From julien at typed-hole.org  Sat Jan  4 18:38:26 2020
From: julien at typed-hole.org (julienxx)
Date: Sat, 4 Jan 2020 18:38:26 +0000 (UTC)
Subject: [ANN] Castor, a graphical Gemini browser
In-Reply-To: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
References: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
Message-ID: <1D72D8387069DE0E.6DE6D0E5-4F3A-46A0-8E24-D908DECF6871@mail.outlook.com>

Added gopher and finger support too!




On Tue, Dec 24, 2019 at 5:44 PM +0100, "Julien Blanchard" <julien at typed-hole.org> wrote:










Hey Geminauts,

I just pushed the initial release of Castor, a GTK Gemini browser. There 
are no binaries yet but if you have a Rust toolchain installed it should 
be easy to compile.

Source is here https://git.sr.ht/~julienxx/castor

I would love some feedback on the app if you have ideas, criticism...

Have some nice Winter solstice festivities!

-- julienxx





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200104/9e6fa71c/attachment.htm>

From magnus at kalasarn.se  Tue Jan  7 12:26:18 2020
From: magnus at kalasarn.se (Magnus Wild)
Date: Tue, 7 Jan 2020 13:26:18 +0100
Subject: [ANN] Castor, a graphical Gemini browser
In-Reply-To: <1D72D8387069DE0E.6DE6D0E5-4F3A-46A0-8E24-D908DECF6871@mail.outlook.com>
References: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
 <1D72D8387069DE0E.6DE6D0E5-4F3A-46A0-8E24-D908DECF6871@mail.outlook.com>
Message-ID: <20200107122618.j3gnbheczg7oxfkp@yasuna.kalasarn.se>

> I just pushed the initial release of Castor, a GTK Gemini browser. There 
> are no binaries yet but if you have a Rust toolchain installed it should 
> be easy to compile.

Easy enough, yes. Works well on openbsd too. Thank you for sharing!

> Added gopher and finger support too!

Works quite nicely too!

/Magnus

From lazar.michael22 at gmail.com  Thu Jan  9 06:00:04 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 9 Jan 2020 01:00:04 -0500
Subject: Script to test gemini servers
Message-ID: <CAFTy05Z73QD2BW+v9sd0HTByUZhiAKbvyw7Rwa05N9YQ0iMABw@mail.gmail.com>

Hi all,

I have been working on a python script that can be pointed to a gemini server,
and will automatically send various types of requests to surface errors and
other strange server behavior. This was suggested in the mailing list a while
ago by solderpunk(?). I thought it was a neat idea so I took my own stab at it.

I am not attempting to cover 100% of the gemini specification. Some of the
checks aren't even related to the spec, and are strictly informational.
Take all results with a grain of salt.

For example:

- Does your server support IPv6?
- What version of TLS do you negotiate?
- Is your certificate's CA trusted?
- How do you respond to a http:// URL?
- How do you respond to a URL with an invalid UTF-8 byte sequence?
- How do you respond to a request with a newline but no carriage return?

The program can be found here:

https://github.com/michael-lazar/jetforce/blob/master/jetforce_diagnostics.py

I've included it in the jetforce repo out of convenience, but the script can
be downloaded and run independently of jetforce. The only hard dependency is
Python 3.7+. The python "pyca/cryptography" library is an optional requirement,
if you want to inspect server TLS certificates.

Usage:
  ./jetforce_diagnostics.py host [port]

This is very much still considered a work-in-progress. If you have any
suggestions or would like to contribute additional tests to run, please feel
encouraged to respond here or open an issue or PR in the github repo.

To save you all the trouble, I have already run this against all known gemini
servers and published the results on my server. This is not an attempt to
shame anybody, my own server exposed several failures that I now need to fix.
But I think there are some interesting insights to be gleaned about how servers
are implemented in practice, and how the gemini spec might be improved:

gemini://mozz.us/diagnostics/

Some of the results:

- All servers use "\n" line endings on their home page instead of "\r\n"
- No server will accept a URL without a scheme specified (per the spec, this
  should be implied as gemini://)
- Only half of servers currently support TLS version 1.3

- mozz

From sean at conman.org  Thu Jan  9 07:11:32 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 9 Jan 2020 02:11:32 -0500
Subject: Script to test gemini servers
In-Reply-To: <CAFTy05Z73QD2BW+v9sd0HTByUZhiAKbvyw7Rwa05N9YQ0iMABw@mail.gmail.com>
References: <CAFTy05Z73QD2BW+v9sd0HTByUZhiAKbvyw7Rwa05N9YQ0iMABw@mail.gmail.com>
Message-ID: <20200109071132.GA19769@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> Hi all,

  Hello.

> I have been working on a python script that can be pointed to a gemini server,
> and will automatically send various types of requests to surface errors and
> other strange server behavior. This was suggested in the mailing list a while
> ago by solderpunk(?). I thought it was a neat idea so I took my own stab at it.

  Thanks for doing this.  I find the results interesting, and yes, you did
find three bugs in GLV-1.12556.

> For example:
> 
> - Does your server support IPv6?

  Mine (GLV-1.12556) does, but my hosting provider doesn't have IPv6 yet (or
maybe they do---it's been awhile since I last checked).

> - What version of TLS do you negotiate?

  1.2---it's a limitation of the library I'm using.

> - Is your certificate's CA trusted?

  No.  I'm the one using a custom CA.

> - How do you respond to a http:// URL?

  I reject them.

> - How do you respond to a URL with an invalid UTF-8 byte sequence?

  Here's one of the bugs, and I have no idea how I'll fix this as it's a
cross-library concern.  Sigh.

> - How do you respond to a request with a newline but no carriage return?

  I respond.  I made CRs optional everywhere internally---it makes it easier
for me to test.  Now, you did make one test labeled "RequestMissingCR" where
you did send a LF.  Per the spec, I would expect this to return a 59 Bad
Request, but since I treat CRs as optional, that's why I passed that one.

> Some of the results:
> 
> - All servers use "\n" line endings on their home page instead of "\r\n"
> - No server will accept a URL without a scheme specified (per the spec, this
>   should be implied as gemini://)

  This was another bug.  I've already fixed this, and the one other bug (I
allow URLs longer than 1024 characters, which has been fixed for now).

  Again, thanks for this.

  -spc


From solderpunk at SDF.ORG  Thu Jan  9 19:14:06 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 9 Jan 2020 19:14:06 +0000
Subject: Script to test gemini servers
In-Reply-To: <20200109071132.GA19769@brevard.conman.org>
References: <CAFTy05Z73QD2BW+v9sd0HTByUZhiAKbvyw7Rwa05N9YQ0iMABw@mail.gmail.com>
 <20200109071132.GA19769@brevard.conman.org>
Message-ID: <20200109191406.GA29609@SDF.ORG>

On Thu, Jan 09, 2020 at 02:11:32AM -0500, Sean Conner wrote:
> 
>   Again, thanks for this.
>

Yes, thanks a lot for this, because I'm continuing to do a bad job of
pushing this idea to completion!

If you're feeling motivated, some things which my rough stab at this
tested which you didn't mention are:

* What happens if the client sends a totally empty request?
* What happens if the client sends a non-empty request which is not a
  URL of any kind, like "Hello, Gemini!\r\n"?
* What happens if the client sends a non-empty request with a valid URL
  which is longer than 1024 characters?

All of these should result in a status code of 59.

Cheers,
Solderpunk

From lazar.michael22 at gmail.com  Fri Jan 10 05:08:31 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Fri, 10 Jan 2020 00:08:31 -0500
Subject: Script to test gemini servers
In-Reply-To: <20200109071132.GA19769@brevard.conman.org>
References: <CAFTy05Z73QD2BW+v9sd0HTByUZhiAKbvyw7Rwa05N9YQ0iMABw@mail.gmail.com>
 <20200109071132.GA19769@brevard.conman.org>
Message-ID: <CAFTy05YP3+e6twUe8jQRavPaREo6B89zXW0+U7frjFCByDyumg@mail.gmail.com>

On Thu, Jan 9, 2020 at 2:11 AM Sean Conner <sean at conman.org> wrote:
>
> It was thus said that the Great Michael Lazar once stated:
> > - How do you respond to a request with a newline but no carriage return?
>
>   I respond.  I made CRs optional everywhere internally---it makes it easier
> for me to test.  Now, you did make one test labeled "RequestMissingCR" where
> you did send a LF.  Per the spec, I would expect this to return a 59 Bad
> Request, but since I treat CRs as optional, that's why I passed that one.

It's interesting to hear that this was intentional on your part. You're not
alone on this, 3/5 servers that I tested didn't care about the CR at all. My
own server does require the CR, but I didn't like writing it that way and felt
like I had to jump through unnecessary hoops to conform to the specification:

    data = await self.reader.readuntil(b"\r\n")

instead of the more straightforward:

    data = await self.reader.readline()

I would prefer it if CR was optional. Similar to how <whitespace> is already
defined as "any non-zero number of consecutive spaces or tabs". The same
argument applies here. Content authors can't visually distinguish newline
characters in text/gemini files, and I can't tell the difference in my terminal
when I'm inspecting a gemini request.

   <newline> = [<CR>]<LF>

- mozz

From solderpunk at SDF.ORG  Sun Jan 12 11:36:30 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 12 Jan 2020 11:36:30 +0000
Subject: [ANN] Castor, a graphical Gemini browser
In-Reply-To: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
References: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
Message-ID: <20200112113630.GA7000@SDF.ORG>

Thanks for sharing this, and congrats on being the first graphical
Gemini client author!

Today I finally managed to get Castor compiled (Rust and Debian Stable
are not a winning combiation) and took it for a little test drive.  On
the whole it seems to work quite nicely, but I did notice some oddities
with Gopher content, e.g.
gopher://republic.circumlunar.space/~katolaz/phlog/20200111_hack_the_break.txt
seems to have the top part of the document missing.

I have added Castor to the official list of Gemini software at
gemini.circumlunar.space, sorry for the delay in doing so!

Cheers,
Solderpunk

On Tue, Dec 24, 2019 at 05:44:31PM +0100, Julien Blanchard wrote:
> Hey Geminauts,
> 
> I just pushed the initial release of Castor, a GTK Gemini browser. There are
> no binaries yet but if you have a Rust toolchain installed it should be easy
> to compile.
> 
> Source is here https://git.sr.ht/~julienxx/castor
> 
> I would love some feedback on the app if you have ideas, criticism...
> 
> Have some nice Winter solstice festivities!
> 
> -- julienxx
> 

From baschdel at disroot.org  Sun Jan 12 13:00:13 2020
From: baschdel at disroot.org (baschdel at disroot.org)
Date: Sun, 12 Jan 2020 14:00:13 +0100
Subject: [ANN] Castor, a graphical Gemini browser
In-Reply-To: <20200107122618.j3gnbheczg7oxfkp@yasuna.kalasarn.se>
References: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
 <1D72D8387069DE0E.6DE6D0E5-4F3A-46A0-8E24-D908DECF6871@mail.outlook.com>
 <20200107122618.j3gnbheczg7oxfkp@yasuna.kalasarn.se>
Message-ID: <1578834013.2744.1@disroot.org>


Finally got around to trying it out.
It's good to see a second graphical gemini browser, also you clearly 
put some more work into the gtk side of things wich looks really good, 
than I did with "dragonstone".

Thank you for sharing this one!

-Baschdel


Here is a link to dragonstone: https://gitlab.com/baschdel/dragonstone
(I stopped working on it beacause of other projects)







From solderpunk at SDF.ORG  Sun Jan 12 15:31:39 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 12 Jan 2020 15:31:39 +0000
Subject: [ANN] Announcing Molly Brown, a Gemini server in Go
Message-ID: <20200112153139.GB7000@SDF.ORG>

Happy 2020, Gemininauts!

As I mentioned previously and briefly on this list, over at
https://tildegit.org/solderpunk/molly-brown I am working on a Gemini
server of my own, named (The Unsinkable) Molly Brown.  Molly for
short is just fine!

The server is written in Go and is intended to be a fully featured
server, implementing all aspects of the protocol.  This is a very
deliberate decision to force me to be personally aware of the
implementation difficulty involved in everything that gets specced.

Molly is also designed to function in a multi-user environment, such as
a public access unix server, where individual users have no access to
the main server configuration file and hence need some other way to
control features such as redirection or certificate requirements.  None
of this is implemented yet, but I plan to use .molly files, similar to
the .htaccess files used by Apache.  I'm very open to other ideas,
though, if anybody has any.

Molly Brown is now powering the site at gemini.circumlunar.space (which
previously ran JetForce).

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jan 12 15:43:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 12 Jan 2020 15:43:21 +0000
Subject: [ANN] Announcing free Gemini hosting at gemini.circumlunar.space
Message-ID: <20200112154321.GC7000@SDF.ORG>

If there is anybody on this list who has been itching to start creating
Gemini content but isn't able to or interested in running their own
server, I have good news for you!

I am now offering free Geminispace which you can manage via sftp at
gemini.circumlunar.space.  You can choose a username and you'll get a
good old fashioned tilde URL, like
gemini.circumlunar.space/~solderpunk/.  You can host anything there you
like which doesn't get me in legal trouble and which I judge not to pose
any risk of bringing the Gemini project into ill-repute.

For now, I am extending this offer only to people subscribed to this
list, to keep things easily manageable while Molly Brown is still under
development.

If you are interested, please email me (not the whole list!) with your
desired username and an SSH public key.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jan 12 18:43:41 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 12 Jan 2020 18:43:41 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
Message-ID: <20200112184341.GA1011@SDF.ORG>

Okay, I have started to re-engage with this endless discussion -
slowly and, I have to admit, reluctantly.  When I think about how many
details there are to consider here, how many different options we have
to choose among, and how absolutely incredible the power-to-weight
ratio is of verbatim fixed-width text with a predefined width (I
mean, really, you can:

Left align text,
                             center text,
                                                 even right align text

without the client having to even know what those things are!), it's
incredibly tempting to echo the "reflowed text be damned!" sentiment
recently expressed at mozz.us[1] and spec 40 character fixed text and
just move on.

But I know that'd be rash.  These days I have been worrying less about
catering to small-screened mobile devices and thinking more about the
ability for Gemini to be self-documenting.  Granted, the text/gemini
format is pretty darned simple by design, but nevertheless, having
really nice and clear instructions for beginners, many of whom may
conceivably never have written either web or gopher content before in
their life, will be important to the widespread adoption of the
protocol.

Imagine how much harder it would be to learn HTML if websites couldn't
actually contain any code that you could copy and paste!  This is
exactly where Gemini is today.  Yes, okay, you could put a single
space at the start of a link line so it would be displayed as-is rather
than treated as a link, and that would be mostly fine.  But it would
interfere with the ability to simply copy and paste a block of example
links and have it work as-is, because the spaces at the front of at
least some of the lines would get copied as well.

Gopher is better than the current Gemini spec in this regard, because
you can put gophermap lines in an item type 0 text file no problem and
they'll just be displayed as-is.  But copying and pasting that
gophermap is not guaranteed to go smoothly.  With terminal-based
applications, the tabs would stand a good chance of being transformed
into consecutive spaces, which would actually break them.  Let's be
better than that!  Let's make it possible to display, copy and paste 
Gemini links inside of Gemini documents, to facilitate teaching and
talking about Gemini over Gemini.  It seems quite natural that this
should be possible.

Even if text/gemini were specced at 40 fixed-width characters with no
reflow, meeting this goal would require some syntax comparable to
<pre> tags in HTML, to switch off processing of Gemini links.  If
we're going to have that anyway, we may as well have reflowed text be
the default and this <pre> syntax can do double duty by also enabling
non-reflowed text for source code, poetry, etc.

I remain as commited as ever to the idea that any text/gemini markup
should have the property that simple clients can just dump it right to
stdout verbatim and that should be very usable.  As I argued
previously, this rules out any kind of syntax where <pre> lines are
indicated by some per-line prefix, as that prefix would break
copy-and-pastability for simple clients dumping things to stdout.
This is one more reason not to use the "leading whitespace" system
proposed by Sean[2] (whose detailed spec remains a very nice and
useful precise definition of lots of fuzzy concepts being slung around
here).

So, given this, I am pretty much settled on using an easily
recognisable line to toggle this mode on or off, say:

```

This is the syntax used in the simplified Markdown proposal at
mozz.us[3], and in ratfactor's "Text Junior" format[4], which others
on this list have argued is a good candidate for Gemini syntax.

I have experimented with supporting this syntax, and allowing
reflowing of text not enclosed by ``` lines to an arbitrary
user-specified width in AV-98 (not pushed to tildegit yet, but expect
it soon).  It really is not too difficult to do, so I don't think
complexity of implementation is a good argument against this.

Does anybody know of a programming language where lines consisting only
of three consecutive single quotes happen to occur frequently?

To address briefly some other points raised in this thread:

Somebody suggested that the ``` syntax or similar be used to toggle on
reflowed text, with fixed text being the default.  I have to admit
this feels really backwards to me.  There are many obvious and common
use cases for wanting to embed small fragments of fixed text inside a
document that one would otherwise want flowed.  I can't think of any
case where I'd want the reverse, but of course if people can I'm happy
to hear them.

I am not crazy about the idea of having text/gemini "source code"
consist of extremely long lines of text which are then brutally
wrapped to a given width by a user's terminal.  Some editors might be
smart enough to present that long line wrapped at word boundaries to
the author, but many won't be and this will result in a very ugly
editing environment.  And I'm not aware of any terminal emulator which
wraps long lines at word boundaries, so this will result in an ugly
reading experience for *all* sized screens.

I also really don't like the idea of supporting colour in Gemini
documents.  I see no way to do this with a syntax which would degrade
gracefully when simply dumped to stdout.  This would also open the
possibility of obnoxious pages with gratuitous use of colour.  No,
thanks!

Cheers,
Solderpunk

[1] gemini://mozz.us/journal/2019-12-05.txt
[2] gemini://gemini.conman.org/gRFC/0004
[3] gemini://mozz.us/markdown/
[4] gopher://sdf.org:70/0/users/ratfactor/phlog/2019-04-21-text-junior

From sean at conman.org  Sun Jan 12 19:59:17 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 12 Jan 2020 14:59:17 -0500
Subject: [ANN] Castor, a graphical Gemini browser
In-Reply-To: <20200112113630.GA7000@SDF.ORG>
References: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
 <20200112113630.GA7000@SDF.ORG>
Message-ID: <20200112195917.GD23700@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> Today I finally managed to get Castor compiled (Rust and Debian Stable
> are not a winning combiation) and took it for a little test drive.  On
> the whole it seems to work quite nicely, but I did notice some oddities
> with Gopher content, e.g.
> gopher://republic.circumlunar.space/~katolaz/phlog/20200111_hack_the_break.txt
> seems to have the top part of the document missing.

  That link isn't proper---it should be:

gopher://republic.circumlunar.space/0/~katolaz/phlog/20200111_hack_the_break.txt

  -spc (just an FYI)

From solderpunk at SDF.ORG  Sun Jan 12 20:19:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 12 Jan 2020 20:19:26 +0000
Subject: [ANN] Castor, a graphical Gemini browser
In-Reply-To: <20200112195917.GD23700@brevard.conman.org>
References: <0c8b3f61-1ef9-6ac7-63d2-b3a239931101@typed-hole.org>
 <20200112113630.GA7000@SDF.ORG>
 <20200112195917.GD23700@brevard.conman.org>
Message-ID: <20200112201926.GA14350@SDF.ORG>

Ah, good catch.  I just blindly copied and pasted from the address bar of
Castor, which doesn't seem to iclude item types in the URL.  I don't
think that's related to this error, though, but it might well be.

Cheers,
Solderpunk

On Sun, Jan 12, 2020 at 02:59:17PM -0500, Sean Conner wrote:
> It was thus said that the Great solderpunk once stated:
> > Today I finally managed to get Castor compiled (Rust and Debian Stable
> > are not a winning combiation) and took it for a little test drive.  On
> > the whole it seems to work quite nicely, but I did notice some oddities
> > with Gopher content, e.g.
> > gopher://republic.circumlunar.space/~katolaz/phlog/20200111_hack_the_break.txt
> > seems to have the top part of the document missing.
> 
>   That link isn't proper---it should be:
> 
> gopher://republic.circumlunar.space/0/~katolaz/phlog/20200111_hack_the_break.txt
> 
>   -spc (just an FYI)

From sean at conman.org  Mon Jan 13 22:55:04 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 13 Jan 2020 17:55:04 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200112184341.GA1011@SDF.ORG>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
Message-ID: <20200113225504.GF23700@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> I remain as commited as ever to the idea that any text/gemini markup
> should have the property that simple clients can just dump it right to
> stdout verbatim and that should be very usable.  As I argued
> previously, this rules out any kind of syntax where <pre> lines are
> indicated by some per-line prefix, as that prefix would break
> copy-and-pastability for simple clients dumping things to stdout.
> This is one more reason not to use the "leading whitespace" system
> proposed by Sean[2] (whose detailed spec remains a very nice and
> useful precise definition of lots of fuzzy concepts being slung around
> here).

  Thanks.  I understand the concern about copy-n-pasting (I see issues all
the time on Reddit when people don't understand to prepend each line with
four spaces when posting source code).

> So, given this, I am pretty much settled on using an easily
> recognisable line to toggle this mode on or off, say:
> 
> ```

  I have questions.  Oh, do I have questions.


```
This text is on the left.
		This text is mostly centered.
				This text is on the right.
```

But now ...

````
Note that there are four ticks.
  What's the expected result?
    Literal text?
      Or reflowed text?
```

```
This is similar to the above,
  but the block ends with four ticks,
    not the expecte three.
````

``` What about trailing text?
  Is that allowd?
    What is the expected result?
```

```
```

(You should be able to handle the above as well).

> I have experimented with supporting this syntax, and allowing
> reflowing of text not enclosed by ``` lines to an arbitrary
> user-specified width in AV-98 (not pushed to tildegit yet, but expect
> it soon).  It really is not too difficult to do, so I don't think
> complexity of implementation is a good argument against this.

  One thing to watch out for are lines that exceed the wrapping length with
no space (or dash if you are ambitious) characters to break on.

> Does anybody know of a programming language where lines consisting only
> of three consecutive single quotes happen to occur frequently?

  I want to say Python.  I don't program in Python, but I know I have seen
that syntax in some lanuage.

  -spc

> [2] gemini://gemini.conman.org/gRFC/0004

From tomasino at lavabit.com  Mon Jan 13 23:08:58 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 13 Jan 2020 23:08:58 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200113225504.GF23700@brevard.conman.org>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG> <20200113225504.GF23700@brevard.conman.org>
Message-ID: <50420AAA-DCDB-4180-8ACA-A2327B29C45F@lavabit.com>

> Does anybody know of a programming 
> language where lines consisting only
> of three consecutive single quotes happen to 
> occur frequently?

Just a point of clarification: markdown code fences and your examples use three backticks, not single quotes


From sean at conman.org  Mon Jan 13 23:22:40 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 13 Jan 2020 18:22:40 -0500
Subject: [ANN] Announcing Molly Brown, a Gemini server in Go
In-Reply-To: <20200112153139.GB7000@SDF.ORG>
References: <20200112153139.GB7000@SDF.ORG>
Message-ID: <20200113232240.GG23700@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> Happy 2020, Gemininauts!
> 
> As I mentioned previously and briefly on this list, over at
> https://tildegit.org/solderpunk/molly-brown I am working on a Gemini
> server of my own, named (The Unsinkable) Molly Brown.  Molly for
> short is just fine!
> 
> The server is written in Go and is intended to be a fully featured
> server, implementing all aspects of the protocol.  This is a very
> deliberate decision to force me to be personally aware of the
> implementation difficulty involved in everything that gets specced.

  I was looking over the code for CGI support and I notice we took two very
different approaches to it.  I based my support upon RFC-3875, with some
changes to reflect Gemini (and support running existing web-based CGI
programs by mapping the return status codes), while you pretty much just run
the script.  I would expect at the very least the QUERY_STRING
meta-variable (as RFC-3875 calls it, or "environment variable" as everybody
else calls them) to be set.

  But given that CGI wasn't specced for Gemini, I think both our
implementations are compliant though.

> Molly is also designed to function in a multi-user environment, such as
> a public access unix server, where individual users have no access to
> the main server configuration file and hence need some other way to
> control features such as redirection or certificate requirements.  None
> of this is implemented yet, but I plan to use .molly files, similar to
> the .htaccess files used by Apache.  I'm very open to other ideas,
> though, if anybody has any.

  I previous did this for GLV-1.12556 but removed the feature [1].  Some
issues you will have to deal with:

	* Syntax errors in the config file and how to handle them.
	* Do you cache the configs?  If you do, how do you get new changes?
	  If you don't, you get a potential performance problem.
	* Do you support configs per directory?

  -spc

[1]	Only for authenticating certificates, and it was per-directory. This
	made it hard to support authentication for non-filesystem handlers
	(which I have a lot of) so I moved authentication to the primary
	config file.

From sean at conman.org  Mon Jan 13 23:23:38 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 13 Jan 2020 18:23:38 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <50420AAA-DCDB-4180-8ACA-A2327B29C45F@lavabit.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG> <20200113225504.GF23700@brevard.conman.org>
 <50420AAA-DCDB-4180-8ACA-A2327B29C45F@lavabit.com>
Message-ID: <20200113232338.GH23700@brevard.conman.org>

It was thus said that the Great James Tomasino once stated:
> > Does anybody know of a programming 
> > language where lines consisting only
> > of three consecutive single quotes happen to 
> > occur frequently?
> 
> Just a point of clarification: markdown code fences and your examples use
> three backticks, not single quotes

  Ah!  That's it!  I knew I saw *something* similar to that in Python.

  -spc


From solderpunk at SDF.ORG  Tue Jan 14 18:43:39 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 14 Jan 2020 18:43:39 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <50420AAA-DCDB-4180-8ACA-A2327B29C45F@lavabit.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <20200113225504.GF23700@brevard.conman.org>
 <50420AAA-DCDB-4180-8ACA-A2327B29C45F@lavabit.com>
Message-ID: <20200114184339.GA10786@SDF.ORG>

On Mon, Jan 13, 2020 at 11:08:58PM +0000, James Tomasino wrote:
> > Does anybody know of a programming 
> > language where lines consisting only
> > of three consecutive single quotes happen to 
> > occur frequently?
> 
> Just a point of clarification: markdown code fences and your examples use three backticks, not single quotes
> 

Whoops, right you are!  I blame years and years of LaTeX for blurring
the distinction in my mind with it's `unusual quotation syntax'.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jan 14 19:03:48 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 14 Jan 2020 19:03:48 +0000
Subject: [ANN] Announcing Molly Brown, a Gemini server in Go
In-Reply-To: <20200113232240.GG23700@brevard.conman.org>
References: <20200112153139.GB7000@SDF.ORG>
 <20200113232240.GG23700@brevard.conman.org>
Message-ID: <20200114190348.GB10786@SDF.ORG>

On Mon, Jan 13, 2020 at 06:22:40PM -0500, Sean Conner wrote:
> 
>   I was looking over the code for CGI support and I notice we took two very
> different approaches to it.  I based my support upon RFC-3875, with some
> changes to reflect Gemini (and support running existing web-based CGI
> programs by mapping the return status codes), while you pretty much just run
> the script.  I would expect at the very least the QUERY_STRING
> meta-variable (as RFC-3875 calls it, or "environment variable" as everybody
> else calls them) to be set.
> 
>   But given that CGI wasn't specced for Gemini, I think both our
> implementations are compliant though.

Good eye!  I actually intended to post something abou this to the list
shortly after implementing that CGI support, but I suppose that must
have been around the time things started getting really busy for me.

The extremely simple approach to "CGI" (or whatever we want to call
dynamic content) in MollyBrown came about mostly because sloum was keen
to start playing with dynamic content, so I did the simplest thing that
could possibly work - run the script, tell it the corresponding URL over
stdin and then close the pipe.  It can parse out any user input after a
& if it needs it.

This decision should not be interpreted as a criticism of your
RFC-3875-derived implementation.  I think it makes good sense for there
to be an option for people to easily convert existing web CGI scripts to
Gemini.

But I do think it would be nice if there was one vaguely standard way
for servers to implement this kind of thing, so that dynamic content
generating code could be more portable.  I think for that I'd probably
prefer something as light as possible, and to explicitly distance Gemini
from many of the ideas baked into RFC-3875, especially that dynamic
content code should have access to the end user's IP address.

I think there's a lot to recommend the way Molly Brown works, especially
if we generalise it just a little to "Gemini CGI apps should endlessly
read single line URLs over THING, until THING is closed, at which point
the app should terminate".  Here THING could be stdin, or a TCP
connection (making a CGI app basically a small self-contained server),
or a unix domain socket.  Simple servers could do what Molly currently
does, just spawn the script, send a single URL over stdin and then close
stdin, giving us the good old fashioned one-process-per-request model of
traditional web CGI.  But more advanced servers could give admins a way
to configure different approaches where the process is persistent, more
like FastCGI.  Or they could round-robin load balance between multiple
servers on a local network.  The actual CGI program would see very
little difference between these scenarios, you'd just give a slightly
different argument to a library function which produced some kind of
iterator over URLs.  This has great power:weight.

I was very happy with this idea until I realised that CGI programs
should also have some way to get access to client certificates, not just
the URL. :(

I haven't returned since then to thinking about how to achieve this.
Maybe a good subject for a new thread...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jan 14 19:34:00 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 14 Jan 2020 19:34:00 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200113225504.GF23700@brevard.conman.org>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <20200113225504.GF23700@brevard.conman.org>
Message-ID: <20200114193400.GC10786@SDF.ORG>

On Mon, Jan 13, 2020 at 05:55:04PM -0500, Sean Conner wrote:

It seems easiest to me (and my current experimental implementation in
AV-98 does this) to make the spec quite strict in this regard: verbatim
mode is toggled on/off by lines consisting of precisely 3 ticks and
nothing else.  Which means...
 
> ````
> Note that there are four ticks.
>   What's the expected result?
>     Literal text?
>       Or reflowed text?
> ```

The first 5 lines of this will be reflowed, the final line will trigger
literal text below it.

> ```
> This is similar to the above,
>   but the block ends with four ticks,
>     not the expecte three.
> ````

Literal mode is turned on by the first line but never turned off, so
there will be a literal line of four ticks and that end, and whatever
comes lext will be literalised, too!
 
> ``` What about trailing text?
>   Is that allowd?
>     What is the expected result?
> ```

Literal mode won't be turned on until the very end, and the first three
lines will be flowed.

> ```
> ```
> 
> (You should be able to handle the above as well).

Hmm, I think AV-98 will handle that just fine, hang on...yep, no
problems.

>   One thing to watch out for are lines that exceed the wrapping length with
> no space (or dash if you are ambitious) characters to break on.

Ah, that's an annoying edge case.  I guess such lines can just be broken
at exactly the viewport width, possibly with a dash at the end of all
but the final line?
 
>   I want to say Python.  I don't program in Python, but I know I have seen
> that syntax in some lanuage.

I was briefly worried about Python docstrings (before Tomasino pointed
out we aren't using quotes at all!), but PEP 257 recommends always using
double quotes for them anyway.

Cheers,
Solderpunk

From tomasino at lavabit.com  Tue Jan 14 21:02:52 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 14 Jan 2020 21:02:52 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200114193400.GC10786@SDF.ORG>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG> <20200113225504.GF23700@brevard.conman.org>
 <20200114193400.GC10786@SDF.ORG>
Message-ID: <1D76A420-2CB1-4FEA-9B0D-66DE63E220BF@lavabit.com>




-------- Original Message --------
From: solderpunk <solderpunk at SDF.ORG>

> verbatim mode is toggled on/off by lines 
> consisting of precisely 3 ticks and nothing 
> else.  

Again, just clarifying for people who might not be familiar: the code fencing in markdown often allows the initial backtick trio to be followed by a filetype which aids clients in syntax highlighting. They look like so:

```bash
```javascript
```ruby

I don't suggest gemini needs that, but know that people may assume the behavior because it is familiar. It might be easier to declare lines starting with 3 backticks to be the code fence barriers regardless of what comes later. If clients want to develop extra syntax highlighting they could, but mostly it would mean people pasting code they'd use on GitHub or stackoverflow will not be surprised by broken wrapping.


From sean at conman.org  Tue Jan 14 23:49:20 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 14 Jan 2020 18:49:20 -0500
Subject: CGI and CGI like support (was Re: [ANN] Announcing Molly Brown,
 a Gemini server in Go)
In-Reply-To: <20200114190348.GB10786@SDF.ORG>
References: <20200112153139.GB7000@SDF.ORG>
 <20200113232240.GG23700@brevard.conman.org> <20200114190348.GB10786@SDF.ORG>
Message-ID: <20200114234920.GA13720@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> This decision should not be interpreted as a criticism of your
> RFC-3875-derived implementation.  I think it makes good sense for there
> to be an option for people to easily convert existing web CGI scripts to
> Gemini.
> 
> But I do think it would be nice if there was one vaguely standard way
> for servers to implement this kind of thing, so that dynamic content
> generating code could be more portable.  I think for that I'd probably
> prefer something as light as possible, and to explicitly distance Gemini
> from many of the ideas baked into RFC-3875, especially that dynamic
> content code should have access to the end user's IP address.

  RFC-3875 wasn't that bad to support as there aren't that many
meta-varables (as they are called) to suport, and several are optional
anyway.  The RFC doesn't cover how the meta-varriables are sent to the
script, but under Unixland, it's via envinroment variables.

Here's what I currently do:

	AUTH_TYPE
		Not set unless the client provides a certificate, then this
		gets set to "Certificate".

	CONTENT_LENGTH
		Doesn't apply as there's no way to send a document to a
		Gemini server.

	CONTENT_TYPE
		Doesn't apply.

	GATEWAY_INTERFACE
		Set to "CGI/1.1"

	PATH_INFO
		Per RFC (wording is a bit muddled), and not always set.

	PATH_TRANSLATED
		Per RFC, and not always set.  I will say that these two are
		a bit persnickity to get right.

	QUERY_STRING
		Must be set.  If no query string, set to "".

	REMOTE_ADDR
	REMOTE_HOST
		I take it these are the ones you oject to the most.  But if
		I'm running a Gemini server, I *already* have your IP
		address anyway.  It seems silly to hide it to me, but I
		don't live in Europe so take what I say with a grain of salt
		or two.  I set these (to just the IP address).

	REMOTE_IDENT
		Nobody supports RFC-1413, so I skip this one.

	REMOTE_USER 
		If a client provides a certificate, I set this to the client
		subject common name.

	REQUEST_METHOD
		I set this to "", as Gemini has no concept of a request
		method (but see below).

	SCRIPT_NAME
		Per RFC.  Not hard to set properly.

	SERVER_NAME 
		Hostname of the current server.  If you support multiple
		hosts per Gemini, then I would set this to the host the
		client connected to.

	SERVER_PORT
		Set to port number of server.

	SERVER_PROTOCOL
		Set to "GEMINI".

	SERVER_SOFTWARE
		Set to "GLV-1.12556/1".

  And that's it without further configuration.  As a default, a CGI script
will ONLY get these environment variables (whereas your implementation leaks
the parent environment to the script---might want to check that).  I allow
one to set other environment variables per script (like $PATH or $LANG or
whatever).  If you need HTTP compatibility, I set some HTTP_* and change
REQUEST_METHOD to "GET" and SERVER_PROTOCOL to "HTTP/1.0".  I also have an
option to set some variables that Apache sets as well.

  If the client presents a certificate, I set the following:

	TLS_CIPHER
	TLS_VERSION
	TLS_CLIENT_HASH
	TLS_CLIENT_ISSUER
	TLS_CLIENT_SUBJECT
	TLS_CLIENT_NOT_BEFORE
	TLS_CLIENT_NOT_AFTER
	TLS_CLIENT_REMAIN (time between now and TLS_CLIENT_NOT_AFTER)
	TLS_CLIENT_ISSUER_* (various fields broken down)
	TLS_CLIENT_SUBJECT_* (various fields broken down)

and AUTH_TYPE and REMOTE_USER as mentioned above (if Apache compatibility
requested, the names change but it's largely the same information).  Details
can be seen starting here:

https://github.com/spc476/GLV-1.12556/blob/master/Lua/GLV-1/cgi.lua#L241
	
> I think there's a lot to recommend the way Molly Brown works, especially
> if we generalise it just a little to "Gemini CGI apps should endlessly
> read single line URLs over THING, until THING is closed, at which point
> the app should terminate".  

  Oh, so pretty much a Gemini server sans TLS then.

> Here THING could be stdin, or a TCP
> connection (making a CGI app basically a small self-contained server),
> or a unix domain socket.  Simple servers could do what Molly currently
> does, just spawn the script, send a single URL over stdin and then close
> stdin, giving us the good old fashioned one-process-per-request model of
> traditional web CGI.  But more advanced servers could give admins a way
> to configure different approaches where the process is persistent, more
> like FastCGI.  Or they could round-robin load balance between multiple
> servers on a local network.  The actual CGI program would see very
> little difference between these scenarios, you'd just give a slightly
> different argument to a library function which produced some kind of
> iterator over URLs.  This has great power:weight.
> 
> I was very happy with this idea until I realised that CGI programs
> should also have some way to get access to client certificates, not just
> the URL. :(
> 
> I haven't returned since then to thinking about how to achieve this.

  Perhaps a series of line, like:

	Request: gemini://example.net/foo/bar/script
	TLS_Cipher: ...
	TLS_Version: ...
	TLS_CLient_Hash: ...
	TLS_Client_Issuer: ...

  Ends with EOF (or a blank line or a NUL byte or some way to indicate the end
of this one request).  This is consistent (each line is formatted the same
way) and I think, easy to deal with.

  But whatever you come up with, I would try to avoid calling it CGI, as
that tends to lead to RFC-3875 ...

  -spc

From lazar.michael22 at gmail.com  Wed Jan 15 05:03:28 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Wed, 15 Jan 2020 00:03:28 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200112184341.GA1011@SDF.ORG>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
Message-ID: <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>

On Sun, Jan 12, 2020 at 1:43 PM solderpunk <solderpunk at sdf.org> wrote:
>
> Okay, I have started to re-engage with this endless discussion -
> slowly and, I have to admit, reluctantly.  When I think about how many
> details there are to consider here, how many different options we have
> to choose among, and how absolutely incredible the power-to-weight
> ratio is of verbatim fixed-width text with a predefined width (I
> mean, really, you can:
>
> Left align text,
>                              center text,
>                                                  even right align text
>
> without the client having to even know what those things are!), it's
> incredibly tempting to echo the "reflowed text be damned!" sentiment
> recently expressed at mozz.us[1] and spec 40 character fixed text and
> just move on.

For what it's worth, I have been trying
out the 40-character width thing for a
while now and I'm really enjoying it! I
actually find it a lot more pleasant to
type vs 80 character lines. I don't know
if it's because my eyes don't need to
jump as far, or because it takes fewer
keystrokes to move my cursor to the
middle of a line... Something about it
just *feels* good to type.

Not to mention, pages like this [1]
display perfectly on my iphone using a
gemini-http proxy server. Regardless of
whether you choose to adopt the ```
mode, you're still going to need to
recommend a line length for authors to
hard wrap their text/gemini files at.
And I suggest that 40 is still worth
considering for this.

> Gopher is better than the current Gemini spec in this regard, because
> you can put gophermap lines in an item type 0 text file no problem and
> they'll just be displayed as-is.  But copying and pasting that
> gophermap is not guaranteed to go smoothly.  With terminal-based
> applications, the tabs would stand a good chance of being transformed
> into consecutive spaces, which would actually break them.  Let's be
> better than that!  Let's make it possible to display, copy and paste
> Gemini links inside of Gemini documents, to facilitate teaching and
> talking about Gemini over Gemini.  It seems quite natural that this
> should be possible.
>
> Even if text/gemini were specced at 40 fixed-width characters with no
> reflow, meeting this goal would require some syntax comparable to
> <pre> tags in HTML, to switch off processing of Gemini links.  If
> we're going to have that anyway, we may as well have reflowed text be
> the default and this <pre> syntax can do double duty by also enabling
> non-reflowed text for source code, poetry, etc.

Here are some other alternatives that
might be worth considering. I do think
that displaying gemini links is a valid
use-case, but adding a whole new
preformatted text mode only for this
narrow case feels a bit heavy-handed to
me. Granted, I realize there are other
benefits to the preformatted mode that
have already been outlined.

Option 1. Use a no-op link

Pick a URL that by convention doesn't
lead anywhere useful, and then hijack
the (link friendly name) portion to
display your gemini link.

=># =>/about.txt About

"#" is a valid relative URL, right?
Somebody else on this list *cough* sean
might be able to some up with something
better. This would be displayed on
most gemini clients as:

=>/about.txt About

The line would be highlighted as a link
(unless clients choose to handle this
special case), but otherwise it should
work without any changes to the spec.

Option 2. Use text/plain

For the narrow use-case where you want
to show off some examples of gemini
links, stick those links in a separate
text/plain document. Or just serve your
whole page as text/plain. The example
links can't intermingle with real gemini
links in the same document, but is that
really such a big deal?

How you feel about this option likely
depends on which side of the fence you
fall on regarding text/gemini usage.
Should text/gemini be used like HTML is
on the web, with most content being
written as gemini files? Or should it be
more like gopher, where directories are
type text/gemini but many people write
their blog posts and other leaf
documents as text/plain.

Lately I have been leaning more towards
the second interpretation. Take another
example: Instead of writing a python
code snippet inline in a text/gemini
document, what if you instead added a
link to your code snippet and served it
as "text/x-python"? This feels natural
to me given that other media content
like images also can't be displayed
inline.

[1] https://portal.mozz.us/gemini/mozz.us/diagnostics/2020-01-08/notes.gmi

- mozz

From sean at conman.org  Wed Jan 15 05:21:17 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 15 Jan 2020 00:21:17 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
Message-ID: <20200115052117.GB13720@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> 
> Option 1. Use a no-op link
> 
> Pick a URL that by convention doesn't
> lead anywhere useful, and then hijack
> the (link friendly name) portion to
> display your gemini link.
> 
> =># =>/about.txt About
> 
> "#" is a valid relative URL, right?
> Somebody else on this list *cough* sean
> might be able to some up with something
> better. 

  Who?  Me?  Wait!  Did you ask for two examples of a pronoun?  

  Anyway, yes '#' is a vaild URL, or at least, it passes through my URL
parser.  And it's a cute work around.

> This would be displayed on
> most gemini clients as:
> 
> =>/about.txt About
> 
> The line would be highlighted as a link
> (unless clients choose to handle this
> special case), but otherwise it should
> work without any changes to the spec.
> 
> Option 2. Use text/plain

  Option 3, Use text/markdown.  RFCs 7763 and 7764.  

  Other than that, I don't really ha much of a horse in this particular
race.

  -spc


From b__m__e at mailfence.com  Wed Jan 15 19:30:50 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Wed, 15 Jan 2020 20:30:50 +0100 (CET)
Subject: Text reflow woes (or: I want bullets back!)y
Message-ID: <660019441.8880.1579116650232@ichabod.co-bxl>

Solderpunk wrote recently regarding use of color in gemini
documents. 

I would like to put in a vote to the contrary. I know that not
all clients will support color, those that do not may not be
coded to remove any methodology of adding color (current
methods surround vt100/ansi escape sequences). Many
clients will also not be terminal based, making escape
sequences nearly meaningless. Having said all this, my two
cents are that the spec should not address this whatsoever.
It should be on content creators to decide whether adding
said escape sequences is something that are comfortable 
with. Likewise, each client should choose whether this is
a detail they want to handle or not. At present my client
supports color for all protocols that it supports (gopher,
gemini, finger, local files). When color mode is toggled on
any escape sequences in the \033[???m series will be
rendered (but no other escape sequences). It feels weird
to _remove_ gemini from this feature. It feels like it should
not be a part of the spec, just like it is not part of the
gopher spec, and some clients support it and some dont:
content creators beware.


I am running into similar worries with the wrapping and
reflowing conversation. I do not want to add horizontal
scrolling to my client so hard wrapping will be done at
screen width. Reflowing is another matter of course....
I'm starting to feel like it just isnt worth the fuss. Since
_all_ clients seem to hard wrap, just use a long line if you
want flowed content. Done. No extra work required for
clients. It keeps things very very simple. At present gemini
is great to navigate around (what there is of it anyway)
and fulfills the goal of being like gopher, but better. 

Just my two cents...

--?
Sent with https://mailfence.com
Secure and private email

From solderpunk at SDF.ORG  Wed Jan 15 20:21:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 15 Jan 2020 20:21:37 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
Message-ID: <20200115202137.GA21763@SDF.ORG>

On Wed, Jan 15, 2020 at 12:03:28AM -0500, Michael Lazar wrote:
> 
> Not to mention, pages like this [1]
> display perfectly on my iphone using a
> gemini-http proxy server. Regardless of
> whether you choose to adopt the ```
> mode, you're still going to need to
> recommend a line length for authors to
> hard wrap their text/gemini files at.
> And I suggest that 40 is still worth
> considering for this.

Yes, I definitely intend to include a recommendation that text/gemini
content be hard wrapped at something less than the traditional 70 or 80
columns.  This convention seems to slowly taking hold in the
phlogosphere (driven, delightfully, as much by retro PDA enthusiasts as
smartphone users!).  In writing about this earlier, I idly raised the
prospect of clients for "real computers" displaying text hard wrapped at
~40 characters displaying multiple columns side by side - I actually
bumped into an example of this in the wild the other day (see the end of
gemini://tilde.black/users/brool/stoned.txt) and thought it looked
great!
 
> Here are some other alternatives that
> might be worth considering. I do think
> that displaying gemini links is a valid
> use-case, but adding a whole new
> preformatted text mode only for this
> narrow case feels a bit heavy-handed to
> me. Granted, I realize there are other
> benefits to the preformatted mode that
> have already been outlined.

I agree that the ability to display literal Gemini links inside a
text/gemini page probably doesn't, by itself, justify adding any kind
of markup complexity.  But there are indeed many other benefits, as you
mentioned.  I had kind of been on the fence about whether or not such
complexity was worth adding mostly on the basis of those other benefits
(which mostly relate to supporting mobile devices, which, even though I
do use them, I kind of hate and feel reluctant to cater to).  The
realisation that a verbatim text mode can also do some genuinely useful
work even on a "big screen" where text reflowing never has to be done
has, I think, tipped the scales for me enough to decide that this is
worth it.

After all, the essential complexity cost we'd be paying for these
benefits is quite low.  Remembering that it will be explicitly okay for
simple clients not to reflow text if they don't want to, the most
anybody will be obligated to do is something like the following:

in_verbatim = False
for line in all_the_lines:
    if line == "```":
        in_verbatim = not in_verbatim
    elif line.startswith("=>"):
        handle_a_link(line)
    else:
        print(line)

This won't display the ``` lines and will avoid trying to parse any
links which are supposed to be presented verbatim to the uesr (which,
for the purposes of education, might be syntactically invalid and not
something the client should try to parse anyway).  Nobody can
reasonably call the above difficult or bloated, and it's only three
lines longer than the bare minimum that is currently required:
 
for line in all_the_lines:
    if line.startswith("=>"):
        handle_a_link(line)
    else:
        print(line)

(as an aside, the times recently I've talked about "simple clients
catting content straight to stdout" was a bit careless, because of
course you need to actively extract the links as above)

If this is all it takes to make it possible for ambitious client authors
to support word reflowing on mobile clients without making it impossible
to include ASCII art, source code or poetry, that seems like a fair
trade to me.

> Option 1. Use a no-op link
> 
> Pick a URL that by convention doesn't
> lead anywhere useful, and then hijack
> the (link friendly name) portion to
> display your gemini link.
> 
> =># =>/about.txt About
> 
> "#" is a valid relative URL, right?

This is kind of a cute hack, I'll admit, but I worry that (especially to
people that aren't intimiately familiar with RFC3986!) it's obscure and
less easy to remember than the back tick syntax familiar from several
other markup languages.  Also...

> This would be displayed on
> most gemini clients as:
> 
> =>/about.txt About

...it would display as something like:

[7] =>/about.txt About

in AV-98.  And with a button styling in Castor!  In general I think it's
nice if clients have a little leeway in choosing how they want to
present links.

> The line would be highlighted as a link
> (unless clients choose to handle this
> special case), 

Which I guess would take at *least* two extra lines of code, giving this
approach only a one line advantage over the ``` approach which also
facilitates reflowing text (this hack is just to make it possible to
display link syntax insie text/gemini documents, right?).

> Option 2. Use text/plain
> 
> ...
> 
> How you feel about this option likely
> depends on which side of the fence you
> fall on regarding text/gemini usage.
> Should text/gemini be used like HTML is
> on the web, with most content being
> written as gemini files? Or should it be
> more like gopher, where directories are
> type text/gemini but many people write
> their blog posts and other leaf
> documents as text/plain.
> 
> Lately I have been leaning more towards
> the second interpretation. Take another
> example: Instead of writing a python
> code snippet inline in a text/gemini
> document, what if you instead added a
> link to your code snippet and served it
> as "text/x-python"? This feels natural
> to me given that other media content
> like images also can't be displayed
> inline.

This is a conversation well worth having!  From my point of view, Gemini
very deliberately chose to cast aside Gopher's strict distinction
between menus and content, in part because so many people in Gopherspace
seemed to be disatisfied with it.  So, it seems kind of a shame to just
disregard this and go back to the gopher way.  Of course, people are
totally free to do so if they want to!  Neither the protocol nor I will
object.

It is true that there seem to be quite a lot of cases in the wild where
people are using text/gemini menus to link to collections of text/plain
files.  Sometimes this seems to be accidental, because the files
actually contain attempted Gemini links, e.g.:

gemini://tilde.black/users/fox/journal/20190831-starting-out.txt

Other times I suspect this is to facilitate straightforward bihosting on
Gopher and Gemini.

I presonally plan to write Gemini content primarily in text/gemini, and
in fact I'll probably decide how to distribute content between my Gopher
and Gemini sites based in part on how well different kinds of content
benefit from Gemini's ability to do in-line links.  Is anybody else
planning to do this?  Are the people currently not doing this doing so
out of conscious choice or just carrying over old Gopher habits?

As for using in-line links as a way to include un-flowed text, I did
think of this option (maybe somebody else already mentioned it in the
list?).  It would work, but I feel like the user experience would be
fairly clunky, especially for the combination of articles with frequent
short code snippets (like programming tutorials) and simple
terminal-based clients where going "back" to the text/gemini document
from the text/x-python document wouldn't return the reader to the same
point in the (potentially quite long) document from which they followed
the link.

I do take your point, though, that we're already forced into that clunky
paradigm for images and other non-textual media...

Ultimately I don't think I like either of these alternatives as much as
the ``` syntax, but I'm happy to hear others' thoughts...

Cheers,
Solderpunk

From aaron at ajanse.me  Wed Jan 15 20:47:27 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Wed, 15 Jan 2020 12:47:27 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200115202137.GA21763@SDF.ORG>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
Message-ID: <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>

On Wed, Jan 15, 2020, at 12:21 PM, solderpunk wrote:
> On Wed, Jan 15, 2020 at 12:03:28AM -0500, Michael Lazar wrote:
> > 
> > Not to mention, pages like this [1]
> > display perfectly on my iphone using a
> > gemini-http proxy server. Regardless of
> > whether you choose to adopt the ```
> > mode, you're still going to need to
> > recommend a line length for authors to
> > hard wrap their text/gemini files at.
> > And I suggest that 40 is still worth
> > considering for this.
> 
> Yes, I definitely intend to include a recommendation that text/gemini
> content be hard wrapped

May I ask why?

Hard wrapping causes several issues:

1. If someone is using git, for example, to version control their gemini blog
   source code, they might have to re-wrap entire paragraphs in order to add
   one word to the beginning.

2. Many markdown documents have 500+ column lines (one paragraph per
   newline). If we require that Gemini source code is hard-wrapped, users
   couldn't copy-paste markdown into their gemini blog/site without
   hard-wrapping first.

In fact, I think *discouraging* hard-wrapping might actually make life easier
for client implementers. Hard-wrapping would require clients to un-wrap the
newlines then re-wrap to the desired width. I think that's more complex than:

1. Leaving wrapping up to the output medium (e.g. terminal, web browser).

2. Implementing wrapping within the client source code (which would be done
   anyway if Gemini source code *can be* hard-wrapped)

Oh, well. I'm vocal about this because Gemini looks really exciting to me.
As someone who plans to use it, I simply want it to be what I think is as
easy to use as possible :-)

Cheers!

From b__m__e at mailfence.com  Wed Jan 15 21:21:54 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Wed, 15 Jan 2020 22:21:54 +0100 (CET)
Subject: Text reflow woes (or: I want bullets back!)y
Message-ID: <1959862440.15925.1579123314431@ichabod.co-bxl>

> 2. Many markdown documents have 500+ column lines (one paragraph per
>    newline). If we require that Gemini source code is hard-wrapped, users
>    couldn't copy-paste markdown into their gemini blog/site without
>    hard-wrapping first.

Why would they need to hard wrap it? It would be the client or terminal that would be required to follow the spec and hard wrap it, not the content creators. I think every current client hard wraps at least to window size (if not some other value). This makes it so that a user can have a 500+ column row and the client/terminal/browser/etc will wrap it for them, leaving nothing for the user to do but paste it into their document for it to be wrapped automatically. I would image that most clients that allow the saving of pages would retain the original document structure free of any modifications made by the wrap (though I suppose mileage may vary in that regard).


This text reflow thread has been quite the minefield over time. Who would have thought that this would be the big thing to figure out when all this started?

From solderpunk at SDF.ORG  Wed Jan 15 22:11:17 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 15 Jan 2020 22:11:17 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
Message-ID: <20200115221117.GB21763@SDF.ORG>

On Wed, Jan 15, 2020 at 12:47:27PM -0800, Aaron Janse wrote:

> > Yes, I definitely intend to include a recommendation that text/gemini
> > content be hard wrapped
> 
> May I ask why?

Mostly because I want simple-as-possible clients to be viable, which
means simply printing non-link lines to stdout should result in
something usable.  Paragraphs of text formatted as a single line are
tremendously unpleasant to read when displayed this way!  If this were
the norm for text/gemini documents, I suspect nobody would use any
client that didn't include (tedious to write!) code to wrap these
lines at word breaks.

> In fact, I think *discouraging* hard-wrapping might actually make life easier
> for client implementers. Hard-wrapping would require clients to un-wrap the
> newlines then re-wrap to the desired width.

It wouldn't *require* that, the lines could simply be displayed at their
hard-wrapped width, which is why we're concerned with recommending a
narrow enough width that this would work on devices with narrow
displays.

Basically, consider what happens with the bare minimum amount of code in
either case:

A) If an entire paragraph is one line and a client doesn't have code to
break that big line up at word boundaries, leaving wrapping up to the
terminal results in multiple lines (potentially uncomfortably long for
reading) with randomly cut-up words at their beginnings and ends.

B) If the paragraph is hard-wrapped at ~40 characters and a client doesn't
have code to un-wrap and re-rewrap those lines, the result is lines of a
comfortabe length for reading, which fit on a smartphone and don't have any
randomly cut-up words at their beginnings and ends.

Given these two choices, surely B) is preferable?

Admittedly, this analysis is somewhat terminal-centric.  A lot of GUI
toolkits probably have text displaying widgets which will handle
breaking lines at word boundaries without the developer having to give
it a second though.

On the one hand, the vast majority of extant clients are
terminal-centric and I think the majority of the early adopters (being
gopher folk) lead terminal-centric lives, so a terminal-centric
perspective is only natural.  On the other hand, Gemini isn't supposed
to be only for a certain group of people, so I'm reluctant to lean on
this too much...

> Oh, well. I'm vocal about this because Gemini looks really exciting to me.
> As someone who plans to use it, I simply want it to be what I think is as
> easy to use as possible :-)

I appreciate you speaking up and I'm glad you're excited!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jan 15 22:12:57 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 15 Jan 2020 22:12:57 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <1959862440.15925.1579123314431@ichabod.co-bxl>
References: <1959862440.15925.1579123314431@ichabod.co-bxl>
Message-ID: <20200115221257.GC21763@SDF.ORG>

On Wed, Jan 15, 2020 at 10:21:54PM +0100, Brian Evans wrote:

> Who would have thought that this would be the big thing to figure out when all this started?

Let me assure you, I certainly didn't! :)

Cheers,
Solderpunk

From aaron at ajanse.me  Thu Jan 16 02:41:00 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Wed, 15 Jan 2020 18:41:00 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200115221117.GB21763@SDF.ORG>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
Message-ID: <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>

On Wed, Jan 15, 2020, at 2:11 PM, solderpunk wrote:
> B) If the paragraph is hard-wrapped at \~40 characters and a client doesn't
> have code to un-wrap and re-rewrap those lines, the result is lines of a
> comfortabe length for reading, which fit on a smartphone and don't have any
> randomly cut-up words at their beginnings and ends.
> 
> Given these two choices, surely B) is preferable?
> 

I think that one-line-per-paragraph would be much better for mobile phones.
I personally use a web browser proxy to read gemini pages when on mobile.
Text wrapped at 80 columns looks horrible. Text wrapped at 40 columns looks
okay, depending on my font size. But if text was one-line-per-paragraph,
firefox would wrap it wonderfully with *zero* effort from the proxy author.

> Admittedly, this analysis is somewhat terminal-centric.  A lot of GUI
> toolkits probably have text displaying widgets which will handle
> breaking lines at word boundaries without the developer having to give
> it a second though.

Yeah. And the variety of clients adds a lot of nuance to how text wrapping
degrades.

I can only imagine unlimited-column text catastrophically failing in two
places:

1. A very wide terminal
2. A very wide web browser

However, each has a simple solution:

1. Pipe text into the bash `fmt` command, which intelligently wraps text
2. Use *simple* css to make the viewport narrower, then let the browser
   do the wrapping

Thanks, solderpunk, for being a thoughtful BDFL!

Cheers!


From lazar.michael22 at gmail.com  Thu Jan 16 04:58:48 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Wed, 15 Jan 2020 23:58:48 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200115202137.GA21763@SDF.ORG>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
Message-ID: <CAFTy05aAydPa5xNZquEpc29+ddgPcxiY+xv7YFrVaHvgfdcGrw@mail.gmail.com>

On Wed, Jan 15, 2020 at 3:21 PM solderpunk <solderpunk at sdf.org> wrote:
>
> On Wed, Jan 15, 2020 at 12:03:28AM -0500, Michael Lazar wrote:
> > Here are some other alternatives that
> > might be worth considering. I do think
> > that displaying gemini links is a valid
> > use-case, but adding a whole new
> > preformatted text mode only for this
> > narrow case feels a bit heavy-handed to
> > me. Granted, I realize there are other
> > benefits to the preformatted mode that
> > have already been outlined.
>
> ...
>
> Ultimately I don't think I like either of these alternatives as much as
> the ``` syntax, but I'm happy to hear others' thoughts...
>
> Cheers,
> Solderpunk

Thanks for your response. After seeing
everything laid out in front of me, I
think I agree with you and I like your
proposal the best.

I wanted to visualize what this would
look like on mobile, so  I hacked up my
Gemini-HTTPS proxy to render the ```
markdown syntax. Here are some example
pages:

https://portal.mozz.us/gemini/mozz.us/files/aaatutorial.gmi?reflow=2
https://portal.mozz.us/gemini/mozz.us/files/flask_mega_tutorial_part_2.gmi?reflow=2

I think they look quite nice!

- mozz

From solderpunk at SDF.ORG  Thu Jan 16 15:10:01 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 16 Jan 2020 15:10:01 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
Message-ID: <20200116151001.GA24028@SDF.ORG>

On Wed, Jan 15, 2020 at 06:41:00PM -0800, Aaron Janse wrote:
 
> I think that one-line-per-paragraph would be much better for mobile phones.
> I personally use a web browser proxy to read gemini pages when on mobile.
> Text wrapped at 80 columns looks horrible. Text wrapped at 40 columns looks
> okay, depending on my font size. But if text was one-line-per-paragraph,
> firefox would wrap it wonderfully with *zero* effort from the proxy author.

I am kind of reluctant to make any Gemini design decisions based on the
assumption of a web browser as the user agent.  I understand that in
these very early days this is by far the quickest and easiest way to get
into Geminispace, and for smartphones it's probably the *only* viable
way.  But I hope that as time moves forward the proxies will become a
niche thing, serving as a "gateway drug" for real clients.  This is
surely a valuable role, but for regular use I think they should be
"considered harmful".  They represent single (or few) points of failure,
they involve trusting the proxy operator not to manipulate content
(Gemini isn't sophisticated enough to permit proper TLS proxying, so the
the web proxy is basically a MITM between client and server), proxy
operators have more opportunities to log and track their users than
individual Gemini servers do, and proxy users need to run vastly more
complex than necessary software (i.e. web browsers, although at least
Gemini proxies should typically be usable with nice alternative browsers
like dillo).

(aside: some of these issues go away with proxies designed to be run
locally by the user - a nice project for anybody itching for one!)

None of this is to say the web proxies or bad and that people shouldn't
run them or use them - I'm very gratefully to the people who have set
them up!  But I don't think of them as "first class" clients, and given
a choice between pushing implementation effort onto native client
authors or onto web proxy authors, I will make life easier for native
client authors every time.

Besides, getting a web proxy to provide beautiful wrapping if a
text/gemini file is hard-wrapped at 40 chars involves nothing more than
wrapping paragraphs in <p> and </p> tags.  That's a significantly easier
task than getting a terminal client to provide beautiful wrapping if a
text/gemini file has lines thousands of characters long, which requires
splitting the line into words, calculating and summing the lengths of
words, etc, etc.  Given the choice between making web proxy authors do
a little bit more work and makig native client authors to a moderate
amount of more work, I'm definitely going to choose the former.

> I can only imagine unlimited-column text catastrophically failing in two
> places:
> 
> 1. A very wide terminal
> 2. A very wide web browser

Neither of which are terribly uncommon, right, with full-screen windows
on desktops or even laptops?  My "daily driver" laptop terminal is 113
chars wide.  Although, even on a terminal < 80 chars wide, I kind of
consider words being split across lines as pretty severe failure.  I
don't want to read that - it's even less pleasant than hard-wrapped 80
char lines on a mobile.

> Thanks, solderpunk, for being a thoughtful BDFL!

I'm glad you think I'm thoughtful!  Sorry if I seem to be dismissing the
"long lines" approach out of hand, I promise you I'm giving it a lot of
thought.  I'm already stressing out that I'm being unduly influenced by
the fact that I use simple / old-fashioned editors and mostly write
stuff that should be hard-wrapped (plain text email, gopher content,
source code).  From my perspective, writing "long line" content is a
less pleasant experience for authors, because my editors don't work that
way out of the box.  But I realise that, actually, for the majority of
people that's far *more* accessible.  Someone using something resembling
Notepad is going to have a miserable time writing content hard-wrapped
at 40 chars, while the "long line" format just happens, probably without
them even realising it.

Then again, making text/gemini easy to write with "normal" editors
arguably isn't worth much if the next step is anyway "now use sftp or a
git push to get your content on the server".  Gemini is never going to
be able to support easy WYSIWIG authoring experiences akin to WordPress,
so perhaps it's pointless to consider the user experience for
non-technical types.

Argh!  Simplicity ain't simple.

Cheers,
Solderpunk

From aaron at ajanse.me  Thu Jan 16 17:40:50 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Thu, 16 Jan 2020 09:40:50 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200116151001.GA24028@SDF.ORG>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
Message-ID: <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>

On Thu, Jan 16, 2020, at 7:10 AM, solderpunk wrote:
> But I realise that, actually, for the majority of people that's far
> *more* accessible.  Someone using something resembling Notepad is going
> to have a miserable time writing content hard-wrapped at 40 chars, while
> the "long line" format just happens, probably without them even realising
> it.

I do admit that you've nearly convinced me that 40 chars is easiest for
readers, even though I'm not sure if it's best if we consider authors, too.

> Then again, making text/gemini easy to write with "normal" editors
> arguably isn't worth much if the next step is anyway "now use sftp or a
> git push to get your content on the server".

In my experience, though, hard-wrapping text doesn't work well with git
anyway. And I don't know of any text editors that re-hard-wrap automatically
when the beginning of a paragraph is edited.

Maybe gemini files could be authored in either wrapped or unwrapped format,
then the server could hard-wrap intelligently before sending it to the
reader? Would that be bad practice?

Cheers!

From sean at conman.org  Thu Jan 16 18:27:46 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 16 Jan 2020 13:27:46 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
References: <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
Message-ID: <20200116182746.GA11266@brevard.conman.org>

It was thus said that the Great Aaron Janse once stated:
> On Thu, Jan 16, 2020, at 7:10 AM, solderpunk wrote:
> > But I realise that, actually, for the majority of people that's far
> > *more* accessible.  Someone using something resembling Notepad is going
> > to have a miserable time writing content hard-wrapped at 40 chars, while
> > the "long line" format just happens, probably without them even realising
> > it.
> 
> I do admit that you've nearly convinced me that 40 chars is easiest for
> readers, even though I'm not sure if it's best if we consider authors, too.
> 
> > Then again, making text/gemini easy to write with "normal" editors
> > arguably isn't worth much if the next step is anyway "now use sftp or a
> > git push to get your content on the server".
> 
> In my experience, though, hard-wrapping text doesn't work well with git
> anyway. And I don't know of any text editors that re-hard-wrap automatically
> when the beginning of a paragraph is edited.
> 
> Maybe gemini files could be authored in either wrapped or unwrapped format,
> then the server could hard-wrap intelligently before sending it to the
> reader? Would that be bad practice?

  First question---how to tell the server the width?  Well, one solution:

	gemini://gemini.conman.org/test/wrap;80
	gemini://gemini.conman.org/test/wrap;40
	gemini://gemini.conman.org/test/wrap;32
	gemini://gemini.conman.org/test/wrap;132

  Just replace the number at the end with your preferred width.  If not
given:

	gemini://gemini.conman.org/test/wrap

it will currently default to 77.

  I just happen to have the code to handle reflowing text at arbitrary
widths, but the code to do so has to take into account a few edge cases that
might not be readily apparent (what if there is no breakpoint within the
mandated width?).

  -spc (Also note---I added that to my Gemini site last September)

From aaron at ajanse.me  Thu Jan 16 19:48:09 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Thu, 16 Jan 2020 11:48:09 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200116182746.GA11266@brevard.conman.org>
References: <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <20200116182746.GA11266@brevard.conman.org>
Message-ID: <4e1d76cb-eff5-4ecb-9470-dbc22860d89f@www.fastmail.com>

On Thu, Jan 16, 2020, at 10:27 AM, Sean Conner wrote:
>   First question---how to tell the server the width?  Well, one solution:

On one hand, I like the idea of the server doing the wrapping.

It would allow viewport-specific fixed text. For example, two things
that server-side wrapping would allow that are currently used in the
Gemini speculative spec:

- viewport-width-specific dividers (a bunch of dashes)
- indented paragraphs or trailing-indent bullet points

On the other hand, server-side wrapping has the following drawbacks:

- broadcasting viewport width goes against Gemini privacy values
- clients can no longer download a gemini blog then view it at
  different widths
- this could open up room to server-side trickery, such as indenting
  fixed-width content, which I don't think is a good idea

Also, speaking of privacy, does Gemini work over Tor?

From lel at envs.net  Thu Jan 16 20:26:40 2020
From: lel at envs.net (lel)
Date: Thu, 16 Jan 2020 15:26:40 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <4e1d76cb-eff5-4ecb-9470-dbc22860d89f@www.fastmail.com>
References: <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <20200116182746.GA11266@brevard.conman.org>
 <4e1d76cb-eff5-4ecb-9470-dbc22860d89f@www.fastmail.com>
Message-ID: <20200116202640.GA25554@briz>

On Thu, Jan 16, 2020 at 11:48:09AM -0800, Aaron Janse wrote:
> On Thu, Jan 16, 2020, at 10:27 AM, Sean Conner wrote:
> >   First question---how to tell the server the width?  Well, one solution:
> 
> On one hand, I like the idea of the server doing the wrapping.
> 
> It would allow viewport-specific fixed text. For example, two things
> that server-side wrapping would allow that are currently used in the
> Gemini speculative spec:
> 
> - viewport-width-specific dividers (a bunch of dashes)
> - indented paragraphs or trailing-indent bullet points
> 
> On the other hand, server-side wrapping has the following drawbacks:
> 
> - broadcasting viewport width goes against Gemini privacy values
> - clients can no longer download a gemini blog then view it at
>   different widths
> - this could open up room to server-side trickery, such as indenting
>   fixed-width content, which I don't think is a good idea
> 
> Also, speaking of privacy, does Gemini work over Tor?

Yeah, I don't think this does it because not only does it complicate server
implementation, but it does so in a way that seeks to allow servers to learn
about clients.

That being said, as far as I'm concerned, literally anything at
all is preferable to hard-wrapping at 40 characters -- less than a quarter of
my *laptop* screen with a mid-size font; I can only imagine how it looks on an
actual monitor. Limiting lines to 5-6 words would seem to limit, on a
fundamental level, the types of content that can even be served over gemini.

Adding an arbitrary cap to line lengths purely so that a hypothetical
mobile client doesn't require 10-20 lines of wrapping code (code that
Google suggests already exists in the Android SDK and merely has to be
invoked) seems absurd to me, particularly when the wrapping itself is
trivial, and this is entirely because word-wrapping is considered
preferable to naive, occasionally-mid-word wrapping.

The argument I'm reading is that nobody would use a client that
occasionally wraps in the middle of words, and the gemini spec is
explicitly geared toward making client implementations as simple as
possible. 

I understand this, yet I think there exists a world of
difference between "it should be trivial to write a client"
and "it should be trivial to write a client that formats
every line beautifully and that we would all love using,"
particularly when the point of difference between the two is
whether or not some words are line-broken some of the time.

This is just my two cents, but I feel like that's
something that it makes more sense to leave up to
the client. The actual client-side process of
interacting with the server is still simple, but
printing it can be done in a simple way (wrap,
occasionally breaking words) or with a few lines
and a couple conditions to guard edge-cases (to
word-wrap).

I don't know, I understand that some arguments
in favor of a 40 character hard-wrap have been
made from a reading level, and I understand
them, but I don't think that justifies
hard-capping all lines at only a few words. If
you want to be able to speed-read lines, you
could write a client that word-wraps at 40
characters very, very easily. You could write a
client that flashes words at you one at a time
quickly like those speed-reading programs if you
want to take that idea to an extreme. But I feel
like this is a very drastic response to a
non-issue. Maybe I wouldn't feel so bad about it
if the limit being suggested weren't as puny as
40 characters. But no matter what the limit is,
there are still screens, or fonts, or what have
you, where any hard-wrapping solution does not
solve the problem. And if aesthetics are the
main concern, and we can't stomach a few split
words, then I really don't get why the best
solution is to squash every single gemini site
into the left 25% of our screens.

I'm sure whatever flagship gemini client
eventually emerges on top is going to be
beautiful and not wrap in the middle of
words, but I also don't think that the
spec should be specced based upon the
hypothetical flagship client -- client
implementation can be simple, and it
will no doubt remain so for gemini;
but flagship client implementation is
not, cannot, and will never be, for any
protocol.

I'm not trying to be insulting to
anyone, and I get that y'all will
likely disagree. I fully understand the
reasons behind what everyone in favor
of the 40 char limit is suggesting, but
I think that practically speaking, it's
not liveable for anyone trying to use
gemini, and it causes more problems
than it solves.

idk
~ lel

From solderpunk at SDF.ORG  Thu Jan 16 20:26:52 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 16 Jan 2020 20:26:52 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
References: <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
Message-ID: <20200116202652.GA23953@SDF.ORG>

On Thu, Jan 16, 2020 at 09:40:50AM -0800, Aaron Janse wrote:

> In my experience, though, hard-wrapping text doesn't work well with git
> anyway. And I don't know of any text editors that re-hard-wrap automatically
> when the beginning of a paragraph is edited.

Hmm.  Neither do I and, in fact, well...I just do it manually.  Which I
feel very sheepish admitting because that's kind of ridiculous.  But
everybody writing for Gopherspace (which is many people here) must face
precisely this problem, because hard-wrapping is basically compulsory
there.  What are other people doing, writing in "long line" form and
then feeding the result to `fmt` or `par` before uploading?

Cheers,
Solderpunk

From lazar.michael22 at gmail.com  Thu Jan 16 20:38:23 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 16 Jan 2020 15:38:23 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
Message-ID: <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>

On Thu, Jan 16, 2020 at 12:41 PM Aaron Janse <aaron at ajanse.me> wrote:
>
> On Thu, Jan 16, 2020, at 7:10 AM, solderpunk wrote:
> > Then again, making text/gemini easy to write with "normal" editors
> > arguably isn't worth much if the next step is anyway "now use sftp or a
> > git push to get your content on the server".
>
> In my experience, though, hard-wrapping text doesn't work well with git
> anyway. And I don't know of any text editors that re-hard-wrap automatically
> when the beginning of a paragraph is edited.
>
> Maybe gemini files could be authored in either wrapped or unwrapped format,
> then the server could hard-wrap intelligently before sending it to the
> reader? Would that be bad practice?
>
> Cheers!

I see no reason we can't let each server decide this on a case-by-case basis,
based on the needs of their users.

If you're hosting shared gemini content for a group of non-technical users, it
might make sense for your server to automatically reformat gemini files before
sending them. On the other hand, if you're running a home-grown gemini server
and writing all of your own content, this step might be unnecessary or invasive
to your preferred workflow.

If we're adopting the proposed format with ``` for preformatted blocks, the
rules can be totally ambiguous for server-side line wrapping.

  1. preformatted blocks are not touched by the server
  2. links are not touched by the server
  3. everything else can be wrapped by the server to the preferred width

Content authors should not expect their non preformatted text to have line
lengths / indents / etc. preserved.

- mozz

From aaron at ajanse.me  Thu Jan 16 20:50:45 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Thu, 16 Jan 2020 12:50:45 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
Message-ID: <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>

On Thu, Jan 16, 2020, at 12:26 PM, solderpunk wrote:
> But everybody writing for Gopherspace (which is many people here) must
> face precisely this problem, because hard-wrapping is basically compulsory
> there.

And my understanding is that while Gemini isn't supposed to be a Gopher 2.0,
it's supposed to make it better than Gopher. I think that non-hard-wrapping
could be a big step towards this goal.

lel said:
> Adding an arbitrary cap to line lengths purely so that a hypothetical
> mobile client doesn't require 10-20 lines of wrapping code (code that
> Google suggests already exists in the Android SDK and merely has to be
> invoked) seems absurd to me, particularly when the wrapping itself is
> trivial, and this is entirely because word-wrapping is considered
> preferable to naive, occasionally-mid-word wrapping.

Honestly, even if it takes 40 lines of code, I'd rather write that then
manually wrap every single gemini document I ever write. 

> What are other people doing, writing in "long line" form and
> then feeding the result to `fmt` or `par` before uploading?

For things such as email, after manually wrapping quotes, I think using
`fmt` or `par` is the most efficient way to wrap text. However, this only
works for text that's written once, such as emails. This doesn't work for
continually edited content such as websites.

> If you're hosting shared gemini content for a group of non-technical users,
> it might make sense for your server to automatically reformat gemini files
> before sending them

I don't have a problem with people "rendering" into Gemini. I just think that
the spec shouldn't make it necessary. Rendering/compiling into Gemini adds
a level of indirection that hides the transparency that makes me love the
protocol.

Cheers!

From solderpunk at SDF.ORG  Thu Jan 16 20:54:38 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 16 Jan 2020 20:54:38 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05aAydPa5xNZquEpc29+ddgPcxiY+xv7YFrVaHvgfdcGrw@mail.gmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <CAFTy05aAydPa5xNZquEpc29+ddgPcxiY+xv7YFrVaHvgfdcGrw@mail.gmail.com>
Message-ID: <20200116205438.GB23953@SDF.ORG>

On Wed, Jan 15, 2020 at 11:58:48PM -0500, Michael Lazar wrote:
 
> I wanted to visualize what this would
> look like on mobile, so  I hacked up my
> Gemini-HTTPS proxy to render the ```
> markdown syntax. Here are some example
> pages:
> 
> https://portal.mozz.us/gemini/mozz.us/files/aaatutorial.gmi?reflow=2
> https://portal.mozz.us/gemini/mozz.us/files/flask_mega_tutorial_part_2.gmi?reflow=2
> 
> I think they look quite nice!

These look great!  And I don't just mean aesthetically, they are an
excellent example of the practical usefulness of being able to embed
prefromatted text in otherwise "normal" prose.

Cheers,
Solderpunk

From aaron at ajanse.me  Thu Jan 16 21:09:18 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Thu, 16 Jan 2020 13:09:18 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
Message-ID: <546c2284-4b16-4ec1-8a9f-a072e0773799@www.fastmail.com>

Oops, I meant to mention two things:
1. Clients are already using TLS. I think wrapping is significantly
   easier than encryption.
2. Lists are tough to handle when re-flowing text.

Thanks again for the thoughtfulness, solderpunk!

From lazar.michael22 at gmail.com  Thu Jan 16 22:00:59 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 16 Jan 2020 17:00:59 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 <f8432dc5-17cf-4b0c-b687-d71607d60ed0@www.fastmail.com>
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
Message-ID: <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>

On Thu, Jan 16, 2020 at 3:51 PM Aaron Janse <aaron at ajanse.me> wrote:
> On Thu, Jan 16, 2020, at 12:26 PM, solderpunk wrote:
> > If you're hosting shared gemini content for a group of non-technical users,
> > it might make sense for your server to automatically reformat gemini files
> > before sending them
>
> I don't have a problem with people "rendering" into Gemini. I just think that
> the spec shouldn't make it necessary. Rendering/compiling into Gemini adds
> a level of indirection that hides the transparency that makes me love the
> protocol.
>
> Cheers!

To be clear, I agree with you that a max line length shouldn't be enforced by
the spec. I support the current wording of SHOULD as opposed to MUST. I'm more
talking about establishing a recommended best practice. Gemini files with lines
over N characters long should still be considered "valid" and must be accepted
by any gemini client. They might just look a little funky depending on how
sophisticated your client is.

My belief is that if we don't establish a guidance on the line length, the
community will informally gravitate towards one anyway. And that will almost
certainly be 70-80 characters because that's what most people in this community
are used to. Servers that return 500+ characters on a single line will look
bad on many of the gemini clients that people write, and content authors will
be pressured into conforming to maintain readability for those clients.

The spec-spec as written right now says that all gemini lines should be
formatted so that they can reflowed by clients if the client chooses to do so.
That spec has been almost unanimously rejected by current gemini servers, in
favor of hard wrapping at 70-80 characters.

- mozz

From solderpunk at SDF.ORG  Thu Jan 16 22:12:02 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 16 Jan 2020 22:12:02 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <546c2284-4b16-4ec1-8a9f-a072e0773799@www.fastmail.com>
References: <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <546c2284-4b16-4ec1-8a9f-a072e0773799@www.fastmail.com>
Message-ID: <20200116221202.GC23953@SDF.ORG>

On Thu, Jan 16, 2020 at 01:09:18PM -0800, Aaron Janse wrote:
> Oops, I meant to mention two things:
> 1. Clients are already using TLS. I think wrapping is significantly
>    easier than encryption.

I was about to quip that the TLS is made really easy by high-level
library support while the wrapping has to be done manually, but then I
thought to check and, holy heck, Python has a `textwrap` module I wasn't
aware of.

> 2. Lists are tough to handle when re-flowing text.

One of the most appealing things to me about the "long lines" approach
is that it actually makes lists with multi-line items feasible without
having to define any special syntax for them.  I might elaborate on this
later...

Cheers,
Solderpunk

From sean at conman.org  Thu Jan 16 22:15:29 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 16 Jan 2020 17:15:29 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200116202652.GA23953@SDF.ORG>
References: <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <20200116202652.GA23953@SDF.ORG>
Message-ID: <20200116221529.GA3354@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Thu, Jan 16, 2020 at 09:40:50AM -0800, Aaron Janse wrote:
> 
> > In my experience, though, hard-wrapping text doesn't work well with git
> > anyway. And I don't know of any text editors that re-hard-wrap automatically
> > when the beginning of a paragraph is edited.
> 
> Hmm.  Neither do I and, in fact, well...I just do it manually.  Which I
> feel very sheepish admitting because that's kind of ridiculous.  But
> everybody writing for Gopherspace (which is many people here) must face
> precisely this problem, because hard-wrapping is basically compulsory
> there.  What are other people doing, writing in "long line" form and
> then feeding the result to `fmt` or `par` before uploading?

  Setting aside my phlog [1], the rest of the content on my gopher and
Gemini servers is written with 80 columns in mind.  The editor I use will
wrap at a default setting of 77 (but can be changed on the fly).  The last
computer I used with a width of less than 80 characters was my TRS-80 Color
Computer which had a width of 32 characters (and I last used regularly in
1987).  Since then, all the computers I've had supported at least 80
characters [2].

  For my phlog, it's a rendering of my web-based blog [3] where I use Lynx
to do the conversion from HTML to plain text (with a bit of post-processing
to fix intra-blog links).

  How do I write my blog entries?  I use my regular editor and I've adopted
a style a few years ago where I write ... not exactly a sentance per line,
but a thought per line.  Okay, an example from a previous post [4]:

[=== example ===]
<p>Okay,
to be fair,
I did find references and draft material covering the problem of pirates,
but I found his stance on a 12 gauge shotgun to be ?more accurate? than a hand gun to be questionable at best.
?Accuracy? on a rolling, pitching boat in the open water is going to be questionable,
regardless of choice of firearm.</p>

<p>There is correspondence with yatch manufactuers,
blue prints,
price breakdowns
(nearly $300,000 in 1982 dollars,
making it nearly $800,000 in today's dollars?ouch!)
and scores of articles on everything related to sailing.
It also appears that Dad was trying to invent a new type of sail,
as there were drawings he did and correspondence with an engineering firm.
I'm not sure what I'll do with it all,
but the blueprints are cool.</p>
[=== end ===]

  Web browsers don't care about the raw formatting---they reflow it, with
styling coming from HTML and CSS.  And the reason I keep it very ragged like
that is to make it easier to move sentances and fragments about when editing
the entry.  I also run the entry through a processing script to convert some
shortcuts, like turning `` into ? or "1^st" into "1<sup>ST</sup>" [4] or
even pulling out image sizes for the <IMG> tag.

  This is probably more than you wanted to know 8-)

  -spc

[1]	gopher://gopher.conman.org/1phlog.gopher

[2]	Okay, yes!  I have an iPhone.  I don't use it to browse gopherspace
	though.

[3]	http://boston.conman.org/

[4]	Yes, I have a type of markup I use, but it's totally custom to me
	and how I write entries, but it does quite a bit.  Here's a sample
	that includes all the features (I think I keep this up to date):

		https://github.com/spc476/mod_blog/blob/master/NOTES/testmsg

	And the script I use:

		https://github.com/spc476/mod_blog/blob/master/Lua/format.lua

From sean at conman.org  Thu Jan 16 22:19:23 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 16 Jan 2020 17:19:23 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200116221529.GA3354@brevard.conman.org>
References: <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <20200116202652.GA23953@SDF.ORG> <20200116221529.GA3354@brevard.conman.org>
Message-ID: <20200116221922.GB3354@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
>   How do I write my blog entries?  I use my regular editor and I've adopted
> a style a few years ago where I write ... not exactly a sentance per line,
> but a thought per line.  Okay, an example from a previous post [4]:

  This footnote [4] should have pointed to here:

		http://boston.conma.norg/2020/01/13.1

>   Web browsers don't care about the raw formatting---they reflow it, with
> styling coming from HTML and CSS.  And the reason I keep it very ragged like
> that is to make it easier to move sentances and fragments about when editing
> the entry.  I also run the entry through a processing script to convert some
> shortcuts, like turning `` into ? or "1^st" into "1<sup>ST</sup>" [4] or
> even pulling out image sizes for the <IMG> tag.

  And this footnote [4] should have been footnote [5].  I got distracted
when writing the email.

  -spc

> [5]	Yes, I have a type of markup I use, but it's totally custom to me
> 	and how I write entries, but it does quite a bit.  Here's a sample
> 	that includes all the features (I think I keep this up to date):
> 
> 		https://github.com/spc476/mod_blog/blob/master/NOTES/testmsg
> 
> 	And the script I use:
> 
> 		https://github.com/spc476/mod_blog/blob/master/Lua/format.lua

From solderpunk at SDF.ORG  Thu Jan 16 22:24:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 16 Jan 2020 22:24:58 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
References: <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
Message-ID: <20200116222458.GD23953@SDF.ORG>

On Thu, Jan 16, 2020 at 05:00:59PM -0500, Michael Lazar wrote:
 
> To be clear, I agree with you that a max line length shouldn't be enforced by
> the spec. I support the current wording of SHOULD as opposed to MUST. I'm more
> talking about establishing a recommended best practice. Gemini files with lines
> over N characters long should still be considered "valid" and must be accepted
> by any gemini client. They might just look a little funky depending on how
> sophisticated your client is.

Oh, absolutely.  All this discussion about hard wrapping at 40 chars is
firmly in the real of best practice recommendation.

> The spec-spec as written right now says that all gemini lines should be
> formatted so that they can reflowed by clients if the client chooses to do so.
> That spec has been almost unanimously rejected by current gemini servers, in
> favor of hard wrapping at 70-80 characters.

The current spec-spec says that clients can reflow long lines if they
want to, but it doesn't place any obligation on authors or servers to
actually provide long lines.

Cheers,
Solderpunk

From aaron at ajanse.me  Thu Jan 16 23:26:13 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Thu, 16 Jan 2020 15:26:13 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200116222458.GD23953@SDF.ORG>
References: <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
Message-ID: <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>

On Thu, Jan 16, 2020, at 2:24 PM, solderpunk wrote:
> The current spec-spec says that clients can reflow long lines if they
> want to, but it doesn't place any obligation on authors or servers to
> actually provide long lines.

Hmm, even allowing reflowing sounds like it could cause incompatibility
issues. Should there be standardized markup for bullet points? What about
poems, something I think are much easier to find on Gopher than on the
HTML web? How about markdown title lines immediately followed by text?

I think that wrapping then reflowing fundamentally leads to loss of
original information. I'll provide below a few things that I'm not sure
how to reflow. Note that, except for the haiku, many of the lines could
go past the viewport width, making fixed text mode not an option (
especially for lists).


This is a haiku
Should it be reflowed or not?
I don't think it should.

 - this is a bullet point
- so is this
* and this 
 * and this
   * and this
-> and this
1. and this
   I. and this
   II. and this
~ and this
+ and using plus signs is even valid markdown

*R*emember
*A*crostic
*P*oems

One
word
per
line
for
emphasis

# Title
Start of paragraph immediately after
## Subtitle without spacing above
> Quote for this sub-section


While providing the option of hard-wrapped text would appeal to retro
users, it could come at the cost of a much more complex spec for how
to reflow along with incompatibilities as clients act differently
when confronted with un-specified situations.

Cheers

From solderpunk at SDF.ORG  Fri Jan 17 11:11:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 17 Jan 2020 11:11:58 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
References: <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
Message-ID: <20200117111158.GA10236@SDF.ORG>

On Thu, Jan 16, 2020 at 03:26:13PM -0800, Aaron Janse wrote:
> 
> Hmm, even allowing reflowing sounds like it could cause incompatibility
> issues. Should there be standardized markup for bullet points? What about
> poems, something I think are much easier to find on Gopher than on the
> HTML web? How about markdown title lines immediately followed by text?

Well, a lot of this is exactly what the recently proposed ``` was
supposed to help fix.  Things precisely like the haiku example you
provided would be enclosed within ``` lines so that they didn't get
mangled by a reflowing client.

A speedy recap of the history of text/gemini, excluding the link syntax
debate which is thankfully past us:

* Originally, the spec-spec said nothing about wrapping or flowing or
  anything of the sort.  Everybody was producing hard-wrapped content
  and/or writing clients which expected hard-wrapped content (probably
  running on auto-pilot from Gopher experiece), so that was in some
  sense the implicit standard.
* Several people wrote to me and said Gopher's hard line wrapping was
  one of their least favourite parts of Gopher because the days where
  everybody was at an 80 char terminal are over and Gopher content often
  looks mangled on their smartphones.
* This seemed reasonable and easy to fix, so in what was now clearly a
  mistake I updated the spec-spec to its current version, permitting
  clients to reflow if they want to, because, hey, what's the worst that
  could happen?
* Very shortly after the first client implementation efforts happened it
  became clear that this was a disaster, precisely because it breaks
  bulleted lists (hence the subject of this thread), but also other
  content like ASCII art, poems, source code, etc.
* Everybody agreed there had to be some way to preserve these things, so
  the hunt was on for a slightly extended syntax to allow clearly
  signalling to reflowing clients "thou shalt not reflow/wrap/mangle
  these particular lines" (even at this point, there were voices which
  said this was all getting to hard and we should forget about
  reflowing).
* After a false start involving the idea of leading and/or trailing
  whitespace signalling that text should not be reflowed (which I now
  think is a bad idea for several reasons and don't want us to consider
  again), the ``` line idea seems to have provoked no serious objections.
  I thought there was light at the end of the tunnel..

But as your email makes clear, the ``` syntax is not a panacea.  It will
allow haikus, one-word-per-line text, source and other things, so it's
an improvement over the current spec-spec.  However, it still doesn't
really work, or works in a very inconvenient and ugly way, for many
other things like lists, Markdown headings, etc.

I don't hate bulleted lists, or Markdown headings.  On the contrary, I
like them and use them a lot and it would be lovely if Gemini documents
could include them.

But I really, really don't want:

1. To distract everybody's time and energy for the Gemini project for
   even more months than we already have hammering this stuff out when
   we could be discussing way more interesting and important stuff, or
   writing software, or best of all writing content so this thing takes
   off.

2. To end up with a final spec where the section that explains precisely
   how to render a text/gemini document involves more words than the
   sections which explain the actual protocol itself.  text/gemini is
   supposed to be a lightweight format!

3. To end up with a text/gemini specification which is basically exactly
   the same as Markdown except with a different link syntax.  That's
   just using a lot of time to basically reinvent a wheel, and it's an
   especially poor use of time when Gemini is already capable of just
   serving actual Markdown with a MIME type to indicate that it's doing
   that!  And it sucks for authors of non-graphical clients, because how
   to properly render Markdown isn't actually defined beyond how to
   properly transform it to HTML, and how to render HTML in a terminal
   is not defined at all and there are few libraries for it.  It would
   be an epic fail if simple terminal Gemini clients had to hand content
   over to lynx as a external formatting tool.

4. To compromise on the idea that writing a basic but usable client
   should be really quick and easy.  I don't mind if text/gemini has
   some voluntary extra complexity.  I really like the two digit status
   code solution we chose for the response header - extra
   information/power is there for when it is needed, but simple clients
   can ignore it and still function correctly.  This has to be true for
   handling text/gemini too.  Whatever extra complexity we add has to
   degrade gracefully when ignored.  I get that really comfy,
   full-featured "flagship" clients are inevitably going to be more
   complicated, and that's fine.  But I don't want to repeat the
   mistake of the web where flagship clients are basically compulsory,
   and if you try to take something nice and simple like Dillo outside
   of a very, very small subset of the web (maintained by people like
   us) you end up with a badly broken user experience.  Something that
   a single person can bang out on the same weekend they read the spec
   for the first time should be able to render the majority of
   Geminispace into something that's comfortable to read.  Not
   necessarily perfect, but something that you might voluntarily use to
   read content for half an hour.

I just don't see how to simultaneously avoid all these things *and* end
up with a text/gemini that nicely supports headings and lists and
quotations which are robust against reflowing/wrapping.  I honestly
think it's impossible to simultaneously satisfy all three of:

1. Easy to describe and to parse
2. Capable of "richness" like headings, lists, quotes, etc.
3. Looks good on arbitrary screen widths

Basically, you have to pick two.  If you really want 2. and 3. you have
no choice but define a whole set of special syntax like in HTML or
Markdown (which is really just a more syntactically lightweight form of
a subset of HTML), and that kills 1.  Specifying a fixed character width
for hard-wrapped lines gives you 1. and 2. (this is exactly how Gopher
works, where people use all that richness all the time without even
thinking about it), but breaks 3 because the fixed character width is
always going to be too long or too short for some device.  And finally,
the current spec-spec delivers 1. and 3.  It's not hard to reflow just
plain paragraphs of text to arbitrary widths, the breakage only occurs
when the text contains richness like headers, lists, quotes, etc.  By
adding ``` to the spec-spec we can allow a tiny bit of richness in
(poems, source code, ASCII art), but it's not enough to give us anything
like a web-like or even gopher-like textual experience.

Compromising on 1. means compromising on the entire point of Gemini, so
that's not happening.

We need to either compromise on 2. by giving up on the idea that
text/gemini documents can reliably support headings, lists, etc. (and
this will be a bit of a blow for the idea of boostrapping Geminispace by
mirroring existing Gopher content, because a lot of that Gopher content
is going to include exactly those things in Markdownesque format without
any Gemini-specific ``` lines it, and so will be mangled by reflowing
Gemini clients) or we need to compromise on 3. by defining a fixed
character width (with doesn't necessarily have to be 40) and accepting
that Gemini just won't look great on tiny screens.

Right now I'm inclined to sacrifice 3. more than I am 2.  Not working
nicely on smartphones will be a shame and probably upset a lot of
people, but *something* has to give and it seems sensible for that to be
devices which, at the end of the day, are obviously not well suited to
displaying non-trivial quantities of text anyway.  There's a reason that
newspapers, magazines, books, e-readers and even folded brochures are
all wider than phones!  And it would just be embarrassing for Gemini
documents to need to be structurally simpler than Gopher documents (by
never using lists, etc.).

> While providing the option of hard-wrapped text would appeal to retro
> users, it could come at the cost of a much more complex spec for how
> to reflow along with incompatibilities as clients act differently
> when confronted with un-specified situations.

At this point, hard-wrapping text for me has a lot of appeal which has
*nothing* to do with being retro and is actually about *avoiding* a more
complex spec.  If text/gemini is hard-wrapped and clients are forbidden
from ever reflowing, then people can basically use Markdown syntax (or
any other syntax they like!) to produce rich text content without the
client needing to actually understand any of that syntax, and hence
without the spec needing to describe any of it.  It gives you maximum
expressive power for minimum spec or implemetation complexity, which is
very Gemini.

Before you started posting to this list I would have added "and the
*only* downside is that it ruins things on narrow phone screens" and
then smugly dismissed phones as junk and been happy.  But you have
covinced me (and I thank you for it!) that this approach has real
downsides too, in that it doesn't play as nicely with version control
software and is, averaging across the space of all possible editors,
actually more difficult for authors to write and to edit than the form
where paragraphs are just very long single lines.  So, now I recognise
this as a compromise solution and I'm not hugely enthusiastic about it.
But I really do think that the solution *has* to be a compromise, and
that this might be the best possible compromise, all things considered.

If anybody really wants to change my mind on this, your time is probably
best spent trying to come up with a text/gemini syntax which allows rich
text features, degrades gracefully in very simple clients, can be
rendered in no more than 100 LOC of Python (and less is better!) and can
be succinctly but unambigiously described in the spec.  I consider the
existence of such a syntax unlikely but not impossible.  I'll try to
come up with one myself, but unless one materialises that nobody really
hates and that can be shown to work well via actual running code by the
end of January, I will declare text/gemini hard-wrapped and we can all
move on to arguing about the One True Width to wrap at instead. :)

Cheers,
Solderpunk

PS: I'll probably refrain from posting about *this* particular issue on
the list over the weekend, otherwise I'll never get anything else done!

From solderpunk at SDF.ORG  Fri Jan 17 13:33:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 17 Jan 2020 13:33:12 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117111158.GA10236@SDF.ORG>
References: <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG>
Message-ID: <20200117133312.GA7402@SDF.ORG>

Hmm, I've just realised something which might salvage this whole mess.
It's possible even that what I'm about to describe is exactly what the
"long line" folks have been talking about all along without my
realising it.  Sorry for missing it if so, but I don't think it was
ever made explicit!

I have always conceptualised our choice as being between two
alternatives:

1. Hard-wrapped text which clients display verbatim, line-by-line,
   exactly the way Gopher works.

2. What I'll call "full blown reflowing", the way HTML and LaTeX work.
   This involves lines longer than the viewport being split up into
   multiple shorter lines, but also consecutive non-blank lines
   shorter than the viewport being joined into fewer, longer lines.
   Basically, this model of reflow is "paragraph based".  Consecutive
   non-empty lines of text form clumps called paragraphs which are
   formatted as a whole, whether this results in more or fewer total
   lines compared to the "source".

There is another option that I hadn't thought about until now, which
is to do only the first half of 2. above.  That is, lines longer than
the viewport get broken up nicely at word boundaries into lines of
length equal to or less than the viewport width - but that's it.
Consecutive shorter lines are *not* joined together.  Blank lines in
the "source" are rendered, one by one, into empty vertical space.
The renderer has no explicit concept of a paragraph.

This allows writing things we want to look like paragraphs as
individual long lines (easy for most editors, plays nicely with
version control) with the knowledge they'll be nicely wrapped to the
viewport width, but it doesn't break things like
one
word
per
line
for
emphasis, because the lines won't be sucked up and joined together, and
it also doesn't break lists for the same reason (more on lists below).

I kind of like this.  Unlike the paragraph-oriented web/LaTeX model
where ten consecutive newlines and two consecutive newlines are
identical, this also allows us to put larger gaps between paragraphs
to give the impression of pausing for thought.





Neat, huh?

This does rescue lists, right?  A list of short items:

* Mercury
* Gemini
* Apollo
* Shuttle

does't get turned into a mess of:

* Mercury * Gemini * Apollo Shuttle

But multi-line list items get wrapped appropriately.  Dumb clients
which don't recognise list items at all can do this in an ugly way, by
applying exactly the same wrapping code they use for normal lines:

* This is a multi-line list item where the beginning of lines after
the first one are not offset from the left hand of the viewport to
match the offset of the first one.

Whereas smarter clients can recognise lines beginning with "*" as
being list items and do slightly nicer formatting:

* This is a multi-line list item which has been handled by a smarter
  client which results in a nicer appearance - a strictly optional bit
  of extra work for ambitious client authors.

There doesn't seem to be any need to keep track of whether or not you
are inside of a list or not?

This syntax is strictly line-based, and recognising a special type of
line involves only looking at the first few characters.  Recognising
Gemini links is of course mandatory, but so long as every other
special kind of line can be handled appropriately by just printing it
(in the way that list items seemingly can be) then defining special
line types for headings, etc. doesn't actually add any extra burden on
simple clients.  It's basically a question of how many cases you want
to handle in a switch statement...

This seems pretty great, the only downside is that even bare minimal
clients need to be able to wrap long lines to result in readability.
I'm not quite as bothered by this as I was before I realised that
Python has a standard library function which just does this (it's
even pretty smart, e.g. if the final word of a line would make that
line longer than the requested width, and the word has a hyphen in
it, it'll break at the hyphen if that shortens the lin enough), but
it's still not great.  I wonder how common that kind of function is
across standard libraries?

Surely it can't be this simple.  I look forward to somebody pointing
out the inevitable overlooked fatal flaw...

Cheers,
Solderpunk

From lel at envs.net  Fri Jan 17 13:58:04 2020
From: lel at envs.net (lel)
Date: Fri, 17 Jan 2020 08:58:04 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117133312.GA7402@SDF.ORG>
References: <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
Message-ID: <20200117135804.GA5259@briz>

On Fri, Jan 17, 2020 at 01:33:12PM +0000, solderpunk wrote:
> It's possible even that what I'm about to describe is exactly what the
> "long line" folks have been talking about all along without my
> realising it.
> ...
> There is another option that I hadn't thought about until now, which
> is to do only the first half of 2. above.  That is, lines longer than
> the viewport get broken up nicely at word boundaries into lines of
> length equal to or less than the viewport width - but that's it.
> Consecutive shorter lines are *not* joined together.  Blank lines in
> the "source" are rendered, one by one, into empty vertical space.
> The renderer has no explicit concept of a paragraph.

Yes, this is exactly what I was trying to say. There's no need to join
subsequent lines together. That's just reflowing, as far as I can tell.
But you don't need to reflow in that specific way unless your content
is inconveniently hard-wrapped when you want it to be resizable. This
sort of reflowing leads to loss of information if the single
line-breaks were intended and meaningful, so it makes more sense to me
to not add those line-breaks into the content, but into their rendering
on the client-side.

This is the happiest I've been to see an email in a while honestly lol

~ lel

From solderpunk at SDF.ORG  Fri Jan 17 14:27:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 17 Jan 2020 14:27:15 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117135804.GA5259@briz>
References: <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz>
Message-ID: <20200117142715.GA23881@SDF.ORG>

On Fri, Jan 17, 2020 at 08:58:04AM -0500, lel wrote:
> 
> Yes, this is exactly what I was trying to say.

Ah, right, sorry for not getting that.  I think this whole conversation,
despite Sean's best efforts to give us formally defined terms, is
suffering a lot from the fact that things like "reflowing" mean
different things to different people or in different contexts, so we're
often talking past each other.

We'd still need ``` in this system, right, to avoid e.g. long lines of
source getting mangled on very narrow phone screens?  So minimal
rendering pseudocode looks like this:

preformatted = False
for line in all_the_lines:
    if line == "```":
        preformatted = not preformatted
    elif preformatted:
        print(line)
    elif line.startwith("=>"):
        handle_link(line)
    else:
        wrap_line_to_viewport(line)

Where wrap_line_to_viewport may need to be written by the user if there
isn't a library function (and should print empty lines if given them).

Non-minimal rendering just involves replacing that final "else" clause
with more "elifs" to catch e.g. list items or headers (dispatching to
different functions, like wrap_bold_line_to_viewport to display headings
in bold).  You can add as many or as few of those extra clauses as you
like to pretty things up, as long as whatever prettiness you want
doesn't depend upon anything.

If this rendering code *is* fed text/gemini that has been hard wrapped
to a width less than or equal to the viewport, that text comes back
unmangled (but narrower than it otherwise could be). 

Are there really no catches beyond this?  I'm sure there must be, but if
not I guess the next thing to do is to start thinking about how
difficult a "good enough" (not necessarily perfect) implementation of
wrap_line_to_viewport is in most languages, and decide whether or not we
think that burden is too high.

Cheers,
Solderpunk

From lel at envs.net  Fri Jan 17 16:07:08 2020
From: lel at envs.net (lel)
Date: Fri, 17 Jan 2020 11:07:08 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117142715.GA23881@SDF.ORG>
References: <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
Message-ID: <20200117160708.GA11117@briz>

On Fri, Jan 17, 2020 at 02:27:15PM +0000, solderpunk wrote:
> ...
> I guess the next thing to do is to start thinking about how
> difficult a "good enough" (not necessarily perfect) implementation of
> wrap_line_to_viewport is in most languages, and decide whether or not we
> think that burden is too high.

I don't think it's too high. I just wrote up an awful implementation in 
the most naive way possible and it came out ~30 lines, with a good deal of
that being the edge case of words longer than the viewport width (i 
handled this by splitting these words with hyphens at the viewport width;
i don't know if there are other edge-cases that need to be handled but i 
can't think of any).

I'm attaching it. You can execute it with:

```
python3 wrap.py [length] [text]
```

Or import it and call wrap with first parameter being the text and the
second being the viewport width.

I can't stress enough how "not perfect" this is (I wrote it up on my
phone, of all things, in about 5 minutes, so very little thought was put
into making it good) but at the very least it's doable. I know you mention
that python can do this natively, but I didn't use any dynamic-typing, and
all that's required for this sort of implementation is a method to split 
by newline and space, so really something like this could be done pretty 
universally.

But it's still not good.

~ lel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrap.py
Type: text/x-python
Size: 1233 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200117/4becec65/attachment.py>

From aaron at ajanse.me  Fri Jan 17 16:52:52 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Fri, 17 Jan 2020 08:52:52 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117160708.GA11117@briz>
References: <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
Message-ID: <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>

lel said:
> Yes, this is exactly what I was trying to say.

Ahaha, same here. Thank you, solderpunk, for hearing us out. Sorry for not
being so explicit!

> then defining special
> line types for headings, etc. doesn't actually add any extra burden on
> simple clients.  It's basically a question of how many cases you want
> to handle in a switch statement...

This is definitely a big appeal for me. Fancy clients could also wrap
quote blocks by putting a greater-than sign on the beginning of each
wrapped line, without requiring simple clients to do the same :-)

> even bare minimal clients need to be able to wrap long lines to result
> in readability.

In order to deal with wide clients, yes. But if we did hard wrapping, we'd
have to do the exact same thing (but plus reflowing) on narrow clients
anyway.

> I don't think it's too high. I just wrote up an awful implementation in 
> the most naive way possible and it came out ~30 lines

Plus, most systems have bash, so worst case, someone either calls `fmt`/`par`
from the client source code or pipes their client output into `fmt`/`par`.

> This is the happiest I've been to see an email in a while honestly lol

Definitely. Unless there is a problem I'm not seeing, this sounds very
exciting!

Cheers!

From solderpunk at SDF.ORG  Fri Jan 17 17:29:02 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 17 Jan 2020 17:29:02 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
References: <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
Message-ID: <20200117172902.GA1432@SDF.ORG>

On Fri, Jan 17, 2020 at 08:52:52AM -0800, Aaron Janse wrote:
> 
> Definitely. Unless there is a problem I'm not seeing, this sounds very
> exciting!

I'm excited by this, too.  Because I can't control myself I've already
started writing up a rough spec for this, included below for comment.  I
definitely want to wait until more people have chimed in before getting
too excited, and I'd especially like to hear from all, or at least most,
of the authors of existing clients before making even a tentative
decision.  But I have to say, in writing up the below, I get a very good
feeling.  The description is not exactly short, but it's very *not
fiddly* compared to how it would look if we were going to support
"reflow in both directions".  This "half reflow" approach seems to hit
an amazing sweetspot of simplicity, richness and adaptability of display
widths.  I have figured out how to get vim to let me write this kind of
content in a pleasant and easy way, so I think I'm happy to switch.  And
if anybody *really* hates it, they can still hard-wrap their files and
wide clients following these rules will display it properly.  Narrow
clients will end up with a mess, but that's just the price people will
have to pay for sticking to their hard-wrapping guns.  Many of them will
probably be happy to dismiss mobile clients out of hand, anyway!

Feedback on the below very welcome!

Cheers,
Solderpunk

---------

The text/gemini syntax is inspired by and looks visually similar to
Markdown, but it is significantly simpler (and consequently less
powerful).  The syntax is strictly line-based: a file can be processed
one line at a time and each line can be handled in a way which does
not depend upon any previous or subsequent lines.  The only internal
state a rendering engine needs to maintain is a single boolean
variable (for preformatting mode, described below).

The lines of a text/gemini file come in 8 different types.  It is
possible to unambiguously determine the type of a line by only
considering its first three characters.  Knowing a line's type is the
only information necessary to know how to handle it correctly.

Just like Gemini's status code system is designed so that simple
clients can ignore the second digit of the code and still function
correctly, the text/gemini syntax is designed so that simple clients
can treat several different types of line identically and still
provide a usable representation of the document.  A bare-minimum
client need only recognise four different types of line.  These are:

1. PREFORMATTED TOGGLE LINES

Lines consisting of only and exactly three back ticks (```) are
preformatted toggle lines.  These lines should not be displayed to the
user and are instead used to toggle preformatted mode on and off (the
mode is off when the parser is intialised).  When preformatted mode is
on, the usual rules for identifying line types are suspended and all
lines should be unconditionally identified as PREFORMATTED TEXT LINES.

2. PREFORMATTED TEXT LINES

Preformatted text lines should be presented to the user in a monowidth
font exactly as they appear in the text/gemini file.  Lines longer
than the client's viewport must not be wrapped, leading or trailing
whitespace must not be removed, etc.  Handling of lines longer than the
viewport is client-specific.  Advanced clients may display a
horizontal scrollbar.  Simple clients may simply truncate the line.

3. LINK LINES

Lines beginning with the two characters => are link lines.  We all know
how these work by now.

4. TEXT LINES

All other lines are TEXT LINES.  They should be presented to the user
in a client-specific "pleasing manner".  Lines longer than the
client's viewport should be wrapped into multiple lines of a suitable
length.  Variable width fonts may be used.  Blank lines are a special
case of TEXT LINES and should be reproduced in the output.

It is important to realise that while Markdown, HTML, LaTeX and many
other document markup formats are "block based" or "paragraph based",
the text/gemini format is not.  Consecutive, non-blank lines of text
which are much shorter than the client's viewport should *not* be
combined into longer lines.  Equivalently, *every* newline character
in a text/gemini file is significant, not only consecutive pairs of
newline characters.  Clients ignoring this fact will produce incorrect
output.

Advanced clients may also recognise the following additional line
types.  Simple clients may treat all line types below as TEXT LINES
with no loss of essential function.

5. HEADING LINES

Lines beginning with one, two or three consecutive # characters are
HEADING LINES, corresponding to headings, subheadings or susubheadings
respectively.  The text following the # characters (with leading
whitespace removed) constitute the heading and should be displayed to
the user.  Clients MAY choose to apply special styling to headings to
distinguish them from ordinary lines.  However, the primary purpose of
HEADING LINES is to represent the internal structure of the document
in a machine-readable way.  Advanced clients can use this information
to, e.g. display a hierarchically formatted "table of contents" for a
long document in a side-pane, allowing users to easily jump to
specific sections without excessive scrolling.  Or CMS-style tools
automatically generating menus or Atom/RSS feeds for a directory of
text/gemini files can use the first heading in a file as a
human-friendly label for links to it.

6. UNORDERED LIST ITEMS

Lines beginning with a * are UNORDERED LIST ITEMS.  This line type
exists purely for stylistic reasons.  The * may be replaced in
advanced clients by a bullet symbol.  Any text after the * character
should be presented to the user as if it were a TEXT LINE, i.e.
wrapped to fit the viewport.  Advanced clients can take the space of
the bullet symbol into account when performing wrapping and ensure
that all lines of text corresponding to the item are aligned with one
another.

7. ORDERED LIST ITEMS

As above with obvious changes.

From aaron at ajanse.me  Fri Jan 17 17:59:18 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Fri, 17 Jan 2020 09:59:18 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117172902.GA1432@SDF.ORG>
References: <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
Message-ID: <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>

> Lines consisting of only and exactly three back ticks (```) are preformatted
> toggle lines.

Hmm, this might confuse some people who are used to markdown's allowance of
specifying the language:

```python
print("Hello!")
```

Plus, if we *allow* people to specify the language, maybe some clients could
implement syntax highlighting. Would that be too complex?

If not, what would happen if people add text to the closing three ticks?

> Lines longer than the client's viewport must not be wrapped, leading or
> trailing whitespace must not be removed, etc.  Handling of lines longer than
> the viewport is client-specific

These two sentences contradict each other, I think. Maybe state that clients
MUST NOT remove trailing space, etc, but state that clients SHOULD allow
readers to copy the text such that it can be pasted directly into a text editor
then run (this would allow the 100-line python client to just print the lines;
terminals should un-soft-wrap lines longer than the viewport when copied to the
clipboard).

> They should be presented to the user in a client-specific "pleasing manner"
> Variable width fonts may be used.

I *love* that this is part of the spec!

> 6. UNORDERED LIST ITEMS

Are minus signs allowed for unordered list items? How about plus signs etc?
I'm somewhat in favor of limiting bullets to astrisks and minuses.

Can top-level bullets begin with a space? What about nested bullet points?

> 7. ORDERED LIST ITEMS

I'd further specify what is/isn't allowed here. For example:
- Some people may try `1)` instead of `1.`. I personally think that spec should
  say that only the latter is allowed but clients may choose to *render*
  ordered lists as the former
- What about nested ordered bullet points. Wouldn't they start with whitespace?
- Markdown allows lists to be auto-numbered. For example, the nested bullet
  points would be re-numbered from 1 to 5 in markdown:
  1. one
  1. two
  5. three
  2. four
  1. five
- What about lettered lists (A-Z)? I think these would be cool to have but I
  doubt they'd be worth the complexity. I'd be explicit in the spec
- What about roman numerals? I don't think these should be allowed

While we could leave some stuff un-specified and see how things play out, I
think there could be some value in limiting authors for the sake of preventing
a scenario where making a client is so complex that very few nice clients exist
(as we see in the world of web browsers).

> The lines of a text/gemini file come in 8 different types.

Hmm, I only saw 7 different types specified. I also recommend you specify that
people may use greater-than-symbol quotes, which may be nested. I'd recommend
that authors MUST NOT unnecessarily hard-wrap their quotes, suggesting that
advanced clients MAY add a visual greater-than symbol to the beginning of each
wrapped line.

Example:

> hello this is wider than the viewport

Displayed by advanced clients as:

> hello this is
> wider that the
> viewport

---

I asked a ton of questions, but I still like the direction we're going. I'd
just like to bring up one more thing:

What about Gemini proxies of comment thread sites, such as hacker news (*waves
to Michael Lazar's awesome HN Gopher proxy*). I think we should take those
into consideration.

If we wanted to introduce new syntax (which is a bit crazy, but fun), we could
use pipes like greater-than signs. We could use the exact same code for this
that we would use for fancy-wrapping greater-than-sign quotes.

For example, the source code would be:

| # John
| this is a comment wider than the very narrow viewport
|
| | # Joe
| | and this is a sub comment tthat is very very very long!
| |
| | | # You
| | | and this is a sub sub comment!
|
| | # Bob
| | and this is a sub comment

The output on a narrow viewport would be:

| # John
| this is a comment wider
| than the very narrow
| viewport
|
| | # Joe
| | and this is a sub
| | comment that is very
| | very very long!
| |
| | | # You
| | | and this is a sub
| | | sub comment!
|
| | # Bob
| | and this is a sub
| | comment

I know it's super crazy, but it sounds simple to implement. I was considering
mentioning it in its own thread, but I think this is the most relevant time
to bring it up.

Cheers!

From sean at conman.org  Sat Jan 18 02:16:27 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 17 Jan 2020 21:16:27 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117172902.GA1432@SDF.ORG>
References: <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
Message-ID: <20200118021627.GF3354@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> Feedback on the below very welcome!

  Red alert!  Raise shields!  Strap in!  This is going to be a bumpy ride.

  Attached is a sample document that I created that I'm trying to format per
the spec below.  I'm already running into trouble, else I would have not
replied with this particular response.

> The text/gemini syntax is inspired by and looks visually similar to
> Markdown, but it is significantly simpler (and consequently less
> powerful).  The syntax is strictly line-based: a file can be processed
> one line at a time and each line can be handled in a way which does
> not depend upon any previous or subsequent lines.  The only internal
> state a rendering engine needs to maintain is a single boolean
> variable (for preformatting mode, described below).
> 
> The lines of a text/gemini file come in 8 different types.  

  I only see 7 listed below.

> It is
> possible to unambiguously determine the type of a line by only
> considering its first three characters.  Knowing a line's type is the
> only information necessary to know how to handle it correctly.

  Not quite true, even according to this document.  Leading white space in
lists is the glaring exception here.

> Just like Gemini's status code system is designed so that simple
> clients can ignore the second digit of the code and still function
> correctly, the text/gemini syntax is designed so that simple clients
> can treat several different types of line identically and still
> provide a usable representation of the document.  A bare-minimum
> client need only recognise four different types of line.  These are:

  Yet seven are listed.  

> 1. PREFORMATTED TOGGLE LINES
> 
> Lines consisting of only and exactly three back ticks (```) are
> preformatted toggle lines.  These lines should not be displayed to the
> user and are instead used to toggle preformatted mode on and off (the
> mode is off when the parser is intialised).  When preformatted mode is
> on, the usual rules for identifying line types are suspended and all
> lines should be unconditionally identified as PREFORMATTED TEXT LINES.
> 
> 2. PREFORMATTED TEXT LINES
> 
> Preformatted text lines should be presented to the user in a monowidth
> font exactly as they appear in the text/gemini file.  Lines longer
> than the client's viewport must not be wrapped, leading or trailing
> whitespace must not be removed, etc.  Handling of lines longer than the
> viewport is client-specific.  Advanced clients may display a
> horizontal scrollbar.  Simple clients may simply truncate the line.

  No real problems so far.

> 3. LINK LINES
> 
> Lines beginning with the two characters => are link lines.  We all know
> how these work by now.

  Again, no real problem.

> 4. TEXT LINES
> 
> All other lines are TEXT LINES.  They should be presented to the user
> in a client-specific "pleasing manner".  Lines longer than the
> client's viewport should be wrapped into multiple lines of a suitable
> length.  Variable width fonts may be used.  Blank lines are a special
> case of TEXT LINES and should be reproduced in the output.
> 
> It is important to realise that while Markdown, HTML, LaTeX and many
> other document markup formats are "block based" or "paragraph based",
> the text/gemini format is not.  Consecutive, non-blank lines of text
> which are much shorter than the client's viewport should *not* be
> combined into longer lines.  Equivalently, *every* newline character
> in a text/gemini file is significant, not only consecutive pairs of
> newline characters.  Clients ignoring this fact will produce incorrect
> output.

  Fair enough. And so far, things are okay.

> Advanced clients may also recognise the following additional line
> types.  Simple clients may treat all line types below as TEXT LINES
> with no loss of essential function.

  It's here we start running into trouble.

> 5. HEADING LINES
> 
> Lines beginning with one, two or three consecutive # characters are
> HEADING LINES, corresponding to headings, subheadings or susubheadings
> respectively.  The text following the # characters (with leading
> whitespace removed) 

  The parenthetical here is ambiguous.  Does it refer to this issue?

#A title
## A title with space between the '#' and text
###	Even more white space

or

#A title
  ##A title with leading space before the '#'
	###Even more white space

  I'm thinking the former now that I'm replying, but my code deals with both
cases combined, so I can handle:

# A title
  ##     A title with spaces
	###	Yippee!  Spaces galore!

  Almost---tabs (and yes, I do use tabs---I like me the tabs) are an issue
and while I can handle them (I have code that will expand them up to 8
spaces) not everybody has code to deal with this.  So question:

	WHAT ABOUT TABS?

  They WILL show up.

> constitute the heading and should be displayed to
> the user.  Clients MAY choose to apply special styling to headings to
> distinguish them from ordinary lines.  However, the primary purpose of
> HEADING LINES is to represent the internal structure of the document
> in a machine-readable way.  Advanced clients can use this information
> to, e.g. display a hierarchically formatted "table of contents" for a
> long document in a side-pane, allowing users to easily jump to
> specific sections without excessive scrolling.  Or CMS-style tools
> automatically generating menus or Atom/RSS feeds for a directory of
> text/gemini files can use the first heading in a file as a
> human-friendly label for links to it.

  So another question.  I have some headings like this:

### Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sodales eget nisi quis condimentum. Donec ipsum arcu, fermentum eu ullamcorper sit amet, facilisis id nunc. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam tempus nulla ut dolor luctus malesuada. Suspendisse orci sem, semper at maximus non, pharetra et justo. Quisque lectus arcu, viverra ac convallis eu, vulputate ut enim. Nulla aliquam, lacus consequat suscipit facilisis, nisl tortor facilisis nisi, vel mattis eros arcu sed tellus. Duis quis lectus pellentesque, posuere dolor ut, sodales massa. Proin vel blandit mauris.

Given a screen width of 40, which of the four below should be displayed?

### Lorem ipsum dolor sit amet, consect

### Lorem ipsum dolor sit amet, cons...

### Lorem ipsum dolor sit amet,
### consectetur adipiscing elit. Cras
### sodales eget nisi quis condimentum.
### Donec ipsum arcu, fermentum eu
### ullamcorper sit amet, facilisis id
### nunc. Class aptent taciti sociosqu
### ad litora torquent per conubia
### nostra, per inceptos himenaeos. Nam
### tempus nulla ut dolor luctus
### malesuada. Suspendisse orci sem,
### semper at maximus non, pharetra et
### justo. Quisque lectus arcu, viverra
### ac convallis eu, vulputate ut enim.
### Nulla aliquam, lacus consequat
### suscipit facilisis, nisl tortor
### facilisis nisi, vel mattis eros
### arcu sed tellus. Duis quis lectus
### pellentesque, posuere dolor ut,
### sodales massa. Proin vel blandit
### mauris.

### Lorem ipsum dolor sit amet,
    consectetur adipiscing elit. Cras
    sodales eget nisi quis condimentum.
    Donec ipsum arcu, fermentum eu
    ullamcorper sit amet, facilisis id
    nunc. Class aptent taciti sociosqu
    ad litora torquent per conubia
    nostra, per inceptos himenaeos. Nam
    tempus nulla ut dolor luctus
    malesuada. Suspendisse orci sem,
    semper at maximus non, pharetra et
    justo. Quisque lectus arcu, viverra
    ac convallis eu, vulputate ut enim.
    Nulla aliquam, lacus consequat
    suscipit facilisis, nisl tortor
    facilisis nisi, vel mattis eros
    arcu sed tellus. Duis quis lectus
    pellentesque, posuere dolor ut,
    sodales massa. Proin vel blandit
    mauris.

### Lorem ipsum dolor sit amet,
consectetur adipiscing elit. Cras
sodales eget nisi quis condimentum.
Donec ipsum arcu, fermentum eu
ullamcorper sit amet, facilisis id
nunc. Class aptent taciti sociosqu ad
litora torquent per conubia nostra, per
inceptos himenaeos. Nam tempus nulla ut
dolor luctus malesuada. Suspendisse
orci sem, semper at maximus non,
pharetra et justo. Quisque lectus arcu,
viverra ac convallis eu, vulputate ut
enim. Nulla aliquam, lacus consequat
suscipit facilisis, nisl tortor
facilisis nisi, vel mattis eros arcu
sed tellus. Duis quis lectus
pellentesque, posuere dolor ut, sodales
massa. Proin vel blandit mauris.

  Or is this way into the "you have *got* to be kidding!" territory?  I
swear, I'm not trying to take these things to the extreme ... well, okay, I
*am* trying to take these things to the exteme, but only to find out where
the borders are.

> 6. UNORDERED LIST ITEMS
> 
> Lines beginning with a * are UNORDERED LIST ITEMS.  This line type
> exists purely for stylistic reasons.  The * may be replaced in
> advanced clients by a bullet symbol.  Any text after the * character
> should be presented to the user as if it were a TEXT LINE, i.e.
> wrapped to fit the viewport.  Advanced clients can take the space of
> the bullet symbol into account when performing wrapping and ensure
> that all lines of text corresponding to the item are aligned with one
> another.

  Okay, several questions here.  First off, replace the '###' with '*' in
the above example---how to properly format a list item that is ridiculously
long.

  Second question---this list:

* lorem
 * ipsum
  * dolor
   * Fusce faucibus ... (I'll save you the text)
   * Nunc pharetra ...
  * consectetur
  * adipiscing
  * elit
 * Cras
 * sodales
* eget
* nisi

  This is a nested list, so the lines start with a blank line.  This list
indents one space, but it could be two spaces per index, three, eight. 
Also, this list:

* lorem
	* ipsum
		* dolor
			* Fusce faucibus ...
			* Nunc pharetra ... 
		* consectetur
		* adipiscing
		* elit
	* Cras
	* sodales
* eget
* nisi

  Uses tabs (ah, lovely tabs).  Are indents preserved?  Transformed?  What
if there's mixed spaces and tabs (one line is a tab and two space, another
line is 10 spaces---with a default tab stop of 8, they both line up)? 

> 7. ORDERED LIST ITEMS
> 
> As above with obvious changes.

  Not so fast there!  Again, the same issues as above, but now here are some
ordered lists that are obvious *to me* but maybe not to others:

1 lorem
 1 ipsum
  1 dolor
   1 Fusce faucibus ...
   2 Nunc pharetra ...
  2 consectetur
  3 adipiscing
  4 elit
 2 Cras
 3 sodales
2 eget
3 nisi

  The following is how I learned outlining in school:

1 lorem
 A ipsum
  i dolor
   a Fusce faucibus ...
   b Nunc pharetra ...
  ii consectetur
  iii adipiscing
  iv elit
 B Cras
 C sodales
2 eget
3 nisi

  And in case you don't want to support Roman numerals:

1 lorem
 A ipsum
  1 dolor
   A Fusce faucibus ...
   B Nunc pharetra ...
  2 consectetur
  3 adipiscing
  4 elit
 B Cras
 C sodales
2 eget
3 nisi

  And again, all the same questions apply from unordered lists.

  That's it for now.  I'm going to hold off on my implementation until some
of this is cleared up, but please do check out the attached document as a
warning of what might be possible with this format.

  -spc (Will torture specs for food ...)

-------------- next part --------------
# Sample Gemini Text File
## Very long lines, blank lines between them

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sodales eget nisi quis condimentum. Donec ipsum arcu, fermentum eu ullamcorper sit amet, facilisis id nunc. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam tempus nulla ut dolor luctus malesuada. Suspendisse orci sem, semper at maximus non, pharetra et justo. Quisque lectus arcu, viverra ac convallis eu, vulputate ut enim. Nulla aliquam, lacus consequat suscipit facilisis, nisl tortor facilisis nisi, vel mattis eros arcu sed tellus. Duis quis lectus pellentesque, posuere dolor ut, sodales massa. Proin vel blandit mauris.

Aenean vehicula eu eros vel feugiat. Quisque sagittis metus eu nisl dapibus condimentum. Aenean ipsum justo, sagittis vel ipsum sit amet, fermentum convallis elit. Ut congue scelerisque velit, nec euismod nulla gravida quis. Duis faucibus tempus ligula, non malesuada neque lobortis quis. Nam neque magna, ornare eu dui ut, porttitor tincidunt purus. Duis id malesuada ante. Suspendisse gravida condimentum nisl, eget gravida dui pellentesque et.

Fusce tempor leo nulla, non posuere sem maximus eget. Integer non maximus quam. Nam ac felis ut elit aliquam aliquam. Curabitur laoreet metus nulla, a ornare lorem molestie a. Sed id libero vel nunc lobortis lacinia sed quis metus. Sed feugiat eget ipsum et commodo. Fusce condimentum est ut arcu imperdiet, vel porta felis tincidunt. Aliquam quis molestie libero, sit amet luctus quam. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Suspendisse potenti. Integer quis eros neque. Sed vulputate condimentum est et cursus. Nunc urna ante, euismod quis tempus ac, aliquam at felis. Sed hendrerit ex eu odio sodales fermentum.

Fusce faucibus dui et consectetur aliquet. Nullam augue magna, bibendum sit amet commodo at, sagittis non leo. Sed eget mauris eget arcu vulputate vulputate. Morbi non gravida dolor, in mollis turpis. Ut quis tempor elit. Aenean nec arcu vitae justo gravida placerat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam vel suscipit nisi. Curabitur vitae elit ultricies, ultrices dolor sed, vehicula augue. Phasellus euismod ligula sit amet mi volutpat tempor. Nunc scelerisque mauris dui, sed placerat nibh tempus non. Mauris eleifend purus nec tincidunt dapibus. Maecenas tincidunt volutpat varius. Phasellus eu congue risus. Nam venenatis erat non auctor ullamcorper.

Nunc pharetra sem nec velit tempus, sed malesuada felis accumsan. Vestibulum egestas ex nisl, sit amet rhoncus mauris laoreet at. Ut neque lorem, tempus et dictum non, laoreet ac mauris. Maecenas consectetur blandit neque eget maximus. Duis tincidunt elementum lorem, at varius nisl dapibus vel. In blandit ipsum sed molestie commodo. Quisque aliquet nunc eget pretium viverra. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi ligula nisi, sollicitudin tincidunt efficitur nec, lobortis eu diam. Vestibulum convallis erat velit, semper semper augue sodales in.

## Very long lines, one after the other

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sodales eget nisi quis condimentum. Donec ipsum arcu, fermentum eu ullamcorper sit amet, facilisis id nunc. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam tempus nulla ut dolor luctus malesuada. Suspendisse orci sem, semper at maximus non, pharetra et justo. Quisque lectus arcu, viverra ac convallis eu, vulputate ut enim. Nulla aliquam, lacus consequat suscipit facilisis, nisl tortor facilisis nisi, vel mattis eros arcu sed tellus. Duis quis lectus pellentesque, posuere dolor ut, sodales massa. Proin vel blandit mauris.
Aenean vehicula eu eros vel feugiat. Quisque sagittis metus eu nisl dapibus condimentum. Aenean ipsum justo, sagittis vel ipsum sit amet, fermentum convallis elit. Ut congue scelerisque velit, nec euismod nulla gravida quis. Duis faucibus tempus ligula, non malesuada neque lobortis quis. Nam neque magna, ornare eu dui ut, porttitor tincidunt purus. Duis id malesuada ante. Suspendisse gravida condimentum nisl, eget gravida dui pellentesque et.
Fusce tempor leo nulla, non posuere sem maximus eget. Integer non maximus quam. Nam ac felis ut elit aliquam aliquam. Curabitur laoreet metus nulla, a ornare lorem molestie a. Sed id libero vel nunc lobortis lacinia sed quis metus. Sed feugiat eget ipsum et commodo. Fusce condimentum est ut arcu imperdiet, vel porta felis tincidunt. Aliquam quis molestie libero, sit amet luctus quam. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Suspendisse potenti. Integer quis eros neque. Sed vulputate condimentum est et cursus. Nunc urna ante, euismod quis tempus ac, aliquam at felis. Sed hendrerit ex eu odio sodales fermentum.
Fusce faucibus dui et consectetur aliquet. Nullam augue magna, bibendum sit amet commodo at, sagittis non leo. Sed eget mauris eget arcu vulputate vulputate. Morbi non gravida dolor, in mollis turpis. Ut quis tempor elit. Aenean nec arcu vitae justo gravida placerat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam vel suscipit nisi. Curabitur vitae elit ultricies, ultrices dolor sed, vehicula augue. Phasellus euismod ligula sit amet mi volutpat tempor. Nunc scelerisque mauris dui, sed placerat nibh tempus non. Mauris eleifend purus nec tincidunt dapibus. Maecenas tincidunt volutpat varius. Phasellus eu congue risus. Nam venenatis erat non auctor ullamcorper.
Nunc pharetra sem nec velit tempus, sed malesuada felis accumsan. Vestibulum egestas ex nisl, sit amet rhoncus mauris laoreet at. Ut neque lorem, tempus et dictum non, laoreet ac mauris. Maecenas consectetur blandit neque eget maximus. Duis tincidunt elementum lorem, at varius nisl dapibus vel. In blandit ipsum sed molestie commodo. Quisque aliquet nunc eget pretium viverra. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi ligula nisi, sollicitudin tincidunt efficitur nec, lobortis eu diam. Vestibulum convallis erat velit, semper semper augue sodales in.

## Very short lines (how I tend to blog)

Lorem ipsum dolor sit amet,
consectetur adipiscing elit.
Cras sodales eget nisi quis condimentum.
Donec ipsum arcu,
fermentum eu ullamcorper sit amet,
facilisis id nunc.
Class aptent taciti sociosqu ad litora torquent per conubia nostra,
per inceptos himenaeos.
Nam tempus nulla ut dolor luctus malesuada. 
Suspendisse orci sem,
semper at maximus non,
pharetra et justo.
Quisque lectus arcu,
viverra ac convallis eu,
vulputate ut enim.
Nulla aliquam,
lacus consequat suscipit facilisis,
nisl tortor facilisis nisi,
vel mattis eros arcu sed tellus.
Duis quis lectus pellentesque,
posuere dolor ut,
sodales massa.
Proin vel blandit mauris.

## Links

=> gemini://example.net/ Lorem ipsum dolor sit amet
=> gemini://example.net/ Class aptent taciti sociosqu ad litora torquent per conubia nostra
=> gemini://example.net/ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sodales eget nisi quis condimentum. Donec ipsum arcu, fermentum eu ullamcorper sit amet, facilisis id nunc. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam tempus nulla ut dolor luctus malesuada. Suspendisse orci sem, semper at maximus non, pharetra et justo. Quisque lectus arcu, viverra ac convallis eu, vulputate ut enim. Nulla aliquam, lacus consequat suscipit facilisis, nisl tortor facilisis nisi, vel mattis eros arcu sed tellus. Duis quis lectus pellentesque, posuere dolor ut, sodales massa. Proin vel blandit mauris.
=> gemini://example.net/
=> gemini://example.net/lorem/ipsum/dolor/sit/amet/consectetur/adipiscing/elit/cras/sodales/eget/nisi/quis/condimentum/donec/ipsum/arcu/fermentum/eu/ullamcorper/sit/amet/facilisis/id/nunc/class/aptent/taciti/sociosqu/ad/litora/torquent/per/conubia/nostra/per/inceptos/himenaeos/nam/tempus/nulla/ut/dolor/luctus/

## Preformatted Text Lines

```
quis x1  = facilisis "lpeg"
quis x2  = "..."
quis x3  = x1.x4(x1.x5("AZ","az")^1)
         + (x1.x6(1) - x1.x5("AZ","ax"))^1
quis x7  = x1.x8(x3^1)
quis x9  = x7:lobortis(x2)
quis x10 = 1

-- Lorem ipsum dolor sit amet, consectetur adipiscing elit.  Cras sodales
-- eget nisi quis condimentum.  Donec ipsum arcu, fermentum eu ullamcorper
-- sit amet, facilisis id nunc.  Class aptent taciti sociosqu ad litora
-- torquent per conubia nostra, per inceptos himenaeos.  Nam tempus nulla ut
-- dolor luctus malesuada.  Suspendisse orci sem, semper at maximus non,
-- pharetra et justo.  Quisque lectus arcu, viverra ac convallis eu,
-- vulputate ut enim.  Nulla aliquam, lacus consequat suscipit facilisis,
-- nisl tortor facilisis nisi, vel mattis eros arcu sed tellus.  Duis quis
-- lectus pellentesque, posuere dolor ut, sodales massa.  Proin vel blandit
-- mauris.

elit x11 nisi sed.liguia() dolor
  eget x11 ~= "" eu
    sed.aliquam:nunc(lectus.amet('  [%q]=%q,\n',x11,x9[i]:lobortis()))
    x10 = x10 + 1
  sit
    sed.aliquam:nunc(x11,'\n')
  consectetur
consectetur
```

## Lists
### Bullet List 1

* lorem
 * ipsum
  * dolor
   * Fusce faucibus dui et consectetur aliquet. Nullam augue magna, bibendum sit amet commodo at, sagittis non leo. Sed eget mauris eget arcu vulputate vulputate. Morbi non gravida dolor, in mollis turpis. Ut quis tempor elit. Aenean nec arcu vitae justo gravida placerat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam vel suscipit nisi. Curabitur vitae elit ultricies, ultrices dolor sed, vehicula augue. Phasellus euismod ligula sit amet mi volutpat tempor. Nunc scelerisque mauris dui, sed placerat nibh tempus non. Mauris eleifend purus nec tincidunt dapibus. Maecenas tincidunt volutpat varius. Phasellus eu congue risus. Nam venenatis erat non auctor ullamcorper.
   * Nunc pharetra sem nec velit tempus, sed malesuada felis accumsan. Vestibulum egestas ex nisl, sit amet rhoncus mauris laoreet at. Ut neque lorem, tempus et dictum non, laoreet ac mauris. Maecenas consectetur blandit neque eget maximus. Duis tincidunt elementum lorem, at varius nisl dapibus vel. In blandit ipsum sed molestie commodo. Quisque aliquet nunc eget pretium viverra. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi ligula nisi, sollicitudin tincidunt efficitur nec, lobortis eu diam. Vestibulum convallis erat velit, semper semper augue sodales in.
  * consectetur
  * adipiscing
  * elit
 * Cras
 * sodales
* eget
* nisi

### Bullet List 2

* lorem
	* ipsum
		* dolor
			* Fusce faucibus dui et consectetur aliquet. Nullam augue magna, bibendum sit amet commodo at, sagittis non leo. Sed eget mauris eget arcu vulputate vulputate. Morbi non gravida dolor, in mollis turpis. Ut quis tempor elit. Aenean nec arcu vitae justo gravida placerat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam vel suscipit nisi. Curabitur vitae elit ultricies, ultrices dolor sed, vehicula augue. Phasellus euismod ligula sit amet mi volutpat tempor. Nunc scelerisque mauris dui, sed placerat nibh tempus non. Mauris eleifend purus nec tincidunt dapibus. Maecenas tincidunt volutpat varius. Phasellus eu congue risus. Nam venenatis erat non auctor ullamcorper.
			* Nunc pharetra sem nec velit tempus, sed malesuada felis accumsan. Vestibulum egestas ex nisl, sit amet rhoncus mauris laoreet at. Ut neque lorem, tempus et dictum non, laoreet ac mauris. Maecenas consectetur blandit neque eget maximus. Duis tincidunt elementum lorem, at varius nisl dapibus vel. In blandit ipsum sed molestie commodo. Quisque aliquet nunc eget pretium viverra. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi ligula nisi, sollicitudin tincidunt efficitur nec, lobortis eu diam. Vestibulum convallis erat velit, semper semper augue sodales in.
		* consectetur
		* adipiscing
		* elit
	* Cras
	* sodales
* eget
* nisi

### Ordered List 1

1 lorem
 1 ipsum
  1 dolor
   1 Fusce faucibus dui et consectetur aliquet. Nullam augue magna, bibendum sit amet commodo at, sagittis non leo. Sed eget mauris eget arcu vulputate vulputate. Morbi non gravida dolor, in mollis turpis. Ut quis tempor elit. Aenean nec arcu vitae justo gravida placerat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam vel suscipit nisi. Curabitur vitae elit ultricies, ultrices dolor sed, vehicula augue. Phasellus euismod ligula sit amet mi volutpat tempor. Nunc scelerisque mauris dui, sed placerat nibh tempus non. Mauris eleifend purus nec tincidunt dapibus. Maecenas tincidunt volutpat varius. Phasellus eu congue risus. Nam venenatis erat non auctor ullamcorper.
   2 Nunc pharetra sem nec velit tempus, sed malesuada felis accumsan. Vestibulum egestas ex nisl, sit amet rhoncus mauris laoreet at. Ut neque lorem, tempus et dictum non, laoreet ac mauris. Maecenas consectetur blandit neque eget maximus. Duis tincidunt elementum lorem, at varius nisl dapibus vel. In blandit ipsum sed molestie commodo. Quisque aliquet nunc eget pretium viverra. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi ligula nisi, sollicitudin tincidunt efficitur nec, lobortis eu diam. Vestibulum convallis erat velit, semper semper augue sodales in.
  2 consectetur
  3 adipiscing
  4 elit
 2 Cras
 3 sodales
2 eget
3 nisi

### Ordered List 2

1 lorem
 A ipsum
  i dolor
   a Fusce faucibus dui et consectetur aliquet. Nullam augue magna, bibendum sit amet commodo at, sagittis non leo. Sed eget mauris eget arcu vulputate vulputate. Morbi non gravida dolor, in mollis turpis. Ut quis tempor elit. Aenean nec arcu vitae justo gravida placerat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam vel suscipit nisi. Curabitur vitae elit ultricies, ultrices dolor sed, vehicula augue. Phasellus euismod ligula sit amet mi volutpat tempor. Nunc scelerisque mauris dui, sed placerat nibh tempus non. Mauris eleifend purus nec tincidunt dapibus. Maecenas tincidunt volutpat varius. Phasellus eu congue risus. Nam venenatis erat non auctor ullamcorper.
   b Nunc pharetra sem nec velit tempus, sed malesuada felis accumsan. Vestibulum egestas ex nisl, sit amet rhoncus mauris laoreet at. Ut neque lorem, tempus et dictum non, laoreet ac mauris. Maecenas consectetur blandit neque eget maximus. Duis tincidunt elementum lorem, at varius nisl dapibus vel. In blandit ipsum sed molestie commodo. Quisque aliquet nunc eget pretium viverra. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi ligula nisi, sollicitudin tincidunt efficitur nec, lobortis eu diam. Vestibulum convallis erat velit, semper semper augue sodales in.
  ii consectetur
  iii adipiscing
  iv elit
 B Cras
 C sodales
2 eget
3 nisi

### Ordered List 3

1 lorem
 A ipsum
  1 dolor
   A Fusce faucibus dui et consectetur aliquet. Nullam augue magna, bibendum sit amet commodo at, sagittis non leo. Sed eget mauris eget arcu vulputate vulputate. Morbi non gravida dolor, in mollis turpis. Ut quis tempor elit. Aenean nec arcu vitae justo gravida placerat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam vel suscipit nisi. Curabitur vitae elit ultricies, ultrices dolor sed, vehicula augue. Phasellus euismod ligula sit amet mi volutpat tempor. Nunc scelerisque mauris dui, sed placerat nibh tempus non. Mauris eleifend purus nec tincidunt dapibus. Maecenas tincidunt volutpat varius. Phasellus eu congue risus. Nam venenatis erat non auctor ullamcorper.
   B Nunc pharetra sem nec velit tempus, sed malesuada felis accumsan. Vestibulum egestas ex nisl, sit amet rhoncus mauris laoreet at. Ut neque lorem, tempus et dictum non, laoreet ac mauris. Maecenas consectetur blandit neque eget maximus. Duis tincidunt elementum lorem, at varius nisl dapibus vel. In blandit ipsum sed molestie commodo. Quisque aliquet nunc eget pretium viverra. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Morbi ligula nisi, sollicitudin tincidunt efficitur nec, lobortis eu diam. Vestibulum convallis erat velit, semper semper augue sodales in.
  2 consectetur
  3 adipiscing
  4 elit
 B Cras
 C sodales
2 eget
3 nisi

## Long Titles

### Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sodales eget nisi quis condimentum. Donec ipsum arcu, fermentum eu ullamcorper sit amet, facilisis id nunc. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam tempus nulla ut dolor luctus malesuada. Suspendisse orci sem, semper at maximus non, pharetra et justo. Quisque lectus arcu, viverra ac convallis eu, vulputate ut enim. Nulla aliquam, lacus consequat suscipit facilisis, nisl tortor facilisis nisi, vel mattis eros arcu sed tellus. Duis quis lectus pellentesque, posuere dolor ut, sodales massa. Proin vel blandit mauris.

### Aenean vehicula eu eros vel feugiat. Quisque sagittis metus eu nisl dapibus condimentum. Aenean ipsum justo, sagittis vel ipsum sit amet, fermentum convallis elit. Ut congue scelerisque velit, nec euismod nulla gravida quis. Duis faucibus tempus ligula, non malesuada neque lobortis quis. Nam neque magna, ornare eu dui ut, porttitor tincidunt purus. Duis id malesuada ante. Suspendisse gravida condimentum nisl, eget gravida dui pellentesque et.

And this should provide for some long discussions.  I hope.

From sean at conman.org  Sat Jan 18 03:47:21 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 17 Jan 2020 22:47:21 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117172902.GA1432@SDF.ORG>
References: <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
Message-ID: <20200118034720.GG3354@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> Feedback on the below very welcome!

  Okay, I went ahead and implemented some of this spec.  I didn't bother
with the list stuff as that has to be clarified.  But the rest I did, and so
far, the implementation wasn't *too* bad---about 50 lines, but I'm using a
library to wrap text which may or may not exist in other languages.

  Anyway, you guys can test out a server rendered version at various widths
(you can even specify the width) at:

	gemini://gemini.conman.org/test/testreflow.gemini

  Some notes---the link section may or may not be how clients render
links---since the output is pure text, I decided to just make them look
distinct.  Also, that large block of text (with the header "Very long lines,
one after the other") I might change (add a blank line that doesn't exist)
but that would complicate the implementation (in case there *is* a blank
line in the input), so I'm still thinking on that one.

  But in any case, here's a sample implementation (the link to the code is
in the page mentioned above) that I'm presenting for your bikeshedding
excitement.

  -spc (Remember---I haven't implemented lists yet ... )

From lazar.michael22 at gmail.com  Sat Jan 18 05:02:42 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sat, 18 Jan 2020 00:02:42 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200116221202.GC23953@SDF.ORG>
References: <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <546c2284-4b16-4ec1-8a9f-a072e0773799@www.fastmail.com>
 <20200116221202.GC23953@SDF.ORG>
Message-ID: <CAFTy05bxMDGSmKwcD1XKODKVQxDi-55Wp14E5xYCVgxrQ4PR0g@mail.gmail.com>

On Thu, Jan 16, 2020 at 5:12 PM solderpunk <solderpunk at sdf.org> wrote:
>
> On Thu, Jan 16, 2020 at 01:09:18PM -0800, Aaron Janse wrote:
> > Oops, I meant to mention two things:
> > 1. Clients are already using TLS. I think wrapping is significantly
> >    easier than encryption.
>
> I was about to quip that the TLS is made really easy by high-level
> library support while the wrapping has to be done manually, but then I
> thought to check and, holy heck, Python has a `textwrap` module I wasn't
> aware of.

Python's textwrap module is fundamentally flawed for unicode and they have no
intention of ever fixing it [0]. Once you start going down the rabbit hole of
CJK characters, emojis, grapheme clusters, etc. it becomes exceedingly hard
to figure out how to correctly determine the width of unicode text. You can
get it working 99% of the time, but there's always those fringe cases that
no one thinks about until somebody files a bug report.

I don't know if this has any bearing on the discussion, but it's worth keeping
in the back of your mind if you intend to make unicode a first-class citizen.
I would be cautious about calling text wrapping "significantly" easier than TLS
or anything else for that matter. This was actually one of the things that drew
me to gopher in the first place, I could assume everything was ASCII and throw
all of that complexity out the window.

[0] https://bugs.python.org/issue24665

From solderpunk at SDF.ORG  Sat Jan 18 11:45:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 11:45:03 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
References: <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
Message-ID: <20200118114503.GA4518@SDF.ORG>

On Fri, Jan 17, 2020 at 09:59:18AM -0800, Aaron Janse wrote:
> > Lines consisting of only and exactly three back ticks (```) are preformatted
> > toggle lines.
> 
> Hmm, this might confuse some people who are used to markdown's allowance of
> specifying the language:
> 
> ```python
> print("Hello!")
> ```
> 
> Plus, if we *allow* people to specify the language, maybe some clients could
> implement syntax highlighting. Would that be too complex?

Ah, yes, Tomasino mentioned this earlier.

I guess it is harmless (?) to change the definition of these lines to
any which begin with ```, not which consist strictly of ```.  That lets
sufficiently fancy clients support this, the rest can just ignore it.
These lines are never actually shown to the user, so it doesn't matter
what junk comes after the ```.

> If not, what would happen if people add text to the closing three ticks?

Well, that's unambiguous.  If we didn't make the above change, lines with
text after the three ticks would not meet the definition of a preformatted
toggle line, so a client would identify them as a text line and they would
be rendered accordingly.

> > Lines longer than the client's viewport must not be wrapped, leading or
> > trailing whitespace must not be removed, etc.  Handling of lines longer than
> > the viewport is client-specific
> 
> These two sentences contradict each other, I think.

Hmm, okay, I guess they technically do.  Clients can handle over-long
lines however they want as long as they don't wrap them?

> Are minus signs allowed for unordered list items? How about plus signs etc?
> I'm somewhat in favor of limiting bullets to astrisks and minuses.

I'm fairly strongly in favour of limiting everything to exactly one way
of doing it.  The other day I skimmed the CommonMark spec
https://spec.commonmark.org/0.29/ to reassure myself we weren't doing
too much wheel re-invention.  Holy heck, there are so many different
ways to do everything!  Simple is best, less is more, one is enough!
 
> Can top-level bullets begin with a space? What about nested bullet points?

If a line begins with a space, then it doesn't begin with a *!  So then
it's by definition not an UNORDERED LIST ITEM.  It's a TEXT LINE.  I
really did mean "begins with" everywhere I said it.  IMHO this syntax
quickly becomes really unappealing unless the task of deciding which
type of line a line is remains dirt simple.

Yes, this means no nested lists.  It may seem like I've gone nuts and
suddenly happily let a whole bunch of complicated stuff into the spec,
but I really haven't!  This is still supposed to be a very simple
syntax, which inevitably comes with limitations.  There is no nested
anything in the whole syntax.  Reliable detection of nestedness in the
face of even slight variation in how authors write things will require
considering lines in the context of previous or subsequent lines, and
that's a no-no here.  I'm only willing to allow all these fun toys in if
we can do it in such a way that an adequate rendering job can be done by
considering each line of the file in perfect isolation, with a single
pass of the entire document.

> > 7. ORDERED LIST ITEMS
> 
> I'd further specify what is/isn't allowed here. For example:
> - Some people may try `1)` instead of `1.`. I personally think that spec should
>   say that only the latter is allowed but clients may choose to *render*
>   ordered lists as the former
> - What about nested ordered bullet points. Wouldn't they start with whitespace?
> - Markdown allows lists to be auto-numbered. For example, the nested bullet
>   points would be re-numbered from 1 to 5 in markdown:
>   1. one
>   1. two
>   5. three
>   2. four
>   1. five
> - What about lettered lists (A-Z)? I think these would be cool to have but I
>   doubt they'd be worth the complexity. I'd be explicit in the spec
> - What about roman numerals? I don't think these should be allowed
> 
> While we could leave some stuff un-specified and see how things play out, I
> think there could be some value in limiting authors for the sake of preventing
> a scenario where making a client is so complex that very few nice clients exist
> (as we see in the world of web browsers).

Okay, I totally goofed up here in declaring the changes as "obvious".  I
meant "obvious to everybody who has read
gemini://mozz.us/markdown/design_document and accepted is as their
personal Lord and saviour".  Well, actually, I read that and foolishly
assumed the nice approach to ordered list items was more or less the
same as standard Markdown.  Turns out it's not and Michael has done very
good simplifying work here.

As said above, I am strongly in favour of there being exactly one way to
do things, and of identifying a line's type being brutally simple.  This
totally rules out letting authors actually write numbers.  Actually
having a number followed by a period define such a line type would also
bring a very high risk of falsely identifying ordered list item lines
when processing hard-wrapped text if a sentence ending in a number, like
"Ten Gemini crews flew low Earth orbit (LEO) missions during 1965 and
1966." was wrapped in such a way that the final word was at the start of
a line.  Yes, I know, this new syntax works best when there is no hard
wrapping, so that we can use lines to determine the scope of certain
kinds of "specialness", but I will be VERY HAPPY if we can make the
syntax robust enough that it can still be applied to rare instances of
hard-wrapped content without much going wrong.

So, lines beginning with a + (not any whitespace, but a +!) are ORDERED
LIST ITEM lines.  Clients who want to be fancy can add a little bit of
extra internal state to their rendering code and can replace the +s with
incrementing numbers.  It's the client's choice whether it uses 1. 2. 3.
or 1) 2) 3) or i> ii> iii> or whatever else.  Very fancy clients can let
the user decide.  Yes, this means content authors lose precise control
over how their content is rendered (while retaining precise control over
the *semantics* of their content, i.e. authors decide whether an item is
ordered or not).  I'm not just okay with this, I'm actively happy about
it.  The web paradigm where readers are subordinate to authors with
regards to layout is a cause of many different kinds of grief.  Good
riddace to it!
 
> Hmm, I only saw 7 different types specified.

Okay, turns out I can't count in a hurry. :)  I actually just wrote N
when I first wrote that sentence, then when I ran out of time to sketch
this thing out I went back, did a quick, incorrect count, and changed
it.  In the actual spec I'll double check, and the number will be
whatever it is - I didn't mean for the list I sent out to be exhaustive,
although I also think we should resist the urge to add every nice little
thing we can think of.  It'd be great if we kept the total number to 10
or less.

> I also recommend you specify that
> people may use greater-than-symbol quotes, which may be nested.

I have no problem with quotes, but I'm not thrilled by the nesting
prospect.

> that authors MUST NOT unnecessarily hard-wrap their quotes, suggesting that
> advanced clients MAY add a visual greater-than symbol to the beginning of each
> wrapped line.
> 
> Example:
> 
> > hello this is wider than the viewport
> 
> Displayed by advanced clients as:
> 
> > hello this is
> > wider that the
> > viewport

This is exactly how I'd expect advanced clients to handle this, and I
think this whole idea is implicit in the design of this syntax: the
start of a line indicates what kind of line it is, and the scope of that
type is precisely that line.  A hard-wrapped quote with a > at the start
of each line is, in this syntax, actually several distinct consecutive
quotes.
 
> What about Gemini proxies of comment thread sites, such as hacker news (*waves
> to Michael Lazar's awesome HN Gopher proxy*). I think we should take those
> into consideration.

Hmm.  I would want to think a bit before I lay down a hard statement on
this because I don't want to impose too much of my own ideology on
Gemini, as it's supposed to be a general-purpose tool....but I am not
excited by verbatim dragging of mainstream web 2.0 cultural concepts
like comment threads into Gemini.  The circle of Gemini early-adopters
overlaps considerably with the "Small Internet" / "Slow Internet"
movement, which I guess has coloured how I think about the protocol.
Thus the idea of adding something into the spec specifically to support
visualising deep comment threads in the web-conventional way kind of
gives me the heebie-jeebies.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jan 18 12:59:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 12:59:16 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05bxMDGSmKwcD1XKODKVQxDi-55Wp14E5xYCVgxrQ4PR0g@mail.gmail.com>
References: <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <546c2284-4b16-4ec1-8a9f-a072e0773799@www.fastmail.com>
 <20200116221202.GC23953@SDF.ORG>
 <CAFTy05bxMDGSmKwcD1XKODKVQxDi-55Wp14E5xYCVgxrQ4PR0g@mail.gmail.com>
Message-ID: <20200118125916.GB4518@SDF.ORG>

On Sat, Jan 18, 2020 at 12:02:42AM -0500, Michael Lazar wrote:
 
> Python's textwrap module is fundamentally flawed for unicode and they have no
> intention of ever fixing it [0]. Once you start going down the rabbit hole of
> CJK characters, emojis, grapheme clusters, etc. it becomes exceedingly hard
> to figure out how to correctly determine the width of unicode text. You can
> get it working 99% of the time, but there's always those fringe cases that
> no one thinks about until somebody files a bug report.

...

God, I hate computers.

But, many thanks for bringing this to my attention.
 
> I don't know if this has any bearing on the discussion, but it's worth keeping
> in the back of your mind if you intend to make unicode a first-class citizen.

Unicode is already a first-class citizen in Gemini (text/gemini is
assumed to be UTF-8 if a different encoding is not explicitly provided
in the response header), and I don't think I have any interest in
changing that.

As for the present discussion...well, it's obvious this problem is no
less of a problem under paragraph-oriented "bidirectional" reflowing.
It's not obvious to me if it's less of a problem under a Gopher-style
hard-wrapping to a pre-defined maximum width model....I suppose if the
width of line including CJK characters is dependent upon the combination
of font and terminal being used (I don't know if it is, but it seems
probable) then it's not actually possible for a CJK-using author to
comply with a spec like "Hard-wrap all your content at X characters"...

Hmm...

Solderpunk

From tomasino at lavabit.com  Sat Jan 18 13:10:39 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sat, 18 Jan 2020 13:10:39 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118114503.GA4518@SDF.ORG>
References: <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
Message-ID: <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>

From: solderpunk <solderpunk at SDF.ORG>

> Yes, this means no nested lists.  It may seem like I've gone nuts and
> suddenly happily let a whole bunch of complicated stuff into the spec,
> but I really haven't!  This is still supposed to be a very simple
> syntax, which inevitably comes with limitations.  There is no nested
> anything in the whole syntax.


Love the + thing. If you think of lists and sublists hierarchically rather than nested then we do have a parallel, the # headers!

Ordered list:
+ List item one
+ List item 2
++ Level 2 item 1
++ Level 2 item 2

Unordered list:
* List 1
** Deeper
*** Maximum deepitude

And it maintains the whole "read the first 3 characters to determine what this is" rule. No extra tabbing or spacing to get in the way and follows similar conventions to the headings.


From solderpunk at SDF.ORG  Sat Jan 18 14:11:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 14:11:44 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
References: <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
Message-ID: <20200118141144.GC4518@SDF.ORG>

On Sat, Jan 18, 2020 at 01:10:39PM +0000, James Tomasino wrote:
> From: solderpunk <solderpunk at SDF.ORG>
> 
> Love the + thing. If you think of lists and sublists hierarchically rather than nested then we do have a parallel, the # headers!
> 
> ... 
> 
> And it maintains the whole "read the first 3 characters to determine what this is" rule. No extra tabbing or spacing to get in the way and follows similar conventions to the headings.
> 

Ah, now *that*'s nice!  Having a consistent system makes the whole thing
easier to learn and remember.  Good thinking!

Cheers,
Solderpunk

From dave at ratfactor.com  Sat Jan 18 14:46:47 2020
From: dave at ratfactor.com (Dave Gauer)
Date: Sat, 18 Jan 2020 09:46:47 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
References: <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
Message-ID: <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>

On 1/18/20 8:10 AM, James Tomasino wrote:
> From: solderpunk <solderpunk at SDF.ORG>
> 
>> Yes, this means no nested lists.  It may seem like I've gone nuts and
>> suddenly happily let a whole bunch of complicated stuff into the spec,
>> but I really haven't!  This is still supposed to be a very simple
>> syntax, which inevitably comes with limitations.  There is no nested
>> anything in the whole syntax.
> 
> 
> Love the + thing. If you think of lists and sublists hierarchically rather than nested then we do have a parallel, the # headers!
> 
> Ordered list:
> + List item one
> + List item 2
> ++ Level 2 item 1
> ++ Level 2 item 2
> 
> Unordered list:
> * List 1
> ** Deeper
> *** Maximum deepitude
> 
> And it maintains the whole "read the first 3 characters to determine what this is" rule. No extra tabbing or spacing to get in the way and follows similar conventions to the headings.


Hello!  I've been lurking throughout the entire long history of this 
discussion.  ("Wanted to contribute, but other commitments...etc. etc.")

I just wanted to pipe in to share my excitement about this simple 3-char 
rule.  I *love* the simplicity of "context-free" line-based parsing.

This reminds me of several times in which I've used an "indent level + 
sort order" in databases to simulate complex nested tree hierarchies to 
make rendering to the screen absolutely trivial.

For some reason, it had never occurred to me that counting the number of 
stars '*' at the beginning of the line logically amounted to the same 
thing.  This is wonderful.

I'm also strongly in favor of the Maximum Deepitude rule.

<3

-ratfactor

From julien at typed-hole.org  Sat Jan 18 15:21:04 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 18 Jan 2020 16:21:04 +0100
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
References: <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
Message-ID: <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>

On 1/18/20 2:10 PM, James Tomasino wrote:

> Ordered list:
> + List item one
> + List item 2
> ++ Level 2 item 1
> ++ Level 2 item 2
>
> Unordered list:
> * List 1
> ** Deeper
> *** Maximum deepitude
>
> And it maintains the whole "read the first 3 characters to determine what this is" rule. No extra tabbing or spacing to get in the way and follows similar conventions to the headings.
I really like this idea combined with the "read the first 3 characters", 
simple and elegant!

From solderpunk at SDF.ORG  Sat Jan 18 15:39:47 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 15:39:47 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>
References: <20200117133312.GA7402@SDF.ORG> <20200117135804.GA5259@briz>
 <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>
Message-ID: <20200118153947.GD4518@SDF.ORG>

On Sat, Jan 18, 2020 at 04:21:04PM +0100, Julien Blanchard wrote:
> I really like this idea combined with the "read the first 3 characters",
> simple and elegant!

Julien, as the author of multiple Gemini clients, how do you feel about
the prospect of most text/gemini content having very long lines which
need to be wrapped to fit the viewport?

Cheers,
Solderpunk

From julien at typed-hole.org  Sat Jan 18 16:41:05 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 18 Jan 2020 17:41:05 +0100
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118153947.GD4518@SDF.ORG>
References: <20200117133312.GA7402@SDF.ORG> <20200117135804.GA5259@briz>
 <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>
 <20200118153947.GD4518@SDF.ORG>
Message-ID: <b2d1b848-c6ba-d6ed-1c93-47485c751bfc@typed-hole.org>

On 1/18/20 4:39 PM, solderpunk wrote:

> Julien, as the author of multiple Gemini clients, how do you feel about
> the prospect of most text/gemini content having very long lines which
> need to be wrapped to fit the viewport?

Both my clients try to display content as the author wrote it and I
parse it line by line so I don't see any issue with the proposal as
long as I can get the viewport size in my clients.
Both NCurses and GTK should provide that I'm quite sure.

Identifying what is meant by a line by it's first 3 characters is
great, will make the parsing even simpler!

The ``` case will be a little bit more problematic as the parsing
process would need to know what was parsed a few lines before
(was a "tag" opened?).

Line by line parsing is preferable to allow simple implementations
to me, but that's not be a deal-breaker either.


From julien at typed-hole.org  Sat Jan 18 17:05:35 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 18 Jan 2020 18:05:35 +0100
Subject: Adding a content size meta?
Message-ID: <a5f8b5d4-247a-4372-cdc2-284e6d5b6040@typed-hole.org>

Thanks to gemini://konpeito.media I noticed we might be missing the
content size information in some cases, mostly binary files.
With content that takes some time to be downloaded it would be nice to
be able to show the user the download progress. Most clients currently
leave the user in the dark regarding what's happening. Since I hope
that Gemini will be used for more medium than text as cat uses it,
this would be a nice addition to clients.
I would imagine this added meta only for non `text/whatever` content.

There is also another need I felt being a client developer, it's
knowing what mime type an URL will return to be able to treat/display
it differently without necessarily getting the content.? Could we
imagine a standardized way to query an URL just for it's meta header
maybe?

These are really client dev concerns and I feel this might be overkill
and going against the simplicity we want but I had to ask :)

From solderpunk at SDF.ORG  Sat Jan 18 17:15:56 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 17:15:56 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118021627.GF3354@brevard.conman.org>
References: <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <20200118021627.GF3354@brevard.conman.org>
Message-ID: <20200118171556.GE4518@SDF.ORG>

On Fri, Jan 17, 2020 at 09:16:27PM -0500, Sean Conner wrote:
 
>   Red alert!  Raise shields!  Strap in!  This is going to be a bumpy ride.

I'd have expected nothing less from you. :)  In fact, the very fact that
felt this abrupt change of direction was worth careful nit-picking
rather than dismisisng it with a fatal flaw up front is a plesant
surprise!

>   Not quite true, even according to this document.  Leading white space in
> lists is the glaring exception here.

I'll deal with this properly in the relevant part below, but there *is*
no leading whitespace in lists by definition.  "Begins with" means
"begins with"! :)
 
> > 5. HEADING LINES
> > 
> > Lines beginning with one, two or three consecutive # characters are
> > HEADING LINES, corresponding to headings, subheadings or susubheadings
> > respectively.  The text following the # characters (with leading
> > whitespace removed) 
> 
>   The parenthetical here is ambiguous.  Does it refer to this issue?
> 
> #A title
> ## A title with space between the '#' and text
> ###	Even more white space
> 
> or
> 
> #A title
>   ##A title with leading space before the '#'
> 	###Even more white space
> 
>   I'm thinking the former now that I'm replying, but my code deals with both
> cases combined, so I can handle:

Definitely the former.  Lines with leading spaces before the # do not
satisfy the definition of a HEADING LINE, which is any line that begins
with #, ## or ###

I'm open to reconsidering the leading whitespace thing.  I guess I was
thinking that some people might like to line up their headings in this
fashion:

#   Title
##  Section
### Sub-section 

and we should think of the top-level heading as "Title" and not "
Title".
 
>   Almost---tabs (and yes, I do use tabs---I like me the tabs) are an issue
> and while I can handle them (I have code that will expand them up to 8
> spaces) not everybody has code to deal with this.  So question:
> 
> 	WHAT ABOUT TABS?
> 
>   They WILL show up.
 
In headings???  I have no idea what to suggest regarding how to handle
that.  Is this such a deranged edge case that we feel safe letting that
behaviour be client-defined?

> > constitute the heading and should be displayed to
> > the user.  Clients MAY choose to apply special styling to headings to
> > distinguish them from ordinary lines.  However, the primary purpose of
> > HEADING LINES is to represent the internal structure of the document
> > in a machine-readable way.  Advanced clients can use this information
> > to, e.g. display a hierarchically formatted "table of contents" for a
> > long document in a side-pane, allowing users to easily jump to
> > specific sections without excessive scrolling.  Or CMS-style tools
> > automatically generating menus or Atom/RSS feeds for a directory of
> > text/gemini files can use the first heading in a file as a
> > human-friendly label for links to it.
> 
>   So another question.  I have some headings like this:
> 
> ### Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sodales eget nisi quis condimentum. Donec ipsum arcu, fermentum eu ullamcorper sit amet, facilisis id nunc. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam tempus nulla ut dolor luctus malesuada. Suspendisse orci sem, semper at maximus non, pharetra et justo. Quisque lectus arcu, viverra ac convallis eu, vulputate ut enim. Nulla aliquam, lacus consequat suscipit facilisis, nisl tortor facilisis nisi, vel mattis eros arcu sed tellus. Duis quis lectus pellentesque, posuere dolor ut, sodales massa. Proin vel blandit mauris.
> 
> Given a screen width of 40, which of the four below should be displayed?
> 
> ### Lorem ipsum dolor sit amet, consect
> 
> ### Lorem ipsum dolor sit amet, cons...
> 
> ### Lorem ipsum dolor sit amet,
> ### consectetur adipiscing elit. Cras
> ### sodales eget nisi quis condimentum.
> ### Donec ipsum arcu, fermentum eu
> ### ullamcorper sit amet, facilisis id
> ### nunc. Class aptent taciti sociosqu
> ### ad litora torquent per conubia
> ### nostra, per inceptos himenaeos. Nam
> ### tempus nulla ut dolor luctus
> ### malesuada. Suspendisse orci sem,
> ### semper at maximus non, pharetra et
> ### justo. Quisque lectus arcu, viverra
> ### ac convallis eu, vulputate ut enim.
> ### Nulla aliquam, lacus consequat
> ### suscipit facilisis, nisl tortor
> ### facilisis nisi, vel mattis eros
> ### arcu sed tellus. Duis quis lectus
> ### pellentesque, posuere dolor ut,
> ### sodales massa. Proin vel blandit
> ### mauris.
> 
> ### Lorem ipsum dolor sit amet,
>     consectetur adipiscing elit. Cras
>     sodales eget nisi quis condimentum.
>     Donec ipsum arcu, fermentum eu
>     ullamcorper sit amet, facilisis id
>     nunc. Class aptent taciti sociosqu
>     ad litora torquent per conubia
>     nostra, per inceptos himenaeos. Nam
>     tempus nulla ut dolor luctus
>     malesuada. Suspendisse orci sem,
>     semper at maximus non, pharetra et
>     justo. Quisque lectus arcu, viverra
>     ac convallis eu, vulputate ut enim.
>     Nulla aliquam, lacus consequat
>     suscipit facilisis, nisl tortor
>     facilisis nisi, vel mattis eros
>     arcu sed tellus. Duis quis lectus
>     pellentesque, posuere dolor ut,
>     sodales massa. Proin vel blandit
>     mauris.
> 
> ### Lorem ipsum dolor sit amet,
> consectetur adipiscing elit. Cras
> sodales eget nisi quis condimentum.
> Donec ipsum arcu, fermentum eu
> ullamcorper sit amet, facilisis id
> nunc. Class aptent taciti sociosqu ad
> litora torquent per conubia nostra, per
> inceptos himenaeos. Nam tempus nulla ut
> dolor luctus malesuada. Suspendisse
> orci sem, semper at maximus non,
> pharetra et justo. Quisque lectus arcu,
> viverra ac convallis eu, vulputate ut
> enim. Nulla aliquam, lacus consequat
> suscipit facilisis, nisl tortor
> facilisis nisi, vel mattis eros arcu
> sed tellus. Duis quis lectus
> pellentesque, posuere dolor ut, sodales
> massa. Proin vel blandit mauris.
> 
>   Or is this way into the "you have *got* to be kidding!" territory?  I
> swear, I'm not trying to take these things to the extreme ... well, okay, I
> *am* trying to take these things to the exteme, but only to find out where
> the borders are.

You're right to do so.

Your last example is what would be produced by a simple client which
recognises only the compulsory line types (and hence treats heading
lines as text lines).

I think any of the others would be reasonable outputs for an advanced
client, although as a reader I would strongly prefer one of the
non-truncating options.  I'm not sure it makes sense to specify the
correct behaviour here, any more than it makes sense to specify what
kind of bullet symbol should be used for list items.

>   Okay, several questions here.  First off, replace the '###' with '*' in
> the above example---how to properly format a list item that is ridiculously
> long.

Well, a simple client that doesn't recognise list items as anything
special will just wrap it:

* To demonstrate endurance of humans and equipment in spaceflight for
extended periods, at least eight days required for a Moon landing, to
a maximum of two weeks

If we adopt this syntax, I would probably have AV-98 recognise item
lines and format the above like this:

* To demonstrate endurance of humans and equipment in spaceflight for
  extended periods, at least eight days required for a Moon landing,
  to a maximum of two weeks

i.e. instead of splitting the line into lines of length N, split them
into lines of length N-2, prefix the first line with "* " (or maybe find
some nice unicode bullet symbol) and prefix all the other lines with
"  ".  I suspect most clients will do something vaguely similar.  I'm
not sure we need to constrain this via spec, if somebody writes a client
which yields:

* To demonstrate endurance of humans and equipment in spaceflight...

nobody is going to want to use it.
 
>   Second question---this list:
> 
> * lorem
>  * ipsum
>   * dolor
>    * Fusce faucibus ... (I'll save you the text)
>    * Nunc pharetra ...
>   * consectetur
>   * adipiscing
>   * elit
>  * Cras
>  * sodales
> * eget
> * nisi
> 
>   This is a nested list, so the lines start with a blank line.  This list
> indents one space, but it could be two spaces per index, three, eight. 
> Also, this list:
> 
> * lorem
> 	* ipsum
> 		* dolor
> 			* Fusce faucibus ...
> 			* Nunc pharetra ... 
> 		* consectetur
> 		* adipiscing
> 		* elit
> 	* Cras
> 	* sodales
> * eget
> * nisi
> 
>   Uses tabs (ah, lovely tabs).  Are indents preserved?  Transformed?  What
> if there's mixed spaces and tabs (one line is a tab and two space, another
> line is 10 spaces---with a default tab stop of 8, they both line up)? 

Well, as I guess is clear by now, I don't consider most of those lines
to be list item lines because they don't start with *.  I had intended
nested lists to be unsupported, but I don't think I have a problem with
Tomasino's idea of permitting them via *** .  I'm still thinking on that
though.

> > 7. ORDERED LIST ITEMS
> > 
> > As above with obvious changes.
> 
>   Not so fast there!  Again, the same issues as above, but now here are some
> ordered lists that are obvious *to me* but maybe not to others:

Well, I guess a lot of your questions here are moot in light of my
earlier post about the + syntax.
 
>   -spc (Will torture specs for food ...)

You'll never go hungry!

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sat Jan 18 17:23:01 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 17:23:01 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <b2d1b848-c6ba-d6ed-1c93-47485c751bfc@typed-hole.org>
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>
 <20200118153947.GD4518@SDF.ORG>
 <b2d1b848-c6ba-d6ed-1c93-47485c751bfc@typed-hole.org>
Message-ID: <20200118172301.GF4518@SDF.ORG>

On Sat, Jan 18, 2020 at 05:41:05PM +0100, Julien Blanchard wrote:
 
> Both my clients try to display content as the author wrote it and I
> parse it line by line so I don't see any issue with the proposal as
> long as I can get the viewport size in my clients.
> Both NCurses and GTK should provide that I'm quite sure.

Okay, great!
 
> The ``` case will be a little bit more problematic as the parsing
> process would need to know what was parsed a few lines before
> (was a "tag" opened?).

By "was a tag opened?", do you just mean "am I currently inside or
outside a pair of ```s?".  I have found this very easy to track, you
just need a single boolean variable, initialised to False at the start
of the document.  Every time you see a ``` line you flip it's value.
When processing all other line types, the first thing you do is check
whether that value's true.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jan 18 17:30:48 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 17:30:48 +0000
Subject: What shall we call Gemini logs, anyway?
Message-ID: <20200118173048.GG4518@SDF.ORG>

A post by tfurrows got me thinking about this:

gemini://consensus.circumlunar.space/blog/2019-10-24_geminiBlog.gmi

(tfurrows, if you're reading - that file is served up as text/plain,
which breaks the link at the end!)

The web has blogs, gopher has phlogs, what should we call the Gemini
equivalent?

As tfurrows mentions, a minority of phloggers prefer to use "glog" over
"phlog", so that obvious candidate is taken.

The next thing that came to my mind is "gemlog", but that feels awkward
to me because it's someone's username at SDF (and I follow them on
Mastodon, too).  But I suppose most people won't recognise it as such.
Maybe I'll ask how they'd feel about us using the term.

But does anybody have any other ideas?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jan 18 17:34:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 17:34:19 +0000
Subject: Adding a content size meta?
In-Reply-To: <a5f8b5d4-247a-4372-cdc2-284e6d5b6040@typed-hole.org>
References: <a5f8b5d4-247a-4372-cdc2-284e6d5b6040@typed-hole.org>
Message-ID: <20200118173419.GH4518@SDF.ORG>

This was discussed previously in the following thread:

https://lists.orbitalfox.eu/archives/gemini/2019/000012.html

Which I'm now going to re-read to remind myself of what was said.  From
memory, I wasn't keen about adding extra fields to the META part of the
response header, for my usual fear of opening the gates to people adding
on weird non-standard extensions once it's established that more than
exactly one thing is allowed there.

Interestingly, I somehow forgot about this ubiquitous fear of mine with
regards to the recent proliferation of text/gemini line types...

Cheers,
Solderpunk


On Sat, Jan 18, 2020 at 06:05:35PM +0100, Julien Blanchard wrote:
> Thanks to gemini://konpeito.media I noticed we might be missing the
> content size information in some cases, mostly binary files.
> With content that takes some time to be downloaded it would be nice to
> be able to show the user the download progress. Most clients currently
> leave the user in the dark regarding what's happening. Since I hope
> that Gemini will be used for more medium than text as cat uses it,
> this would be a nice addition to clients.
> I would imagine this added meta only for non `text/whatever` content.
> 
> There is also another need I felt being a client developer, it's
> knowing what mime type an URL will return to be able to treat/display
> it differently without necessarily getting the content.? Could we
> imagine a standardized way to query an URL just for it's meta header
> maybe?
> 
> These are really client dev concerns and I feel this might be overkill
> and going against the simplicity we want but I had to ask :)

From julien at typed-hole.org  Sat Jan 18 17:39:47 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 18 Jan 2020 18:39:47 +0100
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118172301.GF4518@SDF.ORG>
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>
 <20200118153947.GD4518@SDF.ORG>
 <b2d1b848-c6ba-d6ed-1c93-47485c751bfc@typed-hole.org>
 <20200118172301.GF4518@SDF.ORG>
Message-ID: <4730caa8-65b1-a9cd-aa9b-24756288e13e@typed-hole.org>

On 1/18/20 6:23 PM, solderpunk wrote:

> By "was a tag opened?", do you just mean "am I currently inside or
> outside a pair of ```s?".  I have found this very easy to track, you
> just need a single boolean variable, initialised to False at the start
> of the document.  Every time you see a ``` line you flip it's value.
> When processing all other line types, the first thing you do is check
> whether that value's true.
Yes, no doubt it's relatively easy to implement but this could open the 
way to more "tags"
and I just hope it won't.

I'm really glad this conversation is coming to a conclusion which so far 
seems to satisfy
everybody and we can finally move on to other topics!

From solderpunk at SDF.ORG  Sat Jan 18 17:48:49 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 17:48:49 +0000
Subject: File size issues
In-Reply-To: <20190818113641.GC5354@SDF.ORG>
References: <20190815154110.GE28953@SDF.ORG>
 <20190815180620.GA18238@brevard.conman.org>
 <20190816104312.GA23118@SDF.ORG>
 <8736i1z27g.fsf@camilla.carcosa.net>
 <20190816134427.GA7388@SDF.ORG>
 <CAFTy05YVFKyLExAdfNof3G_s+YcQEMdFYHNTkPypVDG58U3dcw@mail.gmail.com>
 <20190818113641.GC5354@SDF.ORG>
Message-ID: <20200118174849.GI4518@SDF.ORG>

On Sun, Aug 18, 2019 at 11:36:41AM +0000, solderpunk wrote:
 
> Yeah, I think we can leave this for now.  It was a hypothetical concern
> that somebody had.  Not necessarily a bad one, but until it's observed
> actually creating significant trouble for actual users on actual clients
> I think we can just table this issue.  If it does come up as a practical
> concern, we can resume discussion of some of the ideas here.

Well, I guess this is no longer quite so hypothetical, as Konpeito has
given us large binary files over Gemini.  I noticed that this was an
unpleasant user experience to download via AV-98 (with the client
appearing to "hang" for a long time during the download).  And, in fact,
I did receive an email from one person telling me they liked Gemini a
lot, who mentioned that they had not been able to download the Konpeito
album.  I strongly suspect that, in fact, they just didn't realise their
client was slowly downloading it.

One possible solution to the user experience problem that doesn't
require the client actually knowing the file size is to display, instead
of a progress bar, some kind of "stuff is happening" indicator, e.g. an
animated spinner (you know, of the /, -, \, | kind) accompanied by a 
count of KiB / MiB downloaded so far?  That would at least make it
obvious to users that something was happening.

And a convention of specifying filesizes for large binary files in the
link text would allow rough mental calculation of progress?

Cheers,
Solderpunk

From julien at typed-hole.org  Sat Jan 18 17:50:24 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 18 Jan 2020 18:50:24 +0100
Subject: Adding a content size meta?
In-Reply-To: <20200118173419.GH4518@SDF.ORG>
References: <a5f8b5d4-247a-4372-cdc2-284e6d5b6040@typed-hole.org>
 <20200118173419.GH4518@SDF.ORG>
Message-ID: <7d9b3e08-5545-443f-8f01-960e02ace544@typed-hole.org>

On 1/18/20 6:34 PM, solderpunk wrote:

> This was discussed previously in the following thread:
>
> https://lists.orbitalfox.eu/archives/gemini/2019/000012.html
>
> Which I'm now going to re-read to remind myself of what was said.  From
> memory, I wasn't keen about adding extra fields to the META part of the
> response header, for my usual fear of opening the gates to people adding
> on weird non-standard extensions once it's established that more than
> exactly one thing is allowed there.
>
> Interestingly, I somehow forgot about this ubiquitous fear of mine with
> regards to the recent proliferation of text/gemini line types...

Ah yes fogot about that thread! Basically Sean's proposal 
https://lists.orbitalfox.eu/archives/gemini/2019/000045.html would 
satisfy all my needs client-wise, but if you prefer not to go this route
that's fine too. Kind of a cherry on top of the cake!


From b__m__e at mailfence.com  Sat Jan 18 17:58:26 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sat, 18 Jan 2020 18:58:26 +0100 (CET)
Subject: Adding a content size meta?
Message-ID: <382432062.15242.1579370306771@ichabod.co-bxl>

julienxx writes:
> Could we imagine a standardized way to query 
an URL just for it's meta header maybe?

I have just been requesting the document reading 
the first line and then severing the connection. 


I do agree that having content size, pref in bytes, in 
the meta would allow for loading animations, 
percent counters, download managers, etc. Which
would benefit the user of any client.

--?
Sent with https://mailfence.com
Secure and private email

From solderpunk at SDF.ORG  Sat Jan 18 18:34:56 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 18:34:56 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <4730caa8-65b1-a9cd-aa9b-24756288e13e@typed-hole.org>
References: <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>
 <20200118153947.GD4518@SDF.ORG>
 <b2d1b848-c6ba-d6ed-1c93-47485c751bfc@typed-hole.org>
 <20200118172301.GF4518@SDF.ORG>
 <4730caa8-65b1-a9cd-aa9b-24756288e13e@typed-hole.org>
Message-ID: <20200118183456.GJ4518@SDF.ORG>

On Sat, Jan 18, 2020 at 06:39:47PM +0100, Julien Blanchard wrote:

> I'm really glad this conversation is coming to a conclusion which so far
> seems to satisfy
> everybody and we can finally move on to other topics!

Me too!  Although I'm still very keen to hear from jmcbray on these
recent developments.  I *suspect* they'll be happy.  But I really don't
want to rush into this.

But I am amazed at how much more tractable getting away from
gopher-style hard wrapping has made this whole discussion.  It has made
it obvious to me that the problem all along has been with determining
the scope of special features.

Consider bulleted lists, with hard-wrapping.  Suppose we have this
content, hard wrapped to 40 characters, and our viewport is 60
characters so we want to combine lines:

* To demonstrate endurance of humans and    | Line 1
equipment in spaceflight for extended       | 2
periods, at least eight days required       | 3
for a Moon landing, to a maximum of two     | 4
weeks                                       | 5
* To effect rendezvous and docking with     | 6
another vehicle, and to maneuver the        | 7
combined spacecraft using the               | 8
propulsion system of the target vehicle     | 9
* To demonstrate Extra-Vehicular            | 10
Activity (EVA), or space-"walks" outside    |
the protection of the spacecraft, and to    |
evaluate the astronauts' ability to         |
perform tasks there * To perfect            |
techniques of atmospheric reentry and       |
touchdown at a pre-selected location on     |
land                                        |

Any old client can recognise that Line 1 is a list item by virtue of
the leading *.  But in order for a client to do a nice job of
reformatting this list to 60 chars, it has to understand that lines 1
through 5 constitute a single list item (i.e. that this is the scope of
the * in line 1), and that lines 2-5 are not an independent paragraph
of text coming after a list with only a single item.  To a human, this
is obvious, even if they can't read English, because the list items at
lines 6 and 10 make it clear.  But to a parser, at the time it
encounters line 2, it has no idea what's in lines 6 or 10.  So parsing
requires looking ahead, and understanding rules like "Once started, a
list item continues until we encounter either a new list item or a blank
line".  It's exactly that kind of fiddly rule that I was terrified of
filling the spec with earlier.

In HTML, the scoping problem is trivial, because there are explicit
beginning and tags, <li> and </li>.  Markdown gets rid of these for
visual lightness (great!), but that scoping information is still
essential.  In Markdown it's in there implicitly for a sufficiently
complicated (bad!) parser which understands the concept of blocks
(which can be nested).  So Markdown trades the visual complexity of
HTML for conceptual complexity that makes it a pain to parse.

The syntax we're now talking about, where scope is limited to a single
line, is such an elegant alternative to both of these!  One way to think
about it is that things like =>, * and # are differnet kinds of opening
tag but they all have the same closing tag, which is \n.  Because there
are opening and closing tags, the parsing is easy, like HTML.  But
because our closing tags are invisible and need to be there anyway, we
get ease of authoring and visual lightness like Markdown.  It's the best
of both worlds.

I'm so glad we hit upon this before I ran out of patience and just
declared Gopher-style plain text hard wrapping to be the final decision!
Thanks to everybody who steered the conversation in this direction.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sat Jan 18 18:45:30 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 18:45:30 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>
References: <20200117133312.GA7402@SDF.ORG> <20200117135804.GA5259@briz>
 <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>
Message-ID: <20200118184530.GK4518@SDF.ORG>

On Sat, Jan 18, 2020 at 09:46:47AM -0500, Dave Gauer wrote:
> 
> Hello!  I've been lurking throughout the entire long history of this
> discussion.  ("Wanted to contribute, but other commitments...etc. etc.")
> 
> I just wanted to pipe in to share my excitement about this simple 3-char
> rule.  I *love* the simplicity of "context-free" line-based parsing.

I'm so glad to hear this from you in particular!  Reading your phlog
convinced me that you've spent more time thinking about markup and
formatting issues for plain text than most other people talking about it
combined.  If you think we're on a good track here, I'm feeling a lot
better.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jan 18 18:57:49 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 18:57:49 +0000
Subject: Adding a content size meta?
In-Reply-To: <382432062.15242.1579370306771@ichabod.co-bxl>
References: <382432062.15242.1579370306771@ichabod.co-bxl>
Message-ID: <20200118185749.GL4518@SDF.ORG>

On Sat, Jan 18, 2020 at 06:58:26PM +0100, Brian Evans wrote:
> julienxx writes:
> > Could we imagine a standardized way to query 
> an URL just for it's meta header maybe?
> 
> I have just been requesting the document reading 
> the first line and then severing the connection. 
> 
> 
> I do agree that having content size, pref in bytes, in 
> the meta would allow for loading animations, 
> percent counters, download managers, etc. Which
> would benefit the user of any client.

I guess the question is whether we prefer adding this information
into the response header and having clients do the request-and-terminate
trick, or defining a well-known endpoint servers can implement which
takes a path as an input and returns either what the response header
would be, or maybe a small JSON structure of metadata (which could
include stuff like last-modified date).

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jan 18 19:05:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 19:05:19 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <660019441.8880.1579116650232@ichabod.co-bxl>
References: <660019441.8880.1579116650232@ichabod.co-bxl>
Message-ID: <20200118190519.GM4518@SDF.ORG>

On Wed, Jan 15, 2020 at 08:30:50PM +0100, Brian Evans wrote:
> Solderpunk wrote recently regarding use of color in gemini
> documents. 
> 
> I would like to put in a vote to the contrary.

Nearly forgot to get around to replying to this, but not quite. :)

When I previously declared I wasn't interested in supporting colour, I
was thinking purely about defining some kind of syntax for it, like
<red>this</red> (or any similar such thing).

I didn't mean to say anything about ANSI escape codes.  I know we're
going to have to come up with some kind of official stance on those
eventually, but I've given it no serious thought yet.

Cheers,
Solderpunk

From julien at typed-hole.org  Sat Jan 18 19:20:31 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 18 Jan 2020 20:20:31 +0100
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118190519.GM4518@SDF.ORG>
References: <660019441.8880.1579116650232@ichabod.co-bxl>
 <20200118190519.GM4518@SDF.ORG>
Message-ID: <c35b8191-dffa-8315-e693-cc56173eb233@typed-hole.org>

On 1/18/20 8:05 PM, solderpunk wrote:

> I didn't mean to say anything about ANSI escape codes.  I know we're
> going to have to come up with some kind of official stance on those
> eventually, but I've given it no serious thought yet.
FWIW I intend to add some stuff with ANSI colors on my Gemini-space, I 
have some ideas I need to tryout :)
I might add two links though, one for the colored version and another 
for the readable one if needed.
Since Bombadillo and Castor already support ANSI colors and 
kompeito.media is such a great place, I'm in favor of officially 
supporting them or at least not ban them, up to the clients to deal with 
them or not.

From aaron at ajanse.me  Sat Jan 18 19:20:10 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 18 Jan 2020 11:20:10 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118184530.GK4518@SDF.ORG>
References: <20200117133312.GA7402@SDF.ORG> <20200117135804.GA5259@briz>
 <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>
 <20200118184530.GK4518@SDF.ORG>
Message-ID: <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>

I think we made an oversight: syntax nested within quotes.

For example:

```gemini
> > It looks like things are moving along, I wonder if we forgot anything
> > that would make us need to read more than three chars to specify the
> > line type?
> 
> Here's a site to demo gemini's syntax:
> => gemini://example.com Gemini Syntax Demo
> 
> In the future, we can add the following features:
> * foo
> * bar

Client:
 *doesn't know to make quoted link clickable*
 *doesn't know to fancy-render the quoted list*
```

---

Regardless, here are my thoughts on everything else...

I definitely love:

* The use of asterisks only for unordered lists
* The use of plus signs for ordered lists. I wish markdown had this!
* Repeated list markers (*/+) to indicate depth
* Stateless line-by-line parsing

Changes I think we should make to the spec spec, based on what I've read
here and my own opinion:

* Preformatted text toggle lines only need to *start* with three
  backticks. Specify the significance of text after the backticks.
  
  Some ideas:
    * It's permitted in order to please markdown users. Ignore it
    * Display it to the user (could be position in file, language, etc)
    * Use it for syntax highlighting

* Specify that preformatted code blocks are intended for content such as
  ascii art and code, meaning that it should be easily copy-pasteable
  into a text editor without needed to undergo extra steps to revert it
  from its displayed form to its original form

* Add horizontal rule lines (three+ dashes)

* Specify that ordered lists MUST use plus sign markers

* Specify Tomasino's nested list system

* Explicitly specify markdown syntax that is not allowed. Random idea,
  but maybe we could even advise clients to shame this syntax the same
  way modern web browsers are shaming non-HTTP sites? Regardless, here
  are some things that I think we should explicitly ban in text/gemini: 
  * Ordered lists using letters or numberal markers
  * Indented markdown lists
  * Unordered lists starting with a dash
  * Embedded HTML
  * Markdown images
  * Tables in non-preformatted text blocks
  * Hard-wrapping quotes
  * Hard-wrapping text
  * Horizontal rules with anything other than three+ dashes
  * Expecting anything special when a line ends with whitespace

Are we really limited to a max depth of three? Even if we allow unlimited
depth of headers and lists, clients would only need to read the first two
chars of a line to determine its type (unless we add horizontal rules,
in which case we'd need to read three characters).

> Hmm.  I would want to think a bit before I lay down a hard statement on
> this because I don't want to impose too much of my own ideology on
> Gemini, as it's supposed to be a general-purpose tool....but I am not
> excited by verbatim dragging of mainstream web 2.0 cultural concepts
> like comment threads into Gemini.

Well, worst case scenario, if someone really badly wants comment threads,
maybe they could use nested quote blocks (assuming we figure that out).

Cheers!

From aaron at ajanse.me  Sat Jan 18 19:24:12 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 18 Jan 2020 11:24:12 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <c35b8191-dffa-8315-e693-cc56173eb233@typed-hole.org>
References: <660019441.8880.1579116650232@ichabod.co-bxl>
 <20200118190519.GM4518@SDF.ORG>
 <c35b8191-dffa-8315-e693-cc56173eb233@typed-hole.org>
Message-ID: <fa38adad-4774-4093-9c26-e8c5ad371b52@www.fastmail.com>

> Since Bombadillo and Castor already support ANSI colors and 
> kompeito.media is such a great place, I'm in favor of officially 
> supporting them or at least not ban them, up to the clients to deal with 
> them or not.

Hmmm. It does seem, though, that *allowing* ANSI colors would require
non-terminal clients to strip ANSI colors, which would be a PITA,
expecially considering that ANSI is a hot mess (I built an ANSI parser
a while ago [1])

=> https://github.com/aaronjanse/i3-tmux/tree/master/vterm [1]

From julien at typed-hole.org  Sat Jan 18 20:08:27 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 18 Jan 2020 21:08:27 +0100
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
References: <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
Message-ID: <0F5F2C9A-711B-4C23-9C3D-5336CE46B458@typed-hole.org>

I thought the use case of ``` was precisely do nothing with the next lines (ie. don?t parse) until marker is met again or am I wrong here?

From aaron at ajanse.me  Sat Jan 18 20:30:32 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 18 Jan 2020 12:30:32 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <0F5F2C9A-711B-4C23-9C3D-5336CE46B458@typed-hole.org>
References: <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
 <0F5F2C9A-711B-4C23-9C3D-5336CE46B458@typed-hole.org>
Message-ID: <31870ce6-c0dd-4fd9-a8cb-c8324fa2658c@www.fastmail.com>

I meant to say "text after the ticks, but in the same line."

Such as:

```this text
Code code code
```or this text

From solderpunk at SDF.ORG  Sat Jan 18 21:33:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 21:33:03 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>
 <20200118184530.GK4518@SDF.ORG>
 <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
Message-ID: <20200118213303.GN4518@SDF.ORG>

On Sat, Jan 18, 2020 at 11:20:10AM -0800, Aaron Janse wrote:
> I think we made an oversight: syntax nested within quotes.
> 
> Client:
>  *doesn't know to make quoted link clickable*
>  *doesn't know to fancy-render the quoted list*
> ```

Hmm, I really would not have had any expectation that quoted Gemini
syntax would do anything at all.

What sort of context would you expect this to occur in?
 
> * Preformatted text toggle lines only need to *start* with three
>   backticks. Specify the significance of text after the backticks.

I think I'm probably fine with this, does anybody have objections?
 
> * Specify that preformatted code blocks are intended for content such as
>   ascii art and code, meaning that it should be easily copy-pasteable
>   into a text editor without needed to undergo extra steps to revert it
>   from its displayed form to its original form

Yeah, it might be a good idea to emphasise the intent to preserve
copy-and-pastability.

> * Add horizontal rule lines (three+ dashes)

I guess this is harmless.  It feels a bit to me like we're adding it
just because Markdown has it - unlike headings and lists and even,
occasionally, quotes, I don't know that I've ever seen a horiozontal
rule used in Gopherspace.  But I don't see a good reason to disallow it.

> * Specify that ordered lists MUST use plus sign markers

Yep.

> * Specify Tomasino's nested list system

I think I'm still onboard with this, although I'm starting to wonder
about how these nested lists will look when rendered by a basic client
treating them as text lines.  I'm not sure it degrades to something
terribly readable.

> * Explicitly specify markdown syntax that is not allowed.

It feels very strange to me for a syntax specification to explicitly
list stuff from a different syntax specification which isn't allowed.  I
can see it being helpful to point this stuff out in a tutorial for
people learning text/gemini, but in a formal specification of a markup
format, it goes without saying that anything which isn't explicitly
supported is unsupported.

>   but maybe we could even advise clients to shame this syntax the same
>   way modern web browsers are shaming non-HTTP sites?

Wouldn't doing that (all questions about whether this is appropriate
behaviour aside) require writing code to detect all the stuff that we're
not supporting precisely because it's a pain to write code to reliably
detect it?  Seems counterproductive!

> Regardless, here
>   are some things that I think we should explicitly ban in text/gemini: 
>  ...
>   * Hard-wrapping text

I don't want to explicitly ban hard-wrapped text, I don't see the need
to.  I think this syntax actually degrades pretty gracefully when fed
hard-wrapped text that is shorter than the viewport, and that's nice.  I
think the vast majoity of people will end up taking the long line
approach because it will support a wider range of clients (especially
narrow screens) and some things will render slightly nicer.  If a small
percentage want to stick to the old ways for whatever reason, knowing
and accepting the downsides, I see no reason not to let them.
 
> Are we really limited to a max depth of three? Even if we allow unlimited
> depth of headers and lists, clients would only need to read the first two
> chars of a line to determine its type (unless we add horizontal rules,
> in which case we'd need to read three characters).

Good catch, technically speaking once a line is detected, on the basis
of the first three or fewer chars, as a header or list, it can be passed
to a function than handles a header line or a list line, and that
function has access to the whole line.

That said, maybe we should add a limit anyway.  Otherwise clients have
to write totally generalised code to handle arbitrarily many levels,
which could get tricky.
 
> Well, worst case scenario, if someone really badly wants comment threads,
> maybe they could use nested quote blocks (assuming we figure that out).

Well, it seems like the > syntax generalises in exactly the same way as
the heading and list syntaxes.

Speaking of these...what happens when a client encounters this:

** Foo
** Bar
** Baz

i.e. a bunch of allegedly nested list items which are not emedded in a
higher-level list?

For a simple text-based client which only uses the nestedness level to
determine how many spaces to stick in front of the line, this shouldn't
post major problems.  But fancy clients planning on doing graphical
things (I'm actually thinking more about quotes here than list items)
might choke if not carefully written.  Should we explicitly require
correct nesting?  Or explicitly say clients must be resilient against
weird nesting?

Cheers,
Solderpunk

From b__m__e at mailfence.com  Sat Jan 18 21:34:27 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sat, 18 Jan 2020 22:34:27 +0100 (CET)
Subject: Text reflow woes (or: I want bullets back!)y
Message-ID: <739591427.21203.1579383267196@ichabod.co-bxl>

Aaron Janse writes:
> Hmmm. It does seem, though, that *allowing* ANSI colors would require
> non-terminal clients to strip ANSI colors, which would be a PITA,
> expecially considering that ANSI is a hot mess (I built an ANSI parser
> a while ago [1])

Currently Bombadillo has a few different modes. The normal mode removes 
ansi escape codes. As I am parsing a document if I read an `\033` character I 
just toggle an escape code boolean and then consume until I read a A-Za-z
character (and consume that char as well). It works very quickly and handles
removing them quite well. I do the same thing for the color mode for any
escape codes that do not end in `m`. That said, it may not work as well for
people not parsing by writing characters into a buffer char by char.

I would also argue that it would _not_ require clients to strip them. There are
a few options:

1. Decide, rightly in my opinion, that if a content creator uses escape codes
     they are taking the chance that the codes themselves will be displayed to
     the eventual viewer depending on the client.
2. Do a simple find and replace on the whole document for '\033' and replace
    it with "ESC". While this will still leave the codes displaying to the viewer
    they will not actually render, thus you do not need to worry about line
     movement, screen clears, etc.


--?
Sent with https://mailfence.com
Secure and private email

From aaron at ajanse.me  Sat Jan 18 22:18:39 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 18 Jan 2020 14:18:39 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118213303.GN4518@SDF.ORG>
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>
 <20200118184530.GK4518@SDF.ORG>
 <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
 <20200118213303.GN4518@SDF.ORG>
Message-ID: <bddeeec4-5e79-415d-9b64-91d99b379457@www.fastmail.com>

On Sat, Jan 18, 2020, at 1:33 PM, solderpunk wrote:
> Hmm, I really would not have had any expectation that quoted Gemini
> syntax would do anything at all.
> 
> What sort of context would you expect this to occur in?

I often see quoted syntax (e.g. links, lists) on StackOverflow. However,
I haven't seen quoted syntax in phlogs. Plus, supported mixing nested
syntax could be a PITA to implement.

Also seen in the wild:
* nested lists of links (nice to have, but not sad if unsupported)
* hyperlink headers (this sounds like a mess regarding `=> #` vs `# =>`)

Either way, I'd still specify what nesting is/isn't allowed.

> I guess this is harmless.  It feels a bit to me like we're adding it
> just because Markdown has it - unlike headings and lists and even,
> occasionally, quotes, I don't know that I've ever seen a horiozontal
> rule used in Gopherspace.  But I don't see a good reason to disallow it.

I see horizontal rules used in gopherspace all the time:

=> gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/a-new-start.txt
=> gopher://zaibatsu.circumlunar.space/0/~tfurrows/phlog/2020-01-02_clickBaitGeneration.txt
=> gopher://tilde.team/0/~ben/blog/weechat-setup.md

> It feels very strange to me for a syntax specification to explicitly
> list stuff from a different syntax specification which isn't allowed.

You make a good point here. Maybe, we instead specify that clients MUST NOT
support non-specified syntax, in order to discourage pages with un-specified
syntax from being published in the first place.

> I don't want to explicitly ban hard-wrapped text, I don't see the need
> to.  I think this syntax actually degrades pretty gracefully when fed
> hard-wrapped text that is shorter than the viewport, and that's nice.

That makes sense. However, would it be unreasonable to state that users
"SHOULD NOT" hard-wrap, since doing so degrades quite poorly on mobile?

>  
> > Are we really limited to a max depth of three? Even if we allow unlimited
> > depth of headers and lists, clients would only need to read the first two
> > chars of a line to determine its type (unless we add horizontal rules,
> > in which case we'd need to read three characters).
> 
> Good catch, technically speaking once a line is detected, on the basis
> of the first three or fewer chars, as a header or list, it can be passed
> to a function than handles a header line or a list line, and that
> function has access to the whole line.
> 
> That said, maybe we should add a limit anyway.  Otherwise clients have
> to write totally generalised code to handle arbitrarily many levels,
> which could get tricky.

Hmmm. If max depth is one, that makes sense. Same if max depth is two. But
once max depth is three, it sounds like clients would be using generalized
code anyway. Plus, a shallow max depth might be very confusing for authors
using text/gemini.

>  
> > Well, worst case scenario, if someone really badly wants comment threads,
> > maybe they could use nested quote blocks (assuming we figure that out).
> 
> Well, it seems like the > syntax generalises in exactly the same way as
> the heading and list syntaxes.

But for quotes, I beg that a space character is allowed between the
greater-than symbols in nested quotes, so that we don't have to abandon
the way quotes are used in emails. In fact, I think the spec should say
that a single space after a `>` symbol should always be stripped.

> 
> Speaking of these...what happens when a client encounters this:
> 
> ** Foo
> ** Bar
> ** Baz
> 
> i.e. a bunch of allegedly nested list items which are not emedded in a
> higher-level list?
> 
> For a simple text-based client which only uses the nestedness level to
> determine how many spaces to stick in front of the line, this shouldn't
> post major problems.  But fancy clients planning on doing graphical
> things (I'm actually thinking more about quotes here than list items)
> might choke if not carefully written.  Should we explicitly require
> correct nesting?  Or explicitly say clients must be resilient against
> weird nesting?

I personally think resilients is a bad idea. It's partially to blame for so
many web browser quirks nowadays. I think that if fancy clients refuse to
render invalid syntax, that could be a good deterrant. OTOH, it's sometimes
tough to contact gopher/gemini users, so maybe nobody would be able to tell
them something's wrong. Unless we write scripts to verify that text is valid
text/gemini, and/or integrate this functionality into servers?

Cheers!

From sean at conman.org  Sat Jan 18 22:35:08 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 18 Jan 2020 17:35:08 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <b2d1b848-c6ba-d6ed-1c93-47485c751bfc@typed-hole.org>
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <a09633fb-828b-4b56-5465-6e319861d811@typed-hole.org>
 <20200118153947.GD4518@SDF.ORG>
 <b2d1b848-c6ba-d6ed-1c93-47485c751bfc@typed-hole.org>
Message-ID: <20200118223508.GH3354@brevard.conman.org>

It was thus said that the Great Julien Blanchard once stated:
> On 1/18/20 4:39 PM, solderpunk wrote:
> 
> >Julien, as the author of multiple Gemini clients, how do you feel about
> >the prospect of most text/gemini content having very long lines which
> >need to be wrapped to fit the viewport?
> 
> The ``` case will be a little bit more problematic as the parsing
> process would need to know what was parsed a few lines before
> (was a "tag" opened?).

  I found that to be easy to support.  The code looks like:

local literal = false

for line in file:lines() do
  if line:match "^#" then
    ...

  elseif line:match "^```$" then
    literal = not literal -- Yup, that's all there was to it.

  elseif line:match "^=>" then
    ...

  else
    if literal then
      display_text_to_width(line)
    else
      wrap_text_to_width(line)
    end
  end

  -spc

From sean at conman.org  Sat Jan 18 23:10:09 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 18 Jan 2020 18:10:09 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118171556.GE4518@SDF.ORG>
References: <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <20200117135804.GA5259@briz> <20200117142715.GA23881@SDF.ORG>
 <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG> <20200118021627.GF3354@brevard.conman.org>
 <20200118171556.GE4518@SDF.ORG>
Message-ID: <20200118231009.GI3354@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Fri, Jan 17, 2020 at 09:16:27PM -0500, Sean Conner wrote:
>  
> >   Red alert!  Raise shields!  Strap in!  This is going to be a bumpy ride.
> 
> I'd have expected nothing less from you. :)  In fact, the very fact that
> felt this abrupt change of direction was worth careful nit-picking
> rather than dismisisng it with a fatal flaw up front is a plesant
> surprise!

  Well, I don't have very strong feelings about text formatting for Gemini.

  Also, anything that's been cleared up in subsequent emails will not be
addressed here as there's no need to clutter things up.

> >   Almost---tabs (and yes, I do use tabs---I like me the tabs) are an issue
> > and while I can handle them (I have code that will expand them up to 8
> > spaces) not everybody has code to deal with this.  So question:
> > 
> > 	WHAT ABOUT TABS?
> > 
> >   They WILL show up.
>  
> In headings???  I have no idea what to suggest regarding how to handle
> that.  Is this such a deranged edge case that we feel safe letting that
> behaviour be client-defined?

  Not necessarily in headers, but they will appear in Gemini files (I'm
thinking most likely in pre-formatted blocks).  The thing the clients have
to be aware of is that tabs take 1 character space, but can reference up to N
spaces (where N is typically 8, but can be arbitrary values per tab).

> Well, I guess a lot of your questions here are moot in light of my
> earlier post about the + syntax.

  They are, and I shall update my code accordingly.

> >   -spc (Will torture specs for food ...)
> 
> You'll never go hungry!

  Ha!

  -spc


From tomasino at lavabit.com  Sat Jan 18 23:13:50 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sat, 18 Jan 2020 23:13:50 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <bddeeec4-5e79-415d-9b64-91d99b379457@www.fastmail.com>
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 <d6a05822-2cc1-4267-a47a-ef7eede7ab16@www.fastmail.com>
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>
 <20200118184530.GK4518@SDF.ORG>
 <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
 <20200118213303.GN4518@SDF.ORG>
 <bddeeec4-5e79-415d-9b64-91d99b379457@www.fastmail.com>
Message-ID: <d1c39345-1051-71db-2775-8dd2fa402b13@lavabit.com>

On 1/18/20 10:18 PM, Aaron Janse wrote:
> Speaking of these...what happens when a client encounters this:
> 
> ** Foo
> ** Bar
> ** Baz
> 
> i.e. a bunch of allegedly nested list items which are not emedded in a
> higher-level list?

Line 1: A list has started at depth 2. Display a depth 2 list item.

Line 2: A list has continued at depth 2.
Display another depth 2 list item.

Line 3: A list has continued at depth 2.
Display another depth 2 list item.

Pretty straight forward if we're just processing line by line. It's
every-so-slightly trickier if we're working in ordered lists. You'll
want to keep an ordinal stack.

+ item 1
++ sub item 1
+++ sub-sub item 1
+++ sub-sub item 2
++ sub item 2
+++ a new sub-sub item 1
++ sub item 3
+ item 2

As you push deeper you'll want to keep references to those items at a
higher level so you can continue to number when you pop back out. Upon
popping, though, you can reset the deeper list ordinal. At least, that's
how I'd handle it.

What constitutes the end of an ordered list? Unordered lists are "dumb"
in that they just display their appropriate depth no matter what, but
the ordered lists need to keep track of that state. Does a non-list line
break the list? What about empty lines?

+ is this list

+ still counting

+ up to 3?


From solderpunk at SDF.ORG  Sat Jan 18 23:22:39 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 18 Jan 2020 23:22:39 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <d1c39345-1051-71db-2775-8dd2fa402b13@lavabit.com>
References: <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 <c683e092-dc5e-abd6-76f5-716e57b3185f@ratfactor.com>
 <20200118184530.GK4518@SDF.ORG>
 <dcea439b-15c4-4360-86a0-7cd786db0703@www.fastmail.com>
 <20200118213303.GN4518@SDF.ORG>
 <bddeeec4-5e79-415d-9b64-91d99b379457@www.fastmail.com>
 <d1c39345-1051-71db-2775-8dd2fa402b13@lavabit.com>
Message-ID: <20200118232239.GB29273@SDF.ORG>

On Sat, Jan 18, 2020 at 11:13:50PM +0000, James Tomasino wrote:
 
> What constitutes the end of an ordered list? Unordered lists are "dumb"
> in that they just display their appropriate depth no matter what, but
> the ordered lists need to keep track of that state. Does a non-list line
> break the list? What about empty lines?
> 
> + is this list
> 
> + still counting
> 
> + up to 3?

Argh, excellent question.  It seems like something vaguely like the
notion of a block has crept in!

This is a timely question, too.  I'm goofing around trying to implement
some of these new ideas in AV-98 (and so far I'm very pleased with the
results - # headers are made bold with ANSI escape codes, and unordered
lists get nice bullets and nice spacing, looks great!) and had to deal
with exactly this.  For testing I just decided that anything other than
an ordered list line breaks a list and resets the counter.  I'm open to
other ideas but I worry that anything other than this is liable to be
too complicated.

Cheers,
Solderpunk
 

From julien at typed-hole.org  Sat Jan 18 23:36:19 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sun, 19 Jan 2020 00:36:19 +0100
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200118232239.GB29273@SDF.ORG>
References: <20200118232239.GB29273@SDF.ORG>
Message-ID: <1226FC48-8721-4396-B306-8601007FE468@typed-hole.org>


> Le 19 janv. 2020 ? 00:22, solderpunk <solderpunk at sdf.org> a ?crit :
> 
> ?Argh, excellent question.  It seems like something vaguely like the
> notion of a block has crept in!
> 
> This is a timely question, too.  I'm goofing around trying to implement
> some of these new ideas in AV-98 (and so far I'm very pleased with the
> results - # headers are made bold with ANSI escape codes, and unordered
> lists get nice bullets and nice spacing, looks great!) and had to deal
> with exactly this.  For testing I just decided that anything other than
> an ordered list line breaks a list and resets the counter.  I'm open to
> other ideas but I worry that anything other than this is liable to be
> too complicated.
> 

Do we really need ordered lists? I?m not sure the what the use case is.
Couldn?t they be replaced by:
### 1. Foo
### 2. Bar
Or something like that if you really wanted numbers?

From sean at conman.org  Sat Jan 18 23:36:37 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 18 Jan 2020 18:36:37 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <739591427.21203.1579383267196@ichabod.co-bxl>
References: <739591427.21203.1579383267196@ichabod.co-bxl>
Message-ID: <20200118233637.GJ3354@brevard.conman.org>

It was thus said that the Great Brian Evans once stated:
> Aaron Janse writes:
> > Hmmm. It does seem, though, that *allowing* ANSI colors would require
> > non-terminal clients to strip ANSI colors, which would be a PITA,
> > expecially considering that ANSI is a hot mess (I built an ANSI parser
> > a while ago [1])
> 
> Currently Bombadillo has a few different modes. The normal mode removes 
> ansi escape codes. As I am parsing a document if I read an `\033` character I 
> just toggle an escape code boolean and then consume until I read a A-Za-z
> character (and consume that char as well). It works very quickly and handles
> removing them quite well. I do the same thing for the color mode for any
> escape codes that do not end in `m`. That said, it may not work as well for
> people not parsing by writing characters into a buffer char by char.

  Having written an ECMA-48 (the terminal control codes everybody calls ANSI
escape codes when they aren't defined by ANSI) parser you'll probably catch
99% of the control codes used.  But the actual definition is (RFC-5234 BNF):

	CSI   = %d27 '['
	      / %d155       ; ISO-8859-1 or similar
	      / %d194 %d155 ; UTF-8 encoding
	param = %d48-63     ; chars '0' through '?'
        meta  = %d32-47     ; chars ' ' through '/'
        cmd   = %d64-126    ; chars '@' through '~'

	sequence = CSI *param *meta cmd

  There are other ECMA-48 sequences that could prove dangerous if not
filtered for.  I do have Lua code to parse these [1][2] and use them in my
current gopher client to filter them out (and yes, I have come across sites
that embed ECMA-48 control codes).

> 2. Do a simple find and replace on the whole document for '\033' and replace
>     it with "ESC". While this will still leave the codes displaying to the viewer
>     they will not actually render, thus you do not need to worry about line
>      movement, screen clears, etc.

  You might want to replace the following codepoints to render control codes
harmless:

	0 - 31	; C0 set, except interpret the range from 7-13 inclusive
	127	; DEL
	128-159	; C1 set

I say codepoints because in UTF-8, the C1 set is represented by the
sequences

	194 128 through 194 129

-spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/iso/control.lua

	This handles encodings in ISO-8859-1 and similar.  I have a UTF-8
	one that is separate.  This one just returns the escape sequence as
	a unit with no further parsing of the actual sequence.

[2]	https://github.com/spc476/LPeg-Parsers/blob/master/iso/ctrl.lua

	This does a more complete parse of the escape sequence, to include
	its name (if any).  Again, This is for ISO-8859-1 and similar
	encodinds.  I have another version for UTF-8.

From tiwesdaeg at tilde.pink  Sat Jan 18 23:40:12 2020
From: tiwesdaeg at tilde.pink (tiwesdaeg at tilde.pink)
Date: Sat, 18 Jan 2020 23:40:12 +0000
Subject: What shall we call Gemini logs, anyway?
In-Reply-To: <20200118173048.GG4518@SDF.ORG>
References: <20200118173048.GG4518@SDF.ORG>
Message-ID: <20200118234012.r4f3ro2eempk6hez@tilde.pink>

On Sat, Jan 18, 2020 at 05:30:48PM +0000, solderpunk wrote:
> A post by tfurrows got me thinking about this:
> 
> gemini://consensus.circumlunar.space/blog/2019-10-24_geminiBlog.gmi
> 
> (tfurrows, if you're reading - that file is served up as text/plain,
> which breaks the link at the end!)
> 
> The web has blogs, gopher has phlogs, what should we call the Gemini
> equivalent?
> 
> As tfurrows mentions, a minority of phloggers prefer to use "glog" over
> "phlog", so that obvious candidate is taken.
> 
> The next thing that came to my mind is "gemlog", but that feels awkward
> to me because it's someone's username at SDF (and I follow them on
> Mastodon, too).  But I suppose most people won't recognise it as such.
> Maybe I'll ask how they'd feel about us using the term.
> 
> But does anybody have any other ideas?
> 
> Cheers,
> Solderpunk

I've been using the term gemlog, but I like the word gem and don't think
gemlog sounds awkward. I think glog sounds weird. It makes me think of
the word gl?gg.

Tiwesdaeg

From julien at typed-hole.org  Sun Jan 19 00:04:44 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sun, 19 Jan 2020 01:04:44 +0100
Subject: What shall we call Gemini logs, anyway?
In-Reply-To: <20200118173048.GG4518@SDF.ORG>
References: <20200118173048.GG4518@SDF.ORG>
Message-ID: <367CB83F-81E0-4E35-BAAF-B3C8D8EF63C8@typed-hole.org>

I used ?Flight Journal? for mine because gemlog reminds me too much of Ruby gems, but that?s not really something I would advise. glog sounds a bit weird too, at least when trying to pronounce it.
Looking at the Gemini program I found the word ?capsule?. What?s interesting is that in French it can mean ?a short column on a given subject? and I kinda like how it sounds.

From sean at conman.org  Sun Jan 19 00:10:19 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 18 Jan 2020 19:10:19 -0500
Subject: Color and other escape sequences in Gemini
Message-ID: <20200119001019.GK3354@brevard.conman.org>


  I'm seeing some people wanting to support some other formatting options
like color, leading to the support of ECMA-48 [1].  I would rather NOT see
this supported because of several issues.

1). Complexity.  The spec is rather complex and wide ranging.  There are 130
    escape codes (and I'm EXCLUDING those defined by ANSI, codes 0 through
    31).  If you are filtering them, then five or six cases (depending if
    you want to support one non-standard encoding used by xterm) need to be
    considered (which is still four or five more than most would expect).

2). Security.  Passing raw escape sequences can not only leave the termainal
    into an unknown state, but there are a few seqences that are especially
    alarming:

	DCS	Device Control String
	OSC	Operating System Command
	APC	Application Program Command

    which, if supported, are exactly what they say on the tin, and thus, you
    *don't* want these to be processed *at all*.  Personally, I haven't come
    across any terminal or program that supports these.

    Also, ANSI.SYS, originally for MS-DOS but maybe it still exists for
    Windows?  (I don't know, I don't use Windows) allows one to redefine any
    key on the keyboard to send a new sequence.  "DELTREE C:\*" anyone?

Below is the BNF (RFC-5234) for ECMA-48 control sequences:

	CSI      = %d27 '['
	         / %d155        ; ISO charset
	         / %d194 %d155  ; UTF-8
	OSC      = %d27 ']'
	         / %d157        ; ISO
	         / %d194 %d157  ; UTF-8
	ST       = %d27 '\'
	         / %d156        ; ISO
	         / %d194 %156   ; UTF-8
	string   = %d27 ( 'P' / 'X' / '^' / '_')
	         / (%d144 / %d152 / %d158 / %d159)       ; ISO
	         / %d194 (%d144 / %d152 / %d158 / %d159) ; UTF-8
	iso      = %d160-255
	
	; the utf8 rule is any UTF-8 codepoint 160 or higher

	sequence = CSI    *(%d48-63) *(%d32-47) %d64-126
                 / OSC    *(%d8-13 / %32-126 / iso / utf8) (ST / %d7)
                 / string *(%d8-13 / %32-126 / iso / utf8) ST
		 / %d27 (%d64-126)
	         / %d128-159         ; ISO
		 / %d194 (%d128-159) ; UTF-8

  If you are parsing an ISO charset (like ISO-8859-1) then remove the rules
marked UTF-8; similarly, if you are parsing UTF-8, then remove the rules
marked ISO.  

  -spc

[1]	The so called 'ANSI escape codes', which is funny because they're
	not defined by ANSI, but ISO, so of course they're called ECMA.


From aaron at ajanse.me  Sun Jan 19 00:14:27 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 18 Jan 2020 16:14:27 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <1226FC48-8721-4396-B306-8601007FE468@typed-hole.org>
References: <20200118232239.GB29273@SDF.ORG>
 <1226FC48-8721-4396-B306-8601007FE468@typed-hole.org>
Message-ID: <051fb7d9-f8c4-4d87-93b6-b6f70498d6ed@www.fastmail.com>

On Sat, Jan 18, 2020, at 3:36 PM, Julien Blanchard wrote:
> 
> > Le 19 janv. 2020 ? 00:22, solderpunk <solderpunk at sdf.org> a ?crit :
> > 
> > ?Argh, excellent question.  It seems like something vaguely like the
> > notion of a block has crept in!
> > 
> > This is a timely question, too.  I'm goofing around trying to implement
> > some of these new ideas in AV-98 (and so far I'm very pleased with the
> > results - # headers are made bold with ANSI escape codes, and unordered
> > lists get nice bullets and nice spacing, looks great!) and had to deal
> > with exactly this.  For testing I just decided that anything other than
> > an ordered list line breaks a list and resets the counter.  I'm open to
> > other ideas but I worry that anything other than this is liable to be
> > too complicated.
> > 
> 
> Do we really need ordered lists? I?m not sure the what the use case is.

Some use cases:

1. Instructions with step numbers. Yes, references to steps may need to be
   changed if items are items, but that's less work than replacing both
   references and the bullet markers themselves.
2. Listing things (e.g. problems), then referring to them by number ("but
   this once again causes problem #1")
3. "There are X ways to do this... <ordered list>"

I don't know what to do about spaces between ordered lists. If there's text
between items, I think manually-numbered sections should be used instead.

But if it's only newlines between items, I don't see why the count should be
restarted.

Cheers!

From julien at typed-hole.org  Sun Jan 19 00:24:59 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sun, 19 Jan 2020 01:24:59 +0100
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <051fb7d9-f8c4-4d87-93b6-b6f70498d6ed@www.fastmail.com>
References: <051fb7d9-f8c4-4d87-93b6-b6f70498d6ed@www.fastmail.com>
Message-ID: <BE5C740B-BEA4-41A0-BC05-AC103F1CD21C@typed-hole.org>

Sorry I wasn?t clear, I meant what would be the use case of showing them in a special way compared to headers with a number or plain text?

From tomasino at lavabit.com  Sun Jan 19 01:47:44 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 19 Jan 2020 01:47:44 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <BE5C740B-BEA4-41A0-BC05-AC103F1CD21C@typed-hole.org>
References: <051fb7d9-f8c4-4d87-93b6-b6f70498d6ed@www.fastmail.com>
 <BE5C740B-BEA4-41A0-BC05-AC103F1CD21C@typed-hole.org>
Message-ID: <6D0FC1A7-2676-4AE9-BB1B-D21E4FDA377A@lavabit.com>

-------- Original Message --------
From: Julien Blanchard <julien at typed-hole.org>

Sorry I wasn?t clear, I meant what would be the use case of showing them in a special way compared to headers with a number or plain text?
----

1. Listing things
2. Quick instructions where headers are overkill
3. Track listings
4. Top 10 lists
5. The same reasons we want bullets the reflow
6. Recipes!


And so on.


From b__m__e at mailfence.com  Sun Jan 19 19:15:14 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 19 Jan 2020 20:15:14 +0100 (CET)
Subject: FW: Text reflow woes (or: I want bullets back!)y
Message-ID: <574762512.1104.1579461314537@ichabod.co-bxl>

I've mostly been sitting back through all of this list and raw mode
talk, only occasionally popping in small points here or there. But
I figure if this is a community decision it is good if those in the community
voice their support or lack of support for ideas. 
 
I am mostly ambivalent about the need for a raw text mode. Terminals 
and any graphical clients (GTK, FLTK, Tcl/Tk) all wrap to the window at either
a hard or a word wrap. If we arent reflowing, then we are already doing what
needs to be done. There has been talk about not wrapping python code. Ok.
I get how that would look bad. But which is more readable:
      1. Hard-wrapped python code
      2. Truncated python code where you just straight up lose the content
Clearly #1. I get it as a nice thing for ascii art, but again I feel like using
ascii art is a risk a content creator takes... knowing that it may degrade
poorly on various output systems.
 
Tomasino writes:
> 1. Listing things
> 2. Quick instructions where headers are overkill
> 3. Track listings
> 4. Top 10 lists
> 5. The same reasons we want bullets the reflow
> 6. Recipes!
 
I think Tomasino's response to Julien, in plain text, just proved the _lack_ of 
need for lists.
 
Want a list? Write a list.... handled. I really really really do not see the point of 
adding all of this markup :-/ Just serve files as markdown if you want
markdown and let clients either support markdown or not. 
 
I really do not want to, and likely will not, add support for lists in my current
or any future gemini client I make. I don't see the point. 
 
I do appreciate all of the work and thought that has gone into trying to
figure these things out. It just feels unnecessary for a simple protocol
like gemini. Why get complex when just serving markdown or html or
whatever you like will do the job and people can read it as they see fit.
We are definitely starting to get into the territory with the proposals
where some client authors will support some things and some wont...
which will create a fractured view of gemini to users. So why not keep it
simple and cohesive by just having links and move on to other things?
 
Just my two cents at the moment.

From solderpunk at SDF.ORG  Sun Jan 19 20:01:23 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 19 Jan 2020 20:01:23 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <574762512.1104.1579461314537@ichabod.co-bxl>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
Message-ID: <20200119200123.GA7786@SDF.ORG>

On Sun, Jan 19, 2020 at 08:15:14PM +0100, Brian Evans wrote:

> I've mostly been sitting back through all of this list and raw mode
> talk, only occasionally popping in small points here or there. But
> I figure if this is a community decision it is good if those in the community
> voice their support or lack of support for ideas. 

It definitely is, if people who don't feel good about proposed changes
keep quiet and all I hear on the list is agreement it will just lead to
the most vocal members driving things.  I'm glad you've spoken up.

This will be a quick and kind of partial reply, sorry.  But, very
briefly, I understand the concern about lists (of all the recent
proposed changes, they are the least valuable IMHO because they only
concern presentation).  How do you feel about the heading proposals?
IMHO they are probably the most valuable of these changes because they
can be totally ignored from the perspective of presentation and yet
still do genuinely useful stuff, like automatically generated tables of
contents, which do nothing but make large and well-structured text
content easier to read, or help with automatic generation of
user-friendly menus or feeds to bodies of content.  That's good stuff,
surely?

> I really do not want to, and likely will not, add support for lists in my current
> or any future gemini client I make. I don't see the point. 

As I intend to actually write all this stuff in the spec, if I decide to
adopt it, supporting the list line types will be strictly optional, so
this is absolutely fine.  For a text-based client like Bombadillo, the
difference between supporting lists and not is an extremely small
aesthetic thing that some users probably won't even notice.

> I do appreciate all of the work and thought that has gone into trying to
> figure these things out. It just feels unnecessary for a simple protocol
> like gemini. Why get complex when just serving markdown or html or
> whatever you like will do the job and people can read it as they see fit.
> We are definitely starting to get into the territory with the proposals
> where some client authors will support some things and some wont...
> which will create a fractured view of gemini to users. So why not keep it
> simple and cohesive by just having links and move on to other things?

The fractured Geminispace thing is a real concern, but actually I think
an argument can be made in both ways here.  If text/gemini is kept
extremely simple and plain and the official policy is "Serve Markdown or
HTML if you want even basic text styling" then people may well do that.
Some clients will add support for rendering those but many won't because
it's so much more complicated (far worse than what has been proposed
here!).  Then we end up with two regions of Geminispace, the text/gemini
subspace which anybody can visit and the Markdown subspace which only
people using the fanciest clients can visit.  IMHO, this is a worse kind
of fracturing than one where we adopt the proposed new text/gemini
syntax and different clients implement different subsets of the optional
features.  After all, the only reason I've been so positive about these
recently proposed changes is that they all seem to degrade very
gracefully if a client doesn't recognise them and treats them equivalent
to text.  The degree of fracturing possible is actually very slight.

> Just my two cents at the moment.

One cent of opinion from client or server authors is valued equal to one
dollar of opinion from anybody else. :)

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jan 19 21:30:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 19 Jan 2020 21:30:35 +0000
Subject: What shall we call Gemini logs, anyway?
In-Reply-To: <367CB83F-81E0-4E35-BAAF-B3C8D8EF63C8@typed-hole.org>
References: <20200118173048.GG4518@SDF.ORG>
 <367CB83F-81E0-4E35-BAAF-B3C8D8EF63C8@typed-hole.org>
Message-ID: <20200119213035.GB7786@SDF.ORG>

On Sun, Jan 19, 2020 at 01:04:44AM +0100, Julien Blanchard wrote:
> I used ?Flight Journal? for mine because gemlog reminds me too much of Ruby gems, but that?s not really something I would advise. glog sounds a bit weird too, at least when trying to pronounce it.
> Looking at the Gemini program I found the word ?capsule?. What?s interesting is that in French it can mean ?a short column on a given subject? and I kinda like how it sounds.

The "capsule" idea was proposed earlier on (I forget by who, sorry!).  I
kind of like it, but I've come to think of it as a slightly more general
term, like "gopherhole" - i.e. it doesn't actually imply regular
updates.

I asked the Gemlog I know how he felt about us using "gemlog" in this
context and he had no objections!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jan 19 22:18:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 19 Jan 2020 22:18:26 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200119200123.GA7786@SDF.ORG>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG>
Message-ID: <20200119221826.GC7786@SDF.ORG>

On Sun, Jan 19, 2020 at 08:01:23PM +0000, solderpunk wrote:
 
> The fractured Geminispace thing is a real concern, but actually I think
> an argument can be made in both ways here.  If text/gemini is kept
> extremely simple and plain and the official policy is "Serve Markdown or
> HTML if you want even basic text styling" then people may well do that.
> Some clients will add support for rendering those but many won't because
> it's so much more complicated (far worse than what has been proposed
> here!).  Then we end up with two regions of Geminispace, the text/gemini
> subspace which anybody can visit and the Markdown subspace which only
> people using the fanciest clients can visit.  IMHO, this is a worse kind
> of fracturing than one where we adopt the proposed new text/gemini
> syntax and different clients implement different subsets of the optional
> features.  After all, the only reason I've been so positive about these
> recently proposed changes is that they all seem to degrade very
> gracefully if a client doesn't recognise them and treats them equivalent
> to text.  The degree of fracturing possible is actually very slight.

Oh, there was also the argument made at some point that if Gemini
doesn't have any standardised syntax for these common formatting tasks,
ambitious clients might start trying to recognise the most popular
non-standard ways of doing it, which could easily lead to divergent
implementations across clients.  So, better to provide a standard way to
do to provide us control and uniformity.

I don't mean to claim either of these arguments are bulletproof, I just
think that a principle of "we shouldn't do anything that risks
fragmentation of Geminispace" (which is obviously a good principle)
necessarily comes down clearly on one side of this question or the
other.

Cheers,
Solderpunk

From lazar.michael22 at gmail.com  Mon Jan 20 02:01:17 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sun, 19 Jan 2020 21:01:17 -0500
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200119221826.GC7786@SDF.ORG>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
Message-ID: <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>

I think there have been a lot of good suggestions coming from all sides. Here's
my take on a compromised format that tries to take everything into account while
also inserting a few of my own opinions:

Parser pseudo-code (actually, it's valid python):

```
preformat_mode = False
preformat_buffer = []
for line in document:
    if line.startswith('```'):
        if not preformat_mode:
            # Start preformat block
            preformat_mode = True
            preformat_buffer = []
        else:
            # End preformat block
            preformat_mode = False
            display_preformat_block(preformat_buffer)
    elif preformat_mode:
        # Inside of preformat block
        preformat_buffer.append(line)
    elif line.startswith('###'):
        display_header_level_3(line)
    elif line.startswith('##'):
        display_header_level_2(line)
    elif line.startswith('#'):
        display_header_level_1(line)
    elif line.startswith('=>'):
        display_link(line)
    elif line.startswith('---'):
        display_horizontal_rule()
    else:
        display_paragraph(line)

if preformat_mode:
    # Flush the preformat block if there was no end tag
    add_preformat_block(preformat_buffer)
```

This pseudo-code was written with "fancy" gemini clients in mind. In other
words, this should be close to the worst-case scenario for how complicated a
gemini document parser would ever need to be.

## Preformat mode

Many clients are going to want to display a preformat block of text in a
horizontally scrollable window or some other type of block widget. This
pseudo-code reflects that by sticking the pre-formatted lines in a separate
buffer until the end of the block. I think this is a more accurate
representation of what most client parsers would end up looking like.

## Headers

I'm of the opinion that there should only be a fixed number of header levels.
It keeps the matching logic flat and straightforward. Three levels is few
enough that most clients should be able to come up with distinct styles to
display them. Fixed header lines are trivial to parse and provide a lot of
utility for organizing a document and linking to sub-sections.

### Ordered Lists & Unordered Lists

Lists are tricky because while they would be nice to have, the complicate the
parsing significantly. In order to parse a list while preserving its semantic
structure, you will need to keep track of where it starts and ends. Nested
lists complicate this even further, no matter which syntax for nesting is used.

Parsing lists semantically would require keeping a separate buffer for each type
of list, and then keeping flags and making sure that these buffers are flushed
after the last element in the list. Because of this, I do not believe that they
pass the power-to-weight ratio smell test.

For authors, they still have a few choices for lists:

1. Stick the list in a preformat block
2. Write the list in plain mode without special formatting

I accept that neither of these options is *ideal* for all use cases, but I
think they are *good enough* for most use cases. Don't forget that unicode
bullets can already be added directly in gemini documents if the author
wishes to do so.

### Quotes

Quote blocks with ">" would be ok if we could count on them being only a single
line long. However, many quotes will necessarily include line breaks that
should be displayed together in a single block. This complicates parsing in the
same way that lists do, so I think that quotes should also be omitted for the
same reason.

If you want to display something like a quote from a mailing list message, I
think that would be a perfect candidate for copying it into a preformat
block. For other types of quotes, stick them between two horizontal rules to
separate them from the surrounding text.

### Horizontal Rule

I find the horizontal rule useful for separating sections of a page. I see them
commonly use on gopher to add a footer to the bottom. They can likewise be
used for header sections.

```
Header
---
Content
---
Footer
```

The following gemini sites already use some form of horizontal separator on
their front pages (the precise syntax varies):

- gemini://vger.cloud/
- gemini://gemini.conman.org/
- gemini://zaibatsu.circumlunar.space/
- gemini://carcosa.net/
- gemini://yam655.com/

I think that since horizontal rules are easy to parse and they add utility for
structuring pages, they should be included in the spec.

### Other Random Opinions

- Leading and trailing whitespace should be stripped from all of lines outside
  of the preformat block. If you're allowing a non-monospace font for these
  elements, then leading whitespace can look inconsistent and trailing
  whitespace serves no real purpose. By leading whitespace, I mean that

##     heading text

  Should be interpreted as "heading text", not "     heading text".
- I have no opinion on whether the ``` should allow text after it on the same
  line.

I think I would be satisfied enough with the above document to at least try it
out by converting all of my existing gemini content. I also think I would be
fine keeping everything fixed-width and hard wrapping. I *don't* think I would
want to implement nested lists or quote blocks, or anything significantly more
complicated than what is outlined above.

- mozz

From solderpunk at SDF.ORG  Mon Jan 20 09:58:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 20 Jan 2020 09:58:33 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <574762512.1104.1579461314537@ichabod.co-bxl>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
Message-ID: <20200120095833.GA13472@SDF.ORG>

On Sun, Jan 19, 2020 at 08:15:14PM +0100, Brian Evans wrote:

I've been thinking more about lists and, while I understand the concern
about maintaining simplicity, I really do think that:

> I think Tomasino's response to Julien, in plain text, just proved the _lack_ of 
> need for lists.
>  
> Want a list? Write a list.... handled.

is a bit too simplistic.  Tomasino's response consisted entirely of
short list items which didn't require wrapping, and also happened in a
plain text email, which is a hard wrapping environment and so not
comparable to a "long line" text/gemini document.

In Gopherspace, it's very common for people writing lists to format
multi-line list items "nicely", e.g. people write this:

---
* To demonstrate endurance of humans and equipment in spaceflight for
  extended periods, at least eight days required for a Moon landing,
  to a maximum of two weeks
* To effect rendezvous and docking with another vehicle, and to maneuver
  the combined spacecraft using the propulsion system of the target
  vehicle
* To demonstrate Extra-Vehicular Activity (EVA), or space-"walks"
  outside the protection of the spacecraft, and to evaluate the
  astronauts' ability to perform tasks there
* To perfect techniques of atmospheric reentry and touchdown at a
  pre-selected location on land
---

In preference to this:

---
* To demonstrate endurance of humans and equipment in spaceflight for
extended periods, at least eight days required for a Moon landing,
to a maximum of two weeks
* To effect rendezvous and docking with another vehicle, and to
maneuver the combined spacecraft using the propulsion system of
the target vehicle
* To demonstrate Extra-Vehicular Activity (EVA), or
space-"walks" outside the protection of the spacecraft, and
to evaluate the astronauts' ability to perform tasks there
* To perfect techniques of atmospheric reentry and
touchdown at a pre-selected location on land
---

I had worried, before writing this, that perhaps I was a lone weirdo for
caring about this, but didn't have to search too far to find examples of
others doing it, e.g.
gopher://zaibatsu.circumlunar.space:70/0/~tfurrows/phlog/2020-01-16_worldEndingStuff.txt

Now, this nice list formatting is simple and easy in a hard-wrapping
environment with fixed line width.  In a long line environment where
clients wrap the line to the appropriate length, and the appropriate
length is different for everybody, it's impossible for a content
author to ensure readers get the first, nicer style of list
formatting.  As a consequence of client wrapping, we get stuck with the
second.

For lists of short items, there is no difference.

Some might argue that this really doesn't matter and isn't worth adding
complicating features for.  But the fact that people writing for Gopher
take the time to do the nice formatting suggests people actually care
about this.  And I don't think it's purely a matter of vanity and
wanting our content to simply look pretty - if that's what we wanted, we
wouldn't be writing for gopher!  I actually think the nicer list
formatting makes for a genuinely better reading experience.  The list is
much more easily and immediately recognisable as a list and it's much
easier for the eyes to parse out the separate list items.  This really
is a functional thing, I think.  A small one, I grant you, but a real
one.  It would be a shame if Gemini content had to be in some ways
harder to read than Gopher content, and ironic if that happened as a
result of the decision to have clients wrap lines to fit the viewport
neatly in order to ensure a better reading experience for everyone!

After thinking about this I am more convinced than I was yesterday that
having some defined markup for lists is worthwhile.  That said, I'm
becoming rapidly less convinced about *nested* lists, especially
without a limit on the permitted level of nesting.  More on that when I
reply to Michael's recent email, which will probably be much later
today.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Mon Jan 20 10:28:56 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 20 Jan 2020 10:28:56 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
Message-ID: <20200120102856.GA4819@SDF.ORG>

Just a quick response for now: nice post, thanks, there's a lot in here
that I agree with (and I had been starting to think similar things about
quotes), but can I ask you to elaborate on:

On Sun, Jan 19, 2020 at 09:01:17PM -0500, Michael Lazar wrote:
 
> Lists are tricky because while they would be nice to have, the complicate the
> parsing significantly. In order to parse a list while preserving its semantic
> structure, you will need to keep track of where it starts and ends. Nested
> lists complicate this even further, no matter which syntax for nesting is used.
> 
> Parsing lists semantically would require keeping a separate buffer for each type
> of list, and then keeping flags and making sure that these buffers are flushed
> after the last element in the list. Because of this, I do not believe that they
> pass the power-to-weight ratio smell test.

In particular, what do you mean by "parsing lists semantically"?

At no point in these discussions have I been envisaging anything to do
with lists which requires clients to recognise or keep track of whether
or not they are "inside" a list or not, or sticking lists in buffers.
I have imagined list items standing alone and "lists" being an emergent
property of a document that clients have no awareness of - in exactly
the same way that "paragraphs" are an emergenty property of lines (if
some of those lines happen to be blank).

Well, that's true for unordered lists, at least.  Ordered lists are
another story 

Cheers,
Solderpunk

From tomasino at lavabit.com  Mon Jan 20 12:09:01 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 20 Jan 2020 12:09:01 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200120102856.GA4819@SDF.ORG>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
Message-ID: <ea028ed5-5d3f-72cb-1642-6977d59e4f31@lavabit.com>

On 1/20/20 10:28 AM, solderpunk wrote:
> Well, that's true for unordered lists, at least.  Ordered lists are
> another story 

Ordered lists are--so far--the only thing that really does break the
linear line-by-line processing approach. If they are sacrificed to the
gods of a cleaner spec, I for one wouldn't cry too much. Unordered lists
that support reflow is the more important bit. One could always cheat
and just use unordered lists and start each one with a number:

* 1) item one!
* 2) A really long item two that will be wonderfully reflowed on small
screens by our awesome client writers.
** 2a) I'm lookin' at you, Michael!
** 2b) And the rest of you too. ;)

Saves us a bit o' logic. Keeps everything line based. You could run a
stateless renderer on a stream now and it wouldn't choke.


From solderpunk at SDF.ORG  Mon Jan 20 12:32:30 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 20 Jan 2020 12:32:30 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <ea028ed5-5d3f-72cb-1642-6977d59e4f31@lavabit.com>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
 <ea028ed5-5d3f-72cb-1642-6977d59e4f31@lavabit.com>
Message-ID: <20200120123230.GB16971@SDF.ORG>

On Mon, Jan 20, 2020 at 12:09:01PM +0000, James Tomasino wrote:
 
> One could always cheat
> and just use unordered lists and start each one with a number:
> 
> * 1) item one!
> * 2) A really long item two that will be wonderfully reflowed on small
> screens by our awesome client writers.
> ** 2a) I'm lookin' at you, Michael!
> ** 2b) And the rest of you too. ;)
> 
> Saves us a bit o' logic. Keeps everything line based. You could run a
> stateless renderer on a stream now and it wouldn't choke.

This has two other advantages, too.  First, when processed by a simple
client which opts not to treat list items as anything special, the
result is still obviously an ordered list.  Under the + proposal, it
will look just like an unordered list whose author chose a different
bullet character for reasons of taste.  Ambiguous degredation is not
graceful degredation!

Second, authors can unambiguously refer back to a list item in later
writing.  I can say "Tomasino used a winky face in item 2b above" and
you can all go back and find 2b and confirm this.  If I said that and
you were using a simple client that just rendered + and ++, it would
be up to you to mentally figure out which point was 2b.  And even if
you're using an advanced client that does render ordered lists, I
might write "2b" but your fancy client might use Roman numerals for
second level lists and print 2ii instead of 2b, and again the
connection wouldn't be immediate.  This could only be solved by
tediously specifying that first level lists MUST use Arabic numerals,
second level lists MUST use lowercase letters, third level lists MUST
use Roman numerals, and so on and so on.  And then what happens when
somebody uses more than 26 second level list items and we run out of
lowercase letters to use?

A spec that can avoid all these problems will be exactly the kind of
long, tedious, fiddly spec that I really don't want us to use, and which
nobody will want to code to anyway.  I'm starting to think we should
either drop the ordered list idea, or at the very least strictly limit
it to one level with no nesting.

Cheers,
Solderpunk

From lazar.michael22 at gmail.com  Mon Jan 20 17:30:14 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Mon, 20 Jan 2020 12:30:14 -0500
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200120102856.GA4819@SDF.ORG>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
Message-ID: <CAFTy05aCw+LVwmbw+P=b-xw167o76GEc1+_SgUSvTwSmc=MgtQ@mail.gmail.com>

On Mon, Jan 20, 2020 at 5:29 AM solderpunk <solderpunk at sdf.org> wrote:
>
> Just a quick response for now: nice post, thanks, there's a lot in here
> that I agree with (and I had been starting to think similar things about
> quotes), but can I ask you to elaborate on:
>
> On Sun, Jan 19, 2020 at 09:01:17PM -0500, Michael Lazar wrote:
>
> > Lists are tricky because while they would be nice to have, the complicate the
> > parsing significantly. In order to parse a list while preserving its semantic
> > structure, you will need to keep track of where it starts and ends. Nested
> > lists complicate this even further, no matter which syntax for nesting is used.
> >
> > Parsing lists semantically would require keeping a separate buffer for each type
> > of list, and then keeping flags and making sure that these buffers are flushed
> > after the last element in the list. Because of this, I do not believe that they
> > pass the power-to-weight ratio smell test.
>
> In particular, what do you mean by "parsing lists semantically"?
>
> At no point in these discussions have I been envisaging anything to do
> with lists which requires clients to recognise or keep track of whether
> or not they are "inside" a list or not, or sticking lists in buffers.
> I have imagined list items standing alone and "lists" being an emergent
> property of a document that clients have no awareness of - in exactly
> the same way that "paragraphs" are an emergenty property of lines (if
> some of those lines happen to be blank).

By "parsing lists semantically" I mean that if I build an AST, I want all of
the list items grouped together inside of single list object. This is how I
did it when I was playing around with markdown a while ago [0]. From my
research this seems to be the common way to do it [1].

Sophisticated gemini clients could utilize this is a variety of ways. Maybe
you want to add a little bit of extra whitespace surrounding the list. Or you
want to make sure that the your display does not cut-off half way through the
list. Or you want to support re-ordering list items alphabetically. I don't
know, the sky is the limit.

I'm willing to admit that HTML has perhaps tainted my thinking here, but it
just feels *wrong* to me to have an <li> without the surrounding <ul>. Doing
the same thing with "paragraphs" (i.e. each line is a new paragraph) doesn't
feel wrong in the same way. I just have a hard time mentally getting past it.

If I understand correctly, the main argument that I'm hearing in favor of
unordered lists is so that users can visually distinguish the first line of
the list from subsequent lines that have been wrapped by the client. I can
emphasize with this. Bullet lists have been called out because they're an
obvious example of where this is painful. But this might be a more generalized
problem. For example, a poem will have deliberate line breaks, but you would
also like your poem to be wrapped by the client.

What if I were to say this:

When a client is wrapping a line longer than the viewport, the client may chose
to add indents or other visual indicators to distinguish the beginning of the
line from a continuation line. The simplest way to do this would be by adding a
hanging indent to continuation lines.

Expanding on my previous code example:

```
def display_paragraph(line):
    # Strip leading and trailing whitespace
    line = line.strip()

    initial_indent = ''
    subsequent_indent = '    '
    wrapped_text = textwrap.wrap(line, initial_indent, subsequent_indent)
    for line in wrapped_text:
        print(line)
```

If we generalize this to all lines, we don't need to handle list items as a
special case. Is there anything that this would break?

[0] gemini://mozz.us/markdown/design_document.json
[1] https://github.com/syntax-tree/mdast#list

- mozz

From aaron at ajanse.me  Mon Jan 20 18:17:28 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Mon, 20 Jan 2020 10:17:28 -0800
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200120123230.GB16971@SDF.ORG>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
 <ea028ed5-5d3f-72cb-1642-6977d59e4f31@lavabit.com>
 <20200120123230.GB16971@SDF.ORG>
Message-ID: <93ad675f-ca9c-45a0-bd0a-c51cee8b038e@www.fastmail.com>

> I'm of the opinion that there should only be a fixed number of header levels.
> It keeps the matching logic flat and straightforward. Three levels is few
> enough that most clients should be able to come up with distinct styles to
> display them. Fixed header lines are trivial to parse and provide a lot of
> utility for organizing a document and linking to sub-sections.

I like that this would discourage the "markdown hacking" seen on GitHub where
unnecessary depth is used to make the HTML render look nicer.

OTOH, it would be easy for authors to:
* rotate header colors
* use the same colors for depth 4+ that they use for depth 3

> Quote blocks with ">" would be ok if we could count on them being only a single
> line long. However, many quotes will necessarily include line breaks that
> should be displayed together in a single block. This complicates parsing in the
> same way that lists do, so I think that quotes should also be omitted for the
> same reason.

I'm strongly against reflowing quote blocks. I understand that we don't want
to display lists inside quotes in a fancy way, but I still think that we
shouldn't break them:

```
> My opinion:
> * these lines
> * should not be
> * reflowed
```

Speaking of which, should we explicitly disallow fancy-rendering lists within
quotes, or leave the choice up to client authors?

> If you want to display something like a quote from a mailing list message, I
> think that would be a perfect candidate for copying it into a preformat
> block. For other types of quotes, stick them between two horizontal rules to
> separate them from the surrounding text.

Maybe. I still don't like the idea of quotes not wrapping with display width.

> And then what happens when
> somebody uses more than 26 second level list items and we run out of
> lowercase letters to use?

Simply use multiple letters:

```
a. lorem ipsum
b. lorem ipsum
[...]
y. lorem ipsum
z. lorem ipsum
aa. lorem ipsum
ab. lorem ipsum
ac. lorem ipsum
```

However, this may be complex. I'll try to write a simple client tonight to see
how difficult all this is.

Cheers!

From solderpunk at SDF.ORG  Mon Jan 20 19:48:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 20 Jan 2020 19:48:33 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <CAFTy05aCw+LVwmbw+P=b-xw167o76GEc1+_SgUSvTwSmc=MgtQ@mail.gmail.com>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
 <CAFTy05aCw+LVwmbw+P=b-xw167o76GEc1+_SgUSvTwSmc=MgtQ@mail.gmail.com>
Message-ID: <20200120194833.GA15749@SDF.ORG>

On Mon, Jan 20, 2020 at 12:30:14PM -0500, Michael Lazar wrote:
 
> By "parsing lists semantically" I mean that if I build an AST, I want all of
> the list items grouped together inside of single list object. This is how I
> did it when I was playing around with markdown a while ago [0]. From my
> research this seems to be the common way to do it [1].
> 
> Sophisticated gemini clients could utilize this is a variety of ways. Maybe
> you want to add a little bit of extra whitespace surrounding the list. Or you
> want to make sure that the your display does not cut-off half way through the
> list. Or you want to support re-ordering list items alphabetically. I don't
> know, the sky is the limit.

Got it, thanks for clarifying.

We'll never be able to stop people going nuts and defining their own
structure on top of the official structure in the spec if they really
want to, but I think if the official spec can define a perfectly flat
structure (such that actually building an AST is unnecessary) which is
rich enough to take care of the most compelling styling that's needed to
achieve good readability, then that's absolutely fine.  There's no need
to have a concept of a list encapsulating consecutive list items in
order to implement the clean formatting I discussed previously, so I
think we can do without it.  It might feel weird compared to HTML or
LaTeX, but if it works, where's the problem?  I think this is how lists
work in common troff macros, actually, but I can't swear to it.
 
> I'm willing to admit that HTML has perhaps tainted my thinking here, but it
> just feels *wrong* to me to have an <li> without the surrounding <ul>. Doing
> the same thing with "paragraphs" (i.e. each line is a new paragraph) doesn't
> feel wrong in the same way. I just have a hard time mentally getting past it.

In the rough spec I sent around for this line-oriented syntax, each line
*isn't* a new paragraph in any meaningful sense.  If you want vertical
whitespace between two parts of text which correspond to different lines
before wrapping, you need to put a blank line in between them.  This
facilitatess things like
one
word
per
line
for emphasis, acrostic poems, etc.

> When a client is wrapping a line longer than the viewport, the client may chose
> to add indents or other visual indicators to distinguish the beginning of the
> line from a continuation line. The simplest way to do this would be by adding a
> hanging indent to continuation lines.

Hmm.  An elegant idea, but I guess it would look quite strange for
ordinary text?

> Expanding on my previous code example:
> 
> ```
> def display_paragraph(line):
>     # Strip leading and trailing whitespace
>     line = line.strip()
> 
>     initial_indent = ''
>     subsequent_indent = '    '
>     wrapped_text = textwrap.wrap(line, initial_indent, subsequent_indent)
>     for line in wrapped_text:
>         print(line)
> ```

Aah!!!  I hadn't noticed that initial_indent, subsequent_indent feature
of textwrap.wrap.  That makes handling unordered list items in the
proposed way absolutely trivial!

def display_unordered_list_item(line):
    # Strip * and any whitespace
    line = line[1:].strip()
    print(textwrap.fill(line, viewportwidth-2, "* ", " ")

Cheers,
Solderpunk

From aaron at ajanse.me  Mon Jan 20 19:53:51 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Mon, 20 Jan 2020 11:53:51 -0800
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200120194833.GA15749@SDF.ORG>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
 <CAFTy05aCw+LVwmbw+P=b-xw167o76GEc1+_SgUSvTwSmc=MgtQ@mail.gmail.com>
 <20200120194833.GA15749@SDF.ORG>
Message-ID: <d8df4e72-3ebf-4e6f-8714-04677d5fbac9@www.fastmail.com>

Attached is a <100 line python gemini renderer with the following features:
* no external dependencies
* only two state variables
* unlimited-depth ordered lists that rotates through
  * numbers
  * letters (does `az` after `z`, `aaa` after `zz`, etc)
  * roman numerals
* unlimited-depth unordered lists
* unlimited-depth headers with rotating colors
* wraps at word boundaries, with fancy indents for lists and quotes
* colors for all special syntax
* horizontal rules that span the width of the display
* preformatted text
* links

To use this script, pipe text/gemini into stdin.

I hope this makes a strong case that these features aren't too complex to
implement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gemini.py
Type: text/x-python
Size: 2501 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200120/40ce994f/attachment-0001.py>

From aaron at ajanse.me  Mon Jan 20 19:58:09 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Mon, 20 Jan 2020 11:58:09 -0800
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <d8df4e72-3ebf-4e6f-8714-04677d5fbac9@www.fastmail.com>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
 <CAFTy05aCw+LVwmbw+P=b-xw167o76GEc1+_SgUSvTwSmc=MgtQ@mail.gmail.com>
 <20200120194833.GA15749@SDF.ORG>
 <d8df4e72-3ebf-4e6f-8714-04677d5fbac9@www.fastmail.com>
Message-ID: <77ddcd88-80c0-42c2-ae66-3189ce693148@www.fastmail.com>

Whoops, I forgot to reset the list counter. Fixed version attached.

Still < 100 lines of code, including empty lines.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gemini.py
Type: text/x-python
Size: 2511 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200120/da535619/attachment.py>

From solderpunk at SDF.ORG  Mon Jan 20 21:26:52 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 20 Jan 2020 21:26:52 +0000
Subject: FW: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <d8df4e72-3ebf-4e6f-8714-04677d5fbac9@www.fastmail.com>
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 <CAFTy05YRbZGO2q0fE4wA3vF4M9dQV7g2H4CrScDKnnrcOHxuAg@mail.gmail.com>
 <20200120102856.GA4819@SDF.ORG>
 <CAFTy05aCw+LVwmbw+P=b-xw167o76GEc1+_SgUSvTwSmc=MgtQ@mail.gmail.com>
 <20200120194833.GA15749@SDF.ORG>
 <d8df4e72-3ebf-4e6f-8714-04677d5fbac9@www.fastmail.com>
Message-ID: <20200120212652.GA5988@SDF.ORG>

Thanks for taking the time to write this!

There are a few details that could be nitpicked (e.g. a lot of this code
seems to assume that *s or #s at the start of lines are followed by
whitespace, which hasn't been specced), but I'm totally happy that this
code is representative of the complexity involved in handling everything
proposed so far.

If a bare-minimum renderer implementing only the compulsory core line
types can be done in ~10 lines and a full-strength renderer implementing
everything to the max can be done in ~100 lines then I'm totally happy
with that - in terms of implementation difficulty.

I still want to think very carefully about graceful degradation, to make
sure those ~10 line renderers still yield usable results.  I still have
real concerns about ordered lists in that regard.

Cheers,
Solderpunk



On Mon, Jan 20, 2020 at 11:53:51AM -0800, Aaron Janse wrote:
> Attached is a <100 line python gemini renderer with the following features:
> * no external dependencies
> * only two state variables
> * unlimited-depth ordered lists that rotates through
>   * numbers
>   * letters (does `az` after `z`, `aaa` after `zz`, etc)
>   * roman numerals
> * unlimited-depth unordered lists
> * unlimited-depth headers with rotating colors
> * wraps at word boundaries, with fancy indents for lists and quotes
> * colors for all special syntax
> * horizontal rules that span the width of the display
> * preformatted text
> * links
> 
> To use this script, pipe text/gemini into stdin.
> 
> I hope this makes a strong case that these features aren't too complex to
> implement.

> #!/usr/bin/env python3
> 
> import sys
> import textwrap
> 
> def int2roman(number):
>     numerals = { 1 : "I", 4 : "IV", 5 : "V", 9 : "IX", 10 : "X", 40 : "XL", 
>         		 50 : "L", 90 : "XC", 100 : "C", 400 : "CD", 500 : "D",
>         		 900 : "CM", 1000 : "M" }
>     result = ""
>     for value, numeral in sorted(numerals.items(), reverse=True):
>         while number >= value:
>             result += numeral
>             number -= value
>     return result
> 
> width = 80
> 
> # only two state variables
> preformatted = False
> list_counter = [0]
> 
> for line in sys.stdin:
> 	if line.startswith('```'):
> 		preformatted = not preformatted
> 		continue
> 
> 	if preformatted:
> 		print('\033[37m'+line+'\033[m', end='')
> 		continue
> 
> 	line = line.rstrip()
> 
> 	if line.startswith('=>'):
> 		parts = line[2:].strip().split(maxsplit=1)
> 		print('\033[36m'+parts[0]) # url
> 		print(parts[1]+'\033[m') # text
> 	elif line.startswith('#'):
> 		parts = line.split(maxsplit=1)
> 		depth = len(parts[0]) - 1
> 		colors = ['31', '93', '92', '34']
> 		color = colors[depth % len(colors)]
> 		print('\033['+color+'m'+line+'\033[m')
> 	elif line.startswith('*'):
> 		parts = line.split(maxsplit=1)
> 		depth = len(parts[0])
> 		text = textwrap.fill(parts[1], width)
> 		text = textwrap.indent(text, ' '*(2*depth)).lstrip()
> 		print(2*(depth-1)*' '+'\033[93m???\033[m '+text)
> 	elif line.startswith('+'):
> 		list_counter = list_counter if len(list_counter) > 0 else [0]
> 
> 		parts = line.split(maxsplit=1)
> 		depth = len(parts[0])
> 
> 		if depth > len(list_counter):
> 			list_counter += [0]
> 		elif depth < len(list_counter):
> 			list_counter = list_counter[:depth]
> 
> 		assert len(list_counter) == depth
> 
> 		marker = ''
> 
> 		counter_type = (len(list_counter) - 1) % 3
> 		list_counter[-1] += 1
> 		count = list_counter[-1]
> 		if counter_type == 0:
> 			marker = str(count)
> 		elif counter_type == 1:
> 			while True:
> 				count -= 1
> 				marker = chr(97+(count%26)) + marker
> 				count = count // 26
> 				if count == 0:
> 					break
> 		else:
> 			marker = int2roman(count)
> 
> 		text = textwrap.fill(parts[1], width)
> 		text = textwrap.indent(text, ' '*(3*depth)+' '*(len(marker)-1)).lstrip()
> 		print('\033[93m'+(depth-1)*3*' ' + marker + '. \033[m' + text)
> 	elif line.startswith('>'):
> 		depth = 0
> 		while True:
> 			if line.startswith('>'):
> 				line = line[1:].lstrip()
> 				depth += 1
> 			else:
> 				break
> 		text = textwrap.fill(line, width)
> 		text = textwrap.indent(text, '\033[93m>\033[m '*depth)
> 		print(text)
> 	elif line.startswith('---'):
> 		print('\033[37m'+'-'*width+'\033[m')
> 	else:
> 		print(textwrap.fill(line, width))
> 


From jmcbray at carcosa.net  Tue Jan 21 15:01:31 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 21 Jan 2020 10:01:31 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200116202652.GA23953@SDF.ORG> (solderpunk@sdf.org's message of
 "Thu, 16 Jan 2020 20:26:52 +0000")
References: <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <20200116202652.GA23953@SDF.ORG>
Message-ID: <87wo9kdfas.fsf@cassilda.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> Hmm. Neither do I and, in fact, well...I just do it manually. Which I
> feel very sheepish admitting because that's kind of ridiculous. But
> everybody writing for Gopherspace (which is many people here) must
> face precisely this problem, because hard-wrapping is basically
> compulsory there. What are other people doing, writing in "long line"
> form and then feeding the result to `fmt` or `par` before uploading?

I use Emacs. I set fill-column to 72 characters, and turn on
auto-fill-mode. This means that things get hard wrapped while I am
writing. You can reflow a paragraph with one key: M-q, mapped to
fill-paragraph or unfill-toggle. I'm normally writing Markdown, which
will get converted to HTML for my static blog, or served raw on my
gopherhole. 

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Tue Jan 21 15:17:46 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 21 Jan 2020 10:17:46 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200117133312.GA7402@SDF.ORG> (solderpunk@sdf.org's message of
 "Fri, 17 Jan 2020 13:33:12 +0000")
References: <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
Message-ID: <87sgk8dejp.fsf@cassilda.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> There is another option that I hadn't thought about until now, which
> is to do only the first half of 2. above.  That is, lines longer than
> the viewport get broken up nicely at word boundaries into lines of
> length equal to or less than the viewport width - but that's it.
> Consecutive shorter lines are *not* joined together.  Blank lines in
> the "source" are rendered, one by one, into empty vertical space.
> The renderer has no explicit concept of a paragraph.

If 'paragraphs' are always written as continuous long lines, this works.
If they get written as hard-wrapped 80-column lines, then you get the
existing issue on narrow displays. So specifying this implementation of
wrapping is also a recommendation to authors to write paragraphs as
continuous long lines, I guess.

It's not bad. It preserves quality 1 (ease of implementation) and 2
(some richness allowed by literal text formatting), and *may* get you 3
most of the time, as long as authors comply with the recommendation.

I'd recommend, if you go with this, to not also include the ``` literal
formatting. There's going to be a breakpoint of complexity somewhere
where text/gemini will not do the job you want it to, and you should be
serving text/markdown or even text/html.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Tue Jan 21 15:30:43 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 21 Jan 2020 10:30:43 -0500
Subject: Adding a content size meta?
In-Reply-To: <20200118185749.GL4518@SDF.ORG> (solderpunk@sdf.org's message of
 "Sat, 18 Jan 2020 18:57:49 +0000")
References: <382432062.15242.1579370306771@ichabod.co-bxl>
 <20200118185749.GL4518@SDF.ORG>
Message-ID: <87lfq0ddy4.fsf@cassilda.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> I guess the question is whether we prefer adding this information into
> the response header and having clients do the request-and-terminate
> trick, or defining a well-known endpoint servers can implement which
> takes a path as an input and returns either what the response header
> would be, or maybe a small JSON structure of metadata (which could
> include stuff like last-modified date).

Personally, I feel like request-and-terminate is the better approach;
it's easier on server developers to correctly handle dropped connections
(which you have to do anyway), as opposed to implementing a separate
route for dynamically-generated metadata responses. I'm strongly against
returning JSON metadata, because it opens the door to unlimited
extensibility.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From tomasino at lavabit.com  Tue Jan 21 16:08:13 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 21 Jan 2020 16:08:13 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <87wo9kdfas.fsf@cassilda.carcosa.net>
References: <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 <CAFTy05Z-VzmrFGcnR_cpOLa8+WSqW3tsdraETT+Wnfa2hkCYtQ@mail.gmail.com>
 <20200115202137.GA21763@SDF.ORG>
 <c1385419-76f6-46dd-9f95-87a9bfe42e92@www.fastmail.com>
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <20200116202652.GA23953@SDF.ORG> <87wo9kdfas.fsf@cassilda.carcosa.net>
Message-ID: <10379A34-B76B-497C-9BEE-116E5DA0206C@lavabit.com>

"I use Emacs. I set fill-column to 72 characters, and turn on auto-fill-mode"

I author gopher content in vim with a text width of 67 using vim-pencil in hard-wrap mode. If the proposed changes get implemented then in Gemini I'll tell pencil to go into soft mode instead. Bam! Done.

Recommending against hard wrapping outside of ``` fences is nice and easy.


From solderpunk at SDF.ORG  Tue Jan 21 20:06:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 21 Jan 2020 20:06:54 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <87sgk8dejp.fsf@cassilda.carcosa.net>
References: <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <87sgk8dejp.fsf@cassilda.carcosa.net>
Message-ID: <20200121200654.GA8684@SDF.ORG>

Okay, it looks like we are not as close to a consensus as I had hoped or
imagined.  That's fine.  I don't want to rush this process, as much as
I'm looking forward to it being over.  I wonder if we can make a simple
incremental improvement to the spec-spec now, though, using some of the
ideas that have come out of this latest round of discussion.

As a reminder, the current spec-spec, version 0.9.2, basically defines
text/gemini thusly:

* Lines beginning with => are links
* Links must always be displayed on their own lines
* All other lines are just text
* Text may be optionally reflowed as per RFC 1896, i.e. by turning
  isolated newlines into spaces and N consecutive newlines into N
  consecutive newlines.

That's it.

This format:

* Gives us links
* Results in nice text on arbitrary width screens
* Completely breaks lists like this one by joining all items
  together

(this last point kicked off this gigantic email thread)

We could change this to the following:

* Lines beginning with => are links
* Links must always be displayed on their own lines
* All other lines are just text
* Lines of text wider than the screen should be wrapped to fit the
  screen, but no RFC 1896 style mangling of newlines is allowed
* Authors are strongly encouraged not to hard-wrap their text but to
  write long lines instead.

This format:

* Gives us links
* Results in nice text on arbitrary width screens
* Lets lists like this one work just fine

i.e. it solves the problem that kicked off this email thread, without
sacrificing support for arbitary screen width - at the cost of requiring
that clients be able to wrap lines.

Does anybody *disagree* that this change by itself would improve the
current spec-spec?

I think this is, in fact, the smallest possible change to the current
spec-spec which solves my original complaint without sacrificing support
for arbitrary screen width.  So maybe I should rephrase that question:

Would anybody *prefer* that we spec hard-wrapping to some specified
length (80, 40, whatever) over speccing the above "long line" solution?
Please speak up if so!

Cheers,
Solderpunk

From jmcbray at carcosa.net  Wed Jan 22 14:31:15 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 22 Jan 2020 09:31:15 -0500
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200121200654.GA8684@SDF.ORG> (solderpunk@sdf.org's message of
 "Tue, 21 Jan 2020 20:06:54 +0000")
References: <20200116151001.GA24028@SDF.ORG>
 <e00b3c7c-a3cd-4d84-a3b7-02be590605f4@www.fastmail.com>
 <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <87sgk8dejp.fsf@cassilda.carcosa.net> <20200121200654.GA8684@SDF.ORG>
Message-ID: <87pnfba7gs.fsf@cassilda.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> Would anybody *prefer* that we spec hard-wrapping to some specified
> length (80, 40, whatever) over speccing the above "long line" solution?
> Please speak up if so!

No; though I think the long-line solution is imperfect, it is strictly
better than specifying hard-wrapping to a specified length.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From solderpunk at SDF.ORG  Wed Jan 22 15:30:53 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 22 Jan 2020 15:30:53 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <87pnfba7gs.fsf@cassilda.carcosa.net>
References: <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <87sgk8dejp.fsf@cassilda.carcosa.net>
 <20200121200654.GA8684@SDF.ORG>
 <87pnfba7gs.fsf@cassilda.carcosa.net>
Message-ID: <20200122153053.GA15119@SDF.ORG>

On Wed, Jan 22, 2020 at 09:31:15AM -0500, Jason McBrayer wrote:
> solderpunk <solderpunk at SDF.ORG> writes:
> 
> > Would anybody *prefer* that we spec hard-wrapping to some specified
> > length (80, 40, whatever) over speccing the above "long line" solution?
> > Please speak up if so!
> 
> No; though I think the long-line solution is imperfect, it is strictly
> better than specifying hard-wrapping to a specified length.

Okay, thanks!

I realised I asked "Would anybody *prefer* hard-wrapping?", but please
do respond with "no" if you wouldn't, so I can tell the difference
between nobody prefering it and nobody having had time to respond yet.
:)

Cheers,
Solderpunk


From aaron at ajanse.me  Wed Jan 22 16:25:45 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Wed, 22 Jan 2020 08:25:45 -0800
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200122153053.GA15119@SDF.ORG>
References: <CAFTy05bPEuCvx9iL606V0t1vc0POCoqGAk39-CpCOxzo--wLQw@mail.gmail.com>
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <87sgk8dejp.fsf@cassilda.carcosa.net> <20200121200654.GA8684@SDF.ORG>
 <87pnfba7gs.fsf@cassilda.carcosa.net> <20200122153053.GA15119@SDF.ORG>
Message-ID: <dea09aea-5a9c-44d5-abdb-da3b76d811ad@www.fastmail.com>

On Wed, Jan 22, 2020, at 7:30 AM, solderpunk wrote:
> I realised I asked "Would anybody *prefer* hard-wrapping?", but please
> do respond with "no" if you wouldn't, so I can tell the difference
> between nobody prefering it and nobody having had time to respond yet.
> :)

I would prefer the spec explicitly discouraging hard-wrapping :)

From lel at envs.net  Wed Jan 22 16:37:37 2020
From: lel at envs.net (lel)
Date: Wed, 22 Jan 2020 16:37:37 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <dea09aea-5a9c-44d5-abdb-da3b76d811ad@www.fastmail.com>
References: <CAFTy05abY5JYRGduhyKojXjVRLyykDQHCw_ZM=obXxHvOsfDPw@mail.gmail.com>
 <20200116222458.GD23953@SDF.ORG>
 <142b420d-acf6-48c0-8aca-21c4348a7ad3@www.fastmail.com>
 <20200117111158.GA10236@SDF.ORG> <20200117133312.GA7402@SDF.ORG>
 <87sgk8dejp.fsf@cassilda.carcosa.net>
 <20200121200654.GA8684@SDF.ORG>
 <87pnfba7gs.fsf@cassilda.carcosa.net>
 <20200122153053.GA15119@SDF.ORG>
 <dea09aea-5a9c-44d5-abdb-da3b76d811ad@www.fastmail.com>
Message-ID: <20200122163737.GA9722@mir>

On Wed, Jan 22, 2020 at 08:25:45AM -0800, Aaron Janse wrote:
> I would prefer the spec explicitly discouraging hard-wrapping :)

Ditto!

From b__m__e at mailfence.com  Wed Jan 22 22:51:37 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Wed, 22 Jan 2020 23:51:37 +0100 (CET)
Subject: Text reflow woes (or: I want bullets back!)y
Message-ID: <1091608776.152630.1579733497266@ichabod.co-bxl>

Solderpunk write's:
> I think this is, in fact, the smallest possible change to the current
> spec-spec which solves my original complaint without sacrificing support
> for arbitrary screen width.

I am FOR eliminating text reflow (ala RFC 1896) and AGAINST a specific 
hard wrap number (other than the viewport itself). Which is to say: I think
your proposal is a good compromise that _does_ improve the spec and makes
things more clear.


The issue of lists and such is still open, but I have come around on
that slightly. Solderpunk, via e-mail, pointed out that lists and headers
can provide more varied and flexible display in graphical clients... and I
had not thought of things in terms of graphical clients. That makes sense
to me. So long as it is not a mandate, but an optional part of the spec, I
withdraw my objection.

From solderpunk at SDF.ORG  Thu Jan 23 11:13:51 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 23 Jan 2020 11:13:51 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <1091608776.152630.1579733497266@ichabod.co-bxl>
References: <1091608776.152630.1579733497266@ichabod.co-bxl>
Message-ID: <20200123111351.GA11285@SDF.ORG>

On Wed, Jan 22, 2020 at 11:51:37PM +0100, Brian Evans wrote:

> So long as it is not a mandate, but an optional part of the spec, I
> withdraw my objection.

I don't intend anything to be mandatory except link lines, ordinary text
lines and possibly ``` raw/verbatim/preformatted handling (I'm not 100%
sure on that last one, I think perhaps switching to wrapped long lines
as the official recommendation removes many of the justifications we
had for first proposing it - though certainly not all of them).

Anything to do with headings, lists, etc. will be strictly optional, and
a major factor in whether I decide to adopt any of those things will be
how well they degrade when viewed on a simple terminal-based client
which completely ignores all optional components.

All I've ever wanted is to permit improvements to readability or
navigation in advanced (possibly, but not necessarily, graphical)
clients as much as possible without interfering in any non-trivial way
with the usability of incredibly simple clients.

Cheers,
Solderpunk

From Bradley at NorthTech.US  Sat Jan 25 02:42:06 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Fri, 24 Jan 2020 18:42:06 -0800
Subject: CGI and CGI like support (was Re: [ANN] Announcing Molly Brown, a
 Gemini server in Go)
In-Reply-To: <20200114234920.GA13720@brevard.conman.org>
References: <20200112153139.GB7000@SDF.ORG>
 <20200113232240.GG23700@brevard.conman.org> <20200114190348.GB10786@SDF.ORG>
 <20200114234920.GA13720@brevard.conman.org>
Message-ID: <509c8161-a3ad-b5c6-12e1-f820f4c336fa@NorthTech.US>



On 1/14/2020 3:49 PM, Sean Conner wrote:
> It was thus said that the Great solderpunk once stated:
>>
>> This decision should not be interpreted as a criticism of your
>> RFC-3875-derived implementation.  I think it makes good sense for there
>> to be an option for people to easily convert existing web CGI scripts to
>> Gemini.
>>

> 
>   But whatever you come up with, I would try to avoid calling it CGI, as
> that tends to lead to RFC-3875 ...
> 
>   -spc
> 

 Perhaps... GPI or GGI - Gemini Programming Interface or Gemini Gateway
Interface.

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

From jmcbray at carcosa.net  Fri Jan 31 19:26:28 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 31 Jan 2020 14:26:28 -0500
Subject: Adding a content size meta?
In-Reply-To: <a5f8b5d4-247a-4372-cdc2-284e6d5b6040@typed-hole.org> (Julien
 Blanchard's message of "Sat, 18 Jan 2020 18:05:35 +0100")
References: <a5f8b5d4-247a-4372-cdc2-284e6d5b6040@typed-hole.org>
Message-ID: <87o8ujbf6j.fsf@cassilda.carcosa.net>

Julien Blanchard <julien at typed-hole.org> writes:

> Thanks to gemini://konpeito.media I noticed we might be missing the
> content size information in some cases, mostly binary files.

After finally being on my laptop at home since bookmarking
konpeito.media a month ago, I've come to agree with this. We really need
to include content-length in some way. 

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From solderpunk at SDF.ORG  Sat Feb  1 18:00:34 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 1 Feb 2020 18:00:34 +0000
Subject: Text reflow woes (or: I want bullets back!)y
In-Reply-To: <20200123111351.GA11285@SDF.ORG>
References: <1091608776.152630.1579733497266@ichabod.co-bxl>
 <20200123111351.GA11285@SDF.ORG>
Message-ID: <20200201180034.GA2644@SDF.ORG>

Okay, I'm going to update the spec-spec this weekend to replace the
current RFC-1896 text wrapping with the new "wrap long lines but don't
join short lines" approach with everybody seems either to agree is an
improvement or to feel indifferent about, and which nobody objected to
for the past week or so either on this list or to me directly.

My plan is to replace the entirety of section 1.3.5.3 with the below.
Does anybody want to suggest any minor changes to this text to remove
ambiguity or anything like that?

Cheers,
Solderpunk

```
1.3.5.3 Text display

Textual content for Gopher is typically "hard-wrapped", i.e. composed
of lines no longer than (typically) 80 characters.  Each line of text
is printed to the screen as-is.  In contrast, in HTML content on the
web, browsers ignore the length of lines of text and instead "reflow"
text to a width appropriate for the display device - lines of text in
a HTML file which are "too long" get split up, while consecutive
lines which are "too short" get joined together.  Gemini adopts a
strategy between these two approaches, designed to strike a balance 
between implementation complexity, flexibility of display width, and
support for common text formatting patterns.

Lines of text in a text/gemini document which are not link lines (i.e.
do not begin with "=>") which are longer than can fit on a client's
display device SHOULD be "wrapped" to fit, i.e. long lines should be
split (ideally at whitespace or at hyphens) into multiple consecutive
lines of a device-appropriate width.  Recall that text/gemini
processing is strictly line-based: the above wrapping is applied to
each line of text independently.  Multiple consecutive lines which
are shorter than the client's display device MUST NOT be combined.

Blank lines receive no special treatment: they are ordinary text
lines, with a display length of zero.  Thus, they fit on any
client's display device and never need to be wrapped.  Each
individual blank line in a text/gemini document MUST be rendered by
the client as an individual blank line.

In order to take full advantage of this method of text formatting,
authors of text/gemini content SHOULD avoid hard-wrapping to a
specific fixed width.  Most text editors can be configured to
"soft-wrap", i.e. to write this kind of file while displaying the long
lines wrapped to fit the author's display device.

Authors who insist on hard-wrapping their content MUST be aware that
the content will display neatly on clients whose display device is as
wide as the hard-wrapped length or wider, but will appear with
irregular line widths on narrower clients.
```

On Thu, Jan 23, 2020 at 11:13:51AM +0000, solderpunk wrote:
> On Wed, Jan 22, 2020 at 11:51:37PM +0100, Brian Evans wrote:
> 
> > So long as it is not a mandate, but an optional part of the spec, I
> > withdraw my objection.
> 
> I don't intend anything to be mandatory except link lines, ordinary text
> lines and possibly ``` raw/verbatim/preformatted handling (I'm not 100%
> sure on that last one, I think perhaps switching to wrapped long lines
> as the official recommendation removes many of the justifications we
> had for first proposing it - though certainly not all of them).
> 
> Anything to do with headings, lists, etc. will be strictly optional, and
> a major factor in whether I decide to adopt any of those things will be
> how well they degrade when viewed on a simple terminal-based client
> which completely ignores all optional components.
> 
> All I've ever wanted is to permit improvements to readability or
> navigation in advanced (possibly, but not necessarily, graphical)
> clients as much as possible without interfering in any non-trivial way
> with the usability of incredibly simple clients.
> 
> Cheers,
> Solderpunk

From solderpunk at SDF.ORG  Mon Feb  3 20:17:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 3 Feb 2020 20:17:58 +0000
Subject: [SPEC-CHANGE] Full text reflow is out, long line wrapping is in
Message-ID: <20200203201758.GA7475@SDF.ORG>

Attention Gemininauts!

I have officially updated the spec-spec just now.

SUMMARY OF CHANGES:

Section 1.3.5.3 (Text display) has been completely rewritten.  The
previous optional text reflowing has been replaced with instructions to,
breifly, wrap long lines but not join short lines.

IMPLICATIONS FOR SERVER AUTHORS:

None

IMPLICATIONS FOR CLIENT AUTHORS:

Clients now need to implement wrapping of long lines.

IMPLICATIONS FOR CONTENT AUTHORS:

Authors MAY (and are encouraged to) reformat their content to avoid
hard-wrapping, so that their content can be displayed neatly on clients
with arbitrary display widths.

Cheers,
Solderpunk

From julien at typed-hole.org  Mon Feb  3 20:20:46 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Mon, 3 Feb 2020 21:20:46 +0100
Subject: [SPEC-CHANGE] Full text reflow is out, long line wrapping is in
In-Reply-To: <20200203201758.GA7475@SDF.ORG>
References: <20200203201758.GA7475@SDF.ORG>
Message-ID: <06F4E3B1-D7B5-484A-8654-A940CE23F261@typed-hole.org>

Awesome! So glad we can finally move on to other subjects! I?ll update my clients soonish hopefully.

> Le 3 f?vr. 2020 ? 21:18, solderpunk <solderpunk at sdf.org> a ?crit :
> 
> ?Attention Gemininauts!
> 
> I have officially updated the spec-spec just now.
> 
> SUMMARY OF CHANGES:
> 
> Section 1.3.5.3 (Text display) has been completely rewritten.  The
> previous optional text reflowing has been replaced with instructions to,
> breifly, wrap long lines but not join short lines.
> 
> IMPLICATIONS FOR SERVER AUTHORS:
> 
> None
> 
> IMPLICATIONS FOR CLIENT AUTHORS:
> 
> Clients now need to implement wrapping of long lines.
> 
> IMPLICATIONS FOR CONTENT AUTHORS:
> 
> Authors MAY (and are encouraged to) reformat their content to avoid
> hard-wrapping, so that their content can be displayed neatly on clients
> with arbitrary display widths.
> 
> Cheers,
> Solderpunk


From solderpunk at SDF.ORG  Mon Feb  3 20:32:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 3 Feb 2020 20:32:59 +0000
Subject: [SPEC-CHANGE] Full text reflow is out, long line wrapping is in
In-Reply-To: <06F4E3B1-D7B5-484A-8654-A940CE23F261@typed-hole.org>
References: <20200203201758.GA7475@SDF.ORG>
 <06F4E3B1-D7B5-484A-8654-A940CE23F261@typed-hole.org>
Message-ID: <20200203203259.GB7475@SDF.ORG>

On Mon, Feb 03, 2020 at 09:20:46PM +0100, Julien Blanchard wrote:
> Awesome! So glad we can finally move on to other subjects! I?ll update my clients soonish hopefully.

I am hoping we can now, quickly, come to a decision regarding the need
for a pre-formatting mode (new post about this soonish).

I have already removed what little hard-wrapping existed at
gemini.circumlunar.space, and am updating AV-98 now.  Then I'll move on
to the ~100 LOC demo clients.

Cheers,
Solderpunk


> > Le 3 f?vr. 2020 ? 21:18, solderpunk <solderpunk at sdf.org> a ?crit :
> > 
> > ?Attention Gemininauts!
> > 
> > I have officially updated the spec-spec just now.
> > 
> > SUMMARY OF CHANGES:
> > 
> > Section 1.3.5.3 (Text display) has been completely rewritten.  The
> > previous optional text reflowing has been replaced with instructions to,
> > breifly, wrap long lines but not join short lines.
> > 
> > IMPLICATIONS FOR SERVER AUTHORS:
> > 
> > None
> > 
> > IMPLICATIONS FOR CLIENT AUTHORS:
> > 
> > Clients now need to implement wrapping of long lines.
> > 
> > IMPLICATIONS FOR CONTENT AUTHORS:
> > 
> > Authors MAY (and are encouraged to) reformat their content to avoid
> > hard-wrapping, so that their content can be displayed neatly on clients
> > with arbitrary display widths.
> > 
> > Cheers,
> > Solderpunk
> 
> 

From Bradley at NorthTech.US  Wed Feb  5 00:57:27 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Tue, 4 Feb 2020 16:57:27 -0800
Subject: [SPEC-CHANGE] Full text reflow is out, long line wrapping is in
In-Reply-To: <20200203201758.GA7475@SDF.ORG>
References: <20200203201758.GA7475@SDF.ORG>
Message-ID: <5b0b967f-d01e-543c-59d9-38dc19aa4ee7@NorthTech.US>



On 2/3/2020 12:17 PM, solderpunk wrote:
> Attention Gemininauts!
> 
> I have officially updated the spec-spec just now.
> 
> SUMMARY OF CHANGES:
> 
> Section 1.3.5.3 (Text display) has been completely rewritten.  The
> previous optional text reflowing has been replaced with instructions to,
> breifly, wrap long lines but not join short lines.

I'm not sure what *briefly* implies, but IMHO, this is a good thing.

Kindest regards,

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

From solderpunk at SDF.ORG  Wed Feb  5 09:06:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 5 Feb 2020 09:06:15 +0000
Subject: [SPEC-CHANGE] Full text reflow is out, long line wrapping is in
In-Reply-To: <5b0b967f-d01e-543c-59d9-38dc19aa4ee7@NorthTech.US>
References: <20200203201758.GA7475@SDF.ORG>
 <5b0b967f-d01e-543c-59d9-38dc19aa4ee7@NorthTech.US>
Message-ID: <20200205090615.GA8780@SDF.ORG>

On Tue, Feb 04, 2020 at 04:57:27PM -0800, Bradley D. Thornton wrote:
> 
> I'm not sure what *briefly* implies, but IMHO, this is a good thing.

I just meant that "wrap long lines, don't join short ones" was just a
brief summary of what the spec actually says.

Glad you're happy!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Feb  5 09:22:43 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 5 Feb 2020 09:22:43 +0000
Subject: Preformatted text blocks
Message-ID: <20200205092243.GB8780@SDF.ORG>

Now that the line-wrapping issue seems to be sorted, at long last, the
next thing I want to quickly clear up is whether or not we really do
want some kind of pre-formatted text mode (the thing we've been
discussing with ``` syntax).

All the header/list stuff we've talked about is definitely - and always
was definitely - going to be optional and ignorable by simple clients.
So I don't feel as strong a need to build consensus on that, and I'm
pretty sure I'm going to spec it.  But verbatim mode would likely be an
obligatory thing to implement, if only because if it's in the spec at
all, some authors will produce content with would-be Gemini links in it,
under the expectation that clients won't try to parse them as links
because they're within a verbatim text block.  Some of these lines may
not actually use valid link syntax, for the purposes of teaching newbies
how *not* to format their links, so clients which ignore the ``` lines
may find themselves in trouble (although, ideally, all clients should be
robust against malformed link lines - Sean, is that in the torture
test?).

I don't think there's any question that such a facility would have
legitimate and useful applications, the quesiton is whether they provide
enough value to be worth the increased implementation effort - which,
for the record, is quite low.

The only reason I think this is worth questioning is that the *original*
reason having such a feature was proposed on this list was as a
work-around to our old style of text reflow breaking lists.  The idea
was that bulleted lists could be enclosed in ``` lines to prevent the
lines all getting joined together.  This was never a great solution in
the first place (as was discussed on the list, it just meant that
content would display weirdly if any individual list item was longer
than a single line on a given client's display), and now it is totally
unecessary as our new line-wrapping solution doesn't break lists, or
poems, or source code.

As far as I see it, the main arguments in favour of a preformatted block
concept now are:

1. The ability to include text/gemini syntax without it actually being
   rendered by the client, so Gemini can be discussed/taught over
   Gemini.
2. The ability to insist that some content (e.g. source code, ASCII
   art), be rendered in a monospace font, even by graphical clients
   which might display text in a variable width font by default.

Point 2. could in principle be nullified by mandating the use of
monospace fonts for all clients, but I think this is a pretty bad idea
and conflicts with the idea that clients should be *able* to make
reading text/gemini a typographically pleasant experience.

I think the case is strong enough to spec these, but I recall at least
one person already suggested we shouldn't, so I'm willing to hear
counter arguments, if anybody wants to provide them.

Cheers,
Solderpunk

From lazar.michael22 at gmail.com  Wed Feb  5 21:53:46 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Wed, 5 Feb 2020 16:53:46 -0500
Subject: Preformatted text blocks
In-Reply-To: <20200205092243.GB8780@SDF.ORG>
References: <20200205092243.GB8780@SDF.ORG>
Message-ID: <CAFTy05aOrL-En-U9q6n-9jna+zssGO5jLRkOwPL=7o9tGXSdgA@mail.gmail.com>

On Wed, Feb 5, 2020 at 4:22 AM solderpunk <solderpunk at sdf.org> wrote:
> As far as I see it, the main arguments in favour of a preformatted block
> concept now are:
>
> 1. The ability to include text/gemini syntax without it actually being
>    rendered by the client, so Gemini can be discussed/taught over
>    Gemini.
> 2. The ability to insist that some content (e.g. source code, ASCII
>    art), be rendered in a monospace font, even by graphical clients
>    which might display text in a variable width font by default.

I would like to tack on another argument in favor of the ``` blocks that I
think is still valid after the recent changes.

3. The ability for GUI clients to display preformatted text blocks in a
   container with horizontal scrolling.

To see exactly what I mean by this, try opening this page on a mobile browser
[0]. The page banner is ASCII art which can be scrolled left and right using
your thumb. The rest of the text on the page is wrapped to fit the screen. This
is the type of interface that I envision gemini GUI clients evolving to support.
For gemini clients that choose to implement it, it would give them an escape
hatch from this section of the spec:

> Authors who insist on hard-wrapping their content MUST be aware that
> the content will display neatly on clients whose display device is as
> wide as the hard-wrapped length or wider, but will appear with
> irregular line widths on narrower clients.

[0] https://github.com/michael-lazar/hn-gopher/blob/master/README.md

- mozz

From sean at conman.org  Wed Feb  5 23:40:06 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 5 Feb 2020 18:40:06 -0500
Subject: Preformatted text blocks
In-Reply-To: <20200205092243.GB8780@SDF.ORG>
References: <20200205092243.GB8780@SDF.ORG>
Message-ID: <20200205234006.GB30172@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> (although, ideally, all clients should be
> robust against malformed link lines - Sean, is that in the torture
> test?).

  No, but what would a malformed link look like?  I mean, I can get all
nasty with invalid characters in the scheme, path, host, etc., but how
tortuous do we really want to get?

  -spc


From solderpunk at SDF.ORG  Thu Feb  6 08:40:00 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 6 Feb 2020 08:40:00 +0000
Subject: Preformatted text blocks
In-Reply-To: <20200205234006.GB30172@brevard.conman.org>
References: <20200205092243.GB8780@SDF.ORG>
 <20200205234006.GB30172@brevard.conman.org>
Message-ID: <20200206084000.GA27798@SDF.ORG>

On Wed, Feb 05, 2020 at 06:40:06PM -0500, Sean Conner wrote:
 
>   No, but what would a malformed link look like?  I mean, I can get all
> nasty with invalid characters in the scheme, path, host, etc., but how
> tortuous do we really want to get?

Well, my first thought was quite a bit simpler than that - I wonder how
many clients would choke on the below?

=> There's no URL here, chump!

or

=> I forgot which way around link and text go gemini://whoops.doh

Cheers,
Solderpunk

From sean at conman.org  Thu Feb  6 16:36:58 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 6 Feb 2020 11:36:58 -0500
Subject: Preformatted text blocks
In-Reply-To: <20200206084000.GA27798@SDF.ORG>
References: <20200205092243.GB8780@SDF.ORG>
 <20200205234006.GB30172@brevard.conman.org> <20200206084000.GA27798@SDF.ORG>
Message-ID: <20200206163657.GA32394@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Wed, Feb 05, 2020 at 06:40:06PM -0500, Sean Conner wrote:
>  
> >   No, but what would a malformed link look like?  I mean, I can get all
> > nasty with invalid characters in the scheme, path, host, etc., but how
> > tortuous do we really want to get?
> 
> Well, my first thought was quite a bit simpler than that - I wonder how
> many clients would choke on the below?
> 
> => There's no URL here, chump!
> 
> or
> 
> => I forgot which way around link and text go gemini://whoops.doh

  I would expect the following requests:

	gemini://gemini.conman.org/test/torture/There%27s
	gemini://gemini.conman.org/test/torture/I

but I do see your point.

  -spc


From sean at conman.org  Thu Feb  6 21:32:16 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 6 Feb 2020 16:32:16 -0500
Subject: Preformatted text blocks
In-Reply-To: <20200206084000.GA27798@SDF.ORG>
References: <20200205092243.GB8780@SDF.ORG>
 <20200205234006.GB30172@brevard.conman.org> <20200206084000.GA27798@SDF.ORG>
Message-ID: <20200206213215.GA1421@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Wed, Feb 05, 2020 at 06:40:06PM -0500, Sean Conner wrote:
>  
> >   No, but what would a malformed link look like?  I mean, I can get all
> > nasty with invalid characters in the scheme, path, host, etc., but how
> > tortuous do we really want to get?
> 
> Well, my first thought was quite a bit simpler than that - I wonder how
> many clients would choke on the below?
> 
> => There's no URL here, chump!
> 
> or
> 
> => I forgot which way around link and text go gemini://whoops.doh

  Okay, I added some more torture tests, and even found a bug in my server
with test 0031 (in preparation of dealing with bad requests).

  -spc

From solderpunk at SDF.ORG  Tue Feb 25 19:43:56 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 25 Feb 2020 19:43:56 +0000
Subject: Gemini Universal Search
Message-ID: <20200225194356.GA16266@SDF.ORG>

I am very pleased to share with the list that I have been made aware
of an exciting new Gemini project - our first search engine!  It's
called Gemini Universal Search, or (delightfully![1]) GUS for short.
You can find it at gemini://gus.guru/, and there's now a link to it
from the gemini://gemini.circumlunar.space page.  GUS is a project by
Natalie Pendragon, who is subscribed to this list.

In addition to hopefully being an incentive for people to start
producing content, this raises a number of interesting discussion
points for the community.

One technical question is the issue of how server admins can opt out
of having their stuff crawled.  GUS currently recognises a /robots.txt
resource with (I presume) identical syntax to that used for HTTP.
This is certainly one potential solution to the problem (and perhaps
the most sensible one), but we might want to consider others.

One more "community" oriented question is how we might like a Gemini
search engine to work.  Currently, as I understand it, GUS functions
entirely based on the content of resources.  It does not take into
account linking structure, in the way that mainstream web search
engines do.  Depending upon one's perspective, this might be a good
thing or a bad thing.  In general, the way search engines work can
influence the way that people tend to produce content, as people avoid
doing things that they know will lower their search ranking.  It's
well worth thinking about negative consequences this has had for the
web that we want to avoid repeating in Geminispace.

Cheers,
Solderpunk

[1] https://en.wikipedia.org/wiki/Gus_Grissom

From andrew at 68kmentat.com  Wed Feb 26 17:07:39 2020
From: andrew at 68kmentat.com (Andrew Kennedy)
Date: Wed, 26 Feb 2020 12:07:39 -0500
Subject: WWW indexing concerns (was: Gemini Universal Search)
In-Reply-To: <mailman.1.1582718402.11006.gemini@lists.orbitalfox.eu>
References: <mailman.1.1582718402.11006.gemini@lists.orbitalfox.eu>
Message-ID: <1708277e02c.db11f14762556.598282234051256173@68kmentat.com>

Very cool! I want to express two points: one, I am glad to see this. As geminispace gets larger, a search method that doesn't rely on personal bookmarks will be really useful. I forget to bookmark gopher documents all the time, and Veronica really helps there.

As for crawling in general, this is something that I've been thinking about lately, and I guess now it's timely: 

HTTP/S gemini proxies allow all of the public geminispace to be indexed by Google and other services. I think that we generally consider the two current proxies to be useful (I certainly do), so to a point this is unavoidable.

proxy.vulpes.one has a robots.txt to prevent WWW crawling, which is a fair stopgap. portal.mozz.us does not, but I'm not angry about it. I meant to send out an e-mail to mozz to ask their opinion, but just haven't gotten around to it.

My issue here is that the only 2 ways to opt out of Google indexing are to use a robots.txt, or to register yourself as the domain owner and control indexing via Google's console. Both of those methods apply to the proxy website's owner, not to the gemini server's owner, because each gemini server appears like a subdirectory on the proxy's domain.

So the issue here is that the only way to opt out of being indexed is to contact each proxy maintainer and request that they make accommodations for you. That's fine with only 15 or so gemini servers, but not fair to proxy maintainers as gemini grows. It's also not enough to ask all proxies to use robots.txt, because there's nothing stopping someone from ignoring it either out of ignorance or in bad faith.

Perhaps there isn't much that can be done here, and this e-mail is little more than me venting a concern. I realize that the only way to stay anonymous on the internet is to constantly maintain your anonymity. I'm doing that in some places. But my gemini server's domain name is already tied to my IRL identity, and I wish that it was at least harder for my gemini files to be on the 1st page of a Google result.

This e-mail got a little long, and it's less formal than some of the other discussions. Sorry if it's bothersome. I'm not really a programmer, so I can't offer any solutions. But I wanted to throw this conversation into the general dialogue in case anyone has any thoughts or ideas here. Gemini is *not* the Web, after all.

- m68k


 ---- On Wed, 26 Feb 2020 07:00:02 -0500  <gemini-request at lists.orbitalfox.eu> wrote ----

 > One technical question is the issue of how server admins can opt out
 > of having their stuff crawled.  GUS currently recognises a /robots.txt
 > resource with (I presume) identical syntax to that used for HTTP.
 > This is certainly one potential solution to the problem (and perhaps
 > the most sensible one), but we might want to consider others.
 > 

From sean at conman.org  Wed Feb 26 19:29:59 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 26 Feb 2020 14:29:59 -0500
Subject: WWW indexing concerns (was: Gemini Universal Search)
In-Reply-To: <1708277e02c.db11f14762556.598282234051256173@68kmentat.com>
References: <mailman.1.1582718402.11006.gemini@lists.orbitalfox.eu>
 <1708277e02c.db11f14762556.598282234051256173@68kmentat.com>
Message-ID: <20200226192959.GA18132@brevard.conman.org>

It was thus said that the Great Andrew Kennedy once stated:
> 
> So the issue here is that the only way to opt out of being indexed is to
> contact each proxy maintainer and request that they make accommodations
> for you. That's fine with only 15 or so gemini servers, but not fair to
> proxy maintainers as gemini grows. It's also not enough to ask all proxies
> to use robots.txt, because there's nothing stopping someone from ignoring
> it either out of ignorance or in bad faith.

  There are other ways.  One way is to recognize a proxy server and block
any requests from it.  I think it would be easy to recognize one because of
all the requests from a single IP address (or block of IP addresses).  The
blocking can be at a firewall level, or the gemini server could recognice
the IP (or IP block) and close the connection or return an error.  That can
be done now.

  A second one is to extend robots.txt to indicate proxying preference, or
some other file, but then there are multiple requests (or maybe
not---caching information could be included).  Heck, even a DNS record (like
a TXT RR with the contents "v=Gemini; proxy=no" with the TTL of the DNS
record being honored).  But that relies upon the good will of the proxy to
honor that data.

  Or your idea of just asking could work just as well.

  -spc


From Bradley at NorthTech.US  Thu Feb 27 03:25:24 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Wed, 26 Feb 2020 19:25:24 -0800
Subject: Gemini Universal Search
In-Reply-To: <20200225194356.GA16266@SDF.ORG>
References: <20200225194356.GA16266@SDF.ORG>
Message-ID: <d4845fca-d9bf-4f79-98ff-74d36b9948c3@NorthTech.US>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 2/25/2020 11:43 AM, solderpunk wrote:
> I am very pleased to share with the list that I have been made
> aware of an exciting new Gemini project - our first search engine!
> It's called Gemini Universal Search, or (delightfully![1]) GUS for
> short.

Oh Goodies! Because Betty still is still single after Archie dumped
her and married Veronica instead at the end of the series/saga (True
story) ;)

GUS <3 Betty

> One more "community" oriented question is how we might like a
> Gemini search engine to work.  Currently, as I understand it, GUS
> functions entirely based on the content of resources.

Yes that is preferable from my perspective. It's a problem with
VERONICA and VERONICA2 that only indexes the text in the selector
strings. Although that is highly useful, it is  no substitute for
indexing the actual content itself.

Jughead (jugtail) is a local indexer.

Thank you Natalie! :)


- -- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
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/

iQEzBAEBCAAdFiEENWT7St9Eg6sLyiLAuIw5wQytyEkFAl5XNqMACgkQuIw5wQyt
yEmVrAgAhvGqqnNLKHrIqcHLF2FvzqYjKnjfqCmWS6I7Qg3OaVSPT+tFIJ+wYRi7
qGRGcwFxbqHeGB3AWCPzywqA+5ww00DRV5MVHzMRCrGYEV21Bl/vFKyK7TxhCYQx
FNt6AgNP90Vm45fhpEpW1jmpG+H00N+avZo7uxO5SLp3ETm7naW0t+dVK4ZAD5PP
2f0i++DP//hcsXIt2yCC/PhRk7SNb3zURn/EYY4Jhv2ej5P+TGemwBrqrHAMGDgP
6YzJBphunlUd9o1OEcA9vCC2rPxxOz9eqxAgXwEO0fq9ZUbDmPPUpC786STLYwjk
eYSu6BKGurIqyTaMze9apAQdasJwFw==
=87Q+
-----END PGP SIGNATURE-----

From Bradley at NorthTech.US  Thu Feb 27 03:54:35 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Wed, 26 Feb 2020 19:54:35 -0800
Subject: WWW indexing concerns (was: Gemini Universal Search)
In-Reply-To: <20200226192959.GA18132@brevard.conman.org>
References: <mailman.1.1582718402.11006.gemini@lists.orbitalfox.eu>
 <1708277e02c.db11f14762556.598282234051256173@68kmentat.com>
 <20200226192959.GA18132@brevard.conman.org>
Message-ID: <11b983bb-0135-a16c-0a9a-b96e3e1696b3@NorthTech.US>



On 2/26/2020 11:29 AM, Sean Conner wrote:
> It was thus said that the Great Andrew Kennedy once stated:
>>
>> So the issue here is that the only way to opt out of being indexed is to
>> contact each proxy maintainer and request that they make accommodations
>> for you. That's fine with only 15 or so gemini servers, but not fair to
>> proxy maintainers as gemini grows. It's also not enough to ask all proxies
>> to use robots.txt, because there's nothing stopping someone from ignoring
>> it either out of ignorance or in bad faith.
> 
>   There are other ways.  One way is to recognize a proxy server and block
> any requests from it.
This is preferable to me, just blocking it at the firewall level, but
does become administratively cumbersome as critical mass is acheived and
a curated list of proxies isn't available - if someone does maintain
such a list, it could  just be popped into ipsets to keep the rulesets
to a minimum.

I don't want ANYONE being able to access any of my Gemini servers via a
browser that doesn't support Gemini either natively, or via a plug-in.
I've been quite vocal and adament about this in the Gopher community for
well over a decade - to me, but not most folks apparently, it defeats
the purpose of, and incentive to, develop unique content in
Gopher/Gemini space, since someone is simply accessing it via HTTP anyway.

The problem with this method is that, let's say, there's a GUS server
attempting to spider me on TCP 1965, but there's also some infernal HTTP
< > Gemini proxy trying to access content on my Gemini servers from the
same IP. I end up with an uncomfortable choice because I want to be
indexed by GUS, but I don't want to allow anyone to use the World Wide
Web to access my content.


>   A second one is to extend robots.txt to indicate proxying preference, or
> some other file, but then there are multiple requests (or maybe
> not---caching information could be included). 

Ah yes, in a perfect world Sean :)



> Heck, even a DNS record (like
> a TXT RR with the contents "v=Gemini; proxy=no" with the TTL of the DNS
> record being honored).  But that relies upon the good will of the proxy to
> honor that data.

Again, in a perfect world ;) Either of these solutions (a TXT RR and/or
utilizing robots.txt) are ideal, sans the concerns about extra
traffic/requests.

Right now everyone, for the most part, is on this list, and the good
folks here are inclined to adhere to such friendly standards, but moving
forward as adoption builds like a snowball rolling down the mountain,
there will invariably be bad actors coming online.

One consideration worth mentioning is that, at least in my case, I tend
to have A and AAAA RRs point to a single host, and rely upon the
listening ports to determine which protocols are used to serve the
appropriate data. The way you suggested using the TXT RR would work fine
 in this case, however :)

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

From stryan at saintnet.tech  Thu Feb 27 04:25:02 2020
From: stryan at saintnet.tech (Steve Ryan)
Date: Wed, 26 Feb 2020 23:25:02 -0500
Subject: WWW indexing concerns (was: Gemini Universal Search)
In-Reply-To: <20200226192959.GA18132@brevard.conman.org>
References: <mailman.1.1582718402.11006.gemini@lists.orbitalfox.eu>
 <1708277e02c.db11f14762556.598282234051256173@68kmentat.com>
 <20200226192959.GA18132@brevard.conman.org>
Message-ID: <20200227042502.43metdxlvystsou4@vineta.saintnet.lan>

On 20/02/26 02:29PM, Sean Conner wrote:
>   A second one is to extend robots.txt to indicate proxying preference, or
> some other file, but then there are multiple requests (or maybe
> not---caching information could be included).  Heck, even a DNS record (like
> a TXT RR with the contents "v=Gemini; proxy=no" with the TTL of the DNS
> record being honored).  But that relies upon the good will of the proxy to
> honor that data.
> 
>   Or your idea of just asking could work just as well.

I'm of the opinion that either a robots.txt method or TXT record will do
for preventing spiders/proxies, I feel that stronger than assuming good
faith will always lead to an arms-war, and I'm not sure for the protocol
the servers have any chance of winning a war against clients.

If something must be kept private from proxys or spiders, perhaps
requiring a client certificate might be for the best? I'm sure someone
clever than I could figure out a way to require human intervention in
creating a cert to access a page.

-Steve

From sean at conman.org  Thu Feb 27 04:48:29 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 26 Feb 2020 23:48:29 -0500
Subject: WWW indexing concerns (was: Gemini Universal Search)
In-Reply-To: <20200227042502.43metdxlvystsou4@vineta.saintnet.lan>
References: <mailman.1.1582718402.11006.gemini@lists.orbitalfox.eu>
 <1708277e02c.db11f14762556.598282234051256173@68kmentat.com>
 <20200226192959.GA18132@brevard.conman.org>
 <20200227042502.43metdxlvystsou4@vineta.saintnet.lan>
Message-ID: <20200227044829.GB7698@brevard.conman.org>

It was thus said that the Great Steve Ryan once stated:
> On 20/02/26 02:29PM, Sean Conner wrote:
> >   A second one is to extend robots.txt to indicate proxying preference, or
> > some other file, but then there are multiple requests (or maybe
> > not---caching information could be included).  Heck, even a DNS record (like
> > a TXT RR with the contents "v=Gemini; proxy=no" with the TTL of the DNS
> > record being honored).  But that relies upon the good will of the proxy to
> > honor that data.
> > 
> >   Or your idea of just asking could work just as well.
> 
> I'm of the opinion that either a robots.txt method or TXT record will do
> for preventing spiders/proxies, I feel that stronger than assuming good
> faith will always lead to an arms-war, and I'm not sure for the protocol
> the servers have any chance of winning a war against clients.

  To that end, I have a TXT record for gemini.conman.org.  

	v=Gemini; proxy=no; webproxies=yes

	v=Gemini	- TXT record for Gemini

	proxy=no	- server does not support proxying requests
	proxy=yes	- server does support proxying requests

	webproxies=no	- please do not proxy this server via the web
	webproxies=yes	- web proxying is okay

  Discussion, questions, concerns, etc. welcome.

> If something must be kept private from proxys or spiders, perhaps
> requiring a client certificate might be for the best? I'm sure someone
> clever than I could figure out a way to require human intervention in
> creating a cert to access a page.

  It's fairly easy, and I do have two directories that require client
certificates:

	gemini://gemini.conman.org/private	- any client certificate
	gemini://gemini.conman.org/conman-labs-private - particular client certificates required

  -spc

From solderpunk at SDF.ORG  Thu Feb 27 20:02:57 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 27 Feb 2020 20:02:57 +0000
Subject: WWW indexing concerns (was: Gemini Universal Search)
In-Reply-To: <11b983bb-0135-a16c-0a9a-b96e3e1696b3@NorthTech.US>
References: <mailman.1.1582718402.11006.gemini@lists.orbitalfox.eu>
 <1708277e02c.db11f14762556.598282234051256173@68kmentat.com>
 <20200226192959.GA18132@brevard.conman.org>
 <11b983bb-0135-a16c-0a9a-b96e3e1696b3@NorthTech.US>
Message-ID: <20200227200257.GA1449@SDF.ORG>

On Wed, Feb 26, 2020 at 07:54:35PM -0800, Bradley D. Thornton wrote:

> This is preferable to me, just blocking it at the firewall level, but
> does become administratively cumbersome as critical mass is acheived and
> a curated list of proxies isn't available - if someone does maintain
> such a list, it could  just be popped into ipsets to keep the rulesets
> to a minimum.

I am happy to add something to the Best Practices document regarding
HTTP proxies, which could include a polite request to inform me of
proxies and their IP addresses so I can maintain a master list
somewhere, as well as a strong admonition to serve a robots.txt which
prevents web crawlers from slurping up Gemini content.
 
> I don't want ANYONE being able to access any of my Gemini servers via a
> browser that doesn't support Gemini either natively, or via a plug-in.
> I've been quite vocal and adament about this in the Gopher community for
> well over a decade - to me, but not most folks apparently, it defeats
> the purpose of, and incentive to, develop unique content in
> Gopher/Gemini space, since someone is simply accessing it via HTTP anyway.

I understand this sentiment, but at the end of the day it's literally
impossible to prevent this.  It's part and parcel of serving digital
content to universal machines owned and operated by other people - you
lose all control over things like this.  As was posted previously,
attempts to regain control with things like DRM just turn into arms
races that make life harder for legitimate users.  I'm in favour of
leaving things at a straightforward "gentleman's agreement".

> The problem with this method is that, let's say, there's a GUS server
> attempting to spider me on TCP 1965, but there's also some infernal HTTP
> < > Gemini proxy trying to access content on my Gemini servers from the
> same IP. I end up with an uncomfortable choice because I want to be
> indexed by GUS, but I don't want to allow anyone to use the World Wide
> Web to access my content.
> 
> >   A second one is to extend robots.txt to indicate proxying preference, or
> > some other file, but then there are multiple requests (or maybe
> > not---caching information could be included). 
 
Extending robots.txt to do this seems fairly straightforward.  We could
introduce "pseudo user-agents" like "proxy/*", "indexer/*", etc. which
all user agents of a particular type should respect.

Cheers,
Solderpunk

From ciprian.craciun at gmail.com  Thu Feb 27 23:16:30 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Fri, 28 Feb 2020 01:16:30 +0200
Subject: An outsider's view of the `gemini://` protocol
Message-ID: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>

Hello all!

[Disclaimer:  I'm not an active `gopher://` user, although long ago I
did implement my own Gopher server in Erlang and another one in Go;
however I do keep an eye on the Gopher mailing list, mostly because
I'm nostalgic of a "simpler" web...]

Today I've stumbled upon the `gemini://` protocol specification
(v0.10) and FAQ, and after reading them both, I thought that perhaps
an "outsiders" point of view could be useful.




First of all I get it that `gemini://` wants to "sit" in between
`gopher://` and `http://`;  however from what it seems I think it
resembles more HTTP/0.9
(https://www.w3.org/Protocols/HTTP/AsImplemented.html);  i.e. it adds
only the virtual host and response MIME type capability on-top of
HTTP/0.9 or Gopher (plus TLS, but that's transport related).

Although I do agree that the HTTP/1.1 semantic (because a large part
is nowadays included in HTTP/2 and HTTP/3) has become extremely
complex (from chunked encoding, to caching, and to server side push
via `Link` headers, etc.), there are some features that I think are
useful, especially given some of the stated goals of `gemini://` (like
for example slow links, etc.):

* caching -- given that most content is going to be static, caching
should be quite useful;  however it doesn't seem to have been present
as a concern neither in the spec, FAQ or the mailing list archive;
I'm not advocating for the whole HTTP caching headers, but perhaps for
a simple SHA of the body so that clients can just skip downloading it
(although this would imply a more elaborate protocol, having a
"headers" and separate "body" phase);

* compression -- needless to say that `text/*` MIME types compress
very well, thus saving both bandwidth and caching storage;  (granted
one can use compression on the TLS side, although I think that one was
dropped due to security issues?);

* `Content-Length` -- I've seen this mentioned in the FAQ or the
mailing lists;  I think the days of "unreliable" protocols has passed;
 (i.e. we should better make sure that the intended document was
properly delivered, in its entirety and unaltered;)

* status codes -- although both Gemini and HTTP use numeric status
codes, I do believe that these are an artifact of ancient times, and
we could just replace them with proper symbols (perhaps hierarchical
in nature like `redirect:temporary` or `failure:temporary:slow-down`;

* keep-alive -- although in Gopher and Gemini the served documents
seem to be self-contained, and usually connections will be idle while
the user is pondering what to read, in case of crawlers having to
re-establish each time a new connection (especially a TLS one) would
eat a lot of resources and incur significant delays;  (not to mention
that repeated TCP connection establishment to the same port or target
IP might be misinterpreted as an attack by various security appliances
or cloud providers;)




Now on the transport side, somewhat related to the previous point, I
think TLS transient certificates are an overkill...  If one wants to
implement "sessions", one could introduce
"client-side-generated-cookies" which are functionally equivalent to
these transient certificates.  Instead of creating a transient
certificate, the client generates a unique token and sends that to the
server instead.  The server has no more control over the value of that
cookie as it does for the transient certificate.

Moreover the way sessions are signaled between the server and client,
piggy-backed ontop of status codes, seems rather an afterthought than
part of an orthogonal design.  Perhaps these sessions should "moved"
to a higher level (i.e. after transport and before the actual
transaction, just like in the case of OSI stack).

Also these transient certificates are sold as "privacy enablers" or
"tracking preventing" which is far from the truth.  The server (based
on IP, ASN or other information) can easily map various transient
certificates as "possibly" belonging to the same person.  Thus just by
allowing these one opens up the possibility of tracking (even if only
for a given session).  Moreover, securely generating these transient
certificates does require some CPU power.




On a second thought, why TLS?  Why not something based on NaCL /
`libsodium` constructs, or even the "Noise Protocol"
(http://www.noiseprotocol.org/)?  For example I've tried to build the
Asuka Rust-based client and it pulled ~104 dependencies and took a few
minutes to compile, this doesn't seem too lightweight...  Granted a
lot of those dependencies might have come from other direct
dependencies, and in general Rust takes a lot to compile, but it does
give a hint...

Why not just re-use PGP to sign / encrypt requests and replies?  With
regard to PGP, given that Gopher communities tend to be quite small,
and composed of mostly "techie" people, this goes hand-in-hand with
the "web-of-trust" that is enabled by PGP and can provide something
that TLS can't at this moment: actual "attribution" of servers to
human beings and trust delegation;  for example for a server one could
generate a pair of keys and other people could sign those keys as a
way to denote their "trust" in that server (and thus the hosted
content).  Why not take this a step further and allow each document
served to be signed, thus extending this "attribution" not only to the
servers, but to the actual contents.  This way a server could provide
a mirror / cached version of a certain document, while still proving
it is the original one.

In fact with such an PGP approach one would no more authenticate the
server, but authenticate the actual document it receives;  thus the
server becomes a simple "conduit" through which the user downloads the
content, enabling one to proxy or mirror other servers and still keep
intact the cryptographic "proof of origin".




Now getting back to the `gemini://` protocol, another odd thing I
found is the "query" feature.  Gemini explicitly supports only `GET`
requests, and the `text/gemini` format doesn't support forms, yet it
still tries to implement a "single input-box form"...  Granted it's a
nice hack, but it's not "elegant"...  (Again, like in the case of
sessions, it seems more as an afterthought, even though this is the
way Gopher does it...)

Perhaps a simple "form" solution would be better?  Perhaps completely
eliminating for the time these "queries"?  Or perhaps introducing a
new form of URL's like for example:
`gemini-query:?url=gemini://server/path&prompt=Please+enter+something`
which can be served either in-line (as was possible in Gopher) and /
or served as a redirect (thus eliminating another status code family).




Regarding the `text/gemini` format -- and taking into account various
emails in the archive about reflowing, etc -- makes me wonder if it is
actually needed.  Why can't CommonMark be adopted as the HTML
equivalent, and a more up-to-date Gopher map variant as an alternative
for menus?  There are already countless safe CommonMark parsers
out-there (for example in Rust there is one implemented by Google) and
the format is well understood and accepted by a large community
(especially the static side generators community).

Regarding an up-to-date Gopher map alternative, I think this is an
important piece of the Gopher ecosystem that is missing from today's
world:  a machine-parsable standard format of indexing documents.  I
very fondly remember "directory" sites of yesteryear (like DMOZ or the
countless other clones) that strives to categorize the internet not by
"machine learning" but by human curation.




In fact (and here I stop speaking about Gemini as it is right now, but
instead I try to summarize what I believe a proper alternative for the
"web" would be) if one puts together:
* a simple Gemini like protocol;
* the Gopher-like map alternative (thus indexing);
* the PGP signed documents;
* more structured links between these documents;
* perhaps add support for versioning;
* and perhaps add support for content-based addressing (as opposed to
server-based addressing) (i.e. persistent URL's);

, we get closer to the initial "spirit" of both the "web" (i.e. the
90's era WWW), namely:
* a "body" of "documents" that aren't tied to a particular server,
that link to one-another;
* that have a minimal metadata (especially author and date) and
perhaps revisions;
* and a way to categorize and organize these into a proper (perhaps
hierarchical) structure;

(Perhaps the closest to this ideal would be a Wikipedia style web...)




All in all I find the `gemini://` project quite interesting, and I'll
keep an close eye on it.  I'm also glad to see that the Gopher world
hasn't yet died, but instead spawned a modern alternative.

Also, although all of my above comments are somewhat in a negative
tone, please take them in a constructive manner, and please note that
I do appreciate other aspects of the Gemini proposal (from the
simplification of the protocol and allowing as first class citizen the
proxying of other kinds of URL's, to the fact that the `text/gemini`
mandates that the client is free to wrap the text as one sees fit).

Good work guys, and I hope you'll find this useful,
Ciprian.

From sean at conman.org  Fri Feb 28 02:44:09 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 27 Feb 2020 21:44:09 -0500
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
Message-ID: <20200228024409.GA16159@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> Hello all!

  Hello.

  [ snip ]

> * caching -- given that most content is going to be static, caching
> should be quite useful;  however it doesn't seem to have been present
> as a concern neither in the spec, FAQ or the mailing list archive;
> I'm not advocating for the whole HTTP caching headers, but perhaps for
> a simple SHA of the body so that clients can just skip downloading it
> (although this would imply a more elaborate protocol, having a
> "headers" and separate "body" phase);

  I don't think solderpunk (creator of this protocol) expects Gemini to be a
replacement for HTTP---for him, it's more of a way to cut down on the bloat
that has become the web.  In fact, everything in Gemini could in fact be
done with HTTP.  With that said, I have made oblique references to adding
something (a timestamp) to cut down on unneeded requests.  It hasn't been
taken up.

> * `Content-Length` -- I've seen this mentioned in the FAQ or the
> mailing lists;  I think the days of "unreliable" protocols has passed;
>  (i.e. we should better make sure that the intended document was
> properly delivered, in its entirety and unaltered;)

  I did bring this up early in the design, but it was rejected outright. 
This has since been brought up due to one Gemini site serving very large
files.  There has been some talk, but nothing has yet come from it.

> * status codes -- although both Gemini and HTTP use numeric status
> codes, I do believe that these are an artifact of ancient times, and
> we could just replace them with proper symbols (perhaps hierarchical
> in nature like `redirect:temporary` or `failure:temporary:slow-down`;

  I disagree.  Using "proper symbols" is over all harder to deal with. 
First, it tends to be English-centric.  I mean, we could go with:

	defectum:tempus:tardius

or how about

	teip:sealadach:n?os-moille

  First off, the code has to be parsed, and while this is easy in languages
like Python or Perl, you run into ... issues, with Rust, C++ or Go (not to
mention the complete mess that is C).  A number is easy to parse, easy to
check and whose meaning can be translated into another language.  The Gemini
status codes (as well as HTTP and other three-digit status codes) don't even
have to be converted into a number---you can easily do a two level check:

	if (status[0] == '2')
		/* happy path */
	else if (status[0] == '3')
		/* redirection path */
	else if (status[0] == '4')
		/* tempoary failure */
	else if (status[0] == '5')
		/* permanent failure */
	else if (status[0] == '6')
	{
		/* authorizatio needed */
		if (status[1] == '1')
			/* client cert required */
		else if (status[1] == '3')
			/* rejected! */
	}

  There was a long, drawn-out discussion between solderpunk and me about
status codes.  The compromise was the two digit codes currently in use.

> * keep-alive -- although in Gopher and Gemini the served documents
> seem to be self-contained, and usually connections will be idle while
> the user is pondering what to read, in case of crawlers having to
> re-establish each time a new connection (especially a TLS one) would
> eat a lot of resources and incur significant delays;  (not to mention
> that repeated TCP connection establishment to the same port or target
> IP might be misinterpreted as an attack by various security appliances
> or cloud providers;)

  I would think that would be a plus for this crowd, as it's less likely for
Gemini to be quickly exploited.

> Now on the transport side, somewhat related to the previous point, I
> think TLS transient certificates are an overkill...  If one wants to
> implement "sessions", one could introduce

  This is the fault of both myself and solderpunk.  When I implemented the
first Gemin server (yes, even more solderpunk, who created the protocol) I
included support for client certificates as a means of authentication of the
client.  My intent (besides playing around with that technology) was to have
fine grained control over server requests without the user to have a
password, and to that end, I have two areas on my Gemini server that require
client certificates:

	gemini://gemini.conman.org/private/

		This area will accept *any* client certificate, making it
		easy for clients to test that they do, in fact, serve up a
		client certificate.

	gemini://gemini.conman.org/conman-labs-private/

		This area requires certificates signed by my local
		certificate authority (i.e. *I* give you the cert to use). 
		This was my actual intent.

It wasn't my intent to introduce a "cookie" like feature. solderpunk
interpreted this as a "cookie" like feature and called it "transient
certificates".  I still view this feature as "client certificates" myself. 
I personally think the user of "transient certificates" is confusing.

> On a second thought, why TLS?  Why not something based on NaCL /
> `libsodium` constructs, or even the "Noise Protocol"
> (http://www.noiseprotocol.org/)? 

	1) Never, *NEVER* implement crypto yourself.

	2) OpenSSL exists and has support in most (if not all) popular
	languages.

	3) I never even heard of the Noise Protocol.

> For example I've tried to build the
> Asuka Rust-based client and it pulled ~104 dependencies and took a few
> minutes to compile, this doesn't seem too lightweight...  

  So wait?  You try to use something other than OpenSSL and it had too many
dependencies and took too long to compile?  Or is did you mean to say that
the existing Rust-based client for OpenSSL had too many dependencies?  I
think you mean the later, but it could be read as the former.

> Why not just re-use PGP to sign / encrypt requests and replies?  With
> regard to PGP, 

  There are issues with using PGP:

	https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

> given that Gopher communities tend to be quite small,
> and composed of mostly "techie" people, this goes hand-in-hand with
> the "web-of-trust" that is enabled by PGP and can provide something
> that TLS can't at this moment: actual "attribution" of servers to
> human beings and trust delegation;  for example for a server one could
> generate a pair of keys and other people could sign those keys as a
> way to denote their "trust" in that server (and thus the hosted
> content).  Why not take this a step further and allow each document
> served to be signed, thus extending this "attribution" not only to the
> servers, but to the actual contents.  This way a server could provide
> a mirror / cached version of a certain document, while still proving
> it is the original one.

  The hardest problem with crypto is key management.  If anything, key
management with PGP seems more problematic than with OpenSSL and the CA
infrastructure (as bad as the CA infrastructure is).

> Now getting back to the `gemini://` protocol, another odd thing I
> found is the "query" feature.  Gemini explicitly supports only `GET`
> requests, and the `text/gemini` format doesn't support forms, yet it
> still tries to implement a "single input-box form"...  Granted it's a
> nice hack, but it's not "elegant"...  (Again, like in the case of
> sessions, it seems more as an afterthought, even though this is the
> way Gopher does it...)
> 
> Perhaps a simple "form" solution would be better?  Perhaps completely
> eliminating for the time these "queries"?  Or perhaps introducing a
> new form of URL's like for example:
> `gemini-query:?url=gemini://server/path&prompt=Please+enter+something`
> which can be served either in-line (as was possible in Gopher) and /
> or served as a redirect (thus eliminating another status code family).

  Forms lead to applications.  Applications lead to client side scripting. 
Client side scripting leads to the web ... 

  Of course there's pressure to expand the protocol.  solderpunk is trying
his hardest to keep that from happening and turning Gemini into another web
clone.

> Regarding the `text/gemini` format -- and taking into account various
> emails in the archive about reflowing, etc -- makes me wonder if it is
> actually needed.  Why can't CommonMark be adopted as the HTML
> equivalent, and a more up-to-date Gopher map variant as an alternative
> for menus?  There are already countless safe CommonMark parsers
> out-there (for example in Rust there is one implemented by Google) and
> the format is well understood and accepted by a large community
> (especially the static side generators community).

  It can.  RFC-7763 defines the media type text/markdown and RFC-7764 define
known variations that can be specified.  Could be done right now without any
changes to Gemini.  Go for it.

> Regarding an up-to-date Gopher map alternative, I think this is an
> important piece of the Gopher ecosystem that is missing from today's
> world:  a machine-parsable standard format of indexing documents.  I
> very fondly remember "directory" sites of yesteryear (like DMOZ or the
> countless other clones) that strives to categorize the internet not by
> "machine learning" but by human curation.

  Could you provide an example of what you mean by this?  I'm not sure why a
map alternative is needed.

> * and perhaps add support for content-based addressing (as opposed to
> server-based addressing) (i.e. persistent URL's);

  There already exist such protocols---I'm not sure what a new one based
around Gemini would buy.

> (Perhaps the closest to this ideal would be a Wikipedia style web...)

  We already have that---the Wikipedia.

  -spc

From singletona082 at gmail.com  Fri Feb 28 07:02:43 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Fri, 28 Feb 2020 01:02:43 -0600
Subject: Is it too late to consider adding a subset of Markdown to the render
 spec?
Message-ID: <CAPBeim4kNFVZHcShTfuH3cyiZQHBoAbs-+wDO85y+e-v8+dxgw@mail.gmail.com>

This way the files themselves are still effectively plain text andit's on
the browser to render text formatting

Maybe it's one of those 'thigns that don't matter' things, especially when
we're in an early stage of 'hey we are only sorta getting the bare basics
working' but I felt it was worth considering for when rendering becomes
more of a focus.

Also hi, I'm new here. I unfortunately don't have any real technical
background. I just like the idea of a sort of middle ground between HTTP
and Gopher that's still 'advertising and bloat hostile.' Given my poor
vision and my interest in low bandwidth networking a text centric thing
suits me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200228/67026577/attachment-0001.htm>

From ciprian.craciun at gmail.com  Fri Feb 28 07:30:53 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Fri, 28 Feb 2020 09:30:53 +0200
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <20200228024409.GA16159@brevard.conman.org>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
Message-ID: <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>

On Fri, Feb 28, 2020 at 4:44 AM Sean Conner <sean at conman.org> wrote:
>   I disagree.  Using "proper symbols" is over all harder to deal with.
> First, it tends to be English-centric.  I mean, we could go with:
>
>         defectum:tempus:tardius
>
> or how about
>
>         teip:sealadach:n?os-moille


The protocol is already English centric, for example the MIME types
(which are IANA standards), it uses lef-to-right writing, it uses
UTF-8 which is optimized for Latin-based alphabets, etc.;  so if we
want to be politically correct, we could use Latin or Esperanto.


>   First off, the code has to be parsed, and while this is easy in languages
> like Python or Perl, you run into ... issues, with Rust, C++ or Go (not to
> mention the complete mess that is C).  A number is easy to parse, easy to
> check and whose meaning can be translated into another language.  The Gemini
> status codes (as well as HTTP and other three-digit status codes) don't even
> have to be converted into a number---you can easily do a two level check:
>
>         if (status[0] == '2')
>                 /* happy path */
>         else if (status[0] == '3')
>                 /* redirection path */
>         else if (status[0] == '4')
>                 /* tempoary failure */
>         else if (status[0] == '5')
>                 /* permanent failure */
>         else if (status[0] == '6')
>         {
>                 /* authorizatio needed */
>                 if (status[1] == '1')
>                         /* client cert required */
>                 else if (status[1] == '3')
>                         /* rejected! */
>         }


OK, although I understand why things are harder in C, you present
above only the "easy part".  Please take into account the
line-reading, splitting into code and meta (and the protocol does say
one or multiple whitespaces in between), checking the `CRLF` at the
end.  Now assuming you've done all that even the code above has a
couple of bugs:
* what if the server sends `99`?  (it is not covered);
* what if the server sends just `6`? (it is not covered, although
given that perhaps `status` is `\0` terminated it won't be a large
problem, but still it would fall through;)
* what if the server just sends an empty status code? (is it checked
by the parser?)

So if simplicity is a real concern, then why not introduce something
like `0:success` `1:failure:temporary`.  (I.e. the first character is
either `0` or `1`;  other more advanced clients should parse the
rest.)

Also taking into account that the client still has to handle relative
redirects, I think the status code parsing pales in comparison.


As minor issues:
* why `CRLF`?  it's easier (both in terms of availability of functions
and efficiency) to split lines by a single character `\n` than by a
string;
* why allow "one-or-more whitespaces" especially in protocol related
parts?  why not mandate a strict syntax?




> > Now on the transport side, somewhat related to the previous point, I
> > think TLS transient certificates are an overkill...  If one wants to
> > implement "sessions", one could introduce
>
>   This is the fault of both myself and solderpunk.  When I implemented the
> first Gemin server (yes, even more solderpunk, who created the protocol) I
> included support for client certificates as a means of authentication of the
> client.  My intent (besides playing around with that technology) was to have
> fine grained control over server requests without the user to have a
> password, and to that end, I have two areas on my Gemini server that require
> client certificates:
>
> [...]
>
> It wasn't my intent to introduce a "cookie" like feature. solderpunk
> interpreted this as a "cookie" like feature and called it "transient
> certificates".  I still view this feature as "client certificates" myself.
> I personally think the user of "transient certificates" is confusing.


I was specifically targeting only the "transient certificates", not
proper "client certificates".

In fact I appreciate very much the usage of client certificates as
means to authenticate known clients.  (This is something I personally
use in production for back-office endpoints.)




> > On a second thought, why TLS?  Why not something based on NaCL /
> > `libsodium` constructs, or even the "Noise Protocol"
> > (http://www.noiseprotocol.org/)?
>
>         1) Never, *NEVER* implement crypto yourself.


I was never proposing to implement crypto ourselves.  `libsodium` /
NaCL provides very useful high-level constructs, tailored for specific
use-cases (like for example message encryption and signing), that are
proven to be safe, and exports them with a very simple API that can be
easily understood and used.


>         3) I never even heard of the Noise Protocol.


The "Noise Protocol" is currently used by WireGuard, WhatsApp and
possibly other applications that target network-based communications.
Although it is more complex than NaCL.

(It was just an example of more "current" frameworks.)


>         2) OpenSSL exists and has support in most (if not all) popular
>         languages.


Don't know what to say...  I find the OpenSSL documentation terrible,
and it's hard to use...  In fact given the complexity of TLS I would
say any wrapper, reimplementation, or alternative is as bad.  For
example I played with Go's TLS library and even though it's manageable
it requires lots of attention to get things right.




> > For example I've tried to build the
> > Asuka Rust-based client and it pulled ~104 dependencies and took a few
> > minutes to compile, this doesn't seem too lightweight...
>
>   So wait?  You try to use something other than OpenSSL and it had too many
> dependencies and took too long to compile?  Or is did you mean to say that
> the existing Rust-based client for OpenSSL had too many dependencies?  I
> think you mean the later, but it could be read as the former.


Looking in https://tildegit.org/julienxx/asuka/src/branch/master/Cargo.toml
apparently it is using `native-tls`
(https://crates.io/crates/native-tls) which apparently is using
OpenSSL on Linux; and this `native-tls` library isn't an "odd" one, it
is used by many high profile Rust libraries.  Removing it and checking
the dependency tree it seems it drops the dependencies with about 15
packages.

However as said earlier, perhaps it's Rust's ecosystem fault, most
likely other used libraries might also be to blame for this, but
regardless mandating the use of TLS doesn't simplify things.




> > Why not just re-use PGP to sign / encrypt requests and replies?  With
> > regard to PGP,
>
>   There are issues with using PGP:
>
>         https://latacora.micro.blog/2019/07/16/the-pgp-problem.html


There are issues with any technology, TLS included.

However I would say it's easier to integrate GnuPG (even through
subprocesses) in order to encrypt / decrypt payloads (especially given
how low in count they are for Gemini's ecosystem) than implementing
TLS.  Moreover it offers out-of-the-box the whole client side
certificate management, which adding to a TLS-based client would be
much more involved, more on this bellow...


> > given that Gopher communities tend to be quite small,
> > and composed of mostly "techie" people, this goes hand-in-hand with
> > the "web-of-trust" that is enabled by PGP and can provide something
> > that TLS can't at this moment: actual "attribution" of servers to
> > human beings and trust delegation;  for example for a server one could
> > generate a pair of keys and other people could sign those keys as a
> > way to denote their "trust" in that server (and thus the hosted
> > content).  Why not take this a step further and allow each document
> > served to be signed, thus extending this "attribution" not only to the
> > servers, but to the actual contents.  This way a server could provide
> > a mirror / cached version of a certain document, while still proving
> > it is the original one.
>
>   The hardest problem with crypto is key management.  If anything, key
> management with PGP seems more problematic than with OpenSSL and the CA
> infrastructure (as bad as the CA infrastructure is).


One of the `gemini://` specifications explicitly states that the
server certificate authentication model is similar to SSH's first use
accept and cache afterward.  However say you'll go with the actual CA
model, now you need to juggle Let's Encrypt (each 3 months) (or add
support for ACME in your server), then juggle PEM files, etc.
Regardless, either way one will have to implement all this certificate
management from scratch.

Now on the client certificate side, again a client would have to
implement all that from scratch.

Thus on the contrary, PGP (with perhaps GnuPG) would simplify all this
because it already implements all these features, and has clearly
defined operations over all these entities, including a web-of-trust.

(In fact none of the package managers I know of use S/MIME, i.e. X.509
certificates and CA's, for package signatures, but instead delegate to
GnuPG...)




> > Now getting back to the `gemini://` protocol, another odd thing I
> > found is the "query" feature.  Gemini explicitly supports only `GET`
> > requests, and the `text/gemini` format doesn't support forms, yet it
> > still tries to implement a "single input-box form"...  Granted it's a
> > nice hack, but it's not "elegant"...  (Again, like in the case of
> > sessions, it seems more as an afterthought, even though this is the
> > way Gopher does it...)
> >
> > Perhaps a simple "form" solution would be better?  Perhaps completely
> > eliminating for the time these "queries"?  Or perhaps introducing a
> > new form of URL's like for example:
> > `gemini-query:?url=gemini://server/path&prompt=Please+enter+something`
> > which can be served either in-line (as was possible in Gopher) and /
> > or served as a redirect (thus eliminating another status code family).
>
>   Forms lead to applications.  Applications lead to client side scripting.
> Client side scripting leads to the web ...
>
>   Of course there's pressure to expand the protocol.  solderpunk is trying
> his hardest to keep that from happening and turning Gemini into another web
> clone.


But you are already implementing "applications" on-top of Gemini (and
Gopher) through CGI...  And you already are implementing forms,
although "single-input" ones...  Even with this single input form one
could implement a wizard style "one input at a time" form...
Basically you give the technical possibility for "applications".

I wasn't talking about "client side scripting";  I was just saying
either drop this completely from the protocol, either specify it.  (At
the moment nothing stops a client / server implementer to just reuse
the "question" and "answer" to send back and forth an actual form
specification and answer...)

(Also "client side scripting" can't be eradicated through the
protocol.  One is free to include for example JavaScript in the
client, and the protocol can't say "no".)




> > Regarding the `text/gemini` format -- and taking into account various
> > emails in the archive about reflowing, etc -- makes me wonder if it is
> > actually needed.  Why can't CommonMark be adopted as the HTML
> > equivalent, and a more up-to-date Gopher map variant as an alternative
> > for menus?  There are already countless safe CommonMark parsers
> > out-there (for example in Rust there is one implemented by Google) and
> > the format is well understood and accepted by a large community
> > (especially the static side generators community).
>
>   It can.  RFC-7763 defines the media type text/markdown and RFC-7764 define
> known variations that can be specified.  Could be done right now without any
> changes to Gemini.  Go for it.


I know "I can";  I can even use PDF as the default "document format"
in my own client / server.  I could even use Flash.  :)

However I was speaking as the "default", Gemini endorsed format.




> > Regarding an up-to-date Gopher map alternative, I think this is an
> > important piece of the Gopher ecosystem that is missing from today's
> > world:  a machine-parsable standard format of indexing documents.  I
> > very fondly remember "directory" sites of yesteryear (like DMOZ or the
> > countless other clones) that strives to categorize the internet not by
> > "machine learning" but by human curation.
>
>   Could you provide an example of what you mean by this?  I'm not sure why a
> map alternative is needed.


One problem with today's web is that the actual "web structure" is
embedded in unstructured documents as links.  What I liked about
Gopher maps is that it gave a machine-readable, but still
user-friendly, way to map and categorize the "web contents".

Think about the following example:  I want to look for a cheap telecom
plan;  I open multiple telecom provider web sites, and now for each
one I have to "navigate" their "UX optimized" layouts (expanding
menus, drop-downs, burger buttons, etc.) (some placed on the top, some
on the right, etc.) to find the proper page that lists these plans.
Now imagine how that looks in Gopher:  each site would in fact provide
a Gopher-map that looks the same (at least in terms of layout) and I
can find the information I'm looking for much easier.

To be more "academic":  the current web pages (HTML) serve a couple of
distinct purposes:
* actual documents -- documentation, essays, blogs, etc. that use
links mainly as bibliographic references;  (this would be equivalent
to PDF files;)
* actual client-side applications -- single page apps (React, Angular,
etc.);  (this would be equivalent to Flash;)
* index pages -- meant to give a structure to a particular site and
help the user find what he is searching for;  (this would be
equivalent to site-maps, Gopher maps, RSS, etc.)

Now getting back to Gemini:
* actual documents -- we have `text/gemini` (or CommonMark, etc.)
* we don't support client-side applications;
* index pages -- we once more have `text/gemiin` (or others) but which
aren't specifically designed for this purpose;

How would such an "index" document look like?  A machine readable
(don't have the specific syntax yet, perhaps JSON?, perhaps something
else?) that allows one to:
* provide a way to describe links with short description (perhaps a
summary, author, date, some other standard meta-data like RSS/Atom
does);
* provide a way to group links in a hierarchical tree-like menu (so
that one doesn't need multiple transactions to load a small depth,
well structured menu);
* provide hints for crawlers, etc.;




> > * and perhaps add support for content-based addressing (as opposed to
> > server-based addressing) (i.e. persistent URL's);
>
>   There already exist such protocols---I'm not sure what a new one based
> around Gemini would buy.


I agree that `gemini://` is first and foremost a "transfer" protocol.
However one can include a document's identity as a first class citizen
of the protocol.

For example say each document is identified by its SHA;  then when
replying with a document also send that SHA in form of a permanent URL
like say `gemini-object:?sha={SHA}&location=gemini://first-server/...&location=gemini://second-server/...`;
 then a client (that perhaps has bookmarked that particular version of
that document) could send that URL to a server (of his choosing via
configuration, to the first one specified in `location`, etc.) and if
that server has that document just reply with that, else use
`location`, else return 404.

Ciprian.

From sean at conman.org  Fri Feb 28 09:07:09 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 28 Feb 2020 04:07:09 -0500
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
Message-ID: <20200228090709.GB16159@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Fri, Feb 28, 2020 at 4:44 AM Sean Conner <sean at conman.org> wrote:
> >   I disagree.  Using "proper symbols" is over all harder to deal with.
> > First, it tends to be English-centric.  I mean, we could go with:
> >
> >         defectum:tempus:tardius
> >
> > or how about
> >
> >         teip:sealadach:n?os-moille
> 
> 
> The protocol is already English centric, for example the MIME types
> (which are IANA standards), it uses lef-to-right writing, it uses
> UTF-8 which is optimized for Latin-based alphabets, etc.;  so if we
> want to be politically correct, we could use Latin or Esperanto.

  Why is a numeric status code so bad?  Yes, the rest of the protocol is
English centric (MIME types; left-to-right, UTF-8).  It just seems that
using words (regardless of language) is just complexity for its own sake.

> OK, although I understand why things are harder in C, you present
> above only the "easy part".  Please take into account the
> line-reading, splitting into code and meta (and the protocol does say
> one or multiple whitespaces in between), checking the `CRLF` at the
> end.  Now assuming you've done all that even the code above has a
> couple of bugs:
> * what if the server sends `99`?  (it is not covered);
> * what if the server sends just `6`? (it is not covered, although
> given that perhaps `status` is `\0` terminated it won't be a large
> problem, but still it would fall through;)
> * what if the server just sends an empty status code? (is it checked
> by the parser?)

  Oh, thanks for the client test suggestions.  I'll need to add those to my
client torture test (for a client, I would expect it to just reject the
response and indicate a server error to the user).

> As minor issues:
> * why `CRLF`?  it's easier (both in terms of availability of functions
> and efficiency) to split lines by a single character `\n` than by a
> string;

  That was discussed earlier on the list:

	https://lists.orbitalfox.eu/archives/gemini/2019/000116.html

> * why allow "one-or-more whitespaces" especially in protocol related
> parts?  why not mandate a strict syntax?

  solderpunk will have to answer that one.

> > > On a second thought, why TLS?  Why not something based on NaCL /
> > > `libsodium` constructs, or even the "Noise Protocol"
> > > (http://www.noiseprotocol.org/)?
> >
> >         1) Never, *NEVER* implement crypto yourself.
> 
> I was never proposing to implement crypto ourselves.  `libsodium` /
> NaCL provides very useful high-level constructs, tailored for specific
> use-cases (like for example message encryption and signing), that are
> proven to be safe, and exports them with a very simple API that can be
> easily understood and used.

  TLS was choosen because the COMMUNICATIONS LINK is encrypted, not just the
payload.  All Eve (the evesdropper) can see is what IP address you are
connecting to, not what content you are reading, nor (depending upon the TLS
version) what virtual server you might be talking to.

> >         2) OpenSSL exists and has support in most (if not all) popular
> >         languages.
> 
> Don't know what to say...  I find the OpenSSL documentation terrible,
> and it's hard to use...  In fact given the complexity of TLS I would
> say any wrapper, reimplementation, or alternative is as bad.  For
> example I played with Go's TLS library and even though it's manageable
> it requires lots of attention to get things right.

  Yes, it is horrible.  And people make do.  I know for myself I'm using
libtls, which is part of LibreSSL (a fork of OpenSSL) which makes using TLS
trivial.  I was able, with just the header file tls.h and man pages, wrap
libtls for Lua [1], which I use for my Gemini server GLV-1.12556 [2].  I
just wish libtls was more widely available.

> > > Why not just re-use PGP to sign / encrypt requests and replies?  With
> > > regard to PGP,
> >
> >   There are issues with using PGP:
> >
> >         https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
> 
> There are issues with any technology, TLS included.
> 
> However I would say it's easier to integrate GnuPG (even through
> subprocesses) in order to encrypt / decrypt payloads (especially given
> how low in count they are for Gemini's ecosystem) than implementing
> TLS.  Moreover it offers out-of-the-box the whole client side
> certificate management, which adding to a TLS-based client would be
> much more involved, more on this bellow...

  As I have mentioned, that only protects the payload, not the
communications channel.

> >   The hardest problem with crypto is key management.  If anything, key
> > management with PGP seems more problematic than with OpenSSL and the CA
> > infrastructure (as bad as the CA infrastructure is).
> 
> One of the `gemini://` specifications explicitly states that the
> server certificate authentication model is similar to SSH's first use
> accept and cache afterward.  However say you'll go with the actual CA
> model, now you need to juggle Let's Encrypt (each 3 months) (or add
> support for ACME in your server), then juggle PEM files, etc.
> Regardless, either way one will have to implement all this certificate
> management from scratch.

  Or self-signed certificates.

  Okay, we use NaCL.  Now what?  What's needed to secure the communication
channel?  A key exchange.  Again, rule 1---never implement crypto.

> >   Forms lead to applications.  Applications lead to client side scripting.
> > Client side scripting leads to the web ...
> >
> >   Of course there's pressure to expand the protocol.  solderpunk is trying
> > his hardest to keep that from happening and turning Gemini into another web
> > clone.
> 
> 
> But you are already implementing "applications" on-top of Gemini (and
> Gopher) through CGI...  

  Yes ... but there's only two Gemini servers that support CGI, GLV-1.12556
[2] and Jetforce [3] (two out of five Gemini server programs).  I
implemented CGI in GLV-1.12556 just because I could (and I think to prove a
point).  I technically don't need CGI support for the server I run since
it's just as easy for me to implement custom handlers [4].

> > > Regarding an up-to-date Gopher map alternative, I think this is an
> > > important piece of the Gopher ecosystem that is missing from today's
> > > world:  a machine-parsable standard format of indexing documents.  I
> > > very fondly remember "directory" sites of yesteryear (like DMOZ or the
> > > countless other clones) that strives to categorize the internet not by
> > > "machine learning" but by human curation.
> >
> >   Could you provide an example of what you mean by this?  I'm not sure why a
> > map alternative is needed.
> 
> One problem with today's web is that the actual "web structure" is
> embedded in unstructured documents as links.  What I liked about
> Gopher maps is that it gave a machine-readable, but still
> user-friendly, way to map and categorize the "web contents".

  One problem with that---incentives.  What's my incentive to make all this
information more easily machine readable?  On the web, you do that, and what
happens?  Google comes along, munches on all that sweet machine readable
data and serves it up directly to users, meaning the user just has to go to
Google for the information, not your server.  Given those incentives, I have
no reason to make my data easily machine readable when it means less
traffic.

  I recall the large push for RDF (Resource Description Framework) back
around 2004 or so ... embed machine parsable relations and metadata and it
would be oh so wonderful.  Some people even bothered to to all that work. 
And for what?  It was a pain to maintain, the tooling was poor, and Google
would just suck it up and serve it to users directly, no reason for anyone
to actually visit your site.

  As a user, that's great!  As a web site operator, not so much.

> > > * and perhaps add support for content-based addressing (as opposed to
> > > server-based addressing) (i.e. persistent URL's);
> >
> >   There already exist such protocols---I'm not sure what a new one based
> > around Gemini would buy.
> 
> I agree that `gemini://` is first and foremost a "transfer" protocol.
> However one can include a document's identity as a first class citizen
> of the protocol.
> 
> For example say each document is identified by its SHA;  then when
> replying with a document also send that SHA in form of a permanent URL
> like say `gemini-object:?sha={SHA}&location=gemini://first-server/...&location=gemini://second-server/...`;
>  then a client (that perhaps has bookmarked that particular version of
> that document) could send that URL to a server (of his choosing via
> configuration, to the first one specified in `location`, etc.) and if
> that server has that document just reply with that, else use
> `location`, else return 404.

  Hey, go ahead and implement that.  I'd like to see that ... 

  -spc (I got my feet wet in Gemini by implementing the first server ... )

[1]	https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c

[2]	https://github.com/spc476/GLV-1.12556

[3]	https://github.com/michael-lazar/jetforce

[4]	gopher://gopher.conman.org/1Gopher:Ext:GLV-1/handlers/

From sean at conman.org  Fri Feb 28 09:20:11 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 28 Feb 2020 04:20:11 -0500
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
Message-ID: <20200228092010.GC16159@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> 
> For example say each document is identified by its SHA;  then when
> replying with a document also send that SHA in form of a permanent URL
> like say `gemini-object:?sha={SHA}&location=gemini://first-server/...&location=gemini://second-server/...`;
>  then a client (that perhaps has bookmarked that particular version of
> that document) could send that URL to a server (of his choosing via
> configuration, to the first one specified in `location`, etc.) and if
> that server has that document just reply with that, else use
> `location`, else return 404.

  Actually, shouldn't the sever return "defectum:permanens:non_inveni"?

  -spc (Forgot to ask that in my previous email ... )


From solderpunk at SDF.ORG  Fri Feb 28 09:43:47 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 28 Feb 2020 09:43:47 +0000
Subject: Is it too late to consider adding a subset of Markdown to the
 render spec?
In-Reply-To: <CAPBeim4kNFVZHcShTfuH3cyiZQHBoAbs-+wDO85y+e-v8+dxgw@mail.gmail.com>
References: <CAPBeim4kNFVZHcShTfuH3cyiZQHBoAbs-+wDO85y+e-v8+dxgw@mail.gmail.com>
Message-ID: <20200228094347.GA6322@SDF.ORG>

On Fri, Feb 28, 2020 at 01:02:43AM -0600, Andrew Singleton wrote:
 
> Also hi, I'm new here. I unfortunately don't have any real technical
> background. I just like the idea of a sort of middle ground between HTTP
> and Gopher that's still 'advertising and bloat hostile.' Given my poor
> vision and my interest in low bandwidth networking a text centric thing
> suits me.

Welcome, glad you like the goals of the project!

I had actually been planning to make a spec change this weekend, which
would add to the text/gemini definition the verbatim text block idea
(since nobody spoke out strongly, or even weakly, in opposition to it
after my last email on the subject) as well as a *subset* of the
strictly optional extra features we discussed, including e.g. headings
beginning with # and non-nested unordered lists with *, both as per
CommonMark.

Further, after making that change I plan to decree "absolutely no spec
changes for at least six months (or maybe three, let's see how extreme
I'm feeling on Sunday), unless some kind of horrible serious problem is
discovered (I can't imagine what that could be)".  I don't even want to
seriously *discuss* possible spec changes for that long.

The reason for this is that we are operating far too much in a vacuum.
There is still very little original content in Geminispace, and even
less of it which isn't *about* Gemini.  There are plenty of features in
the current spec which nobody has used yet, as far as I know, or have
not been used for anything other than fun little tests.  We have
multiple server implementations, multiple client implementations and
now even a search engine!  I have offered free Geminispace at
gemini.circumlunar.space to anybody who wants it.  It is high time for
us to actually build stuff with what we have achieved so far.

Cheers,
Solderpunk

From ciprian.craciun at gmail.com  Fri Feb 28 10:04:19 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Fri, 28 Feb 2020 12:04:19 +0200
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <20200228090709.GB16159@brevard.conman.org>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
Message-ID: <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>

On Fri, Feb 28, 2020 at 11:07 AM Sean Conner <sean at conman.org> wrote:
>   Why is a numeric status code so bad?  Yes, the rest of the protocol is
> English centric (MIME types; left-to-right, UTF-8).  It just seems that
> using words (regardless of language) is just complexity for its own sake.


Why did people use `/etc/hosts` files before DNS was invented?  Why do
we have `/etc/services`?  Why do we have `O_READ`?  Why do we have
`chmod +x`?

Because numbers are hard to remember, and say nothing to a person that
doesn't know the spec by heart.  (For example although I do a lot of
HTTP related work with regard to routing and such, I always don't
remember which of the 4-5 HTTP redirect codes says "temporary redirect
but keep the same method" as "opposed to temporary redirect but switch
to `GET`".)




> > As minor issues:
> > * why `CRLF`?  it's easier (both in terms of availability of functions
> > and efficiency) to split lines by a single character `\n` than by a
> > string;
>
>   That was discussed earlier on the list:
>
>         https://lists.orbitalfox.eu/archives/gemini/2019/000116.html


OK, reading that email the answer seems to be "because other protocols
have it"...  And even you admit that in your own code you also handle
just `LF`.

So then why bother?  Why not simplify the protocol?




> > > > On a second thought, why TLS?  Why not something based on NaCL /
> > > > `libsodium` constructs, or even the "Noise Protocol"
> > > > (http://www.noiseprotocol.org/)?
> > >
> > >         1) Never, *NEVER* implement crypto yourself.
> >
> > I was never proposing to implement crypto ourselves.  `libsodium` /
> > NaCL provides very useful high-level constructs, tailored for specific
> > use-cases (like for example message encryption and signing), that are
> > proven to be safe, and exports them with a very simple API that can be
> > easily understood and used.
>
>   TLS was choosen because the COMMUNICATIONS LINK is encrypted, not just the
> payload.  All Eve (the evesdropper) can see is what IP address you are
> connecting to, not what content you are reading, nor (depending upon the TLS
> version) what virtual server you might be talking to.


Although I do agree that encryption at the "transport" level to hide
the entire traffic is a good idea, if you take into account that
`gemini://` requires one request and one reply per TCP connection
(thus TLS connection), there is no actual "communications link here".

Basically you are using TLS to encrypt only one payload.  Moreover
also because there is exactly one request / one reply one can just
look at the traffic pattern and deduce what the user is doing just by
analyzing the length of the stream (in both ways) and the time the
server takes to respond (which says static or dynamically generated).
(Granted TLS records are padded, however even so, having the size as
multiple of some fixed value, still gives an insight into what was
requested.)

For example say lives in a country where certain books (perhaps about
cryptography) are forbidden;  now imagine there is a library out there
that serves these books through `gemini://`;  now imagine the country
wants to see what books are read by its own citizens;  all it has to
do is record each session and deduce a response size range, then crawl
that library and see which books fit into that range.

Therefore I would say (I'm no cryptographer) TLS doesn't help at all,
einter does PGP, either `libsodium` / NaCL...




Another related topic regarding TLS that just struck me:  given that
`gemini://` supports out-of-the-box virtual hosts, do you couple that
with TLS SNI?

If not basically TLS is just an "obfuscation" than actual end-to-end
encryption.  Why I say that:  because the spec says one should use
SSH-style "do you trust this server" questions and keep that
certificate in mind.  But how about when the certificate expires, or
is revoked?  (SSH server public keys never expire...)  How does the
user know that the certificate was rightfully replaced or he is a
victim of an MITM attack?




> > > > Why not just re-use PGP to sign / encrypt requests and replies?  With
> > > > regard to PGP,
> > >
> > >   There are issues with using PGP:
> > >
> > >         https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
> >
> > There are issues with any technology, TLS included.
> >
> > However I would say it's easier to integrate GnuPG (even through
> > subprocesses) in order to encrypt / decrypt payloads (especially given
> > how low in count they are for Gemini's ecosystem) than implementing
> > TLS.  Moreover it offers out-of-the-box the whole client side
> > certificate management, which adding to a TLS-based client would be
> > much more involved, more on this bellow...
>
>   As I have mentioned, that only protects the payload, not the
> communications channel.


But as said, you don't have an actual communications channel because
you use TLS for a single request / reply payload pair...  :)




> > >   The hardest problem with crypto is key management.  If anything, key
> > > management with PGP seems more problematic than with OpenSSL and the CA
> > > infrastructure (as bad as the CA infrastructure is).
> >
> > One of the `gemini://` specifications explicitly states that the
> > server certificate authentication model is similar to SSH's first use
> > accept and cache afterward.  However say you'll go with the actual CA
> > model, now you need to juggle Let's Encrypt (each 3 months) (or add
> > support for ACME in your server), then juggle PEM files, etc.
> > Regardless, either way one will have to implement all this certificate
> > management from scratch.
>
>   Or self-signed certificates.
>
>   Okay, we use NaCL.  Now what?  What's needed to secure the communication
> channel?  A key exchange.  Again, rule 1---never implement crypto.


Given that one has the public key of the server (more on that later),
one could use the following on client / server sides:

    https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes

```
The crypto_box_seal() function encrypts a message m of length mlen for
a recipient whose public key is pk. It puts the ciphertext whose
length is crypto_box_SEALBYTES + mlen into c.

The function creates a new key pair for each message, and attaches the
public key to the ciphertext. The secret key is overwritten and is not
accessible after this function returns.

The crypto_box_seal_open() function decrypts the ciphertext c whose
length is clen, using the key pair (pk, sk), and puts the decrypted
message into m (clen - crypto_box_SEALBYTES bytes).
```

How does one get the public key of the server?  One could change the
protocol so that the server speaks first and sends its own public key.


My take on this:  given a set of clear requirements for the
`gemini://` protocol (which I've seen there are) one can come up with
better solutions than TLS, ones that better fit the use-case.

(Again, just to be clear, I'm not saying "lets invent our own crypto",
but instead "let's look at other tested" alternatives.  As a
side-note, NaCL, on which `libsodium` is based, was created by `Daniel
J. Bernstein`...)




> > > > Regarding an up-to-date Gopher map alternative, I think this is an
> > > > important piece of the Gopher ecosystem that is missing from today's
> > > > world:  a machine-parsable standard format of indexing documents.  I
> > > > very fondly remember "directory" sites of yesteryear (like DMOZ or the
> > > > countless other clones) that strives to categorize the internet not by
> > > > "machine learning" but by human curation.
> > >
> > >   Could you provide an example of what you mean by this?  I'm not sure why a
> > > map alternative is needed.
> >
> > One problem with today's web is that the actual "web structure" is
> > embedded in unstructured documents as links.  What I liked about
> > Gopher maps is that it gave a machine-readable, but still
> > user-friendly, way to map and categorize the "web contents".
>
>   One problem with that---incentives.  What's my incentive to make all this
> information more easily machine readable?  On the web, you do that, and what
> happens?  Google comes along, munches on all that sweet machine readable
> data and serves it up directly to users, meaning the user just has to go to
> Google for the information, not your server.  Given those incentives, I have
> no reason to make my data easily machine readable when it means less
> traffic.


The incentive is a clear one:  for the end-user.  Given that we can
standardize on such an "index", then we can create better
"user-agents" that are more useful to our actual users.  (And I'm not
even touching on the persons that have various disabilities that
hamper their interaction with computers.)

For example say I'm exposing a API documentation via `gemini://`.  How
do I handle the "all functions index page"?  Do I create a large
`text/gemini` file, or a large HTML file?  How does the user interact
with that?  With search?  Wouldn't he be better served by a searchable
interface which filters the options as he types, like `dmenu` / `rofi`
/ `fzf` (or the countless other clones) do?  (Currently each
programming language from Rust to Scheme tries to do something similar
with JavaScript and the result is horrible...)

Or, to take another approach, why do people use Google to search
things?  Because our web pages are so poor when it comes to
structuring information, that most often than not, when I want to find
something on a site I just Google: `site:example.com the topic i'm
interested in`.




>   I recall the large push for RDF (Resource Description Framework) back
> around 2004 or so ... embed machine parsable relations and metadata and it
> would be oh so wonderful.  Some people even bothered to to all that work.
> And for what?  It was a pain to maintain, the tooling was poor, and Google
> would just suck it up and serve it to users directly, no reason for anyone
> to actually visit your site.

I'm not advocating for RDF (it was quite convoluted) or semantic web,
or GraphQL, etc.  I'm just advocating something better than the Gopher
map.




>   As a user, that's great!  As a web site operator, not so much.


OK...  Now here is something I don't understand:  aren't you building
Gemini sites for "users"?  You are building it for "operators"?

Because if the operator is what you optimize for, then why not just
SSH into the operator's server where he provides you with his
"favourite" BBS clone.




> > > > * and perhaps add support for content-based addressing (as opposed to
> > > > server-based addressing) (i.e. persistent URL's);
> > >
> > >   There already exist such protocols---I'm not sure what a new one based
> > > around Gemini would buy.
> >
> > I agree that `gemini://` is first and foremost a "transfer" protocol.
> > However one can include a document's identity as a first class citizen
> > of the protocol.
> >
> > For example say each document is identified by its SHA;  then when
> > replying with a document also send that SHA in form of a permanent URL
> > like say `gemini-object:?sha={SHA}&location=gemini://first-server/...&location=gemini://second-server/...`;
> >  then a client (that perhaps has bookmarked that particular version of
> > that document) could send that URL to a server (of his choosing via
> > configuration, to the first one specified in `location`, etc.) and if
> > that server has that document just reply with that, else use
> > `location`, else return 404.
>
>   Hey, go ahead and implement that.  I'd like to see that ...


There is already FreeNet and IPFS that implement content-based
addressing.  I just wanted something in between that is still
"location" driven, but is "content identity" aware.

Ciprian.

From ciprian.craciun at gmail.com  Fri Feb 28 10:20:16 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Fri, 28 Feb 2020 12:20:16 +0200
Subject: Is it too late to consider adding a subset of Markdown to the
 render spec?
In-Reply-To: <20200228094347.GA6322@SDF.ORG>
References: <CAPBeim4kNFVZHcShTfuH3cyiZQHBoAbs-+wDO85y+e-v8+dxgw@mail.gmail.com>
 <20200228094347.GA6322@SDF.ORG>
Message-ID: <CA+Tk8fy9pAJdMSWpsRDG0H6wehd9+9TbKmbMaGreZiPgO5Zm6Q@mail.gmail.com>

On Fri, Feb 28, 2020 at 11:44 AM solderpunk <solderpunk at sdf.org> wrote:
> I had actually been planning to make a spec change this weekend, which
> would add to the text/gemini definition the verbatim text block idea
> (since nobody spoke out strongly, or even weakly, in opposition to it
> after my last email on the subject) as well as a *subset* of the
> strictly optional extra features we discussed, including e.g. headings
> beginning with # and non-nested unordered lists with *, both as per
> CommonMark.


If you are adding a good portion of CommonMark to the specification,
then why not make take a sub-set of CommonMark?

For example:
* restrict the usage of nested lists;
* restrict in-line links and say that "all links should follow the
syntax `=> link description`";  (or even better `=>
[description](link)`)
* restrict horizontal breaks to only `---`;
* etc;

Then no-one needs to re-implement yet another markup language, and can
just re-use their favourite CommonMark parser and feed it this
sub-set.

Granted this would open the door for people to just ignore the spec
and use full CommonMark syntax, but then one could implement "linters"
on the server side (or even in the client side) to check that only the
Gemini sub-set syntax is used.




> Further, after making that change I plan to decree "absolutely no spec
> changes for at least six months (or maybe three, let's see how extreme
> I'm feeling on Sunday), unless some kind of horrible serious problem is
> discovered (I can't imagine what that could be)".  I don't even want to
> seriously *discuss* possible spec changes for that long.


Why not add a version like `text/x-gemini-2020-03`?


Moreover section 6 of RFC 2046 (governing the MIME types) states:

    https://tools.ietf.org/html/rfc2046#section-6

~~~~
A media type value beginning with the characters "X-" is a private
value, to be used by consenting systems by mutual agreement.  Any
format without a rigorous and public definition must be named with an
"X-" prefix, and publicly specified values shall never begin with
"X-".
~~~~

Ciprian.

From solderpunk at SDF.ORG  Fri Feb 28 22:32:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 28 Feb 2020 22:32:35 +0000
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
Message-ID: <20200228223235.GA8734@SDF.ORG>

On Fri, Feb 28, 2020 at 01:16:30AM +0200, Ciprian Dorin Craciun wrote:
> Hello all!
> 
> Today I've stumbled upon the `gemini://` protocol specification
> (v0.10) and FAQ, and after reading them both, I thought that perhaps
> an "outsiders" point of view could be useful.

Howdy!

Thanks very much for taking the time to provide this outside
perspective.  I've done my best to take your comments in the
constructive fashion you intended them.  I'm going to reply relatively
briefly to some major points below - please don't take brevity as me
being dismissive, it's more to do with my available time!
 
> * caching -- given that most content is going to be static, caching
> should be quite useful;  however it doesn't seem to have been present
> as a concern neither in the spec, FAQ or the mailing list archive;
> I'm not advocating for the whole HTTP caching headers, but perhaps for
> a simple SHA of the body so that clients can just skip downloading it
> (although this would imply a more elaborate protocol, having a
> "headers" and separate "body" phase);

Not just a more elaborate protocol (although that does count, by itself,
against caching, as implementation simplicity is a driving goal of the
protocol), but a more extensible protocol.  I've fought since day one
against anything that acts to divide the response header into parts,
equivalent to the multiple header lines of HTTP.  Extensibility, for all
its benefits, is the eventual death of simplicity.

Caching is not a bad thing, but it pays off the most for large content.
Leaving caching out actively encourages content producers to make their
content as small as possible.  I like that.
 
> * compression -- needless to say that `text/*` MIME types compress
> very well, thus saving both bandwidth and caching storage;  (granted
> one can use compression on the TLS side, although I think that one was
> dropped due to security issues?);

As above, compression is not a bad thing, but for small content the
benefit is not proportionate to the implementation effort.  Gopherspace
is an existence proof that worthwhile textual content can be served
uncompressed and still be orders of magnitude smaller than the average
website which *does* use compression.

You're right about TLS compression having security problems.

> * `Content-Length` -- I've seen this mentioned in the FAQ or the
> mailing lists;  I think the days of "unreliable" protocols has passed;
>  (i.e. we should better make sure that the intended document was
> properly delivered, in its entirety and unaltered;)

This is definitely the biggest existing pain point in Gemini so far, I
think.  I might write about this in another email.  I still think for
various reasons we can live without this, but I won't swear that if the
right solution is proposed I won't consider it.

Someone did mention earlier on the list that TLS has a way to explicitly
signal a clean shut down of a connection, which would provide "in its
entirety".

> * status codes -- although both Gemini and HTTP use numeric status
> codes, I do believe that these are an artifact of ancient times, and
> we could just replace them with proper symbols (perhaps hierarchical
> in nature like `redirect:temporary` or `failure:temporary:slow-down`;

This seems to me like extra bytes with very little benefit?  The status
codes are supposed to be machine-readable, so what's wrong with numbers?

> * keep-alive -- although in Gopher and Gemini the served documents
> seem to be self-contained, and usually connections will be idle while
> the user is pondering what to read, in case of crawlers having to
> re-establish each time a new connection (especially a TLS one) would
> eat a lot of resources and incur significant delays;  (not to mention
> that repeated TCP connection establishment to the same port or target
> IP might be misinterpreted as an attack by various security appliances
> or cloud providers;)

The overhead of setting up a new TLS connection each time is a shame.
TLS 1.3 introduces new functionality to reuse previously negotiated
content, which is currently not widely supported in a lot of libraries
but I hope that this will become easier in the future and ease some of
the pain on this point.
 
> Now on the transport side, somewhat related to the previous point, I
> think TLS transient certificates are an overkill...  If one wants to
> implement "sessions", one could introduce
> "client-side-generated-cookies" which are functionally equivalent to
> these transient certificates.  Instead of creating a transient
> certificate, the client generates a unique token and sends that to the
> server instead.  The server has no more control over the value of that
> cookie as it does for the transient certificate.
>
> Moreover the way sessions are signaled between the server and client,
> piggy-backed ontop of status codes, seems rather an afterthought than
> part of an orthogonal design.  Perhaps these sessions should "moved"
> to a higher level (i.e. after transport and before the actual
> transaction, just like in the case of OSI stack).
 
This is all true, but once client certificate support was already in the
protocol for reasons unrelated to sessions, since it was *possible* to
implement sessions using client certificates instead of adding some new
part to the protocol, I chose to do it.  This is part of the "maximise
power to weight" principle that has guided Gemini's design.  Once you
are paying the weight penalty for some part of the protocol, you should
extract as much power from it you can by using it to solve any problem
you can.  This will lead to somewhat clunky solutions to problems
cobbled together from two or three exisitng parts, even when there is an
obvious neater solution that could be achieved with one non-existing
part, but I'm okay with that.
 
> Also these transient certificates are sold as "privacy enablers" or
> "tracking preventing" which is far from the truth.  The server (based
> on IP, ASN or other information) can easily map various transient
> certificates as "possibly" belonging to the same person.  Thus just by
> allowing these one opens up the possibility of tracking (even if only
> for a given session).  Moreover, securely generating these transient
> certificates does require some CPU power.

But servers can do that with raw requests anyway, right?

The CPU power point is well taken, believe me.  I have considered having
the spec (or maybe this belongs in our Best Practices document)
encourage implementers to support and to prefer the computationally
lighter ciphers in TLS (e.g. the ChaCha stream cipher).
 
> On a second thought, why TLS?  Why not something based on NaCL /
> `libsodium` constructs, or even the "Noise Protocol"
> (http://www.noiseprotocol.org/)?

Mostly because TLS library support is much more wide spread than
anything else.

> For example I've tried to build the
> Asuka Rust-based client and it pulled ~104 dependencies and took a few
> minutes to compile, this doesn't seem too lightweight...

A slight off-topic rant:  That's not Asuka's fault, it's not TLS's fault
and it's not Gemini's fault, that's Rust's fault.  Every single Rust
program I have ever tried to build has had over 100 dependencies.  Every
single one has had at least one dependency with a minimum required
version (of either the library, or Rust itself) which was released only
yesterday.  The Rust toolchain and community seem to support and even
actively encourage this unsustainable approach to development.  It
strikes me (as an outsider!) as a total mess.
 
> Why not just re-use PGP to sign / encrypt requests and replies?  With
> regard to PGP, given that Gopher communities tend to be quite small,
> and composed of mostly "techie" people, this goes hand-in-hand with
> the "web-of-trust"

I would prefer not to do anything like explicitly designing Gemini to
cater to a small and tight-knit group of techies.  I know it's that now,
and maybe that's all it will ever be, but I would like to give it a
decent chance of being more.

There is an `application/pgp-encrypted` MIME type that Gemini can serve
content with, and people can write clients that to handle this, so
Gemininaut cypherpunks can do this if they want to!

> Now getting back to the `gemini://` protocol, another odd thing I
> found is the "query" feature.  Gemini explicitly supports only `GET`
> requests, and the `text/gemini` format doesn't support forms, yet it
> still tries to implement a "single input-box form"...  Granted it's a
> nice hack, but it's not "elegant"...  (Again, like in the case of
> sessions, it seems more as an afterthought, even though this is the
> way Gopher does it...)

> Perhaps a simple "form" solution would be better?  Perhaps completely
> eliminating for the time these "queries"?  Or perhaps introducing a
> new form of URL's like for example:
> `gemini-query:?url=gemini://server/path&prompt=Please+enter+something`
> which can be served either in-line (as was possible in Gopher) and /
> or served as a redirect (thus eliminating another status code family).

I did, back during the long, drawn-out contemplation of whether to use
one, two or three digit status codes, consider having the META content
for query status be a string in some kind of small DSL for defining a
form, but decided against it.  You can simulate the effect using a
sequency of "single input forms" tied together with a client certificate
session.  This is, IMHO, "elegant" in it's own way - a FORTHy kind of
elegance where you build complicated things up by combining a small set
of sharp primitives in creative ways.

> Regarding the `text/gemini` format -- and taking into account various
> emails in the archive about reflowing, etc -- makes me wonder if it is
> actually needed.  Why can't CommonMark be adopted as the HTML
> equivalent, and a more up-to-date Gopher map variant as an alternative
> for menus?  There are already countless safe CommonMark parsers
> out-there (for example in Rust there is one implemented by Google) and
> the format is well understood and accepted by a large community
> (especially the static side generators community).

Sorry, I'm still too busy recovering from the trauma of our text/gemini
discussion around Markdown to respond to this now. :)
 
> All in all I find the `gemini://` project quite interesting, and I'll
> keep an close eye on it.

Please do!  And please continue to share your thoughts with us here.  I
hope it doesn't seem to much like I've not taken some of your points
seriously enough and have just stubbornly stuck to previous decisions.
I really do see challenging questions regarding our design decisions as
valuable things, and tried to consider your questions seriously - and
I'll continue to do so in coming days.

Cheers,
Solderpunk


From sean at conman.org  Fri Feb 28 22:41:48 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 28 Feb 2020 17:41:48 -0500
Subject: Is it too late to consider adding a subset of Markdown to the
 render spec?
In-Reply-To: <CA+Tk8fy9pAJdMSWpsRDG0H6wehd9+9TbKmbMaGreZiPgO5Zm6Q@mail.gmail.com>
References: <CAPBeim4kNFVZHcShTfuH3cyiZQHBoAbs-+wDO85y+e-v8+dxgw@mail.gmail.com>
 <20200228094347.GA6322@SDF.ORG>
 <CA+Tk8fy9pAJdMSWpsRDG0H6wehd9+9TbKmbMaGreZiPgO5Zm6Q@mail.gmail.com>
Message-ID: <20200228224148.GD16159@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> 
> Why not add a version like `text/x-gemini-2020-03`?
> 
> Moreover section 6 of RFC 2046 (governing the MIME types) states:
> 
>     https://tools.ietf.org/html/rfc2046#section-6
> 
> ~~~~
> A media type value beginning with the characters "X-" is a private
> value, to be used by consenting systems by mutual agreement.  Any
> format without a rigorous and public definition must be named with an
> "X-" prefix, and publicly specified values shall never begin with
> "X-".
> ~~~~

  RFC-6648 deprecates that practice (surprised me too when it was pointed
out to me).  So either:

	text/x-gemini-2020-03

or

	text/gemini-2020-03

would be fine.  

  -spc


From aaron at ajanse.me  Fri Feb 28 23:21:30 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Fri, 28 Feb 2020 15:21:30 -0800
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <20200228223235.GA8734@SDF.ORG>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228223235.GA8734@SDF.ORG>
Message-ID: <ea14fc2c-731a-46dc-b0d8-e27d86735396@www.fastmail.com>

> The CPU power point is well taken, believe me.  I have considered having
> the spec (or maybe this belongs in our Best Practices document)
> encourage implementers to support and to prefer the computationally
> lighter ciphers in TLS (e.g. the ChaCha stream cipher).

This would be awesome. This would be really nice for people like me who
dream of one day implementing all the protocols for Gemini from scratch.
TLS 1.3's Salsa20 & Poly1305 are much easier to implement than other
protocols (yes, yes, "don't write your own crypto," but my goal here
is novelty, not security of my specific client).

> There is an `application/pgp-encrypted` MIME type that Gemini can serve
> content with, and people can write clients that to handle this, so
> Gemininaut cypherpunks can do this if they want to!

Please no. PGP is a bit of a mess already. It's tough to install/maintain
(because it has a daemon), and it's really easy to mess up. I think using
something like NaCl could be much more difficult to mess up than automated
PGP.

---

Thanks again, everyone, for the thoughtful discussion. While I disagree on this
topic, I'm very optimistic about and excited by the future of Gemini of a whole.

Cheers!
Aaron Janse

From sean at conman.org  Fri Feb 28 23:42:01 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 28 Feb 2020 18:42:01 -0500
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
Message-ID: <20200228234201.GE16159@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Fri, Feb 28, 2020 at 11:07 AM Sean Conner <sean at conman.org> wrote:
> >   Why is a numeric status code so bad?  Yes, the rest of the protocol is
> > English centric (MIME types; left-to-right, UTF-8).  It just seems that
> > using words (regardless of language) is just complexity for its own sake.
> 
> 
> Why did people use `/etc/hosts` files before DNS was invented?  Why do
> we have `/etc/services`?  Why do we have `O_READ`?  Why do we have
> `chmod +x`?

  True, but parsing the status code character by character is only one way
of doing it.  Another way to to just convert it to a number and do that
comparison.  When doing HTTP releated things [1], I do have named constants
like HTTP_OKAY and HTTP_NOTFOUND.

> Because numbers are hard to remember, and say nothing to a person that
> doesn't know the spec by heart.  (For example although I do a lot of
> HTTP related work with regard to routing and such, I always don't
> remember which of the 4-5 HTTP redirect codes says "temporary redirect
> but keep the same method" as "opposed to temporary redirect but switch
> to `GET`".)

  But you have that anyway.  I have HTTP_MOVETEMP (hmmm, why isn't it
HTTP_REDIRECT_TEMPORARY?  I have to think on that ... ) but even then, I
have to know that causes clients to switch to GET and if I don't want that,
I have to use HTTP_MOVETEMP_M (hmm ... I almost typed HTTP_MOVETMP_M ...
something else to think about).  So even with symbolic names there are
issues.

  Perhaps it's me, but I don't mind looking up things if I don't recall
them.  I've been programming in C for 30 years now.  I *still* have to look
up the details to strftime() every single time I use it, but I recall that
rand() returns a number between 0 and MAX_RAND (inclusive), yet I use
strftime() way more often than I do rand().  

> > > As minor issues:
> > > * why `CRLF`?  it's easier (both in terms of availability of functions
> > > and efficiency) to split lines by a single character `\n` than by a
> > > string;
> >
> >   That was discussed earlier on the list:
> >
> >         https://lists.orbitalfox.eu/archives/gemini/2019/000116.html
> 
> OK, reading that email the answer seems to be "because other protocols
> have it"...  And even you admit that in your own code you also handle
> just `LF`.
> 
> So then why bother?  Why not simplify the protocol?

  True, but there's the 800-pound gorilla to consider---Windows.  On
Windows, a call like:

	fgets(buffer,sizeof(buffer),stdin);

will read the next line into the buffer, and automatically convert CRLF into
just LF.  That's because Windows uses CRLF to mark end of lines.  It got
that from MS-DOS, which got that from CP/M, which got that from RT-11, which
got that from (I suspect) a literal interpretation of the ASCII spec from
the mid-60s [2].  Also the RFCs written in the 70s describing the early work
of the Internet also used a literal interpretation of ASCII.

  So there's a lot of protocols defined for the Internet that use CRLF. 
Could a switch be made to just LF?  Sure.  It's also about as likely as the
Internet byte order being switched from big-endian to little-endian.

> >   Okay, we use NaCL.  Now what?  What's needed to secure the communication
> > channel?  A key exchange.  Again, rule 1---never implement crypto.
> 
> 
> Given that one has the public key of the server (more on that later),
> one could use the following on client / server sides:
> 
>     https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes

  There's this wonderful talk by John Carmack:

	https://www.youtube.com/watch?v=dSCBCk4xVa0

which talks about ideas, and what might seem a good idea isn't when it comes
to an actual implementation.

  The linked page just talks about an API for signing and ecrypting data. 
It says nothing about negotiating the cipher, key size, or anything remotely
like a protocol.  I would ask that if you feel this strongly about it, *do
it!*  Implement a client and server that uses these alternative crypto
systems and then we'll have something to talk about.

  When solderpunk first designed Gemini, I didn't agree with all his
descisions (especially the status codes), but I was interested.  I also
wanted to play around with TLS since I had finished writing a Lua interface
for libtls.  So I wrote my own server, with what I felt the status codes
should be.  The thing was---*there was a working implementation* that was
used to argue certain points.  And through that, we got the compromise of
the current status codes.

  You can argue for an idea.  But an idea *and an implementation* is
stronger than just the idea.  I think that's why my Gemini server is so
featureful---I went ahead and implemented my ideas to help argue for/against
ideas, or even to just present *something* to talk about (when I have no
opinion one way or the other).

> My take on this:  given a set of clear requirements for the
> `gemini://` protocol (which I've seen there are) one can come up with
> better solutions than TLS, ones that better fit the use-case.

  So do it.  One of the goals for Gemini is ease of implemetation (of both
the server and the client), so this will go a long way to showing how easy
it is to implement your ideas.

> (Again, just to be clear, I'm not saying "lets invent our own crypto",
> but instead "let's look at other tested" alternatives.  As a
> side-note, NaCL, on which `libsodium` is based, was created by `Daniel
> J. Bernstein`...)

  Yes, I am aware of that.  I even installed djb's version of NaCL and
played around with it.  It's nice, but a protocol it is not.

> >   One problem with that---incentives.  What's my incentive to make all this
> > information more easily machine readable?  On the web, you do that, and what
> > happens?  Google comes along, munches on all that sweet machine readable
> > data and serves it up directly to users, meaning the user just has to go to
> > Google for the information, not your server.  Given those incentives, I have
> > no reason to make my data easily machine readable when it means less
> > traffic.
> 
> The incentive is a clear one:  for the end-user.  Given that we can
> standardize on such an "index", then we can create better
> "user-agents" that are more useful to our actual users.  (And I'm not
> even touching on the persons that have various disabilities that
> hamper their interaction with computers.)

  Okay, how does that incentivise me?

  It's easy enough to add machine readable annotations to HTML.  Heck, there
are plenty of semantic tags in HTML to help with machine readability.  Yet
why don't more people hand-code HTML?  Why is Markdown, which, I will add,
has no defined way of adding metadata except by including HTML, so popular?

> For example say I'm exposing a API documentation via `gemini://`.  How
> do I handle the "all functions index page"?  Do I create a large
> `text/gemini` file, or a large HTML file?  How does the user interact
> with that?  With search?  Wouldn't he be better served by a searchable
> interface which filters the options as he types, like `dmenu` / `rofi`
> / `fzf` (or the countless other clones) do?  (Currently each
> programming language from Rust to Scheme tries to do something similar
> with JavaScript and the result is horrible...)

  PHP (which I don't like personally) has incredible documentation, but the
PHP developers put a lot of work into creating the system to enable that. 
It's not just "make machine readable documentation" and poof---it's done.

  I would say that's mostly tooling, not an emergent property of HTML.

> Or, to take another approach, why do people use Google to search
> things?  Because our web pages are so poor when it comes to
> structuring information, that most often than not, when I want to find
> something on a site I just Google: `site:example.com the topic i'm
> interested in`.

  Web search engines were not initially designed to find stuff on a given
site, it was to find sites you didn't even knew existed, period.  The web
quickly grew from "here's a list of all known web sites" to "there's no way
for a single person to know what's out there."  Since then Google has grown
to be a better index of sites than sites themselves (although I think Google
isn't quite as good as it used to be).

  Creating and maintaining a web site structure isn't easy, and it's all too
easy to make a mistake that is hard to rectify, and I speak from experience
since my website [3] is now 22 years old [4], and I have a bunch of
redirects to rectify past organizational mistakes (and redirects were
another aspect I had to argue to add to Gemini, by the way---the
implemetation helped).

> I'm not advocating for RDF (it was quite convoluted) or semantic web,
> or GraphQL, etc.  I'm just advocating something better than the Gopher
> map.

  Okay, create a format and post it.  That's the best way to get this
started.

> >   As a user, that's great!  As a web site operator, not so much.
> 
> OK...  Now here is something I don't understand:  aren't you building
> Gemini sites for "users"?  You are building it for "operators"?

  I'm building it primarily for me.  Much like my website (and gophersite
[5]) is mostly for my own benefit---if others like it, cool!  But it's not
solely for others.

> Because if the operator is what you optimize for, then why not just
> SSH into the operator's server where he provides you with his
> "favourite" BBS clone.

  Those do exist, but that's not something I want to do.

> >   Hey, go ahead and implement that.  I'd like to see that ...
> 
> There is already FreeNet and IPFS that implement content-based
> addressing.  I just wanted something in between that is still
> "location" driven, but is "content identity" aware.

  Again, what's stopping you from just doing it?  Waiting for consensus? 
Have you read the thread on text formatting?  It's literally half the
messages to this list.  I do have to wonder how far along Gemini would be if
I had not just gone ahead and implented a server.

  -spc (In my opinion, working code trumps ideas ... )

[1]	Like my blog engine, written in C:

	https://github.com/spc476/mod_blog

[2]	A close reading of the actual ASCII standard reveals two control
	codes, CR and LF.  CR is defined as "returning the carriage head
	back to the start of a line" and LF is defined as "advancing to the
	next line, without changing the position of the carriage." So a
	literal reading of the spec says if you want to advance to the start
	of the next line, you send both a CR and LF.  There is no control
	code defined by ASCII that means "return the carriage to the start
	of the line and advance to the next line." There *is* such a control
	character, NEL, but that's defined by the ISO, not ANSI (and it
	happens to be either character 133 or <ESC>E).

	Over time, some systems have adpoted one or the other to mean
	"return carriage to start of line and advance to next line." Most
	8-bit systems I've experienced used CR for that.  Unix picked LF.  A
	few (mostly DEC influenced, like CP/M) used both.

	The RFCs written in the 70s (when the Internet was first being
	developed) used a more literal imterpretation of the ASCII standard
	and required both CRLF to mark the end of the line.

	There is also a similar issue with backspace.  ASCII defines BS as
	"move the carriage to the previous character position; if at the
	start of the line, don't do anything." DEL is defined as "ignore
	this character." Neither one means "move back one space and erase
	the character".  BS was intended to be used to create characters not
	defined by ASCII, like ? by issuing the sequence

		a<BS>"

	Over time, different systems have implemented the "move back one
	space and erase the character" by using either BS or DEL.

[3]	http://www.conman.org/

[4]	At the current domain.  It's a bit older than that, but it was under
	a different domain I didn't control, which is why my personal pages
	are under:

		http://www.conman.org/people/spc/
	
	and not the top level.  That move was painful enough as it was.

[5]	gopher://gopher.conman.org/

From ciprian.craciun at gmail.com  Sat Feb 29 07:35:02 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Sat, 29 Feb 2020 09:35:02 +0200
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <20200228234201.GE16159@brevard.conman.org>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
 <20200228234201.GE16159@brevard.conman.org>
Message-ID: <CA+Tk8fy2d0i_d4xrTac+BhR+PAnmH87Zn-JyiNgL5+beV21CkQ@mail.gmail.com>

On Sat, Feb 29, 2020 at 1:42 AM Sean Conner <sean at conman.org> wrote:
>   Perhaps it's me, but I don't mind looking up things if I don't recall
> them.  I've been programming in C for 30 years now.  I *still* have to look
> up the details to strftime() every single time I use it, but I recall that
> rand() returns a number between 0 and MAX_RAND (inclusive), yet I use
> strftime() way more often than I do rand().


When one is developing code then yes, looking up things in the
documentation is OK.  However when one is reading code, looking in the
documentation breaks your focus.




> > OK, reading that email the answer seems to be "because other protocols
> > have it"...  And even you admit that in your own code you also handle
> > just `LF`.  [...]
>
>   True, but there's the 800-pound gorilla to consider---Windows.  On
> Windows, a call like:
> [...]
>
>   So there's a lot of protocols defined for the Internet that use CRLF.
> Could a switch be made to just LF?  Sure.  It's also about as likely as the
> Internet byte order being switched from big-endian to little-endian.


OK, I'll drop the CRLF thing, but I find it odd that the only argument
to this is "because systems and protocols designed many years ago did
this (i.e. CRLF)", and to that you add "but anyway, all these systems
just ignore all that and behave internally like it wasn't so (i.e.
convert CRLF into LF)"...




As a minor note, I've seen C mentioned a lot of times, but please take
into account that many projects aren't developed in C anymore, but
instead in Python / Ruby / Go / Rust / other "newer" languages, that
are much easier to develop in than C.  Case in point, out of the 3
clients for Gemini, one is in Go, one in Rust and the other in
Python...




> > >   Okay, we use NaCL.  Now what?  What's needed to secure the communication
> > > channel?  A key exchange.  Again, rule 1---never implement crypto.
> >
> >
> > Given that one has the public key of the server (more on that later),
> > one could use the following on client / server sides:
> >
> >     https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes
>
>   The linked page just talks about an API for signing and ecrypting data.
> It says nothing about negotiating the cipher, key size, or anything remotely
> like a protocol.


(I have a hunch that you are not "acquainted" with NaCL / `libsodium`;
 the short story is this:  the designers of NaCL (again including
Daniel J. Bernstein) wanted to design and implement a secure, simple
to use, high level cryptographic library, that makes all the choices
for its users, so that ciphers, key sizes, padding, nonces, etc.,
aren't required to be handled by the user, and thus no mistakes would
be made on this front.)

In fact that link does say at the end under the section `Algorithm
details` what happens behind the scenes:

~~~~
Sealed boxes leverage the crypto_box construction (X25519, XSalsa20-Poly1305).

The format of a sealed box is:

ephemeral_pk || box(m, recipient_pk, ephemeral_sk,
nonce=blake2b(ephemeral_pk || recipient_pk))
~~~~




> I would ask that if you feel this strongly about it, *do
> it!*  Implement a client and server that uses these alternative crypto
> systems and then we'll have something to talk about.


What is the chance you'll change your mind about TLS?  0.01%?  Are you
actually considering to compare TLS vs another proposal without bias
towards "legacy `gemini://` implementations currently using TLS"?




>   You can argue for an idea.  But an idea *and an implementation* is
> stronger than just the idea.  I think that's why my Gemini server is so
> featureful---I went ahead and implemented my ideas to help argue for/against
> ideas, or even to just present *something* to talk about (when I have no
> opinion one way or the other).


Perhaps I'll throw a proof-of-concept in Python or Go.  (Although as
said above, I think it won't change anything, as there is already a
lot of "investment" in TLS...)




> > >   One problem with that---incentives.  What's my incentive to make all this
> > > information more easily machine readable?  On the web, you do that, and what
> > > happens?  Google comes along, munches on all that sweet machine readable
> > > data and serves it up directly to users, meaning the user just has to go to
> > > Google for the information, not your server.  Given those incentives, I have
> > > no reason to make my data easily machine readable when it means less
> > > traffic.
> >
> > The incentive is a clear one:  for the end-user.  Given that we can
> > standardize on such an "index", then we can create better
> > "user-agents" that are more useful to our actual users.  (And I'm not
> > even touching on the persons that have various disabilities that
> > hamper their interaction with computers.)
>
>   Okay, how does that incentivise me?


I don't know what incentives one to publish content;  some just want
to push their ideas on the internet, others might want to help others
through tutorials or documentation, others hope that by sharing they
advertise themselves, and so on...

However all of the above reasons (perhaps except the first one) do
need to care about their users.




>   It's easy enough to add machine readable annotations to HTML.  Heck, there
> are plenty of semantic tags in HTML to help with machine readability.  Yet
> why don't more people hand-code HTML?  Why is Markdown, which, I will add,
> has no defined way of adding metadata except by including HTML, so popular?


I don't know where the HTML micro-formats popped out in this
discussion, as I advocated against this approach.  :)




> > I'm not advocating for RDF (it was quite convoluted) or semantic web,
> > or GraphQL, etc.  I'm just advocating something better than the Gopher
> > map.
>
>   Okay, create a format and post it.  That's the best way to get this
> started.


OK, I'll try to take a stab at that.  (Although like in the case of
TLS, I think there is already too much "investment" in the current way
things are done.)




> > >   Hey, go ahead and implement that.  I'd like to see that ...
> >
> > There is already FreeNet and IPFS that implement content-based
> > addressing.  I just wanted something in between that is still
> > "location" driven, but is "content identity" aware.
>
>   Again, what's stopping you from just doing it?  Waiting for consensus?


Yes, a little bit of consensus won't hurt anybody...  Else we end-up
with TLS transient client certificates that act like cookies and which
require about 2 or 3 separate status codes to signal their
management...  :)

Ciprian.

From sean at conman.org  Sat Feb 29 09:50:29 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 29 Feb 2020 04:50:29 -0500
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fy2d0i_d4xrTac+BhR+PAnmH87Zn-JyiNgL5+beV21CkQ@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
 <20200228234201.GE16159@brevard.conman.org>
 <CA+Tk8fy2d0i_d4xrTac+BhR+PAnmH87Zn-JyiNgL5+beV21CkQ@mail.gmail.com>
Message-ID: <20200229095029.GG16159@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Sat, Feb 29, 2020 at 1:42 AM Sean Conner <sean at conman.org> wrote:
> >   True, but there's the 800-pound gorilla to consider---Windows.  On
> > Windows, a call like:
> > [...]
> >
> >   So there's a lot of protocols defined for the Internet that use CRLF.
> > Could a switch be made to just LF?  Sure.  It's also about as likely as the
> > Internet byte order being switched from big-endian to little-endian.
> 
> 
> OK, I'll drop the CRLF thing, but I find it odd that the only argument
> to this is "because systems and protocols designed many years ago did
> this (i.e. CRLF)", and to that you add "but anyway, all these systems
> just ignore all that and behave internally like it wasn't so (i.e.
> convert CRLF into LF)"...

  I have support to check for both CRLF and LF because I do quite a bit of
work with existing Internet protocols (which define the use of CRLF) and do
extensive testing with Unix (which defines only using LF) and it makes my
life easier to support both [1].  Besides, I think you are underestimating
the extent of Windows development out there, and I think (I can't prove)
that it's easier for a programmer under Unix to add the '\r' than it would
be for a Windows programmer to force Windows *not* to add the '\r'.

> >   The linked page just talks about an API for signing and ecrypting data.
> > It says nothing about negotiating the cipher, key size, or anything remotely
> > like a protocol.
> 
> (I have a hunch that you are not "acquainted" with NaCL / `libsodium`;

  No, I'm aware of both NaCL (which as I stated before, I have installed on
my home system) and libsodium (which I haven't installed, having NaCL
already installed).

>  the short story is this:  the designers of NaCL (again including
> Daniel J. Bernstein) wanted to design and implement a secure, simple
> to use, high level cryptographic library, that makes all the choices
> for its users, so that ciphers, key sizes, padding, nonces, etc.,
> aren't required to be handled by the user, and thus no mistakes would
> be made on this front.)

  Yes, and I just found the Lua module I wrote for NaCL (*not* libsodium)
back in 2013 when I was last playing around with it.  

> In fact that link does say at the end under the section `Algorithm
> details` what happens behind the scenes:
> 
> ~~~~
> Sealed boxes leverage the crypto_box construction (X25519, XSalsa20-Poly1305).
> 
> The format of a sealed box is:
> 
> ephemeral_pk || box(m, recipient_pk, ephemeral_sk,
> nonce=blake2b(ephemeral_pk || recipient_pk))
> ~~~~

  I was going by what I recalled of NaCL, written by the highly esteemed Dr.
Daniel J. Bernstein, of having to make *some* choices in what underlying
function to use for encryption and being a bit concerned that the entirety
of NaCL had to be included in the Lua module due to linking issues [4].

> > I would ask that if you feel this strongly about it, *do
> > it!*  Implement a client and server that uses these alternative crypto
> > systems and then we'll have something to talk about.
> 
> What is the chance you'll change your mind about TLS?  0.01%?  

  Right now?  Sounds about right.  If you provide some "proof-of-concept"
that can be looked at?  It goes up.  

> Are you
> actually considering to compare TLS vs another proposal without bias
> towards "legacy `gemini://` implementations currently using TLS"?

  What I'm considering is "Hey!  We should implement my great idea!  And by
'we' I mean, someone else!" vibe I get when arguments like this pop up [5].

> >   You can argue for an idea.  But an idea *and an implementation* is
> > stronger than just the idea.  I think that's why my Gemini server is so
> > featureful---I went ahead and implemented my ideas to help argue for/against
> > ideas, or even to just present *something* to talk about (when I have no
> > opinion one way or the other).
> 
> Perhaps I'll throw a proof-of-concept in Python or Go.  (Although as
> said above, I think it won't change anything, as there is already a
> lot of "investment" in TLS...)

  So let me show you how much investment it took me to use TLS for my Gemini
server:

	local tls = require "org.conman.nfl.tls"
	
	local function main(ios)  -- main routine to handle a request
	  local request = ios:read("*l")  -- mimics the Lua file IO API
	  -- rest of code
	end

	local okay,err = tls.listen(CONF.network.addr,CONF.network.port,main,function(conf)
	  conf:verify_client_optional()
	  conf:insecure_no_verify_cert()
	  return conf:cert_file(CONF.certificate.cert)
	     and conf:key_file (CONF.certificate.key)
	     and conf:protocols("all")
	end)

  That's it. [6]  Granted, I think I had an easier time of it than some
others because of the library I picked (libtls, which makes using TLS very
easy).  If the other non-TLS options are this easy then you might have a
case. As solderpunk said, there are many, many, libraries and modules
available for the most popular languages for TLS.  And "ease of
implementation" was one of the goals of Gemini.  If these alternatives to
TLS are just as easy to use, then a proof-of-concept should show that,
right?

  And for an indication of how easy it is for me to use TLS, a hypothetical
TCP-only version of Gemini would look very similar:

	local tcp = require "org.conman.nfl.tcp"

	local function main(ios)
	  local request = ios:read("*l")
	  -- rest of code
	end

	local okay,err = tcp.listen(CONF.network.addr,CONF.network.port,main)

  No other changes (except to remove the code to check for user
certificates) would be required.  That's how easy it should be.

> >   It's easy enough to add machine readable annotations to HTML.  Heck, there
> > are plenty of semantic tags in HTML to help with machine readability.  Yet
> > why don't more people hand-code HTML?  Why is Markdown, which, I will add,
> > has no defined way of adding metadata except by including HTML, so popular?
> 
> I don't know where the HTML micro-formats popped out in this
> discussion, as I advocated against this approach.  :)

  Machine readable formats, or at least, machine readable bits.

> > > I'm not advocating for RDF (it was quite convoluted) or semantic web,
> > > or GraphQL, etc.  I'm just advocating something better than the Gopher
> > > map.
> >
> >   Okay, create a format and post it.  That's the best way to get this
> > started.
> 
> OK, I'll try to take a stab at that.  (Although like in the case of
> TLS, I think there is already too much "investment" in the current way
> things are done.)

  Dude, have you *read* the thread about text formatting?  Literally half
the messages to this list have been about that, and we're *still* talking
about it.

> >   Again, what's stopping you from just doing it?  Waiting for consensus?
> 
> Yes, a little bit of consensus won't hurt anybody...  Else we end-up
> with TLS transient client certificates that act like cookies and which
> require about 2 or 3 separate status codes to signal their
> management...  :)

  Touch?.

  -spc

[1]	Okay, I have code that parses SIP messages [2].  As defined by many
	(many, many) RFCs, the transport over IP requires handling of CRLF. 
	But test the parser, it's easier to support just LF, since the
	testing I do is all under Unix [3].

	I also have code that deals with email messages, again, which are
	defined with CRLF, but on Unix, usually end with just LF.

[2]	At work.  At home, I don't have to deal with the horrors of SIP.

[3]	No Windows at all at home, or at work.

[4]	I can go over this in detail if you wish, but I'd rather not as it
	gets rather deep rather quickly.

[5]	It happens quite regularly on the Lua mailing list I'm on.  So much
	so that I outright ignore several people on that list.

[6]	Okay, it took a bit to write the Lua module around libtls (from
	LibreSSL), and some work to adapt it to my socket framework, but now
	that that is done, other people can leverage that work.

From ciprian.craciun at gmail.com  Sun Mar  1 01:31:47 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Sun, 1 Mar 2020 03:31:47 +0200
Subject: Regarding `gemini://` over NaCL (replacing TLS)
Message-ID: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>

So I've taken Sean Conner advice and implemented a proof-of-concept
client and server (only the protocol, transport and crypto part, not
the actual file serving) in Python by replacing TLS with NaCL /
`libsodium`.



The code is available on GitHub:

    https://github.com/cipriancraciun/gemini-experiments/blob/e4bbeae01a8e7d2e393ab93317890f5c7f511b09/nacl/sources

The sources are structured as such:

* `protocol_v1.py` builds upon `transport.py`, and actually implements
the `gemini://` protocol;  no surprises here, the `protocol_client`
function (that takes the server's address, an optional public key
(used for NaCL signatures), and a selector) interacts with the server
and returns the body;  similarly the `protocol_server` function takes
a listening socket and a handler function (that given a selector
returns the status, meta and body) and interacts with exactly one
client;

* `transport.py` builds upon `crypto.py` and `packets.py`;  more on this later;

* `crypto.py` wraps various NaCL functions and gives a better idea of
what happens;  again more on this later;

* `packets.py` basically just handles sockets and reading / writing
full payloads;  it also adds support for framed send / receive by
writing a 4 bytes length, followed by a payload of that many bytes (a
well known pattern);  this basically replaces TLS segments and removes
the need of line splitting, as now each individual protocol item
(selector, status and meta, body, and the key exchanges) uses one
single frame;

* the code is not "pythonic" (whatever that means), uses no global
state, and relies exclusively on functions that take all required
inputs as arguments;  (this way the functionality of one function can
be assessed only in terms of its inputs and outputs, thus I hope
simplifying the understanding;)  (one can think of it as almost purely
functional, with the exception of nonces and sockets which are both
mutated by successive calls to the various transport functions;)



Now regarding the transport / crypto and how it replaces TLS:

* as said, the transport module uses exclusively the framed (4 byte
length prefixed) packets, so from now on "send" and "receive" implies
such frames;

* the bulk of NaCL implementation happens inside `transport_prepare`
(https://github.com/cipriancraciun/gemini-experiments/blob/e4bbeae01a8e7d2e393ab93317890f5c7f511b09/nacl/sources/transport.py#L40-L94)
which does as follows;

* both the client and server use this function, thus from now on the
transport protocol is identical, thus symmetrical;

* by using `crypto_kx_keypair`
(https://libsodium.gitbook.io/doc/key_exchange) the local peer creates
an ephemeral session public / private key pair, which it exchanges
with its remote peer;  (this is the only piece of information that
doesn't travel encrypted, and thus available to an attacker;)

* the by using `crypto_kx_client_session_keys` (from the same link as
above) the local peer creates two symmetric secret keys, one for
sending and one for receiving;  (by now the remote peer has done the
same and obtained exactly the same symmetric secret keys;)

* also the local peer, using its own session public key (known to the
remote peer, and also known by an attacker) it creates (in a
deterministic manner, thus again known by an attacker) a nonce for
received packets;  using its remote peer session public key (again
known to an attacker) it creates a nonce for sent packets;  each time
one of these nonces are used (for sending and receiving), its
respective value is incremented by 1;  (according to the cryptographic
properties described at that page, having known nonces to the attacker
is OK, the only requirement is not to reuse them;)

* from here on, all exchanged messages are encrypted by using
`crypto_secretbox`
(https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox)
which provides both encryption and authentication against tampering;
(and coupled with the unique incremental nonces, it also assures that
the messages haven't been replayed, reordered, or dropped;)

* by using `crypto_sign_keypair`
(https://libsodium.gitbook.io/doc/public-key_cryptography/public-key_signatures)
the local peer creates a signature public / private key pair used for
authentication;  (both the client and server can use a stored public
key, or generated on the fly if `None` is used);

* by using `crypto_sign_detached` (the same link), the local peer
signs with its own signature private key the remote peer's session
public key;  the local peer then exchanges with the remote peer its
own signature public key and the computed signature;  (this proves
that the local peer has control over the signature secret key, and
also that this is not a replay attack as it signs something under the
control of the remote peer;)

* then, after receiving the remote peer's signature public key and the
detached signature it verifies it accordingly;

* at this moment the session is considered open, and the peers have
authenticated themselves to one-another;



A few notes about this encryption scheme:

* I am not a cryptographer or security expert, however I think I've
followed the best practices, especially those described in
(https://libsodium.gitbook.io/doc/secret-key_cryptography/encrypted-messages);
 (I bet an experimented cryptographer can take a look at this and say
if there are any issues, and how to fix those;)

* at the moment there is no padding, and give the way NaCL encrypts
data (i.e. the output has the same length as the input plus a fixed
constant), the length of the selector and header can be determined by
an attacker by looking at the network traffic;  adding a padding to
all packets multiple of say 128 bytes, and perhaps randomly adding one
to four such 128 bytes groups, would make these length unguessable
while impacting very little the network performance;

* at the moment two consecutive packets (like for example the
signature public key and signature verifier) are sent as different
`socket.send` calls, and thus perhaps as two different actual TCP
segments;  but a more efficient implementation can coalesce these into
a single `socket.send`;

* the overhead of the proposed protocol is minimal, both in terms of
payload size and latency due to round-trips (remember the protocol is
symmetric, thus this applies both to the client and server):
  * 32+4 bytes for the session public key exchange;
  * (both peers must read what was sent above before continuing, thus
one half-trip);
  * 32+16+4 bytes for the signature public key exchange;
  * 64+16+4 bytes for the signature verifier;
  * (both peers must read what was sent above before continuing, thus
another half-trip);
  * (so far a single complete round-trip was made;)
  * for each additional message an extra 16+4 bytes are sent;  (16
bytes for the `secretbox` authentication, and the 4 bytes for the
framing;)

* this schema is compliant with TCP FastOpen
(https://en.wikipedia.org/wiki/TCP_Fast_Open), i.e. the session public
key exchange can be done at the same time as the TCP
three-way-handshake happens;

* given the 4 bytes framing, the selector, headers and body can't be
larger than 4 GiB;  this is not a limitation, as we can implement for
the body an 8 bytes length prefixed framing;

* also given the 4 bytes framing, we solve the `Content-Length` issue,
and also the possibility of keep-alive;

* another advantage of the 4 bytes framing is that we can reuse the
frames instead of parsing for `CRLF`;

* at the moment TLS-SNI like functionality can be easily implemented
by asking the client to send with its signature public key also the
"virtual host" it wants to communicate with, thus based on that the
server can respond with that proper public key (this doesn't affect
the packet exchanges);  as opposed to TLS-SNI feature, this proposal
does not expose to an attacker the identity of the server public key
(i.e. the virtual host);  (granted there is a proposed extension to
TLS-SNI that encrypts that information;)

* the protocol should definitively require a version format (both for
the transport but also for the `gemini://` semantic) that should be
sent first by the client, and based on that the server should choose
the proper implementation if supported;  (however such a feature has
to be carefully implemented as not to be used by attackers to
downgrade a certain client into a vulnerable version;)



I hope I haven't made too many mistakes, and I hope this is useful as
a proof-of-concept that one could replace TLS for such simpler
protocols,
Ciprian.

From dave at ratfactor.com  Sun Mar  1 01:52:27 2020
From: dave at ratfactor.com (Dave Gauer)
Date: Sat, 29 Feb 2020 20:52:27 -0500
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
Message-ID: <808fac60-bffe-218b-4f30-5a25498a6acf@ratfactor.com>

On 2/29/20 8:31 PM, Ciprian Dorin Craciun wrote:
> So I've taken Sean Conner advice and implemented a proof-of-concept
> client and server (only the protocol, transport and crypto part, not
> the actual file serving) in Python by replacing TLS with NaCL /
> `libsodium`.
> 
> The code is available on GitHub:
> 
>      https://github.com/cipriancraciun/gemini-experiments/blob/e4bbeae01a8e7d2e393ab93317890f5c7f511b09/nacl/sources


Holy crap. You wrote this in the time it took me to draft a response to 
your *first* email. :-)

I just wanted to say: I like your ideas and applaud this tangible 
addition to the ecosystem.  I would personally love it something simpler 
than TLS could be used for Gemini.

I love the passion I've seen in the mailing list - it's gratifying to 
see others who care deeply about the same things I do.  My hat's off to 
all of the pioneers who have written clients, servers, and content for 
Gemini so far.

Okay, back to lurking.

(I swear I'll have something substantive to add in the future.)

-ratfactor

From Bradley at NorthTech.US  Sun Mar  1 08:22:22 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Sun, 1 Mar 2020 00:22:22 -0800
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
Message-ID: <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>



On 2/28/2020 2:04 AM, Ciprian Dorin Craciun wrote:
> On Fri, Feb 28, 2020 at 11:07 AM Sean Conner <sean at conman.org> wrote:
>>   Why is a numeric status code so bad?  Yes, the rest of the protocol is
>> English centric (MIME types; left-to-right, UTF-8).  It just seems that
>> using words (regardless of language) is just complexity for its own sake.
> 
> 
> Why did people use `/etc/hosts` files before DNS was invented?  Why do
> we have `/etc/services`?  Why do we have `O_READ`?  Why do we have
> `chmod +x`?
> 
> Because numbers are hard to remember, and say nothing to a person that
> doesn't know the spec by heart.  (For example although I do a lot of
> HTTP related work with regard to routing and such, I always don't
> remember which of the 4-5 HTTP redirect codes says "temporary redirect
> but keep the same method" as "opposed to temporary redirect but switch
> to `GET`".)
> 

Well, section 1.3.2 of the Gemini spec-spec says two digit codes, but
single (first digit) is all that is required. So, a 2, a 20, and a 21
are all success and there's no ambituity as to anything occuring at the
first digit level, it's just more gravy with the second digit.

I do fail to see why what appears to me to be a whole lot of work to
implement what you suggest, especially considering that most servers
will invariably choose to implement their own custom handlers for
status/error codes, much like one does in Apache so the server operator
themselves gets to choose what content to deliver as a result of a 404.

So there would be added framework for human readable, non-numeric status
codes (I would rather read the numerical codes in my logfiles), and then
as Gemini matures and stabilizes, devs will build frameworks so the
server operators can and will devlop custom pages for the status codes
anyway. This seems, at best, somewhat redundant to me (ultimately).

A 5 (or 50) might not provide as complete a picture as one would like,
yet it's optional to serve the full digit code and still unambiguous
with respect of what's going on at the baseline - a permanent falure.

A 51 though, perhaps the most common user facing state where errors are
encountered, will certainly eventually be accommodated by some clever
little remark intended to amuse the user who just asked for something
that isn't there. Reinforcing my suggestion that the server operators
are going to want the devs to enable them to deliver cute little
messages during such fashion faux pas'.

That's just kinda what I was pondering while reading the exchange.

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

From Bradley at NorthTech.US  Sun Mar  1 09:05:03 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Sun, 1 Mar 2020 01:05:03 -0800
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
 <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
Message-ID: <33ded471-2053-fbef-a55e-9910f05cf7c6@NorthTech.US>



On 3/1/2020 12:22 AM, Bradley D. Thornton wrote:
> 
> 

> 
> Well, section 1.3.2 of the Gemini spec-spec says two digit codes, but
> single (first digit) is all that is required. So, a 2, a 20, and a 21
> are all success and there's no ambituity as to anything occuring at the
> first digit level, it's just more gravy with the second digit.

Errata: There's no '2', the first character is followed by a zero on the
most basic implementations. My bad.

But we still don't have a Gemini status code analagous to that of the
HTTP 418 - and IMNSHO, we should :P

>

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

From ciprian.craciun at gmail.com  Sun Mar  1 09:10:31 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Sun, 1 Mar 2020 11:10:31 +0200
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
 <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
Message-ID: <CA+Tk8fyBiGagqmCOnsXCnQ_eGuo=WzoPxPdrHQRqnAZYbpKZ0g@mail.gmail.com>

On Sun, Mar 1, 2020 at 10:22 AM Bradley D. Thornton
<Bradley at northtech.us> wrote:
> On 2/28/2020 2:04 AM, Ciprian Dorin Craciun wrote:
> > On Fri, Feb 28, 2020 at 11:07 AM Sean Conner <sean at conman.org> wrote:
> >>   Why is a numeric status code so bad?  Yes, the rest of the protocol is
> >> English centric (MIME types; left-to-right, UTF-8).  It just seems that
> >> using words (regardless of language) is just complexity for its own sake.
> >
> > Because numbers are hard to remember, and say nothing to a person that
> > doesn't know the spec by heart.  (For example although I do a lot of
> > HTTP related work with regard to routing and such, I always don't
> > remember which of the 4-5 HTTP redirect codes says "temporary redirect
> > but keep the same method" as "opposed to temporary redirect but switch
> > to `GET`".)
>
> Well, section 1.3.2 of the Gemini spec-spec says two digit codes, but
> single (first digit) is all that is required. So, a 2, a 20, and a 21
> are all success and there's no ambituity as to anything occuring at the
> first digit level, it's just more gravy with the second digit.


Although I didn't state this before, having two digits, which in fact
are interpreted as a two level decision tree (the first digit denoting
generic class of conditions, and the second digit denoting more
fine-grained reasons), has at least the following problems:

* (given that `gemini://` wants to be simple) it's too much;  out of
the 410 non-empty lines of specification (v0.10.0), 77 are dedicated
to section `1.3.2 Status Codes` and another 93 to the `Appendix 1 --
Full two digit status codes`, i.e. ~40% of the specification is
dedicated to only these two digits...  granted these two sections also
contain additional information about how to interpret them and the
meta field, etc.;  but regardless having so many status codes does add
additional complexity to the protocol;

* either it's not enough, given that we've already used 50% of the
"generic class of conditions" (i.e. first digits 1 through 6);  soon
enough, as the protocol progresses and matures, we'll identify new
classes of conditions, and we'll have to start to either introduce a
"miscellaneous" category, or use values from other categories,
breaking thus the clear hierarchy;

* some conditions don't fall particularly well into clear categories;
for example `21 success with end of client certificate session` has to
do with TLS transient certificates management (which is `6x`);  in
fact this shouldn't even be a status code, but a "signal", because for
example a redirect or other failure could as well require the end of
client certificate session;

* another example of "unclear" status codes are `42 CGI error` and `43
proxy error`, which are part of the `4x temporary failure` group, but
might be in fact (especially in the case of 43, although granted we
have 53) permanent errors;  (even `51 not found` can be seen as a
temporary error, because perhaps the resource will exist tomorrow;)

* and speaking of proxies, we have `43 temporary proxy error` and `53
proxy request refused`, but we have no other proxy related statuses
like for example `6y` that states `proxy requires authentication`,
etc.;




So, if we really want to keep things simple why not change this into:

* (we only use one digit to denote success or failure);
* `0` (i.e. like in UNIX) means success, here is your document;
* `1` (i.e. again like in UNIX) means "undefined failure", the client
MUST display the meta field to the user as plain text;  (please note
that this "soft"-forbids the client and server to implement any clever
"extensions";)
* `2` not found / gone;  (i.e. the server is working fine, but what
you are searching for does not exist at the moment;  perhaps it
existed in the past, perhaps later it will exist;)
* `3` redirect;  neither temporary nor permanent; (because in fact
there isn't a clear definition and usage of temporary vs permanent;)
* `4` input;  (though as stated earlier I find this to be hack, and it
can be more elegantly solved with a redirect to a `gemini+query:...`
URL;)

* all automated crawlers, upon receiving an status code of `1` should
log the failure, and not retry the same URL for more than 4 times in a
24 hour window;
* all automated crawlers, should pause for at least 6 hours if:
  * they have received at least 100 consecutive errors;
  * over the last 200 requests, at least 100 of them where errors;


How would we automate authentication given we have no `authentication
required`?  We display the user the meta, the user interprets the
message and if he sees a message that prompts him to authenticate he
will do so through a menu, and the user-agent will perhaps remember
this decision.




> I do fail to see why what appears to me to be a whole lot of work to
> implement what you suggest,


Now getting back to my "symbolic" status codes proposal, it's no more
work, because currently the code looks like:

````
if (status[0] == '1') {
   ...
} else if (status[0] == '2') {
   ...
}
````

Meanwhile my proposal would require one to:
````
if (hasprefix (status, "success:")) {
   ...
} else if (hasprefix (status, "redirect:")) {
   ...
}
````

Granted now one has to implement, or find already implemented the
`hasprefix`, but all languages have it, and even in C one can
implement it as `strncmp (status, expected, strlen (expected)) == 0`.




> , especially considering that most servers
> will invariably choose to implement their own custom handlers for
> status/error codes, much like one does in Apache so the server operator
> themselves gets to choose what content to deliver as a result of a 404.


No this proliferation of "status codes" won't happen because the
protocol won't allow for it.  (Although even today with numeric status
codes people can just invent their own, unless we clearly define
conditions for all 100 codes, and even then people can disregard their
definitions...)


The only marginal advantage I see for numeric codes is in logs as you've stated.

Ciprian.

From solderpunk at SDF.ORG  Sun Mar  1 16:36:18 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 1 Mar 2020 16:36:18 +0000
Subject: [SPEC-CHANGE] Preformatted text, header and unordered list lines
 defined
Message-ID: <20200301163618.GA7582@SDF.ORG>

Attention Gemininauts!

I have officially updated the spec-spec just now.
        
SUMMARY OF CHANGES:

Section 1.3.5 (text/gemini response) has been edited and expanded in
several places, to define new line types.  The only non-optional change
defines lines beginning with ``` as toggling a "preformatted" mode,
within which all lines (including those which would constitute link
lines outside of preformatted mode) must be presented verbatim in a
fixed width font.

IMPLICATIONS FOR SERVER AUTHORS:
	 
None
	  
IMPLICATIONS FOR CLIENT AUTHORS:
	   
Clients now need to detect and correctly handle preformatted lines.

Clients MAY optionally recognise heading lines and unordered list item
lines.
	    
IMPLICATIONS FOR CONTENT AUTHORS:

Authors with ASCII art, source code or other content which may appear
incorrectly when displayed in a variable width font or with minor
whitespace normalisation should enclose said content within
preformatting toggle lines.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Mar  1 17:06:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 1 Mar 2020 17:06:59 +0000
Subject: Three month spec freeze
Message-ID: <20200301170659.GB7582@SDF.ORG>

Greetings all,

After today's change to the spec to introduce some new line types, I am
announcing a three month spec freeze.  I am happy to make small changes
to correct typos, fixing inconsistencies or reduce ambiguities (and I
have no doubt the latest change intorduced some of these things).  But I
will not make any substantive changes until June 1st 2020.  The reason
for this, as previously stated, is that I think in general we are doing
far too much "designing in a vacuum".

Designing protocols in the abstract on a mailing list is fun, but there
will *always* be reasonable arguments for adding just one more thing.
We'll never be finished and we'll move ever further away from the ethos
that people should be realistically able to write their own
feature-complete Gemini software in a weekend or two.  I am strongly of
the opinion that, now that we have defined something which is
(hopefully!) manageably small and simple, we should build the best
possible space we can within the limits that small and simple thing
imposes, and then ask ourselves "are we content with this?".  Not
"wouldn't it be nicer if we also had X?", because of course it would,
but "if this really were it, forever, would using this be genuinely
unpleasant?".

At this point I would really like to consider making changes if and
only if they fix actual real-world problems which we can point at that
are affecting multiple non-hypothetical servers or users.  Right now
there's just not enough stuff out there for this kind of "real world
driven design" to happen, and until that changes I think our time is
better used writing content than specs or code.

Moving forward, I strongly advocate for a model something like:

1. INTERVAL = 3 months
2. Spend INTERVAL actually building Geminispace and associated tools,
   with no major spec changes.
3. Ask "What is the *single* biggest problem/shortcoming of the current
   spec, based on everything that has actually been done or been tried
   in the past INTERVAL?"
4. Possibly (but not necessarily) change the spec to address the
   answer to 3, if the problem is deemed bad enough and can be
   addressed without adding too much extra complexity.
5. Set INTERVAL = 2*INTERVAL
6. GOTO 2, or END.

This way the protocol solidifies pretty rapidly, and all our attention
is focussed on demonstrable problems, which are tackled in order of
severity.  This model strongly encourages solving most problems not
through changes to the spec, which are precious rareties, but through
extra layers of optional convention, e.g. defining well-known endpoints
like robots.txt or sitemap.xml.  This, in turn, minimises breakage of
existing tooling.

So, let's spend most of our Gemini energy until June on creating
content and tools!  In addition to finally starting some gemlogs, I
still plan to prioritise the creation of an Atom-based aggregator to
play the role of Bongusta for Geminispace.  This, I hope, will encourage
content creation by making new content easily discoverable.  In
Gopherspace, Bongusta and, before Bongusta existed, the SDF phlog
listing played a strong role in easy content discovery.  Geminispace is
still stuck with manually checking every known server every day to find
infrequent updates, which is not something many people are going to want
to do (even I quickly stopped doing it!).  This discourages writing
content, due to the feeling that it will never be seen.  Fixing this is,
I think, important.

Cheers,
Solderpunk


From singletona082 at gmail.com  Sun Mar  1 17:20:20 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Sun, 1 Mar 2020 11:20:20 -0600
Subject: Three month spec freeze
In-Reply-To: <20200301170659.GB7582@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG>
Message-ID: <CAPBeim5REiEcDh16bhX2Ho6_O7Spy+QcGYWKyykpSiVW04+DiQ@mail.gmail.com>

This kind of sork is like writing a book. It is always tempting to go back
and revize and edit because yu are never happy eith it.

As someone that is lookingto use this on api zero acting as a
tinkerboxservet? I am lookingforward to the serverand client software that
can be written jn this time now that the spec is at least momentarily in
place.

On Sun, Mar 1, 2020, 11:07 AM solderpunk <solderpunk at sdf.org> wrote:

> Greetings all,
>
> After today's change to the spec to introduce some new line types, I am
> announcing a three month spec freeze.  I am happy to make small changes
> to correct typos, fixing inconsistencies or reduce ambiguities (and I
> have no doubt the latest change intorduced some of these things).  But I
> will not make any substantive changes until June 1st 2020.  The reason
> for this, as previously stated, is that I think in general we are doing
> far too much "designing in a vacuum".
>
> Designing protocols in the abstract on a mailing list is fun, but there
> will *always* be reasonable arguments for adding just one more thing.
> We'll never be finished and we'll move ever further away from the ethos
> that people should be realistically able to write their own
> feature-complete Gemini software in a weekend or two.  I am strongly of
> the opinion that, now that we have defined something which is
> (hopefully!) manageably small and simple, we should build the best
> possible space we can within the limits that small and simple thing
> imposes, and then ask ourselves "are we content with this?".  Not
> "wouldn't it be nicer if we also had X?", because of course it would,
> but "if this really were it, forever, would using this be genuinely
> unpleasant?".
>
> At this point I would really like to consider making changes if and
> only if they fix actual real-world problems which we can point at that
> are affecting multiple non-hypothetical servers or users.  Right now
> there's just not enough stuff out there for this kind of "real world
> driven design" to happen, and until that changes I think our time is
> better used writing content than specs or code.
>
> Moving forward, I strongly advocate for a model something like:
>
> 1. INTERVAL = 3 months
> 2. Spend INTERVAL actually building Geminispace and associated tools,
>    with no major spec changes.
> 3. Ask "What is the *single* biggest problem/shortcoming of the current
>    spec, based on everything that has actually been done or been tried
>    in the past INTERVAL?"
> 4. Possibly (but not necessarily) change the spec to address the
>    answer to 3, if the problem is deemed bad enough and can be
>    addressed without adding too much extra complexity.
> 5. Set INTERVAL = 2*INTERVAL
> 6. GOTO 2, or END.
>
> This way the protocol solidifies pretty rapidly, and all our attention
> is focussed on demonstrable problems, which are tackled in order of
> severity.  This model strongly encourages solving most problems not
> through changes to the spec, which are precious rareties, but through
> extra layers of optional convention, e.g. defining well-known endpoints
> like robots.txt or sitemap.xml.  This, in turn, minimises breakage of
> existing tooling.
>
> So, let's spend most of our Gemini energy until June on creating
> content and tools!  In addition to finally starting some gemlogs, I
> still plan to prioritise the creation of an Atom-based aggregator to
> play the role of Bongusta for Geminispace.  This, I hope, will encourage
> content creation by making new content easily discoverable.  In
> Gopherspace, Bongusta and, before Bongusta existed, the SDF phlog
> listing played a strong role in easy content discovery.  Geminispace is
> still stuck with manually checking every known server every day to find
> infrequent updates, which is not something many people are going to want
> to do (even I quickly stopped doing it!).  This discourages writing
> content, due to the feeling that it will never be seen.  Fixing this is,
> I think, important.
>
> Cheers,
> Solderpunk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200301/0272bfc9/attachment.htm>

From sean at conman.org  Mon Mar  2 00:18:42 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 1 Mar 2020 19:18:42 -0500
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
Message-ID: <20200302001842.GC5475@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> So I've taken Sean Conner advice and implemented a proof-of-concept
> client and server (only the protocol, transport and crypto part, not
> the actual file serving) in Python by replacing TLS with NaCL /
> `libsodium`.

  Wow.  For that I thank you.  Now there's something to actually look at. I
do have a few questions about the code as I'm looking over it.  Prepare for
lots of questions.  I had them for solderpunk as well.

1) I assume the 32-bit length is sent bigendian (if I understand the
argument to struct.pack() and struct.unpack() correctly---I'm not a Python
programmer).  Why big endian?  99% of all computers on the Internet today is
little endian (x86) so it seems to me that sending it little endian would be
better.  [1][2]

2) As I feared, this requires a more complicated implementation.  solderpunk
wanted a protocol that could be implemented quickly and while TLS might be a
bad protocol, it at least has the feature of being widely available and
largly transparent if done correctly (like libtls, part of LibreSSL, does). 
It handles not only the crypo portion, but the framing of data (invisibly to
the rest of the application).  To tell the truth, I don't know the actual
bytes of the TLS portion of the protcol as that is handled for me.

  In fact, that's part of why HTTPS was so successful---it doesn't change
the HTTP protocol at all.  It just slips in between TCP and HTTP and is
transparent to both.

  [ snip ]

> I hope I haven't made too many mistakes, and I hope this is useful as
> a proof-of-concept that one could replace TLS for such simpler
> protocols,

  I know that given the self-sign certificate nature of Gemini decreases
security a bit (TOFU and all that), not *all* Gemini servers are using
self-signed certificates.  There's at least two that I know of that use
actual signed certificates (from Let's Encrypt), and for my own server, I
use a signed certificate from my own CA (technically, the certificate isn't
self-signed, but the CA is self-certificed).  With a signed certificate, you
get *some* assurance that the server you are talking to is the server you
expect to be talking to, but it's still, technically, subject to a MITM
attack (either at the corporate level, or at the state level---it's way less
likely to come from some random hacker).

  What's still missing from your proof-of-concept though, is support for
client certificates.  Yes, you have the "transient" stuff working, but for
my Gemini server, I have a second that is unavailable unless you have a
signed certificate from me.  Send in a certificate request, I generate the
certificate and send that back, and you can access the sooperseecret portion
of my site [3] (no one has done that yet; then again, I haven't exactly
advertised that I would do that either).

  This way, I can control who has access to what on my Gemini server in a
mostly stateless way (I don't have to maintain a database of userids and
passwords, just pass out certificates which can be revoked if needed, and
will expire after a period of my choosing).  Yes, that complicated *my* end,
and may complicate a client that wants to support that, but it doesn't
complicate the *protocol* at all---TLS provides all the machinery for that.

  I'm still going over your code, but I'm not sure I can run it.  For one, I
don't know which version of Python (I know there are major differences
between 2 and 3 and I think I only have 2.something---I don't program in
Python) and I don't have libsodium install (but I do have NaCL).  But again,
I thank you for doing this work and giving us something tangible to look at
and run.

  -spc

[1]	Okay, I happen to agree with the big endian choice, but that's
	because I'm biased---binary based Internet protocols are all big
	endian, and I have a soft spot for the Motorola CPUs of past.  I've
	never been a fan of little endian personally.

[2]	I'm also asking to reflect back to you the same argument you
	presented with using CRLF.  Your big endian choice seems to be
	"because that's how all Internet protocols do it".

[3]	gemini://gemini.conman.org/conman-labs-private/

From sean at conman.org  Mon Mar  2 01:39:18 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 1 Mar 2020 20:39:18 -0500
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <CA+Tk8fyBiGagqmCOnsXCnQ_eGuo=WzoPxPdrHQRqnAZYbpKZ0g@mail.gmail.com>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
 <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
 <CA+Tk8fyBiGagqmCOnsXCnQ_eGuo=WzoPxPdrHQRqnAZYbpKZ0g@mail.gmail.com>
Message-ID: <20200302013918.GD5475@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> 
> * either it's not enough, given that we've already used 50% of the
> "generic class of conditions" (i.e. first digits 1 through 6);  soon
> enough, as the protocol progresses and matures, we'll identify new
> classes of conditions, and we'll have to start to either introduce a
> "miscellaneous" category, or use values from other categories,
> breaking thus the clear hierarchy;

  Before the mailing list, solderpunk and I went back and forth over the
status codes.  solderpunk was intent on using single digit codes, whereas I
was pushing for three digit codes.  As I wrote to him back in July of 2019:

>   With a two digit scehem, you have at most 100 error codes (00 through 99),
> with very clearly delineated classes that makes it easy for a client to act
> upon just the first digit.
> 
>   With your one character scheme (and yes, I'm calling it "one character"
> and not "one hexidecimal") the grouping is less clear, and it can *still* be
> extended out to a total of 94 codes (if you use other characters).  Also,
> what should happen when a client receives a code of 'a' through 'f'?  Is it
> only upper case allowed?  Or the lower case version as well?  Because in
> hexidecimal, 0xF and 0xf are the same value.
> 
>   What are you really afraid of?  Expansion?  Gopher gives you two
> results---the content or nothing.  A bit brutal, but simple.  You can cut
> this down to just four cases:
> 
>         success
>         transitory error
>         permanent error
>         need authorization
> 
> but that's still a bit brutal.  Just because you have 100, or 400, error
> codes doesn't mean they all will get used.  I'm sure the top three codes
> seen in the wild for HTTP are:
> 
>         200     Okay
>         304     Not modified
>         404     Not found
> 
> with the following codes just enough to show up:
> 
>         302     Move temp
>         301     Move perm
>         403     Not authorized
>         500     Internal error
> 
> and the rest are rounding errors.  I can't seem to find any evidence to back
> this up, but that's my gut feeling.  I think a single character response
> code is just too llmiting and yet, ripe for more abuse than with a two-digit
> numeric range.

  Also, the use of three digit status codes goes back a long time.  In fact,
it was first proposed in RFC-360, dated June 24, 1972! [1] And guess what? 
It was almost a one-to-one mapping of current HTTP status code.  2xx where
okay, 3xx were different, but I could see the mapping, 4xx were client
errors and 5xx were server errors.  There were also 1xx, but HTTP/1.1
defined 1xx status as well.

  And if anything, the fact that no new status classifications have come up
in 48 years says that your fears of new categories might not be warranted.

> * some conditions don't fall particularly well into clear categories;
> for example `21 success with end of client certificate session` has to
> do with TLS transient certificates management (which is `6x`);  

  Fair enough, but solderpunk would have to fix that one.

> in
> fact this shouldn't even be a status code, but a "signal", because for
> example a redirect or other failure could as well require the end of
> client certificate session;

  Again, fair enough.  I'm sure some of this is speculative anyway, since I
don't think any servers have actually implemented this feature (I know I
haven't).

> * another example of "unclear" status codes are `42 CGI error` and `43
> proxy error`, which are part of the `4x temporary failure` group, but
> might be in fact (especially in the case of 43, although granted we
> have 53) permanent errors;  (even `51 not found` can be seen as a
> temporary error, because perhaps the resource will exist tomorrow;)

  Yes, solderpunk changed from client errors/server errors to
temporary/permanent errors.  I didn't fight it that much since I can see the
logic in it.

> * and speaking of proxies, we have `43 temporary proxy error` and `53
> proxy request refused`, but we have no other proxy related statuses
> like for example `6y` that states `proxy requires authentication`,
> etc.;

  I can see the argument for a "AUTHORIZATION FOR PROXY" error, but by the
same token, what type of certificate? (and even there, I think having three
different types of certificates is certainly a bit of confusion).  This may
require some clarification from solderpunk in the mean time.

> So, if we really want to keep things simple why not change this into:
> 
> * (we only use one digit to denote success or failure);
> * `0` (i.e. like in UNIX) means success, here is your document;
> * `1` (i.e. again like in UNIX) means "undefined failure", the client
> MUST display the meta field to the user as plain text;  (please note
> that this "soft"-forbids the client and server to implement any clever
> "extensions";)

  I still like numeric values as they are language agnostic.  I mean, what
If I get back:

	Bh? teip ann an cl?r a chur i bhfeidhm

Would you even know what language to translate from?

  Yes, most likely this would be English, but I am ornery enough to follow
the letter of the law if not the spirit.

> * `2` not found / gone;  (i.e. the server is working fine, but what
> you are searching for does not exist at the moment;  perhaps it
> existed in the past, perhaps later it will exist;)

  There is a distinction between "gone" and "not found".  "Gone" means "it
was once here, but has since been removed, please stop referencing this
resource" (i.e. "remove it from your bookmarks file"), while "not found"
means just that---it's not here.

  I mentioned to solderpunk that I wish gopher had a "gone" message (along
with redirect, which I'll get to below), since there is a good reason to
mark something as "gone" and not just "not found".

> * `3` redirect;  neither temporary nor permanent; (because in fact
> there isn't a clear definition and usage of temporary vs permanent;)

  I think there is:

	* permanent---this resource has permanently moved, and any future
		reference should use the new location (i.e. update your
		index or bookmark file!)

	* temporary---this reference is still a valid reference, but the
		acutual content is, for whatever reason, located there.

  A valid reason for a temorary redirect might be to redirect users to the
most current resource available, say, a specification.  A base link like:

	gemini://gemini.example.com/foobar-spec

could in fact do a temporary redirect to

	gemini://gemini.example.com/foobar-spec.1.3.2

One can always link directly to a specific version, but the current will
*always* be found at a known location.

  The actions are the same, but the semantics are different.

> > I do fail to see why what appears to me to be a whole lot of work to
> > implement what you suggest,
> 
> Now getting back to my "symbolic" status codes proposal, it's no more
> work, because currently the code looks like:
> 
> ````
> if (status[0] == '1') {
>    ...
> } else if (status[0] == '2') {
>    ...
> }
> ````
> 
> Meanwhile my proposal would require one to:
> ````
> if (hasprefix (status, "success:")) {
>    ...
> } else if (hasprefix (status, "redirect:")) {
>    ...
> }
> ````
> 
> Granted now one has to implement, or find already implemented the
> `hasprefix`, but all languages have it, and even in C one can
> implement it as `strncmp (status, expected, strlen (expected)) == 0`.

  Nice, but you still need a function to check the second (and possibly)
third fields.  There's strtok() (a standard C function) but that can't be
used in multithreaded applications ... 

> > , especially considering that most servers
> > will invariably choose to implement their own custom handlers for
> > status/error codes, much like one does in Apache so the server operator
> > themselves gets to choose what content to deliver as a result of a 404.
> 
> No this proliferation of "status codes" won't happen because the
> protocol won't allow for it.  (Although even today with numeric status
> codes people can just invent their own, unless we clearly define
> conditions for all 100 codes, and even then people can disregard their
> definitions...)

  That can be done now.  I can program a web server to return a status of
700.  Now what clients will do in that case ... hmm ... okay, a quick test
revealed the following:

	Firefox		- treated a status code of 700 as a 200 and
			displayed the page

	Safari		- treated a status code of 700 as a 200 and 
			displayed the page

	Lynx		- warned of the nonstandard status code, and then
			proceeded to treat 700 as 200 and displayed the page.

  -spc

[1]	There is also RFC-354, an earlier RFC but one dated two weeks after
	RFC-360, that also uses three digit status codes similar to RFC-360.

From Bradley at NorthTech.US  Mon Mar  2 08:36:33 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Mon, 2 Mar 2020 00:36:33 -0800
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <20200302001842.GC5475@brevard.conman.org>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
Message-ID: <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>



On 3/1/2020 4:18 PM, Sean Conner wrote:
> It was thus said that the Great Ciprian Dorin Craciun once stated:
>> So I've taken Sean Conner advice and implemented a proof-of-concept
>> client and server (only the protocol, transport and crypto part, not
>> the actual file serving) in Python by replacing TLS with NaCL /
>> `libsodium`.
> 
>   Wow.  For that I thank you.  Now there's something to actually look at. I
> do have a few questions about the code as I'm looking over it.  Prepare for
> lots of questions.  I had them for solderpunk as well.
> 
> 1) I assume the 32-bit length is sent bigendian (if I understand the
> argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> programmer).  Why big endian?  99% of all computers on the Internet today is
> little endian (x86) so it seems to me that sending it little endian would be
> better.  [1][2]
> 
> 2) As I feared, this requires a more complicated implementation.  solderpunk
> wanted a protocol that could be implemented quickly and while TLS might be a
> bad protocol, it at least has the feature of being widely available and
> largly transparent if done correctly (like libtls, part of LibreSSL, does).


um.... <smile>, Sean I have to call attention here to the fact that such
an implementation of security isn't actually as simple as you portray in
that statement, lolz...

For example, just a couple of days ago you touted the libtls that you
[were able to] took advantage of, as a result of developing GLV-1.12556
being written in Lua ;)

In fact, you posted a tiny snippet of text showing how simple it was (in
that language), lending in part, to the simplicity of a Gemini server
being possible as a result of a weekend coding and beer session.

On the other hand, I recall quite clearly, Michaels encyclopedic
lamentations on the vagaries of attempting to acheive successful results
in Python, with regards to TLS and client/transient certs, due to the
horrendous state of Python libs in that regard :)

Just sayin', yes, it's trivial because you chose (whether by design or
inadvertantly) a framework upon which to support TLS, while in practice,
the implementation for others isn't necessarily so straight-forward ;)


>   In fact, that's part of why HTTPS was so successful---it doesn't change
> the HTTP protocol at all.  It just slips in between TCP and HTTP and is
> transparent to both.


Again, you chose something other than Python3 to do this with :)


>   I know that given the self-sign certificate nature of Gemini decreases
> security a bit (TOFU and all that), not *all* Gemini servers are using
> self-signed certificates.  There's at least two that I know of that use
> actual signed certificates (from Let's Encrypt), and for my own server, I


My servers are among those :)


>   What's still missing from your proof-of-concept though, is support for
> client certificates.  Yes, you have the "transient" stuff working, but for
> my Gemini server, I have a second that is unavailable unless you have a
> signed certificate from me.  Send in a certificate request, I generate the
> certificate and send that back, and you can access the sooperseecret portion
> of my site [3] (no one has done that yet; then again, I haven't exactly
> advertised that I would do that either).

That's really kewl, but it brings to mind the notion (at least to me),
that we may be painting ourselves into a corner by specifying a method
of encryption in canon that precludes the possibility for allowing other
methods, emerging or otherwise, that might *date* the Gemini protocol's
utility moving forward.

Question: Isn't it (even if non-trivial) possible, to account for other
methods of encryption by the listening daemon, some servers being able
to secure communications by one or another method if the upcoming
clients can also support those technologies?

I'm just thinking that security is a moving, and mostly reactive, rather
than proactive target, but allowing for the adoption, in a proactive
way, for the inclusion of developing encryption methods might be a good
thing to ensure that something like Gemini isn't relegated to the
boneyard when earlier methods two decades and more are eventually
deprecated (Like true SSL was).


>   I'm still going over your code, but I'm not sure I can run it.  For one, I

I have no idea whether Ciprian's proof of concept can translate into
viable solutions, but I'm confident that if anyone can competently
evaluate the pros and cons of what he's suggesting - it is you my friend :)


-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

From natpen at natpen.net  Mon Mar  2 12:07:38 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Mon, 2 Mar 2020 07:07:38 -0500
Subject: Gemini Universal Search
In-Reply-To: <d4845fca-d9bf-4f79-98ff-74d36b9948c3@NorthTech.US>
References: <20200225194356.GA16266@SDF.ORG>
 <d4845fca-d9bf-4f79-98ff-74d36b9948c3@NorthTech.US>
Message-ID: <20200302120738.GB335198@goldfish.localdomain>

On Wed, Feb 26, 2020 at 07:25:24PM -0800, Bradley D. Thornton wrote:
> Yes that is preferable from my perspective. It's a problem with
> VERONICA and VERONICA2 that only indexes the text in the selector
> strings. Although that is highly useful, it is  no substitute for
> indexing the actual content itself.

Wow, I had no idea that's how Veronica worked - no wonder I've had
trouble (re)finding some things with it in the past!

In addition to this thread, I've had a couple other conversations and
votes for content-based indexing over network-based indexing. So, I
think I'll keep it that way for now, and focus on improving the
tokenization/indexing quality.

I also just added search suggestions in the case of no results found,
which could be helpful in the case the searcher makes a query typo. It
also helps in the case of legitimately no results, which isn't too
far-fetched given the small amount of content we currently have :P

If anyone has other thoughts about desired features or undesired
anti-features please let me know. I want to make something useful, but
I also want to make sure the project is kind and respectful to Gemini
content creators :)

Natalie

From ciprian.craciun at gmail.com  Mon Mar  2 13:11:12 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Mon, 2 Mar 2020 15:11:12 +0200
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <20200302001842.GC5475@brevard.conman.org>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
Message-ID: <CA+Tk8fzOy=n_KCNSYtC==DOnXctTjXkS2VMmNLV7zJ_pZg33AA@mail.gmail.com>

On Mon, Mar 2, 2020 at 2:18 AM Sean Conner <sean at conman.org> wrote:
> 1) I assume the 32-bit length is sent bigendian (if I understand the
> argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> programmer).  Why big endian?  99% of all computers on the Internet today is
> little endian (x86) so it seems to me that sending it little endian would be
> better.  [1][2]
>
> [1]     Okay, I happen to agree with the big endian choice, but that's
>         because I'm biased---binary based Internet protocols are all big
>         endian, and I have a soft spot for the Motorola CPUs of past.  I've
>         never been a fan of little endian personally.
>
> [2]     I'm also asking to reflect back to you the same argument you
>         presented with using CRLF.  Your big endian choice seems to be
>         "because that's how all Internet protocols do it".


There are a couple of reasons I like big endian for protocols:

* (although not a strong argument, like in the case of CRLF, and as
you've observed in [2]) most other protocols are big endian, thus
there is a lot of tooling for this;  (for example Erlang even has
built-in functions for this;)

* it is logical;  for example although all integers are stored in
little endian on x86, when we write numbers in code we use "big
endian";

* (and most importantly) when dumping a protocol capture there are no
"surprises", I read the number left to right, and if I just take the
bytes in hex and concatenate them I can get the constant, i.e. `[01 02
03 04]` is just `0x01020304`;




> 2) As I feared, this requires a more complicated implementation.  solderpunk
> wanted a protocol that could be implemented quickly and while TLS might be a
> bad protocol, it at least has the feature of being widely available and
> largly transparent if done correctly (like libtls, part of LibreSSL, does).


The current proof-of-concept in Python I've presented is "feature
complete" in terms of what the current `gemini://` specification
requires;  except perhaps the certificate validation, but the specs
says it should be handled SSH-like.

My take on this is:  if we have a clear specification about what we
require from the transport layer, then we can come-up with a design
and implementation that provides it, nothing more.  At the moment the
`gemini://` specification requires nothing more than what I've
implemented.




> It handles not only the crypo portion, but the framing of data (invisibly to
> the rest of the application).  To tell the truth, I don't know the actual
> bytes of the TLS portion of the protcol as that is handled for me.


Here I want to argue that you are wrong on the following accounts:

* TLS natively implements a "message stream protocol" (as opposed to
"byte streams") which it calls TLS records;  (though these
unfortunately are limited to 16 KiB);

* unfortunately libraries (like OpenSSL) doesn't explicitly expose
this to the applications, although it warns the user in the man-page;
however if one calls `SSL_read` with a large enough buffer, at most
one record will be read at one time:

~~~~
https://www.openssl.org/docs/man1.0.2/man3/SSL_read.html

SSL_read() works based on the SSL/TLS records. The data are received
in records (with a maximum record size of 16kB for SSLv3/TLSv1). Only
when a record has been completely received, it can be processed
(decryption and check of integrity). Therefore data that was not
retrieved at the last call of SSL_read() can still be buffered inside
the SSL layer and will be retrieved on the next call to SSL_read(). If
num is higher than the number of bytes buffered, SSL_read() will
return with the bytes buffered. If no more bytes are in the buffer,
SSL_read() will trigger the processing of the next record. Only when
the record has been received and processed completely, SSL_read() will
return reporting success. At most the contents of the record will be
returned. As the size of an SSL/TLS record may exceed the maximum
packet size of the underlying transport (e.g. TCP), it may be
necessary to read several packets from the transport layer before the
record is complete and SSL_read() can succeed.
~~~~

Thus the TLS framing is not "invisible" to the application, it just
can be safely ignored.

Thus most applications will build yet-another-framing-mechanism on-top
of TLS.  (Just because `gemini://` and other protocols use lines ended
by `CRLF` doesn't mean these aren't "frames", i.e. one frame is a
sequence of one or multiple bytes followed by exactly one `CRLF` or
perhaps `LF` or perhaps `CR` or perhaps `LFCR`.)


That is why in my protocol proposal we don't need the `CRLF` framing
any more, because we rely on the transport layer to both apply the
framing and do the crypto.




>   In fact, that's part of why HTTPS was so successful---it doesn't change
> the HTTP protocol at all.  It just slips in between TCP and HTTP and is
> transparent to both.


OK, just because HTTPS was "so successful" doesn't mean we need to
copy it one-to-one.  In case of HTTPS the TLS layer "just slips in
between HTTP and TCP" because it was an afterthought, and everybody
wanted a quick solution, either in terms of TLS offloading / proxy and
other "hacks".

On the other side a lot of HTTPS security issues stemmed from this
ignorance of TLS, like for example cookie leaks due to TLS
compression, etc.

Thus my position is that a secure protocol can't be designed by
ignoring the actual layer providing the "security"...




>   [ snip ]
>
> > I hope I haven't made too many mistakes, and I hope this is useful as
> > a proof-of-concept that one could replace TLS for such simpler
> > protocols,
>
>   I know that given the self-sign certificate nature of Gemini decreases
> security a bit (TOFU and all that), not *all* Gemini servers are using
> self-signed certificates.  There's at least two that I know of that use
> actual signed certificates (from Let's Encrypt), and for my own server, I
> use a signed certificate from my own CA (technically, the certificate isn't
> self-signed, but the CA is self-certificed).  With a signed certificate, you
> get *some* assurance that the server you are talking to is the server you
> expect to be talking to, but it's still, technically, subject to a MITM
> attack (either at the corporate level, or at the state level---it's way less
> likely to come from some random hacker).


Strictly regarding TLS certificates, my "security" of and "trust" in a
site protected with a proper TLS certificate is proportional to the
amount of effort that is required to:
* break in into the server and steal the private key;
* (in case of non LetsEncrypt certificates) at some point in time in
the last year or two, one is able to social engineer someone at the
company to validate the issuance of a certificate;
* (in case of LetsEncrypt certificates) at some point in time in the
last three months, one was able to hijack or spoof either the DNS,
either the IP behind the domain I'm accessing, and thus validate the
issuance of a certificate;

Thus, personally I don't put a lot of weight in these certificates for
important stuff, instead I put faith in the various "extra checks" the
web and browsers community have implemented, from HTTPS certificate
pinning, to hard-coded certificates in browsers (for Google domains
for example), etc.


So in the end I think the `gemini://` design team should take a decision:
* do we use only self-signed certificates, authenticating them
SSH-like;  (and keep things simple;)
* do we we implement a web-of-trust, like PGP allows;  (as HTTPS has
done with various certificate related verifications outside the X.509
standard;)
* do we rely strictly on TLS certificates;

So if `gemini://` wants to be simple and secure, I would say a mix of
the first two.




>   What's still missing from your proof-of-concept though, is support for
> client certificates.  Yes, you have the "transient" stuff working, but for
> my Gemini server, I have a second that is unavailable unless you have a
> signed certificate from me.  Send in a certificate request, I generate the
> certificate and send that back, and you can access the sooperseecret portion
> of my site [3] (no one has done that yet; then again, I haven't exactly
> advertised that I would do that either).


On the contrary, the my current protocol does have support for
"permanent" client certificates, as they are just a special case of
"transient" ones;  just:
* create off-line a private / secret key;
* instead of sending a X.509 CSR (which in fact is nothing more than a
self-signed document proving that you have access to the secret key
bound to that public key, and perhaps additional information), send
the public key;
* on the server just whitelist that public key, like we do with
`~/.ssh/authorized_keys`;

Sure, now you'll say that with a proper TLS client certificate you
don't need to store it on your server, because you can just verify
that it has a proper signature from your own CA.  However how do you
revoke such a certificate?  You create a CRL which you store in a
file.

Thus in case of TLS you still need to maintain a "blacklist", while in
my simpler proposal you need to maintain a "whitelist".  :)




My take on the whole "certificates" would be this:  given that
`gemini://` wants to be simple, let's also keep the crypto stuff
simple;  i.e. no "certificates", just like in case of SSH public /
private keys.




> [...]  Yes, that complicated *my* end,
> and may complicate a client that wants to support that, but it doesn't
> complicate the *protocol* at all---TLS provides all the machinery for that.


Because `gemini://` mandates the usage of TLS, I think it's unfair to
treat TLS as "not part of the protocol";  you can ignore that it
exists, but that is counter-productive I think.




>   I'm still going over your code, but I'm not sure I can run it.  For one, I
> don't know which version of Python (I know there are major differences
> between 2 and 3 and I think I only have 2.something---I don't program in
> Python) and I don't have libsodium install (but I do have NaCL).  But again,
> I thank you for doing this work and giving us something tangible to look at
> and run.

You need Python 2.7 and I would suggest creating a virtualenv.  The
only dependency I used is `pysodium` which requires `libsodium`.  (All
the commands I run are written in the `z-run` file, which I think is
self-explanatory.)

Ciprian.

From ciprian.craciun at gmail.com  Mon Mar  2 13:23:26 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Mon, 2 Mar 2020 15:23:26 +0200
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
Message-ID: <CA+Tk8fzuzGztkcJMsJrFpYNsOg9mdehssp0=3Z3EGnSyaB=e6Q@mail.gmail.com>

On Mon, Mar 2, 2020 at 10:36 AM Bradley D. Thornton
<Bradley at northtech.us> wrote:
> Question: Isn't it (even if non-trivial) possible, to account for other
> methods of encryption by the listening daemon, some servers being able
> to secure communications by one or another method if the upcoming
> clients can also support those technologies?


This is exactly what happened with SSL (at least two versions) which
coexisted alongside with TLSv1.0, which then together coexisted
alongside with TLSv1.1, which then all together coexisted with
TLSv1.2, which now all coexist with TLSv1.3;  and although everybody
screams that anything under TLSv1.2 is "broken", we still haven't
dropped support for TLSv1.1...  :)

My take is having "options" is good for "complex" things, however for
simple things, like `gemini://` strives to be, having one "good-enough
but simple" solution is the best.


So if I were to vote I would say:
* let's add the notion of "`gemini://` protocol version" that the
client sends in the first packet (even before encryption), and the
server must match or error out;  (we need to make sure that after the
encryption is established, this "version" is re-confirmed, so that we
aren't vulnerable to protocol downgrade attacks;)
* let's push the community to keep compatibility with no more than 3
`gemini://` protocol versions;  (i.e. the current "stable", the
previous "stable", and the "long-term-support" one;)

Ciprian.

From ciprian.craciun at gmail.com  Mon Mar  2 13:40:06 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Mon, 2 Mar 2020 15:40:06 +0200
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <20200302013918.GD5475@brevard.conman.org>
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228024409.GA16159@brevard.conman.org>
 <CA+Tk8fxCyQ2ZVaX=fCXRhQxLdw=md6yiuWU9B47RWDqih4mVgw@mail.gmail.com>
 <20200228090709.GB16159@brevard.conman.org>
 <CA+Tk8fxyiGDETSM-Fc5jO9UJvS6CfP=nSvebawpAGwHfmHn0Ug@mail.gmail.com>
 <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
 <CA+Tk8fyBiGagqmCOnsXCnQ_eGuo=WzoPxPdrHQRqnAZYbpKZ0g@mail.gmail.com>
 <20200302013918.GD5475@brevard.conman.org>
Message-ID: <CA+Tk8fxHuA23r544vYr7ZmAbj+eCjQPbzWTMsehv7K2VZUj=7g@mail.gmail.com>

On Mon, Mar 2, 2020 at 3:39 AM Sean Conner <sean at conman.org> wrote:
> > So, if we really want to keep things simple why not change this into:
> >
> > * (we only use one digit to denote success or failure);
> > * `0` (i.e. like in UNIX) means success, here is your document;
> > * `1` (i.e. again like in UNIX) means "undefined failure", the client
> > MUST display the meta field to the user as plain text;  (please note
> > that this "soft"-forbids the client and server to implement any clever
> > "extensions";)
>
>   I still like numeric values as they are language agnostic.  I mean, what
> If I get back:
>
>         Bh? teip ann an cl?r a chur i bhfeidhm
>
> Would you even know what language to translate from?


If a client would receive such a status it would reply to the user:
"server error: invalid protocol".  Why?  Because I'm not advocating
for "any sequence of ASCII characters", but a predefined (thus limited
and known) list of tokens that are accepted.


More clearly, there are two separate issues:
* the syntax -- one digit, vs two digits, vs any number of digits, vs
ASCII tokens, etc. -- i.e. the serialization of an error condition;
* the semantic -- be it `2`, `200`, `success` -- i.e. how many
different "response" classes do we want to specify;




> > * `2` not found / gone;  (i.e. the server is working fine, but what
> > you are searching for does not exist at the moment;  perhaps it
> > existed in the past, perhaps later it will exist;)
>
>   There is a distinction between "gone" and "not found".  "Gone" means "it
> was once here, but has since been removed, please stop referencing this
> resource" (i.e. "remove it from your bookmarks file"), while "not found"
> means just that---it's not here.
>
>   I mentioned to solderpunk that I wish gopher had a "gone" message (along
> with redirect, which I'll get to below), since there is a good reason to
> mark something as "gone" and not just "not found".


I understand the "philosophical" distinction between "gone" and "not
found";  but how often have you encountered a web server that properly
responds with "gone"?  Or, given that many `gemini://` servers will be
static servers using the file-system, how would one "know" if a
selector refers to a "gone" file?




> > * `3` redirect;  neither temporary nor permanent; (because in fact
> > there isn't a clear definition and usage of temporary vs permanent;)
>
>   A valid reason for a temorary redirect might be to redirect users to the
> most current resource available, say, a specification.  A base link like:
>
> [...]
>
> One can always link directly to a specific version, but the current will
> *always* be found at a known location.
>
>   The actions are the same, but the semantics are different.


I think that if one would apply a case-by-case analysis, one could
find better solutions.

For example in your documentation case, how about instead of
redirecting we present an `text/gemini` resource that provides a short
summary, a link to the current version, and a list of links to
previous versions.

I would say it makes more sense because:
* the user isn't surprised anymore by the redirect, and is aware that
there are multiple versions;
* in order for older versions to be indexed by a crawler, we always
need such a "links page", thus why not make proper use of it;

Ciprian.

From sean at conman.org  Mon Mar  2 22:00:47 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 2 Mar 2020 17:00:47 -0500
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
Message-ID: <20200302220047.GH5475@brevard.conman.org>

It was thus said that the Great Bradley D. Thornton once stated:
> On 3/1/2020 4:18 PM, Sean Conner wrote:
> > 
> > 2) As I feared, this requires a more complicated implementation.  solderpunk
> > wanted a protocol that could be implemented quickly and while TLS might be a
> > bad protocol, it at least has the feature of being widely available and
> > largly transparent if done correctly (like libtls, part of LibreSSL, does).
> 
> um.... <smile>, Sean I have to call attention here to the fact that such
> an implementation of security isn't actually as simple as you portray in
> that statement, lolz...
> 
> For example, just a couple of days ago you touted the libtls that you
> [were able to] took advantage of, as a result of developing GLV-1.12556
> being written in Lua ;)
> 
> In fact, you posted a tiny snippet of text showing how simple it was (in
> that language), lending in part, to the simplicity of a Gemini server
> being possible as a result of a weekend coding and beer session.
> 
> On the other hand, I recall quite clearly, Michaels encyclopedic
> lamentations on the vagaries of attempting to acheive successful results
> in Python, with regards to TLS and client/transient certs, due to the
> horrendous state of Python libs in that regard :)

  Do you have any links to this?  I don't remember seeing any of that, and
I'd be interested in reading it.

> Just sayin', yes, it's trivial because you chose (whether by design or
> inadvertantly) a framework upon which to support TLS, while in practice,
> the implementation for others isn't necessarily so straight-forward ;)

  By design.  I knew libtls, written by the OpenBSD people, was designed to
make using TLS simple to use, and hard to use incorrectly.  Since my prerred
language is Lua, it was a simple matter to wrap up libtls for use in Lua
and a moderate amount of work to get it working within a network event
driver.  I happen to agree with the OpenBSD guys that *using* crypto is too
hard.

  I'm just sad that libtls doesn't seem to get much use.  But it could be
that I haven't looked hard enough.  I don't know.
  
> Question: Isn't it (even if non-trivial) possible, to account for other
> methods of encryption by the listening daemon, some servers being able
> to secure communications by one or another method if the upcoming
> clients can also support those technologies?

  In general?  Yes.  In practice, with current implementations of TLS?  I
don't know, I haven't looked into it.

  But to remind you, I'm not the one who developed the Gemini protocol.

  -spc

From sean at conman.org  Mon Mar  2 22:10:34 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 2 Mar 2020 17:10:34 -0500
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fzuzGztkcJMsJrFpYNsOg9mdehssp0=3Z3EGnSyaB=e6Q@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
 <CA+Tk8fzuzGztkcJMsJrFpYNsOg9mdehssp0=3Z3EGnSyaB=e6Q@mail.gmail.com>
Message-ID: <20200302221034.GI5475@brevard.conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Mon, Mar 2, 2020 at 10:36 AM Bradley D. Thornton
> <Bradley at northtech.us> wrote:
> > Question: Isn't it (even if non-trivial) possible, to account for other
> > methods of encryption by the listening daemon, some servers being able
> > to secure communications by one or another method if the upcoming
> > clients can also support those technologies?
> 
> 
> This is exactly what happened with SSL (at least two versions) which
> coexisted alongside with TLSv1.0, which then together coexisted
> alongside with TLSv1.1, which then all together coexisted with
> TLSv1.2, which now all coexist with TLSv1.3;  and although everybody
> screams that anything under TLSv1.2 is "broken", we still haven't
> dropped support for TLSv1.1...  :)

  Because dropping support would make too many people scream.  As I told a
VP of the company I work for, "it doesn't make sense for our department to
have two week sprints when our customer [the Monopolistic Phone Company] has
two year sprints!" It took five years just to get a flag we needed added to
a message. [1]

  -spc

[1]	We were able to work around it, but it wasn't pretty.

From sean at conman.org  Mon Mar  2 22:30:51 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 2 Mar 2020 17:30:51 -0500
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fzOy=n_KCNSYtC==DOnXctTjXkS2VMmNLV7zJ_pZg33AA@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
 <CA+Tk8fzOy=n_KCNSYtC==DOnXctTjXkS2VMmNLV7zJ_pZg33AA@mail.gmail.com>
Message-ID: <20200302223051.GJ5475@brevard.conman.org>


  I think I'm going to bow out of the encryption talk.  It's clear to me
that I feel TLS is good enougn, and Ciprian doesn't (or would rather have
alternatives).  I'm not the creator of the Gemini protocol, so I don't have
the authority to make drastic changes to the protocol.

  I've heard the admonintion to not roll your own crypto, and I believe that
it extends to protocols as well.  And as bad and complex as TLS might be,
it's a standard, there are real cryptographers trying to break it, and there
are multiple implementations of it available: OpenSSL and LibreSSL are two,
but off the top of my head, there are also bearSSL, PolarSSL, boringSSL. and
GNUTLS.  And in a sense, that makes it easier to use, since these
implementations *exit*.  This new protocol Ciprian is designing hasn't been
vetted, and I'm unaware of anyone on this list that is expert enough in
crypto to fully examine it.

  And Ciprian wants to design a new secure protocol ... 

  Anyway, a few comments about this message.

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Mon, Mar 2, 2020 at 2:18 AM Sean Conner <sean at conman.org> wrote:
> > 1) I assume the 32-bit length is sent bigendian (if I understand the
> > argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> > programmer).  Why big endian?  99% of all computers on the Internet today is
> > little endian (x86) so it seems to me that sending it little endian would be
> > better.  [1][2]
> >
> > [1]     Okay, I happen to agree with the big endian choice, but that's
> >         because I'm biased---binary based Internet protocols are all big
> >         endian, and I have a soft spot for the Motorola CPUs of past.  I've
> >         never been a fan of little endian personally.
> >
> > [2]     I'm also asking to reflect back to you the same argument you
> >         presented with using CRLF.  Your big endian choice seems to be
> >         "because that's how all Internet protocols do it".
> 
> There are a couple of reasons I like big endian for protocols:
> 
> * it is logical;  for example although all integers are stored in
> little endian on x86, when we write numbers in code we use "big
> endian";

  We use the Arabic numerals these days.  It's interesting to note that the
value three hundred and twenty-one is written in the order of 321 in Arabic
(much like in Western countries) but Arabic itself is written right-to-left,
so one could say they write their numbers in little endian format.  You're
just expressing a western bias---logic has nothing to do with it 8-P

> * (and most importantly) when dumping a protocol capture there are no
> "surprises", I read the number left to right, and if I just take the
> bytes in hex and concatenate them I can get the constant, i.e. `[01 02
> 03 04]` is just `0x01020304`;

  And it'd be backwards for Arabic programmers.

  -spc

From lazar.michael22 at gmail.com  Tue Mar  3 03:00:37 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Mon, 2 Mar 2020 22:00:37 -0500
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <20200302220047.GH5475@brevard.conman.org>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
 <20200302220047.GH5475@brevard.conman.org>
Message-ID: <CAFTy05YzQQSNQ5-S2BCYEkDPD27oNDFPNcKe-GU3zd_Ae+Uyaw@mail.gmail.com>

> It was thus said that the Great Bradley D. Thornton once stated:
> > On 3/1/2020 4:18 PM, Sean Conner wrote:
> > >
> > > 2) As I feared, this requires a more complicated implementation.  solderpunk
> > > wanted a protocol that could be implemented quickly and while TLS might be a
> > > bad protocol, it at least has the feature of being widely available and
> > > largly transparent if done correctly (like libtls, part of LibreSSL, does).
> >
> > um.... <smile>, Sean I have to call attention here to the fact that such
> > an implementation of security isn't actually as simple as you portray in
> > that statement, lolz...
> >
> > For example, just a couple of days ago you touted the libtls that you
> > [were able to] took advantage of, as a result of developing GLV-1.12556
> > being written in Lua ;)
> >
> > In fact, you posted a tiny snippet of text showing how simple it was (in
> > that language), lending in part, to the simplicity of a Gemini server
> > being possible as a result of a weekend coding and beer session.
> >
> > On the other hand, I recall quite clearly, Michaels encyclopedic
> > lamentations on the vagaries of attempting to acheive successful results
> > in Python, with regards to TLS and client/transient certs, due to the
> > horrendous state of Python libs in that regard :)
>
>   Do you have any links to this?  I don't remember seeing any of that, and
> I'd be interested in reading it.

I believe this is referencing this post that I made a while ago [1].

Personally, I would rather have gemini:// not be encrypted at all. I know
there is a subset of privacy conscious users who are super dogmatic about
security and E2E encryption. This much is clear from watching the gopher
community. But I am not one of those users, and that is not what excites me
about the gemini protocol.

[1] gemini://mozz.us/journal/2019-08-21_transient_tls_certs.gmi

- mozz

From sean at conman.org  Tue Mar  3 04:55:57 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 2 Mar 2020 23:55:57 -0500
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CAFTy05YzQQSNQ5-S2BCYEkDPD27oNDFPNcKe-GU3zd_Ae+Uyaw@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
 <20200302220047.GH5475@brevard.conman.org>
 <CAFTy05YzQQSNQ5-S2BCYEkDPD27oNDFPNcKe-GU3zd_Ae+Uyaw@mail.gmail.com>
Message-ID: <20200303045557.GK5475@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> > It was thus said that the Great Bradley D. Thornton once stated:
> > > >
> > > On the other hand, I recall quite clearly, Michaels encyclopedic
> > > lamentations on the vagaries of attempting to acheive successful results
> > > in Python, with regards to TLS and client/transient certs, due to the
> > > horrendous state of Python libs in that regard :)
> >
> >   Do you have any links to this?  I don't remember seeing any of that, and
> > I'd be interested in reading it.
> 
> I believe this is referencing this post that I made a while ago [1].

  Ah, thanks.

  I'm beginning to think it's a shame that libtls isn't used more often.  I
know of only one other TLS implementation that has implemented libtls, and
that's bearTLS (which hasn't implemented everything in libtls as of yet).
It really does make using encryption with TLS easier.

> Personally, I would rather have gemini:// not be encrypted at all. I know
> there is a subset of privacy conscious users who are super dogmatic about
> security and E2E encryption. This much is clear from watching the gopher
> community. But I am not one of those users, and that is not what excites me
> about the gemini protocol.

  I hear you.  I'm not overly fond of the whole "encrypt all the things"
movement myself.    But hey, the only constant is change.

> [1] gemini://mozz.us/journal/2019-08-21_transient_tls_certs.gmi

  -spc


From ciprian.craciun at gmail.com  Tue Mar  3 12:20:57 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Tue, 3 Mar 2020 14:20:57 +0200
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
Message-ID: <CA+Tk8fwP9Qozkgk-KH25aea11KudN+f_njBdQWWTcmpfF2Qi+Q@mail.gmail.com>

OK, I've been doing some "light reading" about this topic, and this is
what I've found out so far.

(Although I think the change of adopting anything besides TLS is
closer to 0 at this moment, which I would say is a shame...)




#### About "pro-TLS", and "don't roll your own"

[I.e.  This part is a counter argument to my previous emails.  I still
think we can do "simpler", but I do like to be fair, and thus I'm
debating myself...]  :)


Bellow I'll point out three articles, written by three different
people (which after searching the internet seem to be knowledgeable in
this domain, perhaps not Schneier / Bernstein level, but still much
better than the average developer), in a time span of about 10 years.
(The section we are interested in is `client-server application
security`, and not `website security` because the later actually means
"HTTPS security", thus TLS is mandatory, although the former
completely ignores certificates, as in X.509, thus only SSH-like
assumptions.)

* [2018]  https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
* [2015]  https://gist.github.com/tqbf/be58d2d39690c3b366ad
* [2009]  http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html


>From [2009] (although I would say it's an incomplete advice as it
doesn't say what to do next):
~~~~
One of the reasons OpenSSL has such a poor track record is that the
SSL protocol itself is highly complex. Certificate chains, revocation
lists, ASN.1, multiple different hashing and encryption schemes...
when you have over a hundred thousand lines of code, it's no wonder
that bugs creep in.
~~~~


>From [2015] (Colin is the author of the [2009] article):
~~~~
What happens when you design your own custom RSA protocol is that 1-18
months afterward, hopefully sooner but often later, you discover that
you made a mistake and your protocol had virtually no security. That
happened to Colin, but a better example is Salt Stack. Salt managed to
deploy e=1 RSA.

[...]

Most of these attacks can be mitigated by hardcoding TLS 1.2+, ECDHE
and AES-GCM. That sounds tricky, and it is, but it's less tricky than
designing your own transport protocol with ECDHE and AES-GCM!

In a custom transport scenario, you don't need to depend on CAs: you
can self-sign a certificate and ship it with your code, just like
Colin suggests you do with RSA keys.

Avoid: designing your own encrypted transport, which is a genuinely
hard engineering problem; using TLS but in a default configuration,
like, with "curl"; using "curl", IPSEC.
~~~~


>From [2018]:
~~~~
In custom protocols, you don?t have to (and shouldn?t) depend on 3rd
party CAs. You don?t even have to use CAs at all (though it?s not hard
to set up your own); you can just use a whitelist of self-signed
certificates ? which is approximately what SSH does by default, and
what you?d come up with on your own.

Since you?re doing a custom protocol, you can use the best possible
TLS cipher suites: TLS 1.2+, Curve25519, and ChaPoly. That eliminates
most attacks on TLS. The reason everyone doesn?t do this is that they
need backwards-compatibility, but in custom protocols you don?t need
that.

[...]

Avoid: designing your own encrypted transport, which is a genuinely
hard engineering problem; using TLS but in a default configuration,
like, with ?curl?; using ?curl?, IPSEC.
~~~~


The takeaway:  if we go with TLS, let's mandate:
* TLS 1.2 with TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
* or, TLS 1.3 with TLS_CHACHA20_POLY1305_SHA256
  https://ciphersuite.info/cs/TLS_CHACHA20_POLY1305_SHA256
* as for certificates only ECDSA, which seem to be available also via
Lets Encrypt;

These options are also suggested by both Mozilla and CloudFlare:
* https://wiki.mozilla.org/Security/Server_Side_TLS
* https://developers.cloudflare.com/ssl/ssl-tls/cipher-suites




#### About the noise protocol

I've glossed over the Noise protocol specification, however before
getting into that I've read the first link bellow:

* https://latacora.micro.blog/factoring-the-noise/
* https://noiseprotocol.org/noise.html  (this is the actual specification);

Basically I think the only Noise protocol instance that pertains to
`gemini://` is the `XX` exchange pattern, citing from the first link
above:
~~~~
XX and XK require an extra round trip before they send over the
initiator?s static key. Flip side: they have the strongest possible
privacy protection for the initiator, whose identity is only sent to
the responder after they?ve been authenticated and forward secrecy has
been established.
~~~~

In fact Alexey Ermishkin together with Trevor Perrin (the original
author of the protocol) have started a project called NoiseSocket,
which basically just focuses on the the `XX` pattern.  (As for
credentials, Trevor Perrin worked for WhatsApp in designing the Noise
protocol, which is still used today.)

* https://github.com/noisesocket/spec
* https://noisesocket.org/post/1/ -- I strongly suggest reading this
document if one is interested in the Noise protocol;

The only disadvantage with Noise (or NoiseSocket) is that given the
frame size is limited to 64K, in case of `gemini://` we need to
implement extra "chunking" for it to work for bodies.  (Alternatively
we can just use it as we do TLS, namely a "stupid pipe that just
applies encryption"...)




####  The part about other alternatives

I've found the following project that also does a "state-of-the-art"
analysis (though granted in 2015):

* https://github.com/auditdrivencrypto/secure-channel
* https://github.com/auditdrivencrypto/secure-channel/blob/master/prior-art.md
* https://github.com/auditdrivencrypto/secure-channel/blob/master/properties.md
* https://github.com/auditdrivencrypto/secure-channel/blob/master/draft.md
* https://github.com/auditdrivencrypto/secure-channel/blob/master/draft2.md

(I don't know his credentials, thus I would assume nothing.)

The "state-of-the-art" is quite "high-level", but it provides a nice
starting point.  The properties document is a good check-list to
analyze any proposal against.  (The only issue, is that he is
interested in building a peer-to-peer network, thus at least the
public key of the server is known in advance.)

The second draft (i.e. `draft2.md` above) is quite interesting,
although as said it does one require to know beforehand the server's
public key.




####  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 `transport_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).

Ciprian.

From solderpunk at SDF.ORG  Tue Mar  3 19:16:20 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 3 Mar 2020 19:16:20 +0000
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fwP9Qozkgk-KH25aea11KudN+f_njBdQWWTcmpfF2Qi+Q@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <CA+Tk8fwP9Qozkgk-KH25aea11KudN+f_njBdQWWTcmpfF2Qi+Q@mail.gmail.com>
Message-ID: <20200303191620.GB29986@SDF.ORG>

On Tue, Mar 03, 2020 at 02:20:57PM +0200, Ciprian Dorin Craciun wrote:
 
> (Although I think the change of adopting anything besides TLS is
> closer to 0 at this moment, which I would say is a shame...)

You are pretty well right about this (and I won't even argue too
strongly the fact that it's kind of a shame).

I really hate to do anything like shutting this line of discussion down,
especially after you have already invested so much effort into
implementing a proof of concept.  But the truth is that I think it's too
late in the game for this kind of change.

Replacing TLS with *anything* else would completely break every existing
piece of Gemini software, which is a non-trivial amount, written by many
different people of varying degrees of continuing activity in the
project.  There is a very real chance that this kind of change would
introduce a permanent schism between "New Gemini" and "Old Gemini" when
a subset of servers (in both senses of the word) and clients were not
updated.  Not only would software break, but I imagine a lot of
participants in the projet would be unhappy as well.  I worry that the
community is too small and fraile to survive what would effectively be a
fork.

It's possible some kind of compatibility-maintaining change could be
negotiated with the use of protocol verison numbers, but I have always,
and still have been, opposed to the idea of versioning Gemini, because I
see this as basically negating all the effort that was put into avoiding
extensibility.  My intent has always been to get it right (or close
enough) the first time, in a relatively short period, and then leave it
fixed - more or less as per Gopher.  I realise that's a tall order.  The
idea was that Gemini would be so simple that this would be possible.
Unforseen problems requiring later changes are a symptom of
overcomplication, which interferes with anticipating problems.

I understand that there's a lot *not* to like about TLS.  And while I
absolutely understand the importance of the "don't roll your own crypto"
dogma, I do also understand that it *is* a dogma, which has a stagnating
effect, especially when overextended - there is a real difference
between combining established and well-tested primitives into a new
protocol and a totally naive person who doesn't know block ciphers from
stream ciphers coming up with something truly from scratch and assuming
it's good because none of the three friends they asked could break it.

But all that said, even if this were the very early days of Gemini
again and we could be a bit more agile in core aspects of the
protocol's design, I'm not convinced I wouldn't still choose TLS.  The
most important argument in its favour, IMHO, is the simple fact that
TLS is going to be used, studied, and improved/maintained by some of
the best security people in the world for a long time to come, for
reasons *entirely* unrelated to Gemini.  By going with TLS, we
basically get to piggy-back on all of this, for free.  The moment we
change to anything else, there is immediately a 90% reduction in the
amount of attention being paid by anybody to our security system.
That's very hard to argue against, I would say, even in the interests of
simplicity.  And, for what it's worth, TLS *is* getting simpler.  TLS
1.3 drastically reduced the amount of different configurations which are
possible.  I really wanted to spec TLS 1.3 as the minimum supported for
Gemini, but it's not yet supported in LibreSSL - which is itself all
about simplifying TLS, so discouraging adoption of it would be counter
productive on that front.  This is why we have TLS 1.2 as the minimum.
If it softens the blow any, I'm absolutely open to the idea of
explicitly disallowing some TLS 1.2 configurations.

Cheers,
Solderpunk


> #### About "pro-TLS", and "don't roll your own"
> 
> [I.e.  This part is a counter argument to my previous emails.  I still
> think we can do "simpler", but I do like to be fair, and thus I'm
> debating myself...]  :)
> 
> 
> Bellow I'll point out three articles, written by three different
> people (which after searching the internet seem to be knowledgeable in
> this domain, perhaps not Schneier / Bernstein level, but still much
> better than the average developer), in a time span of about 10 years.
> (The section we are interested in is `client-server application
> security`, and not `website security` because the later actually means
> "HTTPS security", thus TLS is mandatory, although the former
> completely ignores certificates, as in X.509, thus only SSH-like
> assumptions.)
> 
> * [2018]  https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
> * [2015]  https://gist.github.com/tqbf/be58d2d39690c3b366ad
> * [2009]  http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
> 
> 
> >From [2009] (although I would say it's an incomplete advice as it
> doesn't say what to do next):
> ~~~~
> One of the reasons OpenSSL has such a poor track record is that the
> SSL protocol itself is highly complex. Certificate chains, revocation
> lists, ASN.1, multiple different hashing and encryption schemes...
> when you have over a hundred thousand lines of code, it's no wonder
> that bugs creep in.
> ~~~~
> 
> 
> >From [2015] (Colin is the author of the [2009] article):
> ~~~~
> What happens when you design your own custom RSA protocol is that 1-18
> months afterward, hopefully sooner but often later, you discover that
> you made a mistake and your protocol had virtually no security. That
> happened to Colin, but a better example is Salt Stack. Salt managed to
> deploy e=1 RSA.
> 
> [...]
> 
> Most of these attacks can be mitigated by hardcoding TLS 1.2+, ECDHE
> and AES-GCM. That sounds tricky, and it is, but it's less tricky than
> designing your own transport protocol with ECDHE and AES-GCM!
> 
> In a custom transport scenario, you don't need to depend on CAs: you
> can self-sign a certificate and ship it with your code, just like
> Colin suggests you do with RSA keys.
> 
> Avoid: designing your own encrypted transport, which is a genuinely
> hard engineering problem; using TLS but in a default configuration,
> like, with "curl"; using "curl", IPSEC.
> ~~~~
> 
> 
> >From [2018]:
> ~~~~
> In custom protocols, you don?t have to (and shouldn?t) depend on 3rd
> party CAs. You don?t even have to use CAs at all (though it?s not hard
> to set up your own); you can just use a whitelist of self-signed
> certificates ? which is approximately what SSH does by default, and
> what you?d come up with on your own.
> 
> Since you?re doing a custom protocol, you can use the best possible
> TLS cipher suites: TLS 1.2+, Curve25519, and ChaPoly. That eliminates
> most attacks on TLS. The reason everyone doesn?t do this is that they
> need backwards-compatibility, but in custom protocols you don?t need
> that.
> 
> [...]
> 
> Avoid: designing your own encrypted transport, which is a genuinely
> hard engineering problem; using TLS but in a default configuration,
> like, with ?curl?; using ?curl?, IPSEC.
> ~~~~
> 
> 
> The takeaway:  if we go with TLS, let's mandate:
> * TLS 1.2 with TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
>   https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
> * or, TLS 1.3 with TLS_CHACHA20_POLY1305_SHA256
>   https://ciphersuite.info/cs/TLS_CHACHA20_POLY1305_SHA256
> * as for certificates only ECDSA, which seem to be available also via
> Lets Encrypt;
> 
> These options are also suggested by both Mozilla and CloudFlare:
> * https://wiki.mozilla.org/Security/Server_Side_TLS
> * https://developers.cloudflare.com/ssl/ssl-tls/cipher-suites
> 
> 
> 
> 
> #### About the noise protocol
> 
> I've glossed over the Noise protocol specification, however before
> getting into that I've read the first link bellow:
> 
> * https://latacora.micro.blog/factoring-the-noise/
> * https://noiseprotocol.org/noise.html  (this is the actual specification);
> 
> Basically I think the only Noise protocol instance that pertains to
> `gemini://` is the `XX` exchange pattern, citing from the first link
> above:
> ~~~~
> XX and XK require an extra round trip before they send over the
> initiator?s static key. Flip side: they have the strongest possible
> privacy protection for the initiator, whose identity is only sent to
> the responder after they?ve been authenticated and forward secrecy has
> been established.
> ~~~~
> 
> In fact Alexey Ermishkin together with Trevor Perrin (the original
> author of the protocol) have started a project called NoiseSocket,
> which basically just focuses on the the `XX` pattern.  (As for
> credentials, Trevor Perrin worked for WhatsApp in designing the Noise
> protocol, which is still used today.)
> 
> * https://github.com/noisesocket/spec
> * https://noisesocket.org/post/1/ -- I strongly suggest reading this
> document if one is interested in the Noise protocol;
> 
> The only disadvantage with Noise (or NoiseSocket) is that given the
> frame size is limited to 64K, in case of `gemini://` we need to
> implement extra "chunking" for it to work for bodies.  (Alternatively
> we can just use it as we do TLS, namely a "stupid pipe that just
> applies encryption"...)
> 
> 
> 
> 
> ####  The part about other alternatives
> 
> I've found the following project that also does a "state-of-the-art"
> analysis (though granted in 2015):
> 
> * https://github.com/auditdrivencrypto/secure-channel
> * https://github.com/auditdrivencrypto/secure-channel/blob/master/prior-art.md
> * https://github.com/auditdrivencrypto/secure-channel/blob/master/properties.md
> * https://github.com/auditdrivencrypto/secure-channel/blob/master/draft.md
> * https://github.com/auditdrivencrypto/secure-channel/blob/master/draft2.md
> 
> (I don't know his credentials, thus I would assume nothing.)
> 
> The "state-of-the-art" is quite "high-level", but it provides a nice
> starting point.  The properties document is a good check-list to
> analyze any proposal against.  (The only issue, is that he is
> interested in building a peer-to-peer network, thus at least the
> public key of the server is known in advance.)
> 
> The second draft (i.e. `draft2.md` above) is quite interesting,
> although as said it does one require to know beforehand the server's
> public key.
> 
> 
> 
> 
> ####  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 `transport_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).
> 
> Ciprian.
> 

From ciprian.craciun at gmail.com  Tue Mar  3 19:24:17 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Tue, 3 Mar 2020 21:24:17 +0200
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fwP9Qozkgk-KH25aea11KudN+f_njBdQWWTcmpfF2Qi+Q@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <CA+Tk8fwP9Qozkgk-KH25aea11KudN+f_njBdQWWTcmpfF2Qi+Q@mail.gmail.com>
Message-ID: <CA+Tk8fwNyfG685zXNYw_o12x2Hu7q5Twg3_uX42j1Q=+_PVYxQ@mail.gmail.com>

On Tue, Mar 3, 2020 at 2:20 PM Ciprian Dorin Craciun
<ciprian.craciun at gmail.com> wrote:
> ####  The part about other alternatives
>
> I've found the following project that also does a "state-of-the-art"
> analysis (though granted in 2015):


Another interesting approach is CurveCP (designed by Daniel J. Bernstein):
* http://www.curvecp.org/
* http://www.curvecp.org/security.html
* http://www.curvecp.org/packets.html -- especially interesting to read

However it has a few drawbacks:
* it is not yet widely implemented except in C;
* it does not use TCP, but instead UDP;
* it requires that the client knows beforehand the signing public key
of the server;

On the flip side, especially looking at the packets document, the
specification is extremely simple, both to understand and implement.
(The most complex part of that specification is the nonces
handling...)




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


In the interim I've reversed engineered the crypto primitives used by
`libsodium` (it wasn't hard, but I had to do it):

* https://github.com/cipriancraciun/gemini-experiments/blob/master/nacl/documentation/libsodium-internals.md


Then I've created a nice diagram of what happens in the proposed protocol:

* https://github.com/cipriancraciun/gemini-experiments/blob/master/nacl/documentation/diagrams/protocol-v1.png
* https://github.com/cipriancraciun/gemini-experiments/blob/master/nacl/documentation/diagrams/protocol-v1.svg




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

I've "fixed" that by making the server authenticate itself first.


Next I'll try to submit this proposal to a cryptographers community to
receive some feedback.

Ciprian.

From ciprian.craciun at gmail.com  Tue Mar  3 19:34:03 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Tue, 3 Mar 2020 21:34:03 +0200
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <20200303191620.GB29986@SDF.ORG>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <CA+Tk8fwP9Qozkgk-KH25aea11KudN+f_njBdQWWTcmpfF2Qi+Q@mail.gmail.com>
 <20200303191620.GB29986@SDF.ORG>
Message-ID: <CA+Tk8fzgpJKSKuf5yN8mY_cTMnQfUDggKxevMc7KUOVas2YGAA@mail.gmail.com>

On Tue, Mar 3, 2020 at 9:16 PM solderpunk <solderpunk at sdf.org> wrote:
> On Tue, Mar 03, 2020 at 02:20:57PM +0200, Ciprian Dorin Craciun wrote:
>
> > (Although I think the change of adopting anything besides TLS is
> > closer to 0 at this moment, which I would say is a shame...)
>
> You are pretty well right about this (and I won't even argue too
> strongly the fact that it's kind of a shame).
>
> I really hate to do anything like shutting this line of discussion down,
> especially after you have already invested so much effort into
> implementing a proof of concept.  But the truth is that I think it's too
> late in the game for this kind of change.


Can I still keep this thread "open", at least to give a "theoretical"
alternative?  (Just talking about the alternative, although not using
it, could give us an insight of what might be nice to have in a future
iteration.)

(I don't think I'll be posting much on this, except after I get some
feedback from the cryptographers community.)




> Replacing TLS with *anything* else would completely break every existing
> piece of Gemini software, which is a non-trivial amount, written by many
> different people of varying degrees of continuing activity in the
> project.

It's not like there are hundreds of client and server implementations...  :)




> There is a very real chance that this kind of change would
> introduce a permanent schism between "New Gemini" and "Old Gemini" when
> a subset of servers (in both senses of the word) and clients were not
> updated.  Not only would software break, but I imagine a lot of
> participants in the projet would be unhappy as well.  I worry that the
> community is too small and fraile to survive what would effectively be a
> fork.


This is perhaps true;  although as said, with strong consensus, I
don't think that would happen.

Ciprian.

From b__m__e at mailfence.com  Tue Mar  3 21:05:04 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Tue, 3 Mar 2020 22:05:04 +0100 (CET)
Subject: Tools
Message-ID: <977314474.88097.1583269503970@ichabod.co-bxl>

Solderpunk write's:
> [ ... ] So, let's spend most of our Gemini energy until June on creating
> content and tools! 

While thinking out content ideas I thought it might be nice to have some
basic tooling available. To that end I have created a highlight syntax and
file recognition for text/gemini documents when edited with Vim.

The spec for said documents is not very complex and syntax highlighting
may not be necessary, but it is nice to have to more clearly see what you
are working with.

The syntax covers everything in the current spec (preformatted blocks,
list items, headings, and links). The way it handles the url portion of a link
is extremely naive, but should work for most basic purposes (it does not
url formatting validation... any text coming after the magic string until the
next space is considered the url).

I have included a makefile for easy install into a local environment (users of
non-standard Vim implementations like SpaceVim will need to move the
files manually).

The filetype recognition recognizes files with a filetype equal to "gmi"). It is 
my understanding that that has become the common filetype. If that is not 
the case and additional support is required please let me know.

If anyone experiences any issues not spoken of in the README or has
ideas for updates or changes feel free to open an issue at the repo or
e-mail me directly.

Syntax available here:
https://tildegit.org/sloum/gemini-vim-syntax

Enjoy!

From solderpunk at SDF.ORG  Tue Mar  3 21:13:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 3 Mar 2020 21:13:33 +0000
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <CA+Tk8fzgpJKSKuf5yN8mY_cTMnQfUDggKxevMc7KUOVas2YGAA@mail.gmail.com>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <CA+Tk8fwP9Qozkgk-KH25aea11KudN+f_njBdQWWTcmpfF2Qi+Q@mail.gmail.com>
 <20200303191620.GB29986@SDF.ORG>
 <CA+Tk8fzgpJKSKuf5yN8mY_cTMnQfUDggKxevMc7KUOVas2YGAA@mail.gmail.com>
Message-ID: <20200303211333.GA4669@SDF.ORG>

On Tue, Mar 03, 2020 at 09:34:03PM +0200, Ciprian Dorin Craciun wrote:
 
> Can I still keep this thread "open", at least to give a "theoretical"
> alternative?  (Just talking about the alternative, although not using
> it, could give us an insight of what might be nice to have in a future
> iteration.)
> 
> (I don't think I'll be posting much on this, except after I get some
> feedback from the cryptographers community.)

As long as it's a reasonable amount of traffic, sure.
 
> > Replacing TLS with *anything* else would completely break every existing
> > piece of Gemini software, which is a non-trivial amount, written by many
> > different people of varying degrees of continuing activity in the
> > project.
> 
> It's not like there are hundreds of client and server implementations...  :)

Well, no, but it's not like there's 1 or 2 either.
 
Cheers,
Solderpunk


From singletona082 at gmail.com  Tue Mar  3 21:15:39 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Tue, 3 Mar 2020 15:15:39 -0600
Subject: Tools
In-Reply-To: <977314474.88097.1583269503970@ichabod.co-bxl>
References: <977314474.88097.1583269503970@ichabod.co-bxl>
Message-ID: <CAPBeim6rm+GnfHnJXggDCcK4U+UNXVVw9okuR5cREz1wCoqENA@mail.gmail.com>

Clicking the link takes me to a 404 page.

Do have question on why vim and what windows users could do as an onramp
but this is a one man operation and you are working wjth what you use.
Mostly just wanted toreport the 404.

On Tue, Mar 3, 2020, 3:05 PM Brian Evans <b__m__e at mailfence.com> wrote:

> Solderpunk write's:
> > [ ... ] So, let's spend most of our Gemini energy until June on creating
> > content and tools!
>
> While thinking out content ideas I thought it might be nice to have some
> basic tooling available. To that end I have created a highlight syntax and
> file recognition for text/gemini documents when edited with Vim.
>
> The spec for said documents is not very complex and syntax highlighting
> may not be necessary, but it is nice to have to more clearly see what you
> are working with.
>
> The syntax covers everything in the current spec (preformatted blocks,
> list items, headings, and links). The way it handles the url portion of a
> link
> is extremely naive, but should work for most basic purposes (it does not
> url formatting validation... any text coming after the magic string until
> the
> next space is considered the url).
>
> I have included a makefile for easy install into a local environment
> (users of
> non-standard Vim implementations like SpaceVim will need to move the
> files manually).
>
> The filetype recognition recognizes files with a filetype equal to "gmi").
> It is
> my understanding that that has become the common filetype. If that is not
> the case and additional support is required please let me know.
>
> If anyone experiences any issues not spoken of in the README or has
> ideas for updates or changes feel free to open an issue at the repo or
> e-mail me directly.
>
> Syntax available here:
> https://tildegit.org/sloum/gemini-vim-syntax
>
> Enjoy!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200303/2ed5d695/attachment.htm>

From julien at typed-hole.org  Tue Mar  3 21:18:19 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Tue, 3 Mar 2020 22:18:19 +0100
Subject: Tools
In-Reply-To: <977314474.88097.1583269503970@ichabod.co-bxl>
References: <977314474.88097.1583269503970@ichabod.co-bxl>
Message-ID: <6288065B-7E7A-4819-8B49-3C252D51D0DD@typed-hole.org>

Great idea! Now I have to make an Emacs mode :)

From singletona082 at gmail.com  Tue Mar  3 21:26:26 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Tue, 3 Mar 2020 15:26:26 -0600
Subject: Tools
In-Reply-To: <6288065B-7E7A-4819-8B49-3C252D51D0DD@typed-hole.org>
References: <977314474.88097.1583269503970@ichabod.co-bxl>
 <6288065B-7E7A-4819-8B49-3C252D51D0DD@typed-hole.org>
Message-ID: <CAPBeim64QU7A_VOswODDPgj4qZygvf9jSHVsJ-+Fr3rAeh5R3A@mail.gmail.com>

Well I brought it up mostly because I mainly use windows (boo! Hiss! I
know... I know.) however while i neither vim or emacs having options for
both in the Great Debate is in my view good.

Worse comes to worse, install linux for windows 10 and go from there. Will
admit part of my facination with gopher is the relative simplicity of
building the pages/maps so kinda head scratching here. Then again likely
that I missed a thing somewhere about the spec where the 'how a page is
built' is spelled out.

On Tue, Mar 3, 2020 at 3:18 PM Julien Blanchard <julien at typed-hole.org>
wrote:

> Great idea! Now I have to make an Emacs mode :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200303/7d9f39ca/attachment.htm>

From singletona082 at gmail.com  Tue Mar  3 21:33:40 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Tue, 3 Mar 2020 15:33:40 -0600
Subject: Tools
In-Reply-To: <CAPBeim64QU7A_VOswODDPgj4qZygvf9jSHVsJ-+Fr3rAeh5R3A@mail.gmail.com>
References: <977314474.88097.1583269503970@ichabod.co-bxl>
 <6288065B-7E7A-4819-8B49-3C252D51D0DD@typed-hole.org>
 <CAPBeim64QU7A_VOswODDPgj4qZygvf9jSHVsJ-+Fr3rAeh5R3A@mail.gmail.com>
Message-ID: <CAPBeim4TVqSPvSf8C1qrctCiAv8hTzGWbD_iELCs-HDYGAuc7Q@mail.gmail.com>

> And to poke the bear just slightly re: windows .....
> https://assets.amuniversal.com/6b08abb09fbb012f2fe600163e41dd5b

i'll have you know a friend dumpster dove for this computer as a parting
gift from boingboing's forums! (They didn't know it was a parting gift. I
just found the place a bit too uncomfortable and argument inducing.) In all
seriousness though it's a nice off lease box I'd done a few things to and I
really should reinstall one stripe of linux on or another, but then there
is the gaming that seems to not play entirely nice with linux, which is why
I hadn't bothered for a long while after my cr48 finally died (i had the
insyde bios and peppermint linux installed. It was rather nice given the
machine's limits.) Then again I tend to use nano when in command line
anyway because both vim and emacs seemed overkill (emacs, where you get an
entire environment along with your text editor ;))

> If you use another editor that supports syntax user made syntax files I'd
be happy to
> look into creating one. Let me know!
> mode :)

Only thing that springs to mind is notepad++ and I'm not sure if you can
add custom syntax definitions to it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200303/261eae70/attachment.htm>

From solderpunk at SDF.ORG  Tue Mar  3 21:41:32 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 3 Mar 2020 21:41:32 +0000
Subject: Tools
In-Reply-To: <CAPBeim64QU7A_VOswODDPgj4qZygvf9jSHVsJ-+Fr3rAeh5R3A@mail.gmail.com>
References: <977314474.88097.1583269503970@ichabod.co-bxl>
 <6288065B-7E7A-4819-8B49-3C252D51D0DD@typed-hole.org>
 <CAPBeim64QU7A_VOswODDPgj4qZygvf9jSHVsJ-+Fr3rAeh5R3A@mail.gmail.com>
Message-ID: <20200303214132.GB4669@SDF.ORG>

On Tue, Mar 03, 2020 at 03:26:26PM -0600, Andrew Singleton wrote:
 
> Worse comes to worse, install linux for windows 10 and go from there. Will
> admit part of my facination with gopher is the relative simplicity of
> building the pages/maps so kinda head scratching here. Then again likely
> that I missed a thing somewhere about the spec where the 'how a page is
> built' is spelled out.

IMHO, building a Gemini page is even easier than building a Gophermap.
You don't need to try to remember item types, and you can just paste
URLs instead of having to tab-separate hosts, ports and paths.  It's
about as simple as can be!

Cheers,
Solderpunk


From lazar.michael22 at gmail.com  Wed Mar  4 04:09:25 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 3 Mar 2020 23:09:25 -0500
Subject: [SPEC-CHANGE] Preformatted text,
 header and unordered list lines defined
In-Reply-To: <20200301163618.GA7582@SDF.ORG>
References: <20200301163618.GA7582@SDF.ORG>
Message-ID: <CAFTy05akd_1g7HQVCfhaSZWJai1u==_N0BFJkSysJ6vLJKxu+w@mail.gmail.com>

On Sun, Mar 1, 2020 at 11:36 AM solderpunk <solderpunk at sdf.org> wrote:
>
> Attention Gemininauts!
>
> I have officially updated the spec-spec just now.
>
> SUMMARY OF CHANGES:
>
> Section 1.3.5 (text/gemini response) has been edited and expanded in
> several places, to define new line types.  The only non-optional change
> defines lines beginning with ``` as toggling a "preformatted" mode,
> within which all lines (including those which would constitute link
> lines outside of preformatted mode) must be presented verbatim in a
> fixed width font.

Thank you for this solderpunk!

I have just finished updating my gemini server [1] and my gemini-http proxy [2]
to display the new line types. Things are looking optimistic and all of the
existing gemini servers are still readable with proportional fonts and wrapped
lines. This biggest change will be wrapping figlet art with ``` blocks.

(FYI, you need to drop the leading whitespace from the bullets on
gemini.circumlunar.space :p )

[1] gemini://mozz.us
[2] https://portal.mozz.us/

From stryan at saintnet.tech  Wed Mar  4 04:35:50 2020
From: stryan at saintnet.tech (Steve Ryan)
Date: Tue, 3 Mar 2020 23:35:50 -0500
Subject: [SPEC-CHANGE] Preformatted text, header and unordered list lines
 defined
In-Reply-To: <CAFTy05akd_1g7HQVCfhaSZWJai1u==_N0BFJkSysJ6vLJKxu+w@mail.gmail.com>
References: <20200301163618.GA7582@SDF.ORG>
 <CAFTy05akd_1g7HQVCfhaSZWJai1u==_N0BFJkSysJ6vLJKxu+w@mail.gmail.com>
Message-ID: <20200304043550.phyvzx527eh3lf2t@vineta.saintnet.lan>

On 20/03/03 11:09PM, Michael Lazar wrote:
> On Sun, Mar 1, 2020 at 11:36 AM solderpunk <solderpunk at sdf.org> wrote:
> >
> > Attention Gemininauts!
> >
> > I have officially updated the spec-spec just now.
> 
> Thank you for this solderpunk!
> 
> I have just finished updating my gemini server [1] and my gemini-http proxy [2]
> to display the new line types. Things are looking optimistic and all of the
> existing gemini servers are still readable with proportional fonts and wrapped
> lines. This biggest change will be wrapping figlet art with ``` blocks.

Will the jetforce_diagnostics script be updated as well? I've been using
it to make sure my server[0] is reasonably standard-compliant and it's
been a nice tool to have.

[0] https://github.com/stryan/secretshop

From sean at conman.org  Wed Mar  4 06:26:48 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 4 Mar 2020 01:26:48 -0500
Subject: [ANN] More client torture tests
Message-ID: <20200304062648.GA27976@brevard.conman.org>


  Client testing time!  More tests!  This time, checking the status codes.
It's an open question as to what a client should do with an invalid succss
code and an invalid redirection status.  The rest of the results I think
should be fine.

  -spc


From solderpunk at SDF.ORG  Wed Mar  4 09:51:31 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 4 Mar 2020 09:51:31 +0000
Subject: [SPEC-CHANGE] Preformatted text, header and unordered list lines
 defined
In-Reply-To: <CAFTy05akd_1g7HQVCfhaSZWJai1u==_N0BFJkSysJ6vLJKxu+w@mail.gmail.com>
References: <20200301163618.GA7582@SDF.ORG>
 <CAFTy05akd_1g7HQVCfhaSZWJai1u==_N0BFJkSysJ6vLJKxu+w@mail.gmail.com>
Message-ID: <20200304095131.GA22938@SDF.ORG>

On Tue, Mar 03, 2020 at 11:09:25PM -0500, Michael Lazar wrote:
 
> (FYI, you need to drop the leading whitespace from the bullets on
> gemini.circumlunar.space :p )

Ooh, thanks for the heads up!  I'll do that right now.

And I'll get all my clients recognising preformatting toggle lines in
the near future, this coming weekend at latest.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Mar  4 09:54:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 4 Mar 2020 09:54:16 +0000
Subject: [ANN] More client torture tests
In-Reply-To: <20200304062648.GA27976@brevard.conman.org>
References: <20200304062648.GA27976@brevard.conman.org>
Message-ID: <20200304095416.GB22938@SDF.ORG>

On Wed, Mar 04, 2020 at 01:26:48AM -0500, Sean Conner wrote:
> 
>   Client testing time!  More tests!  This time, checking the status codes.
> It's an open question as to what a client should do with an invalid succss
> code and an invalid redirection status.  The rest of the results I think
> should be fine.

Hmm.  An invalid success code, like a 20 followed by something that
isn't a valid MIME type?  Did the spec say that the MIME type after a 2x
is optional and if unspecified defaults to text/gemini?  (checks) No, it
doesn't.  So a naked 20 is also invalid.

And I guess an invalid redirect is one without a valid URL.

It seems to me like all a client ought to do in such a scenario is to
inform its user that it received an invalid response in a graceful
manner, rather than crash?

Cheers,
Solderpunk

From jmcbray at carcosa.net  Tue Mar 10 13:46:58 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 10 Mar 2020 09:46:58 -0400
Subject: An outsider's view of the `gemini://` protocol
In-Reply-To: <ea14fc2c-731a-46dc-b0d8-e27d86735396@www.fastmail.com> (Aaron
 Janse's message of "Fri, 28 Feb 2020 15:21:30 -0800")
References: <CA+Tk8fzzdJQ=j0tQsYbdspt5juCFPqjf8R0+0D13Vn=ZK=EGkQ@mail.gmail.com>
 <20200228223235.GA8734@SDF.ORG>
 <ea14fc2c-731a-46dc-b0d8-e27d86735396@www.fastmail.com>
Message-ID: <87d09k725p.fsf@cassilda.carcosa.net>

"Aaron Janse" <aaron at ajanse.me> writes:

> Please no. PGP is a bit of a mess already. It's tough to
> install/maintain (because it has a daemon), and it's really easy to
> mess up. I think using something like NaCl could be much more
> difficult to mess up than automated PGP.

Yeah, in 2020, PGP is an elaborate foot-gun.

The suggestion of Noise protocol is actually more interesting, as it's
smaller and more future-proof than TLS. But while there are
implementations in several languages, it's not as ubiquitous as TLS.
(For instance, I had no trouble writing a Gemini server in Common Lisp,
but I'd have to write my own bindings of the C implementation to use
Noise protocol.) I'd have to read a lot more about it to know what its
advantages are.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Tue Mar 10 13:50:00 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 10 Mar 2020 09:50:00 -0400
Subject: Is it too late to consider adding a subset of Markdown to the
 render spec?
In-Reply-To: <20200228094347.GA6322@SDF.ORG> (solderpunk@sdf.org's message of
 "Fri, 28 Feb 2020 09:43:47 +0000")
References: <CAPBeim4kNFVZHcShTfuH3cyiZQHBoAbs-+wDO85y+e-v8+dxgw@mail.gmail.com>
 <20200228094347.GA6322@SDF.ORG>
Message-ID: <878sk8720n.fsf@cassilda.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:
> The reason for this is that we are operating far too much in a vacuum.
> There is still very little original content in Geminispace, and even
> less of it which isn't *about* Gemini.

Definitely some of this is my bad. Life has really caught up with me.
Now that there's a search engine, I may start publishing my blog/phlog
to my Gemini capsule, rather than keeping my capsule separate. I can't
rely on security-through-obscurity to hide stuff I don't want on my
public web page anymore.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Tue Mar 10 13:55:31 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 10 Mar 2020 09:55:31 -0400
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <20200302001842.GC5475@brevard.conman.org> (Sean Conner's message
 of "Sun, 1 Mar 2020 19:18:42 -0500")
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
Message-ID: <874kuw71rg.fsf@cassilda.carcosa.net>

Sean Conner <sean at conman.org> writes:

> It was thus said that the Great Ciprian Dorin Craciun once stated:
>> So I've taken Sean Conner advice and implemented a proof-of-concept
>> client and server (only the protocol, transport and crypto part, not
>> the actual file serving) in Python by replacing TLS with NaCL /
>> `libsodium`.

> 2) As I feared, this requires a more complicated implementation.  solderpunk
> wanted a protocol that could be implemented quickly and while TLS might be a
> bad protocol, it at least has the feature of being widely available and
> largly transparent if done correctly (like libtls, part of LibreSSL, does). 
> It handles not only the crypo portion, but the framing of data (invisibly to
> the rest of the application).  To tell the truth, I don't know the actual
> bytes of the TLS portion of the protcol as that is handled for me.

If we really wanted to go down this route, Noise protocol is more
comparable to TLS than just using NaCL directly; the Python bindings
seem only about as complex to use as the Python TLS bindings. The only
thing is that Noise has libraries for 5 or 6 languages, compared to how
ubiquitous TLS is.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From ciprian.craciun at gmail.com  Tue Mar 10 14:02:12 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Tue, 10 Mar 2020 16:02:12 +0200
Subject: Regarding `gemini://` over NaCL (replacing TLS)
In-Reply-To: <874kuw71rg.fsf@cassilda.carcosa.net>
References: <CA+Tk8fwYfs29M1Z72qRLm20r_WCQgL98FFi-LesUzpjzMk=eNg@mail.gmail.com>
 <20200302001842.GC5475@brevard.conman.org>
 <874kuw71rg.fsf@cassilda.carcosa.net>
Message-ID: <CA+Tk8fwNcZQHLiqkFJvsmPAhsydnoK7JAyHNnLShpynZqNRxGg@mail.gmail.com>

On Tue, Mar 10, 2020 at 3:55 PM Jason McBrayer <jmcbray at carcosa.net> wrote:
> If we really wanted to go down this route, Noise protocol is more
> comparable to TLS than just using NaCL directly; the Python bindings
> seem only about as complex to use as the Python TLS bindings. The only
> thing is that Noise has libraries for 5 or 6 languages, compared to how
> ubiquitous TLS is.


In the interim I've documented my proposal, including a clear diagram,
used functions from libsodium and an asessment:
* https://github.com/cipriancraciun/gemini-experiments/blob/master/nacl/documentation/protocol-v1.md
* https://github.com/cipriancraciun/gemini-experiments/blob/master/nacl/documentation/libsodium-internals.md


Now, regarding the Noise protocol, as you've observed there aren't
many implementations of it;  however on the other side the Noise
protocol is actually a "blueprint" of how to implement secure
communication protocols and doesn't actually specify any cryptographic
primitives;  thus all the existing libraries are either incompatible
with each other or are quite uninteligible (I've looked at a few
Rust-based implementations and I wouldn't know where to start using
them).

On the other side my proposal was to get "inspired" from the Noise
protocol, and then try to provide a simple and clear "recipe" based on
that.


Ciprian.

From jmcbray at carcosa.net  Fri Mar 13 03:26:52 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 12 Mar 2020 23:26:52 -0400
Subject: Creating some Gemini-exclusive content
Message-ID: <87lfo5djer.fsf@cassilda.carcosa.net>

I've just started a ranty political newsletter about living in America
during the confluence of the 2020 Presidential election and the COVID-19
pandemic, called "President Xi, Send The Nukes". It should be updated
weekdays with a summary of the latest outrages, brain worms, and
political perversions.

gemini://carcosa.net/send-the-nukes

Send me an email to comment on it.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From krixano at protonmail.com  Mon Mar 16 12:28:15 2020
From: krixano at protonmail.com (Krixano)
Date: Mon, 16 Mar 2020 12:28:15 +0000
Subject: New Gemini Server
Message-ID: <cnhGhvKkk8awNKsCsdjZqsIlnT7SK02HXizOAzpZkqt-K7WvdjpFtPTYXl_9CzqKqlRR9c4KpZGi4ZhUoSGJxzCdCC7fnemuYaIgDeJ-5PI=@protonmail.com>

Hello (Geminites?)

I've created a new Gemini server hosted on a new pubnix that I will be opening up to the public soon, called PoNIX. You can visit the Gemini server at `gemini://pon.ix.tc`.

Christian Seibold

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200316/25e00cc8/attachment.htm>

From jmcbray at carcosa.net  Mon Mar 16 14:48:28 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 16 Mar 2020 10:48:28 -0400
Subject: New Gemini Server
In-Reply-To: <cnhGhvKkk8awNKsCsdjZqsIlnT7SK02HXizOAzpZkqt-K7WvdjpFtPTYXl_9CzqKqlRR9c4KpZGi4ZhUoSGJxzCdCC7fnemuYaIgDeJ-5PI=@protonmail.com>
 (krixano@protonmail.com's message of "Mon, 16 Mar 2020 12:28:15 +0000")
References: <cnhGhvKkk8awNKsCsdjZqsIlnT7SK02HXizOAzpZkqt-K7WvdjpFtPTYXl_9CzqKqlRR9c4KpZGi4ZhUoSGJxzCdCC7fnemuYaIgDeJ-5PI=@protonmail.com>
Message-ID: <875zf4jqyr.fsf@cassilda.carcosa.net>


Nice! Glad to see it.
-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From solderpunk at SDF.ORG  Tue Mar 17 10:25:13 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 17 Mar 2020 10:25:13 +0000
Subject: New Gemini Server
In-Reply-To: <875zf4jqyr.fsf@cassilda.carcosa.net>
References: <cnhGhvKkk8awNKsCsdjZqsIlnT7SK02HXizOAzpZkqt-K7WvdjpFtPTYXl_9CzqKqlRR9c4KpZGi4ZhUoSGJxzCdCC7fnemuYaIgDeJ-5PI=@protonmail.com>
 <875zf4jqyr.fsf@cassilda.carcosa.net>
Message-ID: <20200317102513.GA22166@SDF.ORG>

On Mon, Mar 16, 2020 at 10:48:28AM -0400, Jason McBrayer wrote:
> 
> Nice! Glad to see it.

Yes, I'm glad too, both that the PoNIX project is going well, and that
it will support Gemini.  I've added your server to the master list at
gemini://gemini.circumlunar.space/servers/.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Mar 17 10:26:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 17 Mar 2020 10:26:54 +0000
Subject: Creating some Gemini-exclusive content
In-Reply-To: <87lfo5djer.fsf@cassilda.carcosa.net>
References: <87lfo5djer.fsf@cassilda.carcosa.net>
Message-ID: <20200317102654.GB22166@SDF.ORG>

On Thu, Mar 12, 2020 at 11:26:52PM -0400, Jason McBrayer wrote:
> I've just started a ranty political newsletter about living in America
> during the confluence of the 2020 Presidential election and the COVID-19
> pandemic, called "President Xi, Send The Nukes". It should be updated
> weekdays with a summary of the latest outrages, brain worms, and
> political perversions.
> 
> gemini://carcosa.net/send-the-nukes

Wonderful!  Thanks for making the effort to do this.  It's motivated me
to finally start writing a few simple tools to facilitate aggregation of
regularly updated content in Geminispace.  I hope you'll be a willing
guinea pig!  Expect to hear more on this later this week.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Mar 17 20:39:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 17 Mar 2020 20:39:19 +0000
Subject: [ANN] Announcing Gemfeed, an Atom feed tool for Gemini
Message-ID: <20200317203919.GA697@SDF.ORG>

Greetings, Geminauts!

I had been planning something like this for a while, but the recent
announcement of the "Send the nukes" gemlog prompted me to get off my
butt and actually churn it out.

I am happy to announce that a tool named Gemfeed
(https://tildegit.org/solderpunk/gemfeed) is now ready for preliminary
testing.  Gemfeed's job is to create a single XML file containing an
Atom feed for all the .gmi or .gemini files in a single directory,
except the index.gmi/index.gemini file, if it exists.  It's designed
to be a very easy solution for a simple gemlog which is just a bunch
of .gmi files in a directory, especially when you are using the newly
specced heading line syntax (where h1, h2 and h3 level headings are
lines beginning with #, ## and ###).  You can either run it manually
after each post, or just set a cronjob to run it regularly enough and
then forget about it.  There are options to override the following
behaviour, but by default it uses the first heading it finds in the
index file as the feed's title, and uses the first heading it finds in
every non-index file as the title of an entry in the feed.  Each
entry's update time is set to the corresponding file's creation time
(not modification time, so you can fix minor typos the day after
without your feed changing).  Basically, if you are using headings in
a sensible way, all you need to tell Gemfeed is the URL corresponding
to the directory you're creating a feed for, and it will produce
something sensible.

Full instructions at
https://tildegit.org/solderpunk/gemfeed/src/branch/master/README.md.

If you have any kind of periodically updated Gemini content, please
give this a try!  I now plan to immediately begin work on a public
aggregator named CAPCOM (it will be both a tool you can use for your
own aggregation, like moku-pona, and a high-profile public aggregator,
like Bongusta), so the incentive for adopting Gemfeed is that you'll
be able to get your content aggregated there from the earliest days.
Stay tuned!

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Tue Mar 17 20:43:10 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 17 Mar 2020 20:43:10 +0000
Subject: [ANN] Announcing Gemfeed, an Atom feed tool for Gemini
In-Reply-To: <20200317203919.GA697@SDF.ORG>
References: <20200317203919.GA697@SDF.ORG>
Message-ID: <20200317204310.GB697@SDF.ORG>

Whoops, I forgot to mention, Gemfeed depends upon the "FeedGen" library
for Python:

https://github.com/lkiesow/python-feedgen

It's installable via pip with `pip install feedgen`.  I'll make a
setup.py for Gemfeed declaring this dependency as soon as the invetiable
first round of bugs get shaken out by brave volunteers from this list.

Also forgot to mention, if you are using the free Gemini hosting offered
at gemini.circumlunar.space and want to start having feeds generated for
any of your directories, let me know which ones and I'll setup a cron
job for you (which you can't do yourself with only sftp access).

Cheers,
Solderpunk


From jmcbray at carcosa.net  Wed Mar 18 11:36:44 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 18 Mar 2020 07:36:44 -0400
Subject: [ANN] Announcing Gemfeed, an Atom feed tool for Gemini
In-Reply-To: <20200317204310.GB697@SDF.ORG> (solderpunk@sdf.org's message of
 "Tue, 17 Mar 2020 20:43:10 +0000")
References: <20200317203919.GA697@SDF.ORG> <20200317204310.GB697@SDF.ORG>
Message-ID: <87imj16gj7.fsf@cassilda.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> It's installable via pip with `pip install feedgen`. I'll make a
> setup.py for Gemfeed declaring this dependency as soon as the
> invetiable first round of bugs get shaken out by brave volunteers from
> this list.

I've used it to generate a feed for "President Xi, Send The Nukes". Only
issue I notice is that if I pass "-b gemini://carcosa.net/send-the-nukes/"
as the base URL, the feed generates a rel=self for itself of
gemini://carcosa.net/atom.xml, rather than
gemini://carcosa.net/send-the-nukes/atom.xml. The links for all the
other resources are right.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From solderpunk at SDF.ORG  Wed Mar 18 17:18:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 18 Mar 2020 17:18:54 +0000
Subject: [ANN] Announcing Gemfeed, an Atom feed tool for Gemini
In-Reply-To: <87imj16gj7.fsf@cassilda.carcosa.net>
References: <20200317203919.GA697@SDF.ORG> <20200317204310.GB697@SDF.ORG>
 <87imj16gj7.fsf@cassilda.carcosa.net>
Message-ID: <20200318171854.GA16925@SDF.ORG>

On Wed, Mar 18, 2020 at 07:36:44AM -0400, Jason McBrayer wrote:
> 
> I've used it to generate a feed for "President Xi, Send The Nukes". Only
> issue I notice is that if I pass "-b gemini://carcosa.net/send-the-nukes/"
> as the base URL, the feed generates a rel=self for itself of
> gemini://carcosa.net/atom.xml, rather than
> gemini://carcosa.net/send-the-nukes/atom.xml. The links for all the
> other resources are right.

Hmm, are you sure you were including a trailing slash with the base URL?
If you were giving "-b gemini://carcosa.net/send-the-nukes" then I can
see why this would happen, given the standard logic for converting base
and relative URLs to an absolute URL.  I've just pushed a commit which
will add the trailing slash in if it's missing, which would fix that
case.  But if you really were including the slash, then I'm not sure
what's going on...

I also fixed the issue with it picking up your index.gmi.  If you pull
the latest code and regenerate you should at least see that fixed.

Thanks for helping me kick the tyres!

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Thu Mar 19 19:25:25 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 19 Mar 2020 19:25:25 +0000
Subject: [ANN] Announcing Gemfeed, an Atom feed tool for Gemini
In-Reply-To: <20200318171854.GA16925@SDF.ORG>
References: <20200317203919.GA697@SDF.ORG> <20200317204310.GB697@SDF.ORG>
 <87imj16gj7.fsf@cassilda.carcosa.net>
 <20200318171854.GA16925@SDF.ORG>
Message-ID: <20200319192525.GA26306@SDF.ORG>

Gemfeed is now registered at PyPi, so you can install it easily with
pip!  That's one less excuse for not giving it a try. :)

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Mar 19 19:38:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 19 Mar 2020 19:38:59 +0000
Subject: [ANN] Announcing CAPCOM, a Gemini Atom aggregator
Message-ID: <20200319193859.GB26306@SDF.ORG>

Greetings Geminauts!

Hot on the heels of Gemfeed, I'm happy to announce that a rough first
implementation now exists of my long-planned Gemini feed aggregator,
CAPCOM:

https://tildegit.org/solderpunk/CAPCOM

It's probably not yet ready for people to experiment with setting up
their own personal CAPCOMs (ala moku-pona), but I'm announcing it
already to draw attention to the fact that I now have an experimental
version of the public CAPCOM instance up at:

gemini://gemini.circumlunar.space/capcom/

It is aggregating jmcbray's "Send the Nukes" feed, and the feed for my
own "Hi-ten Heroes" cycling gemlog, because these are the only feeds I
know of!  Only you can help to change that...

At least in these very early days of Geminispace, I don't intend to
"curate" the public CAPCOM, it will basically be the "firehose" for
all of Geminispace.  I hope this will make it an awful lot easier for
the small community to keep tabs on itself, compared to manually
checking a whole lot of infrequently updated addresses every day.  I
also hope that it will remove the fear that some people may have been
having that there's no point spending time producing content for
Gemini because nobody will find or read it.  Now that we have
something like Bongusta, there is no reason an active gemlogosphere
can't bootstrap itself.

As already stated, if you are using the sftp-based free Geminispace I
offer at gemini.circumlunar.space, you can email me to get an Atom
feed generated for any of your directories via a cron job.  If you are
hosting content at your own server (or any server where you can setup
cron jobs or run commands from ssh), you can test out Gemfeed 1.0.0 to
generate your own feed!  If you get it working, just email me (or the
list) your feed URL and I will add it to CAPCOM.

Cheers,
Solderpunk

From sean at conman.org  Sun Mar 22 01:39:46 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 21 Mar 2020 21:39:46 -0400
Subject: Requests for robots.txt
Message-ID: <20200322013946.GC22036@brevard.conman.org>


  I'm going through my Gemini logs, and I'm finding this:

remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua:1965/robots.txt" bytes=14 subject="" issuer=""
remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua/glv-1:1965/robots.txt" bytes=14 subject="" issuer=""
remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua/glv-1/handlers:1965/robots.txt" bytes=14 subject="" issuer=""
remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua/glv-1/handlers/filesystem.lua:1965/robots.txt" bytes=14 subject="" issuer=""
remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua/glv-1/handlers/sample.lua:1965/robots.txt" bytes=14 subject="" issuer=""
remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua/glv-1/handlers/userdir.lua:1965/robots.txt" bytes=14 subject="" issuer=""
remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua/glv-1/msg.lua:1965/robots.txt" bytes=14 subject="" issuer=""
remote=XXX.XXX.XXX.XXX status=51 request="gemini://gemini.conman.org/sourcecode/lua/glv-1/cgi.lua:1965/robots.txt" bytes=14 subject="" issuer=""

(I'm censoring the IP to protect the guilty here)

  I don't mind the crawling, but I am concerned about the references to
robots.txt.  In the web world, robots.txt lives at the top level and *only*
at the top level.  I don't think there's been a official response from
solderpunk about robots.txt, but I would expect it to be very similar to how
it works on the web---the top level only.

  But a clarification would be nice (either way).  In my opinion, it should
only live at the top level, but I can adapt to every "directory" as well.

  -spc


From solderpunk at SDF.ORG  Sun Mar 22 11:51:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 22 Mar 2020 11:51:21 +0000
Subject: Requests for robots.txt
In-Reply-To: <20200322013946.GC22036@brevard.conman.org>
References: <20200322013946.GC22036@brevard.conman.org>
Message-ID: <20200322115121.GA26849@SDF.ORG>

On Sat, Mar 21, 2020 at 09:39:46PM -0400, Sean Conner wrote:
 
>   I don't mind the crawling, but I am concerned about the references to
> robots.txt.  In the web world, robots.txt lives at the top level and *only*
> at the top level.  I don't think there's been a official response from
> solderpunk about robots.txt, but I would expect it to be very similar to how
> it works on the web---the top level only.
> 
>   But a clarification would be nice (either way).  In my opinion, it should
> only live at the top level, but I can adapt to every "directory" as well.

This is nicely timed, actually, as things like robots.txt are now
looming larger on my personal radar than they have previously - with
CAPCOM I am writing for the first time a program which automatically
makes Gemini requests, and I'm very keen on making sure that it's a
"good citizen".  There hasn't been too much overt discussion of good
Gemini citizenship yet, but now that non-human clients are becoming more
common, there should be.  Robots.txt is obviously part of that package.

(It's *not* super relevant to feed aggregation, because nobody publishes
a feed without the expectation that it is read entirely by bots, but
other issues, especially rate limiting, rate)

It's been many years since I read any robots.txt specs from the web.  I
will refresh my memory and start thinking about this, and asking
questions, in the hopes that we can finalise some stuff soon.

Cheers,
Solderpunk

From natpen at natpen.net  Sun Mar 22 11:59:22 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sun, 22 Mar 2020 07:59:22 -0400
Subject: Requests for robots.txt
In-Reply-To: <20200322013946.GC22036@brevard.conman.org>
References: <20200322013946.GC22036@brevard.conman.org>
Message-ID: <20200322115922.GA1875@goldfish.localdomain>

FWIW I'm 99% sure those are requests from GUS, and I agree that it
should be top level only. That was a regression in GUS' crawling code,
which I've now fixed!

I'm still very happy to accommodate more official guidance on how
robots.txt should work, but in the meantime (and in the absence of any
more regressions, eep!) I plan to check top-level-only robots.txt.

So sorry about the :bug:!

From solderpunk at SDF.ORG  Sun Mar 22 18:13:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 22 Mar 2020 18:13:33 +0000
Subject: robots.txt for Gemini
Message-ID: <20200322181333.GB26849@SDF.ORG>

Howdy all,

As the first and perhaps most important push toward getting some clear
guidelines in place for well-behaved non-human Gemini clients (e.g.
Gemini to web proxies, search engine spiders, feed aggregators, etc.),
let's get to work on adapting robots.txt to Gemini.

My current thinking is that this doesn't belong in the Gemini spec
itself, much like robots.txt does not belong in the HTTP spec.  That
said, this feels like it warrants something more than just being put in
the Best Practices doc.  Maybe we need to start working on official
"side specs", too.  Not sure what these should be called.

Anyway, I've refamiliarised myself with robots.txt.  Turns out it is
still only a de facto standard without an official RFC.  My
understanding is based on:

* The https://www.robotstxt.org/ website (which Wikipedia calls the
  "Official website" at
  https://en.wikipedia.org/wiki/Robots_exclusion_standard - it's not
  clear to me what "official" means for a de facto standard), and in
  particular:
* An old draft RFC from 1996 which that site hosts at
  https://www.robotstxt.org/norobots-rfc.txt
* A new draft RFC from 2019 which appears to have gotten further than
  the first, considering it is hosted by the IETF at
  https://tools.ietf.org/html/draft-rep-wg-topic-00

While the 1996 draft is web-specific, I was pleasantly surprised to
see that the 2019 version is not.  Section 2.3 says:

> As per RFC3986 [1], the URI of the robots.txt is:
> 
> "scheme:[//authority]/robots.txt"
> 
> For example, in the context of HTTP or FTP, the URI is:
> 
> http://www.example.com/robots.txt
> 
> https://www.example.com/robots.txt
> 
> ftp://ftp.example.com/robots.txt

So, why not Gemini too?

Regarding the first practical question which was raised by Sean's recent
post, it seems a no-brainer to me that Gemini should retain the
convention of there being a single /robots.txt URL rather than having
them per-directory or anything like that.  Which it now seems was the
intended behaviour of GUS all along, so I'm guessing nobody will find
this controversial (but speak up if you do).

https://www.robotstxt.org/robotstxt.html claims that excluding all files
except one from robot access is "currently a bit awkward, as there is no
"Allow" field".  However, both the old and new RFC drafts clearly
mention one.  I am not sure exactly what the ground truth is here, in
terms of how often Allow is used in the wild or to what extent it is
obeyed even by well-intentiond bots.  I would be very happy in principle
to just declare that Allow lines are valid for Gemini robot.txt files,
but if it turns out that popular programming languages have standard
library tools for parsing robot.txt which don't choke on gemini:// URLs
but don't recognise "Allow", this could quickly lead to unintended
consequences, so perhaps it is best to be conservative here.

If anybody happens to be familiar with current practice on the web with
regard to Allow, please chime in.

There is the question of caching.  Both RFC drafts for robots.txt make
it clear that standard HTTP caching mechanisms apply to robots.txt, but
Gemini doesn't have an equivalent and I'm not interested in adding one
yet, especially not for the purposes of robots.txt.  And yet, obviously,
*some* caching needs to take place.  A spider requesting /robots.txt
again and again for every document at a host is generating a lot of
needless traffic.  The 1996 RFC recommends "If no cache-control
directives are present robots should default to an expiry of 7 days",
while the 2019 one says "Crawlers SHOULD NOT use the cached version for
more than 24 hours, unless the robots.txt is unreachable".  My gut tells
me most Gemini robots.txt files will change very infrequently and 7 days
is more appropriate than 24 hours, but I'm happy for us to discuss this.

The biggest question, in my mind, is what to do about user-agents, which
Gemini lacks (by design, as they are a component of the browser
fingerprinting problem, and because they encourage content developers to
serve browser-specific content which is a bad thing IMHO).  The 2019 RFC
says "The product token SHOULD be part of the identification string that
the crawler sends to the service" (where "product token" is bizarre and
disappointingly commercial alternative terminology for "user-agent" in
this document), so the fact that Gemini doesn't send one is not
technically a violation.

Of course, a robot doesn't need to *send* its user-agent in order to
*know* its user-agent and interpet robots.txt accordingly.  But it's
much harder for Gemini server admins than their web counterparts to know
exactly which bot is engaging in undesired behaviour and how to address
it.  Currently, the only thing that seems achievable in Gemini is to use
the wildcard user-agent "*" to allow/disallow access by *all* bots to
particular resources.

But not all bots are equal.  I'm willing to bet there are people using
Gemini who are perfectly happy with e.g. the GUS search engine spider
crawling their site to make it searchable via a service which is offered
exclusively within Geminispace, but who are not happy with Gemini to web
proxies accessing their content because they are concerned that
poorly-written proxies will not disallow Google from crawling them so
that Gemini content ends up being searchable within webspace.  This is a
perfectly reasonable stance to take and I think we should try to
facilitate it.

With no Gemini-specific changes to the de facto robots.txt spec, this
would require admins to either manually maintain a whitelist of
Gemini-only search engine spiders in their robots.txt *or* a blacklist
of web proxies.  This is easy today when you can count the number of
either of things on one hand, but it does not scale well and is not a
reasonable thing to expect admins to do in order to enforce a reasonable
stance.

(and, really, this isn't a Gemini-specific problem and I'm surprised
that what I'm about to propose isn't a thing for the web)

I have mentioned previously on this list (quickly, in passing), the idea
of "meta user-agents" (I didn't use that term when I first mentioned
it).  But since there is no way for Gemini server admins to learn the
user-agent of arbitrary bots, we could define a small (I'm thinking ~5
would suffice, surely 10 at most) number of pre-defined user-agents
which all bots of a given kind MUST respect (in addition to optionally
having their own individual user-agent).  A very rough sketch of some
possibilities, not meant to be exhaustive or even very good, just to
give the flavour:

* A user-agent of "webproxy" which must be respected by all web proxies.
  Possibly this could have sub-types for proxies which do and don't
  forbid web search engines?
* A user-agent of "search" which must be respected by all search engine
  spiders
* A user-agent of "research" for bots which crawl a site without making
  specific results of their crawl publically available (I've thought of
  writing something like this to study the growth of Geminispace and the
  structure of links between documents)

Enumerating actual use cases is probably the wrong way to go about it,
rather we should think of broad classes of behaviour which differ with
regard to privacy implications - e.g. bots which don't make the results
of their crawling public, bots which make their results public over
Gemini only, bots which breach the Gemini-web barrier, etc.

Do people think this is a good idea?

Can anybody think of other things to consider in adapting robots.txt to
Gemini?

Cheers,
Solderpunk

From krixano at protonmail.com  Sun Mar 22 22:39:05 2020
From: krixano at protonmail.com (Krixano)
Date: Sun, 22 Mar 2020 22:39:05 +0000
Subject: robots.txt for Gemini
In-Reply-To: <20200322181333.GB26849@SDF.ORG>
References: <20200322181333.GB26849@SDF.ORG>
Message-ID: <tNXt7WjS-5AlS6TEThMbkVE9yb3GEwQLaVgorbKIa9l2Z1OegK3tX7PwFlw7HLJ5i7nWPieiCACrWKFKGgdLwYdwwihvWTTA-i0BBN7yCsQ=@protonmail.com>

You can go to literally any website and append "/robots.txt" to see what they use. I've already seen a couple that use "Allow".


Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Sunday, March 22, 2020 1:13 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> Howdy all,
>
> As the first and perhaps most important push toward getting some clear
> guidelines in place for well-behaved non-human Gemini clients (e.g.
> Gemini to web proxies, search engine spiders, feed aggregators, etc.),
> let's get to work on adapting robots.txt to Gemini.
>
> My current thinking is that this doesn't belong in the Gemini spec
> itself, much like robots.txt does not belong in the HTTP spec. That
> said, this feels like it warrants something more than just being put in
> the Best Practices doc. Maybe we need to start working on official
> "side specs", too. Not sure what these should be called.
>
> Anyway, I've refamiliarised myself with robots.txt. Turns out it is
> still only a de facto standard without an official RFC. My
> understanding is based on:
>
> -   The https://www.robotstxt.org/ website (which Wikipedia calls the
>     "Official website" at
>     https://en.wikipedia.org/wiki/Robots_exclusion_standard - it's not
>     clear to me what "official" means for a de facto standard), and in
>     particular:
>
> -   An old draft RFC from 1996 which that site hosts at
>     https://www.robotstxt.org/norobots-rfc.txt
>
> -   A new draft RFC from 2019 which appears to have gotten further than
>     the first, considering it is hosted by the IETF at
>     https://tools.ietf.org/html/draft-rep-wg-topic-00
>
>     While the 1996 draft is web-specific, I was pleasantly surprised to
>     see that the 2019 version is not. Section 2.3 says:
>
>
> > As per RFC3986 [1], the URI of the robots.txt is:
> > "scheme:[//authority]/robots.txt"
> > For example, in the context of HTTP or FTP, the URI is:
> > http://www.example.com/robots.txt
> > https://www.example.com/robots.txt
> > ftp://ftp.example.com/robots.txt
>
> So, why not Gemini too?
>
> Regarding the first practical question which was raised by Sean's recent
> post, it seems a no-brainer to me that Gemini should retain the
> convention of there being a single /robots.txt URL rather than having
> them per-directory or anything like that. Which it now seems was the
> intended behaviour of GUS all along, so I'm guessing nobody will find
> this controversial (but speak up if you do).
>
> https://www.robotstxt.org/robotstxt.html claims that excluding all files
> except one from robot access is "currently a bit awkward, as there is no
> "Allow" field". However, both the old and new RFC drafts clearly
> mention one. I am not sure exactly what the ground truth is here, in
> terms of how often Allow is used in the wild or to what extent it is
> obeyed even by well-intentiond bots. I would be very happy in principle
> to just declare that Allow lines are valid for Gemini robot.txt files,
> but if it turns out that popular programming languages have standard
> library tools for parsing robot.txt which don't choke on gemini:// URLs
> but don't recognise "Allow", this could quickly lead to unintended
> consequences, so perhaps it is best to be conservative here.
>
> If anybody happens to be familiar with current practice on the web with
> regard to Allow, please chime in.
>
> There is the question of caching. Both RFC drafts for robots.txt make
> it clear that standard HTTP caching mechanisms apply to robots.txt, but
> Gemini doesn't have an equivalent and I'm not interested in adding one
> yet, especially not for the purposes of robots.txt. And yet, obviously,
> some caching needs to take place. A spider requesting /robots.txt
> again and again for every document at a host is generating a lot of
> needless traffic. The 1996 RFC recommends "If no cache-control
> directives are present robots should default to an expiry of 7 days",
> while the 2019 one says "Crawlers SHOULD NOT use the cached version for
> more than 24 hours, unless the robots.txt is unreachable". My gut tells
> me most Gemini robots.txt files will change very infrequently and 7 days
> is more appropriate than 24 hours, but I'm happy for us to discuss this.
>
> The biggest question, in my mind, is what to do about user-agents, which
> Gemini lacks (by design, as they are a component of the browser
> fingerprinting problem, and because they encourage content developers to
> serve browser-specific content which is a bad thing IMHO). The 2019 RFC
> says "The product token SHOULD be part of the identification string that
> the crawler sends to the service" (where "product token" is bizarre and
> disappointingly commercial alternative terminology for "user-agent" in
> this document), so the fact that Gemini doesn't send one is not
> technically a violation.
>
> Of course, a robot doesn't need to send its user-agent in order to
> know its user-agent and interpet robots.txt accordingly. But it's
> much harder for Gemini server admins than their web counterparts to know
> exactly which bot is engaging in undesired behaviour and how to address
> it. Currently, the only thing that seems achievable in Gemini is to use
> the wildcard user-agent "*" to allow/disallow access by all bots to
> particular resources.
>
> But not all bots are equal. I'm willing to bet there are people using
> Gemini who are perfectly happy with e.g. the GUS search engine spider
> crawling their site to make it searchable via a service which is offered
> exclusively within Geminispace, but who are not happy with Gemini to web
> proxies accessing their content because they are concerned that
> poorly-written proxies will not disallow Google from crawling them so
> that Gemini content ends up being searchable within webspace. This is a
> perfectly reasonable stance to take and I think we should try to
> facilitate it.
>
> With no Gemini-specific changes to the de facto robots.txt spec, this
> would require admins to either manually maintain a whitelist of
> Gemini-only search engine spiders in their robots.txt or a blacklist
> of web proxies. This is easy today when you can count the number of
> either of things on one hand, but it does not scale well and is not a
> reasonable thing to expect admins to do in order to enforce a reasonable
> stance.
>
> (and, really, this isn't a Gemini-specific problem and I'm surprised
> that what I'm about to propose isn't a thing for the web)
>
> I have mentioned previously on this list (quickly, in passing), the idea
> of "meta user-agents" (I didn't use that term when I first mentioned
> it). But since there is no way for Gemini server admins to learn the
> user-agent of arbitrary bots, we could define a small (I'm thinking ~5
> would suffice, surely 10 at most) number of pre-defined user-agents
> which all bots of a given kind MUST respect (in addition to optionally
> having their own individual user-agent). A very rough sketch of some
> possibilities, not meant to be exhaustive or even very good, just to
> give the flavour:
>
> -   A user-agent of "webproxy" which must be respected by all web proxies.
>     Possibly this could have sub-types for proxies which do and don't
>     forbid web search engines?
>
> -   A user-agent of "search" which must be respected by all search engine
>     spiders
>
> -   A user-agent of "research" for bots which crawl a site without making
>     specific results of their crawl publically available (I've thought of
>     writing something like this to study the growth of Geminispace and the
>     structure of links between documents)
>
>     Enumerating actual use cases is probably the wrong way to go about it,
>     rather we should think of broad classes of behaviour which differ with
>     regard to privacy implications - e.g. bots which don't make the results
>     of their crawling public, bots which make their results public over
>     Gemini only, bots which breach the Gemini-web barrier, etc.
>
>     Do people think this is a good idea?
>
>     Can anybody think of other things to consider in adapting robots.txt to
>     Gemini?
>
>     Cheers,
>     Solderpunk
>



From b__m__e at mailfence.com  Mon Mar 23 05:04:47 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Mon, 23 Mar 2020 06:04:47 +0100 (CET)
Subject: Announcing `spacewalk`
Message-ID: <1276766723.224624.1584939887478@ichabod.co-bxl>

Greetings all!

I too have been working on getting some aggregation tools together for gemini.
I have written this: https://tildegit.org/sloum/spacewalk

It generates update listings similarly to moku-pona. It is written in golang and
takes advantage of concurrency when checking for updates to pages and should
run pretty fast. It also allows for individual users to manage multiple aggregation
feeds/pages and is ideal on a multiuser system (though users will still need access
to cron to be able to have things automatically run on a schedule).

If you get it installed and running please let me know how it works out for you as
I have not had opportunity to use it in conjunction with an actual gemini server
as of yet (just a lot of local testing).

I know there is also still the problem of content on gemini that does not involve
talking about gemini itself. To that end I have put up some content on my
circumlunar geminispace:

gemini://gemini.circumlunar.space:1965/~sloum/

I was a musician in a previous life and have a large catalog of various types of
music. I thought maybe it could have a second life on gemini, or a first life in the
case of a few things I plan to eventually post. My plan is to put up another album
every week or two. The first one is a drone/ambient album. Hopefully someone
will enjoy some of it (there is a bunch of different stuff, so definitely come back
again even if the first one isnt to your taste).

Credit where credit is due:

The idea to put up music was very much inspired by Cat's excellent gemini capsule
KONPeITO (gemini://konpeito.media), which posts really really awesome mixes.


I hope the plaguetimes are treating everyone alright and that you are all staying
safe/healthy!

From jmcbray at dorothy.carcosa.net  Tue Mar 24 12:47:53 2020
From: jmcbray at dorothy.carcosa.net (Jason McBrayer)
Date: Tue, 24 Mar 2020 08:47:53 -0400
Subject: robots.txt for Gemini
In-Reply-To: <20200322181333.GB26849@SDF.ORG>
References: <20200322181333.GB26849@SDF.ORG>
Message-ID: <87blol9ax2.fsf@dorothy.carcosa.net>


solderpunk writes:

> But since there is no way for Gemini server admins to learn the
> user-agent of arbitrary bots, we could define a small (I'm thinking ~5
> would suffice, surely 10 at most) number of pre-defined user-agents
> which all bots of a given kind MUST respect (in addition to optionally
> having their own individual user-agent). A very rough sketch of some
> possibilities, not meant to be exhaustive or even very good, just to
> give the flavour:

I think this is probably the right approach, since it doesn't require
adding user-agents to the protocol.

> * A user-agent of "webproxy" which must be respected by all web
> proxies. Possibly this could have sub-types for proxies which do and
> don't forbid web search engines?

webproxy-bot and webproxy-nobot, perhaps.

> * A user-agent of "search" which must be respected by all search
> engine spiders

> * A user-agent of "research" for bots which crawl a site without
> making specific results of their crawl publically available (I've
> thought of writing something like this to study the growth of
> Geminispace and the structure of links between documents)

Another type I can think of is "archive", for things that rehost
existing gemini content elsewhere on gemini. Besides being another use
case, this category also has the implication that it may make deleted
content available (a la the Wayback Machine).

--
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

From solderpunk at SDF.ORG  Tue Mar 24 19:54:04 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 24 Mar 2020 19:54:04 +0000
Subject: robots.txt for Gemini
In-Reply-To: <tNXt7WjS-5AlS6TEThMbkVE9yb3GEwQLaVgorbKIa9l2Z1OegK3tX7PwFlw7HLJ5i7nWPieiCACrWKFKGgdLwYdwwihvWTTA-i0BBN7yCsQ=@protonmail.com>
References: <20200322181333.GB26849@SDF.ORG>
 <tNXt7WjS-5AlS6TEThMbkVE9yb3GEwQLaVgorbKIa9l2Z1OegK3tX7PwFlw7HLJ5i7nWPieiCACrWKFKGgdLwYdwwihvWTTA-i0BBN7yCsQ=@protonmail.com>
Message-ID: <20200324195404.GA7041@SDF.ORG>

On Sun, Mar 22, 2020 at 10:39:05PM +0000, Krixano wrote:
> You can go to literally any website and append "/robots.txt" to see what they use. I've already seen a couple that use "Allow".

Thanks for that. I've also verified that Python's stdlib function for
parsing robots.txt recognises "Allow", so it seems that this is not as
obscure an option as some sources suggest.  I'd say we may as well
explicitly support this for Gemini.

Cheers,
Solderpunk


> 
> Christian Seibold
> 
> Sent with ProtonMail Secure Email.
> 
> ??????? Original Message ???????
> On Sunday, March 22, 2020 1:13 PM, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> > Howdy all,
> >
> > As the first and perhaps most important push toward getting some clear
> > guidelines in place for well-behaved non-human Gemini clients (e.g.
> > Gemini to web proxies, search engine spiders, feed aggregators, etc.),
> > let's get to work on adapting robots.txt to Gemini.
> >
> > My current thinking is that this doesn't belong in the Gemini spec
> > itself, much like robots.txt does not belong in the HTTP spec. That
> > said, this feels like it warrants something more than just being put in
> > the Best Practices doc. Maybe we need to start working on official
> > "side specs", too. Not sure what these should be called.
> >
> > Anyway, I've refamiliarised myself with robots.txt. Turns out it is
> > still only a de facto standard without an official RFC. My
> > understanding is based on:
> >
> > -   The https://www.robotstxt.org/ website (which Wikipedia calls the
> >     "Official website" at
> >     https://en.wikipedia.org/wiki/Robots_exclusion_standard - it's not
> >     clear to me what "official" means for a de facto standard), and in
> >     particular:
> >
> > -   An old draft RFC from 1996 which that site hosts at
> >     https://www.robotstxt.org/norobots-rfc.txt
> >
> > -   A new draft RFC from 2019 which appears to have gotten further than
> >     the first, considering it is hosted by the IETF at
> >     https://tools.ietf.org/html/draft-rep-wg-topic-00
> >
> >     While the 1996 draft is web-specific, I was pleasantly surprised to
> >     see that the 2019 version is not. Section 2.3 says:
> >
> >
> > > As per RFC3986 [1], the URI of the robots.txt is:
> > > "scheme:[//authority]/robots.txt"
> > > For example, in the context of HTTP or FTP, the URI is:
> > > http://www.example.com/robots.txt
> > > https://www.example.com/robots.txt
> > > ftp://ftp.example.com/robots.txt
> >
> > So, why not Gemini too?
> >
> > Regarding the first practical question which was raised by Sean's recent
> > post, it seems a no-brainer to me that Gemini should retain the
> > convention of there being a single /robots.txt URL rather than having
> > them per-directory or anything like that. Which it now seems was the
> > intended behaviour of GUS all along, so I'm guessing nobody will find
> > this controversial (but speak up if you do).
> >
> > https://www.robotstxt.org/robotstxt.html claims that excluding all files
> > except one from robot access is "currently a bit awkward, as there is no
> > "Allow" field". However, both the old and new RFC drafts clearly
> > mention one. I am not sure exactly what the ground truth is here, in
> > terms of how often Allow is used in the wild or to what extent it is
> > obeyed even by well-intentiond bots. I would be very happy in principle
> > to just declare that Allow lines are valid for Gemini robot.txt files,
> > but if it turns out that popular programming languages have standard
> > library tools for parsing robot.txt which don't choke on gemini:// URLs
> > but don't recognise "Allow", this could quickly lead to unintended
> > consequences, so perhaps it is best to be conservative here.
> >
> > If anybody happens to be familiar with current practice on the web with
> > regard to Allow, please chime in.
> >
> > There is the question of caching. Both RFC drafts for robots.txt make
> > it clear that standard HTTP caching mechanisms apply to robots.txt, but
> > Gemini doesn't have an equivalent and I'm not interested in adding one
> > yet, especially not for the purposes of robots.txt. And yet, obviously,
> > some caching needs to take place. A spider requesting /robots.txt
> > again and again for every document at a host is generating a lot of
> > needless traffic. The 1996 RFC recommends "If no cache-control
> > directives are present robots should default to an expiry of 7 days",
> > while the 2019 one says "Crawlers SHOULD NOT use the cached version for
> > more than 24 hours, unless the robots.txt is unreachable". My gut tells
> > me most Gemini robots.txt files will change very infrequently and 7 days
> > is more appropriate than 24 hours, but I'm happy for us to discuss this.
> >
> > The biggest question, in my mind, is what to do about user-agents, which
> > Gemini lacks (by design, as they are a component of the browser
> > fingerprinting problem, and because they encourage content developers to
> > serve browser-specific content which is a bad thing IMHO). The 2019 RFC
> > says "The product token SHOULD be part of the identification string that
> > the crawler sends to the service" (where "product token" is bizarre and
> > disappointingly commercial alternative terminology for "user-agent" in
> > this document), so the fact that Gemini doesn't send one is not
> > technically a violation.
> >
> > Of course, a robot doesn't need to send its user-agent in order to
> > know its user-agent and interpet robots.txt accordingly. But it's
> > much harder for Gemini server admins than their web counterparts to know
> > exactly which bot is engaging in undesired behaviour and how to address
> > it. Currently, the only thing that seems achievable in Gemini is to use
> > the wildcard user-agent "*" to allow/disallow access by all bots to
> > particular resources.
> >
> > But not all bots are equal. I'm willing to bet there are people using
> > Gemini who are perfectly happy with e.g. the GUS search engine spider
> > crawling their site to make it searchable via a service which is offered
> > exclusively within Geminispace, but who are not happy with Gemini to web
> > proxies accessing their content because they are concerned that
> > poorly-written proxies will not disallow Google from crawling them so
> > that Gemini content ends up being searchable within webspace. This is a
> > perfectly reasonable stance to take and I think we should try to
> > facilitate it.
> >
> > With no Gemini-specific changes to the de facto robots.txt spec, this
> > would require admins to either manually maintain a whitelist of
> > Gemini-only search engine spiders in their robots.txt or a blacklist
> > of web proxies. This is easy today when you can count the number of
> > either of things on one hand, but it does not scale well and is not a
> > reasonable thing to expect admins to do in order to enforce a reasonable
> > stance.
> >
> > (and, really, this isn't a Gemini-specific problem and I'm surprised
> > that what I'm about to propose isn't a thing for the web)
> >
> > I have mentioned previously on this list (quickly, in passing), the idea
> > of "meta user-agents" (I didn't use that term when I first mentioned
> > it). But since there is no way for Gemini server admins to learn the
> > user-agent of arbitrary bots, we could define a small (I'm thinking ~5
> > would suffice, surely 10 at most) number of pre-defined user-agents
> > which all bots of a given kind MUST respect (in addition to optionally
> > having their own individual user-agent). A very rough sketch of some
> > possibilities, not meant to be exhaustive or even very good, just to
> > give the flavour:
> >
> > -   A user-agent of "webproxy" which must be respected by all web proxies.
> >     Possibly this could have sub-types for proxies which do and don't
> >     forbid web search engines?
> >
> > -   A user-agent of "search" which must be respected by all search engine
> >     spiders
> >
> > -   A user-agent of "research" for bots which crawl a site without making
> >     specific results of their crawl publically available (I've thought of
> >     writing something like this to study the growth of Geminispace and the
> >     structure of links between documents)
> >
> >     Enumerating actual use cases is probably the wrong way to go about it,
> >     rather we should think of broad classes of behaviour which differ with
> >     regard to privacy implications - e.g. bots which don't make the results
> >     of their crawling public, bots which make their results public over
> >     Gemini only, bots which breach the Gemini-web barrier, etc.
> >
> >     Do people think this is a good idea?
> >
> >     Can anybody think of other things to consider in adapting robots.txt to
> >     Gemini?
> >
> >     Cheers,
> >     Solderpunk
> >
> 
> 
> 

From solderpunk at SDF.ORG  Tue Mar 24 19:57:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 24 Mar 2020 19:57:03 +0000
Subject: Announcing `spacewalk`
In-Reply-To: <1276766723.224624.1584939887478@ichabod.co-bxl>
References: <1276766723.224624.1584939887478@ichabod.co-bxl>
Message-ID: <20200324195703.GB7041@SDF.ORG>

On Mon, Mar 23, 2020 at 06:04:47AM +0100, Brian Evans wrote:
> Greetings all!
> 
> I too have been working on getting some aggregation tools together for gemini.
> I have written this: https://tildegit.org/sloum/spacewalk

Wonderful!  I've added it to the official software list.
 
> I know there is also still the problem of content on gemini that does not involve
> talking about gemini itself. To that end I have put up some content on my
> circumlunar geminispace:
> 
> gemini://gemini.circumlunar.space:1965/~sloum/

Also wonderful!  Geminispace is turning out to be a surprisingly musical
place!  Thanks for your contribution.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Mar 24 20:00:52 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 24 Mar 2020 20:00:52 +0000
Subject: robots.txt for Gemini
In-Reply-To: <87blol9ax2.fsf@dorothy.carcosa.net>
References: <20200322181333.GB26849@SDF.ORG>
 <87blol9ax2.fsf@dorothy.carcosa.net>
Message-ID: <20200324200052.GC7041@SDF.ORG>

On Tue, Mar 24, 2020 at 08:47:53AM -0400, Jason McBrayer wrote:
 
> Another type I can think of is "archive", for things that rehost
> existing gemini content elsewhere on gemini. Besides being another use
> case, this category also has the implication that it may make deleted
> content available (a la the Wayback Machine).

Yes, certainly!  This is actually quite an important use case.  Many
folks are unhappy that archive.org no longer respects robots.txt, while
on the other hand the archive.org folks argue that people were writing
robots.txt rules based on how they wanted search engine robots ot act
rather than considering archive bots.  Making it easy for Gemini server
admins to explicitly set different policies for the two kinds of bots
(if they want to!) seems a substantial improvement.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Mar 24 20:17:11 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 24 Mar 2020 20:17:11 +0000
Subject: Rate limiting
Message-ID: <20200324201711.GD7041@SDF.ORG>

Howdy all,

As part of the broader discussion of "Good Gemini citizenship" I wanted
to bring up the issue of rate limiting.

The Gemini protocol features a mechanism by which servers can explicitly
tell robots "slow down, you are requesting things too fast!".  To my
knowledge (but I could be wrong) no servers have actually implemented
support for this yet.

Obviously exactly when this mechanism should kick in can be something
determined by individual server authors (who can decide defaults) and/or
server admins (who can override those defaults).  But what do we think
sane ballpark defaults may be?

This applies not only to server authors but also authors of bots.  Okay,
in principle a bot can start hitting a server as fast as possible
immediately and wait for the server to say "stop", but that's rude.  It
would be nice to have a guideline in place, which could be mentioned in
the Best Practices, for what is considered reasonable.

Current CAPCOM won't send consecutive requests to a single host with
less than 5 seconds between them.  That's probably gentler than
necessary, but I don't really mind, it runs once per six hours and is in
no rush.

What seems reasonable?

Cheers,
Solderpunk


From sean at conman.org  Tue Mar 24 21:35:08 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 24 Mar 2020 17:35:08 -0400
Subject: robots.txt for Gemini
In-Reply-To: <20200322181333.GB26849@SDF.ORG>
References: <20200322181333.GB26849@SDF.ORG>
Message-ID: <20200324213508.GD22036@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> The biggest question, in my mind, is what to do about user-agents, which
> Gemini lacks (by design, as they are a component of the browser
> fingerprinting problem, and because they encourage content developers to
> serve browser-specific content which is a bad thing IMHO).  The 2019 RFC
> says "The product token SHOULD be part of the identification string that
> the crawler sends to the service" (where "product token" is bizarre and
> disappointingly commercial alternative terminology for "user-agent" in
> this document), so the fact that Gemini doesn't send one is not
> technically a violation.

  Two possible solutions for robot identification:

1) Allow IP addresses to be used where a user-agent would be specificifed. 
Some examples:

	User-agent: 172.16.89.3
	User-agent: 172.17.24.0/27
	User-agent: fde7:a680:47d3/48

Yes, I'm including CIDR (Classless Inter-Domain Routing) notation to specify
a range of IP addresses.  And for a robot, if your IP addresss matches an IP
address (or range), then you need to follow the following rules.

2) Use the fragment portion of a URL to designate a robot.  The fragment
portion of a URL has no meaning for a server (it does for a client).  A
robot could use this fact to skip it its identifier when making a request. 
The server MUST NOT use this information, but the logs could show it.  For
example, a robot could request:

	gemini://example.com/robots.txt#GUS

A review of the logs would reveal that GUS is a robot, and the text "GUS"
could be placed in the User-agent: field to control it.  It SHOULD be the
text the robot would recognize in robots.txt.  One clarification, this:

	gemini://example.com/robots.txt#foo%20bot

would be 

	User-agent: foo bot

but a robot ID SHOULD NOT contain spaces---it SHOULD be one word.

  Anyway, that's my ideas.

  -spc


From solderpunk at SDF.ORG  Thu Mar 26 19:57:17 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 26 Mar 2020 19:57:17 +0000
Subject: robots.txt for Gemini
In-Reply-To: <20200324213508.GD22036@brevard.conman.org>
References: <20200322181333.GB26849@SDF.ORG>
 <20200324213508.GD22036@brevard.conman.org>
Message-ID: <20200326195717.GA499@SDF.ORG>

On Tue, Mar 24, 2020 at 05:35:08PM -0400, Sean Conner wrote:
 
>   Two possible solutions for robot identification:
> 
> 1) Allow IP addresses to be used where a user-agent would be specificifed. 
> Some examples:
> 
> 	User-agent: 172.16.89.3
> 	User-agent: 172.17.24.0/27
> 	User-agent: fde7:a680:47d3/48
> 
> Yes, I'm including CIDR (Classless Inter-Domain Routing) notation to specify
> a range of IP addresses.  And for a robot, if your IP addresss matches an IP
> address (or range), then you need to follow the following rules.

Hmm, I'm not a huge fan of this idea (although I recognise it as a valid
technical solution to the problem at hand, which is perhaps all you
meant it to be).  Mostly because I don't like to encourage people to
think of IP addresses as permanently mapping to, well, just anything.
The address of a VPN running an abusive bot today might be handed out to
a different customer running a well-behaved bot next year.
 
> 2) Use the fragment portion of a URL to designate a robot.  The fragment
> portion of a URL has no meaning for a server (it does for a client).  A
> robot could use this fact to skip it its identifier when making a request. 
> The server MUST NOT use this information, but the logs could show it.  For
> example, a robot could request:
> 
> 	gemini://example.com/robots.txt#GUS
> 
> A review of the logs would reveal that GUS is a robot, and the text "GUS"
> could be placed in the User-agent: field to control it.  It SHOULD be the
> text the robot would recognize in robots.txt.

Hmm, nice out-of-the-box thinking.  Since the suggestion has come from
you I will assume it does not violate the letter of any RFCs, even
though I can't shake a strange feeling that this is "abusing" the
fragment concept a little...

Cheers,
Solderpunk

From sean at conman.org  Thu Mar 26 21:07:28 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 26 Mar 2020 17:07:28 -0400
Subject: robots.txt for Gemini
In-Reply-To: <20200326195717.GA499@SDF.ORG>
References: <20200322181333.GB26849@SDF.ORG>
 <20200324213508.GD22036@brevard.conman.org> <20200326195717.GA499@SDF.ORG>
Message-ID: <20200326210728.GE22036@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Tue, Mar 24, 2020 at 05:35:08PM -0400, Sean Conner wrote:
>  
> >   Two possible solutions for robot identification:
> > 
> > 1) Allow IP addresses to be used where a user-agent would be specificifed. 
> > Some examples:
> > 
> > 	User-agent: 172.16.89.3
> > 	User-agent: 172.17.24.0/27
> > 	User-agent: fde7:a680:47d3/48
> > 
> > Yes, I'm including CIDR (Classless Inter-Domain Routing) notation to specify
> > a range of IP addresses.  And for a robot, if your IP addresss matches an IP
> > address (or range), then you need to follow the following rules.
> 
> Hmm, I'm not a huge fan of this idea (although I recognise it as a valid
> technical solution to the problem at hand, which is perhaps all you
> meant it to be). 

  Pretty much.  

> Mostly because I don't like to encourage people to
> think of IP addresses as permanently mapping to, well, just anything.
> The address of a VPN running an abusive bot today might be handed out to
> a different customer running a well-behaved bot next year.

  Fair enough.  I'm just throwing out ideas here.

> > 2) Use the fragment portion of a URL to designate a robot.  The fragment
> > portion of a URL has no meaning for a server (it does for a client).  A
> > robot could use this fact to skip it its identifier when making a request. 
> > The server MUST NOT use this information, but the logs could show it.  For
> > example, a robot could request:
> > 
> > 	gemini://example.com/robots.txt#GUS
> > 
> > A review of the logs would reveal that GUS is a robot, and the text "GUS"
> > could be placed in the User-agent: field to control it.  It SHOULD be the
> > text the robot would recognize in robots.txt.
> 
> Hmm, nice out-of-the-box thinking.  Since the suggestion has come from
> you I will assume it does not violate the letter of any RFCs, even
> though I can't shake a strange feeling that this is "abusing" the
> fragment concept a little...

  Well ... it's skating right up to the line, and may be going over it a
bit.  RFC-3986 says this about fragments:

	The fragment identifier component of a URI allows indirect
	identification of a secondary resource by reference to a primary
	resource and additional identifying information.  The identified
	secondary resource may be some portion or subset of the primary
	resource, some view on representations of the primary resource, or
	some other resource defined or described by those representations.

... and so on.  An argument could be made that a request like:

	gemini://example.com/robots.txt#Foobot

could apply, as it is "referencing" the "Foobot" section of robots.txt, but
such a claim would only be applicable to /robots.txt and not other resources
on the server.  Perhaps this could be just limited to references to
/robots.txt?

  So yes, on the line here.  And yes, it's "abusing" the fragment concept a
little ... but other than these two methods, how else would one identify a
robot on Gemini?

  -spc

From julien at typed-hole.org  Sun Apr 19 16:05:54 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sun, 19 Apr 2020 17:05:54 +0200
Subject: IRC channel
In-Reply-To: <20200302120738.GB335198@goldfish.localdomain>
References: <20200225194356.GA16266@SDF.ORG>
 <d4845fca-d9bf-4f79-98ff-74d36b9948c3@NorthTech.US>
 <20200302120738.GB335198@goldfish.localdomain>
Message-ID: <a49fd66e-dcf9-9c37-bd67-4d8d32e3d2e4@typed-hole.org>

Hello,

Not sure it has already been mentioned here, there is an unofficial 
#gemini IRC channel on tilde.chat if you're in the mood for chat.


From benulo at systemli.org  Sun Apr 19 17:31:03 2020
From: benulo at systemli.org (Ben)
Date: Sun, 19 Apr 2020 21:01:03 +0430
Subject: IRC channel
In-Reply-To: <a49fd66e-dcf9-9c37-bd67-4d8d32e3d2e4@typed-hole.org>
References: <20200225194356.GA16266@SDF.ORG>
 <d4845fca-d9bf-4f79-98ff-74d36b9948c3@NorthTech.US>
 <20200302120738.GB335198@goldfish.localdomain>
 <a49fd66e-dcf9-9c37-bd67-4d8d32e3d2e4@typed-hole.org>
Message-ID: <128136be-eac1-3e96-4aa8-26e831d55393@systemli.org>

Not XMPP!?


From julien at typed-hole.org  Sun Apr 19 20:01:53 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sun, 19 Apr 2020 21:01:53 +0200
Subject: IRC
Message-ID: <D4FADFD2-3959-47E5-801A-00FA48AD9163@typed-hole.org>


(Reposting at the root level because apparently I don?t know how to use a mailing list :D)

Hello,

Not sure it has already been mentioned here, there is an unofficial 
#gemini IRC channel on tilde.chat if you're in the mood for chat.

From julien at typed-hole.org  Sun Apr 19 22:25:19 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sun, 19 Apr 2020 23:25:19 +0200
Subject: Client certificates
Message-ID: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>

Hello Geminauts,
When trying to implement client certificate support in my client I 
wondered whether or not we would want to be able to use different 
certificates for different gemini places?
I figured why not so started I my implementation by searching for a 
certificate that matches the host domain name like 
astrobotany.mozz.us.key and astrobotany.mozz.us.crt.
Does it make sense? Where should one put its certificates if such a 
place exists in a filesystem?


From ciprian.craciun at gmail.com  Mon Apr 20 14:02:00 2020
From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun)
Date: Mon, 20 Apr 2020 16:02:00 +0300
Subject: Client certificates
In-Reply-To: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>
References: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>
Message-ID: <CA+Tk8fwFw4tyT1-v5A8S1M53x_A+KqfDzWM7YhBaEb95N9qKrA@mail.gmail.com>

[Disclaimer:  I'm not directly involved in Gemini development or
ecosystem, but I follow closely these developments.]


On Mon, Apr 20, 2020 at 12:23 AM Julien Blanchard <julien at typed-hole.org> wrote:
> When trying to implement client certificate support in my client I
> wondered whether or not we would want to be able to use different
> certificates for different gemini places?

I would definitively want to have different "personas" for different
sites.  In fact even for the same site I would like to have different
ones, for example:  one for administrative purposes, and one for
normal (but authenticated) access.



> I figured why not so started I my implementation by searching for a
> certificate that matches the host domain name like
> astrobotany.mozz.us.key and astrobotany.mozz.us.crt.
> Does it make sense? Where should one put its certificates if such a
> place exists in a filesystem?


Automatically choosing a client certificate and presenting it to the
server, I believe is a bad idea from a privacy perspective.  I would
implement something like this:  when connecting to a domain for which
one could use a client certificate, ask the user the first time if he
wants to:
* always use the same certificate for that particular domain;
* wants to use a particular certificate (assuming there are multiple),
but prefers to confirm it for each new "tab" (or browsing context);
(i.e. sort of "last-used" but "confirm";)
* never use any certificate;

Ciprian.

From solderpunk at SDF.ORG  Mon Apr 20 19:19:56 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 20 Apr 2020 18:19:56 +0000
Subject: Client certificates
In-Reply-To: <CA+Tk8fwFw4tyT1-v5A8S1M53x_A+KqfDzWM7YhBaEb95N9qKrA@mail.gmail.com>
References: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>
 <CA+Tk8fwFw4tyT1-v5A8S1M53x_A+KqfDzWM7YhBaEb95N9qKrA@mail.gmail.com>
Message-ID: <20200420181956.GA22501@SDF.ORG>

On Mon, Apr 20, 2020 at 04:02:00PM +0300, Ciprian Dorin Craciun wrote:
 
> On Mon, Apr 20, 2020 at 12:23 AM Julien Blanchard <julien at typed-hole.org> wrote:
> > When trying to implement client certificate support in my client I
> > wondered whether or not we would want to be able to use different
> > certificates for different gemini places?
> 
> I would definitively want to have different "personas" for different
> sites.  In fact even for the same site I would like to have different
> ones, for example:  one for administrative purposes, and one for
> normal (but authenticated) access.

Yes, absolutely the idea is that different certificates would be used to
identify the client to different servers.  A universal client
certificate would allow server admins to compare logs and track users.

Possibly this question was provoked by the way the (wonderful!)
astrobotany app advices people to use client certs with AV-98, where you
provide a cert path when starting AV-98 and it's used for everything.  I
should clarify that this way of handling client certs was added to AV-98
as a kind of quick-and-dirty way to get the astrobotany app usable.
It's not supposed to be the standard way of using client certificates.

> > I figured why not so started I my implementation by searching for a
> > certificate that matches the host domain name like
> > astrobotany.mozz.us.key and astrobotany.mozz.us.crt.
> > Does it make sense? Where should one put its certificates if such a
> > place exists in a filesystem?

Transient certificates are explicitly bound to a domain in the spec.
Nothing is said about non-transient certificates, but I guess it makes
sense that they would work similarly.  The META part of response headers
with status 6x have no explicit semantics yet - it's possible we could
implement a syntax for binding certificates to subdomains?  Or even
paths?

I should remind myself how this works for cookies...
 
> Automatically choosing a client certificate and presenting it to the
> server, I believe is a bad idea from a privacy perspective.  I would
> implement something like this:  when connecting to a domain for which
> one could use a client certificate, ask the user the first time if he
> wants to:
> * always use the same certificate for that particular domain;
> * wants to use a particular certificate (assuming there are multiple),
> but prefers to confirm it for each new "tab" (or browsing context);
> (i.e. sort of "last-used" but "confirm";)
> * never use any certificate;

Bugging the user about certs upon each connection to a new domain would
be a pretty unpleasant user experience!  I would expect clients not to
use client certificates by default and not to ask the user about client
certificates until receieving a response with a status of 60, 61 or 62.

When a user opts to generate a new non-transient certificate to send to
a site, I guess it would be handy if the client offered a "Remember me"
option, such that the same certificate would then automatically be used
for all connections to that domain (which would involve saving the key
and certificate to disk, presumably in some client-specific location).
This way one could automatically and invisibly log in to places like
astrobotany on each visit.  One of course could reverse this decision at
any time.

While we're talking details on client certificates - I never envisaged
client certificates being signed by the server they're destined for.
This does no harm, but it also does no good, either, if the server signs
them without any kind of validation process.  In general I don't see a
need for it and it just adds a lot of friction to the "signup process".
But, I'm aware that lots of TLS libraries are very inflexible when it
comes to certificate validation, and accepting self-signed client
certificates may not be possible - I wouldn't be surprised if this was
the cause for astrobotany, since Python's standard library is precisely
one of these inflexible ones...

Cheers,
Solderpunk

From lazar.michael22 at gmail.com  Mon Apr 20 23:02:32 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Mon, 20 Apr 2020 18:02:32 -0400
Subject: Client certificates
In-Reply-To: <20200420181956.GA22501@SDF.ORG>
References: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>
 <CA+Tk8fwFw4tyT1-v5A8S1M53x_A+KqfDzWM7YhBaEb95N9qKrA@mail.gmail.com>
 <20200420181956.GA22501@SDF.ORG>
Message-ID: <CAFTy05YkLHe63BO7JA-_nSL23WRxTkQxYdwt99AOSPJQMQZsYw@mail.gmail.com>

On Mon, Apr 20, 2020 at 2:20 PM solderpunk <solderpunk at sdf.org> wrote:
> While we're talking details on client certificates - I never envisaged
> client certificates being signed by the server they're destined for.
> This does no harm, but it also does no good, either, if the server signs
> them without any kind of validation process. In general I don't see a
> need for it and it just adds a lot of friction to the "signup process".
> But, I'm aware that lots of TLS libraries are very inflexible when it
> comes to certificate validation, and accepting self-signed client
> certificates may not be possible - I wouldn't be surprised if this was
> the cause for astrobotany, since Python's standard library is precisely
>one of these inflexible ones...

To be honest, I never even considered doing it that way. Assuming I have
access to a half-decent TLS library, does this flow make sense for self-signed
client certificates?

- The client requests "gemini://astrobotany.mozz.us/" and receives a
  "62 AUTHORISED CERTIFICATE REQUIRED" response.
- The client generates a self-signed certificate and makes a second request to
  the same endpoint. This certificate generation could be done through the
  gemini client software itself, or the user could provide their own cert.
- The server accepts the self-signed client certificate and saves a hashed
  fingerprint of the peer cert. This fingerprint is now associated with that
  user and represents a unique UUID that nobody else can spoof.
- We kick the can down the road concerning the user needing to update or
  re-associate their client certificate. We hope that they set an expiration
  date far enough in the future for this to never matter.

Are there any flaws that I'm not seeing here? I actually like this a lot more
than the current solution now that I look at it.

- Michael

From solderpunk at SDF.ORG  Tue Apr 21 08:51:50 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 21 Apr 2020 07:51:50 +0000
Subject: Client certificates
In-Reply-To: <CAFTy05YkLHe63BO7JA-_nSL23WRxTkQxYdwt99AOSPJQMQZsYw@mail.gmail.com>
References: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>
 <CA+Tk8fwFw4tyT1-v5A8S1M53x_A+KqfDzWM7YhBaEb95N9qKrA@mail.gmail.com>
 <20200420181956.GA22501@SDF.ORG>
 <CAFTy05YkLHe63BO7JA-_nSL23WRxTkQxYdwt99AOSPJQMQZsYw@mail.gmail.com>
Message-ID: <20200421075150.GA3163@SDF.ORG>

On Mon, Apr 20, 2020 at 06:02:32PM -0400, Michael Lazar wrote:
 
> - The client requests "gemini://astrobotany.mozz.us/" and receives a
>   "62 AUTHORISED CERTIFICATE REQUIRED" response.
> - The client generates a self-signed certificate and makes a second request to
>   the same endpoint. This certificate generation could be done through the
>   gemini client software itself, or the user could provide their own cert.
> - The server accepts the self-signed client certificate and saves a hashed
>   fingerprint of the peer cert. This fingerprint is now associated with that
>   user and represents a unique UUID that nobody else can spoof.
> - We kick the can down the road concerning the user needing to update or
>   re-associate their client certificate. We hope that they set an expiration
>   date far enough in the future for this to never matter.

Yes, this is more or less precisely as I imagined it working!

With "nice" clients, the user basically gets a prompt like "Would you
like to create a persistent identity for this service? Y/N", and if Y,
the client itself generates and saves a self-signed certificate to use
without the user having to drop to the commandline and use openssl
commands.  The cert is associated with a particular domain and, if the
client is set up to do so, can be used automatically for all requests
to that domain.  This gives a pretty fluid user experience: the user
doesn't need to understand anything technical about TLS at all.  They
just get a transparently working account which is basically bound to
the device/client they used at sign up (advanced users of course can
export/import cert-key pairs to multiple devices).  No passwords to
forget, or to be brute-forced.  Even a full compromise of the server's
database does not allow account hijacking, even with all the rainbow
tables and time in the world, because the private key never leaves the
client.  Of course, good backups of the cert-key pairs becomes
essential to avoid getting locked out of things after a disk
failure...

You raise good points about cert expiry.  Let's think about that.

Cheers,
Solderpunk

From sean at conman.org  Sat May  2 04:03:46 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 1 May 2020 23:03:46 -0400
Subject: Gemini mentioned on Hacker News and Lobsters
Message-ID: <20200502030345.GB7305@brevard.conman.org>


  I found the following page on Hacker News:

	https://news.ycombinator.com/item?id=23042424

and on Lobsters:

	https://lobste.rs/s/79pu7o/gemini_protocol_inbetween_gopher_web

  Just thought it might be of interest to some people here.

  -spc


From julien at typed-hole.org  Sat May  2 13:57:52 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 2 May 2020 14:57:52 +0200
Subject: Gemini mentioned on Hacker News and Lobsters
In-Reply-To: <20200502030345.GB7305@brevard.conman.org>
References: <20200502030345.GB7305@brevard.conman.org>
Message-ID: <c8cc7ebf-59b3-7b6f-dec6-d1e108c8fb3e@typed-hole.org>

That's funny, I also found out that Castor was in Sourcehut featured 
projects https://sr.ht/projects?search=gemini&sort=recently-updated, 
looks like someone is making another server too. Gemini everywhere!

On 5/2/20 5:03 AM, Sean Conner wrote:
>    I found the following page on Hacker News:
>
> 	https://news.ycombinator.com/item?id=23042424
>
> and on Lobsters:
>
> 	https://lobste.rs/s/79pu7o/gemini_protocol_inbetween_gopher_web
>
>    Just thought it might be of interest to some people here.
>
>    -spc

From charles at thorley.us  Sat May  2 23:50:32 2020
From: charles at thorley.us (Charles Thorley)
Date: Sat, 02 May 2020 15:50:32 -0700
Subject: Introduction and an offering
Message-ID: <6cd448f3-e2de-4e0e-9fd4-70bf130d15a6@www.fastmail.com>

Hello,

I saw the front page item on Hacker News yesterday and was immediately intrigued by this project, and as I investigated a little, the community around it (which I had no idea existed).  Having sent yesterday evening and this morning reading and exploring, I'm finding myself really excited to get involved and learn more.

To facilitate the learning side of things, I put together a Molly Brown container this afternoon, and thought that other folks might find it useful for learning and experimentation:

https://sr.ht/~cthorley/molly-docker/

In its current form, this container is pretty narrowly targeted at local deployment.  However, I'm planning on expanding its scope to support non-local deployment targets, and will prioritize this work if there appears to be interest from the community.

Thanks to everyone who has invested time in this ecosystem so far.

Best regards,

Charles

From solderpunk at SDF.ORG  Sun May  3 10:22:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 3 May 2020 09:22:37 +0000
Subject: Introduction and an offering
In-Reply-To: <6cd448f3-e2de-4e0e-9fd4-70bf130d15a6@www.fastmail.com>
References: <6cd448f3-e2de-4e0e-9fd4-70bf130d15a6@www.fastmail.com>
Message-ID: <20200503092237.GB12399@SDF.ORG>

Hi Charles,

Welcome to the community!  I am glad that reading about Gemini sparked
your interest.

I have to admit, I was very apprehensive about learning that Gemini had
featured at HN.  In part simply because I feared too many people turning
up at once and this small, slow, "human scale" project being
overwhelmed.  Also, in part, because of a perceived cultural mismatch.
But so far actually I am very happy to see that the majority of the
response has been positive or at least constructive.  It's good to have
more people around!

Please don't take this the wrong way, but my hope is that once I've had
the time to put a bit more work into Molly-Brown, building a container
for it will be something very obviously not worth the time and trouble
required!  Containers make sense for complicated software with large and
fragile dependency networks, which is exactly the kind of thing Gemini
software should *not* be!  But I absolutely grant that in its current
just-barely-running state, where it doesn't daemonise itself and isn't
integrated with any init systems, and you have to manually create the
key/cert pair, there's enough of a barrier to entry that casually
interested people might be turned away.  If a container gets more people
setting up Gemini servers, that's only a good thing.

Cheers,
Solderpunk

On Sat, May 02, 2020 at 03:50:32PM -0700, Charles Thorley wrote:
> Hello,
> 
> I saw the front page item on Hacker News yesterday and was immediately intrigued by this project, and as I investigated a little, the community around it (which I had no idea existed).  Having sent yesterday evening and this morning reading and exploring, I'm finding myself really excited to get involved and learn more.
> 
> To facilitate the learning side of things, I put together a Molly Brown container this afternoon, and thought that other folks might find it useful for learning and experimentation:
> 
> https://sr.ht/~cthorley/molly-docker/
> 
> In its current form, this container is pretty narrowly targeted at local deployment.  However, I'm planning on expanding its scope to support non-local deployment targets, and will prioritize this work if there appears to be interest from the community.
> 
> Thanks to everyone who has invested time in this ecosystem so far.
> 
> Best regards,
> 
> Charles

From colecmac at protonmail.com  Mon May  4 17:22:17 2020
From: colecmac at protonmail.com (Cole Anthony Capilongo)
Date: Mon, 04 May 2020 16:22:17 +0000
Subject: [ANN] gemget, a gemini downloader
Message-ID: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>

Hello Geminauts!

I found out about Gemini through the recent Hacker News post, and I
couldn't resist exploring and making something for it.

I'm using both Castor and Bombadillo for browsing Gemini, and neither
of them really did what I wanted in terms of downloading. There's no
indication of progress, so it feels a bit like the client has frozen
up, until I see the file saved, or some application open.

For that and other reasons, I decided to create a command line
downloader for Gemini, similar to wget but much simpler at the moment.
It's available at https://github.com/makeworld-the-better-one/gemget/
and is written in Go, with binaries available.

I'm somewhat new to Go and Gemini, so I'd appreciate any suggestions
or bug reports a lot.

Happy hacking!

makeworld

From colecmac at protonmail.com  Tue May  5 00:47:56 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 04 May 2020 23:47:56 +0000
Subject: GUS questions
Message-ID: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>

Hello all,

I just have some quick questions about GUS that I figured the whole list
could benefit from.

Is there source code available anywhere? I'd love to read it and learn,
or even host my own instance.

The other thing I'm wondering is how to get to other pages. When I search
something, GUS mentions "Page 1 of X" at the bottom, but there doesn't seem
to be any way to get to the other page.

makeworld

From natpen at natpen.net  Tue May  5 13:51:13 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Tue, 5 May 2020 08:51:13 -0400
Subject: GUS questions
In-Reply-To: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
References: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
Message-ID: <20200505125113.GA148355@goldfish.localdomain>

Hi!

The source code for GUS is available here [1]. I wouldn't consider it
"batteries-included," so if you want to run it yourself it may be a
bit of an adventure! If you host an instance, note that we'll be
increasing the "crawl-load" on Geminispace non-trivially - this
actually motivated a commit this morning to add support for respecting
robots.txt's `crawl_delay` and also added a default per-domain 500ms
delay. Let's be kind with our crawls together :)

Paging is not implemented. I had been thinking about different ways to
implement it, but haven't really figured a solution I like yet. I
could just have it return all results I suppose, given the current
size of Geminispace, but I have slight misgivings about that approach
as well, since some queries can return hundreds of results. In the
meantime, I've simply left it unimplemented and hoped that the top ten
results would be sufficient for most usage.

[1] https://git.sr.ht/~natpen/gus

On Mon, May 04, 2020 at 11:47:56PM +0000, colecmac at protonmail.com wrote:
> Hello all,
>
> I just have some quick questions about GUS that I figured the whole list
> could benefit from.
>
> Is there source code available anywhere? I'd love to read it and learn,
> or even host my own instance.
>
> The other thing I'm wondering is how to get to other pages. When I search
> something, GUS mentions "Page 1 of X" at the bottom, but there doesn't seem
> to be any way to get to the other page.
>
> makeworld

From colecmac at protonmail.com  Tue May  5 16:45:04 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 05 May 2020 15:45:04 +0000
Subject: GUS questions
In-Reply-To: <20200505125113.GA148355@goldfish.localdomain>
References: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
 <20200505125113.GA148355@goldfish.localdomain>
Message-ID: <wik2s-Yf4ZWXP_J0a3ummQkA31NERuFqMuTWDVrSihxDA0BWGMLgvRCakUq_XgpA0ds-Mjm2CeD4m-E1vxIoEVuzWkNrQC9CZKMxDZo_dSI=@protonmail.com>

Hi, thanks for the reply!

Crawl-load is a good point, let's keep Gemini DDOS-free! I definitely
think that 500ms delay could be larger though, maybe 1-2 seconds?
I suppose it depends what kind of server is hosting the website.

Thanks for the code link, it's very cool! I might play around with it
later.

As for paging, what if it was part of the URL path? Like the initial
search link asks for a query, then leads you to
gemini://gus.guru/page/1?queryhere and then there's a link at the
bottom leading you to gemini://gus.guru/page/2?queryhere, etc. I
don't know if Jetforce can extract the page number for you, but if
not it would be easy to do.

makeworld


??????? Original Message ???????
On Tuesday, May 5, 2020 8:48 AM, Natalie Pendragon <natpen at natpen.net> wrote:

> Hi!
>
> The source code for GUS is available here [1]. I wouldn't consider it
> "batteries-included," so if you want to run it yourself it may be a
> bit of an adventure! If you host an instance, note that we'll be
> increasing the "crawl-load" on Geminispace non-trivially - this
> actually motivated a commit this morning to add support for respecting
> robots.txt's `crawl_delay` and also added a default per-domain 500ms
> delay. Let's be kind with our crawls together :)
>
> Paging is not implemented. I had been thinking about different ways to
> implement it, but haven't really figured a solution I like yet. I
> could just have it return all results I suppose, given the current
> size of Geminispace, but I have slight misgivings about that approach
> as well, since some queries can return hundreds of results. In the
> meantime, I've simply left it unimplemented and hoped that the top ten
> results would be sufficient for most usage.
>
> [1] https://git.sr.ht/~natpen/gus
>
> On Mon, May 04, 2020 at 11:47:56PM +0000, colecmac at protonmail.com wrote:
>
> > Hello all,
> > I just have some quick questions about GUS that I figured the whole list
> > could benefit from.
> > Is there source code available anywhere? I'd love to read it and learn,
> > or even host my own instance.
> > The other thing I'm wondering is how to get to other pages. When I search
> > something, GUS mentions "Page 1 of X" at the bottom, but there doesn't seem
> > to be any way to get to the other page.
> > makeworld



From solderpunk at SDF.ORG  Tue May  5 19:56:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 5 May 2020 18:56:16 +0000
Subject: [ANN] gemget, a gemini downloader
In-Reply-To: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>
References: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>
Message-ID: <20200505185616.GF19068@SDF.ORG>

Ahoy!

I'm really happy to see that somebody has written something like this,
it's something I've thought would be handy for a long time.  In my mind,
a program like this is an ideal solution to the usability problems
people have cited with rare things like downloading konpeito.media
releases using the more interactive clients.

I'd love to give this a spin, but it's not building for me - or rather,
the github.com/schollz/progressbar dependency isn't building.  Which is
probably just my "ancient" Debian stable version of Go...

Cheers,
Solderpunk

On Mon, May 04, 2020 at 04:22:17PM +0000, Cole Anthony Capilongo wrote:
> Hello Geminauts!
> 
> I found out about Gemini through the recent Hacker News post, and I
> couldn't resist exploring and making something for it.
> 
> I'm using both Castor and Bombadillo for browsing Gemini, and neither
> of them really did what I wanted in terms of downloading. There's no
> indication of progress, so it feels a bit like the client has frozen
> up, until I see the file saved, or some application open.
> 
> For that and other reasons, I decided to create a command line
> downloader for Gemini, similar to wget but much simpler at the moment.
> It's available at https://github.com/makeworld-the-better-one/gemget/
> and is written in Go, with binaries available.
> 
> I'm somewhat new to Go and Gemini, so I'd appreciate any suggestions
> or bug reports a lot.
> 
> Happy hacking!
> 
> makeworld
> 

From colecmac at protonmail.com  Tue May  5 20:50:24 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 05 May 2020 19:50:24 +0000
Subject: [ANN] gemget, a gemini downloader
In-Reply-To: <20200505185616.GF19068@SDF.ORG>
References: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>
 <20200505185616.GF19068@SDF.ORG>
Message-ID: <nP4cC1899IrIxCJqtqUs47vRKEZCKOTaRQkp96XSSiPIXVwfVCYRhg58pr08db0Bpoz9eD_GMdVfngPL6lnYBGHspg64PTnxVqDpMODH3RY=@protonmail.com>

Hello,

Glad to hear you like it! And downloading from Konpeito was exactly
my use case too, it was one of my first tests.

That dependency is annoying, I don't think it's just you. I've changed
the README, the install command is now:

GO111MODULE=on go get -u github.com/makeworld-the-better-one/gemget

Try that and let me know if it works better, you have to have at least
Go version 1.11 I think. Worst case, you can always install from a binary.

One small nitpick: Could you update the Gemini software page? It says
gemnet instead gemget. Thanks for adding it!

makeworld

??????? Original Message ???????
On Tuesday, May 5, 2020 2:56 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> Ahoy!
>
> I'm really happy to see that somebody has written something like this,
> it's something I've thought would be handy for a long time. In my mind,
> a program like this is an ideal solution to the usability problems
> people have cited with rare things like downloading konpeito.media
> releases using the more interactive clients.
>
> I'd love to give this a spin, but it's not building for me - or rather,
> the github.com/schollz/progressbar dependency isn't building. Which is
> probably just my "ancient" Debian stable version of Go...
>
> Cheers,
> Solderpunk
>
> On Mon, May 04, 2020 at 04:22:17PM +0000, Cole Anthony Capilongo wrote:
>
> > Hello Geminauts!
> > I found out about Gemini through the recent Hacker News post, and I
> > couldn't resist exploring and making something for it.
> > I'm using both Castor and Bombadillo for browsing Gemini, and neither
> > of them really did what I wanted in terms of downloading. There's no
> > indication of progress, so it feels a bit like the client has frozen
> > up, until I see the file saved, or some application open.
> > For that and other reasons, I decided to create a command line
> > downloader for Gemini, similar to wget but much simpler at the moment.
> > It's available at https://github.com/makeworld-the-better-one/gemget/
> > and is written in Go, with binaries available.
> > I'm somewhat new to Go and Gemini, so I'd appreciate any suggestions
> > or bug reports a lot.
> > Happy hacking!
> > makeworld



From fabrixxm at kirgroup.net  Wed May  6 20:08:22 2020
From: fabrixxm at kirgroup.net (Fabio)
Date: Wed, 06 May 2020 21:08:22 +0200
Subject: [ANN] Alrisha: a Qt/QML gemini browser
Message-ID: <YTBX9Q.NCYEJ17VKDJB@kirgroup.net>

Hi everybody!

I'm new here! I found Gemini last week thanks to Castor being featured 
on sr.ht (:thumbup:!)

So my first thought was "I need a Gemini browser on my phone", 
obviously.


I started playing with some code and I ended up with a desktop browser 
written in Qt/QML

It's ugly and slow and sometimes it doesn't works as it should and you 
can find it here:

=> https://git.sr.ht/~fabrixxm/alrisha

Eventually I'll port it to SailfishOS :) I need it to water my 
astroplany on the move

I have another project to show, but It's not ready yet :D




From colecmac at protonmail.com  Thu May  7 00:03:13 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 06 May 2020 23:03:13 +0000
Subject: [ANN] Alrisha: a Qt/QML gemini browser
In-Reply-To: <YTBX9Q.NCYEJ17VKDJB@kirgroup.net>
References: <YTBX9Q.NCYEJ17VKDJB@kirgroup.net>
Message-ID: <VC8PwPgYjMDZvhgHIvlChVSlJ9U-FXDhvnwo1cZjeAyMVpXK9V8kSTxIAM-al0V9EvlCxwFsqOh3rEYNFNRetFNfdQzPtBb8dVoGmYBVEs0=@protonmail.com>

Hi Fabio,

Nice work, this looks great! Happy to see another GUI browser,
and the default style is nice. Good choice with the margins,
I hate reading text that goes across the whole screen.
Tabbed browsing is also exciting!

If anyone else was unsure how to install it, cloning and then
running `make` works fine. And the `AppDataLocation` the README
mentions is ~/.local/share/alrisha/ on Linux, so
putting/symlinking your certs and keys there works.

> I have another project to show, but It's not ready yet :D

Any hints for us? :)


makeworld

??????? Original Message ???????
On Wednesday, May 6, 2020 3:08 PM, Fabio <fabrixxm at kirgroup.net> wrote:

> Hi everybody!
>
> I'm new here! I found Gemini last week thanks to Castor being featured
> on sr.ht (:thumbup:!)
>
> So my first thought was "I need a Gemini browser on my phone",
> obviously.
>
> I started playing with some code and I ended up with a desktop browser
> written in Qt/QML
>
> It's ugly and slow and sometimes it doesn't works as it should and you
> can find it here:
>
> => https://git.sr.ht/~fabrixxm/alrisha
>
> Eventually I'll port it to SailfishOS :) I need it to water my
> astroplany on the move
>
> I have another project to show, but It's not ready yet :D



From sean at conman.org  Thu May  7 03:06:37 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 6 May 2020 22:06:37 -0400
Subject: The Gemini Client Torture tests
Message-ID: <20200507020637.GD7305@brevard.conman.org>


  If anyone has been trying to use the Gemini Torture tests
(gemini://gemini.conman.org/test/torture/) and having problems getting past
test #8, I do apologize.  I recently fixed a memory leak, which in turn
revealed an actual crashing bug (if the client is buggy---fancy that) in the
server that took about a week to track down (and was a simple one line
fix---always the case).  The gory details are here:

	http://boston.conman.org/2020/05/06.1

if anyone is interested in the details.  The server, and more importantly,
the torture tests, should stay up this time.

  -spc
  

From fabrixxm at kirgroup.net  Thu May  7 09:56:24 2020
From: fabrixxm at kirgroup.net (Fabio)
Date: Thu, 07 May 2020 10:56:24 +0200
Subject: [ANN] Alrisha: a Qt/QML gemini browser
Message-ID: <06EY9Q.QNIF24M66RRY1@kirgroup.net>

 > I hate reading text that goes across the whole screen.

Yeah, me too. The first version was full width, but it lasted a short 
time :)

 > Tabbed browsing is also exciting!

Hint: CTRL+click to open link in a new tab :D

 > If anyone else was unsure how to install it, cloning and then
running `make` works fine

I usually just open the project in Qt Creator. I'll add a "run make" 
note to the readme ?

 > > I have another project to show, but It's not ready yet :D
 >
 > Any hints for us? :)

https://kirgroup.com/note/34c72a805d099139719bf947

or if you prefer

gemini://kirgroup.com/outbox/34c72a805d099139719bf947/activity

:)

I hope this mail will get thru correctly. I had some problem with my 
mail server.
Sorry if it isn't threaded correctly..






From dwh at vi.rs  Thu May  7 23:24:32 2020
From: dwh at vi.rs (Dave Huseby)
Date: Thu, 07 May 2020 15:24:32 -0700
Subject: Publishing packages/installers for Gemini browsers
Message-ID: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>

Long time listener, first time caller...

I just stood up my own Gemini space to publish my writing on user sovereignty, decentralization and privacy. You can find it here: gemini://vi.rs  I'm using Let's Encrypt TLS certs with a modified Pollux. I've been watching the Gemini project for months now and I like where it is headed. I chose to publish using only Gemini because it is the closest user-sovereign publishing system we have ATM.

The only problem now is that lots of people have asked me what they can download and run to read my Gemini "mission log". There aren't any precompiled packages or installers so I've been having them ssh to kiosk to run the VP client. Is anybody planning to publish packages/installers anytime soon? I've had several thousand hits on my Gemini space in the last couple of days despite the hurdles for getting onto Gemini. Castor is hosted on sr.ht that has CI capabilities. I'm familiar with setting up CI builds on Github but not on sr.ht. Does anybody know how to set that up and is willing to send a patch to the maintainer of Castor?

Cheers!
Dave

From stryan at saintnet.tech  Fri May  8 00:10:52 2020
From: stryan at saintnet.tech (Steve Ryan)
Date: Thu, 7 May 2020 19:10:52 -0400
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
References: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
Message-ID: <20200507231052.2daa3ntn2slj4y5s@vineta.saintnet.lan>

On 20/05/07 03:24PM, Dave Huseby wrote:
> Long time listener, first time caller...
> 
> I just stood up my own Gemini space to publish my writing on user sovereignty, decentralization and privacy. You can find it here: gemini://vi.rs  I'm using Let's Encrypt TLS certs with a modified Pollux. I've been watching the Gemini project for months now and I like where it is headed. I chose to publish using only Gemini because it is the closest user-sovereign publishing system we have ATM.
> 
> The only problem now is that lots of people have asked me what they can download and run to read my Gemini "mission log". There aren't any precompiled packages or installers so I've been having them ssh to kiosk to run the VP client. Is anybody planning to publish packages/installers anytime soon? I've had several thousand hits on my Gemini space in the last couple of days despite the hurdles for getting onto Gemini. Castor is hosted on sr.ht that has CI capabilities. I'm familiar with setting up CI builds on Github but not on sr.ht. Does anybody know how to set that up and is willing to send a patch to the maintainer of Castor?
> 
> Cheers!
> Dave

Can't answer your specific question since I've only written a server not
a client, but I figured I'd chime in.

I'm somewhat familiar with packaging stuff using OpenSuse's OpenBuildSystem
which can spit out rpms, debs, etc pretty easily. If anyone wants their
client/server packaged but doesn't know how I'm more than happy to help
out and get that ball rolling.

-Steve

From sean at conman.org  Fri May  8 03:35:45 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 7 May 2020 22:35:45 -0400
Subject: The Gemini Client Torture tests
In-Reply-To: <20200507020637.GD7305@brevard.conman.org>
References: <20200507020637.GD7305@brevard.conman.org>
Message-ID: <20200508023545.GE7305@brevard.conman.org>


  I just found another bug with the Gemini Client Torture test:

	gemini://gemini.conman.org/test/torture/

This time with test #40.  It has been fixed.

  -spc


From dominik.dalek at thaumatec.com  Fri May  8 08:25:06 2020
From: dominik.dalek at thaumatec.com (Dominik Dalek)
Date: Fri, 8 May 2020 09:25:06 +0200
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
References: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
Message-ID: <CACVUgn-6YrGbfsQNrew77oQ6bCF7B9Q6BsSywuHVPO2iVwvLNQ@mail.gmail.com>

Howdy!

FWIW I had a very pleasant experience with Asuka client. It has no package
available for download but it's in Rust and can be built by a relatively
unskilled person. Some documentation on how one would build it is missing
but I'm sure this is something that can be remedied without much effort.

Instruction pretty much boils down to:
1. Run rustup
2. Get the code
3. Run cargo build
4. Done.

The undocumented part is between 2 and 3:
* on Windows, change dependencies to pancurses (I should send a patch)
* on Linux, `sudo apt install ...` some dependencies (needs documenting)

But yeah, in an ideal world there would be a package ready for download.

-Dom

On Fri, May 8, 2020 at 12:25 AM Dave Huseby <dwh at vi.rs> wrote:
>
> Long time listener, first time caller...
>
> I just stood up my own Gemini space to publish my writing on user sovereignty, decentralization and privacy. You can find it here: gemini://vi.rs  I'm using Let's Encrypt TLS certs with a modified Pollux. I've been watching the Gemini project for months now and I like where it is headed. I chose to publish using only Gemini because it is the closest user-sovereign publishing system we have ATM.
>
> The only problem now is that lots of people have asked me what they can download and run to read my Gemini "mission log". There aren't any precompiled packages or installers so I've been having them ssh to kiosk to run the VP client. Is anybody planning to publish packages/installers anytime soon? I've had several thousand hits on my Gemini space in the last couple of days despite the hurdles for getting onto Gemini. Castor is hosted on sr.ht that has CI capabilities. I'm familiar with setting up CI builds on Github but not on sr.ht. Does anybody know how to set that up and is willing to send a patch to the maintainer of Castor?
>
> Cheers!
> Dave



-- 
Dominik Dalek, Software Engineer
Thaumatec Sp. z o.o.
ul. Mickiewicza 20c, 51-619 Wroclaw

From cat at ff3366.com  Fri May  8 08:44:41 2020
From: cat at ff3366.com (Cat)
Date: Fri, 8 May 2020 17:44:41 +1000
Subject: [ANN] gemget, a gemini downloader
In-Reply-To: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>
References: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>
Message-ID: <CAN7Pwngy8ertT9_5a8Wzsuhd5tRWMNV9+02GPPqQrRXVk5v2rw@mail.gmail.com>

This is dope, thank you!

On Tue, May 5, 2020 at 2:22 AM Cole Anthony Capilongo
<colecmac at protonmail.com> wrote:
>
> Hello Geminauts!
>
> I found out about Gemini through the recent Hacker News post, and I
> couldn't resist exploring and making something for it.
>
> I'm using both Castor and Bombadillo for browsing Gemini, and neither
> of them really did what I wanted in terms of downloading. There's no
> indication of progress, so it feels a bit like the client has frozen
> up, until I see the file saved, or some application open.
>
> For that and other reasons, I decided to create a command line
> downloader for Gemini, similar to wget but much simpler at the moment.
> It's available at https://github.com/makeworld-the-better-one/gemget/
> and is written in Go, with binaries available.
>
> I'm somewhat new to Go and Gemini, so I'd appreciate any suggestions
> or bug reports a lot.
>
> Happy hacking!
>
> makeworld

From julien at typed-hole.org  Fri May  8 10:48:48 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Fri, 8 May 2020 11:48:48 +0200
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
References: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
Message-ID: <fd63d111-e22a-6258-9d21-8c74b20266ed@typed-hole.org>

On 5/8/20 12:24 AM, Dave Huseby wrote:

> You can find it here: gemini://vi.rs  I'm using Let's Encrypt TLS certs with a modified Pollux.
Cool place! Funny to see someone using Pollux besides me!
> Castor is hosted on sr.ht that has CI capabilities. I'm familiar with setting up CI builds on Github but not on sr.ht. Does anybody know how to set that up and is willing to send a patch to the maintainer of Castor?

I'm the maintainer of Asuka and Castor. Providing packages is something 
I definitely want to do. I'll be looking into OpenBuildSystem this looks 
very neat!


From julien at typed-hole.org  Fri May  8 10:52:03 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Fri, 8 May 2020 11:52:03 +0200
Subject: [ANN] gemget, a gemini downloader
In-Reply-To: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>
References: <7SM7_qUfAbJu7ul1bssgRrihNenCOgQIezjg7ZsVRhWlDA9wLcTEH8ictqKyUL4Zuhu4mUpihG8_6KRNqLNYF-S6_mhmHd9JlXqcuJSFdkk=@protonmail.com>
Message-ID: <17d89fc1-edd7-0239-60b0-a1b705274a51@typed-hole.org>

On 5/4/20 6:22 PM, Cole Anthony Capilongo wrote:

> It's available at https://github.com/makeworld-the-better-one/gemget/
> and is written in Go, with binaries available.

Just tried it, it's very cool! Maybe I could use it with Castor when 
available on a system.


From solderpunk at SDF.ORG  Sat May  9 15:34:01 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 9 May 2020 14:34:01 +0000
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
References: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
Message-ID: <20200509143401.GE2210@SDF.ORG>

Hi Dave,

This is a good point to raise.  I guess prior to the recent influx of
interest from Hacker News and other places, we've been able to somewhat
ignore this, because most of the consumers of Gemini content have also
been active community members who have the skills, interest and time to
get their client(s) of choice up and running.  But lowering the barrier
to entry will be important for wider adoption.

I can't promise anything, but I'll make an effort to push out a 1.0.0
release of AV-98 tomorrow (cue anguished cries from people in
Gopherspace who have been waiting years for a 1.0.0 release of VF-1!),
and as part of that I'll upload it to PyPI - that means a simple `pip
install` will be able to get people started.  Admittedly a command-line
client isn't going to be an easy intro for a lot of people, but it will
work for many, and to be honest I'm not sure the project is necessarily
ready for thousands of new users in a short time span yet.  But some
extra energy - and especially content! - would definitely be very
welcome.

Cheers,
Solderpunk


On Thu, May 07, 2020 at 03:24:32PM -0700, Dave Huseby wrote:
> Long time listener, first time caller...
> 
> I just stood up my own Gemini space to publish my writing on user sovereignty, decentralization and privacy. You can find it here: gemini://vi.rs  I'm using Let's Encrypt TLS certs with a modified Pollux. I've been watching the Gemini project for months now and I like where it is headed. I chose to publish using only Gemini because it is the closest user-sovereign publishing system we have ATM.
> 
> The only problem now is that lots of people have asked me what they can download and run to read my Gemini "mission log". There aren't any precompiled packages or installers so I've been having them ssh to kiosk to run the VP client. Is anybody planning to publish packages/installers anytime soon? I've had several thousand hits on my Gemini space in the last couple of days despite the hurdles for getting onto Gemini. Castor is hosted on sr.ht that has CI capabilities. I'm familiar with setting up CI builds on Github but not on sr.ht. Does anybody know how to set that up and is willing to send a patch to the maintainer of Castor?
> 
> Cheers!
> Dave

From natpen at natpen.net  Sat May  9 19:12:41 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sat, 9 May 2020 14:12:41 -0400
Subject: Search GUS by content type!
Message-ID: <20200509181241.GA161718@goldfish.localdomain>

Hi everyone,

I just wanted to share a nice update on GUS. After some discussion
with sloum, I decided to put some time into better support for content
types.

Content types been being printed alongside search results for a few
weeks already, but I'm happy to announce that as of today you also get
first-class support for them in your queries! There is documentation
for how to use them at gemini://gus.guru/about, along with a number of
useful content types to try out, like audio, image, and text.

One of my favorite so far is `audio`. You could search for, say,
`content_type:audio` to find ALL music in Geminispace, or `dogs
content_type:audio/mp3` to find some good songs about dogs in mp3
format.

Thank you for all the feedback on this project so far. I still have a
nice list of TODOs for GUS, mostly due to conversations with other
Geminauts.

Nat

From sean at conman.org  Mon May 11 01:18:21 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 10 May 2020 20:18:21 -0400
Subject: An observation about client certificates
Message-ID: <20200511001820.GI7305@brevard.conman.org>


  I know logging isn't popular here, but I still do it anyway, in order to
track down issues that might come up, either bugs in the server.  Early on,
I decided also log certificates that might be used to hit the "/private"
directory on my server.  I'm seeing a bit more activity there, which is
nice, the latest one being:

remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="/CN=AV-98 cert test" issuer="/CN=AV-98 cert test"

  But the following requests had me seriously puzzled:

remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="" issuer=""
remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/mondrian.gif" bytes=3082 subject="" issuer=""

  After quite a bit of testing and thinking on this, I can only conclude
that whomever sent this request did have a certificate, but the certificate
did not include the issuer or subject fields.  As I stated, I accept any
certificate (as long as the dates are valid).  I did not expect a
certificate sans issuer/subject could be valid as well.  Perhaps it's not, I
don't actually know, but kudos to the requestor.  I was not expecting this.

  -spc



From b__m__e at mailfence.com  Mon May 11 01:18:57 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Mon, 11 May 2020 02:18:57 +0200 (CEST)
Subject: Publishing packages/installers for Gemini browsers
Message-ID: <189864553.486215.1589156337414@ichabod.co-bxl>

Hi Dave,
Funny to see this on the mailing list this morning as I was reading through your work just last night. Really great stuff!

I cannot speak for the other client maintainers, but I can give some info for my client (Bombadillo):

All major and minor versions, but not patch versions, are available as pre-compiled binaries from the website or gopher (bombadillo.colorfield.space in either case), for Linux-32, Linux-64, OSX-64, and I believe we have a BSD build up as well but do not quote me on that (we do not support Windows at present).

I was told someone has a build up in the Arch AUR as well. I am not an Arch user and have not been able to verify what version they are at or if they are actively maintaining it.

I would love to see it packaged for other distros. Steve, in a response to the OP, mentions OpenSuse having a good build system. I may have to look into that. I'm not sure I have the time to devote to maintaining the codebase as well as packaging for multiple distros, but I'd definitely give it a try for at least Debian. I may wait until the next minor release as I have some gemini-specific improvements that should be releasing in the near future. I'd love any advice people have re: packaging as I am very new to trying to do so (I usually just build everything from source when possible).

As far as building goes, for those users with the desire to try, Bombadillo will compile with a Go compiler for 1.11 or newer. It uses no packages outside of the standard library and comes with a makefile (sudo make install, and you should be good to go).

--?
Sent with https://mailfence.com
Secure and private email

From solderpunk at SDF.ORG  Mon May 11 09:18:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 11 May 2020 08:18:16 +0000
Subject: An observation about client certificates
In-Reply-To: <20200511001820.GI7305@brevard.conman.org>
References: <20200511001820.GI7305@brevard.conman.org>
Message-ID: <20200511081816.GA23500@SDF.ORG>

Haha, this was me!  In order to get a 1.0.0 release of AV-98 out the
door and into PyPI quickly so that there's an easy to install client for
curious newcomers, I spent some time yesterday hacking away on client
certificate support.  Mozz added some basic support a few weeks back to
facilitate the astrobotany game, but I am working on something slightly
more user-friendly.  As long as the `openssl` command line tool is
installed, it will soon be possible to generate certs from within AV-98
in response to status codes wanting them.  Once you navigate to a
different domain other than the one for which the cert was generated,
you'll get a privacy warning and the option to stop using that cert.
It's certainly still rough around the edges, but it's usable enough and
will facilitate more experimentation on the server side with client
certificates.  I'll post lots more about this work here in the near
future.

Anyway, at some point yesterday I got tired of filling out `openssl`s
prompts when making new certs and just gave blank answers to everything,
which would be the requests you noticed.  Are you quite sure that your
server handled them just fine as the logs indicate?  If I remember
rightly the SSL handshake seemed to fail when I did this so I quickly
reverted to putting something non-zero in there.

We should talk about logging formats some time.  Molly Brown keeps logs
too (I keep meaning to make a nice graph showing the wave of traffice
that came in after we hit HN), in an ad-hoc format that doesn't match
yours below at all (unsurprisingly).  Having a standard format would
facilitate tools to monitor/visualise logs.

Cheers,
Solderpunk

On Sun, May 10, 2020 at 08:18:21PM -0400, Sean Conner wrote:
> 
>   I know logging isn't popular here, but I still do it anyway, in order to
> track down issues that might come up, either bugs in the server.  Early on,
> I decided also log certificates that might be used to hit the "/private"
> directory on my server.  I'm seeing a bit more activity there, which is
> nice, the latest one being:
> 
> remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="/CN=AV-98 cert test" issuer="/CN=AV-98 cert test"
> 
>   But the following requests had me seriously puzzled:
> 
> remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="" issuer=""
> remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/mondrian.gif" bytes=3082 subject="" issuer=""
> 
>   After quite a bit of testing and thinking on this, I can only conclude
> that whomever sent this request did have a certificate, but the certificate
> did not include the issuer or subject fields.  As I stated, I accept any
> certificate (as long as the dates are valid).  I did not expect a
> certificate sans issuer/subject could be valid as well.  Perhaps it's not, I
> don't actually know, but kudos to the requestor.  I was not expecting this.
> 
>   -spc
> 
> 

From plugd at thelambdalab.xyz  Mon May 11 09:30:30 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Mon, 11 May 2020 10:30:30 +0200
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
References: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
Message-ID: <lzwo5i6fh5.fsf@bs-mbpr348.d.ethz.ch>




Dave Huseby writes:

> Long time listener, first time caller...
>
> I just stood up my own Gemini space to publish my writing on user sovereignty, decentralization and privacy. You can find it here: gemini://vi.rs  I'm using Let's Encrypt TLS certs with a modified Pollux. I've been watching the Gemini project for months now and I like where it is headed. I chose to publish using only Gemini because it is the closest user-sovereign publishing system we have ATM.
>
> The only problem now is that lots of people have asked me what they can download and run to read my Gemini "mission log". There aren't any precompiled packages or installers so I've been having them ssh to kiosk to run the VP client. Is anybody planning to publish packages/installers anytime soon? I've had several thousand hits on my Gemini space in the last couple of days despite the hurdles for getting onto Gemini. Castor is hosted on sr.ht that has CI capabilities. I'm familiar with setting up CI builds on Github but not on sr.ht. Does anybody know how to set that up and is willing to send a patch to the maintainer of Castor?
>
> Cheers!
> Dave



From plugd at thelambdalab.xyz  Mon May 11 09:35:09 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Mon, 11 May 2020 10:35:09 +0200
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
References: <f17d37b8-8eca-4ffd-9c6d-5d768541227a@www.fastmail.com>
Message-ID: <lztv0m6f9e.fsf@bs-mbpr348.d.ethz.ch>


Hi Dave,

Dave Huseby writes:
> Is anybody planning to publish packages/installers anytime soon?

For what it's worth, my emacs-based client elpher is available from the
MELPA repository.  So, for emacs users at least, installation is as
simple as "M-x package-install RET elpher RET".

Cheers,

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200511/0a91de66/attachment.sig>

From sean at conman.org  Mon May 11 10:21:01 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 11 May 2020 05:21:01 -0400
Subject: An observation about client certificates
In-Reply-To: <20200511081816.GA23500@SDF.ORG>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG>
Message-ID: <20200511092101.GJ7305@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> Anyway, at some point yesterday I got tired of filling out `openssl`s
> prompts when making new certs and just gave blank answers to everything,
> which would be the requests you noticed.  Are you quite sure that your
> server handled them just fine as the logs indicate?

  If it doesn't, I have bigger issues.  But I was unable to reproduce what I
was seeing, but I didn't actually get around to producing a certificate
with an empty issuer and subject field.  

> If I remember
> rightly the SSL handshake seemed to fail when I did this so I quickly
> reverted to putting something non-zero in there.

  Well, I told the TLS layer that I didn't want *it* to verify the
certificate, and the only validation *I* do prior to request specific
checks, is to check the date.  And for my "/private" subdirectory, all I do
is return 'true'---I don't bother checking the actual certificate.

> We should talk about logging formats some time.  Molly Brown keeps logs
> too (I keep meaning to make a nice graph showing the wave of traffice
> that came in after we hit HN), in an ad-hoc format that doesn't match
> yours below at all (unsurprisingly).  Having a standard format would
> facilitate tools to monitor/visualise logs.

  I log via syslog(), which handles the timestamps for me (and log rotation,
and a whole bunch of other stuff related to logging).  I place the name of
the fields to make later processing a bit easier, but as far as I can tell,
the only thing I log that you don't is the issuer and subject from any
certificates presented, and that was to satisfy my own curiousity (and to
potentially troubleshoot any issues).

  But there's really not much to log, other than remote address, request,
status, and potentially the issuer/subject of any given certificate (and
even that might be optional).  

  -spc

From gmym at coopdot.com  Mon May 11 18:15:09 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Mon, 11 May 2020 19:15:09 +0200
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <189864553.486215.1589156337414@ichabod.co-bxl>
References: <189864553.486215.1589156337414@ichabod.co-bxl>
Message-ID: <CAObwWNhPSi8P1CHJGjfFm6opcEwfSY0aSYtf9Yb-4-zuDHWVhA@mail.gmail.com>

Hello, I got here from Hacker News in the beginning of the month.

Brian Evans <b__m__e at mailfence.com> wrote:

> I was told someone has a build up in the Arch AUR as well. I am not an
> Arch user and have not been able to verify what version they are at or if
> they are actively maintaining it.
>

The package in the Arch User Repository has not been updated since it was
first submitted. I installed bombadillo that way on my laptop just now and
it was painless for an AUR package. It didn't like my server's certificate,
but other servers were fine.

The package details:

https://aur.archlinux.org/packages/bombadillo-git

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200511/9abb879f/attachment.htm>

From colecmac at protonmail.com  Mon May 11 19:06:34 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 11 May 2020 18:06:34 +0000
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <CAObwWNhPSi8P1CHJGjfFm6opcEwfSY0aSYtf9Yb-4-zuDHWVhA@mail.gmail.com>
References: <189864553.486215.1589156337414@ichabod.co-bxl>
 <CAObwWNhPSi8P1CHJGjfFm6opcEwfSY0aSYtf9Yb-4-zuDHWVhA@mail.gmail.com>
Message-ID: <wX1nFwfA3iApmUErXWXHVwkl8zgMCsfWhdXZOj25k2ZYrXTVRgzHtAtXcuU4eL3jg_72xoHggjIZjaMCCLrzE9AZF1Qz_3x1ZWgRUUqAjZo=@protonmail.com>

> The package in the Arch User Repository has not been updated since it was first submitted

Just to clarify, the AUR pkg that's been linked is a git package, which means that it just pulls from git everytime you install or update it. So it's okay that it "hasn't been updated".


makeworld

??????? Original Message ???????
On Monday, May 11, 2020 1:15 PM, Katarina Eriksson <gmym at coopdot.com> wrote:

> Hello, I got here from Hacker News in the beginning of the month.
>
> Brian Evans <b__m__e at mailfence.com> wrote:
>
> > I was told someone has a build up in the Arch AUR as well. I am not an Arch user and have not been able to verify what version they are at or if they are actively maintaining it.
>
> The package in the Arch User Repository has not been updated since it was first submitted. I installed bombadillo that way on my laptop just now and it was painless for an AUR package. It didn't like my server's certificate, but other servers were fine.
>
> The package details:
>
> https://aur.archlinux.org/packages/bombadillo-git
>
> --?
> Katarina
>
> >



From escondida at iff.ink  Mon May 11 22:32:34 2020
From: escondida at iff.ink (Ivy Foster)
Date: Mon, 11 May 2020 16:32:34 -0500
Subject: Publishing packages/installers for Gemini browsers
In-Reply-To: <CAObwWNhPSi8P1CHJGjfFm6opcEwfSY0aSYtf9Yb-4-zuDHWVhA@mail.gmail.com>
References: <189864553.486215.1589156337414@ichabod.co-bxl>
 <CAObwWNhPSi8P1CHJGjfFm6opcEwfSY0aSYtf9Yb-4-zuDHWVhA@mail.gmail.com>
Message-ID: <20200511172547.GA784@beanhill.localdomain>

On 11 May 2020, at  7:15 pm +0200, Katarina Eriksson wrote:
> Brian Evans <b__m__e at mailfence.com> wrote:
> > I was told someone has a build up in the Arch AUR as well. I am not an
> > Arch user and have not been able to verify what version they are at or if
> > they are actively maintaining it.

> The package in the Arch User Repository has not been updated since it was
> first submitted. I installed bombadillo that way on my laptop just now and
> it was painless for an AUR package. It didn't like my server's certificate,
> but other servers were fine.

Hey, folks, I'm new here, too. Gemini seems awesome!

The way -git (and -hg, et al.) build scripts work in the AUR (which
doesn't contain any packages: it's a repository of build scripts you
can use to build Arch packages) is that the only time they need to get
updated on the site is if the build instructions change. When a user
builds the package with Arch's packaging tools, the latest git (or
whatever) is automagically fetched from the repository listed in the
$source variable in the PKGBUILD, and the version of their newly-built
local package is updated to reflect that.

Cheers,
Ivy

From dwh at vi.rs  Tue May 12 02:37:18 2020
From: dwh at vi.rs (Dave Huseby)
Date: Mon, 11 May 2020 18:37:18 -0700
Subject: An observation about client certificates
In-Reply-To: <20200511092101.GJ7305@brevard.conman.org>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
Message-ID: <fdee9e98-528b-4bad-b154-859721b1e3e4@www.fastmail.com>

On Mon, May 11, 2020, at 2:21 AM, Sean Conner wrote:
> > We should talk about logging formats some time.  Molly Brown keeps logs
> > too (I keep meaning to make a nice graph showing the wave of traffice
> > that came in after we hit HN), in an ad-hoc format that doesn't match
> > yours below at all (unsurprisingly).  Having a standard format would
> > facilitate tools to monitor/visualise logs.
> 
>   I log via syslog(), which handles the timestamps for me (and log rotation,
> and a whole bunch of other stuff related to logging).  I place the name of
> the fields to make later processing a bit easier, but as far as I can tell,
> the only thing I log that you don't is the issuer and subject from any
> certificates presented, and that was to satisfy my own curiousity (and to
> potentially troubleshoot any issues).

I think by default, any logging we do should be at a bare minimum and not contain the IP address of the client or any other data that would link the log line to them. I added logging to my hacked up version of Pollux but it only logs which page was loaded and when. My purpose was to track basic traffic and any errors that occur and nothing else.

Dave

From sean at conman.org  Tue May 12 03:58:34 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 11 May 2020 22:58:34 -0400
Subject: An observation about client certificates
In-Reply-To: <fdee9e98-528b-4bad-b154-859721b1e3e4@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <fdee9e98-528b-4bad-b154-859721b1e3e4@www.fastmail.com>
Message-ID: <20200512025833.GM7305@brevard.conman.org>

It was thus said that the Great Dave Huseby once stated:
> On Mon, May 11, 2020, at 2:21 AM, Sean Conner wrote:
> > > We should talk about logging formats some time.  Molly Brown keeps logs
> > > too (I keep meaning to make a nice graph showing the wave of traffice
> > > that came in after we hit HN), in an ad-hoc format that doesn't match
> > > yours below at all (unsurprisingly).  Having a standard format would
> > > facilitate tools to monitor/visualise logs.
> > 
> >   I log via syslog(), which handles the timestamps for me (and log rotation,
> > and a whole bunch of other stuff related to logging).  I place the name of
> > the fields to make later processing a bit easier, but as far as I can tell,
> > the only thing I log that you don't is the issuer and subject from any
> > certificates presented, and that was to satisfy my own curiousity (and to
> > potentially troubleshoot any issues).
> 
> I think by default, any logging we do should be at a bare minimum and not
> contain the IP address of the client or any other data that would link the
> log line to them. I added logging to my hacked up version of Pollux but it
> only logs which page was loaded and when. My purpose was to track basic
> traffic and any errors that occur and nothing else.

  One misbehaving client on an IP address can present a headache by repeated
making requests and (especially if it's behind a larger pipe than yours)
sawmp the server.  By recording the IP address, it can be identified and
blocked.

  Or a mishevaving client always makes the same request to a non-existant
resource.  I had this happen on my gopher server---some web bot kept trying
to fetch the main index.html page.  Very annoying.  Again, easy to block if
you have the IP.

  -spc (Oooh, that reminds me, I have a bug to patch in GLV-1.12556 ... )


From dave at westside.vegas  Tue May 12 02:32:45 2020
From: dave at westside.vegas (Dave Huseby)
Date: Mon, 11 May 2020 18:32:45 -0700
Subject: Basic git clone over gemini:// working
Message-ID: <93f3849a-88a2-4eb7-91b6-5d21aea6c515@www.fastmail.com>

Howdy,

I got bored over the weekend and wrote a simple Git remote helper for the gemini protocol. I published it on github for now: https://github.com/dhuseby/git-remote-gemini.git  Once you have it built and installed in your PATH somewhere, you'll then be able to clone it from the its actual location here: gemini://vi.rs/git-remote-gemini.git

I did a short terminal capture of me cloning a repo over gemini: https://asciinema.org/a/y2QxPEbgHsiGh4Go1AuHTLT0D

To make this work, I had to hack up Pollux to respond to simple queries and run the appropriate Git commands on the server. The details are in the README.gemini file in the repo.

Cheers!
Dave

From ziggys at autistici.org  Tue May 12 14:58:34 2020
From: ziggys at autistici.org (ziggys at autistici.org)
Date: Tue, 12 May 2020 10:58:34 -0300
Subject: New gemini server fully spanish
Message-ID: <-ywzopde1jpum-aemw8i-79ok97ugm405p19gtz-ybk2a9-t7hltje7oo1j-85zli5-215n3d32p3fktm8io-b2bzms-pxdms3-nd1e08-hhxqbdu3uzpszf89kf-l4ge77-98en0e-6aygjt-wz5rixz3n0wn.1589291914118@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200512/534a8d04/attachment.htm>

From solderpunk at SDF.ORG  Tue May 12 19:04:20 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 12 May 2020 18:04:20 +0000
Subject: New gemini server fully spanish
In-Reply-To: <-ywzopde1jpum-aemw8i-79ok97ugm405p19gtz-ybk2a9-t7hltje7oo1j-85zli5-215n3d32p3fktm8io-b2bzms-pxdms3-nd1e08-hhxqbdu3uzpszf89kf-l4ge77-98en0e-6aygjt-wz5rixz3n0wn.1589291914118@email.android.com>
References: <-ywzopde1jpum-aemw8i-79ok97ugm405p19gtz-ybk2a9-t7hltje7oo1j-85zli5-215n3d32p3fktm8io-b2bzms-pxdms3-nd1e08-hhxqbdu3uzpszf89kf-l4ge77-98en0e-6aygjt-wz5rixz3n0wn.1589291914118@email.android.com>
Message-ID: <20200512180420.GB16945@SDF.ORG>

On Tue, May 12, 2020 at 10:58:34AM -0300, ziggys at autistici.org wrote:
> <div dir="auto">Hi, All.?<div><br /></div><div>To announce our new gemini capsule is online for all spanish-speaking community. Available on:</div><div><br /></div><div>gemini://gagarin.p4g.club</div><div><br />Regards.?</div><div><br /></div></div>

Wonderful, thanks for letting us know.  It's good to some linguistic
diversity in Geminispace!  I will actually make a post here when I get a
chance on some i18n-related thoughts for Gemini...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 12 19:13:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 12 May 2020 18:13:59 +0000
Subject: Basic git clone over gemini:// working
In-Reply-To: <93f3849a-88a2-4eb7-91b6-5d21aea6c515@www.fastmail.com>
References: <93f3849a-88a2-4eb7-91b6-5d21aea6c515@www.fastmail.com>
Message-ID: <20200512181359.GC16945@SDF.ORG>

Holy heck!  That is impressive and exciting.  I know essentially nothing
about git internals.  To what extent does doing this rely on features of
Gemini which have no equivalent in Gopher?  Or is this actually much
simpler than I'm imagining it?

Cheers,
Solderpunk

On Mon, May 11, 2020 at 06:32:45PM -0700, Dave Huseby wrote:
> Howdy,
> 
> I got bored over the weekend and wrote a simple Git remote helper for the gemini protocol. I published it on github for now: https://github.com/dhuseby/git-remote-gemini.git  Once you have it built and installed in your PATH somewhere, you'll then be able to clone it from the its actual location here: gemini://vi.rs/git-remote-gemini.git
> 
> I did a short terminal capture of me cloning a repo over gemini: https://asciinema.org/a/y2QxPEbgHsiGh4Go1AuHTLT0D
> 
> To make this work, I had to hack up Pollux to respond to simple queries and run the appropriate Git commands on the server. The details are in the README.gemini file in the repo.
> 
> Cheers!
> Dave

From solderpunk at SDF.ORG  Tue May 12 19:23:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 12 May 2020 18:23:15 +0000
Subject: Gemini server logging formats and practices
In-Reply-To: <20200511092101.GJ7305@brevard.conman.org>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG>
 <20200511092101.GJ7305@brevard.conman.org>
Message-ID: <20200512182315.GD16945@SDF.ORG>

On Mon, May 11, 2020 at 05:21:01AM -0400, Sean Conner wrote:
 
>   But there's really not much to log, other than remote address, request,
> status, and potentially the issuer/subject of any given certificate (and
> even that might be optional).  

I agree, there's not much to log, far less than HTTP.  But there's some
real utility in having, err, utilities which can parse a log and
generate basic statistics an admin might like to know: most popular
resources, frequent requests resulting in 51 Not Found responses,
average requests per day.  And people are more likely to write things
like this if there's one format to worry about and not one per server.

This isn't a hard side-project by any means.  Something very simple and
easy to read into existing data processing tools, like a comma separated
or tab separated value file with standardised names and/or order for the
columns and an agreed-upon representation of time would do the trick.

I am understanding of and sympathetic towards both admins who want to
log IPs for debugging or abuse-detection purposes and towards those who
don't want to so they can (rightfully) boast about their severs' respect
for privacy.  So the standard format should include a column for remote
IP and also have a clearly defined behaviour for anonymised logs which
log analysers can recognise and handle gracefully (as simple as
specifying a standard character, like "-", to be placed in that column).
We could also define a half-way format, where a compact hash of the IP is
logged, so that unique visitor statistics can be calcualted for those
who want them, or e.g. malfunctioning bots can be spotted, but nothing.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 12 20:27:09 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 12 May 2020 19:27:09 +0000
Subject: Search GUS by content type!
In-Reply-To: <20200509181241.GA161718@goldfish.localdomain>
References: <20200509181241.GA161718@goldfish.localdomain>
Message-ID: <20200512192708.GF16945@SDF.ORG>

Hi Natalie,

This is a great addition to GUS, thanks very much!  I hadn't realised
there was as much audio content on Gemini already as there is.

I'm really pleased that search for Gemini is already lightyears ahead of
where it is for Gopherspace, despite Gopherspace having a head start of
several decades!

Looking forward to further development of GUS.

Cheers,
Solderpunk

On Sat, May 09, 2020 at 02:12:41PM -0400, Natalie Pendragon wrote:
> Hi everyone,
> 
> I just wanted to share a nice update on GUS. After some discussion
> with sloum, I decided to put some time into better support for content
> types.
> 
> Content types been being printed alongside search results for a few
> weeks already, but I'm happy to announce that as of today you also get
> first-class support for them in your queries! There is documentation
> for how to use them at gemini://gus.guru/about, along with a number of
> useful content types to try out, like audio, image, and text.
> 
> One of my favorite so far is `audio`. You could search for, say,
> `content_type:audio` to find ALL music in Geminispace, or `dogs
> content_type:audio/mp3` to find some good songs about dogs in mp3
> format.
> 
> Thank you for all the feedback on this project so far. I still have a
> nice list of TODOs for GUS, mostly due to conversations with other
> Geminauts.
> 
> Nat

From solderpunk at SDF.ORG  Tue May 12 20:44:43 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 12 May 2020 19:44:43 +0000
Subject: Welcome, newcomers!
Message-ID: <20200512194443.GH16945@SDF.ORG>

Greetings Gemininauts!

I just wanted to wish a warm welcome to all the new subscribers to this
list who have discovered Gemini in the wake of our recent exposure on
Hacker News and Lobste.rs.  I realise this is slightly overdue, but
perhaps this is a nice introduction to the relatively relaxed pace of
development here in Geminiland!  Not that we are opposed to getting
stuff done, but we are still a small community of volunteers and the
typical pace matches that reality.

New energy and new ideas are very welcome, so please feel free to jump
in to the mailing list and the community more broadly.

Unsurprisingly, given that you are the kind of people who read Hacker
News, many of you have already started on Gemini-related software
projects.  This is welcome, please keep us informed about them.
However, Gemini is probably already setting new world records for the
ratio of software implementations to available content for an internet
protocol!  More important than anything else for the growth of the
community and the refinement of the protocol is *content*.  Good content
will encourage people to install clients, check the place out, and
spread the word.  Ambitious content creation projects help us figure out
what the protocol's strong and weak points are and can help make sure
any future changes are based on real world experience and not trying to
anticipate the future.

Any and all content is good, but Gemini-exclusive content is better, and
content that isn't *about* Gemini is best of all.  There's nothing wrong
with writing about the protocol - I do it myself, in a gemlog dedicated
to the subject - but we don't want to become an insular community which
only talks about itself.  Adoption of the protocol by newcomers will be
much more likely if there's stuff in Geminispace which is of value or
interest for people who don't already know much about it.

If you want to get started publishing content in Geminispace, anybody on
this mailing list can email me an ssh public key in order to get sftp
access to a user directory at gemini.circumlunar.space, where you can
host anything which doesn't get me into legal hot water or bring the
project as a whole into ill repute.  There are other places out there
offering user accounts, too - explore the list of known hosts at
gemini://gemini.circumlunar.space/servers/.  However, be aware that many
of these places are pre-existing communities who have started offering
Gemini hosting alongside other servicces (like gopher or web hosting,
email, shell-based BBSes, etc).  Don't be rude and join one of these
places just for the free Geminispace if you have no intention in
genuinely participating in their broader community!  If the idea of a
"pubnix" or "tilde" community is wholy new to you, I strongly encourage
you to check it out!  Many of the earliest and most active
participants in Geminispace "come from" one of these communities, and
they might offer some insight into the perspectives, attitudes and
ideals which are prominent in Geminispace.

That's all from me for now.  Welcome once again, thanks for your time
and interest and thus far wholly positive comments and contributions to
this fledgling slice of the internet.  I hope you stick around!

Cheers,
Solderpunk


From sean at conman.org  Tue May 12 22:39:08 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 12 May 2020 17:39:08 -0400
Subject: Gemini server logging formats and practices
In-Reply-To: <20200512182315.GD16945@SDF.ORG>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
Message-ID: <20200512213908.GO7305@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Mon, May 11, 2020 at 05:21:01AM -0400, Sean Conner wrote:
>  
> >   But there's really not much to log, other than remote address, request,
> > status, and potentially the issuer/subject of any given certificate (and
> > even that might be optional).  
> 
> I agree, there's not much to log, far less than HTTP.  But there's some
> real utility in having, err, utilities which can parse a log and
> generate basic statistics an admin might like to know: most popular
> resources, frequent requests resulting in 51 Not Found responses,
> average requests per day.  And people are more likely to write things
> like this if there's one format to worry about and not one per server.
> 
> This isn't a hard side-project by any means.  Something very simple and
> easy to read into existing data processing tools, like a comma separated
> or tab separated value file with standardised names and/or order for the
> columns and an agreed-upon representation of time would do the trick.
> 
> I am understanding of and sympathetic towards both admins who want to
> log IPs for debugging or abuse-detection purposes and towards those who
> don't want to so they can (rightfully) boast about their severs' respect
> for privacy.  So the standard format should include a column for remote
> IP and also have a clearly defined behaviour for anonymised logs which
> log analysers can recognise and handle gracefully (as simple as
> specifying a standard character, like "-", to be placed in that column).
> We could also define a half-way format, where a compact hash of the IP is
> logged, so that unique visitor statistics can be calcualted for those
> who want them, or e.g. malfunctioning bots can be spotted, but nothing.

  Okay, here's the format I'm using, and some notes about it:

remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="/CN=AV-98 cert test" issuer="/CN=AV-98 cert test" 
remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/" bytes=3026 subject="" issuer=""

(NOTE: I'm blanking out the IP address)

  As stated before, I'm using syslog() for logging, so I'm not logging the
time since that's added by syslog().  The request, subject and issuer fields
are quoted, so any double quote that appears inside has to be escaped with
'\' [1].  The fields are named, so they are (assuming you know English)
self-describing (to a degree).  I include bytes, but that's because I have
that information (even for dynamic output) due to how I wrote the server.

  Aside from the time field (which could be added, but for me, would be
redundant since syslog() does that for me), I would say the pros of format
is:

	* it's self describing
	* technically, the fields could be in any order
	* the fields could be made optional
	* new fields can be added (parsers should ignore fields they don't know)
	* there are tools that already exist tha can handle field=value data
	  (for example, Splunk, which we use at work)

The cons:

	* it takes more space due to the field names
	* it's slightly more complex to parse [2]
	* the double quote will need to be escaped in some fields [2]

  Thinking about it, a tool to process logs could require a module (or
plugin) to handle reading the data, so for instance, I write a module for
this tool to handle GLV-1.12556, and you could write one for Molly Brown. 
The data these modules include should be (and format):

	timestamp	ISO-8601 format, e.g. 2020-05-12T17:33-0500
	remote address 	opaque token (could be IPv4, IPv6, hash value)
	request		string
	bytes		number

and optionally:

	client certificate issuer	string
	client certificate subject	string

  -spc (refuses to give up syslog)

[1]	Which for me, is handled automatically by Lua, the language my
	server is written in.  

[2]	But not horrible either.  If you use a CSV format, you have to deal
	with escaping commas that might appear in a field *anyway* [3].  At
	least with a TSV (tab-separated values) there's less chance of
	actual tabs being in the data, but you have to be careful when
	parsing to handle two consecutive tabs (or two consecutive commas
	when using CSV).

[3]	And if you think CSV is a well-defined format, you haven't been out
	much.

From dwh at vi.rs  Wed May 13 00:25:52 2020
From: dwh at vi.rs (Dave Huseby)
Date: Tue, 12 May 2020 16:25:52 -0700
Subject: Basic git clone over gemini:// working
In-Reply-To: <20200512181359.GC16945@SDF.ORG>
References: <93f3849a-88a2-4eb7-91b6-5d21aea6c515@www.fastmail.com>
 <20200512181359.GC16945@SDF.ORG>
Message-ID: <a405e60f-f349-4ab8-9191-ff56c61c0de7@www.fastmail.com>

So it does rely on the query parameters feature of Gemini urls but I supposed a gopher equivalent would be to encode the git command parameters as parts of the path just like how the document type is sometimes encoded as part of the url path.

Git is actually pretty modular and is easily adapted to new transport protocols. You just have to implement a "remote helper" binary that follows Git's pipe-fork API for remotes. It's documented in the Git documentation and there's article written about implementing them.

I wrote the absolutely bare minimum remote helper. And since Gemini is a read-only protocol, `git push` will never work. This is just useful for publishing git repos on Gemini sites. The server side could easily be added to the Gemini servers that support CGI scripts.

Cheers!
Dave

On Tue, May 12, 2020, at 11:13 AM, solderpunk wrote:
> Holy heck!  That is impressive and exciting.  I know essentially nothing
> about git internals.  To what extent does doing this rely on features of
> Gemini which have no equivalent in Gopher?  Or is this actually much
> simpler than I'm imagining it?
> 
> Cheers,
> Solderpunk
> 
> On Mon, May 11, 2020 at 06:32:45PM -0700, Dave Huseby wrote:
> > Howdy,
> > 
> > I got bored over the weekend and wrote a simple Git remote helper for the gemini protocol. I published it on github for now: https://github.com/dhuseby/git-remote-gemini.git  Once you have it built and installed in your PATH somewhere, you'll then be able to clone it from the its actual location here: gemini://vi.rs/git-remote-gemini.git
> > 
> > I did a short terminal capture of me cloning a repo over gemini: https://asciinema.org/a/y2QxPEbgHsiGh4Go1AuHTLT0D
> > 
> > To make this work, I had to hack up Pollux to respond to simple queries and run the appropriate Git commands on the server. The details are in the README.gemini file in the repo.
> > 
> > Cheers!
> > Dave
>

From audiodude at gmail.com  Wed May 13 01:28:48 2020
From: audiodude at gmail.com (Travis Briggs)
Date: Tue, 12 May 2020 17:28:48 -0700
Subject: Creating a Gemini site from an (advanced) Jekyll site
Message-ID: <CAMPYpA6vJ8LKx_sxp49_OhYKsSOBvrZVeXJhD8BRA8w0YfzOpA@mail.gmail.com>

Hello,

Thanks for the warm welcome in the other thread, solderpunk! I'm not sure
if I read about Gemini on HN, but probably around the same time, being on
tilde.club and other tildes.

I just wanted to share some of the work I did to create the content for
gemini://gem.bestalbumsintheuniverse.com.

This site has existed for a number of years now, and probably isn't updated
as much as it should be (like all blogs of course). My intuition was
confirmed by solderpunk's call to content in the other thread, that
Geminispace needs content that isn't about Gemini. So I thought I'd re-work
my album listings as .gmi files.

You can see the whole source of the website here:
https://github.com/audiodude/best-albums

Currently I am running Jetforce, since I am primarily a Javascript and
Python developer, though I have done Ruby as you can see in the repo linked
above.

The basic layout of the site is that it is a Jekyll site, but it uses
advanced features of Jekyll to create an albums.json file, which is then
dynamically loaded by the Javascript of the frontend of the website. For
the Gemini version, I decided to use Pandoc (https://pandoc.org/) to
convert from my markdown files into what is essentially plain text, but
with a custom template for putting a header hash and the like. Pandoc was
really convenient for this because it automatically reads YAML
"frontmatter" in Markdown files and makes them available in templates.

I then wrote a simple script to take the albums.json file and generate an
overall index.gmi file for the site (write_gemini_index.rb). Finally there
is a Makefile that ties it all together and generates best-albums.tgz,
which I then scp to the gemini host and copy to /var/gemini.

While I think a general purpose Jekyll -> Gemini converter would be useful
for people, I don't have any desire to attempt such a project based on 1)
not wanting to use Ruby and 2) the fact that Jekyll isn't particularly
extensible. I wonder if there is a project to be created adding plugins for
some other popular static site generator (Hugo? Gatsby?) to output Gemini
content.

Cheers,
-Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200512/0f387257/attachment.htm>

From dwh at vi.rs  Wed May 13 02:43:51 2020
From: dwh at vi.rs (Dave Huseby)
Date: Tue, 12 May 2020 18:43:51 -0700
Subject: Gemini server logging formats and practices
In-Reply-To: <20200512182315.GD16945@SDF.ORG>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
Message-ID: <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>

On Tue, May 12, 2020, at 11:23 AM, solderpunk wrote:
> I am understanding of and sympathetic towards both admins who want to
> log IPs for debugging or abuse-detection purposes and towards those who
> don't want to so they can (rightfully) boast about their severs' respect
> for privacy.

Thanks. This is how the HTTP protocol conversation should have gone back in 1989.

> We could also define a half-way format, where a compact hash of the IP is
> logged, so that unique visitor statistics can be calcualted for those
> who want them, or e.g. malfunctioning bots can be spotted, but nothing.

I think it may help to consider that the IP address of a sender is personally identifiable information and is not the server operator's to collect without consent. Right now the only thing we can do is willfully blind our servers. Eventually though, if all goes according to plan, Gemini servers will be running on a mixnet of some kind and they won't be able to track IP addresses because the source isn't mapped to anything in the real world. Users will appear to the server as first time users on every request. The only balance to be struck will be if the user offers a correlation identifier to the server for some reason, say to access some stored state they have on the server (e.g. their own plant in the cyber garden or whatever).

Accessing permissioned resources (i.e. 6X response codes) doesn't necessarily imply correlation of the user. Certainly the user can present the same cryptographic credentials on subsequent requests but a better design is to allow for pair-wise credentials that are ephemeral to each session and potentially ephemeral to each request. Currently TLS doesn?t allow for this mode of operation. Something like CurveCP with decentralized verifiable credentials is a superior solution for uncorrelatable confidentiality. 

Anyway, back to logging. I don't think it is our place as server operators to collect IP addresses without consent since it isn't our data. It is an unfortunate legacy of the existing IP network layer that will hopefully be overcome soon. I think the hashing of IP addresses for correlation is fine but I think it is fair to expect all server operators to notify their users that they are doing so.

I may sound extreme but if we want to make the internet better, our thinking has to first shift. 

Cheers!
Dave

From sean at conman.org  Wed May 13 04:06:30 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 12 May 2020 23:06:30 -0400
Subject: Gemini server logging formats and practices
In-Reply-To: <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
Message-ID: <20200513030630.GP7305@brevard.conman.org>

It was thus said that the Great Dave Huseby once stated:
> On Tue, May 12, 2020, at 11:23 AM, solderpunk wrote:
> > I am understanding of and sympathetic towards both admins who want to
> > log IPs for debugging or abuse-detection purposes and towards those who
> > don't want to so they can (rightfully) boast about their severs' respect
> > for privacy.
> 
> Thanks. This is how the HTTP protocol conversation should have gone back
> in 1989.

  Back in 1989, the Internet as we know it was still five years away. 
Commerical activity was against the rules and the only people who were on
the Internet back then where largely academics (students, instructors,
professors) at universities and a few researchers at some select companies
(like IBM, Sun or Symbolics).  I would think that had you seriously
presented this argument at the time, people might have looked at you
strangely.  While people were still largely trustful of other users, the
Morris Worm of Nov 1988 was still quite recent and if not for logging, it
would have taken much longer to stop.

> > We could also define a half-way format, where a compact hash of the IP is
> > logged, so that unique visitor statistics can be calcualted for those
> > who want them, or e.g. malfunctioning bots can be spotted, but nothing.
> 
> I think it may help to consider that the IP address of a sender is
> personally identifiable information and is not the server operator's to
> collect without consent. 

  So a not-so-hypothetical situation here---if I were to put on my Gemini
server "I LOG ALL THE IPS!", honestly, how could I get your consent (or
non-consent)?  I can't get it from you prior to your connection, because I
don't know you will connect.  I can't get your concent afterwards because I
already have your IP.  And would such a disclaimer have to be added to every
page?  How can you know prior to requesting a Gemini page that the server
will log your IP address?

  I'm not under the delusion that security is possible on the Internet, nor
privacy.  I've always operated under the assumption that anything I put on a
public server, *even with access controls,* is public [1].

  Yes, I'm a bit antagonistic towards such goals because I don't believe
that one can have a truly anonymous exchange of data over *any* medium, but
unfortunately, I don't have such a proof, other than---you need two
endpoints who of of each other such that data can be exchanged, and how do
you prove your identities (or repudate an identity, such as "I am NOT a FBI
agent")?  I think you can exchange data anonymously but you won't know who
is actually on the other end, or you can know, but so will an observer.  I
don't think you can get both.

> Right now the only thing we can do is willfully
> blind our servers. Eventually though, if all goes according to plan,
> Gemini servers will be running on a mixnet of some kind 

  Really?  I don't recall seeing such a plan myself.  Solderpunk, are you
holding out on me?

> and they won't be
> able to track IP addresses because the source isn't mapped to anything in
> the real world. 

  I know a lot of people use TOR for anonimity, but I feel that it's still
not 100% secure and that a state actor (like, oh, I don't know, China or the
United States) can, with enough resources, do a correlation attack on both
ingress and egress TOR points.  I mean, the authorities *say* they caught
the Dread Pirate Roberts on one mistake he made a few years earlier, but I
feel that the mistake was found *after* they knew who we really was, because
the US threw enough resources (legal and otherwise) into finding him.

> Accessing permissioned resources (i.e. 6X response codes) doesn't
> necessarily imply correlation of the user. Certainly the user can present
> the same cryptographic credentials on subsequent requests but a better
> design is to allow for pair-wise credentials that are ephemeral to each
> session and potentially ephemeral to each request. Currently TLS doesn?t
> allow for this mode of operation. Something like CurveCP with
> decentralized verifiable credentials is a superior solution for
> uncorrelatable confidentiality.

  So go ahead and implement it if you think it's possible.  

> Anyway, back to logging. I don't think it is our place as server operators
> to collect IP addresses without consent since it isn't our data. 

  Technically, the IP address you use to access a server isn't yours either. 
It's the providers.  They are just letting you use it.

> It is an
> unfortunate legacy of the existing IP network layer that will hopefully be
> overcome soon. 

  TOR?  Content addressible stuff with names like 9a793f67-3df1-45e2-a3f5-4b3166800102? 
Yeah, I'm not sold on that stuff.

> I think the hashing of IP addresses for correlation is fine
> but I think it is fair to expect all server operators to notify their
> users that they are doing so.

  Again, how?

  -spc

[1]	A few days ago, I was informed of a bug in my server where you could
	by-pass the certificate check with a malformed, but still accepted,
	request.

From dwh at vi.rs  Wed May 13 17:07:00 2020
From: dwh at vi.rs (Dave Huseby)
Date: Wed, 13 May 2020 09:07:00 -0700
Subject: Gemini server logging formats and practices
In-Reply-To: <20200513030630.GP7305@brevard.conman.org>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
Message-ID: <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>

I love your enthusiasm Sean. I'm going to reply in kind and call out when I'm trolling you. Just remember that I appreciate your position and thank you for sharing your perspective. I'm sincere as Fred Rogers when I say that. Now...let the trolling begin! Let's see who can flame each other better. ; )

On Tue, May 12, 2020, at 8:06 PM, Sean Conner wrote:
>   Back in 1989, the Internet as we know it was still five years away. 
> Commerical activity was against the rules and the only people who were on
> the Internet back then where largely academics (students, instructors,
> professors) at universities and a few researchers at some select companies
> (like IBM, Sun or Symbolics).  I would think that had you seriously
> presented this argument at the time, people might have looked at you
> strangely.  While people were still largely trustful of other users, the
> Morris Worm of Nov 1988 was still quite recent and if not for logging, it
> would have taken much longer to stop.

You're not wrong. I was. It was 1991, not 1989: 

=> http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1991.messages/1.html

Dismissive troll: The rest of what you said above is irrelevant, missing the point, and distracting.
 
>   So a not-so-hypothetical situation here---if I were to put on my Gemini
> server "I LOG ALL THE IPS!", honestly, how could I get your consent (or
> non-consent)?  I can't get it from you prior to your connection, because I
> don't know you will connect.  I can't get your concent afterwards because I
> already have your IP.  And would such a disclaimer have to be added to every
> page?  How can you know prior to requesting a Gemini page that the server
> will log your IP address?

You're not wrong. IP is what we have. You seemed to have completely missed that I'm making philosophical arguments.

>   I'm not under the delusion that security is possible on the Internet, nor
> privacy.  I've always operated under the assumption that anything I put on a
> public server, *even with access controls,* is public [1].

Humble swagger troll: Write better software. I'd be happy to teach you how you can have strong enough security without logging. You wrote your server in Lua. You put a lot of trust in the underlying C code. I personally wouldn't be comfortable with that situation. I'd also be willing to help you learn a real programming language like Rust. ; )

>   Yes, I'm a bit antagonistic towards such goals because I don't believe
> that one can have a truly anonymous exchange of data over *any* medium, but
> unfortunately, I don't have such a proof, other than---you need two
> endpoints who of of each other such that data can be exchanged, and how do
> you prove your identities (or repudate an identity, such as "I am NOT a FBI
> agent")?  I think you can exchange data anonymously but you won't know who
> is actually on the other end, or you can know, but so will an observer.  I
> don't think you can get both.

You're not wrong with what you think is the state of the world, so I understand why you're black pilled. However, it is theoretically possible to achieve both uncorrelatable and correlatable pseudonimity using stochastic mixnets as the routing mechanism on top of IP. I'll also soon publish my paper on what I call "Anon's Triangle" where I show that cryptographically provable contributions to open source projects can serve as a human-scale proof-of-work system for bootstrapping actual trust in a pseudonymous identity. If you throw in there, zero-knowledge proofs for verifiable claims, it's possible to shift authorization to be focused on *what* I am and not *who* I am. A good friend of mine likes to say: "I only care that the pilot is properly trained and fit to fly the plane. I don't care what their name is or anything else for that matter."

The problem has always been the lack of a global, trustworthy PKI. Just look at why GPG never took off or why Mobile IP isn't pervasive; it's the PKI problem. However, we now have standardized and ubiquitous PKI.

See:

=> https://w3c.github.io/did-core/
=> https://w3c-ccg.github.io/did-method-registry/
=> https://www.w3.org/TR/vc-data-model/
=> https://www.techrepublic.com/article/linux-foundation-will-host-the-trust-over-ip-foundation/

Time for you to catch up with the rest of us Sean. It's only a matter of time now. People--including me--are already working on a mixnet that leverages this. Once we unlock that achievement, Gemini will be able to stop relying on IP entirely.

Concern troll: I'm worried about you. Hopefully post-mixnet you'll have a better attitude about the state of the world. Stress kills y'know ; )

> > Right now the only thing we can do is willfully
> > blind our servers. Eventually though, if all goes according to plan,
> > Gemini servers will be running on a mixnet of some kind 
> 
>   Really?  I don't recall seeing such a plan myself.  Solderpunk, are you
> holding out on me?

You're not wrong. I made a mistake implying the Gemini had *anything* to do with my efforts fix the Internet status quo. i gave three, one-hour presentations last week at the Internet Identity Workshop and decided I was going to walk the walk and *not* publish my papers on the web. I grep'd the internet and discovered Gemini. I always disliked Gopher because of the ugly hack used to get text in Gopher index. Gemini fixed that elegantly and I'm a fan.
 
> > and they won't be
> > able to track IP addresses because the source isn't mapped to anything in
> > the real world. 
> 
>   I know a lot of people use TOR for anonimity, but I feel that it's still
> not 100% secure and that a state actor (like, oh, I don't know, China or the
> United States) can, with enough resources, do a correlation attack on both
> ingress and egress TOR points.  I mean, the authorities *say* they caught
> the Dread Pirate Roberts on one mistake he made a few years earlier, but I
> feel that the mistake was found *after* they knew who we really was, because
> the US threw enough resources (legal and otherwise) into finding him.

You're not wrong. It's well known that MIT researchers working for intelligence agencies mounted a pretty widespread attack again the Tor network and proved that statistical de-anonymization was possible.

=> https://www.extremetech.com/extreme/211169-mit-researchers-figure-out-how-to-break-tor-anonymity-without-cracking-encryption

My support for pseudonimity is a philosophical line in the sand. The only way for users to maintain leverage against surveillance capitalism to do all they can to maintain pseudonimity and privacy. My contributions to the Gemini community are mostly philosophical. There's no reason we have to do things the same way just because that's how it's always been done. Gemini is about being better than the web and gopher. Why should the Gemini protocol *settle* for the same bad/limited solutions that contributed to the dumpster fire that is the surveillance/propaganda system we call "the web."

> > Accessing permissioned resources (i.e. 6X response codes) doesn't
> > necessarily imply correlation of the user. Certainly the user can present
> > the same cryptographic credentials on subsequent requests but a better
> > design is to allow for pair-wise credentials that are ephemeral to each
> > session and potentially ephemeral to each request. Currently TLS doesn?t
> > allow for this mode of operation. Something like CurveCP with
> > decentralized verifiable credentials is a superior solution for
> > uncorrelatable confidentiality.
> 
>   So go ahead and implement it if you think it's possible.

It is. I am.
 
> > Anyway, back to logging. I don't think it is our place as server operators
> > to collect IP addresses without consent since it isn't our data. 
> 
>   Technically, the IP address you use to access a server isn't yours either. 
> It's the providers.  They are just letting you use it.

You're not wrong.

Troll: Again, you're answering a philosophical argument with a technical one. I'm starting to think you're uncomfortable discussing philosophy and always run to the comfort of black and white, right angles and straight jackets....I mean straight walls. ; )

When I send you a packet, my computer fills in the source IP address. That source IP address is personally identifiable information the vast majority of the time. It's the same as me filling in my address on an envelope. I may rent, and not own, the house--and therefore the address--that I live in but legally, my address is considered personally identifiable information (PII) and protected under the GDPR and CCPA. I'm suggesting that to gain a consistent and coherent philosophy about user sovereignty to make the internet better with truly decentralized systems, we should all start thinking of IP addresses as PII and build/configure systems accordingly.

I'll repeat myself: 

> > It is an
> > unfortunate legacy of the existing IP network layer that will hopefully be
> > overcome soon. 
 
>   TOR?  Content addressible stuff with names like 
> 9a793f67-3df1-45e2-a3f5-4b3166800102? 
> Yeah, I'm not sold on that stuff.

Troll: You're not a lost cause then. ; )

> > I think the hashing of IP addresses for correlation is fine
> > but I think it is fair to expect all server operators to notify their
> > users that they are doing so.
> 
>   Again, how?

You're not wrong, with the world it is now. Digest functions are one way. If I intentionally blind myself by using salted hashes of IP's first, it is theoretically impossible for me to take those hashes and get the pre-image IP address that could de-anonymize the client. As we work to make the internet better we have to be conscious of every possible way our design decisions affect user sovereignty.

Thanks for your reply Sean. It was fun replying to you. I understand what you're saying and you're not wrong with all of your technical details. But I was speaking in philosophical terms as guiding principles for making decisions going forward. I reject the current status quo. I only look back to remind myself of what went wrong but all of my energy is focused ahead of me. I think Aaron's quote is apropos here:

"What is the most important thing you could be working on in the world right now? ... And if you're not working on that, why aren't you?"

Troll: maybe you should work on learning Rust and meditating ; )

Cheers!
Dave

From solderpunk at SDF.ORG  Wed May 13 22:10:08 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 13 May 2020 21:10:08 +0000
Subject: Alternative transports, philosophy [was: Gemini server logging
 formats and practices]
In-Reply-To: <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG>
 <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
Message-ID: <20200513211008.GA18145@SDF.ORG>

On Wed, May 13, 2020 at 09:07:00AM -0700, Dave Huseby wrote:
> Now...let the trolling begin! Let's see who can flame each other better. ; )

It would be great if we could just refrain from trolling or flaming
each other entirely -- even weird, happy-smiley pseudo-trolling -- and
just have normal conversations, which can of course include polite and
adult disagreement!

Just weighing in on a few points quickly:
 
> > > Right now the only thing we can do is willfully
> > > blind our servers. Eventually though, if all goes according to plan,
> > > Gemini servers will be running on a mixnet of some kind 
> > 
> >   Really?  I don't recall seeing such a plan myself.  Solderpunk, are you
> > holding out on me?
> 
> You're not wrong. I made a mistake implying the Gemini had *anything* to do
> with my efforts fix the Internet status quo.

I'll admit that I've never given serious thought to alternative
transports, but the spec *does* take care to say "When Gemini is served
over TCP/IP, servers should listen on port 1965", implying that it might
be done over things other than TCP/IP.  I could have *sworn* I also
explicitly called it an "application layer" protocol, but apparently not.
I *will* fix that, it's always been my intent.

If people want to run Gemini over some sort of new-fangled mixnet
transport layer that's absolutely fine by me, and I'd regard such
experiments with keen interest.  But as far as I'm concerned that's
largely orthogonal to the Gemini spec proper.

To some extent, the spec privileges TCP/IP, or rather transport and
internet layer protocols which don't provide any encryption.  TLS is
designed in deeply enough that removing it would be problematic, which
means means that there is guaranteed to be some redundancy if the
higher layers provide security features of their own.

I would rather address this when and if any such alternative layers
achieve significant traction by introducing a separate, relatively
simple new specification - in the spirit of DNS over TLS or HTTP -
rather than trying to totally generalise the spec now.  If these new
layers are so radically different that refactoring Gemini to work over
them isn't trivial, then people can just define a new protocol native to
that transport which is heavily Gemini-inspired, in the way that Gemini
is heavily Gopher-inspired.

This reflects my general stance on the appropriate balance for Gemini
to strike between philosophical and technical considerations.  I don't
think it will come as a surprise to anybody that I'm an idealist.  I am
interested in making the internet a better place, and I consider Gemini
to be doing precisely that.  However, I have pretty humble ambitions
with this project.

By the standards of a lot of projects concerned with "making the
internet a better place", Gemini looks decidedly old-fashioned or
conservative.  It's client-server and not peer-to-peer, content is
hosted in one place on the originating server and is not replicated
across requesting clients, and stuff is addressed by location and not
content.  Heck, it doesn't even have a blockchain in it!

These decisions obviously place a limit on just how revolutionary we can
be in fixing the ills of the web.  But I also think these decisions are
one of Gemini's great strengths.  Gemini should feel overwhelmingly
familiar to most technical people, both in terms of the primitives it's
built from (URLs, MIME types, TLS) and the conceptual ideas that join
them together.  I think this fact is in no small part responsible for
Gemini, despite being small and young, already having no shortage of
implementations.  Meanwhile, the internet is full of - and has been for
a long, long time - more ambitious, radical projects with a lot more
"cognitive friction" which haven't taken off.

I welcome input from hardcore idealists and philosophers, because I
think it's good to keep one eye on the stars (an appropriate
metaphor for this project!).  But I'm going to meet those ideals
only as far as I think we can while keeping Gemini conceptually light
and easy for people to pickup and begin working with.  We won't
completely solve every single problem with the web this way, but
we'll make real improvements.  Incremental progress is still progress,
and widely-deployed progress is the best kind.

Cheers,
Solderpunk


From sean at conman.org  Wed May 13 22:58:20 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 13 May 2020 17:58:20 -0400
Subject: Gemini server logging formats and practices
In-Reply-To: <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
Message-ID: <20200513215820.GR7305@brevard.conman.org>

It was thus said that the Great Dave Huseby once stated:
> I love your enthusiasm Sean. I'm going to reply in kind and call out when
> I'm trolling you. Just remember that I appreciate your position and thank
> you for sharing your perspective. I'm sincere as Fred Rogers when I say
> that. Now...let the trolling begin! Let's see who can flame each other
> better. ; )
> 
> On Tue, May 12, 2020, at 8:06 PM, Sean Conner wrote:
> >   Back in 1989, the Internet as we know it was still five years away. 
> > Commerical activity was against the rules and the only people who were on
> > the Internet back then where largely academics (students, instructors,
> > professors) at universities and a few researchers at some select companies
> > (like IBM, Sun or Symbolics).  I would think that had you seriously
> > presented this argument at the time, people might have looked at you
> > strangely.  While people were still largely trustful of other users, the
> > Morris Worm of Nov 1988 was still quite recent and if not for logging, it
> > would have taken much longer to stop.
> 
> You're not wrong. I was. It was 1991, not 1989: 
> 
> => http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1991.messages/1.html
> 
> Dismissive troll: The rest of what you said above is irrelevant, missing
> the point, and distracting.
>  
> >   So a not-so-hypothetical situation here---if I were to put on my Gemini
> > server "I LOG ALL THE IPS!", honestly, how could I get your consent (or
> > non-consent)?  I can't get it from you prior to your connection, because I
> > don't know you will connect.  I can't get your concent afterwards because I
> > already have your IP.  And would such a disclaimer have to be added to every
> > page?  How can you know prior to requesting a Gemini page that the server
> > will log your IP address?
> 
> You're not wrong. IP is what we have. You seemed to have completely missed
> that I'm making philosophical arguments.

  I come across people who make grand statements like yours.  Such as
Stanislav:

	The Loper OS Project aims to remake computing. I am aware that
	others have tried and failed. Laughing? The job is not nearly as
	difficult as it sounds.  Much of the complexity found in modern
	systems software is accidental, rather than inherent. A large
	portion of my thinking has gone into figuring out what parts of an
	operating system are non-axiomatic - vestiges from a computational
	Stone Age which could safely be swept away.

		http://www.loper-os.org/?p=4#selection-33.0-41.338

(written in 2007; he's still writing at his blog today, but no Loper OS). 
There was Fran?ois-Ren? Rideau Dang-Vu B?n with his TUNES operating system:

	TUNES is a project to replace existing Operating Systems, Languages,
	and User Interfaces by a completely rethought Computing System,
	based on a correctness-proof-secure higher-order reflective
	self-extensible fine-grained distributed persistent fault-tolerant
	version-aware decentralized (no-kernel) object system.

		http://tunes.org/papers/WhyNewOS/WhyNewOS.html

(I recall when it was first announced in 1992---I thought it was silly back
then; again, TUNES is no longer).  Then there's Richard Kulisz:

	PlanNine has modularity, composability, distribution and half of
	uniformity. You can also include reliability.

	Unix has only modularity and many people seem to act like it's the
	"best OS of all time."

	ErosOs satisfies Reliability, TransparentPersistence and most of
	security.  It doesn't seem to give very practical security.

	BlueAbyss aims to satisfy all of the principles to the utmost,
	except for Correctness Proofs, which I see as a costly fad that adds
	little value.

		https://wiki.c2.com/?OperatingSystemsDesignPrinciples

(again, grand plans and not much to show for it years later).  And finally
to round out these examples, I present Curtis Yarvin and Urbit---and I still
can't decide if it's an elaborate troll or an earnest endevour, but Urbit
was introduced with this:

	This spec defines one function, Nock.

	2 Structures

	A noun is an atom or a cell.  An atom is any unsigned integer.
	A cell is an ordered pair of any two nouns.

	3 Pseudocode

	Brackets enclose cells.  [a b c] is [a [b c]].

	*a is Nock(a).  Reductions match top-down.

	4 Reductions

	?[a b]           => 0
	?a               => 1

	^[a b]           => ^[a b]
	^a               => (a + 1)

	=[a a]           => 0
	=[a b]           => 1
	=a               => =a

	/[1 a]           => a
	/[2 a b]         => a
	/[3 a b]         => b
	/[(a + a) b]     => /[2 /[a b]]
	/[(a + a + 1) b] => /[3 /[a b]]
	/a               => /a

	*[a 0 b]         => /[b a]
	*[a 1 b]         => b
	*[a 2 b c d]     => *[a 3 [0 1] 3 [1 c d] [1 0] 3 [1 2 3] [1 0] 5 5 b]
	*[a 3 b]         => **[a b]
	*[a 4 b]         => ?*[a b]
	*[a 5 b]         => ^*[a b]
	*[a 6 b]         => =*[a b]
	*[a [b c] d]     => [*[a b c] *[a d]]
	*a               => *a

		https://www.unqualified-reservations.org/2010/01/maxwells-equations-of-software/

And further elaborates:

	Urbit is a static functional namespace: a programming environment
	specified as a single stateless, frozen function. The Urbit function
	is Maxwellian: formally defined by a small system of axioms. Urbit,
	while a cool toy, is designed for practical computing.

		https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html

(and it seems to have become A Thing at https://urbit.org/, although Curtis
is no longer associated with the project).

  I present these examples (and there are more I have saved) as a means of
explanation---I come across these grand sweeping statements that we're doing
this all wrong and we must, MUST! change how it all works because the
current way is (to be charitable) not optimum!  And in all these cases, it's
all words, no implementation (except for Urbit, but even they cheat by not
using Nock but "optimizing" it with native code).

  Your message came across exactly like that to me---IP is bad, we must use
this other technology now!

  And I will admit that my reply might have been a bit incendiary.

> Time for you to catch up with the rest of us Sean. It's only a matter of
> time now. People--including me--are already working on a mixnet that
> leverages this. Once we unlock that achievement, Gemini will be able to
> stop relying on IP entirely.

  I'll patiently await the results.  <troll>Hopefully it won't take as long
as TUNES, Loper OS, Blue Abyss, or Urbit.</troll>

> Concern troll: I'm worried about you. Hopefully post-mixnet you'll have a
> better attitude about the state of the world. Stress kills y'know ; )

  I know.  Thanks.

> You're not wrong. I made a mistake implying the Gemini had *anything* to
> do with my efforts fix the Internet status quo. i gave three, one-hour
> presentations last week at the Internet Identity Workshop and decided I
> was going to walk the walk and *not* publish my papers on the web. 

  Good for you.  At least now I know you are serious enough to work on this.

> My support for pseudonimity is a philosophical line in the sand. The only
> way for users to maintain leverage against surveillance capitalism to do
> all they can to maintain pseudonimity and privacy. My contributions to the
> Gemini community are mostly philosophical. There's no reason we have to do
> things the same way just because that's how it's always been done. 

  True enough, but the issue I have is people questioning the design and
declaring it should have been done another way, *without doing any work*. 
Not even a proof-of-concept.

  When solderpunk first designed the protocol, I had a problem with the then
defined status codes.  I ignored that aspect when writing the first server,
opting instead to reuse HTTP codes.  That lead to a long discussion and
finally the design we have.  But the crutial point is that *there was code!*

> > > Anyway, back to logging. I don't think it is our place as server operators
> > > to collect IP addresses without consent since it isn't our data. 
> > 
> >   Technically, the IP address you use to access a server isn't yours either. 
> > It's the providers.  They are just letting you use it.
> 
> You're not wrong.
> 
> Troll: Again, you're answering a philosophical argument with a technical
> one. I'm starting to think you're uncomfortable discussing philosophy and
> always run to the comfort of black and white, right angles and straight
> jackets....I mean straight walls. ; )

  My best friend has a degree in Philosophy, so I'm not unconfortable with
it.  But there comes a time when Reality comes knocking at the door ...

> When I send you a packet, my computer fills in the source IP address. That
> source IP address is personally identifiable information the vast majority
> of the time. It's the same as me filling in my address on an envelope. I
> may rent, and not own, the house--and therefore the address--that I live
> in but legally, my address is considered personally identifiable
> information (PII) and protected under the GDPR and CCPA. I'm suggesting
> that to gain a consistent and coherent philosophy about user sovereignty
> to make the internet better with truly decentralized systems, we should
> all start thinking of IP addresses as PII and build/configure systems
> accordingly.

  And that's easy to say.  It's another thing to implement it.

> Thanks for your reply Sean. 

  You're welcome.

> It was fun replying to you. I understand what
> you're saying and you're not wrong with all of your technical details. But
> I was speaking in philosophical terms as guiding principles for making
> decisions going forward. I reject the current status quo. I only look back
> to remind myself of what went wrong but all of my energy is focused ahead
> of me. I think Aaron's quote is apropos here:
> 
> "What is the most important thing you could be working on in the world
> right now? ... And if you're not working on that, why aren't you?"

  Was that Aaron Swartz?

> Troll: maybe you should work on learning Rust and meditating ; )

  Rusty meditation?  What are you on about? 8-P

  -spc

From shufei at riseup.net  Wed May 13 23:04:11 2020
From: shufei at riseup.net (Shufei)
Date: Wed, 13 May 2020 15:04:11 -0700
Subject: New Twin, Mobile?
Message-ID: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>

How do you do, fellow kids,

I am a new Gemini twin on GCS (thanks, Solderpunk!). Please do drop by. If you have any helpful hints on Gemini formatting, please let me know.

Is anyone working on a mobile client or knows a good way to read Gemini via mobile right now? I?d especially hope for a iOS client. So if you are working on such, please ping me.

Also, how does one open Gemini pages in Bombadillo? With Gemini:// it doesn?t like urls. Without, it opens as gopher. And it?s not documented in man yet.

Thanks!
Shufei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200513/3afe94b5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200513/3afe94b5/attachment.sig>

From gmym at coopdot.com  Thu May 14 00:14:27 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Thu, 14 May 2020 01:14:27 +0200
Subject: New Twin, Mobile?
In-Reply-To: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
Message-ID: <CAObwWNghPqSMC_GSq41Q6wgP=k1c6yztDN=WnDb-7sLL5b30KQ@mail.gmail.com>

Shufei <shufei at riseup.net> wrote:

> Also, how does one open Gemini pages in Bombadillo?  With Gemini:// it
> doesn?t like urls.  Without, it opens as gopher.  And it?s not documented
> in man yet.
>

Just writing this in a shell works for me:
$ bombadillo gemini://gemini.circumlunar.space

Entering command line mode with space bar also works:
<spc>gemini://gemini.circumlunar.space

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200514/9bb1e8a4/attachment.htm>

From visiblink at gmx.com  Thu May 14 02:27:18 2020
From: visiblink at gmx.com (Visiblink)
Date: Wed, 13 May 2020 18:27:18 -0700
Subject: New Twin, Mobile?
In-Reply-To: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
Message-ID: <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>

On 2020-05-13 3:04 p.m., Shufei wrote:
> How do you do, fellow kids,
>
> I am a new Gemini twin on GCS (thanks, Solderpunk!). Please do drop by. If you have any helpful hints on Gemini formatting, please let me know.
>
> Is anyone working on a mobile client or knows a good way to read Gemini via mobile right now? I?d especially hope for a iOS client. So if you are working on such, please ping me.
>
> Also, how does one open Gemini pages in Bombadillo? With Gemini:// it doesn?t like urls. Without, it opens as gopher. And it?s not documented in man yet.
>
> Thanks!
> Shufei
>

There is a mobile client for Android. You can find it at:
https://framagit.org/waweic/gemini-client

I have noticed that it does not work with *all* gemini servers (in
particular the gemlog at 80h.dev).

-v

From int at 80h.dev  Thu May 14 02:58:13 2020
From: int at 80h.dev (int 80h)
Date: Wed, 13 May 2020 21:58:13 -0400
Subject: New Twin, Mobile?
In-Reply-To: <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
Message-ID: <C2Q2WA498Y6L.15JPI9BYIE9IB@freebsd.lan>

On Wed May 13, 2020 at 2:27 PM EDT, Visiblink wrote:
> I have noticed that it does not work with *all* gemini servers (in
> particular the gemlog at 80h.dev).

I haven't checked the code but I wonder if it's not set to use sni? I
had that problem with another client before.

int 80h

From sean at conman.org  Thu May 14 07:12:39 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 02:12:39 -0400
Subject: New Twin, Mobile?
In-Reply-To: <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
 <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
Message-ID: <20200514061239.GU7305@brevard.conman.org>

It was thus said that the Great Visiblink once stated:
> 
> There is a mobile client for Android. You can find it at:
> https://framagit.org/waweic/gemini-client
> 
> I have noticed that it does not work with *all* gemini servers (in
> particular the gemlog at 80h.dev).

  I'm curious to know which servers don't work with it.

  -spc


From me at ecmelberk.com  Thu May 14 09:09:11 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Thu, 14 May 2020 11:09:11 +0300
Subject: Server software recommendations
Message-ID: <20200514110911.2c81f9fa@socimda>

Hello all!

I've been checking out the mailing list and reading about Gemini every
now and then, and decided to try and host a Gemini server for my blog.

One question I had is: Which server software is the most mature one?

On the software list [1], there is no description about the state and
feature set of any of the listed server software.

[1]: gemini://gemini.circumlunar.space/software/ 

I only need to serve static files, as everything else happens on a
static site generator before being uploaded.

I'd also like a server which supports multiple host names (vhosts?),
but that's mostly optional. (Browsing though the server software list,
most of them seem to only accept a single host in their configuration.)

Thanks in advance for any responses, and feel free to say no such thing
exists. I am not averse to trying to build my own :)

From sean at conman.org  Thu May 14 09:50:41 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 04:50:41 -0400
Subject: Server software recommendations
In-Reply-To: <20200514110911.2c81f9fa@socimda>
References: <20200514110911.2c81f9fa@socimda>
Message-ID: <20200514085039.GW7305@brevard.conman.org>

It was thus said that the Great Ecmel Berk Canl?er once stated:
> Hello all!
> 
> I've been checking out the mailing list and reading about Gemini every
> now and then, and decided to try and host a Gemini server for my blog.
> 
> One question I had is: Which server software is the most mature one?

  What do you mean by "most mature"?  By age, it's GLV-1.12556 (disclaimer:
I wrote it).  By feature set, it's a toss-up between GLV-1.12556:

		* support for any type of documents (from multiple directories)
		* CGI (both Gemini and HTTP specific, RFC-3875 compliant)
		* user directories
		* client certificate support
		* easy to extend with custom modules (if you know Lua)

and Gemserv:

		* support for any type of document
		* CGI (Gemini only, not quite RFC-3875 compliant)
		* user directories
		* reverse proxy
		* virtual hosts

Both have recent updates. By popularity, last time I checked, it was
JetForce (which also has had recent updates).  Of the three mentioned,
JetForce is in Python, Gemserv in Rust, and GLV-1.12556 in Lua.  The lack of
virtual hosting in GLV-1.12556 is because I lack experience in dealing with
server certificates with multple hosts, and because of that, I can't exactly
test that feature.

> On the software list [1], there is no description about the state and
> feature set of any of the listed server software.
> 
> [1]: gemini://gemini.circumlunar.space/software/ 
> 
> I only need to serve static files, as everything else happens on a
> static site generator before being uploaded.

  If that's the case, then most of the servers would probably work, it then
comes down to which language do you have available for compiling/running the
server.

  -spc

From fabrixxm at kirgroup.net  Thu May 14 09:56:30 2020
From: fabrixxm at kirgroup.net (Fabio)
Date: Thu, 14 May 2020 10:56:30 +0200
Subject: New Twin, Mobile?
In-Reply-To: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
Message-ID: <6UCBAQ.E7TX38SJERUW1@kirgroup.net>



Il giorno mer 13 mag 2020 alle 15:04, Shufei <shufei at riseup.net> ha 
scritto:
> How do you do, fellow kids,
> 
> Is anyone working on a mobile client or knows a good way to read 
> Gemini via mobile right now?  I?d especially hope for a iOS client. 
>  So if you are working on such, please ping me.
> 

> 
I'm about (as in "as soon I find some time") to port 
https://git.sr.ht/~fabrixxm/alrisha to SailfishOS. Not that will be 
useful to many people, but it will be a mobile client :D




From natpen at natpen.net  Thu May 14 13:09:07 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Thu, 14 May 2020 08:09:07 -0400
Subject: GUS questions
In-Reply-To: <wik2s-Yf4ZWXP_J0a3ummQkA31NERuFqMuTWDVrSihxDA0BWGMLgvRCakUq_XgpA0ds-Mjm2CeD4m-E1vxIoEVuzWkNrQC9CZKMxDZo_dSI=@protonmail.com>
References: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
 <20200505125113.GA148355@goldfish.localdomain>
 <wik2s-Yf4ZWXP_J0a3ummQkA31NERuFqMuTWDVrSihxDA0BWGMLgvRCakUq_XgpA0ds-Mjm2CeD4m-E1vxIoEVuzWkNrQC9CZKMxDZo_dSI=@protonmail.com>
Message-ID: <20200514120907.GA2791104@goldfish.localdomain>

Hi again,

Paging is now implemented! It will show up at the bottom of search
result pages that have more than one page and its usage should be
self-explanatory. Thanks for suggesting this, and providing your
thoughts on possible URL structuring for it - I went with your
idea!

Also, another small but interesting GUS update - I'm now computing
some basic statistics about Geminispace each time the index is built.
You can see the current index' statistics at the new statistics page
[1]. As time goes on, I think this will also become an interesting
source of longitudinal data.

Nat

[1] gemini://gus.guru/statistics

From jmcbray at carcosa.net  Thu May 14 13:49:48 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 14 May 2020 08:49:48 -0400
Subject: GUS questions
In-Reply-To: <20200514120907.GA2791104@goldfish.localdomain>
References: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
 <20200505125113.GA148355@goldfish.localdomain>
 <wik2s-Yf4ZWXP_J0a3ummQkA31NERuFqMuTWDVrSihxDA0BWGMLgvRCakUq_XgpA0ds-Mjm2CeD4m-E1vxIoEVuzWkNrQC9CZKMxDZo_dSI=@protonmail.com>
 <20200514120907.GA2791104@goldfish.localdomain>
Message-ID: <87ftc2d6kz.fsf@dorothy.carcosa.net>


> Also, another small but interesting GUS update - I'm now computing
> some basic statistics about Geminispace each time the index is built.
> You can see the current index' statistics at the new statistics page
> [1]. As time goes on, I think this will also become an interesting
> source of longitudinal data.

Your work on GUS is amazing. I'm so grateful that you're doing it.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Thu May 14 13:54:00 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 14 May 2020 08:54:00 -0400
Subject: New Twin, Mobile?
In-Reply-To: <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
 <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
Message-ID: <87eermd6dz.fsf@dorothy.carcosa.net>


Visiblink writes:

> There is a mobile client for Android. You can find it at:
> https://framagit.org/waweic/gemini-client

The Android client is coming along really well. The original question
was for iOS, though. Before the Android client came out, I thought that
the best way to Gemini on mobile was the web portal at
https://portal.mozz.us/.


--
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

From tiwesdaeg at tilde.pink  Thu May 14 13:35:45 2020
From: tiwesdaeg at tilde.pink (tiwesdaeg at tilde.pink)
Date: Thu, 14 May 2020 12:35:45 +0000
Subject: Server software recommendations
In-Reply-To: <20200514085039.GW7305@brevard.conman.org>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
Message-ID: <20200514123545.vdx2gwzhytp5risg@tilde.pink>


I have found both of these servers very difficult to install. With
gemserv, I tried debian's packaged rust, rustup, and rustup nightly.
All failed for different interesting reasons. I could never get the
dependencies sorted out for GLV-1.12556.

Jetforce is very easy to install with pip, which is probably why it's
the most used server currently.

I'm using molly-brown currently, because I like how it handles user
public_gemini directories. Full cgi support would be nice.

Thanks for all the hard work all you software developers are doing!

On Thu, May 14, 2020 at 04:50:41AM -0400, Sean Conner wrote:
> It was thus said that the Great Ecmel Berk Canl?er once stated:
> > Hello all!
> > 
> > I've been checking out the mailing list and reading about Gemini every
> > now and then, and decided to try and host a Gemini server for my blog.
> > 
> > One question I had is: Which server software is the most mature one?
> 
>   What do you mean by "most mature"?  By age, it's GLV-1.12556 (disclaimer:
> I wrote it).  By feature set, it's a toss-up between GLV-1.12556:
> 
> 		* support for any type of documents (from multiple directories)
> 		* CGI (both Gemini and HTTP specific, RFC-3875 compliant)
> 		* user directories
> 		* client certificate support
> 		* easy to extend with custom modules (if you know Lua)
> 
> and Gemserv:
> 
> 		* support for any type of document
> 		* CGI (Gemini only, not quite RFC-3875 compliant)
> 		* user directories
> 		* reverse proxy
> 		* virtual hosts
> 
> Both have recent updates. By popularity, last time I checked, it was
> JetForce (which also has had recent updates).  Of the three mentioned,
> JetForce is in Python, Gemserv in Rust, and GLV-1.12556 in Lua.  The lack of
> virtual hosting in GLV-1.12556 is because I lack experience in dealing with
> server certificates with multple hosts, and because of that, I can't exactly
> test that feature.
> 
> > On the software list [1], there is no description about the state and
> > feature set of any of the listed server software.
> > 
> > [1]: gemini://gemini.circumlunar.space/software/ 
> > 
> > I only need to serve static files, as everything else happens on a
> > static site generator before being uploaded.
> 
>   If that's the case, then most of the servers would probably work, it then
> comes down to which language do you have available for compiling/running the
> server.
> 
>   -spc

From visiblink at gmx.com  Thu May 14 15:09:05 2020
From: visiblink at gmx.com (Visiblink)
Date: Thu, 14 May 2020 07:09:05 -0700
Subject: New Twin, Mobile?
In-Reply-To: <20200514061239.GU7305@brevard.conman.org>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
 <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
 <20200514061239.GU7305@brevard.conman.org>
Message-ID: <305389dd-94cc-38de-bad4-1b8146d1af72@gmx.com>

On 2020-05-13 11:12 p.m., Sean Conner wrote:
> It was thus said that the Great Visiblink once stated:
>>
>> There is a mobile client for Android. You can find it at:
>> https://framagit.org/waweic/gemini-client
>>
>> I have noticed that it does not work with *all* gemini servers (in
>> particular the gemlog at 80h.dev).
>
>    I'm curious to know which servers don't work with it.
>
>    -spc
>

I'll report any others when I use it next. So far that gemlog is the one
that stands out, because it's active and there are a lot of entries in
CAPCOM.

-v

From visiblink at gmx.com  Thu May 14 15:13:35 2020
From: visiblink at gmx.com (Visiblink)
Date: Thu, 14 May 2020 07:13:35 -0700
Subject: New Twin, Mobile?
In-Reply-To: <87eermd6dz.fsf@dorothy.carcosa.net>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
 <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
 <87eermd6dz.fsf@dorothy.carcosa.net>
Message-ID: <602d7178-91fd-2680-9039-93eb6246909b@gmx.com>

On 2020-05-14 5:54 a.m., Jason McBrayer wrote:
>
> The Android client is coming along really well. The original question
> was for iOS, though. Before the Android client came out, I thought that
> the best way to Gemini on mobile was the web portal at
> https://portal.mozz.us/.
>

Whoops. I didn't mean to hijack the thread if it was about iOS. I guess
I might have mis-read "especially" in the original post.

I'll enter any new comments on the Android app under a new subject heading.

From solderpunk at SDF.ORG  Thu May 14 15:45:13 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 14:45:13 +0000
Subject: GUS questions
In-Reply-To: <87ftc2d6kz.fsf@dorothy.carcosa.net>
References: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
 <20200505125113.GA148355@goldfish.localdomain>
 <wik2s-Yf4ZWXP_J0a3ummQkA31NERuFqMuTWDVrSihxDA0BWGMLgvRCakUq_XgpA0ds-Mjm2CeD4m-E1vxIoEVuzWkNrQC9CZKMxDZo_dSI=@protonmail.com>
 <20200514120907.GA2791104@goldfish.localdomain>
 <87ftc2d6kz.fsf@dorothy.carcosa.net>
Message-ID: <20200514144513.GA12880@SDF.ORG>

On Thu, May 14, 2020 at 08:49:48AM -0400, Jason McBrayer wrote:
 
> Your work on GUS is amazing. I'm so grateful that you're doing it.

I second this, big time!  It's fantastic to have such good search
support so early on in a project like this.  It's hugely appreciated.

Cheers,
Solderpunk

From felix at masterq32.de  Thu May 14 16:01:49 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Thu, 14 May 2020 17:01:49 +0200
Subject: Nice project!
Message-ID: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>

Hey all (and especially solderpunk)!

I've found gemini yesterday and i'm excited! It's nice to see that
people try to increase the surface of the web.

I hate a lot of stuff in the modern web, especially all that bloat,
tracking and unnecessary transmissions and i wanted to design a protocol
that doesn't allow this. Now i find that Gemini already did this and the
design is really well done!

I started implementing a gemini CLI client [0] in Zig that will work
similar to curl to allow command line fetches of files.

Maybe i'm even motivated enough to write a small browser with rendering
support for text/gemini...

Happy hacking, ya'll
- xq

[0] https://github.com/MasterQ32/gurl

From solderpunk at SDF.ORG  Thu May 14 16:08:11 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 15:08:11 +0000
Subject: Server software recommendations
In-Reply-To: <20200514123545.vdx2gwzhytp5risg@tilde.pink>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
 <20200514123545.vdx2gwzhytp5risg@tilde.pink>
Message-ID: <20200514150810.GB12880@SDF.ORG>

On Thu, May 14, 2020 at 12:35:45PM +0000, tiwesdaeg at tilde.pink wrote:
 
> I'm using molly-brown currently, because I like how it handles user
> public_gemini directories. Full cgi support would be nice.

I've been meaning to write a gemlog about this for ages, but never seem
to have the time...

GCI support in Molly Brown scares the pants off me.  Go doesn't reliably
support setuid() and this totally breaks all the standard pradigms of
unix server design.  In particular, I can find no way for MB to spawn a
CGI process which doesn't run as the same user as MB itself, and
therefore necessarily has the ability to read the TLS private key files
and write to the log file, which is obviously a massive security hole.
Because the MB process never runs as root, it's not possible to chroot
the CGI processes somewhere they couldn't see those files, either.

I'm frankly baffled that a language with Ken Thompson and Rob Pike as
designers, created specifically to help Google engineers write server
software, could turn out to be so terrible for...writing servers on
unix.  I can only imagine this has happened because nobody at Google
would ever do something so terribly mundane and non-scalable as fork
off an entire whole new process on the same machine to generate some
content.  Probably there'd be ten layers of containers and proxying and
reverse-proxying and other Cloudian faff keeping the content-generating
processes separated from the server processes so that uids were a quaint
and irrelevant consideration.

(if any Go wizards have recently joined the list and can correct me on
any of the above I'd be thrilled)

If you're just running your own server and you have control over the CGI
code, then go for it and be careful.  In a pubnix type environment where
you are letting third parties upload stuff, you basically need to be
extremely careful, use the configuration to restrict CGI to directories
writable only by people you really trust or will actively verify the
code of.

This was the reason that I pondered a few months back on this list some
kind of FastCGI-esque system for a Gemini server to communicate with a
process it didn't spawn itself over a domain socket or similar.  But
maybe I should just give up on Go for servers (this exact same issue
affects Shizaru, too.).

Cheers,
Solderpunk

> Thanks for all the hard work all you software developers are doing!
> 
> On Thu, May 14, 2020 at 04:50:41AM -0400, Sean Conner wrote:
> > It was thus said that the Great Ecmel Berk Canl?er once stated:
> > > Hello all!
> > > 
> > > I've been checking out the mailing list and reading about Gemini every
> > > now and then, and decided to try and host a Gemini server for my blog.
> > > 
> > > One question I had is: Which server software is the most mature one?
> > 
> >   What do you mean by "most mature"?  By age, it's GLV-1.12556 (disclaimer:
> > I wrote it).  By feature set, it's a toss-up between GLV-1.12556:
> > 
> > 		* support for any type of documents (from multiple directories)
> > 		* CGI (both Gemini and HTTP specific, RFC-3875 compliant)
> > 		* user directories
> > 		* client certificate support
> > 		* easy to extend with custom modules (if you know Lua)
> > 
> > and Gemserv:
> > 
> > 		* support for any type of document
> > 		* CGI (Gemini only, not quite RFC-3875 compliant)
> > 		* user directories
> > 		* reverse proxy
> > 		* virtual hosts
> > 
> > Both have recent updates. By popularity, last time I checked, it was
> > JetForce (which also has had recent updates).  Of the three mentioned,
> > JetForce is in Python, Gemserv in Rust, and GLV-1.12556 in Lua.  The lack of
> > virtual hosting in GLV-1.12556 is because I lack experience in dealing with
> > server certificates with multple hosts, and because of that, I can't exactly
> > test that feature.
> > 
> > > On the software list [1], there is no description about the state and
> > > feature set of any of the listed server software.
> > > 
> > > [1]: gemini://gemini.circumlunar.space/software/ 
> > > 
> > > I only need to serve static files, as everything else happens on a
> > > static site generator before being uploaded.
> > 
> >   If that's the case, then most of the servers would probably work, it then
> > comes down to which language do you have available for compiling/running the
> > server.
> > 
> >   -spc

From colecmac at protonmail.com  Thu May 14 16:10:56 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 14 May 2020 15:10:56 +0000
Subject: Alternative transports,
 philosophy [was: Gemini server logging formats and practices]
In-Reply-To: <20200513211008.GA18145@SDF.ORG>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG>
 <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
Message-ID: <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>

Thanks for clearing things up a bit, and dialing the troll level down.

As someone who's played around a fair bit with alternative
networks, I just want to point out (more to Dave than you) that TCP/IP,
and therefore Gemini, really shouldn't conflict with the idea of an
alternative, private, "mixnet" network. If I think about encrypted
mesh networks like CJDNS or Yggdrasil (maybe even TOR?), Gemini will
work completely out of the box on those networks, as long as your
servers and clients support IPv6. No need to redefine new protocols
or spec. The only inefficiency is that you also have TLS, when those
networks already mandate encryption, but that's not such an issue. I'm
happy that Gemini mandates it anyway, because most of its use will be
on the regular Internet.

> Meanwhile, the internet is full of - and has been for
> a long, long time - more ambitious, radical projects with a lot more
> "cognitive friction" which haven't taken off.

I like this point about cognitive friction a lot. The best kind of
technology is one that gets out of your way, and I think Gemini is on
its way to doing that. I like the simplicity of it, I think it'll allow
it to achieve so much.

makeworld

??????? Original Message ???????
On Wednesday, May 13, 2020 5:10 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Wed, May 13, 2020 at 09:07:00AM -0700, Dave Huseby wrote:
>
> > Now...let the trolling begin! Let's see who can flame each other better. ; )
>
> It would be great if we could just refrain from trolling or flaming
> each other entirely -- even weird, happy-smiley pseudo-trolling -- and
> just have normal conversations, which can of course include polite and
> adult disagreement!
>
> Just weighing in on a few points quickly:
>
> > > > Right now the only thing we can do is willfully
> > > > blind our servers. Eventually though, if all goes according to plan,
> > > > Gemini servers will be running on a mixnet of some kind
> > >
> > > Really? I don't recall seeing such a plan myself. Solderpunk, are you
> > > holding out on me?
> >
> > You're not wrong. I made a mistake implying the Gemini had anything to do
> > with my efforts fix the Internet status quo.
>
> I'll admit that I've never given serious thought to alternative
> transports, but the spec does take care to say "When Gemini is served
> over TCP/IP, servers should listen on port 1965", implying that it might
> be done over things other than TCP/IP. I could have sworn I also
> explicitly called it an "application layer" protocol, but apparently not.
> I will fix that, it's always been my intent.
>
> If people want to run Gemini over some sort of new-fangled mixnet
> transport layer that's absolutely fine by me, and I'd regard such
> experiments with keen interest. But as far as I'm concerned that's
> largely orthogonal to the Gemini spec proper.
>
> To some extent, the spec privileges TCP/IP, or rather transport and
> internet layer protocols which don't provide any encryption. TLS is
> designed in deeply enough that removing it would be problematic, which
> means means that there is guaranteed to be some redundancy if the
> higher layers provide security features of their own.
>
> I would rather address this when and if any such alternative layers
> achieve significant traction by introducing a separate, relatively
> simple new specification - in the spirit of DNS over TLS or HTTP -
> rather than trying to totally generalise the spec now. If these new
> layers are so radically different that refactoring Gemini to work over
> them isn't trivial, then people can just define a new protocol native to
> that transport which is heavily Gemini-inspired, in the way that Gemini
> is heavily Gopher-inspired.
>
> This reflects my general stance on the appropriate balance for Gemini
> to strike between philosophical and technical considerations. I don't
> think it will come as a surprise to anybody that I'm an idealist. I am
> interested in making the internet a better place, and I consider Gemini
> to be doing precisely that. However, I have pretty humble ambitions
> with this project.
>
> By the standards of a lot of projects concerned with "making the
> internet a better place", Gemini looks decidedly old-fashioned or
> conservative. It's client-server and not peer-to-peer, content is
> hosted in one place on the originating server and is not replicated
> across requesting clients, and stuff is addressed by location and not
> content. Heck, it doesn't even have a blockchain in it!
>
> These decisions obviously place a limit on just how revolutionary we can
> be in fixing the ills of the web. But I also think these decisions are
> one of Gemini's great strengths. Gemini should feel overwhelmingly
> familiar to most technical people, both in terms of the primitives it's
> built from (URLs, MIME types, TLS) and the conceptual ideas that join
> them together. I think this fact is in no small part responsible for
> Gemini, despite being small and young, already having no shortage of
> implementations. Meanwhile, the internet is full of - and has been for
> a long, long time - more ambitious, radical projects with a lot more
> "cognitive friction" which haven't taken off.
>
> I welcome input from hardcore idealists and philosophers, because I
> think it's good to keep one eye on the stars (an appropriate
> metaphor for this project!). But I'm going to meet those ideals
> only as far as I think we can while keeping Gemini conceptually light
> and easy for people to pickup and begin working with. We won't
> completely solve every single problem with the web this way, but
> we'll make real improvements. Incremental progress is still progress,
> and widely-deployed progress is the best kind.
>
> Cheers,
> Solderpunk



From colecmac at protonmail.com  Thu May 14 16:20:20 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 14 May 2020 15:20:20 +0000
Subject: GUS questions
In-Reply-To: <20200514120907.GA2791104@goldfish.localdomain>
References: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
 <20200505125113.GA148355@goldfish.localdomain>
 <wik2s-Yf4ZWXP_J0a3ummQkA31NERuFqMuTWDVrSihxDA0BWGMLgvRCakUq_XgpA0ds-Mjm2CeD4m-E1vxIoEVuzWkNrQC9CZKMxDZo_dSI=@protonmail.com>
 <20200514120907.GA2791104@goldfish.localdomain>
Message-ID: <OjszAqq2s3GauHsOrTHOnEFPR2ukCQ-dzfNkbRg92ZfzGqeSYF1llTJ-w7gC2LwG1WhH2fKNg-LfjqiCroi0n-8LiPXFQIKtedH9UQY0g_g=@protonmail.com>

Hello,

That's great to hear! Glad you liked my idea, and thanks
for continuing to develop GUS. It's an awesome resource to have.
The stats page looks great!

makeworld

??????? Original Message ???????
On Thursday, May 14, 2020 8:06 AM, Natalie Pendragon <natpen at natpen.net> wrote:

> Hi again,
>
> Paging is now implemented! It will show up at the bottom of search
> result pages that have more than one page and its usage should be
> self-explanatory. Thanks for suggesting this, and providing your
> thoughts on possible URL structuring for it - I went with your
> idea!
>
> Also, another small but interesting GUS update - I'm now computing
> some basic statistics about Geminispace each time the index is built.
> You can see the current index' statistics at the new statistics page
> [1]. As time goes on, I think this will also become an interesting
> source of longitudinal data.
>
> Nat
>
> [1] gemini://gus.guru/statistics



From stryan at saintnet.tech  Thu May 14 16:26:23 2020
From: stryan at saintnet.tech (Steve Ryan)
Date: Thu, 14 May 2020 11:26:23 -0400
Subject: Server software recommendations
In-Reply-To: <20200514150810.GB12880@SDF.ORG>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
 <20200514123545.vdx2gwzhytp5risg@tilde.pink>
 <20200514150810.GB12880@SDF.ORG>
Message-ID: <20200514152623.pwh5bsm3hgefixjl@vineta.saintnet.lan>

On 20/05/14 03:08PM, solderpunk wrote:
> I'm frankly baffled that a language with Ken Thompson and Rob Pike as
> designers, created specifically to help Google engineers write server
> software, could turn out to be so terrible for...writing servers on
> unix.  I can only imagine this has happened because nobody at Google
> would ever do something so terribly mundane and non-scalable as fork
> off an entire whole new process on the same machine to generate some
> content.  Probably there'd be ten layers of containers and proxying and
> reverse-proxying and other Cloudian faff keeping the content-generating
> processes separated from the server processes so that uids were a quaint
> and irrelevant consideration.
> 
> (if any Go wizards have recently joined the list and can correct me on
> any of the above I'd be thrilled)
> 

As an FYI, there's is a proposed patch[0] to add proper setuid dropping
for Golang. It's not through yet but is in review and testing stage.
Hopefully it'll make it in for 1.15.

Otherwise you're correct; all-thread setuid is done either through raw
syscalls and process forking wizardry, syscalls, wrapper programs, etc.

For my (also Golang) server SecretShop I've been handling it through the
systemd unit file. A bit messy, but I'm also not explictly supporting
multi-user deployments.

-Steve


[0] https://go-review.googlesource.com/c/go/+/210639

From jr at vrtz.ch  Thu May 14 16:26:22 2020
From: jr at vrtz.ch (Johannes von Rotz)
Date: Thu, 14 May 2020 17:26:22 +0200
Subject: Gemini Server in C
Message-ID: <dee9c074-fe18-0172-84d6-ae44ed912414@vrtz.ch>

Hi all

I'd also like to thank you for the warm welcome earlier this week. I
really feel excited about this project. I saw it as a nice opportunity
to start hacking again and threw together some C to resemble a Gemini
server.

It's in a very early stage and the code may not be very great, but it's
serving content! Feel free to comment and use it as you like:
https://github.com/jovoro/geminid/

Cheers, J.

From colecmac at protonmail.com  Thu May 14 16:28:16 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 14 May 2020 15:28:16 +0000
Subject: Nice project!
In-Reply-To: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
Message-ID: <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>

Hello!

Welcome! It's cool to have another command line tool for the ecosystem,
and Zig seems like an interesting language. I think you're the first
to make a Gemini tool with it!

I've made a command line downloader[0] myself, but having a more
advanced curl type tool would be great.

[0] https://github.com/makeworld-the-better-one/gemget

Also I see you're using wolfSSL, is it any good? I don't do much in C,
but there was some chatter in IRC the other day about BearSSL[1], maybe
it could be good for your project too.

[1] https://bearssl.org/


makeworld

??????? Original Message ???????
On Thursday, May 14, 2020 11:01 AM, Felix Quei?ner <felix at masterq32.de> wrote:

> Hey all (and especially solderpunk)!
>
> I've found gemini yesterday and i'm excited! It's nice to see that
> people try to increase the surface of the web.
>
> I hate a lot of stuff in the modern web, especially all that bloat,
> tracking and unnecessary transmissions and i wanted to design a protocol
> that doesn't allow this. Now i find that Gemini already did this and the
> design is really well done!
>
> I started implementing a gemini CLI client [0] in Zig that will work
> similar to curl to allow command line fetches of files.
>
> Maybe i'm even motivated enough to write a small browser with rendering
> support for text/gemini...
>
> Happy hacking, ya'll
>
> -   xq
>
>     [0] https://github.com/MasterQ32/gurl
>



From felix at masterq32.de  Thu May 14 16:36:22 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Thu, 14 May 2020 17:36:22 +0200
Subject: Nice project!
In-Reply-To: <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
 <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
Message-ID: <b3203cac-b866-acfb-c7f0-2c7749ff0201@masterq32.de>

Hey makeworld

> Welcome! It's cool to have another command line tool for the ecosystem,
> and Zig seems like an interesting language. I think you're the first
> to make a Gemini tool with it!
Yeah pretty much. The Zig community is still quite small, but constantly
growing and evolving :)

> I've made a command line downloader[0] myself, but having a more
> advanced curl type tool would be great.
> 
> [0] https://github.com/makeworld-the-better-one/gemget
Oh nice, reference code! I'm struggling with SSL atm, receiving my first
line of the response "20 text/gemini", but then i receive a "peer sent
close notify alert" from WolfSSL, so i might check out code code a bit
and the dependencies

> Also I see you're using wolfSSL, is it any good? I don't do much in C,
> but there was some chatter in IRC the other day about BearSSL[1], maybe
> it could be good for your project too.
> 
> [1] https://bearssl.org/
Taking a look now, it is already more attractive than WolfSSL as it's
MIT licence and not GPL. I've tried like 5 libraries yesterday and none
were either well documented, well working or well compilable, so giving
a shot now at BearSSL... WolfSSL was just the first library that got a
TLS connection established

Regards
xq

From colecmac at protonmail.com  Thu May 14 16:41:14 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 14 May 2020 15:41:14 +0000
Subject: Nice project!
In-Reply-To: <b3203cac-b866-acfb-c7f0-2c7749ff0201@masterq32.de>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
 <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
 <b3203cac-b866-acfb-c7f0-2c7749ff0201@masterq32.de>
Message-ID: <aq7jpQkviH-4qla7WBbdXF3r4ftBEJZ9xyeZmI57XlCUOTk9gsfxE1T7eTCug1JU077BG8p35nIhc5y0AWcUOPG8Fagig0EZ-zWK11HcZ4o=@protonmail.com>

> Oh nice, reference code!

Not really, I'm afraid - for TLS anyway. My project just uses a library
called go-gemini[0], but even that library just uses the Go TLS library
to make connections, the TLS connection is just one line. Hopefully the
code can help you in other ways? Best of luck.

[0] https://git.sr.ht/~yotam/go-gemini

makeworld


From luke.emmet at gmail.com  Thu May 14 16:55:56 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 14 May 2020 16:55:56 +0100
Subject: Cognitive aspects of navigation in gemini space
Message-ID: <5EBD6A0C.6090702@gmail.com>

Hello all

Just recently joined your email list after lurking for a while (via HN). 
I like the look of gemini, hopefully it can hit a sweet spot of simple 
hypertext without the baggage of the full web infrastructure. I think 
gemini is interesting. And I particularly have enjoyed reading the 
discussion about text formatting and bullets... no, seriously.

I'm interested in user interfaces and cognitive aspects of hypertext 
among other things.

My question is really about how we can support cognitive aspects of user 
navigation through gemini-space. I understand and largely endorse the 
reasons for the simple text based protocol and format. However at the 
moment, browsing gemini-space is a very homogenous experience (each page 
looks the same as others). So it is not so clear to the user whose page 
you are on.

On the wider web, there is a stronger notion of place, which has become 
very brand heavy and each website is a graphic masterpiece in its own 
right. There is a "cost" to that clearly.

Is there a simple and gemini-friendly way for us to (optionally!) convey 
this sense of place. For example, to set a simple global favicon or 
background colour for pages on a certain site. It could help with user's 
task of navigation and understanding exactly where they are. I know 
there are lots of CLI junkies around here, so maybe this hasn't been a 
priority so far.

I'm not proposing anything heavy or like the www, but I feel there could 
be some simple sweet spot here to be investigated.

Best wishes

   - Luke

From b__m__e at mailfence.com  Thu May 14 18:06:19 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Thu, 14 May 2020 19:06:19 +0200 (CEST)
Subject: Cognitive aspects of navigation in gemini space
Message-ID: <6204139.202339.1589475979277@ichabod.co-bxl>

> Just recently joined your email list after lurking for a while

Welcome! Glad to have you here (keep that in mind as I disagree with you below).

> Is there a simple and gemini-friendly way for us to (optionally!) convey 
> this sense of place.

At present I think Konpeito Media (gemini://konpeito.media) is a great example of providing what you are talking about. 
They offer color, as well as a non-color mode. Many gemini capsules also use figlet fonts or other forms of ascii and unicode
art.

My feeling is that gemini inherits more from gopher than from the web. Including a lot of the culture that has surrounded it in its early days.
That doesnt mean that things need to stay that way, though I admit my preference is to avoid styling almost entirely. Styling, to me, misses the
point: that the content is the important thing.

> browsing gemini-space is a very homogenous experience

I think I disagree with this. I think coming from the web, yes that may be true. But users that have been using gopher have had the
mental shift to interacting with this sort of content for quite some time and the subtle differences in how text is arranged can have
a big impact and really create a style and flavor for each capsule. It just takes a little distance from the maximalism that is the web.
People that drink a 2-litre of cola each day are used to sweet and think that a sparkling water with a bit of lime has no flavor. But if
you stop drinking soda for awhile your taste starts to return to a more normal realm. I think this is true of gemini and gopher as well
when contrasted with the web.



As you likely read in the discussions surrounding bullets, there is definitely nothing stopping servers and clients from serving up and 
rendering html or markdown and having the styling that comes with those. I cannot speak for everyone, but my feeling is that the
text/gemini format is intended to be very simple and to allow consistent display across devices (many of which do not support color
or font size changes).

I would definitely be interested to see if we can find some ways of achieving what you are talking about by creating a culture and 
community that finds creative ways to use text to really give gemini a feel of its own. While I cited Konpeito above, I know that
the escape sequence thing is a fun hack, but that graphical clients will have trouble.

I do think we should be providing alt text to ascii art blocks, maybe like so:

```smiley face

o    o
    .
\___/

```

Anyway, sorry for the opinionated ramble. Really: truly glad to have your voice in the discussion (as well as all of the other recent
new folks to this mailing list and to gemini in general).
--?
Sent with https://mailfence.com
Secure and private email

From solderpunk at SDF.ORG  Thu May 14 18:14:46 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 17:14:46 +0000
Subject: New Twin, Mobile?
In-Reply-To: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
References: <54922219-24b9-4d78-8be0-98956a63c6c1@Canary>
Message-ID: <20200514171446.GE10556@SDF.ORG>

On Wed, May 13, 2020 at 03:04:11PM -0700, Shufei wrote:
 
> I am a new Gemini twin on GCS (thanks, Solderpunk!).

No problem, glad you've gotten up and running!  Let me know if you want
a cron job running to generate an Atom feed for your Gmiphlog.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu May 14 18:18:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 17:18:15 +0000
Subject: New Twin, Mobile?
In-Reply-To: <C2Q2WA498Y6L.15JPI9BYIE9IB@freebsd.lan>
References: <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
 <C2Q2WA498Y6L.15JPI9BYIE9IB@freebsd.lan>
Message-ID: <20200514171815.GF10556@SDF.ORG>

On Wed, May 13, 2020 at 09:58:13PM -0400, int 80h wrote:
> On Wed May 13, 2020 at 2:27 PM EDT, Visiblink wrote:
> > I have noticed that it does not work with *all* gemini servers (in
> > particular the gemlog at 80h.dev).
> 
> I haven't checked the code but I wonder if it's not set to use sni? I
> had that problem with another client before.
> 

Somebody just asked me about this on Mastodon earlier today.

The spec so far does not mention SNI at all, which should definitely be
changed.

It seems to me like servers really ought to be tolerant of it not being
used, which implies having a designated default host.  But also that
clients really ought to be sending it.

Are there good reasons not to make SNI mandatory for clients?  If not
the spec could basically enforce Postel's law here, clients MUST use it
and servers MUST tolerate its absence...

Cheers,
Solderpunk
 

From solderpunk at SDF.ORG  Thu May 14 18:22:45 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 17:22:45 +0000
Subject: Server software recommendations
In-Reply-To: <20200514085039.GW7305@brevard.conman.org>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
Message-ID: <20200514172245.GH10556@SDF.ORG>

On Thu, May 14, 2020 at 04:50:41AM -0400, Sean Conner wrote:
 
>   What do you mean by "most mature"?  By age, it's GLV-1.12556 (disclaimer:
> I wrote it).  By feature set, it's a toss-up between GLV-1.12556:
> 
> 		* support for any type of documents (from multiple directories)
> 		* CGI (both Gemini and HTTP specific, RFC-3875 compliant)
> 		* user directories
> 		* client certificate support
> 		* easy to extend with custom modules (if you know Lua)
> 
> and Gemserv:
> 
> 		* support for any type of document
> 		* CGI (Gemini only, not quite RFC-3875 compliant)
> 		* user directories
> 		* reverse proxy
> 		* virtual hosts
> 
> Both have recent updates. By popularity, last time I checked, it was
> JetForce (which also has had recent updates).

Goodness, I'm getting left right behind!  Poor, neglected Molly Brown.
:(

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Thu May 14 18:36:39 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 17:36:39 +0000
Subject: Gemini Server in C
In-Reply-To: <dee9c074-fe18-0172-84d6-ae44ed912414@vrtz.ch>
References: <dee9c074-fe18-0172-84d6-ae44ed912414@vrtz.ch>
Message-ID: <20200514173639.GI10556@SDF.ORG>

Howdy,

Great, thanks for letting us know!  I've added it to the list of
software on the project gemini site.

Cheers,
Solderpunk

On Thu, May 14, 2020 at 05:26:22PM +0200, Johannes von Rotz wrote:
> Hi all
> 
> I'd also like to thank you for the warm welcome earlier this week. I
> really feel excited about this project. I saw it as a nice opportunity
> to start hacking again and threw together some C to resemble a Gemini
> server.
> 
> It's in a very early stage and the code may not be very great, but it's
> serving content! Feel free to comment and use it as you like:
> https://github.com/jovoro/geminid/
> 
> Cheers, J.

From solderpunk at SDF.ORG  Thu May 14 18:38:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 17:38:03 +0000
Subject: Server software recommendations
In-Reply-To: <20200514152623.pwh5bsm3hgefixjl@vineta.saintnet.lan>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
 <20200514123545.vdx2gwzhytp5risg@tilde.pink>
 <20200514150810.GB12880@SDF.ORG>
 <20200514152623.pwh5bsm3hgefixjl@vineta.saintnet.lan>
Message-ID: <20200514173803.GJ10556@SDF.ORG>

On Thu, May 14, 2020 at 11:26:23AM -0400, Steve Ryan wrote:
 
> As an FYI, there's is a proposed patch[0] to add proper setuid dropping
> for Golang. It's not through yet but is in review and testing stage.
> Hopefully it'll make it in for 1.15.

Ah, good to know!  Thanks very much for bringing this to my attention.
I'll keep a close eye on this and put off doing anything else with
dynamic content in Molly Brown until it's been accepted.

> Otherwise you're correct; all-thread setuid is done either through raw
> syscalls and process forking wizardry, syscalls, wrapper programs, etc.

Yeah, I'd seen a few examples of this black magic online but it didn't
seem like anything I wanted to put deep trust in.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Thu May 14 18:41:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 17:41:55 +0000
Subject: Nice project!
In-Reply-To: <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
 <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
Message-ID: <20200514174155.GK10556@SDF.ORG>

On Thu, May 14, 2020 at 03:28:16PM +0000, colecmac at protonmail.com wrote:
 
> Also I see you're using wolfSSL, is it any good? I don't do much in C,
> but there was some chatter in IRC the other day about BearSSL[1], maybe
> it could be good for your project too.

Ah, I'm glad people have discovered BearSSL!  I was planning to mention
it in a big TLS-related gemlog post later tonight.  Once again I'm
behind the curve on my own project!

Would this IRC chatter be in #gemini on tilde.chat?  Julien did tell me
about that channel but I have to admit I haven't poked my head in even
once yet (I'm not much of an IRCer).  Are people hanging out there
semi-regularly and discussing Gemini?  If so I'll make a mention of it
in the FAQ alongside this mailing list.

Does anybody whose IRC-handy feel like hosting logs on gemini://?

Cheers,
Solderpunk

> 
> [1] https://bearssl.org/
> 
> 
> makeworld
> 
> ??????? Original Message ???????
> On Thursday, May 14, 2020 11:01 AM, Felix Quei?ner <felix at masterq32.de> wrote:
> 
> > Hey all (and especially solderpunk)!
> >
> > I've found gemini yesterday and i'm excited! It's nice to see that
> > people try to increase the surface of the web.
> >
> > I hate a lot of stuff in the modern web, especially all that bloat,
> > tracking and unnecessary transmissions and i wanted to design a protocol
> > that doesn't allow this. Now i find that Gemini already did this and the
> > design is really well done!
> >
> > I started implementing a gemini CLI client [0] in Zig that will work
> > similar to curl to allow command line fetches of files.
> >
> > Maybe i'm even motivated enough to write a small browser with rendering
> > support for text/gemini...
> >
> > Happy hacking, ya'll
> >
> > -   xq
> >
> >     [0] https://github.com/MasterQ32/gurl
> >
> 
> 
> 

From lazar.michael22 at gmail.com  Thu May 14 18:50:11 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 14 May 2020 13:50:11 -0400
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <5EBD6A0C.6090702@gmail.com>
References: <5EBD6A0C.6090702@gmail.com>
Message-ID: <CAFTy05a9+qcQmd6wcugEWXf+nUa16H5KO-rLm=3jrc_m7eZYQg@mail.gmail.com>

On Thu, May 14, 2020 at 11:56 AM Luke Emmet <luke.emmet at gmail.com> wrote:
> Is there a simple and gemini-friendly way for us to (optionally!) convey
> this sense of place. For example, to set a simple global favicon or
> background colour for pages on a certain site. It could help with user's
> task of navigation and understanding exactly where they are. I know
> there are lots of CLI junkies around here, so maybe this hasn't been a
> priority so far.
>
> I'm not proposing anything heavy or like the www, but I feel there could
> be some simple sweet spot here to be investigated.

Hi!

I really appreciate that you brought up favicons. I've also been thinking
about how they might be a fun and useful way to give a bit of "personality"
to sites as they appear in bookmark lists, etc.

The original implementation of favicons on the web was so simple and nice.
Just plop a favicon.ico file in your root of your directory and you're
done! Now on the modern web, it's gotten complicated with every browser
having their own conventions on what the optimized size/format should be.
So you end up needing to use a tool to generate 8 different file formats
and link to them to using various <meta> tags in the page header.

I think utilizing unicode characters, specifically emojis, might be an
elegant solution to this problem. They're scalable to any resolution and
standard enough to provide a uniform experience across sites. A content
author wouldn't need to worry about their image being transparent or
looking like crap on higher resolutions, for example. And of course, they
would work on terminal clients too!

My proposed convention would be something like this

gemini://my-site.com/favicon.txt

This resource should be optional. If it exists, it should contain a single
unicode character (the exact semantics of what a "character" is would need
to be ironed out). Clients may chose to display this character alongside
links or in the page title bar.

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200514/6fa14bb3/attachment.htm>

From solderpunk at SDF.ORG  Thu May 14 19:21:04 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 18:21:04 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <5EBD6A0C.6090702@gmail.com>
References: <5EBD6A0C.6090702@gmail.com>
Message-ID: <20200514182104.GL10556@SDF.ORG>

Howdy,

On Thu, May 14, 2020 at 04:55:56PM +0100, Luke Emmet wrote:

> And I particularly have enjoyed reading the discussion about
> text formatting and bullets... no, seriously.

Seek help! :p

Just kidding, welcome to Gemini!
 
> My question is really about how we can support cognitive aspects of user
> navigation through gemini-space. I understand and largely endorse the
> reasons for the simple text based protocol and format. However at the
> moment, browsing gemini-space is a very homogenous experience (each page
> looks the same as others). So it is not so clear to the user whose page you
> are on.

I understand entirely where you are coming from.  An idea I've had for
a while now (I don't remember if I've mentioned it here before) is that
it would be nice if a graphical Gemini browser used a different
foreground and background colour (and perhaps even a different font?)
for different domains (subdomains)?  This would be something the client
would do itself, with no possibility of control or influence from the
server - it would just use the domain as the seed to a PRNG which chose
a new scheme.  This would then give different sites their own subtly
distinct look and feel, which a user could learn to recognise in time.
I have no idea how feasible this is: programmatically generating
genuinely pleasant colour schemes is certainly not straightforward.
 
> Is there a simple and gemini-friendly way for us to (optionally!) convey
> this sense of place. For example, to set a simple global favicon or
> background colour for pages on a certain site. It could help with user's
> task of navigation and understanding exactly where they are. I know there
> are lots of CLI junkies around here, so maybe this hasn't been a priority so
> far.

The idea of favicons has been mentioned before in a gemlog post:

gemini://mozz.us/journal/2020-04-17.gmi

I have a couple of big concerns here:

One is that right now Gemini is strictly one-request-per-resource and a
lot of people, myself included, consider that a really desirable
property.  Anything like favicons or CSS would remove that property, no
matter how light weight they were.  It's true that at least the second
request would go to the same server as the first so this doesn't
actually destroy predictability or control of which servers your client
connects to, which is one of the arguments in favour of the one request
thing.

Another is that, philosophically, I kind of feel like styling *should*
be under the control of the client and not the server.  Some people have
strong preferences for light text on dark backgrounds, for example,
because they have problems with eye strain the other way around.  Right
now on the web this is really only possible if the author deigns to
provide the option (as Stack Overflow recently did, to much fanfare).  I
think that's totally backwards.  Give the power over styling to the
people who actually have to read the content, let them read your stuff
in the way that works best for their eyesight and that *they* find
aesthetically pleasing.  I realise this reduces some of the scope for
self-expression on the part of Gemini content authors, but there's more
than enough scope for that in the actual *content* they produce (if not,
there are bigger problems...).

(of course, this is kind of a weak argument against CSS-light in Gemini,
because actually honouring the settings would be optional and clients 
could ignore them and use the user's preferences instead)

The biggest concern is (no surprises to regular readers here!) is that
it's really hard to do this in a way that's not extensible.  With the
best of intentions we'll specify a strictly optional CSS-ultralight
thing which can only choose background and foreground colours from a
small fixed pallette...and then some client will implement one extra
optional feature, and it'll be popular, so then other clients will copy
it, and the whole thing snowballs until people start to think of these
unofficial extensions as a real part of Gemini, and strictly
spec-adherent clients which don't support them as "broken".  This exact
story happened many times over with the web and I'm terrified of the
same things happening to Gemini.  It's why I've tried at every turn in
this project to avoid adding in anything that feels like it will be
really easy to extend in new directions.

I'm not opposed to hearing ideas, but I have a hard time imagining much
can be done in the way of ultralight optional styling which doesn't
violate the non-extensibility principle.

I'd be much more interested in us exploring innovative possibilities
which are strictly under the control of the client, like keying the
styling to the domain as I mentioned earlier.  I'm not saying that exact
approach necessarily is the best way to do it, or even a good way.  But
it's *a* way to do it which doesn't run afoul of any of the issues above
and that kind of out-of-the-box thinking is a good direction to take,
IMHO.

Hope you're not too disappointed by this response, feel free to
(politely, constuctively!) argue back against any of this.  Thanks for
your interest and welcome to Gemini!

Cheers,
Solderpunk


From tomasino at lavabit.com  Thu May 14 19:27:11 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 14 May 2020 18:27:11 +0000
Subject: Nice project!
In-Reply-To: <20200514174155.GK10556@SDF.ORG>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
 <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
 <20200514174155.GK10556@SDF.ORG>
Message-ID: <ca55487f-00fe-831e-8dd7-5e891c544e61@lavabit.com>

On 5/14/20 5:41 PM, solderpunk wrote:
> Does anybody whose IRC-handy feel like hosting logs on gemini://?

A few of us in the tildeverse #gemini room are discussing this now and
will have an IRC log backup on gemini:// in the near future. The rest of
you are all welcome to come chat with us there as well.

Learn more about our IRC server at https://tilde.chat/

or just connect at

irc.tildeverse.org/6697 (SSL)
#gemini

- tomasino


From dunderpate at sdf.org  Thu May 14 19:29:03 2020
From: dunderpate at sdf.org (Dunderpate)
Date: Thu, 14 May 2020 13:29:03 -0500
Subject: Any Windows clients?
Message-ID: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>

Hi everyone,

I just wanted to start out by thanking you all for a great project, spec
and community. It's great to see and hear other people with the same
desire for a simpler web.

I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm confined
to Windows for my day job :/ So, I was just wondering if anyone on this
list knows of a Windows client floating around that I could use.

Thanks everyone!
-- 
Dunderpate


From solderpunk at SDF.ORG  Thu May 14 19:33:27 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 18:33:27 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <6204139.202339.1589475979277@ichabod.co-bxl>
References: <6204139.202339.1589475979277@ichabod.co-bxl>
Message-ID: <20200514183327.GN10556@SDF.ORG>

On Thu, May 14, 2020 at 07:06:19PM +0200, Brian Evans wrote:
 
> I do think we should be providing alt text to ascii art blocks, maybe like so:

I've kind of wondered about this too.  Specifically, I started wondering
about this after the recent styling changes at typed-hole.org (sorry to
pick on you, Julien!).  The new figlet-generated (I assume?) section
headers look really great, but they're not great for accessibility (a
screen reader won't know how to read them) and they're not great for
searchability (a GUS search for words used in one of them won't turn up
results).

I'm kind of torn here.  A lot of folks are doing very cool things with
ASCII/ANSI art and colour escape codes in Geminispace.  I love the way
it looks, and coming from the Gopher culture myself I totally understand
and appreciate this urge.  I really don't want to publically condemn
these practices and seem like a creativity-destroying jerk who wants
Geminispace to be bland and depersonalised and black and white.

But there *are* a lot of non-trivial problems with this stuff: on top of
accessibility and searchability, Sean has mentioned potential security
problems with handling ANSI escape codes from untrusted sources...

Cheers,
Solderpunk

From tomasino at lavabit.com  Thu May 14 19:42:40 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 14 May 2020 18:42:40 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200514182104.GL10556@SDF.ORG>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
Message-ID: <e21c45ce-738b-8a4e-9e8c-49df164ea666@lavabit.com>

On 5/14/20 6:21 PM, solderpunk wrote:
> it would be nice if a graphical Gemini browser used a different
> foreground and background colour (and perhaps even a different font?)
> for different domains (subdomains)? 

That sounds like a really nice feature that some people would value in a
client that offered it. If, while browsing gemini, I could quickly set
the colors or styling on a domain level it could be neat to visually
separate places I go routinely. Some users might value that feature
enough to choose a client that offers it. Others wouldn't care.

Another option on the client level would be to hash the domain into a
color code of some sort, dynamically creating variation in the
backgrounds to a reasonable degree (shades of grey? below a certain
lumen?). That would give the user an obvious indication if a link
followed changed domains. Again, it might be of value to somebody and
others won't care.

We're getting a plethora of clients popping up. Maybe some of these new
ones want a way to differentiate themselves. I'd suggest that putting
any and all of these levels of control into the client's hands would be
great for gemini long term. The problems come when we want to solve
these things server-side.


From tomasino at lavabit.com  Thu May 14 19:47:39 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 14 May 2020 18:47:39 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200514183327.GN10556@SDF.ORG>
References: <6204139.202339.1589475979277@ichabod.co-bxl>
 <20200514183327.GN10556@SDF.ORG>
Message-ID: <f6eeaa5b-30bb-b213-10a3-b73c048e4dc4@lavabit.com>

On 5/14/20 6:33 PM, solderpunk wrote:
> he new figlet-generated (I assume?) section
> headers look really great, but they're not great for accessibility (a
> screen reader won't know how to read them) and they're not great for
> searchability (a GUS search for words used in one of them won't turn up
> results).

It's a really tough situation and you nailed it on the head. Code
fencing can be used for creative art or for literally preserving
whitespace on indexable content. It would be nice to indicate to both
screen readers and search engines which is which.

I hesitate to even offer a solution because it gets too close to our
heated code fencing & list markup discussion, but... As code fences
currently begin with ```
and end with
```

We could use the starting code fence to indicate whether the content is
art or not, or parseable as text or not.

```text

```art

or some ARIA-esque token.

I was originally thinking that the text following ``` could be a literal
alt text. I dunno. Just throwing out ideas.

solderpunk, please don't shoot me.


From solderpunk at SDF.ORG  Thu May 14 19:55:10 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 18:55:10 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <CAFTy05a9+qcQmd6wcugEWXf+nUa16H5KO-rLm=3jrc_m7eZYQg@mail.gmail.com>
References: <5EBD6A0C.6090702@gmail.com>
 <CAFTy05a9+qcQmd6wcugEWXf+nUa16H5KO-rLm=3jrc_m7eZYQg@mail.gmail.com>
Message-ID: <20200514185510.GO10556@SDF.ORG>

On Thu, May 14, 2020 at 01:50:11PM -0400, Michael Lazar wrote:
 
> This resource should be optional. If it exists, it should contain a single
> unicode character (the exact semantics of what a "character" is would need
> to be ironed out). Clients may chose to display this character alongside
> links or in the page title bar.

Huh!  That is pretty non-extensible!  Compared to something like a file
full of key=value pairs for CSS-like properties, I mean.

Cheers,
Solderpunk

From b__m__e at mailfence.com  Thu May 14 19:57:50 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Thu, 14 May 2020 20:57:50 +0200 (CEST)
Subject: Cognitive aspects of navigation in gemini space
Message-ID: <345770818.210897.1589482670266@ichabod.co-bxl>

Tomasino writes:
> We could use the starting code fence to indicate whether the content is
> art or not, or parseable as text or not.

I actually really like this idea. I previously had thought a literal alt text there as well. But differentiating crawlable content seems useful. It could also tell screen readers whether or not to attempt to read the content or not.

I propose, also very hesitantly, that the following be optional elements to code fences:
- The opening fence can be followed by a flag value of text or art (or some other words that get decided upon, maybe even a or t)
- The closing fence can be followed by alt text

```art
8-)
``` Googly eyed smiley face

```text
I am
   a short thing
with      literal      spacing
```

Alt text may or may not be needed for a text style fence but an art one almost certainly could benefit from it. A system like this would give clients and users the ability to communicate things based on user preference (ie. a screen reader user only wanting alt text for art with no attempt to read the actual content in the fence, or a different user only wanting the content but not the alt).


Anyway, interesting ideas.


--?
Sent with https://mailfence.com
Secure and private email

From colecmac at protonmail.com  Thu May 14 19:59:31 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 14 May 2020 18:59:31 +0000
Subject: Nice project!
In-Reply-To: <20200514174155.GK10556@SDF.ORG>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
 <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
 <20200514174155.GK10556@SDF.ORG>
Message-ID: <GC7ttN5ED2F27KNJlvl55BFVkdZy5B1jVun0u5visRpYt-q9NzMO8cXca8ZR9RtOZfdbJQBHjTgDCgaPdK936RRuQHyBbocrSWMTOVnGYSc=@protonmail.com>

> Would this IRC chatter be in #gemini on tilde.chat? Julien did tell me
> about that channel but I have to admit I haven't poked my head in even
> once yet (I'm not much of an IRCer). Are people hanging out there
> semi-regularly and discussing Gemini? If so I'll make a mention of it
> in the FAQ alongside this mailing list.

It is that chat! You should definitely come join. I'm not much of an
IRC person either, but once I setup a self-hosted client like thelounge[0]
it was much more fun to use.

[0] https://thelounge.chat/


makeworld

??????? Original Message ???????
On Thursday, May 14, 2020 1:41 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Thu, May 14, 2020 at 03:28:16PM +0000, colecmac at protonmail.com wrote:
>
> > Also I see you're using wolfSSL, is it any good? I don't do much in C,
> > but there was some chatter in IRC the other day about BearSSL[1], maybe
> > it could be good for your project too.
>
> Ah, I'm glad people have discovered BearSSL! I was planning to mention
> it in a big TLS-related gemlog post later tonight. Once again I'm
> behind the curve on my own project!
>
> Would this IRC chatter be in #gemini on tilde.chat? Julien did tell me
> about that channel but I have to admit I haven't poked my head in even
> once yet (I'm not much of an IRCer). Are people hanging out there
> semi-regularly and discussing Gemini? If so I'll make a mention of it
> in the FAQ alongside this mailing list.
>
> Does anybody whose IRC-handy feel like hosting logs on gemini://?
>
> Cheers,
> Solderpunk
>
> > [1] https://bearssl.org/
> > makeworld
> > ??????? Original Message ???????
> > On Thursday, May 14, 2020 11:01 AM, Felix Quei?ner felix at masterq32.de wrote:
> >
> > > Hey all (and especially solderpunk)!
> > > I've found gemini yesterday and i'm excited! It's nice to see that
> > > people try to increase the surface of the web.
> > > I hate a lot of stuff in the modern web, especially all that bloat,
> > > tracking and unnecessary transmissions and i wanted to design a protocol
> > > that doesn't allow this. Now i find that Gemini already did this and the
> > > design is really well done!
> > > I started implementing a gemini CLI client [0] in Zig that will work
> > > similar to curl to allow command line fetches of files.
> > > Maybe i'm even motivated enough to write a small browser with rendering
> > > support for text/gemini...
> > > Happy hacking, ya'll
> > >
> > > -   xq
> > >     [0] https://github.com/MasterQ32/gurl
> > >



From luke.emmet at orlando-lutes.com  Thu May 14 20:00:57 2020
From: luke.emmet at orlando-lutes.com (Luke Emmet)
Date: Thu, 14 May 2020 20:00:57 +0100
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200514182104.GL10556@SDF.ORG>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
Message-ID: <5EBD9569.70309@orlando-lutes.com>

Hello
> I understand entirely where you are coming from.  An idea I've had for
> a while now (I don't remember if I've mentioned it here before) is that
> it would be nice if a graphical Gemini browser used a different
> foreground and background colour (and perhaps even a different font?)
> for different domains (subdomains)?  This would be something the client
> would do itself, with no possibility of control or influence from the
> server - it would just use the domain as the seed to a PRNG which chose
> a new scheme.  This would then give different sites their own subtly
> distinct look and feel, which a user could learn to recognise in time.
> I have no idea how feasible this is: programmatically generating
> genuinely pleasant colour schemes is certainly not straightforward.

This is interesting, something like the sigils in Urbit, or Gravitar 
that are automatically generated from
some identifier?

https://urbit.org/blog/creating-sigils/

https://en.gravatar.com/site/implement/

And so when you were on a "site" the content would be labelled/decorated 
in a simple yet consistent way

I think that could work.

If it is for the client to decide, how do we determine the "scope" of a 
site:

1.  If it is one per domain then that works, but I suppose that is not a 
universal
     assumption a client can make as many gemini spaces might be hosted 
on the same domain.

2. Full path - is very specific, but it would mean the placemarker would 
change with every request.

3. The author indicates it somehow

4. ?

It would be good perhaps if the author could optionally provide a seed 
site id as part of the content.

e.g. "site-name: Mysite" or other such pre-defined, not extensible 
syntax (we have headings, bullets, links...). Maybe the @symbol is 
awaiting such a role

"@ MySite"

This can be ignored by any disinterested client and is just text in the 
document that CLI readers can read without polluting the content with 
metadata.

> The idea of favicons has been mentioned before in a gemlog post:
>
> gemini://mozz.us/journal/2020-04-17.gmi
>
> I have a couple of big concerns here:
>
> One is that right now Gemini is strictly one-request-per-resource and a
> lot of people, myself included, consider that a really desirable
> property.  Anything like favicons or CSS would remove that property, no
> matter how light weight they were.  It's true that at least the second
> request would go to the same server as the first so this doesn't
> actually destroy predictability or control of which servers your client
> connects to, which is one of the arguments in favour of the one request
> thing.

I don't see the single request per resource is really violated here, 
since it is optional and not required to understand the content. But if 
that is really a worry
the client side option might work.

Maybe the favicon thing is just a convention that authors could include 
or not. The client could search up the url path and show the first one 
it finds, or none


> Another is that, philosophically, I kind of feel like styling *should*
> be under the control of the client and not the server.
That is OK, but maybe the server can hint.
>   Some people have
> strong preferences for light text on dark backgrounds, for example,
> because they have problems with eye strain the other way around.
Agree
> Right
> now on the web this is really only possible if the author deigns to
> provide the option (as Stack Overflow recently did, to much fanfare).  I
> think that's totally backwards.  Give the power over styling to the
> people who actually have to read the content, let them read your stuff
> in the way that works best for their eyesight and that *they* find
> aesthetically pleasing.  I realise this reduces some of the scope for
> self-expression on the part of Gemini content authors, but there's more
> than enough scope for that in the actual *content* they produce (if not,
> there are bigger problems...).
>
> <snip>
> I'd be much more interested in us exploring innovative possibilities
> which are strictly under the control of the client, like keying the
> styling to the domain as I mentioned earlier.  I'm not saying that exact
> approach necessarily is the best way to do it, or even a good way.  But
> it's *a* way to do it which doesn't run afoul of any of the issues above
> and that kind of out-of-the-box thinking is a good direction to take,
> IMHO.

-- 
______________________________________

Orlando Lutes
http://www.orlando-lutes.com


From luke.emmet at gmail.com  Thu May 14 20:02:21 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 14 May 2020 20:02:21 +0100
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200514182104.GL10556@SDF.ORG>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
Message-ID: <5EBD95BD.4050405@gmail.com>

Hello
> I understand entirely where you are coming from.  An idea I've had for
> a while now (I don't remember if I've mentioned it here before) is that
> it would be nice if a graphical Gemini browser used a different
> foreground and background colour (and perhaps even a different font?)
> for different domains (subdomains)?  This would be something the client
> would do itself, with no possibility of control or influence from the
> server - it would just use the domain as the seed to a PRNG which chose
> a new scheme.  This would then give different sites their own subtly
> distinct look and feel, which a user could learn to recognise in time.
> I have no idea how feasible this is: programmatically generating
> genuinely pleasant colour schemes is certainly not straightforward.

This is interesting, something like the sigils in Urbit, or Gravitar 
that are automatically generated from
some identifier?

https://urbit.org/blog/creating-sigils/

https://en.gravatar.com/site/implement/

And so when you were on a "site" the content would be labelled/decorated 
in a simple yet consistent way

I think that could work.

If it is for the client to decide, how do we determine the "scope" of a 
site:

1.  If it is one per domain then that works, but I suppose that is not a 
universal
     assumption a client can make as many gemini spaces might be hosted 
on the same domain.

2. Full path - is very specific, but it would mean the placemarker would 
change with every request.

3. The author indicates it somehow

4. ?

It would be good perhaps if the author could optionally provide a seed 
site id as part of the content.

e.g. "site-name: Mysite" or other such pre-defined, not extensible 
syntax (we have headings, bullets, links...). Maybe the @symbol is 
awaiting such a role

"@ MySite"

This can be ignored by any disinterested client and is just text in the 
document that CLI readers can read without polluting the content with 
metadata.

> The idea of favicons has been mentioned before in a gemlog post:
>
> gemini://mozz.us/journal/2020-04-17.gmi
>
> I have a couple of big concerns here:
>
> One is that right now Gemini is strictly one-request-per-resource and a
> lot of people, myself included, consider that a really desirable
> property.  Anything like favicons or CSS would remove that property, no
> matter how light weight they were.  It's true that at least the second
> request would go to the same server as the first so this doesn't
> actually destroy predictability or control of which servers your client
> connects to, which is one of the arguments in favour of the one request
> thing.

I don't see the single request per resource is really violated here, 
since it is optional and not required to understand the content. But if 
that is really a worry
the client side option might work.

Maybe the favicon thing is just a convention that authors could include 
or not. The client could search up the url path and show the first one 
it finds, or none


> Another is that, philosophically, I kind of feel like styling *should*
> be under the control of the client and not the server.
That is OK, but maybe the server can hint.
>   Some people have
> strong preferences for light text on dark backgrounds, for example,
> because they have problems with eye strain the other way around.
Agree
> Right
> now on the web this is really only possible if the author deigns to
> provide the option (as Stack Overflow recently did, to much fanfare).  I
> think that's totally backwards.  Give the power over styling to the
> people who actually have to read the content, let them read your stuff
> in the way that works best for their eyesight and that *they* find
> aesthetically pleasing.  I realise this reduces some of the scope for
> self-expression on the part of Gemini content authors, but there's more
> than enough scope for that in the actual *content* they produce (if not,
> there are bigger problems...).
>
> <snip>
> I'd be much more interested in us exploring innovative possibilities
> which are strictly under the control of the client, like keying the
> styling to the domain as I mentioned earlier.  I'm not saying that exact
> approach necessarily is the best way to do it, or even a good way.  But
> it's *a* way to do it which doesn't run afoul of any of the issues above
> and that kind of out-of-the-box thinking is a good direction to take,
> IMHO.

-- 
______________________________________

Orlando Lutes
http://www.orlando-lutes.com


From luke.emmet at gmail.com  Thu May 14 20:09:43 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 14 May 2020 20:09:43 +0100
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <CAFTy05a9+qcQmd6wcugEWXf+nUa16H5KO-rLm=3jrc_m7eZYQg@mail.gmail.com>
References: <5EBD6A0C.6090702@gmail.com>
 <CAFTy05a9+qcQmd6wcugEWXf+nUa16H5KO-rLm=3jrc_m7eZYQg@mail.gmail.com>
Message-ID: <5EBD9777.90801@gmail.com>

Hi Michael

On 14-May-2020 18:50, Michael Lazar wrote:
> I really appreciate that you brought up favicons. I've also been thinking
> about how they might be a fun and useful way to give a bit of "personality"
> to sites as they appear in bookmark lists, etc.
>
> The original implementation of favicons on the web was so simple and nice.
> Just plop a favicon.ico file in your root of your directory and you're
> done! Now on the modern web, it's gotten complicated with every browser
> having their own conventions on what the optimized size/format should be.
> So you end up needing to use a tool to generate 8 different file formats
> and link to them to using various<meta>  tags in the page header.
>
> I think utilizing unicode characters, specifically emojis, might be an
> elegant solution to this problem. They're scalable to any resolution and
> standard enough to provide a uniform experience across sites. A content
> author wouldn't need to worry about their image being transparent or
> looking like crap on higher resolutions, for example. And of course, they
> would work on terminal clients too!
>
> My proposed convention would be something like this
>
> gemini://my-site.com/favicon.txt
>
> This resource should be optional. If it exists, it should contain a single
> unicode character (the exact semantics of what a "character" is would need
> to be ironed out). Clients may chose to display this character alongside
> links or in the page title bar.
I think that would be a nice start, perhaps with a colour hint to be 
considered by the client, but of course not everyone can map their identity
onto a single unicode code point!

I really like the Haiku small vector graphic format. It is a bazillion 
times simpler than SVG and
makes for crisp icons and different resolutions

https://www.haiku-os.org/docs/userguide/en/applications/icon-o-matic.html

Regards

  - Luke

From luke.emmet at gmail.com  Thu May 14 20:17:08 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 14 May 2020 20:17:08 +0100
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200514183327.GN10556@SDF.ORG>
References: <6204139.202339.1589475979277@ichabod.co-bxl>
 <20200514183327.GN10556@SDF.ORG>
Message-ID: <5EBD9934.4070808@gmail.com>

>> I do think we should be providing alt text to ascii art blocks, maybe like so:
> I've kind of wondered about this too.  Specifically, I started wondering
> about this after the recent styling changes at typed-hole.org (sorry to
> pick on you, Julien!).  The new figlet-generated (I assume?) section
> headers look really great, but they're not great for accessibility (a
> screen reader won't know how to read them) and they're not great for
> searchability (a GUS search for words used in one of them won't turn up
Personally I find Ascii art or Figlet type fonts unattractive, but each 
to their own. Some clients for Gemini will be
using non-fixed-width rendering fonts. But I suppose it they are wrapped in
preformat blocks it is OK.

> I'm kind of torn here.  A lot of folks are doing very cool things with
> ASCII/ANSI art and colour escape codes in Geminispace.  I love the way
> it looks, and coming from the Gopher culture myself I totally understand
> and appreciate this urge.  I really don't want to publically condemn
> these practices and seem like a creativity-destroying jerk who wants
> Geminispace to be bland and depersonalised and black and white
>
>
<snip>
> But there *are* a lot of non-trivial problems with this stuff: on top of
> accessibility and searchability, Sean has mentioned potential security
> problems with handling ANSI escape codes from untrusted sources...

Colour escape codes seem like a Unix/terminal hack to me, they would 
look strange in a non CLI?
They aren't very accessible (e.g. screen readers for the blind) and if 
there are security
  issues I think that has to be a serious consideration

Best wishes

   - Luke

From plugd at thelambdalab.xyz  Thu May 14 20:19:26 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Thu, 14 May 2020 21:19:26 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <CAFTy05a9+qcQmd6wcugEWXf+nUa16H5KO-rLm=3jrc_m7eZYQg@mail.gmail.com>
References: <5EBD6A0C.6090702@gmail.com>
 <CAFTy05a9+qcQmd6wcugEWXf+nUa16H5KO-rLm=3jrc_m7eZYQg@mail.gmail.com>
Message-ID: <lzsgg22ukh.fsf@bs-mbpr348.d.ethz.ch>


Hi Michael,

Michael Lazar writes:
> gemini://my-site.com/favicon.txt
>
> This resource should be optional. If it exists, it should contain a single
> unicode character (the exact semantics of what a "character" is would need
> to be ironed out). Clients may chose to display this character alongside
> links or in the page title bar.

Interesting - it sounds like this is a kind of client/publisher
agreement that sidesteps the server entirely. Almost a super-protocol.
In the sense that you, as publisher, are free to make whatever files you
want available while I, as the client, am free to display your files in
whatever way I like.

(Think about how awkward it would be to _exclude_ this behaviour in the
spec!)

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200514/5429357c/attachment.sig>

From luke.emmet at gmail.com  Thu May 14 20:33:51 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 14 May 2020 20:33:51 +0100
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <e21c45ce-738b-8a4e-9e8c-49df164ea666@lavabit.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <e21c45ce-738b-8a4e-9e8c-49df164ea666@lavabit.com>
Message-ID: <5EBD9D1F.80207@gmail.com>

Hi James

On 14-May-2020 19:42, James Tomasino wrote:
> On 5/14/20 6:21 PM, solderpunk wrote:
>> it would be nice if a graphical Gemini browser used a different
>> foreground and background colour (and perhaps even a different font?)
>> for different domains (subdomains)?
> That sounds like a really nice feature that some people would value in a
> client that offered it. If, while browsing gemini, I could quickly set
> the colors or styling on a domain level it could be neat to visually
> separate places I go routinely. Some users might value that feature
> enough to choose a client that offers it. Others wouldn't care.
>
> Another option on the client level would be to hash the domain into a
> color code of some sort, dynamically creating variation in the
> backgrounds to a reasonable degree (shades of grey? below a certain
> lumen?). That would give the user an obvious indication if a link
> followed changed domains. Again, it might be of value to somebody and
> others won't care.
>
I think this is worth exploring if it can be done.

But I can't yet see how a client can determine when it is a cross-site 
link (or for client side
styling a site). Since there may be multiple users on the same site. So 
the author
has to indicate it in a consistent (i.e. standardised) way.

But I like this line of discussion.

  - Luke


From gmym at coopdot.com  Thu May 14 20:40:49 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Thu, 14 May 2020 21:40:49 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <345770818.210897.1589482670266@ichabod.co-bxl>
References: <345770818.210897.1589482670266@ichabod.co-bxl>
Message-ID: <CAObwWNhC+qUFMiCe17MzpvL6T2M6XcRzkfYZBkRXKgSUSD+tgA@mail.gmail.com>

Brian Evans <b__m__e at mailfence.com> wrote:

> I propose, also very hesitantly, that the following be optional elements
> to code fences:
> - The opening fence can be followed by a flag value of text or art (or
> some other words that get decided upon, maybe even a or t)
> - The closing fence can be followed by alt text


I was planning to suggest this when the spec freeze ends in a few weeks.
Not sure if it's a good idea to put it in the spec or as a recommended
convention.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200514/2c4daaed/attachment.htm>

From solderpunk at SDF.ORG  Thu May 14 20:46:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 19:46:28 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <CAObwWNhC+qUFMiCe17MzpvL6T2M6XcRzkfYZBkRXKgSUSD+tgA@mail.gmail.com>
References: <345770818.210897.1589482670266@ichabod.co-bxl>
 <CAObwWNhC+qUFMiCe17MzpvL6T2M6XcRzkfYZBkRXKgSUSD+tgA@mail.gmail.com>
Message-ID: <20200514194628.GP10556@SDF.ORG>

On Thu, May 14, 2020 at 09:40:49PM +0200, Katarina Eriksson wrote:
> Brian Evans <b__m__e at mailfence.com> wrote:
> 
> > I propose, also very hesitantly, that the following be optional elements
> > to code fences:
> > - The opening fence can be followed by a flag value of text or art (or
> > some other words that get decided upon, maybe even a or t)
> > - The closing fence can be followed by alt text
> 
> I was planning to suggest this when the spec freeze ends in a few weeks.
> Not sure if it's a good idea to put it in the spec or as a recommended
> convention.

There's an existing convention in Markdown, if I'm not mistaken, of
mentioning a programming language's name in curly brackets after an
opening code fence, which is used as a hint for syntax highlighting.
I'm not clear on the details, entirely, but people have mentioned it
before.

It might be smart to adopt/extend that syntax?

For now I am leaning toward "recommended convention"...

Cheers,
Solderpunk


From jmcbray at carcosa.net  Thu May 14 20:53:51 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 14 May 2020 15:53:51 -0400
Subject: Creating a Gemini site from an (advanced) Jekyll site
In-Reply-To: <CAMPYpA6vJ8LKx_sxp49_OhYKsSOBvrZVeXJhD8BRA8w0YfzOpA@mail.gmail.com>
References: <CAMPYpA6vJ8LKx_sxp49_OhYKsSOBvrZVeXJhD8BRA8w0YfzOpA@mail.gmail.com>
Message-ID: <87a72acmy8.fsf@dorothy.carcosa.net>


Travis Briggs writes:

> I wonder if there is a project to be created adding plugins for some
> other popular static site generator (Hugo? Gatsby?) to output Gemini
> content.

I have written an output format for Hugo to build Gopher sites, and I
could pretty easily retool it to build Gemini sites. It doesn't convert
from Markdown, but just builds all of the index/list pages as
gophermaps.

The writeup is here:
gopher://jfm.carcosa.net:70/0/blog/computing/hugo-gopher.txt



--
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

From felix at masterq32.de  Thu May 14 20:57:42 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Thu, 14 May 2020 21:57:42 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200514194628.GP10556@SDF.ORG>
References: <345770818.210897.1589482670266@ichabod.co-bxl>
 <CAObwWNhC+qUFMiCe17MzpvL6T2M6XcRzkfYZBkRXKgSUSD+tgA@mail.gmail.com>
 <20200514194628.GP10556@SDF.ORG>
Message-ID: <8153f229-a634-ae12-102c-b03c4f4afab6@masterq32.de>

Hey,

> There's an existing convention in Markdown, if I'm not mistaken, of
> mentioning a programming language's name in curly brackets after an
> opening code fence, which is used as a hint for syntax highlighting.
> I'm not clear on the details, entirely, but people have mentioned it
> before.
Yeah, there kinda is [0]. It's called the "info string" and has (by
spec) no defined meaning, it's usually used to hint the syntax
highlighter on the correct programming language.

> It might be smart to adopt/extend that syntax?
I think that would be a good thing. I enjoyed some of the ASCII art you
an find in gemini space and it would be nice to recognize these in a
search engine and filter these out. It could also allow to search for
certain programming languages (considering ascii art a PL)

> For now I am leaning toward "recommended convention"...
Yeah, sounds reasonable. Having the info string in the spec is a good
idea though, but make it's content not fixed

Regards
xq

[0] https://spec.commonmark.org/0.29/#fenced-code-blocks

From dwh at vi.rs  Thu May 14 21:27:55 2020
From: dwh at vi.rs (Dave Huseby)
Date: Thu, 14 May 2020 13:27:55 -0700
Subject: =?UTF-8?Q?Re:_Alternative_transports,
 _philosophy_[was:_Gemini_server_log?=
 =?UTF-8?Q?ging_formats_and_practices]?=
In-Reply-To: <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
Message-ID: <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>

This is a great reply. I never troll, I was just trying humor to dissuade Sean but he didn't catch the hint and doubled down. I have no patience for people who cannot be bothered to be neighborly. I've been around in open source long enough to know that trolls like Sean are like graffiti. If you tolerate them, the trolling only gets worse and eventually leads to ruining the neighborhood.

I want to point out that the *only* reason I'm using Gemini at all is because it respects the sovereignty of users more than the web. You guys are going to get tired of me talking about it. Gemini is no where near fully user sovereign though. Frankly the software and research I'm doing doesn't really need something like Gemini. It was my mistake to mix up the ideas of what I'm publishing on my Gemini space with Gemini.

My only real criticism for Gemini is that it relies on TLS. I personally believe that all communications should be encrypted by default. Gemini insisting on encryption is good but going with TLS is bad when there are much better choices such as CurveCP. 

I don't trust TLS because of this: 

=> https://arstechnica.com/information-technology/2013/01/turkish-government-agency-spoofed-google-certificate-accidentally/

I know, I know, but what about OCSP stapling and the global issuance observatory that were created to address this? The fact that the CA system is centralized and top-down combined with the fact that applications just blindly trust the root certs in the file that Mozilla puts on all of our computers leaves too many attack vectors for me to trust it over the long term. Gemini allows for self-signed certs, if you're going that far, why not use a better sign-after-encrypt protocol that actually increases security. CurveCP is much simpler that TLS at all levels.

Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system? If the stated goal of Gemini is to be better than the web, why make the same mistakes as the web? If the stated goal is to just keep the code simple, fine, but why TLS then, CurveCP is simpler?

What is are the goals of Gemini?

Cheers!
Dave

From dwh at vi.rs  Thu May 14 21:33:26 2020
From: dwh at vi.rs (Dave Huseby)
Date: Thu, 14 May 2020 13:33:26 -0700
Subject: =?UTF-8?Q?Re:_Alternative_transports,
 __philosophy_[was:_Gemini_server_lo?=
 =?UTF-8?Q?gging_formats_and_practices]?=
In-Reply-To: <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
Message-ID: <2616b90c-114e-4744-8968-bbbacabab205@www.fastmail.com>

On Thu, May 14, 2020, at 1:27 PM, Dave Huseby wrote:
> This is a great reply.

I meant that Colecmac's reply was great. Not mine.

Dave

From solderpunk at SDF.ORG  Thu May 14 21:57:53 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 20:57:53 +0000
Subject: Alternative transports,  philosophy [was: Gemini server logging
 formats and practices]
In-Reply-To: <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG>
 <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
Message-ID: <20200514205753.GQ10556@SDF.ORG>

On Thu, May 14, 2020 at 01:27:55PM -0700, Dave Huseby wrote:

> This is a great reply. I never troll, I was just trying humor to dissuade Sean but he didn't catch the hint and doubled down. I have no patience for people who cannot be bothered to be neighborly. I've been around in open source long enough to know that trolls like Sean are like graffiti. If you tolerate them, the trolling only gets worse and eventually leads to ruining the neighborhood.

I have to admit to being really confused by this.  I thought that Sean
absolutely took your post in the spirit it was intended and replied
well, in that same spirit, and better than I'd hoped.  I felt like I'd
stepped in prematurely to try to settle things down.  If this is as bad
as the trolling gets around here, I'll be pretty happy.

And for the record, Sean has done a lot to *improve* this neighbourhood
so far.

> My only real criticism for Gemini is that it relies on TLS. I personally believe that all communications should be encrypted by default. Gemini insisting on encryption is good but going with TLS is bad when there are much better choices such as CurveCP.

I'm writing a gemlog post right now which talks about a whole lot of
things related to TLS, including some attempt to justify the decision to
use it.  It'll be up soon, and I hope you'll read it.
 
> Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system?

It's true that not everybody (including myself) has properly implemented
it yet, but Gemini *does* deliberately and explicitly try to avoid
relying on the CA system by permitting clients to use a TOFU security
model.  Surely you read that in the spec?

Cheers,
Solderpunk

From int at 80h.dev  Thu May 14 21:53:35 2020
From: int at 80h.dev (int 80h)
Date: Thu, 14 May 2020 16:53:35 -0400
Subject: New Twin, Mobile?
In-Reply-To: <20200514171815.GF10556@SDF.ORG>
Message-ID: <C2QR1KS0N3QX.2ARL5AOPX48TX@freebsd.lan>

On Thu May 14, 2020 at 1:18 PM EDT, solderpunk wrote:
> It seems to me like servers really ought to be tolerant of it not being
> used, which implies having a designated default host. But also that
> clients really ought to be sending it.

While I'm not a fan of it, I added a default. Which wasn't the problem
anyway.

Turns out I was sending the status and body together. Doing so worked
fine on all the clients I use but I guess not all. It's fixed now.

Sorry to whoever the dev of the client is for thinking it was on your
side.

int 80h

From sean at conman.org  Thu May 14 22:04:00 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 17:04:00 -0400
Subject: =?us-ascii?B?PT9VVEYtOD9RP1JlOl9BbHRl?=
 =?us-ascii?B?cm5hdGl2ZV90cmFuc3BvcnRzLCBfcGhpbG9zb3BoeV9bd2FzOl9HZW1pbmlf?=
 =?us-ascii?B?c2VydmVyX2xvZz89?= ging formats and practices]
In-Reply-To: <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
Message-ID: <20200514210400.GX7305@brevard.conman.org>

It was thus said that the Great Dave Huseby once stated:
> 
> Why shouldn't Gemini avoid relying on centralized solutions such as TLS
> and the CA system? If the stated goal of Gemini is to be better than the
> web, why make the same mistakes as the web? If the stated goal is to just
> keep the code simple, fine, but why TLS then, CurveCP is simpler?

  So implement a Gemini server and client using the technology you think is
better so others can see it, play with it, and see how easy, secure,
whatever, it is.

  -spc

From solderpunk at SDF.ORG  Thu May 14 22:08:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 21:08:29 +0000
Subject: Alternative transports,  philosophy [was: Gemini server logging
 formats and practices]
In-Reply-To: <20200514205753.GQ10556@SDF.ORG>
References: <20200511081816.GA23500@SDF.ORG>
 <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
 <20200514205753.GQ10556@SDF.ORG>
Message-ID: <20200514210829.GR10556@SDF.ORG>

On Thu, May 14, 2020 at 08:57:53PM +0000, solderpunk wrote:
 
> I'm writing a gemlog post right now which talks about a whole lot of
> things related to TLS, including some attempt to justify the decision to
> use it.  It'll be up soon, and I hope you'll read it.

It's up!

gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/tls-musings.gmi

Cheers,
Solderpunk

From dwh at vi.rs  Thu May 14 22:09:04 2020
From: dwh at vi.rs (Dave Huseby)
Date: Thu, 14 May 2020 14:09:04 -0700
Subject: =?UTF-8?Q?Re:_Alternative_transports,
 __philosophy_[was:_Gemini_server_lo?=
 =?UTF-8?Q?gging_formats_and_practices]?=
In-Reply-To: <20200514205753.GQ10556@SDF.ORG>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
 <20200514205753.GQ10556@SDF.ORG>
Message-ID: <fd553652-38aa-4ffb-9d9d-883e28222a6a@www.fastmail.com>

On Thu, May 14, 2020, at 1:57 PM, solderpunk wrote:
> On Thu, May 14, 2020 at 01:27:55PM -0700, Dave Huseby wrote:
> 
> > This is a great reply. I never troll, I was just trying humor to dissuade Sean but he didn't catch the hint and doubled down. I have no patience for people who cannot be bothered to be neighborly. I've been around in open source long enough to know that trolls like Sean are like graffiti. If you tolerate them, the trolling only gets worse and eventually leads to ruining the neighborhood.
> 
> I have to admit to being really confused by this.  I thought that Sean
> absolutely took your post in the spirit it was intended and replied
> well, in that same spirit, and better than I'd hoped.  I felt like I'd
> stepped in prematurely to try to settle things down.  If this is as bad
> as the trolling gets around here, I'll be pretty happy.

Noted. Moving on : )

> And for the record, Sean has done a lot to *improve* this neighbourhood
> so far.

I did notice this.

> > My only real criticism for Gemini is that it relies on TLS. I personally believe that all communications should be encrypted by default. Gemini insisting on encryption is good but going with TLS is bad when there are much better choices such as CurveCP.
> 
> I'm writing a gemlog post right now which talks about a whole lot of
> things related to TLS, including some attempt to justify the decision to
> use it.  It'll be up soon, and I hope you'll read it.

I surely will. I'm curious about your thinking.
 
> > Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system?
> 
> It's true that not everybody (including myself) has properly implemented
> it yet, but Gemini *does* deliberately and explicitly try to avoid
> relying on the CA system by permitting clients to use a TOFU security
> model.  Surely you read that in the spec?

Oops, I deleted some largely irrelevant parts of my reply that included me saying, "I get it that Gemini allows for self-signed certs but if you're going with TOFU as a primary requirement then why not Noise? CurveCP does have some TOFU limintations around knowing public keys ahead of time and through secure independent distribution."

Looking forward to your gemlog. I wish we were using the term "mission log" instead, but meh, I'm indifferent.

Cheers!
Dave

From int at 80h.dev  Thu May 14 22:01:29 2020
From: int at 80h.dev (int 80h)
Date: Thu, 14 May 2020 17:01:29 -0400
Subject: Server software recommendations
In-Reply-To: <20200514123545.vdx2gwzhytp5risg@tilde.pink>
Message-ID: <C2QR7MPL6502.1JH6XTNJ7Q5G1@freebsd.lan>

On Thu May 14, 2020 at 8:35 AM EDT, tiwesdaeg  wrote: 
>
> I have found both of these servers very difficult to install. With
> gemserv, I tried debian's packaged rust, rustup, and rustup nightly.
> All failed for different interesting reasons.

Could you email information on what problems you were having? I threw a
linux binary up on the project page to make it easier on people.

> Jetforce is very easy to install with pip, which is probably why it's
> the most used server currently.
>
> Thanks for all the hard work all you software developers are doing!

Indeed thank you everyone!

int 80h

From sean at conman.org  Thu May 14 22:15:54 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 17:15:54 -0400
Subject: Server software recommendations
In-Reply-To: <20200514123545.vdx2gwzhytp5risg@tilde.pink>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
 <20200514123545.vdx2gwzhytp5risg@tilde.pink>
Message-ID: <20200514211554.GY7305@brevard.conman.org>

It was thus said that the Great tiwesdaeg at tilde.pink once stated:
> 
> I have found both of these servers very difficult to install. With
> gemserv, I tried debian's packaged rust, rustup, and rustup nightly.
> All failed for different interesting reasons. I could never get the
> dependencies sorted out for GLV-1.12556.

  I admit it might be difficult to install GLV-1.12556.  I missed listing
one dependency (oops).  But I feel the biggest hurdle is the requirement of
LibreSSL, as not many people use it (shame, because it has what I feel is
the easiest to use TLS implementation with its libtls).  I'm not sure what
to do about that, but thanks for trying it (or even looking at it).

> Thanks for all the hard work all you software developers are doing!

  You're welcome.

  -spc


From solderpunk at SDF.ORG  Thu May 14 22:23:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 21:23:58 +0000
Subject: Alternative transports, philosophy [was: Gemini server logging
 formats and practices]
In-Reply-To: <fd553652-38aa-4ffb-9d9d-883e28222a6a@www.fastmail.com>
References: <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
 <20200514205753.GQ10556@SDF.ORG>
 <fd553652-38aa-4ffb-9d9d-883e28222a6a@www.fastmail.com>
Message-ID: <20200514212358.GS10556@SDF.ORG>

On Thu, May 14, 2020 at 02:09:04PM -0700, Dave Huseby wrote:
 
> I surely will. I'm curious about your thinking.

I'm not sure you'll be completely sold, but I hope you'll see where I'm
coming from.

To try to boil it all down:  I absolutely agree that TLS has problems
and I don't doubt that other things, like CurveCP, might overcome or
avoid a lot of them.  But I believe something built on TLS is
overwhelmingly more likely to be widely implemented and deployed than
something based on literally anything else, and at the end of the day a
I think a good but not perfect protocol which becomes widely used and
supported will do a lot more good for the internet than a "perfect"
protocol which never becomes more than a curiosity for a small
community of enthusiasts.

This is not to say I don't think anything "strange and new" can *ever*
"catch on" or that I think any such efforts are a waste of time.  I wish
all the radical projects aiming at lofty goals all the luck in the
world, sincerely.  But there's a valid niche for something not quite so
radical which can still be a real and valuable improvement over the
status quo with very low barriers to adoption.

Cheers,
Solderpunk


From b__m__e at mailfence.com  Thu May 14 22:25:39 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Thu, 14 May 2020 23:25:39 +0200 (CEST)
Subject: New aggregator
Message-ID: <1413246217.220603.1589491539267@ichabod.co-bxl>

I had forgotten to mention (it has been running for a few days now) that I have finally put up a gemini capsule 
that uses my program 'spacewalk' (tildegit.org/sloum/spacewalk) to aggregate some gemini content. This is
a more gopher-like experience than the, very awesome, atom feed based aggregator (capcom) that solderpunk 
set up.

It can be found here: 
gemini://rawtext.club:1965/~sloum/spacewalk.gmi

If you have some content up that you would like to be listed please shoot me an e-mail.


From solderpunk at SDF.ORG  Thu May 14 22:30:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 14 May 2020 21:30:58 +0000
Subject: New aggregator
In-Reply-To: <1413246217.220603.1589491539267@ichabod.co-bxl>
References: <1413246217.220603.1589491539267@ichabod.co-bxl>
Message-ID: <20200514213058.GT10556@SDF.ORG>

I've just added a link to this to the main gemini.circumlunar.space page
after the CAPCOM link, sorry it took me a while to get around to this!
Thanks a lot for putting this up.

Cheers,
Solderpunk
(last reply of the night!)

On Thu, May 14, 2020 at 11:25:39PM +0200, Brian Evans wrote:
> I had forgotten to mention (it has been running for a few days now) that I have finally put up a gemini capsule 
> that uses my program 'spacewalk' (tildegit.org/sloum/spacewalk) to aggregate some gemini content. This is
> a more gopher-like experience than the, very awesome, atom feed based aggregator (capcom) that solderpunk 
> set up.
> 
> It can be found here: 
> gemini://rawtext.club:1965/~sloum/spacewalk.gmi
> 
> If you have some content up that you would like to be listed please shoot me an e-mail.
> 

From sean at conman.org  Thu May 14 22:38:54 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 17:38:54 -0400
Subject: Server software recommendations
In-Reply-To: <20200514150810.GB12880@SDF.ORG>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
 <20200514123545.vdx2gwzhytp5risg@tilde.pink> <20200514150810.GB12880@SDF.ORG>
Message-ID: <20200514213854.GZ7305@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Thu, May 14, 2020 at 12:35:45PM +0000, tiwesdaeg at tilde.pink wrote:
>  
> > I'm using molly-brown currently, because I like how it handles user
> > public_gemini directories. Full cgi support would be nice.
> 
> I've been meaning to write a gemlog about this for ages, but never seem
> to have the time...
> 
> GCI support in Molly Brown scares the pants off me.  Go doesn't reliably
> support setuid() and this totally breaks all the standard pradigms of
> unix server design.  In particular, I can find no way for MB to spawn a
> CGI process which doesn't run as the same user as MB itself, and
> therefore necessarily has the ability to read the TLS private key files
> and write to the log file, which is obviously a massive security hole.
> Because the MB process never runs as root, it's not possible to chroot
> the CGI processes somewhere they couldn't see those files, either

  Does Go actually check the permissions of a file before calling exec() on
it?  And refuse to run it if it's setuid?  That sounds strange to me.  Or do
you mean something like?

	child = fork()
	if (child == 0) /* child process */
	{
	  setuid(CGIowner);
	  exec(CGIprogram);
	}

  And because I feel compelled to state this:  setuid() only works for root.

  And it is possible to chroot programs, but it's not generally done in
these days of dynamically linked programs because you need to copy in all
the shared objects into the chroot with the program.  Hmmm ... I wonder if
you can't do a chroot with some LD_PRELOAD trickery ... might have to play
around with that.

> I'm frankly baffled that a language with Ken Thompson and Rob Pike as
> designers, created specifically to help Google engineers write server
> software, could turn out to be so terrible for...writing servers on
> unix.

  Rob Pike doesn't trust programmers.  Direct quote from him:

	The key point here is our programmers are Googlers, they're not
	researchers.  They're typically, fairly young, fresh out of school,
	probably learned Java, maybe learned C or C++, probably learned
	Python. They're not capable of understanding a brilliant language
	but we want to use them to build good software. So, the language
	that we give them has to be easy for them to understand and easy to
	adopt.

		http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent

> This was the reason that I pondered a few months back on this list some
> kind of FastCGI-esque system for a Gemini server to communicate with a
> process it didn't spawn itself over a domain socket or similar.  But
> maybe I should just give up on Go for servers (this exact same issue
> affects Shizaru, too.).

  FastCGI could be a way of doing it.  I might just look into that for
GLV-1.12556 ...

  -spc (There's always Rust ... )


From sean at conman.org  Thu May 14 22:43:37 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 17:43:37 -0400
Subject: Nice project!
In-Reply-To: <b3203cac-b866-acfb-c7f0-2c7749ff0201@masterq32.de>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
 <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
 <b3203cac-b866-acfb-c7f0-2c7749ff0201@masterq32.de>
Message-ID: <20200514214337.GA7305@brevard.conman.org>

It was thus said that the Great Felix Quei?ner once stated:
> Hey makeworld
> 
> > Welcome! It's cool to have another command line tool for the ecosystem,
> > and Zig seems like an interesting language. I think you're the first
> > to make a Gemini tool with it!
> Yeah pretty much. The Zig community is still quite small, but constantly
> growing and evolving :)
> 
> > I've made a command line downloader[0] myself, but having a more
> > advanced curl type tool would be great.
> > 
> > [0] https://github.com/makeworld-the-better-one/gemget
> Oh nice, reference code! I'm struggling with SSL atm, receiving my first
> line of the response "20 text/gemini", but then i receive a "peer sent
> close notify alert" from WolfSSL, so i might check out code code a bit
> and the dependencies
> 
> > Also I see you're using wolfSSL, is it any good? I don't do much in C,
> > but there was some chatter in IRC the other day about BearSSL[1], maybe
> > it could be good for your project too.
> > 
> > [1] https://bearssl.org/
> Taking a look now, it is already more attractive than WolfSSL as it's
> MIT licence and not GPL. I've tried like 5 libraries yesterday and none
> were either well documented, well working or well compilable, so giving
> a shot now at BearSSL... WolfSSL was just the first library that got a
> TLS connection established

  I use LibreSSL, which includes a library called libtls, which makes it
*very* easy to use TLS, especially for clients.  I have some examples of
its use here:

	https://github.com/spc476/libtls-examples

  -spc


From int at 80h.dev  Thu May 14 22:33:57 2020
From: int at 80h.dev (int 80h)
Date: Thu, 14 May 2020 17:33:57 -0400
Subject: Server software recommendations
In-Reply-To: <20200514150810.GB12880@SDF.ORG>
Message-ID: <C2QRWHLM6BAZ.DT6HT70FA3F6@freebsd.lan>

On Thu May 14, 2020 at 11:08 AM EDT, solderpunk wrote:
> This was the reason that I pondered a few months back on this list some
> kind of FastCGI-esque system for a Gemini server to communicate with a
> process it didn't spawn itself over a domain socket or similar. But
> maybe I should just give up on Go for servers (this exact same issue
> affects Shizaru, too.).

That's a good idea, CGI scares me. Are you planning to create a standard
or should we just go off of regular FASTCGI? I've never used CGI outside
of gemini so I'm not sure what people need.

int 80h

From natpen at natpen.net  Thu May 14 23:02:17 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Thu, 14 May 2020 18:02:17 -0400
Subject: New aggregator
In-Reply-To: <1413246217.220603.1589491539267@ichabod.co-bxl>
References: <1413246217.220603.1589491539267@ichabod.co-bxl>
Message-ID: <20200514220217.GA3057579@goldfish.localdomain>

I know folks were just talking on this list about how ascii art
probably isn't doing my search engine's indexing any favors (and
they're probably right LOL) but nevertheless I think Spacewalk looks
SOOOO cool!!!

From natpen at natpen.net  Thu May 14 23:05:29 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Thu, 14 May 2020 18:05:29 -0400
Subject: GUS questions
In-Reply-To: <20200514144513.GA12880@SDF.ORG>
References: <piEULycseOm93OMr6N8YTcMZlFJYSWYRqTgpdHkeFMIFyRIZTIdKMmNyG6kBxGSZHm4M_rx-LKoEaK98IaKVwObunz4Ah6eYo1ukf3hfu8U=@protonmail.com>
 <20200505125113.GA148355@goldfish.localdomain>
 <wik2s-Yf4ZWXP_J0a3ummQkA31NERuFqMuTWDVrSihxDA0BWGMLgvRCakUq_XgpA0ds-Mjm2CeD4m-E1vxIoEVuzWkNrQC9CZKMxDZo_dSI=@protonmail.com>
 <20200514120907.GA2791104@goldfish.localdomain>
 <87ftc2d6kz.fsf@dorothy.carcosa.net>
 <20200514144513.GA12880@SDF.ORG>
Message-ID: <20200514220529.GA3063026@goldfish.localdomain>

Aww, thanks! I'm glad it's an appreciated little piece of Geminispace.

From bob at freedombone.net  Thu May 14 23:16:21 2020
From: bob at freedombone.net (Bob Mottram)
Date: Thu, 14 May 2020 23:16:21 +0100
Subject: Alternative transports,  philosophy [was: Gemini server logging
 formats and practices]
In-Reply-To: <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG>
 <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
Message-ID: <20200514221621.GA15610@freedombone.net>

On Thu, May 14, 2020 at 01:27:55PM -0700, Dave Huseby wrote:
>Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system? If the stated goal of Gemini is to be better than the web, why make the same mistakes as the web? If the stated goal is to just keep the code simple, fine, but why TLS then, CurveCP is simpler?


afaik Gemini doesn't use the CA system. It's just TOFU.

If it does use CAs then this should be considered a design fault.

Avoid anything centralized. The future will thank us for it.

From sean at conman.org  Thu May 14 23:28:16 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 18:28:16 -0400
Subject: Server software recommendations
In-Reply-To: <C2QRWHLM6BAZ.DT6HT70FA3F6@freebsd.lan>
References: <20200514150810.GB12880@SDF.ORG>
 <C2QRWHLM6BAZ.DT6HT70FA3F6@freebsd.lan>
Message-ID: <20200514222815.GB7305@brevard.conman.org>

It was thus said that the Great int 80h once stated:
> On Thu May 14, 2020 at 11:08 AM EDT, solderpunk wrote:
> > This was the reason that I pondered a few months back on this list some
> > kind of FastCGI-esque system for a Gemini server to communicate with a
> > process it didn't spawn itself over a domain socket or similar. But
> > maybe I should just give up on Go for servers (this exact same issue
> > affects Shizaru, too.).
> 
> That's a good idea, CGI scares me. Are you planning to create a standard
> or should we just go off of regular FASTCGI? I've never used CGI outside
> of gemini so I'm not sure what people need.

  The specification of CGI is RFC-3875 [1] and there are a number of Gemini
servers that have implemented it to some degree [2].  I found the
specification for FastCGI [3] and it seems a bit more involved (with it
being a protocol and all) but I think it could be used for Gemini, much like
CGI can be used for Gemini.

  -spc

[1]	https://tools.ietf.org/html/rfc3875

[2]	GLV-1.12556 can handle both Gemini specific CGI scripts and HTTP
	specific CGI scripts (by converting the return code from HTTP to
	Gemini).

[3]	https://fastcgi-archives.github.io/FastCGI_Specification.html

From int at 80h.dev  Thu May 14 23:43:16 2020
From: int at 80h.dev (int 80h)
Date: Thu, 14 May 2020 18:43:16 -0400
Subject: Server software recommendations
In-Reply-To: <20200514222815.GB7305@brevard.conman.org>
Message-ID: <C2QTDK9ZU0EU.1HK0UDLJWCPX2@freebsd.lan>

On Thu May 14, 2020 at 2:28 PM EDT, Sean Conner wrote:
> The specification of CGI is RFC-3875 [1] and there are a number of
> Gemini
> servers that have implemented it to some degree [2]. I found the
> specification for FastCGI [3] and it seems a bit more involved (with it
> being a protocol and all) but I think it could be used for Gemini, much
> like
> CGI can be used for Gemini.
>
> -spc
>
> [1] https://tools.ietf.org/html/rfc3875
>
> [2] GLV-1.12556 can handle both Gemini specific CGI scripts and HTTP
> specific CGI scripts (by converting the return code from HTTP to
> Gemini).
>
> [3] https://fastcgi-archives.github.io/FastCGI_Specification.html

Thank you for the links. I see there's also SCGI which looks similar. I
guess I have some reading to do

int 80h

From felix at masterq32.de  Fri May 15 00:25:01 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Fri, 15 May 2020 01:25:01 +0200
Subject: Nice project!
In-Reply-To: <20200514214337.GA7305@brevard.conman.org>
References: <a1f9fd9c-138c-53af-e135-46cd6af1b5c8@masterq32.de>
 <gSAjkUdRA1lKY3cMcJtQgR29OEsjGrf5MgJ7tlWI1N_LwJrbpwofvQJFdvbdDhLyjdNx8HbrysvMlX2Hc_jI6hv8i12zGkKMmKnpI6TS1_4=@protonmail.com>
 <b3203cac-b866-acfb-c7f0-2c7749ff0201@masterq32.de>
 <20200514214337.GA7305@brevard.conman.org>
Message-ID: <d51862c2-f074-3dc1-4d26-9eb27cf26ae7@masterq32.de>

Hey

>   I use LibreSSL, which includes a library called libtls, which makes it
> *very* easy to use TLS, especially for clients.  I have some examples of
> its use here:
> 
> 	https://github.com/spc476/libtls-examples

Thanks for sharing the code!

I've integreated BearSSL now and i really like it. It's not really high
level or whatsoever, but i start to understand now what steps are taken
and required when building up a SSL connection, including the
certificate stuff.

BearSSL fits perfectly to Zig as it has no builtin allocations and i can
just use Zigs allocator interface with BearSSL and i don't have to think
about when using malloc/free or my own allocators.

Regards
xq

From dwh at vi.rs  Fri May 15 00:27:25 2020
From: dwh at vi.rs (Dave Huseby)
Date: Thu, 14 May 2020 16:27:25 -0700
Subject: =?UTF-8?Q?Re:_Alternative_transports,
 _philosophy_[was:_Gemini_server_log?=
 =?UTF-8?Q?ging_formats_and_practices]?=
In-Reply-To: <20200514212358.GS10556@SDF.ORG>
References: <20200511092101.GJ7305@brevard.conman.org>
 <20200512182315.GD16945@SDF.ORG>
 <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
 <20200514205753.GQ10556@SDF.ORG>
 <fd553652-38aa-4ffb-9d9d-883e28222a6a@www.fastmail.com>
 <20200514212358.GS10556@SDF.ORG>
Message-ID: <38dd7c1f-f4ad-4137-9103-50dd75719bc2@www.fastmail.com>

I totally understand. The next version of TLS is using something like Noise/CurveCP as the default protocol. What I don't like the most about TLS is the complexity due to backwards compatibility and protocol negotiation. Using TLS properly requires lots of tweaking of complicated parameters that very few people understand.

I still look forward to your post.

Cheers!
Dave

On Thu, May 14, 2020, at 2:23 PM, solderpunk wrote:
> On Thu, May 14, 2020 at 02:09:04PM -0700, Dave Huseby wrote:
>  
> > I surely will. I'm curious about your thinking.
> 
> I'm not sure you'll be completely sold, but I hope you'll see where I'm
> coming from.
> 
> To try to boil it all down:  I absolutely agree that TLS has problems
> and I don't doubt that other things, like CurveCP, might overcome or
> avoid a lot of them.  But I believe something built on TLS is
> overwhelmingly more likely to be widely implemented and deployed than
> something based on literally anything else, and at the end of the day a
> I think a good but not perfect protocol which becomes widely used and
> supported will do a lot more good for the internet than a "perfect"
> protocol which never becomes more than a curiosity for a small
> community of enthusiasts.
> 
> This is not to say I don't think anything "strange and new" can *ever*
> "catch on" or that I think any such efforts are a waste of time.  I wish
> all the radical projects aiming at lofty goals all the luck in the
> world, sincerely.  But there's a valid niche for something not quite so
> radical which can still be a real and valuable improvement over the
> status quo with very low barriers to adoption.
> 
> Cheers,
> Solderpunk
> 
>

From sean at conman.org  Fri May 15 00:48:10 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 14 May 2020 19:48:10 -0400
Subject: Server software recommendations
In-Reply-To: <20200514213854.GZ7305@brevard.conman.org>
References: <20200514110911.2c81f9fa@socimda>
 <20200514085039.GW7305@brevard.conman.org>
 <20200514123545.vdx2gwzhytp5risg@tilde.pink> <20200514150810.GB12880@SDF.ORG>
 <20200514213854.GZ7305@brevard.conman.org>
Message-ID: <20200514234810.GE7305@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
>   And because I feel compelled to state this:  setuid() only works for root.

  Let me further clarify this before the replies come pouring in---the
simple answer is "setuid() only works for root".  The complex answer is more
nuanced and involves the "effective user id" concept.

  -spc

From tiwesdaeg at tilde.pink  Fri May 15 01:13:33 2020
From: tiwesdaeg at tilde.pink (Tiwesdaeg Twohands)
Date: Thu, 14 May 2020 19:13:33 -0500
Subject: Server software recommendations
In-Reply-To: <C2QR7MPL6502.1JH6XTNJ7Q5G1@freebsd.lan>
References: <20200514123545.vdx2gwzhytp5risg@tilde.pink>
 <C2QR7MPL6502.1JH6XTNJ7Q5G1@freebsd.lan>
Message-ID: <20200514191333.0b408523@azalea.lignumvitae.org>

I finally got it to compile on debian using rustup stable. It's now the
geminid for gemini://libraryoferis.org The big win here is that I was
able to get CGI working perfectly to serve dynamic content using shell
script, python, and sqlite3! 

Have you thought about support the .gmi file type as well? It took me
forever to realize what was going on with index.gmi. I am looking at
trying gemserv out on tilde.pink, but my current users are all
using .gmi.

I'm really happy with gemserv, thanks!

On Thu, 14 May 2020 17:01:29 -0400
"int 80h" <int at 80h.dev> wrote:

> On Thu May 14, 2020 at 8:35 AM EDT, tiwesdaeg  wrote: 
> >
> > I have found both of these servers very difficult to install. With
> > gemserv, I tried debian's packaged rust, rustup, and rustup nightly.
> > All failed for different interesting reasons.  
> 
> Could you email information on what problems you were having? I threw
> a linux binary up on the project page to make it easier on people.
> 
> > Jetforce is very easy to install with pip, which is probably why
> > it's the most used server currently.
> >
> > Thanks for all the hard work all you software developers are
> > doing!  
> 
> Indeed thank you everyone!
> 
> int 80h


From int at 80h.dev  Fri May 15 02:14:09 2020
From: int at 80h.dev (int 80h)
Date: Thu, 14 May 2020 21:14:09 -0400
Subject: Server software recommendations
In-Reply-To: <20200514191333.0b408523@azalea.lignumvitae.org>
Message-ID: <C2QWL35GS3WB.2ZOF9CD9H9EG7@freebsd.lan>

On Thu May 14, 2020 at 3:13 PM EDT, Tiwesdaeg Twohands wrote:
> I finally got it to compile on debian using rustup stable. It's now the
> geminid for gemini://libraryoferis.org The big win here is that I was
> able to get CGI working perfectly to serve dynamic content using shell
> script, python, and sqlite3!
>
> Have you thought about support the .gmi file type as well? It took me
> forever to realize what was going on with index.gmi. I am looking at
> trying gemserv out on tilde.pink, but my current users are all
> using .gmi.
>
> I'm really happy with gemserv, thanks!

Thank! You're the first person to run anything I've made. It now
supports configurable index per vhost.

int 80h

From gmym at coopdot.com  Fri May 15 03:27:48 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Fri, 15 May 2020 04:27:48 +0200
Subject: Server software recommendations
In-Reply-To: <C2QWL35GS3WB.2ZOF9CD9H9EG7@freebsd.lan>
References: <20200514191333.0b408523@azalea.lignumvitae.org>
 <C2QWL35GS3WB.2ZOF9CD9H9EG7@freebsd.lan>
Message-ID: <CAObwWNgGdTsh8+5y4ej6kSMehEP4yEXxDePbXM-GeHzGVFJWag@mail.gmail.com>

int 80h <int at 80h.dev> wrote:

> Thank! You're the first person to run anything I've made. It now
> supports configurable index per vhost.
>

Gemserv has filled my need for server software since a few days ago. Maybe
I should upgrade to the new version when I wake up tomorrow?

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/a62d5477/attachment.htm>

From int at 80h.dev  Fri May 15 05:54:01 2020
From: int at 80h.dev (int 80h)
Date: Fri, 15 May 2020 00:54:01 -0400
Subject: Server software recommendations
In-Reply-To: <CAObwWNgGdTsh8+5y4ej6kSMehEP4yEXxDePbXM-GeHzGVFJWag@mail.gmail.com>
Message-ID: <C2R19FD46LAU.30GOI8W6179C0@freebsd.lan>

On Fri May 15, 2020 at 12:27 AM EDT, Katarina Eriksson wrote:
> Gemserv has filled my need for server software since a few days ago.
> Maybe
> I should upgrade to the new version when I wake up tomorrow?

Oh, thank you! If you find any problems please let me know. I thought it was
only used by me.

int 80h

From benulo at systemli.org  Fri May 15 07:44:44 2020
From: benulo at systemli.org (Ben)
Date: Fri, 15 May 2020 11:14:44 +0430
Subject: Announcing kwiecien.us
Message-ID: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>

After being a long-time subscriber to this list while having no idea 
what Gemini (or even Gopher) is, I've gotten to the point of running my 
own server. You should be able to access it at gemini://kwiecien.us/

It's a dummy page for now before I figure out what to do with it, but I 
intend to keep Gemini running on this host for good.

My first attempt was to use geminid (written in C) because I figure it'd 
compile most easily on my system, which runs FreeBSD. It did compile 
easy, but I haven't gotten it to work just yet likely because of not 
configuring it right.

Next try was with Jetforce because I already had Python3 on the system, 
which has very limited storage so this seemed better than tinkering with 
the environment and installing stuff that I won't use for anything else.

Jetforce seems to be working nicely enough, but if you find you can't 
access it let me know so I can figure out what's wrong.

I'm having an issue with elpher where it asks me to approve the site's 
SSL cert because it says something like the issuer not being 
recognized... well that can't be right, so either I set up Jetforce a 
little bit wrong (specified the wrong files?), or this is some issue 
with elpher, which I noticed complains about the certs of most Gemini 
sites. My issuer is LetsEncrypt, which should be fine.


From jr at vrtz.ch  Fri May 15 08:05:22 2020
From: jr at vrtz.ch (Johannes von Rotz)
Date: Fri, 15 May 2020 09:05:22 +0200
Subject: Announcing kwiecien.us
In-Reply-To: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
Message-ID: <36220906-c2d8-4318-208e-60d37ee2e228@vrtz.ch>

Ben wrote:
> My first attempt was to use geminid (written in C) because I figure it'd 
> compile most easily on my system, which runs FreeBSD. It did compile 
> easy, but I haven't gotten it to work just yet likely because of not 
> configuring it right.

Hi Ben

Oh man, it still was listening on port 2222, because that's one of the
ports that are opened for outbound connections in my company's network.
Sorry about that. It's now fixed.

Also, thanks for considering my little project for serving your stuff. I
wouldn't put it into production just yet, though... :)

Cheers, J.

From benulo at systemli.org  Fri May 15 08:23:35 2020
From: benulo at systemli.org (Ben)
Date: Fri, 15 May 2020 11:53:35 +0430
Subject: Announcing kwiecien.us
In-Reply-To: <36220906-c2d8-4318-208e-60d37ee2e228@vrtz.ch>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
 <36220906-c2d8-4318-208e-60d37ee2e228@vrtz.ch>
Message-ID: <108228a8-41c0-f823-5608-ecf861821d4d@systemli.org>

Johannes,

Thanks for the quick reply! Let me know if you ever want me to test it, 
since I have it set up to compile on my system it would not be difficult.


From solderpunk at SDF.ORG  Fri May 15 08:58:02 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 07:58:02 +0000
Subject: Alternative transports,  philosophy [was: Gemini server logging
 formats and practices]
In-Reply-To: <38dd7c1f-f4ad-4137-9103-50dd75719bc2@www.fastmail.com>
References: <74dd3821-810a-4f6f-982c-2180c5ea64ef@www.fastmail.com>
 <20200513030630.GP7305@brevard.conman.org>
 <02d0aa93-ccaf-4223-990e-6b657932469d@www.fastmail.com>
 <20200513211008.GA18145@SDF.ORG>
 <I4S9Fh_s9OgwffDgzfcsFgGOhZ1b-du3uLI6-25IbWJftPtITb1-tuNDCNsudMRKt9IKX47jus2vIGtiK0NH_6tBbOhcVyTwMbwEyPTDweU=@protonmail.com>
 <b8e9faff-322f-4675-8660-3916e5e47e21@www.fastmail.com>
 <20200514205753.GQ10556@SDF.ORG>
 <fd553652-38aa-4ffb-9d9d-883e28222a6a@www.fastmail.com>
 <20200514212358.GS10556@SDF.ORG>
 <38dd7c1f-f4ad-4137-9103-50dd75719bc2@www.fastmail.com>
Message-ID: <20200515075802.GA2094@SDF.ORG>

On Thu, May 14, 2020 at 04:27:25PM -0700, Dave Huseby wrote:
> What I don't like the most about TLS is the complexity due to backwards compatibility and protocol negotiation.

I totally get this.  I really want to spec TLS 1.3 as the bare minimum
permitted for Gemini because it gets rid of a lot of that complexity.
Web browsers can't afford to do this because they need to support all
the old servers out there.  We don't have that legacy and could start
with a clean slate of a simpler, less fiddly TLS.  All that holds me
back is that this would rule out a lot of otherwise very compelling TLS
libraries which don't yet have TLS 1.3 support.

Cheers,
Solderpunk

> I still look forward to your post.
> 
> Cheers!
> Dave
> 
> On Thu, May 14, 2020, at 2:23 PM, solderpunk wrote:
> > On Thu, May 14, 2020 at 02:09:04PM -0700, Dave Huseby wrote:
> >  
> > > I surely will. I'm curious about your thinking.
> > 
> > I'm not sure you'll be completely sold, but I hope you'll see where I'm
> > coming from.
> > 
> > To try to boil it all down:  I absolutely agree that TLS has problems
> > and I don't doubt that other things, like CurveCP, might overcome or
> > avoid a lot of them.  But I believe something built on TLS is
> > overwhelmingly more likely to be widely implemented and deployed than
> > something based on literally anything else, and at the end of the day a
> > I think a good but not perfect protocol which becomes widely used and
> > supported will do a lot more good for the internet than a "perfect"
> > protocol which never becomes more than a curiosity for a small
> > community of enthusiasts.
> > 
> > This is not to say I don't think anything "strange and new" can *ever*
> > "catch on" or that I think any such efforts are a waste of time.  I wish
> > all the radical projects aiming at lofty goals all the luck in the
> > world, sincerely.  But there's a valid niche for something not quite so
> > radical which can still be a real and valuable improvement over the
> > status quo with very low barriers to adoption.
> > 
> > Cheers,
> > Solderpunk
> > 
> >

From solderpunk at SDF.ORG  Fri May 15 09:05:27 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 08:05:27 +0000
Subject: Announcing kwiecien.us
In-Reply-To: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
Message-ID: <20200515080527.GB2094@SDF.ORG>

On Fri, May 15, 2020 at 11:14:44AM +0430, Ben wrote:
 
> I'm having an issue with elpher where it asks me to approve the site's SSL
> cert because it says something like the issuer not being recognized... well
> that can't be right, so either I set up Jetforce a little bit wrong
> (specified the wrong files?), or this is some issue with elpher, which I
> noticed complains about the certs of most Gemini sites. My issuer is
> LetsEncrypt, which should be fine.

I'm not sure because I haven't used it, but perhaps Elpher is one of the
few clients (the other I know of is Bombadillo) which have implemented
the TOFU security model recommended in the spec.  Current
implementations of Gemini are fairly inconsistent with how they handle
TLS, which admittedly is my fault for speccing that clients can validate
certs however they like and just "strongly recommending" TOFU.  Many
people have fallen back on the standard CA approach.  Heck, my own client
so far doesn't do any certificate validation at all!  I'll be TOFUising
it this weekend, though.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri May 15 09:17:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 08:17:55 +0000
Subject: Announcing kwiecien.us
In-Reply-To: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
Message-ID: <20200515081755.GC2094@SDF.ORG>

On Fri, May 15, 2020 at 11:14:44AM +0430, Ben wrote:
> After being a long-time subscriber to this list while having no idea what
> Gemini (or even Gopher) is, I've gotten to the point of running my own
> server. You should be able to access it at gemini://kwiecien.us/

Thanks for letting us know, I've added it to the list!

Cheers,
Solderpunk

From plugd at thelambdalab.xyz  Fri May 15 09:38:07 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 15 May 2020 10:38:07 +0200
Subject: Announcing kwiecien.us
In-Reply-To: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
Message-ID: <lz8shth9u8.fsf@bs-mbpr348.d.ethz.ch>


Hi Ben,

Ben writes:
> I'm having an issue with elpher where it asks me to approve the site's
> SSL cert because it says something like the issuer not being
> recognized... well that can't be right, so either I set up Jetforce a
> little bit wrong (specified the wrong files?), or this is some issue
> with elpher, which I noticed complains about the certs of most Gemini
> sites. My issuer is LetsEncrypt, which should be fine.

Elpher just relies on Emacs' default Network Security Manager behaviour,
as described in the manual:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Network-Security.html.
I'm not sure why this is claiming your cert is invalid.  I'll look into
it, but I suspect the issue will be upstream from elpher.

That aside, elpher (or rather the NSM) does tend to raise warnings about every new gemini
site you visit since it's common to use self-signed certificates.  While
the spec-spec suggests a trust-on-first-use behaviour, this doesn't seem
to be possible with the NSM. This exposes three security levels: "low",
which doesn't do any security checks, "medium", which is the default
level and is what you're experiencing, and "high", which is even more stringent.

Thus I've had to choose between no certificate validation at all and the
current system.  Seeing as (a) the number of gemini sites has (until
recently) been extremely small, (b) emacs remembers accepted
self-signed/invalid certificates and doesn't ask again, and (c) at least
one person has expressed a preference for more security rather than
less, I've stuck with the "medium" setting.  However, I suspect I'm
going to have to reconsider this stance the near future due to the
amazing number of new gemini hosts appearing.

Cheers,

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/91dce597/attachment.sig>

From plugd at thelambdalab.xyz  Fri May 15 09:41:54 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 15 May 2020 10:41:54 +0200
Subject: Announcing kwiecien.us
In-Reply-To: <20200515080527.GB2094@SDF.ORG>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
 <20200515080527.GB2094@SDF.ORG>
Message-ID: <lz5zcxh9nx.fsf@bs-mbpr348.d.ethz.ch>


solderpunk writes:
> I'm not sure because I haven't used it, but perhaps Elpher is one of the
> few clients (the other I know of is Bombadillo) which have implemented
> the TOFU security model recommended in the spec.  Current

Sadly not.  As I said in my reply to Ben, it essentially implements
inverse-TOFU: distrust-on-first-use.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/7d7da321/attachment.sig>

From jr at vrtz.ch  Fri May 15 11:46:47 2020
From: jr at vrtz.ch (Johannes von Rotz)
Date: Fri, 15 May 2020 12:46:47 +0200
Subject: Announcing gemini.uxq.ch
Message-ID: <409f2e5c-70ce-ba88-1a80-97e953f3326b@vrtz.ch>

Hi all

Since my little gemini server is now able to fork, I have created my own
site: gemini://gemini.uxq.ch

There's not much going on yet, but it's probably the best way to put the
code to the test...

Cheers, J.

From cmccabe at rawtext.club  Fri May 15 12:12:48 2020
From: cmccabe at rawtext.club (cmccabe at rawtext.club)
Date: Fri, 15 May 2020 11:12:48 +0000
Subject: Announcing gemini://rawtext.club
Message-ID: <20200515111248.GA178906@rawtext.club>

Hello fellow geminoids,

I have been watching the Gemini Project from afar for some time, but only
recently took a close look.  With the spate of "announcing..." emails recently,
I thought I'd join the fun.

After a bit of hand-holding from solderpunk, I successfully installed Molly
Brown on rawtext.club, and we're off the ground.  gemini://rawtext.club
currently only hosts a mirror of the content on the server's http and gopher
sites, but I will soon link to user directories as well. 

Beyond simply hosting a main page with some neat figlet text, I have been
trying to think about unique gemini content to post.  I am reading Herman and
Chomsky's Manufacturing Consent again (I'm obsessed with the problem of the
corrupted role of news and social media in "democratic" societies) and I have
thought about posting a short book review.  Would that kind of content interest
anyone?  I think that book and similar works are a really strong motivational
backdrop for this growing activity of the decentralized internet.

Has anyone written a gemini server in awk yet?  That might be a fun challenge
too...

</end of "announcing..." email>

Stay safe everyone,
cmccabe

From me at ecmelberk.com  Fri May 15 12:52:18 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Fri, 15 May 2020 14:52:18 +0300
Subject: Announcing gemini://ecmelberk.com
Message-ID: <20200515145218.503c29f2@socimda>

Hey all!

I just wanted to let people know I am now hosting a Gemini server for
my own site.

I am currently using molly-brown as my server software, though I will
most likely fork it (or write another one myself) as I have something
specific in mind, and none of the existing software seem to be flexible
enough to do it.

For content, I am currently just converting Markdown to text/gemini (is
there any canonical name for the format?) via an ugly script, which can
be found at [1] if anyone's willing to see and use it for their own
needs.

As for my thoughts about Gemini (from someone who never used anything
but HTTP): It's really nice. The only suggestion I'd give would be to
make text/gemini have a little more flexibility in terms of formatting
(maybe like Markdown, but w/o images), but I do realise that (1) it
would be difficult to render to any TUI browser and (2) most formatting
can be accomplished via clever ASCII/ANSI art, especially if you write
it by hand and not use any scripts like I do.

Anyway, I wish Gemini succeeds, and I wish everyone a good day!

[1]: https://git.sr.ht/~admicos/ecmelberk.com/tree/master/_gemini

p.s: I also have an RSS feed at gemini://ecmelberk.com/gemini.xml if
anyone wants to subscribe to it for some reason.

From tomasino at lavabit.com  Fri May 15 13:29:39 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 15 May 2020 12:29:39 +0000
Subject: Announcing gemini://ecmelberk.com
In-Reply-To: <20200515145218.503c29f2@socimda>
References: <20200515145218.503c29f2@socimda>
Message-ID: <f64179de-e60f-ec9e-0a58-a5292421916c@lavabit.com>

On 5/15/20 11:52 AM, Ecmel Berk Canl?er wrote:
> The only suggestion I'd give would be to
> make text/gemini have a little more flexibility in terms of formatting
> (maybe like Markdown, but w/o images), but I do realise that (1) it
> would be difficult to render to any TUI browser and (2) most formatting
> can be accomplished via clever ASCII/ANSI art, especially if you write
> it by hand and not use any scripts like I do.

Gemini can serve other mime types, so if you'd like to serve
text/markdown you are able to do so. The gemini format for .gmi or
.gemini is intentionally stripped down, but is itself quite similar to
markdown.

If a few people start serving content with that mime-type, you're likely
to see some of these lovely clients add support to render it as well.


From me at ecmelberk.com  Fri May 15 13:44:21 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Fri, 15 May 2020 15:44:21 +0300
Subject: Announcing gemini://ecmelberk.com
In-Reply-To: <f64179de-e60f-ec9e-0a58-a5292421916c@lavabit.com>
References: <20200515145218.503c29f2@socimda>
 <f64179de-e60f-ec9e-0a58-a5292421916c@lavabit.com>
Message-ID: <20200515154421.43b75423@socimda>

On Fri, 15 May 2020 12:29:39 +0000
James Tomasino <tomasino at lavabit.com> wrote: 
> Gemini can serve other mime types, so if you'd like to serve
> text/markdown you are able to do so. The gemini format for .gmi or
> .gemini is intentionally stripped down, but is itself quite similar to
> markdown.
> 
> If a few people start serving content with that mime-type, you're
> likely to see some of these lovely clients add support to render it
> as well.
> 

I know it can be done, but since Markdown isn't currently a thing in
most clients, serving Markdown files (right now, at least) most likely
won't be as polished as text/gemini or plain text even.

I'm not complaining btw, The text/gemini format in it's current state
is pretty good, and does what (I assume) it's supposed to do pretty
well.

From b__m__e at mailfence.com  Fri May 15 17:42:24 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Fri, 15 May 2020 18:42:24 +0200 (CEST)
Subject: Vim Syntax update
Message-ID: <2092894479.283623.1589560944748@ichabod.co-bxl>

Just a quick note to anyone using the vim syntax I wrote:

I have updated it to work for both *.gmi and *.gemini suffixes. It had previously only worked for *.gmi as I was unaware people were using *.gemini

Feel free to re-pull and run `make`: https://tildegit.org/sloum/gemini-vim-syntax

As an aside: if there are any Windows based Vim users on the list, I would love if you were able to try installing this and see if it works. I do not have a windows machine (and dont want to spin up a virtual one) to test this one and any feedback on that side of things would be very welcome. Or if anyone wants anything added, feel free to open an issue or e-mail me directly.

--?
Sent with https://mailfence.com
Secure and private email

From gemini at gkbrk.com  Fri May 15 18:34:05 2020
From: gemini at gkbrk.com (Leo)
Date: Fri, 15 May 2020 18:34:05 +0100
Subject: DNS SRV Records
Message-ID: <df4c07c5-b387-1fda-1262-f2627a40cd26@gkbrk.com>

Hi all,
I was wondering if there are currently any Gemini clients that check SRV 
records instead of connecting to the default port.

Or if there are any plans to include this in the spec.

I think it is a good way to add Gemini support to domains without 
requiring the Gemini server to be installed on the same machine as other 
service. I think XMPP for example has benefited a lot from this.

--
Leo

From audiodude at gmail.com  Fri May 15 18:35:24 2020
From: audiodude at gmail.com (Travis Briggs)
Date: Fri, 15 May 2020 10:35:24 -0700
Subject: Announcing kwiecien.us
In-Reply-To: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
Message-ID: <CAMPYpA4Fax0pCpMdkwyYvkOo=X19Cc=QTxdSg=yGnMF4Hwnesg@mail.gmail.com>

On Thu, May 14, 2020 at 11:44 PM Ben <benulo at systemli.org> wrote:

> I'm having an issue with elpher where it asks me to approve the site's
> SSL cert because it says something like the issuer not being
> recognized... well that can't be right, so either I set up Jetforce a
> little bit wrong (specified the wrong files?), or this is some issue
> with elpher, which I noticed complains about the certs of most Gemini
> sites. My issuer is LetsEncrypt, which should be fine.
>
>
Isn't that just because, by default, Jetforce generates it's own
certificates and they are self-signed? When browsing with elpher I get this
warning all the time, it seems everyone is using self signed certificates.

For gemini://gem.bestalbumsintheuniverse.com I am also using Jetforce and
accessing with elpher, but I don't get the warnings because I used Let's
Encrypt to generate CA certificates. If you've used Let's Encrypt and
certbot before, the process is the same as if you were setting up an https
site, except that instead of passing the certs in an nginx or Apache
config, you pass the cert paths to the Jetforce startup command. For
example, here is the startup command I'm using for Jetforce:

 python3 jetforce.py --host "" --hostname gem.bestalbumsintheuniverse.com
--tls-certfile fullchain.pem --tls-keyfile privkey.pem

This is of course after I copied the fullchain.pem and privkey.pem files
from the  /etc/letsencrypt/live/gem.bestalbumsintheuniverse.com/ directory
and chown'd them to the user that runs the jetforce server.

Hope this helps!
-Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/c81921ed/attachment.htm>

From colecmac at protonmail.com  Fri May 15 18:40:58 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 15 May 2020 17:40:58 +0000
Subject: DNS SRV Records
In-Reply-To: <df4c07c5-b387-1fda-1262-f2627a40cd26@gkbrk.com>
References: <df4c07c5-b387-1fda-1262-f2627a40cd26@gkbrk.com>
Message-ID: <AxyMqmBULHu0bdGlJte9HPdZslOcVeIYXsuyGlqnpPBRx4ESSpJY3GuqzzAindU4dUnVlZOYpPbZb__hPHcC0LLVZBKeCxDSQkpyJnsZkrg=@protonmail.com>

Hello!

DNS SRV records are pretty interesting, but in my opinion this would
unnecessarily complicate the spec. Like HTTP, if you want to connect
to a non-default port you can just specify it in the URL. If you want
to run the gemini server on a different machine, there's lots of ways
to redirect that, but the simplest would be having a `gem.domain.tld`
subdomain for your domain name.

makeworld

> Hi all,
> I was wondering if there are currently any Gemini clients that check SRV
> records instead of connecting to the default port.
>
> Or if there are any plans to include this in the spec.
>
> I think it is a good way to add Gemini support to domains without
> requiring the Gemini server to be installed on the same machine as other
> service. I think XMPP for example has benefited a lot from this.
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Leo



From benulo at systemli.org  Fri May 15 19:11:03 2020
From: benulo at systemli.org (Ben)
Date: Fri, 15 May 2020 22:41:03 +0430
Subject: Announcing kwiecien.us
In-Reply-To: <CAMPYpA4Fax0pCpMdkwyYvkOo=X19Cc=QTxdSg=yGnMF4Hwnesg@mail.gmail.com>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
 <CAMPYpA4Fax0pCpMdkwyYvkOo=X19Cc=QTxdSg=yGnMF4Hwnesg@mail.gmail.com>
Message-ID: <6ff0f715-26b6-69f9-ec16-100a031b1a95@systemli.org>

Thanks Travis, I was using "cert.pem" of my host's LetsEncrypt files 
already, and they are known to be good for the other services I run. 
(None of them ever complained.) I switched to "fullchain.pem" to see if 
the result would be any different, but elpher says:

 >the certificate was signed by an unknown and therefore untrusted authority

So I guess the issue is not the cert itself, but maybe emacs or elpher 
need something to know that LetsEncrypt is a trusted authority.

But anyway, I can just permanently accept the cert so it's no big deal.

On 5/15/20 10:05 PM, Travis Briggs wrote:
> python3 jetforce.py --host "" --hostname 
> gem.bestalbumsintheuniverse.com 
> <http://gem.bestalbumsintheuniverse.com> --tls-certfile fullchain.pem 
> --tls-keyfile privkey.pem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/4dbeaa85/attachment.htm>

From jmcbray at carcosa.net  Fri May 15 20:37:16 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 15 May 2020 15:37:16 -0400
Subject: Any Windows clients?
In-Reply-To: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
Message-ID: <874ksh6lcj.fsf@dorothy.carcosa.net>


Dunderpate writes:

> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm confined
> to Windows for my day job :/ So, I was just wondering if anyone on this
> list knows of a Windows client floating around that I could use.

Last I checked, AV-98 *almost but not quite* worked on Windows; it would
probably be fairly easy to fix. Something to do with tempfile handling.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Fri May 15 20:49:23 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 15 May 2020 15:49:23 -0400
Subject: Announcing gemini://rawtext.club
In-Reply-To: <20200515111248.GA178906@rawtext.club>
References: <20200515111248.GA178906@rawtext.club>
Message-ID: <8736816ksc.fsf@dorothy.carcosa.net>


cmccabe at rawtext.club writes:

> Beyond simply hosting a main page with some neat figlet text, I have been
> trying to think about unique gemini content to post.  I am reading Herman and
> Chomsky's Manufacturing Consent again (I'm obsessed with the problem of the
> corrupted role of news and social media in "democratic" societies) and I have
> thought about posting a short book review.  Would that kind of content interest
> anyone?

I would love to read that kind of content, especially if it gets added
to CAPCOM.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From dunderpate at sdf.org  Fri May 15 21:11:59 2020
From: dunderpate at sdf.org (Dunderpate)
Date: Fri, 15 May 2020 15:11:59 -0500
Subject: Any Windows clients?
In-Reply-To: <874ksh6lcj.fsf@dorothy.carcosa.net>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
 <874ksh6lcj.fsf@dorothy.carcosa.net>
Message-ID: <b5d194f5dd1bfbc6375d4b3a5f9a1190.squirrel@mx.sdf.org>

>> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
>> confined
>> to Windows for my day job :/ So, I was just wondering if anyone on this
>> list knows of a Windows client floating around that I could use.
>
> Last I checked, AV-98 *almost but not quite* worked on Windows; it would
> probably be fairly easy to fix. Something to do with tempfile handling.

PerfectI saw AV-98 on the list of clients, but didn't know it was even
remotely close to working on Windows. I'll see if I can poke around in the
code and make it work. If I have success, I'll try to contact the author
about upstreaming the patch(es).

Thanks for the info :D
-- 
Dunderpate


From jack at sofialondonmoskva.com  Fri May 15 21:26:23 2020
From: jack at sofialondonmoskva.com (borislav nikolov)
Date: Fri, 15 May 2020 22:26:23 +0200
Subject: Announcing https://github.com/jackdoe/net-gemini - embeddable gemini
 go server
Message-ID: <CAMb_2kk4DM+5dMEOODgc8f8fdV4FUxe6wWgEYKeYr5qjCmKs9g@mail.gmail.com>

Hi,

First thanks for working on gemini! I have been struggling with the
modern web for a while, and finding this community makes me really
happy!

I would like to announce those two things:

* https://github.com/jackdoe/net-gemini
  (made it today, so fresh out of the oven)
  embeddable golang gemini server (similar to net/http)

  inspired by https://tildegit.org/solderpunk/molly-brown

  example usage:
  gemini.HandleFunc("/example", func(w *gemini.Response, r *gemini.Request) {
  if len(r.URL.RawQuery) == 0 {
  w.SetStatus(gemini.StatusInput, "what is the answer to the ultimate question")
  } else {
  w.SetStatus(gemini.StatusSuccess, "text/gemini")
  answer := r.URL.RawQuery
  w.Write([]byte("HELLO: " + r.URL.Path + ", yes the answer is: " + answer))
  }
  })
  log.Fatal(gemini.ListenAndServeTLS(":1965", "localhost.crt", "localhost.key"))

  it is easy to build dynamic content (as the example shows) without
  resorting to CGI due to go's setuid limitation.

* gemini://berserk.red
  shell + web/gemini/finger hosting

  for example:
    gemini://berserk.red/~jack

  I have a small hosting for my friends on https://berserk.red we use
  it for talk(1) and other things. This is just to showcase usage of
  net-gemini, and I used it to test and develop the api.


-b

From solderpunk at SDF.ORG  Fri May 15 21:32:07 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 20:32:07 +0000
Subject: Any Windows clients?
In-Reply-To: <b5d194f5dd1bfbc6375d4b3a5f9a1190.squirrel@mx.sdf.org>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
 <874ksh6lcj.fsf@dorothy.carcosa.net>
 <b5d194f5dd1bfbc6375d4b3a5f9a1190.squirrel@mx.sdf.org>
Message-ID: <20200515203207.GA5879@SDF.ORG>

On Fri, May 15, 2020 at 03:11:59PM -0500, Dunderpate wrote:
 
> PerfectI saw AV-98 on the list of clients, but didn't know it was even
> remotely close to working on Windows. I'll see if I can poke around in the
> code and make it work. If I have success, I'll try to contact the author
> about upstreaming the patch(es).

Please do!  It would be great to have AV-98 work on as many platforms as
possible.  I think this should be very possible, I've probably just been
lazy about path manipulations somewhere or something like that.

Hmm, well, it will, by default, try calling out to programs like `cat`
and `less` which it may not find (although I understand there's a lot
more support for unix-like userspace in modern Windows?).  That should
all be fixable with some calls to `handler` (which you can then stick in
an rc file to make persistent).  Let me know if you have problems with
any of this.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri May 15 21:35:25 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 20:35:25 +0000
Subject: Announcing gemini.uxq.ch
In-Reply-To: <409f2e5c-70ce-ba88-1a80-97e953f3326b@vrtz.ch>
References: <409f2e5c-70ce-ba88-1a80-97e953f3326b@vrtz.ch>
Message-ID: <20200515203525.GC5879@SDF.ORG>

Thanks, it's on the list!

Cheers,
Solderpunk
On Fri, May 15, 2020 at 12:46:47PM +0200, Johannes von Rotz wrote:
> Hi all
> 
> Since my little gemini server is now able to fork, I have created my own
> site: gemini://gemini.uxq.ch
> 
> There's not much going on yet, but it's probably the best way to put the
> code to the test...
> 
> Cheers, J.

From solderpunk at SDF.ORG  Fri May 15 21:38:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 20:38:59 +0000
Subject: Announcing gemini://ecmelberk.com
In-Reply-To: <20200515145218.503c29f2@socimda>
References: <20200515145218.503c29f2@socimda>
Message-ID: <20200515203859.GD5879@SDF.ORG>

On Fri, May 15, 2020 at 02:52:18PM +0300, Ecmel Berk Canl?er wrote:
 
> I just wanted to let people know I am now hosting a Gemini server for
> my own site.

Thanks for the heads up, it's on the list now.
 
> converting Markdown to text/gemini (is
> there any canonical name for the format?)

Some people have called text/gemini documents "Geminimaps", generalising
from "Gophermaps".  I haven't officially "endorsed" anything yet (at
least not that I remember doing!), but that name certainly doesn't
bother me.

> p.s: I also have an RSS feed at gemini://ecmelberk.com/gemini.xml if
> anyone wants to subscribe to it for some reason.

Hmm, maybe I need to think about adding RSS support to CAPCOM...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri May 15 21:41:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 20:41:19 +0000
Subject: Vim Syntax update
In-Reply-To: <2092894479.283623.1589560944748@ichabod.co-bxl>
References: <2092894479.283623.1589560944748@ichabod.co-bxl>
Message-ID: <20200515204119.GE5879@SDF.ORG>

On Fri, May 15, 2020 at 06:42:24PM +0200, Brian Evans wrote:
 
> I have updated it to work for both *.gmi and *.gemini suffixes. It had previously only worked for *.gmi as I was unaware people were using *.gemini

Oh, I must have missed the initial announcement!  Sorry.  This is now
listed on the software list.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri May 15 21:45:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 20:45:54 +0000
Subject: Announcing kwiecien.us
In-Reply-To: <CAMPYpA4Fax0pCpMdkwyYvkOo=X19Cc=QTxdSg=yGnMF4Hwnesg@mail.gmail.com>
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
 <CAMPYpA4Fax0pCpMdkwyYvkOo=X19Cc=QTxdSg=yGnMF4Hwnesg@mail.gmail.com>
Message-ID: <20200515204554.GF5879@SDF.ORG>

On Fri, May 15, 2020 at 10:35:24AM -0700, Travis Briggs wrote:

> it seems everyone is using self signed certificates.

Not everyone, but many people, because the spec strongly encourages this,
in conjunction with a ssh-style TOFU model.  Few clients are doing
this yet, but I hope that will change.  I'm unsure about somethings,
though; I'm going to start a conversation about this in the near future.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Fri May 15 21:50:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 20:50:16 +0000
Subject: DNS SRV Records
In-Reply-To: <AxyMqmBULHu0bdGlJte9HPdZslOcVeIYXsuyGlqnpPBRx4ESSpJY3GuqzzAindU4dUnVlZOYpPbZb__hPHcC0LLVZBKeCxDSQkpyJnsZkrg=@protonmail.com>
References: <df4c07c5-b387-1fda-1262-f2627a40cd26@gkbrk.com>
 <AxyMqmBULHu0bdGlJte9HPdZslOcVeIYXsuyGlqnpPBRx4ESSpJY3GuqzzAindU4dUnVlZOYpPbZb__hPHcC0LLVZBKeCxDSQkpyJnsZkrg=@protonmail.com>
Message-ID: <20200515205016.GG5879@SDF.ORG>

On Fri, May 15, 2020 at 05:40:58PM +0000, colecmac at protonmail.com wrote:
> Hello!
> 
> DNS SRV records are pretty interesting, but in my opinion this would
> unnecessarily complicate the spec.

I don't think this would necessarily need to clutter up the main spec -
this is a "companion spec" kind of thing, like robots.txt or other
things like that.

Ideas for those are kind of piling up, it's probably high time to do
some documenting and delegating...

Cheers,
Solderpunk

From sean at conman.org  Fri May 15 22:01:15 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 15 May 2020 17:01:15 -0400
Subject: Any Windows clients?
In-Reply-To: <20200515203207.GA5879@SDF.ORG>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
 <874ksh6lcj.fsf@dorothy.carcosa.net>
 <b5d194f5dd1bfbc6375d4b3a5f9a1190.squirrel@mx.sdf.org>
 <20200515203207.GA5879@SDF.ORG>
Message-ID: <20200515210115.GC24022@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Fri, May 15, 2020 at 03:11:59PM -0500, Dunderpate wrote:
>  
> > PerfectI saw AV-98 on the list of clients, but didn't know it was even
> > remotely close to working on Windows. I'll see if I can poke around in the
> > code and make it work. If I have success, I'll try to contact the author
> > about upstreaming the patch(es).
> 
> Please do!  It would be great to have AV-98 work on as many platforms as
> possible.  I think this should be very possible, I've probably just been
> lazy about path manipulations somewhere or something like that.
> 
> Hmm, well, it will, by default, try calling out to programs like `cat`
> and `less` which it may not find (although I understand there's a lot
> more support for unix-like userspace in modern Windows?).  That should
> all be fixable with some calls to `handler` (which you can then stick in
> an rc file to make persistent).  Let me know if you have problems with
> any of this.

  On Unix, there are several programs that examine $PAGER (the environment
variable) to know which program to use to paginate output.  Two other
environment variables that might be useful are $VISUAL and $EDITOR (both for
editing text), $TEMP (Windows), $TMP and $TMPDIR (Unix) for a directory for
temporary files.

  -spc

From solderpunk at SDF.ORG  Fri May 15 22:01:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 15 May 2020 21:01:44 +0000
Subject: Announcing https://github.com/jackdoe/net-gemini - embeddable
 gemini go server
In-Reply-To: <CAMb_2kk4DM+5dMEOODgc8f8fdV4FUxe6wWgEYKeYr5qjCmKs9g@mail.gmail.com>
References: <CAMb_2kk4DM+5dMEOODgc8f8fdV4FUxe6wWgEYKeYr5qjCmKs9g@mail.gmail.com>
Message-ID: <20200515210144.GH5879@SDF.ORG>

Thanks for the announcements, I've listed both!

Your server throws a "41 not found" status in response to requests for
gemini://berserk.red, only working correctly for gemini://berserk.red/
(with a trailing slash).  And the "not found" status could should be
51, not 41!

Cheers,
Solderpunk

On Fri, May 15, 2020 at 10:26:23PM +0200, borislav nikolov wrote:
> Hi,
> 
> First thanks for working on gemini! I have been struggling with the
> modern web for a while, and finding this community makes me really
> happy!
> 
> I would like to announce those two things:
> 
> * https://github.com/jackdoe/net-gemini
>   (made it today, so fresh out of the oven)
>   embeddable golang gemini server (similar to net/http)
> 
>   inspired by https://tildegit.org/solderpunk/molly-brown
> 
>   example usage:
>   gemini.HandleFunc("/example", func(w *gemini.Response, r *gemini.Request) {
>   if len(r.URL.RawQuery) == 0 {
>   w.SetStatus(gemini.StatusInput, "what is the answer to the ultimate question")
>   } else {
>   w.SetStatus(gemini.StatusSuccess, "text/gemini")
>   answer := r.URL.RawQuery
>   w.Write([]byte("HELLO: " + r.URL.Path + ", yes the answer is: " + answer))
>   }
>   })
>   log.Fatal(gemini.ListenAndServeTLS(":1965", "localhost.crt", "localhost.key"))
> 
>   it is easy to build dynamic content (as the example shows) without
>   resorting to CGI due to go's setuid limitation.
> 
> * gemini://berserk.red
>   shell + web/gemini/finger hosting
> 
>   for example:
>     gemini://berserk.red/~jack
> 
>   I have a small hosting for my friends on https://berserk.red we use
>   it for talk(1) and other things. This is just to showcase usage of
>   net-gemini, and I used it to test and develop the api.
> 
> 
> -b

From sean at conman.org  Fri May 15 22:07:36 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 15 May 2020 17:07:36 -0400
Subject: Announcing gemini://ecmelberk.com
In-Reply-To: <20200515145218.503c29f2@socimda>
References: <20200515145218.503c29f2@socimda>
Message-ID: <20200515210735.GD24022@brevard.conman.org>

It was thus said that the Great Ecmel Berk Canl?er once stated:
> Hey all!

  Hello.

> I just wanted to let people know I am now hosting a Gemini server for
> my own site.
> 
> I am currently using molly-brown as my server software, though I will
> most likely fork it (or write another one myself) as I have something
> specific in mind, and none of the existing software seem to be flexible
> enough to do it.

  I'm curious as to the feature you have in mind.  Care to share?

> As for my thoughts about Gemini (from someone who never used anything
> but HTTP): It's really nice. The only suggestion I'd give would be to
> make text/gemini have a little more flexibility in terms of formatting
> (maybe like Markdown, but w/o images), but I do realise that (1) it
> would be difficult to render to any TUI browser and (2) most formatting
> can be accomplished via clever ASCII/ANSI art, especially if you write
> it by hand and not use any scripts like I do.

  Check the archives [1] for previous discussions.  It won't be hard to find
them, as they make up about half the posts so far.

> Anyway, I wish Gemini succeeds, and I wish everyone a good day!

  Thanks.

  -spc

[1]	https://lists.orbitalfox.eu/archives/gemini/

From stryan at saintnet.tech  Fri May 15 22:12:45 2020
From: stryan at saintnet.tech (Steve Ryan)
Date: Fri, 15 May 2020 17:12:45 -0400
Subject: ANN: SecretShop 1.0.0 and saintnet.tech
Message-ID: <20200515211245.r22x5esz3npfyfw3@vineta.saintnet.lan>

Hi all,

SecretShop, a Gemini server written in Go, is now available for
download. You can grab the source from my Git repo[1]. The latest
version is actually 1.0.1 as I released a quick fix after.

Technically this has existed for a while, but I finally got around to
handling certificates and officially releasing a 1.0 so I figured I'd
make a formal announcement.

I've also packaged it up on OBS so any OpenSuse users can download an
RPM for it from my home repo[2]. Fedora and other RPM users will be
coming next, followed up by Debian whenever I learn how to generated deb
files. The repo might be a bit behind and only have 1.0.0 right now but
that should change.

I've also set up my own capsule at saintnet.tech[3], both as a personal
site and as a demonstration of SecretShop. There ain't much there yet
but I'm working on it. It'll probably end up being a mismatch of
personal posts, metal reviews, and random rants about tech, philosphy,
and weird religions.

Cheers,
Steve

[1] https://git.saintnet.tech/stryan/secretshop
[2] https://build.opensuse.org/project/show/home:stryan
[3] gemini://saintnet.tech


From jack at sofialondonmoskva.com  Fri May 15 22:19:42 2020
From: jack at sofialondonmoskva.com (borislav nikolov)
Date: Fri, 15 May 2020 23:19:42 +0200
Subject: Announcing https://github.com/jackdoe/net-gemini - embeddable
 gemini go server
In-Reply-To: <20200515210144.GH5879@SDF.ORG>
References: <CAMb_2kk4DM+5dMEOODgc8f8fdV4FUxe6wWgEYKeYr5qjCmKs9g@mail.gmail.com>
 <20200515210144.GH5879@SDF.ORG>
Message-ID: <CAMb_2kkR_1OaOjNsV8MxW6YOS4o6PpbrqcWyBi4RS1Gsit3Auw@mail.gmail.com>

Thanks!

I fixed both issues, thanks for spotting them! I was testing with
asuka and bombadillo and I think both of them added trailing slash,
thanks for spotting it!

slash issue:
https://github.com/jackdoe/net-gemini/commit/02c261b052edbc409f83b65f64a6654bc38e39c6

status code issue:
https://github.com/jackdoe/net-gemini/commit/d0cc95e98ebdd35ff0424fd61c13c77833184bc8

and re-deployed.

-b

On Fri, 15 May 2020 at 23:01, solderpunk <solderpunk at sdf.org> wrote:
>
> Thanks for the announcements, I've listed both!
>
> Your server throws a "41 not found" status in response to requests for
> gemini://berserk.red, only working correctly for gemini://berserk.red/
> (with a trailing slash).  And the "not found" status could should be
> 51, not 41!
>
> Cheers,
> Solderpunk
>
> On Fri, May 15, 2020 at 10:26:23PM +0200, borislav nikolov wrote:
> > Hi,
> >
> > First thanks for working on gemini! I have been struggling with the
> > modern web for a while, and finding this community makes me really
> > happy!
> >
> > I would like to announce those two things:
> >
> > * https://github.com/jackdoe/net-gemini
> >   (made it today, so fresh out of the oven)
> >   embeddable golang gemini server (similar to net/http)
> >
> >   inspired by https://tildegit.org/solderpunk/molly-brown
> >
> >   example usage:
> >   gemini.HandleFunc("/example", func(w *gemini.Response, r *gemini.Request) {
> >   if len(r.URL.RawQuery) == 0 {
> >   w.SetStatus(gemini.StatusInput, "what is the answer to the ultimate question")
> >   } else {
> >   w.SetStatus(gemini.StatusSuccess, "text/gemini")
> >   answer := r.URL.RawQuery
> >   w.Write([]byte("HELLO: " + r.URL.Path + ", yes the answer is: " + answer))
> >   }
> >   })
> >   log.Fatal(gemini.ListenAndServeTLS(":1965", "localhost.crt", "localhost.key"))
> >
> >   it is easy to build dynamic content (as the example shows) without
> >   resorting to CGI due to go's setuid limitation.
> >
> > * gemini://berserk.red
> >   shell + web/gemini/finger hosting
> >
> >   for example:
> >     gemini://berserk.red/~jack
> >
> >   I have a small hosting for my friends on https://berserk.red we use
> >   it for talk(1) and other things. This is just to showcase usage of
> >   net-gemini, and I used it to test and develop the api.
> >
> >
> > -b

From sean at conman.org  Fri May 15 22:32:51 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 15 May 2020 17:32:51 -0400
Subject: DNS SRV Records
In-Reply-To: <20200515205016.GG5879@SDF.ORG>
References: <df4c07c5-b387-1fda-1262-f2627a40cd26@gkbrk.com>
 <AxyMqmBULHu0bdGlJte9HPdZslOcVeIYXsuyGlqnpPBRx4ESSpJY3GuqzzAindU4dUnVlZOYpPbZb__hPHcC0LLVZBKeCxDSQkpyJnsZkrg=@protonmail.com>
 <20200515205016.GG5879@SDF.ORG>
Message-ID: <20200515213251.GE24022@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Fri, May 15, 2020 at 05:40:58PM +0000, colecmac at protonmail.com wrote:
> > Hello!
> > 
> > DNS SRV records are pretty interesting, but in my opinion this would
> > unnecessarily complicate the spec.
> 
> I don't think this would necessarily need to clutter up the main spec -
> this is a "companion spec" kind of thing, like robots.txt or other
> things like that.

  Kind of.  One issue is:  given the URL:

	gemini://gemini.example.com/

does that mean a client has to look up the SRV RR for 'gemini.example.com'
before defaulting to port 1965?  Also, it's not like there can only be one
SRV RR for a given service.  Hypothetically, a client could get this back:

			         P    W  port  host
-------------------------------------------------------------
_gemini._tcp.example.net. IN SRV 10    1 1965 backupserver3.example.net.
			  IN SRV 0     0 1965 server3.example.net.
			  IN SRV 0  5000 1965 server1.example.net.
			  IN SRV 10    2 1966 backupserver2.example.net.
			  IN SRV 10    3 1967 backupserver1.example.net.
			  IN SRV 5     0 1965 redundant1.example.net.
			  IN SRV 0  1000 1965 server2.example.net.
			  IN SRV 0  5000 5691 server3.example.net.
			  IN SRV 5     0 1965 redundant2.example.net.
			  IN SRV 5     0 2020 redundant3.example.net.


		P = priority - lower values first 
		W = weight - higher values first

  A client would need to sort the list based upon priority (lower first),
then by weight (higher first), then pick a server at random among those with
the same priority and weight.  So according to this list, a client would
have to first attempt to contact

		pick one at random
			server1.example.net:1965
			server3.example.net:6591

and last

		backupserver3.example.net:1965

It's all spelled out in RFC-2782 [1].

  Is this a pathological case?  Yes.  Will most SRV records have one entry? 
Probably, but that's a gut feeling, I don't have actual numbers to look at.
And unlike looking up an A or AA RR with the "standard" POSIX function
getaddrinfo(), there is not simple API that I am aware of for the SRV RR.
Also, an SRV RR query might require a second A/AAAA RR lookup [2].

  -spc (Just some things to keep in mind ... )

[1]	Shameless plug---I wote a DNS library in C:

		https://github.com/spc476/SPCDNS

	Yeah, that's why I know this stuff.

[2]	Depends upon the DNS server.  Some will return the answer along with
	additional records to avoid further queries, some won't.

From audiodude at gmail.com  Fri May 15 23:10:18 2020
From: audiodude at gmail.com (Travis Briggs)
Date: Fri, 15 May 2020 15:10:18 -0700
Subject: Wikipedia mirror over gemini "proxy"
Message-ID: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>

Hello,

I have an idea for quickly and vastly expanding the amount of content that
is available in Geminispace. What about a Wikipedia mirror/proxy? I put
proxy in quotes because it would modify the documents it returned in order
to be largely text based.

The main thing that's tripping
<https://en.wikipedia.org/wiki/Psychedelic_experience> me up is the fact
that wikipedia <https://en.wikipedia.org> articles are written
<https://en.wikipedia.org/wiki/Writing> with a lot of inline links. And
navigating those links is a key part of the Wikipedia browsing experience.

My naive read of the text/gemini format is that I would have to do
something like:

The main thing that's
=> gemini://gem.wiki-mirror.pizza/article.cgi?Tripping tripping
me up is the fact that
=> gemini://gem.wiki-mirror.pizza/article.cgi?Wikipedia wikipedia
articles are
=> gemini://gem.wiki-mirror.pizza/article.cgi?Writing written
with a lot of inline links.

Which seems really clunky. The other option I'm considering is serving
text/markdown, which I assume most Gemini clients would display as plain
text. The problem then is that [links won't be clickable](http://dev/null).
But maybe the mere existence of so much markdown content would incentivize
some client author to add native support?

Feedback is appreciated, thanks!
-Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/101e20e7/attachment-0001.htm>

From colecmac at protonmail.com  Fri May 15 23:19:29 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 15 May 2020 22:19:29 +0000
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
Message-ID: <FYFfC9L--u8Jl6t8Vt7RZi2D-WmjL0aODgSIs2CEMBNvkS-F6-rSWmIgQFMRh4v7EaWZY4sDkRFbmqikbrnOc8No0ja1_VDnAlHHGmlAaTI=@protonmail.com>

Personally, I think markdown would make the most sense in this usecase.

> I have an idea for quickly and vastly expanding the amount of content
> that is available in Geminispace. What about a Wikipedia mirror/proxy?

I think this idea is kinda flawed. I can only speak for myself,
but I'm guessing that most people here want the Geminispace to expand
naturally, and for interesting and unique content to come up. There's
nothing wrong with a Wikipedia proxy, but I feel like it misses the
point a bit. If I want to read Wikipedia, I would just use Firefox.

makeworld

??????? Original Message ???????
On Friday, May 15, 2020 6:10 PM, Travis Briggs <audiodude at gmail.com> wrote:

> Hello,
>
> I have an idea for quickly and vastly expanding the amount of content that is available in Geminispace. What about a Wikipedia mirror/proxy? I put proxy in quotes because it would modify the documents it returned in order to be largely text based.
>
> The main thing that's tripping me up is the fact that wikipedia articles are written with a lot of inline links. And navigating those links is a key part of the Wikipedia browsing experience.
>
> My naive read of the text/gemini format is that I would have to do something?like:
>
> The main thing that's
> =>?gemini://gem.wiki-mirror.pizza/article.cgi?Tripping?tripping
> me up is the fact that
> => gemini://gem.wiki-mirror.pizza/article.cgi?Wikipedia wikipedia
> articles are
> => gemini://gem.wiki-mirror.pizza/article.cgi?Writing written
> with a lot of inline links.
>
> Which seems really clunky. The other option I'm considering is serving text/markdown, which I assume most Gemini clients would display as plain text. The problem then is that [links won't be clickable](http://dev/null). But maybe the mere existence of so much markdown content would incentivize some client author to add native support?
>
> Feedback is appreciated, thanks!
> -Travis



From sean at conman.org  Fri May 15 23:23:21 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 15 May 2020 18:23:21 -0400
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
Message-ID: <20200515222321.GG24022@brevard.conman.org>

It was thus said that the Great Travis Briggs once stated:
> Hello,
> 
> I have an idea for quickly and vastly expanding the amount of content that
> is available in Geminispace. What about a Wikipedia mirror/proxy? I put
> proxy in quotes because it would modify the documents it returned in order
> to be largely text based.
> 
> The main thing that's tripping
> <https://en.wikipedia.org/wiki/Psychedelic_experience> me up is the fact
> that wikipedia <https://en.wikipedia.org> articles are written
> <https://en.wikipedia.org/wiki/Writing> with a lot of inline links. And
> navigating those links is a key part of the Wikipedia browsing experience.
> 
> My naive read of the text/gemini format is that I would have to do
> something like:
> 
> The main thing that's
> => gemini://gem.wiki-mirror.pizza/article.cgi?Tripping tripping
> me up is the fact that
> => gemini://gem.wiki-mirror.pizza/article.cgi?Wikipedia wikipedia
> articles are
> => gemini://gem.wiki-mirror.pizza/article.cgi?Writing written
> with a lot of inline links.
> 
> Which seems really clunky. The other option I'm considering is serving
> text/markdown, which I assume most Gemini clients would display as plain
> text. The problem then is that [links won't be clickable](http://dev/null).
> But maybe the mere existence of so much markdown content would incentivize
> some client author to add native support?

  Okay, here's a blog post I made a few days ago [1] and how it could be
rendered into a text/gemini.

  -spc

[1]	http://boston.conman.org/2020/04/23.1

===

Of course, after I point the finger to LibreSSL [1] for the memory leak, I
find the leak ? in my own code.

=> gemini://boston.conman.org/2020/04/22.1 [1]

Sigh.

Not knowing what else to do, I thought I would go through my TLS Lua module
[2] to make sure I didn't miss anything. That's when I noticed that I was
keeping a reference to a connection so that I can deal with the callbacks
[3] from libtls. I was expecting the __gc() method to clean things up, but
with a (non-weak) reference, that was never going to happen.

=> https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c [2]
=> https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c#L107 [3]

Yes, just because you are using a garbage collected language doesn't mean
you can't still have memory leaks.

I verified that, yes indeed, the references were being kept around after the
request was finished. It was then straightforward to fix the issue.

That's not to say that libtls still isn't leaking memory?it is, but (it
seems) only when you initialize it (which means it's not as bad). But I'll
know in a day or two if I fixed the leak. I hope that was it.

From benulo at systemli.org  Fri May 15 23:25:25 2020
From: benulo at systemli.org (Ben)
Date: Sat, 16 May 2020 02:55:25 +0430
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
Message-ID: <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>

I was actually thinking of this problem today with respect to converting 
content with in-line linking to Gemini format.

So far the best idea I could imagine is that during the conversion 
process the linked items are marked (for example, number in superscript) 
in reference to a list of links provided below, basically as a footnote 
or appendix either to the paragraph, section, or the entire page.

Maybe not ideal, but with a little experimentation this method could 
result in a format that's pleasing/readable and also navigable 
especially if the user can manipulate their client to jump to the link 
they want... for example, by numbers or tabbing through them or some 
other jump mechanism.

Or maybe Gemini should support in-line links of its own? It's already 
got some markdown elements in other aspects of page formatting.

On 5/16/20 2:40 AM, Travis Briggs wrote:
> The main thing that's tripping 
> <https://en.wikipedia.org/wiki/Psychedelic_experience> me up is the 
> fact that wikipedia <https://en.wikipedia.org> articles are written 
> <https://en.wikipedia.org/wiki/Writing> with a lot of inline links.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200516/23c36593/attachment.htm>

From audiodude at gmail.com  Fri May 15 23:25:04 2020
From: audiodude at gmail.com (Travis Briggs)
Date: Fri, 15 May 2020 15:25:04 -0700
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <20200515222321.GG24022@brevard.conman.org>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <20200515222321.GG24022@brevard.conman.org>
Message-ID: <CAMPYpA76N5ZoxbaEyqTezCfThb_wkER9ET4GFX3MHi_GTiavOA@mail.gmail.com>

On Fri, May 15, 2020 at 3:23 PM Sean Conner <sean at conman.org> wrote:

>   Okay, here's a blog post I made a few days ago [1] and how it could be
> rendered into a text/gemini.
>

This looks like a really nice idea. Do you think it's a problem that for
long Wikipedia articles, the refs could go into the hundreds or even
thousands [1345]?

[1345] //dev/nul

-Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/7379d97e/attachment.htm>

From benulo at systemli.org  Fri May 15 23:27:20 2020
From: benulo at systemli.org (Ben)
Date: Sat, 16 May 2020 02:57:20 +0430
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <FYFfC9L--u8Jl6t8Vt7RZi2D-WmjL0aODgSIs2CEMBNvkS-F6-rSWmIgQFMRh4v7EaWZY4sDkRFbmqikbrnOc8No0ja1_VDnAlHHGmlAaTI=@protonmail.com>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <FYFfC9L--u8Jl6t8Vt7RZi2D-WmjL0aODgSIs2CEMBNvkS-F6-rSWmIgQFMRh4v7EaWZY4sDkRFbmqikbrnOc8No0ja1_VDnAlHHGmlAaTI=@protonmail.com>
Message-ID: <9dee1bad-3541-367b-9b4a-c323bcf33fbb@systemli.org>

We need to make our own wiki ;)

On 5/16/20 2:49 AM, colecmac at protonmail.com wrote:
> I'm guessing that most people here want the Geminispace to expand
> naturally

From sean at conman.org  Fri May 15 23:38:50 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 15 May 2020 18:38:50 -0400
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <CAMPYpA76N5ZoxbaEyqTezCfThb_wkER9ET4GFX3MHi_GTiavOA@mail.gmail.com>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <20200515222321.GG24022@brevard.conman.org>
 <CAMPYpA76N5ZoxbaEyqTezCfThb_wkER9ET4GFX3MHi_GTiavOA@mail.gmail.com>
Message-ID: <20200515223850.GH24022@brevard.conman.org>

It was thus said that the Great Travis Briggs once stated:
> On Fri, May 15, 2020 at 3:23 PM Sean Conner <sean at conman.org> wrote:
> 
> >   Okay, here's a blog post I made a few days ago [1] and how it could be
> > rendered into a text/gemini.
> 
> This looks like a really nice idea. Do you think it's a problem that for
> long Wikipedia articles, the refs could go into the hundreds or even
> thousands [1345]?

  Don't know until I see it.  But I don't think it will be that bad, given
the links appear below the paragraph they're found in.

  -spc (Give it a try if you can ... )


From sean at conman.org  Fri May 15 23:41:01 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 15 May 2020 18:41:01 -0400
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
Message-ID: <20200515224101.GI24022@brevard.conman.org>

It was thus said that the Great Ben once stated:
> Or maybe Gemini should support in-line links of its own? It's already 
> got some markdown elements in other aspects of page formatting.

  As I said before, check the archives [1] for previous discussions.  It
won't be hard to find them, as they make up about half the posts so far.

  -spc (It's a popular bike shedding topic ... )

[1]	https://lists.orbitalfox.eu/archives/gemini/


From b__m__e at mailfence.com  Fri May 15 23:55:13 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sat, 16 May 2020 00:55:13 +0200 (CEST)
Subject: Wikipedia mirror over gemini "proxy"
Message-ID: <234068207.304950.1589583313029@ichabod.co-bxl>

This was done for gopher and can be found here:

gopher://gopherpedia.com:70/1

You may be able to pick up some tricks from what they did (and possibly improve upon it).
I have used gopherpedia a good amount and would probably use a gemini version. That said,
I do think it would be nice to build out original (non-web-mirroring) content. But that certainly
doesnt mean that we cant or should have some degree of both!


--?
Sent with https://mailfence.com
Secure and private email

From plugd at thelambdalab.xyz  Sat May 16 00:00:05 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Sat, 16 May 2020 01:00:05 +0200
Subject: Any Windows clients?
In-Reply-To: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
Message-ID: <lzwo5ckdmy.fsf@bs-mbpr348.d.ethz.ch>


Dunderpate writes:
> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm confined
> to Windows for my day job :/ So, I was just wondering if anyone on this
> list knows of a Windows client floating around that I could use.

Provided you have emacs installed, the elpher package is known to work
under windows.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200516/7de0f4b2/attachment.sig>

From luke.emmet at gmail.com  Sat May 16 00:09:05 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sat, 16 May 2020 00:09:05 +0100
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <20200515224101.GI24022@brevard.conman.org>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
 <20200515224101.GI24022@brevard.conman.org>
Message-ID: <5EBF2111.4020304@gmail.com>

Hmm this convention of using square bracket note-citations inline, 
followed by the URL. It seems nice and gemini-friendly.

How widely used is that? Can it be "recommended" as a good practice if 
you want to do inline links?

I'm thinking if it is a sufficiently established practice, clients can 
look for this pattern. And then when a suitably designed client if it 
sees this, could reverse the process to provide an inline clickable 
link, and then no need to duplicate the URL in the displayed content

e.g. Source of

"some text with a citation [1] more text etc

=> gemini://domain/path [1]

next paragraph"

is then simply rendered as

"some text with a citation [1] more text etc

next paragraph"

and when rendered by the client, the "[1]" is an active element.

Regards

  - Luke

On 15-May-2020 23:41, Sean Conner wrote:
> It was thus said that the Great Ben once stated:
>> Or maybe Gemini should support in-line links of its own? It's already
>> got some markdown elements in other aspects of page formatting.
>    As I said before, check the archives [1] for previous discussions.  It
> won't be hard to find them, as they make up about half the posts so far.
>
>    -spc (It's a popular bike shedding topic ... )
>
> [1]	https://lists.orbitalfox.eu/archives/gemini/
>

From luke.emmet at gmail.com  Sat May 16 00:18:31 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sat, 16 May 2020 00:18:31 +0100
Subject: Any Windows clients?
In-Reply-To: <lzwo5ckdmy.fsf@bs-mbpr348.d.ethz.ch>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
 <lzwo5ckdmy.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <5EBF2347.6070003@gmail.com>

The other options of course are to use the web proxys via a web browser.

https://portal.mozz.us/gemini/gemini.circumlunar.space/

https://proxy.vulpes.one/gemini/gemini.circumlunar.space

They both work nicely, but it is slightly more obvious with the first 
how to go directly to a URL (rather browse a link to it), as there is a 
text box at the top of each page. In the second you have to hack the 
URL, but the UI rendering is more visually appealing IMO.

  - L

On 16-May-2020 00:00, plugd wrote:
> Dunderpate writes:
>> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm confined
>> to Windows for my day job :/ So, I was just wondering if anyone on this
>> list knows of a Windows client floating around that I could use.
> Provided you have emacs installed, the elpher package is known to work
> under windows.
>
> Tim

From plugd at thelambdalab.xyz  Sat May 16 01:13:46 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Sat, 16 May 2020 02:13:46 +0200
Subject: Elpher 2.7.0: the text/gemini update
Message-ID: <lztv0gg2it.fsf@bs-mbpr348.d.ethz.ch>

Hi all,

Anybody using elpher might be interested to know that I've just pushed a
number of gemini-centric improvements/changes.

Changes specific to text/gemini:

* Text wraps at word boundaries near 80 columns or the window width,
  whichever is smaller.

* Text wrapping works sensibly with bullets, indenting wrapped lines.

* Pre-formatted text blocks work.

* Styles are applied to headers (different font sizes by default and
  when possible.

* Removed the left hand margin which used to contain link types, which
  was a result of reusing gophermap rendering functions and doesn't
  make as much sense in gemini (which lacks a finite set of link types).
  Links are still coloured according to protocol, however.

Changes relating to network connections:

* I've optimized the functions responsible for retrieving gemini, gopher
  and finger content, resulting in a massive improvement in transfer
  rate.  (That's a very positive way to say that I've replaced a very
  silly function with a more sensible one.)  It wasn't practical to
  download mp3s previously, now it is.

* Given the slew of new servers, I've altered the default server
  certificate verification policy to, erm, not verify certificates.
  Even though this behaviour is configurable, I feel a bit dirty about
  this.  Hopefully I'll find a way to implement a proper tofu behaviour
  in the future.

Changes missing from this update:

* !! Support for client certificates. :-( !!


The new version is already up on MELPA and should be up on MELPA Stable
within the hour.

Cheers,

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200516/72f57b91/attachment.sig>

From sean at conman.org  Sat May 16 01:22:09 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 15 May 2020 20:22:09 -0400
Subject: An observation about client certificates
In-Reply-To: <fdee9e98-528b-4bad-b154-859721b1e3e4@www.fastmail.com>
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <fdee9e98-528b-4bad-b154-859721b1e3e4@www.fastmail.com>
Message-ID: <20200516002209.GJ24022@brevard.conman.org>

It was thus said that the Great Dave Huseby once stated:
> 
> I think by default, any logging we do should be at a bare minimum and not
> contain the IP address of the client or any other data that would link the
> log line to them. I added logging to my hacked up version of Pollux but it
> only logs which page was loaded and when. My purpose was to track basic
> traffic and any errors that occur and nothing else.

  I am not trolling here.  The scenaio I'll describe is *actually* happening
to me as I write this message.

  Over the past hour, I've over 2,700 requests in my client torture test,
specifically, test #22, leading into the "Redirect From Hell" portion.  If
it was going any faster, I'd probably block it with the firewall, but my
question to Dave is, what happens on your server when something like this
happens?  You don't log the IP, so now what?  

  -spc (I'll go under my bridge now ... )


From audiodude at gmail.com  Sat May 16 01:41:00 2020
From: audiodude at gmail.com (Travis Briggs)
Date: Fri, 15 May 2020 17:41:00 -0700
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <234068207.304950.1589583313029@ichabod.co-bxl>
References: <234068207.304950.1589583313029@ichabod.co-bxl>
Message-ID: <CAMPYpA5wjfhqhJ=rVGcJ9N7UeS_yA-DpfUm=o=3LkLsXUijPxQ@mail.gmail.com>

Thanks for the pointer, that's really helpful and cool and basically
exactly what I was hoping to accomplish.

Basically a "Simpsons did it" moment for me. Ah well.

But I've contacted the author and maybe I can get some insight into what
could be done differently the second time around.

Cheers,
-Travis

On Fri, May 15, 2020 at 3:55 PM Brian Evans <b__m__e at mailfence.com> wrote:

> This was done for gopher and can be found here:
>
> gopher://gopherpedia.com:70/1
>
> You may be able to pick up some tricks from what they did (and possibly
> improve upon it).
> I have used gopherpedia a good amount and would probably use a gemini
> version. That said,
> I do think it would be nice to build out original (non-web-mirroring)
> content. But that certainly
> doesnt mean that we cant or should have some degree of both!
>
>
> --
> Sent with https://mailfence.com
> Secure and private email
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200515/6eb17e40/attachment.htm>

From invis at park-city.club  Sat May 16 02:10:29 2020
From: invis at park-city.club (invis at park-city.club)
Date: Sat, 16 May 2020 01:10:29 +0000
Subject: Announcing gemini://park-city.club
Message-ID: <b34b719d3bf7b9d434854fcadff96d5b@park-city.club>

Might as well join in on the announcements bandwagon. :p

I'm hosting a server at gemini://park-city.club. It's for the "netgroup"/not-quite-pubnix that I admin, Park City. We're a *lot* more active at https://park-city.club, but we have a small-but-respectable gopher presence as well. I'm mostly planning on having the Gemini server be a rehost of the Gopher content, with perhaps some of the HTML content as well if I can get that working smoothly enough.

Right now we're using molly-brown as our server, as it just worked really. I only set it up yesterday, so the only thing we're hosting at the moment is a rehost of my personal phlog (which i need to move to my tilde still) and some experiments with color and inline graphics. I'll try to add some more stuff moving forwards, but maintaining content for three protocols is a *bit* tricky.

Some of the other park city members were commenting that they'd be more likely to use Gemini if they had a way to set background/text colors and give their pages a *little* bit of flair. The HTML versions of cosmic.voyage and gemini.circumlunar.space were pointed out as good examples. I know that's not exactly what the standard is aiming for, but I do understand their concern over wanting to personalize their space a *little* bit. But I'm sure we'll play around and see what we can make regardless.

I can't wait to see where the Gemini project goes. There's a lot of potential here.

-- InvisibleUp (https://invisibleup.com)

-- Email domain proudly hosted at https://migadu.com


From benulo at systemli.org  Sat May 16 03:19:46 2020
From: benulo at systemli.org (Ben)
Date: Sat, 16 May 2020 06:49:46 +0430
Subject: Elpher 2.7.0: the text/gemini update
In-Reply-To: <lztv0gg2it.fsf@bs-mbpr348.d.ethz.ch>
References: <lztv0gg2it.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <2d0a88e0-338c-8401-95dd-7db97cd4f630@systemli.org>

I love this! Elpher was already the best client I've used so far, but 
this update just takes the cake. 1000x improvement.


From colecmac at protonmail.com  Sat May 16 04:41:05 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 16 May 2020 03:41:05 +0000
Subject: Ambiguity in the gemini document spec
Message-ID: <mrKqZN-1kETSQwHbs5da0moglHnseriGyMzR8NJ7pTtJ8gUOm1tvOb8L6YeGvck5EtmQ8_kZ3R6uAnABzM0LKKBxnfpltYQK8cnmYNzdIok=@protonmail.com>

Hello everyone! Although this is mostly directed to solderpunk.

I've noticed something that's not clearly defined in the part of
the Gemini spec that concerns the text/gemini format. Specifically,
something should be added in section 1.3.5.1 or 1.3.5.2.

The link specification in 1.3.5.3.2 defines links as:

=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>

But no where else in the spec does it say that lines must end with
<CR><LF> characters, in fact how lines end is not defined at all. I haven't
inspected a lot of gemini sites, but I suspect that most of them
just use <LF>, aka \n, for line endings, because that is the default
for most text editors. And I suspect that most clients are fine with
this, for links or any other text lines.

My suggestion is to change the spec to explicitly say that lines end
with <LF>, with the <CR> part being optional. This could apply to
URL requests, etc, as well, but that's not really necessary, it would
just be nice.

This change will bring the current practices of users and clients into
spec, and it will also clear up that ambiguity.

Let me know what you think!

Thank you,
makeworld


From me at ecmelberk.com  Sat May 16 07:19:44 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Sat, 16 May 2020 09:19:44 +0300
Subject: Announcing gemini://ecmelberk.com
In-Reply-To: <20200515210735.GD24022@brevard.conman.org>
References: <20200515145218.503c29f2@socimda>
 <20200515210735.GD24022@brevard.conman.org>
Message-ID: <20200516091944.6e94bd51@socimda>

On Fri, 15 May 2020 17:07:36 -0400
Sean Conner <sean at conman.org> wrote:

>   I'm curious as to the feature you have in mind.  Care to share?

I am essentially looking for some way to replicate the nginx
configuration at [1], which if done, would allow for a GitHub Pages-like
"`git push` to publish" system for Gemini.

The wildcard portion of it might be done with scripts listening for new
directories and updating server configuration accordingly, but most
of the server software I checked out didn't have good (if any) vhost
support.

[1]:
https://git.sr.ht/~admicos/nginxpages/tree/master/nginx/default.conf#L3-8

From sean at conman.org  Sat May 16 09:04:18 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 16 May 2020 04:04:18 -0400
Subject: Announcing gemini://ecmelberk.com
In-Reply-To: <20200516091944.6e94bd51@socimda>
References: <20200515145218.503c29f2@socimda>
 <20200515210735.GD24022@brevard.conman.org> <20200516091944.6e94bd51@socimda>
Message-ID: <20200516080417.GO24022@brevard.conman.org>

It was thus said that the Great Ecmel Berk Canl?er once stated:
> On Fri, 15 May 2020 17:07:36 -0400
> Sean Conner <sean at conman.org> wrote:
> 
> >   I'm curious as to the feature you have in mind.  Care to share?
> 
> I am essentially looking for some way to replicate the nginx
> configuration at [1], which if done, would allow for a GitHub Pages-like
> "`git push` to publish" system for Gemini.

  Huh.  If I understand that fragment [2] it seems to maybe use some form of
regex to map directory names to domain names?  Or something?  It allows the
importing of a number of sites per name?  

  And yeah, the virtual hosting in Gemini is pretty weak right now---I would
have thought there would be more servers that support it, but no, I checked
each one listed [3] and only found two that support vhosts:

	gemserv
	GLV-1.12556 [4]

> The wildcard portion of it might be done with scripts listening for new
> directories and updating server configuration accordingly, but most
> of the server software I checked out didn't have good (if any) vhost
> support.

  Define "good vhost support."  Is it---ease of configuration?  Actual
support?  

  -spc

> [1] https://git.sr.ht/~admicos/nginxpages/tree/master/nginx/default.conf#L3-8

[2]	I run Apache (and have since the late 90s) and never really looked
	at Nginx.

[3]	https://portal.mozz.us/gemini/gemini.circumlunar.space/software/

[4]	I thought a certificate had to list all possible hosts on the
	server, but no, you can use multiple certificates.  Learned that and
	rewrote GLV-1.12556 to support multiple sites over the past two
	days.


From julien at typed-hole.org  Sat May 16 16:12:20 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 16 May 2020 17:12:20 +0200
Subject: Any Windows clients?
In-Reply-To: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
Message-ID: <469bd947-d0e9-9270-6826-550b8afcf286@typed-hole.org>

If you're feeling adventurous, someone sent me instructions to build
Castor (https://git.sr.ht/~julienxx/castor) on Windows without WSL.

https://gist.github.com/sexybiggetje/3a4df41bb7f304aab02ea6006944f283

Haven't tried it myself.

Cheers!
--julienxx

On 5/14/20 8:29 PM, Dunderpate wrote:
> Hi everyone,
>
> I just wanted to start out by thanking you all for a great project, spec
> and community. It's great to see and hear other people with the same
> desire for a simpler web.
>
> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm confined
> to Windows for my day job :/ So, I was just wondering if anyone on this
> list knows of a Windows client floating around that I could use.
>
> Thanks everyone!

From fabrixxm at kirgroup.net  Sat May 16 16:17:26 2020
From: fabrixxm at kirgroup.net (Fabio)
Date: Sat, 16 May 2020 17:17:26 +0200
Subject: Any Windows clients?
In-Reply-To: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
Message-ID: <2TJFAQ.QMXFTMSB42CD2@kirgroup.net>



Il giorno gio 14 mag 2020 alle 13:29, Dunderpate <dunderpate at sdf.org> 
ha scritto:
> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm 
> confined
> to Windows for my day job :/ So, I was just wondering if anyone on 
> this
> list knows of a Windows client floating around that I could use.
> 

Hi Dunderpate

I didn't tried but I would say that Alrisha 
(https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on 
windows without any problem...




From jan at mecinus.com  Sat May 16 18:49:47 2020
From: jan at mecinus.com (Jan Schreiber)
Date: Sat, 16 May 2020 19:49:47 +0200
Subject: Announcing jan.bio & ncgopher gemini support
Message-ID: <20200516174947.53prbeayzhbq4wxt@badister>

Hi,

after a long time of lurking on this list, I've finally installed jetforce on
my server [1]. There is not much to see at the moment, but I'm working on it.

I've also implemented rudimentary gemini support in my gopher client ncgopher [2].
There are still a lot of rough edges, especially some keyboard commands that only
work on gophermaps and not on gemini, but it's getting better every day. I pretty
much use ncgopher as my primary gemini client and fix what comes along.

One of the issues that has come up with other clients is that they block
on binary downloads. ncgopher downloads files in background, indicating
the number of bytes read (a bit like lynx). This way, you can continue browsing
while downloading your favourite konpeito mix.

ncgopher is written in Rust, which some people hate and others love. I started
to implement this client to teach myself rust, so it's far from perfect.

However, the client is known to compile on FreeBSD (my primary system), OpenBSD,
Linux (tested on Debian and Arch), and OS X. Maybe Windows works as well.

More features will be coming available in the next weeks. Feel free to create
an issue on [2], if you encounter any bugs.

- Jan

[1] gemini://jan.bio
[2] https://github.com/jansc/ncgopher

-- 
 Fry: Where's Captain Bender? Off catastrophizing some other planet? 

From colecmac at protonmail.com  Sun May 17 01:43:50 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 17 May 2020 00:43:50 +0000
Subject: [ANN] md2gemini - a markdown to gemini converter
Message-ID: <6sG0WJBwFejSWNurE3TsVXz1ckZXhk7qj8V9pu9Q517poYLaZGfGAOJuzfeHI6pDdGNrCTRvCvNwvOrncD8k5YpWSXQunA9-e4cYxjxB8Hg=@protonmail.com>

Evening Geminauts!

I've created another Gemini tool, they're lots of fun.
This one takes Markdown files and converts them into the Gemini
text format. I've heard some people mention something like this
on the mailing list before, and I wanted to make it, so hear you
go! Hope it can be used well.

My ideal usage was to allow for easy bi-hosting of blogs. Often
blogs are written in Markdown, and then transformed with tools
like Jekyll. md2gemini could transform those markdown files into
files ready to host on Gemini. It could even be part of a CGI script,
to convert files on the fly.

In my opinion, its "killer feature" is that it supports markdown tables,
converting them into Unicode or ASCII tables instead. It can also strip
Jekyll front matter [0] from files, which I hope will make bi-hosting with
Jekyll easier.

[0] https://jekyllrb.com/docs/front-matter/

Obviously markdown and gemini are not directly compatible. When things
in markdown don't apply to gemini, I just left them in plain text.
This applies to indented lists, block quotes, inline code, etc.
There was discussion earlier about footnote links, which is something I plan
to support, but for now this code just takes inline links and converts them
into gemini links, splitting up the paragraph.

It's available at https://github.com/makeworld-the-better-one/md2gemini
Let me know what you think!

makeworld

From benulo at systemli.org  Sun May 17 02:24:37 2020
From: benulo at systemli.org (Ben)
Date: Sun, 17 May 2020 05:54:37 +0430
Subject: [ANN] md2gemini - a markdown to gemini converter
In-Reply-To: <6sG0WJBwFejSWNurE3TsVXz1ckZXhk7qj8V9pu9Q517poYLaZGfGAOJuzfeHI6pDdGNrCTRvCvNwvOrncD8k5YpWSXQunA9-e4cYxjxB8Hg=@protonmail.com>
References: <6sG0WJBwFejSWNurE3TsVXz1ckZXhk7qj8V9pu9Q517poYLaZGfGAOJuzfeHI6pDdGNrCTRvCvNwvOrncD8k5YpWSXQunA9-e4cYxjxB8Hg=@protonmail.com>
Message-ID: <43a11859-02d3-805b-f519-01344ddd31a5@systemli.org>

Hey, I installed this using `pip3 install --user md2gemini` and the 
installation appears to have succeeded, but at the moment there doesn't 
seem to be an md2gemini executable or script that I could run from the 
command line.


From b__m__e at mailfence.com  Sun May 17 03:21:05 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 17 May 2020 04:21:05 +0200 (CEST)
Subject: [ANN] Gemini Mailing List gemini mirror
Message-ID: <1044942723.361254.1589682065502@ichabod.co-bxl>

Hi all,
Given all the recent activity on the mailing list I thought
it might be nice to see what is going on with the protocol
via the protocol itself.

I wrote a little scraper (woefully inefficient, but is getting the
job done) and have the results set to update on a CRON every
6 hours at this location:

gemini://rawtext.club:1965/~sloum/geminilist/

I'll be improving the output formatting of the posts themselves
over time, but it is pretty readable at present (I hope).

Enjoy!

From colecmac at protonmail.com  Sun May 17 04:03:21 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 17 May 2020 03:03:21 +0000
Subject: [ANN] md2gemini - a markdown to gemini converter
In-Reply-To: <43a11859-02d3-805b-f519-01344ddd31a5@systemli.org>
References: <6sG0WJBwFejSWNurE3TsVXz1ckZXhk7qj8V9pu9Q517poYLaZGfGAOJuzfeHI6pDdGNrCTRvCvNwvOrncD8k5YpWSXQunA9-e4cYxjxB8Hg=@protonmail.com>
 <43a11859-02d3-805b-f519-01344ddd31a5@systemli.org>
Message-ID: <GEBKrWUoNjoLPSSARHiuLONNFV2tkpfCQa4CJAoYU_pYqpupV-nLiIoaLsuBtLJqPygdfIBTNMAfQheUVWYOjxvv50Qc4CLwv_EXlrJnVHM=@protonmail.com>

Glad to hear you tried it!

So I looked into some things, and it looks like I made a mistake
with the package. Sorry about that, it's my first time putting one
on PyPI. For now, you should be able to run it with:

python3 -m md2gemini <options here>

I will find out how to have an executable and update the package.
I might not announce the update here, but feel free to watch the project
on Github, and/or update using pip.

Thanks for catching this!

makeworld

??????? Original Message ???????
On Saturday, May 16, 2020 9:24 PM, Ben <benulo at systemli.org> wrote:

> Hey, I installed this using `pip3 install --user md2gemini` and the
> installation appears to have succeeded, but at the moment there doesn't
> seem to be an md2gemini executable or script that I could run from the
> command line.



From aaron at ajanse.me  Sun May 17 04:05:46 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 16 May 2020 20:05:46 -0700
Subject: Announcing `gurl`: like `curl` but for gemini
Message-ID: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>

I just thought it would be helpful to have a tool that interfaces with gemini on the rawest level. I forked this from solderpunk's demo python client. Cheers!

https://github.com/aaronjanse/gurl

P.S. I'm working on writing actual, gemini-exclusive content that's not about gemini itself. Wish me luck!

~ Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200516/762b3a72/attachment-0001.htm>

From colecmac at protonmail.com  Sun May 17 04:23:35 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 17 May 2020 03:23:35 +0000
Subject: [ANN] md2gemini - a markdown to gemini converter
In-Reply-To: <43a11859-02d3-805b-f519-01344ddd31a5@systemli.org>
References: <6sG0WJBwFejSWNurE3TsVXz1ckZXhk7qj8V9pu9Q517poYLaZGfGAOJuzfeHI6pDdGNrCTRvCvNwvOrncD8k5YpWSXQunA9-e4cYxjxB8Hg=@protonmail.com>
 <43a11859-02d3-805b-f519-01344ddd31a5@systemli.org>
Message-ID: <c41Al4JJEYeR_1c8MNqGktiqlIyw-nDQXNwCHkSWqaCtgyNWI5xl5RY-Mup24fWm4-1CLTWS_0uM0BoIJIhLds-scRiz9UuIrAM5LBeECco=@protonmail.com>

Okay, I just fixed it, it should work now. Thanks for catching
that! Just update it through pip.

If you or anyone else finds anymore issues, or has feature requests,
feel free to email me or make an issue on Github!

makeworld

??????? Original Message ???????
On Saturday, May 16, 2020 9:24 PM, Ben <benulo at systemli.org> wrote:

> Hey, I installed this using `pip3 install --user md2gemini` and the
> installation appears to have succeeded, but at the moment there doesn't
> seem to be an md2gemini executable or script that I could run from the
> command line.



From felix at masterq32.de  Sun May 17 04:27:26 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 17 May 2020 05:27:26 +0200
Subject: Announcing `gurl`: like `curl` but for gemini + release of `gurl`
 like `curl` but by another person
In-Reply-To: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
Message-ID: <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>

Hey!

> I just thought it would be helpful to have a tool that interfaces with gemini on the rawest level. I forked this from solderpunk's demo python client. Cheers!

Congratulations on your release!

> https://github.com/aaronjanse/gurl
I'm laughing so hard right now. I *just* wanted to write an email ...
with the exact same topic!

So i feel free and hijack this topic a bit:

I just released my curl-similar client `gurl` [0] in a really early
version right now. It supports basic interaction with the protocol, but
does not follow redirects or does TOFU atm. But is already a pretty good
request  debugging tool.

Currently only supports linux builds, but i try to integrate windows and
freebsd support as well

Regards
xq

PS.: Sorry Aaron for thread hijacking, but the topic is perfect

[0] https://github.com/MasterQ32/gurl/releases/tag/v0.1

From colecmac at protonmail.com  Sun May 17 04:28:26 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 17 May 2020 03:28:26 +0000
Subject: [ANN] Gemini Mailing List gemini mirror
In-Reply-To: <1044942723.361254.1589682065502@ichabod.co-bxl>
References: <1044942723.361254.1589682065502@ichabod.co-bxl>
Message-ID: <ifXCEWB5tiUFJfkkVmv8ncKoBtn4j8haiwJb-3R813UTJ6Se__zrisfmoJ_n8OU79rbljVLvt9eOBnCU9q-mN6S_aapwWw_4K1n7RI3O8gs=@protonmail.com>

Good idea, thanks! The only problem I see is that I can't
access the server right now ;)

Port 1965 seems to be closed?

makeworld



From colecmac at protonmail.com  Sun May 17 04:38:12 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 17 May 2020 03:38:12 +0000
Subject: Announcing `gurl`: like `curl` but for gemini + release of `gurl`
 like `curl` but by another person
In-Reply-To: <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
Message-ID: <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>

Gemini now has two tools that do the same job, by the same name...
It's too good haha

Now I know what solderpunk means when he talks about our software
to server ratio...

Although I suppose I can't throw stones when I've made two tools
and have ideas for more, but still don't have a server yet :)

makeworld

From colecmac at protonmail.com  Sun May 17 05:52:59 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 17 May 2020 04:52:59 +0000
Subject: Gemini IRC logs... on Gemini!
Message-ID: <OSrhLrcwlN6Apx-tlbke8IzZ94eavWyXlJT17rFiQ-eLPSWRBit6cCPXMpVa557OAjlIY4x1Q5Cf4UV-8Rgu8bEmN5tfMYW3PNLJhmEg_Lg=@protonmail.com>

The busy mailing list has finally been winding down for
the night... Or night where I am anyway.

But I wanted to make one last announcement. I've put the
Gemini IRC logs on Gemini! They're available on my new
server: gemini://makeworld.gq

The direct link is gemini://makeworld.gq/cgi-bin/gemini-irc
for now, if that changes they'll always be a link on my
homepage.

If you didn't know about this already, there's an IRC server
for Gemini you can come join, at #gemini on tilde.chat.

Hope to see the rest of you there!

Good <localtime greeting>,
makeworld

From aaron at ajanse.me  Sun May 17 06:03:18 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 16 May 2020 22:03:18 -0700
Subject: =?UTF-8?Q?Re:_Announcing_`gurl`:_like_`curl`_but_for_gemini_+_release_of?=
 =?UTF-8?Q?_`gurl`_like_`curl`_but_by_another_person?=
In-Reply-To: <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
Message-ID: <1cfbeaaf-c3e3-47c5-8f61-a0e41404c3fb@www.fastmail.com>

> Gemini now has two tools that do the same job, by the same name...
> It's too good haha

Oh, ha. I had no idea.

> Now I know what solderpunk means when he talks about our software
> to server ratio...

I agree 100%. I hope I can redeem myself by writing some actual content.

From aaron at ajanse.me  Sun May 17 06:23:54 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sat, 16 May 2020 22:23:54 -0700
Subject: Writing emails in text/gemini?
Message-ID: <07a648e6-4b11-4ff9-9865-31b0824bb964@www.fastmail.com>

I love that Gemini recommends writing long lines and letting the client wrap text. However, it seems like this mailing list is still being written in plaintext hard-wrapped at 80-columns. This makes reading the mailing list difficult on mobile.

Is there opposition to letting people here format their emails in text/gemini (i.e. long lines)?

P.S. I've been subscribed for a while, but I can't find the answer by searching the mailing list messages I've received: what happened to block quote syntax in text/gemini?

~ Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200516/8c6df484/attachment.htm>

From me at ecmelberk.com  Sun May 17 07:30:12 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Sun, 17 May 2020 09:30:12 +0300
Subject: [ANN] Gemini Mailing List gemini mirror
In-Reply-To: <1044942723.361254.1589682065502@ichabod.co-bxl>
References: <1044942723.361254.1589682065502@ichabod.co-bxl>
Message-ID: <20200517093012.25349b6f@socimda>

On Sun, 17 May 2020 04:21:05 +0200 (CEST)
Brian Evans <b__m__e at mailfence.com> wrote:
> I wrote a little scraper (woefully inefficient, but is getting the
> job done) and have the results set to update on a CRON every
> 6 hours at this location:

Wouldn't it be better to have a mail server scripted to write the mails
into files instead of a scraper? It would be almost real-time.

Or, just hook it up into an email account (say, your own) and listen
for new mails there? That wouldn't be as responsive as the above, but
~5 minutes are better than 6 hours IMO.

Just throwing out ideas, feel free to say no :)

From solderpunk at SDF.ORG  Sun May 17 09:40:04 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 08:40:04 +0000
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
Message-ID: <20200517084004.GA23565@SDF.ORG>

On Sat, May 16, 2020 at 02:55:25AM +0430, Ben wrote:
 
> Or maybe Gemini should support in-line links of its own? It's already got
> some markdown elements in other aspects of page formatting.

I'm really not keen on adding in-line links.  It would significantly
increase the effort involved in parsing text/gemini documents - instead
of peeking at the first 3 characters of a line and then being able to
handle it, every line has to be split up into words and each word tested
individually.

Yes, there are e.g. Markdown libraries out there which will do this, but
they're only usable if we adopt Markdown wholesale, which brings in a
whole load of other problems.  Not to mention that almost none of those
libraries do anything other than convert to HTML, etc.).

The current text/gemini definition was very carefully and painstakingly
arrived at after a lot of discussion.  I'm not saying it's perfect, but
I think any future changes to it will be very minor, and something like
a switch to in-line links is pretty well off-the-table at this point.

I acknowledge that when you are used to being able to link in-line, not
being able to feels weird and different and like you are forced into
clunky ways of formatting your text.  But the one-line-per-link format
has real advantages, aside from extreme simplicity of parsing of
presentation.  It makes links extremely easy to find, and it encourages
neat, well-organised layout where links are put into related lists.  It
works very well in particular for "landing pages" - text/gemini as a
whole does, actually - the combination of headers, subheaders and
sub-subheaders via #, ## and ###, with one-line-per-link, strongly
encourages you to structure your site neatly and to layout the entire
structure on the front page so that navigation is an absolute breeze.
Chalk and cheese, when compared to modern websites.

For content it doesn't always work as well, but before deciding that it
just cannot work I propose we make a concerted effort to develop new
writing habits/conventions which work with it as well as possible.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sun May 17 09:41:49 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 08:41:49 +0000
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <5EBF2111.4020304@gmail.com>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
 <20200515224101.GI24022@brevard.conman.org>
 <5EBF2111.4020304@gmail.com>
Message-ID: <20200517084149.GB23565@SDF.ORG>

On Sat, May 16, 2020 at 12:09:05AM +0100, Luke Emmet wrote:
 
> How widely used is that? Can it be "recommended" as a good practice if you
> want to do inline links?

It's extremely widely used on Gopher, where you can't do any actual
linking from within content pages (without resorting to ugly hacks
that work well in practice but are definitely a violation of the spirit
of the protocol).

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sun May 17 09:44:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 08:44:28 +0000
Subject: Announcing gemini://park-city.club
In-Reply-To: <b34b719d3bf7b9d434854fcadff96d5b@park-city.club>
References: <b34b719d3bf7b9d434854fcadff96d5b@park-city.club>
Message-ID: <20200517084428.GC23565@SDF.ORG>

On Sat, May 16, 2020 at 01:10:29AM +0000, invis at park-city.club wrote:
 
> I'm hosting a server at gemini://park-city.club. It's for the "netgroup"/not-quite-pubnix that I admin, Park City.

It's on the known server list now.  Welcome to Geminispace!  Nice to see
pubnix-esque places adopting the protocol.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 17 09:49:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 08:49:26 +0000
Subject: Ambiguity in the gemini document spec
In-Reply-To: <mrKqZN-1kETSQwHbs5da0moglHnseriGyMzR8NJ7pTtJ8gUOm1tvOb8L6YeGvck5EtmQ8_kZ3R6uAnABzM0LKKBxnfpltYQK8cnmYNzdIok=@protonmail.com>
References: <mrKqZN-1kETSQwHbs5da0moglHnseriGyMzR8NJ7pTtJ8gUOm1tvOb8L6YeGvck5EtmQ8_kZ3R6uAnABzM0LKKBxnfpltYQK8cnmYNzdIok=@protonmail.com>
Message-ID: <20200517084926.GD23565@SDF.ORG>

On Sat, May 16, 2020 at 03:41:05AM +0000, colecmac at protonmail.com wrote:
> Hello everyone! Although this is mostly directed to solderpunk.
> 
> I've noticed something that's not clearly defined in the part of
> the Gemini spec that concerns the text/gemini format. Specifically,
> something should be added in section 1.3.5.1 or 1.3.5.2.
> 
> The link specification in 1.3.5.3.2 defines links as:
> 
> =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>
> 
> But no where else in the spec does it say that lines must end with
> <CR><LF> characters, in fact how lines end is not defined at all.

Thanks for bringing this to my attention, somebody raised the same point
to me on Mastodon at about the same time.

I'm quite surprised this spec ambiguity hasn't been mentioned before
now!  Perhaps it has, it sounds very vaguely familiar.  I think at the
time nobody thought it mattered much. But the fact that, unlike HTML,
the text/gemini format is explicitly line-oriented, means that this is
actually an important point.

I strongly suspect the use of <CR><LF> in 1.3.5.3.2 is simply the result
of me being in the habit of using it elsewhere in the spec while talking
about the request and response syntax.

This definitely needs to be cleared up, I've added it to the list of
things to address once the spec-freeze thaws (soon!).  In principle the
freeze shouldn't apply to real problems which definitely need solving,
but it's close enough to over now, and this problem, while real,
obviously hasn't caused any actual practical difficulties, so there's no
need to rush it.

Cheers,
Solderpunk

From fabrixxm at kirgroup.net  Sun May 17 09:53:45 2020
From: fabrixxm at kirgroup.net (Fabio)
Date: Sun, 17 May 2020 10:53:45 +0200
Subject: Ambiguity in the gemini document spec
In-Reply-To: <20200517084926.GD23565@SDF.ORG>
References: <mrKqZN-1kETSQwHbs5da0moglHnseriGyMzR8NJ7pTtJ8gUOm1tvOb8L6YeGvck5EtmQ8_kZ3R6uAnABzM0LKKBxnfpltYQK8cnmYNzdIok=@protonmail.com>
 <20200517084926.GD23565@SDF.ORG>
Message-ID: <LPWGAQ.51TFL3D71CGC@kirgroup.net>


Just to add another small point: also in links section 1.3.5.3.2 it says


	=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>

	where:

	* <whitespace> is any non-zero number of consecutive spaces or
	  tabs

	[...]

	All the following examples are valid link lines:

	[...]

	=>gemini://example.org/bar Yet another example link at the same host


so, the first whitespace can be a zero number of consecutive spaces or 
tabs :)



From jan6 at tilde.ninja  Sun May 17 09:57:13 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 08:57:13 +0000
Subject: Ambiguity in the gemini document spec
In-Reply-To: <LPWGAQ.51TFL3D71CGC@kirgroup.net>
References: <LPWGAQ.51TFL3D71CGC@kirgroup.net>
 <mrKqZN-1kETSQwHbs5da0moglHnseriGyMzR8NJ7pTtJ8gUOm1tvOb8L6YeGvck5EtmQ8_kZ3R6uAnABzM0LKKBxnfpltYQK8cnmYNzdIok=@protonmail.com>
 <20200517084926.GD23565@SDF.ORG>
Message-ID: <f97dafb74a23738a70611035e70a413b@tilde.ninja>

May 17, 2020 11:53 AM, "Fabio" <fabrixxm at kirgroup.net> wrote:
> =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>
> 
> =>gemini://example.org/bar Yet another example link at the same host
> 
> so, the first whitespace can be a zero number of consecutive spaces or tabs :)

it also says that

* Square brackets indicate that the enclosed content is
  optional.

From solderpunk at SDF.ORG  Sun May 17 10:13:32 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:13:32 +0000
Subject: Announcing jan.bio & ncgopher gemini support
In-Reply-To: <20200516174947.53prbeayzhbq4wxt@badister>
References: <20200516174947.53prbeayzhbq4wxt@badister>
Message-ID: <20200517091332.GF23565@SDF.ORG>

Howdy,

Both your server and client are now on the appropriate lists, thanks for sharing!
It's nice to see another combined Gopher/Gemini client on the list.

I think the fact that Gemini documents can straightforwardly link out to
content on other protocols without resorting to hacks is one of its
nicer improvements over Gopher.  Clients which support both protocols
make it easier to take full advantage of that.

On Sat, May 16, 2020 at 07:49:47PM +0200, Jan Schreiber wrote:
 
> One of the issues that has come up with other clients is that they block
> on binary downloads. ncgopher downloads files in background, indicating
> the number of bytes read (a bit like lynx). This way, you can continue browsing
> while downloading your favourite konpeito mix.

Hey, that's outstanding, good work!  I have always hoped that better
client design could be a solution to that problem, rather than adding
content length information into the response header.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 17 10:19:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:19:15 +0000
Subject: [ANN] md2gemini - a markdown to gemini converter
In-Reply-To: <6sG0WJBwFejSWNurE3TsVXz1ckZXhk7qj8V9pu9Q517poYLaZGfGAOJuzfeHI6pDdGNrCTRvCvNwvOrncD8k5YpWSXQunA9-e4cYxjxB8Hg=@protonmail.com>
References: <6sG0WJBwFejSWNurE3TsVXz1ckZXhk7qj8V9pu9Q517poYLaZGfGAOJuzfeHI6pDdGNrCTRvCvNwvOrncD8k5YpWSXQunA9-e4cYxjxB8Hg=@protonmail.com>
Message-ID: <20200517091915.GG23565@SDF.ORG>

Nice work, thanks for a useful little tool!  It's on the software list
now.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 17 10:26:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:26:15 +0000
Subject: [ANN] Gemini Mailing List gemini mirror
In-Reply-To: <1044942723.361254.1589682065502@ichabod.co-bxl>
References: <1044942723.361254.1589682065502@ichabod.co-bxl>
Message-ID: <20200517092615.GH23565@SDF.ORG>

On Sun, May 17, 2020 at 04:21:05AM +0200, Brian Evans wrote:

> Hi all,
> Given all the recent activity on the mailing list I thought
> it might be nice to see what is going on with the protocol
> via the protocol itself.

Great idea!  Obvious in retrospect, but congrats and thanks for actually
coming up with it and implementing it.  It will be great to be able to
link to previous discussion with gemini:// links
 
> gemini://rawtext.club:1965/~sloum/geminilist/

As somebody else reported, I can't connect right now but I guess that's
just a temporary issue at RTC.  I look forward to seeing this later.
Does it have nice thread-aware navigation?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 17 10:31:22 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:31:22 +0000
Subject: Announcing `gurl`: like `curl` but for gemini + release of
 `gurl` like `curl` but by another person
In-Reply-To: <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
Message-ID: <20200517093122.GI23565@SDF.ORG>

On Sun, May 17, 2020 at 03:38:12AM +0000, colecmac at protonmail.com wrote:
> Gemini now has two tools that do the same job, by the same name...
> It's too good haha

Well, this is awkward...how do you want these projects listed at the
software page?

> Now I know what solderpunk means when he talks about our software
> to server ratio...

I mean, it's not necessarily a bad thing, just terribly surprising and
kind of strange.  But I'm mostly taking it as a sign of success - it's
clearly possible for people to build their own Gemini tools quickly and
easily which was part of the whole idea.

My big concern is that during this period of high interest after
appearing on popular news sites, lots of people will write software in
their initial excitement then get bored and moved on, we'll make some
spec changes which require updates to thta software but it won't happen,
and we'll end up with a lot of slightly broken software around.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 17 10:33:43 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:33:43 +0000
Subject: Gemini IRC logs... on Gemini!
In-Reply-To: <OSrhLrcwlN6Apx-tlbke8IzZ94eavWyXlJT17rFiQ-eLPSWRBit6cCPXMpVa557OAjlIY4x1Q5Cf4UV-8Rgu8bEmN5tfMYW3PNLJhmEg_Lg=@protonmail.com>
References: <OSrhLrcwlN6Apx-tlbke8IzZ94eavWyXlJT17rFiQ-eLPSWRBit6cCPXMpVa557OAjlIY4x1Q5Cf4UV-8Rgu8bEmN5tfMYW3PNLJhmEg_Lg=@protonmail.com>
Message-ID: <20200517093343.GJ23565@SDF.ORG>

On Sun, May 17, 2020 at 04:52:59AM +0000, colecmac at protonmail.com wrote:
 
> But I wanted to make one last announcement. I've put the
> Gemini IRC logs on Gemini! They're available on my new
> server: gemini://makeworld.gq

Fantastic!  Thanks for doing this.  Between this and the mailing list
mirror it's now possible to consume almost all discussion of Gemini via
Gemini itself, which feels like a nice milestone!  I'll definitely be
keeping an eye on this.
 
> If you didn't know about this already, there's an IRC server
> for Gemini you can come join, at #gemini on tilde.chat.

Well, there's an IRC *channel* for Gemini on tilde.chat - which is an
IRC sever for an awful lot more than just Gemini. :)

Cheers,
Solderpunk

From aaron at ajanse.me  Sun May 17 10:41:28 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sun, 17 May 2020 02:41:28 -0700
Subject: =?UTF-8?Q?Re:_Announcing_`gurl`:_like_`curl`_but_for_gemini_+_release_of?=
 =?UTF-8?Q?_`gurl`_like_`curl`_but_by_another_person?=
In-Reply-To: <20200517093122.GI23565@SDF.ORG>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
 <20200517093122.GI23565@SDF.ORG>
Message-ID: <7725e263-dca5-4d4c-bfe7-cd9261e21efa@www.fastmail.com>

> Well, this is awkward...how do you want these projects listed at the
> software page?

Maybe just state the programming language? I'd put MasterQ32's implementation
first because they published first.

~ Aaron

From solderpunk at SDF.ORG  Sun May 17 10:42:25 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:42:25 +0000
Subject: Writing emails in text/gemini?
In-Reply-To: <07a648e6-4b11-4ff9-9865-31b0824bb964@www.fastmail.com>
References: <07a648e6-4b11-4ff9-9865-31b0824bb964@www.fastmail.com>
Message-ID: <20200517094225.GK23565@SDF.ORG>

On Sat, May 16, 2020 at 10:23:54PM -0700, Aaron Janse wrote:
 
> Is there opposition to letting people here format their emails in text/gemini (i.e. long lines)?

I don't think this is a good idea.  No email client is going to
recognise text/gemini (famous last words!) which means for most people
(okay, I don't have hard data, but I'm *assuming* most people aren't
reading the list on a mobile device) this will just result in a much
reduced user experience.

Once rawtext.club is back up you should at least be able to follow the
discussion (read-only) via text/gemini!

> P.S. I've been subscribed for a while, but I can't find the answer by searching the mailing list messages I've received: what happened to block quote syntax in text/gemini?
 
I think the person/people who was/were really pushing hard for this were
really invested in a relatively complicated form of it which was
infinitely nestable, so it could be used to represent e.g. deep comment
threads, and I wasn't super keen on that idea.

As a purely optional line-type with no special semantics, acting just as
a styling hint, the way unordered item lists are currently implemented,
I think I'm actually fairly unopposed to adding this.

Of course it would, like everything else, be strictly line-based, so
quoting multi-paragraph content might not format the way people
expect...

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sun May 17 10:45:04 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:45:04 +0000
Subject: [ANN] Gemini Mailing List gemini mirror
In-Reply-To: <20200517093012.25349b6f@socimda>
References: <1044942723.361254.1589682065502@ichabod.co-bxl>
 <20200517093012.25349b6f@socimda>
Message-ID: <20200517094504.GL23565@SDF.ORG>

On Sun, May 17, 2020 at 09:30:12AM +0300, Ecmel Berk Canl?er wrote:
 
> Or, just hook it up into an email account (say, your own) and listen
> for new mails there? That wouldn't be as responsive as the above, but
> ~5 minutes are better than 6 hours IMO.

This approach seems a bit more flexible to me - it would allow setting
up a Gemini mirror for any mailing list under the sun, without needing
the list admin to do any work.

A tool that does this in a totally general / configurable way could be a
nice project if anybody is looking for one that isn't just another
client or server.

Cheers,
Solderpunk

From aaron at ajanse.me  Sun May 17 10:48:29 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sun, 17 May 2020 02:48:29 -0700
Subject: Writing emails in text/gemini?
In-Reply-To: <20200517094225.GK23565@SDF.ORG>
References: <07a648e6-4b11-4ff9-9865-31b0824bb964@www.fastmail.com>
 <20200517094225.GK23565@SDF.ORG>
Message-ID: <6689f1a9-ad24-450e-82b2-22f6eb5d238b@www.fastmail.com>

> I think the person/people who was/were really pushing hard for this were
> really invested in a relatively complicated form of it which was
> infinitely nestable, so it could be used to represent e.g. deep comment
> threads, and I wasn't super keen on that idea.

Hehe, that person was me. Yep, I've been thinking about it more, and I
agree with you. I think it would be just fine to have comments without
nesting. Going out of our way to support deep comment threads would
help proxies while distracting from the high-value, original content
that attracts people (or at least me) to gopher & gemini in the frst
place.

> As a purely optional line-type with no special semantics, acting just as
> a styling hint, the way unordered item lists are currently implemented,
> I think I'm actually fairly unopposed to adding this.

Yay!

> Of course it would, like everything else, be strictly line-based, so
> quoting multi-paragraph content might not format the way people
> expect...

Hmm, we could just use multiple quotes, right? One per paragraph?

~ Aaron

From luke.emmet at gmail.com  Sun May 17 10:53:33 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sun, 17 May 2020 10:53:33 +0100
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <20200517084004.GA23565@SDF.ORG>
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
 <20200517084004.GA23565@SDF.ORG>
Message-ID: <5EC1099D.9060102@gmail.com>


On 17-May-2020 09:40, solderpunk wrote:
> On Sat, May 16, 2020 at 02:55:25AM +0430, Ben wrote:
>
>> Or maybe Gemini should support in-line links of its own? It's already got
>> some markdown elements in other aspects of page formatting.
> I'm really not keen on adding in-line links.  It would significantly
> increase the effort involved in parsing text/gemini documents - instead
> of peeking at the first 3 characters of a line and then being able to
> handle it, every line has to be split up into words and each word tested
> individually.

I think certain common idioms can be implemented by a client as a UI 
pretification, for example the frequently seen square bracket citations 
could be expanded [like this] or this [1]. The community could encourage 
this idiom as it is very gemini-friendly.

=> scheme://domain/path1 [like this]
=> scheme://domain/path2 [1]

I'm working on a UI playground to explore some of these ideas, among 
others, hope to have something to show soon.

  - Luke

From solderpunk at SDF.ORG  Sun May 17 10:55:57 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 09:55:57 +0000
Subject: Ambiguity in the gemini document spec
In-Reply-To: <f97dafb74a23738a70611035e70a413b@tilde.ninja>
References: <LPWGAQ.51TFL3D71CGC@kirgroup.net>
 <mrKqZN-1kETSQwHbs5da0moglHnseriGyMzR8NJ7pTtJ8gUOm1tvOb8L6YeGvck5EtmQ8_kZ3R6uAnABzM0LKKBxnfpltYQK8cnmYNzdIok=@protonmail.com>
 <20200517084926.GD23565@SDF.ORG>
 <f97dafb74a23738a70611035e70a413b@tilde.ninja>
Message-ID: <20200517095557.GN23565@SDF.ORG>

On Sun, May 17, 2020 at 08:57:13AM +0000, jan6 at tilde.ninja wrote:
> May 17, 2020 11:53 AM, "Fabio" <fabrixxm at kirgroup.net> wrote:
> > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>
> > 
> > =>gemini://example.org/bar Yet another example link at the same host
> > 
> > so, the first whitespace can be a zero number of consecutive spaces or tabs :)
> 
> it also says that
> 
> * Square brackets indicate that the enclosed content is
>   optional.

The bigger problem here (which somebody mentioned in a HN comment) which
definitely needs fixing is that "any non-zero number of spaces/tabs"
includes, say, 13 tabs per atom in the universe.

I actually got a patch for AV-98 recently to address this.  Somebody
wrote a proof-of-concept server which sends infinitely long response
headers and AV-98 stupidly slurped it all down until the Linux OOM
killer stepped in.

(which is as much sloppy programming on my part as it is a problem with
the spec - in principle, a well-written client could slurp down and
immediately discard insignificant whitespace)

But clearly the spec needs to place a maximum length on response
headers.

Cheers,
Solderpunk


From aaron at ajanse.me  Sun May 17 10:55:53 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sun, 17 May 2020 02:55:53 -0700
Subject: Gemini is not more complex than Gopher
Message-ID: <2f685ccc-1a40-46aa-a39b-2c8306293aee@www.fastmail.com>

The mailing list has the following title:
> A protocol that is slightly more complex than gopher, but
> significantly simpler than HTTP

I disagree with this description. I think Gemini is significantly
simpler than Gopher.

I think the following description, for example, would be more accurate:
> A protocol like Gopher, but simpler and easier to use

Just a thought.

~ Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/7374bb22/attachment.htm>

From me at ecmelberk.com  Sun May 17 10:55:52 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Sun, 17 May 2020 12:55:52 +0300
Subject: [ANN] Gemini Mailing List gemini mirror
In-Reply-To: <20200517094504.GL23565@SDF.ORG>
References: <1044942723.361254.1589682065502@ichabod.co-bxl>
 <20200517093012.25349b6f@socimda> <20200517094504.GL23565@SDF.ORG>
Message-ID: <20200517125552.2645340e@socimda>

On Sun, 17 May 2020 09:45:04 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> This approach seems a bit more flexible to me - it would allow setting
> up a Gemini mirror for any mailing list under the sun, without needing
> the list admin to do any work.

When I said mail server, I didn't mean the server of the list itself,
but creating a mail daemon configured to write any messages it
received, and subscribing to the list like any other account.

But there are still advantages of the latter approach, like not having
to host a mail daemon, as you can just create a mail account with any
of the tons of email providers, and poll for mails like a regular mail
client.

From aaron at ajanse.me  Sun May 17 11:01:18 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sun, 17 May 2020 03:01:18 -0700
Subject: Writing emails in text/gemini?
In-Reply-To: <20200517094225.GK23565@SDF.ORG>
References: <07a648e6-4b11-4ff9-9865-31b0824bb964@www.fastmail.com>
 <20200517094225.GK23565@SDF.ORG>
Message-ID: <a23727a8-79ed-4171-a1eb-c080c3a6e2fc@www.fastmail.com>

> I don't think this is a good idea.  No email client is going to
> recognise text/gemini (famous last words!) which means for most people
> (okay, I don't have hard data, but I'm *assuming* most people aren't
> reading the list on a mobile device) this will just result in a much
> reduced user experience.

Oh, I meant to suggest we, as a community, write text/gemini while marking
it as text/plain. But yeah, apparently some email clients still don't
know how to wrap text at a reasonable width? But last time I checked, this
is a flamewar topic.

~ Aaron

From solderpunk at SDF.ORG  Sun May 17 11:10:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 10:10:29 +0000
Subject: A quick note on adding things to the server/software lists
Message-ID: <20200517101029.GO23565@SDF.ORG>

Ahoy, Gemininauts!

It's great seeing the steady stream of new Gemini software and new
Gemini servers being announced.  I encourage people to keep sending
these to the list, to keep the community informed and to have a visible
indication of growth/activity.

I would encourage people to use the [ANN] subject-prefix for these
"announcement" type posts, so that people who want to can filter them
out from "actual discussion", just to make the list a bit easier to
follow.

I'm personally going to stop replying to those posts saying "Thanks,
I've added this to the list", just because it's taking a non-trivial
amount of time for me to do it and because I imagine it's just filling
everybody's inbox up with low-value emails.  So, please take it for
granted that I'll be following these announcements and adding them to
the relevant lists.  If you see that I've failed to do so after, say,
3 days from your initial post, feel free to email me a reminder
off-list.

Finally, regarding the list of known-servers: there is now a similar
list at GUS (gemini://gus.guru/known-hosts) which is automatically
generated based on the crawler's explorations, and which you can
manually submit your server's URL to.  This list is basically guaranteed
to be a more reliable source of this information in the long term than
the list at gemini.circumlunar.space, which is updated manually by me.

Because there's a more reliable automated alternative and because
updating the list is taking me time that could otherwise be spent
hacking on Gemini or writing Gemini content, I've decided that once that
list hits 50 servers I will stop updating it.  So effectively it will
become a list of the first 50 Gemini servers, which will be a nice
little historical document to have around.  We're already getting to the
point where's it not a quick and easy thing to manually check out every
server in existence, and it makes a lot more sense to use search to find
stuff you're actually interested in.

So, in addition to making announcement posts here, please be sure to
also submit your server to GUS via the easy-to-find links at gus.guru.

I will still maintain the software list manually without limit for now,
because software is much harder to automatically detect than servers
are.

Cheers,
Solderpunk

From fabrixxm at kirgroup.net  Sun May 17 11:48:24 2020
From: fabrixxm at kirgroup.net (Fabio)
Date: Sun, 17 May 2020 12:48:24 +0200
Subject: Ambiguity in the gemini document spec
In-Reply-To: <20200517095557.GN23565@SDF.ORG>
References: <LPWGAQ.51TFL3D71CGC@kirgroup.net>
 <mrKqZN-1kETSQwHbs5da0moglHnseriGyMzR8NJ7pTtJ8gUOm1tvOb8L6YeGvck5EtmQ8_kZ3R6uAnABzM0LKKBxnfpltYQK8cnmYNzdIok=@protonmail.com>
 <20200517084926.GD23565@SDF.ORG>
 <f97dafb74a23738a70611035e70a413b@tilde.ninja>
 <20200517095557.GN23565@SDF.ORG>
Message-ID: <O02HAQ.ZPGTG32PXDTS@kirgroup.net>



Il giorno dom 17 mag 2020 alle 09:55, solderpunk <solderpunk at SDF.ORG> 
ha scritto:
> On Sun, May 17, 2020 at 08:57:13AM +0000, jan6 at tilde.ninja wrote:
>>  May 17, 2020 11:53 AM, "Fabio" <fabrixxm at kirgroup.net> wrote:
>>  > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK 
>> NAME>]<CR><LF>
>>  >
>>  > =>gemini://example.org/bar Yet another example link at the same 
>> host
>>  >
>>  > so, the first whitespace can be a zero number of consecutive 
>> spaces or tabs :)
>> 
>>  it also says that
>> 
>>  * Square brackets indicate that the enclosed content is
>>    optional.

Well, you're right.. my brain just skip the square brackets.
Sorry for the noise.



From felix at masterq32.de  Sun May 17 12:00:18 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 17 May 2020 13:00:18 +0200
Subject: Announcing `gurl`: like `curl` but for gemini + release of `gurl`
 like `curl` but by another person
In-Reply-To: <20200517093122.GI23565@SDF.ORG>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
 <20200517093122.GI23565@SDF.ORG>
Message-ID: <f57722ed-6865-ede6-4de8-f81a6cdd0075@masterq32.de>

Hey!


> Well, this is awkward...how do you want these projects listed at the
> software page?
I have no problem with changing the name of my project, but i actually
try to mimic real curl command line options, so something similar to
"curl" would be appropriate.

I'd love to hear some suggestions for names!

Regards
xq

From julien at typed-hole.org  Sun May 17 12:05:07 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sun, 17 May 2020 13:05:07 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <f6eeaa5b-30bb-b213-10a3-b73c048e4dc4@lavabit.com>
References: <6204139.202339.1589475979277@ichabod.co-bxl>
 <20200514183327.GN10556@SDF.ORG>
 <f6eeaa5b-30bb-b213-10a3-b73c048e4dc4@lavabit.com>
Message-ID: <4e227259-def6-3543-c9be-eb06dba6dcf7@typed-hole.org>

On 5/14/20 8:47 PM, James Tomasino wrote:

> I hesitate to even offer a solution because it gets too close to our
> heated code fencing & list markup discussion, but... As code fences
> currently begin with ```
> and end with
> ```
>
> We could use the starting code fence to indicate whether the content is
> art or not, or parseable as text or not.
>
> ```text
>
> ```art
>
> or some ARIA-esque token.
>
> I was originally thinking that the text following ``` could be a literal
> alt text. I dunno. Just throwing out ideas.

I like this proposal, I played with this idea on gemini://typed-hole.org front-page. I was a quick change on my clients code so that could work.
I tried having the first opening fence with some kind of type (art in this case) and the closing one with some alt-text.


From jan6 at tilde.ninja  Sun May 17 12:42:50 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 11:42:50 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <4e227259-def6-3543-c9be-eb06dba6dcf7@typed-hole.org>
References: <4e227259-def6-3543-c9be-eb06dba6dcf7@typed-hole.org>
 <6204139.202339.1589475979277@ichabod.co-bxl>
 <20200514183327.GN10556@SDF.ORG>
 <f6eeaa5b-30bb-b213-10a3-b73c048e4dc4@lavabit.com>
Message-ID: <7b48b1637c50e043a461ec4504ec22f6@tilde.ninja>

> On 5/14/20 8:47 PM, James Tomasino wrote:
> 
> We could use the starting code fence to indicate whether the content is
> art or not, or parseable as text or not.
> 
> ```text
> 
> ```art

I'm not a fan of the ending part having text too,
slightly harder parser, and noticeably harder to read for humans, 
especially if there are several blocks back-to-back
other than that, not too bad idea, I suppose

of course, ``` might not be the best characters, but it'd work
(` is accessable on US keyboard, but often a combining character or behind some key-chord on other layouts)

maybe...something like this?

``` whitespace [optional alt text describing contents]
monospace art or code block
```

where you could do stuff like
``` hello_world.py
print("hello world")
```
and
```  a cheering stick-man
\o/
 |
/ \
```
or simply
``` 
can re-use as block quote as well
because why not?
~jan6, 2020
```

would probably be good to have different start and end tags to make it simple to parse
otherwise you'd need to count if current ``` line is odd or even numbered (did it just start, or did it finish?), or such extra checks

that's why it could be good to require at least one whitespace after starting ``` and none after closing one,
alt text optional, but descriptive if used (you could have a convention of having art captions start with "art, depicting" or such, but not one word "art, figure it out yourself")


but hey, these are just my initial thoughts, feedback?

From aaron at ajanse.me  Sun May 17 12:46:26 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sun, 17 May 2020 04:46:26 -0700
Subject: =?UTF-8?Q?Re:_Announcing_`gurl`:_like_`curl`_but_for_gemini_+_release_of?=
 =?UTF-8?Q?_`gurl`_like_`curl`_but_by_another_person?=
In-Reply-To: <f57722ed-6865-ede6-4de8-f81a6cdd0075@masterq32.de>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
 <20200517093122.GI23565@SDF.ORG>
 <f57722ed-6865-ede6-4de8-f81a6cdd0075@masterq32.de>
Message-ID: <0cabb393-5d83-46ad-87bc-a438b662062e@www.fastmail.com>

That's super cool. I'll rename my project tomorrow.

On Sun, May 17, 2020, at 4:00 AM, Felix Quei?ner wrote:
> Hey!
> 
> 
> > Well, this is awkward...how do you want these projects listed at the
> > software page?
> I have no problem with changing the name of my project, but i actually
> try to mimic real curl command line options, so something similar to
> "curl" would be appropriate.
> 
> I'd love to hear some suggestions for names!
> 
> Regards
> xq
>

From phoe at disroot.org  Sun May 17 12:54:51 2020
From: phoe at disroot.org (=?UTF-8?Q?Micha=c5=82_=22phoe=22_Herda?=)
Date: Sun, 17 May 2020 13:54:51 +0200
Subject: Video examples
Message-ID: <r9r8mb$k1j$7@lc.orbitalfox.eu>

Are there any video examples of the Gemini protocol in action? Something
that shows a person interacting with a Gemini browser and some content
served via the protocol.

~phoe

From phoe at disroot.org  Sun May 17 12:54:51 2020
From: phoe at disroot.org (=?UTF-8?Q?Micha=c5=82_=22phoe=22_Herda?=)
Date: Sun, 17 May 2020 13:54:51 +0200
Subject: Video examples
Message-ID: <r9r8mb$k1j$7@lc.orbitalfox.eu>

Are there any video examples of the Gemini protocol in action? Something
that shows a person interacting with a Gemini browser and some content
served via the protocol.

~phoe

From felix at masterq32.de  Sun May 17 13:55:03 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 17 May 2020 14:55:03 +0200
Subject: Questions regarding "POST" request and line endings
Message-ID: <640b80c3-ffce-ed5d-2eb7-1d4503572e1c@masterq32.de>

Hey!

I wanted to ask (and maybe discuss, if not done already) why Gemini has
no option to upload a file to a server except for a roughly 1024 byte
long URL string.

Imho this would be a practical use case e.g. for web forums or other
services. As some gemini servers already work with cgi scripts and
similar, i think it's a reasonable thing to allow updates via the spec.

And people will eventually use the query string to upload files with
multiple requests if they want to upload files...

Another question:
Why does gemini use <CR><LF> line endings instead of a single <LF> or
<CR> token? It makes the parser implementation more complex and imho
brings no benefit to the protocol and text format itself. I see no
reason why i should have a single <CR> or <LF> in a line and it may
confuse users: "12345, World!<CR>Hello" may be printed as "Hello,
World!" on most text terminals which is imho undesirable for
non-interactive output.

If a text-based client requires output to be <CR><LF> instead of <LF>,
it can patch the data on the fly while outputting it.

Regards
xq

From jan6 at tilde.ninja  Sun May 17 14:10:28 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 13:10:28 +0000
Subject: Questions regarding "POST" request and line endings
In-Reply-To: <640b80c3-ffce-ed5d-2eb7-1d4503572e1c@masterq32.de>
References: <640b80c3-ffce-ed5d-2eb7-1d4503572e1c@masterq32.de>
Message-ID: <471a87749342ac14ce492caf0f9629f3@tilde.ninja>

May 17, 2020 3:55 PM, "Felix Quei?ner" <felix at masterq32.de> wrote:
> Why does gemini use <CR><LF> line endings instead of a single <LF> or
> <CR> token? It makes the parser implementation more complex and imho
> brings no benefit to the protocol and text format itself.

<CR><LF> is the windows line ending, also HTTP spec for example, requires that
no idea why it's required, exactly

functionally you could just split on <LF> and remove all <CR> occurrences, I think.
CR, the carriage return, would return the cursor to the start of the line, which is almost certainly not wanted in the middle of the text (also ancient macOS, before OS X, used ONLY <CR>, iirc, as a fun sidenote)

using <CR><LF> would allow you to directly netcat from windows, or so, I suppose...

I'd think it would be best if the server side would accept either <CR><LF>, AND only a normal <LF>

and I'm not sure it really matter what the server returns, because you can strip out all <CR> characters,
and on linux (probably all unixes?) it displays like a normal newline anyway

From tomasino at lavabit.com  Sun May 17 14:16:05 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 17 May 2020 13:16:05 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <7b48b1637c50e043a461ec4504ec22f6@tilde.ninja>
References: <4e227259-def6-3543-c9be-eb06dba6dcf7@typed-hole.org>
 <6204139.202339.1589475979277@ichabod.co-bxl>
 <20200514183327.GN10556@SDF.ORG>
 <f6eeaa5b-30bb-b213-10a3-b73c048e4dc4@lavabit.com>
 <7b48b1637c50e043a461ec4504ec22f6@tilde.ninja>
Message-ID: <083b16d3-c9b4-a62c-508c-eb0b6f1bf538@lavabit.com>

On 5/17/20 11:42 AM, jan6 at tilde.ninja wrote:
> I'm not a fan of the ending part having text too,
> slightly harder parser, and noticeably harder to read for humans, 
> especially if there are several blocks back-to-back
> other than that, not too bad idea, I suppose

TLDR;

``` this is alt text / syntax descriptor
this should not be search by engines or read by screen readers by default
```

```
this has no alt text and should be searched by engines and read by
screen readers
```

--- The long version ---

I've been thinking of ways to keep it extremely simple. If the goals are:

- provide alt text for a block that may not be easily parsed by bots &
screen readers

- indicate which blocks should and should not be parsed

Then I think we can accomplish the goal with a single code fence suffix
that is either blank, indicating that the content CAN be parsed, or has
text, indicating that IS the alt text.

``` anything here is alt text
moo moo moo moo moo
```

```
This will be parsed because there's no fence suffix at the start.
```

That would be incredibly easy to parse and require zero effort from
clients that already exist since they can continue to just look at the
first three characters and ignore the rest. Search engines can read the
alt/descriptor and skip the rest of the block if it exits, or read the
contents if its blank. Easy all around.


The complication would come if you want that space to have another
purpose, such as defining the language for syntax highlighting on a code
block like we see in markdown.

```bash
#!/usr/bin/env bash
printf "moo moo moo moo moo\\n"
```

This would be interpreted for alt-text purposes as just "bash". First of
all, it would mean that search engines wouldn't parse code blocks which
may or may not be a bad thing.

It may actually work out great for accessible clients though. I don't
know of anyone making an accessible client YET, but if it were
structured this way the block, when hit, could indicate verbally that a
preformatted block had been reached and the alt/descriptor could be
read. A good accessible client might even inform the user how many lines
the block contains and offer some way to "page" through it bit by bit.

This sort of behavior would be nice to talk through with anyone working
on such a client, but beyond giving it some initial consideration I
don't see it as belonging in the gemini spec itself.


From tomasino at lavabit.com  Sun May 17 14:19:14 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 17 May 2020 13:19:14 +0000
Subject: Video examples
In-Reply-To: <r9r8mb$k1j$7@lc.orbitalfox.eu>
References: <r9r8mb$k1j$7@lc.orbitalfox.eu>
Message-ID: <fab0f8b4-9ec0-7664-e3cf-f2d49aa7537c@lavabit.com>

On 5/17/20 11:54 AM, Micha? "phoe" Herda wrote:
> Are there any video examples of the Gemini protocol in action? Something
> that shows a person interacting with a Gemini browser and some content
> served via the protocol.

I've done a peertube/youtube video on gopher [0] relatively recently and
I'm planning on one for gemini as well in the near future. There's so
much in flux right now I've just been waiting on things to settle a tiny
bit more so the content isn't immediately outdated.

[0] https://www.youtube.com/watch?v=QGCSYyH2r6k


From solderpunk at SDF.ORG  Sun May 17 14:27:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 13:27:12 +0000
Subject: Questions regarding "POST" request and line endings
In-Reply-To: <640b80c3-ffce-ed5d-2eb7-1d4503572e1c@masterq32.de>
References: <640b80c3-ffce-ed5d-2eb7-1d4503572e1c@masterq32.de>
Message-ID: <20200517132712.GR23565@SDF.ORG>

On Sun, May 17, 2020 at 02:55:03PM +0200, Felix Quei?ner wrote:
 
> I wanted to ask (and maybe discuss, if not done already) why Gemini has
> no option to upload a file to a server except for a roughly 1024 byte
> long URL string.

I have to admit, this idea has occasionally crossed my mind.  Most
recently, when Dave wrote a helper for Git so that people could `git
pull` over Gemini, which I thought was super cool - `git push` isn't
possible with Gemini as a read-only protocol.

It's not that I don't think there are good uses for this.

The original reason is that I was obsessed from day one with making it
extremely hard for people to be able to extend the core Gemini protocol.
HTTP, for example, allows as many headers as you like in
requests/responses.  Clients are expected to read them all, and handle
the ones they can handle.  This means anybody can come up with a new
header, and if it's popular many clients/servers will implement it, and
then it becomes a de facto part of the standard, and clients/servers
which don't handle it are seen as "broken" or "primitive".

This extensibility is of course a useful thing in many ways from an
engineering perspective.  But in the long term it is, IMHO, fundamentaly
totally incompatible with ideals like simplicity and minimalism and
privacy and "anybody can implement it themselves over a weekend in <
1000 LOC".  Designers of protocols which are extensible effectively lose
a lot of control over their protocol.  It's pointless me trying very
hard to keep stuff which could be abused for tracking out of Gemini if
it can be snuck in by popular consensus this way, because inevitably it
will be.  You've just got to limit the scope for this kind of extension
everywhere you can.

If you take this idea seriously, you are basically forced to choose
one kind of "thing" a lot, and then have that thing be totally implicit.
If there's only one kind of Gemini request (something analogous to GET),
then we don't have to explicitly put anything in the request format
saying "this is a GET-ish request".  And if there's nothing explicit
there, nobody can write an "advanced" server which recognises a
different value in that place.

So, thinking from a perspective of simplifying HTTP, I had to choose
only one method, so I chose GET.  I had to choose only one response
header, so I chose Content-type (because my experience maintaining a
popular Gopher client convinced me this was the most sorely lacking bit
of information).  Several people convinced me to use full blown URLs
instead of just paths as I originally specced for requests, which is
equivalent to choosing Host as the only request header.  Basically this
theme runs deep all throughout Gemini's design: wherever HTTP allows
several things, pick the one most fundamentally important/useful one,
and make it an implicit default with no scope for anything else.

If somebody can come up with a way to distinguish GET from POST style
requests without also opening up an obvious door to arbitrarily many
extra request types, I'll give it some thought.  But I'm not optimistic.

Insisting on non-extensibility necessarily imposes limits on how much
Gemini can do.  That's okay.  Limitations encourage creativity, and give
different things their own unique style/taste/whatever.  Gemini is never
going to be able to do everything that the web can do - it can't
possibly do that while remaining simpler.  We should accept this.
 
> Another question:
> Why does gemini use <CR><LF> line endings instead of a single <LF> or
> <CR> token? It makes the parser implementation more complex and imho
> brings no benefit to the protocol and text format itself. I see no
> reason why i should have a single <CR> or <LF> in a line and it may
> confuse users: "12345, World!<CR>Hello" may be printed as "Hello,
> World!" on most text terminals which is imho undesirable for
> non-interactive output.

As recently mentioned, the spec doesn't actually explicitly say anything
about line endings in text/gemini content itself (although it should).
It does suggest that CRLF is needed at the end of => lines, but that was
unintentional on my part.  I agree that requiring CRLF for actual
content is strange and I suspect this will change in the next revision.

CRLF *is* clearly and deliberately specced in the non-content part of
the protocol, i.e. for requests and response headers.  And the honest
answer here is, well, that's how every internet protocol whose spec I've
ever looked at works - HTTP, Gopher, SMTP, IRC, for example, all do
this.  I admit to being ignorant as to the exact historical reason for 
his convention.  But it's a deep and wide convention adhered to by
people who know more than I do, and for that reason I'm reluctant to
break it without very good reason.

If people have strong feelings in either direction about the line
terminator to be used in the protocol and in text/gemini content, I'm
very happy to hear it.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 17 14:30:31 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 17 May 2020 13:30:31 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <083b16d3-c9b4-a62c-508c-eb0b6f1bf538@lavabit.com>
References: <4e227259-def6-3543-c9be-eb06dba6dcf7@typed-hole.org>
 <6204139.202339.1589475979277@ichabod.co-bxl>
 <20200514183327.GN10556@SDF.ORG>
 <f6eeaa5b-30bb-b213-10a3-b73c048e4dc4@lavabit.com>
 <7b48b1637c50e043a461ec4504ec22f6@tilde.ninja>
 <083b16d3-c9b4-a62c-508c-eb0b6f1bf538@lavabit.com>
Message-ID: <20200517133031.GS23565@SDF.ORG>

On Sun, May 17, 2020 at 01:16:05PM +0000, James Tomasino wrote:
> 
> It may actually work out great for accessible clients though. I don't
> know of anyone making an accessible client YET

Rhapsode is an "auditory web browser" that recently added Gemini
support:

http://rhapsode.adrian.geek.nz/

So, they do exist.  I hope it is only the first of more to come.  This
is an area where we can very easily beat the pants off most of the web.

Cheers,
Solderpunk

From krixano at protonmail.com  Sun May 17 14:44:38 2020
From: krixano at protonmail.com (Krixano)
Date: Sun, 17 May 2020 13:44:38 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200517133031.GS23565@SDF.ORG>
References: <4e227259-def6-3543-c9be-eb06dba6dcf7@typed-hole.org>
 <6204139.202339.1589475979277@ichabod.co-bxl>
 <20200514183327.GN10556@SDF.ORG>
 <f6eeaa5b-30bb-b213-10a3-b73c048e4dc4@lavabit.com>
 <7b48b1637c50e043a461ec4504ec22f6@tilde.ninja>
 <083b16d3-c9b4-a62c-508c-eb0b6f1bf538@lavabit.com>
 <20200517133031.GS23565@SDF.ORG>
Message-ID: <uqi9wqVIphrGLVGjRjp9Qd0qI9LYjPWWGFoxXTvFKB7JcmnHJC2bkYy2Ui00j6uDNWwNZYmMPeTPzW62OVGmkewnojOuE5rWNUNiF2Ox9pE=@protonmail.com>

> would probably be good to have different start and end tags to make it simple to parse
otherwise you'd need to count if current ``` line is odd or even numbered (did it just start, or did it finish?), or such extra checks

Guys... I don't want to be mean, but parsing is not that hard, lol.
<cr><lf> is not hard to parse either. For ```, all you need is a boolean (or even just a context enum)
that's set to its opposite value everytime you see ``` at the start of a line. If the value was set to
true, then you're now in a block and everything after ``` will be the alt text.


Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Sunday, May 17, 2020 8:30 AM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Sun, May 17, 2020 at 01:16:05PM +0000, James Tomasino wrote:
>
> > It may actually work out great for accessible clients though. I don't
> > know of anyone making an accessible client YET
>
> Rhapsode is an "auditory web browser" that recently added Gemini
> support:
>
> http://rhapsode.adrian.geek.nz/
>
> So, they do exist. I hope it is only the first of more to come. This
> is an area where we can very easily beat the pants off most of the web.
>
> Cheers,
> Solderpunk



From felix at masterq32.de  Sun May 17 15:10:36 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 17 May 2020 16:10:36 +0200
Subject: Questions regarding "POST" request and line endings
In-Reply-To: <20200517132712.GR23565@SDF.ORG>
References: <640b80c3-ffce-ed5d-2eb7-1d4503572e1c@masterq32.de>
 <20200517132712.GR23565@SDF.ORG>
Message-ID: <dabc8d5e-8046-cf9a-6d47-34c22d9e34fa@masterq32.de>

First of all: thanks for the very extensive response!

> It's not that I don't think there are good uses for this.
> 
> The original reason is that I was obsessed from day one with making it
> extremely hard for people to be able to extend the core Gemini protocol.
> HTTP, for example, allows as many headers as you like in
> requests/responses.  Clients are expected to read them all, and handle
> the ones they can handle.  This means anybody can come up with a new
> header, and if it's popular many clients/servers will implement it, and
> then it becomes a de facto part of the standard, and clients/servers
> which don't handle it are seen as "broken" or "primitive".
Yes i can understand this and it was not my intention to create
extensibility in the protocol but just allow a single, client-induced
data upload to the server.

> This extensibility is of course a useful thing in many ways from an
> engineering perspective.  But in the long term it is, IMHO, fundamentaly
> totally incompatible with ideals like simplicity and minimalism and
> privacy and "anybody can implement it themselves over a weekend in <
> 1000 LOC".  Designers of protocols which are extensible effectively lose
> a lot of control over their protocol.
Yes, true

> It's pointless me trying very
> hard to keep stuff which could be abused for tracking out of Gemini if
> it can be snuck in by popular consensus this way, because inevitably it
> will be.  You've just got to limit the scope for this kind of extension
> everywhere you can.
One proposal for more privacy and less tracking:
Explicitly allow clients to remove the query string from any request, as
most of the web stuff does also tracking via request parameters (before
cookies).

This would prevent servers relying on per-user generated URLs in between
pages and the user can be queried if they want to remove the query
parameters.

> If you take this idea seriously, you are basically forced to choose
> one kind of "thing" a lot, and then have that thing be totally implicit.
> If there's only one kind of Gemini request (something analogous to GET),
> then we don't have to explicitly put anything in the request format
> saying "this is a GET-ish request".  And if there's nothing explicit
> there, nobody can write an "advanced" server which recognises a
> different value in that place.

Yeah that's why i asked for a specific PUT in the first place. It may
start to emerge that people want a more interactive version of
gemini-served pages and would start to abuse standard features like url
queries to introduce that kind of interactivity and it would be a point
where the server would be able to pretty easily "trick" the user into
following trackable links.

Having an explicit PUT option in the protocol and preventing servers to
rely on queries would make stuff simpler and more straightforward in the
long term

> If somebody can come up with a way to distinguish GET from POST style
> requests without also opening up an obvious door to arbitrarily many
> extra request types, I'll give it some thought.  But I'm not optimistic.

I actually came up with an idea, but i don't know how good it is in the end:

Respec the 10 INPUT so that it works like this:

1. Client sends usual request header
2. Server responds with "10 Your forum post:"
3. Client now has two options:
    1. The client drops the connection and sends no bytes. This would be
the status quo.
    2. The client now sends a single line with the mime type of the
data, then sends the data similar to the server responding with a 20
status code (so, instead of the server sending data to the client, the
client just sends data to the server)

This would allow several things:
1. Server can notify that the client needs to upload data, the client
can now chose to upload or not
2. With the mime type in the upload header, the server can just drop the
connection after the mime, displaying the client that the data sent is
unwanted.


> Insisting on non-extensibility necessarily imposes limits on how much
> Gemini can do.  That's okay.  Limitations encourage creativity, and give
> different things their own unique style/taste/whatever.  Gemini is never
> going to be able to do everything that the web can do - it can't
> possibly do that while remaining simpler.  We should accept this.

Yeah true. But the first idea that comes to my mind when i'd like to
upload a file would be:

Chunk the file into 256 byte large pieces, and upload the whole data via
a huge load of requests containing a query

  /path/?offset=X&length=Y&blob=Z

where X is the offset in the uploaded file, Y is the length of the
transferred data and Z would be the URL-encoded data itself.


> As recently mentioned, the spec doesn't actually explicitly say anything
> about line endings in text/gemini content itself (although it should).
> It does suggest that CRLF is needed at the end of => lines, but that was
> unintentional on my part.  I agree that requiring CRLF for actual
> content is strange and I suspect this will change in the next revision.
> 
> CRLF *is* clearly and deliberately specced in the non-content part of
> the protocol, i.e. for requests and response headers.  And the honest
> answer here is, well, that's how every internet protocol whose spec I've
> ever looked at works - HTTP, Gopher, SMTP, IRC, for example, all do
> this.  I admit to being ignorant as to the exact historical reason for 
> his convention.  But it's a deep and wide convention adhered to by
> people who know more than I do, and for that reason I'm reluctant to
> break it without very good reason.
Thanks for clarifying!

> If people have strong feelings in either direction about the line
> terminator to be used in the protocol and in text/gemini content, I'm
> very happy to hear it.
I'd like to see a pure <LF> version, especially for the protocol header.
My client atm just reads until the first <LF>, then checks if the <CR>
is there and if not, drops the connection to the server and respons with
"InvalidResponse"

I assume a lot of servers/clients either ignore the existence of <CR> or
drop the connection for protocol violation because both options are the
sane thing to do. It's not like a lone <CR> or <LF> are allowed anyways
in the header.

Regards
xq

From b__m__e at mailfence.com  Sun May 17 16:19:42 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 17 May 2020 17:19:42 +0200 (CEST)
Subject: Cognitive aspects of navigation in gemini space
Message-ID: <1558722495.384905.1589728782465@ichabod.co-bxl>

_jan6 writes:_
> I'm not a fan of the ending part having text too,
> slightly harder parser, and noticeably harder to read for humans, 
> especially if there are several blocks back-to-back

I'm not sure about this. It seems to me that someone parsing by line can just set a flag for `in_pre_block`.
When they get to a line beginning with ``` they know the pre block has ended. Sounds dead simple to me.

As to harder for humans, the whole point is to make it easier for humans. The ``` and text should not appear
to most users. It is not for them, it is for the client. Having the opening ``` with a type of some form allows a
client to offer options such as "show ascii art" and "show pre text" as boolean options. If someone chose to
set "show ascii art" to to false for the below:

``` art
:-)
``` A simple smiley

The client could display:

[art: A simple smiley]

To that user instead of the full block. I think there is real value and utility in that. Not only that but it adds to
the ability of any future screen reader implementations to be able to parse the document in a way that will
make sense to the user using the screen reader.

I would go so far as to recommend this be a requirement for preformatted blocks in accessibility merits alone.
I think there should be three types: Art, Text, Code and that descriptions on the end blocks should be compulsory.

That said, I'm definitely not wanting to bikeshed this thing and we have already had a lot of text/gemini discussions
in the past.

--?
Sent with https://mailfence.com
Secure and private email

From jan6 at tilde.ninja  Sun May 17 16:35:32 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 15:35:32 +0000
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <1558722495.384905.1589728782465@ichabod.co-bxl>
References: <1558722495.384905.1589728782465@ichabod.co-bxl>
Message-ID: <748360781a991f7205dfe73ac16abe1e@tilde.ninja>

May 17, 2020 6:19 PM, "Brian Evans" <b__m__e at mailfence.com> wrote:
> As to harder for humans, the whole point is to make it easier for humans. The ``` and text should
> not appear
> to most users. It is not for them, it is for the client.

no...
point of gemini is to have a format so simple you don't *need* specialized clients,
that you can view it with basically TLS-enabled netcat equivalent... a super-simple client...
for example, => lines are quite readable, you can easily see where they go and what they're named with your eyes, without *needing* to do fancy "hide url, only show human-readable part", which is just a nicety fancy clients CAN do...

"oh the client will take care of it" is a bad way of thinking
at that rate you'll end up with something like html,
"hey, the user doesn't need to see the source! let's make it all fancy!", because y'know, html is readable...

and sure, you could keep a boolean or such for that, but why not make it easier?
it doesn't matter too much parsing-side, I suppose, sure...

From plugd at thelambdalab.xyz  Sun May 17 17:10:38 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Sun, 17 May 2020 18:10:38 +0200
Subject: Questions regarding "POST" request and line endings
In-Reply-To: <20200517132712.GR23565@SDF.ORG>
References: <640b80c3-ffce-ed5d-2eb7-1d4503572e1c@masterq32.de>
 <20200517132712.GR23565@SDF.ORG>
Message-ID: <lzimgu4k5d.fsf@bs-mbpr348.d.ethz.ch>

solderpunk writes:
> On Sun, May 17, 2020 at 02:55:03PM +0200, Felix Quei?ner wrote:
> I have to admit, this idea has occasionally crossed my mind.  Most
> recently, when Dave wrote a helper for Git so that people could `git
> pull` over Gemini, which I thought was super cool - `git push` isn't
> possible with Gemini as a read-only protocol.
>
> It's not that I don't think there are good uses for this.

For what it's worth, I personally don't even think allowing git pushes
over gemini is a good reason for modifying the protocol.  Git has it's
own application-level protocol that works perfectly for this kind of
thing.  Gemini is very close to _perfect_ for it's intended use: serving
up primarily textual content to humans in a relatively secure but
pleasantly simple way.  I really think it'd be tragic to compromise on
this for reasons that are tangential to the original goal.

Just my 2c,

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/ebf55f04/attachment-0001.sig>

From escondida at iff.ink  Sun May 17 18:17:03 2020
From: escondida at iff.ink (Ivy Foster)
Date: Sun, 17 May 2020 12:17:03 -0500
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <1558722495.384905.1589728782465@ichabod.co-bxl>
References: <1558722495.384905.1589728782465@ichabod.co-bxl>
Message-ID: <20200517171703.GA2317@thrax.localdomain>

On 17 May 2020, at  5:19 pm +0200, Brian Evans wrote:
> _jan6 writes:_
> > I'm not a fan of the ending part having text too, slightly harder
> > parser, and noticeably harder to read for humans, especially if
> > there are several blocks back-to-back

> I'm not sure about this. It seems to me that someone parsing by line can
> just set a flag for `in_pre_block`.  When they get to a line beginning
> with ``` they know the pre block has ended. Sounds dead simple to me.

> As to harder for humans, the whole point is to make it easier for
> humans. The ``` and text should not appear to most users. It is not
> for them, it is for the client. Having the opening ``` with a type of
> some form allows a client to offer options such as "show ascii art"
> and "show pre text" as boolean options. If someone chose to set "show
> ascii art" to to false for the below:

> ``` art
> :-)
> ``` A simple smiley
> The client could display:

> [art: A simple smiley]

> I would go so far as to recommend this be a requirement for preformatted
> blocks in accessibility merits alone.  I think there should be three
> types: Art, Text, Code and that descriptions on the end blocks should
> be compulsory.

I like the idea of severely limiting the available block-type options.

How about this for block syntax, with the understanding that the alt
text is highly recommended for accessibility. Specifying the block
type and the programming language or written language (as appropriate)
would be strictly optional: those that wanted to make use of them
could, those who did not want to make use of them would not have to.

For the purposes of this proposal, there would be *no space* between
the backticks and the optional content-type field, which field may not
contain spaces. There must be at least one space on the line before
the (recommended) alt text. That way, the client doesn't need to try
and figure out where one ends and one begins: the instant the client
sees a space, we're into alt-text territory for the rest of the line.

```[art | code[:programming language] | text[:written language]] [alt text]
...
```

So, e.g.,

```code:c The Laziest Hello World
#include "real_hello_world.h"
```

```text:fr_FR Antoine de Saint-Exup?ry on perfection
	Il semble que la perfection soit atteinte non quand il n'y a
	plus rien ? ajouter, mais quand il n'y a plus rien ?
	retrancher.
		-- Terre des Hommes, 1939
```

``` This is a block with just alt text.
You know, I think the alt text is better than the content this time.
```

What the client does with the alt text and the block type, if
anything, is up to the author.

I think this way, it would be both nicely readable to a human reading
the source text/gemini, without sacrificing ease of parsing. Just
throwing an idea at the wall to see whether it sticks.

Cheers,
Ivy Foster
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/d7fa247d/attachment.sig>

From b__m__e at mailfence.com  Sun May 17 18:24:53 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 17 May 2020 19:24:53 +0200 (CEST)
Subject: Cognitive aspects of navigation in gemini space
Message-ID: <23525681.390952.1589736293241@ichabod.co-bxl>

jan6 writes:
> [...] point of gemini is to have a format so simple you don't *need* specialized clients

Funny, I never saw that written anywhere. Simple: yes. Designed specifically to be run without a client that does nothing more that cat
the raw format: nope. While that is certainly a valid use case I definitely balk at the idea that that should be a primary target.

> "hey, the user doesn't need to see the source! let's make it all fancy!"

I cannot speak for any other clients, but with mine you can always just download the file as raw source if you want the source.
The fact is that there will be variance in use case and client approaches. The use case you mention is perfectly valid, as are
programs (I hesitate to call them clients if all they do is make a request and print the response as raw text) that do what you
described. 

I hardly think providing an alt string/type string to what could be a big blob of non-sense characters to a non-sighted
person should be considered too complicated. Nor do I think it is hard to visually grep the following:

``` ascii art of a dog

Seems unambiguous to me. 

> [...] without *needing* to do fancy "hide url, only show human-readable part", which is just a nicety fancy clients CAN do...

The spec actually _requires_ that the ``` line itself not be shown to users, thus making a netcat like response not in line with what the spec
would consider a client. Taken from the spec:

"Any line whose first three characters are "```" (i.e. three consecutive back ticks with no leading whitespace) are preformatted toggle lines. 
These lines should NOT be included in the rendered output shown to the user."

I think the alt text feature would be a very useful tool in making gemini more accessible than gopher. The web is an accessibility nightmare 
and some simple planning and very low overhead features can be implemented here in gemini to make it more approachable to all users, 
but especially those that use various assistive technologies. 

Again, this is a very bikeshed oriented topic and I am not wanting to start a new rabbit hole on this.  Solderpunk, if you are reading this, I
too remember the formatting conversations and do not relish a deep dive back in. So feel free to chime in and pump the breaks on this
convo if you think that is the right approach.

From b__m__e at mailfence.com  Sun May 17 18:33:02 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 17 May 2020 19:33:02 +0200 (CEST)
Subject: [ANN] Gemini Mailing List gemini mirror
In-Reply-To: <20200517093012.25349b6f@socimda>
References: <1044942723.361254.1589682065502@ichabod.co-bxl>
 <20200517093012.25349b6f@socimda>
Message-ID: <1868264787.391361.1589736782508@ichabod.co-bxl>

> Wouldn't it be better to have a mail server scripted to write the mails
> into files instead of a scraper? It would be almost real-time.

It might be. However, I know nothing about mail servers and do not wish to wade into those
waters at present. If you'd like to build it I would definitely love to check out the code and
visit the resulting gemini capsule :)

> ~5 minutes are better than 6 hours IMO.

The 6 hours was due to it being run on a resource limited system that is shared by other users.
However, now that it is caught up with the more than 400 messages for 2020, it uses up a lot
less processing time and memory to just keep up with the current posts. I have updated the 
CRON job to every 20 minutes.

My thought is that the gemini version is meant to be read as a digest a time or two a day. Not to
be constantly refreshed for new updates. At elast, that is the use case I built it for.

> Just throwing out ideas, feel free to say no :)

I genuinely appreciate the ideas! I had not thought of the mailserver route. As said above, it isnt
an area I know about so will likely not pursue... but it IS very interesting and could be a really
cool way to build something similar. While it isnt 5 minutes, I hope the 20 minute interval works
out better for you (and everyone).


It seems the server that I host through was down for a bit this morning (what may be afternoon
for many of you). It seems to be back up and cmccabe (the server admin) and I have been in touch
re: what happened. It seems there was a minor bug in the server code that has hopefully been
fixed. So if you didnt get a chance to check it out and wanted to, you should be able to now:

gemini://rawtext.club:1965/~sloum/geminilist/


From b__m__e at mailfence.com  Sun May 17 18:42:00 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 17 May 2020 19:42:00 +0200 (CEST)
Subject: Cognitive aspects of navigation in gemini space
Message-ID: <1487181786.391765.1589737320661@ichabod.co-bxl>

Ivy writes:
> I like the idea of severely limiting the available block-type options.
>
> How about this for block syntax, with the understanding that the alt
> text is highly recommended for accessibility. Specifying the block
> type and the programming language or written language (as appropriate)
> would be strictly optional: those that wanted to make use of them
> could, those who did not want to make use of them would not have to.
>
> For the purposes of this proposal, there would be *no space* between
> the backticks and the optional content-type field, which field may not
> contain spaces. There must be at least one space on the line before
> the (recommended) alt text. That way, the client doesn't need to try
> and figure out where one ends and one begins: the instant the client
> sees a space, we're into alt-text territory for the rest of the line.
>
> ```[art | code[:programming language] | text[:written language]] [alt text]
> ...
> ```

I think you hit on it perfectly Ivy. I love this proposal and it definitely has my full support.
It communicates a lot of information in a small space and is still very parsable. Given the
specs mandate of the ``` not being shown directly tot he user it should not clutter up
the document for those viewing it under most circumstances. It is also easy to write for
those developing content. I like that both parts are optional, but available, and a lot can
be communicated with them. Well done.

--?
Sent with https://mailfence.com
Secure and private email

From tomasino at lavabit.com  Sun May 17 18:52:38 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 17 May 2020 17:52:38 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <1487181786.391765.1589737320661@ichabod.co-bxl>
References: <1487181786.391765.1589737320661@ichabod.co-bxl>
Message-ID: <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>

On 5/17/20 5:42 PM, Brian Evans wrote:
> ```[art | code[:programming language] | text[:written language]] [alt text]
> ...
> ```

I'm getting lost in the brackets a bit. If I want to include alt text,
must i have art, code, or text as the first word, or no?

```art superman logo

vs

``` superman logo




From gmym at coopdot.com  Sun May 17 19:15:43 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sun, 17 May 2020 20:15:43 +0200
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
References: <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
Message-ID: <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>

James Tomasino <tomasino at lavabit.com> wrote:

> > ```[art | code[:programming language] | text[:written language]] [alt
> text]
> > ...
> > ```
>
> I'm getting lost in the brackets a bit. If I want to include alt text,
> must i have art, code, or text as the first word, or no?
>
> ```art superman logo
>
> vs
>
> ``` superman logo
>

Both are OK according to the proposal above, there is no "must" as
everything is optional

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/0aa642a0/attachment.htm>

From nicole at strega-nil.co  Sun May 17 19:36:44 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Sun, 17 May 2020 18:36:44 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
References: <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
Message-ID: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>

I think it makes a lot more sense to have a specific alt text marker; something like

```art | alt text here
```

or for example:

```code:cpp | Fibonacci implementation
int fib(int n) {
if (n < 2) {
return n;
}

return fib(n - 1) + fib(n - 2);
}
```

With this, one could tell what's alt text and what is the "kind" very easily.

- Nicole Mazzuca

P.S. Sorry for the HTML if this sends HTML, I'm using a mobile client and it is unclear how to do plain text.

-------- Original Message --------
On May 17, 2020, 11:15, Katarina Eriksson wrote:

> James Tomasino <tomasino at lavabit.com> wrote:
>
>>> ```[art | code[:programming language] | text[:written language]] [alt text]
>>> ...
>>> ```
>>
>> I'm getting lost in the brackets a bit. If I want to include alt text,
>> must i have art, code, or text as the first word, or no?
>>
>> ```art superman logo
>>
>> vs
>>
>> ``` superman logo
>
> Both are OK according to the proposal above, there is no "must" as everything is optional
>
> --
> Katarina
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/e9106866/attachment-0001.htm>

From jan6 at tilde.ninja  Sun May 17 19:36:58 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 18:36:58 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
References: <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
Message-ID: <d0586aa87569b39b4c1a85148bce50be@tilde.ninja>

May 17, 2020 9:15 PM, "Katarina Eriksson" <gmym at coopdot.com> wrote:
> 
> Both are OK according to the proposal above, there is no "must" as everything is optional
> 
everything except the space, is ;P
in order for the space to be optional it'd need to be [art|blabla][ alt] instead of [art|blabla] [alt], as latter makes it mandatory to have a space there no matter what (and a single space at that, not allowing tabs or multiple spaces)

I'm not sure having types which are optional, is too good of an idea, but otherwise it's nice...
what if I happen to have an alt text like "code red" on some art piece? accessible clients would read nonsense...

also don't really see the point/reasoning of the "text" type there, if it's not code nor art, what is it?
monospace text for no reason? maybe just "misc" category then? accessibility-wise you can just avoid art, so that doesn't seem to be much reason for a text type...

also maybe allow one-letter shorthand types? kinda like [a[rt]|c[ode]|t[ext]], use either "c hello.lua" or "code hello.lua"
not much practical value, but it allows one to only check the first character and skip to alt-text, if wanted (or ignore anything other than first 4 characters on that line)

From plugd at thelambdalab.xyz  Sun May 17 19:39:15 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Sun, 17 May 2020 20:39:15 +0200
Subject: [ANN] Gemini Mailing List gemini mirror
In-Reply-To: <1868264787.391361.1589736782508@ichabod.co-bxl>
References: <1044942723.361254.1589682065502@ichabod.co-bxl>
 <20200517093012.25349b6f@socimda>
 <1868264787.391361.1589736782508@ichabod.co-bxl>
Message-ID: <lzftby4d9o.fsf@bs-mbpr348.d.ethz.ch>

Hi Brian,

Brian Evans writes:
> So if you didnt get a chance to check it out and wanted to, you should be able to now:
>
> gemini://rawtext.club:1965/~sloum/geminilist/

Cool!  Just one issue: the gemini files you're serving for the emails
contain an unterminated ``` block.  (The terminating ``` characters are
actually there, but they're at the end of a line of text.  For example,
here's the header of one of Krixano's emails:

--- snip ---

=> gemini://rawtext.club/~sloum/geminilist/ <-- back to the mailing list
# Cognitive aspects of navigation in gemini space

Krixano  krixano at protonmail.com
Sun May 17 14:44:38 BST 2020

```
- - - - - - - - - - - - - - - - - - - ```

--- snip ---

(Just noticed that the email text wasn't wrapping nicely, and this was
the reason.)

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/060e4137/attachment.sig>

From plugd at thelambdalab.xyz  Sun May 17 19:43:15 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Sun, 17 May 2020 20:43:15 +0200
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
References: <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
Message-ID: <lzd0724d30.fsf@bs-mbpr348.d.ethz.ch>


Katarina Eriksson writes:
> James Tomasino <tomasino at lavabit.com> wrote:
>> ```art superman logo
>>
>> vs
>>
>> ``` superman logo
>>
>
> Both are OK according to the proposal above, there is no "must" as
> everything is optional

What if the alt text is "art superman logo"?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/b4ac7493/attachment.sig>

From jan6 at tilde.ninja  Sun May 17 19:43:41 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 18:43:41 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
Message-ID: <e214a360ffb4507aaab17281c49a164c@tilde.ninja>

May 17, 2020 9:36 PM, "Nicole Mazzuca" <nicole at strega-nil.co> wrote:

> I think it makes a lot more sense to have a specific alt text marker; something like
> 
> ```art | alt text here
> ```
> 
> With this, one could tell what's alt text and what is the "kind" very easily.

current proposal would mean you just treat everything after space as alt-text
the space is mandatory before alt-text in that proposal (probably should be "nonzero amount of <whitespace>")

nothing is preventing me from making an alt-text saying something like "this | that - a poem", so it wouldn't exactly solve anything, other than making it slightly easier to parse (separating only on first space shouldn't be hard at all anyway)

From tomasino at lavabit.com  Sun May 17 20:28:18 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 17 May 2020 19:28:18 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
Message-ID: <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>

On 5/17/20 6:43 PM, jan6 at tilde.ninja wrote:
> nothing is preventing me from making an alt-text saying something like "this | that - a poem", so it wouldn't exactly solve anything, other than making it slightly easier to parse (separating only on first space shouldn't be hard at all anyway)

I'm really leaning toward the simplest of all things, which is no
special "type" at all. Just

```[optional whitespace][optional alt text]

The art type is meaningless once we have an alt, so that's easy to
dismiss. The text type doesn't help tell me if the content should be
spidered or read aloud. Including a language property seems nice, but we
don't have a lang property on the whole document, so it's overkill in
this context.

Really the only thing we're doing is codifying a bunch of extra rules
and enumeration so that we can specify code syntax languages. That leads
to clients being able to mark things up, which is fine and all, but
seems far less important than the plain accessibily goal.

If this becomes cumbersome or fragile (space vs no space breaking
things) then people won't use it. I suggest the simpler approach here
will be better for gemini.

If people want to use the alt text area to indicate code & language,
then that's a pattern we can toss into the best practices doc. If it
gets put into practice, clients can check for it if it matters to them.


From nicole at strega-nil.co  Sun May 17 20:36:37 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Sun, 17 May 2020 19:36:37 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
Message-ID: <ENjFSeoe4tP6z-yyeCkr43aCN71o7XOhPen8ah0hiVU2oHVmzXSbxGgJliuSF3ZmRa6jmEj-xIuIaOAGzi0mhQuGqvTHiQqmr4kTSToNVGo=@strega-nil.co>

That seems like a mistake. Code highlighting is _really_ important for code gemlogs, imo.

Nicole

Sent from ProtonMail mobile

-------- Original Message --------
On May 17, 2020, 12:28, James Tomasino wrote:

> On 5/17/20 6:43 PM, jan6 at tilde.ninja wrote:
>> nothing is preventing me from making an alt-text saying something like "this | that - a poem", so it wouldn't exactly solve anything, other than making it slightly easier to parse (separating only on first space shouldn't be hard at all anyway)
>
> I'm really leaning toward the simplest of all things, which is no
> special "type" at all. Just
>
> ```[optional whitespace][optional alt text]
>
> The art type is meaningless once we have an alt, so that's easy to
> dismiss. The text type doesn't help tell me if the content should be
> spidered or read aloud. Including a language property seems nice, but we
> don't have a lang property on the whole document, so it's overkill in
> this context.
>
> Really the only thing we're doing is codifying a bunch of extra rules
> and enumeration so that we can specify code syntax languages. That leads
> to clients being able to mark things up, which is fine and all, but
> seems far less important than the plain accessibily goal.
>
> If this becomes cumbersome or fragile (space vs no space breaking
> things) then people won't use it. I suggest the simpler approach here
> will be better for gemini.
>
> If people want to use the alt text area to indicate code & language,
> then that's a pattern we can toss into the best practices doc. If it
> gets put into practice, clients can check for it if it matters to them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/d49f44e0/attachment.htm>

From ech at emmah.net  Sun May 17 20:36:52 2020
From: ech at emmah.net (Emma Humphries)
Date: Sun, 17 May 2020 12:36:52 -0700
Subject: ssh tunneling for gemini services
Message-ID: <0a40e75d-e6a2-4f02-b6e2-05a58b2e890f@www.fastmail.com>

Hi, 

Since gemini is well suited to run on small machines such a raspberry pi's, I'd like to use a SSH tunnel to make a server public. 

Pagekite doesn't support the 1965 port yet, and I'm asking them if they would consider it.

Are there other SSH tunnel hosting services that are specifically supporting gemini:// or allowing arbitrary ports?

-- Emma H

From ech at emmah.net  Sun May 17 20:45:14 2020
From: ech at emmah.net (Emma Humphries)
Date: Sun, 17 May 2020 12:45:14 -0700
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <ENjFSeoe4tP6z-yyeCkr43aCN71o7XOhPen8ah0hiVU2oHVmzXSbxGgJliuSF3ZmRa6jmEj-xIuIaOAGzi0mhQuGqvTHiQqmr4kTSToNVGo=@strega-nil.co>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <ENjFSeoe4tP6z-yyeCkr43aCN71o7XOhPen8ah0hiVU2oHVmzXSbxGgJliuSF3ZmRa6jmEj-xIuIaOAGzi0mhQuGqvTHiQqmr4kTSToNVGo=@strega-nil.co>
Message-ID: <b110d2a9-6746-4926-82de-a5bdedac9e6d@www.fastmail.com>

On Sun, May 17, 2020, at 12:36, Nicole Mazzuca wrote:
> That seems like a mistake. Code highlighting is _really_ important for 
> code gemlogs, imo.

Because there's already a large, potential base of content that would be ported to hosting on gemini, I'm worried that over-specifying the "alt-text" would create an extra set of steps for content creators. 

Perhaps the client can be opinionated, or ask the user what they want to do with a text block.

"This text block has no hints, should I just render it as monospaced text?"
"This text block has the hint text 'art' should I render it as ascii art?"
"If I run across text blocks with alt text like javascript, fortran, ruby, css... should I apply code formatting"

But the baseline for the client would be to say "it's a text block, I'm rendering it as monospace".

-- Emma

From tomasino at lavabit.com  Sun May 17 20:55:39 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 17 May 2020 19:55:39 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <b110d2a9-6746-4926-82de-a5bdedac9e6d@www.fastmail.com>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <ENjFSeoe4tP6z-yyeCkr43aCN71o7XOhPen8ah0hiVU2oHVmzXSbxGgJliuSF3ZmRa6jmEj-xIuIaOAGzi0mhQuGqvTHiQqmr4kTSToNVGo=@strega-nil.co>
 <b110d2a9-6746-4926-82de-a5bdedac9e6d@www.fastmail.com>
Message-ID: <e36e1a77-c247-8c64-e33d-7f61743cecb1@lavabit.com>

On 5/17/20 7:45 PM, Emma Humphries wrote:
> "This text block has no hints, should I just render it as monospaced text?"

```
with nothing after it, this would be the default. It can apply
monospaced text, but won't stop screen readers from parsing it or search
engines from spidering it.

> "This text block has the hint text 'art' should I render it as ascii art?"

``` some sort of alt text
handles art, weird formatted text that can't parse, figlet, etc. Accessible!

> "If I run across text blocks with alt text like javascript, fortran, ruby, css... should I apply code formatting"

``` !code pascal
Give it some special token to indicate to clients that care that it can
be handled in a special way. Don't know what the token should be. Could
be a hash-bang! :)

Nicole says code highlighting is important. Granted there's a lot of
that type of content coming. I still don't think we need to
overcomplicate this thing.


From meff at meff.me  Sun May 17 21:05:07 2020
From: meff at meff.me (Meff)
Date: Sun, 17 May 2020 13:05:07 -0700
Subject: Gemini Nim Client Library
Message-ID: <f295e976-6deb-1dc5-5eab-77fdb1dcfd2f@meff.me>

Hey all,

I wanted to take a stab at creating a featureful Nim client for Gemini. 
I don't write much Nim, but I modeled a lot of it on the Nim httpclient. 
Right now it supports both a regular client and an async client, and 
included are examples of using both clients. I'll be documenting and 
adding tests as I continue to develop and add more features.

I plan on writing a user-facing client in Nim and I'll be using my work 
on that to get some "real-world" experience dogfeeding this library. 
Please feel free to leave any feedback!

Nim Library: https://github.com/Koshroy/gemclient

Thanks,
Koushik

From jan6 at tilde.ninja  Sun May 17 21:07:43 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 20:07:43 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <ENjFSeoe4tP6z-yyeCkr43aCN71o7XOhPen8ah0hiVU2oHVmzXSbxGgJliuSF3ZmRa6jmEj-xIuIaOAGzi0mhQuGqvTHiQqmr4kTSToNVGo=@strega-nil.co>
References: <ENjFSeoe4tP6z-yyeCkr43aCN71o7XOhPen8ah0hiVU2oHVmzXSbxGgJliuSF3ZmRa6jmEj-xIuIaOAGzi0mhQuGqvTHiQqmr4kTSToNVGo=@strega-nil.co>
 <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
Message-ID: <cb624460511a286eef3633584187dd8b@tilde.ninja>

May 17, 2020 10:36 PM, "Nicole Mazzuca" <nicole at strega-nil.co> wrote:
> That seems like a mistake. Code highlighting is _really_ important for code gemlogs, imo.

can't you just get that out of the filename?
just have a convention that the alt text starts with the filename of the code, if applicable?
and I'm not aware of anything with syntax to highlight that DOESN'T have a filename extension like .js or .py or .yaml or whatnot...

``` code.py
print("hello")
```
``` code2.sh prints "world"
echo "world"
```
```example.json about how to do nothing
{"abc":123}
```

and whatnot, stuff like that?

From jmcbray at carcosa.net  Sun May 17 22:41:33 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Sun, 17 May 2020 17:41:33 -0400
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <5EC1099D.9060102@gmail.com> (Luke Emmet's message of "Sun, 17
 May 2020 10:53:33 +0100")
References: <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
 <20200517084004.GA23565@SDF.ORG> <5EC1099D.9060102@gmail.com>
Message-ID: <87wo5a5jea.fsf@dorothy.carcosa.net>

Luke Emmet <luke.emmet at gmail.com> writes:

> I think certain common idioms can be implemented by a client as a UI
> pretification, for example the frequently seen square bracket
> citations could be expanded [like this] or this [1]. The community
> could encourage this idiom as it is very gemini-friendly.
>
> => scheme://domain/path1 [like this]
> => scheme://domain/path2 [1]

I think something like this as a "best practice" is our best substitute
for inline links. I'd add a short link description after the bracketed
expression in the link line, like this[3]

=> gemini://domain/path3     [1] Further discussion of link formats

I had tried things like *, ?, ?, as in print, but they're not that great
visually, especially without the ability to superscript them.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Sun May 17 22:43:53 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Sun, 17 May 2020 17:43:53 -0400
Subject: Elpher 2.7.0: the text/gemini update
In-Reply-To: <lztv0gg2it.fsf@bs-mbpr348.d.ethz.ch> (plugd@thelambdalab.xyz's
 message of "Sat, 16 May 2020 02:13:46 +0200")
References: <lztv0gg2it.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <87sgfy5jae.fsf@dorothy.carcosa.net>

plugd <plugd at thelambdalab.xyz> writes:

> Anybody using elpher might be interested to know that I've just pushed a
> number of gemini-centric improvements/changes.

Thanks so much for this! I've really been looking forward to it.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Sun May 17 22:47:02 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Sun, 17 May 2020 17:47:02 -0400
Subject: An observation about client certificates
In-Reply-To: <20200516002209.GJ24022@brevard.conman.org> (Sean Conner's
 message of "Fri, 15 May 2020 20:22:09 -0400")
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 <fdee9e98-528b-4bad-b154-859721b1e3e4@www.fastmail.com>
 <20200516002209.GJ24022@brevard.conman.org>
Message-ID: <87o8qm5j55.fsf@dorothy.carcosa.net>

Sean Conner <sean at conman.org> writes:

>   Over the past hour, I've over 2,700 requests in my client torture test,
> specifically, test #22, leading into the "Redirect From Hell" portion.  If
> it was going any faster, I'd probably block it with the firewall, but my
> question to Dave is, what happens on your server when something like this
> happens?  You don't log the IP, so now what?  

Yeah, IMO you need to log IP addresses in case you need to blacklist
them either in the server or the firewall, in cases of abuse. If you
only kept hashes of addresses, you could check them in the server for
blocking, but it would not be as fast.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jan6 at tilde.ninja  Sun May 17 22:48:18 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Sun, 17 May 2020 21:48:18 +0000
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <87wo5a5jea.fsf@dorothy.carcosa.net>
References: <87wo5a5jea.fsf@dorothy.carcosa.net>
 <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
 <20200517084004.GA23565@SDF.ORG> <5EC1099D.9060102@gmail.com>
Message-ID: <ab62876d28dde746cc195931ad2f3baf@tilde.ninja>

May 18, 2020 12:41 AM, "Jason McBrayer" <jmcbray at carcosa.net> wrote:
> => gemini://domain/path3 [1] Further discussion of link formats
> 
> I had tried things like *, ?, ?, as in print, but they're not that great
> visually, especially without the ability to superscript them.

technically you can use unicode with superscript block, like: x???? and whatnot,
but that's...probably not the best way to go about it

I like your format the best of the ones I've seen so far

From benulo at systemli.org  Sun May 17 22:56:59 2020
From: benulo at systemli.org (Ben)
Date: Mon, 18 May 2020 02:26:59 +0430
Subject: Wikipedia mirror over gemini "proxy"
In-Reply-To: <ab62876d28dde746cc195931ad2f3baf@tilde.ninja>
References: <87wo5a5jea.fsf@dorothy.carcosa.net>
 <CAMPYpA6ww7HW52qb1OZ7w589hd0sifgFTc-tKL3QMpUvP93+LA@mail.gmail.com>
 <cab1ed8a-caf3-7e39-5b06-0a08e3fd7b4f@systemli.org>
 <20200517084004.GA23565@SDF.ORG> <5EC1099D.9060102@gmail.com>
 <ab62876d28dde746cc195931ad2f3baf@tilde.ninja>
Message-ID: <0529f1c4-0991-9750-1fdc-3fb8dfa6a4d0@systemli.org>

I for one am Unicode-positive... it's actually one of the main reasons I 
chose to start using Gemini in the first place, so I could create 
pages/documents that use it. They might not render in old Unix 
terminals, but nowadays even my Linux desktop has support for crazy 
things like emoji that I now see even while I'm using irssi. We just 
have to embrace it.

On 5/18/20 2:18 AM, jan6 at tilde.ninja wrote:
> but that's...probably not the best way to go about it

-- 
gemini://kwiecien.us/


From krixano at protonmail.com  Sun May 17 23:08:27 2020
From: krixano at protonmail.com (Krixano)
Date: Sun, 17 May 2020 22:08:27 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <d0586aa87569b39b4c1a85148bce50be@tilde.ninja>
References: <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <d0586aa87569b39b4c1a85148bce50be@tilde.ninja>
Message-ID: <xyHMPccUG85eq-DCZ0PUBGmKeDnCBjDppMkvajFz2z2HiNa0pKRIPZXSUxcyf15H64IqT_i7NzGqn-V0Uie3v_M_rZskjPOis8LW9fc5elA=@protonmail.com>

> also don't really see the point/reasoning of the "text" type there, if it's not code nor art, what is it?
monospace text for no reason? maybe just "misc" category then? accessibility-wise you can just avoid art, so that doesn't seem to be much reason for a text type...

Don't forget about Poetry! :)


Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Sunday, May 17, 2020 1:36 PM, <jan6 at tilde.ninja> wrote:

> May 17, 2020 9:15 PM, "Katarina Eriksson" gmym at coopdot.com wrote:
>
> > Both are OK according to the proposal above, there is no "must" as everything is optional
>
> everything except the space, is ;P
> in order for the space to be optional it'd need to be [art|blabla][ alt] instead of [art|blabla] [alt], as latter makes it mandatory to have a space there no matter what (and a single space at that, not allowing tabs or multiple spaces)
>
> I'm not sure having types which are optional, is too good of an idea, but otherwise it's nice...
> what if I happen to have an alt text like "code red" on some art piece? accessible clients would read nonsense...
>
> also don't really see the point/reasoning of the "text" type there, if it's not code nor art, what is it?
> monospace text for no reason? maybe just "misc" category then? accessibility-wise you can just avoid art, so that doesn't seem to be much reason for a text type...
>
> also maybe allow one-letter shorthand types? kinda like [a[rt]|c[ode]|t[ext]], use either "c hello.lua" or "code hello.lua"
> not much practical value, but it allows one to only check the first character and skip to alt-text, if wanted (or ignore anything other than first 4 characters on that line)



From aaron at ajanse.me  Mon May 18 00:38:42 2020
From: aaron at ajanse.me (Aaron Janse)
Date: Sun, 17 May 2020 16:38:42 -0700
Subject: =?UTF-8?Q?Re:_Announcing_`gurl`:_like_`curl`_but_for_gemini_+_release_of?=
 =?UTF-8?Q?_`gurl`_like_`curl`_but_by_another_person?=
In-Reply-To: <0cabb393-5d83-46ad-87bc-a438b662062e@www.fastmail.com>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
 <20200517093122.GI23565@SDF.ORG>
 <f57722ed-6865-ede6-4de8-f81a6cdd0075@masterq32.de>
 <0cabb393-5d83-46ad-87bc-a438b662062e@www.fastmail.com>
Message-ID: <6c2f90ee-4203-47f4-b3d4-6b14ab8462de@www.fastmail.com>

I've renamed the project to `gcat`: https://github.com/aaronjanse/gcat

On Sun, May 17, 2020, at 4:46 AM, Aaron Janse wrote:
> That's super cool. I'll rename my project tomorrow.
> 
> On Sun, May 17, 2020, at 4:00 AM, Felix Quei?ner wrote:
> > Hey!
> > 
> > 
> > > Well, this is awkward...how do you want these projects listed at the
> > > software page?
> > I have no problem with changing the name of my project, but i actually
> > try to mimic real curl command line options, so something similar to
> > "curl" would be appropriate.
> > 
> > I'd love to hear some suggestions for names!
> > 
> > Regards
> > xq
> >
>

From benulo at systemli.org  Mon May 18 01:33:29 2020
From: benulo at systemli.org (Ben)
Date: Mon, 18 May 2020 05:03:29 +0430
Subject: Announcing `gurl`: like `curl` but for gemini + release of `gurl`
 like `curl` but by another person
In-Reply-To: <6c2f90ee-4203-47f4-b3d4-6b14ab8462de@www.fastmail.com>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
 <20200517093122.GI23565@SDF.ORG>
 <f57722ed-6865-ede6-4de8-f81a6cdd0075@masterq32.de>
 <0cabb393-5d83-46ad-87bc-a438b662062e@www.fastmail.com>
 <6c2f90ee-4203-47f4-b3d4-6b14ab8462de@www.fastmail.com>
Message-ID: <38bd7630-f6e9-8709-93c7-e40db669be8b@systemli.org>

Was "gat" taken?

On 5/18/20 4:08 AM, Aaron Janse wrote:
> I've renamed the project to `gcat`:https://github.com/aaronjanse/gcat

-- 
gemini://kwiecien.us/


From sean at conman.org  Mon May 18 01:49:48 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 17 May 2020 20:49:48 -0400
Subject: Gemini Nim Client Library
In-Reply-To: <f295e976-6deb-1dc5-5eab-77fdb1dcfd2f@meff.me>
References: <f295e976-6deb-1dc5-5eab-77fdb1dcfd2f@meff.me>
Message-ID: <20200518004947.GB30203@brevard.conman.org>

It was thus said that the Great Meff once stated:
> Hey all,
> 
> I wanted to take a stab at creating a featureful Nim client for Gemini. 
> I don't write much Nim, but I modeled a lot of it on the Nim httpclient. 
> Right now it supports both a regular client and an async client, and 
> included are examples of using both clients. I'll be documenting and 
> adding tests as I continue to develop and add more features.
> 
> I plan on writing a user-facing client in Nim and I'll be using my work 
> on that to get some "real-world" experience dogfeeding this library. 
> Please feel free to leave any feedback!

  You might want to test this against the client torture test at

	gemini://gemini.conman.org/test/torture/

  -spc


From sean at conman.org  Mon May 18 02:02:51 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 17 May 2020 21:02:51 -0400
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
Message-ID: <20200518010251.GC30203@brevard.conman.org>

It was thus said that the Great James Tomasino once stated:
> Including a language property seems nice, but we
> don't have a lang property on the whole document, so it's overkill in
> this context.

  It could be included with the MIME type as:

	text/gemini; lang=en_US

or maybe as:

	text/gemini; language=se_NO

  -spc (There is a way ... )


From tomasino at lavabit.com  Mon May 18 12:25:04 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 18 May 2020 11:25:04 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200518010251.GC30203@brevard.conman.org>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
Message-ID: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>

On 5/18/20 1:02 AM, Sean Conner wrote:
>   It could be included with the MIME type as:
> 
> 	text/gemini; lang=en_US

As language directives would help with client-side translation options
and aid global access to content I am a fan! However, I don't see a way
of accomplishing this purely on the server level without a blanket
decision that all your content is going to be in one language. If we
allow it to be set at the document level then we're starting to add
document header.

It would be neat if there's a way. Anyone else see a good option that
doesn't introduce extensibility or complexity?


From defdefred at protonmail.com  Mon May 18 12:50:30 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 18 May 2020 11:50:30 +0000
Subject: About document signing
Message-ID: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>

Hello,

I'm reading Gemini stuff for days now and I feel that the idea of a lighter and safer web is marvelous.

I must confess that TLS is a big issue for me.
I don't really trust TLS as company/states nowdays use TLS interception and we should consider TLS as broken.
Really secure application are now using end-to-end encryption at application level (protonmail, etc.).

Why not simply using GPG?

Signing all document at publication time (oneshoot computation) and serving gemini page with server/path/document.gmi + server/path/document.gpg could assure you that the original document is free of hacking and don't break minimalist gemini browser.

* This keep the phylosophy of serving data with only one connexion, the second for security purpose is optional.
* Keeping vital data (text) throughput requirement low is important to spread on network with low bandwidth and high latency.


Regards, K.I.S.S and Less is More :-)
freD.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - defdefred at protonmail.com - 0xF2B9981B.asc
Type: application/pgp-keys
Size: 1828 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/f8e85cc8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/f8e85cc8/attachment.sig>

From koushik at meff.me  Sun May 17 21:03:33 2020
From: koushik at meff.me (Koushik Roy)
Date: Sun, 17 May 2020 13:03:33 -0700
Subject: Gemini Nim Client Library
Message-ID: <7438eafe-7a6a-6335-1c48-7bced94f01dd@meff.me>

Hey all,

I wanted to take a stab at creating a featureful Nim client for Gemini. 
I don't write much Nim, but I modeled a lot of it on the Nim httpclient. 
Right now it supports both a regular client and an async client, and 
included are examples of using both clients. I'll be documenting and 
adding tests as I continue to develop and add more features.

I plan on writing a user-facing client in Nim and I'll be using my work 
on that to get some "real-world" experience dogfeeding this library. 
Please feel free to leave any feedback!

Nim Library: https://github.com/Koshroy/gemclient

Thanks,
Koushik

From plugd at thelambdalab.xyz  Mon May 18 13:00:06 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Mon, 18 May 2020 14:00:06 +0200
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
 <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
Message-ID: <lzwo59sbax.fsf@bs-mbpr348.d.ethz.ch>

Hi James,

James Tomasino writes:
> On 5/18/20 1:02 AM, Sean Conner wrote:
> decision that all your content is going to be in one language. If we
> allow it to be set at the document level then we're starting to add
> document header.

Maybe in the source files held on the server, but this could also be
specified on a per-directory or even per-user basis.  But this is just
server implementation detail, isn't it?  The text/gemini response that's
actually served doesn't accrue a header.

A gopher analogy: none of the "gopher maps" served up for my gopherhole
look anything like the source files from which they're generated. But
that has nothing to do with RFC-1436.

> It would be neat if there's a way. Anyone else see a good option that
> doesn't introduce extensibility or complexity?

It's just a parameter in the content type string, is it really
introducing extensibility when servers are already free to add as many
of these as they like (up to the character limit), and clients are free
to ignore them?

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/5ed68b0a/attachment.sig>

From defdefred at protonmail.com  Mon May 18 13:05:11 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 18 May 2020 12:05:11 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
 <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
Message-ID: <bAVNbmiJSc2cM6KFnsRbk5IBDvPimSox-vnqwpaKkTVG2i3xjMfkOSPziPPDoTrWmdeV26yrmODADyheBS-N7pw08bahdkWkiaoDj5QRBlQ=@protonmail.com>

On Monday 18 May 2020 13:25, James Tomasino <tomasino at lavabit.com> wrote:
> It would be neat if there's a way. Anyone else see a good option that
> doesn't introduce extensibility or complexity?

Sometime, things must be strict and old files must be remaster :-)

UTF-8 as mandatory character set for gemini page with .gmi extension!

All other text encoding should be consider as external content and manage by external software.

Regards, K.I.S.S and Less is more :-)
freD.


From jmcbray at carcosa.net  Mon May 18 13:13:34 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 18 May 2020 08:13:34 -0400
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200517171703.GA2317@thrax.localdomain> (Ivy Foster's message
 of "Sun, 17 May 2020 12:17:03 -0500")
References: <1558722495.384905.1589728782465@ichabod.co-bxl>
 <20200517171703.GA2317@thrax.localdomain>
Message-ID: <87imgt5tld.fsf@dorothy.carcosa.net>

Ivy Foster <escondida at iff.ink> writes:

> How about this for block syntax, with the understanding that the alt
> text is highly recommended for accessibility.[...]

I quite like the content of this proposal. It reminds me of org-mode
source blocks.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jan6 at tilde.ninja  Mon May 18 13:29:42 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Mon, 18 May 2020 12:29:42 +0000
Subject: About document signing
In-Reply-To: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
References: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
Message-ID: <be80b7e94fdcbdb59218570732b593d1@tilde.ninja>

May 18, 2020 2:50 PM, "defdefred" <defdefred at protonmail.com> wrote:

> Hello,
> 
> I'm reading Gemini stuff for days now and I feel that the idea of a lighter and safer web is
> marvelous.
> 
> I must confess that TLS is a big issue for me.
> I don't really trust TLS as company/states nowdays use TLS interception and we should consider TLS
> as broken.

well... the spec recommends TOFU verification, which would mean you can safely self-sign your sites, which many do
the TOFU part, as is mentioned in the spec, works by trusting the first cert you see,
so all you'd need to do is get the site ONCE, through a trusted connection, and be done with it, you can just ignore all the CAs and chains or trust and whatnot,
so unless the company/state manages to re-encrypt with the exact SAME KEY, you will see it differ, and can warn user or refuse connection.

PGP isn't a bad idea, but I don't think there's anywhere CLOSE to as much support to PGP APIs than there is to TLS, in various programming languages, and calling an OS program, even when possible, is usually seen as a bad idea...

From solderpunk at SDF.ORG  Mon May 18 13:45:18 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 12:45:18 +0000
Subject: About document signing
In-Reply-To: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
References: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
Message-ID: <20200518124518.GA11560@SDF.ORG>

On Mon, May 18, 2020 at 11:50:30AM +0000, defdefred wrote:
> 
> Why not simply using GPG?
> 
> Signing all document at publication time (oneshoot computation) and serving gemini page with server/path/document.gmi + server/path/document.gpg could assure you that the original document is free of hacking and don't break minimalist gemini browser.

Unless I've badly misunderstood something, this solution:

1) Provides literally nothing in the way of confidentiality (the first
request happens totally as plaintext, right?).  That means your ISP
can monitor everything you read via Gemini and compile a behavioural
profile to sell to marketers and/or to have stolen by state security
serivices.  States with censorship regimes can requires ISPs to
terminate connections when forbidden keywords are detected in plaintext
content.  In this respect, Gemini would be no improvement over Gopher.

2) Provides authentication and integrity if and only if the client has
some totally unspecified way of securely acquiring the public key
required to validate the signature downloaded in the second request
- i.e. if we assume that the really hard part of public key cryptography
is already solved.

TLS certainly has problems, but it's better than this!

Of course, there is nothing wrong with signing files to be distributed
via Gemini and if this makes sense for people they can and should do
exactly this.  But it's not in any way a sensible blanket solution.

Cheers,
Solderpunk


From elkaod at gmail.com  Mon May 18 14:06:24 2020
From: elkaod at gmail.com (kaoD)
Date: Mon, 18 May 2020 15:06:24 +0200
Subject: About document signing
In-Reply-To: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
References: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
Message-ID: <CADG3GQ1rvQU=T3SmDfi9bS26wRf3bHZKrxKyU=iZg2bG8R4dSg@mail.gmail.com>

Hi!

I love cryptography so this is kinda my area of interest. Just to add to
solderpunk's great reply: modern TLS with DH also adds forward secrecy,
which is a very desirable property that GPG lacks.

Inline on freD's message:

I must confess that TLS is a big issue for me.
I don't really trust TLS as company/states nowdays use TLS interception and
we should consider TLS as broken.


Can you elaborate? What is TLS interception and how does it make TLS broken?

Really secure application are now using end-to-end encryption at
application level (protonmail, etc.).


AFAIK Protonmail uses both: TLS for in-transit crypto (communication with
Protonmail servers) and GPG for at-rest crypto (the actual mail contents).

As a reminder: TLS is end-to-end encrypted!

In summary: TLS and GPG solve different problems and they can be used
alongside. (Also: GPG is a nightmare and there are better alternatives[0],
but that's another story).

Cheers,
kaoD

[0] https://www.cryptologie.net/article/502/alternatives-to-pgp/,
discussion in Reddit
https://www.reddit.com/r/crypto/comments/ggvl2h/alternatives_to_pgp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/367bbf25/attachment.htm>

From jan6 at tilde.ninja  Mon May 18 14:10:04 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Mon, 18 May 2020 13:10:04 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
References: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
 <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
Message-ID: <e74f207159efc48c88535a634222ff31@tilde.ninja>

May 18, 2020 2:25 PM, "James Tomasino" <tomasino at lavabit.com> wrote:
> However, I don't see a way of accomplishing this purely on the server level without a blanket decision that all your content is going to be in one language.

why not? there can be many approaches...

you can have metadata file, that has a list, like
 hello-en.gmi en-US
 hello-et.gmi et-EE

you could separate directories by language, and have the server serve them as if they were in the same dir
 en-US/hello.gmi ? hello.gmi
 sv_SE/hi.gmi ? hi.gmi
with some duplicate checking probably

you could have a little header in your source files, just the first line, and have server ignore the first line
(it could be just language, or the entire mimetype, maybe)

etc etc, there are so many approaches to this ;P

From solderpunk at SDF.ORG  Mon May 18 14:24:38 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 13:24:38 +0000
Subject: About document signing
In-Reply-To: <CADG3GQ1rvQU=T3SmDfi9bS26wRf3bHZKrxKyU=iZg2bG8R4dSg@mail.gmail.com>
References: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
 <CADG3GQ1rvQU=T3SmDfi9bS26wRf3bHZKrxKyU=iZg2bG8R4dSg@mail.gmail.com>
Message-ID: <20200518132438.GA21960@SDF.ORG>

On Mon, May 18, 2020 at 03:06:24PM +0200, kaoD wrote:
 
> I love cryptography so this is kinda my area of interest. Just to add to
> solderpunk's great reply: modern TLS with DH also adds forward secrecy,
> which is a very desirable property that GPG lacks.

I am planning for the next spec revision to state that Gemini
transactions using TLS 1.2 MUST use only a limited set of ciphersuites,
all of which will provide forward secrecy.  I will be relying on the
community to help curate a list of example code for different
languages/libraries to impose these constraints.

As I've said elsewhere, I would *love* to spec only TLS 1.3 or above,
where all options provide forward secrecy and old cruft like RC4 has
been removed.  But this would be equivalent to requiring OpenSSL, which
I'd rather not do.  As a compromise, 1.2 will be allowed but only if
used responsibly.

> Can you elaborate? What is TLS interception and how does it make TLS broken?

I imagine this is mostly in reference to companies loading their
employee's computers with browsers that have the company's own CA added
alongside the browser's defaults.  Which is not a cryptographic break of
TLS in any way.

Cheers,
Solderpunk


From tomasino at lavabit.com  Mon May 18 14:31:44 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 18 May 2020 13:31:44 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <e74f207159efc48c88535a634222ff31@tilde.ninja>
References: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
 <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
 <e74f207159efc48c88535a634222ff31@tilde.ninja>
Message-ID: <25e4ddde-59cd-9a2d-c6db-cf6c38d3b392@lavabit.com>

On 5/18/20 1:10 PM, jan6 at tilde.ninja wrote:
> you could have a little header in your source files, just the first line, and have server ignore the first line
> (it could be just language, or the entire mimetype, maybe)
> 
> etc etc, there are so many approaches to this ;P

There's a few decent ideas floating around already, I'll admit. I hope
one of them resonates with people. I'm wary of ones that involve adding
things to a gemini file, though, especially if they're not spec. If one
server decides to implement a language header by adding content to the
top of a .gmi, then moving content to another server type has burden
added. Little things like that add up and you end up with the different
"flavors" like markdown.

This is doubly true for what plugd was saying about gopher maps not
looking like the files that they are authored in for many gopher
servers. I would hope we can avoid this problem from the start. The .gmi
spec is simple and flexible. I'd hate to see us get into a situation
where we are creating new languages to generate it for transport so
early in the life of gemini.

I like your idea of a metadata file. I doubly-like it because then it's
an individual problem servers can handle on their own without us needing
to address anything more in the specs.


From defdefred at protonmail.com  Mon May 18 14:52:02 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 18 May 2020 13:52:02 +0000
Subject: About document signing
In-Reply-To: <20200518124518.GA11560@SDF.ORG>
References: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
 <20200518124518.GA11560@SDF.ORG>
Message-ID: <11orlTaAGSzMt8IONG4qa4f3Q2MbqyNagVIwTfDaWAR0LS0ZtIULvINhthshsibD-196zJ-Ay2CUc6kKQiD8MuCybW8_4VIeqrxdJoLznUI=@protonmail.com>

??????? Original Message ???????
On Monday 18 May 2020 14:45, solderpunk <solderpunk at SDF.ORG> wrote:
> 1.  Provides literally nothing in the way of confidentiality (the first
>     request happens totally as plaintext, right?). That means your ISP
>     can monitor everything you read via Gemini and compile a behavioural
>     profile to sell to marketers and/or to have stolen by state security
>     serivices. States with censorship regimes can requires ISPs to
>     terminate connections when forbidden keywords are detected in plaintext
>     content. In this respect, Gemini would be no improvement over Gopher.

GPG signing is only for data integrity and achieve simple secure public data diffusion with optional client driven computation.
If someone need to store private information in a gemini server I will tell him to store file already encryted with his public key.
Is TLS really useful in censorship regimes or are they closing access to all web site where they can't add TLS inspection?
Courageous people are rather using VPN and/or multiple ssh jump to hide...

With TLS, only the transport layer is "secure", but you don't know if someone hack the server and the files!
It is not End-to-End encrypted between the writer and the reader.

> 2.  Provides authentication and integrity if and only if the client has
>     some totally unspecified way of securely acquiring the public key
>     required to validate the signature downloaded in the second request

Initial TOFU is no more an option?

Maybe having gimini:// and TLS geminis:// is the way to go to keep gemini usable for small computer and low bandwith networks.

Imagine, the gemini browser:
1. download the first file.gmi and present it to the user.
2. download the second file.gpg while the user is reading.
3. after computation notice if file integrity is preserved.

Regards,
freD.


From solderpunk at SDF.ORG  Mon May 18 15:01:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 14:01:58 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200518010251.GC30203@brevard.conman.org>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
Message-ID: <20200518140158.GA3866@SDF.ORG>

On Sun, May 17, 2020 at 09:02:51PM -0400, Sean Conner wrote:
 
>   It could be included with the MIME type as:
> 
> 	text/gemini; lang=en_US
> 
> or maybe as:
> 
> 	text/gemini; language=se_NO

I have been meaning to propose exactly this.

The FAQ says that the "first class" application of Gemini is human
consumption of predominantly written material, and specifying a language
is actually really important metadata for this application.  Knowing the
text encoding is not adequate:

Screenreaders (like Rhapsode) need to know a language to be able to
pronounce text vaguely correctly.

Text in some languages should be rendered right to left and/or top to
bottom.

The same word can mean very different things in different languages and
search engines should not return irrelevant results on this basis.

Someone is bound to ask: "Oh, does this mean text/gemini;
content-size=1234 is okay, too?".  No!  We are talking about MIME types
here.  This is *category* information.  Details specific to one
particular document are inappropriate.

Cheers,
Solderpunk


From defdefred at protonmail.com  Mon May 18 15:20:27 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 18 May 2020 14:20:27 +0000
Subject: About document signing
In-Reply-To: <CADG3GQ1rvQU=T3SmDfi9bS26wRf3bHZKrxKyU=iZg2bG8R4dSg@mail.gmail.com>
References: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
 <CADG3GQ1rvQU=T3SmDfi9bS26wRf3bHZKrxKyU=iZg2bG8R4dSg@mail.gmail.com>
Message-ID: <UjzeI_a3rPJGe-eEi_K1dwkuFZnBhBCHzlaXf4HTzHrcT1Ntmv68Y3VkVy_xxvB0OwgSKETxvYP4gNKdBOIzcwPAqpWbhjV6znDHqoi7PV4=@protonmail.com>

On Monday 18 May 2020 15:06, kaoD <elkaod at gmail.com> wrote:

> I love cryptography so this is kinda my area of interest. Just to add to solderpunk's great reply: modern TLS with DH also adds forward secrecy, which is a very desirable property that GPG lacks.
In cryptography, regular enhancement is mandatory :-)

> Can you elaborate? What is TLS interception and how does it make TLS broken?
https://en.wikipedia.org/wiki/Transport_Layer_Security_Security#TLS_interception

> AFAIK Protonmail uses both: TLS for in-transit crypto (communication with Protonmail servers) and GPG for at-rest crypto (the actual mail contents).
They use both because the old SMTP protocol is keeping metadata impossible to encrypt.

> As a reminder: TLS is end-to-end encrypted!
Not End-to-End (Writer-to-Reader)... Only Server-to-Browser, without protection for the hosted files.

> [0]?https://www.cryptologie.net/article/502/alternatives-to-pgp/, discussion in Reddit?https://www.reddit.com/r/crypto/comments/ggvl2h/alternatives_to_pgp/
Maybe the blog author is forgotting that GPG signing is not useful without verifying signature...

Regards,
freD.

From solderpunk at SDF.ORG  Mon May 18 15:25:17 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 14:25:17 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
 <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
Message-ID: <20200518142517.GC3866@SDF.ORG>

On Mon, May 18, 2020 at 11:25:04AM +0000, James Tomasino wrote:
 
> However, I don't see a way
> of accomplishing this purely on the server level without a blanket
> decision that all your content is going to be in one language.

Some equivalent of Apache's .htaccess files would allow users to specify
languages for particular files/directories.

One day, Molly Brown will recognise .molly files to allow things like
this, along with specifying MIME types for unusual/unconventional file
extensions, specifying client certificate fingerprints to restrict
access to some content to certain clients only, etc., etc.

I don't know that this approach is the best way to do it, it's just the
one I'm familiar with.  But, I mean, "Content-Language" is a HTTP
response header - there *must* be plenty of ideas out there in web land
that server authors could look to for ways to handle this.

Cheers,
Solderpunk

From defdefred at protonmail.com  Mon May 18 15:36:04 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 18 May 2020 14:36:04 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
References: <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
 <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
Message-ID: <UINuq56UZbejwqF8yvXwbOoyxrXXadJPaUTItZPyDEbbATU4_IggpSCryQKQD7_9nFef-AopD0zmlATrM3TwMCtX0Gzu-RNPeIoxRv6UsME=@protonmail.com>

On Monday 18 May 2020 13:25, James Tomasino <tomasino at lavabit.com> wrote:
> and aid global access to content I am a fan! However, I don't see a way
> of accomplishing this purely on the server level without a blanket
> decision that all your content is going to be in one language.

No need to be in only one language, UTF-8 is able to do all language in in the same document!

All new content is UTF-8 now, and older content can be easily converted.
https://en.wikipedia.org/wiki/UTF-8#/media/File:Utf8webgrowth.svg

Regards,
freD.

From solderpunk at SDF.ORG  Mon May 18 15:54:49 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 14:54:49 +0000
Subject: Announcing `gurl`: like `curl` but for gemini + release of
 `gurl` like `curl` but by another person
In-Reply-To: <6c2f90ee-4203-47f4-b3d4-6b14ab8462de@www.fastmail.com>
References: <b34039ef-3bce-4886-bc32-6d1369008955@www.fastmail.com>
 <49ec1584-44a0-9426-e395-658c35e5fd9b@masterq32.de>
 <2am88sYBN514ksDwIWbOf3ruoVn66SHrQALs6eALYnzLIf7gvGdBDK59ORbHSvN3YiTSXJ1F41_qQjdfiD_sbWO8t4CDhiIoAeXPhYvH_5U=@protonmail.com>
 <20200517093122.GI23565@SDF.ORG>
 <f57722ed-6865-ede6-4de8-f81a6cdd0075@masterq32.de>
 <0cabb393-5d83-46ad-87bc-a438b662062e@www.fastmail.com>
 <6c2f90ee-4203-47f4-b3d4-6b14ab8462de@www.fastmail.com>
Message-ID: <20200518145449.GD3866@SDF.ORG>

On Sun, May 17, 2020 at 04:38:42PM -0700, Aaron Janse wrote:
> I've renamed the project to `gcat`: https://github.com/aaronjanse/gcat

Very nice to see this naming collision resolved quickly and amicably!

Cheers,
Solderpunk


From jan6 at tilde.ninja  Mon May 18 16:00:01 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Mon, 18 May 2020 15:00:01 +0000
Subject: About document signing
In-Reply-To: <UjzeI_a3rPJGe-eEi_K1dwkuFZnBhBCHzlaXf4HTzHrcT1Ntmv68Y3VkVy_xxvB0OwgSKETxvYP4gNKdBOIzcwPAqpWbhjV6znDHqoi7PV4=@protonmail.com>
References: <UjzeI_a3rPJGe-eEi_K1dwkuFZnBhBCHzlaXf4HTzHrcT1Ntmv68Y3VkVy_xxvB0OwgSKETxvYP4gNKdBOIzcwPAqpWbhjV6znDHqoi7PV4=@protonmail.com>
 <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
 <CADG3GQ1rvQU=T3SmDfi9bS26wRf3bHZKrxKyU=iZg2bG8R4dSg@mail.gmail.com>
Message-ID: <7142eaf1287f7e3bd57b45ec75b85faa@tilde.ninja>

May 18, 2020 5:20 PM, "defdefred" <defdefred at protonmail.com> wrote:
>> As a reminder: TLS is end-to-end encrypted!
> 
> Not End-to-End (Writer-to-Reader)... Only Server-to-Browser, without protection for the hosted
> files.

even for PGP, unless you encrypt in a way decryptable with a specific key, you still only can trust as far as your server...
otherwise you need either some out of band way to get the key

if you get the key over gemini or other unencrypted connection, how do you know the key AND the data haven't been modified?
if you send plain content and then key, how do you know the separate key or signature was not modified on the server, or in transmission?

you can not have writer-to-reader encryption *AND* have it accessible to lots of people, without trusting the server...

From jan6 at tilde.ninja  Mon May 18 16:12:04 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Mon, 18 May 2020 15:12:04 +0000
Subject: SPOOFED: Cognitive aspects of navigation in gemini space
In-Reply-To: <UINuq56UZbejwqF8yvXwbOoyxrXXadJPaUTItZPyDEbbATU4_IggpSCryQKQD7_9nFef-AopD0zmlATrM3TwMCtX0Gzu-RNPeIoxRv6UsME=@protonmail.com>
References: <UINuq56UZbejwqF8yvXwbOoyxrXXadJPaUTItZPyDEbbATU4_IggpSCryQKQD7_9nFef-AopD0zmlATrM3TwMCtX0Gzu-RNPeIoxRv6UsME=@protonmail.com>
 <jYUFUr7iZPhzfXo7fIbW1Ufe3RncgDKyLvuO652eOLvV0GH8HJCEPWA7u4HuhO09DjiHX5iVhUgkxr2Xl9pCiqDdc0w3720-BuBSGNU8IUM=@strega-nil.co>
 <1487181786.391765.1589737320661@ichabod.co-bxl>
 <0c1a17b5-aed9-8f01-19d2-a95594c68869@lavabit.com>
 <CAObwWNgaHq1qOz09ZH=onznvku7CfUXjtztsh-qbQRoWk3WYWw@mail.gmail.com>
 <e214a360ffb4507aaab17281c49a164c@tilde.ninja>
 <cbc30468-5357-8635-db81-ee55ff5da39b@lavabit.com>
 <20200518010251.GC30203@brevard.conman.org>
 <3c69d4d0-6d17-0a9a-78d6-09d6a26ed041@lavabit.com>
Message-ID: <75d848017bcdecad1ab57e81b4b35827@tilde.ninja>

May 18, 2020 5:36 PM, "defdefred" <defdefred at protonmail.com> wrote:
> No need to be in only one language, UTF-8 is able to do all language in in the same document!

no, that's not the point
the point is, as stated before, allowing screen-readers and search engines to properly read the documents, and for allowing languages that render in a different direction to do so (like right-to left languages, or vertical writing), if you search "pain" you probably don't want to see a french page about making bread, if you read an icelandic page as english with TTS (such as those who're visually impaired might do), it will sound like absolute nonsense, etc...

utf-8 takes care of glyphs, but several things require knowing the language to work.

(while at it, a language code such as "zxx", the code for things known not to be in ANY language, should be supported, and used for things like ascii/unicode art)

From defdefred at protonmail.com  Mon May 18 17:18:50 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 18 May 2020 16:18:50 +0000
Subject: About client rendering...
Message-ID: <Oa7P4eHvj37ZcDBMRQL0Ow2RwI0q4uUEmMQBi_Hg7XZtAIaC_dMQHiyjp-2LS6WWa_J189zi1wkrBMI39_mE3HNvUNUzuB12X4bOC7WL9bk=@protonmail.com>

Considering the whole variety of screen we are using, what do you think of this idea?

* Phone used verticaly and old screen with pixel witdh < 1280, should display the text with one column.
* recent computer with 1280 <= pixel witdh < 1920, should display the document with 2 colunms or use only half of the screen to allow display of generated data like table of content, or external data like picture, video, http, gopher, etc... probably managed by external application.
* top of the line >= 1920 pixel wide could use more columns...

I notice that 1280 is 2x640 and 1920 is 3x640...
Of course, the user should be able to change the layout...

Regards,
freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/1158f287/attachment.htm>

From felix at masterq32.de  Mon May 18 17:33:30 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Mon, 18 May 2020 18:33:30 +0200
Subject: About client rendering...
In-Reply-To: <Oa7P4eHvj37ZcDBMRQL0Ow2RwI0q4uUEmMQBi_Hg7XZtAIaC_dMQHiyjp-2LS6WWa_J189zi1wkrBMI39_mE3HNvUNUzuB12X4bOC7WL9bk=@protonmail.com>
References: <Oa7P4eHvj37ZcDBMRQL0Ow2RwI0q4uUEmMQBi_Hg7XZtAIaC_dMQHiyjp-2LS6WWa_J189zi1wkrBMI39_mE3HNvUNUzuB12X4bOC7WL9bk=@protonmail.com>
Message-ID: <7a880d06-b04c-d1b8-357b-405187914187@masterq32.de>

Hey,

> Considering the whole variety of screen we are using, what do you think of this idea?
I don't think we should specify how clients should display the data. We
gain much from having variety in clients, their kind of displaying and
everything. I for example use 1080p monitor with usually a two-column
layout[0].

> * Phone used verticaly and old screen with pixel witdh < 1280, should display the text with one column.
I often use my phone in landscape mode when reading text as i can put
more characters per line or have a slightly bigger font that eases
reading. I'd be sad if a system would force me into portrait mode

Regards
xq

[0] https://mq32.de/public/acbd2dc3ac6232e4a132408394c8e4cbe7fd3b7c.png

From solderpunk at SDF.ORG  Mon May 18 17:38:08 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 16:38:08 +0000
Subject: About client rendering...
In-Reply-To: <7a880d06-b04c-d1b8-357b-405187914187@masterq32.de>
References: <Oa7P4eHvj37ZcDBMRQL0Ow2RwI0q4uUEmMQBi_Hg7XZtAIaC_dMQHiyjp-2LS6WWa_J189zi1wkrBMI39_mE3HNvUNUzuB12X4bOC7WL9bk=@protonmail.com>
 <7a880d06-b04c-d1b8-357b-405187914187@masterq32.de>
Message-ID: <20200518163808.GF3866@SDF.ORG>

On Mon, May 18, 2020 at 06:33:30PM +0200, Felix Quei?ner wrote:
 
> I don't think we should specify how clients should display the data. We
> gain much from having variety in clients, their kind of displaying and
> everything. I for example use 1080p monitor with usually a two-column
> layout[0].

I assumed that this post was a suggestion for an interesting idea which
some client authors might care to discuss and experiment with, taking
advantage of the fact that content display is left to the client's
discretion in Gemini.  In which case, I'm all in favour of
experimentation and diversity and user choice on that front.
Multi-column rendering on wide screens certainly doesn't sound like a
bad idea, to me.

If it was a suggestion that we put something like this into the spec,
them I'm opposed and it's not happening.  Clients can do what they like.

Cheers,
Solderpunk

From peteyboy at sdf.org  Mon May 18 19:21:53 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Mon, 18 May 2020 11:21:53 -0700
Subject: Example Gemini pages?
Message-ID: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>

I can't find any reference that just shows some example Gemini markup page sources. I am confused by the => vs [..|..] link markup. I was just going to throw up a server on sdf and see, but im not ready to depend that kind of time on it yet. The Gemini project web page would be improved if you showed what gemini looks like, IMO.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200518/8e2a17f0/attachment-0001.htm>

From solderpunk at SDF.ORG  Mon May 18 19:46:18 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 18:46:18 +0000
Subject: Example Gemini pages?
In-Reply-To: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
Message-ID: <20200518184618.GG3866@SDF.ORG>

On Mon, May 18, 2020 at 11:21:53AM -0700, peteyboy at sdf.org wrote:
> I can't find any reference that just shows some example Gemini markup page sources. I am confused by the => vs [..|..] link markup. I was just going to throw up a server on sdf and see, but im not ready to depend that kind of time on it yet. The Gemini project web page would be improved if you showed what gemini looks like, IMO.

Well, there are several examples of the link syntax in the
specification.  But you make a good point: having a single, short
example text/gemini document which fits on a single screen and shows off
all the supported features in a clear and beginner-friendly way would be
a really useful thing to have.

If anybody wants to write one and send it to me, I'll gladly put it in
the documentation folder of the project page.

I might also update the FAQ to make it very clear that text/gemini is
*not* Markdown, and is not even a subset of Markdown.

Cheers,
Solderpunk

From colecmac at protonmail.com  Mon May 18 19:59:33 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 18 May 2020 18:59:33 +0000
Subject: Example Gemini pages?
In-Reply-To: <20200518184618.GG3866@SDF.ORG>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
 <20200518184618.GG3866@SDF.ORG>
Message-ID: <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>

Here's my attempt:

# Heading 1
## Heading 2
### Heading 3

Paragraphs and text are written normally. They are wrapped, so one paragraph should be written on one line. This line is part of the same paragraph
This line will not be added to the ones above, it will always be on a new line.


Spaces are not collapsed, there will always be two spaces above.

=> gemini://example.com/ Link text here
=> gemini://example.com/link/with/no/text
=>gemini://example.com/ Spaces after the => is optional

There are no inline links.

```
Preformatted text goes inside backticks, similar to markdown.
Another line.
```

There can also be unordered lists, using an asterisk:
* List item
* Another list item

Sub-lists are not supported.




How does that look? Did I forget anything?

makeworld

??????? Original Message ???????
On Monday, May 18, 2020 2:46 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Mon, May 18, 2020 at 11:21:53AM -0700, peteyboy at sdf.org wrote:
>
> > I can't find any reference that just shows some example Gemini markup page sources. I am confused by the => vs [..|..] link markup. I was just going to throw up a server on sdf and see, but im not ready to depend that kind of time on it yet. The Gemini project web page would be improved if you showed what gemini looks like, IMO.
>
> Well, there are several examples of the link syntax in the
> specification. But you make a good point: having a single, short
> example text/gemini document which fits on a single screen and shows off
> all the supported features in a clear and beginner-friendly way would be
> a really useful thing to have.
>
> If anybody wants to write one and send it to me, I'll gladly put it in
> the documentation folder of the project page.
>
> I might also update the FAQ to make it very clear that text/gemini is
> not Markdown, and is not even a subset of Markdown.
>
> Cheers,
> Solderpunk



From jmcbray at carcosa.net  Mon May 18 20:34:51 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 18 May 2020 15:34:51 -0400
Subject: About document signing
In-Reply-To: <11orlTaAGSzMt8IONG4qa4f3Q2MbqyNagVIwTfDaWAR0LS0ZtIULvINhthshsibD-196zJ-Ay2CUc6kKQiD8MuCybW8_4VIeqrxdJoLznUI=@protonmail.com>
 (defdefred@protonmail.com's message of "Mon, 18 May 2020 13:52:02 +0000")
References: <Pst0fJ3KnjxSPtEJtr3huujRNUQ04_aGmtz82g5EqDD91BmLtL1SBSFxjqkwz-brog2HCpTfqebm9ady10y-P5pNZGzs06DV2yS0lKTpOXI=@protonmail.com>
 <20200518124518.GA11560@SDF.ORG>
 <11orlTaAGSzMt8IONG4qa4f3Q2MbqyNagVIwTfDaWAR0LS0ZtIULvINhthshsibD-196zJ-Ay2CUc6kKQiD8MuCybW8_4VIeqrxdJoLznUI=@protonmail.com>
Message-ID: <87blml595w.fsf@dorothy.carcosa.net>

defdefred <defdefred at protonmail.com> writes:

> With TLS, only the transport layer is "secure", but you don't know if
> someone hack the server and the files! It is not End-to-End encrypted
> between the writer and the reader.

You're missing the point that Gemini is a client-server protocol. The
two ends are the client and the server; it's not like email or chat
where the two ends are clients with a server in between.

TLS is *not* broken ? arguably, the CA system is broken, and it's very
broken if your employer or government can force you to accept them as a
CA, which is where TLS interception comes in. But Gemini does not rely
on the CA system.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From benulo at systemli.org  Mon May 18 20:44:01 2020
From: benulo at systemli.org (Ben)
Date: Tue, 19 May 2020 00:14:01 +0430
Subject: Example Gemini pages?
In-Reply-To: <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
 <20200518184618.GG3866@SDF.ORG>
 <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
Message-ID: <e4dd70a0-0fdf-61a1-fe96-0e77da34a24b@systemli.org>

Isn't document text all treated as "pre-formatted" anyway?

-- 
gemini://kwiecien.us/


From colecmac at protonmail.com  Mon May 18 20:48:47 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 18 May 2020 19:48:47 +0000
Subject: Example Gemini pages?
In-Reply-To: <e4dd70a0-0fdf-61a1-fe96-0e77da34a24b@systemli.org>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
 <20200518184618.GG3866@SDF.ORG>
 <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
 <e4dd70a0-0fdf-61a1-fe96-0e77da34a24b@systemli.org>
Message-ID: <zeB3GXBmvbsNsdGQSs3tiAUluQBxn83FqGbtEgehXU0XZmXWaoiVmqhJ7JN_Xhv2dmvbulgzwKOhU9mxtxNG1ndvomAIPuyhpqQ8o7KuCZA=@protonmail.com>

No, clients are free to format it, wrap it, apply fonts and colours, etc.
If it was preformatted, then links wouldn't work, for example.
There's a difference between this:

=> gemini://gus.guru/ GUS

and this:

```
=> gemini://gus.guru/ GUS
```

In the second one, a client will not form a link, it will just show the raw text.
It should also show the text in a monospace font, whereas it might apply some
other font for the first example.

makeworld

??????? Original Message ???????
On Monday, May 18, 2020 3:44 PM, Ben <benulo at systemli.org> wrote:

> Isn't document text all treated as "pre-formatted" anyway?
>
> -----------------------------------------------------------
>
> gemini://kwiecien.us/



From tomasino at lavabit.com  Mon May 18 20:49:22 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 18 May 2020 19:49:22 +0000
Subject: SPOOFED: Re: Example Gemini pages?
In-Reply-To: <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
 <20200518184618.GG3866@SDF.ORG>
 <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
Message-ID: <ab0b7778-b027-6e24-9078-f153449db876@lavabit.com>

On 5/18/20 6:59 PM, colecmac at protonmail.com wrote:
> Paragraphs and text are written normally. They are wrapped, so one paragraph should be written on one line. This line is part of the same paragraph
> This line will not be added to the ones above, it will always be on a new line.

Did we do this part in the spec? I know we have the ``` for
preformatted, but I thought all other text was up to the client. If
someone wanted to write in an editor that hard-wraps to 80col, that text
would still reflow in clients that reflow.


From colecmac at protonmail.com  Mon May 18 20:53:10 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 18 May 2020 19:53:10 +0000
Subject: SPOOFED: Re: Example Gemini pages?
In-Reply-To: <ab0b7778-b027-6e24-9078-f153449db876@lavabit.com>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
 <20200518184618.GG3866@SDF.ORG>
 <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
 <ab0b7778-b027-6e24-9078-f153449db876@lavabit.com>
Message-ID: <brhIaIMgjR1M8S8rkNYV-SoLMAeQGzST8OE2qSqhAtptvpXLvxzr0CXO6sl3Dpo1h49GgIJafh2RmU5RxVY1MCytRLhxCuNx2u5zshPxeSE=@protonmail.com>

It is part of the spec, to my understanding.
Section 1.3.5.3.1 (jeez) states:

> Text lines which are longer than can fit on a client's display device
SHOULD be "wrapped" to fit, i.e. long lines should be split (ideally
at whitespace or at hyphens) into multiple consecutive lines of a
device-appropriate width.  This wrapping is applied to each line of
text independently.  Multiple consecutive lines which are shorter
than the client's display device MUST NOT be combined into fewer,
longer lines.

To me, this is in agreement with what I said before.


makeworld

From tomasino at lavabit.com  Mon May 18 20:58:26 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 18 May 2020 19:58:26 +0000
Subject: SPOOFED: Re: SPOOFED: Re: Example Gemini pages?
In-Reply-To: <brhIaIMgjR1M8S8rkNYV-SoLMAeQGzST8OE2qSqhAtptvpXLvxzr0CXO6sl3Dpo1h49GgIJafh2RmU5RxVY1MCytRLhxCuNx2u5zshPxeSE=@protonmail.com>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
 <20200518184618.GG3866@SDF.ORG>
 <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
 <ab0b7778-b027-6e24-9078-f153449db876@lavabit.com>
 <brhIaIMgjR1M8S8rkNYV-SoLMAeQGzST8OE2qSqhAtptvpXLvxzr0CXO6sl3Dpo1h49GgIJafh2RmU5RxVY1MCytRLhxCuNx2u5zshPxeSE=@protonmail.com>
Message-ID: <dde22462-3e86-4a0a-0897-c87af707cef7@lavabit.com>

On 5/18/20 7:53 PM, colecmac at protonmail.com wrote:
> To me, this is in agreement with what I said before.

I stand corrected! That's indeed what the spec says. Please witness as I
go change to soft-wrapping in my gmi files! ;D


From solderpunk at SDF.ORG  Mon May 18 21:35:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 20:35:44 +0000
Subject: Proposed minor spec changes, for comment.
Message-ID: <20200518203544.GA23608@SDF.ORG>

Ahoy!

The three month spec freeze announced, well, almost three months ago,
will be expiring soon.  Things to ponder/discuss have been piling
up.  So, I've been considering dealing with some of the "low hanging
fruit" early (I have some time off work later this week because of a
national holiday).  I'm thinking in particular of fairly minor
changes, where it is obvious that there is a problem in what's already
specced or important functionality is missing, and where there are
fairly obviously solutions.

To this end, I'm going to outline some proposals below for feedback.
I *hope* that these will be pretty uncontroversial.  Feedback is
welcome, as always, but we have to do *something* about these issues,
so if you really think what I propose below is a bad idea, a better
alternative would be a very good thing to bring to the discussion!

Here we go, then...

ISSUE 1:

Problem: The current spec does not impose any limit on request header
length.  The status code and META field can be separated by
arbitrarily many spaces and/or tabs.  Malicious or buggy servers can
hang or crash carelessly written clients by sending an infinite stream
of whitespace.  It's not clear *why* anybody would want to do this (a
"reverse DOS attack" is not very useful!), but it's clearly a problem
nevertheless.

Proposal: Redfine response headers from:

<STATUS><whitespace><META><CR><LF>

to:

<STATUS> <META><CR><LF>

i.e. exactly one space character between <STATUS> and <META>

Rationale: Allowing multiple whitespace characters of different kinds
makes sense in, e.g., the link syntax of text/gemini - that has to be
written and read by human content authors, so it's a good idea to
accommodate different editor behaviours and different personal
preferences for laying things out.  But response headers are written
and read by software, so there's no need to be so generous.
Specifying the header format more precisely actually just makes life
slightly easier for client authors.  As a result of this, the maximum
length of a response becomes finite (as the length of <STATUS> and
<META> are already well defined elsewhere).

Client authors who want to follow Postel's law won't need to make any
changes here.  I imagine many server authors also won't actually need
to.  The most probable scenario is no change needed (the server already
sends one space) or a single s/\t/ / is neeed.

ISSUE 2:

Problem: The spec makes a big fuss about how text/gemini is
line-oriented, but does not clearly state what exactly constitutes a
line.  The definition of link lines includes a <CR><LF> at the end but
it's not clear if that applies to all line types - or whether I even
meant to do this or it was a careless error.

Proposal: Actually, it turns out this is decided for us.  RFC2046,
which defines the text/* MIME media type and the text/plain subtype
covers this very clearly:

---
4.1.1.  Representation of Line Breaks

   The canonical form of any MIME "text" subtype MUST always represent a
   line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
   MIME "text" MUST represent a line break.  Use of CR and LF outside of
   line break sequences is also forbidden.

   This rule applies regardless of format or character set or sets
   involved.
---

Since text/gemini is, well, text/gemini, it is a "text" subtype and
using anything other than CRLF means we're violating the RFCs we're
supposedly building on top of.

So, CRLF everywhere it is.

I propose it be mostly the server's job to handle this.  Text editors
on different operating systems used by content authors will use
various different line break encodings which are beyond our control,
so we can't really make it the author's job.  Servers can translate LF
to CRLF before sending content over the network.  This way clients
only need to handle the "canonical" format, no matter what authors do.

Rationale: Don't break foundational RFCs.

Yeah, I know, this is tedious and no fun for server authors, but, well,
see above.

ISSUE 3:

Problem: There's no way to specify the (human) language a text/gemini document
is written in.

Proposal: Define a new parameter for the text/gemini MIME type
(alongside the previously defined `charset`) to specify language.
Following the example set by HTML, it seems natural to call the
parameter `lang` and to allow values as per RFC1766, e.g.:

text/gemini; charset=utf-8; lang=en
text/gemini; charset=utf-8; lang=en-US
text/gemini; charset=utf-8; lang=en-GB
text/gemini; charset=utf-8; lang=es
text/gemini; charset=utf-8; lang=fr

Rationale: A protocol for a global network which targets human beings
reading textual content as its first-class application shouldn't be
Anglocentric!  Gemini already has:

* A Spanish-only server at gemini://gagarin.p4g.club
* An auditory browser which is/will be language aware
* A search engine which will eventually become more difficult to use
  without the ability to limit searches to target languages.

This looks a bit scary at first from an extensibility point of view,
because it does kind of open the door to defining all sorts of
additional parameters.  However, the pre-exisiting MIME RFCs we're
leveraging here make it pretty clear that (i) these things aren't
open-ended, each MIME type and subtype has a fixed and finite set of
defined parameters, and (ii) that only certain kinds of semantic
information are really appropriate here.  So this is about as safe as
extensibility gets.

ISSUE 4:

Problem: Name-based virtual hosting is explicitly described as being
supported in the spec, but no mention is made of SNI (Server Name
Indication, a TLS extension which puts the desired server hostname in
the TLS handshake).  Without this, virtual hosting can't be made to
work reliably.

Proposal: Mandate use of SNI by clients.

Rationale: Earlier I proposed speccing that clients SHOULD use SNI but
requiring that servers be robust against its absence, by assigning a
default hostname.  Upon more thought, this won't work.  I was thinking
about how a missing Host: header was handled in this situation in
HTTP, where a default host works just fine.  But with TLS involved,
this is a problem: if the default host is not the one the client has
actually requested, the default certificate's Common Name and Subject
Alternative Names won't match what the client expects and the
certificiate will be rejected.  So, I think we just have to require
SNI.

If you're a client developer, please check whether or not the TLS
library you are using supports SNI!  If not, let me know.  I imagine
in this day and age they all will, so this won't be a burdensome
requirement.

That's it!

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Mon May 18 21:40:45 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 20:40:45 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518203544.GA23608@SDF.ORG>
References: <20200518203544.GA23608@SDF.ORG>
Message-ID: <20200518204045.GB23608@SDF.ORG>

On Mon, May 18, 2020 at 08:35:44PM +0000, solderpunk wrote:

Whoops, small mistake:

> ISSUE 1:
> 
> Problem: The current spec does not impose any limit on request header
> length.

This should say "response header", not "request header".

Cheers,
Solderpunk

From colecmac at protonmail.com  Mon May 18 21:48:51 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 18 May 2020 20:48:51 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518203544.GA23608@SDF.ORG>
References: <20200518203544.GA23608@SDF.ORG>
Message-ID: <BTZiUyTJPc7uZ-GpSJjpzn3iyZeE4_ZlXAFhS-MwLudfcqAGJeOMo4InXGD1p11QvdWMCgTj_XteH_zXn1L2kF9WJLKxZQT9GTf6zHD8490=@protonmail.com>

These are good additions, thanks.

I take issue with, maybe predictably, number 2. I didn't realize
that RFC existed, and I was surprised to read it. Are there any
other formats that actually follow this? Take markdown for
example, plenty of people write markdown with only a \n at the
end of each line, and it doesn't affect anything. In fact, in the
markdown spec, it explicitly says just \n is fine:
https://spec.commonmark.org/0.29/#line-ending

I don't see the point in following the RFC in this case, I think
it adds needless complication to the spec. Obviously it's not
such a big change to server software, but I don't think there's a
good reason to add it.

> Rationale: Don't break foundational RFCs.

It would be hard to argue with this, except that there seems to be
a precedent of not caring about this specific part of this RFC.
I think Gemini would be less surprising and more simple, if it
disregarded this like most other specs seem to do.

I'm in favor of defining a line ending as \r\n OR \n.

Thoughts?

makeworld

From sean at conman.org  Mon May 18 22:03:41 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 18 May 2020 17:03:41 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518203544.GA23608@SDF.ORG>
References: <20200518203544.GA23608@SDF.ORG>
Message-ID: <20200518210340.GD30203@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> ISSUE 3:
> 
> Problem: There's no way to specify the (human) language a text/gemini document
> is written in.
> 
> Proposal: Define a new parameter for the text/gemini MIME type
> (alongside the previously defined `charset`) to specify language.
> Following the example set by HTML, it seems natural to call the
> parameter `lang` and to allow values as per RFC1766, e.g.:
> 
> text/gemini; charset=utf-8; lang=en
> text/gemini; charset=utf-8; lang=en-US
> text/gemini; charset=utf-8; lang=en-GB
> text/gemini; charset=utf-8; lang=es
> text/gemini; charset=utf-8; lang=fr

  What's a client to do if 'lang=' isn't there?  Assume English?  Assume
nothing?

  -spc

From solderpunk at SDF.ORG  Mon May 18 22:13:47 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 21:13:47 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518210340.GD30203@brevard.conman.org>
References: <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
Message-ID: <20200518211347.GC23608@SDF.ORG>

On Mon, May 18, 2020 at 05:03:41PM -0400, Sean Conner wrote:
 
>   What's a client to do if 'lang=' isn't there?  Assume English?  Assume
> nothing?

Good question.  Should clients which do something with this information
(like screenreaders) have a default language setting which users can
set?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Mon May 18 22:42:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 18 May 2020 21:42:15 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518210340.GD30203@brevard.conman.org>
References: <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
Message-ID: <20200518214215.GA12325@SDF.ORG>

On Mon, May 18, 2020 at 05:03:41PM -0400, Sean Conner wrote:
 
>   What's a client to do if 'lang=' isn't there?  Assume English?  Assume
> nothing?

Specifying English, or any other language, as a default value doesn't
seem right to me.

Realistically, the majority of clients will not do anything with this
information.  Those which *do* use it in some way will know best what
the most sensible behaviour is in the absence of explicit information.
So I propose that client behaviour in the absence of a specified
language is up to the client.

The search engine case seems the trickiest to me (compared to, say,
screen reading).  Statistical language recognition is a thing, but doing
it on every document in Geminispace is likely to be burdensome...

Cheers,
Solderpunk


From jan6 at tilde.ninja  Mon May 18 22:45:35 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Mon, 18 May 2020 21:45:35 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518211347.GC23608@SDF.ORG>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
Message-ID: <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>

On Mon, May 18, 2020 at 05:03:41PM -0400, Sean Conner wrote:
> What's a client to do if 'lang=' isn't there? Assume English? Assume nothing?

I'd think only the mimetype should be mandatory, and the rest will use defaults, when not
specified...
of course, spec shouldn't specify what the defaults are...

it could also attempt to auto-detect and prompt user if it matters (normal text browsers will
probably be indifferent, but audio browser could ask, and search engines could warn, which will
incentivize users to put a language anyway), but that's a client-specific extra...

I'm not sure I see the point in the encoding part, though...
practically everything can be converted to utf8 rather easily, making it a bit useless to
specify...

another interesting point, what specification is the lang= tag?
it should probably encouraged to use some special use codes too, taking ISO 639-2 as example
(standard specifying three-letter codes for languages):
mis, for "uncoded languages";
mul, for "multiple languages";
und, for "undetermined";
zxx, for "no linguistic content; not applicable";

where, AFAIK, "mis" would apply for languages not in the spec, probably stuff like Toki Pona
"mul" wouldn't be that useful on its own, but maybe when "mul" is specified and there are specified
multiple languages in addition, it could help?
"zxx" would apply for art, because if you happen to have an ascii art gallery or so, there's no
point in indexing it fully (you can just have a list of all the names on another page, to get them
listed), and no point in reading it aloud...

there's probably a somewhat similar part of whatever the spec is, or similar convention

From stryan at saintnet.tech  Mon May 18 22:51:45 2020
From: stryan at saintnet.tech (Steve Ryan)
Date: Mon, 18 May 2020 17:51:45 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518203544.GA23608@SDF.ORG>
References: <20200518203544.GA23608@SDF.ORG>
Message-ID: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>

On 20/05/18 08:35PM, solderpunk wrote:
> ISSUE 2:
> 
> Problem: The spec makes a big fuss about how text/gemini is
> line-oriented, but does not clearly state what exactly constitutes a
> line.  The definition of link lines includes a <CR><LF> at the end but
> it's not clear if that applies to all line types - or whether I even
> meant to do this or it was a careless error.
> 
> Proposal: Actually, it turns out this is decided for us.  RFC2046,
> which defines the text/* MIME media type and the text/plain subtype
> covers this very clearly:
> 
> ---
> 4.1.1.  Representation of Line Breaks
> 
>    The canonical form of any MIME "text" subtype MUST always represent a
>    line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
>    MIME "text" MUST represent a line break.  Use of CR and LF outside of
>    line break sequences is also forbidden.
> 
>    This rule applies regardless of format or character set or sets
>    involved.
> ---
> 
> Since text/gemini is, well, text/gemini, it is a "text" subtype and
> using anything other than CRLF means we're violating the RFCs we're
> supposedly building on top of.
> 
> So, CRLF everywhere it is.
> 
> I propose it be mostly the server's job to handle this.  Text editors
> on different operating systems used by content authors will use
> various different line break encodings which are beyond our control,
> so we can't really make it the author's job.  Servers can translate LF
> to CRLF before sending content over the network.  This way clients
> only need to handle the "canonical" format, no matter what authors do.
> 
> Rationale: Don't break foundational RFCs.
> 
> Yeah, I know, this is tedious and no fun for server authors, but, well,
> see above.

My only concern with this is the "server's job" part. I'd rather not
have my server transform user-supplied content, even if it's something
as minor as line breaks. Apache doesn't attempt to fix invalid HTML, why
should SecretShop fix invalid text/gemini? Seems to me this should be
handled by something like the gemini vim-syntax plugin.

It also makes writing servers a bit more complicated since text/gemini
has to be treated differently from other files and actually parsed
versus being directly served up. Not the biggest deal (and you've
already admited it's tedious) but just something I noticed.

> 
> ISSUE 4:
> 
> Problem: Name-based virtual hosting is explicitly described as being
> supported in the spec, but no mention is made of SNI (Server Name
> Indication, a TLS extension which puts the desired server hostname in
> the TLS handshake).  Without this, virtual hosting can't be made to
> work reliably.
> 
> Proposal: Mandate use of SNI by clients.
> 

SecretShop implements virtual-hosting with the assumption that clients
are using SNI, so I'm in favour.

-Steve

From jan6 at tilde.ninja  Mon May 18 23:00:56 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Mon, 18 May 2020 22:00:56 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
Message-ID: <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>

May 19, 2020 12:51 AM, "Steve Ryan" <stryan at saintnet.tech> wrote:
> My only concern with this is the "server's job" part. I'd rather not
> have my server transform user-supplied content, even if it's something
> as minor as line breaks. Apache doesn't attempt to fix invalid HTML, why
> should SecretShop fix invalid text/gemini? Seems to me this should be
> handled by something like the gemini vim-syntax plugin.
> 
> It also makes writing servers a bit more complicated since text/gemini
> has to be treated differently from other files and actually parsed
> versus being directly served up. Not the biggest deal (and you've
> already admited it's tedious) but just something I noticed.

well, teeeechnically it'd have to do this for all text/* files, according to the rfc, including
plaintext and whatnot... although THAT's unlikely to happen...

I'd also be in favor of server handling it, although that is a kinda-valid point...
html doesn't count because the browsers will do their best to fix all kinds of TOTALLY BROKEN html,
you can have partial tags, no end tags for some, etc, and the browser will never tell the user your
site is a trashpile, it will just silently try its best to fix it up (even in inspect element,
you'd see the "repaired" version)...

From benulo at systemli.org  Mon May 18 23:16:35 2020
From: benulo at systemli.org (Ben)
Date: Tue, 19 May 2020 02:46:35 +0430
Subject: Example Gemini pages?
In-Reply-To: <zeB3GXBmvbsNsdGQSs3tiAUluQBxn83FqGbtEgehXU0XZmXWaoiVmqhJ7JN_Xhv2dmvbulgzwKOhU9mxtxNG1ndvomAIPuyhpqQ8o7KuCZA=@protonmail.com>
References: <3B0EF999-091C-41BF-852E-B085DF72D508@sdf.org>
 <20200518184618.GG3866@SDF.ORG>
 <Rqf4NQgjuZsMG34B8Y3Y6bsUXPR6y8nbw3Z7Aszv72SZ_q762ZXoGbu0gDpXJ_D2jfZ_pFqvv66KF3okc3Bm1ZbyImuqlm-cjJ5Ziy_kLDo=@protonmail.com>
 <e4dd70a0-0fdf-61a1-fe96-0e77da34a24b@systemli.org>
 <zeB3GXBmvbsNsdGQSs3tiAUluQBxn83FqGbtEgehXU0XZmXWaoiVmqhJ7JN_Xhv2dmvbulgzwKOhU9mxtxNG1ndvomAIPuyhpqQ8o7KuCZA=@protonmail.com>
Message-ID: <2cf50fb8-dc3c-e71f-bc86-6b466b82a684@systemli.org>

Ah thanks! I should have known that. To be honest, I wrote my pages with 
the intention that a monospace font would always be in use. It does seem 
a common behavior for Gemini clients.

On 5/19/20 12:18 AM, colecmac at protonmail.com wrote:
> In the second one, a client will not form a link, it will just show the raw text.
> It should also show the text in a monospace font, whereas it might apply some
> other font for the first example.

-- 
gemini://kwiecien.us/


From epoch at enzo.thebackupbox.net  Mon May 18 23:37:15 2020
From: epoch at enzo.thebackupbox.net (epoch)
Date: Mon, 18 May 2020 17:37:15 -0500
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
Message-ID: <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>

On Mon, May 18, 2020 at 10:00:56PM +0000, jan6 at tilde.ninja wrote:
> May 19, 2020 12:51 AM, "Steve Ryan" <stryan at saintnet.tech> wrote:
> > My only concern with this is the "server's job" part. I'd rather not
> > have my server transform user-supplied content, even if it's something
> > as minor as line breaks. Apache doesn't attempt to fix invalid HTML, why
> > should SecretShop fix invalid text/gemini? Seems to me this should be
> > handled by something like the gemini vim-syntax plugin.
> > 
> > It also makes writing servers a bit more complicated since text/gemini
> > has to be treated differently from other files and actually parsed
> > versus being directly served up. Not the biggest deal (and you've
> > already admited it's tedious) but just something I noticed.
> 
> well, teeeechnically it'd have to do this for all text/* files, according to the rfc, including
> plaintext and whatnot... although THAT's unlikely to happen...
> 
> I'd also be in favor of server handling it, although that is a kinda-valid point...
> html doesn't count because the browsers will do their best to fix all kinds of TOTALLY BROKEN html,
> you can have partial tags, no end tags for some, etc, and the browser will never tell the user your
> site is a trashpile, it will just silently try its best to fix it up (even in inspect element,
> you'd see the "repaired" version)...

https://tools.ietf.org/html/rfc5147#section-4.1

"   In Internet messages, line endings in text/plain MIME entities are
   represented by CR+LF character sequences (see RFC 2046 [3] and RFC
   3676 [6]).  However, some protocols (such as HTTP) additionally allow
   other conventions for line endings."

precedent of protocols allowing for other line endings, so the gemini spec
could just say the same thing that http does about line endings.

https://tools.ietf.org/html/rfc2616#section-3.7.1

"   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when it is done consistently for an entire entity-body. HTTP
   applications MUST accept CRLF, bare CR, and bare LF as being
   representative of a line break in text media received via HTTP."

From martin at no.ucant.org  Mon May 18 23:55:17 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Mon, 18 May 2020 23:55:17 +0100 (BST)
Subject: [ANN] another Gemini server, blizanci
Message-ID: <alpine.DEB.2.20.2005182343190.18317@pling.qwghlm.org>


Hello,

I've made a trivial Gemini server in Erlang, available on github at:

     https://github.com/mk270/blizanci

It's pre-alpha quality at the moment, but it was very useful for getting 
my head round how the protocol works.

I've also set up a server at:

     gemini://gemini.ucant.org/

which has got a small amount of original content on it unconnected with 
discussions of Gemini itself.

Thank you to everyone who has given up their time to get Gemini off the 
ground. I hope Gemini prospers.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From colecmac at protonmail.com  Tue May 19 00:03:47 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 18 May 2020 23:03:47 +0000
Subject: [ANN] another Gemini server, blizanci
In-Reply-To: <alpine.DEB.2.20.2005182343190.18317@pling.qwghlm.org>
References: <alpine.DEB.2.20.2005182343190.18317@pling.qwghlm.org>
Message-ID: <YCjeNExdkh_dN9sPog2YSBhyPfbag0T1aWssYkVIEzUketdksmF1gPAvbGZfgKrIclhcxjVhpNSZlL4Ff7Li8DEHQ96o7ukpUngaTR8aTv0=@protonmail.com>

Happy to have you and your server!

> gemini://gemini.ucant.org/

This doesn't load for me however. Trying to load the domain gives
"No route to host", and pinging the IP address reveals:
"Packet filtered". I've confirmed with others on the gemini IRC
that it's not just me.

makeworld

??????? Original Message ???????
On Monday, May 18, 2020 6:55 PM, Martin Keegan <martin at no.ucant.org> wrote:

> Hello,
>
> I've made a trivial Gemini server in Erlang, available on github at:
>
> https://github.com/mk270/blizanci
>
> It's pre-alpha quality at the moment, but it was very useful for getting
> my head round how the protocol works.
>
> I've also set up a server at:
>
> gemini://gemini.ucant.org/
>
> which has got a small amount of original content on it unconnected with
> discussions of Gemini itself.
>
> Thank you to everyone who has given up their time to get Gemini off the
> ground. I hope Gemini prospers.
>
> Mk
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/



From martin at no.ucant.org  Tue May 19 00:09:46 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 19 May 2020 00:09:46 +0100 (BST)
Subject: [ANN] another Gemini server, blizanci
In-Reply-To: <YCjeNExdkh_dN9sPog2YSBhyPfbag0T1aWssYkVIEzUketdksmF1gPAvbGZfgKrIclhcxjVhpNSZlL4Ff7Li8DEHQ96o7ukpUngaTR8aTv0=@protonmail.com>
References: <alpine.DEB.2.20.2005182343190.18317@pling.qwghlm.org>
 <YCjeNExdkh_dN9sPog2YSBhyPfbag0T1aWssYkVIEzUketdksmF1gPAvbGZfgKrIclhcxjVhpNSZlL4Ff7Li8DEHQ96o7ukpUngaTR8aTv0=@protonmail.com>
Message-ID: <alpine.DEB.2.20.2005190009201.18317@pling.qwghlm.org>

On Mon, 18 May 2020, colecmac at protonmail.com wrote:

> Happy to have you and your server!
>
>> gemini://gemini.ucant.org/
>
> This doesn't load for me however. Trying to load the domain gives
> "No route to host", and pinging the IP address reveals:
> "Packet filtered". I've confirmed with others on the gemini IRC
> that it's not just me.

Sorry, butterfingers on the firewall. It's now fixed and should be 
world-accessible again.

Mk

From sean at conman.org  Tue May 19 01:07:53 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 18 May 2020 20:07:53 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
Message-ID: <20200519000753.GE30203@brevard.conman.org>

It was thus said that the Great jan6 at tilde.ninja once stated:
> On Mon, May 18, 2020 at 05:03:41PM -0400, Sean Conner wrote:
> > What's a client to do if 'lang=' isn't there? Assume English? Assume nothing?
> 
> I'd think only the mimetype should be mandatory, and the rest will use defaults, when not
> specified...
> of course, spec shouldn't specify what the defaults are...
> 
> it could also attempt to auto-detect and prompt user if it matters (normal text browsers will
> probably be indifferent, but audio browser could ask, and search engines could warn, which will
> incentivize users to put a language anyway), but that's a client-specific extra...

  I thought about autodetection---Unicode is defined in blocks, where each
alphabet becomes a defined block in Unicode.  I then realized that there are
multiple languages that use the European block.  Sure, detecting Greek is
easy since they have their own alphabet, but what about Spanish, French and
German?  They use the same alphabet.

  Nice idea, but there are some tough issues to address.

> I'm not sure I see the point in the encoding part, though...
> practically everything can be converted to utf8 rather easily, making it a bit useless to
> specify...

  Think legacy documents.  And not every legacy encoding scheme can round
trip through Unicode---I recall there being issues with several east Asian
languages (Chinese, Japanese in particular).

> another interesting point, what specification is the lang= tag?

  Solderpunk mentioned RFC-1766, which uses the two letter standard for
languages.

> it should probably encouraged to use some special use codes too, taking ISO 639-2 as example
> (standard specifying three-letter codes for languages):
> mis, for "uncoded languages";
> mul, for "multiple languages";
> und, for "undetermined";
> zxx, for "no linguistic content; not applicable";

  I buy that.

  -spc

From elkaod at gmail.com  Tue May 19 02:04:25 2020
From: elkaod at gmail.com (kaoD)
Date: Tue, 19 May 2020 03:04:25 +0200
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518203544.GA23608@SDF.ORG>
References: <20200518203544.GA23608@SDF.ORG>
Message-ID: <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>

Glad to hear about SNI being in the radar. It's a must for virtual hosting.

Any thoughts about SNI interaction with the current "host in request URL is
like Host header" in the spec? Since SNI does the virtual hosting part (and
better) it would only be useful for proxying other hosts AFAICT.

Is proxying allowed currently in any server? Is it even desirable in the
protocol? Or is it just an idea that ossified in the spec without real
world use? (Genuine questions! I don't see the use but in sure it's been
discussed and I'm just late to the party.)

Most servers (all I've tried, circumlunar.space included) fail to handle
host-less requests (out of spec) and deny proxying other hosts.

And I'm pretty sure clients are adapting to this behavior. I'm afraid this
will end up being the de facto standard even with SNI making it obsolete.

Cheers,
kaoD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/0a7d3715/attachment.htm>

From sean at conman.org  Tue May 19 03:21:38 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 18 May 2020 22:21:38 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
References: <20200518203544.GA23608@SDF.ORG>
 <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
Message-ID: <20200519022138.GF30203@brevard.conman.org>

It was thus said that the Great kaoD once stated:
> Glad to hear about SNI being in the radar. It's a must for virtual hosting.

  Yup.  At least two servers that I am aware of implement it, GLV-1.12556 (I
wrote this one) and gemserv.

> Any thoughts about SNI interaction with the current "host in request URL is
> like Host header" in the spec? 

  It's how GLV-1.12556 determines what set of content handlers to look
through when serving up a request.  The public server I have doesn't serve
multiple hosts, but the code running it can.

> Since SNI does the virtual hosting part (and
> better) it would only be useful for proxying other hosts AFAICT.
> 
> Is proxying allowed currently in any server? 

  I saw something about gemserv supporting proxying, but I don't know the
details of how it works.

  As for proxy support in GLV-1.12556 (the only server I can speak
authoritatively about), it would be easy to write a handler to support a
proxy like:

	gemini://gemini.conman.org/proxy/mozz.us/journal/2020-05-06.gmi

  But if by "proxy" you mean you connect to gemini.conman.org and expect the
request itself to be proxied:

		gemini://mozz.us/journal/2020-05-06.gmi

that ... could be done, but it would require two things---1) your client
would have to know to use the gemini.conman.org certificate to connect to my
server and 2) my server would have to know to proxy this domain (and
supporting that type of proxy in GLV-1.12556 would require some
thought---the server isn't set up for that type of thing [1]).

> Is it even desirable in the
> protocol? Or is it just an idea that ossified in the spec without real
> world use? (Genuine questions! I don't see the use but in sure it's been
> discussed and I'm just late to the party.)

  When the suggestion to use the URL as the request (which would give us
multidomain support with a server), solderpunk also saw a proxy being easy
to implement without thinking about the implications.  

> Most servers (all I've tried, circumlunar.space included) fail to handle
> host-less requests (out of spec) and deny proxying other hosts.
> 
> And I'm pretty sure clients are adapting to this behavior. I'm afraid this
> will end up being the de facto standard even with SNI making it obsolete.

  Huh?  I don't understand the concern here.

  -spc
[1]	Nor does it support multiple domains with a single certificate/key
	pair.  Right now, each server requires its own certificate/key file.

From sean at conman.org  Tue May 19 03:28:10 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 18 May 2020 22:28:10 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519022138.GF30203@brevard.conman.org>
References: <20200518203544.GA23608@SDF.ORG>
 <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
 <20200519022138.GF30203@brevard.conman.org>
Message-ID: <20200519022810.GG30203@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:

>   But if by "proxy" you mean you connect to gemini.conman.org and expect the
> request itself to be proxied:
> 
> 		gemini://mozz.us/journal/2020-05-06.gmi
> 
> that ... could be done, but it would require two things---1) your client
> would have to know to use the gemini.conman.org certificate to connect to my
> server and 2) my server would have to know to proxy this domain (and
> supporting that type of proxy in GLV-1.12556 would require some
> thought---the server isn't set up for that type of thing [1]).

  I just thought of a way it could be done---I could have a copy of the
certificate/key pair for the domain I'm proxying for.  Then it would be easy
to write a handler to forward the request to the original domain and return
the contents.

  -spc

> [1]	Nor does it support multiple domains with a single certificate/key
> 	pair.  Right now, each server requires its own certificate/key file.

From int at 80h.dev  Tue May 19 03:41:19 2020
From: int at 80h.dev (int 80h)
Date: Mon, 18 May 2020 22:41:19 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519000753.GE30203@brevard.conman.org>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
Message-ID: <CAF42uF7_Pwu1Kn_94AT4s+tWTAkjwtijUNDqW22CL_ty2Ct-Dg@mail.gmail.com>

I was also wondering about how autodetection would work. Instead of
autodetection how about having the language be on the first line in a
file and have the server parse that for the information? Sorry if that
was already discussed.

int 80

From int at 80h.dev  Tue May 19 03:46:19 2020
From: int at 80h.dev (int 80h)
Date: Mon, 18 May 2020 22:46:19 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
References: <20200518203544.GA23608@SDF.ORG>
 <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
Message-ID: <CAF42uF6h=PurBLP6Szphugb=_vRZWfoNdyfAvxV4iJcbzGtbkw@mail.gmail.com>

On Mon, May 18, 2020 at 9:04 PM kaoD <elkaod at gmail.com> wrote:
> Is proxying allowed currently in any server? Is it even desirable in the protocol? Or is it just an idea that ossified in the spec without real world use? (Genuine questions! I don't see the use but in sure it's been discussed and I'm just late to the party.)

Gemserv has reverse proxy support. That's what's being used to proxy
gemini to gopher on my site.

int 80h

From colecmac at protonmail.com  Tue May 19 03:53:18 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 19 May 2020 02:53:18 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519022138.GF30203@brevard.conman.org>
References: <20200518203544.GA23608@SDF.ORG>
 <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
 <20200519022138.GF30203@brevard.conman.org>
Message-ID: <sx1IYpL5Li-IFjs_wfajAuYvgiZf4-JvqqPRntqBskYfe4VyHdMe3j9KSQiGtwgRX4X0rA4ZxyryeYhs4kIegfdtAOX8b_FssXGfYlIrqsw=@protonmail.com>

> > Glad to hear about SNI being in the radar. It's a must for virtual hosting.

>   Yup.  At least two servers that I am aware of implement it, GLV-1.12556 (I
wrote this one) and gemserv.

Jetforce does as well, I'm not sure about others.

makeworld


From colecmac at protonmail.com  Tue May 19 04:03:22 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 19 May 2020 03:03:22 +0000
Subject: [ANN] md2gemini release v1.1.0 and gemini linking discussion
Message-ID: <G_6Y_888Je1yAW1RQ7vz_BKPVgFb2Pppos73Bcx2wqahpjwxFd8lSI6dT7kRuKVMUyMR71f_fNVWwVlHf2LeVtK6gsJvXcbj9SyxVTphVwM=@protonmail.com>

Hello Geminauts,

I've just released v1.1.0 of md2gemini[1], I hope you're all proud. ;)

I'm not just emailing to plug my project though. This new release adds
support for footnotes as an alternative way to handle inline links,
which markdown supports but text/gemini doesn't. You can see an example
of how these footnotes look in my email here. md2gemini will automatically
create footnotes for all your inline links in markdown, if you enable it.

md2gemini actually offers several linking options: breaking up the paragraph
to directly link, removing all links, footnotes at the end of each
paragraph, or footnotes at the end of the document - like my email.

There was some discussion in another thread about having inline links
in text/gemini, which solderpunk rejected because it would make
parsing much more difficult. I agree with him, and so I wonder what
others on this list think of my take on this. Does using footnotes make
sense? Are there better, or just different ways to do solve this problem?


1: https://github.com/makeworld-the-better-one/md2gemini

makeworld

From nicole at strega-nil.co  Tue May 19 05:13:38 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Tue, 19 May 2020 04:13:38 +0000
Subject: Announcing garnet, a new (soon-to-be) TUI client
Message-ID: <c9v5dJo8xQe9NUUY0IMaSJ-3YwPGGAhl6ELow4jA8Mol4SbpQyEGAQ3qQKPG43ve7jVdnwnaZXyeP7pPFLX3FAAHacfSN9vpKZQSNv3Eeu0=@strega-nil.co>

Hey all!
I've just recently started looking into Gemini, and I decided to try and write my own little client. ? I love what other people have done, but something I've noticed is that a lot of existing clients don't support Windows, so I thought I'd work on my own. ?
Additionally, I kinda wanted to play with Rust and localization technologies, so that's on full display here as well. ?
Here's the github page! https://github.com/strega-nil/garnet
I warn you that it is... not feature complete at all. Currently, all it does is request gemini pages and print the resulting response out directly.

Thanks for checking it out y'all!
Nicole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/cf803c50/attachment.htm>

From zoey at dos.cafe  Tue May 19 05:42:15 2020
From: zoey at dos.cafe (Zoey Riordan)
Date: Tue, 19 May 2020 04:42:15 +0000
Subject: vostok: my protocol-agnostic framework,
 with (very basic) gemini support
Message-ID: <9ubMHnqYsJnRb8beq_cUw7dzNqDQ6GHjJDhVzVTbkGsHHx4XZYIbJObbUkJtz5hzddIrHT2v1xFraNXTOFeTN1HxuQXNURRmzGZ8ctbZCaY=@dos.cafe>

Hey ??

Hopefully this didn't send twice, I messed up my subscription the first time and couldn't send ??. I've been working on a new protocol-agnostic framework. And as a test I added (very basic) gemini support! Its written in rust and inspired by the rocket.rs framework. Feel free to check it out at https://github.com/ZoeyR/vostok

Right now all it can do is respond with text/plain content, but it shouldn't be too hard for me to add a lot more. I hope you find it interesting!

Zoey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/7244e649/attachment.htm>

From benulo at systemli.org  Tue May 19 06:11:26 2020
From: benulo at systemli.org (Ben)
Date: Tue, 19 May 2020 09:41:26 +0430
Subject: [ANN] md2gemini release v1.1.0 and gemini linking discussion
In-Reply-To: <G_6Y_888Je1yAW1RQ7vz_BKPVgFb2Pppos73Bcx2wqahpjwxFd8lSI6dT7kRuKVMUyMR71f_fNVWwVlHf2LeVtK6gsJvXcbj9SyxVTphVwM=@protonmail.com>
References: <G_6Y_888Je1yAW1RQ7vz_BKPVgFb2Pppos73Bcx2wqahpjwxFd8lSI6dT7kRuKVMUyMR71f_fNVWwVlHf2LeVtK6gsJvXcbj9SyxVTphVwM=@protonmail.com>
Message-ID: <d9dd6f88-3ed8-872b-c953-56ae97fa0088@systemli.org>

For my part, I already started putting the "at-end" option to work 
(links at the end of the document). The result is working for me 
beautifully.

On 5/19/20 7:33 AM, colecmac at protonmail.com wrote:
> Does using footnotes make sense? Are there better, or just different ways to do solve this problem?

-- 
gemini://kwiecien.us/


From defdefred at protonmail.com  Tue May 19 08:13:12 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 07:13:12 +0000
Subject: About client rendering...
In-Reply-To: <7a880d06-b04c-d1b8-357b-405187914187@masterq32.de>
References: <Oa7P4eHvj37ZcDBMRQL0Ow2RwI0q4uUEmMQBi_Hg7XZtAIaC_dMQHiyjp-2LS6WWa_J189zi1wkrBMI39_mE3HNvUNUzuB12X4bOC7WL9bk=@protonmail.com>
 <7a880d06-b04c-d1b8-357b-405187914187@masterq32.de>
Message-ID: <Zk-C_VgQEEfyqGQg1I4XFiKR4b989ARaikcimmsyFDK0NWteE-tQtsHa5ik57yaPSsY6rH9zkzHg2tiJB-QASBKsc4VUUMlN7cYqpwtZjZA=@protonmail.com>

On Monday 18 May 2020 18:32, Felix Quei?ner <felix at masterq32.de> wrote:
> I don't think we should specify how clients should display the data. We
> gain much from having variety in clients, their kind of displaying and
> everything. I for example use 1080p monitor with usually a two-column
> layout[0].
Agree.
it is only ideas about auto-layout :-)


From solderpunk at SDF.ORG  Tue May 19 08:14:46 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 07:14:46 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
Message-ID: <20200519071446.GA4068@SDF.ORG>

On Mon, May 18, 2020 at 09:45:35PM +0000, jan6 at tilde.ninja wrote:
 
> I'm not sure I see the point in the encoding part, though...
> practically everything can be converted to utf8 rather easily, making it a bit useless to
> specify...

That's been in the spec since early days, the only proposed change here
is the language part.  The charset parameter is explicitly optional and
the default in its absence is UTF-8, which clients MUST support.
Support for additional encodings in clients is optional, but they should
fail gracefully in the face of things they can't handle.

I expect 90%+ of content to be UTF-8 and for servers not to bother
specifying this as it's the explicit default, but it seemed unwise to be
completely incapable of handing anything else.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 19 08:20:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 07:20:16 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519000753.GE30203@brevard.conman.org>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
Message-ID: <20200519072016.GB4068@SDF.ORG>

On Mon, May 18, 2020 at 08:07:53PM -0400, Sean Conner wrote:

> Sure, detecting Greek is
> easy since they have their own alphabet, but what about Spanish, French and
> German?  They use the same alphabet.

I don't think it's viable for interactive user clients (especially light
and simple ones) to attempt this, but in the context of, say, a search
engine which really wants to categorise everything (which is not to say
that GUS necessarily has to shoulder this burden!), even distinguishing
languages with the same alphabet is possible by looking at bigram and
trigram frequencies if there's enough text.  German text will have many
more occurences of "lich" and "heit" than French or Spanish, etc.
 
>   Nice idea, but there are some tough issues to address.

Yeah, this language proposal may have been poorly categorised as "quick
and easy" compared to the others.

Cheers,
Solderpunk

From plugd at thelambdalab.xyz  Tue May 19 08:29:48 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Tue, 19 May 2020 09:29:48 +0200
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519000753.GE30203@brevard.conman.org>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
Message-ID: <lz5zcstmab.fsf@bs-mbpr348.d.ethz.ch>


Sean Conner writes:
>   I thought about autodetection---Unicode is defined in blocks, where each

Please, _please_ don't require autodetection of lanugage or anything
else.  Gopher required autodetection of charsets and content type, which
was horrible.  One of the best things about the current protocol is that
it makes these things explicit.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/f850a214/attachment.sig>

From solderpunk at SDF.ORG  Tue May 19 08:30:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 07:30:29 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
References: <20200518203544.GA23608@SDF.ORG>
 <CADG3GQ05RVj-8TNSUxffQqHDUoA7GMa7YdRPZ-MJe3c750gHNg@mail.gmail.com>
Message-ID: <20200519073029.GC4068@SDF.ORG>

On Tue, May 19, 2020 at 03:04:25AM +0200, kaoD wrote:

> Is proxying allowed currently in any server? Is it even desirable in the
> protocol? Or is it just an idea that ossified in the spec without real
> world use? (Genuine questions! I don't see the use but in sure it's been
> discussed and I'm just late to the party.)

I used the proxying capabilities of Gemini to write a Gopher-to-Gemini
proxy named Agena:

https://tildegit.org/solderpunk/agena

It is basically a Gemini server, which when it receives requests for
gopher:// URLs, downloads the content from Gopher, and, in the case of
Gopher menus, converts them to text/gemini menus and replies with that,
and in the case of anything else does MIME type and (for text/*) charset
detection, and replies with that with the appropriate header.

AV-98 lets you specify the host and port of such a proxy and if you try
to follow a link into Gopherspace, it routes it through proxy.

This makes it possible to seamlessly surf Geminispace and Gopherspace
from within the same client with a consistent interface without
requiring client authors to go through the trouble of adding support for
both protocols.

I think this is a super neat idea, but as far as I know AV-98 is the
only client which supports it and, since I wrote Agena, multiple other
clients have actually gained native Gemini and Gopher support (like
Bombadillo and Castor), so I guess the incentive is reduced (which is a
shame, because there are at least two public Agena proxies running, as
far as I know, one of which only went up very recently).

But I think it demonstrates that the proxying idea does have really
interesting and useful applications.

If you wanted to surf Geminispace from work during your lunch break but
your employer's firewall disallows outgoing traffic on port 1965, you
could setup a proxying Geminiserver on a server you control which
listens on a port other than 1965 and restrict access to it by requiring
a client certificate which is on a whitelist, and whitelist only your
work machine(s), to work around this.

I'm sure other examples exist, too.

Cheers,
Solderpunk

From defdefred at protonmail.com  Tue May 19 08:35:59 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 07:35:59 +0000
Subject: About client rendering...
In-Reply-To: <20200518163808.GF3866@SDF.ORG>
References: <Oa7P4eHvj37ZcDBMRQL0Ow2RwI0q4uUEmMQBi_Hg7XZtAIaC_dMQHiyjp-2LS6WWa_J189zi1wkrBMI39_mE3HNvUNUzuB12X4bOC7WL9bk=@protonmail.com>
 <7a880d06-b04c-d1b8-357b-405187914187@masterq32.de>
 <20200518163808.GF3866@SDF.ORG>
Message-ID: <jFrRAxggvwz8l9qqTch7i0iwpZHUPAqRQMpn4Y0IujsXKLuynM-Rw9avZrFc8YNLs5SKb8YMqEU5hq-d_EaFn5bC14yk_HYuLEaddPlVSlE=@protonmail.com>

On Monday 18 May 2020 18:38, solderpunk <solderpunk at SDF.ORG> wrote:
> If it was a suggestion that we put something like this into the spec,
> them I'm opposed and it's not happening. Clients can do what they like.

Agree.

Suggestions are useful for Backend/Frontend Synergies.


From solderpunk at SDF.ORG  Tue May 19 08:46:25 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 07:46:25 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
Message-ID: <20200519074625.GD4068@SDF.ORG>

On Mon, May 18, 2020 at 05:37:15PM -0500, epoch wrote:
 
> https://tools.ietf.org/html/rfc5147#section-4.1
> 
> "   In Internet messages, line endings in text/plain MIME entities are
>    represented by CR+LF character sequences (see RFC 2046 [3] and RFC
>    3676 [6]).  However, some protocols (such as HTTP) additionally allow
>    other conventions for line endings."
> 
> precedent of protocols allowing for other line endings, so the gemini spec
> could just say the same thing that http does about line endings.
> 
> https://tools.ietf.org/html/rfc2616#section-3.7.1
> 
> "   When in canonical form, media subtypes of the "text" type use CRLF as
>    the text line break. HTTP relaxes this requirement and allows the
>    transport of text media with plain CR or LF alone representing a line
>    break when it is done consistently for an entire entity-body. HTTP
>    applications MUST accept CRLF, bare CR, and bare LF as being
>    representative of a line break in text media received via HTTP."

Aaah, wonderful!  Thanks for bringing this to my attention.

I *had* been wondering whether or not mainstream webservers were doing
newline translation for text/html, which I had convinced myself they
should have been doing, in principle.

Okay, so we can actually spec whatever we like here for stuff that goes
over the wire. CRLF is only mandatory for "canonical form" (although if
that's not what is on the disk and not what is on the wire, what the
heck *is* it?).

So now the question is which do we prefer, forcing servers to
canonicalise (canonise?) everything, with client behaviour then being
strictly limited, or letting servers just send whatever the author uses
and forcing clients to accept any of CRLF, CR or LF?

In general I have preferred pushing burden to server authors over client
authors for Gemini...but I expect the client burden is pretty small here
as most languages will have some kind of functionality for breaking
strings into lines which already handles this...

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Tue May 19 08:54:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 07:54:37 +0000
Subject: vostok: my protocol-agnostic framework, with (very basic) gemini
 support
In-Reply-To: <9ubMHnqYsJnRb8beq_cUw7dzNqDQ6GHjJDhVzVTbkGsHHx4XZYIbJObbUkJtz5hzddIrHT2v1xFraNXTOFeTN1HxuQXNURRmzGZ8ctbZCaY=@dos.cafe>
References: <9ubMHnqYsJnRb8beq_cUw7dzNqDQ6GHjJDhVzVTbkGsHHx4XZYIbJObbUkJtz5hzddIrHT2v1xFraNXTOFeTN1HxuQXNURRmzGZ8ctbZCaY=@dos.cafe>
Message-ID: <20200519075437.GE4068@SDF.ORG>

On Tue, May 19, 2020 at 04:42:15AM +0000, Zoey Riordan wrote:
> Hey ??
 
> Hopefully this didn't send twice

Nope, just once!

With the arrival of Vostok alongside the in-development clients Soyuz
(gemini://gemini.circumlunar.space/users/dominikd/) and Voskhod (JMB, is
there a link for Voskhod yet?), we are just about out of names to borrow
from the classic era of Soviet manned spaceflight! :)  I guess Salyut is
left.

Cheers,
Solderpunk

From julien at typed-hole.org  Tue May 19 10:03:51 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Tue, 19 May 2020 11:03:51 +0200
Subject: Video examples
In-Reply-To: <r9r8mb$k1j$7@lc.orbitalfox.eu>
References: <r9r8mb$k1j$7@lc.orbitalfox.eu>
Message-ID: <3e55cb1a-57eb-75fa-9007-e3dc1bffff43@typed-hole.org>

On 17/05/2020 13:54, Micha? "phoe" Herda wrote:
> Are there any video examples of the Gemini protocol in action? Something
> that shows a person interacting with a Gemini browser and some content
> served via the protocol.
> 
> ~phoe
> 

I made this video showcasing gemnine (a Gemini browser for plan9/9front) 
yesterday 
https://toobnix.org/videos/watch/aed52d47-3c6c-413a-b84c-925990cd86aa.
It's not really representative of the general Gemini experience but it 
shows some Gemini places.

From defdefred at protonmail.com  Tue May 19 10:21:13 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 09:21:13 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519000753.GE30203@brevard.conman.org>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
Message-ID: <KQ938L_HQ7E0TGiP5YkbPGELmhcCtKgrwoHi9-g42jaFCRwrmVuiLd649Pzfws_I0JozXkiVeC90guUs6DpJ7XXgti-bDztPYgMwN4aqhq4=@protonmail.com>

On Tuesday 19 May 2020 02:07, Sean Conner <sean at conman.org> wrote:

> I thought about autodetection---Unicode is defined in blocks, where each
> alphabet becomes a defined block in Unicode. I then realized that there are
> multiple languages that use the European block. Sure, detecting Greek is
> easy since they have their own alphabet, but what about Spanish, French and
> German? They use the same alphabet.

Autodetection is necessary for document using multiple languages.
Browser preference is fine for hard to detect case.

> > I'm not sure I see the point in the encoding part, though...
> > practically everything can be converted to utf8 rather easily, making it a bit useless to
> > specify...
>
> Think legacy documents. And not every legacy encoding scheme can round
> trip through Unicode---I recall there being issues with several east Asian
> languages (Chinese, Japanese in particular).

UTF-8 is capable for all existing language and more :-).
Legacy document if not UTF-8 converted are just out of the gemeni browser scope.
Must gemini browser be able to display every kind of document ?

Regards,
freD.



From jan6 at tilde.ninja  Tue May 19 10:23:21 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Tue, 19 May 2020 09:23:21 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519074625.GD4068@SDF.ORG>
References: <20200519074625.GD4068@SDF.ORG>
 <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
Message-ID: <c15b3a25231d2c969dfc8e1cdf250f5c@tilde.ninja>

May 19, 2020 10:46 AM, "solderpunk" <solderpunk at sdf.org> wrote:
> So now the question is which do we prefer, forcing servers to
> canonicalise (canonise?) everything, with client behaviour then being
> strictly limited, or letting servers just send whatever the author uses
> and forcing clients to accept any of CRLF, CR or LF?
> 
> In general I have preferred pushing burden to server authors over client
> authors for Gemini...but I expect the client burden is pretty small here
> as most languages will have some kind of functionality for breaking
> strings into lines which already handles this...
> 
> Cheers,
> Solderpunk

well, if it's ONLY CRLF, then it enables making basic clients in *ANY* language, including pure assembly, if someone were brave enough (well, the core part, you'd probably write the TLS part in C or something, still)

maybe change the spec slightly, so, after the header, there's CRLF, immediately after which is an empty line with the line ending that applies for the rest of the document, and require at least one non-empty line after that?
that wouldn't matter for more advanced languages, which can just ignore that and use builtin functions, but for more basic ones, it makes it easy to read, "is it LF, else is it CR followed by LF, else assume CR"... while it would be possible to do that with normal content lines too, it'd be harder, as you can't just "eat" a byte or two from the start...

From defdefred at protonmail.com  Tue May 19 10:35:26 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 09:35:26 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519072016.GB4068@SDF.ORG>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
 <20200519072016.GB4068@SDF.ORG>
Message-ID: <AX2KlqzR9MwAPdsaFwqDn5tQNMmXTnuxZpy4pYuxyG63l7eRbY5NPz2ClEH8M4R1qz4ClbCfiGWBrIKS1DyS1OINB4UM4TnvIyeZ161TjNk=@protonmail.com>

On Tuesday 19 May 2020 09:20, solderpunk <solderpunk at SDF.ORG> wrote:
> I don't think it's viable for interactive user clients (especially light
> and simple ones) to attempt this, but in the context of, say, a search
> engine which really wants to categorise everything (which is not to say
> that GUS necessarily has to shoulder this burden!), even distinguishing
> languages with the same alphabet is possible by looking at bigram and
> trigram frequencies if there's enough text. German text will have many
> more occurences of "lich" and "heit" than French or Spanish, etc.
Agree and french have ???, spanish ?? and german ? :-)
Nice to have UTF-8 to display all of them in the same document...


From defdefred at protonmail.com  Tue May 19 10:39:50 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 09:39:50 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <lz5zcstmab.fsf@bs-mbpr348.d.ethz.ch>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
 <lz5zcstmab.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <PzzIb-EGPImPJrodUQM5MOFKEWZHWAyF0noU2tT2LkikCr3mWjAsq-JftohmGxyINAHvcrLgNI57ieJhzv9XtrTr9HxgDLXt17sN7Ubwuzc=@protonmail.com>

On Tuesday 19 May 2020 09:29, plugd <plugd at thelambdalab.xyz> wrote:
> Please,please don't require autodetection of lanugage or anything
> else. Gopher required autodetection of charsets and content type, which
> was horrible. One of the best things about the current protocol is that
> it makes these things explicit.

Having multiple charset is horrible :-)
UTF-8 will rule them all and converter will clean things up.
Historical document with ancien encoding should be displayed using external viewer.

From zoey at dos.cafe  Tue May 19 05:30:40 2020
From: zoey at dos.cafe (Zoey Riordan)
Date: Tue, 19 May 2020 04:30:40 +0000
Subject: vostok: my protocol-agnostic framework,
 with (very basic) gemini support
Message-ID: <DCJQCGNzEPovVdRhb8aI2-yIW44EMXpJDvBk79lv8edTNpX0C80ZTC0lQoSDGH7mZHv8AE47u7B1pQ8aOI2I7pH6pOdWEaVpTeAGMLk--2s=@dos.cafe>

Hey ??

I've been working on a new protocol-agnostic framework. And as a test I added (very basic) gemini support! Its written in rust and inspired by the rocket.rs framework. Feel free to check it out at https://github.com/ZoeyR/vostok

Right now all it can do is respond with text/plain content, but it shouldn't be too hard for me to add a lot more. I hope you find it interesting!

Zoey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/2bbf3726/attachment-0001.htm>

From defdefred at protonmail.com  Tue May 19 12:15:55 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 11:15:55 +0000
Subject: any Gemini to HTTP gateway?
Message-ID: <b1fdxvBCvR7WJN45pE8ltkpgp3mt8S68V-_wko8Ccb6jGYmgpeQoXSlazPUO5T2GLVvKsU-SHJ90PDOp0OWzAfXLEyQqHBNf2MnVC2T_DJw=@protonmail.com>

Hey!
Do you know any good gateway to read gemini  with a http browser?

Regards,
freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/24a9c739/attachment.htm>

From benulo at systemli.org  Tue May 19 12:37:55 2020
From: benulo at systemli.org (Ben)
Date: Tue, 19 May 2020 16:07:55 +0430
Subject: any Gemini to HTTP gateway?
In-Reply-To: <b1fdxvBCvR7WJN45pE8ltkpgp3mt8S68V-_wko8Ccb6jGYmgpeQoXSlazPUO5T2GLVvKsU-SHJ90PDOp0OWzAfXLEyQqHBNf2MnVC2T_DJw=@protonmail.com>
References: <b1fdxvBCvR7WJN45pE8ltkpgp3mt8S68V-_wko8Ccb6jGYmgpeQoXSlazPUO5T2GLVvKsU-SHJ90PDOp0OWzAfXLEyQqHBNf2MnVC2T_DJw=@protonmail.com>
Message-ID: <b9aeb3a6-8fba-0176-a104-3275aefc4134@systemli.org>

I know a couple listed on the Gemini project page:

https://portal.mozz.us/?url=gemini%3A%2F%2Fgemini.circumlunar.space%2F&fmt=fixed
https://proxy.vulpes.one/gemini/gemini.circumlunar.space

-- 
gemini://kwiecien.us/


From jmcbray at carcosa.net  Tue May 19 12:38:53 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 19 May 2020 07:38:53 -0400
Subject: [ANN] md2gemini release v1.1.0 and gemini linking discussion
In-Reply-To: <G_6Y_888Je1yAW1RQ7vz_BKPVgFb2Pppos73Bcx2wqahpjwxFd8lSI6dT7kRuKVMUyMR71f_fNVWwVlHf2LeVtK6gsJvXcbj9SyxVTphVwM=@protonmail.com>
 (colecmac@protonmail.com's message of "Tue, 19 May 2020 03:03:22 +0000")
References: <G_6Y_888Je1yAW1RQ7vz_BKPVgFb2Pppos73Bcx2wqahpjwxFd8lSI6dT7kRuKVMUyMR71f_fNVWwVlHf2LeVtK6gsJvXcbj9SyxVTphVwM=@protonmail.com>
Message-ID: <874ksc5f3m.fsf@dorothy.carcosa.net>

colecmac at protonmail.com writes:

> There was some discussion in another thread about having inline links
> in text/gemini, which solderpunk rejected because it would make
> parsing much more difficult. I agree with him, and so I wonder what
> others on this list think of my take on this. Does using footnotes make
> sense? Are there better, or just different ways to do solve this problem?

As a 'best practice', and not as a specification, I prefer using
footnotes after each paragraph. I'm glad to see your program supports
that option.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Tue May 19 12:45:14 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 19 May 2020 07:45:14 -0400
Subject: vostok: my protocol-agnostic framework,
 with (very basic) gemini support
In-Reply-To: <20200519075437.GE4068@SDF.ORG> (solderpunk@sdf.org's message of
 "Tue, 19 May 2020 07:54:37 +0000")
References: <9ubMHnqYsJnRb8beq_cUw7dzNqDQ6GHjJDhVzVTbkGsHHx4XZYIbJObbUkJtz5hzddIrHT2v1xFraNXTOFeTN1HxuQXNURRmzGZ8ctbZCaY=@dos.cafe>
 <20200519075437.GE4068@SDF.ORG>
Message-ID: <87zha4408l.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> On Tue, May 19, 2020 at 04:42:15AM +0000, Zoey Riordan wrote:
> With the arrival of Vostok alongside the in-development clients Soyuz
> (gemini://gemini.circumlunar.space/users/dominikd/) and Voskhod (JMB, is
> there a link for Voskhod yet?), we are just about out of names to borrow
> from the classic era of Soviet manned spaceflight! :)  I guess Salyut is
> left.

I realize there's not, and the code is only on the ThinkPad whose power
adapter let out the magic smoke, so there won't be until the replacement
power adapter arrives. It's kind of in limbo for now, because I need to
figure out how Gnome Builder interacts with PyGTK better.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From me at ecmelberk.com  Tue May 19 13:43:00 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Tue, 19 May 2020 15:43:00 +0300
Subject: [ANN] Moonlander: The fanciest Gemini client in the entire solar
 system
Message-ID: <20200519154300.64815d02@socimda>

Hey all!

I was working on this for the last weekend or so, and I believe it's
now ready enough to share.

Announcing: Moonlander[1], the fanciest graphical Gemini client in the
entire solar system [citation needed].

[1]: https://sr.ht/~admicos/moonlander

A screenshot: https://files.ecmelberk.com/img/1589891854.png

Please note that it's still under development, and there are a lot of
known bugs. Still, why not take it for a spin?


The rest of this mail will be an excerpt from the readme file:
----

## Features

- Custom, themeable rendering engine via Cairo & Pango
- Tries to follow Gnome HIG

### Known Bugs

- TLS Certificates aren't verified
- Somewhat high resource usage (for a Gemini client)
- No cross-protocol linking (yet)
- Cannot navigate backwards through redirections
- Renderer doesn't behave "native"
  - Cannot select/copy text
  - No interaction other than mouse clicks on links and scrolling

### Planned Features

- Tabs
- Render more than just text/gemini and plaintext.
  - Planned: Markdown & images

- Possibly support other protocols
  - Gopher, etc.
  - Definitely not HTTP, unless excluding HTML

- Syntax highlighting (?)
  - Waiting on text/gemini preformatting annotations to be somewhat
  standardized

From natpen at natpen.net  Tue May 19 15:19:25 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Tue, 19 May 2020 10:19:25 -0400
Subject: Extra GUS crawling this morning
Message-ID: <20200519141925.GC1613152@goldfish.localdomain>

Hi all,

Just FYI in case anyone is seeing the increased crawling traffic this
morning, GUS is getting some upgrades. And by upgrades I of course
mean it's now breaking in novel, unexpected ways. Fingers crossed it
should calm down soon! And once it does, GUS searches should be even
better (I noticed I wasn't handling relative links on pages well, so I
think the index has been missing a fair bit of content thus far).

Natalie

From defdefred at protonmail.com  Tue May 19 15:34:46 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 14:34:46 +0000
Subject: [ANN] Moonlander: The fanciest Gemini client in the entire solar
 system
In-Reply-To: <20200519154300.64815d02@socimda>
References: <20200519154300.64815d02@socimda>
Message-ID: <MGUkWLg93GVCBByALEPBoIOvVh-hxhy3lsg9H1QkiIfwivIU8HZ4u_mdM1HU6_hw7HVN11IdaPSI42qQ2MLjTjhyEq8xUXTr2JhsDEsH37Q=@protonmail.com>

On Tuesday 19 May 2020 14:43, Ecmel Berk Canl?er <me at ecmelberk.com> wrote:
> -   Render more than just text/gemini and plaintext.
>     -   Planned: Markdown & images
A Markdown Browser... what a nice idea!

From dunderpate at sdf.org  Tue May 19 16:09:14 2020
From: dunderpate at sdf.org (Dunderpate)
Date: Tue, 19 May 2020 10:09:14 -0500
Subject: Announcing garnet, a new (soon-to-be) TUI client
In-Reply-To: <c9v5dJo8xQe9NUUY0IMaSJ-3YwPGGAhl6ELow4jA8Mol4SbpQyEGAQ3qQKPG43ve7jVdnwnaZXyeP7pPFLX3FAAHacfSN9vpKZQSNv3Eeu0=@strega-nil.co>
References: <c9v5dJo8xQe9NUUY0IMaSJ-3YwPGGAhl6ELow4jA8Mol4SbpQyEGAQ3qQKPG43ve7jVdnwnaZXyeP7pPFLX3FAAHacfSN9vpKZQSNv3Eeu0=@strega-nil.co>
Message-ID: <9673ce30bd6a8b98906cc47f50ee527c.squirrel@mx.sdf.org>

> Hey all!
> I've just recently started looking into Gemini, and I decided to try and
> write my own little client. ???? I love what other people have done, but
> something I've noticed is that a lot of existing clients don't support
> Windows, so I thought I'd work on my own. ????
> Additionally, I kinda wanted to play with Rust and localization
> technologies, so that's on full display here as well. ????
> Here's the github page! https://github.com/strega-nil/garnet
> I warn you that it is... not feature complete at all. Currently, all it
> does is request gemini pages and print the resulting response out
> directly.
>
> Thanks for checking it out y'all!
> Nicole
Hi Nicole,

Can't wait to try this out. I'll probably take some time to dig through
the code to see how it works and how it's built as time allows. I'm stuck
on Windows for my day-job, so having a nice Gemini client would be a real
luxury :)

Thanks for the time and effort you are putting into this project!
-- 
Dunderpate


From dunderpate at sdf.org  Tue May 19 16:12:59 2020
From: dunderpate at sdf.org (Dunderpate)
Date: Tue, 19 May 2020 10:12:59 -0500
Subject: Any Windows clients?
In-Reply-To: <2TJFAQ.QMXFTMSB42CD2@kirgroup.net>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
 <2TJFAQ.QMXFTMSB42CD2@kirgroup.net>
Message-ID: <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel@mx.sdf.org>

> Il giorno gio 14 mag 2020 alle 13:29, Dunderpate <dunderpate at sdf.org>
> ha scritto:
>> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
>> confined
>> to Windows for my day job :/ So, I was just wondering if anyone on
>> this
>> list knows of a Windows client floating around that I could use.
>>
> I didn't tried but I would say that Alrisha
> (https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on
> windows without any problem...
Hi there!

Thanks for the recommendation! I just had a chance to look into this last
night and, unfortunately I'm not that comfortable creating a Qt account
just to install the tooling required to run qmake :/ I might be missing
something that allows me to bypass the account creation, but it's a
principle thing I guess LOL. The client itself seems nice enough though,
and if they had pre-compiled builds I'd certainly use one of 'em.

Thanks again :D
-- 
Dunderpate


From andrew at 68kmentat.com  Tue May 19 18:18:03 2020
From: andrew at 68kmentat.com (Andrew Kennedy)
Date: Tue, 19 May 2020 13:18:03 -0400
Subject: Any Windows clients?
In-Reply-To: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
Message-ID: <1722df13a02.c7b4232b344431.1739687027125254459@68kmentat.com>

I just got mcross running, after struggling to get Castor to build (even with the instructions, I'm not sure what I'm missing :/)

https://sr.ht/~nhanb/mcross/

it's pretty straightforward: Python 3.7+, run "pip install mcross" and then "mcross"

- Andrew


 ---- On Tue, 19 May 2020 11:13:04 -0400  <gemini-request at lists.orbitalfox.eu> wrote ----
 > Message: 9
 > Date: Tue, 19 May 2020 10:12:59 -0500
 > From: "Dunderpate" <dunderpate at sdf.org>
 > To: "A protocol that is slightly more complex than gopher, but
 >     significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
 > Subject: Re: Any Windows clients?
 > Message-ID: <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel at mx.sdf.org>
 > Content-Type: text/plain;charset=iso-8859-1
 > 
 > > Il giorno gio 14 mag 2020 alle 13:29, Dunderpate <dunderpate at sdf.org>
 > > ha scritto:
 > >> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
 > >> confined
 > >> to Windows for my day job :/ So, I was just wondering if anyone on
 > >> this
 > >> list knows of a Windows client floating around that I could use.
 > >>
 > > I didn't tried but I would say that Alrisha
 > > (https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on
 > > windows without any problem...
 > Hi there!
 > 
 > Thanks for the recommendation! I just had a chance to look into this last
 > night and, unfortunately I'm not that comfortable creating a Qt account
 > just to install the tooling required to run qmake :/ I might be missing
 > something that allows me to bypass the account creation, but it's a
 > principle thing I guess LOL. The client itself seems nice enough though,
 > and if they had pre-compiled builds I'd certainly use one of 'em.
 > 
 > Thanks again :D
 > -- 
 > Dunderpate
 > 

From andrew at 68kmentat.com  Tue May 19 18:34:29 2020
From: andrew at 68kmentat.com (Andrew Kennedy)
Date: Tue, 19 May 2020 13:34:29 -0400
Subject: Someone's client struggles with relative URLs
Message-ID: <1722e0046a7.cf4f6fc8347317.523042478508257830@68kmentat.com>

checking my logs, and noticed a client that was tacking relative URLs onto the current document, instead of the current folder. Maybe I'm wrong, but that sounds like wrong behavior on the client's end to me. Here's the logs:

,,,
May 19 13:09:13 raspberrypi jetforce[343]: 92.8.xxx.xx [19/May/2020:13:09:13 -0400] "gemini://gemini.68kmentat.com:1965/updates.gmi/nilog/" 51 "Not Found" 14
May 19 13:09:21 raspberrypi jetforce[343]: 92.8.xxx.xx [19/May/2020:13:09:21 -0400] "gemini://gemini.68kmentat.com:1965/updates.gmi/updates.gmi" 51 "Not Found" 14
,,,

and the links in gemini://gemini.68kmentat.com/updates.gmi:

,,,
=> updates.gmi Updates - now have an update log
=> nilog/ Nilog - new Nilog entry
,,,

I don't really understand how the client managed to get to updates.gmi, since that is also relatively linked in my index.gmi. But hopefully the dev will read this e-mail if they didn't already know about the issue.

- Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/8d9e3766/attachment.htm>

From luke.emmet at gmail.com  Tue May 19 18:45:54 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Tue, 19 May 2020 18:45:54 +0100
Subject: Someone's client struggles with relative URLs
In-Reply-To: <1722e0046a7.cf4f6fc8347317.523042478508257830@68kmentat.com>
References: <1722e0046a7.cf4f6fc8347317.523042478508257830@68kmentat.com>
Message-ID: <5EC41B52.3000707@gmail.com>

On 19-May-2020 18:34, Andrew Kennedy wrote:
> checking my logs, and noticed a client that was tacking relative URLs 
> onto the current document, instead of the current folder. Maybe I'm 
> wrong, but that sounds like wrong behavior on the client's end to me. 
> Here's the logs:
>
> I don't really understand how the client managed to get to 
> updates.gmi, since that is also relatively linked in my index.gmi. But 
> hopefully the dev will read this e-mail if they didn't already know 
> about the issue.
Thanks for that - its probably me - I'm testing a new client. Still a 
few things to fix before announcing, like this broken URL assembly 
behaviour...

Or maybe I was testing the robustness of your server by requesting 
broken urls ;-)

  - Luke

From dunderpate at sdf.org  Tue May 19 18:52:20 2020
From: dunderpate at sdf.org (Dunderpate)
Date: Tue, 19 May 2020 12:52:20 -0500
Subject: Any Windows clients?
In-Reply-To: <1722df13a02.c7b4232b344431.1739687027125254459@68kmentat.com>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
 <1722df13a02.c7b4232b344431.1739687027125254459@68kmentat.com>
Message-ID: <0235b28c4f1280b39c012113bdbebfb2.squirrel@mx.sdf.org>

Hi Andrew,

Fantastic! I'm much more familiar with Python than I am with rust and all
the vcpkg shenanigans that were going on with castor. I'll give this a
shot and post a pic if it works.

Thanks again Andrew :D

Dunderpate
> I just got mcross running, after struggling to get Castor to build (even
> with the instructions, I'm not sure what I'm missing :/)
>
> https://sr.ht/~nhanb/mcross/
>
> it's pretty straightforward: Python 3.7+, run "pip install mcross" and
> then "mcross"
>
> - Andrew
>
>
>  ---- On Tue, 19 May 2020 11:13:04 -0400
> <gemini-request at lists.orbitalfox.eu> wrote ----
>  > Message: 9
>  > Date: Tue, 19 May 2020 10:12:59 -0500
>  > From: "Dunderpate" <dunderpate at sdf.org>
>  > To: "A protocol that is slightly more complex than gopher, but
>  >     significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>  > Subject: Re: Any Windows clients?
>  > Message-ID: <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel at mx.sdf.org>
>  > Content-Type: text/plain;charset=iso-8859-1
>  >
>  > > Il giorno gio 14 mag 2020 alle 13:29, Dunderpate <dunderpate at sdf.org>
>  > > ha scritto:
>  > >> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
>  > >> confined
>  > >> to Windows for my day job :/ So, I was just wondering if anyone on
>  > >> this
>  > >> list knows of a Windows client floating around that I could use.
>  > >>
>  > > I didn't tried but I would say that Alrisha
>  > > (https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on
>  > > windows without any problem...
>  > Hi there!
>  >
>  > Thanks for the recommendation! I just had a chance to look into this
> last
>  > night and, unfortunately I'm not that comfortable creating a Qt account
>  > just to install the tooling required to run qmake :/ I might be missing
>  > something that allows me to bypass the account creation, but it's a
>  > principle thing I guess LOL. The client itself seems nice enough
> though,
>  > and if they had pre-compiled builds I'd certainly use one of 'em.
>  >
>  > Thanks again :D
>  > --
>  > Dunderpate
>  >
>


From nicole at strega-nil.co  Tue May 19 19:10:14 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Tue, 19 May 2020 18:10:14 +0000
Subject: Any Windows clients?
In-Reply-To: <0235b28c4f1280b39c012113bdbebfb2.squirrel@mx.sdf.org>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
 <1722df13a02.c7b4232b344431.1739687027125254459@68kmentat.com>
 <0235b28c4f1280b39c012113bdbebfb2.squirrel@mx.sdf.org>
Message-ID: <HYRa4PhhvxJ9gDn5pah6dKi82qoZ_Q0euPh3Dn1pXAlV-tQHXZx0IfsXxpqozYmAig3dOgnbQlkTlBlPX9tUDV-ffHhVREFePKQ8eNx3o6s=@strega-nil.co>

FWIW, I'm on the vcpkg team so if anyone needs help with it you can always reach out. Additionally, includecpp.org's discord has a #vcpkg channel a few of us hang out on.

(somewhat unrelated but _shrug_)

Nicole

-------- Original Message --------
On May 19, 2020, 10:52, Dunderpate wrote:

> Hi Andrew,
>
> Fantastic! I'm much more familiar with Python than I am with rust and all
> the vcpkg shenanigans that were going on with castor. I'll give this a
> shot and post a pic if it works.
>
> Thanks again Andrew :D
>
> Dunderpate
>> I just got mcross running, after struggling to get Castor to build (even
>> with the instructions, I'm not sure what I'm missing :/)
>>
>> https://sr.ht/~nhanb/mcross/
>>
>> it's pretty straightforward: Python 3.7+, run "pip install mcross" and
>> then "mcross"
>>
>> - Andrew
>>
>>
>> ---- On Tue, 19 May 2020 11:13:04 -0400
>> <gemini-request at lists.orbitalfox.eu> wrote ----
>> > Message: 9
>> > Date: Tue, 19 May 2020 10:12:59 -0500
>> > From: "Dunderpate" <dunderpate at sdf.org>
>> > To: "A protocol that is slightly more complex than gopher, but
>> > significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>> > Subject: Re: Any Windows clients?
>> > Message-ID: <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel at mx.sdf.org>
>> > Content-Type: text/plain;charset=iso-8859-1
>> >
>> > > Il giorno gio 14 mag 2020 alle 13:29, Dunderpate <dunderpate at sdf.org>
>> > > ha scritto:
>> > >> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
>> > >> confined
>> > >> to Windows for my day job :/ So, I was just wondering if anyone on
>> > >> this
>> > >> list knows of a Windows client floating around that I could use.
>> > >>
>> > > I didn't tried but I would say that Alrisha
>> > > (https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on
>> > > windows without any problem...
>> > Hi there!
>> >
>> > Thanks for the recommendation! I just had a chance to look into this
>> last
>> > night and, unfortunately I'm not that comfortable creating a Qt account
>> > just to install the tooling required to run qmake :/ I might be missing
>> > something that allows me to bypass the account creation, but it's a
>> > principle thing I guess LOL. The client itself seems nice enough
>> though,
>> > and if they had pre-compiled builds I'd certainly use one of 'em.
>> >
>> > Thanks again :D
>> > --
>> > Dunderpate
>> >
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/cfdf7397/attachment.htm>

From peteyboy at sdf.org  Tue May 19 19:40:45 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Tue, 19 May 2020 11:40:45 -0700
Subject: [ANN] Moonlander: The fanciest Gemini client in the entiresolar
 system
In-Reply-To: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
Message-ID: <7E9E467C-AD34-405D-BBC3-88EBA84809FD@sdf.org>

Cool! I just got Castor and mcross installed last night, but neither works with alternate ports (not 1965) which I've had to host my jetforce server on. So im stuck playing with authoring using V-98to view. So if you could make sure gemini://url:port works, I'd love it.

On May 19, 2020 8:13:04 AM 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. any Gemini to HTTP gateway? (defdefred)
>   2. Re: any Gemini to HTTP gateway? (Ben)
>   3. Re: [ANN] md2gemini release v1.1.0 and gemini linking
>      discussion (Jason McBrayer)
>   4. Re: vostok: my protocol-agnostic framework, with (very basic)
>      gemini support (Jason McBrayer)
>   5. [ANN] Moonlander: The fanciest Gemini client in the entire
>      solar system (Ecmel Berk Canl?er)
>   6. Extra GUS crawling this morning (Natalie Pendragon)
>   7. Re: [ANN] Moonlander: The fanciest Gemini client in the
>      entire solar system (defdefred)
>   8. Re: Announcing garnet, a new (soon-to-be) TUI client (Dunderpate)
>   9. Re: Any Windows clients? (Dunderpate)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 19 May 2020 11:15:55 +0000
>From: defdefred <defdefred at protonmail.com>
>To: "A protocol that is slightly more complex than gopher, but
>	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>Subject: any Gemini to HTTP gateway?
>Message-ID:
>	<b1fdxvBCvR7WJN45pE8ltkpgp3mt8S68V-_wko8Ccb6jGYmgpeQoXSlazPUO5T2GLVvKsU-SHJ90PDOp0OWzAfXLEyQqHBNf2MnVC2T_DJw=@protonmail.com>
>	
>Content-Type: text/plain; charset="utf-8"
>
>Hey!
>Do you know any good gateway to read gemini  with a http browser?
>
>Regards,
>freD.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/24a9c739/attachment-0001.htm>
>
>------------------------------
>
>Message: 2
>Date: Tue, 19 May 2020 16:07:55 +0430
>From: Ben <benulo at systemli.org>
>To: defdefred <defdefred at protonmail.com>, A protocol that is slightly
>	more complex than "gopher," but significantly simpler than HTTP
>	<gemini at lists.orbitalfox.eu>
>Subject: Re: any Gemini to HTTP gateway?
>Message-ID: <b9aeb3a6-8fba-0176-a104-3275aefc4134 at systemli.org>
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>I know a couple listed on the Gemini project page:
>
>https://portal.mozz.us/?url=gemini%3A%2F%2Fgemini.circumlunar.space%2F&fmt=fixed
>https://proxy.vulpes.one/gemini/gemini.circumlunar.space
>
>-- 
>gemini://kwiecien.us/
>
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 19 May 2020 07:38:53 -0400
>From: Jason McBrayer <jmcbray at carcosa.net>
>To: colecmac at protonmail.com
>Cc: "A protocol that is slightly more complex than gopher\, but
>	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>Subject: Re: [ANN] md2gemini release v1.1.0 and gemini linking
>	discussion
>Message-ID: <874ksc5f3m.fsf at dorothy.carcosa.net>
>Content-Type: text/plain
>
>colecmac at protonmail.com writes:
>
>> There was some discussion in another thread about having inline links
>> in text/gemini, which solderpunk rejected because it would make
>> parsing much more difficult. I agree with him, and so I wonder what
>> others on this list think of my take on this. Does using footnotes
>make
>> sense? Are there better, or just different ways to do solve this
>problem?
>
>As a 'best practice', and not as a specification, I prefer using
>footnotes after each paragraph. I'm glad to see your program supports
>that option.
>
>-- 
>+-----------------------------------------------------------+  
>| Jason F. McBrayer                    jmcbray at carcosa.net  |  
>| If someone conquers a thousand times a thousand others in |  
>| battle, and someone else conquers himself, the latter one |  
>| is the greatest of all conquerors.  --- The Dhammapada    |  
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 19 May 2020 07:45:14 -0400
>From: Jason McBrayer <jmcbray at carcosa.net>
>To: solderpunk <solderpunk at SDF.ORG>
>Cc: gemini at lists.orbitalfox.eu
>Subject: Re: vostok: my protocol-agnostic framework, with (very basic)
>	gemini support
>Message-ID: <87zha4408l.fsf at dorothy.carcosa.net>
>Content-Type: text/plain
>
>solderpunk <solderpunk at SDF.ORG> writes:
>
>> On Tue, May 19, 2020 at 04:42:15AM +0000, Zoey Riordan wrote:
>> With the arrival of Vostok alongside the in-development clients Soyuz
>> (gemini://gemini.circumlunar.space/users/dominikd/) and Voskhod (JMB,
>is
>> there a link for Voskhod yet?), we are just about out of names to
>borrow
>> from the classic era of Soviet manned spaceflight! :)  I guess Salyut
>is
>> left.
>
>I realize there's not, and the code is only on the ThinkPad whose power
>adapter let out the magic smoke, so there won't be until the
>replacement
>power adapter arrives. It's kind of in limbo for now, because I need to
>figure out how Gnome Builder interacts with PyGTK better.
>
>-- 
>+-----------------------------------------------------------+  
>| Jason F. McBrayer                    jmcbray at carcosa.net  |  
>| If someone conquers a thousand times a thousand others in |  
>| battle, and someone else conquers himself, the latter one |  
>| is the greatest of all conquerors.  --- The Dhammapada    |  
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 19 May 2020 15:43:00 +0300
>From: Ecmel Berk Canl?er <me at ecmelberk.com>
>To: gemini at lists.orbitalfox.eu
>Subject: [ANN] Moonlander: The fanciest Gemini client in the entire
>	solar system
>Message-ID: <20200519154300.64815d02 at socimda>
>Content-Type: text/plain; charset=US-ASCII
>
>Hey all!
>
>I was working on this for the last weekend or so, and I believe it's
>now ready enough to share.
>
>Announcing: Moonlander[1], the fanciest graphical Gemini client in the
>entire solar system [citation needed].
>
>[1]: https://sr.ht/~admicos/moonlander
>
>A screenshot: https://files.ecmelberk.com/img/1589891854.png
>
>Please note that it's still under development, and there are a lot of
>known bugs. Still, why not take it for a spin?
>
>
>The rest of this mail will be an excerpt from the readme file:
>----
>
>## Features
>
>- Custom, themeable rendering engine via Cairo & Pango
>- Tries to follow Gnome HIG
>
>### Known Bugs
>
>- TLS Certificates aren't verified
>- Somewhat high resource usage (for a Gemini client)
>- No cross-protocol linking (yet)
>- Cannot navigate backwards through redirections
>- Renderer doesn't behave "native"
>  - Cannot select/copy text
>  - No interaction other than mouse clicks on links and scrolling
>
>### Planned Features
>
>- Tabs
>- Render more than just text/gemini and plaintext.
>  - Planned: Markdown & images
>
>- Possibly support other protocols
>  - Gopher, etc.
>  - Definitely not HTTP, unless excluding HTML
>
>- Syntax highlighting (?)
>  - Waiting on text/gemini preformatting annotations to be somewhat
>  standardized
>
>
>------------------------------
>
>Message: 6
>Date: Tue, 19 May 2020 10:19:25 -0400
>From: Natalie Pendragon <natpen at natpen.net>
>To: gemini at lists.orbitalfox.eu
>Subject: Extra GUS crawling this morning
>Message-ID: <20200519141925.GC1613152 at goldfish.localdomain>
>Content-Type: text/plain; charset=us-ascii
>
>Hi all,
>
>Just FYI in case anyone is seeing the increased crawling traffic this
>morning, GUS is getting some upgrades. And by upgrades I of course
>mean it's now breaking in novel, unexpected ways. Fingers crossed it
>should calm down soon! And once it does, GUS searches should be even
>better (I noticed I wasn't handling relative links on pages well, so I
>think the index has been missing a fair bit of content thus far).
>
>Natalie
>
>
>------------------------------
>
>Message: 7
>Date: Tue, 19 May 2020 14:34:46 +0000
>From: defdefred <defdefred at protonmail.com>
>To: "A protocol that is slightly more complex than gopher, but
>	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>Subject: Re: [ANN] Moonlander: The fanciest Gemini client in the
>	entire solar system
>Message-ID:
>	<MGUkWLg93GVCBByALEPBoIOvVh-hxhy3lsg9H1QkiIfwivIU8HZ4u_mdM1HU6_hw7HVN11IdaPSI42qQ2MLjTjhyEq8xUXTr2JhsDEsH37Q=@protonmail.com>
>	
>Content-Type: text/plain; charset=UTF-8
>
>On Tuesday 19 May 2020 14:43, Ecmel Berk Canl?er <me at ecmelberk.com>
>wrote:
>> -   Render more than just text/gemini and plaintext.
>>     -   Planned: Markdown & images
>A Markdown Browser... what a nice idea!
>
>
>------------------------------
>
>Message: 8
>Date: Tue, 19 May 2020 10:09:14 -0500
>From: "Dunderpate" <dunderpate at sdf.org>
>To: "Nicole Mazzuca" <nicole at strega-nil.co>, "A protocol that is
>	slightly more complex than gopher, but significantly simpler than
>	HTTP" <gemini at lists.orbitalfox.eu>
>Subject: Re: Announcing garnet, a new (soon-to-be) TUI client
>Message-ID: <9673ce30bd6a8b98906cc47f50ee527c.squirrel at mx.sdf.org>
>Content-Type: text/plain;charset=iso-8859-1
>
>> Hey all!
>> I've just recently started looking into Gemini, and I decided to try
>and
>> write my own little client. ???? I love what other people have done,
>but
>> something I've noticed is that a lot of existing clients don't
>support
>> Windows, so I thought I'd work on my own. ????
>> Additionally, I kinda wanted to play with Rust and localization
>> technologies, so that's on full display here as well. ????
>> Here's the github page! https://github.com/strega-nil/garnet
>> I warn you that it is... not feature complete at all. Currently, all
>it
>> does is request gemini pages and print the resulting response out
>> directly.
>>
>> Thanks for checking it out y'all!
>> Nicole
>Hi Nicole,
>
>Can't wait to try this out. I'll probably take some time to dig through
>the code to see how it works and how it's built as time allows. I'm
>stuck
>on Windows for my day-job, so having a nice Gemini client would be a
>real
>luxury :)
>
>Thanks for the time and effort you are putting into this project!
>-- 
>Dunderpate
>
>
>
>------------------------------
>
>Message: 9
>Date: Tue, 19 May 2020 10:12:59 -0500
>From: "Dunderpate" <dunderpate at sdf.org>
>To: "A protocol that is slightly more complex than gopher, but
>	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>Subject: Re: Any Windows clients?
>Message-ID: <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel at mx.sdf.org>
>Content-Type: text/plain;charset=iso-8859-1
>
>> Il giorno gio 14 mag 2020 alle 13:29, Dunderpate <dunderpate at sdf.org>
>> ha scritto:
>>> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
>>> confined
>>> to Windows for my day job :/ So, I was just wondering if anyone on
>>> this
>>> list knows of a Windows client floating around that I could use.
>>>
>> I didn't tried but I would say that Alrisha
>> (https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on
>> windows without any problem...
>Hi there!
>
>Thanks for the recommendation! I just had a chance to look into this
>last
>night and, unfortunately I'm not that comfortable creating a Qt account
>just to install the tooling required to run qmake :/ I might be missing
>something that allows me to bypass the account creation, but it's a
>principle thing I guess LOL. The client itself seems nice enough
>though,
>and if they had pre-compiled builds I'd certainly use one of 'em.
>
>Thanks again :D
>-- 
>Dunderpate
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>Gemini mailing list
>Gemini at lists.orbitalfox.eu
>https://lists.orbitalfox.eu/listinfo/gemini
>
>
>------------------------------
>
>End of Gemini Digest, Vol 10, Issue 50
>**************************************

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/0d2fb483/attachment-0001.htm>

From jetkoten at gmail.com  Tue May 19 20:07:14 2020
From: jetkoten at gmail.com (=?UTF-8?B?4pyI5YCL5bGV?=)
Date: Tue, 19 May 2020 14:07:14 -0500
Subject: gemini-fmt idea
Message-ID: <CANW6ZfFjbykO9wE4e+tyqVcCArv=y1AacTN9hmmp3UiopG0rkQ@mail.gmail.com>

Hi all,

I just joined the list but have read some of the recent messages and
wondered if having a gemini-fmt tool like Go and Rust use to conform a
source document to a pre-existing spec might solve some of the issues
around Gemini documents meeting the spec and around properly configuring
the meta headers.

I feel like the people writing servers and clients are doing a huge service
to the community, so having this gemini-fmt tool would help ease the load
on them by ensuring that the Gemini documents that get uploaded to servers
for public consumption and are then served to clients are more or less
guaranteed to conform to the spec. This will save the people who write the
servers and clients from having to spend time handling all kinds of edge
cases. I'm including a preliminary outline of what I have in mind here
below. Comments are welcome.

Thanks,
J

--

# gemini-fmt idea

## Summary

A tool for Gemini authors that automatically conforms their Gemini texts to
the Gemini spec and also applies the author's preferences for meta headings
such as spoken language and robot indexing/proxying.

Should likely be written in Python 3, so that it can run just about
everywhere and be very lightweight.

Could also be hosted on a website, where a Gemini author could cut and
paste their text and indicate their meta preferences (see below) and
recieve a spec compliant Gemini text to paste back into their editor to
then save and upload to a server.

## On first run

gemini-fmt will ask the Gemini author to input their preferences for the
following:

### Language

- Enter the spoken language that your Gemini texts will usually be
published in

### Robots

- archiving - Should your Gemini texts be allowed to be archived long-term
on a third party website?

- proxy-gopher - Should your Gemini texts be allowed to be accessible over
gopher through Gemini to gopher translator services?

- proxy-html - Should your Gemini texts be allowed to be accessible through
Gemini to html translator services?

- research - Should your Gemini texts be allowed to be scanned by third
parties conducting research that will access your texts but not re-publish
the contents?

- search-engine - Should your Gemini texts be allowed to be scanned for use
and/or re-publishing in search engines?

## Other ideas

- Simple mode/expert mode - let a more technical user that might like to
otherwise configure their own settings just run a spec check that won't
automatically change their text but just warn of errors and point them to
relavent parts of the spec

- Override general settings - a Gemini author might want to give full
robots permissions to one text but no others, maybe there needs to be some
kind of index for robots that shows the file path for those?

- Something like the preformatted tag to indicate a second language within
a text already tagged as another language
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/b5027d1c/attachment.htm>

From jmcbray at carcosa.net  Tue May 19 20:19:00 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 19 May 2020 15:19:00 -0400
Subject: Emacs mode for text/gemini?
Message-ID: <87h7wb91i3.fsf@dorothy.carcosa.net>

Hi, all. Has anyone written an emacs mode for text/gemini? I know
there's a vim syntax for it, and someone mentioned one for emacs, but
they might just have been assuming.

Eventually, I'll write one if no one has.
-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jan6 at tilde.ninja  Tue May 19 20:32:40 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Tue, 19 May 2020 19:32:40 +0000
Subject: gemini-fmt idea
In-Reply-To: <CANW6ZfFjbykO9wE4e+tyqVcCArv=y1AacTN9hmmp3UiopG0rkQ@mail.gmail.com>
References: <CANW6ZfFjbykO9wE4e+tyqVcCArv=y1AacTN9hmmp3UiopG0rkQ@mail.gmail.com>
Message-ID: <d9bddb6be5f53dadb413e5670edd632b@tilde.ninja>

May 19, 2020 10:07 PM, "???" <jetkoten at gmail.com> wrote:

> Hi all,
> 
> I just joined the list but have read some of the recent messages and wondered if having a
> gemini-fmt tool like Go and Rust use to conform a source document to a pre-existing spec might
> solve some of the issues around Gemini documents meeting the spec and around properly configuring
> the meta headers.
> 
> I feel like the people writing servers and clients are doing a huge service to the community, so
> having this gemini-fmt tool would help ease the load on them by ensuring that the Gemini documents
> that get uploaded to servers for public consumption and are then served to clients are more or less
> guaranteed to conform to the spec. This will save the people who write the servers and clients from
> having to spend time handling all kinds of edge cases. I'm including a preliminary outline of what
> I have in mind here below. Comments are welcome.
> 
> Thanks,
> 
> J

Sounds cool, as a tool unrelated to the official spec, just as a utility...

Right now, the verification load is put on the servers anyway, but this could also double as an easy way to get started with writing a gemini server, as you can just take the "verify" part, and not need to re-implement all the checks (and since you can cache the files with some simple checksum, it probably wouldn't be too bad performance-wise to run it as an external executable, even)
for being portable and embeddable, C is also a good choice, mostly because practically every platform has a C compiler, and a LOT of languages have some sort of "CFFI" or similar thing, "C Foreign Function Interface", which lets you call C functions from that language, you can use a C library in python through that, for example...
python3 is probably very much OK for practical usage by humans

> - Something like the preformatted tag to indicate a second language within a text already tagged as
> another language

I...don't think this is part of the spec, but I'd LOVE if there was a way to indicate multiple languages in one document... if you write parts in different languages (maybe are writing articles about conlangs, or want to have some quotes from another language, or something), then it would be really useful to allow signifying the change...

From martin at no.ucant.org  Tue May 19 20:46:17 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 19 May 2020 20:46:17 +0100 (BST)
Subject: gemini-fmt idea
In-Reply-To: <d9bddb6be5f53dadb413e5670edd632b@tilde.ninja>
References: <CANW6ZfFjbykO9wE4e+tyqVcCArv=y1AacTN9hmmp3UiopG0rkQ@mail.gmail.com>
 <d9bddb6be5f53dadb413e5670edd632b@tilde.ninja>
Message-ID: <alpine.DEB.2.20.2005192037380.18317@pling.qwghlm.org>

On Tue, 19 May 2020, jan6 at tilde.ninja wrote:

> Sounds cool, as a tool unrelated to the official spec, just as a utility...
>
> Right now, the verification load is put on the servers anyway, but this could also double as an easy way to get started with writing a gemini server, as you can just take the "verify" part, and not need to re-implement all the checks (and since you can cache the files with some simple checksum, it probably wouldn't be too bad performance-wise to run it as an external executable, even)
> for being portable and embeddable, C is also a good choice, mostly because practically every platform has a C compiler, and a LOT of languages have some sort of "CFFI" or similar thing, "C Foreign Function Interface", which lets you call C functions from that language, you can use a C library in python through that, for example...
> python3 is probably very much OK for practical usage by humans

For the time being, it'd be a good step forward just to have a tool in
*any* language which reliably answered the question whether a file/string
were conformant with the spec. It'd be nice to be able to say 
sendfile(readfile()) and know that one's not breaking the strict reading
of the spec.

For this, it suffices to have a gemini-check tool rather than a gemini-fmt 
tool, which presumably would be able to output a new, conformant file.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From nicole at strega-nil.co  Tue May 19 21:01:26 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Tue, 19 May 2020 20:01:26 +0000
Subject: gemini-fmt idea
In-Reply-To: <d9bddb6be5f53dadb413e5670edd632b@tilde.ninja>
References: <CANW6ZfFjbykO9wE4e+tyqVcCArv=y1AacTN9hmmp3UiopG0rkQ@mail.gmail.com>
 <d9bddb6be5f53dadb413e5670edd632b@tilde.ninja>
Message-ID: <U0tr7m5vVWZ3cIxf-QnwsZHyXuvdDbw98_q8yqplnUFwtGsAOlAhBmizM-0GTz7K4HZdtJtIMDdJ2exjJdcev-_SV_LGzOxiDaGPIybIOoQ=@strega-nil.co>

> I...don't think this is part of the spec, but I'd
> LOVE if there was a way to indicate multiple
> languages in one document... if you write
> parts in different languages (maybe are
> writing articles about conlangs, or want to
> have some quotes from another language, or
> something), then it would be really useful to
> allow signifying the change...

FWIW, this is also a necessity for writing both Chinese and Japanese in the same document, due to the Han unification of Unicode.

Nicole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/a6a11690/attachment.htm>

From jetkoten at gmail.com  Tue May 19 21:07:17 2020
From: jetkoten at gmail.com (=?UTF-8?B?4pyI5YCL5bGV?=)
Date: Tue, 19 May 2020 15:07:17 -0500
Subject: gemini-fmt idea
In-Reply-To: <alpine.DEB.2.20.2005192037380.18317@pling.qwghlm.org>
References: <CANW6ZfFjbykO9wE4e+tyqVcCArv=y1AacTN9hmmp3UiopG0rkQ@mail.gmail.com>
 <d9bddb6be5f53dadb413e5670edd632b@tilde.ninja>
 <alpine.DEB.2.20.2005192037380.18317@pling.qwghlm.org>
Message-ID: <CANW6ZfGeDfCa6OK=ydC=RkXAydYQjg2PC=77vOk+y610Qti60A@mail.gmail.com>

On Tue, May 19, 2020, 14:46 Martin Keegan <martin at no.ucant.org> wrote:

> On Tue, 19 May 2020, jan6 at tilde.ninja wrote:
>
> C is also a good choice [?] python3 is probably very much OK for practical
> usage by humans


Sorry Jan, I didn't get your email from the list so I have to double quote
it here. Oops, yeah, I meant to say that about python too. Just to make it
easier for less technical would be Gemini authors. pip install gemini-fmt
and then gemini-fmt mytext.gemini is super easy, in addition to the
lightweight and portable parts.

Makes a lot of sense to look at an embeddable similar verify tool.

>
> For the time being, it'd be a good step forward just to have a tool in
> *any* language which reliably answered the question whether a file/string
> were conformant with the spec. It'd be nice to be able to say
> sendfile(readfile()) and know that one's not breaking the strict reading
> of the spec.
>
> For this, it suffices to have a gemini-check tool rather than a gemini-fmt
> tool, which presumably would be able to output a new, conformant file.
>

Yes, gemini-fmt in "simple mode" would output a new file but "expert mode"
would be a gemini-check with friendly error output that would say what
didn't match the spec

Thank you both for the comments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/fd2cb72b/attachment-0001.htm>

From jetkoten at gmail.com  Tue May 19 21:10:56 2020
From: jetkoten at gmail.com (=?UTF-8?B?4pyI5YCL5bGV?=)
Date: Tue, 19 May 2020 15:10:56 -0500
Subject: gemini-fmt idea
In-Reply-To: <U0tr7m5vVWZ3cIxf-QnwsZHyXuvdDbw98_q8yqplnUFwtGsAOlAhBmizM-0GTz7K4HZdtJtIMDdJ2exjJdcev-_SV_LGzOxiDaGPIybIOoQ=@strega-nil.co>
References: <CANW6ZfFjbykO9wE4e+tyqVcCArv=y1AacTN9hmmp3UiopG0rkQ@mail.gmail.com>
 <d9bddb6be5f53dadb413e5670edd632b@tilde.ninja>
 <U0tr7m5vVWZ3cIxf-QnwsZHyXuvdDbw98_q8yqplnUFwtGsAOlAhBmizM-0GTz7K4HZdtJtIMDdJ2exjJdcev-_SV_LGzOxiDaGPIybIOoQ=@strega-nil.co>
Message-ID: <CANW6ZfFWQ5FjJsC3zgzPLKXq9h0gxPaqbsufAFKywkYvOrW=Vw@mail.gmail.com>

On Tue, May 19, 2020, 15:01 Nicole Mazzuca <nicole at strega-nil.co> wrote:

> > I...don't think this is part of the spec, but I'd
> > LOVE if there was a way to indicate multiple
> > languages in one document... if you write
> > parts in different languages (maybe are
> > writing articles about conlangs, or want to
> > have some quotes from another language, or
> > something), then it would be really useful to
> > allow signifying the change...
>
> FWIW, this is also a necessity for writing both Chinese and Japanese in
> the same document, due to the Han unification of Unicode.
>
> Nicole
>

Yes, and I don't know for sure but I would think, for instance, among
lesser known Romance languages it would be difficult to autodetect them and
much easier to have the author tag them.

Thanks,
J

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/c6e6269d/attachment.htm>

From jan6 at tilde.ninja  Tue May 19 21:12:17 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Tue, 19 May 2020 20:12:17 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <PzzIb-EGPImPJrodUQM5MOFKEWZHWAyF0noU2tT2LkikCr3mWjAsq-JftohmGxyINAHvcrLgNI57ieJhzv9XtrTr9HxgDLXt17sN7Ubwuzc=@protonmail.com>
References: <PzzIb-EGPImPJrodUQM5MOFKEWZHWAyF0noU2tT2LkikCr3mWjAsq-JftohmGxyINAHvcrLgNI57ieJhzv9XtrTr9HxgDLXt17sN7Ubwuzc=@protonmail.com>
 <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
 <lz5zcstmab.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <ca67c95b4f3fe36c44148d930db0d299@tilde.ninja>

I'd LOVE if there was a way to indicate multiple languages in one document...

if you write parts in different languages (maybe are writing articles about conlangs, or want to have some quotes from another language, or have language tutorials or comparisons or something), then it would be really useful to allow signifying the change...

and as Nicole said in another thread,
> FWIW, this is also a necessity for writing both Chinese and Japanese in the same document, due to the Han unification of Unicode.

would need to be another block type thingy, probably...

while it's complicating the spec a little, it'd be quite useful for some people...

From colecmac at protonmail.com  Tue May 19 21:43:35 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 19 May 2020 20:43:35 +0000
Subject: vostok: my protocol-agnostic framework,
 with (very basic) gemini support
In-Reply-To: <87zha4408l.fsf@dorothy.carcosa.net>
References: <9ubMHnqYsJnRb8beq_cUw7dzNqDQ6GHjJDhVzVTbkGsHHx4XZYIbJObbUkJtz5hzddIrHT2v1xFraNXTOFeTN1HxuQXNURRmzGZ8ctbZCaY=@dos.cafe>
 <20200519075437.GE4068@SDF.ORG>
 <87zha4408l.fsf@dorothy.carcosa.net>
Message-ID: <5rmFKwaLf8MjUu5h9CCbNEMq-orN5urL4rkpp65Ua8RRhrRsfvV-c9OvJH3vSHOXiPhebTh_XXY7x_uII3Gty2NMBuuOtRf8oqFILsNT_18=@protonmail.com>

On Tuesday, May 19, 2020 7:45 AM, Jason McBrayer <jmcbray at carcosa.net> wrote:

> solderpunk solderpunk at SDF.ORG writes:
>
> > On Tue, May 19, 2020 at 04:42:15AM +0000, Zoey Riordan wrote:
> > With the arrival of Vostok alongside the in-development clients Soyuz
> > (gemini://gemini.circumlunar.space/users/dominikd/) and Voskhod (JMB, is
> > there a link for Voskhod yet?), we are just about out of names to borrow
> > from the classic era of Soviet manned spaceflight! :) I guess Salyut is
> > left.
>
> I realize there's not, and the code is only on the ThinkPad whose power
> adapter let out the magic smoke, so there won't be until the replacement
> power adapter arrives. It's kind of in limbo for now, because I need to
> figure out how Gnome Builder interacts with PyGTK better.

Did you mix up your emails? I'm very confused :P

From colecmac at protonmail.com  Tue May 19 21:52:02 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 19 May 2020 20:52:02 +0000
Subject: [ANN] Moonlander: The fanciest Gemini client in the entire solar
 system
In-Reply-To: <20200519154300.64815d02@socimda>
References: <20200519154300.64815d02@socimda>
Message-ID: <Egy8kp6C94w4i6Pnyd3l64WZRFyvhN6rG2kYpCCWiu6Oz3b44Evr04pvt2MDDBz_wH3T5Dg1xWPQPKsT_porHb5pcTidlaOLQsE4W3HDs8g=@protonmail.com>

Wow, that screenshot is looking good! I'm excited for the planned
markdown and image rendering. Feel free to send an update to us
as more features are added. Also come join us on IRC: #gemini at
tilde.chat (irc.tilde.chat is the actual server).

I will compile and try it out!

makeworld

??????? Original Message ???????
On Tuesday, May 19, 2020 8:43 AM, Ecmel Berk Canl?er <me at ecmelberk.com> wrote:

> Hey all!
>
> I was working on this for the last weekend or so, and I believe it's
> now ready enough to share.
>
> Announcing: Moonlander[1], the fanciest graphical Gemini client in the
> entire solar system [citation needed].
>
> [1]: https://sr.ht/~admicos/moonlander
>
> A screenshot: https://files.ecmelberk.com/img/1589891854.png
>
> Please note that it's still under development, and there are a lot of
> known bugs. Still, why not take it for a spin?
>
> The rest of this mail will be an excerpt from the readme file:
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Features
>
> ---------
>
> -   Custom, themeable rendering engine via Cairo & Pango
> -   Tries to follow Gnome HIG
>
> ### Known Bugs
>
> -   TLS Certificates aren't verified
> -   Somewhat high resource usage (for a Gemini client)
> -   No cross-protocol linking (yet)
> -   Cannot navigate backwards through redirections
> -   Renderer doesn't behave "native"
>     -   Cannot select/copy text
>     -   No interaction other than mouse clicks on links and scrolling
>
> ### Planned Features
>
> -   Tabs
> -   Render more than just text/gemini and plaintext.
>     -   Planned: Markdown & images
> -   Possibly support other protocols
>     -   Gopher, etc.
>     -   Definitely not HTTP, unless excluding HTML
> -   Syntax highlighting (?)
>     -   Waiting on text/gemini preformatting annotations to be somewhat
>         standardized
>



From solderpunk at SDF.ORG  Tue May 19 21:56:43 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 20:56:43 +0000
Subject: vostok: my protocol-agnostic framework, with (very basic) gemini
 support
In-Reply-To: <5rmFKwaLf8MjUu5h9CCbNEMq-orN5urL4rkpp65Ua8RRhrRsfvV-c9OvJH3vSHOXiPhebTh_XXY7x_uII3Gty2NMBuuOtRf8oqFILsNT_18=@protonmail.com>
References: <9ubMHnqYsJnRb8beq_cUw7dzNqDQ6GHjJDhVzVTbkGsHHx4XZYIbJObbUkJtz5hzddIrHT2v1xFraNXTOFeTN1HxuQXNURRmzGZ8ctbZCaY=@dos.cafe>
 <20200519075437.GE4068@SDF.ORG>
 <87zha4408l.fsf@dorothy.carcosa.net>
 <5rmFKwaLf8MjUu5h9CCbNEMq-orN5urL4rkpp65Ua8RRhrRsfvV-c9OvJH3vSHOXiPhebTh_XXY7x_uII3Gty2NMBuuOtRf8oqFILsNT_18=@protonmail.com>
Message-ID: <20200519205643.GE19768@SDF.ORG>

On Tue, May 19, 2020 at 08:43:35PM +0000, colecmac at protonmail.com wrote:
> On Tuesday, May 19, 2020 7:45 AM, Jason McBrayer <jmcbray at carcosa.net> wrote:
> 
> > solderpunk solderpunk at SDF.ORG writes:
> >
> > > On Tue, May 19, 2020 at 04:42:15AM +0000, Zoey Riordan wrote:
> > > With the arrival of Vostok alongside the in-development clients Soyuz
> > > (gemini://gemini.circumlunar.space/users/dominikd/) and Voskhod (JMB, is
> > > there a link for Voskhod yet?), we are just about out of names to borrow
> > > from the classic era of Soviet manned spaceflight! :) I guess Salyut is
> > > left.
> >
> > I realize there's not, and the code is only on the ThinkPad whose power
> > adapter let out the magic smoke, so there won't be until the replacement
> > power adapter arrives. It's kind of in limbo for now, because I need to
> > figure out how Gnome Builder interacts with PyGTK better.
> 
> Did you mix up your emails? I'm very confused :P

No mix up, he's explaining why I couldn't find a link for his Voskhod
project.

Cheers,
Solderpunk

From me at ecmelberk.com  Tue May 19 21:58:14 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Tue, 19 May 2020 23:58:14 +0300
Subject: [ANN] Moonlander: The fanciest Gemini client in the entire
 solar system
In-Reply-To: <Egy8kp6C94w4i6Pnyd3l64WZRFyvhN6rG2kYpCCWiu6Oz3b44Evr04pvt2MDDBz_wH3T5Dg1xWPQPKsT_porHb5pcTidlaOLQsE4W3HDs8g=@protonmail.com>
References: <20200519154300.64815d02@socimda>
 <Egy8kp6C94w4i6Pnyd3l64WZRFyvhN6rG2kYpCCWiu6Oz3b44Evr04pvt2MDDBz_wH3T5Dg1xWPQPKsT_porHb5pcTidlaOLQsE4W3HDs8g=@protonmail.com>
Message-ID: <20200519235814.78ec361d@socimda>

On Tue, 19 May 2020 20:52:02 +0000
colecmac at protonmail.com wrote:

> Wow, that screenshot is looking good! I'm excited for the planned
> markdown and image rendering. 

Thanks :)

> Feel free to send an update to us as more features are added. 

Will do! (Assuming I don't get bored and stop working on it)

> Also come join us on IRC: #gemini at tilde.chat (irc.tilde.chat is
> the actual server).

Already there (admicos)


From me at ecmelberk.com  Tue May 19 22:00:17 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Wed, 20 May 2020 00:00:17 +0300
Subject: [ANN] Moonlander: The fanciest Gemini client in the entiresolar
 system
In-Reply-To: <7E9E467C-AD34-405D-BBC3-88EBA84809FD@sdf.org>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
 <7E9E467C-AD34-405D-BBC3-88EBA84809FD@sdf.org>
Message-ID: <20200520000017.68e7f84f@socimda>

On Tue, 19 May 2020 11:40:45 -0700
peteyboy at sdf.org wrote:

> Cool! I just got Castor and mcross installed last night, but neither
> works with alternate ports (not 1965) which I've had to host my
> jetforce server on. So im stuck playing with authoring using V-98to
> view. So if you could make sure gemini://url:port works, I'd love it.

It *should* work. If you have an example server with a different port,
please let me know and I'll try to make it work if it doesn't.

From solderpunk at SDF.ORG  Tue May 19 22:05:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 21:05:12 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <ca67c95b4f3fe36c44148d930db0d299@tilde.ninja>
References: <PzzIb-EGPImPJrodUQM5MOFKEWZHWAyF0noU2tT2LkikCr3mWjAsq-JftohmGxyINAHvcrLgNI57ieJhzv9XtrTr9HxgDLXt17sN7Ubwuzc=@protonmail.com>
 <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
 <lz5zcstmab.fsf@bs-mbpr348.d.ethz.ch>
 <ca67c95b4f3fe36c44148d930db0d299@tilde.ninja>
Message-ID: <20200519210512.GF19768@SDF.ORG>

On Tue, May 19, 2020 at 08:12:17PM +0000, jan6 at tilde.ninja wrote:
 
> while it's complicating the spec a little, it'd be quite useful for some people...

Yeah, but *everything*'s quite useful for some people, and individually
each little useful thing is not *that* much more complicated, and then
one day...

Which is not to say nothing like this will ever happen, I actually think
that really good multilingual support is a lot more important than many
other things and might be worth the cost.  But I've definitely changed
my mind that this is a quick and easy thing which can be snuck in along
with defining lining breaks and SNI and stuff.  We can take our time to
figure out a good solution to this.

Cheers,
Solderpunk

From felix at masterq32.de  Tue May 19 22:08:09 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 19 May 2020 23:08:09 +0200
Subject: Underspecified part in the Specification
Message-ID: <e7d0a3e8-ec43-87a2-cd0a-4ba5e1f4e685@masterq32.de>

Hey List and especially solderpunk!

I just started to read on the certificate stuff and looked at
Astrobotany [0] as an example application using client certificates.

Their process looks like this:
1. Generate private key
2. Generate a certificate request
3. Submit your CSR via HTTPS to astrobotany, they will then send you a
signed certificate
4. Use that certificate to authenticate at astrobotany

Now i wonder:
Is this the planned way everyone should go? What about self-signed
client certificates?

I would expect Gemini to use self-signed client certificates for
identitiy management, and even more for transient certificates.

The documentation on client certificates is mainly ?1.4.3 and the status
codes 61 and 62, but no word about how to obtain these client certificates.

I think this needs some clarification on how to handle this

Regards
xq

[0] gemini://astrobotany.mozz.us/

From solderpunk at SDF.ORG  Tue May 19 22:12:18 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 21:12:18 +0000
Subject: Underspecified part in the Specification
In-Reply-To: <e7d0a3e8-ec43-87a2-cd0a-4ba5e1f4e685@masterq32.de>
References: <e7d0a3e8-ec43-87a2-cd0a-4ba5e1f4e685@masterq32.de>
Message-ID: <20200519211218.GG19768@SDF.ORG>

Howdy,

Yes, massively, you are right.  I mentioned this in my recent gemlog
post on TLS, please see:
gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/tls-musings.gmi

This part of the spec needs tightening up, and since we actually have
real world implementations of an application using client certificates I
consider this a higher priority than some other stuff, which is only a
possible future concern yet.

I expect most of the major changes to come shortly after the spec
unfreeze will relate to client certificates.

I have been thinking about the matter and have coded up lots of client
certificate related stuff in AV-98 in the past week or so to demonstrate
concrete ideas about how we might want this to work.

Please be patient until this coming weekend when I'll do a release and
make some posts about this. :)

Cheers,
Solderpunk

On Tue, May 19, 2020 at 11:08:09PM +0200, Felix Quei?ner wrote:
> Hey List and especially solderpunk!
> 
> I just started to read on the certificate stuff and looked at
> Astrobotany [0] as an example application using client certificates.
> 
> Their process looks like this:
> 1. Generate private key
> 2. Generate a certificate request
> 3. Submit your CSR via HTTPS to astrobotany, they will then send you a
> signed certificate
> 4. Use that certificate to authenticate at astrobotany
> 
> Now i wonder:
> Is this the planned way everyone should go? What about self-signed
> client certificates?
> 
> I would expect Gemini to use self-signed client certificates for
> identitiy management, and even more for transient certificates.
> 
> The documentation on client certificates is mainly ?1.4.3 and the status
> codes 61 and 62, but no word about how to obtain these client certificates.
> 
> I think this needs some clarification on how to handle this
> 
> Regards
> xq
> 
> [0] gemini://astrobotany.mozz.us/

From nicole at strega-nil.co  Tue May 19 22:12:34 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Tue, 19 May 2020 21:12:34 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519210512.GF19768@SDF.ORG>
References: <PzzIb-EGPImPJrodUQM5MOFKEWZHWAyF0noU2tT2LkikCr3mWjAsq-JftohmGxyINAHvcrLgNI57ieJhzv9XtrTr9HxgDLXt17sN7Ubwuzc=@protonmail.com>
 <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
 <lz5zcstmab.fsf@bs-mbpr348.d.ethz.ch>
 <ca67c95b4f3fe36c44148d930db0d299@tilde.ninja>
 <20200519210512.GF19768@SDF.ORG>
Message-ID: <niHIklje8GrPTYmdPZrwxN9mzPBL4bA1PqjOUfSiqmCZq6SKrPHP06Jq9LArcolhXdr35rv8TInVaxXrOcWzu3Mus78-hojY6YlI3XzRokc=@strega-nil.co>

I will say that "allowing someone to send a lang flag per-page" gets you the vast majority of the way there, and is a necessity. Changing languages is an addition to think about later, imo.

Nicole

-------- Original Message --------
On May 19, 2020, 14:05, solderpunk wrote:

> On Tue, May 19, 2020 at 08:12:17PM +0000, jan6 at tilde.ninja wrote:
>
>> while it's complicating the spec a little, it'd be quite useful for some people...
>
> Yeah, but *everything*'s quite useful for some people, and individually
> each little useful thing is not *that* much more complicated, and then
> one day...
>
> Which is not to say nothing like this will ever happen, I actually think
> that really good multilingual support is a lot more important than many
> other things and might be worth the cost. But I've definitely changed
> my mind that this is a quick and easy thing which can be snuck in along
> with defining lining breaks and SNI and stuff. We can take our time to
> figure out a good solution to this.
>
> Cheers,
> Solderpunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/8abdcf74/attachment.htm>

From felix at masterq32.de  Tue May 19 22:17:32 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 19 May 2020 23:17:32 +0200
Subject: Underspecified part in the Specification
In-Reply-To: <20200519211218.GG19768@SDF.ORG>
References: <e7d0a3e8-ec43-87a2-cd0a-4ba5e1f4e685@masterq32.de>
 <20200519211218.GG19768@SDF.ORG>
Message-ID: <a0a02a85-791c-22b9-1508-621c30c34bf4@masterq32.de>

Hey,

> Yes, massively, you are right.  I mentioned this in my recent gemlog
> post on TLS, please see:
> gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/tls-musings.gmi
It might be that your server is currently unreachable, i can't connect
to port 1965 with IPv4 :(
> Please be patient until this coming weekend when I'll do a release and
> make some posts about this. :)
Okay, sure! I think i'll need the time to understand all of this anyways :D

Regards
xq

From solderpunk at SDF.ORG  Tue May 19 22:21:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 19 May 2020 21:21:21 +0000
Subject: Underspecified part in the Specification
In-Reply-To: <a0a02a85-791c-22b9-1508-621c30c34bf4@masterq32.de>
References: <e7d0a3e8-ec43-87a2-cd0a-4ba5e1f4e685@masterq32.de>
 <20200519211218.GG19768@SDF.ORG>
 <a0a02a85-791c-22b9-1508-621c30c34bf4@masterq32.de>
Message-ID: <20200519212121.GH19768@SDF.ORG>

On Tue, May 19, 2020 at 11:17:32PM +0200, Felix Quei?ner wrote:
> Hey,
> 
> > Yes, massively, you are right.  I mentioned this in my recent gemlog
> > post on TLS, please see:
> > gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/tls-musings.gmi
> It might be that your server is currently unreachable, i can't connect
> to port 1965 with IPv4 :(

Whoops, sorry, it literally *just* went down (I navigated to that post
to get the URL before sending the email).  Honestly, who wrote this
buggy thing?!

It's back up now.

Cheers,
Solderpunk

From colecmac at protonmail.com  Tue May 19 22:45:36 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 19 May 2020 21:45:36 +0000
Subject: A new kind of client torture test
Message-ID: <-RheTfqDZiUHsymRHrnQPFKFCu5ai3SqgvGCwJF2NwIXbukLXU42xIfUVibMjP3sJuFPw3oG1ajA3mCqmeZsj5Fbb6sJhy7k3AGw-uOQZJQ=@protonmail.com>

Hello,

I've noticed that my about page[1] has caused issues in some browsers, graphical
ones especially, like mcross[2] or moonlander[3]. My page contains some advanced
Unicode, like spaces that have been accented with many many diacritics, as well
as emojis. This is a good way to test if your client works with unicode, it seems.

Happy to report that Bombadillo and Castor display it fine though!


1: gemini://makeworld.gq/about.gmi
2: https://git.sr.ht/~nhanb/mcross
3: https://sr.ht/~admicos/moonlander/

From defdefred at protonmail.com  Tue May 19 22:50:51 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 19 May 2020 21:50:51 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <niHIklje8GrPTYmdPZrwxN9mzPBL4bA1PqjOUfSiqmCZq6SKrPHP06Jq9LArcolhXdr35rv8TInVaxXrOcWzu3Mus78-hojY6YlI3XzRokc=@strega-nil.co>
References: <PzzIb-EGPImPJrodUQM5MOFKEWZHWAyF0noU2tT2LkikCr3mWjAsq-JftohmGxyINAHvcrLgNI57ieJhzv9XtrTr9HxgDLXt17sN7Ubwuzc=@protonmail.com>
 <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
 <lz5zcstmab.fsf@bs-mbpr348.d.ethz.ch>
 <ca67c95b4f3fe36c44148d930db0d299@tilde.ninja>
 <20200519210512.GF19768@SDF.ORG>
 <niHIklje8GrPTYmdPZrwxN9mzPBL4bA1PqjOUfSiqmCZq6SKrPHP06Jq9LArcolhXdr35rv8TInVaxXrOcWzu3Mus78-hojY6YlI3XzRokc=@strega-nil.co>
Message-ID: <zg8sjdFMr6r3buH4Z9X0mpcICEQkhZet9p2Ys71AXa0zMzoxfA4be1vv_InhrsR9GXLnxWw8BhWE_R6lbsyyyZc1lR7qa3orfZG5tQbJNRE=@protonmail.com>

I wonder how a native RTL reader should format a gemini document?
Should
#Big Title
Become:
eltiT giB#
or:
#eltiT giB
:-)
Regards,
freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200519/7e78a644/attachment.htm>

From julien at typed-hole.org  Tue May 19 22:58:30 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Tue, 19 May 2020 23:58:30 +0200
Subject: [ANN] Moonlander: The fanciest Gemini client in the entiresolar
 system
In-Reply-To: <20200520000017.68e7f84f@socimda>
References: <20200520000017.68e7f84f@socimda>
Message-ID: <9F1C496C-BFDB-4317-8B41-A7FA3E3053D9@typed-hole.org>



> Le 19 mai 2020 ? 23:01, Ecmel Berk Canl?er <me at ecmelberk.com> a ?crit :
> 
> ?On Tue, 19 May 2020 11:40:45 -0700
> peteyboy at sdf.org wrote:
> 
>> Cool! I just got Castor and mcross installed last night, but neither
>> works with alternate ports (not 1965) which I've had to host my
>> jetforce server on. So im stuck playing with authoring using V-98to
>> view. So if you could make sure gemini://url:port works, I'd love it.
> 
Pushed Castor 0.8.8 that should fix this issue.

From invis at park-city.club  Tue May 19 23:42:24 2020
From: invis at park-city.club (invis at park-city.club)
Date: Tue, 19 May 2020 22:42:24 +0000
Subject: [ANN] Twin Peaks: A graphical Gemini browser written in C#
Message-ID: <a7bac10e51d1463617323dd81b196fe6@park-city.club>

Hello.

I was getting a little tired of browsing Geminispace from a SSH session or a web browser on my Windows machine, so last weekend I whipped up really quick a new Gemini client: https://github.com/invisibleup/twinpeaks/releases

It's still pretty rough, as I've only thrown about two days of effort into it. (For instance, the link rendering right now is pretty broken, because of a bug in the rich text renderer I'm using where it doesn't handle links properly.) But it's been mostly fine with every page I've thrown at it. It mostly passes the torture test, so I consider that an accomplishment. It's amazing that I can make a perfectly adequate browser *this* quickly, really.

Right now it only supports text/gemini documents in UTF-8, but I eventually want to add support for Markdown, plain text, images, and binary data. Gopher support would be cool too. I also eventually want to add customization options for the home page, the colors, the fonts, etc. Maybe have per-site themes? That might be neat.

Let me know what you think.

-- InvisibleUp (gemini://park-city.club/~invis)

-- Email domain proudly hosted at https://migadu.com


From peteyboy at SDF.ORG  Wed May 20 01:34:47 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Wed, 20 May 2020 00:34:47 +0000 (UTC)
Subject: [ANN] Moonlander: The fanciest Gemini client in the entiresolar
 system
In-Reply-To: <20200520000017.68e7f84f@socimda>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
 <7E9E467C-AD34-405D-BBC3-88EBA84809FD@sdf.org>
 <20200520000017.68e7f84f@socimda>
Message-ID: <alpine.NEB.2.21.2005200034150.3672@otaku.sdf.org>

It does work! Very nice! I appreciate it!

On Wed, 20 May 2020, Ecmel Berk Canl?er wrote:

> Date: Tue, 19 May 2020 21:00:17
> From: Ecmel Berk Canl?er <me at ecmelberk.com>
> To: peteyboy at sdf.org
> Cc: "A protocol that is slightly more complex than gopher, but significantly s
>     impler than HTTP" <gemini at lists.orbitalfox.eu>
> Subject: Re: [ANN] Moonlander: The fanciest Gemini client in the entiresolar
>     system
> 
> On Tue, 19 May 2020 11:40:45 -0700
> peteyboy at sdf.org wrote:
>
>> Cool! I just got Castor and mcross installed last night, but neither
>> works with alternate ports (not 1965) which I've had to host my
>> jetforce server on. So im stuck playing with authoring using V-98to
>> view. So if you could make sure gemini://url:port works, I'd love it.
>
> It *should* work. If you have an example server with a different port,
> please let me know and I'll try to make it work if it doesn't.
>

peteyboy at sdf.org
SDF Public Access UNIX System - http://sdf.org

From peteyboy at SDF.ORG  Wed May 20 01:46:52 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Wed, 20 May 2020 00:46:52 +0000 (UTC)
Subject: Gemini Digest, Vol 10, Issue 54
In-Reply-To: <mailman.160.1589928150.533.gemini@lists.orbitalfox.eu>
References: <mailman.160.1589928150.533.gemini@lists.orbitalfox.eu>
Message-ID: <alpine.NEB.2.21.2005200036240.3672@otaku.sdf.org>

On Tue, 19 May 2020, gemini-request at lists.orbitalfox.eu wrote:

> Message: 8
> Date: Tue, 19 May 2020 23:58:30 +0200
> From: Julien Blanchard <julien at typed-hole.org>
> To: "A protocol that is slightly more complex than gopher, but
> 	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
> Subject: Re: [ANN] Moonlander: The fanciest Gemini client in the
> 	entiresolar system
> Message-ID: <9F1C496C-BFDB-4317-8B41-A7FA3E3053D9 at typed-hole.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
>> Le 19 mai 2020 ? 23:01, Ecmel Berk Canl?er <me at ecmelberk.com> a ?crit :
>>
>> ?On Tue, 19 May 2020 11:40:45 -0700
>> peteyboy at sdf.org wrote:
>>
>>> Cool! I just got Castor and mcross installed last night, but neither
>>> works with alternate ports (not 1965) which I've had to host my
>>> jetforce server on. So im stuck playing with authoring using V-98to
>>> view. So if you could make sure gemini://url:port works, I'd love it.
>>
> Pushed Castor 0.8.8 that should fix this issue.
>
> ------------------------------
Wow, thank you! Such fast turnaround! Yours is the nicest looking of all 
the GUI browsers, to my eye.

However, I may be doing something wrong, but I did a 'git pull' and a 
'make install' and the executable seemed to be updated, but I'm not 
getting the fix to work. I get an error dialog "Could not connect to 
peteyboy.freeshell.org:32056" when I put 
"gemini://peteyboy.freeshell.org:32056" in the address bar.  I've left the 
server up in my shell with tmux in case you want to point to it yourself. 
I hacked gcat (which is fixed to 1965) and tried moonlander from my same 
local machine (not on SDF), and they work, so I don't think that it's my 
server (previously I was using solderpunk's kiosk to run AV-98, which 
should also be external to my sever and can get pages from it).

Anyway, thanks for what you are doing, Castor is really cool, and I don't 
know how important it is for dorks like me using public access shared unix 
servers need to be supported...

peteyboy at sdf.org
SDF Public Access UNIX System - http://sdf.org

From peteyboy at SDF.ORG  Wed May 20 02:00:56 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Wed, 20 May 2020 01:00:56 +0000 (UTC)
Subject: [ANN] Moonlander: The fanciest Gemini client in the entiresolar
 system
In-Reply-To: <20200520000017.68e7f84f@socimda>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
 <7E9E467C-AD34-405D-BBC3-88EBA84809FD@sdf.org>
 <20200520000017.68e7f84f@socimda>
Message-ID: <alpine.NEB.2.21.2005200057280.3672@otaku.sdf.org>

Oh, at least for awhile, I've left my server running in a tmux session, 
accessible via: gemini://peteyboy.freeshell.org:32056

If I keep that jetforce server running, I probably will need to put in a 
cron job with a dtach session or something.

On Wed, 20 May 2020, Ecmel Berk Canl?er wrote:

> Date: Tue, 19 May 2020 21:00:17
> From: Ecmel Berk Canl?er <me at ecmelberk.com>
> To: peteyboy at sdf.org
> Cc: "A protocol that is slightly more complex than gopher, but significantly s
>     impler than HTTP" <gemini at lists.orbitalfox.eu>
> Subject: Re: [ANN] Moonlander: The fanciest Gemini client in the entiresolar
>     system
> 
> On Tue, 19 May 2020 11:40:45 -0700
> peteyboy at sdf.org wrote:
>
>> Cool! I just got Castor and mcross installed last night, but neither
>> works with alternate ports (not 1965) which I've had to host my
>> jetforce server on. So im stuck playing with authoring using V-98to
>> view. So if you could make sure gemini://url:port works, I'd love it.
>
> It *should* work. If you have an example server with a different port,
> please let me know and I'll try to make it work if it doesn't.
>

peteyboy at sdf.org
SDF Public Access UNIX System - http://sdf.org

From lel at envs.net  Wed May 20 12:33:50 2020
From: lel at envs.net (lel)
Date: Wed, 20 May 2020 07:33:50 -0400
Subject: [ANN] Announcing `commie.space`...
Message-ID: <20200520113350.GA2116544@spektr>

Howdy gang,

Don't think I've posted to this list since I got involved when it became
apparent that with the way discussions were going text/gemini was officially
going to be hardwrapped if someone didn't step in to support the one or two
people arguing against it. So something like 3-4 months(??).

I've had accounts on most of the tildes with gemini servers running, and I was
apparently the first person to have a gemini.circumlunar.space account, but
I've never had a server of my own.

uNtIl NoW!

Last night after zooming with friends while blackout drunk I apparently
purchased the domain name `commie.space`, and also spun up a debian VPS, so I
woke up today to a fully-DNS-propagated server. I also see that molly-brown
was installed. I've been meaning to do something like this, so I can only
assume it was supposed to be for gemini. Many thanks to the gemini community
and smirnoff for the $20/month recurring draw from my bank account.

That being said, now that the trigger's been pulled, I plan to keep this thing
up, so this morning I actually set molly brown up and quickly drafted up a
couple blog (flight log? capsule? glog?) posts, one of which explains what the
hell I even plan to put there. At the moment, the idea mostly revolves around
wild stories about working retail during the coronavirus pandemic. Maybe I'll
write hot takes about the current DiScOuRsE on left twitter every once in a
while too. And what would a gemini server be without the stereotypical meta
content about gemini?

I know it's not some wonderful, novel, interesting use for the protocol, but I
figure if I say something here, it might end up in the gemini.circumlunar.space
server list, and if that happens, it will probably get indexed by gus, so it
will actually be in gemini space. And if that happens, it'll probably force me
to actually keep up posting to it.

Anyway, that's the deal, I guess there's nothing more to say.

Thanks a lot,
lel

From jmcbray at carcosa.net  Wed May 20 14:07:21 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 20 May 2020 09:07:21 -0400
Subject: [ANN] Twin Peaks: A graphical Gemini browser written in C#
In-Reply-To: <a7bac10e51d1463617323dd81b196fe6@park-city.club>
 (invis@park-city.club's message of "Tue, 19 May 2020 22:42:24 +0000")
References: <a7bac10e51d1463617323dd81b196fe6@park-city.club>
Message-ID: <874ksa92ly.fsf@dorothy.carcosa.net>

invis at park-city.club writes:

> I was getting a little tired of browsing Geminispace from a SSH
> session or a web browser on my Windows machine, so last weekend I
> whipped up really quick a new Gemini client:
> https://github.com/invisibleup/twinpeaks/releases

Very nice! I've been using elpher on my Windows machines, but it's great
to see a graphical browser for Windows.

Someone needs to step up for MacOS now.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Wed May 20 14:08:57 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 20 May 2020 09:08:57 -0400
Subject: [ANN] Announcing `commie.space`...
In-Reply-To: <20200520113350.GA2116544@spektr> (lel@envs.net's message of
 "Wed, 20 May 2020 07:33:50 -0400")
References: <20200520113350.GA2116544@spektr>
Message-ID: <87zha27nyu.fsf@dorothy.carcosa.net>

lel <lel at envs.net> writes:

> Last night after zooming with friends while blackout drunk I apparently
> purchased the domain name `commie.space`, and also spun up a debian VPS, so I
> woke up today to a fully-DNS-propagated server. I also see that molly-brown
> was installed.

Noice. I actually happened upon your gemlog before seeing this post,
because I was browsing the known servers on GUS. I would love to hear
stories of retail during the pandemic.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From fabrixxm at kirgroup.net  Wed May 20 14:14:13 2020
From: fabrixxm at kirgroup.net (Fabio)
Date: Wed, 20 May 2020 15:14:13 +0200
Subject: Any Windows clients?
In-Reply-To: <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel@mx.sdf.org>
References: <edf3913bb7ac536ea1e05d8710199e2e.squirrel@mx.sdf.org>
 <2TJFAQ.QMXFTMSB42CD2@kirgroup.net>
 <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel@mx.sdf.org>
Message-ID: <20ddb17c38539f68f4fbf89f5fab0eb8c4b657ae.camel@kirgroup.net>

Il giorno mar, 19/05/2020 alle 10.12 -0500, Dunderpate ha scritto:
> Thanks for the recommendation! I just had a chance to look into this
> last
> night and, unfortunately I'm not that comfortable creating a Qt
> account
> just to install the tooling required to run qmake :/ I might be
> missing
> something that allows me to bypass the account creation, but it's a
> principle thing I guess LOL

you should not need any qt account to use the opensource edition.
I'm not on windows so I can't check right now, but last time I
installed Qt Creator on win I just downloaded the installer and skipped
any step regarding qt accounts. But things may have changed.


> The client itself seems nice enough though,
> and if they had pre-compiled builds I'd certainly use one of 'em.
> 
> Thanks again :D

I'll try to cross-compile it. Sounds funny :)


From bob at freedombone.net  Wed May 20 17:14:01 2020
From: bob at freedombone.net (Bob Mottram)
Date: Wed, 20 May 2020 17:14:01 +0100
Subject: [ANN] Announcing `commie.space`...
In-Reply-To: <20200520113350.GA2116544@spektr>
References: <20200520113350.GA2116544@spektr>
Message-ID: <20200520161401.GA513@freedombone.net>

On Wed, May 20, 2020 at 07:33:50AM -0400, lel wrote:
>I've had accounts on most of the tildes with gemini servers running, and I was
>apparently the first person to have a gemini.circumlunar.space account, but
>I've never had a server of my own.
>
>uNtIl NoW!


Congrats, and that's a great domain name.

From dominik.dalek at thaumatec.com  Wed May 20 17:20:25 2020
From: dominik.dalek at thaumatec.com (Dominik Dalek)
Date: Wed, 20 May 2020 18:20:25 +0200
Subject: Status codes
Message-ID: <CACVUgn__fRRX+u=8sB07pqyY_sHHHAT4gpQ=x4U9nX1w+4VO-Q@mail.gmail.com>

Howdy!

I'm working on my own client and figured I'd write on the status codes.
This is something that, I feel, can be simplified. My comments will be
based on two assumptions:
1. Things should be as simple as possible, but not simpler
2. Complexity is a source of bugs and exploits[1]

I understand that there may be some aversion to changing things that
are already pretty well established, but I hope it's not too late and
my arguments will be at least a little bit convincing. :)

Suggestion #0: Strengthen language around status codes

It is softly stated that the second digit is an extension to the status
code. Then valid first digits are laid out. Upon first reading I found
this confusing so I would welcome rephrasing this into something that
states explicitly:
1. All clients and servers must at the very least recognize status codes
10, 20, 30, 40, 50 and 60.
2. Any xy code not recognized by the client can be safely interpreted
as x0 (e.g. 21 can be safely treated as 20, and 45 can be treated like
40 w/o consequences)
3. The status codes section shouldn't use single digits but the core
codes (10, 20, etc.) or as masks (1y, 2y, etc.)
4. Replace the unique phrasing of "range of codes" in section 1.3.1 with
"status code category" used elsewhere (range felt like a broader term
than category and caused me some time to figure out if I'm missing
something important).

Suggestion #1: Remove proxy related codes

Current spec is already something that is likely to be two IETF RFCs
in the future (protocol and document format). Adding proxy support into
the mix complicates things even further. Problems with proxy IMO start
with the fact that it's not clear (to me at least) what sort of proxy
gemini would benefit from; nor is it stated in the spec.

Classical reverse proxy roles of load balancing and caching are possible
but I don't see how these can be implemented w/o expiration mechanisms
added to the spec. It could be done, but I think it should be tackled
in a separate RFC. Forwarding proxy, anonymizing or otherwise is
a possibility but, again, I think this should be an extension that
ends up in a separate spec.

There's also a lot of work that has to be done for the proxy to support
client certificates in various setups (when we want anonymity or not,
where we deal with session certs or permanent ones, and so on), how
various error paths should perform, etc. It's a lot of work and would
definitely need fairly stable clients and some reference proxy
implementation to validate assumptions about what could work.

How server and client certs are handled in the proxy scenario is also
something that I don't think is trivial and as such would require some
legwork to get up and running. So, yeah, I'd cut any mention of proxy
at the moment and with that's codes 43 and 53.

Suggestion #2: Deduplicate client cert errors

Only a single client cert can be sent when establishing the communication
channel. My mental model (correct me if I'm wrong!) is that transient
cert is a session substitute and permanent cert is authentication
mechanism (roughly speaking at least).

Current spec has 3 cert request mechanisms, 3 rejection codes and
a revocation code. This creates numerous corner cases for clients
to handle properly, e.g.
* what do you do if you get 21 in response to a request that included
your permanent key? I sure hope the browser doesn't actually delete
the permanent key from the store :)
* what do you do if you get 64 but your cert is not from the future?
* what do you do if you get 65 but your cert hasn't expired?

I'd like to see a single "client certificate rejected" code eliminating
responses that would potentially make no sense.

I feel that differentiating between the types of rejection opens some
opportunity for oracle attacks (i.e. rogue clients can inspect server
cert processing bugs by observing how responses differ for various
crafted requests). In essence I'd cut 64 and 65.

Suggestion #3: Change end of cert session (21) into a redirection

This will probably be a very controversial one but the way I see it
the end of session typically results in the redirection. This lets you
chain requests on logout in a way that enables permanent client key
delivery or temporary key replacement. With current design you serve
a page in a response to a request that displays something and asks
the client to delete the transient cert. If you want to re-establish
some sort of validation from the client, you need a manual intervention
from the user to do that. I'm not sure if my explanation is clear enough,
I can try and expand upon it if needed.

Suggestion #4: Merge different types of server error to prevent leaking
what happened under the hood

HTTP 500 is often seen as an indication of something wrong in the server
application logic. This would be the primary attack vector for someone
trying to compromise the server (even if only DOS it). I don't think it
makes sense to differentiate codes 40-42 with the exception maybe of
a planned maintenance. Basically I'm sort of allergic to disclosing
information about the server state.

The counter argument is likely going to be: there's reason not to give
extra details.

To which I say ;) sure, but you can already do that with <META>.

Suggestion #5: A comment, really

5x codes are by design permanent errors but 51 (HTTP 404 equivalent) is
actually a temporary problem according to the spec.
In fact this is precisely what differentiates it from HTTP 410 GONE
(gemini 52). So there seems to be a design error here but I don't really
know what the correct solution is. Either 5x aren't really permanent
errors (how would they be called then?) or 51 shouldn't be a 5x error
to begin with.

This sums up my thoughts about the status codes. I know this reads very
much like "too complex, cut!" and that kinda is exactly that. But if you
can make things simpler, why not do it? :)

Thanks for reading this, cheers!
-Dom

[1] There's a neat research on exploiting HTTP status codes:
https://www.youtube.com/watch?v=4OztMJ4EL1s

From solderpunk at SDF.ORG  Wed May 20 18:21:45 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 20 May 2020 17:21:45 +0000
Subject: [ANN] New Gemfeed release
Message-ID: <20200520172145.GA27836@SDF.ORG>

Hi everyone,

I just pushed Gemfeed 1.1.0 to PyPI, so you can upgrade or install with
pip.

Having tried to get a few people setup with Gemfeed it has become
apparent that using the creation time from the filesystem to set update
time is far too error-prone.  As such, if a .gmi file's filename begins
with an ISO 8601 datestamp (e.g. 2020-05-20), Gemfeed will now recognise
this and use that date (with a time of midnight UTC) as the update time
in the feed.  It seems that several people are already using exactly
this datestamp format as either a complete filename or as a prefix in
their filenames, so hopefully this makes setting up a feed easier for
many people.

Remember that if you set up an Atom feed for your Gemini content (using
Gemfeed or otherwise), let me know about it and I can add it to the
CAPCOM aggregator!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed May 20 18:32:32 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 20 May 2020 17:32:32 +0000
Subject: [ANN] Announcing `commie.space`...
In-Reply-To: <20200520113350.GA2116544@spektr>
References: <20200520113350.GA2116544@spektr>
Message-ID: <20200520173232.GA27888@SDF.ORG>

On Wed, May 20, 2020 at 07:33:50AM -0400, lel wrote:
 
> I know it's not some wonderful, novel, interesting use for the protocol, but I
> figure if I say something here, it might end up in the gemini.circumlunar.space
> server list, and if that happens, it will probably get indexed by gus

GUS tends to find stuff before I do these days. :)  But you're on the
server list now too anyway, so you'd better keep posting!

Cheers,
Solderpunk

From koodikone at cybertronica.org  Wed May 20 19:23:11 2020
From: koodikone at cybertronica.org (koodikone)
Date: Wed, 20 May 2020 18:23:11 +0000
Subject: [ANN] cybertronica.org - new gemini space
Message-ID: <_-Mp7W5rzmB2LJ7wCcfBl_HnAz_55UdK3iyY1b85B06aDoEehoSeO6JUbG3tH6A758Dob8f6vJuYgPQn23hQTEYFizkv4ttyPhET5168szA=@cybertronica.org>

Greetings all,

I created a *log gemini space at: gemini://cybertronica.org

It is running on Molly Brown and FreeBSD 12.1

I am really excited about gemini and the speed it is forming right now. Cant wait for developing some dynamic stuff on it later on.

koodikone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200520/396e4789/attachment.htm>

From colecmac at protonmail.com  Wed May 20 19:39:15 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 20 May 2020 18:39:15 +0000
Subject: [ANN] cybertronica.org - new gemini space
In-Reply-To: <_-Mp7W5rzmB2LJ7wCcfBl_HnAz_55UdK3iyY1b85B06aDoEehoSeO6JUbG3tH6A758Dob8f6vJuYgPQn23hQTEYFizkv4ttyPhET5168szA=@cybertronica.org>
References: <_-Mp7W5rzmB2LJ7wCcfBl_HnAz_55UdK3iyY1b85B06aDoEehoSeO6JUbG3tH6A758Dob8f6vJuYgPQn23hQTEYFizkv4ttyPhET5168szA=@cybertronica.org>
Message-ID: <vjuzWwMQhnj5pQrwozdLYdTUyFzEpDIlsaFncnR1ZDCrCXryIzYYKcwN554bgp9RXJzNKxzyp4uAHjnUBDTogYsvDgcEWpygAxEXT8tc06s=@protonmail.com>

Nice site! Although the "best viewed in terminal browsers" text reminds me of
"This site is best viewed in Chrome" warnings. Maybe wrap all the text in a
preformatted block so it will display the same in graphical browsers too?


> Cant wait for developing some dynamic stuff on it later on.

I've been working on it :)
With luck they'll be an announcement about it this week or weekend.

makeworld

??????? Original Message ???????
On Wednesday, May 20, 2020 2:23 PM, koodikone <koodikone at cybertronica.org> wrote:

> Greetings all,
>
> I created a *log gemini space at:?gemini://cybertronica.org
>
> It is running on?Molly Brown and?FreeBSD 12.1
>
> I am really excited?about gemini and the speed it is forming right now. Cant wait for developing some dynamic stuff on it?later on.
>
> koodikone



From koodikone at cybertronica.org  Wed May 20 20:03:04 2020
From: koodikone at cybertronica.org (koodikone)
Date: Wed, 20 May 2020 19:03:04 +0000
Subject: [ANN] cybertronica.org - new gemini space
In-Reply-To: <vjuzWwMQhnj5pQrwozdLYdTUyFzEpDIlsaFncnR1ZDCrCXryIzYYKcwN554bgp9RXJzNKxzyp4uAHjnUBDTogYsvDgcEWpygAxEXT8tc06s=@protonmail.com>
References: <_-Mp7W5rzmB2LJ7wCcfBl_HnAz_55UdK3iyY1b85B06aDoEehoSeO6JUbG3tH6A758Dob8f6vJuYgPQn23hQTEYFizkv4ttyPhET5168szA=@cybertronica.org>
 <vjuzWwMQhnj5pQrwozdLYdTUyFzEpDIlsaFncnR1ZDCrCXryIzYYKcwN554bgp9RXJzNKxzyp4uAHjnUBDTogYsvDgcEWpygAxEXT8tc06s=@protonmail.com>
Message-ID: <cEgOdnPnkZ0tDWUlQiId0tQ6OI2C0SGbKQuKsryUZ5_W6IC_FowLxe63Z99pjFiVDt5XE3eGnBAN1FNzfqUjTcG2Q_TFso8FqsBwQOiBYk0=@cybertronica.org>

Heh! Sure. I havent just tested yet other clients than bombadillo.

koodikone

On Wed, May 20, 2020 at 20:39, <colecmac at protonmail.com> wrote:

> Nice site! Although the "best viewed in terminal browsers" text reminds me of
> "This site is best viewed in Chrome" warnings. Maybe wrap all the text in a
> preformatted block so it will display the same in graphical browsers too?
>
>> Cant wait for developing some dynamic stuff on it later on.
>
> I've been working on it :)
> With luck they'll be an announcement about it this week or weekend.
>
> makeworld
>
> ??????? Original Message ???????
> On Wednesday, May 20, 2020 2:23 PM, koodikone <koodikone at cybertronica.org> wrote:
>
>> Greetings all,
>>
>> I created a *log gemini space at: gemini://cybertronica.org
>>
>> It is running on Molly Brown and FreeBSD 12.1
>>
>> I am really excited about gemini and the speed it is forming right now. Cant wait for developing some dynamic stuff on it later on.
>>
>> koodikone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200520/e7033f0c/attachment.htm>

From b__m__e at mailfence.com  Wed May 20 20:06:34 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Wed, 20 May 2020 21:06:34 +0200 (CEST)
Subject: gemini-fmt idea
Message-ID: <1135944624.646346.1590001594045@ichabod.co-bxl>

I liked this idea. I use the go toolchain a lot and really appreciate the options available. 
In particular `go fmt`. I think consistent code is readable code.  The same is possible
for `text/gemini` documents.

In that spirit I have made a tool (it is still a work in progress):
https://tildegit.org/sloum/gemini

(I'm open to changing the name, but I liked the idea of running:
     `gemini fmt ./index.gmi`

Current features:

## fmt
* Normalizes a text/gemini document's style
* Reports errors in markup
* Ability to read a piped file from stdin (coming soon)
* Writes to stdout and stderr
* -o flag to write to file (coming very soon)

## get
* Makes a basic request and prints the result (ala curl)
* Can request just the header; defaults to just the body (for easy redirection/piping)
* Ability to pass cert/key pair (coming soon)
* Automatically follows redirects
* Writes to stdout/stderr
* -o flag to write to file (coming very soon)

## spec
* Makes a get request for the spec
* Writes to stdout/stderr
* -o flag to write to file (coming very soon)
* request a subsection of the spec (coming soon)

## version
* prints the tool version

## serve (coming soon)
* will spin up a really simple gemini file server on localhost
* configurable port



If people would like anything else let me know. I dug through the `text/gemini` to make sure
I was getting everything within spec for the formatting. The only place I break from the spec
is w/ regard to alt text on the opening line of a preformatted block (I allow it and format it). I
have included it, but specifically state in the README.md that it is an experimental feature
that may be removed or changed in the future.

Anyway, hopefully it is useful to someone eventually. I have definitely liked the consistent
output that it provides. It lets me write with a lot of extra spacing and organize my thoughts
how I want, but then cleans it all up nicely. :)

From jmcbray at carcosa.net  Wed May 20 20:14:01 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 20 May 2020 15:14:01 -0400
Subject: gemini.el, a basic syntax-highlighting mode
Message-ID: <87o8qimnba.fsf@dorothy.carcosa.net>

Hi. I've written a simple and basic syntax-highlighting mode for
text/gemini for emacs, available at
https://git.carcosa.net/jmcbray/gemini.el. It doesn't support any
multiline constructs yet (e.g. pre blocks), and I'd like to highlight
the different elements of a link differently, which it doesn't do yet,
but it's good enough for basic use at this point. Pull requests from
people who are better at elisp than me are welcome.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From sean at conman.org  Wed May 20 21:15:27 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 20 May 2020 16:15:27 -0400
Subject: Status codes
In-Reply-To: <CACVUgn__fRRX+u=8sB07pqyY_sHHHAT4gpQ=x4U9nX1w+4VO-Q@mail.gmail.com>
References: <CACVUgn__fRRX+u=8sB07pqyY_sHHHAT4gpQ=x4U9nX1w+4VO-Q@mail.gmail.com>
Message-ID: <20200520201527.GI30203@brevard.conman.org>

It was thus said that the Great Dominik Dalek once stated:
> Howdy!

  Hello.

  [bit ol' snip]

> Suggestion #1: Remove proxy related codes

  [ snip ]

> How server and client certs are handled in the proxy scenario is also
> something that I don't think is trivial and as such would require some
> legwork to get up and running. So, yeah, I'd cut any mention of proxy
> at the moment and with that's codes 43 and 53.

  There are at least two Gemini servers that handle proxying to various
degrees (to my knowledge).  I expect changes, but not removal.

> Suggestion #2: Deduplicate client cert errors
> 
> Only a single client cert can be sent when establishing the communication
> channel. My mental model (correct me if I'm wrong!) is that transient
> cert is a session substitute and permanent cert is authentication
> mechanism (roughly speaking at least).
> 
> Current spec has 3 cert request mechanisms, 3 rejection codes and
> a revocation code. This creates numerous corner cases for clients
> to handle properly, e.g.
> * what do you do if you get 21 in response to a request that included
> your permanent key? I sure hope the browser doesn't actually delete
> the permanent key from the store :)
> * what do you do if you get 64 but your cert is not from the future?
> * what do you do if you get 65 but your cert hasn't expired?

  Both of those indicate either

	1) a buggy server
	2) a buggy client
	2) the client clock is incorrect
	3) the server clock is incorrect

  I would only really expect to see these around the time of certificate
expiry (or certificate creation).

> I'd like to see a single "client certificate rejected" code eliminating
> responses that would potentially make no sense.
> 
> I feel that differentiating between the types of rejection opens some
> opportunity for oracle attacks (i.e. rogue clients can inspect server
> cert processing bugs by observing how responses differ for various
> crafted requests). In essence I'd cut 64 and 65.

  I don't agree.  I don't have a fully fleshed out response to the "but muh
security!" argument (well, there is "security through obscurity" isn't) but
it's rooted around the following story:

	Ken Thompson [creator of C and Unix] has an automobile which he
	helped design.  Unlike most automobiles, it has neither speedometer,
	nor gas gage, nor any of the numerous idiot lights which plague the
	modern driver.  Rather, if the driver makes any mistake, a giant "?"
	lights up in the center of the dashboard.  "The experienced driver",
	he says, "will usually know what's wrong."

  I've done tech support and have had to deal with "it's broke---fix it!"
questions with nothing more than that.  I'd rather not do that again.

> Suggestion #3: Change end of cert session (21) into a redirection
> 
> This will probably be a very controversial one but the way I see it
> the end of session typically results in the redirection. This lets you
> chain requests on logout in a way that enables permanent client key
> delivery or temporary key replacement. With current design you serve
> a page in a response to a request that displays something and asks
> the client to delete the transient cert. If you want to re-establish
> some sort of validation from the client, you need a manual intervention
> from the user to do that. I'm not sure if my explanation is clear enough,
> I can try and expand upon it if needed.

  It might help to test against a server that actually implements this.  I
kind of see what you are getting at, and a "logout" mechanism is solely
missing from HTTP (if you are using the actual authentication mechanism and
not HTTP cookies), but I'm not exactly sure what your objection here is.

> Suggestion #4: Merge different types of server error to prevent leaking
> what happened under the hood

  See above---we'll have to agree to disagree on this.

> HTTP 500 is often seen as an indication of something wrong in the server
> application logic. This would be the primary attack vector for someone
> trying to compromise the server (even if only DOS it). I don't think it
> makes sense to differentiate codes 40-42 with the exception maybe of
> a planned maintenance. Basically I'm sort of allergic to disclosing
> information about the server state.

  Nothing to stop a server from just serving up '40' for everything.

> Suggestion #5: A comment, really

  The 40 range of codes map to HTTP 500 range (server errors), and the 50
range of codes map to HTTP 400 range (client errors), and when I first wrote
GLV-1.12556, I used HTTP status codes (because I felt the original status
codes were ... less than optimal), but later solderpunk renamed "client
errors" to "permanent errors" and "server errors" to "temporary errors" (I
think he gave some justification for this, but I don't recall what it was).

> 5x codes are by design permanent errors but 51 (HTTP 404 equivalent) is
> actually a temporary problem according to the spec.
> In fact this is precisely what differentiates it from HTTP 410 GONE
> (gemini 52). So there seems to be a design error here but I don't really
> know what the correct solution is. Either 5x aren't really permanent
> errors (how would they be called then?) or 51 shouldn't be a 5x error
> to begin with.

  It starts to make sense when you realize they were originally server and
client errors.

  But let me be fair, and report back all the errors that GLV-1.12556 can
return (modulo what a CGI scripts and the torture test):

	10	prompt for input
	20	okay
	30	temporary redirect
	31	permament redirect
	40	temporary error
	51	not found
	52	gone
	59	bad request
	61	transient certificate
	62	authorized certificate
	63	certificate rejected
	64	future certificate
	65	expired certificate

  Even my CGI module only returns 40 (if it can't run a CGI script for
whatever reason).  

> This sums up my thoughts about the status codes. I know this reads very
> much like "too complex, cut!" and that kinda is exactly that. But if you
> can make things simpler, why not do it? :)

  It broke.  Fix it. 8-P

  -spc


From solderpunk at SDF.ORG  Wed May 20 21:16:42 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 20 May 2020 20:16:42 +0000
Subject: Status codes
In-Reply-To: <CACVUgn__fRRX+u=8sB07pqyY_sHHHAT4gpQ=x4U9nX1w+4VO-Q@mail.gmail.com>
References: <CACVUgn__fRRX+u=8sB07pqyY_sHHHAT4gpQ=x4U9nX1w+4VO-Q@mail.gmail.com>
Message-ID: <20200520201642.GC27888@SDF.ORG>

> Howdy!

Ahoy!
 
> I understand that there may be some aversion to changing things that
> are already pretty well established, but I hope it's not too late and
> my arguments will be at least a little bit convincing. :)

I do kind of worry that the time to propose changes to "core" stuff is
passed or passing.  New implementations are being written at an
astonishing rate and with so many clients and servers out there, every
substantial change runs the risk of fracturing the nascent Geminispace
into incompatible subspaces.  Stuff that is very poorly implemented,
like client certificiate stuff, doesn't have this risk so much, but
anything fundamental I worry is already more or less "set" now.  It's
the downside to unexpected explosive growth!

> Suggestion #0: Strengthen language around status codes

I'm totally open to rewording parts of the spec to make stuff clearer if
people think what's there now is confusing.  I will take this into
consideration, and please look out for a post to the list sometime this
coming weekend about people being able to more conveniently make
suggestions for changes to the spec and other docs.
 
> Suggestion #1: Remove proxy related codes
 
> Current spec is already something that is likely to be two IETF RFCs
> in the future (protocol and document format).

I like your optimism!!!

> Adding proxy support into
> the mix complicates things even further. Problems with proxy IMO start
> with the fact that it's not clear (to me at least) what sort of proxy
> gemini would benefit from; nor is it stated in the spec.

The most compelling case, IMHO, is proxies which are
protocol-translating gateways.  One of these already exists
(https://tildegit.org/solderpunk/agena), it answers queries for
gopher:// URLs by fetching the original content over gopher and
translating it to text/gemini (which is, by design, very easy to do).
AV-98 can be given the host and port of such a proxy and then it will
automatically use it to follow Gopher links.  Any other client could add
this support to become a combined Gemini-Gopher client without the
author having to write a line of Gopher-related code.

In principle this could be done for HTTP too, but converting websites to
text/gemini is less straight forward (and likely to result in something
ugly to look at anyway because all sorts of irrelevant crap will be
converted too, minus some Herculean effort to detect what the actual
content is).

One could also simply run a straight Gemini proxy which listens on a
port other than 1965 in order to circumvent a filter on outgoing traffic
on that port.

There are definitely useful things which can be done.  Perhaps "proxy"
is a misleading word to have used for this.  I was never imagining
anything super complicated with expiration mechanisms, or a proxy server
which basically acts as a packet router.  They would be very explicitly
MITM operations, and you couldn't use them to access services which
relied on client cetificiatees - which should really end up being a
small minority of content.  Nothing that would actually require anything
in the way of a formal spec.

Should these be called something else?

> Suggestion #2: Deduplicate client cert errors
 
> Only a single client cert can be sent when establishing the communication
> channel. My mental model (correct me if I'm wrong!) is that transient
> cert is a session substitute and permanent cert is authentication
> mechanism (roughly speaking at least).

That model is totally accurate (roughly speaking at least), I'm glad
people get this!
 
> Current spec has 3 cert request mechanisms, 3 rejection codes and
> a revocation code. This creates numerous corner cases for clients
> to handle properly, e.g.
> * what do you do if you get 21 in response to a request that included
> your permanent key? I sure hope the browser doesn't actually delete
> the permanent key from the store :)
> * what do you do if you get 64 but your cert is not from the future?
> * what do you do if you get 65 but your cert hasn't expired?
> 
> I'd like to see a single "client certificate rejected" code eliminating
> responses that would potentially make no sense.

I'm not really convinced these are serious problems.  If you get a 64 or
65 but you know your cert is temporaly, you display an error message
suggesting perhaps the server's clock is faulty.

I mean, what do you do if you get your proposed "client certificate
rejected" status code in response to a request which was made without a
client certificate?

> Suggestion #3: Change end of cert session (21) into a redirection
> 
> This will probably be a very controversial one but the way I see it
> the end of session typically results in the redirection. This lets you
> chain requests on logout in a way that enables permanent client key
> delivery or temporary key replacement. With current design you serve
> a page in a response to a request that displays something and asks
> the client to delete the transient cert. If you want to re-establish
> some sort of validation from the client, you need a manual intervention
> from the user to do that. I'm not sure if my explanation is clear enough,
> I can try and expand upon it if needed.

I'd appreciate it if you tried, I'm not sure I really understand what
you are proposing here.

> Suggestion #4: Merge different types of server error to prevent leaking
> what happened under the hood
> 
> a planned maintenance. Basically I'm sort of allergic to disclosing
> information about the server state.

I don't think it would be any probem at all for a server admin who was
conerned about the security implications of this to configure their
server so that it logged the full two-digit codes for the sake of log
monitoring and debugging, but exclusively sent x0 codes to the client.

I think actually in the very early days of Gemini when debate raged over
how many status codes we need and how many digits was enough, I made the
case that there was no point at all in having codes that distinguish
situations which clients can't possibly react to in meaningfully
different ways.  I was convinced (and rightly so, I think), that it's
good to be able to make these distinctions on the server side.  The
strategy outlined above is kind of like an encoding of this principle.

Of course, no off-the-shell servers support this mode of operation yet,
but if people like the idea that could change...
 
> Suggestion #5: A comment, really
> 
> 5x codes are by design permanent errors but 51 (HTTP 404 equivalent) is
> actually a temporary problem according to the spec.
> In fact this is precisely what differentiates it from HTTP 410 GONE
> (gemini 52). So there seems to be a design error here but I don't really
> know what the correct solution is. Either 5x aren't really permanent
> errors (how would they be called then?) or 51 shouldn't be a 5x error
> to begin with.

It's true that "not found" is, in principle, temporary, or at least
non permanent, in the sense that, yes, maybe tomorrow or next month or
next year there will be something at that address.

The temporary/permanent error distinction in Gemini is intended mostly
to be useful for non-human user agents, like search engine crawlers or
feed aggregators or things like that, rather than people sitting in
front of something like Bombadillo or Castor.  If a bot tries to fetch a
feed from a bad URL, it would be nice if it didn't continually try again
every hour on the hour thinking that it's only a temporary failure and
one day the feed will appear!

> This sums up my thoughts about the status codes. I know this reads very
> much like "too complex, cut!" and that kinda is exactly that. But if you
> can make things simpler, why not do it? :)

It's very refreshing to see discussion on this mailing list aimed at
taking stuff away, not adding it! :)

> Thanks for reading this, cheers!

Thanks for sharing your thoughts!

Cheers,
Solderpunk

From dunderpate at sdf.org  Wed May 20 21:59:08 2020
From: dunderpate at sdf.org (Dunderpate)
Date: Wed, 20 May 2020 15:59:08 -0500
Subject: Any Windows clients?
In-Reply-To: <HYRa4PhhvxJ9gDn5pah6dKi82qoZ_Q0euPh3Dn1pXAlV-tQHXZx0IfsXxpqozYmAig3dOgnbQlkTlBlPX9tUDV-ffHhVREFePKQ8eNx3o6s=@strega-nil.co>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
 <1722df13a02.c7b4232b344431.1739687027125254459@68kmentat.com>
 <0235b28c4f1280b39c012113bdbebfb2.squirrel@mx.sdf.org>
 <HYRa4PhhvxJ9gDn5pah6dKi82qoZ_Q0euPh3Dn1pXAlV-tQHXZx0IfsXxpqozYmAig3dOgnbQlkTlBlPX9tUDV-ffHhVREFePKQ8eNx3o6s=@strega-nil.co>
Message-ID: <f27f8eddb1420305c2354dc198fe064d.squirrel@mx.sdf.org>

Hi there Nicole,

LOL, it's great to have a community of people that are willing to help
with n00bs like me when it comes to vcpkg.

AFAIK, the issue in my case was with OpenSSL failing to compile (which I
eventually got past), and the naming of the gtk *.libs. After about a
half-hour of various failures and fighting with my work computer's
restrictions, vcvarsall, and other stuff; I changed the name of the *.lib
files according to the instructions I was following, and then the linker
just exploded with roughly a gazillion errors. A small tear ran down the
side of my face and I moved on. Perhaps with enough caffeine and a
chatroom of pros, I might stand a chance :D

Thanks again for the pointers to the discord channel. Please do forgive my
remark about vcpkg being "shenanigans". It just happened to be the
proverbial straw that broke my back that day.

Christopher
> FWIW, I'm on the vcpkg team so if anyone needs help with it you can always
> reach out. Additionally, includecpp.org's discord has a #vcpkg channel a
> few of us hang out on.
>
> (somewhat unrelated but _shrug_)
>
> Nicole
>
> -------- Original Message --------
> On May 19, 2020, 10:52, Dunderpate wrote:
>
>> Hi Andrew,
>>
>> Fantastic! I'm much more familiar with Python than I am with rust and
>> all
>> the vcpkg shenanigans that were going on with castor. I'll give this a
>> shot and post a pic if it works.
>>
>> Thanks again Andrew :D
>>
>> Dunderpate
>>> I just got mcross running, after struggling to get Castor to build
>>> (even
>>> with the instructions, I'm not sure what I'm missing :/)
>>>
>>> https://sr.ht/~nhanb/mcross/
>>>
>>> it's pretty straightforward: Python 3.7+, run "pip install mcross" and
>>> then "mcross"
>>>
>>> - Andrew
>>>
>>>
>>> ---- On Tue, 19 May 2020 11:13:04 -0400
>>> <gemini-request at lists.orbitalfox.eu> wrote ----
>>> > Message: 9
>>> > Date: Tue, 19 May 2020 10:12:59 -0500
>>> > From: "Dunderpate" <dunderpate at sdf.org>
>>> > To: "A protocol that is slightly more complex than gopher, but
>>> > significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>>> > Subject: Re: Any Windows clients?
>>> > Message-ID: <fea0338c5bd0b17594fa5689ffcbc6d6.squirrel at mx.sdf.org>
>>> > Content-Type: text/plain;charset=iso-8859-1
>>> >
>>> > > Il giorno gio 14 mag 2020 alle 13:29, Dunderpate
>>> <dunderpate at sdf.org>
>>> > > ha scritto:
>>> > >> I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
>>> > >> confined
>>> > >> to Windows for my day job :/ So, I was just wondering if anyone on
>>> > >> this
>>> > >> list knows of a Windows client floating around that I could use.
>>> > >>
>>> > > I didn't tried but I would say that Alrisha
>>> > > (https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on
>>> > > windows without any problem...
>>> > Hi there!
>>> >
>>> > Thanks for the recommendation! I just had a chance to look into this
>>> last
>>> > night and, unfortunately I'm not that comfortable creating a Qt
>>> account
>>> > just to install the tooling required to run qmake :/ I might be
>>> missing
>>> > something that allows me to bypass the account creation, but it's a
>>> > principle thing I guess LOL. The client itself seems nice enough
>>> though,
>>> > and if they had pre-compiled builds I'd certainly use one of 'em.
>>> >
>>> > Thanks again :D
>>> > --
>>> > Dunderpate
>>> >
>>>


-- 
Dunderpate


From martin at no.ucant.org  Wed May 20 22:11:00 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Wed, 20 May 2020 22:11:00 +0100 (BST)
Subject: [ANN] Announcing `commie.space`...
In-Reply-To: <20200520173232.GA27888@SDF.ORG>
References: <20200520113350.GA2116544@spektr> <20200520173232.GA27888@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2005202210140.18317@pling.qwghlm.org>

On Wed, 20 May 2020, solderpunk wrote:

> GUS tends to find stuff before I do these days. :)  But you're on the
> server list now too anyway, so you'd better keep posting!

Ah please add gemini://gemini.ucant.org/ too :)

But more seriously - is anyone willing to help me write a "server torture"
script? We're starting to need one.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From jan6 at tilde.ninja  Wed May 20 22:13:34 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Wed, 20 May 2020 21:13:34 +0000
Subject: Status codes
In-Reply-To: <20200520201642.GC27888@SDF.ORG>
References: <20200520201642.GC27888@SDF.ORG>
 <CACVUgn__fRRX+u=8sB07pqyY_sHHHAT4gpQ=x4U9nX1w+4VO-Q@mail.gmail.com>
Message-ID: <aa7f26821143d1dc8b71c67eadaef603@tilde.ninja>

May 20, 2020 11:16 PM, "solderpunk" <solderpunk at sdf.org> wrote:

> I do kind of worry that the time to propose changes to "core" stuff is
> passed or passing. New implementations are being written at an
> astonishing rate and with so many clients and servers out there, every
> substantial change runs the risk of fracturing the nascent Geminispace
> into incompatible subspaces. Stuff that is very poorly implemented,
> like client certificiate stuff, doesn't have this risk so much, but
> anything fundamental I worry is already more or less "set" now. It's
> the downside to unexpected explosive growth

can't you simply set up different version revisions, though, for that?
maybe just a "gemini-stable" and "gemini-next" branch, where gemini-next is explictly experimental and can change at any time,
and ideas from there that work, can be cycled into gemini-stable at some kinda-set intervals?

> 
>> Suggestion #5: A comment, really
>> 
>> 5x codes are by design permanent errors but 51 (HTTP 404 equivalent) is
>> actually a temporary problem according to the spec.
>> In fact this is precisely what differentiates it from HTTP 410 GONE
>> (gemini 52). So there seems to be a design error here but I don't really
>> know what the correct solution is. Either 5x aren't really permanent
>> errors (how would they be called then?) or 51 shouldn't be a 5x error
>> to begin with.
> 
> It's true that "not found" is, in principle, temporary, or at least
> non permanent, in the sense that, yes, maybe tomorrow or next month or
> next year there will be something at that address.
> 
> The temporary/permanent error distinction in Gemini is intended mostly
> to be useful for non-human user agents, like search engine crawlers or
> feed aggregators or things like that, rather than people sitting in
> front of something like Bombadillo or Castor. If a bot tries to fetch a
> feed from a bad URL, it would be nice if it didn't continually try again
> every hour on the hour thinking that it's only a temporary failure and
> one day the feed will appear!
> 

I think it'd be best if it returned an (optional?) timeout/expiry info, for the tag (if not optional, 0 or -1 can signify infinite time), not sure what time unit, probably just seconds, though "1h" for 1 hour, and such is also possible
that way the server can specify if it should be flagged as missing for the next hour, or next day, or forevermore, etc, 
useful in cases that you temporarily take down a page for whatever reason, or where you might change urls every so often, or if you're simply prone to typos and sometimes fumble the links, and don't want to bother to manually ask for re-index... sometime you might not even know that a page is not crawled by some crawler...

also while probably not necessarily part of the spec, what should be the case if there's a redirect to a nonexistant URL?
should the url that was redirected FROM, be permanently "not found" as well?

and if it's intended for non-human agents, maybe mention that, too? that human-controlled clients are allowed to re-request on demand and don't have to block it forever?

"client error" makes more sense than "permanent error" in this case, too

From solderpunk at SDF.ORG  Wed May 20 22:16:43 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 20 May 2020 21:16:43 +0000
Subject: [ANN] Announcing `commie.space`...
In-Reply-To: <alpine.DEB.2.20.2005202210140.18317@pling.qwghlm.org>
References: <20200520113350.GA2116544@spektr> <20200520173232.GA27888@SDF.ORG>
 <alpine.DEB.2.20.2005202210140.18317@pling.qwghlm.org>
Message-ID: <20200520211643.GB8234@SDF.ORG>

On Wed, May 20, 2020 at 10:11:00PM +0100, Martin Keegan wrote:
 
> But more seriously - is anyone willing to help me write a "server torture"
> script? We're starting to need one.

I started one of these ages ago, but never got very far.  I agree it's a
very good idea.  I'll try to dig up my code tomorrow to see which tests
I came up with, but certainly I didn't cover everything.

Cheers,
Solderpunk

From k at kvn.dev  Wed May 20 22:55:21 2020
From: k at kvn.dev (kristof)
Date: Wed, 20 May 2020 23:55:21 +0200
Subject: [ANN] houston - yet another gemini search engine
Message-ID: <20200520215521.gtzuaucmksisj43p@kvn.dev>

Hi there,

I just created gemini://houston.coder.town

It's a very, very barebones search at this time.

Features are:
  * Very simple
  * Returns parts of the text where your search matches

Plans:
  * More advanced search methodology
  * Better and more exhaustive indexing

It uses a custom client and server. There's probably still a bunch of
bugs.

Let me know what you think.

From mbrubeck at limpet.net  Wed May 20 23:40:43 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Wed, 20 May 2020 15:40:43 -0700
Subject: Announcing Agate, another Rust server
Message-ID: <CAD1=23=S09G7ur=nV=Bqxwt-3_XAbjKGHPerGs1Z3dkCFx4RfA@mail.gmail.com>

Greetings! I'm very excited about the Gemini project. Kudos to all the
contributors.

I wrote a basic Gemini server in Rust. It's called Agate. You can find its
home page here (self-hosting, of course):

gemini://gem.limpet.net/agate/

All it does at the moment is serve static text files. It doesn't have a lot
to distinguish it from other Gemini servers, though it does use async I/O
to handle concurrent requests with very low resource use. It could be good
for hosting a static site on low-powered hardware like a Raspberry Pi.
Mostly, it's just meant to be simple and bare-bones. For the curious, you
can find the source code here:

https://github.com/mbrubeck/agate

I hope to write a client also, as soon as I have the time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200520/0fe1c862/attachment-0001.htm>

From luke.emmet at gmail.com  Thu May 21 00:25:35 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 21 May 2020 00:25:35 +0100
Subject: [ANN] houston - yet another gemini search engine
In-Reply-To: <20200520215521.gtzuaucmksisj43p@kvn.dev>
References: <20200520215521.gtzuaucmksisj43p@kvn.dev>
Message-ID: <5EC5BC6F.5090004@gmail.com>

On 20-May-2020 22:55, kristof wrote:
> I just created gemini://houston.coder.town
>
> It's a very, very barebones search at this time.
>
> <snip>
>
> It uses a custom client and server. There's probably still a bunch of
> bugs.
>
> Let me know what you think.

It seems to work well - it is nice to see some snippets coming back, not 
just the path/filename.

A couple of minor thoughts for your consideration

1. Would be useful to have a link at the top of each results page to 
allow user to refine their search

2. Might be better UI to display snippets as bullets. That way clients 
that prettily handle them will be able to show them nicely. I dont think 
it matters to enumerate them 1 to 5.

3. Is there a way for the user to lengthen the snippets, perhaps there 
could be some alternative URLs that allow longer or shorter results shown.

4. Maybe there needs to be some pagination of the results if too many 
are shown, or maybe that is not a problem yet...

otherwise - keep up the good work!

  - Luke

From nicole at strega-nil.co  Thu May 21 07:01:07 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Thu, 21 May 2020 06:01:07 +0000
Subject: Any Windows clients?
In-Reply-To: <f27f8eddb1420305c2354dc198fe064d.squirrel@mx.sdf.org>
References: <mailman.150.1589901184.533.gemini@lists.orbitalfox.eu>
 <1722df13a02.c7b4232b344431.1739687027125254459@68kmentat.com>
 <0235b28c4f1280b39c012113bdbebfb2.squirrel@mx.sdf.org>
 <HYRa4PhhvxJ9gDn5pah6dKi82qoZ_Q0euPh3Dn1pXAlV-tQHXZx0IfsXxpqozYmAig3dOgnbQlkTlBlPX9tUDV-ffHhVREFePKQ8eNx3o6s=@strega-nil.co>
 <f27f8eddb1420305c2354dc198fe064d.squirrel@mx.sdf.org>
Message-ID: <IaPc0_GOCx515PzW9--Yz_qRfrGlm_IYC64JRU3Lfke1q1_zEGLgyjiD8xgci1CfvoTxleoU6_SEERV-xllyUi5w1Y8BA0Cy2SNu5Xx9CBw=@strega-nil.co>

Don't worry about it; building C++ is _always_ shenanigans ?

Nicole


Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Wednesday, May 20, 2020 1:59 PM, Dunderpate <dunderpate at sdf.org> wrote:

> Hi there Nicole,
>
> LOL, it's great to have a community of people that are willing to help
> with n00bs like me when it comes to vcpkg.
>
> AFAIK, the issue in my case was with OpenSSL failing to compile (which I
> eventually got past), and the naming of the gtk *.libs. After about a
> half-hour of various failures and fighting with my work computer's
> restrictions, vcvarsall, and other stuff; I changed the name of the *.lib
> files according to the instructions I was following, and then the linker
> just exploded with roughly a gazillion errors. A small tear ran down the
> side of my face and I moved on. Perhaps with enough caffeine and a
> chatroom of pros, I might stand a chance :D
>
> Thanks again for the pointers to the discord channel. Please do forgive my
> remark about vcpkg being "shenanigans". It just happened to be the
> proverbial straw that broke my back that day.
>
> Christopher
>
> > FWIW, I'm on the vcpkg team so if anyone needs help with it you can always
> > reach out. Additionally, includecpp.org's discord has a #vcpkg channel a
> > few of us hang out on.
> > (somewhat unrelated but shrug)
> > Nicole
> > -------- Original Message --------
> > On May 19, 2020, 10:52, Dunderpate wrote:
> >
> > > Hi Andrew,
> > > Fantastic! I'm much more familiar with Python than I am with rust and
> > > all
> > > the vcpkg shenanigans that were going on with castor. I'll give this a
> > > shot and post a pic if it works.
> > > Thanks again Andrew :D
> > > Dunderpate
> > >
> > > > I just got mcross running, after struggling to get Castor to build
> > > > (even
> > > > with the instructions, I'm not sure what I'm missing :/)
> > > > https://sr.ht/~nhanb/mcross/
> > > > it's pretty straightforward: Python 3.7+, run "pip install mcross" and
> > > > then "mcross"
> > > >
> > > > -   Andrew
> > > >
> > > > ---- On Tue, 19 May 2020 11:13:04 -0400
> > > > gemini-request at lists.orbitalfox.eu wrote ----
> > > >
> > > > > Message: 9
> > > > > Date: Tue, 19 May 2020 10:12:59 -0500
> > > > > From: "Dunderpate" dunderpate at sdf.org
> > > > > To: "A protocol that is slightly more complex than gopher, but
> > > > > significantly simpler than HTTP" gemini at lists.orbitalfox.eu
> > > > > Subject: Re: Any Windows clients?
> > > > > Message-ID: fea0338c5bd0b17594fa5689ffcbc6d6.squirrel at mx.sdf.org
> > > > > Content-Type: text/plain;charset=iso-8859-1
> > > > >
> > > > > > Il giorno gio 14 mag 2020 alle 13:29, Dunderpate
> > > > > > dunderpate at sdf.org
> > > > >
> > > > > > ha scritto:
> > > > > >
> > > > > > > I'm a big-time Linux user, bare-metal, and BSD guy. However, I'm
> > > > > > > confined
> > > > > > > to Windows for my day job :/ So, I was just wondering if anyone on
> > > > > > > this
> > > > > > > list knows of a Windows client floating around that I could use.
> > > > > >
> > > > > > I didn't tried but I would say that Alrisha
> > > > > > (https://git.sr.ht/~fabrixxm/alrisha) being pure Qt should run on
> > > > > > windows without any problem...
> > > > > > Hi there!
> > > > >
> > > > > Thanks for the recommendation! I just had a chance to look into this
> > > > > last
> > > > > night and, unfortunately I'm not that comfortable creating a Qt
> > > > > account
> > > > > just to install the tooling required to run qmake :/ I might be
> > > > > missing
> > > > > something that allows me to bypass the account creation, but it's a
> > > > > principle thing I guess LOL. The client itself seems nice enough
> > > > > though,
> > > > > and if they had pre-compiled builds I'd certainly use one of 'em.
> > > > >
> > > > > Thanks again :D
> > > > >
> > > > > ----------------
> > > > >
> > > > > Dunderpate
>
> --
>
> Dunderpate



From gmym at coopdot.com  Thu May 21 07:31:19 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Thu, 21 May 2020 08:31:19 +0200
Subject: Questions about ``` lines
Message-ID: <CAObwWNhWeBOmQ9_FcZ+fHUiOpPMSumrkJ43FjzZu70hEMyzC0w@mail.gmail.com>

Hello Geminauts

1. Are ``` lines to be block markers or mode switches?

>From the discussions on the the list, it seems like they are block markers.
The current spec calls them "toggle lines" that toggle "pre-formatted mode
being on or off" which suggests it's a mode switch.

The way I interpret the difference between the two is that blocks need to
close before end-of-file to be valid and in the other case the file can end
in any mode.

This might be splitting hairs but I want this to be clear.

2. Is it desirable to close the window of extensibility?

When reading the archives, I noticed that ``` lines used to only work if
they had no trailing characters. This was changed to be less surprising
when someone writes
    ```python
as if it was a markdown code block.

There is a discussion in another thread to use this space for alternative
text when entering pre-formatted mode but I have other extensions on my
mind. These extensions I will show you are not proposals I want to see.

    ``` Visual browsers will
    ``` not display these lines.
    ``` So as long as there are
    ``` an even number of them,
    ``` I can get away with using
    ``` them as comment lines.

Someone could also construct a browser that embeds media files with a
fallback to a link for other browsers:

    ``` @embed image/png
    ``` width=300 height=200
    => path/to/image.png Alt. text

I don't think we need to close this window, but I also don't see a need to
allow consecutive ``` lines.

These are real questions with added context and not opinions or rhetoric
dressed as questions.

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/e1bb4cae/attachment.htm>

From plugd at thelambdalab.xyz  Thu May 21 08:17:10 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Thu, 21 May 2020 09:17:10 +0200
Subject: [ANN] cybertronica.org - new gemini space
In-Reply-To: <cEgOdnPnkZ0tDWUlQiId0tQ6OI2C0SGbKQuKsryUZ5_W6IC_FowLxe63Z99pjFiVDt5XE3eGnBAN1FNzfqUjTcG2Q_TFso8FqsBwQOiBYk0=@cybertronica.org>
References: <_-Mp7W5rzmB2LJ7wCcfBl_HnAz_55UdK3iyY1b85B06aDoEehoSeO6JUbG3tH6A758Dob8f6vJuYgPQn23hQTEYFizkv4ttyPhET5168szA=@cybertronica.org>
 <vjuzWwMQhnj5pQrwozdLYdTUyFzEpDIlsaFncnR1ZDCrCXryIzYYKcwN554bgp9RXJzNKxzyp4uAHjnUBDTogYsvDgcEWpygAxEXT8tc06s=@protonmail.com>
 <cEgOdnPnkZ0tDWUlQiId0tQ6OI2C0SGbKQuKsryUZ5_W6IC_FowLxe63Z99pjFiVDt5XE3eGnBAN1FNzfqUjTcG2Q_TFso8FqsBwQOiBYk0=@cybertronica.org>
Message-ID: <lzd06xsqo9.fsf@bs-mbpr348.d.ethz.ch>

koodikone writes:
> Heh! Sure. I havent just tested yet other clients than bombadillo.

It looks fine in elpher, at least with the default monospaced text
face and text width. Just make sure to wrap your ascii art in ``` blocks
to ensure it still looks okay regardless of these kinds of settings.
(The spec protects your art in this case. :-) )

Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/acda117c/attachment.sig>

From plugd at thelambdalab.xyz  Thu May 21 08:36:39 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Thu, 21 May 2020 09:36:39 +0200
Subject: Questions about ``` lines
In-Reply-To: <CAObwWNhWeBOmQ9_FcZ+fHUiOpPMSumrkJ43FjzZu70hEMyzC0w@mail.gmail.com>
References: <CAObwWNhWeBOmQ9_FcZ+fHUiOpPMSumrkJ43FjzZu70hEMyzC0w@mail.gmail.com>
Message-ID: <lz8shlsprs.fsf@bs-mbpr348.d.ethz.ch>

Hi Katarina,

Katarina Eriksson writes:
>     ``` @embed image/png
>     ``` width=300 height=200
>     => path/to/image.png Alt. text
>
> I don't think we need to close this window, but I also don't see a need to
> allow consecutive ``` lines.

I think I understand your worry, but wouldn't it be difficult to close
this window?  To exclude this possibility requires adding this special
exclusion to the spec, and for every client to do something special to
produce an error in the case of consecutive ``` lines.

Even if it were in the spec, I'd be very tempted to just allow it in my
client, just because ignoring this restriction would allow for a cleaner
implementation and would produces no issues with correctly formatted
text/gemini pages, while also allowing some incorrectly formatted pages
to be displayed. (As a user, I honestly don't care whether a gopher map
or text/gemini file meets the spec or not, I just want to read it.)

Just my random thoughts,

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/e3fbbea0/attachment.sig>

From solderpunk at SDF.ORG  Thu May 21 08:52:23 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 21 May 2020 07:52:23 +0000
Subject: Questions about ``` lines
In-Reply-To: <CAObwWNhWeBOmQ9_FcZ+fHUiOpPMSumrkJ43FjzZu70hEMyzC0w@mail.gmail.com>
References: <CAObwWNhWeBOmQ9_FcZ+fHUiOpPMSumrkJ43FjzZu70hEMyzC0w@mail.gmail.com>
Message-ID: <20200521075223.GC28130@SDF.ORG>

On Thu, May 21, 2020 at 08:31:19AM +0200, Katarina Eriksson wrote:
> Hello Geminauts

Hello!

> 1. Are ``` lines to be block markers or mode switches?
 
> >From the discussions on the the list, it seems like they are block markers.
> The current spec calls them "toggle lines" that toggle "pre-formatted mode
> being on or off" which suggests it's a mode switch.

They are definitely mode switches, as stated in the spec.

People tend to speak quite informally on the list - sometimes too
informally for my tastes!  I have noticed people referring to Gemini
sites/servers as websites or webservers which always stuns me a bit...

 
> The way I interpret the difference between the two is that blocks need to
> close before end-of-file to be valid and in the other case the file can end
> in any mode.

There's nothing invalid about a file ending with pre-formatted mode on
according to the current spec and I don't really see a need for this to
change.  Clients should set the value of pre-formatted mode to off
when they begin pasing a new document.

In general, there should be as few ways as possible for a text/gemini
file to be "invalid", it should be dirt simple.  To be honest, I'm kind
of surprised by all the discussion around some kind of
formatting/validating/linting tool for text/gemini.  It doesn't bother
me and people who want them can certainly write them, but to me it seems
like there is so little scope for messing things up writing it by hand
that tools like that feel unnecessary and cumbersome.
 
> 2. Is it desirable to close the window of extensibility?
> 
> When reading the archives, I noticed that ``` lines used to only work if
> they had no trailing characters. This was changed to be less surprising
> when someone writes
>     ```python
> as if it was a markdown code block.

That was the main motivation, but as a little side thing it also meant
it became true that all line types can be unambiguously recognised by
inspecting only their first 3 characters, and I liked having something
that simple apply without exception.  If nothing is allowed after the
``` you need to also check the line length to recognise toggles.

>     ``` Visual browsers will
>     ``` not display these lines.
>     ``` So as long as there are
>     ``` an even number of them,
>     ``` I can get away with using
>     ``` them as comment lines.

My first thought: Oh, cute!  Cute and neat...
 
>     ``` @embed image/png
>     ``` width=300 height=200
>     => path/to/image.png Alt. text

...followed by "Oh, dear God, no!" :O

This is a real and frightening way that clients can sneak in support for
arbitrarily complicated extra functionality, and it degrades absolutely
invisibly in non-supporting clients, so there is no incentive against
content authors using it.  I congratulate you for recognising this and
thank you for bringing it to our attention!  In some ways, this is the
logical conclusion of all the discussion around putting stuff for
clients to parse in that space.

> I don't think we need to close this window, but I also don't see a need to
> allow consecutive ``` lines.

I don't see a need to allow consecutive ``` lines either, but I am
really, really attached to the current property of text/gemini that you
can handle it correctly by handling each line independently of every
other line in a single top-to-bottom pass with very minimal internal
state.  Forbidding consecutive ``` lines would break that and require
the parser to remember the type of the previous line.

But I see no other way to close this window without reverting to toggle
lines being strictly three-characters only, and then we lose the
alt-text option.  To be honest, I could live without specifying
programming languages to enable syntax highlighting in text/gemini - I
get that that's *nice*, but it's not really essential.  But the alt-text
thing kind of feels important to me, because people are right now using
pre-formatted blocks to do things that ruin accessibility/searchability
without it, and those things matter.

I guess one could cynically ask "what makes you think people doing that
right now would use alt-text to fix the problem if you gave them the
means to?", and conclude that we just have to let people suffer the
consequences of not using text/gemini "cleanly"...
 
> These are real questions with added context and not opinions or rhetoric
> dressed as questions.

Definitely real food for thought in here.  Thanks again for this post.

Cheers,
Solderpunk

From k at kvn.dev  Thu May 21 14:26:02 2020
From: k at kvn.dev (kristof)
Date: Thu, 21 May 2020 15:26:02 +0200
Subject: [gemini] Re: [ANN] houston - yet another gemini search engine
In-Reply-To: <5EC5BC6F.5090004@gmail.com>
References: <20200520215521.gtzuaucmksisj43p@kvn.dev>
 <5EC5BC6F.5090004@gmail.com>
Message-ID: <20200521132602.nov3i7wdrkdtymjw@kvn.dev>

On 20/05/21 12:25AM, Luke Emmet wrote:

> It seems to work well - it is nice to see some snippets coming back, not
> just the path/filename.

Ye, I wanted to be able to show where the 'match' comes from, so people
can judge in a more informed way if it's relevant.

> A couple of minor thoughts for your consideration
>
> 1. Would be useful to have a link at the top of each results page to allow
> user to refine their search

Sure, makes sense

> 2. Might be better UI to display snippets as bullets. That way clients that
> prettily handle them will be able to show them nicely. I dont think it
> matters to enumerate them 1 to 5.

I'll have to read the gemini spec again :P

> 3. Is there a way for the user to lengthen the snippets, perhaps there could
> be some alternative URLs that allow longer or shorter results shown.

That should be easily done, in principle I could also allow the
modification of the number of highlights returned (currently max 5).

> 4. Maybe there needs to be some pagination of the results if too many are
> shown, or maybe that is not a problem yet...

Currently not a problem, and when it becomes a problem I think I prefer
to just cap the result set. Using other (http) search engines showed me
that everything not on page 1 is probably not relevant anyway and if I
would offer [1] people could refine the search to be more relevant.

> otherwise - keep up the good work!

Thanks for the comments, they're very useful!

k

From tomasino at lavabit.com  Thu May 21 14:31:27 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 21 May 2020 13:31:27 +0000
Subject: Questions about ``` lines
In-Reply-To: <20200521075223.GC28130@SDF.ORG>
References: <CAObwWNhWeBOmQ9_FcZ+fHUiOpPMSumrkJ43FjzZu70hEMyzC0w@mail.gmail.com>
 <20200521075223.GC28130@SDF.ORG>
Message-ID: <c9b8f21e-37a8-53f2-40cb-24398605909c@lavabit.com>

On 5/21/20 7:52 AM, solderpunk wrote:
>>     ``` @embed image/png
>>     ``` width=300 height=200
>>     => path/to/image.png Alt. text
> ...followed by "Oh, dear God, no!" :O

If ``` gains the alt text it will prevent this sort of abuse on
accident, won't it?


From jan6 at tilde.ninja  Thu May 21 14:37:39 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Thu, 21 May 2020 13:37:39 +0000
Subject: [gemini] Re: [ANN] houston - yet another gemini search engine
In-Reply-To: <20200521132602.nov3i7wdrkdtymjw@kvn.dev>
References: <20200521132602.nov3i7wdrkdtymjw@kvn.dev>
 <20200520215521.gtzuaucmksisj43p@kvn.dev> <5EC5BC6F.5090004@gmail.com>
Message-ID: <cf998dd4cd49712f86e7d95e54dced6a@tilde.ninja>

May 21, 2020 4:26 PM, "kristof" <k at kvn.dev> wrote:
>> 4. Maybe there needs to be some pagination of the results if too many are
>> shown, or maybe that is not a problem yet...
> 
> Currently not a problem, and when it becomes a problem I think I prefer
> to just cap the result set. Using other (http) search engines showed me
> that everything not on page 1 is probably not relevant anyway and if I
> would offer [1] people could refine the search to be more relevant.

http search engines have quite a many results on a page, usually
also
it's usually first 3 pages that have relevant information, top 5 results are usually engineered and not relevent anyway, for www, also the extra results help to see how the query should be refined, such as "ice -cream" or whatnot

maybe make a "brief" and a "detailed" version, latter of which has longer descriptions and pagination (or simply a long page of the results?)

if you search for "blog" for example, you're bound to get more results than fit...and you might well want to see all of them...
related, maybe an option to reduce the hits on a single domain or directory? resulting in a hit, and at the end of the snippet or something, "and 7 other results from $domain" or such, obviously that is different enough that should be optional, if a feature at all

idk, maybe I'm overcomplicating and overthingking it all...

From b__m__e at mailfence.com  Thu May 21 16:01:44 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Thu, 21 May 2020 17:01:44 +0200 (CEST)
Subject: Questions about ``` lines
Message-ID: <303580426.705361.1590073304203@ichabod.co-bxl>

Katarina writes:
>     ``` @embed image/png
>     ``` width=300 height=200
>     => path/to/image.png Alt. text

I had not thought of using that space for something like that. This is unfortunate.
However, I am grateful to Katarina for bringing it to our attention. I think this
is important.

I also concur with solderpunk's assessment:
> To be honest, I could live without specifying
> programming languages to enable syntax highlighting in text/gemini - I
> get that that's *nice*, but it's not really essential.  But the alt-text
> thing kind of feels important to me

I think accessibility is extremely important and that alt text for ascii art
is of great benefit.

I have a branch of my client, Bombadillo, built that supports alt text and
toggling off preformatted block lines in favor of their alt text (or nothing,
if there is no alt text). It works well for what it is trying to do. If alt text
became a part of the spec and was widely encouraged by the community
such that it became standard practice I think it would be really wonderful.
I also see that as a real possible thing that could happen (in a way that HTML
has struggled with).

Of note, that build of Bombadillo does NOT allow any text on the closing line
of a preformatted block. Or at the very least, it will ignore that text. I don't
know that that solves anything for the issues described by Katarina but it
might help.

Another suggestion, and I know this is rough, is to add another block type so
that there is one for readable text and one for art.

Somthing like:

```
    def i_am_a_code_block():
        print("How do I add alt text?")
```

~~~
   : - p
~~~

Having the two types makes it fairly non-extensible. It does NOT solve the alt
text problem, which I would still very much like to see. But it does separate out
crawlable content for search engines, allow clients to let their users turn off all
ascii art,hide art for screen readers while allowing them to ask the user if they
want a preformatted text block read to them, and probably a few other uses.

Every way I try to think of adding alt text ends up being arbitrarily extendable
and hidden to users under most circumstances. This is a very big bummer. I
continue to think that alt text is essential for a free and openly expressive
platform that is accessible to all. If anyone has any ideas please post! 

I suppose alt text could have its own tag, but it seems like we'd have the same
issues....

From jan6 at tilde.ninja  Thu May 21 16:12:40 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Thu, 21 May 2020 15:12:40 +0000
Subject: Questions about ``` lines
In-Reply-To: <303580426.705361.1590073304203@ichabod.co-bxl>
References: <303580426.705361.1590073304203@ichabod.co-bxl>
Message-ID: <349ce63774923356c6c6b089197f94d7@tilde.ninja>

> I also concur with solderpunk's assessment:
>> To be honest, I could live without specifying
>> programming languages to enable syntax highlighting in text/gemini - I
>> get that that's *nice*, but it's not really essential. But the alt-text
>> thing kind of feels important to me

well, you could make it a boolean that any amount of alt-text = art, and showing the alt-text is optional, but reccommended

that way if someone tried to do such a thing, a lot of clients would see that as a kind of caption, and people would get annoyed at it and tell to stop with the nonsense alt-text...

at least that's what I'd assume would happen ;)

also, it would mean that someone labelling their code, would see it as art, which would be a detriment to accessibility, but otherwise not straight-out fail, which is probably good...

and if allowed at all, I think they should only be allowed at the starting tag-line anyway

From mbrubeck at limpet.net  Thu May 21 19:04:26 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Thu, 21 May 2020 11:04:26 -0700
Subject: [ANN] Announcing Agate, another Rust server
In-Reply-To: <CAD1=23=S09G7ur=nV=Bqxwt-3_XAbjKGHPerGs1Z3dkCFx4RfA@mail.gmail.com>
References: <CAD1=23=S09G7ur=nV=Bqxwt-3_XAbjKGHPerGs1Z3dkCFx4RfA@mail.gmail.com>
Message-ID: <CAD1=23miq_8frhPVkPY05VnDp_b3KRycAbtNK=s0aBt-qiH1kQ@mail.gmail.com>

Update: With the help of Michael Lazar?s jetforce_diagnostics.py script
[1], I have published Agate 1.0.1 [2] with several error handling
improvements. It should now use more accurate error codes, and gracefully
handle more types of requests, although it is still not perfect. Thank you
for this test suite!

=>
https://github.com/michael-lazar/jetforce/blob/master/jetforce_diagnostics.py
[1]
=> gemini://gem.limpet.net/agate/ [2]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/a0f79d06/attachment.htm>

From luke.emmet at gmail.com  Thu May 21 19:37:43 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 21 May 2020 19:37:43 +0100
Subject: [gemini] Re: [ANN] houston - yet another gemini search engine
In-Reply-To: <20200521132602.nov3i7wdrkdtymjw@kvn.dev>
References: <20200520215521.gtzuaucmksisj43p@kvn.dev>
 <5EC5BC6F.5090004@gmail.com> <20200521132602.nov3i7wdrkdtymjw@kvn.dev>
Message-ID: <5EC6CA77.7070500@gmail.com>

On 21-May-2020 14:26, kristof wrote:
>> 2. Might be better UI to display snippets as bullets. That way clients that
>> prettily handle them will be able to show them nicely. I dont think it
>> matters to enumerate them 1 to 5.
> I'll have to read the gemini spec again :P

It would just be really simple like this

=> gemini://host1/path1 display text 1
* snippet 1
* snippet 2
* snippet 3
* etc

=> gemini://host2/path2 display text 2
* snippet 1
* snippet 2
* snippet 3
* etc

Best wishes

  - Luke

From martin at no.ucant.org  Thu May 21 21:14:16 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Thu, 21 May 2020 21:14:16 +0100 (BST)
Subject: [ANN] Announcing Agate, another Rust server
In-Reply-To: <CAD1=23miq_8frhPVkPY05VnDp_b3KRycAbtNK=s0aBt-qiH1kQ@mail.gmail.com>
References: <CAD1=23=S09G7ur=nV=Bqxwt-3_XAbjKGHPerGs1Z3dkCFx4RfA@mail.gmail.com>
 <CAD1=23miq_8frhPVkPY05VnDp_b3KRycAbtNK=s0aBt-qiH1kQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2005212112460.18317@pling.qwghlm.org>

On Thu, 21 May 2020, Matt Brubeck wrote:

> handle more types of requests, although it is still not perfect. Thank you
> for this test suite!

> https://github.com/michael-lazar/jetforce/blob/master/jetforce_diagnostics.py

I've left a github ticket on jetforce requesting that this script be made 
a separate project, as a potential basis for a general conformance testing 
suite for all Gemini server implementations.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From ben at benburwell.com  Thu May 21 21:37:47 2020
From: ben at benburwell.com (Ben Burwell)
Date: Thu, 21 May 2020 16:37:47 -0400
Subject: Adding gemini protocol to curl
Message-ID: <831ba0b2-7a69-495c-98c1-c052dfbf3248@www.fastmail.com>

Hi all, I'm just starting to play around with gemini -- seems very
interesting!

I have started writing a patch for curl which adds support for the
gemini protocol. I just joined the mailing list, so I am not sure if
anyone has already done any work with curl; I did see some mentions of
`gurl` tools in the archives but I did not see mention of curl itself.

My curl tree with the gemini patch is available here:
https://git.sr.ht/~benburwell/curl

If you build it, you should be able to successfully run `curl
gemini://gemini.circumlunar.space`. It's currently the result of about a
hour's worth of hacking, so beware of dragons. I plan to make it a bit
more robust as well as add better response header handling (think `curl
-i` -- right now they are just printed without being parsed at all),
redirect handling (think `curl -L`) and alternate URL handling (think
`curl -H host:other.site http://example.com`).

I suspect that a patch to add support for a new protocol would not be
accepted to the upstream curl project at least until there is a
finalized spec.

In the meantime, feel free to build/use this for non-production
purposes, and if anyone has already done work on this I'd be curious to
learn about it.

Best,
Ben

From solderpunk at SDF.ORG  Thu May 21 21:47:31 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 21 May 2020 20:47:31 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200519074625.GD4068@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG>
Message-ID: <20200521204731.GA4116@SDF.ORG>

On Tue, May 19, 2020 at 07:46:25AM +0000, solderpunk wrote:
 
> So now the question is which do we prefer, forcing servers to
> canonicalise (canonise?) everything, with client behaviour then being
> strictly limited, or letting servers just send whatever the author uses
> and forcing clients to accept any of CRLF, CR or LF?
> 
> In general I have preferred pushing burden to server authors over client
> authors for Gemini...but I expect the client burden is pretty small here
> as most languages will have some kind of functionality for breaking
> strings into lines which already handles this...

Some quick experimentation with Python revealed that str.splitlines()
is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.
Encouraged by this, I made a single Gemini page that mixes all three
styles in a single document:

gemini://gemini.circumlunar.space/users/solderpunk/linebreaks.gmi

I visited it with a selection of clients, but the results weren't
encouraging.

It rendered just fine in AV-98, because apparently Python is awesome at
this.

Curiously, McCross, also in Python, could handle CR fine, split CRLF
into lines but displayed some stray characters at the end of lines, and
did not split LF lines at all.  Perhaps this is because it's a GUI
client and is relying on Tkinter to redner text?

Bombadillo and Castor (an old build of Castor I had lying around,
admittedly) both handled CR and CRLF fine, but did not split LF lines at
all.  The same was true of my tiny demo Lua and Go clients.

So, speccing any line ending as permissble, like HTML does, would
seemingly immediately render most clients out-of-spec.

Specifying CR or CRLF but not LF would require the minimum amount of
rework, but it would be hard to justify this by anything other than
laziness.  We either go strict, and require CRLF only, or we go
permissive, and allow anything, but we can't really pick and mix for the
sake of convenience.

We basically need to choose between forcing server authors to normalise
all endings to CRLF or forcing client authors to recgonise LF (even
though it'll probably never be seen in the wild).

Neither really thrill me, but, well, here we are.

Cheers,
Solderpunk

From sean at conman.org  Thu May 21 21:54:47 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 21 May 2020 16:54:47 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521204731.GA4116@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
Message-ID: <20200521205446.GL30203@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> So, speccing any line ending as permissble, like HTML does, would
> seemingly immediately render most clients out-of-spec.

  Please, *please*, *PLEASE* do not let this disuade you from making most
clients out of spec.  We have had to suffer terrible things because of this
thinking (like Makefiles and tabs---"when I realized my mistake, there were
already 10 people using it").

> Specifying CR or CRLF but not LF would require the minimum amount of
> rework, but it would be hard to justify this by anything other than
> laziness. 

  And bizareness.  The last time I worked on any systems that used only CR
was back in the 80s.  Today everybody uses either CRLF (Windows) or LF
(Linux, Mac OS-X, whatever remaining bits of Unix are still around).

> We basically need to choose between forcing server authors to normalise
> all endings to CRLF or forcing client authors to recgonise LF (even
> though it'll probably never be seen in the wild).

  Would that be only for text/gemini?  Or all of the text/* formats?

  -spc

From jan6 at tilde.ninja  Thu May 21 21:56:57 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Thu, 21 May 2020 20:56:57 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521204731.GA4116@SDF.ORG>
References: <20200521204731.GA4116@SDF.ORG>
 <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG>
Message-ID: <6acd7d92d6d0e99640594be9478634a7@tilde.ninja>

May 21, 2020 11:47 PM, "solderpunk" <solderpunk at sdf.org> wrote:
> We basically need to choose between forcing server authors to normalise
> all endings to CRLF or forcing client authors to recgonise LF (even
> though it'll probably never be seen in the wild).
> 
> Neither really thrill me, but, well, here we are.

"it'll probably never be seen in the wild" why?
just LF is the standard linux line ending, and if it's allowed, I'm fairly certain there will be several servers which would serve the files as-is, and given they'd likely be on some sort of unix machine, likely be ending with LF

CR on the other hand, is very unlikely to be found in the wild, since it's used by any living OS, afaik, and also should, in theory, just move cursor to the start of line, instead of putting a newline, at least on linux terminals... which would overwrite the line...

From solderpunk at SDF.ORG  Thu May 21 22:00:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 21 May 2020 21:00:28 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <6acd7d92d6d0e99640594be9478634a7@tilde.ninja>
References: <20200521204731.GA4116@SDF.ORG>
 <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG>
 <6acd7d92d6d0e99640594be9478634a7@tilde.ninja>
Message-ID: <20200521210028.GA1122@SDF.ORG>

On Thu, May 21, 2020 at 08:56:57PM +0000, jan6 at tilde.ninja wrote:
> May 21, 2020 11:47 PM, "solderpunk" <solderpunk at sdf.org> wrote:
> > We basically need to choose between forcing server authors to normalise
> > all endings to CRLF or forcing client authors to recgonise LF (even
> > though it'll probably never be seen in the wild).
> > 
> > Neither really thrill me, but, well, here we are.
> 
> "it'll probably never be seen in the wild" why?
> just LF is the standard linux line ending, and if it's allowed, I'm fairly certain there will be several servers which would serve the files as-is, and given they'd likely be on some sort of unix machine, likely be ending with LF
> 
> CR on the other hand, is very unlikely to be found in the wild, since it's used by any living OS, afaik, and also should, in theory, just move cursor to the start of line, instead of putting a newline, at least on linux terminals... which would overwrite the line...

Argh, yep, sorry.  Exchange *all* instances of lone CR and lone LF in
my entire last email, I mixed them up.

Cheers,
Poldersunk

From luke.emmet at gmail.com  Thu May 21 22:13:07 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 21 May 2020 22:13:07 +0100
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521204731.GA4116@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
Message-ID: <5EC6EEE3.9030909@gmail.com>


On 21-May-2020 21:47, solderpunk wrote:
> On Tue, May 19, 2020 at 07:46:25AM +0000, solderpunk wrote:
>> So now the question is which do we prefer, forcing servers to
>> canonicalise (canonise?) everything, with client behaviour then being
>> strictly limited, or letting servers just send whatever the author uses
>> and forcing clients to accept any of CRLF, CR or LF?
>>
>> In general I have preferred pushing burden to server authors over client
>> authors for Gemini...but I expect the client burden is pretty small here
>> as most languages will have some kind of functionality for breaking
>> strings into lines which already handles this...
> Some quick experimentation with Python revealed that str.splitlines()
> is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.
> Encouraged by this, I made a single Gemini page that mixes all three
> styles in a single document:
>
> gemini://gemini.circumlunar.space/users/solderpunk/linebreaks.gmi
>
> I visited it with a selection of clients, but the results weren't
> encouraging.
>
> It rendered just fine in AV-98, because apparently Python is awesome at
> this.
As a client author, I think we have to expect a mix of line endings, but 
perhaps not commonly in the same document. But even this will happen at 
some stage when you have multiple authors contributing to the same file. 
Most text editors will handle this without complaint. I think it is not 
to be surprising that servers will generally just serve up the GMI file 
as is. End users/authors will simply use whatever text editor and os 
defaults it uses.

You can normalise them very simply just before display as follows (or 
similar scheme)

  - Replace all CRLF with LF in the document.
  - Replace all plain CR with LF
  - Then display, splitting at LF
  - Job done.

This is not onerous or a big performance hit as GMI files are in the 
grand scheme of things *very small* text files.

Works for me in my WIP client as a first approximation - the above link 
looks fine. But if the language has a library for this, we should just 
use it.

Best Wishes

   - Luke



From solderpunk at SDF.ORG  Thu May 21 22:13:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 21 May 2020 21:13:28 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521205446.GL30203@brevard.conman.org>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <20200521205446.GL30203@brevard.conman.org>
Message-ID: <20200521211328.GB1122@SDF.ORG>

On Thu, May 21, 2020 at 04:54:47PM -0400, Sean Conner wrote:
 
>   Please, *please*, *PLEASE* do not let this disuade you from making most
> clients out of spec.  We have had to suffer terrible things because of this
> thinking (like Makefiles and tabs---"when I realized my mistake, there were
> already 10 people using it").

Point taken.
 
> > Specifying CR or CRLF but not LF would require the minimum amount of
> > rework, but it would be hard to justify this by anything other than
> > laziness. 
> 
>   And bizareness.  The last time I worked on any systems that used only CR
> was back in the 80s.  Today everybody uses either CRLF (Windows) or LF
> (Linux, Mac OS-X, whatever remaining bits of Unix are still around).

Yep, as stated, this should have been "LR or CRLF".  Speccing that would
require minimal changes to servers (which could just serve files
verbatim and assume nobody is generating CR-only files in this day and
age), and clients (most of which could handle these two with either no
trouble or minimal trouble).

But doesn't just picking two out of the three seem lazy?  Or is that
just me?  Is it okay in 2020 to just write bare CR out of existence?

> > We basically need to choose between forcing server authors to normalise
> > all endings to CRLF or forcing client authors to recgonise LF (even
> > though it'll probably never be seen in the wild).
> 
>   Would that be only for text/gemini?  Or all of the text/* formats?

Ugh.  Let me think...

Cheers,
Solderpunk

From martin at no.ucant.org  Thu May 21 22:17:50 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Thu, 21 May 2020 22:17:50 +0100 (BST)
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521204731.GA4116@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>

On Thu, 21 May 2020, solderpunk wrote:

> We basically need to choose between forcing server authors to normalise
> all endings to CRLF or forcing client authors to recgonise LF (even
> though it'll probably never be seen in the wild).

Could we have a bit of a breather to allow the implications to sink in, 
and, critically, to allow the development of conformance testing tools?

If there were a tool which could be run on a document, that confirmed that 
it was conformant, and a similar tool for server behaviour, and people 
had had some time to try to integrate these with the existing 
software, it'd be easier to assess the tradeoffs involved in the spec 
decision.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From julien at typed-hole.org  Thu May 21 22:26:22 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Thu, 21 May 2020 23:26:22 +0200
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521204731.GA4116@SDF.ORG>
References: <20200521204731.GA4116@SDF.ORG>
Message-ID: <B6A09D7C-F976-4630-96D9-45BE346A66F5@typed-hole.org>

Le 21 mai 2020 ? 22:47, solderpunk <solderpunk at sdf.org> a ?crit :

> Bombadillo and Castor (an old build of Castor I had lying around,
> admittedly) both handled CR and CRLF fine, but did not split LF lines at
> all.  The same was true of my tiny demo Lua and Go clients.

FWIW this wouldn?t be an issue to change in Castor as I had to add code to split on CLRF explicitly if I recall correctly.

From b__m__e at mailfence.com  Thu May 21 22:28:01 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Thu, 21 May 2020 23:28:01 +0200 (CEST)
Subject: Proposed minor spec changes, for comment.
Message-ID: <1266149129.731475.1590096481443@ichabod.co-bxl>

In the CR, LF , and CRLF debate I find myself in favor of 
not worrying about the relic that is CR only. No modern systems use this
and as a new protocol I dont see a compelling reason to support ancient systems.
Particularly given that even among ancient systems just a CR as a line ending
was a rarity.

(The below quote has been edited to provide the character that was actually
meant, per solderpunk's later post):
> Bombadillo and Castor (an old build of Castor I had lying around,
> admittedly) both handled LF and CRLF fine, but did not split CR lines at
> all.  

Bombadillo should be able to handle two of the three. For dealing with lines
I split on newline and remove trailing whitespace from all lines when rendering.
Bombadillo will also never render a `\r` character (the line wrapping parses them
out of the render for display purposes). I imagine Castor and Asuka are doing 
something vaguely similar.


> Some quick experimentation with Python revealed that str.splitlines()
> is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.

That _is_ pretty cool that the python method was able to detect \r line endings
and split them though. Points to python on that one.

From jetkoten at gmail.com  Thu May 21 22:28:19 2020
From: jetkoten at gmail.com (=?UTF-8?B?4pyI5YCL5bGV?=)
Date: Thu, 21 May 2020 16:28:19 -0500
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
Message-ID: <CANW6ZfGYax9izKSMbUj3N468_vHpEks9Pt08Dp5jrypLuiHm=Q@mail.gmail.com>

I think what Martin is saying is some of what I was trying to convey at
with my "gemini-fmt idea" proposal on another thread? that Gemini content
authors run their texts through a spec conforming tool before a text ever
reaches the servers and clients of Geminispace.

Whatever combination of CR, LF or CR LF is in the pre-conformed text it
will be correct when it gets on the server and correct when it gets to the
client if run through such a tool.

The people who are writing the server and client software are doing a huge
service to the Gemini community, so please don't saddle them with the
admittedly tedious work of writing code to check in the server and then
check again in the client if it is an improper combination of CR, LF or CR
LF and then even more code to re-conform it. That kind of thing really
seems to go against the 100 lines of code, code it in a weekend Gemini
spirit in my opinion.

Thanks for your consideration.

J

On Thu, May 21, 2020, 16:18 Martin Keegan <martin at no.ucant.org> wrote:

> On Thu, 21 May 2020, solderpunk wrote:
>
> > We basically need to choose between forcing server authors to normalise
> > all endings to CRLF or forcing client authors to recgonise LF (even
> > though it'll probably never be seen in the wild).
>
> Could we have a bit of a breather to allow the implications to sink in,
> and, critically, to allow the development of conformance testing tools?
>
> If there were a tool which could be run on a document, that confirmed that
> it was conformant, and a similar tool for server behaviour, and people
> had had some time to try to integrate these with the existing
> software, it'd be easier to assess the tradeoffs involved in the spec
> decision.
>
> Mk
>
> --
> Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/a6c3faea/attachment.htm>

From luke.emmet at gmail.com  Thu May 21 22:28:44 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 21 May 2020 22:28:44 +0100
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
Message-ID: <5EC6F28C.3070807@gmail.com>

On 21-May-2020 22:17, Martin Keegan wrote:
> On Thu, 21 May 2020, solderpunk wrote:
>
>> We basically need to choose between forcing server authors to normalise
>> all endings to CRLF or forcing client authors to recgonise LF (even
>> though it'll probably never be seen in the wild).
>
> Could we have a bit of a breather to allow the implications to sink 
> in, and, critically, to allow the development of conformance testing 
> tools?
>
> If there were a tool which could be run on a document, that confirmed 
> that it was conformant, and a similar tool for server behaviour, and 
> people had had some time to try to integrate these with the existing 
> software, it'd be easier to assess the tradeoffs involved in the spec 
> decision.

I would think Postels rule should pragmatically apply to line endings in 
the response body, but the spec should definitely be very specific about 
line endings in any headers (as is http). But those are generated by the 
server anyway.

If we force one line ending kind on authors, it will be a deterrent to 
them forging ahead with writing user content if they have to use some 
tool just to be able to get the content onto the server. Look at XHTML, 
it was a resounding failure and rejected by authors even though there 
were some good (and ill conceived) intentions of the spec writers.

Best Wishes

  - Luke

From solderpunk at SDF.ORG  Thu May 21 22:32:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 21 May 2020 21:32:59 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <5EC6F28C.3070807@gmail.com>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
 <5EC6F28C.3070807@gmail.com>
Message-ID: <20200521213259.GC1122@SDF.ORG>

On Thu, May 21, 2020 at 10:28:44PM +0100, Luke Emmet wrote:
 
> I would think Postels rule should pragmatically apply to line endings in the
> response body, but the spec should definitely be very specific about line
> endings in any headers (as is http). But those are generated by the server
> anyway.

No question, the response header ends in CRLF as per internet spec
convention.  This discussion is purely about the response body.

Cheers,
Solderpunk

From martin at no.ucant.org  Thu May 21 22:50:20 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Thu, 21 May 2020 22:50:20 +0100 (BST)
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <5EC6F28C.3070807@gmail.com>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
 <5EC6F28C.3070807@gmail.com>
Message-ID: <alpine.DEB.2.20.2005212243070.18317@pling.qwghlm.org>

On Thu, 21 May 2020, Luke Emmet wrote:

> If we force one line ending kind on authors, it will be a deterrent to them 
> forging ahead with writing user content if they have to use some tool just to 
> be able to get the content onto the server. Look at XHTML, it was a 
> resounding failure and rejected by authors even though there were some good 
> (and ill conceived) intentions of the spec writers.

I believe there's a difference between requiring servers only to use CRLF 
in the body, and content authors only to use CRLF. If it were specified 
that servers "MUST NOT" send text/gemini bodies that use line separators 
other than CRLF, then it remains up to server implementers to choose 
whether

1) to require content authors to develop or save their content with 
CRLFs, or

2) to translate the content themselves (either on the fly, or by
caching a fettled version with the right line separators).

This is why I keep banging on about having a gemini-check tool for file 
formats (though I understand someone may now have written one up in Go).

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From solderpunk at SDF.ORG  Thu May 21 22:52:09 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 21 May 2020 21:52:09 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <CANW6ZfGYax9izKSMbUj3N468_vHpEks9Pt08Dp5jrypLuiHm=Q@mail.gmail.com>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
 <CANW6ZfGYax9izKSMbUj3N468_vHpEks9Pt08Dp5jrypLuiHm=Q@mail.gmail.com>
Message-ID: <20200521215209.GD1122@SDF.ORG>

On Thu, May 21, 2020 at 04:28:19PM -0500, ??? wrote:
 
> The people who are writing the server and client software are doing a huge
> service to the Gemini community, so please don't saddle them with the
> admittedly tedious work of writing code to check in the server and then
> check again in the client if it is an improper combination of CR, LF or CR
> LF and then even more code to re-conform it.

I'd rather make life a little harder for developers - who are
technical people who know what a CR and LF are and are, anyway, signing
up for a bit of fiddly detail by undertaking to implement an internet
protocol from scratch - than make life harder for content authors, who
may have no idea what this nonsense is all about and are arguably doing
an even bigger service for the community by providing something to use
our present abundance of servers and clients to read.

Sorry if this seems blunt!

Cheers,
Solderpunk

> seems to go against the 100 lines of code, code it in a weekend Gemini
> spirit in my opinion.
> 
> Thanks for your consideration.
> 
> J
> 
> On Thu, May 21, 2020, 16:18 Martin Keegan <martin at no.ucant.org> wrote:
> 
> > On Thu, 21 May 2020, solderpunk wrote:
> >
> > > We basically need to choose between forcing server authors to normalise
> > > all endings to CRLF or forcing client authors to recgonise LF (even
> > > though it'll probably never be seen in the wild).
> >
> > Could we have a bit of a breather to allow the implications to sink in,
> > and, critically, to allow the development of conformance testing tools?
> >
> > If there were a tool which could be run on a document, that confirmed that
> > it was conformant, and a similar tool for server behaviour, and people
> > had had some time to try to integrate these with the existing
> > software, it'd be easier to assess the tradeoffs involved in the spec
> > decision.
> >
> > Mk
> >
> > --
> > Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
> >

From luke.emmet at gmail.com  Thu May 21 23:01:14 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 21 May 2020 23:01:14 +0100
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <alpine.DEB.2.20.2005212243070.18317@pling.qwghlm.org>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
 <5EC6F28C.3070807@gmail.com>
 <alpine.DEB.2.20.2005212243070.18317@pling.qwghlm.org>
Message-ID: <5EC6FA2A.5020801@gmail.com>

On 21-May-2020 22:50, Martin Keegan wrote:
> On Thu, 21 May 2020, Luke Emmet wrote:
>
>> If we force one line ending kind on authors, it will be a deterrent 
>> to them forging ahead with writing user content if they have to use 
>> some tool just to be able to get the content onto the server. Look at 
>> XHTML, it was a resounding failure and rejected by authors even 
>> though there were some good (and ill conceived) intentions of the 
>> spec writers.
>
> I believe there's a difference between requiring servers only to use 
> CRLF in the body, and content authors only to use CRLF. If it were 
> specified that servers "MUST NOT" send text/gemini bodies that use 
> line separators other than CRLF, then it remains up to server 
> implementers to choose whether
>
> 1) to require content authors to develop or save their content with 
> CRLFs, or
>
> 2) to translate the content themselves (either on the fly, or by
> caching a fettled version with the right line separators).

I see better now what the alternative suggestions are, thanks.

I still think a robust client has to in all likelihood anticipate both 
CRLF and LF. There will be a range of servers out there and just getting 
the content of the file sent to you isnt going to be unusual. Probably 
plain Mac/CR is too ancient to be widely found, but see below.

Another consideration that comes to me now is for any applications of 
Gemini that might require a binary correct transfer of a text file from 
A to B. For example if we are gemini as a content transfer layer for a 
source code repository. There is already a Git over gemini service which 
seems interesting. In these scenarios as the end user, you would expect 
that a GMI file served to you from the repo was the same as it is on the 
server. So I think we should support all "normal" plain text formats as 
the response body and not in general have the server munging or 
adjusting them.

Best Wishes

  - Luke

From jetkoten at gmail.com  Thu May 21 23:05:03 2020
From: jetkoten at gmail.com (=?UTF-8?B?4pyI5YCL5bGV?=)
Date: Thu, 21 May 2020 17:05:03 -0500
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521215209.GD1122@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <alpine.DEB.2.20.2005212213370.18317@pling.qwghlm.org>
 <CANW6ZfGYax9izKSMbUj3N468_vHpEks9Pt08Dp5jrypLuiHm=Q@mail.gmail.com>
 <20200521215209.GD1122@SDF.ORG>
Message-ID: <CANW6ZfHn+ZoZREyFAzBj3NDs_sqDBPk5mvJiOe4248QuHhBtpw@mail.gmail.com>

But is it a zero sum game like that really (either make it hard on server
authors or make it hard on content authors)?

The would-be Gemini content author at this point in the game will be
someone who either has created an SSH key and SSHed into a pubnix, used Git
to send their content to a Dome style server or used sftp to upload their
hand written Gemini text.

Is it truly making their life harder to enter:

gemini fmt mytext.gemini<Enter>

and thereby save the server and client authors from having to do all of
that checking logic? They're still are many other ways they can enjoy the
moving target development against an evolving spec aren't there?

:)

I hope my idea doesn't seem hostile somehow, because it's not intended to
be in any way. I just figure save everybody effort and complexity,
everybody wins? feed two birds with one seed.

Thanks

On Thu, May 21, 2020, 16:52 solderpunk <solderpunk at sdf.org> wrote:

> On Thu, May 21, 2020 at 04:28:19PM -0500, ??? wrote:
>
> > The people who are writing the server and client software are doing a
> huge
> > service to the Gemini community, so please don't saddle them with the
> > admittedly tedious work of writing code to check in the server and then
> > check again in the client if it is an improper combination of CR, LF or
> CR
> > LF and then even more code to re-conform it.
>
> I'd rather make life a little harder for developers - who are
> technical people who know what a CR and LF are and are, anyway, signing
> up for a bit of fiddly detail by undertaking to implement an internet
> protocol from scratch - than make life harder for content authors, who
> may have no idea what this nonsense is all about and are arguably doing
> an even bigger service for the community by providing something to use
> our present abundance of servers and clients to read.
>
> Sorry if this seems blunt!
>
> Cheers,
> Solderpunk
>
> > seems to go against the 100 lines of code, code it in a weekend Gemini
> > spirit in my opinion.
> >
> > Thanks for your consideration.
> >
> > J
> >
> > On Thu, May 21, 2020, 16:18 Martin Keegan <martin at no.ucant.org> wrote:
> >
> > > On Thu, 21 May 2020, solderpunk wrote:
> > >
> > > > We basically need to choose between forcing server authors to
> normalise
> > > > all endings to CRLF or forcing client authors to recgonise LF (even
> > > > though it'll probably never be seen in the wild).
> > >
> > > Could we have a bit of a breather to allow the implications to sink in,
> > > and, critically, to allow the development of conformance testing tools?
> > >
> > > If there were a tool which could be run on a document, that confirmed
> that
> > > it was conformant, and a similar tool for server behaviour, and people
> > > had had some time to try to integrate these with the existing
> > > software, it'd be easier to assess the tradeoffs involved in the spec
> > > decision.
> > >
> > > Mk
> > >
> > > --
> > > Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/0569461b/attachment.htm>

From mbrubeck at limpet.net  Fri May 22 01:45:20 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Thu, 21 May 2020 17:45:20 -0700
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200521204731.GA4116@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
Message-ID: <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>

On Thu, May 21, 2020 at 1:47 PM solderpunk <solderpunk at sdf.org> wrote:
> Some quick experimentation with Python revealed that str.splitlines()
> is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.

For what it's worth, the Rust standard library is designed to work
with both LF ("\n") and CRLF ("\r\n") line endings, but not CR alone
("\r"):
https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md

In the discussion that led to this, there was no real support for
supporting "\r" line endings, nor for other uncommon newlines like
U+2028 LINE SEPARATOR:
https://github.com/rust-lang/rfcs/pull/1212

I think text/gemini should allow both "\n" and "\r\n". Requiring a
single style would either place a burden on content authors (on
servers that don't auto-convert line endings), or make servers more
complex and less efficient. (They would need to inspect every
text/gemini file and possibly transform it, rather than stream it
directly from disk to the network.)  Meanwhile, I think client
software can handle either option fairly simply.

For the protocol header, I don't have a strong opinion. Any choice we
make is fairly easy to implement in both server and client. However, I
have a slight preference for specifying just "\n" as the header
terminator. One byte is (marginally) more efficient than two, and in
some languages it's slightly simpler to split on a single-byte
delimiter.

From nicole at strega-nil.co  Fri May 22 03:02:47 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Fri, 22 May 2020 02:02:47 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
Message-ID: <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>

I am a strong proponent of "follow the existing practice if there isn't good reason to change". I personally think CRLF should be recommended, but not required for content, as text/* is wont to do over HTTP; I think expecting clients to deal with any of {CR, LF, CRLF} is totally fine. However, the header should _absolutely_ end in CRLF, as every existing protocol works this way.


Nicole

??????? Original Message ???????
On Thursday, May 21, 2020 5:45 PM, Matt Brubeck <mbrubeck at limpet.net> wrote:

> On Thu, May 21, 2020 at 1:47 PM solderpunk solderpunk at sdf.org wrote:
>
> > Some quick experimentation with Python revealed that str.splitlines()
> > is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.
>
> For what it's worth, the Rust standard library is designed to work
> with both LF ("\n") and CRLF ("\r\n") line endings, but not CR alone
> ("\r"):
> https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md
>
> In the discussion that led to this, there was no real support for
> supporting "\r" line endings, nor for other uncommon newlines like
> U+2028 LINE SEPARATOR:
> https://github.com/rust-lang/rfcs/pull/1212
>
> I think text/gemini should allow both "\n" and "\r\n". Requiring a
> single style would either place a burden on content authors (on
> servers that don't auto-convert line endings), or make servers more
> complex and less efficient. (They would need to inspect every
> text/gemini file and possibly transform it, rather than stream it
> directly from disk to the network.) Meanwhile, I think client
> software can handle either option fairly simply.
>
> For the protocol header, I don't have a strong opinion. Any choice we
> make is fairly easy to implement in both server and client. However, I
> have a slight preference for specifying just "\n" as the header
> terminator. One byte is (marginally) more efficient than two, and in
> some languages it's slightly simpler to split on a single-byte
> delimiter.



From benulo at systemli.org  Fri May 22 03:12:30 2020
From: benulo at systemli.org (Ben)
Date: Fri, 22 May 2020 06:42:30 +0430
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
Message-ID: <9830f348-1086-46a3-58f7-a9cc057c7f3d@systemli.org>

Isn't CRLF a DOS/Windows thing? Why use it at all?

-- 
gemini://kwiecien.us/

From nicole at strega-nil.co  Fri May 22 03:14:48 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Fri, 22 May 2020 02:14:48 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <9830f348-1086-46a3-58f7-a9cc057c7f3d@systemli.org>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <9830f348-1086-46a3-58f7-a9cc057c7f3d@systemli.org>
Message-ID: <pWuFQDM8yIQ_xCSoUa83x4Ffn5GWuRqI5lWqVAy15LDiBPjs0B0rsVJY3vWyEwWCY_Z4d6XQ9XzPnmHiUbx2oe1mCFXujAIhdE3FHF2RWWQ=@strega-nil.co>

CRLF is the canonical representation of text/* file types; see https://tools.ietf.org/html/rfc2616#section-3.7.1


Nicole

??????? Original Message ???????
On Thursday, May 21, 2020 7:12 PM, Ben <benulo at systemli.org> wrote:

> Isn't CRLF a DOS/Windows thing? Why use it at all?
>
> -------------------------------------------------------
>
> gemini://kwiecien.us/



From mbrubeck at limpet.net  Fri May 22 03:22:19 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Thu, 21 May 2020 19:22:19 -0700
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
Message-ID: <CAD1=23kXdUqi+mNcUuFJr=FiZL4c2UyjU5BFMBA_vQ_+an1ybQ@mail.gmail.com>

On Thu, May 21, 2020 at 7:02 PM Nicole Mazzuca <nicole at strega-nil.co> wrote:
> However, the header should _absolutely_ end in CRLF, as every existing protocol works this way.

Yeah, that's fair. I?ve just caught up on the parts of this thread
that happened before I subscribed, and I agree that making the
protocol work the same as other line-based protocols is compelling.
(And Solderpunk said that this part is already decided, anyway, which
is fine.)

From plugd at thelambdalab.xyz  Fri May 22 08:01:45 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 22 May 2020 09:01:45 +0200
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
Message-ID: <lz5zcosbae.fsf@bs-mbpr348.d.ethz.ch>


jan6 at tilde.ninja writes:
> I'd also be in favor of server handling it, although that is a kinda-valid point...
> html doesn't count because the browsers will do their best to fix all kinds of TOTALLY BROKEN html,
> you can have partial tags, no end tags for some, etc, and the browser will never tell the user your
> site is a trashpile, it will just silently try its best to fix it up (even in inspect element,
> you'd see the "repaired" version)...

And this is exactly what's going to happen with gemini too.  The second
you have >=2 clients around, there's going to be a race to accept the
widest range of content, regardless of errors.  Besides pleaces where it
puts users' privacy/security at risk, clients can never be expected to
police complience of the document with the spec.  (After all, the client
user is almost always someone entirely unresponsible for the generation
of the document.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200522/fe16b1ef/attachment-0001.sig>

From solderpunk at SDF.ORG  Fri May 22 15:54:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 22 May 2020 14:54:55 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <9830f348-1086-46a3-58f7-a9cc057c7f3d@systemli.org>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <9830f348-1086-46a3-58f7-a9cc057c7f3d@systemli.org>
Message-ID: <20200522145455.GA22060@SDF.ORG>

On Fri, May 22, 2020 at 06:42:30AM +0430, Ben wrote:
> Isn't CRLF a DOS/Windows thing? Why use it at all?

It's not often I'll say anything that might be perceived as "sticking up
for Microsoft" in the context of storing text (I mean, really, Office
*still* doesn't use UTF-8 by default, and Excel uses different
delimiters in .csv files depending on the OS locale, making cross-locale
file exchange a pain), but we really shouldn't demonise them for using
CRLF (this is mostly in response, just to be clear, to a HN comment
calling CRLF something like "a Microsoft abomination".

It's true Windows is the only place using CRLF these days, but it's not
like the rest of the world has always use plain old LF and MS decided to
be different just for the sake of different.  DOS inherited CRLF from
CP/M, and Windows is just the "last man standing" from a long CRLF
tradition dating back to the days of physical teletypes, and which
included systems with a lot more geek street cred, like DEC's TOPS-10
and RT-11.

IETF's decision to use CRLF as the canonical form (which was apparently
mostly driven by Postel, according to
https://www.rfc-editor.org/old/EOLstory.txt) was a perfectly sensible
one at the time, when plain CR was also in use (on Macs, LISP machines
and many 8-bit home microcomputers), as it guaranteed lines would always
get split.

Anyway, I've made a deicision on this which, I'll post shortly.

Cheers,
Solderpunk

From plugd at thelambdalab.xyz  Fri May 22 16:01:34 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 22 May 2020 17:01:34 +0200
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200522145455.GA22060@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <9830f348-1086-46a3-58f7-a9cc057c7f3d@systemli.org>
 <20200522145455.GA22060@SDF.ORG>
Message-ID: <lzeerct3n5.fsf@bs-mbpr348.d.ethz.ch>

solderpunk writes:
> be different just for the sake of different.  DOS inherited CRLF from
> CP/M, and Windows is just the "last man standing" from a long CRLF
> tradition dating back to the days of physical teletypes, and which
> included systems with a lot more geek street cred, like DEC's TOPS-10
> and RT-11.

Which makes sense, given that you need a line feed to advance to the
next line, and a carriage return to return the carriage to the first
column.  :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200522/c0a3434c/attachment.sig>

From solderpunk at SDF.ORG  Fri May 22 16:02:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 22 May 2020 15:02:35 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <lz5zcosbae.fsf@bs-mbpr348.d.ethz.ch>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <lz5zcosbae.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <20200522150235.GB22060@SDF.ORG>

On Fri, May 22, 2020 at 09:01:45AM +0200, plugd wrote:
> 
> jan6 at tilde.ninja writes:
> > html doesn't count because the browsers will do their best to fix all kinds of TOTALLY BROKEN html,
> > you can have partial tags, no end tags for some, etc, and the browser will never tell the user your
> > site is a trashpile, it will just silently try its best to fix it up
> 
> And this is exactly what's going to happen with gemini too.

I kind of hope that it won't ever be possible for a text/gemini page to
*be* a trashpile.  It's genuinely very hard to create something
"invalid".  There is no concept of anything coming in opening/closing
pairs.  Whitespace is always optional so it doesn't matter whether it's
there or not.

A link line where the first thing after => can't be parsed as a URL is a
genuine invalidity, but remember that relative links are allowed, so
even:

=> one two three

is fine (a relative link to a path ending in "one", with label "two
three").  Something like:

=> foo://bar://baz:// Chew on this!

is a real problem, but it's not going to happen by accident.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Fri May 22 16:03:41 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 22 May 2020 15:03:41 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <lzeerct3n5.fsf@bs-mbpr348.d.ethz.ch>
References: <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <9830f348-1086-46a3-58f7-a9cc057c7f3d@systemli.org>
 <20200522145455.GA22060@SDF.ORG>
 <lzeerct3n5.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <20200522150341.GC22060@SDF.ORG>

On Fri, May 22, 2020 at 05:01:34PM +0200, plugd wrote:
 
> Which makes sense, given that you need a line feed to advance to the
> next line, and a carriage return to return the carriage to the first
> column.  :-)

Yeah, it's not even a "DEC thing", it's a "cold, hard, mechanical
reality" thing!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri May 22 17:07:30 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 22 May 2020 16:07:30 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <CAD1=23kXdUqi+mNcUuFJr=FiZL4c2UyjU5BFMBA_vQ_+an1ybQ@mail.gmail.com>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <CAD1=23kXdUqi+mNcUuFJr=FiZL4c2UyjU5BFMBA_vQ_+an1ybQ@mail.gmail.com>
Message-ID: <20200522160730.GD22060@SDF.ORG>

Thanks, everybody, for your thoughts on this matter!  I've made a
decision.

Let me start out by saying how thoroughly ridiculous it is that in 2020
people can still have spirited discussions about how the concept of "a
line of text" should work!  I hope that one day this is standardised
once and for all across all systems, but I won't hold my breath.

The line of thinking to my decision has gone something like this:

While it's true that the spec currently is totally ambiguous on what our
supposedly line-oriented format uses to define a line, and that's a
genuine problem which needs to be fixed because specs *shouldn't* be
ambiguous about this kind of thing (thanks to everybody who flagged this
issue!), it's also true that as far as I'm aware this ambiguity has
created precisely zero interoperability problems for anybody.

In a situation where some spec detail is ambiguous but everything is
working just fine 100%, the obvious default course of action should be
to codify whatever the current practice is.

That seems to be everybody using plain LF.  So, there would need to be a
very compelling reason *not* to allow plain LF.  I can't think of any
and nobody has mentioned any, so, first conclusion: plain LF has to be
allowed.

As previously noticed, it is already IETF-mandated that the canonical
representation of anything with a text/* MIME type is CRLF.  HTTP sets a
precedent of protocols being able to permit additional line endings on
top of that, but it seems a very different proposition for a protocol to
*disallow* use of the canonical representation.  So, second conclusion,
CRLF has to be allowed as well.

This leaves only the question of whether or not plain CR should be
allowed as a third option.  Given the complete absence of any
CR-separated content in Geminispace so far, the poor support for
CR-separated line recognition in contemporary programming languages (and
the consequent poor support for it in almost all extant Gemini cliens),
and the fact that mandatory TLS means anybody who really wants to
implement Gemini on an old CR-based system is going to have muuuuuch
bigger problems to worry about than translating line endings, this seems
very hard to justify.  I did previously have the notion that this was
somehow "the right thing to do", but having had to spend more time and
energy thinking about this issue than it really deserves, I'm a bit more
inclined to help "grease the wheels of history" on its clear path toward
reduced variability in such a fundamental matter.  LFCR is now well and
truly dead, and CR is very, very close to it.  It's clear that other new
technologies are choosing to leave it behind, so we might as well follow
suit and help the world get to a place of only having to worry about two
common EOLs instead of three (and may our grandchildren only have to
worry about one!).  Conclusion the third, let's not allow CR.

Since CRLF is the canonical form of all text/* subtypes, these changes
to the Gemini spec won't go in section 1.3.5 (which defines
text/gemini), but in section 1.3.3 (which defines response bodies in
general, and is where we e.g. define UTF-8 as the default encoding).  I
will probably borrow verbatim the wording used by the HTTP spec but just
leave out CR.

This solves the ambiguity of the spec on this matter, and should involve
very little actual work from anybody to attain/retain compliance - which
is exactly how it should be, given that everything is already working
just fine despite the ambiguity.  In particular, given the complete lack
of modern systems using anything other than LF or CRLF, server munging
should not be necessary and Gemini content can be served as verbatim
binary data from the filesystem, which is a very desirable property.

I'll make this change, along with the two other uncontroversial
housekeeping changes (mandating SNI and requiring response headers to
use exactly one space instead of arbitrary whitespace), tonight or
tomorow.  Then we can shift focus to more important things, like client
certificates.

Cheers,
Solderpunk


From luke.emmet at gmail.com  Fri May 22 17:13:33 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 22 May 2020 17:13:33 +0100
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200522160730.GD22060@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <CAD1=23kXdUqi+mNcUuFJr=FiZL4c2UyjU5BFMBA_vQ_+an1ybQ@mail.gmail.com>
 <20200522160730.GD22060@SDF.ORG>
Message-ID: <5EC7FA2D.2000709@gmail.com>


On 22-May-2020 17:07, solderpunk wrote:
> Thanks, everybody, for your thoughts on this matter!  I've made a
> decision
>
> <snip>
>
> This solves the ambiguity of the spec on this matter, and should involve
> very little actual work from anybody to attain/retain compliance - which
> is exactly how it should be, given that everything is already working
> just fine despite the ambiguity.  In particular, given the complete lack
> of modern systems using anything other than LF or CRLF, server munging
> should not be necessary and Gemini content can be served as verbatim
> binary data from the filesystem, which is a very desirable property

Not that you need my endorsement, but this gets a thankful thumbs up 
from me.

  - Luke

From peteyboy at sdf.org  Fri May 22 17:36:16 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Fri, 22 May 2020 09:36:16 -0700
Subject: Proposed minor spec changes, for comment. (???)
In-Reply-To: <mailman.189.1590130924.533.gemini@lists.orbitalfox.eu>
References: <mailman.189.1590130924.533.gemini@lists.orbitalfox.eu>
Message-ID: <31937A90-46B0-4351-B810-479FC3A36A0D@sdf.org>

My only two Gemini files were composed in nano in sdf shell. I like being able to just write a file and not worry about stuff.

Also the point someone made about git is, I think, something to consider wrt jacking around with file contents vs just working with them.



On May 22, 2020 12:02:04 AM PDT, 
>Message: 1
>Date: Thu, 21 May 2020 17:05:03 -0500
>From: ??? <jetkoten at gmail.com>
>To: "A protocol that is slightly more complex than gopher, but
>	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>Subject: Re: Proposed minor spec changes, for comment.
>Message-ID:
>	<CANW6ZfHn+ZoZREyFAzBj3NDs_sqDBPk5mvJiOe4248QuHhBtpw at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>But is it a zero sum game like that really (either make it hard on
>server
>authors or make it hard on content authors)?
>
>The would-be Gemini content author at this point in the game will be
>someone who either has created an SSH key and SSHed into a pubnix, used
>Git
>to send their content to a Dome style server or used sftp to upload
>their
>hand written Gemini text.
>
>Is it truly making their life harder to enter:
>
>gemini fmt mytext.gemini<Enter>
>
>and thereby save the server and client authors from having to do all of
>that checking logic? They're still are many other ways they can enjoy
>the
>moving target development against an evolving spec aren't there?
>
>:)
>
>I hope my idea doesn't seem hostile somehow, because it's not intended
>to
>be in any way. I just figure save everybody effort and complexity,
>everybody wins? feed two birds with one seed.
>
>Thanks
>
>On Thu, May 21, 2020, 16:52 solderpunk <solderpunk at sdf.org> wrote:
>
>> On Thu, May 21, 2020 at 04:28:19PM -0500, ??? wrote:
>>
>> > The people who are writing the server and client software are doing
>a
>> huge
>> > service to the Gemini community, so please don't saddle them with
>the
>> > admittedly tedious work of writing code to check in the server and
>then
>> > check again in the client if it is an improper combination of CR,
>LF or
>> CR
>> > LF and then even more code to re-conform it.
>>
>> I'd rather make life a little harder for developers - who are
>> technical people who know what a CR and LF are and are, anyway,
>signing
>> up for a bit of fiddly detail by undertaking to implement an internet
>> protocol from scratch - than make life harder for content authors,
>who
>> may have no idea what this nonsense is all about and are arguably
>doing
>> an even bigger service for the community by providing something to
>use
>> our present abundance of servers and clients to read.
>>
>> Sorry if this seems blunt!
>>
>> Cheers,
>> Solderpunk
>>
>> > seems to go against the 100 lines of code, code it in a weekend
>Gemini
>> > spirit in my opinion.
>> >
>> > Thanks for your consideration.
>> >
>> > J
>> >
>> > On Thu, May 21, 2020, 16:18 Martin Keegan <martin at no.ucant.org>
>wrote:
>> >
>> > > On Thu, 21 May 2020, solderpunk wrote:
>> > >
>> > > > We basically need to choose between forcing server authors to
>> normalise
>> > > > all endings to CRLF or forcing client authors to recgonise LF
>(even
>> > > > though it'll probably never be seen in the wild).
>> > >
>> > > Could we have a bit of a breather to allow the implications to
>sink in,
>> > > and, critically, to allow the development of conformance testing
>tools?
>> > >
>> > > If there were a tool which could be run on a document, that
>confirmed
>> that
>> > > it was conformant, and a similar tool for server behaviour, and
>people
>> > > had had some time to try to integrate these with the existing
>> > > software, it'd be easier to assess the tradeoffs involved in the
>spec
>> > > decision.
>> > >
>> > > Mk
>> > >
>> > > --
>> > > Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
>> > >
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/0569461b/attachment-0001.htm>
>
>------------------------------
>
>Message: 2
>Date: Thu, 21 May 2020 17:45:20 -0700
>From: Matt Brubeck <mbrubeck at limpet.net>
>To: "A protocol that is slightly more complex than gopher, but
>	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>Subject: Re: Proposed minor spec changes, for comment.
>Message-ID:
>	<CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg at mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>On Thu, May 21, 2020 at 1:47 PM solderpunk <solderpunk at sdf.org> wrote:
>> Some quick experimentation with Python revealed that str.splitlines()
>> is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.
>
>For what it's worth, the Rust standard library is designed to work
>with both LF ("\n") and CRLF ("\r\n") line endings, but not CR alone
>("\r"):
>https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md
>
>In the discussion that led to this, there was no real support for
>supporting "\r" line endings, nor for other uncommon newlines like
>U+2028 LINE SEPARATOR:
>https://github.com/rust-lang/rfcs/pull/1212
>
>I think text/gemini should allow both "\n" and "\r\n". Requiring a
>single style would either place a burden on content authors (on
>servers that don't auto-convert line endings), or make servers more
>complex and less efficient. (They would need to inspect every
>text/gemini file and possibly transform it, rather than stream it
>directly from disk to the network.)  Meanwhile, I think client
>software can handle either option fairly simply.
>
>For the protocol header, I don't have a strong opinion. Any choice we
>make is fairly easy to implement in both server and client. However, I
>have a slight preference for specifying just "\n" as the header
>terminator. One byte is (marginally) more efficient than two, and in
>some languages it's slightly simpler to split on a single-byte
>delimiter.
>
>
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From plugd at thelambdalab.xyz  Fri May 22 17:44:52 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 22 May 2020 18:44:52 +0200
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200522150235.GB22060@SDF.ORG>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <lz5zcosbae.fsf@bs-mbpr348.d.ethz.ch> <20200522150235.GB22060@SDF.ORG>
Message-ID: <lzblmfudff.fsf@bs-mbpr348.d.ethz.ch>

solderpunk writes:
> On Fri, May 22, 2020 at 09:01:45AM +0200, plugd wrote:
>> And this is exactly what's going to happen with gemini too.
>
> I kind of hope that it won't ever be possible for a text/gemini page to
> *be* a trashpile.  It's genuinely very hard to create something
> "invalid".  There is no concept of anything coming in opening/closing
> pairs.  Whitespace is always optional so it doesn't matter whether it's
> there or not.

Definitely agree, at the moment it all seems very close to optimal.  And
sorry, I didn't mean to sound so defeatist!  I was just getting worried
that some of the ideas being proposed for closing exploitation holes in
text/gemini were of this "unenforceable" variety.

> A link line where the first thing after => can't be parsed as a URL is a
> genuine invalidity, but remember that relative links are allowed, so
> even:
>
> => one two three
>
> is fine (a relative link to a path ending in "one", with label "two
> three").  Something like:
>
> => foo://bar://baz:// Chew on this!
>
> is a real problem, but it's not going to happen by accident.

True. And _all_ clients would have to go out of their way and conspire
together to interpret this as anything but garbage.

... then again, if clients start to act defensively and ignore malformatted link
lines, it wouldn't be impossible for document authors to start
incorporating intentionally malformatted lines containing non-standard
directives:

=> foo://bar://inline-image:cat.jpg

Has anybody developed a general theory of specification creep? :-)

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200522/0ead0cbb/attachment.sig>

From spf at flowkarma.live  Fri May 22 18:24:55 2020
From: spf at flowkarma.live (Simon Forman)
Date: Fri, 22 May 2020 10:24:55 -0700
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <5EC7FA2D.2000709@gmail.com>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <CAD1=23kXdUqi+mNcUuFJr=FiZL4c2UyjU5BFMBA_vQ_+an1ybQ@mail.gmail.com>
 <20200522160730.GD22060@SDF.ORG> <5EC7FA2D.2000709@gmail.com> 
Message-ID: <20200522172455.98BDCE07A3@smtp.hushmail.com>

On 5/22/2020 at 9:13 AM, "Luke Emmet" <luke.emmet at gmail.com> wrote:
>
>On 22-May-2020 17:07, solderpunk wrote:
>> Thanks, everybody, for your thoughts on this matter!  I've made a
>> decision
>>
>Not that you need my endorsement, but this gets a thankful thumbs 
>up 
>from me.

Ditto.  This seems very well thought out to me.  Kudos!

~Simon


From solderpunk at SDF.ORG  Fri May 22 18:26:36 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 22 May 2020 17:26:36 +0000
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <20200522172455.98BDCE07A3@smtp.hushmail.com>
References: <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <20200518223715.iysu4hsc57bwa465@enzo.thebackupbox.net>
 <20200519074625.GD4068@SDF.ORG> <20200521204731.GA4116@SDF.ORG>
 <CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg@mail.gmail.com>
 <RqbCjyEwZzDgKkCXsCPDi0_C9lSGwO6HhImf760ciszHLTMm--FI2vzhqjgSC9rdX6Am0EedtIdDy5l50Bna55ZBkzy1m5ZQd_3o3hTCPQ8=@strega-nil.co>
 <CAD1=23kXdUqi+mNcUuFJr=FiZL4c2UyjU5BFMBA_vQ_+an1ybQ@mail.gmail.com>
 <20200522160730.GD22060@SDF.ORG> <5EC7FA2D.2000709@gmail.com>
 <20200522172455.98BDCE07A3@smtp.hushmail.com>
Message-ID: <20200522172636.GA17110@SDF.ORG>

On Fri, May 22, 2020 at 10:24:55AM -0700, Simon Forman wrote:
> On 5/22/2020 at 9:13 AM, "Luke Emmet" <luke.emmet at gmail.com> wrote:
> >
> >On 22-May-2020 17:07, solderpunk wrote:
> >> Thanks, everybody, for your thoughts on this matter!  I've made a
> >> decision
> >>
> >Not that you need my endorsement, but this gets a thankful thumbs 
> >up 
> >from me.
> 
> Ditto.  This seems very well thought out to me.  Kudos!
> 

Thank you both!

Cheers,
Solderpunk


From sean at conman.org  Fri May 22 20:35:42 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 22 May 2020 15:35:42 -0400
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <lzblmfudff.fsf@bs-mbpr348.d.ethz.ch>
References: <20200518215145.drc5qnigdb6cd522@vineta.saintnet.lan>
 <20200518203544.GA23608@SDF.ORG>
 <ee7785a80639428d0cf9c902a9d67ec8@tilde.ninja>
 <lz5zcosbae.fsf@bs-mbpr348.d.ethz.ch> <20200522150235.GB22060@SDF.ORG>
 <lzblmfudff.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <20200522193542.GN30203@brevard.conman.org>

It was thus said that the Great plugd once stated:
> 
> Has anybody developed a general theory of specification creep? :-)

  Yes.  There's Zawinski's Law:  Every program attempts to expand until it
can read mail. Those programs which cannot so expand are replaced by ones
which can.

  You can read some commentary about it from these links:

https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles
https://softwareengineering.stackexchange.com/questions/150254/what-does-jamie-zawinskis-law-mean

  -spc (Every program has at least one bug and can be shortened by at least
	one instruction---from which, by induction, one can deduce that
	every program can be reduced to one instruction which doesn't work. [1])

[1]	This actually happened.  Not to me, but I know of such a case.


From epoch at enzo.thebackupbox.net  Sat May 23 01:32:45 2020
From: epoch at enzo.thebackupbox.net (epoch)
Date: Fri, 22 May 2020 19:32:45 -0500
Subject: Proposed minor spec changes, for comment.
In-Reply-To: <KQ938L_HQ7E0TGiP5YkbPGELmhcCtKgrwoHi9-g42jaFCRwrmVuiLd649Pzfws_I0JozXkiVeC90guUs6DpJ7XXgti-bDztPYgMwN4aqhq4=@protonmail.com>
References: <20200518211347.GC23608@SDF.ORG> <20200518203544.GA23608@SDF.ORG>
 <20200518210340.GD30203@brevard.conman.org>
 <cb3824778cd51d13759f415c8c9834dc@tilde.ninja>
 <20200519000753.GE30203@brevard.conman.org>
 <KQ938L_HQ7E0TGiP5YkbPGELmhcCtKgrwoHi9-g42jaFCRwrmVuiLd649Pzfws_I0JozXkiVeC90guUs6DpJ7XXgti-bDztPYgMwN4aqhq4=@protonmail.com>
Message-ID: <20200523003245.5e7ghmig7sqnxlat@enzo.thebackupbox.net>

On Tue, May 19, 2020 at 09:21:13AM +0000, defdefred wrote:
> On Tuesday 19 May 2020 02:07, Sean Conner <sean at conman.org> wrote:
> 
> > I thought about autodetection---Unicode is defined in blocks, where each
> > alphabet becomes a defined block in Unicode. I then realized that there are
> > multiple languages that use the European block. Sure, detecting Greek is
> > easy since they have their own alphabet, but what about Spanish, French and
> > German? They use the same alphabet.
> 
> Autodetection is necessary for document using multiple languages.
> Browser preference is fine for hard to detect case.
> 

I was thinking, maybe add a "lang" parameter to the end of mime-types, like how charset and boundary work.

Then, if people want multiple languages per-"document"? I guess per-response. They can use
mime multipart, then when the mime-type for each part is picked, they can put the language there.

That doesn't really help with "inline" different languages. Example gemini response:

20 multipart/mixed; boundary=longrandomthing
--longrandomthing
Content-Type: text/plain; lang=en-US

color. withOUT a 'u'. ha.
--longrandomthing
Content-Type: text/plain; lang=jp

[insert some japanese here]
--longrandomthing--


This document seems like it might come in handy:

https://www.w3.org/International/articles/language-tags/

From sathariel at airmail.cc  Sat May 23 06:20:01 2020
From: sathariel at airmail.cc (Sathariel)
Date: Sat, 23 May 2020 00:20:01 -0500
Subject: Zain, a Tcl/Tk gemini client
Message-ID: <20200523002001.c2df6d61d70437fdcbb28282@airmail.cc>

I started to write a gemini client in Tcl/Tk the last weekend. I'm not a programmer, but i wanted to try this and learn on the way. It also served to introduce some of my friends to the gemini universe. I'm willing to know what you think about this little project.

Git repository: https://gitgud.io/sathariel/zain
Gemini site: gemini://sathariel.tk/zain/

-- 
Sathariel <sathariel at airmail.cc>

From luke.emmet at gmail.com  Sat May 23 07:49:03 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sat, 23 May 2020 07:49:03 +0100
Subject: Gemini and CGI hosting
Message-ID: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>

Hi everyone

Can anyone suggest or recommend a server or host where I can make a simple Gemini capsule serving static gmi files, but also CGI scripts?

I'm interested to see what kind of simple applications can be written and delivered over Gemini space.

I'd rather not get into setting up my own server at this stage, if I can avoid it.

Feel free to reply or send a personal message.

Many thanks

Luke

From solderpunk at SDF.ORG  Sat May 23 10:07:41 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 09:07:41 +0000
Subject: Zain, a Tcl/Tk gemini client
In-Reply-To: <20200523002001.c2df6d61d70437fdcbb28282@airmail.cc>
References: <20200523002001.c2df6d61d70437fdcbb28282@airmail.cc>
Message-ID: <20200523090741.GA18311@SDF.ORG>

On Sat, May 23, 2020 at 12:20:01AM -0500, Sathariel wrote:
> I started to write a gemini client in Tcl/Tk the last weekend. I'm not a programmer, but i wanted to try this and learn on the way. It also served to introduce some of my friends to the gemini universe. I'm willing to know what you think about this little project.
 
It seemed to work quite nicely for me, based on a quick test.  Nice to
see a Gemini client which is quick and easy to get working for somebody
who doesn't know the development language/environment!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat May 23 10:59:05 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 09:59:05 +0000
Subject: Updates to Gemini FAQ
Message-ID: <20200523095905.GB18311@SDF.ORG>

Hey there Geminauts!

I have just made some changes to the official Gemini FAQ at:

gemini://gemini.circumlunar.space/docs/faq.txt
gopher://gemini.circumlunar.space/0/docs/faq.txt
https://gemini.circumlunar.space/docs/faq.txt

I updated section 1.3 to mention that the mailing list archives are
accessible via Gemini, and mentioned the #gemini channel at tilde.chat.

Section 3 is entirely new and attempts to provide some advice for
newcomers to Geminispace.  In particular, please note that I am now
trying to list places where people who don't want to or can't run their
own server can find hosting.  I have added a few places I am aware of
off the top of my head, but if you provide hosting and you're not
listed but would like to be, please let me know!  If you are already
listed but you'd rather remain underground, let me know too and I'll
remove you.

Section 4 is also entirely new and provides pointers on contributing to
the community, but there is not much there yet.

Suggestions for new questions to cover in sections 3 and 4 are very
welcome!

I am considering migrating the FAQ and other essential docs to a
non-commercial git host somewhere to make it easier for other people to
take an active hand in maintaining them or proposing changes.  Feedback
on this idea is welcome too!

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sat May 23 11:03:40 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 10:03:40 +0000
Subject: Updates to Gemini best practices
Message-ID: <20200523100340.GA12486@SDF.ORG>

Hello again!

I have also just made changes to the official "best practices" document
at:

* gemini://gemini.circumlunar.space/docs/best-practices.txt
* gopher://gemini.circumlunar.space/0/docs/best-practices.txt
* https://gemini.circumlunar.space/docs/best-practices.txt

There is a new section on TLS cipher suites wherein it is recommended
that anybody who is supporting TLS 1.2 (which is optional according to
the spec, but more or less a practical requirement at this point in
order to be able to communicate with clients/servers using e.g. LibreSSL
or BearSSL) supports only a minimal subset of it to provide similar
security to TLS 1.3.

This might be a nice thing for server testing tools (like
gemini-diagnostics) to optionally test!

Cheers,
Solderpunk

PS: You can all guess what the next email will be...

From solderpunk at SDF.ORG  Sat May 23 11:26:51 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 10:26:51 +0000
Subject: [SPEC-CHANGE] Small housekeeping updates
Message-ID: <20200523102651.GB12486@SDF.ORG>

Ahoy!

I pushed some small changes to the Gemini specification this morning,
which you can see at:

* gemini://gemini.circumlunar.space/docs/spec-spec.txt
* gopher://gemini.circumlunar.space/0/docs/spec-spec.txt
* https://gemini.circumlunar.space/docs/spec-spec.txt

These are fairly small, house-keeping style changes being made in
advance of the formal "unfreezing" of the spec come June.  Most
server/client implementations should need only minor changes if any to
keep up with these, but authors, please do check/test rather than
assuming!

SUMMARY OF CHANGES:

Response headers now must use only a single space character to separate
the <META> content from the status code, instead of a mix of one-or-more
spaces and tabs (see section 1.3.1).  This means the maximum size of a
valid response header is now 1029 bytes (including the CRLF), whereas
before it was unbounded.

It is now specified that content with a text/* media type may be
transferred via Gemini using bare LF line separators as well as the
canonical CRLF (see section 1.3.3).

Use of the Server Name Indication (SNI) extension to TLS is now
mandatory (see section 1.4)

IMPLICATIONS FOR SERVER AUTHORS:

If your server is using a tab character to separate status codes from
<META> content, you MUST switch to using a space.

IMPLICATIONS FOR CLIENT AUTHORS:

Client authors of a Postelian inclination probably don't need to change
anything in response to the change of response headers.  If you really
want to you MAY refuse to parse headers using non-compliant whitespace,
but this will probably just require adding ugly code for little
benefit.

Check that your client can handle text/gemini content with
CRLF-separated lines without visibly displaying the CR.  If you are
using built-in line splitting tools from your programming languages
standard library, chances are very good you are already fine in this
regard.

If your client is not using SNI, you MUST start using it.

IMPLICATIONS FOR CONTENT AUTHORS:

If you author your Gemini content on a pre-OS X Apple computer, '70s or
'80s vintage 8-bit microcomputer or MIT LISP machine, you should take
care to convert your line endings to CR or CRLF before uploading it to
your server of choice, or write your own server which does the
conversion before you.  Please let the list know more about your amazing
life decisions!

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sat May 23 14:28:39 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 13:28:39 +0000
Subject: Call for AV-98 testing
Message-ID: <20200523132839.GD12486@SDF.ORG>

Hey folks,

I'm preparing to finally do a 1.0.0 release of AV-98 this weekend and
would appreciate people helping me kick the tyres.  Once the release is
made you'll be able to install it with pip, but for now you need to
clone the repo:

https://tildegit.org/solderpunk/AV-98/

There's a setup.py in there if you want to install it yourself, but it
has no essential third party dependencies and it's all in a single file
so you can just run av98.py from right where you clone it, easy peasy.

The release is mostly for the sake of easier installation, and for
everyday use you won't notice much new if you are already used to how
AV-98 works.  But there have been substantial changes to the TLS-side
of things.

Firstly, you can now toggle between two methods of TLS certificate
validation (AV-98, until now, did no verification whatsoever, an
embarrassing reminder of it's "hacked together quickly in response to
the surprise experience of an actual, live Gemini server" legacy).

With `set tls_mode tofu` (the default), you get the TOFU validation mode
I initially envisioned for Gemini.  When you first visit a server, the
received certificate is blindly trusted.  An SQLite database is
maintained with the fingerprints of trusted certificates, a count of how
many times they've been seen and the dates they were first and most
recently seen.  If you ever subsequently see a different certificate for
that host, you get a warning with details on how often the previous cert
was seen and when it is/was due to expire, to inform your decision on
whether or not to accept it.

Note that it's not required, but the TOFU mode works beter if you have
the `cryptography` module installed - certificates won't be blindly
accepted if they are expired, or not yet valid, or don't have a common
name or subject alternate name matching the expected hostname.  Python's
standard `ssl` module doesn't let you check this for self-signed
certificates (really!).

In TOFU-mode there's a lot of creation of files and directories and this
is largely what I'm hoping to discover bugs in by getting people to try
this out.

With `set tls_mode ca` (which you can stick in an RC file to make your
permanent setting), AV-98 will do typical CA-based validation using your
platform's default trusted certificates, and will refuse to accept
self-signed certificates.

For now I'm still wimping out on setting a hard requirement on TLS cert
validation in the spec (which allows whatever the client likes - but
clients really should be extremely upfront with users about what they
are doing!).  But for my part I am pretty committed to experimenting
with less centralised and less commercial alternatives to the CA system
and I'll probably end up building a lot more options into AV-98's TOFU
mode to reduce the risk associated with the initial acceptance.  I'm
taking a lot of inspiration and ideas from DNS-based solutions like
DANE, and from projects like Perspectives and Convergence.  I'm happy to
discuss them with interested folks.

Secondly, there is now a "client certificate manager" which is accessed
via the `cert` command.  Use of client certificates in Gemini is
currently under-specced and (perhaps as a partial consequence)
under-used, and I want to correct this in the near future.  So I threw
some stuff together in AV-98 to give us concrete ideas to discuss and
test.  None of how this functions is "canonical" yet - I'm embracing the
notion of AV-98 as an experimental client where we test stuff out.

For now, the client certificate manager relies on the `openssl` command
line tool being available to run with `system()`, because this is a
whole world of pain less than doing it in Python.

When it receives a 60, 61 or 62 status code, AV-98 will pop up a
notification and give the use the option to generate a client
certificate to use when re-requesting the resource, or to load a
previously generated (non-transient!) certificate from the filesystem.
When client certificates are *not* being used, the AV-98> prompt now
appears in a happy, friendly lime green colour.  As soon as a client
certificate is loaded, the prompt becomes a scary deep red and displays
as "AV-98+cert>".  If, while a client cert is loaded, you try to
navigate away to a different domain, AV-98 will warn you and give you a
Y/N dialogue to deactivate the cert before continuing, to avoid
"identity leak".  If you subsequently navigate back, during the same
session (I mean AV-98 session here, i.e. you haven't exited and
restarted the program), to a domain where you previously used a client
cert, you'll be asked if you want to load it again.  You can use the
`cert` command to explicitly end a client certificate session any time
you like.

It's all a bit clunky and explicit for now (although to some extent
that's a good thing because people should be *aware* of how they use
client certs), but it's definitely a huge improvement over previous
options for occasionally keeping an eye on your astrobotany plant!

I will make a separate more detailed post later about client
certificates and the things we should think about with regard to them.

That's about it!  Thanks to anybody who tests out, bug reports welcome
via email or at https://tildegit.org/solderpunk/AV-98/issues.

Cheers,
Solderpunk


From tiwesdaeg at tilde.pink  Sat May 23 14:33:04 2020
From: tiwesdaeg at tilde.pink (tiwesdaeg at tilde.pink)
Date: Sat, 23 May 2020 13:33:04 +0000 (UTC)
Subject: Gemini and CGI hosting
In-Reply-To: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>
References: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>
Message-ID: <alpine.NEB.2.21.2005231332370.14453@tilde.pink>

Luke,

I'm looking in to this on tilde.pink. So far, the only way I could get a 
cgi script located in a user directory to work was to create a symbolic 
link directly to /var/gemini/cgi-bin/. So far, no one has implemented a 
server that acts like gophernicus or geomyidae, allowing for scripts to be 
run from any served directory.

I don't know how this is handled by webservers that support ~user 
accounts.

-Tiwesdaeg

On Sat, 23 May 2020, Luke Emmet wrote:

> Hi everyone
>
> Can anyone suggest or recommend a server or host where I can make a simple Gemini capsule serving static gmi files, but also CGI scripts?
>
> I'm interested to see what kind of simple applications can be written and delivered over Gemini space.
>
> I'd rather not get into setting up my own server at this stage, if I can avoid it.
>
> Feel free to reply or send a personal message.
>
> Many thanks
>
> Luke

From solderpunk at SDF.ORG  Sat May 23 14:35:32 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 13:35:32 +0000
Subject: Gemini and CGI hosting
In-Reply-To: <alpine.NEB.2.21.2005231332370.14453@tilde.pink>
References: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>
 <alpine.NEB.2.21.2005231332370.14453@tilde.pink>
Message-ID: <20200523133532.GF12486@SDF.ORG>

I'd love for Molly Brown and hence gemini.circumlunar.space to support
this, but until Go gets properly setuid support I just can't do it
securely, unfortunately.  Or until the FastGCI / SCGI idea gets polished
a bit more.  I know 80h has done some work on that front and I've been
meaning to ask for details.

Cheers,
Solderpunk

On Sat, May 23, 2020 at 01:33:04PM +0000, tiwesdaeg at tilde.pink wrote:
> Luke,
> 
> I'm looking in to this on tilde.pink. So far, the only way I could get a cgi
> script located in a user directory to work was to create a symbolic link
> directly to /var/gemini/cgi-bin/. So far, no one has implemented a server
> that acts like gophernicus or geomyidae, allowing for scripts to be run from
> any served directory.
> 
> I don't know how this is handled by webservers that support ~user accounts.
> 
> -Tiwesdaeg
> 
> On Sat, 23 May 2020, Luke Emmet wrote:
> 
> > Hi everyone
> > 
> > Can anyone suggest or recommend a server or host where I can make a simple Gemini capsule serving static gmi files, but also CGI scripts?
> > 
> > I'm interested to see what kind of simple applications can be written and delivered over Gemini space.
> > 
> > I'd rather not get into setting up my own server at this stage, if I can avoid it.
> > 
> > Feel free to reply or send a personal message.
> > 
> > Many thanks
> > 
> > Luke

From gmym at coopdot.com  Sat May 23 15:18:24 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sat, 23 May 2020 16:18:24 +0200
Subject: [SPEC-CHANGE] Small housekeeping updates
In-Reply-To: <20200523102651.GB12486@SDF.ORG>
References: <20200523102651.GB12486@SDF.ORG>
Message-ID: <CAObwWNgDxJ33Cp=zkqJ_0aB53czvnPHdgdJUXDm+QNSAsry59w@mail.gmail.com>

solderpunk <solderpunk at sdf.org> wrote:

> If you author your Gemini content on a pre-OS X Apple computer, '70s or
> '80s vintage 8-bit microcomputer or MIT LISP machine, you should take
> care to convert your line endings to CR or CRLF before uploading it to
> your server of choice, or write your own server which does the
> conversion before you.  Please let the list know more about your amazing
> life decisions!
>

You mean "convert your line endings to LF or CRLF", right?

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200523/b7860ca0/attachment.htm>

From solderpunk at SDF.ORG  Sat May 23 15:56:38 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 14:56:38 +0000
Subject: Client certificate musings
Message-ID: <20200523145638.GG12486@SDF.ORG>

Howdy,

It's time to start thinking hard about client certificates.

A super quick introduction for the unaware: everyone is (hopefully!)
familiar with the idea that when you make a TLS connection to a server,
the server provides a certificate (basically a public key plus some
metadata, signed - directly or via a chain - by a trusted third party).
This is supposed to convince you that you've connected to who you think
you have.  What some may not know is that TLS allows clients to send a
certificate to the server as well.  This never (or almost never) happens
on the web, where clients typically authenticate using a username and
password inside a cookie-powered session.

I first learned about client certificates in the murky, distant past
when the "semantic web" was a hot topic, in the context of the
decentralised "Friend Of a Friend" social network idea.  You can read
about FOAF+SSL at https://www.w3.org/wiki/Foaf+ssl.

Gemini specs a lot of use for client certificates - partially because
they're a nice tool for the job, partially because the design goal of
maximising power-to-weight ratio means once you accept the weight of
using TLS you'd better implement everything you can using TLS rather
than adding yet another pile of concepts.

The current rough spec fairly clearly outlines two usage scenarios for
client certificates.

One is where you want to restrict access to some Gemini resource to a
limited set of clients, e.g. you want to be able to check a webcam at
your home via Gemini from your office while at work, or via your phone,
but you don't want to open up access to the whole world.  So, you
generate a self-signed certificate on your office computer or your
phone, and manually add its fingerprint to a whitelist on your home
server, and nobody else is allowed in.  This is entirely analogous to
the way many of you are probably familiar with of logging into a server
over ssh using a private key.  It works the same way and has the same
pros/cons (e.g. can't be brute forced, is limited to devices with the
right keys installed).

This is pretty explicitly supported in Gemini via status code 62 to
request such a certificate and 63 to reject one not on the whitelist.
It is actually implemented at gemini://gemini.conman.org/, if you want
to play around with this.

I'm not sure there's much more to consider for this scenario.  Because
in a whitelisting scenario the server and client are typically both
under some degree of control by the same person, people can handle
expiry/renewal however they want and the spec should stay silent on
this.

The second scenario involves transient client certificates.  These are
basically an alternative to cookie-powered sessions in HTTP(S).  A
client generates a self-signed certificate and uses it for some
requests so that the server can recognise consecutive requests as coming
from the same location, and use the certificate fingerprint as a key in
a database to maintain state between requests.  This allows, e.g. using
a long series of status code 10 responses to basically "fill out a
form", e.g. in signing a guest book there could be separate prompts for
a name, email address or URL, plus guest book comment.  You could
actually build fairly extensive command-line applications using this
paradigm (they'd suck in a graphical browser that kept popping up input
windows, but in something like AV-98 the experience would be a lot
smoother).

Anyway, the appeal of using client certificates for sessions is that:

* They have to be generated by the client and sent to the server,
  instead of the other way around, so they are fundamentally opt-in
* If the client deletes them the server cannot possibly recreate the
  session after recognising the client based on IP address or anything
  else because the private key is gone, so the client can always
  unilaterally opt-out whenever they want
* They are very hard to hi-jack because the private key never travels
  over the network

Compared to cookies they are more secure and put the client in control.

Gemini allows for transient sessions using the 61 and 21 status codes.
61 requests the start of a session, which clients can always refuse to
do.  21 allows servers to signal the termination of a session and
clients should immediately and permanently delete the corresponding
keypair upon receiving it.

Until very recently, I don't think any of this was implemented anywhere.
AV-98 now recognises these codes and reacts appropriately.  I tested it
with a purpose-built dummy server which does nothing but send these
codes.  I am hoping we can soon start to explore this mechanism more,
but there are some things to discuss:

* Some TLS libraries have default values for the various conventional
  fields that go in the "Subject" metadata of the cert - company names,
  countries, states, etc.  These leak information about which TLS
  library the client is using and in this way facilitate a weaker
  version of the dreaded "browser fingerprint".  Since transient
  certificates are by design supposed to be short lived and in no way
  tied to any permanent notion of identity, it follows that they should
  not have any meaningful metadata associated with them, and therefore
  we should spec something to ensure this.  Right now, AV-98 fills the
  "Subject" of transient certs with random unique values from Python's
  `uuid` module, because I seemed to encounter errors sending totally
  empty certificates to conman.org.  I don't know if the X509 spec
  allows empty certs, and even if it does I don't know whether all
  popular TLS libraries accept them without choking.
* We should specify a fixed validity time for the certificate, again
  because if we don't different clients will do different things and
  certs will become weakly fingerprintable.  AV-98 uses 24 hours, which
  seems reasonable to me.

There is a third scenario, which the spec does not explicitly discuss at
all, but which is actually the most widely used scenario in Geminispace
so far, which is the main reason that I want to kick off a discussion
about this and change the spec if required.  It's the idea of persistent
identity (basically, a "user account") at a server which is not under
the client's control.  The persistent part differentiates this scenario
from the clearly defined transient certificates, and the lack of
combined control differentiates it from the previously discussed
ssh-style whitelist scenario.  This is exactly the scenario which holds
with the astrobotany.mozz.us application.

Astrobotany currently requires users to generate a CSR for their
certificate, which is submitted to mozz.us over HTTPS, which signs
whatever it sees.  This is cumbersome for the user, and doesn't actually
achieve anything because the signing is done unconditionally.  Everybody
involved agrees this should be done differently.  The reason it turned
out like it has is because of the extreme lack of detail in the cert on
anything to do with client certificates, but with this particular
scenario in particular.

Right now, the spec describes status code 62 (originally intended for
whitelisting scenarios) with "This resource is protected and a client
certificate which the server accepts as valid must be used - a
disposable key/cert generated on the fly in response to this status is
not appropriate as the server will do something like compare the
certificate fingerprint against a white-list of allowed certificates".
This *could* be relaxed a bit to make it clear that the client *can* try
generating a cert in response to the status, but that the server may not
accept it.  This would allow e.g. astrobotany to send a 62 to a new
user, for the user to generate a non-disposable self-signed cert and
send it back, and for astrobotany to immediatley accept the cert and
connect its fingerprint to a user ID in its database.  This is basically
the smallest possible change to the spec which permits a much more
streamlined version of the way astrobotany currently works.  AV-98 is
ready right now to work with applications using this paradigm.

But, I don't know if it makes more sense to introduce new 6x codes to
explicitly separate this scenario from the whitelisted cert scenario.
If we don't do this, clients may waste time prompting their users to
generate a cert to send to a server which is never going to accept it,
which may confused users.

We could change 62 to specify that the META should be a plain-language
message to users, which could disambiguate the scenario.  Something
else to consider here is that astrobotany uses the Common Name part of
the certificate for the username.  I like this idea a lot, but
different applications may want different or additional user
information, and using META to convey this information could work well.

There is also the open question of how to handle renewal of this kind of
certificate, which people might have need of for years and years.
Applications which a user authenticates to this way could request the
user to provide an email address (which could be validated in the usual
webbish way of sending a gemini:// URL with a unique token in it).
Then, once the initial sign-up cert is due to expire soon, the app could
email the user a URL with a unique token in it which they should access
using a new cert, whereupon the new cert's fingerprint should be tied to
the account.  But I'm wary of blindly copying ideas from the web.  This
approach doesn't allow a long term account without associating an email
address, and that sucks from a privacy perspective.

A similar workflow could happen inside the app if somebody "signs in"
close to the expiry date of their cert, which would not require an email
address.  But this doesn't work if you happen not to log in for several
months on either side of the expiry date.

Users could sign their new certificate with their old certificate to
prove continuity, but to some extent this defeats the purpose of
expiring certs in the first place, which is to limit the impact of
private key compromise.

Of course, for very low-stakes applications like Astrobotany - and,
realistically, *all* Gemini applications are likely to be very
low-stakes for the foreseeable future - users could also just "sign up"
with very long-lived certificates.  The CA/Browser Forum disallows certs
that live longer than two years currently, and will apparently soon drop
the limit to one year, but there's no reason we need to listen to them,
especially not in the context of client certificates.

There are probably plenty of relevant things I have not mentioned yet.
Feel free to mention them!

For anybody thinking "Holy heck, this sounds complicated, why are we
putting this in Gemini?" and/or "I sure don't want to write all the code
to do this in my client":  Client certificates weren't dreamed up for
Gemini, they are a pre-existing part of TLS.  Even if the Gemini spec
didn't say a word about them, people could build applications using them
for authentication without violating the Gemini spec in anyway.  Because
they're very handy things, their eventual use in conjunction with Gemini
is likely inevitable.  Thus, my thinking is that we might as well
standardise on how to use them with Gemini to provide for easier
interoperability and streamlined user experiences.  Also, they are
totally unnecessary for public content like gemlogs, and a client which
does not implement them at all (which is currently the vast majority of
clients) is likely to remain extremely usable for the majority of people
and the majority of purposes.  In fact, to some extent the existence of
popular clients which *don't* handle client certificates would provide a
useful protective measure against people hiding content behind certs
(which, I realise, also facilitate nasty things like "pay walls")
without a good reason.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat May 23 15:58:36 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 14:58:36 +0000
Subject: [SPEC-CHANGE] Small housekeeping updates
In-Reply-To: <CAObwWNgDxJ33Cp=zkqJ_0aB53czvnPHdgdJUXDm+QNSAsry59w@mail.gmail.com>
References: <20200523102651.GB12486@SDF.ORG>
 <CAObwWNgDxJ33Cp=zkqJ_0aB53czvnPHdgdJUXDm+QNSAsry59w@mail.gmail.com>
Message-ID: <20200523145836.GH12486@SDF.ORG>

On Sat, May 23, 2020 at 04:18:24PM +0200, Katarina Eriksson wrote:
> solderpunk <solderpunk at sdf.org> wrote:
> 
> > If you author your Gemini content on a pre-OS X Apple computer, '70s or
> > '80s vintage 8-bit microcomputer or MIT LISP machine, you should take
> > care to convert your line endings to CR or CRLF before uploading it to
> > your server of choice, or write your own server which does the
> > conversion before you.  Please let the list know more about your amazing
> > life decisions!
> >
> 
> You mean "convert your line endings to LF or CRLF", right?

Darn it, yes, I do.  Why do I keep mixing those two up even after
thinking about this obsessively for several days?

Cheers,
Solderpunk

From int at 80h.dev  Sat May 23 17:32:32 2020
From: int at 80h.dev (int 80h)
Date: Sat, 23 May 2020 12:32:32 -0400
Subject: Gemini and CGI hosting
In-Reply-To: <20200523133532.GF12486@SDF.ORG>
Message-ID: <C2Y94LXN9BOZ.1OJKAAQQ9C4R5@freebsd.lan>

On Sat May 23, 2020 at 9:35 AM EDT, solderpunk wrote:
> I'd love for Molly Brown and hence gemini.circumlunar.space to support
> this, but until Go gets properly setuid support I just can't do it
> securely, unfortunately. Or until the FastGCI / SCGI idea gets polished
> a bit more. I know 80h has done some work on that front and I've been
> meaning to ask for details.

I still haven't got around to FastCGI but SCGI is pretty easy. SCGI is
basically a netstring with null terminated environmental variables sent
to the server(cgi script)

int 80h

From luke.emmet at gmail.com  Sat May 23 17:46:19 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sat, 23 May 2020 17:46:19 +0100
Subject: Gemini and CGI hosting
In-Reply-To: <alpine.NEB.2.21.2005231332370.14453@tilde.pink>
References: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>
 <alpine.NEB.2.21.2005231332370.14453@tilde.pink>
Message-ID: <5EC9535B.2010808@gmail.com>

Thanks (and to others who responded). I would be interested in something 
like this if and when it proves feasible for user based scripting.

At the moment I'm just looking at the old fashioned plain CGI - due to 
its simplicity from the script author's point of view - even though as 
we know it is harder to secure and the performance is not great.

I've made some progress and managed to get Molly Brown installed on a 
local raspberrypi, so at least I have somewhere to experiment for now.

Thanks

  - Luke

On 23-May-2020 14:33, tiwesdaeg at tilde.pink wrote:
> Luke,
>
> I'm looking in to this on tilde.pink. So far, the only way I could get 
> a cgi script located in a user directory to work was to create a 
> symbolic link directly to /var/gemini/cgi-bin/. So far, no one has 
> implemented a server that acts like gophernicus or geomyidae, allowing 
> for scripts to be run from any served directory.
>
> I don't know how this is handled by webservers that support ~user 
> accounts.
>
> -Tiwesdaeg
>
> On Sat, 23 May 2020, Luke Emmet wrote:
>
>> Hi everyone
>>
>> Can anyone suggest or recommend a server or host where I can make a 
>> simple Gemini capsule serving static gmi files, but also CGI scripts?
>>
>> I'm interested to see what kind of simple applications can be written 
>> and delivered over Gemini space.
>>
>> I'd rather not get into setting up my own server at this stage, if I 
>> can avoid it.
>>
>> Feel free to reply or send a personal message.
>>
>> Many thanks
>>
>> Luke

From solderpunk at SDF.ORG  Sat May 23 17:55:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 16:55:44 +0000
Subject: Gemini and CGI hosting
In-Reply-To: <C2Y94LXN9BOZ.1OJKAAQQ9C4R5@freebsd.lan>
References: <20200523133532.GF12486@SDF.ORG>
 <C2Y94LXN9BOZ.1OJKAAQQ9C4R5@freebsd.lan>
Message-ID: <20200523165544.GL12486@SDF.ORG>

On Sat, May 23, 2020 at 12:32:32PM -0400, int 80h wrote:

> I still haven't got around to FastCGI but SCGI is pretty easy. SCGI is
> basically a netstring with null terminated environmental variables sent
> to the server(cgi script)

Just read https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
and, yeah, this looks pretty straightforward.  Are you using Sean's
adaptation of CGI variables to Gemini in conjunction with this?  Maybe
I'll try to get this into Molly Brown if I ever find the time.  I really
want to be able to start experimenting with dynamic content.

Cheers,
Solderpunk

From int at 80h.dev  Sat May 23 18:02:28 2020
From: int at 80h.dev (int 80h)
Date: Sat, 23 May 2020 13:02:28 -0400
Subject: Gemini and CGI hosting
In-Reply-To: <20200523165544.GL12486@SDF.ORG>
Message-ID: <C2Y9RIS56TSV.CL9RP6DRUF9J@freebsd.lan>

On Sat May 23, 2020 at 12:55 PM EDT, solderpunk wrote:
> Just read https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
> and, yeah, this looks pretty straightforward. Are you using Sean's
> adaptation of CGI variables to Gemini in conjunction with this? Maybe
> I'll try to get this into Molly Brown if I ever find the time. I really
> want to be able to start experimenting with dynamic content.

No but I should... right now it's only a small subset of the variables.

int 80h

From colecmac at protonmail.com  Sat May 23 18:15:36 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 23 May 2020 17:15:36 +0000
Subject: Gemini and CGI hosting
In-Reply-To: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>
References: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>
Message-ID: <XLRlErcuufe-UNvkPuAmyi-8h0hWSW6HLNcxegA_bWsROQLraIIiL9k-FF8g-GSXKH5JXnr9yKgm4AxM0ozJ5aUwIYNB4bvz8XreCMuGcrE=@protonmail.com>

Hello Luke,

Somehow, no one has answered your question yet. Hopefully I can do that.
The server that I have the most experience with is Jetforce[1] which
can do all that you're asking, it will serve static files and do CGI too.

1: https://github.com/michael-lazar/jetforce

makeworld

??????? Original Message ???????
On Saturday, May 23, 2020 2:49 AM, Luke Emmet <luke.emmet at gmail.com> wrote:

> Hi everyone
>
> Can anyone suggest or recommend a server or host where I can make a simple Gemini capsule serving static gmi files, but also CGI scripts?
>
> I'm interested to see what kind of simple applications can be written and delivered over Gemini space.
>
> I'd rather not get into setting up my own server at this stage, if I can avoid it.
>
> Feel free to reply or send a personal message.
>
> Many thanks
>
> Luke



From ziggys at autistici.org  Sat May 23 18:28:15 2020
From: ziggys at autistici.org (ziggys at autistici.org)
Date: Sat, 23 May 2020 14:28:15 -0300
Subject: Gemini browser written in Tcl/Tk
Message-ID: <-7ftx5o-iforu834cacw-xixg0o-a3yu48-7ou153osypvx-qq0yos-fl9uet-at68lsnk7qgh-gk8i1k7j3emu-5j5pyumye3og5pel5t-oibjab51cgdq4vmhp5-ndxe8wobfd6t-fz6u1dqspkiv-dc5sfk.1590254730146@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200523/a8ff47c6/attachment.htm>

From int at 80h.dev  Sat May 23 18:26:42 2020
From: int at 80h.dev (int 80h)
Date: Sat, 23 May 2020 13:26:42 -0400
Subject: Gemini and CGI hosting
In-Reply-To: <XLRlErcuufe-UNvkPuAmyi-8h0hWSW6HLNcxegA_bWsROQLraIIiL9k-FF8g-GSXKH5JXnr9yKgm4AxM0ozJ5aUwIYNB4bvz8XreCMuGcrE=@protonmail.com>
Message-ID: <C2YAA2ZWKUBR.32XJLH9J8VUX@freebsd.lan>

On Sat May 23, 2020 at 1:15 PM EDT, colecmac wrote:
> Somehow, no one has answered your question yet. Hopefully I can do that.
> The server that I have the most experience with is Jetforce[1] which
> can do all that you're asking, it will serve static files and do CGI
> too.
>
> 1: https://github.com/michael-lazar/jetforce
>

Oh my apologies!

There's also Molly Brown, GLV-1.12556 and gemserv. Sorry, if I missed
any others.

int 80h

[1] https://tildegit.org/solderpunk/molly-brown
[2] https://github.com/spc476/GLV-1.12556
[3] gemini://80h.dev/projects/gemserv/

From solderpunk at SDF.ORG  Sat May 23 18:39:07 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 17:39:07 +0000
Subject: Gemini and CGI hosting
In-Reply-To: <C2YAA2ZWKUBR.32XJLH9J8VUX@freebsd.lan>
References: <XLRlErcuufe-UNvkPuAmyi-8h0hWSW6HLNcxegA_bWsROQLraIIiL9k-FF8g-GSXKH5JXnr9yKgm4AxM0ozJ5aUwIYNB4bvz8XreCMuGcrE=@protonmail.com>
 <C2YAA2ZWKUBR.32XJLH9J8VUX@freebsd.lan>
Message-ID: <20200523173907.GN12486@SDF.ORG>

On Sat, May 23, 2020 at 01:26:42PM -0400, int 80h wrote:
> On Sat May 23, 2020 at 1:15 PM EDT, colecmac wrote:
> > Somehow, no one has answered your question yet. Hopefully I can do that.
> > The server that I have the most experience with is Jetforce[1] which
> > can do all that you're asking, it will serve static files and do CGI
> > too.
> >
> > 1: https://github.com/michael-lazar/jetforce
> >
> 
> Oh my apologies!
> 
> There's also Molly Brown, GLV-1.12556 and gemserv. Sorry, if I missed
> any others.
> 

I think Luke was asking for servers (i.e. machines) offering hosting for
people who aren't running their own, rather than servers as in software.

Cheers,
Solderpunk


From felix at masterq32.de  Sat May 23 18:46:18 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sat, 23 May 2020 19:46:18 +0200
Subject: [ANN] I started a gemlog!
Message-ID: <0dd30c26-0c22-335b-11fa-a5293e123249@masterq32.de>

Hey list!

I just started a new gemini page with a small gemlog on it. I've seen
some gemlogs already and i'm inspired to write about stuff in a
text/gemini fashion without much focus on style, just content.

Main content will be tech talk about projects i'm doing, stuff i've
discovered on the web and some recipies for those who love to cook :)

gemini://random-projects.net/

Regards
- xq

From solderpunk at SDF.ORG  Sat May 23 18:56:53 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 17:56:53 +0000
Subject: [ANN] I started a gemlog!
In-Reply-To: <0dd30c26-0c22-335b-11fa-a5293e123249@masterq32.de>
References: <0dd30c26-0c22-335b-11fa-a5293e123249@masterq32.de>
Message-ID: <20200523175653.GP12486@SDF.ORG>

On Sat, May 23, 2020 at 07:46:18PM +0200, Felix Quei?ner wrote:
> Hey list!
> 
> I just started a new gemini page with a small gemlog on it. I've seen
> some gemlogs already and i'm inspired to write about stuff in a
> text/gemini fashion without much focus on style, just content.
> 
> Main content will be tech talk about projects i'm doing, stuff i've
> discovered on the web and some recipies for those who love to cook :)
> 
> gemini://random-projects.net/
> 
> Regards
> - xq

Thanks for letting us know!  Let me know if you end up adding a feed for
your blog and I'll put it on CAPCOM.

The Ashet project looks like fun.  I didn't watch the video of your
recent talk because I only understand very basic German, and couldn't
find an answer at the English website: do I understand correctly that
right now this is only an emulated system?  But it sounds like you plan
to realise it in an FPGA in future?

Of course, the most important question: how does it represent line
breaks?!

Cheers,
Solderpunk

From felix at masterq32.de  Sat May 23 19:01:48 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sat, 23 May 2020 20:01:48 +0200
Subject: [ANN] I started a gemlog!
In-Reply-To: <20200523175653.GP12486@SDF.ORG>
References: <0dd30c26-0c22-335b-11fa-a5293e123249@masterq32.de>
 <20200523175653.GP12486@SDF.ORG>
Message-ID: <90058e8c-da8a-122a-ba30-ffdde3c070c8@masterq32.de>

Hey

> Thanks for letting us know!  Let me know if you end up adding a feed for
> your blog and I'll put it on CAPCOM.
You're welcome! Have to look up all that feed stuff, it's a new world
for me to host an actual blog instead of just consuming them... :D

> The Ashet project looks like fun.  I didn't watch the video of your
> recent talk because I only understand very basic German, and couldn't
> find an answer at the English website: do I understand correctly that
> right now this is only an emulated system?  But it sounds like you plan
> to realise it in an FPGA in future?
No! It's an actual working piece of "hardware" lying next to my desk
consisting of several breadboards, a jumper wire hell and development
boards for FPGA, UART, a RAM module and a self-made R2R-VGA-Output.

It's one of the next projects for which i started the blog as i want to
keep myself motivated by writing update posts :)

> Of course, the most important question: how does it represent line
> breaks?!
As it uses raw ANSI terminals as an interface, it uses CRLF or LFCR,
depending on what is more convenient to output at the place in the code
*laughs in assembly hackery*

Regards
- xq

From solderpunk at SDF.ORG  Sat May 23 19:14:20 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 23 May 2020 18:14:20 +0000
Subject: [ANN] I started a gemlog!
In-Reply-To: <90058e8c-da8a-122a-ba30-ffdde3c070c8@masterq32.de>
References: <0dd30c26-0c22-335b-11fa-a5293e123249@masterq32.de>
 <20200523175653.GP12486@SDF.ORG>
 <90058e8c-da8a-122a-ba30-ffdde3c070c8@masterq32.de>
Message-ID: <20200523181420.GR12486@SDF.ORG>

On Sat, May 23, 2020 at 08:01:48PM +0200, Felix Quei?ner wrote:

> No! It's an actual working piece of "hardware" lying next to my desk
> consisting of several breadboards, a jumper wire hell and development
> boards for FPGA, UART, a RAM module and a self-made R2R-VGA-Output.

Ah, cool!  I know all about jumper wire hell. :)  I've seen some of the
cool R2R-VGA projects around the web (like at Lucid Science, if I
remember the sit ename correctly) and have always thought it would be
fun to play with.

Okay, next more important question - how is the FPGA implementation of
TLS 1.3 coming along so it can support Gemini? :p

> It's one of the next projects for which i started the blog as i want to
> keep myself motivated by writing update posts :)

I look forward to these!

Cheers,
Solderpunk

From colecmac at protonmail.com  Sat May 23 19:17:02 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 23 May 2020 18:17:02 +0000
Subject: Gemini and CGI hosting
In-Reply-To: <20200523173907.GN12486@SDF.ORG>
References: <XLRlErcuufe-UNvkPuAmyi-8h0hWSW6HLNcxegA_bWsROQLraIIiL9k-FF8g-GSXKH5JXnr9yKgm4AxM0ozJ5aUwIYNB4bvz8XreCMuGcrE=@protonmail.com>
 <C2YAA2ZWKUBR.32XJLH9J8VUX@freebsd.lan>
 <20200523173907.GN12486@SDF.ORG>
Message-ID: <CG3wAIxuNXPTBwD1wCs_6Ff5Omd9U35ETkwj8jnLXj-qcPjzGRVryXCqBbwRw_H_yZlXXR3VIggFfO1R6TO3NNYdAGOs9vAgLL5J1gw2mvs=@protonmail.com>

> I think Luke was asking for servers (i.e. machines) offering hosting for
> people who aren't running their own, rather than servers as in software.

Oh you're completely right, my bad. Sorry Luke!

makeworld



From sean at conman.org  Sat May 23 22:09:01 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 23 May 2020 17:09:01 -0400
Subject: Gemini and CGI hosting
In-Reply-To: <alpine.NEB.2.21.2005231332370.14453@tilde.pink>
References: <DDA4A0C0-ECFA-4E76-A156-6CB3C31A32C9@gmail.com>
 <alpine.NEB.2.21.2005231332370.14453@tilde.pink>
Message-ID: <20200523210901.GA23998@brevard.conman.org>

It was thus said that the Great tiwesdaeg at tilde.pink once stated:
> Luke,
> 
> I'm looking in to this on tilde.pink. So far, the only way I could get a 
> cgi script located in a user directory to work was to create a symbolic 
> link directly to /var/gemini/cgi-bin/. So far, no one has implemented a 
> server that acts like gophernicus or geomyidae, allowing for scripts to be 
> run from any served directory.

  Ahem.

  GLV-1.12556 will run a CGI script from any directory.

  This is accomplished by treating any file with execute permissions as a
CGI script.  If CGI is NOT enabled, then any reference to a script with
executable permissions returns a "Temporary Error" (40).

> I don't know how this is handled by webservers that support ~user 
> accounts.

  I handle it the same as above---any file that has execute permissions is
treated as a CGI script.

  -spc


From defdefred at protonmail.com  Sat May 23 22:10:07 2020
From: defdefred at protonmail.com (defdefred)
Date: Sat, 23 May 2020 21:10:07 +0000
Subject: Gemini browser written in Tcl/Tk
In-Reply-To: <-7ftx5o-iforu834cacw-xixg0o-a3yu48-7ou153osypvx-qq0yos-fl9uet-at68lsnk7qgh-gk8i1k7j3emu-5j5pyumye3og5pel5t-oibjab51cgdq4vmhp5-ndxe8wobfd6t-fz6u1dqspkiv-dc5sfk.1590254730146@email.android.com>
References: <-7ftx5o-iforu834cacw-xixg0o-a3yu48-7ou153osypvx-qq0yos-fl9uet-at68lsnk7qgh-gk8i1k7j3emu-5j5pyumye3og5pel5t-oibjab51cgdq4vmhp5-ndxe8wobfd6t-fz6u1dqspkiv-dc5sfk.1590254730146@email.android.com>
Message-ID: <wM6WPU1z_ppZ52NTjKBFkuQ9bZRMjFfCZrQtjLJkHcx2K8oLfomqOd2r0OPRvSazaV8_v9gcbve_cp5QK9x3mEHTWZcUTn5eDiAxFMvIFdA=@protonmail.com>

Only need to install tcl tk tcl-lts ( <8MB) and
curl https://gitgud.io/sathariel/zain/-/raw/master/zain?inline=false > zain
chmod +x zain
Excellent!
??????? Original Message ???????
On Saturday, May 23, 2020 7:28 PM, ziggys at autistici.org <ziggys at autistici.org> wrote:

> Zain
>
> https://gitgud.io/sathariel/zain
>
> Zain is a gemini browser written in Tcl/Tk. For more information about the gemini protocol visit https://gemini.circumlunar.space/
>
> #installationInstallation
>
> You need to install Tcl/Tk and tcl-tls to run this script. Then give it execute permission and run it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200523/1702caaf/attachment.htm>

From sebastian1231alejandro at gmail.com  Sat May 23 22:18:39 2020
From: sebastian1231alejandro at gmail.com (Sebastian Alejandro)
Date: Sat, 23 May 2020 17:18:39 -0400
Subject: Gemini browser written in Tcl/Tk
In-Reply-To: <-7ftx5o-iforu834cacw-xixg0o-a3yu48-7ou153osypvx-qq0yos-fl9uet-at68lsnk7qgh-gk8i1k7j3emu-5j5pyumye3og5pel5t-oibjab51cgdq4vmhp5-ndxe8wobfd6t-fz6u1dqspkiv-dc5sfk.1590254730146@email.android.com>
Message-ID: <C2YF7OEXA8N5.DBXLBOZKL5Z0@helios>

I just gave it a try, it's pretty good!

On Sat May 23, 2020 at 10:28 AM EDT, ziggys at autistici.org wrote:
> <div dir="auto"><h1 dir="auto">Zain</h1><div><span
> style="font-family:sans-serif">https://gitgud.io/sathariel/zain</span></div><div><span
> style="font-family:sans-serif"><br /></span></div><div><br /></div>
> <p dir="auto">Zain is a gemini browser written in Tcl/Tk. For more
> information about the gemini protocol visit <a
> href="https://gemini.circumlunar.space/">https://gemini.circumlunar.space/</a></p><p
> dir="auto"><br /></p>
> <h2 dir="auto">
> <a href="#installation"></a>Installation</h2>
> <p dir="auto">You need to install Tcl/Tk and tcl-tls to run this script.
> Then give it execute permission and run it.</p><div><br /></div></div>


From tkarpiniec at icloud.com  Sun May 24 00:04:29 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Sun, 24 May 2020 09:04:29 +1000
Subject: Client certificate musings
In-Reply-To: <20200523145638.GG12486@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
Message-ID: <20200523230429.GA38201@allanon.local>

Hi!

On Sat, May 23, 2020 at 02:56:38PM +0000, solderpunk wrote:
> Gemini specs a lot of use for client certificates - partially because
> they're a nice tool for the job, partially because the design goal of
> maximising power-to-weight ratio means once you accept the weight of
> using TLS you'd better implement everything you can using TLS rather
> than adding yet another pile of concepts.

This was the thing that stood out most on my first read-through of the
spec! I particularly like the insistence "Transient certificates MUST
NOT be generated automatically". I wasn't here for the earlier
discussion but I assume this is to fend off servers making sessions
purely for tracking purposes by default.

>   Right now, AV-98 fills the "Subject" of transient certs with
>   random unique values from Python's `uuid` module, because I seemed
>   to encounter errors sending totally empty certificates to
>   conman.org.

I've seen similar problems before with custom usage of X.509. It would
be nice to use something smaller than UUID if possible just to keep
cert size down - provided there is library support as you noted.

> There is a third scenario, which the spec does not explicitly discuss at
> all, but which is actually the most widely used scenario in Geminispace
> so far, which is the main reason that I want to kick off a discussion
> about this and change the spec if required.  It's the idea of persistent
> identity (basically, a "user account") at a server which is not under
> the client's control.
> ...
> We could change 62 to specify that the META should be a plain-language
> message to users, which could disambiguate the scenario.  Something
> else to consider here is that astrobotany uses the Common Name part of
> the certificate for the username.  I like this idea a lot, but
> different applications may want different or additional user
> information, and using META to convey this information could work well.

I'm not a big fan of using certificate fields for anything meaningful
- it's a side channel (surrounded by lots of other fields that people
might be tempted to use) - and it slightly increases the complexity of
integration between the TLS library and the client/server code.

When a server wants the client to use a non-disposable certificate
there is an ambiguity. Is it just because they want the user to
preserve their authentication for more than 24 hours for convenience?
Or is it because the user will permanently lose access to their
account if they ever lose that key?

Much like a bitcoin wallet, the latter is technically a very tidy and
secure solution but it absolutely sets up users to fail. People who
are auto-generating this authentication in regular clients will lose
their keys and be sad about it. By comparison, those who are setting
up whitelisted keys out-of-band are likely more savvy and know what
they're getting into.

With this in mind, my current opinion is that there should be no way
for a server to request a non-disposable certificate. Where
authentication is required, it should be done in-band via a password
or username/password 10 responses as you noted, which is then
associated on the server with the transient certificate. It then
becomes the responsibility of clients to ask the user "how long do you
want to stay authenticated to this website?" If it times out, they can
simply repeat their authentication.

One argument against is that it encourages clients to choose very lax
deletion policies to reduce friction. This may not be as big a concern
as it is on the web, since users will presumably only have a session
with a small fraction of the gemini sites they visit, so they are not
picking up transient tracking sessions willy nilly that need to be
flushed out.

One final thought: do we need a way to encourage clients to have
multiple certificates for the same server, depending on path? If I
authenticate to a CGI application on a multi-user server I don't
necessarily want my identity to be followed by everybody else's
applications on that server.

Cheers,

Tom

From martin at no.ucant.org  Sun May 24 01:06:20 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sun, 24 May 2020 01:06:20 +0100 (BST)
Subject: spec clarification request: scheme omission
Message-ID: <alpine.DEB.2.20.2005240103040.18317@pling.qwghlm.org>


Hello,

The spec says, at 1.2, that:

"<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
If the scheme of the URL is not specified, a scheme of gemini:// is
implied."

Is this supposed to allow one or both of

   //hostname.domain:port/filename
   hostname.domain:port/filename

as synonyms for

   gemini://hostname.domain:port/filename

?

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From martin at no.ucant.org  Sun May 24 01:46:55 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sun, 24 May 2020 01:46:55 +0100 (BST)
Subject: [SPEC-CHANGE] Small housekeeping updates
In-Reply-To: <20200523145836.GH12486@SDF.ORG>
References: <20200523102651.GB12486@SDF.ORG>
 <CAObwWNgDxJ33Cp=zkqJ_0aB53czvnPHdgdJUXDm+QNSAsry59w@mail.gmail.com>
 <20200523145836.GH12486@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2005240146330.18317@pling.qwghlm.org>

On Sat, 23 May 2020, solderpunk wrote:

>> You mean "convert your line endings to LF or CRLF", right?
>
> Darn it, yes, I do.  Why do I keep mixing those two up even after
> thinking about this obsessively for several days?

This must be how "CRFL" made its way into the spec ;)

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From sean at conman.org  Sun May 24 02:57:14 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 23 May 2020 21:57:14 -0400
Subject: Client certificate musings
In-Reply-To: <20200523230429.GA38201@allanon.local>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
Message-ID: <20200524015714.GC23998@brevard.conman.org>

It was thus said that the Great Thomas Karpiniec once stated:
> Hi!
> 
> On Sat, May 23, 2020 at 02:56:38PM +0000, solderpunk wrote:
> > Gemini specs a lot of use for client certificates - partially because
> > they're a nice tool for the job, partially because the design goal of
> > maximising power-to-weight ratio means once you accept the weight of
> > using TLS you'd better implement everything you can using TLS rather
> > than adding yet another pile of concepts.
> 
> This was the thing that stood out most on my first read-through of the
> spec! I particularly like the insistence "Transient certificates MUST
> NOT be generated automatically". I wasn't here for the earlier
> discussion but I assume this is to fend off servers making sessions
> purely for tracking purposes by default.

  There wasn't much of a discussion.

  Okay, a bit of history of this mess, which can be laid at the feet of me
and solderpunk.

  In early June of last year, solderpunk starting the design of Gemini and
sometime between the 16th and 21st, he had the initial protocol designed. 
On the 21st (19:18:37 -0400 to be exact) I started GLV-1.12556.  I already
had a framework for servers written, and a TLS wrapper for Lua, and I wanted
to play around with TLS.

  Now, the library I picked for this was LibreSSL, a hard fork of OpenSSL
because of issues.  The reason I picked LibreSSL was mainly for its
inclusion of a higher-level library libtls, which makes it easy for an
application writer to use TLS correctly in an application.  And if your
client accepts the whole CA mechanism (for both servers and clients) then
yes, it is *very* easy to use [1].  This is further reflected by some of the
functions they defined:

	tls_config_insecure_noverifycert()
	tls_config_insecure_noverifyname()
	tls_config_insecure_noverifytime()

  They definitely want to make sure you know that not verifying a
certificate is bad.  They also make it easy to use client certificates:

	tls_config_verify_client()
	tls_config_verify_client_optional()

  So with all this, by midnight on the 22nd, I had a minimal Gemini server
written, with client certificate support by the 24th.  Since client
certificates weren't a part of the original specification, I thought I would
just go ahead and implement it to show it could be done [2].  To that end, I
set up two end points that were (and still are) protected:

	gemini://gemini.conman.org/private/
	gemini://gemini.conman.org/conman-labs-private/

  I set client certifications optional (else every request would require
them and this would be checked by libtls), and for "/private/" all I require
is that a certificate is sent (I don't even bother looking at it).  For
"/conman-labs-private/" I require a certificate I signed to be used (much
like Astrobotany).  My intent was to protect certain areas of a Gemini
server with an access control mechanism, and using certificates was (in my
mind) a no brainer.

  It was on July 9th that solderpunk decided he liked the idea of a client
certificate for authentication and on August 15th, settled on the idea for
good, and seems to have come to see temporary client certificates as for
some form of "cookie" the client controls by the 19th, because of the
"/private/" area on my server not requiring any particular client
certificate (just *a* client certificate).

  And from then, there wasn't much work on it until just recently.  I was
surprised and amused that Astrobotany exists, using client certificates as I
envisioned them being used.

> >   Right now, AV-98 fills the "Subject" of transient certs with
> >   random unique values from Python's `uuid` module, because I seemed
> >   to encounter errors sending totally empty certificates to
> >   conman.org.
> 
> I've seen similar problems before with custom usage of X.509. It would
> be nice to use something smaller than UUID if possible just to keep
> cert size down - provided there is library support as you noted.

  I'm not aware of what fields are mandatory either, but certainly using the
string "anon" or "unknown" or "noydb" [3].  Or you know, Noah Body or Abby
Normal.  

> I'm not a big fan of using certificate fields for anything meaningful
> - it's a side channel (surrounded by lots of other fields that people
> might be tempted to use) - and it slightly increases the complexity of
> integration between the TLS library and the client/server code.
> 
> When a server wants the client to use a non-disposable certificate
> there is an ambiguity. Is it just because they want the user to
> preserve their authentication for more than 24 hours for convenience?

  One scenario I envisioned was a Gemini server serving up sensitive
material to known, authenticated users.  How that authentication happens is
beyond the scope of the Gemini protocol, but perhaps a companion way (or a
"best practices" way) could be discussed.

> Or is it because the user will permanently lose access to their
> account if they ever lose that key?

  Of if they get logged out and forget the password?  That can happen now,
so I don't think it's of much concern.

> With this in mind, my current opinion is that there should be no way
> for a server to request a non-disposable certificate. 

  I disagree.  I might want to serve up documents to a select few, and I can
control that by given them a client certificate to use.

  -spc

[1]	https://github.com/spc476/libtls-examples

[2]	I've also played around with client certificates for the web.  I
	wish they were used more often as they obliviate the need for
	"logging" in (has certificate?  User is logged in) and "logging out"
	(client just stops browsing).  It gets difficult when you use
	multiple devices, and the UI around generating and using them is ...
	let's say it's "technical" and leave it at that.

[3]	None of your darned business.

From sean at conman.org  Sun May 24 02:58:50 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 23 May 2020 21:58:50 -0400
Subject: spec clarification request: scheme omission
In-Reply-To: <alpine.DEB.2.20.2005240103040.18317@pling.qwghlm.org>
References: <alpine.DEB.2.20.2005240103040.18317@pling.qwghlm.org>
Message-ID: <20200524015850.GD23998@brevard.conman.org>

It was thus said that the Great Martin Keegan once stated:
> 
> Hello,
> 
> The spec says, at 1.2, that:
> 
> "<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
> If the scheme of the URL is not specified, a scheme of gemini:// is
> implied."
> 
> Is this supposed to allow one or both of
> 
>   //hostname.domain:port/filename
>   hostname.domain:port/filename
> 
> as synonyms for
> 
>   gemini://hostname.domain:port/filename

  	//hostname:port/filename

  Per the URL spec (RFC-3986), the '//' is part of the host portion of the
URL.

  -spc


From int at 80h.dev  Sun May 24 03:10:25 2020
From: int at 80h.dev (int 80h)
Date: Sat, 23 May 2020 22:10:25 -0400
Subject: spec clarification request: scheme omission
In-Reply-To: <20200524015850.GD23998@brevard.conman.org>
Message-ID: <C2YLF2ITRJXA.3C09C7XGY1FAR@freebsd.lan>

On Sat May 23, 2020 at 5:58 PM EDT, Sean Conner wrote:
> //hostname:port/filename
>
> Per the URL spec (RFC-3986), the '//' is part of the host portion of the
> URL.

That's also what gemini-diagnostics[1] uses in its URLSchemeMissing test.

[1] https://github.com/michael-lazar/gemini-diagnostics

int 80h

From tkarpiniec at icloud.com  Sun May 24 03:30:29 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Sun, 24 May 2020 12:30:29 +1000
Subject: Client certificate musings
In-Reply-To: <20200524015714.GC23998@brevard.conman.org>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
 <20200524015714.GC23998@brevard.conman.org>
Message-ID: <20200524023029.GA39921@allanon.local>

On Sat, May 23, 2020 at 09:57:14PM -0400, Sean Conner wrote:
> > Or is it because the user will permanently lose access to their
> > account if they ever lose that key?
> 
>   Of if they get logged out and forget the password?  That can happen now,
> so I don't think it's of much concern.

I don't think these are really the same. Even ignoring the many people
who remember their passwords (against all good advice) there are well
established password managers and it's likely that random gemini
client X will require additional backup work to avoid losing its
keys. Strong passwords can be easily written down somewhere safe and
typed in, keys less so.

It also means the only way to share an account between multiple
devices is to copy the key material across, and coordinate renewals so
that it is only done once.

> > With this in mind, my current opinion is that there should be no way
> > for a server to request a non-disposable certificate. 
> 
>   I disagree.  I might want to serve up documents to a select few, and I can
> control that by given them a client certificate to use.

I think I made this statement broader than intended - it makes
complete sense to support that use case the way it's working now. I
didn't mean to say we should take that away.

What I meant was in a regular browsing session, where a client and
server meet each other for the first time, a server would not be able
to rely on the client having a permanent certificate store. They may
request (and get) a transient client certificate. They may encourage
the user to hold onto it. But a server application must assume that
the same person will need to reauthenticate with a new certificate at
some point in the future. This would solve both the user-friendliness
issue, and also the problem of client certificate renewal.

Looking at it another way, suppose it was possible for a long-term
client key to be generated, negotiated and stored, in-band via the
gemini protocol. My hope would be that most server applications would
eschew this in favour of user/pass authentication over transient
keys. However if setting up a permanent client key became common
practice (possibly because it's easier) I am worried that we would end
up in a similar situation to cryptocurrencies where only "hardcore"
users manage their own key material and others rely on some sort of
managed service to keep things safe but available to them.

Cheers,

Tom

From tkarpiniec at icloud.com  Sun May 24 05:06:54 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Sun, 24 May 2020 14:06:54 +1000
Subject: Client certificate musings
In-Reply-To: <20200524015714.GC23998@brevard.conman.org>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
 <20200524015714.GC23998@brevard.conman.org>
Message-ID: <20200524040654.GB39921@allanon.local>

On Sat, May 23, 2020 at 09:57:14PM -0400, Sean Conner wrote:
> > Or is it because the user will permanently lose access to their
> > account if they ever lose that key?
> 
>   Of if they get logged out and forget the password?  That can happen now,
> so I don't think it's of much concern.

Apologies for the double-reply; another thought occurred to me.

Suppose that TLS just expects a parseable cert from the client, and
the server application is only interested in the key type and
fingerprint. Maybe expiry is not a significant concern? (After all, we
don't normally expire passwords on the web.)

A client could implement this using random keys and a permanent
keystore if it wanted. It could simply regenerate its own certificate
based on the same key when it wants to. That sidesteps the validity
problem.

Alternatively, a client could use a key derivation function based on a
combination of a user-selected (hopefully high quality) password and
the domain of the server. You would then be able to reestablish your
identity at any time knowing just the password. If the key derivation
method was enshrined as a best practice, you could then take your
passwords with you when you try out different clients that implemented
it.

This would free applications from the main burden of my original
proposal, which is having to add some sort of login/response system on
top of the certificate. That is admittedly a hassle.

I forgot to mention, thank you for the history of how the current
certificate handling came to be! Very interesting.

Cheers,

Tom





From sean at conman.org  Sun May 24 05:58:48 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 24 May 2020 00:58:48 -0400
Subject: Gemini and CGI hosting
In-Reply-To: <20200523165544.GL12486@SDF.ORG>
References: <20200523133532.GF12486@SDF.ORG>
 <C2Y94LXN9BOZ.1OJKAAQQ9C4R5@freebsd.lan> <20200523165544.GL12486@SDF.ORG>
Message-ID: <20200524045847.GG23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Sat, May 23, 2020 at 12:32:32PM -0400, int 80h wrote:
> 
> > I still haven't got around to FastCGI but SCGI is pretty easy. SCGI is
> > basically a netstring with null terminated environmental variables sent
> > to the server(cgi script)
> 
> Just read https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
> and, yeah, this looks pretty straightforward.  Are you using Sean's
> adaptation of CGI variables to Gemini in conjunction with this?  

  I don't know about 80h, but I know I am.  I'm following the spec (what
there is of it) at

	https://web.archive.org/web/20020403050958/http://python.ca/nas/scgi/protocol.txt

(taken from the Wikipedia article about SCGI).  From what I can determine
(checking Wikipedia, the above article and the Apache documentation) it
appears that the Gemini server (or web server in the case of Apache) is
expecting the SCGI program to be running already, and all that happens is
the Gemini (Apache) server connects to it, sends the request and awaits a
response.

  The *only* example lists the following meta-variables (to use RFC-3875
terminology):

	CONTENT_LENGTH	(mandatory for SCGI)
	SCGI		(mandatory for SCGI)
	REQUEST_METHOD	(mandatory for CGI)
	REQUEST_URI	(not part of RFC-3875)

  I'm keeping *most* of the RFC-3875 meta-variables except for those that
don't really make sense, like GATEWAY_INTERFACE (since it's not),
SCRIPT_NAME (since it's not a script), PATH_INFO and PATH_TRANSLATED (again,
becuase it's not a script).  I am keeping REQUEST_METHOD, and for
REQUEST_URI I have GEMINI_URL and GEMINI_URL_PATH (these are now available
in my CGI interface as well).  I haven't added REQUEST_URI because it's
underspecced in my opinion---the example only shows the path portion, and I
have a workaround in place anyway.

  I was going to make SCGI support a handler (like all of my dynamic content
generators in GLV-1.12556) but that requires support in the config file and
thus leaves users out [1].  I then had an inspired thought (or evil, take
your pick) to use symbolic links in the filesystem pointing to the server

lrwxrwxrwx  1 spc spc 16 May 24 00:03 foo -> scgi:////tmp/log
lrwxrwxrwx  1 spc spc 22 May 23 23:57 here -> scgi://localhost:33333
lrwxrwxrwx  1 spc spc 22 May 23 23:58 there -> scgi://[fc00::1]:3333/

  The first points to a Unix domain socket, the other two to TCP sockets. 
This will give users a way to use SCGI without having access to the config
files for the Gemini server.  I'm not saying everybody has to use this
symbolic hack for SCGI---it's just that I'm using this hack for SCGI support
in GLV-1.12556.  

  I'll report more on this when I have it finished.

  -spc

[1]	The CGI support in GLV-1.12556 is not a handler, but is a module
	used by the filesystem handler when it sees a file that is
	executable.  The userdirectory handler uses the filesystem handler,
	so the use of CGI is transfered to userdirectories as well.

From gmym at coopdot.com  Sun May 24 11:33:17 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sun, 24 May 2020 12:33:17 +0200
Subject: Client certificate musings
In-Reply-To: <20200523230429.GA38201@allanon.local>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
Message-ID: <CAObwWNh_dyXFSEJxE6ec5ug4VTveg0ejUapi8WSGKnP=rYq-_Q@mail.gmail.com>

Thomas Karpiniec <tkarpiniec at icloud.com> wrote:

> Where authentication is required, it should be done in-band via a password
> or username/password 10 responses as you noted, which is then
> associated on the server with the transient certificate.


Hello

It would be nice if we had a separate status code for password input, say
11. Simple clients could treat this as a 10, intermediate clients could
hide user input behind asterisks and advanced clients could ask to make a
call to the password manager (set up in advance) or whatever other
convenience system there might exist.

This has been mentioned before but I didn't want to dig through the archive
again. Sorry for the sidetrack.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200524/b2de3466/attachment.htm>

From solderpunk at SDF.ORG  Sun May 24 15:27:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 14:27:26 +0000
Subject: Client certificate musings
In-Reply-To: <20200523230429.GA38201@allanon.local>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
Message-ID: <20200524142726.GB4190@SDF.ORG>

On Sun, May 24, 2020 at 09:04:29AM +1000, Thomas Karpiniec wrote:
 
> This was the thing that stood out most on my first read-through of the
> spec! I particularly like the insistence "Transient certificates MUST
> NOT be generated automatically". I wasn't here for the earlier
> discussion but I assume this is to fend off servers making sessions
> purely for tracking purposes by default.

Right, transient sessions generated automatically and invisibly to the
user are not really any better than cookies.  Of course, even though tht
spec forbids is, there is a risk that clients start actually doing that.
The fact that generating a certificate takes a small but noticable
amount of time means this would not make for a good user experience,
which I hope is incentive against it.
 
> I've seen similar problems before with custom usage of X.509. It would
> be nice to use something smaller than UUID if possible just to keep
> cert size down - provided there is library support as you noted.

The cert size concern is a good one (the lack of connection reuse in
Gemini means that TLS overhead is more of an issue than it otherwise
would be.  This is one nice thing about self-signed certs, they will
typically be shorter as they won't have a long chain of intermediate
signing certs).  I think Sean's solution of having the spec require a
single fixed nonce value is a good one.  Having every cert identical
with regard to subject/issuer prevents linking certs together just as
well as having every one be unique.
 
> I'm not a big fan of using certificate fields for anything meaningful
> - it's a side channel (surrounded by lots of other fields that people
> might be tempted to use) - and it slightly increases the complexity of
> integration between the TLS library and the client/server code.

I guess I am seduced to some extent by the ideas in FOAF+SSL.  If the
cert can refer to some other resource (a FOAF profile in that case, but
we wouldn't need to follow that) and that resource contains the cert
fingerprint to validate the connection, then client certificates can -
if and only if the user wants them to! - be vehicles for rich
identities under full user control.
 
> When a server wants the client to use a non-disposable certificate
> there is an ambiguity. Is it just because they want the user to
> preserve their authentication for more than 24 hours for convenience?
> Or is it because the user will permanently lose access to their
> account if they ever lose that key?

The former, i.e. the idea is that, unlike a transient certificate (which
has the semantics of "I don't really care who you are and am not at all
interested in recognising you again next week, I just need to tie
together a handful of separate requests *right now*" - although that
idea can be destroyed if that handful of separate requests involves the
client providing a username and password), a non-disposable certificate
is supposed to be a persistent identity - what people think of as a
"user account" on the web.

In the simplest possible implementation of this, the server just uses
the cert hash as user ID and then, yes, we're in high-risk territory
where if the user doesn't backup their keys and certs then a hard drive
failure or theft of a laptop or similar scenarios result in lock out.
It doesn't *need* to work that way, though.  An application which users
authenticate to this way could give users the option to associate an
email address which could be used for the equivalent of "password
recovery" - email the user a URL with a random unique token in it and
tell them the first new certificate which visits that URL sometime in
the next one hour will become linked to their account.

> With this in mind, my current opinion is that there should be no way
> for a server to request a non-disposable certificate. Where
> authentication is required, it should be done in-band via a password
> or username/password 10 responses as you noted, which is then
> associated on the server with the transient certificate. It then
> becomes the responsibility of clients to ask the user "how long do you
> want to stay authenticated to this website?" If it times out, they can
> simply repeat their authentication.

Hmm, interesting.  I'll ponder this, thanks for your thoughts.  My first
reaction is that that I'm reluctant to remove a dedicated mechanism for
creating something which is unavoidably and non-negotiably very short
lived.  Maybe you didn't mean for that to happen, though?

> One final thought: do we need a way to encourage clients to have
> multiple certificates for the same server, depending on path? If I
> authenticate to a CGI application on a multi-user server I don't
> necessarily want my identity to be followed by everybody else's
> applications on that server.

Ah!  I absolutely positively meant to bring this up in my original post
to this thread.  This is a very valid point.  Right now, the spec (and
my proof-of-concept implementations in AV-98) associates client certs
with a domain.  The presence of many multi-user servers in Geminispace
(and for what it's worth, I like those, a lot, assuming the users
constitute a community in some sense beyond sharing a server) means this
is not necessarily going to work well.  We could use the <META> content
of status codes which request a cert to specify a path or range of paths
for which the cert should be used.

I'm, unsurprisingly, extremely out of touch with modern web development:
are cookies still strictly tied to domains or have they evolved some
kind of path-specificity?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 24 15:31:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 14:31:26 +0000
Subject: [SPEC-CHANGE] Small housekeeping updates
In-Reply-To: <alpine.DEB.2.20.2005240146330.18317@pling.qwghlm.org>
References: <20200523102651.GB12486@SDF.ORG>
 <CAObwWNgDxJ33Cp=zkqJ_0aB53czvnPHdgdJUXDm+QNSAsry59w@mail.gmail.com>
 <20200523145836.GH12486@SDF.ORG>
 <alpine.DEB.2.20.2005240146330.18317@pling.qwghlm.org>
Message-ID: <20200524143126.GD4190@SDF.ORG>

On Sun, May 24, 2020 at 01:46:55AM +0100, Martin Keegan wrote:
> On Sat, 23 May 2020, solderpunk wrote:
> 
> > > You mean "convert your line endings to LF or CRLF", right?
> > 
> > Darn it, yes, I do.  Why do I keep mixing those two up even after
> > thinking about this obsessively for several days?
> 
> This must be how "CRFL" made its way into the spec ;)

Oh, flippin' 'eck!  Fixed just now, thanks for pointing this out!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 24 15:44:02 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 14:44:02 +0000
Subject: Gemini and CGI hosting
In-Reply-To: <20200524045847.GG23998@brevard.conman.org>
References: <20200523133532.GF12486@SDF.ORG>
 <C2Y94LXN9BOZ.1OJKAAQQ9C4R5@freebsd.lan>
 <20200523165544.GL12486@SDF.ORG>
 <20200524045847.GG23998@brevard.conman.org>
Message-ID: <20200524144402.GE4190@SDF.ORG>

On Sun, May 24, 2020 at 12:58:48AM -0400, Sean Conner wrote:
> 
> From what I can determine
> (checking Wikipedia, the above article and the Apache documentation) it
> appears that the Gemini server (or web server in the case of Apache) is
> expecting the SCGI program to be running already, and all that happens is
> the Gemini (Apache) server connects to it, sends the request and awaits a
> response.

This is precisely what excites me about SCGI.  Until Go gets non-broken
from the perspective of traditional unix user-based permissions, there's
no way for Molly Brown to securely kick off a CGI process via fork().
If something else (a helper program, or the admin) starts the process,
they can presumably start it as a `nobody` user and chroot it somewhere
safe.  It's clunky, but I can live with it for now.
 
>   I'm keeping *most* of the RFC-3875 meta-variables except for those that
> don't really make sense, like GATEWAY_INTERFACE (since it's not),
> SCRIPT_NAME (since it's not a script), PATH_INFO and PATH_TRANSLATED (again,
> becuase it's not a script).  I am keeping REQUEST_METHOD, and for
> REQUEST_URI I have GEMINI_URL and GEMINI_URL_PATH (these are now available
> in my CGI interface as well).  I haven't added REQUEST_URI because it's
> underspecced in my opinion---the example only shows the path portion, and I
> have a workaround in place anyway.

We really need to get the adaptation of RFC-3875 documented somewhere.
Not in the Gemini-spec, but in some kind of side-spec thing, with it's
own name or ID and file in gemini.circumlunar.space/docs/, or a sub
directory thereof.  Not just CGI, but our proposed adaptation of robots.txt,
and other stuff like that.  I dunno what these should be called, I'm not
sure how they should be managed.  I might end up delegating most
responsibility for these "side specs" to interested people who I trust
to do a good job.  I have a bunch of ill-formed ideas for side specs
that it would be good to bring to life.
 
>   I was going to make SCGI support a handler (like all of my dynamic content
> generators in GLV-1.12556) but that requires support in the config file and
> thus leaves users out [1].  I then had an inspired thought (or evil, take
> your pick) to use symbolic links in the filesystem pointing to the server
> 
> lrwxrwxrwx  1 spc spc 16 May 24 00:03 foo -> scgi:////tmp/log
> lrwxrwxrwx  1 spc spc 22 May 23 23:57 here -> scgi://localhost:33333
> lrwxrwxrwx  1 spc spc 22 May 23 23:58 there -> scgi://[fc00::1]:3333/
> 
>   The first points to a Unix domain socket, the other two to TCP sockets. 
> This will give users a way to use SCGI without having access to the config
> files for the Gemini server.  I'm not saying everybody has to use this
> symbolic hack for SCGI---it's just that I'm using this hack for SCGI support
> in GLV-1.12556.  

Nice hack!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 24 16:49:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 15:49:19 +0000
Subject: Client certificate musings
In-Reply-To: <CAObwWNh_dyXFSEJxE6ec5ug4VTveg0ejUapi8WSGKnP=rYq-_Q@mail.gmail.com>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
 <CAObwWNh_dyXFSEJxE6ec5ug4VTveg0ejUapi8WSGKnP=rYq-_Q@mail.gmail.com>
Message-ID: <20200524154919.GF4190@SDF.ORG>

On Sun, May 24, 2020 at 12:33:17PM +0200, Katarina Eriksson wrote:
 
> It would be nice if we had a separate status code for password input, say
> 11. Simple clients could treat this as a 10, intermediate clients could
> hide user input behind asterisks and advanced clients could ask to make a
> call to the password manager (set up in advance) or whatever other
> convenience system there might exist.
> 
> This has been mentioned before but I didn't want to dig through the archive
> again. Sorry for the sidetrack.

Yes, I proposed precisely this along time ago.  It never gained much
traction, but then it's only very useful on top of a client certificate
and *they* are only just now starting to see use, so maybe it's not too
surprising.

I think I will add this to the spec.  It's very little effort for
clients to handle, and it degrades well enough in a client that
treats 11 as 10.  People will probably do the usename/password thing
anyway even without it, so we may as well make it possible to protect
against shoulder surfing.

Cheers,
Solderpunk

From b__m__e at mailfence.com  Sun May 24 17:33:56 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 24 May 2020 18:33:56 +0200 (CEST)
Subject: Query Strings
Message-ID: <1141063286.117280.1590338036891@ichabod.co-bxl>

Greetings,
I got a bug report recently for Bombadillo about how I have been handling query strings.
I had accidentally left a big in where I was chaining queries:

some.site/thing.gmi?hello?world

They brought up, and it seemed clear to me, that the query should be replaced and not
added on to. So I have done that update (and it will be a part of a big release soon, for
which I will notify the list when it happens).

The other thing they brought up was escaping before sending to the server. Bombadillo
does not escape querystrings currently (for gopher or for gemini).

A look at the spec provides no further explanation re: what is expected: escaped or
unescaped? The spec does point to an RFC that no doubt encourages the escaping
of querystrings (I have not read through the RFC recently)... 

However, in practice, servers offering search (GUS and Houston) do not seem to
unescape a query that is sent to them. I have not tested places other than those two
but neither seems to do so. If I send:

some.site/thing.gmi?This%2C+is+a+string

GUS reports the search string as: "This%2C+is+a+string"
But it should, if escaping and unescaping is expected, report it as: "This, is a string"

I think it would be good to clearly state what is expected of clients and servers
regarding the escaping of querystring values for gemini.

--?
Sent with https://mailfence.com
Secure and private email

From solderpunk at SDF.ORG  Sun May 24 17:42:42 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 16:42:42 +0000
Subject: Query Strings
In-Reply-To: <1141063286.117280.1590338036891@ichabod.co-bxl>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
Message-ID: <20200524164242.GB19442@SDF.ORG>

On Sun, May 24, 2020 at 06:33:56PM +0200, Brian Evans wrote:
 
> I think it would be good to clearly state what is expected of clients and servers
> regarding the escaping of querystring values for gemini.

Clients should definitely be URL escaping their queries, and servers
should be unescaping them at their end.

If this isn't done, then the thing that clients send to servers aren't
genuine, RFC-compliant URLs.  I would actually expect that any server
using a URL-parsing function from a decent library would get an error
from that function if attempting to parse an unescaped URL, and would
in turn give a permanent failure status back to the Gemini client.

Yet another client torture test?

Cheers,
Solderpunk

From b__m__e at mailfence.com  Sun May 24 18:11:09 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 24 May 2020 19:11:09 +0200 (CEST)
Subject: Query Strings
In-Reply-To: <1141063286.117280.1590338036891@ichabod.co-bxl>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
Message-ID: <395363538.119196.1590340269172@ichabod.co-bxl>

According to RFC3986:
>   The URI syntax provides a method of encoding data, presumably for the
>  sake of identifying a resource, as a sequence of characters.  The URI
>   characters are, in turn, frequently encoded as octets for transport
>   or presentation.  This specification does not mandate any particular
>   character encoding for mapping between URI characters and the octets
>   used to store or transmit those characters.  When a URI appears in a
>   protocol element, the character encoding is defined by that protocol;
>   without such a definition, a URI is assumed to be in the same
>   character encoding as the surrounding text.

Given the above, it seems that it is on gemini to define the encoding used
for URIs.

I particular this passage:
>   This specification does not mandate any particular
>   character encoding for mapping between URI characters and the octets
>   used to store or transmit those characters.

To my knowledge gopher does not URL encode querystrings (such that they
are in gopher - not generally compliant with other URI RFCs). 

I have left them unencoded in my recent release for Bombadillo in line
with what a perceive to be community standards until that community
standard changes or the spec explicitly makes clear the expectation.

I imagine Sean will have some good information here to bring to the table,
as he has read various RFCs in greater detail than I have. If anyone, not just
Sean, thinks I have misinterpreted the above mentioned RFC or that there
is not a need for a clear and explicit rule for how queries should be encoded
in the spec, please let me know.

From natpen at natpen.net  Sun May 24 18:15:59 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sun, 24 May 2020 13:15:59 -0400
Subject: Query Strings
In-Reply-To: <20200524164242.GB19442@SDF.ORG>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
 <20200524164242.GB19442@SDF.ORG>
Message-ID: <20200524171559.GA1739@goldfish.localdomain>

GUS uses Jetforce, which unquotes queries before passing them along
[1]. I'm not sure exactly what happened in your test cases Brian, but
typically I see escaped queries in the server logs (which I assume is
due to most clients automatically escaping their users' queries for
them).

[1] https://github.com/michael-lazar/jetforce/blob/b5f4235535d8eabad5a15cdf634f6d6149b37c29/jetforce/app/base.py#L64

And them from testing myself just now, when I submit a GUS query using
any of the big-name clients, I see my own query A) show up in GUS
server logs as escaped, and B) show up in the GUS query results page
as unescaped.

In the server logs, I think I found your queries, and one thing I
notice is that you're passing in pluses (`+`) for spaces, which I
don't actually think get handled by the standard quoting/unquoting
machinery (at least in Python). In Python, there's a separate
`unquote_plus()` method [2] which says it is "like unquote(), but also
replaces plus signs by spaces, as required for unquoting HTML form
values." So... I'm actually not sure if that's something Gemini should
respect, given the lack of forms.

[2] https://docs.python.org/3/library/urllib.parse.html#urllib.parse.unquote_plus

On Sun, May 24, 2020 at 04:42:42PM +0000, solderpunk wrote:
> On Sun, May 24, 2020 at 06:33:56PM +0200, Brian Evans wrote:
>
> > I think it would be good to clearly state what is expected of clients and servers
> > regarding the escaping of querystring values for gemini.
>
> Clients should definitely be URL escaping their queries, and servers
> should be unescaping them at their end.
>
> If this isn't done, then the thing that clients send to servers aren't
> genuine, RFC-compliant URLs.  I would actually expect that any server
> using a URL-parsing function from a decent library would get an error
> from that function if attempting to parse an unescaped URL, and would
> in turn give a permanent failure status back to the Gemini client.
>
> Yet another client torture test?
>
> Cheers,
> Solderpunk

From natpen at natpen.net  Sun May 24 18:33:34 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sun, 24 May 2020 13:33:34 -0400
Subject: Query Strings
In-Reply-To: <395363538.119196.1590340269172@ichabod.co-bxl>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
 <395363538.119196.1590340269172@ichabod.co-bxl>
Message-ID: <20200524173334.GB1739@goldfish.localdomain>

Actually I don't know if "big-name" is accurate - I think it's
probably just a biased set of clients in languages I frequently build
code in. Sorry! That may have come across as dismissive of other
clients, which I didn't intend. But, FWIW, of those clients I already
had around, here is a quick check of which ones escape and don't
escape with a current build:

Bombadillo : does not escape
Elpher     : escapes
AV-98      : escapes
Castor     : escapes

From solderpunk at SDF.ORG  Sun May 24 18:33:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 17:33:03 +0000
Subject: Query Strings
In-Reply-To: <395363538.119196.1590340269172@ichabod.co-bxl>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
 <395363538.119196.1590340269172@ichabod.co-bxl>
Message-ID: <20200524173303.GC19442@SDF.ORG>

Hmm.  Perhaps we have a little bit of wiggle room, but my reading of RFC
3986 section 2.2 leads me to believe that, if nothing else, the
characters:

":", "/", "?", "#", "[", "]", and "@"

are reserved characters in the generic URI scheme (which I presume means
they are also reserved in all protocol-specific schemes), so if those
appear in a client's response to a query prompt, they *need* to be
encoded some how - and for obvious reasons!

You're right, however, that exactly how they are encoded is up to us.
That's a surprise to me!  So the spec will have to address this, but
IMHO it's barely even up for discussion how to proceed here - we do it
how HTTP does it so we can leverage the pre-existing libraries in every
programming language under the sun, in keeping with the idea that Gemini
machinery should be easily assembled from existing parts as much as
possible.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun May 24 18:35:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 17:35:21 +0000
Subject: Query Strings
In-Reply-To: <20200524173334.GB1739@goldfish.localdomain>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
 <395363538.119196.1590340269172@ichabod.co-bxl>
 <20200524173334.GB1739@goldfish.localdomain>
Message-ID: <20200524173521.GD19442@SDF.ORG>

On Sun, May 24, 2020 at 01:33:34PM -0400, Natalie Pendragon wrote:

> Sorry! That may have come across as dismissive of other
> clients, which I didn't intend.

I'm sorry too, Brian, if my initial quick reply came across as
dismissive of your quesiton.  I had thought this was much more tightly
sewn up by the URI RFC.

Cheers,
Solderpunk

From b__m__e at mailfence.com  Sun May 24 19:16:49 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 24 May 2020 20:16:49 +0200 (CEST)
Subject: Query Strings
In-Reply-To: <395363538.119196.1590340269172@ichabod.co-bxl>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
 <395363538.119196.1590340269172@ichabod.co-bxl>
Message-ID: <1526758320.122713.1590344209823@ichabod.co-bxl>

Definitely no worries. I am a little bummed that I did not get this cleared up before a major
 release I just did. I just went through multi-hour (it needs to get improved) cross-compilation 
and website updates and do not relish doing so again this weekend. So this may sit for a short
bit, but will get updated in the not distant future for Bombadillo. I have added the issue on
the tildegit[1] and will try to get to it this week.

I definitely agree that escaping should occur, but since my client was originally built as a
gopher client I was not escaping there... and just never updated anything in that regard
when gemini got added. The Go net/url module's QueryEscape[2] uses '+' for space rather 
than '%20'.  So it seems that is why I was running into thinking people were not supporting 
escaping. What is the advice here? It seems that python does not, by default, escape a '+'
as a space and a number of servers are using Python. Further, it seems that '+' can be,
optionally, supported as representing a space... this seems like it can/will lead to problems.

My guess is that Molly Brown will support it fine, but that JetForce and many others may
not.

[1] https://tildegit.org/sloum/bombadillo/issues/161#issuecomment-5137
[2] https://golang.org/pkg/net/url/#QueryEscape


From b__m__e at mailfence.com  Sun May 24 19:59:00 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sun, 24 May 2020 20:59:00 +0200 (CEST)
Subject: [ANN] Big update to Bombadillo
Message-ID: <4844017.124546.1590346740735@ichabod.co-bxl>

I normally would not do an announcement on here for a new version (and do not generally plan to
in the future). However, there was a lot of gemini related stuff updated in Bombadillo this time
around and I thought gemini folks using it would want to know about the updates:

Changelog:

* Adds quick navigation to the first 10 links on a page (using the number keys 1 - 0, where 0 represents 10)
* Fixes a bug where on some platforms terminal line wrapping was not properly turned back on when Bombadillo exits
* Adds certificate expiration timestamps to the ini, next to the cert hash
* Uses the newly stored certificate expiration datetimes to autorenew certificates, resulting in far fewer certificate issues for users to deal with manually
* Fixes a bug in which two concurrent bits were trying to both read from stdin, resulting in a read being very buggy
* Adds 'h' and 'l' as hot key aliases for back and forward, bringing things further in line with vi style keybindings and keeping fingers on the home row
* Adds automatic requesting of new certificates on expiration (when the site is next visited)
* Adds support for alt text in gemini preformatted blocks
* Fixes a parsing error when parsing gemini preformatted blocks
* Adds config value 'geminiblocks' to control how alt text displays
* Improved handling of relative URLs for gemini
* Updates the gemini redirect policy to auto-redirect if, and only if, the only change to the requested URL would be the addition of a terminal '/' character
* Fixes issue where querystring values would chain instead of replace
* Removes a dependency on external program 'stty' in favor of a pure Go solution via syscalls
* Updates the man page with the relevant changes

As you may have seen here on the mailing list there is an issue with escaping query strings that is
currently present in all builds. I will be working out a fix after some thinking on the subject, so there
will likely be a patch later in the week.

Thanks to @dancek and @asdf for their contributions to this version and to @makeworld for
helping us sort through the issues and giving good input/guidance

If you build from source (by far the recommended route) you can just pull master and `sudo make install`.

If you use precompiled binaries they are available here:
http://bombadillo.colorfield.space/releases/binaries.html


As an added note: 

If you are a BSD user we are looking for some help making the Makefile function
under BSD (it runs fine for most Linux and OSX systems). At present it does not work under 
FreeBSD 12-Release. 

Additionally, if anyone is interested in getting involved as a maintainer for a package repo
we would be very interested in that (currently the Arch AUR has a git build version, but not
other repos currently have bombadillo).


Thanks everyone! I have been loving the influx of clients, servers, tools, and especially content!!

From tiwesdaeg at tilde.pink  Sun May 24 15:47:39 2020
From: tiwesdaeg at tilde.pink (Tiwesdaeg Twohands)
Date: Sun, 24 May 2020 09:47:39 -0500
Subject: [ANN] Big update to Bombadillo
In-Reply-To: <4844017.124546.1590346740735@ichabod.co-bxl>
References: <4844017.124546.1590346740735@ichabod.co-bxl>
Message-ID: <20200524094739.114f55ca@pricklypear>

I'm getting a weird issue on bombadillo. For gemini://tilde.pink/ and
gemini://tilde.pink/~tiwesdaeg/ it's not displaying the url line at the
top, except for a split second each time I press j and k to scroll up
and down. It shows up correctly on some of the other user gemini sites
on tilde.pink.

-Tiwesdaeg

On Sun, 24 May 2020 20:59:00 +0200 (CEST)
Brian Evans <b__m__e at mailfence.com> wrote:

> I normally would not do an announcement on here for a new version
> (and do not generally plan to in the future). However, there was a
> lot of gemini related stuff updated in Bombadillo this time around
> and I thought gemini folks using it would want to know about the
> updates:
> 
> Changelog:
> 
> * Adds quick navigation to the first 10 links on a page (using the
> number keys 1 - 0, where 0 represents 10)
> * Fixes a bug where on some platforms terminal line wrapping was not
> properly turned back on when Bombadillo exits
> * Adds certificate expiration timestamps to the ini, next to the cert
> hash
> * Uses the newly stored certificate expiration datetimes to autorenew
> certificates, resulting in far fewer certificate issues for users to
> deal with manually
> * Fixes a bug in which two concurrent bits were trying to both read
> from stdin, resulting in a read being very buggy
> * Adds 'h' and 'l' as hot key aliases for back and forward, bringing
> things further in line with vi style keybindings and keeping fingers
> on the home row
> * Adds automatic requesting of new certificates on expiration (when
> the site is next visited)
> * Adds support for alt text in gemini preformatted blocks
> * Fixes a parsing error when parsing gemini preformatted blocks
> * Adds config value 'geminiblocks' to control how alt text displays
> * Improved handling of relative URLs for gemini
> * Updates the gemini redirect policy to auto-redirect if, and only
> if, the only change to the requested URL would be the addition of a
> terminal '/' character
> * Fixes issue where querystring values would chain instead of replace
> * Removes a dependency on external program 'stty' in favor of a pure
> Go solution via syscalls
> * Updates the man page with the relevant changes
> 
> As you may have seen here on the mailing list there is an issue with
> escaping query strings that is currently present in all builds. I
> will be working out a fix after some thinking on the subject, so
> there will likely be a patch later in the week.
> 
> Thanks to @dancek and @asdf for their contributions to this version
> and to @makeworld for helping us sort through the issues and giving
> good input/guidance
> 
> If you build from source (by far the recommended route) you can just
> pull master and `sudo make install`.
> 
> If you use precompiled binaries they are available here:
> http://bombadillo.colorfield.space/releases/binaries.html
> 
> 
> As an added note: 
> 
> If you are a BSD user we are looking for some help making the
> Makefile function under BSD (it runs fine for most Linux and OSX
> systems). At present it does not work under FreeBSD 12-Release. 
> 
> Additionally, if anyone is interested in getting involved as a
> maintainer for a package repo we would be very interested in that
> (currently the Arch AUR has a git build version, but not other repos
> currently have bombadillo).
> 
> 
> Thanks everyone! I have been loving the influx of clients, servers,
> tools, and especially content!!


From peteyboy at sdf.org  Sun May 24 21:04:42 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Sun, 24 May 2020 13:04:42 -0700
Subject: Gemini and CGI hosting
In-Reply-To: <mailman.205.1590296333.533.gemini@lists.orbitalfox.eu>
References: <mailman.205.1590296333.533.gemini@lists.orbitalfox.eu>
Message-ID: <CB81617B-2C78-4B28-82CD-58A2709F1E7B@sdf.org>

So, in my head I've been noodling on the idea of writing a server. I don't understand at all the 10 response, I assume it's supposed to be this cgi business, because i don't see anywhere where a .gmi page can prompt the user. Is that true? Either way, could someone point me to a simple example? (I am running jetforce right now, if that helps)
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200524/8f03d109/attachment.htm>

From sean at conman.org  Sun May 24 21:17:43 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 24 May 2020 16:17:43 -0400
Subject: Client certificate musings
In-Reply-To: <20200524142726.GB4190@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local> <20200524142726.GB4190@SDF.ORG>
Message-ID: <20200524201743.GI23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> I'm, unsurprisingly, extremely out of touch with modern web development:
> are cookies still strictly tied to domains or have they evolved some
> kind of path-specificity?

  It's not path-specificity, but domain-specificity, but a cookie *can* be
shared between sub-domains of a domain.

	domain	cookies
	===============
	conman.org
		alpha

	www.conman.org
		alpba
		beta

	sub.www.conman.org
		alpha
		beta
		gamma

  The 'alpha' cookie will be sent to the domain and each subdomain, the
'beta' cookie will only be sent to the www subdomain, and 'gamma' will be
only sent to sub.www sub-subdomain.  A cookie can only be set on a domain,
not a TLD, but this requires some explaining.  If my site were under the UK,
then:

	conman.co.uk
		alpha

	www.conman.co.uk
		alpha
		beta

	sub.www.conman.co.uk
		alpha
		beta
		gamma

  A cookie for 'co,uk' MUST be rejected by browsers, as 'co.uk' is
considered a TLD (much like .org and .com).  Yes, this means that every
browser has to be aware of the domain rules for every country (and they can
change over time).  For the US, a domain is either a place name under a
state (two letter code) or (and this changed several years back) any domain
(other than the state ones) under the .us domain:

	nyc.ny.us	-- VALID for cookies
	acme.us		-- VALID for cookies
	ny.us		-- INVALID for cookies

  If you think this is insane, it is.  

  -spc (Kind of wish I was making this up)

From sean at conman.org  Sun May 24 21:33:47 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 24 May 2020 16:33:47 -0400
Subject: Gemini and CGI hosting
In-Reply-To: <CB81617B-2C78-4B28-82CD-58A2709F1E7B@sdf.org>
References: <mailman.205.1590296333.533.gemini@lists.orbitalfox.eu>
 <CB81617B-2C78-4B28-82CD-58A2709F1E7B@sdf.org>
Message-ID: <20200524203347.GJ23998@brevard.conman.org>

It was thus said that the Great peteyboy at sdf.org once stated:
> So, in my head I've been noodling on the idea of writing a server. I don't
> understand at all the 10 response, I assume it's supposed to be this cgi
> business, because i don't see anywhere where a .gmi page can prompt the
> user. Is that true? Either way, could someone point me to a simple
> example? (I am running jetforce right now, if that helps)

  Sure, go to 

	gemini://gemini.conman.org/hilo/

  It's a simple "Guess the Number" game.

  -spc


From solderpunk at SDF.ORG  Sun May 24 21:44:27 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 24 May 2020 20:44:27 +0000
Subject: Gemini and CGI hosting
In-Reply-To: <CB81617B-2C78-4B28-82CD-58A2709F1E7B@sdf.org>
References: <mailman.205.1590296333.533.gemini@lists.orbitalfox.eu>
 <CB81617B-2C78-4B28-82CD-58A2709F1E7B@sdf.org>
Message-ID: <20200524204427.GG19442@SDF.ORG>

On Sun, May 24, 2020 at 01:04:42PM -0700, peteyboy at sdf.org wrote:
> So, in my head I've been noodling on the idea of writing a server. I don't understand at all the 10 response, I assume it's supposed to be this cgi business, because i don't see anywhere where a .gmi page can prompt the user. Is that true? Either way, could someone point me to a simple example? (I am running jetforce right now, if that helps)
> -- 

There's no way to prompt the user from within a static text/gemini
document.  You'll need a server with some kind of support for dynamic
content to send the 10 status in response to a request.  This is perhaps
one of the the biggest conceptual differences between Gopher and Gemini.

I don't see it as a big limitation in practice - a static document
couldn't *do* anything with the user's response anyway, so there's going
to need to be a CGI app or something similar involved anyway.

Cheers,
Solderpunk

From felix at masterq32.de  Sun May 24 22:16:05 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 24 May 2020 23:16:05 +0200
Subject: Client certificate musings
In-Reply-To: <20200523145638.GG12486@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
Message-ID: <c985ea32-276d-1ab4-0f5b-20ccad31a44b@masterq32.de>

Hey!

> thoughts about client certificates

First of all: I really love the idea of client certificates, especially
for short-term session management it's a nice idea!

I wanted to write a much longer, more detailed answer with deeper
insight, but i don't think i'll find the time for that, so i just share
my "main" concern/idea:

When i first read the idea of the persistent/long-term certificates, i
didn't even come across the idea of using it for whitelisting.

My first thought was: Nice, this makes some really good identitiy
management for web forums/shops/chats/...

It gives the client full control over their identity. I can use multiple
client certificates for the same site to manage different identities.

What i imagined in a client was this:
https://i.imgur.com/Ayh2sVx.png

When a server requests use of a client certificate, you get to chose one
of many identities, maybe even share an identity between sites for
collaborating services.

You are always allowed to create new identities, destroy old ones.

</end-of-vision>

It didn't occur to me that certificates require a lifetime to be chosen
and now i'm thinking about how to solve this.

The "easy" way would be to create certificates with 150 year duration,
and force the recovery strategies on the user. But as already discussed,
this isn't practical and losing the certificate and/or key would require
some kind of account recovery strategy.

E-Mail-Recovery is a usual strategy common in the webspace, but i'm not
a huge fan of that. Another possibility would be that the server gives
the user a common secret that allows re-connection of a account to a new
certificate, but there's the same problem of the lost identity.

Regards
- xq

From sean at conman.org  Sun May 24 22:28:58 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 24 May 2020 17:28:58 -0400
Subject: Query Strings
In-Reply-To: <1141063286.117280.1590338036891@ichabod.co-bxl>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
Message-ID: <20200524212858.GK23998@brevard.conman.org>

It was thus said that the Great Brian Evans once stated:
> Greetings,
> I got a bug report recently for Bombadillo about how I have been handling
> query strings. 

  [ snip ]

> I think it would be good to clearly state what is expected of clients and
> servers regarding the escaping of querystring values for gemini.

  There are three standards conflating here.  They are:

	[CGI]	  RFC-3875
	[URI]	  RFC-3986
	[WEBFORM] https://www.w3.org/TR/html401/interact/forms.html

  I'm going to try to do a summary here (if anyone is interested in the gory
details, check the docs listed above).  To encode a URL (per [URI]), the
following characters can be used AS IS:

	ALPHA DIGIT - . _ ~

and the following characters MUST always be encoded [1]:

	% < > [ ] { } | \ ^ SPACE CONTROL NON-ASCII

  The set of characters not included in this depend upon where in the URL is
appears (more on that below).

  Encoding a character means converting it to its hex value and preceeding
it with a '%':

	##%	-> %23%23%25

  Each section of a URL (scheme, authority [2], path, query, fragment)
allows certain characters that would otherwise be encoded to NOT be encoded. 
I'll concentrate on the query portion since that's the part under question. 
The query portion allows the following characters to appear non-encoded:

	ALPHA DIGIT - . _ ~ / ? : @

  The '=' and '&' are used as sub-delimeters (to separate name and value,
and to separate namevalue pairs).  If a '=' or '&' appear in a name or the
value, they have to be encoded.

  The '+' sign is listed as a sub-delimeter in [URI], but otherwise says
nothing about it.  [CGI] and [WEBFORM] define it differently.  [CGI] allows
it, but *only* if '=' and '&' aren't used (section 4.4):

	...?one+two+three		'+' ALLOWED
	...?one+two=3&three=3		'+' DISALLOWED

  And in this case, the '+' is to be treated as a space.  In any other case,
the space needs to be encoded:

	...?query=what%20is%20this%20madness&lang=en	DEFINED
	...?query=what+is+this+madness&lang=en		UNDEFINED

  [WEBFORM] defines the '+' to be a space, but only when the data is being
sent as part of a POST, and the content type is
"application/x-www-form-urlencoded".  This doesn't apply at all to Gemini.

  Now, it could be that there are webservers (or CGI scripts) that convert
'+' to spaces reguardless.  I'm just saying ...

  Hopefully, this clears it all up (said as he wipes the mud off his face).

  -spc (Don't hesitate to ask any questions ... )

[1]	You'd be hard pressed to see these listed in [URI] since they aren't
	listed!  RFC-1738 lists those characters explicitly, so that's four
	references.  Sorry.

[2]	[URI] calls the host portion "authority".

From martin at no.ucant.org  Sun May 24 23:22:48 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sun, 24 May 2020 23:22:48 +0100 (BST)
Subject: Client certificate musings
In-Reply-To: <20200523145638.GG12486@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>

On Sat, 23 May 2020, solderpunk wrote:

> I first learned about client certificates in the murky, distant past
> when the "semantic web" was a hot topic, in the context of the
> decentralised "Friend Of a Friend" social network idea.  You can read
> about FOAF+SSL at https://www.w3.org/wiki/Foaf+ssl.

Though very skeptical about SSL itself, I have always had a soft spot for 
SSL client certificates. I first came across them at Zeus (we made an HTTP 
webserver that behaved rather differently from Apache; in particular, CGI 
was implemented via a SCGI-like mechanism. I loved CGI - in the 1990s I 
would check in at http://hoohoo.uiuc.ncsa.edu/CGI/ just to see if they'd 
updated the spec): not only did some of our customers use client certs, 
but we used them for authenticating email: if your cert had been signed by 
our CA and not revoked, the IMAP/SMTP magically worked for you, otherwise 
no.

I've tried writing a Gemini server (now looking pretty tidy: 
https://github.com/mk270/blizanci/blob/master/apps/blizanci/src/blizanci_gemini.erl 
) but I reckon SSL client certs are going to be what stops me using Erlang 
and forces me over to Rust with the cool crowd. The use case I care about 
is your first one:

   I want to make a set of documents available to clients who can present a
   certificate signed by a particular CA (e.g., one I control).

I appreciate that under the current dispensation, the distribution of 
certificates or certificate-signing-requests is out-of-band, but in my use 
case, it's not clear to me how I'd go about implementing this. I'd
have thought something like:

C: connect to S, without presenting a client cert and request /path/file
S: 62 you need to present an authorised client cert; closes connection

C: reconnect to S, presenting appropriate client cert, request /path/file
S: 20 text/gemini [data follows]; closes connection

However, it's my possibly mistaken understanding that an SSL client will 
not present a cert to the server unless the server sends the 
CertificateRequest message first. Since the server doesn't know whether 
the client is going to ask for a restricted resource, it won't request a 
client cert. This seems to lead to a chicken-and-egg problem: to get 
access to the resource, the client must present its cert; to present the 
cert, the client must be asked to do so by the server; but the server 
doesn't know it should ask for the certificate before the client has said 
which resource it wants to access.

This only arises where there is a combination of restricted and 
unrestricted resources in the URL namespace on a server on a particular 
port. In the case where *all* the resources on the server are restricted, 
the server could unconditionally request a cert from each client that 
connects, and then allow or deny access to the resources on a per-URL, 
per-cert basis. What seems to be impossible is having a landing page, say, 
gemini://gemini.podunk.edu/ which has a link to 
gemini://gemini.podunk.edu/restricted on its main landing page.

Maybe this is fine, or maybe I misunderstand how SSL works (I know things 
changed a little on the certificate request front in TLS1.3).


Anyway, I think the ergonomics and patterns around how certificate signing 
requests get moved around are going to be a bigger problem.

Keep up the good work!

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From martin at no.ucant.org  Sun May 24 23:41:57 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sun, 24 May 2020 23:41:57 +0100 (BST)
Subject: Client certificate musings
In-Reply-To: <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
Message-ID: <alpine.DEB.2.20.2005242341340.18317@pling.qwghlm.org>

On Sun, 24 May 2020, Martin Keegan wrote:

>
> Anyway, I think the ergonomics and patterns around how certificate signing 
> requests get moved around are going to be a bigger problem.

Oh, +1 on using the "Common Name" / CN field as a username.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From felix at masterq32.de  Mon May 25 12:54:55 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Mon, 25 May 2020 13:54:55 +0200
Subject: Split the spec into two
Message-ID: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>

Hey!

It just came to me that the specification for gemini is actually two
specifications intermixed, making it hard to work on only one of the two
components.

I propose to split the specification into either two documents or a
single document with a clear separation between text/gemini and the
gemini protocol.

This shouldn't change anything semantic-wise, but makes working with the
specifications easier as i don't have to skip-read over all text/gemini
stuff when writing the protocol implementation itself and vice-versa.

If that's already planned for one day: Cool, looking forward to that!
If not: Please consider to separate these two parts, even if they are
pretty close related

Regards
- xq

From defdefred at protonmail.com  Mon May 25 14:26:23 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 25 May 2020 13:26:23 +0000
Subject: Split the spec into two
In-Reply-To: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
References: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
Message-ID: <UAGmxLfaynIQH8HMWiYFxwdKUlAj2sj5ehuW1owzaFdP0B1DaFG2f847SLWTzkYjBoDfmj_xDmvnrS40_WAsU_tO6jGqyo-2jgOuomFix04=@protonmail.com>

+1

??????? Original Message ???????
On Monday 25 May 2020 13:54, Felix Quei?ner <felix at masterq32.de> wrote:

> Hey!
>
> It just came to me that the specification for gemini is actually two
> specifications intermixed, making it hard to work on only one of the two
> components.
>
> I propose to split the specification into either two documents or a
> single document with a clear separation between text/gemini and the
> gemini protocol.
>
> This shouldn't change anything semantic-wise, but makes working with the
> specifications easier as i don't have to skip-read over all text/gemini
> stuff when writing the protocol implementation itself and vice-versa.
>
> If that's already planned for one day: Cool, looking forward to that!
> If not: Please consider to separate these two parts, even if they are
> pretty close related
>
> Regards
>
> -   xq



From colecmac at protonmail.com  Mon May 25 16:51:40 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 25 May 2020 15:51:40 +0000
Subject: [ANN] Big update to Bombadillo
In-Reply-To: <20200524094739.114f55ca@pricklypear>
References: <4844017.124546.1590346740735@ichabod.co-bxl>
 <20200524094739.114f55ca@pricklypear>
Message-ID: <91WMgnxsnPFve3RxNYyEpW4MaoKoE5gXj-0yPUQA6e6eVFm9uqZQKWam47sriN5_A4ULPTXvIXorcifitTuAvVog_NMSWtIWcAgsHFwQN_A=@protonmail.com>

On Sunday, May 24, 2020 10:47 AM, Tiwesdaeg Twohands <tiwesdaeg at tilde.pink> wrote:

> I'm getting a weird issue on bombadillo. For gemini://tilde.pink/ and
> gemini://tilde.pink/~tiwesdaeg/ it's not displaying the url line at the
> top, except for a split second each time I press j and k to scroll up
> and down. It shows up correctly on some of the other user gemini sites
> on tilde.pink.
>
> -Tiwesdaeg


I can't confirm this, it displays fine for me. I'm using Guake on Arch Linux.

makeworld

From colecmac at protonmail.com  Mon May 25 16:54:32 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 25 May 2020 15:54:32 +0000
Subject: Query Strings
In-Reply-To: <20200524212858.GK23998@brevard.conman.org>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
 <20200524212858.GK23998@brevard.conman.org>
Message-ID: <mIbgwewiglbTQqJYunYyMOQFiCilcI_l9Tqj9ppnd1kgPj2d5G4ZfBFB3WhmHa9Dd306-up127xthOxhyPFmzF1dIFQ_d7A1YmIs4ImxRdc=@protonmail.com>

I think it might just make the most sense to say in the spec that
encoding is required, and should be done with percent signs, for
spaces too. Like in Sean's message:

?query=what%20is%20this%20madness&lang=en


makeworld

??????? Original Message ???????
On Sunday, May 24, 2020 5:28 PM, Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great Brian Evans once stated:
>
> > Greetings,
> > I got a bug report recently for Bombadillo about how I have been handling
> > query strings.
>
> [ snip ]
>
> > I think it would be good to clearly state what is expected of clients and
> > servers regarding the escaping of querystring values for gemini.
>
> There are three standards conflating here. They are:
>
> [CGI] RFC-3875
> [URI] RFC-3986
> [WEBFORM] https://www.w3.org/TR/html401/interact/forms.html
>
> I'm going to try to do a summary here (if anyone is interested in the gory
> details, check the docs listed above). To encode a URL (per [URI]), the
> following characters can be used AS IS:
>
> ALPHA DIGIT - . _ ~
>
> and the following characters MUST always be encoded [1]:
>
> % < > [ ] { } | \ ^ SPACE CONTROL NON-ASCII
>
> The set of characters not included in this depend upon where in the URL is
> appears (more on that below).
>
> Encoding a character means converting it to its hex value and preceeding
> it with a '%':
>
> ##% -> %23%23%25
>
> Each section of a URL (scheme, authority [2], path, query, fragment)
> allows certain characters that would otherwise be encoded to NOT be encoded.
> I'll concentrate on the query portion since that's the part under question.
> The query portion allows the following characters to appear non-encoded:
>
> ALPHA DIGIT - . _ ~ / ? : @
>
> The '=' and '&' are used as sub-delimeters (to separate name and value,
> and to separate namevalue pairs). If a '=' or '&' appear in a name or the
> value, they have to be encoded.
>
> The '+' sign is listed as a sub-delimeter in [URI], but otherwise says
> nothing about it. [CGI] and [WEBFORM] define it differently. [CGI] allows
> it, but only if '=' and '&' aren't used (section 4.4):
>
> ...?one+two+three '+' ALLOWED
> ...?one+two=3&three=3 '+' DISALLOWED
>
> And in this case, the '+' is to be treated as a space. In any other case,
> the space needs to be encoded:
>
> ...?query=what%20is%20this%20madness&lang=en DEFINED
> ...?query=what+is+this+madness&lang=en UNDEFINED
>
> [WEBFORM] defines the '+' to be a space, but only when the data is being
> sent as part of a POST, and the content type is
> "application/x-www-form-urlencoded". This doesn't apply at all to Gemini.
>
> Now, it could be that there are webservers (or CGI scripts) that convert
> '+' to spaces reguardless. I'm just saying ...
>
> Hopefully, this clears it all up (said as he wipes the mud off his face).
>
> -spc (Don't hesitate to ask any questions ... )
>
> [1] You'd be hard pressed to see these listed in [URI] since they aren't
> listed! RFC-1738 lists those characters explicitly, so that's four
> references. Sorry.
>
> [2] [URI] calls the host portion "authority".



From cage-dev at twistfold.it  Mon May 25 17:33:57 2020
From: cage-dev at twistfold.it (cage)
Date: Mon, 25 May 2020 18:33:57 +0200
Subject: humble suggestions to specs documentation
Message-ID: <20200525163357.GA4823@kurosawa.casa.net>

Hi!

I  find  gemini very  exciting,  bringing  back  some fun  in  network
programming!

I have some  small suggestions to spec style, i  apologize if this was
already  addressed in  a previous  message  (i am  lazy and  i did  not
searched archive, sorry).

       --------------
1.3.1

Gemini response headers look like this:

<STATUS> <META><CR><LF>

[...]

       --------------

In my opinion the space character between <STATUS> and <META> could be
a symbol not the character itself something like:

<STATUS><SPACE><META><CR><LF>

this  way it  is much  more difficult  that the  reader could  miss or
misunderstand the single space in the response line.

       --------------

1.4.2

[...]

1.4.3

       --------------

I think would be a good idea to include some code snippets (maybe in C
with libssl?) to illustrate how to do server validation or make client
certificate.

I the code was  too long could be added in an  appendix or some code
form an existing implementation can be linked, i do know.

I think there is a minor typo in the FAQ:

       --------------
### 1.3 Where can I learn more?

[...]

Official discussion regarding Gemini hapens on a mailing list.

[...]

       --------------

Bye and thank you for gemini!
C.

From lazar.michael22 at gmail.com  Mon May 25 17:44:45 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Mon, 25 May 2020 12:44:45 -0400
Subject: jetforce security vulnerability, affecting versions < 0.2.3
Message-ID: <CAFTy05YPNVU-q8KnYyPmZneGQAyYTevvwAfa-KsBi7XQVvm1_Q@mail.gmail.com>

Greetings,

A vulnerability was recently discovered regarding the jetforce server. There
was a bug in the code that allowed maliciously crafted URLs to break out of
the
root directory and serve files from elsewhere on the filesystem [1].

I have fixed the issue and have uploaded a new release v0.2.3 to PyPI and
Github [2][3]. This is a bugfix-only release and does not contain any other
breaking changes. I now consider all versions < v0.2.3 to be insecure. If
you
are running jetforce, I strongly urge you to upgrade to the latest version
as
soon as possible.

Best,
Michael

[1] https://github.com/michael-lazar/jetforce/issues/24
[2] https://github.com/michael-lazar/jetforce/releases/tag/v0.2.3
[3] https://pypi.org/project/Jetforce/0.2.3/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200525/6ce17ffc/attachment.htm>

From peteyboy at sdf.org  Mon May 25 21:16:27 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Mon, 25 May 2020 13:16:27 -0700
Subject: Gemini and CGI hosting
In-Reply-To: <mailman.1.1590404401.26413.gemini@lists.orbitalfox.eu>
References: <mailman.1.1590404401.26413.gemini@lists.orbitalfox.eu>
Message-ID: <519A8F20-D42F-4B3B-8061-604697DDE69C@sdf.org>

Cool, i will check that out. But is that a custom app, then? There's no .cgi file or anything you're pointing to. How'd you implement it?

>Date: Sun, 24 May 2020 16:33:47 -0400
>From: Sean Conner <sean at conman.org>
>To: "A protocol that is slightly more complex than gopher, but
>	significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
>Subject: Re: Gemini and CGI hosting
>Message-ID: <20200524203347.GJ23998 at brevard.conman.org>
>Content-Type: text/plain; charset=us-ascii
>
>It was thus said that the Great peteyboy at sdf.org once stated:
>> So, in my head I've been noodling on the idea of writing a server. I
>don't
>> understand at all the 10 response, I assume it's supposed to be this
>cgi
>> business, because i don't see anywhere where a .gmi page can prompt
>the
>> user. Is that true? Either way, could someone point me to a simple
>> example? (I am running jetforce right now, if that helps)
>
>  Sure, go to 
>
>	gemini://gemini.conman.org/hilo/
>
>  It's a simple "Guess the Number" game.
>
>  -spc
>
>
>
>------------------------------

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From sean at conman.org  Mon May 25 22:06:58 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 25 May 2020 17:06:58 -0400
Subject: Gemini and CGI hosting
In-Reply-To: <519A8F20-D42F-4B3B-8061-604697DDE69C@sdf.org>
References: <mailman.1.1590404401.26413.gemini@lists.orbitalfox.eu>
 <519A8F20-D42F-4B3B-8061-604697DDE69C@sdf.org>
Message-ID: <20200525210658.GN23998@brevard.conman.org>

It was thus said that the Great peteyboy at sdf.org once stated:
> Cool, i will check that out. But is that a custom app, then? There's no
> .cgi file or anything you're pointing to. How'd you implement it?

  You are right it's not a CGI script [1].  It's a custom module I added to
the server [2].  The source code is here:

	gemini://gemini.conman.org/extensions/GLV-1/handlers/hilo.lua

and most of it is just error checking, I can still walk you through the code
though.  

	function handler(_,_,loc,match)

  The handler gets four parameters, but I don't care about the first two
(the first is the configuration paremeters for the handler, which for this
handler I don't care about, and the second is the client certificate info,
again, there is none).  The third one is the broken down URL, for example:

	{
	  scheme = "gemini",
	  path = "/hilo/1082",
	  query = "33",
	  host = "gemini.conman.org",
	  port = 1965.000000,
	}

  The last parameter is the path portion of the URL broken up into two
components (it's specified in the configuration portion how to split the
path up) and for the example above, it would be:

	{ "/hilo/" , "1082" }

  When you first enter the game, the second element of the match paramter
will be "", so that starts a game, which generates a random number and
generates a link that contains the encoded number (I wanted something simple
to demonstrate the 10 status codes, I didn't want to make this bulletproof).

  If there's no query portion to the URL, then I return a status code of 10
with a prompt.  If there *is* a query portion, I decode the query string and
do some error checking (making sure it's formatted properly and a number). 
I then convert the second portion of the match paramter to a value to
recover the original number, compare it to the guess and return a 10 status
code if it's not right, or a 20 if you guessed it.

  It could very well be a CGI script, and I could make it look exactly the
same with the same URLs and everything [3], but I went this route because I
could, and it was a bit easier to implement.

  -spc

[1]	The server it's running on does support CGI.

[2]	Because its' easy enough to write a custom module (or handler) for
	GLV-1.12556.

[3]	In my server, when it comes across a file that is marked executable,
	and CGI is enabled, will then treat the file as a CGI script.  No
	special extensions required.  For example:

		gemini://gemini.conman.org/cgi/test
		gemini://gemini.conman.org/cgi/test/1082
		gemini://gemini.conman.org/cgi/test/1082?33

	Here, the CGI script is called "test".  

From sean at conman.org  Tue May 26 00:11:04 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 25 May 2020 19:11:04 -0400
Subject: Gateway Interfaces for Gemini
Message-ID: <20200525231103.GO23998@brevard.conman.org>


  I just finished support for SCGI for GLV-1.12556, which makes it the
second gateway interface it supports (the other being CGI).  And I feel this
is probably the time to talk variables---what informatino can be expected
for CGI and SCGI programs when then run under Gemini.  The CGI specification
[1] calls such information "meta-variables".  The SCGI specification [2]
calls them "headers".  Most people know them as "environment variables" [3],
but whatever, it would be nice to know what a gateway interface program can
expect in the way of data from the server.

  As I've mentioned before, for CGI, I follow the spec (with some minor
variations due to Gemini).  For SCGI, I decided to pass along the same
information but with a minor variation.  So, for BOTH, the data I pass
along:

	GEMINI_DOCUMENT_ROOT	Path to the domain's main content directory
	GEMINI_URL		The requested URL
	GEMINI_URL_PATH		The path portion of the requested URL
	PATH_INFO		optional per CGI
	PATH_TRANSLATED		optional per CGI
	QUERY_STRING		Query string portion of request, or "" [a]
	REMOTE_ADDR		Remote address [b]
	REMOTE_HOST		Remote hostname [b][c]
	SCRIPT_NAME		Name of the script [d]
	SERVER_NAME		Hostname of the request
	SERVER_PORT		Port number from the request
	SERVER_SOFTWARE		"GLV-1.12556/1"

	AUTH_TYPE		"Certificate" [e]
	REMOTE_USER		The subject CN from the client cert [e]

	TLS_CIPHER		TLS cipher used [e][f]
	TLS_CLIENT_HASH		TLS hash [e][f]
	TLS_CLIENT_ISSUER	The issuer field [e][f][g]
	TLS_CLIENT_ISSUER_*	Subfields from the isser (like C, CN, etc.) [e][f]
	TLS_CLIENT_NOT_AFTER	Expiration date [e][f]
	TLS_CLIENT_NOT_BEFORE	Valid date [e][f]
	TLS_CLIENT_REMAIN	Number of days until cert expires [e][f]
	TLS_CLIENT_SUBJECT	The subject field [e][f]
	TLS_CLIENT_SUBJECT_*	Subfields from the subject(like CN, etc.) [e][f][g]
	TLS_VERSION		TLS version being used [e][f]

[a]	Mandatory per RFC-3875
[b]	Mandatory per RFC-3875---the more security conscience of you might
	not like this, but in that case, I can recommend the value of
	"127.0.0.1" or "::1" 
[c]	Can be the IP address, which is what I do
[d]	In my case, it's the full path to the file (CGI) or symbolic link
	(SCGI) 
[e]	Only set if a client certificate is sent
[f]	Only set if configured to do so.
[g]	For example, TLS_CLIENT_SUBJECT_CN, TLS_CLIENT_SUBJECT_OU

  I added GEMINI_DOCUMENT_ROOT to mimic Apache's DOCUMENT_ROOT, and
GEMINI_URL and GEMINI_URL_PATH because I found a few servers that defined
GEMINI_URL and passed either the full URL or the path portion, and I wanted
to cover both cases with something.

  For CGI, the program will also receive the following variable:

	GATEWAY_INTERFACE	"CGI/1.1" (mandatory per RFC-3875)

  And for SCGI, the program will receive the following variables:

	CONTENT_LENGTH		"0" (mandatory per spec)
	SCGI			"1" (mandatory per spec)

  Why SCGI didn't use GATEWAY_INTERFACE="SCGI/1" is beyond me, but anyway,
there's the variables I pass along for both CGI and SCGI.  You can see
actual values used by following these links:

	gemini://gemini.conman.org/cgi/test
	gemini://gemini.conman.org/cgi/test/path/file
	gemini://gemini.conman.org/scgi-sample
	gemini://gemini.conman.org/scgi-sample/path/file

  If you see some extra data, it's because I allow extra values to be set.

  And my question to you is---what variables should a CGI/SCGI program
depend upon to exist?

  -spc

[1]	RFC-3875

[2]	https://web.archive.org/web/20020403050958/http://python.ca/nas/scgi/protocol.txt

[3]	Because how they're passed to CGI scripts.

From colecmac at protonmail.com  Tue May 26 00:39:07 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 25 May 2020 23:39:07 +0000
Subject: [ANN] gemlikes - A liking and comment system for Gemini
Message-ID: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>

Hello Geminauts,

I had this idea pretty soon after finding out about Gemini, and over
the past week or so I've finally managed to implement it.

Like many of us, I've really enjoyed reading and taking in people's
gemlogs on Geminispace. But I often want to reply to what people have
written, to ask a question, let them know I enjoyed it etc. I created
gemlikes to be able to do that.

It consists of three binaries, and works using CGI. This means you don't
have to run another server or anything, it should work with any server
that supports CGI. If it doesn't, please let me know!

There's a demo of the system available on my site[1], and the code is on
Github[2]. Most other questions like how to get it up and running, etc,
should be answered on that README.

1: gemini://makeworld.gq/gemlog/2020-05-21-first.gmi
2: https://github.com/makeworld-the-better-one/gemlikes

I'm hoping that this can be "successful" in the Geminispace, and that it
won't just be my gemlog that uses it. If there's a feature that would help
you use it, feel free to let me know!


makeworld

From tkarpiniec at icloud.com  Tue May 26 05:05:17 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Tue, 26 May 2020 14:05:17 +1000
Subject: An unexpected favicon request
Message-ID: <20200526040517.GA1478@allanon.local>

Hi all,

I noticed an interesting error in my server log:

status=51 request=gemini://gem.1.21jiggawatts.net/posts/favicon.ico

I guess somebody is experimenting with this in a client - it looks
like it was an automated request following a .gmi file. What's odd is
that it's looking in exactly the same directory as the page that was
requested, rather than the domain root.

It strikes me as a bug but I thought I'd bring it up to see if anyone
thinks otherwise!

Cheers,

Tom

From sean at conman.org  Tue May 26 09:29:35 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 26 May 2020 04:29:35 -0400
Subject: An unexpected favicon request
In-Reply-To: <20200526040517.GA1478@allanon.local>
References: <20200526040517.GA1478@allanon.local>
Message-ID: <20200526082935.GP23998@brevard.conman.org>

It was thus said that the Great Thomas Karpiniec once stated:
> Hi all,
> 
> I noticed an interesting error in my server log:
> 
> status=51 request=gemini://gem.1.21jiggawatts.net/posts/favicon.ico
> 
> I guess somebody is experimenting with this in a client - it looks
> like it was an automated request following a .gmi file. What's odd is
> that it's looking in exactly the same directory as the page that was
> requested, rather than the domain root.
> 
> It strikes me as a bug but I thought I'd bring it up to see if anyone
> thinks otherwise!

  I found requests for favicon.ico from last week.  Perhaps it's a web
proxy?  

  Anyway, I set up my server to serve up a favicon.ico no matter where it's
requested (oh yeah, new feature to GLV-1.12556).

  -spc (That shouldn't be a problem, right?)




From pitr.vern at gmail.com  Tue May 26 10:42:20 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 26 May 2020 11:42:20 +0200
Subject: Geddit, link aggregator for Gemini
Message-ID: <CAG-mZ3id5iEk2T5ji80POpEhUs4fa5P48mbp7qdQB-2DDS4P-g@mail.gmail.com>

Been working on a super simple link aggregator like reddit that works for
Gemini.

gemini://geddit.pitr.ca

Decided against likes/votes as these would be inflated by crawlers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/aa125e9e/attachment.htm>

From acdw at acdw.net  Tue May 26 04:18:28 2020
From: acdw at acdw.net (Case Duckworth)
Date: Mon, 25 May 2020 22:18:28 -0500
Subject: [ANN] bollux, a bash gemini browser
Message-ID: <20200525221828.67386af2@bax>

Well, it took me a little longer than a weekend but I got it done!

I'm proud to announce the release of *bollux*, a Gemini browser written
in bash:

https://git.sr.ht/~acdw/bollux
gemini://gemini.circumlunar.space/~acdw/bollux (just the README)

It requires stuff most Linux users should have, like gawk
(possibly could use awk), dd, a recent version of bash, etc.

As of this release, bollux can
- navigate to gemini urls
- display text/* documents, and prettify text/gemini ones
- download other mimetypes

I still want to implement history, bookmarks, and the other
ease-of-life improvements that make a browser worth using. But I also
really wanted to send a [ANN] email tonight, so here we are.

Let me know what you think!

-- 
Best,
Case
acdw.net | breadpunk.club
he/him

From hannu.hartikainen+gemini at gmail.com  Tue May 26 14:15:55 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Tue, 26 May 2020 16:15:55 +0300
Subject: [ANN] personal Gemini space and twinlog
Message-ID: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>

Hi!

I've been lurking for a couple of days and had some code merged to
Bombadillo, and now I finally got my own Gemini space up.

gemini://hannuhartikainen.fi/

I'll probably be posting some raw tech content (see the mirrored blog
posts, or my website for an idea of topics), and the non-tech things I want
to write about but don't want to make an eternal part of my public image.
Sorry for not being more specific right now, but my interests vary.

Oh, and there's a feed at gemini://hannuhartikainen.fi/twinlog/atom.xml .
I'd be happy to be included in CAPCOM and Spacewalk if @solderpunk and
@sloum are reading. :)

Thanks to everyone who's been building the community and the tooling! Happy
to be here!

--
Hannu Hartikainen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/b47fc844/attachment.htm>

From colecmac at protonmail.com  Tue May 26 16:04:16 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 26 May 2020 15:04:16 +0000
Subject: Geddit, link aggregator for Gemini
In-Reply-To: <CAG-mZ3id5iEk2T5ji80POpEhUs4fa5P48mbp7qdQB-2DDS4P-g@mail.gmail.com>
References: <CAG-mZ3id5iEk2T5ji80POpEhUs4fa5P48mbp7qdQB-2DDS4P-g@mail.gmail.com>
Message-ID: <eFg9zipBRwDddxxGruumYl5e_Rvofhkd3N3zjlsCcC65MoDcVxHVm9WrXRyMAmUJRw9OcnepYboBSTAb0pOXh44ZQxFAyXDdVqCBxqvKrKc=@protonmail.com>

Wow, that's pretty cool, nice work! Do you have the source code up anywhere?

I just made a comment system myself[1] and I'm interested in how yours works.

1: https://github.com/makeworld-the-better-one/gemlikes


makeworld

??????? Original Message ???????
On Tuesday, May 26, 2020 5:42 AM, Peter Vernigorov <pitr.vern at gmail.com> wrote:

> Been working on a super simple link aggregator like reddit that works for Gemini.
>
> gemini://geddit.pitr.ca
> Decided against likes/votes as these would be inflated by crawlers.



From colecmac at protonmail.com  Tue May 26 16:27:12 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 26 May 2020 15:27:12 +0000
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
Message-ID: <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>

Sounds interesting, but unfortunately I get a "Cert hostname does not match"
error in Bombadillo. Did you use a self-signed cert? If so, make sure
your hostname was entered in the correct field. You will have to recreate
the cert.

makeworld

??????? Original Message ???????
On Tuesday, May 26, 2020 9:15 AM, Hannu Hartikainen <hannu.hartikainen+gemini at gmail.com> wrote:

> Hi!
>
> I've been lurking for a couple of days and had some code merged to Bombadillo, and now I finally got my own Gemini space up.
>
> gemini://hannuhartikainen.fi/
>
> I'll probably be posting some raw tech content (see the mirrored blog posts, or my website for an idea of topics), and the non-tech things I want to write about but don't want to make an eternal part of my public image. Sorry for not being more specific right now, but my interests vary.
>
> Oh, and there's a feed at gemini://hannuhartikainen.fi/twinlog/atom.xml . I'd be happy to be included in CAPCOM and Spacewalk if @solderpunk and @sloum are reading. :)
>
> Thanks to everyone who's been building the community and the tooling! Happy to be here!
>
> --
> Hannu Hartikainen



From pitr.vern at gmail.com  Tue May 26 16:46:08 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 26 May 2020 17:46:08 +0200
Subject: Geddit, link aggregator for Gemini
In-Reply-To: <eFg9zipBRwDddxxGruumYl5e_Rvofhkd3N3zjlsCcC65MoDcVxHVm9WrXRyMAmUJRw9OcnepYboBSTAb0pOXh44ZQxFAyXDdVqCBxqvKrKc=@protonmail.com>
References: <CAG-mZ3id5iEk2T5ji80POpEhUs4fa5P48mbp7qdQB-2DDS4P-g@mail.gmail.com>
 <eFg9zipBRwDddxxGruumYl5e_Rvofhkd3N3zjlsCcC65MoDcVxHVm9WrXRyMAmUJRw9OcnepYboBSTAb0pOXh44ZQxFAyXDdVqCBxqvKrKc=@protonmail.com>
Message-ID: <CAG-mZ3jq1akibRUmDFYG3NVGvgmWwFP2XGNoJNXJT3RwF_pZpw@mail.gmail.com>

Thanks. Source is at
https://github.com/pitr/geddit it is quite simple.
I used a nice and minimal go library https://github.com/jackdoe/net-gemini

On Tue, May 26, 2020 at 17:04 <colecmac at protonmail.com> wrote:

> Wow, that's pretty cool, nice work! Do you have the source code up
> anywhere?
>
> I just made a comment system myself[1] and I'm interested in how yours
> works.
>
> 1: https://github.com/makeworld-the-better-one/gemlikes
>
>
> makeworld
>
> ??????? Original Message ???????
> On Tuesday, May 26, 2020 5:42 AM, Peter Vernigorov <pitr.vern at gmail.com>
> wrote:
>
> > Been working on a super simple link aggregator like reddit that works
> for Gemini.
> >
> > gemini://geddit.pitr.ca
> > Decided against likes/votes as these would be inflated by crawlers.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/5fcb8955/attachment.htm>

From detegr at rbx.email  Tue May 26 16:47:08 2020
From: detegr at rbx.email (Antti =?utf-8?Q?Ker=C3=A4nen?=)
Date: Tue, 26 May 2020 18:47:08 +0300
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
 <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>
Message-ID: <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>

On Tue, May 26, 2020 at 03:27:12PM +0000, colecmac at protonmail.com wrote:
> Sounds interesting, but unfortunately I get a "Cert hostname does not match"
> error in Bombadillo.

Confirmed. Works great with AV-98, but gives a certificate error when
accessed with Bombadillo.

-- 
Antti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/db427f3c/attachment.htm>

From hannu.hartikainen+gemini at gmail.com  Tue May 26 17:27:59 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Tue, 26 May 2020 19:27:59 +0300
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
 <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>
 <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>
Message-ID: <CANmFPemBsB=fPw8mx6bhX8+Ta0bwOsxGCxMcO1GQ7dFs+ZzBoQ@mail.gmail.com>

Oops! Thanks for pointing that out. It's fixed now.

Of course this will break TOFU, so at least users of AV-98 who visited
before will have to accept the new certificate with the
fingerprint f83a41457ae34c5cc6b3836bfdd41e4563ac73c4c03c1397306051c2544af491.

I was working with a subdomain for a long time, and only tested with AV-98
and ncgopher after switching domains. Live and learn, I guess.

On Tue, 26 May 2020 at 18:47, Antti Ker?nen <detegr at rbx.email> wrote:

> On Tue, May 26, 2020 at 03:27:12PM +0000, colecmac at protonmail.com wrote:
>
>> Sounds interesting, but unfortunately I get a ?Cert hostname does not
>> match? error in Bombadillo.
>>
> Confirmed. Works great with AV-98, but gives a certificate error when
> accessed with Bombadillo.
>
> ? Antti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/68cf3bea/attachment-0001.htm>

From solderpunk at SDF.ORG  Tue May 26 18:03:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:03:55 +0000
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
Message-ID: <20200526170355.GA6603@SDF.ORG>

On Tue, May 26, 2020 at 04:15:55PM +0300, Hannu Hartikainen wrote:
 
> Oh, and there's a feed at gemini://hannuhartikainen.fi/twinlog/atom.xml .
> I'd be happy to be included in CAPCOM and Spacewalk if @solderpunk and
> @sloum are reading. :)

Joo, min? luen. :)  Kiitos Atomista ja tervetuloa Geminiin!

But, hey, please be very careful about posting stuff in Geminispace that
you would not be comfortable posting to the web because you are worried
about possible real-world consequences.  I totally understand the
concern and applaud you being careful about it, but often these little
"underground" spaces prove not to be as hidden as you might think, in
the long term.  It has happened before in Gopherspace that somebody has
setup a Gopher-to-web proxy or gateway thing to make Gopherspace easily
accessible from a standard web browser, but they have not been careful
about using robots.txt to exclude search engine crawerls from that
service.  Now big swathes of Gopher content are easy to find via Google.
Obviously this stuff does not rank highly in Google's algorithms so it
won't turn up if you are writing about stuff which is widely discussed
on the web, but with a specific enough search term, it'll be there.

A carefully used psuedonym is a better idea, IMHO.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 26 18:05:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:05:55 +0000
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
 <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>
 <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>
Message-ID: <20200526170555.GB6603@SDF.ORG>

On Tue, May 26, 2020 at 06:47:08PM +0300, Antti Ker?nen wrote:
> On Tue, May 26, 2020 at 03:27:12PM +0000, colecmac at protonmail.com wrote:
> > Sounds interesting, but unfortunately I get a "Cert hostname does not match"
> > error in Bombadillo.
> 
> Confirmed. Works great with AV-98, but gives a certificate error when
> accessed with Bombadillo.

Huh, that's kind of weird, AV-98 should definitely be checking that one
of the hostnames in a certificate matches the expected hostname.  Or are
you running an older version (anything more than like a week old would
not bat an eye at this).

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Tue May 26 18:17:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:17:59 +0000
Subject: Geddit, link aggregator for Gemini
In-Reply-To: <CAG-mZ3id5iEk2T5ji80POpEhUs4fa5P48mbp7qdQB-2DDS4P-g@mail.gmail.com>
References: <CAG-mZ3id5iEk2T5ji80POpEhUs4fa5P48mbp7qdQB-2DDS4P-g@mail.gmail.com>
Message-ID: <20200526171759.GC6603@SDF.ORG>

On Tue, May 26, 2020 at 11:42:20AM +0200, Peter Vernigorov wrote:
> Been working on a super simple link aggregator like reddit that works for
> Gemini.
> 
> gemini://geddit.pitr.ca
> 
> Decided against likes/votes as these would be inflated by crawlers.

Very interesting, thanks for sharing!

It will be interesting to see how the possibility of applications like
this holds up long term in Geminispace.  Obviously on the web things
like Reddit rely very strongly on what are essentially tracking
technologies to combat spam by imposing rate limits for posting, making
people do CAPTCHAS, and so on.  Gemini has deliberately much reduced
ability for this kind of thing.  It won't matter in the early days when
this stuff is all for fun and has very little visibility (there are
plenty of guestbooks and things on Gophespace which are totally open in
this way but are totally spam free because it's just too out of the
way), but if Gemini ever really seriously takes off it will become an
issue.

Making people provide a client certificate and create an account is one
possible solution, and for something like a Reddit-clone people might
see that see the hassle of having to do that as worthwhile.  For quick
and simple things, like "likes", nobody will want to bother, so they
will eventually become totally meaningless (which somemight argue they
are in the first place :p).

This isn't necessarily a problem.  We don't need to recreate every part
of the web experience in Gemini - in fact, I and probably many others
will actively resist this!  But it will be very interesting to watch the
interaction of technical limitations and cultural norms and see which
kinds of familiar "tropes" from the web we carry over, which ones we
modify in some way to fit the new environment and which ones we simply
reject outright, or replace with something better.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 26 18:23:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:23:29 +0000
Subject: An unexpected favicon request
In-Reply-To: <20200526082935.GP23998@brevard.conman.org>
References: <20200526040517.GA1478@allanon.local>
 <20200526082935.GP23998@brevard.conman.org>
Message-ID: <20200526172329.GD6603@SDF.ORG>

 
>   I found requests for favicon.ico from last week.  Perhaps it's a web
> proxy?  

I would guess it's a Gemini client experimenting with the idea of
favicons in Gemini, which have certainly been proposed.  See, e.g.:

gemini://mozz.us/journal/2020-04-17.gmi

plus discussion elsewhere on this list (where somebody proposed using a
single UTF-8 encoded emoji as an ultralight favicon, which is a cute
idea).

>   Anyway, I set up my server to serve up a favicon.ico no matter where it's
> requested (oh yeah, new feature to GLV-1.12556).
> 
>   -spc (That shouldn't be a problem, right?)

Well, it's not really within the scope of the Gemini spec to explicitly
forbid things like this.  If people want to write clients which do it,
nobody can stop them.  If people want to do it, I strongly encourage
them to make it an option the user can easily disabled.  Some people,
myself included, hold the "one request per page" principle in very high
regard, so I probably wouldn't add this to a client of mine, even if I
had a graphical one where it made sense.

I do grant that, as far as "secondary requests" not under direct control
of the user go, this is probably the least harmful kind possible, where
the path is fixed and it goes to a server that the user has already
agreed to visit.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 26 18:28:23 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:28:23 +0000
Subject: [ANN] bollux, a bash gemini browser
In-Reply-To: <20200525221828.67386af2@bax>
References: <20200525221828.67386af2@bax>
Message-ID: <20200526172823.GE6603@SDF.ORG>

Howdy,

I clone the repo but when I try to use it:

zaibatsu$ ./bollux                                                                                              
GO> gemini.circumlunar.space
bollux:	[] 
bollux:	
./bollux: line 38: exit: 100 Unknown response code: .: numeric argument required
zaibatsu$

Am I doing it wrong?

Cheers,
Solderpunk

On Mon, May 25, 2020 at 10:18:28PM -0500, Case Duckworth wrote:
> Well, it took me a little longer than a weekend but I got it done!
> 
> I'm proud to announce the release of *bollux*, a Gemini browser written
> in bash:
> 
> https://git.sr.ht/~acdw/bollux
> gemini://gemini.circumlunar.space/~acdw/bollux (just the README)
> 
> It requires stuff most Linux users should have, like gawk
> (possibly could use awk), dd, a recent version of bash, etc.
> 
> As of this release, bollux can
> - navigate to gemini urls
> - display text/* documents, and prettify text/gemini ones
> - download other mimetypes
> 
> I still want to implement history, bookmarks, and the other
> ease-of-life improvements that make a browser worth using. But I also
> really wanted to send a [ANN] email tonight, so here we are.
> 
> Let me know what you think!
> 
> -- 
> Best,
> Case
> acdw.net | breadpunk.club
> he/him

From defdefred at protonmail.com  Tue May 26 18:37:31 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 26 May 2020 17:37:31 +0000
Subject: An unexpected favicon request
In-Reply-To: <20200526172329.GD6603@SDF.ORG>
References: <20200526040517.GA1478@allanon.local>
 <20200526082935.GP23998@brevard.conman.org>
 <20200526172329.GD6603@SDF.ORG>
Message-ID: <vdlzUCeXarxVJyzNhDfWPFhxrRAiroZWpHlorhkC-bDJAS4_tOBm_UV-AE_nikyd6Z2FO-atI5ItXfUHCxzSCAkyLnlWbuOt2fDp2wqlBiw=@protonmail.com>

On Tuesday 26 May 2020 19:23, solderpunk <solderpunk at SDF.ORG> wrote:
> Well, it's not really within the scope of the Gemini spec to explicitly
> forbid things like this. If people want to write clients which do it,
> nobody can stop them. If people want to do it, I strongly encourage
> them to make it an option the user can easily disabled. Some people,
> myself included, hold the "one request per page" principle in very high
> regard, so I probably wouldn't add this to a client of mine, even if I
> had a graphical one where it made sense.

Useless network usage...

"One request to rule them all" :-)


From detegr at rbx.email  Tue May 26 18:41:04 2020
From: detegr at rbx.email (Antti =?utf-8?Q?Ker=C3=A4nen?=)
Date: Tue, 26 May 2020 20:41:04 +0300
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <20200526170555.GB6603@SDF.ORG>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
 <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>
 <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>
 <20200526170555.GB6603@SDF.ORG>
Message-ID: <20200526174104.qmxz7cpudpog4sgt@haukka.localdomain>

On Tue, May 26, 2020 at 05:05:55PM +0000, solderpunk wrote:
> Huh, that's kind of weird, AV-98 should definitely be checking that one
> of the hostnames in a certificate matches the expected hostname.  Or are
> you running an older version (anything more than like a week old would
> not bat an eye at this).

I was running commit a68e092593fa2999a81edd7a7e111e52076d5922

Sadly I cannot test it again with the latest master branch as Hannu
fixed his server already. :)

-- 
Antti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/49c1b6c1/attachment.htm>

From colecmac at protonmail.com  Tue May 26 18:43:50 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 26 May 2020 17:43:50 +0000
Subject: [ANN] bollux, a bash gemini browser
In-Reply-To: <20200526172823.GE6603@SDF.ORG>
References: <20200525221828.67386af2@bax>
 <20200526172823.GE6603@SDF.ORG>
Message-ID: <BIQhTUOec_xU83emFDZLdM7z3tpYl_7mmYIKnausoA_tZDcb3QlM45FanHACDlEt2CeLvf-IWKgT2z94PBkYuJszYRgQaIjW2wF9wGhlOeQ=@protonmail.com>

I can confirm this, it seems like a known issue actually:

https://todo.sr.ht/~acdw/bollux/1


makeworld

??????? Original Message ???????
On Tuesday, May 26, 2020 1:28 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> Howdy,
>
> I clone the repo but when I try to use it:
>
> zaibatsu$ ./bollux
> GO> gemini.circumlunar.space
> bollux: []
> bollux:
> ./bollux: line 38: exit: 100 Unknown response code: .: numeric argument required
> zaibatsu$
>
> Am I doing it wrong?
>
> Cheers,
> Solderpunk
>
> On Mon, May 25, 2020 at 10:18:28PM -0500, Case Duckworth wrote:
>
> > Well, it took me a little longer than a weekend but I got it done!
> > I'm proud to announce the release of bollux, a Gemini browser written
> > in bash:
> > https://git.sr.ht/~acdw/bollux
> > gemini://gemini.circumlunar.space/~acdw/bollux (just the README)
> > It requires stuff most Linux users should have, like gawk
> > (possibly could use awk), dd, a recent version of bash, etc.
> > As of this release, bollux can
> >
> > -   navigate to gemini urls
> > -   display text/* documents, and prettify text/gemini ones
> > -   download other mimetypes
> >
> > I still want to implement history, bookmarks, and the other
> > ease-of-life improvements that make a browser worth using. But I also
> > really wanted to send a [ANN] email tonight, so here we are.
> > Let me know what you think!
> > --
> > Best,
> > Case
> > acdw.net | breadpunk.club
> > he/him



From solderpunk at SDF.ORG  Tue May 26 18:45:06 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:45:06 +0000
Subject: [ANN] gemlikes - A liking and comment system for Gemini
In-Reply-To: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>
References: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>
Message-ID: <20200526174506.GF6603@SDF.ORG>

On Mon, May 25, 2020 at 11:39:07PM +0000, colecmac at protonmail.com wrote:
 
> Like many of us, I've really enjoyed reading and taking in people's
> gemlogs on Geminispace. But I often want to reply to what people have
> written, to ask a question, let them know I enjoyed it etc. I created
> gemlikes to be able to do that.

Thanks for sharing your project!

Somewhat like I said in my earlier post responding to the announcement
of Geddit, it will be really interesting to see whether or not this kind
of thing takes root in Geminispace, where it's comparatively difficult
(compared to the web) to control spam without making the user jump
through hoops (nobody is going to want to generate a client certificate
for each gemlog they might want to comment on).

Commenting is very rare in Gopherspace, although it is possible and you
occassionally see it.  By convention people respond either by just
emailing the author or by writing a response post of their own.  I have
read many people say that they really like this, because it encourages a
more carefully thought out and long form response than a comment.  Of
course, this second option (writing a response) only really works
because Gopherspace is small enough that there is a high likelihood of
the original poster finding your response.  It works well within small
communities, but does not scale.  Since Gemini does a very good job of
addressing just about all of the small irritations that people tend to
notice in Gopher, I am kind of hoping that it grows to be larger than
Gopherspace, and as such this cherished norm might break down.

In my experience the email thing works well, and lends Gopherspace a
very personal feel, which I enjoy.  That, too, might break down if email
address harvesting robots penetrate Geminispace in the future and people
don't want to put their address on their "about" page.

Who knows how things will pan out here.  I'd be kind of sad to see the
rise of a third-party Disqus-style solution here in Geminispace, but of
course I'm powerless to stop it.

Sorry if I sound down on all these cool new commenting and link-sharing
projects, I don't mean to me!  I'm really happy to see people pouring
energy and into Geminispace projects.  I'm just really curious to see
how all of this pans out in the longer term.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 26 18:47:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:47:21 +0000
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <20200526174104.qmxz7cpudpog4sgt@haukka.localdomain>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
 <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>
 <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>
 <20200526170555.GB6603@SDF.ORG>
 <20200526174104.qmxz7cpudpog4sgt@haukka.localdomain>
Message-ID: <20200526174721.GG6603@SDF.ORG>

On Tue, May 26, 2020 at 08:41:04PM +0300, Antti Ker?nen wrote:
 
> I was running commit a68e092593fa2999a81edd7a7e111e52076d5922
> 
> Sadly I cannot test it again with the latest master branch as Hannu
> fixed his server already. :)

Huh, that should definitely have picked up mismatching hostname issue.

Unless Bombadillo only checks the Common Name and not Subject
Alternative Names?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 26 18:59:08 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 17:59:08 +0000
Subject: Gateway Interfaces for Gemini
In-Reply-To: <20200525231103.GO23998@brevard.conman.org>
References: <20200525231103.GO23998@brevard.conman.org>
Message-ID: <20200526175908.GH6603@SDF.ORG>

On Mon, May 25, 2020 at 07:11:04PM -0400, Sean Conner wrote:

> [b]	Mandatory per RFC-3875---the more security conscience of you might
> 	not like this, but in that case, I can recommend the value of
> 	"127.0.0.1" or "::1" 
> [c]	Can be the IP address, which is what I do

It's true that, as I've written in the past, I really am not a fan of
this information being passed along for privacy reasons.  Yes, of
course, I know full well that the server itself already knows your IP
address, by necessity.  I am totally fine with admins logging that
information for the sake of debugging or abuse prevention.

But I just don't see the need to pass this information along to
applications.  What possible legitimate use could they have for it?  If
they want to recognise consecutive requests from the same user so they
can maintain state server side, well, that's what client certificates
are for.  The application can request one, instead of relying on the IP
address, which won't work well anyway if somebody is using a popular VPN
exit node.  The only other thing I can think of which is potentially
even vaguely legimiate is geolocation so the app can e.g. serve a
suitable translated interface.  But even that's iffy in my mind because
geolocation is so terribly unreliable in this day and age because so
many people habitually use VPNs and may not be where they appear to be.

I know this field is mandatory in RFC-3875 - what is the scope of that
RFC with respect to protocols?  Does it only talk about HTTP or is it
supposed to be more general?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 26 19:07:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 18:07:28 +0000
Subject: humble suggestions to specs documentation
In-Reply-To: <20200525163357.GA4823@kurosawa.casa.net>
References: <20200525163357.GA4823@kurosawa.casa.net>
Message-ID: <20200526180728.GI6603@SDF.ORG>

On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote:
> Hi!

Howdy!

> I  find  gemini very  exciting,  bringing  back  some fun  in  network
> programming!

Happy to hear it! :)

> 1.3.1
> 
> Gemini response headers look like this:
> 
> <STATUS> <META><CR><LF>
> 
> [...]
> 
> In my opinion the space character between <STATUS> and <META> could be
> a symbol not the character itself something like:
> 
> <STATUS><SPACE><META><CR><LF>
> 
> this  way it  is much  more difficult  that the  reader could  miss or
> misunderstand the single space in the response line.

This makes sense, I will make the change.
 
> I think would be a good idea to include some code snippets (maybe in C
> with libssl?) to illustrate how to do server validation or make client
> certificate.
> 
> I the code was  too long could be added in an  appendix or some code
> form an existing implementation can be linked, i do know.

I think code examples are beyond the scope of a specification, and would
be far too long if we tried to provide good coverage.  But I've thought
for a while now some kind of "implementer's guide" as a separate
document would be a good idea.  Specifically, it would be nice to have
code in many languages / libraries for setting up TLS 1.2 to use only
the more secure cipher suites.

> I think there is a minor typo in the FAQ:
> 
> ### 1.3 Where can I learn more?
> 
> [...]
> 
> Official discussion regarding Gemini hapens on a mailing list.
> 
> [...]
> 

Fixed!

> Bye and thank you for gemini!

Thanks for taking the time to make these suggests.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue May 26 19:19:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 18:19:28 +0000
Subject: Query Strings
In-Reply-To: <mIbgwewiglbTQqJYunYyMOQFiCilcI_l9Tqj9ppnd1kgPj2d5G4ZfBFB3WhmHa9Dd306-up127xthOxhyPFmzF1dIFQ_d7A1YmIs4ImxRdc=@protonmail.com>
References: <1141063286.117280.1590338036891@ichabod.co-bxl>
 <20200524212858.GK23998@brevard.conman.org>
 <mIbgwewiglbTQqJYunYyMOQFiCilcI_l9Tqj9ppnd1kgPj2d5G4ZfBFB3WhmHa9Dd306-up127xthOxhyPFmzF1dIFQ_d7A1YmIs4ImxRdc=@protonmail.com>
Message-ID: <20200526181928.GK6603@SDF.ORG>

On Mon, May 25, 2020 at 03:54:32PM +0000, colecmac at protonmail.com wrote:
> I think it might just make the most sense to say in the spec that
> encoding is required, and should be done with percent signs, for
> spaces too. Like in Sean's message:
> 
> ?query=what%20is%20this%20madness&lang=en

Yeah, I will do this, once I find the time to dig through the relevant
RFCs and make sure I can explain what should be done succinctly and
unambiguously using all the right terminology.

If this isn't done in like a week or so, somebody poke me!

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Tue May 26 19:21:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 18:21:35 +0000
Subject: Split the spec into two
In-Reply-To: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
References: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
Message-ID: <20200526182135.GL6603@SDF.ORG>

On Mon, May 25, 2020 at 01:54:55PM +0200, Felix Quei?ner wrote:
 
> I propose to split the specification into either two documents or a
> single document with a clear separation between text/gemini and the
> gemini protocol.

Yeah, this makes sense.  I hadn't really thought about it, but the
text/gemini spec is kind of smack bang in the middle of the other stuff.

I still think it's a good idea to have everything in one place, but some
rearrangement would not hurt.  I will try to do this tonight.

Cheers,
Solderpunk


From hannu.hartikainen+gemini at gmail.com  Tue May 26 19:59:16 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Tue, 26 May 2020 21:59:16 +0300
Subject: [ANN] personal Gemini space and twinlog
In-Reply-To: <20200526174721.GG6603@SDF.ORG>
References: <CANmFPenPZx6zRpsWDDudA6wpWBVi1kOnG7+Sj7QpZ4z314TMDg@mail.gmail.com>
 <Ma97UEy5Pghs9YkqvV74whD2SyGOXQ3jF8-fcwQA_cKGf4H1C8vEcXDlQp3bX1aw6zI8QE9nbJD4_yh8yFaCRb8mx53QjS4dkEIKai6f4Qg=@protonmail.com>
 <20200526154708.w3a52x2nz5mur25s@haukka.localdomain>
 <20200526170555.GB6603@SDF.ORG>
 <20200526174104.qmxz7cpudpog4sgt@haukka.localdomain>
 <20200526174721.GG6603@SDF.ORG>
Message-ID: <CANmFPekJJ0iwu-D+K4WtARdZxPpHnSwSJmwZ-gHy1UHce8DufA@mail.gmail.com>

On Tue, 26 May 2020 at 20:04, solderpunk <solderpunk at sdf.org> wrote:

> But, hey, please be very careful about posting stuff in Geminispace that
> you would not be comfortable posting to the web because you are worried
> about possible real-world consequences.
>

That's a good thing to point out. I think picking someone's words out of
context years later and tearing them apart is inhumane. So that's why I'm
worried and write about it. Not because I think I'm more at risk than any
random person.

On Tue, May 26, 2020, 20:47 solderpunk <solderpunk at sdf.org> wrote:

> On Tue, May 26, 2020 at 08:41:04PM +0300, Antti Ker?nen wrote:
>
> > I was running commit a68e092593fa2999a81edd7a7e111e52076d5922
> >
> > Sadly I cannot test it again with the latest master branch as Hannu
> > fixed his server already. :)
>
> Huh, that should definitely have picked up mismatching hostname issue.
>
> Unless Bombadillo only checks the Common Name and not Subject
> Alternative Names?
>

I'm pretty sure the previous cert only had CN=gemini.hannuhartikainen.fi,
no SANs. The command I used was probably `openssl req -x509 -newkey
rsa:4096 -days 3650 -nodes -out cert.pem -keyout key.pem`.

-- 
Hannu Hartikainen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/d67bc791/attachment.htm>

From jetkoten at gmail.com  Tue May 26 20:16:47 2020
From: jetkoten at gmail.com (=?UTF-8?B?4pyI5YCL5bGV?=)
Date: Tue, 26 May 2020 14:16:47 -0500
Subject: humble suggestions to specs documentation
In-Reply-To: <20200526180728.GI6603@SDF.ORG>
References: <20200525163357.GA4823@kurosawa.casa.net>
 <20200526180728.GI6603@SDF.ORG>
Message-ID: <CANW6ZfHkLD=qffqck+JgaP=tsjKbiX2Ofa1qd9-vzcbSjH5LRg@mail.gmail.com>

Would <SINGLE SPACE> be useful here? If I recall it had gone from any
whitespace to single whitespace? so that might make it unambiguous?

J

On Tue, May 26, 2020, 13:07 solderpunk <solderpunk at sdf.org> wrote:

> On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote:
> > Hi!
>
> Howdy!
>
> > I  find  gemini very  exciting,  bringing  back  some fun  in  network
> > programming!
>
> Happy to hear it! :)
>
> > 1.3.1
> >
> > Gemini response headers look like this:
> >
> > <STATUS> <META><CR><LF>
> >
> > [...]
> >
> > In my opinion the space character between <STATUS> and <META> could be
> > a symbol not the character itself something like:
> >
> > <STATUS><SPACE><META><CR><LF>
> >
> > this  way it  is much  more difficult  that the  reader could  miss or
> > misunderstand the single space in the response line.
>
> This makes sense, I will make the change.
>
> > I think would be a good idea to include some code snippets (maybe in C
> > with libssl?) to illustrate how to do server validation or make client
> > certificate.
> >
> > I the code was  too long could be added in an  appendix or some code
> > form an existing implementation can be linked, i do know.
>
> I think code examples are beyond the scope of a specification, and would
> be far too long if we tried to provide good coverage.  But I've thought
> for a while now some kind of "implementer's guide" as a separate
> document would be a good idea.  Specifically, it would be nice to have
> code in many languages / libraries for setting up TLS 1.2 to use only
> the more secure cipher suites.
>
> > I think there is a minor typo in the FAQ:
> >
> > ### 1.3 Where can I learn more?
> >
> > [...]
> >
> > Official discussion regarding Gemini hapens on a mailing list.
> >
> > [...]
> >
>
> Fixed!
>
> > Bye and thank you for gemini!
>
> Thanks for taking the time to make these suggests.
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/133da147/attachment-0001.htm>

From solderpunk at SDF.ORG  Tue May 26 20:19:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 19:19:28 +0000
Subject: humble suggestions to specs documentation
In-Reply-To: <CANW6ZfHkLD=qffqck+JgaP=tsjKbiX2Ofa1qd9-vzcbSjH5LRg@mail.gmail.com>
References: <20200525163357.GA4823@kurosawa.casa.net>
 <20200526180728.GI6603@SDF.ORG>
 <CANW6ZfHkLD=qffqck+JgaP=tsjKbiX2Ofa1qd9-vzcbSjH5LRg@mail.gmail.com>
Message-ID: <20200526191928.GP6603@SDF.ORG>

On Tue, May 26, 2020 at 02:16:47PM -0500, ??? wrote:
> Would <SINGLE SPACE> be useful here? If I recall it had gone from any
> whitespace to single whitespace? so that might make it unambiguous?
> 

It's disambiguated a few words further down:

"<STATUS> and <META> are separated by a single space character."

Cheers,
Solderpunk

> 
> On Tue, May 26, 2020, 13:07 solderpunk <solderpunk at sdf.org> wrote:
> 
> > On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote:
> > > Hi!
> >
> > Howdy!
> >
> > > I  find  gemini very  exciting,  bringing  back  some fun  in  network
> > > programming!
> >
> > Happy to hear it! :)
> >
> > > 1.3.1
> > >
> > > Gemini response headers look like this:
> > >
> > > <STATUS> <META><CR><LF>
> > >
> > > [...]
> > >
> > > In my opinion the space character between <STATUS> and <META> could be
> > > a symbol not the character itself something like:
> > >
> > > <STATUS><SPACE><META><CR><LF>
> > >
> > > this  way it  is much  more difficult  that the  reader could  miss or
> > > misunderstand the single space in the response line.
> >
> > This makes sense, I will make the change.
> >
> > > I think would be a good idea to include some code snippets (maybe in C
> > > with libssl?) to illustrate how to do server validation or make client
> > > certificate.
> > >
> > > I the code was  too long could be added in an  appendix or some code
> > > form an existing implementation can be linked, i do know.
> >
> > I think code examples are beyond the scope of a specification, and would
> > be far too long if we tried to provide good coverage.  But I've thought
> > for a while now some kind of "implementer's guide" as a separate
> > document would be a good idea.  Specifically, it would be nice to have
> > code in many languages / libraries for setting up TLS 1.2 to use only
> > the more secure cipher suites.
> >
> > > I think there is a minor typo in the FAQ:
> > >
> > > ### 1.3 Where can I learn more?
> > >
> > > [...]
> > >
> > > Official discussion regarding Gemini hapens on a mailing list.
> > >
> > > [...]
> > >
> >
> > Fixed!
> >
> > > Bye and thank you for gemini!
> >
> > Thanks for taking the time to make these suggests.
> >
> > Cheers,
> > Solderpunk
> >

From jetkoten at gmail.com  Tue May 26 20:22:46 2020
From: jetkoten at gmail.com (=?UTF-8?B?4pyI5YCL5bGV?=)
Date: Tue, 26 May 2020 14:22:46 -0500
Subject: humble suggestions to specs documentation
In-Reply-To: <20200526191928.GP6603@SDF.ORG>
References: <20200525163357.GA4823@kurosawa.casa.net>
 <20200526180728.GI6603@SDF.ORG>
 <CANW6ZfHkLD=qffqck+JgaP=tsjKbiX2Ofa1qd9-vzcbSjH5LRg@mail.gmail.com>
 <20200526191928.GP6603@SDF.ORG>
Message-ID: <CANW6ZfGv3RoQPXecKRLz2mW+TDiaiyvXZFJodxzhKQcMNhP-1w@mail.gmail.com>

Thanks, sorry I missed that from just following the email discussion.

J

On Tue, May 26, 2020, 14:19 solderpunk <solderpunk at sdf.org> wrote:

> On Tue, May 26, 2020 at 02:16:47PM -0500, ??? wrote:
> > Would <SINGLE SPACE> be useful here? If I recall it had gone from any
> > whitespace to single whitespace? so that might make it unambiguous?
> >
>
> It's disambiguated a few words further down:
>
> "<STATUS> and <META> are separated by a single space character."
>
> Cheers,
> Solderpunk
>
> >
> > On Tue, May 26, 2020, 13:07 solderpunk <solderpunk at sdf.org> wrote:
> >
> > > On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote:
> > > > Hi!
> > >
> > > Howdy!
> > >
> > > > I  find  gemini very  exciting,  bringing  back  some fun  in
> network
> > > > programming!
> > >
> > > Happy to hear it! :)
> > >
> > > > 1.3.1
> > > >
> > > > Gemini response headers look like this:
> > > >
> > > > <STATUS> <META><CR><LF>
> > > >
> > > > [...]
> > > >
> > > > In my opinion the space character between <STATUS> and <META> could
> be
> > > > a symbol not the character itself something like:
> > > >
> > > > <STATUS><SPACE><META><CR><LF>
> > > >
> > > > this  way it  is much  more difficult  that the  reader could  miss
> or
> > > > misunderstand the single space in the response line.
> > >
> > > This makes sense, I will make the change.
> > >
> > > > I think would be a good idea to include some code snippets (maybe in
> C
> > > > with libssl?) to illustrate how to do server validation or make
> client
> > > > certificate.
> > > >
> > > > I the code was  too long could be added in an  appendix or some code
> > > > form an existing implementation can be linked, i do know.
> > >
> > > I think code examples are beyond the scope of a specification, and
> would
> > > be far too long if we tried to provide good coverage.  But I've thought
> > > for a while now some kind of "implementer's guide" as a separate
> > > document would be a good idea.  Specifically, it would be nice to have
> > > code in many languages / libraries for setting up TLS 1.2 to use only
> > > the more secure cipher suites.
> > >
> > > > I think there is a minor typo in the FAQ:
> > > >
> > > > ### 1.3 Where can I learn more?
> > > >
> > > > [...]
> > > >
> > > > Official discussion regarding Gemini hapens on a mailing list.
> > > >
> > > > [...]
> > > >
> > >
> > > Fixed!
> > >
> > > > Bye and thank you for gemini!
> > >
> > > Thanks for taking the time to make these suggests.
> > >
> > > Cheers,
> > > Solderpunk
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200526/8b743be4/attachment.htm>

From cage-dev at twistfold.it  Tue May 26 20:25:04 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 26 May 2020 21:25:04 +0200
Subject: humble suggestions to specs documentation
In-Reply-To: <20200526180728.GI6603@SDF.ORG>
References: <20200525163357.GA4823@kurosawa.casa.net>
 <20200526180728.GI6603@SDF.ORG>
Message-ID: <20200526192504.GA7800@kurosawa.casa.net>

On Tue, May 26, 2020 at 06:07:28PM +0000, solderpunk wrote:

Hi solderpunk!

> >
> > I the code was  too long could be added in an  appendix or some code
> > form an existing implementation can be linked, i do know.
>
> I think code examples are beyond the scope of a specification, and would
> be far too long if we tried to provide good coverage.

That is a fair point. :)

> But I've thought
> for a while now some kind of "implementer's guide" as a separate
> document would be a good idea.

I think this is an excellent idea! :D

> Specifically, it would be nice to have
> code in many languages / libraries for setting up TLS 1.2 to use only
> the more secure cipher suites.

I am quite busy with another  project at the moment, but if interested
(and if i succeed) i could contribute showing some code in common lisp
in the future. I actually do not  know very well the current status of
TLS libraries in  this language but peraphs this could  be a chance to
improve the libraries too, who knows! :)

>
> Thanks for taking the time to make these suggests.

I am  happy i was able  to give a  contribute to this project  even if
(given my modest skills) just minimal! :)

Bye!
C.

From jmcbray at carcosa.net  Tue May 26 20:53:42 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 26 May 2020 15:53:42 -0400
Subject: [ANN] gemlikes - A liking and comment system for Gemini
In-Reply-To: <20200526174506.GF6603@SDF.ORG> (solderpunk@sdf.org's message of
 "Tue, 26 May 2020 17:45:06 +0000")
References: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>
 <20200526174506.GF6603@SDF.ORG>
Message-ID: <87ftbm79rt.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> On Mon, May 25, 2020 at 11:39:07PM +0000, colecmac at protonmail.com wrote:
>  
>> Like many of us, I've really enjoyed reading and taking in people's
>> gemlogs on Geminispace. But I often want to reply to what people have
>> written, to ask a question, let them know I enjoyed it etc. I created
>> gemlikes to be able to do that.
>
> Thanks for sharing your project!

Yes, thanks. I've been pondering myself what is the best way to
facilitate discussions that span more than one phlog/gemlog. Apologies
if I end up hijacking this thread to do it.

> Commenting is very rare in Gopherspace, although it is possible and you
> occassionally see it.  By convention people respond either by just
> emailing the author or by writing a response post of their own.  I have
> read many people say that they really like this, because it encourages a
> more carefully thought out and long form response than a comment.  Of
> course, this second option (writing a response) only really works
> because Gopherspace is small enough that there is a high likelihood of
> the original poster finding your response.

This does mostly work in gopherspace, but there have been times I wanted
to write a reply (on my own phlog), but felt balked because I felt like
they wouldn't see the reply unless I was listed on one of the two phlog
aggregators that most people use, and I wasn't.

> In my experience the email thing works well, and lends Gopherspace a
> very personal feel, which I enjoy.  That, too, might break down if email
> address harvesting robots penetrate Geminispace in the future and people
> don't want to put their address on their "about" page.

I should probably make my reply email more prominent on my gemlog posts.

But what I was thinking about was something more similar to
Pingbacks[1]. I'm not interested in comments on blogs; I'm more
interested in something like what we have going in gopher, but with a
system for notifying authors that they've been replied to on another
gemlog. It looks like the current specification for doing this kind of
thing on the web is Webmention[2], which comes from the indieweb
community. I haven't put in very much thought into how I actually want
it to work, but I probably need to start by reading the Webmention
documentation. 

[1]: https://en.wikipedia.org/wiki/Pingback
[2]: https://en.wikipedia.org/wiki/Webmention

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From felix at masterq32.de  Tue May 26 21:12:26 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 26 May 2020 22:12:26 +0200
Subject: Split the spec into two
In-Reply-To: <20200526182135.GL6603@SDF.ORG>
References: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
 <20200526182135.GL6603@SDF.ORG>
Message-ID: <a4cc96fa-1442-2f17-b520-f58dd2f0d7c6@masterq32.de>


> Yeah, this makes sense.  I hadn't really thought about it, but the
> text/gemini spec is kind of smack bang in the middle of the other stuff.
Yeah, it's not always obvious when working a long time on some stuff.
All relevant information is there, but there is stuff added and removed
and one misses the bigger picture sometimes.

> I still think it's a good idea to have everything in one place, but some
> rearrangement would not hurt.  I will try to do this tonight.
Nice, thanks!

Regards
- xq

From tkarpiniec at icloud.com  Tue May 26 21:19:34 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Wed, 27 May 2020 06:19:34 +1000
Subject: An unexpected favicon request
In-Reply-To: <20200526172329.GD6603@SDF.ORG>
References: <20200526040517.GA1478@allanon.local>
 <20200526082935.GP23998@brevard.conman.org>
 <20200526172329.GD6603@SDF.ORG>
Message-ID: <20200526201934.GA7209@allanon.local>

On Tue, May 26, 2020 at 05:23:29PM +0000, solderpunk wrote:
> Well, it's not really within the scope of the Gemini spec to explicitly
> forbid things like this.  If people want to write clients which do it,
> nobody can stop them.  If people want to do it, I strongly encourage
> them to make it an option the user can easily disabled.  Some people,
> myself included, hold the "one request per page" principle in very high
> regard, so I probably wouldn't add this to a client of mine, even if I
> had a graphical one where it made sense.

That's my attitude also. If someone wants to expend a TLS session for
a tiny picture then that's their business. :)

Thanks for the comments all. Clearly there is no consensus whatsoever
on how favicons work so there is no right or wrong. It's interesting
to hear about the special casing in GLV-1.12556.

Cheers,

Tom

From sean at conman.org  Tue May 26 21:48:12 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 26 May 2020 16:48:12 -0400
Subject: An unexpected favicon request
In-Reply-To: <20200526201934.GA7209@allanon.local>
References: <20200526040517.GA1478@allanon.local>
 <20200526082935.GP23998@brevard.conman.org> <20200526172329.GD6603@SDF.ORG>
 <20200526201934.GA7209@allanon.local>
Message-ID: <20200526204812.GQ23998@brevard.conman.org>

It was thus said that the Great Thomas Karpiniec once stated:
> Thanks for the comments all. Clearly there is no consensus whatsoever
> on how favicons work so there is no right or wrong. It's interesting
> to hear about the special casing in GLV-1.12556.

  It's not that special of a special case.  I just added the feature to
serve up a single page:

	handlers =
	{
	  {
	    path   = "^/motd$",
	    module = "GLV-1.handlers.file",
	    file   = "/etc/motd"
	  },
	  ...
	}

  In the above example, it's for serving up a page that might not live in
a directory with the rest of the content.  The "path" defines the path
portion of the URL to be matched, so for the favicon.ico, all I had to do
was:

	handlers =
	{
	  {
	    path   = "^/.*favicon.ico$",
	    module = "GLV-1.handlers.file",
	    file   = "/path/to/favicon.ico"
	  },
	  ...
	}

and made sure this was the first path checked.

  -spc

From solderpunk at SDF.ORG  Tue May 26 21:55:18 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 20:55:18 +0000
Subject: Split the spec into two
In-Reply-To: <a4cc96fa-1442-2f17-b520-f58dd2f0d7c6@masterq32.de>
References: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
 <20200526182135.GL6603@SDF.ORG>
 <a4cc96fa-1442-2f17-b520-f58dd2f0d7c6@masterq32.de>
Message-ID: <20200526205518.GQ6603@SDF.ORG>

On Tue, May 26, 2020 at 10:12:26PM +0200, Felix Quei?ner wrote:
 
> > I still think it's a good idea to have everything in one place, but some
> > rearrangement would not hurt.  I will try to do this tonight.
> Nice, thanks!

I just made this change, moving the definition of text/gemini into its
own section at the end of the spec (but before the appendix listing all
status codes), so that all of the protocol stuff is contiguous.

While I was at it, I fixed the ridiculous section numbering scheme.
Literally everything was a subsection of a single top-level section!
Talk about nuts.  So most things that were 1.x.y.z became just x.y.z.
All the text/gemini stuff got moved to its own dedicated section 5, so
the deepest level of nesting is also now one level less than it was
before.

This is a big overall improvement in readability and citeability.
Thanks a lot for suggesting it.

Cheers,
Solderpunk

From sean at conman.org  Tue May 26 22:02:01 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 26 May 2020 17:02:01 -0400
Subject: [ANN] gemlikes - A liking and comment system for Gemini
In-Reply-To: <87ftbm79rt.fsf@dorothy.carcosa.net>
References: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>
 <20200526174506.GF6603@SDF.ORG> <87ftbm79rt.fsf@dorothy.carcosa.net>
Message-ID: <20200526210201.GR23998@brevard.conman.org>

It was thus said that the Great Jason McBrayer once stated:
> 
> But what I was thinking about was something more similar to
> Pingbacks[1]. I'm not interested in comments on blogs; I'm more
> interested in something like what we have going in gopher, but with a
> system for notifying authors that they've been replied to on another
> gemlog. It looks like the current specification for doing this kind of
> thing on the web is Webmention[2], which comes from the indieweb
> community. I haven't put in very much thought into how I actually want
> it to work, but I probably need to start by reading the Webmention
> documentation. 

  Both Pingback and Webmention use the <link> tag in HTML or a custom HTTP
header to indicate an endpoint to send a notification to.  It will be
interesting to see how you would work around the lack of such things in
Gemini.

  -spc

> [1]: https://en.wikipedia.org/wiki/Pingback
> [2]: https://en.wikipedia.org/wiki/Webmention


From solderpunk at SDF.ORG  Tue May 26 22:14:41 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 21:14:41 +0000
Subject: [ANN] gemlikes - A liking and comment system for Gemini
In-Reply-To: <20200526210201.GR23998@brevard.conman.org>
References: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>
 <20200526174506.GF6603@SDF.ORG>
 <87ftbm79rt.fsf@dorothy.carcosa.net>
 <20200526210201.GR23998@brevard.conman.org>
Message-ID: <20200526211441.GS6603@SDF.ORG>

On Tue, May 26, 2020 at 05:02:01PM -0400, Sean Conner wrote:
 
>   Both Pingback and Webmention use the <link> tag in HTML or a custom HTTP
> header to indicate an endpoint to send a notification to.  It will be
> interesting to see how you would work around the lack of such things in
> Gemini.

Some kind of well-known endpoint convention comes to mind as the obvious
solution, although since this would need to be relative to the entire
domain name it wouldn't necessarily work well in a multi-user
environment...

Cheers,
Solderpunk

From natpen at natpen.net  Tue May 26 22:18:34 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Tue, 26 May 2020 17:18:34 -0400
Subject: Split the spec into two
In-Reply-To: <20200526205518.GQ6603@SDF.ORG>
References: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
 <20200526182135.GL6603@SDF.ORG>
 <a4cc96fa-1442-2f17-b520-f58dd2f0d7c6@masterq32.de>
 <20200526205518.GQ6603@SDF.ORG>
Message-ID: <20200526211834.GA1344@goldfish.localdomain>

> This is a big overall improvement in readability and citeability.
> Thanks a lot for suggesting it.

This IS a big improvement!

A small additional idea - would you be open to hosting a `text/gemini`
version? I can definitely see the merit of the `text/plain` version,
for maximum ease of distribution, so maybe this is just asking for
trouble to host two versions, but I do feel at this point in Gemini,
most folks are probably consuming the Gemini spec in a Gemini browser,
within which readability would be substantially enhanced by even just
the addition of a bit of the usual client header line handling (would
you look at that, Gemini supports three levels of it, and now we only
*have* three levels of it in the spec :).

From sean at conman.org  Tue May 26 22:17:44 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 26 May 2020 17:17:44 -0400
Subject: Gateway Interfaces for Gemini
In-Reply-To: <20200526175908.GH6603@SDF.ORG>
References: <20200525231103.GO23998@brevard.conman.org>
 <20200526175908.GH6603@SDF.ORG>
Message-ID: <20200526211744.GS23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Mon, May 25, 2020 at 07:11:04PM -0400, Sean Conner wrote:
> 
> > [b]	Mandatory per RFC-3875---the more security conscience of you might
> > 	not like this, but in that case, I can recommend the value of
> > 	"127.0.0.1" or "::1" 
> > [c]	Can be the IP address, which is what I do
> 
> I know this field is mandatory in RFC-3875 - what is the scope of that
> RFC with respect to protocols?  Does it only talk about HTTP or is it
> supposed to be more general?

  First paragraph of the abstract of RFC-3875:

	The Common Gateway Interface (CGI) is a simple interface for running
	external programs, software or gateways under an information server
	in a platform-independent manner.  Currently, the supported
	information servers are HTTP servers.

so it's clearly HTTP biased, but it also states in 4.1.18:

	The server SHOULD set meta-variables specific to the protocol and
	scheme for the request.  Interpretation of protocol-specific
	variables depends on the protocol version in SERVER_PROTOCOL.  The
	server MAY set a meta-variable with the name of the scheme to a
	non-NULL value if the scheme is not the same as the protocol.  The
	presence of such a variable indicates to a script which scheme is
	used by the request.

which to me reads that it may apply to other protocols, like Gemini (or even
gopher).  From RFC-3875:

	4.1.8.  REMOTE_ADDR

		The REMOTE_ADDR variable MUST be set to the network address
		of the client sending the request to the server.

	4.1.9.  REMOTE_HOST

		The REMOTE_HOST variable contains the fully qualified domain
		name of the client sending the request to the server, if
		available, otherwise NULL. ...

		The server SHOULD set this variable.  If the hostname is not
		available for performance reasons or otherwise, the server
		MAY substitute the REMOTE_ADDR value.

thus mu recommendation for "127.0.0.1" or "::1".

  -spc

From solderpunk at SDF.ORG  Tue May 26 22:22:43 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 26 May 2020 21:22:43 +0000
Subject: Split the spec into two
In-Reply-To: <20200526211834.GA1344@goldfish.localdomain>
References: <76e13c62-2580-488e-12e1-f349740f7188@masterq32.de>
 <20200526182135.GL6603@SDF.ORG>
 <a4cc96fa-1442-2f17-b520-f58dd2f0d7c6@masterq32.de>
 <20200526205518.GQ6603@SDF.ORG>
 <20200526211834.GA1344@goldfish.localdomain>
Message-ID: <20200526212243.GT6603@SDF.ORG>

On Tue, May 26, 2020 at 05:18:34PM -0400, Natalie Pendragon wrote:
 
> A small additional idea - would you be open to hosting a `text/gemini`
> version? I can definitely see the merit of the `text/plain` version,
> for maximum ease of distribution, so maybe this is just asking for
> trouble to host two versions, but I do feel at this point in Gemini,
> most folks are probably consuming the Gemini spec in a Gemini browser,
> within which readability would be substantially enhanced by even just
> the addition of a bit of the usual client header line handling (would
> you look at that, Gemini supports three levels of it, and now we only
> *have* three levels of it in the spec :).

Yes, I'd like to do this!  I've been meaning to write some quick little
scripts to convert text/gemini to text/plain (mostly just a matter of
wrapping to 80 columns) and to text/html, so I can move to maintaining
the spec, FAQ, etc. in text/gemini and automate the mirroring to Gopher
and HTTPS.  It will happen one day! :)

Cheers,
Solderpunk

PS: Or has somebody already written these tools?

From colecmac at protonmail.com  Tue May 26 23:14:51 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 26 May 2020 22:14:51 +0000
Subject: [ANN] gemlikes - A liking and comment system for Gemini
In-Reply-To: <87ftbm79rt.fsf@dorothy.carcosa.net>
References: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>
 <20200526174506.GF6603@SDF.ORG>
 <87ftbm79rt.fsf@dorothy.carcosa.net>
Message-ID: <cCIBOmjltnmSqf6z03IAQUICJuRHTKfocQQY3TYwvEbX5RI2KJWFkFRlOP7MT9VL85iB-g_oxGGne6W2WVwHb63-obNh8A992yeGsPeG5AI=@protonmail.com>

> there have been times I wanted
> to write a reply (on my own phlog), but felt balked because I felt like
> they wouldn't see the reply unless I was listed on one of the two phlog
> aggregators that most people use, and I wasn't.

I was thinking about this earlier, and the simplest solution might just be
to leave a comment that's just a link to your post. But obviously that
requires comments to already be a thing on their gemlog.

Some sort of webmention-type system would be cool, but only if it means
we can all see the webmentions, and it doesn't end up being a private message
to the author. Also, I worry about the complication of developing a whole
other mentioning protocol, since at first glance the existing systems don't
seem very transferable. I'd be happy to be wrong about that though.

makeworld

From colecmac at protonmail.com  Tue May 26 23:18:49 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 26 May 2020 22:18:49 +0000
Subject: Gateway Interfaces for Gemini
In-Reply-To: <20200526175908.GH6603@SDF.ORG>
References: <20200525231103.GO23998@brevard.conman.org>
 <20200526175908.GH6603@SDF.ORG>
Message-ID: <PXZTSlrKtOlYrl8Bf7u36K6K7PVaGKYTmtZFQIcJiZIRfs20FLe_QdF9DW-gQqOaqqb89GQrw7jpIrhmI_SBE8_k1izSEblAvK3U8mN5w4M=@protonmail.com>

> But I just don't see the need to pass this information along to
> applications. What possible legitimate use could they have for it?

I use it for gemlikes, because it's just a really simple way to prevent
spam without having to complicate things with client certs. Client
certs are great, but as you said, it would be a huge hassle to have
to do it for each site.

I providing the IP address is fine, and applications can use it if they
want. Trying to restrict apps from accessing it will give people a false
sense of security, I think.

makeworld

??????? Original Message ???????
On Tuesday, May 26, 2020 1:59 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Mon, May 25, 2020 at 07:11:04PM -0400, Sean Conner wrote:
>
> > [b] Mandatory per RFC-3875---the more security conscience of you might
> > not like this, but in that case, I can recommend the value of
> > "127.0.0.1" or "::1"
> > [c] Can be the IP address, which is what I do
>
> It's true that, as I've written in the past, I really am not a fan of
> this information being passed along for privacy reasons. Yes, of
> course, I know full well that the server itself already knows your IP
> address, by necessity. I am totally fine with admins logging that
> information for the sake of debugging or abuse prevention.
>
> But I just don't see the need to pass this information along to
> applications. What possible legitimate use could they have for it? If
> they want to recognise consecutive requests from the same user so they
> can maintain state server side, well, that's what client certificates
> are for. The application can request one, instead of relying on the IP
> address, which won't work well anyway if somebody is using a popular VPN
> exit node. The only other thing I can think of which is potentially
> even vaguely legimiate is geolocation so the app can e.g. serve a
> suitable translated interface. But even that's iffy in my mind because
> geolocation is so terribly unreliable in this day and age because so
> many people habitually use VPNs and may not be where they appear to be.
>
> I know this field is mandatory in RFC-3875 - what is the scope of that
> RFC with respect to protocols? Does it only talk about HTTP or is it
> supposed to be more general?
>
> Cheers,
> Solderpunk



From acdw at acdw.net  Wed May 27 01:50:34 2020
From: acdw at acdw.net (Case Duckworth)
Date: Wed, 27 May 2020 00:50:34 +0000
Subject: [ANN] bollux, a bash gemini browser
In-Reply-To: <20200525221828.67386af2@bax>
References: <20200525221828.67386af2@bax>
Message-ID: <184e3048-df05-410f-934f-0a62267aef71@www.fastmail.com>

Hey geminauts,

I was able to fix bollux this evening with possibly the smallest diff
ever. I changed a '/' to ':'.

Anyway, I'm definitely going to test my software before I release it
from now on. So try it, let me know what you think!

(I wrote a post about it on my nilog as well:
=> gemini://gemini.circumlunar.space/users/acdw/2020-05-22.gmi

--
acdw

On Tue, May 26, 2020, at 3:18 AM, Case Duckworth wrote:
> Well, it took me a little longer than a weekend but I got it done!
> 
> I'm proud to announce the release of *bollux*, a Gemini browser written
> in bash:
> 
> https://git.sr.ht/~acdw/bollux
> gemini://gemini.circumlunar.space/~acdw/bollux (just the README)
> 
> It requires stuff most Linux users should have, like gawk
> (possibly could use awk), dd, a recent version of bash, etc.
> 
> As of this release, bollux can
> - navigate to gemini urls
> - display text/* documents, and prettify text/gemini ones
> - download other mimetypes
> 
> I still want to implement history, bookmarks, and the other
> ease-of-life improvements that make a browser worth using. But I also
> really wanted to send a [ANN] email tonight, so here we are.
> 
> Let me know what you think!
> 
> -- 
> Best,
> Case
> acdw.net | breadpunk.club
> he/him
>

From meff at meff.me  Wed May 27 03:34:47 2020
From: meff at meff.me (Meff)
Date: Tue, 26 May 2020 19:34:47 -0700
Subject: [ANN] Darwaza - An extensible Tcl/Tk Graphical Browser
Message-ID: <3d4baa01-18a6-dab0-5f80-59c22e663907@meff.me>

Hey all,

I wanted to create a lightweight graphical client that allows the user 
to have maximum flexibility, a la modifying a Lisp system. To that 
regard, I am working on Darwaza (https://github.com/Koshroy/darwaza), a 
graphical Tcl/Tk browser. Right now, the client looks and feels a lot 
like McRoss, with some differences in presentation.

To install, clone the repo, then mark "main.tcl" as executable, and run it!

Some of the groundwork has been laid for making Darwaza extensible. The 
plan is to allow the user to hook into every part of the renderer to 
have control over how to display pages, but also have a simple interface 
to allow users a simple interface to change colors, font sizes, and 
other such things.

Darwaza is still fairly raw, but can already navigate around Gemini space.

Upcoming is:
* Async request support
* A refactor of the renderer
* An option to spawn an interpreter on the live-running Darwaza instance 
for live modification

Thanks,
meff

From jmcbray at carcosa.net  Wed May 27 16:27:34 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 27 May 2020 11:27:34 -0400
Subject: [ANN] gemlikes - A liking and comment system for Gemini
In-Reply-To: <20200526211441.GS6603@SDF.ORG> (solderpunk@sdf.org's message of
 "Tue, 26 May 2020 21:14:41 +0000")
References: <V_JYxHJ1fXT0cGj_Dbw5EejWcID_95ufiTv7pA8IOn583Uo_6NN_SMMEExK0GYdKdK-sp5jKGlADXCXE2-4XRqRTIeNCfLs6Js8-f-DFs_8=@protonmail.com>
 <20200526174506.GF6603@SDF.ORG> <87ftbm79rt.fsf@dorothy.carcosa.net>
 <20200526210201.GR23998@brevard.conman.org> <20200526211441.GS6603@SDF.ORG>
Message-ID: <87blm975zt.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> On Tue, May 26, 2020 at 05:02:01PM -0400, Sean Conner wrote:
>  
>>   Both Pingback and Webmention use the <link> tag in HTML or a custom HTTP
>> header to indicate an endpoint to send a notification to.  It will be
>> interesting to see how you would work around the lack of such things in
>> Gemini.
>
> Some kind of well-known endpoint convention comes to mind as the obvious
> solution, although since this would need to be relative to the entire
> domain name it wouldn't necessarily work well in a multi-user
> environment...

Yeah, my plan was a well-known endpoint. It might be reasonable in a
multi-user environment for everyone to have to rely on a site-wide
Gemmention script.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From solderpunk at SDF.ORG  Wed May 27 17:42:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 27 May 2020 16:42:54 +0000
Subject: Client certificate musings
In-Reply-To: <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
Message-ID: <20200527164254.GA8751@SDF.ORG>

On Sun, May 24, 2020 at 11:22:48PM +0100, Martin Keegan wrote:
> On Sat, 23 May 2020, solderpunk wrote:
 
> I appreciate that under the current dispensation, the distribution of
> certificates or certificate-signing-requests is out-of-band, but in my use
> case, it's not clear to me how I'd go about implementing this. I'd
> have thought something like:
> 
> C: connect to S, without presenting a client cert and request /path/file
> S: 62 you need to present an authorised client cert; closes connection
> 
> C: reconnect to S, presenting appropriate client cert, request /path/file
> S: 20 text/gemini [data follows]; closes connection

This is exactly the intended workflow, and is now supported somewhat
smoothly in AV-98.  Here is an example session.  For the sake of making
it clear what is happening, I have `set debug true` but deleted most of
the debugging output, leaving only what is necessarily to make it clear
what is happening here:

AV-98> go gemini://gemini.conman.org/conman-labs-private/
[DEBUG] Response header: 62 Authorized Certicate Required.
The site gemini.conman.org is requesting a client certificate.
This will allow the site to recognise you across requests.
What do you want to do?
1. Give up.
2. Generate new certificate and retry the request.
3. Load previously generated certificate from file.
4. Load certificate from file and retry the request.
> 2
What do you want to name this new certificate?
Answering `mycert` will create `~/.av98/certs/mycert.crt` and
`~/.av98/certs/mycert.key`
conman
Generating a RSA private key
..............+++++
.........................................+++++
writing new private key to '/home/solderpunk/.av98/client_certs/conman.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:Let me in!
Email Address []:.
[DEBUG] Sending gemini://gemini.conman.org/conman-labs-private/<CRLF>
[DEBUG] Response header: 63 Certificate Not Accepted.
The server did not accept your certificate.
You may need to e.g. coordinate with the admin to get your certificate
fingerprint whitelisted.
What do you want to do?
1. Give up.
2. Generate new certificate and retry the request.
3. Load previously generated certificate from file.
4. Load certificate from file and retry the request.
> 1

> However, it's my possibly mistaken understanding that an SSL client will not
> present a cert to the server unless the server sends the CertificateRequest
> message first. Since the server doesn't know whether the client is going to
> ask for a restricted resource, it won't request a client cert. This seems to
> lead to a chicken-and-egg problem: to get access to the resource, the client
> must present its cert; to present the cert, the client must be asked to do
> so by the server; but the server doesn't know it should ask for the
> certificate before the client has said which resource it wants to access.

Hmm.  Either you are mistaken, or you're correct but all the servers
I've tested this against thus far (admittedly not many!) request a
client cert unconditionally and don't complain when one is not provided.
If you're right, I guess we need to spec this behaviour as required.

> Anyway, I think the ergonomics and patterns around how certificate signing
> requests get moved around are going to be a bigger problem.

I have to admit that I don't see a lot of point in using CSRs in this
context.  The whole point of a signed certificate is so that party A can
prove to anybody who trusts party B that party B verified they are
really party A.  The certificate is for the benefit of third parties.
If you are running a Gemini server and you want to use client certificates to
restrict access to certain people, there is no third party in the
picture.  So why not just remember the fingerprint of certificates you've
verified as belong to people you want to grant access to?  That way nobody
has to send you a CSR and you don't have to send back a signed certificate.
In a two-party scenario all that just seems like pointless busy work to
me.  Am I missing something?

Cheers,
Solderpunk

From martin at no.ucant.org  Wed May 27 19:37:02 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Wed, 27 May 2020 19:37:02 +0100 (BST)
Subject: Client certificate musings
In-Reply-To: <20200527164254.GA8751@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
 <20200527164254.GA8751@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>

On Wed, 27 May 2020, solderpunk wrote:

>> must present its cert; to present the cert, the client must be asked to do
>> so by the server; but the server doesn't know it should ask for the
>> certificate before the client has said which resource it wants to access.
>
> Hmm.  Either you are mistaken, or you're correct but all the servers
> I've tested this against thus far (admittedly not many!) request a
> client cert unconditionally and don't complain when one is not provided.
> If you're right, I guess we need to spec this behaviour as required.

Thanks for taking the time to spell this out. I was largely mistaken, as 
far as I can tell from my own attempts to add client certs to my server 
implementation. I think what's going on is that since I last seriously 
looked into this circa 2001, client UIs now behave better when servers 
request a client cert without making it mandatory.

>> Anyway, I think the ergonomics and patterns around how certificate signing
>> requests get moved around are going to be a bigger problem.
>
> I have to admit that I don't see a lot of point in using CSRs in this
> context.  The whole point of a signed certificate is so that party A can

Well, they are a potential implementation of the step you referred to as
"You may need to e.g. coordinate with the admin to get your certificate"

In my proposed pattern, the server trusts any cert which has been signed 
by some CA run by the server operator. The coordination with the admin to 
get such a cert is done via normal CSRs.

I'd recommend having a look at how Scuttlebutt does its analogous step: 
"invite codes". See, e..g.,

https://github.com/ssbc/ssb-server/wiki/pub-servers
https://ssbc.github.io/scuttlebutt-protocol-guide/ (invite codes section)
https://handbook.scuttlebutt.nz/guides/pubs/create-an-invite

... which suggests that a layer on top of CSRs may also be useful. Anyway, 
best way to find out is to try it.

> really party A.  The certificate is for the benefit of third parties.
> If you are running a Gemini server and you want to use client certificates to
> restrict access to certain people, there is no third party in the
> picture.  So why not just remember the fingerprint of certificates you've
> verified as belong to people you want to grant access to?  That way nobody
> has to send you a CSR and you don't have to send back a signed certificate.
> In a two-party scenario all that just seems like pointless busy work to
> me.  Am I missing something?

Well, in the two party scenario, sending a CSR and sending a fingerprint 
seem to be pretty similar: the user's software submits the mystic runes 
to openssl and the result is pasted to the other party. In the CSR route, 
however, you do indeed need to save the other party's response (the cert).

I would say that the CSR mechanism goes with the grain of how SSL is 
conventionally used, and thus is likely to have better 
existinglibrary/docs support.

My server sets $REMOTE_USER to the client cert's "Common Name" field, 
which is probably not what other people are doing, but which I think is 
more in the spirit of Gemini. If I get time I'll write up what the current 
practices of the other server software are.

Mk


-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From solderpunk at SDF.ORG  Wed May 27 19:58:07 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 27 May 2020 18:58:07 +0000
Subject: Client certificate musings
In-Reply-To: <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
 <20200527164254.GA8751@SDF.ORG>
 <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>
Message-ID: <20200527185807.GA21489@SDF.ORG>

On Wed, May 27, 2020 at 07:37:02PM +0100, Martin Keegan wrote:
 
> I'd recommend having a look at how Scuttlebutt does its analogous step:
> "invite codes". See, e..g.,
> 
> https://github.com/ssbc/ssb-server/wiki/pub-servers
> https://ssbc.github.io/scuttlebutt-protocol-guide/ (invite codes section)
> https://handbook.scuttlebutt.nz/guides/pubs/create-an-invite
> 
> ... which suggests that a layer on top of CSRs may also be useful. Anyway,
> best way to find out is to try it.

Thanks, I will have a read!
 
> Well, in the two party scenario, sending a CSR and sending a fingerprint
> seem to be pretty similar: the user's software submits the mystic runes to
> openssl and the result is pasted to the other party. In the CSR route,
> however, you do indeed need to save the other party's response (the cert).

Sure, but in the fingerprint case the relevant runes just get sent as a
side-effect of an ordinary TLS transaction.
 
> I would say that the CSR mechanism goes with the grain of how SSL is
> conventionally used, and thus is likely to have better existinglibrary/docs
> support.

Ah, now *this* is definitely true.  At the start of this whole thing I
brushed off a lot of people's concerns about the complexity of TLS by
waving my hands and saying "there are library bindings to do this in
every language".  I did not realise that so many of those libraries
would be so totally unable to handle anything even the slightest bit
unconventional.  It bothers me a bit now that fully implementing so many
of the ideas that I thought would make TLS a little bit less of an
imposition, or a little bit less offensive to radical decentralists,
looks like it will be quite a pain in some cases.  I never would have
imagined it would be literally impossible for a server using Python's
standard `ssl` module to accept a self-signed client certificate!

Cheers,
Solderpunk

From petite.abeille at gmail.com  Wed May 27 22:07:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 27 May 2020 23:07:47 +0200
Subject: Client certificate musings
In-Reply-To: <20200527185807.GA21489@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
 <20200527164254.GA8751@SDF.ORG>
 <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>
 <20200527185807.GA21489@SDF.ORG>
Message-ID: <AB846192-8F0E-414F-BE74-DC58F6331B72@gmail.com>



> On May 27, 2020, at 20:58, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>  I never would have
> imagined it would be literally impossible for a server using Python's
> standard `ssl` module to accept a self-signed client certificate!

https://docs.python.org/3/library/ssl.html#ssl.CERT_REQUIRED

From solderpunk at SDF.ORG  Wed May 27 22:11:51 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 27 May 2020 21:11:51 +0000
Subject: Client certificate musings
In-Reply-To: <AB846192-8F0E-414F-BE74-DC58F6331B72@gmail.com>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
 <20200527164254.GA8751@SDF.ORG>
 <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>
 <20200527185807.GA21489@SDF.ORG>
 <AB846192-8F0E-414F-BE74-DC58F6331B72@gmail.com>
Message-ID: <20200527211151.GC21489@SDF.ORG>

On Wed, May 27, 2020 at 11:07:47PM +0200, Petite Abeille wrote:
> > On May 27, 2020, at 20:58, solderpunk <solderpunk at SDF.ORG> wrote:
> > 
> >  I never would have
> > imagined it would be literally impossible for a server using Python's
> > standard `ssl` module to accept a self-signed client certificate!
> 
> https://docs.python.org/3/library/ssl.html#ssl.CERT_REQUIRED

Yes, precisely:

> With server socket, this mode provides mandatory TLS client cert
> authentication. A client certificate request is sent to the client and
> the client must provide a valid and trusted certificate.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Wed May 27 22:13:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 27 May 2020 23:13:09 +0200
Subject: Client certificate musings
In-Reply-To: <20200527211151.GC21489@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
 <20200527164254.GA8751@SDF.ORG>
 <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>
 <20200527185807.GA21489@SDF.ORG>
 <AB846192-8F0E-414F-BE74-DC58F6331B72@gmail.com>
 <20200527211151.GC21489@SDF.ORG>
Message-ID: <53E5F0E0-5840-46A3-932A-4819AAA20529@gmail.com>



> On May 27, 2020, at 23:11, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Yes, precisely:

SSL/TLS client certificate verification with Python v3.4+ SSLContext
https://www.electricmonk.nl/log/2018/06/02/ssl-tls-client-certificate-verification-with-python-v3-4-sslcontext/

From solderpunk at SDF.ORG  Wed May 27 22:30:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 27 May 2020 21:30:33 +0000
Subject: Client certificate musings
In-Reply-To: <53E5F0E0-5840-46A3-932A-4819AAA20529@gmail.com>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
 <20200527164254.GA8751@SDF.ORG>
 <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>
 <20200527185807.GA21489@SDF.ORG>
 <AB846192-8F0E-414F-BE74-DC58F6331B72@gmail.com>
 <20200527211151.GC21489@SDF.ORG>
 <53E5F0E0-5840-46A3-932A-4819AAA20529@gmail.com>
Message-ID: <20200527213033.GD21489@SDF.ORG>

On Wed, May 27, 2020 at 11:13:09PM +0200, Petite Abeille wrote:

> SSL/TLS client certificate verification with Python v3.4+ SSLContext
> https://www.electricmonk.nl/log/2018/06/02/ssl-tls-client-certificate-verification-with-python-v3-4-sslcontext/

Okay, I stand very slightly corrected: a Python server using the
standard library can accept a self-signed client certificate *if* that
certificate (not just its fingerprint but the entire thing) is
whitelisted in advance of the connection.  But this is insufficient for
almost all the applications we've discussed.  It's of no use for the
transient client certificate paradigm, in particular.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Wed May 27 23:51:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 28 May 2020 00:51:19 +0200
Subject: Client certificate musings
In-Reply-To: <20200527213033.GD21489@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <alpine.DEB.2.20.2005242215110.18317@pling.qwghlm.org>
 <20200527164254.GA8751@SDF.ORG>
 <alpine.DEB.2.20.2005271916350.18317@pling.qwghlm.org>
 <20200527185807.GA21489@SDF.ORG>
 <AB846192-8F0E-414F-BE74-DC58F6331B72@gmail.com>
 <20200527211151.GC21489@SDF.ORG>
 <53E5F0E0-5840-46A3-932A-4819AAA20529@gmail.com>
 <20200527213033.GD21489@SDF.ORG>
Message-ID: <B7ADC039-18B8-40A5-9B0E-9228C4C70C36@gmail.com>



> On May 27, 2020, at 23:30, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> But this is insufficient for
> almost all the applications we've discussed.  It's of no use for the
> transient client certificate paradigm, in particular.

Bah. No python then. Still like the creative use of TLS.


From luke.emmet at gmail.com  Thu May 28 12:22:07 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 28 May 2020 12:22:07 +0100
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
Message-ID: <5ECF9EDF.90607@gmail.com>

Hi All

I'm pleased to announce the first release of GemiNaut, a user friendly 
Gemini client for Windows.

Its written with a more "typical" end user in mind who may not be so 
familiar with the command line and would like a graphical browser to 
explore Gemini space. In particular, I'm interested in usability, 
cognitive aspects of navigation through hypertext - how to support the 
user in his or her understanding of where they are and what comes up 
next if they were to click on the links.

Some key features

* Attractive GUI with familiar browser navigation features/keyboard 
shortcuts etc
* Smooth content wrap and flow
* Content theming engine - view the same content in different visual modes
* Automatic site based themes - help to distinguish one site from another
* Easily distinguish links outside of Gemini (e.g. to HTTP web servers) 
from the link style (fat arrow vs squiggly one)
* View source

The theming engine is extensible - not quite drop in yet, but that is my 
direction of travel. It uses HTML for the actual rendering of the 
content, which allows for some innovation and experimentation of the 
possible options.

One element that is innovative as far as I know is the support for 
automatic "site-specific" themes. As you know there is no styling 
information in GMI documents, so it is sometimes difficult to know whose 
site you are on, and when you have traversed the boundary from one 
author voice to another. On the web each site has its own look and feel.

I wanted to explore the idea of automatic site specific themes, and the 
"Fabric" theme puts some of these ideas into practice as an initial 
pass. Each site gets its own simple look and feel as if laid out on a 
different fabric, like a tablecloth.

There are other themes in this initial release, including

Plain - simple, and effective, black text on white background, blue links
Terminal - for fixed width folk who like to live in the dark
Unified - a theme that tries to bring together common navigational and 
search elements

You can switch between these as you go.

For further details, screenshots, downloads and source, please see the 
project home page:

   https://www.marmaladefoo.com/pages/geminaut

Any feedback and further thoughts welcome.

Best Wishes

  - Luke

From tastytea+gemini at tastytea.de  Thu May 28 14:38:39 2020
From: tastytea+gemini at tastytea.de (tastytea)
Date: Thu, 28 May 2020 15:38:39 +0200
Subject: gemserv: Non-gemini files have mime type text/gemini
Message-ID: <20200528153839.5e04f94b@ventiloplattform.tastytea.de>

For example, <gemini://tastytea.de/dotfiles/.emacs.d/init.el> returns
?20 text/gemini??. Files without a file extension are also returned as
text/gemini.

I think text/plain is better suited as the default type for unknown
files.

? echo -en 'gemini://tastytea.de/dotfiles/.emacs.d/init.el\r\n' \
      | openssl s_client -connect tastytea.de:1965 -quiet | head -n 1
-- 
Get my PGP key with `gpg --locate-keys tastytea at tastytea.de` or at
<https://tastytea.de/tastytea.asc>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200528/e58aaeed/attachment.sig>

From tastytea+gemini at tastytea.de  Thu May 28 14:57:57 2020
From: tastytea+gemini at tastytea.de (tastytea)
Date: Thu, 28 May 2020 15:57:57 +0200
Subject: gemserv: Non-gemini files have mime type text/gemini
In-Reply-To: <20200528153839.5e04f94b@ventiloplattform.tastytea.de>
References: <20200528153839.5e04f94b@ventiloplattform.tastytea.de>
Message-ID: <20200528155757.3bb3425a@ventiloplattform.tastytea.de>

On 2020-05-28 15:38+0200
tastytea <tastytea+gemini at tastytea.de> wrote:
>[?]

Oops, sorry. I don't know how that happened. ?

-- 
Get my PGP key with `gpg --locate-keys tastytea at tastytea.de` or at
<https://tastytea.de/tastytea.asc>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200528/36bd644a/attachment.sig>

From solderpunk at SDF.ORG  Thu May 28 16:29:13 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 15:29:13 +0000
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <5ECF9EDF.90607@gmail.com>
References: <5ECF9EDF.90607@gmail.com>
Message-ID: <20200528152913.GA21188@SDF.ORG>

On Thu, May 28, 2020 at 12:22:07PM +0100, Luke Emmet wrote:
 
> Any feedback and further thoughts welcome.
> 

Thanks a lot for sharing this!  Even as a "terminal junkie" myself I am
really happy to see more "user friendly" clients appear, especially for
more mainstream platforms.

I am very excited to see that people are starting to explore the
possibilities for client-driven styling of Geminispace.  Slight
differences in appearance for different domains, and also for links
into/out of Geminispace are both excellent ideas.  I'm curious about the
blue and white geomeric icon shown in your screenshot for the "fabric"
theme.  Is that randomly generated based on the hostname?  Is it the
result of a failed favicon request, or is it always there in that theme?

Something no client has done yet, as far as I know, which I think would
be great is to make use of the different levels of heading which are
possible in text/gemini to automatically generate a "table of contents"
for a long document which could be displayed in a side-panel, and allow
immediate jumping to a particular location.  A lot of PDF viewers have
something like this.  This was just as big a motivation for my decision
to include those headers in the spec as that they look nice.  My hope is
that with good clients it ends up being extremely easy to make
geminisites which are very quick and easy to navigate or, at the very
least, requires a concerted effort to make one which is hard to
navigate.

I would also like to see - and this is just my personal preference,
which I hope people agree with but which I can't force anybody to share
- better support in clients for bookmarking and for handling Atom/RSS
feeds.  The mainstream web experience has tended towards people having
their browsing directed for them, by things popping up on feeds hosted
by (a small number of) other people.  There's obviously some value in
this for content discovery and discussion, but I think it would also be
nice if, along with the technical changes at a protocol level to
discourage tracking, reduce software and hardware requirements, and
generally remove bloat and clutter, Gemini could also be a vehicle for
a "cultural change" toward (among other things!) more self-directed and
self-paced reading.

But we'll see how that goes.

Anyway, this looks like a great project with really interesting plans.
Please keep us informed!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu May 28 16:40:49 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 15:40:49 +0000
Subject: Client certificate musings
In-Reply-To: <20200524142726.GB4190@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
 <20200524142726.GB4190@SDF.ORG>
Message-ID: <20200528154049.GB21188@SDF.ORG>

On Sun, May 24, 2020 at 02:27:26PM +0000, solderpunk wrote:
> On Sun, May 24, 2020 at 09:04:29AM +1000, Thomas Karpiniec wrote:
>  
> > With this in mind, my current opinion is that there should be no way
> > for a server to request a non-disposable certificate. Where
> > authentication is required, it should be done in-band via a password
> > or username/password 10 responses as you noted, which is then
> > associated on the server with the transient certificate. It then
> > becomes the responsibility of clients to ask the user "how long do you
> > want to stay authenticated to this website?" If it times out, they can
> > simply repeat their authentication.
> 
> Hmm, interesting.  I'll ponder this, thanks for your thoughts.  My first
> reaction is that that I'm reluctant to remove a dedicated mechanism for
> creating something which is unavoidably and non-negotiably very short
> lived.  Maybe you didn't mean for that to happen, though?

I really like the "put all control into the hands of the user" aspect of
this design, I have to admit.  And only having support for one kind of
on-demand client certificate simplifies things.  I just keep coming back
to the thought that it's hard for the user to have all the information
they need to make that decision.  There's no way to stop people using
certificate fingerprinting to do a bitcoin-esque tying of account
identity to a private key.  Some people might really think that's better
than using in-band username and password (which is subject to weak
passwords, brute-forcing, theft of password database, etc.).  So in all
likelihood both patterns will end up being used "in the wild".  And
unless I know in advance what's coming up after I generate a
certificate, it's hard to know what to do.  If I'm about to be asked to
supply a username and password, I probably would have been happy with a
short-lived certificate which gets deleted when I close my client.  If
I'm about to be told "okay, great, we've taken your cert fingerprint,
this is now your idea, please back it up and be careful", I definitely
want to pick something longer lived.  This either requires different
status codes for different authentication models so that clients can
suggest sensible defaults and users can make informed decisions, *or* it
requires good communication from app designers at some point in the
"sign in/up" workflow before the client request comes along (and good
understanding from the user).

Cheers,
Solderpunk

From int at 80h.dev  Thu May 28 17:48:10 2020
From: int at 80h.dev (int 80h)
Date: Thu, 28 May 2020 12:48:10 -0400
Subject: gemserv: Non-gemini files have mime type text/gemini
In-Reply-To: <20200528153839.5e04f94b@ventiloplattform.tastytea.de>
Message-ID: <C32ILAQBGNBT.V4PPSEJGULPC@freebsd.lan>

On Thu May 28, 2020 at 11:38 AM EDT, tastytea wrote:
> For example, <gemini://tastytea.de/dotfiles/.emacs.d/init.el> returns
> ?20 text/gemini??. Files without a file extension are also returned
> as
> text/gemini.
>
> I think text/plain is better suited as the default type for unknown
> files.

That's probably a good idea. The only difference is formatting so that
that would make more sense. Thanks.

int 80h

From solderpunk at SDF.ORG  Thu May 28 18:59:05 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 17:59:05 +0000
Subject: Client certificate musings
In-Reply-To: <20200528154049.GB21188@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
 <20200524142726.GB4190@SDF.ORG> <20200528154049.GB21188@SDF.ORG>
Message-ID: <20200528175905.GD21188@SDF.ORG>

As some of you may have read at
gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi,
I have been having a small semi-crisis-of-confidence regarding the
apparently unavoidable complexity of speccing a robust and flexible
mechanism for in-band authentication with client certificates.  Thanks,
by the way, to everybody who emailed me or made posts of their own in
response to that post.

I'm still committed to mandatory TLS in Gemini, as I have been since day
one.  And I still think client certificates are an under-appreciated and
powerful tool for authentication.  But I've also convinced myself that
the transient certificate idea got specced mostly just because I was so
pleased by the realisation that it was *possible* to use client certs
that way, not because there was a clear motivation.  So far nobody has
used them for anything and it hasn't exactly ruined the experience.
People have been building interesting interactive things without client
certs so far.  The most obvious and compelling use case for client
certificates for me is for people to be able to put up private content
for their own use (a private bookmarking or to-do app, for example), and
that doesn't require anything complicated in Gemini at all, it can be
done ssh style by whitelisting the fingerprint of a self-signed cert, or
traditional TLS style by setting up your own CA.

None of which is to say the other stuff needs to go, but I think it
probably ought to be a lower priority than other considerations which
affect searchability and accessibility of publically available material,
which is clearly more important - yes, less fun and interesting from a
technogeek perspective, but more actually important.

I'm going to keep thinking about this stuff, and I encourage people to
share their thoughts and ideas and to experiment with what's specced in
AV-98.  But, whereas I previously thought this would be the part of the
spec which saw the bulk of activity once the spec freeze wore off, I
think maybe for now this should actually stay in the "experimental
features for power users, subject to change" category while we focus on
other stuff.

Cheers,
Solderpunk


From martin at no.ucant.org  Thu May 28 19:28:04 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Thu, 28 May 2020 19:28:04 +0100 (BST)
Subject: Client certificate musings
In-Reply-To: <20200528175905.GD21188@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local> <20200524142726.GB4190@SDF.ORG>
 <20200528154049.GB21188@SDF.ORG> <20200528175905.GD21188@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2005281910540.18317@pling.qwghlm.org>

On Thu, 28 May 2020, solderpunk wrote:

> I have been having a small semi-crisis-of-confidence regarding the
> apparently unavoidable complexity of speccing a robust and flexible
> mechanism for in-band authentication with client certificates.  Thanks,
> by the way, to everybody who emailed me or made posts of their own in
> response to that post.

> that way, not because there was a clear motivation.  So far nobody has
> used them for anything and it hasn't exactly ruined the experience.
> People have been building interesting interactive things without client
> certs so far.  The most obvious and compelling use case for client
> certificates for me is for people to be able to put up private content
> for their own use (a private bookmarking or to-do app, for example), and
> that doesn't require anything complicated in Gemini at all, it can be
> done ssh style by whitelisting the fingerprint of a self-signed cert, or
> traditional TLS style by setting up your own CA.

There is no need whatsoever for a crisis of confidence. I certainly have 
confidence in your approach to Gemini or I'd not have tried making a 
server in an uphill language like Erlang. The client certificate mechanism
is unfamiliar rather than complex. The unfamiliarity will run into 
friction in terms of developer resistance and the limitations of existing 
code and documentation, but those are only two among many elements in the 
tradeoff. Given time, the limitations of SSL libraries will be better 
understood or obviated.

Maybe the transient cert thing will take off; maybe it won't. Again, time 
will tell and it doesn't need to be resolved any time soon.

I have a pretty clear vision for what I'd like to be able to do with 
Gemini: have a visually tasteful, minimalist, distraction-free reading 
experience for content that is trivial to publish and trivial to keep just 
among my friends, and I feel the ecosystem will be there in a few months 
if not weeks.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From solderpunk at SDF.ORG  Thu May 28 19:43:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 18:43:21 +0000
Subject: The lang parameter to text/gemini
Message-ID: <20200528184321.GE21188@SDF.ORG>

Ahoy!

Let's pick this issue up again, in its own thread this time.

My original proposal was that we add a new parameter to the text/gemini
media type to specify the human language a document is written in.
Following the lead of RFC1766, the parameter would be called "lang" and
take values based on ISO 639 language codes and ISO 3166 country codes.

As far as I recall, nobody actually objected to this as something we
should do in principle, instead we just got distracted by various edge
cases.  But I guess I may as well ask now: does anybody think this is a
*bad* idea?

The two concerete motivations for adding this were:

1. Screenreaders need to know this information to know which settings to
use for their text-to-speech engine: the same letters correspond to
different sounds in different languages.

2. Search engines may want to to offer their users the ability to ask
for results only in a particular set of languages.

Can anybody think of additional likey use cases besides these?

Since these are the main motivations, that also means that "normal
clients" (i.e. for use by sighted human users) have minimal use for this
information and can more or less ignore it.  So, in considering the edge
cases that came up, we should be thinking about screenreaders and search
engines, not the stuff that most people here are presumably using day to
day.

The first question was what to do if the parameter is not specified.

I was, and am, opposed to putting a default language in the spec.

In the case of a screenreader, it seems entirely sensible to me that the
user of any such screenreader should be able to specify their own
default based on their primary reading languages, and that the software
should make it easy to change this when it is clear there is a problem.
It's not really the Gemini spec's job to say anything about this.

The case of search engines is trickier, since their resulting database
does not have just one user but many.  This was where autodetection
first came up, which some people seemed to get carried away with.  Fully
generalised autodetection of language is computationally expensive and
it gives answers with some uncertainty.  A large search engine project
*may* want to think about it - the idea of clients for humans users
doing it as a routine response to a lack of a lang parameter is nuts.

A simpler option for search engines might simply be to interpret a user
request of "only show me results in languages X" as "don't show results
*known* to be in languages other than X".  i.e documents for which the
language is not known are always possible search results.  This is
imperfect, but, well, sometimes life is.

In short, I am not sure that the lack of specified default behaviour is
a good reason not to go ahead with this.

The second question was what to do when a document contains text in
multiple languages.  This is a trickier question.  I'd prefer not to
define a new line type to handle it.  We could at least allow the lang
parameter to accept multiple values separated by some delimiter.  It
wouldn't be clear from that which parts were what, but it could at least
act as a strong hint to screenreaders.  Search engines could include
such pages in results if any of the delcared languages matched one the
user had requested.  Actually, perhaps that's a perfectly adequate
solution, in which case this is not trickier at all.

There's also the question of directionality, which I think might require
a separate parameter entirely.  But let's focus on the language thing
for now.  How does the above sound to people?

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Thu May 28 19:47:24 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 18:47:24 +0000
Subject: Client certificate musings
In-Reply-To: <alpine.DEB.2.20.2005281910540.18317@pling.qwghlm.org>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local>
 <20200524142726.GB4190@SDF.ORG> <20200528154049.GB21188@SDF.ORG>
 <20200528175905.GD21188@SDF.ORG>
 <alpine.DEB.2.20.2005281910540.18317@pling.qwghlm.org>
Message-ID: <20200528184724.GF21188@SDF.ORG>

On Thu, May 28, 2020 at 07:28:04PM +0100, Martin Keegan wrote:
 
> I have a pretty clear vision for what I'd like to be able to do with Gemini:
> have a visually tasteful, minimalist, distraction-free reading experience
> for content that is trivial to publish and trivial to keep just among my
> friends, and I feel the ecosystem will be there in a few months if not
> weeks.

This is pretty much the "first class" application for Gemini,
well-stated.  It is clear that the protocol is capable of more, and
where it's posible to pave a smooth path for doing more without
interfering with exactly what you said or making things too complex I
intend to do it.  But that stuff should be thought of as "icing" on the
cake that you described (although I'd add something about privacy in
there too).

Cheers,
Solderpunk

From nicole at strega-nil.co  Thu May 28 21:02:34 2020
From: nicole at strega-nil.co (Nicole Mazzuca)
Date: Thu, 28 May 2020 20:02:34 +0000
Subject: The lang parameter to text/gemini
In-Reply-To: <20200528184321.GE21188@SDF.ORG>
References: <20200528184321.GE21188@SDF.ORG>
Message-ID: <bUz83kRQD3H3RP2l2VI_UHE_rURSdOLnq0P56z4LLBouOVN-ULwZyprY3vBnpVfWWS8QYMgaAyLrANB1N-Rsmx9ocoeYLCDs-2aSOiHrkRY=@strega-nil.co>

I would say, generally, that the base directionality of text is given by the script one is using, which is defined by the language tag. A language has a default script (for en-US, that's Latin), and if someone wants to change their script, it's very easy to do so via the script part of the lang tag, for example, yi-US (which is shorthand for yi-Hebr-US, and is RTL) vs yi-Latn-US (LTR).

Nicole

On Thu, May 28, 2020 at 11:43, solderpunk <solderpunk at SDF.ORG> wrote:

> Ahoy!
>
> Let's pick this issue up again, in its own thread this time.
>
> My original proposal was that we add a new parameter to the text/gemini
> media type to specify the human language a document is written in.
> Following the lead of RFC1766, the parameter would be called "lang" and
> take values based on ISO 639 language codes and ISO 3166 country codes.
>
> As far as I recall, nobody actually objected to this as something we
> should do in principle, instead we just got distracted by various edge
> cases. But I guess I may as well ask now: does anybody think this is a
> *bad* idea?
>
> The two concerete motivations for adding this were:
>
> 1. Screenreaders need to know this information to know which settings to
> use for their text-to-speech engine: the same letters correspond to
> different sounds in different languages.
>
> 2. Search engines may want to to offer their users the ability to ask
> for results only in a particular set of languages.
>
> Can anybody think of additional likey use cases besides these?
>
> Since these are the main motivations, that also means that "normal
> clients" (i.e. for use by sighted human users) have minimal use for this
> information and can more or less ignore it. So, in considering the edge
> cases that came up, we should be thinking about screenreaders and search
> engines, not the stuff that most people here are presumably using day to
> day.
>
> The first question was what to do if the parameter is not specified.
>
> I was, and am, opposed to putting a default language in the spec.
>
> In the case of a screenreader, it seems entirely sensible to me that the
> user of any such screenreader should be able to specify their own
> default based on their primary reading languages, and that the software
> should make it easy to change this when it is clear there is a problem.
> It's not really the Gemini spec's job to say anything about this.
>
> The case of search engines is trickier, since their resulting database
> does not have just one user but many. This was where autodetection
> first came up, which some people seemed to get carried away with. Fully
> generalised autodetection of language is computationally expensive and
> it gives answers with some uncertainty. A large search engine project
> *may* want to think about it - the idea of clients for humans users
> doing it as a routine response to a lack of a lang parameter is nuts.
>
> A simpler option for search engines might simply be to interpret a user
> request of "only show me results in languages X" as "don't show results
> *known* to be in languages other than X". i.e documents for which the
> language is not known are always possible search results. This is
> imperfect, but, well, sometimes life is.
>
> In short, I am not sure that the lack of specified default behaviour is
> a good reason not to go ahead with this.
>
> The second question was what to do when a document contains text in
> multiple languages. This is a trickier question. I'd prefer not to
> define a new line type to handle it. We could at least allow the lang
> parameter to accept multiple values separated by some delimiter. It
> wouldn't be clear from that which parts were what, but it could at least
> act as a strong hint to screenreaders. Search engines could include
> such pages in results if any of the delcared languages matched one the
> user had requested. Actually, perhaps that's a perfectly adequate
> solution, in which case this is not trickier at all.
>
> There's also the question of directionality, which I think might require
> a separate parameter entirely. But let's focus on the language thing
> for now. How does the above sound to people?
>
> Cheers,
> Solderpunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200528/0330b10c/attachment.htm>

From solderpunk at SDF.ORG  Thu May 28 21:13:25 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 20:13:25 +0000
Subject: The lang parameter to text/gemini
In-Reply-To: <bUz83kRQD3H3RP2l2VI_UHE_rURSdOLnq0P56z4LLBouOVN-ULwZyprY3vBnpVfWWS8QYMgaAyLrANB1N-Rsmx9ocoeYLCDs-2aSOiHrkRY=@strega-nil.co>
References: <20200528184321.GE21188@SDF.ORG>
 <bUz83kRQD3H3RP2l2VI_UHE_rURSdOLnq0P56z4LLBouOVN-ULwZyprY3vBnpVfWWS8QYMgaAyLrANB1N-Rsmx9ocoeYLCDs-2aSOiHrkRY=@strega-nil.co>
Message-ID: <20200528201325.GJ21188@SDF.ORG>

On Thu, May 28, 2020 at 08:02:34PM +0000, Nicole Mazzuca wrote:
> I would say, generally, that the base directionality of text is given by the script one is using, which is defined by the language tag. A language has a default script (for en-US, that's Latin), and if someone wants to change their script, it's very easy to do so via the script part of the lang tag, for example, yi-US (which is shorthand for yi-Hebr-US, and is RTL) vs yi-Latn-US (LTR).

Ah, I wasn't aware of this, thank you!  Shufei, if you're reading, do
you know if this addresses the concerns you've voiced to me previously
about vertical rendering of traditional Chinese?  Or is the problem that
there's just no standardised way to denote that, rather than a lack of
client support?

Cheers,
Solderpunk


From dunderpate at sdf.org  Thu May 28 21:27:35 2020
From: dunderpate at sdf.org (Dunderpate)
Date: Thu, 28 May 2020 15:27:35 -0500
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <5ECF9EDF.90607@gmail.com>
References: <5ECF9EDF.90607@gmail.com>
Message-ID: <43c4c0b6ddd59fa6ea28c32a2efb54e3.squirrel@mx.sdf.org>

Hi there Luke!

Thanks a boat-load for this :D It's super light, portable and there are
pre-built binaries. I'm all over it. I'd be happy to report any issues
that I find while using it.

Thanks again!
-- 
Dunderpate


From ben at tilde.team  Thu May 28 21:37:50 2020
From: ben at tilde.team (Ben Harris)
Date: Thu, 28 May 2020 16:37:50 -0400
Subject: Some notes from the tildeverse
Message-ID: <a171827c-ba44-13d7-ddf4-35b00192ad34@tilde.team>

Hello geminauts!

First time poster here.

I recognize some familiar names here and I try to keep up with the list 
when I can, but there's usually too much going on here (not a bad 
problem to have).

First, I'd like to announce that I've set up user hosting on tilde.team 
with gemserv out of ~/public_gemini[0]. I'm looking forward to seeing 
more user content!

I've also set up a homepage for the tildeverse[1].

If you've been on irc, you've probably heard about my troubleshooting on 
getting gemserv up and running!

Now some notes about tildegit.org, where some notable projects are hosted:

- registration on tildegit is whitelisted to tilde email addresses 
(namely from tildeverse members and known pubnixes). feel free to 
contact me (email is fine, irc is preferred) if you don't have a tilde 
email address and I'd be happy to set up an account for you. Otherwise, 
you might consider signing up for a tilde account! :)

- gitea, the software that powers tildegit.org, does not support 
incoming email (i know, it's unfortunate), and I've been receiving 
plenty of mails of people replying to issues/PRs that end up in my inbox 
and not on the issue as you might expect. there's an existing issue for 
incoming mail for gitea, but it hasn't seen much traction. [2]

Cheers,
~ben

[0]: gemini://tilde.team
[1]: gemini://tildeverse.org
[2]: https://github.com/go-gitea/gitea/issues/2386

From natpen at natpen.net  Thu May 28 21:51:56 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Thu, 28 May 2020 16:51:56 -0400
Subject: The lang parameter to text/gemini
In-Reply-To: <20200528184321.GE21188@SDF.ORG>
References: <20200528184321.GE21188@SDF.ORG>
Message-ID: <20200528205156.GA267254@goldfish.localdomain>

On Thu, May 28, 2020 at 06:43:21PM +0000, solderpunk wrote:
> As far as I recall, nobody actually objected to this as something we
> should do in principle, instead we just got distracted by various edge
> cases.  But I guess I may as well ask now: does anybody think this is a
> *bad* idea?

Nope, I think it's a nice addition and not a bad idea at all! Low
extensibility, high value for the two use cases you described (screen
readers and search engines).

On Thu, May 28, 2020 at 06:43:21PM +0000, solderpunk wrote:
> I was, and am, opposed to putting a default language in the spec.

Agreed.

On Thu, May 28, 2020 at 06:43:21PM +0000, solderpunk wrote:
> The case of search engines is trickier, since their resulting database
> does not have just one user but many.  This was where autodetection
> first came up, which some people seemed to get carried away with.  Fully
> generalised autodetection of language is computationally expensive and
> it gives answers with some uncertainty.  A large search engine project
> *may* want to think about it - the idea of clients for humans users
> doing it as a routine response to a lack of a lang parameter is nuts.

Agreed.

On Thu, May 28, 2020 at 06:43:21PM +0000, solderpunk wrote:
> A simpler option for search engines might simply be to interpret a user
> request of "only show me results in languages X" as "don't show results
> *known* to be in languages other than X".  i.e documents for which the
> language is not known are always possible search results.  This is
> imperfect, but, well, sometimes life is.
>
> In short, I am not sure that the lack of specified default behaviour is
> a good reason not to go ahead with this.

I agree with this in principle (i.e., as a guidepost for good user
experience in a search engine), but there can be complicating factors
in practice. In particular, some common and generally effective text
indexing processes involve things like porter stemming words (so
"stemmed" and "stemming" would both get indexed as something like
"stem") and removal of "stop words" (and, in, the...). As you might
imagine, both of these operations are specific to language.

So, simply in creating an index of Geminispace, there might already be
an assumed "default" language. In the case of GUS, this is English. I
don't stop GUS from indexing any non-English content currently, but
the quality of indexing is lower for other languages. Operations like
the above (porter stemming and removing stop words) will simply be
no-ops.

And then the other side of this experience is that when a user types
in a search query, that also goes through the same process - the query
is porter stemmed, stripped of its stop words, then shuttled off to
the TF-IDF index to find and score the actual matches.

For what its worth, I do not believe any of what I've written here is
an argument for adding a default language to the spec. That, to me,
feels solidly outside the appropriate scope of the spec. But, if we're
talking search engines, there's probably going to end up being a
default language in practice for any search engine based on mainstream
full-text search approaches.

On Thu, May 28, 2020 at 06:43:21PM +0000, solderpunk wrote:
> The second question was what to do when a document contains text in
> multiple languages.  This is a trickier question.  I'd prefer not to
> define a new line type to handle it.  We could at least allow the lang
> parameter to accept multiple values separated by some delimiter.

Agreed! I think the power-to-weight ratio of a line-specific lang
value is too low. Allowing multiple lang values at the document level
feels like a nice balance though.

On Thu, May 28, 2020 at 06:43:21PM +0000, solderpunk wrote:
> There's also the question of directionality, which I think might require
> a separate parameter entirely.  But let's focus on the language thing
> for now.  How does the above sound to people?

What does directionality mean in this context?

In terms of how the above all sounds:
- I support the addition of the document-level lang parameter, which
  can accept multiple values, to the spec.
- I do NOT support the addition of a default document-level lang value
  to the spec.
- I do NOT support the addition of a line-level lang parameter.

Natalie

From solderpunk at SDF.ORG  Thu May 28 21:49:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 20:49:35 +0000
Subject: Some notes from the tildeverse
In-Reply-To: <a171827c-ba44-13d7-ddf4-35b00192ad34@tilde.team>
References: <a171827c-ba44-13d7-ddf4-35b00192ad34@tilde.team>
Message-ID: <20200528204935.GK21188@SDF.ORG>

On Thu, May 28, 2020 at 04:37:50PM -0400, Ben Harris wrote:
 
> First, I'd like to announce that I've set up user hosting on tilde.team with
> gemserv out of ~/public_gemini[0]. I'm looking forward to seeing more user
> content!

Hey Ben, wonderful to hear this!  The broad support for Gemini coming
out of the tilde/pubnix scene makes me really happy.

> - registration on tildegit is whitelisted to tilde email addresses (namely
> from tildeverse members and known pubnixes). feel free to contact me (email
> is fine, irc is preferred) if you don't have a tilde email address and I'd
> be happy to set up an account for you. Otherwise, you might consider signing
> up for a tilde account! :)

Aaah, is *that* what's happened?  I've heard a few people mention not
being able to register an account, but couldn't see why not with a quick
check.  Was it always like this (I guess I wouldn't have noticed, using
an @sdf.org address), or was this done in response to abuse problems?

I get that tildegit is intended to serve the tildeverse so in some ways
this restriction makes perfect sense.  It's kind of a shame, though, for
"outsiders" to not be able to open issues, make pull requests, etc. :(

Cheers,
Solderpunk

From ben at tilde.team  Thu May 28 22:13:08 2020
From: ben at tilde.team (Ben Harris)
Date: Thu, 28 May 2020 17:13:08 -0400
Subject: Some notes from the tildeverse
In-Reply-To: <20200528204935.GK21188@SDF.ORG>
References: <a171827c-ba44-13d7-ddf4-35b00192ad34@tilde.team>
 <20200528204935.GK21188@SDF.ORG>
Message-ID: <5c5b1c18-5d37-fd39-00d6-2cc1408a6ced@tilde.team>

On 5/28/20 4:49 PM, solderpunk wrote:

>> - registration on tildegit is whitelisted to tilde email addresses (namely
>> from tildeverse members and known pubnixes). feel free to contact me (email
>> is fine, irc is preferred) if you don't have a tilde email address and I'd
>> be happy to set up an account for you. Otherwise, you might consider signing
>> up for a tilde account! :)
> 
> Aaah, is *that* what's happened?  I've heard a few people mention not
> being able to register an account, but couldn't see why not with a quick
> check.  Was it always like this (I guess I wouldn't have noticed, using
> an @sdf.org address), or was this done in response to abuse problems?

I set up the whitelist to combat a large number of automated accounts 
being created. It was several dozen automated spam accounts per week, 
which was a pain to deal with!

I've added @sdf.org to the whitelist and I'm happy to create accounts 
for people as needed as I mentioned above.

> I get that tildegit is intended to serve the tildeverse so in some ways
> this restriction makes perfect sense.  It's kind of a shame, though, for
> "outsiders" to not be able to open issues, make pull requests, etc. :(


From natpen at natpen.net  Thu May 28 22:17:28 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Thu, 28 May 2020 17:17:28 -0400
Subject: The lang parameter to text/gemini
In-Reply-To: <20200528205156.GA267254@goldfish.localdomain>
References: <20200528184321.GE21188@SDF.ORG>
 <20200528205156.GA267254@goldfish.localdomain>
Message-ID: <20200528211728.GB267254@goldfish.localdomain>

On Thu, May 28, 2020 at 04:51:56PM -0400, Natalie Pendragon wrote:
> What does directionality mean in this context?

Ah, I understand directionality now from reading Nicole's response!
Left-to-right vs right-to-left languages.

From solderpunk at SDF.ORG  Thu May 28 22:15:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 21:15:35 +0000
Subject: The lang parameter to text/gemini
In-Reply-To: <20200528205156.GA267254@goldfish.localdomain>
References: <20200528184321.GE21188@SDF.ORG>
 <20200528205156.GA267254@goldfish.localdomain>
Message-ID: <20200528211535.GL21188@SDF.ORG>

On Thu, May 28, 2020 at 04:51:56PM -0400, Natalie Pendragon wrote:

> I agree with this in principle (i.e., as a guidepost for good user
> experience in a search engine), but there can be complicating factors
> in practice. In particular, some common and generally effective text
> indexing processes involve things like porter stemming words (so
> "stemmed" and "stemming" would both get indexed as something like
> "stem") and removal of "stop words" (and, in, the...). As you might
> imagine, both of these operations are specific to language.
> 
> So, simply in creating an index of Geminispace, there might already be
> an assumed "default" language. In the case of GUS, this is English. I
> don't stop GUS from indexing any non-English content currently, but
> the quality of indexing is lower for other languages. Operations like
> the above (porter stemming and removing stop words) will simply be
> no-ops.
> 
> And then the other side of this experience is that when a user types
> in a search query, that also goes through the same process - the query
> is porter stemmed, stripped of its stop words, then shuttled off to
> the TF-IDF index to find and score the actual matches.

Thanks for shedding some light on the processing that happens behind the
scenes in GUS!  Language declaration is even more important to search
engines than I had realised.  Once we've got this specced we will have
to really encourage the authors of servers to make it possible for users
to control this parameter, and to encourage the folks at non-English
servers to use it!
 
> What does directionality mean in this context?

Left-to-right vs right-to-left vs top-to-bottom, etc.  I don't think
this will actually be relevant for search at all?
 
> In terms of how the above all sounds:
> - I support the addition of the document-level lang parameter, which
>   can accept multiple values, to the spec.
> - I do NOT support the addition of a default document-level lang value
>   to the spec.
> - I do NOT support the addition of a line-level lang parameter.

Thanks for the nice, clear summary!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu May 28 22:16:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 28 May 2020 21:16:44 +0000
Subject: Some notes from the tildeverse
In-Reply-To: <5c5b1c18-5d37-fd39-00d6-2cc1408a6ced@tilde.team>
References: <a171827c-ba44-13d7-ddf4-35b00192ad34@tilde.team>
 <20200528204935.GK21188@SDF.ORG>
 <5c5b1c18-5d37-fd39-00d6-2cc1408a6ced@tilde.team>
Message-ID: <20200528211644.GM21188@SDF.ORG>

On Thu, May 28, 2020 at 05:13:08PM -0400, Ben Harris wrote:
 
> I set up the whitelist to combat a large number of automated accounts being
> created. It was several dozen automated spam accounts per week, which was a
> pain to deal with!

Ah, that sounds nasty.  I totally understand the whitelist, then!

Cheers,
Solderpunk

From peteyboy at SDF.ORG  Thu May 28 22:57:01 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Thu, 28 May 2020 21:57:01 +0000 (UTC)
Subject: Nano context highlighting for gmi file
Message-ID: <alpine.NEB.2.21.2005282145260.20615@sdf.lonestar.org>

So, to make it more pleasant to write gmi files in shell, I created a 
very simple "gemini.nanorc" file for text highlighting gemini files.

I figure I'd just paste the file's contents and instructions here:
Just open a new file in nayno (I assume that's what you are using if you 
are going to use this feature), paste all the text between the two ``` 
lines below into the file, and save as "gemini.nanorc", either in 
/usr/local/share/nano (if you are admin), ~/share/nano or whatever is 
right for your installation.

Then, again, depending on your installation, create or append to your 
existing /etc/nanorc or ~/.nanorc a line like the following:

include "/etc/nanorc/gemini.nanorc"

Hope it's useful for somebody! Here's the contents:

```
## Here is an example for the gemini web scheme's gmi file format

syntax gemini "\.(gmi|GMI)$"

# links
color magenta "^=>.*$"u

# preformatted
color yellow  start="^```* ?$" end="^```* ?$"

#headings
color cyan "^\#+.*$"

#bullets
color green "^\*+.*$"
```
--
peteyboy at sdf.org
SDF Public Access UNIX System - http://sdf.org

From peteyboy at SDF.ORG  Thu May 28 23:08:56 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Thu, 28 May 2020 22:08:56 +0000 (UTC)
Subject: Nano context highlighting for gmi file
Message-ID: <alpine.NEB.2.21.2005282202030.20615@sdf.lonestar.org>


Oops, I messed that up. The word "gemini" needs to be in quotes on line 2 
of the file. It should be:

syntax "gemini" "\.(gmi|GMI)$"

Here's the whole thing again:


  So, to make it more pleasant to write gmi files in shell, I created a
  very simple "gemini.nanorc" file for text highlighting gemini files.

  I figure I'd just paste the file's contents and instructions here:
  Just open a new file in nano (I assume that's what you are using if you
  are going to use this feature), paste all the text between the two ```
  lines below into the file, and save as "gemini.nanorc", either in
  /usr/local/share/nano (if you are admin), ~/share/nano or whatever is
  right for your installation.

  Then, again, depending on your installation, create or append to your
  existing /etc/nanorc or ~/.nanorc a line like the following:

  include "/etc/nanorc/gemini.nanorc"

  Hope it's useful for somebody! Here's the contents:

  ```
  ## Here is an example for the gemini web scheme's gmi file format

  syntax "gemini" "\.(gmi|GMI)$"

  # links
  color magenta "^=>.*$"

  # preformatted
  color yellow  start="^```* ?$" end="^```* ?$"

  #headings
  color cyan "^\#+.*$"

  #bullets
  color green "^\*+.*$"
  ```
  --
  peteyboy at sdf.org
  SDF Public Access UNIX System - http://sdf.org

--
peteyboy at sdf.org
SDF Public Access UNIX System - http://sdf.org

From sean at conman.org  Thu May 28 23:13:44 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 28 May 2020 18:13:44 -0400
Subject: Client certificate musings
In-Reply-To: <20200528175905.GD21188@SDF.ORG>
References: <20200523145638.GG12486@SDF.ORG>
 <20200523230429.GA38201@allanon.local> <20200524142726.GB4190@SDF.ORG>
 <20200528154049.GB21188@SDF.ORG> <20200528175905.GD21188@SDF.ORG>
Message-ID: <20200528221344.GT23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> As some of you may have read at
> gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi,

  Ooh, I did not know this.

  Anyway, I just read it, and having written both a gopher server [1] and a
Gemini server [2], I think I can answer the questions you posed.

> How much more difficult is Gemini to implement than Mercury?

  This, I think will depend upon the TLS libries used.  It would take me
less than five minutes to adapt my Gemini server to a Mercury server.  At a
minimum, I would just have to change

	local tls = require "org.conman.nfl.tls"

	local okay,err = tls.listen(addr,port,main,function(conf)
	  -- options for TLS 
	  ...
	end)

to

	local tcp = require "org.conman.nfl.tcp"

	local okay,err = tcp.listen(addr,post,main)

and remove the authentication block from the configuration, and ta-daaah!  I
have Mercury running.  But I was careful in my selection of TLS library and
I specifically picked the one I used [3] because of the ease it made using
TLS.  For the record, both my gopher server and Gemini server are *very*
similar in construction, and largely have feature-parity (sans TLS).

  I can't say for other TLS libraries---only the writers of other Gemini
servers (or clients) can say for sure how much complexity was added due to
TLS.  And as we're finding out, the client certificate support is a bit of
a mess, regardless of TLS library.

> What are the things Gemini can do which Mercury cannot?

  TLS.  And protection of an area of a Gemini site.

> How much do we value those things?

  TLS is valued quite a bit from what I see.  People are *still*
experiementing with TLS and gopher.

  I don't have much else to say about your post, or this message.  I think
the ease (or not) of TLS is an interesting conversation on its own right.

  -spc

[1]	https://github.com/spc476/port70

[2]	https://github.com/spc476/GLV-1.12556

[3]	It was a pain to install, but only because:

	1. it's a fork of OpenSSL
	2. I didn't want to blow out my current installation of OpenSSL

	It can be done thouygh, and I should probably do a write up on it so
	others may have a change of using GLV-1.12556, or even just know the
	joys of using libtls.

From petite.abeille at gmail.com  Thu May 28 23:29:49 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 00:29:49 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <5EBD9569.70309@orlando-lutes.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
Message-ID: <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com>



> On May 14, 2020, at 21:00, Luke Emmet <luke.emmet at orlando-lutes.com> wrote:
> 
> This is interesting, something like the sigils in Urbit, or Gravitar that are automatically generated from
> some identifier?
> 
> https://urbit.org/blog/creating-sigils/
> 

Had to give it a try ?

E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ??


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigil.svg
Type: image/svg+xml
Size: 2845 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/35aa06ba/attachment.svg>
-------------- next part --------------






From luke.emmet at gmail.com  Fri May 29 00:24:31 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 29 May 2020 00:24:31 +0100
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <20200528152913.GA21188@SDF.ORG>
References: <5ECF9EDF.90607@gmail.com> <20200528152913.GA21188@SDF.ORG>
Message-ID: <5ED0482F.2020703@gmail.com>

On 28-May-2020 16:29, solderpunk wrote:
> Thanks a lot for sharing this!  Even as a "terminal junkie" myself I am
> really happy to see more "user friendly" clients appear, especially for
> more mainstream platforms.

I think this will be important that there are clients out there for 
everyone.

> I am very excited to see that people are starting to explore the
> possibilities for client-driven styling of Geminispace.  Slight
> differences in appearance for different domains, and also for links
> into/out of Geminispace are both excellent ideas.  I'm curious about the
> blue and white geomeric icon shown in your screenshot for the "fabric"
> theme.  Is that randomly generated based on the hostname?  Is it the
> result of a failed favicon request, or is it always there in that theme?
This is a site-specific "placemarker" automatically generated for that 
site. It is the equivalent of a site logo, or something like that. 
Perhaps I might implement putting any favicon there if it exists. Each 
site has a different background "fabric" and placemarker. Together these 
elements help dramatically in my experience in finding your way around. 
You can click a link and recognise you have arrived at a familiar place.

The site placemarker is an active element. It will take you to the the 
home page for the site or user.

My concept of a site is that it is either the domain itself, or if there 
is a user specified in the path, then it is the user home.

gemini://domain1.tld/mypath.gmi -> site is domain1.tld for that page

gemini://domain2.tld/users/foo/bar/baz.gmi -> site is domain/users/foo 
for that page

This gives a nice overall approach that each user gets a singular theme 
applied to all their content, but there can be many users on a domain.

> Something no client has done yet, as far as I know, which I think would
> be great is to make use of the different levels of heading which are
> possible in text/gemini to automatically generate a "table of contents"
> for a long document which could be displayed in a side-panel, and allow
> immediate jumping to a particular location.  A lot of PDF viewers have
> something like this.  This was just as big a motivation for my decision
> to include those headers in the spec as that they look nice.  My hope is
> that with good clients it ends up being extremely easy to make
> geminisites which are very quick and easy to navigate or, at the very
> least, requires a concerted effort to make one which is hard to
> navigate.
Ah yes - it was already on my todo list, and I knew it wasnt going to be 
hard. I'm assuming you mean something like this :-)

   
https://www.marmaladefoo.com/vanilla/marmaladefoo/uploads/geminaut/geminaut_toc.png

I just now uploaded a new 0.8.3 version that has this implemented:

   https://www.marmaladefoo.com/pages/geminaut

> I would also like to see - and this is just my personal preference,
> which I hope people agree with but which I can't force anybody to share
> - better support in clients for bookmarking and for handling Atom/RSS
> feeds.  The mainstream web experience has tended towards people having
> their browsing directed for them, by things popping up on feeds hosted
> by (a small number of) other people.  There's obviously some value in
> this for content discovery and discussion, but I think it would also be
> nice if, along with the technical changes at a protocol level to
> discourage tracking, reduce software and hardware requirements, and
> generally remove bloat and clutter, Gemini could also be a vehicle for
> a "cultural change" toward (among other things!) more self-directed and
> self-paced reading.

I agree there are a set of cultural practices and expectations that we 
can try to shape with Gemini as a way of using the Internet. Finding the 
sweet spot is always a challenge, but I think there is good evidence of 
the general direction of our collective travel.

> But we'll see how that goes.
>
> Anyway, this looks like a great project with really interesting plans.
> Please keep us informed!

Thanks!

  - Luke



From luke.emmet at gmail.com  Fri May 29 00:26:55 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 29 May 2020 00:26:55 +0100
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <43c4c0b6ddd59fa6ea28c32a2efb54e3.squirrel@mx.sdf.org>
References: <5ECF9EDF.90607@gmail.com>
 <43c4c0b6ddd59fa6ea28c32a2efb54e3.squirrel@mx.sdf.org>
Message-ID: <5ED048BF.8080404@gmail.com>

Hello Dunderplate

On 28-May-2020 21:27, Dunderpate wrote:
> Thanks a boat-load for this :D It's super light, portable and there are
> pre-built binaries. I'm all over it. I'd be happy to report any issues
> that I find while using it.
>
> Thanks again!

Thanks - I'd be grateful of any practical feedback you have. It is still 
work in progress and I expect a few bugs here and there...

Feel free to re-download the latest 0.8.3 build.

Best Wishes

  - Luke

From luke.emmet at gmail.com  Fri May 29 00:29:35 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 29 May 2020 00:29:35 +0100
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com>
Message-ID: <5ED0495F.2050907@gmail.com>

On 28-May-2020 23:29, Petite Abeille wrote:
>> On May 14, 2020, at 21:00, Luke Emmet<luke.emmet at orlando-lutes.com>  wrote:
>>
>> This is interesting, something like the sigils in Urbit, or Gravitar that are automatically generated from
>> some identifier?
>>
>> https://urbit.org/blog/creating-sigils/
> Had to give it a try ?
>
> E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ??
Huh - that is cute. These Urbit avatars are quite attractive. I think 
they spent quite a bit of time on the graphic design of that engine.

  - Luke

From petite.abeille at gmail.com  Fri May 29 00:47:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 01:47:28 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <5ED0495F.2050907@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
Message-ID: <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>



> On May 29, 2020, at 01:29, Luke Emmet <luke.emmet at gmail.com> wrote:
> 
>> E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ??
> Huh - that is cute. These Urbit avatars are quite attractive. I think they spent quite a bit of time on the graphic design of that engine.

Yeah, pretty nifty actually.

Like their 'phonemic naming system' as well (the 4028369029 to ~lapryt-fidse bit):

https://urbit.org/understanding-urbit/urbit-id/
https://github.com/urbit/urbit-ob/blob/master/src/internal/co.js
https://github.com/urbit/sigil-js

It's a bit of a pain to run 'out-of-the-box' if you are not into node.js, but I'm confidant spc will get a sweet Lua implementation in no time :)

--
PA


From sean at conman.org  Fri May 29 01:09:22 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 28 May 2020 20:09:22 -0400
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <5ED0482F.2020703@gmail.com>
References: <5ECF9EDF.90607@gmail.com> <20200528152913.GA21188@SDF.ORG>
 <5ED0482F.2020703@gmail.com>
Message-ID: <20200529000922.GU23998@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
> Each site has a different background "fabric" and placemarker.

  How is this done?  I'm looking at the code and I don't see an obvious
place where this is done.  Then again, I don't use C# so I'm not sure where
to look.  It's a cool idea.

> My concept of a site is that it is either the domain itself, or if there 
> is a user specified in the path, then it is the user home.
> 
> gemini://domain1.tld/mypath.gmi -> site is domain1.tld for that page
> 
> gemini://domain2.tld/users/foo/bar/baz.gmi -> site is domain/users/foo 
> for that page

  Be careful, because different servers might display user directories
differently.  Some might do:

	gemini://example.com/~alice/

and others:

	gemini://example.net/users/bob/

and still others:

	gemini://example.org/Carol/

And some might just do all three just to mess with you 8-P

  -spc 


From parnikkapore at disroot.org  Fri May 29 01:22:57 2020
From: parnikkapore at disroot.org (parnikkapore at disroot.org)
Date: Fri, 29 May 2020 07:22:57 +0700
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <20200529000922.GU23998@brevard.conman.org>
Message-ID: <527e1558-fae0-4aa7-85d1-2ff2a6b78255@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/3636d683/attachment.htm>

From sean at conman.org  Fri May 29 01:52:21 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 28 May 2020 20:52:21 -0400
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <527e1558-fae0-4aa7-85d1-2ff2a6b78255@email.android.com>
References: <20200529000922.GU23998@brevard.conman.org>
 <527e1558-fae0-4aa7-85d1-2ff2a6b78255@email.android.com>
Message-ID: <20200529005221.GV23998@brevard.conman.org>

It was thus said that the Great parnikkapore at disroot.org once stated:
>
> Gravatar. (It's in the theme template)

  Ah.  Cool.

  -spc


From sean at conman.org  Fri May 29 01:55:45 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 28 May 2020 20:55:45 -0400
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
Message-ID: <20200529005545.GW23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On May 29, 2020, at 01:29, Luke Emmet <luke.emmet at gmail.com> wrote:
> > 
> >> E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ??
> > Huh - that is cute. These Urbit avatars are quite attractive. I think
> > they spent quite a bit of time on the graphic design of that engine.
> 
> Yeah, pretty nifty actually.
> 
> Like their 'phonemic naming system' as well (the 4028369029 to ~lapryt-fidse bit):

  First off, it should be ~lapryt-fidseg.  Secondly, how do you get
~4028369029 from gemini.circumlunar.space?  I either get taplux~ligsef or
~~rocpel~ladtuc, depending on if I use bit-endian or
little-endian on the IP address (as a 32-bit quantity).

> https://urbit.org/understanding-urbit/urbit-id/
> https://github.com/urbit/urbit-ob/blob/master/src/internal/co.js
> https://github.com/urbit/sigil-js
> 
> It's a bit of a pain to run 'out-of-the-box' if you are not into node.js,
> but I'm confidant spc will get a sweet Lua implementation in no time :)

  Heh.

  -spc (How hard could it be?)


From petite.abeille at gmail.com  Fri May 29 02:12:34 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 03:12:34 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <20200529005545.GW23998@brevard.conman.org>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200529005545.GW23998@brevard.conman.org>
Message-ID: <6768A790-900B-4A19-88FF-A95F1BFC3B48@gmail.com>



> On May 29, 2020, at 02:55, Sean Conner <sean at conman.org> wrote:
> 
>  First off, it should be ~lapryt-fidseg.  Secondly, how do you get
> ~4028369029 from gemini.circumlunar.space?  I either get taplux~ligsef or
> ~~rocpel~ladtuc, depending on if I use bit-endian or
> little-endian on the IP address (as a 32-bit quantity).

Using the first few bytes of the sha3.sha256 of the domain.

With the IP address:

gemini.circumlunar.space ? 168.235.111.58 ? 2834001722 ? ~taplux-ligsef ? sigil


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigil.svg
Type: image/svg+xml
Size: 2922 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/f05bb26b/attachment.svg>
-------------- next part --------------




From invis at park-city.club  Fri May 29 02:13:29 2020
From: invis at park-city.club (InvisibleUp)
Date: Thu, 28 May 2020 21:13:29 -0400
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <5ECF9EDF.90607@gmail.com>
References: <5ECF9EDF.90607@gmail.com>
Message-ID: <61e3a392-776e-3f01-2d2a-83248c54ebfa@park-city.club>

I see my own browser Twin Peaks has some competition. :p

Nah, it's good to see some more user-friendly Gemini clients out there. 
There's a lot about yours that I really like. The themes, the document 
title in the titlebar, and especially the "Fabric" theme with it's 
automatic patterns are all super nice. I'm absolutely going to have to 
borrow some from this. We're both using C# under the GPLv3, and we both 
took the approach of rendering Gemini to a web browser view, so I 
imagine we could definitely share a lot of code.

I can't wait to see what more comes of this.


-- Email domain proudly hosted at https://migadu.com


From petite.abeille at gmail.com  Fri May 29 02:28:22 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 03:28:22 +0200
Subject: Cognitive aspects of navigation in gemini space
In-Reply-To: <6768A790-900B-4A19-88FF-A95F1BFC3B48@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200529005545.GW23998@brevard.conman.org>
 <6768A790-900B-4A19-88FF-A95F1BFC3B48@gmail.com>
Message-ID: <0F24AE36-49DC-4209-BFED-CA8F1B373C2B@gmail.com>



> On May 29, 2020, at 03:12, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Using the first few bytes of the sha3.sha256 of the domain.
> 

Actually, the certificate serial number could be a seed as well, e.g.:

tonumber( ( '03AFB22DF61DC72291F4B7C3745572BB7F4F' ):sub( 1, 8 ), 16 ) ? 61846061 ? ~wantun-linbyn? sigil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigil.svg
Type: image/svg+xml
Size: 2734 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/e35e46b4/attachment-0001.svg>

From invis at park-city.club  Fri May 29 02:33:44 2020
From: invis at park-city.club (InvisibleUp)
Date: Thu, 28 May 2020 21:33:44 -0400
Subject: Possibly silly text/gemini spec suggestion: Frames
Message-ID: <02b01942-e9af-8c4d-2ce7-643645790220@park-city.club>

I had an idea for a new line type for the text/gemini document type.I'm 
not sure how attached I am to it, or how well it would be received,but I 
figure it would at least be worth mentioning here.

"Frames" are a way to create collapsible "sections" of a Gemini 
document. In graphical browsers I imagine these would be arranged 
horizontally, but they would be perfectly readable vertically as well.

Proposed syntax:
||| denotes the start or end of a frame
|?? (or any non-'|' characters after the first '|') denotes a new frame 
section
--- denotes a vertical/same section division in a frame section

A very good example of this would be a navigation bar. For example,

# Page Title
|||||||||||||||||

=> ../ Back
=> page1/ Page 1
=> page2/ Page 2
=> page3/ Page 3

| | | | | | | | |

## Article Title
2020-05-28
-----------------

Article contents
...

|||||||||||||||||
Footer text


This is perfectly readable on a dumb terminal display, but on a TUI/GUI 
browserit may look something like this:

# Page Title
 ??? -----------------------------
 ??? => Back?? | ## Article Title
 ??? => Page 1 | 2020-05-28
 ??? => Page 2 |------------------
 ??? => Page 3 | Article contents
 ? ?? ???????? | ...
 ??? -----------------------------
 ??? Footer text

With this example, it may be a better idea to place the links at the 
*end*of the document, resulting in a right sidebar. This keeps the 
navigation fromencroaching onto the document contents in a vertical 
view. Left sidebars should
be short, sweet, and simple.

The user should be able to collapse the navigation component, if they 
choose.They may also choose to display it vertically. Perhaps frame 
sections consistingsolely of links could also display the links in a 
line, at the client'sdiscretion.

This could also be used inline in a standard document, for figures w/ 
captiontext, poetry next to ASCII art w/ alt-text, etc.

Note that you cannot nest a frame within another frame. This vastly 
simplifiesthe syntax and implementation, as well as discouraging future 
extensions.

Another idea for layout:

 ??? |||
 ??? # Article Title
 ??? 2020-05-28
 ??? |
 ??? => ../ All
 ??? => next/ Next
 ??? => prev/ Previous
 ??? |||
Article contents
...

which could be displayed as

# Article Title | => All
 ??? 2020-05-28 ? ?? | => Next
 ?? ? ?? ??????????? | => Previous
 ??? ------------------------------
 ??? Article contents
 ??? ...

I kinda like it, but I can definitely see the arguments against it. Let 
me know what you think of this.

-- InvisibleUp <gemini://park-city.club/~invis>

-- Email domain proudly hosted at https://migadu.com


From petite.abeille at gmail.com  Fri May 29 03:10:40 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 04:10:40 +0200
Subject: <META> overloading...
Message-ID: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>

Presently, a successful status code may look like:

20 text/gemini; charset=utf-8

Would it be reasonable to consider the structure of <META> as equivalent to a modernized MIME header?

We already have the charset, so... as we have 1024 bytes to play with...

... we could add a couple of further information such as Content-Length [1], Content-Disposition [2], Content-Language [3], and Date[4]..

Perhaps something like this:

20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US

A slim 107 bytes altogether. All optional. 

Heresy?

-- 
PA

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language
[4] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date


From sean at conman.org  Fri May 29 03:19:39 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 28 May 2020 22:19:39 -0400
Subject: <META> overloading...
In-Reply-To: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
Message-ID: <20200529021939.GY23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> Presently, a successful status code may look like:
> 
> 20 text/gemini; charset=utf-8
> 
> Would it be reasonable to consider the structure of <META> as equivalent to a modernized MIME header?
> 
> We already have the charset, so... as we have 1024 bytes to play with...
> 
> ... we could add a couple of further information such as Content-Length [1], Content-Disposition [2], Content-Language [3], and Date[4]..
> 
> Perhaps something like this:
> 
> 20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US
> 
> A slim 107 bytes altogether. All optional. 
> 
> Heresy?

  I previously proposed the filesize for this, and solderpunk rejected that
(reasoning here: https://lists.orbitalfox.eu/archives/gemini/2020/000808.html).
And I'm not a fan at all of Content-Disposition because of the way web
browsers implement it (no!  I don't want to save that!  I want to *see* it! 
Let me see it in the browser!).  I think language will pass, but that's
about it ...

  -spc

From parnikkapore at disroot.org  Fri May 29 03:22:31 2020
From: parnikkapore at disroot.org (parnikkapore at disroot.org)
Date: Fri, 29 May 2020 09:22:31 +0700
Subject: Possibly silly text/gemini spec suggestion: Frames
In-Reply-To: <02b01942-e9af-8c4d-2ce7-643645790220@park-city.club>
Message-ID: <a0da5f21-5570-46e2-bacf-ed634f6f52db@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/1cb2abc5/attachment.htm>

From petite.abeille at gmail.com  Fri May 29 03:34:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 04:34:04 +0200
Subject: <META> overloading...
In-Reply-To: <20200529021939.GY23998@brevard.conman.org>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529021939.GY23998@brevard.conman.org>
Message-ID: <44E3F688-6892-48A8-99F8-5EA80D77EBFD@gmail.com>



> On May 29, 2020, at 04:19, Sean Conner <sean at conman.org> wrote:
> 
>  I previously proposed the filesize for this, and solderpunk rejected that

Well, the thing is, as soon as we open the door for semicolons in what is effectively the content-type header, then... we open the floodgates to extensions. The whole 1024 bytes of them :) 

You mentioned it yourself nearly a year ago:

"The MIME type that is returned can have parameters, and these parameters can act as small headers"
-- File size issues, Sean Conner, August 18 2019

https://lists.orbitalfox.eu/archives/gemini/2019/000045.html

What's the current thinking one year on?

-- 
PA

From petite.abeille at gmail.com  Fri May 29 03:49:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 04:49:31 +0200
Subject: <META> overloading...
In-Reply-To: <20200529021939.GY23998@brevard.conman.org>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529021939.GY23998@brevard.conman.org>
Message-ID: <DE3EB1D3-5942-4B4F-81D4-046FD6D02803@gmail.com>



> On May 29, 2020, at 04:19, Sean Conner <sean at conman.org> wrote:
> 
> (reasoning here: https://lists.orbitalfox.eu/archives/gemini/2020/000808.html).

"Someone is bound to ask: "Oh, does this mean text/gemini; content-size=1234 is okay, too?".  No!"
-- solderpunk, Cognitive aspects of navigation in gemini space, May 18 2020

Fair enough.

The information I'm really after is a date byline [1]. 

In the same way as text is not just a collection of bytes, but have an actual language, they are also anchored in time, not just floating in the ether, timeless.

[1] https://en.wikipedia.org/wiki/Dateline

 


From sean at conman.org  Fri May 29 03:49:38 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 28 May 2020 22:49:38 -0400
Subject: <META> overloading...
In-Reply-To: <44E3F688-6892-48A8-99F8-5EA80D77EBFD@gmail.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529021939.GY23998@brevard.conman.org>
 <44E3F688-6892-48A8-99F8-5EA80D77EBFD@gmail.com>
Message-ID: <20200529024938.GZ23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On May 29, 2020, at 04:19, Sean Conner <sean at conman.org> wrote:
> > 
> >  I previously proposed the filesize for this, and solderpunk rejected that
> 
> Well, the thing is, as soon as we open the door for semicolons in what is
> effectively the content-type header, then... we open the floodgates to
> extensions. The whole 1024 bytes of them :)
> 
> You mentioned it yourself nearly a year ago:
> 
> "The MIME type that is returned can have parameters, and these parameters
> can act as small headers"
> -- File size issues, Sean Conner, August 18 2019
> 
> https://lists.orbitalfox.eu/archives/gemini/2019/000045.html
> 
> What's the current thinking one year on?

  I still feel the same way, and I don't have an issue with this.  We'll
have to see what solderpunk thinks of this.

  -spc


From martin at no.ucant.org  Fri May 29 04:11:02 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Fri, 29 May 2020 04:11:02 +0100 (BST)
Subject: <META> overloading...
In-Reply-To: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
Message-ID: <alpine.DEB.2.20.2005290407570.18317@pling.qwghlm.org>

On Fri, 29 May 2020, Petite Abeille wrote:

> 20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US
>
> A slim 107 bytes altogether. All optional.

It's not really the length that's the issue for me. Why not

20 text/gemini; execute-js=true; utm_term=sexual+health+checkup;
    cookie=U29tZSBhcmJpdHJhcnkgY29va2llIHRleHQK

etc, etc?

Mk

From poomklao at yahoo.com  Fri May 29 04:18:48 2020
From: poomklao at yahoo.com (poomklao at yahoo.com)
Date: Fri, 29 May 2020 10:18:48 +0700
Subject: More silly text/gemini spec proposals
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
Message-ID: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/5acaa3d7/attachment.htm>

From petite.abeille at gmail.com  Fri May 29 04:26:23 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 05:26:23 +0200
Subject: <META> overloading...
In-Reply-To: <alpine.DEB.2.20.2005290407570.18317@pling.qwghlm.org>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <alpine.DEB.2.20.2005290407570.18317@pling.qwghlm.org>
Message-ID: <F39F67EB-62D4-49E9-9FD4-1C6EE40E433E@gmail.com>



> On May 29, 2020, at 05:11, Martin Keegan <martin at no.ucant.org> wrote:
> 
> It's not really the length that's the issue for me. Why not
> 
> 20 text/gemini; execute-js=true; utm_term=sexual+health+checkup;
>   cookie=U29tZSBhcmJpdHJhcnkgY29va2llIHRleHQK
> 
> etc, etc?

Sure thing. It's a MIME header. You can put anything in it. The main difference with TheProtocolThatShallNotBeNamed is that such line noise will just end up in /dev/null as there is no one to look, nor act, on it. 

On the other hand, if you put such nice  utm_term in the Gemini request or in a text/gemini link line... that would be another can of worms altogether :)



From petite.abeille at gmail.com  Fri May 29 04:33:49 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 05:33:49 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
Message-ID: <EFB65B5B-C116-417D-82D1-B1E50C9E2441@gmail.com>



> On May 29, 2020, at 05:18, poomklao at yahoo.com wrote:
> 
> # Images
> 
> Elegant form:
> IMG /static/fun.png "Alt text to display if you're in a terminal"

Talking of which... what about Data URLs [1] in text/gemini link lines?

Kosher? How are they meant to be handled? Inline? As attachment? Verboten?


[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs

From petite.abeille at gmail.com  Fri May 29 04:46:27 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 05:46:27 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
Message-ID: <D931BA41-8B5C-4DAD-BA35-B77AA25B3E1D@gmail.com>



> On May 29, 2020, at 05:18, poomklao at yahoo.com wrote:
> 
> # Blockquotes
> 
> Pretty much the same as in Markdown:
> 
> >> Gemini is a new, collaboratively designed internet protocol, which explores the space in between gopher and the web.
> >>
> >> It strives to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other.
> > I think we need to be careful, because we could very well
> >
> > uh
> >
> > inherit the worst of both of them

Ehehe! :D

Actually, blockquotes (or should it be linequotes?), are more in the spirit of text/gemini line oriented format. 

And they predate markdown  by a a good decade, or two, or three:

https://en.wikipedia.org/wiki/Posting_style#Quoted_line_prefix
https://en.wikipedia.org/wiki/Usenet_quoting



From poomklao at yahoo.com  Fri May 29 05:12:22 2020
From: poomklao at yahoo.com (poomklao at yahoo.com)
Date: Fri, 29 May 2020 11:12:22 +0700
Subject: <META> overloading...
In-Reply-To: <F39F67EB-62D4-49E9-9FD4-1C6EE40E433E@gmail.com>
References: <2687f3a0-9584-409e-bb7f-874b8ad5aa62.ref@email.android.com>
Message-ID: <2687f3a0-9584-409e-bb7f-874b8ad5aa62@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/1377cc7d/attachment.htm>

From poomklao at yahoo.com  Fri May 29 05:20:12 2020
From: poomklao at yahoo.com (poomklao at yahoo.com)
Date: Fri, 29 May 2020 11:20:12 +0700
Subject: More silly text/gemini spec proposals
In-Reply-To: <EFB65B5B-C116-417D-82D1-B1E50C9E2441@gmail.com>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
Message-ID: <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/06aeb3df/attachment-0001.htm>

From petite.abeille at gmail.com  Fri May 29 05:34:29 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 06:34:29 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
Message-ID: <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>



> On May 29, 2020, at 06:20, poomklao at yahoo.com wrote:
> 
> Gar nicht verboten.
> 
> => gemini://gemini.conman.org/test/torture/0021

Ohhh...  shiny! 

data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D

Let's see what else is hiding in those marvelous URI schemes:

https://en.wikipedia.org/wiki/List_of_URI_schemes






From sean at conman.org  Fri May 29 06:08:50 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 01:08:50 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <EFB65B5B-C116-417D-82D1-B1E50C9E2441@gmail.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <EFB65B5B-C116-417D-82D1-B1E50C9E2441@gmail.com>
Message-ID: <20200529050849.GA23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On May 29, 2020, at 05:18, poomklao at yahoo.com wrote:
> > 
> > # Images
> > 
> > Elegant form:
> > IMG /static/fun.png "Alt text to display if you're in a terminal"
> 
> Talking of which... what about Data URLs [1] in text/gemini link lines?
> 
> Kosher? How are they meant to be handled? Inline? As attachment? Verboten?

  Funny you should ask that:

	gemini://gemini.conman.org/test/torture/0021

  -spc (Expect a flurry of tests now ... )

> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs


From petite.abeille at gmail.com  Fri May 29 06:55:53 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 07:55:53 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529050849.GA23998@brevard.conman.org>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <EFB65B5B-C116-417D-82D1-B1E50C9E2441@gmail.com>
 <20200529050849.GA23998@brevard.conman.org>
Message-ID: <65648B88-2A68-4DDE-9386-1480E17758E4@gmail.com>



> On May 29, 2020, at 07:08, Sean Conner <sean at conman.org> wrote:
> 
>  Funny you should ask that:
> 
> 	gemini://gemini.conman.org/test/torture/0021
> 
>  -spc (Expect a flurry of tests now ... )

Got to say, this is a fantastic resource. Thank you very much.

For the record: torture test
https://portal.mozz.us/gemini/gemini.conman.org/test/torture/

Much excellent.

If anything, you just have superior tooling:

https://github.com/spc476/LPeg-Parsers

E.g.:

https://github.com/spc476/LPeg-Parsers/blob/master/http-client.lua

You command of lpeg is to be commanded.

For the curious:

http://www.inf.puc-rio.br/~roberto/lpeg/



From sean at conman.org  Fri May 29 07:15:13 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 02:15:13 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <65648B88-2A68-4DDE-9386-1480E17758E4@gmail.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <EFB65B5B-C116-417D-82D1-B1E50C9E2441@gmail.com>
 <20200529050849.GA23998@brevard.conman.org>
 <65648B88-2A68-4DDE-9386-1480E17758E4@gmail.com>
Message-ID: <20200529061513.GB23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On May 29, 2020, at 07:08, Sean Conner <sean at conman.org> wrote:
> > 
> >  Funny you should ask that:
> > 
> > 	gemini://gemini.conman.org/test/torture/0021
> > 
> >  -spc (Expect a flurry of tests now ... )
> 
> Got to say, this is a fantastic resource. Thank you very much.

  You're welcome.

> If anything, you just have superior tooling:
> 
> https://github.com/spc476/LPeg-Parsers
> 
> E.g.:
> 
> https://github.com/spc476/LPeg-Parsers/blob/master/http-client.lua

  Oh man ... you just happened to pick one of the parsers I haven't finished
yet [1].  The header names need to be matched case-insensitively, which they
aren't, and I haven't finished with all the headers yet.  Ah well.

> You command of lpeg is to be commanded.

  It took a few years, but I'm now at the stage were I can pretty much
answer any LPEG question out there.  I use it extensively in GLV-1.12556 as
well.

> For the curious:
> 
> http://www.inf.puc-rio.br/~roberto/lpeg/

  -spc

[1]	If it doesn't have a rockspec, it's not finished.

From plugd at thelambdalab.xyz  Fri May 29 08:13:14 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 29 May 2020 09:13:14 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
Message-ID: <lz8shbqkmt.fsf@bs-mbpr348.d.ethz.ch>

poomklao at yahoo.com writes:
> Backwards-compatible form:
> => image:/static/fun.png "Image: My cute little cat"

Please no....!

> I think that only one form should be picked, but I'm not sure
> which. Also, I know that solderpunk doesn't really like embedded
> stuff...

They're not the only one!

>I miss it form the Web though.

I get this, but honestly if there's one sure-fire way to allow corporate
branding, ads, and other evilness into gemini, I really believe it's this.

Anyway, if you want these things, you can always just serve text/html or
text/markdown over gemini.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/35517c4b/attachment.sig>

From felix at masterq32.de  Fri May 29 08:50:57 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Fri, 29 May 2020 09:50:57 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <lz8shbqkmt.fsf@bs-mbpr348.d.ethz.ch>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <lz8shbqkmt.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <25ae29e6-c36e-1dea-aec7-de94ffb5045f@masterq32.de>

> I get this, but honestly if there's one sure-fire way to allow corporate
> branding, ads, and other evilness into gemini, I really believe it's this.
> 
> Anyway, if you want these things, you can always just serve text/html or
> text/markdown over gemini.

Also, nobody forbids that a client *may* serve links to images/videos
inline instead of displaying them only as a link.

We have the freedom to do so and nobody is hurt by doing or not doing it

From felix at masterq32.de  Fri May 29 08:53:06 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Fri, 29 May 2020 09:53:06 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
Message-ID: <acf75c4d-54ea-3754-7059-1917c88f2e57@masterq32.de>

> # Blockquotes
> 
> Pretty much the same as in Markdown:
> 
>  >> Gemini is a new, collaboratively designed internet protocol, which explores 
> the space in between gopher and the web.
>  >>
>  >> It strives to address (perceived) limitations of one while avoiding the 
> (undeniable) pitfalls of the other.
>  > I think we need to be careful, because we could very well
>  >
>  > uh
>  >
>  > inherit the worst of both of them

I think block quotes may be a nice rendering extension, but are not
essential, as we can always just use the text in raw form instead of
having a defined formatting.

From southerntofu at thunix.net  Fri May 29 09:29:46 2020
From: southerntofu at thunix.net (southerntofu at thunix.net)
Date: Fri, 29 May 2020 04:29:46 -0400
Subject: Trust model for addresses and certificates (DANE etc..)
Message-ID: <20200529082946.GB302232@thunix.net>

Hey,

I've been following Gemini from afar, that's a really cool project you've got! I'm curious about the threat model with gemini and how we can increase security in ways that are not user-hostile, and do not concentrate power in the hands of third parties.

A TOFU approach to certificates (trust on first use, i.e. blind trust) can be easier to deal with, but strongly lacks any security guarantee. Especially, so far user agents of all sorts have been terrible at making a UX to inspect and verify server/peer certificates, so i think it's not so good.

DANE is a RFC that describes how to distribute TLS public keys over the DNS (+ DNSSEC). It consists of TLSA records containing the server's public key, which can also be CNAME'd to, like in the example in the spec:

      example.com.                IN MX 0 mx1.example.com.
      example.com.                IN MX 0 mx2.example.com.
      _25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.
      _25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.
      tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c149a...

Using DANE to distribute certificates reduces the attack surface, because the DNS is already a SPOF for a gemini server. I personally believe the gemini spec should strongly encourage admins to use DANE to distribute their server certificates.

A different approach to this problem is the GNU Name System, which is a DNS-compatible, fully autonomous and secure naming system: https://datatracker.ietf.org/doc/draft-schanzen-gns/

GNS has much stronger security guarantees than DNSSEC, which is ideal for bootstrapping a secure connection to a remote server. It's also entirely decentralized and name seizures are made impossible by introducing cryptographic forms of zone delegation (instead of IP-based delegation as DNS does). I would recommend people investigate it, because interpersonal concerns set aside, GNS is in my view the best proposal for a secure, censorship-free naming system.

There was a presentation at ICANN about GNS, which you can view here: https://git.gnunet.org/gnunet-videos-2019.git/plain/ICANN66/GNU_Name_System_-_2019_ICANN66__Martin_Schanzenbach.webm

I hope this message brings you food for thought. Long live the free internet, burn all prisons and borders!

From solderpunk at SDF.ORG  Fri May 29 10:24:51 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 09:24:51 +0000
Subject: <META> overloading...
In-Reply-To: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
Message-ID: <20200529092451.GA2354@SDF.ORG>

On Fri, May 29, 2020 at 04:10:40AM +0200, Petite Abeille wrote:

I can see this has triggered a thread of replies already but I only have
a little time before I need to start work so I thought I'd just reply
now to the first post without having read anything else to share my
initial and uninfluenced reaction (which I don't think will change, mind
you).

> Presently, a successful status code may look like:
> 
> 20 text/gemini; charset=utf-8
> 
> Would it be reasonable to consider the structure of <META> as equivalent to a modernized MIME header?

They're not "equivalent to a modernized MIME header", they are literally
specced as being exactly that (well, without the modernized part).  From
section 3.3:

> Response bodies only accompany responses whose header indicates a
> SUCCESS status (i.e. a status code whose first digit is 2).  For such
> responses, <META> is a MIME media type as defined in RFC 2046.

This is very deliberate!  It lets people use pre-existing machinery for
parsing MIME types to easily throw together Gemini software without
having to write any customised code.
 
> We already have the charset, so... as we have 1024 bytes to play with...

Yes, it's true we are free to define additional parameters for our media
type, and I *have* stressed out about this in the past.  However...
 
> ... we could add a couple of further information such as Content-Length [1], Content-Disposition [2], Content-Language [3], and Date[4]..
> 
> Perhaps something like this:
> 
> 20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US

...most of what is new here makes no sense whatsoever.  We are allowed
to define parameters for our media type, but we can't change the fact
that it is a *media type*.  It is information for clients about *what
kind of thing* they're about to get, so they can determine how to handle
it.  It is *category* information.  "English text with Gemini line
types" is a sensible category.  There can be infinitely many documents
in that category and it makes sense for a user agent to treat them all
identically, and to perhaps treat them a little differently from "Arabic
text with Gemini line types" (by rendering text LTR instead of RTL).
Those are genuine "types of stuff".  But "28102 bytes of English text
with Gemini line types written three days ago with the title
Speculative specification" isn't a "type of stuff".  It's not a sensible
category.  Information which is unique to a particular document is just
wholly inappropriate in a MIME media type, it's not the place for it.

I'm definitely not going to spec any parameters for text/gemini which I
don't feel fit with the semantics of what a media type is.  It's true
that I can't stop servers from doing this (and the MIME RFC clearly says
that clients must ignore parameters they don't recognise, so I can't
even recommend that clients refuse to handle responses which do this as
a kind of defensive measure).  I hope people will be disuaded from doing
this not just by virtue of it being against my wishes for and the
intended spirit of Gemini, but also because it completely and clearly
violates the intent of a much older and more established piece of
internet infrastructure.  It's double wrong!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri May 29 10:35:20 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 09:35:20 +0000
Subject: More silly text/gemini spec proposals
In-Reply-To: <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
Message-ID: <20200529093520.GB2354@SDF.ORG>

On Fri, May 29, 2020 at 06:34:29AM +0200, Petite Abeille wrote:
 
> Ohhh...  shiny! 
> 
> data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D
> 
> Let's see what else is hiding in those marvelous URI schemes:

...let's not take delight in actively trying to crush the spirit of this
thing?  I mean, the web is right there if that's what you want.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Fri May 29 12:03:26 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 13:03:26 +0200
Subject: <META> overloading...
In-Reply-To: <20200529092451.GA2354@SDF.ORG>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
Message-ID: <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>



> On May 29, 2020, at 11:24, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> It's double wrong!

Fair enough ??

This leaves link lines:

=>data:,Hello%2C%20World!
=>data:message/rfc822;base64, ...
=>data:multipart/mixed; boundary=--8<--;base64, ...
=>dict://dict.org/d:shortcake:
=>fax:+3585551234567
=>feed:https://example.com/entries.atom
=>geo:13.4125,103.8667
=>mailto:someone at example.com
=>sms:+15105550101
=>tag:example.com,2004:1234
=>tel:+12125551234

Those could be nicely rendered, perhaps in some creative, interesting, and weird ways. Time will tell.



From solderpunk at SDF.ORG  Fri May 29 14:15:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 13:15:33 +0000
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529093520.GB2354@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG>
Message-ID: <20200529131533.GA21134@SDF.ORG>

On Fri, May 29, 2020 at 09:35:20AM +0000, solderpunk wrote:
> On Fri, May 29, 2020 at 06:34:29AM +0200, Petite Abeille wrote:
>  
> > Ohhh...  shiny! 
> > 
> > data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D
> > 
> > Let's see what else is hiding in those marvelous URI schemes:
> 
> ...let's not take delight in actively trying to crush the spirit of this
> thing?  I mean, the web is right there if that's what you want.

Ugh, sorry about this email.  I was irritable from a lack of good sleep
and waking up to a whole slew of posts here about extra complications,
just as I was starting to feel we were at last approaching a kind of
"cross the t's and dot the lowercase j's" state where there wasn't much
left to add.  But I have no idea what your intended tone was and it may
well have just been tongue in cheek.  Mostly I was just annoyed at
learning that these data:// URLs exist.  I hadn't been aware of them.
And frankly...what the hell?  Who thought it was a good idea to turn a
harmless way to indicate *where* some data can be found into a way to
shoehorn in the data itself?  What are we supposed to use in a context
where we don't want that to be a possibility?  Bah!

Cheers,
Solderpunk

From petite.abeille at gmail.com  Fri May 29 14:50:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 15:50:28 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529131533.GA21134@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
Message-ID: <C5D34AD8-1B2E-45A9-94E7-38AE5852354B@gmail.com>


> On May 29, 2020, at 15:15, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Ugh, sorry about this email.  

No worries.

> I was irritable from a lack of good sleep
> and waking up to a whole slew of posts here about extra complications,
> just as I was starting to feel we were at last approaching a kind of
> "cross the t's and dot the lowercase j's" state where there wasn't much
> left to add.  But I have no idea what your intended tone was and it may
> well have just been tongue in cheek.

Just kicking the tires, I actually do like retro tech  ?? 

No harm intended.

>  Mostly I was just annoyed at
> learning that these data:// URLs exist.  I hadn't been aware of them.
> And frankly...what the hell?  Who thought it was a good idea to turn a
> harmless way to indicate *where* some data can be found into a way to
> shoehorn in the data itself?

Larry Masinter
Internet pioneer and ACM Fellow ??
https://en.wikipedia.org/wiki/Larry_Masinter

? RFC 1737 Functional Requirements for Uniform Resource Names (K. Sollins, L. Masinter)
? RFC 1738 Uniform Resource Locators (URL) (T. Berners-Lee, L. Masinter, M. McCahill)
? RFC 1867 Form-based File Upload in HTML (E. Nebel, L. Masinter)
? RFC 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (L. Masinter)
? RFC 2368 The mailto URL scheme (P. Hoffman, L. Masinter, J. Zawinski)
? RFC 2388 Returning Values from Forms: multipart/form-data (L. Masinter)
? RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter)
? RFC 2397 The "data" URL scheme (L. Masinter)
? RFC 2532 Extended Facsimile Using Internet Mail (L. Masinter, D. Wing)
? RFC 2534 Media Features for Display, Print, and Fax (L. Masinter, D. Wing, A. Mutz, K. Holtman)
? RFC 2542 Terminology and Goals for Internet Fax (L. Masinter)
? RFC 2616 Hypertext Transfer Protocol?HTTP/1.1 (R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee)
? RFC 2718 Guidelines for new URL Schemes (L. Masinter, H. Alvestrand, D. Zigmond, R. Petke)
? RFC 2732 Format for Literal IPv6 Addresses in URL's (R. Hinden, B. Carpenter, L. Masinter)
? RFC 2854 The 'text/html' Media Type (D. Connolly, L. Masinter)
? RFC 2938 Identifying Composite Media Features (G. Klyne, L. Masinter)
? RFC 2972 Context and Goals for Common Name Resolution (N. Popp, M. Mealling, L. Masinter, K. Sollins)
? RFC 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols (S. Hollenbeck, M. Rose, L. Masinter)
? RFC 3553 An IETF URN Sub-namespace for Registered Protocol Parameters (M. Mealling, L. Masinter, T. Hardie, G. Klyne)
? RFC 3778 The application/pdf Media Type (E. Taft, J. Pravetz, S. Zilles, L. Masinter)
? RFC 3986 Uniform Resource Identifier (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter)
? RFC 4395 Guidelines and Registration Procedures for New URI Schemes (T. Hansen, T. Hardie, L. Masinter)
? RFC 6068 The 'mailto' URI Scheme (M. Duerst, L. Masinter, J. Zawinski)
? RFC 7578 Returning Values from Forms: multipart/form-data (L. Masinter)
? RFC 7995 PDF Format for RFCs (L. Masinter)

> What are we supposed to use in a context
> where we don't want that to be a possibility?  Bah!

5.3.2 Link lines is arguably the best feature of Gemini. With TLS. Less is more, love it.

But of course, at the same time, it opens the door to creative tampering of sort.

On the other hand, the destructive creativity will be limited to the client side. 

And may never gain traction in practice. Supply & demand & all.

All in the spirit of Gemini:

Clients can present links to users in whatever fashion the client author wishes.

In term of damage control, we could perhaps arbitrary limit link lines' length to 1024 bytes, similarly to 2 Gemini requests.

This will not discourage miscreant from using, like, *two* lines for their misdeeds,  but at least the protocol itself would have made the point -loud and clear- about how it feels about it.

Either way, nothing to lose sleep over.

"Great job, team. Head back to base for debriefing and cocktails. "
-- Spottswoode, Team America: World Police, 2004


-- 
PA






 






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/05c9ad5c/attachment.htm>

From jmcbray at carcosa.net  Fri May 29 14:56:44 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 29 May 2020 09:56:44 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529131533.GA21134@SDF.ORG> (solderpunk@sdf.org's message of
 "Fri, 29 May 2020 13:15:33 +0000")
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
Message-ID: <87blm6n8tf.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

>  Mostly I was just annoyed at learning that these data:// URLs exist.
> I hadn't been aware of them. And frankly...what the hell? Who thought
> it was a good idea to turn a harmless way to indicate *where* some
> data can be found into a way to shoehorn in the data itself? What are
> we supposed to use in a context where we don't want that to be a
> possibility? Bah!

On the web, they make sense as a way of inlining short content, like
icons, and avoiding a server round-trip. But obviously, they don't make
sense for Gemini, and there's no reason clients should support them.

If you want lolcats, just link to the image file. I do it all the time
in my gemlogs.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Fri May 29 15:01:51 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 29 May 2020 10:01:51 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 (poomklao@yahoo.com's message of "Fri, 29 May 2020 10:18:48 +0700")
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
Message-ID: <877dwun8kw.fsf@dorothy.carcosa.net>

poomklao at yahoo.com writes:

> I think that only one form should be picked, but I'm not sure which.
> Also, I know that solderpunk doesn't really like embedded stuff... I
> miss it form the Web though.

Inline images break the principle of "one request per page". I was there
when inline images were added to HTML, and while I was excited at the
time, in retrospect, that's where things started to go pear shaped.

> # Blockquotes
>
> Pretty much the same as in Markdown:

I actually really want blockquotes (pretty much the same as in Usenet,
as someone else pointed out). My only concern is how they might
complicate implementing line wrapping. I also think they should not be
nestable. 

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Fri May 29 15:08:04 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 29 May 2020 10:08:04 -0400
Subject: Trust model for addresses and certificates (DANE etc..)
In-Reply-To: <20200529082946.GB302232@thunix.net> (southerntofu@thunix.net's
 message of "Fri, 29 May 2020 04:29:46 -0400")
References: <20200529082946.GB302232@thunix.net>
Message-ID: <87367in8aj.fsf@dorothy.carcosa.net>

southerntofu at thunix.net writes:

> Using DANE to distribute certificates reduces the attack surface, because the
> DNS is already a SPOF for a gemini server. I personally believe the gemini spec
> should strongly encourage admins to use DANE to distribute their server
> certificates.

Could you provide a minimal sample implementation of how a client would
implement this? Just to demonstrate feasibility and to provide a guide
to other client authors?

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From colecmac at protonmail.com  Fri May 29 15:34:52 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 29 May 2020 14:34:52 +0000
Subject: Possibly silly text/gemini spec suggestion: Frames
In-Reply-To: <02b01942-e9af-8c4d-2ce7-643645790220@park-city.club>
References: <02b01942-e9af-8c4d-2ce7-643645790220@park-city.club>
Message-ID: <FSe0LlbQ5scjnVmz-Sd96XvuKMUx4t2LB-lLY9GWGdcieIMaKnykEA6D113Ciqa0Fipj_EzSagwSf07GOC3_zauejLy2YdDLmDTGyF4kDA8=@protonmail.com>

Couldn't nice clients do this already, just using the heading and
preformatted blocks? That keeps thing simple but still allow for this
kind of functionality. I'm picturing something like what Wikipedia
looks like on mobile.

makeworld

??????? Original Message ???????
On Thursday, May 28, 2020 9:33 PM, InvisibleUp <invis at park-city.club> wrote:

> I had an idea for a new line type for the text/gemini document type.I'm
> not sure how attached I am to it, or how well it would be received,but I
> figure it would at least be worth mentioning here.
>
> "Frames" are a way to create collapsible "sections" of a Gemini
> document. In graphical browsers I imagine these would be arranged
> horizontally, but they would be perfectly readable vertically as well.
>
> Proposed syntax:
> ||| denotes the start or end of a frame
> |?? (or any non-'|' characters after the first '|') denotes a new frame
> section
> --- denotes a vertical/same section division in a frame section
>
> A very good example of this would be a navigation bar. For example,
>
> Page Title
>
> ===========
>
> |||||||||||||||||
>
> => ../ Back
> => page1/ Page 1
> => page2/ Page 2
> => page3/ Page 3
>
> | | | | | | | | |
>
> Article Title
>
> --------------
>
> 2020-05-28
>
> -----------
>
> Article contents
> ...
>
> |||||||||||||||||
> Footer text
>
> This is perfectly readable on a dumb terminal display, but on a TUI/GUI
> browserit may look something like this:
>
> Page Title
>
> ===========
>
> -----------------------------
> ??? => Back?? | ## Article Title
> => Page 1 | 2020-05-28
> => Page 2 |------------------
> => Page 3 | Article contents
> | ...
> ??? -----------------------------
> ??? Footer text
>
> With this example, it may be a better idea to place the links at the
> endof the document, resulting in a right sidebar. This keeps the
> navigation fromencroaching onto the document contents in a vertical
> view. Left sidebars should
> be short, sweet, and simple.
>
> The user should be able to collapse the navigation component, if they
> choose.They may also choose to display it vertically. Perhaps frame
> sections consistingsolely of links could also display the links in a
> line, at the client'sdiscretion.
>
> This could also be used inline in a standard document, for figures w/
> captiontext, poetry next to ASCII art w/ alt-text, etc.
>
> Note that you cannot nest a frame within another frame. This vastly
> simplifiesthe syntax and implementation, as well as discouraging future
> extensions.
>
> Another idea for layout:
>
> ??? |||
> ??? # Article Title
> ??? 2020-05-28
> ??? |
> ??? => ../ All
> => next/ Next
> => prev/ Previous
> |||
> Article contents
> ...
>
> which could be displayed as
>
> Article Title | => All
>
> =======================
>
> 2020-05-28 ? ?? | => Next
> | => Previous
> ------------------------------
> ??? Article contents
> ??? ...
>
> I kinda like it, but I can definitely see the arguments against it. Let
> me know what you think of this.
>
> -- InvisibleUp gemini://park-city.club/~invis
>
> -- Email domain proudly hosted athttps://migadu.com



From solderpunk at SDF.ORG  Fri May 29 15:42:49 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 14:42:49 +0000
Subject: More silly text/gemini spec proposals
In-Reply-To: <87blm6n8tf.fsf@dorothy.carcosa.net>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net>
Message-ID: <20200529144249.GA28953@SDF.ORG>

On Fri, May 29, 2020 at 09:56:44AM -0400, Jason McBrayer wrote:
 
> On the web, they make sense as a way of inlining short content, like
> icons, and avoiding a server round-trip. But obviously, they don't make
> sense for Gemini, and there's no reason clients should support them.

There's no reason they *should*, but they can.  And some of them will.
And then people will think of this as normal and expect it and design
their documents around it, and the snowball will roll...

I tried *so* hard to avoid this, but you just can't.  This data:// URL
thing is a monster.  No RFC puts a limit on the allowed length of a URL.
And the data:// scheme includes MIME types.  So they are a vehicle for
arbitrary content of arbitrary size.  Turns out this entire time Gemini
- and even it's hypothetical deliberately stripped-back cousin Mercury -
has allowed embedding of inline images, audio and videos.  It's just
impossible to avoid this stuff unless you throw out URLs entirely and
start with something else, in which case the effort to learn the spec
and implement it skyrockets because you can't leverage existing
knowledge and code.  I was naive to think the internet was made out of
little do-one-thing-and-do-it-well components you could compose in novel
ways to build things of deliberately limited scope.  Turns out it's made
of a few massively overpowered blobs and it's impossible to build
anything small.

Yes, alright, to some extent abuse of this loophole will be limited by
the fact that all this content has to be downloaded in a single file in
a single transaction before any of it can be displayed, so the user
experience will be miserable if there is more than just a little bit of
embedded content.  We won't quite end up as bad as the web.  But still!
This is just unspeakably frustrating.

Cheers,
Solderpunk

From tomasino at lavabit.com  Fri May 29 15:51:16 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 29 May 2020 14:51:16 +0000
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529144249.GA28953@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
Message-ID: <cfe6e856-f4f6-5d91-3623-aa27d2d78a8f@lavabit.com>

On 5/29/20 2:42 PM, solderpunk wrote:
> I tried *so* hard to avoid this, but you just can't.

Perhaps I'm missing something, but I don't think we've got a really big
problem here. Links can link to anything; sure, but a client deciding to
inline their display will create a monster of a user experience even if
they try to do it with simple images. There's no sizing at work. There's
no positioning available. If a site tries to very carefully link to
images in a way designed to be inlined, a hundred more will not be doing
that. The client's attempts to display those things will break browsing
for its users and, hopefully, not gain popularity.

If someone wants to do something edge-casey that only works in very
specific situations then cool. I don't see it as a threat to gemini
because of the guardrails you already have in place.


From solderpunk at SDF.ORG  Fri May 29 15:53:32 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 14:53:32 +0000
Subject: Trust model for addresses and certificates (DANE etc..)
In-Reply-To: <20200529082946.GB302232@thunix.net>
References: <20200529082946.GB302232@thunix.net>
Message-ID: <20200529145332.GB28953@SDF.ORG>

On Fri, May 29, 2020 at 04:29:46AM -0400, southerntofu at thunix.net wrote:
> Hey,

Hey!

I'm too bummed out over this data:// URL nonsense to give a detailed
response to this right now, but let me quickly say:  I am a big fan of
DANE, and I'm aware of an unhappy about the sad state of affairs which
is DNS security.  I'm very reluctant to spec any of it because the
implementation burden is *heavy*, but I have big plans to stick all
kinds of stuff into AV-98 in the future to reduce the risk associated
with the initial TOFU acceptance.  This includes looking for DANE
records (ideally over DNScrypt, so that even in the absence of DNSSEC
there is *some* extra security - and, yes, I realise that DNScrypt and
DNSsec provide very different kinds of security) and also various ideas
riffing on the old Perspectives project.  Hell, I'm even curious about
DNS-over-Gemini.  I'll write about all this in due time.

Cheers,
Solderpunk

From martin at no.ucant.org  Fri May 29 15:55:21 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Fri, 29 May 2020 15:55:21 +0100 (BST)
Subject: <META> overloading...
In-Reply-To: <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
 <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
Message-ID: <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>

On Fri, 29 May 2020, Petite Abeille wrote:

> Those could be nicely rendered, perhaps in some creative, interesting, and weird ways. Time will tell.

Good catch. I think we need to rule out the equivalent of

=> data:text/javascript,(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');ga('create', 'UA-XXXXX-Y', 'auto');ga('send', 'pageview');

or it compromises one of key benefits of Gemini.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From colecmac at protonmail.com  Fri May 29 16:10:30 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 29 May 2020 15:10:30 +0000
Subject: <META> overloading...
In-Reply-To: <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
 <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
 <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>
Message-ID: <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>

> I think we need to rule out the equivalent of

All existing clients rule this out, I don't see the issue. As long as
clients continue not to execute arbitrary Javascript, it should be fine.


makeworld

??????? Original Message ???????
On Friday, May 29, 2020 10:55 AM, Martin Keegan <martin at no.ucant.org> wrote:

> On Fri, 29 May 2020, Petite Abeille wrote:
>
> > Those could be nicely rendered, perhaps in some creative, interesting, and weird ways. Time will tell.
>
> Good catch. I think we need to rule out the equivalent of
>
> => data:text/javascript,(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
>
> (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
> })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');ga('create', 'UA-XXXXX-Y', 'auto');ga('send', 'pageview');
>
> or it compromises one of key benefits of Gemini.
>
> Mk
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/



From tomasino at lavabit.com  Fri May 29 16:17:49 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 29 May 2020 15:17:49 +0000
Subject: SPOOFED: Re: <META> overloading...
In-Reply-To: <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
 <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
 <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>
 <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>
Message-ID: <98bc4645-8849-ae3a-8147-198c6e3502c7@lavabit.com>

On 5/29/20 3:10 PM, colecmac at protonmail.com wrote:
>> I think we need to rule out the equivalent of
> All existing clients rule this out, I don't see the issue. As long as
> clients continue not to execute arbitrary Javascript, it should be fine.
> 
> makeworld

More-so, I think we just keep beating people over the head that
text/gemini is a text document format and links *MUST* not be prefetched
or loaded without user interaction. They should also be inspectable in
some way so the user knows where they lead.

These are security things, not a matter of convenience and pretty
display. An image link pointing to a tracking pixel shouldn't auto-load.
A data link trying to run an arbitrary script should be seen for what it is.

I'd suggest that be made extremely clear in the spec itself. *Can*
someone build a client on gemini that doesn't follow that rule? Sure!
There will be crawlers running through its space doing exactly that, but
a client for users should respect their users.


From petite.abeille at gmail.com  Fri May 29 16:43:41 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 17:43:41 +0200
Subject: SPOOFED: Re: <META> overloading...
In-Reply-To: <98bc4645-8849-ae3a-8147-198c6e3502c7@lavabit.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
 <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
 <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>
 <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>
 <98bc4645-8849-ae3a-8147-198c6e3502c7@lavabit.com>
Message-ID: <DC84B472-6603-42CC-9483-EF10A2CF55ED@gmail.com>



> On May 29, 2020, at 17:17, James Tomasino <tomasino at lavabit.com> wrote:
> 
> These are security things, not a matter of convenience and pretty
> display. An image link pointing to a tracking pixel shouldn't auto-load.
> A data link trying to run an arbitrary script should be seen for what it is.

Right. That said, where does the content originate from? The users themselves. For their own convenience, supposedly. 

Hopefully they will not poison themselves with toxic content.

But, if they choose to, well, then, it's their own deliberate  choice. Medical advise be damned.

Have a large serving of metaphorical chloroquine with that thought :P

"As a scientist, you have a loyalty to reason. It makes you a little untrustworthy.?
-- General Mark Naird, Space Force, 2020

-- 
PA

From solderpunk at SDF.ORG  Fri May 29 16:45:17 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 15:45:17 +0000
Subject: <META> overloading...
In-Reply-To: <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
 <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
 <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>
 <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>
Message-ID: <20200529154517.GC28953@SDF.ORG>

On Fri, May 29, 2020 at 03:10:30PM +0000, colecmac at protonmail.com wrote:
> > I think we need to rule out the equivalent of
> 
> All existing clients rule this out, I don't see the issue. As long as
> clients continue not to execute arbitrary Javascript, it should be fine.

The issue is that the history of the web demonstrates that the most
powerful/inclusive interpretation of a spec tends to become the only
acceptable implementation over a long enough timeline.  Everybody builds
their content for that interpretation, and more conservative clients
come to be considered "broken".  It's like trying to surf the modern web
with cookies and JS turned off: nothing works.  The only hope is to
design specs where the most powerful interpretation is within acceptable
limits.  Which seems to me to be impossible in a world where URLs can be
harmless pointers to network resources *or* arbitrarily large chunks of
data of arbitrary but unamiguous type.

In that crazy world, our only hope is a strong cultural norm of "No,
don't do that!".  It's true that maybe that will work better for Gemini
than it did for the web, because, you know, the web is actually there
alongside Gemini and people who really want the worst of the web will
just stick with it and leave us alone.

But I really didn't want to just rely on politely asking people not to
do certain things, but to make it impossible or very difficult to do
them at the protocol level.  I know you can never *really* do that,
people can ignore RFCs and implement totally broken stuff and the
internet police don't come and arrest them.  But I had hoped we could
get really close to that ideal.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri May 29 17:06:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 16:06:26 +0000
Subject: More silly text/gemini spec proposals
In-Reply-To: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
Message-ID: <20200529160626.GD28953@SDF.ORG>

On Fri, May 29, 2020 at 10:18:48AM +0700, poomklao at yahoo.com wrote:

> <div dir='auto'>I have a couple of silly ideas for extra formatting:<div dir="auto"><br></div><div dir="auto"># Images</div><div dir="auto"><br></div><div dir="auto">Elegant form:</div><div dir="auto">IMG /static/fun.png "Alt text to display if you're in a terminal"</div>

This definitely isn't happening.  It *screams* for extension.  Even if
the spec only defined IMG, clients would immediately start also
supporting VID and SND.  It's way too slippery a slope.

Futhermore, anything which encourages clients to make additional requests
while processing the results of an earlier request is definitely not
happening.  The privacy game is over then, and many other important
games are over too.  It's the end of user autonomy.  We end up with the
current situation on the web where you follow a link and you have no
idea what's going to happen as a result and you just subject yourself to
the will of whoever authored the text/html on the other side.  Will your
browser connect to 1 host or 10 hosts or 100 hosts?  Nobody knows!  Will
one of those hosts belong to a company whom I don't want my computer
talking to because I think they're evil?  Nobody knows!  Will my computer
start making sounds, even though I'm in a library or a quiet cafe or I
have the radio on beside me?  Nobody knows!  This is a disaster we have
to avoid at all costs.  The user needs to be in control of this stuff.
Presenting links for them to follow *if* they want and *when* they want
gives them that control.  Inlining content takes it away.  We should
respect people's bandwidth and we should respect people's attention.

# Blockquotes</div><div dir="auto"><br></div><div dir="auto">Pretty much the same as in Markdown:</div><div dir="auto"><br></div><div dir="auto">&gt;&gt;&nbsp;Gemini is a new, collaboratively designed internet protocol, which 
> explores the space in between gopher and the web.</div>

I'm much less bothered by blockquotes, they are totally inoffensive,
degrade nicely if ignored and treated as text, and several people have
asked for them.  In fact, I've already said I'll probably add them to
the spec, as another optional line type.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Fri May 29 17:09:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 18:09:19 +0200
Subject: <META> overloading...
In-Reply-To: <20200529154517.GC28953@SDF.ORG>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
 <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
 <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>
 <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>
 <20200529154517.GC28953@SDF.ORG>
Message-ID: <60F5CF3B-5DEE-4379-8326-A935183AD9A5@gmail.com>



> On May 29, 2020, at 17:45, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> The issue is that the history of the web demonstrates that the most
> powerful/inclusive interpretation of a spec tends to become the only
> acceptable implementation over a long enough timeline. 

To echo spc sentiment  [1]:

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
-- Zawinski's law of software envelopment

=>data:message/rfc822;base64, ...

We already can! ??

No drama though, it's all going to be good. Perhaps we will have learned something after ~30 years of web browsing. ??

[1] https://lists.orbitalfox.eu/archives/gemini/2020/000975.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/23f242d5/attachment.htm>

From solderpunk at SDF.ORG  Fri May 29 17:23:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 29 May 2020 16:23:12 +0000
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529160626.GD28953@SDF.ORG>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200529160626.GD28953@SDF.ORG>
Message-ID: <20200529162312.GA5928@SDF.ORG>

On Fri, May 29, 2020 at 04:06:26PM +0000, solderpunk wrote:

> This is a disaster we have
> to avoid at all costs.  The user needs to be in control of this stuff.
> Presenting links for them to follow *if* they want and *when* they want
> gives them that control.  Inlining content takes it away.  We should
> respect people's bandwidth and we should respect people's attention.

I realise, by the way, that this hardcore "cyber-granola" attitude is
not an explicitly stated goal of the project anywhere, so people might
feel like it's coming out of nowhere.  To be honest, the FAQ etc. were
never written with a really general audience in mind.  This used to be a
small project where almost everybody involved was coming from
Gopherspace and/or pubnixspace, so all this stuff was just kind of
implicit and obvious and went without saying.  Hacker News felt a
million miles away!  Perhaps this should change.  I am *big* on user
autonomy.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Fri May 29 17:29:13 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 18:29:13 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529160626.GD28953@SDF.ORG>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200529160626.GD28953@SDF.ORG>
Message-ID: <8072FE89-C7A5-4FE8-8649-9D71C622340A@gmail.com>



> On May 29, 2020, at 18:06, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> We should respect people's bandwidth and we should respect people's attention.

I will personally take this to heart. After all, I wish to use Gemini for my own pedestrian reasons.

That said, if *I* would like *my* =>geo:13.4125,103.8667 link, in *my* own authored text/gemini, to magically turn into some wacky inline Map Web Snapshot behemoth  [1],  *I* will damn do so. 

Because it's my time, my bandwidth, my attention, and my ultimate decision. Specification's feelings be damned ?

[1] https://developer.apple.com/documentation/snapshots


From petite.abeille at gmail.com  Fri May 29 18:00:54 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 19:00:54 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529144249.GA28953@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
Message-ID: <1562C7E6-7542-4D71-AA17-879D658E9FCA@gmail.com>



> On May 29, 2020, at 16:42, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> No RFC puts a limit on the allowed length of a URL


? RFC822  (?1982) ? RFC2822 (?2001) ? RFC5322 (?2008) 2.1.1. Line Length Limits

There are two limits that this standard places on the number of characters in a line...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/7490e5c5/attachment-0001.htm>

From plugd at thelambdalab.xyz  Fri May 29 19:10:12 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 29 May 2020 20:10:12 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <8072FE89-C7A5-4FE8-8649-9D71C622340A@gmail.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200529160626.GD28953@SDF.ORG>
 <8072FE89-C7A5-4FE8-8649-9D71C622340A@gmail.com>
Message-ID: <lzsgfizk6z.fsf@bs-mbpr348.d.ethz.ch>

Petite Abeille writes:
> That said, if *I* would like *my* =>geo:13.4125,103.8667 link, in *my*
> own authored text/gemini, to magically turn into some wacky inline Map
> Web Snapshot behemoth [1], *I* will damn do so.

As long as you're only talking about how things render on _your_
computer, I agree.  But it's ultimately _my_ choice how to interpret
_your_ authored text/gemini on _my_ computer.

This is going off-topic, but I think users tend to lose this power when
faced with the gigantic sprawling mass of complexity that html+js+css
has become. There are only 2 or 3 (?) independent client implementations
in the *world*, meaning that nobody, to a very good approximation, has a
real choice in how their devices interpret that mess in a useful way.
`
Contrast this with gopher and gemini, where implementations abound, and
someone like me - who's not a software engineer by any stretch - can:

(a) be _completely_ in control of the (at least application-level)
details of what my computer does with the stuff servers send me, and

(b) still usefully extract, with my own clients, the majority of the
meaning that people are trying to convey using the protocols.

I'm _very_ thankful for the efforts people here have gone through to try
to ensure that users continue to have this level of control over the
behaviour of their own hardware.

Sorry for the ramble, but you struck a nerve! :-)

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/68d60ffa/attachment.sig>

From petite.abeille at gmail.com  Fri May 29 19:39:38 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 29 May 2020 20:39:38 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <lzsgfizk6z.fsf@bs-mbpr348.d.ethz.ch>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200529160626.GD28953@SDF.ORG>
 <8072FE89-C7A5-4FE8-8649-9D71C622340A@gmail.com>
 <lzsgfizk6z.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <054D3923-C132-4BFD-915A-80C0412DC286@gmail.com>



> On May 29, 2020, at 20:10, plugd <plugd at thelambdalab.xyz> wrote:
> 
> As long as you're only talking about how things render on _your_
> computer, I agree.  But it's ultimately _my_ choice how to interpret
> _your_ authored text/gemini on _my_ computer.

Absolutely. We are in total agreement. To each their own client. 

There is a plethora to choose from:

https://portal.mozz.us/gemini/gemini.circumlunar.space/software/

It's all happening between cleared-eyed, consenting adults.

??

From luke.emmet at gmail.com  Fri May 29 21:06:20 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 29 May 2020 21:06:20 +0100
Subject: [ANN] GemiNaut - a user friendly Gemini browser for Windows in C#
In-Reply-To: <20200529000922.GU23998@brevard.conman.org>
References: <5ECF9EDF.90607@gmail.com> <20200528152913.GA21188@SDF.ORG>
 <5ED0482F.2020703@gmail.com> <20200529000922.GU23998@brevard.conman.org>
Message-ID: <5ED16B3C.3080002@gmail.com>



On 29-May-2020 01:09, Sean Conner wrote:
>> My concept of a site is that it is either the domain itself, or if there
>> is a user specified in the path, then it is the user home.
>>
>> gemini://domain1.tld/mypath.gmi ->  site is domain1.tld for that page
>>
>> gemini://domain2.tld/users/foo/bar/baz.gmi ->  site is domain/users/foo
>> for that page
>    Be careful, because different servers might display user directories
> differently.  Some might do:
>
> 	gemini://example.com/~alice/
>
> and others:
>
> 	gemini://example.net/users/bob/
>
> and still others:
>
> 	gemini://example.org/Carol/
>
> And some might just do all three just to mess with you 8-P

I was a little loose with my description. It cannot know where the 
"user"'s "home" page is, it just makes an educated guess based on a 
general heuristic. I think it mostly applies, at least in these early 
days of Gemini Pubnix DIY server culture. All it is doing is traversing 
up the path from the current page  URL to propose a likely home path

In the first two cases alice and bob would get their own theming. Carol 
would inherit the site wide theming as there is no way to infer her 
existence as a user based on the URL. So Carol would have to nag her 
sysadmin if she wanted the site specific theming to apply to her.

There are other cases (servers in other languages for example). Maybe a 
German server would have gemini://domain/benutzer/frank - this is not 
considered at present, but pull requests are welcome! Also I havent 
implemented it so "*/~bar/baz" gets the same theme as "*/users/bar/baz" 
on the same server, but that could come if it is a common form to be 
found around and about. It could be always be an option, even 
potentially the end user might say "for this path, I expect the home 
page to be at this level in the URL"

It would be nice if there was a way for a user to optionally convey some 
kind of seed or info for some basic theming (like favicon). That could 
be picked up by a client if it existed. Very basic info, maybe 
foreground, background colours, site icon and maybe the definitive home 
page link.

Best wishes

   - Luke

From gemini at gkn.me.uk  Fri May 29 20:53:13 2020
From: gemini at gkn.me.uk (Grey Nicholson)
Date: Fri, 29 May 2020 20:53:13 +0100
Subject: Syntax highlighting for GtkSourceView (GNOME Builder, gedit)
Message-ID: <P8Z3BQ.5N1FHOXB2KJO3@gkn.me.uk>

Hi folks!

I've been using text/gemini for notes recently, because it's suitably 
simple and easy to parse.

I made a language spec for gedit, which I thought other people might 
find useful; you can find it at:
=> 
https://git.scuttlebot.io/%25bIpwmyP44M5EXF6SdICYQa8rBHhvRRtmqnclkZRx2%2BE%3D.sha256

It also works in GNOME Builder, and theoretically any other text editor 
using GtkSourceView versions 2 to 4.

Cheers,
-- 
Grey



From carsten at strotmann.de  Fri May 29 21:37:16 2020
From: carsten at strotmann.de (Carsten Strotmann)
Date: Fri, 29 May 2020 22:37:16 +0200
Subject: Trust model for addresses and certificates (DANE etc..)
In-Reply-To: <87367in8aj.fsf@dorothy.carcosa.net>
References: <20200529082946.GB302232@thunix.net>
 <87367in8aj.fsf@dorothy.carcosa.net>
Message-ID: <86k10upjer.fsf@emacs.strotmann.de>

Hi,

Jason McBrayer <jmcbray at carcosa.net> writes:

> southerntofu at thunix.net writes:
>
>> Using DANE to distribute certificates reduces the attack 
>> surface, because the
>> DNS is already a SPOF for a gemini server. I personally believe 
>> the gemini spec
>> should strongly encourage admins to use DANE to distribute 
>> their server
>> certificates.
>
> Could you provide a minimal sample implementation of how a 
> client would
> implement this? Just to demonstrate feasibility and to provide a 
> guide
> to other client authors?

I can't give a reference implementation, but as far as I know DANE 
can
be almost 100% delegated to OpenSSL or GNUTLS.

The DANE User Mailing List
<https://mail.sys4.de/mailman/listinfo/dane-users> is a good place 
to
get implementation help, sometimes directly from the RFC and 
OpenSSL
authors.

Greetings

Carsten

From jmcbray at carcosa.net  Fri May 29 21:37:24 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 29 May 2020 16:37:24 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529144249.GA28953@SDF.ORG> (solderpunk@sdf.org's message of
 "Fri, 29 May 2020 14:42:49 +0000")
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
Message-ID: <87pnamxyt7.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> On Fri, May 29, 2020 at 09:56:44AM -0400, Jason McBrayer wrote:
>  
>> On the web, they make sense as a way of inlining short content, like
>> icons, and avoiding a server round-trip. But obviously, they don't make
>> sense for Gemini, and there's no reason clients should support them.
>
> There's no reason they *should*, but they can.  And some of them will.
> And then people will think of this as normal and expect it and design
> their documents around it, and the snowball will roll...

Can't we just say: "A spec-compliant client MUST NOT display data: URLs
inline; a client MAY treat data: URLs as links to media, to be opened
only on user request."?

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From luke.emmet at gmail.com  Fri May 29 22:09:09 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 29 May 2020 22:09:09 +0100
Subject: More silly text/gemini spec proposals
In-Reply-To: <87pnamxyt7.fsf@dorothy.carcosa.net>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
 <87pnamxyt7.fsf@dorothy.carcosa.net>
Message-ID: <5ED179F5.3000607@gmail.com>

On 29-May-2020 21:37, Jason McBrayer wrote:
> Can't we just say: "A spec-compliant client MUST NOT display data: URLs
> inline; a client MAY treat data: URLs as links to media, to be opened
> only on user request."?
Can't see that would work - how about automated clients like spiders 
that crawl to build a search index for GUS etc?

I think whilst we may disapprove, we cant enforce the behaviour of a 
client to interpret content served.

  - Luke

From plugd at thelambdalab.xyz  Fri May 29 22:11:45 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 29 May 2020 23:11:45 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <87pnamxyt7.fsf@dorothy.carcosa.net>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
 <87pnamxyt7.fsf@dorothy.carcosa.net>
Message-ID: <lza71qa1ke.fsf@bs-mbpr348.d.ethz.ch>

Jason McBrayer writes:
> Can't we just say: "A spec-compliant client MUST NOT display data: URLs
> inline; a client MAY treat data: URLs as links to media, to be opened
> only on user request."?

While ideal, I think Postel's law will eventually bite you there -
correctly formatted pages will render just fine without clients
forbidding data: URLS, while incorrectly formatted pages will only work
on clients technically violating the spec.

How about this: it's a bit of a hack, but imagine if we explicitly
harnessed data URLs to do something vaguely useful?

e.g.

=> data://a%20person%20dancing
```
  \o/
   |
  / \
```

I know, I know, very silly - but _if_ there were a way to make data://
URLs an indispensible part of text/gemini it would make it very
difficult to abuse them without breaking things, wouldn't it?

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/07b7ee04/attachment-0001.sig>

From sean at conman.org  Fri May 29 22:15:04 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 17:15:04 -0400
Subject: <META> overloading...
In-Reply-To: <20200529154517.GC28953@SDF.ORG>
References: <7754AECC-1076-4ABA-ABE2-3B4F7FA0DA33@gmail.com>
 <20200529092451.GA2354@SDF.ORG>
 <0924CE54-73C4-4908-A9D9-AF8E19619AF7@gmail.com>
 <alpine.DEB.2.20.2005291553330.18317@pling.qwghlm.org>
 <ymj0ztLqmVkmGswQTOq5gjuQDtlasLuPh_xQ3XnZs1EkM4nhp0RdtRXz67vvVSfpM9H49dEHn4RcRr86NlPQ_V4n09rDqq9mdL6c9z63v_8=@protonmail.com>
 <20200529154517.GC28953@SDF.ORG>
Message-ID: <20200529211503.GD23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Fri, May 29, 2020 at 03:10:30PM +0000, colecmac at protonmail.com wrote:
> > > I think we need to rule out the equivalent of
> > 
> > All existing clients rule this out, I don't see the issue. As long as
> > clients continue not to execute arbitrary Javascript, it should be fine.
> 
> The issue is that the history of the web demonstrates that the most
> powerful/inclusive interpretation of a spec tends to become the only
> acceptable implementation over a long enough timeline.  Everybody builds
> their content for that interpretation, and more conservative clients
> come to be considered "broken".  It's like trying to surf the modern web
> with cookies and JS turned off: nothing works.  


> The only hope is to
> design specs where the most powerful interpretation is within acceptable
> limits.  Which seems to me to be impossible in a world where URLs can be
> harmless pointers to network resources *or* arbitrarily large chunks of
> data of arbitrary but unamiguous type.

  I added the test for data: URIs for the lulz (it is, after all, a *client
torture* test), which the expectation that no one would really do anything
with it.  And the data itself is 'text/gamini' as a nice treat for anyone
that did anything with it.

  One way to think of data: is not to inline data, but as a pre-fetch of
data, but without the overhead of a second request.  Yes, it's silly, but it
is what it is.  Besides, as just a gut feeling, I think the majority (well
over 99%) of the links you'll find in the Geminisphere are:

	gemini:
	gopher:
	https:
	http:
	mailto:

  I have no numbers to back that up, but that feels right to me, and such
links as tel: or sip: will almost *never* show up (for the record, I haven't
come across tel: or sip: on the web in the wild [1]).

> But I really didn't want to just rely on politely asking people not to
> do certain things, but to make it impossible or very difficult to do
> them at the protocol level.  I know you can never *really* do that,
> people can ignore RFCs and implement totally broken stuff and the
> internet police don't come and arrest them.  But I had hoped we could
> get really close to that ideal.

  Creativity is amplified by restrictions, and oh boy is Gemini restrictive. 
So it's not surprising to me that people are poking and proding at the edges
to see what's possible.  I never realized that music consisting of the same
note was a thing until this video:

	https://www.youtube.com/watch?v=eSuK_5zW2iM

or how about the restriction of using a single color for a painting?

	https://www.youtube.com/watch?v=u-pdyTFOvYw

  Years ago, a friend sent me an email of only 26 words.  It was a coherent
message *where every word was in alphabetical order!*  I replied with
another 26 words, with a coherent message, but in *reverse alphabetical
order!*

  I mention these as a way to explain the recent activity in Gemini, as more
peoples' creativity has been unleashed by the contraints of Gemini.

  And always keep in mind, a polite "no" is always a viable answer.

  -spc

[1]	I do at work, but at work I deal with SIP, so tel: and sip: comes
	with that territory.

From luke.emmet at gmail.com  Fri May 29 22:17:23 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 29 May 2020 22:17:23 +0100
Subject: More silly text/gemini spec proposals
In-Reply-To: <5ED179F5.3000607@gmail.com>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
 <87pnamxyt7.fsf@dorothy.carcosa.net> <5ED179F5.3000607@gmail.com>
Message-ID: <351C9670-D770-43C1-A055-0D79EB4DABFD@gmail.com>

Sorry ignore my last remarks about spiders in the email below, I didn't spot it was just referring to data:// URLs.

Still it seems hard to enforce a singular client behaviour with respect to interpreting content.

Luke

> On 29 May 2020, at 22:09, Luke Emmet <luke.emmet at gmail.com> wrote:
> 
>> On 29-May-2020 21:37, Jason McBrayer wrote:
>> Can't we just say: "A spec-compliant client MUST NOT display data: URLs
>> inline; a client MAY treat data: URLs as links to media, to be opened
>> only on user request."?
> Can't see that would work - how about automated clients like spiders that crawl to build a search index for GUS etc?
> 
> I think whilst we may disapprove, we cant enforce the behaviour of a client to interpret content served.
> 
> - Luke

From tkarpiniec at icloud.com  Fri May 29 22:26:15 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Sat, 30 May 2020 07:26:15 +1000
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529131533.GA21134@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
Message-ID: <20200529212615.GA28360@allanon.local>

On Fri, May 29, 2020 at 01:15:33PM +0000, solderpunk wrote:
> Who thought it was a good idea to turn a harmless way to indicate
> *where* some data can be found into a way to shoehorn in the data
> itself?  What are we supposed to use in a context where we don't
> want that to be a possibility?  Bah!

I think it is completely reasonable to specify a set of allowed
schemes whose use aligns with gemini's goals. For the sake of a
concrete example, perhaps:

* gemini
* http
* https
* gopher
* gophers
* mailto
* tel

Every programmatic interface I've worked with for URLs will parse the
scheme so you can easily inspect it, and a content container such a
webview or an NSTextView will let you filter requests before passing
them through to the operating system for action.

Making such a rule in the specification is not going to limit anyone's
ability to use regular libraries. It would probably only become an
issue in the sort of client where the developer has decided to render
text/gemini inside a webview, in which case sanitisation is a huge
problem anyway.

Cheers,

Tom

From sean at conman.org  Fri May 29 22:28:51 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 17:28:51 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529131533.GA21134@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
Message-ID: <20200529212851.GE23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Fri, May 29, 2020 at 09:35:20AM +0000, solderpunk wrote:
> > On Fri, May 29, 2020 at 06:34:29AM +0200, Petite Abeille wrote:
> >  
> > > Ohhh...  shiny! 
> > > 
> > > data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D
> > > 
> > > Let's see what else is hiding in those marvelous URI schemes:
> > 
> > ...let's not take delight in actively trying to crush the spirit of this
> > thing?  I mean, the web is right there if that's what you want.
> 
> Ugh, sorry about this email.  I was irritable from a lack of good sleep
> and waking up to a whole slew of posts here about extra complications,
> just as I was starting to feel we were at last approaching a kind of
> "cross the t's and dot the lowercase j's" state where there wasn't much
> left to add.  But I have no idea what your intended tone was and it may
> well have just been tongue in cheek.  Mostly I was just annoyed at
> learning that these data:// URLs exist.  I hadn't been aware of them.
> And frankly...what the hell?  Who thought it was a good idea to turn a
> harmless way to indicate *where* some data can be found into a way to
> shoehorn in the data itself?  What are we supposed to use in a context
> where we don't want that to be a possibility?  Bah!

  As I mentioned in my previous email, data: URIs can be "followed" just as
any other URI, it's just that the data has already been "pre-cached" so to
speak.  And since it comes with a MIME-type as part of the scheme, it can be
displayed in a client as any other MIME-type, just not automatically
inlined.

  And trying to whitelist "acceptable" URI schemes is pointless as there are
scores of schemes that are defined:

	https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

not all of which actually point to a resource, like urn: (RFC-8141).  And
speaking of urn:, it's specification states (section 4.1):

   Because a URN is, syntactically, a URI under the "urn" scheme, in
   theory a URN can be placed in any protocol slot that allows for a URI
   (to name just a few, the "href" and "src" attributes in HTML, the
   base element in HTML, the "xml:base" attribute in XML [XML-BASE], and
   the "xmlns" attribute in XML for XML namespace names [XML-NAMES]).

   However, this does not imply that, semantically, it always makes
   sense in practice to place a URN in a given URI protocol slot; in
   particular, because a URN might not specify the location of a
   resource or even point indirectly to one, it might not be appropriate
   to place a URN in a URI protocol slot that points to a resource
   (e.g., the aforementioned "href" and "src" attributes).

   Ultimately, guidelines regarding when it is appropriate to use URIs
   under the "urn" scheme (or any other scheme) are the responsibility
   of specifications for individual URI protocol slots (e.g., the
   specification for the "xml:base" attribute in XML might recommend
   that it is inappropriate to use URNs in that protocol slot).  This
   specification cannot possibly anticipate all of the relevant cases,
   and it is not the place of this specification to require or restrict
   usage for individual protocol slots.

  So it might be prudent to state in the Gemini spec that

	1) urn: is not a valid URI type for links, and
	2) NO INLINING OF LINKS ALLOWED [1].

  -spc (You have my permission to do so 8-)

[1]	I have more to say about this in an upcoming email.

From sean at conman.org  Fri May 29 22:32:11 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 17:32:11 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529144249.GA28953@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
Message-ID: <20200529213210.GF23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Fri, May 29, 2020 at 09:56:44AM -0400, Jason McBrayer wrote:
>  
> > On the web, they make sense as a way of inlining short content, like
> > icons, and avoiding a server round-trip. But obviously, they don't make
> > sense for Gemini, and there's no reason clients should support them.
> 
> There's no reason they *should*, but they can.  And some of them will.
> And then people will think of this as normal and expect it and design
> their documents around it, and the snowball will roll...
> 
> I tried *so* hard to avoid this, but you just can't.  This data:// URL
> thing is a monster.  No RFC puts a limit on the allowed length of a URL.

  RFC-2397 (The "data" URL scheme) states (section 2):

   The "data:" URL scheme is only useful for short values. Note that
   some applications that use URLs may impose a length limit; for
   example, URLs embedded within <A> anchors in HTML have a length limit
   determined by the SGML declaration for HTML [RFC1866]. The LITLEN
   (1024) limits the number of characters which can appear in a single
   attribute value literal, the ATTSPLEN (2100) limits the sum of all
   lengths of all attribute value specifications which appear in a tag,
   and the TAGLEN (2100) limits the overall length of a tag.

So there are, in fact, limits.  

  -spc

From sean at conman.org  Fri May 29 22:40:26 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 17:40:26 -0400
Subject: More silly text/gemini spec proposals
In-Reply-To: <lza71qa1ke.fsf@bs-mbpr348.d.ethz.ch>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
 <87pnamxyt7.fsf@dorothy.carcosa.net> <lza71qa1ke.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <20200529214026.GG23998@brevard.conman.org>

It was thus said that the Great plugd once stated:
> Jason McBrayer writes:
> > Can't we just say: "A spec-compliant client MUST NOT display data: URLs
> > inline; a client MAY treat data: URLs as links to media, to be opened
> > only on user request."?
> 
> While ideal, I think Postel's law will eventually bite you there -
> correctly formatted pages will render just fine without clients
> forbidding data: URLS, while incorrectly formatted pages will only work
> on clients technically violating the spec.
> 
> How about this: it's a bit of a hack, but imagine if we explicitly
> harnessed data URLs to do something vaguely useful?
> 
> e.g.
> 
> => data://a%20person%20dancing

  That's the incorrect format.  It should be:

=> data:text/plain,a%20person%20dancing

> ```
>   \o/
>    |
>   / \
> ```
> I know, I know, very silly - but _if_ there were a way to make data://
> URLs an indispensible part of text/gemini it would make it very
> difficult to abuse them without breaking things, wouldn't it?

  The issue is when someone does something like:

=> data:image/jpeg;base64,YSBwZXJzb24gZGFuY2luZw...
```
   \o/
    |
   / \
```
  -spc



From plugd at thelambdalab.xyz  Fri May 29 23:23:48 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Sat, 30 May 2020 00:23:48 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529214026.GG23998@brevard.conman.org>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net> <20200529144249.GA28953@SDF.ORG>
 <87pnamxyt7.fsf@dorothy.carcosa.net> <lza71qa1ke.fsf@bs-mbpr348.d.ethz.ch>
 <20200529214026.GG23998@brevard.conman.org>
Message-ID: <lzv9kenzwr.fsf@bs-mbpr348.d.ethz.ch>

Sean Conner writes:
>   That's the incorrect format.  It should be:
> => data:text/plain,a%20person%20dancing

Sure, but the point is to _abuse_ the data: URL so as to make it
useless.

>   The issue is when someone does something like:
>
> => data:image/jpeg;base64,YSBwZXJzb24gZGFuY2luZw...
> ```
>    \o/
>     |
>    / \
> ```

But that will render horribly in clients that are obeying the spec where
we abuse the contents of the data URL to specify the alt-text.  

I'm not actually suggesting this, to be honest - I'm just pointing out
one technically feasible way of making it in the client author's
best interest to prohibit using data: URLs to embed arbitrary content.
Just saying to client authors, "you MUST refuse this URL type" isn't
going to work.  But making it somehow impossible for clients to
simultaneously behave sensibly in the face of correctly formatted
text/gemini _and_ interpret data: URLs as they are intended seems like
it could work, at least in principle.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200530/2d95536e/attachment.sig>

From mbays at sdf.org  Fri May 29 23:42:52 2020
From: mbays at sdf.org (Martin Bays)
Date: Sat, 30 May 2020 00:42:52 +0200
Subject: More silly text/gemini spec proposals
In-Reply-To: <20200529144249.GA28953@SDF.ORG>
References: <b0623922-2655-4559-a757-8d6b5478580a.ref@email.android.com>
 <b0623922-2655-4559-a757-8d6b5478580a@email.android.com>
 <D64FBE31-B937-479E-9D0B-6089B2A8F69B@gmail.com>
 <20200529093520.GB2354@SDF.ORG> <20200529131533.GA21134@SDF.ORG>
 <87blm6n8tf.fsf@dorothy.carcosa.net>
 <20200529144249.GA28953@SDF.ORG>
Message-ID: <20200529224252.pphmeofkkfymri6g@gonzales.net>

* Friday, 2020-05-29 at 14:42 +0000 - solderpunk <solderpunk at SDF.ORG>:

>I tried *so* hard to avoid this, but you just can't.  This data:// URL
>thing is a monster.

One possible solution I haven't seen mentioned: make it part of the spec 
that the full URI of a link should (or even must) be displayed as part 
of any rendering of the link. That would hopefully be enough to thwart 
any slide towards data links being interpreted by some clients as inline 
images etc, since spec-respecting clients would render them as ugly long 
strings.

Personally I think this would be a good rule anyway -- as part of the 
user control dogma, the user should have full awareness of what request 
to what server following a link will result in.

From sean at conman.org  Sat May 30 02:49:18 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 21:49:18 -0400
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini space)
In-Reply-To: <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
Message-ID: <20200530014918.GH23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On May 29, 2020, at 01:29, Luke Emmet <luke.emmet at gmail.com> wrote:
> > 
> >> E.g. ? gemini.circumlunar.space ? 4028369029 ? ~lapryt-fidse ? sigil ??
> > Huh - that is cute. These Urbit avatars are quite attractive. I think
> > they spent quite a bit of time on the graphic design of that engine.
> 
> Yeah, pretty nifty actually.
> 
> Like their 'phonemic naming system' as well (the 4028369029 to ~lapryt-fidse bit):
> 
> https://urbit.org/understanding-urbit/urbit-id/
> https://github.com/urbit/urbit-ob/blob/master/src/internal/co.js
> https://github.com/urbit/sigil-js
> 
> It's a bit of a pain to run 'out-of-the-box' if you are not into node.js,
> but I'm confidant spc will get a sweet Lua implementation in no time :)

  I think you know me too well.

  Anyway, if anyone is interested in playing with this, I have a CGI script
set up.  A few sample links:

	gemini://gemini.conman.org/sigil?id=~lapryt~fidseg&fg=green&bg=white
	gemini://gemini.conman.org/sigil?id=F01C0885&fg=green&bg=white
	gemini://gemini.conman.org/sigil?id=~lapryt~fidseg
	gemini://gemini.conman.org/sigil?id=F01C0885

  The source code to the CGI is also avaiable on the site---warning:  it's
*big*.  202,390 bytes big.  But the code is pure Lua, no dependencies other
than Lua 5.1 or higher, and I've tested the CGi script on a Gemini server, a
web server, and a gopher server, so it serves as an example of a
multi-server CGi script as well.

  -spc (Work has been a bit slow for some reason ... )

From sean at conman.org  Sat May 30 03:41:37 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 29 May 2020 22:41:37 -0400
Subject: The Problems of Transclusion (was Re: More silly text/gemini spec
 proposals)
In-Reply-To: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
Message-ID: <20200530024137.GI23998@brevard.conman.org>

It was thus said that the Great poomklao at yahoo.com once stated:
> I have a couple of silly ideas for extra formatting:
> 
> # Images
> 
> Elegant form:
> 
> IMG /static/fun.png "Alt text to display if you're in a terminal"
> 
> Backwards-compatible form:
> 
> => image:/static/fun.png "Image: My cute little cat"

  I'm picking this message as a starting point.  I'm not trying to shame
poomklao for this idea, as people have been wanting something like this for
years [1].  And I promised an email about this earlier to day, when I said:

> NO INLINING OF LINKS ALLOWED

and here is the rational I have for this.

  The idea is technically called "transclusion" and was coined by Ted
Nelson.  "Transclusion" is the automatic inclusion of content into one
document from another one and was meant as a means of presenting a quote
(<blockquote> in HTML) from a particular version of a particular document
(with royalties and all that mess).  We have a very limited form of it on
the Web---the only three mediums that can be directly transcluded are
images, video and sounds, none of which support transclusion themselves. 
You also have a limited from with frames in HTML, but ...

  Like all formal, well specified systems, things tend to go pear shaped [2]
when you allow self-referential references, and that's what transclusion (in
general) brings to the table.  In the Hacker News thread about Gemini [4], a
person brought up transclusion [5] in text/gemini files with the following
syntax:

	<= gemini://example.com/path/to/resource

and for the sake of argument, let's assume this does what it
indicates---that the document at the given link is inserted at that point
into the document being rendered [6].  For the example, let's say we are
obtaining the document <gemini://example.com/document.gemini>, and in that
document you have:

	<= gemini://example.com/document.gemini

  And thus the problem is revealed.  

  "But surely, you can keep track of all transcluded files to prevent this
from happening," you say.  And yes, that is possible.  But as the creator of
the Client Torture Test, I can assure you that I can create an endless
stream of unique documents that transclude an endless stream of unique
documents that transclude an endless stream of unique documents that
transclude an endless stream of unique documents th

Core error-bus dumped.

  Where was I?

  Oh yes, self-referential transclusion, or an infinite amount of
transclusion.

  "But surely, like rediection, you can limit the depth of transclusion,"
you say.  Yes, you can limit the level of transclusion, but that just adds
to the complexity of the implementation.  An implementation would have to
both track the documents being transcluded plus the depth of transclusion.
Unlike rediects, where you just track the number of times you are being
redirected, transclusion is a bit more complex:

	doc1 <= doc2 <= doc3 <= doc4  <= doc5
				      <= doc6
				      <= doc7
			     <= doc8  <= doc9
				      <= doc10
				      <= doc11
			     <= doc12 <= doc13 

  Just limited the depth of transclusion to 5 levels still leads to a
potential 626 documents being transcluded (if I did my math correctly).  And
implementing just one level is annoying for little in return.

  So while I like the idea of transclusion, I have to admit there are issues
when you can possibly transclude documents that transclude other documents.
So in this, I say:

                        NO INLINING OF LINKS ALLOWED!

  -spc

[1]	Starting in the 60s, with Ted Nelson and his Xanadu project.

[2]	English (perhaps an Americanism) for "Situation Normal All Fouled
	Up" [3]

[3]	aka SNAFU.
 
[4]	https://news.ycombinator.com/item?id=23042424

[5]	https://news.ycombinator.com/item?id=23046008

[6]	In the Hacker News comment, the transclusion is meant to be done by
	the server, not the client.  For my argument, it doesn't make a
	difference *who* does the translusion.

From petite.abeille at gmail.com  Sat May 30 10:17:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 11:17:05 +0200
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <20200530014918.GH23998@brevard.conman.org>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
Message-ID: <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>



> On May 30, 2020, at 03:49, Sean Conner <sean at conman.org> wrote:
> 
>  I think you know me too well.

Wow! Super fantastic. Was it fun to do? :)

For the record:
https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua

Very, very nice :)

From petite.abeille at gmail.com  Sat May 30 10:36:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 11:36:19 +0200
Subject: The Problems of Transclusion (was Re: More silly text/gemini spec
 proposals)
In-Reply-To: <20200530024137.GI23998@brevard.conman.org>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200530024137.GI23998@brevard.conman.org>
Message-ID: <9588974C-1131-4CC8-8146-FA061022B8AA@gmail.com>



> On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote:
> 
> [1]	Starting in the 60s, with Ted Nelson and his Xanadu project.

Ted! Xanadu! It never gets old :)

EVERYTHING IS DEEPLY INTERTWINGLED
https://en.wikipedia.org/wiki/Intertwingularity

[ALL CAP AND ALL]




From petite.abeille at gmail.com  Sat May 30 10:46:29 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 11:46:29 +0200
Subject: The Problems of Transclusion (was Re: More silly text/gemini spec
 proposals)
In-Reply-To: <20200530024137.GI23998@brevard.conman.org>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200530024137.GI23998@brevard.conman.org>
Message-ID: <A66D6270-60AD-4706-A232-E969D2911202@gmail.com>



> On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote:
> 
> NO INLINING OF LINKS ALLOWED!

In all due respect: this is wishful thinking at best, delusion at worst.

But then again, the Gemini spec can -and perhaps should- be opinionated.

Be the Zed Shaw and David Heinemeier Hansson of specification, all rolled into one... [1]

[1] http://programming-motherfucker.com

From petite.abeille at gmail.com  Sat May 30 15:13:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 16:13:47 +0200
Subject: =?utf-8?Q?=E2=99=8A=EF=B8=8E=23_=28was_Re=3A_=5BANN=5D_GemiNaut_-?=
 =?utf-8?Q?_a_user_friendly_Gemini_browser_for_Windows_in_C=23=29?=
In-Reply-To: <5ED16B3C.3080002@gmail.com>
References: <5ECF9EDF.90607@gmail.com> <20200528152913.GA21188@SDF.ORG>
 <5ED0482F.2020703@gmail.com> <20200529000922.GU23998@brevard.conman.org>
 <5ED16B3C.3080002@gmail.com>
Message-ID: <2919D17D-9004-4EF4-A458-028B1E1A7C56@gmail.com>


> On May 29, 2020, at 22:06, Luke Emmet <luke.emmet at gmail.com> wrote:
> 
> It would be nice if there was a way for a user to optionally convey some kind of seed or info for some basic theming (like favicon). That could be picked up by a client if it existed. Very basic info, maybe foreground, background colours, site icon and maybe the definitive home page link.

Perhaps some sort of informal convention, ala shebang [1], as a prelude to a text/gemini, with a few directives, such as:

#!?? ?(u?op?p?sdn ??) ?(black white) 

In other words, to be considered a gemini shebang (??# for short):

? It MUST be the first line of a text/gemini
? The line MUST start with the sequence U+0023 U+0021 U+264A U+FE0E U+0020 ('#!?? ')

Followed by any number of key-value pairs, perhaps as algol type sexp, e.g.:

? (U+2302 HOUSE) for user info such as name (u?op?p?sdn) and icon (?? U+2623 BIOHAZARD SIGN)
? (U+2F8A COLOR) for styling info such as text color (black) and background (white)

Blending both retro and contemporary styling, a bit like Gemini itself.

Gemini For The Win (???? for short)

P.S. Aside from being a gimmick, the use of Unicode symbols showcase Gemini's capabilities, namely full Unicode support.
P.P.S. To paraphrase some old slogan, Keep Gemini Weird ?

[1] https://en.wikipedia.org/wiki/Shebang_(Unix)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200530/523719ad/attachment.htm>

From martin at no.ucant.org  Sat May 30 15:55:45 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sat, 30 May 2020 15:55:45 +0100 (BST)
Subject: =?UTF-8?Q?Re=3A_=E2=99=8A=EF=B8=8E#_=28was_Re=3A_=5BANN=5D_GemiNaut_-_a_user_friendly_Gemini_browser_for_Windows_in_C#=29?=
In-Reply-To: <2919D17D-9004-4EF4-A458-028B1E1A7C56@gmail.com>
References: <5ECF9EDF.90607@gmail.com> <20200528152913.GA21188@SDF.ORG>
 <5ED0482F.2020703@gmail.com> <20200529000922.GU23998@brevard.conman.org>
 <5ED16B3C.3080002@gmail.com> <2919D17D-9004-4EF4-A458-028B1E1A7C56@gmail.com>
Message-ID: <alpine.DEB.2.20.2005301526240.18317@pling.qwghlm.org>

On Sat, 30 May 2020, Petite Abeille wrote:

> Perhaps some sort of informal convention, ala shebang [1], as a prelude to a text/gemini, with a few directives, such as:
>
> #!?? ?(u?op?p?sdn ??) ?(black white)

This stuff surely is already doable with HTML on the normal web.

There's an ornateness spectrum, from very intricate, complex and decorated 
to very minimal and austere. On the one hand we have Catholic and Orthodox 
churches, subway graffiti, NHS GP waiting room notice boards, Geocities, 
Myspace, etc, and on the other we have Quaker meeting houses, Danshari, 
Wikipedia, medium.com, suckless.org, etc. The existing HTML-based web 
caters very well to the ornate end of the spectrum. text/gemini as 
originally conceived caters well to the minimal end.

In the present circumstances, familiarity and the lure of popularity will 
generally create a pressure to move away from the minimal end of this 
spectrum, leaving the demand it satisfied once again uncatered to. It is a 
huge shame that people who just want to write, and people who just want to 
read, must, if they want to communicate over the web, contend with vast 
amounts of complexity thrown in their way by advertisers and designers. 
Moving to duplicate the web will just fragment Gemini as the "just want to 
write and read" crowd evict themselves to a different text file format.

Mk

From petite.abeille at gmail.com  Sat May 30 16:17:40 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 17:17:40 +0200
Subject: =?utf-8?Q?Re=3A_=E2=99=8A=EF=B8=8E=23_=28was_Re=3A_=5BANN=5D_Gemi?=
 =?utf-8?Q?Naut_-_a_user_friendly_Gemini_browser_for_Windows_in_C=23=29?=
In-Reply-To: <alpine.DEB.2.20.2005301526240.18317@pling.qwghlm.org>
References: <5ECF9EDF.90607@gmail.com> <20200528152913.GA21188@SDF.ORG>
 <5ED0482F.2020703@gmail.com> <20200529000922.GU23998@brevard.conman.org>
 <5ED16B3C.3080002@gmail.com> <2919D17D-9004-4EF4-A458-028B1E1A7C56@gmail.com>
 <alpine.DEB.2.20.2005301526240.18317@pling.qwghlm.org>
Message-ID: <C52E7033-1BCA-4E27-8D92-922422509416@gmail.com>



> On May 30, 2020, at 16:55, Martin Keegan <martin at no.ucant.org> wrote:
> 
> Quaker

Gemini, the Amish of protocols.

This is meant in an endearing* way.

* compare and contrast: endearing ? enduring



From martin at no.ucant.org  Sat May 30 16:32:59 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sat, 30 May 2020 16:32:59 +0100 (BST)
Subject: =?UTF-8?Q?Re=3A_=E2=99=8A=EF=B8=8E#_=28was_Re=3A_=5BANN=5D_GemiNaut_-_a_user_friendly_Gemini_browser_for_Windows_in_C#=29?=
In-Reply-To: <C52E7033-1BCA-4E27-8D92-922422509416@gmail.com>
References: <5ECF9EDF.90607@gmail.com> <20200528152913.GA21188@SDF.ORG>
 <5ED0482F.2020703@gmail.com> <20200529000922.GU23998@brevard.conman.org>
 <5ED16B3C.3080002@gmail.com> <2919D17D-9004-4EF4-A458-028B1E1A7C56@gmail.com>
 <alpine.DEB.2.20.2005301526240.18317@pling.qwghlm.org>
 <C52E7033-1BCA-4E27-8D92-922422509416@gmail.com>
Message-ID: <alpine.DEB.2.20.2005301625120.18317@pling.qwghlm.org>

On Sat, 30 May 2020, Petite Abeille wrote:

> Gemini, the Amish of protocols.
>
> This is meant in an endearing* way.
>
> * compare and contrast: endearing ? enduring

Indeed. I take that glyph to mean that the two properties promote each 
other.

Likewise, with my reference to NHS GP surgeries: the noticeboards are 
usually a messy collage of competing posters about different treatments 
and public health concerns, because there's normally no inclination to 
impose a single message or resist the addition of just "one" more poster. 
It was in February when the posters were all cleared away and replaced by 
a single COVID19 poster that I realised the pandemic was deadly serious.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From petite.abeille at gmail.com  Sat May 30 17:11:53 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 18:11:53 +0200
Subject: MAKER'S MAP (was Re: More silly text/gemini spec proposals)
In-Reply-To: <20200529160626.GD28953@SDF.ORG>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200529160626.GD28953@SDF.ORG>
Message-ID: <03DC330F-3862-4AD6-A434-35D328A99C93@gmail.com>


> On May 29, 2020, at 18:06, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> This definitely isn't happening.

To atone for any possible noise induced anxiety, here is a small token of gratitude for you:

MAKER'S MAP
Any creative act can be a perilous journey. A small box was discovered at the edge of a volcano containing coded notes from an unnamed source. Believed by many to be lost manuscripts from the failed expedition of a now forgotten explorer, the notes were pieced together and found to be a map of the creative process. We are proud to present you with this powerful tool as a reminder of all the frames of mind you have access to at any point as you work to bring something to life. This map is for creators who want to live and invite others to live also!

Ahoi, Dreamer [1]
The Fog of Fear [2]
Wonder Mountain [3]

( via swissmiss at https://www.swiss-miss.com/2020/05/makers-map.html )
( by montague workshop at https://shopmontagueworkshop.com/products/makers-map )

[1] https://cdn.shopify.com/s/files/1/1800/5841/products/makersmap01_1024x1024.jpg
[2] https://cdn.shopify.com/s/files/1/1800/5841/products/IMG_0563_1024x1024.jpg
[3] https://cdn.shopify.com/s/files/1/1800/5841/products/IMG_0549_1024x1024.jpg





From mbays at sdf.org  Sat May 30 19:11:41 2020
From: mbays at sdf.org (Martin Bays)
Date: Sat, 30 May 2020 20:11:41 +0200
Subject: [ANN] Diohsc: incredibly ordinary haskell client
Message-ID: <20200530181141.qj6cbiaff462fk4a@gonzales.net>

I hacked together a little haskell client:

gemini://gemini.thegonz.net/diohsc/
https://repo.or.cz/diohsc.git

It implements everything except client certificates. Those may get added 
at some point.

For now at least, the interface is line-based, similar to AV-98.

For TLS, it uses the rather nice pure haskell libraries (tls, x509, 
cryptonite) by Vincent Hanquez. It allows a mix of TOFU and trusting 
specified CAs.

Currently it's tested only on my linux machine, but in theory it should 
be pretty portable.

The code is fairly terse:
$ grep -hv '^--' *.hs | grep -v '^$' | wc
724    4312   34955

Let me know if you find any bugs or other inadequacies.

From solderpunk at SDF.ORG  Sat May 30 19:13:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 30 May 2020 18:13:21 +0000
Subject: Possibly silly text/gemini spec suggestion: Frames
In-Reply-To: <02b01942-e9af-8c4d-2ce7-643645790220@park-city.club>
References: <02b01942-e9af-8c4d-2ce7-643645790220@park-city.club>
Message-ID: <20200530181321.GB29889@SDF.ORG>

Hey,

Thanks for the suggestion and sorry for the slow response!

Perhaps predictably, I'm not really enthusiastic about this.  I
acknowledge that you've tried to limit the complexity of this by
explicitly forbidding the nesting of frames (and thank goodness!), but I
still think this is a substantial increase in complexity compared to
everything else.

Adding this, as it is proposed, would break the principle that has held
so far of text/gemini being parsable and renderable line-by-line in a
single pass with almost no internal state in the parser.  A frame-based
solution would require a client to hold the entire document in memory at
once and impose some kind of internal structure on it.  I understand
it's supposed to be optional, but I would like it if even a "full
flavoured" renderer which supports all line types is still a pretty
modest undertaking.

This would also, for the first time, make it really possible to produce
non-trivially invalid text/gemini.  E.g. a "|  " line encountered befeore a
"|||" line makes no sense.  People could also easily write, deliberately
or by accident, a text/gemini document which did nest frames in the way
that's not allowed, and clients would need to recognise this and then
decide what to do with it.

So the complications and potential problems this brings along are pretty
substantial, more so than ever other line type so far.

I also appreciate that you've given thought to how this would degrade in
a dumb terminal display.  Even if we grant that your suggested layouts
don't look too bad, I worry that people will come up with other layouts
which *do* look confusing.

I guess I'm also not clear what problem this is intended to solve which
couldn't be solved in a simpler way.  If this is just suppose to give
text/gemini authors a way to creatively express themselves a bit, then
I guess this isn't really a concern (but I would suggest that there are
probably simpler ways to jazz up a page a bit).  But if it's supposed to
make pages easier to navigate, maybe there are other ways to achieve
this?  In what I assume is the intended rendering of one of your
examples, the document title remains visible at the top the entire time
as you scroll through the actual content.  text/gemini already *has* a
clear and simple way to indicate the title of a document, by putting a
first-level header on the first non-empty line.  GUI/TUI clients could
easily extract that title and display it permanently in part of their
layout.  Navigation links are less obvious, but I'm not sure what is
wrong with just having them sit, by convention, at the end of a
document.  Any decent client should allow the user to hit the End key on
their keyboard and immediately jump down to those links.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sat May 30 19:49:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 30 May 2020 18:49:55 +0000
Subject: Nano context highlighting for gmi file
In-Reply-To: <alpine.NEB.2.21.2005282202030.20615@sdf.lonestar.org>
References: <alpine.NEB.2.21.2005282202030.20615@sdf.lonestar.org>
Message-ID: <20200530184955.GD29889@SDF.ORG>

Thanks for sharing this, Peteyboy!

Have you seen the nano highlighting at:

https://github.com/yzzyx-network/nanorc/blob/master/gemini.nanorc

?  Just thought I'd point you at it in case it gave you any ideas (I
haven't tested it, no idea if it actually works).  I'm just guessing,
but I think it colours links differently depending on whether or not
they have a label or are just a URL?  Looks like there is a difference
in how it detects pre-formatted content, too.  No idea what, though.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sat May 30 19:54:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 30 May 2020 18:54:59 +0000
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com>
 <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
Message-ID: <20200530185459.GE29889@SDF.ORG>

On Sat, May 30, 2020 at 11:17:05AM +0200, Petite Abeille wrote:
> 
> 
> > On May 30, 2020, at 03:49, Sean Conner <sean at conman.org> wrote:
> > 
> >  I think you know me too well.
> 
> Wow! Super fantastic. Was it fun to do? :)

Indeed, these look really great.  I like the idea of mapping identifiers
(be they Urbit IDs or URLs) to visually appealing and distinct little
graphical elements.

I'm kind of wary of Gemini clients using Urbit IDs for this purpose,
though.  Totally aside from any kind of potential IP issue, it just
seems a little rude when the Urbit folk obviously put an awful lot of
time and energy into coming up with these sigils as part of their own
project's visual identity.  But adopting the general idea I'm totally
enthusiastic about.

Any graphic designers, or similarly inclined people, on the list?

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sat May 30 20:15:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 21:15:39 +0200
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <20200530185459.GE29889@SDF.ORG>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
 <20200530185459.GE29889@SDF.ORG>
Message-ID: <26EAD736-74E2-4789-8180-724C9D149C2E@gmail.com>



> On May 30, 2020, at 20:54, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> I'm kind of wary of Gemini clients using Urbit IDs for this purpose, though.

MIT License

https://github.com/urbit/sigil-js

They put it out there to be actually used, by actual people.


From solderpunk at SDF.ORG  Sat May 30 20:21:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 30 May 2020 19:21:26 +0000
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <26EAD736-74E2-4789-8180-724C9D149C2E@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com>
 <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
 <20200530185459.GE29889@SDF.ORG>
 <26EAD736-74E2-4789-8180-724C9D149C2E@gmail.com>
Message-ID: <20200530192126.GF29889@SDF.ORG>

On Sat, May 30, 2020 at 09:15:39PM +0200, Petite Abeille wrote:
> MIT License
> 
> https://github.com/urbit/sigil-js
> 
> They put it out there to be actually used, by actual people.
> 

Presumably for use in Urbit-related contexts, right?

Okay, I realise that given the code is out there under an MIT license
they can't stop people doing whatever they want with it.  We're
*allowed* to.  It just feels rude, to me.  But I can't stop Gemini
client authors doing it.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sat May 30 20:25:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 21:25:39 +0200
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <20200530192126.GF29889@SDF.ORG>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
 <20200530185459.GE29889@SDF.ORG>
 <26EAD736-74E2-4789-8180-724C9D149C2E@gmail.com>
 <20200530192126.GF29889@SDF.ORG>
Message-ID: <5A0B9AA1-28A3-4D6F-9F97-2C73D0B605B6@gmail.com>



> On May 30, 2020, at 21:21, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Presumably for use in Urbit-related contexts, right?

?!? Urbit has those already...no point in releasing it back to themselves...

> 
> Okay, I realise that given the code is out there under an MIT license
> they can't stop people doing whatever they want with it.

A MIT license is meant to *allow* people to do whatever the heck they want.

>  We're *allowed* to.  It just feels rude, to me.

...

>  But I can't stop Gemini client authors doing it.

This is a profound truth.


From petite.abeille at gmail.com  Sat May 30 20:32:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 21:32:04 +0200
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <20200530185459.GE29889@SDF.ORG>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
 <20200530185459.GE29889@SDF.ORG>
Message-ID: <56FC05E4-CA0C-440D-9C4D-0CB035352A55@gmail.com>



> On May 30, 2020, at 20:54, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Any graphic designers, or similarly inclined people, on the list?

Actually, if someone is up to it, their methodology for composing visually distinct images is very generic:

https://urbit.org/blog/creating-sigils/

Looking at Sean's implementation, one could fiddle with the various SVG fragments, and achieve a distinctive visual identity, without having to change much of the mechanics themselves:

https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua




From petite.abeille at gmail.com  Sat May 30 20:43:10 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 30 May 2020 21:43:10 +0200
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <20200530192126.GF29889@SDF.ORG>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
 <20200530185459.GE29889@SDF.ORG>
 <26EAD736-74E2-4789-8180-724C9D149C2E@gmail.com>
 <20200530192126.GF29889@SDF.ORG>
Message-ID: <043496AF-8D7E-45FB-A43A-CF02E8008545@gmail.com>



> On May 30, 2020, at 21:21, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>  It just feels rude, to me.

"Urbit ID and the sigils are components of Urbit that are totally separate from the OS ? you can use them on their own and potentially even extend their functionality. We?re happy with what we?ve done with them so far, and hope that people will experiment with what?s possible with this naming and identity system."

-- Gavin Atkinson, Creating Sigils, 202-02-04
 https://urbit.org/blog/creating-sigils/ <https://urbit.org/blog/creating-sigils/>

It would be rude not to :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200530/7e2f1bc1/attachment.htm>

From sean at conman.org  Sat May 30 21:43:57 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 30 May 2020 16:43:57 -0400
Subject: The Sigil! (was Re: Cognitive aspects of navigation in gemini
 space)
In-Reply-To: <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
Message-ID: <20200530204357.GK23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On May 30, 2020, at 03:49, Sean Conner <sean at conman.org> wrote:
> > 
> >  I think you know me too well.
> 
> Wow! Super fantastic. Was it fun to do? :)

  Yes.  I"ve never really looked at SVG before, and I had to pick up just
enough to know how to construct the file.

> For the record:
> https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua
> 
> Very, very nice :)

  Thanks.

  -spc

From tomasino at lavabit.com  Sat May 30 22:53:06 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sat, 30 May 2020 21:53:06 +0000
Subject: gophermap -> text/gemini converter
In-Reply-To: <20200530204357.GK23998@brevard.conman.org>
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 <5EBD9569.70309@orlando-lutes.com>
 <BB314B41-E075-48E9-A057-8B1C5230D328@gmail.com> <5ED0495F.2050907@gmail.com>
 <A5DC2E47-030C-4C1C-BCF0-787D8F2200ED@gmail.com>
 <20200530014918.GH23998@brevard.conman.org>
 <497DAA63-7311-481E-B4F7-DCFBF3722A1B@gmail.com>
 <20200530204357.GK23998@brevard.conman.org>
Message-ID: <c7f8c89c-283d-b9cb-fb1b-b9d4fe4119d8@lavabit.com>

There was an offhand request for a converter from gophermap to the
native text/gemini format in the IRC channel. I had an awk script
written already to parse gophermaps, so I made some quick adjustments
and can share the results here:

https://github.com/jamestomasino/dotfiles-minimal/blob/master/bin/gophermap2gemini.awk

Currently it detects html links, telnet links, and remaining linkable
gopher types and formats those into the => link pattern. I am checking
URLs for spaces and escaping those, since spaced URLs do actually work
in gopher but won't in gemini due to link line parsing. I'm defaulting
to code-fencing all type i lines in the file unless the lines match the
formatting for a header (#, ##, ###, but not ####), or an unordered list.

It's in GNU awk and untested on BSD. I'm guessing it'll explode there
brilliantly.

For those of you looking to batch-convert or cross-serve content, it may
be useful. Hack it up and enjoy.

PS: do we have a name for the text/gemini format itself? The spec-spec
just refers to it by media type.


From benulo at systemli.org  Sun May 31 04:10:22 2020
From: benulo at systemli.org (Ben)
Date: Sun, 31 May 2020 07:40:22 +0430
Subject: [ANN] Diohsc: incredibly ordinary haskell client
In-Reply-To: <20200530181141.qj6cbiaff462fk4a@gonzales.net>
References: <20200530181141.qj6cbiaff462fk4a@gonzales.net>
Message-ID: <ca2d12b2-4974-8bfb-fb8f-a2033617b48d@systemli.org>

Sweet! I love Haskell.

How about a server too? Or maybe erlang would be better for that.

On 5/30/20 10:41 PM, Martin Bays wrote:
> I hacked together a little haskell client:
> 
> gemini://gemini.thegonz.net/diohsc/
> https://repo.or.cz/diohsc.git

-- 
gemini://kwiecien.us/

From tkarpiniec at icloud.com  Sun May 31 04:55:26 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Sun, 31 May 2020 13:55:26 +1000
Subject: Ambiguity in unordered list item definition
Message-ID: <20200531035526.GA45400@allanon.local>

Hi,

While testing a GUI text/gemini renderer I noticed that if a line
starts with an ASCII-emphasised word like this:

*Great* times are ahead

Then a spec-compliant browser will turn that into a bullet:

 ?  Great* times are ahead

In the scheme of things it's a minor gotcha but I wonder if everyone
would be happier if some whitespace was required?

I note that this would make it different from the headings, which
specify optional whitespace. It would make parsing slightly easier if
that whitespace was mandatory here too - as it stands, you must check
for "###", "##" and "#" in that order so as to avoid "###Hello" being
a top-level heading of value "##Hello".

None of this greatly matters but I think it's worth noting as
something to watch out for!

Cheers,

Tom

From fkfd at macaw.me  Sun May 31 05:09:34 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Sun, 31 May 2020 12:09:34 +0800
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200531035526.GA45400@allanon.local>
References: <20200531035526.GA45400@allanon.local>
Message-ID: <E9A3A22F-730B-4FB4-A52D-4D28FB8598DA@macaw.me>

This makes so much sense! IMO the whitespace should be mandatory. Just curious, why wasn't `-` (hyphen) for bullet lists?

~fkfd

From solderpunk at SDF.ORG  Sun May 31 11:09:46 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 31 May 2020 10:09:46 +0000
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200531035526.GA45400@allanon.local>
References: <20200531035526.GA45400@allanon.local>
Message-ID: <20200531100946.GB10707@SDF.ORG>

On Sun, May 31, 2020 at 01:55:26PM +1000, Thomas Karpiniec wrote:
> Hi,
> 
> While testing a GUI text/gemini renderer I noticed that if a line
> starts with an ASCII-emphasised word like this:
> 
> *Great* times are ahead
> 
> Then a spec-compliant browser will turn that into a bullet:
> 
>  ?  Great* times are ahead

Yeah, I have noticed this too.  It's minor, like you say, but I will
admit it grates on me.

I guess there are a bunch of things we could do about this.

Solutions that involve changing the spec:

* We could introduce mandatory whitespace before the * character.
* We could replace * with - for list items.

Solutions that don't involve changing the spec:

* Authors could take care to introduce a leading space before text lines
  which begin with emphasised words.
* Geminispace could adopt a convention of emphasising words like _this_
  instead of like *this* (or any other way not involving *s).

I think if we were starting from scratch I would probably use - instead
of * for list items.  This maintains some familiarity from Markdown and
allows *this kind of emphasis* to exist unambiguously alongside
unordered items.  With the recent explosion of both software and content
I'm a little reluctant to change this now as it will make (a little,
yes) work for many people, and chances are good at least half of the
people who made things excitedly on the first weekend after the HN
article have now gotten bored and left and won't change anything, so
we'll end up with long-term visible inconsistencies (which will give
some people the idea that both * and - are valid, ala Markdown,
perpetuating the situation).  It would be a shame to do that for the
sake of something so minor.  Then again, maybe I should be less afraid
of breaking things.  All the content that exists today will hopefully be
a small percentage of all the content what will be created...

> I note that this would make it different from the headings, which
> specify optional whitespace. It would make parsing slightly easier if
> that whitespace was mandatory here too - as it stands, you must check
> for "###", "##" and "#" in that order so as to avoid "###Hello" being
> a top-level heading of value "##Hello".

It's true the checking needs to be done in "reverse" order, but I'm not
sure this is a big problem.  It doesn't need any *more* code than the
other way around, and it's a pretty obvious mistake to notice and fix if
people overlook it on their first try.

Cheers,
Solderpunk

From tkarpiniec at icloud.com  Sun May 31 11:21:17 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Sun, 31 May 2020 20:21:17 +1000
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200531100946.GB10707@SDF.ORG>
References: <20200531035526.GA45400@allanon.local>
 <20200531100946.GB10707@SDF.ORG>
Message-ID: <20200531102117.GA48485@allanon.local>

All makes sense to me!

On Sun, May 31, 2020 at 10:09:46AM +0000, solderpunk wrote:
> Solutions that don't involve changing the spec:
> 
> * Authors could take care to introduce a leading space before text lines
>   which begin with emphasised words.
> * Geminispace could adopt a convention of emphasising words like _this_
>   instead of like *this* (or any other way not involving *s).

I didn't think of such a simple workaround (the leading space). You're
right, I expect it would become common knowledge that you have to look
out for that while composing gemini text.

Not worth making breaking changes for in any case.

Cheers,

Tom

From fkfd at macaw.me  Sun May 31 11:34:40 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Sun, 31 May 2020 18:34:40 +0800
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200531100946.GB10707@SDF.ORG>
References: <20200531035526.GA45400@allanon.local>
 <20200531100946.GB10707@SDF.ORG>
Message-ID: <E2791AE5-661F-4A3F-A64B-C002F375C34A@macaw.me>

On May 31, 2020 6:09:46 PM GMT+08:00, solderpunk <solderpunk at SDF.ORG> wrote:
>On Sun, May 31, 2020 at 01:55:26PM +1000, Thomas Karpiniec wrote:

>I'm a little reluctant to change this now as it will make (a little,
>yes) work for many people, and chances are good at least half of the
>people who made things excitedly on the first weekend after the HN
>article have now gotten bored and left and won't change anything, so
>we'll end up with long-term visible inconsistencies (which will give
>some people the idea that both * and - are valid, ala Markdown,
>perpetuating the situation).  It would be a shame to do that for the
>sake of something so minor.  

But hey look, the magic of free software suggests there's nothing that's set in stone. All can be patched. Personally I don't believe a jury-rigged weekend project would be used by more than a dozen people - who will hop to better clients eventually. The more we postpone refining the spec, the harder it will become to actually do it. That said, my stance is that we deprecate * and adopt - for bullet lists.

~fkfd

From felix at masterq32.de  Sun May 31 11:34:54 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 31 May 2020 12:34:54 +0200
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200531100946.GB10707@SDF.ORG>
References: <20200531035526.GA45400@allanon.local>
 <20200531100946.GB10707@SDF.ORG>
Message-ID: <2f7c6489-7953-f635-f8cf-c597183c35d3@masterq32.de>

Hey!
> It would be a shame to do that for the
> sake of something so minor.  Then again, maybe I should be less afraid
> of breaking things.  All the content that exists today will hopefully be
> a small percentage of all the content what will be created...

Don't be afraid of breaking things for a better spec. I would still
consider Gemini experimental, so that's okay.

My approach would be:

  * Mark `*` at the begin of the line deprecated as a list identifier
    and to be removed in the next iteration of the spec
  * Declare "  *" as the list identifier

It makes lists indented and stand out, also remove the ambiguity.

Right now, my parser would break on that, but it's an easy fix in pretty
much all programming languages as well as the plain text documents:

[]$ sed 's/^*/  */'

Regards
- xq

From pitr.vern at gmail.com  Sun May 31 12:12:09 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sun, 31 May 2020 13:12:09 +0200
Subject: [ANN] Gemini browser for iOS
Message-ID: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>

Super excited to share this. I've been working on this for 2 weeks,
and using it daily as my only Gemini browser.

You need Testflight app, as it is still beta. Please submit bug
reports or suggestions.

https://testflight.apple.com/join/ln6yTtqK

I used Firefox for iOS as a base, like many other browsers on the app
store. All telemetry/tracking code has been removed, and UI simplified
as much as possible. I would like to add support for client
certificates, Gopher protocol, and a few other smaller things.

Source is located here - https://github.com/pitr/gemini-ios - you can
also find a screenshot there.

Cheers!

From alex at alexschroeder.ch  Sun May 31 12:43:45 2020
From: alex at alexschroeder.ch (Alex Schroeder)
Date: Sun, 31 May 2020 13:43:45 +0200
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
Message-ID: <6481C866-D3BA-44E2-B070-5E3EC1F24AD3@alexschroeder.ch>

I love how it renders images! ??

-- 
Typed on a tiny keyboard. Sorry for being terse.

> On 31 May 2020, at 13:12, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
> ?Super excited to share this. I've been working on this for 2 weeks,
> and using it daily as my only Gemini browser.
> 
> You need Testflight app, as it is still beta. Please submit bug
> reports or suggestions.
> 
> https://testflight.apple.com/join/ln6yTtqK
> 
> I used Firefox for iOS as a base, like many other browsers on the app
> store. All telemetry/tracking code has been removed, and UI simplified
> as much as possible. I would like to add support for client
> certificates, Gopher protocol, and a few other smaller things.
> 
> Source is located here - https://github.com/pitr/gemini-ios - you can
> also find a screenshot there.
> 
> Cheers!

From alex at alexschroeder.ch  Sun May 31 12:46:28 2020
From: alex at alexschroeder.ch (Alex Schroeder)
Date: Sun, 31 May 2020 13:46:28 +0200
Subject: Ambiguity in unordered list item definition
In-Reply-To: <2f7c6489-7953-f635-f8cf-c597183c35d3@masterq32.de>
References: <2f7c6489-7953-f635-f8cf-c597183c35d3@masterq32.de>
Message-ID: <46251E6A-73D9-4A0E-AB0C-E780C8DD27FB@alexschroeder.ch>

I suggest we simply add a space after the asterisk if it?s a list item. I also see no harm in supporting both asterisk and the minus for list items.

From solderpunk at SDF.ORG  Sun May 31 12:59:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 31 May 2020 11:59:16 +0000
Subject: Ambiguity in unordered list item definition
In-Reply-To: <46251E6A-73D9-4A0E-AB0C-E780C8DD27FB@alexschroeder.ch>
References: <2f7c6489-7953-f635-f8cf-c597183c35d3@masterq32.de>
 <46251E6A-73D9-4A0E-AB0C-E780C8DD27FB@alexschroeder.ch>
Message-ID: <20200531115916.GE10707@SDF.ORG>

On Sun, May 31, 2020 at 01:46:28PM +0200, Alex Schroeder wrote:
> I also see no harm in supporting both asterisk and the minus for list items.

I guess I see it as "indirect harm".  It adds words to the spec and
bytes to clients without any real advantage.  What's the point in having
more than one easy and familiar and unambiguous way to designate
something?  Sure, it's not going to add *many* words or bytes, but taking
ideas like simplicity and minimalism seriously means pushing back
against small enroachments.  Gemini is explicitly "heavier than Gopher",
but that shouldn't mean we happily take on weight without giving it
thought.

Cheers,
Solderpunk

From mbays at sdf.org  Sun May 31 08:48:22 2020
From: mbays at sdf.org (Martin Bays)
Date: Sun, 31 May 2020 09:48:22 +0200
Subject: [ANN] Diohsc: incredibly ordinary haskell client
In-Reply-To: <ca2d12b2-4974-8bfb-fb8f-a2033617b48d@systemli.org>
References: <20200530181141.qj6cbiaff462fk4a@gonzales.net>
 <ca2d12b2-4974-8bfb-fb8f-a2033617b48d@systemli.org>
Message-ID: <20200531074822.4ww5gzxgvnbafnfn@gonzales.net>

* Sunday, 2020-05-31 at 07:40 +0430 - Ben <benulo at systemli.org>:

>Sweet! I love Haskell.
>How about a server too?

I thought about that, but couldn't come up with a decent pun for the 
name. I might do it anyway, if the mood takes me -- but if someone else 
wants to do it first, carry on.

From luke.emmet at gmail.com  Sun May 31 15:25:37 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sun, 31 May 2020 15:25:37 +0100
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
Message-ID: <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>

Hi Peter

This is very nice, I just tried it.

Possible suggestion - to have an option to show or not show URLs on links. 

Preformatted text seems to be wrapping, might be better  to have a scroll on it instead?

Best wishes

Luke

> On 31 May 2020, at 12:12, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
> Super excited to share this. I've been working on this for 2 weeks,
> and using it daily as my only Gemini browser.
> 
> You need Testflight app, as it is still beta. Please submit bug
> reports or suggestions.
> 
> https://testflight.apple.com/join/ln6yTtqK
> 
> I used Firefox for iOS as a base, like many other browsers on the app
> store. All telemetry/tracking code has been removed, and UI simplified
> as much as possible. I would like to add support for client
> certificates, Gopher protocol, and a few other smaller things.
> 
> Source is located here - https://github.com/pitr/gemini-ios - you can
> also find a screenshot there.
> 
> Cheers!

From jzs at sketchground.dk  Sun May 31 16:44:44 2020
From: jzs at sketchground.dk (jzs)
Date: Sun, 31 May 2020 15:44:44 +0000
Subject: [ANN] Yet another gemlog and server
Message-ID: <Evi1o4BHNohvw7XoHFFhjDpuUfq2OBYT_x7SkuqEO-22xtqPKBjO-YJFBtQiqyMCRBLrW2swqj72zfEPvqeB3Ywp170OoBL1ZFBKr5-_N5E=@sketchground.dk>

Hi all,

Yet another gemlog has appeared!

=> gemini://cozylabs.eu/ cozylabs.eu

I will not stick to particular topics on this gemlog but rather write about what's
on my mind. The first post contains information about my gemini server that i wrote.
It almost feels mandatory to write your own gemini server :)

The server supports comments on the individual posts and the source code is available
for people to study. However you will have to get the links by going to the site ;)

It's only tested in Bombadillo and AV-98 so send a note my way if it does not work in
your preferred gemini browser.

Anyways, I'm happy to join you fellow geminauts on this journey.

/Jens

From peteyboy at sdf.org  Mon Jun  1 07:51:09 2020
From: peteyboy at sdf.org (Pete D.)
Date: Sun, 31 May 2020 23:51:09 -0700
Subject: Ambiguity in unordered list item definition
In-Reply-To: <mailman.5.1590922811.3708.gemini@lists.orbitalfox.eu>
References: <mailman.5.1590922811.3708.gemini@lists.orbitalfox.eu>
Message-ID: <829c562f-c7f0-a8d3-7317-dd4b0c06a9db@sdf.org>

gemini-request at lists.orbitalfox.eu wrote:
> Message: 6
> Date: Sun, 31 May 2020 20:21:17 +1000
> From: Thomas Karpiniec<tkarpiniec at icloud.com>
> To: Gemini application layer protocol<gemini at lists.orbitalfox.eu>
> Subject: Re: Ambiguity in unordered list item definition
> Message-ID:<20200531102117.GA48485 at allanon.local>
> Content-Type: text/plain; charset=us-ascii
>
> All makes sense to me!
>
> On Sun, May 31, 2020 at 10:09:46AM +0000, solderpunk wrote:
>> Solutions that don't involve changing the spec:
>>
>> * Authors could take care to introduce a leading space before text lines
>>    which begin with emphasised words.
>> * Geminispace could adopt a convention of emphasising words like_this_
>>    instead of like*this*  (or any other way not involving *s).
> I didn't think of such a simple workaround (the leading space). You're
> right, I expect it would become common knowledge that you have to look
> out for that while composing gemini text.
>
> Not worth making breaking changes for in any case.
>
> Cheers,
>
> Tom


Doesn't it make more sense to do the *reverse* (see what I did there?), 
by requiring bullet lines to have a space *after* the *?
Because the normal standard for "ascii bold" has no spaces between the 
leading * and the bolded word, as you can see in my mail (if it hasn't 
been already rendered in bold by your mail program.

It would make sense for a bullet to be a space away from the text it is 
bulleting, so that ^[[:star:]][[:space:]] would be a bulleted list, 
while [[:star:]]Thing I want to emphasize[[:star:]]

So only really sloppy ascii-type text would break this, and so then 
maybe it should. And most bulleters would be doing this already (I see 
that that's what I did for my bullets, I'm used to mediawiki, and 
markdown is the same

https://wordpress.com/support/markdown-quick-reference/

    Bullet Lists

    * Item * Item


From solderpunk at SDF.ORG  Mon Jun  1 09:06:01 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 1 Jun 2020 08:06:01 +0000
Subject: Ambiguity in unordered list item definition
In-Reply-To: <829c562f-c7f0-a8d3-7317-dd4b0c06a9db@sdf.org>
References: <mailman.5.1590922811.3708.gemini@lists.orbitalfox.eu>
 <829c562f-c7f0-a8d3-7317-dd4b0c06a9db@sdf.org>
Message-ID: <20200601080601.GB23050@SDF.ORG>

On Sun, May 31, 2020 at 11:51:09PM -0700, Pete D. wrote:
 
> Doesn't it make more sense to do the *reverse* (see what I did there?), by
> requiring bullet lines to have a space *after* the *?
> Because the normal standard for "ascii bold" has no spaces between the
> leading * and the bolded word, as you can see in my mail (if it hasn't been
> already rendered in bold by your mail program.

Ah, I must say, I like "* " better than " *"!  If we did it that way I
suspect much fewer people would need to make changes to their content,
which is a good thing.

Cheers,
Solderpunk

From tkarpiniec at icloud.com  Mon Jun  1 09:12:47 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Mon, 1 Jun 2020 18:12:47 +1000
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200601080601.GB23050@SDF.ORG>
References: <mailman.5.1590922811.3708.gemini@lists.orbitalfox.eu>
 <829c562f-c7f0-a8d3-7317-dd4b0c06a9db@sdf.org>
 <20200601080601.GB23050@SDF.ORG>
Message-ID: <20200601081247.GA70015@allanon.local>

On Mon, Jun 01, 2020 at 08:06:01AM +0000, solderpunk wrote:
> Ah, I must say, I like "* " better than " *"!  If we did it that way I
> suspect much fewer people would need to make changes to their content,
> which is a good thing.

Oops, that's what I meant in the first place! Unfortunately I too was
ambiguous. I didn't realise in the subsequent discussion that I was
misunderstood.

So to restate it clearly, what I was trying to propose was changing
bullets from a line starting with "*" to a line starting with "* ".

Cheers,

Tom

From solderpunk at SDF.ORG  Mon Jun  1 10:50:09 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 1 Jun 2020 09:50:09 +0000
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200601081247.GA70015@allanon.local>
References: <mailman.5.1590922811.3708.gemini@lists.orbitalfox.eu>
 <829c562f-c7f0-a8d3-7317-dd4b0c06a9db@sdf.org>
 <20200601080601.GB23050@SDF.ORG>
 <20200601081247.GA70015@allanon.local>
Message-ID: <20200601095009.GA10564@SDF.ORG>

On Mon, Jun 01, 2020 at 06:12:47PM +1000, Thomas Karpiniec wrote:
 
> Oops, that's what I meant in the first place! Unfortunately I too was
> ambiguous. I didn't realise in the subsequent discussion that I was
> misunderstood.
> 
> So to restate it clearly, what I was trying to propose was changing
> bullets from a line starting with "*" to a line starting with "* ".

Oh, great!

Does anybody *not* like this idea?

Cheers,
Solderpunk

From hannu.hartikainen+gemini at gmail.com  Mon Jun  1 11:00:35 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Mon, 1 Jun 2020 13:00:35 +0300
Subject: GUS database (was: Re: Ambiguity in unordered list item definition)
Message-ID: <CANmFPem_hFpZhGsUP_dpOcSDiXdDqeV9g+g226_AQKdzFEb0Wg@mail.gmail.com>

Just a thought: it would be great if the GUS database was openly available
(for protocol development purposes, at least). With the current amount of
content you could just grep through everything to see if anybody is using
`*listitem` syntax (my guess: no).

Of course with this amount of content everybody could just crawl everything
themselves, but that can't be good etiquette.

On Mon, 1 Jun 2020 at 12:50, solderpunk <solderpunk at sdf.org> wrote:

> On Mon, Jun 01, 2020 at 06:12:47PM +1000, Thomas Karpiniec wrote:
>
> > Oops, that's what I meant in the first place! Unfortunately I too was
> > ambiguous. I didn't realise in the subsequent discussion that I was
> > misunderstood.
> >
> > So to restate it clearly, what I was trying to propose was changing
> > bullets from a line starting with "*" to a line starting with "* ".
>
> Oh, great!
>
> Does anybody *not* like this idea?
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200601/6bf27c16/attachment.htm>

From natpen at natpen.net  Mon Jun  1 14:05:00 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Mon, 1 Jun 2020 09:05:00 -0400
Subject: GUS database (was: Re: Ambiguity in unordered list item
 definition)
In-Reply-To: <CANmFPem_hFpZhGsUP_dpOcSDiXdDqeV9g+g226_AQKdzFEb0Wg@mail.gmail.com>
References: <CANmFPem_hFpZhGsUP_dpOcSDiXdDqeV9g+g226_AQKdzFEb0Wg@mail.gmail.com>
Message-ID: <20200601130500.GC141070@goldfish.localdomain>

Hi Hannu,

On Mon, Jun 01, 2020 at 01:00:35PM +0300, Hannu Hartikainen wrote:
> Just a thought: it would be great if the GUS database was openly available
> (for protocol development purposes, at least). With the current amount of
> content you could just grep through everything to see if anybody is using
> `*listitem` syntax (my guess: no).

I'm not necessarily opposed to sharing GUS' index, and will think
through it more. I do have a few concerns that come to mind
immediately though, about which I'm curious what people think.

* PRIVACY: a lot of folks around here seem to care a lot about it. In
  the current state of Gemini, everything created in Geminispace has a
  fairly high degree of anonymity through obscurity without even
  trying. If I release the index to the world, then it's easy for
  people to do things like search it for email addresses. Or use it to
  create a Gemini archive. People have expressed concern about that in
  the past, because it doesn't give users the agency to take down
  their own content - and now, by whitelisting GUS in their
  robots.txt, they're also implicitly whitelisting those use-cases.

* OVERCOMPLICATION: if I just made a way to enter regex in
  GUS itself, then we could probably all answer the great majority of
  these questions, on demand, without having to download anything, or
  learn the schema, or figure out how to grep it (it's not a standard
  "database" so figuring out how to grep it is actually non-trivial).
  Adding regex support feels pretty compelling to me, because GUS *is*
  essentially an open index

In the meantime, please do feel free to email me and chat about any
index questions you're having trouble answering. In the case of the
unordered list discussion, I just wrote some regex to collect relevant
numbers, and will post them to the other thread!

Yours faithfully,
Natalie

From natpen at natpen.net  Mon Jun  1 14:55:14 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Mon, 1 Jun 2020 09:55:14 -0400
Subject: Ambiguity in unordered list item definition
In-Reply-To: <20200601095009.GA10564@SDF.ORG>
References: <mailman.5.1590922811.3708.gemini@lists.orbitalfox.eu>
 <829c562f-c7f0-a8d3-7317-dd4b0c06a9db@sdf.org>
 <20200601080601.GB23050@SDF.ORG>
 <20200601081247.GA70015@allanon.local>
 <20200601095009.GA10564@SDF.ORG>
Message-ID: <20200601135514.GD141070@goldfish.localdomain>

Interestingly, I could find no existing link lines in Geminispace that
would go out-of-spec with this change. There *are* a number of what
appear to be intended boldings words at the beginning of lines that
would actually go in-spec with this change, since right now they're
technically list items, which seems unintentional to me.

You can find an example on this page:
gemini://carcosa.net/journal/20190925-status.gmi

Aside from several more serendipitous boldings like that, the only
other thing of note I found, which would require an actual change by
Mozz, is this page of tests:
gemini://mozz.us/files/text_formatting_test_20200303.gmi

So, I'm in favor of this change!

Yours faithfully,
Natalie

From pitr.vern at gmail.com  Tue Jun  2 00:31:09 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 2 Jun 2020 01:31:09 +0200
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
Message-ID: <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>

Thanks everyone for trying, and for suggestions. I implemented both,
waiting now on Apple to approve the next build. Regarding showing URL, I
preferred this duri early development, but showing just the title looks
much better :)

Question about client certificates: not sure how other clients implement
this, but I was thinking of generating and using the same client cert for
all sites, and giving an option to create a cert for specific domain. Does
that make sense? Potential problem I see is that main certificate is
something user could be identified by across websites.

On Sun, May 31, 2020 at 16:25 Luke Emmet <luke.emmet at gmail.com> wrote:

> Hi Peter
>
> This is very nice, I just tried it.
>
> Possible suggestion - to have an option to show or not show URLs on links.
>
> Preformatted text seems to be wrapping, might be better  to have a scroll
> on it instead?
>
> Best wishes
>
> Luke
>
> > On 31 May 2020, at 12:12, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> >
> > Super excited to share this. I've been working on this for 2 weeks,
> > and using it daily as my only Gemini browser.
> >
> > You need Testflight app, as it is still beta. Please submit bug
> > reports or suggestions.
> >
> > https://testflight.apple.com/join/ln6yTtqK
> >
> > I used Firefox for iOS as a base, like many other browsers on the app
> > store. All telemetry/tracking code has been removed, and UI simplified
> > as much as possible. I would like to add support for client
> > certificates, Gopher protocol, and a few other smaller things.
> >
> > Source is located here - https://github.com/pitr/gemini-ios - you can
> > also find a screenshot there.
> >
> > Cheers!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/09001fe2/attachment.htm>

From petite.abeille at gmail.com  Tue Jun  2 02:14:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 03:14:39 +0200
Subject: approachabe & frugal & composable 
Message-ID: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>

As it stands, Gemini [1] -and especially Mercury [2]- is refreshingly approachable and  frugal.

A -very minimal- one-liner Gemini client:

# openssl s_client -quiet -crlf -connect gemini.conman.org:1965 <<< gemini://gemini.conman.org/ 2>/dev/null
20 text/gemini
Welcome to Conman Laboraties Gemini Server!

And that is that. The whole Gemini protocol in 3 lines.

But what 3 lines!

A request is a single line containing a fully specified URL.
A successful response is a single line containing the numeric response code, a space, and a content-type.
The canonical content, text/gemini, consists of two core line types: text and link. 
All UTF-8 encoded. Over TLS.

And that is that.

Quite spartan at first glance.

But also, possibly, quite universal.

Fancy jumping the shark over Zawinski's law [3] from the onset?

Combine RFC5092 [4] for the request and RFC2045 [5] for the response:

imap://minbari.example.org/gray-council/;uid=20 <imap://minbari.example.org/gray-council/;uid=20>
20 message/rfc822
Mime-Version: 1.0 
...

Fancy supporting multiple protocols at once?

Look at conman's nifty sigil script [6], which supports HTTP, GEMINI, and GOPHER for good measure. From one CGI script.

In other words, because a Gemini request is a full-fledged URL, it can support any number of protocols, as long as such protocol can be expressed as an URL [7].

Ditto for the response, which can be any media type [8] a Gemini server cares to generate. 

In short, a Gemini URL request combined with a Gemini media type response is quite universal indeed. 


Ditto for the rather unassuming text/gemini content type.

While at its core it only sports 2 line types, the presence of the link line, which is an URL, open the door to infinite composition.

Fancy an atom feed? Add a feed URI [9] in your text/gemini:

=> feed://example.com/entries.atom

Would you like to anchor your text/gemini in a point in time? Perhaps the tag URI can help:

=> tag:example.com,2004-01-01:1234

Indicate a location? A geo URI may help:

=> geo:37.786971,-122.399677

etc, etc, the possibilities are endless.

Quite a lot of firepower for a two lines protocol, with a two line content type :)

--
PA


[1] https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/spec-spec.txt <https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/spec-spec.txt>
[2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi <https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi>
[3] https://en.wikipedia.org/wiki/Jamie_Zawinski <https://en.wikipedia.org/wiki/Jamie_Zawinski>
[4] https://tools.ietf.org/html/rfc5092 <https://tools.ietf.org/html/rfc5092>
[5] https://tools.ietf.org/html/rfc2045 <https://tools.ietf.org/html/rfc2045>
[6] https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua <https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua>
[7] https://en.wikipedia.org/wiki/List_of_URI_schemes <https://en.wikipedia.org/wiki/List_of_URI_schemes>
[8] https://en.wikipedia.org/wiki/Media_type <https://en.wikipedia.org/wiki/Media_type>
[9] https://en.wikipedia.org/wiki/Feed_URI_scheme <https://en.wikipedia.org/wiki/Feed_URI_scheme>
[10] https://en.wikipedia.org/wiki/Tag_URI_scheme <https://en.wikipedia.org/wiki/Tag_URI_scheme>
[11] https://en.wikipedia.org/wiki/Geo_URI_scheme <https://en.wikipedia.org/wiki/Geo_URI_scheme>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/33926e11/attachment-0001.htm>

From defdefred at protonmail.com  Tue Jun  2 07:40:17 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 02 Jun 2020 06:40:17 +0000
Subject: approachabe & frugal & composable
In-Reply-To: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
Message-ID: <eh1BXtM5lj74SeEDU5-I8gpGjZMkzWC-MiJcIJ4vvWVr57IeRX9b4WJAC91mxOw5zlM7qMZKsmkfyQpyheinIpdTbO4eUEMnaYSm8IsJfuM=@protonmail.com>

Maybe Gemini is too open to protect users from the web as it is now...
freD.

??????? Original Message ???????
On Tuesday 2 June 2020 03:14, Petite Abeille <petite.abeille at gmail.com> wrote:

> As it stands, Gemini [1] -and especially Mercury [2]- is refreshingly approachable and  frugal.
>
> A -very minimal- one-liner Gemini client:
>
> # openssl s_client -quiet -crlf -connect gemini.conman.org:1965 <<< gemini://gemini.conman.org/ 2>/dev/null
> 20 text/gemini
> Welcome to Conman Laboraties Gemini Server!
>
> And that is that. The whole Gemini protocol in 3 lines.
>
> But what 3 lines!
>
> A request is a single line containing a fully specified URL.
> A successful response is a single line containing the numeric response code, a space, and a content-type.
> The canonical content, text/gemini, consists of two core line types: text and link.
> All UTF-8 encoded. Over TLS.
>
> And that is that.
>
> Quite spartan at first glance.
>
> But also, possibly, quite universal.
>
> Fancy jumping the shark over Zawinski's law [3] from the onset?
>
> Combine RFC5092 [4] for the request and RFC2045 [5] for the response:
>
> imap://minbari.example.org/gray-council/;uid=20
> 20 message/rfc822
> Mime-Version: 1.0
> ...
>
> Fancy supporting multiple protocols at once?
>
> Look at conman's nifty sigil script [6], which supports HTTP, GEMINI, and GOPHER for good measure. From one CGI script.
>
> In other words, because a Gemini request is a full-fledged URL, it can support any number of protocols, as long as such protocol can be expressed as an URL [7].
>
> Ditto for the response, which can be any media type [8] a Gemini server cares to generate.
>
> In short, a Gemini URL request combined with a Gemini media type response is quite universal indeed.
>
> Ditto for the rather unassuming text/gemini content type.
>
> While at its core it only sports 2 line types, the presence of the link line, which is an URL, open the door to infinite composition.
>
> Fancy an atom feed? Add a feed URI [9] in your text/gemini:
>
> => feed://example.com/entries.atom
>
> Would you like to anchor your text/gemini in a point in time? Perhaps the tag URI can help:
>
> => tag:example.com,2004-01-01:1234
>
> Indicate a location? A geo URI may help:
>
> => geo:37.786971,-122.399677
>
> etc, etc, the possibilities are endless.
>
> Quite a lot of firepower for a two lines protocol, with a two line content type :)
>
> --
> PA
>
> [1] https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/spec-spec.txt
> [2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi
> [3] https://en.wikipedia.org/wiki/Jamie_Zawinski
> [4] https://tools.ietf.org/html/rfc5092
> [5] https://tools.ietf.org/html/rfc2045
> [6] https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua
> [7] https://en.wikipedia.org/wiki/List_of_URI_schemes
> [8] https://en.wikipedia.org/wiki/Media_type
> [9] https://en.wikipedia.org/wiki/Feed_URI_scheme
> [10] https://en.wikipedia.org/wiki/Tag_URI_scheme
> [11] https://en.wikipedia.org/wiki/Geo_URI_scheme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/007a5d92/attachment.htm>

From jmcbray at carcosa.net  Tue Jun  2 13:16:09 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 02 Jun 2020 08:16:09 -0400
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com> (Peter
 Vernigorov's message of "Tue, 2 Jun 2020 01:31:09 +0200")
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
Message-ID: <87ftbdy86u.fsf@dorothy.carcosa.net>

Peter Vernigorov <pitr.vern at gmail.com> writes:

> Question about client certificates: not sure how other clients
> implement this, but I was thinking of generating and using the same
> client cert for all sites, and giving an option to create a cert for
> specific domain. Does that make sense? Potential problem I see is that
> main certificate is something user could be identified by across
> websites.

Yeah, we've discussed previously the idea of a client having a default
client cert it uses for every site, and decided that it's a bad idea,
because it enables cross-site tracking. In general, you shouldn't send a
client cert unless the page you're asking for needs one.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From petite.abeille at gmail.com  Tue Jun  2 16:00:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 17:00:19 +0200
Subject: approachabe & frugal & composable
In-Reply-To: <eh1BXtM5lj74SeEDU5-I8gpGjZMkzWC-MiJcIJ4vvWVr57IeRX9b4WJAC91mxOw5zlM7qMZKsmkfyQpyheinIpdTbO4eUEMnaYSm8IsJfuM=@protonmail.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <eh1BXtM5lj74SeEDU5-I8gpGjZMkzWC-MiJcIJ4vvWVr57IeRX9b4WJAC91mxOw5zlM7qMZKsmkfyQpyheinIpdTbO4eUEMnaYSm8IsJfuM=@protonmail.com>
Message-ID: <5908F34D-F77C-4494-8A99-EA1DD2626B22@gmail.com>



> On Jun 2, 2020, at 08:40, defdefred <defdefred at protonmail.com> wrote:
> 
> Maybe Gemini is too open to protect users from the web as it is now...
> 

How so? 

Gemini/Mercury has a quite impressive "power to weight ratio". A poster child for the principle of parsimony. Bravo.

Such power, in and by itself,  in no way help, hinder, or compromise anything on its own.

Time will tell how it's actually used.

From solderpunk at SDF.ORG  Tue Jun  2 19:19:22 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 18:19:22 +0000
Subject: approachabe & frugal & composable
In-Reply-To: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
Message-ID: <20200602181922.GC16068@SDF.ORG>

Howdy,

Thanks for this enthusiastic summary of your very positive feelings
about Gemini!  I like the "approchable and frugal" characterisation.

I fully share your enthusiasm about Gemini as a protocol, i.e. the use
of nothing but URLs as requests as the the reduction of response headers
to explicit status information and a media type.  I really think that
good design decisions have been made in this part of the spec and I
don't think there's really anything there to change (note that the
intended addition of the `lang` parameter is *not* a change to this
level of the protocol, but rather an extension of the text/gemini media
type which is a separte thing).  On this front, I am content.

I can't quite get as enthusiastic as you are about the range of
possibilities for text/gemini.  I fully grant that everything you wrote
about is totally valid as text/gemini is currently specced.  I will not
even deny that many of your proposals seem genuinely super useful.  E.g.
I am by now a well-documented fan of Atom feeds, and the feed: URI
scheme could be used as a way to add autodiscovery of feeds to Gemini,
circumventing the fact that we have no <rel> tags.  And the tag: URI
scheme is also a nice way to put an unambiguous timestamp on a document.
Not only could this be very useful for search purposes, but it would
simplify the automatic generation of Atom feeds (it's now very clear
that the use of filesystem timestamps as used by gemfeed is not robust
against different people's workflows).

However, it's also true that none of this is stuff I ever envisaged
being in Gemini, because I had a naive mental model of what URIs were.

I feel kind of powerless to prevent the use of these schemes.  I don't
want the Gemini spec to include an explicit whitelist or blacklist or
schemes (although I'm tempted to forbid data:).  This will lead to a
maintenance nightmare as new schemes are proposed (I don't want to be
constantly updating Gemini, I want to try to "get it right" and then
just leave it be), feels authoritarian, and will anyway be unenforcible
if popular opinion wants to use a certain scheme.  So, it seems this
stuff is going to happen.

My big concern is not simply that people will do things with Gemini that
I didn't envision.  That was always going to happen to some extent
anyway.  My concern is that this stuff substantially complicates the job
of designing and implementing clients.

When text/gemini was designed, I used the mental model of "URIs as
pointers to stuff you could fetch off the internet".  This is clearly
what links lines were "supposed to be".  The spec says that clients can
render those lines however they like, but because of that limited sense
of what a URI could be, it went without saying that:

* Every link gets displayed to the user
* Every link is treated identically for the purposes of display
* The basic notion of what's happening is that the client is extending
  an option to the user - "Here is some stuff you can get, if you want
  it".

In short, there was supposed to be a single, concrete "unit of
interface" with narrow scope that a client author has to decide how to
implement.  Variation between clients in how that was done would not
substantially change the overall user experience.

With stuff like data:, feed:, tag:, geo:, and the myriad other
"non-locational schemes", all of this goes out the window.  What is a
client supposed to do with all these?  If I want to write a minimal
client that just knows how to follow gemini:// links and nothing else,
what the heck do I do with a tag: link?  Display it to the user, or
hide it?  If I choose to display it using exactly the same code path I
would use to to display a gemini:// link, I need to go out of my way
to make that code path robust against stuff that doesn't make sense for
"proper" links, like there not being a "netloc" component (AV-98
currently silently drops tag: links, for example, because they cause an
Exception when I try to handle them as if they were a "proper" link).
If I *do* successfully display them as if they were a proper link and
the user tries to follow one, what is supposed to happen?  Assuming I
fix the aforementioned problem, AV-98 will say "Sorry, no support for
tag", because it fills out a template that I designed thinking of cases
like "Sorry, no suport for ftp", which most users will understand.  *I*
would be very confused by a "no support for tag" message, I'd think
"What, there *are* no tags in Gemini, what's going on here?".

Basically the problem left to the discretion of client authors has
changed from a simple and obvious one to one that is rather more
open-ended, and the natural result will be greater variation in the
actual user experience across clients, authors being confused when their
content doesn't render the way they expect it to in some clients (a
familiar experience with the web which it's tragic to recreate in
Gemini!), and users being confused when their client talks about tags
and geos as if they were network protocols.  None of this is a good
thing!  Nothing is supposed to be this open-ended in Gemini!

So, I'm not sure how to proceed here.  People should feel free to
experiment with possibilities, because informed decisions are better
than uninformed ones.  But I would advise people not to get fiercely
attached to any idea of how non-locational URLs might work in Gemini.
It's uncharted territory.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jun  2 19:31:46 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 18:31:46 +0000
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
Message-ID: <20200602183146.GD16068@SDF.ORG>

On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote:
 
> Question about client certificates: not sure how other clients implement
> this, but I was thinking of generating and using the same client cert for
> all sites, and giving an option to create a cert for specific domain. Does
> that make sense? Potential problem I see is that main certificate is
> something user could be identified by across websites.

It's not super clear to me what you're suggesting.

If it's that the client generates a single self-signed client cert the
first time it starts up and then just sends that cert to every single
host as part of every single request: PLEASE DON'T DO THAT!  This is
about as wrong an implementation of Gemini's idea of client certificates
as possible.  The vast majority of URLs will not require or expect a
client cert (which is why there's a way for servers to explicitly
request one in the unusual circumstance it's needed), and any you send
will just be ignored.  You will be needlessly increasing the TLS overhead
(which is already pretty heavy relative to typical text/gemini payload
sizes) for no gain.  Worse, admins of unrelated servers would be able to
compare their logs and track you across Geminispace.

If it's that you generate a single certificate the first time it starts
up but only send it out in response to a status code of 62 that's a
different matter (I assume it goes without saying you shouldn't ever use
it in response to a status code of 61 because the behaviour for
transient certs is extremely clearly specced and this would fly in the
face of just about every part of it).  I still think it's the wrong
thing to do, but it's slightly less disasterous than the first option.

Client certificates should be handled in a very deliberate manner - the
user needs make the clear decision to opt in, on their own terms, to
being identified to some server(s).  It's an exceptional condition and
should never be automated or hidden from the user for the sake of
convenience.  Sharing a single certificate across domains isn't
something anybody should ever do lightly.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jun  2 19:32:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 18:32:54 +0000
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <87ftbdy86u.fsf@dorothy.carcosa.net>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <87ftbdy86u.fsf@dorothy.carcosa.net>
Message-ID: <20200602183254.GE16068@SDF.ORG>

On Tue, Jun 02, 2020 at 08:16:09AM -0400, Jason McBrayer wrote:
 
> Yeah, we've discussed previously the idea of a client having a default
> client cert it uses for every site, and decided that it's a bad idea,
> because it enables cross-site tracking. In general, you shouldn't send a
> client cert unless the page you're asking for needs one.

Did we?  I don't remember that!  I hope everybody was pretty staunchly
opposed to the idea...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jun  2 19:48:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 18:48:29 +0000
Subject: Call for AV-98 testing
In-Reply-To: <20200523132839.GD12486@SDF.ORG>
References: <20200523132839.GD12486@SDF.ORG>
Message-ID: <20200602184829.GG16068@SDF.ORG>

On Sat, May 23, 2020 at 01:28:39PM +0000, solderpunk wrote:
 
> I'm preparing to finally do a 1.0.0 release of AV-98 this weekend and
> would appreciate people helping me kick the tyres.  Once the release is
> made you'll be able to install it with pip, but for now you need to
> clone the repo:

Just to follow up on this now "overdue" release:  I've been getting lots
of helpful bug reports, pull requests and suggestions from people, which
is great.  Thank you all!  I decided to put off the release until a few
days went by without any such thing coming in, which will hopefully
happen soon.

Cheers,
Solderpunk

From colecmac at protonmail.com  Tue Jun  2 19:49:01 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 02 Jun 2020 18:49:01 +0000
Subject: Relative links vs scheme-less links
Message-ID: <7tLKoby9_tKEB5UW_wru5HOpJUqes3bx8a3N7ZUl6DTRGJ7NXHuBx6dFWMaIFfC7tzNzNDZruhMEwHPbfW7raZ9cAefzUlB8tiaegbs-XAc=@protonmail.com>

I was browsing in Bombadillo and just noticed something:
If I follow a link without a scheme, it just assumes it's a relative
link. This works fine when it actually is a relative link, but what
about this?

=> makeworld.gq/gemlog/ Link to gemlog

As humans, most of the time we would assume that to be a scheme-less
link, but Bombadillo will actually try and resolve that as a relative
link. And why not? It very well could be.

I am just writing these wrong, and scheme-less links should always start
with `//`? The spec says "a scheme of gemini:// is implied", so I assumed
having those would be redundant.


makeworld



From petite.abeille at gmail.com  Tue Jun  2 20:09:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 21:09:47 +0200
Subject: approachabe & frugal & composable
In-Reply-To: <20200602181922.GC16068@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
Message-ID: <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>



> On Jun 2, 2020, at 20:19, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> With stuff like data:, feed:, tag:, geo:, and the myriad other
> "non-locational schemes", all of this goes out the window.  What is a
> client supposed to do with all these?

Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'.

In short, only decorate scheme you know, leave the rest alone, and render it as static text.

Never hide anything. 

Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client.

More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort.

And that is that.



From petite.abeille at gmail.com  Tue Jun  2 20:17:00 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 21:17:00 +0200
Subject: Relative links vs scheme-less links
In-Reply-To: <7tLKoby9_tKEB5UW_wru5HOpJUqes3bx8a3N7ZUl6DTRGJ7NXHuBx6dFWMaIFfC7tzNzNDZruhMEwHPbfW7raZ9cAefzUlB8tiaegbs-XAc=@protonmail.com>
References: <7tLKoby9_tKEB5UW_wru5HOpJUqes3bx8a3N7ZUl6DTRGJ7NXHuBx6dFWMaIFfC7tzNzNDZruhMEwHPbfW7raZ9cAefzUlB8tiaegbs-XAc=@protonmail.com>
Message-ID: <FE15A672-0EDF-48B2-8E95-CD0339D0821F@gmail.com>



> On Jun 2, 2020, at 20:49, colecmac at protonmail.com wrote:
> 
> I am just writing these wrong, and scheme-less links should always start
> with `//`? The spec says "a scheme of gemini:// is implied", so I assumed
> having those would be redundant.

Sometime, the simplest things turn out not to be so simple :)

See RFC-3986, section 5.2.2, Relative Resolution:

https://tools.ietf.org/html/rfc3986#section-5.2

And of course, all of Sean's torture tests:

https://portal.mozz.us/gemini/gemini.conman.org/test/torture/

From plugd at thelambdalab.xyz  Tue Jun  2 20:24:16 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Tue, 02 Jun 2020 21:24:16 +0200
Subject: Relative links vs scheme-less links
In-Reply-To: <7tLKoby9_tKEB5UW_wru5HOpJUqes3bx8a3N7ZUl6DTRGJ7NXHuBx6dFWMaIFfC7tzNzNDZruhMEwHPbfW7raZ9cAefzUlB8tiaegbs-XAc=@protonmail.com>
References: <7tLKoby9_tKEB5UW_wru5HOpJUqes3bx8a3N7ZUl6DTRGJ7NXHuBx6dFWMaIFfC7tzNzNDZruhMEwHPbfW7raZ9cAefzUlB8tiaegbs-XAc=@protonmail.com>
Message-ID: <lz367dp8yn.fsf@bs-mbpr348.d.ethz.ch>

colecmac at protonmail.com writes:
> link. This works fine when it actually is a relative link, but what
> about this?
> => makeworld.gq/gemlog/ Link to gemlog

> I am just writing these wrong, and scheme-less links should always start
> with `//`? The spec says "a scheme of gemini:// is implied", so I assumed
> having those would be redundant.

The // are part of the authority section of the URI, which includes the
host.  If this weren't the case, the intepretation of the URI would be ambiguous.

To specify the host but not the scheme you need
=> //makeworld.gq/gemlog/

Sean's client torture test is actually a great source of information on
things like this, and any client that passes it is going to behave in
the same way.  It'd be nice to have it made explict somewhere else too.

plugd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/d7f5be9f/attachment.sig>

From solderpunk at SDF.ORG  Tue Jun  2 20:26:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 19:26:58 +0000
Subject: Three month spec freeze
In-Reply-To: <20200301170659.GB7582@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG>
Message-ID: <20200602192658.GB11961@SDF.ORG>

Ahoy,

As of yesterday, the freeze is over!  The spec is now "liquid" once again.

Many people involved in Gemini now were not here for the original freeze
announcement, so I want to give this some context.

The spec is now open to non-trivial changes again, but this is not a time
to start suggesting new features "willy nilly".  The idea behind the
freeze was to give everybody the chance to build things, or try to build
things, using the spec as it stood, so that at the end of the freeze we
could make changes which solved actual concrete problems people had run
into using Gemini in the real world.  The idea is that we then fix those
problems as best we can, and do another freeze.  I want each freeze to
last longer than the previous, and for the changes we make to get smaller
and smaller each time.  We should not expect any major changes and
certainly no new totally new capabilities to enter the spec at this point.
We are in the "polishing" phase.

A lot happened during these last three months!  Notably, Astrobotany
appeared as the first non-trivial use of client certificates, revealing
how poorly specced that whole thing was (and is).  Non-English content
appeared in Geminispace for the first time (and may much more follow!),
prompting questions related to search and accessibility in a
multilingual space.  People started using pre-formatted lines in ways
not conducive to search or accessibility, raising more questions on
these topics.  Plus a whole pile of tiny ambiguities or inconsistencies
were spotted, many of which I pre-emptively cleaned up so that we could
now focus on these bigger issues.  No dout many more remain!

I really think there is more than enough on our plate to deal with
before announcing another freeze, so I'm not really looking for more
suggestions on things to change.  But if anybody thinks they see a real
problem with the design of anything currently in the protocol, in
principle now is the time to mention it.

I will start making changes to the spec to fix the problems described
above in the near future.  I'm not sure when I will formally announce
the next freeze, but I expect it to be in weeks, not days or months.  As
always I'll share my thoughts with the list and solicit feedback about
proposed changes before making them official.

Cheers,
Solderpunk

From pitr.vern at gmail.com  Tue Jun  2 20:44:08 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 2 Jun 2020 21:44:08 +0200
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <20200602183146.GD16068@SDF.ORG>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
Message-ID: <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>

Thanks. These responses and re-reading the spec clarified my initial
concern. Spec clearly states that transient certificates should not be
shared across domains. And there is no point using permanent certificates
across domains as it is assumed that these certificates have a special
meaning for specific domains.

I am still unclear as to what happens after a transient certificate has
been created. Should browser automatically use it for the page that
requested it and any other pages on that domain? I don?t see a good
solution here. Either certificate is sent only when server requests it,
which would double number of requests (assuming user stays in private
section of the site), or certificate is always sent, which adds overhead to
all requests. Should browser remember which pages need a certificate and
always use it for them?

And additionally, should browser ask user for every page that requires a
certificate if existing one can be used?

Thanks for replying to my earlier questions. I want to make sure that my
support for certificates doesn?t violate the spec or creates a bad user
experience.

On Tue, Jun 2, 2020 at 20:31 solderpunk <solderpunk at sdf.org> wrote:

> On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote:
>
> > Question about client certificates: not sure how other clients implement
> > this, but I was thinking of generating and using the same client cert for
> > all sites, and giving an option to create a cert for specific domain.
> Does
> > that make sense? Potential problem I see is that main certificate is
> > something user could be identified by across websites.
>
> It's not super clear to me what you're suggesting.
>
> If it's that the client generates a single self-signed client cert the
> first time it starts up and then just sends that cert to every single
> host as part of every single request: PLEASE DON'T DO THAT!  This is
> about as wrong an implementation of Gemini's idea of client certificates
> as possible.  The vast majority of URLs will not require or expect a
> client cert (which is why there's a way for servers to explicitly
> request one in the unusual circumstance it's needed), and any you send
> will just be ignored.  You will be needlessly increasing the TLS overhead
> (which is already pretty heavy relative to typical text/gemini payload
> sizes) for no gain.  Worse, admins of unrelated servers would be able to
> compare their logs and track you across Geminispace.
>
> If it's that you generate a single certificate the first time it starts
> up but only send it out in response to a status code of 62 that's a
> different matter (I assume it goes without saying you shouldn't ever use
> it in response to a status code of 61 because the behaviour for
> transient certs is extremely clearly specced and this would fly in the
> face of just about every part of it).  I still think it's the wrong
> thing to do, but it's slightly less disasterous than the first option.
>
> Client certificates should be handled in a very deliberate manner - the
> user needs make the clear decision to opt in, on their own terms, to
> being identified to some server(s).  It's an exceptional condition and
> should never be automated or hidden from the user for the sake of
> convenience.  Sharing a single certificate across domains isn't
> something anybody should ever do lightly.
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/597d8546/attachment.htm>

From petite.abeille at gmail.com  Tue Jun  2 20:57:27 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 21:57:27 +0200
Subject: Three month spec freeze
In-Reply-To: <20200602192658.GB11961@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
Message-ID: <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>



> On Jun 2, 2020, at 21:26, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> As of yesterday, the freeze is over!  The spec is now "liquid" once again.

Cool. Can we remove things? :)


? drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings. 

Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?).


? drop everything from text/gemini but text and link lines.

Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.


? mandate >= TLS 1.3. Drop legacy support. 

Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation.


In short, Mercury over TLS [1] :)


Networking Truths #12 [2]:

In protocol design, perfection has been reached not when thereis nothing left to add, but when there is nothing left to take away.

This would make Saint-Exup?ry proud.


[1] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi
[2] https://tools.ietf.org/html/rfc1925







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/3d68568c/attachment-0001.htm>

From solderpunk at SDF.ORG  Tue Jun  2 21:00:42 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 20:00:42 +0000
Subject: approachabe & frugal & composable
In-Reply-To: <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
Message-ID: <20200602200042.GC11961@SDF.ORG>

On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote:
 
> Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'.
> 
> In short, only decorate scheme you know, leave the rest alone, and render it as static text.
> 
> Never hide anything. 
> 
> Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client.
> 
> More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort.
> 
> And that is that.
 
This sounds "short and sweet" and simple, but this basically makes
Gemini infinitely extensible.  Link lines stop having anything to do
with the concept of "links", and become vehicles for anything that
somebody wants to come up with a URI scheme for, which is a large and
totally open category which will grow over time and may come to include
very scary things (for the love of God, there was an IETF draft for a
javascript: scheme! [1]).  Giving clients the power to recognise any old
scheme which comes along is guaranteed to induce a repeat of the
evolution of the web.  Basically we can now think of the line:

=> scheme:restofuri Human friendly label

as equivalent to something like:

<scheme arg1="restofuri" arg2="Human friendly label"/>

text/gemini would be fully as extensible as HTML where client authors
can just invent new tags like <blink> and <marquee>.  It's exactly what
nobody here wants.

I am *so angry* that there isn't a construct in the internet
architecture which is *nothing more* than a convenient way to concisely
specify an application protocol, a hostname or IP address, a port, and
a path.  This is such an obviously useful thing to have.  It's what
almost everybody *thinks* a URL is, but it turns out that's wrong.  Who
would have thought that Gopher's clunky and archaic notation of:

path<TAB>hostname<TAB>port<TAB>

literally has not been improved on in ~30 years?

At this point I am honestly considering speccing that => lines may
*only* use URLs whose scheme corresponds to an application protocol.
Permitting *any* RFC-compliant URL is just way, way too open-ended and
defeats the point of so much careful efforts elsewhere in the protocol.

Cheers,
Solderpunk

From colecmac at protonmail.com  Tue Jun  2 21:04:12 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 02 Jun 2020 20:04:12 +0000
Subject: Relative links vs scheme-less links
In-Reply-To: <lz367dp8yn.fsf@bs-mbpr348.d.ethz.ch>
References: <7tLKoby9_tKEB5UW_wru5HOpJUqes3bx8a3N7ZUl6DTRGJ7NXHuBx6dFWMaIFfC7tzNzNDZruhMEwHPbfW7raZ9cAefzUlB8tiaegbs-XAc=@protonmail.com>
 <lz367dp8yn.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <cck3O0p4rdybAsZZIpl7N6TAlLkHtAx6vTVA-BrQhc0BHIcNIE-mXzPBfv53znhJZBuOb5jDnptV4d0gpuzwJeb88TeQHBtp3fvQxES2qYM=@protonmail.com>

Okay, I stand corrected. Thanks!


makeworld

??????? Original Message ???????
On Tuesday, June 2, 2020 3:24 PM, plugd <plugd at thelambdalab.xyz> wrote:

> colecmac at protonmail.com writes:
>
> > link. This works fine when it actually is a relative link, but what
> > about this?
> > => makeworld.gq/gemlog/ Link to gemlog
>
> > I am just writing these wrong, and scheme-less links should always start
> > with `//`? The spec says "a scheme of gemini:// is implied", so I assumed
> > having those would be redundant.
>
> The // are part of the authority section of the URI, which includes the
> host. If this weren't the case, the intepretation of the URI would be ambiguous.
>
> To specify the host but not the scheme you need
> => //makeworld.gq/gemlog/
>
> Sean's client torture test is actually a great source of information on
> things like this, and any client that passes it is going to behave in
> the same way. It'd be nice to have it made explict somewhere else too.
>
> plugd



From colecmac at protonmail.com  Tue Jun  2 21:10:47 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 02 Jun 2020 20:10:47 +0000
Subject: Three month spec freeze
In-Reply-To: <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
Message-ID: <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>

I am in favour of 1, but not 2 or 3.

Regarding 1:
Is there a valid usecase for serving non UTF-8 content? It is unlikely to be supported
and should just be converted. But on the other hand, I don't feel like it's a huge issue
if it's allowed. And `charset` is a part of the MIME media type anyway, so it's always
valid.

Regarding 2:
I think that preformatted text lines are very important for rendering
purposes and I would be sad to see them go. I don't feel strongly about list
lines, but now that they're here it seems good to keep them.

Regarding 3:
Solderpunk has already indicated that this would be nice, but not all language libraries
support it. I'd rather have TLS 1.2 still supported, so that all existing (and future)
clients and servers can work.


makeworld

??????? Original Message ???????
On Tuesday, June 2, 2020 3:57 PM, Petite Abeille <petite.abeille at gmail.com> wrote:

> > On Jun 2, 2020, at 21:26, solderpunk <solderpunk at SDF.ORG> wrote:
> >
> > As of yesterday, the freeze is over! ?The spec is now "liquid" once again.
>
> Cool. Can we remove things? :)
>
> ??drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings.?
>
> Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?).
>
> ? drop everything from text/gemini but text and link lines.
>
> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...).?text/gemini will not move the state of the art. Keep it simple. Less is more.
>
> ? mandate >= TLS 1.3. Drop legacy support.?
>
> Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation.
>
> In short, Mercury over TLS [1] :)
>
> Networking Truths #12 [2]:
>
> In protocol design, perfection has been reached not when thereis nothing left to add, but when there is nothing left to take away.
>
> This would make?Saint-Exup?ry proud.
>
> [1] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi
> [2]?https://tools.ietf.org/html/rfc1925



From felix at masterq32.de  Tue Jun  2 21:14:59 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 2 Jun 2020 22:14:59 +0200
Subject: Three month spec freeze
In-Reply-To: <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
Message-ID: <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>

Heya!

> I am in favour of 1, but not 2 or 3.
Everything makeworld said.

+1 for (1)
+1 for (2)
-1 for (3)

Note on (1):
I strongly recommend supporting utf-8 only. iconv -l lists 1179
possible/known encodings. I don't want to support more than one in my
code, most libraries don't support more than UTF-8, UTF-16, UTF-32 and
ASCII. And for UTF-16 and UTF-32 not even a difference between little
and big endian encoded data.

Encoding is hell, enforcing UTF-8 solves this and is even ASCII compatible

Regards
- xq

From petite.abeille at gmail.com  Tue Jun  2 21:21:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 22:21:43 +0200
Subject: approachabe & frugal & composable
In-Reply-To: <20200602200042.GC11961@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
Message-ID: <3892A94D-C223-4E40-A576-63B871CA027D@gmail.com>



> On Jun 2, 2020, at 22:00, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Permitting *any* RFC-compliant URL is just way, way too open-ended and
> defeats the point of so much careful efforts elsewhere in the protocol.

I suspect you are overthinking it :)

URIs are a good thing.

Thinks of them as structured tags.

Nothing more, nothing less.

They do not imply any behavior, but rather convey information. Structured information.

When writing my next great novel, I *do* want to stick a recognizable ISBN to it:

URN:ISBN:978-0061148521

Uniform Resource Names (URN) Namespaces
https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

https://tools.ietf.org/html/rfc2141







From colecmac at protonmail.com  Tue Jun  2 21:25:53 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 02 Jun 2020 20:25:53 +0000
Subject: Three month spec freeze
In-Reply-To: <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
Message-ID: <7YLjxtfG2Jt350Ct_THjmcMrM0bi8EZBcaO-GQvFY-4Vv1vjGqgyLihNW5iZzxw4OzqKFXQoUIfwEeMj_m5LhwPqd63TdyM-GUV1sYBUy6w=@protonmail.com>

> +1 for (2)

So you're for Option 2 of what Abeille said? Could you elaborate on that?


makeworld



From colecmac at protonmail.com  Tue Jun  2 21:27:38 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 02 Jun 2020 20:27:38 +0000
Subject: approachabe & frugal & composable
In-Reply-To: <20200602200042.GC11961@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
Message-ID: <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>

> At this point I am honestly considering speccing that => lines may
*only* use URLs whose scheme corresponds to an application protocol.
Permitting *any* RFC-compliant URL is just way, way too open-ended and
defeats the point of so much careful efforts elsewhere in the protocol.

I would be in favour of this, I don't want to start seeing pages that
have tags on them.


makeworld

??????? Original Message ???????
On Tuesday, June 2, 2020 4:00 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote:
>
> > Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'.
> > In short, only decorate scheme you know, leave the rest alone, and render it as static text.
> > Never hide anything.
> > Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client.
> > More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort.
> > And that is that.
>
> This sounds "short and sweet" and simple, but this basically makes
> Gemini infinitely extensible. Link lines stop having anything to do
> with the concept of "links", and become vehicles for anything that
> somebody wants to come up with a URI scheme for, which is a large and
> totally open category which will grow over time and may come to include
> very scary things (for the love of God, there was an IETF draft for a
> javascript: scheme! [1]). Giving clients the power to recognise any old
> scheme which comes along is guaranteed to induce a repeat of the
> evolution of the web. Basically we can now think of the line:
>
> => scheme:restofuri Human friendly label
>
> as equivalent to something like:
>
> <scheme arg1="restofuri" arg2="Human friendly label"/>
>
> text/gemini would be fully as extensible as HTML where client authors
> can just invent new tags like <blink> and <marquee>. It's exactly what
> nobody here wants.
>
> I am so angry that there isn't a construct in the internet
> architecture which is nothing more than a convenient way to concisely
> specify an application protocol, a hostname or IP address, a port, and
> a path. This is such an obviously useful thing to have. It's what
> almost everybody thinks a URL is, but it turns out that's wrong. Who
> would have thought that Gopher's clunky and archaic notation of:
>
> path<TAB>hostname<TAB>port<TAB>
>
> literally has not been improved on in ~30 years?
>
> At this point I am honestly considering speccing that => lines may
> only use URLs whose scheme corresponds to an application protocol.
> Permitting any RFC-compliant URL is just way, way too open-ended and
> defeats the point of so much careful efforts elsewhere in the protocol.
>
> Cheers,
> Solderpunk



From felix at masterq32.de  Tue Jun  2 21:31:17 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 2 Jun 2020 22:31:17 +0200
Subject: Three month spec freeze
In-Reply-To: <7YLjxtfG2Jt350Ct_THjmcMrM0bi8EZBcaO-GQvFY-4Vv1vjGqgyLihNW5iZzxw4OzqKFXQoUIfwEeMj_m5LhwPqd63TdyM-GUV1sYBUy6w=@protonmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <7YLjxtfG2Jt350Ct_THjmcMrM0bi8EZBcaO-GQvFY-4Vv1vjGqgyLihNW5iZzxw4OzqKFXQoUIfwEeMj_m5LhwPqd63TdyM-GUV1sYBUy6w=@protonmail.com>
Message-ID: <7dfce874-f1bb-19aa-54c7-df865a4c8dab@masterq32.de>



On 02.06.20 22:25, colecmac at protonmail.com wrote:
>> +1 for (2)
> 
> So you're for Option 2 of what Abeille said? Could you elaborate on that?
Maybe i'm just tired and/or distracted? Had a hard day.

No, i'm against dropping headings and other formatting (really nice for
outlining [0]).


+1 for (1)
-1 for (2)
-1 for (3)

Regards
- xq

[0] https://mq32.de/public/d6de3871ba066477b12a9e64411ea7308b31b8b4.png

From solderpunk at SDF.ORG  Tue Jun  2 21:33:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 20:33:03 +0000
Subject: Three month spec freeze
In-Reply-To: <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
Message-ID: <20200602203303.GD11961@SDF.ORG>

On Tue, Jun 02, 2020 at 09:57:27PM +0200, Petite Abeille wrote:
> > 
> > As of yesterday, the freeze is over!  The spec is now "liquid" once again.
> 
> Cool. Can we remove things? :)

Yes, but not willy nilly. :)

> ? drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings. 
> 
> Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?).

Being "about the future" shouldn't mean "losing the ability to view the
past".

Clients are very explicitly permitted not to burden themselves with
legacy charset conversions.  From section 3.3:

> Compliant clients MUST support UTF-8-encoded text/* responses.
> Clients MAY optionally support other encodings.  Clients receiving a
> response in a charset they cannot decode SHOULD gracefully inform
> the user what happened instead of displaying garbage.

If the majority of clients don't support anything other than UTF-8
(which is likely, because adding support for other things is not fun,
and many Gemini clients will be written for fun as small
single-developer or small-team projects), this will exert a strong
pressure for people to only author in UTF-8 (which is also very
strongly encouraged in the Best Practices document that nobody reads),
as well as motivate the inclusion of automatic transcoding in servers.

> ? drop everything from text/gemini but text and link lines.
> 
> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.
 
My biggest objection to this is the heading lines, which I actually don't
see as fundamentally about formatting at all (although obviously clients
*can* use it as a hint for formatting and many do), but rather about
imparting genuine semantic structure to a text/gemini document.  Gemfeed
uses these headers to "just know" how to title entries in a feed and how
to title feeds themselves.  Lightweight CMS software could use them to
generate a directory listing of documents using their titles instead of
their filenames, relieving authors of the need to duplicate the title in
both post.gmi *and* index.gmi.  Clients can use it to let users skip
through long documents by section or subsection, or to display a table
of contents.  Those headers don't just look pretty in some clients, they
can and should do real actual work which genuinely enhances the
experience of consuming textual content.  I honestly think that getting
rid of those would be a case of "less is less".

> ? mandate >= TLS 1.3. Drop legacy support. 
> 
> Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation.

Funny you should mention this. Just today (or yesterday?) a new LibreSSL
version was released which now enables TLS 1.3 support in both clients
and servers by default.  The only reason I didn't spec 1.3 in the first
place was because I didn't want to discourage the use of LibreSSL which
is a project I support a lot (and which the first ever Gemini server
happened to be built with!).  I used to think that as soon as TLS 1.3
came to LibreSSL, I would make exactly this change.

...

Since then I have also learned about BearSSL, which is *another*
implementation I really don't want to discourage use of due to its
extremely small footprint which I feel aligns nicely with Gemini's
philosophy.

That said, the odds of 1.3 support appearing in BearSSL any time soon
seem slim, so waiting for this as well could doom us to never ditching
1.2.

So, I will consider this.  Feedback from implementers welcome.
Statistics on how many known servers support 1.3 especially welcome!

Just for the record, that never-read Best Practices document also
encourages people implementing TLS 1.2 to limit the ciphersuite to
something 1.3-esque.
 
> In protocol design, perfection has been reached not when thereis nothing left to add, but when there is nothing left to take away.
> 
> This would make Saint-Exup?ry proud.

This quote has always been dear to my heart. :)

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jun  2 21:51:13 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 20:51:13 +0000
Subject: Three month spec freeze
In-Reply-To: <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
Message-ID: <20200602205113.GE11961@SDF.ORG>

On Tue, Jun 02, 2020 at 10:14:59PM +0200, Felix Quei?ner wrote:

> I strongly recommend supporting utf-8 only.

Noted, but...

> I don't want to support more than one in my
> code

You don't have to!  Support UTF-8 and you are spec compliant.

> most libraries don't support more than UTF-8, UTF-16, UTF-32 and
> ASCII.

Oh, now that can't be true.  Loads of content produced on Windows
computers is saved in some silly legacy ISO-whatever encoding that
Microsoft refuses to drop.  Any library used by working programmers
in the "real world" of commercial software needs to be able to deal
with that, at least.
 
> Encoding is hell

It's really not that bad at all in a situation, like Gemini (and
unlike Gopher!), where you get told precisely what the encoding is.
AV-98 does this:

---
if mime.startswith("text/"):
    encoding = mime_options.get("charset", "UTF-8")
    try:
        body = body.decode(encoding)                                                                 
    except UnicodeError:
        print("Could not decode response body using %s encoding declared in header!" % encoding)
        return
---

Hardly a nightmare!

Cheers,
Solderpunk

From petite.abeille at gmail.com  Tue Jun  2 21:56:49 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 22:56:49 +0200
Subject: Three month spec freeze
In-Reply-To: <20200602205113.GE11961@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <20200602205113.GE11961@SDF.ORG>
Message-ID: <26C9C1B1-6A6F-410F-B38A-185A3DDFE792@gmail.com>



> On Jun 2, 2020, at 22:51, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Hardly a nightmare!

Because you have delegated it to a bazillion of python scripts behind the scene:

#!/usr/bin/env python3
# AV-98 Gemini client

Out of sight doesn't imply out of mind in this case.


From plugd at thelambdalab.xyz  Tue Jun  2 21:59:23 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Tue, 02 Jun 2020 22:59:23 +0200
Subject: Three month spec freeze
In-Reply-To: <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
Message-ID: <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>

Hi, just some comments from the peanut gallery..

Petite Abeille writes:
> ? drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings. 
>
> Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?).

Clients don't have to implement any of these things.  They can just
refuse to serve non-utf8 content.  But at lease I _know_ that I
shouldn't try to render your koi8 page and can give a sensible reason why.
Otherwise we're back to gopher, using guesswork and inference.

> ? drop everything from text/gemini but text and link lines.
>
> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.

Ok, there goes ascii art from gemini.  Seriously.  This just forces me
to choose between having prose rendered at a sensible width for reading
or having nice art.  Or having to implement more guesswork and inference.

> ? mandate >= TLS 1.3. Drop legacy support. 
>
> Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation.

Is this really necessary?  What's so awesome about 1.3 from a
layperson's perspective?  I'm honestly asking, not just trying to be
contrary.  I worry this would increase the difficulty of complience
without a real qualitative benifit.  (Also, I think this would
immediately break my server, so I'm biased. :-) )

plugd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/930be09f/attachment.sig>

From petite.abeille at gmail.com  Tue Jun  2 22:05:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 23:05:09 +0200
Subject: Three month spec freeze
In-Reply-To: <20200602203303.GD11961@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <20200602203303.GD11961@SDF.ORG>
Message-ID: <68C276B1-55F7-4227-A28C-0DABA9F05B0A@gmail.com>



> On Jun 2, 2020, at 22:33, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> This quote has always been dear to my heart. :)

Here is another one:

?The details are not the details; they make the product? 
-- Charles and Ray Eames


From tomasino at lavabit.com  Tue Jun  2 22:11:06 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 2 Jun 2020 21:11:06 +0000
Subject: Three month spec freeze
In-Reply-To: <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>

On 6/2/20 8:59 PM, plugd wrote:
> ? drop everything from text/gemini but text and link lines.
> 
> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.

I'll be that guy to step in here.

As solderpunk mentioned, headings have semantic meaning, as do lists.
These are not formatting features, although they can be styled by
clients that want to be pretty. They provide structure and meaning to
text documents which is invaluable for accessibility and alternative
devices.

We have also had a LOT of conversation on preformatted text to get where
we are. There are some types of content which are impossible to
implement without it.

I don't see any of those things as extraneous features. They enable the
text/gemini format to be what it is as much as links.


From solderpunk at SDF.ORG  Tue Jun  2 22:15:08 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 21:15:08 +0000
Subject: Three month spec freeze
In-Reply-To: <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <20200602211508.GF11961@SDF.ORG>

On Tue, Jun 02, 2020 at 10:59:23PM +0200, plugd wrote:
> 
> Is this really necessary?  What's so awesome about 1.3 from a
> layperson's perspective?  I'm honestly asking, not just trying to be
> contrary.

1.3 drastically reduces the range of permissible cryptographic
primitives which can be used.  Instead of supporting dozens and dozens
of different ciphersuites with opaque names ranging from "as secure as
it gets" to "known to be broken for years", requiring careful
configuration and implementation to avoid shooting yourself in the foot
or being susceptible to downgrade attacks, 1.3 is basically foolproof.
All the legacy cruft like RC4 is gone, every availble key agreement
scheme offers perfect forward security, etc.  It's definitely something
to be excited about.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Tue Jun  2 22:15:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 23:15:43 +0200
Subject: Three month spec freeze
In-Reply-To: <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>



> On Jun 2, 2020, at 22:59, plugd <plugd at thelambdalab.xyz> wrote:
> 
> Is this really necessary?

TLS in general? A minimum version of it? Not really.

But mandating a secure channel of sort is value added.

That said, mandating TLS only is perhaps counterproductive.

After all, how do I run Gemini over wireguard now? With TLS on top? Because the spec forces me to? Oh, my...

Perhaps Gemini should mandate a secure transmission channel, and then define a profile of it in the specification., say TLS vs TLS >= 1.3 vs wireguard vs whatnot. 




From solderpunk at SDF.ORG  Tue Jun  2 22:19:47 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 21:19:47 +0000
Subject: Three month spec freeze
In-Reply-To: <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
Message-ID: <20200602211947.GG11961@SDF.ORG>

On Tue, Jun 02, 2020 at 11:15:43PM +0200, Petite Abeille wrote:
 
> That said, mandating TLS only is perhaps counterproductive.
> 
> After all, how do I run Gemini over wireguard now? With TLS on top? Because the spec forces me to? Oh, my...

If you run Gemini *without* TLS, how do you handle any of the status
codes relating to client certificates?

Cheers,
Solderpunk

From sean at conman.org  Tue Jun  2 22:25:30 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 17:25:30 -0400
Subject: approachabe & frugal & composable
In-Reply-To: <20200602181922.GC16068@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
Message-ID: <20200602212530.GM23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> In short, there was supposed to be a single, concrete "unit of
> interface" with narrow scope that a client author has to decide how to
> implement.  Variation between clients in how that was done would not
> substantially change the overall user experience.
> 
> With stuff like data:, feed:, tag:, geo:, and the myriad other
> "non-locational schemes", all of this goes out the window.  What is a
> client supposed to do with all these?  

  Web and gopher clients already face this issue.  Web browsers have solved
this issue by allowing the user to configure a program to handle an unknown
URI scheme.  I've registered the "gopher" with Firefox to go through a
gopher proxy, so I can't see why this can't be an option for Gemini clients. 
I'm not aware of a scheme like mailcap (for handing of MIME types) for URI
schemes, but even a simple:

	gopher:	my-gopher-client
	http:	firefox
	https:	firefox
	geo:	missile-launcher

will be good enough (and not even mandatory---I'm just throwing out an idea
here).

> If I want to write a minimal
> client that just knows how to follow gemini:// links and nothing else,
> what the heck do I do with a tag: link?  Display it to the user, or
> hide it?  

  As a quick solution, how about just display a page with:

	I don't know how to handle tag:conman.org,1998-10-16:site
	Sorry about that.

Done!  Ship it!

> If I choose to display it using exactly the same code path I
> would use to to display a gemini:// link, I need to go out of my way
> to make that code path robust against stuff that doesn't make sense for
> "proper" links, like there not being a "netloc" component (AV-98
> currently silently drops tag: links, for example, because they cause an
> Exception when I try to handle them as if they were a "proper" link).

  There exists code to parse a URI, whether homegrown or a library.  At the
very least, the client can check the scheme portion for "gemini".  I've
already seen URIs for http:, https:, mailto: and data: [1].

> If I *do* successfully display them as if they were a proper link and
> the user tries to follow one, what is supposed to happen?  Assuming I
> fix the aforementioned problem, AV-98 will say "Sorry, no support for
> tag", because it fills out a template that I designed thinking of cases
> like "Sorry, no suport for ftp", which most users will understand.  *I*
> would be very confused by a "no support for tag" message, I'd think
> "What, there *are* no tags in Gemini, what's going on here?".

  I've already mentioned Firefox, but Lynx gave me "Alert!: Unsupported URL
scheme!" when I tried using a gemini: link on a webpage.  Don't sweat it.

> So, I'm not sure how to proceed here.  People should feel free to
> experiment with possibilities, because informed decisions are better
> than uninformed ones.  But I would advise people not to get fiercely
> attached to any idea of how non-locational URLs might work in Gemini.
> It's uncharted territory.

  I think your concern (or fear) is overblown here.  Outside of

	http:
	https:
	mailto:

I think other URI types on the web will fall deep into the 0.56% of links
that aren't the above.

  -spc 

[1]	The Gemini Client Torture Test

From petite.abeille at gmail.com  Tue Jun  2 22:29:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 23:29:05 +0200
Subject: Three month spec freeze
In-Reply-To: <20200602211947.GG11961@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
 <20200602211947.GG11961@SDF.ORG>
Message-ID: <EC25237B-1C58-42C8-A4A6-9812108E1DD9@gmail.com>



> On Jun 2, 2020, at 23:19, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> If you run Gemini *without* TLS, how do you handle any of the status
> codes relating to client certificates?

They are irrelevant. Or rather,  for something like wireguard, imply running under  62 AUTHORISED CERTIFICATE REQUIRED or something.

P.S. Off topic, but interesting, https://tailscale.com/blog/how-tailscale-works/






From martin at no.ucant.org  Tue Jun  2 22:34:08 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 2 Jun 2020 22:34:08 +0100 (BST)
Subject: approachabe & frugal & composable
In-Reply-To: <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>
Message-ID: <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>

On Tue, 2 Jun 2020, colecmac at protonmail.com wrote:

>> At this point I am honestly considering speccing that => lines may
> *only* use URLs whose scheme corresponds to an application protocol.
> Permitting *any* RFC-compliant URL is just way, way too open-ended and
> defeats the point of so much careful efforts elsewhere in the protocol.
>
> I would be in favour of this, I don't want to start seeing pages that
> have tags on them.

I believe I earlier proposed something along the lines of whitelisting or 
blacklisting of URL schemes, but I don't really have a coherent proposal.

Ultimately there is a tradeoff which must be made between the benefits of 
the IETF-derived approach (existing, documented standards; existing, 
debugged implementations; conceptual familiarity) and the drawbacks (the 
assumptions with which these come freighted; the "robustness principle" 
rhetoric; the capture of IETF standards-making by particular interests and 
philosophies).

I don't think the existing standards-making systems can be relied upon to 
produce something clean and module like a resource locator that couldn't 
be extended into a Turing-complete language. Therefore, if we want to 
have a minimalist alternative, we may need to depart somewhat from 
re-using IETF / W3C standards, which I would support. The WWW already 
exists for people who want the more complicated/ornate systems.

Mk

From petite.abeille at gmail.com  Tue Jun  2 22:34:25 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 23:34:25 +0200
Subject: Three month spec freeze
In-Reply-To: <20200602211947.GG11961@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
 <20200602211947.GG11961@SDF.ORG>
Message-ID: <CF9171D9-93C9-4B4A-9B01-11D6DC6959B3@gmail.com>



> On Jun 2, 2020, at 23:19, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> If you run Gemini *without* TLS, how do you handle any of the status
> codes relating to client certificates?

Actually, more specifically, the TLS related status code should be part of the TLS Gemini profile. Which would not be relevant for the WireGuard Gemini profile. Or such.


From solderpunk at SDF.ORG  Tue Jun  2 22:40:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 2 Jun 2020 21:40:55 +0000
Subject: approachabe & frugal & composable
In-Reply-To: <3892A94D-C223-4E40-A576-63B871CA027D@gmail.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <3892A94D-C223-4E40-A576-63B871CA027D@gmail.com>
Message-ID: <20200602214055.GH11961@SDF.ORG>

On Tue, Jun 02, 2020 at 10:21:43PM +0200, Petite Abeille wrote:
> 
> > On Jun 2, 2020, at 22:00, solderpunk <solderpunk at SDF.ORG> wrote:
> > 
> > Permitting *any* RFC-compliant URL is just way, way too open-ended and
> > defeats the point of so much careful efforts elsewhere in the protocol.
> 
> I suspect you are overthinking it :)
> 
> URIs are a good thing.
> 
> Thinks of them as structured tags.
> 
> Nothing more, nothing less.

That's something more than I want! :)

> They do not imply any behavior, but rather convey information. Structured information.

This is the problem.  They are way too general purpose.  They can convey
just about any kind of information.  Surely, there are contexts where
that's useful.  But sometimes you want to be able to convey information
of limited scope.  MIME media types are structured information (with a
main type, sub type, parameters), but structured information of a
certain type with a clear scope.  That's a good thing, from a protocol
design perspective.  It lets you reason about the consequences of what
you're specifying.  Arbitrary structured information does not.

Cheers,
Solderpunk

From luke.emmet at gmail.com  Tue Jun  2 22:44:41 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Tue, 2 Jun 2020 22:44:41 +0100
Subject: Three month spec freeze
In-Reply-To: <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
Message-ID: <B2EE3A28-1B68-4E05-80C9-A0620674CE49@gmail.com>

Another voice over here in against any suggestion to drop the frugal but useful heading and bullet structuring we have already.

Having already implemented automatic table of contents in GemiNaut I can confirm it does give a usability boost when reading longer posts. 

It is very lightweight and zero burden for anyone who just wants to write a long essay. 

I think the current spec has it right.

Utf 8 everywhere sounds good as a working principle. Maybe we can wait and see if there really is a widespread need for any other encodings.

We can do ASCII art in Unicode - I don't get what the drive behind that remark was, mentioned earlier.

As for TLS versions, I don't have a strong opinion, except to say that implementing the normal case for the majority of content should be straightforward on the client and server side. Keep the complexity down as far as we can.

Best wishes

Luke

> On 2 Jun 2020, at 22:11, James Tomasino <tomasino at lavabit.com> wrote:
> 
>> On 6/2/20 8:59 PM, plugd wrote:
>> ? drop everything from text/gemini but text and link lines.
>> 
>> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.
> 
> I'll be that guy to step in here.
> 
> As solderpunk mentioned, headings have semantic meaning, as do lists.
> These are not formatting features, although they can be styled by
> clients that want to be pretty. They provide structure and meaning to
> text documents which is invaluable for accessibility and alternative
> devices.
> 
> We have also had a LOT of conversation on preformatted text to get where
> we are. There are some types of content which are impossible to
> implement without it.
> 
> I don't see any of those things as extraneous features. They enable the
> text/gemini format to be what it is as much as links.
> 

From petite.abeille at gmail.com  Tue Jun  2 22:49:20 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 2 Jun 2020 23:49:20 +0200
Subject: approachabe & frugal & composable
In-Reply-To: <20200602214055.GH11961@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <3892A94D-C223-4E40-A576-63B871CA027D@gmail.com>
 <20200602214055.GH11961@SDF.ORG>
Message-ID: <91E96077-BF31-4645-BDFC-92C199CA46BC@gmail.com>



> On Jun 2, 2020, at 23:40, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Arbitrary structured information does not.

Consider the following two URI:

https://tools.ietf.org/html/rfc2648 

vs.

urn:ietf:rfc:2648


Which one actually refers to RFC2648 A URN Namespace for IETF Documents?


From peteyboy at SDF.ORG  Tue Jun  2 22:55:35 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Tue, 2 Jun 2020 21:55:35 +0000 (UTC)
Subject: approachabe & frugal & composable
In-Reply-To: <mailman.31.1591129883.529.gemini@lists.orbitalfox.eu>
References: <mailman.31.1591129883.529.gemini@lists.orbitalfox.eu>
Message-ID: <alpine.NEB.2.21.2006022123020.11287@otaku.sdf.org>


> Message: 1
> Date: Tue, 2 Jun 2020 20:00:42 +0000
> From: solderpunk <solderpunk at SDF.ORG>
> To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
> Subject: Re: approachabe & frugal & composable
> Message-ID: <20200602200042.GC11961 at SDF.ORG>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote:
>
>> Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'.
>>
>> In short, only decorate scheme you know, leave the rest alone, and render it as static text.
>>
>> Never hide anything.
>>
>> Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client.
>>
>> More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort.
>>
>> And that is that.
>
> This sounds "short and sweet" and simple, but this basically makes
> Gemini infinitely extensible.  Link lines stop having anything to do
> with the concept of "links", and become vehicles for anything that
> somebody wants to come up with a URI scheme for, which is a large and
> totally open category which will grow over time and may come to include
> very scary things (for the love of God, there was an IETF draft for a
> javascript: scheme! [1]).  Giving clients the power to recognise any old
> scheme which comes along is guaranteed to induce a repeat of the
> evolution of the web.  Basically we can now think of the line:
>
> => scheme:restofuri Human friendly label
>
> as equivalent to something like:
>
> <scheme arg1="restofuri" arg2="Human friendly label"/>
>
> text/gemini would be fully as extensible as HTML where client authors
> can just invent new tags like <blink> and <marquee>.  It's exactly what
> nobody here wants.
>
> I am *so angry* that there isn't a construct in the internet
> architecture which is *nothing more* than a convenient way to concisely
> specify an application protocol, a hostname or IP address, a port, and
> a path.  This is such an obviously useful thing to have.  It's what
> almost everybody *thinks* a URL is, but it turns out that's wrong.  Who
> would have thought that Gopher's clunky and archaic notation of:
>
> path<TAB>hostname<TAB>port<TAB>
>
> literally has not been improved on in ~30 years?
>
> At this point I am honestly considering speccing that => lines may
> *only* use URLs whose scheme corresponds to an application protocol.
> Permitting *any* RFC-compliant URL is just way, way too open-ended and
> defeats the point of so much careful efforts elsewhere in the protocol.
>
> Cheers,
> Solderpunk


I feel like what's been revealed here is that you have little control of 
this the way it's designed. You could eschew URIs for your own format, but 
then it would be just harder than it is now to use off-the-shelf tools to 
"pervert" gemini, but still possible. It could also be that people fork 
into another protocol. In the end, the browser can be handed something by 
a server, and if the browser and server are both consenting programs, 
they'll do what they want. And if enough people think it's cool, there 
will be more of those servers, more of that content, and then more of 
those browsers. This is what happened to http://, isn't it? How Netscape 
defeated Mosaic?


Some of the excitement around gemini feels like it's because it's a 
rebooting of http. I definitely feel it some myself. I like the aesthetic, 
though, and the idea behind it. The reality is, too, that if people extend 
gemini into another http, it will just be not-as-good http.

But can you stop people from super-setting gemini?

PS reading all this gemini stuff makes me want to create a "wiki://" 
scheme, like native super-wiki web

From prisonpotato at tilde.team  Tue Jun  2 23:00:02 2020
From: prisonpotato at tilde.team (prisonpotato at tilde.team)
Date: Tue, 2 Jun 2020 18:00:02 -0400
Subject: approachabe & frugal & composable
In-Reply-To: <alpine.NEB.2.21.2006022123020.11287@otaku.sdf.org>
References: <mailman.31.1591129883.529.gemini@lists.orbitalfox.eu>
 <alpine.NEB.2.21.2006022123020.11287@otaku.sdf.org>
Message-ID: <20200602220002.GA15313@tilde.team>

I think that because it's so easy to implement a client, it won't
succumb to this sort of thing.  Most people's homemade clients won't
implement geminiscript or whatever, so people will be discouraged from
using it

On Tue, Jun 02, 2020 at 09:55:35PM +0000, Pete D. wrote:
> 
> > Message: 1
> > Date: Tue, 2 Jun 2020 20:00:42 +0000
> > From: solderpunk <solderpunk at SDF.ORG>
> > To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
> > Subject: Re: approachabe & frugal & composable
> > Message-ID: <20200602200042.GC11961 at SDF.ORG>
> > Content-Type: text/plain; charset=us-ascii
> > 
> > On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote:
> > 
> > > Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'.
> > > 
> > > In short, only decorate scheme you know, leave the rest alone, and render it as static text.
> > > 
> > > Never hide anything.
> > > 
> > > Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client.
> > > 
> > > More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort.
> > > 
> > > And that is that.
> > 
> > This sounds "short and sweet" and simple, but this basically makes
> > Gemini infinitely extensible.  Link lines stop having anything to do
> > with the concept of "links", and become vehicles for anything that
> > somebody wants to come up with a URI scheme for, which is a large and
> > totally open category which will grow over time and may come to include
> > very scary things (for the love of God, there was an IETF draft for a
> > javascript: scheme! [1]).  Giving clients the power to recognise any old
> > scheme which comes along is guaranteed to induce a repeat of the
> > evolution of the web.  Basically we can now think of the line:
> > 
> > => scheme:restofuri Human friendly label
> > 
> > as equivalent to something like:
> > 
> > <scheme arg1="restofuri" arg2="Human friendly label"/>
> > 
> > text/gemini would be fully as extensible as HTML where client authors
> > can just invent new tags like <blink> and <marquee>.  It's exactly what
> > nobody here wants.
> > 
> > I am *so angry* that there isn't a construct in the internet
> > architecture which is *nothing more* than a convenient way to concisely
> > specify an application protocol, a hostname or IP address, a port, and
> > a path.  This is such an obviously useful thing to have.  It's what
> > almost everybody *thinks* a URL is, but it turns out that's wrong.  Who
> > would have thought that Gopher's clunky and archaic notation of:
> > 
> > path<TAB>hostname<TAB>port<TAB>
> > 
> > literally has not been improved on in ~30 years?
> > 
> > At this point I am honestly considering speccing that => lines may
> > *only* use URLs whose scheme corresponds to an application protocol.
> > Permitting *any* RFC-compliant URL is just way, way too open-ended and
> > defeats the point of so much careful efforts elsewhere in the protocol.
> > 
> > Cheers,
> > Solderpunk
> 
> 
> I feel like what's been revealed here is that you have little control of
> this the way it's designed. You could eschew URIs for your own format, but
> then it would be just harder than it is now to use off-the-shelf tools to
> "pervert" gemini, but still possible. It could also be that people fork into
> another protocol. In the end, the browser can be handed something by a
> server, and if the browser and server are both consenting programs, they'll
> do what they want. And if enough people think it's cool, there will be more
> of those servers, more of that content, and then more of those browsers.
> This is what happened to http://, isn't it? How Netscape defeated Mosaic?
> 
> 
> Some of the excitement around gemini feels like it's because it's a
> rebooting of http. I definitely feel it some myself. I like the aesthetic,
> though, and the idea behind it. The reality is, too, that if people extend
> gemini into another http, it will just be not-as-good http.
> 
> But can you stop people from super-setting gemini?
> 
> PS reading all this gemini stuff makes me want to create a "wiki://" scheme,
> like native super-wiki web

From mbays at sdf.org  Tue Jun  2 23:33:13 2020
From: mbays at sdf.org (Martin Bays)
Date: Wed, 3 Jun 2020 00:33:13 +0200
Subject: approachabe & frugal & composable
In-Reply-To: <20200602200042.GC11961@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
Message-ID: <20200602223313.7waw53hbdcqr6zvf@gonzales.net>

* Tuesday, 2020-06-02 at 20:00 +0000 - solderpunk <solderpunk at SDF.ORG>:

>At this point I am honestly considering speccing that => lines may
>*only* use URLs whose scheme corresponds to an application protocol.

If the result of limiting schemes is that clients just ignore lines with 
other schemes, you have a clear opportunity for drift. Some clients 
could start to go against spec and interpret links which don't fit this 
restriction.

Perhaps instead, links with whacky schema shouldn't be disallowed, but 
there should be clear requirements for how an interactive client 
interprets them. I suggest two rules:

1. NO MAGIC: an interactive client must do nothing with a link URI other than
displaying the text of the URI, until the user expressly follows the link.

2. The URI of each link line must be displayed in full.

The first rule makes links with arbitrary schemes relatively 
unobjectionable. The second rule is to stop drift away from the first 
rule, by cutting off what could otherwise be a channel for communication 
between off-spec clients and servers which doesn't affect on-spec ones.

From mbays at sdf.org  Wed Jun  3 00:06:10 2020
From: mbays at sdf.org (Martin Bays)
Date: Wed, 3 Jun 2020 01:06:10 +0200
Subject: Three month spec freeze
In-Reply-To: <20200602192658.GB11961@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG>
 <20200602192658.GB11961@SDF.ORG>
Message-ID: <20200602230610.5goz46rmhtfjmdrl@gonzales.net>

* Tuesday, 2020-06-02 at 19:26 +0000 - solderpunk <solderpunk at SDF.ORG>:

>But if anybody thinks they see a real problem with the design of 
>anything currently in the protocol, in principle now is the time to 
>mention it.

One little thing that's bothered me ever since first reading the spec, 
and which I can't see being discussed before (sorry if I missed it):
there seems to be no way to quote a line starting with "```". So for 
example there's no way to present in a preformatted text block a gemini 
document which contains "```" lines.

Relatedly, there's no way to have a text line which starts with any of 
the magic character sequences.

Here's one possible way to solve both these problems *and* the problem 
of invisible strings on a "```" line being used for extensibility:

A line consisting of just the three characters "```" is a preformatting 
toggle line. A line of the form "```TEXT" is interpreted as a text line 
with contents TEXT if preformatted mode is currently off, and as 
a preformatted line with contents TEXT if preformatted mode is on.


Examples:

``````

```#this# is heavy type, not a header

```
``````     ```     ```     ```
  ```     ```     ```     ```
   ```     ```     ```     ```
    raindrops keep falling on my text
```


That last one would be equivalent to:

```
``````     ```     ```     ```
``` ```     ```     ```     ```
```  ```     ```     ```     ```
```   raindrops keep falling on my text
```

which is easier to read.

From sean at conman.org  Wed Jun  3 01:47:45 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 20:47:45 -0400
Subject: Three month spec freeze
In-Reply-To: <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
Message-ID: <20200603004745.GN23998@brevard.conman.org>

It was thus said that the Great Felix Quei?ner once stated:
> 
> I strongly recommend supporting utf-8 only. iconv -l lists 1179
> possible/known encodings. I don't want to support more than one in my
> code, most libraries don't support more than UTF-8, UTF-16, UTF-32 and
> ASCII. And for UTF-16 and UTF-32 not even a difference between little
> and big endian encoded data.

  RFC-1436 (the gopher RFC) suggests ISO Latin1 (ISO-8859-1 if I'm not
mistaken) for 8-bit character sets and says *nothing* about UTF-8 (of
course, it was written before UTF-8 was an RFC, three years later).  But
most of the gopher sites I hit these days are UTF-8---it's rare that I
actually encounter anything but UTF-8.

  Secondly, Linux systems come with iconv.  Not only is this a program, but
it's also a library which is dead simple to use as there are only three
functions:

	iconv_t iconv_open(char const *tocode,char const *fromcode);
	size_t iconv(iconv_t cd,char **inbuf,size_t *inbytes,char **outbuf,size_t *outbytes);
	iconv_close(iconv_t cd);

and that's *if* you want to support conversion.  The world is migrating to
UTF-8 so I think this will be that big of an issue in the long term.  And in
case anyone is curious, I found bindings for

	Lua
	Python
	Rust
	Go
	Haskell

(no comment on how well these bindings work, just that they exist).

  -spc


From sean at conman.org  Wed Jun  3 01:53:51 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 20:53:51 -0400
Subject: Three month spec freeze
In-Reply-To: <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
Message-ID: <20200603005351.GO23998@brevard.conman.org>

It was thus said that the Great James Tomasino once stated:
> We have also had a LOT of conversation on preformatted text to get where
> we are. There are some types of content which are impossible to
> implement without it.

  And you are not limited to just text/gemini.  I know of one blog that is
serving up text/markdown:

	gemini://alexschroeder.ch/

  -spc (HTML is another option ... )


From sean at conman.org  Wed Jun  3 01:59:00 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 20:59:00 -0400
Subject: Three month spec freeze
In-Reply-To: <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
Message-ID: <20200603005900.GP23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Jun 2, 2020, at 22:59, plugd <plugd at thelambdalab.xyz> wrote:
> > 
> > Is this really necessary?
> 
> TLS in general? A minimum version of it? Not really.
> 
> But mandating a secure channel of sort is value added.
> 
> That said, mandating TLS only is perhaps counterproductive.
> 
> After all, how do I run Gemini over wireguard now? With TLS on top?
> Because the spec forces me to? Oh, my...

  Wireguard is a VPN implementation, not specifically a protocol. And as
with other people who have questioned the use of TLS, show us an
implementaion.  Get a Gemini server working over wireguard.  Or both
wireguard *and* TLS.  Because as it is, I have no idea how to go about this,
nor any easy means to test it.

> Perhaps Gemini should mandate a secure transmission channel, and then
> define a profile of it in the specification., say TLS vs TLS >= 1.3 vs
> wireguard vs whatnot.

  Again, the devil is in the details, and we need some more details about
this.

  -spc (And then convince the gopher people who are working hard to get TLS
	working that *that* protocol ... )

From sean at conman.org  Wed Jun  3 02:07:56 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 21:07:56 -0400
Subject: Three month spec freeze
In-Reply-To: <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
Message-ID: <20200603010756.GQ23998@brevard.conman.org>

It was thus said that the Great Martin Bays once stated:
> * Tuesday, 2020-06-02 at 19:26 +0000 - solderpunk <solderpunk at SDF.ORG>:
> 
> >But if anybody thinks they see a real problem with the design of 
> >anything currently in the protocol, in principle now is the time to 
> >mention it.
> 
> One little thing that's bothered me ever since first reading the spec, 
> and which I can't see being discussed before (sorry if I missed it):
> there seems to be no way to quote a line starting with "```". So for 
> example there's no way to present in a preformatted text block a gemini 
> document which contains "```" lines.

  I don't really have a horse in this race (I don't really care) but let me
tell you about an interesting feature of Lua.

  Lua has three forms of strings.  The first type is with the double quote:

	"This is a string.\n"

  The second form is with the single quote:

	'This is also a string.\n'

  These types of strings allow certain characters to be escaped and are
identical in nature, except that the double quote needs to be escaped in a
string in double quotes, and the single quote needs to be escaped in a
string in single quotes.  The third type is what I want to talk about:

[[
This too, is a string.
]]

  This type of string can expand beyond a single line, and it taken as-is. 
There is no escaping of characters though.  So '\n' is NOT translated to the
LF character.  But there *is* a feature of these strings to include the '[['
and ']]' in the string being formed:

[=[
This is a Lua string: [[This is a string.]] See?
]=]

And if *that* needs to be quoted as a string?

[==[
[=[
This is a Lua string: [[This is a string.]] See?
]=]
]==]

And so on.  The format is:

	'[' '='* '[' <data> ']' '='* ']'

where the number of '=' match (not sure how to express that).

  I'm just throwing this out there.

  -spc


From tomasino at lavabit.com  Wed Jun  3 02:09:19 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Wed, 3 Jun 2020 01:09:19 +0000
Subject: Three month spec freeze
In-Reply-To: <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
Message-ID: <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>

On 6/2/20 11:06 PM, Martin Bays wrote:
> One little thing that's bothered me ever since first reading the spec,
> and which I can't see being discussed before (sorry if I missed it):
> there seems to be no way to quote a line starting with "```". So for
> example there's no way to present in a preformatted text block a gemini
> document which contains "```" lines.

I just wrote a gemlog that was demonstrating the uses of ``` [1].
There's a much easier way to do it. Just add a space at the start.

```
 ```
```

As for lines starting with a magic string, you can just put them inside
a preformatted block.

```
=> gemini://linky.mcgoo
```

I'm holding out hope that the space after the ``` will be used for great
purpose for accessibility. I think that's a much more productive
direction than fringe cases of formatting.

[1] gemini://tilde.black/users/fox/journal/20200601-accessibility.gmi


From sean at conman.org  Wed Jun  3 02:21:09 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 21:21:09 -0400
Subject: approachabe & frugal & composable
In-Reply-To: <20200602200042.GC11961@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
Message-ID: <20200603012109.GR23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> Basically we can now think of the line:
> 
> => scheme:restofuri Human friendly label
> 
> as equivalent to something like:
> 
> <scheme arg1="restofuri" arg2="Human friendly label"/>
> 
> text/gemini would be fully as extensible as HTML where client authors
> can just invent new tags like <blink> and <marquee>.  It's exactly what
> nobody here wants.

  "The more you tighten your grip, Tarkin, the more star systems will slip
thorugh your fingers."

  Here's the list of all registered URI schemes:

	https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

  I will bet you that 99 44/100% of all links on the Internet are:

	https:
	http:
	mailto:
	file:	(and these are always a mistake on the part of the author)
	ftp:
	gopher:

  Honestly, I don't think you have to worry too much.

  -spc

From sean at conman.org  Wed Jun  3 02:22:46 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 21:22:46 -0400
Subject: approachabe & frugal & composable
In-Reply-To: <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>
 <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>
Message-ID: <20200603012246.GS23998@brevard.conman.org>

It was thus said that the Great Martin Keegan once stated:
> 
> I don't think the existing standards-making systems can be relied upon to 
> produce something clean and module like a resource locator that couldn't 
> be extended into a Turing-complete language. Therefore, if we want to 
> have a minimalist alternative, we may need to depart somewhat from 
> re-using IETF / W3C standards, which I would support. The WWW already 
> exists for people who want the more complicated/ornate systems.

  And if you think the bikeshedding on text/gemini is bad ...

  -spc (Just a gut feeling here about a long, dark, slog)


From sean at conman.org  Wed Jun  3 02:28:25 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 2 Jun 2020 21:28:25 -0400
Subject: approachabe & frugal & composable
In-Reply-To: <91E96077-BF31-4645-BDFC-92C199CA46BC@gmail.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <3892A94D-C223-4E40-A576-63B871CA027D@gmail.com>
 <20200602214055.GH11961@SDF.ORG>
 <91E96077-BF31-4645-BDFC-92C199CA46BC@gmail.com>
Message-ID: <20200603012825.GT23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Jun 2, 2020, at 23:40, solderpunk <solderpunk at SDF.ORG> wrote:
> > 
> > Arbitrary structured information does not.
> 
> Consider the following two URI:
> 
> https://tools.ietf.org/html/rfc2648 
> 
> vs.
> 
> urn:ietf:rfc:2648
> 
> 
> Which one actually refers to RFC2648 A URN Namespace for IETF Documents?

  Shouldn't that be: <tag://tools.ieft.org,1995-03-11:rfc2648>?

  My bogging engine [1] is configured to recognize links in the form of

	rfc:2648

and generate a link to the RFC.  Also, I have:

	asin:blahblahblah

to link to my Amazon affilate store.  But that's hidden behind the scenes
and those shouldn't leak out.

  -spc (But I'm probably scaring solderpunk even more now ... )

[1]	https://github.com/spc476/mod_blog

  

From plugd at thelambdalab.xyz  Wed Jun  3 08:01:06 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Wed, 03 Jun 2020 09:01:06 +0200
Subject: Three month spec freeze
In-Reply-To: <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
Message-ID: <lz5zc88wgd.fsf@bs-mbpr348.d.ethz.ch>

Petite Abeille writes:
>> On Jun 2, 2020, at 22:59, plugd <plugd at thelambdalab.xyz> wrote:
>> 
>> Is this really necessary?
> TLS in general? A minimum version of it? Not really.

Sorry, you're quoting me without context, which makes it sound like I
was questioning whether TLS is necessary _at all_ - which I absolutely
wasn't.  My question was specific to the suggestion that TLS >= 1.3 be
used.

plugd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/b9f7114a/attachment.sig>

From plugd at thelambdalab.xyz  Wed Jun  3 08:04:20 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Wed, 03 Jun 2020 09:04:20 +0200
Subject: Three month spec freeze
In-Reply-To: <20200602211508.GF11961@SDF.ORG>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch> <20200602211508.GF11961@SDF.ORG>
Message-ID: <lz367c8waz.fsf@bs-mbpr348.d.ethz.ch>

Hey, 

solderpunk writes:
> On Tue, Jun 02, 2020 at 10:59:23PM +0200, plugd wrote:
> 1.3 drastically reduces the range of permissible cryptographic
> primitives which can be used.  Instead of supporting dozens and dozens
> of different ciphersuites with opaque names ranging from "as secure as
> it gets" to "known to be broken for years", requiring careful
> configuration and implementation to avoid shooting yourself in the foot
> or being susceptible to downgrade attacks, 1.3 is basically foolproof.
> All the legacy cruft like RC4 is gone, every availble key agreement
> scheme offers perfect forward security, etc.  It's definitely something
> to be excited about.

Thank you for this clear explanation, this is very helpful!  You've
convinced me that requiring >= 1.3 would be a sensible move.

plugd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/213773ee/attachment.sig>

From plugd at thelambdalab.xyz  Wed Jun  3 08:12:21 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Wed, 03 Jun 2020 09:12:21 +0200
Subject: approachabe & frugal & composable
In-Reply-To: <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>
 <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>
Message-ID: <lzzh9k7hd6.fsf@bs-mbpr348.d.ethz.ch>

Martin Keegan writes:
> I don't think the existing standards-making systems can be relied upon
> to produce something clean and module like a resource locator that
> couldn't be extended into a Turing-complete language.

Reminds me of this protest article by one of the Chicken developers
about the sad state of the URL spec:
https://www.more-magic.net/posts/an-appeal-to-whatwg-uri-spec.html

plugd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/78b44e95/attachment.sig>

From tomasino at lavabit.com  Wed Jun  3 09:17:46 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Wed, 3 Jun 2020 08:17:46 +0000
Subject: [ANN] cosmic.voyage joins gemini
In-Reply-To: <lzzh9k7hd6.fsf@bs-mbpr348.d.ethz.ch>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>
 <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>
 <lzzh9k7hd6.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <a0cbf993-8dc1-0a1a-8576-3bc4bb29ba4e@lavabit.com>

I'm pleased to announce that gemini://cosmic.voyage is up and running
finally. That makes it accessible over gopher, web, and gemini (the
trifecta!).

For those of you unfamiliar, cosmic voyage is a tilde community (free
pubnix) geared toward writing sci-fi stories in a semi-shared universe.
If you're interested in joining, visit the "join" page to sign up.

For aggregators, we have a master log page that can be watched for
changes at:

gemini://cosmic.voyage/log/

There's also an RSS feed of the most recent 100 logs in full text at:

gemini://cosmic.voyage/rss.xml

The perm-links in this feed point to gopher currently, but I'll be
tweaking that on the gemini side shortly.

I hope this goes a long way to adding more non-gemini-focused content to
the gemini environment.

See you round the 'verse,
tomasino


From defdefred at protonmail.com  Wed Jun  3 09:58:46 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 03 Jun 2020 08:58:46 +0000
Subject: Three month spec freeze
In-Reply-To: <B2EE3A28-1B68-4E05-80C9-A0620674CE49@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <B2EE3A28-1B68-4E05-80C9-A0620674CE49@gmail.com>
Message-ID: <3X2Y7guItVOoZXOK3KKv_nAReK494dbS60DVhSILgXzu_vqU0l0EnpJcJTobBlH1CyFua8pGdoQ8hj0mLvobPzUTUDT5zgswqIBDnOy1A-I=@protonmail.com>

On Tuesday 2 June 2020 23:44, Luke Emmet <luke.emmet at gmail.com> wrote:
> We can do ASCII art in Unicode - I don't get what the drive behind that remark was, mentioned earlier.

I can't wait for UTF-8 art :-)

From plugd at thelambdalab.xyz  Wed Jun  3 10:30:51 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Wed, 03 Jun 2020 11:30:51 +0200
Subject: Three month spec freeze
In-Reply-To: <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
Message-ID: <lzlfl4sdh0.fsf@bs-mbpr348.d.ethz.ch>

James Tomasino writes:
> On 6/2/20 8:59 PM, plugd wrote:
>> ? drop everything from text/gemini but text and link lines.
>> 
>> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more.
>
> I'll be that guy to step in here.

I think you meant to reply to Petite Abeille - I was just quoting :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/ab10f89e/attachment-0001.sig>

From felix at masterq32.de  Wed Jun  3 12:33:44 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 3 Jun 2020 13:33:44 +0200
Subject: Unicode-Art (WAS: Three month spec freeze)
In-Reply-To: <3X2Y7guItVOoZXOK3KKv_nAReK494dbS60DVhSILgXzu_vqU0l0EnpJcJTobBlH1CyFua8pGdoQ8hj0mLvobPzUTUDT5zgswqIBDnOy1A-I=@protonmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <B2EE3A28-1B68-4E05-80C9-A0620674CE49@gmail.com>
 <3X2Y7guItVOoZXOK3KKv_nAReK494dbS60DVhSILgXzu_vqU0l0EnpJcJTobBlH1CyFua8pGdoQ8hj0mLvobPzUTUDT5zgswqIBDnOy1A-I=@protonmail.com>
Message-ID: <0f511e54-02ff-e024-a068-615b1e8fd18c@masterq32.de>


>> We can do ASCII art in Unicode - I don't get what the drive behind that remark was, mentioned earlier.
> 
> I can't wait for UTF-8 art :-)
Simply blockpixel UNICODE art:
	gemini://random-projects.net/
(shameless self-advertising)

From felix at masterq32.de  Wed Jun  3 12:40:55 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 3 Jun 2020 13:40:55 +0200
Subject: Three month spec freeze
In-Reply-To: <20200603004745.GN23998@brevard.conman.org>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <20200603004745.GN23998@brevard.conman.org>
Message-ID: <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>

> It was thus said that the Great Felix Quei?ner once stated:
lul

>   Secondly, Linux systems come with iconv.  Not only is this a program, but
> it's also a library which is dead simple to use as there are only three
> functions:
Yeah, i know these bindings and i know that libiconv is a thing. It's
still a dependency that *all* Gemini programs need to incorporate to be
*fully* compliant for displaying text/gemini files


>   RFC-1436 (the gopher RFC) suggests ISO Latin1 (ISO-8859-1 if I'm not
> mistaken) for 8-bit character sets and says *nothing* about UTF-8 (of
> course, it was written before UTF-8 was an RFC, three years later).  But
> most of the gopher sites I hit these days are UTF-8---it's rare that I
> actually encounter anything but UTF-8.

So, what you are saying is:
Most people already use utf-8, so there's no reason to enforce utf-8?

I think it's even more an argument to enforce UTF-8. It makes the
software way simpler and less error pronce, reducing the possibilities
of attacks via badly implemented encodings and also reduces the risk of
il-translated and badly displayed text.

Why drag a dependency on old cruft in when Gemini wants to be "as slim
as possible" and does not need to take care of "the old problems".

Regards
- xq

From tomasino at lavabit.com  Wed Jun  3 12:51:57 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Wed, 3 Jun 2020 11:51:57 +0000
Subject: Three month spec freeze
In-Reply-To: <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <20200603004745.GN23998@brevard.conman.org>
 <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>
Message-ID: <6d534723-f9aa-f8bc-d942-655302a6a3af@lavabit.com>

On 6/3/20 11:40 AM, Felix Quei?ner wrote:
> So, what you are saying is:
> Most people already use utf-8, so there's no reason to enforce utf-8?
> 
> I think it's even more an argument to enforce UTF-8. It makes the
> software way simpler and less error pronce, reducing the possibilities
> of attacks via badly implemented encodings and also reduces the risk of
> il-translated and badly displayed text.
> 
> Why drag a dependency on old cruft in when Gemini wants to be "as slim
> as possible" and does not need to take care of "the old problems".

I didn't have much skin in this discussion at the start, but the more I
understand things the more I support enforcing UTF-8 in text/gemini.

To be clear, though, we're talking specifically about text/gemini,
right? Not text/*. Since text/gemini support is all that's minimally
required for a client then only UTF-8 is minimally required for that
format. If authors were to add support for wider mime types they could
also add support for other encodings there. Or am I not following along
properly?


From defdefred at protonmail.com  Wed Jun  3 13:00:05 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 03 Jun 2020 12:00:05 +0000
Subject: Unicode-Art (WAS: Three month spec freeze)
In-Reply-To: <0f511e54-02ff-e024-a068-615b1e8fd18c@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <B2EE3A28-1B68-4E05-80C9-A0620674CE49@gmail.com>
 <3X2Y7guItVOoZXOK3KKv_nAReK494dbS60DVhSILgXzu_vqU0l0EnpJcJTobBlH1CyFua8pGdoQ8hj0mLvobPzUTUDT5zgswqIBDnOy1A-I=@protonmail.com>
 <0f511e54-02ff-e024-a068-615b1e8fd18c@masterq32.de>
Message-ID: <ydrB6uy9kmplTNYg-M0OTTX91eGO1EhC35kP_Ph8sdfO-TzmPjE0Z1XlKcKzVUqy5k0pQw2F-aHNWgaknhobziylMxxyva3v-SniQuPpnOw=@protonmail.com>

            ?        ?          ??? ???
?? ?? ?????   ?????  ?   ?   ?  ??  ??
?? ?? ?   ?   ?     ???  ?   ? ??? ???
  ?   ?   ?   ?????  ?   ?   ?  ?   ?
?? ?? ?   ?       ?  ?   ?   ?  ?   ?
?? ?? ??????  ?????  ??? ?????  ?   ?



Is it render properlly?


??????? Original Message ???????
On Wednesday 3 June 2020 13:33, Felix Quei?ner <felix at masterq32.de> wrote:

> > > We can do ASCII art in Unicode - I don't get what the drive behind that remark was, mentioned earlier.
> >
> > I can't wait for UTF-8 art :-)
>
> Simply blockpixel UNICODE art:
> gemini://random-projects.net/
> (shameless self-advertising)



From felix at masterq32.de  Wed Jun  3 13:18:35 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 3 Jun 2020 14:18:35 +0200
Subject: Three month spec freeze
In-Reply-To: <6d534723-f9aa-f8bc-d942-655302a6a3af@lavabit.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <20200603004745.GN23998@brevard.conman.org>
 <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>
 <6d534723-f9aa-f8bc-d942-655302a6a3af@lavabit.com>
Message-ID: <11b20ef3-60bc-f145-78c7-1eb470c5b1d9@masterq32.de>


> To be clear, though, we're talking specifically about text/gemini,
> right? Not text/*. Since text/gemini support is all that's minimally
> required for a client then only UTF-8 is minimally required for that
> format. If authors were to add support for wider mime types they could
> also add support for other encodings there. Or am I not following along
> properly?

Yes, exactly. Enforce UTF-8 for text/gemini which makes implementing a
minimal client that only supports utf-8, text/gemini and the gemini
protocol very easy.

From julien at typed-hole.org  Wed Jun  3 13:23:48 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Wed, 3 Jun 2020 14:23:48 +0200
Subject: Three month spec freeze
In-Reply-To: <11b20ef3-60bc-f145-78c7-1eb470c5b1d9@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <20200603004745.GN23998@brevard.conman.org>
 <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>
 <6d534723-f9aa-f8bc-d942-655302a6a3af@lavabit.com>
 <11b20ef3-60bc-f145-78c7-1eb470c5b1d9@masterq32.de>
Message-ID: <3501aa27-5fd9-65ad-1ee2-04063acb79ef@typed-hole.org>

On 03/06/2020 14:18, Felix Quei?ner wrote:
> 
> Yes, exactly. Enforce UTF-8 for text/gemini which makes implementing a
> minimal client that only supports utf-8, text/gemini and the gemini
> protocol very easy.
> 

 From the spec:
If a MIME type begins with "text/" and no charset is explicitly given,
the charset should be assumed to be UTF-8.  Compliant clients MUST
support UTF-8-encoded text/* responses.

From plugd at thelambdalab.xyz  Wed Jun  3 13:29:45 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Wed, 03 Jun 2020 14:29:45 +0200
Subject: Unicode-Art (WAS: Three month spec freeze)
In-Reply-To: <0f511e54-02ff-e024-a068-615b1e8fd18c@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <B2EE3A28-1B68-4E05-80C9-A0620674CE49@gmail.com>
 <3X2Y7guItVOoZXOK3KKv_nAReK494dbS60DVhSILgXzu_vqU0l0EnpJcJTobBlH1CyFua8pGdoQ8hj0mLvobPzUTUDT5zgswqIBDnOy1A-I=@protonmail.com>
 <0f511e54-02ff-e024-a068-615b1e8fd18c@masterq32.de>
Message-ID: <lzimg8s56u.fsf@bs-mbpr348.d.ethz.ch>

Felix Quei?ner writes:
> Simply blockpixel UNICODE art:
> 	gemini://random-projects.net/
> (shameless self-advertising)

Nice! Although I've gotta say that Quokka's capsule
gemini://bleyble.com/users/quokka/
is still the coolest I've seen so far, with the text-based webcam
gemini://bleyble.com/users/quokka/textcam/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/1b494bf7/attachment.sig>

From natpen at natpen.net  Wed Jun  3 13:41:22 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Wed, 3 Jun 2020 08:41:22 -0400
Subject: Three month spec freeze
In-Reply-To: <20200603005351.GO23998@brevard.conman.org>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <20200603005351.GO23998@brevard.conman.org>
Message-ID: <20200603124122.GE246841@goldfish.localdomain>

On Tue, Jun 02, 2020 at 08:53:51PM -0400, Sean Conner wrote:
>   And you are not limited to just text/gemini.  I know of one blog that is
> serving up text/markdown:
>
> 	gemini://alexschroeder.ch/

GUS can help with questions like these, FYI. In total, currently,
there are 54 markdown pages in Geminispace (out of ~6000 pages). The
blog you linked has the majority of markdown content currently in
Geminispace, but there are 3 other domains serving markdown as well
[0].

[0]
gemini://gus.guru/search?content_type%3Amarkdown%20AND%20NOT%20domain%3Aalexschroeder
(that query, without the url quoting, is "content_type:markdown AND NOT
domain:alexschroeder")

There's also the GUS statistics page [1], if you want an overview of all
the content types, just note that it lags behind the true counts by a
few days' worth of crawls for now, so its numbers can be slightly
underrepresentative.

[1] gemini://gus.guru/statistics

From sean at conman.org  Wed Jun  3 17:14:49 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 3 Jun 2020 12:14:49 -0400
Subject: Three month spec freeze
In-Reply-To: <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <20200603004745.GN23998@brevard.conman.org>
 <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>
Message-ID: <20200603161449.GV23998@brevard.conman.org>

It was thus said that the Great Felix Quei?ner once stated:
> > It was thus said that the Great Felix Quei?ner once stated:
> >   Secondly, Linux systems come with iconv.  Not only is this a program, but
> > it's also a library which is dead simple to use as there are only three
> > functions:
> 
> Yeah, i know these bindings and i know that libiconv is a thing. It's
> still a dependency that *all* Gemini programs need to incorporate to be
> *fully* compliant for displaying text/gemini files

  Yes, and because of the line breaking requirement of text/gemini, the
Unicode Line Breaking Algorithm is *also* required---a nice document of
20,000 words:

	https://www.unicode.org/reports/tr14/

  Your client does implement that, right?  Also, what does your client do if
it receives a BOM (byte order mark)?  That's illegal in UTF-8.  Also, what
Unicode normalization forms does it support?  What does it do when it
encounters an illegal byte in the document?

  Or does it pass everything along to the operating system?

> >   RFC-1436 (the gopher RFC) suggests ISO Latin1 (ISO-8859-1 if I'm not
> > mistaken) for 8-bit character sets and says *nothing* about UTF-8 (of
> > course, it was written before UTF-8 was an RFC, three years later).  But
> > most of the gopher sites I hit these days are UTF-8---it's rare that I
> > actually encounter anything but UTF-8.
> 
> So, what you are saying is:
> Most people already use utf-8, so there's no reason to enforce utf-8?

  Yes.

> I think it's even more an argument to enforce UTF-8. It makes the
> software way simpler and less error pronce, reducing the possibilities
> of attacks via badly implemented encodings and also reduces the risk of
> il-translated and badly displayed text.

  I don't agree fully, given some of my questions above.  Also, do you
filter out control sequences?  MS-DOS supported control sequences to
redefine the keyboard but I'm not sure if that is still the case with
Windows.

  -spc


From sean at conman.org  Wed Jun  3 17:32:23 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 3 Jun 2020 12:32:23 -0400
Subject: Three month spec freeze
In-Reply-To: <20200603124122.GE246841@goldfish.localdomain>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <20200603005351.GO23998@brevard.conman.org>
 <20200603124122.GE246841@goldfish.localdomain>
Message-ID: <20200603163223.GW23998@brevard.conman.org>

It was thus said that the Great Natalie Pendragon once stated:
> On Tue, Jun 02, 2020 at 08:53:51PM -0400, Sean Conner wrote:
> >   And you are not limited to just text/gemini.  I know of one blog that is
> > serving up text/markdown:
> >
> > 	gemini://alexschroeder.ch/
> 
> GUS can help with questions like these, FYI. In total, currently,
> there are 54 markdown pages in Geminispace (out of ~6000 pages). The
> blog you linked has the majority of markdown content currently in
> Geminispace, but there are 3 other domains serving markdown as well

  Since the following query isn't supported, could you check to see how many
text/gemini documents have a charset?  And if they do, what charset they
use?

  -spc


From jmcbray at carcosa.net  Wed Jun  3 19:08:44 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 03 Jun 2020 14:08:44 -0400
Subject: Three month spec freeze
In-Reply-To: <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch> (plugd@thelambdalab.xyz's
 message of "Tue, 02 Jun 2020 22:59:23 +0200")
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <87o8q0ja37.fsf@dorothy.carcosa.net>

plugd <plugd at thelambdalab.xyz> writes:
> Petite Abeille writes:

>> ? mandate >= TLS 1.3. Drop legacy support.
>>
>> Rational: no point dragging the burden of the past into the future.
>> Gemini innovative take on TLS deserves a modern foundation.
>
> Is this really necessary? What's so awesome about 1.3 from a
> layperson's perspective? I'm honestly asking, not just trying to be
> contrary. I worry this would increase the difficulty of complience
> without a real qualitative benifit. (Also, I think this would
> immediately break my server, so I'm biased. :-) )

I think it would break my server, too. I'm using a library that supports
1.3, but my previous attempts to force it to use only 1.3 were
unsuccessful.

There are several benefits to TLS 1.3, though. There are fewer options,
and thus fewer ways to mess up, and less legacy stuff to support. From
an end-user perspective, the main benefit is 0-RTT session resumption.
That's especially beneficial for us Geminauts, because we don't do
connection keep-alive, and pay the price of a TLS negotiation every
time. 

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From solderpunk at SDF.ORG  Wed Jun  3 19:15:10 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 3 Jun 2020 18:15:10 +0000
Subject: [ANN] cosmic.voyage joins gemini
In-Reply-To: <a0cbf993-8dc1-0a1a-8576-3bc4bb29ba4e@lavabit.com>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>
 <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>
 <lzzh9k7hd6.fsf@bs-mbpr348.d.ethz.ch>
 <a0cbf993-8dc1-0a1a-8576-3bc4bb29ba4e@lavabit.com>
Message-ID: <20200603181510.GA24058@SDF.ORG>

On Wed, Jun 03, 2020 at 08:17:46AM +0000, James Tomasino wrote:
> I'm pleased to announce that gemini://cosmic.voyage is up and running
> finally. That makes it accessible over gopher, web, and gemini (the
> trifecta!).

Very happy to see that this is official. :)  I appreciate you throwing
your support behind Gemini like this, and I'm sorry I ambandoned my ship
so early. :p

I've added you to the list of known hosts.  cosmic.voyage is number 48!
Only two places left before the hand-maintained list becomes
deprecated...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun  3 19:19:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 3 Jun 2020 18:19:12 +0000
Subject: Small break
Message-ID: <20200603181912.GB24058@SDF.ORG>

Ahoy Geminauts!

Just giving the list a heads up that I'm going to take a small break -
maybe 2 or 3 days - from posting to or reading the list.  This is not
because of anything anybody has said or done, I just need to slow the
pace down a little bit, clear my head and think about things quietly in
my own time.  I'll probably still be doing a little bit of hacking on
AV-98 and/or Molly Brown in this time, and if anybody wants an account
at gemini.circumlunar.space I'm happy to set that up, but I won't be
active here.  Just wanted to make it clear to anybody who otherwise
might have wondered that I haven't run away or disappeared!

Cheers,
Solderpunk

From petite.abeille at gmail.com  Wed Jun  3 19:25:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 20:25:37 +0200
Subject: content-disposition vs data URI
Message-ID: <B8F21775-37EB-4A1C-B53B-FE81BA3B5F04@gmail.com>

content-disposition defines either inline or attachment,  when it comes to how to display content.

text/gemini link is firmly in the external camp, assuming explicit user action to interact with linked content: a link is an external resource to the document, an attachment, to be activated by the user.

Additionally, perhaps text/gemini could embraces data url as small inline adornment.

For example, given a small data encoded vCard, 917 bytes long:

data:text/vcard;charset=utf-8;base64,QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOkd1bXA7Rm9ycmVzdDs7TXIuOw0KRk46Rm9ycmVzdCBHdW1wDQpPUkc6QnViYmEgR3VtcCBTaHJpbXAgQ28uDQpUSVRMRTpTaHJpbXAgTWFuDQpQSE9UTztNRURJQVRZUEU9aW1hZ2UvZ2lmOmh0dHA6Ly93d3cuZXhhbXBsZS5jb20vZGlyX3Bob3Rvcy9teV9waG90by5naWYNClRFTDtUWVBFPXdvcmssdm9pY2U7VkFMVUU9dXJpOnRlbDorMS0xMTEtNTU1LTEyMTINClRFTDtUWVBFPWhvbWUsdm9pY2U7VkFMVUU9dXJpOnRlbDorMS00MDQtNTU1LTEyMTINCkFEUjtUWVBFPVdPUks7UFJFRj0xO0xBQkVMPSIxMDAgV2F0ZXJzIEVkZ2VuQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzEwMCBXYXRlcnMgRWRnZTtCYXl0b3duO0xBOzMwMzE0O1VuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYQ0KQURSO1RZUEU9SE9NRTtMQUJFTD0iNDIgUGxhbnRhdGlvbiBTdC5uQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzQyIFBsYW50YXRpb24gU3QuO0JheXRvd247TEE7MzAzMTQ7VW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhDQpFTUFJTDpmb3JyZXN0Z3VtcEBleGFtcGxlLmNvbQ0KUkVWOjIwMDgwNDI0VDE5NTI0M1oNCngtcXE6MjE1ODg4OTENCkVORDpWQ0FSRA==

A client MAY render it inline, for the user to interact with, in any appropriate ways:

BEGIN:VCARD
VERSION:4.0
N:Gump;Forrest;;Mr.;
FN:Forrest Gump
ORG:Bubba Gump Shrimp Co.
TITLE:Shrimp Man
PHOTO;MEDIATYPE=image/gif:http://www.example.com/dir_photos/my_photo.gif
TEL;TYPE=work,voice;VALUE=uri:tel:+1-111-555-1212
TEL;TYPE=home,voice;VALUE=uri:tel:+1-404-555-1212
ADR;TYPE=WORK;PREF=1;LABEL="100 Waters Edge\nBaytown\, LA 30314\nUnited States of America":;;100 Waters Edge;Baytown;LA;30314;United States of America
ADR;TYPE=HOME;LABEL="42 Plantation St.\nBaytown\, LA 30314\nUnited States of America":;;42 Plantation St.;Baytown;LA;30314;United States of America
EMAIL:forrestgump at example.com
REV:20080424T195243Z
x-qq:21588891
END:VCARD

Forrest Gump
Bubba Gump Shrimp Co.
Shrimp Man

100 Waters Edge Baytown 
LA 30314
United States of America

+1-111-555-1212
forrestgump at example.com

There is a bunch of micro format such as text/vcard, text/calendar, text/directory, text/csv, application/x-x509-ca-cert , etc, etc, worthwhile displaying as small inline attachment.


[1] https://en.wikipedia.org/wiki/VCard




 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/f0664873/attachment.htm>

From mbays at sdf.org  Wed Jun  3 19:25:49 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Wed, 3 Jun 2020 20:25:49 +0200
Subject: Quoting (was: Three month spec freeze)
In-Reply-To: <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
 <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>
Message-ID: <20200603182549.gjnav7lbmdos47ss@gonzales.net>

* Wednesday, 2020-06-03 at 01:09 +0000 - James Tomasino <tomasino at lavabit.com>:

>There's a much easier way to do it. Just add a space at the start.
>
>```
> ```
>```

But then you have a space at the start.

>As for lines starting with a magic string, you can just put them inside
>a preformatted block.
>
>```
>=> gemini://linky.mcgoo
>```

But then it's a preformatted line, not a text line.

>I'm holding out hope that the space after the ``` will be used for 
>great purpose for accessibility. I think that's a much more productive
>direction than fringe cases of formatting.

Arguably. There are other ways to deal with this problem of quoting, if 
the one I suggested becomes unavailable.

I do think that one way or another, it should be possible to represent 
any text line and any preformatted line in a gemini document. Mostly for 
theoretical neatness, but also for practical purposes -- e.g. precisely 
quoting a gemini document.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/260cc1ef/attachment-0001.sig>

From colecmac at protonmail.com  Wed Jun  3 19:30:44 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 03 Jun 2020 18:30:44 +0000
Subject: [ANN] cosmic.voyage joins gemini
In-Reply-To: <20200603181510.GA24058@SDF.ORG>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <8tWmcM1ZJEP5nAUNZLkB-OU8p-H81YzpwIWxQdolnb3wI99ksxSBZL2UB90qxBh9R1tw40SmG5p8IqN0ET4XLhqW5nmzCii7lSR9c3DuwCg=@protonmail.com>
 <alpine.DEB.2.20.2006022215460.18317@pling.qwghlm.org>
 <lzzh9k7hd6.fsf@bs-mbpr348.d.ethz.ch>
 <a0cbf993-8dc1-0a1a-8576-3bc4bb29ba4e@lavabit.com>
 <20200603181510.GA24058@SDF.ORG>
Message-ID: <mkOsLfi0-Y0VfreXuOqlklTmujwhaV7-z-ewuJIHcMpq0niiq5x1ePAcd9tRufbzOKAcgCUlnCdfA0pD4Rp0HSYMY0qa4VdjKZJcTH-7IJg=@protonmail.com>

Could you add my server, makeworld.gq? I didn't realize you still had
spots to fill.

Thanks,
makeworld

??????? Original Message ???????
On Wednesday, June 3, 2020 2:15 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Wed, Jun 03, 2020 at 08:17:46AM +0000, James Tomasino wrote:
>
> > I'm pleased to announce that gemini://cosmic.voyage is up and running
> > finally. That makes it accessible over gopher, web, and gemini (the
> > trifecta!).
>
> Very happy to see that this is official. :) I appreciate you throwing
> your support behind Gemini like this, and I'm sorry I ambandoned my ship
> so early. :p
>
> I've added you to the list of known hosts. cosmic.voyage is number 48!
> Only two places left before the hand-maintained list becomes
> deprecated...
>
> Cheers,
> Solderpunk



From petite.abeille at gmail.com  Wed Jun  3 19:45:24 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 20:45:24 +0200
Subject: Three month spec freeze
In-Reply-To: <20200603005900.GP23998@brevard.conman.org>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
 <20200603005900.GP23998@brevard.conman.org>
Message-ID: <841B5AF2-0C6B-46E0-8850-10D989F91468@gmail.com>



> On Jun 3, 2020, at 02:59, Sean Conner <sean at conman.org> wrote:
> 
> Get a Gemini server working over wireguard.  Or both wireguard *and* TLS. 

Wireguard [1] manifest itself as a network interface, so one can run anything over it without much fuss, e.g. curl --interface wg0 or such. No need to change anything.

Rational:
https://www.linode.com/community/questions/19107/using-wireguard-protocol-vs-individual-ssl-connection

Or something like sshuttle is handy as well:

https://github.com/sshuttle/sshuttle
https://sshuttle.readthedocs.io/en/stable/usage.html


[1] https://www.wireguard.com/quickstart/

From petite.abeille at gmail.com  Wed Jun  3 19:54:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 20:54:19 +0200
Subject: approachabe & frugal & composable
In-Reply-To: <20200603012825.GT23998@brevard.conman.org>
References: <5E087B4C-72B9-4896-B289-D9CD458D54A1@gmail.com>
 <20200602181922.GC16068@SDF.ORG>
 <424D80BC-C93A-45CB-884B-E3AFB9B885E4@gmail.com>
 <20200602200042.GC11961@SDF.ORG>
 <3892A94D-C223-4E40-A576-63B871CA027D@gmail.com>
 <20200602214055.GH11961@SDF.ORG>
 <91E96077-BF31-4645-BDFC-92C199CA46BC@gmail.com>
 <20200603012825.GT23998@brevard.conman.org>
Message-ID: <198A9944-B0C8-49D8-A105-1EF415517D6A@gmail.com>



> On Jun 3, 2020, at 03:28, Sean Conner <sean at conman.org> wrote:
> 
>  Shouldn't that be: <tag://tools.ieft.org,1995-03-11:rfc2648>?

Not quite, no. Even though the IEFT could choose to use the tag uri for such purpose.

There is a dedicated URN Namespace for IETF Documents instead:

https://tools.ietf.org/html/rfc2648

So, urn:ietf:rfc:2648 is actually correct.

The original purpose of the tag URI is to allow anyone to mint unique identifiers, without bothering with a central authority:

https://en.wikipedia.org/wiki/Tag_URI_scheme
https://tools.ietf.org/html/rfc4151

Used to be popular in the syndication world (RSS/Atom/etc).

From petite.abeille at gmail.com  Wed Jun  3 19:56:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 20:56:09 +0200
Subject: Three month spec freeze
In-Reply-To: <lz5zc88wgd.fsf@bs-mbpr348.d.ethz.ch>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <1FD3EF18-2642-4DB2-9344-AEC26A8C893B@gmail.com>
 <lz5zc88wgd.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <0D41F5A3-3A0F-4034-AC76-07C37B9965B8@gmail.com>



> On Jun 3, 2020, at 09:01, plugd <plugd at thelambdalab.xyz> wrote:
> 
> Sorry, you're quoting me without context

Apologies. Brevity was too concise :)




From petite.abeille at gmail.com  Wed Jun  3 20:06:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 21:06:05 +0200
Subject: Unicode-Art (WAS: Three month spec freeze)
In-Reply-To: <lzimg8s56u.fsf@bs-mbpr348.d.ethz.ch>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <B2EE3A28-1B68-4E05-80C9-A0620674CE49@gmail.com>
 <3X2Y7guItVOoZXOK3KKv_nAReK494dbS60DVhSILgXzu_vqU0l0EnpJcJTobBlH1CyFua8pGdoQ8hj0mLvobPzUTUDT5zgswqIBDnOy1A-I=@protonmail.com>
 <0f511e54-02ff-e024-a068-615b1e8fd18c@masterq32.de>
 <lzimg8s56u.fsf@bs-mbpr348.d.ethz.ch>
Message-ID: <827B4C99-4A07-42FD-BCD9-77601E800CA6@gmail.com>



> On Jun 3, 2020, at 14:29, plugd <plugd at thelambdalab.xyz> wrote:
> 
> Nice! Although I've gotta say that Quokka's capsule
> gemini://bleyble.com/users/quokka/
> is still the coolest I've seen so far, with the text-based webcam
> gemini://bleyble.com/users/quokka/textcam/.

Cool :)

Random tools:

jp2a : Converts jpg images to ASCII
https://csl.name/jp2a/
https://github.com/cslarsen/jp2a

And more:
https://en.wikipedia.org/wiki/AAlib
https://en.wikipedia.org/wiki/Libcaca

Watch all of star wars in ASCII :D

https://asciinema.org/a/8




From petite.abeille at gmail.com  Wed Jun  3 20:08:00 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 21:08:00 +0200
Subject: Three month spec freeze
In-Reply-To: <20200603124122.GE246841@goldfish.localdomain>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <20200603005351.GO23998@brevard.conman.org>
 <20200603124122.GE246841@goldfish.localdomain>
Message-ID: <1E990F42-F5D9-41FB-94CF-C397119A867A@gmail.com>



> On Jun 3, 2020, at 14:41, Natalie Pendragon <natpen at natpen.net> wrote:
> 
> [1] gemini://gus.guru/statistics

Fabulous :)

Thanks for such great resource.


From petite.abeille at gmail.com  Wed Jun  3 20:10:30 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 21:10:30 +0200
Subject: Three month spec freeze
In-Reply-To: <20200603161449.GV23998@brevard.conman.org>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <KCxbUKM_rqt1GXAf76baNOW7AIC1fYoICOh7P5ZTbmcnwSBkkh21pUwF4j0xur1bidBm9uJuPtAbbWcT3FVYtmdfHxJg0bIIW1IgMeDQq4o=@protonmail.com>
 <05fa58a6-c3bc-eb78-da71-a331674e03d3@masterq32.de>
 <20200603004745.GN23998@brevard.conman.org>
 <d425bb35-994f-bb5a-6ace-430da3eb70e3@masterq32.de>
 <20200603161449.GV23998@brevard.conman.org>
Message-ID: <CB952B22-BF2B-466C-AB30-5553EB5180E8@gmail.com>



> On Jun 3, 2020, at 18:14, Sean Conner <sean at conman.org> wrote:
> 
>  Yes, and because of the line breaking requirement of text/gemini, the
> Unicode Line Breaking Algorithm is *also* required---a nice document of
> 20,000 words:

Stop scarring people! :D



From petite.abeille at gmail.com  Wed Jun  3 20:16:22 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 21:16:22 +0200
Subject: Quoting (was: Three month spec freeze)
In-Reply-To: <20200603182549.gjnav7lbmdos47ss@gonzales.net>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
 <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>
 <20200603182549.gjnav7lbmdos47ss@gonzales.net>
Message-ID: <9B201C3C-A233-48F9-8284-B2559CC37C5C@gmail.com>



> On Jun 3, 2020, at 20:25, mbays at sdf.org wrote:
> 
> I do think that one way or another, it should be possible to represent any text line and any preformatted line in a gemini document. Mostly for theoretical neatness, but also for practical purposes -- e.g. precisely quoting a gemini document.

Yes, one should be able to represent text/gemini in text/gemini. Say, for documentation purpose.

Is there any escape character or such?

E.g.:

\=>
\```
\#
\*
\\ -- escape the escape


From mbrubeck at limpet.net  Wed Jun  3 20:25:14 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Wed, 3 Jun 2020 12:25:14 -0700
Subject: Relative links vs scheme-less links
In-Reply-To: <FE15A672-0EDF-48B2-8E95-CD0339D0821F@gmail.com>
References: <7tLKoby9_tKEB5UW_wru5HOpJUqes3bx8a3N7ZUl6DTRGJ7NXHuBx6dFWMaIFfC7tzNzNDZruhMEwHPbfW7raZ9cAefzUlB8tiaegbs-XAc=@protonmail.com>
 <FE15A672-0EDF-48B2-8E95-CD0339D0821F@gmail.com>
Message-ID: <CAD1=23nMxun_ZC0HMp9edt8eTD0x1Gqqj-41Lj3nH3_UAp6c4g@mail.gmail.com>

By the way, in the WHATWG URL spec, the standard name for a ?scheme-less
URL? is a ?scheme-relative-URL string?:

https://url.spec.whatwg.org/#scheme-relative-url-string
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/83f17ce5/attachment.htm>

From tomasino at lavabit.com  Wed Jun  3 20:32:38 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Wed, 3 Jun 2020 19:32:38 +0000
Subject: Quoting (was: Three month spec freeze)
In-Reply-To: <9B201C3C-A233-48F9-8284-B2559CC37C5C@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
 <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>
 <20200603182549.gjnav7lbmdos47ss@gonzales.net>
 <9B201C3C-A233-48F9-8284-B2559CC37C5C@gmail.com>
Message-ID: <669192d6-cfdd-c811-915f-ea877f94c8f0@lavabit.com>

On 6/3/20 7:16 PM, Petite Abeille wrote:
> Yes, one should be able to represent text/gemini in text/gemini. Say, for documentation purpose.
> 
> Is there any escape character or such?

I would think that documenting text/gemini source in text/gemini would
use the ``` block to do so. In which case, the only outlier is the ```
itself. I like a simple indenting here to get around the issue since it
requires no work and is easy to discover with 5 minutes of trial and error.

If that's too ugly, there's always the good old zero-width space for you
crazy cats.
https://en.wikipedia.org/wiki/Zero-width_space


From petite.abeille at gmail.com  Wed Jun  3 20:43:08 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 3 Jun 2020 21:43:08 +0200
Subject: Quoting (was: Three month spec freeze)
In-Reply-To: <669192d6-cfdd-c811-915f-ea877f94c8f0@lavabit.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
 <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>
 <20200603182549.gjnav7lbmdos47ss@gonzales.net>
 <9B201C3C-A233-48F9-8284-B2559CC37C5C@gmail.com>
 <669192d6-cfdd-c811-915f-ea877f94c8f0@lavabit.com>
Message-ID: <D208EE9A-8277-4BE1-B71C-9214D6ED5F96@gmail.com>



> On Jun 3, 2020, at 21:32, James Tomasino <tomasino at lavabit.com> wrote:
> 
> If that's too ugly, there's always the good old zero-width space for you
> crazy cats.
> https://en.wikipedia.org/wiki/Zero-width_space

Ah, yes, another can of worms:

Blacklisting in URLs
ICANN rules prohibit domain names from including non-displayed characters such as zero-width space, and most browsers blacklist their use within domain names, because they can be used to create a homograph attack, where a malicious URL is visually indistinguishable from a legitimate one.

http://kb.mozillazine.org/Network.IDN.blacklist_chars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/d9492f8a/attachment.htm>

From luke.emmet at gmail.com  Wed Jun  3 20:50:13 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Wed, 03 Jun 2020 20:50:13 +0100
Subject: Quoting
In-Reply-To: <D208EE9A-8277-4BE1-B71C-9214D6ED5F96@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
 <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>
 <20200603182549.gjnav7lbmdos47ss@gonzales.net>
 <9B201C3C-A233-48F9-8284-B2559CC37C5C@gmail.com>
 <669192d6-cfdd-c811-915f-ea877f94c8f0@lavabit.com>
 <D208EE9A-8277-4BE1-B71C-9214D6ED5F96@gmail.com>
Message-ID: <5ED7FEF5.8030806@gmail.com>

Lets keep it simple please. Here are my 2p worth

For any quoting of the special line prefixes:

1. put within a ``` section inside text/gemini
2. serve the content with text/plain then you can say what you want
3. for quoting ``` prefix with a space or intersperse with a space thus 
` ` ` (or variant thereof)
4. Use a link to a text/plain or whatever other rich format

text/gemini format does not have its own meta language in it. It is 
supposed to be simple, if you need something else, use something else

zero width spaces and their ilk are horrible for many reasons, but 
security is a big one.

Best wishes

  - Luke

On 03-Jun-2020 20:43, Petite Abeille wrote:
>
>
>> On Jun 3, 2020, at 21:32, James Tomasino <tomasino at lavabit.com 
>> <mailto:tomasino at lavabit.com>> wrote:
>>
>> If that's too ugly, there's always the good old zero-width space for you
>> crazy cats.
>> https://en.wikipedia.org/wiki/Zero-width_space
>
> Ah, yes, another can of worms:
>
> *Blacklisting in URLs
> */ICANN rules prohibit domain names from including non-displayed 
> characters such as zero-width space, and most browsers blacklist their 
> use within domain names, because they can be used to create 
> a homograph attack, where a malicious URL is visually 
> indistinguishable from a legitimate one.
> /
> http://kb.mozillazine.org/Network.IDN.blacklist_chars
>

From acdw at acdw.net  Wed Jun  3 21:12:08 2020
From: acdw at acdw.net (Case Duckworth)
Date: Wed, 03 Jun 2020 15:12:08 -0500
Subject: Quoting
In-Reply-To: <5ED7FEF5.8030806@gmail.com>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <20200602230610.5goz46rmhtfjmdrl@gonzales.net>
 <71b35811-ae37-fa90-02f0-40c00a012a5f@lavabit.com>
 <20200603182549.gjnav7lbmdos47ss@gonzales.net>
 <9B201C3C-A233-48F9-8284-B2559CC37C5C@gmail.com>
 <669192d6-cfdd-c811-915f-ea877f94c8f0@lavabit.com>
 <D208EE9A-8277-4BE1-B71C-9214D6ED5F96@gmail.com> <5ED7FEF5.8030806@gmail.com>
Message-ID: <85f3a956-0b25-4a8e-9233-27093decea4a@www.fastmail.com>

On Wed, Jun 3, 2020, at 2:50 PM, Luke Emmet wrote:
> Lets keep it simple please. Here are my 2p worth
> 
> For any quoting of the special line prefixes:
> 
> 1. put within a ``` section inside text/gemini
> 2. serve the content with text/plain then you can say what you want
> 3. for quoting ``` prefix with a space or intersperse with a space thus 
> ` ` ` (or variant thereof)
> 4. Use a link to a text/plain or whatever other rich format
> 
> text/gemini format does not have its own meta language in it. It is 
> supposed to be simple, if you need something else, use something else

I agree with this. I can't think of a use-case where describing text/gemini formatting within a text/gemini document will need to be so flexible so that what Luke suggests won't work. Even if we implemented complex quoting rules, it's simply impossible to round-trip example documents in their own markup. 

Besides, I think marking examples with ``` is useful because it essentially quotes the enclosed content as an example, as opposed to actual content. If you want to copy-paste Gemini content easily, just don't filter the content before passing it on to the client.

Maybe if a specific use-case could be given to where quoting would be important?

~ acdw

From petite.abeille at gmail.com  Thu Jun  4 03:01:40 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 04:01:40 +0200
Subject: The Gemini Assigned Protocols Authority (GAPA)
Message-ID: <30878FE5-AEBD-4F45-9B4E-805D5B3F816B@gmail.com>

Similar to the Internet Assigned Numbers Authority (IANA), but for gemini/text links.

Could provide protocol assignments profile of registered gemini/text links URI schemes, ala mailcap: GEMCAP.

data inline
feed inline 
gopher attachment
http attachment
https attachment
mailto attachment
news attachment
tag inline

Nothing prescriptive, but rather normative. A MAY,  RFC wise.

This could provide an organizational principle to the URI space. A guidance. A norm.

GEMCAP could manifest itself as a network accessible, version controlled, gemini/text document maintained by the community.

From the mailcap introduction, dated September 1993:

"The electronic mail world is in the midst of a transition from
single-part text-only mail to multi-part, multi-media mail.  [...]

Various parties have demonstrated extremely high-functionality
multimedia mail, but the problem of mail interchange between
different user agents has been severe.  In general, only text
messages have been shared between user agents that were not
explicitly designed to work together.  This limitation is not
compatible with a smooth transition to a multi-media mail world."

[1] https://tools.ietf.org/html/rfc1524


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/9d70e20c/attachment-0001.htm>

From petite.abeille at gmail.com  Thu Jun  4 04:31:27 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 05:31:27 +0200
Subject: authorship tag 
Message-ID: <6EB3ACFC-EC4F-4B86-9818-4DC6D92DE0D0@gmail.com>

The tag URI  is defined as follow:

"tag:" authorityName "," YYYY-MM-DD-date ":" specific [ "#" fragment ]

text/gemini document could sport one, to convey authorship.

One could turn a gemini url into a tag, e.g.:

gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/microblogging-via-gemini-a-sketch.gmi
?
authorityName: gemini.circumlunar.space/users/solderpunk
date: 2020-06-01
specific: 5EFkbD
fragment: 16:59:06
?
tag:gemini.circumlunar.space/users/solderpunk,2020-06-01:5EFkbD#16:59:06


gemini://gemini.conman.org/gRFC/0002 
?
authorityName: gemini.conman.org
date: 2019-08-01
specific: 6tXsH
fragment: 20:46:12
?
tag:gemini.conman.org,2019-08-01:6tXsH#20:46:12


 A MAY,  RFC wise.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/9c0d6fd2/attachment.htm>

From petite.abeille at gmail.com  Thu Jun  4 05:25:29 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 06:25:29 +0200
Subject: robot capabilities
Message-ID: <3AB6E4DA-4E26-410A-AEBF-8E9A292C921B@gmail.com>

The robots exclusion standard defines a simple syntax to control access:

User-agent: *
Allow: /

Such syntax can express well-known locations:

Allow: /.well-known/feed --- syndication url
Allow: /.well-known/host-meta -- RFC6415
Allow: /.well-known/icon  -- favorite icon url

Data encoded in text/gemini. To advertise capabilities.

data:text/plain;charset=utf-8,User-agent%3A%20%2A%0D%0AAllow%3A%20%2F%0D%0AAllow%3A%20%2F.well-known%2Ffeed%0D%0AAllow%3A%20%2F.well-known%2Fhost-meta%0D%0AAllow%3A%20%2F.well-known%2Ficon

data:text/plain;charset=utf-8;base64,VXNlci1hZ2VudDogKg0KQWxsb3c6IC8NCkFsbG93OiAvLndlbGwta25vd24vZmVlZA0KQWxsb3c6IC8ud2VsbC1rbm93bi9ob3N0LW1ldGENCkFsbG93OiAvLndlbGwta25vd24vaWNvbg==

A MAY,  RFC wise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/5cabc9a5/attachment.htm>

From petite.abeille at gmail.com  Thu Jun  4 06:22:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 07:22:39 +0200
Subject: $$$[whitespace][text]<CR><LF>
Message-ID: <64E1D8DD-E48B-42AC-AC4E-8A149EF1BC07@gmail.com>

re: https://portal.mozz.us/gemini/gemini.thegonz.net/music.gmi <https://portal.mozz.us/gemini/gemini.thegonz.net/music.gmi>

Really I have to request the following new gemini line type:
$$$[whitespace][text]<CR><LF> : run text as a command in a unix shell.
Surely nothing could possibly go wrong with that?

Actually, you can do that today:

data:application/x-sh;charset=utf-8,echo%20%27main%28%29%7Bunsigned%20r%2Cs%2Ct%2Cm%2Cr2%3Dr%2Crt%2Co%2Ci%3Bfor%28%3B%3B%29%7Br%5E%3Dr%3C%3C13%3Br%5E%3Dr%3E%3E17%3Br%5E%3Dr%3C%3C5%3Bif%28%21%28r%250x7ffe%29%29%7Brt%3Dr%3Br%3Dr2%3Br2%3Drt%3B%7Dfor%28o%3Di%3D0%3Bi%3C32%3Bi%2B%3D8%29%7Bm%3D255%3C%3Ci%3Bt%5E%3D%28t%5E%28t%2B%28s%26m%29%29%29%26m%3Bo%2B%3D%28t%26m%29%3E%3Ei%2B2%3Bs%3Dr%25m%3Fs%3As%2B%28%28r%262%29-1%29%3C%3Ci%3B%7Ds%3Dr%250xffff%3Fs%3A%28s%3E%3E8%29%7C%28%28s%26255%29%3C%3C24%29%3Bputchar%28o%29%3B%7D%7D%27%20%7C%20gcc%20-x%20c%20-o%20%2Ftmp%2FbeautifulMusic%20-%20%26%26%20%2Ftmp%2FbeautifulMusic%20%7C%20aplay

data:application/x-sh;charset=utf-8;base64,ZWNobyAnbWFpbigpe3Vuc2lnbmVkIHIscyx0LG0scjI9cixydCxvLGk7Zm9yKDs7KXtyXj1yPDwxMztyXj1yPj4xNztyXj1yPDw1O2lmKCEociUweDdmZmUpKXtydD1yO3I9cjI7cjI9cnQ7fWZvcihvPWk9MDtpPDMyO2krPTgpe209MjU1PDxpO3RePSh0Xih0KyhzJm0pKSkmbTtvKz0odCZtKT4+aSsyO3M9ciVtP3M6cysoKHImMiktMSk8PGk7fXM9ciUweGZmZmY/czoocz4+OCl8KChzJjI1NSk8PDI0KTtwdXRjaGFyKG8pO319JyB8IGdjYyAteCBjIC1vIC90bXAvYmVhdXRpZnVsTXVzaWMgLSAmJiAvdG1wL2JlYXV0aWZ1bE11c2ljIHwgYXBsYXk=

This doesn't necessarily guaranty such construct will be auto-executed on the client. Surely not. A simple attachment perhaps. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/c0c54d38/attachment.htm>

From tkarpiniec at icloud.com  Thu Jun  4 08:24:38 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Thu, 4 Jun 2020 17:24:38 +1000
Subject: authorship tag
In-Reply-To: <6EB3ACFC-EC4F-4B86-9818-4DC6D92DE0D0@gmail.com>
References: <6EB3ACFC-EC4F-4B86-9818-4DC6D92DE0D0@gmail.com>
Message-ID: <20200604072438.GA70547@allanon.local>

On Thu, Jun 04, 2020 at 05:31:27AM +0200, Petite Abeille wrote:
> The tag URI  is defined as follow:
> 
> "tag:" authorityName "," YYYY-MM-DD-date ":" specific [ "#" fragment ]
> 
> text/gemini document could sport one, to convey authorship.
> 
> One could turn a gemini url into a tag, e.g.:

I'm not clear what that would gain me as either an author or as a
reader?

This suggestion, along with anything else involving packing
"interesting" data inside URIs is very reminiscent of the semantic
web. The idea of the semantic web is that documents are optimised for
reading by _computers_, in ways that web documents currently are not.

Everything about the existing specification of text/gemini, along with
the discussions on this list worrying about how documents look for
those who simply "cat" the contents to screen, suggests a desire for a
document format that is optimised for _human_ consumption even in its
bare form. When meaningful information becomes sandwiched between
colons and URL-encoded, or worse base64-encoded, then that's at odds
with human readability. For all practical purposes computer assistance
is required to extract and interpret the information content, content
that could otherwise have been written in English.

Taken together your ideas seem like an interesting project, one that
could easily operate over the gemini transfer protocol, but such URIs
seem at odds with the dominant usage of text/gemini specifically.

Cheers,

Tom


From luke.emmet at gmail.com  Thu Jun  4 12:22:21 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 04 Jun 2020 12:22:21 +0100
Subject: Lightweight Unicode Author Client Hinting - LUACH proposal
Message-ID: <5ED8D96D.70706@gmail.com>

Hello everyone

I've been thinking about various discussions we've been having on the 
list related to how to use and build on/augment the geminisphere in a 
way that is true to the gemini vision, such as how do we:

- indicate and find comments between pages in a lightweight gemini-way
- provide ways to optionally "include" images or text
- signal where is your a site home page
- provide a common navigation menu
- indicate the location of your site logo

I've started a proposal to define a way for an author to signal these 
elements in a lightweight, text based and optional way, dubbed 
"Lightweight Unicode Author Client Hinting for Gemini - LUACH"

The idea is to codify a minimal set of conventions we can use to build 
further structure on top of the gemini space to support additional 
purposes.

I must emphasis the intention is for this to be *wholly optional* and I 
dont think it needs to become part of the canonical standard, as it is 
just a set of optional text conventions. Maybe if successful it could be 
a set of common conventions that are becoming adopted, and a good 
practice. It codifies things that are emerging as common conventions we 
see in geminispace, or more widely. For example "standard" names for 
home page or ways of communicating comments textually

=> gemini://myowndomain/home.gmi Home
=> gemini://xyzdomain/cookery/egg-recipies.gmi Responds to XYZ thoughts 
on how to cook eggs

Or as we already see the use of unicode glyphs to indicate comments such 
as the speech bubble ? emoji or house ? for home.

This is intended to be very lightweight and helpful for readers using 
simple command line clients as much as it might be for richer clients 
who may provide additional UI. There isnt any overhead for authors apart 
from providing these optional hints in their link text, which can help 
everyone.

The "responds to" and "has comments" can be used by search crawlers to 
build a meta layer of who is commenting on whom within gemini space

I've put it in Github here:

https://github.com/LukeEmmet/GeminiLUACH

Comments and further thoughts welcome

Best wishes

- Luke

From petite_abeille at me.com  Thu Jun  4 06:17:25 2020
From: petite_abeille at me.com (Petite Abeille)
Date: Thu, 4 Jun 2020 07:17:25 +0200
Subject: $$$[whitespace][text]<CR><LF>
Message-ID: <8E4A62EE-1C48-4FAA-8FF8-9D53B0B7A4FC@me.com>

re: https://portal.mozz.us/gemini/gemini.thegonz.net/music.gmi

Really I have to request the following new gemini line type:
$$$[whitespace][text]<CR><LF> : run text as a command in a unix shell.
Surely nothing could possibly go wrong with that?

Actually, you can do that today:

data:application/x-sh;charset=utf-8,echo%20%27main%28%29%7Bunsigned%20r%2Cs%2Ct%2Cm%2Cr2%3Dr%2Crt%2Co%2Ci%3Bfor%28%3B%3B%29%7Br%5E%3Dr%3C%3C13%3Br%5E%3Dr%3E%3E17%3Br%5E%3Dr%3C%3C5%3Bif%28%21%28r%250x7ffe%29%29%7Brt%3Dr%3Br%3Dr2%3Br2%3Drt%3B%7Dfor%28o%3Di%3D0%3Bi%3C32%3Bi%2B%3D8%29%7Bm%3D255%3C%3Ci%3Bt%5E%3D%28t%5E%28t%2B%28s%26m%29%29%29%26m%3Bo%2B%3D%28t%26m%29%3E%3Ei%2B2%3Bs%3Dr%25m%3Fs%3As%2B%28%28r%262%29-1%29%3C%3Ci%3B%7Ds%3Dr%250xffff%3Fs%3A%28s%3E%3E8%29%7C%28%28s%26255%29%3C%3C24%29%3Bputchar%28o%29%3B%7D%7D%27%20%7C%20gcc%20-x%20c%20-o%20%2Ftmp%2FbeautifulMusic%20-%20%26%26%20%2Ftmp%2FbeautifulMusic%20%7C%20aplay

data:application/x-sh;charset=utf-8;base64,ZWNobyAnbWFpbigpe3Vuc2lnbmVkIHIscyx0LG0scjI9cixydCxvLGk7Zm9yKDs7KXtyXj1yPDwxMztyXj1yPj4xNztyXj1yPDw1O2lmKCEociUweDdmZmUpKXtydD1yO3I9cjI7cjI9cnQ7fWZvcihvPWk9MDtpPDMyO2krPTgpe209MjU1PDxpO3RePSh0Xih0KyhzJm0pKSkmbTtvKz0odCZtKT4+aSsyO3M9ciVtP3M6cysoKHImMiktMSk8PGk7fXM9ciUweGZmZmY/czoocz4+OCl8KChzJjI1NSk8PDI0KTtwdXRjaGFyKG8pO319JyB8IGdjYyAteCBjIC1vIC90bXAvYmVhdXRpZnVsTXVzaWMgLSAmJiAvdG1wL2JlYXV0aWZ1bE11c2ljIHwgYXBsYXk=

This doesn't necessarily guaranty such construct will be auto-executed on the client. Surely not. A simple attachment perhaps. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/84f5c877/attachment.htm>

From defdefred at protonmail.com  Thu Jun  4 13:26:06 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 04 Jun 2020 12:26:06 +0000
Subject: $$$[whitespace][text]<CR><LF>
In-Reply-To: <8E4A62EE-1C48-4FAA-8FF8-9D53B0B7A4FC@me.com>
References: <8E4A62EE-1C48-4FAA-8FF8-9D53B0B7A4FC@me.com>
Message-ID: <NGzttEovKvbK8rbu_0GumdALbfeNAwx6zrY80r67q6nN6afD02cXAYKkJBneYq1KgMmJLrkYMZiTHJEnOJRpqZ1jUD577o9hg2hbrqP-m1I=@protonmail.com>

Running shell from internet on one click...
Fine ... just try with "rm -rf *"

Sent with [ProtonMail](https://protonmail.com) Secure Email.

??????? Original Message ???????
On Thursday 4 June 2020 07:17, Petite Abeille <petite_abeille at me.com> wrote:

> re: https://portal.mozz.us/gemini/gemini.thegonz.net/music.gmi
>
> Really I have to request the following new gemini line type:
> $$$[whitespace][text]<CR><LF> : run text as a command in a unix shell.
> Surely nothing could possibly go wrong with that?
>
> Actually, you can do that today:
>
> data:application/x-sh;charset=utf-8,echo%20%27main%28%29%7Bunsigned%20r%2Cs%2Ct%2Cm%2Cr2%3Dr%2Crt%2Co%2Ci%3Bfor%28%3B%3B%29%7Br%5E%3Dr%3C%3C13%3Br%5E%3Dr%3E%3E17%3Br%5E%3Dr%3C%3C5%3Bif%28%21%28r%250x7ffe%29%29%7Brt%3Dr%3Br%3Dr2%3Br2%3Drt%3B%7Dfor%28o%3Di%3D0%3Bi%3C32%3Bi%2B%3D8%29%7Bm%3D255%3C%3Ci%3Bt%5E%3D%28t%5E%28t%2B%28s%26m%29%29%29%26m%3Bo%2B%3D%28t%26m%29%3E%3Ei%2B2%3Bs%3Dr%25m%3Fs%3As%2B%28%28r%262%29-1%29%3C%3Ci%3B%7Ds%3Dr%250xffff%3Fs%3A%28s%3E%3E8%29%7C%28%28s%26255%29%3C%3C24%29%3Bputchar%28o%29%3B%7D%7D%27%20%7C%20gcc%20-x%20c%20-o%20%2Ftmp%2FbeautifulMusic%20-%20%26%26%20%2Ftmp%2FbeautifulMusic%20%7C%20aplay
>
> data:application/x-sh;charset=utf-8;base64,ZWNobyAnbWFpbigpe3Vuc2lnbmVkIHIscyx0LG0scjI9cixydCxvLGk7Zm9yKDs7KXtyXj1yPDwxMztyXj1yPj4xNztyXj1yPDw1O2lmKCEociUweDdmZmUpKXtydD1yO3I9cjI7cjI9cnQ7fWZvcihvPWk9MDtpPDMyO2krPTgpe209MjU1PDxpO3RePSh0Xih0KyhzJm0pKSkmbTtvKz0odCZtKT4+aSsyO3M9ciVtP3M6cysoKHImMiktMSk8PGk7fXM9ciUweGZmZmY/czoocz4+OCl8KChzJjI1NSk8PDI0KTtwdXRjaGFyKG8pO319JyB8IGdjYyAteCBjIC1vIC90bXAvYmVhdXRpZnVsTXVzaWMgLSAmJiAvdG1wL2JlYXV0aWZ1bE11c2ljIHwgYXBsYXk=
>
> This doesn't necessarily guaranty such construct will be auto-executed on the client. Surely not. A simple attachment perhaps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/a45d3592/attachment.htm>

From colecmac at protonmail.com  Thu Jun  4 14:50:54 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 04 Jun 2020 13:50:54 +0000
Subject: Lightweight Unicode Author Client Hinting - LUACH proposal
In-Reply-To: <5ED8D96D.70706@gmail.com>
References: <5ED8D96D.70706@gmail.com>
Message-ID: <tDheP6X_2cL8Dtf71SwPs4sqOfySYYDaISrtlIkKI0V_O1wvY0rr8RyW1AGTh2JjA44DQph3gleJNuuzrgfV6hn4hwXF3bzDre5_7jxm8_Q=@protonmail.com>

This is an interesting proposal, but I feel like it would become a
chore when writing, something you'd try and remember to do because it
wouldn't feel natural. Which is probably the opposite of what we want.

I also don't see the total need for this, could you maybe explain more
about a use case?

makeworld

??????? Original Message ???????
On Thursday, June 4, 2020 7:22 AM, Luke Emmet <luke.emmet at gmail.com> wrote:

> Hello everyone
>
> I've been thinking about various discussions we've been having on the
> list related to how to use and build on/augment the geminisphere in a
> way that is true to the gemini vision, such as how do we:
>
> -   indicate and find comments between pages in a lightweight gemini-way
> -   provide ways to optionally "include" images or text
> -   signal where is your a site home page
> -   provide a common navigation menu
> -   indicate the location of your site logo
>
>     I've started a proposal to define a way for an author to signal these
>     elements in a lightweight, text based and optional way, dubbed
>     "Lightweight Unicode Author Client Hinting for Gemini - LUACH"
>
>     The idea is to codify a minimal set of conventions we can use to build
>     further structure on top of the gemini space to support additional
>     purposes.
>
>     I must emphasis the intention is for this to be wholly optional and I
>     dont think it needs to become part of the canonical standard, as it is
>     just a set of optional text conventions. Maybe if successful it could be
>     a set of common conventions that are becoming adopted, and a good
>     practice. It codifies things that are emerging as common conventions we
>     see in geminispace, or more widely. For example "standard" names for
>     home page or ways of communicating comments textually
>
>     => gemini://myowndomain/home.gmi Home
>
>
> => gemini://xyzdomain/cookery/egg-recipies.gmi Responds to XYZ thoughts
> on how to cook eggs
>
> Or as we already see the use of unicode glyphs to indicate comments such
> as the speech bubble ? emoji or house ? for home.
>
> This is intended to be very lightweight and helpful for readers using
> simple command line clients as much as it might be for richer clients
> who may provide additional UI. There isnt any overhead for authors apart
> from providing these optional hints in their link text, which can help
> everyone.
>
> The "responds to" and "has comments" can be used by search crawlers to
> build a meta layer of who is commenting on whom within gemini space
>
> I've put it in Github here:
>
> https://github.com/LukeEmmet/GeminiLUACH
>
> Comments and further thoughts welcome
>
> Best wishes
>
> -   Luke



From luke.emmet at gmail.com  Thu Jun  4 15:17:13 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 04 Jun 2020 15:17:13 +0100
Subject: Lightweight Unicode Author Client Hinting - LUACH proposal
In-Reply-To: <tDheP6X_2cL8Dtf71SwPs4sqOfySYYDaISrtlIkKI0V_O1wvY0rr8RyW1AGTh2JjA44DQph3gleJNuuzrgfV6hn4hwXF3bzDre5_7jxm8_Q=@protonmail.com>
References: <5ED8D96D.70706@gmail.com>
 <tDheP6X_2cL8Dtf71SwPs4sqOfySYYDaISrtlIkKI0V_O1wvY0rr8RyW1AGTh2JjA44DQph3gleJNuuzrgfV6hn4hwXF3bzDre5_7jxm8_Q=@protonmail.com>
Message-ID: <5ED90269.2000909@gmail.com>

Hello makeworld

There are a number of use cases I have in mind, but all are intended to 
be within the spirit of gemini as presented so far.

1. Helps to assemble the meta-graph of commentary between pages. Various 
gemini search engines (global or local) could show you for any provided 
URL what other pages have provided comments or responses. If a link is 
not decorated some how, the search bot cannot tell if you are merely 
linking to a site or responding to it. In this way I think it could 
support a gemini-flavoured commentary infrastructure

2. Improved UI for clients navigating a site. If you follow a link deep 
into a site you may not know where the "home" is or other common 
navigational links (you might guess). This could provide a way to 
canonically indicate it.

3. Optional inclusion of content in-context. For example to see a figure 
within a page, without it being forced to be included (as is with html). 
It is a hint that can be taken or not depending on user preference.

4. To better enable navigation of everyone through gemini space. Better 
knowing what you will get before you click on a link is a way for 
everyone to make a calculation as to whether you want to follow the link 
or if you dont need to.

As to the matter of naturalness, it is intended to be as lightweight as 
it can be and builds on practices that already exist  (e.g. speech 
bubble or home emoji, or the normal practice of using "home" as the link 
display text). I tried to choose a simple and hopefully-salient set of 
elements, but the actual code points and text is up for discussion.

There is a textual form as well as the unicode code points, so for 
example you can just do this

=>menu.gmi Site [navigation]

There might be other use cases that could make use of the pattern, but I 
think the point would be to have a minimally useful set to start with 
and see how it goes. At the moment we are in the same situation as the 
web where every link is an untyped reference and there is no way of 
understanding the deeper structure unless you have the resources of 
Google behind you.

The actual details can be evolved, its really whether the pattern is 
useful as a codified convention on top of Gemini, and to explore what 
the network effects or authors, clients, search, applications, adopting 
this or something like it would need to be be to make it work (one site 
doing it alone is of little value).

Best Wishes

  - Luke

On 04-Jun-2020 14:50, colecmac at protonmail.com wrote:
> This is an interesting proposal, but I feel like it would become a
> chore when writing, something you'd try and remember to do because it
> wouldn't feel natural. Which is probably the opposite of what we want.
>
> I also don't see the total need for this, could you maybe explain more
> about a use case?
>
> makeworld
>
> ??????? Original Message ???????
> On Thursday, June 4, 2020 7:22 AM, Luke Emmet<luke.emmet at gmail.com>  wrote:
>
>> Hello everyone
>>
>> I've been thinking about various discussions we've been having on the
>> list related to how to use and build on/augment the geminisphere in a
>> way that is true to the gemini vision, such as how do we:
>>
>> -   indicate and find comments between pages in a lightweight gemini-way
>> -   provide ways to optionally "include" images or text
>> -   signal where is your a site home page
>> -   provide a common navigation menu
>> -   indicate the location of your site logo
>>
>>      I've started a proposal to define a way for an author to signal these
>>      elements in a lightweight, text based and optional way, dubbed
>>      "Lightweight Unicode Author Client Hinting for Gemini - LUACH"
>>
>>      The idea is to codify a minimal set of conventions we can use to build
>>      further structure on top of the gemini space to support additional
>>      purposes.
>>
>>      I must emphasis the intention is for this to be wholly optional and I
>>      dont think it needs to become part of the canonical standard, as it is
>>      just a set of optional text conventions. Maybe if successful it could be
>>      a set of common conventions that are becoming adopted, and a good
>>      practice. It codifies things that are emerging as common conventions we
>>      see in geminispace, or more widely. For example "standard" names for
>>      home page or ways of communicating comments textually
>>
>>      =>  gemini://myowndomain/home.gmi Home
>>
>>
>> =>  gemini://xyzdomain/cookery/egg-recipies.gmi Responds to XYZ thoughts
>> on how to cook eggs
>>
>> Or as we already see the use of unicode glyphs to indicate comments such
>> as the speech bubble ? emoji or house ? for home.
>>
>> This is intended to be very lightweight and helpful for readers using
>> simple command line clients as much as it might be for richer clients
>> who may provide additional UI. There isnt any overhead for authors apart
>> from providing these optional hints in their link text, which can help
>> everyone.
>>
>> The "responds to" and "has comments" can be used by search crawlers to
>> build a meta layer of who is commenting on whom within gemini space
>>
>> I've put it in Github here:
>>
>> https://github.com/LukeEmmet/GeminiLUACH
>>
>> Comments and further thoughts welcome
>>
>> Best wishes
>>
>> -   Luke
>

From petite.abeille at gmail.com  Thu Jun  4 16:02:30 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 17:02:30 +0200
Subject: authorship tag
In-Reply-To: <20200604072438.GA70547@allanon.local>
References: <6EB3ACFC-EC4F-4B86-9818-4DC6D92DE0D0@gmail.com>
 <20200604072438.GA70547@allanon.local>
Message-ID: <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>



> On Jun 4, 2020, at 09:24, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:
> 
> I'm not clear what that would gain me as either an author or as a
> reader?

Our Imagination is the limit :)

For example:

For one, as both an author & a reader, I like to have text anchored in time. Nothing happen in a vacuum.

gemini and text/gemini have no notion of time at all.

Instead people tend to compensate by haphazardly leaving contextual breadcrumbs here and there about such basic information:

? gemini://gemini.circumlunar.space/~solderpunk/cornedbeef/
=> microblogging-via-gemini-a-sketch.gmi	2020-06-01 - Microblogging via Gemini: a sketch
=> replies-in-geminispace.gmi	2020-05-31 - Replies in Geminispace
=> the-mercury-protocol.gmi	2020-05-26 - The Mercury Protocol
=> tls-musings.gmi		2020-05-14 - TLS musings
=> gemini-hearts-atom.gmi	2020-03-20 - Gemini ??s Atom! 

? gemini://gemini.conman.org/gRFC/
=> 0001 0001 2019-08-01 PROPOSED MIME type and parameters for Gemini Index Files
=> 0002 0002 2019-08-01 ACCEPTED Resource request format for Gemini
=> 0003 0003 2019-08-01 PROPOSED Response header to include optional file size in reply
=> 0004 0004 2019-09-06 PROPOSED Gemini index format

The authorship tag gives a simple and consistent way to embed such date in the text/gemini document itself.

Furthermore, the tag provides, well,  authorship information: who did it?

E.g. gemini.circumlunar.space/~solderpunk points to solderpunk actual home at circumlunar.

This could be used creatively, by, say, uniquely styling ~solderpunk documents with sigil, color scheme, whatnot:

? gemini.circumlunar.space/~solderpunk ? f01c0885 ? 4028369029 ? ~lapryt-fidseg ? sigil

This provides a more stable and granular alternative to the host IP address or certificate.

Finally, the tag itself is rather readable on its own:

tag:gemini.conman.org <http://gemini.conman.org/>,2019-08-01:gRFC/0002 <gemini://gemini.conman.org/gRFC/0002>#20:46:12

One tag, covering the Who, When, and What, in one fell swoop. 

https://en.wikipedia.org/wiki/Five_Ws <https://en.wikipedia.org/wiki/Five_Ws>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/a062caa5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigil.svg
Type: image/svg+xml
Size: 2846 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/a062caa5/attachment.svg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/a062caa5/attachment-0001.htm>

From prisonpotato at tilde.team  Thu Jun  4 16:37:54 2020
From: prisonpotato at tilde.team (prisonpotato at tilde.team)
Date: Thu, 4 Jun 2020 11:37:54 -0400
Subject: Lightweight Unicode Author Client Hinting - LUACH proposal
In-Reply-To: <5ED8D96D.70706@gmail.com>
References: <5ED8D96D.70706@gmail.com>
Message-ID: <20200604153754.GA25314@tilde.team>

I like this idea, with a few exceptions.
For the logo (?) proposal, I like the favicon.txt proposal as a better,
terminal compliant way to solve this problem.
I'm also not sure how the Menu (? ) is different from Home (?).

On Thu, Jun 04, 2020 at 12:22:21PM +0100, Luke Emmet wrote:
> Hello everyone
> 
> I've been thinking about various discussions we've been having on the list
> related to how to use and build on/augment the geminisphere in a way that is
> true to the gemini vision, such as how do we:
> 
> - indicate and find comments between pages in a lightweight gemini-way
> - provide ways to optionally "include" images or text
> - signal where is your a site home page
> - provide a common navigation menu
> - indicate the location of your site logo
> 
> I've started a proposal to define a way for an author to signal these
> elements in a lightweight, text based and optional way, dubbed "Lightweight
> Unicode Author Client Hinting for Gemini - LUACH"
> 
> The idea is to codify a minimal set of conventions we can use to build
> further structure on top of the gemini space to support additional purposes.
> 
> I must emphasis the intention is for this to be *wholly optional* and I dont
> think it needs to become part of the canonical standard, as it is just a set
> of optional text conventions. Maybe if successful it could be a set of
> common conventions that are becoming adopted, and a good practice. It
> codifies things that are emerging as common conventions we see in
> geminispace, or more widely. For example "standard" names for home page or
> ways of communicating comments textually
> 
> => gemini://myowndomain/home.gmi Home
> => gemini://xyzdomain/cookery/egg-recipies.gmi Responds to XYZ thoughts on
> how to cook eggs
> 
> Or as we already see the use of unicode glyphs to indicate comments such as
> the speech bubble ? emoji or house ? for home.
> 
> This is intended to be very lightweight and helpful for readers using simple
> command line clients as much as it might be for richer clients who may
> provide additional UI. There isnt any overhead for authors apart from
> providing these optional hints in their link text, which can help everyone.
> 
> The "responds to" and "has comments" can be used by search crawlers to build
> a meta layer of who is commenting on whom within gemini space
> 
> I've put it in Github here:
> 
> https://github.com/LukeEmmet/GeminiLUACH
> 
> Comments and further thoughts welcome
> 
> Best wishes
> 
> - Luke

From alex at alexschroeder.ch  Thu Jun  4 16:41:49 2020
From: alex at alexschroeder.ch (Alex Schroeder)
Date: Thu, 4 Jun 2020 17:41:49 +0200
Subject: authorship tag
In-Reply-To: <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>
References: <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>
Message-ID: <1B783825-57AB-45D8-B603-BB67F504F88F@alexschroeder.ch>

I?m reminded of the Wiki Mode for RSS?

https://communitywiki.org/wiki/WikiModule

And that in turn reminds me of the gopher module for feeds I had written, so that we can have one feed for the web and gopher (and why not add Gemini, too). In which case I?d consider the wiki module to be relevant.

Anyway, just more stuff to read and only tangentially related to inline tagging of documents.

I guess we could just have stuff at the bottom of text files:

#author:Alex_Schroeder #date:2020-06-05 #feeds #wiki #metadata #tagging #folksonomy #tags #ohmygodwhenwillitstop

At least I do remember the simple tagging convention for phlogs. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/a4a40261/attachment.htm>

From jmcbray at carcosa.net  Thu Jun  4 16:45:57 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 04 Jun 2020 11:45:57 -0400
Subject: Small break
In-Reply-To: <20200603181912.GB24058@SDF.ORG> (solderpunk@sdf.org's message of
 "Wed, 3 Jun 2020 18:19:12 +0000")
References: <20200603181912.GB24058@SDF.ORG>
Message-ID: <87a71iq1fu.fsf@dorothy.carcosa.net>

Slowing things down sounds like a good idea to me, too. I'm hoping to
have energy to work on Germinal soon. I've published code for Voskhod,
but I'm going to declare it abandoned and free up the name for anyone
else who wants to use it. I had too much trouble with Gnome Builder and
Python having conflicting ideas about how to package things, and left it
before I actually got it loading anything. Anyway, Castor and
especially dragonstone cover too much of the same ground for me to be
super interested in finishing Voskhod.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Thu Jun  4 16:48:58 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 04 Jun 2020 11:48:58 -0400
Subject: content-disposition vs data URI
In-Reply-To: <B8F21775-37EB-4A1C-B53B-FE81BA3B5F04@gmail.com> (Petite
 Abeille's message of "Wed, 3 Jun 2020 20:25:37 +0200")
References: <B8F21775-37EB-4A1C-B53B-FE81BA3B5F04@gmail.com>
Message-ID: <875zc6q1at.fsf@dorothy.carcosa.net>

Petite Abeille <petite.abeille at gmail.com> writes:

> Additionally, perhaps text/gemini could embraces data url as small inline adornment.
>
> For example, given a small data encoded vCard, 917 bytes long:
>
> data:text/vcard;charset=utf-8;base64,QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOkd1bXA7Rm9ycmVzdDs7TXIuOw0KRk46Rm9ycmVzdCBHdW1wDQpPUkc6QnViYmEgR3VtcCBTaHJpbXAgQ28uDQpUSVRMRTpTaHJpbXAgTWFuDQpQSE9UTztNRURJQVRZUEU9aW1hZ2UvZ2lmOmh0dHA6Ly93d3cuZXhhbXBsZS5jb20vZGlyX3Bob3Rvcy9teV9waG90by5naWYNClRFTDtUWVBFPXdvcmssdm9pY2U7VkFMVUU9dXJpOnRlbDorMS0xMTEtNTU1LTEyMTINClRFTDtUWVBFPWhvbWUsdm9pY2U7VkFMVUU9dXJpOnRlbDorMS00MDQtNTU1LTEyMTINCkFEUjtUWVBFPVdPUks7UFJFRj0xO0xBQkVMPSIxMDAgV2F0ZXJzIEVkZ2VuQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzEwMCBXYXRlcnMgRWRnZTtCYXl0b3duO0xBOzMwMzE0O1VuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYQ0KQURSO1RZUEU9SE9NRTtMQUJFTD0iNDIgUGxhbnRhdGlvbiBTdC5uQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzQyIFBsYW50YXRpb24gU3QuO0JheXRvd247TEE7MzAzMTQ7VW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhDQpFTUFJTDpmb3JyZXN0Z3VtcEBleGFtcGxlLmNvbQ0KUkVWOjIwMDgwNDI0VDE5NTI0M1oNCngtcXE6MjE1ODg4OTENCkVORDpWQ0FSRA==
>
>
> A client MAY render it inline, for the user to interact with, in any appropriate ways:

Please, no. I'd be all for a client rendering text/vcard and similar
content types as pages, with whatever formatting the client author
likes, but they should be rendered as separate documents. If you want an
inline link preview, you can write it by hand, or have it generated by a
script. 

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From petite.abeille at gmail.com  Thu Jun  4 16:50:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 17:50:31 +0200
Subject: authorship tag
In-Reply-To: <1B783825-57AB-45D8-B603-BB67F504F88F@alexschroeder.ch>
References: <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>
 <1B783825-57AB-45D8-B603-BB67F504F88F@alexschroeder.ch>
Message-ID: <BD0A8EF9-F5E7-4085-AA17-80112AC388AD@gmail.com>



> On Jun 4, 2020, at 17:41, Alex Schroeder <alex at alexschroeder.ch> wrote:
> 
> #author:Alex_Schroeder #date:2020-06-05 #feeds #wiki #metadata #tagging #folksonomy #tags #ohmygodwhenwillitstop

Ah yes, a boatload of free floating hashes. Which are one space short of being rendered as text/gemini heading lines :D

But yes, in that spirit :)



From petite.abeille at gmail.com  Thu Jun  4 16:58:35 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 17:58:35 +0200
Subject: content-disposition vs data URI
In-Reply-To: <875zc6q1at.fsf@dorothy.carcosa.net>
References: <B8F21775-37EB-4A1C-B53B-FE81BA3B5F04@gmail.com>
 <875zc6q1at.fsf@dorothy.carcosa.net>
Message-ID: <3811EB39-83ED-45EA-954F-A9F31DD4F1CC@gmail.com>



> On Jun 4, 2020, at 17:48, Jason McBrayer <jmcbray at carcosa.net> wrote:
> 
> If you want an inline link preview, you can write it by hand, or have it generated by a script. 

On the server side, I presume?

What happened to the notion of client's agency?

5.3.2 Link lines Clients can present links to users in whatever fashion the client author wishes.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/7d68757a/attachment.htm>

From rak at rak.ac  Thu Jun  4 17:08:44 2020
From: rak at rak.ac (Ryan Kavanagh)
Date: Thu, 4 Jun 2020 12:08:44 -0400
Subject: Ambiguity in spec regarding line endings
Message-ID: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>

I'm reading the current version of the spec, and have come across the
following ambiguous paragraph in ?3.3:

    When in canonical form, media subtypes of the "text" type use CRLF
    as the text line break.  Gemini relaxes this requirement and allows
    the transport of text media with plain LF alone (but NOT a plain CR
    alone) representing a line break when it is done consistently for an
    entire response body.  Gemini clients MUST accept CRLF and bare LF
    as being representative of a line break in text media received via
    HTTP.

How do the second and third sentences interact? In particular, how does

    [...] when it is done consistently for an entire response body.

interact with

    Gemini clients MUST accept CRLF and bare LF as being representative
    of a line break in text media received via HTTP.

How should Gemini clients behave when both CRLF and LF appear in the
same text/gemini transmission? Are both to be equivalently treated as
line breaks?

I've looked through the archives to see what has been said in the past
about line breaks, and the two following messages appear most relevant:

On Sat, Sep 07, 2019 at 04:30:14PM -0400, Jason McBrayer wrote:
> IMO, it makes sense to require CRLF in the plain text parts of the
> protocol (after requests, after the status line of a response), but I
> don't think that the text/gemini file format needs to have CR/LF; IMO
> clients should be prepared to accept either LF or CR/LF just as they
> would with text/plain. And maybe if we're serious about supporting old
> devices, clients should be prepared for bare CR, too (Classic MacOS).
> But it's a pain in the arse to authors to have to save text documents
> with non-native line endings, and I don't feel like servers need to be
> in the business of reformatting the content they serve.

On Sun, Sep 08, 2019 at 02:42:08PM +0000, solderpunk wrote:
> I will admit that the current liberal use of CRLF throughout the
> Gemini spec is the result of me blindly copying from Gopher and other
> RFCs (as Sean mentioned, it's ubiquitous).

Here's [0,1] some of the history of requiring CRLF in network protocols
and in requiring CRLF for text/ subtypes [2] during transmission.

TL;DR: every system has a different native line ending sequence (LF vs
CR vs CRLF). To ensure all can communicate with each other (and to
simplify parsing of communications), transmissions are required to
represent all line endings in text formats by CRLF. Line endings used in
the local storage of text files have *nothing to do* with the line
endings used in transmission, and clients are expected to convert from
CRLF to whatever local format is preferred. So indeed, servers are in
the business of reformatting text/* content that they serve, and they do
so to ensure interoperability between systems with different line ending
conventions.

I think there's a conceptual point to be made here: text/gemini files
are not binary data, but rather, *text files*. This means that their
transmission should not attempt to provide byte-for-byte identical
copies of the local data, but should instead follow well-defined and
agreed-upon representations. If your goal is to transmit a byte-for-byte
identical copy of your file, there are other mime types you can use to
accomplish this (e.g., application/octet-stream).

The FTP protocol makes a similar conceptual distinction. It allows for
text transmission (ASCII and EBCDIC types), where end-of-lines are
defined to be CLRF (ASCII type) and NL (EBCDIC type). It also allows for
a stream / binary transfer mode for transmitting text (and other data)
without any conversion. Quoting from the RFC [4, ?3.4]:

    For the purpose of standardized transfer, the sending host will
    translate its internal end of line or end of record denotation into
    the representation prescribed by the transfer mode and file
    structure, and the receiving host will perform the inverse
    translation to its internal denotation.  [...]  Since these
    transformations imply extra work for some systems, identical systems
    transferring non-record structured text files might wish to use a
    binary representation and stream mode for the transfer.

However, in keeping with Postel's law, I suggest allowing clients to
accept LF as a line ending, as is done by RFC 7230 ?3.5 [3]:

     Although the line terminator for the start-line and header fields
     is the sequence CRLF, a recipient MAY recognize a single LF as a
     line terminator and ignore any preceding CR.

Conclusion:

To eliminate ambiguity and to make the gemini protocol consistent with
every other text transmission protocol I know of, I propose amending the
ambiguous paragraph in the spec as follows:

    As specified in RFC 2046 ?4.1.1, the canonical form of any MIME
    "text" subtype MUST always represent a line break as a CRLF
    sequence. For robustness, a recipient MAY recognize a single LF as
    a line terminator and ignore any preceding CR in text media.

Best,
Ryan

[0] https://www.rfc-editor.org/old/EOLstory.txt
[1] https://tools.ietf.org/html/rfc318
    [ page 8, "End of Line Convention" ]
[2] https://tools.ietf.org/html/rfc2046#section-4.1.1
[3] https://tools.ietf.org/html/rfc7230#section-3.5
[4] https://tools.ietf.org/html/rfc959

-- 
|)|/  Ryan Kavanagh      | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac     |      BD95 8F7B F8FC 4A11 C97A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1873 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/fbf5d0ed/attachment.sig>

From petite.abeille at gmail.com  Thu Jun  4 17:18:03 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 18:18:03 +0200
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
Message-ID: <F0476F55-36E0-4E61-BB6F-E7DBED726998@gmail.com>



> On Jun 4, 2020, at 18:08, Ryan Kavanagh <rak at rak.ac> wrote:
> 
>    As specified in RFC 2046 ?4.1.1, the canonical form of any MIME
>    "text" subtype MUST always represent a line break as a CRLF
>    sequence. For robustness, a recipient MAY recognize a single LF as
>    a line terminator and ignore any preceding CR in text media.

$ delcr | gemini | addcr

https://cr.yp.to/ucspi-tcp/addcr.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/4154c5b5/attachment.htm>

From prisonpotato at tilde.team  Thu Jun  4 17:23:26 2020
From: prisonpotato at tilde.team (prisonpotato at tilde.team)
Date: Thu, 4 Jun 2020 12:23:26 -0400
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
Message-ID: <20200604162326.GB25314@tilde.team>

I disagree with this idea, as it adds a signifigant burden to both
server implementations and client implementations running on unix
systems.

On Thu, Jun 04, 2020 at 12:08:44PM -0400, Ryan Kavanagh wrote:
> I'm reading the current version of the spec, and have come across the
> following ambiguous paragraph in ?3.3:
> 
>     When in canonical form, media subtypes of the "text" type use CRLF
>     as the text line break.  Gemini relaxes this requirement and allows
>     the transport of text media with plain LF alone (but NOT a plain CR
>     alone) representing a line break when it is done consistently for an
>     entire response body.  Gemini clients MUST accept CRLF and bare LF
>     as being representative of a line break in text media received via
>     HTTP.
> 
> How do the second and third sentences interact? In particular, how does
> 
>     [...] when it is done consistently for an entire response body.
> 
> interact with
> 
>     Gemini clients MUST accept CRLF and bare LF as being representative
>     of a line break in text media received via HTTP.
> 
> How should Gemini clients behave when both CRLF and LF appear in the
> same text/gemini transmission? Are both to be equivalently treated as
> line breaks?
> 
> I've looked through the archives to see what has been said in the past
> about line breaks, and the two following messages appear most relevant:
> 
> On Sat, Sep 07, 2019 at 04:30:14PM -0400, Jason McBrayer wrote:
> > IMO, it makes sense to require CRLF in the plain text parts of the
> > protocol (after requests, after the status line of a response), but I
> > don't think that the text/gemini file format needs to have CR/LF; IMO
> > clients should be prepared to accept either LF or CR/LF just as they
> > would with text/plain. And maybe if we're serious about supporting old
> > devices, clients should be prepared for bare CR, too (Classic MacOS).
> > But it's a pain in the arse to authors to have to save text documents
> > with non-native line endings, and I don't feel like servers need to be
> > in the business of reformatting the content they serve.
> 
> On Sun, Sep 08, 2019 at 02:42:08PM +0000, solderpunk wrote:
> > I will admit that the current liberal use of CRLF throughout the
> > Gemini spec is the result of me blindly copying from Gopher and other
> > RFCs (as Sean mentioned, it's ubiquitous).
> 
> Here's [0,1] some of the history of requiring CRLF in network protocols
> and in requiring CRLF for text/ subtypes [2] during transmission.
> 
> TL;DR: every system has a different native line ending sequence (LF vs
> CR vs CRLF). To ensure all can communicate with each other (and to
> simplify parsing of communications), transmissions are required to
> represent all line endings in text formats by CRLF. Line endings used in
> the local storage of text files have *nothing to do* with the line
> endings used in transmission, and clients are expected to convert from
> CRLF to whatever local format is preferred. So indeed, servers are in
> the business of reformatting text/* content that they serve, and they do
> so to ensure interoperability between systems with different line ending
> conventions.
> 
> I think there's a conceptual point to be made here: text/gemini files
> are not binary data, but rather, *text files*. This means that their
> transmission should not attempt to provide byte-for-byte identical
> copies of the local data, but should instead follow well-defined and
> agreed-upon representations. If your goal is to transmit a byte-for-byte
> identical copy of your file, there are other mime types you can use to
> accomplish this (e.g., application/octet-stream).
> 
> The FTP protocol makes a similar conceptual distinction. It allows for
> text transmission (ASCII and EBCDIC types), where end-of-lines are
> defined to be CLRF (ASCII type) and NL (EBCDIC type). It also allows for
> a stream / binary transfer mode for transmitting text (and other data)
> without any conversion. Quoting from the RFC [4, ?3.4]:
> 
>     For the purpose of standardized transfer, the sending host will
>     translate its internal end of line or end of record denotation into
>     the representation prescribed by the transfer mode and file
>     structure, and the receiving host will perform the inverse
>     translation to its internal denotation.  [...]  Since these
>     transformations imply extra work for some systems, identical systems
>     transferring non-record structured text files might wish to use a
>     binary representation and stream mode for the transfer.
> 
> However, in keeping with Postel's law, I suggest allowing clients to
> accept LF as a line ending, as is done by RFC 7230 ?3.5 [3]:
> 
>      Although the line terminator for the start-line and header fields
>      is the sequence CRLF, a recipient MAY recognize a single LF as a
>      line terminator and ignore any preceding CR.
> 
> Conclusion:
> 
> To eliminate ambiguity and to make the gemini protocol consistent with
> every other text transmission protocol I know of, I propose amending the
> ambiguous paragraph in the spec as follows:
> 
>     As specified in RFC 2046 ?4.1.1, the canonical form of any MIME
>     "text" subtype MUST always represent a line break as a CRLF
>     sequence. For robustness, a recipient MAY recognize a single LF as
>     a line terminator and ignore any preceding CR in text media.
> 
> Best,
> Ryan
> 
> [0] https://www.rfc-editor.org/old/EOLstory.txt
> [1] https://tools.ietf.org/html/rfc318
>     [ page 8, "End of Line Convention" ]
> [2] https://tools.ietf.org/html/rfc2046#section-4.1.1
> [3] https://tools.ietf.org/html/rfc7230#section-3.5
> [4] https://tools.ietf.org/html/rfc959
> 
> -- 
> |)|/  Ryan Kavanagh      | GPG: 4E46 9519 ED67 7734 268F
> |\|\  https://rak.ac     |      BD95 8F7B F8FC 4A11 C97A



From tomasino at lavabit.com  Thu Jun  4 17:23:31 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 4 Jun 2020 16:23:31 +0000
Subject: SPOOFED: Re: authorship tag
In-Reply-To: <1B783825-57AB-45D8-B603-BB67F504F88F@alexschroeder.ch>
References: <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>
 <1B783825-57AB-45D8-B603-BB67F504F88F@alexschroeder.ch>
Message-ID: <51f5666f-208c-1e75-7411-c18774c25620@lavabit.com>

On 6/4/20 3:41 PM, Alex Schroeder wrote:
> I?m reminded of the Wiki Mode for RSS?

Alex, are you planning on using client certificates to give yourself
some sort of write access to your wiki on gemini? I know you wrangled up
a "w" item type on gopher so I'm wondering if you could hack something
together in that way and still keep auth locked down.

I was trying to think of useful things to do with the certs and wikis
seem to keep coming up. I'm not sure exactly how editable that would
make them, but I figure you must have done a lot of this thinking
already to get it working on gopher.


From tomasino at lavabit.com  Thu Jun  4 17:31:08 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 4 Jun 2020 16:31:08 +0000
Subject: content-disposition vs data URI
In-Reply-To: <3811EB39-83ED-45EA-954F-A9F31DD4F1CC@gmail.com>
References: <B8F21775-37EB-4A1C-B53B-FE81BA3B5F04@gmail.com>
 <875zc6q1at.fsf@dorothy.carcosa.net>
 <3811EB39-83ED-45EA-954F-A9F31DD4F1CC@gmail.com>
Message-ID: <267f3c86-7ed0-7a79-6018-8a3d842b699e@lavabit.com>

On 6/4/20 3:58 PM, Petite Abeille wrote:
> On the server side, I presume?
> 
> What happened to the notion of client's agency?
> 
> 5.3.2 Link lines/Clients can present links to users in whatever fashion
> the client author wishes./

The clients can present _links_ to users in whatever fashion. They
should still be links. If a URL pattern allows for the encoding of
random material, that should not be license to inline content. The goals
of the project are clear philosophically that text/gemini represents a
single document format that can hyperlink. Pulling in data in the ways
you are describing is no different from the earlier suggestion of a <=
line or frames.

If your client wants to display images inline in the document AFTER a
user clicks on a link, that would be within the purview of a client
author. A client should not choose to inline images automatically,
though, as they would no longer be links.

I think this idea, not the specific technical parts, but the theory and
philosophy, should answer all of the ideas you've been presenting
regarding URL hackery collectively in the negative.


From petite.abeille at gmail.com  Thu Jun  4 17:46:34 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 18:46:34 +0200
Subject: content-disposition vs data URI
In-Reply-To: <267f3c86-7ed0-7a79-6018-8a3d842b699e@lavabit.com>
References: <B8F21775-37EB-4A1C-B53B-FE81BA3B5F04@gmail.com>
 <875zc6q1at.fsf@dorothy.carcosa.net>
 <3811EB39-83ED-45EA-954F-A9F31DD4F1CC@gmail.com>
 <267f3c86-7ed0-7a79-6018-8a3d842b699e@lavabit.com>
Message-ID: <D7794AF4-1847-42AB-B8BB-1AA0E71B3693@gmail.com>



> On Jun 4, 2020, at 18:31, James Tomasino <tomasino at lavabit.com> wrote:
> 
> I think this idea, not the specific technical parts, but the theory and
> philosophy, should answer all of the ideas you've been presenting
> regarding URL hackery collectively in the negative.

Fair enough.

So, to summarize, standard URL hackery: big no-no, on philosophical grounds.

But hacking your heart content by overloading the link description or otherwise randomly spraying text/gemini with obscure hieroglyphs? Ohhhhhh YES!  ??

I foretell a schism ??

"When you come to a fork in the road, take it."
-- Yogi Berra, allegedly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/0c491fc6/attachment.htm>

From rak at rak.ac  Thu Jun  4 17:56:51 2020
From: rak at rak.ac (Ryan Kavanagh)
Date: Thu, 4 Jun 2020 12:56:51 -0400
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604162326.GB25314@tilde.team>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
 <20200604162326.GB25314@tilde.team>
Message-ID: <20200604165651.3xqhphozlupx4ssr@zeta.rak.ac>

Hi,

On Thu, Jun 04, 2020 at 12:23:26PM -0400, prisonpotato at tilde.team wrote:
> I disagree with this idea, as it adds a signifigant burden to both
> server implementations and client implementations running on unix
> systems.

The proposed modification *reduces* the burden for clients on all
systems. Indeed, clients are currently required to accept *both* CRLF
and bare LF as being representative of a line break. The proposed change
requires them only to accept CRLF, while giving them the option to also
accept LF if they so desire. This means: clients satisfying the spec now
will satisfy the spec after the change.

You are correct in that it increases the burden for servers (regardless
of the host system): they must convert bare LF endings to CRLF before
transmitting text. Whether or not this change imposes a "significant"
burden is subjective. For what it's worth, the gopher protocol specifies
CRLF line endings, and gophernicus manages to do this conversion with ~5
lines of code [0, 1].

The question boils down to a cost-benefit analysis of:

    preserving spec compliance for existing servers and not having
    servers worry about line endings

versus

    respecting network protocol conventions that have been established
    for decades and not violating a MUST requirement of RFC 2046 ?4.1.1

Best,
Ryan

[0] https://github.com/gophernicus/gophernicus/blob/master/src/file.c#L68
[1] https://github.com/gophernicus/gophernicus/blob/master/src/string.c#L122

-- 
|)|/  Ryan Kavanagh      | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac     |      BD95 8F7B F8FC 4A11 C97A

From luke.emmet at gmail.com  Thu Jun  4 18:34:49 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 04 Jun 2020 18:34:49 +0100
Subject: [ANN] New server: gemini://gemini.marmaladefoo.com/
Message-ID: <5ED930B9.5020707@gmail.com>

Hi Solderpunk and all

I'm pleased to announce I've just set up a new server:

gemini://gemini.marmaladefoo.com/

I'll be posting items about GemiNaut development, thoughts on gemini and 
will make some experiments in app development in Gemini. You can also 
find out about my other secret life as a lute maker.

Solderpunk - if there is still a space on the hand-curated list of 
servers, can I go on it?

Best Wishes

  - Luke

From prisonpotato at tilde.team  Thu Jun  4 18:46:14 2020
From: prisonpotato at tilde.team (prisonpotato at tilde.team)
Date: Thu, 4 Jun 2020 13:46:14 -0400
Subject: [ANN] New server: gemini://gemini.marmaladefoo.com/
In-Reply-To: <5ED930B9.5020707@gmail.com>
References: <5ED930B9.5020707@gmail.com>
Message-ID: <20200604174614.GA10535@tilde.team>

I wish there was somthing like geminaut for linux

On Thu, Jun 04, 2020 at 06:34:49PM +0100, Luke Emmet wrote:
> Hi Solderpunk and all
> 
> I'm pleased to announce I've just set up a new server:
> 
> gemini://gemini.marmaladefoo.com/
> 
> I'll be posting items about GemiNaut development, thoughts on gemini and
> will make some experiments in app development in Gemini. You can also find
> out about my other secret life as a lute maker.
> 
> Solderpunk - if there is still a space on the hand-curated list of servers,
> can I go on it?
> 
> Best Wishes
> 
>  - Luke

From colecmac at protonmail.com  Thu Jun  4 18:50:50 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 04 Jun 2020 17:50:50 +0000
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604165651.3xqhphozlupx4ssr@zeta.rak.ac>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
 <20200604162326.GB25314@tilde.team>
 <20200604165651.3xqhphozlupx4ssr@zeta.rak.ac>
Message-ID: <3eNSLzu4a-6v9Xl1Cf3M0j-mcXTf6Dv1RlE6RVXsNqoYa1dqgete9xV7_uf5LL4pyf7_yJmqOBsRX0026TBtSK7FQ4IsJL7PbUCoHo2iv48=@protonmail.com>

> The proposed change requires them only to accept CRLF


This is a problem I think, because any clients that do this will
fail to properly display the vast majority on Gemini content. I don't
see the problem with mandating handling LF as well. Just split lines on
LF and you're done for both types.

makeworld

From prisonpotato at tilde.team  Thu Jun  4 18:54:50 2020
From: prisonpotato at tilde.team (prisonpotato at tilde.team)
Date: Thu, 4 Jun 2020 13:54:50 -0400 (EDT)
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <3eNSLzu4a-6v9Xl1Cf3M0j-mcXTf6Dv1RlE6RVXsNqoYa1dqgete9xV7_uf5LL4pyf7_yJmqOBsRX0026TBtSK7FQ4IsJL7PbUCoHo2iv48=@protonmail.com>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
 <20200604162326.GB25314@tilde.team>
 <20200604165651.3xqhphozlupx4ssr@zeta.rak.ac>
 <3eNSLzu4a-6v9Xl1Cf3M0j-mcXTf6Dv1RlE6RVXsNqoYa1dqgete9xV7_uf5LL4pyf7_yJmqOBsRX0026TBtSK7FQ4IsJL7PbUCoHo2iv48=@protonmail.com>
Message-ID: <alpine.DEB.2.21.2006041354200.17582@tilde.team>


I agree.  This seems like a more sensible solution


From acdw at acdw.net  Thu Jun  4 20:00:47 2020
From: acdw at acdw.net (Case Duckworth)
Date: Thu, 04 Jun 2020 14:00:47 -0500
Subject: content-disposition vs data URI
In-Reply-To: <875zc6q1at.fsf@dorothy.carcosa.net>
References: <B8F21775-37EB-4A1C-B53B-FE81BA3B5F04@gmail.com>
 <875zc6q1at.fsf@dorothy.carcosa.net>
Message-ID: <8651e206-5b30-46d9-ba16-eb7d76d1f421@www.fastmail.com>


In the Vcard example, I don't see why you couldn't put the Vcard between code fences. Optionally with an alt text starting it's a Vcard, if the client wants to get fancy. Otherwise, you could just copy and paste it.. it's a text format, after all. 

Which makes me think: there's two kinds of things these 'data:' URIs (which I am against, tho not on a protocol level; I just don't think any client will bother with them): text and binary-encoded-as-text. For the text, just fence it if you really want it inline. For binary, just link them. Surely encoding a binary file as text takes up more space than it does in disk! If a client really wants to display it inline, they can do another request and go totally off spec. If they just have to. 

On Thu, Jun 4, 2020, at 10:48 AM, Jason McBrayer wrote:
> Petite Abeille <petite.abeille at gmail.com> writes:
> 
> > Additionally, perhaps text/gemini could embraces data url as small inline adornment.
> >
> > For example, given a small data encoded vCard, 917 bytes long:
> >
> > data:text/vcard;charset=utf-8;base64,QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOkd1bXA7Rm9ycmVzdDs7TXIuOw0KRk46Rm9ycmVzdCBHdW1wDQpPUkc6QnViYmEgR3VtcCBTaHJpbXAgQ28uDQpUSVRMRTpTaHJpbXAgTWFuDQpQSE9UTztNRURJQVRZUEU9aW1hZ2UvZ2lmOmh0dHA6Ly93d3cuZXhhbXBsZS5jb20vZGlyX3Bob3Rvcy9teV9waG90by5naWYNClRFTDtUWVBFPXdvcmssdm9pY2U7VkFMVUU9dXJpOnRlbDorMS0xMTEtNTU1LTEyMTINClRFTDtUWVBFPWhvbWUsdm9pY2U7VkFMVUU9dXJpOnRlbDorMS00MDQtNTU1LTEyMTINCkFEUjtUWVBFPVdPUks7UFJFRj0xO0xBQkVMPSIxMDAgV2F0ZXJzIEVkZ2VuQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzEwMCBXYXRlcnMgRWRnZTtCYXl0b3duO0xBOzMwMzE0O1VuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYQ0KQURSO1RZUEU9SE9NRTtMQUJFTD0iNDIgUGxhbnRhdGlvbiBTdC5uQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzQyIFBsYW50YXRpb24gU3QuO0JheXRvd247TEE7MzAzMTQ7VW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhDQpFTUFJTDpmb3JyZXN0Z3VtcEBleGFtcGxlLmNvbQ0KUkVWOjIwMDgwNDI0VDE5NTI0M1oNCngtcXE6MjE1ODg4OTENCkVORDpWQ0FSRA==
> >
> >
> > A client MAY render it inline, for the user to interact with, in any appropriate ways:
> 
> Please, no. I'd be all for a client rendering text/vcard and similar
> content types as pages, with whatever formatting the client author
> likes, but they should be rendered as separate documents. If you want an
> inline link preview, you can write it by hand, or have it generated by a
> script. 
> 
> -- 
> +-----------------------------------------------------------+  
> | Jason F. McBrayer                    jmcbray at carcosa.net  |  
> | If someone conquers a thousand times a thousand others in |  
> | battle, and someone else conquers himself, the latter one |  
> | is the greatest of all conquerors.  --- The Dhammapada    |  
>

From alex at alexschroeder.ch  Thu Jun  4 21:23:49 2020
From: alex at alexschroeder.ch (Alex Schroeder)
Date: Thu, 4 Jun 2020 22:23:49 +0200
Subject: SPOOFED: Re: authorship tag
In-Reply-To: <51f5666f-208c-1e75-7411-c18774c25620@lavabit.com>
References: <51f5666f-208c-1e75-7411-c18774c25620@lavabit.com>
Message-ID: <BE39BD3A-2BF1-49D0-A793-6739339AF675@alexschroeder.ch>

Regarding wikis: yes! But I don?t want to know whether the first and the second edit was made by the same person, and I don?t want to issue any client certificates to users, so they seem to be the wrong tool for me. I?m thinking auth. tokens, or passwords without usernames if you will. On my wiki, that would be the security question I ask first time editors (and often my questions are simply ?please say hello?).

More info here:

https://alexschroeder.ch/wiki/2020-06-04_Gemini_Upload
=> gemini://alexschroeder.ch/2020-06-04_Gemini_Upload Gemini Upload

Cheers
Alex
-- 
Please encrypt your email, if you can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/a53f7d53/attachment.htm>

From rak at rak.ac  Thu Jun  4 21:30:46 2020
From: rak at rak.ac (Ryan Kavanagh)
Date: Thu, 4 Jun 2020 16:30:46 -0400
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <3eNSLzu4a-6v9Xl1Cf3M0j-mcXTf6Dv1RlE6RVXsNqoYa1dqgete9xV7_uf5LL4pyf7_yJmqOBsRX0026TBtSK7FQ4IsJL7PbUCoHo2iv48=@protonmail.com>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
 <20200604162326.GB25314@tilde.team>
 <20200604165651.3xqhphozlupx4ssr@zeta.rak.ac>
 <3eNSLzu4a-6v9Xl1Cf3M0j-mcXTf6Dv1RlE6RVXsNqoYa1dqgete9xV7_uf5LL4pyf7_yJmqOBsRX0026TBtSK7FQ4IsJL7PbUCoHo2iv48=@protonmail.com>
Message-ID: <20200604203046.bmnryczvvaa47xys@zeta.rak.ac>

After some thought and discussion, I'd like to retract my proposed
amendment. I misinterpreted that paragraph of the spec as implying
something that it isn't.

Best,
Ryan

-- 
|)|/  Ryan Kavanagh      | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac     |      BD95 8F7B F8FC 4A11 C97A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1873 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/c2657e75/attachment.sig>

From luke.emmet at gmail.com  Thu Jun  4 21:57:17 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 04 Jun 2020 21:57:17 +0100
Subject: Lightweight Unicode Author Client Hinting - LUACH proposal
In-Reply-To: <20200604153754.GA25314@tilde.team>
References: <5ED8D96D.70706@gmail.com> <20200604153754.GA25314@tilde.team>
Message-ID: <5ED9602D.6000806@gmail.com>

Ok - fair enough - I like the favicon proposal too. But the favicon.txt 
proposal means is to choose a single unicode character that is you. 
Might not work for everyone.

The difference between menu and home would be:

? menu is a link to a page containing a *list of links*, which are then presented to assist navigation. In fact there could be more than one menu on a page. It could be presented as an interactive list, or as an embedded list or table.

? home is the singular home page url. Probably what you should get if you click the logo.

Probably an author might just choose one for a specific page. Home url is the simplest, menu more sophisticated. We could say that the home page could be inferred from an item in the menu. I think either is fine.

  - Luke

On 04-Jun-2020 16:37, prisonpotato at tilde.team wrote:
> I like this idea, with a few exceptions.
> For the logo (?) proposal, I like the favicon.txt proposal as a better,
> terminal compliant way to solve this problem.
> I'm also not sure how the Menu (? ) is different from Home (?).


From natpen at natpen.net  Thu Jun  4 22:20:00 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Thu, 4 Jun 2020 17:20:00 -0400
Subject: Three month spec freeze
In-Reply-To: <20200603163223.GW23998@brevard.conman.org>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <20200603005351.GO23998@brevard.conman.org>
 <20200603124122.GE246841@goldfish.localdomain>
 <20200603163223.GW23998@brevard.conman.org>
Message-ID: <20200604212000.GC321367@goldfish.localdomain>

On Wed, Jun 03, 2020 at 12:32:23PM -0400, Sean Conner wrote:
>   Since the following query isn't supported, could you check to see how many
> text/gemini documents have a charset?  And if they do, what charset they
> use?

For all content types:

 5529 - none
  110 - utf-8
   38 - us-ascii
    2 - US-ASCII
    1 - UTF-8

For text/gemini specifically:

 3256 - none
   14 - utf-8
    2 - US-ASCII
    1 - UTF-8

And now, in case you want to explore these data more on your own...
please be patient in case there are new bugs, but `charset` is now a
supported query filter in your own GUS searches. Consider it an early
access "beta" feature, because I still need to put more thought and
work into tokenization and indexing of the charset values. Feel free
to try it out though!

I'll also keep the aggregate counts on the statistics page [2] going
forward for easy reference.

[2] gemini://gus.guru/statistics

From sean at conman.org  Thu Jun  4 22:26:16 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 4 Jun 2020 17:26:16 -0400
Subject: authorship tag
In-Reply-To: <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>
References: <6EB3ACFC-EC4F-4B86-9818-4DC6D92DE0D0@gmail.com>
 <20200604072438.GA70547@allanon.local>
 <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>
Message-ID: <20200604212616.GZ23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> For one, as both an author & a reader, I like to have text anchored in
> time. Nothing happen in a vacuum.
> 
> gemini and text/gemini have no notion of time at all.
> 
> Instead people tend to compensate by haphazardly leaving contextual
> breadcrumbs here and there about such basic information:
> 
> ? gemini://gemini.conman.org/gRFC/
> => 0001 0001 2019-08-01 PROPOSED MIME type and parameters for Gemini Index Files
> => 0002 0002 2019-08-01 ACCEPTED Resource request format for Gemini
> => 0003 0003 2019-08-01 PROPOSED Response header to include optional file size in reply
> => 0004 0004 2019-09-06 PROPOSED Gemini index format

  If you check those links, you'll see I already include such metadata in
the document itself, not just on the link line.  So the above links are not
a good example for you here.

> The authorship tag gives a simple and consistent way to embed such date in
> the text/gemini document itself.

  In a machine readable way.  And the "authorship" is not authorship per se,
but the authority.  The tag: URI includes either a domain *or* an email
address.  It's meant to be used for identification of a resource, not
authorship of a document.

> Furthermore, the tag provides, well,  authorship information: who did it?
> 
> E.g. gemini.circumlunar.space/~solderpunk points to solderpunk actual home
> at circumlunar.
> 
> This could be used creatively, by, say, uniquely styling ~solderpunk
> documents with sigil, color scheme, whatnot:
> 
> ? gemini.circumlunar.space/~solderpunk ? f01c0885 ? 4028369029 ? ~lapryt-fidseg ? sigil
> 
> This provides a more stable and granular alternative to the host IP
> address or certificate.
> 
> Finally, the tag itself is rather readable on its own:
> 
> tag:gemini.conman.org <http://gemini.conman.org/>,2019-08-01:gRFC/0002 <gemini://gemini.conman.org/gRFC/0002>#20:46:12

  It would help your case if you generated valid tag: URIs, like:

	tag:gemini.conman.org,2019-08-01:gRFC0001:PROPOSED:Sean%20Conner

But that's not easy for humans to parse (they can) because of the encoding
and the lack of actual whitespace.

  -spc

From petite.abeille at gmail.com  Thu Jun  4 22:46:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 4 Jun 2020 23:46:05 +0200
Subject: authorship tag
In-Reply-To: <20200604212616.GZ23998@brevard.conman.org>
References: <6EB3ACFC-EC4F-4B86-9818-4DC6D92DE0D0@gmail.com>
 <20200604072438.GA70547@allanon.local>
 <92142D0F-88BB-4824-A976-ED109B4A2BCD@gmail.com>
 <20200604212616.GZ23998@brevard.conman.org>
Message-ID: <2F3FED56-6357-407A-98CE-2E7EE6600B0F@gmail.com>



> On Jun 4, 2020, at 23:26, Sean Conner <sean at conman.org> wrote:
> 
> It's meant to be used for identification of a resource, not
> authorship of a document.

The heavy burden of literalism.


From sean at conman.org  Thu Jun  4 22:53:14 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 4 Jun 2020 17:53:14 -0400
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604162326.GB25314@tilde.team>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
 <20200604162326.GB25314@tilde.team>
Message-ID: <20200604215314.GA23998@brevard.conman.org>

It was thus said that the Great prisonpotato at tilde.team once stated:
> I disagree with this idea, as it adds a signifigant burden to both
> server implementations and client implementations running on unix
> systems.

  And I disagree with this disagreement.  Requiring only LF produces an
undue hardship on Windows systems which use both CR and LF.  And Windows is
*still* the most popular operating system out there.

  -spc (I can't believe I'm defending Windows here ... )


From sean at conman.org  Thu Jun  4 23:02:15 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 4 Jun 2020 18:02:15 -0400
Subject: Three month spec freeze
In-Reply-To: <20200604212000.GC321367@goldfish.localdomain>
References: <20200301170659.GB7582@SDF.ORG> <20200602192658.GB11961@SDF.ORG>
 <A58F7421-8218-4E1D-85B3-FA771006245A@gmail.com>
 <lzv9k9npzo.fsf@bs-mbpr348.d.ethz.ch>
 <ad27c22b-82b1-2b82-f7b5-c3581eb2d72e@lavabit.com>
 <20200603005351.GO23998@brevard.conman.org>
 <20200603124122.GE246841@goldfish.localdomain>
 <20200603163223.GW23998@brevard.conman.org>
 <20200604212000.GC321367@goldfish.localdomain>
Message-ID: <20200604220215.GB23998@brevard.conman.org>

It was thus said that the Great Natalie Pendragon once stated:
> On Wed, Jun 03, 2020 at 12:32:23PM -0400, Sean Conner wrote:
> >   Since the following query isn't supported, could you check to see how many
> > text/gemini documents have a charset?  And if they do, what charset they
> > use?

  First off, thank you for this.  

> For all content types:
> 
>  5529 - none
>   110 - utf-8
>    38 - us-ascii
>     2 - US-ASCII
>     1 - UTF-8

  Hmm ... because I know of *one* page that is text/gemini and is *not*
UTF-8 encoded:

	gemini://gemini.conman.org/test/torture/0013

  I'm guessing you don't crawl the Gemini Client Torture Test then?

> For text/gemini specifically:
> 
>  3256 - none
>    14 - utf-8
>     2 - US-ASCII
>     1 - UTF-8

  What this tells me is that the fears of non-UTF-8 text/gemini pages are
probably unfouned.  For now.  

  I'd recommend keeping the charset on text/gemini.  For the exceeding rare
case of a non-UTF-8 text/gemini page, a very simplistic client that doesn't
want to convert the text can just report an error to the user, or at least
offer an option to display and/or save the content.

  -spc


From sean at conman.org  Thu Jun  4 23:19:14 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 4 Jun 2020 18:19:14 -0400
Subject: SPOOFED: Re: authorship tag
In-Reply-To: <BE39BD3A-2BF1-49D0-A793-6739339AF675@alexschroeder.ch>
References: <51f5666f-208c-1e75-7411-c18774c25620@lavabit.com>
 <BE39BD3A-2BF1-49D0-A793-6739339AF675@alexschroeder.ch>
Message-ID: <20200604221914.GC23998@brevard.conman.org>

It was thus said that the Great Alex Schroeder once stated:
> Regarding wikis: yes! But I don?t want to know whether the first and the
> second edit was made by the same person, and I don?t want to issue any
> client certificates to users, so they seem to be the wrong tool for me.
> I?m thinking auth. tokens, or passwords without usernames if you will. On
> my wiki, that would be the security question I ask first time editors (and
> often my questions are simply ?please say hello?).

  I was wondering if you might do this.

> More info here:
> 
> https://alexschroeder.ch/wiki/2020-06-04_Gemini_Upload
> => gemini://alexschroeder.ch/2020-06-04_Gemini_Upload Gemini Upload

  Thankfully, you used a new URL scheme for this, thus keeping this squarely
out of the Gemini protocol itself.  And the proposal make sense to me.  As
to the open questions you have, unless you think you would be using the
query portion of the URL for something else, why not indicate meta
information there?

	gemini+write://alexschroeder.ch/Test?size=5612&mime=text/markdown&authtoken=foo

  Or even better (as it too, is part of the spec)---use the ';' to desginate
the information on the last part of the path (the ';' is classified as a
sub-delimeter and in the earlier URL RFCs was specifically called out as
such for the path portion):

	gemini+write://alexschroeder.ch/Test;size=5612;mime=text/markdown;authtoken=foo

  That way, you still have the query portion for other uses.

  -spc


From sean at conman.org  Thu Jun  4 23:24:04 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 4 Jun 2020 18:24:04 -0400
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
Message-ID: <20200604222404.GD23998@brevard.conman.org>

It was thus said that the Great Ryan Kavanagh once stated:
> 
> Here's [0,1] some of the history of requiring CRLF in network protocols
> and in requiring CRLF for text/ subtypes [2] during transmission.
> 
> [0] https://www.rfc-editor.org/old/EOLstory.txt
> [1] https://tools.ietf.org/html/rfc318
>     [ page 8, "End of Line Convention" ]

  Thank you for this.  I'm saving the references for future discussions on
this topic.

  -spc


From hello at matthewgraybosch.com  Thu Jun  4 23:21:42 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 4 Jun 2020 18:21:42 -0400
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604215314.GA23998@brevard.conman.org>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
 <20200604162326.GB25314@tilde.team>
 <20200604215314.GA23998@brevard.conman.org>
Message-ID: <20200604182142.2fb2d5d7993bc6105f5154f6@matthewgraybosch.com>

On Thu, 4 Jun 2020 17:53:14 -0400
Sean Conner <sean at conman.org> wrote:

> And I disagree with this disagreement.  Requiring only LF produces
> an undue hardship on Windows systems which use both CR and LF.  And
> Windows is *still* the most popular operating system out there.

What if somebody decides to write a Gemini client for FreeDOS? IIRC,
that OS still uses CR and LF for line endings, just like MS-DOS did.
Wouldn't a LF-only requirement hamper such an effort?

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
All opinions are my own.    Harrisburg, PA USA

"Out of order?! Even in the future nothing works!"

From hello at matthewgraybosch.com  Fri Jun  5 00:41:53 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 4 Jun 2020 19:41:53 -0400
Subject: Packaging Gemini Software for Slackware
Message-ID: <20200604194153.3397f26e836c9db272168db6@matthewgraybosch.com>

Hi, everybody. I was reluctant to use the [ANN] tag in the subject
because I don't have a new Gemini server to announce *yet*, but I
wanted to let everybody know that I've started packaging some Gemini
software for Slackware as Slackbuilds.

I currently have Slackbuilds for the following clients available on my
website, and I've also submitted them to slackbuilds.org. 

- bollux
- castor

Once they've been approved, Slackware users will be able to install by
hand or using tools like sbopkg or slpkg.

Tomorrow I'll take a stab at creating Slackbuilds for some of the
server software, starting with gemserve.

PS: The release tarballs will need to be renamed after downloading them
from Sourcehut because their filenames are "${VERSION}.tar.gz" rather
than "${NAME}-${VERSION}.tar.gz". I don't know if tooks like sbopkg
account for this or if I'll have to email Drew DeVault and report this
as a bug. :)

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
All opinions are my own.    Harrisburg, PA USA

"Out of order?! Even in the future nothing works!"

From sebastian1231alejandro at gmail.com  Fri Jun  5 03:09:44 2020
From: sebastian1231alejandro at gmail.com (Sebastian Alejandro)
Date: Thu, 04 Jun 2020 22:09:44 -0400
Subject: [ANN] New Gemini space - salejandro.me
Message-ID: <C38SX2UUA6VH.1MDW4H3QK0K8E@helios>

Hello, all!

I'm proud to announce my server:

gemini://salejandro.me

I've had it up for a while, but have yet to announce it... until now!
I've got a *log on there, where I'll be talking about a wide
variety of things.

I'll see you all around!

-kayw

From peteyboy at sdf.org  Fri Jun  5 06:43:26 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Thu, 04 Jun 2020 22:43:26 -0700
Subject: SPOOFED: Re: authorship tag
In-Reply-To: <mailman.69.1591307597.529.gemini@lists.orbitalfox.eu>
References: <mailman.69.1591307597.529.gemini@lists.orbitalfox.eu>
Message-ID: <AE84A8B9-C42A-43E5-8C5C-4F52B1537C32@sdf.org>

Holy sh*! You're wiki Alex Schroeder? As in Oddmuse?  I just put this together. Pleased to meet you!
I ran oddmuse for quite some time...

(How about we make a wiki:// scheme?)


>Message: 1
>Date: Thu, 4 Jun 2020 22:23:49 +0200
>From: Alex Schroeder <alex at alexschroeder.ch>
>To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>Subject: Re: SPOOFED: Re: authorship tag
>Message-ID: <BE39BD3A-2BF1-49D0-A793-6739339AF675 at alexschroeder.ch>
>Content-Type: text/plain; charset="utf-8"
>
>Regarding wikis: yes! But I don?t want to know whether the first and
>the second edit was made by the same person, and I don?t want to issue
>any client certificates to users, so they seem to be the wrong tool for
>me. 


-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From defdefred at protonmail.com  Fri Jun  5 09:00:04 2020
From: defdefred at protonmail.com (defdefred)
Date: Fri, 05 Jun 2020 08:00:04 +0000
Subject: Ambiguity in spec regarding line endings
In-Reply-To: <20200604182142.2fb2d5d7993bc6105f5154f6@matthewgraybosch.com>
References: <20200604160844.rohbntqqlvssgytj@zeta.rak.ac>
 <20200604162326.GB25314@tilde.team>
 <20200604215314.GA23998@brevard.conman.org>
 <20200604182142.2fb2d5d7993bc6105f5154f6@matthewgraybosch.com>
Message-ID: <Ys8QkCKbrS4ujT1puLUEKVyLnWkFwXDDUsnAwiwC-REt_d7P2vXvCnSxXpVhngG4dPNUeCP4r4gWp7gHUJ70IFXSsqK7tIKjzBDRSbj-Wac=@protonmail.com>

Isn't it only a text editor issue?

Wordpad is working for unix like text file...


Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Friday 5 June 2020 00:21, Matthew Graybosch <hello at matthewgraybosch.com> wrote:

> On Thu, 4 Jun 2020 17:53:14 -0400
> Sean Conner sean at conman.org wrote:
>
> > And I disagree with this disagreement. Requiring only LF produces
> > an undue hardship on Windows systems which use both CR and LF. And
> > Windows is still the most popular operating system out there.
>
> What if somebody decides to write a Gemini client for FreeDOS? IIRC,
> that OS still uses CR and LF for line endings, just like MS-DOS did.
> Wouldn't a LF-only requirement hamper such an effort?
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Matthew Graybosch https://www.matthewgraybosch.com
> All opinions are my own. Harrisburg, PA USA
>
> "Out of order?! Even in the future nothing works!"



From fkfd at macaw.me  Fri Jun  5 14:17:59 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Fri, 05 Jun 2020 21:17:59 +0800
Subject: [ANN] New site at fkfd.me and an outsider's guide to gemini spec
Message-ID: <C3974Q7DUDRM.299OVK2E17BNS@fakefred>

Real excited to announce my new gemini site which I set up last week but
only had the chance recently to write an article for:

=> gemini://fkfd.me/
=> gemini://fkfd.me/~fkfd/gemini_tldr.gmi Gemini spec TL;DR
=> https://blog.fkfd.me/gemini_tldr/ the same article, on HTTP
=> gemini://fkfd.me/~fkfd/gemini_tldr.md Source file 

It's a ~1k-word-long simplified guide to the gemini spec for outsiders.
I'm not a TCP and TLS pro; would love to hear some corrections and
feedback. Since the article is released in the public domain, you can
also just make a copy of your own.

Thank you for all of this,
~fkfd

From luke at marmaladefoo.com  Fri Jun  5 16:48:24 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 05 Jun 2020 16:48:24 +0100
Subject: First Gemini CGI application in Rebol
Message-ID: <5EDA6948.403@marmaladefoo.com>

Hi everyone

I just uploaded my first CGI server application for Gemini. A simple 
hello world application as a proof of concept.

It was fairly straightforward. Here is a blog post and link to the 
application

=> gemini://gemini.marmaladefoo.com/blog/5-Jun-2020_first_CGI.gmi
=> gemini://gemini.marmaladefoo.com/cgi-bin/hello-world.cgi

I think this might be the first Gemini server script in Rebol

=> https://rebolsource.net/

Best Wishes

  - Luke



From sean at conman.org  Fri Jun  5 21:36:12 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 5 Jun 2020 16:36:12 -0400
Subject: First Gemini CGI application in Rebol
In-Reply-To: <5EDA6948.403@marmaladefoo.com>
References: <5EDA6948.403@marmaladefoo.com>
Message-ID: <20200605203612.GI23998@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
> Hi everyone
> 
> I just uploaded my first CGI server application for Gemini. A simple 
> hello world application as a proof of concept.
> 
> It was fairly straightforward. Here is a blog post and link to the 
> application
> 
> => gemini://gemini.marmaladefoo.com/blog/5-Jun-2020_first_CGI.gmi
> => gemini://gemini.marmaladefoo.com/cgi-bin/hello-world.cgi
> 
> I think this might be the first Gemini server script in Rebol
> 
> => https://rebolsource.net/

  Cool.  One comment though---I think you're using an older version of Molly
Brown, as your patch 

	1) now duplicates some work the current version of Molly Brown now
	does;

	2) won't patch cleanly as the code in Molly Brown has been changed
	quite a bit.

  -spc


From luke.emmet at gmail.com  Fri Jun  5 22:30:58 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 5 Jun 2020 22:30:58 +0100
Subject: First Gemini CGI application in Rebol
In-Reply-To: <20200605203612.GI23998@brevard.conman.org>
References: <5EDA6948.403@marmaladefoo.com>
 <20200605203612.GI23998@brevard.conman.org>
Message-ID: <498C6BDC-1925-4FFF-8155-6E3C6344555E@gmail.com>


> 
>  Cool.  One comment though---I think you're using an older version of Molly
> Brown, as your patch 
> 
>    1) now duplicates some work the current version of Molly Brown now
>    does;
> 
>    2) won't patch cleanly as the code in Molly Brown has been changed
>    quite a bit.
> 

Ah it's good to see those recent changes. I can get back onto the mainline.

Luke

From int at 80h.dev  Sat Jun  6 19:00:04 2020
From: int at 80h.dev (int 80h)
Date: Sat, 06 Jun 2020 14:00:04 -0400
Subject: Packaging Gemini Software for Slackware
In-Reply-To: <20200604194153.3397f26e836c9db272168db6@matthewgraybosch.com>
Message-ID: <C3A7R9A4EUY6.1AXJSUGMW01F4@freebsd.lan>

On Thu Jun 4, 2020 at 3:41 PM EDT, Matthew Graybosch wrote:
> Hi, everybody. I was reluctant to use the [ANN] tag in the subject
> because I don't have a new Gemini server to announce *yet*, but I
> wanted to let everybody know that I've started packaging some Gemini
> software for Slackware as Slackbuilds.

That's cool. Just want to say thanks to you and anyone else that
packages software.

int 80h

From hello at matthewgraybosch.com  Sat Jun  6 20:08:24 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 6 Jun 2020 15:08:24 -0400
Subject: Packaging Gemini Software for Slackware
In-Reply-To: <C3A7R9A4EUY6.1AXJSUGMW01F4@freebsd.lan>
References: <20200604194153.3397f26e836c9db272168db6@matthewgraybosch.com>
 <C3A7R9A4EUY6.1AXJSUGMW01F4@freebsd.lan>
Message-ID: <20200606150824.1d8095a8454d0b1fdb67cc9e@matthewgraybosch.com>

On Sat, 06 Jun 2020 14:00:04 -0400
"int 80h" <int at 80h.dev> wrote:

> That's cool. Just want to say thanks to you and anyone else that
> packages software.

You're welcome. I'd be happy to patch Gemserv next as I mentioned
before, but I'll need a versioned tarball whenever you've got one
ready (no rush, of course). Slackbuilds isn't like AUR on Arch Linux;
they don't take scripts that involve cloning git repos. :)

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
All opinions are my own.    Harrisburg, PA USA

"Out of order?! Even in the future nothing works!"

From sean at conman.org  Sat Jun  6 21:55:48 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 6 Jun 2020 16:55:48 -0400
Subject: favicon.txt?
Message-ID: <20200606205548.GK23998@brevard.conman.org>


  I'm going through the logs for my Gemini server, specifically errors, and
while the majority due to clients hitting some corner cases in references,
there are a few that really stick out to me.

  There are the 27 requests for "favicon.txt", and I have to wonder what's
up with that?  The file is "favicon.ico".  I suppose I could return the .ico
file for any reference to "favicon.*" but I think that might be too cruel.

  Then there are the 5 requests for "c2lnaWwlM0".  No clue on that one
either.

  And then there's the 2 requests for "http://www.conman.org".  I'm sorry,
but the web server is over there, at port 80.

  -spc 


From luke at marmaladefoo.com  Sat Jun  6 22:16:43 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 06 Jun 2020 22:16:43 +0100
Subject: [Ann] An online arithmetic calculator for Gemini
Message-ID: <5EDC07BB.6030606@marmaladefoo.com>

Q: Did you leave your calculator at home before entering your 
Geminispace capsule?

Perhaps not, but in case you did, there is now a Gemini arithmetic 
calculator to get you out of your pickle.

This is another CGI test application - I wanted to test the process of 
getting input from the user.

The calculator itself:

=> gemini://gemini.marmaladefoo.com/cgi-bin/calc.cgi?0

You should be able to throw any simple arithmetic calculation at it, 
including brackets, scientific notation etc. It will try to help you out 
if you feed it nonsense or invalid input. It doesn't have any inbuilt 
functions like sine, or mathematical constants like e, i, pi though. So 
it's kinda basic, but fun.

There is also a short blog post walking through the high level logic

=> gemini://gemini.marmaladefoo.com/blog/6-Jun-2020_CGI_with_input.gmi

Best Wishes

  - Luke


From colecmac at protonmail.com  Sat Jun  6 22:31:43 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 06 Jun 2020 21:31:43 +0000
Subject: favicon.txt?
In-Reply-To: <20200606205548.GK23998@brevard.conman.org>
References: <20200606205548.GK23998@brevard.conman.org>
Message-ID: <PzeooChawbWZNNZX3mwHFX24qcrswj5OEfZuYbJ3CIVLvmXZ7MqnYqdspJYO14wUCjwxbqBvRso38znrsbCY0wBb5eo88igqY5oYOGbg5b0=@protonmail.com>

It's Michael's (mozz) draft RFC for an emoji based favicon for Gemini.

See gemini://mozz.us/files/rfc_gemini_favicon.gmi . There was also a
gemlog post about it.


makeworld

??????? Original Message ???????
On Saturday, June 6, 2020 4:55 PM, Sean Conner <sean at conman.org> wrote:

> I'm going through the logs for my Gemini server, specifically errors, and
> while the majority due to clients hitting some corner cases in references,
> there are a few that really stick out to me.
>
> There are the 27 requests for "favicon.txt", and I have to wonder what's
> up with that? The file is "favicon.ico". I suppose I could return the .ico
> file for any reference to "favicon.*" but I think that might be too cruel.
>
> Then there are the 5 requests for "c2lnaWwlM0". No clue on that one
> either.
>
> And then there's the 2 requests for "http://www.conman.org". I'm sorry,
> but the web server is over there, at port 80.
>
> -spc



From petite.abeille at gmail.com  Sat Jun  6 22:32:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 6 Jun 2020 23:32:12 +0200
Subject: favicon.txt?
In-Reply-To: <20200606205548.GK23998@brevard.conman.org>
References: <20200606205548.GK23998@brevard.conman.org>
Message-ID: <BCB3D673-1A69-4CC4-B11A-1E6ECDE8BD22@gmail.com>



> On Jun 6, 2020, at 22:55, Sean Conner <sean at conman.org> wrote:
> 
>  I'm going through the logs for my Gemini server, specifically errors, and
> while the majority due to clients hitting some corner cases in references,
> there are a few that really stick out to me.

Talking of which, should Gemini servers adopt the /.well-known/ convention [1][2][3]?

Including for robots.txt, favicon.ico, etc, etc, etc...

[1] https://en.wikipedia.org/wiki/List_of_/.well-known/_services_offered_by_webservers
[2] https://tools.ietf.org/html/rfc8615
[3] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

From sean at conman.org  Sat Jun  6 22:48:41 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 6 Jun 2020 17:48:41 -0400
Subject: favicon.txt?
In-Reply-To: <PzeooChawbWZNNZX3mwHFX24qcrswj5OEfZuYbJ3CIVLvmXZ7MqnYqdspJYO14wUCjwxbqBvRso38znrsbCY0wBb5eo88igqY5oYOGbg5b0=@protonmail.com>
References: <20200606205548.GK23998@brevard.conman.org>
 <PzeooChawbWZNNZX3mwHFX24qcrswj5OEfZuYbJ3CIVLvmXZ7MqnYqdspJYO14wUCjwxbqBvRso38znrsbCY0wBb5eo88igqY5oYOGbg5b0=@protonmail.com>
Message-ID: <20200606214841.GL23998@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> It's Michael's (mozz) draft RFC for an emoji based favicon for Gemini.
> 
> See gemini://mozz.us/files/rfc_gemini_favicon.gmi . There was also a
> gemlog post about it.

  Ah.  Okay.  I'll play along then.

  -spc


From sean at conman.org  Sat Jun  6 22:49:58 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 6 Jun 2020 17:49:58 -0400
Subject: favicon.txt?
In-Reply-To: <BCB3D673-1A69-4CC4-B11A-1E6ECDE8BD22@gmail.com>
References: <20200606205548.GK23998@brevard.conman.org>
 <BCB3D673-1A69-4CC4-B11A-1E6ECDE8BD22@gmail.com>
Message-ID: <20200606214958.GM23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Jun 6, 2020, at 22:55, Sean Conner <sean at conman.org> wrote:
> > 
> >  I'm going through the logs for my Gemini server, specifically errors, and
> > while the majority due to clients hitting some corner cases in references,
> > there are a few that really stick out to me.
> 
> Talking of which, should Gemini servers adopt the /.well-known/ convention [1][2][3]?

  Should?  I don't see why not.

> Including for robots.txt, favicon.ico, etc, etc, etc...

  Well, the list of registered well known URLs don't include any of those,
so I'm not sure of the utility, but ... okay?

  -spc

> [1] https://en.wikipedia.org/wiki/List_of_/.well-known/_services_offered_by_webservers
> [2] https://tools.ietf.org/html/rfc8615
> [3] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

From int at 80h.dev  Sat Jun  6 22:53:23 2020
From: int at 80h.dev (int 80h)
Date: Sat, 06 Jun 2020 17:53:23 -0400
Subject: Packaging Gemini Software for Slackware
In-Reply-To: <20200606150824.1d8095a8454d0b1fdb67cc9e@matthewgraybosch.com>
Message-ID: <C3ACPW9SCWWE.QECRP7DD2LCB@freebsd.lan>

On Sat Jun 6, 2020 at 11:08 AM EDT, Matthew Graybosch wrote:
> You're welcome. I'd be happy to patch Gemserv next as I mentioned
> before, but I'll need a versioned tarball whenever you've got one
> ready (no rush, of course). Slackbuilds isn't like AUR on Arch Linux;
> they don't take scripts that involve cloning git repos. :)

I pushed a tag so you can download a tarball from srht. Does that work?

int 80h

From sean at conman.org  Sat Jun  6 22:56:02 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 6 Jun 2020 17:56:02 -0400
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <5EDC07BB.6030606@marmaladefoo.com>
References: <5EDC07BB.6030606@marmaladefoo.com>
Message-ID: <20200606215602.GN23998@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
> 
> You should be able to throw any simple arithmetic calculation at it, 
> including brackets, scientific notation etc. It will try to help you out 
> if you feed it nonsense or invalid input. It doesn't have any inbuilt 
> functions like sine, or mathematical constants like e, i, pi though. So 
> it's kinda basic, but fun.

  So at first, I tried:

	3*2+1

It failed, saying I needed to space the operands.  Okay.  I then tried:

	3 * 2 + 1

And it still failed.  I wonder if you aren't decoding the query properly.

  -spc


From luke at marmaladefoo.com  Sat Jun  6 23:05:43 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 06 Jun 2020 23:05:43 +0100
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <20200606215602.GN23998@brevard.conman.org>
References: <5EDC07BB.6030606@marmaladefoo.com>
 <20200606215602.GN23998@brevard.conman.org>
Message-ID: <5EDC1337.2010806@marmaladefoo.com>


On 06-Jun-2020 22:56, Sean Conner wrote:
> It was thus said that the Great Luke Emmet once stated:
>> You should be able to throw any simple arithmetic calculation at it,
>> including brackets, scientific notation etc. It will try to help you out
>> if you feed it nonsense or invalid input. It doesn't have any inbuilt
>> functions like sine, or mathematical constants like e, i, pi though. So
>> it's kinda basic, but fun.
>    So at first, I tried:
>
> 	3*2+1
>
> It failed, saying I needed to space the operands.  Okay.  I then tried:
>
> 	3 * 2 + 1
>
> And it still failed.  I wonder if you aren't decoding the query properly.

That should work. It works for me:

gemini://gemini.marmaladefoo.com/cgi-bin/calc.cgi?3%20*%202%20+%201

Is your client url escaping the request?

There could be a mismatch between client and server (molly brown) 
regarding query params.

Best wishes

  - Luke

From sean at conman.org  Sat Jun  6 23:16:27 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 6 Jun 2020 18:16:27 -0400
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <5EDC1337.2010806@marmaladefoo.com>
References: <5EDC07BB.6030606@marmaladefoo.com>
 <20200606215602.GN23998@brevard.conman.org>
 <5EDC1337.2010806@marmaladefoo.com>
Message-ID: <20200606221627.GP23998@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
>
> On 06-Jun-2020 22:56, Sean Conner wrote:
> >It was thus said that the Great Luke Emmet once stated:
> >>You should be able to throw any simple arithmetic calculation at it,
> >>including brackets, scientific notation etc. It will try to help you out
> >>if you feed it nonsense or invalid input. It doesn't have any inbuilt
> >>functions like sine, or mathematical constants like e, i, pi though. So
> >>it's kinda basic, but fun.
> >   So at first, I tried:
> >
> >     3*2+1
> >
> >It failed, saying I needed to space the operands.  Okay.  I then tried:
> >
> >     3 * 2 + 1
> >
> >And it still failed.  I wonder if you aren't decoding the query properly.
>
> That should work. It works for me:
>
> gemini://gemini.marmaladefoo.com/cgi-bin/calc.cgi?3%20*%202%20+%201

  That did not work.  What did work?

        "gemini://gemini.marmaladefoo.com/cgi-bin/calc.cgi?3 * 2 + 1"

That is, when I *did not* encode the query [1], it worked.

> Is your client url escaping the request?

  Define "url escaping the request".  Because a query like "3 * 2 + 1" needs
to be esscpaed to "3%20*%202%20+%201"---it can also be escaped as
"%33%20%2A%20%32%20%2B%20%31".  It's that escaped string that is sent to the
server.

  -spc

[1]     I have a *very* basic Gemini client that sends verbatim what I tell
        it to send.


From luke at marmaladefoo.com  Sat Jun  6 23:28:31 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 06 Jun 2020 23:28:31 +0100
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <20200606221627.GP23998@brevard.conman.org>
References: <5EDC07BB.6030606@marmaladefoo.com>
 <20200606215602.GN23998@brevard.conman.org>
 <5EDC1337.2010806@marmaladefoo.com>
 <20200606221627.GP23998@brevard.conman.org>
Message-ID: <5EDC188F.2040103@marmaladefoo.com>

On 06-Jun-2020 23:16, Sean Conner wrote:
> <snip>
>    That did not work.  What did work?
>
>          "gemini://gemini.marmaladefoo.com/cgi-bin/calc.cgi?3 * 2 + 1"
>
> That is, when I *did not* encode the query [1], it worked.
>> Is your client url escaping the request?
>    Define "url escaping the request".  Because a query like "3 * 2 + 1" needs
> to be esscpaed to "3%20*%202%20+%201"---it can also be escaped as
> "%33%20%2A%20%32%20%2B%20%31".  It's that escaped string that is sent to the
> server.
>
>    -spc
>
> [1]     I have a *very* basic Gemini client that sends verbatim what I tell
>          it to send.
Thanks for the feedback.

I'll investigate further and try to get to the bottom of this...

  - Luke

From luke at marmaladefoo.com  Sat Jun  6 23:37:43 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 06 Jun 2020 23:37:43 +0100
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <5EDC188F.2040103@marmaladefoo.com>
References: <5EDC07BB.6030606@marmaladefoo.com>
 <20200606215602.GN23998@brevard.conman.org>
 <5EDC1337.2010806@marmaladefoo.com>
 <20200606221627.GP23998@brevard.conman.org>
 <5EDC188F.2040103@marmaladefoo.com>
Message-ID: <5EDC1AB7.5070009@marmaladefoo.com>

On 06-Jun-2020 23:28, Luke Emmet wrote:
> On 06-Jun-2020 23:16, Sean Conner wrote:
>>    Define "url escaping the request".  Because a query like "3 * 2 + 
>> 1" needs
>> to be esscpaed to "3%20*%202%20+%201"---it can also be escaped as
>> "%33%20%2A%20%32%20%2B%20%31".  It's that escaped string that is sent 
>> to the
>> server.
>>
>>    -spc
>>
>> [1]     I have a *very* basic Gemini client that sends verbatim what 
>> I tell
>>          it to send.

I'm now decoding the query on the server side. Does it work for you now?

This may have revealed a client bug I need to fix

thanks

  - Luke


From hello at matthewgraybosch.com  Sat Jun  6 23:40:44 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 6 Jun 2020 18:40:44 -0400
Subject: Packaging Gemini Software for Slackware
In-Reply-To: <C3ACPW9SCWWE.QECRP7DD2LCB@freebsd.lan>
References: <20200606150824.1d8095a8454d0b1fdb67cc9e@matthewgraybosch.com>
 <C3ACPW9SCWWE.QECRP7DD2LCB@freebsd.lan>
Message-ID: <20200606184044.987795fa4c8c6ba8b20603f9@matthewgraybosch.com>

On Sat, 06 Jun 2020 17:53:23 -0400
"int 80h" <int at 80h.dev> wrote:

> I pushed a tag so you can download a tarball from srht. Does that
> work?

That's exactly what I needed. Thanks again.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
All opinions are my own.    Harrisburg, PA USA

"Out of order?! Even in the future nothing works!"

From sean at conman.org  Sun Jun  7 00:25:12 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 6 Jun 2020 19:25:12 -0400
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <5EDC1AB7.5070009@marmaladefoo.com>
References: <5EDC07BB.6030606@marmaladefoo.com>
 <20200606215602.GN23998@brevard.conman.org>
 <5EDC1337.2010806@marmaladefoo.com>
 <20200606221627.GP23998@brevard.conman.org>
 <5EDC188F.2040103@marmaladefoo.com> <5EDC1AB7.5070009@marmaladefoo.com>
Message-ID: <20200606232512.GR23998@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
> On 06-Jun-2020 23:28, Luke Emmet wrote:
> >On 06-Jun-2020 23:16, Sean Conner wrote:
> >>   Define "url escaping the request".  Because a query like "3 * 2 +
> >>1" needs
> >>to be esscpaed to "3%20*%202%20+%201"---it can also be escaped as
> >>"%33%20%2A%20%32%20%2B%20%31".  It's that escaped string that is sent
> >>to the
> >>server.
> >>
> >>   -spc
> >>
> >>[1]     I have a *very* basic Gemini client that sends verbatim what
> >>I tell
> >>         it to send.
>
> I'm now decoding the query on the server side. Does it work for you now?

  Yes it does.
> 
> thanks

  You're welcome.

  -spc


From int at 80h.dev  Sun Jun  7 00:34:02 2020
From: int at 80h.dev (int 80h)
Date: Sat, 06 Jun 2020 19:34:02 -0400
Subject: Packaging Gemini Software for Slackware
In-Reply-To: <20200606184044.987795fa4c8c6ba8b20603f9@matthewgraybosch.com>
Message-ID: <C3AEUYFPSVFB.3P8AVGC0TOJ27@freebsd.lan>

On Sat Jun 6, 2020 at 2:40 PM EDT, Matthew Graybosch wrote:
> That's exactly what I needed. Thanks again.

And thank you

int 80h


From int at 80h.dev  Sun Jun  7 00:38:57 2020
From: int at 80h.dev (int 80h)
Date: Sat, 06 Jun 2020 19:38:57 -0400
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <5EDC1AB7.5070009@marmaladefoo.com>
Message-ID: <C3AEYPTIJ1PV.29N9EXB78VNAK@freebsd.lan>

On Sat Jun 6, 2020 at 7:37 PM EDT, Luke Emmet wrote:
> I'm now decoding the query on the server side. Does it work for you now?
>
> This may have revealed a client bug I need to fix

Just a heads up, bombadillo doesn't encode the query string.

int 80h

From hello at matthewgraybosch.com  Sun Jun  7 00:18:01 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 6 Jun 2020 19:18:01 -0400
Subject: [ANN] demifiend.org and starbreaker.org
Message-ID: <20200606191801.226544c54975d5fccf42ec2b@matthewgraybosch.com>

I'm pleased to announce that I've got two Gemini capsules running now:

=> gemini://demifiend.org Personal capsule 
=> gemini://starbreaker.org Capsule for my sf writing

There isn't much on starbreaker.org yet, but both sites have atom feeds
that can be used to track my progress as I add material.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
All opinions are my own.    Harrisburg, PA USA

"Out of order?! Even in the future nothing works!"

From felix at masterq32.de  Sun Jun  7 00:56:03 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 7 Jun 2020 01:56:03 +0200
Subject: [ANN] Kristall Small-Internet Browser
Message-ID: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>

Hello Community!

In the last week, i hacked together a new Gemini client:

  Kristall

It started as a pure Gemini + text/gemini client, but i soon started to
implement more features and now it supports more than initially planned.

Some features:

* First class cross-platform with Qt5
* Fetches several protocols (gemini, http, https, ...)
* Serves text and image documents, including text/gemini, markdown and
simplified HTML
* Stylable content display
* All the usability features you want (favourites, navigation history,
multiple tabs, ...)

My focus for this project was user experience and following the basic
gemini ideas (user first, server second). So the client provides you
with with a lot of convenience features like site styling (even
experimental auto-theming based on the domain name), a favourite list,
browsing history, ...)

Notable missing features right now are:
* More protocols (planned atm are gopher, finger and probably FTP)
* Correct TLS handling

Read a bit more about Kristall here:
=> gemini://random-projects.net/blog/2020-06-07-kristall.gemini

And fetch the source code and build it here (also Screenshots!)
=> https://github.com/MasterQ32/kristall

I would be happy about bug reports or improvement ideas, here on the
mailing list, IRC or GitHub!

Regards
- xq

From luke at marmaladefoo.com  Sun Jun  7 01:34:50 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 07 Jun 2020 01:34:50 +0100
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <C3AEYPTIJ1PV.29N9EXB78VNAK@freebsd.lan>
References: <C3AEYPTIJ1PV.29N9EXB78VNAK@freebsd.lan>
Message-ID: <5EDC362A.10604@marmaladefoo.com>

On 07-Jun-2020 00:38, int 80h wrote:
> On Sat Jun 6, 2020 at 7:37 PM EDT, Luke Emmet wrote:
>> I'm now decoding the query on the server side. Does it work for you now?
>>
>> This may have revealed a client bug I need to fix
> Just a heads up, bombadillo doesn't encode the query string.

I noticed this when testing with bombadillo. I think it probably should, 
if I understand things correctly.

It seems it isn't something that is consistently done by the various 
clients. Might be good to have a stress test page on this somewhere.

  - Luke

From solderpunk at SDF.ORG  Sun Jun  7 13:25:14 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 7 Jun 2020 12:25:14 +0000
Subject: Core Gemini docs converted to text/gemini
Message-ID: <20200607122514.GA15622@SDF.ORG>

Ahoy Geminauts!

Yesterday I converted the core Gemini documents, i.e. the protocol
specification, FAQ and best pratices documents, into the text/gemini
format, as only seems appropriate!  The Gopher version of the official
site now serves text/plain versions derived from the new text/gemini
originals using `fmt -s` to wrap lines.  The HTTPS version similarly
serves text/html versions derived from the text/gemini originals using a
Markdown converter and a little bit of sed.  The CSS styling of the
website has also been changed to make reading these long docs a little
more comfortable.

As part of this change, some URLs have changed.  Rather than the URLs
ending in .txt for all three protocols, they now end in .gmi, .txt or
.html as appropriate.  Also, the specification now lives at
specification.*** rather than spec-spec.***.  Redirects and symlinks
should avoid the breakage of any existings links or bookmarks, but if
you notice anything broken, please let me know!

Some changes to the actual content of the FAQ have also been made.

I will make some spec changes later today - nothing which has not
already been discussed here on the list.

Cheers,
Solderpunk

From tomasino at lavabit.com  Sun Jun  7 14:21:24 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 7 Jun 2020 13:21:24 +0000
Subject: Core Gemini docs converted to text/gemini
In-Reply-To: <20200607122514.GA15622@SDF.ORG>
References: <20200607122514.GA15622@SDF.ORG>
Message-ID: <300b8053-5456-03c1-067a-55a71c0fa28d@lavabit.com>

On 6/7/20 12:25 PM, solderpunk wrote:
> but if
> you notice anything broken, please let me know!

Looks like the 5.3.2 has a small issue on gemini where you described the
link format. I think you need to wrap that example in ```. Right now
it's actually being rendered as a link and breaking.


From solderpunk at SDF.ORG  Sun Jun  7 16:20:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 7 Jun 2020 15:20:16 +0000
Subject: Core Gemini docs converted to text/gemini
In-Reply-To: <300b8053-5456-03c1-067a-55a71c0fa28d@lavabit.com>
References: <20200607122514.GA15622@SDF.ORG>
 <300b8053-5456-03c1-067a-55a71c0fa28d@lavabit.com>
Message-ID: <20200607152016.GB15622@SDF.ORG>

On Sun, Jun 07, 2020 at 01:21:24PM +0000, James Tomasino wrote:
> On 6/7/20 12:25 PM, solderpunk wrote:
> > but if
> > you notice anything broken, please let me know!
> 
> Looks like the 5.3.2 has a small issue on gemini where you described the
> link format. I think you need to wrap that example in ```. Right now
> it's actually being rendered as a link and breaking.

Hmm, which client are you using?  The example links in 5.3.2 *are*
wrapped in ``` and render fine for me in AV-98 and using the mozz.us web
proxy...

Cheers,
Solderpunk

From tomasino at lavabit.com  Sun Jun  7 16:48:05 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 7 Jun 2020 15:48:05 +0000
Subject: Core Gemini docs converted to text/gemini
In-Reply-To: <20200607152016.GB15622@SDF.ORG>
References: <20200607122514.GA15622@SDF.ORG>
 <300b8053-5456-03c1-067a-55a71c0fa28d@lavabit.com>
 <20200607152016.GB15622@SDF.ORG>
Message-ID: <6b4e1504-c8fa-f9c5-25b4-e3acc33c2145@lavabit.com>

On 6/7/20 3:20 PM, solderpunk wrote:
> Hmm, which client are you using?  The example links in 5.3.2 *are*
> wrapped in ``` and render fine for me in AV-98 and using the mozz.us web
> proxy...

Ahh, yes, you're right. This was with Castor. I pulled the latest and
rebuilt to be sure, but looks like it's having issues NOT processing
links in preformatted fences.

Screenshot:
https://ttm.sh/Qq6.png


From colecmac at protonmail.com  Sun Jun  7 16:59:41 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 07 Jun 2020 15:59:41 +0000
Subject: [Ann] An online arithmetic calculator for Gemini
In-Reply-To: <C3AEYPTIJ1PV.29N9EXB78VNAK@freebsd.lan>
References: <C3AEYPTIJ1PV.29N9EXB78VNAK@freebsd.lan>
Message-ID: <qN3pX3KIW9nydrGMJ0D1kgDTgFnrhZtWSye8A4ZyseEA95mV59vmhivafg0wWyIdyU5U86ZOqawebQ9Q1rcuDxQQUu0JbWhmUP8YNk6A1aE=@protonmail.com>

As far as I can tell, Bombadillo *is* encoding the query string. Make
sure you're on the latest version.

I think the problem is that Bombadillo is encoding spaces as %20 and pluses
as just a +. This is correct, but I think the server interprets a plus and a
%20 as a space, when it should only be doing the latter.

makeworld

??????? Original Message ???????
On Saturday, June 6, 2020 7:38 PM, int 80h <int at 80h.dev> wrote:

> On Sat Jun 6, 2020 at 7:37 PM EDT, Luke Emmet wrote:
>
> > I'm now decoding the query on the server side. Does it work for you now?
> > This may have revealed a client bug I need to fix
>
> Just a heads up, bombadillo doesn't encode the query string.
>
> int 80h



From solderpunk at SDF.ORG  Sun Jun  7 17:27:23 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 7 Jun 2020 16:27:23 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
Message-ID: <20200607162723.GC15622@SDF.ORG>

Ahoy!

I have just pushed some changes to the Gemini specification.  You can
see the new new v0.13.0 spec at:

* gemini://gemini.circumlunar.space/docs/specification.gmi
* gopher://gemini.circumlunar.space/0/docs/specification.txt
* https://gemini.circumlunar.space/docs/specification.html

Perhaps the biggest change, in conceptual terms, is the introduction of
the "lang" parameter for text/gemini.  However, most clients will not
need to make any changes whatsoever on account of this.

The other changes are either small clarifications or enhancements of
existing functionality and have all been discussed previously on the
mailing list.

SUMMARY OF CHANGES:

text/gemini documents can now specify which natural language(s) they are
written in via a "lang" parameter to the media type.  Valid values of
"lang" are comma-separated lists of language tags, as defined in
RFC4646.  These are actually pretty powerful tags and can specify
language, script (which implies a particular direction of text
rendering), usage of regional variant, etc.  Of course, clients can pay
as much or as little attention to these details as their authors seem
fit.  Servers never have to provide this parameter (although it would be
good practice to do so) and clients never have to pay attention to it.
See section 5.2 for full details.

The definition of unordered list item lines has been changed so that
they begin not just with "*" but with "* ".  This allows the first word
of a regular text line to be *emphasised* in a common fashion without
the line being accidentally considered a list item.  GUS data suggests
that everybody, or almost everybody, is already writing their list items
this way, so this should not require any content updates by authors.
See section 5.4.2 for full details.

Lines beginning with ">" are now defined to be quote lines, as per
popular demand.  Nothing is prescribed about how clients should display
this.  I expect terminal-based clients will simply keep the ">" visible
as its use to convey quotation is extremely widely used and familiar
from email and usenet.  When wrapping long lines to fit the screen, each
resultant line may have a ">" placed at the front.  This is mostly just
a styling matter, but I consider it to be styling which conveys
important semantic information and when quoting multiple paragraphs of
text it helps to disambiguate where the quotation ends.  This is the
last advanced line type I expect to ever add to the spec.  See section
5.4.3 for full details.

Status code 11 has been defined for requesting "sensitive" input, like
passwords.  Clients should treat it exactly like status code 10 except
they should not echo the user's input to the screen.  This will allow us
to experiment with different authentication paradigms as part of client
certificate work-flows.  See Appendix 1 for full details.

The need to use percent-encoding on reserved characters and spaces in
URLs, both in requests and in the link lines of text/gemini bodies, has
been made explicit due to observed variation in how clients/servers
actually handle this.  See sections 3.2.1 and 5.4.2 for full details.

The definition of link lines now clarifies that clients "MUST NOT
automatically make any network connections as part of displaying links
whose scheme corresponds to a network protocol (e.g. gemini://,
gopher://, https://, ftp://, etc.)".  See section 5.4.2 for full
details.

IMPLICATIONS FOR SERVER AUTHORS:

You SHOULD consider providing a way for admins and/or users to specify
which value of the "lang" parameter should be sent for text/gemini
content.

If your server automatically generates text/gemini content (e.g.
directory listings), you MUST make sure it uses percent-encoding in
its URLs (filenames with spaces in them are a good test case!).

IMPLICATIONS FOR CLIENT AUTHORS:

Your client MAY make use of the value of the "lang" parameter in
interpreting text/gemini content (this will mostly be relevant for the
Rhapsode audio browser and perhaps for search engines).

If your client recognises unordered list item lines and treats them
differently from plain text lines, you MUST change the code which
identifies them to require a space after the *.

You MAY update your client to recognise the new quote line type.

You MAY update your client to treat status code 11 differently from
status code 10.

If your client supports status codes beginning with 1, you MUST be
percent-encoding the user input when formatting the subsequent
request.

If your client has been automatically making network connections you
MUST remove this behaviour and atone for your sins!

IMPLICATIONS FOR CONTENT AUTHORS:

If your content has unordered list item lines which do not include a
space after the initial *, you MUST insert that space.

Cheers,
Solderpunk


From tomasino at lavabit.com  Sun Jun  7 17:41:49 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 7 Jun 2020 16:41:49 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607162723.GC15622@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
Message-ID: <8b3849cb-d0de-fa18-39f1-ed6bb3f55564@lavabit.com>

On 6/7/20 4:27 PM, solderpunk wrote:
> The definition of unordered list item lines has been changed so that
> they begin not just with "*" but with "* ".
> Lines beginning with ">" are now defined to be quote lines, as per
> popular demand.

Just to be clear, lists have a mandatory space after them, but for
quotes and headings and links the whitespace is still set to zero-or-more?


From solderpunk at SDF.ORG  Sun Jun  7 17:57:24 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 7 Jun 2020 16:57:24 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <8b3849cb-d0de-fa18-39f1-ed6bb3f55564@lavabit.com>
References: <20200607162723.GC15622@SDF.ORG>
 <8b3849cb-d0de-fa18-39f1-ed6bb3f55564@lavabit.com>
Message-ID: <20200607165724.GD15622@SDF.ORG>

On Sun, Jun 07, 2020 at 04:41:49PM +0000, James Tomasino wrote:
> On 6/7/20 4:27 PM, solderpunk wrote:
> > The definition of unordered list item lines has been changed so that
> > they begin not just with "*" but with "* ".
> > Lines beginning with ">" are now defined to be quote lines, as per
> > popular demand.
> 
> Just to be clear, lists have a mandatory space after them, but for
> quotes and headings and links the whitespace is still set to zero-or-more?

That's how it current is, yeah.

This is, indeed, an inconsistency.  It arises from the fact that * is
the only one of the characters which are significant for determining
line types which has a strongly-engrained alternative use which has led
to actual erroneous formatting in the wild.

We *could* change this.  I don't see a really strong argument against
it, and consistency is good for learnability.  Then again, assuming that
clients are stripping leading whitespace from these line types, if
people get "the wrong idea" that those spaces are mandatory, it doesn't
actually cause any harm.

Cheers,
Solderpunk

From lenormfml at gmail.com  Sun Jun  7 19:38:04 2020
From: lenormfml at gmail.com (Frank LENORMAND)
Date: Sun, 07 Jun 2020 21:38:04 +0300
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607162723.GC15622@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
Message-ID: <159155508489.621220.8460141151809604634@localhost.localdomain>

Hi,

Thanks for this update!

On Sun Jun  7 19:27:23 2020, solderpunk wrote:
> The definition of unordered list item lines has been changed so that
> they begin not just with "*" but with "* ".  This allows the first word
> of a regular text line to be *emphasised* in a common fashion without
> the line being accidentally considered a list item.  GUS data suggests
> that everybody, or almost everybody, is already writing their list items
> this way, so this should not require any content updates by authors.
> See section 5.4.2 for full details.

This amendment that prevents conflicts between list items and
*emphasised text* indirectly acknowledges that clients may not
render *emphasised text* verbatim.

Writers are no longer ensured by the standard that their text surrounded with
asterisks will not be decorated by the client, by extension.

Are there any plans to mention inline text decoration explicitly in the
specification? If yes, it follows that there should be a way for writers
to escape asterisks around words, in non pre-formatted blocks.

Regards,
-- 
Frank LENORMAND

From mbays at sdf.org  Sun Jun  7 19:54:39 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sun, 7 Jun 2020 20:54:39 +0200
Subject: implementing client certificate support
Message-ID: <20200607185439.zd33kbeffsldnzry@gonzales.net>

[This post is also a glog entry at
gemini://gemini.thegonz.net/glog/200607-clientCertificatePostMortem.gmi]

I just finished adding client certificate support to my line-based 
textual gemini client diohsc. This involved making some non-trivial 
choices, and I didn't copy av98 in all cases, so I hope discussing the 
decisions I made and the reasoning behind them could be of use to other 
client developers and in refining the spec.

## User interface
* The technical terminology "client certificate", which describes an 
implementation detail rather than the underlying concept, is mostly 
hidden from the user. Instead, the client talks about "identities". An 
identity is just a client certificate along with an optional name.
* In diohsc, there are two kinds of identity -- temporary anonymous 
identities and long-term named identities. The latter are saved to disc, 
the former are held only in memory.
* There is no way to name and save an anonymous identity. Allowing it 
would complicate the UI and the conceptual distinction between the two 
kinds of identity.

### Creating identities
* When 61 is received, the user is asked if they want to create an 
anonymous identity.
* On any other 6* error code, the user may select an existing named 
identity or create a new named or anonymous identity, and then retry the 
request.
* When creating a named identity, the user is prompted to set a Common 
Name (which can be empty). This is the only choice required of the user. 
It would make for a neater UI to automatically set the Common Name to be 
the name of the identity, and in some ways it would make sense. But the 
user may well want to use the same Common Name (e.g. "anon" or "") on 
multiple servers without a common identity.

### Using identities
* An identity can be set to be used on a given server at and below 
a given URI path. So you can have one identity in use for 
gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...
* Whenever an URI is shown to the user, it is annotated with the 
identity, if any, which would be used if it were requested; e.g. 
"gemini://foo.bar/~xuuq/hello.gmi[clarkKent]". This includes relative 
URIs in links. So the user knows when they're going to use what 
identity.
* Colouring is used to visually separate the annotation from the URI 
(but '[' and ']' are reserved characters in URIs, so this isn't actually 
necessary).
* Anonymous identities are denoted as "[]".
* If the user requests an URI which would use an identity which hasn't 
been used in 30m, they are asked to confirm whether they want to still 
use it. If they don't want to, the identity is disabled for this path.

### Controlling identities
* There is a single new command added to deal with identities: "identify 
[URI]". If URI is missing, it defaults to the current URI (if any).
* If there is an identity in use at the URI, after confirmation it is 
removed.
* Otherwise the user is prompted to select an existing identity or 
create a new one, as if 60 had been received.

## Certificates
* To minimise information leakage to the server, all certificates, for 
both anonymous and named identities, are created the same way apart from 
the Common Name.
* The expiration date is set to 2 years in the future. I'm not sure if 
this is the best compromise.
* The "valid from" date is set to 1 year in the past. Why not set it to 
the current time? It's a known problem that users "in the wild" often 
don't have correctly set clocks -- they don't set the right time zone, 
then set the clock to make the time "look right". Since gemini servers 
are meant to be widely deployed, we shouldn't expect either client or 
server to have the right time. So we should backdate certificates by at 
least a couple of days, and then a year seems a nice round safe choice.
* The serial number is set to 0, no extensions are set, and the 
distinguished name consists only of the Common Name.
* The key is 2048 bit RSA with public exponent e=65537, and with hash 
algorithm SHA256. I would have liked to use Ed25519, which is more 
efficient in size and processing, but not all servers accept it.

### Fingerprinting
Currently, these choices identify diohsc uniquely. Hopefully a future 
version of the spec will suggest defaults to prevent such 
fingerprinting, and I think these would be reasonable choices. But it 
could be worth considering mandating Ed25519, even if this means only 
TLS1.3 servers can use client certificates. This can be considered an 
"advanced" feature for a server, so it isn't so much of a problem if 
some servers aren't capable of it.

## Libraries
I used Vincent Hanquez's excellent pure-haskell cryptography libraries 
to create and use client certificates. Neither openssl nor gnu-tls are 
involved at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200607/b0e961b6/attachment.sig>

From defdefred at protonmail.com  Sun Jun  7 20:13:37 2020
From: defdefred at protonmail.com (defdefred)
Date: Sun, 07 Jun 2020 19:13:37 +0000
Subject: [ANN] Kristall Small-Internet Browser
In-Reply-To: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
References: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
Message-ID: <kY3g8WjrPtW8E4qP7VcA6C26U2LmTO_AiP-t0BrQsFF08dLuqQLmMrhZFnvU55-2GoMWzpNX_E0OZY_AfXm0XuZzWCuwqSJqs0Et8HFLLZ0=@protonmail.com>

Impressive!


From case at acdw.net  Sun Jun  7 20:13:22 2020
From: case at acdw.net (Case Duckworth)
Date: Sun, 07 Jun 2020 19:13:22 +0000
Subject: [ANN] bollux 0.4.0: now with GOPHER
Message-ID: <8e21f48d-0f3e-44ec-ada1-aa77ce7374b5@www.fastmail.com>

Hi everyone,

I'm pleased to announce version 0.4.0 of my bollux client for gemini (and now gopher) space. You can see the full release notes at the repo[1], but the biggest difference is the gopher support. It's still pretty basic and it doesn't do any complicated heuristic that gopher apparently requires in clients. (I must say that writing the gopher support made me appreciate gemini so much more!)

Extra thanks to those who've packaged bollux, told me about issues, and helped with openssl command-lining. Yall know who you are :)

As always, comments/concerns/bug reports/feature requests are welcome. Open an issue on the mailing list[2], @ me on fedi[3], or get in touch somehow else. Thanks for being a great community!

[1]: https://git.sr.ht/~acdw/bollux/refs/0.4.0
[2]: https://lists.sr.ht/~acdw/public-inbox
[3]: https://writing.exchange/@acdw

-- Case (acdw)

From solderpunk at SDF.ORG  Sun Jun  7 21:10:49 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 7 Jun 2020 20:10:49 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <159155508489.621220.8460141151809604634@localhost.localdomain>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
Message-ID: <20200607201049.GF15622@SDF.ORG>

On Sun, Jun 07, 2020 at 09:38:04PM +0300, Frank LENORMAND wrote:
 
> This amendment that prevents conflicts between list items and
> *emphasised text* indirectly acknowledges that clients may not
> render *emphasised text* verbatim.
> 
> Writers are no longer ensured by the standard that their text surrounded with
> asterisks will not be decorated by the client, by extension.

Writers were *never* assured by the standard that text surrounded with
asterisks would not be decorated by the client!

Clients that want to do that can, but it's strictly an optional extra
out-of-spec nicety.  If anybody wants to do this, the onus is on them to
do is smartly enough that it doesn't interfere with the specced use of
asterisks for line items.  If they mess that up, presumably their users
will move to an either less ambitious or better written client which
doesn't mangle things.

> Are there any plans to mention inline text decoration explicitly in the
> specification? If yes, it follows that there should be a way for writers
> to escape asterisks around words, in non pre-formatted blocks.

There aren't.  Even if there were, it wouldn't follow that there would
need to be a way to escape them.  The spec says "authors should not expect
to exercise any control over the precise rendering of their text lines,
only of their actual textual content".  This extends to not being able
to opt out of various optional niceties that clients may choose to
implement above and beyond the spec.

Authors of text/gemini should never expect to influence the size,
weight, colour, font, alignment etc. of any of their text.  That's in
the client's hands, and that's a good thing.  The advanced line types
that exist may have common and semi-predictable consequences for
stylisastion in extant clients, but the reason they are in there is
primarily to give some way to convey important *semantic* information.
It's true that the list item type doesn't *quite* live up to that ideal.
But I like pretty lists, so...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jun  7 21:37:20 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 7 Jun 2020 20:37:20 +0000
Subject: implementing client certificate support
In-Reply-To: <20200607185439.zd33kbeffsldnzry@gonzales.net>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
Message-ID: <20200607203720.GG15622@SDF.ORG>

On Sun, Jun 07, 2020 at 08:54:39PM +0200, mbays at sdf.org wrote:
 
> I just finished adding client certificate support to my line-based textual
> gemini client diohsc. This involved making some non-trivial choices, and I
> didn't copy av98 in all cases, so I hope discussing the decisions I made and
> the reasoning behind them could be of use to other client developers and in
> refining the spec.

Good!  The way stuff is done in AV-98 current is *not* supposed to be
normative.  It's supposed to give us the ability to experiment with
different client certificate work flows so we can see what works and
does not.
 
> ## User interface
> * The technical terminology "client certificate", which describes an
> implementation detail rather than the underlying concept, is mostly hidden
> from the user. Instead, the client talks about "identities". An identity is
> just a client certificate along with an optional name.
> * In diohsc, there are two kinds of identity -- temporary anonymous
> identities and long-term named identities. The latter are saved to disc, the
> former are held only in memory.
> * There is no way to name and save an anonymous identity. Allowing it would
> complicate the UI and the conceptual distinction between the two kinds of
> identity.

This all sounds pretty sensible.

> ### Creating identities
> * When 61 is received, the user is asked if they want to create an anonymous
> identity.
> * On any other 6* error code, the user may select an existing named identity
> or create a new named or anonymous identity, and then retry the request.
> * When creating a named identity, the user is prompted to set a Common Name
> (which can be empty). This is the only choice required of the user. It would
> make for a neater UI to automatically set the Common Name to be the name of
> the identity, and in some ways it would make sense. But the user may well
> want to use the same Common Name (e.g. "anon" or "") on multiple servers
> without a common identity.

For what it's worth, I am thinking pretty heavily about deprecating the
current status code 61 (and 21).  They totally violate the idea that all
status codes should degrade gracefully in super simple clients which
ignore the second digit.  If 61 is interpreted as 60, there is no
guarantee that the resulting certificate will be transient as intended,
and if 21 is interpreted as 20 the active certificate may not be deleted
as soon as the server is done with it.

I am increasingly thinking that having a single code for on-demand
certificates and encouraging clients to implement the
transient/persistent distinction themselves, like you are doing with any
other 6* code.

> ### Using identities
> * An identity can be set to be used on a given server at and below a given
> URI path. So you can have one identity in use for
> gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...
> * Whenever an URI is shown to the user, it is annotated with the identity,
> if any, which would be used if it were requested; e.g.
> "gemini://foo.bar/~xuuq/hello.gmi[clarkKent]". This includes relative URIs
> in links. So the user knows when they're going to use what identity.
> * Colouring is used to visually separate the annotation from the URI (but
> '[' and ']' are reserved characters in URIs, so this isn't actually
> necessary).
> * Anonymous identities are denoted as "[]".
> * If the user requests an URI which would use an identity which hasn't been
> used in 30m, they are asked to confirm whether they want to still use it. If
> they don't want to, the identity is disabled for this path.

This also all sounds really good!  How does a certificate come to be
restricted to a given URL path and subpaths?  Is it just up to the user
to take an educated guess at the required scope for a cert and manually
specify the path?  I have been thinking that perhaps the <META> line for
status coedes 6x could be used for the server to specify precisely this
information.

> ### Controlling identities
> * There is a single new command added to deal with identities: "identify
> [URI]". If URI is missing, it defaults to the current URI (if any).
> * If there is an identity in use at the URI, after confirmation it is
> removed.
> * Otherwise the user is prompted to select an existing identity or create a
> new one, as if 60 had been received.

Aah, so this is how certs get associated with a path.

> ## Certificates
> * To minimise information leakage to the server, all certificates, for both
> anonymous and named identities, are created the same way apart from the
> Common Name.
> * The expiration date is set to 2 years in the future. I'm not sure if this
> is the best compromise.
> * The "valid from" date is set to 1 year in the past. Why not set it to the
> current time? It's a known problem that users "in the wild" often don't have
> correctly set clocks -- they don't set the right time zone, then set the
> clock to make the time "look right". Since gemini servers are meant to be
> widely deployed, we shouldn't expect either client or server to have the
> right time. So we should backdate certificates by at least a couple of days,
> and then a year seems a nice round safe choice.
> * The serial number is set to 0, no extensions are set, and the
> distinguished name consists only of the Common Name.
> * The key is 2048 bit RSA with public exponent e=65537, and with hash
> algorithm SHA256. I would have liked to use Ed25519, which is more efficient
> in size and processing, but not all servers accept it.

I have also been wondering about putting something in the best practices
about certificate key types and sizes (based on discussions with 80h
about performance on their ESP8266 implementation).  And about
ciphersuites generally, with a view toward minimising TLS overhead and
improving performance on low-power machines like Raspbery Pis.

> ### Fingerprinting
> Currently, these choices identify diohsc uniquely. Hopefully a future
> version of the spec will suggest defaults to prevent such fingerprinting,
> and I think these would be reasonable choices. But it could be worth
> considering mandating Ed25519, even if this means only TLS1.3 servers can
> use client certificates. This can be considered an "advanced" feature for a
> server, so it isn't so much of a problem if some servers aren't capable of
> it.

This is definitely worth giving consideration and the spec *should*
eventually say stuff about this.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jun  7 21:57:14 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 7 Jun 2020 20:57:14 +0000
Subject: [ANN] AV-98 1.0.0 released!
Message-ID: <20200607205714.GI15622@SDF.ORG>

Ahoy Geminiatus!

I just released AV-98 1.0.0 at long last!  The release is now at PyPI so
you can use `pip install AV-98` to easily install and, in future,
upgrade it.

Many thanks to everybody who helped test the client out in recent weeks
and especially to those who made contributions!

Cheers,
Solderpunk

From luke.emmet at gmail.com  Sun Jun  7 22:47:41 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sun, 07 Jun 2020 22:47:41 +0100
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607162723.GC15622@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
Message-ID: <5EDD607D.4070900@gmail.com>

Hello all

On 07-Jun-2020 17:27, solderpunk wrote:
> The definition of link lines now clarifies that clients "MUST NOT
> automatically make any network connections as part of displaying links
> whose scheme corresponds to a network protocol (e.g. gemini://,
> gopher://, https://, ftp://, etc.)".  See section 5.4.2 for full
> details.
>
> <snip>
>
> IMPLICATIONS FOR CLIENT AUTHORS:
>
> <snip>
>
> If your client has been automatically making network connections you
> MUST remove this behaviour and atone for your sins!
>
I think all the changes are sensible, apart from the wording that tries 
to specify client behaviour. It is not for the spec IMO to prescribe the 
client behaviour, rather it should specify the exchange format and 
markup (both of which it does well).

If a client must not make subsequent network requests when interpreting 
a page, does this mean that search engines and crawlers are now 
non-compliant clients? This seems to go much too far.

I would think the "MUST NOT" would be better as a "SHOULD NOT" in case 
you are adamant to try to shape client behaviour. In my view this is not 
in scope of a protocol and markup format specification.

Also minor point, I would recommend removing the "atone for your sins" 
sentence as it is overly informal for a spec.

I like the explicit requirements covering URL encoding, lang, and 
bullets. I wonder how authors will reliably signal the language to the 
server though, particularly as it may be on a page by page basis.

Otherwise keep up the good work!

Best wishes

  - Luke


From luke.emmet at gmail.com  Sun Jun  7 22:57:28 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sun, 07 Jun 2020 22:57:28 +0100
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <5EDD607D.4070900@gmail.com>
References: <20200607162723.GC15622@SDF.ORG> <5EDD607D.4070900@gmail.com>
Message-ID: <5EDD62C8.4060109@gmail.com>

A minor clarification below...

On 07-Jun-2020 22:47, Luke Emmet wrote:
> Hello all
>
> On 07-Jun-2020 17:27, solderpunk wrote:
>> The definition of link lines now clarifies that clients "MUST NOT
>> automatically make any network connections as part of displaying links
>> whose scheme corresponds to a network protocol (e.g. gemini://,
>> gopher://, https://, ftp://, etc.)".  See section 5.4.2 for full
>> details.
>>
>> <snip>
>>
>> IMPLICATIONS FOR CLIENT AUTHORS:
>>
>> <snip>
>>
>> If your client has been automatically making network connections you
>> MUST remove this behaviour and atone for your sins!
>>
> I think all the changes are sensible, apart from the wording that 
> tries to specify client behaviour. It is not for the spec IMO to 
> prescribe the client behaviour, rather it should specify the exchange 
> format and markup (both of which it does well).

Sorry, to clarify that particular point, my intended point was that it 
is not for the spec to prescribe *when* the client makes or does not 
make its network requests in light of on its interpretation of the 
textual content. The spec should stick to correct computer to computer 
exchange (protocol matters) and the markup format (both of which it does 
well).
>
> If a client must not make subsequent network requests when 
> interpreting a page, does this mean that search engines and crawlers 
> are now non-compliant clients? This seems to go much too far.
>
> I would think the "MUST NOT" would be better as a "SHOULD NOT" in case 
> you are adamant to try to shape client behaviour. In my view this is 
> not in scope of a protocol and markup format specification.
>
> Also minor point, I would recommend removing the "atone for your sins" 
> sentence as it is overly informal for a spec.
>
> I like the explicit requirements covering URL encoding, lang, and 
> bullets. I wonder how authors will reliably signal the language to the 
> server though, particularly as it may be on a page by page basis.
>
> Otherwise keep up the good work!
>
> Best wishes
>
>  - Luke
>

From sean at conman.org  Sun Jun  7 23:05:33 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 7 Jun 2020 18:05:33 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607162723.GC15622@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
Message-ID: <20200607220533.GT23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> IMPLICATIONS FOR CLIENT AUTHORS:
> 
> If your client has been automatically making network connections you
> MUST remove this behaviour and atone for your sins!

  [Citation needed]

  -spc


From hello at matthewgraybosch.com  Sun Jun  7 23:30:52 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sun, 7 Jun 2020 18:30:52 -0400
Subject: [ANN] bollux 0.4.0: now with GOPHER
In-Reply-To: <8e21f48d-0f3e-44ec-ada1-aa77ce7374b5@www.fastmail.com>
References: <8e21f48d-0f3e-44ec-ada1-aa77ce7374b5@www.fastmail.com>
Message-ID: <20200607183052.f0327004fbe435d68c4f55a0@matthewgraybosch.com>

On Sun, 07 Jun 2020 19:13:22 +0000
"Case Duckworth" <case at acdw.net> wrote:

> Hi everyone,
> 
> I'm pleased to announce version 0.4.0 of my bollux client for gemini
> (and now gopher) space. You can see the full release notes at the repo
> [1], but the biggest difference is the gopher support. 

Good job! I've submitted build scripts for v0.4.0 to slackbuilds.org.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From hello at matthewgraybosch.com  Sun Jun  7 23:40:33 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sun, 7 Jun 2020 18:40:33 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <159155508489.621220.8460141151809604634@localhost.localdomain>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
Message-ID: <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>

On Sun, 07 Jun 2020 21:38:04 +0300
Frank LENORMAND <lenormfml at gmail.com> wrote:

> Writers are no longer ensured by the standard that their text
> surrounded with asterisks will not be decorated by the client, by
> extension.

Writer here, but speaking strictly for myself. I don't see a problem
with this change. Details below.

---

I use asterisks inline for emphasis because that's a habit I've taken
from Markdown. My understanding of the standard was that the
behavior of inline asterisks (as opposed to asterisks at at the
beginning of a line to indicate a list item) is undefined and thus
client-dependent.

If the client uses them to denote *italics* and **bold**, great. If
not, I figure that readers familiar with plain-text email will still
interpret such text accordingly. Either way, as a self-hosting writer,
my job is to make the words and reliably serve them. What happens on
the client side is none of my business.

My understanding of the new changes to the standard is that the
behavior of inline asterisks is *still* client-dependent. That's fine
with me as a writer, TBH. If I wanted the illusion of precise control
over how clients render my documents, I'd go back to HTML/CSS--or
pick up groff again and just post PDFs. :)

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From hello at matthewgraybosch.com  Mon Jun  8 00:06:38 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sun, 7 Jun 2020 19:06:38 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607162723.GC15622@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
Message-ID: <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>

On Sun, 7 Jun 2020 16:27:23 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> I have just pushed some changes to the Gemini specification.  You can
> see the new new v0.13.0 spec at:

Thanks for the work you've been doing. If you don't mind, I have a
couple of questions as a content author.

> Perhaps the biggest change, in conceptual terms, is the introduction
> of the "lang" parameter for text/gemini.  However, most clients will
> not need to make any changes whatsoever on account of this.

I just read the relevant part of the spec, but I'm still not clear on
how I should go about specifying that my text is US English. Do I just
have to add "lang=en_US" on the first line of a text/gemini file?

> Lines beginning with ">" are now defined to be quote lines, as per
> popular demand.

This will be handy, but now I'm wondering about pre-formatted quotes
(mainly for poetry, song lyrics, screenplays, etc.)

For example, if a Gemini content author wanted to quote from a modern
poem like T. S. Eliot's _The Waste Land_ and preserve the original
formatting, would they do something like this?

```
> "What is that noise?"
>                           The wind under the door.
> "What is that noise now? What is the wind doing?"
>                            Nothing again nothing.
>                                                         "Do
> "You know nothing? Do you see nothing? Do you remember
> "Nothing?"
```

I suspect that most clients would interpret this block as just
pre-formatted text and render it in monospace--which I acknowledge is
correct behavior according to the current spec but not necessarily what
a content author wants if they decide to load their own page to see how
it looks in various clients.

Furthermore, looking for quote characters inside a preformatted block
and then rendering that block in a variable-width font instead (when
applicable) sounds like a good way to introduce bugs.

I'd like to suggest instead that we import the | character followed by
a space to denote line blocks from reStructuredText as an advanced line
type.

=>
https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks

Of course, I suppose content authors could just use reStructuredText
instead, which should probably be the goto format for text that uses
footnotes/endnotes as well.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From mbays at sdf.org  Sun Jun  7 23:44:14 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Mon, 8 Jun 2020 00:44:14 +0200
Subject: implementing client certificate support
In-Reply-To: <20200607203720.GG15622@SDF.ORG>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
Message-ID: <20200607224414.pvpcbzjsx6gna3au@gonzales.net>

* Sunday, 2020-06-07 at 20:37 +0000 - solderpunk <solderpunk at SDF.ORG>:

>On Sun, Jun 07, 2020 at 08:54:39PM +0200, mbays at sdf.org wrote:
>
>> ### Using identities
>> * An identity can be set to be used on a given server at and below a given
>> URI path. So you can have one identity in use for
>> gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...
>
>How does a certificate come to be restricted to a given URL path and 
>subpaths?

If an identity starts being used as the result of a 6* response to 
a request, then the identity is subsequently used for all requests to 
that path and anything below. Same if the "identify" command is used on 
an URI.

This doesn't work entirely smoothly with astrobotony -- you might start 
using our certificate at gemini://astrobotany.mozz.us/plant/, so it then 
also takes effect for gemini://astrobotany.mozz.us/plant/water and so 
on, but if you try e.g. gemini://astrobotany.mozz.us/settings you have 
to select the identity again. You can manually "identify 
gemini://astrobotany.mozz.us", but that isn't so smooth. Probably marks 
should optionally have an identity associated -- that would help quite 
a bit, but needs some forethought from the user.

If this method of restricting an identity to subpaths of the path it's 
first requested at became normal, maybe servers would tend to arrange 
everything which requires a certificate below a single "gate" root.

>I have been thinking that perhaps the <META> line for status coedes 6x 
>could be used for the server to specify precisely this information.

That could work.

Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/a05b2f1c/attachment-0001.sig>

From tomasino at lavabit.com  Mon Jun  8 00:18:36 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 7 Jun 2020 23:18:36 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>
References: <20200607162723.GC15622@SDF.ORG>
 <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>
Message-ID: <9f3650ba-4cd2-60a3-eae4-a74e95b228f1@lavabit.com>

On 6/7/20 11:06 PM, Matthew Graybosch wrote:
> For example, if a Gemini content author wanted to quote from a modern
> poem like T. S. Eliot's _The Waste Land_ and preserve the original
> formatting, would they do something like this?
> 
> ```
>> "What is that noise?"
>>                           The wind under the door.
>> "What is that noise now? What is the wind doing?"
>>                            Nothing again nothing.
>>                                                         "Do
>> "You know nothing? Do you see nothing? Do you remember
>> "Nothing?"
> ```
> 
> I suspect that most clients would interpret this block as just
> pre-formatted text and render it in monospace--which I acknowledge is
> correct behavior according to the current spec but not necessarily what
> a content author wants if they decide to load their own page to see how
> it looks in various clients.

Using the preformatted fences is exactly what you'd want to use. Your
example above would preserve whitespace. That's one of the main purposes
of the ```.

I don't understand the need for an additional line type from your
description.


From hello at matthewgraybosch.com  Mon Jun  8 00:41:33 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sun, 7 Jun 2020 19:41:33 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <9f3650ba-4cd2-60a3-eae4-a74e95b228f1@lavabit.com>
References: <20200607162723.GC15622@SDF.ORG>
 <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>
 <9f3650ba-4cd2-60a3-eae4-a74e95b228f1@lavabit.com>
Message-ID: <20200607194133.f78d0b71bc121f05954500e6@matthewgraybosch.com>

On Sun, 7 Jun 2020 23:18:36 +0000
James Tomasino <tomasino at lavabit.com> wrote:

> Using the preformatted fences is exactly what you'd want to use. Your
> example above would preserve whitespace. That's one of the main
> purposes of the ```.
> 
> I don't understand the need for an additional line type from your
> description.
 
I must have been overthinking things, trying to get the best of both
worlds: a blockquote that preserves whitespace.

Sorry to have wasted people's time.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From lazar.michael22 at gmail.com  Mon Jun  8 03:00:02 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sun, 7 Jun 2020 22:00:02 -0400
Subject: implementing client certificate support
In-Reply-To: <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
Message-ID: <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>

On Sun, Jun 7, 2020 at 7:14 PM <mbays at sdf.org> wrote:
>
> This doesn't work entirely smoothly with astrobotony -- you might start
> using our certificate at gemini://astrobotany.mozz.us/plant/, so it then
> also takes effect for gemini://astrobotany.mozz.us/plant/water and so
> on, but if you try e.g. gemini://astrobotany.mozz.us/settings you have
> to select the identity again. You can manually "identify
> gemini://astrobotany.mozz.us", but that isn't so smooth. Probably marks
> should optionally have an identity associated -- that would help quite
> a bit, but needs some forethought from the user.

For what it's worth, I have been thinking about reorganizing the URL
structure for astrobotany so that all of the authenticated endpoints
live behind a single path. I am also planning on adding more
unauthenticated content to the server, so I want to establish a
clear separation between the sections that require a client certificate
and the sections that do not.

- gemini://astrobotany.mozz.us/
- gemini://astrobotany.mozz.us/about
- gemini://astrobotany.mozz.us/app (requires client certificate)
- gemini://astrobotany.mozz.us/app/plant
- gemini://astrobotany.mozz.us/app/directory
- ...

There are several other advantages to having a well designed path
hierarchy. It's something that I often don't spend enough time
thinking about up front and then I regret not doing it right later.

- Michael (mozz)

From int at 80h.dev  Mon Jun  8 05:07:32 2020
From: int at 80h.dev (int 80h)
Date: Mon, 08 Jun 2020 00:07:32 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>
Message-ID: <C3BFAWLE7VKH.Y1A20YJK054G@freebsd.lan>

On Sun Jun 7, 2020 at 3:06 PM EDT, Matthew Graybosch wrote:
> I just read the relevant part of the spec, but I'm still not clear on
> how I should go about specifying that my text is US English. Do I just
> have to add "lang=en_US" on the first line of a text/gemini file?

I'm not sure how other server writers did it but I added "lang" as an
option per vhost, currently on the dev branch.

I've suggested adding "lang" to the first line before[1] but I need to
reread that discussion to see if anyone else commented on it.

[1] https://lists.orbitalfox.eu/archives/gemini/2020/000845.html

int 80h

From solderpunk at SDF.ORG  Mon Jun  8 08:22:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 8 Jun 2020 07:22:33 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
Message-ID: <20200608072233.GB9769@SDF.ORG>

On Sun, Jun 07, 2020 at 06:40:33PM -0400, Matthew Graybosch wrote:

> I use asterisks inline for emphasis because that's a habit I've taken
> from Markdown. My understanding of the standard was that the
> behavior of inline asterisks (as opposed to asterisks at at the
> beginning of a line to indicate a list item) is undefined and thus
> client-dependent.
> 
> If the client uses them to denote *italics* and **bold**, great. If
> not, I figure that readers familiar with plain-text email will still
> interpret such text accordingly. Either way, as a self-hosting writer,
> my job is to make the words and reliably serve them. What happens on
> the client side is none of my business.
> 
> My understanding of the new changes to the standard is that the
> behavior of inline asterisks is *still* client-dependent. That's fine
> with me as a writer, TBH. If I wanted the illusion of precise control
> over how clients render my documents, I'd go back to HTML/CSS--or
> pick up groff again and just post PDFs. :)

This is all correct - technically *and* ideologically. :)

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Mon Jun  8 08:36:06 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 8 Jun 2020 07:36:06 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>
References: <20200607162723.GC15622@SDF.ORG>
 <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>
Message-ID: <20200608073606.GC9769@SDF.ORG>

On Sun, Jun 07, 2020 at 07:06:38PM -0400, Matthew Graybosch wrote:
 
> I just read the relevant part of the spec, but I'm still not clear on
> how I should go about specifying that my text is US English. Do I just
> have to add "lang=en_US" on the first line of a text/gemini file?

No, the "lang" parameter is a parameter to the text/gemini MIME type
which is part of the response header.  It doesn't go in the document
itself.  Server software will need to provide admins and/or users some
way to configure this.

This will be fairly easy for people who run their own serer, and hence
have access to the config file, and who write in only a single language
- they can just set a single value which the server includes for all
.gmi files (or whatever extension has been configured to serve as
text/gemini).

Multi-lingual sites would probably work best with content in different
languages separated by the path hierarchy, and servers could let people
designate different languages depending on which regex the path matches.

Multi-user sites will be trickiest of all and will require users to
either bother the admin, or for servers to implement something like
Apache's .htaccess files.

I don't deny that this is kind of painful.  But I don't see a way around
it - if we say that the first line of a text/gemini file should be
"#lang: en-US" or anything like that we have immediately opened the door
to arbitrarly many additional options.  This basically gives us HTTP's
open-ended response header structure and completely defeats the point of
having a response header which is explicitly a single line.
 
> > Lines beginning with ">" are now defined to be quote lines, as per
> > popular demand.
> 
> This will be handy, but now I'm wondering about pre-formatted quotes
> (mainly for poetry, song lyrics, screenplays, etc.)

I would expect those to be handled just with pre-formatted lines.  I get
that they're also a quote of sorts, but simplicity necessitates
sacrifcing the ability for total semantic precision.  I hope we can live
with this.

(of course, something like an entire screenplay can always just be
served in its own document as text/plain)

> Furthermore, looking for quote characters inside a preformatted block
> and then rendering that block in a variable-width font instead (when
> applicable) sounds like a good way to introduce bugs.

It's also a clear violation of the spec!

Cheers,
Solderpunk

From pitr.vern at gmail.com  Mon Jun  8 08:39:37 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Mon, 8 Jun 2020 09:39:37 +0200
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
Message-ID: <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>

I?ve added support for client certificates in the latest build, basing
mostly on implementation of AV-98. There?s a weird bug when using
gemini://astrobotany.mozz.us/ which requires restart of client for
certificate to work (and for it be deactivated) but
gemini://gemini.conman.org/private/ works properly. Are there any other
servers requiring client certificates that I can test against?

I also updated code to comply with updates to Gemini protocol. Looking
forward to seeing status code 11 in the wild :)

On Tue, Jun 2, 2020 at 21:44 Peter Vernigorov <pitr.vern at gmail.com> wrote:

> Thanks. These responses and re-reading the spec clarified my initial
> concern. Spec clearly states that transient certificates should not be
> shared across domains. And there is no point using permanent certificates
> across domains as it is assumed that these certificates have a special
> meaning for specific domains.
>
> I am still unclear as to what happens after a transient certificate has
> been created. Should browser automatically use it for the page that
> requested it and any other pages on that domain? I don?t see a good
> solution here. Either certificate is sent only when server requests it,
> which would double number of requests (assuming user stays in private
> section of the site), or certificate is always sent, which adds overhead to
> all requests. Should browser remember which pages need a certificate and
> always use it for them?
>
> And additionally, should browser ask user for every page that requires a
> certificate if existing one can be used?
>
> Thanks for replying to my earlier questions. I want to make sure that my
> support for certificates doesn?t violate the spec or creates a bad user
> experience.
>
> On Tue, Jun 2, 2020 at 20:31 solderpunk <solderpunk at sdf.org> wrote:
>
>> On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote:
>>
>> > Question about client certificates: not sure how other clients implement
>> > this, but I was thinking of generating and using the same client cert
>> for
>> > all sites, and giving an option to create a cert for specific domain.
>> Does
>> > that make sense? Potential problem I see is that main certificate is
>> > something user could be identified by across websites.
>>
>> It's not super clear to me what you're suggesting.
>>
>> If it's that the client generates a single self-signed client cert the
>> first time it starts up and then just sends that cert to every single
>> host as part of every single request: PLEASE DON'T DO THAT!  This is
>> about as wrong an implementation of Gemini's idea of client certificates
>> as possible.  The vast majority of URLs will not require or expect a
>> client cert (which is why there's a way for servers to explicitly
>> request one in the unusual circumstance it's needed), and any you send
>> will just be ignored.  You will be needlessly increasing the TLS overhead
>> (which is already pretty heavy relative to typical text/gemini payload
>> sizes) for no gain.  Worse, admins of unrelated servers would be able to
>> compare their logs and track you across Geminispace.
>>
>> If it's that you generate a single certificate the first time it starts
>> up but only send it out in response to a status code of 62 that's a
>> different matter (I assume it goes without saying you shouldn't ever use
>> it in response to a status code of 61 because the behaviour for
>> transient certs is extremely clearly specced and this would fly in the
>> face of just about every part of it).  I still think it's the wrong
>> thing to do, but it's slightly less disasterous than the first option.
>>
>> Client certificates should be handled in a very deliberate manner - the
>> user needs make the clear decision to opt in, on their own terms, to
>> being identified to some server(s).  It's an exceptional condition and
>> should never be automated or hidden from the user for the sake of
>> convenience.  Sharing a single certificate across domains isn't
>> something anybody should ever do lightly.
>>
>> Cheers,
>> Solderpunk
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/e76c5928/attachment-0001.htm>

From solderpunk at SDF.ORG  Mon Jun  8 08:44:38 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 8 Jun 2020 07:44:38 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <5EDD607D.4070900@gmail.com>
References: <20200607162723.GC15622@SDF.ORG>
 <5EDD607D.4070900@gmail.com>
Message-ID: <20200608074438.GD9769@SDF.ORG>

On Sun, Jun 07, 2020 at 10:47:41PM +0100, Luke Emmet wrote:
 
> If a client must not make subsequent network requests when interpreting a
> page, does this mean that search engines and crawlers are now non-compliant
> clients? This seems to go much too far.
> 
> I would think the "MUST NOT" would be better as a "SHOULD NOT" in case you
> are adamant to try to shape client behaviour. In my view this is not in
> scope of a protocol and markup format specification.

You raise a good point, about search engines and the like.  Perhaps I
should specify "interactive clients".

And I get that this kind of prescription is beyond what would usually be
thought of as reasonable scope for a protocol spec.  I also realise that
it's entirely unenforcable.  In some very unlikely distant future where
the spec is being preened for actual IETF consideration I might remove
it.  But for now I want to do my best to make sure that Gemini develops
not just a technical specification but a strong cultural sense of the
right and wrong way to use that spec.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Mon Jun  8 08:47:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 8 Jun 2020 07:47:37 +0000
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
Message-ID: <20200608074737.GE9769@SDF.ORG>

On Mon, Jun 08, 2020 at 09:39:37AM +0200, Peter Vernigorov wrote:

> Are there any other
> servers requiring client certificates that I can test against?

I don't think there are yet.  But lately I've been working to add good
CGI and SCGI support to Molly Brown, including passing information about
client certs on to aps through the variables (following Sean's lead for
now, although I need to bring up some points for discussion about this
in the near future).  Very soon I will take advantage of this to start
experimenting pretty heavily with client cert stuff.  I will probably
put up implementations of various possible authentication workflows to
help us test clients and ideas sometime in the next week or so.

Cheers,
Solderpunk


From hannu.hartikainen+gemini at gmail.com  Mon Jun  8 10:18:06 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Mon, 8 Jun 2020 12:18:06 +0300
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200608074438.GD9769@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG> <5EDD607D.4070900@gmail.com>
 <20200608074438.GD9769@SDF.ORG>
Message-ID: <CANmFPemVRa+0NatAN2Kf4Q2V+KQrOctQ4nRpuJ4LiV93R9qT=Q@mail.gmail.com>

> On Sun, Jun 07, 2020 at 10:47:41PM +0100, Luke Emmet wrote:
> > If a client must not make subsequent network requests when interpreting
a
> > page, does this mean that search engines and crawlers are now
non-compliant
> > clients? This seems to go much too far.

The spec says

> Clients can present links to users in whatever fashion the client author
wishes, however clients MUST NOT automatically make any network connections
as part of displaying links whose scheme corresponds to a network protocol
(e.g. gemini://, gopher://, https://, ftp://, etc.).

I find this reasonable: a crawler does not make any extra network
connections *when interpreting a page* or *as part of displaying links*.
Rather, it fetches single pages per spec, while building a graph of all
known pages (which it then fetches, still as single pages in a way
compatible with the spec). A crawler need not fetch any other pages in
order to add a single page to its index. If a search engine started
supporting inlining content from links it would be breaking the spec.

My two cents.

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/089033a4/attachment.htm>

From defdefred at protonmail.com  Mon Jun  8 14:57:47 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 08 Jun 2020 13:57:47 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <CANmFPemVRa+0NatAN2Kf4Q2V+KQrOctQ4nRpuJ4LiV93R9qT=Q@mail.gmail.com>
References: <20200607162723.GC15622@SDF.ORG> <5EDD607D.4070900@gmail.com>
 <20200608074438.GD9769@SDF.ORG>
 <CANmFPemVRa+0NatAN2Kf4Q2V+KQrOctQ4nRpuJ4LiV93R9qT=Q@mail.gmail.com>
Message-ID: <42XH3De1OSpcFdKCCRI9kZe2yahGENlpEjUVx6vkeq0JD-GMF6mVsEHYfKVtaBZwk4joTBEzianhYcjFcNutXyXN-DNYgsFsEYPLXfU5ycQ=@protonmail.com>

I wonder how many data consumption these search engine are representing all over the web.
Good thing with static site is that they can be cached and don't need to be downloaded each time to check is changed occurred.
A timestamp should suffice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/e3a491a0/attachment.htm>

From hello at matthewgraybosch.com  Mon Jun  8 16:52:16 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Mon, 8 Jun 2020 11:52:16 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <C3BFAWLE7VKH.Y1A20YJK054G@freebsd.lan>
References: <20200607190638.94103f3d44ca8a9abbe928e0@matthewgraybosch.com>
 <C3BFAWLE7VKH.Y1A20YJK054G@freebsd.lan>
Message-ID: <20200608115216.92c035ef3a8de17750a3fa64@matthewgraybosch.com>

On Mon, 08 Jun 2020 00:07:32 -0400
"int 80h" <int at 80h.dev> wrote:

> I'm not sure how other server writers did it but I added "lang" as an
> option per vhost, currently on the dev branch.

lang in vhost config makes sense to me. Thanks.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From julien at typed-hole.org  Mon Jun  8 17:41:44 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Mon, 08 Jun 2020 18:41:44 +0200
Subject: Adding gemini protocol to curl
In-Reply-To: <831ba0b2-7a69-495c-98c1-c052dfbf3248@www.fastmail.com>
Message-ID: <C3BVCD8CO6J0.1R441Y9NDVJ70@x1carbon>

On Thu May 21, 2020 at 6:37 PM CEST, Ben Burwell wrote:
>
> My curl tree with the gemini patch is available here:
> https://git.sr.ht/~benburwell/curl
>

Has the repo moved? I get a 404.

From int at 80h.dev  Mon Jun  8 18:10:42 2020
From: int at 80h.dev (int 80h)
Date: Mon, 08 Jun 2020 13:10:42 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200608073606.GC9769@SDF.ORG>
Message-ID: <C3BVYJGCCRL6.OJWQ70A7TLE4@freebsd.lan>

On Mon Jun 8, 2020 at 3:36 AM EDT, solderpunk wrote:
> No, the "lang" parameter is a parameter to the text/gemini MIME type
> which is part of the response header. It doesn't go in the document
> itself. Server software will need to provide admins and/or users some
> way to configure this.

The way I was thinking is have the server look at the first line for
"#lang" then strip it and put it in the response header. That way it
could be an implementation of the server and not the spec itself.

> Multi-lingual sites would probably work best with content in different
> languages separated by the path hierarchy, and servers could let people
> designate different languages depending on which regex the path matches.
>
> Multi-user sites will be trickiest of all and will require users to
> either bother the admin, or for servers to implement something like
> Apache's .htaccess files.

Something like .htaccess could work. This morning I was also thinking of
it being in the file name. Then it could be on a per file basis like
"index.fr.gmi" would be sent as "index.gmi" with "lang=fr" in the
response header.

int 80h

From solderpunk at SDF.ORG  Mon Jun  8 18:24:51 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 8 Jun 2020 17:24:51 +0000
Subject: implementing client certificate support
In-Reply-To: <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
Message-ID: <20200608172451.GA12292@SDF.ORG>

On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote:
 
> For what it's worth, I have been thinking about reorganizing the URL
> structure for astrobotany so that all of the authenticated endpoints
> live behind a single path. I am also planning on adding more
> unauthenticated content to the server, so I want to establish a
> clear separation between the sections that require a client certificate
> and the sections that do not.
> 
> - gemini://astrobotany.mozz.us/
> - gemini://astrobotany.mozz.us/about
> - gemini://astrobotany.mozz.us/app (requires client certificate)
> - gemini://astrobotany.mozz.us/app/plant
> - gemini://astrobotany.mozz.us/app/directory
> - ...
> 
> There are several other advantages to having a well designed path
> hierarchy. It's something that I often don't spend enough time
> thinking about up front and then I regret not doing it right later.

This seems wise to me.  It's already pretty clear that associating
client certificates with domains, as currently specced (for transient
certs, at least) and as implemented in AV-98, is not the best idea.  It
will inevitably cause confusion/frustration/difficulty in environments
where multiple users share a domain (like pubnixes).  Associating them
with paths seems the obvious solution.

As the current leading implementer of client cert consumning apps, I'm
curious how you feel about the idea of using the <META> for 6x statuses
to convey an intended "path scope" for certs?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Mon Jun  8 18:26:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 8 Jun 2020 17:26:29 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <C3BVYJGCCRL6.OJWQ70A7TLE4@freebsd.lan>
References: <20200608073606.GC9769@SDF.ORG>
 <C3BVYJGCCRL6.OJWQ70A7TLE4@freebsd.lan>
Message-ID: <20200608172629.GB12292@SDF.ORG>

On Mon, Jun 08, 2020 at 01:10:42PM -0400, int 80h wrote:
 
> The way I was thinking is have the server look at the first line for
> "#lang" then strip it and put it in the response header. That way it
> could be an implementation of the server and not the spec itself.

Oh, sorry, I misunderstood!  That seems perfectly cromulent, although
I'd be a bit wary myself of tying my content to a specific server
(unless this convention became widely adopted).

Cheers,
Solderpunk

From int at 80h.dev  Mon Jun  8 18:29:38 2020
From: int at 80h.dev (int 80h)
Date: Mon, 08 Jun 2020 13:29:38 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200608172629.GB12292@SDF.ORG>
Message-ID: <C3BWD1K4E4R8.2D2WCDA405GNG@freebsd.lan>

On Mon Jun 8, 2020 at 1:26 PM EDT, solderpunk wrote:
> Oh, sorry, I misunderstood! That seems perfectly cromulent, although
> I'd be a bit wary myself of tying my content to a specific server
> (unless this convention became widely adopted).

True that could get annoying if it wasn't widely adopted.

int 80h

From jmcbray at carcosa.net  Mon Jun  8 20:28:37 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 08 Jun 2020 15:28:37 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <C3BFAWLE7VKH.Y1A20YJK054G@freebsd.lan> (int@80h.dev's message of
 "Mon, 08 Jun 2020 00:07:32 -0400")
References: <C3BFAWLE7VKH.Y1A20YJK054G@freebsd.lan>
Message-ID: <87tuzlqrve.fsf@dorothy.carcosa.net>

"int 80h" <int at 80h.dev> writes:

> On Sun Jun 7, 2020 at 3:06 PM EDT, Matthew Graybosch wrote:
>> I just read the relevant part of the spec, but I'm still not clear on
>> how I should go about specifying that my text is US English. Do I just
>> have to add "lang=en_US" on the first line of a text/gemini file?
>
> I'm not sure how other server writers did it but I added "lang" as an
> option per vhost, currently on the dev branch.

My intention (in Germinal) is to have a global default option, a default
per-virtual host (once I add virtual hosts), and provide some way of
supplying individual files with metadata ? possibly a TOML file in each
directory with a section for each file or something similar.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From baschdel at disroot.org  Mon Jun  8 20:40:40 2020
From: baschdel at disroot.org (baschdel at disroot.org)
Date: Mon, 08 Jun 2020 21:40:40 +0200
Subject: [ANN] New server: gemini://gemini.marmaladefoo.com/
In-Reply-To: <5ED930B9.5020707@gmail.com>
References: <5ED930B9.5020707@gmail.com>
Message-ID: <SBHMBQ.CEH7SSDW64TO1@disroot.org>

Greetings!

Unfortunately I can't connect with my gnu-tls based client or 
gnutls-cli.

$ gnutls-cli --insecure gemini.marmaladefoo.com 1965
Processed 0 CA certificate(s).
Resolving 'gemini.marmaladefoo.com:443'...
Connecting to '2a00:1098:0:80:1000:3b:1:1:443'...
*** Fatal error: The TLS connection was non-properly terminated.

Have a nice day/night/evening!
- Baschdel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/855be7fc/attachment-0001.htm>

From luke at marmaladefoo.com  Mon Jun  8 20:46:35 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 08 Jun 2020 20:46:35 +0100
Subject: [ANN] New server: gemini://gemini.marmaladefoo.com/
In-Reply-To: <SBHMBQ.CEH7SSDW64TO1@disroot.org>
References: <5ED930B9.5020707@gmail.com> <SBHMBQ.CEH7SSDW64TO1@disroot.org>
Message-ID: <5EDE959B.4070808@marmaladefoo.com>

Hi Baschdel

Thanks for the feedback

I'm just running Molly Brown server - I dont know much about how TLS works

The server is behind a IP4 to IPv6 proxy - but it should work. It works 
for me using other clients, but maybe they arent as strict as the one 
you have

Is there any other information about what it doesnt like?

Best Wishes

   - Luke

On 08-Jun-2020 20:40, baschdel at disroot.org wrote:
> Greetings!
>
> Unfortunately I can't connect with my gnu-tls based client or gnutls-cli.
>
> $ gnutls-cli --insecure gemini.marmaladefoo.com 1965
> Processed 0 CA certificate(s).
> Resolving 'gemini.marmaladefoo.com:443'...
> Connecting to '2a00:1098:0:80:1000:3b:1:1:443'...
> *** Fatal error: The TLS connection was non-properly terminated.
>
> Have a nice day/night/evening!
> - Baschdel

From baschdel at disroot.org  Mon Jun  8 20:46:06 2020
From: baschdel at disroot.org (baschdel at disroot.org)
Date: Mon, 08 Jun 2020 21:46:06 +0200
Subject: [ANN] New server: gemini://gemini.marmaladefoo.com/
In-Reply-To: <SBHMBQ.CEH7SSDW64TO1@disroot.org>
References: <5ED930B9.5020707@gmail.com> <SBHMBQ.CEH7SSDW64TO1@disroot.org>
Message-ID: <UKHMBQ.BXPXPARIVYJG2@disroot.org>

Silly me forgot, that gnutls wants the port appended with a : inbetwee, 
but my client still has issues

On Mo, 8 Jun, 2020 at 21:40, baschdel at disroot.org wrote:
> Greetings!
> 
> Unfortunately I can't connect with my gnu-tls based client or 
> gnutls-cli.
> 
> $ gnutls-cli --insecure gemini.marmaladefoo.com 1965
> Processed 0 CA certificate(s).
> Resolving 'gemini.marmaladefoo.com:443'...
> Connecting to '2a00:1098:0:80:1000:3b:1:1:443'...
> *** Fatal error: The TLS connection was non-properly terminated.
> 
> Have a nice day/night/evening!
> - Baschdel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/68ec55c6/attachment.htm>

From hello at matthewgraybosch.com  Mon Jun  8 22:48:14 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Mon, 8 Jun 2020 17:48:14 -0400
Subject: [ANN] New server: gemini://gemini.marmaladefoo.com/
In-Reply-To: <5ED930B9.5020707@gmail.com>
References: <5ED930B9.5020707@gmail.com>
Message-ID: <20200608174814.0a652ce418b13b3a229b546f@matthewgraybosch.com>

On Thu, 04 Jun 2020 18:34:49 +0100
Luke Emmet <luke.emmet at gmail.com> wrote:

> Hi Solderpunk and all
> 
> I'm pleased to announce I've just set up a new server:

Welcome to gemini space. Your capsule is viewable in bollux and Castor

I'll have to install GemiNaut for my wife to use if she ever gets
curious about Gemini space since she prefers Windows. :)

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From martin at no.ucant.org  Tue Jun  9 01:34:10 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 9 Jun 2020 01:34:10 +0100 (BST)
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <20200608074737.GE9769@SDF.ORG>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2006090034000.18317@pling.qwghlm.org>

On Mon, 8 Jun 2020, solderpunk wrote:

>> Are there any other
>> servers requiring client certificates that I can test against?
>
> I don't think there are yet.  But lately I've been working to add good

Yes, blizanci supports enforcement of client certificates. You can try
to get the URL:

gemini://gemini.ucant.org/restricted/example.gemini

and it'll give you a status 20 or status 60 as the case may be.

> CGI and SCGI support to Molly Brown, including passing information about
> client certs on to aps through the variables (following Sean's lead for
> now, although I need to bring up some points for discussion about this
> in the near future).  Very soon I will take advantage of this to start

My implementation is that $REMOTE_USER is set to the common name in the 
cert subject. I think this is a good idea, but I don't think it's common 
practice in the Gemini universe.

(I remain skeptical about whether SSL is the right choice - I reckon
Gemini's simplicity goal is going to run up against the practice of
trying to reuse as much existing infrastructure as possible.)

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From martin at no.ucant.org  Tue Jun  9 01:43:29 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 9 Jun 2020 01:43:29 +0100 (BST)
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200608172629.GB12292@SDF.ORG>
References: <20200608073606.GC9769@SDF.ORG>
 <C3BVYJGCCRL6.OJWQ70A7TLE4@freebsd.lan> <20200608172629.GB12292@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2006090142090.18317@pling.qwghlm.org>

On Mon, 8 Jun 2020, solderpunk wrote:

> Oh, sorry, I misunderstood!  That seems perfectly cromulent, although
> I'd be a bit wary myself of tying my content to a specific server
> (unless this convention became widely adopted).

There is a danger here of unwittingly reinventing YAML frontmatter.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From gemini at benburwell.com  Tue Jun  9 02:27:32 2020
From: gemini at benburwell.com (Ben Burwell)
Date: Mon, 08 Jun 2020 21:27:32 -0400
Subject: Adding gemini protocol to curl
In-Reply-To: <C3BVCD8CO6J0.1R441Y9NDVJ70@x1carbon>
References: <C3BVCD8CO6J0.1R441Y9NDVJ70@x1carbon>
Message-ID: <0fa7d2e1-a399-44e9-b433-4a681d32cd04@www.fastmail.com>

On 2020-06-08 at 12:41 -04:00, Julien Blanchard <julien at typed-hole.org> wrote:
> Has the repo moved? I get a 404.

Apologies, yes, I moved it over to https://git.burwell.io/mirrors/curl/.

From sean at conman.org  Tue Jun  9 03:10:06 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 8 Jun 2020 22:10:06 -0400
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <alpine.DEB.2.20.2006090034000.18317@pling.qwghlm.org>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <alpine.DEB.2.20.2006090034000.18317@pling.qwghlm.org>
Message-ID: <20200609021006.GU23998@brevard.conman.org>

It was thus said that the Great Martin Keegan once stated:
> On Mon, 8 Jun 2020, solderpunk wrote:
> 
> >CGI and SCGI support to Molly Brown, including passing information about
> >client certs on to aps through the variables (following Sean's lead for
> >now, although I need to bring up some points for discussion about this
> >in the near future).  Very soon I will take advantage of this to start
> 
> My implementation is that $REMOTE_USER is set to the common name in the 
> cert subject. I think this is a good idea, but I don't think it's common 
> practice in the Gemini universe.

Of the dozen Gemini servers (software) out there, five (a little under half)
support CGI.  Out of those, blizanci, GLV-1.12556 and getforce (a little
over half) set REMOTE_USER to the common name of the certifiate.  The other
two don't set REMOTE_USER at all.  

The CGI standard (RFC-3875) states that REMOTE_USER is set only if
authentication is used.  blizanci sets is reguardless ("" if not there),
GLV-1.12556 and jetforce only set it if a certificate is used.

MollyBrown does not set REMOTE_USER, but does set TLS_CLIENT_SUBJECT_CN if a
certificate is used.  GLV-1.12556 will also set TLS_CLIENT_SUBJECT_CN if
TLS environment variables are enabled (and a certificate is used).

One open question---what if the certificate doesn't sent a common name?  I
think a subject *is* required, but I'm unsure of the mandatory subfields of
the subject.

> (I remain skeptical about whether SSL is the right choice - I reckon
> Gemini's simplicity goal is going to run up against the practice of
> trying to reuse as much existing infrastructure as possible.)

  Okay, what encryption system would you have us poor non-cryptographer
programmers who write servers use and poorly implement?  Feel free to bring
to the table a working server and client to show us how easy it is [1].

  -spc

[1]	If this comes across as too snarky or mean, this has come up at
	least twice on this list already.  The proposers were not, to my
	knowledge, professional cryptographers, yet were quite insistent on
	their proposals were sound.  I don't think anyone else on the list
	is a professional cryptographer and thus, can't say if the proposals
	were sound or not.  And the conventional wisdom is "Don't roll your
	own cryptography!" Using an existing and widely used solution is
	better than any other option at this point in time.

	Please keep this in mind when criticizing the choice of TLS.

From martin at no.ucant.org  Tue Jun  9 03:35:35 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 9 Jun 2020 03:35:35 +0100 (BST)
Subject: [ANN] Gemini browser for iOS
In-Reply-To: <20200609021006.GU23998@brevard.conman.org>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <alpine.DEB.2.20.2006090034000.18317@pling.qwghlm.org>
 <20200609021006.GU23998@brevard.conman.org>
Message-ID: <alpine.DEB.2.20.2006090319400.18317@pling.qwghlm.org>

On Mon, 8 Jun 2020, Sean Conner wrote:

>> My implementation is that $REMOTE_USER is set to the common name in the
>> cert subject. I think this is a good idea, but I don't think it's common
>> practice in the Gemini universe.
>
> Of the dozen Gemini servers (software) out there, five (a little under half)
> support CGI.  Out of those, blizanci, GLV-1.12556 and getforce (a little
> over half) set REMOTE_USER to the common name of the certifiate.  The other
> two don't set REMOTE_USER at all.

I stand corrected.

> The CGI standard (RFC-3875) states that REMOTE_USER is set only if
> authentication is used.  blizanci sets is reguardless ("" if not there),
> GLV-1.12556 and jetforce only set it if a certificate is used.

I see no reason not to follow the spec on this point, so I have just
changed this behaviour.

>> (I remain skeptical about whether SSL is the right choice - I reckon
>> Gemini's simplicity goal is going to run up against the practice of
>> trying to reuse as much existing infrastructure as possible.)
>
> Okay, what encryption system would you have us poor non-cryptographer
> programmers who write servers use and poorly implement?  Feel free to bring
> to the table a working server and client to show us how easy it is [1].

Something similar to CurveCP. I am loath to suggest it though, because it 
associated with being a djb fanboy, which I am decidedly not. I don't have
a concrete proposal. What I'd say is that it'd be good not to hardwire SSL 
too strongly into Gemini, in case the tooling around an alternative 
improves sufficiently in the future and we'd like to swap.

> [1]	If this comes across as too snarky or mean, this has come up at

Not a problem whatsoever. I'm fairly thick-skinned.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From lazar.michael22 at gmail.com  Tue Jun  9 05:01:28 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 9 Jun 2020 00:01:28 -0400
Subject: implementing client certificate support
In-Reply-To: <20200608172451.GA12292@SDF.ORG>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
Message-ID: <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>

On Mon, Jun 8, 2020 at 1:25 PM solderpunk <solderpunk at sdf.org> wrote:
>
> On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote:
>
> > There are several other advantages to having a well designed path
> > hierarchy. It's something that I often don't spend enough time
> > thinking about up front and then I regret not doing it right later.
>
> This seems wise to me.  It's already pretty clear that associating
> client certificates with domains, as currently specced (for transient
> certs, at least) and as implemented in AV-98, is not the best idea.  It
> will inevitably cause confusion/frustration/difficulty in environments
> where multiple users share a domain (like pubnixes).  Associating them
> with paths seems the obvious solution.
>
> As the current leading implementer of client cert consumning apps, I'm
> curious how you feel about the idea of using the <META> for 6x statuses
> to convey an intended "path scope" for certs?
>
> Cheers,
> Solderpunk

I think hijacking the <META> is unnecessary for my application. I can accomplish
the same thing by sending a "30 TEMPORARY REDIRECT" to all unauthenticated
requests, and then hitting them with a 61 after they have been redirected to
the path scope. I concede that this wouldn't be *exactly* the same because the
client won't end up at the page that they originally requested. But it's
workable enough for me. And I like having the meta available for human readable
error messages.

Any complexity that we can remove from the spec surrounding client certificates
is a strong positive. I'm in favor of deprecating the 61 and 21 status codes.
Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED"
while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED".

Heck, drop client certificates from the gemini specification all together.
Judging by the lack of client support so far, it's becoming clear that either:

1. They're a pain to implement compared to the rest of the specification
2. There's not much interest in actually using them

I get the vision behind the transient client sessions and fingerprinting stuff,
and it really is a nice idea. But it's also very prescriptive and unproven.
It sticks out when compared to the rest of the spec, which mostly borrows from
tried-and-true patterns already seen in gopher/WWW.

Best,
Michael

From sean at conman.org  Tue Jun  9 05:40:07 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 00:40:07 -0400
Subject: implementing client certificate support
In-Reply-To: <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
 <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
Message-ID: <20200609044007.GV23998@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> 
> Heck, drop client certificates from the gemini specification all together.
> Judging by the lack of client support so far, it's becoming clear that either:
> 
> 1. They're a pain to implement compared to the rest of the specification
> 2. There's not much interest in actually using them

  I personally would like to keep them, if only to protect sections of a
Gemini site from general consumption.  The "transient client certificate"
idea is certainly problematic and I wouldn't mind if that concept went away
though.

  -spc

From solderpunk at SDF.ORG  Tue Jun  9 08:42:32 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 07:42:32 +0000
Subject: implementing client certificate support
In-Reply-To: <20200609044007.GV23998@brevard.conman.org>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
 <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
 <20200609044007.GV23998@brevard.conman.org>
Message-ID: <20200609074232.GA6468@SDF.ORG>

On Tue, Jun 09, 2020 at 12:40:07AM -0400, Sean Conner wrote:
> It was thus said that the Great Michael Lazar once stated:
> > 
> > Heck, drop client certificates from the gemini specification all together.
> > Judging by the lack of client support so far, it's becoming clear that either:
> > 
> > 1. They're a pain to implement compared to the rest of the specification
> > 2. There's not much interest in actually using them
> 
>   I personally would like to keep them, if only to protect sections of a
> Gemini site from general consumption.  The "transient client certificate"
> idea is certainly problematic and I wouldn't mind if that concept went away
> though.

I think it's probably a little too early in the game to interpet the
lack of client support as a lack of interest in using them.  Many people
might be holding off on implementing them in the expectation that the
spec will change/simplify - which it surely will:  I'm pretty much sold
on deprecating the transient client certificate status codes.  There's
also an obvious chicken-and-egg problem here, where client authors have
no incentive to add support until servers require it to access
compelling content.

I too would like to keep *some* client cert support, though.  I really
like the idea of being able to self-host little productivity apps for
myself which I can simply and reliably secure in an ssh-like fashion
(add my self-signed cert fingerprint to the equivalent of an
authorized_keys file).  And, yes, okay, that doesn't strictly require 6x
status codes, the server could just immeditely cut the connection if it
didn't get a cert it liked.  But it would be nice to be able to
gracefully use those apps from within an everyday client.

Mk's concern that "it'd be good not to hardwire SSL too strongly into
Gemini, in case the tooling around an alternative improves sufficiently
in the future and we'd like to swap" is a valid one, though, and one I
have (very occasionally) worried about.  If nothing else this is a good
argument to keep our use of client certificates simple and perhaps not
to make use in apps of anything beyond the cert fingerprint (i.e. don't
rely heavily on the notion of Distinguished Names for Subject and
Issuer)...

Cheers,
Solderpunk

From lenormfml at gmail.com  Mon Jun  8 06:43:27 2020
From: lenormfml at gmail.com (Frank LENORMAND)
Date: Mon, 08 Jun 2020 08:43:27 +0300
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607201049.GF15622@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607201049.GF15622@SDF.ORG>
Message-ID: <159159500782.621220.15935858084839098091@localhost.localdomain>

On Sun Jun  7 23:10:49 2020, solderpunk wrote:
> On Sun, Jun 07, 2020 at 09:38:04PM +0300, Frank LENORMAND wrote:
> > This amendment that prevents conflicts between list items and
> > *emphasised text* indirectly acknowledges that clients may not
> > render *emphasised text* verbatim.
> > 
> > Writers are no longer ensured by the standard that their text surrounded with
> > asterisks will not be decorated by the client, by extension.
> 
> Writers were *never* assured by the standard that text surrounded with
> asterisks would not be decorated by the client!
> 
> Clients that want to do that can, but it's strictly an optional extra
> out-of-spec nicety.  If anybody wants to do this, the onus is on them to
> do is smartly enough that it doesn't interfere with the specced use of
> asterisks for line items.  If they mess that up, presumably their users
> will move to an either less ambitious or better written client which
> doesn't mangle things.

The adjustment made to the bullet item format is an admission that in-line
formatting text is a thing. Writers MAY de-facto influence rendering,
otherwise you wouldn't have needed to make the amendment.

Before, writers could not reproach the clients' behaviour w.r.t to
interpreting asterisks, because nothing in the specification hinted that
it was acknowledged by the standard.

Now, clients MAY highlight \*\S.*\* patterns. The specification was amended
to make sure no ambiguous cases occur with bullet item lines.

Which means that clients who do choose to implement emphasising will be
asked for a way NOT to emphasise ALL such patterns, because the specification
never implied that was a thing, originally. But they are left with a
gaping hole, in the current state of the specification.

It follows that there should be a way for writers to escape asterisks around
words, in non pre-formatted blocks.

Regards,
-- 
Frank LENORMAND

From lenormfml at gmail.com  Mon Jun  8 09:24:44 2020
From: lenormfml at gmail.com (Frank LENORMAND)
Date: Mon, 08 Jun 2020 11:24:44 +0300
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200608072233.GB9769@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
 <20200608072233.GB9769@SDF.ORG>
Message-ID: <159160468478.691652.12797240168353485083@localhost.localdomain>

On Mon Jun  8 10:22:33 2020, solderpunk wrote:
> On Sun, Jun 07, 2020 at 06:40:33PM -0400, Matthew Graybosch wrote:
> > I use asterisks inline for emphasis because that's a habit I've taken
> > from Markdown. My understanding of the standard was that the
> > behavior of inline asterisks (as opposed to asterisks at at the
> > beginning of a line to indicate a list item) is undefined and thus
> > client-dependent.
> > 
> > If the client uses them to denote *italics* and **bold**, great. If
> > not, I figure that readers familiar with plain-text email will still
> > interpret such text accordingly. Either way, as a self-hosting writer,
> > my job is to make the words and reliably serve them. What happens on
> > the client side is none of my business.
> > 
> > My understanding of the new changes to the standard is that the
> > behavior of inline asterisks is *still* client-dependent. That's fine
> > with me as a writer, TBH. If I wanted the illusion of precise control
> > over how clients render my documents, I'd go back to HTML/CSS--or
> > pick up groff again and just post PDFs. :)
> 
> This is all correct - technically *and* ideologically. :)

How are clients supposed to render words that are censored with asterisks?

Consider:

*ssh*le

The spec was modified to make sure clients understand the above isn't a
bullet item. Therefore writers are indirectly allowed by the standard to
influence the rendering, otherwise there would have been no conflict to
address in the first place.

So clients will render the above as "sshle", which isn't the writer's
intent. Only a matter of time until you see writers start escaping asterisks
in texts:

\*ssh\*le

And now, because you've put the responsibility of dealing with a concept
that the standard implies is allowed, some clients will render the above
either verbatim, or have a concept of escaping, the latter being against
the philosophy of Gemini, from what I gather.

You can't pretend clients will fill-in the gaps by themselves if the
specification isn't pedantic about it.

Regards,
-- 
Frank LENORMAND

From hello at matthewgraybosch.com  Tue Jun  9 13:20:44 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Tue, 9 Jun 2020 08:20:44 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <159160468478.691652.12797240168353485083@localhost.localdomain>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
 <20200608072233.GB9769@SDF.ORG>
 <159160468478.691652.12797240168353485083@localhost.localdomain>
Message-ID: <20200609082044.2882fcbc7204dd31487e7c05@matthewgraybosch.com>

On Mon, 08 Jun 2020 11:24:44 +0300
Frank LENORMAND <lenormfml at gmail.com> wrote:

> How are clients supposed to render words that are censored with
> asterisks?

I can't speak for anybody else, but I stopped using asterisks for
self-censorship when I started using Markdown. Instead, I self-censor
with hyphens when I do it at all, because I can't be bothered to make
sure I've escaped every asterisk.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From pitr.vern at gmail.com  Tue Jun  9 13:29:24 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 9 Jun 2020 14:29:24 +0200
Subject: [ANN] Kristall Small-Internet Browser
In-Reply-To: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
References: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
Message-ID: <CAG-mZ3jQ-6aiKaco6tZTb5XM0ftZQ3Hd7kBi1ebNhOg99UUJSA@mail.gmail.com>

I really like auto-theming based on domain. Would you be ok if I used the
same algorithm in my iOS client? https://github.com/pitr/gemini-ios

On Sun, Jun 7, 2020 at 01:56 Felix Quei?ner <felix at masterq32.de> wrote:

> Hello Community!
>
> In the last week, i hacked together a new Gemini client:
>
>   Kristall
>
> It started as a pure Gemini + text/gemini client, but i soon started to
> implement more features and now it supports more than initially planned.
>
> Some features:
>
> * First class cross-platform with Qt5
> * Fetches several protocols (gemini, http, https, ...)
> * Serves text and image documents, including text/gemini, markdown and
> simplified HTML
> * Stylable content display
> * All the usability features you want (favourites, navigation history,
> multiple tabs, ...)
>
> My focus for this project was user experience and following the basic
> gemini ideas (user first, server second). So the client provides you
> with with a lot of convenience features like site styling (even
> experimental auto-theming based on the domain name), a favourite list,
> browsing history, ...)
>
> Notable missing features right now are:
> * More protocols (planned atm are gopher, finger and probably FTP)
> * Correct TLS handling
>
> Read a bit more about Kristall here:
> => gemini://random-projects.net/blog/2020-06-07-kristall.gemini
>
> And fetch the source code and build it here (also Screenshots!)
> => https://github.com/MasterQ32/kristall
>
> I would be happy about bug reports or improvement ideas, here on the
> mailing list, IRC or GitHub!
>
> Regards
> - xq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200609/32a4f0ac/attachment.htm>

From acdw at acdw.net  Tue Jun  9 13:34:55 2020
From: acdw at acdw.net (Case Duckworth)
Date: Tue, 09 Jun 2020 12:34:55 +0000
Subject: =?UTF-8?Q?Re:_[SPEC-CHANGE]_lang_parameter, _minor_line_type_changes,
 _cla?= =?UTF-8?Q?rifications...?=
In-Reply-To: <159160468478.691652.12797240168353485083@localhost.localdomain>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
 <20200608072233.GB9769@SDF.ORG>
 <159160468478.691652.12797240168353485083@localhost.localdomain>
Message-ID: <0f2feefc-4b18-4aec-a23f-a842d9104504@www.fastmail.com>

On Mon, Jun 8, 2020, at 8:24 AM, Frank LENORMAND wrote:

> How are clients supposed to render words that are censored with asterisks?
> 
> Consider:
> 
> *ssh*le
> 
> The spec was modified to make sure clients understand the above isn't a
> bullet item. Therefore writers are indirectly allowed by the standard to
> influence the rendering, otherwise there would have been no conflict to
> address in the first place.
> 
> So clients will render the above as "sshle", which isn't the writer's
> intent. Only a matter of time until you see writers start escaping asterisks
> in texts:
> 
> \*ssh\*le
> 
> And now, because you've put the responsibility of dealing with a concept
> that the standard implies is allowed, some clients will render the above
> either verbatim, or have a concept of escaping, the latter being against
> the philosophy of Gemini, from what I gather.
> 
> You can't pretend clients will fill-in the gaps by themselves if the
> specification isn't pedantic about it.

AFAICT most clients do nothing with in-text formatting, and in fact if the document type is text/gemini they *should* not. text/gemini *only* specifies the 6 line-types for possibilities of special rendering, which means that your example of '*ssh*le' will render exactly as '*ssh*le' -- no escaping needed. If the mimetype is text/markdown, clients *could* render it differently, but text/markdown has its own escaping rules that a client would follow.

-- Case (acdw)

From felix at masterq32.de  Tue Jun  9 17:17:04 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 9 Jun 2020 18:17:04 +0200
Subject: [ANN] Kristall Small-Internet Browser
In-Reply-To: <CAG-mZ3jQ-6aiKaco6tZTb5XM0ftZQ3Hd7kBi1ebNhOg99UUJSA@mail.gmail.com>
References: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
 <CAG-mZ3jQ-6aiKaco6tZTb5XM0ftZQ3Hd7kBi1ebNhOg99UUJSA@mail.gmail.com>
Message-ID: <7cf6e9b3-6839-a268-926b-c5ece919bb03@masterq32.de>

> I really like auto-theming based on domain. 
Thanks!

> Would you be ok if I used the
> same algorithm in my iOS client? https://github.com/pitr/gemini-ios
No, absolutly not! *laughing* /s

Yes, please do! It works surprisingly well, but will probably be
improved in the future with some sanity and contrast checks, so check it
out now and then!

Regards
- xq

From solderpunk at SDF.ORG  Tue Jun  9 19:16:57 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 18:16:57 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <159160468478.691652.12797240168353485083@localhost.localdomain>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
 <20200608072233.GB9769@SDF.ORG>
 <159160468478.691652.12797240168353485083@localhost.localdomain>
Message-ID: <20200609181657.GA13153@SDF.ORG>

On Mon, Jun 08, 2020 at 11:24:44AM +0300, Frank LENORMAND wrote:
 
> How are clients supposed to render words that are censored with asterisks?

However they like!  But "verbatim" seems like the only sensible option.

> The spec was modified to make sure clients understand the above isn't a
> bullet item. Therefore writers are indirectly allowed by the standard to
> influence the rendering, otherwise there would have been no conflict to
> address in the first place.

I really don't follow you here.  Writers are of course *allowed* to put
asterisks around their words if they want to but this doesn't imply that
they should expect clients to do anything in particular with that
information.  People use asterisks to emphasise words when writing
plain text content for Gopher where they know for sure that clients
won't do anything with it.

> So clients will render the above as "sshle", which isn't the writer's
> intent.

What on Earth makes you think clients will render that as sshle?  I
wouldn't use a client that did that.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jun  9 19:39:23 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 18:39:23 +0000
Subject: implementing client certificate support
In-Reply-To: <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
 <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
Message-ID: <20200609183923.GB13153@SDF.ORG>

On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:
 
> Any complexity that we can remove from the spec surrounding client certificates
> is a strong positive. I'm in favor of deprecating the 61 and 21 status codes.

I was thinking of dropping 21 and "softening" 61 to mean something like
"you need a certificate to access this resource, and the server is
signalling that it's okay to use something temporary/disposable" - i.e.
to make it clear this is not an Astrobotany-style application where
losing your key/cert pair means forever losing access to your account.
Clients can handle this however they want - some clients will implement
good support for transient certs which never hit the disk, and will brag
about that, and users who really care will use them.

In general, I was thinking of just having a bunch of 6x codes which all
mean "you need a cert to get in here" but with different hints as to
what is expected - something you can generate yourself on the spot and
dispose of when you like, something you can generate yourself on the spot
and should take care to keep hold of (astrobotany style), or something
pre-approved by the admin (which might mean a CSR process, or just a
fingerprint whitelisting).  No prescribed behaviour for any of them,
clients can give users as many or as few options for dealing with them as
the authors see fit, but at least this way they can convey enough
information to the user for them to make an informed choice.

> Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED"
> while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED".

I expect Sean to object to this...
 
> Judging by the lack of client support so far, it's becoming clear that either:
> 
> 1. They're a pain to implement compared to the rest of the specification

This is true.  I may amend the spec the explicitly call them an advanced
and optional feature.  People should not feel ashamed of writing a
client that just opts out of the whole thing.  To some extent the
existence of good clients which do this will act as a defence against
people putting stuff behind certificates without very good reason.

> It sticks out when compared to the rest of the spec, which mostly borrows from
> tried-and-true patterns already seen in gopher/WWW.

I like to think of at least the pre-approved cert workflow as
tried-and-true from ssh.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Tue Jun  9 19:58:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 9 Jun 2020 20:58:04 +0200
Subject: authority's userinfo?
Message-ID: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>

How is gemini meant to deal with authority's userinfo? 

E.g. 

gemini://username:password at mozz.us/
gemini://username at mozz.us/

Orthodox? 

If so, how does the server communicate authentication failure back to the client?  

Thoughts?

From peteyboy at sdf.org  Tue Jun  9 20:10:15 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Tue, 09 Jun 2020 12:10:15 -0700
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <mailman.129.1591706119.529.gemini@lists.orbitalfox.eu>
References: <mailman.129.1591706119.529.gemini@lists.orbitalfox.eu>
Message-ID: <9EA53F35-045D-4EC5-93C8-64EFB4472223@sdf.org>



>The adjustment made to the bullet item format is an admission that
>in-line
>formatting text is a thing. 

I don't see it that way. It's simply an admission that people use * in plaintext for emphasis, and that there is a pretty straightforward way to make a markup that shouldn't interfere with people's text. It's really only important if people are turning existing files into gmi files, I would think.  It fits the Gemini "philosophy" of determining the line type unambiguously in first 3 chars.

I've dreamed of a wiki-native protocol as well, but Gemini ain't trying to be it. There are several servers as I understand that just serve markdown, too. You can use one of those, as was suggested.



-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200609/3e5c211e/attachment.htm>

From petite.abeille at gmail.com  Tue Jun  9 20:46:56 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 9 Jun 2020 21:46:56 +0200
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
Message-ID: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>

"A client SHOULD NOT send the fragment part of a URL to the server."
-- Sean Conner, Resource request format for Gemini' states, circa 2019-08-01
https://portal.mozz.us/gemini/gemini.conman.org/gRFC/0002

Such restriction is not reflected in the spec itself.

At the same time, the spec mentions header lines as "machine-readable representation of the internal structure of the document".

Could one reflect such structure using fragments?

E.g.:

gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line+types

Part of the gemini canon?

From solderpunk at SDF.ORG  Tue Jun  9 21:00:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 20:00:19 +0000
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
Message-ID: <20200609200019.GC13153@SDF.ORG>

On Tue, Jun 09, 2020 at 09:46:56PM +0200, Petite Abeille wrote:
> "A client SHOULD NOT send the fragment part of a URL to the server."
> -- Sean Conner, Resource request format for Gemini' states, circa 2019-08-01
> https://portal.mozz.us/gemini/gemini.conman.org/gRFC/0002
> 
> Such restriction is not reflected in the spec itself.
> 
> At the same time, the spec mentions header lines as "machine-readable representation of the internal structure of the document".
> 
> Could one reflect such structure using fragments?
> 
> E.g.:
> 
> gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line+types
> 
> Part of the gemini canon?

It's certainly something people have suggested.  I guess to make it work
reliably would require a very strict specification of how to transform
headings into fragments, which sounds fiddly and dull...

Either that, or we allow just numeric fragments like 3.2, which the
client is supposed to map to the second subsection of the third section.

Sounds like a pain to implement in terminal clients, at least.

Cheers,
Solderpunk


From hello at matthewgraybosch.com  Tue Jun  9 21:02:57 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Tue, 9 Jun 2020 16:02:57 -0400
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
Message-ID: <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>

On Tue, 9 Jun 2020 21:46:56 +0200
Petite Abeille <petite.abeille at gmail.com> wrote:

> gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line
> +types
> 
> Part of the gemini canon?

Why send the #5.4+Core+line+types part at all? Can't a client send the
URL without the anchor tag, and then use the anchor tag to automatically
scroll to the specified heading?

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From petite.abeille at gmail.com  Tue Jun  9 21:04:53 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 9 Jun 2020 22:04:53 +0200
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200607162723.GC15622@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
Message-ID: <BDB92ECC-AFB6-449E-8FBE-D3C8E54E98C7@gmail.com>



> On Jun 7, 2020, at 18:27, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> If your client has been automatically making network connections you
> MUST remove this behaviour and atone for your sins!

Tuning down the zealotry MAY be beneficial.


From solderpunk at SDF.ORG  Tue Jun  9 21:09:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 20:09:12 +0000
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
Message-ID: <20200609200912.GD13153@SDF.ORG>

On Tue, Jun 09, 2020 at 04:02:57PM -0400, Matthew Graybosch wrote:
> On Tue, 9 Jun 2020 21:46:56 +0200
> Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> > gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line
> > +types
> > 
> > Part of the gemini canon?
> 
> Why send the #5.4+Core+line+types part at all? Can't a client send the
> URL without the anchor tag, and then use the anchor tag to automatically
> scroll to the specified heading?

Oh, sure, no need to send it to the server.  Sorry, I missed the that
was what Sean was originally talking about.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Tue Jun  9 21:12:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 9 Jun 2020 22:12:43 +0200
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
Message-ID: <5BE3488E-8D25-4984-9870-4A97DDE949DB@gmail.com>



> On Jun 9, 2020, at 22:02, Matthew Graybosch <hello at matthewgraybosch.com> wrote:
> 
>> gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line
>> +types
>> 
>> Part of the gemini canon?
> 
> Why send the #5.4+Core+line+types part at all? Can't a client send the
> URL without the anchor tag, and then use the anchor tag to automatically
> scroll to the specified heading?

Perhaps. How would that work?

=> gemini://gemini.circumlunar.space/docs/specification.gmi#5.4+Core+line+types
vs.
=> gemini://gemini.circumlunar.space/docs/specification.gmi

With the first link, a client could indeed scroll to the relevant header, if so inclined.

How does the second scenario works?


From petite.abeille at gmail.com  Tue Jun  9 21:20:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 9 Jun 2020 22:20:12 +0200
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <20200609200912.GD13153@SDF.ORG>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
 <20200609200912.GD13153@SDF.ORG>
Message-ID: <F83E1084-B13D-4E5F-8BF3-B92E4EBA9FF7@gmail.com>



> On Jun 9, 2020, at 22:09, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>> Why send the #5.4+Core+line+types part at all? Can't a client send the
>> URL without the anchor tag, and then use the anchor tag to automatically
>> scroll to the specified heading?
> 
> Oh, sure, no need to send it to the server.  Sorry, I missed the that
> was what Sean was originally talking about.

Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification.

Still, no harm down if the fragment hit the server, right? Or?


From tomasino at lavabit.com  Tue Jun  9 21:20:57 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 9 Jun 2020 20:20:57 +0000
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <5BE3488E-8D25-4984-9870-4A97DDE949DB@gmail.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
 <5BE3488E-8D25-4984-9870-4A97DDE949DB@gmail.com>
Message-ID: <cd694483-5d10-51a1-6c40-3d14302643f2@lavabit.com>

On 6/9/20 8:12 PM, Petite Abeille wrote:
> Perhaps. How would that work?
> 
> => gemini://gemini.circumlunar.space/docs/specification.gmi#5.4+Core+line+types
> vs.
> => gemini://gemini.circumlunar.space/docs/specification.gmi
> 
> With the first link, a client could indeed scroll to the relevant header, if so inclined.
> 
> How does the second scenario works?

Wouldn't it be infinitely easier and less vague to just use a line
number for the fragment? Everything else is line based, so it fits that
mindset well. It's also less likely to run into issues when someone has
odd characters or multi-character emoji in a heading.


From felix at masterq32.de  Tue Jun  9 21:23:00 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 9 Jun 2020 22:23:00 +0200
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <cd694483-5d10-51a1-6c40-3d14302643f2@lavabit.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
 <5BE3488E-8D25-4984-9870-4A97DDE949DB@gmail.com>
 <cd694483-5d10-51a1-6c40-3d14302643f2@lavabit.com>
Message-ID: <e26fade3-a40a-ca6e-424a-73052eda3a7e@masterq32.de>

> Wouldn't it be infinitely easier and less vague to just use a line
> number for the fragment? Everything else is line based, so it fits that
> mindset well. It's also less likely to run into issues when someone has
> odd characters or multi-character emoji in a heading.

Any continuous numbering has the problem that the content needs to be
perfectly static. No matter if you use line numbers or heading index.

If I insert an introduction, a new sentence, update a date, ? the index
will break

From luke at marmaladefoo.com  Tue Jun  9 21:23:14 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 09 Jun 2020 21:23:14 +0100
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <20200609200019.GC13153@SDF.ORG>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609200019.GC13153@SDF.ORG>
Message-ID: <5EDFEFB2.5020608@marmaladefoo.com>



On 09-Jun-2020 21:00, solderpunk wrote:
> On Tue, Jun 09, 2020 at 09:46:56PM +0200, Petite Abeille wrote:
>> "A client SHOULD NOT send the fragment part of a URL to the server."
>> -- Sean Conner, Resource request format for Gemini' states, circa 2019-08-01
>> https://portal.mozz.us/gemini/gemini.conman.org/gRFC/0002
>>
>> Such restriction is not reflected in the spec itself.
>>
>> At the same time, the spec mentions header lines as "machine-readable representation of the internal structure of the document".
>>
>> Could one reflect such structure using fragments?
>>
>> E.g.:
>>
>> gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line+types
>>
>> Part of the gemini canon?
> It's certainly something people have suggested.  I guess to make it work
> reliably would require a very strict specification of how to transform
> headings into fragments, which sounds fiddly and dull...
>
> Either that, or we allow just numeric fragments like 3.2, which the
> client is supposed to map to the second subsection of the third section.
>

The canonical way to do this in Markdown (and more widely on the web) 
seems to be lowercase kebab case of the alphabetic content, with single 
hyphens

So it would be

gemini://gemini.circumlunar.space/docs/specification.gm#core-line-types

This is much more robust than having an offset index like 3.2, which will break all the links if you add a new section 1 to the page. I will probably implement this scheme in GemiNaut when I get round to it. The case insensitivity means you can change your mind about title casing on the heading and things still generally work fine.

I think the behaviour can be the same as on the web where the fragment behaviour degrades well. If there is no such fragment, or the client does not support them, there is no scrolling to the offset.

I think it is just a matter for the client authors to agree on (where they implement it). If it is in the spec, or accompanying guidance that might be nice, but not essential at the moment.

Best wishes

  - Luke


From pitr.vern at gmail.com  Tue Jun  9 21:23:55 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 9 Jun 2020 22:23:55 +0200
Subject: implementing client certificate support
In-Reply-To: <20200609183923.GB13153@SDF.ORG>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
 <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
 <20200609183923.GB13153@SDF.ORG>
Message-ID: <CAG-mZ3jBb09eDqMeDWudEwpUKDwhUywMSs3UQkkoxPEYbS6A4w@mail.gmail.com>

My two cents: I don?t understand why server gets to decide if user?s
certificate is transient or not. I as a user should make that decision. If
they want to lose access to their Astro plant, that?s their decision. In my
opinion there should just be one 6X status code, to request that user
retries with a certificate. If user didn?t use one, meta field should
explain why it is needed. If user used one - meta should explain why it was
declined (expiry, invalid, etc)

Using this logic, I would say status code 21 is similarly unnecessary. User
should be able to decide if they want to stop using client certificate.
AV-98 for instance allows user to do that (so does my iOS client). It seems
to me that status 21 tries to implement a logout functionality from the
web, where users have a jarfull of cookies and might not be able to delete
the right one. In Gemini on the other hand, it can be a simple toggle
switch.

On Tue, Jun 9, 2020 at 20:39 solderpunk <solderpunk at sdf.org> wrote:

> On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:
>
> > Any complexity that we can remove from the spec surrounding client
> certificates
> > is a strong positive. I'm in favor of deprecating the 61 and 21 status
> codes.
>
> I was thinking of dropping 21 and "softening" 61 to mean something like
> "you need a certificate to access this resource, and the server is
> signalling that it's okay to use something temporary/disposable" - i.e.
> to make it clear this is not an Astrobotany-style application where
> losing your key/cert pair means forever losing access to your account.
> Clients can handle this however they want - some clients will implement
> good support for transient certs which never hit the disk, and will brag
> about that, and users who really care will use them.
>
> In general, I was thinking of just having a bunch of 6x codes which all
> mean "you need a cert to get in here" but with different hints as to
> what is expected - something you can generate yourself on the spot and
> dispose of when you like, something you can generate yourself on the spot
> and should take care to keep hold of (astrobotany style), or something
> pre-approved by the admin (which might mean a CSR process, or just a
> fingerprint whitelisting).  No prescribed behaviour for any of them,
> clients can give users as many or as few options for dealing with them as
> the authors see fit, but at least this way they can convey enough
> information to the user for them to make an informed choice.
>
> > Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE
> REJECTED"
> > while you're at it, they can be subsumed by "63 CERTIFICATE NOT
> ACCEPTED".
>
> I expect Sean to object to this...
>
> > Judging by the lack of client support so far, it's becoming clear that
> either:
> >
> > 1. They're a pain to implement compared to the rest of the specification
>
> This is true.  I may amend the spec the explicitly call them an advanced
> and optional feature.  People should not feel ashamed of writing a
> client that just opts out of the whole thing.  To some extent the
> existence of good clients which do this will act as a defence against
> people putting stuff behind certificates without very good reason.
>
> > It sticks out when compared to the rest of the spec, which mostly
> borrows from
> > tried-and-true patterns already seen in gopher/WWW.
>
> I like to think of at least the pre-approved cert workflow as
> tried-and-true from ssh.
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200609/6c95230c/attachment-0001.htm>

From solderpunk at SDF.ORG  Tue Jun  9 21:26:10 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 20:26:10 +0000
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <F83E1084-B13D-4E5F-8BF3-B92E4EBA9FF7@gmail.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
 <20200609200912.GD13153@SDF.ORG>
 <F83E1084-B13D-4E5F-8BF3-B92E4EBA9FF7@gmail.com>
Message-ID: <20200609202610.GF13153@SDF.ORG>

On Tue, Jun 09, 2020 at 10:20:12PM +0200, Petite Abeille wrote:
 
> Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification.
> 
> Still, no harm down if the fragment hit the server, right? Or?
> 

I guess robust servers *should* tolerate this without throwing an error.

Cheers,
Solderpunk

From luke at marmaladefoo.com  Tue Jun  9 21:29:20 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 09 Jun 2020 21:29:20 +0100
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <20200609202610.GF13153@SDF.ORG>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
 <20200609200912.GD13153@SDF.ORG>
 <F83E1084-B13D-4E5F-8BF3-B92E4EBA9FF7@gmail.com>
 <20200609202610.GF13153@SDF.ORG>
Message-ID: <5EDFF120.6090505@marmaladefoo.com>



On 09-Jun-2020 21:26, solderpunk wrote:
> On Tue, Jun 09, 2020 at 10:20:12PM +0200, Petite Abeille wrote:
>
>> Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification.
>>
>> Still, no harm down if the fragment hit the server, right? Or?
>>
> I guess robust servers *should* tolerate this without throwing an error.
>
> Cheers,
> Solderpunk

Yes servers should definitely ignore any such fragment, which should 
*not* be sent to the server.

The query part of the URI is for server processing, the fragment is 
always client side only as far as I understand it.

https://en.wikipedia.org/wiki/Fragment_identifier

  - L

From solderpunk at SDF.ORG  Tue Jun  9 21:45:27 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 20:45:27 +0000
Subject: implementing client certificate support
In-Reply-To: <CAG-mZ3jBb09eDqMeDWudEwpUKDwhUywMSs3UQkkoxPEYbS6A4w@mail.gmail.com>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
 <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
 <20200609183923.GB13153@SDF.ORG>
 <CAG-mZ3jBb09eDqMeDWudEwpUKDwhUywMSs3UQkkoxPEYbS6A4w@mail.gmail.com>
Message-ID: <20200609204527.GG13153@SDF.ORG>

On Tue, Jun 09, 2020 at 10:23:55PM +0200, Peter Vernigorov wrote:

> My two cents: I don?t understand why server gets to decide if user?s
> certificate is transient or not. I as a user should make that decision.

Definitely agree.  I didn't mean for any of this to imply the server is
"in charge".  The whole reason client certs are so great as a cookie
alternative is that they put the power squarely in the user's hands!

The problem, I think, is that users need to be able to *make* the
decision on an informed basis.  If all I know is "the server needs a
cert", I will probably play it cautious and generate a transient one.
But if it turns out what the server wanted it for was to permanently tie
that cert's fingerprint to my ID, and I decide I quite like the service,
that's kind of a pain.  Unless the server implements a potentially
fiddly re-association feature.

Of course, servers could explain what the cert should be used for (and
should!) in the <META> (unless we repurpose that for a path, which I
still think is worth thinking about), but some users may not understand
the implications.  So I thought it would be nice for the server to be
able to provide a "hint" to inform the decision.  Of *course* the user
should always be able to make up their own mind.

I guess this problem goes away in a client design where all certs are
generated as transient by default but users can then opt to mark a
particular cert as persistent?  Hmm...

Cheers,
Solderpunk

From sean at conman.org  Tue Jun  9 21:46:00 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 16:46:00 -0400
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200609181657.GA13153@SDF.ORG>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
 <20200608072233.GB9769@SDF.ORG>
 <159160468478.691652.12797240168353485083@localhost.localdomain>
 <20200609181657.GA13153@SDF.ORG>
Message-ID: <20200609204600.GW23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Mon, Jun 08, 2020 at 11:24:44AM +0300, Frank LENORMAND wrote:
>  
> > How are clients supposed to render words that are censored with asterisks?
> 
> However they like!  But "verbatim" seems like the only sensible option.
> 
> > The spec was modified to make sure clients understand the above isn't a
> > bullet item. Therefore writers are indirectly allowed by the standard to
> > influence the rendering, otherwise there would have been no conflict to
> > address in the first place.
> 
> I really don't follow you here.  Writers are of course *allowed* to put
> asterisks around their words if they want to but this doesn't imply that
> they should expect clients to do anything in particular with that
> information.  People use asterisks to emphasise words when writing
> plain text content for Gopher where they know for sure that clients
> won't do anything with it.

  A graphical Gemini browser *might* render text between astericks with
italicised or bold text, to *emphasize* the emphasis that astericks imply.
A text based Gemini browser might instead decide to bold or recolor the
text, again to emphasize the emphasis.

  -spc

From tomasino at lavabit.com  Tue Jun  9 21:51:20 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 9 Jun 2020 20:51:20 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200609204600.GW23998@brevard.conman.org>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
 <20200608072233.GB9769@SDF.ORG>
 <159160468478.691652.12797240168353485083@localhost.localdomain>
 <20200609181657.GA13153@SDF.ORG> <20200609204600.GW23998@brevard.conman.org>
Message-ID: <c9956bfb-df4a-7fe0-1ebe-83812cf10e81@lavabit.com>

On 6/9/20 8:46 PM, Sean Conner wrote:
>   A graphical Gemini browser *might* render text between astericks with
> italicised or bold text, to *emphasize* the emphasis that astericks imply.
> A text based Gemini browser might instead decide to bold or recolor the
> text, again to emphasize the emphasis.
> 
>   -spc

I'm reading this in thunderbird, which has chosen to bold your examples
of emphatic text. It does not remove the asterisks, though. Also, if I
_underline_ a word, it renders it as such, but preserves the characters.
If clients are looking for good real-world examples to emulate when
going above-and-beyond the spec, I'd point there.


From solderpunk at SDF.ORG  Tue Jun  9 21:56:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 9 Jun 2020 20:56:29 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <20200609204600.GW23998@brevard.conman.org>
References: <20200607162723.GC15622@SDF.ORG>
 <159155508489.621220.8460141151809604634@localhost.localdomain>
 <20200607184033.53737a99ef0e53048273a293@matthewgraybosch.com>
 <20200608072233.GB9769@SDF.ORG>
 <159160468478.691652.12797240168353485083@localhost.localdomain>
 <20200609181657.GA13153@SDF.ORG>
 <20200609204600.GW23998@brevard.conman.org>
Message-ID: <20200609205629.GH13153@SDF.ORG>

On Tue, Jun 09, 2020 at 04:46:00PM -0400, Sean Conner wrote:
> 
>   A graphical Gemini browser *might* render text between astericks with
> italicised or bold text, to *emphasize* the emphasis that astericks imply.
> A text based Gemini browser might instead decide to bold or recolor the
> text, again to emphasize the emphasis.

This is all fine.  I would gently advise that clients which do this
*should* provide a quick and easy way to toggle this off, in case it
yields unpleasant results with some documents.

Cheers,
Solderpunk

From sean at conman.org  Tue Jun  9 21:59:52 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 16:59:52 -0400
Subject: implementing client certificate support
In-Reply-To: <20200609183923.GB13153@SDF.ORG>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
 <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
 <20200609183923.GB13153@SDF.ORG>
Message-ID: <20200609205951.GX23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:
>  
> > Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED"
> > while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED".
> 
> I expect Sean to object to this...

  Not too terribly.  I only added the bunch of codes to help with debugging
a rejection.  I would accept the following:

	60	client certificate required
	61	client certificate invalid (or expired)
	62	client certificate rejected

  Just saying "bad certificate" isn't actionable enough for the user.  Why
is it bad?  Has it expired?  Rejected?  What?  I NEED TO KNOW!

  -spc

From tadeusz at sosnierz.com  Tue Jun  9 22:06:21 2020
From: tadeusz at sosnierz.com (Tadeusz Sosnierz)
Date: Tue, 09 Jun 2020 23:06:21 +0200 (CEST)
Subject: implementing client certificate support
In-Reply-To: <20200609205951.GX23998@brevard.conman.org>
Message-ID: <E1jilRy-0002zx-Bx@rmmprod07.runbox>


2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>:
> Just saying "bad certificate" isn't actionable enough for the user. Why
> is it bad? Has it expired? Rejected? What? I NEED TO KNOW!

Isn't that something that could go in the "meta" part of the response, or the content itself?

The specificness of 6x codes is something I find quite puzzling,
especially considering how carefully select the other codes are.

Especially 64. When does that even come into play?

(Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions :))

--
tadzik

From vanevander at mayvaneday.art  Tue Jun  9 22:13:21 2020
From: vanevander at mayvaneday.art (vanevander at mayvaneday.art)
Date: Tue, 9 Jun 2020 23:13:21 +0200 (CEST)
Subject: Kristall browser
Message-ID: <M9PvXla--3-2@mayvaneday.art>

I don't use Github, and I'm new to mailing lists, so forgive me if this isn't the right place.

A few days ago, this list informed me of the Kristall graphical browser. I have managed to get it running in Haiku and have written a short tutorial on how to compile and install it.

(gemini) gemini://gemini.mayvaneday.art/archive/tutorials/kristall-haiku.html <http://gemini.mayvaneday.art/archive/tutorials/kristall-haiku.html>?(you might get a hostname certificate error)
(https)?https://mayvaneday.art/archive/tutorials/kristall-haiku.html
(zeronet)?https://zeronet.link/1MeeJWbbQHArbqD6UUHSjh9EVycvnTUBFa/archive/tutorials/kristall-haiku.html

Please be advised my server is IPv6-only.

- vclv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200609/298f7347/attachment-0001.htm>

From sean at conman.org  Tue Jun  9 22:13:35 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 17:13:35 -0400
Subject: implementing client certificate support
In-Reply-To: <E1jilRy-0002zx-Bx@rmmprod07.runbox>
References: <20200609205951.GX23998@brevard.conman.org>
 <E1jilRy-0002zx-Bx@rmmprod07.runbox>
Message-ID: <20200609211335.GY23998@brevard.conman.org>

It was thus said that the Great Tadeusz Sosnierz once stated:
> 
> 2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>:
> > Just saying "bad certificate" isn't actionable enough for the user. Why
> > is it bad? Has it expired? Rejected? What? I NEED TO KNOW!
> 
> Isn't that something that could go in the "meta" part of the response, or
> the content itself?

  It could, but what does it mean when I get back "n? ghlactar le deimhni?",
"di?lta?odh deimhni? sa todhcha?", or "di?lta?odh deimhni? caite"?  Not
everyone speaks English and a numeric response is unambiguous.

> The specificness of 6x codes is something I find quite puzzling,
> especially considering how carefully select the other codes are.
> 
> Especially 64. When does that even come into play?

  Time skew between the client and server on a freshly minted certificate.  

> (Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions :))

  Hello, and no, your questions aren't silly.

  -spc

From felix at masterq32.de  Tue Jun  9 22:17:26 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 9 Jun 2020 23:17:26 +0200
Subject: Kristall browser
In-Reply-To: <M9PvXla--3-2@mayvaneday.art>
References: <M9PvXla--3-2@mayvaneday.art>
Message-ID: <054b184c-0261-0478-52ab-5a179467961c@masterq32.de>

> I don't use Github, and I'm new to mailing lists, so forgive me if this isn't the right place.
I think it's okay :)
> A few days ago, this list informed me of the Kristall graphical browser. I have managed to get it running in Haiku and have written a short tutorial on how to compile and install it.
This sounds freakin' awesome!

> Please be advised my server is IPv6-only.
And this is sad. Can you send me the files via mail so i can read them?
My ISP doesn't serve IPv6...

Regards
- xq

From sean at conman.org  Wed Jun 10 00:14:04 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 19:14:04 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200608074737.GE9769@SDF.ORG>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
Message-ID: <20200609231403.GZ23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> (following Sean's lead for now, although I need to bring up some points
> for discussion about this in the near future).

  So I have two CGI scripts set up.  Both are in a "protected" area of the
server (on my development machine) that requires a client certificate.  One
receives *just* the RFC-3875 defined variables:

AUTH_TYPE=Certificate
GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin
GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
GEMINI_URL_PATH=/cgi-bin/beta/foobar
PATH_INFO=/foobar
PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar
QUERY_STRING=one=1&two=2
REMOTE_ADDR=::ffff:192.168.1.10
REMOTE_HOST=::ffff:192.168.1.10
REMOTE_USER=Sean Conner
REQUEST_METHOD=
SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./beta
SERVER_NAME=lucy.roswell.area51
SERVER_PORT=1965
SERVER_PROTOCOL=GEMINI
SERVER_SOFTWARE=GLV-1.12556/1

  The AUTH_TYPE is "Certificate".  I choose that form because I'm following
the form of HTTP (RFC-2617, updated by RFC-7616) which defines "Basic" and
"Digest".  I know of another Gemini server that sets this to "CERTIFICATE".

  The REMOTE_USER is taken from the Common Name of the certificate subject. 
Right now, if a common name is not supplied, it won't be set (quirk of the
Lua language---I should probably do something about that).  I suppose as a
backup the certificate subject could be used, or perhaps the empty string
(allowed by the RFC---I just checked).

  The rest of the variables I've discussed elsewhere.

  So here's what happens when I enable TLS variables to be set (it's an
option for GLV-1.12556):

AUTH_TYPE=Certificate
GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin
GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/alpha/foobar?one=1&two=2
GEMINI_URL_PATH=/cgi-bin/alpha/foobar
PATH_INFO=/foobar
PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar
QUERY_STRING=one=1&two=2
REMOTE_ADDR=::ffff:192.168.1.10
REMOTE_HOST=::ffff:192.168.1.10
REMOTE_USER=Sean Conner
REQUEST_METHOD=
SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./alpha
SERVER_NAME=lucy.roswell.area51
SERVER_PORT=1965
SERVER_PROTOCOL=GEMINI
SERVER_SOFTWARE=GLV-1.12556/1
TLS_CIPHER=ECDHE-RSA-CHACHA20-POLY1305
TLS_CLIENT_HASH=SHA256:0eab5867fcb5b30046120e4c29562e31b88c51b167b091aee4b4e66221645a20
TLS_CLIENT_ISSUER=/C=US/ST=FL/O=Conman Laboratories/OU=Security Division/CN=Conman Laboratories CA/emailAddress=ca at conman.org
TLS_CLIENT_ISSUER_C=US
TLS_CLIENT_ISSUER_CN=Conman Laboratories CA
TLS_CLIENT_ISSUER_O=Conman Laboratories
TLS_CLIENT_ISSUER_OU=Security Division
TLS_CLIENT_ISSUER_ST=FL
TLS_CLIENT_ISSUER_emailAddress=ca at conman.org
TLS_CLIENT_NOT_AFTER=2020-06-18T23:54:56Z
TLS_CLIENT_NOT_BEFORE=2019-06-19T23:54:56Z
TLS_CLIENT_REMAIN=9
TLS_CLIENT_SUBJECT=/C=US/ST=FL/L=Boca Raton/CN=Sean Conner/emailAddress=sean at conman.org
TLS_CLIENT_SUBJECT_C=US
TLS_CLIENT_SUBJECT_CN=Sean Conner
TLS_CLIENT_SUBJECT_L=Boca Raton
TLS_CLIENT_SUBJECT_ST=FL
TLS_CLIENT_SUBJECT_emailAddress=sean at conman.org
TLS_VERSION=TLSv1.2

  I modeled this behavior from Apache.  Apache uses the prefix "SSL_" for
these, I decided to change them to "TLS_".  I included most of what Apache
sends, but decided against the following fields:

	SSL_CIPHER_ALGKEYSIZE		no way to get this via libtls
	SSL_CIPHER_EXPORT			"
	SSL_CIPHER_USERKEYSIZE			"
	SSL_CLIENT_A_KEY			"
	SSL_CLIENT_A_SIG			"
	SSL_CLIENT_CERT			a copy of the client certificate
	SSL_CLIENT_CERT_CHAIN_n		one (of n) certificates in the
					client certificate chain
	SSL_CLIENT_M_SERIAL		no way to get this via libtls
	SSL_CLIENT_M_VERSION			"
	SSL_COMPRESS_METHOD			"
	SSL_SECURE_RENEG			"
	SSL_SERVER_A_KEY			"
	SSL_SERVER_A_SIG			"
	SSL_SERVER_CERT			a copy of the server certificate
	SSL_SERVER_M_SERIAL		no way to get this via libtls
	SSL_SERVER_M_VERSION			"
	SSL_SESSION_RESUMED			"
	SSL_TLS_SNI			covered by SERVER_NAME
	SSL_VERSION_INTERFACE		didn't care
	SSL_VERSION_LIBRARY		didn't care

  I copied what I thought was most important, dropped what I didn't
understand nor cared for, and that's that.  Certainly most of what I suspect
Gemini will be used for can probably be covered with just AUTH_TYPE and
REMOTE_USER, which is why I made the TLS_ variables optional.

  This also applies to my SCGI implementation, as they both share the same
code to generate the variables.  I will not be upset if the TLS_ variables
are deemed "off limits" and are not to be set at all.  I just added them as
a point of discussion.

  -spc

  

From pitr.vern at gmail.com  Wed Jun 10 01:16:07 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Wed, 10 Jun 2020 02:16:07 +0200
Subject: implementing client certificate support
In-Reply-To: <20200609211335.GY23998@brevard.conman.org>
References: <20200609205951.GX23998@brevard.conman.org>
 <E1jilRy-0002zx-Bx@rmmprod07.runbox>
 <20200609211335.GY23998@brevard.conman.org>
Message-ID: <CAG-mZ3g1t4i+U60kQ9120=k2SH4cwC89rwgZb-NEgrfNWSp2ug@mail.gmail.com>

Wouldn?t the rest of that server?s content be also in the same language and
therefore not accessible to the user?

On Tue, Jun 9, 2020 at 23:13 Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great Tadeusz Sosnierz once stated:
> >
> > 2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>:
> > > Just saying "bad certificate" isn't actionable enough for the user. Why
> > > is it bad? Has it expired? Rejected? What? I NEED TO KNOW!
> >
> > Isn't that something that could go in the "meta" part of the response, or
> > the content itself?
>
>   It could, but what does it mean when I get back "n? ghlactar le
> deimhni?",
> "di?lta?odh deimhni? sa todhcha?", or "di?lta?odh deimhni? caite"?  Not
> everyone speaks English and a numeric response is unambiguous.
>
> > The specificness of 6x codes is something I find quite puzzling,
> > especially considering how carefully select the other codes are.
> >
> > Especially 64. When does that even come into play?
>
>   Time skew between the client and server on a freshly minted
> certificate.
>
> > (Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions
> :))
>
>   Hello, and no, your questions aren't silly.
>
>   -spc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200610/cee6f610/attachment.htm>

From lazar.michael22 at gmail.com  Wed Jun 10 02:02:24 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 9 Jun 2020 21:02:24 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200609231403.GZ23998@brevard.conman.org>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
Message-ID: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>

On Tue, Jun 9, 2020 at 7:14 PM Sean Conner <sean at conman.org> wrote:
>
> It was thus said that the Great solderpunk once stated:
> >
> > (following Sean's lead for now, although I need to bring up some points
> > for discussion about this in the near future).
>
>   So I have two CGI scripts set up.  Both are in a "protected" area of the
> server (on my development machine) that requires a client certificate.  One
> receives *just* the RFC-3875 defined variables:
>
> AUTH_TYPE=Certificate
> GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin
> GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
> GEMINI_URL_PATH=/cgi-bin/beta/foobar
> PATH_INFO=/foobar
> PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar
> QUERY_STRING=one=1&two=2
> REMOTE_ADDR=::ffff:192.168.1.10
> REMOTE_HOST=::ffff:192.168.1.10
> REMOTE_USER=Sean Conner
> REQUEST_METHOD=
> SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./beta
> SERVER_NAME=lucy.roswell.area51
> SERVER_PORT=1965
> SERVER_PROTOCOL=GEMINI
> SERVER_SOFTWARE=GLV-1.12556/1

I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME
should be the part of the URI path that comes before the PATH_INFO [1]. So in
your example:

GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
SCRIPT_NAME=/cgi-bin/beta
PATH_INFO=/foobar

I'm also curious how you are handling URL-encoding in your CGI variables. For
jetforce, I followed my best interpretation of the RFC 3875 guidelines:

- GEMINI_URL: URL-encoded (not specified by the RFC, of course)
- QUERY_STRING: URL-encoded
- PATH_INFO: URL-decoded
- SCRIPT_NAME: URL-decoded

I have a CGI debug script setup here [2] if anybody wants to poke holes in my
implementation.

[1] https://tools.ietf.org/html/rfc3875#section-3.3
[2] gemini://mozz.us/cgi-bin/debug.cgi

Best,
Michael

From colecmac at protonmail.com  Wed Jun 10 02:09:34 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 10 Jun 2020 01:09:34 +0000
Subject: A client SHOULD NOT send the fragment part of a URL to the server?
In-Reply-To: <5EDFF120.6090505@marmaladefoo.com>
References: <B3C27A0D-74C3-49EF-A731-DDA4D8E242A5@gmail.com>
 <20200609160257.dd1b09942924a0fb4fddeb84@matthewgraybosch.com>
 <20200609200912.GD13153@SDF.ORG>
 <F83E1084-B13D-4E5F-8BF3-B92E4EBA9FF7@gmail.com>
 <20200609202610.GF13153@SDF.ORG> <5EDFF120.6090505@marmaladefoo.com>
Message-ID: <zKi7AFBJvPqjjUTfcKkSxJImn3h0mXGeH1M3gzQ-goRf-L7lsE7bwdWdtTDF4UMi5dzicXKQFJX7IwM33Sqq3MwO7IfUFsu0CpyX_wBirAI=@protonmail.com>

I agree, this makes sense. Servers should be able to handle and ignore it, but
clients should not be sending it at all either. The client I'm working on just
strips it out of any URL. It'd be nice to see this explained in the spec.

makeworld

??????? Original Message ???????
On Tuesday, June 9, 2020 4:29 PM, Luke Emmet <luke at marmaladefoo.com> wrote:

> On 09-Jun-2020 21:26, solderpunk wrote:
>
> > On Tue, Jun 09, 2020 at 10:20:12PM +0200, Petite Abeille wrote:
> >
> > > Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification.
> > > Still, no harm down if the fragment hit the server, right? Or?
> >
> > I guess robust servers should tolerate this without throwing an error.
> > Cheers,
> > Solderpunk
>
> Yes servers should definitely ignore any such fragment, which should
> not be sent to the server.
>
> The query part of the URI is for server processing, the fragment is
> always client side only as far as I understand it.
>
> https://en.wikipedia.org/wiki/Fragment_identifier
>
> -   L



From felix at masterq32.de  Wed Jun 10 02:15:10 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 10 Jun 2020 03:15:10 +0200
Subject: [ANN] Kristall Small-Internet Browser V0.2 released
In-Reply-To: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
References: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
Message-ID: <4b9c5068-90c0-b8eb-71dc-0628a07cdb5a@masterq32.de>

Hello Community (again)!

3 days ago i published Kristall in an early version. Since then, a lot
happened. I added a huge bunch of features[0], with a focus on more
protocols (+finger, +gopher), more usability (+theme presets, a lot of
minor tweaks) and support for more media types (+video, +image, +audio).

As always: Enjoy!

Regards
- xq

PS.: @solderpunk, you can probably add Kristall to two of your lists:
Gemini and Gopher clients

[0] https://github.com/MasterQ32/kristall/releases/tag/V0.2

From sean at conman.org  Wed Jun 10 02:29:53 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 21:29:53 -0400
Subject: implementing client certificate support
In-Reply-To: <CAG-mZ3g1t4i+U60kQ9120=k2SH4cwC89rwgZb-NEgrfNWSp2ug@mail.gmail.com>
References: <20200609205951.GX23998@brevard.conman.org>
 <E1jilRy-0002zx-Bx@rmmprod07.runbox>
 <20200609211335.GY23998@brevard.conman.org>
 <CAG-mZ3g1t4i+U60kQ9120=k2SH4cwC89rwgZb-NEgrfNWSp2ug@mail.gmail.com>
Message-ID: <20200610012953.GA23998@brevard.conman.org>

It was thus said that the Great Peter Vernigorov once stated:
> Wouldn?t the rest of that server?s content be also in the same language and
> therefore not accessible to the user?

  Why?  Think of a server written with English error messages yet used to
serve up content in Thai.  Most of the servers are written by English
speaking people, but that doesn't mean all users of said software speak
English---my example just turned that on its head.  And it assumes that the
error messages can't be modified to a particular langauge.

  -spc


From sean at conman.org  Wed Jun 10 02:47:04 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 21:47:04 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
Message-ID: <20200610014704.GB23998@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> On Tue, Jun 9, 2020 at 7:14 PM Sean Conner <sean at conman.org> wrote:
> >
> > It was thus said that the Great solderpunk once stated:
> > >
> > > (following Sean's lead for now, although I need to bring up some points
> > > for discussion about this in the near future).
> >
> >   So I have two CGI scripts set up.  Both are in a "protected" area of the
> > server (on my development machine) that requires a client certificate.  One
> > receives *just* the RFC-3875 defined variables:
> >
> > AUTH_TYPE=Certificate
> > GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin
> > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
> > GEMINI_URL_PATH=/cgi-bin/beta/foobar
> > PATH_INFO=/foobar
> > PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar
> > QUERY_STRING=one=1&two=2
> > REMOTE_ADDR=::ffff:192.168.1.10
> > REMOTE_HOST=::ffff:192.168.1.10
> > REMOTE_USER=Sean Conner
> > REQUEST_METHOD=
> > SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./beta
> > SERVER_NAME=lucy.roswell.area51
> > SERVER_PORT=1965
> > SERVER_PROTOCOL=GEMINI
> > SERVER_SOFTWARE=GLV-1.12556/1
> 
> I believe this is using SCRIPT_NAME incorrectly per RFC 3875. 

  You are correct.  Sigh.  Off to fix it ...

> I'm also curious how you are handling URL-encoding in your CGI variables. For
> jetforce, I followed my best interpretation of the RFC 3875 guidelines:
> 
> - GEMINI_URL: URL-encoded (not specified by the RFC, of course)

  I also URL-encode this.

> - QUERY_STRING: URL-encoded

  I don't URL-decode the query, so what gets passed to the script is what
was passed as the request.

> - PATH_INFO: URL-decoded
> - SCRIPT_NAME: URL-decoded

  Same here, modulo the incorrect SCRIPT_NAME in GLV-1.12556.

  -spc

From sean at conman.org  Wed Jun 10 03:08:54 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 9 Jun 2020 22:08:54 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
Message-ID: <20200610020854.GC23998@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> 
> I have a CGI debug script setup here [2] if anybody wants to poke holes in my
> implementation.
> 
> [1] https://tools.ietf.org/html/rfc3875#section-3.3
> [2] gemini://mozz.us/cgi-bin/debug.cgi

  I notice it doesn't set PATH_TRANSLATED, and it always sets TLS_CIPHER and
TLS_VERSION.  And why HOSTNAME when you also have SERVER_NAME?

  -spc


From lazar.michael22 at gmail.com  Wed Jun 10 04:53:19 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 9 Jun 2020 23:53:19 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200610020854.GC23998@brevard.conman.org>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
Message-ID: <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>

On Tue, Jun 9, 2020 at 10:09 PM Sean Conner <sean at conman.org> wrote:
>
> It was thus said that the Great Michael Lazar once stated:
> >
> > I have a CGI debug script setup here [2] if anybody wants to poke holes in my
> > implementation.
> >
> > [1] https://tools.ietf.org/html/rfc3875#section-3.3
> > [2] gemini://mozz.us/cgi-bin/debug.cgi

>   I notice it doesn't set PATH_TRANSLATED

I just didn't see a compelling reason to add it.

> and it always sets TLS_CIPHER and TLS_VERSION.

Why not? These are just as useful even if the client doesn't send a
certificate.

> And why HOSTNAME when you also have SERVER_NAME?

I can't remember why I added this. I thought I saw HOSTNAME referenced
somewhere...

Some other differences in my server's CGI implementation (I used GLV as a
reference implementation, so there are a lot of similarities too):

TLS_CLIENT_HASH

I'm using a base64-encoded representation of the hash. I like your notation of
SHA256:<HEX> better, but it's too late now and I don't want to break backwards
compatibility.

TLS_CLIENT_SERIAL_NUMBER

The client certificate serial number. I'm surprised that this isn't available
in libtls.

TLS_CLIENT_AUTHORISED

Even though jetforce accepts unverified client certificates now, it will still
check if the certificate is authorised anyway. This means both valid and trusted
by the server's CA store. So this will be set to "1" for trusted and "0" for
untrusted. I like this variable because it gives each CGI script the option to
implement authentication however they want.

From martin at no.ucant.org  Wed Jun 10 05:19:35 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Wed, 10 Jun 2020 05:19:35 +0100 (BST)
Subject: authority's userinfo?
In-Reply-To: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
Message-ID: <alpine.DEB.2.20.2006100517170.18317@pling.qwghlm.org>

On Tue, 9 Jun 2020, Petite Abeille wrote:

> How is gemini meant to deal with authority's userinfo?
>
> E.g.
>
> gemini://username:password at mozz.us/
> gemini://username at mozz.us/
>
> Orthodox?
>
> If so, how does the server communicate authentication failure back to the client?

This kind of stuff really is distracting from the business of just getting 
some decent Gemini content written. We should stick to solving problems as 
they arise in reality, rather than focusing on theoretical issues 
which raise a sort of "gotcha" about the existing spec and philosophy, and 
we ought most particularly so to do if we disagree with that philosophy.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From sean at conman.org  Wed Jun 10 05:38:31 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 10 Jun 2020 00:38:31 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
References: <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
Message-ID: <20200610043830.GD23998@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> On Tue, Jun 9, 2020 at 10:09 PM Sean Conner <sean at conman.org> wrote:
> >
> > It was thus said that the Great Michael Lazar once stated:
> > >
> > > I have a CGI debug script setup here [2] if anybody wants to poke holes in my
> > > implementation.
> > >
> > > [1] https://tools.ietf.org/html/rfc3875#section-3.3
> > > [2] gemini://mozz.us/cgi-bin/debug.cgi
> 
> >   I notice it doesn't set PATH_TRANSLATED
> 
> I just didn't see a compelling reason to add it.

  I think it may have something to do with Apache's rewrite rules.  My blog
[1] is run via a CGI script, and I make extensive use of it to hide the fact
that I'm using a CGI script [2].  For example, the url:

	http://boston.conman.org/about/technical.html

is routed through the following rewrite rule [3]:

	RewriteRule ^about/(.*) boston.cgi/about/$1 [L]

to give the final (internal) path of:

	/boston.cgi/about/technical.html

  I then use PATH_TRANSLATED to find the actual file to display.  No Gemini
server supports rewriting rules, but I don't see a reason why one couldn't.

> > and it always sets TLS_CIPHER and TLS_VERSION.
> 
> Why not? These are just as useful even if the client doesn't send a
> certificate.

  Fair enough.

> Some other differences in my server's CGI implementation (I used GLV as a
> reference implementation, so there are a lot of similarities too):
> 
> TLS_CLIENT_HASH
> 
> I'm using a base64-encoded representation of the hash. I like your notation of
> SHA256:<HEX> better, but it's too late now and I don't want to break backwards
> compatibility.

  The format I use is from libtls---it was not my choice.  

> TLS_CLIENT_SERIAL_NUMBER
> 
> The client certificate serial number. I'm surprised that this isn't available
> in libtls.

  I'm surprised too when I saw TLS_CLIENT_SERIAL_NUMBER for the first time. 
I may have to make an extention module to do some stuff that libtls can't
do.

> TLS_CLIENT_AUTHORISED
> 
> Even though jetforce accepts unverified client certificates now, it will still
> check if the certificate is authorised anyway. This means both valid and trusted
> by the server's CA store. So this will be set to "1" for trusted and "0" for
> untrusted. I like this variable because it gives each CGI script the option to
> implement authentication however they want.

  That makes sense.  That's another thing that libtls makes a bit difficult.

  -spc

[1]	http://boston.conman.org/

[2]	Not for security reasons, but for aesthetic reasons.  I could change
	the name of the CGI script and *none* of the URLs will change.

[3]	I'd have to look up what the '[L]' does---it's been *that* long
	since I've set this up.

From solderpunk at SDF.ORG  Wed Jun 10 08:32:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 07:32:16 +0000
Subject: "Wide load" status code(s)?
Message-ID: <20200610073216.GA16028@SDF.ORG>

Hey all,

Just throwing out a quick idea I had last night while trying to sleep,
to see how people feel about it.  It's simple and easily ignorable and I
think it's kind of neat.

It's been a small pain point for some people for a while now that there
is no way for a Gemini client to know how large a file it's downloading
is without simply downloading the whole thing.  This is inconvenient
from a UI perspective, as there is no way to display a progress bar, and
simple clients like AV-98 which simply download a complete file and then
pass it off to a handler program appear to "freeze" on large downloads
with no clear indication that anything is happening.  This is a much
bigger problem for people on limited machines (e.g. low memory diskless
systems are perfectly viable for reading text/gemini content and
displaying small images but not for downloading large binaries, but they
can't gracefully opt out of the big stuff and are forced to simply
terminate the connection once a threshold amount of content has been
downloaded, and then wastefully discard that partial content) or
internet connections (e.g. people at sea using satellite data plans
which are billed per megabyte).

People usually want to address this by having the server somehow declare
the file size upfront in the header, as per HTTP's "Content-Length", but
I've resisted that tooth and nail because there's no sensible way to do
it which doesn't turn the response header into an infinitely extensible
thing which people can tack their own variables onto, leaving us no
better off than HTTP (so, please, no more ideas on this front)...

I was very happy to realise that a lot of these problems can be solved,
or at least ameliorated, in a very simple way with an additional 2x
status code.  Since I plan to deprecate the current 21 code for ending a
transient certificate session, we could reuse 21 to mean "SUCCESS, a
response body follows, and it's larger than $THRESHOLD MiB" (note I am
proposing no change to the existing code 20 - 20 does NOT mean "what's
coming in less than $THRESHOLD").  Simple clients could simply treat 21
as 20 and be in exactly the situation they are in now, so the graceful
degredation of status codes to their x0 form works nicely here.  But
e.g. AV-98 could print "Downloading large file, please wait..." upon
receving a 21, and then proceed as usual.  This is a very low effort
client change, but it solves the problem of people thinking something
has gone wrong when they unknowingly start a large download.  More
importantly, users in resource-limited environments could use clients
which simply terminate the connection immediately on seeing a header
starting with 21, providing a quick and low-waste "opt out" of large
content.

On the server side, again, a dirt simple server could just always serve
up 20 without actually breaking anything.  I realise that knowing
whether to use 20 or 21 for dynamically generated content may not be
straightforward - no problem, it is *always* valid to just send 20 when
in doubt.  21 is nothing more than a helpful hint to clients who might
need it.  It doesn't need to be 100% reliable to still have value.

This feels like a good idea to me.  It's totally optional and very easy
to handle on both the client and server sides, and I feel like being
friendly to small/slow computers and slow/intermittent network
connections is a good fit with the overall "vibe" of Gemini, provided
doing so does not conflict with overall simplicity.

Naturally, deciding to do this will lead immediately to a weeks-long
heated debate on what the appropriate value of $THRESHOLD should be.  We
*could* wade into those waters, but I'll just also throw out that we
could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
100MiB respectively and leave it at that.  Clients targetting
resource-limited environments could let their users configure their own
threshold for early termination of downloads.

Cheers,
Solderpunk

From natpen at natpen.net  Wed Jun 10 11:36:05 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Wed, 10 Jun 2020 06:36:05 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <20200610103605.GA6867@goldfish.localdomain>

I like the spirit of this idea a lot - Gemini has an opportunity to do
a lot more for users in resource-limited environments, and in addition
to the explicit austerity in the protocol itself, this is another way
to proactively respect users' resources and time.

What I feel less excited about is the specification of a hard-coded
$THRESHOLD. It feels like a magic number that's not going to fit all
situations well - adding three of them like you brought up at the end
improves the situation, but nevertheless still feels like a magic
number solution. And depending on how future-proof you want these
$THRESHOLDs to be, no matter how good the magic numbers are today, as
years pass and internet access/quality across the world changes, for
better or worse, the magic numbers will become more and more out of
date.

The only way I see to make it not a magic number is to allow clients
to specify a $THRESHOLD as part of their request - that, however,
feels like too big of a change to introduce to the Request structure
(even if we could make it gracefully degrade).

So, my conclusions are:

A) I love the idea
B) I don't love the design
C) I worry there may be no better design

And I would support speccing this if no better design arrives, because
it is a meaningful issue to solve!

Nat

From felix at masterq32.de  Wed Jun 10 11:33:36 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 10 Jun 2020 12:33:36 +0200
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <0943dc41-a759-04b0-cec3-96fbaa6210f3@masterq32.de>

Heya!

> This feels like a good idea to me.  It's totally optional and very easy
> to handle on both the client and server sides, and I feel like being
> friendly to small/slow computers and slow/intermittent network
> connections is a good fit with the overall "vibe" of Gemini, provided
> doing so does not conflict with overall simplicity.
Yes, i totally like that idea!

> Naturally, deciding to do this will lead immediately to a weeks-long
> heated debate on what the appropriate value of $THRESHOLD should be.  We
> *could* wade into those waters, but I'll just also throw out that we
> could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> 100MiB respectively and leave it at that.  Clients targetting
> resource-limited environments could let their users configure their own
> threshold for early termination of downloads.
I had the exact same thoughts, and i think the idea of "wasting" 3
status codes for 1, 10 and 100 MB are totally okay. It allows clients to
better display a loading indication

Regards
- xq

From petite.abeille at gmail.com  Wed Jun 10 11:48:52 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 10 Jun 2020 12:48:52 +0200
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200609231403.GZ23998@brevard.conman.org>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
Message-ID: <821CBF1C-37E9-4AEE-8279-4763C640464B@gmail.com>



> On Jun 10, 2020, at 01:14, Sean Conner <sean at conman.org> wrote:
> 
>  I copied what I thought was most important, dropped what I didn't
> understand nor cared for, and that's that.

Very cool.

Lot of data. https://tlsfingerprint.io/static/frolov2019.pdf


From petite.abeille at gmail.com  Wed Jun 10 11:49:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 10 Jun 2020 12:49:11 +0200
Subject: redirect opt-in?
Message-ID: <4B177303-41C0-4727-AC3F-EAB12F7D9C86@gmail.com>

Given that user-agents should refrain from initiating network connection on their own, should redirects (3x)  be manually confirmed? With explicit user consent?

The spec is ambivalent:

Redirect limits
Clients may prompt their users for decisions as to whether or not to follow a redirect, or they may follow redirects automatically.  

Perhaps user-agents SHOULD prompt for decisions as to whether to follow a redirect, or MAY follow redirects automatically.  






From petite.abeille at gmail.com  Wed Jun 10 11:50:08 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 10 Jun 2020 12:50:08 +0200
Subject: authority's userinfo?
In-Reply-To: <alpine.DEB.2.20.2006100517170.18317@pling.qwghlm.org>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <alpine.DEB.2.20.2006100517170.18317@pling.qwghlm.org>
Message-ID: <730EEB07-C6CA-4035-9508-B4D26B149CE3@gmail.com>



> On Jun 10, 2020, at 06:19, Martin Keegan <martin at no.ucant.org> wrote:
> 
> We should stick to solving problems as they arise in reality

It's a real question for me. Groupthink has its limits.


From felix at masterq32.de  Wed Jun 10 12:15:33 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 10 Jun 2020 13:15:33 +0200
Subject: authority's userinfo?
In-Reply-To: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
Message-ID: <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>

> How is gemini meant to deal with authority's userinfo? 
> 
> gemini://username:password at mozz.us/
> gemini://username at mozz.us/
> 
> Orthodox? 
> 
> If so, how does the server communicate authentication failure back to the client?  
I don't think that user/password is the right way to handle
authentication in Gemini. The URL RFC also specifies:

> Use of the format "user:password" in the userinfo field is
> deprecated.

So only user@? is still a valid URL.

If your server handles user@ in a different way than without authority,
i think that's totally in-spec, but authentication is probably not.

One possible usage for authority could be home-dirs instead of an
official site:

Instead of using
=> gemini://random-projects.net/~felix/
one could also access the directory via
=> gemini://felix at random-projects.net/

But that's just some brainfart.

Regards
- xq


[0] https://tools.ietf.org/html/rfc3986

From petite.abeille at gmail.com  Wed Jun 10 12:16:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 10 Jun 2020 13:16:12 +0200
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <8A32AD82-AC96-4826-883C-5BEF248CE337@gmail.com>



> On Jun 10, 2020, at 09:32, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> are forced to simply terminate the connection once a threshold amount of content has been downloaded

Is it really a problem? It should be user-agents prerogative to drop the connection anytime they see fit. And/or only handle a small subset of media type (e.g. text/* only). Ditto for showing network activities. Even the simplest of client could count how many bytes it has read so far, no?


From tadeusz at sosnierz.com  Wed Jun 10 12:16:48 2020
From: tadeusz at sosnierz.com (Tadeusz Sosnierz)
Date: Wed, 10 Jun 2020 13:16:48 +0200 (CEST)
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610103605.GA6867@goldfish.localdomain>
Message-ID: <E1jiyiu-0001sP-J2@rmmprod07.runbox>


2020-06-10 12:36 GMT+02:00 Natalie Pendragon<natpen at natpen.net>:
> What I feel less excited about is the specification of a hard-coded
> $THRESHOLD. It feels like a magic number that's not going to fit all
> situations well - adding three of them like you brought up at the end
> improves the situation, but nevertheless still feels like a magic
> number solution. And depending on how future-proof you want these
> $THRESHOLDs to be, no matter how good the magic numbers are today, as
> years pass and internet access/quality across the world changes, for
> better or worse, the magic numbers will become more and more out of
> date.

I feel the same way; sounds like no matter what you pick will become the
"64 kilobytes" of tomorrow's jokes. And ultimately it doesn't allow the
introduction of a meaningful progress indicator. Is 100MBs a lot? Is it a long wait?
I don't know, is the upstream server fast? Is my wifi having a good day?

The alternative is tricky to come up without making the response structure arbitrary
and complex. Here's a take though: anything bigger than a megabyte or ten is realistically
not going to be text, or anything text-like that can be displayed inline. I can think of images,
videos, maybe PDFs or just a bunch of encrypted data in the form of whatever.
I wonder if it'd make sense to have a status code that indicates
?mimetype is basically meaningless, it's a big whatever,
so I'll give you the content length instead?.

Client could then choose to receive a few more bytes and check a magic byte for something
it recognizes ? or just prompt the client saying ?that's not exactly something we can display anyway,
(how) do you want it saved??

--
tadzik

From koushik at meff.me  Wed Jun 10 08:41:54 2020
From: koushik at meff.me (Koushik Roy)
Date: Wed, 10 Jun 2020 00:41:54 -0700
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <59b701f8-1fe8-2977-ae74-591c2f47931e@meff.me>

Sorry replying to the list address this time...

How about letting the server decide? I can imagine a scenario where the 
server defaults to sending text/* mime types as 20 responses and 
everything else as 21 responses. Then servers can let configuration or 
(s)CGI output determine how to decide on 20 vs 21. While leaving it up 
to the server is subjective, I think most content authors understand 
whether something is meant to be quickly digested and rendered or 
whether something should be downloaded/queued/status line shown.

- meff


On 6/10/20 12:32 AM, solderpunk wrote:
> Hey all,
> 
> Just throwing out a quick idea I had last night while trying to sleep,
> to see how people feel about it.  It's simple and easily ignorable and I
> think it's kind of neat.
> 
> It's been a small pain point for some people for a while now that there
> is no way for a Gemini client to know how large a file it's downloading
> is without simply downloading the whole thing.  This is inconvenient
> from a UI perspective, as there is no way to display a progress bar, and
> simple clients like AV-98 which simply download a complete file and then
> pass it off to a handler program appear to "freeze" on large downloads
> with no clear indication that anything is happening.  This is a much
> bigger problem for people on limited machines (e.g. low memory diskless
> systems are perfectly viable for reading text/gemini content and
> displaying small images but not for downloading large binaries, but they
> can't gracefully opt out of the big stuff and are forced to simply
> terminate the connection once a threshold amount of content has been
> downloaded, and then wastefully discard that partial content) or
> internet connections (e.g. people at sea using satellite data plans
> which are billed per megabyte).
> 
> People usually want to address this by having the server somehow declare
> the file size upfront in the header, as per HTTP's "Content-Length", but
> I've resisted that tooth and nail because there's no sensible way to do
> it which doesn't turn the response header into an infinitely extensible
> thing which people can tack their own variables onto, leaving us no
> better off than HTTP (so, please, no more ideas on this front)...
> 
> I was very happy to realise that a lot of these problems can be solved,
> or at least ameliorated, in a very simple way with an additional 2x
> status code.  Since I plan to deprecate the current 21 code for ending a
> transient certificate session, we could reuse 21 to mean "SUCCESS, a
> response body follows, and it's larger than $THRESHOLD MiB" (note I am
> proposing no change to the existing code 20 - 20 does NOT mean "what's
> coming in less than $THRESHOLD").  Simple clients could simply treat 21
> as 20 and be in exactly the situation they are in now, so the graceful
> degredation of status codes to their x0 form works nicely here.  But
> e.g. AV-98 could print "Downloading large file, please wait..." upon
> receving a 21, and then proceed as usual.  This is a very low effort
> client change, but it solves the problem of people thinking something
> has gone wrong when they unknowingly start a large download.  More
> importantly, users in resource-limited environments could use clients
> which simply terminate the connection immediately on seeing a header
> starting with 21, providing a quick and low-waste "opt out" of large
> content.
> 
> On the server side, again, a dirt simple server could just always serve
> up 20 without actually breaking anything.  I realise that knowing
> whether to use 20 or 21 for dynamically generated content may not be
> straightforward - no problem, it is *always* valid to just send 20 when
> in doubt.  21 is nothing more than a helpful hint to clients who might
> need it.  It doesn't need to be 100% reliable to still have value.
> 
> This feels like a good idea to me.  It's totally optional and very easy
> to handle on both the client and server sides, and I feel like being
> friendly to small/slow computers and slow/intermittent network
> connections is a good fit with the overall "vibe" of Gemini, provided
> doing so does not conflict with overall simplicity.
> 
> Naturally, deciding to do this will lead immediately to a weeks-long
> heated debate on what the appropriate value of $THRESHOLD should be.  We
> *could* wade into those waters, but I'll just also throw out that we
> could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> 100MiB respectively and leave it at that.  Clients targetting
> resource-limited environments could let their users configure their own
> threshold for early termination of downloads.
> 
> Cheers,
> Solderpunk
> 

From tkarpiniec at icloud.com  Wed Jun 10 13:16:03 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Wed, 10 Jun 2020 22:16:03 +1000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <20200610121603.GA52965@allanon.local>

On Wed, Jun 10, 2020 at 07:32:16AM +0000, solderpunk wrote:
> Naturally, deciding to do this will lead immediately to a weeks-long
> heated debate on what the appropriate value of $THRESHOLD should be.  We
> *could* wade into those waters, but I'll just also throw out that we
> could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> 100MiB respectively and leave it at that.  Clients targetting
> resource-limited environments could let their users configure their own
> threshold for early termination of downloads.

That's the real question isn't it? I don't feel strongly about this
either way but I'll share a couple of thoughts.

One place I previously used gopher was IP routed over VHF packet
radio. These links are 1200 baud simplex with an effective throughput
of some 80 B/s. I'm not saying gemini can or should care what weirdos
are doing with VHF radios, but it may one day find use in scenarios
where quantities much less then 1 MB matter. If you're using such a
slow link, you might have to waste quite a lot of time to realise that
you're getting an above-average amount of content, reducing the
effectiveness of a client-side threshold.

One way to offer more flexibility could be to use the second digit of
the "2n" response code as saying "this content >= 10^n bytes".

But I would raise no objections to maintaining the status quo, or to
adopting the three codes suggested here.

Cheers, Tom

From petite.abeille at gmail.com  Wed Jun 10 13:18:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 10 Jun 2020 14:18:47 +0200
Subject: authority's userinfo?
In-Reply-To: <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
Message-ID: <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>



> On Jun 10, 2020, at 13:15, Felix Quei?ner <felix at masterq32.de> wrote:
> 
> I don't think that user/password is the right way to handle
> authentication in Gemini.

Why not? Gemini mandates a secure communication channel (TLS) already. The userinfo is identical to the Basic Authentication scheme, but encoded the URL directly. Rather convenient altogether.

> The URL RFC also specifies:
> 
>> Use of the format "user:password" in the userinfo field is
>> deprecated.

This is more related to authentication over an open channel.

> So only user@? is still a valid URL.
> 
> If your server handles user@ in a different way than without authority,
> i think that's totally in-spec, but authentication is probably not.

I guess user@ could be any magic token/ticket, for the client to maintain a state on the server.

Perhaps a subset of 40 TEMPORARY FAILURE, e.g. 49 Unauthorized, would be an appropriate response if Authenticate: Basic is required by a resource. 

> One possible usage for authority could be home-dirs instead of an
> official site:

I was more looking into a way for the client to maintain some states (e.g. preferences) on the server:

C: gemini://token at mozz.us/?ua=lightweight -- user-agent store its preferences on the server
S: 30 gemini://token at mozz.us/index.gmi-- redirect to an appropriate resource
C: gemini://token at mozz.us/index.gmi -- lightweight version of the resource
S: 20 text/gemini -- customized as per the user-agent stated preferences

A bit of content negotiation in other words.

For all practical purpose, it serves the same purpose as the various 6x (CLIENT CERTIFICATE REQUIRED) statuses. Minus the burden of the actual TLS gymnastic. 



From hello at matthewgraybosch.com  Wed Jun 10 14:49:14 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 10 Jun 2020 09:49:14 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>

On Wed, 10 Jun 2020 07:32:16 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> Hey all,
> 
> It's been a small pain point for some people for a while now that
> there is no way for a Gemini client to know how large a file it's
> downloading is without simply downloading the whole thing.

I agree that it's important to let people using Gemini clients know how
big a file they're about to download is, and I think the status codes
for indicating large, huge, and colossal files are a good idea.

This inspired me to manually add file sizes to my link descriptions for
any file I host on my own capsules as a courtesy to visitors so that
people can decide for themselves whether they want to open a particular
link. I've done the same for my capsules' atom feeds so that people
visiting CAPCOM can also see how large my files are.

I won't presume to recommend that everybody do this, even though it
would be nice to see my approach become a convention. It takes time to
go through your directory tree and get file sizes even if you're just
using shell commands like "ls -hal", but it's a low-tech approach I can
implement today instead of waiting for client and server developers to
catch up.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg,PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From petite.abeille at gmail.com  Wed Jun 10 16:45:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 10 Jun 2020 17:45:11 +0200
Subject: 60 & 61 & 62 vs. userinfo
Message-ID: <6D735B00-BE44-4543-8A6F-F78694DE2EE7@gmail.com>

Currently, the 6x (CLIENT CERTIFICATE REQUIRED) status code range is used to maintain states between gemini client and server.

An example is Astrobotany, which uses self-signed certificate and the certificate's CommonName as username:

"Register a new account by sending a self-signed certificate ... Your certificate's CommonName will be your username..."

https://portal.mozz.us/gemini/astrobotany.mozz.us/

Initially, it was even using certificate signing request, for good measure:

https://portal.mozz.us/gemini/astrobotany.mozz.us/register

This allows Astrobotany to both authenticate & maintain states across gemini requests.

Very nice, high grade authentication and state management to securely attend to all our sativa-indica cravings. 

An alternative, elcheapo, workflow, without any need for client certificate fiddling, could entail just the userinfo authority bit of an URL:

(1) Request a named token:

C: gemini://astrobotany.mozz.us/.well-known/token?anon -- request a named token, at a well known location
S: 30 gemini://anon:token at astrobotany.mozz.us/ -- the server associates an opaque token to validate the named user
C: gemini://anon:token at astrobotany.mozz.us/ -- the user-agent authenticated with the provided userinfo to maintain its state


(2) (Re)use the named token later on:

C: gemini://anon:token at astrobotany.mozz.us/plant
S: 20 text/gemini; charset=utf-32; lang=tlh-Kore-AQ-fonipa
-OR-
S: 40 Unauthorized. Access token required. Get one at gemini://astrobotany.mozz.us/.well-known/acct.

The token can be anything sensible, given what's at stake, e.g. short base58 hmac of the name, random number, whatnot.

Workable? Heresy?














From colecmac at protonmail.com  Wed Jun 10 16:51:20 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 10 Jun 2020 15:51:20 +0000
Subject: authority's userinfo?
In-Reply-To: <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
Message-ID: <A-QYU8ndylHPo1_5OMPGwp1nuypfMfN8eE5JIJURK3K2E6cag4jTC8wlVfv1NuGUgk3thbz4wUIbCTiJb_wE8UiWT9l33PUsAdHBZJp8CIU=@protonmail.com>

xq wrote:
> One possible usage for authority could be home-dirs instead of an
> official site:
>
> Instead of using
> => gemini://random-projects.net/~felix/
> one could also access the directory via
> => gemini://felix at random-projects.net/
>


I actually really like this, it provides a consistent way to do this
for any site.

makeworld

From pitr.vern at gmail.com  Wed Jun 10 17:20:03 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Wed, 10 Jun 2020 18:20:03 +0200
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <CAG-mZ3i9D+Hw9qOvzxhXgDsv8tHMBs5ayARacO5ZiPg0_tksHg@mail.gmail.com>

Although this makes sense at first glance, I believe that a status code is
too late to let user know that the file is large. Bytes are already being
transferred and received by user?s OS, even if client is not reading them
yet. By the time any of this information is displayed to the user, and the
time it takes them to react, damage has already been done. I think the only
sensible solution is for pages to display size information to user next to
the link.

On Wed, Jun 10, 2020 at 09:32 solderpunk <solderpunk at sdf.org> wrote:

> Hey all,
>
> Just throwing out a quick idea I had last night while trying to sleep,
> to see how people feel about it.  It's simple and easily ignorable and I
> think it's kind of neat.
>
> It's been a small pain point for some people for a while now that there
> is no way for a Gemini client to know how large a file it's downloading
> is without simply downloading the whole thing.  This is inconvenient
> from a UI perspective, as there is no way to display a progress bar, and
> simple clients like AV-98 which simply download a complete file and then
> pass it off to a handler program appear to "freeze" on large downloads
> with no clear indication that anything is happening.  This is a much
> bigger problem for people on limited machines (e.g. low memory diskless
> systems are perfectly viable for reading text/gemini content and
> displaying small images but not for downloading large binaries, but they
> can't gracefully opt out of the big stuff and are forced to simply
> terminate the connection once a threshold amount of content has been
> downloaded, and then wastefully discard that partial content) or
> internet connections (e.g. people at sea using satellite data plans
> which are billed per megabyte).
>
> People usually want to address this by having the server somehow declare
> the file size upfront in the header, as per HTTP's "Content-Length", but
> I've resisted that tooth and nail because there's no sensible way to do
> it which doesn't turn the response header into an infinitely extensible
> thing which people can tack their own variables onto, leaving us no
> better off than HTTP (so, please, no more ideas on this front)...
>
> I was very happy to realise that a lot of these problems can be solved,
> or at least ameliorated, in a very simple way with an additional 2x
> status code.  Since I plan to deprecate the current 21 code for ending a
> transient certificate session, we could reuse 21 to mean "SUCCESS, a
> response body follows, and it's larger than $THRESHOLD MiB" (note I am
> proposing no change to the existing code 20 - 20 does NOT mean "what's
> coming in less than $THRESHOLD").  Simple clients could simply treat 21
> as 20 and be in exactly the situation they are in now, so the graceful
> degredation of status codes to their x0 form works nicely here.  But
> e.g. AV-98 could print "Downloading large file, please wait..." upon
> receving a 21, and then proceed as usual.  This is a very low effort
> client change, but it solves the problem of people thinking something
> has gone wrong when they unknowingly start a large download.  More
> importantly, users in resource-limited environments could use clients
> which simply terminate the connection immediately on seeing a header
> starting with 21, providing a quick and low-waste "opt out" of large
> content.
>
> On the server side, again, a dirt simple server could just always serve
> up 20 without actually breaking anything.  I realise that knowing
> whether to use 20 or 21 for dynamically generated content may not be
> straightforward - no problem, it is *always* valid to just send 20 when
> in doubt.  21 is nothing more than a helpful hint to clients who might
> need it.  It doesn't need to be 100% reliable to still have value.
>
> This feels like a good idea to me.  It's totally optional and very easy
> to handle on both the client and server sides, and I feel like being
> friendly to small/slow computers and slow/intermittent network
> connections is a good fit with the overall "vibe" of Gemini, provided
> doing so does not conflict with overall simplicity.
>
> Naturally, deciding to do this will lead immediately to a weeks-long
> heated debate on what the appropriate value of $THRESHOLD should be.  We
> *could* wade into those waters, but I'll just also throw out that we
> could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> 100MiB respectively and leave it at that.  Clients targetting
> resource-limited environments could let their users configure their own
> threshold for early termination of downloads.
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200610/d501e176/attachment.htm>

From hello at matthewgraybosch.com  Wed Jun 10 17:54:09 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 10 Jun 2020 12:54:09 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <CAG-mZ3i9D+Hw9qOvzxhXgDsv8tHMBs5ayARacO5ZiPg0_tksHg@mail.gmail.com>
References: <20200610073216.GA16028@SDF.ORG>
 <CAG-mZ3i9D+Hw9qOvzxhXgDsv8tHMBs5ayARacO5ZiPg0_tksHg@mail.gmail.com>
Message-ID: <20200610125409.6f36750a30c0c49e41d4773d@matthewgraybosch.com>

On Wed, 10 Jun 2020 18:20:03 +0200
Peter Vernigorov <pitr.vern at gmail.com> wrote:

> Although this makes sense at first glance, I believe that a status
> code is too late to let user know that the file is large. Bytes are
> already being transferred and received by user's OS, even if client
> is not reading them yet. By the time any of this information is
> displayed to the user, and the time it takes them to react, damage
> has already been done. I think the only sensible solution is for
> pages to display size information to user next to the link.

I agree, but I suspect that unless content authors take the time to
provide this information themselves displaying size info next to links
will require multiple rounds of communication between the user agent
and the server just to query file sizes. That probably isn't what
solderpunk, etc. had in mind.

-- 
Matthew Graybosch           https://www.matthewgraybosch.com
#include <disclaimer.h>	    gemini://starbreaker.org
Harrisburg, PA	 	    gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From luke at marmaladefoo.com  Wed Jun 10 20:04:54 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Wed, 10 Jun 2020 20:04:54 +0100
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610121603.GA52965@allanon.local>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610121603.GA52965@allanon.local>
Message-ID: <5EE12ED6.9080109@marmaladefoo.com>


On 10-Jun-2020 13:16, Thomas Karpiniec wrote:
> One way to offer more flexibility could be to use the second digit of
> the "2n" response code as saying "this content>= 10^n bytes".
>
> But I would raise no objections to maintaining the status quo, or to
> adopting the three codes suggested here.
This seems nice and future proof, but uses up a lot of status codes 
potentially (29 takes us up to 10^9)

However, it seems we are making a lot of effort to find the wrong way to 
communicate important information about download size. In any networked 
application this information is really useful for clients and users to 
make good choices about whether to wait for something to come or not. If 
we can have lang and mime-type in the response for 20 response, is it 
really that philosophically disturbing to include this important 
information that we know makes network bandwidth negotiation better for 
everyone?

If we have to, I think it could be a client option:

[ ] limit non-text content to 5Mb per request
[x] download all text/* content

Best Wishes

  - Luke

From luke at marmaladefoo.com  Wed Jun 10 20:20:04 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Wed, 10 Jun 2020 20:20:04 +0100
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
Message-ID: <5EE13264.8020501@marmaladefoo.com>



On 10-Jun-2020 14:49, Matthew Graybosch wrote:
>
> I agree that it's important to let people using Gemini clients know how
> big a file they're about to download is, and I think the status codes
> for indicating large, huge, and colossal files are a good idea.
>
> This inspired me to manually add file sizes to my link descriptions for
> any file I host on my own capsules as a courtesy to visitors so that
> people can decide for themselves whether they want to open a particular
> link. I've done the same for my capsules' atom feeds so that people
> visiting CAPCOM can also see how large my files are.
>
> I won't presume to recommend that everybody do this, even though it
> would be nice to see my approach become a convention. It takes time to
> go through your directory tree and get file sizes even if you're just
> using shell commands like "ls -hal", but it's a low-tech approach I can
> implement today instead of waiting for client and server developers to
> catch up.
>
Again, the client can do a lot of work for you in this regard. As we all 
know mostly the heavy content is going to be images and things like 
linked mp3, zip, pdf etc.

Generally speaking a client can examine the URL and make an educated 
assumption about the target mime type from the file extension. Such 
links can be decorated or hinted to the user who may or may not decide 
to download them.

In the upcoming relese of GemiNaut I have implemented a simple 
decoration scheme that lets users infer this form the link. This 
decoration is added by the client irrespective of the server.

=> /normal/path Normal gemini link

These can generally can be assumed to be text/gmi or maybe text/*, no 
extra decoration, so displayed like this:

? Normal gemini link

=> /path/to/file.png Link to an image

these can be decorated to hint this to the user, so what you actually 
see is this. The icon hints at the content you will likely get.

? ? Link to an image

Do I want to click on all links to images? Probably not for various 
reasons including bandwidth/performance, and the client helped me make 
that judgement.

At the moment I have an opt in list of the most likely file types that 
might be linked to:

[png gif jpg etc] are images

[mp3 mov pdf zip gz] are decorated as "binary" files

This gives the user a good idea what they will get and helps make a 
choice to click on the link or not

Best wishes

- Luke

From solderpunk at SDF.ORG  Wed Jun 10 20:47:00 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 19:47:00 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610103605.GA6867@goldfish.localdomain>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610103605.GA6867@goldfish.localdomain>
Message-ID: <20200610194700.GB10136@SDF.ORG>

On Wed, Jun 10, 2020 at 06:36:05AM -0400, Natalie Pendragon wrote:
 
> What I feel less excited about is the specification of a hard-coded
> $THRESHOLD. It feels like a magic number that's not going to fit all
> situations well - adding three of them like you brought up at the end
> improves the situation, but nevertheless still feels like a magic
> number solution. And depending on how future-proof you want these
> $THRESHOLDs to be, no matter how good the magic numbers are today, as
> years pass and internet access/quality across the world changes, for
> better or worse, the magic numbers will become more and more out of
> date.

Hmm.  I'll admit I didn't think about this at all, so good job flagging
it!  That said, I'm not sure this is a problem for us.  Gemini's lack
of caching, lack of compression, and lack of resumable downloads all
mean it's *never* going to be sensible choice for really big downloads,
no matter how fast internet speeds get.  I don't see a future where
Gemini clients wanting to choose between thresholds of 100MiB, 1GiB and
10GiB are sensible.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 20:47:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 19:47:29 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <821CBF1C-37E9-4AEE-8279-4763C640464B@gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <20200609231403.GZ23998@brevard.conman.org>
 <821CBF1C-37E9-4AEE-8279-4763C640464B@gmail.com>
Message-ID: <20200610194729.GC10136@SDF.ORG>

On Wed, Jun 10, 2020 at 12:48:52PM +0200, Petite Abeille wrote:
> > On Jun 10, 2020, at 01:14, Sean Conner <sean at conman.org> wrote:
> > 
> >  I copied what I thought was most important, dropped what I didn't
> > understand nor cared for, and that's that.
> 
> Very cool.
> 
> Lot of data. https://tlsfingerprint.io/static/frolov2019.pdf

Thanks a lot for sharing this!  I printed it out for weekend reading.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 20:53:57 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 19:53:57 +0000
Subject: redirect opt-in?
In-Reply-To: <4B177303-41C0-4727-AC3F-EAB12F7D9C86@gmail.com>
References: <4B177303-41C0-4727-AC3F-EAB12F7D9C86@gmail.com>
Message-ID: <20200610195357.GD10136@SDF.ORG>

On Wed, Jun 10, 2020 at 12:49:11PM +0200, Petite Abeille wrote:
> Given that user-agents should refrain from initiating network connection on their own, should redirects (3x)  be manually confirmed? With explicit user consent?

The recent change in the spec regarding automatic initiation of network
connections is very clearly limited in scope to the displaying of link
lines, so redirects are not covered by it.

> Perhaps user-agents SHOULD prompt for decisions as to whether to follow a redirect, or MAY follow redirects automatically.  

Bombadillo is an example of a client which always prompts for a decision
on redirects with (to my knowledge) a single exception (maybe this is
still just planned, not implemented - I don't use Bombadillo often, but
Sloum and I talk about client design a lot).  If a client requests a URL
not ending in a slash, and the server maps it to a directory, the server
must issue a redirect which appends the slash to the URL, otherwise
relative links will not work.  Manually confirming *that* every time
will be annoying and serve no good purpose.

AV-98 is slightly more pragmatic.  If can be configured to prompt on
every redirect, but by defaut it automatically follows all redirects
*except* those which involve moving between domains or between
protocols, which are the most suspicious kinds.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 20:57:46 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 19:57:46 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <8A32AD82-AC96-4826-883C-5BEF248CE337@gmail.com>
References: <20200610073216.GA16028@SDF.ORG>
 <8A32AD82-AC96-4826-883C-5BEF248CE337@gmail.com>
Message-ID: <20200610195746.GE10136@SDF.ORG>

On Wed, Jun 10, 2020 at 01:16:12PM +0200, Petite Abeille wrote:
> 
> 
> > On Jun 10, 2020, at 09:32, solderpunk <solderpunk at SDF.ORG> wrote:
> > 
> > are forced to simply terminate the connection once a threshold amount of content has been downloaded
> 
> Is it really a problem? It should be user-agents prerogative to drop the connection anytime they see fit. And/or only handle a small subset of media type (e.g. text/* only). Ditto for showing network activities. Even the simplest of client could count how many bytes it has read so far, no?
> 

Yes, of course, the client can always drop the connection whenever,
whyever.  But if your goal is to conserve limited or expensive network
traffic, being able to sever the connection immediately after seeing the
first two bytes of the header will be much more effective than
downloading the first MiB of data and then saying "Nope, I can't afford
to finish this" and then throwing away that already-downloaded MiB.

As for counting bytes, in fact AV-98, after parsing the header, simply
reads from the socket until EOF with a single line:

`body = f.read()`

Replacing this with a loop to make smaller reads, calculate their
length, update a counter, and append them to a buffer is much more work
than simply printing a single "This may take a while..." statement after
parsing the header.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:00:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:00:54 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610121603.GA52965@allanon.local>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610121603.GA52965@allanon.local>
Message-ID: <20200610200054.GF10136@SDF.ORG>

On Wed, Jun 10, 2020 at 10:16:03PM +1000, Thomas Karpiniec wrote:
 
> One place I previously used gopher was IP routed over VHF packet
> radio. These links are 1200 baud simplex with an effective throughput
> of some 80 B/s. I'm not saying gemini can or should care what weirdos
> are doing with VHF radios, but it may one day find use in scenarios
> where quantities much less then 1 MB matter. If you're using such a
> slow link, you might have to waste quite a lot of time to realise that
> you're getting an above-average amount of content, reducing the
> effectiveness of a client-side threshold.

In general I'm very happy to entertain the needs of weirdos doing
non-conventional networking where it doesn't conflict with wider goals.

That said, the unavoidable TLS overhead in Gemini means it's unlikely to
be a good match for super slow network scenrios like packet radio.  We
might be able to squeeze it down by pushing adoption of compact
signature algorithms and encouraging use of TLS 1.3's session
resumption, but in general there will be kilobytes of overhead going on.
If quantities much less than 1 MiB matter, I don't think any status
codes are going to make Gemini feasible.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:03:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:03:37 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
Message-ID: <20200610200337.GG10136@SDF.ORG>

On Wed, Jun 10, 2020 at 09:49:14AM -0400, Matthew Graybosch wrote:
 
> I won't presume to recommend that everybody do this, even though it
> would be nice to see my approach become a convention.

I was going to quip that I had already recommended everybody do this in
the Best Practices document and moan once again that nobody ever reads
it...then and checked and, whoops, it's not in there!  How'd that
happen?

I think it is definitely polite to explicitly indicate file sizes for
anything larger than, I dunno, 10 MiB or thereabouts?

Relatedly, as of a semi-recent update, the automatically generated
directory listings produced by Molly Brown include file sizes.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:07:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:07:55 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <CAG-mZ3i9D+Hw9qOvzxhXgDsv8tHMBs5ayARacO5ZiPg0_tksHg@mail.gmail.com>
References: <20200610073216.GA16028@SDF.ORG>
 <CAG-mZ3i9D+Hw9qOvzxhXgDsv8tHMBs5ayARacO5ZiPg0_tksHg@mail.gmail.com>
Message-ID: <20200610200755.GI10136@SDF.ORG>

On Wed, Jun 10, 2020 at 06:20:03PM +0200, Peter Vernigorov wrote:
> Although this makes sense at first glance, I believe that a status code is
> too late to let user know that the file is large. Bytes are already being
> transferred and received by user?s OS, even if client is not reading them
> yet. By the time any of this information is displayed to the user, and the
> time it takes them to react, damage has already been done. I think the only
> sensible solution is for pages to display size information to user next to
> the link.

It's true, and a good point, that stuff may be buffering up in kernel
space even when the client has only read a little bit of it.  If the
idea was to present a prompt to the user, I would agree this may be of
little use.  But if the client itself peeks at the first two bytes and
then immediately closes the connection, I would have thought that would
be quick enough to make a worthwhile impact.  But I admit I'm not too
sure of that.  Maybe actual real world testing would be in order...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:14:47 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:14:47 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <5EE12ED6.9080109@marmaladefoo.com>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610121603.GA52965@allanon.local>
 <5EE12ED6.9080109@marmaladefoo.com>
Message-ID: <20200610201447.GJ10136@SDF.ORG>

On Wed, Jun 10, 2020 at 08:04:54PM +0100, Luke Emmet wrote:
 
> If we can
> have lang and mime-type in the response for 20 response, is it really that
> philosophically disturbing to include this important information that we
> know makes network bandwidth negotiation better for everyone?

Important distinction: we don't have lang *and* MIME type, we have MIME
type.  The text/gemini MIME type has a lang parameter defined.  We're
allowed to define parameters on text/gemini because it's our type (we
can't prescribe parameters on any other text/* type, which by the way is
the answer to some of the questions in
gemini://mozz.us/journal/2020-06-08.gmi).

Adding a content-size parameter to text/gemini *is* deeply
philosophically disturbing because MIME types are, well, *types*.
Categories.  It makes no sense whatsoever to put details specific to a
particular token as part of type declaration.

So the only way to add an analogue of content-length would be to send a
MIME type *and* content-length, and then we need some kind of delmiter.
For the sake of argument, let's say a tab character.

So you send <MIME><TAB><CONTENT-LENGTH> and then, boom, next week it's
<MIME><TAB><CONTENT-LENGTH><TAB><SOMETHING-ELSE>, and it never stops.
Exactly one parameter is a stable, defensible position (what Gemini has
now).  Arbitrarily many delimited parameters is a stable, defensible
position (what the web has now).  Anything in between is at very real
risk, IMHO, of mutating into the latter over time.  Once a delimiter
comes along, it's impossible to stop subsequent expansions.
 
> If we have to, I think it could be a client option:
 
> [ ] limit non-text content to 5Mb per request
> [x] download all text/* content

Well, this second option is actually already totally possible.  As far
as I know, it's not implemented by anybody yet.  I kind of like the
idea, I may add it to AV-98.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:22:59 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:22:59 +0000
Subject: authority's userinfo?
In-Reply-To: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
Message-ID: <20200610202259.GK10136@SDF.ORG>

On Tue, Jun 09, 2020 at 08:58:04PM +0200, Petite Abeille wrote:
> How is gemini meant to deal with authority's userinfo? 
> 
> E.g. 
> 
> gemini://username:password at mozz.us/
> gemini://username at mozz.us/
> 
> Orthodox? 
> 
> If so, how does the server communicate authentication failure back to the client?  
> 
> Thoughts?

I have to admit I was not thrilled to see this come up, predictably
enough.  But you're, of course, right, this is a defined part of the URI
spec.  And, in fact, because clients are already specced as sending a
URL to the server, nothing needs to be done to make this valid.  Most
URL-parsing libraries will probably make it very easy for the server to
extract the username and password.  So, if servers want to make use of
this information, I guess they can.  They can even make use of statuses
10 and 11 to let users setup usernames and passwords.

For this to "catch on", client authors would need to add some support to
make it easy to add this information to queries.  I am not very keen to
add extra status codes to facilitate this.  We already have status codes
in there for an authentication system which has quite some strengths
compared to this (non-brute forcability, much reduced risk of accidental
password leakage through URL copying and pasting, etc.).

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:28:11 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:28:11 +0000
Subject: authority's userinfo?
In-Reply-To: <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
Message-ID: <20200610202811.GL10136@SDF.ORG>

On Wed, Jun 10, 2020 at 01:15:33PM +0200, Felix Quei?ner wrote:
> 
> If your server handles user@ in a different way than without authority,
> i think that's totally in-spec, but authentication is probably not.
> 
> One possible usage for authority could be home-dirs instead of an
> official site:
> 
> Instead of using
> => gemini://random-projects.net/~felix/
> one could also access the directory via
> => gemini://felix at random-projects.net/

Hmm.  But RFC3985 says "The userinfo subcomponent may consist of a user
name and, optionally, scheme-specific information about how to gain
authorization to access the resource".  I think using even just a
username without a password for non-auth purposes is, at the very least,
against the spirit of the spec.

There are practical difficulties, too.  If servers used the username to
select a user directory, instead of the traditional tilde URL, then for
people to be able to meaningfully copy and paste links from their
client's UI, said UI would need to render the userinfo component.
That's going to be very dangerous if some other servers are using it for
actual authentication.

Putting credentials into URLs in general seems like playing with fire to
me.  Client certificates are much safer in this regard, and more useful.
The documentation for an app can say "To change your profile details, go
to gemini://fancyapp.com/edit/profile" and if I'm "logged in" via an
active cert I can follow that link and it will work.  Or I can paste the
URL at which I get an error to the developer to help them debug, and
they don't have to know my identity.  Etc.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:31:04 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:31:04 +0000
Subject: authority's userinfo?
In-Reply-To: <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
Message-ID: <20200610203104.GM10136@SDF.ORG>

On Wed, Jun 10, 2020 at 02:18:47PM +0200, Petite Abeille wrote:

> I was more looking into a way for the client to maintain some states (e.g. preferences) on the server:
> 
> C: gemini://token at mozz.us/?ua=lightweight -- user-agent store its preferences on the server
> S: 30 gemini://token at mozz.us/index.gmi-- redirect to an appropriate resource
> C: gemini://token at mozz.us/index.gmi -- lightweight version of the resource
> S: 20 text/gemini -- customized as per the user-agent stated preferences
> 
> A bit of content negotiation in other words.

I think the entire notion of serving up "lightweight" and "heavyweight"
versions of a resource is very un-Gemini, and application and client
authors are both going to balk at the idea.  The whole point is that
there *are* no heavyweight clients or apps in Geminispace, by design.
How do you make a heavy text/gemini document which isn't intrinsically
heavy by virtue of its content?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 21:49:57 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 20:49:57 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
References: <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
Message-ID: <20200610204957.GN10136@SDF.ORG>

On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote:
 
> TLS_CLIENT_HASH
> 
> I'm using a base64-encoded representation of the hash. I like your notation of
> SHA256:<HEX> better, but it's too late now and I don't want to break backwards
> compatibility.

I am extremely interested in having a well-defined notion of
"certificate fingerprints" in Geminispace, not just for CGI apps but in
server configs too (Molly Brown will soon support being able to
configure lists of authorised certs for accessing certain directories).
It's a shame it's too late for you to make changes now, but for the sake
of all future implementations we should agree on something.

I was actually going to suggest base64-encoded SHA256 of the binary
(PEM) certificate (mostly guided by OpenSSH's use of base64 in
.authorized_keys), but I'm happy to hear thoughts on this.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 22:04:18 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 21:04:18 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
References: <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
Message-ID: <20200610210418.GP10136@SDF.ORG>

On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote:
> 
> > and it always sets TLS_CIPHER and TLS_VERSION.
> 
> Why not? These are just as useful even if the client doesn't send a
> certificate.

Sorry if this is a silly question, but how *are* these useful in a CGI
script?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 22:07:23 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 21:07:23 +0000
Subject: First Gemini CGI application in Rebol
In-Reply-To: <498C6BDC-1925-4FFF-8155-6E3C6344555E@gmail.com>
References: <5EDA6948.403@marmaladefoo.com>
 <20200605203612.GI23998@brevard.conman.org>
 <498C6BDC-1925-4FFF-8155-6E3C6344555E@gmail.com>
Message-ID: <20200610210723.GQ10136@SDF.ORG>

On Fri, Jun 05, 2020 at 10:30:58PM +0100, Luke Emmet wrote:
> 
> > 
> >  Cool.  One comment though---I think you're using an older version of Molly
> > Brown, as your patch 
> > 
> >    1) now duplicates some work the current version of Molly Brown now
> >    does;
> > 
> >    2) won't patch cleanly as the code in Molly Brown has been changed
> >    quite a bit.
> > 
> 
> Ah it's good to see those recent changes. I can get back onto the mainline.

Sorry I haven't better publicised all these recent extensive Molly Brown
changes!  I did not realise people were running substantially modified
versions in the wild.

Cheers,
Solderpunk

From hello at matthewgraybosch.com  Wed Jun 10 22:15:38 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 10 Jun 2020 17:15:38 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610200337.GG10136@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
Message-ID: <20200610171538.0858a0d913ddbe631f41a06a@matthewgraybosch.com>

On Wed, 10 Jun 2020 20:03:37 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> I was going to quip that I had already recommended everybody do this
> in the Best Practices document and moan once again that nobody ever
> reads it...then and checked and, whoops, it's not in there!  How'd
> that happen?

Maybe you had more pressing concerns?
 
> I think it is definitely polite to explicitly indicate file sizes for
> anything larger than, I dunno, 10 MiB or thereabouts?

I'd suggest warning for 1MB because I doubt that most text content
served on Gemini protocol would exceed 100KB per file, and because
section 3.3 of the spec explicitly states that servers are not supposed
to compress content before sending it down the pipe. I mean, I'd love to
see more writers adopt Gemini for long-form work, but I think most
gemlog posts range from 250-2000 words, which might be 25KB at most.

I looked at the markdown file for my trunk novel, and it weighs in at
1.6MB for 289,000 words. I shudder to think of what one might find in a
text file weighing 10MB or more. I'm thinking of something like the
collected works of Leo Tolstoy or a partial dump of Equifax's data
as of 2020.

Of course, 1.6MB is fine on a decent broadband connection, and even
10MB, but I still remember what it was like to try install Gentoo from
stage one (hundreds of megabytes of code) on a dialup connection. It
wasn't fun.

> Relatedly, as of a semi-recent update, the automatically generated
> directory listings produced by Molly Brown include file sizes.

That's sure to come in handy.

-- 
Matthew Graybosch		https://www.matthewgraybosch.com
#include <disclaimer.h>		gemini://starbreaker.org
Harrisburg, PA			gemini://demifiend.org
"Out of order?! Even in the future nothing works."

From solderpunk at SDF.ORG  Wed Jun 10 22:16:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 21:16:37 +0000
Subject: implementing client certificate support
In-Reply-To: <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
References: <20200607185439.zd33kbeffsldnzry@gonzales.net>
 <20200607203720.GG15622@SDF.ORG>
 <20200607224414.pvpcbzjsx6gna3au@gonzales.net>
 <CAFTy05bKUV5JQioGiL8CWX157KAm3dzfj2GM0XPdYR5AJPnXEA@mail.gmail.com>
 <20200608172451.GA12292@SDF.ORG>
 <CAFTy05btW4EA_=NA1c_Be5mK-hZ1sO7g_GntR7FjSaSGjMbzRQ@mail.gmail.com>
Message-ID: <20200610211637.GR10136@SDF.ORG>

On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:
 
> I think hijacking the <META> is unnecessary for my application. I can accomplish
> the same thing by sending a "30 TEMPORARY REDIRECT" to all unauthenticated
> requests, and then hitting them with a 61 after they have been redirected to
> the path scope. I concede that this wouldn't be *exactly* the same because the
> client won't end up at the page that they originally requested. But it's
> workable enough for me. And I like having the meta available for human readable
> error messages.

Hmm...I think I like this.  I mean, I'm never *super* excited when
redirects are involved, but this workflow would allow us to spec
that the default scope of a cert is all paths below the URI from
which the 6x status was received (which lets client certs be much
narrower in scope than cookies, which IMHO is a good selling point)
and still allow human-readable <META> for 6x statuses to provide
hints about expected certificate lifespan.

Cheers,
Solderpunk


From sean at conman.org  Wed Jun 10 22:22:13 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 10 Jun 2020 17:22:13 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610200337.GG10136@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
Message-ID: <20200610212213.GE23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Wed, Jun 10, 2020 at 09:49:14AM -0400, Matthew Graybosch wrote:
>  
> Relatedly, as of a semi-recent update, the automatically generated
> directory listings produced by Molly Brown include file sizes.

  I just added that to GLV-1.12556.  And because of the way I signal CGI and
SCGI scripts, I can also detect those as well.

Index of private/
---------------------------

=> Welcome.txt  Welcome.txt (352 bytes)
=> cgi-sample   cgi-sample (CGI script)
=> christmas-carol.txt  christmas-carol.txt (187995 bytes)
=> mondrian.gif mondrian.gif (3068 bytes)
=> scgi-sample  scgi-sample (SCGI script)

---------------------------
GLV-1.12556

  -spc


From solderpunk at SDF.ORG  Wed Jun 10 22:25:17 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 21:25:17 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610171538.0858a0d913ddbe631f41a06a@matthewgraybosch.com>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200610171538.0858a0d913ddbe631f41a06a@matthewgraybosch.com>
Message-ID: <20200610212517.GS10136@SDF.ORG>

On Wed, Jun 10, 2020 at 05:15:38PM -0400, Matthew Graybosch wrote:
 
> I'd suggest warning for 1MB because I doubt that most text content
> served on Gemini protocol would exceed 100KB per file, and because
> section 3.3 of the spec explicitly states that servers are not supposed
> to compress content before sending it down the pipe.

Just to be clear: servers can use MIME types like application/gzip or
application/zip to serve compressed content if they want to.  There's
just no way to do what HTTP allows, to send compressed data while
specifying both the compression *and* the underlying media type.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 10 22:37:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 21:37:26 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200610204957.GN10136@SDF.ORG>
References: <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
Message-ID: <20200610213726.GU10136@SDF.ORG>

On Wed, Jun 10, 2020 at 08:49:57PM +0000, solderpunk wrote:
 
> I was actually going to suggest base64-encoded SHA256 of the binary
> (PEM) certificate (mostly guided by OpenSSH's use of base64 in
> .authorized_keys), but I'm happy to hear thoughts on this.

Forgot to mention: in the web browser world, using a hexadecimal
encoding of a SHA-family hash with colons between each byte seems to be
the norm.  We could adopt that for familiarity / consistency as well.
It's less compact, but it's also much easier to e.g. verify by eyeball.
 
Cheers,
Solderpunk

From sean at conman.org  Wed Jun 10 22:50:38 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 10 Jun 2020 17:50:38 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200610204957.GN10136@SDF.ORG>
References: <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
Message-ID: <20200610215038.GF23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote:
>  
> > TLS_CLIENT_HASH
> > 
> > I'm using a base64-encoded representation of the hash. I like your notation of
> > SHA256:<HEX> better, but it's too late now and I don't want to break backwards
> > compatibility.
> 
> I am extremely interested in having a well-defined notion of
> "certificate fingerprints" in Geminispace, not just for CGI apps but in
> server configs too (Molly Brown will soon support being able to
> configure lists of authorised certs for accessing certain directories).
> It's a shame it's too late for you to make changes now, but for the sake
> of all future implementations we should agree on something.

  What?  That it's too late for him to change the format he's using for
TLS_CLIENT_HASH?  On thinking on it, why does it matter what the format is? 
It's a hash value---an obstensibly binary blob.  It's a computable unique
identifier for a resource, so does it really matter if you use the binary
format, or some textual format?  Sure, the binary format is a bit more
compact, but that's it.  A CGI (SCGI, other) can still use it as a key---it
may just not be portable between servers, that's all.

  -spc


From solderpunk at SDF.ORG  Wed Jun 10 23:02:26 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 10 Jun 2020 22:02:26 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200610215038.GF23998@brevard.conman.org>
References: <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
 <20200610215038.GF23998@brevard.conman.org>
Message-ID: <20200610220226.GV10136@SDF.ORG>

On Wed, Jun 10, 2020 at 05:50:38PM -0400, Sean Conner wrote:
 
>   What?  That it's too late for him to change the format he's using for
> TLS_CLIENT_HASH?  On thinking on it, why does it matter what the format is? 
> It's a hash value---an obstensibly binary blob.  It's a computable unique
> identifier for a resource, so does it really matter if you use the binary
> format, or some textual format?  Sure, the binary format is a bit more
> compact, but that's it.  A CGI (SCGI, other) can still use it as a key---it
> may just not be portable between servers, that's all.

Sure, but portability of a fingerprint between different servers and
between different CGI apps is extremely desirable.  If I need to
calculate multiple different fingerprints of a given cert in order to
whitelist it in different applications, that's a big barrier to
adoption.

Cheers,
Solderpunk

From sean at conman.org  Wed Jun 10 23:21:36 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 10 Jun 2020 18:21:36 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610073216.GA16028@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
Message-ID: <20200610222136.GG23998@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> Hey all,
> 
> Just throwing out a quick idea I had last night while trying to sleep,
> to see how people feel about it.  It's simple and easily ignorable and I
> think it's kind of neat.

  [ snip ]

> Naturally, deciding to do this will lead immediately to a weeks-long
> heated debate on what the appropriate value of $THRESHOLD should be.  We
> *could* wade into those waters, but I'll just also throw out that we
> could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> 100MiB respectively and leave it at that.  Clients targetting
> resource-limited environments could let their users configure their own
> threshold for early termination of downloads.

  I'm replying here because I think this is the best play to reply with my
thoughts.  I have read the rest of this thread and will be referencing some
later emails.  You have been warned.

  Dispite being the one who pushed for larger status codes, I'm not a fan of
this proposal, but I can't fully explain *why* other than to say "where does
it stop?"  Like Tadeusz Sosnierz alluded too, what's huge today may be small
tomorrow [1].  Personally, I think adding the filesize to the MIME type *is*
the best answer, but I can see and even agree with the arguemnts against it.
And I think I'm justified in saying that [2].

  Petite Abeille has listed the options that are open today, but solderpunk
didn't like the suggestion(s) as they might complicate the client.  But a
client that simply reads the entire response with a single call, while
simple, is a problem waiting to happen.  What if the response doesn't fit
into memory?  It may be reasonable to say that "text/*" can fit into memory,
but video/*?  image/*?  (seriously, I have a 306MB beautiful image of the
moon, probably from NASA).

  I'm not sure what the best solution is though.

  -spc

[1]	The first real editor I used was 40k in size.  Today, there are
	people who use editors that consume over 1G of RAM when running.

[2]	Visual pun, but you have to use a monosopace font to see it.

From petite.abeille at gmail.com  Wed Jun 10 23:43:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 00:43:28 +0200
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610212213.GE23998@brevard.conman.org>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG> <20200610212213.GE23998@brevard.conman.org>
Message-ID: <3BBBF2BD-F0CE-4694-9187-089A1B525396@gmail.com>



> On Jun 10, 2020, at 23:22, Sean Conner <sean at conman.org> wrote:
> 
> => Welcome.txt  Welcome.txt (352 bytes)
> => cgi-sample   cgi-sample (CGI script)
> => christmas-carol.txt  christmas-carol.txt (187995 bytes)
> => mondrian.gif mondrian.gif (3068 bytes)
> => scgi-sample  scgi-sample (SCGI script)

Cool, if not machine readable.

Perhaps would benefit from a human touch ala ls -h:

When used with the -l option, use unit suffixes: Byte, Kilobyte,
Megabyte, Gigabyte, Terabyte and Petabyte in order to reduce the
number of digits to three or less using base 2 for sizes.

So gemini answer to metadata is to emulate ls in text/gemini? :P

From petite.abeille at gmail.com  Wed Jun 10 23:52:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 00:52:18 +0200
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610195746.GE10136@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <8A32AD82-AC96-4826-883C-5BEF248CE337@gmail.com>
 <20200610195746.GE10136@SDF.ORG>
Message-ID: <31C84776-864F-4C64-A70B-171F7370C0DC@gmail.com>



> On Jun 10, 2020, at 21:57, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> As for counting bytes, in fact AV-98, after parsing the header, simply
> reads from the socket until EOF with a single line:

surely the mighty python ecosystem must have the equivalent of  something like pipe viewer, no?

http://www.ivarch.com/programs/pv.shtml

From lazar.michael22 at gmail.com  Wed Jun 10 23:58:38 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Wed, 10 Jun 2020 18:58:38 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200610220226.GV10136@SDF.ORG>
References: <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
Message-ID: <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>

On Wed, Jun 10, 2020 at 4:50 PM solderpunk <solderpunk at sdf.org> wrote:
>
> On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote:
>
> > TLS_CLIENT_HASH
> >
> > I'm using a base64-encoded representation of the hash. I like your notation of
> > SHA256:<HEX> better, but it's too late now and I don't want to break backwards
> > compatibility.
>
> I am extremely interested in having a well-defined notion of
> "certificate fingerprints" in Geminispace, not just for CGI apps but in
> server configs too (Molly Brown will soon support being able to
> configure lists of authorised certs for accessing certain directories).
> It's a shame it's too late for you to make changes now, but for the sake
> of all future implementations we should agree on something.

Ok I'll walk that back. It's too late to make changes *unless* there's a good
reason to do so. I don't want to break CGI variables on a whim anymore, but if
we all agree on a standard then I will follow suit.

From sean at conman.org  Thu Jun 11 00:17:42 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 10 Jun 2020 19:17:42 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <3BBBF2BD-F0CE-4694-9187-089A1B525396@gmail.com>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG> <20200610212213.GE23998@brevard.conman.org>
 <3BBBF2BD-F0CE-4694-9187-089A1B525396@gmail.com>
Message-ID: <20200610231742.GH23998@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Jun 10, 2020, at 23:22, Sean Conner <sean at conman.org> wrote:
> > 
> > => Welcome.txt  Welcome.txt (352 bytes)
> > => cgi-sample   cgi-sample (CGI script)
> > => christmas-carol.txt  christmas-carol.txt (187995 bytes)
> > => mondrian.gif mondrian.gif (3068 bytes)
> > => scgi-sample  scgi-sample (SCGI script)
> 
> Cool, if not machine readable.

  Okay.  The above is the format for GLV-1.12556.  I found two other pages
(from a quick search) that also include file sizes:

Via <gemini://gemini.circumlunar.space/docs/>

# Directory listing

=> / ..
=> best-practices.gmi best-practices.gmi                             5 KiB   Jun  6 2020
=> faq.gmi faq.gmi                                       17 KiB   Jun  7 2020
=> specification.gmi specification.gmi                             30 KiB   Jun  7 2020

And via <gemini://gemini.circumlunar.space/capcom/>

## 2020-06-10

=> gemini://demifiend.org/journal/2020/i-wanted-to-like-mate-too.gemini demifiend - I Wanted to Like MATE, Too (2.2K)
=> gemini://demifiend.org/journal/2020/exit-bug-reports-loyalty.gemini demifiend - Exit, Bug Reports, and Loyalty (4.1K)
=> gemini://gemini.circumlunar.space/~shufei/phlog/Shufei-ThisAndThat-Weiphlog.gmi Shufei?s Gmiphlog - The ?phlog (Weiphlog)
=> gemini://demifiend.org/journal/2020/choose-life.gemini demifiend - Choose Life; or, The Problem with Video Games (12K)
=> gemini://acidic.website/musings/npr-bridge.gmi Musings of Meff - NPR Text Portal and Spec Changes

> Perhaps would benefit from a human touch ala ls -h:

  Perhaps.

> So gemini answer to metadata is to emulate ls in text/gemini? :P

  Appears to be so.

  -spc

From petite.abeille at gmail.com  Thu Jun 11 00:34:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 01:34:12 +0200
Subject: authority's userinfo?
In-Reply-To: <20200610203104.GM10136@SDF.ORG>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
Message-ID: <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>



> On Jun 10, 2020, at 22:31, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>> A bit of content negotiation in other words.
> 
> I think the entire notion of serving up "lightweight" and "heavyweight"

Do not let the specific example distract you from the general concept: content negotiation. Replace "lightweight" & "heavyweight" with "red" & "blue". Or whatever.

The main point is that the URL userinfo bit can be used to maintain states between gemini requests, as it's passed back and forth between client and server.

Actually, it could be used to fingerprint gemini clients automatically:

C: gemini://mozz.us/  
S: 30 gemini://cookie at mozz.us/ 
C: gemini://cookie at mozz.us/
S: 20 text/gemini 
=> gemini://cookie at mozz.us/beer/

A magic cookie!

https://en.wikipedia.org/wiki/Magic_cookie


From tkarpiniec at icloud.com  Thu Jun 11 00:54:29 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Thu, 11 Jun 2020 09:54:29 +1000
Subject: authority's userinfo?
In-Reply-To: <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
Message-ID: <20200610235429.GA2788@MacBook-Pro.local>

On Thu, Jun 11, 2020 at 01:34:12AM +0200, Petite Abeille wrote:
> Actually, it could be used to fingerprint gemini clients automatically:
> 
> C: gemini://mozz.us/  
> S: 30 gemini://cookie at mozz.us/ 
> C: gemini://cookie at mozz.us/
> S: 20 text/gemini 
> => gemini://cookie at mozz.us/beer/
> 
> A magic cookie!

This is possible regardless using query strings, or even more
obnoxiously, dynamic paths/links. At the end of the day all you can do
is call out dodgy behaviour, and if site owners tried it anyway,
attempt to make this sort of thing visible to client users.

Cheers, Tom

From petite.abeille at gmail.com  Thu Jun 11 01:20:17 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 02:20:17 +0200
Subject: authority's userinfo?
In-Reply-To: <20200610235429.GA2788@MacBook-Pro.local>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
Message-ID: <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>



> On Jun 11, 2020, at 01:54, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:
> 
> This is possible regardless using query strings, or even more
> obnoxiously, dynamic paths/links.

Very true. They are all equivalent:

gemini://cookie at mozz.us/beer/
gemini://mozz.us/beer/?cookie
gemini://mozz.us/beer/#cookie
gemini://mozz.us/beer/cookie

Even though, query strings seem to be "special" in gemini, i.e. equivalent to a POST related to 1x (INPUT).

> At the end of the day all you can do
> is call out dodgy behaviour, and if site owners tried it anyway,
> attempt to make this sort of thing visible to client users.

Sure. 

The thought about userinfo was rather less nefarious: a casual way for user-agent to customize their server access.

Same as 6x (CLIENT CERTIFICATE REQUIRED), but less ceremonial.

I.e. automated cookie tagging is the equivalent of server driven 61 TRANSIENT CERTIFICATE REQUESTED.
And named token would be the similar to 62 AUTHORISED CERTIFICATE REQUIRED.

Minus the yak shaving.




From escondida at iff.ink  Thu Jun 11 06:52:36 2020
From: escondida at iff.ink (Ivy Foster)
Date: Thu, 11 Jun 2020 00:52:36 -0500
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610222136.GG23998@brevard.conman.org>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610222136.GG23998@brevard.conman.org>
Message-ID: <20200611055236.GA31679@thrax.localdomain>

On 10 Jun 2020, at  6:21 pm -0400, Sean Conner wrote:
> It was thus said that the Great solderpunk once stated:
> > Just throwing out a quick idea I had last night while trying to sleep,
> > to see how people feel about it.  It's simple and easily ignorable and I
> > think it's kind of neat.
> 
>   [ snip ]
> 
> > Naturally, deciding to do this will lead immediately to a weeks-long
> > heated debate on what the appropriate value of $THRESHOLD should be.  We
> > *could* wade into those waters, but I'll just also throw out that we
> > could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> > 100MiB respectively and leave it at that.  Clients targetting
> > resource-limited environments could let their users configure their own
> > threshold for early termination of downloads.

>   Dispite being the one who pushed for larger status codes, I'm not a fan of
> this proposal, but I can't fully explain *why* other than to say "where does
> it stop?"  Like Tadeusz Sosnierz alluded too, what's huge today may be small
> tomorrow [1].  Personally, I think adding the filesize to the MIME type *is*
> the best answer, but I can see and even agree with the arguemnts against it.
> And I think I'm justified in saying that [2].

I'm aware that this is a very contentious point, but just to throw a
wrench into things...there actually is [an RFC precedent][rfc1341] for
including size as a parameter to a MIME type, even though MIME type is
generally intended to be a classification. Granted, it's intended
specifically for external message bodies, so the user can decide
whether it's worth their while to download...but isn't an external
message body ultimately what any arbitrary file you fetch is anyway?

[rfc1341]: https://tools.ietf.org/html/rfc1341

I totally get it if the answer's still no to a size parameter; the
"where does it end?" argument is a strong one. However, a precedent
for including a very useful piece of information as a MIME type
parameter is still something to consider.

Cheers,
Ivy

From solderpunk at SDF.ORG  Thu Jun 11 10:02:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 09:02:54 +0000
Subject: authority's userinfo?
In-Reply-To: <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
Message-ID: <20200611090254.GA21836@SDF.ORG>

On Thu, Jun 11, 2020 at 02:20:17AM +0200, Petite Abeille wrote:
> > On Jun 11, 2020, at 01:54, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:
> > 
> > This is possible regardless using query strings, or even more
> > obnoxiously, dynamic paths/links.
> 
> Very true. They are all equivalent:
> 
> gemini://cookie at mozz.us/beer/
> gemini://mozz.us/beer/?cookie
> gemini://mozz.us/beer/#cookie
> gemini://mozz.us/beer/cookie

But the userinfo case seems to be clearly the worst.  If a server uses a
redeirect to attach a "cookie" token to the client's URL using a query
or a fragment, that won't get carried across when relative links are
absolutised, so the scope is limited to that one document, unless the
client somehow plays along by recognising the cookie and propagating it
itself (which no sane client will do).  The path option *will* survive
absolutisation, (well, if you  gemini://mozz.us/beer/cookie/, with a 
trailing slash) but to give every visitor a unique cookie and track them
across the site this way (and, yes, I've always known this is
unavoidable, it's mentioned in some of the very earliest Gemini
writings, from before the project even had a name) requires all content
at the site to be dynamically generated.  Which is possible, of course,
but it's a barrier of sorts, at least. 

The userinfo approach both survives absolutisation *and* works with a
perfectly static text/gemini file using relative links.  It's an
extremely easy and lightweight way to unambiguously track users within
one server, and unlike guessing based off IP (which is also of course
unavoidable) it is robust against multiple users sharing an IP at once.
Of the four approaches outlined above, userinfo clearly has a much
higher "damage inflicted to effort required" ratio than the others.

I don't yet have a clear idea of to what extent URI schemes are
permitted to "pick and choose" from the components of the generic URI
scheme as presented in RFC3986.  It is clear that the "authority"
component (what normal people think of as the hostname and port) is not
required, but if a scheme does require an authority does it also *need*
to permit the userinfo?  The gopher URI scheme (RFC4266) a defintion
clearly does not allow one, but URIs for gopher are a tacked on
after-thought and I don't know how carefully that scheme was designed.
But if it's legitimate for me to declare that the gemini:// URI scheme
does not support userinfo, I'll do it in a flash.  This cookie redirect
thought experiment proves that it's far too dangerous, it's just barely
better than an actual HTTP cookie (in that it's not easily sent to third
parties).

Of course, just saying it's unsupported isn't enough, because servers
can try to do it anyway, so every client now needs to explicitly check
for this and either error out or remove the userinfo.

"URIs were a mistake", as the kids say.  Gopher's menu item format might
be a total PITA for users, but you know exactly what the valid scope of
each component is and there are no "side channels".

> > At the end of the day all you can do
> > is call out dodgy behaviour, and if site owners tried it anyway,
> > attempt to make this sort of thing visible to client users.
> 
> Sure. 

Ultimately, yes, but one can try to reduce the number of places
dodginess is possible to be as few as possible to reduce the burden of
playing this whack-a-mole game.

> Same as 6x (CLIENT CERTIFICATE REQUIRED), but less ceremonial.

And also less consensual.  The ceremony is there for a reason.  Gemini
is supposed to be as close to anonymous by default as the limitations of
running it over TCP/IP allow.  Turning that off, to partake of an
application which maintains state, is *supposed* to be a song and dance.
It should be impossible to not realise you're doing it.  I don't even
mind if doing it is slightly inconvenient, because it should always be a
conscious and considered choice.  It should also be extremely easy to
write a client which is obviously totally incapable of doing it.

Yes, this rules out the notion of "lightweight content-negotiation".  So
what?  Has anybody ever once missed that concept in Gopherspace, or in
nascent Geminispace?  How much value does that idea have for a network
where the majority of content is very minimally formatted plaintext?
Could it ever possibly be worth the risk of introducing something which
can be twisted to act as a cookie?

Sometimes taking a strong stand against very clearly very bad things
(pervasive and uncontrollable tracking) means choosing to live without
some nice things that seem harmless on the surface.  It's a shame, but
that's the way it is.  Thankfully it turns out most nice things are
actually pretty easy to do without once you get rid of it.

> I.e. automated cookie tagging is the equivalent of server driven 61 TRANSIENT CERTIFICATE REQUESTED.

Characterising 6x status codes as "server driven" is extremely
misleading.  The server can only issue *requests* for a certificate.
There is no mechanism for the server to just ram one down the client's
throat.  The client has to opt in, and they can at any point opt-out.
If I delete the private key matching a certificate, that's the end of
that identity.  I'd call that "client driven".  If I delete one of your
userinfo cookies, the server can recognise my IP and feed me the same
value again, resurrecting it.  Yes, there's a risk they'll get it wrong
if that IP is a pubnix or VPN address, but probabilistic persistent
tracking is better than no tracking at all, so they'll try it, and will
be right some of the time.

> Minus the yak shaving.

I guess some yaks are our friends.

Cheers,
Solderpunk

From luke at marmaladefoo.com  Thu Jun 11 10:52:34 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 11 Jun 2020 10:52:34 +0100
Subject: [ANN] GemiNaut 0.8.4 released
Message-ID: <5EE1FEE2.4050303@marmaladefoo.com>

Hi Folks

I'm pleased to announce a new release of GemiNaut, which now has a home 
in geminispace as well as on the web:

=> gemini://gemini.marmaladefoo.com/geminaut/

GemiNaut is a Windows client for gemini, designed with usability in mind 
and to assist the cognitive navigation through the sparse metadata of 
the geminiverse.

Main changes to 0.8.4:

* use correct percent encoding for URL requests with input
* support quotation line style (new addition to Gemini spec)
* provide salient icon hints to common non textual content (images, 
audio, video, docs)
* minor bug fixes, style updates and improvements

As always, feedback and improvement suggestions are welcomed.

Best Wishes

  - Luke

From tkarpiniec at icloud.com  Thu Jun 11 10:58:45 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Thu, 11 Jun 2020 19:58:45 +1000
Subject: authority's userinfo?
In-Reply-To: <20200611090254.GA21836@SDF.ORG>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG>
Message-ID: <20200611095845.GA11312@MacBook-Pro.local>

On Thu, Jun 11, 2020 at 09:02:54AM +0000, solderpunk wrote:
> But if it's legitimate for me to declare that the gemini:// URI scheme
> does not support userinfo, I'll do it in a flash.  This cookie redirect
> thought experiment proves that it's far too dangerous, it's just barely
> better than an actual HTTP cookie (in that it's not easily sent to third
> parties).

By my reading of RFC 3986 (s3.2) you explicitly have that right:

"Some schemes do not allow the userinfo and/or port subcomponents."

> Of course, just saying it's unsupported isn't enough, because servers
> can try to do it anyway, so every client now needs to explicitly check
> for this and either error out or remove the userinfo.

In my experience, an advanced client requires a certain amount of URL
munging anyway (at least if you want to pass Sean's test suite).
Saying that a client SHOULD remove any userinfo component before
initiating a request is not an undue burden. But at the same time it's
clearly not required for a minimally functional client.

Cheers, Tom

From petite.abeille at gmail.com  Thu Jun 11 12:32:00 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 13:32:00 +0200
Subject: authority's userinfo?
In-Reply-To: <20200610202811.GL10136@SDF.ORG>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <20200610202811.GL10136@SDF.ORG>
Message-ID: <2F0A88BB-AD8E-4625-B45F-414331264171@gmail.com>



> On Jun 10, 2020, at 22:28, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> against the spirit of the spec

Specifications are mechanisms. Tools. Syntax. To be combined in interesting and curious ways. To an end. Spirituality has nothing to do with it.

An oldie, but a goodie:

"Why specs matter"
-- Mark Pilgrim, circa 2004
https://pwn.ersh.io/notes/why_specs_matter/

https://en.wikipedia.org/wiki/Mark_Pilgrim
https://web.archive.org/web/20051016203842/http://diveintomark.org/archives/2004/08/16/specs
https://github.com/dpk/diveintomark/blob/master/archive-html/74bd6e47732d711fafd1fdb131006daae30709cf.html







From petite.abeille at gmail.com  Thu Jun 11 12:37:46 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 13:37:46 +0200
Subject: authority's userinfo?
In-Reply-To: <20200611090254.GA21836@SDF.ORG>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG>
Message-ID: <D85F9616-E98F-487D-9423-DF06DF20C5A6@gmail.com>



> On Jun 11, 2020, at 11:02, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> The userinfo approach both survives absolutisation *and* works with a
> perfectly static text/gemini file using relative links.  It's an
> extremely easy and lightweight way to unambiguously track users within
> one server, and unlike guessing based off IP (which is also of course
> unavoidable) it is robust against multiple users sharing an IP at once.
> Of the four approaches outlined above, userinfo clearly has a much
> higher "damage inflicted to effort required" ratio than the others.

Thanks. 

That said, this all hinges on automated redirects, beyond end-user control, all opaque to them. This is the crux of the issue.

If user-agents MUST-SHOULD prompt for decisions as to whether to follow a redirect, this would be all transparent and under user control.

If you truly care about user control and transparency, this is the inflection point.



From petite.abeille at gmail.com  Thu Jun 11 12:49:41 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 13:49:41 +0200
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610195746.GE10136@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <8A32AD82-AC96-4826-883C-5BEF248CE337@gmail.com>
 <20200610195746.GE10136@SDF.ORG>
Message-ID: <1A720CCB-32A7-4746-8E59-33967FE59792@gmail.com>



> On Jun 10, 2020, at 21:57, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Yes, of course, the client can always drop the connection whenever,
> whyever.  But if your goal is to conserve limited or expensive network
> traffic, being able to sever the connection immediately after seeing the
> first two bytes of the header will be much more effective than
> downloading the first MiB of data and then saying "Nope, I can't afford
> to finish this" and then throwing away that already-downloaded MiB.

Perhaps servers could introduce a slight delay between sending the status line and the content itself.

That way, a client may have enough time to drop the connection before the server has actually started to saturate the link with content.

This may address Peter Vernigorov showstopper:

"I believe that a status code is too late to let user know that the file is large. Bytes are already being transferred and received by user?s OS, even if client is not reading them yet. By the time any of this information is displayed to the user, and the time it takes them to react, damage has already been done."

From tomasino at lavabit.com  Thu Jun 11 13:03:04 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 11 Jun 2020 12:03:04 +0000
Subject: authority's userinfo?
In-Reply-To: <2F0A88BB-AD8E-4625-B45F-414331264171@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <20200610202811.GL10136@SDF.ORG>
 <2F0A88BB-AD8E-4625-B45F-414331264171@gmail.com>
Message-ID: <787cf679-800b-ec00-0277-1bb0f4c9ce82@lavabit.com>

On 6/11/20 11:32 AM, Petite Abeille wrote:
>> On Jun 10, 2020, at 22:28, solderpunk <solderpunk at SDF.ORG> wrote:
>> against the spirit of the spec
> Specifications are mechanisms. Tools. Syntax. To be combined in interesting and curious ways. To an end. Spirituality has nothing to do with it.

A 'spirit' is intentionality, the heart of what a spec is trying to communicate. The tools and syntax serve this end.

If you are referring to yourself with the why_specs_matter link, then I would suggest a useful "asshole" would identify these concepts that are contrary to the intentions of gemini and recommend solutions in the spec to prevent them rather than circumventing those intentions.


From petite.abeille at gmail.com  Thu Jun 11 13:37:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 14:37:19 +0200
Subject: authority's userinfo?
In-Reply-To: <787cf679-800b-ec00-0277-1bb0f4c9ce82@lavabit.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <20200610202811.GL10136@SDF.ORG>
 <2F0A88BB-AD8E-4625-B45F-414331264171@gmail.com>
 <787cf679-800b-ec00-0277-1bb0f4c9ce82@lavabit.com>
Message-ID: <49ED8B72-540B-4A00-99F3-AEEA04CB33E3@gmail.com>



> On Jun 11, 2020, at 14:03, James Tomasino <tomasino at lavabit.com> wrote:
> 
> A 'spirit' is intentionality, the heart of what a spec is trying to communicate. The tools and syntax serve this end.

I would venture only concrete implementations have actual intentionality. On the other hand, how many angels can dance on the head of a pin?

> If you are referring to yourself with the why_specs_matter link, then I would suggest a useful "asshole" would identify these concepts that are contrary to the intentions of gemini and recommend solutions in the spec to prevent them rather than circumventing those intentions.

Exactly.

[2020-06-11T11:55:23.337Z] <@tomasino> ugh, Petite Abeille again

Did I overdo it? Apologies.

Still, shooting the messenger do not change the facts on the ground.

Gemini has 3 basic moving parts: URI, MIME, and TLS.

To be useful -as in actionable- the spec should be cognizant of their reach and define clear boundaries if necessary.

A prescriptive specification is fine, a touchy-feely one less so.



From solderpunk at SDF.ORG  Thu Jun 11 16:09:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 15:09:12 +0000
Subject: authority's userinfo?
In-Reply-To: <20200611095845.GA11312@MacBook-Pro.local>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG>
 <20200611095845.GA11312@MacBook-Pro.local>
Message-ID: <20200611150912.GA7373@SDF.ORG>

On Thu, Jun 11, 2020 at 07:58:45PM +1000, Thomas Karpiniec wrote:
 
> By my reading of RFC 3986 (s3.2) you explicitly have that right:
> 
> "Some schemes do not allow the userinfo and/or port subcomponents."

Thanks very much for finding that.  I realise it must seem ridiculous
that I'm building on top of these RFCs without having read then in fine
detail.  I would *love* to have the time to print out the URI, MIME and
TLS RFCs, sit down with a coffee and a pen and go through them all
closely, but it's not likely to happen anytime soon.  I am grateful to
be able to "crowdsource" some details.

And this is great news.  I will update the spec this weekend - to
simplify the client certificate stuff as discussed, but at the same time
I will add a new section defining the Gemini URI scheme and explicitly
disallowing the userinfo component.

Servers receiving a request whose URL contains a userinfo component
should respond with "59 BAD REQUEST".  Clients should strip userinfo
from links in text/gemini documents or status 3x <META> lines.  Then
this nasty loophole is closed.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 11 16:09:53 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 15:09:53 +0000
Subject: authority's userinfo?
In-Reply-To: <2F0A88BB-AD8E-4625-B45F-414331264171@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <20200610202811.GL10136@SDF.ORG>
 <2F0A88BB-AD8E-4625-B45F-414331264171@gmail.com>
Message-ID: <20200611150953.GB7373@SDF.ORG>

On Thu, Jun 11, 2020 at 01:32:00PM +0200, Petite Abeille wrote:
 
> An oldie, but a goodie:
> 
> "Why specs matter"
> -- Mark Pilgrim, circa 2004
> https://pwn.ersh.io/notes/why_specs_matter/

An enjoyable and short read, thanks!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 11 16:25:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 15:25:19 +0000
Subject: authority's userinfo?
In-Reply-To: <D85F9616-E98F-487D-9423-DF06DF20C5A6@gmail.com>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG>
 <D85F9616-E98F-487D-9423-DF06DF20C5A6@gmail.com>
Message-ID: <20200611152519.GC7373@SDF.ORG>

On Thu, Jun 11, 2020 at 01:37:46PM +0200, Petite Abeille wrote:
 
> Thanks. 

I didn't *mean* that as a compliment, but upon reflection you're right
to take it as one.  To be frank, your posts often frustrate me or stress
me out, but I realise that you are, in fact, performing a valuable
service in pointing out loopholes and overlooked details, and this one in
particular was a very valuable catch, thankfully easily fixed.  I hope to
goodness this was the last surprise of this magnitude that you manage to
dig up.
 
> That said, this all hinges on automated redirects, beyond end-user control, all opaque to them. This is the crux of the issue.

That's true, it's not quite fair to blame this entirely on the generic
URI scheme, the issue also highlights the dangers posed by redirects.

> If user-agents MUST-SHOULD prompt for decisions as to whether to follow a redirect, this would be all transparent and under user control.

Also true, but the case of phishing in the web/email world demonstrates
precisely how well relying on users to be able to reliably detect nasty
things via manual inspection of URLs works out in practice.  In this
particular case, given the dubious value of userinfo for Gemini in the
first place, it's much simpler and much more reliable to simply remove
the threat entirely, than to expect people to catch it themselves.

I will consider pushing more strongly for manual intervention in
redirects, but I'm very aware that taking this to extremes will
inevitably result in training users to approve the follow automatically
without a moment's thought.  Much better to make redirects themselves
as safe as we can.

MUST-SHOULDing confirmation for cross-domain redirects might be a good
idea, though.  Those pose a great risk, with the potential for execrable
link shorteners.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 11 16:28:24 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 15:28:24 +0000
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <5EE1FEE2.4050303@marmaladefoo.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
Message-ID: <20200611152824.GD7373@SDF.ORG>

On Thu, Jun 11, 2020 at 10:52:34AM +0100, Luke Emmet wrote:
 
> * provide salient icon hints to common non textual content (images, audio,
> video, docs)

As guessed from file extensions, I suppose?

That seems like a pretty good idea.  I applaud your consistent attention
to this kind of detail, it encourages a high situational awareness on
the part of the user.

Cheers,
Solderpunk

From luke at marmaladefoo.com  Thu Jun 11 16:52:48 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 11 Jun 2020 16:52:48 +0100
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <20200611152824.GD7373@SDF.ORG>
References: <5EE1FEE2.4050303@marmaladefoo.com> <20200611152824.GD7373@SDF.ORG>
Message-ID: <5EE25350.80104@marmaladefoo.com>



On 11-Jun-2020 16:28, solderpunk wrote:
> On Thu, Jun 11, 2020 at 10:52:34AM +0100, Luke Emmet wrote:
>
>> * provide salient icon hints to common non textual content (images, audio,
>> video, docs)
> As guessed from file extensions, I suppose?
Yes. There are 5 main categories at present:

  - audio (mp3, ogg, wav...)
  - images (png jpg svg ...)
  - documents (pdf html doc...)
  - binary (gz tar zip...)
  - video (wmv mov mp4...)

Its not 100% foolproof, but almost always right. It intentionally does 
not do this to URLs having queries on them, since one might be 
*searching* for ".gz" in GUS thus:

=> gemini://gus.guru/search?.gz

and you don't want the link to the second pages of results to be 
interpreted as a link to a binary

=> gemini://gus.guru/search/2?.gz

I've found this useful for some time, and in fact is a liberation that 
interpreting links in general in Gemini is a million times more 
straightforward than on the web where it seems everything is behind a 
dynamic link these days.

As we have all discovered, clicking on a binary link is likely to:

  - throw you out of your current reading context, into a graphical world
  - be a slower download (and in gemini we dont know how long we might wait)
  - might launch some external application, taking time and mental energy

So it is nice to have a good hint as to what will happen on those links.

And of course, the actual feasibility of writing your own Gemini client 
means we can fix all the things like this that are much harder to fix on 
the web where the server completely controls the user experience.

> That seems like a pretty good idea.  I applaud your consistent attention
> to this kind of detail, it encourages a high situational awareness on
> the part of the user.

Thanks!

Best Wishes

  - Luke

From petite.abeille at gmail.com  Thu Jun 11 17:02:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 18:02:48 +0200
Subject: authority's userinfo?
In-Reply-To: <20200611150912.GA7373@SDF.ORG>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG> <20200611095845.GA11312@MacBook-Pro.local>
 <20200611150912.GA7373@SDF.ORG>
Message-ID: <80080225-DCC9-4413-83EA-FC879C89C94C@gmail.com>



> On Jun 11, 2020, at 17:09, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> And this is great news.  I will update the spec this weekend - to
> simplify the client certificate stuff as discussed, but at the same time
> I will add a new section defining the Gemini URI scheme and explicitly
> disallowing the userinfo component.

Cool.

May I suggest two further, hmmm, tightenings?

(1) Mandate a line length limit for every gemini artifacts, both protocol and text format. 1024 bytes for everything. 
(2) Normalize all the sigils to <SIGIL><SPACE>. Drop the optional whitespace concoction [<whitespace>].

From petite.abeille at gmail.com  Thu Jun 11 17:05:06 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 18:05:06 +0200
Subject: authority's userinfo?
In-Reply-To: <20200611150953.GB7373@SDF.ORG>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <20200610202811.GL10136@SDF.ORG>
 <2F0A88BB-AD8E-4625-B45F-414331264171@gmail.com>
 <20200611150953.GB7373@SDF.ORG>
Message-ID: <A23505CA-1270-4047-9049-BF5F0AD62085@gmail.com>



> On Jun 11, 2020, at 17:09, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>> An oldie, but a goodie:
>> 
>> "Why specs matter"
>> -- Mark Pilgrim, circa 2004
>> https://pwn.ersh.io/notes/why_specs_matter/
> 
> An enjoyable and short read, thanks!

You are welcome :)



From petite.abeille at gmail.com  Thu Jun 11 17:07:40 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 18:07:40 +0200
Subject: authority's userinfo?
In-Reply-To: <20200611152519.GC7373@SDF.ORG>
References: <88FD6659-4B29-470D-9AF9-CD8C1E39A171@gmail.com>
 <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG>
 <D85F9616-E98F-487D-9423-DF06DF20C5A6@gmail.com>
 <20200611152519.GC7373@SDF.ORG>
Message-ID: <6DF18F42-4522-4E34-9942-EE8BB57C5E6A@gmail.com>



> On Jun 11, 2020, at 17:25, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>> Thanks. 
> 
> I didn't *mean* that as a compliment, but upon reflection you're right
> to take it as one.  To be frank, your posts often frustrate me or stress
> me out, but I realise that you are, in fact, performing a valuable
> service in pointing out loopholes and overlooked details, and this one in
> particular was a very valuable catch, thankfully easily fixed.  I hope to
> goodness this was the last surprise of this magnitude that you manage to
> dig up.

Do not poke the bear :P

But do look at TLS fingerprinting. Gemini traffic should blend in with the crowd, and not stand out in any obvious ways.


From petite.abeille at gmail.com  Thu Jun 11 17:40:50 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 18:40:50 +0200
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <5EE25350.80104@marmaladefoo.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <20200611152824.GD7373@SDF.ORG> <5EE25350.80104@marmaladefoo.com>
Message-ID: <E19FE46E-4228-4DCF-8742-EA538DF3F985@gmail.com>



> On Jun 11, 2020, at 17:52, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> - audio (mp3, ogg, wav...)
> - images (png jpg svg ...)
> - documents (pdf html doc...)
> - binary (gz tar zip...)
> - video (wmv mov mp4...)

There are 10 main media types defined [1]:

? application
? audio
? font
? example
? image
? message
? model
? multipart
? text
? video

For the ones you don't identify, application/octet-stream is a good default (i.e. binary) [2]. 

There are 3 levels of heuristic you can apply:

(1) last path segment extension
(2) response content type
(3) content signature [3]

Ideally, they should all align. If not, perhaps worthwhile flagging them to the user for discrepancies, to exercise caution. This would also help keeping servers on their toes.

[1] https://www.iana.org/assignments/media-types/media-types.xhtml
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
[3] https://en.wikipedia.org/wiki/List_of_file_signatures



From luke at marmaladefoo.com  Thu Jun 11 17:48:14 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 11 Jun 2020 17:48:14 +0100
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <E19FE46E-4228-4DCF-8742-EA538DF3F985@gmail.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <20200611152824.GD7373@SDF.ORG> <5EE25350.80104@marmaladefoo.com>
 <E19FE46E-4228-4DCF-8742-EA538DF3F985@gmail.com>
Message-ID: <5EE2604E.70208@marmaladefoo.com>

On 11-Jun-2020 17:40, Petite Abeille wrote:
> On Jun 11, 2020, at 17:52, Luke Emmet <luke at marmaladefoo.com> wrote:
>> - audio (mp3, ogg, wav...)
>> - images (png jpg svg ...)
>> - documents (pdf html doc...)
>> - binary (gz tar zip...)
>> - video (wmv mov mp4...)
> There are 10 main media types defined [1]:
>
> ? application
> ? audio
> <snip>
>
> For the ones you don't identify, application/octet-stream is a good default (i.e. binary) [2].
>
> There are 3 levels of heuristic you can apply:
>
> (1) last path segment extension
> (2) response content type
> (3) content signature [3]
Thanks for the links. At the stage I am providing the UI hints is when 
rendering the page, before the user has clicked on anything, so I cannot 
get the content type or content signature. But once you start getting 
the content you definitely have more to go on, when deciding what to do.

My main drive at this stage was to cover the fat end of the extensions 
actually in use, as helpfully detailed by GUS:

gemini://gus.guru/statistics

Best wishes

  - Luke

From petite.abeille at gmail.com  Thu Jun 11 17:55:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 18:55:58 +0200
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <5EE25350.80104@marmaladefoo.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <20200611152824.GD7373@SDF.ORG> <5EE25350.80104@marmaladefoo.com>
Message-ID: <B49E67A4-FE97-4473-A863-03C4CAA570BB@gmail.com>



> On Jun 11, 2020, at 17:52, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> As we have all discovered, clicking on a binary link is likely to:
> 
> - throw you out of your current reading context, into a graphical world
> - be a slower download (and in gemini we dont know how long we might wait)
> - might launch some external application, taking time and mental energy

Of course this is all under your client control. None of this has to happen haphazardly. UX and all.

(1) some common content could be rendered to text for preview purpose perhaps. A sort of sanitization.
(2) external resource acquisition can be as asynchronous, non-blocking, and responsive as you choose to make them
(3) a good UX would be predictable and configurable, with reasonable defaults


From solderpunk at SDF.ORG  Thu Jun 11 18:19:56 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 17:19:56 +0000
Subject: authority's userinfo?
In-Reply-To: <80080225-DCC9-4413-83EA-FC879C89C94C@gmail.com>
References: <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG>
 <20200611095845.GA11312@MacBook-Pro.local>
 <20200611150912.GA7373@SDF.ORG>
 <80080225-DCC9-4413-83EA-FC879C89C94C@gmail.com>
Message-ID: <20200611171956.GA29628@SDF.ORG>

On Thu, Jun 11, 2020 at 06:02:48PM +0200, Petite Abeille wrote:
> Cool.
> 
> May I suggest two further, hmmm, tightenings?
> 
> (1) Mandate a line length limit for every gemini artifacts, both protocol and text format. 1024 bytes for everything. 

With regard to the protocol, isn't this already the case?

>From section 2:

```
Gemini requests are a single CRLF-terminated line with the following
structure:

<URL><CR><LF>

<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
```

So, that's requests handled.

>From section 3.1:

```
Gemini response headers look like this:

<STATUS><SPACE><META><CR><LF>

<STATUS> is a two-digit numeric status code, as described below in 3.2 and in
Appendix 1.

<META> is a UTF-8 encoded string of maximum length 1024 bytes, whose
meaning is <STATUS> dependent.
```

So, that's responses handled.

What am I forgetting?

With regard to lines of text/gemini, that's unfortunately not really
compatible with the idea that content should be written with long lines
and then wrapped by the client to fit the viewport.  It took *months* of
discussion and arguing to settle on that convention and now that I've
had a chance to see it in action I'm actually pretty fond of it.  Having
content display cleanly on different devices is quite nice, and almost a
pre-requisite for widespread adoption in the modern world (not that
widespread adoption is an explicit goal of the project, but there's no
reason to stand in the way of it without good cause).  I can't think of
any way to achieve that property with a short fixed line length that
doesn't tremendously complicate rendering.

What's the motivation for this in text/gemini?

> (2) Normalize all the sigils to <SIGIL><SPACE>. Drop the optional whitespace concoction [<whitespace>].

Does anybody else have strong feelings on this, one way or the other?
After the change to the list item definition, this *would* increase
consistency in the spec, which is generally a good thing.  But dealing
with optional whitespace is not exactly difficult for clients to do and
I feel like a little bit of flexibility in something designed to be
written by humans is not a bad thing...

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 11 18:34:13 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 17:34:13 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200611055236.GA31679@thrax.localdomain>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610222136.GG23998@brevard.conman.org>
 <20200611055236.GA31679@thrax.localdomain>
Message-ID: <20200611173413.GB29628@SDF.ORG>

On Thu, Jun 11, 2020 at 12:52:36AM -0500, Ivy Foster wrote:
 
> I'm aware that this is a very contentious point, but just to throw a
> wrench into things...there actually is [an RFC precedent][rfc1341] for
> including size as a parameter to a MIME type, even though MIME type is
> generally intended to be a classification. Granted, it's intended
> specifically for external message bodies, so the user can decide
> whether it's worth their while to download...but isn't an external
> message body ultimately what any arbitrary file you fetch is anyway?
> 
> [rfc1341]: https://tools.ietf.org/html/rfc1341

Well, that is unexpected!  I guess practicality beats the idea of
semantic purity even in "real specs".

> I totally get it if the answer's still no to a size parameter; the
> "where does it end?" argument is a strong one. However, a precedent
> for including a very useful piece of information as a MIME type
> parameter is still something to consider.

It definitely weakens my argument that file size is not appropriate
information to attach to a MIME type.  Nevertheless, it's still true
that we only get to dictate the permissible parameters for the one MIME
type that we are actually defining ourselves.  All other registered MIME
types, including all the image/*, audio/* and video/* types which are
liable to be the most common large files, have their own pre-defined
list of registered parameters and we shouldn't be adding extras of our
own.

Maybe we just need to (continue to) let the file size issue go.  I won't
deny that it's useful, but (as so often) Gopherspace is the existence
proof that useful and valuable stuff can be built without it.

The concern about users without fast and cheap internet which was part
of the motivation for my recent suggestion for more 2x codes was
genuine, and it would have been one more nice utilisation of the "two
digit codes which degrade gracefully into one digit codes" philosophy
(which I think is neat but worry that we perhaps don't utilise enough
to make it worth while), but as was pointed out in the ensuing
discussion, most text/* content is likely to be quite small and clients
can already terminate connections early on the basis of a non text/*
MIME type in precisely the way that I was proposing they should do on
the receipt of a 2x code above their threshold.  So, they can get quite
a lot of the benefit of that proposal with no changes required.  I think
I will add an option to quick-terminate on non-text content to AV-98.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 11 18:37:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 17:37:03 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
References: <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
 <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
Message-ID: <20200611173703.GC29628@SDF.ORG>

On Wed, Jun 10, 2020 at 06:58:38PM -0400, Michael Lazar wrote:
 
> Ok I'll walk that back. It's too late to make changes *unless* there's a good
> reason to do so. I don't want to break CGI variables on a whim anymore, but if
> we all agree on a standard then I will follow suit.

You're not storing these hashes in some kind of database for
Astrobotany?  Wouldn't changing how you calcultate the TLS_CLIENT_HASH
variable break a lot of accounts?

Cheers,
Solderpunk

From petite.abeille at gmail.com  Thu Jun 11 18:54:44 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 19:54:44 +0200
Subject: authority's userinfo?
In-Reply-To: <20200611171956.GA29628@SDF.ORG>
References: <7cb57d7c-2201-89d4-8aff-9271debc5d03@masterq32.de>
 <B3E00F75-9446-4ADA-A669-2D70C4978E59@gmail.com>
 <20200610203104.GM10136@SDF.ORG>
 <3D0F64A5-5FE0-4F41-B188-18B886D8A4BE@gmail.com>
 <20200610235429.GA2788@MacBook-Pro.local>
 <E712874E-D4ED-46FB-AA99-F8FC937C1DC8@gmail.com>
 <20200611090254.GA21836@SDF.ORG> <20200611095845.GA11312@MacBook-Pro.local>
 <20200611150912.GA7373@SDF.ORG>
 <80080225-DCC9-4413-83EA-FC879C89C94C@gmail.com>
 <20200611171956.GA29628@SDF.ORG>
Message-ID: <5F51FAEC-8FDF-473E-9151-2ACF217FD0FE@gmail.com>



> On Jun 11, 2020, at 19:19, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> What's the motivation for this in text/gemini?

Mostly the link line, which contains an URL. If limiting overall line length is a nuisance, perhaps just applying the 1024 limit to the URL itself would do.

In term of the spec, this could be stated as ANY URLs, be it in the request, response, or links, MUST be 1024  bytes long at most.

Similar to HTML's LITLEN limit, which is 1024 in some contexts - as pointed out by Sean a while back.

This would positively constrain the reach of all those marvelous URL schemes you don't approve of, while not eliminating their experimental use altogether :D

From solderpunk at SDF.ORG  Thu Jun 11 18:58:29 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 17:58:29 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG>
 <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
Message-ID: <20200611175829.GD29628@SDF.ORG>

On Tue, Jun 09, 2020 at 09:02:24PM -0400, Michael Lazar wrote:
 
> I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME
> should be the part of the URI path that comes before the PATH_INFO [1]. So in
> your example:
> 
> GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
> SCRIPT_NAME=/cgi-bin/beta
> PATH_INFO=/foobar

Is this how cgi-bins are traditionally handled?  If a URI paths's prefix
matches the configured cgi-bin path, the standard mapping from URI paths
to the filesystem is interrupted, and the first component of the URI path
*after* the cgi-bin prefix (here `beta`) is the only think looked for on
the disk, with everything else passed along to PATH_INFO?  If there is,
for example, a /var/gemini/cgi-bin/beta/ directory on the disk, the
server does not check for an executable named `foobar` in it?

Semi-related: when the server forks off the CGI process, is it
conventional to set that process' working directory to the CGI bin?

Cheers,
Solderpunk

From petite.abeille at gmail.com  Thu Jun 11 19:26:32 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 20:26:32 +0200
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611175829.GD29628@SDF.ORG>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200611175829.GD29628@SDF.ORG>
Message-ID: <143C2FA5-FB1F-4E6C-BA30-625E6E944BC2@gmail.com>



> On Jun 11, 2020, at 19:58, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Is this how cgi-bins are traditionally handled? 

Is there be any interest in D. J. Bernstein's ucspi-tcp [1] in this time and age? As a nimbler alternative to CGI perhaps?

ucspi-tcp defines the following environment variables:

$PROTO is the string TCP.
$TCPLOCALIP is the IP address of the local host, in dotted-decimal form.
$TCPLOCALPORT is the local TCP port number, in decimal.
$TCPLOCALHOST is the name listed in DNS for the local host. If no name is available, $TCPLOCALHOST is not set. Beware that $TCPLOCALHOST can contain arbitrary characters.
$TCPREMOTEIP is the IP address of the remote host, in dotted-decimal form.
$TCPREMOTEPORT is the remote TCP port number, in decimal.
$TCPREMOTEHOST is the name listed in DNS for the remote host. If no name is available, $TCPREMOTEHOST is not set. Beware that $TCPREMOTEHOST can contain arbitrary characters.
$TCPREMOTEINFO is a connection-specific string supplied by the remote host via the 931/1413/IDENT/TAP protocol. If no information is available, $TCPREMOTEINFO is not set. Beware that $TCPREMOTEINFO can contain arbitrary characters.

The TLS flavor [2] add these:

SSL_PROTOCOL The TLS protocol version (SSLv3, TLSv1, ...).
SSL_SESSION_ID The hex-encoded SSL session id.
SSL_CIPHER  The cipher specification name.
SSL_CIPHER_USEKEYSIZE Number of cipher bits (actually used).
SSL_CIPHER_ALGKEYSIZE Number of cipher bits (possible).
SSL_VERSION_INTERFACE The mod_ssl program version.
SSL_VERSION_LIBRARY The OpenSSL program version.
SSL_CLIENT_M_VERSION The version of the client certificate.
SSL_CLIENT_M_SERIAL The serial of the client certificate.
SSL_CLIENT_S_DN Subject DN in client's certificate.
SSL_CLIENT_S_DN_x509 Component of client's Subject DN.
SSL_CLIENT_I_DN Issuer DN of client's certificate.
SSL_CLIENT_I_DN_x509 Component of client's Issuer DN.
SSL_CLIENT_V_START Validity of client's certificate (start time).
SSL_CLIENT_VERIFY NONE, SUCCESS, GENEROUS or FAILED:reason.
SSL_SERVER_M_SERIAL The serial of the server certificate.
SSL_SERVER_S_DN Subject DN in server's certificate.
SSL_SERVER_S_DN_x509 Component of server's Subject DN.
SSL_SERVER_I_DN Issuer DN of server's certificate.
SSL_SERVER_I_DN_x509 Component of server's Issuer DN.
SSL_SERVER_V_START Validity of server's certificate (start time).
SSL_SERVER_V_END Validity of server's certificate (end time).
SSL_SERVER_A_SIG Algorithm used for the signature of server's certificate.
SSL_SERVER_A_KEY Algorithm used for the public key of server's certificate.
SSL_SERVER_CERT PEM-encoded server certificate.

For $SSL_CLIENT_x_DN_x509 and $SSL_SERVER_x_DN_x509, x509 denotes a
component of the DN: C, ST, L, O, OU, CN, T, I, G, S, D, UID, Email.


[1] https://cr.yp.to/ucspi-tcp/
[2] https://www.fehcom.de/ipnet/ucspi-ssl.html




From petite.abeille at gmail.com  Thu Jun 11 20:02:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 21:02:39 +0200
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
Message-ID: <41D351B4-050E-4BBA-8579-647CFCF748C8@gmail.com>



> On Jun 10, 2020, at 05:53, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> TLS_CLIENT_AUTHORISED
> 
> Even though jetforce accepts unverified client certificates now, it will still
> check if the certificate is authorised anyway. This means both valid and trusted
> by the server's CA store. So this will be set to "1" for trusted and "0" for
> untrusted. I like this variable because it gives each CGI script the option to
> implement authentication however they want.

Is that the equivalent of SSL_CLIENT_VERIFY?

E.g.:

NONE: client has no cert 
SUCCESS = cert is valid 
GENEROUS = says only that some kind of certificate was sent at all 
FAILED:reason = auth with the cert failed 


From lazar.michael22 at gmail.com  Thu Jun 11 20:02:52 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 11 Jun 2020 15:02:52 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611175829.GD29628@SDF.ORG>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200611175829.GD29628@SDF.ORG>
Message-ID: <CAFTy05ZtPsrXQ0P7Uk=-6hhgfPWyK+84xyLkdet8Lthbhcq9kg@mail.gmail.com>

On Thu, Jun 11, 2020 at 1:58 PM solderpunk <solderpunk at sdf.org> wrote:
>
> On Tue, Jun 09, 2020 at 09:02:24PM -0400, Michael Lazar wrote:
>
> > I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME
> > should be the part of the URI path that comes before the PATH_INFO [1]. So in
> > your example:
> >
> > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
> > SCRIPT_NAME=/cgi-bin/beta
> > PATH_INFO=/foobar
>
> Is this how cgi-bins are traditionally handled?  If a URI paths's prefix
> matches the configured cgi-bin path, the standard mapping from URI paths
> to the filesystem is interrupted, and the first component of the URI path
> *after* the cgi-bin prefix (here `beta`) is the only think looked for on
> the disk, with everything else passed along to PATH_INFO?  If there is,
> for example, a /var/gemini/cgi-bin/beta/ directory on the disk, the
> server does not check for an executable named `foobar` in it?

Yes, but it's not limited to only the first component after cgi-bin/. The way
jetforce is implemented (thanks to a PR by arxcode [0]) is that it will walk
through the URI path on the filesystem until it reaches an executable file.
Then, anything left over is attached to the PATH_INFO. These two are both valid:

gemini://mozz.us/cgi-bin/debug.cgi/extra/path/info
-> /var/gemini/cgi-bin/debug.cgi

gemini://mozz.us/cgi-bin/directory/debug.cgi/extra/path/info
-> /var/gemini/cgi-bin/directory/debug.cgi

[0] https://github.com/michael-lazar/jetforce/issues/16

From lazar.michael22 at gmail.com  Thu Jun 11 20:33:37 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 11 Jun 2020 15:33:37 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611173703.GC29628@SDF.ORG>
References: <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
Message-ID: <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>

On Thu, Jun 11, 2020 at 1:37 PM solderpunk <solderpunk at sdf.org> wrote:
>
> On Wed, Jun 10, 2020 at 06:58:38PM -0400, Michael Lazar wrote:
>
> > Ok I'll walk that back. It's too late to make changes *unless* there's a good
> > reason to do so. I don't want to break CGI variables on a whim anymore, but if
> > we all agree on a standard then I will follow suit.
>
> You're not storing these hashes in some kind of database for
> Astrobotany?  Wouldn't changing how you calcultate the TLS_CLIENT_HASH
> variable break a lot of accounts?

I am storing them in the database as base64-encoded strings. But it would not
be hard to convert between the two text formats as long as the fingerprint
bytes are the same. What we're discussing here (to my knowledge) is two
different text representations of the same SHA256 digest of the public x509
certificate DER [0][1]. That's the standard way to do certificate
fingerprinting from what I can tell.

Even if we do pick a different hashing algorithm for the CGI variable,
astrobotany is implemented as a jetforce "application" where the python code is
invoked directly inside the server's interpreter. So it has full access to the
raw client certificate and can generate whichever hash it needs. I think this
is similar to what GLV-1.12556 does with allowing custom LUA "handlers".

[0] https://github.com/michael-lazar/jetforce/blob/ea7d8c6f4cbc3db14f62c01bf12c375abfe98e7e/jetforce/tls.py#L25
[1] https://github.com/pyca/cryptography/blob/f5735cf25acd08222368a1db615bbf61d36b8007/src/cryptography/hazmat/backends/openssl/x509.py#L47

From sean at conman.org  Thu Jun 11 20:45:58 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 11 Jun 2020 15:45:58 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611175829.GD29628@SDF.ORG>
References: <CAG-mZ3hcqFdHD_5LgrUBMCq09GZiJyQ0uHF5_JTpg5Uve058Fw@mail.gmail.com>
 <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200611175829.GD29628@SDF.ORG>
Message-ID: <20200611194558.GA11281@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Tue, Jun 09, 2020 at 09:02:24PM -0400, Michael Lazar wrote:
>  
> > I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME
> > should be the part of the URI path that comes before the PATH_INFO [1]. So in
> > your example:
> > 
> > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
> > SCRIPT_NAME=/cgi-bin/beta
> > PATH_INFO=/foobar
> 
> Is this how cgi-bins are traditionally handled?  

  Yes.

> If a URI paths's prefix
> matches the configured cgi-bin path, the standard mapping from URI paths
> to the filesystem is interrupted, and the first component of the URI path
> *after* the cgi-bin prefix (here `beta`) is the only think looked for on
> the disk, with everything else passed along to PATH_INFO?  If there is,
> for example, a /var/gemini/cgi-bin/beta/ directory on the disk, the
> server does not check for an executable named `foobar` in it?

  To answer that last question, no.

  To explain, let me explain my setup.  GLV-1.12556 allows one to use
multiple directories per virtual host for content.  I have the following
set up on my development box:

      {
        path      = "^(/cgi%-bin/)(.*)", -- [5]
        module    = "GLV-1.handlers.filesystem",
        directory = "/home/spc/projects/gemini/non-checkin/cgi-bin",
        -- ... there are some other directives, not important right now
      },

      {
        path      = ".*", -- [5]
        module    = "GLV-1.handlers.filesystem",
        directory = "/home/spc/projects/gemini/non-checkin/lucy.roswell.area51",
        -- ... more directives ...
      }

Note that depending upon how things are configured, CGI [1] can be in any
directory or restricted to a single directory [2].  With GLV-1.12556, any
file with the 'execute' bit will be treated as a CGI script [3][4].  I just
added a CGI to my main Gemini server:

	gemini://gemini.conman.org/test/a-script/foobar?one=1&two=2

the URL is broken up:

	location =
	{
	  host = "gemini.conman.org",
	  port = 1965.000000,
	  path = "/test/a-script/foobar",
	  scheme = "gemini",
	  query = "one=1&two=2",
	}

the path is matched against each handler's path (in order, first match wins)
and the matching one is handed the request.  Per the configuration, this
match result will be:

	match =
	{
	  "/",
	  "test/a-script/foobar",
	}

  The filesystem handler will breakdown the second match element (the first
is considered the "URL filesystem space"---remember, GLV-1.12556 supports
multiple directories per vhost) and check each segment (for permissions, CGI
script or SCGI script).  So the first check is for:

	<directory> .. "test"

  This is a directory, so it continues, walking down the path.   Next it
tries:

	<directory> .. "test/" .. "a-script"

  This is a file with the execute bit set, so it's run.  The rest of the
match is used to construct the PATH_INFO

	PATH_INFO="/foobar"

and PATH_TRANSLATED

	PATH_TRANSLATED=<directory> .. "/foobar"

This does not imply that such a directory exists.  If there is no more to
the path (say, the request was to "/test/a-script") then the PATH_INFO and
PATH_TRASLATED would not be set.

  A Gemini server doesn't have to do what I do.  It is certainly in line
with Apache to require CGI scripts to have a particular extension, look for
said extension and handle things that way without having to walk down the
filesystem checking each component.  So hypothetically speaking, a request
like:

	gemini://example.net/foo/bar.cgi

the server can scan for ".cgi", find it, know it's going to execute a CGI
script, but there is nothing more of the URL path, so not set PATH_INFO and
PATH_TRANSLATE.  But for this:

	gemini://example.net/foo/bar.cgi/baz

find the .cgi extension, extract the path up through the extension
("/foo/bar.cgi") and because there's more, set up PATH_INFO and
PATH_TRANSLATE.  There's another message on this list where I give a real
life example where I use PATH_INFO and PATH_TRANSLATED here:

	https://lists.orbitalfox.eu/archives/gemini/2020/001485.html

> Semi-related: when the server forks off the CGI process, is it
> conventional to set that process' working directory to the CGI bin?

  It would be conventional to set the working directory to the main
directory for the host.  In my case, given that a host can have multiple
directories, I set the working directory to the handler's directory setting. 
That value is also set in GEMINI_DOCUMENT_ROOT.

  -spc

[1]	And SCGI, I support this as well.

[2]	That's why I have 'cgi-bin'---to test that configuration.

[3]	I didn't bother with extensions for this.  I felt that checking for
	the 'execute' bit was more elegant than just an extension.  Also, if
	CGI has been disabled (server wide, host or directory---the
	configuration is very fine grained) then I return an error to the
	client.

[4]	There's another method for SCGI.

[5]	This is a Lua style regex.  The patterns in () are groupings and the
	filesystem handler wants two groups---the first is the leading
	portion in URL space that doesn't map to a file system, the second
	is the portion that does map to a filesystem.  The original syntax
	for this only required one match and I kept that---in that case, the
	match is redone slightly so that the leading '/' from the URL
	portion is the first match, then the rest.  So the '.*' pattern
	(which is basically "match all") becomes the pattern "^(/)(.*)". 
	This is an implementation detail of GLV-1.12556, but I thought I
	should mention it.

From solderpunk at SDF.ORG  Thu Jun 11 20:50:18 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 19:50:18 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
References: <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
 <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
Message-ID: <20200611195018.GB26289@SDF.ORG>

On Thu, Jun 11, 2020 at 03:33:37PM -0400, Michael Lazar wrote:

> I am storing them in the database as base64-encoded strings. But it would not
> be hard to convert between the two text formats as long as the fingerprint
> bytes are the same. What we're discussing here (to my knowledge) is two
> different text representations of the same SHA256 digest of the public x509
> certificate DER [0][1]. That's the standard way to do certificate
> fingerprinting from what I can tell.

Ah, right, if everybody is already using SHA256 then, yes, we can stick
to that and the different serialisations are convertible.  And I don't
see any reason not too.  From what I can tell there (somewhat
surprisingly) really isn't a standard notion of certificate
fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by
web browsers.

I will express a moderate preference for the "hexadecimal with colons
between bytes" notation.  It takes up more space than base64, but as a
pubnix admin I have people mailing me ssh public keys all the time.
Sometimes they attach them, and I'm happy, but other times they just
paste 'em right into the email and either their mail client splits the
key over several lines and I have to join them back together, or they
are sent as one long line and then mutt wraps them on my end and inserts
+s or =s or somesuch where it wraps, which blend right in with the
actual key content.  It's a fiddly thing.  The hexadecimal colon format
is way easier to work with via eyeball.

Cheers,
Solderpunk

From sean at conman.org  Thu Jun 11 20:50:29 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 11 Jun 2020 15:50:29 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
References: <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
Message-ID: <20200611195029.GB11281@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> 
> Even if we do pick a different hashing algorithm for the CGI variable,
> astrobotany is implemented as a jetforce "application" where the python code is
> invoked directly inside the server's interpreter. So it has full access to the
> raw client certificate and can generate whichever hash it needs. I think this
> is similar to what GLV-1.12556 does with allowing custom LUA "handlers".

  Yes, exactly.

  -spc


From sean at conman.org  Thu Jun 11 21:02:15 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 11 Jun 2020 16:02:15 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <143C2FA5-FB1F-4E6C-BA30-625E6E944BC2@gmail.com>
References: <59F93E7D-6285-40CE-8CDD-60308878AE60@gmail.com>
 <CAG-mZ3jVBKHHedmcQ8j-J-RX0jh-miHaU=pNZS7b4p5yPdwotQ@mail.gmail.com>
 <20200602183146.GD16068@SDF.ORG>
 <CAG-mZ3g6hF1jQ9aG_7=uh6V9roOq1yskB5=ARUf49E4t8S8-sQ@mail.gmail.com>
 <CAG-mZ3iXBiQO2k8Wssi=OBkjxBwnbtpHk2rGea0eu_TT+Gg8Aw@mail.gmail.com>
 <20200608074737.GE9769@SDF.ORG> <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200611175829.GD29628@SDF.ORG>
 <143C2FA5-FB1F-4E6C-BA30-625E6E944BC2@gmail.com>
Message-ID: <20200611200215.GC11281@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> Is there be any interest in D. J. Bernstein's ucspi-tcp [1] in this time
> and age? As a nimbler alternative to CGI perhaps?

  I looked at it (the link you gave for [1] is incorrect by the way), and it
seems more of a way to write a server than for a server to execute CGI
programs.

  I suppose you could have a CGI implementation that uses the ucspi-tcp
variables to pass information, but ... meh.

> [1] https://cr.yp.to/ucspi-tcp/

  Should be:

	https://cr.yp.to/ucspi-tcp.html

  -spc


From lazar.michael22 at gmail.com  Thu Jun 11 21:18:37 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 11 Jun 2020 16:18:37 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611195018.GB26289@SDF.ORG>
References: <20200609231403.GZ23998@brevard.conman.org>
 <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG>
Message-ID: <CAFTy05Z5fgsa0y6pG12eksvScvtfK7ZXK7dTCCfJDO6iAFbf+w@mail.gmail.com>

On Thu, Jun 11, 2020 at 3:50 PM solderpunk <solderpunk at sdf.org> wrote:
>
> I will express a moderate preference for the "hexadecimal with colons
> between bytes" notation.  It takes up more space than base64, but as a
> pubnix admin I have people mailing me ssh public keys all the time.
> Sometimes they attach them, and I'm happy, but other times they just
> paste 'em right into the email and either their mail client splits the
> key over several lines and I have to join them back together, or they
> are sent as one long line and then mutt wraps them on my end and inserts
> +s or =s or somesuch where it wraps, which blend right in with the
> actual key content.  It's a fiddly thing.  The hexadecimal colon format
> is way easier to work with via eyeball.

I have a slight preference towards not sticking the colons between bytes:

- It's easier to generate from bytes without needing to insert the colons
- It's easier to convert back to bytes without needing to remove the colons
- It would have a marginally smaller footprint
- It would look more like a UUID when displayed or inserted into a URL path

From solderpunk at SDF.ORG  Thu Jun 11 21:34:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 11 Jun 2020 20:34:55 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CAFTy05Z5fgsa0y6pG12eksvScvtfK7ZXK7dTCCfJDO6iAFbf+w@mail.gmail.com>
References: <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
 <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG>
 <CAFTy05Z5fgsa0y6pG12eksvScvtfK7ZXK7dTCCfJDO6iAFbf+w@mail.gmail.com>
Message-ID: <20200611203455.GC26289@SDF.ORG>

On Thu, Jun 11, 2020 at 04:18:37PM -0400, Michael Lazar wrote:
 
> I have a slight preference towards not sticking the colons between bytes:
> 
> - It's easier to generate from bytes without needing to insert the colons
> - It's easier to convert back to bytes without needing to remove the colons
> - It would have a marginally smaller footprint
> - It would look more like a UUID when displayed or inserted into a URL path

Actually, the marginally smaller footprint is a really good point which
largely invalidates my arguments about making them easy to stick in
emails.  Without colons, a 256 bit hash formatted as hex is 64
characters long, which will fit in a single line.  With colons, they'd
be 96 characters which typically won't.  So, let's not do them.

Upper or lower case?

Cheers,
Solderpunk?

From sean at conman.org  Thu Jun 11 21:45:41 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 11 Jun 2020 16:45:41 -0400
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611203455.GC26289@SDF.ORG>
References: <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG>
 <CAFTy05Z5fgsa0y6pG12eksvScvtfK7ZXK7dTCCfJDO6iAFbf+w@mail.gmail.com>
 <20200611203455.GC26289@SDF.ORG>
Message-ID: <20200611204541.GD11281@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Thu, Jun 11, 2020 at 04:18:37PM -0400, Michael Lazar wrote:
>  
> > I have a slight preference towards not sticking the colons between bytes:
> > 
> > - It's easier to generate from bytes without needing to insert the colons
> > - It's easier to convert back to bytes without needing to remove the colons
> > - It would have a marginally smaller footprint
> > - It would look more like a UUID when displayed or inserted into a URL path
> 
> Actually, the marginally smaller footprint is a really good point which
> largely invalidates my arguments about making them easy to stick in
> emails.  Without colons, a 256 bit hash formatted as hex is 64
> characters long, which will fit in a single line.  With colons, they'd
> be 96 characters which typically won't.  So, let's not do them.
> 
> Upper or lower case?

  Yes.

  -spc (Or mu.  I'll accept both)


From petite.abeille at gmail.com  Thu Jun 11 22:30:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 11 Jun 2020 23:30:28 +0200
Subject: The Problems of Transclusion (was Re: More silly text/gemini spec
 proposals)
In-Reply-To: <20200530024137.GI23998@brevard.conman.org>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200530024137.GI23998@brevard.conman.org>
Message-ID: <EFBF0D9F-C530-4F4B-B023-33FB37DF2AAB@gmail.com>



> On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote:
> 
>                        NO INLINING OF LINKS ALLOWED!

Meanwhile, back on the interweb:

http://subpixel.space/entries/open-transclude/

Also:
https://subpixel.space/entries/introducing-quotebacks/


From sean at conman.org  Thu Jun 11 22:55:54 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 11 Jun 2020 17:55:54 -0400
Subject: The Problems of Transclusion (was Re: More silly text/gemini spec
 proposals)
In-Reply-To: <EFBF0D9F-C530-4F4B-B023-33FB37DF2AAB@gmail.com>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200530024137.GI23998@brevard.conman.org>
 <EFBF0D9F-C530-4F4B-B023-33FB37DF2AAB@gmail.com>
Message-ID: <20200611215554.GE11281@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> > On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote:
> > 
> >                        NO INLINING OF LINKS ALLOWED!
> 
> Meanwhile, back on the interweb:
> 
> http://subpixel.space/entries/open-transclude/

  Yes, but note that it only works within a certain context and is not a
general solution to transclusion.  Also, the transclusion is done by the
client.  A Gemini server *could* implement transclusion behind the scenes.

> Also:
> https://subpixel.space/entries/introducing-quotebacks/

  I do this now.  If you check this post of mine:

	http://boston.conman.org/2020/03/23.2

you should see a blockquote that links back to the original article.  And if
you check the source, you'll see I used the CITE attribute in the BLOCKQUOTE
tag to *also* link to the source.

  Furthermore, when I use Firefox on Linux, I can highlight the portion of a
page I want to quote, and using a special program, grab not only the HTML
from the clipboard [1] but the URL, use that to grab the page again for the
title, and automatically generate the BLOCKQUOTE for me.

  -spc (Amazing what's hidden under the hood, so to speak)

[1]	The X Windows selection mechanism is quote sophisticated and
	supports multiple MIME types (no, really!).  I have some text
	highlighted in Firefox (under Linux) right now, and I can grab
	(among other values):

		text/html			With the HTML
		UTF8_STRING			sans HTML
		text/x-moz-url			URL of the page

	You can read more about it here:

		https://www.jwz.org/doc/x-cut-and-paste.html

From petite.abeille at gmail.com  Thu Jun 11 23:57:46 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 12 Jun 2020 00:57:46 +0200
Subject: The Problems of Transclusion (was Re: More silly text/gemini spec
 proposals)
In-Reply-To: <20200611215554.GE11281@brevard.conman.org>
References: <3c2683fe-243d-4f22-a4f1-6e79f5031fc9.ref@email.android.com>
 <3c2683fe-243d-4f22-a4f1-6e79f5031fc9@email.android.com>
 <20200530024137.GI23998@brevard.conman.org>
 <EFBF0D9F-C530-4F4B-B023-33FB37DF2AAB@gmail.com>
 <20200611215554.GE11281@brevard.conman.org>
Message-ID: <A2DEA574-7CEB-4D60-AE18-045079400402@gmail.com>



> On Jun 11, 2020, at 23:55, Sean Conner <sean at conman.org> wrote:
> 
>  I do this now.  If you check this post of mine:
> 
> 	http://boston.conman.org/2020/03/23.2
> 
> you should see a blockquote that links back to the original article.  And if
> you check the source, you'll see I used the CITE attribute in the BLOCKQUOTE
> tag to *also* link to the source.

Nifty :)

( got to say, I like the little hover effect in Quotebacks, which lift the blockquote oh-just-so-slightly from the surrounding text. nice visual emphasize )

> [1]	The X Windows selection mechanism is quote sophisticated and
> 	supports multiple MIME types (no, really!).  I have some text
> 	highlighted in Firefox (under Linux) right now, and I can grab
> 	(among other values):
> 
> 		text/html			With the HTML
> 		UTF8_STRING			sans HTML
> 		text/x-moz-url			URL of the page
> 
> 	You can read more about it here:
> 
> 		https://www.jwz.org/doc/x-cut-and-paste.html

Yes, ditto on the mac, curtesy of NSPasteboard:

https://developer.apple.com/documentation/appkit/nspasteboard

And yes, all those NS prefixes refers to NEXTSTEP to this day :D


From tkarpiniec at icloud.com  Fri Jun 12 00:39:51 2020
From: tkarpiniec at icloud.com (Thomas Karpiniec)
Date: Fri, 12 Jun 2020 09:39:51 +1000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611195018.GB26289@SDF.ORG>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
 <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG>
Message-ID: <20200611233951.GA41155@MacBook-Pro.local>

On Thu, Jun 11, 2020 at 07:50:18PM +0000, solderpunk wrote:
> Ah, right, if everybody is already using SHA256 then, yes, we can stick
> to that and the different serialisations are convertible.  And I don't
> see any reason not too.  From what I can tell there (somewhat
> surprisingly) really isn't a standard notion of certificate
> fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by
> web browsers.

At the risk of overthinking things, I was reading RFC6709 "Design
Considerations for Protocol Extensions" for non-Gemini reasons
recently and this section seems relevant:

"4.5.  Cryptographic Agility

... The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular
cryptographic algorithm....  This is usually accomplished by including
an algorithm identifier and parameters in the protocol, and by
specifying the algorithm requirements in the protocol specification."

i.e. Instead of storing opaque bytes, also mention that it's SHA256

A stand-alone implementation of this concept:
https://multiformats.io/multihash/

Cheers, Tom

From martin at no.ucant.org  Fri Jun 12 06:10:58 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Fri, 12 Jun 2020 06:10:58 +0100 (BST)
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611233951.GA41155@MacBook-Pro.local>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG>
 <20200611233951.GA41155@MacBook-Pro.local>
Message-ID: <alpine.DEB.2.20.2006120608570.18317@pling.qwghlm.org>

On Fri, 12 Jun 2020, Thomas Karpiniec wrote:

> i.e. Instead of storing opaque bytes, also mention that it's SHA256
>
> A stand-alone implementation of this concept:
> https://multiformats.io/multihash/

Ah, I like this.

I'd also commend the Scuttlebutt approach to this (Scuttlebutt is a 
"curate's egg" of good and bad examples), which is to include the type of 
key in the canonical representation:

{
   "author": "@FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=.ed25519",
   "content": {
     "type": "pub",
     "address": {
       "host": "one.butt.nz",
       "port": 8008,
       "key": "@VJM7w1W19ZsKmG2KnfaoKIM66BRoreEkzaVm/J//wl8=.ed25519"
     }
   },
   ...
}

The ".ed25519" making it clear what we're dealing with. Instinctively I 
like the multihash thing more, but the Scuttlebutt form has the merit of 
much better legibility/obviousness.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From defdefred at protonmail.com  Fri Jun 12 09:13:28 2020
From: defdefred at protonmail.com (defdefred)
Date: Fri, 12 Jun 2020 08:13:28 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <20200611233951.GA41155@MacBook-Pro.local>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
Message-ID: <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>

Maybe adding version for whole gemini protocol ?


??????? Original Message ???????
On Friday 12 June 2020 01:39, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:

> On Thu, Jun 11, 2020 at 07:50:18PM +0000, solderpunk wrote:
>
> > Ah, right, if everybody is already using SHA256 then, yes, we can stick
> > to that and the different serialisations are convertible. And I don't
> > see any reason not too. From what I can tell there (somewhat
> > surprisingly) really isn't a standard notion of certificate
> > fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by
> > web browsers.
>
> At the risk of overthinking things, I was reading RFC6709 "Design
> Considerations for Protocol Extensions" for non-Gemini reasons
> recently and this section seems relevant:
>
> "4.5. Cryptographic Agility
>
> ... The ability to negotiate the use of a particular cryptographic
> algorithm provides resilience against compromise of a particular
> cryptographic algorithm.... This is usually accomplished by including
> an algorithm identifier and parameters in the protocol, and by
> specifying the algorithm requirements in the protocol specification."
>
> i.e. Instead of storing opaque bytes, also mention that it's SHA256
>
> A stand-alone implementation of this concept:
> https://multiformats.io/multihash/
>
> Cheers, Tom



From solderpunk at SDF.ORG  Fri Jun 12 10:41:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 12 Jun 2020 09:41:12 +0000
Subject: CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)
In-Reply-To: <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG>
 <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG>
 <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
Message-ID: <20200612094112.GA6497@SDF.ORG>

On Fri, Jun 12, 2020 at 08:13:28AM +0000, defdefred wrote:
> Maybe adding version for whole gemini protocol ?

I am fairly staunchly against this, and always have been.  I'm not sure
how popular a stance it is.  In my mind, having protocol versions which
are signalled in-band is just an invitation to endlessly upgrade over
time, and completely defeats the point of all the efforts to limit
extensibility.

I strongly believe that the computing world in general could really
benefit from a healthy dose of the attitude that "things should be
allowed to be finished".

I am hopeful that Gemini is simple enough that we can "get it right", or
right enough, the first time and then just enjoy building stuff within
whatever limitations it imposes forever after.  Gopher is more than 25
years old and people are still using it with very few changes to the
official spec.  I don't see why we can't hope for similar longevity.
Some of Gopher's biggest problems stem just from the fact that it was
born very early - before URIs were invented and before
internationalisation was taken seriously.  Had Gopher been born just a
little later (or had those early major disruptions happened just a
little sooner), it might be being used *exactly* as specced today (well,
the `i` item type would probably still have evolved).

Gopher's item types have not aged well, but we are using MIME types
instead, which are extensible and therefore likely to be usable for the
forseeable future.

Exciting new internet protocols might gain major traction in the future,
but it's a very safe bet they will come with URI schemes, so Gemini will
be able to link to them, no problem.

If there are major happenings in the cryptographic landscape, it is
reasonable to expect new versions of TLS to address that for the
forseeable future, and Gemini will come along for the ride.

At the end of the day, the basic problems we are trying to solve are not
difficult and have not changed for a long time.  Good solutions to these
problems should have long lifespans.  Constant upgrades are a sign of
bad solutions, or excessive ambition / scope creep: HTTP/2 has only come
along because people are convinced that viewing a document online needs
to involve downloading 1,000 inter-connected components from 100 hosts.
Gemini rejects that as obvious nonsense, so it's fine to design with no
intention of that every working well.

Cheers,
Solderpunk


> 
> ??????? Original Message ???????
> On Friday 12 June 2020 01:39, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:
> 
> > On Thu, Jun 11, 2020 at 07:50:18PM +0000, solderpunk wrote:
> >
> > > Ah, right, if everybody is already using SHA256 then, yes, we can stick
> > > to that and the different serialisations are convertible. And I don't
> > > see any reason not too. From what I can tell there (somewhat
> > > surprisingly) really isn't a standard notion of certificate
> > > fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by
> > > web browsers.
> >
> > At the risk of overthinking things, I was reading RFC6709 "Design
> > Considerations for Protocol Extensions" for non-Gemini reasons
> > recently and this section seems relevant:
> >
> > "4.5. Cryptographic Agility
> >
> > ... The ability to negotiate the use of a particular cryptographic
> > algorithm provides resilience against compromise of a particular
> > cryptographic algorithm.... This is usually accomplished by including
> > an algorithm identifier and parameters in the protocol, and by
> > specifying the algorithm requirements in the protocol specification."
> >
> > i.e. Instead of storing opaque bytes, also mention that it's SHA256
> >
> > A stand-alone implementation of this concept:
> > https://multiformats.io/multihash/
> >
> > Cheers, Tom
> 
> 
> 

From tomasino at lavabit.com  Fri Jun 12 12:14:12 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 12 Jun 2020 11:14:12 +0000
Subject: What is Gemini - a video by me
In-Reply-To: <20200612094112.GA6497@SDF.ORG>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
 <20200612094112.GA6497@SDF.ORG>
Message-ID: <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>

Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here:

https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e

https://www.youtube.com/watch?v=DoEI6VzybDk

Please leave comments on anything I got wrong so others can benefit.

I've also pushed up my "notes" slide with these links to my gemlog on tilde.black here:

gemini://tilde.black/users/fox/journal/20200612-what-is-gemini.gmi


From natpen at natpen.net  Fri Jun 12 12:21:03 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Fri, 12 Jun 2020 07:21:03 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610200337.GG10136@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
Message-ID: <20200612112103.GC38108@goldfish.localdomain>

On Wed, Jun 10, 2020 at 08:03:37PM +0000, solderpunk wrote:
> I think it is definitely polite to explicitly indicate file sizes for
> anything larger than, I dunno, 10 MiB or thereabouts?
>
> Relatedly, as of a semi-recent update, the automatically generated
> directory listings produced by Molly Brown include file sizes.

Okay, I will jump on the update train!

GUS now provides, by default, size information for every result*.

It's also exposed as a new query filter, in case you want to explore
more on your own. I put an example query below to show usage, but you
can find more documentation on the about page [0].

"computer AND size:>2000"

gemini://gus.guru/search?computer%20AND%20size%3A%3E2000

[0] gemini://gus.guru/about

* except for content_type input results, because is generally less
  useful for them, and I already use that UI space in input results
  for giving the user a preview of what the actual prompt is.

From natpen at natpen.net  Fri Jun 12 12:57:53 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Fri, 12 Jun 2020 07:57:53 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200610194700.GB10136@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610103605.GA6867@goldfish.localdomain>
 <20200610194700.GB10136@SDF.ORG>
Message-ID: <20200612115753.GD38108@goldfish.localdomain>

On Wed, Jun 10, 2020 at 07:47:00PM +0000, solderpunk wrote:
> Gemini's lack of caching, lack of compression, and lack of resumable
> downloads all mean it's *never* going to be sensible choice for
> really big downloads, no matter how fast internet speeds get.

I agree with this! Gemini isn't suited for big downloads. But, (and I
realize this is very speculative) I think it's very plausible and even
likely that what is "big" will change, perhaps substantially, over
time. We've definitely seen that happen with average file sizes of
say, images, over the past few decades.

A decade ago I would have wanted resumability for a couple hundred MB
download. Now I don't even give it a second thought!

From solderpunk at SDF.ORG  Fri Jun 12 13:32:51 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 12 Jun 2020 12:32:51 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612112103.GC38108@goldfish.localdomain>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
Message-ID: <20200612123251.GA27852@SDF.ORG>

On Fri, Jun 12, 2020 at 07:21:03AM -0400, Natalie Pendragon wrote:
> Okay, I will jump on the update train!
> 
> GUS now provides, by default, size information for every result*.
> 
> It's also exposed as a new query filter, in case you want to explore
> more on your own. I put an example query below to show usage, but you
> can find more documentation on the about page [0].

These are fantastic updates, well done!

Out of curiosity, can you use your GUSly powers to easily tell us, say,
the mean and median size of resources served via Gemini?

How do you feel about the (wonderful!) GUS statistics page being updated
to give information on the size distribution?  Perhaps you could bin
resources into size ranges, say semi-open intervals, [0, 1Kib), [1Kib,
10Kib), [10Kib, 100Kib), etc, etc?

Since I am being greedy and asking you to do things, let me close by
singing the praises of GUS!

Back when new Gemini content was popping up at an insane rate, I would
spend a lot of time exploring and reading.  Weeks later I wonder things
like "where did I read that great retrospective write-up on the career
of a recently deceased motorsport legend?  I wonder if the author has
written anything more?", have absolutely *no* recollection of who wrote
it, or where it was hosted, or much else (I'm not a motorsport fan at
all so did not remember the names of any people, cars, courses, etc.
involved - but the thing was so well written and full of evident passion
that I enjoyed reading it as a complete outsider).  So I'd GUS for some
random small detail I could recall like "oil pressure" and, boom, there
it is.

Anybody who follows my phlog knows that one every few months I'll refer
to something I read in gopherspace but that I have forgotten the source
of and could not find later by checking likely places, so I have to
leave a note saying "if this was you, or you remember who it was, please
let me know!".  I'm thrilled that Geminispace may never have this
problem.

Seriously, Gemini search is already, somehow, a hundred, nay a thousand
times better than Gopher search has ever been, despite the great
disparity in time and attention between the two.  I would love to
understand why, and if there is some difference in the protocols that
explains it.  I have always suspected that Gopher's complete absence of
machine-readable signalling of whether a request succeeded or failed
must be a huge impediment to building a reliable indexer, but I have no
idea if that's actually the reason for the dramatic difference.

Anybody have any insight?

Cheers,
Solderpunk

From petite.abeille at gmail.com  Fri Jun 12 13:50:35 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 12 Jun 2020 14:50:35 +0200
Subject: [OT] An ASCII art music video
Message-ID: <5A49E7E8-3033-4864-83FB-290732158D39@gmail.com>

For the ASCII art lover out there:

https://clad.band

https://github.com/bejd/clad-ascii

From natpen at natpen.net  Fri Jun 12 13:59:45 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Fri, 12 Jun 2020 08:59:45 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612123251.GA27852@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
 <20200612123251.GA27852@SDF.ORG>
Message-ID: <20200612125945.GF38108@goldfish.localdomain>

Aww, thanks!! That makes me really happy to hear.

On Fri, Jun 12, 2020 at 12:32:51PM +0000, solderpunk wrote:
> Out of curiosity, can you use your GUSly powers to easily tell us, say,
> the mean and median size of resources served via Gemini?

Sure, just give me a little bit to do some index hackery and I'll
share results back.

> How do you feel about the (wonderful!) GUS statistics page being updated
> to give information on the size distribution?  Perhaps you could bin
> resources into size ranges, say semi-open intervals, [0, 1Kib), [1Kib,
> 10Kib), [10Kib, 100Kib), etc, etc?

Yes! I was thinking about that too, but hadn't convinced myself of the
best way to present the data. I was also thinking of binning the data
to make histograms, or maybe just avg/median/max to start with.

I think it needs segmented by content_type to be useful though. Or at
least by the first/major component of content_type (i.e., all images
are bundled together for measurement).

From plugd at thelambdalab.xyz  Fri Jun 12 14:10:59 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Fri, 12 Jun 2020 15:10:59 +0200
Subject: What is Gemini - a video by me
In-Reply-To: <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
 <20200612094112.GA6497@SDF.ORG>
 <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
Message-ID: <lzo8po77ks.fsf@bs-mbpr348.d.ethz.ch>

James Tomasino writes:
> Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here:

Cool!  I'm digging your background rug. :-)

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200612/4ded1cf6/attachment-0001.sig>

From natpen at natpen.net  Fri Jun 12 14:25:55 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Fri, 12 Jun 2020 09:25:55 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612125945.GF38108@goldfish.localdomain>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
 <20200612123251.GA27852@SDF.ORG>
 <20200612125945.GF38108@goldfish.localdomain>
Message-ID: <20200612132555.GG38108@goldfish.localdomain>

On Fri, Jun 12, 2020 at 08:59:45AM -0400, Natalie Pendragon wrote:
> On Fri, Jun 12, 2020 at 12:32:51PM +0000, solderpunk wrote:
> > Out of curiosity, can you use your GUSly powers to easily tell us, say,
> > the mean and median size of resources served via Gemini?
>
> Sure, just give me a little bit to do some index hackery and I'll
> share results back.

Okay, here are some statistics for the most prevalent content types.
Please do share any feedback you have, and I'll likely add this or
something similar to the statistics page soon so it's continually
available and up-to-date.

The number in parentheses after content_type is the number pages
in Geminispace with that content_type, and I hope everything else is
self-explanatory!

# text/gemini (10378)
Mean   :    2.1 K
Median :    1.2 K
Max    :  753.3 K

# text/plain (1390)
Mean   :    4.2 K
Median :    1.4 K
Max    :  333.8 K

# image/png (281)
Mean   :  462.2 K
Median :  170.6 K
Max    :    3.4 M

# image/jpeg (159)
Mean   :  998.7 K
Median :  507.9 K
Max    :    4.2 M

# image/gif (18)
Mean   :   35.7 K
Median :    5.9 K
Max    :  356.4 K

# audio/mpeg (367)
Mean   :    3.4 M
Median :    3.3 M
Max    :   16.7 M

# application/octet-stream (40)
Mean   :  497.4 K
Median :   94.1 K
Max    :   10.7 M

# application/pdf (165)
Mean   :    4.2 M
Median :  223.9 K
Max    :  126.9 M

# audio/midi (72)
Mean   :    5.2 K
Median :    4.7 K
Max    :   20.7 K

# audio/flac (48)
Mean   :   21.1 M
Median :   15.4 M
Max    :  118.6 M

# text/x-lilypond (122)
Mean   :    4.7 K
Median :    4.6 K
Max    :    7.6 K

From pwarren at pwarren.id.au  Fri Jun 12 14:28:12 2020
From: pwarren at pwarren.id.au (Paul Warren)
Date: Fri, 12 Jun 2020 23:28:12 +1000
Subject: [ANN] Yet another gemlog! gemini://gem.pwarren.id.au/
Message-ID: <e418e03c-3469-2cdd-3a73-80b8e8033a61@pwarren.id.au>

G'day folks,

I've had a bit of fun the last few weeks doing some recreational
sysadmin and have set up my gemspace at:

gemini://gem.pwarren.id.au/

Has been lots of fun so far :)

I'm not sure what it'll turn into, but I'll try and keep some blog style
posts going to add to the gemini content.

Cheers!
--
Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1003 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200612/270c6b10/attachment.sig>

From hello at matthewgraybosch.com  Fri Jun 12 15:31:44 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 12 Jun 2020 10:31:44 -0400
Subject: [ANN] tanelorn.city: a public gemini host for writers
Message-ID: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>

I'm pleased to announce that tanelorn.city is now open. I'm catering
mainly to writers, but TBH I'll probably give an account to anybody who
wants one as long as they aren't a fascist, a white supremacist, or a
TERF.

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

From colecmac at protonmail.com  Fri Jun 12 16:08:36 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 12 Jun 2020 15:08:36 +0000
Subject: [ANN] tanelorn.city: a public gemini host for writers
In-Reply-To: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
References: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
Message-ID: <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>

Amen. Happy to have another server!

However, in Bombadillo I get the error "Cert hostname does not match".
Make sure you're serving up the right certificate!


makeworld

??????? Original Message ???????
On Friday, June 12, 2020 10:31 AM, Matthew Graybosch <hello at matthewgraybosch.com> wrote:

> I'm pleased to announce that tanelorn.city is now open. I'm catering
> mainly to writers, but TBH I'll probably give an account to anybody who
> wants one as long as they aren't a fascist, a white supremacist, or a
> TERF.
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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."



From hello at matthewgraybosch.com  Fri Jun 12 16:36:45 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 12 Jun 2020 11:36:45 -0400
Subject: [ANN] tanelorn.city: a public gemini host for writers
In-Reply-To: <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>
References: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
 <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>
Message-ID: <20200612113645.d5bac3b4523447a4e779dea5@matthewgraybosch.com>

On Fri, 12 Jun 2020 15:08:36 +0000
colecmac at protonmail.com wrote:

> Amen. Happy to have another server!

Thanks.

> However, in Bombadillo I get the error "Cert hostname does not match".
> Make sure you're serving up the right certificate!

Sorry to hear that!

I just downloaded Bombadillo so I could see for myself, and checked my
Gemserv config on kanajana. As far as I can tell my config is OK and
I'm using the correct cert for each hostname, but the problem might be
that kanajana isn't only serving tanelorn.city but demifiend.org and
starbreaker.org as well.

I'm not sure what to do about it, though since all three sites are
accessible using Castor and bollux.

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

From solderpunk at SDF.ORG  Fri Jun 12 17:35:11 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 12 Jun 2020 16:35:11 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612132555.GG38108@goldfish.localdomain>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
 <20200612123251.GA27852@SDF.ORG>
 <20200612125945.GF38108@goldfish.localdomain>
 <20200612132555.GG38108@goldfish.localdomain>
Message-ID: <20200612163511.GB27304@SDF.ORG>

On Fri, Jun 12, 2020 at 09:25:55AM -0400, Natalie Pendragon wrote:
> 
> Okay, here are some statistics for the most prevalent content types.
> Please do share any feedback you have, and I'll likely add this or
> something similar to the statistics page soon so it's continually
> available and up-to-date.
> 
> The number in parentheses after content_type is the number pages
> in Geminispace with that content_type, and I hope everything else is
> self-explanatory!
> 
> # text/gemini (10378)
> Mean   :    2.1 K
> Median :    1.2 K
> Max    :  753.3 K
> 
> # text/plain (1390)
> Mean   :    4.2 K
> Median :    1.4 K
> Max    :  333.8 K

Thanks for sharing these!  This is actually really useful information to
have, for thinking about the role of TLS overhead in Gemini.  It
actually seems like most text/gemini content is in fact about as big as
the server's TLS certificate or smaller, which kind of blows the idea of
Gemini being a good match for constrained networks out of the water -
even if we did have those 2x status codes, you'd still need to download
the server's cert, plus the (comparatively small) handshake traffic,
before you could make the decision to terminate early.

This overhead also scuttles lots of simple ideas to work around Gemini's
lack of a HEAD request equivalent.  Defining a well-known endpoint where
clients can fetch, e.g. a small file with the timestamps of the N most
recently updated files the server hosts makes no sense whatsoever if the
TLS overhead of fetching *that* list is, in fact, just as big as the
possibly out-of-date file the client actually wants in the first place.

It doesn't need to make it into the spec, but over time we should
develop and publicise best practices for minimising this overhead.  This
may include choosing signature schemes which are secure with smaller
key sizes, like ed25519.  Self-signed certificates also have a strong
advantage here by virtue of not needing to include a long chain of certs
leading to a trusted root.

These measures will bump heads with Petite Abeille's point about TLS
fingerprinting and how it's good, from an anti-censorship point of view,
to blend in with the crowd by not using "unusual" certificates.

Cheers,
Solderpunk

From tastytea+gemini at tastytea.de  Fri Jun 12 17:39:22 2020
From: tastytea+gemini at tastytea.de (tastytea)
Date: Fri, 12 Jun 2020 18:39:22 +0200
Subject: [ANN] tanelorn.city: a public gemini host for writers
In-Reply-To: <20200612113645.d5bac3b4523447a4e779dea5@matthewgraybosch.com>
References: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
 <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>
 <20200612113645.d5bac3b4523447a4e779dea5@matthewgraybosch.com>
Message-ID: <20200612183916.15f5f495@ventiloplattform.tastytea.de>

On 2020-06-12 11:36-0400 Matthew Graybosch <hello at matthewgraybosch.com>
wrote:

> On Fri, 12 Jun 2020 15:08:36 +0000
> colecmac at protonmail.com wrote:
> 
> > Amen. Happy to have another server!  
> 
> Thanks.
> 
> > However, in Bombadillo I get the error "Cert hostname does not
> > match". Make sure you're serving up the right certificate!  
> 
> Sorry to hear that!
> 
> I just downloaded Bombadillo so I could see for myself, and checked my
> Gemserv config on kanajana. As far as I can tell my config is OK and
> I'm using the correct cert for each hostname, but the problem might be
> that kanajana isn't only serving tanelorn.city but demifiend.org and
> starbreaker.org as well.
> 
> I'm not sure what to do about it, though since all three sites are
> accessible using Castor and bollux.
> 

If I interpret the output from `openssl s_client`? correctly, the CN of
the certificate is set to ?Matthew Graybosch?, not a ?tanelorn.city?,
as it is custom for HTTPS. However, while the specification states in
4.2 that ?Clients can validate TLS connections however they like?, it
recommends a ?lightweight "TOFU" certificate-pinning system? without
mentioning hostname validation.

Kristall and elpher also show no error, by the way.

Kind regards, tastytea

? echo -e 'gemini://tanelorn.city\r\n\r\n' \
  | openssl s_client -verify_hostname tanelorn.city tanelorn.city:1965

-- 
Get my PGP key with `gpg --locate-keys tastytea at tastytea.de` or at
<https://tastytea.de/tastytea.asc>.

From solderpunk at SDF.ORG  Fri Jun 12 17:43:25 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 12 Jun 2020 16:43:25 +0000
Subject: [ANN] tanelorn.city: a public gemini host for writers
In-Reply-To: <20200612183916.15f5f495@ventiloplattform.tastytea.de>
References: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
 <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>
 <20200612113645.d5bac3b4523447a4e779dea5@matthewgraybosch.com>
 <20200612183916.15f5f495@ventiloplattform.tastytea.de>
Message-ID: <20200612164325.GD27304@SDF.ORG>

On Fri, Jun 12, 2020 at 06:39:22PM +0200, tastytea wrote:
 
> If I interpret the output from `openssl s_client`? correctly, the CN of
> the certificate is set to ?Matthew Graybosch?, not a ?tanelorn.city?,
> as it is custom for HTTPS. However, while the specification states in
> 4.2 that ?Clients can validate TLS connections however they like?, it
> recommends a ?lightweight "TOFU" certificate-pinning system? without
> mentioning hostname validation.

I guess various best practices for non-conventional certificate
validation should be hashed out in, well, the best practices doc, or
even a dedicated document.

For what it's worth, AV-98 expects either the Subject CN or one of the
SubjectAlternativeNames to match the hostname in the URL it's trying to
fetch and will complain otherwise.  I can visit tanelorn.city just fine,
so I guess there's a valid SAN that perhaps Bombadillo isn't seeing?

Cheers,
Solderpunk

From hello at matthewgraybosch.com  Fri Jun 12 18:41:52 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 12 Jun 2020 13:41:52 -0400
Subject: [ANN] tanelorn.city: a public gemini host for writers
In-Reply-To: <20200612164325.GD27304@SDF.ORG>
References: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
 <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>
 <20200612113645.d5bac3b4523447a4e779dea5@matthewgraybosch.com>
 <20200612183916.15f5f495@ventiloplattform.tastytea.de>
 <20200612164325.GD27304@SDF.ORG>
Message-ID: <20200612134152.6f35ae6de93195da91f725e4@matthewgraybosch.com>

On Fri, 12 Jun 2020 16:43:25 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> On Fri, Jun 12, 2020 at 06:39:22PM +0200, tastytea wrote:
>  
> > If I interpret the output from `openssl s_client`? correctly, the
> > CN of the certificate is set to ?Matthew Graybosch?, not a
> > ?tanelorn.city?, as it is custom for HTTPS. However, while the
> > specification states in 4.2 that ?Clients can validate TLS
> > connections however they like?, it recommends a ?lightweight "TOFU"
> > certificate-pinning system? without mentioning hostname validation.
> 
> I guess various best practices for non-conventional certificate
> validation should be hashed out in, well, the best practices doc, or
> even a dedicated document.
> 
> For what it's worth, AV-98 expects either the Subject CN or one of the
> SubjectAlternativeNames to match the hostname in the URL it's trying
> to fetch and will complain otherwise.  I can visit tanelorn.city just
> fine, so I guess there's a valid SAN that perhaps Bombadillo isn't
> seeing?

I might have gone about creating my certs the wrong way, too.

After RTFMing FreeBSD's openssl implementation I came up with the
following shell script.

```
#!/bin/sh

DOMAIN=${1}
SSL_CERT_PATH=/usr/local/etc/ssl/${DOMAIN}

if [ ! -d "${SSL_CERT_PATH}" ]; then
        mkdir -p $SSL_CERT_PATH
fi

openssl req -x509 -nodes -days 365 -newkey rsa:4096 \
	-keyout ${SSL_CERT_PATH}/ssl.key \
	-out ${SSL_CERT_PATH}/ssl.crt
openssl dhparam -out ${SSL_CERT_PATH}/dhparam.pem 4096
```

It looks like I'm getting prompted to create a CSR for each cert as
well, and I might be putting in the wrong information.

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

From hello at matthewgraybosch.com  Fri Jun 12 19:29:15 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 12 Jun 2020 14:29:15 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612163511.GB27304@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
 <20200612123251.GA27852@SDF.ORG>
 <20200612125945.GF38108@goldfish.localdomain>
 <20200612132555.GG38108@goldfish.localdomain>
 <20200612163511.GB27304@SDF.ORG>
Message-ID: <20200612142915.84ee06ec1273804c15c150e8@matthewgraybosch.com>

On Fri, 12 Jun 2020 16:35:11 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> These measures will bump heads with Petite Abeille's point about TLS
> fingerprinting and how it's good, from an anti-censorship point of
> view, to blend in with the crowd by not using "unusual" certificates.

Not to disparage Petite Abeille's point about TLS fingerprinting and
blending in to avoid notice, but aren't we sticking out anyway by
listening on port 1965?

This is a bit outside my expertise, but wouldn't an adversary
determined to find gemini servers just have to do a port scan?

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

From solderpunk at SDF.ORG  Fri Jun 12 20:11:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 12 Jun 2020 19:11:33 +0000
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612142915.84ee06ec1273804c15c150e8@matthewgraybosch.com>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
 <20200612123251.GA27852@SDF.ORG>
 <20200612125945.GF38108@goldfish.localdomain>
 <20200612132555.GG38108@goldfish.localdomain>
 <20200612163511.GB27304@SDF.ORG>
 <20200612142915.84ee06ec1273804c15c150e8@matthewgraybosch.com>
Message-ID: <20200612191133.GF27304@SDF.ORG>

On Fri, Jun 12, 2020 at 02:29:15PM -0400, Matthew Graybosch wrote:
 
> Not to disparage Petite Abeille's point about TLS fingerprinting and
> blending in to avoid notice, but aren't we sticking out anyway by
> listening on port 1965?

By default, yes, but if somebody wanted to host a server on port 443 in
an attempt to "blend in", they could.  How effectively they would blend
in would then be a function of how typical their certificate looked.

But maybe there's not such a conflict here.  Somebody wanting to run a
server in extreme stealth mode might just have to accept that this
involves sacrificing some efficiency and use fat certs.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Fri Jun 12 20:24:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 12 Jun 2020 21:24:11 +0200
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612191133.GF27304@SDF.ORG>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
 <20200612123251.GA27852@SDF.ORG>
 <20200612125945.GF38108@goldfish.localdomain>
 <20200612132555.GG38108@goldfish.localdomain>
 <20200612163511.GB27304@SDF.ORG>
 <20200612142915.84ee06ec1273804c15c150e8@matthewgraybosch.com>
 <20200612191133.GF27304@SDF.ORG>
Message-ID: <3DC97E8F-EE2D-4A76-8F1C-9936FA9B7CD2@gmail.com>



> On Jun 12, 2020, at 21:11, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> But maybe there's not such a conflict here.  Somebody wanting to run a
> server in extreme stealth mode might just have to accept that this
> involves sacrificing some efficiency and use fat certs.

My name is Fat Tony, and I approve this message.


From fgaz at fgaz.me  Fri Jun 12 21:07:53 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Fri, 12 Jun 2020 22:07:53 +0200
Subject: [ANN] gemini-textboard.fgaz.me: a simple textboard
Message-ID: <20200612220753.2c8ffd2b@phi>

I'm pleased to announce what I believe is the first forum mediated by
the Gemini protocol!

gemini://gemini-textboard.fgaz.me/

It's fairly basic for now: you can create new threads and replies, and
threads are ordered by last activity. For now all posts are kept
forever, but I plan to add automatic deletion of old threads, as is
tradition.

Feel free to use it to talk about whatever!

The server is written in Haskell, and this textboard is actually a
proof of concept for a series of libraries I'm about to release that
will make it easy to write dynamic Gemini sites. You could call it a
lightweight "Gemini framework"[1].

The board and libraries' source code is not public yet. I plan to
announce them in the coming weeks once I finish polishing some stuff.

[1]: Is this an heresy? :)

From luke at marmaladefoo.com  Fri Jun 12 21:33:09 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 12 Jun 2020 21:33:09 +0100
Subject: What is Gemini - a video by me
In-Reply-To: <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
 <20200612094112.GA6497@SDF.ORG>
 <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
Message-ID: <5EE3E685.9020700@marmaladefoo.com>

On 12-Jun-2020 12:14, James Tomasino wrote:
> Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here:
>
> https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e
>
> https://www.youtube.com/watch?v=DoEI6VzybDk
>
> Please leave comments on anything I got wrong so others can benefit.
>
> I've also pushed up my "notes" slide with these links to my gemlog on tilde.black here:
>
> gemini://tilde.black/users/fox/journal/20200612-what-is-gemini.gmi
>
Hey Tomasino

thanks for this - it is a nice overview and I enjoyed watching it. It is 
strange to hear someone actually talk about something I had only ever 
seen in written form, but sort of refreshing to know I didn't imagine 
all this...

And I now have a link to send to all my "normal" friends who wonder what 
I am going on about :p

Best wishes

  - Luke

From colecmac at protonmail.com  Fri Jun 12 21:44:42 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 12 Jun 2020 20:44:42 +0000
Subject: [ANN] tanelorn.city: a public gemini host for writers
In-Reply-To: <20200612183916.15f5f495@ventiloplattform.tastytea.de>
References: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
 <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>
 <20200612113645.d5bac3b4523447a4e779dea5@matthewgraybosch.com>
 <20200612183916.15f5f495@ventiloplattform.tastytea.de>
Message-ID: <SSB9UE8V9SAzWxRH7-sjfphPjiF0hOuRyyifQZbTXd5IjRuFDZv5eiydhEBksD-YJKVjTGFyu3cVvaDenGYkv_gE0sXgN4Bt6gGHo0avuaE=@protonmail.com>

I think it should be noted, that to my knowledge,
Kristall, Elpher, Castor and Bollux all do not check certs.

makeworld

??????? Original Message ???????
On Friday, June 12, 2020 12:39 PM, tastytea <tastytea+gemini at tastytea.de> wrote:

> On 2020-06-12 11:36-0400 Matthew Graybosch hello at matthewgraybosch.com
> wrote:
>
> > On Fri, 12 Jun 2020 15:08:36 +0000
> > colecmac at protonmail.com wrote:
> >
> > > Amen. Happy to have another server!
> >
> > Thanks.
> >
> > > However, in Bombadillo I get the error "Cert hostname does not
> > > match". Make sure you're serving up the right certificate!
> >
> > Sorry to hear that!
> > I just downloaded Bombadillo so I could see for myself, and checked my
> > Gemserv config on kanajana. As far as I can tell my config is OK and
> > I'm using the correct cert for each hostname, but the problem might be
> > that kanajana isn't only serving tanelorn.city but demifiend.org and
> > starbreaker.org as well.
> > I'm not sure what to do about it, though since all three sites are
> > accessible using Castor and bollux.
>
> If I interpret the output from`openssl s_client`? correctly, the CN of
> the certificate is set to ?Matthew Graybosch?, not a ?tanelorn.city?,
> as it is custom for HTTPS. However, while the specification states in
> 4.2 that ?Clients can validate TLS connections however they like?, it
> recommends a ?lightweight "TOFU" certificate-pinning system? without
> mentioning hostname validation.
>
> Kristall and elpher also show no error, by the way.
>
> Kind regards, tastytea
>
> ? echo -e 'gemini://tanelorn.city\r\n\r\n' \
> | openssl s_client -verify_hostname tanelorn.city tanelorn.city:1965
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Get my PGP key with `gpg --locate-keys tastytea at tastytea.de` or at
> https://tastytea.de/tastytea.asc.



From luke at marmaladefoo.com  Fri Jun 12 21:46:19 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 12 Jun 2020 21:46:19 +0100
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612112103.GC38108@goldfish.localdomain>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
Message-ID: <5EE3E99B.2030706@marmaladefoo.com>

On 12-Jun-2020 12:21, Natalie Pendragon wrote:
> Okay, I will jump on the update train!
> GUS now provides, by default, size information for every result*.

Just a quick thought - is this really necessary for the text/* content. 
It seems extra info that is not really important to know? As you have 
demonstrated, these files are all *tiny* and it is not something the 
user needs to take on board to act on. The others, yes, this is a nice 
touch and will help the user.

I'd also like to add my moral support to the work of GUS - it is great 
to have such a nice simple search engine that works well :-)

Best Wishes

  - Luke

From colecmac at protonmail.com  Fri Jun 12 21:49:00 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 12 Jun 2020 20:49:00 +0000
Subject: [ANN] gemini-textboard.fgaz.me: a simple textboard
In-Reply-To: <20200612220753.2c8ffd2b@phi>
References: <20200612220753.2c8ffd2b@phi>
Message-ID: <nKFH3O3_hTlx6IacbfaqLSEBD-jAzCd0nF6I_Ci5mSCcEvQGibIvLQmtca-dOqjFqJNe3JDfjGYHlIfOlr-rUREbLBByubw5BtyIJd44Yrg=@protonmail.com>

Bombadillo says the cert is expired. It seems a lot of people are
using clients that don't check TLS...

Anyway this seems like a cool idea, although geddit.pitr.ca was the
first textboard I believe. It only works on links though, so this seems
like a great addition.

makeworld

??????? Original Message ???????
On Friday, June 12, 2020 4:07 PM, Francesco Gazzetta <fgaz at fgaz.me> wrote:

> I'm pleased to announce what I believe is the first forum mediated by
> the Gemini protocol!
>
> gemini://gemini-textboard.fgaz.me/
>
> It's fairly basic for now: you can create new threads and replies, and
> threads are ordered by last activity. For now all posts are kept
> forever, but I plan to add automatic deletion of old threads, as is
> tradition.
>
> Feel free to use it to talk about whatever!
>
> The server is written in Haskell, and this textboard is actually a
> proof of concept for a series of libraries I'm about to release that
> will make it easy to write dynamic Gemini sites. You could call it a
> lightweight "Gemini framework"[1].
>
> The board and libraries' source code is not public yet. I plan to
> announce them in the coming weeks once I finish polishing some stuff.
>
> [1]: Is this an heresy? :)



From fgaz at fgaz.me  Fri Jun 12 22:42:43 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Fri, 12 Jun 2020 23:42:43 +0200
Subject: [ANN] gemini-textboard.fgaz.me: a simple textboard
In-Reply-To: <nKFH3O3_hTlx6IacbfaqLSEBD-jAzCd0nF6I_Ci5mSCcEvQGibIvLQmtca-dOqjFqJNe3JDfjGYHlIfOlr-rUREbLBByubw5BtyIJd44Yrg=@protonmail.com>
References: <20200612220753.2c8ffd2b@phi>
 <nKFH3O3_hTlx6IacbfaqLSEBD-jAzCd0nF6I_Ci5mSCcEvQGibIvLQmtca-dOqjFqJNe3JDfjGYHlIfOlr-rUREbLBByubw5BtyIJd44Yrg=@protonmail.com>
Message-ID: <20200612234243.0bf447e2@phi>

On Fri, 12 Jun 2020 20:49:00 +0000
colecmac at protonmail.com wrote:

> Bombadillo says the cert is expired. It seems a lot of people are
> using clients that don't check TLS...

Oh wait really? I thought I didn't set an expiration date. I'll check.

> Anyway this seems like a cool idea, although geddit.pitr.ca was the
> first textboard I believe. It only works on links though, so this
> seems like a great addition.

Aha, I suspected there was something similar already, but couldn't find
any with GUS. I just posted a link to the textboard there too :)

I also just saw your comment system. I was thinking about doing
something like that next but I see you got it covered!

From solderpunk at SDF.ORG  Fri Jun 12 22:51:46 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 12 Jun 2020 21:51:46 +0000
Subject: [ANN] gemini-textboard.fgaz.me: a simple textboard
In-Reply-To: <20200612234243.0bf447e2@phi>
References: <20200612220753.2c8ffd2b@phi>
 <nKFH3O3_hTlx6IacbfaqLSEBD-jAzCd0nF6I_Ci5mSCcEvQGibIvLQmtca-dOqjFqJNe3JDfjGYHlIfOlr-rUREbLBByubw5BtyIJd44Yrg=@protonmail.com>
 <20200612234243.0bf447e2@phi>
Message-ID: <20200612215146.GG27304@SDF.ORG>

On Fri, Jun 12, 2020 at 11:42:43PM +0200, Francesco Gazzetta wrote:
> On Fri, 12 Jun 2020 20:49:00 +0000
> colecmac at protonmail.com wrote:
> 
> > Bombadillo says the cert is expired. It seems a lot of people are
> > using clients that don't check TLS...
> 
> Oh wait really? I thought I didn't set an expiration date. I'll check.

Just confirming, AV-98 complains:

AV-98> go gemini-textboard.fgaz.me
ERROR: ('Certificate expired as of: 2020-06-11 13:57:35)!',)

Cheers,
Solderpunk

From fgaz at fgaz.me  Fri Jun 12 23:34:58 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Sat, 13 Jun 2020 00:34:58 +0200
Subject: [ANN] gemini-textboard.fgaz.me: a simple textboard
In-Reply-To: <20200612215146.GG27304@SDF.ORG>
References: <20200612220753.2c8ffd2b@phi>
 <nKFH3O3_hTlx6IacbfaqLSEBD-jAzCd0nF6I_Ci5mSCcEvQGibIvLQmtca-dOqjFqJNe3JDfjGYHlIfOlr-rUREbLBByubw5BtyIJd44Yrg=@protonmail.com>
 <20200612234243.0bf447e2@phi> <20200612215146.GG27304@SDF.ORG>
Message-ID: <20200613003458.3d48b9a3@phi>

Okay, I just generated a new one which should be valid for a couple
hundred years I think. Thanks for bringing up the issue

From felix at masterq32.de  Fri Jun 12 23:41:44 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sat, 13 Jun 2020 00:41:44 +0200
Subject: Thoughts on TOFU
Message-ID: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>

Hey List!

While planning out the implementation of TOFU for Kristall, i noticed
something weird:

Quoting the spec:
----------------------------------------------------------------------
TOFU stands for "Trust On First Use" and is public-key security model
similar to that used by OpenSSH.  The first time a Gemini client
connects to a server, it accepts whatever certificate it is presented.
That certificate's fingerprint and expiry date are saved in a persistent
database (like the .known_hosts file for SSH), associated with the
server's hostname.  On all subsequent connections to that hostname, the
received certificate's fingerprint is computed and compared to the one
in the database.  If the certificate is not the one previously received,
but the previous certificate's expiry date has not passed, the user is
shown a warning, analogous to the one web browser users are shown when
receiving a certificate without a signature chain leading to a trusted CA.
----------------------------------------------------------------------

This means that trust in a server is lost as soon as a certificate is
expired and a subsequent renewal of the certificate with the same
private key is the same as visiting the host for the first time. But
when i refresh my server certificate before it expires (which is
recommended), we will have the situation that the client will not trust
the server anymore (same situation as when an attacker is doing a MITM
attack) which i think is not a good situation.

My proposal for both server certificates is the following:
An endpoint stores the public key of the servers certificate as well as
the host name. As long as this host continues to use the same identity
(pub+privkey), it will be trusted. Certificates that aren't refreshed
will error to the client, having another pubkey presented will error
"harder" (as in: this is a possible MITM attack)

The same behaviour could be used for client certificates as well,
allowing the renewal of client certificates with the same private key
(which would solve the "how do i have persistent identities")

What do you guys think?

Regards
- xq

From sean at conman.org  Fri Jun 12 23:48:24 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 12 Jun 2020 18:48:24 -0400
Subject: "Wide load" status code(s)?
In-Reply-To: <20200612112103.GC38108@goldfish.localdomain>
References: <20200610073216.GA16028@SDF.ORG>
 <20200610094914.01a61efd5cbf8d652f124633@matthewgraybosch.com>
 <20200610200337.GG10136@SDF.ORG>
 <20200612112103.GC38108@goldfish.localdomain>
Message-ID: <20200612224823.GF11281@brevard.conman.org>

It was thus said that the Great Natalie Pendragon once stated:
> On Wed, Jun 10, 2020 at 08:03:37PM +0000, solderpunk wrote:
> > I think it is definitely polite to explicitly indicate file sizes for
> > anything larger than, I dunno, 10 MiB or thereabouts?
> >
> > Relatedly, as of a semi-recent update, the automatically generated
> > directory listings produced by Molly Brown include file sizes.
> 
> Okay, I will jump on the update train!
> 
> GUS now provides, by default, size information for every result*.
> 
> It's also exposed as a new query filter, in case you want to explore
> more on your own. I put an example query below to show usage, but you
> can find more documentation on the about page [0].

  Thank you for your work.  This is wonderful.

  -spc


From sean at conman.org  Fri Jun 12 23:50:19 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 12 Jun 2020 18:50:19 -0400
Subject: Thoughts on TOFU
In-Reply-To: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
Message-ID: <20200612225019.GG11281@brevard.conman.org>

It was thus said that the Great Felix Quei?ner once stated:
> Hey List!
> 
> While planning out the implementation of TOFU for Kristall, i noticed
> something weird:
> 
> Quoting the spec:
> ----------------------------------------------------------------------
> TOFU stands for "Trust On First Use" and is public-key security model
> similar to that used by OpenSSH.  The first time a Gemini client
> connects to a server, it accepts whatever certificate it is presented.
> That certificate's fingerprint and expiry date are saved in a persistent
> database (like the .known_hosts file for SSH), associated with the
> server's hostname.  On all subsequent connections to that hostname, the
> received certificate's fingerprint is computed and compared to the one
> in the database.  If the certificate is not the one previously received,
> but the previous certificate's expiry date has not passed, the user is
> shown a warning, analogous to the one web browser users are shown when
> receiving a certificate without a signature chain leading to a trusted CA.
> ----------------------------------------------------------------------
> 
> This means that trust in a server is lost as soon as a certificate is
> expired and a subsequent renewal of the certificate with the same
> private key is the same as visiting the host for the first time. But
> when i refresh my server certificate before it expires (which is
> recommended), we will have the situation that the client will not trust
> the server anymore (same situation as when an attacker is doing a MITM
> attack) which i think is not a good situation.
> 
> My proposal for both server certificates is the following:
> An endpoint stores the public key of the servers certificate as well as
> the host name. As long as this host continues to use the same identity
> (pub+privkey), it will be trusted. Certificates that aren't refreshed
> will error to the client, having another pubkey presented will error
> "harder" (as in: this is a possible MITM attack)
> 
> The same behaviour could be used for client certificates as well,
> allowing the renewal of client certificates with the same private key
> (which would solve the "how do i have persistent identities")
> 
> What do you guys think?

  I think that's reasonable, as the client certificate for gemini.conman.org
is set to expire in a few days (I run my own CA as an experiment).  

  -spc


From acdw at acdw.net  Fri Jun 12 23:50:47 2020
From: acdw at acdw.net (Case Duckworth)
Date: Fri, 12 Jun 2020 17:50:47 -0500
Subject: [ANN] tanelorn.city: a public gemini host for writers
In-Reply-To: <SSB9UE8V9SAzWxRH7-sjfphPjiF0hOuRyyifQZbTXd5IjRuFDZv5eiydhEBksD-YJKVjTGFyu3cVvaDenGYkv_gE0sXgN4Bt6gGHo0avuaE=@protonmail.com>
References: <20200612103144.9260c2fe077a467cb46beb69@matthewgraybosch.com>
 <UiqvWICU1n738TO4tzlECw8yCzoUk_vXz-d8KFQrjocsftUYWd1s-5Trh3fGshax_giihmF7xNa66PPeGK5eWHpaWHcNoXzWugjU1XaNrww=@protonmail.com>
 <20200612113645.d5bac3b4523447a4e779dea5@matthewgraybosch.com>
 <20200612183916.15f5f495@ventiloplattform.tastytea.de>
 <SSB9UE8V9SAzWxRH7-sjfphPjiF0hOuRyyifQZbTXd5IjRuFDZv5eiydhEBksD-YJKVjTGFyu3cVvaDenGYkv_gE0sXgN4Bt6gGHo0avuaE=@protonmail.com>
Message-ID: <a625a103-6261-4824-8a4f-d4846e20ec3e@www.fastmail.com>

On Fri, Jun 12, 2020, at 3:44 PM, colecmac at protonmail.com wrote:
> I think it should be noted, that to my knowledge,
> Kristall, Elpher, Castor and Bollux all do not check certs.
> 
> makeworld

For bollux, this is correct. TOFU implementation and certificate-checking is on the Very Important list for writing. So there's another good reason to make sure the certs work.

From pellertson at firemail.cc  Sat Jun 13 01:53:35 2020
From: pellertson at firemail.cc (Parker Ellertson)
Date: Fri, 12 Jun 2020 17:53:35 -0700
Subject: [ANN] A new gemini client for acme
Message-ID: <20200612175335.2eb6c05c.pellertson@firemail.cc>

This client is 52 lines long (68 if you count the lines in
"displayonacme"), and as of now it's just a bare-bones client that
doesn't do any sort of TOFU authentication or self-signing certs.
There will be improvements made on it later (such as not opening
duplicate windows for the same URL) but I'm very happy with the way it
is now.  The GitHub link is at the bottom, and there's probably a bug
or two.  I'm going to continue work on this so that it's top-notch.

- Parker

https://github.com/pellertson/gacme


From lel at envs.net  Sat Jun 13 02:06:51 2020
From: lel at envs.net (lel)
Date: Sat, 13 Jun 2020 01:06:51 +0000
Subject: [ANN] A new gemini client for acme
In-Reply-To: <20200612175335.2eb6c05c.pellertson@firemail.cc>
References: <20200612175335.2eb6c05c.pellertson@firemail.cc>
Message-ID: <20200613010651.GA14738@core.envs.net>


You're my hero. I've been using a color-stripped AV-98 in a win pane.

Thank you so much lmao,
~lel

From escondida at iff.ink  Sat Jun 13 04:24:08 2020
From: escondida at iff.ink (Ivy Foster)
Date: Fri, 12 Jun 2020 22:24:08 -0500
Subject: [ANN] A new gemini client for acme
In-Reply-To: <20200612175335.2eb6c05c.pellertson@firemail.cc>
References: <20200612175335.2eb6c05c.pellertson@firemail.cc>
Message-ID: <20200613032408.GA24829@thrax.localdomain>

On 12 Jun 2020, at  5:53 pm -0700, Parker Ellertson wrote:
> This client is 52 lines long (68 if you count the lines in
> "displayonacme"), and as of now it's just a bare-bones client that
> doesn't do any sort of TOFU authentication or self-signing certs.
> There will be improvements made on it later (such as not opening
> duplicate windows for the same URL) but I'm very happy with the way it
> is now.  The GitHub link is at the bottom, and there's probably a bug
> or two.  I'm going to continue work on this so that it's top-notch.

This is already an excellent start; thank you! I've been wanting an
acme client for this right along, but have been too tired to
just...sit down and do it...so, again, thanks!

Incidentally, if you do decide to rewrite in rc (as practice with it
or whatever, given the comment in the script), $PLAN9/lib/acme.rc has
convenience functions for a lot of the stuff in displayonacme.

Cheers,
Ivy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200612/9e8f8a9c/attachment.sig>

From sean at conman.org  Sat Jun 13 06:39:26 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 01:39:26 -0400
Subject: Uploading Gemini content
Message-ID: <20200613053926.GH11281@brevard.conman.org>


  Okay, there's quite a few people on this list what would like to see more
content in Gemini.  What I'm proposing is *not* a modification to the Gemini
protocol itself, but it's an adjunct that *could* be implemented [1] to ease
the creation of more Gemini content.  I'm not trying to scare you,
solderpunk, there are others working on this concept, but they aren't on the
mailing list because of technical issues [2].

  Anyway, it's *another* protocol, very similar to Gemini but one that uses
a new URL scheme, to ensure that no one mistakes this for the actual Gemini
protocol.  There are already two variations on this, one by Alex Schroeder
[3] and one by baschdel [4].  The one I've constructed is a mix of the two
but not quite the same.

  I define two new URL schemes---"gemini+put" and "gemini+del".  The first
is to add (or update) a file to a server, while the second exists to delete
a file.  The protocol for uploading a file (C=client, S=server):

C: gemini+put://example.com/path/to/new.txt?mime=text/plain&size=1024 CRLF
S: 1x continue CRLF
C: size bytes of content
S: 31 gemini://example.com/path/to/new.txt CRLF <close>

  The thought process behind this is for the client to send the full path to
the new (or updated) resource.  They query string sends along some critical
information about the upload, the MIME type and the size.  This allows the
server to reject certain types of content or restrict the resources to a
given size. I'm using the query string for this information the other
methods defined by Alex and baschdel stray a bit too far from Gemini (in my
opinion).  I also think it's fine here as I've defined a new URL scheme and
I can say what the sections mean.

  I included the 1x response (input) in order to give the server a chance to
return errors (like unsupported MIME type or size issues) before the client
sends the data.  So the client can expect to see 4x or 5x here (or even
6x---but more on this below).  Once the client sees the 1x response, it can
then proceed with uploading the content.  Upon successfully receiving the
data, the server then responds with a 31 redirection to the new resource on
the server.  I can see an argument for a 20 status, but to me, 31 (a
permanent redirection) seems semantically better for a "successful" upload.

  The protocol to delete a file is not complicated either (C=client,
S=server):

C: gemini+del://example.com/path/to/old.txt CRLF
S: 52 Gone CRLF <close>

  Again, here a 52 response makes sense as the resource is being
deleted---any other error means an actual error.

  Now obviously this requires some security, so a client certificate giving
authority is required.  The "proof-of-concept" uses the Common Name from the
certificate to control access to the appropriate files.  Assuming user
content is defined by:

	gemini://example.com/~user/

a user of the site could generate (and have validated) or be given (by the
admins) a certificate to use to upload content.  The common name could be
the user name so the server will know what area of the filesystem a
certificate is valid for.  

  The idea is for a user to be able to use a Gemini client to not only
browse Gemini content, but *create* and upload new content to a server, from
within the client (a client can shell out to an editor, for instance).  This
should reduce the friction of generating content.

  I do have a "proof-of-concept" mostly finished [5], and if there is enough
interest, I can make it live.  The registration process would probably be
something like:

	1. Generate a CSR (only field required will be CN)
	2. Upload the CSR to a known path (with MIME type application/pkcs10)
	3. Server will then accept the request, sign it, and redirect to the
	   certificate the client can use (MIME type
	   application/x-x509-user-cert).

  And I repeat---this is *NOT* intended to become part of the actual Gemini
protocol, but an adjunct, a separate protocol that is still simple, but
allows data to flow from the client to the server.  And if solderpunk sticks
his fingers in his ears and goes "La la la la la la la" that's fine
too---this is just an idea.

  -spc

[1]	Because I've implemented it.  It's not live, *yet*.  But my
	"proof-of-concept" does work.

[2]	https://alexschroeder.ch/wiki/2020-06-04_DMARC_an_Mailing_Lists

[3]	https://alexschroeder.ch/wiki/2020-06-05_Gemini_Write
	https://alexschroeder.ch/wiki/2020-06-04_Gemini_Upload

[4]	https://alexschroeder.ch/wiki/Baschdels_spin_on_Gemini_uploading

[5]	All the bits except for certificate generation.  I need to work on
	client certificate verification in GLV-1.12556.

From hello at matthewgraybosch.com  Sat Jun 13 06:55:20 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 13 Jun 2020 01:55:20 -0400
Subject: sysadmin advice concerning backups
Message-ID: <20200613015520.e844d1f5e0b364b51627e383@matthewgraybosch.com>

I could use a little sysadmin advice, because this is really my first
time hosting other people and I don't want to screw it up.

I've got weekly backups arranged via Vultr, but I'm also thinking of
setting up a cron job that takes nightly backups of all users'
public_gemini directories using tar and gzip.

Admittedly this is something users should be doing for themselves if
they're using their shell accounts to write instead of uploading from
their own machines, but I want tanelorn.city to be a welcoming place
for writers even if they aren't Unix wizards, and I think that means
making sure their data is safe.

Is this something that other pubnixes provide for users' home
directories? Are there any downsides I should be aware of aside from
the impact on CPU and storage as more people join tanelorn.city?

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

From solderpunk at SDF.ORG  Sat Jun 13 07:20:17 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 13 Jun 2020 06:20:17 +0000
Subject: Thoughts on TOFU
In-Reply-To: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
Message-ID: <20200613062017.GA19164@SDF.ORG>

On Sat, Jun 13, 2020 at 12:41:44AM +0200, Felix Quei?ner wrote:
 
> My proposal for both server certificates is the following:
> An endpoint stores the public key of the servers certificate as well as
> the host name. As long as this host continues to use the same identity
> (pub+privkey), it will be trusted. Certificates that aren't refreshed
> will error to the client, having another pubkey presented will error
> "harder" (as in: this is a possible MITM attack)

I'm not sure this makes sense: if you expect me to believe that you will
keep your private key secure from compromise for N days/months/years,
then why not just send me a certificate which doesn't expire for N
days/months/years?

But I could be jumping the gun on that.  I haven't had any coffee yet
and there are a host of other reasons that certificates expire beyond
concerns about key compromise.  Some of them don't really transfer from
CA-land to self-signed TOFU land.  But some may...in which case some
kind of "long keys, short certs" model might indeed make sense.

Cheers,
Solderpunk

From me at case.codes  Sat Jun 13 07:22:02 2020
From: me at case.codes (me at case.codes)
Date: Sat, 13 Jun 2020 00:22:02 -0600
Subject: ANN: deedum a mobile gemini browser
Message-ID: <10758a6e-8946-49fd-a32b-9b4053fc4586@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200613/f381fe88/attachment.htm>

From hello at matthewgraybosch.com  Sat Jun 13 07:23:23 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 13 Jun 2020 02:23:23 -0400
Subject: Uploading Gemini content
In-Reply-To: <20200613053926.GH11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
Message-ID: <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>

On Sat, 13 Jun 2020 01:39:26 -0400
Sean Conner <sean at conman.org> wrote:

>   I define two new URL schemes---"gemini+put" and "gemini+del".  The
> first is to add (or update) a file to a server, while the second
> exists to delete a file.  The protocol for uploading a file
> (C=client, S=server):

May I suggest calling this ancillary protocol "titan" after the Titan
II missile repurposed by NASA as a launch vehicle for the Gemini
program? This might help distinguish it from the main gemini protocol.

Also, I'm curious as to what this protocol offers over uploading via
sftp or rsync. Just as clients could shell out to $EDITOR or $VISUAL,
couldn't they also create, update, or delete remote content using
existing tools?

Are you trying to design a platform-agnostic method suitable
for non-Unix and non-Linux clients and servers?

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

From me at case.codes  Sat Jun 13 07:58:44 2020
From: me at case.codes (me at case.codes)
Date: Sat, 13 Jun 2020 06:58:44 +0000
Subject: ANN: deedum a mobile gemini browser
Message-ID: <28e0fb3cdfd4c2173efc909db233769f@case.codes>

[apologies if this is duped, I fear my mail client was sending html and the message got dropped by
the listserv]

Hi all,

What an amazing and inspiring community I've stumbled upon.

I've long been lamenting the idea that a web browser now takes somewhere around a billion dollars
to build. So when I came across gemini I had to try out it's promise of being able to build a
client with low effort.

So I picked up flutter and the protocol spec and made a gemini browser; deedum. This is really cool
to me cause I probably spent less than 16hours on it, mostly fighting fixed width font rendering in
flutter and it's also my first real app.

It's awaiting review in the android playstore, and I'll be trying to get it building for iOS and
into the app store. I'll also look into what it takes to get on fdroid.

Here's the repo

https://github.com/snoe/deedum

If anyone wants to jump in you are more than welcome!

A couple things I ran into:

It's missing client certs, its not clear to me if they actually should be transient or just fully
user managed. They have cool potential though!

Some sites don't seem to close the socket after sending a response, this could be me doing
something wrong but gemini://mozz.us:1965/journal/ is one example of such a site.

`ncat --ssl -c "cat test.gmi" ...` is great for testing, and also proves what a great idea gemini
is.

Thanks!
Case

Email domain proudly hosted at migadu.com

-- Email domain proudly hosted at https://migadu.com


From solderpunk at SDF.ORG  Sat Jun 13 08:05:50 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 13 Jun 2020 07:05:50 +0000
Subject: ANN: deedum a mobile gemini browser
In-Reply-To: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
References: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
Message-ID: <20200613070550.GB19164@SDF.ORG>

On Sat, Jun 13, 2020 at 06:58:44AM +0000, me at case.codes wrote:
> [apologies if this is duped, I fear my mail client was sending html and the message got dropped by
> the listserv]

It didn't get dropped, but goodness, what a relief to get a plaintext
version! :)

> It's awaiting review in the android playstore, and I'll be trying to get it building for iOS and
> into the app store. I'll also look into what it takes to get on fdroid.

That would be just wonderful!  There is so far only one other Android
client to my knowledge, and it's not yet in either of those places.
It's also a little out of date now, with a few spec changes having
happened since it was made.  A more recent Android client available from
F-Droid would make me very happy.

> It's missing client certs, its not clear to me if they actually should be transient or just fully
> user managed. They have cool potential though!

The spec will hopefully be a bit clearer on that front quite soon.  But
I still think people writing new clients now would be making an entirely
rational decision to not bother wading into the client cert thing until
some more established conventional workflows have been settled on.  It's
the most "under development" part of the whole thing by far at this
point, and they are also not necessary to view 99% of what's currently
in Geminispace, so there is no need to rush into supporting them.

Cheers,
Solderpunk

From sean at conman.org  Sat Jun 13 08:05:57 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 03:05:57 -0400
Subject: Uploading Gemini content
In-Reply-To: <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
Message-ID: <20200613070556.GI11281@brevard.conman.org>

It was thus said that the Great Matthew Graybosch once stated:
> On Sat, 13 Jun 2020 01:39:26 -0400
> Sean Conner <sean at conman.org> wrote:
> 
> >   I define two new URL schemes---"gemini+put" and "gemini+del".  The
> > first is to add (or update) a file to a server, while the second
> > exists to delete a file.  The protocol for uploading a file
> > (C=client, S=server):
> 
> May I suggest calling this ancillary protocol "titan" after the Titan
> II missile repurposed by NASA as a launch vehicle for the Gemini
> program? This might help distinguish it from the main gemini protocol.

  I'll keep that in mind if the idea proves popular.

> Also, I'm curious as to what this protocol offers over uploading via
> sftp or rsync. Just as clients could shell out to $EDITOR or $VISUAL,
> couldn't they also create, update, or delete remote content using
> existing tools?
> 
> Are you trying to design a platform-agnostic method suitable
> for non-Unix and non-Linux clients and servers?

  One of Sir Tim Berners-Lee's initial ideas for HTTP was to allow the user
to edit the page in the browser and have that update the file on the server. 
HTTP didn't get this capability until May of 1996 [1] where various methods
were defined that included PUT and DELETE.  It's sad to think that no
browsers at that time even attempted to do that [2].  Instead, we kept on
using FTP, later sftp and maybe even rsync for the technically minded.

  As I mentioned, I know of at least two other people working on this
concept [3], and the notion that having a single tool (even if it just
shells out for the editing portion) might be a good idea to reduce friction. 
And the non-Unix thing is a bonus (but I wasn't even thinking in that
direction).

  -spc

[1]	RFC-1945 which describes HTTP/1.0.

[2]	Although if anyone knows of a browser that did, I'd like to know
	about it.

[3]	To support a wiki on Gemini.

From pellertson at firemail.cc  Sat Jun 13 08:19:11 2020
From: pellertson at firemail.cc (Parker Ellertson)
Date: Sat, 13 Jun 2020 00:19:11 -0700
Subject: [ANN] A new gemini client for acme
Message-ID: <20200613001911.79647b15.pellertson@firemail.cc>

I didn't expect such an immediate response for this client.  To lel,
ivy, and who ever else might use this client: thank you!

I just fixed a bug on the client, so it now handles relative paths
correctly.  The basic client is *finally* complete!

~ A pretty tipsy Parker

From luke at marmaladefoo.com  Sat Jun 13 09:26:50 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 13 Jun 2020 09:26:50 +0100
Subject: Uploading Gemini content
In-Reply-To: <20200613070556.GI11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
Message-ID: <5EE48DCA.2040706@marmaladefoo.com>

On 13-Jun-2020 08:05, Sean Conner wrote:
> One of Sir Tim Berners-Lee's initial ideas for HTTP was to allow the user
> to edit the page in the browser and have that update the file on the server.
> HTTP didn't get this capability until May of 1996 [1] where various methods
> were defined that included PUT and DELETE.  It's sad to think that no
> browsers at that time even attempted to do that [2].  Instead, we kept on
> using FTP, later sftp and maybe even rsync for the technically minded.

Actually there was Amaya (defunct 2012) which was a W3 reference browser 
which implemented read and write for the web. There was also a version 
of Netscape Navigator (3.04 Gold) that had something too.

https://www.w3.org/Amaya/

https://www.webdesignmuseum.org/old-software/web-browsers/netscape-navigator-3-04

Sadly it never really took off as it is less than 1% (n.b. made up 
statistic) of people that write the content on the web, so no-one really 
needed that functionality. But in Gemini, the readers and writers are a 
more overlapping set, as the barriers to participation are lowered.

However, as we all know, what really did explode was the wiki concept of 
being able to edit content in your browser, which has led to the 
plethora of editable websites we see today and markdown.

I'd really like to see a simple concept in gemini (+friends) of being 
able to do this. It would be good to thrash this out.

We already have the simplest, most useful text based markup language, so 
that bit is done.

I think your ideas for a schema are a good start.

> C: gemini+put://example.com/path/to/new.txt?mime=text/plain&size=1024 CRLF
> S: 1x continue CRLF
> C: size bytes of content

I would like to see the target path be a percent encoded parameter to 
the end point, otherwise we cannot so easily implement multiple end 
points on the same server. For example there might be a number of 
different server of CGI applications able to receive content on the same 
server or domain.

so maybe something like this is a more flexible way to specify the put 
request

C: gemini+put://example.com/put-handler?path=path/to/new.txt?mime=text/plain&size=1024 CRLF
<continues>

One idea I've been working with is to integrate this with the preformatted area of a page, and then the client could render certain types using a text editor, something like this:

```gemini+write://example.com/put-handler?path=path/to/new.txt

this content can be edited by the user and the client provides a button somewhere to "submit" it

```end of content

On submitting, the mime=text/plain and size=XYZ is provided

Best Wishes

  - Luke


From felix at masterq32.de  Sat Jun 13 11:38:06 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sat, 13 Jun 2020 12:38:06 +0200
Subject: Uploading Gemini content
In-Reply-To: <20200613053926.GH11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
Message-ID: <dd25962d-2486-207a-9425-9427be4ac745@masterq32.de>

Hey Sean and others!

> *snips the whole protocol description*

I was too working on a gemini extension to allow arbitrary data uploads
as "10 INPUT" is a bit too restricted to ~700 byte of data payload.

But now that i read your gemini+put and gemini+delete extension, i think
i don't need to continue braining over my extension and it's flaws.

I really like the proposal. It's easy to implement and integrate both on
server and client side.
The "gemini+delete" scheme is just the normal gemini handling routine
and the upload routine can be put "in front" of a normal gemini request
and can be handled with the normal response handler.

> The idea is for a user to be able to use a Gemini client to not only
> browse Gemini content, but *create* and upload new content to a
> server, from within the client (a client can shell out to an editor,
> for instance). This should reduce the friction of generating content.

Yes, that was my vision as well. Allow users to write and update their
gemlogs from within a client. Right now, i'm sshing into my server and
author all the files by hand. But just opening Kristall, going to my
gemlog, activating my "editor certificate" and just start editing my
site is just appealing!

Regards
- xq

From luke at marmaladefoo.com  Sat Jun 13 14:06:48 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 13 Jun 2020 14:06:48 +0100
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <5EE48DCA.2040706@marmaladefoo.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
Message-ID: <5EE4CF68.20100@marmaladefoo.com>

Hi everyone

I've been thinking some more about this self-editing wiki concept, which 
seems a great application to support writers of Gemini content. I think 
there is an opportunity for a very simple addition to Gemini that would 
support client based content submission.

The mental model is quite simple - imagine a simple web page, having a 
single text area and a single submit button. The user can edit the text 
and submit the content. The client knows where to send the content (form 
attribute) and how to send it (HTTP protocol using POST).

Exactly what the name for this doesnt really matter, and it will need to 
integrate with the authentication/certificates mechanisms we already are 
establishing.

Essentially there are a number of new elements

1. New scheme extending gemini, only for those that want to. This is not 
gemini, but something else. Whether it gets considered for gemini is a 
separate conversation.

2. An extended client behaviour working with the preformatted text 
regions having suitable markers to be defined

3. A simple text submit protocol (text/plain only, UTF-8 only)

The elements could look like this

1. The scheme name is gemini+submit:// or something, doesnt really 
matter, but is distinct from gemini://.

2. Using the preformatted regions to specify the URL end point to post 
to. Only end points having gemini+submit:// as the scheme would have an 
active behaviour. This is done in a backwards compatible way so simpler 
clients just render the content as preformatted text

Note we use 4 back ticks to convey that the content may be edited and 
submitted. There could be some other option to indicate this, the syntax 
marker is not significant, can be changed to ```! or something else. 
This gracefully degrades and is valid text/gemini

````gemini+submit://domain/end-point/handler?any-params-you-like-probably-includes-asset-id-or-path

```` (could be 3 or 4 doesnt really matter)

the 4 back ticks mean existing clients will just show the text.

The URI will probably contain information for the server to know where 
to put the content such as:

asset-id=1234ae4f34ae

or

path=/path/on/filesystem/to/file.gmi

3. The client allows the user to edit the content and then "submit" 
(button or whatever) the content to the end point as follows:

CONTENTLENGTH<SPACE>FULL_URI_FROM_TEXT_AREA<CR><LF>
<client sends the byte content>
<client closes connection>

Only text/plain is ever sent so we don't need to specify mime type. 
Simple and restricted.
Only UTF is ever sent, so we dont need to specify it. Simple and restricted.

There is only ever one "block" of text submitted, which is the content 
of the preformatted area (no multi-field forms).

The end point on the server knows when content has arrived as the 
content length is pre-notified in the header, replies with redirect to 
success page probably.

server may also respond requesting input,certificates

on the server, the end point might be inside the server or could be a 
CGI or similar application that might get the content via stdin (as per 
POST for HTTP)

It would be nice to adopt a common scheme for this together with 
gemini+put:// (for arbitrary binary upload) and gemini+delete:// 
suggestions suggested earlier on this thread. For example to integrate 
certificates, success or failure etc.

Potentially this scheme can be used to edit simple text content of a 
number of back end applications.

There are no changes need to any client or server that is not interested 
to implement this.

I think this has a similar simplicity to the spirit of Gemini and does 
not open huge doors for a horse and cart to come through.

Best Wishes

  - Luke

From pitr.vern at gmail.com  Sat Jun 13 15:14:06 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sat, 13 Jun 2020 16:14:06 +0200
Subject: [ANN ] Gig - Go framework
Message-ID: <CAG-mZ3i4zfqHLQdFKkGDCDFa-z7=dMX5XZbML-muEkF=Z4b3Vg@mail.gmail.com>

Sort of like a Go web frameworks such as gin and echo. Zero allocation
router, groups, middleware, template support, client certificates,
90+% test coverage etc.

https://github.com/pitr/gig

I've rebuilt gemini://geddit.pitr.ca using it so it is battle tested :)

From tomasino at lavabit.com  Sat Jun 13 15:49:07 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sat, 13 Jun 2020 14:49:07 +0000
Subject: sysadmin advice concerning backups
In-Reply-To: <20200613015520.e844d1f5e0b364b51627e383@matthewgraybosch.com>
References: <20200613015520.e844d1f5e0b364b51627e383@matthewgraybosch.com>
Message-ID: <59665c9d-26fa-eb08-545f-3d8e1e3a4d6b@lavabit.com>

On 6/13/20 5:55 AM, Matthew Graybosch wrote:
> I could use a little sysadmin advice, because this is really my first
> time hosting other people and I don't want to screw it up.

I run {https,gopher,gemini}://cosmic.voyage which I believe to be quite similar to what you're doing. I have a cron that grabs all the writing content, commits it to a git repo, and pushes it up each night. In fact, I do it with the wiki on the site too.

https://tildegit.org/cosmic/cosmic-backup

Since it's all text content, relying on git's diffing saves me the overhead on filesize of binary blobs. I also have a way to roll back through time in case someone accidentally does something horrific. If nothing changed, the git commit is empty and I waste nothing. Honestly, it's worked out great so far as my community's content is all text.

Oh, and yes, I also run backups on Vultr. :)

Best of luck to you!


From pitr.vern at gmail.com  Sat Jun 13 16:37:22 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sat, 13 Jun 2020 17:37:22 +0200
Subject: ANN: deedum a mobile gemini browser
In-Reply-To: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
References: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
Message-ID: <CAG-mZ3gkfqny9KAmjWJi8djWcu3Pqmv+H5vzt+NuYNJ9tJmmRQ@mail.gmail.com>

Awesome work! I personally decided against using a cross-platform
frameworks for my iOS client (source here
https://github.com/pitr/gemini-ios), since I've never used them
before. Once you get to iOS submission to the app store, feel free to
reach out, as it was not quite straight forward for my app to get
approved even for beta testing in Testflight.

On Sat, Jun 13, 2020 at 8:58 AM <me at case.codes> wrote:
>
> [apologies if this is duped, I fear my mail client was sending html and the message got dropped by
> the listserv]
>
> Hi all,
>
> What an amazing and inspiring community I've stumbled upon.
>
> I've long been lamenting the idea that a web browser now takes somewhere around a billion dollars
> to build. So when I came across gemini I had to try out it's promise of being able to build a
> client with low effort.
>
> So I picked up flutter and the protocol spec and made a gemini browser; deedum. This is really cool
> to me cause I probably spent less than 16hours on it, mostly fighting fixed width font rendering in
> flutter and it's also my first real app.
>
> It's awaiting review in the android playstore, and I'll be trying to get it building for iOS and
> into the app store. I'll also look into what it takes to get on fdroid.
>
> Here's the repo
>
> https://github.com/snoe/deedum
>
> If anyone wants to jump in you are more than welcome!
>
> A couple things I ran into:
>
> It's missing client certs, its not clear to me if they actually should be transient or just fully
> user managed. They have cool potential though!
>
> Some sites don't seem to close the socket after sending a response, this could be me doing
> something wrong but gemini://mozz.us:1965/journal/ is one example of such a site.
>
> `ncat --ssl -c "cat test.gmi" ...` is great for testing, and also proves what a great idea gemini
> is.
>
> Thanks!
> Case
>
> Email domain proudly hosted at migadu.com
>
> -- Email domain proudly hosted at https://migadu.com
>

From pitr.vern at gmail.com  Sat Jun 13 18:50:48 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sat, 13 Jun 2020 19:50:48 +0200
Subject: [ANN] Egsam - A new client torture tester
Message-ID: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>

Pronounced egg-sam :)

Building my client, I noticed that there were edge cases that I wanted
to test but was not able to. Hopefully this is useful to others
building clients as well. I broke up the spec into sections and tested
each one individually. At the end you get a score!

gemini://egsam.pitr.ca/

Source code is at https://github.com/pitr/egsam - if there are any
edge cases missing, please open an issue, or better yet a pull
request/patch.

Cheers!

From solderpunk at SDF.ORG  Sat Jun 13 19:15:52 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 13 Jun 2020 18:15:52 +0000
Subject: Draft spec changes for comments
Message-ID: <20200613181552.GC18831@SDF.ORG>

Hey folks,

At gemini://gemini.circumlunar.space/docs/specification-modified.gmi you
will find a modified version of the current spec.  If you download it,
along with the current spec from
gemini://gemini.circumlunar.space/docs/specification.gmi, you can `diff`
them to see the changes.  These changes are a tentative version of those
I want to make before making a new official update and then, at last,
freezing the spec again.  I'm making them available now so people can
point out oversights or suggest improvements.

The changes are:

* Fix a section numbering error
* Define the gemini URI scheme, and explicitly disallow the userinfo
  subcomponent of the authority component, protecting us from Petite
  Abeille's "auto cookie" construct.
* Add a minimal definition of alt text to the definition of preformatted
  mode toggle lines, to address accessability and searchability
  concerns, as well as to close, or at least ameliorate, the
  extensibility loophole identified by Katarina Eriksson.
* A simplification of the client certificate status codes and details,
  including removing transient client certificates as a formally defined
  construct with prescribed behaviour.

I hope that the alt text and client certificate stuff can be augmented
by best practices established outside the spec itself to fill in
details.

If people think we can do a better job of the above changes, I'm happy
to hear about it, but I don't want to consider any non-trivial changes
other than the above before a nice long freeze.

Cheers,
Solderpunk

From tcb913 at gmail.com  Fri Jun 12 17:40:50 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Fri, 12 Jun 2020 12:40:50 -0400
Subject: What is Gemini - a video by me
In-Reply-To: <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
 <20200612094112.GA6497@SDF.ORG>
 <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
Message-ID: <6A760C43-A186-4F43-86FE-43A9F232E1B8@gmail.com>

FYI: The youtube video will not play on my Mac desktop. It crashes within 5 seconds of start.

I have never used toobnix, and I was unable to figure out how to start it.

This is why simple text is the way to go!

Terry Brennan


On Jun 12, 2020, at 7:14 AM, James Tomasino <tomasino at lavabit.com> wrote:

> Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here:
> 
> https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e
> 
> https://www.youtube.com/watch?v=DoEI6VzybDk
> 
> Please leave comments on anything I got wrong so others can benefit.
> 
> I've also pushed up my "notes" slide with these links to my gemlog on tilde.black here:
> 
> gemini://tilde.black/users/fox/journal/20200612-what-is-gemini.gmi
> 


From hello at matthewgraybosch.com  Sat Jun 13 20:05:01 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 13 Jun 2020 15:05:01 -0400
Subject: ANN: deedum a mobile gemini browser
In-Reply-To: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
References: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
Message-ID: <20200613150501.28bec2c338e52878cc06e004@matthewgraybosch.com>

On Sat, 13 Jun 2020 06:58:44 +0000
me at case.codes wrote:

> It's awaiting review in the android playstore, and I'll be trying to
> get it building for iOS and into the app store. I'll also look into
> what it takes to get on fdroid.

I'm glad to hear about this, and I'd love to be able to install deedum
via fdroid.

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

From hannu.hartikainen+gemini at gmail.com  Sat Jun 13 21:06:34 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Sat, 13 Jun 2020 23:06:34 +0300
Subject: Draft spec changes for comments
In-Reply-To: <20200613181552.GC18831@SDF.ORG>
References: <20200613181552.GC18831@SDF.ORG>
Message-ID: <CANmFPektB2RtMG1D6Fxgd0gTx8oPm20-Rrhmj+MaBXpuqJWz0A@mail.gmail.com>

Looks good to me. I noticed there's a lone tab on row 322; maybe fix that
too.

On Sat, 13 Jun 2020 at 21:16, solderpunk <solderpunk at sdf.org> wrote:

> Hey folks,
>
> At gemini://gemini.circumlunar.space/docs/specification-modified.gmi you
> will find a modified version of the current spec.  If you download it,
> along with the current spec from
> gemini://gemini.circumlunar.space/docs/specification.gmi, you can `diff`
> them to see the changes.  These changes are a tentative version of those
> I want to make before making a new official update and then, at last,
> freezing the spec again.  I'm making them available now so people can
> point out oversights or suggest improvements.
>
> The changes are:
>
> * Fix a section numbering error
> * Define the gemini URI scheme, and explicitly disallow the userinfo
>   subcomponent of the authority component, protecting us from Petite
>   Abeille's "auto cookie" construct.
> * Add a minimal definition of alt text to the definition of preformatted
>   mode toggle lines, to address accessability and searchability
>   concerns, as well as to close, or at least ameliorate, the
>   extensibility loophole identified by Katarina Eriksson.
> * A simplification of the client certificate status codes and details,
>   including removing transient client certificates as a formally defined
>   construct with prescribed behaviour.
>
> I hope that the alt text and client certificate stuff can be augmented
> by best practices established outside the spec itself to fill in
> details.
>
> If people think we can do a better job of the above changes, I'm happy
> to hear about it, but I don't want to consider any non-trivial changes
> other than the above before a nice long freeze.
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200613/a51b8430/attachment.htm>

From hello at matthewgraybosch.com  Sat Jun 13 21:26:39 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 13 Jun 2020 16:26:39 -0400
Subject: sysadmin advice concerning backups
In-Reply-To: <59665c9d-26fa-eb08-545f-3d8e1e3a4d6b@lavabit.com>
References: <20200613015520.e844d1f5e0b364b51627e383@matthewgraybosch.com>
 <59665c9d-26fa-eb08-545f-3d8e1e3a4d6b@lavabit.com>
Message-ID: <20200613162639.bf8c9e796ea374d0b91594e4@matthewgraybosch.com>

On Sat, 13 Jun 2020 14:49:07 +0000
James Tomasino <tomasino at lavabit.com> wrote:

> On 6/13/20 5:55 AM, Matthew Graybosch wrote:

> I run {https,gopher,gemini}://cosmic.voyage which I believe to be
> quite similar to what you're doing. 

I've been to cosmic.voyage a few times, actually. Lots of good stuff
there, and I love the premise. I actually plugged cosmic.voyage in my
ballots for the 2019 and 2020 World Fantasy Awards.

tanelorn.city is a little different, though. The name might be inspired
by Michael Moorcock, but there's no unifying premise or theme to what
people write there. You don't have to write Moorcock pastiches to be
welcome. :)

> I have a cron that grabs all the writing content, commits it to a git
> repo, and pushes it up each night. In fact, I do it with the wiki on
> the site too.

Thanks. I've implemented something similar with tanelorn.city users'
public_gemini directories. However, I think I'll combine it with a
strategy involving rsync and rdiff_backup that Thomas Karpiniec
suggested off-list.

> Best of luck to you!
 
Thanks. I appreciate the help.

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

From solderpunk at SDF.ORG  Sat Jun 13 21:56:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 13 Jun 2020 20:56:35 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <5EE4CF68.20100@marmaladefoo.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com>
Message-ID: <20200613205635.GD18831@SDF.ORG>

A couple of thoughts on this new line of discussion:

1. I am very grateful that people have made a point of defining this as
separate "companion" protocol rather than asking for it as part of the
core Gemini protocol, to give me a bit of breathing room.  I *do* like
the idea of naming it titan://...

2. At this point I can only laugh at the completeness with which using
URIs as requests has backfired on me.  First the userinfo auto cookie
debacle and now, hah, the scheme has proven its ability to function as
a vehicle for different request methods.  Yes, the '+' character is
valid in a URI scheme.  So, why not gemini+HEAD://, gemini+POST://,
gemini+PUT://....  Moral of the story: everything is always extensible
if you try hard enough.  Corollary: Gopher has remained largely
unextended for so long for non-technical, presumably cultural reasons.
There may be great wisdom to be found in understanding why.

3. Dear God, when/where/how does it stop?!  This was supposed to be a
simple, humble, protocol of limited scope!  But...

4. ...I totally "get it", with the ability to edit Gemini resources from
within the client.  Compared to the current situation where publishing
in Geminispace requires using scp, (s)ftp, rsync, git or whatever, this
feature would make the protocol accessible to literally several orders
of magnitude more people.  The decision to let this happen or to crush
it in the name of simplicity and minimalism could have tremendous
consequences for the eventual destiny of Gemini.  It's exciting stuff,
and I don't want to exclude non-technical people from using what we've
built.  But...

5. ...I'm wary that facilitating "user friendly" Gemini hosts which
anybody can post to using a client carries a very real risk of fostering
a culture of dependency where people don't know how to do anything not
offered as a feature by their provider, who has the ability to change,
remove, or charge for those featurs, and also of pushing us toward a
more centralised Geminispace where large numbers of users congregate on
a small number of servers which make themselves especially appealing to
non-technical users.  These servers could easily become little
semi-closed gardens with internal-only comment notification facilities
and other such niceties which work much more smoothly than the various
decntralised solutions people have already been talking about.  They
might not, but the risk is there: we might just end up creating new
versions of LiveJournal, Wordpress, Blogspot, etc, etc.

6. Does anybody else feel like we are just instinctively re-implementing
the familiar history of the web without much caution or critical
thought?

7. It's of no practical use today, here and now, for "everyday users",
but I just want to get it on the record that in a hypothetical future
where IPv6 or something else has provided us all with abundant
publically reachable addresses, the obvious and elegant way for a
client to upload to a Gemini "server" is actually to just host the
resource itself, on a random, one-use-only URL, and then send that URL
as a query to a well-known uploading endpoint on the other end,
whereupon the "server" briefly becomes a client and fetches the resource
in the usual way.  Nothing extra needed in the protocol at all!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jun 13 21:59:48 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 13 Jun 2020 20:59:48 +0000
Subject: Draft spec changes for comments
In-Reply-To: <CANmFPektB2RtMG1D6Fxgd0gTx8oPm20-Rrhmj+MaBXpuqJWz0A@mail.gmail.com>
References: <20200613181552.GC18831@SDF.ORG>
 <CANmFPektB2RtMG1D6Fxgd0gTx8oPm20-Rrhmj+MaBXpuqJWz0A@mail.gmail.com>
Message-ID: <20200613205948.GE18831@SDF.ORG>

On Sat, Jun 13, 2020 at 11:06:34PM +0300, Hannu Hartikainen wrote:
> Looks good to me. I noticed there's a lone tab on row 322; maybe fix that
> too.

Got it, kiitos!

Cheers,
Solderpunk

From mbays at sdf.org  Sat Jun 13 22:04:31 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sat, 13 Jun 2020 23:04:31 +0200
Subject: Draft spec changes for comments
In-Reply-To: <20200613181552.GC18831@SDF.ORG>
References: <20200613181552.GC18831@SDF.ORG>
Message-ID: <20200613210431.rafqlistjqgluvyl@localhost>

* Saturday, 2020-06-13 at 18:15 +0000 - solderpunk <solderpunk at SDF.ORG>:

>* Add a minimal definition of alt text to the definition of preformatted
>  mode toggle lines, to address accessability and searchability
>  concerns, as well as to close, or at least ameliorate, the
>  extensibility loophole identified by Katarina Eriksson.

* gemini://gemini.circumlunar.space/docs/specification-modified.gmi
> Any text following the leading "```" of a preformat toggle line which 
> toggles preformatted mode off MUST be ignored by clients.

This seems to be (partially) closing the loophole at the opening of 
a preformatted block, but leaving the matching loophole at the end 
intact? If it's ignored by today's clients, it can be used by 
tomorrow's.

From sean at conman.org  Sat Jun 13 22:10:07 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 17:10:07 -0400
Subject: What is Gemini - a video by me
In-Reply-To: <6A760C43-A186-4F43-86FE-43A9F232E1B8@gmail.com>
References: <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
 <20200612094112.GA6497@SDF.ORG>
 <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
 <6A760C43-A186-4F43-86FE-43A9F232E1B8@gmail.com>
Message-ID: <20200613211006.GJ11281@brevard.conman.org>

It was thus said that the Great Terry Brennan once stated:
> FYI: The youtube video will not play on my Mac desktop. It crashes within 5 seconds of start.
> 
> I have never used toobnix, and I was unable to figure out how to start it.

  For what it's worth, I had no problems with playing either one on a Mac
desktop.  

  -spc


From sean at conman.org  Sat Jun 13 22:50:25 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 17:50:25 -0400
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
Message-ID: <20200613215024.GK11281@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> 
> 7. It's of no practical use today, here and now, for "everyday users",
> but I just want to get it on the record that in a hypothetical future
> where IPv6 or something else has provided us all with abundant
> publically reachable addresses, the obvious and elegant way for a
> client to upload to a Gemini "server" is actually to just host the
> resource itself, on a random, one-use-only URL, and then send that URL
> as a query to a well-known uploading endpoint on the other end,
> whereupon the "server" briefly becomes a client and fetches the resource
> in the usual way.  Nothing extra needed in the protocol at all!

  I'll respond to the rest in another email, but I want to say that this is
a *brilliant* idea and could be done today.  All it would require is
configuring people's routers to forward a port to the computer (gamers
usually have to do this anyway to play online games---thanks NAT! [1]).  I
may end up doing a "proof-of-concept" on this method.

  The only downside is that limit of 1024 characters in the URL, but I don't
think that will actually be that much of a concern.

  -spc

[1]	This destroyed the original peer-to-peer nature of the Internet. 
	Sigh.

From solderpunk at SDF.ORG  Sat Jun 13 23:07:34 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 13 Jun 2020 22:07:34 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613215024.GK11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org>
Message-ID: <20200613220734.GG18831@SDF.ORG>

On Sat, Jun 13, 2020 at 05:50:25PM -0400, Sean Conner wrote:
 
>   I'll respond to the rest in another email, but I want to say that this is
> a *brilliant* idea and could be done today. 

Thanks :)  I'm very pleased with it.

Cheers,
Solderpunk

From sean at conman.org  Sat Jun 13 23:11:04 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 18:11:04 -0400
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
Message-ID: <20200613221103.GL11281@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> A couple of thoughts on this new line of discussion:
> 
> 1. I am very grateful that people have made a point of defining this as
> separate "companion" protocol rather than asking for it as part of the
> core Gemini protocol, to give me a bit of breathing room.  I *do* like
> the idea of naming it titan://...

  Fair enough.  titan: it is.

> 2. At this point I can only laugh at the completeness with which using
> URIs as requests has backfired on me.  First the userinfo auto cookie
> debacle and now, hah, the scheme has proven its ability to function as
> a vehicle for different request methods.  Yes, the '+' character is
> valid in a URI scheme.  So, why not gemini+HEAD://, gemini+POST://,
> gemini+PUT://....  

  Yes, the more I thought about gemini+put:, gemini+del:, the less I liked
it.  And no, the extensibility did not escape me as I was working on this.

  Another way of looking at this is the lengths people will go to to solve
their problems using tools at hand, even if they may not be the best tools
to use to solve the issue.  See Raymond Chen's blog "The Old New Thing" [1]
where he describes some of the crazy things Windows programmers have done.

> Moral of the story: everything is always extensible if you try hard
> enough. Corollary: Gopher has remained largely unextended for so long for
> non-technical, presumably cultural reasons. There may be great wisdom to
> be found in understanding why.

  Gopher has its own URL scheme, which doesn't include:

	* userinfo
	* query string
	* fragments

  That hasn't stopped people from misusing it though (I've seen gopher URLs
with query strings even though that's not allowed).  I think the other
reason (besides cultural) is that it died *quickly* (for the most part) in
the mid-90s (when the UoM wanted to charge royalties for use of the protocol
when HTTP was free).  It limped along for *years* until maybe 2010 when
there was a newed interest, and it's not like people are refusing to use
UTF-8 or non-standard selector types because they're not allowed to ...

> 3. Dear God, when/where/how does it stop?!  This was supposed to be a
> simple, humble, protocol of limited scope!  But...
> 
> 4. ...I totally "get it", with the ability to edit Gemini resources from
> within the client.  Compared to the current situation where publishing
> in Geminispace requires using scp, (s)ftp, rsync, git or whatever, this
> feature would make the protocol accessible to literally several orders
> of magnitude more people.  The decision to let this happen or to crush
> it in the name of simplicity and minimalism could have tremendous
> consequences for the eventual destiny of Gemini.  It's exciting stuff,
> and I don't want to exclude non-technical people from using what we've
> built.  But...
> 
> 5. ...I'm wary that facilitating "user friendly" Gemini hosts which
> anybody can post to using a client carries a very real risk of fostering
> a culture of dependency where people don't know how to do anything not
> offered as a feature by their provider, who has the ability to change,
> remove, or charge for those featurs, and also of pushing us toward a
> more centralised Geminispace where large numbers of users congregate on
> a small number of servers which make themselves especially appealing to
> non-technical users.  These servers could easily become little
> semi-closed gardens with internal-only comment notification facilities
> and other such niceties which work much more smoothly than the various
> decntralised solutions people have already been talking about.  They
> might not, but the risk is there: we might just end up creating new
> versions of LiveJournal, Wordpress, Blogspot, etc, etc.

  As I said, HTTP has had all the features required to support "development
in the browser via HTTP only" since 1996, but as far as I know, no current
browser (or even old ones from the time) ever did this.  I know programs
like DreamWeaver [2] could upload documents to a server, but it did so over
FTP, not the web.

  Another aspect is that it wasn't apparent *how* to support methods like
PUT or DELETE in a general purpose web server, and it took several years for
Apache (for example) to even provide a way to do this---either via custom
Apache modules [3] or (eventually) through a CGI script.  In any case, it
required special configuration on the server side of things, and for mass
hosting ... you ain't gonna get that.  I can, but that's because I'm insane
enough to run my own web server (and email server, and gopher server, and
gemini server ... ).

> 6. Does anybody else feel like we are just instinctively re-implementing
> the familiar history of the web without much caution or critical
> thought?

  Believe me, I had actively surpress thoughts during the initial
development of Gemini to push for more web-like features.  And this proposal
woudn't even have come to light if it weren't for Alex Schroeder working on
this because he likes wikis so much (also, see my response for point 2).

> 7. It's of no practical use today, here and now, for "everyday users",
> but I just want to get it on the record that in a hypothetical future
> where IPv6 or something else has provided us all with abundant
> publically reachable addresses, the obvious and elegant way for a
> client to upload to a Gemini "server" is actually to just host the
> resource itself, on a random, one-use-only URL, and then send that URL
> as a query to a well-known uploading endpoint on the other end,
> whereupon the "server" briefly becomes a client and fetches the resource
> in the usual way.  Nothing extra needed in the protocol at all!

  I responsed to this in my previous email.

  -spc

[1]	https://devblogs.microsoft.com/oldnewthing/

[2]	An HTML editor from the mid to late 90s.

[3]	Not easy to do.  I did write an Apache module [4] twenty years ago
	and I find it easier to maintain a instance of Apache 1.3 to run it,
	than to try to adapt the code to Apache 2.4.  Maybe one of these
	days I'll get a round tuit.

[4]	https://github.com/spc476/mod_litbook

From sean at conman.org  Sat Jun 13 23:19:06 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 18:19:06 -0400
Subject: Uploading Gemini content
In-Reply-To: <dd25962d-2486-207a-9425-9427be4ac745@masterq32.de>
References: <20200613053926.GH11281@brevard.conman.org>
 <dd25962d-2486-207a-9425-9427be4ac745@masterq32.de>
Message-ID: <20200613221906.GM11281@brevard.conman.org>

It was thus said that the Great Felix Quei?ner once stated:
> Hey Sean and others!
> 
> > *snips the whole protocol description*
> 
> I was too working on a gemini extension to allow arbitrary data uploads
> as "10 INPUT" is a bit too restricted to ~700 byte of data payload.
> 
> But now that i read your gemini+put and gemini+delete extension, i think
> i don't need to continue braining over my extension and it's flaws.

  I'm curious as to what you were planning.  Care to share?

> I really like the proposal. It's easy to implement and integrate both on
> server and client side. The "gemini+delete" scheme is just the normal
> gemini handling routine and the upload routine can be put "in front" of a
> normal gemini request and can be handled with the normal response handler.

  I wouldn't be too sure about that.  My own "proof-of-concept" took about
five hours to write, and it's a separate server of its own.  I did that
because trying to integrate the new URL support would have been too invasive
of a change in GLV-1.12556.

  And while the protocol itself is easy, there were issues I had to be very
cautious about to ensure nothing bad happened when a delete was called for. 
For instance, I had to account for the deletion of a directory and
everything below it.  I also had to handle the creation of multiple
directories for the put method.

  -spc


From sean at conman.org  Sat Jun 13 23:53:03 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 18:53:03 -0400
Subject: [ANN] Egsam - A new client torture tester
In-Reply-To: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>
References: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>
Message-ID: <20200613225303.GN11281@brevard.conman.org>

It was thus said that the Great Peter Vernigorov once stated:
> Pronounced egg-sam :)
> 
> Building my client, I noticed that there were edge cases that I wanted
> to test but was not able to.

  You should have said something, I could have added most to my Gemini
Client Torture Test [1].

> Hopefully this is useful to others
> building clients as well. I broke up the spec into sections and tested
> each one individually. At the end you get a score!

  It's cool that there's very little overlap between our two test sets. 
It's not cool that I seem to have been a bit slack in coming up with tests. 
Sigh.

  I also like the organization scheme you came up with.

  -spc

[1]	gemini://gemini.conman.org/test/torture/

From felix at masterq32.de  Sun Jun 14 00:09:33 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 14 Jun 2020 01:09:33 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
Message-ID: <34e5e030-ce9b-82da-b72a-cde45de171e8@masterq32.de>


> 7. It's of no practical use today, here and now, for "everyday users",
> but I just want to get it on the record that in a hypothetical future
> where IPv6 or something else has provided us all with abundant
> publically reachable addresses, the obvious and elegant way for a
> client to upload to a Gemini "server" is actually to just host the
> resource itself, on a random, one-use-only URL, and then send that URL
> as a query to a well-known uploading endpoint on the other end,
> whereupon the "server" briefly becomes a client and fetches the resource
> in the usual way.  Nothing extra needed in the protocol at all!

As much as i like the idea, as much i see it fail in the current world
of ISPs.
Real world example:
I was developing the finger implementation for Kristall on the train,
using a mobile hotspot. I had neither the possibilty to use
finger://ping at cosmic.voyage from either my mobile phones hotspot as well
as the public wifi in the train, as the firewalls prevent pinging,
NATing and everything else.

Most "normal" people I know don't even have a computer anymore, owning
pretty much only tablets and mobile phones. If we want to get these guys
on the train as well as possible content creators, we need to provide an
easy way of uploading resources to gemini space via a client request,
not a reverse-server.

Afaik it also isn't possible from some mobile devices to activly use
most of the network features (like listing on sockets, using UDP on some
devices is completly disabled, ...)

IPv6 will probably not change this ever

And that's why i want to have some kind of company protocol or built-in
facility in Geminispace to get people on the train that are not tech
savvies.
I'm aware that we as the tech guys often forgot that most people on a
computer don't have any idea how those machines actually work and
requiring them to have a reverse-server for content uploads is just
impossible to explain and must be "hidden" in a client to be able to
probive them content changing options?

The question is now: Do we want to have those people on the train as
content creators or should gemini have a nice and easy way to have
content creators do their thing?

It's sad, but that's my view on reality
- xq

From felix at masterq32.de  Sun Jun 14 00:14:34 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 14 Jun 2020 01:14:34 +0200
Subject: [ANN] Egsam - A new client torture tester
In-Reply-To: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>
References: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>
Message-ID: <0e12c78f-0f13-95cd-2f6e-c247242a41a1@masterq32.de>

Heya!

> Building my client, I noticed that there were edge cases that I wanted
> to test but was not able to. Hopefully this is useful to others
> building clients as well. I broke up the spec into sections and tested
> each one individually. At the end you get a score!
> 
> gemini://egsam.pitr.ca/
> 
> Source code is at https://github.com/pitr/egsam - if there are any
> edge cases missing, please open an issue, or better yet a pull
> request/patch.
> 
> Cheers!
> 

Wonderful, thank you!

From hello at matthewgraybosch.com  Sun Jun 14 00:30:19 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 13 Jun 2020 19:30:19 -0400
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
Message-ID: <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>

On Sat, 13 Jun 2020 20:56:35 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> I *do* like the idea of naming it titan://...

Thanks. I honestly just couldn't resist.

> 5. ...I'm wary that facilitating "user friendly" Gemini hosts which
> anybody can post to using a client carries a very real risk of
> fostering a culture of dependency where people don't know how to do
> anything not offered as a feature by their provider, who has the
> ability to change, remove, or charge for those featurs, and also of
> pushing us toward a more centralised Geminispace where large numbers
> of users congregate on a small number of servers which make
> themselves especially appealing to non-technical users.

> 6. Does anybody else feel like we are just instinctively
> re-implementing the familiar history of the web without much caution
> or critical thought?

That's been nagging at me as well. TBH, I'm not actually comfortable
with the seeming necessity of public hosts like tanelorn.city to get
people creating and publishing gemini content. I'm not used to asking
people to trust me like this, and I'm not comfortable with the power I
have over people using tanelorn.city.

Let's be honest; it shouldn't be that hard to run a gemini daemon out
of a personal computer in your own home, whether it's your main desktop
or just a raspberry pi. The protocol is light enough that CPU and
memory usage should be next to nothing compared to Firefox or Chrome. 

It probably wouldn't be that hard for a compentent Windows or OSX
developer to create a graphical app suitable for people who aren't
sysadmins that published an arbitrary directory and starts up again
whenever their PC or Mac reboots. The nature of the protocol all but
guarantees that.

I think the biggest problem, at least in the US, is that ISPs seem
hellbent on keeping residential internet users from using their
connections for anything but consumption. You've got to use a dynamic
DNS service like no-ip.com, and even if you manage that you might still
find yourself getting cut off over a TOS violation. People are
thoroughly conditioned toward using the internet as glorified cable TV,
and only expressing themselves on platforms they don't control.

Then there's DNS, domain names, ICAAN, etc. Maybe if we still used a
UUCP-style addressing scheme like
<country>.<province>.<city>.<neighborhood>.<hostname> it wouldn't
matter what I called my host as long as the hostname was unique to the
<neighborhood>. But instead we settled on <domain-name>.<tld>, which
needs to be administered by registrars to ensure uniqueness, and domain
registration is yet more sysadmin stuff that most people don't
necessarily have the time, skill, or inclination to deal with.

I would prefer that public hosts weren't necessary. I think that
everybody who wants to should be able to publish from their own device
without having to become a sysadmin. As long as operating a gemini
service remains the province of sysadmins, we're going to maintain the
division between haves (sysadmins) and have nots (people who can't or
don't want to sysadmin) that prevented the web from becoming (or
remaining) a democratic platform.

This became something of a political rant, and I probably should have
put it on demifiend.org instead. Sorry if this doesn't belong here; I'm
posting this under a new subject so that it starts a new thread instead
of derailing the existing one.

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

From petite.abeille at gmail.com  Sun Jun 14 01:33:52 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 14 Jun 2020 02:33:52 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613220734.GG18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG> <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
Message-ID: <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>



> On Jun 14, 2020, at 00:07, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>>  I'll respond to the rest in another email, but I want to say that this is
>> a *brilliant* idea and could be done today. 
> 
> Thanks :)  I'm very pleased with it.

A bit like the 'Mode Switching' in NNTP of yore. 

Such mode switch -where client and server trade places- would be a very nice use of the protocol capabilities. Very cool idea. Like it.

Eddie Murphy would be proud [1].

If only NAT traversal was a solved problem though. Sigh. Where is my overlay network when I need it.

Meanwhile, perhaps a simple 'patch' command would do.

For example, to turn specification.gmi into specification-modified.gmi, one could issue a patch command transforming the former into the latter:

gemini://gemini.circumlunar.space/docs/specification.gmi?data:text/x-patch...

Unfortunately, the 1024 bytes limit doesn't get  us very far. The diff itself is ~14K. ~5K compressed. Too big for one request.

Fossil delta format [2] is much more compact than diff -u, but still weights ~4K, 2K compressed. And this is not accounting for data: encoding overhead.

So, hmmm, 1024 bytes is quite a limiting factor if one must use only one request.

Perhaps this could be worked around using a sequence of requests, ala chunked transfer encoding [3]:

gemini://gemini.circumlunar.space/docs/specification.gmi?data:... chunk1
gemini://gemini.circumlunar.space/docs/specification.gmi?data:... chunk2
gemini://gemini.circumlunar.space/docs/specification.gmi?data:... chunk3

The server would then reassemble the various parts and apply the delta.

A bit clunky, but workable :D

[1] https://en.wikipedia.org/wiki/Trading_Places
[2] https://www.fossil-scm.org/xfer/doc/trunk/www/delta_format.wiki 
[3] https://en.wikipedia.org/wiki/Chunked_transfer_encoding


P.S. FWIW, attached is the fossil delta between specification.gmi and specification-modified.gmi

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: specification.delta.txt
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200614/26e687af/attachment.txt>
-------------- next part --------------




From petite.abeille at gmail.com  Sun Jun 14 01:49:36 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 14 Jun 2020 02:49:36 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
Message-ID: <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>



> On Jun 13, 2020, at 22:56, solderpunk <solderpunk at SDF.ORG> wrote:
> 
>  Nothing extra needed in the protocol at all!

Considering the various network topology hurdles along the way, perhaps the gemini protocol itself could facilitate such a role reversal by offering a way to initiate such switch.  

From sean at conman.org  Sun Jun 14 02:22:15 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 21:22:15 -0400
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
Message-ID: <20200614012215.GO11281@brevard.conman.org>

It was thus said that the Great Matthew Graybosch once stated:
> 
> Let's be honest; it shouldn't be that hard to run a gemini daemon out
> of a personal computer in your own home, whether it's your main desktop
> or just a raspberry pi. The protocol is light enough that CPU and
> memory usage should be next to nothing compared to Firefox or Chrome. 

 ... 

> I think the biggest problem, at least in the US, is that ISPs seem
> hellbent on keeping residential internet users from using their
> connections for anything but consumption. 

  As someone who has worked for various ISPs and webhosting companies for
most of my career, I think this slamming of IPSs is unwaranted.  And as
someone who runs both a public server *and* a few services on my home
network [1] there are some things you need to consider.

1. Open servers are *attacked* at an alarming rate. At home, I run an sshd
instance tha is open to the Internet [2].  I am currently blocking 2,520
hosts that have attempted to log in via ssh.  That count is only over the
past 30 days (technically, 30 days, 10 hours, 30 minutes, as that's the
average month length over the year).  Not doing so means my machine will be
constantly under login attempts.

  99% of all traffic to my webserver (on my actual public server) is
automated programs, not actual humans.  Most are just webbots spidering my
content, some are script kiddies looking for an exploit and some are just
incompetently written programs that just blow my mind [3].  There's the
wierd network traffic that just sucks up connections requests [4].  And then
there's the *wierd* (and quite stressful) situations involving black-hat
hackers [5].

  Then there's the issues with running UDP based services [6].  It's not
pretty on the open Internet.

2. If people could run a business server on their home connection, they
would.  Then they'll bitch and moan about the service being slow, or can't
the ISP do something about the DDoS attack they're under?  Even if they
aren't and their service is just popular.  Or why their connection dropped? 
Never mind the power is out, why did my server loose connection?

  Or in self defense, the ISP cuts the connection because the home server is
running a port scanner, participating in a botnet, or sending out spam
emails because of an unpatched exploit in some server being run at home.

3. Do people realize they'll need to basically firewall off their Windows
boxes?  Seriously, the level of exploits on Windows is (was?) staggering and
the number of services (like file sharing) it runs by default (because
that's what the users want) it runs is *not* condusive to allowing a Windows
box full access to the Internet.  The same can be said for Mac and Linux,
but to a slightly lesser degree.

4. It was email that poisoned home-run servers intially.  Spam increased
dramatically during the late 90s/early 2000s to the point where it because a
Byzantine nightmare to configure and run an email server due to SPF, DMARC
and DKIM, along with greylisting and filtering of attachments.  Oh, and as a
self-defense mechanism, nearly every ISP around the world will block
incoming/outgoing TCP port 25 to home users.

> You've got to use a dynamic
> DNS service like no-ip.com, and even if you manage that you might still
> find yourself getting cut off over a TOS violation. People are
> thoroughly conditioned toward using the internet as glorified cable TV,
> and only expressing themselves on platforms they don't control.

  That is true too, but I suspect even *if* you could easily run a server at
home, 99% would not even bother (or know what it is).

> Then there's DNS, domain names, ICAAN, etc. Maybe if we still used a
> UUCP-style addressing scheme like
> <country>.<province>.<city>.<neighborhood>.<hostname> it wouldn't
> matter what I called my host as long as the hostname was unique to the
> <neighborhood>. But instead we settled on <domain-name>.<tld>, which
> needs to be administered by registrars to ensure uniqueness, and domain
> registration is yet more sysadmin stuff that most people don't
> necessarily have the time, skill, or inclination to deal with.

  There are groups working on alternative naming/routing schemes that don't
require a global namespace.  It's not an easy problem.

  Also, at one time, domains under the .us domain were restricted to
geographical names, like example.boca-raton.fl.us.  But they were free to
register, and as far as I can tell, permanent.  The issue though, is that
even under the <city>,<state>.us, you still need unique names, although it's
a smaller area to worry about.

  I don't think you can do that anymore.  I went down that rabbit hole
several months ago looking to register a geographical domain under .us and
couldn't do it (or find out who controls the domains under
boca-raton.fl.us).  Pitty, I was hoping to get a free domain registration
for life.

> I would prefer that public hosts weren't necessary. I think that
> everybody who wants to should be able to publish from their own device
> without having to become a sysadmin. As long as operating a gemini
> service remains the province of sysadmins, we're going to maintain the
> division between haves (sysadmins) and have nots (people who can't or
> don't want to sysadmin) that prevented the web from becoming (or
> remaining) a democratic platform.

  Never underestimate the lack of giving a damn the general population have. 
I'm sure there are aspects of your life that you lack a damn about that
other people think you should give more than a damn.

> This became something of a political rant, and I probably should have
> put it on demifiend.org instead. Sorry if this doesn't belong here; I'm
> posting this under a new subject so that it starts a new thread instead
> of derailing the existing one.

  I think it's a conversation worth having, as it relates to how Gemini
expands with new content.

  -spc

[1]	Disclaimer: I do pay extra for a static IPv4 address---at the time I
	needed it for my job, and now it's a "nice to have" and I can still
	afford it.  It's actually not that much over the stock price of
	service.

[2]	My router will forward ssh traffic to my main development system.

[3]	http://boston.conman.org/2019/07/09-12
	http://boston.conman.org/2019/08/06.2

[4]	http://boston.conman.org/2020/04/05.1

[5]	http://boston.conman.org/2004/09/19.1

[6]	http://boston.conman.org/2019/05/13.1

From petite.abeille at gmail.com  Sun Jun 14 02:40:50 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 14 Jun 2020 03:40:50 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
Message-ID: <2D2AA9C7-1D11-43A5-BCB0-DCF15C5D3CC5@gmail.com>



> On Jun 14, 2020, at 02:49, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Considering the various network topology hurdles along the way, perhaps the gemini protocol itself could facilitate such a role reversal by offering a way to initiate such switch.  

Perhaps this could be all done with just 1x (INPUT), between consenting pairs:

C: gemini://.../specification.gmi??gemini://.../delta.txt --notify the server of the location of the delta and to switch role to get it, as indicated by the ? sigil
C?S: <start role reversal> -- the client maintain the network connection and accepts one gemini request
S: gemini://.../delta.txt -- the server request the content from the client 
C: 20 text/x-patch; length=4106 -- the client return the data to the server
C?S: <end role reversal> -- upon EOF
S: 30 gemini://.../specification.gmi -- client redirected to updated resource

This would require a persistent connection though. And some sort of indications of content EOF, be it length or otherwise.



From jmcbray at carcosa.net  Sun Jun 14 03:06:39 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Sat, 13 Jun 2020 22:06:39 -0400
Subject: Germinal v0.2.0 update
Message-ID: <875zbuo0y8.fsf@dorothy.carcosa.net>

Germinal update!

I would like to announce the release of version 0.2 of my Common Lisp
Gemini server, Germinal[1]. In this release:

* Support for configuration by command-line or TOML config file.
* Many, many bug fixes, many of which are thanks to Tobias Rautenkranz

The most important of these bug fixes is a fix to a path-traversal bug,
that could have allowed carefully constructed requests to read
world-readable files from outside your Germinal document root. (There
was code to catch path traversals before, but it was wrong, and only
caught simple cases). If you are running Germinal, you are *highly*
recommended to upgrade because of this bug. Also, write to me[2]; there
can't be more than a couple people running this, and until Tobias
started submitting pull requests, I thought I was the only one. 

=> /germinal/  [1] Germinal home page on Gemini.
=> mailto:jmcbray+germinal at carcosa.net    [2] Email me.

The source is hosted on my own gittea instance[3], and I'm happy to
accept patches either there, or by email (format with git-format-patch
and/or git-send-email).

=> https://git.carcosa.net/jmcbray/germinal/       [3] Germinal gitea

If you are a smug Lisp weenie, please be gentle. I'm a Lisp newbie
whomst is trying to learn things by writing this.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From sean at conman.org  Sun Jun 14 03:11:59 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 22:11:59 -0400
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
Message-ID: <20200614021159.GP11281@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Jun 13, 2020, at 22:56, solderpunk <solderpunk at SDF.ORG> wrote:
> > 
> >  Nothing extra needed in the protocol at all!
> 
> Considering the various network topology hurdles along the way, perhaps
> the gemini protocol itself could facilitate such a role reversal by
> offering a way to initiate such switch.

  Such a thing would require a new response code block, like 70 (for
UPLOAD---INPUT is inadiquate for this).  Basic servers can then ignore this
block like they can ignore client certificates.  It would also require
knowing of the upload link, but I think that can be solved using
pre-existing measures (link titles, well-known links, etc.).

  Here's a simple proposal:

C: gemini://example.com/post-endpoint CRLF
S: 70 Proceed with upload CRLF
C: - 1234 text/plain; charset=us-ascii CRLF
C: data ...
S: 2x / 3x / 4x / 5x CRLF

C: gemini://example.com/put-endpoint CRLF
S: 71 Proceed with new resource CRLF
C: gemini://example.com/path/to/new/resource 1234 text/plain; charset=us-ascii CRLF
C: data ...
S: 31 gemini://example.com/path/to/new/resource CRLF

  For the seond method, a size of 0 means to delete the resource.  I made
the client response the same way to both to simplify the implementation. 
There is a semantic difference between a generic UPLOAD and the replacement
of an existing resource on the server, thus the two codes.

  A case could be made of making the size and mime type query parameters to
the endpoint---that would allow the server to check the proposed type and
sizes and reject before the upload starts.  In that case, I would propose
this:

C: gemini://example.com/post-endpoint?size=1234&mime=text/plain;charset=us-ascii CRLF
S: 70 Proceed with upload CRLF
C: data ...
S: 2x / 3x / 4x / 5x CRLF

C: gemini://example.com/put-endpoint?size=1234&mime=text/plain;charset=us-ascii CRLF
S: 71 Proceed with new resource CRLF
C: gemini://example.com/path/to/new/resource CRLF
C: data ...
S: 31 gemini://example.com/path/to/new/resource CRLF

  Depending upon the CGI implementation, this could even be handled via CGI
rather than the server.

  -spc
  

From sean at conman.org  Sun Jun 14 03:21:52 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 22:21:52 -0400
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <2D2AA9C7-1D11-43A5-BCB0-DCF15C5D3CC5@gmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
 <2D2AA9C7-1D11-43A5-BCB0-DCF15C5D3CC5@gmail.com>
Message-ID: <20200614022152.GQ11281@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Jun 14, 2020, at 02:49, Petite Abeille <petite.abeille at gmail.com> wrote:
> > 
> > Considering the various network topology hurdles along the way, perhaps
> > the gemini protocol itself could facilitate such a role reversal by
> > offering a way to initiate such switch.
> 
> Perhaps this could be all done with just 1x (INPUT), between consenting
> pairs:
> 
> C: gemini://.../specification.gmi??gemini://.../delta.txt --notify the server of the location of the delta and to switch role to get it, as indicated by the ? sigil
> C?S: <start role reversal> -- the client maintain the network connection and accepts one gemini request
> S: gemini://.../delta.txt -- the server request the content from the client 
> C: 20 text/x-patch; length=4106 -- the client return the data to the server
> C?S: <end role reversal> -- upon EOF
> S: 30 gemini://.../specification.gmi -- client redirected to updated resource
> 
> This would require a persistent connection though. And some sort of
> indications of content EOF, be it length or otherwise.

  You know, another (maybe silly) way:

C: inimeg://example.com/specification.gmi CRLF
   <starts role reversal---the connection is maintained and the server sends the request>
S: gemini://example.com/specification.gmi CRLF
C: <data>
C: 20 text/gemini CRLF
   <end role reversal>
S: 31 gemini://example.com/spcification.gmi CRLF

  This doesn't solve the uploading of just data though.

  -spc 


From petite.abeille at gmail.com  Sun Jun 14 03:39:15 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 14 Jun 2020 04:39:15 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200614022152.GQ11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
 <2D2AA9C7-1D11-43A5-BCB0-DCF15C5D3CC5@gmail.com>
 <20200614022152.GQ11281@brevard.conman.org>
Message-ID: <EE6CC7B1-DFDD-4ACC-858F-BD081AF2044C@gmail.com>



> On Jun 14, 2020, at 04:21, Sean Conner <sean at conman.org> wrote:
> 
>  You know, another (maybe silly) way:
> 
> C: inimeg://example.com/specification.gmi CRLF
>   <starts role reversal---the connection is maintained and the server sends the request>
> S: gemini://example.com/specification.gmi CRLF
> C: <data>
> C: 20 text/gemini CRLF
>   <end role reversal>
> S: 31 gemini://example.com/spcification.gmi CRLF

inimeg! Like! :)

>  This doesn't solve the uploading of just data though.

Why not? Just inimeg to a new URL.

So, to create a resource is the same as updating a resource.

C: inimeg://path/to/resource/role_reversal.gmi
?
S: gemini://path/to/resource/role_reversal.gmi
C: 20 text/gemini;length=123
?
S: 31 gemini://path/to/resource/role_reversal.gmi




From hello at matthewgraybosch.com  Sun Jun 14 03:40:24 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 13 Jun 2020 22:40:24 -0400
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200614012215.GO11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
Message-ID: <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>

On Sat, 13 Jun 2020 21:22:15 -0400
Sean Conner <sean at conman.org> wrote:

> As someone who has worked for various ISPs and webhosting companies
> for most of my career, I think this slamming of IPSs is unwaranted.

You're probably right.

> 1. Open servers are *attacked* at an alarming rate. At home, I run an
> sshd instance tha is open to the Internet [2].  I am currently
> blocking 2,520 hosts that have attempted to log in via ssh.  That
> count is only over the past 30 days (technically, 30 days, 10 hours,
> 30 minutes, as that's the average month length over the year).  Not
> doing so means my machine will be constantly under login attempts.

I'm finding this out the hard way. Fortunately I thought to disable
root logins in /etc/ssh/sshd_config when I first set up my VPS, but I'm
also reading up on fail2ban. Thinking of using this HOWTO since it
emphasizes not tampering with distributed config files.

https://phrye.com/tools/fail2ban-on-freebsd/

> And then there's the *wierd* (and quite stressful) situations
> involving black-hat hackers [5].

You know what? I think I recognize your email because I've read about
your experience with the black-hat.

I'm reading this email and thinking, "Dear creeping gods, what have I
gotten myself into?"

> 2. If people could run a business server on their home connection,
> they would. ... Never mind the power is out, why did my
> server loose connection?

I've been this clueless. Fortunate my phone wasn't working so I
couldn't inflict it on some poor tech support worker.

>   Or in self defense, the ISP cuts the connection because the home
> server is running a port scanner, participating in a botnet, or
> sending out spam emails because of an unpatched exploit in some
> server being run at home.


You're right, this is legit.
 
> 3. Do people realize they'll need to basically firewall off their
> Windows boxes?

I firewalled the hell out of my wife's Windows machine just to block
the damn telemetry. It's insane.

> 4. It was email that poisoned home-run servers intially.

I remember this now. I know there was a reason I was reluctant to even
try setting up external email on tanelorn.city. I thought I was just
being irrational.

> That is true too, but I suspect even *if* you could easily run a
> server at home, 99% would not even bother (or know what it is).

Fair point.
 
> Never underestimate the lack of giving a damn the general
> population have. I'm sure there are aspects of your life that you
> lack a damn about that other people think you should give more than a
> damn.

You're right. It's just that I see barriers and had forgotten that some
of the barriers exist for a reason.

> I think it's a conversation worth having, as it relates to how
> Gemini expands with new content.

Thanks for taking the time to reply. There's a lot here that I either
didn't know or had forgotten.

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

From lazar.michael22 at gmail.com  Sun Jun 14 03:50:16 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sat, 13 Jun 2020 22:50:16 -0400
Subject: Draft spec changes for comments
In-Reply-To: <20200613181552.GC18831@SDF.ORG>
References: <20200613181552.GC18831@SDF.ORG>
Message-ID: <CAFTy05biH4GNx72u4Dx6oq0ULaewXPNxO9_wowUgAxL3KTE+LA@mail.gmail.com>

On Sat, Jun 13, 2020 at 2:16 PM solderpunk <solderpunk at sdf.org> wrote:
>
> Hey folks,
>
> At gemini://gemini.circumlunar.space/docs/specification-modified.gmi you
> will find a modified version of the current spec.  If you download it,
> along with the current spec from
> gemini://gemini.circumlunar.space/docs/specification.gmi, you can `diff`
> them to see the changes.  These changes are a tentative version of those
> I want to make before making a new official update and then, at last,
> freezing the spec again.  I'm making them available now so people can
> point out oversights or suggest improvements.

Nice work! I appreciate all of the effort that you are putting into making the
spec more clear and readable.

A few comments:

> 5.4.2 Link lines
>
> =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>

I am confused that the <CR><LF> is explicitly called out here and not for any
of the other line types. It makes me think if my client sees a link without the
<CR> in it, I should treat it like a text line instead of a link. There is also
an edge case where the last line of a text/gemini contains a link, but doesn't
have a newline at all. I suggest removing the newline from the link definition
all together since line breaking behavior is already defined elsewhere.

=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]

> 61 CERTIFICATE NOT AUTHORISED
>
> The supplied client certificate is not authorised for accessing the
particular requested resource.  The problem is not with the certificate itself,
which may be authorised for other rsources.

Spelling error, "rsources"

> 62 CERTIFICATE NOT VALID
>
> The supplied client certificate was not accepted because either its validity
start date is in the future or its expiry date has passed.  This indicates a
problem with the certificate in and of itself, with no consideration of the
particular requested resource.

This wording implies that the validity/expiration date are the ONLY two errors
that should ever trigger this error code. There are probably other certificate
errors that should fall into this category like corrupt certificates or invalid
self-signatures.

Astrobotany returns a 6x error message if you attempt to sign-in using a TLS
certificate that does not contain a subject CN field. What error should that
return with the new spec, 61 or 62?

Best,
Michael

From petite.abeille at gmail.com  Sun Jun 14 03:51:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 14 Jun 2020 04:51:19 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <EE6CC7B1-DFDD-4ACC-858F-BD081AF2044C@gmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
 <2D2AA9C7-1D11-43A5-BCB0-DCF15C5D3CC5@gmail.com>
 <20200614022152.GQ11281@brevard.conman.org>
 <EE6CC7B1-DFDD-4ACC-858F-BD081AF2044C@gmail.com>
Message-ID: <833C4C18-E03D-4FFE-BE00-4388549EC650@gmail.com>



> On Jun 14, 2020, at 04:39, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> 
> 
>> On Jun 14, 2020, at 04:21, Sean Conner <sean at conman.org> wrote:
>> 
>> You know, another (maybe silly) way:
>> 
>> C: inimeg://example.com/specification.gmi CRLF
>>  <starts role reversal---the connection is maintained and the server sends the request>
>> S: gemini://example.com/specification.gmi CRLF
>> C: <data>
>> C: 20 text/gemini CRLF
>>  <end role reversal>
>> S: 31 gemini://example.com/spcification.gmi CRLF
> 
> inimeg! Like! :)
> 
>> This doesn't solve the uploading of just data though.
> 
> Why not? Just inimeg to a new URL.
> 
> So, to create a resource is the same as updating a resource.
> 
> C: inimeg://path/to/resource/role_reversal.gmi
> ?
> S: gemini://path/to/resource/role_reversal.gmi
> C: 20 text/gemini;length=123
> ?
> S: 31 gemini://path/to/resource/role_reversal.gmi
> 

To delete something:

C: inimeg://path/to/resource/role_reversal.gmi
?
S: gemini://path/to/resource/role_reversal.gmi
C: 20 dev/null
?
S: 31 gemini://.../thanks


From petite.abeille at gmail.com  Sun Jun 14 03:59:41 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 14 Jun 2020 04:59:41 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <833C4C18-E03D-4FFE-BE00-4388549EC650@gmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
 <2D2AA9C7-1D11-43A5-BCB0-DCF15C5D3CC5@gmail.com>
 <20200614022152.GQ11281@brevard.conman.org>
 <EE6CC7B1-DFDD-4ACC-858F-BD081AF2044C@gmail.com>
 <833C4C18-E03D-4FFE-BE00-4388549EC650@gmail.com>
Message-ID: <B35D017D-D17A-4898-8012-41389D6E8D08@gmail.com>



> On Jun 14, 2020, at 04:51, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> To delete something:

Actually:

C: inimeg://path/to/resource/role_reversal.gmi
?
S: gemini://path/to/resource/role_reversal.gmi
C: 52 GONE
?
S: 31 gemini://.../thanks


From fkfd at macaw.me  Sun Jun 14 04:07:18 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Sun, 14 Jun 2020 03:07:18 +0000
Subject: [ANN] Git front-end for Gemini
Message-ID: <5AFCB6D0-6D11-4E69-9DA9-DEE4A8FA7A44@macaw.me>

Hi all! After eight hours of struggle yesterday, I finally made an MVP for Git.gmi, a CGI script that serves as a git frontend like cgit and git.sr.ht. It currently supports viewing repo index, summary, tree, textual blob, and commit log. Unlike gemgit it is not a static site generator, but a real, dynamic application.

Here is a demo page:
=> gemini://fkfd.me/git/cgi/

It *may* work (or it may not); if you encounter status code 42, this could be the server or browser messing up relative links. Try fiddling with the URL in the address bar, like checking for missing/extra slashes.

Repo (which you can also view on the demo above, of course):
=> https://git.sr.ht/~fkfd/git.gmi

~fkfd

From sean at conman.org  Sun Jun 14 04:11:19 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 13 Jun 2020 23:11:19 -0400
Subject: Uploading Gemini content
In-Reply-To: <20200613053926.GH11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
Message-ID: <20200614031119.GR11281@brevard.conman.org>


  To begin with, I'm going with the titan: scheme, to ensure that this isn't
mixed up with the gemini: scheme itself.

  This proposal is mostly based upon a new URL scheme, and I've spent the
day diving deep into RFC-7595 (URI Scheme Guidelines June 2015, current
standard).  First, the good news---gemini fits the spec for a "Permanent
Status" with the IETF.  Next, these bits from the RFC:

Section 1:

	The URI syntax provides a federated and extensible naming system,
	where each scheme's specification can further restrict the syntax
	and define the semantics of identifiers using that scheme.

Section 3.4:

	Note: It is perfectly valid to say that "no operation apart from GET
	is defined for this URI."

  Both are quite good for the current definition of the gemini: scheme. 

  It's some other bits from section 3.4 that bodes somewhat well for the
current proposal (with a new scheme) under consideration:

	It is also valid to say that "there's only one operation defined for
	this URI, and it's not very GET-like." The important point is that
	what is defined on this scheme is described ... The default
	invocation, or dereferencing, of a URI SHOULD be "safe" in the sense
	described by Section 3.4 of [W3CWebArch]; i.e., performing such an
	invocation should not incur any additional obligations by doing so.

[W3CWebArch]	https://www.w3.org/TR/webarch/#safe-interaction

  So doing a non-GET method based on a scheme is okay.  That's the one thing
I was worried about, as I looked over all the currently registered schemes
[1] appear to *only* specify a location, not an action and a location.  So
the following are "okay" (ish) per the spec:

	titan+put:
	titan+post:
	titan+del:

  Further more, from RFC-6335 (Service Name and Port Number Procedures
August 2011), section 5:

	There may be more than one service name associated with a particular
	transport protocol and port.  There are three ways that such port
	number overloading can occur:

	o  Overloading occurs when one service is an extension of another
	   service, and an in-band mechanism exists for determining if the
	   extension is present or not.

  So I'm still "okay" (ish) with the new URL schemes.  

  I rejected the following URL:

	titan://put at example.com/path/to/new/item

  While it's cute, and syntatically correct, semantically it's quite a
stretch---it's not a "user", it's a "command", which doesn't semantically
follow as a user nor a location.  It's too much of an abuse for my liking.

  Semantically, I would probably treat these three new schemes differently. 
The first, titan+post: (or titan-post: which is easier to type) would be:

	titan+post://example.com/post-handler/endpoint?size=1234&mime=text/plain

  The size and MIME types are part of the query string, as the data being
uploaded is *NOT* a replacement of a resource on the server, must data for a
service to consume, so semantically, it makes sense as a query string.

	titan+put://example.com/path/to/new/resource;size=1234&mime=text/plain

  Here request is being replaced---there's no "endpoint" per se to receive
the data, so query data doesn't make semantic sense.  The size and MIME type
are inherent properties of the resource being uploaded, so by using the ';'
as a sub-delimeter in the path, it semantically relates to the resource. 
That semantic relationship doesn't exist with a query string.

	tital+del://example.com/path/to/remove

  Nothing more to say, other than the resource is removed.

  Upon reflection, given the semantic meanings involved, I can cut the
number of new schemes down to just one: "titan:".  Here are the three
examples again:

	titan://example.com/post-handler/endpoint?size=1234&mime=text/plain
	titan://example.com/path/to/new/resource;size=1234&mime=text/plain
	titan://example.com/path/to/remove;size=0

  The logic goes something like this [2]:

	if the request has a query, it's an upload of data---accept data.
	if the request has no query, and the path parameter (marked by ';')
		doesn't exist---error.
	if the request has no query, and the path parameter exists:
		if size==0, delete the resource
		if size>0, accept data and make the resource available.

  So that's my current thinking (other than having a way of Gemini to
reverse the flow).

  -spc

[1]	https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

[2]	Assuming proper authorization and data checks are made.

From petite.abeille at gmail.com  Sun Jun 14 04:27:25 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 14 Jun 2020 05:27:25 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <B35D017D-D17A-4898-8012-41389D6E8D08@gmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <48C74CCE-A8AB-4E9F-BA9E-E7016253C88A@gmail.com>
 <2D2AA9C7-1D11-43A5-BCB0-DCF15C5D3CC5@gmail.com>
 <20200614022152.GQ11281@brevard.conman.org>
 <EE6CC7B1-DFDD-4ACC-858F-BD081AF2044C@gmail.com>
 <833C4C18-E03D-4FFE-BE00-4388549EC650@gmail.com>
 <B35D017D-D17A-4898-8012-41389D6E8D08@gmail.com>
Message-ID: <66E07554-9961-4B03-85ED-C034639BCDFE@gmail.com>



> On Jun 14, 2020, at 04:59, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
>> To delete something:
> 
> Actually:
> 
> C: inimeg://path/to/resource/role_reversal.gmi
> ?
> S: gemini://path/to/resource/role_reversal.gmi
> C: 52 GONE
> ?
> S: 31 gemini://.../thanks

To move something:

C: inimeg://.../old.gmi
?
S: gemini://.../old.gmi
C: 31 gemini://.../new.gmi
?
S: 31 gemini://.../new.gmi

Of course, the server could also respond with 59 BAD REQUEST, or whatever is appropriate, if it doesn't like the client commands.






From me at case.codes  Sun Jun 14 04:50:59 2020
From: me at case.codes (case)
Date: Sat, 13 Jun 2020 21:50:59 -0600
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
Message-ID: <C69630A9-5C97-4DFE-AFC5-542D101D542A@case.codes>



On June 13, 2020 2:56:35 PM MDT, solderpunk <solderpunk at SDF.ORG> wrote:
>A couple of thoughts on this new line of discussion:
>

>3. Dear God, when/where/how does it stop?!  This was supposed to be a
>simple, humble, protocol of limited scope!

To me, this is key and exactly where the web went off the rails. If this is embraced by the community it becomes a defacto standard; clients that do not support it will be considered less. This is what happened to mosaic and Netscape.

>
>6. Does anybody else feel like we are just instinctively
>re-implementing
>the familiar history of the web without much caution or critical
>thought?

Yes!


Why does this have to be a part of or associated with gemini at all? Why not build a separate protocol and client and build a community of authors around it?

In my mind gemini is a passive reader's tool. It gets all of the noise out of the way, advertising, comments, likes, social media distractions, incentives to grow audiences etc...

How about a protocol extension that says user input MUST NOT be persisted by servers?

Cheers,
Case


-- Email domain proudly hosted at https://migadu.com


From lel at envs.net  Sun Jun 14 07:11:01 2020
From: lel at envs.net (lel)
Date: Sun, 14 Jun 2020 02:11:01 -0400
Subject: [ANN] Git front-end for Gemini
In-Reply-To: <5AFCB6D0-6D11-4E69-9DA9-DEE4A8FA7A44@macaw.me>
References: <5AFCB6D0-6D11-4E69-9DA9-DEE4A8FA7A44@macaw.me>
Message-ID: <20200614061101.GA691999@spektr>

It looks like the page at gemini://fkfd.me/git/cgi sends a bad header line. The server responds with a header of `20 SUCCESS text/gemini`, which means a status code of 20 (which means success), and a mime type of "SUCCESS text/gemini", which isn't a valid mime type, and isn't recognized as one by any client I know of. Looking in gemini://fkfd.me/git/const.py, it seems you define all of your status codes this way. Just replying with `20' is the behavior required for a client to know what to do with your response.

Having changed that, I haven't been able to get anything other than 42 statuses on your demo or a server of my own, but I'm sure there's some way to fix it, like you mention in your announcement. This could still be beyond way cool tho, given that gemini requires the web to proliferate itself rn, outside of just hosting tarballs or whatever.

Best,
~lel

From fkfd at macaw.me  Sun Jun 14 10:07:01 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Sun, 14 Jun 2020 17:07:01 +0800
Subject: [ANN] Git front-end for Gemini
In-Reply-To: <20200614061101.GA691999@spektr>
References: <5AFCB6D0-6D11-4E69-9DA9-DEE4A8FA7A44@macaw.me>
 <20200614061101.GA691999@spektr>
Message-ID: <e4dca7dc-1e4f-0630-74f1-efe96a8ead50@macaw.me>

On 6/14/20 2:11 PM, lel wrote:
> It looks like the page at gemini://fkfd.me/git/cgi sends a bad header line. 

Just FYI, jetforce doesn't inform git.gmi of the existence of a slash at
the end of a CGI PATH_INFO, so `/git/cgi` and `/git/cgi/` are requests
for the same page; but the relative links differ in behavior: `=> tree/`
links to `/git/tree/` and `/git/cgi/tree/`, respectively.

> The server responds with a header of `20 SUCCESS text/gemini`, which means a status code of 20 (which means success), and a mime type of "SUCCESS text/gemini", which isn't a valid mime type, and isn't recognized as one by any client I know of. Looking in gemini://fkfd.me/git/const.py, it seems you define all of your status codes this way. Just replying with `20' is the behavior required for a client to know what to do with your response.

Oh! I totally let slip of that. My testing client doesn't care about
mimetypes; it just renders in text/gemini whatsoever. It should be
correct in the next commit.

> Having changed that, I haven't been able to get anything other than 42 statuses on your demo or a server of my own, but I'm sure there's some way to fix it, like you mention in your announcement. This could still be beyond way cool tho, given that gemini requires the web to proliferate itself rn, outside of just hosting tarballs or whatever.

I haven't written up the Usage part yet in the documentation. You need
to change a few hardwired lines like the shebang in the CGI entry
executable, `cgi`, as well as other configs in `const.py`. I'll get
around to it.

~fkfd

From cage-dev at twistfold.it  Sun Jun 14 10:07:31 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 14 Jun 2020 11:07:31 +0200
Subject: [SPECS text/gemini] Heading lines proposal
Message-ID: <20200614090731.GA3639@kurosawa.casa.net>

Hi!

When studying the documentation about  the text format (and reading the
mailing list messages) i started  to think that the same argumentation
that lead to adding  a space after the list item  marker (the '*') are
valid to the heading marker as well.

For example if i starts a line mentioning an IRC channel like that:

#channel [...]

this would be presented  to the user as an header of  level 1 which is
not.

The same would be true if i mention a tag for a social network.

As for the  list item i think would  be a good idea to add  a space to
the header mark: so from "#" to  "#<space>" and so on for header level
2 and 3.

Not really sure if this is correct, though so i am looking forward for
your comments.

Bye!
C.

From solderpunk at SDF.ORG  Sun Jun 14 10:46:30 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 09:46:30 +0000
Subject: Germinal v0.2.0 update
In-Reply-To: <875zbuo0y8.fsf@dorothy.carcosa.net>
References: <875zbuo0y8.fsf@dorothy.carcosa.net>
Message-ID: <20200614094630.GA363@SDF.ORG>

On Sat, Jun 13, 2020 at 10:06:39PM -0400, Jason McBrayer wrote:
 
> The most important of these bug fixes is a fix to a path-traversal bug,
> that could have allowed carefully constructed requests to read
> world-readable files from outside your Germinal document root. (There
> was code to catch path traversals before, but it was wrong, and only
> caught simple cases).

Path-traversal bugs are scary!  Is it worth sharing the details of this
so that other server authors can check for analogous bugs in their
servers?  Or was it highly specific to your programming language or
server design? 

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jun 14 10:48:10 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 09:48:10 +0000
Subject: [ANN] Egsam - A new client torture tester
In-Reply-To: <20200613225303.GN11281@brevard.conman.org>
References: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>
 <20200613225303.GN11281@brevard.conman.org>
Message-ID: <20200614094810.GB363@SDF.ORG>

On Sat, Jun 13, 2020 at 06:53:03PM -0400, Sean Conner wrote:

> It's not cool that I seem to have been a bit slack in coming up with tests. 
> Sigh.

You have been anything but slack in expanding and maintaining your
torture tests, which have been and remain a very valuable resource.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jun 14 11:01:07 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 10:01:07 +0000
Subject: Draft spec changes for comments
In-Reply-To: <CAFTy05biH4GNx72u4Dx6oq0ULaewXPNxO9_wowUgAxL3KTE+LA@mail.gmail.com>
References: <20200613181552.GC18831@SDF.ORG>
 <CAFTy05biH4GNx72u4Dx6oq0ULaewXPNxO9_wowUgAxL3KTE+LA@mail.gmail.com>
Message-ID: <20200614100107.GC363@SDF.ORG>

On Sat, Jun 13, 2020 at 10:50:16PM -0400, Michael Lazar wrote:

Thanks a lot for the feedback!
 
> > 5.4.2 Link lines
> >
> > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>
> 
> I am confused that the <CR><LF> is explicitly called out here and not for any
> of the other line types. It makes me think if my client sees a link without the
> <CR> in it, I should treat it like a text line instead of a link. There is also
> an edge case where the last line of a text/gemini contains a link, but doesn't
> have a newline at all. I suggest removing the newline from the link definition
> all together since line breaking behavior is already defined elsewhere.
> 
> =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]

Good catch, this makes perfect sense.  This probably should have been
spotted and changed at the same time as clarifying CR/LF requirements.

> > 61 CERTIFICATE NOT AUTHORISED
> >
> > The supplied client certificate is not authorised for accessing the
> particular requested resource.  The problem is not with the certificate itself,
> which may be authorised for other rsources.
> 
> Spelling error, "rsources"

Fixed, thanks!

> > 62 CERTIFICATE NOT VALID
> >
> > The supplied client certificate was not accepted because either its validity
> start date is in the future or its expiry date has passed.  This indicates a
> problem with the certificate in and of itself, with no consideration of the
> particular requested resource.
> 
> This wording implies that the validity/expiration date are the ONLY two errors
> that should ever trigger this error code. There are probably other certificate
> errors that should fall into this category like corrupt certificates or invalid
> self-signatures.

Yep, very true, I will fix this.

> Astrobotany returns a 6x error message if you attempt to sign-in using a TLS
> certificate that does not contain a subject CN field. What error should that
> return with the new spec, 61 or 62?

Hmm.  The subject field itself is actually allowed to be empty, I think.
So strictly speaking such a certificate is not "invalid" in any absolute
sense.  Sice a non-empty subject CN is a requirement of Astrobotany, I
guess 61 is the correct code.  The CN requirement should be made clear
in the META.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jun 14 11:16:20 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 10:16:20 +0000
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <20200614090731.GA3639@kurosawa.casa.net>
References: <20200614090731.GA3639@kurosawa.casa.net>
Message-ID: <20200614101620.GD363@SDF.ORG>

On Sun, Jun 14, 2020 at 11:07:31AM +0200, cage wrote:

> For example if i starts a line mentioning an IRC channel like that:
> 
> #channel [...]
> 
> this would be presented  to the user as an header of  level 1 which is
> not.
> 
> The same would be true if i mention a tag for a social network.

I guess this is just as good an argument as the *emphasised* words
clashing with list items thing.  AFAIK it hasn't been spotted in the
wild yet, but that's probably just a function of Geminispace being young
and small.

> As for the  list item i think would  be a good idea to add  a space to
> the header mark: so from "#" to  "#<space>" and so on for header level
> 2 and 3.

This would be covered by Petite Abeille's proposal to just put a
mandatory space after *all* the special line indicators.

Is it silly that I'm sad this would require (on account of
### sub-sub-headings) changing "It is possible to unambiguously
determine a line's type purely by inspecting its first three characters"
to "first four characters"?  It is silly.  But three just feels like a
much more *natural* choice of entirely arbitrary small number...

Cheers,
Solderpunk

From martin at no.ucant.org  Sun Jun 14 13:30:59 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sun, 14 Jun 2020 13:30:59 +0100 (BST)
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <C69630A9-5C97-4DFE-AFC5-542D101D542A@case.codes>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <C69630A9-5C97-4DFE-AFC5-542D101D542A@case.codes>
Message-ID: <alpine.DEB.2.20.2006141317490.18317@pling.qwghlm.org>

On Sat, 13 Jun 2020, case wrote:

> On June 13, 2020 2:56:35 PM MDT, solderpunk <solderpunk at SDF.ORG> wrote:

>> 3. Dear God, when/where/how does it stop?!  This was supposed to be a
>> simple, humble, protocol of limited scope!
>
> To me, this is key and exactly where the web went off the rails. If this 
> is embraced by the community it becomes a defacto standard; clients that 
> do not support it will be considered less. This is what happened to 
> mosaic and Netscape.

> Why does this have to be a part of or associated with gemini at all? Why 
> not build a separate protocol and client and build a community of 
> authors around it?

I think an upload protocol should *not* be developed. We should instead 
concentrate on creating the *content* that should be uploaded, and 
improving the *existing* tools for getting content onto servers.

Until I started using Gemini, I had avoided learning how to use TRAMP in 
Emacs - it is a system which allows you to edit remote files, so you open 
up /ssh:gemini.ucant.org:public_gemini/index.gemini in the editor, and it 
does SFTP to gemini.ucant.org and edits public_gemini/index.gemini for you 
transparently. It knows about ftp and a bunch of other protocols. 
Similarly, there are all sorts of user-space filesystems out there 
nowadays, such as sshfs, and good old git post-receive hooks and NFS 
automounts. The situation on Windows is apparently even better.
So my conventional "rsync this directory to the right spot on the server" 
script is basically redundant.

I'd say, Keep Gemini Simple, and improve the documentation and tooling for 
*existing* systems of "how do I update this file on the server". I'd also 
caution that WebDAV never took off, and this looks like GeminiDAV. And 
finally I'd caution that making things easier for the those who are not 
"technically savvy" should almost never be at the cost of indirectly
making it harder for those who are.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From cage-dev at twistfold.it  Sun Jun 14 14:59:56 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 14 Jun 2020 15:59:56 +0200
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <20200614101620.GD363@SDF.ORG>
References: <20200614090731.GA3639@kurosawa.casa.net>
 <20200614101620.GD363@SDF.ORG>
Message-ID: <20200614135956.GA8766@kurosawa.casa.net>

On Sun, Jun 14, 2020 at 10:16:20AM +0000, solderpunk wrote:

Hi solderpunk!

> On Sun, Jun 14, 2020 at 11:07:31AM +0200, cage wrote:

> > For example if i starts a line mentioning an IRC channel like that:
> >
> > #channel [...]
> >
> > this would be presented  to the user as an header of  level 1 which is
> > not.
> >
> > The same would be true if i mention a tag for a social network.
>
> I guess this is just as good an argument as the *emphasised* words
> clashing with list items thing.  AFAIK it hasn't been spotted in the
> wild yet, but that's probably just a function of Geminispace being young
> and small.

yes, and probably even less likely to occurs than the emphasis.

> > As for the  list item i think would  be a good idea to add  a space to
> > the header mark: so from "#" to  "#<space>" and so on for header level
> > 2 and 3.
>
> This would be covered by Petite Abeille's proposal to just put a
> mandatory space after *all* the special line indicators.
>
> Is it silly that I'm sad this would require (on account of
> ### sub-sub-headings) changing "It is possible to unambiguously
> determine a line's type purely by inspecting its first three characters"
> to "first four characters"?  It is silly.  But three just feels like a
> much more *natural* choice of entirely arbitrary small number...

:) Well i think i can sort of understand, if i would need to choose to
change  the  sentence  above  to  "It  is  possible  to  unambiguously
determine  a  line's  type  purely  by  inspecting  its  first  *four*
characters", and  remove the  sentence for  inexplicable (even  to me)
reason i would choose the second! ;-D

Anyway, i am starting writing a parser, it is refreshing (for my mind)
the fact that the syntax is so simple and still effective! :)

Bye!
C.

From solderpunk at SDF.ORG  Sun Jun 14 15:26:15 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 14:26:15 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <34e5e030-ce9b-82da-b72a-cde45de171e8@masterq32.de>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <34e5e030-ce9b-82da-b72a-cde45de171e8@masterq32.de>
Message-ID: <20200614142615.GE363@SDF.ORG>

On Sun, Jun 14, 2020 at 01:09:33AM +0200, Felix Quei?ner wrote:
 
> Most "normal" people I know don't even have a computer anymore, owning
> pretty much only tablets and mobile phones.

This is something that I know, abstractly, to be true, but my brain kind
of self-censors it out of my everyday thinking because, sheesh, what a
terrifying prospect to contemplate!

I genuinely don't mean to pass judgement on those people, because I
don't doubt that it makes a lot of sense for them to do that, based on
what they want to use computers and the internet for.  At the same time,
choosing to have only those devices does pretty much mean willfully
opting out of producing meaningful written content - the kind of thing
that Gemini is specifically designed to distribute.  There is a
reason that email clients for those platforms often automatically insert
signatures saying "Written in X on a Y, please excuse Z".  Writing text
on them is *such* a miserable experience that it causes people to
produce text falling so far below societal expectations of what's
appropriate for written communication that an apology is called for.
That's not hyperbole, it's literal truth!  Let that sink in.  I don't
think it makes sense to try to make it easy to publish content to Gemini
using that kind of device.  It's straight up the wrong tool for the job.

Lowering the barriers to entry for people who aren't familiar with ssh
and unix file permissions is good and appropriate, but I don't think
requiring a "real computer" is *inappropriate*.  This may rule a lot of
people out as potential content producers, but frankly they've ruled
*themselves* out.  I don't see this as exclusionary or discriminatory:
A secondhand laptop that's 10 years old or more is *absolutely* capable
of writing text/gemini content (I am writing this email on the same 9
year old surplus Thinkpad that I've used to author all my Gemini content
*and* software, and I bet there is already somebody on this list using
something older and less powerful) and is far cheaper than any
smartphone or tablet.  Heck, a big part of the appeal of Geminispace for
me is the knowledge that I can use "ancient" hardware and turn the CPU
scaling down to the lowest setting to save battery life and it will
remain perfectly usable, and even if I run multiple clients at once the
fan will never, ever spin up!  What a dream...anyway, my point is cheap,
old laptops in danger of ending up as landfill are not only more capable
tools for writing Gemini content than iPhones and iPads, by virtue of
having actual text input peripherals, they are also accessible to and
inclusive of a wider range of potential content producers.  So let's not
go out of our way to accommodate crippled devices.

The discussion around making publishing content in Geminispace easier
for people who aren't technogeeks is well worth having and I don't want
to stiffle it.  But we should keep it grounded and not let ourselves get
carried away with dreams of massive mainstream adoption and thinking
about what the proverbial "man in the street" needs to start publishing
content.  We are talking about a system designed specifically for
distributing relatively long-form writing without any bells or whistles. 
Most people simply aren't going to be interested in that no matter how
easy it is.  People who are really excited about it because they're fed
up with the web may be so enthusiastic that they are willing to invest a
little bit of time in learning how to publish, and we definitely should
not waste that opportunity!  If anybody has been wanting to contribute
valuable content to Geminispace but has been lacking in ideas,
accessible explanations of how to use tools like sftp, written for a
broad audience, would definitely not be a bad thing to have...

Finally, we have kind of conflated two separate concerns here.  One is
how to make publishing content to Geminispace easier for people for whom
setting up a VPS or joining a pubnix and scping up files is well beyond
their knowledge and experience.  The other is how to make
collaboratively edited things like wikis possible - the two problems are
related, but not identical, and may have different viable solutions.

Cheers,
Solderpunk

From fkfd at macaw.me  Sun Jun 14 15:37:41 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Sun, 14 Jun 2020 22:37:41 +0800
Subject: [ANN] Git front-end for Gemini
In-Reply-To: <20200614061101.GA691999@spektr>
References: <5AFCB6D0-6D11-4E69-9DA9-DEE4A8FA7A44@macaw.me>
 <20200614061101.GA691999@spektr>
Message-ID: <fca40da4-2a12-4087-3ace-5a91bce44540@macaw.me>

Most things should be fixed now. Things won't break as long as one
clicks the "canonical" links as provided by the server, and does not
tamper with the trailing slash.

=> gemini://fkfd.me/git/cgi/ Take a look?

I'm, shamelessly, also self-advertising and asking for someone to list
git.gmi in gemini.circumlunar.space/software/ .

~fkfd

From tcb913 at gmail.com  Sun Jun 14 15:58:55 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Sun, 14 Jun 2020 10:58:55 -0400
Subject: What is Gemini - a video by me
In-Reply-To: <20200613211006.GJ11281@brevard.conman.org>
References: <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
 <20200612094112.GA6497@SDF.ORG>
 <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
 <6A760C43-A186-4F43-86FE-43A9F232E1B8@gmail.com>
 <20200613211006.GJ11281@brevard.conman.org>
Message-ID: <86c77e2b-2060-e769-ad6f-1c3119ad3f22@gmail.com>

Apologies if I came across as arrogant. I was just reporting what 
(looked like) a problem.

BTW, is there a user's guide or FAQ for toobnix?

Terry Brennan


On 06/13/2020 05:10 PM, Sean Conner wrote:
> It was thus said that the Great Terry Brennan once stated:
>> FYI: The youtube video will not play on my Mac desktop. It crashes within 5 seconds of start.
>>
>> I have never used toobnix, and I was unable to figure out how to start it.
>    For what it's worth, I had no problems with playing either one on a Mac
> desktop.
>
>    -spc
>


From solderpunk at SDF.ORG  Sun Jun 14 16:05:47 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 15:05:47 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
Message-ID: <20200614150547.GF363@SDF.ORG>

On Sun, Jun 14, 2020 at 02:33:52AM +0200, Petite Abeille wrote:
> 
> Unfortunately, the 1024 bytes limit doesn't get  us very far. The diff itself is ~14K. ~5K compressed. Too big for one request.
> 
> Fossil delta format [2] is much more compact than diff -u, but still weights ~4K, 2K compressed. And this is not accounting for data: encoding overhead.
> 
> So, hmmm, 1024 bytes is quite a limiting factor if one must use only one request.

Well, look - 1024 bytes as a maximum URL length is a value I more or
less plucked out of the air without deep consideration, simply because
the elements passed around by a protocol *should* have a well-defined
maximum length so people can allocate appropriately sized memory
buffers, etc.  I certainly *wasn't* thinking about using queries to
upload content, I was thinking of "ordinary URLs" and so 1024 bytes
seemed hugely generous.

I believe most web browsers have a larger maximum URL length.  I did
look into this briefly for some reason - IIRC, Internet Explorer has/had
the smallest limit, and it was either 2048 or 4096 bytes.

According to GUS, currently more than half of the text/gemini content
out there is less than 1.2 KiB in size.  If URLs were allowed to be 2048
bytes long, all that content could be uploaded as a query.

I do not have hard numbers on this (Alex may be able to provide them),
but I would *imagine* that most edits to wikis, when expressed as diffs,
would also be much less than 1 KiB.

Can we solve a lot of these issues by bumping up our maximum URL length
and, perhaps, defining a new 1x status code meaning "I'm asking you for
some input and in this context it's quite reasonable that you might want
to submit something on the long side", which clients could optionally
respond to by launching a text editor instead of just reading a single
line of input?  Clients which chose to support this code would become
the preferred clients of wiki enthusiasts or people who don't want to or
don't know how to use scp etc.

Heck, wiki nerds could write their own clients which can launch an
editor pointed at a local copy of the resource being viewed, then
calculate a diff in some format and submit *that* as a query, and the
wiki software the server runs could apply the diff.  The special wiki
editing clients could even do your suggested chunked transfer thing for
very large diffs, if the wiki servers all implemented a standard API for
such a thing.

It should also be very easy to write an app targetted at "non-technical"
authors which lets them submit chunks of writing up to 2 KiB or so, with
an "append" link at the submission confirmation page to submit a follow
up chunk.  It wouldn't necessarily be the smoothest experience in the
world, but if most content could be written in a single request and 99%
with one or two "append" requests, I think it would be usable enough.
Heck, this is the "slow internet", right?  A little bit of inconvenience
as part of a careful and deliberate process should not scare us away.

In general, solving perceived problems with the limitations that Gemini
imposes by combining the "primitives" which are already there in
creative new ways, even if they are very slightly clunky, makes me far,
far happier than adding in additional more advanced features to remove
those limitations.  If we discover really useful and generally
applicable constructions that can be built in this way, we can give them
names, standardise them, and clients can choose to impelement them in
ways which hide the clunkiness from the user.  It would be wonderful,
though, if they were still usable in a clunky way by a knowledgable
users in clients which didn't support them explicitly.

In short, think like FORTH. :)

> A bit clunky, but workable :D

Maybe we should adopt this as an official motto? :p

Cheers,
Solderpunk

From tomasino at lavabit.com  Sun Jun 14 16:06:40 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 14 Jun 2020 15:06:40 +0000
Subject: What is Gemini - a video by me
In-Reply-To: <86c77e2b-2060-e769-ad6f-1c3119ad3f22@gmail.com>
References: <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
 <CpndzSPMCBaob8wl6Al-py5yA0IAz1VrIeW5ZG7d97LNlYzWbCzf1bzCKM2HvT_4L7VWIH_0wEWSZ9WyiI9IMB6-MN8mXXtS6LtVk4EBHXk=@protonmail.com>
 <20200612094112.GA6497@SDF.ORG>
 <f5ad82f7-dc20-fa0e-4fa1-72c00625a856@lavabit.com>
 <6A760C43-A186-4F43-86FE-43A9F232E1B8@gmail.com>
 <20200613211006.GJ11281@brevard.conman.org>
 <86c77e2b-2060-e769-ad6f-1c3119ad3f22@gmail.com>
Message-ID: <f45639a2-ec01-7ac4-e4f0-374bed6de5d9@lavabit.com>

On 6/14/20 2:58 PM, Terry Brennan wrote:
> BTW, is there a user's guide or FAQ for toobnix?

Toobnix is just a peertube instance managed by SDF. You can learn more about the platform here: https://joinpeertube.org/


From solderpunk at SDF.ORG  Sun Jun 14 17:52:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 16:52:44 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200614150547.GF363@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG>
Message-ID: <20200614165244.GG363@SDF.ORG>

On Sun, Jun 14, 2020 at 03:05:47PM +0000, solderpunk wrote:

Regarding:

> Heck, wiki nerds could write their own clients which can launch an
> editor pointed at a local copy of the resource being viewed, then
> calculate a diff in some format and submit *that* as a query, and the
> wiki software the server runs could apply the diff.

and:
 
> It should also be very easy to write an app targetted at "non-technical"
> authors which lets them submit chunks of writing up to 2 KiB or so, with
> an "append" link at the submission confirmation page to submit a follow
> up chunk.  It wouldn't necessarily be the smoothest experience in the
> world, but if most content could be written in a single request and 99%
> with one or two "append" requests, I think it would be usable enough.

I realise this works a heck of a lot better for textual content than
base64-encoded binary content, where uploading, say, a JPG photograph
would require many, many chunks.  I think I'm okay with this.  Gemini is
deliberately and unapologetically a text-first protocol.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jun 14 18:11:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 14 Jun 2020 17:11:33 +0000
Subject: [ANN] Git front-end for Gemini
In-Reply-To: <fca40da4-2a12-4087-3ace-5a91bce44540@macaw.me>
References: <5AFCB6D0-6D11-4E69-9DA9-DEE4A8FA7A44@macaw.me>
 <20200614061101.GA691999@spektr>
 <fca40da4-2a12-4087-3ace-5a91bce44540@macaw.me>
Message-ID: <20200614171133.GH363@SDF.ORG>

On Sun, Jun 14, 2020 at 10:37:41PM +0800, Frederick Yin wrote:
 
> I'm, shamelessly, also self-advertising and asking for someone to list
> git.gmi in gemini.circumlunar.space/software/ .

Done!

Cheers,
Solderpunk

From colecmac at protonmail.com  Sun Jun 14 19:13:09 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 14 Jun 2020 18:13:09 +0000
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>
Message-ID: <ynIhaxwCK90fqhpv9FN-s8sv32gErns3Rq8053ri0jLiqRHiQRrHKAnEa3widBxm-GlWwlsIM1Go8Mt0UN_iiHlKqUavQaWRC15tQWETXMM=@protonmail.com>

> I'm finding this out the hard way. Fortunately I thought to disable
> root logins in /etc/ssh/sshd_config when I first set up my VPS, but I'm
> also reading up on fail2ban. Thinking of using this HOWTO since it
> emphasizes not tampering with distributed config files.

If you haven't already, it's a MUST to setup an SSH key and turn off password
login. This will basically remove all SSH based attacks.

https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/

makeworld

??????? Original Message ???????
On Saturday, June 13, 2020 10:40 PM, Matthew Graybosch <hello at matthewgraybosch.com> wrote:

> On Sat, 13 Jun 2020 21:22:15 -0400
> Sean Conner sean at conman.org wrote:
>
> > As someone who has worked for various ISPs and webhosting companies
> > for most of my career, I think this slamming of IPSs is unwaranted.
>
> You're probably right.
>
> > 1.  Open servers are attacked at an alarming rate. At home, I run an
> >     sshd instance tha is open to the Internet [2]. I am currently
> >     blocking 2,520 hosts that have attempted to log in via ssh. That
> >     count is only over the past 30 days (technically, 30 days, 10 hours,
> >     30 minutes, as that's the average month length over the year). Not
> >     doing so means my machine will be constantly under login attempts.
> >
>
> I'm finding this out the hard way. Fortunately I thought to disable
> root logins in /etc/ssh/sshd_config when I first set up my VPS, but I'm
> also reading up on fail2ban. Thinking of using this HOWTO since it
> emphasizes not tampering with distributed config files.
>
> https://phrye.com/tools/fail2ban-on-freebsd/
>
> > And then there's the wierd (and quite stressful) situations
> > involving black-hat hackers [5].
>
> You know what? I think I recognize your email because I've read about
> your experience with the black-hat.
>
> I'm reading this email and thinking, "Dear creeping gods, what have I
> gotten myself into?"
>
> > 2.  If people could run a business server on their home connection,
> >     they would. ... Never mind the power is out, why did my
> >     server loose connection?
> >
>
> I've been this clueless. Fortunate my phone wasn't working so I
> couldn't inflict it on some poor tech support worker.
>
> > Or in self defense, the ISP cuts the connection because the home
> > server is running a port scanner, participating in a botnet, or
> > sending out spam emails because of an unpatched exploit in some
> > server being run at home.
>
> You're right, this is legit.
>
> > 3.  Do people realize they'll need to basically firewall off their
> >     Windows boxes?
> >
>
> I firewalled the hell out of my wife's Windows machine just to block
> the damn telemetry. It's insane.
>
> > 4.  It was email that poisoned home-run servers intially.
>
> I remember this now. I know there was a reason I was reluctant to even
> try setting up external email on tanelorn.city. I thought I was just
> being irrational.
>
> > That is true too, but I suspect even if you could easily run a
> > server at home, 99% would not even bother (or know what it is).
>
> Fair point.
>
> > Never underestimate the lack of giving a damn the general
> > population have. I'm sure there are aspects of your life that you
> > lack a damn about that other people think you should give more than a
> > damn.
>
> You're right. It's just that I see barriers and had forgotten that some
> of the barriers exist for a reason.
>
> > I think it's a conversation worth having, as it relates to how
> > Gemini expands with new content.
>
> Thanks for taking the time to reply. There's a lot here that I either
> didn't know or had forgotten.
>
> ------------------------------------------------------------------------------------------------------
>
> 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."



From jzs at sketchground.dk  Sun Jun 14 20:24:05 2020
From: jzs at sketchground.dk (jzs)
Date: Sun, 14 Jun 2020 19:24:05 +0000
Subject: [SPEC-CHANGE] lang parameter, minor line type changes,
 clarifications...
In-Reply-To: <C3BVYJGCCRL6.OJWQ70A7TLE4@freebsd.lan>
References: <C3BVYJGCCRL6.OJWQ70A7TLE4@freebsd.lan>
Message-ID: <eHP8VKYrzO5dKdSh3n3hvqga_C4SpQl8qdx74_DawDaXsYZGD3LnARpn9GlgwMyAez36bB3uMvSZq4FZzHrkWW3fmZiImEwSy974HjUERG8=@sketchground.dk>

> Multi-user sites will be trickiest of all and will require users to
> either bother the admin, or for servers to implement something like
> Apache's .htaccess files.
> Something like .htaccess could work. This morning I was also thinking of it being in the file name. Then it could be on a per file basis like "index.fr.gmi" would be sent as "index.gmi" with "lang=fr" in the response header.
int 80h

One could also let the server interpret gmi files and strip the first x lines in each file. You could use pandoc title block, multimarkdown metadata or yaml front matter. That way you can also insert date etc to automatically generate for example atom feeds. Of cause these "file headers" will be stripped before sending the file to the client.
Its really up to the server on how to deal with it.

/Jens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200614/5c1391c0/attachment.htm>

From j3s at c3f.net  Sun Jun 14 21:34:08 2020
From: j3s at c3f.net (jes)
Date: Sun, 14 Jun 2020 15:34:08 -0500
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>
Message-ID: <61b3ed4c-1601-8c93-83f8-00280f4a44c7@c3f.net>

On 6/13/20 9:40 PM, Matthew Graybosch wrote:
> On Sat, 13 Jun 2020 21:22:15 -0400
> I'm finding this out the hard way. Fortunately I thought to disable
> root logins in /etc/ssh/sshd_config when I first set up my VPS, but I'm
> also reading up on fail2ban. Thinking of using this HOWTO since it
> emphasizes not tampering with distributed config files.
> 
> https://phrye.com/tools/fail2ban-on-freebsd/

Hi!

You might also consider that there are a number of drawbacks regarding 
fail2ban, here's the article that I've written on the subject:

https://j3s.sh/thoughts/fail2ban-sucks.txt

From luke at marmaladefoo.com  Sun Jun 14 21:54:12 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 14 Jun 2020 21:54:12 +0100
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200614142615.GE363@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <34e5e030-ce9b-82da-b72a-cde45de171e8@masterq32.de>
 <20200614142615.GE363@SDF.ORG>
Message-ID: <5EE68E74.3040107@marmaladefoo.com>



On 14-Jun-2020 15:26, solderpunk wrote:
>
> Lowering the barriers to entry for people who aren't familiar with ssh
> and unix file permissions is good and appropriate, but I don't think
> requiring a "real computer" is *inappropriate*.  This may rule a lot of
> people out as potential content producers, but frankly they've ruled
> *themselves* out.  I don't see this as exclusionary or discriminatory:
> A secondhand laptop that's 10 years old or more is *absolutely* capable
> of writing text/gemini content (I am writing this email on the same 9
> year old surplus Thinkpad that I've used to author all my Gemini content
> *and* software, and I bet there is already somebody on this list using
> something older and less powerful) and is far cheaper than any
> smartphone or tablet.  Heck, a big part of the appeal of Geminispace for
> me is the knowledge that I can use "ancient" hardware and turn the CPU
> scaling down to the lowest setting to save battery life and it will
> remain perfectly usable, and even if I run multiple clients at once the
> fan will never, ever spin up!  What a dream...anyway, my point is cheap,
> old laptops in danger of ending up as landfill are not only more capable
> tools for writing Gemini content than iPhones and iPads, by virtue of
> having actual text input peripherals, they are also accessible to and
> inclusive of a wider range of potential content producers.  So let's not
> go out of our way to accommodate crippled devices.
This is quite a harsh perspective IMO - in the developing world there 
are many people who can only afford to access the internet via a phone. 
Whilst we might not build specifically for phone users, the light weight 
nature of Gemini does make it a potential vehicle to be used for many 
more people than we may imagine.

Perhaps in this phase of the definition of Gemini, we should think of a 
potential user as our "significant others". Perhaps users who have an 
inclination to write and share their thoughts outside of the highly 
commercialised mainstream web. But certainly not an assumption they know 
what ssh, sftp or running your own linux server.

What would these users need to assist them?

Best Wishes

  - Luke

From defdefred at protonmail.com  Sun Jun 14 21:57:57 2020
From: defdefred at protonmail.com (defdefred)
Date: Sun, 14 Jun 2020 20:57:57 +0000
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200614012215.GO11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
Message-ID: <gp6Ja5zK2ZCDtNROdt5Q5-iIkv1IxnMmsJGLHf-TBcoHuNv4-gUdpBfsyzwTHL5VdbVjF8M72CgCFgvxqpL4BMNaesfvNP_FnPNWCJlaC60=@protonmail.com>

On Sunday, June 14, 2020 3:22 AM, Sean Conner <sean at conman.org> wrote:
> [3] http://boston.conman.org/2019/07/09-12
> http://boston.conman.org/2019/08/06.2

Should we deduce that a significative part of the internet traffic is fake request?
That a shame concidering the environmental impact of the digital world.
Maybe blocking all this non-human request is the solution?

From luke at marmaladefoo.com  Sun Jun 14 22:06:11 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 14 Jun 2020 22:06:11 +0100
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200614150547.GF363@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG> <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG>
Message-ID: <5EE69143.503@marmaladefoo.com>



On 14-Jun-2020 16:05, solderpunk wrote:
> According to GUS, currently more than half of the text/gemini content
> out there is less than 1.2 KiB in size.  If URLs were allowed to be 2048
> bytes long, all that content could be uploaded as a query.
>
> I do not have hard numbers on this (Alex may be able to provide them),
> but I would *imagine* that most edits to wikis, when expressed as diffs,
> would also be much less than 1 KiB.
>
> Can we solve a lot of these issues by bumping up our maximum URL length
> and, perhaps, defining a new 1x status code meaning "I'm asking you for
> some input and in this context it's quite reasonable that you might want
> to submit something on the long side", which clients could optionally
> respond to by launching a text editor instead of just reading a single
> line of input?  Clients which chose to support this code would become
> the preferred clients of wiki enthusiasts or people who don't want to or
> don't know how to use scp etc.
>
> It should also be very easy to write an app targetted at "non-technical"
> authors which lets them submit chunks of writing up to 2 KiB or so, with
> an "append" link at the submission confirmation page to submit a follow
> up chunk.  It wouldn't necessarily be the smoothest experience in the
> world, but if most content could be written in a single request and 99%
> with one or two "append" requests, I think it would be usable enough.
> Heck, this is the "slow internet", right?  A little bit of inconvenience
> as part of a careful and deliberate process should not scare us away.

I think this is a great idea! It would go quite a long way to supporting 
collaborative editing. And as you say it is infrastructure we already have.

if your lines are about 25 characters long, 2kb is about 80 lines worth 
of text. That seems a nice sweet spot to me.

We could argue if you need more than that you will be better placed to 
find a more flexible upload option.

The only other part to the jigsaw in my view is a way to integrate the 
editing experience into the client so you can *round-trip* the content. 
As we know the first edit is seldom a perfect one.

The basic wiki concept has the following:

1. Page displays content (we can do that)
2. Edit mode of the existing page content
3. Upload (2k allowed - OK)
4. Review submitted content (return to 1)

For step 2, we want the user to be able to edit the existing content, 
not necessarily compose completely afresh.

One suggestion is that clients MAY present an integrated editor bound to 
a preformatted region on a page (perhaps the first one or a user 
selected one). This allows the re-editing of the existing content. This 
is then what is submitted when writing back via the submission.

This would cover the full lifecycle of simple yet basic wiki editing.

Best Wishes

  - Luke

From colecmac at protonmail.com  Mon Jun 15 00:09:05 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 14 Jun 2020 23:09:05 +0000
Subject: Thoughts on TOFU
In-Reply-To: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
Message-ID: <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>

So I've realized that this will break a lot of workflows, I think.

Many sites on Gemini-space just use their Let's Encrypt cert for their
site, but the Let's Encrypt tool, certbot, sets a new private key when
renewing[1]. As far as I can tell, this is standard practice (certbot or no),
and so I don't think that storing only the public key for TOFU is a good idea.

1: https://github.com/certbot/certbot/issues/231

However, this doesn't solve the issue Felix presented:

> This means that trust in a server is lost as soon as a certificate is
> expired and a subsequent renewal of the certificate with the same
> private key is the same as visiting the host for the first time. But
> when i refresh my server certificate before it expires (which is
> recommended), we will have the situation that the client will not trust
> the server anymore (same situation as when an attacker is doing a MITM
> attack) which i think is not a good situation.

I'm not sure what to do about this. Both options seem bad, and both will cause
breakage. It seems that there is no good way to do TOFU with certs, unless
you want to try and control how servers use certs, like specifying that keypairs
should not change or something.

Solderpunk, I'd appreciate if we could work towards some general solution for this,
and official recommendations for how to handle TOFU and cert renewal.

makeworld

From hello at matthewgraybosch.com  Mon Jun 15 02:17:01 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sun, 14 Jun 2020 21:17:01 -0400
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <ynIhaxwCK90fqhpv9FN-s8sv32gErns3Rq8053ri0jLiqRHiQRrHKAnEa3widBxm-GlWwlsIM1Go8Mt0UN_iiHlKqUavQaWRC15tQWETXMM=@protonmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>
 <ynIhaxwCK90fqhpv9FN-s8sv32gErns3Rq8053ri0jLiqRHiQRrHKAnEa3widBxm-GlWwlsIM1Go8Mt0UN_iiHlKqUavQaWRC15tQWETXMM=@protonmail.com>
Message-ID: <20200614211701.9c8286f05014d522302b74c3@matthewgraybosch.com>

On Sun, 14 Jun 2020 18:13:09 +0000
colecmac at protonmail.com wrote:

> If you haven't already, it's a MUST to setup an SSH key and turn off
> password login. This will basically remove all SSH based attacks.
> 
> https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/

Thanks for the advice. I've already disabled root logins in my
sshd_config, and I've set up public-key logins for my own accounts.
I've got to do a better job of educating tanelorn.city's residents
before I can disable password logins via ssh entirely, though.

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

From hello at matthewgraybosch.com  Mon Jun 15 02:31:07 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sun, 14 Jun 2020 21:31:07 -0400
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <61b3ed4c-1601-8c93-83f8-00280f4a44c7@c3f.net>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>
 <61b3ed4c-1601-8c93-83f8-00280f4a44c7@c3f.net>
Message-ID: <20200614213107.094efc352cd936a8eeed690d@matthewgraybosch.com>

On Sun, 14 Jun 2020 15:34:08 -0500
jes <j3s at c3f.net> wrote:

> You might also consider that there are a number of drawbacks
> regarding fail2ban, here's the article that I've written on the
> subject:
> 
> https://j3s.sh/thoughts/fail2ban-sucks.txt
 
Thanks. I just finished reading this, and am now reading the article on
OpenSSH hardening that you linked. I had root login disabled from the
start, so that's a start. :)

I've also seen some forum posts suggesting that I can disable password
authentication for all users by default, and then allow exceptions for
particular users. This might help me harden Tanelorn without making
things harder for less-skilled users who haven't gotten the hang of
generating a ssh key and copying it yet.

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

From sean at conman.org  Mon Jun 15 03:23:20 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 14 Jun 2020 22:23:20 -0400
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <gp6Ja5zK2ZCDtNROdt5Q5-iIkv1IxnMmsJGLHf-TBcoHuNv4-gUdpBfsyzwTHL5VdbVjF8M72CgCFgvxqpL4BMNaesfvNP_FnPNWCJlaC60=@protonmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <gp6Ja5zK2ZCDtNROdt5Q5-iIkv1IxnMmsJGLHf-TBcoHuNv4-gUdpBfsyzwTHL5VdbVjF8M72CgCFgvxqpL4BMNaesfvNP_FnPNWCJlaC60=@protonmail.com>
Message-ID: <20200615022320.GT11281@brevard.conman.org>

It was thus said that the Great defdefred once stated:
> On Sunday, June 14, 2020 3:22 AM, Sean Conner <sean at conman.org> wrote:
> > [3] http://boston.conman.org/2019/07/09-12
> > http://boston.conman.org/2019/08/06.2
> 
> Should we deduce that a significative part of the internet traffic is fake request?
> That a shame concidering the environmental impact of the digital world.
> Maybe blocking all this non-human request is the solution?

  Okay, how does one detect fake requests vs. legitimate requests?  Way back
in 2006 when I was paid to do this type of work, I set up a tarpit [1] with
the idea of maybe using the information gathered from it to block unwanted
tarffic.  Unfortunately, had I set this up, we still would *receive* the
packets.  To really have the effect you want, you need to block it *at the
source* and to do that would require cooperation with literally *hundreds*
(if not a few thousand) other network operators.

  My blog entry for January 26, 2006 [2] I noted having seen 107,287
connection attempts over a 24-hour period.  I didn't record the number of
unique IPs (which could give an indication of the number of networks
involved) but that's still over one "reported incident" per second.

  After awhile, it just beomces background noise you learn to ignore.

  -spc

[1]	https://en.wikipedia.org/wiki/Tarpit_%28networking%29

[2]	http://boston.conman.org/2006/01/26.3

From j3s at c3f.net  Mon Jun 15 03:26:45 2020
From: j3s at c3f.net (jes)
Date: Sun, 14 Jun 2020 21:26:45 -0500
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200614213107.094efc352cd936a8eeed690d@matthewgraybosch.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <20200613224024.70fbfb299b20eaae5ca8cb80@matthewgraybosch.com>
 <61b3ed4c-1601-8c93-83f8-00280f4a44c7@c3f.net>
 <20200614213107.094efc352cd936a8eeed690d@matthewgraybosch.com>
Message-ID: <43ca9349-3d40-51d3-83e6-6d4a3825fccc@c3f.net>

On 6/14/20 8:31 PM, Matthew Graybosch wrote:
> On Sun, 14 Jun 2020 15:34:08 -0500
> I've also seen some forum posts suggesting that I can disable password
> authentication for all users by default, and then allow exceptions for
> particular users. This might help me harden Tanelorn without making
> things harder for less-skilled users who haven't gotten the hang of
> generating a ssh key and copying it yet.

Up to you! In my mind turning password auth is priority number one - but 
since you have users who could be confused by it, it's up to you and 
your own risk tolerance.

If any of these users are able to switch to the root user or similar, 
I'd say that you must disable password auth now regardless of what your 
users prefer.

You may consider setting MaxAuthTries to a reasonable value (say, 3 or 
4) which will lock user accounts that fail password auth that many times.


j3s

From solderpunk at SDF.ORG  Mon Jun 15 08:32:31 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 07:32:31 +0000
Subject: Thoughts on TOFU
In-Reply-To: <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
Message-ID: <20200615073231.GA16765@SDF.ORG>

On Sun, Jun 14, 2020 at 11:09:05PM +0000, colecmac at protonmail.com wrote:
 
> Solderpunk, I'd appreciate if we could work towards some general solution for this,
> and official recommendations for how to handle TOFU and cert renewal.

I would *love* to!  And I have loads of ideas on this front.  I've just
never had the time to write anything substantial on them because there
is always some more urgent matter popping up, like surprise auto-cookies
or people wanting to add upload capabilities.  If things ever settle
down (tonight I will make official the spec changes I recently asked for
feedback on and then freeze the thing again, perhaps that will help) we
can tackle this.

> I'm not sure what to do about this. Both options seem bad, and both will cause
> breakage. It seems that there is no good way to do TOFU with certs, unless
> you want to try and control how servers use certs, like specifying that keypairs
> should not change or something.

I don't think that keeping the same keypair forever is a good idea, but
I *do* think that "controlling how servers use certs" is.  Without CAs
in the picture it's trivial to automate cert changes, which makes this
easy.  I also think that pushing Gemini servers to use the smallest
certs they can (i.e. not RSA) is a good idea to reduce TLS overhead,
which is another reason for people to take control of their own
certificate generation.

Quick sketches:

* Servers can sign their new cert with their *previous* private key.
Then TOFU clients which accepted the previous cert can validate the
changeover - and then immediately stop trusting the previous cert so
that anybody who stole the private key can't sign their own new cert.
Basically, when you accept a new cert you also grant it one-use-only,
very-limited-scope CA powers.

* Servers can generate their new self-signed cert N months in advance
and, for those N months, advertise the hash of the new cert at a
well-known endpoint, access to which is secured by the current cert.
TOFU clients can notice when an accepted cert is close to expiry and
pre-fetch the future fingerprint.

* Servers can use DANE (RFC6698) to advertise their self-signed cert
over DNS, and TOFU clients can check this when receiving an unrecognised
cert.  LOTS of details to discuss here re: DNS security.

* We could built Perspectives/Convergence style "notary" servers that
TOFU clients clients can consult when receiving an unrecognised cert.
This was an idea that was developed before it's time, IMHO.  Today there
is no reason that achieving broad network perspective requires trusted
third parties and an effective "shadow infrastructure" alongside CAs.
Just run your own certificate observatory on a dirt cheap VPS.  Share it
with friends, who share theirs with you.  Pubnixes can run then for
their users.  Unlike some of the other ideas, this works just as nicely
with CA-signed certs (like those from Let's Encrypt) as self-signed
certs.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Mon Jun 15 08:35:12 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 07:35:12 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <5EE68E74.3040107@marmaladefoo.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <34e5e030-ce9b-82da-b72a-cde45de171e8@masterq32.de>
 <20200614142615.GE363@SDF.ORG> <5EE68E74.3040107@marmaladefoo.com>
Message-ID: <20200615073512.GB16765@SDF.ORG>

Sorry, my reply to this last night went straight to Luke, not the whole
list.  Here it is again:

On Sun, Jun 14, 2020 at 09:54:12PM +0100, Luke Emmet wrote:
> This is quite a harsh perspective IMO - in the developing world there are
> many people who can only afford to access the internet via a phone. Whilst
> we might not build specifically for phone users, the light weight nature of
> Gemini does make it a potential vehicle to be used for many more people than
> we may imagine.

Fair point: not everybody without a keyboard is without one by choice.
I guess I just can't personally conceive of ever *wanting* to routinely
write hundreds of words on a touchscreen phone.  Especially not with
URLs and syntax like => thrown in.  No matter how effortless the upload
process, the actual writing would be unbearable.

Now, *reading* content is a very different story, and not what I was
talking about with my comment about not targetting "crippled devices".
For users accessing the internet on phones with low memory/CPU resources
on slow and/or expensive networks, I think Gemini could be an extremely
appealing choice.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Mon Jun 15 08:39:01 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 07:39:01 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <5EE69143.503@marmaladefoo.com>
References: <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
Message-ID: <20200615073901.GC16765@SDF.ORG>

On Sun, Jun 14, 2020 at 10:06:11PM +0100, Luke Emmet wrote:
 
> I think this is a great idea! It would go quite a long way to supporting
> collaborative editing. And as you say it is infrastructure we already have.

I'm glad you think so!  I hope other people who were keen on an upload
mechanism are too.  As you point out there are small details to smooth
over for the wiki case; but for simple "publishing for the masses"
where the starting state is a blank page, doesn't this basically get us
there?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Mon Jun 15 10:51:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 09:51:21 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200615073901.GC16765@SDF.ORG>
References: <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG>
Message-ID: <20200615095121.GA20393@SDF.ORG>

On Mon, Jun 15, 2020 at 07:39:01AM +0000, solderpunk wrote:
> On Sun, Jun 14, 2020 at 10:06:11PM +0100, Luke Emmet wrote:
>  
> > I think this is a great idea! It would go quite a long way to supporting
> > collaborative editing. And as you say it is infrastructure we already have.
> 
> I'm glad you think so!  I hope other people who were keen on an upload
> mechanism are too.  As you point out there are small details to smooth
> over for the wiki case; but for simple "publishing for the masses"
> where the starting state is a blank page, doesn't this basically get us
> there?

An interesting idea which was just floated on the BBS at the Zaibatsu
pubnix, inspired by the "friSBEe" project started by cmmcabe (admin of
gemini://rawtext.club), is the possibility of publishing via email.
Typical text/gemini content is certainly small enough to be "uploaded"
as an attachment (it can't really travel in the body of an email due to
restrictions on line length).

Cheers,
Solderpunk

From defdefred at protonmail.com  Mon Jun 15 11:14:23 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 15 Jun 2020 10:14:23 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
Message-ID: <_I2MnEyKotPVsLV8GucP3GLol-D6j_QFW9xOsgjAuA0_ExfquRPprsc93r1giPTbdfwKDUFF4dkfuAeo8CpJjWNQpHE8AKYW0pDeSogHy6Q=@protonmail.com>

On Saturday 13 June 2020 22:56, solderpunk <solderpunk at SDF.ORG> wrote:
> 6.  Does anybody else feel like we are just instinctively re-implementing
>     the familiar history of the web without much caution or critical
>     thought?
yep

From jmcbray at carcosa.net  Mon Jun 15 11:55:33 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 15 Jun 2020 06:55:33 -0400
Subject: Germinal v0.2.0 update
In-Reply-To: <20200614094630.GA363@SDF.ORG>
References: <875zbuo0y8.fsf@dorothy.carcosa.net> <20200614094630.GA363@SDF.ORG>
Message-ID: <25e08543-1d38-48cd-a2cd-3ea0971df4ad@localhost>

Sure. Originally, I took a very simplistic approach, just eating '../'
whenever I saw it in a request. Unfortunately, it didn't handle a bare
'..', which meant the parent directory of the document root was
listable. Worse, you could construct a request like
gemini://my.site/.../...//.../...//etc/passwd to get whatever you
wanted, as long as it was locally world-readable.

The fix normalizes all pathnames before looking for files, and it checks
that the resulting path is under the document root. I pulled in a
library to help with this, which I originally wanted to avoid, but
pathname handling in Common Lisp is pretty weird, and I felt the library
(ppath) was worth it.

--
+----------------------------------------------------------------+
| Jason F. McBrayer                         jmcbray at carcosa.net  |
| The scalloped tatters of the King in Yellow must hide Yhtill   |
| forever.                    R.W. Chambers _The King in Yellow_ |

From jmcbray at carcosa.net  Mon Jun 15 11:57:01 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 15 Jun 2020 06:57:01 -0400
Subject: gemini-mode.el is now in MELPA
Message-ID: <d31cbefa-f4dd-4007-bc91-f020248f17aa@localhost>

Gemini-mode, a simple mode for editing text/gemini files in Emacs, is now 
in MELPA, which should make it easier for most people to install it.

If you want to contribute, or to install it manually, the source is at
https://git.carcosa.net/jmcbray/gemini.el.

--
+----------------------------------------------------------------+
| Jason F. McBrayer                         jmcbray at carcosa.net  |
|  "If you wish to make Pythocles wealthy, don't give him more   |
|   money; rather, reduce his desires."            -- Epicurus   |

From solderpunk at SDF.ORG  Mon Jun 15 12:01:14 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 11:01:14 +0000
Subject: Germinal v0.2.0 update
In-Reply-To: <25e08543-1d38-48cd-a2cd-3ea0971df4ad@localhost>
References: <875zbuo0y8.fsf@dorothy.carcosa.net> <20200614094630.GA363@SDF.ORG>
 <25e08543-1d38-48cd-a2cd-3ea0971df4ad@localhost>
Message-ID: <20200615110114.GB20393@SDF.ORG>

On Mon, Jun 15, 2020 at 06:55:33AM -0400, Jason McBrayer wrote:
> Sure. Originally, I took a very simplistic approach, just eating '../'
> whenever I saw it in a request. Unfortunately, it didn't handle a bare
> '..', which meant the parent directory of the document root was
> listable. Worse, you could construct a request like
> gemini://my.site/.../...//.../...//etc/passwd to get whatever you
> wanted, as long as it was locally world-readable.
> 
> The fix normalizes all pathnames before looking for files, and it checks
> that the resulting path is under the document root. I pulled in a
> library to help with this, which I originally wanted to avoid, but
> pathname handling in Common Lisp is pretty weird, and I felt the library
> (ppath) was worth it.

Thanks for sharing this!  A good cautionary tale for people quickly
throwing together servers.

For what it's worth, if Molly Brown detects even a single ".." in a
request URL anywhere it immediately returns:

"50 Your directory traversal technique has been defeated!\r\n"

without even consulting the filesystem. :)  Just not worth the risk of
trying to get it right, IMHO.  Even then, I *still* explicitly check
the resultant filesystem path is under the document root, and also
explicitly check that it is not equal to the server access log or the
TLS cert or key files (which should never inside the document root,
but better safe than sorry!).

Cheers,
Solderpunk

From julien at typed-hole.org  Mon Jun 15 12:50:30 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Mon, 15 Jun 2020 13:50:30 +0200
Subject: gemini-mode.el is now in MELPA
In-Reply-To: <d31cbefa-f4dd-4007-bc91-f020248f17aa@localhost>
Message-ID: <C3HNJ73XNUF7.16B0JS7WCYOU7@x1carbon>

On Mon Jun 15, 2020 at 8:57 AM CEST, Jason McBrayer wrote:
> Gemini-mode, a simple mode for editing text/gemini files in Emacs, is
> now
> in MELPA, which should make it easier for most people to install it.
>
> If you want to contribute, or to install it manually, the source is at
> https://git.carcosa.net/jmcbray/gemini.el.
>

Just installed it and it's very nice, congrats!

From tomasino at lavabit.com  Mon Jun 15 13:39:03 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 15 Jun 2020 12:39:03 +0000
Subject: gemini streaming
In-Reply-To: <20200615095121.GA20393@SDF.ORG>
References: <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG> <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG> <20200615095121.GA20393@SDF.ORG>
Message-ID: <c631f61b-0011-6fff-b662-5722fc68a281@lavabit.com>

Since text/gemini (or gemtext, if that's what we're calling it) is parsable from top-to bottom in a single pass, it's also perfectly well suited to being treated as a stream instead of a document. I believe the only limitation to this currently is that many clients are expecting that gemtext is a document and are deferring parsing until the end-of-document is reached.

When I raised this question on the IRC channel I wanted to know if there was a way to indicate within the MIME perhaps that the resource is a stream and not a document. Then clients could know explicitly that they shouldn't be waiting on the end of document before parsing. I'm really not familiar with the technical mechanisms of how that's set up on HTTP, so I wanted to toss it to the list. 

Should we investigate a MIME solution to be explicit, or should clients treat all text/gemini as streams and just parse as they go? The later seems easier from a implementation standpoint. Someone raised the question about how the display should be handled between the two, though. Sometimes streams desire to keep the focus pinned to the newest content, not the start of the document. That sort of functionality would support using a separate explicit MIME or some other way to differentiate them.

With streams in place we could do some very cool things. We could build a fediverse front-end, or a view into the IRC channel. If you use two tabs and a response 10 loop and client certs, you could even post INTO these platforms. Let your imagination run wild!


From defdefred at protonmail.com  Mon Jun 15 14:35:02 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 15 Jun 2020 13:35:02 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200615095121.GA20393@SDF.ORG>
References: <20200613070556.GI11281@brevard.conman.org>
 <20200613205635.GD18831@SDF.ORG> <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG> <20200615095121.GA20393@SDF.ORG>
Message-ID: <pY_OmfmYR7_AMBpjkU1YKW22bMLpD0L_mb0eXMrjnal1-OnlYvNeEi3JEOxezt-OF_XezWmKeMgDYuVQGDO1YnWTdYOCPA7gr824vCc07A4=@protonmail.com>

On Monday 15 June 2020 11:51, solderpunk <solderpunk at SDF.ORG> wrote:
> An interesting idea which was just floated on the BBS at the Zaibatsu
> pubnix, inspired by the "friSBEe" project started by cmmcabe (admin of
> gemini://rawtext.club), is the possibility of publishing via email.
> Typical text/gemini content is certainly small enough to be "uploaded"
> as an attachment (it can't really travel in the body of an email due to
> restrictions on line length).
Also a nice way to send moderated comment to an article.

From fgaz at fgaz.me  Mon Jun 15 15:09:47 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Mon, 15 Jun 2020 16:09:47 +0200
Subject: CSRF in Gemini
Message-ID: <20200615160947.06cc84f8@phi>

Hi all,

I just wrote down a few thoughts about cross-site request forgery in
Gemini:

gemini://gemini.circumlunar.space/~/fgaz/posts/2020-06-15-csrf-in-gemini/

I'm starting this thread to brainstorm ideas about the last point.
Basically:

> CSRF protection via non-native nonces is ugly, can we do better than
> the web?

Cheers
-- Francesco

From solderpunk at SDF.ORG  Mon Jun 15 15:30:07 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 14:30:07 +0000
Subject: CSRF in Gemini
In-Reply-To: <20200615160947.06cc84f8@phi>
References: <20200615160947.06cc84f8@phi>
Message-ID: <20200615143007.GE20393@SDF.ORG>

On Mon, Jun 15, 2020 at 04:09:47PM +0200, Francesco Gazzetta wrote:
 
> I'm starting this thread to brainstorm ideas about the last point.

Thanks for getting this conversation started!

It's perhaps a little bit tedious for users, but the simplest solution I
can think of for things like this is a convention that all requests
which trigger side-effects (like comments, etc.) must be made with a
client certificate, because that will make it very clear to the user
that something is happening and no surprises are possible.

I strongly suspect that completely preventing this kind of thing will be
impossible if we simultaneously insist on a simple protocol and a
frictionless user experience - in which case, everybody knows which one
will be prioritised. :)  But if we can somehow pull off both at once
that will be best.

Cheers,
Solderpunk

From felix at masterq32.de  Mon Jun 15 16:05:33 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Mon, 15 Jun 2020 17:05:33 +0200
Subject: CSRF in Gemini
In-Reply-To: <20200615160947.06cc84f8@phi>
References: <20200615160947.06cc84f8@phi>
Message-ID: <c612dd1d-8d81-625e-84eb-e4cc7f94fe33@masterq32.de>

Hey!

> I just wrote down a few thoughts about cross-site request forgery in Gemini:

Good read! I thought about that as well?

>> CSRF protection via non-native nonces is ugly, can we do better than
>> the web?
I think one solution would be to force clients to remove queries from
all URLs. It's not a really elegant solution and makes CGI stuff harder
to implement, but will prevent a lot of URL-fuckery. I'm also always
scared when clicking links in interactive things, because double
postings are really easy to achieve with the query appended to URLs.
Hitting refresh in your browser to see new posts? You create a new post
in the guestbook!

While writing this, i got the following idea (which seams reasonable to me):
Specify that a response to INPUT MUST be passed with a query-parameter
"?input=?" where "?" is the data from the user. The data is fully
urlencoded with all forbidden characters(space,?,=,?) replaced with
their percent-encoding.

Also specify that clients SHOULD remove the "input"-parameter between
redirects and in documents using the gemini-scheme.

This allows us to prevent passing accidential or malicious data via
redirects, but doesn't help against a spam-bot that targets a site
directly. It also makes client implementation a bit harder.

Regards
- xq

From gmym at coopdot.com  Mon Jun 15 16:38:01 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Mon, 15 Jun 2020 17:38:01 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <pY_OmfmYR7_AMBpjkU1YKW22bMLpD0L_mb0eXMrjnal1-OnlYvNeEi3JEOxezt-OF_XezWmKeMgDYuVQGDO1YnWTdYOCPA7gr824vCc07A4=@protonmail.com>
References: <20200613070556.GI11281@brevard.conman.org>
 <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org> <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG>
 <5EE69143.503@marmaladefoo.com> <20200615073901.GC16765@SDF.ORG>
 <20200615095121.GA20393@SDF.ORG>
 <pY_OmfmYR7_AMBpjkU1YKW22bMLpD0L_mb0eXMrjnal1-OnlYvNeEi3JEOxezt-OF_XezWmKeMgDYuVQGDO1YnWTdYOCPA7gr824vCc07A4=@protonmail.com>
Message-ID: <CAObwWNg+wumNBDP=XBPBdk6EEaOMVN9QjvZe+u4BhProrSELqA@mail.gmail.com>

defdefred <defdefred at protonmail.com> wrote:

> On Monday 15 June 2020 11:51, solderpunk <solderpunk at SDF.ORG> wrote:
> > An interesting idea which was just floated on the BBS at the Zaibatsu
> > pubnix, inspired by the "friSBEe" project started by cmmcabe (admin of
> > gemini://rawtext.club), is the possibility of publishing via email.
> > Typical text/gemini content is certainly small enough to be "uploaded"
> > as an attachment (it can't really travel in the body of an email due to
> > restrictions on line length).
> Also a nice way to send moderated comment to an article.
>

My gemlog is using that as it's comment system.

-- 
Katarina Eriksson

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200615/73f53daf/attachment.htm>

From hello at matthewgraybosch.com  Mon Jun 15 16:50:09 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Mon, 15 Jun 2020 11:50:09 -0400
Subject: gemini-mode.el is now in MELPA
In-Reply-To: <d31cbefa-f4dd-4007-bc91-f020248f17aa@localhost>
References: <d31cbefa-f4dd-4007-bc91-f020248f17aa@localhost>
Message-ID: <20200615115009.742dc1c2d782ee4ad891b48b@matthewgraybosch.com>

On Mon, 15 Jun 2020 06:57:01 -0400
Jason McBrayer <jmcbray at carcosa.net> wrote:

> Gemini-mode, a simple mode for editing text/gemini files in Emacs, is
> now in MELPA, which should make it easier for most people to install
> it.

Got it in my .emacs with use-package.

(use-package gemini-mode
  :ensure t)

Just had to do M-x package-refresh-contents and then M-x eval-buffer to
install.

Thanks for doing this.

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

From gmym at coopdot.com  Mon Jun 15 16:53:35 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Mon, 15 Jun 2020 17:53:35 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200614150547.GF363@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org> <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG>
Message-ID: <CAObwWNhwd_66YRuUt7kdYh1_xnNxyhiQy8jaJykyMuJrmdxYdw@mail.gmail.com>

solderpunk <solderpunk at sdf.org> wrote:

> It should also be very easy to write an app targetted at "non-technical"
> authors which lets them submit chunks of writing up to 2 KiB or so, with
> an "append" link at the submission confirmation page to submit a follow
> up chunk.  It wouldn't necessarily be the smoothest experience in the
> world, but if most content could be written in a single request and 99%
> with one or two "append" requests, I think it would be usable enough.
> Heck, this is the "slow internet", right?  A little bit of inconvenience
> as part of a careful and deliberate process should not scare us away.
>

People write a lot longer Twitter threads than that and Tweets are tiny
compared to Gemini's meta field. I wish I had the energy to build a proof
of concept right now because this sounds interesting.

-- 
Katarina Eriksson

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200615/ab82ea6e/attachment.htm>

From felix at masterq32.de  Mon Jun 15 17:11:41 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Mon, 15 Jun 2020 18:11:41 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200615095121.GA20393@SDF.ORG>
References: <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG> <20200613215024.GK11281@brevard.conman.org>
 <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG> <20200615095121.GA20393@SDF.ORG>
Message-ID: <37f6461b-7931-9f68-9405-22eb6acf9835@masterq32.de>


> An interesting idea which was just floated on the BBS at the Zaibatsu
> pubnix, inspired by the "friSBEe" project started by cmmcabe (admin of
> gemini://rawtext.club), is the possibility of publishing via email.
> Typical text/gemini content is certainly small enough to be "uploaded"
> as an attachment (it can't really travel in the body of an email due to
> restrictions on line length).

Email sounds like a really nice solution! Using email as a
human->machine interface is actually quite nice, but you need some kind
of spoofing protection, but GPG solves that problem already.

Using simple "subject=path", "body=content", you can easily update your
server with a fitting server-side daemon.

I like!

Regards
- xq

From solderpunk at SDF.ORG  Mon Jun 15 17:13:17 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 16:13:17 +0000
Subject: [SPEC-CHANGE] Simplified client certs, URI scheme, alt text
Message-ID: <20200615161317.GF20393@SDF.ORG>

Ahoy, Geminauts!

I have just made the proposed spec changes that I asked for comment on
over the just past weekend official.

SUMMARY OF CHANGES:
 
* A gemini:// URI scheme is formally defined for the first time,
  explicitly disallowing the use of the userinfo subcomponent of the
  authority component.
* The client certificate system has been substantially simplified, with
  transient certificates no long a formally defined concept with
  prescribed behaviour.
* A lightweight notion of alt text for pre-formatted content has been
  introduced as a tentative step toward fixing the worst search and
  accessibility related problems with pre-formatted non-textual content.
  No special structures or semantics for alt text are defined - if a
  convention for doing this organically arises in the community it may
  become a recommended best practice.
* A few minor corrections and tidyups.

IMPLICATIONS FOR SERVER AUTHORS:
   
Servers SHOULD return status 59 (BAD REQUEST) if they receive a request
for a gemini:// URL containing a userinfo subcomponent.  If you really
want to be hyper-Postelian, you MAY instead strip out the userinfo so
that, for example, it does not end up in logs, is not passed to CGI
apps, etc.
    
IMPLICATIONS FOR CLIENT AUTHORS:
     
Clients should either refuse to follow gemini:// links with userinfo
subcomponents, or should strip out the userinfo before following the
link.

Clients with support for client certificates should adapt to the new
simplified specification, which may involve e.g. removing support for
the deprecated status code 21.

Clients may do something with alt text.  This is probably most relevant
to search engines and accessibility-focussed clients, but I suppose e.g.
graphical clients may wish to support web browser style hover over
display.  Strictly optional in all cases.
      
IMPLICATIONS FOR CONTENT AUTHORS:

If you have authored content which includes gemini:// links with
userinfo subcomponents, you MUST remove the userinfo.

You may wish to add alt text to preformatted content which is not
meaningfully screen readable or search engine indexable.

Cheers,
Solderpunk


From peteyboy at SDF.ORG  Mon Jun 15 18:05:43 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Mon, 15 Jun 2020 17:05:43 +0000 (UTC)
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was R
 Uploading Gemini content))
In-Reply-To: <mailman.206.1592188011.529.gemini@lists.orbitalfox.eu>
References: <mailman.206.1592188011.529.gemini@lists.orbitalfox.eu>
Message-ID: <alpine.NEB.2.21.2006151702580.17060@otaku.sdf.org>


> From: Matthew Graybosch <hello at matthewgraybosch.com>
> To: gemini at lists.orbitalfox.eu
> Subject: Re: Repeating the Web's Mistakes (was gemini+submit:// (was
> 	Re: Uploading Gemini content))
> Message-ID:
> 	<20200614211701.9c8286f05014d522302b74c3 at matthewgraybosch.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Sun, 14 Jun 2020 18:13:09 +0000
> colecmac at protonmail.com wrote:
>
>> If you haven't already, it's a MUST to setup an SSH key and turn off
>> password login. This will basically remove all SSH based attacks.
>>
>> https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/
>
> Thanks for the advice. I've already disabled root logins in my
> sshd_config, and I've set up public-key logins for my own accounts.
> I've got to do a better job of educating tanelorn.city's residents
> before I can disable password logins via ssh entirely, though.

I think some of the tilde sites only use ssh key login. Tilde.town, 
Tilde.team, and hashbang all do.  You  could sign up for one to see how 
they do it. I think in tilde.team you paste in your ssh key on a web page 
and then you can log in?


peteyboy at sdf.org
SDF Public Access UNIX System - http://sdf.org

From peteyboy at SDF.ORG  Mon Jun 15 18:28:46 2020
From: peteyboy at SDF.ORG (Pete D.)
Date: Mon, 15 Jun 2020 17:28:46 +0000 (UTC)
Subject: gemini+submit:// (was Re: Uploading Gemini content)
Message-ID: <alpine.NEB.2.21.2006151714240.17060@otaku.sdf.org>

It's funny, when I first looked at gemini, it sparked my interest as an 
idea of a wiki scheme, just implementing the initial dream of interwiki 
as a protocol, so every page is a wiki page, with some sort of native 
markup, connected to other pages, which would all be wikis.

I was disabused of that notion when I realized, after reading a bunch of 
email digests, that the final spec for links was not in-line at all, and 
the idea was to make gopher that was less annoying (ok, it's annoying to 
me, I quit after initial phlogging because of gophermaps). But man, I 
love a simple wiki mark-up (# * ```, =>)!

So, I got caught up in this mini-reprise of the initial days of the www, 
though, it is so cool that most of the gemini content can't be gotten 
unless you have a gemini browser!  So I let go of the wiki dream, and got 
into this new world of simple text.

In this www-reprise model, lots of extra stuff is being proposed, it seems 
to me, and at some point, one has to ask, why not use http if you are 
going to decorate with all the http things? One answer is, of course, is 
that old, unfancy http seems lame and dated (looks at SDF tutorial pages), 
which is valid. That stuff is not exciting.

And so now, seeing all this wiki talk, I'm excited again by the idea of a 
wiki protocol, but at the same time, I feel like it really should be a 
different project. It's not what gemini is.

If we are turning this into a wiki protocol, why don't we have inline 
links and all the cool markup available to make nice documents (TOCs, 
etc), and versioning and all that?


peteyboy at sdf.org
SDF Public Access UNIX System - http://sdf.org

From solderpunk at SDF.ORG  Mon Jun 15 18:38:13 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 17:38:13 +0000
Subject: Permanent freeze on non-trivial new features
Message-ID: <20200615173813.GA17413@SDF.ORG>

Greetings all,

After today's change to the spec to introduce some new line types, I am 
announcing a permanent freeze on the addition of non-trivial new 
features to Gemini.

This is a bit of a deviation from the big picture plan I sketched when
announcing the last three month spec free, which was:

> 1. INTERVAL = 3 months
> 2. Spend INTERVAL actually building Geminispace and associated tools,
>    with no major spec changes.
> 3. Ask "What is the *single* biggest problem/shortcoming of the current
>    spec, based on everything that has actually been done or been tried
>    in the past INTERVAL?"
> 4. Possibly (but not necessarily) change the spec to address the
>    answer to 3, if the problem is deemed bad enough and can be
>    addressed without adding too much extra complexity.
> 5. Set INTERVAL = 2*INTERVAL
> 6. GOTO 2, or END.

I still very much agree with the spirit of this plan and think this is a
fine way to develop small and simple software with a clear purpose and
to avoid the ever-present danger of feature creep.  That said, in terms 
of the practical implications for Gemini, strictly following this plan 
would cause things to stretch on too long.  Announcing a six month 
freeze would bring us into next year, and to be honest I really want 
this whole thing (as in, the specification of Gemini) to be absolutely 
done and dusted by the end of this year.  That includes all the final
fine-toothed combing and worrying about little details and edge cases.
Which means actual work needs to stop as soon as possible.

What we have specced right now is still small and simple, easy to learn
and easy to implement.  IMHO we have done a good job smoothing off all
the rough edges of Gopher and all of the project's original ambitions
have been met.  The full capabilities of, and the full extent of
problems with, even very simple systems like Gemini take years to be
fully uncovered and understood (a point the demosceners amongst us
will attest to!).  Things like Tomasino's recent post about the exciting
possibilities of taking advantage of the fact that Gemtext can be 
correctly processed line-by-line to "stream" content like chatrooms or 
logs, and Francesco's post about CSRF in Gemini, both show that we have
only just begun to scratch the surface of Gemini.  Adding anything
further at this stage when there are still so very many practical points
needing attention, and when we still don't even really know what we
have, seems very unwise to me.

This means there will never be any official mechanism for uploading
Gemini content within Gemini itself, beyond what can be built on top of
what we already have, with possibly a few trivial tweaks added to ease
this.  I realise this will disappoint a lot of people and I'm honestly
really unhappy about that.  But Gemini was never supposed to be all
things to all people - I really don't believe any software which is
really simple *can* be that, and I really believe that radical
simplicity is necessary to make software possible to correctly reason
about, which in turn is necessary to make it reliable and secure and for
users to exercise their autonomy, and to make it easy to implement and
deploy, which in turn is necessary to keep it from falling into familiar
traps of centralisation, monopolisation, etc.

If there are people in the community who want to independently develop a
separate companion protocol in the spirit of Gemini to address the
upload problem, I can't and won't attempt to discourage them, as I'm
fully aware that I have absolutely no right to do so.

As the focus of activity in the community begins to move away from
defining the Gemini protocol and toward building things on top of the
fixed foundation that its final form offers, there is honestly a really
wide range of things that interested people can get their hands dirty
with if they want to, and this includes lots of stuff related to making
Gemini more accessible to people without the requisite technology
background to make use of pubnix hosting and similar resources.  This
includes development work (I think it's very clear that we have not even
begun to scratch the surface of possible ways to ease the publishing
process without adding anything to the protocol) and educational work
(writing good Gemini-hosted content helping people acquire that
technical backround).  This is very worthy work toward a very worthy
goal and I fully support it.

Those of you who just won't know what to do with yourselves without the
thrill of arguing over specification details need not feel any sense of
loss as the Gemini protocol begins to stabilise, even if you don't have
the stomach for the less glamorous work of fiddly minor final detail
wrangling: we still have a big pile of interesting "side-specs" that
have not received full attention, most notably adapting robots.txt into
an environment without User-Agents.

I think we can rightfully be very proud of ourselves for what we've
developed here so far, and I really look forward to us starting to make
use of it in earnest!  Thanks to everybody who has contributed to the
project in any way, large or small.  Despite the air of finality
throughout this email, this really is just the very beginning of this
whole thing.  Let's build an awesome Geminispace!

Cheers,
Solderpunk

From apellis at gmail.com  Mon Jun 15 18:40:31 2020
From: apellis at gmail.com (Alex Ellis)
Date: Mon, 15 Jun 2020 10:40:31 -0700
Subject: gemini servers and "frameworks"?
Message-ID: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>

I'm new to Gemini, and I've started implementing a gemini server. Is there
a list of gemini server projects (as in serving software, not live servers
that are serving content)? I'm interested in seeing how others handle
dynamic routes. Are there any projects yet implementing gemini "frameworks"
(a la python's Flask for web)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200615/7033d315/attachment-0001.htm>

From krixano at protonmail.com  Mon Jun 15 18:45:13 2020
From: krixano at protonmail.com (Krixano)
Date: Mon, 15 Jun 2020 17:45:13 +0000
Subject: Gemini, Web, and Solderpunk
Message-ID: <sHIXIdnoU5_LhIgulppriw_vcm-1oRMZERVsupvDSUeo3AHq02nPeUWBn2o4P2NNwUcFOB-fKE5xwArLmEj3CkMDiNizSs8QVPS-3TRz4YY=@protonmail.com>

Ok, so I'm writing this for multiple reasons that center around one reason. I'm just going to get into it. Just be aware
that I'm writing this not to be mean, but to make sure everybody here pays attention to every consequence each decision has. :)

We can *not* let Gemini turn into the Web, period. We have to remember how the Web turned into a disaster and actively prevent that.
If we are moving toward making full Virtual Machine applications that can do threading and sockets and UI and GPU rendering and all of this... crap... we have
then turned into the web and are requiring browser implementers to basically create full operating systems, which will prevent small teams from
ever being able to develop a browser for Gemini, which means only bigger companies would be able to do this, which will reduce competition, and then
we have a duopoly on browsers *and the spec*, like with what the web is today.

Imo, we have to remember that not *everything* needs to be in *one unified protocol*. This is the exact line of thinking that led to HTTP and the other Web
technologies. Not everyone who is browsing is a content creator. Content creators aren't necessarily browsing when creating content. Why do these two things
need to be in the same protocol?

Similarly, we already have Operating Systems that can run native programs millions of times faster than any Virtual Machine. We do not need a virtual machine.
(I haven't seen anybody moving this far yet, but I still want to make this point because it's important).

If we want something like being able to edit content on servers, what's wrong with (S)FTP? or SSH? or SCP? If something's wrong with these, then fix it! We can make
a new, better, and simpler FTP! Or we can make a more complicated FTP! Or we can make a more Gopher/Gemini-focused FTP!
(imo, FTP is very old and complicated, that we could actually use a new protocol for this, and this is something I've thought about way before Gemini was even a thing.)
We can use Gemini's certificate concept for this new protocol that would be like a Semi-Anonymous FTP user. This being a separate protocol will allow for a lot more than if we
try to shoehorn it into Gemini.

Why should this be in a separate protocol? Gemini is not suited for Binary. And binary might be important for something like this. Gemini's display structure is suited for content,
not editing filesystems or files. There are probably other reasons, but these are the most important.

I wanted to say to Solderpunk... it's important that you take input, but just make sure you put your foot down when it needs to be done. Because,
if anybody's read the Mythical-Man Month, or seen how committees (especially web committees) design things, large groups of people trying to decide things
is not the best thing. It can have detrimental effects on the protocol. I appreciate everything you are doing Solderpunk, because it's important.

And to everyone else, I would say, don't be afraid to design your own protocols. Competition is a good thing, and your ideas/goals are very likely to be different from
anybody else's.

I also want to announce that with recent developments in Gemini, I'm *very* excited for it now, and I will be focusing more on Gemini development in the future.
I don't think I ever announced my Gemini server (gemini://pon.ix.tc) on here, so I'm announcing it now. I have some ideas of things I want to do, so watch out for these.

Christian Seibold

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200615/9a1701e9/attachment.htm>

From pitr.vern at gmail.com  Mon Jun 15 19:10:03 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Mon, 15 Jun 2020 20:10:03 +0200
Subject: gemini servers and "frameworks"?
In-Reply-To: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
References: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
Message-ID: <CAG-mZ3juwo25175-2HRXbZz=Y3bFP1mkC8LgvSqy=2QqDrrGxw@mail.gmail.com>

I?ve recently announced my go framework that I?ve been using for all my
servers
https://github.com/pitr/gig I don?t think it?s listed on the official
website. It supports dynamic routes and lots of helpers to make writing
Gemini apps quickly. Ultimately a Gemini framework would be very similar to
a web framework, where you declare a route like ?/user/:name? and the
framework would extract that part from the url and pass it to your handler.

On Mon, Jun 15, 2020 at 19:40 Alex Ellis <apellis at gmail.com> wrote:

> I'm new to Gemini, and I've started implementing a gemini server. Is there
> a list of gemini server projects (as in serving software, not live servers
> that are serving content)? I'm interested in seeing how others handle
> dynamic routes. Are there any projects yet implementing gemini "frameworks"
> (a la python's Flask for web)?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200615/339d0a76/attachment.htm>

From colecmac at protonmail.com  Mon Jun 15 19:53:49 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 15 Jun 2020 18:53:49 +0000
Subject: Thoughts on TOFU
In-Reply-To: <20200615073231.GA16765@SDF.ORG>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
 <20200615073231.GA16765@SDF.ORG>
Message-ID: <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>

> I would love to! And I have loads of ideas on this front.

Happy to hear it! Let's do this :)

> I do think that "controlling how servers use certs" is [a good idea]

This is probably the only way forward, but unfortunately it complicates things.
It makes Gemini less simple, because people can't stick to what they
know about certs, or just use the existing one they have for their domain.
I guess we just have to try and get servers to support this and abstract it
away.

> -   Servers can sign their new cert with their previous private key.
>     Then TOFU clients which accepted the previous cert can validate the
>     changeover - and then immediately stop trusting the previous cert so
>     that anybody who stole the private key can't sign their own new cert.
>     Basically, when you accept a new cert you also grant it one-use-only,
>     very-limited-scope CA powers.

BLoCkcHaiN style, nice ;)
This does mean that servers would have to serve up an ever growing certificate
chain though? I think? Because otherwise how can a client verify that it was signed.

I guess the servers only need to serve up two certs, the previous and current, but
if I boot up my client after a year, then how does it know whether it just has missed
some certs in between, or if there's an MITM attack?

> -   Servers can generate their new self-signed cert N months in advance
>     and, for those N months, advertise the hash of the new cert at a
>     well-known endpoint, access to which is secured by the current cert.
>     TOFU clients can notice when an accepted cert is close to expiry and
>     pre-fetch the future fingerprint.

The problem is still like what if I miss a cert? Like if my client got cert 1 and
the hash of cert 2, but by the time I come back online, that site is serving cert 3
and I don't know whether that's one I should trust or not.

> -   Servers can use DANE (RFC6698) to advertise their self-signed cert
>     over DNS, and TOFU clients can check this when receiving an unrecognised
>     cert. LOTS of details to discuss here re: DNS security.

DANE seems cool, I want to look into it more. But it will complicate things, and then
there's DNSSEC, etc etc. I'm guessing it should be avoided for now.

> -   We could built Perspectives/Convergence style "notary" servers that
>     TOFU clients clients can consult when receiving an unrecognised cert.
>     This was an idea that was developed before it's time, IMHO. Today there
>     is no reason that achieving broad network perspective requires trusted
>     third parties and an effective "shadow infrastructure" alongside CAs.
>     Just run your own certificate observatory on a dirt cheap VPS. Share it
>     with friends, who share theirs with you. Pubnixes can run then for
>     their users. Unlike some of the other ideas, this works just as nicely
>     with CA-signed certs (like those from Let's Encrypt) as self-signed
>     certs.

This seems cool, and I want to learn more. How is conflict resolution handled?
Doesn't this need bootstrapping? It could be a good solution, but still will
complicate the protocol a lot.


I feel somewhat unsure about the problems I raised here btw, please correct me if
I've made any mistakes.

makeworld

??????? Original Message ???????
On Monday, June 15, 2020 3:32 AM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Sun, Jun 14, 2020 at 11:09:05PM +0000, colecmac at protonmail.com wrote:
>
> > Solderpunk, I'd appreciate if we could work towards some general solution for this,
> > and official recommendations for how to handle TOFU and cert renewal.
>
> I wouldlove to! And I have loads of ideas on this front. I've just
> never had the time to write anything substantial on them because there
> is always some more urgent matter popping up, like surprise auto-cookies
> or people wanting to add upload capabilities. If things ever settle
> down (tonight I will make official the spec changes I recently asked for
> feedback on and then freeze the thing again, perhaps that will help) we
> can tackle this.
>
> > I'm not sure what to do about this. Both options seem bad, and both will cause
> > breakage. It seems that there is no good way to do TOFU with certs, unless
> > you want to try and control how servers use certs, like specifying that keypairs
> > should not change or something.
>
> I don't think that keeping the same keypair forever is a good idea, but
> I do think that "controlling how servers use certs" is. Without CAs
> in the picture it's trivial to automate cert changes, which makes this
> easy. I also think that pushing Gemini servers to use the smallest
> certs they can (i.e. not RSA) is a good idea to reduce TLS overhead,
> which is another reason for people to take control of their own
> certificate generation.
>
> Quick sketches:
>
> -   Servers can sign their new cert with their previous private key.
>     Then TOFU clients which accepted the previous cert can validate the
>     changeover - and then immediately stop trusting the previous cert so
>     that anybody who stole the private key can't sign their own new cert.
>     Basically, when you accept a new cert you also grant it one-use-only,
>     very-limited-scope CA powers.
>
> -   Servers can generate their new self-signed cert N months in advance
>     and, for those N months, advertise the hash of the new cert at a
>     well-known endpoint, access to which is secured by the current cert.
>     TOFU clients can notice when an accepted cert is close to expiry and
>     pre-fetch the future fingerprint.
>
> -   Servers can use DANE (RFC6698) to advertise their self-signed cert
>     over DNS, and TOFU clients can check this when receiving an unrecognised
>     cert. LOTS of details to discuss here re: DNS security.
>
> -   We could built Perspectives/Convergence style "notary" servers that
>     TOFU clients clients can consult when receiving an unrecognised cert.
>     This was an idea that was developed before it's time, IMHO. Today there
>     is no reason that achieving broad network perspective requires trusted
>     third parties and an effective "shadow infrastructure" alongside CAs.
>     Just run your own certificate observatory on a dirt cheap VPS. Share it
>     with friends, who share theirs with you. Pubnixes can run then for
>     their users. Unlike some of the other ideas, this works just as nicely
>     with CA-signed certs (like those from Let's Encrypt) as self-signed
>     certs.
>
>     Cheers,
>     Solderpunk
>



From colecmac at protonmail.com  Mon Jun 15 20:02:22 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 15 Jun 2020 19:02:22 +0000
Subject: [SPEC-CHANGE] Simplified client certs, URI scheme, alt text
In-Reply-To: <20200615161317.GF20393@SDF.ORG>
References: <20200615161317.GF20393@SDF.ORG>
Message-ID: <Xff6InGzZiX9m3u-SrWAdK7tD4xQzzPnTtIvjN7SqZnSy7HXUC7SOsQqGypIDecs5cYJGRtxP8Qtvy30UVPbFMi3kjH4VOEBCmJsRT1s1aA=@protonmail.com>

Sounds good! Can this be updated on the website?

makeworld

??????? Original Message ???????
On Monday, June 15, 2020 12:13 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> Ahoy, Geminauts!
>
> I have just made the proposed spec changes that I asked for comment on
> over the just past weekend official.
>
> SUMMARY OF CHANGES:
>
> -   A gemini:// URI scheme is formally defined for the first time,
>     explicitly disallowing the use of the userinfo subcomponent of the
>     authority component.
>
> -   The client certificate system has been substantially simplified, with
>     transient certificates no long a formally defined concept with
>     prescribed behaviour.
>
> -   A lightweight notion of alt text for pre-formatted content has been
>     introduced as a tentative step toward fixing the worst search and
>     accessibility related problems with pre-formatted non-textual content.
>     No special structures or semantics for alt text are defined - if a
>     convention for doing this organically arises in the community it may
>     become a recommended best practice.
>
> -   A few minor corrections and tidyups.
>
>     IMPLICATIONS FOR SERVER AUTHORS:
>
>     Servers SHOULD return status 59 (BAD REQUEST) if they receive a request
>     for a gemini:// URL containing a userinfo subcomponent. If you really
>     want to be hyper-Postelian, you MAY instead strip out the userinfo so
>     that, for example, it does not end up in logs, is not passed to CGI
>     apps, etc.
>
>     IMPLICATIONS FOR CLIENT AUTHORS:
>
>     Clients should either refuse to follow gemini:// links with userinfo
>     subcomponents, or should strip out the userinfo before following the
>     link.
>
>     Clients with support for client certificates should adapt to the new
>     simplified specification, which may involve e.g. removing support for
>     the deprecated status code 21.
>
>     Clients may do something with alt text. This is probably most relevant
>     to search engines and accessibility-focussed clients, but I suppose e.g.
>     graphical clients may wish to support web browser style hover over
>     display. Strictly optional in all cases.
>
>     IMPLICATIONS FOR CONTENT AUTHORS:
>
>     If you have authored content which includes gemini:// links with
>     userinfo subcomponents, you MUST remove the userinfo.
>
>     You may wish to add alt text to preformatted content which is not
>     meaningfully screen readable or search engine indexable.
>
>     Cheers,
>     Solderpunk
>



From colecmac at protonmail.com  Mon Jun 15 20:04:32 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 15 Jun 2020 19:04:32 +0000
Subject: gemini servers and "frameworks"?
In-Reply-To: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
References: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
Message-ID: <A-PwrGXGbpafR6JY7QMXIzGgVcp4NiOqxGtrw4Av8ZlPbje0CwAZg9xyyXvAU8C6g-Ta1X2DIB8E5288RRE0HKuu8MEDrBqaoApGj3cKGxE=@protonmail.com>

Jetforce and net-gemini also offer frameworks in Python and Go respectively.

https://github.com/michael-lazar/jetforce
https://github.com/jackdoe/net-gemini

makeworld

??????? Original Message ???????
On Monday, June 15, 2020 1:40 PM, Alex Ellis <apellis at gmail.com> wrote:

> I'm new to Gemini, and I've started implementing a gemini server. Is there a list of gemini server projects (as in serving software, not live servers that are serving content)? I'm interested in seeing how others handle dynamic routes. Are there any projects yet implementing gemini "frameworks" (a la python's Flask for web)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200615/a3288b06/attachment.htm>

From solderpunk at SDF.ORG  Mon Jun 15 20:25:11 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 19:25:11 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <alpine.NEB.2.21.2006151714240.17060@otaku.sdf.org>
References: <alpine.NEB.2.21.2006151714240.17060@otaku.sdf.org>
Message-ID: <20200615192511.GA2293@SDF.ORG>

On Mon, Jun 15, 2020 at 05:28:46PM +0000, Pete D. wrote:
 
> In this www-reprise model, lots of extra stuff is being proposed, it seems
> to me, and at some point, one has to ask, why not use http if you are going
> to decorate with all the http things?

Perhaps the biggest current gap in the Gemini FAQ is a response to "Why
are you bothering to create something new for this, don't you realise
you can just use a subset of HTTP and a subset of HTML?!".  It's a fair
question.  It's not like I'm not aware of the possibility - I wrote my
"non-violent webserver" Shizaru
(https://tildegit.org/solderpunk/shizaru/) before starting Gemini.

I have thought about this a lot, and I *do* think there is a point to
creating something new, but I can't express it in a short, sharp form
yet.  I'm working on it.

That said, I think there would be plenty of interest and energy around a
kind of "back to basics" web movement.  People are really getting sick
and tired of the mainstream web and are looking for escapes and
alternatives.  For many, that's Gopher.  Gemini was started in large
part out of a feeling that many people who *wanted* to escape, perhaps
badly, would not see Gopher as an adequate refuge.  I hope for some it is.
For some it still may not be, and some kind of minimalist subset of the
web might be better.

> And so now, seeing all this wiki talk, I'm excited again by the idea of a
> wiki protocol, but at the same time, I feel like it really should be a
> different project. It's not what gemini is.

I hope that even for people who disagree strongly with design decisions
I've made for Gemini can look to it as a source of hope and empowerment.
No matter how bad the mainstream internet experience gets and how
hopeless it may seem, the clean slate of TCP/IP is always there and you
can build whatever you want on top of it.  Something which is "just an
idea" can always turn into "a thing" if you can convince enough people
that it's a good idea.  The internet is magic and malleable and has
plenty of room for all sorts.  Build things that make you happy!

Cheers,
Solderpunk

From mbrubeck at limpet.net  Mon Jun 15 20:37:58 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Mon, 15 Jun 2020 12:37:58 -0700
Subject: gemini servers and "frameworks"?
In-Reply-To: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
References: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
Message-ID: <CAD1=23=pLBcLdVCV=2OBZWFfnz4NL5Q=p3yNwvraPUKZNvLESw@mail.gmail.com>

There?s a list of server software at
gemini://gemini.circumlunar.space/software/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200615/0f6a50f2/attachment.htm>

From solderpunk at SDF.ORG  Mon Jun 15 21:34:36 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 15 Jun 2020 20:34:36 +0000
Subject: [SPEC-CHANGE] Simplified client certs, URI scheme, alt text
In-Reply-To: <Xff6InGzZiX9m3u-SrWAdK7tD4xQzzPnTtIvjN7SqZnSy7HXUC7SOsQqGypIDecs5cYJGRtxP8Qtvy30UVPbFMi3kjH4VOEBCmJsRT1s1aA=@protonmail.com>
References: <20200615161317.GF20393@SDF.ORG>
 <Xff6InGzZiX9m3u-SrWAdK7tD4xQzzPnTtIvjN7SqZnSy7HXUC7SOsQqGypIDecs5cYJGRtxP8Qtvy30UVPbFMi3kjH4VOEBCmJsRT1s1aA=@protonmail.com>
Message-ID: <20200615203436.GB2293@SDF.ORG>

Whoops, sorry!  I totally forgot that's a seprate process now, since the
reformatting of the spec to actually be a text/gemini document!  It's
done now, thanks for the reminder.

Cheers,
Solderpunk

On Mon, Jun 15, 2020 at 07:02:22PM +0000, colecmac at protonmail.com wrote:
> Sounds good! Can this be updated on the website?
> 
> makeworld

From sean at conman.org  Mon Jun 15 21:49:37 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 15 Jun 2020 16:49:37 -0400
Subject: gemini servers and "frameworks"?
In-Reply-To: <A-PwrGXGbpafR6JY7QMXIzGgVcp4NiOqxGtrw4Av8ZlPbje0CwAZg9xyyXvAU8C6g-Ta1X2DIB8E5288RRE0HKuu8MEDrBqaoApGj3cKGxE=@protonmail.com>
References: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
 <A-PwrGXGbpafR6JY7QMXIzGgVcp4NiOqxGtrw4Av8ZlPbje0CwAZg9xyyXvAU8C6g-Ta1X2DIB8E5288RRE0HKuu8MEDrBqaoApGj3cKGxE=@protonmail.com>
Message-ID: <20200615204936.GW11281@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> Jetforce and net-gemini also offer frameworks in Python and Go respectively.
> 
> https://github.com/michael-lazar/jetforce
> https://github.com/jackdoe/net-gemini

  GLV-1.12556 provides a framework in Lua.

	https://github.com/spc476/GLV-1.12556

  -spc

From pitr.vern at gmail.com  Mon Jun 15 22:01:03 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Mon, 15 Jun 2020 23:01:03 +0200
Subject: [ANN] Egsam - A new client torture tester
In-Reply-To: <20200613225303.GN11281@brevard.conman.org>
References: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>
 <20200613225303.GN11281@brevard.conman.org>
Message-ID: <CAG-mZ3iVQaWW0T1dXZydL-_n9xa2-fgbaS4urd2fTXhzP5q2vg@mail.gmail.com>

Hopefully my announcement was not taken as a jab at the original
torture tests. I have used your test suite extensively when building
my client, and it made my life easier.

If we can come up with a way to merge the two, I would love it.

On Sun, Jun 14, 2020 at 12:53 AM Sean Conner <sean at conman.org> wrote:
>
> It was thus said that the Great Peter Vernigorov once stated:
> > Pronounced egg-sam :)
> >
> > Building my client, I noticed that there were edge cases that I wanted
> > to test but was not able to.
>
>   You should have said something, I could have added most to my Gemini
> Client Torture Test [1].
>
> > Hopefully this is useful to others
> > building clients as well. I broke up the spec into sections and tested
> > each one individually. At the end you get a score!
>
>   It's cool that there's very little overlap between our two test sets.
> It's not cool that I seem to have been a bit slack in coming up with tests.
> Sigh.
>
>   I also like the organization scheme you came up with.
>
>   -spc
>
> [1]     gemini://gemini.conman.org/test/torture/

From pitr.vern at gmail.com  Mon Jun 15 23:11:35 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 16 Jun 2020 00:11:35 +0200
Subject: CSRF in Gemini
In-Reply-To: <c612dd1d-8d81-625e-84eb-e4cc7f94fe33@masterq32.de>
References: <20200615160947.06cc84f8@phi>
 <c612dd1d-8d81-625e-84eb-e4cc7f94fe33@masterq32.de>
Message-ID: <CAG-mZ3juGAxLYb8wBmiJpaCFh=xiT0gtmef4-GqTnRNn7UbhEA@mail.gmail.com>

This type of attack impacts more than just endpoints that rely on
query parameter. For example, one can delete their astrobotany plant
simply by getting redirected to /app/plant/harvest/confirm (although
that is not strictly deletion). If a certificate is already activated
for this site, then this will not help stop the attack.

However, the difference I see between HTTP/HTML and Gemini is that
this attack is not happening in an invisible iframe/xhr request, but
in plain sight of the user. Once they are redirected to any of the
impacted pages, they will see a message from server informing them of
their actions. "you posted a comment", "you harvested/deleted your
plant". Perhaps an easy workaround is to let user undo their action?
"you posted a comment, would you like to undo?" This has an additional
positive side effect of an easy undo of human errors, in case the
comment was submitted prematurely, or contains an error.

On Mon, Jun 15, 2020 at 5:05 PM Felix Quei?ner <felix at masterq32.de> wrote:
>
> Hey!
>
> > I just wrote down a few thoughts about cross-site request forgery in Gemini:
>
> Good read! I thought about that as well?
>
> >> CSRF protection via non-native nonces is ugly, can we do better than
> >> the web?
> I think one solution would be to force clients to remove queries from
> all URLs. It's not a really elegant solution and makes CGI stuff harder
> to implement, but will prevent a lot of URL-fuckery. I'm also always
> scared when clicking links in interactive things, because double
> postings are really easy to achieve with the query appended to URLs.
> Hitting refresh in your browser to see new posts? You create a new post
> in the guestbook!
>
> While writing this, i got the following idea (which seams reasonable to me):
> Specify that a response to INPUT MUST be passed with a query-parameter
> "?input=?" where "?" is the data from the user. The data is fully
> urlencoded with all forbidden characters(space,?,=,?) replaced with
> their percent-encoding.
>
> Also specify that clients SHOULD remove the "input"-parameter between
> redirects and in documents using the gemini-scheme.
>
> This allows us to prevent passing accidential or malicious data via
> redirects, but doesn't help against a spam-bot that targets a site
> directly. It also makes client implementation a bit harder.
>
> Regards
> - xq

From felix at masterq32.de  Mon Jun 15 23:37:34 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 16 Jun 2020 00:37:34 +0200
Subject: TOFU Tester
Message-ID: <26ba1cf9-b631-f7e5-5e9f-6572a9c96aac@masterq32.de>

Hello, people of gemspace!

I have created a small, new service for you all!

=> gemini://tofu-tester.random-projects.net:1966/

The mighty TOFU Tester!

Well, it's actually just gemserv that is restarted every 5 minutes with
a new certificate, alternating between an EC and an RSA key pair.

This should allow you to test your clients server-certificate handling
pretty easily!

Regards
- xq

From sean at conman.org  Tue Jun 16 02:05:55 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 15 Jun 2020 21:05:55 -0400
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200615095121.GA20393@SDF.ORG>
References: <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org> <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG> <20200615095121.GA20393@SDF.ORG>
Message-ID: <20200616010555.GY11281@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> On Mon, Jun 15, 2020 at 07:39:01AM +0000, solderpunk wrote:
> > On Sun, Jun 14, 2020 at 10:06:11PM +0100, Luke Emmet wrote:
> >  
> > > I think this is a great idea! It would go quite a long way to supporting
> > > collaborative editing. And as you say it is infrastructure we already have.
> > 
> > I'm glad you think so!  I hope other people who were keen on an upload
> > mechanism are too.  As you point out there are small details to smooth
> > over for the wiki case; but for simple "publishing for the masses"
> > where the starting state is a blank page, doesn't this basically get us
> > there?
> 
> An interesting idea which was just floated on the BBS at the Zaibatsu
> pubnix, inspired by the "friSBEe" project started by cmmcabe (admin of
> gemini://rawtext.club), is the possibility of publishing via email.
> Typical text/gemini content is certainly small enough to be "uploaded" as
> an attachment (it can't really travel in the body of an email due to
> restrictions on line length).

  As someone who runs their own email server [1], and set up my blog to
accept posts via email [2], I think I'm in a unique position to comment
credibly on this topic.

  It's a good idea, but there are issues to consider.  When I first added
email support to my blogging engine (back in 2001, 2002?) I often wondered
why no other blogging engine copied the idea.  I mean, the user can use
their own proferred method of editing, and email clients exist for just
about everything under the sun, but no.  That feature remains a very niche
feature, and I think I finally figured out why---NO ONE BLODDY WELL RUNS
THEIR OWN EMAIL SERVER ANYMORE! [3]

  Ahem.  Sorry.

  But it's true.  Due to a lot of reasons I outlined in another email,
running a server is a pain, and email is especially painful because of all
the *other* things you have to do in addition to running an SMTP server. 
Now, aside the usual problem when running a server for a well known service,
I will say that setting up a "receive-only" email server (for the express
purpose of updating content) is vastly easier than a "full service email
server", so that's a positive.

  The next issue is hooking up the processing into the email server.  This
is not really an issue as any MTA (Postfix is great, there are others, but
trust me on this---avoid sendmail [4] at all costs) can do this.  The MTA I
use makes this trivial---just add an entry to /etc/aliases that looks like:

localaddress: "|/program/to/handle -option1 -option2"

  Done.

  Now the issue becomes one of validating the email.  The scheme I use for
my blog is not secure [5] but it hasn't been broken yet, mainly because it's
not worth the trouble to thwart it.  I use a special email address that's
never been published, and there are some checks I make on the incoming
email but nothing bullet-proof.  The program then knows how to add the entry
to my blog, but subsequent changes tend to require manual editing of the
file on the server [6].  

  Then you have to decide how the email is to be formatted for the system to
know what is being created, updated, deleted, etc.  I include the required
information (author, title, date, etc) of the post in the email body [7] and
as such, it's again, not bullet-proof since I'm the only one using it, so I
know what I can and can't do (and even then, I've been bitten by typos I've
made---sigh).  

  The relevant limits for SMTP is in RFC-5321, and are:

	1,000 bytes per line
	65,536 bytes maximum message size

  Of course, a server can support larger limits than these (and I would
suspect modern systems do, but I haven't tested this).  I've never had an
issue with sending posts, but then rarely do I have lines longer than 1,000
bytes [8].

  To address security concerns, some of the things that *could* be done
include:

	Use a custom email to accept emails, perhaps a custom one per user.

	Check the From: or Sender: header, do a DNS MX lookup on the domain
	portion, and cross reference that with the Received: headers.

	Check the DKIM-Signature: header (if it exists).

	Dive into the rabbit hole that is PGP.

  So that's my two-bits worth on this topic.  Good idea, but quite a bit of
work involved.

  -spc

[1]	Of course I would.

[2]	Of course I did.

[3]	Well, almost no one.

[4]	It is a nightmare.  The last time I worked with sendmail, the
	configuration file had a configuration file (I kid you not) and it's
	been the enevitable Swiss Cheese of secure programs over its entire
	history.

[5]	This is probably a mistake to announce on a public list, but I am
	aware of the ramifications of doing so.

[6]	I do not have a way to handle a modification of an existing entry
	via email, but that's a limitiation I have, not to the idea as a
	whole.

[7]	I could use email headers for some of this, but I was lazy at the
	time and found it easier to specify in the body.

[8]	The technique I use these days is to have a sentance fragment per
	line.  This allows me easier editing while composing the entry. 
	Here's a sample of the first two paragraphs of my reply written in
	this style.

As someone who runs their own email server [1],
and set up my blog to accept posts via email [2],
I think I'm in a unique position to comment credibly on this topic.

It's a good idea,
but there are issues to consider.
When I first added email support to my blogging engine
(back in 2001, 2002?)
I often wondered why no other blogging engine copied the idea.
I mean,
the user can use their own proferred method of editing,
and email clients exist for just about everything under the sun,
but no.
That feature remains a very niche feature,
and I think I finally figured out why---NO ONE BLODDY WELL RUNS THEIR OWN EMAIL SERVER ANYMORE! [3]

From jmcbray at carcosa.net  Tue Jun 16 02:15:16 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 15 Jun 2020 21:15:16 -0400
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <5EE68E74.3040107@marmaladefoo.com> (Luke Emmet's message of
 "Sun, 14 Jun 2020 21:54:12 +0100")
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <34e5e030-ce9b-82da-b72a-cde45de171e8@masterq32.de>
 <20200614142615.GE363@SDF.ORG> <5EE68E74.3040107@marmaladefoo.com>
Message-ID: <874krbyfob.fsf@cassilda.carcosa.net>

Luke Emmet <luke at marmaladefoo.com> writes:

> Perhaps in this phase of the definition of Gemini, we should think of
> a potential user as our "significant others". Perhaps users who have
> an inclination to write and share their thoughts outside of the highly
> commercialised mainstream web. But certainly not an assumption they
> know what ssh, sftp or running your own linux server.
>
> What would these users need to assist them?

I'm bullish on native apps for this, which is part of why I'm not so
sold on the various editing/submission proposals. It really shouldn't be
that hard to wrap some existing tools like rsync+ssh behind a cute
native UI and provide a nice mobile editing experience.

Of course, I'm a known pervert, so I use Emacs in Termux on an Android
phone to update my gemlog, some of the time.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From sean at conman.org  Tue Jun 16 02:18:22 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 15 Jun 2020 21:18:22 -0400
Subject: gemini streaming
In-Reply-To: <c631f61b-0011-6fff-b662-5722fc68a281@lavabit.com>
References: <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613215024.GK11281@brevard.conman.org> <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG> <20200615095121.GA20393@SDF.ORG>
 <c631f61b-0011-6fff-b662-5722fc68a281@lavabit.com>
Message-ID: <20200616011822.GZ11281@brevard.conman.org>

It was thus said that the Great James Tomasino once stated:
> Since text/gemini (or gemtext, if that's what we're calling it) is
> parsable from top-to bottom in a single pass, it's also perfectly well
> suited to being treated as a stream instead of a document. I believe the
> only limitation to this currently is that many clients are expecting that
> gemtext is a document and are deferring parsing until the end-of-document
> is reached.
> 
> When I raised this question on the IRC channel I wanted to know if there
> was a way to indicate within the MIME perhaps that the resource is a
> stream and not a document. Then clients could know explicitly that they
> shouldn't be waiting on the end of document before parsing. I'm really not
> familiar with the technical mechanisms of how that's set up on HTTP, so I
> wanted to toss it to the list.

  A web browser already knows how it will deal with the content by the time
it's reading the body of the response, and unless the browser is going to
hand off the content to another program (say a PDF viewer) the browser can
just treat the resulting download of data as a stream.  TCP (the underlying
protocol for both HTTP and Gemini) provides a "reliable byte-oriented
stream" [1] and it's up to the client to deal with that as it sees fit.

  A Gemini client can see it's getting a text/gemimi file, and start reading
the network stream a line at a time and displaying it at the same time if it
so chooses.  It doesn't *have* to wait for the entire file to download
before processing it.

> Should we investigate a MIME solution to be explicit, or should clients
> treat all text/gemini as streams and just parse as they go? The later
> seems easier from a implementation standpoint. Someone raised the question
> about how the display should be handled between the two, though. Sometimes
> streams desire to keep the focus pinned to the newest content, not the
> start of the document. That sort of functionality would support using a
> separate explicit MIME or some other way to differentiate them.

  It depends how the client is written.  I client can certainly parse and
display a text/gemini as it receives it (much like web browsers can start
displaying partially downloaded content) but it complicates the codebase. 
Is it worth the tradeoff?  

> With streams in place we could do some very cool things. We could build a
> fediverse front-end, or a view into the IRC channel. If you use two tabs
> and a response 10 loop and client certs, you could even post INTO these
> platforms. Let your imagination run wild!

  Nothing stopping you now from doing that.  This no size parameter, a
Gemini client can continuously stream data to a client until the connection
is broken.

  -spc

[1]	Technically, TCP exists to manage the bandwidth between two
	endpoints, but it was engineers to also provide the said "reliable
	byte-oriented stream".  There are no packets to the client code,
	just a stream of bytes it has to read.

From sean at conman.org  Tue Jun 16 02:28:08 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 15 Jun 2020 21:28:08 -0400
Subject: CSRF in Gemini
In-Reply-To: <20200615160947.06cc84f8@phi>
References: <20200615160947.06cc84f8@phi>
Message-ID: <20200616012808.GA11281@brevard.conman.org>

It was thus said that the Great Francesco Gazzetta once stated:
> Hi all,
> 
> I just wrote down a few thoughts about cross-site request forgery in
> Gemini:
> 
> gemini://gemini.circumlunar.space/~/fgaz/posts/2020-06-15-csrf-in-gemini/

  I read the article and I don't think this is that much of an issue with
Gemini.  It lacks javascript.  It lacks cookies.  It serverely limits the
data that can be posted.  Authentication is done via certificates.  About
the only valid issue is the SPAM issue you brought up, but I think it *is*
possible to detect since the server will have the IP address of the
sender---repeated requests could be blocked by blocking the IP address.

  Another issue with the nonce (other than how to send it back) is that a
malicious bot can just make a request that returns the nonce and use it,
like like a Gemini client with a human driver will do.

  It's an issue, but less of one than on the web.

  -spc


From sean at conman.org  Tue Jun 16 02:37:54 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 15 Jun 2020 21:37:54 -0400
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <alpine.NEB.2.21.2006151714240.17060@otaku.sdf.org>
References: <alpine.NEB.2.21.2006151714240.17060@otaku.sdf.org>
Message-ID: <20200616013754.GB11281@brevard.conman.org>

It was thus said that the Great Pete D. once stated:
> And so now, seeing all this wiki talk, I'm excited again by the idea of a 
> wiki protocol, but at the same time, I feel like it really should be a 
> different project. It's not what gemini is.
> 
> If we are turning this into a wiki protocol, why don't we have inline 
> links and all the cool markup available to make nice documents (TOCs, 
> etc), and versioning and all that?

  Sadly, that *is* HTTP.  HTTP/1.0 added the methods PUT and DELETE which
make adding/updating/removing resources from a webserver possible with just
a web client.  The methods map to:

	GET	Retrieve a resource, should be no side-effects on the server
	POST	Submit data to an existing resource
	PUT	Add a new resource (a file for example) to the server
	DELETE	Remove a resource (a file for example file) from the server

  The major difference between POST and PUT is that with POST, the resource
receiving the data isn't modified (it's a fixed endpoint) whereas with PUT,
the resource given is created or modified by the data.

  Of the complaints I've read online about Gemini, the question of "why not
use HTTP" comes up, and in a sense, I can see the reason for the
question---HTTP does *not* inherenetly imply spying and tracking but that
there are external forces that force that in the HTTP world.

  I still like the idea, but the trick is to tame (or limit) the damage that
can be done.

  -spc


From sean at conman.org  Tue Jun 16 02:50:49 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 15 Jun 2020 21:50:49 -0400
Subject: [ANN] Egsam - A new client torture tester
In-Reply-To: <CAG-mZ3iVQaWW0T1dXZydL-_n9xa2-fgbaS4urd2fTXhzP5q2vg@mail.gmail.com>
References: <CAG-mZ3iSKUkaE5sRwBHOPfiGKgvhw0EwcneZmZf4OLhRnJ+vJQ@mail.gmail.com>
 <20200613225303.GN11281@brevard.conman.org>
 <CAG-mZ3iVQaWW0T1dXZydL-_n9xa2-fgbaS4urd2fTXhzP5q2vg@mail.gmail.com>
Message-ID: <20200616015049.GC11281@brevard.conman.org>

It was thus said that the Great Peter Vernigorov once stated:
> Hopefully my announcement was not taken as a jab at the original
> torture tests. 

  No it wasn't.  And I was a bit surprised that our tests are quite
different in nature.

> I have used your test suite extensively when building
> my client, and it made my life easier.

  Cool.

> If we can come up with a way to merge the two, I would love it.

  I wouldn't mind, but I did write a special module for GLV-1.12556 to
handle the tests.  And I think you also wrote a custom server to handle the
tests as well.  

  This might require some thought ...

  -spc


From krixano at protonmail.com  Tue Jun 16 04:55:34 2020
From: krixano at protonmail.com (Krixano)
Date: Tue, 16 Jun 2020 03:55:34 +0000
Subject: Introducing YouTube Interface for Gemini
Message-ID: <nklDFGxfVvG-mY3i7JiT_M2FIGJxPyHgEIPVF6em6wAlBBF-goFRlWWKt5AQvlD6nkQXen9IpCIAMLmfVAA0j5pk7Hx-gm9JI38X5AF_te0=@protonmail.com>

I have completed most of what is necessary for a YouTube interface for Gemini!!!
It has a Search feature, Channel pages, Playlist pages, and Video pages. Video pages
will link to the YouTube url for that video.

You can view it here: gemini://pon.ix.tc:1965/cgi-bin/youtube.cgi

The next things I will be doing:
* Expose comments on their own pages so we can see video comments
* Experiment with the Certificate stuff so you can subscribe to YouTube Channels but
completely detached from the YouTube site's subs. I can then show recent videos from
your subs when using a certificate.
* Other useful video information like View Count, Like Count, Quality, Duration
* Related Videos List
* Direct video download?

Christian Seibold

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200616/03940745/attachment.htm>

From luke at marmaladefoo.com  Tue Jun 16 09:01:13 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 16 Jun 2020 09:01:13 +0100
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200616013754.GB11281@brevard.conman.org>
References: <alpine.NEB.2.21.2006151714240.17060@otaku.sdf.org>
 <20200616013754.GB11281@brevard.conman.org>
Message-ID: <5EE87C49.9010004@marmaladefoo.com>


On 16-Jun-2020 02:37, Sean Conner wrote:
> It was thus said that the Great Pete D. once stated:
>> And so now, seeing all this wiki talk, I'm excited again by the idea of a
>> wiki protocol, but at the same time, I feel like it really should be a
>> different project. It's not what gemini is.
>>
>    Sadly, that *is* HTTP.  HTTP/1.0 added the methods PUT and DELETE which
> make adding/updating/removing resources from a webserver possible with just
> a web client.  The methods map to:
>
> 	GET	Retrieve a resource, should be no side-effects on the server
> 	POST	Submit data to an existing resource
> 	PUT	Add a new resource (a file for example) to the server
> 	DELETE	Remove a resource (a file for example file) from the server
>
>    The major difference between POST and PUT is that with POST, the resource
> receiving the data isn't modified (it's a fixed endpoint) whereas with PUT,
> the resource given is created or modified by the data.

Yes at the moment we have implemented GET, but not POST. It turned out 
the other verbs (PUT, DELETE) are not really essential as they can 
usually be implemented via POST, certainly for user facing applications. 
So I don't think there is a need to get side tracked by those.

As far as I understand it GET is supposed to be for persistent resources 
that are more or less idempotent. It shouldn't really be used as a 
vehicle to update a system, as the URLs are shareable and linkable 
(hence the potential SPAM problem of having a million pre-configured 
links to post comments whenever a search engine crawls your page).

Unfortunately we don't have any equivalent to POST. I do think this is a 
weakness and would be pleased to understand what the alternative in-band 
method is. SSH and SFTP is I know being recommended for some, but a) 
that is an out of band channel and wont be accessible to the majority of 
end users and b) limits the content to being file-system based.

We should not re-implement the web I agree, but there are a few things 
we should learn from that history and specify a constrained POST scheme 
that is not extendible.

>    Of the complaints I've read online about Gemini, the question of "why not
> use HTTP" comes up, and in a sense, I can see the reason for the
> question---HTTP does *not* inherenetly imply spying and tracking but that
> there are external forces that force that in the HTTP world.
>
>    I still like the idea, but the trick is to tame (or limit) the damage that
> can be done.

I think we just need to lock it down and keep it really simple, but good 
enough. Something like this:

scheme://domain/fixed-end-point?params
<here come the bytes...>
close connection

params should include path/content length/mime but not the content

We just need to bolt it down. There should be no _hidden_ state that the 
server can request (like cookies).

Seeing as gemini just does GET, we can have a single simple POST scheme 
that does nothing else

gemini:// (a perfect simple GET, not really extendible)
postscheme:// (a perfect simple POST, not really extendible)

Maybe in future PUT/DELETE but I dont think they're needed as a suitably 
configured end point can receive parameters to enact this. The web got 
by without it for almost all of its life, and is only used by some REST 
end points.

Best Wishes

  - Luke




From luke at marmaladefoo.com  Tue Jun 16 09:06:19 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 16 Jun 2020 09:06:19 +0100
Subject: Introducing YouTube Interface for Gemini
In-Reply-To: <nklDFGxfVvG-mY3i7JiT_M2FIGJxPyHgEIPVF6em6wAlBBF-goFRlWWKt5AQvlD6nkQXen9IpCIAMLmfVAA0j5pk7Hx-gm9JI38X5AF_te0=@protonmail.com>
References: <nklDFGxfVvG-mY3i7JiT_M2FIGJxPyHgEIPVF6em6wAlBBF-goFRlWWKt5AQvlD6nkQXen9IpCIAMLmfVAA0j5pk7Hx-gm9JI38X5AF_te0=@protonmail.com>
Message-ID: <5EE87D7B.9090103@marmaladefoo.com>


On 16-Jun-2020 04:55, Krixano wrote:
> I have completed most of what is necessary for a YouTube interface for 
> Gemini!!!
> It has a Search feature, Channel pages, Playlist pages, and Video 
> pages. Video pages
> will link to the YouTube url for that video.
>
> You can view it here: gemini://pon.ix.tc:1965/cgi-bin/youtube.cgi
>

Great work! If only there was a way to just link to the video without 
all the youtube website cruft!

Best Wishes

  - Luke

From krixano at protonmail.com  Tue Jun 16 09:43:26 2020
From: krixano at protonmail.com (Krixano)
Date: Tue, 16 Jun 2020 08:43:26 +0000
Subject: Introducing YouTube Interface for Gemini
In-Reply-To: <5EE87D7B.9090103@marmaladefoo.com>
References: <nklDFGxfVvG-mY3i7JiT_M2FIGJxPyHgEIPVF6em6wAlBBF-goFRlWWKt5AQvlD6nkQXen9IpCIAMLmfVAA0j5pk7Hx-gm9JI38X5AF_te0=@protonmail.com>
 <5EE87D7B.9090103@marmaladefoo.com>
Message-ID: <7yRLLqE5mhuk2PNfZxEO035D5MDVmcWpXcxXVApBo18fe_d3TerXA0d88DbsK9GUMukUYn5qNc0lz2DsKtgpnSMtarcSfYOluRhEML6nn-c=@protonmail.com>

Thanks!

Do you mean like a direct download link of the video? This is planned, but I'm not
sure how easy it is to do. I might be able to use youtube-dl and just redirect that
to the output of the cgi program, idk. I could also just try to look at youtube-dl's
code and use that.

If anybody can help with this, it'd be very much appreciated!
I'm gonna make a repo of this cgi program soon :)


Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Tuesday, June 16, 2020 3:06 AM, Luke Emmet <luke at marmaladefoo.com> wrote:

> On 16-Jun-2020 04:55, Krixano wrote:
>
> > I have completed most of what is necessary for a YouTube interface for
> > Gemini!!!
> > It has a Search feature, Channel pages, Playlist pages, and Video
> > pages. Video pages
> > will link to the YouTube url for that video.
> > You can view it here: gemini://pon.ix.tc:1965/cgi-bin/youtube.cgi
>
> Great work! If only there was a way to just link to the video without
> all the youtube website cruft!
>
> Best Wishes
>
> -   Luke



From fgaz at fgaz.me  Tue Jun 16 10:18:37 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Tue, 16 Jun 2020 11:18:37 +0200
Subject: Escaping in text/gemini
Message-ID: <20200616111837.04d372ec@phi>

Just after the feature freeze :) I remembered to post about this: is
there an official way to escape stuff in text/gemini?

For example in gemini://gemini-textboard.fgaz.me/thread/3 from post #37
onwards you can see that links, pre blocks, etc are all escaped with a
backslash, but the backslash appears in the output an is kinda ugly.

From fgaz at fgaz.me  Tue Jun 16 10:23:13 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Tue, 16 Jun 2020 11:23:13 +0200
Subject: CSRF in Gemini
In-Reply-To: <20200615143007.GE20393@SDF.ORG>
References: <20200615160947.06cc84f8@phi>
	<20200615143007.GE20393@SDF.ORG>
Message-ID: <20200616112313.454f1a28@phi>

On Mon, 15 Jun 2020 14:30:07 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> It's perhaps a little bit tedious for users, but the simplest
> solution I can think of for things like this is a convention that all
> requests which trigger side-effects (like comments, etc.) must be
> made with a client certificate, because that will make it very clear
> to the user that something is happening and no surprises are possible.

Doesn't this imply that all requests with a client cert will have to be
confirmed by the user?

> I strongly suspect that completely preventing this kind of thing will
> be impossible if we simultaneously insist on a simple protocol and a
> frictionless user experience - in which case, everybody knows which
> one will be prioritised. :)  But if we can somehow pull off both at
> once that will be best.

Of course, which is why I wrote

> But this would require a separator, and we all know where this leads.

:)

Still, I don't think this is a matter of frictionless user experience,
more like... developer ux? Unless we find something simpler than nonces.

From felix at masterq32.de  Tue Jun 16 10:26:57 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 16 Jun 2020 11:26:57 +0200
Subject: Escaping in text/gemini
In-Reply-To: <20200616111837.04d372ec@phi>
References: <20200616111837.04d372ec@phi>
Message-ID: <2d579d1e-4b8d-9eba-7e22-5adaf0b59f6c@masterq32.de>



On 16.06.20 11:18, Francesco Gazzetta wrote:
> Just after the feature freeze :) I remembered to post about this: is
> there an official way to escape stuff in text/gemini?
> 
> For example in gemini://gemini-textboard.fgaz.me/thread/3 from post #37
> onwards you can see that links, pre blocks, etc are all escaped with a
> backslash, but the backslash appears in the output an is kinda ugly.

I think the escaping is done pretty easily: Prefix your lines with a
single space.

Gemini requires you to have line identifiers to be at the very start of
a line, so prefixing the line with a single space should escape the line
itself.

I've made a simple test file [0] for that, Kristall strips of leading
spaces in pretty much all text except preformatted one to make a nice
text rendering. You can see a "reference" rendering in [1].

Regards
- xq

[0] gemini://random-projects.net/torture/0007.gemini
[1] https://mq32.de/public/6b626fd8070b6aba9fa3add94d85d7209592acfd.png

From fgaz at fgaz.me  Tue Jun 16 10:29:12 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Tue, 16 Jun 2020 11:29:12 +0200
Subject: CSRF in Gemini
In-Reply-To: <c612dd1d-8d81-625e-84eb-e4cc7f94fe33@masterq32.de>
References: <20200615160947.06cc84f8@phi>
 <c612dd1d-8d81-625e-84eb-e4cc7f94fe33@masterq32.de>
Message-ID: <20200616112912.3f28c5b0@phi>

On Mon, 15 Jun 2020 17:05:33 +0200
Felix Quei?ner <felix at masterq32.de> wrote:

> I think one solution would be to force clients to remove queries from
> all URLs. It's not a really elegant solution and makes CGI stuff
> harder to implement, but will prevent a lot of URL-fuckery.

That coul be a good and clean solution, if we get microbotany, gus, etc
to move the stuff they put in the query to a path fragment. Too bad
this means that it's no longer possible to use cgi for that stuff.

> While writing this, i got the following idea (which seams reasonable
> to me): Specify that a response to INPUT MUST be passed with a
> query-parameter "?input=?" where "?" is the data from the user. The
> data is fully urlencoded with all forbidden characters(space,?,=,?)
> replaced with their percent-encoding.
> 
> Also specify that clients SHOULD remove the "input"-parameter between
> redirects and in documents using the gemini-scheme.

Less clean, but preserves cgi functionality and it's stateless! I like
this

> This allows us to prevent passing accidential or malicious data via
> redirects, but doesn't help against a spam-bot that targets a site
> directly. It also makes client implementation a bit harder.

Eh, the spam problem is a problem on its own anyway, and I probably
should have made a different example in my article.

From fgaz at fgaz.me  Tue Jun 16 10:35:20 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Tue, 16 Jun 2020 11:35:20 +0200
Subject: CSRF in Gemini
In-Reply-To: <CAG-mZ3juGAxLYb8wBmiJpaCFh=xiT0gtmef4-GqTnRNn7UbhEA@mail.gmail.com>
References: <20200615160947.06cc84f8@phi>
 <c612dd1d-8d81-625e-84eb-e4cc7f94fe33@masterq32.de>
 <CAG-mZ3juGAxLYb8wBmiJpaCFh=xiT0gtmef4-GqTnRNn7UbhEA@mail.gmail.com>
Message-ID: <20200616113520.524580ec@phi>

On Tue, 16 Jun 2020 00:11:35 +0200
Peter Vernigorov <pitr.vern at gmail.com> wrote:

> This type of attack impacts more than just endpoints that rely on
> query parameter. For example, one can delete their astrobotany plant
> simply by getting redirected to /app/plant/harvest/confirm (although
> that is not strictly deletion). If a certificate is already activated
> for this site, then this will not help stop the attack.

I think that's also a different problem. Such endpoints should IMO
require input from the user, like "Type yes to confirm". Or there could
be an additional 1x code for requesting a simple yes/no confirmation.
This code could easily fallback to 10, by having the buttons send "yes"
or "no" and the question say "Do you confirm? Type yes/no".

> However, the difference I see between HTTP/HTML and Gemini is that
> this attack is not happening in an invisible iframe/xhr request, but
> in plain sight of the user. Once they are redirected to any of the
> impacted pages, they will see a message from server informing them of
> their actions. "you posted a comment", "you harvested/deleted your
> plant". Perhaps an easy workaround is to let user undo their action?
> "you posted a comment, would you like to undo?" This has an additional
> positive side effect of an easy undo of human errors, in case the
> comment was submitted prematurely, or contains an error.

Undo is not always easy to implement though (strawman: you launched a
nuclear missile. undo?), and one has to remember to do it for every
page, much like remembering to escape string-concatenated sql
statements.

From fgaz at fgaz.me  Tue Jun 16 10:40:11 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Tue, 16 Jun 2020 11:40:11 +0200
Subject: CSRF in Gemini
In-Reply-To: <20200616012808.GA11281@brevard.conman.org>
References: <20200615160947.06cc84f8@phi>
 <20200616012808.GA11281@brevard.conman.org>
Message-ID: <20200616114011.73f2c51b@phi>

On Mon, 15 Jun 2020 21:28:08 -0400
Sean Conner <sean at conman.org> wrote:

> Authentication is done via
> certificates.

But unless confirmation is required for _every_ request with a
certificate (is it? I'll have to re-read the spec) then the problem
persists, since the request is done by the victim.

> About the only valid issue is the SPAM issue you
> brought up, but I think it *is* possible to detect since the server
> will have the IP address of the sender---repeated requests could be
> blocked by blocking the IP address.

It's not detectable without nonces, because the spammer doesn't have to
do any request, only the victims (with presumably different IPs)

>   Another issue with the nonce (other than how to send it back) is
> that a malicious bot can just make a request that returns the nonce
> and use it, like like a Gemini client with a human driver will do.

Yes, but like in the web we can act on that first request an check for
client cert (which the attacker won't have) and IP (which will always
be the attacker's one)

From defdefred at protonmail.com  Tue Jun 16 10:47:16 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 16 Jun 2020 09:47:16 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200616010555.GY11281@brevard.conman.org>
References: <5EE48DCA.2040706@marmaladefoo.com>
 <20200613215024.GK11281@brevard.conman.org> <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG> <20200615095121.GA20393@SDF.ORG>
 <20200616010555.GY11281@brevard.conman.org>
Message-ID: <S8ulQd-BzX_qr1fOHMFjR-VXoQpIfeSXdF_Zs7TAD7Kae1jgR4ZzkqddSeSNOUz8v8MZIGwgnlZ9IwpuIk0lGouoEZykpgPuk1krDFU3wRc=@protonmail.com>

On Tuesday 16 June 2020 03:05, Sean Conner <sean at conman.org> wrote:
> and I think I finally figured out why---NO ONE BLODDY WELL RUNS THEIR OWN EMAIL SERVER ANYMORE! [3]

No need to run a smtp server.
It is totally possible to fetch email from a external smtp server to achieve the same goal.

From defdefred at protonmail.com  Tue Jun 16 10:49:36 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 16 Jun 2020 09:49:36 +0000
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <37f6461b-7931-9f68-9405-22eb6acf9835@masterq32.de>
References: <20200613070556.GI11281@brevard.conman.org>
 <20200613215024.GK11281@brevard.conman.org> <20200613220734.GG18831@SDF.ORG>
 <2C817A43-1AD9-4011-A0EF-13264F0B75D5@gmail.com>
 <20200614150547.GF363@SDF.ORG> <5EE69143.503@marmaladefoo.com>
 <20200615073901.GC16765@SDF.ORG> <20200615095121.GA20393@SDF.ORG>
 <37f6461b-7931-9f68-9405-22eb6acf9835@masterq32.de>
Message-ID: <Wkew409vZEYkp9-hA7sB3chEx8SL3xII8zBtg3Tg3sEk9mjkJOlPQsGWoNMVCMnFLrf-yNkJ6m8uLUoK4g1zSfkwHSsZuQ186lYQxx8SMio=@protonmail.com>

On Monday 15 June 2020 18:11, Felix Quei?ner <felix at masterq32.de> wrote:
> Email sounds like a really nice solution! Using email as a
> human->machine interface is actually quite nice, but you need some kind
> of spoofing protection, but GPG solves that problem already.

PGP/GPG power!
The best way to authenticate writer allowed to publish in a mutualised geminispace.



From fgaz at fgaz.me  Tue Jun 16 11:33:34 2020
From: fgaz at fgaz.me (Francesco Gazzetta)
Date: Tue, 16 Jun 2020 12:33:34 +0200
Subject: Escaping in text/gemini
In-Reply-To: <2d579d1e-4b8d-9eba-7e22-5adaf0b59f6c@masterq32.de>
References: <20200616111837.04d372ec@phi>
 <2d579d1e-4b8d-9eba-7e22-5adaf0b59f6c@masterq32.de>
Message-ID: <20200616123334.53fb7f17@phi>

On Tue, 16 Jun 2020 11:26:57 +0200
Felix Quei?ner <felix at masterq32.de> wrote:

> I think the escaping is done pretty easily: Prefix your lines with a
> single space.

That could work if clients start stripping leading whitespace. I don't
know of any client that does this though.

> I've made a simple test file [0] for that, Kristall strips of leading
> spaces in pretty much all text except preformatted one to make a nice
> text rendering. You can see a "reference" rendering in [1].

The whitespace seems to still be there though:

https://framapic.org/jrL943673D6n/LaxAzkOCzEnL.png

From fkfd at macaw.me  Tue Jun 16 14:26:12 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Tue, 16 Jun 2020 13:26:12 +0000
Subject: gemini servers and "frameworks"?
In-Reply-To: <A-PwrGXGbpafR6JY7QMXIzGgVcp4NiOqxGtrw4Av8ZlPbje0CwAZg9xyyXvAU8C6g-Ta1X2DIB8E5288RRE0HKuu8MEDrBqaoApGj3cKGxE=@protonmail.com>
References: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
 <A-PwrGXGbpafR6JY7QMXIzGgVcp4NiOqxGtrw4Av8ZlPbje0CwAZg9xyyXvAU8C6g-Ta1X2DIB8E5288RRE0HKuu8MEDrBqaoApGj3cKGxE=@protonmail.com>
Message-ID: <ECEAD102-DEA3-4AA8-AD06-9B902C14C559@macaw.me>

On June 15, 2020 7:04:32 PM UTC, colecmac at protonmail.com wrote:
>Jetforce and net-gemini also offer frameworks in Python and Go
>respectively.
>
>https://github.com/michael-lazar/jetforce
Friendly reminder that Jetforce is under an unconventional license (Floodgap "Free" Software License), which may be a drawback from building dynamic applications with it (which indeed is mine).

~fkfd

From tastytea+gemini at tastytea.de  Tue Jun 16 14:35:03 2020
From: tastytea+gemini at tastytea.de (tastytea)
Date: Tue, 16 Jun 2020 15:35:03 +0200
Subject: Introducing YouTube Interface for Gemini
In-Reply-To: <7yRLLqE5mhuk2PNfZxEO035D5MDVmcWpXcxXVApBo18fe_d3TerXA0d88DbsK9GUMukUYn5qNc0lz2DsKtgpnSMtarcSfYOluRhEML6nn-c=@protonmail.com>
References: <nklDFGxfVvG-mY3i7JiT_M2FIGJxPyHgEIPVF6em6wAlBBF-goFRlWWKt5AQvlD6nkQXen9IpCIAMLmfVAA0j5pk7Hx-gm9JI38X5AF_te0=@protonmail.com>
 <5EE87D7B.9090103@marmaladefoo.com>
 <7yRLLqE5mhuk2PNfZxEO035D5MDVmcWpXcxXVApBo18fe_d3TerXA0d88DbsK9GUMukUYn5qNc0lz2DsKtgpnSMtarcSfYOluRhEML6nn-c=@protonmail.com>
Message-ID: <20200616153458.1b95fb62@ventiloplattform.tastytea.de>

On 2020-06-16 08:43+0000 Krixano <krixano at protonmail.com> wrote:

> Do you mean like a direct download link of the video? This is
> planned, but I'm not sure how easy it is to do. I might be able to
> use youtube-dl and just redirect that to the output of the cgi
> program, idk. I could also just try to look at youtube-dl's code and
> use that.

If you use `youtube-dl --get-url`, you often get separate URLs for the
video and the audio file. If you request a specific file extension
(with `youtube-dl --get-url --format=webm` for example), you get the
URL to a single file?.

Kind regards, tastytea

? <https://github.com/ytdl-org/youtube-dl/#format-selection>

-- 
Get my PGP key with `gpg --locate-keys tastytea at tastytea.de` or at
<https://tastytea.de/tastytea.asc>.

From jmcbray at carcosa.net  Tue Jun 16 16:12:22 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 16 Jun 2020 11:12:22 -0400
Subject: CSRF in Gemini
In-Reply-To: <20200615160947.06cc84f8@phi> (Francesco Gazzetta's message of
 "Mon, 15 Jun 2020 16:09:47 +0200")
References: <20200615160947.06cc84f8@phi>
Message-ID: <87lfknm4dl.fsf@dorothy.carcosa.net>

Francesco Gazzetta <fgaz at fgaz.me> writes:

>> CSRF protection via non-native nonces is ugly, can we do better than
>> the web?

My swimming-against the current proposal: all Gemini requests must be
idempotent. The easy way to make a request idempotent is to make it have
no side-effects.

Yes, this effectively limits Gemini to a document-delivery protocol, and
strictly constrains what apps could be built on top of it. That may not
be a bad thing.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Tue Jun 16 16:16:41 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 16 Jun 2020 11:16:41 -0400
Subject: gemini servers and "frameworks"?
In-Reply-To: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com> (Alex
 Ellis's message of "Mon, 15 Jun 2020 10:40:31 -0700")
References: <CADwRCm4fR3VrT4V71hrBMCAjE_59DDXPS6diKf9dCAbNF7f4Tw@mail.gmail.com>
Message-ID: <87h7vbm46e.fsf@dorothy.carcosa.net>

Alex Ellis <apellis at gmail.com> writes:

> I'm new to Gemini, and I've started implementing a gemini server. Is
> there a list of gemini server projects (as in serving software, not
> live servers that are serving content)? I'm interested in seeing how
> others handle dynamic routes. Are there any projects yet implementing
> gemini "frameworks" (a la python's Flask for web)?

Germinal doesn't yet, but it's planned for when I have a little more
time. 

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From solderpunk at SDF.ORG  Tue Jun 16 17:03:30 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 16 Jun 2020 16:03:30 +0000
Subject: CSRF in Gemini
In-Reply-To: <87lfknm4dl.fsf@dorothy.carcosa.net>
References: <20200615160947.06cc84f8@phi> <87lfknm4dl.fsf@dorothy.carcosa.net>
Message-ID: <20200616160330.GA10768@SDF.ORG>

On Tue, Jun 16, 2020 at 11:12:22AM -0400, Jason McBrayer wrote:
 
> My swimming-against the current proposal: all Gemini requests must be
> idempotent. The easy way to make a request idempotent is to make it have
> no side-effects.
> 
> Yes, this effectively limits Gemini to a document-delivery protocol, and
> strictly constrains what apps could be built on top of it. That may not
> be a bad thing.

I am leaning toward "all Gemini requests made without client
certificates should be idempotent" - stay tuned for *much* more detail
later tonight.  I have ideas which, I hope, will let us make people who
are only interested in a document-delivery protocol *and* hopeless nerds
who want to build apps happy, and even keep them out of each other's
hair to the extent that they want to be...

Cheers,
Solderpunk

From luke at marmaladefoo.com  Tue Jun 16 20:21:51 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 16 Jun 2020 20:21:51 +0100
Subject: HTTP/0.95 - the sweet spot or thereabouts?
Message-ID: <5EE91BCF.9080703@marmaladefoo.com>

Hi everyone

Just to toss a couple of things into the debate, for those interested in 
a minimal application capability for Gemini, but don't want all the 
bells, whistles and complexity of what the web became (cue scary music)

I did a bit of digging on the background history of HTTP. Maybe you are 
all familiar with this, but personally I found it quite illuminating on 
our conversation. If we are positioning Gemini between Gopher and the 
Web, we can decide where is the sweet spot along the spectrum.

https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP 


https://hpbn.co/brief-history-of-http/

HTTP 1.1 was the first fully standardised version, having an extensible 
structure, and many possible headers, cookies etc. However before that 
there were two pre-standardisation version that are quite interesting to 
look at.

== HTTP 0.9 ==

This was the very first version designed by Berners Lee. All it had was 
GET (sound familiar?)

Modulo the certificates/TLS stuff in Gemini, it is more or less what 
Gemini is right now.

If you just want idempotent resources and nothing else, this is all you 
need and is what we have in Gemini at the moment.

== HTTP 1.0 ==

This introduced two other methods HEAD (a GET with no response body) and 
POST which is for sending content to the server. It was still one 
connection per resource. It defined URL format, charsets and mime types 
and the idea of a header format and some standard headers 
(Content-Length, Date, Others).

It also defined a mechanism to create new arbitrary headers (we can get 
rid of that)

== HTTP 1.1 ==

The first fully standardised version that really took off and had a 
million different options including persistent connections, cookies and 
so on. This is too much for our needs and the extensibility opened the 
door to all the sugary complexity we are trying to avoid.

    _________

Looking at HTTP 1.0, it seems to mirror the basic needs for Gemini to be 
able to be used as a platform without the bloat that became 1.1, 2.0 
(and in the future 3.0/QUIC is in discussion)

My sense is we can find the sweet spot at about "HTTP 0.95" which is 
enough to support application development without the cruft of arbitrary 
headers and extensibility.

Here is the RFC for HTTP 1.0:

https://tools.ietf.org/html/rfc1945

quoting from the RFC about POST:


    The POST method is used to request that the destination server accept
    the entity enclosed in the request as a new subordinate of the
    resource identified by the Request-URI in the Request-Line. POST is
    designed to allow a uniform method to cover the following functions:

       o Annotation of existing resources;

       o Posting a message to a bulletin board, newsgroup, mailing list,
         or similar group of articles;

       o Providing a block of data, such as the result of submitting a
         form, to a data-handling process;

       o Extending a database through an append operation.


    The actual function performed by the POST method is determined by the
    server and is usually dependent on the Request-URI. The posted entity
    is subordinate to that URI in the same way that a file is subordinate
    to a directory containing it, a news article is subordinate to a
    newsgroup to which it is posted, or a record is subordinate to a
    database.

<continues>

    A valid Content-Length is required on all HTTP/1.0 POST requests. An
    HTTP/1.0 server should respond with a 400 (bad request) message if it
    cannot determine the length of the request message's content.

    Applications must not cache responses to a POST request because the
    application has no way of knowing that the server would return an
    equivalent response on some future request.


This seems to well describe the needs of building non-idempotent 
applications in Gemini.
As per previous emails we dont need the full vocabulary of the other 
HTTP verbs such as DELETE/PUT etc
and we can also still dispense with HEAD (a body-less GET) as adding not 
much (and was not much used).
Clients can implement a simplistic form of HEAD by abandoning a 
connection after the header line is seen.

So what I think we need is something around HTTP 0.95 (it never existed) 
which is about half way between HTTP 0.9 and 1.0.

GET (gemini right now)
POST (for non-idempotent interactions)
Content-Length indicator (to make POST work)

no other headers, so not extensible, so not as far as HTTP 1.0, but 
allows application development.

I'll leave you in peace now :-)

  - Luke


From solderpunk at SDF.ORG  Tue Jun 16 20:53:06 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 16 Jun 2020 19:53:06 +0000
Subject: A vision for Gemini applications
Message-ID: <20200616195306.GA14032@SDF.ORG>

Hi all,

I just posted a (long!) entry at my Corned Beef Sandwiches gemlog
outlining my vision for applications in Geminispace:

gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-for-gemini-applications.gmi

Note that my vision does not need to be everybody's vision.  I am
benevolent dictator of the protocol, but not what people build on top of
it.  I do hope people will give it some thought, though.  I'd like to
think there are good ideas in there.  It ties in many things which have
been discussed on the list recently, including Tomasino's "streaming"
idea and the issue of all our nice simple apps being vulnerable to CSRF.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Tue Jun 16 21:00:14 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Tue, 16 Jun 2020 20:00:14 +0000
Subject: HTTP/0.95 - the sweet spot or thereabouts?
In-Reply-To: <5EE91BCF.9080703@marmaladefoo.com>
References: <5EE91BCF.9080703@marmaladefoo.com>
Message-ID: <20200616200014.GB14032@SDF.ORG>

On Tue, Jun 16, 2020 at 08:21:51PM +0100, Luke Emmet wrote:
 
> So what I think we need is something around HTTP 0.95 (it never existed)
> which is about half way between HTTP 0.9 and 1.0.
> 
> GET (gemini right now)
> POST (for non-idempotent interactions)
> Content-Length indicator (to make POST work)
> 
> no other headers, so not extensible, so not as far as HTTP 1.0, but allows
> application development.

This sounds really nice (honestly!), but the big problem for me was
always: how does the client tell the server if it's doing a GET or a
POST without the protocol including some kind of marker for this, which
could then potentially get extended ad infinitum by people defining
their own equivalents to HEAD and PUT and etc, etc?  It's the usual
theme: if you have *one* of something, it can be implicit, and as such
nobody can try alternative values.  As soon as you have two or more, you
need to tell the server about it, and then people can try telling it
different things, and before long there is more than just two...

Cheers,
Solderpunk

From luke at marmaladefoo.com  Tue Jun 16 21:05:40 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 16 Jun 2020 21:05:40 +0100
Subject: HTTP/0.95 - the sweet spot or thereabouts?
In-Reply-To: <20200616200014.GB14032@SDF.ORG>
References: <5EE91BCF.9080703@marmaladefoo.com>
 <20200616200014.GB14032@SDF.ORG>
Message-ID: <5EE92614.4050806@marmaladefoo.com>



On 16-Jun-2020 21:00, solderpunk wrote:
> On Tue, Jun 16, 2020 at 08:21:51PM +0100, Luke Emmet wrote:
>
>> So what I think we need is something around HTTP 0.95 (it never existed)
>> which is about half way between HTTP 0.9 and 1.0.
>>
>> GET (gemini right now)
>> POST (for non-idempotent interactions)
>> Content-Length indicator (to make POST work)
>>
>> no other headers, so not extensible, so not as far as HTTP 1.0, but allows
>> application development.
> This sounds really nice (honestly!), but the big problem for me was
> always: how does the client tell the server if it's doing a GET or a
> POST without the protocol including some kind of marker for this, which
> could then potentially get extended ad infinitum by people defining
> their own equivalents to HEAD and PUT and etc, etc?  It's the usual
> theme: if you have *one* of something, it can be implicit, and as such
> nobody can try alternative values.  As soon as you have two or more, you
> need to tell the server about it, and then people can try telling it
> different things, and before long there is more than just two...

One really simplistic solution is we just have another scheme name 
(foo:// gemini+foo://), or just bolt it down in the spec (like mime and 
charset is). Gemini doesn't have to specify its really a GET, because it 
only does GET.

BTW I think there is lots of juicy ideas in your new blog post - still 
digesting it.

Best wishes

  - Luke


From pellertson at firemail.cc  Wed Jun 17 03:57:53 2020
From: pellertson at firemail.cc (Parker Ellertson)
Date: Tue, 16 Jun 2020 19:57:53 -0700
Subject: [ANN] Acme client is finally fixed.
Message-ID: <20200616195753.2ed586c8.pellertson@firemail.cc>

I've finally gotten awk to parse the URLs correctly, plus now the main
script is written in rc!  Note: you will have to run sudo or doas in
front of make.  User input, actually parsing through the response
header,  TOFU authentication, and client-side certificates are still in
the works.  But now you can actually click on links and have them go
places.

Happy browsing!

~ Parker

From meff at meff.me  Wed Jun 17 08:53:32 2020
From: meff at meff.me (Meff)
Date: Wed, 17 Jun 2020 00:53:32 -0700
Subject: A vision for Gemini applications
In-Reply-To: <20200616195306.GA14032@SDF.ORG>
References: <20200616195306.GA14032@SDF.ORG>
Message-ID: <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>

Hey all,

I like many of the ideas you expressed in your post but wanted to 
discuss one thing.

You mentioned that you would like to see *no* cross-domain linking, in 
order to remove the complexities of having to do some sort of CSRF-style 
validation. The thing is, I think cross-domain linking is useful. It's 
useful when replying to someone's Gemlog post, it's useful when creating 
lists of links you would like to recommend to visitors of your capsule, 
and for linking to sources of truth that may live elsewhere (especially 
if linking against the web).

How about a relaxed version of this, where all clients that wish to 
"follow" cross-domain links *must* strip out any query params. For basic 
clients, that would be as simple as a regex that strips the "?" used to 
start a query string, and everything that comes after. For more 
sophisticated clients that have access to URL processing libraries, this 
should be as simple as parsing the URL, removing any query strings, and 
hydrating this URL again. Now cross-domain requests cannot contain any 
sort of "payload" that the server would mutate state with. Of course, 
there is the possibility that a page view for an URL even without a 
query param would mutate state on the server, but that is already an 
issue now.

Thanks,
meff

On 6/16/20 12:53 PM, solderpunk wrote:
> Hi all,
> 
> I just posted a (long!) entry at my Corned Beef Sandwiches gemlog
> outlining my vision for applications in Geminispace:
> 
> gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-for-gemini-applications.gmi
> 
> Note that my vision does not need to be everybody's vision.  I am
> benevolent dictator of the protocol, but not what people build on top of
> it.  I do hope people will give it some thought, though.  I'd like to
> think there are good ideas in there.  It ties in many things which have
> been discussed on the list recently, including Tomasino's "streaming"
> idea and the issue of all our nice simple apps being vulnerable to CSRF.
> 
> Cheers,
> Solderpunk
> 

From paper at tilde.institute  Wed Jun 17 10:56:57 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Wed, 17 Jun 2020 05:56:57 -0400
Subject: [ANN] List of Gemini web mirrors
Message-ID: <20200617095657.4l6tfh3in4em4677@tilde.institute>

Hi, geminispace is growing and some web services are getting mirrored on
gemini. I am starting a list of mirrors on gemini. If you know about
more mirrors than I have there, I will be happy to hear about them. I
also wrote a page about how clients could benefit from this list.

gemini://gempaper.strangled.net/mirrorlist/

Paper

From solderpunk at SDF.ORG  Wed Jun 17 11:02:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 17 Jun 2020 10:02:21 +0000
Subject: A vision for Gemini applications
In-Reply-To: <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>
References: <20200616195306.GA14032@SDF.ORG>
 <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>
Message-ID: <20200617100221.GA6870@SDF.ORG>

On Wed, Jun 17, 2020 at 12:53:32AM -0700, Meff wrote:
 
> You mentioned that you would like to see *no* cross-domain linking, in order
> to remove the complexities of having to do some sort of CSRF-style
> validation. The thing is, I think cross-domain linking is useful. It's
> useful when replying to someone's Gemlog post, it's useful when creating
> lists of links you would like to recommend to visitors of your capsule, and
> for linking to sources of truth that may live elsewhere (especially if
> linking against the web).

You have misunderstood!  The stuff about no cross-domain linking was
strictly in the context of a "safety client" for very safely using a
certificate-secured app.  In the context of a reading-oriented client
for browsing gemlogs etc., *of course* cross-domain linking is
absolutely essential and a client which didn't allow it would be
useless.
 
> How about a relaxed version of this, where all clients that wish to "follow"
> cross-domain links *must* strip out any query params. For basic clients,
> that would be as simple as a regex that strips the "?" used to start a query
> string, and everything that comes after. For more sophisticated clients that
> have access to URL processing libraries, this should be as simple as parsing
> the URL, removing any query strings, and hydrating this URL again. Now
> cross-domain requests cannot contain any sort of "payload" that the server
> would mutate state with. Of course, there is the possibility that a page
> view for an URL even without a query param would mutate state on the server,
> but that is already an issue now.

This is a perfectly good idea for "everyday" clients to implement, in
order to make life a bit easier for people who really want to build and
use apps that don't hide behind a certificate requirement.  It would
make it impossible to, e.g., link to a GUS search result page, though.
That could be fixed if gemini://gus.guru/search?foo redirected to
gemini://gus.guru/search/marbles, but maybe it's not worth it.

In general, requiring all non-idempotent requests to use a query and
recommending clients to strip (or ask for confirmation of) queries found
in links and redirects, might be enough to solve the worst of the
problem.  It would make applications quite a bit clunkier to use (I
guess they would need to use status code 10 to ask "Are you sure?" to
every non-idempotent request), but some people might find that less clunky
than using certs, I guess.

Cheers,
Solderpunk

From defdefred at protonmail.com  Wed Jun 17 11:13:11 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 17 Jun 2020 10:13:11 +0000
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <5EE1FEE2.4050303@marmaladefoo.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
Message-ID: <vrei-zLTbw6kRH7YjqxKVrBbBGSYtdDpa4HkI3JzndDN4XGyj76tqSUc6pvoSHh6y6fxY81spj_DDPhORfgWuh6YmtcPoc9zEgFqNa7FpwU=@protonmail.com>

Thank you!
Really pleasant to use.


??????? Original Message ???????
On Thursday 11 June 2020 11:52, Luke Emmet <luke at marmaladefoo.com> wrote:

> Hi Folks
>
> I'm pleased to announce a new release of GemiNaut, which now has a home
> in geminispace as well as on the web:
>
> => gemini://gemini.marmaladefoo.com/geminaut/
>
> GemiNaut is a Windows client for gemini, designed with usability in mind
> and to assist the cognitive navigation through the sparse metadata of
> the geminiverse.
>
> Main changes to 0.8.4:
>
> -   use correct percent encoding for URL requests with input
> -   support quotation line style (new addition to Gemini spec)
> -   provide salient icon hints to common non textual content (images,
>     audio, video, docs)
>
> -   minor bug fixes, style updates and improvements
>
>     As always, feedback and improvement suggestions are welcomed.
>
>     Best Wishes
>
>     -   Luke



From solderpunk at SDF.ORG  Wed Jun 17 11:17:58 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 17 Jun 2020 10:17:58 +0000
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <20200617095657.4l6tfh3in4em4677@tilde.institute>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
Message-ID: <20200617101758.GC6870@SDF.ORG>

On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
 
> gemini://gempaper.strangled.net/mirrorlist/

Good job with the "Why?" page!  You convinced me quickly.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Wed Jun 17 11:20:10 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 17 Jun 2020 10:20:10 +0000
Subject: A vision for Gemini applications
In-Reply-To: <20200617100221.GA6870@SDF.ORG>
References: <20200616195306.GA14032@SDF.ORG>
 <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>
 <20200617100221.GA6870@SDF.ORG>
Message-ID: <20200617102010.GD6870@SDF.ORG>

On Wed, Jun 17, 2020 at 10:02:21AM +0000, solderpunk wrote:
 
> In general, requiring all non-idempotent requests to use a query and
> recommending clients to strip (or ask for confirmation of) queries found
> in links and redirects, might be enough to solve the worst of the
> problem.

Of course, it only takes *one* popular client not bothering to do this
to make all apps relying on it vulnerable, so really robust ones are
probably going to have to faff about with nonces anyway.

Cheers,
Solderpunk

From paper at tilde.institute  Wed Jun 17 11:24:11 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Wed, 17 Jun 2020 06:24:11 -0400
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <20200617101758.GC6870@SDF.ORG>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
Message-ID: <20200617102411.kp5wlksgsokvsvoi@tilde.institute>

On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
> On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
> 
> Good job with the "Why?" page!  You convinced me quickly.
> 
> Cheers,
> Solderpunk

I wasn't sure the Why page was good enough, thanks alot.

Paper

From defdefred at protonmail.com  Wed Jun 17 11:45:40 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 17 Jun 2020 10:45:40 +0000
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
Message-ID: <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>

Soon a wikipedia mirror?

:-)

??????? Original Message ???????
On Wednesday 17 June 2020 12:24, <paper at tilde.institute> wrote:

> On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
>
> > On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
> > Good job with the "Why?" page! You convinced me quickly.
> > Cheers,
> > Solderpunk
>
> I wasn't sure the Why page was good enough, thanks alot.
>
> Paper



From petite.abeille at gmail.com  Wed Jun 17 12:31:49 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 17 Jun 2020 13:31:49 +0200
Subject: gemini+submit:// (was Re: Uploading Gemini content)
In-Reply-To: <20200613205635.GD18831@SDF.ORG>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
Message-ID: <C962EB25-1113-4A00-8575-3B1FCF7F4184@gmail.com>



> On Jun 13, 2020, at 22:56, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> 3. Dear God, when/where/how does it stop?!  This was supposed to be a
> simple, humble, protocol of limited scope!  But...

It never stops. Gemini is now bidirectional.

It will reach consciousness  in 3, 2, 1...

When the Yogurt Took Over
LOVE DEATH + ROBOTS  
https://www.imdb.com/title/tt9788494/


From lenormfml at gmail.com  Tue Jun 16 10:27:50 2020
From: lenormfml at gmail.com (Frank LENORMAND)
Date: Tue, 16 Jun 2020 12:27:50 +0300
Subject: Escaping in text/gemini
In-Reply-To: <20200616111837.04d372ec@phi>
References: <20200616111837.04d372ec@phi>
Message-ID: <159229967030.1517025.15803565160004408044@localhost.localdomain>

On Thu Jan  1 03:00:00 1970, Francesco Gazzetta wrote:
> Just after the feature freeze :) I remembered to post about this: is
> there an official way to escape stuff in text/gemini?
> 
> For example in gemini://gemini-textboard.fgaz.me/thread/3 from post #37
> onwards you can see that links, pre blocks, etc are all escaped with a
> backslash, but the backslash appears in the output an is kinda ugly.

That took even less time than I expected.

>Only a matter of time until you see writers start escaping [text]

https://lists.orbitalfox.eu/archives/gemini/2020/001444.html

Regards,
-- 
Frank LENORMAND

From jmcbray at carcosa.net  Wed Jun 17 13:01:23 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 17 Jun 2020 08:01:23 -0400
Subject: A vision for Gemini applications
In-Reply-To: <20200617102010.GD6870@SDF.ORG> (solderpunk@sdf.org's message of
 "Wed, 17 Jun 2020 10:20:10 +0000")
References: <20200616195306.GA14032@SDF.ORG>
 <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>
 <20200617100221.GA6870@SDF.ORG> <20200617102010.GD6870@SDF.ORG>
Message-ID: <87bllhzyss.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> On Wed, Jun 17, 2020 at 10:02:21AM +0000, solderpunk wrote:
>  
>> In general, requiring all non-idempotent requests to use a query and
>> recommending clients to strip (or ask for confirmation of) queries found
>> in links and redirects, might be enough to solve the worst of the
>> problem.
>
> Of course, it only takes *one* popular client not bothering to do this
> to make all apps relying on it vulnerable, so really robust ones are
> probably going to have to faff about with nonces anyway.

I hope to write a fuller response to your vision post later today, if I
get a chance. But quickly one thought:

What if, as you suggest, non-idempotent requests are required to use
certificates, and further, that general-purpose clients are required to
make cross-site requests *without a client certificate*, even if they
have a certificate for the target in their store?

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From hello at matthewgraybosch.com  Wed Jun 17 13:26:12 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 17 Jun 2020 08:26:12 -0400
Subject: [ANN] tanelorn.city cert fixed
Message-ID: <20200617082612.fefbd20aec5b4d3c087aa5cf@matthewgraybosch.com>

The certs for tanelorn.city (as well as demifiend.org and
starbreaker.org) are fixed. You should be able to access with clients
like bombadillo now (that client worked for me when testing).

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

From lel at envs.net  Wed Jun 17 13:27:45 2020
From: lel at envs.net (lel)
Date: Wed, 17 Jun 2020 08:27:45 -0400
Subject: [ANN] Acme client is finally fixed.
In-Reply-To: <20200616195753.2ed586c8.pellertson@firemail.cc>
References: <20200616195753.2ed586c8.pellertson@firemail.cc>
Message-ID: <20200617122745.GA90749@spektr>

Thanks! This appears to fix a thing happening on my end where the letter
b was being filtered out of every response. I've been meaning to open an
issue or something, but I haven't had time to figure out what was
causing it, and I didn't want to open an issue if it was something wrong
with my environment. Looks to be working now, in any case.

Best,
lel

From solderpunk at SDF.ORG  Wed Jun 17 13:29:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 17 Jun 2020 12:29:37 +0000
Subject: A vision for Gemini applications
In-Reply-To: <87bllhzyss.fsf@dorothy.carcosa.net>
References: <20200616195306.GA14032@SDF.ORG>
 <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>
 <20200617100221.GA6870@SDF.ORG> <20200617102010.GD6870@SDF.ORG>
 <87bllhzyss.fsf@dorothy.carcosa.net>
Message-ID: <20200617122937.GE6870@SDF.ORG>

On Wed, Jun 17, 2020 at 08:01:23AM -0400, Jason McBrayer wrote:
 
> What if, as you suggest, non-idempotent requests are required to use
> certificates, and further, that general-purpose clients are required to
> make cross-site requests *without a client certificate*, even if they
> have a certificate for the target in their store?

Yes, that would definitely be possible (AV-98 almost does this, but it
explicitly asks you if you want to reactivate a previously used
certificate when you cross back to a domain).  I didn't mean to say that
I think it's impossible to build a general purpose client that's
optimised for reading static text but also certificate aware enough to
use apps, and to do so in a careful way that avoids CSRF attacks or
accidental "leakage" of identities.  I don't doubt it can be done!  And
people are genuinely welcome to try.  It just seemed to me that a client
like that is going to be at the very least more fiddly work for
developers to write and test, and perhaps also a bit more confusing for
users to use, compared to either a client which just has no concept of
client certificates, or one which does but is bound to a single domain.
Two simple programs which each do one thing and do it well will be
simpler and safer, and it plays well to one of our core strengths, which
is that usable clients can be extremely lightweight so running one per
app is very feasible.

Cheers,
Solderpunk

From defdefred at protonmail.com  Wed Jun 17 13:59:36 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 17 Jun 2020 12:59:36 +0000
Subject: Escaping in text/gemini
In-Reply-To: <20200616123334.53fb7f17@phi>
References: <20200616111837.04d372ec@phi>
 <2d579d1e-4b8d-9eba-7e22-5adaf0b59f6c@masterq32.de>
 <20200616123334.53fb7f17@phi>
Message-ID: <HOWf4xNrFlI3LACz6JCkro96S0AcbGofYELbDVE_KOXGEc9t3jD08XLZXFTajYoR5j7U2cXIiJ53aD2KZte-a_j3TUr6E940-YzcPOG5_Dw=@protonmail.com>

If another * is found in the same line, it is not a bullet.

From solderpunk at SDF.ORG  Wed Jun 17 14:28:05 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Wed, 17 Jun 2020 13:28:05 +0000
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <gp6Ja5zK2ZCDtNROdt5Q5-iIkv1IxnMmsJGLHf-TBcoHuNv4-gUdpBfsyzwTHL5VdbVjF8M72CgCFgvxqpL4BMNaesfvNP_FnPNWCJlaC60=@protonmail.com>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <gp6Ja5zK2ZCDtNROdt5Q5-iIkv1IxnMmsJGLHf-TBcoHuNv4-gUdpBfsyzwTHL5VdbVjF8M72CgCFgvxqpL4BMNaesfvNP_FnPNWCJlaC60=@protonmail.com>
Message-ID: <20200617132805.GA15149@SDF.ORG>

On Sun, Jun 14, 2020 at 08:57:57PM +0000, defdefred wrote:
> On Sunday, June 14, 2020 3:22 AM, Sean Conner <sean at conman.org> wrote:
> > [3] http://boston.conman.org/2019/07/09-12
> > http://boston.conman.org/2019/08/06.2
> 
> Should we deduce that a significative part of the internet traffic is fake request?
> That a shame concidering the environmental impact of the digital world.
> Maybe blocking all this non-human request is the solution?

It's true that this is a shame.  As Sean says, however, it's extremely
difficult to actually block all non-human requests.

I am sensitive to this issue and I hope that as part of the general
emphasis on being small and simple, the Gemini community can help also
foster a culture of not treating the internet as an ephemeral magic
thing with no physical impact.  Non-human traffic is not evil and
can serve a good purpose, but we should be careful with it.

In some ways, Gemini is disadvantagaed here with its lack of facilities
for things like conditional fetching.  If we make a norm of using small
self-signed certificates using eliptic curve ciphers, and supporting TLS
session resumption, we might be able to get request overhead down to the
point where clients can address well-known endpoints to query the time
of last change for something without it actually being a losing
proposition most of the time.

But even in the absence of this, we can be smarter.  For example,
software which consumes RSS/Atom feeds gets, for free, information on
the distribution of times between consecutive updates for the last 10 or
maybe more updates.  Instead of polling everything several times a day,
aggregators *could* poll each feed at a specific frequency which is
matched to its typical publication schedule.

Cheers,
Solderpunk


From koushik at meff.me  Wed Jun 17 22:34:53 2020
From: koushik at meff.me (Koushik Roy)
Date: Wed, 17 Jun 2020 14:34:53 -0700
Subject: A vision for Gemini applications
In-Reply-To: <20200617122937.GE6870@SDF.ORG>
References: <20200616195306.GA14032@SDF.ORG>
 <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>
 <20200617100221.GA6870@SDF.ORG> <20200617102010.GD6870@SDF.ORG>
 <87bllhzyss.fsf@dorothy.carcosa.net> <20200617122937.GE6870@SDF.ORG>
Message-ID: <04d5aa48-1bd8-2de6-8373-6215a7782d9e@meff.me>

On Wed, Jun 17, 2020 at 08:01:23AM -0400, Jason McBrayer wrote:
>   
>> What if, as you suggest, non-idempotent requests are required to use
>> certificates, and further, that general-purpose clients are required to
>> make cross-site requests *without a client certificate*, even if they
>> have a certificate for the target in their store?

I feel that this is too restrictive. Just offhand, things like a site 
counter are not idempotent but are quite useful. I think the server 
should be smart and gate non-trivial non-idempotent logic behind a 
certificate.


On 6/17/20 5:29 AM, solderpunk wrote:
> It just seemed to me that a client
> like that is going to be at the very least more fiddly work for
> developers to write and test, and perhaps also a bit more confusing for
> users to use, compared to either a client which just has no concept of
> client certificates, or one which does but is bound to a single domain.
> Two simple programs which each do one thing and do it well will be
> simpler and safer, and it plays well to one of our core strengths, which
> is that usable clients can be extremely lightweight so running one per
> app is very feasible.

Do you visualize separate clients per application, an 
application-optimized client, or both? Just curious about the 
destination of this vision.

- meff


From koushik at meff.me  Thu Jun 18 02:36:57 2020
From: koushik at meff.me (Koushik Roy)
Date: Wed, 17 Jun 2020 18:36:57 -0700
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <20200614012215.GO11281@brevard.conman.org>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
Message-ID: <a5f87b02-5b4f-449d-25ce-9453f1aa0254@meff.me>

I also get paid to do a lot of networking and infrastructure related 
things for a tech company, so I understand where you're coming from when 
it comes to understanding that ISPs have restrictions in place due to 
good reasons (the amount of abuse on the net is staggering, and so much 
of my job deals with ways to serve legitimate traffic while not allowing 
abuse to impact our services/our users).

I also want to reiterate in this thread the importance of enabling users 
who wish to author gemini content on devices such as tablets and 
smartphones. Imagine a kid who doesn't even have access to a computer 
but has access to an aging smartphone or a feature phone. Or think of 
someone who lives in non-traditional housing (whether by choice or not) 
and travels a lot; for them a tablet may be a better option when it 
comes to space/weight/money. I think it is very important to enable 
users to author content no matter the device.

All that said, I'm not convinced that an in-band Gemini posting 
mechanism is the correct answer. I prefer a solution that involves the 
community standardizing around some other mechanism to upload content, 
and then building/popularizing apps (native or not) that use this 
mechanism. To make this more concrete, I can imagine a scenario where 
apps are built on top of FTPS to allow users to author content and then 
transparently have them appear in a Gemini capsule. Swap FTPS with one 
of many other mechanisms, such as SFTP, NNTPS, Email, what have you.

I just feel that overloading these sorts of concerns onto Gemini will 
lead to greater complexity in the protocol than would be desirable and 
turn off potential implementers of both servers and clients. I think the 
explosion we're seeing of software and content right now is directly 
attributable to how simple the spec is to understand and implement. 
Publishing-oriented clients can then bundle some sort of interface to 
this companion protocol and either shell out to a text editor or open a 
native text editing widget (or even work through some sort of 
Electron-style textbox). I realize that titan:// is a separate protocol, 
but I think something like Passive FTPS may be a better fit here.

- meff

On 6/13/20 6:22 PM, Sean Conner wrote:
> It was thus said that the Great Matthew Graybosch once stated:
>>
>> Let's be honest; it shouldn't be that hard to run a gemini daemon out
>> of a personal computer in your own home, whether it's your main desktop
>> or just a raspberry pi. The protocol is light enough that CPU and
>> memory usage should be next to nothing compared to Firefox or Chrome.
> 
>   ...
> 
>> I think the biggest problem, at least in the US, is that ISPs seem
>> hellbent on keeping residential internet users from using their
>> connections for anything but consumption.
> 
>    As someone who has worked for various ISPs and webhosting companies for
> most of my career, I think this slamming of IPSs is unwaranted.  And as
> someone who runs both a public server *and* a few services on my home
> network [1] there are some things you need to consider.
> 
> 1. Open servers are *attacked* at an alarming rate. At home, I run an sshd
> instance tha is open to the Internet [2].  I am currently blocking 2,520
> hosts that have attempted to log in via ssh.  That count is only over the
> past 30 days (technically, 30 days, 10 hours, 30 minutes, as that's the
> average month length over the year).  Not doing so means my machine will be
> constantly under login attempts.
> 
>    99% of all traffic to my webserver (on my actual public server) is
> automated programs, not actual humans.  Most are just webbots spidering my
> content, some are script kiddies looking for an exploit and some are just
> incompetently written programs that just blow my mind [3].  There's the
> wierd network traffic that just sucks up connections requests [4].  And then
> there's the *wierd* (and quite stressful) situations involving black-hat
> hackers [5].
> 
>    Then there's the issues with running UDP based services [6].  It's not
> pretty on the open Internet.
> 
> 2. If people could run a business server on their home connection, they
> would.  Then they'll bitch and moan about the service being slow, or can't
> the ISP do something about the DDoS attack they're under?  Even if they
> aren't and their service is just popular.  Or why their connection dropped?
> Never mind the power is out, why did my server loose connection?
> 
>    Or in self defense, the ISP cuts the connection because the home server is
> running a port scanner, participating in a botnet, or sending out spam
> emails because of an unpatched exploit in some server being run at home.
> 
> 3. Do people realize they'll need to basically firewall off their Windows
> boxes?  Seriously, the level of exploits on Windows is (was?) staggering and
> the number of services (like file sharing) it runs by default (because
> that's what the users want) it runs is *not* condusive to allowing a Windows
> box full access to the Internet.  The same can be said for Mac and Linux,
> but to a slightly lesser degree.
> 
> 4. It was email that poisoned home-run servers intially.  Spam increased
> dramatically during the late 90s/early 2000s to the point where it because a
> Byzantine nightmare to configure and run an email server due to SPF, DMARC
> and DKIM, along with greylisting and filtering of attachments.  Oh, and as a
> self-defense mechanism, nearly every ISP around the world will block
> incoming/outgoing TCP port 25 to home users.
> 
>> You've got to use a dynamic
>> DNS service like no-ip.com, and even if you manage that you might still
>> find yourself getting cut off over a TOS violation. People are
>> thoroughly conditioned toward using the internet as glorified cable TV,
>> and only expressing themselves on platforms they don't control.
> 
>    That is true too, but I suspect even *if* you could easily run a server at
> home, 99% would not even bother (or know what it is).
> 
>> Then there's DNS, domain names, ICAAN, etc. Maybe if we still used a
>> UUCP-style addressing scheme like
>> <country>.<province>.<city>.<neighborhood>.<hostname> it wouldn't
>> matter what I called my host as long as the hostname was unique to the
>> <neighborhood>. But instead we settled on <domain-name>.<tld>, which
>> needs to be administered by registrars to ensure uniqueness, and domain
>> registration is yet more sysadmin stuff that most people don't
>> necessarily have the time, skill, or inclination to deal with.
> 
>    There are groups working on alternative naming/routing schemes that don't
> require a global namespace.  It's not an easy problem.
> 
>    Also, at one time, domains under the .us domain were restricted to
> geographical names, like example.boca-raton.fl.us.  But they were free to
> register, and as far as I can tell, permanent.  The issue though, is that
> even under the <city>,<state>.us, you still need unique names, although it's
> a smaller area to worry about.
> 
>    I don't think you can do that anymore.  I went down that rabbit hole
> several months ago looking to register a geographical domain under .us and
> couldn't do it (or find out who controls the domains under
> boca-raton.fl.us).  Pitty, I was hoping to get a free domain registration
> for life.
> 
>> I would prefer that public hosts weren't necessary. I think that
>> everybody who wants to should be able to publish from their own device
>> without having to become a sysadmin. As long as operating a gemini
>> service remains the province of sysadmins, we're going to maintain the
>> division between haves (sysadmins) and have nots (people who can't or
>> don't want to sysadmin) that prevented the web from becoming (or
>> remaining) a democratic platform.
> 
>    Never underestimate the lack of giving a damn the general population have.
> I'm sure there are aspects of your life that you lack a damn about that
> other people think you should give more than a damn.
> 
>> This became something of a political rant, and I probably should have
>> put it on demifiend.org instead. Sorry if this doesn't belong here; I'm
>> posting this under a new subject so that it starts a new thread instead
>> of derailing the existing one.
> 
>    I think it's a conversation worth having, as it relates to how Gemini
> expands with new content.
> 
>    -spc
> 
> [1]	Disclaimer: I do pay extra for a static IPv4 address---at the time I
> 	needed it for my job, and now it's a "nice to have" and I can still
> 	afford it.  It's actually not that much over the stock price of
> 	service.
> 
> [2]	My router will forward ssh traffic to my main development system.
> 
> [3]	http://boston.conman.org/2019/07/09-12
> 	http://boston.conman.org/2019/08/06.2
> 
> [4]	http://boston.conman.org/2020/04/05.1
> 
> [5]	http://boston.conman.org/2004/09/19.1
> 
> [6]	http://boston.conman.org/2019/05/13.1
> 

From krixano at protonmail.com  Thu Jun 18 04:23:05 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 18 Jun 2020 03:23:05 +0000
Subject: Odin-lang.org Gemini Mirror
Message-ID: <O7EVVrz2UFr8iagi4WvxHi3BjuEKVAqNNPKQXG8oGo0_xxGVp80-T41XKQEVT9Y2fMHDmSORXuwXfty0eMtPnxOq1gVz77qcHHc7XjUretc=@protonmail.com>

I have gotten permission from the Odin developer to create an https://odin-lang.org mirror for Gemini!
You can visit it at gemini://pon.ix.tc/odin

It's basically finished, although there are a few things that could be improved, like hosting the release files on gemini, linking to images used on the site, and a few other things.

Finally, thanks to makeworld for his great library, md2gemini, that was very useful for this project!

Christian Seibold

Sent with ProtonMail Secure Email.

From defdefred at protonmail.com  Thu Jun 18 07:28:17 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 18 Jun 2020 06:28:17 +0000
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <vrei-zLTbw6kRH7YjqxKVrBbBGSYtdDpa4HkI3JzndDN4XGyj76tqSUc6pvoSHh6y6fxY81spj_DDPhORfgWuh6YmtcPoc9zEgFqNa7FpwU=@protonmail.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <vrei-zLTbw6kRH7YjqxKVrBbBGSYtdDpa4HkI3JzndDN4XGyj76tqSUc6pvoSHh6y6fxY81spj_DDPhORfgWuh6YmtcPoc9zEgFqNa7FpwU=@protonmail.com>
Message-ID: <K9fhghmwhRffPDD9qTEqyiwFTkbkTn2-aa3fDfFbe78b9dxTg8UVnIO7PVv8q4F7UjGCuAq4qflKsi4DLBoGDR0Qxi8aErtt7rVyqw18Qjw=@protonmail.com>

Could it be possible to duplicate CSS files to automaticaly create a new Theme?
I like to have the writing more grey than brigth white in the terminal theme.

Thanks!

From solderpunk at SDF.ORG  Thu Jun 18 14:45:08 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 18 Jun 2020 13:45:08 +0000
Subject: A vision for Gemini applications
In-Reply-To: <04d5aa48-1bd8-2de6-8373-6215a7782d9e@meff.me>
References: <20200616195306.GA14032@SDF.ORG>
 <232dde9b-b100-bf9c-12e5-9a8bcc17f71f@meff.me>
 <20200617100221.GA6870@SDF.ORG> <20200617102010.GD6870@SDF.ORG>
 <87bllhzyss.fsf@dorothy.carcosa.net>
 <20200617122937.GE6870@SDF.ORG>
 <04d5aa48-1bd8-2de6-8373-6215a7782d9e@meff.me>
Message-ID: <20200618134508.GA2565@SDF.ORG>

On Wed, Jun 17, 2020 at 02:34:53PM -0700, Koushik Roy wrote:
 
> Do you visualize separate clients per application, an application-optimized
> client, or both? Just curious about the destination of this vision.

General purpose, application-optimised clients.  Application specific
clients would be nothing to get excited about.  To quote my post:

> Yes, you can build tiny little remote command line apps which use HTTP
> to talk to an API somewhere, but every one of them is its own separate
> app, wedded to its own specific API and not useful for anything else.
> The Gemini-based solution sketched above lets you use *one* client
> program for *all* apps, which is clearly far superior, and does so
> without any risk of the apps being able to interact with one another.

I have an in-development proof-of-concept implementation of this here:

https://tildegit.org/solderpunk/alphonse

It is basically AV-98 with half the code ripped out (and more ripping to
be done!).  It requires a URL, TLS cert and TLS key as compulsory
command line options.  The cert is used unconditionally for all
requests, and it will refuse to visit any URL which is not at the same
domain and the same path or lower as the provided starting URL.  The
"go" command, all bookmarking stuff, "tour" command and any other
interface elements that allow the user to specify somewhere to go have
been removed.  You just use the internal links of the apps you point it
at upon startup and can't go anywhere else.

I have aliased `astrobotany` in my shell to fire up Alphonse, pointed at
astrobotany.mozz.us/app and feeding in my existing cert/key, and it's
now how I water my plant.  As intended, it basically gives the remote
Gemini app the appearance of a local command line application.  Now I
can use any Gemini client I like for my day to day reading of gemlogs,
without it needing to support client certificates or, if it does support
them, without me having told it where to find my astrobotany certs, and
thus my little space plant is now totally invulnerable to CSRF attacks.

This is not only a safer way to use astrobotany, it is much more
convenient than opening a general purpose client, opening my bookmarks,
choosing astrobotany, selecting my cert from a list that is brought up
when it sees the 6x status code, and then playing.  I just open a new
terminal, type `astro`, hit tab, hit enter and then I'm in,
authenticated, ready to go.  I can't imagine wanting to go back to the
old way.  If more applications built around long-lived certificates
appear in Geminispace, I will add new aliases for the ones that
interest me.  It's a really great approach, IMHO.

It is not foolproof - it cannot protect against application-internal
CSRF attacks, e.g. some kind of multi-user application where one user
can post text/gemini content which is rendered by another user of the
same application.  But for single-user applications or applications
where different users cannot interact with one another via means of
unfiltered text/gemini, this is great.  App developers do not need to
bother with tedious nonce code, and users can click on any link they
like in their everyday client knowing the apps they use via their
app-specific client are totally safe.

Cheers,
Solderpunk

From jmcbray at carcosa.net  Thu Jun 18 15:57:56 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 18 Jun 2020 10:57:56 -0400
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <a5f87b02-5b4f-449d-25ce-9453f1aa0254@meff.me> (Koushik Roy's
 message of "Wed, 17 Jun 2020 18:36:57 -0700")
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com> <5EE4CF68.20100@marmaladefoo.com>
 <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <a5f87b02-5b4f-449d-25ce-9453f1aa0254@meff.me>
Message-ID: <87v9joa0az.fsf@dorothy.carcosa.net>

Koushik Roy <koushik at meff.me> writes:

> All that said, I'm not convinced that an in-band Gemini posting
> mechanism is the correct answer. I prefer a solution that involves the
> community standardizing around some other mechanism to upload content,
> and then building/popularizing apps (native or not) that use this
> mechanism. To make this more concrete, I can imagine a scenario where
> apps are built on top of FTPS to allow users to author content and
> then transparently have them appear in a Gemini capsule. Swap FTPS
> with one of many other mechanisms, such as SFTP, NNTPS, Email, what
> have you.

I strongly agree with this. For me, the attraction of Gemini is that the
web is no longer a suitable protocol for document delivery, because most
sites require very large, complex browsers that are optimized for use as
an application runtime. If every webserver were running Shizaru, I could
use a reasonable browser like Lynx or Dillo, but that's not realistic
today. I want a document-sharing ecosystem that is not going to expand
to require runtimes for untrusted remote applications.

I don't really feel that we are lacking in file copying protocols, or
that any of the existing file copying protocols are problematic in the
same way that http(s) is. While some of them (SCP? Rsync over SSH?
git+ssh?) may be complex to implement from scratch, they also are mostly
encapsulated by small programs that can be scripted. I also realize
titan: is a separate protocol, but I'm not sure it does the same job as
Gemini of solving a problem that needs to be solved. I'm afraid it's
more like the tendency of the web to replace all other protocols with
extensions of itself.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From solderpunk at SDF.ORG  Thu Jun 18 16:13:23 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 18 Jun 2020 15:13:23 +0000
Subject: Repeating the Web's Mistakes (was gemini+submit:// (was Re:
 Uploading Gemini content))
In-Reply-To: <87v9joa0az.fsf@dorothy.carcosa.net>
References: <20200613053926.GH11281@brevard.conman.org>
 <20200613022323.46fd03f0ec8bd59ca6a5709b@matthewgraybosch.com>
 <20200613070556.GI11281@brevard.conman.org>
 <5EE48DCA.2040706@marmaladefoo.com>
 <5EE4CF68.20100@marmaladefoo.com> <20200613205635.GD18831@SDF.ORG>
 <20200613193019.08e51c07b60416936ab3ab4f@matthewgraybosch.com>
 <20200614012215.GO11281@brevard.conman.org>
 <a5f87b02-5b4f-449d-25ce-9453f1aa0254@meff.me>
 <87v9joa0az.fsf@dorothy.carcosa.net>
Message-ID: <20200618151323.GB2565@SDF.ORG>

On Thu, Jun 18, 2020 at 10:57:56AM -0400, Jason McBrayer wrote:

> If every webserver were running Shizaru, I could
> use a reasonable browser like Lynx or Dillo, but that's not realistic
> today.

I will post something on just that topic quite shortly.  :)  Stay tuned!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 18 16:36:54 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 18 Jun 2020 15:36:54 +0000
Subject: Why there's a point to alternative protocols and spaces
Message-ID: <20200618153654.GC2565@SDF.ORG>

Howdy all!

Perhaps the most common criticism I've read of Gemini comes from people
who think defining a new protocol whose capabilities are very closely
matched by a subset of an existing one is a waste of time.  Why build
something from scratch when you can just build webpages which don't use
javascript or iframes etc., and serve them with servers that don't send
cookies and E-tags?

It's a fair enough question on the face of it, and I want our FAQ to
address it.

I think everybody here understands the tremendous difference between
that and what we're trying to do with Gemini, but it's a difficult thing
to boil down to a succinct answer.  I have written up some of my
thoughts in the traditional long form at:

gemini://gemini.circumlunar.space/~solderpunk/cornedbeef/why-not-just-use-a-subset-of-http-and-html.gmi

I am keen to hear people's thoughts, both on what I've written and on
the question in general, and receive suggestions on what good responses
are to people who ask this question.

Cheers,
Solderpunk

From defdefred at protonmail.com  Thu Jun 18 18:25:02 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 18 Jun 2020 17:25:02 +0000
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <20200618153654.GC2565@SDF.ORG>
References: <20200618153654.GC2565@SDF.ORG>
Message-ID: <-_GlD-Zu5ezMsGpCzFXBYwY3WpdaO2cfeigYqF-S8w4mVAI-rtdVEEG7k-u4SlkzrRNbLEvBdtVhDdUEG9G6KNThPxMDq16ZvJIUbNDklxs=@protonmail.com>

typo:
- Javsacript
- buliding

I 'm Totally agreed with the content.

Bloated browser, auto-playing video, ads, all of this is against rational use of energy and human brain.

freD.

From solderpunk at SDF.ORG  Thu Jun 18 19:09:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 18 Jun 2020 18:09:44 +0000
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <-_GlD-Zu5ezMsGpCzFXBYwY3WpdaO2cfeigYqF-S8w4mVAI-rtdVEEG7k-u4SlkzrRNbLEvBdtVhDdUEG9G6KNThPxMDq16ZvJIUbNDklxs=@protonmail.com>
References: <20200618153654.GC2565@SDF.ORG>
 <-_GlD-Zu5ezMsGpCzFXBYwY3WpdaO2cfeigYqF-S8w4mVAI-rtdVEEG7k-u4SlkzrRNbLEvBdtVhDdUEG9G6KNThPxMDq16ZvJIUbNDklxs=@protonmail.com>
Message-ID: <20200618180944.GD2565@SDF.ORG>

On Thu, Jun 18, 2020 at 05:25:02PM +0000, defdefred wrote:
> typo:
> - Javsacript
> - buliding

Thanks, fixed!

Cheers,
Solderpunk

From defdefred at protonmail.com  Thu Jun 18 19:16:47 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 18 Jun 2020 18:16:47 +0000
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <20200618180944.GD2565@SDF.ORG>
References: <20200618153654.GC2565@SDF.ORG>
 <-_GlD-Zu5ezMsGpCzFXBYwY3WpdaO2cfeigYqF-S8w4mVAI-rtdVEEG7k-u4SlkzrRNbLEvBdtVhDdUEG9G6KNThPxMDq16ZvJIUbNDklxs=@protonmail.com>
 <20200618180944.GD2565@SDF.ORG>
Message-ID: <WO-83oegyRVQbnGBZuur35iXbKnCdfsEryuPtKgIxa44XTfr9qSHg7xsm2z2l8ACVlRej3xIApVGDWRwoYmRninNA4EMC9Idyjap1WEB604=@protonmail.com>

It maybe an extremist point of view, but the possibility to link to other protocol is the "beginning of the end" for the SafeWeb.

How about using a web sanitizer gateway accessible via gemini protocol?

freD.

From me at case.codes  Thu Jun 18 19:36:25 2020
From: me at case.codes (case)
Date: Thu, 18 Jun 2020 12:36:25 -0600
Subject: A plan for growing the ecosystem
Message-ID: <4B0053AB-AD37-40FB-8ADF-84FB8B591618@case.codes>

I believe the best way to grow the Gemini ecosystem is to launch a concerted effort to get Gemini support built into the tools of bloggers. This is something I'd been thinking about for awhile, before discovering Gemini that filled a large part in my desire to reclaim the internet from advertising and the corporate browser problem.

If we can make producing Gemini content a default choice alongside html, I believe most amateur writers would be totally happy with a secondary channel. 

So as a community,  what do you think about a campaign to:

1. Work with static site generators to get Gemini support built. At the least as supported plugins, then as part of the default distribution. md2gemini is key here

2. Get feed readers to support gemini, starting with open source ones.

And this is the hardest but is aided by the previous two:
3. Get CMS/blog hosts to support gemini; I'm thinking smaller players first but building up to WordPress, medium, etc...

Cheers,
Case


-- Email domain proudly hosted at https://migadu.com


From cage-dev at twistfold.it  Thu Jun 18 19:45:36 2020
From: cage-dev at twistfold.it (cage)
Date: Thu, 18 Jun 2020 20:45:36 +0200
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <20200618153654.GC2565@SDF.ORG>
References: <20200618153654.GC2565@SDF.ORG>
Message-ID: <20200618184536.GA10108@kurosawa.casa.net>

On Thu, Jun 18, 2020 at 03:36:54PM +0000, solderpunk wrote:

Hi!

quoting from the mentioned article:

"[...] Safeweb  status is  inherently  unstable by  virtue  of being  a
subset of something greater [...]"

This, in my opinion, is the key  concept of the document.  I would say
that  this is  a  very  problematic equilibrium  as  the super-set  of
Safeweb has been  exploited or even designed to be  "unsafe" (at least
for the privacy of the users).

Bye!
C.

From hello at matthewgraybosch.com  Thu Jun 18 21:30:30 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 18 Jun 2020 16:30:30 -0400
Subject: A plan for growing the ecosystem
In-Reply-To: <4B0053AB-AD37-40FB-8ADF-84FB8B591618@case.codes>
References: <4B0053AB-AD37-40FB-8ADF-84FB8B591618@case.codes>
Message-ID: <20200618163030.7f3f7528bcc077ca47989828@matthewgraybosch.com>

On Thu, 18 Jun 2020 12:36:25 -0600
case <me at case.codes> wrote:

> 1. Work with static site generators to get Gemini support built. At
> the least as supported plugins, then as part of the default
> distribution. md2gemini is key here

My understanding is that you only really need text/gemini for index
pages; all other text content can be text/plain, text/markdown, etc.
How this text gets varies by client, but the only thing stopping
somebody using a static site generator from also publishing on Gemini
is the need to generate text/gemini index pages.

However, I remember enough about how Jekyll works to know that it
should be possible to create a Liquid template that outputs a gemini
index, since Liquid templates have also been used in Jekyll to generate
RSS, Atom, and JSON feeds. You can probably do the same in Hugo and
Pelican using their templates; no need for plugins.

Hell, you could probably generate a text/gemini index with M4 and a
makefile if you wanted.

> 2. Get feed readers to support gemini, starting with open source ones.

IIRC, feed readers support render HTML by using libraries like
webkitgtk3. Supporting Gemini text would require the implementation of a
similar rendering library.

> And this is the hardest but is aided by the previous two:
> 3. Get CMS/blog hosts to support gemini; I'm thinking smaller players
> first but building up to WordPress, medium, etc...

We could probably go directly for WordPress support by implementing
text/gemini publishing as a plugin. 

However, I suggest that we immediately write off Medium as a lost
cause. I don't think there's any way Ev Williams and co. would be
amenable to letting content leak out of their proprietary walled garden
via an alternate protocol like Gemini.

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

From paper at tilde.institute  Thu Jun 18 21:40:43 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Thu, 18 Jun 2020 16:40:43 -0400
Subject: A plan for growing the ecosystem
In-Reply-To: <4B0053AB-AD37-40FB-8ADF-84FB8B591618@case.codes>
References: <4B0053AB-AD37-40FB-8ADF-84FB8B591618@case.codes>
Message-ID: <20200618204043.GA79335@tilde.institute>

On Thu, Jun 18, 2020 at 12:36:25PM -0600, case wrote:

> 2. Get feed readers to support gemini, starting with open source ones.
This shouldn't be that hard, but I don't think non-tech people even know
what feed reader is nowadays.

> And this is the hardest but is aided by the previous two:
> 3. Get CMS/blog hosts to support gemini; I'm thinking smaller players first but building up to WordPress, medium, etc...
I don't like this. One of the main points of gemini for me is
decentralization and that it is not commercial. Adding support for
something like medium would slowly make it only slightly better than the
web - requiring users to login after they read 3 articles, etc.

I think it would be cool if we had a pretty Android & IOS app marketed
as a blogging/writing platform. On the first screen it would prompt the
user to select an instance where they want to register an account (in
fact creating an ssh account), then it would be simply normal gemini
client app. The homepage could be a feed reader, the user could write
gemini markup directly in the app or they could write it as WYSIWYG.

I think this way, it would be possible to get non-tech people use it.

Paper

From paper at tilde.institute  Thu Jun 18 21:48:11 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Thu, 18 Jun 2020 16:48:11 -0400
Subject: A plan for growing the ecosystem
In-Reply-To: <20200618163030.7f3f7528bcc077ca47989828@matthewgraybosch.com>
References: <4B0053AB-AD37-40FB-8ADF-84FB8B591618@case.codes>
 <20200618163030.7f3f7528bcc077ca47989828@matthewgraybosch.com>
Message-ID: <20200618204811.GB79335@tilde.institute>

On Thu, Jun 18, 2020 at 04:30:30PM -0400, Matthew Graybosch wrote:
> On Thu, 18 Jun 2020 12:36:25 -0600
> case <me at case.codes> wrote:
> 
> > 1. Work with static site generators to get Gemini support built. At
> > the least as supported plugins, then as part of the default
> > distribution. md2gemini is key here
> 
> My understanding is that you only really need text/gemini for index
> pages; all other text content can be text/plain, text/markdown, etc.

Yes, but the text/gemini syntax is much simpler, simpler to parse... Of
course if a blogger wants to have inline images, then they will probably
have to use markdown.

> However, I remember enough about how Jekyll works to know that it
> should be possible to create a Liquid template that outputs a gemini
> index, since Liquid templates have also been used in Jekyll to generate
> RSS, Atom, and JSON feeds. You can probably do the same in Hugo and
> Pelican using their templates; no need for plugins.

I read a phlog post about 3 months ago where someone was describing how
they created a template for Hugo which outputs gophermaps, maybe we
could get inspiration there.

> > 2. Get feed readers to support gemini, starting with open source ones.
> 
> IIRC, feed readers support render HTML by using libraries like
> webkitgtk3. Supporting Gemini text would require the implementation of a
> similar rendering library.

Most people I know are using a web based client, there it shouldn't be a
big problem. Plus, webkit2gtk and other libraries like this render HTML,
so if we converted text/gemini to HTML, it will work. I know, not the
best solution, but it's a possibility.

Paper

From hello at matthewgraybosch.com  Thu Jun 18 22:02:00 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 18 Jun 2020 17:02:00 -0400
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <20200618153654.GC2565@SDF.ORG>
References: <20200618153654.GC2565@SDF.ORG>
Message-ID: <20200618170200.d5d453066f6fa72054fa572a@matthewgraybosch.com>

On Thu, 18 Jun 2020 15:36:54 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> I am keen to hear people's thoughts, both on what I've written and on
> the question in general, and receive suggestions on what good
> responses are to people who ask this question.

I think the general thrust of this post is solid, but I want to address
this part in particular. Not because I disagree with it, but to provide
my own answer.

> Why not just build non-evil websites using the existing technology,
> instead of building something new from the ground up?

I could, but I don't want to. It's too much like work. (I build
government web apps at my day job.)

* HTML is a pain to write.
* HTML is a pain to generate from markdown.
* HTML is a pain to style with CSS.
* CSS is a pain to write.
* Semantic markup is a pain.
* Worrying about desktop vs mobile is a pain.
* SEO is a pain.
* Knowing that Google will bury your site to push ads is infuriating.
* Knowing that social media platforms like Facebook and Twitter see
independent websites as nothing but resources to plunder is infuriating.
* I'm tired of trying to help preserve a document-oriented web when the
vast majority either want the web to be about apps or a la carte cable
TV with a comment section.

TBH, I like that the Gemini scene has the sort of
underground/DIY/zine/samizdat vibe that it does. I like plain text. If I
still thought doing websites with a "safe subset" of HTML and CSS was
worthwhile I'd still be doing that.

Instead, I'm here.

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

From colecmac at protonmail.com  Fri Jun 19 00:27:51 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 18 Jun 2020 23:27:51 +0000
Subject: [ANN] Amfora, a fancy terminal browser for Gemini
Message-ID: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>

Hello Geminauts,

Today I released Amfora, my client for Gemini. It aims to be a great looking,
featureful browser... all in the terminal. It is similar to Bombadillo, but
has colors and stylings, *tabbed browsing*, and brings in a lot more deps.
Sloum, if you're reading this, thanks so much for all the work you've done
with Bombadillo.

I aim to add a lot more features to it over the coming weeks, like bookmarks,
downloading, header navigation / TOC, client certs, and feed subscribing.
Let me know what you think!

Github: https://github.com/makeworld-the-better-one/amfora
Binaries: https://github.com/makeworld-the-better-one/amfora/releases

makeworld



From martin at no.ucant.org  Fri Jun 19 03:46:56 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Fri, 19 Jun 2020 03:46:56 +0100 (BST)
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <20200618153654.GC2565@SDF.ORG>
References: <20200618153654.GC2565@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2006190329390.18317@pling.qwghlm.org>

On Thu, 18 Jun 2020, solderpunk wrote:

> to boil down to a succinct answer.  I have written up some of my
> thoughts in the traditional long form at:
>
> gemini://gemini.circumlunar.space/~solderpunk/cornedbeef/why-not-just-use-a-subset-of-http-and-html.gmi
>
> I am keen to hear people's thoughts, both on what I've written and on
> the question in general, and receive suggestions on what good responses
> are to people who ask this question.

I have written up a shorter version of roughly the same argument here:

gemini://gemini.ucant.org/meta/why-gemini.gemini

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From hello at matthewgraybosch.com  Fri Jun 19 03:50:38 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 18 Jun 2020 22:50:38 -0400
Subject: [ANN] Amfora, a fancy terminal browser for Gemini
In-Reply-To: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
References: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
Message-ID: <20200618225038.7409a592a086b1894ffa5ade@matthewgraybosch.com>

On Thu, 18 Jun 2020 23:27:51 +0000
colecmac at protonmail.com wrote:

> Hello Geminauts,
> 
> Today I released Amfora, my client for Gemini. It aims to be a great
> looking, featureful browser... all in the terminal. It is similar to
> Bombadillo, but has colors and stylings, *tabbed browsing*, and
> brings in a lot more deps. Sloum, if you're reading this, thanks so
> much for all the work you've done with Bombadillo.

The Linux AMD64 port works fine on my Slackware machines. Good work.

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

From j3s at c3f.net  Fri Jun 19 04:46:33 2020
From: j3s at c3f.net (j3s at c3f.net)
Date: Fri, 19 Jun 2020 03:46:33 +0000
Subject: [ANN] Amfora, a fancy terminal browser for Gemini
In-Reply-To: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
References: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
Message-ID: <01fd12beffa28bc8bef0af5ac817a408@c3f.net>

June 18, 2020 4:27 PM, colecmac at protonmail.com wrote:

> Today I released Amfora, my client for Gemini.

Heck yes, this is amazing - thank you. 

I'll be tracking this project to see how it shapes up, it looks very promising and worked very well on Alpine under WSL.

From defdefred at protonmail.com  Fri Jun 19 07:40:32 2020
From: defdefred at protonmail.com (defdefred)
Date: Fri, 19 Jun 2020 06:40:32 +0000
Subject: Great web site to port to gemini
Message-ID: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>

A good way to make geminispace great is to adapt marvelous web site to gemini browsing.

wikipedia is a must
https://librivox.org/?is excellent

Do you know other?

From koushik at meff.me  Fri Jun 19 07:46:50 2020
From: koushik at meff.me (Koushik Roy)
Date: Thu, 18 Jun 2020 23:46:50 -0700
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
 <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
Message-ID: <0ea5b3bd-7d8e-5cd0-7561-a4815bce1e96@meff.me>

Thank you so much for this page, I was actually planning on starting a 
Lobsters mirror myself before looking at this.

- meff

On 6/17/20 3:45 AM, defdefred wrote:
> Soon a wikipedia mirror?
> 
> :-)
> 
> ??????? Original Message ???????
> On Wednesday 17 June 2020 12:24, <paper at tilde.institute> wrote:
> 
>> On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
>>
>>> On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
>>> Good job with the "Why?" page! You convinced me quickly.
>>> Cheers,
>>> Solderpunk
>>
>> I wasn't sure the Why page was good enough, thanks alot.
>>
>> Paper
> 
> 

From luke at marmaladefoo.com  Fri Jun 19 09:24:56 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 19 Jun 2020 09:24:56 +0100
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <K9fhghmwhRffPDD9qTEqyiwFTkbkTn2-aa3fDfFbe78b9dxTg8UVnIO7PVv8q4F7UjGCuAq4qflKsi4DLBoGDR0Qxi8aErtt7rVyqw18Qjw=@protonmail.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <vrei-zLTbw6kRH7YjqxKVrBbBGSYtdDpa4HkI3JzndDN4XGyj76tqSUc6pvoSHh6y6fxY81spj_DDPhORfgWuh6YmtcPoc9zEgFqNa7FpwU=@protonmail.com>
 <K9fhghmwhRffPDD9qTEqyiwFTkbkTn2-aa3fDfFbe78b9dxTg8UVnIO7PVv8q4F7UjGCuAq4qflKsi4DLBoGDR0Qxi8aErtt7rVyqw18Qjw=@protonmail.com>
Message-ID: <5EEC7658.902@marmaladefoo.com>

Hello

At the moment the themes are fixed, but you can edit them. For example 
if you want an off-white and off-black in the Terminal theme you can 
edit the file Terminal.css in the GmiConverters folder thus:

body {
     background-color: #222827;
     color: #e0e0e0;
     font-family:Consolas,Courier New;
     font-size: 1em;
     margin-left:3.5em;
     margin-right:3.5em;

}

or however you like it. You can change the whole stylesheet if you want.

Best Wishes

  - Luke


On 18-Jun-2020 07:28, defdefred wrote:
> Could it be possible to duplicate CSS files to automaticaly create a new Theme?
> I like to have the writing more grey than brigth white in the terminal theme.
>
> Thanks!

From luke at marmaladefoo.com  Fri Jun 19 09:27:35 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 19 Jun 2020 09:27:35 +0100
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <5EEC7658.902@marmaladefoo.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <vrei-zLTbw6kRH7YjqxKVrBbBGSYtdDpa4HkI3JzndDN4XGyj76tqSUc6pvoSHh6y6fxY81spj_DDPhORfgWuh6YmtcPoc9zEgFqNa7FpwU=@protonmail.com>
 <K9fhghmwhRffPDD9qTEqyiwFTkbkTn2-aa3fDfFbe78b9dxTg8UVnIO7PVv8q4F7UjGCuAq4qflKsi4DLBoGDR0Qxi8aErtt7rVyqw18Qjw=@protonmail.com>
 <5EEC7658.902@marmaladefoo.com>
Message-ID: <5EEC76F7.3000506@marmaladefoo.com>

In fact that will be the default in the next release. Pure white on 
black is a little harsh.

On 19-Jun-2020 09:24, Luke Emmet wrote:
> Hello
>
> At the moment the themes are fixed, but you can edit them. For example 
> if you want an off-white and off-black in the Terminal theme you can 
> edit the file Terminal.css in the GmiConverters folder thus:
>
> body {
>     background-color: #222827;
>     color: #e0e0e0;
>     font-family:Consolas,Courier New;
>     font-size: 1em;
>     margin-left:3.5em;
>     margin-right:3.5em;
>
> }
>
> or however you like it. You can change the whole stylesheet if you want.
>
> Best Wishes
>
>  - Luke
>
>
> On 18-Jun-2020 07:28, defdefred wrote:
>> Could it be possible to duplicate CSS files to automaticaly create a 
>> new Theme?
>> I like to have the writing more grey than brigth white in the 
>> terminal theme.
>>
>> Thanks!

From defdefred at protonmail.com  Fri Jun 19 10:18:23 2020
From: defdefred at protonmail.com (defdefred)
Date: Fri, 19 Jun 2020 09:18:23 +0000
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <5EEC76F7.3000506@marmaladefoo.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <vrei-zLTbw6kRH7YjqxKVrBbBGSYtdDpa4HkI3JzndDN4XGyj76tqSUc6pvoSHh6y6fxY81spj_DDPhORfgWuh6YmtcPoc9zEgFqNa7FpwU=@protonmail.com>
 <K9fhghmwhRffPDD9qTEqyiwFTkbkTn2-aa3fDfFbe78b9dxTg8UVnIO7PVv8q4F7UjGCuAq4qflKsi4DLBoGDR0Qxi8aErtt7rVyqw18Qjw=@protonmail.com>
 <5EEC7658.902@marmaladefoo.com> <5EEC76F7.3000506@marmaladefoo.com>
Message-ID: <cDjWqR9GPLvYfeQKNd7bXP41tEh1O-D3srcnmRFJEJEZcVVOX6rSoq7iH3VYd-C4Xoers8HvW0YlOAta3mK3BLdJL0CVrkxCdOeQZFym0CI=@protonmail.com>

Good!

A simple dark mode could be usefull too... like terminal but with variable font width.

Thanks!

??????? Original Message ???????
On Friday 19 June 2020 10:27, Luke Emmet <luke at marmaladefoo.com> wrote:

> In fact that will be the default in the next release. Pure white on
> black is a little harsh.
>
> On 19-Jun-2020 09:24, Luke Emmet wrote:
>
> > Hello
> > At the moment the themes are fixed, but you can edit them. For example
> > if you want an off-white and off-black in the Terminal theme you can
> > edit the file Terminal.css in the GmiConverters folder thus:
> > body {
> > background-color: #222827;
> > color: #e0e0e0;
> > font-family:Consolas,Courier New;
> > font-size: 1em;
> > margin-left:3.5em;
> > margin-right:3.5em;
> > }
> > or however you like it. You can change the whole stylesheet if you want.
> > Best Wishes
> >
> > -   Luke
> >
> > On 18-Jun-2020 07:28, defdefred wrote:
> >
> > > Could it be possible to duplicate CSS files to automaticaly create a
> > > new Theme?
> > > I like to have the writing more grey than brigth white in the
> > > terminal theme.
> > > Thanks!



From luke at marmaladefoo.com  Fri Jun 19 10:34:31 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 19 Jun 2020 10:34:31 +0100
Subject: [ANN] GemiNaut 0.8.4 released
In-Reply-To: <cDjWqR9GPLvYfeQKNd7bXP41tEh1O-D3srcnmRFJEJEZcVVOX6rSoq7iH3VYd-C4Xoers8HvW0YlOAta3mK3BLdJL0CVrkxCdOeQZFym0CI=@protonmail.com>
References: <5EE1FEE2.4050303@marmaladefoo.com>
 <vrei-zLTbw6kRH7YjqxKVrBbBGSYtdDpa4HkI3JzndDN4XGyj76tqSUc6pvoSHh6y6fxY81spj_DDPhORfgWuh6YmtcPoc9zEgFqNa7FpwU=@protonmail.com>
 <K9fhghmwhRffPDD9qTEqyiwFTkbkTn2-aa3fDfFbe78b9dxTg8UVnIO7PVv8q4F7UjGCuAq4qflKsi4DLBoGDR0Qxi8aErtt7rVyqw18Qjw=@protonmail.com>
 <5EEC7658.902@marmaladefoo.com> <5EEC76F7.3000506@marmaladefoo.com>
 <cDjWqR9GPLvYfeQKNd7bXP41tEh1O-D3srcnmRFJEJEZcVVOX6rSoq7iH3VYd-C4Xoers8HvW0YlOAta3mK3BLdJL0CVrkxCdOeQZFym0CI=@protonmail.com>
Message-ID: <5EEC86A7.2020506@marmaladefoo.com>

It is done - next release :-)

  - Luke

On 19-Jun-2020 10:18, defdefred wrote:
> Good!
>
> A simple dark mode could be usefull too... like terminal but with variable font width.
>
> Thanks!
>
> ??????? Original Message ???????
> On Friday 19 June 2020 10:27, Luke Emmet<luke at marmaladefoo.com>  wrote:
>
>> In fact that will be the default in the next release. Pure white on
>> black is a little harsh.
>>
>> On 19-Jun-2020 09:24, Luke Emmet wrote:
>>
>>> Hello
>>> At the moment the themes are fixed, but you can edit them. For example
>>> if you want an off-white and off-black in the Terminal theme you can
>>> edit the file Terminal.css in the GmiConverters folder thus:
>>> body {
>>> background-color: #222827;
>>> color: #e0e0e0;
>>> font-family:Consolas,Courier New;
>>> font-size: 1em;
>>> margin-left:3.5em;
>>> margin-right:3.5em;
>>> }
>>> or however you like it. You can change the whole stylesheet if you want.
>>> Best Wishes
>>>
>>> -   Luke
>>>
>>> On 18-Jun-2020 07:28, defdefred wrote:
>>>
>>>> Could it be possible to duplicate CSS files to automaticaly create a
>>>> new Theme?
>>>> I like to have the writing more grey than brigth white in the
>>>> terminal theme.
>>>> Thanks!
>

From jmcbray at carcosa.net  Fri Jun 19 13:56:04 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 19 Jun 2020 08:56:04 -0400
Subject: A plan for growing the ecosystem
In-Reply-To: <20200618204811.GB79335@tilde.institute> (paper@tilde.institute's
 message of "Thu, 18 Jun 2020 16:48:11 -0400")
References: <4B0053AB-AD37-40FB-8ADF-84FB8B591618@case.codes>
 <20200618163030.7f3f7528bcc077ca47989828@matthewgraybosch.com>
 <20200618204811.GB79335@tilde.institute>
Message-ID: <87o8pfkye3.fsf@dorothy.carcosa.net>

paper at tilde.institute writes:
> I read a phlog post about 3 months ago where someone was describing
> how they created a template for Hugo which outputs gophermaps, maybe
> we could get inspiration there.

Haha, that was me. I've considered adding support for text/gemini, but
the way my original solution worked, it would only create text/gemini
index pages; the actual content pages don't get converted from whatever
the source was (probably markdown).

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Fri Jun 19 14:15:49 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 19 Jun 2020 09:15:49 -0400
Subject: [ANN] Amfora, a fancy terminal browser for Gemini
In-Reply-To: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
 (colecmac@protonmail.com's message of "Thu, 18 Jun 2020 23:27:51 +0000")
References: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
Message-ID: <87k103kxh6.fsf@dorothy.carcosa.net>

colecmac at protonmail.com writes:

> Hello Geminauts,
>
> Today I released Amfora, my client for Gemini. It aims to be a great looking,
> featureful browser... all in the terminal. It is similar to Bombadillo, but
> has colors and stylings, *tabbed browsing*, and brings in a lot more deps.
> Sloum, if you're reading this, thanks so much for all the work you've done
> with Bombadillo.
>
> I aim to add a lot more features to it over the coming weeks, like bookmarks,
> downloading, header navigation / TOC, client certs, and feed subscribing.
> Let me know what you think!
>
> Github: https://github.com/makeworld-the-better-one/amfora
> Binaries: https://github.com/makeworld-the-better-one/amfora/releases

Neat! The linux-arm7 binary mostly works on my phone (in Termux), but it
looks like it tries to load pages over IPv6, which doesn't exist on my
WiFi network? I can send a screenshot if it would help (I admit that
this is a particularly weird edge case that you may not be interested in
pursuing). 

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From benulo at systemli.org  Fri Jun 19 14:54:47 2020
From: benulo at systemli.org (Ben)
Date: Fri, 19 Jun 2020 18:24:47 +0430
Subject: [ANN] Amfora, a fancy terminal browser for Gemini
In-Reply-To: <87k103kxh6.fsf@dorothy.carcosa.net>
References: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
 <87k103kxh6.fsf@dorothy.carcosa.net>
Message-ID: <865d72ce-f995-3506-c7d2-1d8fb094bac0@systemli.org>

Thanks for providing binaries; that's really helpful!

-- 
gemini://kwiecien.us/

From colecmac at protonmail.com  Fri Jun 19 15:48:04 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 19 Jun 2020 14:48:04 +0000
Subject: [ANN] Amfora, a fancy terminal browser for Gemini
In-Reply-To: <87k103kxh6.fsf@dorothy.carcosa.net>
References: <4IcW48F49PMQgJqADnfu4pAKZvMIh9RLt-XNp7Uvx51mEZix3doBbLDRliXIspm-xjOgihgjBuIbqg0TO12508fqn74r9tqoGYcRB0KCeDo=@protonmail.com>
 <87k103kxh6.fsf@dorothy.carcosa.net>
Message-ID: <meF9h0fowWtPQ5GyeLsTfEjpIDBBZlFQ4CxYFcapQKC5OeZTq6yJKd4NBpHFubWmcW_J_xd4VTENMzSFmKEXzC0dHERVMtP_4S52uSi7T94=@protonmail.com>

Thanks to everyone for the nice responses!

Jason McBrayer wrote:
> Neat! The linux-arm7 binary mostly works on my phone (in Termux), but it
> looks like it tries to load pages over IPv6, which doesn't exist on my
> WiFi network? I can send a screenshot if it would help (I admit that
> this is a particularly weird edge case that you may not be interested in
> pursuing).

I'm not sure why this would happen... I'll accept a screenshot yeah, but this
might be an issue with Go and Android, and not using Android binaries, etc.
My TLS connection doesn't specify any special preference for IPv4 or IPv6.

makeworld


From hello at matthewgraybosch.com  Fri Jun 19 17:48:08 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 19 Jun 2020 12:48:08 -0400
Subject: Great web site to port to gemini
In-Reply-To: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
Message-ID: <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>

On Fri, 19 Jun 2020 06:40:32 +0000
defdefred <defdefred at protonmail.com> wrote:

> Do you know other?

How about Project Gutenberg (gutenberg.org)?

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

From tomasino at lavabit.com  Fri Jun 19 18:28:20 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 19 Jun 2020 17:28:20 +0000
Subject: [ANN] Tiny ad-hoc server
Message-ID: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>

I put up a tiny experiment of an ad-hoc server over on gemini://tomasino.org. The code for the server is on that gemini page for you to inspect and play with. Credit to xq for the concept. It's trivial to implement and may open the door for some folks who don't have a plan of running a big server. It may even be able to work with solderpunk's micro-instance ideas. I'm not sure if there's a way to validate client certs by building on to it, but that would make for easy micro-services.

- tomasino


From solderpunk at SDF.ORG  Fri Jun 19 18:29:34 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 19 Jun 2020 17:29:34 +0000
Subject: Thoughts on TOFU
In-Reply-To: <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
 <20200615073231.GA16765@SDF.ORG>
 <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>
Message-ID: <20200619172934.GA20306@SDF.ORG>

Sorry for letting this thread sit for a while!

On Mon, Jun 15, 2020 at 06:53:49PM +0000, colecmac at protonmail.com wrote:
 
> > I do think that "controlling how servers use certs" is [a good idea]
> 
> This is probably the only way forward, but unfortunately it complicates things.
> It makes Gemini less simple, because people can't stick to what they
> know about certs, or just use the existing one they have for their domain.
> I guess we just have to try and get servers to support this and abstract it
> away.

Well, "different" and "less simple" aren't always the same.  The
automated cron-based approach of Let's Encrypt is *very* different to
what people were used to before it came along, but uptake was swift -
okay, in part because it was free, but also in part because it was
actually easier.  I think that anything which can be implemented as a
cron job is feasible for widespread adoption.  A cron job which does not
communicate with any external machines is arguably even simpler than one
which does.

> > -   Servers can sign their new cert with their previous private key.
> >     Then TOFU clients which accepted the previous cert can validate the
> >     changeover - and then immediately stop trusting the previous cert so
> >     that anybody who stole the private key can't sign their own new cert.
> >     Basically, when you accept a new cert you also grant it one-use-only,
> >     very-limited-scope CA powers.
> 
> BLoCkcHaiN style, nice ;)
> This does mean that servers would have to serve up an ever growing certificate
> chain though? I think? Because otherwise how can a client verify that it was signed.

I hadn't imagined an ever-growing chain, that would soon add up to some
pretty hefty overhead.  I imagined just two or maybe three at most.

> I guess the servers only need to serve up two certs, the previous and current, but
> if I boot up my client after a year, then how does it know whether it just has missed
> some certs in between, or if there's an MITM attack?

It wouldn't!

Let me be clear: TOFU is a very simple security model.  It's totally
decentralised, totally decommercialised, involves no third parties
beyond the server and client and you can deploy it even on weirdo
off-grid wifi meshnets that have no connection to the Real Internet
whatsoever.  It should go without saying that something like this is not
going to give you 100% unconditional authentication of remote
identities under all circumstances.

That doesn't mean it's rubbish.  The CA model doesn't give you 100%
unconditional authentication either (and it certainly don't look simple
once you add in things like OCSP and CT to try and get it closer to that
goal).  In terms of the its ability to protect everyday people from
their greatest realistic privacy threats (things like passive, automated
bulk surveillance by their ISP) compared to its implementation
complexity, I think TOFU can be very worth using.  But you do need to
have realistic expectations: really strengthening it up to the point
where it can address active, targetted attacks will necessarily involve
adding more complexity, and this is the spirit in which I brought up all
the ideas in this thread.

The role of TOFU-based TLS in Gemini is not to offer something
equivalent to TLS on the web, so we can all comfortably send around our
credit card numbers and make bank transfers in Geminispace even though
criminals are actively trying to intercept us.  It's to fix the glaring
defect of Gopher whereby nobody would blame you for being reluctant to
use Gopher to consume:

* serious political activism
* information about a locally-banned religion
* erotic literature
* health advice for stigmatised conditions
* counselling resources for abuse victims

because it would be trivial for your ISP to sell that information to
marketing agencies or report you to people who will haul you off to the
gulag (because if they don't, *they're* at risk of getting hauled off).
Or because if you're using the open wifi network at a cafe or a public
library or an airport, all the other patrons on that network will be
able to see what you're reading.  I believe that people who want/need
to read the above *should* be able to read the above with some degree
of protection, and Gopher lets them down on that point.  I honestly
think this keeps a lot of people who are fed up with all the web's
problems from migrating into Gopherspace.  At the same time, I believe
that fixing this *shouldn't* require complicated and expensive
private infrastructure: Yes, Let's Encrypt is free for the end user
and I'm a big fan, but it costs millions of dollars each year to run
it, most of which comes from corporate sponsors and, ironically, some
of their biggest sponsors are companies like Google and Facebook
that make the money they donate by doing things that *aren't* good for
privacy!

>From this perspective, TOFU provides "good enough" security at a "cheap
enough" price that I feel like it should be treated as a first class
option in Geminispace, and that it's a viable option for a lot of (but
maybe not all) Gemini servers.  It's enough to stop ISPs and sleazy
hotspot providers doing automated MITM attacks on all Gemini traffic,
which they could do if we just accepted whatever certificate came down
the line without any checks whatsoever - all it takes is one customer
with a TOFU client on a machine which routinely moves between networks
(say work and home, or home and the library, whatever) to reveal that
this is happening and raise the alarm.

Thinking about comparatively simple extensions on top of basic TOFU
which can add a little extra security is absolutely worth doing and I
encourage it and that's the spirit in which I've proposed a lot of these
things, like signing new certs with old keys, or pre-announcement of
cert roll-overs.  But I think it makes more sense to ask of these simple
additional layers "do they add protection against some feasible attack
on vanilla TOFU?" and not "are there still some scenarios in which this
is vulnerable?", because the answer to the latter will always be "yes".

For the record, I would not recommend using Gemini for serious life and
death stuff, unless perhaps you're in a situation where you can meet
everybody involved face-to-face and confirm certificate fingerprints in
an offline way.

> > -   Servers can generate their new self-signed cert N months in advance
> >     and, for those N months, advertise the hash of the new cert at a
> >     well-known endpoint, access to which is secured by the current cert.
> >     TOFU clients can notice when an accepted cert is close to expiry and
> >     pre-fetch the future fingerprint.
> 
> The problem is still like what if I miss a cert? Like if my client got cert 1 and
> the hash of cert 2, but by the time I come back online, that site is serving cert 3
> and I don't know whether that's one I should trust or not.

Same response as above, I guess.  Both of these approaches work best
for sites that you visit "regularly", where "regular" is relative to
certificate lifetime.  If you're only going to check in with somewhere
once every few years and have no contact with the people involved
inbetween, it's very hard to maintain trust without involving third
parties.

> DANE seems cool, I want to look into it more. But it will complicate things, and then
> there's DNSSEC, etc etc. I'm guessing it should be avoided for now.

I was surprised at how many people in #gemini said the other day that
they had DNSSEC working for their domains!  But, yes, this is perhaps
the trickiest add-on discussed, because automating it would require
hooking into an API for updating DNS records, and there are many of
those in use so writing a cron-jobbable implementation of this approach
which can be used by the majority of people is not straightforward.
This might be something adopted by a relatively small number of servers
who have some good reason to want to provide additonal assurance to
their visitors.

> > -   We could built Perspectives/Convergence style "notary" servers that
> >     TOFU clients clients can consult when receiving an unrecognised cert.
> >     This was an idea that was developed before it's time, IMHO. Today there
> >     is no reason that achieving broad network perspective requires trusted
> >     third parties and an effective "shadow infrastructure" alongside CAs.
> >     Just run your own certificate observatory on a dirt cheap VPS. Share it
> >     with friends, who share theirs with you. Pubnixes can run then for
> >     their users. Unlike some of the other ideas, this works just as nicely
> >     with CA-signed certs (like those from Let's Encrypt) as self-signed
> >     certs.
> 
> This seems cool, and I want to learn more. How is conflict resolution handled?
> Doesn't this need bootstrapping? It could be a good solution, but still will
> complicate the protocol a lot.

I think this one is cool, too. :)  I plan to code such an observatory
(as a Gemini server itself, naturally!) one day.  I like that it works
well even for CA-signed certs, and that it requires nothing special on
the part of the server admin.

Conflict resolution would, I imagine, be configurable at the client's
end.  You could set it up to raise a red flag unless every observatory
polled had seen the cert in question, or you could accept a cert if more
than N observatories had seen it, whatever you thought was sensible.  I
don't think bootstrapping is needed, observatories can check which cert
they see for a domain fairly quickly when they first receive a query
about it (and thereafter add it to a list to to check on a recurring
basis).

Regarding "complicating the protocol a lot", I certainly don't imagine
*speccing* this or any of the other ideas here as required.  I don't
think consulting remote TLS observatories will be a mainstream thing
the average Geminiaut does.  It will probably mostly be a toy for
privacy and decentralisation geeks, and perhaps something that people
involved in serious activism might pick up once said geeks have gotten
it working smoothly.

> I feel somewhat unsure about the problems I raised here btw, please correct me if
> I've made any mistakes.

I think everything you said, about possible shortcomings of my
proposals, was factually correct!  I think there was just a difference
in expectations of what simple TOFU solutions can provide.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri Jun 19 19:13:21 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 19 Jun 2020 18:13:21 +0000
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <alpine.DEB.2.20.2006190329390.18317@pling.qwghlm.org>
References: <20200618153654.GC2565@SDF.ORG>
 <alpine.DEB.2.20.2006190329390.18317@pling.qwghlm.org>
Message-ID: <20200619181321.GB20306@SDF.ORG>

On Fri, Jun 19, 2020 at 03:46:56AM +0100, Martin Keegan wrote:
> On Thu, 18 Jun 2020, solderpunk wrote:
 
> I have written up a shorter version of roughly the same argument here:
> 
> gemini://gemini.ucant.org/meta/why-gemini.gemini

Thanks for sharing this!  If I end up supplementing a short answer to
this in the FAQ with links to longer pieces on the matter, do you mind
me including this one?

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri Jun 19 19:31:22 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 19 Jun 2020 18:31:22 +0000
Subject: Great web site to port to gemini
In-Reply-To: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
Message-ID: <20200619183122.GA9567@SDF.ORG>

On Fri, Jun 19, 2020 at 06:40:32AM +0000, defdefred wrote:
> A good way to make geminispace great is to adapt marvelous web site to gemini browsing.

This has actually been a contentious idea, historically.  I don't think
anybody is *opposed* to people doing this (although obviously people
should take care regarding copyright), but there is a strong argument to
be made, and many have made it, that if we want to attract people into
Geminispace it's important that they can find good content there that
they *can't* find on the web.

There is, of course, room for both approaches, and making good,
openly-licensed content like Wikipedia, Projet Gutenberg, etc. available
in Geminispace would be great, as per the compelling arguments made at
the recently shared list of web mirrors.

Cheers,
Solderpunk

From colecmac at protonmail.com  Fri Jun 19 19:51:35 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 19 Jun 2020 18:51:35 +0000
Subject: Thoughts on TOFU
In-Reply-To: <20200619172934.GA20306@SDF.ORG>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
 <20200615073231.GA16765@SDF.ORG>
 <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>
 <20200619172934.GA20306@SDF.ORG>
Message-ID: <zRS1CVTZHgzt7Alr2ER4lIMpCS5NW4ZGZcumbFYDyCaCVr4u-z7gpIp6m7v1lTEj4mhPitYyOUUisM4J9oOudOvRwKjoKcrM9J0yAQ1QtQc=@protonmail.com>

Thanks for the well written response! Worth the wait :)

I see now that I have over-analyzed TOFU, thanks for pointing that
out. I think having a mostly secure protocol that works without
a centralized system is a good place to be in, even though reaching
"full" security might be mostly unattainable.

With that in mind, let me look back at those ideas again.

> * Servers can generate their new self-signed cert N months in advance
> and, for those N months, advertise the hash of the new cert at a
> well-known endpoint, access to which is secured by the current cert.
> TOFU clients can notice when an accepted cert is close to expiry and
> pre-fetch the future fingerprint.

This is the one I like the most I think, it seems the simplest. Even simpler
than the signing method, because server don't need to serve multiple certs
and increase the overhead, and clients don't even need to do key validation.

Whether this is specced (as an optional client behaviour) or not, I think
the spirit of "mostly secure" suggests that at the very least, simple clients
should look at cert hash and expiry, and not just the cert public key as Felix
suggested in this thread originally. I think it'd be nice to see this suggestion
in the Best Practices file, if you agree.

Thanks,
makeworld

??????? Original Message ???????
On Friday, June 19, 2020 1:29 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> Sorry for letting this thread sit for a while!
>
> On Mon, Jun 15, 2020 at 06:53:49PM +0000, colecmac at protonmail.com wrote:
>
> > > I do think that "controlling how servers use certs" is [a good idea]
> >
> > This is probably the only way forward, but unfortunately it complicates things.
> > It makes Gemini less simple, because people can't stick to what they
> > know about certs, or just use the existing one they have for their domain.
> > I guess we just have to try and get servers to support this and abstract it
> > away.
>
> Well, "different" and "less simple" aren't always the same. The
> automated cron-based approach of Let's Encrypt is very different to
> what people were used to before it came along, but uptake was swift -
> okay, in part because it was free, but also in part because it was
> actually easier. I think that anything which can be implemented as a
> cron job is feasible for widespread adoption. A cron job which does not
> communicate with any external machines is arguably even simpler than one
> which does.
>
> > > -   Servers can sign their new cert with their previous private key.
> > >     Then TOFU clients which accepted the previous cert can validate the
> > >     changeover - and then immediately stop trusting the previous cert so
> > >     that anybody who stole the private key can't sign their own new cert.
> > >     Basically, when you accept a new cert you also grant it one-use-only,
> > >     very-limited-scope CA powers.
> > >
> >
> > BLoCkcHaiN style, nice ;)
> > This does mean that servers would have to serve up an ever growing certificate
> > chain though? I think? Because otherwise how can a client verify that it was signed.
>
> I hadn't imagined an ever-growing chain, that would soon add up to some
> pretty hefty overhead. I imagined just two or maybe three at most.
>
> > I guess the servers only need to serve up two certs, the previous and current, but
> > if I boot up my client after a year, then how does it know whether it just has missed
> > some certs in between, or if there's an MITM attack?
>
> It wouldn't!
>
> Let me be clear: TOFU is a very simple security model. It's totally
> decentralised, totally decommercialised, involves no third parties
> beyond the server and client and you can deploy it even on weirdo
> off-grid wifi meshnets that have no connection to the Real Internet
> whatsoever. It should go without saying that something like this is not
> going to give you 100% unconditional authentication of remote
> identities under all circumstances.
>
> That doesn't mean it's rubbish. The CA model doesn't give you 100%
> unconditional authentication either (and it certainly don't look simple
> once you add in things like OCSP and CT to try and get it closer to that
> goal). In terms of the its ability to protect everyday people from
> their greatest realistic privacy threats (things like passive, automated
> bulk surveillance by their ISP) compared to its implementation
> complexity, I think TOFU can be very worth using. But you do need to
> have realistic expectations: really strengthening it up to the point
> where it can address active, targetted attacks will necessarily involve
> adding more complexity, and this is the spirit in which I brought up all
> the ideas in this thread.
>
> The role of TOFU-based TLS in Gemini is not to offer something
> equivalent to TLS on the web, so we can all comfortably send around our
> credit card numbers and make bank transfers in Geminispace even though
> criminals are actively trying to intercept us. It's to fix the glaring
> defect of Gopher whereby nobody would blame you for being reluctant to
> use Gopher to consume:
>
> -   serious political activism
> -   information about a locally-banned religion
> -   erotic literature
> -   health advice for stigmatised conditions
> -   counselling resources for abuse victims
>
>     because it would be trivial for your ISP to sell that information to
>     marketing agencies or report you to people who will haul you off to the
>     gulag (because if they don't, they're at risk of getting hauled off).
>     Or because if you're using the open wifi network at a cafe or a public
>     library or an airport, all the other patrons on that network will be
>     able to see what you're reading. I believe that people who want/need
>     to read the above should be able to read the above with some degree
>     of protection, and Gopher lets them down on that point. I honestly
>     think this keeps a lot of people who are fed up with all the web's
>     problems from migrating into Gopherspace. At the same time, I believe
>     that fixing this shouldn't require complicated and expensive
>     private infrastructure: Yes, Let's Encrypt is free for the end user
>     and I'm a big fan, but it costs millions of dollars each year to run
>     it, most of which comes from corporate sponsors and, ironically, some
>     of their biggest sponsors are companies like Google and Facebook
>     that make the money they donate by doing things that aren't good for
>     privacy!
>
>     From this perspective, TOFU provides "good enough" security at a "cheap
>     enough" price that I feel like it should be treated as a first class
>     option in Geminispace, and that it's a viable option for a lot of (but
>     maybe not all) Gemini servers. It's enough to stop ISPs and sleazy
>     hotspot providers doing automated MITM attacks on all Gemini traffic,
>     which they could do if we just accepted whatever certificate came down
>     the line without any checks whatsoever - all it takes is one customer
>     with a TOFU client on a machine which routinely moves between networks
>     (say work and home, or home and the library, whatever) to reveal that
>     this is happening and raise the alarm.
>
>     Thinking about comparatively simple extensions on top of basic TOFU
>     which can add a little extra security is absolutely worth doing and I
>     encourage it and that's the spirit in which I've proposed a lot of these
>     things, like signing new certs with old keys, or pre-announcement of
>     cert roll-overs. But I think it makes more sense to ask of these simple
>     additional layers "do they add protection against some feasible attack
>     on vanilla TOFU?" and not "are there still some scenarios in which this
>     is vulnerable?", because the answer to the latter will always be "yes".
>
>     For the record, I would not recommend using Gemini for serious life and
>     death stuff, unless perhaps you're in a situation where you can meet
>     everybody involved face-to-face and confirm certificate fingerprints in
>     an offline way.
>
>
> > > -   Servers can generate their new self-signed cert N months in advance
> > >     and, for those N months, advertise the hash of the new cert at a
> > >     well-known endpoint, access to which is secured by the current cert.
> > >     TOFU clients can notice when an accepted cert is close to expiry and
> > >     pre-fetch the future fingerprint.
> > >
> >
> > The problem is still like what if I miss a cert? Like if my client got cert 1 and
> > the hash of cert 2, but by the time I come back online, that site is serving cert 3
> > and I don't know whether that's one I should trust or not.
>
> Same response as above, I guess. Both of these approaches work best
> for sites that you visit "regularly", where "regular" is relative to
> certificate lifetime. If you're only going to check in with somewhere
> once every few years and have no contact with the people involved
> inbetween, it's very hard to maintain trust without involving third
> parties.
>
> > DANE seems cool, I want to look into it more. But it will complicate things, and then
> > there's DNSSEC, etc etc. I'm guessing it should be avoided for now.
>
> I was surprised at how many people in #gemini said the other day that
> they had DNSSEC working for their domains! But, yes, this is perhaps
> the trickiest add-on discussed, because automating it would require
> hooking into an API for updating DNS records, and there are many of
> those in use so writing a cron-jobbable implementation of this approach
> which can be used by the majority of people is not straightforward.
> This might be something adopted by a relatively small number of servers
> who have some good reason to want to provide additonal assurance to
> their visitors.
>
> > > -   We could built Perspectives/Convergence style "notary" servers that
> > >     TOFU clients clients can consult when receiving an unrecognised cert.
> > >     This was an idea that was developed before it's time, IMHO. Today there
> > >     is no reason that achieving broad network perspective requires trusted
> > >     third parties and an effective "shadow infrastructure" alongside CAs.
> > >     Just run your own certificate observatory on a dirt cheap VPS. Share it
> > >     with friends, who share theirs with you. Pubnixes can run then for
> > >     their users. Unlike some of the other ideas, this works just as nicely
> > >     with CA-signed certs (like those from Let's Encrypt) as self-signed
> > >     certs.
> > >
> >
> > This seems cool, and I want to learn more. How is conflict resolution handled?
> > Doesn't this need bootstrapping? It could be a good solution, but still will
> > complicate the protocol a lot.
>
> I think this one is cool, too. :) I plan to code such an observatory
> (as a Gemini server itself, naturally!) one day. I like that it works
> well even for CA-signed certs, and that it requires nothing special on
> the part of the server admin.
>
> Conflict resolution would, I imagine, be configurable at the client's
> end. You could set it up to raise a red flag unless every observatory
> polled had seen the cert in question, or you could accept a cert if more
> than N observatories had seen it, whatever you thought was sensible. I
> don't think bootstrapping is needed, observatories can check which cert
> they see for a domain fairly quickly when they first receive a query
> about it (and thereafter add it to a list to to check on a recurring
> basis).
>
> Regarding "complicating the protocol a lot", I certainly don't imagine
> speccing this or any of the other ideas here as required. I don't
> think consulting remote TLS observatories will be a mainstream thing
> the average Geminiaut does. It will probably mostly be a toy for
> privacy and decentralisation geeks, and perhaps something that people
> involved in serious activism might pick up once said geeks have gotten
> it working smoothly.
>
> > I feel somewhat unsure about the problems I raised here btw, please correct me if
> > I've made any mistakes.
>
> I think everything you said, about possible shortcomings of my
> proposals, was factually correct! I think there was just a difference
> in expectations of what simple TOFU solutions can provide.
>
> Cheers,
> Solderpunk



From solderpunk at SDF.ORG  Fri Jun 19 21:03:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 19 Jun 2020 20:03:37 +0000
Subject: Thoughts on TOFU
In-Reply-To: <zRS1CVTZHgzt7Alr2ER4lIMpCS5NW4ZGZcumbFYDyCaCVr4u-z7gpIp6m7v1lTEj4mhPitYyOUUisM4J9oOudOvRwKjoKcrM9J0yAQ1QtQc=@protonmail.com>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
 <20200615073231.GA16765@SDF.ORG>
 <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>
 <20200619172934.GA20306@SDF.ORG>
 <zRS1CVTZHgzt7Alr2ER4lIMpCS5NW4ZGZcumbFYDyCaCVr4u-z7gpIp6m7v1lTEj4mhPitYyOUUisM4J9oOudOvRwKjoKcrM9J0yAQ1QtQc=@protonmail.com>
Message-ID: <20200619200337.GB9567@SDF.ORG>

On Fri, Jun 19, 2020 at 06:51:35PM +0000, colecmac at protonmail.com wrote:
 
> Whether this is specced (as an optional client behaviour) or not, I think
> the spirit of "mostly secure" suggests that at the very least, simple clients
> should look at cert hash and expiry, and not just the cert public key as Felix
> suggested in this thread originally. I think it'd be nice to see this suggestion
> in the Best Practices file, if you agree.

I want to setup an entirely separate document on TOFU practices!  I
don't want to rush into it, though.  I am planning to read this paper
over the weeekend:

https://rp.delaat.net/2012-2013/p56/report.pdf

Feel free to join in!

Cheers,
Solderpunk


From martin at no.ucant.org  Fri Jun 19 22:20:57 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Fri, 19 Jun 2020 22:20:57 +0100 (BST)
Subject: Why there's a point to alternative protocols and spaces
In-Reply-To: <20200619181321.GB20306@SDF.ORG>
References: <20200618153654.GC2565@SDF.ORG>
 <alpine.DEB.2.20.2006190329390.18317@pling.qwghlm.org>
 <20200619181321.GB20306@SDF.ORG>
Message-ID: <alpine.DEB.2.20.2006192220090.18317@pling.qwghlm.org>

On Fri, 19 Jun 2020, solderpunk wrote:

>
> Thanks for sharing this!  If I end up supplementing a short answer to
> this in the FAQ with links to longer pieces on the matter, do you mind
> me including this one?

Yes yes of course! It probably needs a complete rewrite by yet someone 
else, but until then it's good on its own terms.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From colecmac at protonmail.com  Fri Jun 19 22:57:47 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 19 Jun 2020 21:57:47 +0000
Subject: Thoughts on TOFU
In-Reply-To: <20200619200337.GB9567@SDF.ORG>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
 <20200615073231.GA16765@SDF.ORG>
 <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>
 <20200619172934.GA20306@SDF.ORG>
 <zRS1CVTZHgzt7Alr2ER4lIMpCS5NW4ZGZcumbFYDyCaCVr4u-z7gpIp6m7v1lTEj4mhPitYyOUUisM4J9oOudOvRwKjoKcrM9J0yAQ1QtQc=@protonmail.com>
 <20200619200337.GB9567@SDF.ORG>
Message-ID: <acXFFdHqIMz9idGWKi32bh3mc_HGlMLBAXQb4INpt2s1vhg5hLw8zrUpzRLUuoIvmnWZ4Wme2AyI29oJBwEjO7AqKgPHUlC3RNwBC8jIwkA=@protonmail.com>

Oh okay, sounds good! Happy to hear your thoughts later. I'll
check that document out.

Thanks,
makeworld

From pitr.vern at gmail.com  Fri Jun 19 23:46:11 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sat, 20 Jun 2020 00:46:11 +0200
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
 <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
Message-ID: <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>

Wikipedia on Gemini by popular demand:

gemini://wp.pitr.ca/en/Gemini_(constellation)

This is not strictly a mirror, as a dump of wikipedia is quite large -
https://dumps.wikimedia.org/enwiki/20200520/ - but rather a proxy that
makes request to wikipedia API, parses wikitext into an HTML DOM
(since wikitext supports HTML tags) which is then simplified into
text/gemini. This process is not perfect and there are quite a few
imperfections. But before I sink more time into this, I wonder if
text/gemini is indeed the best format for wikipedia articles. Pages
are usually huge, with lots of links. And this is even before
considerations for how best to handle images, tables, special symbols,
special tags, etc. From trying to browse it myself, my first
impression is that wikipedia format can't/shouldn't be simplified any
further than it already is on the web. What do others think?

On Wed, Jun 17, 2020 at 12:45 PM defdefred <defdefred at protonmail.com> wrote:
>
> Soon a wikipedia mirror?
>
> :-)
>
> ??????? Original Message ???????
> On Wednesday 17 June 2020 12:24, <paper at tilde.institute> wrote:
>
> > On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
> >
> > > On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
> > > Good job with the "Why?" page! You convinced me quickly.
> > > Cheers,
> > > Solderpunk
> >
> > I wasn't sure the Why page was good enough, thanks alot.
> >
> > Paper
>
>

From tomasino at lavabit.com  Fri Jun 19 23:56:54 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 19 Jun 2020 22:56:54 +0000
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
 <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
 <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
Message-ID: <e23b4805-0e09-a357-0323-d46fb6a949d4@lavabit.com>

On 6/19/20 10:46 PM, Peter Vernigorov wrote:
> I wonder if
> text/gemini is indeed the best format for wikipedia articles.

I can't answer that definitively, but I can say from experience that gopherpedia is used quite a lot and referenced in gopher phlogs all the time. I suspect gemini will likewise enjoy its existence.

gopher://gopherpedia.com


From colecmac at protonmail.com  Sat Jun 20 01:16:54 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 20 Jun 2020 00:16:54 +0000
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
 <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
 <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
Message-ID: <XnsFTSmro33xjsNUV7LmB74uOkcgVJ2KnMQxo-LBspkX_w-_TGw8vD7i8YB5q_EQo8lnk4UvrOaNlyo-34ovBMZOKe3ojmu_MtHIH9PzVtI=@protonmail.com>

This is very cool and works well, nice work! That's a good way of handling
inline links, I'm going to add that as an option to md2gemini.

Do you think you will add caching to this service, if you haven't already?
Probably would improve response times a lot.

> I wonder if text/gemini is indeed the best format for wikipedia articles.

It is not, mostly because of the lack of inline links. However, you've done
a good job with this mirror/proxy and I'm happy it exists. But in general
I wouldn't recommend text/gemini for wiki type stuff.

makeworld

??????? Original Message ???????
On Friday, June 19, 2020 6:46 PM, Peter Vernigorov <pitr.vern at gmail.com> wrote:

> Wikipedia on Gemini by popular demand:
>
> gemini://wp.pitr.ca/en/Gemini_(constellation)
>
> This is not strictly a mirror, as a dump of wikipedia is quite large -
> https://dumps.wikimedia.org/enwiki/20200520/ - but rather a proxy that
> makes request to wikipedia API, parses wikitext into an HTML DOM
> (since wikitext supports HTML tags) which is then simplified into
> text/gemini. This process is not perfect and there are quite a few
> imperfections. But before I sink more time into this, I wonder if
> text/gemini is indeed the best format for wikipedia articles. Pages
> are usually huge, with lots of links. And this is even before
> considerations for how best to handle images, tables, special symbols,
> special tags, etc. From trying to browse it myself, my first
> impression is that wikipedia format can't/shouldn't be simplified any
> further than it already is on the web. What do others think?
>
> On Wed, Jun 17, 2020 at 12:45 PM defdefred defdefred at protonmail.com wrote:
>
> > Soon a wikipedia mirror?
> > :-)
> > ??????? Original Message ???????
> > On Wednesday 17 June 2020 12:24, paper at tilde.institute wrote:
> >
> > > On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
> > >
> > > > On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
> > > > Good job with the "Why?" page! You convinced me quickly.
> > > > Cheers,
> > > > Solderpunk
> > >
> > > I wasn't sure the Why page was good enough, thanks alot.
> > > Paper



From colecmac at protonmail.com  Sat Jun 20 01:22:13 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 20 Jun 2020 00:22:13 +0000
Subject: Thoughts on TOFU
In-Reply-To: <20200619200337.GB9567@SDF.ORG>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
 <20200615073231.GA16765@SDF.ORG>
 <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>
 <20200619172934.GA20306@SDF.ORG>
 <zRS1CVTZHgzt7Alr2ER4lIMpCS5NW4ZGZcumbFYDyCaCVr4u-z7gpIp6m7v1lTEj4mhPitYyOUUisM4J9oOudOvRwKjoKcrM9J0yAQ1QtQc=@protonmail.com>
 <20200619200337.GB9567@SDF.ORG>
Message-ID: <6sryuWozINyVYejLwUVN1jaP3cqBBuMekO6FO9_pGu9UuxPUI27DnYcCJamvG3fr7wXXyvSv4n3wUavoHJOxM-hBiI28GCeFpR-JtIEtbU4=@protonmail.com>

Two quick takeaways I made that I will add to Amfora:

* The port should be stored in the TOFU database too
* I should be storing the hash of cert.RawSubjectPublicKeyInfo and not cert.Raw


makeworld

??????? Original Message ???????
On Friday, June 19, 2020 4:03 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Fri, Jun 19, 2020 at 06:51:35PM +0000, colecmac at protonmail.com wrote:
>
> > Whether this is specced (as an optional client behaviour) or not, I think
> > the spirit of "mostly secure" suggests that at the very least, simple clients
> > should look at cert hash and expiry, and not just the cert public key as Felix
> > suggested in this thread originally. I think it'd be nice to see this suggestion
> > in the Best Practices file, if you agree.
>
> I want to setup an entirely separate document on TOFU practices! I
> don't want to rush into it, though. I am planning to read this paper
> over the weeekend:
>
> https://rp.delaat.net/2012-2013/p56/report.pdf
>
> Feel free to join in!
>
> Cheers,
> Solderpunk



From sean at conman.org  Sat Jun 20 02:28:10 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 19 Jun 2020 21:28:10 -0400
Subject: Some new tests in the Gemini Client Torture Test
Message-ID: <20200620012810.GO11281@brevard.conman.org>


  I just added 10 new tests to the Gemini Client Torture Test, tests 41
through 50.  They all test section 5.4.1 of the Gemini Specification (text
lines).  Each page contains a line that exceeds 8,500 bytes (yes, bytes, not
characters, although some of then exceed 8,500 characters, depends upon the
characters used).  A few mild spoilers:

	Some have the spaces replaced with dashes.
	Some have no spaces, dashes or any puntuation to speak of.
	Some have Unicode combining characters.

  I do apologize for the snark in test 50, but it represents one of the many
aspects that I dislike about Unicode in general.  

  I expect these tests to be among the hardest to deal with for a client. 
You have been warned.  If anyone thinks these tests are unfair, well, here's
the thread to discuss it.

  -spc


From luke.emmet at gmail.com  Sat Jun 20 08:42:20 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sat, 20 Jun 2020 08:42:20 +0100
Subject: Some new tests in the Gemini Client Torture Test
In-Reply-To: <20200620012810.GO11281@brevard.conman.org>
References: <20200620012810.GO11281@brevard.conman.org>
Message-ID: <5EEDBDDC.1010401@gmail.com>

Hi Sean

Thanks for the new tests - I just ran them on GemiNaut.

I believe my client GemiNaut is doing the right thing for all of them. 
But this is because I'm using a system web browser control to do the 
hard work of the text rendering. Apart from the ones mentioned below 
which I disagree with, it wraps them all as I would expect.

The only quibble I would have with the tests is the ones with no spacers 
at all (43, 46 and 49). I don't agree that the client should try to 
hyphenate the words. Doing so is a non-trivial problem and for a real 
language is very language specific (where are the syllable boundaries 
perhaps). So the correct thing to do is to simply lay them out in a 
non-wrapped line. I don't think there could be any authority about how 
to wrap an arbitrary sequence of unicode points? If there is such a 
thing please say.

So I think for those tests, you should say that the client should not 
crash, but should display either a) as a wrapped link (wrapped any old 
how for those clients that insist on forcing a wrap, perhaps on mobile 
or b) as a single unwrapped line with a scrolling mechanism.

A suggestion for a possible improvement - it would be helpful if there 
was a "back to tests index" link on each page, that way you can choose a 
few tests from the index, then go back to the index when you are done - 
otherwise you might have to go back N times, which is not quite as nice.

Best Wishes

  - Luke

On 20-Jun-2020 02:28, Sean Conner wrote:
>    I just added 10 new tests to the Gemini Client Torture Test, tests 41
> through 50.  They all test section 5.4.1 of the Gemini Specification (text
> lines).  Each page contains a line that exceeds 8,500 bytes (yes, bytes, not
> characters, although some of then exceed 8,500 characters, depends upon the
> characters used).  A few mild spoilers:
>
> 	Some have the spaces replaced with dashes.
> 	Some have no spaces, dashes or any puntuation to speak of.
> 	Some have Unicode combining characters.
>
>    I do apologize for the snark in test 50, but it represents one of the many
> aspects that I dislike about Unicode in general.
>
>    I expect these tests to be among the hardest to deal with for a client.
> You have been warned.  If anyone thinks these tests are unfair, well, here's
> the thread to discuss it.
>
>    -spc
>

From luke at marmaladefoo.com  Sat Jun 20 08:57:42 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 20 Jun 2020 08:57:42 +0100
Subject: Some new tests in the Gemini Client Torture Test
In-Reply-To: <20200620012810.GO11281@brevard.conman.org>
References: <20200620012810.GO11281@brevard.conman.org>
Message-ID: <5EEDC176.5010006@marmaladefoo.com>

Hi Sean

Thanks for the new tests - I think they are all reasonable, even the 
last one.

I just ran them on GemiNaut and I believe it is doing the right thing 
for all of them, which is to wrap at the word, hyphen or soft-hypen. But 
I shouldn't claim much credit, I'm just using a system control to 
display the text content, which does the hard work of rendering the 
unicode into the display.

For tests 43, 46 and 49, it is unclear in the test what you expect 
should happen. Do you just want the client to confirm it doesn't barf on 
the content, but can display it somehow? For these I don't agree that 
the client should try to split the content as doing so is a non-trivial 
problem and for a real language is very language specific (where are the 
syllable boundaries perhaps). So the correct thing to do is to simply 
lay them out in a non-wrapped line. Or if your client takes a hard line 
it could arbitrarily break the content up (perhaps on mobile).

I think the main thing is that the character content is displayed and 
the client can continue. I think the preference should be for an 
unwrapped line with a scrolling mechanism.

A suggestion for a possible improvement - it would be helpful if there 
was a "back to tests index" link on each page, that way you can choose a 
few tests from the index, then go back to the index when you are done - 
otherwise you might have to go back N times, which is not quite as nice.

Best Wishes

  - Luke


On 20-Jun-2020 02:28, Sean Conner wrote:
>    I just added 10 new tests to the Gemini Client Torture Test, tests 41
> through 50.  They all test section 5.4.1 of the Gemini Specification (text
> lines).  Each page contains a line that exceeds 8,500 bytes (yes, bytes, not
> characters, although some of then exceed 8,500 characters, depends upon the
> characters used).  A few mild spoilers:
>
> 	Some have the spaces replaced with dashes.
> 	Some have no spaces, dashes or any puntuation to speak of.
> 	Some have Unicode combining characters.
>
>    I do apologize for the snark in test 50, but it represents one of the many
> aspects that I dislike about Unicode in general.
>
>    I expect these tests to be among the hardest to deal with for a client.
> You have been warned.  If anyone thinks these tests are unfair, well, here's
> the thread to discuss it.
>
>    -spc
>

From sean at conman.org  Sat Jun 20 09:19:03 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 20 Jun 2020 04:19:03 -0400
Subject: Some new tests in the Gemini Client Torture Test
In-Reply-To: <5EEDC176.5010006@marmaladefoo.com>
References: <20200620012810.GO11281@brevard.conman.org>
 <5EEDC176.5010006@marmaladefoo.com>
Message-ID: <20200620081902.GP11281@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
> Hi Sean
> 
> Thanks for the new tests - I think they are all reasonable, even the 
> last one.

  Heh, I was a bit worried about that last one.

> I just ran them on GemiNaut and I believe it is doing the right thing 
> for all of them, which is to wrap at the word, hyphen or soft-hypen. 

  There is a Unicode Line Breaking Algorithm:

	https://www.unicode.org/reports/tr14/

  Warning:  it's long.  Longer than the Gemini specification, and it's in
it's 13th revision.  This is *not* an easy problem.

> But 
> I shouldn't claim much credit, I'm just using a system control to 
> display the text content, which does the hard work of rendering the 
> unicode into the display.
> 
> For tests 43, 46 and 49, it is unclear in the test what you expect 
> should happen. 

  I think "not crash" is a good starting point.  Past that, it's up to the
client.  The way I've done it (in my gopher client) is to just simply wrap
the text (being careful to not break between a glyph codepoint and a
combining codepoint).  Given this:

LoremipsumdolorsitametconsecteturadipiscingelitInlaciniasemperfringillaDonecvehiculafermentummaximusAliquamegetfelisquamCrasegetullamcorpernuncSuspendisseidlaoreetrisusUtaerosmiMaurisaloremposuereelementumjustosedpellentesquequamAeneansagittisquameupretiumporttitorInnecsemaenimvehiculafaucibusAeneanluctusnonloremacblanditIntegertinciduntlectusnecpulvinarcongueestenimpharetraliberoutgravidadolorneque

And a "screen width" of say, 40 characters, you end up with:

Loremipsumdolorsitametconsecteturadipisc
ingelitInlaciniasemperfringillaDonecvehi
culafermentummaximusAliquamegetfelisquam
CrasegetullamcorpernuncSuspendisseidlaor
eetrisusUtaerosmiMaurisaloremposuereelem
entumjustosedpellentesquequamAeneansagit
tisquameupretiumporttitorInnecsemaenimve
hiculafaucibusAeneanluctusnonloremacblan
ditIntegertinciduntlectusnecpulvinarcong
ueestenimpharetraliberoutgravidadolorneq
ue

  Leaving it as one line and side-scrolling is another valid method. 
There's not much you can do in the face of such input.

> Do you just want the client to confirm it doesn't barf on 
> the content, but can display it somehow? 

  Pretty much.  I figure if the client doesn't crash, and does The Right
Thing (even if for some tests quite arbitrary what The Right Thing is), then
it's good to go.

> A suggestion for a possible improvement - it would be helpful if there 
> was a "back to tests index" link on each page, that way you can choose a 
> few tests from the index, then go back to the index when you are done - 
> otherwise you might have to go back N times, which is not quite as nice.

  Sounds like a good idea.  I'll probably have them added in the next day or
so.  Thank you for the suggestion.

  -spc


From luke at marmaladefoo.com  Sat Jun 20 09:19:27 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 20 Jun 2020 09:19:27 +0100
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
 <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
 <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
Message-ID: <5EEDC68F.5030101@marmaladefoo.com>

Hi Peter

That looks great and is worth keeping if you are happy to host it.

The question of what is the equivalent of in-line links in Gemini comes 
up from time to time, either as it is a natural thing that authors want 
to do and already do, or when re-presenting existing markdown or html 
for gemini.

The most common idiom I have seen is the use of square brackets to 
indicate the placemarker in the text line as a citation, followed by a 
link having the reference. For example like this [1] that would be one 
of the subsequent links, or another one [2] that goes to the second one. 
It is a common form seen in many places, such as academic papers with 
footnotes and references.

=> url display text with matching item at end [1]
=> url2 [2] display text with match at beginning

Personally I find this better than simply having the text without any 
clear boundary, as it is clearer where the citation is made. For example 
if you just use a single word it is unclear which usage of it is the 
link anchor. There could even be multiple words that match, and you 
don't want them all implicitly referencing the link. So it is more 
specific this way.

My personal view is that this type of re-wiring-up, to put back the 
links into the text could be a client option, and user choice. Then the 
hotspots in the text could be reinstated. The criteria would be:

1. Link anchor uses the defined pattern e.g.

  - [n] as the first or last item in the display text
  - or more adventurously, matching text in a square bracket as the 
whole link line display text like this: [the thing]

2. After the line is a list of links, and there is a match as the first 
or last word in the display text. Or maybe just in the following content 
(like a list of references at the end of the page)

3. Then the link anchor is wired up to the target

  - optional) the link line is optionally hidden (again user and client 
choice)

It would be nice if the mirroring tools adopted a common convention on 
this, as then clients can do more work to improve the UI for users.

And anyway, this all gracefully degrades and is just a client nicety. It 
could be noted as part of our collective common practice.

Best wishes

  - Luke

On 19-Jun-2020 23:46, Peter Vernigorov wrote:
> Wikipedia on Gemini by popular demand:
>
> gemini://wp.pitr.ca/en/Gemini_(constellation)
>
> This is not strictly a mirror, as a dump of wikipedia is quite large -
> https://dumps.wikimedia.org/enwiki/20200520/ - but rather a proxy that
> makes request to wikipedia API, parses wikitext into an HTML DOM
> (since wikitext supports HTML tags) which is then simplified into
> text/gemini. This process is not perfect and there are quite a few
> imperfections. But before I sink more time into this, I wonder if
> text/gemini is indeed the best format for wikipedia articles. Pages
> are usually huge, with lots of links. And this is even before
> considerations for how best to handle images, tables, special symbols,
> special tags, etc. From trying to browse it myself, my first
> impression is that wikipedia format can't/shouldn't be simplified any
> further than it already is on the web. What do others think?
>
> On Wed, Jun 17, 2020 at 12:45 PM defdefred<defdefred at protonmail.com>  wrote:
>> Soon a wikipedia mirror?
>>
>> :-)
>>
>> ??????? Original Message ???????
>> On Wednesday 17 June 2020 12:24,<paper at tilde.institute>  wrote:
>>
>>> On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
>>>
>>>> On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
>>>> Good job with the "Why?" page! You convinced me quickly.
>>>> Cheers,
>>>> Solderpunk
>>> I wasn't sure the Why page was good enough, thanks alot.
>>>
>>> Paper
>>

From mbays at sdf.org  Sat Jun 20 12:59:00 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sat, 20 Jun 2020 13:59:00 +0200
Subject: fingerprint art
Message-ID: <20200620115900.GB15711@localhost>

I'd like to suggest that, to supplement TOFU, we copy OpenSSH's trick of 
displaying a fingerprint as ASCII art. I just implemented this in my 
client diohsc; here's an example:

```
> g gemini.circumlunar.space
>>> gemini://gemini.circumlunar.space
Certificate chain: DST Root CA X3 >>> Let's Encrypt Authority X3 >>> gemini.circumlunar.space
    +-----[X509]------+           +-----[X509]------+
    |   ..     .      |           |  ... .          |
    |o .  .   . .     |           |   . o .         |
    |+o  . o   o      |           |    o o          |
    |+E   = . =       |           |   . . o         |
    | .  + + ^ .      |           |  . . o ^        |
    |   . + * o       |    >>>    |   + + E         |
    |    . o .        |           |  . @ .          |
    |       .         |           |.o + *           |
    |                 |           |B+..o            |
    +----[SHA256]-----+           +----[SHA256]-----+
Let's Encrypt Authority X     gemini.circumlunar.space
    Expires 2021-03-17            Expires 2020-08-01
25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d
>>> 2bba43d5886f92f4e3f1d0fc1d66d647c2b890965e8088f09d0345649bb5bd25
No previous certificate seen for this host -- trusting provided certificate!
[press a key]
```

The idea is that these pictures are much easier for humans to recognise 
than long hex strings. So even if you don't have the fingerprint you're 
expecting saved to disk, you might be familiar enough with its picture 
that you can recognise if it's changed.

This is using the "drunken bishop" algorithm used by OpenSSH; it's 
pretty straightforward, and described nicely here:
http://www.dirk-loss.de/sshvis/drunken_bishop.pdf
(I'm using this nice haskell implementation:
https://hackage.haskell.org/package/drunken-bishop )

I think it might be nice if we had a cross-client convention to use 
these fingerprint pictures.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200620/8004b10c/attachment.sig>

From solderpunk at SDF.ORG  Sat Jun 20 15:14:34 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 20 Jun 2020 14:14:34 +0000
Subject: Happy birthday, Gemini!
Message-ID: <20200620141434.GA17136@SDF.ORG>

(this message also available in Geminispace at
gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/happy-birthday-gemini.gmi)

Last summer I had been doing a lot of thinking and a lot of writing in
my phlog on the subject of improvements which could be made to gopher,
as part of a wider conversation which was going on in the phlogosphere
at the time.  I wanted to keep following that train of thought, but I
knew that not everybody in the Gopher community was interested, and I
also didn't want the subject to steal too much focus away from the other
things I had been happily phlogging about for years.  So I decided to
start an entirely new section of my gopherhole, and announced in my
phlog that I would be sticking all future posts on the matter of new
protocol design there, in a separate space for those who wanted to
follow it.  In the same announcement, I gave the thing a name for the
first time: Project Gemini!  I made that announcement on June 20th,
2019. 

At the time, I honestly didn't consider the project anything more
than a thought experiment.  I was genuinely shocked when I heard just
two days later on June 22nd that Sean Conner had gone and actually
*implemented* the damn thing and setup a publically accessible Gemini
server at gemini.conman.org.  I'm no less surprised to be writing this
message one year later in the knowledge that Geminispace is just shy of
*one hundred* public servers!  The enthusiasm that Gemini has attracted
and the growth that the community and the space have undergone in the
past year has exceeded my every expectation.

I would like to say "thank you" to everybody who has contributed to
Gemini in a small way or a big way in this time.  Thanks to everybody
who has helped shape the protocol through discussion on the mailing list
(and thanks to the generous host of this this mailing list!); to
everybody who has written a server, or a client, or any other software;
to everybody who is running a Gemini server; to everybody who is
producing content for Geminispace; and to everybody who is helping to
spread awareness of the project.

We've come a long way in the past year, and I think we can rightly be
very proud of what we've built.  Now that the fundamentals of the
protocol have solidified, I am very excited to see what we can achieve
together as we start to shift focus toward building both static and
dynamic content in our new space: the Gemini journey has only just
begun.

Onward and upward!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jun 20 15:45:22 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 20 Jun 2020 14:45:22 +0000
Subject: ANN: deedum a mobile gemini browser
In-Reply-To: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
References: <28e0fb3cdfd4c2173efc909db233769f@case.codes>
Message-ID: <20200620144522.GB17136@SDF.ORG>

On Sat, Jun 13, 2020 at 06:58:44AM +0000, me at case.codes wrote:
 
> It's awaiting review in the android playstore, and I'll be trying to get it building for iOS and
> into the app store. I'll also look into what it takes to get on fdroid.

I was pleased to find just now that Deedum is, indeed, available in the
Playstore!  This is quite a big step in making mobile Gemini browsing
widely accessible, thanks a lot!

Cheers,
Solderpunk

From mbays at sdf.org  Sat Jun 20 15:47:43 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sat, 20 Jun 2020 16:47:43 +0200
Subject: fingerprint art
In-Reply-To: <20200620115900.GB15711@localhost>
References: <20200620115900.GB15711@localhost>
Message-ID: <20200620144743.GA22160@localhost>

The pictures were wrong in my original post, sorry, I was accidentally 
rehashing the hash; in case anyone wants to use them to test their own 
implementation, I believe the correct pictures should be:

```
   +-----[X509]------+         +-----[X509]------+
   |      ..+ooO++   |         |  .*+*o.   .     |
   |       .++Bo+ +  |         |  ..B.. . o . .. |
   |      . oO o.+ o |         |     o . E . ....|
   |       *=.= o o .|         |    ..o + o .o o.|
   |      *.^*E... . |         |    o.oo^..o+.o  |
   |     . +.Boo .   |   >>>   |   . = o.+....   |
   |        o . .    |         |    + * . +      |
   |         o       |         |     B + . .     |
   |        .        |         |    ..=..        |
   +----[SHA256]-----+         +----[SHA256]-----+
Let's Encrypt Authority     gemini.circumlunar.spac
   Expires 2021-03-17          Expires 2020-08-01
```

From petite.abeille at gmail.com  Sat Jun 20 16:00:14 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 20 Jun 2020 17:00:14 +0200
Subject: fingerprint art
In-Reply-To: <20200620115900.GB15711@localhost>
References: <20200620115900.GB15711@localhost>
Message-ID: <E1FCCD13-5D43-4DEE-AEA6-AB4AA69A40C0@gmail.com>



> On Jun 20, 2020, at 13:59, mbays at sdf.org wrote:
> 
> This is using the "drunken bishop" algorithm used by OpenSSH; it's pretty straightforward, and described nicely here:
> http://www.dirk-loss.de/sshvis/drunken_bishop.pdf

Cool.

Further reading related to this technic:

Hash Visualization? a New Technique to improve Real?-World Security
http://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf




From lists at ryliejamesthomas.net  Sat Jun 20 16:43:25 2020
From: lists at ryliejamesthomas.net (rjt)
Date: Sun, 21 Jun 2020 01:43:25 +1000
Subject: Happy birthday, Gemini!
In-Reply-To: <20200620141434.GA17136@SDF.ORG>
References: <20200620141434.GA17136@SDF.ORG>
Message-ID: <9681b757-855e-32e3-4476-5cd6fb0b5a05@ryliejamesthomas.net>

<3

On 21/6/20 12:14 am, solderpunk wrote:
> (this message also available in Geminispace at
> gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/happy-birthday-gemini.gmi)
>
> Last summer I had been doing a lot of thinking and a lot of writing in
> my phlog on the subject of improvements which could be made to gopher,
> as part of a wider conversation which was going on in the phlogosphere
> at the time.  I wanted to keep following that train of thought, but I
> knew that not everybody in the Gopher community was interested, and I
> also didn't want the subject to steal too much focus away from the other
> things I had been happily phlogging about for years.  So I decided to
> start an entirely new section of my gopherhole, and announced in my
> phlog that I would be sticking all future posts on the matter of new
> protocol design there, in a separate space for those who wanted to
> follow it.  In the same announcement, I gave the thing a name for the
> first time: Project Gemini!  I made that announcement on June 20th,
> 2019.
>
> At the time, I honestly didn't consider the project anything more
> than a thought experiment.  I was genuinely shocked when I heard just
> two days later on June 22nd that Sean Conner had gone and actually
> *implemented* the damn thing and setup a publically accessible Gemini
> server at gemini.conman.org.  I'm no less surprised to be writing this
> message one year later in the knowledge that Geminispace is just shy of
> *one hundred* public servers!  The enthusiasm that Gemini has attracted
> and the growth that the community and the space have undergone in the
> past year has exceeded my every expectation.
>
> I would like to say "thank you" to everybody who has contributed to
> Gemini in a small way or a big way in this time.  Thanks to everybody
> who has helped shape the protocol through discussion on the mailing list
> (and thanks to the generous host of this this mailing list!); to
> everybody who has written a server, or a client, or any other software;
> to everybody who is running a Gemini server; to everybody who is
> producing content for Geminispace; and to everybody who is helping to
> spread awareness of the project.
>
> We've come a long way in the past year, and I think we can rightly be
> very proud of what we've built.  Now that the fundamentals of the
> protocol have solidified, I am very excited to see what we can achieve
> together as we start to shift focus toward building both static and
> dynamic content in our new space: the Gemini journey has only just
> begun.
>
> Onward and upward!
>
> Cheers,
> Solderpunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200621/6bde1f7b/attachment.htm>

From petite.abeille at gmail.com  Sat Jun 20 17:04:10 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 20 Jun 2020 18:04:10 +0200
Subject: Happy birthday, Gemini!
In-Reply-To: <20200620141434.GA17136@SDF.ORG>
References: <20200620141434.GA17136@SDF.ORG>
Message-ID: <7C2D337C-4FFF-4AFE-8F13-24F808F83553@gmail.com>



> On Jun 20, 2020, at 16:14, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Onward and upward!

Happy birthday Gemini!

Blast from the past:
http://textfiles.com/100/


From paper at tilde.institute  Sat Jun 20 17:54:45 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Sat, 20 Jun 2020 12:54:45 -0400
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
 <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
 <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
Message-ID: <20200620165445.GD79335@tilde.institute>

Thanks, I added this wikipedia mirror/proxy and Alex's mirror to the
list.

Paper

On Sat, Jun 20, 2020 at 12:46:11AM +0200, Peter Vernigorov wrote:
> Wikipedia on Gemini by popular demand:
> 
> gemini://wp.pitr.ca/en/Gemini_(constellation)
> 
> This is not strictly a mirror, as a dump of wikipedia is quite large -
> https://dumps.wikimedia.org/enwiki/20200520/ - but rather a proxy that
> makes request to wikipedia API, parses wikitext into an HTML DOM
> (since wikitext supports HTML tags) which is then simplified into
> text/gemini. This process is not perfect and there are quite a few
> imperfections. But before I sink more time into this, I wonder if
> text/gemini is indeed the best format for wikipedia articles. Pages
> are usually huge, with lots of links. And this is even before
> considerations for how best to handle images, tables, special symbols,
> special tags, etc. From trying to browse it myself, my first
> impression is that wikipedia format can't/shouldn't be simplified any
> further than it already is on the web. What do others think?
> 
> On Wed, Jun 17, 2020 at 12:45 PM defdefred <defdefred at protonmail.com> wrote:
> >
> > Soon a wikipedia mirror?
> >
> > :-)
> >
> > ??????? Original Message ???????
> > On Wednesday 17 June 2020 12:24, <paper at tilde.institute> wrote:
> >
> > > On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
> > >
> > > > On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
> > > > Good job with the "Why?" page! You convinced me quickly.
> > > > Cheers,
> > > > Solderpunk
> > >
> > > I wasn't sure the Why page was good enough, thanks alot.
> > >
> > > Paper
> >
> >

From petite.abeille at gmail.com  Sat Jun 20 18:35:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 20 Jun 2020 19:35:18 +0200
Subject: =?utf-8?B?8J+GgfCfhbTwn4W7IGxpbms=?=
Message-ID: <42882610-03E8-4B46-9387-F188B3A5937B@gmail.com>

HTML defines the rel attribute for the <link> element: the rel attribute specifies the relationship between the current document and the linked resource.

text/gemini can broadly achieve the same functionality by the expedient of consistently annotating its link lines:

=> gemini://example.org/favicon.png <gemini://example.org/favicon.png> ??? ICON IMAGE/PNG
=> gemini://example.org/atom.xml <gemini://example.org/atom.xml> ??? ALTERNATE APPLICATION/ATOM+XML

There is a pleathora of rel values to choose from:

http://microformats.org/wiki/existing-rel-values <http://microformats.org/wiki/existing-rel-values>

Any interest to flesh this out in more details?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200620/c0411e2b/attachment.htm>

From petite.abeille at gmail.com  Sat Jun 20 18:53:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 20 Jun 2020 19:53:47 +0200
Subject: Great web site to port to gemini
In-Reply-To: <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
 <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
Message-ID: <2D9B5415-F3C8-43B5-8452-32778874AD79@gmail.com>



> On Jun 19, 2020, at 18:48, Matthew Graybosch <hello at matthewgraybosch.com> wrote:
> 
> How about Project Gutenberg (gutenberg.org)?

With matching /gemini/ hardware perhaps:

https://www.vice.com/en_us/article/7x5kpb/anyone-can-build-this-open-source-drm-free-kindle-alternative
https://www.hackster.io/news/the-open-book-an-open-feather-compatible-ebook-2011bffe9ddc
https://github.com/joeycastillo/The-Open-Book






From luke at marmaladefoo.com  Sun Jun 21 14:33:02 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 21 Jun 2020 14:33:02 +0100
Subject: [ANN] GemiNaut 0.8.5 released
Message-ID: <5EEF618E.80807@marmaladefoo.com>

Hi All

Just to let you know there is a new release of GemiNaut out today.

Mostly minor fixes and improvements, but with a new gorgeous dark theme 
and bookmarks, there are both usability and aesthetic improvements for 
everyone. You can also now create your own custom themes if you wish.

More screenshots and downloads on the gemini and web sites:

=> gemini://gemini.marmaladefoo.com/geminaut/
=> https://www.marmaladefoo.com/pages/geminaut

Changes in this version:

* new dark theme, with variable width font, colours are based on dark 
themes of source code editors
* bookmarks - source format is just text/gemini of course
* better vertical spacing - e.g. headings always have space between them 
and surrounding paragraphs
* user definable themes - create your own and drop it in the 
GmiConverters/themes folder
* help files now use text/gemini format and have their own table of contents
* minor style improvements for plain theme

As always, any feedback and suggestions welcome.

Best Wishes

  - Luke

From lenormf.ml at gmail.com  Sun Jun 21 14:49:36 2020
From: lenormf.ml at gmail.com (Frank LENORMAND)
Date: Sun, 21 Jun 2020 16:49:36 +0300
Subject: [ANN] GemiNaut 0.8.5 released
In-Reply-To: <5EEF618E.80807@marmaladefoo.com>
References: <5EEF618E.80807@marmaladefoo.com>
Message-ID: <159274737669.2727245.13178353740623233928@localhost.localdomain>

On Sun Jun 21 16:33:02 2020, Luke Emmet wrote:
> Just to let you know there is a new release of GemiNaut out today.
> 
> Mostly minor fixes and improvements, but with a new gorgeous dark theme 
> and bookmarks, there are both usability and aesthetic improvements for 
> everyone. You can also now create your own custom themes if you wish.
> 
> More screenshots and downloads on the gemini and web sites:
> 
> => gemini://gemini.marmaladefoo.com/geminaut/
> => https://www.marmaladefoo.com/pages/geminaut
> 
> Changes in this version:
> 
> * new dark theme, with variable width font, colours are based on dark 
> themes of source code editors
> * bookmarks - source format is just text/gemini of course
> * better vertical spacing - e.g. headings always have space between them 
> and surrounding paragraphs
> * user definable themes - create your own and drop it in the 
> GmiConverters/themes folder
> * help files now use text/gemini format and have their own table of contents
> * minor style improvements for plain theme
> 
> As always, any feedback and suggestions welcome.

It's a bit ironic that theming relies on HTML and CSS.

I think there's room here for a minimal language that would allow applying
colours/decoration to arbitrary Gemini contents without depending on the
HTML/CSS pair.

I don't have any suggestions (yet), but I think Gemini browser authors
have an opportunity to come up with a minimalist syntax geared for Gemini
contents that isn't as convoluted and rich as CSS.

What do you think?

Regards,
-- 
Frank LENORMAND

From luke at marmaladefoo.com  Sun Jun 21 16:18:50 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 21 Jun 2020 16:18:50 +0100
Subject: [ANN] GemiNaut 0.8.5 released
In-Reply-To: <159274737669.2727245.13178353740623233928@localhost.localdomain>
References: <5EEF618E.80807@marmaladefoo.com>
 <159274737669.2727245.13178353740623233928@localhost.localdomain>
Message-ID: <5EEF7A5A.1050602@marmaladefoo.com>


On 21-Jun-2020 14:49, Frank LENORMAND wrote:
> On Sun Jun 21 16:33:02 2020, Luke Emmet wrote:
>> Just to let you know there is a new release of GemiNaut out today.
>>
>> Mostly minor fixes and improvements, but with a new gorgeous dark theme
>> and bookmarks, there are both usability and aesthetic improvements for
>> everyone. You can also now create your own custom themes if you wish.
> It's a bit ironic that theming relies on HTML and CSS.
Perhaps, but I don't think so. HTML and CSS is just an implementation 
detail that allows for a very flexible way to present structured textual 
content. I'd rather focus on building the nicest experience that 
focusses on readability in a broad sense.

To express the elements needed for building the user experience in 
GemiNaut I would need: font colour, font face, font size, padding, 
margin, border, underline, hanging indent, block float, text wrap 
behaviour, tooltips. I think I've just reinvented a wheel, and now I 
need to invent a layout and behavioural engine to interpret said 
language. Hang on, my OS can do that for me, so I can spend more time 
thinking about other stuff...

My intention in creating the themes in GemiNaut is to provide some good 
ones that will suit a wide range of users, but once you have that 
flexibility it seems no reason not to let users do their own if they 
have strong opinions on typesetting and layout etc.

> I think there's room here for a minimal language that would allow applying
> colours/decoration to arbitrary Gemini contents without depending on the
> HTML/CSS pair.
Might be nice, but I'm not sure its necessary or whether it would be 
widely adopted by all the different clients. Each client is going to 
have its own options for how content is styled and presented. Its not 
just about H1 font and colour is X + Y.
> I don't have any suggestions (yet), but I think Gemini browser authors
> have an opportunity to come up with a minimalist syntax geared for Gemini
> contents that isn't as convoluted and rich as CSS.
>
> What do you think?
I think you might as well start from a subset of CSS if you want the 
flexibility beyond basic styles. Or if you want something basic, maybe 
just a list of fonts colours and sizes. But that still leaves out 
elements of whitespace, margins etc.

Best Wishes

  - Luke

From felix at masterq32.de  Sun Jun 21 22:52:21 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sun, 21 Jun 2020 23:52:21 +0200
Subject: [ANN] Kristall Small-Internet Browser V0.3 released
In-Reply-To: <4b9c5068-90c0-b8eb-71dc-0628a07cdb5a@masterq32.de>
References: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
 <4b9c5068-90c0-b8eb-71dc-0628a07cdb5a@masterq32.de>
Message-ID: <f57e388a-a59c-0bc0-c006-ca88f8dd71f5@masterq32.de>

Hey!

Two weeks ago was the last release of Kristall, and now the next release
is finished:

Kristall 0.3

Major new features:
* Client certificate support
* TLS management with TOFU, CA and manual trust for HTTPS and Gemini
* Improved network management, now yielding better error messages
* Now supports non-UTF-8 encodings via iconv

In general, the 0.3 release is focused on security while surfing and
enables you to take control of Kristalls behaviour.

You can fetch the source release at GitHub [0].

As usual, i'm happy about feedback and patches!

Regards
- xq

[0] - https://github.com/MasterQ32/kristall/releases/tag/V0.3

From colecmac at protonmail.com  Mon Jun 22 04:34:13 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 22 Jun 2020 03:34:13 +0000
Subject: Proposal: Stream status code
Message-ID: <sRvtbQm6-LAk6jJWeE9WfkK3DDO8j77AoaoaN0Y5yQNkK3Wtcyr-YZgh3mqU60edPuXtfHS2Ua00rGqDa3gJc6wh0Yd2sh3NNEDdwX_5clc=@protonmail.com>

On IRC today there was some discussion about how there should be a way
to tell clients when content is being streamed. This comes on the heels
of Mozz's post and demo of streaming, where he has an IRC-style chat on
Gemini.

gemini://mozz.us/journal/2020-06-21.gmi
gemini://chat.mozz.us

Many of the current clients, such as Kristall, implement a timeout on the
server sending data, it's even part of the Egsam client test. It'd be nice
to be able to know when data is being streamed or when it comes to end, for
things like downloads as well.

It was krixano on IRC who brought this all up and suggested a new 2x status
code for this purpose. Maybe status 22, since 21 used to be for certs?

What do you think?

makeworld



From benulo at systemli.org  Mon Jun 22 08:12:31 2020
From: benulo at systemli.org (Ben)
Date: Mon, 22 Jun 2020 11:42:31 +0430
Subject: [ANN] Kristall Small-Internet Browser V0.3 released
In-Reply-To: <f57e388a-a59c-0bc0-c006-ca88f8dd71f5@masterq32.de>
References: <5deabbec-82cd-0bc2-d771-be5e4d7a7ad0@masterq32.de>
 <4b9c5068-90c0-b8eb-71dc-0628a07cdb5a@masterq32.de>
 <f57e388a-a59c-0bc0-c006-ca88f8dd71f5@masterq32.de>
Message-ID: <1589ae2b-1c81-9dfb-2191-d600b1a5a5b1@systemli.org>

Congratulations! I've been tracking Kristall on git and the rate of its 
development is very impressive. It's also one of my favorite clients so far.

-- 
gemini://kwiecien.us/

From solderpunk at SDF.ORG  Mon Jun 22 09:15:31 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 22 Jun 2020 08:15:31 +0000
Subject: Away from list for a few days
Message-ID: <20200622081531.GA13190@SDF.ORG>

Hey all,

As part of my summer vacation I'm going to be away from civilisation for
three or four days starting in just a few hours.  I will catch up on
mailing list traffic when I get back, just wanted to let people know not
to expect quick responses to anything for a while.  Try not to burn the
place down, and keep writing wonderful Gemini content!

Cheers,
Solderpunk

From defdefred at protonmail.com  Mon Jun 22 09:53:02 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 22 Jun 2020 08:53:02 +0000
Subject: Article talking about Gemini
Message-ID: <RaizkUZRcdSCoi7xPaDm_YFBbWfXYUiUS_Wqak3KPVQ6PsRmcG5Ls6imKWFLITbeLhpejPOp4knne18oTZXH4hWo331W0mmp8pGcie3YU9Q=@protonmail.com>

https://cheapskatesguide.org/articles/beauty-of-text.html

freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200622/2a7a62b7/attachment.htm>

From defdefred at protonmail.com  Mon Jun 22 10:18:46 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 22 Jun 2020 09:18:46 +0000
Subject: [ANN] GemiNaut 0.8.5 released
In-Reply-To: <5EEF7A5A.1050602@marmaladefoo.com>
References: <5EEF618E.80807@marmaladefoo.com>
 <159274737669.2727245.13178353740623233928@localhost.localdomain>
 <5EEF7A5A.1050602@marmaladefoo.com>
Message-ID: <suaqCRaXR9KKgzJZFY-deMrmyynQrdP9_UzX5WxdXoSNJbdHClB4BO_9X3rO0sB2MrYkeRZmyJVRXh7R3wB8js7HOU2ATqIKThxBa-wBvZg=@protonmail.com>

Thanks for your work!

Thought: TOC could be accessible via application menu rather then inside the document...

freD.


From defdefred at protonmail.com  Mon Jun 22 10:23:50 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 22 Jun 2020 09:23:50 +0000
Subject: Thoughts on TOFU
In-Reply-To: <20200619200337.GB9567@SDF.ORG>
References: <3f96a5ee-3ade-cb1d-40a0-ea6c77ed1441@masterq32.de>
 <kr1OrJ-cleGQ6seQsq7daH9N5pdBufwiHbkTBSw5IYv_bVUEP4mmXix2RVrZmKKWfRYAN7LallLyCZVxaYXCQ6JmuAsRf94DwSgCND1EbJQ=@protonmail.com>
 <20200615073231.GA16765@SDF.ORG>
 <Z-lCPOETzWlwXWZly7mBB27iQIb1IFuDurIrsGOrVEWzVonLnFHXP7ZwzIMJRtACAfjIA8riLb3rSinbTe5UYC32_1frBSsV3qW3WPa8org=@protonmail.com>
 <20200619172934.GA20306@SDF.ORG>
 <zRS1CVTZHgzt7Alr2ER4lIMpCS5NW4ZGZcumbFYDyCaCVr4u-z7gpIp6m7v1lTEj4mhPitYyOUUisM4J9oOudOvRwKjoKcrM9J0yAQ1QtQc=@protonmail.com>
 <20200619200337.GB9567@SDF.ORG>
Message-ID: <R8RggVgjCGj8b-FjrjhiWBWkXW94aGjmXi_9LNUEWYrRNdAciz8Bqbzr4KrUB58KBRE2dAQLfmowMhrt3MFuu2Ey4CaY2G91wQb-Z6NDGnY=@protonmail.com>

Maybe some trusted gemini server could also propose a dedicated page with known certificat from gemini server.

If all truster server give the same certificat, it's giving a higher level of security.

TOFU to get the bytes and multiple trusted servers to valid the bites?

freD.

From defdefred at protonmail.com  Mon Jun 22 11:47:57 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 22 Jun 2020 10:47:57 +0000
Subject: Wikipedia through Gemini
Message-ID: <5xj8AMhJLSLCICO-RbzsvbCYEHbBLdcZgkG2wMJguOpM3RXFhXcMQ_KYg6obkRTRwFZGmZOh9mWIZJmiZuI7lzt5fYpXsmWxOwP_zbyLBJY=@protonmail.com>

Seems that a Gemini reference is missing...

gemini://wp.pitr.ca/en/Gemini

Don't you think so?
freD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200622/4fb62879/attachment.htm>

From pitr.vern at gmail.com  Mon Jun 22 12:35:10 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Mon, 22 Jun 2020 13:35:10 +0200
Subject: Wikipedia through Gemini
In-Reply-To: <5xj8AMhJLSLCICO-RbzsvbCYEHbBLdcZgkG2wMJguOpM3RXFhXcMQ_KYg6obkRTRwFZGmZOh9mWIZJmiZuI7lzt5fYpXsmWxOwP_zbyLBJY=@protonmail.com>
References: <5xj8AMhJLSLCICO-RbzsvbCYEHbBLdcZgkG2wMJguOpM3RXFhXcMQ_KYg6obkRTRwFZGmZOh9mWIZJmiZuI7lzt5fYpXsmWxOwP_zbyLBJY=@protonmail.com>
Message-ID: <CAG-mZ3irCKW2bPHVtjP7AXDQw1usXabeSPuwJg7nrjYvbEBrGA@mail.gmail.com>

Do you mean that there is no Wikipedia article about Gemini protocol?

On Mon, Jun 22, 2020 at 12:48 PM defdefred <defdefred at protonmail.com> wrote:
>
> Seems that a Gemini reference is missing...
>
> gemini://wp.pitr.ca/en/Gemini
>
> Don't you think so?
> freD

From pitr.vern at gmail.com  Mon Jun 22 14:29:33 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Mon, 22 Jun 2020 15:29:33 +0200
Subject: [ANN] List of Gemini web mirrors
In-Reply-To: <5EEDC68F.5030101@marmaladefoo.com>
References: <20200617095657.4l6tfh3in4em4677@tilde.institute>
 <20200617101758.GC6870@SDF.ORG>
 <20200617102411.kp5wlksgsokvsvoi@tilde.institute>
 <j1xvdIJ2Zgg9eVlc2P_VC17fT01zlVcl0taKgm340MrVpDu-uc_f1XNQTT4wWy4dgmqnkZOMLrD5sayoDpBEGT8PgH3D1ivnXRmXMIoxiMw=@protonmail.com>
 <CAG-mZ3g71sRRmt62JeFwywD3q39vSq=0JgCVXfPWbaRx1X5v+Q@mail.gmail.com>
 <5EEDC68F.5030101@marmaladefoo.com>
Message-ID: <CAG-mZ3jc--or3SkFNRDemXOhMFeanRifF=RiStHzpsnJkQGQ_A@mail.gmail.com>

Thanks for feedback, Luke. I initially went with the [N] syntax. What
I found out was that "url [1]" does not work because of things like
"[constellation]s" becoming "constellation [1]s". "[1] url" is not
ideal either, as some clients, like av98, would already have a link
counter, and since I have a 2 links hardcoded at the top of the page
to search and home, I ended up needing to increment link counter by 2,
and even then it would be rendered as "[22] [22] name". In the end I
changed it to "... [url] ..." so the reader knows that they can get
more info by finding the link at the end of the paragraph. Hopefully
it's a good compromise.

On Sat, Jun 20, 2020 at 10:19 AM Luke Emmet <luke at marmaladefoo.com> wrote:
>
> Hi Peter
>
> That looks great and is worth keeping if you are happy to host it.
>
> The question of what is the equivalent of in-line links in Gemini comes
> up from time to time, either as it is a natural thing that authors want
> to do and already do, or when re-presenting existing markdown or html
> for gemini.
>
> The most common idiom I have seen is the use of square brackets to
> indicate the placemarker in the text line as a citation, followed by a
> link having the reference. For example like this [1] that would be one
> of the subsequent links, or another one [2] that goes to the second one.
> It is a common form seen in many places, such as academic papers with
> footnotes and references.
>
> => url display text with matching item at end [1]
> => url2 [2] display text with match at beginning
>
> Personally I find this better than simply having the text without any
> clear boundary, as it is clearer where the citation is made. For example
> if you just use a single word it is unclear which usage of it is the
> link anchor. There could even be multiple words that match, and you
> don't want them all implicitly referencing the link. So it is more
> specific this way.
>
> My personal view is that this type of re-wiring-up, to put back the
> links into the text could be a client option, and user choice. Then the
> hotspots in the text could be reinstated. The criteria would be:
>
> 1. Link anchor uses the defined pattern e.g.
>
>   - [n] as the first or last item in the display text
>   - or more adventurously, matching text in a square bracket as the
> whole link line display text like this: [the thing]
>
> 2. After the line is a list of links, and there is a match as the first
> or last word in the display text. Or maybe just in the following content
> (like a list of references at the end of the page)
>
> 3. Then the link anchor is wired up to the target
>
>   - optional) the link line is optionally hidden (again user and client
> choice)
>
> It would be nice if the mirroring tools adopted a common convention on
> this, as then clients can do more work to improve the UI for users.
>
> And anyway, this all gracefully degrades and is just a client nicety. It
> could be noted as part of our collective common practice.
>
> Best wishes
>
>   - Luke
>
> On 19-Jun-2020 23:46, Peter Vernigorov wrote:
> > Wikipedia on Gemini by popular demand:
> >
> > gemini://wp.pitr.ca/en/Gemini_(constellation)
> >
> > This is not strictly a mirror, as a dump of wikipedia is quite large -
> > https://dumps.wikimedia.org/enwiki/20200520/ - but rather a proxy that
> > makes request to wikipedia API, parses wikitext into an HTML DOM
> > (since wikitext supports HTML tags) which is then simplified into
> > text/gemini. This process is not perfect and there are quite a few
> > imperfections. But before I sink more time into this, I wonder if
> > text/gemini is indeed the best format for wikipedia articles. Pages
> > are usually huge, with lots of links. And this is even before
> > considerations for how best to handle images, tables, special symbols,
> > special tags, etc. From trying to browse it myself, my first
> > impression is that wikipedia format can't/shouldn't be simplified any
> > further than it already is on the web. What do others think?
> >
> > On Wed, Jun 17, 2020 at 12:45 PM defdefred<defdefred at protonmail.com>  wrote:
> >> Soon a wikipedia mirror?
> >>
> >> :-)
> >>
> >> ??????? Original Message ???????
> >> On Wednesday 17 June 2020 12:24,<paper at tilde.institute>  wrote:
> >>
> >>> On Wed, Jun 17, 2020 at 10:17:58AM +0000, solderpunk wrote:
> >>>
> >>>> On Wed, Jun 17, 2020 at 05:56:57AM -0400, paper at tilde.institute wrote:
> >>>> Good job with the "Why?" page! You convinced me quickly.
> >>>> Cheers,
> >>>> Solderpunk
> >>> I wasn't sure the Why page was good enough, thanks alot.
> >>>
> >>> Paper
> >>

From colecmac at protonmail.com  Mon Jun 22 22:36:16 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 22 Jun 2020 21:36:16 +0000
Subject: Golang percent encoding
Message-ID: <u4RAaMtZBWaA_xkvMt0dDVRUv8TNy-yRYkaL-Da2f4GoHU7OHNrv-5HXcbIRXM2JivtHTLvW6q6_GD9C1Ctg4xRvc9YrwS0OEnmwjZE7A0Y=@protonmail.com>

Just wanted to let other Gemini Go coders know something about encoding
query strings. The Gemini spec mandates percent coding, so you should be
using url.PathEscape and url.PathUnescape to deal with queries, and NOT
url.QueryEscape and url.QueryUnescape.

However, there's one more thing. url.PathEscape does not replace +
characters, although to ensure compatibility, it probably should. Here's
the function I use in all my projects to escape queries:

func pathEscape(path string) string {
	return strings.ReplaceAll(url.PathEscape(path), "+", "%2B")
}

This is simple, but seems to work perfectly. url.PathUnescape will still
work fine for decoding.

Cheers,
makeworld



From colecmac at protonmail.com  Tue Jun 23 00:12:26 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 22 Jun 2020 23:12:26 +0000
Subject: [ANN] gemget v1.2.0
Message-ID: <LUINTjJQQ5D46MLQXjXOOzm3oc1XYK9WWrDTXUcgdMv_flbm4rXRl1q1-q6CPndBtLIV2O6pTyoG-NYDrE5SIaZ4ZdMcv_eMu7L_tkQ7Kj0=@protonmail.com>

Just a quick announcement, I've released a new version of gemget,
v1.2.0. This works with self-signed certs a lot better, you should
definitely update!

https://github.com/makeworld-the-better-one/gemget/releases/tag/v1.2.0

I don't plan on crowding the mailing list with any future updates if they
come, so your best bet is to subscribe to releases on Github.

I also recommend that for any of my other software, like md2gemini,
Amfora, and gemlikes.

Thanks,
makeworld



From hello at matthewgraybosch.com  Tue Jun 23 03:06:53 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Mon, 22 Jun 2020 22:06:53 -0400
Subject: Great web site to port to gemini
In-Reply-To: <8-glswtVejVS7IfX2tIYjHWHGfDkxCQo-nIksch-3bJo2RpaFQJPAs_Cj3angduDw11NLloShZfxAhu62VW7m4NdCi-JTAMkFgl9BaxWK9Q=@protonmail.com>
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
 <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
 <8-glswtVejVS7IfX2tIYjHWHGfDkxCQo-nIksch-3bJo2RpaFQJPAs_Cj3angduDw11NLloShZfxAhu62VW7m4NdCi-JTAMkFgl9BaxWK9Q=@protonmail.com>
Message-ID: <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>

On Mon, 22 Jun 2020 10:39:22 +0000
defdefred <defdefred at protonmail.com> wrote:

> On Friday 19 June 2020 18:48, Matthew Graybosch
> > How about Project Gutenberg (gutenberg.org)?
> 
> Yes!
> and with the plain text utf-8 books, no need to quit the gemini
> browser.

Got a small proof-of-concept going on gemini://tanelorn.city/library/,
but it's hand-curated. Doing a full mirror would take over 42GB just
for the texts.

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

From philanc at gmail.com  Tue Jun 23 05:46:11 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Tue, 23 Jun 2020 04:46:11 +0000
Subject: Mercury
Message-ID: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>

Hi all,

I have very recently discovered Gemini, so I am late at the party, but
very excited by the Gemini concept and philosophy.

At the same time, I am a bit disappointed by the mandatory use of TLS
in the protocol. It seems _so_ at odds with the overall philosophy and
simplicity of Gemini...  But I _do_ understand that there is momentum
behind TLS usage.

Looking for discussion about this TLS issue, I found in a message by
Petite Abeille [1] a link to the Mercury document [2] by Solderpunk.

I don't know when it was published and couldn't find a discussion
about Mercury (i.e. Gemini without TLS)

What I would like to know:

* is the Mercury document an old document that has been already
discussed and the concept discarded?  (any link to the discussion?)

* is the concept still "alive"?  is the document still "open for comments"?

* are there Gemininauts interested in Mercury?

* are there clients and servers targeting both Gemini and Mercury?
(i.e. the Gemini concept with and without TLS)

* has a solution been proposed for the two protocols coexistence?
(e.g. port 1965 for Gemini and 1963 for Mercury  (the year of the last
Mercury flight :-)

I am sorry if it has already been hashed and rehashed. And thanks in
advance for your answers about any of the points above

Phil

[1] https://lists.orbitalfox.eu/archives/gemini/2020/001237.html

[2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi

From b__m__e at mailfence.com  Tue Jun 23 07:14:09 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Tue, 23 Jun 2020 08:14:09 +0200 (CEST)
Subject: [ANN] Geminews: News feeds over gemini
Message-ID: <1359073644.788024.1592892849105@ichabod.co-bxl>

Hi all,
I have mostly been stepping away from gemini development, mostly in favor of making non-gemini-specific improvements 
to my existing software proejcts and also in favor of adding things to read to the gemini-sphere. Toward the later I have
set up some news scraping similar to floodgaps "flood feeds" section.

If you would like to get some news over gemini head to:

gemini://rawtext.club/~sloum/geminews/

Currently I am scraping: NPR, CNN, and Christian Science Monitor (which actually has some quality reporting even if I
do not ascribe to their beliefs in general). If I end up with time I may add to this list, but that should give a taste of what
is going on from a few different sources.

Enjoy.

From defdefred at protonmail.com  Tue Jun 23 09:33:03 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 23 Jun 2020 08:33:03 +0000
Subject: Mercury
In-Reply-To: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
Message-ID: <jWxJR2hFxPgDN7TqKJtgZ3Foti3a7MA6qf-9GOxn35ElULGwTyToGQYgu7jSmB0JVXkSQyuW73vFf2AFsPl7BAAcKFVdCj17ZNWdhIUpxI8=@protonmail.com>

On Tuesday 23 June 2020 06:46, Phil Leblanc <philanc at gmail.com> wrote:
>     [2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi

Hey thanks!
I totally miss this post about mercury.

This is very interesting and address small network bandwidth / small computer ressources / frugal energy usage issue.

Seems that the protocol specification should be separate from the text format protocol (true for gemini too).

freD.

From defdefred at protonmail.com  Tue Jun 23 09:43:59 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 23 Jun 2020 08:43:59 +0000
Subject: [ANN] Geminews: News feeds over gemini
In-Reply-To: <1359073644.788024.1592892849105@ichabod.co-bxl>
References: <1359073644.788024.1592892849105@ichabod.co-bxl>
Message-ID: <4B_5DLGOof7gs9bJ2chZkK6YxINfmJ9RuZJWho0PBLNyZNjt1Fj5JAivoZQ8T-9IH4sdxcXICJeWtkImIWjWYBwN45lfpXY-3rb9x5lBBbw=@protonmail.com>

thanks!

From felix at masterq32.de  Tue Jun 23 09:53:44 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 23 Jun 2020 10:53:44 +0200
Subject: Mercury
In-Reply-To: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
Message-ID: <3c31de1f-91cd-b59d-7e96-c99614606c76@masterq32.de>

Hey!

> * is the concept still "alive"?  is the document still "open for
comments"?

I think Mercury was just a thought experiment, but it sounds like we can
spec that out to be fully usable (specify port and such)

> * are there Gemininauts interested in Mercury?
Yeah, definitly. It sounds like the perfect match for embedded devices,
as it requires no encryption and no complex state machines.

> * are there clients and servers targeting both Gemini and Mercury?
> (i.e. the Gemini concept with and without TLS)
Probably in some hours? I'm really tempted to implement a mercury://
into Kristall and provide people a client they can use :)

> * has a solution been proposed for the two protocols coexistence?
> (e.g. port 1965 for Gemini and 1963 for Mercury  (the year of the last
> Mercury flight :-)

> I am sorry if it has already been hashed and rehashed. And thanks in
> advance for your answers about any of the points above
To my knowledge we haven't had a discussion about Mercury yet and it's
simple enough to "just be used"

Regards
- xq

From defdefred at protonmail.com  Tue Jun 23 10:13:34 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 23 Jun 2020 09:13:34 +0000
Subject: Mercury
In-Reply-To: <jWxJR2hFxPgDN7TqKJtgZ3Foti3a7MA6qf-9GOxn35ElULGwTyToGQYgu7jSmB0JVXkSQyuW73vFf2AFsPl7BAAcKFVdCj17ZNWdhIUpxI8=@protonmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <jWxJR2hFxPgDN7TqKJtgZ3Foti3a7MA6qf-9GOxn35ElULGwTyToGQYgu7jSmB0JVXkSQyuW73vFf2AFsPl7BAAcKFVdCj17ZNWdhIUpxI8=@protonmail.com>
Message-ID: <65mi_qqNunQ6rpTHvMtqTudmECU2CMNdBD7HSYImU7WViqnism8AuDtIaGaIGgNprFGCx25UntjxuddyourA0B1aAoPM-i6R4wCPVRlfPaU=@protonmail.com>

On Tuesday 23 June 2020 10:33, defdefred <defdefred at protonmail.com> wrote:

> On Tuesday 23 June 2020 06:46, Phil Leblanc philanc at gmail.com wrote:
>
> >     [2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cornedbeef/the-mercury-protocol.gmi
> >
>
> Hey thanks!
> I totally miss this post about mercury.
>
> This is very interesting and address small network bandwidth / small computer ressources / frugal energy usage issue.
>
> Seems that the protocol specification should be separate from the text format protocol (true for gemini too).
>
> freD.

It will also permit surfing at the speed of ligth with instant display of clicked link... something that is no more existing in the old-school-too-much dynamic web.

freD.



From jmcbray at carcosa.net  Tue Jun 23 13:29:32 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 23 Jun 2020 08:29:32 -0400
Subject: Great web site to port to gemini
In-Reply-To: <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>
 (Matthew Graybosch's message of "Mon, 22 Jun 2020 22:06:53 -0400")
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
 <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
 <8-glswtVejVS7IfX2tIYjHWHGfDkxCQo-nIksch-3bJo2RpaFQJPAs_Cj3angduDw11NLloShZfxAhu62VW7m4NdCi-JTAMkFgl9BaxWK9Q=@protonmail.com>
 <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>
Message-ID: <877dvyq82b.fsf@dorothy.carcosa.net>

Matthew Graybosch <hello at matthewgraybosch.com> writes:

> Got a small proof-of-concept going on gemini://tanelorn.city/library/,
> but it's hand-curated. Doing a full mirror would take over 42GB just
> for the texts.

Hey, very cool. Are the subject categories hand-managed/static? Or do
you have a database backend of some kind?

I may try to curate a public domain Gemini library for Weird fiction,
starting with The King In Yellow...

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From jmcbray at carcosa.net  Tue Jun 23 13:41:45 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 23 Jun 2020 08:41:45 -0400
Subject: [ANN] Geminews: News feeds over gemini
In-Reply-To: <1359073644.788024.1592892849105@ichabod.co-bxl> (Brian Evans's
 message of "Tue, 23 Jun 2020 08:14:09 +0200 (CEST)")
References: <1359073644.788024.1592892849105@ichabod.co-bxl>
Message-ID: <87366mq7hy.fsf@dorothy.carcosa.net>

Brian Evans <b__m__e at mailfence.com> writes:

> If you would like to get some news over gemini head to:
>
> gemini://rawtext.club/~sloum/geminews/

Very nice! Are you scraping full-fat web pages and distilling them down,
or are you relying on (e.g.) text.npr.org for a simpler structure to
scrape? Or are you using rss feeds? Because I'd love to see the
Intercept added, and maybe the Grauniad.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From hannu.hartikainen+gemini at gmail.com  Tue Jun 23 14:58:35 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Tue, 23 Jun 2020 16:58:35 +0300
Subject: Great web site to port to gemini
In-Reply-To: <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
 <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
 <8-glswtVejVS7IfX2tIYjHWHGfDkxCQo-nIksch-3bJo2RpaFQJPAs_Cj3angduDw11NLloShZfxAhu62VW7m4NdCi-JTAMkFgl9BaxWK9Q=@protonmail.com>
 <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>
Message-ID: <CANmFPem96QEASPCVhH-2tJ=Y5aaO5DA=U-tUDz9RC1Xn57xxCQ@mail.gmail.com>

On Tue, 23 Jun 2020 at 05:06, Matthew Graybosch <hello at matthewgraybosch.com>
wrote:

> Got a small proof-of-concept going on gemini://tanelorn.city/library/,
> but it's hand-curated. Doing a full mirror would take over 42GB just
> for the texts.
>

IMHO that's a much better resource than a full mirror. These days the
problem is not finding content; it's finding content worthy of your time.
Of course I don't share tastes with most people, so it would be great to
have similar curated libraries from many diverse people. I've tried to find
something good to read on Project Gutenberg on multiple occasions and it's
a behemoth of a task.

So thanks for sharing, that's a great idea that I wish other people will
also consider! I started my own humble selection at gemini://
hannuhartikainen.fi/library/ .

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200623/6182f338/attachment.htm>

From b__m__e at mailfence.com  Tue Jun 23 15:43:49 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Tue, 23 Jun 2020 16:43:49 +0200 (CEST)
Subject: Mercury
Message-ID: <386712293.818255.1592923429148@ichabod.co-bxl>

> * is the concept still "alive"?  is the document still "open for
comments"?

I have been in discussions with solderpunk about this and there has
been debate whether to move forward. I have a server built and have
integrated mercury support into a branch of my client. However,
that support differs from the original posting of mercury as a concept
(it simplifies status codes, but there have been talks about removing
the status codes altogether). I was definitely using a different port than
the suggested 1963 (I think I used 1961, the year of the first crewed
flight). My implementation uses text/gemini but only recognizes link
lines and all other lines are treated as plain text rendered literally.

In any case I would consider waiting to implement until solderpunk is
back on the mailing list as I know he had thoughts about this (I believe
he was hoping to deliver a finished and complete spec and not really
hash out the concept much beyond that). Otherwise I think we run the
risk of fragmented implementation and drawn out discussions to patch
up that fragmentation whenr eally this should be a simple thing that all
can just build from an already established spec.

--?
Sent with https://mailfence.com
Secure and private email

From b__m__e at mailfence.com  Tue Jun 23 15:45:21 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Tue, 23 Jun 2020 16:45:21 +0200 (CEST)
Subject: [ANN] Geminews: News feeds over gemini
In-Reply-To: <87366mq7hy.fsf@dorothy.carcosa.net>
References: <1359073644.788024.1592892849105@ichabod.co-bxl>
 <87366mq7hy.fsf@dorothy.carcosa.net>
Message-ID: <1530622701.818373.1592923521886@ichabod.co-bxl>

> Very nice! Are you scraping full-fat web pages and distilling them down,
> or are you relying on (e.g.) text.npr.org for a simpler structure to
> scrape? Or are you using rss feeds? Because I'd love to see the
> Intercept added, and maybe the Grauniad.

I am using the stripped down text versions of each of those news providers.
I had actually not thought of RSS feeds. That could be a good way to go too.
I'll look into the publications you mentioned. :)

From cage-dev at twistfold.it  Tue Jun 23 16:00:39 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 23 Jun 2020 17:00:39 +0200
Subject: [ANN] tinmop, a pleroma client includes a gemini viewer
Message-ID: <20200623150039.GA20300@kurosawa.casa.net>

Hi!

Maybe someone could  be interested that i have added  a minimal gemini
viewer in my client for pleroma: tinmop

https://www.autistici.org/interzona/tinmop.html

Tinmop  is  a  distraction-free   terminal  based  client  for  pleroma
federated  social network.  Know  when a  gemini link  is  met in  the
message the program is able to  follow the link and visualize the page
in a (terminal) window.

>From that page is possible to follow gemini links and so on so this is
a minimal browser, dare to say! ;)

The  implementation of  the protocol  is not  complete, in  particular
missing are:


- all the client authentication mechanisms (code 6x)
- sensitive inputs (codes 11)

and the  implementation it is  a bit  crude (no bookmark,  no browsing
history...) but there will be time to improves it, i hope! :)

Many thanks to the folks on the gemini mailing list (especially people
behind the  client torture test!)  and folks from cl+ssl  library that
helped me to implement TOFU.

Enjoy, but expect many bugs! ;-)
C.

From jb55 at jb55.com  Tue Jun 23 17:04:17 2020
From: jb55 at jb55.com (William Casarin)
Date: Tue, 23 Jun 2020 09:04:17 -0700
Subject: Mercury
In-Reply-To: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
Message-ID: <87pn9pg45a.fsf@jb55.com>


Hey Phil,

Phil Leblanc <philanc at gmail.com> writes:
> Hi all,
>
> I have very recently discovered Gemini, so I am late at the party, but
> very excited by the Gemini concept and philosophy.
>
> At the same time, I am a bit disappointed by the mandatory use of TLS
> in the protocol. It seems _so_ at odds with the overall philosophy and
> simplicity of Gemini...  But I _do_ understand that there is momentum
> behind TLS usage.

same and agreed

> Looking for discussion about this TLS issue, I found in a message by
> Petite Abeille [1] a link to the Mercury document [2] by Solderpunk.
>
> I don't know when it was published and couldn't find a discussion
> about Mercury (i.e. Gemini without TLS)
>
> What I would like to know:
>
> * is the Mercury document an old document that has been already
> discussed and the concept discarded?  (any link to the discussion?)

If you search the geminiverse for mercury you'll see a few comments. I
found that there were mostly negative responses toward Mercury, but then
again it's a pretty small sample size.

> * is the concept still "alive"?  is the document still "open for comments"?

I don't see why there couldn't be another ecosystem around mercury. I
picture clients eventually supporting a suite of protocols, such as
gopher, mercury and gemini all at once.

> * are there Gemininauts interested in Mercury?

very much so, TLS is the only thing holding me back from publishing
content on Gemini. Mercury is something I was hoping more people would
pick up interest in.

> * are there clients and servers targeting both Gemini and Mercury?
> (i.e. the Gemini concept with and without TLS)

I haven't seen any but would love that idea!


Cheers,
Will

From felix at masterq32.de  Tue Jun 23 17:12:15 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 23 Jun 2020 18:12:15 +0200
Subject: Mercury
In-Reply-To: <87pn9pg45a.fsf@jb55.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com>
Message-ID: <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>


>> * are there Gemininauts interested in Mercury?
> 
> very much so, TLS is the only thing holding me back from publishing
> content on Gemini. Mercury is something I was hoping more people would
> pick up interest in.
Can you elaborate that further? Setting up a (stupid) gemini server is
not that much work, considering [0].

Using one of the many gemini servers available shouldn't be a hurdle either

Regards
- xq


[0] gemini://tomasino.org

From jb55 at jb55.com  Tue Jun 23 17:17:43 2020
From: jb55 at jb55.com (William Casarin)
Date: Tue, 23 Jun 2020 09:17:43 -0700
Subject: Mercury
In-Reply-To: <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
Message-ID: <87mu4tg3iw.fsf@jb55.com>

Felix Quei?ner <felix at masterq32.de> writes:
>>> * are there Gemininauts interested in Mercury?
>> 
>> very much so, TLS is the only thing holding me back from publishing
>> content on Gemini. Mercury is something I was hoping more people would
>> pick up interest in.
> Can you elaborate that further? Setting up a (stupid) gemini server is
> not that much work, considering [0].

setting it up is not the issue. I'm just not a fan of the extra
complexity and latency[1]. I would prefer to use a protocol that is as
snappy as gopher but with a nicer syntax that is more markdown-friendly.
Mercury seems to fit that bill quite nicely.

[1] https://bitcoinhackers.org/@jb55/104355504715040809

From hello at matthewgraybosch.com  Tue Jun 23 19:55:02 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Tue, 23 Jun 2020 14:55:02 -0400
Subject: Great web site to port to gemini
In-Reply-To: <87wo3xd6fo.fsf@dorothy.carcosa.net>
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
 <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
 <8-glswtVejVS7IfX2tIYjHWHGfDkxCQo-nIksch-3bJo2RpaFQJPAs_Cj3angduDw11NLloShZfxAhu62VW7m4NdCi-JTAMkFgl9BaxWK9Q=@protonmail.com>
 <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>
 <877dvyq82b.fsf@dorothy.carcosa.net>
 <20200623092609.1d91f3d3e53b568cc5c97db4@matthewgraybosch.com>
 <87wo3xd6fo.fsf@dorothy.carcosa.net>
Message-ID: <20200623145502.dfc3bdcee2e838a832ebf29d@matthewgraybosch.com>

On Tue, 23 Jun 2020 13:43:07 -0400
Jason McBrayer <jmcbray at carcosa.net> wrote:

> I wonder if a static site generator kind of thing would be the sweet
> spot for this. Just being able to tag a file with multiple tags and
> other metadata, and have appropriate index pages generated, without
> duplication of the bigger files.

If you take a moment to visit tanelorn.city/library/ you'll find that I
haven't been duplicating the texts. They all live in a texts/
directory, and then I link to them from multiple indexes as
appropriate. For example, Emma Goldman's _Anarchy and Other Essays_
appears in both "anarchism.gemini" and "feminism.gemini".

> Sounds like a good idea to me. Do you have a place you'd prefer to
> host such a repo?

I'm tempted to use SourceHut because I'm familiar with it, but it has
the potential to be a huge repository. While I'm a paying customer (but
only $5 a month) I don't want to put an unreasonable amount of strain
on the service. 

GitHub might be more convenient for potential contributors, but I'm not
sure I should entrust this to a Microsoft-controlled service.

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

From jmcbray at carcosa.net  Tue Jun 23 20:46:54 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 23 Jun 2020 15:46:54 -0400
Subject: Great web site to port to gemini
In-Reply-To: <20200623145502.dfc3bdcee2e838a832ebf29d@matthewgraybosch.com>
 (Matthew Graybosch's message of "Tue, 23 Jun 2020 14:55:02 -0400")
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
 <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
 <8-glswtVejVS7IfX2tIYjHWHGfDkxCQo-nIksch-3bJo2RpaFQJPAs_Cj3angduDw11NLloShZfxAhu62VW7m4NdCi-JTAMkFgl9BaxWK9Q=@protonmail.com>
 <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>
 <877dvyq82b.fsf@dorothy.carcosa.net>
 <20200623092609.1d91f3d3e53b568cc5c97db4@matthewgraybosch.com>
 <87wo3xd6fo.fsf@dorothy.carcosa.net>
 <20200623145502.dfc3bdcee2e838a832ebf29d@matthewgraybosch.com>
Message-ID: <87sgeld0pd.fsf@dorothy.carcosa.net>

Matthew Graybosch <hello at matthewgraybosch.com> writes:

> If you take a moment to visit tanelorn.city/library/ you'll find that
> I haven't been duplicating the texts. They all live in a texts/
> directory, and then I link to them from multiple indexes as
> appropriate. For example, Emma Goldman's _Anarchy and Other Essays_
> appears in both "anarchism.gemini" and "feminism.gemini".

Ah, looks good; that's what I was suggesting a static site generator do.
Does it get at all hairy maintaining it by hand?

> I'm tempted to use SourceHut because I'm familiar with it, but it has
> the potential to be a huge repository. While I'm a paying customer
> (but only $5 a month) I don't want to put an unreasonable amount of
> strain on the service.

I imagine it would be a pretty long time before it got to be a big repo,
if people were manually curating the books. People aren't going to be
editing the books very much, after all, only the index files (or scripts
and metadata used to generate the index files).

> GitHub might be more convenient for potential contributors, but I'm
> not sure I should entrust this to a Microsoft-controlled service.

Yeah, I only use GitHub as a mirror of my self-hosted Gitea. Which I'd
offer for this task, but it's on residential cable and couldn't take
lots of users.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray at carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

From hannu.hartikainen+gemini at gmail.com  Tue Jun 23 21:33:15 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Tue, 23 Jun 2020 23:33:15 +0300
Subject: Mercury
In-Reply-To: <87mu4tg3iw.fsf@jb55.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
Message-ID: <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>

On Tue, 23 Jun 2020 at 19:17, William Casarin <jb55 at jb55.com> wrote:

> setting it up is not the issue. I'm just not a fan of the extra
> complexity and latency[1]. I would prefer to use a protocol that is as
> snappy as gopher but with a nicer syntax that is more markdown-friendly.
> Mercury seems to fit that bill quite nicely.
>

The Gemini spec does not *require* TCP, so similar levels of snappiness
could be achieved with QUIC. It does the connection handshake
simultaneously with the TLS handshake, ending up with no more handshake
messages than the classical TCP SYN / SYN+ACK / ACK handshake.

You could get still snappier with a connectionless protocol. I just
captured a single page load of Gopherpedia using Wireshark. Guess how many
Ethernet frames? 11. These text based protocols are not optimized for speed
or simplicity (as in minimizing abstraction layers). We are all standing on
the shoulders of giants.

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200623/5aa92565/attachment.htm>

From jb55 at jb55.com  Tue Jun 23 22:25:52 2020
From: jb55 at jb55.com (William Casarin)
Date: Tue, 23 Jun 2020 14:25:52 -0700
Subject: Mercury
In-Reply-To: <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
Message-ID: <87imfhfp9b.fsf@jb55.com>

Hannu Hartikainen <hannu.hartikainen+gemini at gmail.com> writes:

> On Tue, 23 Jun 2020 at 19:17, William Casarin <jb55 at jb55.com> wrote:
>
>> setting it up is not the issue. I'm just not a fan of the extra
>> complexity and latency[1]. I would prefer to use a protocol that is as
>> snappy as gopher but with a nicer syntax that is more markdown-friendly.
>> Mercury seems to fit that bill quite nicely.
>>
>
> The Gemini spec does not *require* TCP, so similar levels of snappiness
> could be achieved with QUIC. It does the connection handshake
> simultaneously with the TLS handshake, ending up with no more handshake
> messages than the classical TCP SYN / SYN+ACK / ACK handshake.

Gemini over QUIC would be really cool, as TLS latency is my main gripe
right now.

From philanc at gmail.com  Tue Jun 23 22:29:00 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Tue, 23 Jun 2020 21:29:00 +0000
Subject: Mercury
In-Reply-To: <87imfhfp9b.fsf@jb55.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
Message-ID: <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>

First, thank you all for your answers.

@Felix Quei?ner

> Yeah, definitely. It sounds like the perfect match for embedded devices,
as it requires no encryption and no complex state machines.

I think also for hobbyists and education. As soon as "what is a
socket" has been explained, Mercury can be used as one of the first
examples of how it works.  Add TLS in the mix and suddenly it becomes
more difficult to grasp.

@defdefred

> Seems that the protocol specification should be separate from the text format protocol (true for gemini too).

Of course the request/response protocol and the text/gemini format are
distinct. But I think at the moment they are best together in the
"Gemini Spec" document.  It doesn't prevent anybody to serve
text/gemini pages over http... :-)

@William Casarin

> I don't see why there couldn't be another ecosystem around mercury. I
picture clients eventually supporting a suite of protocols, such as
gopher, mercury and gemini all at once.

In my mind, it wouldn't be a different ecosystem -- exactly like there
is only one "web ecosystem", with both http and https URLs.

As long as the spec specifies both the "with TLS" and "without TLS
bits", and as long as most client/server authors agree to support
both, there shouldn't be any ecosystem split -- again, same as what
happened with http and https

Phil

From acdw at acdw.net  Wed Jun 24 15:26:59 2020
From: acdw at acdw.net (Case Duckworth)
Date: Wed, 24 Jun 2020 09:26:59 -0500
Subject: Mercury
In-Reply-To: <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
Message-ID: <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>

I think Mercury is a bad idea, at least for now, when Gemini is still very young and not established (or just established). For one thing, TLS was the main reason solderpunk even began thinking about an alternative to gopher (see gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/why-gopher-needs-crypto.txt), and it's really the most important part of the protocol. Specifically the concerns over censorship, traffic modification, PGP key transmission, etc. I think removing TLS (or some kind of crypto) is a bad idea for that reason.

If you don't want to use TLS, use gopher. Gemini isn't trying to be everything for everyone -- it specifically mentions that it's *not* trying to supplant gopher or http, and it's trying to be a *new* protocol, built from the ground up with modern sensibilities. Mercury is a step backward in that regard.

As far as http, https (cf.

> As long as the spec specifies both the "with TLS" and "without TLS
> bits", and as long as most client/server authors agree to support
> both, there shouldn't be any ecosystem split -- again, same as what
> happened with http and https
> 
> Phil

) -- remember how much work was put into the public education part of looking to the little green lock at the address bar of browsers, and how long it took for most of the web (even now, not all of it's https) to switch to https? I'm not even really a developer and I remember seeing headline after headline, blogpost after blogpost, begging authors to switch to https -- and even now, it's a patchwork. 

I have to use an extension like HTTPS Everywhere to make sure that a web page doesn't load some assets in the clear while I'm on a secured page! While gemini doesn't have that *particular* issue, it'll still be confusing for people casually browsing to know when/if they're moving to an insecure channel from a secure one or vice-versa. 

Best,
Case (acdw)

From me at case.codes  Wed Jun 24 15:47:40 2020
From: me at case.codes (case)
Date: Wed, 24 Jun 2020 08:47:40 -0600
Subject: [ANN] deedum browser update
Message-ID: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>

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

From colecmac at protonmail.com  Wed Jun 24 15:59:59 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 24 Jun 2020 14:59:59 +0000
Subject: [ANN] deedum browser update
In-Reply-To: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
Message-ID: <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>

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


From hello at matthewgraybosch.com  Wed Jun 24 16:26:07 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 24 Jun 2020 11:26:07 -0400
Subject: [ANN] deedum browser update
In-Reply-To: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
Message-ID: <20200624112607.c5e2314bf5c28340ba7f8a34@matthewgraybosch.com>

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

From hello at matthewgraybosch.com  Wed Jun 24 16:36:32 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 24 Jun 2020 11:36:32 -0400
Subject: Mercury
In-Reply-To: <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
Message-ID: <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>

On Wed, 24 Jun 2020 09:26:59 -0500
"Case Duckworth" <acdw at acdw.net> wrote:

> remember how much work was put into the public education part of
> looking to the little green lock at the address bar of browsers, and
> how long it took for most of the web (even now, not all of it's
> https) to switch to https? I'm not even really a developer and I
> remember seeing headline after headline, blogpost after blogpost,
> begging authors to switch to https -- and even now, it's a patchwork. 

I remember, and I'd rather not repeat that bit of history.

I don't want to say that Mercury is a bad idea because I'm not really
qualified to make that judgment. However, I *will* say that I won't
support protocols that don't require encrypted connections, whether
over TLS, SSH, or something that replaces these 20 years from now.

I don't want to serve my own stuff in the clear, and if I'm
providing hosting to other people I don't want to serve their stuff
in the clear either. It's just not safe. 

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

From defdefred at protonmail.com  Wed Jun 24 17:14:46 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 24 Jun 2020 16:14:46 +0000
Subject: Mercury
In-Reply-To: <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
Message-ID: <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>

On Wednesday 24 June 2020 17:36, Matthew Graybosch <hello at matthewgraybosch.com> wrote:
> On Wed, 24 Jun 2020 09:26:59 -0500
> "Case Duckworth" acdw at acdw.net wrote:
> > remember how much work was put into the public education part of
> > looking to the little green lock at the address bar of browsers, and
> > how long it took for most of the web (even now, not all of it's
> > https) to switch to https? I'm not even really a developer and I
> > remember seeing headline after headline, blogpost after blogpost,
> > begging authors to switch to https -- and even now, it's a patchwork.
> I don't want to serve my own stuff in the clear, and if I'm
> providing hosting to other people I don't want to serve their stuff
> in the clear either. It's just not safe.

That the point about serving public data encrypted while every body can request it?
Example:
- public domain book
- weather (curl wttr.in/paris)
- public news
- governmental information
- cute kitten videos
- etc.

Optional PGP signature is enough to provide integrity.

Are you sure that TLS is safe?
States are allowing communication they can't decipher?

>From my point of view TLS is needed to manage personal data, but not for all the geminispace.

freD.

From felix at masterq32.de  Wed Jun 24 17:30:26 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 24 Jun 2020 18:30:26 +0200
Subject: Mercury
In-Reply-To: <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
Message-ID: <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>

Hey

> That the point about serving public data encrypted while every body can request it?
> Example:
> - public domain book
> - weather (curl wttr.in/paris)
> - public news
> - governmental information
> - cute kitten videos
> - etc.
Yes, as you can trust that you actually receive the data the server
wants you to see. If a MITM attack happens, they can serve you the wrong
news for example, wrong governmental information (deluding you to do
illegal acts)

> Optional PGP signature is enough to provide integrity.
It depends strongly on how you verify that PGP signature (same rules
apply to TLS though)


Regards
- xq

From acdw at acdw.net  Wed Jun 24 17:32:38 2020
From: acdw at acdw.net (Case Duckworth)
Date: Wed, 24 Jun 2020 11:32:38 -0500
Subject: Mercury
In-Reply-To: <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
Message-ID: <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>

On Wed, Jun 24, 2020, at 11:14 AM, defdefred wrote:
> That the point about serving public data encrypted while every body can 
> request it?
> Example:
> - public domain book
> - weather (curl wttr.in/paris)
> - public news
> - governmental information
> - cute kitten videos
> - etc.
> 
> Optional PGP signature is enough to provide integrity.

If transmissions are sent in the clear, anyone in the middle (ISP, malicious actor) can modify any data, including a PGP signature (meaning a malicious actor could change the PGP signature to their PGP signature, then impersonate the person). TLS encrypts the *transmission* between the two endpoints, which is the only way to guarantee the message hasn't been tampered with.

> 
> Are you sure that TLS is safe?
> States are allowing communication they can't decipher?

I have no idea about this, but I defer to the experts who've designed and implemented the system. Besides, if a *state* wants to take you down, I'm not sure if there's anything you can meaningfully do. TLS is more like a lock on the door than a bunker.

> 
> From my point of view TLS is needed to manage personal data, but not 
> for all the geminispace.

Do you think the same of the web? HTTPS is nearly universal, and I'd say that's a good thing -- Wikipedia (to me, the definition of public information) redirects http requests to https automatically.

- Case

From hello at matthewgraybosch.com  Wed Jun 24 17:42:34 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 24 Jun 2020 12:42:34 -0400
Subject: Mercury
In-Reply-To: <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
Message-ID: <20200624124234.060cfcbfca07ebbac9363269@matthewgraybosch.com>

On Wed, 24 Jun 2020 16:14:46 +0000
defdefred <defdefred at protonmail.com> wrote:

I don't know enough to claim that TLS is perfectly safe, let alone
enough. I just think it's better than nothing.

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

From gmym at coopdot.com  Wed Jun 24 17:53:10 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Wed, 24 Jun 2020 18:53:10 +0200
Subject: [ANN] deedum browser update
In-Reply-To: <20200624112607.c5e2314bf5c28340ba7f8a34@matthewgraybosch.com>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <20200624112607.c5e2314bf5c28340ba7f8a34@matthewgraybosch.com>
Message-ID: <CAObwWNgJtb_V2EFDq8EGRp1CNYDGEyVO=1zVdN64Y=3XY7kC7Q@mail.gmail.com>

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

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200624/fee60fb1/attachment.htm>

From me at case.codes  Wed Jun 24 19:22:12 2020
From: me at case.codes (Case Nelson)
Date: Wed, 24 Jun 2020 18:22:12 +0000 (UTC)
Subject: [ANN] deedum browser update
In-Reply-To: <CAObwWNgJtb_V2EFDq8EGRp1CNYDGEyVO=1zVdN64Y=3XY7kC7Q@mail.gmail.com>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <20200624112607.c5e2314bf5c28340ba7f8a34@matthewgraybosch.com>
 <CAObwWNgJtb_V2EFDq8EGRp1CNYDGEyVO=1zVdN64Y=3XY7kC7Q@mail.gmail.com>
Message-ID: <d5c7b261-8328-471d-aaf8-79848e94af23@case.codes>

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


From sean at conman.org  Wed Jun 24 21:25:59 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 24 Jun 2020 16:25:59 -0400
Subject: [ANN] deedum browser update
In-Reply-To: <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>
Message-ID: <20200624202559.GB19717@brevard.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


From defdefred at protonmail.com  Wed Jun 24 21:46:24 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 24 Jun 2020 20:46:24 +0000
Subject: Mercury
In-Reply-To: <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
Message-ID: <_LWn9L7z1K4oJQWA4IYmVOcHrSjh2CZreW5wIBgHkjXT0Qq4R3UGC5J4jQA4ujYeBzzp34Gy8_j318LhuKDg20D3C-WhtU-iE27hUdPuAuk=@protonmail.com>

On Wednesday 24 June 2020 18:30, Felix Quei?ner <felix at masterq32.de> wrote:
> > Optional PGP signature is enough to provide integrity.
> It depends strongly on how you verify that PGP signature (same rules
> apply to TLS though)

The fun fact is:
- with TLS, the whole server is using only one certficat and the integrity of publication rely only on this security and you don't know if it is a compromised server.
- with PGP signature, each writer using the server have his own certificat to secure his writing integrity.

freD.


From philanc at gmail.com  Wed Jun 24 21:47:44 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 24 Jun 2020 20:47:44 +0000
Subject: Mercury
In-Reply-To: <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
Message-ID: <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>

On Wed, Jun 24, 2020 at 2:27 PM Case Duckworth <acdw at acdw.net> wrote:
>
> I think Mercury is a bad idea, at least for now, when Gemini is still very young and not established (or just established). For one thing, TLS was the main reason solderpunk even began thinking about an alternative to gopher (see gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/why-gopher-needs-crypto.txt), and it's really the most important part of the protocol. Specifically the concerns over censorship, traffic modification, PGP key transmission, etc. I think removing TLS (or some kind of crypto) is a bad idea for that reason.

I will check the  Solderpunk's document. Thanks for the pointer.

Regarding Gemini vs. Gopher,  I do think that the very simple
request/response protocol and the great text/gemini document format
with links embedded in the text are together by far _the_  great step
forward, from Gopher to Gemini.

> If you don't want to use TLS, use gopher. Gemini isn't trying to be everything for everyone -- it specifically mentions that it's *not* trying to supplant gopher or http, and it's trying to be a *new* protocol, built from the ground up with modern sensibilities. Mercury is a step backward in that regard

I find it hard to follow you here. Do you imply that starting with
Mercury and adding TLS would be a step forward, in terms of _newness_?

>  remember how much work was put into the public education part of looking to the little green lock at the address bar of browsers, and how long it took for most of the web (even now, not all of it's https) to switch to https?

Definitely yes. And the same could be said about HTML and HTTP:
remember how much work has been put in education and development and
infrastructure to put in place the web as we know it!  -- Is it enough
of a reason not to try another way?

> Best,
> Case (acdw)

Thanks for your input.  I want to reiterate that with respect to
Gemini, my biggest gripe is _mandatory_ TLS, not TLS itself.

I feel a bit like a guy discovering a group of people trying to
establish an utopian community from the ground up, based on fresh and
frugal principles. After digging a bit, I found that they mandate the
use of Toyota SUV for transportation in all the villages (because they
are available everywhere in the world and are efficient for
transportation).

Maybe villages without Toyota SUVs could also be part of the utopian
community? :-)

Cheers,

Phil

From defdefred at protonmail.com  Wed Jun 24 21:50:37 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 24 Jun 2020 20:50:37 +0000
Subject: Mercury
In-Reply-To: <20200624124234.060cfcbfca07ebbac9363269@matthewgraybosch.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <20200624124234.060cfcbfca07ebbac9363269@matthewgraybosch.com>
Message-ID: <jK7eWvvEFd_OjHPXlG5-Vp58j9UT8OP6FLQWmtvzm-vQtsAzud2N4VfwLj_O8-5Rrgbsm-fX5XuyR7jhTedHWVa8QHFzVztRlm1y9n_AYZI=@protonmail.com>

On Wednesday 24 June 2020 18:42, Matthew Graybosch <hello at matthewgraybosch.com> wrote:
> I don't know enough to claim that TLS is perfectly safe, let alone
> enough. I just think it's better than nothing.

True. Security software are using end-to-end encryption + TLS transport.

Having TLS is better, but it come with a latency cost with the one connection per request behavior.
Freedom is also having the choice.

freD.

From defdefred at protonmail.com  Wed Jun 24 21:55:52 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 24 Jun 2020 20:55:52 +0000
Subject: Mercury
In-Reply-To: <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
Message-ID: <eiPJAFSgaBrvIDNGQI2ySun760UimVkEgDWEhYyXv1IpmoozgIMJlXrG8y_mAZfEw8gGeZaXnPTLU95QK117EWVDO2aT-sCCeVnALC6R070=@protonmail.com>

On Wednesday 24 June 2020 22:47, Phil Leblanc <philanc at gmail.com> wrote:
> Maybe villages without Toyota SUVs could also be part of the utopian
> community? :-)

Exactly!

freD.


From defdefred at protonmail.com  Wed Jun 24 22:29:37 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 24 Jun 2020 21:29:37 +0000
Subject: Mercury
In-Reply-To: <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>
Message-ID: <2p3ofLX2Mq0w2ljJObLLX9bmIbmFVgBn1twvxC5jlnEoze2uAmxlKFKskxbuk2V7F8dTY3f2xj0DpnKUjdkpM5VlJEBgOcGLgw6GJPiIBlY=@protonmail.com>

On Wednesday 24 June 2020 18:32, Case Duckworth <acdw at acdw.net> wrote:
> If transmissions are sent in the clear, anyone in the middle (ISP, malicious actor) can modify any data, including a PGP signature (meaning a malicious actor could change the PGP signature to their PGP signature, then impersonate the person). TLS encrypts thetransmission between the two endpoints, which is the only way to guarantee the message hasn't been tampered with.

When you are reading pgp signed document from a server where you own a defined set of public pgp keys, you don't fear MITM attack (the same way TLS is secure only with a PKI).

The difference is that external PGP signature are all computed only at document publication time and not on the fly for each user request.

freD.

From sean at conman.org  Wed Jun 24 23:03:51 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 24 Jun 2020 18:03:51 -0400
Subject: Mercury
In-Reply-To: <2p3ofLX2Mq0w2ljJObLLX9bmIbmFVgBn1twvxC5jlnEoze2uAmxlKFKskxbuk2V7F8dTY3f2xj0DpnKUjdkpM5VlJEBgOcGLgw6GJPiIBlY=@protonmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>
 <2p3ofLX2Mq0w2ljJObLLX9bmIbmFVgBn1twvxC5jlnEoze2uAmxlKFKskxbuk2V7F8dTY3f2xj0DpnKUjdkpM5VlJEBgOcGLgw6GJPiIBlY=@protonmail.com>
Message-ID: <20200624220351.GD19717@brevard.conman.org>

It was thus said that the Great defdefred once stated:
> On Wednesday 24 June 2020 18:32, Case Duckworth <acdw at acdw.net> wrote:
> > If transmissions are sent in the clear, anyone in the middle (ISP,
> > malicious actor) can modify any data, including a PGP signature (meaning
> > a malicious actor could change the PGP signature to their PGP signature,
> > then impersonate the person). TLS encrypts thetransmission between the
> > two endpoints, which is the only way to guarantee the message hasn't
> > been tampered with.
> 
> When you are reading pgp signed document from a server where you own a
> defined set of public pgp keys, you don't fear MITM attack (the same way
> TLS is secure only with a PKI).
> 
> The difference is that external PGP signature are all computed only at
> document publication time and not on the fly for each user request.

  How do you safely get my public key?

  -spc


From pellertson at firemail.cc  Wed Jun 24 23:15:14 2020
From: pellertson at firemail.cc (Parker)
Date: Wed, 24 Jun 2020 15:15:14 -0700
Subject: Atom Feeds?
Message-ID: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>

Just curious as to how those of you with gemlogs are making your atom feeds?

~ Parker
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From me at case.codes  Wed Jun 24 23:21:12 2020
From: me at case.codes (Case Nelson)
Date: Wed, 24 Jun 2020 22:21:12 +0000 (UTC)
Subject: Working around implementation quirks
In-Reply-To: <20200624202559.GB19717@brevard.conman.org>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>
 <20200624202559.GB19717@brevard.conman.org>
Message-ID: <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>

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
> 

From colecmac at protonmail.com  Wed Jun 24 23:45:42 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 24 Jun 2020 22:45:42 +0000
Subject: Atom Feeds?
In-Reply-To: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
References: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
Message-ID: <JhPTmoVgcAzyYWbJyvs-thqZOHouVnN9QskffwF2tbhgQ0nZY1gYwzTK3bAsBuQ_KYeJ5WcVFOQnVK6ah5mk4dqLlJAZbIlbmy1WagkEu1k=@protonmail.com>

Good question!

The majority of people are probably using Solderpunk's gemfeed, which
can be installed with pip.

https://tildegit.org/solderpunk/gemfeed

It works well with CAPCOM, which is the main use of it that I've seen.

A minority of people might also be writing the feeds by hand, or using
some custom script.

makeworld

??????? Original Message ???????
On Wednesday, June 24, 2020 6:15 PM, Parker <pellertson at firemail.cc> wrote:

> Just curious as to how those of you with gemlogs are making your atom feeds?
>
> ~ Parker
>
> ---------------------------------------------------------------------------------------
>
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



From colecmac at protonmail.com  Wed Jun 24 23:47:58 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 24 Jun 2020 22:47:58 +0000
Subject: Working around implementation quirks
In-Reply-To: <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>
 <20200624202559.GB19717@brevard.conman.org>
 <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>
Message-ID: <XlMIlkdcMLGKInfUY5E9nCoODS7xQihylV6TkmPXAZiPxoLmSc7r23DyIhi7tRaDjq2ZJ4sDaIzcKWhxYdBNEcDZHdjKZyZLbSSUC6d8sCs=@protonmail.com>

> a no_write shutdown signal

Can you clarify more what this is? And more about the difference
between your two examples?

makeworld


From me at case.codes  Thu Jun 25 00:13:59 2020
From: me at case.codes (Case Nelson)
Date: Wed, 24 Jun 2020 23:13:59 +0000 (UTC)
Subject: Working around implementation quirks
In-Reply-To: <XlMIlkdcMLGKInfUY5E9nCoODS7xQihylV6TkmPXAZiPxoLmSc7r23DyIhi7tRaDjq2ZJ4sDaIzcKWhxYdBNEcDZHdjKZyZLbSSUC6d8sCs=@protonmail.com>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>
 <20200624202559.GB19717@brevard.conman.org>
 <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>
 <XlMIlkdcMLGKInfUY5E9nCoODS7xQihylV6TkmPXAZiPxoLmSc7r23DyIhi7tRaDjq2ZJ4sDaIzcKWhxYdBNEcDZHdjKZyZLbSSUC6d8sCs=@protonmail.com>
Message-ID: <aca128de-e797-478b-ac7f-f9c9cb8d4090@case.codes>

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/374f6699be936d551cf57a5f2a147eb7ff2193a7/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
> 

From petite.abeille at gmail.com  Thu Jun 25 00:41:06 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 25 Jun 2020 01:41:06 +0200
Subject: Mercury
In-Reply-To: <20200624220351.GD19717@brevard.conman.org>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>
 <2p3ofLX2Mq0w2ljJObLLX9bmIbmFVgBn1twvxC5jlnEoze2uAmxlKFKskxbuk2V7F8dTY3f2xj0DpnKUjdkpM5VlJEBgOcGLgw6GJPiIBlY=@protonmail.com>
 <20200624220351.GD19717@brevard.conman.org>
Message-ID: <EDD78C34-15B2-4125-9F72-22636D20E03F@gmail.com>



> On Jun 25, 2020, at 00:03, Sean Conner <sean at conman.org> wrote:
> 
>> The difference is that external PGP signature are all computed only at
>> document publication time and not on the fly for each user request.
> 
>  How do you safely get my public key?

Once that's [securely] sorted, they can also be complementary, as a text/gemini could have an existence outside of gemini itself.

# saltpack --detach sign <<< text/gemini
BEGIN SALTPACK DETACHED SIGNATURE. kYM5h1pg6qz9UMn j6G7KBABYjYydzb Pklk5155D39lht1 PIb7SbVzthKfu8l 4bRIlCMIYVYUD0g 5YG4eznmm7OwrqH xNzsAdLzTtW9vh6 aHO1UvNpWsRfjBW dWIg2IxMDW4MPp0 2JIVEgqGlv2EyDQ mQwd3Cyz5CEGTfI S05Wy9A56Wpi67d Y0CQ57mD2U2rcS6 qKSCZIu. END SALTPACK DETACHED SIGNATURE.

From mbrubeck at limpet.net  Thu Jun 25 01:36:24 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Wed, 24 Jun 2020 17:36:24 -0700
Subject: TLS 1.3 Early Data (0RTT)
Message-ID: <CAD1=23mqPuDQvMQVZTG5vhhxLGEro-GKMbgHHcreiB81mBayMA@mail.gmail.com>

One of the acknowledged disadvantages of TLS for Gemini is latency.
TLS 1.3 has a feature that could mitigate this problem in some
circumstances.  To quote RFC 8470:

> TLS 1.3 [TLS13] introduces the concept of early data (also known as
> zero round-trip time (0-RTT) data).  If the client has spoken to the
> same server recently, early data allows a client to send data to a
> server in the first round trip of a connection, without waiting for
> the TLS handshake to complete.
>
> When used with HTTP [HTTP], early data allows clients to send
> requests immediately, thus avoiding the one or two round-trip delays
> needed for the TLS handshake.  This is a significant performance
> enhancement; however, it has significant limitations.
>
> The primary risk of using early data is that an attacker might
> capture and replay the request(s) it contains.

Has anyone implemented a Gemini client and/or server with support for
0-RTT data? Any thoughts on which requests can safely use it?  (For
example, would it be reasonable to allow early data for all requests
that don't use a client certificate?)

From tomasino at lavabit.com  Thu Jun 25 02:20:24 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 25 Jun 2020 01:20:24 +0000
Subject: SPOOFED: Working around implementation quirks
In-Reply-To: <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>
 <20200624202559.GB19717@brevard.conman.org>
 <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>
Message-ID: <94e2cab7-d890-eeab-639f-ac2a01fba79c@lavabit.com>

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


From coleman at envs.net  Thu Jun 25 05:11:06 2020
From: coleman at envs.net (coleman)
Date: Thu, 25 Jun 2020 04:11:06 +0000
Subject: Working around implementation quirks
In-Reply-To: <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <ik3Pdh2wb6NwXz0aPJ7rZm_lEZoP9h3SObkpyw-yq-Z04ChQjc88Q8ZX8aqVuJZyvwj7hwk2CcDa5GHEIics2VMQ6yeiC5hsc3NGRyIbRJM=@protonmail.com>
 <20200624202559.GB19717@brevard.conman.org>
 <518d3b0c-4a13-42fa-827a-f462b4a40970@case.codes>
Message-ID: <20200625041106.fc6egwanuqhqkn3d@core.envs.net>

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

From defdefred at protonmail.com  Thu Jun 25 11:18:48 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 10:18:48 +0000
Subject: Mercury
In-Reply-To: <EDD78C34-15B2-4125-9F72-22636D20E03F@gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>
 <2p3ofLX2Mq0w2ljJObLLX9bmIbmFVgBn1twvxC5jlnEoze2uAmxlKFKskxbuk2V7F8dTY3f2xj0DpnKUjdkpM5VlJEBgOcGLgw6GJPiIBlY=@protonmail.com>
 <20200624220351.GD19717@brevard.conman.org>
 <EDD78C34-15B2-4125-9F72-22636D20E03F@gmail.com>
Message-ID: <nhj9-RD6F4GQ8-G-nAWlRnk0HDXneTE0vJ3VVBRJJTjDo9WqRDcqEvrz3OAAg6L4Rfg3ZAzI2vqqaAsKG8Vc3JKgSWsQdejFFkVa1kbkFL4=@protonmail.com>

With Mercury, we surf at the speed of light!
https://www.youtube.com/watch?v=NAMuiAYCRac

Sorry...

From vidak at riseup.net  Thu Jun 25 11:49:08 2020
From: vidak at riseup.net (Blair Vidakovich)
Date: Thu, 25 Jun 2020 18:49:08 +0800
Subject: [ANN] Tiny ad-hoc server
References: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>
 <mailman.705.1592587708.530.gemini@lists.orbitalfox.eu>
Message-ID: <87d05n774r.fsf@riseup.net>

wow... that is awesome, i can't believe it is done in so few lines of
code!

vidak

-eof

From julien at sideburns.eu  Thu Jun 25 11:49:09 2020
From: julien at sideburns.eu (julienXX)
Date: Thu, 25 Jun 2020 12:49:09 +0200
Subject: Mercury
In-Reply-To: <mailman.814.1593031850.530.gemini@lists.orbitalfox.eu>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <20200624124234.060cfcbfca07ebbac9363269@matthewgraybosch.com>
 <jK7eWvvEFd_OjHPXlG5-Vp58j9UT8OP6FLQWmtvzm-vQtsAzud2N4VfwLj_O8-5Rrgbsm-fX5XuyR7jhTedHWVa8QHFzVztRlm1y9n_AYZI=@protonmail.com>
 <mailman.814.1593031850.530.gemini@lists.orbitalfox.eu>
Message-ID: <rd1vf5$7j9$1@lc.orbitalfox.eu>

On 24/06/2020 22:50, defdefred wrote
> Having TLS is better, but it come with a latency cost with the one connection per request behavior.
> Freedom is also having the choice.
> 

What's wrong with gopher, http 0.9 or 1.0 if you don't want encryption?


From defdefred at protonmail.com  Thu Jun 25 12:34:05 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 11:34:05 +0000
Subject: [ANN] Tiny ad-hoc server
In-Reply-To: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>
References: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>
Message-ID: <1DXsRDdaU_9fYcgkeozAbwq4h0TlL-HVZ4LX-g3OELw0Oxp4CcYf09nZ-3212g6M-DQrVb_dnwAXe_H2eyqJY0euPUBE17teb0QA4NuCZ0I=@protonmail.com>

Hello!

I don't understand how the infinite while works in this case...
Is it consuming cpu all the time?

I play once with ncat and the program was rather in two parts:

1: the-worker
#!/bin/sh
printf "20 text/gemini; charset=utf-8\r\n"
printf "Page generated: %s\n\n" "$(date)"
cat file-to-serve

2: the-listener
#!/bin/sh

port="1965"
cert="cert.pem"
key="key.pem"

printf "Starting gemini server on port %s...\n" "$port"
ncat --ssl --ssl-cert "$cert" --ssl-key "$key" --listen "$port" -k -c ./the-worker

freD.


??????? Original Message ???????
On Friday 19 June 2020 19:28, James Tomasino <tomasino at lavabit.com> wrote:

&gt; I put up a tiny experiment of an ad-hoc server over on gemini://tomasino.org. The code for the server is on that gemini page for you to inspect and play with. Credit to xq for the concept. It's trivial to implement and may open the door for some folks who don't have a plan of running a big server. It may even be able to work with solderpunk's micro-instance ideas. I'm not sure if there's a way to validate client certs by building on to it, but that would make for easy micro-services.
&gt;
&gt; -   tomasino

</tomasino at lavabit.com>

From defdefred at protonmail.com  Thu Jun 25 12:39:56 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 11:39:56 +0000
Subject: Mercury
In-Reply-To: <rd1vf5$7j9$1@lc.orbitalfox.eu>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <20200624124234.060cfcbfca07ebbac9363269@matthewgraybosch.com>
 <jK7eWvvEFd_OjHPXlG5-Vp58j9UT8OP6FLQWmtvzm-vQtsAzud2N4VfwLj_O8-5Rrgbsm-fX5XuyR7jhTedHWVa8QHFzVztRlm1y9n_AYZI=@protonmail.com>
 <mailman.814.1593031850.530.gemini@lists.orbitalfox.eu>
 <rd1vf5$7j9$1@lc.orbitalfox.eu>
Message-ID: <Nc6Vz5NmnecLIo-EB-sAddQnPCJI8SnknBDyae0xYeAdh-u5XyOvmPU6KrocaDKcTEWPGf5w1DzFEFe7yh0w9Hkdry8jK26N7D51WV43ZTE=@protonmail.com>

On Thursday 25 June 2020 12:49, julienXX <julien at sideburns.eu> wrote:
> What's wrong with gopher, http 0.9 or 1.0 if you don't want encryption?

About Gopher:
cut historical constraints
to have a fresh and modern start

About http:
We need a protocol madness proof

freD.

From tomasino at lavabit.com  Thu Jun 25 13:09:25 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 25 Jun 2020 12:09:25 +0000
Subject: SPOOFED: Re: [ANN] Tiny ad-hoc server
In-Reply-To: <1DXsRDdaU_9fYcgkeozAbwq4h0TlL-HVZ4LX-g3OELw0Oxp4CcYf09nZ-3212g6M-DQrVb_dnwAXe_H2eyqJY0euPUBE17teb0QA4NuCZ0I=@protonmail.com>
References: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>
 <1DXsRDdaU_9fYcgkeozAbwq4h0TlL-HVZ4LX-g3OELw0Oxp4CcYf09nZ-3212g6M-DQrVb_dnwAXe_H2eyqJY0euPUBE17teb0QA4NuCZ0I=@protonmail.com>
Message-ID: <fea1aa24-cb56-ab61-69ff-b7ef353421aa@lavabit.com>

On 6/25/20 11:34 AM, defdefred wrote:
> I don't understand how the infinite while works in this case...
> Is it consuming cpu all the time?

ncat waits only for a single connection, then terminates. I tried using the switch to keep the connection alive and reuse it, but that means the connection is never closed on any single request and most clients display nothing. By wrapping it in an infinite while I just tell ncat to start a new listener when the previous one is used. There's only ever one running at a time, and it's a single thread, but traffic is low and it seems to work just fine.


From luke at marmaladefoo.com  Thu Jun 25 13:21:14 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 25 Jun 2020 13:21:14 +0100
Subject: SVG Bob
Message-ID: <5EF496BA.1010009@marmaladefoo.com>

Hi everyone

Maybe you all know about this already, but I just discovered SVG Bob

https://ivanceras.github.io/svgbob-editor/

I'm imagining it could be possible to integrate this into a Gemini 
client some day, to provide *alternative* renderings of ASCII art in 
Gemini alongside the source. I threw some random ASCII Art at it and it 
did a good job generally.

Best Wishes

  - Luke

From defdefred at protonmail.com  Thu Jun 25 13:30:27 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 12:30:27 +0000
Subject: SPOOFED: Re: [ANN] Tiny ad-hoc server
In-Reply-To: <fea1aa24-cb56-ab61-69ff-b7ef353421aa@lavabit.com>
References: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>
 <1DXsRDdaU_9fYcgkeozAbwq4h0TlL-HVZ4LX-g3OELw0Oxp4CcYf09nZ-3212g6M-DQrVb_dnwAXe_H2eyqJY0euPUBE17teb0QA4NuCZ0I=@protonmail.com>
 <fea1aa24-cb56-ab61-69ff-b7ef353421aa@lavabit.com>
Message-ID: <stSWi7Ym4kO8LsHPDBzzfrqmadZHHhZZaZRmLmaZlXiRMUHKu_FhUN06JDZ16YyV2sFBsx9sJfEBNDif2zNGt6leN8gPiyqxrsTX4CS3ybk=@protonmail.com>

Ok I'm dumb... don't saw the braces :-)

Bash process substitution will do too

#!/bin/sh

port="1965"
cert="cert.pem"
key="key.pem"

printf "Starting gemini server on port %s...\n" "$port"
while true; do
    ncat --ssl --ssl-cert "$cert" --ssl-key "$key" --listen "$port" <( \
    printf "20 text/gemini; charset=utf-8\r\n" ; \
    printf "Page generated: %s\n\n" "$(date)" ; \
    cat "$1" )
done

freD.

??????? Original Message ???????
On Thursday 25 June 2020 14:09, James Tomasino <tomasino at lavabit.com> wrote:

> On 6/25/20 11:34 AM, defdefred wrote:
>
> > I don't understand how the infinite while works in this case...
> > Is it consuming cpu all the time?
>
> ncat waits only for a single connection, then terminates. I tried using the switch to keep the connection alive and reuse it, but that means the connection is never closed on any single request and most clients display nothing. By wrapping it in an infinite while I just tell ncat to start a new listener when the previous one is used. There's only ever one running at a time, and it's a single thread, but traffic is low and it seems to work just fine.



From vidak at riseup.net  Thu Jun 25 11:49:08 2020
From: vidak at riseup.net (Blair Vidakovich)
Date: Thu, 25 Jun 2020 18:49:08 +0800
Subject: [ANN] Tiny ad-hoc server
References: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>
 <mailman.705.1592587708.530.gemini@lists.orbitalfox.eu>
Message-ID: <87d05n774r.fsf@riseup.net>

wow... that is awesome, i can't believe it is done in so few lines of
code!

vidak

-eof

From julien at sideburns.eu  Thu Jun 25 11:49:09 2020
From: julien at sideburns.eu (julienXX)
Date: Thu, 25 Jun 2020 12:49:09 +0200
Subject: Mercury
In-Reply-To: <mailman.814.1593031850.530.gemini@lists.orbitalfox.eu>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <20200624124234.060cfcbfca07ebbac9363269@matthewgraybosch.com>
 <jK7eWvvEFd_OjHPXlG5-Vp58j9UT8OP6FLQWmtvzm-vQtsAzud2N4VfwLj_O8-5Rrgbsm-fX5XuyR7jhTedHWVa8QHFzVztRlm1y9n_AYZI=@protonmail.com>
 <mailman.814.1593031850.530.gemini@lists.orbitalfox.eu>
Message-ID: <rd1vf5$7j9$1@lc.orbitalfox.eu>

On 24/06/2020 22:50, defdefred wrote
> Having TLS is better, but it come with a latency cost with the one connection per request behavior.
> Freedom is also having the choice.
> 

What's wrong with gopher, http 0.9 or 1.0 if you don't want encryption?


From hello at matthewgraybosch.com  Thu Jun 25 14:15:21 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 25 Jun 2020 09:15:21 -0400
Subject: Atom Feeds?
In-Reply-To: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
References: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
Message-ID: <20200625091521.1cc391f802708b9c4366f7bd@matthewgraybosch.com>

On Wed, 24 Jun 2020 15:15:14 -0700
Parker <pellertson at firemail.cc> wrote:

> Just curious as to how those of you with gemlogs are making your atom
> feeds?

I have feeds, but I've been doing them manually.

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

From tomasino at lavabit.com  Thu Jun 25 14:16:11 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 25 Jun 2020 13:16:11 +0000
Subject: Atom Feeds?
In-Reply-To: <20200625091521.1cc391f802708b9c4366f7bd@matthewgraybosch.com>
References: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
 <20200625091521.1cc391f802708b9c4366f7bd@matthewgraybosch.com>
Message-ID: <b2768f3d-ddfe-f500-098e-be4d90f3714c@lavabit.com>

On 6/25/20 1:15 PM, Matthew Graybosch wrote:
>> Just curious as to how those of you with gemlogs are making your atom
>> feeds?
> I have feeds, but I've been doing them manually.

I just added one on ~fox the other day. It's done by hand.


From plugd at thelambdalab.xyz  Thu Jun 25 15:36:16 2020
From: plugd at thelambdalab.xyz (plugd)
Date: Thu, 25 Jun 2020 16:36:16 +0200
Subject: Atom Feeds?
In-Reply-To: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
References: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
Message-ID: <lzbll7dxgf.fsf@bs-mbpr348.d.ethz.ch>

Parker writes:
> Just curious as to how those of you with gemlogs are making your atom feeds?

My server supports extension scripts in Scheme, and the atom feed
generator is one of those.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200625/8ba9c813/attachment.sig>

From philanc at gmail.com  Thu Jun 25 16:33:47 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Thu, 25 Jun 2020 15:33:47 +0000
Subject: Mercury
In-Reply-To: <rd1vf5$7j9$1@lc.orbitalfox.eu>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <20200624124234.060cfcbfca07ebbac9363269@matthewgraybosch.com>
 <jK7eWvvEFd_OjHPXlG5-Vp58j9UT8OP6FLQWmtvzm-vQtsAzud2N4VfwLj_O8-5Rrgbsm-fX5XuyR7jhTedHWVa8QHFzVztRlm1y9n_AYZI=@protonmail.com>
 <mailman.814.1593031850.530.gemini@lists.orbitalfox.eu>
 <rd1vf5$7j9$1@lc.orbitalfox.eu>
Message-ID: <CAOH6EB9yzyJSmmrsUuUdJ5v0G8QvkB69m3RJ7gX4-fCQzNe7EQ@mail.gmail.com>

On Thu, Jun 25, 2020 at 10:50 AM julienXX <julien at sideburns.eu> wrote:
>
> What's wrong with gopher, http 0.9 or 1.0 if you don't want encryption?
>

I guess one could also ask "What's wrong with https if you want
encryption?"  -- and the answer could be the same :-)

The best real answer has been provided by Solderpunk:here:
gemini://gemini.circumlunar.space/~solderpunk/cornedbeef/why-not-just-use-a-subset-of-http-and-html.gmi

It applies as well to Gemini with or without TLS.

Phil

From solderpunk at SDF.ORG  Thu Jun 25 16:49:20 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 25 Jun 2020 15:49:20 +0000
Subject: TLS 1.3 Early Data (0RTT)
In-Reply-To: <CAD1=23mqPuDQvMQVZTG5vhhxLGEro-GKMbgHHcreiB81mBayMA@mail.gmail.com>
References: <CAD1=23mqPuDQvMQVZTG5vhhxLGEro-GKMbgHHcreiB81mBayMA@mail.gmail.com>
Message-ID: <20200625154920.GD16671@SDF.ORG>

On Wed, Jun 24, 2020 at 05:36:24PM -0700, Matt Brubeck wrote:
 
> Has anyone implemented a Gemini client and/or server with support for
> 0-RTT data?

To the best of my knowledge, no.  I don't think anybody has written
anything supporting session resumption, either.

It's very true that the combination of TLS and
one-request-per-connection is a bad combination for latency (although,
for what it's worth, I still think the user experience is pretty
acceptable even now, and much better than the web).  As for "how bad"
this is, and whether or not it's a good motivation (as alluded to in
other threads) for dropping TLS, it should be noted that, today, we are
surely seeing almost the worst possible cases for this.  Nobody is using
stuff like 0-RTT data, nobody is using session resumption, and most
people are using Let's Encrypt certificate chains which are three certs
long, and each one uses big RSA keys.  We can and should try to do
better in this regard.

> Any thoughts on which requests can safely use it?  (For
> example, would it be reasonable to allow early data for all requests
> that don't use a client certificate?)

In combination with the idea I've proposed previously that any request
with non-reversible non-trivial consequences should require a client
certificate, that would seem, at first glance, a pretty sensible
response to the threat of replay attacks.

Regarding TLS session resumption, there is the issue to consider of
so-called "prolongation attacks":

https://svs.informatik.uni-hamburg.de/publications/2018/2018-12-06-Sy-ACSAC-Tracking_Users_across_the_Web_via_TLS_Session_Resumption.pdf

whereby TLS session information which roundtrips from the server to
client and back can be used (as can *any* information which roundtrips
in this way) for tracking.  This could be mitigated easily with
client-side policies on maximum session duration, but would be something
for implementers to be wary of.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Thu Jun 25 16:55:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 25 Jun 2020 15:55:19 +0000
Subject: Atom Feeds?
In-Reply-To: <JhPTmoVgcAzyYWbJyvs-thqZOHouVnN9QskffwF2tbhgQ0nZY1gYwzTK3bAsBuQ_KYeJ5WcVFOQnVK6ah5mk4dqLlJAZbIlbmy1WagkEu1k=@protonmail.com>
References: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
 <JhPTmoVgcAzyYWbJyvs-thqZOHouVnN9QskffwF2tbhgQ0nZY1gYwzTK3bAsBuQ_KYeJ5WcVFOQnVK6ah5mk4dqLlJAZbIlbmy1WagkEu1k=@protonmail.com>
Message-ID: <20200625155519.GE16671@SDF.ORG>

On Wed, Jun 24, 2020 at 10:45:42PM +0000, colecmac at protonmail.com wrote:
 
> The majority of people are probably using Solderpunk's gemfeed, which
> can be installed with pip.
> 

Probably - we could certainly do with more variety around this topic.
An early gemlog post suggested that static site generators don't have
much place in Gemini:

gemini://gemini.circumlunar.space/users/fgaz/posts/2020-05-08-staticgens/

I actually don't agree with this - there's plenty of interesting and
useful stuff that static site engines could automate the production of,
and Atom feeds (including fine-rained feeds for, e.g., different
categories of posts) is a great example.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 25 16:58:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 25 Jun 2020 15:58:19 +0000
Subject: [ANN] deedum browser update
In-Reply-To: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
Message-ID: <20200625155819.GF16671@SDF.ORG>

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

From solderpunk at SDF.ORG  Thu Jun 25 17:04:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 25 Jun 2020 16:04:44 +0000
Subject: Mercury
In-Reply-To: <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
Message-ID: <20200625160444.GG16671@SDF.ORG>

On Wed, Jun 24, 2020 at 08:47:44PM +0000, Phil Leblanc wrote:
 
> I feel a bit like a guy discovering a group of people trying to
> establish an utopian community from the ground up, based on fresh and
> frugal principles. After digging a bit, I found that they mandate the
> use of Toyota SUV for transportation in all the villages (because they
> are available everywhere in the world and are efficient for
> transportation).

As a non-car-owner and keen cyclist, this hurts! :)

I will reply to this whole Mercury thread tomorrow (probably relatively
briefly), but a quick request for disambiguation, regarding the SUV
analogy: is the objection here mostly on the grounds of prefering
minimalism, simplicity, easier DIYability?  Or is there actually an
explicit environmental component here, regarding the energy overhead of
encryption?

Cheers,
Solderpunk

From defdefred at protonmail.com  Thu Jun 25 18:11:24 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 17:11:24 +0000
Subject: Atom Feeds?
In-Reply-To: <20200625155519.GE16671@SDF.ORG>
References: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
 <JhPTmoVgcAzyYWbJyvs-thqZOHouVnN9QskffwF2tbhgQ0nZY1gYwzTK3bAsBuQ_KYeJ5WcVFOQnVK6ah5mk4dqLlJAZbIlbmy1WagkEu1k=@protonmail.com>
 <20200625155519.GE16671@SDF.ORG>
Message-ID: <Og0LicCSoXY6aECt6YUMyk8Na0eNLuqizHzCIDDnDsRSpqWH62FE7AIk_fJ6pN54LUMyN-tJTAGG4Oe3JwUbp15c3CV-bSVYMFCeBWuea5U=@protonmail.com>

On Thursday 25 June 2020 17:55, solderpunk <solderpunk at SDF.ORG> wrote:
> I actually don't agree with this - there's plenty of interesting and
> useful stuff that static site engines could automate the production of,
> and Atom feeds (including fine-rained feeds for, e.g., different
> categories of posts) is a great example.

- tag classification
- production of external pgp signature per document
- creation of synthetic report for GUS to avoid redundant network download

I like the work one, serve many of static sites.


From me at case.codes  Thu Jun 25 18:59:51 2020
From: me at case.codes (Case Nelson)
Date: Thu, 25 Jun 2020 17:59:51 +0000 (UTC)
Subject: SPOOFED: Re: [ANN] Tiny ad-hoc server
In-Reply-To: <stSWi7Ym4kO8LsHPDBzzfrqmadZHHhZZaZRmLmaZlXiRMUHKu_FhUN06JDZ16YyV2sFBsx9sJfEBNDif2zNGt6leN8gPiyqxrsTX4CS3ybk=@protonmail.com>
References: <f8ec8fb7-757b-5204-7b1b-db9187f9a130@lavabit.com>
 <1DXsRDdaU_9fYcgkeozAbwq4h0TlL-HVZ4LX-g3OELw0Oxp4CcYf09nZ-3212g6M-DQrVb_dnwAXe_H2eyqJY0euPUBE17teb0QA4NuCZ0I=@protonmail.com>
 <fea1aa24-cb56-ab61-69ff-b7ef353421aa@lavabit.com>
 <stSWi7Ym4kO8LsHPDBzzfrqmadZHHhZZaZRmLmaZlXiRMUHKu_FhUN06JDZ16YyV2sFBsx9sJfEBNDif2zNGt6leN8gPiyqxrsTX4CS3ybk=@protonmail.com>
Message-ID: <044ea4e7-4e04-4a8f-af70-f1d68f041621@case.codes>

I think you can get rid of the loop here and use ncat -k , it's been working pretty well for me in testing.

Jun 25, 2020 6:30:42 AM defdefred <defdefred at protonmail.com>:

> Ok I'm dumb... don't saw the braces :-)
> 
> Bash process substitution will do too
> 
> #!/bin/sh
> 
> port="1965"
> cert="cert.pem"
> key="key.pem"
> 
> printf "Starting gemini server on port %s...\n" "$port"
> while true; do
> ncat --ssl --ssl-cert "$cert" --ssl-key "$key" --listen "$port" <( \
> printf "20 text/gemini; charset=utf-8\r\n" ; \
> printf "Page generated: %s\n\n" "$(date)" ; \
> cat "$1" )
> done
> 
> freD.
> 
> ??????? Original Message ???????
> On Thursday 25 June 2020 14:09, James Tomasino <tomasino at lavabit.com> wrote:
> 
>> On 6/25/20 11:34 AM, defdefred wrote:
>> 
>>> I don't understand how the infinite while works in this case...
>>> Is it consuming cpu all the time?
>> 
>> ncat waits only for a single connection, then terminates. I tried using the switch to keep the connection alive and reuse it, but that means the connection is never closed on any single request and most clients display nothing. By wrapping it in an infinite while I just tell ncat to start a new listener when the previous one is used. There's only ever one running at a time, and it's a single thread, but traffic is low and it seems to work just fine.
> 

From defdefred at protonmail.com  Thu Jun 25 19:08:30 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 18:08:30 +0000
Subject: Mercury
In-Reply-To: <20200625160444.GG16671@SDF.ORG>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
Message-ID: <GOjArCvVQ4LXWQDw8wCxx_i3ZgKpPjj27so1NvRjcOfyL8xiwbsukDT0GWLVrVASLk3jXpKCcg6nFL7HxlqNmctPTjIuht-vZpejNCeRtB8=@protonmail.com>

On Thursday 25 June 2020 18:04, solderpunk <solderpunk at SDF.ORG> wrote:
> I will reply to this whole Mercury thread tomorrow (probably relatively
> briefly), but a quick request for disambiguation, regarding the SUV
> analogy: is the objection here mostly on the grounds of prefering
> minimalism, simplicity, easier DIYability? Or is there actually an
> explicit environmental component here, regarding the energy overhead of
> encryption?

Limiting the environmental footprint of internet is useful.
For example, this site https://solar.lowtechmagazine.com/ will run longer without encryption...

Limiting the latency is useful too.
So light document should display directly after request.
The one request per file paradigm make latency more visible, when I click one image, it should display fast.

Encryption is very important too.
So Gemini for strong encryption and Mercury for public data or DIY static encryption seems perfect.

Not everybody have fiber internet connection and a protocol able to serv data on limited network is valuable.
http://www.rowetel.com/?p=7207
https://hackaday.com/2020/02/26/lora-mesh-network-with-off-the-shelf-hardware/


freD.

From mbrubeck at limpet.net  Thu Jun 25 19:22:29 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Thu, 25 Jun 2020 11:22:29 -0700
Subject: [ANN] deedum browser update
In-Reply-To: <20200625155819.GF16671@SDF.ORG>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <20200625155819.GF16671@SDF.ORG>
Message-ID: <CAD1=23m64taSwp9ByS8C31DEp3sSSBkgO4oqLhoi4EMYRRJS3Q@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200625/dc2385ad/attachment.htm>

From solderpunk at SDF.ORG  Thu Jun 25 19:42:28 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 25 Jun 2020 18:42:28 +0000
Subject: Mercury
In-Reply-To: <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
References: <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
Message-ID: <20200625184228.GH16671@SDF.ORG>

On Wed, Jun 24, 2020 at 06:30:26PM +0200, Felix Quei?ner wrote:
> Hey
> 
> > That the point about serving public data encrypted while every body can request it?
> > Example:
> > - public domain book
> > - weather (curl wttr.in/paris)
> > - public news
> > - governmental information
> > - cute kitten videos
> > - etc.
> Yes, as you can trust that you actually receive the data the server
> wants you to see. If a MITM attack happens, they can serve you the wrong
> news for example, wrong governmental information (deluding you to do
> illegal acts)

Okay, I lied, some Mercury responses today, not tomorrow. :)

No MITM attack is even necessary for this n?ive "I can use plaintext
to read publically available information and only turn it on when I do
important secret stuff" attitude to backfire!  Does this really need
explanation in 2020?  Here's a list of publically available,
non-personal information, a lot of which you could find in a good
public library, which would nevertheless be a very bad idea to be
easily identified as wanting to read or having read in various
times/places in recent history right up to the present, with
consequences ranging from serious social stigma and ostracism to
imprisonment, torture and death:

* The Bible
* The Torah
* The Quran
* The collected works of Karl Marx
* The collected works of the US founding fathers
* Eye-witness accounts of what happened in Tiananmen Square in 1989
* Factual medical information concerning contraception
* Factual medical information concerning abortion
* Factual medical information concerning sexually transmitted diseases
* Factual medical information concerning same-sex sexual health
* Factual legal information concerning domestic violence
* Factual legal information concerning sexual assault
* Factual legal information concerning recreational drugs
* Factual political information on when/where/how to vote for X
* Public news reporting from the "wrong" source

This is not a remote issue affecting only distant third-world
dictatorships, or an outdated issue only relevant in the McCarthyist
past; plenty of the above will get you into trouble in certain parts of
Western liberal democracies in 2020 - okay, probably not tortured or
killed by the government, but people will absolutely be bullied, be
beaten up, be kicked out of home, be kicked out of school, or lose
friends, parters or jobs because of some of the above material even in
"normal" countries where none of the above is illegal (and in the case
of information on abortion in some parts of the US, jail time is not 
actually inconceivable).

Often times the adversary who needs to be defeated to avoid these
scenarios is not an all-powerful intelligence/police/military actor with
a big budget and a team of infosec specialists and a warehouse full of
supercomputers, for whom TLS is (perhaps) not impenetrable, but rather
parents, teachers, classmates, employers, nosy small business owners
providing open wireless hotspots, script kiddies sniffing traffic on
said hotspots or small, rural police departments for whom we can safely
assume TLS *is* impenetrable.

Lucky you if 99% of what you want to read online does not fall into
these categories at the present time in your present location, but:
* What's safe today may not be safe tomorrow (and computers can
  remember for a long time).
* Making it easy to deliberately perform unencrypted transactions when
  it's safe simultaneously makes it easy to accidentally perform (or to
  be tricked into performing) unencrypted transactions when it's *not*
  safe.
* Only using encryption the 1% of times you really need it makes the
  use of encryption suspicious in and of itself.

Crypto is not a "sometimes food"!  More or less the entire technology
industry has accepted this argument and the simultaneous side-by-side
existence of http:// and https:// with browsers equally happy to accept
either is on its way to becoming a brief historical accident.  I'm
really unenthusiastic about deliberately rolling that clock back in
Geminispace.  More than one person has told me that Gopher's lack of
support for encryption stopped them from ditching the web in favour of
Gopher, despite prefering Gopher in every other respect.  Now they're
happily in Geminispace.  I suspect that this is *not* an unusual
situation.

Yes, it sucks that this philosophy drags in some complexity (I chose TLS
precisely to try to minimise the *implementation* complexity, by virtue
of ubiquitious library support and documentation) and some performance
penalty (which we so far have not made much serious effort to
ameliorate) and an increased energy footprint (which I assure you
professional cryptographers are actively trying to reduce without
compromising security, because doing so will improve battery life on
phones and "smart" devices, which is a multi-billion dollar industry,
and by virtue of using the industry-standard TLS we'll be able to reap
future payoffs of this research - and which, anyway, I am not sure is
actually greater than the wireless data transmission footprint in many
real-world scenarios).  I still think it's the right philosophy for
Gemini and that throwing away important privacy protections for the sake
of decreased latency would make many more would-be Geminauts sad than
it would make happy.  I really think we just need to do our best to
minimise the impact of the unavoidable suckage that ubiquitious
cryptography brings with it.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jun 25 19:43:55 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 25 Jun 2020 18:43:55 +0000
Subject: Atom Feeds?
In-Reply-To: <Og0LicCSoXY6aECt6YUMyk8Na0eNLuqizHzCIDDnDsRSpqWH62FE7AIk_fJ6pN54LUMyN-tJTAGG4Oe3JwUbp15c3CV-bSVYMFCeBWuea5U=@protonmail.com>
References: <1AABDE38-5067-49D0-9D16-4AD374439861@firemail.cc>
 <JhPTmoVgcAzyYWbJyvs-thqZOHouVnN9QskffwF2tbhgQ0nZY1gYwzTK3bAsBuQ_KYeJ5WcVFOQnVK6ah5mk4dqLlJAZbIlbmy1WagkEu1k=@protonmail.com>
 <20200625155519.GE16671@SDF.ORG>
 <Og0LicCSoXY6aECt6YUMyk8Na0eNLuqizHzCIDDnDsRSpqWH62FE7AIk_fJ6pN54LUMyN-tJTAGG4Oe3JwUbp15c3CV-bSVYMFCeBWuea5U=@protonmail.com>
Message-ID: <20200625184355.GI16671@SDF.ORG>

On Thu, Jun 25, 2020 at 05:11:24PM +0000, defdefred wrote:
 
> - tag classification
> - production of external pgp signature per document
> - creation of synthetic report for GUS to avoid redundant network download
> 
> I like the work one, serve many of static sites.
> 

Yes, these are also all fine ideas.  There still hasn't been any
discussion yet of whether we want/need something like sitemap.xml in
Geminispace.

Cheers,
Solderpunk

From philanc at gmail.com  Thu Jun 25 19:48:04 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Thu, 25 Jun 2020 18:48:04 +0000
Subject: Mercury
In-Reply-To: <20200625160444.GG16671@SDF.ORG>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
Message-ID: <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>

On Thu, Jun 25, 2020 at 4:04 PM solderpunk <solderpunk at sdf.org> wrote:
>
> a quick request for disambiguation, regarding the SUV
> analogy: is the objection here mostly on the grounds of prefering
> minimalism, simplicity, easier DIYability?  Or is there actually an
> explicit environmental component here, regarding the energy overhead of
> encryption?

_minimalism_:  as a personal taste and aesthetic principle, Yes. Also
a guiding principle, as frugality.

_simplicity_: Yes, by far the most important reason -- as in "less
moving parts", "no black box". Easily understanding all the core parts
to the ground  Grasping it all at the same time without digging deep.

It relates to "_explainability_":  explain sockets and basic network
to a beginner and they will grasp Gemini without pain - it could even
be a basic example of how to use sockets

Back to the analogy: Show me a bicycle, I understand immediately how
it works - except maybe the freewheel :-)  Show me the modern SUV
engine fuel injection system. I somehow _know_ what it does. I know it
is very efficient. I know the black box contains powerful MCUs with
sophisticated algorithms. I don't really feel I understand it.

I remember a Python core developer coming up with a nice motto for a
Python conference many years ago: "It fits my brain".  Gemini, without
TLS fits my brain.  A bicycle, even an old car may fit my brain. A
modern car does not anymore.

_easier DIYability_: Yes. closely related to simplicity. A _very
refreshing_ aspect of Gemini is "it is so simple you can implement it
in a few hours. -- Ooops... and for TLS?  -- it is very simple. Just
call this [big] shared library. -- Hmm ... if I call a big TLS library
where it becomes complex, I could as well _very easily_ build a
HTTP/HTML client by calling libcurl, right?  And arguably, I can find
libcurl in as many platforms as libtls!

I think it relates also to hardware hobbyists. I don't mean the
Raspberry Pi sort of thing (actually more powerful than hardly old
PCs). I mean rather Arduino-like boards. I could imagine some smart
guys will or have already implemented a ultra minimal TCP stack, and
PPP to an internet gateway and could use Gemini -- ... probably not
with TLS.

Phil

From felix at masterq32.de  Thu Jun 25 19:59:29 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Thu, 25 Jun 2020 20:59:29 +0200
Subject: Mercury
In-Reply-To: <20200625184228.GH16671@SDF.ORG>
References: <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de> <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
Message-ID: <ab66e815-dfe4-12a0-ea0b-4a795b369c7c@masterq32.de>


> No MITM attack is even necessary for this n?ive "I can use plaintext
> to read publically available information and only turn it on when I do
> ...

Wonderfully said, i fully agree with you and will incorporate that email
into my stash of arguments.

Regards
- xq

From philanc at gmail.com  Thu Jun 25 20:48:43 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Thu, 25 Jun 2020 19:48:43 +0000
Subject: Mercury
In-Reply-To: <GOjArCvVQ4LXWQDw8wCxx_i3ZgKpPjj27so1NvRjcOfyL8xiwbsukDT0GWLVrVASLk3jXpKCcg6nFL7HxlqNmctPTjIuht-vZpejNCeRtB8=@protonmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
 <GOjArCvVQ4LXWQDw8wCxx_i3ZgKpPjj27so1NvRjcOfyL8xiwbsukDT0GWLVrVASLk3jXpKCcg6nFL7HxlqNmctPTjIuht-vZpejNCeRtB8=@protonmail.com>
Message-ID: <CAOH6EB_JgsNpRmMkDQ3c0G-r=RBec29ahOg6bOfhajgWJcj6Jg@mail.gmail.com>

On Thu, Jun 25, 2020 at 6:08 PM defdefred <defdefred at protonmail.com> wrote:
>
> Limiting the environmental footprint of internet is useful.
> For example, this site https://solar.lowtechmagazine.com/ will run longer without encryption...

Right.


> Limiting the latency is useful too.
> So light document should display directly after request.
> The one request per file paradigm makes latency more visible, when I click one image, it should display fast.

Yes. But as Solderpunk just said, the whole industry is marching
towards more efficient and integrated solutions to these: reducing the
energy consumed and the latency  -- ... at the expense of ever more
complexity.   Having a look at Early Data and how to safely use
pre-shared keys (PSK) in the openssl documentation just made me cringe
:-)

> Encryption is very important too.

 Yes it is. And Gemini / Mercury could be a great playground to
explore alternative options.

> http://www.rowetel.com/?p=7207
> https://hackaday.com/2020/02/26/lora-mesh-network-with-off-the-shelf-hardware/

Cool!!   thanks for the links.  I am sure more and more hobbyists and
hackers will develop interesting alternative network solutions. I
think Gemini/Mercury could be a great fit in these new spaces.

Phil

From solderpunk at SDF.ORG  Thu Jun 25 20:51:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 25 Jun 2020 19:51:03 +0000
Subject: Mercury
In-Reply-To: <ab66e815-dfe4-12a0-ea0b-4a795b369c7c@masterq32.de>
References: <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <ab66e815-dfe4-12a0-ea0b-4a795b369c7c@masterq32.de>
Message-ID: <20200625195103.GA1146@SDF.ORG>

On Thu, Jun 25, 2020 at 08:59:29PM +0200, Felix Quei?ner wrote:
> 
> > No MITM attack is even necessary for this n?ive "I can use plaintext
> > to read publically available information and only turn it on when I do
> > ...
> 
> Wonderfully said, i fully agree with you and will incorporate that email
> into my stash of arguments.
>

Thank you, but actually, I deeply regret making that email my first
response to this thread.  Please, nobody else reply to it.  I believe in
and stand by everything I said, but let's be honest, it's nothing
everybody hasn't heard before.  The people who are already sold on
ubiquitous crypto are, well, already sold, and the people who aren't
probably never will be.  The last thing we need is this thread - which
is already a distraction from work on Gemini proper - diverging into a
long and heated argument about cryptopolitics.  I regret letting myself
get worked up over what is a personal hot topic for me.

I'll reply again tomorrow with a more level-headed response.  I do have
other things to say on this - there are issues of fundamentally
incompatible targets of optimisation (really low energy consumption and
really low latency are at odds with one another) and about understanding
what Gemini's realistic niches are (regarding really low energy
consumption, I am full of enthusiasm for radical solarpunk utopia
visions of an alternative internet, but I don't think Gemini fits there
- it's full of "old world internet" ideas - client-server architecture,
location-based addressing, etc.  It has no real place in a future world
of solar-powered RaspberryPis forming small local mesh networks with
inter-village data transfer performed by vegans riding bikes with
saddlebags full of USB sticks).  And, of course, the actual role/status
of the Mercury thought experiment.

Cheers,
Solderpunk
(signing off the the night)

From defdefred at protonmail.com  Thu Jun 25 20:54:18 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 19:54:18 +0000
Subject: Mercury
In-Reply-To: <20200625184228.GH16671@SDF.ORG>
References: <87pn9pg45a.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
Message-ID: <Wubnvbgwb0zuUrqfAIrkPMDTtT6k5Uj9mnYDgH6WIVnPOTUXX2rbssJ3wfRL9Ild9QUiVENy8vopkrV5wYjI6mgmbhaUF2geVfaqD1dXVho=@protonmail.com>

On Thursday 25 June 2020 20:42, solderpunk <solderpunk at SDF.ORG> wrote:
> -   The Bible
So if you read www.the-bible.org TLS will not keep your privacy as IP:port is not encrypted...

Seems that VPN is the only way to privacy...

A good dictator should have a https proxy with TLS interception and force all the population to us it...

freD.

From defdefred at protonmail.com  Thu Jun 25 21:05:00 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 20:05:00 +0000
Subject: Mercury
In-Reply-To: <Wubnvbgwb0zuUrqfAIrkPMDTtT6k5Uj9mnYDgH6WIVnPOTUXX2rbssJ3wfRL9Ild9QUiVENy8vopkrV5wYjI6mgmbhaUF2geVfaqD1dXVho=@protonmail.com>
References: <87pn9pg45a.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <Wubnvbgwb0zuUrqfAIrkPMDTtT6k5Uj9mnYDgH6WIVnPOTUXX2rbssJ3wfRL9Ild9QUiVENy8vopkrV5wYjI6mgmbhaUF2geVfaqD1dXVho=@protonmail.com>
Message-ID: <yNIdjcVJecuK56IiKMnPt18XeI_C1Hsa2ESGFfDlFVfsqMnh7Hyg2zYmiJeMzpbi5BOGiouCrC6H_Ye8g9_E4ag66VXW3J-HL3akiKjnVlM=@protonmail.com>

On Thursday 25 June 2020 21:54, defdefred <defdefred at protonmail.com> wrote:
> Seems that VPN is the only way to privacy...

VPN + no log keeping gateway...



From defdefred at protonmail.com  Thu Jun 25 21:06:55 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 20:06:55 +0000
Subject: Fw: Re: Mercury
In-Reply-To: <hui6mxEmSvfA5DpGUolfPn1o-ShSo-mD7GNTPirlXu5gt8nc3MjUn5bTen0gLTPrk68MSiP0M-OqM10h30BmDUpFS5MZzeFRwchYmzwBB9M=@protonmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>
 <2p3ofLX2Mq0w2ljJObLLX9bmIbmFVgBn1twvxC5jlnEoze2uAmxlKFKskxbuk2V7F8dTY3f2xj0DpnKUjdkpM5VlJEBgOcGLgw6GJPiIBlY=@protonmail.com>
 <20200624220351.GD19717@brevard.conman.org>
 <hui6mxEmSvfA5DpGUolfPn1o-ShSo-mD7GNTPirlXu5gt8nc3MjUn5bTen0gLTPrk68MSiP0M-OqM10h30BmDUpFS5MZzeFRwchYmzwBB9M=@protonmail.com>
Message-ID: <weBEDRqC0IwaMiMWzw4TZApLaFsoHivZtxMXaFey5FyShJp-HZZGUzUSP4B1nA6Hz9ZJwhA9dLT8q--aYvQKGIigKvxHIu8h-q-7D2pjiHY=@protonmail.com>

sorry list email missing in my reply...

??????? Original Message ???????
On Thursday 25 June 2020 10:23, defdefred <defdefred at protonmail.com> wrote:

> On Thursday 25 June 2020 00:03, Sean Conner sean at conman.org wrote:
>
> > How do you safely get my public key?
>
> By asking to you?
> By checking on https://keys.openpgp.org/?
> By checking on several server on a dedicate page of known public keys?
>
> all of this...



From defdefred at protonmail.com  Thu Jun 25 21:07:52 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 20:07:52 +0000
Subject: Fw: Re: Mercury
In-Reply-To: <20200625091658.GG19717@brevard.conman.org>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <1fcc0ccf-de9b-4762-b3c4-a9048422591b@www.fastmail.com>
 <2p3ofLX2Mq0w2ljJObLLX9bmIbmFVgBn1twvxC5jlnEoze2uAmxlKFKskxbuk2V7F8dTY3f2xj0DpnKUjdkpM5VlJEBgOcGLgw6GJPiIBlY=@protonmail.com>
 <20200624220351.GD19717@brevard.conman.org>
 <hui6mxEmSvfA5DpGUolfPn1o-ShSo-mD7GNTPirlXu5gt8nc3MjUn5bTen0gLTPrk68MSiP0M-OqM10h30BmDUpFS5MZzeFRwchYmzwBB9M=@protonmail.com>
 <20200625091658.GG19717@brevard.conman.org>
Message-ID: <g3bsfkwUyOhdghpnr-PqQO1XakDsU3UK2NcD5zdQJ7jgRGrZ1XBiPjRYw-roDoZKMipKnBedC8Lgyj46CFb9GUonbLBtymuavwWkmooJkaU=@protonmail.com>

sorry list email missing in my reply...

??????? Original Message ???????
On Thursday 25 June 2020 11:16, Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great defdefred once stated:
>
> > On Thursday 25 June 2020 00:03, Sean Conner sean at conman.org wrote:
> >
> > > How do you safely get my public key?
> >
> > By asking to you?
> > By checking on https://keys.openpgp.org/?
> > By checking on several server on a dedicate page of known public keys?
> > all of this...
>
> Okay, I'll be replying to several of your messages here because I'm
> getting mixed signals here. And then I can answer your questions.
>
> First:
>
> > It will also permit surfing at the speed of ligth with instant display of
> > clicked link... something that is no more existing in the
> > old-school-too-much dynamic web.
>
> and
>
> > Having TLS is better, but it come with a latency cost with the one
> > connection per request behavior. Freedom is also having the choice.
>
> It seems a primary concern of yours is overhead of establishing a
> connection. Well, TCP itself has overhead---three packets (at 40 bytes per)
> before the connection is considered "up". Yes, TLS increaases that bit
> more, but to say that there will be no latency without TLS is not a good
> argument. UDP has no latency, but there are other issues with using it [1].
>
> Continuing ...
>
> > Optional PGP signature is enough to provide integrity.
> > Are you sure that TLS is safe? States are allowing communication they
> > can't decipher?
>
> and
>
> > The fun fact is:
> >
> > -   with TLS, the whole server is using only one certficat and the integrity
> >     of publication rely only on this security and you don't know if it is a
> >     compromised server.
> >
> > -   with PGP signature, each writer using the server have his own certificat
> >     to secure his writing integrity.
> >
>
> and
>
> > When you are reading pgp signed document from a server where you own a
> > defined set of public pgp keys, you don't fear MITM attack (the same way
> > TLS is secure only with a PKI).
> > The difference is that external PGP signature are all computed only at
> > document publication time and not on the fly for each user request.
>
> It also seems you have reservations about the PKI infrastructure, which is
> fine, I do too. It seems you really distrust TLS. Okay. But PGP (for GPG
> for that matter) isn't the silver bullet you think it is. So let me answer
> you questions now.
>
> > By asking to you?
>
> Okay.HOW do I get you the public key and ensure you have it correctly?
> Yes, it's a public key, so there's no issue with people seeing it, but how
> do you know I am the one giving you the key?
>
> The only way I know of to be 100% certain is to exchange keys in person.
>
> > By checking on https://keys.openpgp.org/?
>
> I'll throw your own statement back at you: "you don't know if it is a
> compromised server." I don't know, and I think you don't know either.
> Again, your own words back at you: "Are you sure that TLS is safe? States
> are allowing communication they can't decipher?"
>
> > By checking on several server on a dedicate page of known public keys?
>
> Reduces the likelyhood of MITM, but still a pain.
>
> The hardest part of cryptography, by far, is key management. There is
> still no good way to distribute public keys that aren't subject to various
> attacks.
>
> -spc
>
> [1] Namely, you open yourself up to participate in amplified denial of
> service attacks. I used to run the QOTD service on UDP, until I
> realized I was getting requests from forged IP addresses and sending
> data to said forged IP addresses. This is why we can't have nice
> things on the Internet. [2]
>
> [2] QUIC. Yes, I know about it. Yes, I don't like it, and it will have
> similar issues to TCP. Yeah, yeah, Google says it has 0-connection
> overhead, but I don't know how hard it's been attacked yet. And
> guess what? That's yet another library dependency for a "simple
> client" because QUIC has no support in any kernel I know of, and
> probably won't for several years. I also don't trust Google, but
> that's my issue.



From paper at tilde.institute  Thu Jun 25 22:23:51 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Thu, 25 Jun 2020 17:23:51 -0400
Subject: Mercury
In-Reply-To: <yNIdjcVJecuK56IiKMnPt18XeI_C1Hsa2ESGFfDlFVfsqMnh7Hyg2zYmiJeMzpbi5BOGiouCrC6H_Ye8g9_E4ag66VXW3J-HL3akiKjnVlM=@protonmail.com>
References: <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <Wubnvbgwb0zuUrqfAIrkPMDTtT6k5Uj9mnYDgH6WIVnPOTUXX2rbssJ3wfRL9Ild9QUiVENy8vopkrV5wYjI6mgmbhaUF2geVfaqD1dXVho=@protonmail.com>
 <yNIdjcVJecuK56IiKMnPt18XeI_C1Hsa2ESGFfDlFVfsqMnh7Hyg2zYmiJeMzpbi5BOGiouCrC6H_Ye8g9_E4ag66VXW3J-HL3akiKjnVlM=@protonmail.com>
Message-ID: <20200625212351.qsed7bmloqw27zuc@tilde.institute>

On Thu, Jun 25, 2020 at 08:05:00PM +0000, defdefred wrote:
> On Thursday 25 June 2020 21:54, defdefred <defdefred at protonmail.com> wrote:
> > Seems that VPN is the only way to privacy...
> 
> VPN + no log keeping gateway...
> 

not really, VPN is only moving the problem to a different state/company,
then the traffic would be plain text. The solution would be a VPN to the
gemini server, but basicaly that's called TLS xD

Paper

From defdefred at protonmail.com  Thu Jun 25 22:41:56 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 25 Jun 2020 21:41:56 +0000
Subject: Mercury
In-Reply-To: <20200625212351.qsed7bmloqw27zuc@tilde.institute>
References: <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <Wubnvbgwb0zuUrqfAIrkPMDTtT6k5Uj9mnYDgH6WIVnPOTUXX2rbssJ3wfRL9Ild9QUiVENy8vopkrV5wYjI6mgmbhaUF2geVfaqD1dXVho=@protonmail.com>
 <yNIdjcVJecuK56IiKMnPt18XeI_C1Hsa2ESGFfDlFVfsqMnh7Hyg2zYmiJeMzpbi5BOGiouCrC6H_Ye8g9_E4ag66VXW3J-HL3akiKjnVlM=@protonmail.com>
 <20200625212351.qsed7bmloqw27zuc@tilde.institute>
Message-ID: <PZvoJu3vFVvZemrvdAT_RGU9JZ1IUn7w-6Bz-OnaDe51nVu9p_UBZ7We08oTiVtseo0kmKCSNrck9c1iOTEBh2ZzWeFjmtlFqvx-lOs_EnE=@protonmail.com>

On Thursday 25 June 2020 23:23, <paper at tilde.institute> wrote:
> not really, VPN is only moving the problem to a different state/company,
> then the traffic would be plain text. The solution would be a VPN to the
> gemini server, but basicaly that's called TLS xD

True, but a VPN is created to serve multiple requests.

May be wireguard to the gemini server is the way to go :-)

freD.

From colecmac at protonmail.com  Thu Jun 25 22:44:01 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 25 Jun 2020 21:44:01 +0000
Subject: Mercury
In-Reply-To: <20200625195103.GA1146@SDF.ORG>
References: <87mu4tg3iw.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <ab66e815-dfe4-12a0-ea0b-4a795b369c7c@masterq32.de>
 <20200625195103.GA1146@SDF.ORG>
Message-ID: <n5Q5X8EwCJyQjF84c6APWSnFWNf1EvOKAySgPBY6Hntc_6W1BbdnjmbkRNZ_zFOD5IggmdiN6aOgOQ5C7XtcLdftNhrMv_z9uXFnd_zJACQ=@protonmail.com>

> a future world of solar-powered RaspberryPis forming small local mesh networks
> with inter-village data transfer performed by vegans riding bikes with
> saddlebags full of USB sticks

Stealing this ;)

But seriously, thanks for chiming in on the Mercury discussion. I'll be happy
to read your post tomorrow.

makeworld

From hannu.hartikainen+gemini at gmail.com  Fri Jun 26 07:48:52 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Fri, 26 Jun 2020 09:48:52 +0300
Subject: Mercury
In-Reply-To: <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>
References: <CAOH6EB-PtjzZqbF+EhhYktzUD1TqELbpyBDDCyZUOiYAd4N+sw@mail.gmail.com>
 <87pn9pg45a.fsf@jb55.com> <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
 <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>
Message-ID: <CANmFPema2AA8wWyddasfWksFv1MaP=-ywL0U7ee0Z5hdDCA+Vw@mail.gmail.com>

On Thu, 25 Jun 2020 at 21:48, Phil Leblanc <philanc at gmail.com> wrote:

> It relates to "_explainability_":  explain sockets and basic network
> to a beginner and they will grasp Gemini without pain - it could even
> be a basic example of how to use sockets
>

In my humble opinion, this extends to TLS too. Tell a beginner about
asymmetric cryptography and how it can be used to negotiate a key for
symmetric cryptography, and they will understand the general concept of TLS
and thus "grasp Gemini without pain".

I remember a Python core developer coming up with a nice motto for a
> Python conference many years ago: "It fits my brain".  Gemini, without
> TLS fits my brain.  A bicycle, even an old car may fit my brain. A
> modern car does not anymore.
>

I have two issues with this argument. The first one is that whoever uses
it, uses their brain as the golden standard. The second one is that it
assumes that "basic networking" is easy to understand.

I once spent weeks and weeks in low-level TCP debugging at my day job, and
obviously trying to learn whatever I can to facilitate the work. After long
days of reading RFCs and investigating Wireshark dumps, I still can't say I
understand TCP (let alone IP or Ethernet, let alone the complete network
stack). I once researched what it would take to implement an ethernet
adapter on an FPGA and it's a huge amount of work.

I've never taken a freewheel or a derailleur apart, yet I fully understand
how they work. TCP/IP I've spent man-months on, yet I only have a surface
understanding.

***

Sorry if this comes off as rude or argumentative. I do see the point of the
"fits my brain" concept, and am actively trying to fit stuff into my brain.
I do understand wanting Gemini without TLS; I just don't agree with the
goal nor with these arguments.

IMHO there would be room for a really simple, really low-latency text
protocol. Gopher over UDP, maybe? But that's another experiment.

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200626/f177951f/attachment-0001.htm>

From pitr.vern at gmail.com  Fri Jun 26 09:52:06 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Fri, 26 Jun 2020 10:52:06 +0200
Subject: [ANN] deedum browser update
In-Reply-To: <CAD1=23m64taSwp9ByS8C31DEp3sSSBkgO4oqLhoi4EMYRRJS3Q@mail.gmail.com>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <20200625155819.GF16671@SDF.ORG>
 <CAD1=23m64taSwp9ByS8C31DEp3sSSBkgO4oqLhoi4EMYRRJS3Q@mail.gmail.com>
Message-ID: <CAG-mZ3iXsrDyZ3YWvUVmX0=mbgAW5GqL7oet=gq0QbYe-+JRqQ@mail.gmail.com>

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
>

From defdefred at protonmail.com  Fri Jun 26 10:19:07 2020
From: defdefred at protonmail.com (defdefred)
Date: Fri, 26 Jun 2020 09:19:07 +0000
Subject: [ANN] GemiNaut 0.8.5 released
In-Reply-To: <suaqCRaXR9KKgzJZFY-deMrmyynQrdP9_UzX5WxdXoSNJbdHClB4BO_9X3rO0sB2MrYkeRZmyJVRXh7R3wB8js7HOU2ATqIKThxBa-wBvZg=@protonmail.com>
References: <5EEF618E.80807@marmaladefoo.com>
 <159274737669.2727245.13178353740623233928@localhost.localdomain>
 <5EEF7A5A.1050602@marmaladefoo.com>
 <suaqCRaXR9KKgzJZFY-deMrmyynQrdP9_UzX5WxdXoSNJbdHClB4BO_9X3rO0sB2MrYkeRZmyJVRXh7R3wB8js7HOU2ATqIKThxBa-wBvZg=@protonmail.com>
Message-ID: <_GSjGfn3ZumFJdHiLiY6LXU3TUKJBf-LlTRy32-O90BP80AUhf7rdcdhBYBmXCVG4Z1A0KhEl5gB128qMCOb02zTd-AHY1Llq1mcDkxRnSo=@protonmail.com>

Hey Luke,

Geminaut is crashing when I put a wrong url...
"toto" for example.


freD.

??????? Original Message ???????
On Monday 22 June 2020 11:18, defdefred <defdefred at protonmail.com> wrote:

> Thanks for your work!
>
> Thought: TOC could be accessible via application menu rather then inside the document...
>
> freD.



From solderpunk at SDF.ORG  Fri Jun 26 12:04:24 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 26 Jun 2020 11:04:24 +0000
Subject: Mercury
In-Reply-To: <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>
References: <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
 <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>
Message-ID: <20200626110424.GA4156@SDF.ORG>

On Thu, Jun 25, 2020 at 06:48:04PM +0000, Phil Leblanc wrote:
> _minimalism_:  as a personal taste and aesthetic principle, Yes. Also
> a guiding principle, as frugality.
> 
> _simplicity_: Yes, by far the most important reason -- as in "less
> moving parts", "no black box". Easily understanding all the core parts
> to the ground  Grasping it all at the same time without digging deep.
> 
> It relates to "_explainability_":  explain sockets and basic network
> to a beginner and they will grasp Gemini without pain - it could even
> be a basic example of how to use sockets
> 
> ...
> 
> _easier DIYability_: Yes. closely related to simplicity. A _very
> refreshing_ aspect of Gemini is "it is so simple you can implement it
> in a few hours. -- Ooops... and for TLS?  -- it is very simple. Just
> call this [big] shared library. -- Hmm ... if I call a big TLS library
> where it becomes complex, I could as well _very easily_ build a
> HTTP/HTML client by calling libcurl, right?  And arguably, I can find
> libcurl in as many platforms as libtls!
> 
> I think it relates also to hardware hobbyists. I don't mean the
> Raspberry Pi sort of thing (actually more powerful than hardly old
> PCs). I mean rather Arduino-like boards. I could imagine some smart
> guys will or have already implemented a ultra minimal TCP stack, and
> PPP to an internet gateway and could use Gemini -- ... probably not
> with TLS.

Thanks for clarifying.  For what it's worth, I acknowledge all these
points.  I appreciate beautifully minimal things like FORTH, I value
ease of teaching and of learning, and I tinker with AVR micros and even
more constrained platforms myself.  I get it.  These are important things
to consider.  But at the end of the day no one protocol can optimise
simultaneously for all these things.  Often times the different
requirements fight each other.  Even aesthetic minimalism and
explainability can conflict, as really beautifully minimal systems with
great generality/flexibility/power often require the user to first adapt
to some unfamiliar, abstract mode of thinking that is not easy to grasp
quickly.

Ultimately, Gemini is supposed to be a practical protocol to solve a
concrete, real-world problem: the web has become a disaster on many
fronts simultaneously, and lots of people really want out, at least some
of the time and for some things, but the only "off the shelf" thing they
can flee to for roughly the same experience is Gopher, but many of them
can't/won't flee to Gopher due to various shortcomings, one of which,
yes, really, is the lack of encryption.  I don't want Gemini to be a
beautiful object of appreciation for hackers that most people have no
use for (there's no shortage of these!), I want it to be a viable
lifeboat for evacuees from the web.  The first-class application is
computer literate non-developers using "normal computers" and software
other people wrote to read meaningful textual content with a reasonable
expectation of privacy.  I am happy to make it simpler, more beautiful,
more hackable, more general purpose, friendlier to low power computers
and slow networks, to whatever extent is possible without interfering
with its seaworthiness as a lifeboat.  I realise that it's worthwhile
to do so to incentivise developers (who are inevitably the early
adopters, and who will get excited by these properties) to write
clients and servers and other tools which can then be used by others.
And it honestly makes *me* happier to push it in those directions.
But throwing out TLS so that it can be more readily implemented by
somebody who just learned what a socket is yesterday is ultimately
self-defeating from the lifeboat perspective.  If part of the reason
people want to flee from the web is because of privacy concerns,
offering them a plaintext alternative makes no sense at all, and they
just won't make the jump.  The mandatory encryption in Gemini is an
important, functional, deliberate part of the lifeboat design.  It would
be a bad lifeboat without out.

When we *do* chase improvements in these other regards without
compromising our role as a lifeboat, we also need to keep a sense of
perspective, make our criteria clear, make measurements and not trust
our guts, etc.  I'm all for a lower power, greener internet.  But if you
really want to push in that direction hard, you need to make radical
departures from the basic paradigms that the web and Gemini are both
built around.  I'm talking about systems where content is automatically
and user-invisibly replicated across hosts and naturally ends up
"migrating" to hosts which are closest, from a network perspective, to
the places where demand for access to that content is highest.  A really
radical solarpunk future internet has to be built around slow,
intermittent, improvised/opportunistic connections, and "offline first"
thinking has to dominate.  Gemini is just dead in the water in that
kind of a world.  It's built around old-fashioned ideas, on purpose, in
order to be "radically familiar" to both users and developers from the
web, because a lifeboat protocol *needs* to be radically familiar.  If
you throw in P2P and content-based addressing and blockchains and all
the stuff you need to use to address the deep problems with the
internet, a majority of both users and developers immediately have no
idea what is going on and they won't get in your lifeboat because they
can't.  So, by virtue of its deliberate old fashionedness, Gemini is
never going to be the absolute best choice for low power consumption,
for low bandwidth, etc.  That's not so say we shouldn't give those
things any thought, but we needn't bend over backward for 1% or 2%
savings because it just doesn't make sense.  We should concern ourselves
with the "low hanging fruit" of these problems.

If people who are interested in solving problems other than the "web
evacuee lifeboat" problem, or who are interested in building "jewels for
hackers" want to start separate projects of their own to do so, I wish
them, sincerely, all the luck in the world.  I straight up do not have
the time and energy spare after Gemini to have even slight active
involvement in such projects, but that doesn't mean I don't wish them
well.  If these other projects want to make use of the text/gemini
markup format, I am more than happy about that - it's a popular part of
Gemini and one which is completely orthogonal to the network protocol.
Please feel free to distribute it over IPFS, DAT, SSB, Gopher (maybe
people can write Gopher clients which interpret item type 0 documents
differently based on file extension?  It forces you into ugly URLs
forever, but so be it), and stuff that doesn't even exist yet.  You have
my blessing.

Be wary, please, of spreading a small and young community (not the
Gemini community, but the "neo small internet" community) too thin with
multiple simultaneous projects with only minor differences between each
other.  Be wary of burdening client authors with an expectation that a
good "small internet browser" needs to simultaneously support a large
number of protocols to be useful, because that's a pain and you should
be nice to client authors.  Be wary that clients which speak encrypted
protocols and unencrypted ones and which flip between them automatically
and invisibly are fundamentally risky propositions.

Be aware that "Mercury", as I sketched it, was a "conceptual
navigational aid" for me to try to grapple with the question of whether
or not Gemini was becoming "too complex" (and one that most people - not
all, but most - had a very negative reaction to).  As such it is was
designed (very quickly!) from the perspective of starting with Gemini
and ripping stuff out.  If other projects seek to explicitly optimise
some criteria which they feel Gemini is lacking in (energy consumption,
network overhead or latency, fits-in-head-ability, need for external
libraries), they should be aware that the Mercury sketch is not
necessarily a sensible starting point, because its design took for
granted certain concepts already depply established in the design of
Gemini, and those concepts were not established with these other
criteria in mind.  You might do a lot better by starting from scratch
and making all decisions with your ultimate goal firmly in mind.

I think that's all I have to say on this matter.

Cheers,
Solderpunk


From jmcbray at carcosa.net  Fri Jun 26 12:51:05 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 26 Jun 2020 07:51:05 -0400
Subject: Mercury
In-Reply-To: <20200625184228.GH16671@SDF.ORG> (solderpunk@sdf.org's message of
 "Thu, 25 Jun 2020 18:42:28 +0000")
References: <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
Message-ID: <87d05mcafq.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> Yes, it sucks that this philosophy drags in some complexity (I chose TLS
> precisely to try to minimise the *implementation* complexity, by virtue
> of ubiquitious library support and documentation) and some performance
> penalty (which we so far have not made much serious effort to
> ameliorate) [...]

One argument that I often see is that TLS makes it impossible to use
Gemini with retrocomputing setups (i.e. computers older than about
2005 in this case). I've encountered this also with brutaldon, my static HTML
front-end for the Fediverse; people want to connect to it from Windows
3.1 or Mac System 7, and can't use anything newer than SSLv2, which a
modern server will reject.

My general recommendation for this case is to run a proxy (e.g. stunnel)
on your own LAN, on something like a Raspberry Pi or a cellphone, and
let it handle the encryption. This would work for Gemini as well. You'd
need a cleartext client, but only for retro devices.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From solderpunk at SDF.ORG  Fri Jun 26 13:55:52 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 26 Jun 2020 12:55:52 +0000
Subject: Mercury
In-Reply-To: <87d05mcafq.fsf@dorothy.carcosa.net>
References: <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <87d05mcafq.fsf@dorothy.carcosa.net>
Message-ID: <20200626125552.GB4156@SDF.ORG>

On Fri, Jun 26, 2020 at 07:51:05AM -0400, Jason McBrayer wrote:
 
> One argument that I often see is that TLS makes it impossible to use
> Gemini with retrocomputing setups (i.e. computers older than about
> 2005 in this case). I've encountered this also with brutaldon, my static HTML
> front-end for the Fediverse; people want to connect to it from Windows
> 3.1 or Mac System 7, and can't use anything newer than SSLv2, which a
> modern server will reject.

I see it too.  I love retrocomputing!  Honestly.  But it's insane to say
that 99.9% of the world should sacrifice important privacy protections so
that the geekiest 0.1% can play with very old computers.  I am kind of
dubious that it's impossible to compile a modern TLS library on a
computer from 2005, but I'll admit I haven't tried it recently (up until
approximatey 3 or 4 years ago I occasionally used a Thinkpad X60s (from
2006) and I don't remember having any TLS issues).
 
> My general recommendation for this case is to run a proxy (e.g. stunnel)
> on your own LAN, on something like a Raspberry Pi or a cellphone, and
> let it handle the encryption. This would work for Gemini as well. You'd
> need a cleartext client, but only for retro devices.

This is a really solid suggestion and I may well add it to the FAQ in
the retrocomputing sections.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri Jun 26 14:33:09 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 26 Jun 2020 13:33:09 +0000
Subject: Real world data on TLS power consumption on mobile devices
Message-ID: <20200626133309.GC4156@SDF.ORG>

For those interested:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6806263/

A quick summary, focussing on stuff relevant for TLS 1.3 or TLS 1.2
limited to TLS 1.3 ciphersuites: on tested Samsung and Xioami phones,
ChaCha20-Poly1305 is both faster and consumes less battery than AES in
GCM mode - and it's not a small difference, either.

This will not necessarily generalise to PCs with modern Intel CPUs in
them, which can have dedicated hardware instructions for AES.  But on
phones, tablets, RaspberryPi's etc. it is very likely the case that
prefering ChaCha20-Poly1305 over AES will make Gemini faster and
greener.

TLS allows both the server and client to express a preference for
ciphersuites, and IIRC it's up to the server to decide whether its
preferences or the client's have the final say.  It seems to me that
servers running on VPSes, or otherwise in scenarios where they have
reliable and abundant power, ought to defer to the client's preferences
(at least by default), that mobile clients ought to explicitly prefer
ChaCha20-Poly1305 over AES, and that non-mobile clients ought to allow
users to configure this preference for themselves.  People using RPis,
older PCs without hardware AES support, etc. can then configure a
ChaCha20-Poly1305 preference and things will be faster for them.  Maybe
not noticably faster to the naked eye, but faster.

Cheers,
Solderpunk

From luke at marmaladefoo.com  Fri Jun 26 14:47:27 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 26 Jun 2020 14:47:27 +0100
Subject: [ANN] GemiNaut 0.8.5 released
In-Reply-To: <_GSjGfn3ZumFJdHiLiY6LXU3TUKJBf-LlTRy32-O90BP80AUhf7rdcdhBYBmXCVG4Z1A0KhEl5gB128qMCOb02zTd-AHY1Llq1mcDkxRnSo=@protonmail.com>
References: <5EEF618E.80807@marmaladefoo.com>
 <159274737669.2727245.13178353740623233928@localhost.localdomain>
 <5EEF7A5A.1050602@marmaladefoo.com>
 <suaqCRaXR9KKgzJZFY-deMrmyynQrdP9_UzX5WxdXoSNJbdHClB4BO_9X3rO0sB2MrYkeRZmyJVRXh7R3wB8js7HOU2ATqIKThxBa-wBvZg=@protonmail.com>
 <_GSjGfn3ZumFJdHiLiY6LXU3TUKJBf-LlTRy32-O90BP80AUhf7rdcdhBYBmXCVG4Z1A0KhEl5gB128qMCOb02zTd-AHY1Llq1mcDkxRnSo=@protonmail.com>
Message-ID: <5EF5FC6F.905@marmaladefoo.com>

On 26-Jun-2020 10:19, defdefred wrote:
> Geminaut is crashing when I put a wrong url...
> "toto" for example.

Huh - try not to do that for now :)

It will deal with all schemes (handing off to the system if the scheme 
is not rendered internally), but if the text is not even a URI, yes it 
is unhappy.

I've fixed this in the next release.

Many thanks

  - Luke



From solderpunk at SDF.ORG  Fri Jun 26 14:56:33 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 26 Jun 2020 13:56:33 +0000
Subject: TLS certificate sizes in Geminispace
Message-ID: <20200626135633.GD4156@SDF.ORG>

There are several contributing factors to TLS overhead.  Some of it is
network based, to do with actually downloading the certificate, and
doing the handshake.  Some of it is computation based, to do with the
key exchange calculations.  Which is the more important bottleneck will
differe between applications.  In cases where network overhead is more
important, getting down the size of the certificate may help.

My AV-98 TOFU database has 103 certificates stored in it.  The mean size
is 1247 bytes - about as large, IIRC, as the average text/gemini
document.  95% of certificates range in size between 704 bytes and 1634
bytes.

However, the smallest certificate I have encountered belongs to
cozylabs.eu.  It is 273 bytes, i.e. 20% of the average!  Or, about 1 KiB
smaller than average.  That's 1KiB less network traffic for each
request to that server compare to a typical server.

cozylabs.eu achieves this feat with a single self-signed ED25519
certificate.  For folks who want to ditch the CA system and embrace
TOFU, this is clearly the way to do it.  I will migrate
gemini.circumlunar.space to this style of certificate in the near
future.

Unfortunately making this kind of cert with the `openssl` tool is not
as straightforward as other options.  The standard library for Go seems
up to the task.  I will write a small and simple bulletproof program to
generate these certs next week, and document it well.  It will be handy
not only for server admins but people who want to generate their own
client certs for use with clients like Alphonse.  Stay tund...

Cheers,
Solderpunk

From petite.abeille at gmail.com  Fri Jun 26 15:07:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 26 Jun 2020 16:07:28 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626135633.GD4156@SDF.ORG>
References: <20200626135633.GD4156@SDF.ORG>
Message-ID: <36ADA57A-D34F-4869-A3E7-CEA409DA9F52@gmail.com>



> On Jun 26, 2020, at 15:56, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> Unfortunately making this kind of cert with the `openssl` tool is not
> as straightforward as other options.

Does anyone have a reasonable recipe for openssl?

Stumbled upon this:

Create ED25519 certificates for TLS with OpenSSL
https://blog.pinterjann.is/ed25519-certificates.html

Is that a reasonable approach? Or?

>  The standard library for Go seems
> up to the task.  I will write a small and simple bulletproof program to
> generate these certs next week, and document it well.  It will be handy
> not only for server admins but people who want to generate their own
> client certs for use with clients like Alphonse.  Stay tund...
> 

Looking forward to it.

From jmcbray at carcosa.net  Fri Jun 26 15:30:44 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 26 Jun 2020 10:30:44 -0400
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626135633.GD4156@SDF.ORG> (solderpunk@sdf.org's message of
 "Fri, 26 Jun 2020 13:56:33 +0000")
References: <20200626135633.GD4156@SDF.ORG>
Message-ID: <878sg9dhm3.fsf@dorothy.carcosa.net>

solderpunk <solderpunk at SDF.ORG> writes:

> cozylabs.eu achieves this feat with a single self-signed ED25519
> certificate. For folks who want to ditch the CA system and embrace
> TOFU, this is clearly the way to do it. I will migrate
> gemini.circumlunar.space to this style of certificate in the near
> future.

I would like to do this for my server, but I'm concerned about changing
the certificate when there are people actually using TOFU. Do we have a
best practice note on changing certificates?

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From acdw at acdw.net  Fri Jun 26 16:03:47 2020
From: acdw at acdw.net (Case Duckworth)
Date: Fri, 26 Jun 2020 15:03:47 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626135633.GD4156@SDF.ORG>
References: <20200626135633.GD4156@SDF.ORG>
Message-ID: <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>

On Fri, Jun 26, 2020, at 1:56 PM, solderpunk wrote:
> cozylabs.eu achieves this feat with a single self-signed ED25519
> certificate.  For folks who want to ditch the CA system and embrace
> TOFU, this is clearly the way to do it.  I will migrate
> gemini.circumlunar.space to this style of certificate in the near
> future.
> 
> Unfortunately making this kind of cert with the `openssl` tool is not
> as straightforward as other options.  The standard library for Go seems
> up to the task.  I will write a small and simple bulletproof program to
> generate these certs next week, and document it well.  It will be handy
> not only for server admins but people who want to generate their own
> client certs for use with clients like Alphonse.  Stay tund...

Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)".

This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.

~ Case (acdw)

From felix at masterq32.de  Fri Jun 26 16:05:22 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Fri, 26 Jun 2020 17:05:22 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
Message-ID: <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de>


> Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)".
> 
> This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.
Using Kristall works and it's blazingly fast, seems to be a correct
server configuration

Regards
- xq

From acdw at acdw.net  Fri Jun 26 16:14:44 2020
From: acdw at acdw.net (Case Duckworth)
Date: Fri, 26 Jun 2020 15:14:44 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de>
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
 <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de>
Message-ID: <6acf4490-f151-4132-8cc8-f76e9a2b0eb0@www.fastmail.com>

On Fri, Jun 26, 2020, at 3:05 PM, Felix Quei?ner wrote:
> 
> > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)".
> > 
> > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.
> Using Kristall works and it's blazingly fast, seems to be a correct
> server configuration
> 
> Regards
> - xq

Hm, must be an issue with my network (I'm at work) then -- sorry for clogging up the ML! I'll try again at home tonight.

~ acdw

From jmcbray at carcosa.net  Fri Jun 26 16:15:39 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 26 Jun 2020 11:15:39 -0400
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de> ("Felix
 =?utf-8?Q?Quei=C3=9Fner=22's?= message of "Fri, 26 Jun 2020 17:05:22
 +0200")
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
 <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de>
Message-ID: <874kqxdfj8.fsf@dorothy.carcosa.net>

Felix Quei?ner <felix at masterq32.de> writes:

>> Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool,
>> or actually any gemini browser, including AV-98: the error there is "ERROR:
>> [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key
>> parameters (_ssl.c:1108)".
>> 
>> This makes me think it's an error with the server, as opposed to the ED22519
>> key; I'd love to try another server with this type of certificate for testing.

> Using Kristall works and it's blazingly fast, seems to be a correct
> server configuration

Works fine in elpher, too. It actually works for me in AV-98 and openssl
s_client, though, so this may be dependent on OpenSSL version? I have
openssl-1.1.1g installed, but I understand there are lots of systems out
there still on 1.0.x.

(Note: this is a big reason why it's hard to do the "limit to TLS 1.3 or
1.2 with good cyphers: the wide use of ancient OpenSSL versions. It's
also why Germinal doesn't actually forbid TLS 1.1 connections: the
method for doing so has changed between OpenSSL 1.0 and 1.1, and the
library I'm using doesn't support the 1.1 method.)

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jzs at sketchground.dk  Fri Jun 26 16:40:04 2020
From: jzs at sketchground.dk (jzs)
Date: Fri, 26 Jun 2020 15:40:04 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626135633.GD4156@SDF.ORG>
References: <20200626135633.GD4156@SDF.ORG>
Message-ID: <S8ywRdsrBKOQ-Nnc5IP9TouFEBfrwA9VcN9O4NAS_pBBzPbgOOfTngZQsP9d_uAdIB6qIYnRrReU7x4ssLSTZ7Vogo1k0Fmnp6JORAN5tMQ=@sketchground.dk>

Hi there,

I am the author of cozylabs.eu.

> However, the smallest certificate I have encountered belongs to
> cozylabs.eu. It is 273 bytes, i.e. 20% of the average! Or, about 1 KiB
> smaller than average. That's 1KiB less network traffic for each
> request to that server compare to a typical server.
>
> cozylabs.eu achieves this feat with a single self-signed ED25519
> certificate. For folks who want to ditch the CA system and embrace
> TOFU, this is clearly the way to do it. I will migrate
> gemini.circumlunar.space to this style of certificate in the near
> future.
>
> Cheers,
> Solderpunk


The code that i use to generate my certificate is as follows:
https://git.sr.ht/~jzs/cozylabs.eu-gemini/tree/master/server.go#L263

It might serve as an inspiration to making a generic standalone certificate
generator for those interested.

Kind regards,
Jens.

From paper at tilde.institute  Fri Jun 26 16:46:28 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Fri, 26 Jun 2020 11:46:28 -0400
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
Message-ID: <20200626154628.smb6dgvgmxsro44k@tilde.institute>

On Fri, Jun 26, 2020 at 03:03:47PM +0000, Case Duckworth wrote:
> Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)".
> 
> This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.

I suspect the issue is old openssl version, which version are you using?
I am using the lastest libressl and I have the same problem. OpenSSL
only recently added support for ed25519, so libressl might not have it
yet.

Paper

From defdefred at protonmail.com  Fri Jun 26 16:54:30 2020
From: defdefred at protonmail.com (defdefred)
Date: Fri, 26 Jun 2020 15:54:30 +0000
Subject: Real world data on TLS power consumption on mobile devices
In-Reply-To: <20200626133309.GC4156@SDF.ORG>
References: <20200626133309.GC4156@SDF.ORG>
Message-ID: <z65ERID-qmdHixyNcemUbderP04Yexqle6Q66hkKAMmdSeqKgMyH3q4FiFvc5p2JYDBVSyjFiPNrkqGwxrGCsd8DifGUQ9suF8j9zEKSx5E=@protonmail.com>

On Friday 26 June 2020 15:33, solderpunk <solderpunk at SDF.ORG> wrote:
> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6806263/

Thanks!

All modern smartphone have AES in hardware.
>From the article: "The Xiaomi device, having an ARMv8-a architecture, has support for AES hardware acceleration. "

Yesterday AES-128 was sufficient.
Today AES-256 make states happy.
Tomorrow we will have to use AES-384 or its successor.
This is endless.
Maybe one day a quantum-like way will definitely fix this.

Maybe to solution to avoid latency for each request is to make first a encrypted tunnel to the gemini server and then use this tunnel to perform each single request?

Like surfing using sftp:// :-)

freD.


From me at ur.gs  Fri Jun 26 16:55:05 2020
From: me at ur.gs (Nick Thomas)
Date: Fri, 26 Jun 2020 16:55:05 +0100
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626135633.GD4156@SDF.ORG>
References: <20200626135633.GD4156@SDF.ORG>
Message-ID: <93f860ac6fe676ec6f9d3309269133e9f74cc090.camel@ur.gs>

Hey,

> I will write a small and simple bulletproof program
> to
> generate these certs next week, and document it well.  It will be
> handy
> not only for server admins but people who want to generate their own
> client certs for use with clients like Alphonse.  Stay tund...
> 
> Cheers,
> Solderpunk

Just a heads-up that go has a few of these already, including IP SANs.
The one I usually use - and I can't find a link to it offhand - is by
one Jason Woods. They're all derived from this in the stdlib though:

https://github.com/golang/go/blob/master/src/crypto/tls/generate_cert.go

/Nick


From petite.abeille at gmail.com  Fri Jun 26 17:12:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 26 Jun 2020 18:12:39 +0200
Subject: Real world data on TLS power consumption on mobile devices
In-Reply-To: <z65ERID-qmdHixyNcemUbderP04Yexqle6Q66hkKAMmdSeqKgMyH3q4FiFvc5p2JYDBVSyjFiPNrkqGwxrGCsd8DifGUQ9suF8j9zEKSx5E=@protonmail.com>
References: <20200626133309.GC4156@SDF.ORG>
 <z65ERID-qmdHixyNcemUbderP04Yexqle6Q66hkKAMmdSeqKgMyH3q4FiFvc5p2JYDBVSyjFiPNrkqGwxrGCsd8DifGUQ9suF8j9zEKSx5E=@protonmail.com>
Message-ID: <0481A71B-13CF-46CF-8C32-AEBA6E4A7EAA@gmail.com>



> On Jun 26, 2020, at 17:54, defdefred <defdefred at protonmail.com> wrote:
> 
> Maybe to solution to avoid latency for each request is to make first a encrypted tunnel to the gemini server and then use this tunnel to perform each single request?

Or have gemini support persistent connections, as the Gemini streaming talks are suggesting.

In regards to mandating TLS, there was talk to move the TLS requirement into a separate Gemini TLS profile instead, allowing for a Gemini 'plain' profile, which could run over wireguard or such [1][2].

[1] https://lists.orbitalfox.eu/archives/gemini/2020/001267.html
[2] https://tailscale.com/blog/remembering-the-lan/

From petite.abeille at gmail.com  Fri Jun 26 17:17:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 26 Jun 2020 18:17:58 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <93f860ac6fe676ec6f9d3309269133e9f74cc090.camel@ur.gs>
References: <20200626135633.GD4156@SDF.ORG>
 <93f860ac6fe676ec6f9d3309269133e9f74cc090.camel@ur.gs>
Message-ID: <4553A418-2AB4-41FC-8F02-01D99D8C95F0@gmail.com>



> On Jun 26, 2020, at 17:55, Nick Thomas <me at ur.gs> wrote:
> 
> Just a heads-up that go has a few of these already, including IP SANs.
> The one I usually use - and I can't find a link to it offhand - is by
> one Jason Woods. They're all derived from this in the stdlib though:
> 
> https://github.com/golang/go/blob/master/src/crypto/tls/generate_cert.go

That Jason Woods (driskell)?

https://github.com/driskell/log-courier/blob/master/lc-tlscert/lc-tlscert.go

From gemini at ur.gs  Fri Jun 26 17:22:33 2020
From: gemini at ur.gs (Nick Thomas)
Date: Fri, 26 Jun 2020 17:22:33 +0100
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <4553A418-2AB4-41FC-8F02-01D99D8C95F0@gmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <93f860ac6fe676ec6f9d3309269133e9f74cc090.camel@ur.gs>
 <4553A418-2AB4-41FC-8F02-01D99D8C95F0@gmail.com>
Message-ID: <a8ac0105396978b67f1f040f900b3cc76783708a.camel@ur.gs>


> That Jason Woods (driskell)?
> 
> https://github.com/driskell/log-courier/blob/master/lc-tlscert/lc-tlscert.go

The very same!


From petite.abeille at gmail.com  Fri Jun 26 17:44:46 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 26 Jun 2020 18:44:46 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <a8ac0105396978b67f1f040f900b3cc76783708a.camel@ur.gs>
References: <20200626135633.GD4156@SDF.ORG>
 <93f860ac6fe676ec6f9d3309269133e9f74cc090.camel@ur.gs>
 <4553A418-2AB4-41FC-8F02-01D99D8C95F0@gmail.com>
 <a8ac0105396978b67f1f040f900b3cc76783708a.camel@ur.gs>
Message-ID: <AEE71A39-1170-4A26-BCBA-2350B989AD58@gmail.com>



> On Jun 26, 2020, at 18:22, Nick Thomas <gemini at ur.gs> wrote:
> 
>> That Jason Woods (driskell)?
>> 
>> https://github.com/driskell/log-courier/blob/master/lc-tlscert/lc-tlscert.go
> 
> The very same!

Cool. It''s even documented:

https://github.com/driskell/log-courier/blob/master/docs/SSLCertificateUtility.md


From petite.abeille at gmail.com  Fri Jun 26 17:58:33 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 26 Jun 2020 18:58:33 +0200
Subject: Mercury
In-Reply-To: <20200626110424.GA4156@SDF.ORG>
References: <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de> <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
 <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>
 <20200626110424.GA4156@SDF.ORG>
Message-ID: <9FDDF58C-5FC1-4011-957E-86B2F5A3D2C2@gmail.com>



> On Jun 26, 2020, at 13:04, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> I want it to be a viable lifeboat for evacuees from the web

This sum it up nicely. Perhaps worthwhile adding this to Gemini's FAQ or similar.


From philanc at gmail.com  Fri Jun 26 18:13:59 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Fri, 26 Jun 2020 17:13:59 +0000
Subject: Mercury
In-Reply-To: <20200626110424.GA4156@SDF.ORG>
References: <87pn9pg45a.fsf@jb55.com>
 <2c320228-c23c-84e3-3e99-093035ba8345@masterq32.de>
 <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
 <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>
 <20200626110424.GA4156@SDF.ORG>
Message-ID: <CAOH6EB8Hjndv8KsSajfv8-yS=AZ_M8G4-X_d0J3DRYGG0f0Pcw@mail.gmail.com>

On Fri, Jun 26, 2020 at 11:04 AM solderpunk <solderpunk at sdf.org> wrote:
> [...]
> Ultimately, Gemini is supposed to be a practical protocol to solve a
> concrete, real-world problem: [...]   I don't want Gemini to be a
> beautiful object of appreciation for hackers that most people have no
> use for (there's no shortage of these!), I want it to be a viable
> lifeboat for evacuees from the web.  The first-class application is
> computer literate non-developers using "normal computers" and software
> other people wrote to read meaningful textual content with a reasonable
> expectation of privacy.

I think this is the best summary of the overall project direction. I
quoted just a bit but maybe the whole paragraph could find its way in
the Gemini FAQ or in a Gemini "vision" document. I _did_ read as much
as I could before posting but didn't see this orientation as clearly
stated.elsewhere.

> I am happy to make it simpler, more beautiful,
> more hackable, more general purpose, friendlier to low power computers
> and slow networks, to whatever extent is possible without interfering
> with its seaworthiness as a lifeboat. [...]
> But throwing out TLS so that it can be more readily implemented by
> somebody who just learned what a socket is yesterday is ultimately
> self-defeating from the lifeboat perspective.

Please note that my initial post was just a question: "Is this Mercury
concept still alive and are members of the community interested in
it?"

I _did not_ suggest to "throw out TLS" and made it clear in the
following discussion that my "gripe" (if I may say!) was not with TLS
but with _mandatory_ TLS.

I just happen to think that the initial http/https was not such a bad
thing, contrary to the orthodox view in the HTTPS/Web world of today
-- I won't explain why I think that because I don't want to pour more
oil on the fire :-)

> The mandatory encryption in Gemini is an
> important, functional, deliberate part of the lifeboat design.  It would
> be a bad lifeboat without out.

Good. It clarifies things. Maybe this (and other parts of your answer)
could be prepended to the Mercury document as a caveat / "note to the
reader"
>
> When we *do* chase improvements in these other regards without
> compromising our role as a lifeboat, we also need to keep a sense of
> perspective, make our criteria clear, make measurements and not trust
> our guts, etc.  I'm all for a lower power, greener internet.  But if you
> really want to push in that direction hard, you need to make radical
> departures from the basic paradigms that the web and Gemini are both
> built around.
> [...]Gemini is
> never going to be the absolute best choice for low power consumption,
> for low bandwidth, etc.  That's not so say we shouldn't give those
> things any thought, but we needn't bend over backward for 1% or 2%
> savings because it just doesn't make sense.  We should concern ourselves
> with the "low hanging fruit" of these problems.

Maybe the whole discussion got side-tracked by my SUV analogy.  It was
mostly intended as a joke.
I then made the mistake of answering too seriously to your "please
disambiguate" question. I am sorry for that.

BTW I loved your "vegans carrying loads of USB keys on their bikes".
Good one! :-)
>
> Be aware that "Mercury", as I sketched it, was a "conceptual
> navigational aid" for me to try to grapple with the question of whether
> or not Gemini was becoming "too complex" (and one that most people - not
> all, but most - had a very negative reaction to).

I didn't know that. I guess this is why I asked on the mailing list. I
do understand now that it is a touchy subject. I am sorry for the
noise.

> I think that's all I have to say on this matter.

Heard you loud and clear ;-)

Phil

From petite.abeille at gmail.com  Fri Jun 26 18:23:21 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 26 Jun 2020 19:23:21 +0200
Subject: multiaddr (was Re: CGI, SCGI and Certificates (was Re: [ANN] Gemini
 browser for iOS))
In-Reply-To: <20200611233951.GA41155@MacBook-Pro.local>
References: <CAFTy05aD=v0eTvQnMf8+HV4YU5-cd9KH8D=EoeSS9MaaQyo57g@mail.gmail.com>
 <20200610020854.GC23998@brevard.conman.org>
 <CAFTy05bkVWY3ujKO8GppgzVg2FEPFVXwZYejgzp_+XaLffHsqQ@mail.gmail.com>
 <20200610204957.GN10136@SDF.ORG> <20200610215038.GF23998@brevard.conman.org>
 <20200610220226.GV10136@SDF.ORG>
 <CAFTy05ajTy1J=YGOjPKSPb8yaT+WXJVg617DQahFanHxmV7dSg@mail.gmail.com>
 <20200611173703.GC29628@SDF.ORG>
 <CAFTy05avH-wCrseWbk2VQQEFqVBgUkM4TzQbjmFw7UG7LyNkug@mail.gmail.com>
 <20200611195018.GB26289@SDF.ORG> <20200611233951.GA41155@MacBook-Pro.local>
Message-ID: <5612C40C-808B-4D96-97CB-1DFBE219EDDA@gmail.com>



> On Jun 12, 2020, at 01:39, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:
> 
> https://multiformats.io/multihash/

Which also sport multiaddr:

https://multiformats.io/multiaddr/

How would one describe a gemini address?

For example, given gemini://mozz.us/beer/, would the following be appropriate?

/dns4/mozz.us/tcp/1965/tls/gemini/beer/
/ip4/174.138.124.169/tcp/1965/tls/gemini/beer/

Based on:
https://github.com/multiformats/multiaddr/issues/63





From hello at matthewgraybosch.com  Fri Jun 26 18:52:25 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 26 Jun 2020 13:52:25 -0400
Subject: [ANN] deedum browser update
In-Reply-To: <d5c7b261-8328-471d-aaf8-79848e94af23@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <20200624112607.c5e2314bf5c28340ba7f8a34@matthewgraybosch.com>
 <CAObwWNgJtb_V2EFDq8EGRp1CNYDGEyVO=1zVdN64Y=3XY7kC7Q@mail.gmail.com>
 <d5c7b261-8328-471d-aaf8-79848e94af23@case.codes>
Message-ID: <20200626175225.GB2520@kether>

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

From colecmac at protonmail.com  Fri Jun 26 19:10:24 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 26 Jun 2020 18:10:24 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <878sg9dhm3.fsf@dorothy.carcosa.net>
References: <20200626135633.GD4156@SDF.ORG>
 <878sg9dhm3.fsf@dorothy.carcosa.net>
Message-ID: <9Vb6C6d29qxyexIOSEJnRrE3winoyOBq3GTJeDmeMeOHCGwKfXjsS5tFnoWMAMhKuxTdUVCUen3pgNEzw0FsPCZN2-LqdhmYZ_iMiNm-Zms=@protonmail.com>

On Friday, June 26, 2020 10:30 AM, Jason McBrayer <jmcbray at carcosa.net> wrote:

> I would like to do this for my server, but I'm concerned about changing
> the certificate when there are people actually using TOFU. Do we have a
> best practice note on changing certificates?

Solderpunk and I were discussing ideas in the "Thoughts on TOFU" thread.
For now, I would suggest just changing it, and clients may complain, but
eventually they will switch over. I'd be happy to hear Solderpunk's opinion
on this though.

makeworld

From sean at conman.org  Fri Jun 26 19:50:53 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 26 Jun 2020 14:50:53 -0400
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <6acf4490-f151-4132-8cc8-f76e9a2b0eb0@www.fastmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
 <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de>
 <6acf4490-f151-4132-8cc8-f76e9a2b0eb0@www.fastmail.com>
Message-ID: <20200626185053.GI19717@brevard.conman.org>

It was thus said that the Great Case Duckworth once stated:
> On Fri, Jun 26, 2020, at 3:05 PM, Felix Quei?ner wrote:
> > 
> > > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)".
> > > 
> > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.
> > Using Kristall works and it's blazingly fast, seems to be a correct
> > server configuration
> > 
> > Regards
> > - xq
> 
> Hm, must be an issue with my network (I'm at work) then -- sorry for clogging up the ML! I'll try again at home tonight.

  No, I get an error with my own too simple Gemini client:

ios:write() = handshake failed: error:06FFF09C:digital envelope routines:CRYPTO_internal:unsupported algorithm

  It looks to be an issue of the TLS library not supporting the crypto
algorithm (in my case, a few months old version of LibreSSL).

  -spc


From acdw at acdw.net  Fri Jun 26 20:29:50 2020
From: acdw at acdw.net (Case Duckworth)
Date: Fri, 26 Jun 2020 19:29:50 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626185053.GI19717@brevard.conman.org>
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
 <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de>
 <6acf4490-f151-4132-8cc8-f76e9a2b0eb0@www.fastmail.com>
 <20200626185053.GI19717@brevard.conman.org>
Message-ID: <8e055481-0e2d-496c-8913-c4d02d58492b@www.fastmail.com>

That might be my problem as well -- looks like I'm a few dot-versions behind. Which I must admit is a little concerning if this becomes the de facto cert crypto method -- even worse than the TLS 1.2/1.3 divide.

~ acdw

On Fri, Jun 26, 2020, at 6:50 PM, Sean Conner wrote:
> It was thus said that the Great Case Duckworth once stated:
> > On Fri, Jun 26, 2020, at 3:05 PM, Felix Quei?ner wrote:
> > > 
> > > > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)".
> > > > 
> > > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.
> > > Using Kristall works and it's blazingly fast, seems to be a correct
> > > server configuration
> > > 
> > > Regards
> > > - xq
> > 
> > Hm, must be an issue with my network (I'm at work) then -- sorry for clogging up the ML! I'll try again at home tonight.
> 
>   No, I get an error with my own too simple Gemini client:
> 
> ios:write() = handshake failed: error:06FFF09C:digital envelope 
> routines:CRYPTO_internal:unsupported algorithm
> 
>   It looks to be an issue of the TLS library not supporting the crypto
> algorithm (in my case, a few months old version of LibreSSL).
> 
>   -spc
> 
>

From jzs at sketchground.dk  Fri Jun 26 20:33:45 2020
From: jzs at sketchground.dk (jzs)
Date: Fri, 26 Jun 2020 19:33:45 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <8e055481-0e2d-496c-8913-c4d02d58492b@www.fastmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
 <94ad6d48-7adb-0bd5-114e-309e585359aa@masterq32.de>
 <6acf4490-f151-4132-8cc8-f76e9a2b0eb0@www.fastmail.com>
 <20200626185053.GI19717@brevard.conman.org>
 <8e055481-0e2d-496c-8913-c4d02d58492b@www.fastmail.com>
Message-ID: <EBo1Mx703FquMTMfJ334QhWWwKO7r-Mm61iXOzkd6lXLa52loTeI7sDMcIRSLvBLuMiHHHO645bc0MT2oEmSe4cBLcVBGj3XHn_qT1AAREE=@sketchground.dk>

In all fairness, i don't think Many people are using ed25519. Maybe solderpunk has some stats on that :)

Anyways, if i'm the only one creating problems, i could change back to a std rsa cert.

/Jens.

??????? Original Message ???????
On Friday, June 26, 2020 9:29 PM, Case Duckworth <acdw at acdw.net> wrote:

> That might be my problem as well -- looks like I'm a few dot-versions behind. Which I must admit is a little concerning if this becomes the de facto cert crypto method -- even worse than the TLS 1.2/1.3 divide.
>
> ~ acdw
>

From solderpunk at SDF.ORG  Fri Jun 26 21:21:41 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 26 Jun 2020 20:21:41 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <93f860ac6fe676ec6f9d3309269133e9f74cc090.camel@ur.gs>
References: <20200626135633.GD4156@SDF.ORG>
 <93f860ac6fe676ec6f9d3309269133e9f74cc090.camel@ur.gs>
Message-ID: <20200626202141.GC24983@SDF.ORG>

On Fri, Jun 26, 2020 at 04:55:05PM +0100, Nick Thomas wrote:
 
> Just a heads-up that go has a few of these already, including IP SANs.
> The one I usually use - and I can't find a link to it offhand - is by
> one Jason Woods. They're all derived from this in the stdlib though:
> 
> https://github.com/golang/go/blob/master/src/crypto/tls/generate_cert.go
> 

Thanks a lot for this heads up!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Fri Jun 26 21:59:42 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 26 Jun 2020 20:59:42 +0000
Subject: Mercury
In-Reply-To: <CAOH6EB8Hjndv8KsSajfv8-yS=AZ_M8G4-X_d0J3DRYGG0f0Pcw@mail.gmail.com>
References: <87mu4tg3iw.fsf@jb55.com>
 <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <87imfhfp9b.fsf@jb55.com>
 <CAOH6EB-gtO3x0WSdFE4NzcOQuWsxb-iZqcdsEo_GO=x1_ZkuAA@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <CAOH6EB_xMM2z89PK-H5p9sBVLWbJj3twPYQ3qn0F7pkQemY5WQ@mail.gmail.com>
 <20200625160444.GG16671@SDF.ORG>
 <CAOH6EB8DGcvqBfSw-cCdPQ9Q_=ZbHp4FprkctinAnxACikeudA@mail.gmail.com>
 <20200626110424.GA4156@SDF.ORG>
 <CAOH6EB8Hjndv8KsSajfv8-yS=AZ_M8G4-X_d0J3DRYGG0f0Pcw@mail.gmail.com>
Message-ID: <20200626205942.GD24983@SDF.ORG>

On Fri, Jun 26, 2020 at 05:13:59PM +0000, Phil Leblanc wrote:
 
> I think this is the best summary of the overall project direction. I
> quoted just a bit but maybe the whole paragraph could find its way in
> the Gemini FAQ or in a Gemini "vision" document. I _did_ read as much
> as I could before posting but didn't see this orientation as clearly
> stated.elsewhere.

I've never stated it that way before. :)  My own understanding of these
things clarifies over time in response to other people's ideas about the
direction things should take.  For which I am grateful!

> Please note that my initial post was just a question: "Is this Mercury
> concept still alive and are members of the community interested in
> it?"
> 
> I _did not_ suggest to "throw out TLS" and made it clear in the
> following discussion that my "gripe" (if I may say!) was not with TLS
> but with _mandatory_ TLS.

Duly noted!  I guess my reply was, implicitly, addressed at various
folks who expressed disapproval of the TLS idea at various times.
 
> Maybe the whole discussion got side-tracked by my SUV analogy.  It was
> mostly intended as a joke.
> I then made the mistake of answering too seriously to your "please
> disambiguate" question. I am sorry for that.

No need!
 
> BTW I loved your "vegans carrying loads of USB keys on their bikes".
> Good one! :-)

I'm not even sure I was joking!  If we genuinely want to minimise
"Environmental Damage Units" per byte transferred per metre per second,
where EDU is a vague all-encompassing measure which incorporates CO2
emissions, consumption of non-renewable resources, etc., I don't doubt
that there are certain combinations of payload size and distance where
"bikenet" is actually quite competitive, especially if you replace the
USB keys with 1TB hard drives.  A plant-based diet would undeniably
help decrease the EDU total, but it may not even be necessary to
outcompete higher tech solutions.  It gets even better if you consider
that the bike is a general-purpose tool which could also transport food,
medicine, etc. at the same time...

> I didn't know that. I guess this is why I asked on the mailing list. I
> do understand now that it is a touchy subject. I am sorry for the
> noise.

No need to apologise, really!

Cheers,
Solderpunk

From linde.philip at gmail.com  Fri Jun 26 22:32:08 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 26 Jun 2020 23:32:08 +0200
Subject: New Dillo plugin
Message-ID: <20200626233208.ad2ac3e362c3c1b44b9f295c@gmail.com>

Hi all,

I tried the existing Dillo plugin but couldn't get it to work.
Perhaps it got the job done at some iteration of the protocol.
I've written my own according to the current spec for anyone
interested:

https://github.com/boomlinde/gemini.filter.dpi

I've decided that in my client you explicitly have to pin invalid
certificates and certificates with unknown authorities. On the first
request to a site with a self-signed or invalid certificate, an error
description will be displayed and you'll be given the option to pin it
and continue anyway. After the certificate is pinned, you won't get a
warning again until it changes.

The certificate pins are stored in $HOME/.dillo/gemini/pinned as
base64 encoded sha1 sums of the entire certificate chain used.

For now it doesn't undersand client certificate status codes and will
show them as it does errors (simply outputting the header in plain
text). It will display an error on any encoding except utf-8 and
us-ascii.

Input works fine!

The project has also yielded two interesting libraries:

https://github.com/boomlinde/gemini is a protocol implementation, for
now only a client, in Go. The client library makes it easy to set up a
pin database and verifies connections by default.

https://github.com/boomlinde/dpi implements a Dillo plugin server, in
Go. It can be used to build both filter and server plugins.

Neither of these libraries are really versioned yet. I want to dog-food
the plugin for a while to weed any issues out before I will say that
the APIs are stable.

I hope someone else finds some use for this!

--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200626/a3d89eff/attachment.sig>

From sean at conman.org  Fri Jun 26 23:18:11 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 26 Jun 2020 18:18:11 -0400
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626135633.GD4156@SDF.ORG>
References: <20200626135633.GD4156@SDF.ORG>
Message-ID: <20200626221811.GJ19717@brevard.conman.org>

It was thus said that the Great solderpunk once stated:
> There are several contributing factors to TLS overhead.  

  I think some of the overhead concern is overblown.  As I said to
defdefred, people are forgetting that TCP *itself* has overhead.  More on
that below.

> Some of it is
> network based, to do with actually downloading the certificate, and
> doing the handshake.  Some of it is computation based, to do with the
> key exchange calculations.  Which is the more important bottleneck will
> differe between applications.  In cases where network overhead is more
> important, getting down the size of the certificate may help.
> 
> My AV-98 TOFU database has 103 certificates stored in it.  The mean size
> is 1247 bytes - about as large, IIRC, as the average text/gemini
> document.  95% of certificates range in size between 704 bytes and 1634
> bytes.

  How are they stored?  If they look like this:

-----BEGIN CERTIFICATE-----
MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT
MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG
A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0
...

then your figures are a bit high---the certificate is *not* transmitted as
base-64 encoded data, so unless you took that into account, your figures are
on the high side.

  And as I'm wont to do, I did a deep dive into this.  I made a request to
<gemini://gemini.conman.org/> to obtain the 2,633 byte file, and I captured
it with wireshark.  Here is the packet-by-packet replay of that exchange.

		size direction
	1	60 ->		SYN packet to server (no data)
	2	60 <-		SYN + ACK from server (still no data)
	3	52 ->		ACK from client (still no data)
	4	203 ->		initial client TLS request
	5	52 <-		ACK from server (no data)
	6	1492 <-		server certificate
	7	52 ->		ACK from client (no data)
	8	611 <-		TLS? unsure from this point on
	9	52 ->		ACK from client (no data)
	10	144 ->		data
	11	52 <-		ACK from server (no data)
	12	95 <-		data
	13	102 ->		data
	14	1492 <-		data (I'm assuming by now this is the file)
	15	1282 <-		data (probably more file)
	16	52 ->		ACK from client (no data)
	17	75 <-		getting ready to close?
	18	75 ->		getting ready to cloes?
	19	52 ->		FIN + ACK from client (no data)
	20	46 <-		FIN from server (no data)

  One implementation quirk GLV-1.12556 has is that before it serves up any
data, it ensures that the complete TLS handshake has finished---I do that to
ensure the client certificate (if any) is available but I could probably try
moving that out of the "happy no-certificate path".  Anyway ...

  Half the packets involved are simply TCP overhead, no data of any type is
sent.  The first three packets are larger than the minimum 40 bytes due to
TCP options being sent, and the largst packet size availble is 1492, due to
limititaions on Ethernet.  And just for completeness, here's a gopher
request to a file of similar size (<gopher://gopher.conman.org/>, 2,413
bytes):

		size direction
	1	60 ->		SYN packet to server (no data)
	2	60 <-		SYN + ACK from server (no data)
	3	52 ->		ACK from client (no data)
	4	54 ->		request to server
	5	52 <-		ACK from server (no data)
	6	1492 <-		data from server
	7	52 ->		ACK from client (no data)
	8	1039 <-		data from server
	9	52 ->		ACI from client (no data)
	10	52 <-		FIN from server (no data)
	11	52 ->		FIN from client (no data)
	12	52 <-		ACK from server (no data)

  Here, 75% of the packets are pure TCP overhead, but it is 60% of the
packets of the TLS request.  I'm leaving it as an exercise for the reader to
compare the actual byte counts between the two requests.  

  And as far as removing the TCP overhead, good luck with *that!*  I'd love
to see the solution ...

  -spc


From sean at conman.org  Fri Jun 26 23:32:19 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 26 Jun 2020 18:32:19 -0400
Subject: Mercury
In-Reply-To: <PZvoJu3vFVvZemrvdAT_RGU9JZ1IUn7w-6Bz-OnaDe51nVu9p_UBZ7We08oTiVtseo0kmKCSNrck9c1iOTEBh2ZzWeFjmtlFqvx-lOs_EnE=@protonmail.com>
References: <CANmFPek_6r-RErq=bcUESJQ8epwY8Gtg8rfYszwViAQAxb0fkg@mail.gmail.com>
 <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <Wubnvbgwb0zuUrqfAIrkPMDTtT6k5Uj9mnYDgH6WIVnPOTUXX2rbssJ3wfRL9Ild9QUiVENy8vopkrV5wYjI6mgmbhaUF2geVfaqD1dXVho=@protonmail.com>
 <yNIdjcVJecuK56IiKMnPt18XeI_C1Hsa2ESGFfDlFVfsqMnh7Hyg2zYmiJeMzpbi5BOGiouCrC6H_Ye8g9_E4ag66VXW3J-HL3akiKjnVlM=@protonmail.com>
 <20200625212351.qsed7bmloqw27zuc@tilde.institute>
 <PZvoJu3vFVvZemrvdAT_RGU9JZ1IUn7w-6Bz-OnaDe51nVu9p_UBZ7We08oTiVtseo0kmKCSNrck9c1iOTEBh2ZzWeFjmtlFqvx-lOs_EnE=@protonmail.com>
Message-ID: <20200626223218.GK19717@brevard.conman.org>

It was thus said that the Great defdefred once stated:
> On Thursday 25 June 2020 23:23, <paper at tilde.institute> wrote:
> > not really, VPN is only moving the problem to a different state/company,
> > then the traffic would be plain text. The solution would be a VPN to the
> > gemini server, but basicaly that's called TLS xD
> 
> True, but a VPN is created to serve multiple requests.

  Yes and no.  A VPN is *not* at all like HTTPS or Gemini.  It is *not* used
for program to program communication (the TCP layer) but computer to
computer communciation (the IP layer).  Technically, a VPN routes IP (the
packet of which are encrypted) over IP (the packets of which are regular,
unencrypted packets) and looks like a router.  Normally, traffic would go:

	[program1 -> data -> TCP -> IP -> client] (1st computer)
		-> router -> router -> ... router -> 
	[server -> IP -> TCP -> data -> program2] (2nd computer)

  A VPN does this:

	[program1 -> data -> TCP -> IP -> VPN endpoint -> client] (1st computer)
		-> router -> router ... -> router ->
	[VPN endpoint] (2nd computer)
		-> router -> router ... -> router ->
	[server -> IP -> TCP -> data -> program2] (3rd computer)

I.E., a VPN is just a fancy router.  The server never knows (nor cares)
about the VPN.

> May be wireguard to the gemini server is the way to go :-)

  Stop trying to sell it as a TLS alternative---it *ISN'T!*

  -spc

From solderpunk at SDF.ORG  Fri Jun 26 23:37:43 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 26 Jun 2020 22:37:43 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626221811.GJ19717@brevard.conman.org>
References: <20200626135633.GD4156@SDF.ORG>
 <20200626221811.GJ19717@brevard.conman.org>
Message-ID: <20200626223743.GA7071@SDF.ORG>

On Fri, Jun 26, 2020 at 06:18:11PM -0400, Sean Conner wrote:
> It was thus said that the Great solderpunk once stated:
> > There are several contributing factors to TLS overhead.  
> 
>   I think some of the overhead concern is overblown.

Oh, I completely agree.  It seems to bother a lot of people so I've been
pointing out comparatively quick and easy things we could do without
changing the spec at all to address it, because I'd much rather do that
than increase complexity or reduce security.  But my personal experience
using AV-98 is that browsing Geminispace feels plenty snappy enough as is.
Especially relative to how long the content takes to consume.

>   How are they stored?  If they look like this:
> 
> -----BEGIN CERTIFICATE-----
> MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT
> MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG
> A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0
> ...
> 
> then your figures are a bit high

They're DER encoded binary files, so no worries about that.

> 		size direction
> 	1	60 ->		SYN packet to server (no data)
> 	2	60 <-		SYN + ACK from server (still no data)
> 	3	52 ->		ACK from client (still no data)
> 	4	203 ->		initial client TLS request
> 	5	52 <-		ACK from server (no data)
> 	6	1492 <-		server certificate
> 	7	52 ->		ACK from client (no data)
> 	8	611 <-		TLS? unsure from this point on
> 	9	52 ->		ACK from client (no data)
> 	10	144 ->		data
> 	11	52 <-		ACK from server (no data)
> 	12	95 <-		data
> 	13	102 ->		data
> 	14	1492 <-		data (I'm assuming by now this is the file)
> 	15	1282 <-		data (probably more file)
> 	16	52 ->		ACK from client (no data)
> 	17	75 <-		getting ready to close?
> 	18	75 ->		getting ready to cloes?
> 	19	52 ->		FIN + ACK from client (no data)
> 	20	46 <-		FIN from server (no data)

Thanks for this, very enlightening!

Cheers,
Solderpunk

From sean at conman.org  Fri Jun 26 23:51:26 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 26 Jun 2020 18:51:26 -0400
Subject: Real world data on TLS power consumption on mobile devices
In-Reply-To: <0481A71B-13CF-46CF-8C32-AEBA6E4A7EAA@gmail.com>
References: <20200626133309.GC4156@SDF.ORG>
 <z65ERID-qmdHixyNcemUbderP04Yexqle6Q66hkKAMmdSeqKgMyH3q4FiFvc5p2JYDBVSyjFiPNrkqGwxrGCsd8DifGUQ9suF8j9zEKSx5E=@protonmail.com>
 <0481A71B-13CF-46CF-8C32-AEBA6E4A7EAA@gmail.com>
Message-ID: <20200626225126.GL19717@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> > On Jun 26, 2020, at 17:54, defdefred <defdefred at protonmail.com> wrote:
> > 
> > Maybe to solution to avoid latency for each request is to make first a
> > encrypted tunnel to the gemini server and then use this tunnel to
> > perform each single request?
> 
> Or have gemini support persistent connections, as the Gemini streaming
> talks are suggesting.
> 
> In regards to mandating TLS, there was talk to move the TLS requirement
> into a separate Gemini TLS profile instead, allowing for a Gemini 'plain'
> profile, which could run over wireguard or such [1][2].

  I think "plain" Gemini would me Mercuri (Gemini sans TLS).

  Also, using wireguard would require a client to use a library/software
program/kernel module, unlike TLS, which just requires a library.

  But hey, prove me wrong---get a working Gemini server and client using
wiregard and tell us how easy it is.

> [1] https://lists.orbitalfox.eu/archives/gemini/2020/001267.html
> [2] https://tailscale.com/blog/remembering-the-lan/

  -spc


From cel at celehner.com  Sat Jun 27 00:47:50 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Fri, 26 Jun 2020 19:47:50 -0400
Subject: New Dillo plugin
In-Reply-To: <20200626233208.ad2ac3e362c3c1b44b9f295c@gmail.com>
References: <20200626233208.ad2ac3e362c3c1b44b9f295c@gmail.com>
Message-ID: <20200626194709.66fda53c@celehner.com>

Hi Philip,

Nice work. I like the certificate pinning feature.

The other plugin (dillo-gemini) works with the current protocol, except for client certificates or any server certificate management. Maybe you were missing a dependency. I added a link to yours in its readme.

Regards,
Charles L.

On Fri, 26 Jun 2020 23:32:08 +0200
Philip Linde <linde.philip at gmail.com> wrote:

> Hi all,
> 
> I tried the existing Dillo plugin but couldn't get it to work.
> Perhaps it got the job done at some iteration of the protocol.
> I've written my own according to the current spec for anyone
> interested:
> 
> https://github.com/boomlinde/gemini.filter.dpi
> 
> I've decided that in my client you explicitly have to pin invalid
> certificates and certificates with unknown authorities. On the first
> request to a site with a self-signed or invalid certificate, an error
> description will be displayed and you'll be given the option to pin it
> and continue anyway. After the certificate is pinned, you won't get a
> warning again until it changes.
> 
> The certificate pins are stored in $HOME/.dillo/gemini/pinned as
> base64 encoded sha1 sums of the entire certificate chain used.
> 
> For now it doesn't undersand client certificate status codes and will
> show them as it does errors (simply outputting the header in plain
> text). It will display an error on any encoding except utf-8 and
> us-ascii.
> 
> Input works fine!
> 
> The project has also yielded two interesting libraries:
> 
> https://github.com/boomlinde/gemini is a protocol implementation, for
> now only a client, in Go. The client library makes it easy to set up a
> pin database and verifies connections by default.
> 
> https://github.com/boomlinde/dpi implements a Dillo plugin server, in
> Go. It can be used to build both filter and server plugins.
> 
> Neither of these libraries are really versioned yet. I want to
> dog-food the plugin for a while to weed any issues out before I will
> say that the APIs are stable.
> 
> I hope someone else finds some use for this!
> 
> --
> Philip


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200626/24f4ba06/attachment.sig>

From cage-dev at twistfold.it  Sat Jun 27 09:32:08 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 27 Jun 2020 10:32:08 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <64418812-c458-4feb-a7f5-3bc8a4ff8fc2@www.fastmail.com>
Message-ID: <20200627083208.GA2683@kurosawa.casa.net>

On Fri, Jun 26, 2020 at 03:03:47PM +0000, Case Duckworth wrote:

Hi!

> Unfortunately, I can't access cozylabs.eu using the `openssl s_client`

FWIW i was able to access this address with my client (i am using cl+ssl for TLS).

Bye!
C.

From solderpunk at SDF.ORG  Sat Jun 27 09:57:14 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 27 Jun 2020 08:57:14 +0000
Subject: Illusory latency due to trailing slash redirects
Message-ID: <20200627085714.GA7701@SDF.ORG>

I sent the following email (and many others, which will follow shortly)
to the list last night, but SDF's mailserver was acting up and they
never went through.  I thought they'd appear eventually, but it appears
not, so I'm resending them now.  Apologies if double posts eventually
appear.

----- Forwarded message from solderpunk <solderpunk at SDF.ORG> -----

Date: Fri, 26 Jun 2020 15:47:57 +0000
From: solderpunk <solderpunk at SDF.ORG>
To: gemini at lists.orbitalfox.eu
Subject: Illusory latency due to trailing slash redirects

Gemini servers (and servers for any other protocol supporting relative
URLs, including HTTP) will use redirects to get clients to add a
trailing slash to a URL which maps to a directory on the server's
filesystem.  Handling this redirect is often invisible to the client
user, with the result that what "looks and feels" like a single request
is actually two immediately consecutive requests.  This makes latency
appear to be much worse than it actually is.  Perhaps this underlies
some people's perceptions that Gemini has unacceptable latency.

This basic problem is unavoidable, but there are many small things
client and server authors can do to minimise how often it happens:

In general, the client can't add a missing trailing slash itself because
it never knows if a given URL maps to something file-like or something
directory-like.  An interesting exception is the root of the server.
Molly Brown and Jetforce (but not GLV-1.12556) both seem to redirect
gemini.example.com to gemini.example.com/, making the loading of
"homepages" feel slower than it needs to.  I'm pretty sure it should be
safe for clients to automatically append trailing slashes to URLs
without paths.

On the server side, server authors should take care when doing things
like automatically generating directory listings to put trailing slashes
in links to directories so that the redirect is not necessary.

These measures together could cut perceived latency in half for a
non-trivial proportion of Gemini requests, including the psychologically
heavily weighted request of visiting a server's homepage.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sat Jun 27 09:58:19 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 27 Jun 2020 08:58:19 +0000
Subject: TLS certificate sizes in Geminispace
Message-ID: <20200627085819.GB7701@SDF.ORG>

----- Forwarded message from solderpunk <solderpunk at SDF.ORG> -----

Date: Fri, 26 Jun 2020 15:57:59 +0000
From: solderpunk <solderpunk at SDF.ORG>
To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
Subject: Re: TLS certificate sizes in Geminispace

On Fri, Jun 26, 2020 at 05:05:22PM +0200, Felix Quei?ner wrote:
> > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.
> Using Kristall works and it's blazingly fast, seems to be a correct
> server configuration
>

Hmm, I think SDF's mail server must be having issues, I'm not seeing
other posts to this thread, even my own replies, but I can see them at
Sloum's Gemini mirror of the list.  I'll send this now in the hopes it
gets through eventually...

I think perhaps it is, indeed, the case that older versions of OpenSSL
will choke on this.  That *sucks*.  I know this is a big problem with
the web, but the web, by virtue of being mostly a commercial enterprise,
needs to support janky old clients because the people using them still
have good money.  I figured that since there *are* no janky old Gemini
clients, we would not be bitten by this kind of thing.

Okay, perhaps everybody jumping to ED22519 right now is not viable, but
it should be a medium-term goal and, in the mean time, we can figure out
what the smallest possible widely supported certificate is (without
doing silly things like using tiny key sizes), and build tools / write
docs help folks generate them.

Cheers,
Solderpunk


From solderpunk at SDF.ORG  Sat Jun 27 09:59:10 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 27 Jun 2020 08:59:10 +0000
Subject: TLS certificate sizes in Geminispace
Message-ID: <20200627085910.GC7701@SDF.ORG>

----- Forwarded message from solderpunk <solderpunk at SDF.ORG> -----

Date: Fri, 26 Jun 2020 16:44:41 +0000
From: solderpunk <solderpunk at SDF.ORG>
To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
Subject: Re: TLS certificate sizes in Geminispace

On Fri, Jun 26, 2020 at 05:05:22PM +0200, Felix Quei?ner wrote:
> Using Kristall works and it's blazingly fast, seems to be a correct
> server configuration

Initially, I could not access cozylabs.eu using Bombadillo.  Then I
upgraded my Golang version from 1.11 to 1.14 and rebuilt Bomadillo, and
now it works just fine.  I have not tested it yet, but I presume that
exactly the same would be true of Amfora.  I tried this after realising
that the crypto/ed25519 package only appeared in the Go standard library
with the 1.13 release (September last year).

I run Debian stable, famous for lagging behind the latest release of
everthing.  In this case, Debian stable was far enough behind on Go that
it meant Go-based clients wouldn't work with ED25519.  After the *next*
Debian stable release, I imagine this will not be an issue.  Already
with the current stable release, Python-based clients using Python's
OpenSSL binding work with ED25519 just fine.  My tiny little ~100 line
Lua client also works just fine, although to be fair I may have pulled
in some Lua libraries from LuaRocks which are more up to date than what
Debian ships with.

Anyway, it seems to me that we're perhaps a year or so away from a
situation where even famously slow moving and outdated distributions can
handle these certs out-of-the-box with a majority of clients , so let's
look forward to that faster future.

In the meantime, folks who like to "live on the edge" can change earlier
I will probably, contrary to my earlier claim, be a bit more
conservative with gemini.circumlunar.space, because that really ought to
be very widely acccessible.

Also in the meantime, I encourage all authors of Gemini-related software
written in Go who distribute pre-compiled binaries to compile their
binaries with the latest version of Go they can.

Cheers,
Solderpunk

From mbays at sdf.org  Sat Jun 27 10:07:51 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sat, 27 Jun 2020 11:07:51 +0200
Subject: RTT0
Message-ID: <20200627090751.GA7371@localhost>

Do any currently running servers implement RTT0, i.e. accept early data? 
It seems plenty of servers will happily resume sessions, but I haven't 
found one yet which accepts early data.

Context: I recently added session resumption and early data support to 
my client diohsc; I tried throwing together a server accepting RTT0 
using the haskell libraries, but: I'm finding that requests using RTT0 
do not obtain a new session, while the server (rightly, to avoid replay 
attacks) deletes the existing session, with the result that only one in 
two requests successfully usees RTT0. I'm not sure whether this is 
a limitation of the libraries I'm using on the server, or how I'm using 
them, or my client doing something wrong -- so having other 
implementations to test against would help!

=> gemini://gemini.thegonz.net/diohsc  client now with session resumption
=> gemini://gemini.thegonz.net/glog/200624-RREPLs.gmi  background on why I'm interested in RTT0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/54617f74/attachment.sig>

From linde.philip at gmail.com  Sat Jun 27 10:42:39 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sat, 27 Jun 2020 11:42:39 +0200
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627085714.GA7701@SDF.ORG>
References: <20200627085714.GA7701@SDF.ORG>
Message-ID: <20200627114239.0d9233f5d45a4d1f41187930@gmail.com>

> I'm pretty sure it should be safe for clients to automatically append
> trailing slashes to URLs without paths.

Indeed it should be, per rfc3986:

> In general, a URI that uses the generic syntax for authority with
> an empty path should be normalized to a path of "/".

An authority in this context is //[<user>[:<password>]@]<host>[:<port>],
so "gemini://example.horse" and "gemini://example.horse/" are
equivalent in a strictly compliant rfc3986 implementation.

A server that serves different content on //server and //server/ can be
a huge pain in the neck. When I wrote my dillo plugin I noticed that it
seems to apply this normalization in reverse before the URL is handed
to the plugin. So "gemini://example.horse/" could only be seen on the
plugin end as "gemini://example.horse", which also makes redirects to
"gemini://example.horse/" loop back to "gemini://example.horse/".
Redirect hell ensued!

That Dillo does this might be strange, but absolutely fine from a
standards perspective. It's the server that's not compliant.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/627e8733/attachment.sig>

From pwarren at pwarren.id.au  Sat Jun 27 11:37:17 2020
From: pwarren at pwarren.id.au (Paul Warren)
Date: Sat, 27 Jun 2020 20:37:17 +1000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200627085819.GB7701@SDF.ORG>
References: <20200627085819.GB7701@SDF.ORG>
Message-ID: <c616a813-2b01-65f6-6273-7ee246ab5d28@pwarren.id.au>

G'day!

I've put an ed25519 based cert on gemini://gem.pwarren.id.au/ which is
being served out by the latest gemserv.

I generated it on debian with openssl 1.1.1d via:

$ openssl genpkey -algorithm ED25519 > gemkey.pem

$ openssl req -x509 -key gemkey.pem -subj "/CN=gem.pwarren.id.au"
-reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf
"[SAN]\nsubjectAltName=DNS:gem.pwarren.id.au,DNS:gemini.pwarren.id.au,DNS:gemini.lan"))
-out gemnew.pem -days 3600

I'm not sure if SANs are required really for gemini, I think with the
TOFU idea it's only the hash that matters?

The new cert is 489 bytes vs the 1830 for the old RSA keyed certificate
(in PEM format), most of my content so far is < 2000 bytes!

Cheers
--
Paul


On 27/6/20 6:58 pm, solderpunk wrote:
> ----- Forwarded message from solderpunk <solderpunk at SDF.ORG> -----
> 
> Date: Fri, 26 Jun 2020 15:57:59 +0000
> From: solderpunk <solderpunk at SDF.ORG>
> To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
> Subject: Re: TLS certificate sizes in Geminispace
> 
> On Fri, Jun 26, 2020 at 05:05:22PM +0200, Felix Quei?ner wrote:
>>> This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing.
>> Using Kristall works and it's blazingly fast, seems to be a correct
>> server configuration
>>
> 
> Hmm, I think SDF's mail server must be having issues, I'm not seeing
> other posts to this thread, even my own replies, but I can see them at
> Sloum's Gemini mirror of the list.  I'll send this now in the hopes it
> gets through eventually...
> 
> I think perhaps it is, indeed, the case that older versions of OpenSSL
> will choke on this.  That *sucks*.  I know this is a big problem with
> the web, but the web, by virtue of being mostly a commercial enterprise,
> needs to support janky old clients because the people using them still
> have good money.  I figured that since there *are* no janky old Gemini
> clients, we would not be bitten by this kind of thing.
> 
> Okay, perhaps everybody jumping to ED22519 right now is not viable, but
> it should be a medium-term goal and, in the mean time, we can figure out
> what the smallest possible widely supported certificate is (without
> doing silly things like using tiny key sizes), and build tools / write
> docs help folks generate them.
> 
> Cheers,
> Solderpunk
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1003 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/d958682b/attachment-0001.sig>

From pwarren at pwarren.id.au  Sat Jun 27 12:05:51 2020
From: pwarren at pwarren.id.au (Paul Warren)
Date: Sat, 27 Jun 2020 21:05:51 +1000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <c616a813-2b01-65f6-6273-7ee246ab5d28@pwarren.id.au>
References: <20200627085819.GB7701@SDF.ORG>
 <c616a813-2b01-65f6-6273-7ee246ab5d28@pwarren.id.au>
Message-ID: <e02c8ae1-28c9-1342-56af-22a1604d7caa@pwarren.id.au>

On 27/6/20 8:37 pm, Paul Warren wrote:
> G'day!
> 
> I've put an ed25519 based cert on gemini://gem.pwarren.id.au/ which is
> being served out by the latest gemserv.
> 
> I generated it on debian with openssl 1.1.1d via:
> 
> $ openssl genpkey -algorithm ED25519 > gemkey.pem
> 
> $ openssl req -x509 -key gemkey.pem -subj "/CN=gem.pwarren.id.au"
> -reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf
> "[SAN]\nsubjectAltName=DNS:gem.pwarren.id.au,DNS:gemini.pwarren.id.au,DNS:gemini.lan"))
> -out gemnew.pem -days 3600
> 
> I'm not sure if SANs are required really for gemini, I think with the
> TOFU idea it's only the hash that matters?
> 
> The new cert is 489 bytes vs the 1830 for the old RSA keyed certificate
> (in PEM format), most of my content so far is < 2000 bytes!
> 
> Cheers
> --
> Paul


Uh, oh, in all this mucking about with certs, I overwrote my Astrobotany
key, which I'd not got round to backing up yet :(

Not sure what'll happen to my legendary hissing mature pachypodium now!

(Apologies for the previous top post!

--
Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1003 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/e30cd6e7/attachment.sig>

From linde.philip at gmail.com  Sat Jun 27 13:49:06 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sat, 27 Jun 2020 14:49:06 +0200
Subject: New Dillo plugin
In-Reply-To: <20200626194709.66fda53c@celehner.com>
References: <20200626233208.ad2ac3e362c3c1b44b9f295c@gmail.com>
 <20200626194709.66fda53c@celehner.com>
Message-ID: <20200627144906.06fa2db575baa59ef31ac343@gmail.com>

> Hi Philip,
> 
> Nice work. I like the certificate pinning feature.

Thanks, Charles. I think your plugin better embodies the "100-line
client" idea in at least having significantly less than a thousand lines
of code, and there is high value in that. I will link back to it as
well.

> The other plugin (dillo-gemini) works with the current protocol, except
> for client certificates or any server certificate management. Maybe you
> were missing a dependency. I added a link to yours in its readme.

I investigated a bit further and found that my client doesn't
understand the -verify_quiet flag:

 $ openssl s_client -verify_quiet -quiet "example.horse:1965"
 unknown option -verify_quiet
 # ...
 $ openssl version
 LibreSSL 3.0.2

So my openssl is actually from the LibreSSL fork. OpenBSD does this,
and (apparently) my desktop OS of choice, Void Linux. There seem to be
further differences preventing a simple fix.

I have systems running Debian with genuine OpenSSL so if I can work out
the differences and improve compatibility with LibreSSL in a clean way,
I'll send you a patch.

Have a great weekend,
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/63e5906e/attachment.sig>

From paper at tilde.institute  Sat Jun 27 18:06:04 2020
From: paper at tilde.institute (paper at tilde.institute)
Date: Sat, 27 Jun 2020 13:06:04 -0400
Subject: Mercury
In-Reply-To: <20200626223218.GK19717@brevard.conman.org>
References: <bc73297a-40a9-4deb-a444-44b53e576d15@www.fastmail.com>
 <20200624113632.5f258430ffaee561e42478d6@matthewgraybosch.com>
 <iNK1PCrwVj0rBXNL7-spLy3NAyRtyBaIn11eoUhxCc5sAXZBC8UCpmcQIiD0E27bPoZCRnZdoRxgu_OlfatgjPuwS09ycxlTGtyWaFY9Bno=@protonmail.com>
 <9ddf1275-2d45-371e-d81a-9fb80ba467db@masterq32.de>
 <20200625184228.GH16671@SDF.ORG>
 <Wubnvbgwb0zuUrqfAIrkPMDTtT6k5Uj9mnYDgH6WIVnPOTUXX2rbssJ3wfRL9Ild9QUiVENy8vopkrV5wYjI6mgmbhaUF2geVfaqD1dXVho=@protonmail.com>
 <yNIdjcVJecuK56IiKMnPt18XeI_C1Hsa2ESGFfDlFVfsqMnh7Hyg2zYmiJeMzpbi5BOGiouCrC6H_Ye8g9_E4ag66VXW3J-HL3akiKjnVlM=@protonmail.com>
 <20200625212351.qsed7bmloqw27zuc@tilde.institute>
 <PZvoJu3vFVvZemrvdAT_RGU9JZ1IUn7w-6Bz-OnaDe51nVu9p_UBZ7We08oTiVtseo0kmKCSNrck9c1iOTEBh2ZzWeFjmtlFqvx-lOs_EnE=@protonmail.com>
 <20200626223218.GK19717@brevard.conman.org>
Message-ID: <20200627170604.soyeijmntcayndiv@tilde.institute>

On Fri, Jun 26, 2020 at 06:32:19PM -0400, Sean Conner wrote:
> It was thus said that the Great defdefred once stated:
> > On Thursday 25 June 2020 23:23, <paper at tilde.institute> wrote:
> > > not really, VPN is only moving the problem to a different state/company,
> > > then the traffic would be plain text. The solution would be a VPN to the
> > > gemini server, but basicaly that's called TLS xD
> > 
> > True, but a VPN is created to serve multiple requests.
> 
>   Yes and no.  A VPN is *not* at all like HTTPS or Gemini.  It is *not* used
> for program to program communication (the TCP layer) but computer to
> computer communciation (the IP layer).  Technically, a VPN routes IP (the
> packet of which are encrypted) over IP (the packets of which are regular,
> unencrypted packets) and looks like a router.  Normally, traffic would go:
> 
> 	[program1 -> data -> TCP -> IP -> client] (1st computer)
> 		-> router -> router -> ... router -> 
> 	[server -> IP -> TCP -> data -> program2] (2nd computer)
> 
>   A VPN does this:
> 
> 	[program1 -> data -> TCP -> IP -> VPN endpoint -> client] (1st computer)
> 		-> router -> router ... -> router ->
> 	[VPN endpoint] (2nd computer)
> 		-> router -> router ... -> router ->
> 	[server -> IP -> TCP -> data -> program2] (3rd computer)
> 
> I.E., a VPN is just a fancy router.  The server never knows (nor cares)
> about the VPN.

I know that, I was joking. My point was that defdefred was trying to
invent something like TLS, so I pointed him in the right direction ;)

Paper

From colecmac at protonmail.com  Sat Jun 27 18:52:31 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 27 Jun 2020 17:52:31 +0000
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627085714.GA7701@SDF.ORG>
References: <20200627085714.GA7701@SDF.ORG>
Message-ID: <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>

> I'm pretty sure it should besafe for clients to automatically append
> trailing slashes to URLs without paths.

I've done this in Amfora, it makes typing in domains much simpler.

Currently, every redirect in Amfora must be confirmed by the user, but
I wonder if it would make sense to automatically accept redirects that
just add a slash, as a convenience thing. I would need to add some logic
that prevents a redirect hell of course.

makeworld

??????? Original Message ???????
On Saturday, June 27, 2020 4:57 AM, solderpunk <solderpunk at SDF.ORG> wrote:

> I sent the following email (and many others, which will follow shortly)
> to the list last night, but SDF's mailserver was acting up and they
> never went through. I thought they'd appear eventually, but it appears
> not, so I'm resending them now. Apologies if double posts eventually
> appear.
>
> ----- Forwarded message from solderpunk solderpunk at SDF.ORG -----
>
> Date: Fri, 26 Jun 2020 15:47:57 +0000
> From: solderpunk solderpunk at SDF.ORG
> To: gemini at lists.orbitalfox.eu
> Subject: Illusory latency due to trailing slash redirects
>
> Gemini servers (and servers for any other protocol supporting relative
> URLs, including HTTP) will use redirects to get clients to add a
> trailing slash to a URL which maps to a directory on the server's
> filesystem. Handling this redirect is often invisible to the client
> user, with the result that what "looks and feels" like a single request
> is actually two immediately consecutive requests. This makes latency
> appear to be much worse than it actually is. Perhaps this underlies
> some people's perceptions that Gemini has unacceptable latency.
>
> This basic problem is unavoidable, but there are many small things
> client and server authors can do to minimise how often it happens:
>
> In general, the client can't add a missing trailing slash itself because
> it never knows if a given URL maps to something file-like or something
> directory-like. An interesting exception is the root of the server.
> Molly Brown and Jetforce (but not GLV-1.12556) both seem to redirect
> gemini.example.com to gemini.example.com/, making the loading of
> "homepages" feel slower than it needs to. I'm pretty sure it should be
> safe for clients to automatically append trailing slashes to URLs
> without paths.
>
> On the server side, server authors should take care when doing things
> like automatically generating directory listings to put trailing slashes
> in links to directories so that the redirect is not necessary.
>
> These measures together could cut perceived latency in half for a
> non-trivial proportion of Gemini requests, including the psychologically
> heavily weighted request of visiting a server's homepage.
>
> Cheers,
> Solderpunk



From cage-dev at twistfold.it  Sat Jun 27 19:27:02 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 27 Jun 2020 20:27:02 +0200
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
References: <20200627085714.GA7701@SDF.ORG>
 <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
Message-ID: <20200627182702.GA1942@kurosawa.casa.net>

On Sat, Jun 27, 2020 at 05:52:31PM +0000, colecmac at protonmail.com wrote:

Hi!

[...]

> Currently, every redirect in Amfora must be confirmed by the user,

Funny thing  is that yhis isOA what i  also do. I  thought it was  a bad
idea, turned out it was not, actually! :)

Bye!
C.

From martin at no.ucant.org  Sat Jun 27 19:33:30 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sat, 27 Jun 2020 19:33:30 +0100 (BST)
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627182702.GA1942@kurosawa.casa.net>
References: <20200627085714.GA7701@SDF.ORG>
 <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
 <20200627182702.GA1942@kurosawa.casa.net>
Message-ID: <alpine.DEB.2.20.2006271932440.1719@pling.qwghlm.org>

On Sat, 27 Jun 2020, cage wrote:

>> Currently, every redirect in Amfora must be confirmed by the user,
>
> Funny thing  is that yhis isOA what i  also do. I  thought it was  a bad
> idea, turned out it was not, actually! :)

Incidentally, how do these clients behave if someone sets their server to 
redirect "gemini://hostname.domain.com/" to 
"gemini://hostname.domain.com", i.e., if they remove the slash?

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From b__m__e at mailfence.com  Sat Jun 27 20:01:10 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sat, 27 Jun 2020 21:01:10 +0200 (CEST)
Subject: [REQ] Element IDs in the web specification
Message-ID: <1099146806.1107636.1593284470312@ichabod.co-bxl>

I would like to link to the `text/gemini` portion of the spec for a project I am working on.
However, there are no IDs on any of the elements. This makes it impossible to link someone
directly to a section. :(

If this can get updated it would be much appreciated. I am trying to link it as additional information
for non-technical users... so linking to the full spec might be overwhelming.

I know it has been brought up before to separate text/gemini from the protocol spec, and just thought
I would float that here again...

--?
Sent with https://mailfence.com
Secure and private email

From b__m__e at mailfence.com  Sat Jun 27 20:07:27 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sat, 27 Jun 2020 21:07:27 +0200 (CEST)
Subject: [ANN] Web based gemlog authoring
Message-ID: <1786878639.1107843.1593284847475@ichabod.co-bxl>

I believe that avoiding the web entirely, with regard to gemini, is probably the best call. 
But that that leaves out a TON of people that lack the technical knowhow to ssh, rsync, git, etc.

As such, I have built a website that allows users to create accounts on my gemini server
and post content from simple web based forms. The site uses no js, no cookies, no session or
local storage, and no external stylesheet(s).

I am hopeful that as interest in gemini grows in non-developer communities the site may offer
a way for less technically inclined folks to add their voices to gemini space.

The site is specifically focused on "gemlogs"/journaling rather than on general content upload. 

The website and gemini URLs:

https://gemlog.blue
gemini://gemlog.blue

I'm still working through some things, but all of the basic functionality is working.

Small shout out to the creator of: https://proxy.vulpes.one
When a post is made, the content is linked via the proxy and has worked out quite well!

--?
Sent with https://mailfence.com
Secure and private email

From cage-dev at twistfold.it  Sat Jun 27 20:23:16 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 27 Jun 2020 21:23:16 +0200
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <alpine.DEB.2.20.2006271932440.1719@pling.qwghlm.org>
References: <20200627085714.GA7701@SDF.ORG>
 <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
 <20200627182702.GA1942@kurosawa.casa.net>
 <alpine.DEB.2.20.2006271932440.1719@pling.qwghlm.org>
Message-ID: <20200627192316.GA4956@kurosawa.casa.net>

On Sat, Jun 27, 2020 at 07:33:30PM +0100, Martin Keegan wrote:

[...]

> Incidentally, how do these clients behave if someone sets their server to
> redirect "gemini://hostname.domain.com/" to "gemini://hostname.domain.com",
> i.e., if they remove the slash?

Interesting question!

I did not took into account this case but seems that my client is not
going to  remove the  slash. I wonder  if this is  the correct  way to
process such URI.

Bye!
C.

From cel at celehner.com  Sat Jun 27 20:28:17 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Sat, 27 Jun 2020 15:28:17 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627114239.0d9233f5d45a4d1f41187930@gmail.com>
References: <20200627085714.GA7701@SDF.ORG>
 <20200627114239.0d9233f5d45a4d1f41187930@gmail.com>
Message-ID: <20200627152817.452a0840@celehner.com>

On Sat, 27 Jun 2020 08:57:14 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> On the server side, server authors should take care when doing things
> like automatically generating directory listings to put trailing
> slashes in links to directories so that the redirect is not necessary.

Search engines and link aggregators could also help.

For example, GUS has this entry:
  gemini://gemini.circumlunar.space/servers
which is a redirect to:
  gemini://gemini.circumlunar.space/servers/

The search engine could try to detect that kind of redirect during the
crawl and update the entry.

On Sat, 27 Jun 2020 11:42:39 +0200
Philip Linde <linde.philip at gmail.com> wrote:

> A server that serves different content on //server and //server/ can
> be a huge pain in the neck. When I wrote my dillo plugin I noticed
> that it seems to apply this normalization in reverse before the URL
> is handed to the plugin. So "gemini://example.horse/" could only be
> seen on the plugin end as "gemini://example.horse", which also makes
> redirects to "gemini://example.horse/" loop back to
> "gemini://example.horse/". Redirect hell ensued!

I also noticed this. Dillo uses whichever URL was loaded first in the
session (with or without the "/"). It caches the resulting resource,
with the normalized URL as the cache key. So if you visit
"gemini://example.horse" first, then subsequently visiting
"gemini://example.horse/" retrieves the cached response for
"gemini://example.horse". And you can't remove the cache entry except
by starting a new Dillo process.

Since servers are redirecting "" to "/", I think adding the "/" in the
plugin like you are doing is the right thing to do, to work around what
I now consider a bug in Dillo. In the older dillo-gemini plugin, I did
not think to do that, but instead made redirects not automatic but just
an internal page with a link to the target URL (i.e. require user
confirmation) and work around the cache/normalization problem as a
user by manually adding a query string to the URL to get a new cache
key, e.g. visiting "gemini://example.horse/?"

-- 
Charles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/2dc0b44e/attachment.sig>

From colecmac at protonmail.com  Sat Jun 27 20:35:38 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 27 Jun 2020 19:35:38 +0000
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627152817.452a0840@celehner.com>
References: <20200627085714.GA7701@SDF.ORG>
 <20200627114239.0d9233f5d45a4d1f41187930@gmail.com>
 <20200627152817.452a0840@celehner.com>
Message-ID: <Sm6M2mAXxd5xPJldiq8L8le0JYjZj1Uj7f7LCtfETYKDRsqme52SMpvL8PTb-6qcUP_6akwj8gRZPCdb1x3F70MPG-99-lPvFPx18bYkHlk=@protonmail.com>

> I also noticed this. Dillo uses whichever URL was loaded first in the
> session (with or without the "/"). It caches the resulting resource,
> with the normalized URL as the cache key. So if you visit
> "gemini://example.horse" first, then subsequently visiting
> "gemini://example.horse/" retrieves the cached response for
> "gemini://example.horse". And you can't remove the cache entry except
> by starting a new Dillo process.


The way I do it in Amfora is normalize each URL for the cache and display,
so that URLs like //example.com:1965/ and gemini://example.com/ aren't cached
twice. And redirects are never cached, although maybe it makes sense to do that
separately.

makeworld

From paper at tilde.institute  Sat Jun 27 20:37:46 2020
From: paper at tilde.institute (Paper)
Date: Sat, 27 Jun 2020 15:37:46 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627085714.GA7701@SDF.ORG>
References: <20200627085714.GA7701@SDF.ORG>
Message-ID: <20200627193746.dtbbnzmits75jnmt@tilde.institute>

On Sat, Jun 27, 2020 at 08:57:14AM +0000, solderpunk wrote:
> Gemini servers (and servers for any other protocol supporting relative
> URLs, including HTTP) will use redirects to get clients to add a
> trailing slash to a URL which maps to a directory on the server's
> filesystem.  Handling this redirect is often invisible to the client
> user, with the result that what "looks and feels" like a single request
> is actually two immediately consecutive requests.  This makes latency
> appear to be much worse than it actually is.  Perhaps this underlies
> some people's perceptions that Gemini has unacceptable latency.
> 
> This basic problem is unavoidable, but there are many small things
> client and server authors can do to minimise how often it happens:
> 
> In general, the client can't add a missing trailing slash itself because
> it never knows if a given URL maps to something file-like or something
> directory-like.  An interesting exception is the root of the server.
> Molly Brown and Jetforce (but not GLV-1.12556) both seem to redirect
> gemini.example.com to gemini.example.com/, making the loading of
> "homepages" feel slower than it needs to.  I'm pretty sure it should be
> safe for clients to automatically append trailing slashes to URLs
> without paths.

I have a script which checks for redirects on websites and reports
status codes. On web it is much smaller problem - the saved latency is
much less. This way I can see dead links and links which could cause
problems - http redirects instead of https or normal redirects which can be
optimised. Maybe something similar could be done for gemini, so that content
authors could check if their links are ok.

I don't like this idea, because content authors should focus on writing
content, not on how the content looks or if they are writing it the
"correct way". Linters for gemini code sound like a bad idea and a sign
that something is wrong.

> On the server side, server authors should take care when doing things
> like automatically generating directory listings to put trailing slashes
> in links to directories so that the redirect is not necessary.
That's the best solution I think.

Paper

From tcb913 at gmail.com  Sat Jun 27 20:41:00 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Sat, 27 Jun 2020 15:41:00 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627182702.GA1942@kurosawa.casa.net>
References: <20200627085714.GA7701@SDF.ORG>
 <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
 <20200627182702.GA1942@kurosawa.casa.net>
Message-ID: <c5e00ba2-84f6-a2e2-649f-dd7051e9fe9c@gmail.com>

Please excuse something a bit off-topic.

If the author/maintainer of the (mostly excellent) bombadillo browser 
sees this, please email back to me. I want to pass on an issue, and have 
been stymied by your "issues" page.

Thanks.

tb

From colecmac at protonmail.com  Sat Jun 27 20:46:36 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 27 Jun 2020 19:46:36 +0000
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <c5e00ba2-84f6-a2e2-649f-dd7051e9fe9c@gmail.com>
References: <20200627085714.GA7701@SDF.ORG>
 <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
 <20200627182702.GA1942@kurosawa.casa.net>
 <c5e00ba2-84f6-a2e2-649f-dd7051e9fe9c@gmail.com>
Message-ID: <CillJK9MODGiYLuBRng9kv0T8wck99iTj29BS5RbVCC_Iq9lz0DAG83OXRwZIs-dajHAw_sL0lq2vNwUrE31rW2XCTIfPW8VyKrksdXiweY=@protonmail.com>

> Please excuse something a bit off-topic.
>
> If the author/maintainer of the (mostly excellent) bombadillo browser
> sees this, please email back to me. I want to pass on an issue, and have
> been stymied by your "issues" page.
>
> Thanks.
>
> tb


You'll need a tildegit account. Feel free to email me the issue and I'll file it for you though.

makeworld

From tcb913 at gmail.com  Sat Jun 27 20:54:36 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Sat, 27 Jun 2020 15:54:36 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <CillJK9MODGiYLuBRng9kv0T8wck99iTj29BS5RbVCC_Iq9lz0DAG83OXRwZIs-dajHAw_sL0lq2vNwUrE31rW2XCTIfPW8VyKrksdXiweY=@protonmail.com>
References: <20200627085714.GA7701@SDF.ORG>
 <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
 <20200627182702.GA1942@kurosawa.casa.net>
 <c5e00ba2-84f6-a2e2-649f-dd7051e9fe9c@gmail.com>
 <CillJK9MODGiYLuBRng9kv0T8wck99iTj29BS5RbVCC_Iq9lz0DAG83OXRwZIs-dajHAw_sL0lq2vNwUrE31rW2XCTIfPW8VyKrksdXiweY=@protonmail.com>
Message-ID: <58e68e2d-b1b4-c43f-2ecf-8bfc8ea516e7@gmail.com>

Right! one issue with bombadillo, one with the "issues" page.

Bombadillo: I really like the look and feel of the browser, and 
accessing a few sites (especially gemini.circumlunar.space) is very 
quick. But most other gopher and gemini sites (eg: 
bombadillo.colorfield.space) seem to be unreachable. I get a TCP 
time-out after 5 seconds. This is tough, since my "broadband" connection 
is pretty slow.

"Issues": you may have answered this already. Submitting an issue 
requires registering. Registering requires three fields: a user name, an 
email address, and a password. But when I give an email address, the 
page tells me that I cannot use an email address (required field). Odd.

Thanks very much for your help.

tb


On 06/27/2020 03:46 PM, colecmac at protonmail.com wrote:
>> Please excuse something a bit off-topic.
>>
>> If the author/maintainer of the (mostly excellent) bombadillo browser
>> sees this, please email back to me. I want to pass on an issue, and have
>> been stymied by your "issues" page.
>>
>> Thanks.
>>
>> tb
>
> You'll need a tildegit account. Feel free to email me the issue and I'll file it for you though.
>
> makeworld


From meff at meff.me  Sat Jun 27 21:25:21 2020
From: meff at meff.me (Meff)
Date: Sat, 27 Jun 2020 13:25:21 -0700
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626223743.GA7071@SDF.ORG>
References: <20200626135633.GD4156@SDF.ORG>
 <20200626221811.GJ19717@brevard.conman.org> <20200626223743.GA7071@SDF.ORG>
Message-ID: <26c24fcf-bf18-fb53-268b-4eb6b0d21708@meff.me>

I, personally, feel that TLS is an incontrovertible part of the appeal 
of Gemini to me
(I've been using Gopher for my own personal things that I want to serve 
_without_ TLS),
but I think there should be guidance on selecting TLS parameters. I've 
run some load tests
and generated some pretty graphs for different generated keys and using 
them with both
Jetforce and Molly Brown, and there is certainly low hanging fruit to 
work on. If folks
are interested, I can collect some of my tests, data, and Python 
analysis and I can
put them up in a digestible post.

- meff

On 6/26/20 3:37 PM, solderpunk wrote:
> On Fri, Jun 26, 2020 at 06:18:11PM -0400, Sean Conner wrote:
>> It was thus said that the Great solderpunk once stated:
>>> There are several contributing factors to TLS overhead.
>>    I think some of the overhead concern is overblown.
> Oh, I completely agree.  It seems to bother a lot of people so I've been
> pointing out comparatively quick and easy things we could do without
> changing the spec at all to address it, because I'd much rather do that
> than increase complexity or reduce security.  But my personal experience
> using AV-98 is that browsing Geminispace feels plenty snappy enough as is.
> Especially relative to how long the content takes to consume.
>
>>    How are they stored?  If they look like this:
>>
>> -----BEGIN CERTIFICATE-----
>> MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT
>> MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG
>> A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0
>> ...
>>
>> then your figures are a bit high
> They're DER encoded binary files, so no worries about that.
>
>> 		size direction
>> 	1	60 ->		SYN packet to server (no data)
>> 	2	60 <-		SYN + ACK from server (still no data)
>> 	3	52 ->		ACK from client (still no data)
>> 	4	203 ->		initial client TLS request
>> 	5	52 <-		ACK from server (no data)
>> 	6	1492 <-		server certificate
>> 	7	52 ->		ACK from client (no data)
>> 	8	611 <-		TLS? unsure from this point on
>> 	9	52 ->		ACK from client (no data)
>> 	10	144 ->		data
>> 	11	52 <-		ACK from server (no data)
>> 	12	95 <-		data
>> 	13	102 ->		data
>> 	14	1492 <-		data (I'm assuming by now this is the file)
>> 	15	1282 <-		data (probably more file)
>> 	16	52 ->		ACK from client (no data)
>> 	17	75 <-		getting ready to close?
>> 	18	75 ->		getting ready to cloes?
>> 	19	52 ->		FIN + ACK from client (no data)
>> 	20	46 <-		FIN from server (no data)
> Thanks for this, very enlightening!
>
> Cheers,
> Solderpunk


From ben at tilde.team  Sat Jun 27 21:38:10 2020
From: ben at tilde.team (Ben Harris)
Date: Sat, 27 Jun 2020 16:38:10 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <58e68e2d-b1b4-c43f-2ecf-8bfc8ea516e7@gmail.com>
References: <20200627085714.GA7701@SDF.ORG>
 <IqyUxD_ey7Z6Ai7HIqAFy9pnWF_eJL70fazFzHfmS2UKRUOnPhXF4mM6z7zeraULJHRuCltmFehgk9uLb56gvFT26EfCoF-97-p95kSQbHU=@protonmail.com>
 <20200627182702.GA1942@kurosawa.casa.net>
 <c5e00ba2-84f6-a2e2-649f-dd7051e9fe9c@gmail.com>
 <CillJK9MODGiYLuBRng9kv0T8wck99iTj29BS5RbVCC_Iq9lz0DAG83OXRwZIs-dajHAw_sL0lq2vNwUrE31rW2XCTIfPW8VyKrksdXiweY=@protonmail.com>
 <58e68e2d-b1b4-c43f-2ecf-8bfc8ea516e7@gmail.com>
Message-ID: <78132972-55b8-0a03-6758-d9a4ace602de@tilde.team>

On 6/27/20 3:54 PM, Terry Brennan wrote:
> Right! one issue with bombadillo, one with the "issues" page.
> 
> Bombadillo: I really like the look and feel of the browser, and 
> accessing a few sites (especially gemini.circumlunar.space) is very 
> quick. But most other gopher and gemini sites (eg: 
> bombadillo.colorfield.space) seem to be unreachable. I get a TCP 
> time-out after 5 seconds. This is tough, since my "broadband" connection 
> is pretty slow.
> 
> "Issues": you may have answered this already. Submitting an issue 
> requires registering. Registering requires three fields: a user name, an 
> email address, and a password. But when I give an email address, the 
> page tells me that I cannot use an email address (required field). Odd.

I'm the admin on tildegit.org. I just added a notice to the signup page 
about the allowed email domain list. Sorry for the inconvenience but it 
has curbed automated spam accounts entirely, which was taking a 
significant amount of my time.

Cheers,
~ben

From natpen at natpen.net  Sat Jun 27 22:06:00 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sat, 27 Jun 2020 17:06:00 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627152817.452a0840@celehner.com>
References: <20200627085714.GA7701@SDF.ORG>
 <20200627114239.0d9233f5d45a4d1f41187930@gmail.com>
 <20200627152817.452a0840@celehner.com>
Message-ID: <20200627210600.GA1331@goldfish.localdomain>

On Sat, Jun 27, 2020 at 03:28:17PM -0400, Charles E. Lehner wrote:
> Search engines and link aggregators could also help.
>
> For example, GUS has this entry:
>   gemini://gemini.circumlunar.space/servers
> which is a redirect to:
>   gemini://gemini.circumlunar.space/servers/

Out of curiosity, do you remember the query that got you that search
result? When I perform the below search, I only seem to be able to
find it with the trailing slash. Your result is surprising to me
because GUS already does reliably follow (or at least I think it does
:) trailing slash redirects and provide the redirected URL in search
results.

```
## "servers AND domain:circumlunar"

=> gemini://gemini.circumlunar.space/servers/ gemini.circumlunar.space/servers/ (text/gemini, 2K)
* ...Geminispace is now growing at such a rate that maintaining an exhaustive list of servers by hand is no longer terribly practical or terribly useful. Thus, this list is no longer being...
```

From sean at conman.org  Sat Jun 27 22:17:42 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 27 Jun 2020 17:17:42 -0400
Subject: [REQ] Element IDs in the web specification
In-Reply-To: <1099146806.1107636.1593284470312@ichabod.co-bxl>
References: <1099146806.1107636.1593284470312@ichabod.co-bxl>
Message-ID: <20200627211742.GN19717@brevard.conman.org>

It was thus said that the Great Brian Evans once stated:
> I would like to link to the `text/gemini` portion of the spec for a
> project I am working on. However, there are no IDs on any of the elements.
> This makes it impossible to link someone directly to a section. :(
> 
> If this can get updated it would be much appreciated. I am trying to link
> it as additional information for non-technical users... so linking to the
> full spec might be overwhelming.
> 
> I know it has been brought up before to separate text/gemini from the
> protocol spec, and just thought I would float that here again...

  On the plus side, there are two RFCs (RFC-5147 and RFC-7111) that define
URI fragment semantics to particular resource types.  Downside, they don't
directly apply to text/gemini.

  One method would be to use verbatim text as the ID, starting from the
start of the line.  So for your use case:

gemini://gemini.circumlunar.space/docs/specification.gmi#%235%20The

the fragment portion, decoded, would be "# 5 The" (note:  the '#' here is
encoded as %23).  The client would then scan through the document in
question looking for a line that starts with "# The" and position the
document accordingly in the window/viewport/terminal.

  The second method would be to adapt the one for text/plain (RFC-5147).

  The two methods have the advantage of not modifying text/gemini and could
be a convention of clients util some method clearly beomces the winner.

  -spc


From b__m__e at mailfence.com  Sat Jun 27 22:27:05 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Sat, 27 Jun 2020 23:27:05 +0200 (CEST)
Subject: [REQ] Element IDs in the web specification
In-Reply-To: <20200627211742.GN19717@brevard.conman.org>
References: <1099146806.1107636.1593284470312@ichabod.co-bxl>
 <20200627211742.GN19717@brevard.conman.org>
Message-ID: <2139366945.3933.1593293225235@ichabod.co-bxl>


> From: Sean Conner <sean at conman.org>
>   On the plus side, there are two RFCs (RFC-5147 and RFC-7111) that define
> URI fragment semantics to particular resource types.  Downside, they don't
> directly apply to text/gemini.
> 
>   One method would be to use verbatim text as the ID, starting from the
> start of the line.  So for your use case:
> 
> gemini://gemini.circumlunar.space/docs/specification.gmi#%235%20The
> 
> the fragment portion, decoded, would be "# 5 The" (note:  the '#' here is
> encoded as %23).  The client would then scan through the document in
> question looking for a line that starts with "# The" and position the
> document accordingly in the window/viewport/terminal.
> 
>   The second method would be to adapt the one for text/plain (RFC-5147).
> 
>   The two methods have the advantage of not modifying text/gemini and could
> be a convention of clients util some method clearly beomces the winner.
> 
>   -spc
> 

I'm sorry I wasnt more clear: I had meant for the web version adding ID
attributes would be useful.

That said, I like the idea of using the fragment portion on gemini in the way you
describe. If I get some time I may try to mock this up and see if I can get it to
work. :)

--?
Sent with https://mailfence.com
Secure and private email

From sean at conman.org  Sat Jun 27 22:40:33 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 27 Jun 2020 17:40:33 -0400
Subject: [ANN] Web based gemlog authoring
In-Reply-To: <1786878639.1107843.1593284847475@ichabod.co-bxl>
References: <1786878639.1107843.1593284847475@ichabod.co-bxl>
Message-ID: <20200627214033.GO19717@brevard.conman.org>

It was thus said that the Great Brian Evans once stated:
> I believe that avoiding the web entirely, with regard to gemini, is probably the best call. 
> But that that leaves out a TON of people that lack the technical knowhow to ssh, rsync, git, etc.
> 
> As such, I have built a website that allows users to create accounts on my gemini server
> and post content from simple web based forms. The site uses no js, no cookies, no session or
> local storage, and no external stylesheet(s).
> 
> https://gemlog.blue
> gemini://gemlog.blue

  I saw on your Gemini post that you are trying to get editing and deleting
posts working.  A very silly, and out there suggestion---why not client
certificates?  Apache does support them, and there are HTTP methods that are
quite well suited to the task at hand (POST, PUT, DELETE).  You could set up
a method similar to Astrobotany to sign CSRs

	gemini://astrobotany.mozz.us/register

  Just an idea ...

  -spc

P.S. Here's the Apache config I created a few weeks ago when I started
looking into this:

<VirtualHost 192.168.1.10:443>
        ServerName      wiki.roswell.area51
        ServerAdmin     spc at conman.org
        DocumentRoot    /home/spc/web/wiki/htdocs
        ScriptAlias     /.cgi/ /home/spc/web/wiki/cgi-bin/
        AddHandler      cgi-script .cgi

        SSLEngine               on
        SSLCipherSuite          ALL
        SSLCACertificateFile    /home/spc/JAIL/etc/ssl/cert.pem
        SSLCertificateFile      /home/spc/web/wiki/cert.pem
        SSLCertificateKeyFile   /home/spc/web/wiki/key.pem
        SSLProtocol             +TLSv1.2

        <Directory /home/spc/web/wiki/cgi-bin>
                Options                 All
                AllowOverride           None
                Require                 valid-user
                Require                 ssl-verify-client
                SSLOptions              +StdEnvVars
                SSLVerifyClient         require
                SSLVerifyDepth          5
        </Directory>

        <Directory /home/spc/web/wiki/htdocs>
                Options         All -ExecCGI
                AllowOverride   None
                Require         all granted
                Script          PUT    /.cgi/put.cgi
                Script          DELETE /.cgi/delete.cgi
        </Directory>
</VirtualHost>


From mbrubeck at limpet.net  Sat Jun 27 23:18:18 2020
From: mbrubeck at limpet.net (Matt Brubeck)
Date: Sat, 27 Jun 2020 15:18:18 -0700
Subject: RTT0
In-Reply-To: <20200627090751.GA7371@localhost>
References: <20200627090751.GA7371@localhost>
Message-ID: <CAD1=23=zpQeXT=frWFry_E-D97OOuLUeMrEDXkkS_yBeaQacsA@mail.gmail.com>

On Sat, Jun 27, 2020 at 2:09 AM <mbays at sdf.org> wrote:
> Do any currently running servers implement RTT0, i.e. accept early data?

In this recent thread, the answer was no (as far as anyone seems to know):
https://lists.orbitalfox.eu/archives/gemini/2020/001886.html

I'm hoping to add early data support to my own server at some point,
but I haven't had time yet.

From cel at celehner.com  Sun Jun 28 00:31:36 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Sat, 27 Jun 2020 19:31:36 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627210600.GA1331@goldfish.localdomain>
References: <20200627085714.GA7701@SDF.ORG>
 <20200627114239.0d9233f5d45a4d1f41187930@gmail.com>
 <20200627152817.452a0840@celehner.com>
 <20200627210600.GA1331@goldfish.localdomain>
Message-ID: <20200627193136.1809f2ac@celehner.com>

Hi Natalie,

> > For example, GUS has this entry:
> >   gemini://gemini.circumlunar.space/servers
> > which is a redirect to:
> >   gemini://gemini.circumlunar.space/servers/  
> 
> Out of curiosity, do you remember the query that got you that search
> result? When I perform the below search, I only seem to be able to
> find it with the trailing slash. Your result is surprising to me
> because GUS already does reliably follow (or at least I think it does
> :) trailing slash redirects and provide the redirected URL in search
> results.

My mistake, it is houston, not GUS. I'm glad GUS follows the redirects already.

gemini://houston.coder.town/search?list

Regards,
Charles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/82a114fd/attachment-0001.sig>

From me at evertpot.com  Sun Jun 28 02:05:10 2020
From: me at evertpot.com (Evert Pot)
Date: Sat, 27 Jun 2020 21:05:10 -0400
Subject: SRV records
Message-ID: <f257cb50-77ef-c359-08a2-de73f5d22b80@evertpot.com>

Dear list,

I would like to play around with Gemini and build a personal site. I'd
love to be able to host it on my main domain at gemini://evertpot.com/

However, that domain is currently pointing to Github Pages, something I
would like to not change.

It occurred to me that it would be nice if I could use DNS SRV records
to point gemini:// clients to a different host. However, after reading
the spec it doesn't seem like there is support for this.

I would love support for this, but or that to be realistically useful,
it would have to be in the spec and required. I know a lot of HTTP folks
wish they had that from the start too, as it's a pain to adopt later.

I couldn't find in the archives if this has been asked before.

Great project, and I hope I can make a positive contribution to the
ecosystem.

Evert




From sean at conman.org  Sun Jun 28 03:55:52 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 27 Jun 2020 22:55:52 -0400
Subject: SRV records
In-Reply-To: <f257cb50-77ef-c359-08a2-de73f5d22b80@evertpot.com>
References: <f257cb50-77ef-c359-08a2-de73f5d22b80@evertpot.com>
Message-ID: <20200628025552.GP19717@brevard.conman.org>

It was thus said that the Great Evert Pot once stated:
> Dear list,
> 
> I would like to play around with Gemini and build a personal site. I'd
> love to be able to host it on my main domain at gemini://evertpot.com/

  Okay, so you are running a service on port 1965 that *isn't* Gemini, and
you would like to run a Gemini server on a different port, but not have to
specify the port number on the URL.  Okay, got it.

> It occurred to me that it would be nice if I could use DNS SRV records
> to point gemini:// clients to a different host. However, after reading
> the spec it doesn't seem like there is support for this.
> 
> I would love support for this, but or that to be realistically useful,
> it would have to be in the spec and required. I know a lot of HTTP folks
> wish they had that from the start too, as it's a pain to adopt later.

  Like you, I wouldn't mind seeing SRV records used more often, but there
are considerations.  First off, the dismal state of DNS resolution libaries
out there.  For the most part, they pretty much do too much (have their own
network driver that is hard to integrate into an existing network based
program) and do too little (very little support for non A/AAAA records---you
might get lucky and get MX support).

  I was fed up enough to write my own DNS encoding/decoding library [1] but
that only helps if you use C (or Lua---I include Lua bindings in the
library) and you still need to integrate your own networking with it [3].

  Second, the code needs to be aware that multiple SRV records for a given
service can exist, and how to order the results and pick one.

  And the use of SRV records impact clients more than servers.  Instead of
now, where a client can go:

	location = breakdown(url)
	address = getaddrinfo(location.host,location.port or 1965)

you now need:

	results = lookup(RR_SRV,location.host)
	if results then
		sort(results) /* based upon priority and weight */
				/* if not done by the lookup() routine */
		for each result in results do
		  address = getaddrinfo(result.host,result.port)
		  if address then break
		end
	end
	if not address then
		address = getaddrinfo(location.host,location.port or 1965)
	end

  Keep in mind the above is "get the idea" pseudocode, not real code.

> I couldn't find in the archives if this has been asked before.

  It has not.

  -spc (The client now needs to know which DNS server to query, and how does
	it obtain *that* information?)

[1]	https://github.com/spc476/SPCDNS [2]

[2]	My most popular Github project if going by stars.

[3]	A lot easier than with the other DNS libraries I've come across, but
	it still needs to be done.

From colecmac at protonmail.com  Sun Jun 28 04:46:46 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 28 Jun 2020 03:46:46 +0000
Subject: SRV records
In-Reply-To: <f257cb50-77ef-c359-08a2-de73f5d22b80@evertpot.com>
References: <f257cb50-77ef-c359-08a2-de73f5d22b80@evertpot.com>
Message-ID: <CsqTErmiyJsf6xw950O3UEycQEaDeagumjD5gz8kJvrDHFPUrQsUramkR6GvJG4JO7txbfkiiJk5yqT9_vg42BFoEKpMfDtYteiiadAzub0=@protonmail.com>

> I would like to play around with Gemini and build a personal site. I'd
> love to be able to host it on my main domain at gemini://evertpot.com/
>
> However, that domain is currently pointing to Github Pages, something I
> would like to not change.

There isn't really a great way around this, as you can't rely on clients
supporting SRV records or anything. Here are two options:

* Host Gemini on gem.evertpot.com, or gemini.evertpot.com
* Switch Github pages to www.evertpot.com, and on your Gemini machine, run
  a webserver that serves redirects from evertpot.com to www.evertpot.com - and
  then also run a Gemini server on :1965

The latter is what I do personally, but either works. I don't see a lot of
other options.

makeworld

From krixano at protonmail.com  Sun Jun 28 09:20:40 2020
From: krixano at protonmail.com (Krixano)
Date: Sun, 28 Jun 2020 08:20:40 +0000
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200627085714.GA7701@SDF.ORG>
References: <20200627085714.GA7701@SDF.ORG>
Message-ID: <7SfCdG-cR3S02xHp0SWl-YUiJs0NZ4IzoRNyGIKsLaRZ-RdsKRH95CdIsLwGmADgbpsO7tTTzZpS5QsUqcygdnH_fPhyks038oEUjPdhjFo=@protonmail.com>

Ok, so I have a legitimate question... why are servers even redirecting for something as dumb as a trailing slash anyways?


Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Saturday, June 27, 2020 3:57 AM, solderpunk <solderpunk at SDF.ORG> wrote:

> I sent the following email (and many others, which will follow shortly)
> to the list last night, but SDF's mailserver was acting up and they
> never went through. I thought they'd appear eventually, but it appears
> not, so I'm resending them now. Apologies if double posts eventually
> appear.
>
> ----- Forwarded message from solderpunk solderpunk at SDF.ORG -----
>
> Date: Fri, 26 Jun 2020 15:47:57 +0000
> From: solderpunk solderpunk at SDF.ORG
> To: gemini at lists.orbitalfox.eu
> Subject: Illusory latency due to trailing slash redirects
>
> Gemini servers (and servers for any other protocol supporting relative
> URLs, including HTTP) will use redirects to get clients to add a
> trailing slash to a URL which maps to a directory on the server's
> filesystem. Handling this redirect is often invisible to the client
> user, with the result that what "looks and feels" like a single request
> is actually two immediately consecutive requests. This makes latency
> appear to be much worse than it actually is. Perhaps this underlies
> some people's perceptions that Gemini has unacceptable latency.
>
> This basic problem is unavoidable, but there are many small things
> client and server authors can do to minimise how often it happens:
>
> In general, the client can't add a missing trailing slash itself because
> it never knows if a given URL maps to something file-like or something
> directory-like. An interesting exception is the root of the server.
> Molly Brown and Jetforce (but not GLV-1.12556) both seem to redirect
> gemini.example.com to gemini.example.com/, making the loading of
> "homepages" feel slower than it needs to. I'm pretty sure it should be
> safe for clients to automatically append trailing slashes to URLs
> without paths.
>
> On the server side, server authors should take care when doing things
> like automatically generating directory listings to put trailing slashes
> in links to directories so that the redirect is not necessary.
>
> These measures together could cut perceived latency in half for a
> non-trivial proportion of Gemini requests, including the psychologically
> heavily weighted request of visiting a server's homepage.
>
> Cheers,
> Solderpunk



From carsten at strotmann.de  Sun Jun 28 10:14:07 2020
From: carsten at strotmann.de (Carsten Strotmann)
Date: Sun, 28 Jun 2020 11:14:07 +0200
Subject: SRV records
In-Reply-To: <f257cb50-77ef-c359-08a2-de73f5d22b80@evertpot.com>
References: <f257cb50-77ef-c359-08a2-de73f5d22b80@evertpot.com>
Message-ID: <86y2o7k0ww.fsf@emacs.strotmann.de>

Hi Evert,
Hi List,

Evert Pot <me at evertpot.com> writes:
>
> It occurred to me that it would be nice if I could use DNS SRV 
> records
> to point gemini:// clients to a different host. However, after 
> reading
> the spec it doesn't seem like there is support for this.

The SRV record might be superceded by the SVCB/HTTPSSVC record:

Service binding and parameter specification via the DNS (DNS SVCB 
and HTTPSSVC)
<https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc>

Goolge is experimenting with this to be able to upgrade HTTPS 
sessions
to QUIC, while Apple seems to use it to discover DoT/DoH resolver 
for
the upcoming MacOS 11 and iOS 14.

SVCB/HTTPSSVC is an Internet Draft, it will likely change (a lot) 
until
reaching RFC status, or it might expire (not reach RFC status at 
all).

The problems remains that OS resovler libraries (libc) do not 
support DNS
records other than A/AAAA and a handful of others.

Libraries like GetDNSAPI <https://getdnsapi.net/> need to be used 
to retrieve
these records.

Gemini server discovery could be discussed in a document separate 
of the
Gemini protocol spec.

Client implementations could optionally implement support for 
finding
Gemini server via SRV, SVCB, mDNS or other discovery protocols.

Greetings

Carsten

From sean at conman.org  Sun Jun 28 11:12:44 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 28 Jun 2020 06:12:44 -0400
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <7SfCdG-cR3S02xHp0SWl-YUiJs0NZ4IzoRNyGIKsLaRZ-RdsKRH95CdIsLwGmADgbpsO7tTTzZpS5QsUqcygdnH_fPhyks038oEUjPdhjFo=@protonmail.com>
References: <20200627085714.GA7701@SDF.ORG>
 <7SfCdG-cR3S02xHp0SWl-YUiJs0NZ4IzoRNyGIKsLaRZ-RdsKRH95CdIsLwGmADgbpsO7tTTzZpS5QsUqcygdnH_fPhyks038oEUjPdhjFo=@protonmail.com>
Message-ID: <20200628101243.GQ19717@brevard.conman.org>

It was thus said that the Great Krixano once stated:
> Ok, so I have a legitimate question... why are servers even redirecting
> for something as dumb as a trailing slash anyways?

  Semantically (and stated in RFC-3986) they are separate resources.  For a
fun time, try the following two links:

	gemini://gemini.conman.org/test/doc1
	gemini://gemini.conman.org/test/doc1/

  Spoiler:  they aren't the same document.

  -spc (Also, consider CGI scripts, they don't *have* to have an extension,
	at least on GLV-1.12556 ... [1])

[1]	Not to say those two links are done via CGI.

From linde.philip at gmail.com  Sun Jun 28 20:22:29 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sun, 28 Jun 2020 21:22:29 +0200
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200628101243.GQ19717@brevard.conman.org>
References: <20200627085714.GA7701@SDF.ORG>
 <7SfCdG-cR3S02xHp0SWl-YUiJs0NZ4IzoRNyGIKsLaRZ-RdsKRH95CdIsLwGmADgbpsO7tTTzZpS5QsUqcygdnH_fPhyks038oEUjPdhjFo=@protonmail.com>
 <20200628101243.GQ19717@brevard.conman.org>
Message-ID: <20200628212229.a8df2a7bf7a178ec573255cb@gmail.com>

>   Semantically (and stated in RFC-3986) they are separate resources.  For a
> fun time, try the following two links:
> 
> 	gemini://gemini.conman.org/test/doc1
> 	gemini://gemini.conman.org/test/doc1/

Those two are, but consider these:

	gemini://gemini.conman.org
	gemini://gemini.conman.org/

Per RFC 3986, they should be equivalent. A server respecting the
standard should understand an authority without a path specified as
referring to the path "/". This is described in section 6.2.3.

Of course, this is "in general" for schemes using authorities? and I
guess a scheme can define its own normalization rules, but AFAIK no
exceptions to this have been specified for Gemini.

On that basis I think servers that serve different content on these
should fix it to mean exactly the same thing.

For URLs that have paths specified like in your example, clients should
as you say be able to handle them being different because there are no
such normalization rules for URLS with paths specified.

Best regards,
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200628/56c5d513/attachment.sig>

From solderpunk at SDF.ORG  Mon Jun 29 12:08:39 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Mon, 29 Jun 2020 11:08:39 +0000
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <7SfCdG-cR3S02xHp0SWl-YUiJs0NZ4IzoRNyGIKsLaRZ-RdsKRH95CdIsLwGmADgbpsO7tTTzZpS5QsUqcygdnH_fPhyks038oEUjPdhjFo=@protonmail.com>
References: <20200627085714.GA7701@SDF.ORG>
 <7SfCdG-cR3S02xHp0SWl-YUiJs0NZ4IzoRNyGIKsLaRZ-RdsKRH95CdIsLwGmADgbpsO7tTTzZpS5QsUqcygdnH_fPhyks038oEUjPdhjFo=@protonmail.com>
Message-ID: <20200629110839.GA1993@SDF.ORG>

On Sun, Jun 28, 2020 at 08:20:40AM +0000, Krixano wrote:
> Ok, so I have a legitimate question... why are servers even redirecting for something as dumb as a trailing slash anyways?

It might *seem* dumb, but it's essential for relative URLs to work
correctly.  Links in text/gemini may be relative URLs, e.g. just
"other_page.gmi".  It's the client's job to turn that into an absolute
URL, in accordance with the RFC rules for doing so.  If you are at
"gemini://example.com/foo", then that relative link turns into
"gemini://example.com/other_page.gmi", but if you are at
"gemini://example.com/foo/" then it turns into
"gemini://example.com/foo/other_page.gmi".  Web servers do this all the
time for exactly the same reason, you just never notice because browsers
never tell you.

Cheers,
Solderpunk

From defdefred at protonmail.com  Mon Jun 29 21:20:15 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 29 Jun 2020 20:20:15 +0000
Subject: Illusory latency due to trailing slash redirects
In-Reply-To: <20200629110839.GA1993@SDF.ORG>
References: <20200627085714.GA7701@SDF.ORG>
 <7SfCdG-cR3S02xHp0SWl-YUiJs0NZ4IzoRNyGIKsLaRZ-RdsKRH95CdIsLwGmADgbpsO7tTTzZpS5QsUqcygdnH_fPhyks038oEUjPdhjFo=@protonmail.com>
 <20200629110839.GA1993@SDF.ORG>
Message-ID: <S82_2I48NaSLguHk75sihQlehEb5Cq21JfeC8bBB9NtojayImh8MqGILaF2Z3Ysmg8x7kupdT8TUqVW2G8R7J3P8WzjsMIcObHqxB-B0XEE=@protonmail.com>

> On Sun, Jun 28, 2020 at 08:20:40AM +0000, Krixano wrote:
>
> > Ok, so I have a legitimate question... why are servers even redirecting for something as dumb as a trailing slash anyways?

Why are browsers requesting url with servername without the trailing slash?
freD.


From defdefred at protonmail.com  Tue Jun 30 07:59:25 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 30 Jun 2020 06:59:25 +0000
Subject: SVG Bob
In-Reply-To: <5EF496BA.1010009@marmaladefoo.com>
References: <5EF496BA.1010009@marmaladefoo.com>
Message-ID: <UdTqlgqhJ20tf24X5R7CgrilR8did0Jh_fpJC_Ld3srtR6IjyZWSaRcf8SxPsdKH7dcokTI7saq54hfVusQ7eyEt_P_3riZ1edLrIgRXXI0=@protonmail.com>

On Thursday, June 25, 2020 2:21 PM, Luke Emmet <luke at marmaladefoo.com> wrote:
> https://ivanceras.github.io/svgbob-editor/

Thanks!

From defdefred at protonmail.com  Tue Jun 30 08:02:22 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 30 Jun 2020 07:02:22 +0000
Subject: Great web site to port to gemini
In-Reply-To: <87sgeld0pd.fsf@dorothy.carcosa.net>
References: <JUgn4fE7DWgdVddj_nEdDbmbDaG8863b_b96Tp2dSNuHIcCEOinoi4DpC5X9DZY-SSXD2WsZvbqnK-wUKcj8yGbnMCXEkBr-xJG8cVDKLKs=@protonmail.com>
 <20200619124808.cbd7f26fd26c4bef93bdfc7f@matthewgraybosch.com>
 <8-glswtVejVS7IfX2tIYjHWHGfDkxCQo-nIksch-3bJo2RpaFQJPAs_Cj3angduDw11NLloShZfxAhu62VW7m4NdCi-JTAMkFgl9BaxWK9Q=@protonmail.com>
 <20200622220653.8bb04f5d3e43b4b243be397f@matthewgraybosch.com>
 <877dvyq82b.fsf@dorothy.carcosa.net>
 <20200623092609.1d91f3d3e53b568cc5c97db4@matthewgraybosch.com>
 <87wo3xd6fo.fsf@dorothy.carcosa.net>
 <20200623145502.dfc3bdcee2e838a832ebf29d@matthewgraybosch.com>
 <87sgeld0pd.fsf@dorothy.carcosa.net>
Message-ID: <Y5A7XfiYIbI-CoIUA_ye9bAE4eZDgNS1XyF5Eo4kzQDaSwwXgiG3uzVdiX0g5CzZSbtMqlUdBZKMy4V-NioR38lBNLI_dTqOPYbvDmuZBP8=@protonmail.com>

https://sjmulder.nl/en/textonly.html

freD.

From traderbeckola at tahoma.com  Tue Jun 30 16:49:33 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Tue, 30 Jun 2020 11:49:33 -0400
Subject: Gemini Text Markup Language specification
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
Message-ID: <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>

Hi all;

Could someone please point me in the direction of the markup language spec for Gemini? I understand it is a small subset of html, but wasn?t able to find it in the list archives or online at either the http:// or gemini:// sites.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200630/656e3059/attachment.htm>

From petite.abeille at gmail.com  Tue Jun 30 16:52:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 30 Jun 2020 17:52:18 +0200
Subject: Gemini Text Markup Language specification
In-Reply-To: <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
Message-ID: <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>



> On Jun 30, 2020, at 17:49, traderbeckola at tahoma.com wrote:
> 
> Could someone please point me in the direction of the markup language spec for Gemini? I understand it is a small subset of html, but wasn?t able to find it in the list archives or online at either the http:// or gemini:// sites.


gemini://gemini.circumlunar.space/docs/specification.gmi
https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/specification.gmi

From baschdel at disroot.org  Tue Jun 30 21:35:08 2020
From: baschdel at disroot.org (Baschdel)
Date: Tue, 30 Jun 2020 22:35:08 +0200
Subject: (A little) Ambiguity in the response header specification
Message-ID: <5ae0a489-7804-8567-5246-960a618bef80@disroot.org>

Hello [?].

Section 3.1 of the Gemini specification says that <STATUS> and <META> 
are separated by a single space character.

 > Gemini response headers look like this:
 >
 > <STATUS><SPACE><META><CR><LF>
 >
 > [?]
 >
 > <STATUS> and <META> are separated by a single space character.

The problem is the following:

Most people would read this as an ascii space character, however for 
some people this also includes a tab characters (and in my opinion they 
are not wrong)

For this reason I suggest to clarify by adding a line that states that 
<SPACE> refers to the ascii character 0x20 (because that is used by 
almost all servers already) (or if we want to allow tabs clearly specify 
that)

Have a nice Evening!
- Baschdel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200630/129cf901/attachment.htm>

From traderbeckola at tahoma.com  Tue Jun 30 22:26:53 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Tue, 30 Jun 2020 17:26:53 -0400
Subject: Gemini Text Markup Language specification
In-Reply-To: <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
Message-ID: <006b01d64f25$2d05d6f0$871184d0$@tahoma.com>

Thanks!

-----Original Message-----
From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Petite Abeille
Sent: Tuesday, June 30, 2020 11:52 AM
To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
Subject: Re: Gemini Text Markup Language specification



> On Jun 30, 2020, at 17:49, traderbeckola at tahoma.com wrote:
> 
> Could someone please point me in the direction of the markup language spec for Gemini? I understand it is a small subset of html, but wasn?t able to find it in the list archives or online at either the http:// or gemini:// sites.


gemini://gemini.circumlunar.space/docs/specification.gmi
https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/specification.gmi


From tiwesdaeg at tilde.pink  Wed Jul  1 16:12:15 2020
From: tiwesdaeg at tilde.pink (Tiwesdaeg Twohands)
Date: Wed, 1 Jul 2020 10:12:15 -0500
Subject: Gemini Text Markup Language specification
In-Reply-To: <006b01d64f25$2d05d6f0$871184d0$@tahoma.com>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <006b01d64f25$2d05d6f0$871184d0$@tahoma.com>
Message-ID: <e09f2119-0a1f-c2cc-519d-a5fc94862d8c@tilde.pink>

Welcome to tilde.pink! I hope you brought your shades. Your account is
now activated with the username evn. SSH login is via key only.

We do not offer web services. We use geomyidae instead as our
gopher server. It uses .gph files, instead of gophermaps. Default is
index.gph. A public_gopher folder has been created for you with a sample
index.gph file. We've also added a gemini server. Gemini is a gopher
like protocol that is currently in development. It is being designed to
fix some of the drawbacks of gopher, but without having all the issues
of html. You can experiment with gemini by editing and adding things to
your public_gemini folder. There is some initial documentation linked
on the main page.

Please note, the server is in its early stages and very bare bones.
Please let me know if something is missing that you are used to using
in a shell. Also, this is a NetBSD installation. There are many things
different from your normal linux system including your default shell
which is /bin/sh instead of bash. Bash is available if you would like
to change it.

If you are interested in talking to other ~pink users or need help,
please join us via irc on #pink hosted on the irc network tilde.chat

On 6/30/20 4:26 PM, traderbeckola at tahoma.com wrote:
> Thanks!
> 
> -----Original Message-----
> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Petite Abeille
> Sent: Tuesday, June 30, 2020 11:52 AM
> To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
> Subject: Re: Gemini Text Markup Language specification
> 
> 
> 
>> On Jun 30, 2020, at 17:49, traderbeckola at tahoma.com wrote:
>>
>> Could someone please point me in the direction of the markup language spec for Gemini? I understand it is a small subset of html, but wasn?t able to find it in the list archives or online at either the http:// or gemini:// sites.
> 
> 
> gemini://gemini.circumlunar.space/docs/specification.gmi
> https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/specification.gmi
> 

From tiwesdaeg at tilde.pink  Wed Jul  1 16:16:48 2020
From: tiwesdaeg at tilde.pink (Tiwesdaeg Twohands)
Date: Wed, 1 Jul 2020 10:16:48 -0500
Subject: Gemini Text Markup Language specification
In-Reply-To: <e09f2119-0a1f-c2cc-519d-a5fc94862d8c@tilde.pink>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <006b01d64f25$2d05d6f0$871184d0$@tahoma.com>
 <e09f2119-0a1f-c2cc-519d-a5fc94862d8c@tilde.pink>
Message-ID: <885dea88-e3a7-09f0-00eb-6f227a7aa8d5@tilde.pink>

Please disregard. Too many inboxes, so little time.

On 7/1/20 10:12 AM, Tiwesdaeg Twohands wrote:
> Welcome to tilde.pink! I hope you brought your shades. Your account is
> now activated with the username evn. SSH login is via key only.
> 
> We do not offer web services. We use geomyidae instead as our
> gopher server. It uses .gph files, instead of gophermaps. Default is
> index.gph. A public_gopher folder has been created for you with a sample
> index.gph file. We've also added a gemini server. Gemini is a gopher
> like protocol that is currently in development. It is being designed to
> fix some of the drawbacks of gopher, but without having all the issues
> of html. You can experiment with gemini by editing and adding things to
> your public_gemini folder. There is some initial documentation linked
> on the main page.
> 
> Please note, the server is in its early stages and very bare bones.
> Please let me know if something is missing that you are used to using
> in a shell. Also, this is a NetBSD installation. There are many things
> different from your normal linux system including your default shell
> which is /bin/sh instead of bash. Bash is available if you would like
> to change it.
> 
> If you are interested in talking to other ~pink users or need help,
> please join us via irc on #pink hosted on the irc network tilde.chat
> 
> On 6/30/20 4:26 PM, traderbeckola at tahoma.com wrote:
>> Thanks!
>>
>> -----Original Message-----
>> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Petite 
>> Abeille
>> Sent: Tuesday, June 30, 2020 11:52 AM
>> To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>> Subject: Re: Gemini Text Markup Language specification
>>
>>
>>
>>> On Jun 30, 2020, at 17:49, traderbeckola at tahoma.com wrote:
>>>
>>> Could someone please point me in the direction of the markup language 
>>> spec for Gemini? I understand it is a small subset of html, but 
>>> wasn?t able to find it in the list archives or online at either the 
>>> http:// or gemini:// sites.
>>
>>
>> gemini://gemini.circumlunar.space/docs/specification.gmi
>> https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/specification.gmi 
>>
>>

From cage-dev at twistfold.it  Wed Jul  1 18:10:34 2020
From: cage-dev at twistfold.it (cage)
Date: Wed, 1 Jul 2020 19:10:34 +0200
Subject: [ANN] tinmop update
Message-ID: <20200701171034.GA8077@kurosawa.casa.net>

Hi!

I have updated  gemini browser included in  tinmop: a distraction-free
pleroma client.

This  version  (0.1.0)  improves  the gemini  navigation,  now  it  is
possible to  open an arbitrary  address (using command line  switch or
using the Terminal interface) and i  have added a "go back" command to
browse backward the addresses the user already visited.

Of course it  is still possible to open gemini  links contained in the
body of a message posted on the social network.

Tinmop  is  free  software  (GPLv3+ licensed),  more  information  are
available here:

https://www.autistici.org/interzona/tinmop.html

Bye!
C.

PS: i  will only post  update about this  program only when  there are
changes on its gemini browser, i do  not want to spam the mailing list
:)

From philanc at gmail.com  Wed Jul  1 23:06:44 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 1 Jul 2020 22:06:44 +0000
Subject: Minimal client
Message-ID: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>

Hi all,

I am looking for a solution to build a _small_, _statically linked_,
minimal gemini client. My focus at the moment is to implement the
basic communication layer (including TLS!): just enough to send a
request to a gemini host and receive a response.

Has anybody already built such a client? any pointer or suggestion?

Where I stand as of now:

--- I discarded OpenSSL.  Bad memories of building small static
executables a long time ago. Maybe it has improved and I am just
prejudiced.

--- LibreSSL:
  - not TLS v1.3 yet, but definitely alive and moving there.
  - easily builds static libraries, but no modular build: I mean I
found no way to build libraries/executable with only a limited set of
crypto algorithms
  => executables are large: The openssl command (similar to the
OpenSSL one) is 2.5 MB  (built on Linux with Musl libc, fully static,
-Os, stripped). They also include the OpenBSD 'nc' command which
supports TLS connections - 2 MB (for reference I have a small static
nc without TLS support which is 50KB)

--- BearSSL
  - very nice code. An impressive feat for a one-man project (Thomas Pornin)
  - not yet at TLS-1.3. The code looks maintained but I don't know if
it is actively developed. I saw no sign of ed25519 cert signing, but
may be wrong here.
  - code size: the whole libbearssl.a is ~ 860KB, basic client and
server examples are in the 150KB range, which is very nice.

--- WolfSSL
  - supports TLS-1.3. Is actively maintained by a company targeting
embedded systems (but the code is GPL)
  - I don't know yet how to properly build small code, but with a
default support for only TLS-1.3, and no ed25519 cert support, I could
build basic client/server examples at ~ 260 KB.

--- MatrixSSL
  - supports TLS-1.3 but the code of the last public (GPL) version
hasn't changed in the last 6 months.
  - I have not yet succeeded in building static working examples with
a cross compiler. So I don't have ballpark code size figures.

--- Busybox ssl_client
  - some TLS support has been added in the recent busybox trees, based
on MatrixSSLcode. As they say, "enough TLS to allow the busybox wget
applet to retrieve a kernel source" from https://kernel.org/
  - I built the ssl_client applet as a standalone static exe: 71 KB
  - it supports TLS-1.2 with a very limited set of crypto algos. and
_no cert validation_.
  - I tried for fun to retrieve with it the root pages from all the
gemini sites listed on Gus / known hosts:  On a total of 116 sites, it
managed to
get 98 root pages and 18 TLS errors (I lack detailed error causes, but
apparently mostly missing algos, and maybe some unsupported curves for
 ECDH(E).-- not so bad for such a small "client" - but clearly not
enough for real use.

Obviously, a big part of the equation is the evil number of
combinations of ciphers, hashes and key exchange algos.  Any guideline
or best practice document about what ciphers/algos Gemini servers
_should_ minimally support would help immensely!

Again, any suggestion on how to build a small, static SSL client is
more than welcome.Thanks in advance,

Phil

From defdefred at protonmail.com  Wed Jul  1 23:11:10 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 01 Jul 2020 22:11:10 +0000
Subject: Minimal client
In-Reply-To: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
Message-ID: <UXOs-4ENcxT9MTGupw7oKv451IpHkEIbS5JDWpt6o3u4KbXzXk36tc7lZoxXFsIAerHdYF-4uXqtu15sn98ew6yzQnxMAKZjqNR9dbTapq0=@protonmail.com>

netcat ?

freD.

??????? Original Message ???????
On Thursday 2 July 2020 00:06, Phil Leblanc <philanc at gmail.com> wrote:

> Hi all,
>
> I am looking for a solution to build a small, statically linked,
> minimal gemini client. My focus at the moment is to implement the
> basic communication layer (including TLS!): just enough to send a
> request to a gemini host and receive a response.
>
> Has anybody already built such a client? any pointer or suggestion?
>
> Where I stand as of now:
>
> --- I discarded OpenSSL. Bad memories of building small static
> executables a long time ago. Maybe it has improved and I am just
> prejudiced.
>
> --- LibreSSL:
>
> -   not TLS v1.3 yet, but definitely alive and moving there.
> -   easily builds static libraries, but no modular build: I mean I
>     found no way to build libraries/executable with only a limited set of
>     crypto algorithms
>     => executables are large: The openssl command (similar to the
>
>
> OpenSSL one) is 2.5 MB (built on Linux with Musl libc, fully static,
> -Os, stripped). They also include the OpenBSD 'nc' command which
> supports TLS connections - 2 MB (for reference I have a small static
> nc without TLS support which is 50KB)
>
> --- BearSSL
>
> -   very nice code. An impressive feat for a one-man project (Thomas Pornin)
> -   not yet at TLS-1.3. The code looks maintained but I don't know if
>     it is actively developed. I saw no sign of ed25519 cert signing, but
>     may be wrong here.
>
> -   code size: the whole libbearssl.a is ~ 860KB, basic client and
>     server examples are in the 150KB range, which is very nice.
>
>     --- WolfSSL
>
> -   supports TLS-1.3. Is actively maintained by a company targeting
>     embedded systems (but the code is GPL)
>
> -   I don't know yet how to properly build small code, but with a
>     default support for only TLS-1.3, and no ed25519 cert support, I could
>     build basic client/server examples at ~ 260 KB.
>
>     --- MatrixSSL
>
> -   supports TLS-1.3 but the code of the last public (GPL) version
>     hasn't changed in the last 6 months.
>
> -   I have not yet succeeded in building static working examples with
>     a cross compiler. So I don't have ballpark code size figures.
>
>     --- Busybox ssl_client
>
> -   some TLS support has been added in the recent busybox trees, based
>     on MatrixSSLcode. As they say, "enough TLS to allow the busybox wget
>     applet to retrieve a kernel source" from https://kernel.org/
>
> -   I built the ssl_client applet as a standalone static exe: 71 KB
> -   it supports TLS-1.2 with a very limited set of crypto algos. and
>     no cert validation.
>
> -   I tried for fun to retrieve with it the root pages from all the
>     gemini sites listed on Gus / known hosts: On a total of 116 sites, it
>     managed to
>     get 98 root pages and 18 TLS errors (I lack detailed error causes, but
>     apparently mostly missing algos, and maybe some unsupported curves for
>     ECDH(E).-- not so bad for such a small "client" - but clearly not
>     enough for real use.
>
>     Obviously, a big part of the equation is the evil number of
>     combinations of ciphers, hashes and key exchange algos. Any guideline
>     or best practice document about what ciphers/algos Gemini servers
>     should minimally support would help immensely!
>
>     Again, any suggestion on how to build a small, static SSL client is
>     more than welcome.Thanks in advance,
>
>     Phil
>



From philanc at gmail.com  Wed Jul  1 23:22:23 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 1 Jul 2020 22:22:23 +0000
Subject: Minimal client
In-Reply-To: <UXOs-4ENcxT9MTGupw7oKv451IpHkEIbS5JDWpt6o3u4KbXzXk36tc7lZoxXFsIAerHdYF-4uXqtu15sn98ew6yzQnxMAKZjqNR9dbTapq0=@protonmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
 <UXOs-4ENcxT9MTGupw7oKv451IpHkEIbS5JDWpt6o3u4KbXzXk36tc7lZoxXFsIAerHdYF-4uXqtu15sn98ew6yzQnxMAKZjqNR9dbTapq0=@protonmail.com>
Message-ID: <CAOH6EB_O42f8ehgaZKKi1LUSd2-Jtqvxfu7fbQNcbZMW+UmEjw@mail.gmail.com>

On Wed, Jul 1, 2020 at 10:11 PM defdefred <defdefred at protonmail.com> wrote:
>
> netcat ?
>

Yes, something like netcat (or nc, or ncat) -- but with the following
properties:
  - TLS support,
  - it can build as a _small_ _static_ executable (the libressl nc is
at best 2 MB !!),
  - it can be built with a selected set of ciphers/protocols - and not
the whole set,
  - and it allows to retrieve the server cert.

Phil

From hannu.hartikainen+gemini at gmail.com  Thu Jul  2 00:07:31 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Thu, 2 Jul 2020 02:07:31 +0300
Subject: Minimal client
In-Reply-To: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
Message-ID: <CANmFPemkn7KD7JRQjtf8uUVPBdungXDABv=2B9QzObZPtw6PzQ@mail.gmail.com>

On Thu, 2 Jul 2020 at 01:07, Phil Leblanc <philanc at gmail.com> wrote:

> I am looking for a solution to build a _small_, _statically linked_,
> minimal gemini client. My focus at the moment is to implement the
> basic communication layer (including TLS!): just enough to send a
> request to a gemini host and receive a response.
>

Sounds a bit like embedded development. Maybe look at Mbed TLS? (I haven't
tried it.)
https://github.com/ARMmbed/mbedtls

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200702/14cc4b82/attachment-0001.htm>

From philanc at gmail.com  Thu Jul  2 00:18:47 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 1 Jul 2020 23:18:47 +0000
Subject: Minimal client
In-Reply-To: <CANmFPemkn7KD7JRQjtf8uUVPBdungXDABv=2B9QzObZPtw6PzQ@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
 <CANmFPemkn7KD7JRQjtf8uUVPBdungXDABv=2B9QzObZPtw6PzQ@mail.gmail.com>
Message-ID: <CAOH6EB_ay_ckX4Fs1w-r7UF_N28jUCYEkf_OdXG-YmEAq4aeUA@mail.gmail.com>

On Wed, Jul 1, 2020 at 11:07 PM Hannu Hartikainen
<hannu.hartikainen+gemini at gmail.com> wrote:
>
> Sounds a bit like embedded development. Maybe look at Mbed TLS? (I haven't tried it.)
> https://github.com/ARMmbed/mbedtls
>
> -Hannu

I will look into it. Thanks for the pointer.

Phil

From mforney at mforney.org  Thu Jul  2 01:37:36 2020
From: mforney at mforney.org (Michael Forney)
Date: Wed, 1 Jul 2020 17:37:36 -0700
Subject: Minimal client
In-Reply-To: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
Message-ID: <CAGw6cBuQbgRSxnBK7t=zOK5q-2vpHP=C5GGyyF34sR5ko1SfBw@mail.gmail.com>

On 2020-07-01, Phil Leblanc <philanc at gmail.com> wrote:
> --- BearSSL
>   - very nice code. An impressive feat for a one-man project (Thomas
> Pornin)
>   - not yet at TLS-1.3. The code looks maintained but I don't know if
> it is actively developed. I saw no sign of ed25519 cert signing, but
> may be wrong here.
>   - code size: the whole libbearssl.a is ~ 860KB, basic client and
> server examples are in the 150KB range, which is very nice.

Have you looked at the TLS 1.3 page (https://bearssl.org/tls13.html)?
It suggests that support for TLS 1.3 is planned, but there are some
obstacles with Ed25519 that require more memory usage (buffering the
complete certificate) and code size increase. I think it is a little
out of date since RSA/PSS is now implemented in BearSSL, but you're
right that there hasn't been much development for TLS 1.3 in a while.
I'm hopeful that it will eventually be implemented.

So if Ed25519 is what gemini servers are settling on for their
certificates, then BearSSL is probably not a good option until support
is available. Though, ECDSA uses comparable key/signature sizes and I
believe it is fairly widely supported, so I think BearSSL would work
quite well for that.

I'm not sure if there are any existing gemini clients using libtls,
but if there are, you might be interested in
https://git.sr.ht/~mcf/libtls-bearssl. You could get a much smaller
statically linked binary by just linking against libtls-bearssl
instead of libtls from LibreSSL.

-Michael

From philanc at gmail.com  Thu Jul  2 03:29:13 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Thu, 2 Jul 2020 02:29:13 +0000
Subject: Minimal client
In-Reply-To: <CAGw6cBuQbgRSxnBK7t=zOK5q-2vpHP=C5GGyyF34sR5ko1SfBw@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
 <CAGw6cBuQbgRSxnBK7t=zOK5q-2vpHP=C5GGyyF34sR5ko1SfBw@mail.gmail.com>
Message-ID: <CAOH6EB_QMLa=DbzG4n9BbC__d-_D+vS8sDDJsUk-B9XARZh2Kw@mail.gmail.com>

On Thu, Jul 2, 2020 at 12:37 AM Michael Forney <mforney at mforney.org> wrote:
>
> Have you looked at the TLS 1.3 page (https://bearssl.org/tls13.html)?
> It suggests that support for TLS 1.3 is planned, [...]

Thanks! I don't know how I missed this page :-)

>
> I'm not sure if there are any existing gemini clients using libtls,
> but if there are, you might be interested in
> https://git.sr.ht/~mcf/libtls-bearssl. You could get a much smaller
> statically linked binary by just linking against libtls-bearssl
> instead of libtls from LibreSSL.

Your project is very nice! I built your libtls-bearssl library and
then rebuilt the 'nc' client that comes with LibreSSL against your
libtls.a and libbearssl.a.

Just a minor issue:   " undefined reference to `explicit_bzero' ". I
provided it with a quick hack and I could build  the libreSSL 'nc'
with bearssl  - Here are the executable sizes:
   LibreSSL nc  1,976 KB
   The _same_ nc linked against bearssl and your libtls-bearssl  276
KB  -- Wow!! and it works fine! :-)

(both are built static with musl libc, -Os, stripped)

> -Michael

Thanks!

Phil

From defdefred at protonmail.com  Thu Jul  2 10:02:40 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 02 Jul 2020 09:02:40 +0000
Subject: Minimal client
In-Reply-To: <CAOH6EB_O42f8ehgaZKKi1LUSd2-Jtqvxfu7fbQNcbZMW+UmEjw@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
 <UXOs-4ENcxT9MTGupw7oKv451IpHkEIbS5JDWpt6o3u4KbXzXk36tc7lZoxXFsIAerHdYF-4uXqtu15sn98ew6yzQnxMAKZjqNR9dbTapq0=@protonmail.com>
 <CAOH6EB_O42f8ehgaZKKi1LUSd2-Jtqvxfu7fbQNcbZMW+UmEjw@mail.gmail.com>
Message-ID: <QJlzmYEsl8COcut-OQSlPVZJY75ojTtQMTkpCboPbI_TzBP1eMvTPJgz0YsvHe003dN_4XAqjyDfjomS4w9m76z-p09BZHndIG_qI3td-KI=@protonmail.com>

netcat is supporting tls :-)
You can make a minimal client and a minimal server with it...

freD.

??????? Original Message ???????
On Thursday 2 July 2020 00:22, Phil Leblanc <philanc at gmail.com> wrote:

> On Wed, Jul 1, 2020 at 10:11 PM defdefred defdefred at protonmail.com wrote:
>
> > netcat ?
>
> Yes, something like netcat (or nc, or ncat) -- but with the following
> properties:
>
> -   TLS support,
> -   it can build as a small static executable (the libressl nc is
>     at best 2 MB !!),
>
> -   it can be built with a selected set of ciphers/protocols - and not
>     the whole set,
>
> -   and it allows to retrieve the server cert.
>
>     Phil
>



From luke at marmaladefoo.com  Thu Jul  2 12:20:58 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 02 Jul 2020 12:20:58 +0100
Subject: [ANN] GMI to Atom converter CGI script
Message-ID: <5EFDC31A.40001@marmaladefoo.com>

Hi All

I've created a gemini server CGI script that automatically serves an 
Atom XML feed based on a live gemlog/blog GMI file.

So you can write your Gemlog file in the normal way and the Atom feed is 
automatically up to date. This is a nice solution for users who aren't 
technically able to, or don't want the hassle of generating the content 
form the command line

There is a write up here:

   
gemini://gemini.marmaladefoo.com/blog/2-Jul-2020_GMI_based_feed_generator.gmi

and you can download the software from Github:

   https://github.com/LukeEmmet/GMIToAtomFeed

It supports per user feeds on the same machine if desired.

Its written in Rebol, but you could easily adapt it other languages if 
you want

Best wishes

  - Luke


From tcb913 at gmail.com  Thu Jul  2 17:25:25 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Thu, 2 Jul 2020 12:25:25 -0400
Subject: Gemini Text Markup Language specification
In-Reply-To: <e09f2119-0a1f-c2cc-519d-a5fc94862d8c@tilde.pink>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <006b01d64f25$2d05d6f0$871184d0$@tahoma.com>
 <e09f2119-0a1f-c2cc-519d-a5fc94862d8c@tilde.pink>
Message-ID: <e5fc12f9-8287-2590-bbfc-6087a36294e3@gmail.com>

I think this was sent to me by mistake.

Terry Brennan


On 07/01/2020 11:12 AM, Tiwesdaeg Twohands wrote:
> Welcome to tilde.pink! I hope you brought your shades. Your account is
> now activated with the username evn. SSH login is via key only.
>
> We do not offer web services. We use geomyidae instead as our
> gopher server. It uses .gph files, instead of gophermaps. Default is
> index.gph. A public_gopher folder has been created for you with a sample
> index.gph file. We've also added a gemini server. Gemini is a gopher
> like protocol that is currently in development. It is being designed to
> fix some of the drawbacks of gopher, but without having all the issues
> of html. You can experiment with gemini by editing and adding things to
> your public_gemini folder. There is some initial documentation linked
> on the main page.
>
> Please note, the server is in its early stages and very bare bones.
> Please let me know if something is missing that you are used to using
> in a shell. Also, this is a NetBSD installation. There are many things
> different from your normal linux system including your default shell
> which is /bin/sh instead of bash. Bash is available if you would like
> to change it.
>
> If you are interested in talking to other ~pink users or need help,
> please join us via irc on #pink hosted on the irc network tilde.chat
>
> On 6/30/20 4:26 PM, traderbeckola at tahoma.com wrote:
>> Thanks!
>>
>> -----Original Message-----
>> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Petite 
>> Abeille
>> Sent: Tuesday, June 30, 2020 11:52 AM
>> To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>> Subject: Re: Gemini Text Markup Language specification
>>
>>
>>
>>> On Jun 30, 2020, at 17:49, traderbeckola at tahoma.com wrote:
>>>
>>> Could someone please point me in the direction of the markup 
>>> language spec for Gemini? I understand it is a small subset of html, 
>>> but wasn?t able to find it in the list archives or online at either 
>>> the http:// or gemini:// sites.
>>
>>
>> gemini://gemini.circumlunar.space/docs/specification.gmi
>> https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/specification.gmi 
>>
>>


From solderpunk at SDF.ORG  Thu Jul  2 17:52:51 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 2 Jul 2020 16:52:51 +0000
Subject: Gemini Text Markup Language specification
In-Reply-To: <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
Message-ID: <20200702165251.GB10251@SDF.ORG>

On Tue, Jun 30, 2020 at 05:52:18PM +0200, Petite Abeille wrote:
> 
> > On Jun 30, 2020, at 17:49, traderbeckola at tahoma.com wrote:
> > 
> > Could someone please point me in the direction of the markup language spec for Gemini? I understand it is a small subset of html, but wasn?t able to find it in the list archives or online at either the http:// or gemini:// sites.
> 
> 
> gemini://gemini.circumlunar.space/docs/specification.gmi
> https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/specification.gmi

The protocol specification is, of course, the authoritative place for
the final word on these things.  But it's been pointed out in the past
that people really shouldn't need to read through the entire spec just
in order to know how to write a document, which is entirely true.  So,
behold!

gemini://gemini.circumlunar.space/docs/gemtext.gmi
gemini://gemini.circumlunar.space/docs/cheatsheet.gmi

Two new resources to help beginners to get up and writing quickly.
Feedback welcome!

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Thu Jul  2 18:27:22 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Thu, 2 Jul 2020 17:27:22 +0000
Subject: (A little) Ambiguity in the response header specification
In-Reply-To: <5ae0a489-7804-8567-5246-960a618bef80@disroot.org>
References: <5ae0a489-7804-8567-5246-960a618bef80@disroot.org>
Message-ID: <20200702172722.GC10251@SDF.ORG>

On Tue, Jun 30, 2020 at 10:35:08PM +0200, Baschdel wrote:
 
> For this reason I suggest to clarify by adding a line that states that
> <SPACE> refers to the ascii character 0x20 (because that is used by almost
> all servers already) (or if we want to allow tabs clearly specify that)

I have clarified this just now - sorry for forgetting to respond to your
earlier message about this on Mastodon!

Cheers,
Solderpunk

From luke at marmaladefoo.com  Thu Jul  2 23:23:33 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 02 Jul 2020 23:23:33 +0100
Subject: Gemini Text Markup Language specification
In-Reply-To: <20200702165251.GB10251@SDF.ORG>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <20200702165251.GB10251@SDF.ORG>
Message-ID: <5EFE5E65.9080803@marmaladefoo.com>

On 02-Jul-2020 17:52, solderpunk wrote:
> gemini://gemini.circumlunar.space/docs/gemtext.gmi
> gemini://gemini.circumlunar.space/docs/cheatsheet.gmi
>
> Two new resources to help beginners to get up and writing quickly.
> Feedback welcome!

That looks good, a minor comment - I think you have a broken link on the 
page:

gemini://gemini.circumlunar.space/docs/gemtext.gmi

it points to

gemini://gemini.circumlunar.space/docs/cheetsheet.gmi

(note mis-spelling of cheatsheet).

Best Wishes

  - Luke

From gemini at ajtjp.com  Fri Jul  3 05:01:09 2020
From: gemini at ajtjp.com (Andrew J)
Date: Fri, 03 Jul 2020 00:01:09 -0400
Subject: [ANN] Titan - a Console-based Browser Written in Java
Message-ID: <0e3fe997-c55d-4294-9a69-0dec571780cc@www.fastmail.com>

Hello!

I discovered Gemini a little over a month ago, and like many others, decided to
write my own client. It's been a fun project, and it's now been a few weeks since
it reached the point where I'm spending more time browsing Gemini capsules
than writing it. Thus, I figured I should share it in case others found it useful.

Notable features include a vim-inspired interface, a focus on features of
convenience for browsing such as search within a page, and cross-platform
support, including making it relatively easy for non-developers to run it
through releasing binaries.

I invite you to visit its home page at
https://ajtjp.com/software/titan/titan.html and give it a try. For now, I've
left its home page on the WWW, so that users without a Gemini browser can
discover and download it more easily. I've set up a couple mailing lists on
SourceHut (linked from its home page), so if you are interested in following
Titan, you can subscribe there, as I don't want to spam this thread.

I've also recently set up a Gemini capsule at gemini://ajtjp.com, running
Gemserv. There isn't much content there yet, compared to my Gopher or HTTPS
sites, but I will likely be adding more in the future.

- Andrew J

P.S. It's been pretty cool reading various Gemlogs over the past month. I
should probably reach out in response occasionally; there are several capsules
where I've seen enough updates to start recognizing them. Doubly so when I've
realized I've also browsed their Gopher hole in the past!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200703/4de1a1a2/attachment-0001.htm>

From sean at conman.org  Fri Jul  3 06:42:10 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 3 Jul 2020 01:42:10 -0400
Subject: [ANN] Titan - a Console-based Browser Written in Java
In-Reply-To: <0e3fe997-c55d-4294-9a69-0dec571780cc@www.fastmail.com>
References: <0e3fe997-c55d-4294-9a69-0dec571780cc@www.fastmail.com>
Message-ID: <20200703054210.GR19717@brevard.conman.org>

It was thus said that the Great Andrew J once stated:
> Hello!

  Greetings!

> I discovered Gemini a little over a month ago, and like many others, decided to
> write my own client. It's been a fun project, and it's now been a few weeks since
> it reached the point where I'm spending more time browsing Gemini capsules
> than writing it. Thus, I figured I should share it in case others found it useful.

  I appreciate the effort, but I feel the need to tell you that the name
Titan has already been used with a Gemini related project---a upload
protocol:

	https://communitywiki.org/wiki/Titan

and it has been referenced on the mailing list:

	https://lists.orbitalfox.eu/archives/gemini/2020/001632.html

  Just thought you should know.  But other than that, it looks nice.

  -spc


From pwarren at pwarren.id.au  Fri Jul  3 10:46:50 2020
From: pwarren at pwarren.id.au (Paul Warren)
Date: Fri, 3 Jul 2020 19:46:50 +1000
Subject: [ANN] deedum browser update
In-Reply-To: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
Message-ID: <c59a6a9c-dc16-6426-3302-29cfe5ee81ca@pwarren.id.au>



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1003 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200703/1d2298b0/attachment.sig>

From lel at envs.net  Fri Jul  3 11:17:14 2020
From: lel at envs.net (lel)
Date: Fri, 3 Jul 2020 06:17:14 -0400
Subject: [ANN] Titan - a Console-based Browser Written in Java
In-Reply-To: <20200703054210.GR19717@brevard.conman.org>
References: <0e3fe997-c55d-4294-9a69-0dec571780cc@www.fastmail.com>
 <20200703054210.GR19717@brevard.conman.org>
Message-ID: <20200703101714.GA14218@n1.lan>

On Fri, Jul 03, 2020 at 01:42:10AM -0400, Sean Conner wrote:
> It was thus said that the Great Andrew J once stated:
> > Hello!
> 
>   Greetings!
> 
> > I discovered Gemini a little over a month ago, and like many others, decided to
> > write my own client. It's been a fun project, and it's now been a few weeks since
> > it reached the point where I'm spending more time browsing Gemini capsules
> > than writing it. Thus, I figured I should share it in case others found it useful.
> 
>   I appreciate the effort, but I feel the need to tell you that the name
> Titan has already been used with a Gemini related project---a upload
> protocol:
> 
> 	https://communitywiki.org/wiki/Titan
> 
> and it has been referenced on the mailing list:
> 
> 	https://lists.orbitalfox.eu/archives/gemini/2020/001632.html
> 
>   Just thought you should know.  But other than that, it looks nice.
> 
>   -spc
> 

It's funny that we've reached the point where rocketry-related names for gemini projects
are beginning to collide. That would seem to say something about both the number of
projects in gemini and the lack of rocketry-related names. I myself used the name
titan coincidentally also for the name of a java gemini client in like March as the final
project for a CS course, although I named it that not only for the rocket but also to
bully Java for being big and bad and eating its children and deserving of getting
banished to Tartarus (using Java was required in the final project so I was semi-salty).

My actual question (to the list, not just you) is this: has any known site implemented
Titan support besides CommunityWiki, and has any client implemented titan support
besides Alex Schroeder's titan bash function? Last thing I knew, Titan was being
discussed on this list but no one had formalized anything about it yet, and even the name
was just someone's thrown-in idea that solderpunk said was better than gemini+submit and
you had said you'd keep in mind. After that if my memory can be trusted the thread flowed
into streaming discussion. Is there somewhere else (an IRC channel, another mailing list,
etc) where Titan development has been discussed?

Thanks,

From solderpunk at SDF.ORG  Fri Jul  3 11:52:48 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Fri, 3 Jul 2020 10:52:48 +0000
Subject: Gemini Text Markup Language specification
In-Reply-To: <5EFE5E65.9080803@marmaladefoo.com>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <20200702165251.GB10251@SDF.ORG>
 <5EFE5E65.9080803@marmaladefoo.com>
Message-ID: <20200703105248.GA11999@SDF.ORG>

On Thu, Jul 02, 2020 at 11:23:33PM +0100, Luke Emmet wrote:
 
> That looks good, a minor comment - I think you have a broken link on the
> page:
> 
> gemini://gemini.circumlunar.space/docs/gemtext.gmi
> 
> it points to
> 
> gemini://gemini.circumlunar.space/docs/cheetsheet.gmi
> 
> (note mis-spelling of cheatsheet).

Thank you, it's now fixed!

Cheers,
Solderpunk

From tcb913 at gmail.com  Fri Jul  3 15:57:39 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Fri, 3 Jul 2020 10:57:39 -0400
Subject: Gemini Text Markup Language specification
In-Reply-To: <20200703105248.GA11999@SDF.ORG>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <20200702165251.GB10251@SDF.ORG> <5EFE5E65.9080803@marmaladefoo.com>
 <20200703105248.GA11999@SDF.ORG>
Message-ID: <43362a39-c939-971e-6280-d1ea36f3764a@gmail.com>

Hmm. Trying to check this out today with bombadillo. Get an error message:

"No matching certificate was found for 'gemini.circumlunar.space' "

Never got this before. Thought you might like to know.

tb


On 07/03/2020 06:52 AM, solderpunk wrote:
> On Thu, Jul 02, 2020 at 11:23:33PM +0100, Luke Emmet wrote:
>   
>> That looks good, a minor comment - I think you have a broken link on the
>> page:
>>
>> gemini://gemini.circumlunar.space/docs/gemtext.gmi
>>
>> it points to
>>
>> gemini://gemini.circumlunar.space/docs/cheetsheet.gmi
>>
>> (note mis-spelling of cheatsheet).
> Thank you, it's now fixed!
>
> Cheers,
> Solderpunk


From me at case.codes  Fri Jul  3 16:19:16 2020
From: me at case.codes (Case Nelson)
Date: Fri, 3 Jul 2020 15:19:16 +0000 (UTC)
Subject: [ANN] deedum browser update
In-Reply-To: <c59a6a9c-dc16-6426-3302-29cfe5ee81ca@pwarren.id.au>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <c59a6a9c-dc16-6426-3302-29cfe5ee81ca@pwarren.id.au>
Message-ID: <e705e943-66db-41db-ab40-c78c187a179b@case.codes>

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


From colecmac at protonmail.com  Fri Jul  3 21:51:26 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 03 Jul 2020 20:51:26 +0000
Subject: [ANN] Titan - a Console-based Browser Written in Java
In-Reply-To: <20200703101714.GA14218@n1.lan>
References: <0e3fe997-c55d-4294-9a69-0dec571780cc@www.fastmail.com>
 <20200703054210.GR19717@brevard.conman.org> <20200703101714.GA14218@n1.lan>
Message-ID: <oNvmt03UaEPKevslmueIhqR8hInHD2rmpfF35RoAXQ0RV1eR3Hj345IvOVZZNgYJijqj-bwiYORqrzhIdYsJDu77O6cm_iNNihIZCSMtnpU=@protonmail.com>

lel wrote:
> [...] but no one had formalized anything about it yet [...]

This, and the rest of the paragraph, is correct as far as I know. I'd like to see
more discussion around the gemini write / titan protocol, so that we can get something
that people can agree on, and clients and servers can actually implement.

I've talked kensanata / Alex, who created CommunityWiki on IRC, and we've discussed how
he was experimenting and pushing things ahead, but I don't think I'm alone in saying that
there should definitely be more discussion, an official spec, Solderpunk chiming in, etc.

Don't get me wrong, I'm happy that there's real code and stuff that works.

> Is there somewhere else (an IRC channel, another mailing list,
> etc) where Titan development has been discussed?

There's #gemini on the tilde.chat IRC, some things have been discussed there, but
anything big will probably happen here.

Cheers,
makeworld

From mforney at mforney.org  Fri Jul  3 21:59:13 2020
From: mforney at mforney.org (Michael Forney)
Date: Fri, 3 Jul 2020 13:59:13 -0700
Subject: Minimal client
In-Reply-To: <CAOH6EB_QMLa=DbzG4n9BbC__d-_D+vS8sDDJsUk-B9XARZh2Kw@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
 <CAGw6cBuQbgRSxnBK7t=zOK5q-2vpHP=C5GGyyF34sR5ko1SfBw@mail.gmail.com>
 <CAOH6EB_QMLa=DbzG4n9BbC__d-_D+vS8sDDJsUk-B9XARZh2Kw@mail.gmail.com>
Message-ID: <CAGw6cBuD0z1v_JHB=ZzvEQP=3UOzAXkY8LkGDzKf0N9oEposnA@mail.gmail.com>

On 2020-07-01, Phil Leblanc <philanc at gmail.com> wrote:
> Your project is very nice!

Thanks :)

> I built your libtls-bearssl library and
> then rebuilt the 'nc' client that comes with LibreSSL against your
> libtls.a and libbearssl.a.
>
> Just a minor issue:   " undefined reference to `explicit_bzero' ".

Are you using an old version of musl? It should be available since
1.1.20. I didn't add a compat implementation since it is pretty widely
supported (glibc, musl, BSDs).

From sean at conman.org  Fri Jul  3 23:07:45 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 3 Jul 2020 18:07:45 -0400
Subject: [ANN] Titan - a Console-based Browser Written in Java
In-Reply-To: <oNvmt03UaEPKevslmueIhqR8hInHD2rmpfF35RoAXQ0RV1eR3Hj345IvOVZZNgYJijqj-bwiYORqrzhIdYsJDu77O6cm_iNNihIZCSMtnpU=@protonmail.com>
References: <0e3fe997-c55d-4294-9a69-0dec571780cc@www.fastmail.com>
 <20200703054210.GR19717@brevard.conman.org> <20200703101714.GA14218@n1.lan>
 <oNvmt03UaEPKevslmueIhqR8hInHD2rmpfF35RoAXQ0RV1eR3Hj345IvOVZZNgYJijqj-bwiYORqrzhIdYsJDu77O6cm_iNNihIZCSMtnpU=@protonmail.com>
Message-ID: <20200703220745.GS19717@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> lel wrote:
> > [...] but no one had formalized anything about it yet [...]
> 
> This, and the rest of the paragraph, is correct as far as I know. I'd like to see
> more discussion around the gemini write / titan protocol, so that we can get something
> that people can agree on, and clients and servers can actually implement.
> 
> I've talked kensanata / Alex, who created CommunityWiki on IRC, and we've discussed how
> he was experimenting and pushing things ahead, but I don't think I'm alone in saying that
> there should definitely be more discussion, an official spec, Solderpunk chiming in, etc.

  Not to put words into solderpunk's mouth, but I suspect he'd stay out of
this conversation and as long as it isn't pushed as something that's
mandatory, he'd be fine with this.

  As per more discussion, Alex is basing his work off this message to the
list:

	https://lists.orbitalfox.eu/archives/gemini/2020/001657.html

with the slight change in that the path parameters are all separated by a
';', not a leading ';' and '&' for the others, which, okay, I'm fine with
it.  So to update it a bit:

	titan://example.com/post-handler/endpoint?size=1234&mime=text/plain
	titan://example.com/path/to/new/resource;size=1234;mime=text/plain
	titan://example.com/path/to/remove;size=0

  The logic goes something like this [2]:

	if the request has a query, it's an upload of data---accept data.
	if the request has no query, and the path parameter (marked by ';')
		doesn't exist---error.
	if the request has no query, and the path parameter exists:
		if size==0, delete the resource
		if size>0, accept data and make the resource available.

  The 'size' parameter is mandatory; the 'mime' parameter is mandatory for
non-delete requests, there may be other parameters that are specific to a
host or implementation.

  I was also thinking that a request like:

	titan://example.com/path/to/resource

with no query string or path parameters, *might* return meta information
about the resource, like:

	size			(mandatory)
	MIME type		(mandatory)
	creation time		(optional)
	modification time	(mandatory)
	author			(optional)
	version			(optional)
	etc.			(other, optional fields)

  Just an idea.

> Don't get me wrong, I'm happy that there's real code and stuff that works.

  Same here.

  -spc


From alex at gnu.org  Fri Jul  3 23:16:15 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sat, 04 Jul 2020 00:16:15 +0200
Subject: Titan, the proposed upload protocol for Gemini
Message-ID: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>

Hi all
People on the IRC channel asked me to send an email to the list
regarding the Titan protocol I've been using for my Gemini Wiki
project.

Background

I'm really interested in wikis. They seem to me to be the simplest form
of collaboration in text. Simple both in because you don't need a lot
of technology to make it work, and also simple because all of the
structure, all of the processes, are things that the software doesn't
provide: it's up to people to organize themselves. I wrote a bit more
about it on my site, if you're interested.
https://alexschroeder.ch/wiki/2020-06-15_Why_Wiki%e2%80%bd
gemini://alexschroeder.ch/2020-06-15_Why_Wiki%e2%80%bd

At first, I proposed something I called Gemini+Write, and implemented
it for my site, and for a Gemini Client I was using. It was inspired by
my idea for Gopher Wiki. I know, I know. I keep bashing on that wiki
idea. Anyway, the idea is simple: to *read* from a site, you open a
connection and send a selector. Then, on subsequent lines, you send
more stuff like MIME-type, file-size, password, and so on. It wasn't
pretty.
https://alexschroeder.ch/wiki/2017-12-30_Gopher_Wiki
gemini://alexschroeder.ch/2017-12-30_Gopher_Wiki
https://alexschroeder.ch/wiki/2020-06-04_Gemini_Upload
gemini://alexschroeder.ch/2020-06-04_Gemini_Upload

In any case, Sean Conner picked up on the idea, and started a long
thread back in June. It went a lot further than what I had in mind,
mimicking HTTP methods (GET, PUT, POST), discussed the differences
between PUT and POST, and some form of authentication that used client
certificates to allow users to edit just their pages.
https://lists.orbitalfox.eu/archives/gemini/2020/001611.html
https://lists.orbitalfox.eu/archives/gemini/2020/001657.html

Matthew Greybosch proposed to name this protocol "Titan" in one of the
replies to Sean Conner's post.
https://lists.orbitalfox.eu/archives/gemini/2020/001615.html

There was some resistance to the idea, and my mail setup was apparently
causing some users a bit of grief, and for both of these reasons I
didn't get involved in the discussion. I wanted to get a Gemini Wiki
working and that was all I cared about.

Titan

Sean Conner's Titan proposal had some ideas I liked and some I didn't
care for. The shortest summary is the following, from the second thread
link of his:

  titan://example.com/post-handler/endpoint?size=1234&mime=text/plain
  titan://example.com/path/to/new/resource;size=1234&mime=text/plain
  titan://example.com/path/to/remove;size=0

  The logic goes something like this [2]:

  if the request has a query, it's an upload of data---accept data.
  if the request has no query, and the path parameter (marked by ';')
    doesn't exist---error.
  if the request has no query, and the path parameter exists:
    if size==0, delete the resource
    if size>0, accept data and make the resource available.

I decided that what I really needed was just the second example he
provided:

titan://example.com/path/to/new/resource;size=1234&mime=text/plain

I also needed some form of authorization (are you allowed to edit the
site) and I didn't really care for authentication (are you the person
you claim to be). I imagined my Gemini Wiki working without necessarily
identifying users. I needed some sort of token, a kind of password. My
Oddmuse wiki uses this system since 2003: there are editor and admin
passwords, and knowing one of these passwords allows you to do things
reserved to editors and admins, but these passwords aren't tied to
usernames. They're basically just tokens. You can pass them to a friend
and say: here, join us!

Thus, for my needs I need the following:

titan://example.com/path/to/new/resource;size=1234;mime=text/plain;toke
n=hello

Some people used to web URIs might be wondering: where is the question
mark between path and query? The point is that this isn't a query. If
you look at the URI RFC 3986 section 3.3, you'll see what I mean.

"URI producing applications often use the reserved characters allowed
in a segment to delimit scheme-specific or
dereference-handler-specific subcomponents. For example, the semicolon
(";") and equals ("=") reserved characters are often used to delimit
parameters and parameter values applicable to that segment. The comma
(",") reserved character is often used for similar purposes. For
example, one URI producer might use a segment such as "name;v=1.1" to
indicate a reference to version 1.1 of "name", whereas another might
use a segment such as "name,1.1" to indicate the same. Parameter types
may be defined by scheme-specific semantics, but in most cases the
syntax of a parameter is specific to the implementation of the URI's
dereferencing algorithm."
https://tools.ietf.org/html/rfc3986#section-3.3

So that's how I think about it. Let's look at this example again:

titan://example.com/path/to/new/resource;size=1234;mime=text/plain;toke
n=hello

We want to create a new revision of "resource" and the necessary
parameters, as defined by the Titan protocol, are size, MIME-type, and
token.

Now, you might wonder: why size? The server needs to know when the
transmission of the client ends. Remember, if connectivity is bad,
content can arrive in chunks interspersed with silence. Is the client
done? In text based transmissions, we have more options. A Ctrl-D might
be used to indicate the end-of-file (EOF). In your ASCII man page it
might say "EOT (end of transmission)". In very old tools like Berkley
mail you'd end your letter with a single dot on a line. The Gopher spec
also says that a single dot on a line ends the transmission. All of
these solutions won't work when we're talking about binary files,
however. And yes, I want a wiki where people can upload images, or
audio files, or videos, PDF files. Therefore, no particular byte or
pattern can be used. We need to tell the server how many bytes to
expect, and then the server reads exactly that many bytes, with a
timeout in case the transmission just isn't going to work.

You might also wonder: why MIME-type? Can't we just rely on file name
extensions? I guess we could. But why not use MIME-types? I've gotten
used to them. My wiki serves images called "foo" and tells your browser
via the MIME-type that it's an image/png. It allows my wiki to store
this MIME-type and serve it back in a response when clients request a
file. Otherwise I'd have to guess. I've had unhappy experiences with
/etc/mailcap files. All the programming languages do "something",
merging system mailcap files with user mailcap files and programming
language libary mailcap files, and mailcap files so much more than just
an association of file name extensions and MIME-types. They're a
nightmare. Compared to that complexity (which is often invisible to
developers, granted), I find explicit MIME-types easier to deal with.

Upload

OK, so now we've talked about the request: The client sends
titan://example.com/path/to/new/resource;size=1234;mime=text/plain;toke
n=hello followed by the CR LF sequence we all know, and then it sends
the 1234 bytes it promised to send. That's it.

Now, the client-server reaction can be a bit tricky if you're writing a
client: how do you handle an error message after the first line?
Because there will be errors. My wiki has errors for resources that
aren't editable, sizes that exceed the max size I'm willing to accept,
MIME-types I'm not willing to accept, and tokens that are not correct.
There might be more. I'm using 59 error codes for them all. I know that
Baschdel has been arguing for better error codes. The Baschdel proposal
argued for special error codes: ES for wrong size, EM for wrong MIME
type, and E_ for whatever else. Baschdel also argued that it would be
nice if a server replied with WR to say that it will in fact accept the
upload. I confess, I didn't really care for that and decided to write a
very simple implementation.
https://alexschroeder.ch/wiki/Baschdels_spin_on_Gemini_uploading
gemini://alexschroeder.ch/Baschdels_spin_on_Gemini_uploading

Request for Comments (RFC)

So there you have it. Uploading! Titan! ????

What do you think?

I'd love to see more clients supporting it. I have two independent
implementations to show how it works, both for servers and clients,
four in total:

My wiki uses a server code that interfaces with the underlying Oddmuse
wiki engine to edit pages.
https://oddmuse.org/wiki/Gemini_Server
gemini://alexschroeder.ch/

My Gemini Wiki uses stand-alone code to just serve .gmi files as a
wiki, allowing users to create new ones and to edit existing ones. Note
that it is hosted on the same domain, but on a different port.
https://alexschroeder.ch/cgit/gemini-wiki/about/
gemini://alexschroeder.ch:1968/

My two Bash functions "gemini" and "titan" allow a super simple
interaction with Gemini (for reading) and Titan (for writing).
https://alexschroeder.ch/cgit/gemini-titan/about/

I also love Emacs and so I wrote some code that allows me to edit wiki
pages from Elpher.
https://alexschroeder.ch/cgit/gemini-write/about/

Anyway, let me know what you think. Let me know what you'd like to
implement for your servers and clients and what you'd need to add or
drop from this proposal.

Here's what I can see:

- the size parameter can be made optional if you only care about text
uploads
- the MIME-type can be made optional if you only care about Gemtext
- the token can be made optional if you want to rely on client
certificates

What else?

Hope to hear from you all,
Alex



From philanc at gmail.com  Sat Jul  4 01:17:56 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Sat, 4 Jul 2020 00:17:56 +0000
Subject: Minimal client
In-Reply-To: <CAGw6cBuD0z1v_JHB=ZzvEQP=3UOzAXkY8LkGDzKf0N9oEposnA@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
 <CAGw6cBuQbgRSxnBK7t=zOK5q-2vpHP=C5GGyyF34sR5ko1SfBw@mail.gmail.com>
 <CAOH6EB_QMLa=DbzG4n9BbC__d-_D+vS8sDDJsUk-B9XARZh2Kw@mail.gmail.com>
 <CAGw6cBuD0z1v_JHB=ZzvEQP=3UOzAXkY8LkGDzKf0N9oEposnA@mail.gmail.com>
Message-ID: <CAOH6EB9Pe89-s5rpofVkz8iHUk3eyJXBgYK3N_iaewZQgKo9qA@mail.gmail.com>

On Fri, Jul 3, 2020 at 8:59 PM Michael Forney <mforney at mforney.org> wrote:
>
> > Just a minor issue:   " undefined reference to `explicit_bzero' ".
>
> Are you using an old version of musl? It should be available since
> 1.1.20. I didn't add a compat implementation since it is pretty widely
> supported (glibc, musl, BSDs).

You are absolutely right. On  this PC, I was still using 1.1.18. Time
to update :-)

Thanks for the head-up!

Phil

From alex at gnu.org  Sat Jul  4 10:09:18 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sat, 04 Jul 2020 11:09:18 +0200
Subject: Titan, the proposed upload protocol for Gemini
In-Reply-To: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>
References: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>
Message-ID: <008debb3d160ed6a38387d28abf88076e9f436ae.camel@gnu.org>

Upon reading my mail the next day I'd like to add a few points.
https://lists.orbitalfox.eu/archives/gemini/2020/002034.html


Titan, the name

I don't mind lel's Java client being called "Titan". After all, there
are many things that are called Titan ? and Apache also named their
webserver httpd. And, like I said, originally I called the protocol
gemini+write... So, I don't know? I like the name Titan, of course. ?


gnutls-cli

Here's an example of me updating a page with the content of test.txt
using gnutls-cli:

(sleep 1; \
 echo "titan://alexschroeder.ch:1968/raw/Test;mime=text/plain;size="`wc
--bytes < test.txt`";token=hello"; \
 cat test.txt) | \
 gnutls-cli --insecure localhost:1965

I'm using --insecure because of the self-signed certificate, and I'm
using sleep 1 because gnutls-cli (at least on my system) isn't
immediately ready to accept ouput.

The drawback with this solution is that there's plenty of gnuttls-cli
info shown that you don't really care about.


openssl

Here's an example of me updating a page with the content of test.txt
using openssl:

echo "titan://alexschroeder.ch:1968/raw/Test;mime=text/plain;size="`wc
--bytes < test.txt`";token=hello" \
  | cat - test.txt | openssl s_client --quiet --connect
alexschroeder.ch:1968 2>/dev/null

Here I can use the --quiet flag to reduce openssl's output, and as the
rest is printed on stderr I can redirect stderr to /dev/null in order
to make the output really quiet.


Gemini Wiki on the web

The Gemini Wiki also serves HTTP (although it's an extremely simple
HTTP server: no content negotiation). That's why you can visit
gemini://alexschroeder.ch:1968 on the web using 
https://alexschroeder.ch:1968 ? Gemini Wiki installations just have to
make sure to use those Let's Encrypt certificates and not their self-
signed ones because browsers are really picky and display all sorts of
warnings. Gemini Wiki only serves the web as secondary citizen. There
are no HTML forms to edit pages from the web. That only works using the
Titan protocol.


Cheers
Alex


From lel at envs.net  Sat Jul  4 10:24:55 2020
From: lel at envs.net (lel)
Date: Sat, 4 Jul 2020 05:24:55 -0400
Subject: Titan, the proposed upload protocol for Gemini
In-Reply-To: <008debb3d160ed6a38387d28abf88076e9f436ae.camel@gnu.org>
References: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>
 <008debb3d160ed6a38387d28abf88076e9f436ae.camel@gnu.org>
Message-ID: <20200704092232.GA6314@c-s>

On Sat, Jul 04, 2020 at 11:09:18AM +0200, Alex Schroeder wrote:
> I don't mind lel's Java client being called "Titan". After all, there
lol I'm sincerely hoping mine is never found by anyone,
but Andrew J's looks polished and written with love!

best,
lel

From natpen at natpen.net  Sat Jul  4 12:49:32 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sat, 4 Jul 2020 07:49:32 -0400
Subject: GUS, backlinks, and Replies in Geminispace
Message-ID: <20200704114932.GA284887@goldfish.localdomain>

Hi all,

In service of some recent discussion about replies in Geminispace [0]
[1] [2], I wanted to share a bit about a new feature on GUS.
Specifically, backlinks. It's live, you can go try it out right now if
you want [a], and I think it provides one possible solution to finding
replies to posts in Geminispace.

First, what are backlinks? Take, for example, page A. Now let's say
there are three pages B, C, and D, all of which link to page A. In
this situation we define B, C, and D as A's backlinks.

I think this could be interesting information in a general sense, if
you as a content author simply want to know what pages link to you.
But since most (I think?) reply-type posts link to the original post
they're replying to, that means they will get surfaced by this
functionality too. So, if you want to see replies to post "foo",
simply look at the backlinks for that page on GUS.

I have some ideas for functionality that could be built on top of this
feature, if it sticks around. For example, maybe there's finally a use
for certificate auth on GUS, so folks could create "accounts," specify
URLs and domains that they care about, and get some sort of
notification when new backlinks are discovered for those URLs or
domains.

There are some definite pros and cons to this solution to the "replies
in Geminispace" problem, but in the spirit of experimentation, I've
built a quick version of it and put it out there for some
experimentation. Please let me your thoughts!

[0] gemini://gemini.circumlunar.space/~solderpunk/cornedbeef/replies-in-geminispace.gmi
[1] gemini://carcosa.net/journal/20200529-some-replies.gmi
[2] gemini://gemini.circumlunar.space/~shufei/phlog/20200529-Reply-ProstheticConscience.gmi

[a] documentation for the feature is at gemini://gus.guru/about - but
the TLDR is: perform a GUS search, click the link to enter verbose
mode, and now you should see links to backlinks pages for each result
that has backlinks.

From sir at cmpwn.com  Sat Jul  4 14:44:16 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sat, 04 Jul 2020 09:44:16 -0400
Subject: Ditching mandatory TLS
Message-ID: <C3XVUNF1XAXS.274U88O0BVZTN@homura>

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)

From felix at masterq32.de  Sat Jul  4 15:09:15 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Sat, 4 Jul 2020 16:09:15 +0200
Subject: Ditching mandatory TLS
In-Reply-To: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
References: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
Message-ID: <867198d5-c92e-e81b-fef6-509e986087e7@masterq32.de>

Hey Drew,

> Unpopular opinion time: Gemini should not have mandatory TLS.

We already had the discussion. Please see the ML-Thread on "Mercury",
especially solderpunks answers there.

See here: gemini://rawtext.club/~sloum/geminilist/001927.gmi

I think a lot of people on the list here are tired of seeing the same
mail thread appearing again and again

Regards
- xq

From colecmac at protonmail.com  Sat Jul  4 16:01:32 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 04 Jul 2020 15:01:32 +0000
Subject: Ditching mandatory TLS
In-Reply-To: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
References: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
Message-ID: <8PpmIUmcu3jhmbtXQwG_ipsgKWSnjjm3tyrIVugEKVSgTaSaT5TZBjTPCIDI1o18OzWADeAan6Ornyq6ZKqSMQvV4U-F3AazBTCy6E-3JME=@protonmail.com>

Hello! I'm in favour of mandatory TLS for Gemini, so let me take a stab
at this.


> -   TLS is not conveinent for local development
> -   TLS is inherently dependent on a centralized oligarchy of CAs

I think you've misunderstood how TLS works in Gemini. Gemini works using TOFU, or
Trust On First Use, which means that CAs are out of the picture, and self-signed
certs can be (and are) used. Generating a self-signed cert is pretty simple for
local dev.

You can learn more about this in the Gemini spec, and also I've just written a post
about how TOFU works in Gemini:

gemini://makeworld.gq/gemlog/2020-07-03-tofu-rec.gmi

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

Solderpunk has addressed these concerns on the list before, where he's said that
Gemini was created for the here and now, for the modern, current, internet. I am
involved in the meshnet community, and am all for them succeeding, and yes, TLS
would be an overhead. But right now that is not the situation for the majority of
people, and Gemini is designed to work and be (somewhat) secure *today*.

Cheers,
makeworld

From colecmac at protonmail.com  Sat Jul  4 16:17:28 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 04 Jul 2020 15:17:28 +0000
Subject: Titan, the proposed upload protocol for Gemini
In-Reply-To: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>
References: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>
Message-ID: <qkTm8yFD7X6ecMHCLY-kKEndDNzYOT9832hR33aIp9RT_VBcmL-gmN2jfZk8hI9nMyic9ayIV3a5EjYdiOMN5usqqPZ1b_MF7AUZoH1CMqY=@protonmail.com>

Thanks for making this post and explaining Titan!

I think it'd be great to eventually use client certificates for
authentication, but I definitely understand why you went with the
simpler token system for this initial implementation, it's a lot
easier to handle.

makeworld

From solderpunk at SDF.ORG  Sat Jul  4 17:14:53 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 4 Jul 2020 16:14:53 +0000
Subject: Ditching mandatory TLS
In-Reply-To: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
References: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
Message-ID: <20200704161453.GB25115@SDF.ORG>

On Sat, Jul 04, 2020 at 09:44:16AM -0400, Drew DeVault wrote:
> Unpopular opinion time: Gemini should not have mandatory TLS.

To be honest, I think by now this counts as a pretty popular opinion. :)
 
> - TLS is not conveinent for local development

Mostly because the `openssl` tool for making certs is garbage?  I do
hope to write a simple replacement for it for Gemini purposes soon.

> - TLS is inherently dependent on a centralized oligarchy of CAs

I don't think the dependency is inherent, and have tried to push back
against it by explicitly speccing TOFU as a first-class option.  I
admit this has proven to conflict much harder than I expected with the
"simplicity of implementation" idea as it turns out most TLS libraries
are not designed to do anything remotely unorthodox, which is a real
shame.

> - 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 can see the merit of these arguments.  In the context of a protocol
designed for use into the long term future and by people who are
technically skilled enough that they can set up something like
Yggdrasil, building in TLS is indeed dubious.  But I'm not targetting
that space with Gemini.  There is no shortage of (good!) projects
offering ways to distribute content online which is more private,
more decentralised, and more censorship resilient than Gemini.  They
all come with substantial "cognitive friction" in the form of concepts
that many developers and most users don't, won't or can't understand,
and as such they have all remained small projects and there's a good
chance they always will.  Gemini is by design "radically familiar" and
people don't have to learn any new concepts to build for it or use it.
I believe this is a large part of the reason why Gemini already has a
ridiculous number of implementations and a surprising number of hosts.

While it hasn't yet been codified as an official goal of the project, I
at least have increasingly come to conceptualise Gemini as a "lifeboat
for evacuees from the web", and specifically "a better lifeboat than
Gopher", which a lot of people won't jump to precisely on account of its
total lack of security.  Gemini lets something like "ordinary people"
shift their content off the web onto something vaguely weblike without
having to learn any weird new concepts or do anything strange to their
computer.  This is a valuable thing to have and not a space which has
received much exploration.  Removing mandatory TLS would make Gemini a
much worse lifeboat here and now and I'm reluctant to do this for the
sake of making Gemini a more viable option in a hypothetical future
where everybody is on something like Yggdrasil.

Cheers,
Solderpunk

From alex at gnu.org  Sat Jul  4 19:49:20 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sat, 04 Jul 2020 20:49:20 +0200
Subject: Titan, the proposed upload protocol for Gemini
In-Reply-To: <qkTm8yFD7X6ecMHCLY-kKEndDNzYOT9832hR33aIp9RT_VBcmL-gmN2jfZk8hI9nMyic9ayIV3a5EjYdiOMN5usqqPZ1b_MF7AUZoH1CMqY=@protonmail.com>
References: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>
 <qkTm8yFD7X6ecMHCLY-kKEndDNzYOT9832hR33aIp9RT_VBcmL-gmN2jfZk8hI9nMyic9ayIV3a5EjYdiOMN5usqqPZ1b_MF7AUZoH1CMqY=@protonmail.com>
Message-ID: <8e090a022c878ea289373959d4557a2cd0e951ca.camel@gnu.org>

On Sat, 2020-07-04 at 15:17 +0000, colecmac at protonmail.com wrote:
> I think it'd be great to eventually use client certificates for
> authentication, but I definitely understand why you went with the
> simpler token system for this initial implementation, it's a lot
> easier to handle.

Oh, sure. I do think those are two different use cases, though:
authentication and authorization. It's not just easier to implement
(because I don't really understand the nitty gritty of TLS) but it also
involves a design goal of mine regarding anonymous collaboration.

That's how I understand client certificates, in any case:

If we're using temporary client certificates, then nothing is gained.
In a wiki context, we don't need to know about sessions. We don't need
to know that this edit was made by the same person that made the other
edit a few minutes ago. (And in fact, Gemini Wiki computes a changing
"code" for each contributor and stores that, hopefully allowing us to
discern visually whether two edits made a few minutes appart are
probably made by the same person without allowing us to know whether
two edits made days appart were made by the same person.)

If we're using permanent client certificates, we've again gained
perpetual sessions which we don't need, or we're using the client
certificats to hand out capabilities: who is an admin, who is an
editor, who is a visitor, who is banned. We're using them for
autorization. I'd like to avoid thinking about that as part of Titan,
though. It's already part of Gemini. If anybody needs this, like they
want to restrict people to uploads to their own area of a site, then
that's fine. That's already covered by Gemini, as far as I'm concerned.

For my use case, tokens straddle that middle ground of anonymous
editing, web of trust, friends of friends, and password protection. We
can pass tokens on to friends and friends of friends, and if it breaks
down, we will issue a new set of tokens. These will again spread from
person to person (or to anybody who knows where to look them up). That
is, in any case, how I would like it to be. ?

And if we really want, then of course we can tie tokens to users, make
them into bearer tokens like they are used in OAuth2: somewhere, you
make an account, you generate a token, and use it for your Gemini
client. On the original site, you can invalidate the token, or the
person running the server can invalidate the token, the token can be
associated with different capabilities, and so on. Tokens allow us to
go there... but we don't have to.

Anyway, Gemini Wiki has the notion of "spaces" ? separate wikis hosted
within the same software. These spaces could be tied to client
certificates, for example, allowing people to have personal wikis that
are effectively read-only for others. The software isn't there, yet,
but it's something on my radar, for sure. I'm expecting that this will
work without having to change anything about Titan because client
certificates are already part of Gemini ? and if I go there, I might
decide that those spaces either don't need tokens, or I might decide
that within those spaces, the people with the right client certificate
are admins and get to generate and invalidate local tokens for their
friends and family. Then we can have both: authentication for admins,
and simple token-based authorization for collaborators.

Cheers
Alex



From philanc at gmail.com  Sat Jul  4 20:17:37 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Sat, 4 Jul 2020 19:17:37 +0000
Subject: URL/META length
Message-ID: <CAOH6EB-KBUDR7EUyMo=23YJHGoYOePSkJbPmZDPoxw-mk1g04A@mail.gmail.com>

I read a very interesting discussion between Petite Abeille,
Solderpunk, Luke Emmet 2-3 weeks ago, regarding how to upload small
content to Gemini servers (eg. wiki page updates, comments,...)

The idea revolves around using the URL to upload small content (or
chunked content in several requests)

Petite Abeille
https://lists.orbitalfox.eu/archives/gemini/2020/001644.html

Solderpunk reply
https://lists.orbitalfox.eu/archives/gemini/2020/001672.html

and Luke Emmet
https://lists.orbitalfox.eu/archives/gemini/2020/001681.html

Quoting Solderpunk:

>Well, look - 1024 bytes as a maximum URL length is a value I more or
less plucked out of the air without deep consideration, simply because
the elements passed around by a protocol *should* have a well-defined
maximum length so people can allocate appropriately sized memory
buffers, etc.  I certainly *wasn't* thinking about using queries to
upload content, I was thinking of "ordinary URLs" and so 1024 bytes
seemed hugely generous.

> According to GUS, currently more than half of the text/gemini content
out there is less than 1.2 KiB in size.  If URLs were allowed to be 2048
bytes long, all that content could be uploaded as a query.

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

What do you think?

Phil

From sean at conman.org  Sat Jul  4 22:12:17 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 4 Jul 2020 17:12:17 -0400
Subject: Ditching mandatory TLS
In-Reply-To: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
References: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
Message-ID: <20200704211217.GT19717@brevard.conman.org>

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.

From solderpunk at SDF.ORG  Sat Jul  4 22:24:03 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 4 Jul 2020 21:24:03 +0000
Subject: Ditching mandatory TLS
In-Reply-To: <20200704211217.GT19717@brevard.conman.org>
References: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
 <20200704211217.GT19717@brevard.conman.org>
Message-ID: <20200704212403.GC5368@SDF.ORG>

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

From solderpunk at SDF.ORG  Sat Jul  4 22:33:46 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 4 Jul 2020 21:33:46 +0000
Subject: URL/META length
In-Reply-To: <CAOH6EB-KBUDR7EUyMo=23YJHGoYOePSkJbPmZDPoxw-mk1g04A@mail.gmail.com>
References: <CAOH6EB-KBUDR7EUyMo=23YJHGoYOePSkJbPmZDPoxw-mk1g04A@mail.gmail.com>
Message-ID: <20200704213346.GD5368@SDF.ORG>

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

From sean at conman.org  Sat Jul  4 22:56:19 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 4 Jul 2020 17:56:19 -0400
Subject: Ditching mandatory TLS
In-Reply-To: <20200704212403.GC5368@SDF.ORG>
References: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
 <20200704211217.GT19717@brevard.conman.org> <20200704212403.GC5368@SDF.ORG>
Message-ID: <20200704215618.GU19717@brevard.conman.org>

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


From solderpunk at SDF.ORG  Sat Jul  4 22:59:44 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 4 Jul 2020 21:59:44 +0000
Subject: Ditching mandatory TLS
In-Reply-To: <20200704215618.GU19717@brevard.conman.org>
References: <C3XVUNF1XAXS.274U88O0BVZTN@homura>
 <20200704211217.GT19717@brevard.conman.org>
 <20200704212403.GC5368@SDF.ORG>
 <20200704215618.GU19717@brevard.conman.org>
Message-ID: <20200704215944.GG5368@SDF.ORG>

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

From philanc at gmail.com  Sat Jul  4 22:59:23 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Sat, 4 Jul 2020 21:59:23 +0000
Subject: URL/META length
In-Reply-To: <20200704213346.GD5368@SDF.ORG>
References: <CAOH6EB-KBUDR7EUyMo=23YJHGoYOePSkJbPmZDPoxw-mk1g04A@mail.gmail.com>
 <20200704213346.GD5368@SDF.ORG>
Message-ID: <CAOH6EB_GDzfkMcn8zssLmmuAneYSPFxg7DNZma+Xvd7ifgXAGg@mail.gmail.com>

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-for-gemini-applications.gmi

It is _not_ a modification in any way of the Gemini protocol - Just a
different size limit.

Phil

From solderpunk at SDF.ORG  Sat Jul  4 23:14:37 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 4 Jul 2020 22:14:37 +0000
Subject: URL/META length
In-Reply-To: <CAOH6EB_GDzfkMcn8zssLmmuAneYSPFxg7DNZma+Xvd7ifgXAGg@mail.gmail.com>
References: <CAOH6EB-KBUDR7EUyMo=23YJHGoYOePSkJbPmZDPoxw-mk1g04A@mail.gmail.com>
 <20200704213346.GD5368@SDF.ORG>
 <CAOH6EB_GDzfkMcn8zssLmmuAneYSPFxg7DNZma+Xvd7ifgXAGg@mail.gmail.com>
Message-ID: <20200704221437.GH5368@SDF.ORG>

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

From traderbeckola at tahoma.com  Sat Jul  4 23:33:58 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Sat, 4 Jul 2020 18:33:58 -0400
Subject: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini?
References: <7c745a34-8bd1-4964-ac5b-5acedf3dd0bb@Spark>
Message-ID: <39802f4e-8f27-4474-a406-ee782a60df55@Spark>

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200704/648fcba4/attachment.htm>

From solderpunk at SDF.ORG  Sat Jul  4 23:37:16 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sat, 4 Jul 2020 22:37:16 +0000
Subject: =?utf-8?B?V2hhdOKAmQ==?= =?utf-8?Q?s?= considered proxying in
 Gemini?
In-Reply-To: <39802f4e-8f27-4474-a406-ee782a60df55@Spark>
References: <7c745a34-8bd1-4964-ac5b-5acedf3dd0bb@Spark>
 <39802f4e-8f27-4474-a406-ee782a60df55@Spark>
Message-ID: <20200704223716.GK5368@SDF.ORG>

On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com wrote:
> 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!

What's the value of `Hostname` in your Molly Brown configuration, and is
that the hostname with which you are trying to access the server?

Cheers,
Solderpunk

From traderbeckola at tahoma.com  Sun Jul  5 00:01:24 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Sat, 4 Jul 2020 19:01:24 -0400
Subject: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini?
In-Reply-To: <20200704223716.GK5368@SDF.ORG>
References: <7c745a34-8bd1-4964-ac5b-5acedf3dd0bb@Spark>
 <39802f4e-8f27-4474-a406-ee782a60df55@Spark>
 <20200704223716.GK5368@SDF.ORG>
Message-ID: <3d72f875-d512-4f8c-845e-dad393e89476@Spark>

Yes. Just checked to make sure the hostname is harmonized across molly.conf, hostname on the server system, and the hostname the dns/dhcp server assigns it.
On Jul 4, 2020, 18:38 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
> On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com wrote:
> > 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!
>
> What's the value of `Hostname` in your Molly Brown configuration, and is
> that the hostname with which you are trying to access the server?
>
> Cheers,
> Solderpunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200704/60a001c5/attachment-0001.htm>

From baschdel at disroot.org  Sun Jul  5 00:12:45 2020
From: baschdel at disroot.org (Baschdel)
Date: Sun, 5 Jul 2020 01:12:45 +0200
Subject: Ditching mandatory TLS
In-Reply-To: <6c8aedf6-f7c9-5ac5-cfae-ac5be2cad5a5@disroot.org>
References: <6c8aedf6-f7c9-5ac5-cfae-ac5be2cad5a5@disroot.org>
Message-ID: <2b0d0c70-7333-8276-ca30-6a3ffcced0fa@disroot.org>

On 04.07.20 23:59, solderpunk wrote:
> TLS is baked in pretty deep.

Someone who implements Gemini over <TLS_alternative> could if that 
alternative didn't offer anything that can be a drop in replacement for 
client certificates do a negotiation protocol before doing the usual 
Gemini request.

That negotiation would probably look something like this:

server sends some data. (That could also be the servers public key and a 
payload that verifys the servers identity)

client signs it and reply's with the signature and its public key or a 
well known placeholder that means "no certificate"

(I not even spend two minutes of thinking on this, so don't assume this 
is THE way to do it)


What I want to say is that while not easy it also isn't impossible to 
replace TLS.

(If that someone wrote a good library for this in C (or at least with a 
c API) it could be bound to most languages people are already writing 
Gemini software in (the replacement crypto library has to be ported and 
clients and servers be extended to handle the new underlying protocol 
anyway).


Just throwing the idea out there, have a nice Evening!

- Baschdel


From hello at matthewgraybosch.com  Sun Jul  5 02:13:51 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 4 Jul 2020 21:13:51 -0400
Subject: [ANN] GMI to Atom converter CGI script
In-Reply-To: <5EFDC31A.40001@marmaladefoo.com>
References: <5EFDC31A.40001@marmaladefoo.com>
Message-ID: <20200704211351.05d80d1d40381b773c9f1693@matthewgraybosch.com>

On Thu, 02 Jul 2020 12:20:58 +0100
Luke Emmet <luke at marmaladefoo.com> wrote:

> Hi All
> 
> I've created a gemini server CGI script that automatically serves an 
> Atom XML feed based on a live gemlog/blog GMI file.

This looks good. Thanks for making it publicly available.

I might have to look into installing Rebol on FreeBSD and setting this
up at tanelorn.city.

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

From hello at matthewgraybosch.com  Sun Jul  5 02:16:05 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Sat, 4 Jul 2020 21:16:05 -0400
Subject: Gemini Text Markup Language specification
In-Reply-To: <20200702165251.GB10251@SDF.ORG>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <20200702165251.GB10251@SDF.ORG>
Message-ID: <20200704211605.713d86951b9e8e6c3cb610dd@matthewgraybosch.com>

On Thu, 2 Jul 2020 16:52:51 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> gemini://gemini.circumlunar.space/docs/gemtext.gmi
> gemini://gemini.circumlunar.space/docs/cheatsheet.gmi
> 
> Two new resources to help beginners to get up and writing quickly.
> Feedback welcome!

Thanks for putting these together. This will help if tanelorn.city
picks up more residents.

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

From Bradley at NorthTech.US  Sun Jul  5 03:23:51 2020
From: Bradley at NorthTech.US (Bradley D. Thornton)
Date: Sat, 4 Jul 2020 19:23:51 -0700
Subject: [ANN] deedum browser update
In-Reply-To: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
Message-ID: <6231272c-95c6-dde5-c71d-f92dbe67bea0@NorthTech.US>

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

From solderpunk at SDF.ORG  Sun Jul  5 11:08:38 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 5 Jul 2020 10:08:38 +0000
Subject: [ANN] GMI to Atom converter CGI script
In-Reply-To: <20200704211351.05d80d1d40381b773c9f1693@matthewgraybosch.com>
References: <5EFDC31A.40001@marmaladefoo.com>
 <20200704211351.05d80d1d40381b773c9f1693@matthewgraybosch.com>
Message-ID: <20200705100838.GB7829@SDF.ORG>

On Sat, Jul 04, 2020 at 09:13:51PM -0400, Matthew Graybosch wrote:
> On Thu, 02 Jul 2020 12:20:58 +0100
> Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> > Hi All
> > 
> > I've created a gemini server CGI script that automatically serves an 
> > Atom XML feed based on a live gemlog/blog GMI file.
> 
> This looks good. Thanks for making it publicly available.

Yes, thanks, this is a really useful thing to have, especially for
people who are hosting multiple users on their server.  It's much easier
for the admin to maintain a small config file mapping usernames to URLs
for a tool like this, than having to setup gemfeed cronjobs for each
user.

I'm adding it now to the official software list.

Cheers,
Solderpunk

From solderpunk at SDF.ORG  Sun Jul  5 12:01:01 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 5 Jul 2020 11:01:01 +0000
Subject: Adding Gemini support to edbrowse
Message-ID: <20200705110101.GD7829@SDF.ORG>

Greetings Geminauts,

I recently heard from one of the developers of edbrowse (see
edbrowse.org), who said that he thought Gemini could be very popular
with disabled internet uses due to its potential for much better
accessibility than the web.  He is open to the idea of adding Gemini
support to edbrowse, but doesn't haven't the time to do it himself.
He suggested that if I or somebody else submitted a pull request doing
this, it could very well be adopted.  I also don't have time to do this
anytime soon, and my C is pretty rusty anyway.  If anybody else is
looking for a Gemini-related coding project and has good C skills, this
could be an excellent candidate.  It's also a good opportunity to bring
awareness of and access to Gemini to a large pre-existing userbase who
might find it very useful.

Edbrowse already supports gopher, and the gopher module is apparently
about 300 lines of C.  Gemini is in some ways simpler than Gopher and
other ways less simple; this job would perhaps involve writing ~500
lines of C or thereabouts.

Let me know if you are interested.

Cheers,
Solderpunk

From traderbeckola at tahoma.com  Sun Jul  5 13:15:57 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Sun, 5 Jul 2020 08:15:57 -0400
Subject: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini?
In-Reply-To: <3d72f875-d512-4f8c-845e-dad393e89476@Spark>
References: <7c745a34-8bd1-4964-ac5b-5acedf3dd0bb@Spark>
 <39802f4e-8f27-4474-a406-ee782a60df55@Spark>
 <20200704223716.GK5368@SDF.ORG>
 <3d72f875-d512-4f8c-845e-dad393e89476@Spark>
Message-ID: <d86a1a67-be2e-411f-9dd2-bed51d8e3d64@Spark>

I played with commenting out the code block in molly-brown that?s relevant to the proxy test; that change will allow the client to connect.
On Jul 4, 2020, 19:02 -0400, traderbeckola at tahoma.com, wrote:
> Yes. Just checked to make sure the hostname is harmonized across molly.conf, hostname on the server system, and the hostname the dns/dhcp server assigns it.
> On Jul 4, 2020, 18:38 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
> > On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com wrote:
> > > 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!
> >
> > What's the value of `Hostname` in your Molly Brown configuration, and is
> > that the hostname with which you are trying to access the server?
> >
> > Cheers,
> > Solderpunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200705/0154257f/attachment.htm>

From traderbeckola at tahoma.com  Sun Jul  5 13:19:43 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Sun, 5 Jul 2020 08:19:43 -0400
Subject: Gemini Text Markup Language specification
In-Reply-To: <20200704211605.713d86951b9e8e6c3cb610dd@matthewgraybosch.com>
References: <435613ad-7530-47aa-a85b-c0bef799170b@Spark>
 <5a6a7b86-be93-4059-905f-b5cf3d4793a9@Spark>
 <1BD746C0-9D31-47DC-9962-32F1662FB500@gmail.com>
 <20200702165251.GB10251@SDF.ORG>
 <20200704211605.713d86951b9e8e6c3cb610dd@matthewgraybosch.com>
Message-ID: <4845a26b-6136-476c-b96f-6dbe949a0e4f@Spark>

Thanks!
On Jul 4, 2020, 21:45 -0400, Matthew Graybosch <hello at matthewgraybosch.com>, wrote:
> On Thu, 2 Jul 2020 16:52:51 +0000
> solderpunk <solderpunk at SDF.ORG> wrote:
>
> > gemini://gemini.circumlunar.space/docs/gemtext.gmi
> > gemini://gemini.circumlunar.space/docs/cheatsheet.gmi
> >
> > Two new resources to help beginners to get up and writing quickly.
> > Feedback welcome!
>
> Thanks for putting these together. This will help if tanelorn.city
> picks up more residents.
>
> --
> 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200705/6191942b/attachment.htm>

From solderpunk at SDF.ORG  Sun Jul  5 14:14:31 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 5 Jul 2020 13:14:31 +0000
Subject: =?utf-8?B?V2hhdOKAmQ==?= =?utf-8?Q?s?= considered proxying in
 Gemini?
In-Reply-To: <d86a1a67-be2e-411f-9dd2-bed51d8e3d64@Spark>
References: <7c745a34-8bd1-4964-ac5b-5acedf3dd0bb@Spark>
 <39802f4e-8f27-4474-a406-ee782a60df55@Spark>
 <20200704223716.GK5368@SDF.ORG>
 <3d72f875-d512-4f8c-845e-dad393e89476@Spark>
 <d86a1a67-be2e-411f-9dd2-bed51d8e3d64@Spark>
Message-ID: <20200705131431.GA11143@SDF.ORG>

On Sun, Jul 05, 2020 at 08:15:57AM -0400, traderbeckola at tahoma.com wrote:
> I played with commenting out the code block in molly-brown that?s relevant to the proxy test; that change will allow the client to connect.

No doubt, but that does nothing to fix the fact that something is
clearly wrong wrong somewhere.

Gemini requests are URLs, with hostnames in them.  It's possible in
principle to connect to the foo.com host and send it a request for
gemini://bar.net, and its possible in principle for foo.com to respond
to this by sending the request on to bar.net and then relaying the
response to the original client.  This is what is meant by "proxying" in
Gemini.

It is rarely used, and with good reason, as Gemini servers used as
proxies are also "men in the middle".  There are legitimate uses,
though: my Agena software will accept Gemini requests for gopher://
URLs, fetch them and the translate Gopher menus into gemtext.  I run it
on localhost so it's just "me spying on me".  It lets me use AV-98
(which can be configured to forward gopher:// requests to such a proxy)
as both a Gemini client and Gopher client seamlessly, without having to
actually put any Gopher code into AV-98.  Any other client could easily
add support for this too.

Anyway, Molly Brown offers no support for any of this.  If it receives a
request for a URL with a hostname that doesn't match its configured
hostname, it will respond with a "no proxying allowed" error, and that's
the end of that.  The actual server system's hostname is not consulted.
If you're seeing these errors, it can only mean that your client is
sending a URL with the wrong hostname (or there's a bug in Molly Brown,
in which case we should try to identify and fix it, not just comment it
out).

Are you perhaps connecting to the server by typing its IP address into
your client, and not the hostname?  That's something I can think of
which would cause this (and perhaps shouldn't).

If that's not the case, look in your Molly Brown access log.  You'll be
able to see the URL your client is sending.  That will probably let us
know what's going on.

Cheers,
Solderpunk

> On Jul 4, 2020, 19:02 -0400, traderbeckola at tahoma.com, wrote:
> > Yes. Just checked to make sure the hostname is harmonized across molly.conf, hostname on the server system, and the hostname the dns/dhcp server assigns it.
> > On Jul 4, 2020, 18:38 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
> > > On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com wrote:
> > > > 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!
> > >
> > > What's the value of `Hostname` in your Molly Brown configuration, and is
> > > that the hostname with which you are trying to access the server?
> > >
> > > Cheers,
> > > Solderpunk

From traderbeckola at tahoma.com  Sun Jul  5 15:11:18 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Sun, 5 Jul 2020 10:11:18 -0400
Subject: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini?
In-Reply-To: <20200705131431.GA11143@SDF.ORG>
References: <7c745a34-8bd1-4964-ac5b-5acedf3dd0bb@Spark>
 <39802f4e-8f27-4474-a406-ee782a60df55@Spark>
 <20200704223716.GK5368@SDF.ORG>
 <3d72f875-d512-4f8c-845e-dad393e89476@Spark>
 <d86a1a67-be2e-411f-9dd2-bed51d8e3d64@Spark>
 <20200705131431.GA11143@SDF.ORG>
Message-ID: <81598d18-56e0-4886-9c57-fe1b8752b3a9@Spark>

Thanks. In short, I agree. The idea of commenting out that code was to help me get a better handle on where the problem was originating in the broadest sense (client program, server issue, user error). Taking that block out doesn?t help actually fix the problem; it just helped me identify it better as a total gemini (and go lang, and ...) rookie.

Will keep digging to get a better idea of a real solution.

Regards,

Erik
On Jul 5, 2020, 09:15 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
> On Sun, Jul 05, 2020 at 08:15:57AM -0400, traderbeckola at tahoma.com wrote:
> > I played with commenting out the code block in molly-brown that?s relevant to the proxy test; that change will allow the client to connect.
>
> No doubt, but that does nothing to fix the fact that something is
> clearly wrong wrong somewhere.
>
> Gemini requests are URLs, with hostnames in them. It's possible in
> principle to connect to the foo.com host and send it a request for
> gemini://bar.net, and its possible in principle for foo.com to respond
> to this by sending the request on to bar.net and then relaying the
> response to the original client. This is what is meant by "proxying" in
> Gemini.
>
> It is rarely used, and with good reason, as Gemini servers used as
> proxies are also "men in the middle". There are legitimate uses,
> though: my Agena software will accept Gemini requests for gopher://
> URLs, fetch them and the translate Gopher menus into gemtext. I run it
> on localhost so it's just "me spying on me". It lets me use AV-98
> (which can be configured to forward gopher:// requests to such a proxy)
> as both a Gemini client and Gopher client seamlessly, without having to
> actually put any Gopher code into AV-98. Any other client could easily
> add support for this too.
>
> Anyway, Molly Brown offers no support for any of this. If it receives a
> request for a URL with a hostname that doesn't match its configured
> hostname, it will respond with a "no proxying allowed" error, and that's
> the end of that. The actual server system's hostname is not consulted.
> If you're seeing these errors, it can only mean that your client is
> sending a URL with the wrong hostname (or there's a bug in Molly Brown,
> in which case we should try to identify and fix it, not just comment it
> out).
>
> Are you perhaps connecting to the server by typing its IP address into
> your client, and not the hostname? That's something I can think of
> which would cause this (and perhaps shouldn't).
>
> If that's not the case, look in your Molly Brown access log. You'll be
> able to see the URL your client is sending. That will probably let us
> know what's going on.
>
> Cheers,
> Solderpunk
>
> > On Jul 4, 2020, 19:02 -0400, traderbeckola at tahoma.com, wrote:
> > > Yes. Just checked to make sure the hostname is harmonized across molly.conf, hostname on the server system, and the hostname the dns/dhcp server assigns it.
> > > On Jul 4, 2020, 18:38 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
> > > > On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com wrote:
> > > > > 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!
> > > >
> > > > What's the value of `Hostname` in your Molly Brown configuration, and is
> > > > that the hostname with which you are trying to access the server?
> > > >
> > > > Cheers,
> > > > Solderpunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200705/55b9dad0/attachment-0001.htm>

From solderpunk at SDF.ORG  Sun Jul  5 17:16:35 2020
From: solderpunk at SDF.ORG (solderpunk)
Date: Sun, 5 Jul 2020 16:16:35 +0000
Subject: Change of email address
Message-ID: <20200705161635.GC11143@SDF.ORG>

Howdy Geminauts,

I am in the process of migrating to a new email address.  Future posts
to this list from solderpunk at posteo.net are, indeed, from "The Real
Solderpunk" and not some imposter.  You can further verify this by
noticing that the new email address is now in the official Gemini
documentation and in my Zaibatsu gopherhole.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Jul  5 17:17:15 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 05 Jul 2020 18:17:15 +0200
Subject: Change of email address
In-Reply-To: <20200705161635.GC11143@SDF.ORG>
Message-ID: <C3YTQBPSCTXJ.1CSORBSVO6B25@stilgar>

On Sun Jul 5, 2020 at 6:16 PM CEST, solderpunk wrote:

> I am in the process of migrating to a new email address. Future posts
> to this list from solderpunk at posteo.net are, indeed, from "The Real
> Solderpunk" and not some imposter. You can further verify this by
> noticing that the new email address is now in the official Gemini
> documentation and in my Zaibatsu gopherhole.

Chiming in quickly from the other address as some kind of very mild
additional verification.

Cheers,
Solderpunk

From colecmac at protonmail.com  Sun Jul  5 17:27:19 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 05 Jul 2020 16:27:19 +0000
Subject: Removing expiry dates for TOFU
Message-ID: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>

Hello all,

Mozz proposed an interesting idea to me on Github, which was removing expiry dates
from TOFU entirely.

I wrote a quick post on it, I'd appreciate it if you could read
it and offer your thoughts. I think this could help make things more secure on
Gemini, and possibly make TOFU and cert management more painless.

gemini://makeworld.gq/gemlog/2020-07-05-tofu-2.gmi

Thanks,
makeworld



From traderbeckola at tahoma.com  Sun Jul  5 17:29:58 2020
From: traderbeckola at tahoma.com (traderbeckola at tahoma.com)
Date: Sun, 5 Jul 2020 12:29:58 -0400
Subject: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini?
In-Reply-To: <20200705131431.GA11143@SDF.ORG>
References: <7c745a34-8bd1-4964-ac5b-5acedf3dd0bb@Spark>
 <39802f4e-8f27-4474-a406-ee782a60df55@Spark>
 <20200704223716.GK5368@SDF.ORG>
 <3d72f875-d512-4f8c-845e-dad393e89476@Spark>
 <d86a1a67-be2e-411f-9dd2-bed51d8e3d64@Spark>
 <20200705131431.GA11143@SDF.ORG>
Message-ID: <b5bba637-67bf-4b82-8112-1cac91d50558@Spark>

I figured it out. I think. Case sensitivity.
On Jul 5, 2020, 09:15 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
> On Sun, Jul 05, 2020 at 08:15:57AM -0400, traderbeckola at tahoma.com wrote:
> > I played with commenting out the code block in molly-brown that?s relevant to the proxy test; that change will allow the client to connect.
>
> No doubt, but that does nothing to fix the fact that something is
> clearly wrong wrong somewhere.
>
> Gemini requests are URLs, with hostnames in them. It's possible in
> principle to connect to the foo.com host and send it a request for
> gemini://bar.net, and its possible in principle for foo.com to respond
> to this by sending the request on to bar.net and then relaying the
> response to the original client. This is what is meant by "proxying" in
> Gemini.
>
> It is rarely used, and with good reason, as Gemini servers used as
> proxies are also "men in the middle". There are legitimate uses,
> though: my Agena software will accept Gemini requests for gopher://
> URLs, fetch them and the translate Gopher menus into gemtext. I run it
> on localhost so it's just "me spying on me". It lets me use AV-98
> (which can be configured to forward gopher:// requests to such a proxy)
> as both a Gemini client and Gopher client seamlessly, without having to
> actually put any Gopher code into AV-98. Any other client could easily
> add support for this too.
>
> Anyway, Molly Brown offers no support for any of this. If it receives a
> request for a URL with a hostname that doesn't match its configured
> hostname, it will respond with a "no proxying allowed" error, and that's
> the end of that. The actual server system's hostname is not consulted.
> If you're seeing these errors, it can only mean that your client is
> sending a URL with the wrong hostname (or there's a bug in Molly Brown,
> in which case we should try to identify and fix it, not just comment it
> out).
>
> Are you perhaps connecting to the server by typing its IP address into
> your client, and not the hostname? That's something I can think of
> which would cause this (and perhaps shouldn't).
>
> If that's not the case, look in your Molly Brown access log. You'll be
> able to see the URL your client is sending. That will probably let us
> know what's going on.
>
> Cheers,
> Solderpunk
>
> > On Jul 4, 2020, 19:02 -0400, traderbeckola at tahoma.com, wrote:
> > > Yes. Just checked to make sure the hostname is harmonized across molly.conf, hostname on the server system, and the hostname the dns/dhcp server assigns it.
> > > On Jul 4, 2020, 18:38 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
> > > > On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com wrote:
> > > > > 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!
> > > >
> > > > What's the value of `Hostname` in your Molly Brown configuration, and is
> > > > that the hostname with which you are trying to access the server?
> > > >
> > > > Cheers,
> > > > Solderpunk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200705/a6b59e21/attachment.htm>

From benulo at systemli.org  Sun Jul  5 18:13:38 2020
From: benulo at systemli.org (Ben)
Date: Sun, 5 Jul 2020 21:43:38 +0430
Subject: Change of email address
In-Reply-To: <C3YTQBPSCTXJ.1CSORBSVO6B25@stilgar>
References: <C3YTQBPSCTXJ.1CSORBSVO6B25@stilgar>
Message-ID: <32dd9240-556a-b7b5-97a2-e256f77abdae@systemli.org>

Ganbatte!

-- 
gemini://kwiecien.us/

From solderpunk at posteo.net  Sun Jul  5 18:17:48 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 05 Jul 2020 19:17:48 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>
References: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>
Message-ID: <be4b0efd64dbdaea89b5a37b39f92773@posteo.net>

Using the same keypair for a very long time is generally considered a 
bad idea, as it increases both the risk of key compromise and the 
duration for which a stolen key can be exploited.  There's also the 
issue of ownership of domain names changing over long timespans, and 
former legitimate domain owners being able to impersonate new legitimate 
domain owners with old certificates.  Even CA certificates have expiry 
dates.  I don't think we should be advising people to use certs which 
last forever.

That said, for typical Gemini applications I don't think something like 
a three year key/cert lifespan is necessarily a big problem, and would 
certainly make TOFU issues less common.  In principle it doesn't make 
much sense to rotate your TLS keys much more often than your server's 
SSH keys, and let's be honest: how often do most of us do that?

One idea I had, which could be neat for people who are really serious 
about good, long-term identity management without CAs, is the following: 
generate a key pair, for use as an ephemeral signing key, and a 
self-signed certificate for the public key with 100 years of validity.  
Then generate 100 additional keypairs, and use the signing key to sign 
certificates for them with a validity of, say, 1 year each, and 
consecutive validity periods.  Permanently delete the signing key, but 
keep the self-signed certificate.  Move all the 1 year keys to a USB 
stick, and transfer them one at a time, as they become valid, to your 
server.  For the next 100 years, serve up a two certificate long chain, 
with the self-signed cert for the signing key, plus your currently 
active 1 year cert signed with the signing key.  Once a client 
TOFU-accepts the signing key's certificate, they'll be able to validate 
all the annual key roll overs as originating from the same party, even 
if they don't visit your site for 10 years at a time.  Someone who 
breaks into your server can steal this year's key, but not any future 
keys, because they're on the USB stick, so their ability to impersonate 
you is strictly time-limited.  Nobody can steal the original signing key 
and make their own certificate which will be accepted by TOFU clients, 
because it's been deleted.  Hijacking this identity basically requires 
stealing the physical USB key.  This sounds like a lot of work, but 
generating all the keys and certs could be trivially automated.

Cheers,
Solderpunk

On 05.07.2020 18:27, colecmac at protonmail.com wrote:
> Hello all,
> 
> Mozz proposed an interesting idea to me on Github, which was removing
> expiry dates
> from TOFU entirely.
> 
> I wrote a quick post on it, I'd appreciate it if you could read
> it and offer your thoughts. I think this could help make things more 
> secure on
> Gemini, and possibly make TOFU and cert management more painless.
> 
> gemini://makeworld.gq/gemlog/2020-07-05-tofu-2.gmi
> 
> Thanks,
> makeworld

From peteyboy at sdf.org  Sun Jul  5 18:58:02 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Sun, 05 Jul 2020 10:58:02 -0700
Subject: Hacker News again
In-Reply-To: <mailman.36.1593903703.544.gemini@lists.orbitalfox.eu>
References: <mailman.36.1593903703.544.gemini@lists.orbitalfox.eu>
Message-ID: <404BE332-C164-470E-9DCD-35FC5AC28360@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-for-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!
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://lists.orbitalfox.eu/archives/gemini/attachments/20200704/648fcba4/attachment-0001.htm>
>
>------------------------------
>
>Message: 9
>Date: Sat, 4 Jul 2020 22:37:16 +0000
>From: solderpunk <solderpunk at SDF.ORG>
>To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>Subject: Re: What?s considered proxying in Gemini?
>Message-ID: <20200704223716.GK5368 at SDF.ORG>
>Content-Type: text/plain; charset=utf-8
>
>On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com
>wrote:
>> 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!
>
>What's the value of `Hostname` in your Molly Brown configuration, and
>is
>that the hostname with which you are trying to access the server?
>
>Cheers,
>Solderpunk
>
>
>------------------------------
>
>Message: 10
>Date: Sat, 4 Jul 2020 19:01:24 -0400
>From: traderbeckola at tahoma.com
>To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>Subject: Re: =?utf-8?Q?What=E2=80=99s_?=considered proxying in Gemini?
>Message-ID: <3d72f875-d512-4f8c-845e-dad393e89476 at Spark>
>Content-Type: text/plain; charset="utf-8"
>
>Yes. Just checked to make sure the hostname is harmonized across
>molly.conf, hostname on the server system, and the hostname the
>dns/dhcp server assigns it.
>On Jul 4, 2020, 18:38 -0400, solderpunk <solderpunk at SDF.ORG>, wrote:
>> On Sat, Jul 04, 2020 at 06:33:58PM -0400, traderbeckola at tahoma.com
>wrote:
>> > 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!
>>
>> What's the value of `Hostname` in your Molly Brown configuration, and
>is
>> that the hostname with which you are trying to access the server?
>>
>> Cheers,
>> Solderpunk
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://lists.orbitalfox.eu/archives/gemini/attachments/20200704/60a001c5/attachment.htm>
>
>------------------------------
>
>Subject: Digest Footer
>
>Gemini mailing list
>Gemini at lists.orbitalfox.eu
>https://lists.orbitalfox.eu/listinfo/gemini
>
>
>------------------------------
>
>End of Gemini Digest, Vol 12, Issue 9
>*************************************

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200705/4bd18908/attachment-0001.htm>

From solderpunk at posteo.net  Sun Jul  5 18:59:19 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 05 Jul 2020 19:59:19 +0200
Subject: Hacker News again
In-Reply-To: <404BE332-C164-470E-9DCD-35FC5AC28360@sdf.org>
Message-ID: <C3YVWH560CYG.5Z8SJ43ZLC97@stilgar>

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

From solderpunk at posteo.net  Sun Jul  5 19:03:31 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 05 Jul 2020 20:03:31 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>
Message-ID: <C3YVZP6ROTJ4.1TDHIPD7QDSM8@stilgar>

By the way, I appreciate you writing this up, and also your earlier post
on TOFU which you shared here.

I've finally started work on my gentle TLS cert introduction, it's at
gemini://gemini.circumlunar.space/docs/tls-tutorial.gmi.  So far it's
just background stuff, but TOFU will feature eventually.  Keep an eye on
it over the next week or so.  Feedback welcome at any stage, though.

Cheers,
Solderpunk

From colecmac at protonmail.com  Sun Jul  5 19:48:24 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 05 Jul 2020 18:48:24 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <be4b0efd64dbdaea89b5a37b39f92773@posteo.net>
References: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>
 <be4b0efd64dbdaea89b5a37b39f92773@posteo.net>
Message-ID: <AxqvxgimIVnejomktBh0E5f2uJOD0-61sEsYbJNrYq9eE46GutOJBfcf6NWvejfKgqTU6GrHJoHZxQsSTTEm4oJkAlm--xp6x5GQHJhXUGQ=@protonmail.com>

Looks like it was a bad idea after all haha. I wasn't sure about it,
so thanks for showing some issues with it.

I will have to look at your USB example another time to understand it
fully, but it sounds interesting. Another optional security thing like
you explained with notaries?

> That said, for typical Gemini applications I don't think something like
> a three year key/cert lifespan is necessarily a big problem, and would
> certainly make TOFU issues less common. In principle it doesn't make
> much sense to rotate your TLS keys much more often than your server's
> SSH keys, and let's be honest: how often do most of us do that?

Maybe this is a better solution, everyone using longer term certs? It
still might not be enough though.

My thinking behind my original post was that the fewer valid reasons for
changing certs the better. If changing certs is very rare, then clients
can be more informative to the user, and say with more surety that there
is a MITM attack going on. How can we lessen the behaviour of just clicking
through any TOFU pop-up?

Thanks,
makeworld

From solderpunk at posteo.net  Sun Jul  5 22:20:11 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 05 Jul 2020 23:20:11 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <AxqvxgimIVnejomktBh0E5f2uJOD0-61sEsYbJNrYq9eE46GutOJBfcf6NWvejfKgqTU6GrHJoHZxQsSTTEm4oJkAlm--xp6x5GQHJhXUGQ=@protonmail.com>
Message-ID: <C3Z069NVF98Q.3VMDOCAM9Z8Q1@stilgar>

On Sun Jul 5, 2020 at 8:48 PM CEST,  wrote:
> Looks like it was a bad idea after all haha. I wasn't sure about it,
> so thanks for showing some issues with it.
>
> Maybe this is a better solution, everyone using longer term certs? It
> still might not be enough though.
>
> My thinking behind my original post was that the fewer valid reasons for
> changing certs the better. If changing certs is very rare, then clients
> can be more informative to the user, and say with more surety that there
> is a MITM attack going on. How can we lessen the behaviour of just
> clicking through any TOFU pop-up?

Well, I think your overall thinking was very much in the right
direction, you just took it too far. :)

It's basically just a trade-off.  If certificates never, ever expire
then TOFU is very simple and clients will never have to show scary
messages under ordinary circumstances when everything is fine, but the
risk of the private key being stolen or broken (keys which are long
enough to be safe today will not be decades later) is very high, and if
it happens, the consequences last forever.  If certificates expire every
week, it's very hard to steal or crack a key before the corresponding
cert expires, but TOFU is unworkable without some extra complication on
top.  The best approach is somewhere in the middle.  The question is:
where?

On the web, certificate lifetimes are getting shorter and shorter - but
CAs have a strong financial incentive to be risk averse here, because
bad publicity around a single, long-lasting erroneously issued cert will
damage their reputation and hence business, possibly quite hard.  But
Gemini server admins using self-signed certs don't have that risk at
all.  Also, on the web, TLS is often protecting credit card details, or
access to email, or other things people have a strong incentive to
actively try to steal.  A personal Gemini host serving a gemlog is not
likely to be the target of serious efforts at compromise, so yet less
reason to be super cautious about key rotation.  For low-risk
applications, a five year certificate might be perfectly reasonable.

One could argue that longer lived certs actually help TOFU work, within
reason.  The longer a cert is in use, the more opportunity you have to
observe that cert being served to you from multiple different networks
(at home, at work, at the library, at the airport), which helps build
up your trust in it: getting MITMed once on a single network might be a
plausible risk.  Being consistently MITMed every time you visit a host,
from multiple locations, for years and years, is almost impossible, so
the longer you see the same cert, the more confident you can become that
when you blindly accepted the cert the very first time you weren't being
attacked.

Cheers,
Solderpunk

From colecmac at protonmail.com  Sun Jul  5 23:18:56 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 05 Jul 2020 22:18:56 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <C3Z069NVF98Q.3VMDOCAM9Z8Q1@stilgar>
References: <C3Z069NVF98Q.3VMDOCAM9Z8Q1@stilgar>
Message-ID: <tLXRGeRZKfpbux6Hn1r4CojGP02TcMPn2J-GGavwT4zNQEzKOBc4KUNXGbxjcPVVYJDKSGba9D9C9C5wnqZlFnyswlXOMA27vpj702blIhM=@protonmail.com>

5 year certs sound like a good compromise to me. We can make client
messages sufficiently scary, seeing as a five year expiry will make
TOFU issue somewhat rare. Will you set that as a default for your
cert tool then?

Do you agree with my original recommendation that clients should
auto-accept any cert once the old one has expired? This seems relevant
here. I think it's nice for UX, although I see the obvious security risk.

makeworld

From hannu.hartikainen+gemini at gmail.com  Sun Jul  5 23:49:55 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Mon, 6 Jul 2020 01:49:55 +0300
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
Message-ID: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>

Hi!

I'm announcing my first proper piece of Gemini software: twinwiki!

The general idea is that a single line of input[1] works for very few text
editing interfaces, yet most of us know one: sed. Mostly people use a very
small subset of sed. Here I've implemented a slightly larger subset and I
feel you could actually edit pages quite well if the browser showed line
numbers.

To get a feel, please try out this test instance:
gemini://hannuhartikainen.fi/twinwiki

Feel free to create new pages and edit the existing ones. All page changes
can be reverted. Pages cannot be deleted. I.e. if you're able to break
something, it's my fault.

The basic wiki features exist: you can edit, create pages, view history,
see an index of pages and read help.

Some caveats:
- Navigating back to a /_edit?<sed_command> URL will redo the edit, which
is mostly not what you tried to do. This will probably be an issue on many
gemini applications; browsers will need to consider it if applications
become a thing.
- The sed syntax is not fully POSIX even for the implemented parts:
whitespace after commands is taken literally; regex syntax is the one from
the Rust regex crate.

The project page (git repo, mailing lists, ticket tracker) is at
https://sr.ht/~dancek/twinwiki/

Any comments, contributions etc. are welcome. I hope this will give other
people other ideas about possible user interfaces.

-Hannu

[1] A sed command containing newlines will probably work, too, as long as
it's percent-encoded properly (ie. \n = %0A). However, the Gemini spec
suggests that the input should not contain newlines: "The requested
resource accepts a line of textual user input." Is it a bad sin to send
multiple lines?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200706/b713b8ec/attachment.htm>

From int at 80h.dev  Sun Jul  5 23:56:54 2020
From: int at 80h.dev (int 80h)
Date: Sun, 05 Jul 2020 18:56:54 -0400
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
Message-ID: <C3Z28BTHDR5A.3NW4VJZOIO9UP@freebsd.lan>

On Sun Jul 5, 2020 at 9:49 PM EDT, Hannu Hartikainen wrote:
> The general idea is that a single line of input[1] works for very few
> text
> editing interfaces, yet most of us know one: sed. Mostly people use a
> very
> small subset of sed. Here I've implemented a slightly larger subset and
> I
> feel you could actually edit pages quite well if the browser showed line
> numbers.

I really like the idea of using sed for a wiki interface. Nice work.

int 80h

From lists at ryliejamesthomas.net  Mon Jul  6 00:30:57 2020
From: lists at ryliejamesthomas.net (rjt)
Date: Mon, 6 Jul 2020 09:30:57 +1000
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <C3Z28BTHDR5A.3NW4VJZOIO9UP@freebsd.lan>
References: <C3Z28BTHDR5A.3NW4VJZOIO9UP@freebsd.lan>
Message-ID: <fea1ec2a-945d-c883-ab1c-c6a1fef5dcea@ryliejamesthomas.net>

On 6/7/20 8:56 am, int 80h wrote:
> On Sun Jul 5, 2020 at 9:49 PM EDT, Hannu Hartikainen wrote:
>> The general idea is that a single line of input[1] works for very few
>> text
>> editing interfaces, yet most of us know one: sed. Mostly people use a
>> very
>> small subset of sed. Here I've implemented a slightly larger subset and
>> I
>> feel you could actually edit pages quite well if the browser showed line
>> numbers.
> 
> I really like the idea of using sed for a wiki interface. Nice work.
> 
> int 80h
> 

Same, what a beautiful idea!

From me at case.codes  Mon Jul  6 01:21:02 2020
From: me at case.codes (Case Nelson)
Date: Mon, 6 Jul 2020 00:21:02 +0000 (UTC)
Subject: [ANN] deedum browser update
In-Reply-To: <6231272c-95c6-dde5-c71d-f92dbe67bea0@NorthTech.US>
References: <83DC3D79-9915-4DB8-8339-FA2B7C96C82B@case.codes>
 <6231272c-95c6-dde5-c71d-f92dbe67bea0@NorthTech.US>
Message-ID: <481319ed-c989-4a84-bb48-8ae560872980@case.codes>

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


From defdefred at protonmail.com  Mon Jul  6 07:06:33 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 06 Jul 2020 06:06:33 +0000
Subject: Titan, the proposed upload protocol for Gemini
In-Reply-To: <8e090a022c878ea289373959d4557a2cd0e951ca.camel@gnu.org>
References: <62a658ca529faa305ac95aca09820df653f6aaf2.camel@gnu.org>
 <qkTm8yFD7X6ecMHCLY-kKEndDNzYOT9832hR33aIp9RT_VBcmL-gmN2jfZk8hI9nMyic9ayIV3a5EjYdiOMN5usqqPZ1b_MF7AUZoH1CMqY=@protonmail.com>
 <8e090a022c878ea289373959d4557a2cd0e951ca.camel@gnu.org>
Message-ID: <7e4l4N2rd-js66TJ6YslBCqsVzpjJCIQ1Oz5s3pEb-oGrj47xHuJyheESQ04NC1SOOrL_Jj9gcv1xpsIiHt1JADLH12pD31KZqvsR2yLP9Y=@protonmail.com>

Hello,

Reading the thread, I just think that https://en.wikipedia.org/wiki/Magic_number_(programming) are nice to find the file format too.

freD.

From fkfd at macaw.me  Mon Jul  6 07:32:19 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Mon, 06 Jul 2020 06:32:19 +0000
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
References: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
Message-ID: <6F6A614B-08D2-4906-B741-6A492E485BB3@macaw.me>

On July 5, 2020 10:49:55 PM UTC, Hannu Hartikainen <hannu.hartikainen+gemini at gmail.com> wrote:
>- Navigating back to a /_edit?<sed_command> URL will redo the edit,
>which
>is mostly not what you tried to do. This will probably be an issue on
>many
>gemini applications; browsers will need to consider it if applications
>become a thing.

Maybe we could try adding a volatile session token assigned to each edit request. Then, reject any other edit with the same (and other unauthorized) token.

For example:
* Client requests /twinwiki/Sandbox/_edit
* Server generates session token, a random hex string, valid for this page and this ten minutes only
* Client gets redirected to /twinwiki/Sandbox/_edit/<session_token> 
* Client asks user for sed command.
* User fills in sed command, sends request to <session_token>?<sed_command>.
* Server checks validity of token. Once verified, apply change and destroy token. Otherwise, reject.

Overall, twinwiki is way cooler than I could have imagined. If we are to continue this conversation we should probably move to the sr.ht list instead.


~fkfd

From benulo at systemli.org  Mon Jul  6 07:44:06 2020
From: benulo at systemli.org (Ben)
Date: Mon, 6 Jul 2020 11:14:06 +0430
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
References: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
Message-ID: <0f155c37-88fa-dd26-21ab-4a81027c1e02@systemli.org>

I tried opening the test instance, but none of my clients can handle it. 
Kristall says it violates protocol by using CRLF, Castor crashes, 
Alrisha shows an error, Moonlander error, asuka crashes, diohsc says the 
header is malformed, etc.

I think I finally got it to open with AV98. AV98 don't care. :D

-- 
gemini://kwiecien.us/

From hannu.hartikainen+gemini at gmail.com  Mon Jul  6 08:56:45 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Mon, 6 Jul 2020 10:56:45 +0300
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <0f155c37-88fa-dd26-21ab-4a81027c1e02@systemli.org>
References: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
 <0f155c37-88fa-dd26-21ab-4a81027c1e02@systemli.org>
Message-ID: <CANmFPekW0mJScu7T7S6xL5YwezuO9q30pPHegLT1NEdAaot_nQ@mail.gmail.com>

Oops! I didn't really read the spec thoroughly and just used println! for
the header lines. I changed all header lines to use CRLF. It should work
now.

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200706/12809d88/attachment.htm>

From defdefred at protonmail.com  Mon Jul  6 12:58:52 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 06 Jul 2020 11:58:52 +0000
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <CANmFPekW0mJScu7T7S6xL5YwezuO9q30pPHegLT1NEdAaot_nQ@mail.gmail.com>
References: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
 <0f155c37-88fa-dd26-21ab-4a81027c1e02@systemli.org>
 <CANmFPekW0mJScu7T7S6xL5YwezuO9q30pPHegLT1NEdAaot_nQ@mail.gmail.com>
Message-ID: <NA0Ai3TFDQxX0-lqxQPjrrs-l_67u9Q8kKADMi9OC8nkuQKvJW9di8vZJPk97VyN8Pz_Ar7bvKk1yHtTqyOiJ5ZnkXmSM7OtvR0PEiX5v3c=@protonmail.com>

Ok with Geminaut.

"Edit mode" should display the document with line number :-)

freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200706/094dde1b/attachment.htm>

From defdefred at protonmail.com  Mon Jul  6 12:59:34 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 06 Jul 2020 11:59:34 +0000
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <NA0Ai3TFDQxX0-lqxQPjrrs-l_67u9Q8kKADMi9OC8nkuQKvJW9di8vZJPk97VyN8Pz_Ar7bvKk1yHtTqyOiJ5ZnkXmSM7OtvR0PEiX5v3c=@protonmail.com>
References: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
 <0f155c37-88fa-dd26-21ab-4a81027c1e02@systemli.org>
 <CANmFPekW0mJScu7T7S6xL5YwezuO9q30pPHegLT1NEdAaot_nQ@mail.gmail.com>
 <NA0Ai3TFDQxX0-lqxQPjrrs-l_67u9Q8kKADMi9OC8nkuQKvJW9di8vZJPk97VyN8Pz_Ar7bvKk1yHtTqyOiJ5ZnkXmSM7OtvR0PEiX5v3c=@protonmail.com>
Message-ID: <K9Dmbtd7v_5C4BmN7bAQHQAg2ywPlDkasFWCJEuIPHYLYr_MMw0BdRKGV5EGIats-c184mYmbZUW3qdtKi0gLbTBah0ZfS-ED7_vaEwA10I=@protonmail.com>

and edit CGI should prevent multiple execution of the same command :-)

freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200706/85ce323a/attachment.htm>

From defdefred at protonmail.com  Mon Jul  6 13:11:52 2020
From: defdefred at protonmail.com (defdefred)
Date: Mon, 06 Jul 2020 12:11:52 +0000
Subject: Geminaut
Message-ID: <7ZzYsSc6AXRyargGKDdNUweBX2CSw6SmHXHL6YZ4DUQu6fEWlm0Em_Kr85dtCYRapY20G6RGXfwaTrrB4bixQJ-dAxC2FYsVU24uc6FGsmA=@protonmail.com>

Hey Luke,

Will it be difficult to add the capability to display clicked image on the right inside the Geminaut view instead of external viewer?

Like a panel that dont scroll with the rest of the document...

Thanks for the nice client!
freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200706/672eb320/attachment.htm>

From benulo at systemli.org  Mon Jul  6 13:40:40 2020
From: benulo at systemli.org (Ben)
Date: Mon, 6 Jul 2020 17:10:40 +0430
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <CANmFPekW0mJScu7T7S6xL5YwezuO9q30pPHegLT1NEdAaot_nQ@mail.gmail.com>
References: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
 <0f155c37-88fa-dd26-21ab-4a81027c1e02@systemli.org>
 <CANmFPekW0mJScu7T7S6xL5YwezuO9q30pPHegLT1NEdAaot_nQ@mail.gmail.com>
Message-ID: <567a8c09-666a-35b0-3fdd-59d8d50faf74@systemli.org>

On 7/6/20 12:26 PM, Hannu Hartikainen wrote:
> I changed all header lines to use CRLF. It should work now.

Looks good! Works perfectly in Kristall now

-- 
gemini://kwiecien.us/

From solderpunk at posteo.net  Mon Jul  6 13:55:36 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 06 Jul 2020 14:55:36 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <tLXRGeRZKfpbux6Hn1r4CojGP02TcMPn2J-GGavwT4zNQEzKOBc4KUNXGbxjcPVVYJDKSGba9D9C9C5wnqZlFnyswlXOMA27vpj702blIhM=@protonmail.com>
Message-ID: <C3ZK2H8JSQXW.1O20FUBNX1IT4@stilgar>

On Mon Jul 6, 2020 at 12:18 AM CEST,  wrote:
> 5 year certs sound like a good compromise to me. We can make client
> messages sufficiently scary, seeing as a five year expiry will make
> TOFU issue somewhat rare. Will you set that as a default for your
> cert tool then?

Maybe! ;)  I *do* plan to finally start work on that tool this week, by
the way.

Hopefully by 2025 we'll have agreed on a way to do smooth roll-overs
which is widely implemented!  If that does happen, and it's easily
automated (which I'd very much like it to be), maybe we can start
shifting towards less long-lived keys/certs for a extra peace of mind.

> Do you agree with my original recommendation that clients should
> auto-accept any cert once the old one has expired? This seems relevant
> here. I think it's nice for UX, although I see the obvious security
> risk.

In the absence of any other roll-over mechanism, yeah, this seems like
sane behaviour for a TOFU client.

Cheers,
Solderpunk


From dave at ratfactor.com  Mon Jul  6 15:09:17 2020
From: dave at ratfactor.com (Dave Gauer)
Date: Mon, 6 Jul 2020 10:09:17 -0400
Subject: Minimal client
In-Reply-To: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
References: <CAOH6EB8kzin-ZqaMQa9_K4Swasj=wedJ-BmAvSNxKOFFSGougQ@mail.gmail.com>
Message-ID: <dd671278-c451-7e8c-b9e2-1a0b68b7a6e4@ratfactor.com>

On 7/1/20 6:06 PM, Phil Leblanc wrote:
> Hi all,
> 
> I am looking for a solution to build a _small_, _statically linked_,
> minimal gemini client. My focus at the moment is to implement the
> basic communication layer (including TLS!): just enough to send a
> request to a gemini host and receive a response.


I have long been planning to do the same thing, but haven't even 
started. The plan was to write it in Rust and use this:

https://github.com/ctz/rustls

Copied from README.md:
=================================================================
## Current features

* TLS1.2 and TLS1.3.
* ECDSA, Ed25519 or RSA server authentication by clients.
* ECDSA, Ed25519 or RSA server authentication by servers.
* Forward secrecy using ECDHE; with curve25519, nistp256 or nistp384 curves.
* AES128-GCM and AES256-GCM bulk encryption, with safe nonces.
* ChaCha20-Poly1305 bulk encryption 
([RFC7905](https://tools.ietf.org/html/rfc7905)).
* ALPN support.
* SNI support.
* Tunable MTU to make TLS messages match size of underlying transport.
* Optional use of vectored IO to minimise system calls.
* TLS1.2 session resumption.
* TLS1.2 resumption via tickets (RFC5077).
* TLS1.3 resumption via tickets or session storage.
* TLS1.3 0-RTT data for clients.
* Client authentication by clients.
* Client authentication by servers.
* Extended master secret support (RFC7627).
* Exporters (RFC5705).
* OCSP stapling by servers.
* SCT stapling by servers.
* SCT verification by clients.
=================================================================

Statically linked, yes. But I have no idea if it would meet the _small_ 
goal!

-Dave

From solderpunk at posteo.net  Mon Jul  6 15:32:01 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 06 Jul 2020 16:32:01 +0200
Subject: Minimal client
In-Reply-To: <dd671278-c451-7e8c-b9e2-1a0b68b7a6e4@ratfactor.com>
Message-ID: <C3ZM4B3ZUK4I.12JCB421QWF78@stilgar>

On Mon Jul 6, 2020 at 4:09 PM CEST, Dave Gauer wrote:

> Statically linked, yes. But I have no idea if it would meet the _small_
> goal!

Hitting statically linked, small, and good TLS support simultaneously
seems a little tricky.  Which is a shame.  Go produces static
executables and has a pretty nice TLS library (with ED25519 support in
the latest releases), but the executables sure ain't small.  Something
written in C using one of the TLS libraries targetting embedded systems
seems the safest bet.

Cheers,
Solderpunk


From laurens at daemon.be  Mon Jul  6 15:35:32 2020
From: laurens at daemon.be (Laurens Vets)
Date: Mon, 06 Jul 2020 07:35:32 -0700
Subject: Removing expiry dates for TOFU
In-Reply-To: <tLXRGeRZKfpbux6Hn1r4CojGP02TcMPn2J-GGavwT4zNQEzKOBc4KUNXGbxjcPVVYJDKSGba9D9C9C5wnqZlFnyswlXOMA27vpj702blIhM=@protonmail.com>
References: <C3Z069NVF98Q.3VMDOCAM9Z8Q1@stilgar>
 <tLXRGeRZKfpbux6Hn1r4CojGP02TcMPn2J-GGavwT4zNQEzKOBc4KUNXGbxjcPVVYJDKSGba9D9C9C5wnqZlFnyswlXOMA27vpj702blIhM=@protonmail.com>
Message-ID: <172e22be303f6ea3053a5cbca4d7a9b2@daemon.be>

On 2020-07-05 15:18, colecmac at protonmail.com wrote:
> 5 year certs sound like a good compromise to me. We can make client
> messages sufficiently scary, seeing as a five year expiry will make
> TOFU issue somewhat rare. Will you set that as a default for your
> cert tool then?
> 
> Do you agree with my original recommendation that clients should
> auto-accept any cert once the old one has expired? This seems relevant
> here. I think it's nice for UX, although I see the obvious security 
> risk.

Also not that soon(-ish) Apple, Google & Mozilla browsers will _only_ 
accept certificates with a valid lifetime of maximum 1 year effectively 
making this a "standard". While not necessarily relevant to Gemini 
directly, it's something to keep in mind.

From colecmac at protonmail.com  Mon Jul  6 15:41:24 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 06 Jul 2020 14:41:24 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <C3ZK2H8JSQXW.1O20FUBNX1IT4@stilgar>
References: <C3ZK2H8JSQXW.1O20FUBNX1IT4@stilgar>
Message-ID: <NjzH5EcfLa84igEgXweniOBVYaSbvGkMXy8ngS_OS5ZmAmFpIdIzLd3i1VbZWK08g5OyToKRCMHA9ZZsr10rq7RRlTLfrMAcbyxgJA5nvdo=@protonmail.com>

Good to hear, thanks! Now we just have to get all the servers
to switch over...

makeworld

??????? Original Message ???????
On Monday, July 6, 2020 8:55 AM, Solderpunk <solderpunk at posteo.net> wrote:

> On Mon Jul 6, 2020 at 12:18 AM CEST, wrote:
>
> > 5 year certs sound like a good compromise to me. We can make client
> > messages sufficiently scary, seeing as a five year expiry will make
> > TOFU issue somewhat rare. Will you set that as a default for your
> > cert tool then?
>
> Maybe! ;) Ido plan to finally start work on that tool this week, by
> the way.
>
> Hopefully by 2025 we'll have agreed on a way to do smooth roll-overs
> which is widely implemented! If that does happen, and it's easily
> automated (which I'd very much like it to be), maybe we can start
> shifting towards less long-lived keys/certs for a extra peace of mind.
>
> > Do you agree with my original recommendation that clients should
> > auto-accept any cert once the old one has expired? This seems relevant
> > here. I think it's nice for UX, although I see the obvious security
> > risk.
>
> In the absence of any other roll-over mechanism, yeah, this seems like
> sane behaviour for a TOFU client.
>
> Cheers,
> Solderpunk



From solderpunk at posteo.net  Mon Jul  6 15:36:46 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 06 Jul 2020 16:36:46 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <172e22be303f6ea3053a5cbca4d7a9b2@daemon.be>
Message-ID: <C3ZM7XX0J4VT.LJIDL1F17VK9@stilgar>

On Mon Jul 6, 2020 at 4:35 PM CEST, Laurens Vets wrote:

> Also not that soon(-ish) Apple, Google & Mozilla browsers will _only_
> accept certificates with a valid lifetime of maximum 1 year effectively
> making this a "standard". While not necessarily relevant to Gemini
> directly, it's something to keep in mind.

Yes, the CA/Browser forum (https://cabforum.org/) is really pushing for
shorter certificate lifespans.  It makes a good amount of sense if you
buy into the whole CA system.  I think under a TOFU scheme the structure
of incentives and risks is pretty different.  At least in these early
days where there's no widespread agreement and implementation on ways to
rotate keys more regularly without training users to always click
through any warning they see, I think using longer lived certs has
definite upsides.

Cheers,
Solderpunk

From dave at ratfactor.com  Mon Jul  6 15:57:01 2020
From: dave at ratfactor.com (Dave Gauer)
Date: Mon, 6 Jul 2020 10:57:01 -0400
Subject: Minimal client
In-Reply-To: <C3ZM4B3ZUK4I.12JCB421QWF78@stilgar>
References: <C3ZM4B3ZUK4I.12JCB421QWF78@stilgar>
Message-ID: <b2304ed6-e0d1-bf8a-bda3-f32a80219ce0@ratfactor.com>

On 7/6/20 10:32 AM, Solderpunk wrote:
> On Mon Jul 6, 2020 at 4:09 PM CEST, Dave Gauer wrote:
> 
>> Statically linked, yes. But I have no idea if it would meet the _small_
>> goal!
> 
> Hitting statically linked, small, and good TLS support simultaneously
> seems a little tricky.  Which is a shame.


Indeed!  I was curious, so I built the "TLS client" example in the 
rustls repo.  It compiles in the following 32 crates:

aho-corasick, atty, base64, cfg-if, ct-logs, docopt, env_logger, 
humantime, lazy_static, log, memchr, mio, once_cell, quick-error, quote, 
regex, regex-syntax, ring, rustls, rustls-mio, sct, serde, serde_derive, 
spin, strsim, syn, termcolor, thread_local, unicode-xid, untrusted, 
webpki, webpki-roots

(Note things like webpki are used in the example.)

A `--release` build comes to 6,844,552 bytes. So no, not small.

-Dave

From lazar.michael22 at gmail.com  Tue Jul  7 04:20:23 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Mon, 6 Jul 2020 23:20:23 -0400
Subject: Removing expiry dates for TOFU
In-Reply-To: <be4b0efd64dbdaea89b5a37b39f92773@posteo.net>
References: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>
 <be4b0efd64dbdaea89b5a37b39f92773@posteo.net>
Message-ID: <CAFTy05awUdNz6hx++0F8nX+vN8DDEQj2VgTb1Q+1Ovkowft4Lw@mail.gmail.com>

On Sun, Jul 5, 2020 at 1:17 PM Solderpunk <solderpunk at posteo.net> wrote:
> Using the same keypair for a very long time is generally considered a
> bad idea, as it increases both the risk of key compromise and the
> duration for which a stolen key can be exploited. There's also the issue of
> ownership of domain names changing over long timespans, and former legitimate
> domain owners being able to impersonate new legitimate domain owners with old
> certificates. Even CA certificates have expiry dates.

Is this actually true for TOFU certificates? SSH fingerprints don't expire [1].

Servers can still rotate key pairs without introducing the attack vector of
expiring the old ones [2]. As soon as a client connects to a server and accepts
the new keypair, any old certs should automatically become invalid to that
client, because they're not the trusted "first-use" certificate anymore. It's
not like a CA system where there can be multiple valid keypairs live at the
same time. This is also true for transferring domain ownership.

An attacker can only continue to exploit a client until they visit the real
server. If the client never visits the real server, the attacker can just swap
out the expired certificate with a new self-signed certificate and it will look
like a harmless key rotation. Expiration doesn't gain you anything there.

I get the point about encryption algorithms becoming insecure over time and
private keys more likely to be stolen. I just don't understand the advantage to
key rotation + expiring the old keys vs. simple key rotation by itself.

[1] https://tools.ietf.org/html/rfc4716

[2] The attack vector being something like this: Your server rotates key pairs
every 60 days and issues certificates with a 90 day expiration. I visit your
server once and then don't come back for 90 days. My client sees that the
fingerprint in my local TOFU database is expired, and probably accepts whatever
server sends me. This scenario is dramatically lessened with > 1 year expiration
times, but why allow it to happen at all?

> One idea I had, which could be neat for people who are really serious
> about good, long-term identity management without CAs, is the following:
> generate a key pair, for use as an ephemeral signing key, and a
> self-signed certificate for the public key with 100 years of validity.
> Then generate 100 additional keypairs, and use the signing key to sign
> certificates for them with a validity of, say, 1 year each, and
> consecutive validity periods.  Permanently delete the signing key, but
> keep the self-signed certificate.  Move all the 1 year keys to a USB
> stick, and transfer them one at a time, as they become valid, to your
> server.  For the next 100 years, serve up a two certificate long chain,
> with the self-signed cert for the signing key, plus your currently
> active 1 year cert signed with the signing key.  Once a client
> TOFU-accepts the signing key's certificate, they'll be able to validate
> all the annual key roll overs as originating from the same party, even
> if they don't visit your site for 10 years at a time.  Someone who
> breaks into your server can steal this year's key, but not any future
> keys, because they're on the USB stick, so their ability to impersonate
> you is strictly time-limited.  Nobody can steal the original signing key
> and make their own certificate which will be accepted by TOFU clients,
> because it's been deleted.  Hijacking this identity basically requires
> stealing the physical USB key.  This sounds like a lot of work, but
> generating all the keys and certs could be trivially automated.

You would need some overlap in the validity periods to allow time to swap out
the keys on the server.

Honestly though, this sounds like an obtuse way to avoid using a CA. Once you
are employing certificate chains is it really self-signed anymore? Generate
your own CA with a 100-year expiration and stick *that* on the USB drive. You
could even maintain your own certificate revocation list! Utilizing CAs does
not need to imply trusting the root browser CAs.

best,
mozz

From colecmac at protonmail.com  Tue Jul  7 04:29:37 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 07 Jul 2020 03:29:37 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <CAFTy05awUdNz6hx++0F8nX+vN8DDEQj2VgTb1Q+1Ovkowft4Lw@mail.gmail.com>
References: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>
 <be4b0efd64dbdaea89b5a37b39f92773@posteo.net>
 <CAFTy05awUdNz6hx++0F8nX+vN8DDEQj2VgTb1Q+1Ovkowft4Lw@mail.gmail.com>
Message-ID: <PdTD0bMzM0wqsOqF_KOR_omnLahUqUmtL5EtCJaqT8RB7Qfuzf7JCU_JfA7MTPk3fRhyVJwdXhAX8ttfi9GWbs-Rk103UWSLNp_MW6KuEAw=@protonmail.com>

> Servers can still rotate key pairs without introducing the attack vector of
> expiring the old ones [2].

> I just don't understand the advantage to
> key rotation + expiring the old keys vs. simple key rotation by itself.

Thanks for chiming in mozz!

How can a server rotate a keypair and prove it's still the same server
as before, that there's not an MITM attack going on? This is a genuine question,
I haven't heard much about key rotation for TLS before. Could you explain or
send a link on how this works? I can't find much on it.

Thanks,
makeworld

From tom.karpiniec at outlook.com  Tue Jul  7 05:26:48 2020
From: tom.karpiniec at outlook.com (Thomas Karpiniec)
Date: Tue, 7 Jul 2020 04:26:48 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <PdTD0bMzM0wqsOqF_KOR_omnLahUqUmtL5EtCJaqT8RB7Qfuzf7JCU_JfA7MTPk3fRhyVJwdXhAX8ttfi9GWbs-Rk103UWSLNp_MW6KuEAw=@protonmail.com>
References: <zGHyRxi0C-SOQKGCszAJNDjDG-nNneodEEOLQEAWz7eOGF8mV0P87_vm2yfuAZOX8nWmlB156j6VZsafL-QfPI1T3o36-xkrVpNzUYpwlfw=@protonmail.com>
 <be4b0efd64dbdaea89b5a37b39f92773@posteo.net>
 <CAFTy05awUdNz6hx++0F8nX+vN8DDEQj2VgTb1Q+1Ovkowft4Lw@mail.gmail.com>
 <PdTD0bMzM0wqsOqF_KOR_omnLahUqUmtL5EtCJaqT8RB7Qfuzf7JCU_JfA7MTPk3fRhyVJwdXhAX8ttfi9GWbs-Rk103UWSLNp_MW6KuEAw=@protonmail.com>
Message-ID: <MN2PR07MB6655E917EA3DA3DFEDF83DE1E4660@MN2PR07MB6655.namprd07.prod.outlook.com>

> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of
> colecmac at protonmail.com
> How can a server rotate a keypair and prove it's still the same server as
> before, that there's not an MITM attack going on? This is a genuine question,
> I haven't heard much about key rotation for TLS before. Could you explain or
> send a link on how this works? I can't find much on it.

This thread feels like it's trying to hack certificate validation into doing something for which it really wasn't intended, operating without a CA. Getting this right is likely to be more complicated than any aspect of the Gemini protocol itself.

The spec:
> the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).

Could I gently push back on the idea that getting an LE certificate is a high barrier to entry? Configuring certbot is relatively easy and a known quantity. Cleaning up after my private key is lost or exposed is an open ended problem with no easy solutions. I know there is a diversity of opinions/priorities but my vote would be to lean on the regular CA infrastructure so that we don't have to tussle with all of the scenarios currently being discussed.

More broadly, Gemini is a magnificent hack to co-opt the best of both gopher and the web into a carefully calibrated new thing, leaning on existing technologies like URLs, MIME types and TLS for expedience. LetsEncrypt is a magnificent hack to the CA system, providing all the benefits to us at no monetary cost, and that was no small undertaking. I don't think it should fall to Gemini, and therefore the implementors of Gemini clients and servers, to "fix" TLS trust. A good solution, once it is actually adopted, is likely to apply to all TLS servers rather than Gemini alone. Provided we are using TLS libraries we can take advantage of whatever that happens to be.

If nothing else, clients could attempt to verify the provided cert/chain against the system's trusted root CAs. If this takes precedence over TOFU it offers an escape hatch for anybody who wanted to try the self-signed thing and then it didn't work out. Nothing I've suggested here is _contrary_ to the spec as it stands - it's just a question of what people do by default, which hopefully won't set them up for failure later.

Cheers, Tom


From solderpunk at posteo.net  Tue Jul  7 10:30:20 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 07 Jul 2020 11:30:20 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <MN2PR07MB6655E917EA3DA3DFEDF83DE1E4660@MN2PR07MB6655.namprd07.prod.outlook.com>
Message-ID: <C40ABV74L8W6.2R14KJAURINIG@stilgar>

On Tue Jul 7, 2020 at 6:26 AM CEST, Thomas Karpiniec wrote:

> Could I gently push back on the idea that getting an LE certificate is a
> high barrier to entry? Configuring certbot is relatively easy and a
> known quantity. Cleaning up after my private key is lost or exposed is
> an open ended problem with no easy solutions. I know there is a
> diversity of opinions/priorities but my vote would be to lean on the
> regular CA infrastructure so that we don't have to tussle with all of
> the scenarios currently being discussed.

This opinion has been expressed in the past - in fact, by Michael Lazar
if I remember rightly?  The extent to which Geminispace at large has
been interested in trying to breakaway from the "centralised oligarchy
of CAs" has changed.  I'd love to have detail stats on the actual
proportion of servers using self-signed vs CA-signd certs over time!
There seems to be more enthusiasm behind TOFU at the moment than
at other times in the relatively recent past.

The spec is deliberately, for now, quite open ended on this.  I didn't
want to force people to implement TOFU, which has proven less trivial
than I first imagined.  But I also didn't want server operators who do
choose to experiment with it to become second class citizens of
Geminispace, with most clients throwing up scary warnings every time.

> If nothing else, clients could attempt to verify the provided cert/chain
> against the system's trusted root CAs. If this takes precedence over
> TOFU it offers an escape hatch for anybody who wanted to try the
> self-signed thing and then it didn't work out. Nothing I've suggested

In generally agree with you here.  This allows folks without
philosophical/political axes to grind to just setup certbot and know it
will work smoothly (which it doesn't with pure TOFU clients, which will
trigger warnings regularly)  The only reason AV-98 doesn't do this, and
forces you to manually switch between the two modes, is that the
standard Python ssl module doesn't allow it (at least not gracefully,
without making a new connection after one fails).

> This thread feels like it's trying to hack certificate validation into
> doing something for which it really wasn't intended, operating without a
> CA. Getting this right is likely to be more complicated than any aspect
> of the Gemini protocol itself.

I have been thinking this myself lately.  Not that I want to give up on
TOFU, but that all the more clever/elegant ways of doing it which
involve certificate chains are actually not the way to go: they might be
solid security wise, but no TLS library is going to support them out of
the box.  They *might* be easily implemented with a library which
exposes signature validation functions nicely, but those will be rare,
and further more programmers who understand how to do that properly will
be even rarer, running the risk of bad implementations.

My current thinking is that any recommended approach should avoid
treating certificates as anything more than than opaque binary blobs as
much as possible (for the purposes of trust management, I mean).  The
various ideas around serving future certificates on a well-known
endpoint for some time before they become valid fits in with this.  It
just involves fetching a pile of bytes and hashing it, no understanding
of keys/signing on the part of the client author required...

> A good solution, once it
> is actually adopted, is likely to apply to all TLS servers rather than
> Gemini alone.

I'm not too sure about this.  Solutions which work in an environment
dominated by dissemination of publically available information
(Geminispace, I hope) may not work acceptably well in an environment
dominated by private conversations (email, and a lot of the web).  I
suspect it's a lot easier to come up with something relatively simple
that works for us which most other TLS servers will be disinterested in.

Cheers,
Solderpunk

From solderpunk at posteo.net  Tue Jul  7 10:53:34 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 07 Jul 2020 11:53:34 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <CAFTy05awUdNz6hx++0F8nX+vN8DDEQj2VgTb1Q+1Ovkowft4Lw@mail.gmail.com>
Message-ID: <C40ATNDKIE71.323OYSY8RE86E@stilgar>

On Tue Jul 7, 2020 at 5:20 AM CEST, Michael Lazar wrote:

> Servers can still rotate key pairs without introducing the attack vector
> of
> expiring the old ones [2]. As soon as a client connects to a server and
> accepts
> the new keypair, any old certs should automatically become invalid to
> that
> client, because they're not the trusted "first-use" certificate anymore.
> It's
> not like a CA system where there can be multiple valid keypairs live at
> the
> same time. This is also true for transferring domain ownership.

You're right that TOFU clients should in general only have a single
actively trusted key on record for each server.

I guess I see the main utility of explicit expiration dates in this
context as being a kind of promise from the sever admin that "I have no
plans to do a key rotation for about this length of time".  This means
that apparent MITM attacks happening at a time when there's a lot of
validity left can be treated with much higher suspicion.

> You would need some overlap in the validity periods to allow time to
> swap out
> the keys on the server.

Sure.

> Honestly though, this sounds like an obtuse way to avoid using a CA.
> Once you
> are employing certificate chains is it really self-signed anymore?
> Generate
> your own CA with a 100-year expiration and stick *that* on the USB
> drive.

Well, that's sort of what that idea is, at core: being your own CA.
TOFU clients treating certificates that they've trusted once as CAs
of very limited power (only able to sign future certs for that one
domain, and perhaps only good for a single signature) is an interesting
way to get from "trusting on blind faith everytime a new cert comes down
the line" to "trusting on blind faith once at the very beginning and
then building up strong trust over time that you're always interacting
with the same party".  That second situation, if we can get there, is, I
would argue, good enough for Geminispace - and, arguably, a lot more
like how trust in the real world works.

Cheers,
Solderpunk


From solderpunk at posteo.net  Tue Jul  7 11:14:30 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 07 Jul 2020 12:14:30 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <C40ATNDKIE71.323OYSY8RE86E@stilgar>
Message-ID: <C40B9OGF2BVL.37E26R39CC4TD@stilgar>

A proposal: "TOFU-TOTS".  You know, like tater tots, but without
potatoes in them.  Or rather, trust-on-first-use augmented by
trust-over-time-and-space.

Desiderata:

* Limit actions of blind faith to a single point in time.
* Allow ever more trust to slowly, organically build up after that
  point.
* Permit fully automated regular key rotation on servers.
* Don't require client authors to write code to validate signatures.

Assumptions:

* MITM attacks limited to a single network for a short duration of time
  are a plausible threat, but MITM attacks which target an individual
  user no matter which network their using are extremely hard, and even
  on a single network (home ISP, say), MITM attacks which last for
  months or years require dedication and are more likely to be
  whistleblown.

Quick description:

* Certs last for several years
* The very first time you connect to a server (or the first time after
  so long that all your previous knowledge about that server is badly
  out of date), blindly accept whatever you get.
* New keys and certs are generated 1 year before they become valid
  (consecutive certs have maybe 1 month of overlapping validity to allow
  for change over)
* New certs, or their fingerprint, are served on a well-known end point
  immediately after generation, i.e. for roughly one year before their
  validity begins.
* TOFU-TOTS clients have a "trust maintenance" procedure which should be
  run, say, once a month, or maybe every 3 months.  Fancy clients can do
  this automatically in the background on a separate thread.  Simple
  clients can just keep track of when this was last run, check that
  against the current date on startup and say "Hey, you haven't done
  trust maintenance in a while, wanna do it now?  Y/N" without bothering
  with threads.  Users who are security nerds should be able to run it
  on demand whenever they like.
* Trust maintenance involves:
    - Removing expired certificates from the TOFU database
    - If a non-expired cert in the DB has less than 1 year of validity
      left, hit the server's well known endpoint and, assuming that
      transaction takes place using a previously trusted cert, store the
      cert/fingerprint you see at that endpoint, along with a counter of
      how many times you've observed it.
    - If the same well known endpoint ever serves up different future
      certificates while the same current certificate is valid, "warn
      hard".
* When a new cert comes down the line, "warn hard" if it's completely
  out of the blue.  Accept it silently if it's been pre-advertised by
  the appropriate server at least N times previously (perhaps "warn
  softly" if it's been advertised less than N times but at least once),
  and delete that server's previously trusted cert (possibly
  incrementing a counter of the number of trusted roll-overs this server
  has achieved, permitting the option to "warn extremely hard" if we
  ever get an out of the blue cert change for a server which has
  previously done the right thing multiple times).

Properties:

* Meets all desiderata above.
* If I steal your private key, I can straightforwardly use this in
  attacks only until your current cert expires - not forever, as
  would be the case with 100 year certs.
* In order to extend the time I can exploit the stolen key, I need to
  successfully MITM every possible future victim of my attacks, for
  multiple executions of their trust maintenance routine, which happen
  at unpredictable times, over the course of a year, possibly from
  multiple different networks, and I can't do this if I steal your key
  in its final year of validity, because victims will have already
  picked up the true next certificate at least once - this is a big
  improvement over roll-over schemes where new certificates are signed
  with the private key of the old certificate, in which case once I've
  stolen your key it's trivial for me to just sign myself future
  certificates which anybody will accept - and I can keep doing this,
  forever, spinning a single key breach out indefinitely despite
  regular rotation!
* Clients are, as always, vulnerable to undetected MITM attacks on that
  very first connection, but such an attack can be fairly easily
  discovered after the fact (providing a strong disincentive for e.g.
  commercial ISPs to do them regularly) unless the attacker commits to a
  clean exit by MITMing you multiple times in the future to feed you the
  legitimate next cert.

Right now, I think this provides pretty good robustness against MITM
attacks relative to how conceptually complicated it is - nothing is
involved on the server side except generating stand-alone self-signed
certs and copying them at the right time into the document root, which
is very easily automated, and nothing is involved on the client side
except storing hashes of entire certs in a DB and checking expiry dates.
Client authors never have to write their own signature validation code,
so this can be done even with TLS libraries that don't make that easy.
It also has the advantage of keeping TLS network overhead as low as
possible by having servers only ever send a single cert.

But, maybe I've overlooked something.  Feedback welcome.

Cheers,
Solderpunk


From natpen at natpen.net  Tue Jul  7 12:30:14 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Tue, 7 Jul 2020 07:30:14 -0400
Subject: Removing expiry dates for TOFU
In-Reply-To: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
References: <MN2PR07MB6655E917EA3DA3DFEDF83DE1E4660@MN2PR07MB6655.namprd07.prod.outlook.com>
 <C40ABV74L8W6.2R14KJAURINIG@stilgar>
Message-ID: <20200707113014.GA448287@goldfish.localdomain>

On Tue, Jul 07, 2020 at 11:30:20AM +0200, Solderpunk wrote:
> I'd love to have detail stats on the actual proportion of servers
> using self-signed vs CA-signd certs over time! There seems to be
> more enthusiasm behind TOFU at the moment than at other times in the
> relatively recent past.

I can gladly start tracking this with the next GUS crawl, but we're
getting beyond my expertise. I have a very lightly modified version
[0] of Jason McBrayer's gusmobile [1] (in Python) that I think has
been, thankfully, the sole arbiter of all things TLS for GUS. If
anyone is interested in altering that code, or helping me figure out
how to alter that code, to return info on self-signed vs CA-signed
distinctions, we could get statistics on this soon.

[0] https://git.sr.ht/~natpen/gusmobile
[1] https://git.carcosa.net/jmcbray/gusmobile/

From jmcbray at carcosa.net  Tue Jul  7 15:03:31 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 07 Jul 2020 10:03:31 -0400
Subject: Removing expiry dates for TOFU
In-Reply-To: <20200707113014.GA448287@goldfish.localdomain> (Natalie
 Pendragon's message of "Tue, 7 Jul 2020 07:30:14 -0400")
References: <MN2PR07MB6655E917EA3DA3DFEDF83DE1E4660@MN2PR07MB6655.namprd07.prod.outlook.com>
 <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <20200707113014.GA448287@goldfish.localdomain>
Message-ID: <87eepn5sng.fsf@dorothy.carcosa.net>

Natalie Pendragon <natpen at natpen.net> writes:

> I can gladly start tracking this with the next GUS crawl, but we're
> getting beyond my expertise. I have a very lightly modified version
> [0] of Jason McBrayer's gusmobile [1] (in Python) that I think has
> been, thankfully, the sole arbiter of all things TLS for GUS. If
> anyone is interested in altering that code, or helping me figure out
> how to alter that code, to return info on self-signed vs CA-signed
> distinctions, we could get statistics on this soon.
>
> [0] https://git.sr.ht/~natpen/gusmobile
> [1] https://git.carcosa.net/jmcbray/gusmobile/

If your modifications are generally useful, would you be willing to
submit a pull request (or just a git-send-email patch)? I've kind of
neglected gusmobile, to the point that it has an actual long-standing
bug that has to be worked around for the most trivial use-case. I've
been meaning to fix it, but I have so little time for hobby hacking.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From colecmac at protonmail.com  Tue Jul  7 15:34:17 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 07 Jul 2020 14:34:17 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <C40B9OGF2BVL.37E26R39CC4TD@stilgar>
References: <C40B9OGF2BVL.37E26R39CC4TD@stilgar>
Message-ID: <8r362V8ze5dkc_vk122gcx3cCC6jCbu0iQktykRJJSdlGVUoUkfwxsJ4HpXQPTCHCLhuX4AjDIfOztDWH9Q9_BAAonU48A4OKXrfO4Z5wqA=@protonmail.com>

> A proposal: "TOFU-TOTS". You know, like tater tots, but without
> potatoes in them. Or rather, trust-on-first-use augmented by
> trust-over-time-and-space.

I like this proposal, and I want to digest it more fully later, but
it also seems like this complicates what's already the most complicated
part of Gemini. Is this an optional special idea, like notaries, or are
you hoping this gets more widespread use?

Personally, I like the simpler ideas that have been used so far, combined
with something like 5 year certs.


makeworld

P.S. Can anyone explain or give me a link on TLS key rotation? How is it
different from changing certs?


From solderpunk at posteo.net  Tue Jul  7 16:39:00 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 07 Jul 2020 17:39:00 +0200
Subject: [ANN] twinwiki, a Gemini wiki edited with sed commands
In-Reply-To: <CANmFPemKtTiYrC+=w7aq6qgXMHbhzb4O_axSnsB624fuiUEV2g@mail.gmail.com>
Message-ID: <C40I64YJ29HC.306D6VQSHM4O0@stilgar>

On Mon Jul 6, 2020 at 12:49 AM CEST, Hannu Hartikainen wrote:
> Hi!
>
> I'm announcing my first proper piece of Gemini software: twinwiki!
>
> The general idea is that a single line of input[1] works for very few
> text
> editing interfaces, yet most of us know one: sed. Mostly people use a
> very
> small subset of sed. Here I've implemented a slightly larger subset and
> I
> feel you could actually edit pages quite well if the browser showed line
> numbers.

Kiitos t??st?!  Eritt?in kiva idee.  Obviously this sed-based approach
is viable for a narrow slice of people, but in general this is a mindset
that I would like to see become part of "Gemini culture", i.e. embracing
constraints and coming up with creative ways to work within them.

I've added this to the software list, and while I was at it, broke all
CGI applications (at least the ones I recognised as being CGI
applications) out into their own section.  If you've written a CGI tool
for Gemini and I don't have it listed, please let me know.

Cheers,
Solderpunk

From baschdel at disroot.org  Tue Jul  7 18:06:07 2020
From: baschdel at disroot.org (Baschdel)
Date: Tue, 7 Jul 2020 19:06:07 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <C40B9OGF2BVL.37E26R39CC4TD@stilgar>
References: <C40B9OGF2BVL.37E26R39CC4TD@stilgar>
Message-ID: <6c0fae77-a0c4-5c1e-c34a-0918c572b9f6@disroot.org>

I really like the way of announcing future certificates by putting them 
in a well known location (not just their fingerprint, as this requires 
either the server or the client (probably both) to support multiple 
fingerprinting algorithms because even if we agree on one hash algorithm 
today, there are already people trying to break it and updating that 
will be a mess).

That said the name of this well known location should include the name 
tls somewhere to keep the door open for potential tls replacements (I 
think TLS is a great choice, but if something else emerges I don't want 
to bother with legacy magic paths).

There are also three other certificates besides the future one that 
could/should be served at a well known location:

- Alternative (Backup) certificates for both the current and future 
certificate, that can be used when the key behind the original 
certificate was compromised, they have to be valid for the same 
time-span as the originals and become the originals as soon as they are 
used. The private keys of these of course should be kept in cold storage 
until they are needed. Clients should at least notify the user when they 
see a backup certificate being used and treat the original certificate 
as untrusted but not delete it immanently (as it is possible that only 
the backup key was compromised and still be used by the original 
server). The user must have the ultimate choice which certificate to 
trust after a backup certificate has been used as which certificate is 
trustable should be communicated out of band in such a case.

- The currently used certificate that could be checked by clients to 
detect general purpose dragnet TLS interception, that knows nothing 
about Gemini and its conventions (basically what I'd do if I was the 
dictator of a surveillance state to monitor and censor internet access 
for thousands or millions of people). This too could also be useful if 
some TLS alternative emerges, you already trust one key the server uses, 
so why not use that to get the other keys it uses. Another possible 
usecase is that someone really concerned could use any niche proxy 
protocol to fetch the certificate the server should have (I know 
portal.mozz.us already has a feature that allows one to fetch the server 
certificate but proxy.vulpes.one doesn't and a gemini to gemini proxy 
would have to use a well known endpoint to fetch the certificate anyway 
(but that wouldn't allow you to check if the proxy got MitMd by a lazy 
TLS interception)) To make this even more of a pain for attackers each 
server could have (a) secondary endpoint(s) that is/are only 
communicated in human readable form (i.e. generating a captcha image 
that contains the filename in a nonstandard location) that changes on a 
regular basis) that too serve(s) the certificate used with the 
possibility for a security focused client to have a tool that can 
automatically check against the certificates it trusts and the one it 
received from the server. (All of this can be realized by adding two 
configuration options to a Gemini server, or if the server doesn't 
support that symlinks should work as well).

Again, I'm just throwing Ideas around hoping that they'll be considered 
useful.

Have a nice Evening

- Baschdel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200707/f3df19bb/attachment-0001.htm>

From luke at marmaladefoo.com  Tue Jul  7 21:06:39 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 07 Jul 2020 21:06:39 +0100
Subject: [ANN] GemiNaut =?UTF-8?B?4p2k77iPIEdvcGhlciAtIGEgbmV3IHJlbGVhc2Ug?=
 =?UTF-8?B?b2YgR2VtaU5hdXQgMC44LjY=?=
Message-ID: <5F04D5CF.7070103@marmaladefoo.com>

Hi everyone

I'm pleased to announce a new release of GemiNaut 0.8.6, a particularly 
user friendly Gemini client for Windows.

The main change in 0.8.6 release is that GemiNaut now supports Gopher, 
so you can now browse Gopher space too. Due to the lack of accessible 
clients, there have perhaps not been so many Windows users exploring the 
gopher holes for many years. I've been discovering gopher space for 
myself in testing GemiNaut and whilst it is a slower medium than Gemini, 
there is quite a lot of thoughtful writing to discover. Needless to say 
gopher pages look really nice in GemiNaut which smooths over the visual 
gaps providing a common experience of gemini, gopher maps and text files.

Key changes and updates:

  - support gopher, with same theming engine as for gemini
  - search in gopher (e.g. Veronica)
  - updated faster "Fabric" theme generated directly by GemiNaut
  - scroll bars added when needed to each preformatted area as the 
window size decreases
  - auto linking of URLs in gopher text files
  - use latest gemget 0.1.3
  - other minor UI improvements and bug fixes

I'd like to put out a word of appreciation to makeworld for the gemget 
utility and the prologic guys for the go-gopher library, the latest 
versions of both of which have been incorporated.

Details and screenshots of this release:

   
gemini://gemini.marmaladefoo.com/blog/7-Jul-2020_GemiNaut_v0_8_6_release.gmi

Download binaries and source:

   https://www.marmaladefoo.com/pages/geminaut

As always feedback and improvement suggestions are welcomed.

Best Wishes

  - Luke

From luke at marmaladefoo.com  Tue Jul  7 23:22:49 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 07 Jul 2020 23:22:49 +0100
Subject: Geminaut
In-Reply-To: <7ZzYsSc6AXRyargGKDdNUweBX2CSw6SmHXHL6YZ4DUQu6fEWlm0Em_Kr85dtCYRapY20G6RGXfwaTrrB4bixQJ-dAxC2FYsVU24uc6FGsmA=@protonmail.com>
References: <7ZzYsSc6AXRyargGKDdNUweBX2CSw6SmHXHL6YZ4DUQu6fEWlm0Em_Kr85dtCYRapY20G6RGXfwaTrrB4bixQJ-dAxC2FYsVU24uc6FGsmA=@protonmail.com>
Message-ID: <5F04F5B9.20603@marmaladefoo.com>


On 06-Jul-2020 13:11, defdefred wrote:
> Will it be difficult to add the capability to display clicked image on 
> the right inside the Geminaut view instead of external viewer?
>
> Like a panel that dont scroll with the rest of the document...
>
> Thanks for the nice client!
>
Hi freD

Thanks for the feedback. Yes I am planning to build a simple image 
viewer within GemiNaut. I need a couple of tweaks to the underlying 
retrieval layer so that large downloads can be abandoned if they exceed 
some time or size limit. As we know there is no way of knowing how big a 
download will be so for images and other binary files this is much more 
a pressing problem to be solved before going on to build a UI to display 
them, than it is for text/gemini which is invariably tiny.

Best wishes

  - Luke

From defdefred at protonmail.com  Wed Jul  8 00:02:19 2020
From: defdefred at protonmail.com (defdefred)
Date: Tue, 07 Jul 2020 23:02:19 +0000
Subject: =?utf-8?Q?Re:_[ANN]_GemiNaut_=E2=9D=A4=EF=B8=8F_Gopher_-_a_new_release_of_GemiNaut_0.8.6?=
In-Reply-To: <5F04D5CF.7070103@marmaladefoo.com>
References: <5F04D5CF.7070103@marmaladefoo.com>
Message-ID: <AjrRsOe7EFjzNF2NduF7ifjsQLvrLW_Jf8jgSiHpvtww6P7JimqTLtpFY2Gv4YL4iCFE5KDMAEs1O5Ec-HJEa_Qqa2OLQ8HK0cGInIHZLLw=@protonmail.com>

Thanks!

From hannu.hartikainen+gemini at gmail.com  Wed Jul  8 00:17:44 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Wed, 8 Jul 2020 02:17:44 +0300
Subject: WIP: ANSI art modem download emulator
Message-ID: <CANmFPenthTT=fAPmJaqiYDvR6GSGUh4gsC8MkWvLZBd8M3iRAA@mail.gmail.com>

Hi again, Geminauts!

I'm playing around with streaming. I cloned a mirror of the ANSI art in
https://16colo.rs and hacked together a streaming server that emulates
modem download speed, converts content to UTF-8 and tries its best to wrap
at 80 columns since terminals are wider nowadays.

Try it with gemget or jetforce-client or some other client that supports
streaming, eg:
gemget -o- gemini://ansi.hrtk.in:2020/ansi/us-birth-of-mawu-liza.ans

The source is available on the site if someone is interested. If someone
wants to build a stable 16colo.rs mirror from that, I'd be really happy. I
care more for hacking than managing stable sites, and that site still needs
plenty of minor enhancements (starting from changing the server port...).

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200708/978d4eae/attachment.htm>

From colecmac at protonmail.com  Wed Jul  8 01:57:24 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 08 Jul 2020 00:57:24 +0000
Subject: Geminaut
In-Reply-To: <5F04F5B9.20603@marmaladefoo.com>
References: <7ZzYsSc6AXRyargGKDdNUweBX2CSw6SmHXHL6YZ4DUQu6fEWlm0Em_Kr85dtCYRapY20G6RGXfwaTrrB4bixQJ-dAxC2FYsVU24uc6FGsmA=@protonmail.com>
 <5F04F5B9.20603@marmaladefoo.com>
Message-ID: <Fbgs0HBysf6JA17ZepxswcW23igwrBvqjQ0SXVYUGZJ_njniU3lQbfjKpVVw01J6uxnU4Aetbyl3mohx5BmqvV_PUBpXut4YOrLpqDjo5Kg=@protonmail.com>

> I need a couple of tweaks to the underlying
> retrieval layer so that large downloads can be abandoned if they exceed
> some time or size limit.

Sounds like that might be on me! :)

I'll work on that this week.

Cheers,
makeworld

From colecmac at protonmail.com  Wed Jul  8 02:02:59 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 08 Jul 2020 01:02:59 +0000
Subject: WIP: ANSI art modem download emulator
In-Reply-To: <CANmFPenthTT=fAPmJaqiYDvR6GSGUh4gsC8MkWvLZBd8M3iRAA@mail.gmail.com>
References: <CANmFPenthTT=fAPmJaqiYDvR6GSGUh4gsC8MkWvLZBd8M3iRAA@mail.gmail.com>
Message-ID: <2XHuiFuZRvzrU0JSUbXcCrCW-WmzxofnJUTdvDC1-DZr9lLP1t8tc0ttOVoerUk3VNrXP6FfiJ6JSkhqFarImsnfMRyOocOMTAE4qRVf6HM=@protonmail.com>

Wow, this is great! The modem speed is a cool idea, it looks very
nice loading in like that on gemget (cool to see you using it!).

16colo.rs is cool site too, nice find.

Could you let us know in this thread if you change the port or domain?


Thanks,
makeworld

From pellertson at firemail.cc  Wed Jul  8 03:00:40 2020
From: pellertson at firemail.cc (Parker Ellertson)
Date: Tue, 7 Jul 2020 19:00:40 -0700
Subject: Change to gacme client repository
Message-ID: <20200707190040.69bcc857.pellertson@firemail.cc>

Hey I'd just like to let people know that I've changed the repository
for gacme.  I wanted to get off of github and have the code on a server
I control for my own reasons.  I will no longer be pushing any changes
to github and instead here:

https://cybertron.ninja/bitbucket/users/parker/repos/gacme/browse

Yes, that is a real domain.  It's for a company I'm starting, which I'm
more than happy to talk about in a private email.

In addition, I'll be signing all of my commits, the key to which you
can find here:

https://www.circumlunar.space/~parker/key.asc

Importing this into your keyring will be left as an exercise to the
reader.

Thanks!

~ Parker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200707/4e1db7b0/attachment.sig>

From pellertson at firemail.cc  Wed Jul  8 03:07:37 2020
From: pellertson at firemail.cc (Parker Ellertson)
Date: Tue, 7 Jul 2020 19:07:37 -0700
Subject: Change to gacme client repository
In-Reply-To: <20200707190040.69bcc857.pellertson@firemail.cc>
References: <20200707190040.69bcc857.pellertson@firemail.cc>
Message-ID: <20200707190737.6df47cb0.pellertson@firemail.cc>

On Tue, 7 Jul 2020 19:00:40 -0700
Parker Ellertson <pellertson at firemail.cc> wrote:

> Hey I'd just like to let people know that I've changed the repository
> for gacme.  I wanted to get off of github and have the code on a
> server I control for my own reasons.  I will no longer be pushing any
> changes to github and instead here:
> 
> https://cybertron.ninja/bitbucket/users/parker/repos/gacme/browse
> 
> Yes, that is a real domain.  It's for a company I'm starting, which
> I'm more than happy to talk about in a private email.
> 
> In addition, I'll be signing all of my commits, the key to which you
> can find here:
> 
> https://www.circumlunar.space/~parker/key.asc
> 
> Importing this into your keyring will be left as an exercise to the
> reader.
> 
> Thanks!
> 
> ~ Parker

And for an after-hitting-send PS: I made some updates that require an
update to the plumbing rules.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200707/7bc42669/attachment.sig>

From natpen at natpen.net  Wed Jul  8 11:58:59 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Wed, 8 Jul 2020 06:58:59 -0400
Subject: Removing expiry dates for TOFU
In-Reply-To: <87eepn5sng.fsf@dorothy.carcosa.net>
References: <MN2PR07MB6655E917EA3DA3DFEDF83DE1E4660@MN2PR07MB6655.namprd07.prod.outlook.com>
 <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <20200707113014.GA448287@goldfish.localdomain>
 <87eepn5sng.fsf@dorothy.carcosa.net>
Message-ID: <20200708105859.GA458566@goldfish.localdomain>

On Tue, Jul 07, 2020 at 10:03:31AM -0400, Jason McBrayer wrote:
> If your modifications are generally useful, would you be willing to
> submit a pull request (or just a git-send-email patch)? I've kind of
> neglected gusmobile, to the point that it has an actual long-standing
> bug that has to be worked around for the most trivial use-case. I've
> been meaning to fix it, but I have so little time for hobby hacking.

Sure, patches incoming! You can pick and choose anything that looks
useful, but honestly the reason I hadn't already submitted these
changes upstream is that most of them are hacks to make Gusmobile and
GUS play well together.

From jmcbray at carcosa.net  Wed Jul  8 12:21:52 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 08 Jul 2020 07:21:52 -0400
Subject: Removing expiry dates for TOFU
In-Reply-To: <20200708105859.GA458566@goldfish.localdomain> (Natalie
 Pendragon's message of "Wed, 8 Jul 2020 06:58:59 -0400")
References: <MN2PR07MB6655E917EA3DA3DFEDF83DE1E4660@MN2PR07MB6655.namprd07.prod.outlook.com>
 <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <20200707113014.GA448287@goldfish.localdomain>
 <87eepn5sng.fsf@dorothy.carcosa.net>
 <20200708105859.GA458566@goldfish.localdomain>
Message-ID: <877dve5k1b.fsf@dorothy.carcosa.net>

Natalie Pendragon <natpen at natpen.net> writes:

> On Tue, Jul 07, 2020 at 10:03:31AM -0400, Jason McBrayer wrote:
>> If your modifications are generally useful, would you be willing to
>> submit a pull request (or just a git-send-email patch)? I've kind of
>> neglected gusmobile, to the point that it has an actual long-standing
>> bug that has to be worked around for the most trivial use-case. I've
>> been meaning to fix it, but I have so little time for hobby hacking.
>
> Sure, patches incoming! You can pick and choose anything that looks
> useful, but honestly the reason I hadn't already submitted these
> changes upstream is that most of them are hacks to make Gusmobile and
> GUS play well together.

Thanks, I super appreciate your work!

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From petite.abeille at gmail.com  Wed Jul  8 17:57:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 8 Jul 2020 18:57:18 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
References: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
Message-ID: <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>



> On Jul 7, 2020, at 11:30, Solderpunk <solderpunk at posteo.net> wrote:
> 
> My current thinking is that any recommended approach should avoid
> treating certificates as anything more than than opaque binary blobs as
> much as possible

Perhaps of interest:

Using Raw Public Keys in Transport Layer Security (TLS)
https://tools.ietf.org/html/rfc7250



From philanc at gmail.com  Wed Jul  8 19:25:07 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 8 Jul 2020 18:25:07 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>
References: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>
Message-ID: <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>

On Wed, Jul 8, 2020 at 4:57 PM Petite Abeille <petite.abeille at gmail.com> wrote:
>
> Perhaps of interest:
>
> Using Raw Public Keys in Transport Layer Security (TLS)
> https://tools.ietf.org/html/rfc7250

Yes. Looks interesting, and it goes in the right direction.
Unfortunately, the RFC is already quite old (2014)  and according to
Wikipedia, it is only supported by GnuTLS (I didn't check directly).

Do you know if it is already used in some visible applications?

Phil

From philanc at gmail.com  Wed Jul  8 19:27:23 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 8 Jul 2020 18:27:23 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
References: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>
 <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
Message-ID: <CAOH6EB8LbF9aQ85QVe8=TZwqsRFkn6dCkXt6FpbwTM4qZUWA4w@mail.gmail.com>

On Wed, Jul 8, 2020 at 6:25 PM Phil Leblanc <philanc at gmail.com> wrote:
> according to Wikipedia, [RFC 7250] is only supported by GnuTLS

see https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

> Phil

From luke at marmaladefoo.com  Wed Jul  8 19:57:10 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Wed, 08 Jul 2020 19:57:10 +0100
Subject: Geminaut
In-Reply-To: <Fbgs0HBysf6JA17ZepxswcW23igwrBvqjQ0SXVYUGZJ_njniU3lQbfjKpVVw01J6uxnU4Aetbyl3mohx5BmqvV_PUBpXut4YOrLpqDjo5Kg=@protonmail.com>
References: <7ZzYsSc6AXRyargGKDdNUweBX2CSw6SmHXHL6YZ4DUQu6fEWlm0Em_Kr85dtCYRapY20G6RGXfwaTrrB4bixQJ-dAxC2FYsVU24uc6FGsmA=@protonmail.com>
 <5F04F5B9.20603@marmaladefoo.com>
 <Fbgs0HBysf6JA17ZepxswcW23igwrBvqjQ0SXVYUGZJ_njniU3lQbfjKpVVw01J6uxnU4Aetbyl3mohx5BmqvV_PUBpXut4YOrLpqDjo5Kg=@protonmail.com>
Message-ID: <5F061706.4030307@marmaladefoo.com>


On 08-Jul-2020 01:57, colecmac at protonmail.com wrote:
>> I need a couple of tweaks to the underlying
>> retrieval layer so that large downloads can be abandoned if they exceed
>> some time or size limit.
> Sounds like that might be on me! :)
>
> I'll work on that this week.

Hi makeworld

I just saw your recent commits on this today to gemget - that was very 
quick!  I'll take a look and see if I can get it working.

Many thanks!

  - Luke

From petite.abeille at gmail.com  Wed Jul  8 22:27:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 8 Jul 2020 23:27:37 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
References: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>
 <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
Message-ID: <FBCD1667-16A5-4A63-B57B-2DA5F728E9E7@gmail.com>



> On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
> 
> Yes. Looks interesting, and it goes in the right direction.
> Unfortunately, the RFC is already quite old (2014)  and according to
> Wikipedia, it is only supported by GnuTLS (I didn't check directly).
> 
> Do you know if it is already used in some visible applications?

Hmm, no :) Just stumbled upon it on the openssl mailing list, where someone was asking if it was supported:

RFC 7250 raw public keys?
https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html


There is an open issue for it:

Raw Public Key (RFC 7250) support
https://github.com/openssl/openssl/issues/6929


mbedtls seems to have something:

Support Raw Public Key mode (RFC7250) 
https://github.com/ARMmbed/mbedtls/pull/336

From solderpunk at posteo.net  Wed Jul  8 23:18:25 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Thu, 09 Jul 2020 00:18:25 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <FBCD1667-16A5-4A63-B57B-2DA5F728E9E7@gmail.com>
Message-ID: <C41LAHP83ET9.284908F3T32IQ@stilgar>

Thanks for sharing this!  I will read it closely.  It's a shame if it's
not widely implemented, but there may well still be good ideas in there,
or details we've overlooked.

Cheers,
Solderpunk

On Wed Jul 8, 2020 at 11:27 PM CEST, Petite Abeille wrote:
>
>
> > On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
> > 
> > Yes. Looks interesting, and it goes in the right direction.
> > Unfortunately, the RFC is already quite old (2014)  and according to
> > Wikipedia, it is only supported by GnuTLS (I didn't check directly).
> > 
> > Do you know if it is already used in some visible applications?
>
> Hmm, no :) Just stumbled upon it on the openssl mailing list, where
> someone was asking if it was supported:
>
> RFC 7250 raw public keys?
> https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html
>
>
> There is an open issue for it:
>
> Raw Public Key (RFC 7250) support
> https://github.com/openssl/openssl/issues/6929
>
>
> mbedtls seems to have something:
>
> Support Raw Public Key mode (RFC7250)
> https://github.com/ARMmbed/mbedtls/pull/336


From solderpunk at posteo.net  Wed Jul  8 23:19:44 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Thu, 09 Jul 2020 00:19:44 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <8r362V8ze5dkc_vk122gcx3cCC6jCbu0iQktykRJJSdlGVUoUkfwxsJ4HpXQPTCHCLhuX4AjDIfOztDWH9Q9_BAAonU48A4OKXrfO4Z5wqA=@protonmail.com>
Message-ID: <C41LBHY6DAYC.NU8MQJ6VTDQC@stilgar>

On Tue Jul 7, 2020 at 4:34 PM CEST,  wrote:

> I like this proposal, and I want to digest it more fully later, but
> it also seems like this complicates what's already the most complicated
> part of Gemini. Is this an optional special idea, like notaries, or are
> you hoping this gets more widespread use?

Oh!  I had thought of this as a relatively simple idea, simpler than
anything involving signatures to validate new keys.

> Personally, I like the simpler ideas that have been used so far,
> combined
> with something like 5 year certs.

What are the simpler ideas?  Just straight up TOFU with a scary message
five years later?

Cheers,
Solderpunk

From petite.abeille at gmail.com  Thu Jul  9 00:03:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 01:03:09 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <C41LAHP83ET9.284908F3T32IQ@stilgar>
References: <C41LAHP83ET9.284908F3T32IQ@stilgar>
Message-ID: <A380DB96-87B1-4589-B370-7499361F64F1@gmail.com>



> On Jul 9, 2020, at 00:18, Solderpunk <solderpunk at posteo.net> wrote:
> 
> Thanks for sharing this!  I will read it closely.  It's a shame if it's
> not widely implemented, but there may well still be good ideas in there,
> or details we've overlooked.

Another link, as a counterexample of what we are trying to escape from:

Path Building vs Path Verifying: The Chain of Pain
https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6

The Chain of Pain! :D


From petite.abeille at gmail.com  Thu Jul  9 00:08:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 01:08:09 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
References: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>
 <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
Message-ID: <A004122B-D8CB-478B-A483-6788077224D9@gmail.com>



> On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
> 
> GnuTLS

GNU: A Heuristic for Bad Cryptography
https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/

Ah! 

From philanc at gmail.com  Thu Jul  9 00:10:01 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 8 Jul 2020 23:10:01 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <FBCD1667-16A5-4A63-B57B-2DA5F728E9E7@gmail.com>
References: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>
 <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
 <FBCD1667-16A5-4A63-B57B-2DA5F728E9E7@gmail.com>
Message-ID: <CAOH6EB-ySgpXK_8vtqZxCbObLAEBgT48+g19=iFw6vXaAKzGZA@mail.gmail.com>

On Wed, Jul 8, 2020 at 9:27 PM Petite Abeille <petite.abeille at gmail.com> wrote:
>

> mbedtls seems to have something:
>
> Support Raw Public Key mode (RFC7250)
> https://github.com/ARMmbed/mbedtls/pull/336

I downloaded mbedtls (the development branch) one week ago
(2020-07-01). I grepped through the tree and found no sign of RFC7250
or RPK :-(

From philanc at gmail.com  Thu Jul  9 00:16:29 2020
From: philanc at gmail.com (Phil Leblanc)
Date: Wed, 8 Jul 2020 23:16:29 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <A004122B-D8CB-478B-A483-6788077224D9@gmail.com>
References: <C40ABV74L8W6.2R14KJAURINIG@stilgar>
 <D4BD03DD-678F-4A1E-B9B4-C1E5B481A28A@gmail.com>
 <CAOH6EB8mb1pK78Wngg3e5_YhVKx4s=v3X8SfwnEB=x1AO-VOMw@mail.gmail.com>
 <A004122B-D8CB-478B-A483-6788077224D9@gmail.com>
Message-ID: <CAOH6EB9cMu76VENzBs9QPruXf0-uEhoz2c_rF6_Ay2uVL+ffgg@mail.gmail.com>

On Wed, Jul 8, 2020 at 11:08 PM Petite Abeille <petite.abeille at gmail.com> wrote:
>
> GNU: A Heuristic for Bad Cryptography
> https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/
>
> Ah!

Nice :-)

From colecmac at protonmail.com  Thu Jul  9 00:25:58 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 08 Jul 2020 23:25:58 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <C41LBHY6DAYC.NU8MQJ6VTDQC@stilgar>
References: <C41LBHY6DAYC.NU8MQJ6VTDQC@stilgar>
Message-ID: <DzQd9r9ZSiu3dnLziuzYYNMhdZU-AK_F6epA25QGZ2TvAPNocOMDPzBc7ZbfqnxwLCzZLpR4hOY1Hq9wTDjxgOHUTKy6PM6Pl6HPc64Khwc=@protonmail.com>

On Wednesday, July 8, 2020 6:19 PM, Solderpunk <solderpunk at posteo.net> wrote:

> [...]
> > Personally, I like the simpler ideas that have been used so far,
> > combined
> > with something like 5 year certs.
>
> What are the simpler ideas? Just straight up TOFU with a scary message
> five years later?


Yes, I see that as a lot simpler. It doesn't require a well known endpoint, or
a background service for clients, etc. But I still like the idea.


makeworld


From tom.karpiniec at outlook.com  Thu Jul  9 01:39:04 2020
From: tom.karpiniec at outlook.com (Thomas Karpiniec)
Date: Thu, 9 Jul 2020 00:39:04 +0000
Subject: Removing expiry dates for TOFU
In-Reply-To: <C40B9OGF2BVL.37E26R39CC4TD@stilgar>
References: <C40ATNDKIE71.323OYSY8RE86E@stilgar>
 <C40B9OGF2BVL.37E26R39CC4TD@stilgar>
Message-ID: <MN2PR07MB6655251BF4181BF20088C08FE4640@MN2PR07MB6655.namprd07.prod.outlook.com>

> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Solderpunk
> A proposal: "TOFU-TOTS".  You know, like tater tots, but without
> potatoes in them.  Or rather, trust-on-first-use augmented by
> trust-over-time-and-space.

Setting aside that I already put my support behind the oligarchy, this is an interesting problem and I'll weigh in. :)

I agree that that this proposal would provide fairly effective protection against MITM. I worry that it is so unusual that it would push newbies away from setting up gemini servers. Faced with regular rotation requirements I suspect that many people would automate the process with cronjobs, meaning that the keys for the next certificate are sitting right there on the server ready to be nabbed.

More annoyingly, suppose the current private key is compromised and the legitimate server owner realises it - they don't have any good options. One is to put up with being spoofable until their next-advertised certificate becomes valid, which may be 10 months in the future. Otherwise they could do an out-of-turn certificate rotation, which clients will warn on just as harshly as any other unexpected change. (Further down the thread, Baschdel suggested backup certificates to alleviate this. But what if you're compromised twice? To me the complexity creep feels disproportionate to the advantages.)

A suggestion: what if instead of publishing a future certificate, we publish our own CA certificate, which is used to sign our server certificates? A client should cache this CA certificate permanently and use it to verify all future requests to that domain. A diligent system administrator will keep their CA key material offline. Someone who doesn't care so much can just generate everything on their server.

* Client logic is simpler
* Keys and certificates can be rotated at will by the sysadmin and they can choose whatever expiry they are comfortable with
* Relies on familiar concepts of TLS trust ("oh I'm my own CA, okay") and sysadmins can choose their own level of caution
* Uses the existing feature of TLS libraries to verify a connection against a given CA. Clients don't have to handle public keys or fingerprints - they just download the CA certificate and feed it into their TLS library.
* Combines neatly with LetsEncrypt-style certificate management - you are just adding one extra trusted CA. If it can be verified by either that, or one of the normal roots, then you're okay.
* Only slightly more complicated openssl commands required when setting up a server

Cheers, Tom

From defdefred at protonmail.com  Thu Jul  9 07:42:01 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 09 Jul 2020 06:42:01 +0000
Subject: About limiting the non human internet bandwidth pollution
Message-ID: <LqaP51mG2jDcO3jCMBsMcOy4PmJ93UHXmTmVHIgAymIpm2kM46mPt7lXdslaPqSOkrBHcUDZQ5nNUhX3mggdBinb_ngzUmzVImG48uTaXQY=@protonmail.com>

Hello Geminaut,

I wonder if trying to limite the non human and individual human internet bandwidth usage, could be good for the planet?

Way to do this could be:
- no more than 1 req/s from one IP
- explicit autorisation for crawler with a maximum of req/day

How to manage multi-user http2gemini gateway?

freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/8feb9f89/attachment-0001.htm>

From juhani at envs.net  Thu Jul  9 13:27:54 2020
From: juhani at envs.net (juhani)
Date: Thu, 9 Jul 2020 15:27:54 +0300
Subject: Client behavior when server doesn't close connection?
Message-ID: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>

Hi all,

I'm juhani, new here, and implementing an Android gemini client.

While testing with live sites for the first time I found that some sites worked,
and on others the response handling hung. Comparison of tcp streams revealed
that on the working sites the last packet from the server had FIN flag, and on
the failing sites it didn't.

I changed the client so it doesn't try to read the whole response before parsing
the header. And added timeout to make sure the connection is closed.

These changes make sense to me, but what should the client do if it cant be sure
it has the complete payload? With line based content it's possible to show what
you've got. The clients I've tried, so far, seem to do that, but is it correct?
And what about binary content?


~juhani

gemini://envs.net/~juhani
https://git.envs.net/juhani/minigem


From petite.abeille at gmail.com  Thu Jul  9 13:52:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 14:52:11 +0200
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
Message-ID: <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>



> On Jul 9, 2020, at 14:27, juhani <juhani at envs.net> wrote:
> 
> the working sites the last packet from the server had FIN flag, and on the failing sites it didn't.

In principle, the server MUST close the connection. Gemini doesn't have the concept of persistent connection, or content length, or chunking, or what not. Nothing but close.

If the server doesn't explicitly close the connection, then the client is toast, as there is no other mechanism to indicate end-of-transmission.

> but what should the client do if it cant be sure it has the complete payload?

Pray. Punt. Apply any random heuristics you see fit. But really, no close, no cigar.

> With line based content it's possible to show what you've got. The clients I've tried, so far, seem to do that, but is it correct?

It's a heuristic. Your milage may vary. The short of it is that there is no mechanism to indicate anything aside from the server cleanly closing the connection.

> And what about binary content?

Use a different protocol.



From petite.abeille at gmail.com  Thu Jul  9 14:07:52 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 15:07:52 +0200
Subject: Gemini transactions (was Re: Client behavior when server doesn't
 close connection?)
In-Reply-To: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
Message-ID: <7BD39E37-11C7-4A0C-87F3-DDE29F8E547A@gmail.com>



> On Jul 9, 2020, at 14:27, juhani <juhani at envs.net> wrote:
> 
> Comparison of tcp streams revealed
> that on the working sites the last packet from the server had FIN flag, and on
> the failing sites it didn't.

While at it, perhaps the spec should make closing the connection more prominent.

At the moment, it's shown in 1.1 Gemini transactions:

S:   Sends response header (one CRLF terminated line), closes connection
     under non-success conditions (see 3.1 and 3.2)
S:   Sends response body (text or binary data) (see 3.3)
S:   Closes connection

And mentioned in 3.1 Response headers:

If <STATUS> does not belong to the "SUCCESS" range of codes, then the server MUST close the connection after sending the header and MUST NOT send a response body.

This could be perhaps reemphasized with:

If <STATUS> belongs to the "SUCCESS" range of code, then the server MUST close the connection after sending the header and response body.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/241e8ae7/attachment.htm>

From defdefred at protonmail.com  Thu Jul  9 14:14:19 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 09 Jul 2020 13:14:19 +0000
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>
Message-ID: <urEKBuDmhaeKzgvAWApYchVNa0-cLp69VkcPpH-Nd_B4wfIR0cCuh4RBxQ3FxLLpvHUS1t7qPv3LfcCuZ5blCQ81UKiCB4bZiw0j5zXACO4=@protonmail.com>

On Thursday 9 July 2020 14:52, Petite Abeille <petite.abeille at gmail.com> wrote:
> > And what about binary content?
>
> Use a different protocol.

Gemini can't send image?



From petite.abeille at gmail.com  Thu Jul  9 14:21:13 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 15:21:13 +0200
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <urEKBuDmhaeKzgvAWApYchVNa0-cLp69VkcPpH-Nd_B4wfIR0cCuh4RBxQ3FxLLpvHUS1t7qPv3LfcCuZ5blCQ81UKiCB4bZiw0j5zXACO4=@protonmail.com>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>
 <urEKBuDmhaeKzgvAWApYchVNa0-cLp69VkcPpH-Nd_B4wfIR0cCuh4RBxQ3FxLLpvHUS1t7qPv3LfcCuZ5blCQ81UKiCB4bZiw0j5zXACO4=@protonmail.com>
Message-ID: <23C8653D-8D89-4704-A28D-DA44053CDDEE@gmail.com>



> On Jul 9, 2020, at 15:14, defdefred <defdefred at protonmail.com> wrote:
> 
> On Thursday 9 July 2020 14:52, Petite Abeille <petite.abeille at gmail.com> wrote:
>>> And what about binary content?
>> 
>> Use a different protocol.
> 
> Gemini can't send image?

Sure it can. But perhaps it shouldn't. Depends on how much reliability one is after.

See "File size" in "Best practices for Gemini implementations":
https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/best-practices.gmi


Gemini servers do not inform clients of the size of files they are serving, which can make it difficult to detect if a connection is closed prematurely due to a server fault.  This risk of this happening increases with file size.

Gemini also has no support for compression of large files, or support for checksums to enable detection of file corruption, the risk of which also increases with file size.

For all of these reasons, Gemini is not well suited to the transfer of "very large" files.  Exactly what counts as "very large" depends to some extent on the speed and reliability of the internet connections involved, and the patience of the users.  As a rule of thumb, files larger than 100MiB might be thought of as best served some other way.

Of course, because Gemini supports linking to other online content via any protocol with a URL scheme, it's still possible to link from a Gemini document to a large file served via HTTPS, BitTorrent, IPFS or whatever else tickles your fancy.


Replace "very large file" with binary and you get the gist of it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/421a498b/attachment.htm>

From juhani at envs.net  Thu Jul  9 14:27:27 2020
From: juhani at envs.net (juhani)
Date: Thu, 9 Jul 2020 16:27:27 +0300
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>
Message-ID: <d9b747e3-8d1d-aac1-34e8-db3f4250a702@envs.net>

On 9.7.2020 15.52, Petite Abeille wrote:

>> On Jul 9, 2020, at 14:27, juhani <juhani at envs.net> wrote:
>> but what should the client do if it cant be sure it has the complete payload?
> Pray. Punt. Apply any random heuristics you see fit. But really, no close, no cigar.

Roger that :)


From me at case.codes  Thu Jul  9 14:43:30 2020
From: me at case.codes (Case Nelson)
Date: Thu, 9 Jul 2020 13:43:30 +0000 (UTC)
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
Message-ID: <7233bdde-7a7e-4e5f-b9f6-2231294daa9f@case.codes>

I raised an issue with jetforce for this and poked around in twisted but we might be stuck and could use help getting this fixed. I think jetforce is the most popular server with this issue.

https://github.com/michael-lazar/jetforce/issues/32


From acdw at acdw.net  Thu Jul  9 15:17:21 2020
From: acdw at acdw.net (Case Duckworth)
Date: Thu, 09 Jul 2020 09:17:21 -0500
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <23C8653D-8D89-4704-A28D-DA44053CDDEE@gmail.com>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>
 <urEKBuDmhaeKzgvAWApYchVNa0-cLp69VkcPpH-Nd_B4wfIR0cCuh4RBxQ3FxLLpvHUS1t7qPv3LfcCuZ5blCQ81UKiCB4bZiw0j5zXACO4=@protonmail.com>
 <23C8653D-8D89-4704-A28D-DA44053CDDEE@gmail.com>
Message-ID: <6469cb16-e126-4bb8-bd02-a8373bf912fc@www.fastmail.com>

Gemini absolutely can send binary files -- AFAICT that's one of the main reasons it has the MIME type included in the header. Also, I don't think it's helpful to replace "very large" with "binary" -- there are plenty of binary files that are smaller than 100 MiB, including images of almost any size, lots of binary executables, songs, and even some shorter musical albums. While it's not a great idea to serve giant files over gemini, it's certainly possible (see konpeito.media, sloum's Drift Theory on circumlunar.space), and clients should *absolutely* be able to handle them. 

A client author could write some checks to see if a download is taking too long or hanging, or even filter based on received MIME type, but I think the gemini experience would be lessened if a user couldn't download, e.g., images from gemini.

~ acdw

On Thu, Jul 9, 2020, at 8:21 AM, Petite Abeille wrote:
> 
> 
>> On Jul 9, 2020, at 15:14, defdefred <defdefred at protonmail.com> wrote:
>> 
>> On Thursday 9 July 2020 14:52, Petite Abeille <petite.abeille at gmail.com> wrote:
>>>> And what about binary content?
>>> 
>>> Use a different protocol.
>> 
>> Gemini can't send image?
> 
> Sure it can. But perhaps it shouldn't. Depends on how much reliability one is after.
> 
> See "File size" in "Best practices for Gemini implementations":
> https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/best-practices.gmi
> 
> 
> **Gemini servers do not inform clients of the size of files they are serving, which can make it difficult to detect if a connection is closed prematurely due to a server fault*. This risk of this happening increases with file size.*
> **
> *Gemini also has no support for compression of large files, or support for checksums to enable *detection of file corruption*, the risk of which also increases with file size.*
> **
> *For all of these reasons, *Gemini is not well suited to the transfer* of "very large" files. Exactly what counts as "very large" depends to some extent on the speed and reliability of the internet connections involved, and the patience of the users. As a rule of thumb, files larger than 100MiB might be thought of as best served some other way.*
> **
> *Of course, because Gemini supports linking to other online content via any protocol with a URL scheme, *it's still possible to link from a Gemini document to a large file served via HTTPS*, BitTorrent, IPFS or whatever else tickles your fancy.*
> 
> Replace "very large file" with binary and you get the gist of it.
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/26276f73/attachment.htm>

From petite.abeille at gmail.com  Thu Jul  9 15:23:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 16:23:12 +0200
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <6469cb16-e126-4bb8-bd02-a8373bf912fc@www.fastmail.com>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <CFE13A8A-1690-4715-827A-34894EAE2B17@gmail.com>
 <urEKBuDmhaeKzgvAWApYchVNa0-cLp69VkcPpH-Nd_B4wfIR0cCuh4RBxQ3FxLLpvHUS1t7qPv3LfcCuZ5blCQ81UKiCB4bZiw0j5zXACO4=@protonmail.com>
 <23C8653D-8D89-4704-A28D-DA44053CDDEE@gmail.com>
 <6469cb16-e126-4bb8-bd02-a8373bf912fc@www.fastmail.com>
Message-ID: <6527498A-6E5F-4420-AEBE-8E31A4FEF804@gmail.com>



> On Jul 9, 2020, at 16:17, Case Duckworth <acdw at acdw.net> wrote:
> 
> and clients should *absolutely* be able to handle them

As long as the server bother to actually *close* the darn connection :D

But yes, we are in agreement: Gemini can do it.

If it should -or shouldn't- be used for such purpose is another question altogether.


From hannu.hartikainen+gemini at gmail.com  Thu Jul  9 15:24:49 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Thu, 9 Jul 2020 17:24:49 +0300
Subject: Removing expiry dates for TOFU
In-Reply-To: <C41LAHP83ET9.284908F3T32IQ@stilgar>
References: <FBCD1667-16A5-4A63-B57B-2DA5F728E9E7@gmail.com>
 <C41LAHP83ET9.284908F3T32IQ@stilgar>
Message-ID: <CANmFPekhiOe02Mxd7mpthoNnFD3qnxKm0qffiQzNA3=MOKOmfg@mail.gmail.com>

If you're willing to look at unusual uses of TLS, I'll mention that there's
also an RFC for OpenPGP-based TLS encryption. This is not a recommendation!

https://tools.ietf.org/html/rfc6091

That would allow web-of-trust based infrastructure. But as there are no
widespread implementations, it will be a pain to use in practice.

In my very humble opinion, a community-based distributed trust system is
safer than TOFU and more suitable for non-commercial use than CA based PKI.
But in practice *any* TLS is much, much safer than plaintext as it
completely prevents eavesdropping without a full-fledged MitM attack.

A more practical way of building a web of trust upon TOFU would be for
browsers to export cert fingerprint lists that people can share on their
sites. These could be compared and imported, and with some human
interaction we should notice when MitM attacks start happening in practice.

-Hannu

On Thu, 9 Jul 2020 at 01:19, Solderpunk <solderpunk at posteo.net> wrote:

> Thanks for sharing this!  I will read it closely.  It's a shame if it's
> not widely implemented, but there may well still be good ideas in there,
> or details we've overlooked.
>
> Cheers,
> Solderpunk
>
> On Wed Jul 8, 2020 at 11:27 PM CEST, Petite Abeille wrote:
> >
> >
> > > On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote:
> > >
> > > Yes. Looks interesting, and it goes in the right direction.
> > > Unfortunately, the RFC is already quite old (2014)  and according to
> > > Wikipedia, it is only supported by GnuTLS (I didn't check directly).
> > >
> > > Do you know if it is already used in some visible applications?
> >
> > Hmm, no :) Just stumbled upon it on the openssl mailing list, where
> > someone was asking if it was supported:
> >
> > RFC 7250 raw public keys?
> > https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html
> >
> >
> > There is an open issue for it:
> >
> > Raw Public Key (RFC 7250) support
> > https://github.com/openssl/openssl/issues/6929
> >
> >
> > mbedtls seems to have something:
> >
> > Support Raw Public Key mode (RFC7250)
> > https://github.com/ARMmbed/mbedtls/pull/336
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/3128bd33/attachment.htm>

From colecmac at protonmail.com  Thu Jul  9 15:38:46 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 09 Jul 2020 14:38:46 +0000
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
Message-ID: <j8tQ-1EhCX34oz-bxmi_ovdwCio0pOWJxeO96pBGVSGi3ZBsnG48VNNtoL4xHefENxApo-fh65LzvCMRLel0ZGGohe8m3Mh9A6oG3wNi0XU=@protonmail.com>

> I changed the client so it doesn't try to read the whole response before parsing
> the header. And added timeout to make sure the connection is closed.

This sounds like the way to go! You can't reply on the server being compliant. I wish
we'd get a stream status code so you could know when to disable that, though...

Also for the record, my Go clients never experience this "not closing the connection"
issue. Amfora attempts to load all the data before displaying it (this will change),
and I've never had any problems with that on any servers. It always finds the end of
the data fine, presumably indicated by a closed connection. Maybe the Go TLS
implementation is just more robust?

makeworld

From petite.abeille at gmail.com  Thu Jul  9 15:57:01 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 16:57:01 +0200
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <j8tQ-1EhCX34oz-bxmi_ovdwCio0pOWJxeO96pBGVSGi3ZBsnG48VNNtoL4xHefENxApo-fh65LzvCMRLel0ZGGohe8m3Mh9A6oG3wNi0XU=@protonmail.com>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <j8tQ-1EhCX34oz-bxmi_ovdwCio0pOWJxeO96pBGVSGi3ZBsnG48VNNtoL4xHefENxApo-fh65LzvCMRLel0ZGGohe8m3Mh9A6oG3wNi0XU=@protonmail.com>
Message-ID: <2BD027CA-B2DB-47A0-9397-C4DA82785AFF@gmail.com>



> On Jul 9, 2020, at 16:38, colecmac at protonmail.com wrote:
> 
> You can't rely on the server being compliant.

Right...    (7)  It is always something*

That said, the server has one and only one hard requirement: close the darn connection.

Perhaps this should be a minimum requirement? 

* https://tools.ietf.org/html/rfc1925


From petite.abeille at gmail.com  Thu Jul  9 16:01:41 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 17:01:41 +0200
Subject: About limiting the non human internet bandwidth pollution
In-Reply-To: <LqaP51mG2jDcO3jCMBsMcOy4PmJ93UHXmTmVHIgAymIpm2kM46mPt7lXdslaPqSOkrBHcUDZQ5nNUhX3mggdBinb_ngzUmzVImG48uTaXQY=@protonmail.com>
References: <LqaP51mG2jDcO3jCMBsMcOy4PmJ93UHXmTmVHIgAymIpm2kM46mPt7lXdslaPqSOkrBHcUDZQ5nNUhX3mggdBinb_ngzUmzVImG48uTaXQY=@protonmail.com>
Message-ID: <142E181A-1824-41F3-9AA3-9E09987BFC1B@gmail.com>



> On Jul 9, 2020, at 08:42, defdefred <defdefred at protonmail.com> wrote:
> 
> I wonder if trying to limite the non human and individual human internet bandwidth usage, could be good for the planet?

? propos:

Webwaste
https://alistapart.com/article/webwaste/

From petite.abeille at gmail.com  Thu Jul  9 17:29:16 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 18:29:16 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <20200626135633.GD4156@SDF.ORG>
References: <20200626135633.GD4156@SDF.ORG>
Message-ID: <B53A27FA-D30D-49F4-B8BD-8ECD7254E8D6@gmail.com>



> On Jun 26, 2020, at 15:56, solderpunk <solderpunk at SDF.ORG> wrote:
> 
> cozylabs.eu achieves this feat with a single self-signed ED25519
> certificate.

What is the consensus on those self-signed ED25519 certificates? Good? Bad? Ugly?

$ echo | openssl s_client -connect cozylabs.eu:1965 2>/dev/null | openssl x509 -outform der | wc -c
273

So, 273 bytes in DER format.

$ openssl s_client -quiet -crlf -connect cozylabs.eu:1965 <<< gemini://cozylabs.eu/ 2>/dev/null | wc -c
340

For 340 bytes of text/gemini content. 

Fair enough. (Ignoring all of the TCP overhead itself, as pointed out by Sean [1]).

> Unfortunately making this kind of cert with the `openssl` tool is not as straightforward as other options.  

$ openssl version
OpenSSL 1.1.1g  21 Apr 2020

$ openssl req -new -newkey ed25519 -nodes -keyout key.pem -x509 -days 36500 -subj / -outform der | wc -c
282

282 bytes versus 273 bytes for cozylabs.eu <http://cozylabs.eu/>. 

Doesn't seem to be that bad. Perhaps I missed something :)


[1] https://lists.orbitalfox.eu/archives/gemini/2020/001958.html <https://lists.orbitalfox.eu/archives/gemini/2020/001958.html>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/1eb3e6c0/attachment.htm>

From colecmac at protonmail.com  Thu Jul  9 17:50:59 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 09 Jul 2020 16:50:59 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <B53A27FA-D30D-49F4-B8BD-8ECD7254E8D6@gmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <B53A27FA-D30D-49F4-B8BD-8ECD7254E8D6@gmail.com>
Message-ID: <lZZTSHkA6F5BoXYTLNOUTyixOzkRDuiQVtY9XAZVc_cxjahbHNKqvH5qaKrwytpKDppOOataxWgENExvW7wHBt_rRIkg4u8TETTCKcaNnqE=@protonmail.com>

> What is the consensus on those?self-signed ED25519?certificates? Good? Bad? Ugly?

I prefer using EC keys, which are still quite small (256 bits), but are more widely
supported. The OpenSSL command is a bit annoying, but I made a gemlog post about it
to make it easier.

gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi

The *key* part of it is:
-newkey ec -pkeyopt ec_paramgen_curve:prime256v1

Cheers,
makeworld

From tcb913 at gmail.com  Thu Jul  9 17:57:39 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Thu, 9 Jul 2020 12:57:39 -0400
Subject: Removing expiry dates for TOFU
In-Reply-To: <MN2PR07MB6655251BF4181BF20088C08FE4640@MN2PR07MB6655.namprd07.prod.outlook.com>
References: <C40ATNDKIE71.323OYSY8RE86E@stilgar>
 <C40B9OGF2BVL.37E26R39CC4TD@stilgar>
 <MN2PR07MB6655251BF4181BF20088C08FE4640@MN2PR07MB6655.namprd07.prod.outlook.com>
Message-ID: <1932ecc7-527d-c838-9240-28a4e99887d8@gmail.com>

A thought from one without enough knowledge to have a right to thoughts:

Getting broad acceptance of Gemini both theoretically as a viable 
standard and practically as a growing community is important. Having 
community members developing their own clients and servers - not so much.

I am sure I will always be using a client which someone else wrote, just 
as I use a  web browser someone else wrote. And I am dead certain I will 
never try to write my own server, as I will never try to write my own 
Apache.

Best to all,

Terry B.


On 07/08/2020 08:39 PM, Thomas Karpiniec wrote:
>> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Solderpunk
>> A proposal: "TOFU-TOTS".  You know, like tater tots, but without
>> potatoes in them.  Or rather, trust-on-first-use augmented by
>> trust-over-time-and-space.
> Setting aside that I already put my support behind the oligarchy, this is an interesting problem and I'll weigh in. :)
>
> I agree that that this proposal would provide fairly effective protection against MITM. I worry that it is so unusual that it would push newbies away from setting up gemini servers. Faced with regular rotation requirements I suspect that many people would automate the process with cronjobs, meaning that the keys for the next certificate are sitting right there on the server ready to be nabbed.
>
> More annoyingly, suppose the current private key is compromised and the legitimate server owner realises it - they don't have any good options. One is to put up with being spoofable until their next-advertised certificate becomes valid, which may be 10 months in the future. Otherwise they could do an out-of-turn certificate rotation, which clients will warn on just as harshly as any other unexpected change. (Further down the thread, Baschdel suggested backup certificates to alleviate this. But what if you're compromised twice? To me the complexity creep feels disproportionate to the advantages.)
>
> A suggestion: what if instead of publishing a future certificate, we publish our own CA certificate, which is used to sign our server certificates? A client should cache this CA certificate permanently and use it to verify all future requests to that domain. A diligent system administrator will keep their CA key material offline. Someone who doesn't care so much can just generate everything on their server.
>
> * Client logic is simpler
> * Keys and certificates can be rotated at will by the sysadmin and they can choose whatever expiry they are comfortable with
> * Relies on familiar concepts of TLS trust ("oh I'm my own CA, okay") and sysadmins can choose their own level of caution
> * Uses the existing feature of TLS libraries to verify a connection against a given CA. Clients don't have to handle public keys or fingerprints - they just download the CA certificate and feed it into their TLS library.
> * Combines neatly with LetsEncrypt-style certificate management - you are just adding one extra trusted CA. If it can be verified by either that, or one of the normal roots, then you're okay.
> * Only slightly more complicated openssl commands required when setting up a server
>
> Cheers, Tom


From petite.abeille at gmail.com  Thu Jul  9 18:09:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 9 Jul 2020 19:09:58 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <lZZTSHkA6F5BoXYTLNOUTyixOzkRDuiQVtY9XAZVc_cxjahbHNKqvH5qaKrwytpKDppOOataxWgENExvW7wHBt_rRIkg4u8TETTCKcaNnqE=@protonmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <B53A27FA-D30D-49F4-B8BD-8ECD7254E8D6@gmail.com>
 <lZZTSHkA6F5BoXYTLNOUTyixOzkRDuiQVtY9XAZVc_cxjahbHNKqvH5qaKrwytpKDppOOataxWgENExvW7wHBt_rRIkg4u8TETTCKcaNnqE=@protonmail.com>
Message-ID: <AE937A5C-2864-489B-943D-9B856DC7865E@gmail.com>



> On Jul 9, 2020, at 18:50, colecmac at protonmail.com wrote:
> 
>> What is the consensus on those self-signed ED25519 certificates? Good? Bad? Ugly?
> 
> I prefer using EC keys, which are still quite small (256 bits), but are more widely
> supported. The OpenSSL command is a bit annoying, but I made a gemlog post about it
> to make it easier.
> 
> gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi

Cool. Thanks for sharing.

> The *key* part of it is:
> -newkey ec -pkeyopt ec_paramgen_curve:prime256v1

Ok, so:

$ openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout key.pem -x509 -days 36500 -subj / -outform der | wc -c
347

347 bytes vs 282 bytes for the ED25519 variant. Not bad at all, size wise.

Is it something you are using at makeworld.gq?

$ echo | openssl s_client -connect makeworld.gq:1965 2>/dev/null | openssl x509 -outform der | wc -c
1160

At first glance I guess not:

Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/32d361af/attachment-0001.htm>

From colecmac at protonmail.com  Thu Jul  9 18:13:10 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 09 Jul 2020 17:13:10 +0000
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <AE937A5C-2864-489B-943D-9B856DC7865E@gmail.com>
References: <20200626135633.GD4156@SDF.ORG>
 <B53A27FA-D30D-49F4-B8BD-8ECD7254E8D6@gmail.com>
 <lZZTSHkA6F5BoXYTLNOUTyixOzkRDuiQVtY9XAZVc_cxjahbHNKqvH5qaKrwytpKDppOOataxWgENExvW7wHBt_rRIkg4u8TETTCKcaNnqE=@protonmail.com>
 <AE937A5C-2864-489B-943D-9B856DC7865E@gmail.com>
Message-ID: <nwTooNGD3Y2XgFFrNiQkwMno_tXZ8uS9n-DcGC0HlGq1-kmfObs-HgB70VDCdCZjC5hIVqGq7LcbkcPUbsx7TEU4OGlTcCw-3io218lwIw8=@protonmail.com>

> Ok, so:
>
> $ openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout key.pem -x509 -days 36500 -subj / -outform der | wc -c
> 347
>
> 347?bytes vs?282 bytes for the?ED25519 variant. Not bad at all, size wise.

Yep, pretty equivalent. Thanks for doing the test!

> Is it something you are using at?makeworld.gq?
> At first glance I guess not

I will be, I've generated the new certs already actually. I'm just waiting for my
current certs to expire on Aug. 30th.

Thanks,
makeworld


From lazar.michael22 at gmail.com  Thu Jul  9 18:31:41 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 9 Jul 2020 13:31:41 -0400
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
Message-ID: <CAFTy05bRi==896BWPukNH=yf2KtLp+BvKFQ141hyEm+c5trVeA@mail.gmail.com>

On Thu, Jul 9, 2020 at 8:28 AM juhani <juhani at envs.net> wrote:
> Hi all,
>
> I'm juhani, new here, and implementing an Android gemini client.

Hi!

> While testing with live sites for the first time I found that some sites worked,
> and on others the response handling hung. Comparison of tcp streams revealed
> that on the working sites the last packet from the server had FIN flag, and on
> the failing sites it didn't.
>
> I changed the client so it doesn't try to read the whole response before parsing
> the header. And added timeout to make sure the connection is closed.

There is an open issue with jetforce where it was determined that the server
sends the TLS close_notify alert but doesn't ever close the TCP socket [1]. I
haven't had the time to figure out exactly what is going on yet though. I think
that either the server is waiting for the close_notify acknowledgement message
from the client which it never receives, or the server is not reacting to the
acknowledgement by shutting down the socket.

I do find it strange that it still appears to work with 90% of gemini client
implementations. I have found that if the client sends a close_notify for their
write stream after they transmit the request, then the server will close the
connection fully. The other possibility is that maybe your client isn't sending
the acknowledgement to the server?

My understanding of TLS is that it's not required for the server to wait for the
acknowledgement from the client, so ideally the server should be sending the
close_notify and then immediately closing the connection afterwards.

The main point that I want to make here is that this is a lot more nuanced than
waving it off as "just close the connection". The TLS connection needs to be
shut down safely to prevent truncation attacks, and to make things more
complicated the rules are different between TLS 1.2 and 1.3.

- mozz

[1] https://github.com/michael-lazar/jetforce/issues/32

From clarissa.littler at gmail.com  Thu Jul  9 19:03:52 2020
From: clarissa.littler at gmail.com (Clarissa Littler)
Date: Thu, 9 Jul 2020 11:03:52 -0700
Subject: What's the status of gemini browsers and image handling?
Message-ID: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>

Hey,

Obligatory "I hope this is within the scope of this mailing list" preface!

So I'm not even a week deep into digging into geminispace but I've been
really happy with what exists so far and I'm trying to encourage other
people to join me.

My question, then, is what's the support for serving and browsing images in
gemini. Like as a usecase what if I wanted to set-up a small gemini server
and, say, have a photo gemlog (links to photos on the server embedded
within posts) what servers would work for that and what browsers could I
recommend for a pretty seamless experience?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/87907d3c/attachment.htm>

From colecmac at protonmail.com  Thu Jul  9 19:24:25 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 09 Jul 2020 18:24:25 +0000
Subject: What's the status of gemini browsers and image handling?
In-Reply-To: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
References: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
Message-ID: <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>

Hello, welcome!

All servers will work with images. Most browsers should as
well. The biggest difference you'll find from the Web is
that you'll have to link to images, they won't be displayed inline.

Thanks,
makeworld

From lel at envs.net  Thu Jul  9 19:30:54 2020
From: lel at envs.net (lel)
Date: Thu, 09 Jul 2020 14:30:54 -0400
Subject: What's the status of gemini browsers and image handling?
In-Reply-To: <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>
References: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
 <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>
Message-ID: <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>

On July 9, 2020 2:24:25 PM EDT, colecmac at protonmail.com wrote:
>Hello, welcome!
>
>All servers will work with images. Most browsers should as
>well. The biggest difference you'll find from the Web is
>that you'll have to link to images, they won't be displayed inline.
>
>Thanks,
>makeworld

This, but with the caveat that I keep seeing
people on this list indicating that they're
working on a client that automagically 
displays any images linked as in-line images.

I haven't seen an actual example of this yet,
but if it doesn't exist now (and please
someone say something if it does and
I missed a client announcement because
it would be cool!), it probably will in not too
long. That would sorta be in line with what
OP is looking for, but crucially this isn't
something the server or the protocol is
equipped to do, but rather some sugar
a client could use to simulate in-lining.

~lel

From tomasino at lavabit.com  Thu Jul  9 19:37:44 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 9 Jul 2020 18:37:44 +0000
Subject: What's the status of gemini browsers and image handling?
In-Reply-To: <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>
References: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
 <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>
 <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>
Message-ID: <fcd7d3ae-05ed-988b-3819-82c1ddf56774@lavabit.com>

On 7/9/20 6:30 PM, lel wrote:
> This, but with the caveat that I keep seeing
> people on this list indicating that they're
> working on a client that automagically 
> displays any images linked as in-line images.

If you're interested in this, please by all means do so by leveraging a mime-type other than text/gemini. Markdown support is available in several clients now and it can accomplish your goals.


From acdw at acdw.net  Thu Jul  9 19:59:18 2020
From: acdw at acdw.net (Case Duckworth)
Date: Thu, 09 Jul 2020 18:59:18 +0000
Subject: What's the status of gemini browsers and image handling?
In-Reply-To: <fcd7d3ae-05ed-988b-3819-82c1ddf56774@lavabit.com>
References: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
 <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>
 <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>
 <fcd7d3ae-05ed-988b-3819-82c1ddf56774@lavabit.com>
Message-ID: <4fa871fe-2984-432c-a918-c2b4b92537fc@www.fastmail.com>

I know the proxy at https://proxy.vulpes.one displays images inline, though I tend to agree with Tomasino on this issue.

~ acdw

From lel at envs.net  Thu Jul  9 20:15:39 2020
From: lel at envs.net (lel)
Date: Thu, 09 Jul 2020 15:15:39 -0400
Subject: What's the status of gemini browsers and image handling?
In-Reply-To: <4fa871fe-2984-432c-a918-c2b4b92537fc@www.fastmail.com>
References: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
 <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>
 <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>
 <fcd7d3ae-05ed-988b-3819-82c1ddf56774@lavabit.com>
 <4fa871fe-2984-432c-a918-c2b4b92537fc@www.fastmail.com>
Message-ID: <7BDEF8B2-E341-432C-BC6A-A4E936B85ADF@envs.net>

On July 9, 2020 2:59:18 PM EDT, Case Duckworth <acdw at acdw.net> wrote:
>I know the proxy at https://proxy.vulpes.one displays images inline,
>though I tend to agree with Tomasino on this issue.

Yeah, having now thought about it for more than
like three seconds, it would either lead to certain
chunks of the community writing content under the
assumption that your client will in-line images, and
their content not being readable in mainstream clients,
or if clients that do this themselves become
mainstream, then everyone will start writing content
assuming that, and suddenly simple clients are locked
out from interacting with most content.

text/gemini is intentionally text-y and pretty
opinionated about that, and in-lining images runs
counter to the prevailing gopheresque idiom it's
is trying to capture.

~lel

From luke at marmaladefoo.com  Thu Jul  9 20:23:56 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 09 Jul 2020 20:23:56 +0100
Subject: What's the status of gemini browsers and image handling?
In-Reply-To: <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>
References: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
 <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>
 <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>
Message-ID: <5F076ECC.3020300@marmaladefoo.com>


On 09-Jul-2020 19:30, lel wrote:
> This, but with the caveat that I keep seeing
> people on this list indicating that they're
> working on a client that automagically
> displays any images linked as in-line images.
>
> I haven't seen an actual example of this yet,
> but if it doesn't exist now (and please
> someone say something if it does and
> I missed a client announcement because
> it would be cool!), it probably will in not too
> long. That would sorta be in line with what
> OP is looking for, but crucially this isn't
> something the server or the protocol is
> equipped to do, but rather some sugar
> a client could use to simulate in-lining.
I agree, this is the kind of thing a graphical client might offer to do 
for the user - to show a specific image in-line on request.

Generally the expectation is that images are not automatically loaded 
though, but different clients will have different UI.

My understanding is that most clients will show the linked image when 
you click on it, either within the client itself, or by launching some 
external application.

Best wishes

  - Luke


From drskrzyk at tilde.team  Thu Jul  9 20:31:20 2020
From: drskrzyk at tilde.team (Dr. Otto Skrzyk)
Date: Thu, 9 Jul 2020 14:31:20 -0500
Subject: What's the status of gemini browsers and image handling?
In-Reply-To: <7BDEF8B2-E341-432C-BC6A-A4E936B85ADF@envs.net>
References: <CAH-5XsccG6hB=U5GdP1Dr+3WK+=_P4yBJMy9WD18CFMAhYTVMw@mail.gmail.com>
 <xRpTBAp0BLiFZborkcGVE703Wh6lYwuzk0V0VEIqPpqAWrzX5F24qoI2iT4NxNHxJ3rGCb6aGgKg0wxtVbr2EO0Cvn_UNFn9Ffgiz73Njzs=@protonmail.com>
 <B57E8EC6-F07C-49D2-8E43-5C3E66501702@envs.net>
 <fcd7d3ae-05ed-988b-3819-82c1ddf56774@lavabit.com>
 <4fa871fe-2984-432c-a918-c2b4b92537fc@www.fastmail.com>
 <7BDEF8B2-E341-432C-BC6A-A4E936B85ADF@envs.net>
Message-ID: <20200709193120.GA11650@cipher>

On Thu, Jul 09, 2020 at 03:15:39PM -0400, lel wrote:
> On July 9, 2020 2:59:18 PM EDT, Case Duckworth <acdw at acdw.net> wrote:
> >I know the proxy at https://proxy.vulpes.one displays images inline,
> >though I tend to agree with Tomasino on this issue.
--- cut for brevity --- 
> text/gemini is intentionally text-y and pretty
> opinionated about that, and in-lining images runs
> counter to the prevailing gopheresque idiom it's
> is trying to capture.
> 
> ~lel

This was my first thought. I don't see that there's a value the ethos
and style (if that's the right word) to have a slow creep away from
supporting just a text interface. It's baked in support for people with
visual impairments if nothing else, and future-proof. 

If I wanted that kind of experience, I'd just fall back to static
hypertext on a browser and be done with it.

-- 
Dr . Otto Skrzyk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/76a37d3d/attachment.sig>

From pellertson at firemail.cc  Thu Jul  9 21:49:36 2020
From: pellertson at firemail.cc (Parker Ellertson)
Date: Thu, 9 Jul 2020 13:49:36 -0700
Subject: [ANN] New Server and Drudge Report Mirror
Message-ID: <20200709134936.13dc1eac.pellertson@firemail.cc>

I've set up a server real quick over on gemini://ellertson.org/ .  I'm
still working on writing the rc script to set it up as a proper
service, but it is running as I write this.

On the site, you will ll find a link to a CGI script to a mirror of the
Drudge Report news aggregator.  It only shows the main headlines and
the dozen or so stories you see in the upper left of the site as of
now, but it's still pretty neat.  With any luck this will be the most
political message I will send in the mailing list.  XD

Have fun!

~ Parker

From lambdatronic at disroot.org  Thu Jul  9 22:39:09 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Thu, 09 Jul 2020 17:39:09 -0400
Subject: [ANN] New Gemini Server: Space Age
Message-ID: <87v9iwwepu.fsf@disroot.org>

Howdy Geminauts,

  Some of you may know me as lambdatronic at floss.social on Mastodon. I've
been having a lot of fun playing around in Geminispace for the past
several weeks, and I decided it was about time that I wrote my own
Gemini server to add to the software list on the Project Gemini capsule.

So without further ado, here it is:

  https://gitlab.com/lambdatronic/space-age

Space Age is a Gemini server written in Clojure (https://clojure.org/).

It implements Gemini protocol specification v0.14.2 (July 2nd 2020), all
except for client certificates (which I'm still working on).

The entire code base (including build files) clocks in at a cool 200
lines with absolutely no dependency libraries.

At present, Space Age simply works as a read-only file server over
Gemini. It will serve up any readable files under its document root
directory (specified at startup) or from the public_gemini directory in
any user's home directory.

If a requested URL maps to a directory, the server looks for an
index.gmi or index.gemini file in that directory. If neither of those
exist, it automatically generates a directory listing in text/gemini
format with links to each of the files and directories within it for
easy filesystem navigation.

Take a look, read the README, and give it a spin. I'd be happy to hear
any feedback you folks might have or ideas for additional features.

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From pellertson at firemail.cc  Thu Jul  9 22:44:59 2020
From: pellertson at firemail.cc (Parker Ellertson)
Date: Thu, 9 Jul 2020 14:44:59 -0700
Subject: [ANN] New Server and Drudge Report Mirror
In-Reply-To: <20200709134936.13dc1eac.pellertson@firemail.cc>
References: <20200709134936.13dc1eac.pellertson@firemail.cc>
Message-ID: <20200709144459.6f192180.pellertson@firemail.cc>

I took the down to experiment with generating keys.  It's back up now,
but do be aware that the certs could be improperly generated.


On Thu, 9 Jul 2020 13:49:36 -0700
Parker Ellertson <pellertson at firemail.cc> wrote:

> I've set up a server real quick over on gemini://ellertson.org/ .  I'm
> still working on writing the rc script to set it up as a proper
> service, but it is running as I write this.
> 
> On the site, you will ll find a link to a CGI script to a mirror of
> the Drudge Report news aggregator.  It only shows the main headlines
> and the dozen or so stories you see in the upper left of the site as
> of now, but it's still pretty neat.  With any luck this will be the
> most political message I will send in the mailing list.  XD
> 
> Have fun!
> 
> ~ Parker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/36849fde/attachment.sig>

From colecmac at protonmail.com  Thu Jul  9 23:08:54 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 09 Jul 2020 22:08:54 +0000
Subject: [ANN] New Server and Drudge Report Mirror
In-Reply-To: <20200709144459.6f192180.pellertson@firemail.cc>
References: <20200709134936.13dc1eac.pellertson@firemail.cc>
 <20200709144459.6f192180.pellertson@firemail.cc>
Message-ID: <Q6W6XuZRIZ0fAUbulys0y_gPBUEP8NFoiiqlfxp1_mFfd6drUVzaocZ6p9MxTMUYfKLd8tG1eiQmiqtu00jJ35ST8KBYkOAR0yBdlqSO86E=@protonmail.com>

> I took the down to experiment with generating keys. It's back up now,
> but do be aware that the certs could be improperly generated.

"certificate is valid for *.ellertson.org, not ellertson.org"

Yeah, seems like it. Maybe my post might be of use? ?

gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi

Seems like a quick fix though, just change the CN to ellertson.org instead.
If you actually want to create a wildcard cert, you can use this command
from the post:

openssl req -new -subj "/CN=*.example.com" -addext "subjectAltName = DNS:example.com, DNS:*.example.com" -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -days 1825 -nodes -out cert.pem -keyout key.pem

The part you missed was adding the regular domain to subjectAltName.

Cheers,
makeworld

From hannu.hartikainen+gemini at gmail.com  Thu Jul  9 23:57:50 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Fri, 10 Jul 2020 01:57:50 +0300
Subject: 16colo.rs mirror (was: WIP: ANSI art modem download emulator)
In-Reply-To: <2XHuiFuZRvzrU0JSUbXcCrCW-WmzxofnJUTdvDC1-DZr9lLP1t8tc0ttOVoerUk3VNrXP6FfiJ6JSkhqFarImsnfMRyOocOMTAE4qRVf6HM=@protonmail.com>
References: <CANmFPenthTT=fAPmJaqiYDvR6GSGUh4gsC8MkWvLZBd8M3iRAA@mail.gmail.com>
 <2XHuiFuZRvzrU0JSUbXcCrCW-WmzxofnJUTdvDC1-DZr9lLP1t8tc0ttOVoerUk3VNrXP6FfiJ6JSkhqFarImsnfMRyOocOMTAE4qRVf6HM=@protonmail.com>
Message-ID: <CANmFPemA=ht8QDOOr=qMycTeOJ_XX5xQRHGEdwRG_5zZa-HD1Q@mail.gmail.com>

On Wed, 8 Jul 2020 at 04:03, <colecmac at protonmail.com> wrote:
> Could you let us know in this thread if you change the port or domain?

Yep! It's now running in the proper port with nicer routes
(/<filename.ans> for the artwork), properly wrapped as a systemd
service automatically provisioned with ansible so it should stay
running. :)

Now serving over 50k pieces of art now that I also included *.ANS in
addition to *.ans. And includes a (small) curated list of some great
pieces.

gemini://ansi.hrtk.in/

-Hannu

PS. While building this I submitted a patch for streaming and
full-domain reverse proxying to gemserv. Hoping to see more streaming
content; maybe people will get ideas :)

From hello at matthewgraybosch.com  Fri Jul 10 03:42:13 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 9 Jul 2020 22:42:13 -0400
Subject: [ANN] New Server and Drudge Report Mirror
In-Reply-To: <20200709134936.13dc1eac.pellertson@firemail.cc>
References: <20200709134936.13dc1eac.pellertson@firemail.cc>
Message-ID: <20200709224213.7510b463926c2a593aa2175e@matthewgraybosch.com>

On Thu, 9 Jul 2020 13:49:36 -0700
Parker Ellertson <pellertson at firemail.cc> wrote:

> I've set up a server real quick over on gemini://ellertson.org/ .  I'm
> still working on writing the rc script to set it up as a proper
> service, but it is running as I write this.

Congratulations getting your own site up.

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

From juhani at envs.net  Fri Jul 10 05:20:59 2020
From: juhani at envs.net (juhani)
Date: Fri, 10 Jul 2020 07:20:59 +0300
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <j8tQ-1EhCX34oz-bxmi_ovdwCio0pOWJxeO96pBGVSGi3ZBsnG48VNNtoL4xHefENxApo-fh65LzvCMRLel0ZGGohe8m3Mh9A6oG3wNi0XU=@protonmail.com>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <j8tQ-1EhCX34oz-bxmi_ovdwCio0pOWJxeO96pBGVSGi3ZBsnG48VNNtoL4xHefENxApo-fh65LzvCMRLel0ZGGohe8m3Mh9A6oG3wNi0XU=@protonmail.com>
Message-ID: <7aa1615a-fdb0-18ea-629d-2aee3237c005@envs.net>

On 9.7.2020 17.38, colecmac at protonmail.com wrote:

> the data fine, presumably indicated by a closed connection. Maybe the Go TLS
> implementation is just more robust?

That seems to be the case. I recorded a request with amfora and jetforce.
Looks like jetforce terminates the TLS session, amfora confirms that, and
then amfora closes the socket.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200710/6cdd690f/attachment.htm>

From hannu.hartikainen+gemini at gmail.com  Fri Jul 10 07:53:44 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Fri, 10 Jul 2020 09:53:44 +0300
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <87v9iwwepu.fsf@disroot.org>
References: <87v9iwwepu.fsf@disroot.org>
Message-ID: <CANmFPe=Hx2q2z8QP+ap0Dy9fML7NX_JFxXjFWJ8YW9XJ5gdtqA@mail.gmail.com>

On Fri, Jul 10, 2020, 00:39 Gary Johnson <lambdatronic at disroot.org> wrote:

> Space Age is a Gemini server written in Clojure (https://clojure.org/).
>
> It implements Gemini protocol specification v0.14.2 (July 2nd 2020), all
> except for client certificates (which I'm still working on).
>
> The entire code base (including build files) clocks in at a cool 200
> lines with absolutely no dependency libraries.
>

Great work!

I write Clojure at $dayjob and consider it a great fit for full-stack web
(and Gemini by extension). Besides a static Gemini site, I've written one
CGI app in Rust (twinwiki) and one server/app in Python/Jetforce (
ansi.hrtk.in). Both could have been in Clojure if there was a nice library.

For my use RAM consumption is important, though, so I'd need to measure a
bit with GraalVM or possibly a tiny JVM instance. Practically Rust will
always be the better (best?) choice, but it's a bit heavy for prototyping.

Briefly reading the code I was left wondering if java.net.URI wouldn't
parse URIs out of the box. Probably it's just not ergonomic and/or has
weird corner cases...

Happy hacking!

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200710/aa14b6fa/attachment.htm>

From defdefred at protonmail.com  Fri Jul 10 08:32:14 2020
From: defdefred at protonmail.com (defdefred)
Date: Fri, 10 Jul 2020 07:32:14 +0000
Subject: About limiting the non human internet bandwidth pollution
In-Reply-To: <142E181A-1824-41F3-9AA3-9E09987BFC1B@gmail.com>
References: <LqaP51mG2jDcO3jCMBsMcOy4PmJ93UHXmTmVHIgAymIpm2kM46mPt7lXdslaPqSOkrBHcUDZQ5nNUhX3mggdBinb_ngzUmzVImG48uTaXQY=@protonmail.com>
 <142E181A-1824-41F3-9AA3-9E09987BFC1B@gmail.com>
Message-ID: <A6VSLfSA6Elrl47zVy2aaU34yiL_nBAGsD5OX81qrbKvoaeiW-s17LFZNrQpZbsFsp3mVqc0WURj7KhtbwbNraBKOpvIYn5Pq56jZehtAfs=@protonmail.com>

On Thursday 9 July 2020 17:01, Petite Abeille <petite.abeille at gmail.com> wrote:
> https://alistapart.com/article/webwaste/

True and not only image and video, but all the dynamic javascript around.

Software are more and more bloated too.

I read a news this morning about using python script into web page for client side execution to replace javascript...
Reading the paper I saw that it is javascript code that interprete python code !!




From solderpunk at posteo.net  Fri Jul 10 10:19:44 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Fri, 10 Jul 2020 11:19:44 +0200
Subject: About limiting the non human internet bandwidth pollution
In-Reply-To: <LqaP51mG2jDcO3jCMBsMcOy4PmJ93UHXmTmVHIgAymIpm2kM46mPt7lXdslaPqSOkrBHcUDZQ5nNUhX3mggdBinb_ngzUmzVImG48uTaXQY=@protonmail.com>
Message-ID: <C42TZDV6CBZ6.3KRZBYFHU681Z@stilgar>

On Thu Jul 9, 2020 at 8:42 AM CEST, defdefred wrote:
> Hello Geminaut,
>
> I wonder if trying to limite the non human and individual human internet
> bandwidth usage, could be good for the planet?
>
> Way to do this could be:
> - no more than 1 req/s from one IP
> - explicit autorisation for crawler with a maximum of req/day

There is a temporary error status code (44) with the meaning of "slow
down", intended for use in rate limiting schemes like this.  To my
knowledge, no server yet supports configuring this, but I do plan to add
it to Molly Brown and have been thinking of simple ways to implement it.
Anyway, that would be the obvious way to do this.

I fully understand and appreciate the issue and motivation, and want to
be mindful of the issue, but we shouldn't lose sight of the fact that
things like Gemini and Gopher are, by default and without any special
effort, orders of magnitude less resource intensive than most of the
modern internet.

Cheers,
Solderpunk

> How to manage multi-user http2gemini gateway?
>
> freD.


From solderpunk at posteo.net  Fri Jul 10 10:26:15 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Fri, 10 Jul 2020 11:26:15 +0200
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <d9b747e3-8d1d-aac1-34e8-db3f4250a702@envs.net>
Message-ID: <C42U4D6YDPKO.1HTSF9WBL8KHJ@stilgar>

On Thu Jul 9, 2020 at 3:27 PM CEST, juhani wrote:
> On 9.7.2020 15.52, Petite Abeille wrote:
>
> >> On Jul 9, 2020, at 14:27, juhani <juhani at envs.net> wrote:
> >> but what should the client do if it cant be sure it has the complete payload?
> > Pray. Punt. Apply any random heuristics you see fit. But really, no close, no cigar.
>
> Roger that :)

I guess one is almost always going to get at least the MIME type of the
partial content, so really robust clients could probably implement a
strategy of looking at that to decide how to proceed (although
proceeding at all in this scenario is always going to be hit-or-miss,
and in principle it should be a perfectly valid decision for a client to
display an error message and nothing more if the connection times out
without closing, or if it closes without a proper TLS finishing
message).  In principle one could categorise MIME types into those where
handling partial content is likely to degrade gracefully (e.g.
uncompressed, "linear" content - text, wav files maybe?) and those where
trying to proceed is just likely to cause an error.

Cheers,
Solderpunk


From solderpunk at posteo.net  Fri Jul 10 10:30:38 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Fri, 10 Jul 2020 11:30:38 +0200
Subject: TLS certificate sizes in Geminispace
In-Reply-To: <B53A27FA-D30D-49F4-B8BD-8ECD7254E8D6@gmail.com>
Message-ID: <C42U7Q4RL9OU.1CP3WNDYCJ33C@stilgar>

On Thu Jul 9, 2020 at 6:29 PM CEST, Petite Abeille wrote:
>
>
> > On Jun 26, 2020, at 15:56, solderpunk <solderpunk at SDF.ORG> wrote:
> > 
> > cozylabs.eu achieves this feat with a single self-signed ED25519
> > certificate.
>
> What is the consensus on those self-signed ED25519 certificates? Good?
> Bad? Ugly?

My opinion is that they are very nice certs indeed and it would be
lovely if we could all use them for everything, but we're probably a
few years away from a point where a server admin can be confident that,
say, 95% or more of potential visitors will be on systems where this
will "just work".  In the interim, ECDSA certificates using the NIST
curves (yes, the ones everybody is suspicious of) are probably the best
possible trade-off between small size and good support.

I've finally started work on my little super-simple certificate
generator.  By default it uses ECDSA with the P256 curve.  You can feed
it an option to use ED25519 instead.  That's it, there is no support for
RSA.

Cheers,
Solderpunk

From solderpunk at posteo.net  Fri Jul 10 11:05:22 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Fri, 10 Jul 2020 12:05:22 +0200
Subject: Removing expiry dates for TOFU
In-Reply-To: <DzQd9r9ZSiu3dnLziuzYYNMhdZU-AK_F6epA25QGZ2TvAPNocOMDPzBc7ZbfqnxwLCzZLpR4hOY1Hq9wTDjxgOHUTKy6PM6Pl6HPc64Khwc=@protonmail.com>
Message-ID: <C42UYBHRNCN8.27GQPQ9772VNP@stilgar>

On Thu Jul 9, 2020 at 1:25 AM CEST,  wrote:

> > What are the simpler ideas? Just straight up TOFU with a scary message
> > five years later?
>
>
> Yes, I see that as a lot simpler. It doesn't require a well known
> endpoint, or
> a background service for clients, etc. But I still like the idea.

I guess it will always be up to individual server admins to decide how
they want to balance the effort involved in different setups against
what kind of user experience they're happy for their visitors to have,
and how they perceive their risk of someone trying to impersonate them.
All we can really do is lay out the various options along the scale, and
perhaps recommend one in particular as the "go to" choice for people who
don't feel up to making the decision.

Cheers,
Solderpunk

From hannu.hartikainen+gemini at gmail.com  Fri Jul 10 12:18:27 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Fri, 10 Jul 2020 14:18:27 +0300
Subject: Debugging TLS connections with Wireshark?
Message-ID: <CANmFPemmD_cs8Y=zvUg=kuJgb74UWjX0e3K8YCVxzqKK_okruw@mail.gmail.com>

I logged some traffic between my own client and server last night with
Wireshark. Obviously the data is encrypted, but I was surprised to not be
able to decrypt the data even when I have the private key for the server
(it would work for some TLS 1.2 setup, apparently). Fortunately I found the
bug hindering my progress just by looking at the code. Eventually.

Does anyone know how to log TLS session keys and later use them to decrypt
the logged traffic? Does some client perhaps already support this?

I'm pretty sure I'll need this at some point.

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200710/cb667d30/attachment.htm>

From jmcbray at carcosa.net  Fri Jul 10 14:01:19 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 10 Jul 2020 09:01:19 -0400
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 (juhani@envs.net's message of "Thu, 9 Jul 2020 15:27:54 +0300")
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
Message-ID: <87a707cyn4.fsf@dorothy.carcosa.net>

juhani <juhani at envs.net> writes:

> I'm juhani, new here, and implementing an Android gemini client.

Hi, juhani!

> While testing with live sites for the first time I found that some sites worked,
> and on others the response handling hung. Comparison of tcp streams revealed
> that on the working sites the last packet from the server had FIN flag, and on
> the failing sites it didn't.

Can you tell us what server software the failing sites are running?
Probably the most helpful thing is to get those servers fixed.

> I changed the client so it doesn't try to read the whole response before parsing
> the header. And added timeout to make sure the connection is closed.

That also sounds reasonable; just don't make the timeout *too* short.

> These changes make sense to me, but what should the client do if it cant be sure
> it has the complete payload? With line based content it's possible to show what
> you've got. The clients I've tried, so far, seem to do that, but is it correct?
> And what about binary content?

For binary files, I'd say treat it as an error; Gemini doesn't have
resumable downloads, so it's either that or retry, and I think you
should leave retrying up to the user. For text, you can show what you
have, and leave it to the user to decide if they got the full document
or not, I guess...

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jr at vrtz.ch  Fri Jul 10 14:22:45 2020
From: jr at vrtz.ch (Johannes von Rotz)
Date: Fri, 10 Jul 2020 15:22:45 +0200
Subject: Debugging TLS connections with Wireshark?
In-Reply-To: <CANmFPemmD_cs8Y=zvUg=kuJgb74UWjX0e3K8YCVxzqKK_okruw@mail.gmail.com>
References: <CANmFPemmD_cs8Y=zvUg=kuJgb74UWjX0e3K8YCVxzqKK_okruw@mail.gmail.com>
Message-ID: <e941c0e2-7b2e-f209-ba79-2da5c23f4ea5@vrtz.ch>

On 10.07.2020 13:18, Hannu Hartikainen wrote:
> I logged some traffic between my own client and server last night with
> Wireshark. Obviously the data is encrypted, but I was surprised to not
> be able to decrypt the data even when I have the private key for the
> server (it would work for some TLS 1.2 setup, apparently). Fortunately I
> found the bug hindering my progress just by looking at the code. Eventually.
> 
> Does anyone know how to log TLS session keys and later use them to
> decrypt the logged traffic? Does some client perhaps already support?this?

The (asymmetric) keys in the certificates are only used to exchange a
(symmetric) session key, which would need to be logged in order to be
able to decrypt the traffic.

You would typically log the session keys to a file which then is read by
Wireshark to decrypt the TLS traffic, see [0] for an example using Firefox.

To have an idea of how to do it in your own application you might want
to have a look at the answers at [1].

Cheers, J.

[0] https://wiki.wireshark.org/TLS#Using_the_.28Pre.29-Master-Secret
[1]
https://security.stackexchange.com/questions/80158/extract-pre-master-keys-from-an-openssl-application

From jmcbray at carcosa.net  Fri Jul 10 14:30:20 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 10 Jul 2020 09:30:20 -0400
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <87v9iwwepu.fsf@disroot.org> (Gary Johnson's message of "Thu, 09
 Jul 2020 17:39:09 -0400")
References: <87v9iwwepu.fsf@disroot.org>
Message-ID: <875zavcxar.fsf@dorothy.carcosa.net>

Gary Johnson <lambdatronic at disroot.org> writes:

> Space Age is a Gemini server written in Clojure (https://clojure.org/).

Nice, now there are two parenthesis-oriented Gemini servers ;)

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From colecmac at protonmail.com  Fri Jul 10 15:51:38 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 10 Jul 2020 14:51:38 +0000
Subject: Client behavior when server doesn't close connection?
In-Reply-To: <7aa1615a-fdb0-18ea-629d-2aee3237c005@envs.net>
References: <5a416869-87b0-0095-2c3b-1971b59a480f@envs.net>
 <j8tQ-1EhCX34oz-bxmi_ovdwCio0pOWJxeO96pBGVSGi3ZBsnG48VNNtoL4xHefENxApo-fh65LzvCMRLel0ZGGohe8m3Mh9A6oG3wNi0XU=@protonmail.com>
 <7aa1615a-fdb0-18ea-629d-2aee3237c005@envs.net>
Message-ID: <QekhEKBXN1Fwxj38rbpu0z-NVly4ZqZ2mT2tNcTlAucaM7ULa0OgkYpWNGZo9VDyEjz1azUH7YvG8i-8WEKG13bVtn4KgW19qPq8Pa3bvSM=@protonmail.com>

??????? Original Message ???????
On Friday, July 10, 2020 12:20 AM, juhani <juhani at envs.net> wrote:

> On 9.7.2020 17.38, colecmac at protonmail.com wrote:
>
> > the data fine, presumably indicated by a closed connection. Maybe the Go TLS
> > implementation is just more robust?
>
> That seems to be the case. I recorded a request with amfora and jetforce.
> Looks like jetforce terminates the TLS session, amfora confirms that, and
> then amfora closes the socket.


Thanks for looking into this! Good to know what's happening behind the scenes.
I assume it's exactly the same for gemget.

Thanks,
makeworld



From cage-dev at twistfold.it  Fri Jul 10 16:17:54 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 10 Jul 2020 17:17:54 +0200
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <875zavcxar.fsf@dorothy.carcosa.net>
References: <87v9iwwepu.fsf@disroot.org> <875zavcxar.fsf@dorothy.carcosa.net>
Message-ID: <20200710151754.GA2370@kurosawa.casa.net>

On Fri, Jul 10, 2020 at 09:30:20AM -0400, Jason McBrayer wrote:

[...]

> > Space Age is a Gemini server written in Clojure (https://clojure.org/).
>
> Nice, now there are two parenthesis-oriented Gemini servers ;)

And a client too ;-)

Bye!
C.

From luke at marmaladefoo.com  Fri Jul 10 17:00:12 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 10 Jul 2020 17:00:12 +0100
Subject: Ansi colour markup - what encoding or mime type
Message-ID: <5F08908C.4040609@marmaladefoo.com>

Hello all

My understanding is that you can use special ANSI markup/escape 
characters to indicate colours.

What is the correct mime type or encoding should be used for this?

Some pages in gemini just seem to apply it in the expectation clients 
will expect it or know how to parse it, but it is not part of the Gemini 
spec, and is a terminal thing only. It seems like sending html markup in 
the middle of a text/gemini file and expecting a client will handle it 
correctly.

Should such pages be served with a specific mime type or encoding to 
definitively indicate this?

thanks

  - Luke

From colecmac at protonmail.com  Fri Jul 10 17:03:52 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 10 Jul 2020 16:03:52 +0000
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <5F08908C.4040609@marmaladefoo.com>
References: <5F08908C.4040609@marmaladefoo.com>
Message-ID: <xionHlB4-YFN70MP5-nxfWCtr4tsxxRVpN5XGt9T9Ujl7jNpVAKu3OSTFejhk9rtC9Gl6RWAqthICVgrLcKKzwha31mE1833qOTOoC7ka9A=@protonmail.com>

It's an interesting question. Personally I'd recommend against
using it very much, unless it's just for fun on one page or something.
But I would advise against using it regularly in gemlog posts or something
like that.

As for mimetype and encoding, I think sticking with text/gemini and UTF-8
is good. Above all, just don't expect clients to render it properly. Some
will and some won't.

makeworld

From petite.abeille at gmail.com  Fri Jul 10 17:15:00 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 10 Jul 2020 18:15:00 +0200
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <5F08908C.4040609@marmaladefoo.com>
References: <5F08908C.4040609@marmaladefoo.com>
Message-ID: <6BA4AF50-E0EF-4B0A-9B35-191F82670069@gmail.com>



> On Jul 10, 2020, at 18:00, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> Should such pages be served with a specific mime type or encoding to definitively indicate this?

My 2?: avoid ANSI escape sequences like the plague. Just say no. Leave it to the terminal kamikaze.

From petite.abeille at gmail.com  Fri Jul 10 17:30:02 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 10 Jul 2020 18:30:02 +0200
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <xionHlB4-YFN70MP5-nxfWCtr4tsxxRVpN5XGt9T9Ujl7jNpVAKu3OSTFejhk9rtC9Gl6RWAqthICVgrLcKKzwha31mE1833qOTOoC7ka9A=@protonmail.com>
References: <5F08908C.4040609@marmaladefoo.com>
 <xionHlB4-YFN70MP5-nxfWCtr4tsxxRVpN5XGt9T9Ujl7jNpVAKu3OSTFejhk9rtC9Gl6RWAqthICVgrLcKKzwha31mE1833qOTOoC7ka9A=@protonmail.com>
Message-ID: <4A7CD2C5-E9A2-491D-969F-E1AC140E841D@gmail.com>



> On Jul 10, 2020, at 18:03, colecmac at protonmail.com wrote:
> 
> Above all, just don't expect clients to render it properly. Some
> will and some won't.

Furthermore, avoid any terminal based client which merely dump raw ANSI escape codes at you. Like in many aspects of life, sanitization it key.

For example:
git: client prints server-sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1000021
https://public-inbox.org/git/20180205204312.GB104086 at aiede.svl.corp.google.com/




From hannu.hartikainen+gemini at gmail.com  Fri Jul 10 17:38:44 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Fri, 10 Jul 2020 19:38:44 +0300
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <5F08908C.4040609@marmaladefoo.com>
References: <5F08908C.4040609@marmaladefoo.com>
Message-ID: <CANmFPe=45QWEcSw3SfVA1sLtCYJipDys45Pydq5JSJZDQYG1oQ@mail.gmail.com>

On Fri, 10 Jul 2020 at 19:00, Luke Emmet <luke at marmaladefoo.com> wrote:
> My understanding is that you can use special ANSI markup/escape
> characters to indicate colours.

You can, in terminals with ANSI support. Some Gemini clients might
even let ANSI sequences through, but they'd be wise to strip them for
text/gemini content.

> What is the correct mime type or encoding should be used for this?

text/x-ansi seems to be used for ANSI art. That's what
gemini://ansi.hrtk.in/ serves.

-Hannu

From acdw at acdw.net  Fri Jul 10 17:42:56 2020
From: acdw at acdw.net (Case Duckworth)
Date: Fri, 10 Jul 2020 11:42:56 -0500
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <CANmFPe=45QWEcSw3SfVA1sLtCYJipDys45Pydq5JSJZDQYG1oQ@mail.gmail.com>
References: <5F08908C.4040609@marmaladefoo.com>
 <CANmFPe=45QWEcSw3SfVA1sLtCYJipDys45Pydq5JSJZDQYG1oQ@mail.gmail.com>
Message-ID: <43691588-01d7-4a3d-823c-5825f4eadfb3@www.fastmail.com>

On 2020-07-10 (Friday) at 11:38, Hannu Hartikainen <hannu.hartikainen+gemini at gmail.com> wrote:

> You can, in terminals with ANSI support. Some Gemini clients might
> even let ANSI sequences through, but they'd be wise to strip them for
> text/gemini content.

I know that with bollux at least (and I think Castor, at least last time I checked, though it's been a while), only the SGR parameters[1] are passed through. That's done automatically with less in bollux, but there are libraries for other languages that can apply highlighting.

Of course, I agree that ANSI escapes should be used *very* sparingly, if indeed at all.

From tomasino at lavabit.com  Fri Jul 10 18:53:41 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 10 Jul 2020 17:53:41 +0000
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <43691588-01d7-4a3d-823c-5825f4eadfb3@www.fastmail.com>
References: <5F08908C.4040609@marmaladefoo.com>
 <CANmFPe=45QWEcSw3SfVA1sLtCYJipDys45Pydq5JSJZDQYG1oQ@mail.gmail.com>
 <43691588-01d7-4a3d-823c-5825f4eadfb3@www.fastmail.com>
Message-ID: <fd871d73-3904-e27e-cc97-f6557da0d4e4@lavabit.com>

On 7/10/20 4:42 PM, Case Duckworth wrote:
> Of course, I agree that ANSI escapes should be used *very* sparingly, if indeed at all.

You can also do like astrobotany and offer a "fancy" version and a regular one. Konpieto used to offer a "spicy" version with ansi color. I like that approach as it doesn't get in the way but it can be fun for those who can see the colors.


From b__m__e at mailfence.com  Fri Jul 10 19:07:50 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Fri, 10 Jul 2020 20:07:50 +0200 (CEST)
Subject: Ansi colour markup - what encoding or mime type
Message-ID: <941284882.615956.1594404470000@ichabod.co-bxl>

My 2 cents:

Colors are really fun for those in terminal clients that support them, 
but seem to be a pain to build out for graphical clients. So expect 
failure. I really loved Konpeito's color banner and really like occasional
touches of color. However, full pages of colors tend to get weird.
Subtle is the way to go to provide a splash of fun.

My client, Bombadillo, has 'normal' and 'color' modes. In normal 
mode all escape sequences are stripped from text/gemini output. 
In color mode escape sequences dealing with color and text style 
(but not placement) are rendered as the escape sequence so that
the effect can be seen.

I advise client authors to strip escape sequences if they do not wish
to deal with color output or terminals potentially getting really
donked.

From lambdatronic at disroot.org  Fri Jul 10 19:38:28 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 10 Jul 2020 14:38:28 -0400
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <CANmFPe=Hx2q2z8QP+ap0Dy9fML7NX_JFxXjFWJ8YW9XJ5gdtqA@mail.gmail.com>
References: <87v9iwwepu.fsf@disroot.org>
 <CANmFPe=Hx2q2z8QP+ap0Dy9fML7NX_JFxXjFWJ8YW9XJ5gdtqA@mail.gmail.com>
Message-ID: <87pn93gqqj.fsf@disroot.org>

Hi Hannu,

  Thanks for the feedback. I also write Clojure+Clojurescript for a
living doing full stack web development and scientific modelling in the
environmental arena.

To control RAM consumption by the JVM, you can set -D-Xmx in Space Age's
toplevel deps.edn file. Outside of embedded environments (e.g.,
Raspberry Pis), I suspect the default of a few hundred MBs of RAM
shouldn't be too much of a burden for most laptops, desktops, or VMs,
but with that flag, you can set the JVM's max memory to whatever you
want. GraalVM could be an interesting build target though, so let me
know if have any success compiling Space Age on it.

I'll take a look at java.net.URI to see if it provides any benefit over
my current approach. I suspect I'll still need to perform string
trimming, selective lower-casing for some URI components, and default
values for missing elements as I am doing currently, but if it shaves a
few lines off the code base, that's certainly nothing to complain about.
;)

In other news, I just added a primitive CLJ script running facility to
Space Age. Now all you have to do is drop an executable <whatever>.clj
file into your ~/public_gemini folder (or the document root directory),
and you're off to the races! Any query params from the request URL are
available to the script in a global variable called (creatively)
"request-params". Anything you print to stdout in your script will be
returned as the body of a text/gemini response to the client.

I'm still thinking through just how much additional info I want to pass
to these scripts and how/whether I should let them send non-success
responses, but that's half the fun of it after all.

(hack 'the :planet)
  Gary


Hannu Hartikainen <hannu.hartikainen+gemini at gmail.com> writes:

> On Fri, Jul 10, 2020, 00:39 Gary Johnson <lambdatronic at disroot.org> wrote:
>
>> Space Age is a Gemini server written in Clojure (https://clojure.org/).
>>
>> It implements Gemini protocol specification v0.14.2 (July 2nd 2020), all
>> except for client certificates (which I'm still working on).
>>
>> The entire code base (including build files) clocks in at a cool 200
>> lines with absolutely no dependency libraries.
>>
>
> Great work!
>
> I write Clojure at $dayjob and consider it a great fit for full-stack web
> (and Gemini by extension). Besides a static Gemini site, I've written one
> CGI app in Rust (twinwiki) and one server/app in Python/Jetforce (
> ansi.hrtk.in). Both could have been in Clojure if there was a nice library.
>
> For my use RAM consumption is important, though, so I'd need to measure a
> bit with GraalVM or possibly a tiny JVM instance. Practically Rust will
> always be the better (best?) choice, but it's a bit heavy for prototyping.
>
> Briefly reading the code I was left wondering if java.net.URI wouldn't
> parse URIs out of the box. Probably it's just not ergonomic and/or has
> weird corner cases...
>
> Happy hacking!
>
> -Hannu


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From petite.abeille at gmail.com  Fri Jul 10 19:51:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 10 Jul 2020 20:51:11 +0200
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <87pn93gqqj.fsf@disroot.org>
References: <87v9iwwepu.fsf@disroot.org>
 <CANmFPe=Hx2q2z8QP+ap0Dy9fML7NX_JFxXjFWJ8YW9XJ5gdtqA@mail.gmail.com>
 <87pn93gqqj.fsf@disroot.org>
Message-ID: <563E24A9-0B05-4E16-B380-EB0F16456A25@gmail.com>



> On Jul 10, 2020, at 20:38, Gary Johnson <lambdatronic at disroot.org> wrote:
> 
> Any query params from the request URL are
> available to the script in a global variable called (creatively)
> "request-params". Anything you print to stdout in your script will be
> returned as the body of a text/gemini response to the client.
> 
> I'm still thinking through just how much additional info I want to pass
> to these scripts and how/whether I should let them send non-success
> responses, but that's half the fun of it after all.

Perhaps The Common Gateway Interface (CGI) could be of guidance?

Sounds similar in principle.


From lambdatronic at disroot.org  Fri Jul 10 20:01:45 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 10 Jul 2020 15:01:45 -0400
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <563E24A9-0B05-4E16-B380-EB0F16456A25@gmail.com>
References: <87v9iwwepu.fsf@disroot.org>
 <CANmFPe=Hx2q2z8QP+ap0Dy9fML7NX_JFxXjFWJ8YW9XJ5gdtqA@mail.gmail.com>
 <87pn93gqqj.fsf@disroot.org> <563E24A9-0B05-4E16-B380-EB0F16456A25@gmail.com>
Message-ID: <87k0zbgpnq.fsf@disroot.org>

Yes, these are CGI scripts in practice. I'm just trying not to shell out
to subprocesses in the interest of server responsiveness. I'm currently
just thinking through how to provide as simple and intuitive an
interface as possible for the script writer. Probably it will amount to
some kind of handler function API that takes a request map and returns a
response map in the classic tradition of all ring-based Clojure web
apps.

Scripts are currently run within their own auto-generated temporary
namespaces, which prevents them from accidentally polluting the server's
namespaces with def* forms. Any I/O to stdout is captured in a string
and currently returned as the body of a "20 text/gemini; charset=utf-8"
response. This is fine as a starting point, but I think I want to create
something that feels more functional and less state-oriented pretty
soon.

I'll keep you posted as it progresses.

Happy hacking,
  Gary


Petite Abeille <petite.abeille at gmail.com> writes:

>> On Jul 10, 2020, at 20:38, Gary Johnson <lambdatronic at disroot.org> wrote:
>> 
>> Any query params from the request URL are
>> available to the script in a global variable called (creatively)
>> "request-params". Anything you print to stdout in your script will be
>> returned as the body of a text/gemini response to the client.
>> 
>> I'm still thinking through just how much additional info I want to pass
>> to these scripts and how/whether I should let them send non-success
>> responses, but that's half the fun of it after all.
>
> Perhaps The Common Gateway Interface (CGI) could be of guidance?
>
> Sounds similar in principle.


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From sean at conman.org  Fri Jul 10 21:05:23 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 10 Jul 2020 16:05:23 -0400
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <87k0zbgpnq.fsf@disroot.org>
References: <87v9iwwepu.fsf@disroot.org>
 <CANmFPe=Hx2q2z8QP+ap0Dy9fML7NX_JFxXjFWJ8YW9XJ5gdtqA@mail.gmail.com>
 <87pn93gqqj.fsf@disroot.org> <563E24A9-0B05-4E16-B380-EB0F16456A25@gmail.com>
 <87k0zbgpnq.fsf@disroot.org>
Message-ID: <20200710200523.GW19717@brevard.conman.org>

It was thus said that the Great Gary Johnson once stated:
> Yes, these are CGI scripts in practice. I'm just trying not to shell out
> to subprocesses in the interest of server responsiveness. I'm currently
> just thinking through how to provide as simple and intuitive an
> interface as possible for the script writer. Probably it will amount to
> some kind of handler function API that takes a request map and returns a
> response map in the classic tradition of all ring-based Clojure web
> apps.
>
> Scripts are currently run within their own auto-generated temporary
> namespaces, which prevents them from accidentally polluting the server's
> namespaces with def* forms. Any I/O to stdout is captured in a string
> and currently returned as the body of a "20 text/gemini; charset=utf-8"
> response. This is fine as a starting point, but I think I want to create
> something that feels more functional and less state-oriented pretty
> soon.
> 
  GLV-1.12556 [1] uses handlers to generate content.  The builtin handlers
include ones to serve up a file (yup--just one file), a filesystem (handles
serving up data from a directory) and user directories [2].  The API I use
is simple.  The optional functions are:

	okay,err = init(conf)

  This function does any intialization for the handler.  It is given the
configuration parameters from the configuration file and returns 'true' if
success, or 'false' and an error message if it fails.  Typically, if I have
this function, it verifies the configuration passed in to make sure it will
handle requests.  This configuratio block can also be used for state
information for the handler if need be.

	okay,err = fini(conf)

  This function is called when the server is being shut down, and is
intended to do any cleanup (that isn't not already handled by the garbage
collector) or saving any persistent data [3].

  The mandatory function is:

	status,mime,data = handler(conf,auth,location,match)

  This handles a request.  It's given the configuration block, the client
certificate (if any [4]), the parsed URL and the 'match' array, which I
don't know how to explain other than an example, in this case, the
filesystem handler (from my development system configuration file):

	{
	  path      = "^(/cgi%-bin/)(.*)",
          module    = "GLV-1.handlers.filesystem",
          directory = "/home/spc/projects/gemini/non-checkin/cgi-bin",
          cgi       = true,
	}

  The path component is a Lua pattern (a type of regex) to determine which
handler to call for a given request, and it has two parts, the first (which
is captured in ()) determines the "base" path of the request, and the second
is the part the handler is reponsible for.  It's these two captures that are
passed in the 'match' section.

  This function returns a status code, meta information (named mime here)
and a body (which for errors, has to be "") as a string.  Handlers do not
have direct access to the socket.  And a given handler can be instantiated
multiple times, each with its own configuration block.

  As handlers in GLV-1.12556 are also Lua modules, that means they get their
own "global" namespace.  It works and I've had no issue with this structure. 
It also means it's easier for me to write a handler than it is a CGI (or
SCGI) script, although it does mean I have to add a configuration block and
restart the server when adding a new handler.

  -spc

[1]	https://github.com/spc476/GLV-1.12556

[2]	I run more custom handlers than I do builtin ones.

[3]	My "quote of the day" handler will save which quote was last served
	in order to pick up from where it left off.

[4]	Authorization has already been done by the time the request is
	handled so the handler doesn't need to do it, but some handlers
	(like the filesystem handler, which deals with CGI/SCGi) can do some
	additional processing.

From hannu.hartikainen+gemini at gmail.com  Fri Jul 10 21:48:45 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Fri, 10 Jul 2020 23:48:45 +0300
Subject: [ANN] New Gemini Server: Space Age
In-Reply-To: <87pn93gqqj.fsf@disroot.org>
References: <87v9iwwepu.fsf@disroot.org>
 <CANmFPe=Hx2q2z8QP+ap0Dy9fML7NX_JFxXjFWJ8YW9XJ5gdtqA@mail.gmail.com>
 <87pn93gqqj.fsf@disroot.org>
Message-ID: <CANmFPemNZ9-_36d=xFyPFLQjwnn3mD1pYvzBnuiY-p+rk44MiA@mail.gmail.com>

On Fri, 10 Jul 2020 at 21:38, Gary Johnson <lambdatronic at disroot.org> wrote:
> To control RAM consumption by the JVM, you can set -D-Xmx in Space Age's
> toplevel deps.edn file.

True, but I've had clojure and java apps crash with OOM in production
by giving them too little. In my experience you need to measure the
RAM consumption with maximum expected load, then add a bit for the
unexpected. Of course for a typical Gemini server that *should* be
very little. Yet I'll need to measure to know. :)

> Outside of embedded environments (e.g.,
> Raspberry Pis), I suspect the default of a few hundred MBs of RAM
> shouldn't be too much of a burden for most laptops, desktops, or VMs,

True, for a single server. But my VPS is soon running four Gemini
servers, some web ones and I have plans for more. The way JVM works it
tends to stay at max allocation, so each JVM instance is a burden.
Thankfully VPSes are huge these days. I used to have one with 64MB
RAM...

But yeah, I'll keep your project in mind. Maybe I'll find the
inspiration to hack with it on GraalVM one of these days!

> (hack 'the :planet)

::awesome!

From hannu.hartikainen+gemini at gmail.com  Fri Jul 10 22:01:20 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Sat, 11 Jul 2020 00:01:20 +0300
Subject: Debugging TLS connections with Wireshark?
In-Reply-To: <e941c0e2-7b2e-f209-ba79-2da5c23f4ea5@vrtz.ch>
References: <CANmFPemmD_cs8Y=zvUg=kuJgb74UWjX0e3K8YCVxzqKK_okruw@mail.gmail.com>
 <e941c0e2-7b2e-f209-ba79-2da5c23f4ea5@vrtz.ch>
Message-ID: <CANmFPenxfVmhNjitfERHx5ct5vzre-R0+39zx8gOeNRqquLPrA@mail.gmail.com>

Thanks for the pointers!

On Fri, 10 Jul 2020 at 16:23, Johannes von Rotz <jr at vrtz.ch> wrote:
> To have an idea of how to do it in your own application you might want
> to have a look at the answers at [1].

I thought it annoying to hack something manually for each different case.
There's now support in the go-gemini library to log pre-master secrets by
setting the env var SSLKEYLOGFILE, just like firefox and chrome and curl.
It will land in gemget at some point (and of course other clients and
servers based on go-gemini).

Big thanks to @makeworld for helping me with the commit and merging the
change! ?

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200711/3537bb45/attachment.htm>

From colecmac at protonmail.com  Fri Jul 10 22:31:18 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 10 Jul 2020 21:31:18 +0000
Subject: Debugging TLS connections with Wireshark?
In-Reply-To: <CANmFPenxfVmhNjitfERHx5ct5vzre-R0+39zx8gOeNRqquLPrA@mail.gmail.com>
References: <CANmFPemmD_cs8Y=zvUg=kuJgb74UWjX0e3K8YCVxzqKK_okruw@mail.gmail.com>
 <e941c0e2-7b2e-f209-ba79-2da5c23f4ea5@vrtz.ch>
 <CANmFPenxfVmhNjitfERHx5ct5vzre-R0+39zx8gOeNRqquLPrA@mail.gmail.com>
Message-ID: <RpG8hDbW6yAvCdXdJtY0si0tGh_x9m6YBzajRY--HQPT_ffPFYenrKPzGoxHGSGTC4w7GOmgKMD-FadBw9efTcW2xISA-9_1B8BQ2YF_v9c=@protonmail.com>

> I thought it annoying to hack something manually for each different case. There's now support in the go-gemini library to log pre-master secrets by setting the env var SSLKEYLOGFILE, just like firefox and chrome and curl. It will land in gemget?at some point (and of course other clients and servers based on go-gemini).
>
> Big thanks to?@makeworld for helping me with the commit and merging the change!??
>
> -Hannu

You're welcome, thanks for making the PR! Support for this is now
in the gemget and Amfora master branches, and will be in the next
release of both of them.

Cheers,
makeworld

From alex at gnu.org  Sat Jul 11 23:04:19 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sun, 12 Jul 2020 00:04:19 +0200
Subject: [ANN] Gemini Wiki
Message-ID: <dcfe651f25f413c417f12c6cd6599d9b9925f5a2.camel@gnu.org>

Gemini Wiki has been getting a few more features these days... The
latest one is virtual hosting. I usually post these things on the
instance I run myself.
=> gemini://alexschroeder.ch:1968/page/2020-07-11%20Virtual%20Hosting

(Note the port: this is not my homepage.)

The last few blog items are always visible on the main page.
=> gemini://alexschroeder.ch:1968/

If you want to follow the edits on that wiki, there's an Atom feed, and
a list of changes made.
=> gemini://alexschroeder.ch:1968/do/atom
=> gemini://alexschroeder.ch:1968/do/changes

Cheers
Alex



From luke at marmaladefoo.com  Sun Jul 12 09:50:22 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 12 Jul 2020 09:50:22 +0100
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <CANmFPe=45QWEcSw3SfVA1sLtCYJipDys45Pydq5JSJZDQYG1oQ@mail.gmail.com>
References: <5F08908C.4040609@marmaladefoo.com>
 <CANmFPe=45QWEcSw3SfVA1sLtCYJipDys45Pydq5JSJZDQYG1oQ@mail.gmail.com>
Message-ID: <5F0ACECE.50402@marmaladefoo.com>


On 10-Jul-2020 17:38, Hannu Hartikainen wrote:
>> What is the correct mime type or encoding should be used for this?
> text/x-ansi seems to be used for ANSI art. That's what
> gemini://ansi.hrtk.in/ serves.

Thanks for all your replies

My reading of the situation now is as follows:

ANSI escape sequences should not be interpreted within text/gemini 
content (after all when would it stop - there could be embedded html or 
other markup that clients will become expected to interpret). Similarly 
they should not be stripped out - since how would one know they were 
there, and should be intepreted rather than just presented. |On a Gemini 
page I might say something like: "Is this the correct code to make all 
text black: \033[30m ?" But I dont want to make the rest of my page 
black by doing so

In terms of where these sequences may be interpreted or stripped out 
there seem to be 3 candidates:

1. content served as text/x-ansi - e.g. for ANSI art

2. content in a preformatted range with the label indicating it as 
text/x-ansi - we dont have a semantics or convention for this yet, but 
it would be nice, like this maybe:

```art;content-type=text/x-ansi

3. content served as some hybrid gemini format like text/gemini+x-ansi

I guess the general points of non-extensibility come up - would this 
become a de-facto expectation for clients to implement? Could there be 
other formats like text/gemini+html?

Best Wishes

  - Luke
|

From lambdatronic at disroot.org  Sun Jul 12 15:41:36 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Sun, 12 Jul 2020 10:41:36 -0400
Subject: [ANN] Space Age now supports dynamic Gemini apps
Message-ID: <87o8okaj8f.fsf@disroot.org>

Howdy Geminauts,

  Space Age will now treat any executable CLJ file in a served directory
as a full fledged Gemini application. Each such CLJ file must define a
"main" function, which takes a request map and returns a response map in
the style of Ring-based Clojure web apps but using the relevant Gemini
protocol keys instead. It's a simple functional idiom that empowers you
to request user input, redirect, return failure messages, or create
dynamic Gemini content.

To learn more, check it out on Gitlab:

  https://gitlab.com/lambdatronic/space-age

(into [:the] #{:future})
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From btilley at gatech.edu  Sun Jul 12 22:25:21 2020
From: btilley at gatech.edu (btilley at gatech.edu)
Date: Sun, 12 Jul 2020 21:25:21 +0000
Subject: SCGI with molly-brown
Message-ID: <20200712212520.GA29194@beagle.local>

Hi,

I have a molly-brown server running on OpenBSD armv7 here:

    gemini://gemini.go350.com/

I'm trying to get basic SCGI functionality now. I wrote a small Go program as an initial SCGI program:

    gemini://gemini.go350.com/main.go

The program works on the system. I can invoke it with netcat and see its output:

    $ nc -U /tmp/url_check.sock 
    Content-Type: text/plain

    Hi there!

However, I cannot get it to work with molly-brown (castor and bombadillo browsers). I think I have everything configure correctly in molly-brown. Here is my SCGI Path from /etc/molly.conf:

    "/scgi-app-1/" = "/tmp/url_check.sock"

Can someone explain what I've done wrong? 

Thanks,

Brad

From hannu.hartikainen+gemini at gmail.com  Sun Jul 12 23:15:32 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Mon, 13 Jul 2020 01:15:32 +0300
Subject: Ansi colour markup - what encoding or mime type
In-Reply-To: <5F0ACECE.50402@marmaladefoo.com>
References: <5F08908C.4040609@marmaladefoo.com>
 <CANmFPe=45QWEcSw3SfVA1sLtCYJipDys45Pydq5JSJZDQYG1oQ@mail.gmail.com>
 <5F0ACECE.50402@marmaladefoo.com>
Message-ID: <CANmFPemD_D3GDU_ACBOvHbO1-GmTiFKZK0e2+G89+zNWCxfAEQ@mail.gmail.com>

On Sun, 12 Jul 2020 at 11:50, Luke Emmet <luke at marmaladefoo.com> wrote:
> ANSI escape sequences should not be interpreted within text/gemini
> content (after all when would it stop - there could be embedded html or
> other markup that clients will become expected to interpret). Similarly
> they should not be stripped out - since how would one know they were
> there, and should be intepreted rather than just presented.

IMHO if a client is outputting to an ANSI terminal, the client author
should consider what will happen with ANSI sequences. It is reasonable
to strip or escape all of them, or a subset of them, or decide to let
them through. Consider that a terminal UI is itself built with ANSI
escapes and rendering them within the page could break the UI (or
worse, emulate the UI!). Moreover, you'd need to fully parse the
sequences and emulate terminal state to implement a sandboxed version
of ANSI sequences (unless you limit to a subset, say, SGR). I learned
that when trying to render 80-column ANSI art on wider terminals
(ansi.hrtk.in does that but background colors leak).

Similarly, if I was writing a Gemini-over-HTML proxy I'd certainly
escape all HTML tags and entities. First, it makes sense to show the
content to the user instead of interpreting it as control sequences.
Second, I've learned on the web that rendering any user-supplied
content without sanitizing will result in a disaster.

Gemini is still small and friendly, but when designing software it's
smart to account for bad actors.

-Hannu

PS. I just added yet another ANSI streaming server,
gemini://asciinema.hrtk.in/ for playing back asciinema.org recordings.
Probably only useful as a tech demo or a client test.

From btilley at gatech.edu  Mon Jul 13 02:24:27 2020
From: btilley at gatech.edu (btilley at gatech.edu)
Date: Mon, 13 Jul 2020 01:24:27 +0000
Subject: SCGI with molly-brown
In-Reply-To: <20200712212520.GA29194@beagle.local>
References: <20200712212520.GA29194@beagle.local>
Message-ID: <20200713012427.GB29194@beagle.local>

On Sun, Jul 12, 2020 at 09:25:21PM +0000, btilley at gatech.edu wrote:
> Hi,
> 
> I have a molly-brown server running on OpenBSD armv7 here:
> 
>     gemini://gemini.go350.com/
> 
> I'm trying to get basic SCGI functionality now. I wrote a small Go program as an initial SCGI program:
> 
>     gemini://gemini.go350.com/main.go
> 
> The program works on the system. I can invoke it with netcat and see its output:
> 
>     $ nc -U /tmp/url_check.sock 
>     Content-Type: text/plain
> 
>     Hi there!
> 
> However, I cannot get it to work with molly-brown (castor and bombadillo browsers). I think I have everything configure correctly in molly-brown. Here is my SCGI Path from /etc/molly.conf:
> 
>     "/scgi-app-1/" = "/tmp/url_check.sock"
> 
> Can someone explain what I've done wrong? 
> 
> Thanks,
> 
> Brad

I figured this out. It's important that this line of molly.conf is uncommented as well:

    [SCGIPaths]

I thought it was just a code comment/section marker. After uncommenting it, the SCGI program worked as expected.

From alex at gnu.org  Tue Jul 14 16:59:16 2020
From: alex at gnu.org (Alex Schroeder)
Date: Tue, 14 Jul 2020 17:59:16 +0200
Subject: [ANN] Transjovian Council: Gemini Wiki hosting
Message-ID: <ee705790e59139c304627dd0ffff95554e962ad4.camel@gnu.org>

I've decided to move all my Gemini stuff from the various solutions I
had to Gemini Wiki, and to host the main instance of Gemini Wiki on a
new site, *The Transjovian Council*.

Everything seems to be working and I guess I'm open for Gemini Wikie hosting, if you think our values align and we'd make for a good intentional community, a sort of Gemini housing cooperative ? in short, the Transjovian Council ? then let me know and we'll figure it out together.

gemini://transjovian.org/
https://transjovian.org:1965/

Cheers
Alex



From acdw at acdw.net  Tue Jul 14 17:48:49 2020
From: acdw at acdw.net (acdw)
Date: Tue, 14 Jul 2020 16:48:49 +0000
Subject: [ANN] Transjovian Council: Gemini Wiki hosting
In-Reply-To: <ee705790e59139c304627dd0ffff95554e962ad4.camel@gnu.org>
References: <ee705790e59139c304627dd0ffff95554e962ad4.camel@gnu.org>
Message-ID: <2def9c12-5317-43ec-8ce6-4f615f66ab6d@www.fastmail.com>

On 2020-07-14 (Tuesday) at 15:59, Alex Schroeder <alex at gnu.org> wrote:

> I've decided to move all my Gemini stuff from the various solutions I
> had to Gemini Wiki, and to host the main instance of Gemini Wiki on a
> new site, *The Transjovian Council*.
> 
> Everything seems to be working and I guess I'm open for Gemini Wikie 
> hosting, if you think our values align and we'd make for a good 
> intentional community, a sort of Gemini housing cooperative ? in short, 
> the Transjovian Council ? then let me know and we'll figure it out 
> together.
> 
> gemini://transjovian.org/
> https://transjovian.org:1965/
> 
> Cheers
> Alex

Absolutely beautiful work! I am especially impressed you have it working on the web *and* in geminispace :D

I've been wanting to try geminizing (and learning) toki pona stuff ... this "wiki" idea looks like the absolute best way to do it!

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From benulo at systemli.org  Tue Jul 14 20:13:13 2020
From: benulo at systemli.org (Ben)
Date: Tue, 14 Jul 2020 23:43:13 +0430
Subject: Client Call
Message-ID: <ff3bad76-5faf-d288-09b1-0ae8f1d303d0@systemli.org>

One thing I like to do is build and test Gemini clients on my Linux 
system. It's interesting for me to follow their development, and this is 
currently what I track and build:

Graphical: alrisha, castor, kristall, moonlander
Text: asuka diohsc

AV-98 of course is interpreted so I don't build it, but I do keep it up 
to date along with the rest. My system is currently unable to build 
projects written in Go, so unfortunately I have not been to test 
bombadillo though I have been wanting to. (I think there was one other 
client as well using Go.) The issue seems that I can't connect to Go's 
online repository, so it's an Internet/ISP problem that I'll have to 
figure out how to work around.

All of the clients are fantastic, but none of them are perfect yet! 
Except... elpher! When testing with my own Gemini pages, I find elpher 
renders them exactly how I want/expect. Generally graphical clients all 
have their own funny little quirks, though they are acceptable, while 
the text mode ones are all solid, so no complaints there.

If you have a client that I missed or don't know about I will be glad to 
add it to my system. I also haven't yet found an Android client I can 
use, though I ran across one in source form but can't/won't build things 
for Android so I'd go for a pre-built package.

Ben

-- 
gemini://kwiecien.us/

From gmym at coopdot.com  Tue Jul 14 21:27:40 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Tue, 14 Jul 2020 22:27:40 +0200
Subject: Client Call
In-Reply-To: <ff3bad76-5faf-d288-09b1-0ae8f1d303d0@systemli.org>
References: <ff3bad76-5faf-d288-09b1-0ae8f1d303d0@systemli.org>
Message-ID: <CAObwWNi694jCTSNry84sd6o4ChMVvGtZ7bcV+X9HkW_cD5va9A@mail.gmail.com>

Ben <benulo at systemli.org> wrote:

> If you have a client that I missed or don't know about I will be glad to
> add it to my system. I also haven't yet found an Android client I can
> use, though I ran across one in source form but can't/won't build things
> for Android so I'd go for a pre-built package.
>

Try Deedum, it's what I use on Android
https://play.google.com/store/apps/details?id=ca.snoe.deedum

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200714/9b36461d/attachment.htm>

From alex at gnu.org  Tue Jul 14 22:33:45 2020
From: alex at gnu.org (Alex Schroeder)
Date: Tue, 14 Jul 2020 23:33:45 +0200
Subject: [ANN] Transjovian Council: Gemini Wiki hosting
In-Reply-To: <2def9c12-5317-43ec-8ce6-4f615f66ab6d@www.fastmail.com>
References: <ee705790e59139c304627dd0ffff95554e962ad4.camel@gnu.org>
 <2def9c12-5317-43ec-8ce6-4f615f66ab6d@www.fastmail.com>
Message-ID: <f078f6c936c31b9fbb0f8c51ea53d7ddc25cb260.camel@gnu.org>

On Tue, 2020-07-14 at 16:48 +0000, acdw wrote:
> Absolutely beautiful work! I am especially impressed you have it
> working on the web *and* in geminispace :D

Thanks! I didn't plan on adding a write option to the web side of the
wiki, but the simple stuff about the web really is simple. This code
doesn't do content negotiation, caching, or anything like that. And
once you know this, all you have to do is read the first request line,
see whether it's a Gemini URL or a GET request, and if it's a get
request, read the reast of the headers (and maybe ignore them all,
haha) until you get to to an empty line (headers all being \r\n
separated), and that's it. 

> I've been wanting to try geminizing (and learning) toki pona stuff
> ... this "wiki" idea looks like the absolute best way to do it!

If you want to set it up yourself, I'm happy to help. And if you want a
separate wiki space, let me know. Otherwise, feel free to use
transjovian.org for Toki Pona. I also spent a little time trying to
learn the language, so you're not alone. ?

Maybe a no-tracking and beginner-friendly variant of this one:
https://tokipona.fandom.com/wiki/lipu_lawa

Cheers
Alex



From benulo at systemli.org  Wed Jul 15 06:19:37 2020
From: benulo at systemli.org (Ben)
Date: Wed, 15 Jul 2020 09:49:37 +0430
Subject: Client Call
In-Reply-To: <CAObwWNi694jCTSNry84sd6o4ChMVvGtZ7bcV+X9HkW_cD5va9A@mail.gmail.com>
References: <ff3bad76-5faf-d288-09b1-0ae8f1d303d0@systemli.org>
 <CAObwWNi694jCTSNry84sd6o4ChMVvGtZ7bcV+X9HkW_cD5va9A@mail.gmail.com>
Message-ID: <82ba2ad1-9991-b24b-902e-c97c557bb4a7@systemli.org>

On 7/15/20 12:57 AM, Katarina Eriksson wrote:
> Try Deedum, it's what I use on Android
> https://play.google.com/store/apps/details?id=ca.snoe.deedum

Oh I remember looking it up but forgot to download and try it. This is 
great!

-- 
gemini://kwiecien.us/

From colecmac at protonmail.com  Wed Jul 15 17:00:23 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 15 Jul 2020 16:00:23 +0000
Subject: Client Call
In-Reply-To: <ff3bad76-5faf-d288-09b1-0ae8f1d303d0@systemli.org>
References: <ff3bad76-5faf-d288-09b1-0ae8f1d303d0@systemli.org>
Message-ID: <W7QUrWVxFn6hhT7FwHhXM5d-fBu0wS6xgkpC2RpBfQljengou55Qg6kH8bp_-v9fA2JRm4pHPU4V5t_rmD0OCaswu04romD0bowB8k2hOoU=@protonmail.com>

Hello Ben,

> (I think there was one other client as well using Go.)

Sounds like it might be mine! :)

https://github.com/makeworld-the-better-one/amfora

I have compiled binaries for all my releases, hope that helps.
Also, if you're sure your Go issue is with accessing the Go/Google
servers, try this command:

GOPROXY=direct GOSUMDB=off GO111MODULE=on go get -u github.com/makeworld-the-better-one/amfora

Those first two env variables turn off the default behaviour where
Google's proxy servers are accessed, and just download direct from
Github, etc. Let me know if that works!

Cheers,
makeworld


From benulo at systemli.org  Wed Jul 15 17:26:37 2020
From: benulo at systemli.org (Ben)
Date: Wed, 15 Jul 2020 20:56:37 +0430
Subject: Client Call
In-Reply-To: <W7QUrWVxFn6hhT7FwHhXM5d-fBu0wS6xgkpC2RpBfQljengou55Qg6kH8bp_-v9fA2JRm4pHPU4V5t_rmD0OCaswu04romD0bowB8k2hOoU=@protonmail.com>
References: <ff3bad76-5faf-d288-09b1-0ae8f1d303d0@systemli.org>
 <W7QUrWVxFn6hhT7FwHhXM5d-fBu0wS6xgkpC2RpBfQljengou55Qg6kH8bp_-v9fA2JRm4pHPU4V5t_rmD0OCaswu04romD0bowB8k2hOoU=@protonmail.com>
Message-ID: <d8d40b57-24bd-a7b6-f67a-b254bfc5a55d@systemli.org>

On 7/15/20 8:30 PM, colecmac at protonmail.com wrote:
> I have compiled binaries for all my releases, hope that helps.

Oh yeah! I do have the binary installed, but I haven't updated it in a 
while. Very kickass client.

I will experiment with Go building a bit more. Also if their system 
supports socks5 I already have that set up on my system.

Thanks!

-- 
gemini://kwiecien.us/

From solderpunk at posteo.net  Wed Jul 15 18:56:03 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Wed, 15 Jul 2020 19:56:03 +0200
Subject: Amfora and Bombadillo now at the ssh kiosk!
Message-ID: <C47E3F5SJYZV.2823UR1TMAZ7L@stilgar>

Ahoy Geminauts,

This announcement has been a long time coming: I've *finally* added some
clients other than AV-98 to the ssh kiosk at gemini.circumlunar.space.
You can now also choose to test drive Amfora or Bombadillo.  Please let
me know if anything doesn't work as expected.

Cheers,
Solderpunk

From colecmac at protonmail.com  Wed Jul 15 19:08:01 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 15 Jul 2020 18:08:01 +0000
Subject: Amfora and Bombadillo now at the ssh kiosk!
In-Reply-To: <C47E3F5SJYZV.2823UR1TMAZ7L@stilgar>
References: <C47E3F5SJYZV.2823UR1TMAZ7L@stilgar>
Message-ID: <tNqM8wlRH3XySVTYfoQhL36pKNfWOK7OMwggyDWZs9BL_xeoYADQlY_-yQqk4SoFaQOnnbRvXExffbfFlGsUuKnVzw-5sFbL9OL8agspzyE=@protonmail.com>

This is very exciting, thanks! The only difference I noticed in
my one minute of testing is that some of the colors in Amfora seem slightly
different. This is likely due to the intricacies of terminal colors,
SSH, themes, etc, not a big deal at all.

Thanks,
makeworld


From solderpunk at posteo.net  Wed Jul 15 18:58:25 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Wed, 15 Jul 2020 19:58:25 +0200
Subject: [ANN] Announcing gemcert, a simple certificate generator
Message-ID: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>

Ahoy!

My dead simple alternative to using `openssl` and its overwhelming
torrent of cryptic command line switches to generate self-signed
certificates for use in Geminispace is finally starting to take shape
and is now ready for some test driving:

https://tildegit.org/solderpunk/gemcert

Some example incantations follow.

Want to make certificate to use for your server at example.com?  Run:

gemcert -server -domain example.com

and that's it!  You'll get, by default, an ECDSA cert valid for any
subdomain of example.com for 5 years.  Prefer ED25519 and 2 years of
validity?  Easy:

gemcert -server -domain example.com -ed25519 -years 2

Want a long-lived certificate you can use as a client cert for
Astrobotany, with the username HirokoAi?  Easy:

gemcert -client -cn HirokoAi -years 100

You get the idea.

It's still a little rough around the edges in some respects (e.g. the
output is always saved to cert.pem and key.pem in the pwd), but it
should be usable with some care.  Feedback very welcome!

Cheers,
Solderpunk

From colecmac at protonmail.com  Wed Jul 15 19:13:37 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 15 Jul 2020 18:13:37 +0000
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
References: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
Message-ID: <WPDUe2RS1JvK6VPFMii70LvSumrRQ_FacZstx0P1BryhMxlp6zISkkLVmQV1GkRtzBQ4H3zS4f389Y84-cWfEAGE2pgPXpcU6jTxQp5idsI=@protonmail.com>

This looks great, thanks!

> Prefer ED25519

I know you mention this on the README, but I just want to remind people
that it's probably best to stick with EC keys for now, as not all clients
and servers support ed25519. And the size is similar.

Also, could you add a go.mod and go.sum file to your repo. You can easily
make one with `go mod init`, just make sure the path in go.mod is correct.
That would allow using go get on the repo.

Thanks,
makeworld

From hannu.hartikainen+gemini at gmail.com  Wed Jul 15 21:33:59 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Wed, 15 Jul 2020 23:33:59 +0300
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
References: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
Message-ID: <CANmFPemfSkn_49YOqrribcNLandAV3BAiY6Li0Tvs8YpLA=Xbg@mail.gmail.com>

Cool! This is very welcome; I scratch my head every time I use openssl.

I personally greatly prefer GNU argument conventions, ie. dual dashes for
long arguments (--server) and short single-dash versions of the most common
arguments (-s). Even if you don't want to implement this now, changing the
docs to use the dual dash versions would make changing later possible.

https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html

I'd also like if the generated filenames contained the domain name. Nice
for vhost configurations.

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200715/a9360242/attachment.htm>

From hannu.hartikainen+gemini at gmail.com  Wed Jul 15 21:46:32 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Wed, 15 Jul 2020 23:46:32 +0300
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <CANmFPemfSkn_49YOqrribcNLandAV3BAiY6Li0Tvs8YpLA=Xbg@mail.gmail.com>
References: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
 <CANmFPemfSkn_49YOqrribcNLandAV3BAiY6Li0Tvs8YpLA=Xbg@mail.gmail.com>
Message-ID: <CANmFPe=HiW2Kct=z+3mC6hN6UgfEe61LksAeg9rGC_VV=1s5Mw@mail.gmail.com>

Now that I fully read the README, I have to wonder if generating wildcard
certs by default is a good idea.

I assume the use case is serving different content on different subdomains,
right? In that case you need vhost support from the server, and the server
should offer support for different certs for each vhost.

I'd argue that having a different cert for each subdomain is more flexible
because you can later move some of them to different servers. Copying a
wildcard cert around is not generally a good idea.

This is a minor detail, of course. As long as it's possible to generate
non-wildcard certs I'm ok with that.

-Hannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200715/fd292e5d/attachment.htm>

From lel at envs.net  Wed Jul 15 21:53:43 2020
From: lel at envs.net (lel)
Date: Wed, 15 Jul 2020 16:53:43 -0400
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <CANmFPemfSkn_49YOqrribcNLandAV3BAiY6Li0Tvs8YpLA=Xbg@mail.gmail.com>
References: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
 <CANmFPemfSkn_49YOqrribcNLandAV3BAiY6Li0Tvs8YpLA=Xbg@mail.gmail.com>
Message-ID: <20200715205343.GA1090@commie.my.domain>

On Wed, Jul 15, 2020 at 11:33:59PM +0300, Hannu Hartikainen wrote:
> Cool! This is very welcome; I scratch my head every time I use openssl.
> 
> I personally greatly prefer GNU argument conventions, ie. dual dashes for
> long arguments (--server) and short single-dash versions of the most common
> arguments (-s). Even if you don't want to implement this now, changing the
> docs to use the dual dash versions would make changing later possible.
> 
> https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
> 
> I'd also like if the generated filenames contained the domain name. Nice
> for vhost configurations.
> 
> -Hannu

For context, it's this way because solderpunk is using the go `flag` package,
which doesn't support GNU flags. Writing it that way would require pulling in
some external dependency, and probably doing some rewrites of the CLI flag
parsing.

~ lel

From lel at envs.net  Wed Jul 15 22:00:43 2020
From: lel at envs.net (lel)
Date: Wed, 15 Jul 2020 17:00:43 -0400
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <20200715205343.GA1090@commie.my.domain>
References: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
 <CANmFPemfSkn_49YOqrribcNLandAV3BAiY6Li0Tvs8YpLA=Xbg@mail.gmail.com>
 <20200715205343.GA1090@commie.my.domain>
Message-ID: <20200715210043.GA1664@commie.my.domain>

On Wed, Jul 15, 2020 at 04:53:43PM -0400, lel wrote:
> On Wed, Jul 15, 2020 at 11:33:59PM +0300, Hannu Hartikainen wrote:
> > Cool! This is very welcome; I scratch my head every time I use openssl.
> > 
> > I personally greatly prefer GNU argument conventions, ie. dual dashes for
> > long arguments (--server) and short single-dash versions of the most common
> > arguments (-s). Even if you don't want to implement this now, changing the
> > docs to use the dual dash versions would make changing later possible.
> > 
> > https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
> > 
> > I'd also like if the generated filenames contained the domain name. Nice
> > for vhost configurations.
> > 
> > -Hannu
> 
> For context, it's this way because solderpunk is using the go `flag` package,
> which doesn't support GNU flags. Writing it that way would require pulling in
> some external dependency, and probably doing some rewrites of the CLI flag
> parsing.
> 
> ~ lel

I sent this a bit early, I also meant to say:

... and honestly I don't think it's worth the effort and dependencies just for
the added feature of making the user type an extra dash before their arguments.

Sorry for the doublepost.

~ lel

From caranatar at riseup.net  Thu Jul 16 09:58:48 2020
From: caranatar at riseup.net (Caranatar)
Date: Thu, 16 Jul 2020 04:58:48 -0400
Subject: Status Codes Question (Forbidden/Internal Server Error)
Message-ID: <17865630-BFD6-4ED0-AB83-99F1510A9AEC@riseup.net>

Hi folks, 

I came across Gemini a couple days ago when I was looking things up in preparation to write a gopher server for practice in a language I'm learning, and decided to crank out a Gemini server instead. I'll probably send an announce for the code and my server tomorrow, but in the meantime...

I have a pretty simple question that I wasn't able to find anywhere on the mailing list or elsewhere:

Are there equivalents to the forbidden and internal server error status codes in HTTP? Alternatively, what extant status codes would y'all recommend using to indicate those errors?

It's mostly for debugging sake, but I found myself wanting a way to say "oops! File permissions are screwed up!" or "oops! I wrote some bad code and there's an unexpected error somewhere". Right now I use 51 for permissions and 59 for a catch all error, but I feel like they're semantically different enough that it irks me to use them.

Thanks and look forward to talking with y'all more,

--Caranatar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200716/98cc8498/attachment.htm>

From sean at conman.org  Thu Jul 16 10:24:47 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 16 Jul 2020 05:24:47 -0400
Subject: Status Codes Question (Forbidden/Internal Server Error)
In-Reply-To: <17865630-BFD6-4ED0-AB83-99F1510A9AEC@riseup.net>
References: <17865630-BFD6-4ED0-AB83-99F1510A9AEC@riseup.net>
Message-ID: <20200716092446.GH19717@brevard.conman.org>

It was thus said that the Great Caranatar once stated:
> Hi folks, 

  Howdy.

> I have a pretty simple question that I wasn't able to find anywhere on the
> mailing list or elsewhere:
> 
> Are there equivalents to the forbidden and internal server error status
> codes in HTTP? Alternatively, what extant status codes would y'all
> recommend using to indicate those errors?

  It's there, but probably under a different subject line.  There's this
message I sent last year:

	https://lists.orbitalfox.eu/archives/gemini/2019/000107.html

It's for running web-based CGI scripts under Gemini [1].  Here's the table I
presented:

        HTTP status     Gemini status
        ---------       --------
        200-299         20
        301             31
        300-399         30
        403             60
        404             51
        405             59
        400-499         50
        500-599         40
        000-999         50

> It's mostly for debugging sake, but I found myself wanting a way to say
> "oops! File permissions are screwed up!" or "oops! I wrote some bad code
> and there's an unexpected error somewhere". Right now I use 51 for
> permissions and 59 for a catch all error, but I feel like they're
> semantically different enough that it irks me to use them.

  What I do is use the most generic status code I can, and log (via syslog()
but use whatever mechanism works for you) the actual error to prevent
information from leaking out to a Gemini client.

  -spc

[1]	GLV-1.12556 [2] can run web-based SCGI/CGI scripts, and I had to set
	up a mapping of status values.

[2]	https://github.com/spc476/GLV-1.12556

From alex at gnu.org  Thu Jul 16 23:16:41 2020
From: alex at gnu.org (Alex Schroeder)
Date: Fri, 17 Jul 2020 00:16:41 +0200
Subject: The Transjovian Vault: moving my Wikipedia Proxy to a separate domain
Message-ID: <c3b5c609cb645ebbd7cad1c8c96ea04238ff9be3.camel@gnu.org>

Hi all

I've been hosting a Wikipedia Proxy on port 1967 of my site, but I'm
going to move it to a differnt domain.

If you're linking to it, please change those links.

old: gemini://alexschroeder.ch:1967 
new: gemini://vault.transjovian.org

The code is not quite the same, but close enough.

The old code is still available as a stand-alone project. I'm probably
not going to work on it any further.
https://alexschroeder.ch/cgit/gemini-wikipedia/about/

The new code is simply part of my Gemini Wiki config file. I'm going to
try and serve all my stuff from this one Gemini Wiki instance with
virtual hosts and all that. So if you care, take a look at this config
file and search for Wikipedia:
gemini://alexschroeder.ch/do/config

Cheers
Alex



From ext0l at riseup.net  Fri Jul 17 02:10:08 2020
From: ext0l at riseup.net (ext0l at riseup.net)
Date: Thu, 16 Jul 2020 18:10:08 -0700
Subject: Co-serving a static site over Gemini
Message-ID: <cbf108be4558dfb13d1968017d949188@riseup.net>

Right now, my personal site https://catgirl.ai is generated using a
static site generator (Zola). I have a git repo with a bunch of markdown
files, and when I want to update it I build and rsync to the server.
Pretty standard stuff.

I'd like to serve it over Gemini as well. So I'm working on a project
<https://github.com/deifactor/exarch> to do so. But now I'm thinking:
since Gemini servers are super easy to write, maybe instead of
converting the markdown to Gemtext and serving that using a generic
Gemini server, maybe I could have Exarch serve the md files and do the
conversion directly, sa well as the 'template' files I use to generate
the lists of posts. And then I just copy over the entire repo and run
`exarch serve repo-root` to serve it via Gemini (or define an archive
format that contains all the gmi files and templates and such).

What do you all think?

ps: I haven't looked too deeply to see if there's an existing solution,
because I want an excuse to learn async Rust :)

From sean at conman.org  Fri Jul 17 03:16:03 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 16 Jul 2020 22:16:03 -0400
Subject: Co-serving a static site over Gemini
In-Reply-To: <cbf108be4558dfb13d1968017d949188@riseup.net>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
Message-ID: <20200717021603.GJ19717@brevard.conman.org>

It was thus said that the Great ext0l at riseup.net once stated:
> 
> I'd like to serve it over Gemini as well. So I'm working on a project
> <https://github.com/deifactor/exarch> to do so. But now I'm thinking:
> since Gemini servers are super easy to write, maybe instead of
> converting the markdown to Gemtext and serving that using a generic
> Gemini server, maybe I could have Exarch serve the md files and do the
> conversion directly, sa well as the 'template' files I use to generate
> the lists of posts. And then I just copy over the entire repo and run
> `exarch serve repo-root` to serve it via Gemini (or define an archive
> format that contains all the gmi files and templates and such).
> 
> What do you all think?

  Sounds like a great idea.  I just finished a module [1] for my own Gemini
server [2] that will convert an entry on my blog [3] from HTML to Gemini
[4].  Although in doing the conversion, I wasn't completely satisfied with
the results due to the simplified nature of Gemin text compared to HTML.  It
works, but there are some cases (like nested <BLOCKQUOTE>s or tables) that
might end up looking a bit wierd.

  -spc

[1]	gemini://gemini.conman.org/extensions/GLV-1/handlers/blog.lua

[2]	https://github.com/spc476/GLV-1.12556

[3]	http://boston.conman.org/

[4]	The feed file:

		gemini://gemini.conman.org/gemlog.gmini

	The archive:

		gemini://gemini.conman.org/boston/

From ext0l at riseup.net  Fri Jul 17 06:00:08 2020
From: ext0l at riseup.net (ext0l at riseup.net)
Date: Thu, 16 Jul 2020 22:00:08 -0700
Subject: Co-serving a static site over Gemini
In-Reply-To: <20200717021603.GJ19717@brevard.conman.org>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
 <20200717021603.GJ19717@brevard.conman.org>
Message-ID: <ea3a615585b1040dcaac58511244080e@riseup.net>

On 2020-07-16 19:16, Sean Conner wrote:
> It was thus said that the Great ext0l at riseup.net once stated:
>>
>> I'd like to serve it over Gemini as well. So I'm working on a project
>> <https://github.com/deifactor/exarch> to do so. But now I'm thinking:
>> since Gemini servers are super easy to write, maybe instead of
>> converting the markdown to Gemtext and serving that using a generic
>> Gemini server, maybe I could have Exarch serve the md files and do the
>> conversion directly, sa well as the 'template' files I use to generate
>> the lists of posts. And then I just copy over the entire repo and run
>> `exarch serve repo-root` to serve it via Gemini (or define an archive
>> format that contains all the gmi files and templates and such).
>>
>> What do you all think?
> 
>   Sounds like a great idea.  I just finished a module [1] for my own Gemini
> server [2] that will convert an entry on my blog [3] from HTML to Gemini
> [4].  Although in doing the conversion, I wasn't completely satisfied with
> the results due to the simplified nature of Gemin text compared to HTML.  It
> works, but there are some cases (like nested <BLOCKQUOTE>s or tables) that
> might end up looking a bit wierd.
> 
>   -spc
> 
> [1]	gemini://gemini.conman.org/extensions/GLV-1/handlers/blog.lua
> 
> [2]	https://github.com/spc476/GLV-1.12556
> 
> [3]	http://boston.conman.org/
> 
> [4]	The feed file:
> 
> 		gemini://gemini.conman.org/gemlog.gmini
> 
> 	The archive:
> 
> 		gemini://gemini.conman.org/boston/

Yeah, I briefly considered starting from the HTML output since that'd
let me ensure that everything looks the same, but then I'd wind up doing
a bunch of weird stuff to work with elements of the HTML that shouldn't
be replicated (having a title link at the top of each page is idiomatic
HTML, but doesn't seem to be idiomatic Gemtext).

From sean at conman.org  Fri Jul 17 07:27:33 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 17 Jul 2020 02:27:33 -0400
Subject: Co-serving a static site over Gemini
In-Reply-To: <ea3a615585b1040dcaac58511244080e@riseup.net>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
 <20200717021603.GJ19717@brevard.conman.org>
 <ea3a615585b1040dcaac58511244080e@riseup.net>
Message-ID: <20200717062733.GL19717@brevard.conman.org>

It was thus said that the Great ext0l at riseup.net once stated:
> 
> Yeah, I briefly considered starting from the HTML output since that'd
> let me ensure that everything looks the same, but then I'd wind up doing
> a bunch of weird stuff to work with elements of the HTML that shouldn't
> be replicated (having a title link at the top of each page is idiomatic
> HTML, but doesn't seem to be idiomatic Gemtext).

  Each of my blog entries is stored in HTML, but not as a complete page.
Bascially, my HTML parser doesn't have to bother with <HTML>, <HEAD> (and
the associated tags that appear there), and the <BODY> tag itself---it only
has to deal with the tags that I use (<P>, <BLOCKQUOTE>, <DL>, <UL>, etc).
But who's to say you even have to convert everything?  You see a <TITLE>? 
Skip over that.  You can tailor both the parser and the ouput to how you do
things.

  -spc (Just an idea ... )

From caranatar at riseup.net  Fri Jul 17 08:42:43 2020
From: caranatar at riseup.net (Caranatar)
Date: Fri, 17 Jul 2020 03:42:43 -0400
Subject: [ANN] gemini://caranatar.xyz and Denoscuri
Message-ID: <87v9imy4cs.fsf@riseup.net>

Hello again, everyone.

I'm happy to announce I have my first release of my bare bones server
software and geminispace up-and-running! I hope to add more content and
functionality to both in the coming weeks, but in the meantime, please
check them both out.

Denoscuri, a Deno/TypeScript Gemini server:
https://github.com/caranatar/denoscuri

My personal geminispace:
gemini://caranatar.xyz

Cheers,
Caranatar

P.S., I know it's a little absurd to write a gemini server in a language
that compiles to javascript, but hey I'm job hunting and needed a
practice project to start learning the language. Plus I wanted to try
out Deno

-- 
sent from emacs using mu4e

From luke at marmaladefoo.com  Fri Jul 17 09:11:35 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 17 Jul 2020 09:11:35 +0100
Subject: [ANN] gemini://caranatar.xyz and Denoscuri
In-Reply-To: <87v9imy4cs.fsf@riseup.net>
References: <87v9imy4cs.fsf@riseup.net>
Message-ID: <5F115D37.6030600@marmaladefoo.com>

On 17-Jul-2020 08:42, Caranatar wrote:

 > Denoscuri, a Deno/TypeScript Gemini server:
 > https://github.com/caranatar/denoscuri
 >
 > My personal geminispace:
 > gemini://caranatar.xyz

Hello Caranatar

I'm getting "failed to connect to the server: hostname does not verify: 
x509: certificate is valid for celulinde, not caranatar.xyz"

Does your certificate match your domain?

 > P.S., I know it's a little absurd to write a gemini server in a language
 > that compiles to javascript, but hey I'm job hunting and needed a
 > practice project to start learning the language. Plus I wanted to try
 > out Deno

No its not absurd, JS is just another programming language with very 
widespread tooling. I think mostly the objections seem to be how using 
it for mobile code deployment is now a web browser client expectation so 
the number of client engines is dwindling to a small handful. And what 
is the real benefit - often not adding much actual value in many places, 
beyond marketing fluff and burning CPU cycles.

But on the server, seems perfectly fine for me, why not build on top of 
the widespread tooling that exists?

Best Wishes

  - Luke


From caranatar at riseup.net  Fri Jul 17 09:20:44 2020
From: caranatar at riseup.net (Caranatar)
Date: Fri, 17 Jul 2020 04:20:44 -0400
Subject: [ANN] gemini://caranatar.xyz and Denoscuri
In-Reply-To: <5F115D37.6030600@marmaladefoo.com>
References: <87v9imy4cs.fsf@riseup.net> <5F115D37.6030600@marmaladefoo.com>
Message-ID: <87365qzh5v.fsf@riseup.net>

Ah crap apparently none of the clients I was using to test were actually
verifying the certificate, and I forgot to change the CN when I
copy/pasted my cert generation command from my laptop. It should be
working now...

Luke Emmet writes:

> On 17-Jul-2020 08:42, Caranatar wrote:
>
>> Denoscuri, a Deno/TypeScript Gemini server:
>> https://github.com/caranatar/denoscuri
>>
>> My personal geminispace:
>> gemini://caranatar.xyz
>
> Hello Caranatar
>
> I'm getting "failed to connect to the server: hostname does not
> verify: x509: certificate is valid for celulinde, not caranatar.xyz"
>
> Does your certificate match your domain?
>
>> P.S., I know it's a little absurd to write a gemini server in a language
>> that compiles to javascript, but hey I'm job hunting and needed a
>> practice project to start learning the language. Plus I wanted to try
>> out Deno
>
> No its not absurd, JS is just another programming language with very
> widespread tooling. I think mostly the objections seem to be how using
> it for mobile code deployment is now a web browser client expectation
> so the number of client engines is dwindling to a small handful. And
> what is the real benefit - often not adding much actual value in many
> places, beyond marketing fluff and burning CPU cycles.
>
> But on the server, seems perfectly fine for me, why not build on top
> of the widespread tooling that exists?
>
> Best Wishes
>
>  - Luke


-- 
sent from emacs using mu4e

From alex at gnu.org  Fri Jul 17 10:09:35 2020
From: alex at gnu.org (Alex Schroeder)
Date: Fri, 17 Jul 2020 11:09:35 +0200
Subject: Does a cert need a Common Name matching the domain?
In-Reply-To: <87365qzh5v.fsf@riseup.net>
References: <87v9imy4cs.fsf@riseup.net> <5F115D37.6030600@marmaladefoo.com>
 <87365qzh5v.fsf@riseup.net>
Message-ID: <71e41cee98d7ecca13ce2febe9e3baf884fdc1e6.camel@gnu.org>

Luke Emmet writes:
> > I'm getting "failed to connect to the server: hostname does not
> > verify: x509: certificate is valid for celulinde, not
> > caranatar.xyz"

On Fri, 2020-07-17 at 04:20 -0400, Caranatar wrote:
> Ah crap apparently none of the clients I was using to test were
> actually
> verifying the certificate, and I forgot to change the CN when I
> copy/pasted my cert generation command from my laptop. It should be
> working now...

What do other people think about this? My personal impression was that
in a trust on first use (TOFU) world, the common name (CN) of a
certificate could be anything. It could be "Alex Schroeder", for
example. Or it could be "alexschroeder.ch". Even if it was served as
the certificate for another domain, like transjovian.org. After all,
the question is only whether you "trust on first use".

My impression is that a client that tries to verify that CN and domain
match is doing it wrong. What do you think? Sadly, my SSL know-how is
weak, so any pointers to how things ought to work in a TOFU world are
appreciated.

Cheers
Alex


From benulo at systemli.org  Fri Jul 17 10:21:50 2020
From: benulo at systemli.org (Ben)
Date: Fri, 17 Jul 2020 13:51:50 +0430
Subject: Question About Link Format
Message-ID: <3ad74bd4-e1c4-235f-65c3-1484e4109ba6@systemli.org>

Hello guys, I am not normally one to get involved in the Gemini spec. I 
got into a discussion with Martin about how UTF-8 characters are 
supposed to be handled in links in Gemini documents.

On my site I have a link in a document like this:

=> logarion/ta?ikio--lando-montara.gmi Ta?ikio: Lando Montara

This refers locally to the actual file name on the disk. The main 
question is, is this allowed in Gemini documents? I thought this should 
work because I believe that Gemini is UTF-8 native or by default, and my 
Unix file system (in this case FreeBSD UFS) appears to be in agreement.

The question is whether clients must support this as well, as in my 
experience so far all of them do but Martin's client seems to reject 
this link due to containing non-ASCII characters and doesn't handle it. 
He said that RFC3986 does not allow links to have non-ASCII characters, 
but perhaps this isn't relevant to Gemini's internal encoding and 
document format, but rather for exported URI's (ie made universal).

It does seem a proper URI should best contain %C4%9D in place of ?, but 
the question is whether I should change it in the document? Does the 
internal linking (in my case the link is local/relative) even count as a 
URI?

Ben

-- 
gemini://kwiecien.us/

From alex at gnu.org  Fri Jul 17 10:24:42 2020
From: alex at gnu.org (Alex Schroeder)
Date: Fri, 17 Jul 2020 11:24:42 +0200
Subject: Client certificates
Message-ID: <ed75980b1a96f14472c6697ad585e239f9463899.camel@gnu.org>

People on the #gemini IRC channel and on Mastodon might have seen me
struggle with client certificates on the server side and it occured to
me that I didn't post my solution to the list so here it is.

Background: I'm using Perl, with a library that uses OpenSSL bindings
in the background, so as you dig deeper, you soon end up reading the
OpenSSL documentation...

Longer write-up:
gemini://alexschroeder.ch/page/2020-07-
13_Client_Certificates_and_IO%3A%3ASocket%3A%3ASSL_%28Perl%29

Short version:

In the TOFU world, the default OpenSSL setup doesn't quite work. The
default is that clients don't send their client certificates to the
server unless the server asks for them during the handshake. In the
OpenSSL world, the server can be told to do this by telling it to
verify the client certificate. When you do that, the server will then
reject the connection because the client certificate is self-signed. In
order to force the server to still accept it, you need to provide your
own verification callback which simply returns 1 for all certificates
in the chain of certificates the client presents you with.

"SSL_set_verify() sets the verification flags for ssl to be mode and
specifies the verify_callback function to be used. If no callback
function shall be specified, the NULL pointer can be used for
verify_callback. In this case last verify_callback set specifically for
this ssl remains."
https://www.openssl.org/docs/manmaster/man3/SSL_set_verify.html

Keywords to look for in your SSL or TLS library's documentation are
"peer verification", "verification mode", "verification callback", etc.

Once you have all that, then you can get the fingerprint of the client
cert on the server side and compare it to the list of fingerprints you
know (if you're trying to only allow some people access), or save the
combination of fingerprint and common name in your database if you want
to create an account (like astrobotany does), or send a 60 code back if
there is no certificate, or a 61 code if the fingerprint doesn't match
anything in your database, or a 62 if you decide to do further tests
such as checking the validity start date or the expiry date of the
client certificate.

Hope that helps somebody
Cheers
Alex



From alex at gnu.org  Fri Jul 17 11:52:43 2020
From: alex at gnu.org (Alex Schroeder)
Date: Fri, 17 Jul 2020 12:52:43 +0200
Subject: Question About Link Format
In-Reply-To: <3ad74bd4-e1c4-235f-65c3-1484e4109ba6@systemli.org>
References: <3ad74bd4-e1c4-235f-65c3-1484e4109ba6@systemli.org>
Message-ID: <668d753c251f8f2547f7c498a7ce1fa28a5b4e7c.camel@gnu.org>

On Fri, 2020-07-17 at 13:51 +0430, Ben wrote:
> It does seem a proper URI should best contain %C4%9D in place of ?,
> but 
> the question is whether I should change it in the document? Does the 
> internal linking (in my case the link is local/relative) even count
> as a 
> URI?

I think you should change it to %C4%9D; otherwise you're relying on
clients to do it for you (which might work). But in the example you
give, the stuff after => is a URL, just not an absolute one. It's a
relative URL and the client is supposed to know how to combine it with
the URL of our current URL and to request this document if the user
wants to follow the link. So if the current URL is
gemini://example.org/foo/bar then following the link below will take
the user to gemini://example.org/foo/logarion/ta%C4%9Dikio.

=> logarion/ta?ikio--lando-montara.gmi Ta?ikio: Lando Montara

A good way to think about this would be spaces in file names. Assume
the filename is "ta?ikio: lando montara.gmi". What would you write?
This won't work:

=> logarion/ta?ikio: lando montara.gmi Ta?ikio: Lando Montara

If you escape the spaces, why not escape the rest that needs escaping?

=> logarion/ta?ikio:%20lando%20montara.gmi Ta?ikio: Lando Montara

That's how I reason about it. Or if you want to go all-in, RFC 3986 has
you covered. The only characters that unambiguously never have to
escaped, no matter where they appear, are the unreserved ones:

   Characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include uppercase and
   lowercase letters, decimal digits, hyphen, period, underscore,
   and tilde.

      unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

   https://tools.ietf.org/html/rfc3986#section-2.3

And to be clear, ALPHA means a-z and A-Z, nothing else.

Cheers
Alex



From alex at gnu.org  Fri Jul 17 12:59:49 2020
From: alex at gnu.org (Alex Schroeder)
Date: Fri, 17 Jul 2020 13:59:49 +0200
Subject: Co-serving a static site over Gemini
In-Reply-To: <cbf108be4558dfb13d1968017d949188@riseup.net>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
Message-ID: <64f33cd685bb6ffcaefd2fb0789a6230d63fc725.camel@gnu.org>

On Thu, 2020-07-16 at 18:10 -0700, ext0l at riseup.net wrote:
> maybe I could have Exarch serve the md files and do
> the
> conversion directly, sa well as the 'template' files I use to
> generate
> the lists of posts. And then I just copy over the entire repo and run
> `exarch serve repo-root` to serve it via Gemini (or define an archive
> format that contains all the gmi files and templates and such).
> 
> What do you all think?
> 

I do the same (using Perl). Except I take the raw wiki text (which may
or may not look like Markdown, haha) and convert it to gemtext on the
fly. Works reasonably well!

Cheers
Alex



From boyd.paul2 at gmail.com  Fri Jul 17 13:21:35 2020
From: boyd.paul2 at gmail.com (Paul Boyd)
Date: Fri, 17 Jul 2020 08:21:35 -0400
Subject: CGI
Message-ID: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>

Hello all,

I was excited to learn about Gemini recently. I ported some web content of
mine over (gemini://pboyd.io), and I've been enjoying looking through
what's out there.

The Gemini sites (err.. capsules?) remind me of the web in another era, so
I thought it would be fun to re-create some "classic" CGI scripts. I
started with a Guestbook (gemini://pboyd.io/guestbook/, source: gemini://
pboyd.io/guestbook/guestbook.pl). I got it working, but it felt like I was
in the weeds from the very start.

The first problem I hit is that I'm limited to one input at a time. I
wanted a few inputs (name, location, comment). Of course, plenty of command
line programs work fine with a single argument list, so, in theory, that
should be enough. But flags or comma-separated input wasn't what I was
going for. Successive input prompts didn't seem quite right either.

I ended up with a "form" made out of links to input URLs. The data is
collected in a temp file named with a random session ID, and there's a
final "submit" link that updates the generated guestbook (in true retro CGI
fashion it probably fails horribly when two people submit at once).

This works, but like I said, kinda in the weeds. Is there a better way to
get multiple inputs that I missed?

The other problem I ran into is that dynamic responses were cached in my
client. In my case, the user would submit the form and be presented with an
error page. They'd fix the error and resubmit only to get the same error
again because of the client cache.

I worked around that by making sure each generated link is unique (by a
counter). Conditional GET behavior is probably too complicated, but it
would be nice if there were a "Pragma: no-cache" type flag on dynamic pages.

Anyway, am I making this harder than it needs to be? Am I just trying to do
something that shouldn't be done on Gemini?

Cheers,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200717/c6a609a0/attachment.htm>

From cage-dev at twistfold.it  Fri Jul 17 16:25:00 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 17 Jul 2020 17:25:00 +0200
Subject: question about links parsing
Message-ID: <20200717152500.GA8555@kurosawa.casa.net>

Hi!

I have found a page with a link written this way

=><whitespace><URL><whitespace><linebreak>

that is, a withespace without the link name following.

How a  parser should interpret  this links?  Is this a  malformed link
according to specs?

My choice was to parse as it was:

=><whitespace><URL><linebreak>

like it had no withespace (and no  link label) after the URI, i wonder
if is  this OK, or  should i interpret this  block of text  like plain
text.

Bye!
C.

From cage-dev at twistfold.it  Fri Jul 17 16:18:13 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 17 Jul 2020 17:18:13 +0200
Subject: [ANN] tinmop 0.1.3
Message-ID: <20200717151813.GA7927@kurosawa.casa.net>

Hi!

A  new version  of  tinmop: a  pleroma  and gemini  client  with a  TUI
interface has been released.

This version  (0.1.3) improves and  fix rendering of gemini  pages and
allow to render the source of a page instead of the rendered version.

https://www.autistici.org/interzona/tinmop.html

Bye!
C.

From colecmac at protonmail.com  Fri Jul 17 16:26:08 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 17 Jul 2020 15:26:08 +0000
Subject: Does a cert need a Common Name matching the domain?
In-Reply-To: <71e41cee98d7ecca13ce2febe9e3baf884fdc1e6.camel@gnu.org>
References: <87v9imy4cs.fsf@riseup.net> <5F115D37.6030600@marmaladefoo.com>
 <87365qzh5v.fsf@riseup.net>
 <71e41cee98d7ecca13ce2febe9e3baf884fdc1e6.camel@gnu.org>
Message-ID: <ay4Wft-DR2S0AJHsnj44SaW97ojXp_nwKnh1yNSERMBx1PyrAk8PsQEt7wYkt5OurTttoo7WPYD8RG42lPbAMA5io6SOeOkEPnsOUJrPO3w=@protonmail.com>

On the surface I think you're right, that in the TOFU world,
CN shouldn't matter, and neither should subjectAltName, etc.
We shouldn't even need wildcard certs, because anything should be
accepted.

However, I hope someone more knowledgeable can chime in, maybe
there's an issue I'm not considering.


makeworld

??????? Original Message ???????
On Friday, July 17, 2020 5:09 AM, Alex Schroeder <alex at gnu.org> wrote:

> Luke Emmet writes:
>
> > > I'm getting "failed to connect to the server: hostname does not
> > > verify: x509: certificate is valid for celulinde, not
> > > caranatar.xyz"
>
> On Fri, 2020-07-17 at 04:20 -0400, Caranatar wrote:
>
> > Ah crap apparently none of the clients I was using to test were
> > actually
> > verifying the certificate, and I forgot to change the CN when I
> > copy/pasted my cert generation command from my laptop. It should be
> > working now...
>
> What do other people think about this? My personal impression was that
> in a trust on first use (TOFU) world, the common name (CN) of a
> certificate could be anything. It could be "Alex Schroeder", for
> example. Or it could be "alexschroeder.ch". Even if it was served as
> the certificate for another domain, like transjovian.org. After all,
> the question is only whether you "trust on first use".
>
> My impression is that a client that tries to verify that CN and domain
> match is doing it wrong. What do you think? Sadly, my SSL know-how is
> weak, so any pointers to how things ought to work in a TOFU world are
> appreciated.
>
> Cheers
> Alex



From colecmac at protonmail.com  Fri Jul 17 16:30:47 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 17 Jul 2020 15:30:47 +0000
Subject: Co-serving a static site over Gemini
In-Reply-To: <cbf108be4558dfb13d1968017d949188@riseup.net>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
Message-ID: <4BqXNtbiSZrHdcM06JrNiHRwdB9atrF1EdWUAf2PKesn4eD6OrbtdVS9v-LpN5BhC8TZyOqyTOSFheYhBVH25GiCrR3g59znlPdxionlJRw=@protonmail.com>

> ps: I haven't looked too deeply to see if there's an existing solution,
> because I want an excuse to learn async Rust :)

An admirable goal :)
I've written a markdown to gemini converter in Python though, if that's
helpful/useful.

https://github.com/makeworld-the-better-one/md2gemini

I've been thinking about setting up a demo server that converts
markdown to gemini on the fly using it, might be interesting. Although
I didn't really write it with performance in mind, so I'd have to see
how it plays out for longer documents.

Cheers,
makeworld

From colecmac at protonmail.com  Fri Jul 17 16:35:15 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 17 Jul 2020 15:35:15 +0000
Subject: CGI
In-Reply-To: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
Message-ID: <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>

One way to do it would be to have multiple inputs in a row,
and store the results in a temp file based on IP address. It
still fails if multiple people from the say IP address submit,
but that's much rarer.

makeworld

From hello at matthewgraybosch.com  Fri Jul 17 16:45:28 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 17 Jul 2020 11:45:28 -0400
Subject: question about links parsing
In-Reply-To: <20200717152500.GA8555@kurosawa.casa.net>
References: <20200717152500.GA8555@kurosawa.casa.net>
Message-ID: <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>

On Fri, 17 Jul 2020 17:25:00 +0200
cage <cage-dev at twistfold.it> wrote:

> Hi!
> 
> I have found a page with a link written this way
> 
> =><whitespace><URL><whitespace><linebreak>
> 
> that is, a withespace without the link name following.

My understanding of the spec is that the link name is optional. Without
it, the link would just be a bare URL.

But please don't take that as gospel; I could be wrong. :)

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>		gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From boyd.paul2 at gmail.com  Fri Jul 17 16:59:46 2020
From: boyd.paul2 at gmail.com (Paul Boyd)
Date: Fri, 17 Jul 2020 11:59:46 -0400
Subject: CGI
In-Reply-To: <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
Message-ID: <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>

That's a good idea. It would probably work fine for this particular case.
Though I'd worry about it for anything more complicated. But I guess that
could be solved by client-side certs.

As an aside, I had a co-worker who made a web game once and added IP-based
rate limiting. The only trouble was that the only people who played his
game were his co-workers who mostly played from the office network, totally
triggering his rate limit.

On Fri, Jul 17, 2020 at 11:35 AM <colecmac at protonmail.com> wrote:

> One way to do it would be to have multiple inputs in a row,
> and store the results in a temp file based on IP address. It
> still fails if multiple people from the say IP address submit,
> but that's much rarer.
>
> makeworld
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200717/f6f35f97/attachment.htm>

From cage-dev at twistfold.it  Fri Jul 17 17:49:07 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 17 Jul 2020 18:49:07 +0200
Subject: question about links parsing
In-Reply-To: <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>
References: <20200717152500.GA8555@kurosawa.casa.net>
 <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>
Message-ID: <20200717164907.GA10480@kurosawa.casa.net>

On Fri, Jul 17, 2020 at 11:45:28AM -0400, Matthew Graybosch wrote:

Hello!

Thank you for your reply!

> On Fri, 17 Jul 2020 17:25:00 +0200
> cage <cage-dev at twistfold.it> wrote:
>
> > Hi!
> >
> > I have found a page with a link written this way
> >
> > =><whitespace><URL><whitespace><linebreak>
> >
> > that is, a withespace without the link name following.
>
> My understanding of the spec is that the link name is optional. Without
> it, the link would just be a bare URL.
>
> But please don't take that as gospel; I could be wrong. :)

No problem! We are just discussing :)

I think  what you  wrote is  entirely reasonable  (in fact  i actually
modified  my  parser to  act  as  you said)  but  then  i checked  the
documentations and the specs for links is written as:

=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]

So *if*  i understand correctly (and  i am not  sure i did :-D),  if i
interpret the  square brackets  as "optional terms",  i can  read that
line as: "A link is formed by the symbol '=>' followed by any non-zero
number of  consecutive spaces followed by  the url and followed  by an
optional block formed by non zero space *and* a link name.

So if there is a <whitespace> after <URL> a link name *must* follows.

If each  terms after the url  was optional i expect  the specs was
something like:

=>[<whitespace>]<URL>[<whitespace>][<USER-FRIENDLY LINK NAME>]

but like i am just guessing here,  i am not a linguist, just an humble
self taught programmer :)

Bye!
C.

From lazar.michael22 at gmail.com  Fri Jul 17 18:36:50 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Fri, 17 Jul 2020 13:36:50 -0400
Subject: CGI
In-Reply-To: <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
Message-ID: <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>

I like the form idea and I wrote something similar for gopher a while back [0].

https://gopher.floodgap.com/gopher/gw?=mozz.us+7005+312f64656d6f2d666f726d

In my case, I used URL query parameters to keep track of previously submitted
form values. This worked because query params do not have any special meaning
in gopher URLs. For gemini the query component is reserved, but you could
probably accomplish the same thing using a special path component with the
encoded fields in it.

gemini://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/

- mozz

[0] https://github.com/michael-lazar/flask-gopher/blob/master/demo/run_server.py#L154

From ext0l at riseup.net  Fri Jul 17 19:00:20 2020
From: ext0l at riseup.net (ext0l at riseup.net)
Date: Fri, 17 Jul 2020 11:00:20 -0700
Subject: Co-serving a static site over Gemini
In-Reply-To: <4BqXNtbiSZrHdcM06JrNiHRwdB9atrF1EdWUAf2PKesn4eD6OrbtdVS9v-LpN5BhC8TZyOqyTOSFheYhBVH25GiCrR3g59znlPdxionlJRw=@protonmail.com>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
 <4BqXNtbiSZrHdcM06JrNiHRwdB9atrF1EdWUAf2PKesn4eD6OrbtdVS9v-LpN5BhC8TZyOqyTOSFheYhBVH25GiCrR3g59znlPdxionlJRw=@protonmail.com>
Message-ID: <71e6022ace7eab07b6d96e3035b88526@riseup.net>

On 2020-07-17 08:30, colecmac at protonmail.com wrote:
>> ps: I haven't looked too deeply to see if there's an existing solution,
>> because I want an excuse to learn async Rust :)
> 
> An admirable goal :)
> I've written a markdown to gemini converter in Python though, if that's
> helpful/useful.
> 
> https://github.com/makeworld-the-better-one/md2gemini
> 
> I've been thinking about setting up a demo server that converts
> markdown to gemini on the fly using it, might be interesting. Although
> I didn't really write it with performance in mind, so I'd have to see
> how it plays out for longer documents.
> 
> Cheers,
> makeworld

Yeah, I came across that and it works great! I just felt like trying to
write my own thing in Rust because it's fun, though I'm cribbing your
paragraph link mode for Exarch.

(One of my other project ideas was a fancy terminal-interface client
with color support, and then I found amfora... so instead I just
packaged it for NixOS and decided to write Exarch instead.)

From boyd.paul2 at gmail.com  Fri Jul 17 19:26:58 2020
From: boyd.paul2 at gmail.com (Paul Boyd)
Date: Fri, 17 Jul 2020 14:26:58 -0400
Subject: CGI
In-Reply-To: <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
 <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
Message-ID: <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>

Hmm.. interesting. I'm already packing data into the URL path, so yeah, I
can just put the rest of the data in there. I'll have to try it out when I
get a minute.

The protocol spec has a max URL size of 1024 bytes, but as long as the
inputs are short I think it will work.

Paul

On Fri, Jul 17, 2020 at 1:37 PM Michael Lazar <lazar.michael22 at gmail.com>
wrote:

> I like the form idea and I wrote something similar for gopher a while back
> [0].
>
> https://gopher.floodgap.com/gopher/gw?=mozz.us+7005+312f64656d6f2d666f726d
>
> In my case, I used URL query parameters to keep track of previously
> submitted
> form values. This worked because query params do not have any special
> meaning
> in gopher URLs. For gemini the query component is reserved, but you could
> probably accomplish the same thing using a special path component with the
> encoded fields in it.
>
> gemini://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/
>
> - mozz
>
> [0]
> https://github.com/michael-lazar/flask-gopher/blob/master/demo/run_server.py#L154
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200717/513ad82b/attachment.htm>

From luke at marmaladefoo.com  Fri Jul 17 19:59:03 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 17 Jul 2020 19:59:03 +0100
Subject: CGI
In-Reply-To: <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
 <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
 <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>
Message-ID: <5F11F4F7.60108@marmaladefoo.com>

A word of warning - as you probably have surmised, query string or 
otherwise manipulated URLs are not good for all types of application. 
They work just like HTTP GET queries and as such should really be 
limited to idempotent interactions with the server (like search queries 
or other peristent URLs).

There is nothing yet equivalent to a non-cacheable data submission to 
the server (like HTTP POST) yet. I think it would be great if there 
could be one, but nothing on the horizon at the moment.

So the complex URLs you can assemble in interactions with Gemini are 
subject to being linked to and replayed.

For example if I have a page on my site with 100 parametrised links to a 
gemini based guest book, every time GUS comes to visit, there could end 
up being 100 new entries posted!

Best wishes

  - Luke

On 17-Jul-2020 19:26, Paul Boyd wrote:
> Hmm.. interesting. I'm already packing data into the URL path, so 
> yeah, I can just put the rest of the data in there. I'll have to try 
> it out when I get a minute.
>
> The protocol spec has a max URL size of 1024 bytes, but as long as the 
> inputs are short I think it will work.
>
> Paul
>
> On Fri, Jul 17, 2020 at 1:37 PM Michael Lazar 
> <lazar.michael22 at gmail.com <mailto:lazar.michael22 at gmail.com>> wrote:
>
>     I like the form idea and I wrote something similar for gopher a
>     while back [0].
>
>     https://gopher.floodgap.com/gopher/gw?=mozz.us+7005+312f64656d6f2d666f726d
>
>     In my case, I used URL query parameters to keep track of
>     previously submitted
>     form values. This worked because query params do not have any
>     special meaning
>     in gopher URLs. For gemini the query component is reserved, but
>     you could
>     probably accomplish the same thing using a special path component
>     with the
>     encoded fields in it.
>
>     gemini://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/
>     <http://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/>
>
>     - mozz
>
>     [0]
>     https://github.com/michael-lazar/flask-gopher/blob/master/demo/run_server.py#L154
>

From kooda at upyum.com  Fri Jul 17 20:39:16 2020
From: kooda at upyum.com (kooda at upyum.com)
Date: Fri, 17 Jul 2020 21:39:16 +0200
Subject: New user, spec details
Message-ID: <2L4C8JSU35PLB.36KUIT6ASS810@appa.upyum.com>

Hi!

I?ve been browsing the Gemini space for about a week and so far I love
it! I just fired up my own server and intend to contribute to the content
soon.

I also skimmed the mailing list and there are still a few details of the
spec I would like to discuss:

First, in the overview of the transaction (#1.1), it appears to me that
the client must wait for the server to close the connection before doing
anything with the response. It seems to be an unnecessary constraint,
especially since the text/gemini format is designed to be handled line by
line without needing to store the whole document. It would also enable
rendering of progressive images, playing audio files, etc during the
transfer.

In the same section, as well as #3.3 Response bodies, it is stated that
the server closes the connection after the document is sent. I think it
would be interesting to be a little more precise and state that the server
sends a close_notify from the TLS layer before closing the connection. It
would make it possible for clients to detect a truncated download and warn
the user about it.

I would also like to know the general opinion about TLS session caches. It
could be used as a light tracking tool? but I don?t think it?s that
bad. IP address and requests timing can also be used in the same way to
track users on a single server. And if someone really wanted, they could
just serve unique URLs to each visitor to track their movements on their
server.

From hello at matthewgraybosch.com  Fri Jul 17 22:48:28 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 17 Jul 2020 17:48:28 -0400
Subject: New user, spec details
In-Reply-To: <2L4C8JSU35PLB.36KUIT6ASS810@appa.upyum.com>
References: <2L4C8JSU35PLB.36KUIT6ASS810@appa.upyum.com>
Message-ID: <20200717174828.681b6ff3f1d3e7278c320611@matthewgraybosch.com>

On Fri, 17 Jul 2020 21:39:16 +0200
kooda at upyum.com wrote:

> It seems to be an unnecessary constraint, especially since the
> text/gemini format is designed to be handled line by line without
> needing to store the whole document. 

It might make more sense if you thought of a gemini document as an
atomic object. Accessing a Gemini document is a four step process:

1. Connect
2. Download
3. Disconnect
4. Render

> It would also enable rendering of progressive images,
> playing audio files, etc during the transfer.

If I cared about rendering images inline, streaming audio, etc. I would
stick to the HTML/CSS/JS web stack. Gemini is mainly text-oriented,
remember?

> It could be used as a light tracking tool? but I don?t think
> it?s that bad. 

I disagree with you. Tracking is too easily abused, as we've seen with
the WWW over the last twenty-five years or so.

> IP address and requests timing can also be used in the
> same way to track users on a single server. And if someone really
> wanted, they could just serve unique URLs to each visitor to track
> their movements on their server.

If I want the WWW, I know where to find it.

I participate in geminispace to get away from the downsides of the WWW,
and that includes the ability to track people as they visit sites and
pages.

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>		gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From luna at owlsne.st  Sat Jul 18 05:33:15 2020
From: luna at owlsne.st (luna)
Date: Sat, 18 Jul 2020 00:33:15 -0400
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
References: <C47E58M2B3UU.2FOKMT130ZR1O@stilgar>
Message-ID: <fbd7ca3d-20c3-e562-b6b7-55d697f1a6dc@owlsne.st>

Glad to see that you released this! ^^

One suggestion I have is to implement an option to specify a limit for
the serial number's size. Generating a big.Int value that goes below the
threshold of 8 bits, 16 bits, etc. in size can help to save a few bytes.

Another suggestion is to have a confirmation prompt for overwriting
files. This is definitely a small detail, but considering the nature of
what's being generated, it might be worth making sure that a user
doesn't accidentally write over their private key.

Using the same domain name and expiration date, sizes of ed25519 certs
through gemcert seem to be a bit larger compared to what I get from a
certificate generator that I wrote a few days back (424 bytes versus 262
bytes) despite the x509 templates using the same basic values.

~luna

-- Email domain proudly hosted at https://migadu.com


From gmym at coopdot.com  Sat Jul 18 10:18:38 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sat, 18 Jul 2020 11:18:38 +0200
Subject: question about links parsing
In-Reply-To: <20200717164907.GA10480@kurosawa.casa.net>
References: <20200717152500.GA8555@kurosawa.casa.net>
 <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>
 <20200717164907.GA10480@kurosawa.casa.net>
Message-ID: <CAObwWNiVqecCMQQHyFT9oSOb2aSWcghSekcCj08ttHBNfcvzaA@mail.gmail.com>

cage <cage-dev at twistfold.it> wrote:

> On Fri, Jul 17, 2020 at 11:45:28AM -0400, Matthew Graybosch wrote:
> If each  terms after the url  was optional i expect  the specs was
> something like:
>
> =>[<whitespace>]<URL>[<whitespace>][<USER-FRIENDLY LINK NAME>]
>

That one makes the whitespace separator between <URL> and <USER-FRIENDLY
LINK NAME> optional, making it hard to parse.

This is what you were looking for:

=>[<whitespace>]<URL>[<whitespace>[<USER-FRIENDLY LINK NAME>]]

However, I think it's reasonable to assume the ending whitespace was
unintentional and ignore it.

Postel's law:

    Be conservative in what you do, be liberal in what you accept from
others

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200718/22cd3695/attachment.htm>

From petite.abeille at gmail.com  Sat Jul 18 10:37:30 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 18 Jul 2020 11:37:30 +0200
Subject: New user, spec details
In-Reply-To: <20200717174828.681b6ff3f1d3e7278c320611@matthewgraybosch.com>
References: <2L4C8JSU35PLB.36KUIT6ASS810@appa.upyum.com>
 <20200717174828.681b6ff3f1d3e7278c320611@matthewgraybosch.com>
Message-ID: <68D44E7D-899F-4B44-A806-BF444733E7F7@gmail.com>



> On Jul 17, 2020, at 23:48, Matthew Graybosch <hello at matthewgraybosch.com> wrote:
> 
> 1. Connect
> 2. Download
> 3. Disconnect
> 4. Render

More simply, when appropriate:

1. Connect
2. Render
3. Disconnect



From cage-dev at twistfold.it  Sat Jul 18 13:28:21 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 18 Jul 2020 14:28:21 +0200
Subject: question about links parsing
In-Reply-To: <CAObwWNiVqecCMQQHyFT9oSOb2aSWcghSekcCj08ttHBNfcvzaA@mail.gmail.com>
References: <20200717152500.GA8555@kurosawa.casa.net>
 <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>
 <20200717164907.GA10480@kurosawa.casa.net>
 <CAObwWNiVqecCMQQHyFT9oSOb2aSWcghSekcCj08ttHBNfcvzaA@mail.gmail.com>
Message-ID: <20200718122821.GA10695@kurosawa.casa.net>

On Sat, Jul 18, 2020 at 11:18:38AM +0200, Katarina Eriksson wrote:

Hi!

> cage <cage-dev at twistfold.it> wrote:
> > If each  terms after the url  was optional i expect  the specs was
> > something like:
> >
> > =>[<whitespace>]<URL>[<whitespace>][<USER-FRIENDLY LINK NAME>]
> >
>
> That one makes the whitespace separator between <URL> and <USER-FRIENDLY
> LINK NAME> optional, making it hard to parse.
>
> This is what you were looking for:
>
> =>[<whitespace>]<URL>[<whitespace>[<USER-FRIENDLY LINK NAME>]]

Yes i was wrong! Thank you for correcting what i wrote. :)

> However, I think it's reasonable to assume the ending whitespace was
> unintentional and ignore it.
>
> Postel's law:
>
>     Be conservative in what you do, be liberal in what you accept from
> others

I was not able to remember the name of this law, thank you!

What disturbs me is that now my parser does not follow the grammar the
specs describe  anymore; but this is  just some personal thing  that i
have to accept someway, i guess! :)

Bye!
C.

From defdefred at protonmail.com  Sat Jul 18 14:14:07 2020
From: defdefred at protonmail.com (defdefred)
Date: Sat, 18 Jul 2020 13:14:07 +0000
Subject: New user, spec details
In-Reply-To: <2L4C8JSU35PLB.36KUIT6ASS810@appa.upyum.com>
References: <2L4C8JSU35PLB.36KUIT6ASS810@appa.upyum.com>
Message-ID: <AgPAWaK8HYeoIaD6jmS-gsLBEMKRYzokMzls9xsfwrTa2yC5QquuwiCQu9XjGIpFNMZXjuifZpGT5Mo4zU53lmCSK21F_BsUvBsgT6vwguk=@protonmail.com>

??????? Original Message ???????
On Friday 17 July 2020 21:39, <kooda at upyum.com> wrote:
> the client must wait for the server to close the connection before doing
> anything with the response. It seems to be an unnecessary constraint,
> especially since the text/gemini format is designed to be handled line by
> line without needing to store the whole document. It would also enable
> rendering of progressive images, playing audio files, etc during the
> transfer.

Agreed.
It will be usefull when gemini documents will be more then >1KB

The important thing is one document per connection, no automatic downloading.

FreD.

From boyd.paul2 at gmail.com  Sat Jul 18 14:46:42 2020
From: boyd.paul2 at gmail.com (Paul Boyd)
Date: Sat, 18 Jul 2020 09:46:42 -0400
Subject: CGI
In-Reply-To: <5F11F4F7.60108@marmaladefoo.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
 <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
 <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>
 <5F11F4F7.60108@marmaladefoo.com>
Message-ID: <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>

I put all the collected data in the URL. It works pretty well and got rid
of the temp files. It event fixed the cache problem since each generated
URL is unique to the data submitted. But it generates some nasty URLs (see
the bottom).

Luke, good points about the ability to replay a post. Temporary session
files didn't have that problem at least. I suppose I could bring back a
session ID just to counter replays, but I'll wait until it becomes a
problem.

Anyway, I'm probably not going to write something like this again. The
guestbook is kind of fun (Hello K?vin and Timur!), so I'll leave it up. But
I'll stick to things that fit better in the future.

Case in point about replays, here's an ugly URL to a pre-filled form:

gemini://
pboyd.io/cgi-bin/guestbook.pl/link/S2luZyBBcnRodXI=;Q2FtZWxvdA==;VGhlIExhZHkgb2YgdGhlIExha2UsIGhlciBhcm0gY2xhZCBpbiB0aGUgcHVyZXN0LCBzaGltbWVyaW5nIHNhbWl0ZSwgaGVsZCBhbG9mdCBFeGNhbGlidXIgZnJvbSB0aGUgYm9zb20gb2YgdGhlIHdhdGVyIHNpZ25pZnlpbmcgYnkgRGl2aW5lIFByb3ZpZGVuY2UgdGhhdCBJLCBBcnRodXIsIHdhcyB0byBjYXJyeSBFeGNhbGlidXIuIFRoYXQgaXMgd2h5IEkgYW0geW91ciBraW5nIQ==;?none

Paul

On Fri, Jul 17, 2020 at 2:59 PM Luke Emmet <luke at marmaladefoo.com> wrote:

> A word of warning - as you probably have surmised, query string or
> otherwise manipulated URLs are not good for all types of application.
> They work just like HTTP GET queries and as such should really be
> limited to idempotent interactions with the server (like search queries
> or other peristent URLs).
>
> There is nothing yet equivalent to a non-cacheable data submission to
> the server (like HTTP POST) yet. I think it would be great if there
> could be one, but nothing on the horizon at the moment.
>
> So the complex URLs you can assemble in interactions with Gemini are
> subject to being linked to and replayed.
>
> For example if I have a page on my site with 100 parametrised links to a
> gemini based guest book, every time GUS comes to visit, there could end
> up being 100 new entries posted!
>
> Best wishes
>
>   - Luke
>
> On 17-Jul-2020 19:26, Paul Boyd wrote:
> > Hmm.. interesting. I'm already packing data into the URL path, so
> > yeah, I can just put the rest of the data in there. I'll have to try
> > it out when I get a minute.
> >
> > The protocol spec has a max URL size of 1024 bytes, but as long as the
> > inputs are short I think it will work.
> >
> > Paul
> >
> > On Fri, Jul 17, 2020 at 1:37 PM Michael Lazar
> > <lazar.michael22 at gmail.com <mailto:lazar.michael22 at gmail.com>> wrote:
> >
> >     I like the form idea and I wrote something similar for gopher a
> >     while back [0].
> >
> >
> https://gopher.floodgap.com/gopher/gw?=mozz.us+7005+312f64656d6f2d666f726d
> >
> >     In my case, I used URL query parameters to keep track of
> >     previously submitted
> >     form values. This worked because query params do not have any
> >     special meaning
> >     in gopher URLs. For gemini the query component is reserved, but
> >     you could
> >     probably accomplish the same thing using a special path component
> >     with the
> >     encoded fields in it.
> >
> >     gemini://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/
> >     <http://example.com/cgi-bin/form/name%3Dpaul%26location%3Dcanada/>
> >
> >     - mozz
> >
> >     [0]
> >
> https://github.com/michael-lazar/flask-gopher/blob/master/demo/run_server.py#L154
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200718/9399e640/attachment.htm>

From petite.abeille at gmail.com  Sat Jul 18 14:51:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 18 Jul 2020 15:51:12 +0200
Subject: CGI
In-Reply-To: <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
 <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
 <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>
 <5F11F4F7.60108@marmaladefoo.com>
 <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>
Message-ID: <61B9999A-C0F1-4ED9-A070-F46190CAF2EA@gmail.com>



> On Jul 18, 2020, at 15:46, Paul Boyd <boyd.paul2 at gmail.com> wrote:
> 
> I put all the collected data in the URL. It works pretty well and got rid of the temp files. It event fixed the cache problem since each generated URL is unique to the data submitted. But it generates some nasty URLs (see the bottom).

Ugly indeed.

Also, keep in mind that URLs are limited to 1024 bytes in Gemini.


From ext0l at riseup.net  Sat Jul 18 20:20:20 2020
From: ext0l at riseup.net (Ash)
Date: Sat, 18 Jul 2020 12:20:20 -0700
Subject: question about links parsing
In-Reply-To: <CAObwWNiVqecCMQQHyFT9oSOb2aSWcghSekcCj08ttHBNfcvzaA@mail.gmail.com>
References: <20200717152500.GA8555@kurosawa.casa.net>
 <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>
 <20200717164907.GA10480@kurosawa.casa.net>
 <CAObwWNiVqecCMQQHyFT9oSOb2aSWcghSekcCj08ttHBNfcvzaA@mail.gmail.com>
Message-ID: <2d6b4a27-5e6a-e9ad-b019-8c0542cf2b9d@riseup.net>

On 7/18/20 2:18 AM, Katarina Eriksson wrote:
> cage <cage-dev at twistfold.it <mailto:cage-dev at twistfold.it>> wrote:
> 
>     On Fri, Jul 17, 2020 at 11:45:28AM -0400, Matthew Graybosch wrote:
>     If each? terms after the url? was optional i expect? the specs was
>     something like:
> 
>     =>[<whitespace>]<URL>[<whitespace>][<USER-FRIENDLY LINK NAME>]
> 
> 
> That one makes the whitespace separator between <URL> and <USER-FRIENDLY 
> LINK NAME> optional, making it hard to parse.
> 
> This is what you were looking for:
> 
> =>[<whitespace>]<URL>[<whitespace>[<USER-FRIENDLY LINK NAME>]]
> 
> However, I think it's reasonable to assume the ending whitespace was 
> unintentional and ignore it.
> 
> Postel's law:
> 
>  ? ? Be conservative in what you do, be liberal in what you accept from 
> others
> 
> -- 
> Katarina
> 

For what it's worth, I think one should be careful in applying Postel's 
law, since it can encourage drift from the spec: if everyone else 
accepts messages that are misformatted in a particular way, then new 
implementations need to do so as well.

That being said, I think this case is simple enough that I would 100% 
support parsers tolerating the trailing whitespace, and even support 
changing the spec in the way you described.

From caranatar at riseup.net  Sat Jul 18 21:23:48 2020
From: caranatar at riseup.net (Caranatar)
Date: Sat, 18 Jul 2020 16:23:48 -0400
Subject: question about links parsing
In-Reply-To: <2d6b4a27-5e6a-e9ad-b019-8c0542cf2b9d@riseup.net>
References: <20200717152500.GA8555@kurosawa.casa.net>
 <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>
 <20200717164907.GA10480@kurosawa.casa.net>
 <CAObwWNiVqecCMQQHyFT9oSOb2aSWcghSekcCj08ttHBNfcvzaA@mail.gmail.com>
 <2d6b4a27-5e6a-e9ad-b019-8c0542cf2b9d@riseup.net>
Message-ID: <F7B4EBD7-3E1F-4B88-992C-D24305781EE0@riseup.net>

A possible solution is changing the grammar to be

=>[whitespace]URL[[whitespace][friendly name]][whitespace]

Since whitespace shouldn't parse out as part of the url anyway

On July 18, 2020 3:20:20 PM EDT, Ash <ext0l at riseup.net> wrote:
>On 7/18/20 2:18 AM, Katarina Eriksson wrote:
>> cage <cage-dev at twistfold.it <mailto:cage-dev at twistfold.it>> wrote:
>> 
>>     On Fri, Jul 17, 2020 at 11:45:28AM -0400, Matthew Graybosch
>wrote:
>>     If each? terms after the url? was optional i expect? the specs
>was
>>     something like:
>> 
>>     =>[<whitespace>]<URL>[<whitespace>][<USER-FRIENDLY LINK NAME>]
>> 
>> 
>> That one makes the whitespace separator between <URL> and
><USER-FRIENDLY 
>> LINK NAME> optional, making it hard to parse.
>> 
>> This is what you were looking for:
>> 
>> =>[<whitespace>]<URL>[<whitespace>[<USER-FRIENDLY LINK NAME>]]
>> 
>> However, I think it's reasonable to assume the ending whitespace was 
>> unintentional and ignore it.
>> 
>> Postel's law:
>> 
>>  ? ? Be conservative in what you do, be liberal in what you accept
>from 
>> others
>> 
>> -- 
>> Katarina
>> 
>
>For what it's worth, I think one should be careful in applying Postel's
>
>law, since it can encourage drift from the spec: if everyone else 
>accepts messages that are misformatted in a particular way, then new 
>implementations need to do so as well.
>
>That being said, I think this case is simple enough that I would 100% 
>support parsers tolerating the trailing whitespace, and even support 
>changing the spec in the way you described.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200718/3f667e48/attachment-0001.htm>

From colecmac at protonmail.com  Sat Jul 18 22:09:42 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 18 Jul 2020 21:09:42 +0000
Subject: Reopening: Stream status code
Message-ID: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>

Hello all,

A stream status code has been mentioned on this list before, and I'd like to
bring it up again. Streams have begun appearing on Gemini, notably on
gemini://chat.mozz.us. But at the same time, responsible clients have been
adding timeouts for server responses. It is even part of the Egsam test, under
section 1.1: gemini://egsam.pitr.ca/1.1.gmi.

The best solution that I see, as I believe that streams can be very useful and
interesting, is to add a SUCCESS AS STREAM status code. I propose status code 21.

Thoughts? I know Solderpunk has said that there won't be non-trivial changes to
spec from now on, but I hope he will see this as an important exception.

Thank you,
makeworld



From defdefred at protonmail.com  Sat Jul 18 22:11:26 2020
From: defdefred at protonmail.com (defdefred)
Date: Sat, 18 Jul 2020 21:11:26 +0000
Subject: question about links parsing
In-Reply-To: <2d6b4a27-5e6a-e9ad-b019-8c0542cf2b9d@riseup.net>
References: <20200717152500.GA8555@kurosawa.casa.net>
 <20200717114528.e18c41d3eb2649f5f42bbbbf@matthewgraybosch.com>
 <20200717164907.GA10480@kurosawa.casa.net>
 <CAObwWNiVqecCMQQHyFT9oSOb2aSWcghSekcCj08ttHBNfcvzaA@mail.gmail.com>
 <2d6b4a27-5e6a-e9ad-b019-8c0542cf2b9d@riseup.net>
Message-ID: <OatXdd-jYtzIz3oI2J63O57xNiJePwBI9mwpJMRREtO87uN2ElF3t7_zNLbbfJ331k6JkmIfVyTosx3uF1OfOM7CV4QgCTAZqZP9wm5j0kI=@protonmail.com>

On Saturday, July 18, 2020 9:20 PM, Ash <ext0l at riseup.net> wrote:
> For what it's worth, I think one should be careful in applying Postel's
> law, since it can encourage drift from the spec: if everyone else
> accepts messages that are misformatted in a particular way, then new
> implementations need to do so as well.

It is true that keeping a strict spec, help keeping clean and short code.
If such badly formed link is rare, it should be considered as an error by all gemini client and then rapidly corrected by the author.

freD.

From defdefred at protonmail.com  Sat Jul 18 22:32:17 2020
From: defdefred at protonmail.com (defdefred)
Date: Sat, 18 Jul 2020 21:32:17 +0000
Subject: CGI
In-Reply-To: <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
 <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
 <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>
 <5F11F4F7.60108@marmaladefoo.com>
 <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>
Message-ID: <Px7nObEzpdfCQr7Sd_a7ApHU70GePqv66Yrfz5uF3CvNaZXN71Uhh1YgM4rucH4YBxTCVh0V5RViEvRyyJPhdHoUtiuPvT1QwQjaf9T1gVA=@protonmail.com>

On Saturday, July 18, 2020 3:46 PM, Paul Boyd <boyd.paul2 at gmail.com> wrote:

> I put all the collected data in the URL. It works pretty well and got rid of the temp files. It event fixed the cache problem since each generated URL is unique to the data submitted. But it generates some nasty URLs (see the bottom).

Consequence is heavy url, possibly bigger than the resulting server response.
Session token and server side temporary file is nicer on network usage...

Maybe in the future, the spec could evolve to allow efficient form, managed by the gemini client and submitted to the server without the need of multiple connection.

freD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200718/47bdf7e3/attachment.htm>

From luke at marmaladefoo.com  Sat Jul 18 23:05:21 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 18 Jul 2020 23:05:21 +0100
Subject: Reopening: Stream status code
In-Reply-To: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
Message-ID: <5F137221.70404@marmaladefoo.com>



On 18-Jul-2020 22:09, colecmac at protonmail.com wrote:
> A stream status code has been mentioned on this list before, and I'd like to
> bring it up again. Streams have begun appearing on Gemini, notably on
> gemini://chat.mozz.us. But at the same time, responsible clients have been
> adding timeouts for server responses. It is even part of the Egsam test, under
> section 1.1: gemini://egsam.pitr.ca/1.1.gmi.
>
> The best solution that I see, as I believe that streams can be very useful and
> interesting, is to add a SUCCESS AS STREAM status code. I propose status code 21.
>
> Thoughts? I know Solderpunk has said that there won't be non-trivial changes to
> spec from now on, but I hope he will see this as an important exception.
Hi makeworld and everyone

I would be against this - it would be a radical change from the existing 
spec - section 1.1 says that the server closes the connection. At 
present we have a simple model - client request-> server response and 
close. Would it be an optional status code that some clients accept and 
others reject (in which case it would seem to violate that you can just 
check the first digit of the status).

It would require a considerable change to the connection logic to some 
clients which wait for the content to be finished being delivered before 
rendering.

For my money if we are opening up these kinds of questions there would 
be others that should be considered. I'm on for a wider discussion about 
evolution of the spec, but not just for this matter on its own.

Best wishes

  - Luke

From colecmac at protonmail.com  Sat Jul 18 23:10:40 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 18 Jul 2020 22:10:40 +0000
Subject: Reopening: Stream status code
In-Reply-To: <5F137221.70404@marmaladefoo.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
 <5F137221.70404@marmaladefoo.com>
Message-ID: <wMlX2CBXXumLKJCpUWPOfDQyuw3lluhDiO5_pKNzZy70tsMNrK8gs7ctXOI6gqlLIVQvIOgsfSN42t9o-7l9uAJxoTsqdLxsYhe-TY6hEds=@protonmail.com>

All good points, thanks. I think it would make sense for some clients
to reject this yeah, but that would break things as you mentioned. Hmm.

makeworld


From lazar.michael22 at gmail.com  Sun Jul 19 03:17:01 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sat, 18 Jul 2020 22:17:01 -0400
Subject: Reopening: Stream status code
In-Reply-To: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
Message-ID: <CAFTy05YVc8R=dJiKVBHrQvPd9gLp1xQBUeCbRwQzuUoCiSCL5g@mail.gmail.com>

On Sat, Jul 18, 2020 at 5:09 PM <colecmac at protonmail.com> wrote:
>
> Hello all,
>
> A stream status code has been mentioned on this list before, and I'd like to
> bring it up again. Streams have begun appearing on Gemini, notably on
> gemini://chat.mozz.us. But at the same time, responsible clients have been
> adding timeouts for server responses. It is even part of the Egsam test, under
> section 1.1: gemini://egsam.pitr.ca/1.1.gmi.
>
> The best solution that I see, as I believe that streams can be very useful and
> interesting, is to add a SUCCESS AS STREAM status code. I propose status code 21.
>
> Thoughts? I know Solderpunk has said that there won't be non-trivial changes to
> spec from now on, but I hope he will see this as an important exception.
>
> Thank you,
> makeworld
>

Hi!

I really like the idea of streaming in gemini! I don't know if it will ever see
widespread adoption outside of a few tech demos, but it's fun to play around
with nonetheless. Here are some of my thoughts on adding a separate status
code.

First, I haven't yet heard a justification for why a client should ever force
the connection to timeout. Adding a short timeout on resolving the host and
establishing the connection, sure that makes sense to me. But why force close
the connection once it has already been established? With gemini's single
request/response model, there should be a person sitting in front of the
keyboard waiting for the page to load. Show them the transfer rate in
bytes/second and let *them* make an informed decision of when to give up based
on their own context. Doing anything else is taking away agency from the user,
and for what gain? If I want to sit in front of a loading screen for an hour
(and keepalive packets are still being sent) I should be allowed to.

The above paragraph doesn't apply to automated requests coming from tools like
gemini scrapers. Those will obviously still need some sort of global timeout on
all connections, regardless of whether they are marked as streaming or not. But
I would argue that that problem is better solved with something like robots.txt.

Second, I haven't yet heard a justification for why clients should be forbidden
from handling responses before they have finished downloading. This is more
fundamental than streaming as it is being discussed in this thread. If I
download a 300 MB mp3 file from your gemini capsule, I should be able to
start playing the audio before the whole thing has finished downloading.
Likewise for rendering images or large text files.

I would argue that "handling" a response also includes saving it to the
filesystem, so any gemini client that can stream a large response to a file
instead of holding the whole thing in memory is already doing this.

Third, I will suggest that the distinction between "streaming" and "non-
streaming" is totally meaningless. Hannu recently stood up an ansi art
mirror [0] which hosts small text files and puts a short time delay between
characters to emulate old modems. Is this streaming? The files have a finite
size and download fairly quickly. Even a naive gemini client could download
them, although it might appear slow. If there was no artificial delay, it
certainly wouldn't be considered streaming. But what if the delay was bumped up
to 30 seconds between characters? What if the delay was not deliberate, but
caused by a slow filesystem on the server? Going in the other direction, if my
server hosts a 1 TB image file it might as well be considered an infinite
stream for all practical purposes.

In summary, my feeling is that most of the features that we associate with
streaming are also relevant to all other gemini requests. If a client wants to
support streaming pages like gemini://chat.mozz.us, then they don't need a
status code to make that distinction. There might be some value in a separate
status code to inform dumb clients that they should not even attempt to load
the page. But there's no clear line to draw in the sand between what is
streaming and what isn't. I think this kind of context information is better off
in human-readable descriptions next to links.

- mozz

[0] https://portal.mozz.us/gemini/ansi.hrtk.in/

From me at case.codes  Sun Jul 19 03:53:49 2020
From: me at case.codes (Case Nelson)
Date: Sun, 19 Jul 2020 02:53:49 +0000 (UTC)
Subject: Reopening: Stream status code
In-Reply-To: <CAFTy05YVc8R=dJiKVBHrQvPd9gLp1xQBUeCbRwQzuUoCiSCL5g@mail.gmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
 <CAFTy05YVc8R=dJiKVBHrQvPd9gLp1xQBUeCbRwQzuUoCiSCL5g@mail.gmail.com>
Message-ID: <566ec4bc-0630-4731-835c-c77292db7ccb@case.codes>

Well, the reason I added a timeout to deedum was because some servers don't close the connection, and the client was much easier to write if the connection terminated.

So, first the ability to tell the user that the server was unresponsive vs asking them to wait for things to stream-in seems important, otherwise how long are they supposed to wait? What if the server just hits an infinite loop?

Yet I question the reason behind keeping an open connection. The ability of a client to render progressive docs, images or video is seems orthogonal to a status code that says this connection will not close. Some of the streaming things out there seem very... application-y, and getting away from the app platform that is the web was a major motivator for me to invest in gemini. This feels like comet which was basically ajax which made everything terrible. Just my ptsd though.


From hannu.hartikainen+gemini at gmail.com  Sun Jul 19 10:28:03 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Sun, 19 Jul 2020 12:28:03 +0300
Subject: Pondering interfaces over the Gemini 1x responses (was: CGI)
In-Reply-To: <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
 <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
 <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>
 <5F11F4F7.60108@marmaladefoo.com>
 <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>
Message-ID: <CANmFPe=wF0Lqd29Tu8JQksLBGq7m5SZhSgFpzRvbCLGodfZ07A@mail.gmail.com>

Hi!

On Sat, 18 Jul 2020 at 16:47, Paul Boyd <boyd.paul2 at gmail.com> wrote:
> Anyway, I'm probably not going to write something like this again. The guestbook is kind of fun (Hello K?vin and Timur!), so I'll leave it up. But I'll stick to things that fit better in the future.

I think it's really valuable to *try* all kinds of things and
different approaches to see *what* fits well. IMHO we have only
scratched the surface of what is possible with the Gemini protocol
(and what makes for good UX).

To summarize what has been discussed here:
1. Filling in multiple values is not trivial with the input response type
2. One way is to generate a session id on the server. (This is
stateful, which has some downsides but avoids replay issues.)
3. Another way is to embed all the responses in the URL.

Some ideas that haven't been mentioned:

a. If you include all the fields at once, you could just ask for them
in one request. Eg. "10 name;location;link;comment" which the user is
smart enough to parse and respond with "Hannu;;;This is cool!". Or for
a better UX, make the fields newline-separated (ie. %0A in the URL)
and have multiline-capable input fields in browsers. Note: this is
against a strict interpretation of the spec but hasn't been discussed
AFAIK.

b. Instead of having different links for different fields, you could
ask for the fields in succession (but this only works well for the
session id based approach). Eg. /guestbook/sign responds with "30
/guestbook/sign/aF3d", then /guestbook/sign/aF3d responds with "10
Name", /guestbook/sign/aF3d?Hannu with "10 Location (optional)", then
"10 Link (optional)" and "10 Comment" in sequence, saving each query
string to the server-side session. After the final response either
save the comment or show the responses with a link to save.

I personally think the Gemini protocol (as it currently is) can be as
powerful as the UNIX command line (note: only CLI, not TUI). In fact,
you could serve a remote shell over Gemini. Of course we're all
spoiled by interactive software even in a terminal so Gemini feels
quite limited.

-Hannu

From boyd.paul2 at gmail.com  Sun Jul 19 13:59:21 2020
From: boyd.paul2 at gmail.com (Paul Boyd)
Date: Sun, 19 Jul 2020 08:59:21 -0400
Subject: Pondering interfaces over the Gemini 1x responses (was: CGI)
In-Reply-To: <CANmFPe=wF0Lqd29Tu8JQksLBGq7m5SZhSgFpzRvbCLGodfZ07A@mail.gmail.com>
References: <CABuFWiJhAObKW9hsVqvboC_0Mau3Z2f3ttEAHOPVWObZy3dDiA@mail.gmail.com>
 <wIhvdApaWutVqma_qKcjTrT-yJQ5M2jBIeGbcVYLDyNjR1URhK5b93vTjU0XeSr_iK2Be_Nsqv1fuG2ymQTOrh_O8gDOALsj54RPA4cNHH0=@protonmail.com>
 <CABuFWi+S1guMFn8mekTf+U6pw+=4t3_OKQTWocsSYZ_TWFg8qA@mail.gmail.com>
 <CAFTy05Zrcph+WRQ+vhCmcYJVUmsGZD-HZsqdCpjKJZNpa0E=2A@mail.gmail.com>
 <CABuFWi+VYQCBz7XCUMBneWYDN4z0ktkboicUNv1YkWrLoXicBw@mail.gmail.com>
 <5F11F4F7.60108@marmaladefoo.com>
 <CABuFWiLemWc+rj=dJpa+6jDe1z+-BVjxW01STS0PjPjc7qy6vw@mail.gmail.com>
 <CANmFPe=wF0Lqd29Tu8JQksLBGq7m5SZhSgFpzRvbCLGodfZ07A@mail.gmail.com>
Message-ID: <CABuFWiJYP0KBBgOZ14ucfv9EMB8kyh00BxchRaqFV_Une23xvQ@mail.gmail.com>

I did consider a succession of inputs. I think we can all agree that a
succession of modal inputs is irritating, and the UI would be exactly that
on most clients.

Asking the user to use a separator seemed error prone, so I didn't want to
do that either. I know it can work. makeworld's gemlikes has a prompt of:

> Enter your username, a space, and your comment

Usernames don't have spaces, and comments do, so this works great here. I'm
just not sure people are going to get "name;location;link;comment" right
consistently. I certainly wouldn't, I'd end up with "paul;;my comment"
instead of "paul;;;my comment" and get my comment in the link field.

Your UNIX command-line comment is interesting. One set of input args is
enough for UNIX, so maybe getopt style flags?

--name John --location "From Beyond" --comment "This is what I have to say"

A form still seems right for a guestbook (the real-life version is a form
after all). But there ought to be something interesting we can do with
flags on the input line. Maybe an ASCII art drawing program? With inputs
like "line --from 0,0 --to 10,10".

Paul

On Sun, Jul 19, 2020 at 5:28 AM Hannu Hartikainen <
hannu.hartikainen+gemini at gmail.com> wrote:

> Hi!
>
> On Sat, 18 Jul 2020 at 16:47, Paul Boyd <boyd.paul2 at gmail.com> wrote:
> > Anyway, I'm probably not going to write something like this again. The
> guestbook is kind of fun (Hello K?vin and Timur!), so I'll leave it up. But
> I'll stick to things that fit better in the future.
>
> I think it's really valuable to *try* all kinds of things and
> different approaches to see *what* fits well. IMHO we have only
> scratched the surface of what is possible with the Gemini protocol
> (and what makes for good UX).
>
> To summarize what has been discussed here:
> 1. Filling in multiple values is not trivial with the input response type
> 2. One way is to generate a session id on the server. (This is
> stateful, which has some downsides but avoids replay issues.)
> 3. Another way is to embed all the responses in the URL.
>
> Some ideas that haven't been mentioned:
>
> a. If you include all the fields at once, you could just ask for them
> in one request. Eg. "10 name;location;link;comment" which the user is
> smart enough to parse and respond with "Hannu;;;This is cool!". Or for
> a better UX, make the fields newline-separated (ie. %0A in the URL)
> and have multiline-capable input fields in browsers. Note: this is
> against a strict interpretation of the spec but hasn't been discussed
> AFAIK.
>
> b. Instead of having different links for different fields, you could
> ask for the fields in succession (but this only works well for the
> session id based approach). Eg. /guestbook/sign responds with "30
> /guestbook/sign/aF3d", then /guestbook/sign/aF3d responds with "10
> Name", /guestbook/sign/aF3d?Hannu with "10 Location (optional)", then
> "10 Link (optional)" and "10 Comment" in sequence, saving each query
> string to the server-side session. After the final response either
> save the comment or show the responses with a link to save.
>
> I personally think the Gemini protocol (as it currently is) can be as
> powerful as the UNIX command line (note: only CLI, not TUI). In fact,
> you could serve a remote shell over Gemini. Of course we're all
> spoiled by interactive software even in a terminal so Gemini feels
> quite limited.
>
> -Hannu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200719/840f7d8a/attachment.htm>

From solderpunk at posteo.net  Sun Jul 19 14:43:09 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 15:43:09 +0200
Subject: Question About Link Format
In-Reply-To: <3ad74bd4-e1c4-235f-65c3-1484e4109ba6@systemli.org>
Message-ID: <C4AN7YU1104A.259GCLBCZSI13@stilgar>

On Fri Jul 17, 2020 at 11:21 AM CEST, Ben wrote:
> Hello guys, I am not normally one to get involved in the Gemini spec. I
> got into a discussion with Martin about how UTF-8 characters are
> supposed to be handled in links in Gemini documents.
>
> On my site I have a link in a document like this:
>
> => logarion/ta?ikio--lando-montara.gmi Ta?ikio: Lando Montara
>
> This refers locally to the actual file name on the disk. The main
> question is, is this allowed in Gemini documents? I thought this should
> work because I believe that Gemini is UTF-8 native or by default, and my
> Unix file system (in this case FreeBSD UFS) appears to be in agreement.

Aaah, I figured we were going to have to deal with this sooner or later.
This has been one of those few remaining unpleasant details in the back
of my mind that I know needs to get sorted out.  It's because of the
existence of things like this that I'm so averse to adding anything new
to the spec - it runs the risk of introducing more things like this,
which aren't obvious at first but then come up only after a few months
of use.

The spec currently uses language like "UTF-8 encoded absolute URL" which
I have to admit has been there since the very earliest version and which
I wrote without any kind of deeper awareness of how this intersected
with existing RFCs.  I've since come to realise that it's very possible
that this language is potentially ambiguous at best, and contradictory
at worse.

I suspect this is going to need a bit of reading and thinking to come up
with a clear stance on and to make appropriate changes on the spec...

> It does seem a proper URI should best contain %C4%9D in place of ?, but
> the question is whether I should change it in the document? Does the
> internal linking (in my case the link is local/relative) even count as a
> URI?

It definitely counts as a relative URI.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Jul 19 14:52:23 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 15:52:23 +0200
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <20200715205343.GA1090@commie.my.domain>
Message-ID: <C4ANF1CGWIXR.1PHPL7X4XN90P@stilgar>

On Wed Jul 15, 2020 at 10:53 PM CEST, lel wrote:

> For context, it's this way because solderpunk is using the go `flag`
> package,
> which doesn't support GNU flags. Writing it that way would require
> pulling in
> some external dependency, and probably doing some rewrites of the CLI
> flag
> parsing.

Precisely.  I would also actually prefer e.g. --domain if I had my
choice, but it's hardly important enough to be worth the effort of
duplicating standard library functionality.  Sorry.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Jul 19 14:54:13 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 15:54:13 +0200
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <CANmFPemfSkn_49YOqrribcNLandAV3BAiY6Li0Tvs8YpLA=Xbg@mail.gmail.com>
Message-ID: <C4ANGFW41W5P.14CYEB7NJF92E@stilgar>

On Wed Jul 15, 2020 at 10:33 PM CEST, Hannu Hartikainen wrote:

> I'd also like if the generated filenames contained the domain name. Nice
> for vhost configurations.

That's a good idea, thanks, I will implement that, hopefully soon.

I have been wondering how best to name client certificate files.  Using
the user-provided CN is no good because people may re-use the same
username across multiple applications.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Jul 19 14:56:08 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 15:56:08 +0200
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <WPDUe2RS1JvK6VPFMii70LvSumrRQ_FacZstx0P1BryhMxlp6zISkkLVmQV1GkRtzBQ4H3zS4f389Y84-cWfEAGE2pgPXpcU6jTxQp5idsI=@protonmail.com>
Message-ID: <C4ANHWVIXE7A.VTYB6UWWMLWG@stilgar>

On Wed Jul 15, 2020 at 8:13 PM CEST,  wrote:

> Also, could you add a go.mod and go.sum file to your repo. You can
> easily
> make one with `go mod init`, just make sure the path in go.mod is
> correct.
> That would allow using go get on the repo.

Thanks for the pointers, I will look into this.  I'm still relatively
green at Go, especially all the packaging infrastructure stuff.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Jul 19 14:57:34 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 15:57:34 +0200
Subject: Does a cert need a Common Name matching the domain?
In-Reply-To: <ay4Wft-DR2S0AJHsnj44SaW97ojXp_nwKnh1yNSERMBx1PyrAk8PsQEt7wYkt5OurTttoo7WPYD8RG42lPbAMA5io6SOeOkEPnsOUJrPO3w=@protonmail.com>
Message-ID: <C4ANJ07KIGVB.PYCXWAK6SZIT@stilgar>

On Fri Jul 17, 2020 at 5:26 PM CEST,  wrote:
> On the surface I think you're right, that in the TOFU world,
> CN shouldn't matter, and neither should subjectAltName, etc.
> We shouldn't even need wildcard certs, because anything should be
> accepted.

There's some degree of sense in this, if the certificate is self-signed
then none of the metadata attached to it is trustworthy in any sense,
and anybody can make a cert with whichever domain(s) they like in the
CN/SAN fields, so one could argue it should be ignored.

I still wonder, though, if it doesn't make sense to check the domain
names and expect them to match (AV-98 does this, for what it's worth),
mostly just to help guard against configuration errors and things like
that?

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Jul 19 15:01:51 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 16:01:51 +0200
Subject: Pondering interfaces over the Gemini 1x responses (was: CGI)
In-Reply-To: <CABuFWiJYP0KBBgOZ14ucfv9EMB8kyh00BxchRaqFV_Une23xvQ@mail.gmail.com>
Message-ID: <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar>

On Sun Jul 19, 2020 at 2:59 PM CEST, Paul Boyd wrote:
> I did consider a succession of inputs. I think we can all agree that a
> succession of modal inputs is irritating, and the UI would be exactly
> that
> on most clients.

To my mind this is the canonical way of getting multi-part input: use
client certificates to establish a persistent session and then just have
the server send successive responses with status code 10.

I agree this would be irritating in a GUI client that pops up a box akin
to a HTTP basic auth login box every time, but that's more an argument
against that being a good UI design than against this being a good way
to handle this kind of input.  This approach is what the protocol makes
natural/obvious, and so it makes sense to design UIs to match it.

In an UI like AV-98, this approach works exceptionally well and provides
a look and feel that's almost indistinguishable from using a shell, or a
terminal application with a REPL interface.  That's a very powerful
thing which we still haven't even begun to experiment with the power of.

I realise something like AV-98 is not a comfortable "daily reading"
interface for most people.  Of course, there are probably ways to make
this approach pleasant to use in a GUI client - people are very welcome
to work on that.  I also still think that having separate clients for
reading static text and using remote applications makes a lot of sense.
It's not necessarily a good match to quick and easy, low-effort
interactivity - but then, that was never the goal.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Jul 19 15:09:24 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 16:09:24 +0200
Subject: Reopening: Stream status code
In-Reply-To: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
Message-ID: <C4ANS2LX7FKK.284EOLQKPCRPW@stilgar>

On Sat Jul 18, 2020 at 11:09 PM CEST,  wrote:
> Hello all,
>
> A stream status code has been mentioned on this list before, and I'd
> like to
> bring it up again. Streams have begun appearing on Gemini, notably on
> gemini://chat.mozz.us. But at the same time, responsible clients have
> been
> adding timeouts for server responses. It is even part of the Egsam test,
> under
> section 1.1: gemini://egsam.pitr.ca/1.1.gmi.

Sorry I didn't chime in on this the first time it came up:  I meant to.
I like all the streaming experiments which have been floating around,
it's cool stuff.

My biggest objection (and I think it's a fatal one) to the idea of
having a 2x status code to convey that a stream is coming is that the
second digit of status codes is supposed to be ignorable without any
serious negative consequences and treating, say, 21 differently from 20
is supposed to be strictly optional on the part of client authors.  If
streamed content breaks clients which take advantage of that
optionality, that's a problem.

Even ignoring that, having separate 20 and 21 codes for "here comes a
non-stream" and "here comes a stream" doesn't make much sense, because
non-streams can be handled perfectly well using exactly the same code,
so the most concise implementation would be to have exactly the same
code handling two different status codes, which makes the different
statuses redundant.

This is mainly just an issue of what to do about timeouts, right?
If you don't have any timeout at all, streamed content works fine, but
buggy/overloaded servers hang the client, and that's bad.  If you have a
fixed timeout of 5 seconds, some streaming applications (like the chat
example mozz has done) break.

Does having clients use, say, a 5 second inital timeout after sending
the request, which gets bumped up to something a little higher after
successfully receiving a response header help a bit here?

Cheers,
Solderpunk

From caranatar at riseup.net  Sun Jul 19 15:22:33 2020
From: caranatar at riseup.net (Caranatar)
Date: Sun, 19 Jul 2020 10:22:33 -0400
Subject: Pondering interfaces over the Gemini 1x responses (was: CGI)
In-Reply-To: <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar>
References: <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar>
Message-ID: <6DF9D9E1-38B6-42DD-A33B-A0C4C5A33ED1@riseup.net>

You could have a sort of landing page for the form, using client certificates, that looks something like

Foo: $foo
=> /form/foo Enter Foo

Bar: $bar
=> /form/bar Enter Bar

=> /form/submit Submit Form

where it displays the current value (if it exists), each associated link allows that value to be input/changed, and then the submit link marks the whole form as ready to be processed. You could even substitute "Please fill out all fields" or something for the last link until the required information is all available.

On July 19, 2020 10:01:51 AM EDT, Solderpunk <solderpunk at posteo.net> wrote:
>On Sun Jul 19, 2020 at 2:59 PM CEST, Paul Boyd wrote:
>> I did consider a succession of inputs. I think we can all agree that
>a
>> succession of modal inputs is irritating, and the UI would be exactly
>> that
>> on most clients.
>
>To my mind this is the canonical way of getting multi-part input: use
>client certificates to establish a persistent session and then just
>have
>the server send successive responses with status code 10.
>
>I agree this would be irritating in a GUI client that pops up a box
>akin
>to a HTTP basic auth login box every time, but that's more an argument
>against that being a good UI design than against this being a good way
>to handle this kind of input.  This approach is what the protocol makes
>natural/obvious, and so it makes sense to design UIs to match it.
>
>In an UI like AV-98, this approach works exceptionally well and
>provides
>a look and feel that's almost indistinguishable from using a shell, or
>a
>terminal application with a REPL interface.  That's a very powerful
>thing which we still haven't even begun to experiment with the power
>of.
>
>I realise something like AV-98 is not a comfortable "daily reading"
>interface for most people.  Of course, there are probably ways to make
>this approach pleasant to use in a GUI client - people are very welcome
>to work on that.  I also still think that having separate clients for
>reading static text and using remote applications makes a lot of sense.
>It's not necessarily a good match to quick and easy, low-effort
>interactivity - but then, that was never the goal.
>
>Cheers,
>Solderpunk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200719/b5c54698/attachment.htm>

From colecmac at protonmail.com  Sun Jul 19 15:38:26 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 19 Jul 2020 14:38:26 +0000
Subject: Reopening: Stream status code
In-Reply-To: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
Message-ID: <Nw2VlGAENi7i-Fx0Nh-ZLbVyx_34ty-NQNe-ZBb4izMyUvmReWOwQDGit8dvWmpAjMOwm3EujveH1fjrkWD1uAQFvumny7Vi-2S_q5ewqMA=@protonmail.com>

Having read all the responses, I think main reason I brought this up
is because of clients (mine and others) that attempt to download the
entire content before rendering it. It seems that this is a poor
strategy, and if I fix that, then stream issues will be solved. Might
be a good thing to add to an FAQ somewhere.

Thanks,
makeworld

From hannu.hartikainen+gemini at gmail.com  Sun Jul 19 16:09:31 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Sun, 19 Jul 2020 18:09:31 +0300
Subject: Pondering interfaces over the Gemini 1x responses (was: CGI)
In-Reply-To: <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar>
References: <CABuFWiJYP0KBBgOZ14ucfv9EMB8kyh00BxchRaqFV_Une23xvQ@mail.gmail.com>
 <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar>
Message-ID: <CANmFPen5gtB45-VYawfORXy_2K2Jktr4OFcgrObCjjt_pZqFWw@mail.gmail.com>

On Sun, 19 Jul 2020 at 17:08, Solderpunk <solderpunk at posteo.net> wrote:
> In an UI like AV-98, this approach works exceptionally well and provides
> a look and feel that's almost indistinguishable from using a shell, or a
> terminal application with a REPL interface.  That's a very powerful
> thing which we still haven't even begun to experiment with the power of.

I was going to post something like this. The paradigm chosen by Gemini
basically prevents GUI or TUI like applications, but it's great for
console use. The web is already a universal GUI application platform,
so Gemini can be something else.

An interaction method like the one in AV-98 would be impossible for
the web but it's amazing for Gemini. I believe this is a strength
we're only beginning to understand. For example, consider the huge
rise of podcasts and audiobooks: people love to listen to information.
With Gemini it would be trivial to browse with a headset while
commuting. The web, on the other hand, is horrible for screen reader
use (ask any blind person).

On Sun, 19 Jul 2020 at 15:59, Paul Boyd <boyd.paul2 at gmail.com> wrote:
> Your UNIX command-line comment is interesting. One set of input args is enough for UNIX, so maybe getopt style flags?
>
> --name John --location "From Beyond" --comment "This is what I have to say"

I like this idea! It also makes me wonder if single-line-capable data
formats would be useful. Eg. edn {:name "Hannu" :comment "Hello
world!"} and YAML {name: Hannu, comment: Hello world!}. (Both do
suffer from unfamiliarity, though.) There must be a huge array of
alternatives, most of them better than my CSV idea.

-Hannu

From hannu.hartikainen+gemini at gmail.com  Sun Jul 19 16:22:37 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Sun, 19 Jul 2020 18:22:37 +0300
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <C4ANF1CGWIXR.1PHPL7X4XN90P@stilgar>
References: <20200715205343.GA1090@commie.my.domain>
 <C4ANF1CGWIXR.1PHPL7X4XN90P@stilgar>
Message-ID: <CANmFPekUgh0kvKsDuPgdc0kY-hUX+9ih0MVVhaEwVMnTWEHNog@mail.gmail.com>

On Sun, 19 Jul 2020 at 16:53, Solderpunk <solderpunk at posteo.net> wrote:
> Precisely.  I would also actually prefer e.g. --domain if I had my
> choice, but it's hardly important enough to be worth the effort of
> duplicating standard library functionality.  Sorry.

Oh, but the flag module *does* support double dashes (it always
supports both). Thus my suggestion to change all documentation to use
--server, --domain and such. You can even add the short versions still
using the flag module; there will be undocumented support for --s
besides -s and -server besides --server, but that's not a huge problem
IMHO.

-Hannu

From mbays at sdf.org  Sun Jul 19 16:50:43 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sun, 19 Jul 2020 17:50:43 +0200
Subject: Pondering interfaces over the Gemini 1x responses (was: CGI)
In-Reply-To: <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar>
References: <CABuFWiJYP0KBBgOZ14ucfv9EMB8kyh00BxchRaqFV_Une23xvQ@mail.gmail.com>
 <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar>
Message-ID: <20200719155043.GA18671@localhost>

* Sunday, 2020-07-19 at 16:01 +0200 - Solderpunk <solderpunk at posteo.net>:

>To my mind this is the canonical way of getting multi-part input: use 
>client certificates to establish a persistent session and then just 
>have the server send successive responses with status code 10.
>
>In an UI like AV-98, this approach works exceptionally well and provides 
>a look and feel that's almost indistinguishable from using a shell

*Except* that you can only have one line of output between each line of 
input, because 10 doesn't allow a body. This is rather limiting.

Other than adding a new response code, the nicest way I see around this 
is a convention that clients should make it easy to rerequest the last 
URI with a new query parameter. This could be done for example with 
a user-enabled "REPL mode" in which the client repeatedly accepts a line 
of input from the user and uses it as a query parameter in a new request 
based on the current URI.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200719/343029d9/attachment.sig>

From hannu.hartikainen+gemini at gmail.com  Sun Jul 19 16:55:28 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Sun, 19 Jul 2020 18:55:28 +0300
Subject: Co-serving a static site over Gemini
In-Reply-To: <cbf108be4558dfb13d1968017d949188@riseup.net>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
Message-ID: <CANmFPek8GuxWLk+UfxL-qMJDoC=2NghVyGwT1As-7WDqObriVw@mail.gmail.com>

Hi there, robot!

On Fri, 17 Jul 2020 at 04:10, <ext0l at riseup.net> wrote:
> I'd like to serve it over Gemini as well. So I'm working on a project
> <https://github.com/deifactor/exarch> to do so.

Nice project! I also have a Zola site and would like something similar
for Gemini. I did actually implement a rudimentary non-HTML support in
Zola itself [0] but it (understandably) feels like the maintainer
doesn't like the direction this would take the project. I contemplated
a Zola fork but it's quite HTML centric so not sure about that.

[0] https://github.com/getzola/zola/pull/1059

If you want my opinions I think building static files is much better
than generating static content on request. And the big features in
Zola that would adapt to Gemini are template support and Atom feeds.
Still, I'm not sure if it's worthwhile to try adapting the same
content to Gemini. I think a simpler static site generator without
markdown might be more suited.

Now that I think about it, I should think about a Gemini specific SSG
a bit more. I've broken stuff with my Makefile+gemfeed+md2gemini based
weird system too many times. (Most recently I broke some Atom
timestamps today, and I haven't yet fixed that.)

-Hannu

From solderpunk at posteo.net  Sun Jul 19 17:08:34 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 19 Jul 2020 18:08:34 +0200
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <fbd7ca3d-20c3-e562-b6b7-55d697f1a6dc@owlsne.st>
Message-ID: <C4AQBB7YOON6.196HT0SEOLK7G@stilgar>

On Sat Jul 18, 2020 at 6:33 AM CEST, luna wrote:

> Using the same domain name and expiration date, sizes of ed25519 certs
> through gemcert seem to be a bit larger compared to what I get from a
> certificate generator that I wrote a few days back (424 bytes versus 262
> bytes) despite the x509 templates using the same basic values.

Hmm...any chance that's comparing PEM and DER encodings?  I would not
expect such a large in an apples-to-apples comparison.

Cheers,
Solderpunk

From alex at gnu.org  Sun Jul 19 19:51:23 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sun, 19 Jul 2020 20:51:23 +0200
Subject: Pondering interfaces over the Gemini 1x responses (was: CGI)
In-Reply-To: <20200719155043.GA18671@localhost>
References: <CABuFWiJYP0KBBgOZ14ucfv9EMB8kyh00BxchRaqFV_Une23xvQ@mail.gmail.com>
 <C4ANMA5J8CZW.2XP0W1FTC3FRU@stilgar> <20200719155043.GA18671@localhost>
Message-ID: <7d0a52d109532a37319cc957aa0cf5b1f7d73efb.camel@gnu.org>

On Sun, 2020-07-19 at 17:50 +0200, mbays at sdf.org wrote:
> *Except* that you can only have one line of output between each line
> of 
> input, because 10 doesn't allow a body. This is rather limiting.
> 

I think this can work because you use redirects in between (which is
also what you need to do if you want to encode the answers in the URL).

/story/123/comment/add

20 text/gemini\r
Hello! We're going to ask you for a temporary certificate to establish
a session, your name, and the comment, OK? If you're ready, click the
link below!
=> ready

/story/123/comment/ready

60 Please tell your client to generate a temporary certificate\r

/story/123/comment/ready

20 text/gemini\r
Excellent! First your name, then the comment, OK? If you're ready,
follow the link below.
=> name

/story/123/comment/name

10 Your name? \r

30 gemini://example.org/story/123/comment/name-ok

/story/123/comment/name-ok

20 text/gemini\r
Excellent, Alex. Thanks! Now for the comment. Please remember that you
have about 900 characters. Follow the link below when you're ready.
=> comment

10 Let's have that comment!\r

30 gemini://example.org/story/123/comment/comment-ok

/story/123/comment/comment-ok

All-right! Got your comment. This is what we're going to save:

"I love your post. Viagra cheap! -- Alex"

Click the link below to save.
=> save

30 gemini://example.org/story/123

20 text/gemini\r
Bla bla bla...



From alex at gnu.org  Sun Jul 19 19:55:56 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sun, 19 Jul 2020 20:55:56 +0200
Subject: Does a cert need a Common Name matching the domain?
In-Reply-To: <C4ANJ07KIGVB.PYCXWAK6SZIT@stilgar>
References: <C4ANJ07KIGVB.PYCXWAK6SZIT@stilgar>
Message-ID: <dac23e0e2fba70183785a6c3a4270c894059b74e.camel@gnu.org>

On Sun, 2020-07-19 at 15:57 +0200, Solderpunk wrote:
> I still wonder, though, if it doesn't make sense to check the domain
> names and expect them to match (AV-98 does this, for what it's
> worth),
> mostly just to help guard against configuration errors and things
> like
> that?
> 

I don't know. Do we HAVE to check? If we only have to check when the
common name is an actual domain, how do we detect that, regular
expressions? It seems to run counter to what TOFU promised.

I fell it should be OK for transjovian.org to serve a wiki, and for
alexschroeder.ch:1965 to show that wiki, even though it uses the
certificate I used for transjovian.org. If the server domains have to
match, then I have to do the SNI thing and server different
certificates and that's going to make certificates harder, again.

Please don't do this.



From pitr.vern at gmail.com  Sun Jul 19 20:26:03 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sun, 19 Jul 2020 21:26:03 +0200
Subject: Username/password authentication strategy
Message-ID: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>

I am trying to implement a simple authentication for my Gemini site,
and was planning to use a client certificate CN field to pass
username:password pair to server. However, upon reading closely about
the TLS handshake -
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
it seems that the client (just like the server) certificate is sent
before the ChangeCipherSpec record, i.e. insecure. That means to me
that the CN field would be passed before the TLS session is started
and therefore not suitable as an authentication medium. Is that
correct?

Another alternative to implement username/password type authentication
in Gemini would be the sensitive input status code, but then I would
have to store a list of certificate fingerprint and username pairs,
greatly complicating the system.

Given that Gemini protocol strives to be minimal/low-cost for both
users and client/server devs, has anyone found a simple way to
implement username/password type authentication systems? To be fair, I
have attempted to use client short-/long-lived client certificates as
per recommendation in Gemini protocol specification; however, if
access to the same "account" from multiple devices and being able to
survive certificate loss without permanently losing access is my
account are requirements, this authentication method quickly becomes a
mess. For example, think about how one would go about getting access
to their astrobotany plant on a new device. This is why I ended up
going back to username/password authentication, but having
difficulties making sure that everything is secure. In need of
help/suggestions/ideas, thanks.

From ext0l at riseup.net  Sun Jul 19 20:36:09 2020
From: ext0l at riseup.net (Ash)
Date: Sun, 19 Jul 2020 12:36:09 -0700
Subject: Co-serving a static site over Gemini
In-Reply-To: <CANmFPek8GuxWLk+UfxL-qMJDoC=2NghVyGwT1As-7WDqObriVw@mail.gmail.com>
References: <cbf108be4558dfb13d1968017d949188@riseup.net>
 <CANmFPek8GuxWLk+UfxL-qMJDoC=2NghVyGwT1As-7WDqObriVw@mail.gmail.com>
Message-ID: <2d6cd1c4-ce23-e011-6953-080d2554e4ab@riseup.net>



On 7/19/20 8:55 AM, Hannu Hartikainen wrote:
> Hi there, robot!
> 
> On Fri, 17 Jul 2020 at 04:10, <ext0l at riseup.net> wrote:
>> I'd like to serve it over Gemini as well. So I'm working on a project
>> <https://github.com/deifactor/exarch> to do so.
> 
> Nice project! I also have a Zola site and would like something similar
> for Gemini. I did actually implement a rudimentary non-HTML support in
> Zola itself [0] but it (understandably) feels like the maintainer
> doesn't like the direction this would take the project. I contemplated
> a Zola fork but it's quite HTML centric so not sure about that.
> 
> [0] https://github.com/getzola/zola/pull/1059
> 
> If you want my opinions I think building static files is much better
> than generating static content on request. And the big features in
> Zola that would adapt to Gemini are template support and Atom feeds.
> Still, I'm not sure if it's worthwhile to try adapting the same
> content to Gemini. I think a simpler static site generator without
> markdown might be more suited.
> 
> Now that I think about it, I should think about a Gemini specific SSG
> a bit more. I've broken stuff with my Makefile+gemfeed+md2gemini based
> weird system too many times. (Most recently I broke some Atom
> timestamps today, and I haven't yet fixed that.)
> 
> -Hannu
> 

?

I'd like to keep Markdown support, but mostly so I can reuse the same 
pages of actual content (the posts and everything). The templates I'm 
probably just going to ignore; my plan is that each section just 
automatically gets a link to every post it contains appended to its 
(rendered) _index.md. This is more 'Exarch's file structure is 
compatible with Zola's, so you can run Exarch on a Zola markdown 
repository' than aiming for feature parity with Zola. If I wanted that, 
I'd just tell people to use a HTTP-Gemini proxy or something.

(p.s., how come Microsoft is the only mainstream vendor that has a good 
robot emoji? Mutant Standard [0] is my favorite, which is why I used a 
variant of it as my favicon. Everything else feels too... toylike.)

[0] 
https://blog.mutant.tech/wp-content/uploads/2019/04/Screenshot-2019-04-29-at-15.47.37.png

From alex at gnu.org  Sun Jul 19 21:03:41 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sun, 19 Jul 2020 22:03:41 +0200
Subject: Username/password authentication strategy
In-Reply-To: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>
References: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>
Message-ID: <ba2ffe761c6556b081d2784d599eef80114f5fd5.camel@gnu.org>

On Sun, 2020-07-19 at 21:26 +0200, Peter Vernigorov wrote:
> I am trying to implement a simple authentication for my Gemini site,
> and was planning to use a client certificate CN field to pass
> username:password pair to server. However, upon reading closely about
> the TLS handshake -
> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
> -
> it seems that the client (just like the server) certificate is sent
> before the ChangeCipherSpec record, i.e. insecure. That means to me
> that the CN field would be passed before the TLS session is started
> and therefore not suitable as an authentication medium. Is that
> correct?

Well, my experience is that you tell the server that you want to verify
peer certificates (which is typically off for servers); then the client
sends you a server that won't validate if you do nothing else: you have
to overwrite the default validation code and return True for
everything. Then your code gets the client certificate and now you can
do the real validation in your app instead of on the TLS layer.

Here's a long blog post:
https://alexschroeder.ch/wiki/2020-07-13_Client_Certificates_and_IO%3a%3aSocket%3a%3aSSL_(Perl)

Here's where I tell my server that I want to verify peers (client
certificates) and that I will provide my own verification code:
https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n758

Here's the verification code for the TLS library which accepts
anything:
https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n775

Here's some example code that does actual validation, requests a client
certificate if none is available, etc:
https://alexschroeder.ch/cgit/gemini-wiki/about/#client-certificates

Good luck!

And yes, I'm using more traditional access tokens for my wiki per
default. ?


From pitr.vern at gmail.com  Sun Jul 19 22:27:18 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sun, 19 Jul 2020 23:27:18 +0200
Subject: Username/password authentication strategy
In-Reply-To: <ba2ffe761c6556b081d2784d599eef80114f5fd5.camel@gnu.org>
References: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>
 <ba2ffe761c6556b081d2784d599eef80114f5fd5.camel@gnu.org>
Message-ID: <CAG-mZ3jXW1AUc5c-49dN0T_+ypYVrC3oaxVmG82Rwn0W6HjbKg@mail.gmail.com>

Thanks for the reply Alex. My understanding is that your blog post
talks about how to get the server to request that the client sends the
certificate, and you are right that many Gemini servers don?t usually
do that. When writing Gig framework - https://github.com/pitr/gig -
and having the same issue, I noticed that most Go-based Gemini servers
out there don?t do this but a quick search showed that it?s just a
matter of one line change to get it working properly:

&tls.Config{
  MinVersion: tls.VersionTLS12,
  ClientAuth: tls.RequestClientCert // <-- this line, default is NoClientCert
}

Anyhow, when the client DOES send the certificate, it seems to do it
in plain text. See this excerpt from TLS handshaking:

...
- The server sends its ServerKeyExchange message (depending on the
selected cipher suite, this may be omitted by the server).
...
- The client responds with a Certificate message, which contains the
client's certificate.
...
- The client now sends a ChangeCipherSpec record, essentially telling
the server, "Everything I tell you from now on will be authenticated
(and encrypted if encryption was negotiated)."
...

Notice how the certificate is sent before client starts encrypting
messages. This means that the CN (and other) fields are also in plain
view and therefore cannot contain secret information.


On Sun, Jul 19, 2020 at 10:03 PM Alex Schroeder <alex at gnu.org> wrote:
>
> On Sun, 2020-07-19 at 21:26 +0200, Peter Vernigorov wrote:
> > I am trying to implement a simple authentication for my Gemini site,
> > and was planning to use a client certificate CN field to pass
> > username:password pair to server. However, upon reading closely about
> > the TLS handshake -
> > https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
> > -
> > it seems that the client (just like the server) certificate is sent
> > before the ChangeCipherSpec record, i.e. insecure. That means to me
> > that the CN field would be passed before the TLS session is started
> > and therefore not suitable as an authentication medium. Is that
> > correct?
>
> Well, my experience is that you tell the server that you want to verify
> peer certificates (which is typically off for servers); then the client
> sends you a server that won't validate if you do nothing else: you have
> to overwrite the default validation code and return True for
> everything. Then your code gets the client certificate and now you can
> do the real validation in your app instead of on the TLS layer.
>
> Here's a long blog post:
> https://alexschroeder.ch/wiki/2020-07-13_Client_Certificates_and_IO%3a%3aSocket%3a%3aSSL_(Perl)
>
> Here's where I tell my server that I want to verify peers (client
> certificates) and that I will provide my own verification code:
> https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n758
>
> Here's the verification code for the TLS library which accepts
> anything:
> https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n775
>
> Here's some example code that does actual validation, requests a client
> certificate if none is available, etc:
> https://alexschroeder.ch/cgit/gemini-wiki/about/#client-certificates
>
> Good luck!
>
> And yes, I'm using more traditional access tokens for my wiki per
> default.
>

From luna at owlsne.st  Mon Jul 20 05:42:31 2020
From: luna at owlsne.st (luna)
Date: Mon, 20 Jul 2020 00:42:31 -0400
Subject: [ANN] Announcing gemcert, a simple certificate generator
In-Reply-To: <C4AQBB7YOON6.196HT0SEOLK7G@stilgar>
References: <C4AQBB7YOON6.196HT0SEOLK7G@stilgar>
Message-ID: <9d5392c1-b8e3-3683-8be8-04b5020dba7c@owlsne.st>

> Hmm...any chance that's comparing PEM and DER encodings?  I would not
> expect such a large in an apples-to-apples comparison.

Turns out I must've stayed up too late writing that email because I
completely forgot that the size I referred to for my generator didn't
take the exported file's PEM encoding into account. Welp, that explains
a lot!

An updated comparison: 412 bytes from my own program versus 424 bytes
from gemcert. Not much of a difference this time around.

~luna

-- Email domain proudly hosted at https://migadu.com


From bouncepaw2 at yandex.ru  Sun Jul 19 16:03:43 2020
From: bouncepaw2 at yandex.ru (Timur Ismagilov)
Date: Sun, 19 Jul 2020 20:03:43 +0500
Subject: text/gemini support in MycorrhizaWiki
Message-ID: <842961595171023@vla5-e043431e7e8d.qloud-c.yandex.net>

The best thing about gemini is its markup language. I liked it so much that I decided to add its support to my wiki engine MycorrhizaWiki. Well, the support is not implemented by me, it is implemented by a fellow named DanInSpace104. Thanks!

I think Mycorrhiza's support of text/gemini may support other developers to support text/gemini in non-gemini things. Talking about non-geminity, Mycorrhiza supports web only for now, but I do not exclude the possibility that I will add a gemini front-end one day.

By the way, is text/gemini the only name the markup language has? What about geminitext? It's not really different but sounds cool and is highly usable. In fact, it's already being used in Mycorrhiza's dev chat!

=> https://github.com/bouncepaw/mycorrhiza

--
gemini://tanelorn.city/~bouncepaw

From hello at matthewgraybosch.com  Mon Jul 20 12:24:05 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Mon, 20 Jul 2020 07:24:05 -0400
Subject: text/gemini support in MycorrhizaWiki
In-Reply-To: <842961595171023@vla5-e043431e7e8d.qloud-c.yandex.net>
References: <842961595171023@vla5-e043431e7e8d.qloud-c.yandex.net>
Message-ID: <20200720072405.7c9d2b47938f012fe11ebeef@matthewgraybosch.com>

On Sun, 19 Jul 2020 20:03:43 +0500
Timur Ismagilov <bouncepaw2 at yandex.ru> wrote:

> By the way, is text/gemini the only name the markup language has?
> What about geminitext? It's not really different but sounds cool and
> is highly usable. In fact, it's already being used in Mycorrhiza's
> dev chat!

Hi, Timur. I think I've seen it called gemtext as well. Glad you're
enjoying Tanelorn.

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>		gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From kevin at susa.net  Mon Jul 20 15:50:01 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 20 Jul 2020 15:50:01 +0100
Subject: Username/password authentication strategy
In-Reply-To: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>
References: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>
Message-ID: <CAPk6LxQAwvg36ZSa8RnheaH4NYnmMv6LhRELAvhqJbw21vL5MQ@mail.gmail.com>

I see this as the same issue that exists for clients - without a trusted
CA, there's nothing to stop me masquerading as anyone else, other than the
certificate (e.g. fingerprint) pinning, so I believe the process absolutely
needs a (one-time) login prompt to pin the certificate - I can't see a way
to avoid it.

Your question made me think about what would be the minimum steps required
to implement client TOFU with PIN or password verification, and the code
below is my take on what I think has to happen. Note the code is only meant
as a concise way to discuss the process.

So, for example, a request to a private resource, such as: -

gemini://susa.net/cgi-bin/private.sh?articleId=1234

Might be handled something like this: -

$ cat private.sh
#!/bin/bash

# If we have no client certificate, request one.
if [[ "${TLS_CLIENT_HASH}" == "" ]]; then

    echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"

elif [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) == "" ]]; then

    # We've never seen this user's client hash, so challenge for a PIN
    # (we could store this current URL for onward forwarding)
    echo -ne "30 /cgi-bin/login.sh\r\n"

else

    echo -ne "20 text/gemini\r\n"
    echo "This is the prize inside the protected resource!"
fi

I think a redirect to a login process is unavoidable, because any
originating request might have its own query_string, yet we're going to
need one for the password prompt response. So the login.sh would be our
one-time verification to pin the certificate to a CN based user-id.

$ cat login
#!/bin/bash

# If we have no client certificate, request one.
if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
    echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
    exit
fi

# If the certificate has no CN, then reject it
if [[ "${REMOTE_USER}" == "" ]]; then
    echo -ne "20 text/gemini\r\n"
    echo "Your CN can't be used as a user-id!"
    exit
fi

# We have a client certificate, is it already authorised?
if [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) != "" ]]; then
    echo -ne "20 text/gemini\r\n"
    echo "You are already authorised!"
    exit
fi

# We have a certificate and a valid user-id (CN), so either prompt for
# a PIN, or verify PIN if we've been given a QUERY_STRING.

# Grep the remote user's line from the passwd file (format CN:PIN)
PWD_ENTRY=$(grep "^${REMOTE_USER}:" login_passwd)

# Strip the CN value and separator, leaving the PIN
MY_PIN="${PWD_ENTRY#${REMOTE_USER}:}"

# Check for our PIN in the query string (which may be empty)
if [[ "${QUERY_STRING}" == "${MY_PIN}" ]]; then
    echo -ne "20 text/gemini\r\n"
    echo "Your PIN checks out, ${REMOTE_USER}!"
    echo "${TLS_CLIENT_HASH}" >>/tmp/${REMOTE_USER}_sigs
    echo "Your hash has been stored in '/tmp/${REMOTE_USER}_sigs'"
    exit
fi

echo -ne "11 Please enter your PIN, ${REMOTE_USER}\r\n"


On Sun, 19 Jul 2020 at 20:26, Peter Vernigorov <pitr.vern at gmail.com> wrote:

> I am trying to implement a simple authentication for my Gemini site,
> and was planning to use a client certificate CN field to pass
> username:password pair to server. However, upon reading closely about
> the TLS handshake -
> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
> it seems that the client (just like the server) certificate is sent
> before the ChangeCipherSpec record, i.e. insecure. That means to me
> that the CN field would be passed before the TLS session is started
> and therefore not suitable as an authentication medium. Is that
> correct?
>
> Another alternative to implement username/password type authentication
> in Gemini would be the sensitive input status code, but then I would
> have to store a list of certificate fingerprint and username pairs,
> greatly complicating the system.
>
> Given that Gemini protocol strives to be minimal/low-cost for both
> users and client/server devs, has anyone found a simple way to
> implement username/password type authentication systems? To be fair, I
> have attempted to use client short-/long-lived client certificates as
> per recommendation in Gemini protocol specification; however, if
> access to the same "account" from multiple devices and being able to
> survive certificate loss without permanently losing access is my
> account are requirements, this authentication method quickly becomes a
> mess. For example, think about how one would go about getting access
> to their astrobotany plant on a new device. This is why I ended up
> going back to username/password authentication, but having
> difficulties making sure that everything is secure. In need of
> help/suggestions/ideas, thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200720/8bb3276f/attachment.htm>

From pitr.vern at gmail.com  Mon Jul 20 22:27:00 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Mon, 20 Jul 2020 23:27:00 +0200
Subject: Username/password authentication strategy
In-Reply-To: <CAPk6LxQAwvg36ZSa8RnheaH4NYnmMv6LhRELAvhqJbw21vL5MQ@mail.gmail.com>
References: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>
 <CAPk6LxQAwvg36ZSa8RnheaH4NYnmMv6LhRELAvhqJbw21vL5MQ@mail.gmail.com>
Message-ID: <CAG-mZ3iXL0ynNhF_MfRxsJF_pAVwLw8L8nH_vXv7Eofm46pVcw@mail.gmail.com>

Hey Kevin,

Yes this solution sounds good, pin is passed as part of query string.
Username is still visible outside tls session of course.

But I think the bigger problem is that now I need to store usernames, pins,
all of user?s cert fingerprints and their first seen and last seen dates, I
would need to build an interface to delete old/lost fingerprints, etc.
Compare that to basic auth in http, which while might not be pretty,
involves very little code to implement: check username/password hash
against ones in db on every request (in a before filter if framework
supports it) and I?m done.

By the way, your solution is very similar to how client ssh usually works,
one would login using username/password into a new server or from a new
client, and then add their client certificate to ~/.authorized_keys. So far
yours is the best solution, but I wonder if there?s a simpler, more elegant
way.

On Mon, Jul 20, 2020 at 16:50 Kevin Sangeelee <kevin at susa.net> wrote:

> I see this as the same issue that exists for clients - without a trusted
> CA, there's nothing to stop me masquerading as anyone else, other than the
> certificate (e.g. fingerprint) pinning, so I believe the process absolutely
> needs a (one-time) login prompt to pin the certificate - I can't see a way
> to avoid it.
>
> Your question made me think about what would be the minimum steps required
> to implement client TOFU with PIN or password verification, and the code
> below is my take on what I think has to happen. Note the code is only meant
> as a concise way to discuss the process.
>
> So, for example, a request to a private resource, such as: -
>
> gemini://susa.net/cgi-bin/private.sh?articleId=1234
>
> Might be handled something like this: -
>
> $ cat private.sh
> #!/bin/bash
>
> # If we have no client certificate, request one.
> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
>
>     echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
>
> elif [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) == "" ]];
> then
>
>     # We've never seen this user's client hash, so challenge for a PIN
>     # (we could store this current URL for onward forwarding)
>     echo -ne "30 /cgi-bin/login.sh\r\n"
>
> else
>
>     echo -ne "20 text/gemini\r\n"
>     echo "This is the prize inside the protected resource!"
> fi
>
> I think a redirect to a login process is unavoidable, because any
> originating request might have its own query_string, yet we're going to
> need one for the password prompt response. So the login.sh would be our
> one-time verification to pin the certificate to a CN based user-id.
>
> $ cat login
> #!/bin/bash
>
> # If we have no client certificate, request one.
> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
>     echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
>     exit
> fi
>
> # If the certificate has no CN, then reject it
> if [[ "${REMOTE_USER}" == "" ]]; then
>     echo -ne "20 text/gemini\r\n"
>     echo "Your CN can't be used as a user-id!"
>     exit
> fi
>
> # We have a client certificate, is it already authorised?
> if [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) != "" ]]; then
>     echo -ne "20 text/gemini\r\n"
>     echo "You are already authorised!"
>     exit
> fi
>
> # We have a certificate and a valid user-id (CN), so either prompt for
> # a PIN, or verify PIN if we've been given a QUERY_STRING.
>
> # Grep the remote user's line from the passwd file (format CN:PIN)
> PWD_ENTRY=$(grep "^${REMOTE_USER}:" login_passwd)
>
> # Strip the CN value and separator, leaving the PIN
> MY_PIN="${PWD_ENTRY#${REMOTE_USER}:}"
>
> # Check for our PIN in the query string (which may be empty)
> if [[ "${QUERY_STRING}" == "${MY_PIN}" ]]; then
>     echo -ne "20 text/gemini\r\n"
>     echo "Your PIN checks out, ${REMOTE_USER}!"
>     echo "${TLS_CLIENT_HASH}" >>/tmp/${REMOTE_USER}_sigs
>     echo "Your hash has been stored in '/tmp/${REMOTE_USER}_sigs'"
>     exit
> fi
>
> echo -ne "11 Please enter your PIN, ${REMOTE_USER}\r\n"
>
>
> On Sun, 19 Jul 2020 at 20:26, Peter Vernigorov <pitr.vern at gmail.com>
> wrote:
>
>> I am trying to implement a simple authentication for my Gemini site,
>> and was planning to use a client certificate CN field to pass
>> username:password pair to server. However, upon reading closely about
>> the TLS handshake -
>> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
>> it seems that the client (just like the server) certificate is sent
>> before the ChangeCipherSpec record, i.e. insecure. That means to me
>> that the CN field would be passed before the TLS session is started
>> and therefore not suitable as an authentication medium. Is that
>> correct?
>>
>> Another alternative to implement username/password type authentication
>> in Gemini would be the sensitive input status code, but then I would
>> have to store a list of certificate fingerprint and username pairs,
>> greatly complicating the system.
>>
>> Given that Gemini protocol strives to be minimal/low-cost for both
>> users and client/server devs, has anyone found a simple way to
>> implement username/password type authentication systems? To be fair, I
>> have attempted to use client short-/long-lived client certificates as
>> per recommendation in Gemini protocol specification; however, if
>> access to the same "account" from multiple devices and being able to
>> survive certificate loss without permanently losing access is my
>> account are requirements, this authentication method quickly becomes a
>> mess. For example, think about how one would go about getting access
>> to their astrobotany plant on a new device. This is why I ended up
>> going back to username/password authentication, but having
>> difficulties making sure that everything is secure. In need of
>> help/suggestions/ideas, thanks.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200720/5bda12bc/attachment-0001.htm>

From kevin at susa.net  Mon Jul 20 23:34:54 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 20 Jul 2020 23:34:54 +0100
Subject: Username/password authentication strategy
In-Reply-To: <CAG-mZ3iXL0ynNhF_MfRxsJF_pAVwLw8L8nH_vXv7Eofm46pVcw@mail.gmail.com>
References: <CAG-mZ3htQ_Zv=K7TU6RyRJ0YbfA1yedehiTQFoJeS_7OvBSrLQ@mail.gmail.com>
 <CAPk6LxQAwvg36ZSa8RnheaH4NYnmMv6LhRELAvhqJbw21vL5MQ@mail.gmail.com>
 <CAG-mZ3iXL0ynNhF_MfRxsJF_pAVwLw8L8nH_vXv7Eofm46pVcw@mail.gmail.com>
Message-ID: <CAPk6LxQAzhiFr4rBYJw8np2_aynJt81XaHK8AP4Ds_wFaLHpWA@mail.gmail.com>

Hi Peter,

The only simplification that I had in mind was to disregard the CN entirely
and replace the PIN with a unique auth-token that they'd have to use to add
a new certificate to their profile.

The storage/processing is not much more complex than with
username/passwords - a profile is just a unique auth-token and a list of
hash strings. Realistically, there's no need to delete anything unless you
revoke their account (delete everything) or a certificate has expired
(remove its hash to force a re-auth).

You could have all auth requests go through a single CGI script, which
would allow you to separate authentication from the actual content. For
example, I have a CGI script called 'serverinfo', and when I make a request
to the script with extra path info, the script is invoked and the extra
path is made available to the script. e.g. gemini://
gemini.susa.net/cgi-bin/serverinfo/something/else.gmi yields variables: -

? GEMINI_URL: gemini://gemini.susa.net/cgi-bin/serverinfo/something/else.gmi
? SERVER_NAME: gemini.susa.net
? SERVER_PROTOCOL: GEMINI
? SERVER_SOFTWARE: gemserv
? SCRIPT_NAME: /cgi-bin/serverinfo
? QUERY_STRING:
? PATH_INFO: /something/else.gmi

The PATH_INFO could then be used by subsequent code to 'direct' the CGI
script to generate the correct content, meaning that all your 'handler'
code could assume that validation has passed, a little more like typical
HTTP based code.

Kevin

On Mon, 20 Jul 2020 at 22:27, Peter Vernigorov <pitr.vern at gmail.com> wrote:

> Hey Kevin,
>
> Yes this solution sounds good, pin is passed as part of query string.
> Username is still visible outside tls session of course.
>
> But I think the bigger problem is that now I need to store usernames,
> pins, all of user?s cert fingerprints and their first seen and last seen
> dates, I would need to build an interface to delete old/lost fingerprints,
> etc. Compare that to basic auth in http, which while might not be pretty,
> involves very little code to implement: check username/password hash
> against ones in db on every request (in a before filter if framework
> supports it) and I?m done.
>
> By the way, your solution is very similar to how client ssh usually works,
> one would login using username/password into a new server or from a new
> client, and then add their client certificate to ~/.authorized_keys. So far
> yours is the best solution, but I wonder if there?s a simpler, more elegant
> way.
>
> On Mon, Jul 20, 2020 at 16:50 Kevin Sangeelee <kevin at susa.net> wrote:
>
>> I see this as the same issue that exists for clients - without a trusted
>> CA, there's nothing to stop me masquerading as anyone else, other than the
>> certificate (e.g. fingerprint) pinning, so I believe the process absolutely
>> needs a (one-time) login prompt to pin the certificate - I can't see a way
>> to avoid it.
>>
>> Your question made me think about what would be the minimum steps
>> required to implement client TOFU with PIN or password verification, and
>> the code below is my take on what I think has to happen. Note the code is
>> only meant as a concise way to discuss the process.
>>
>> So, for example, a request to a private resource, such as: -
>>
>> gemini://susa.net/cgi-bin/private.sh?articleId=1234
>>
>> Might be handled something like this: -
>>
>> $ cat private.sh
>> #!/bin/bash
>>
>> # If we have no client certificate, request one.
>> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
>>
>>     echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
>>
>> elif [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) == "" ]];
>> then
>>
>>     # We've never seen this user's client hash, so challenge for a PIN
>>     # (we could store this current URL for onward forwarding)
>>     echo -ne "30 /cgi-bin/login.sh\r\n"
>>
>> else
>>
>>     echo -ne "20 text/gemini\r\n"
>>     echo "This is the prize inside the protected resource!"
>> fi
>>
>> I think a redirect to a login process is unavoidable, because any
>> originating request might have its own query_string, yet we're going to
>> need one for the password prompt response. So the login.sh would be our
>> one-time verification to pin the certificate to a CN based user-id.
>>
>> $ cat login
>> #!/bin/bash
>>
>> # If we have no client certificate, request one.
>> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
>>     echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
>>     exit
>> fi
>>
>> # If the certificate has no CN, then reject it
>> if [[ "${REMOTE_USER}" == "" ]]; then
>>     echo -ne "20 text/gemini\r\n"
>>     echo "Your CN can't be used as a user-id!"
>>     exit
>> fi
>>
>> # We have a client certificate, is it already authorised?
>> if [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) != "" ]]; then
>>     echo -ne "20 text/gemini\r\n"
>>     echo "You are already authorised!"
>>     exit
>> fi
>>
>> # We have a certificate and a valid user-id (CN), so either prompt for
>> # a PIN, or verify PIN if we've been given a QUERY_STRING.
>>
>> # Grep the remote user's line from the passwd file (format CN:PIN)
>> PWD_ENTRY=$(grep "^${REMOTE_USER}:" login_passwd)
>>
>> # Strip the CN value and separator, leaving the PIN
>> MY_PIN="${PWD_ENTRY#${REMOTE_USER}:}"
>>
>> # Check for our PIN in the query string (which may be empty)
>> if [[ "${QUERY_STRING}" == "${MY_PIN}" ]]; then
>>     echo -ne "20 text/gemini\r\n"
>>     echo "Your PIN checks out, ${REMOTE_USER}!"
>>     echo "${TLS_CLIENT_HASH}" >>/tmp/${REMOTE_USER}_sigs
>>     echo "Your hash has been stored in '/tmp/${REMOTE_USER}_sigs'"
>>     exit
>> fi
>>
>> echo -ne "11 Please enter your PIN, ${REMOTE_USER}\r\n"
>>
>>
>> On Sun, 19 Jul 2020 at 20:26, Peter Vernigorov <pitr.vern at gmail.com>
>> wrote:
>>
>>> I am trying to implement a simple authentication for my Gemini site,
>>> and was planning to use a client certificate CN field to pass
>>> username:password pair to server. However, upon reading closely about
>>> the TLS handshake -
>>> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
>>> it seems that the client (just like the server) certificate is sent
>>> before the ChangeCipherSpec record, i.e. insecure. That means to me
>>> that the CN field would be passed before the TLS session is started
>>> and therefore not suitable as an authentication medium. Is that
>>> correct?
>>>
>>> Another alternative to implement username/password type authentication
>>> in Gemini would be the sensitive input status code, but then I would
>>> have to store a list of certificate fingerprint and username pairs,
>>> greatly complicating the system.
>>>
>>> Given that Gemini protocol strives to be minimal/low-cost for both
>>> users and client/server devs, has anyone found a simple way to
>>> implement username/password type authentication systems? To be fair, I
>>> have attempted to use client short-/long-lived client certificates as
>>> per recommendation in Gemini protocol specification; however, if
>>> access to the same "account" from multiple devices and being able to
>>> survive certificate loss without permanently losing access is my
>>> account are requirements, this authentication method quickly becomes a
>>> mess. For example, think about how one would go about getting access
>>> to their astrobotany plant on a new device. This is why I ended up
>>> going back to username/password authentication, but having
>>> difficulties making sure that everything is secure. In need of
>>> help/suggestions/ideas, thanks.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200720/c699483b/attachment.htm>

From lambdatronic at disroot.org  Tue Jul 21 04:11:22 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Mon, 20 Jul 2020 23:11:22 -0400
Subject: Does a cert need a Common Name matching the domain?
In-Reply-To: <dac23e0e2fba70183785a6c3a4270c894059b74e.camel@gnu.org>
References: <C4ANJ07KIGVB.PYCXWAK6SZIT@stilgar>
 <dac23e0e2fba70183785a6c3a4270c894059b74e.camel@gnu.org>
Message-ID: <877duxa7fp.fsf@disroot.org>

I was under the impression that the Gemini spec already made it
mandatory to make CNs match the requested domain name. That's why I
implemented SNI in Space Age. Here's the relevant section of the spec:

>From gemini://gemini.circumlunar.space/docs/specification.gmi:
-----------------------------------------------------------------
4 TLS

Use of TLS for Gemini transactions is mandatory.

Use of the Server Name Indication (SNI) extension to TLS is also
mandatory, to facilitate name-based virtual hosting.
-----------------------------------------------------------------

If I'm misunderstanding something here, please clarify.

Thanks,
  Gary


Alex Schroeder <alex at gnu.org> writes:

> On Sun, 2020-07-19 at 15:57 +0200, Solderpunk wrote:
>> I still wonder, though, if it doesn't make sense to check the domain
>> names and expect them to match (AV-98 does this, for what it's
>> worth),
>> mostly just to help guard against configuration errors and things
>> like
>> that?
>> 
>
> I don't know. Do we HAVE to check? If we only have to check when the
> common name is an actual domain, how do we detect that, regular
> expressions? It seems to run counter to what TOFU promised.
>
> I fell it should be OK for transjovian.org to serve a wiki, and for
> alexschroeder.ch:1965 to show that wiki, even though it uses the
> certificate I used for transjovian.org. If the server domains have to
> match, then I have to do the SNI thing and server different
> certificates and that's going to make certificates harder, again.
>
> Please don't do this.


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From lambdatronic at disroot.org  Tue Jul 21 04:39:38 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Mon, 20 Jul 2020 23:39:38 -0400
Subject: text/gemini support in MycorrhizaWiki
In-Reply-To: <20200720072405.7c9d2b47938f012fe11ebeef@matthewgraybosch.com>
References: <842961595171023@vla5-e043431e7e8d.qloud-c.yandex.net>
 <20200720072405.7c9d2b47938f012fe11ebeef@matthewgraybosch.com>
Message-ID: <874kq1a64l.fsf@disroot.org>

Gemini's official documentation site refers to the markup format as
"Gemtext". Here's the relevant link:

gemini://gemini.circumlunar.space/docs/gemtext.gmi


Matthew Graybosch <hello at matthewgraybosch.com> writes:

> On Sun, 19 Jul 2020 20:03:43 +0500
> Timur Ismagilov <bouncepaw2 at yandex.ru> wrote:
>
>> By the way, is text/gemini the only name the markup language has?
>> What about geminitext? It's not really different but sounds cool and
>> is highly usable. In fact, it's already being used in Mycorrhiza's
>> dev chat!
>
> Hi, Timur. I think I've seen it called gemtext as well. Glad you're
> enjoying Tanelorn.


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From alex at gnu.org  Tue Jul 21 07:09:25 2020
From: alex at gnu.org (Alex Schroeder)
Date: Tue, 21 Jul 2020 08:09:25 +0200
Subject: Does a cert need a Common Name matching the domain?
In-Reply-To: <877duxa7fp.fsf@disroot.org>
References: <C4ANJ07KIGVB.PYCXWAK6SZIT@stilgar>
 <dac23e0e2fba70183785a6c3a4270c894059b74e.camel@gnu.org>
 <877duxa7fp.fsf@disroot.org>
Message-ID: <55c06980fadf39e1c3018077d00d360505a3f364.camel@gnu.org>

On Mon, 2020-07-20 at 23:11 -0400, Gary Johnson wrote:
> I was under the impression that the Gemini spec already made it
> mandatory to make CNs match the requested domain name. That's why I
> implemented SNI in Space Age. Here's the relevant section of the
> spec:
> 
> From gemini://gemini.circumlunar.space/docs/specification.gmi:
> -----------------------------------------------------------------
> 4 TLS
> 
> Use of TLS for Gemini transactions is mandatory.
> 
> Use of the Server Name Indication (SNI) extension to TLS is also
> mandatory, to facilitate name-based virtual hosting.
> -----------------------------------------------------------------
> 
> If I'm misunderstanding something here, please clarify.

Hi Gary

Thanks for your response.

My thinking is this: SNI is how the client tells the server which host
it wants to reach in case multiple hosts are hosted on the same IP.
Thus, the spec says: in order to facilitate name-based virtual hosting,
we want SNI to be part of the standard. That is, both users Alex and
Gary could host their sites on a single server, and they could both use
their own server certificates. The server would receive requests from
clients for either Alex's site or Gary's site, know which certificate
to send back to the client, and serve the appropriate content. This is
the benefit of SNI.

In my mind, this doesn't require hostname verification, though! Alex's
certificate could have used the common name "Alex Schroeder" and Gary's
certificate could have used the common name "Gary Johnson". All the
client sees is a certificate, which it trusts on first use (TOFU).
Users might decide to look at the common name of the certificate, or
not. There's not even the need to provide a common name ? we could have
generated our certificates using nothing but our email address, or our
organization name.

In short, I'm claiming all of these are valid certificates for a Gemini
site at alexschroeder.ch, even if they are invalid certificates for a
HTTPS site at alexschroeder.ch (maybe? I'm ignoring alt subject name):

openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
        Subject: emailAddress = alex at gnu.org

openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
        Subject: CN = Gemini Wiki

openssl x509 -in /var/lib/dehydrated/certs/transjovian.org/cert.pem
-noout -sha256 -text | grep Subject
        Subject: CN = transjovian.org

What do you think? Do you think SNI inherently mandates that the
subject have a common name field that matches the domain? It would have
to be implied in the X.509 spec somewhere, I guess?

Cheers
Alex



From solderpunk at posteo.net  Tue Jul 21 18:33:24 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 21 Jul 2020 19:33:24 +0200
Subject: Username/password authentication strategy
In-Reply-To: <CAG-mZ3iXL0ynNhF_MfRxsJF_pAVwLw8L8nH_vXv7Eofm46pVcw@mail.gmail.com>
Message-ID: <C4CHDCP3U13Q.3AKQH0I8PA045@stilgar>

On Mon Jul 20, 2020 at 11:27 PM CEST, Peter Vernigorov wrote:

> But I think the bigger problem is that now I need to store usernames,
> pins,
> all of user?s cert fingerprints and their first seen and last seen
> dates, I
> would need to build an interface to delete old/lost fingerprints, etc.

Combining username/password authentication with multiple simultaneous,
long-lived certificates seems like a maximum-complexity approach to me
and I'm not sure there's much to be gained from it.

If you want something light and simple using usernames and passwords, it
makes sense to me to inform the user to generate a short-lived
certificate, to then use a sequence of 10 and 11 status codes to request
a username and password, and, if they are valid, to mark that
certificate fingerprint as authorised for that account and at the same
time immediately deauthorise (and forget about) any and all previous
certificates used for that account.  A user "logs out" manually by
deleting the certificate, or else their session naturally expires when
the certificate's validity period lapses.

I grant you this is less straightforward than HTTP basic auth.
Multi-user applications with user-friendly interfaces aren't really
straightforward in Gemini.

Cheers,
Solderpunk

From alex at gnu.org  Tue Jul 21 20:37:28 2020
From: alex at gnu.org (Alex Schroeder)
Date: Tue, 21 Jul 2020 21:37:28 +0200
Subject: Username/password authentication strategy
In-Reply-To: <C4CHDCP3U13Q.3AKQH0I8PA045@stilgar>
References: <C4CHDCP3U13Q.3AKQH0I8PA045@stilgar>
Message-ID: <653c26dde99f39bc61f57b96b0fa78219df37763.camel@gnu.org>

I'm hoping to collect pieces of advice that apply to all future
developers on a wiki... I hope you're OK with that?

gemini://transjovian.org/phoebe/page/Design

The first post is a copy of Solderpunk's suggestion on how to do
usernames and passwords.

I'd love it if other people also helped collect these, or comment and
refine them, as we all learn more.



From kevin at susa.net  Tue Jul 21 21:48:19 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 21 Jul 2020 21:48:19 +0100
Subject: Username/password authentication strategy
In-Reply-To: <653c26dde99f39bc61f57b96b0fa78219df37763.camel@gnu.org>
References: <C4CHDCP3U13Q.3AKQH0I8PA045@stilgar>
 <653c26dde99f39bc61f57b96b0fa78219df37763.camel@gnu.org>
Message-ID: <CAPk6LxTNPgm2f5FWhzQ5XXgr=xtpszN=2rw8ksTaJj=ciBOjQQ@mail.gmail.com>

I think the idea of collating mailing-list posts on particular subjects
could be useful, though to add value it really needs commentary to
summarise the posts and, perhaps more importantly, links to the relevant
posts.

I'd certainly want to see links to my original posts if I'm mentioned in
reference but otherwise, as far as I'm concerned, if you're happy to curate
stuff, then great!

Kevin


On Tue, 21 Jul 2020 at 20:37, Alex Schroeder <alex at gnu.org> wrote:

> I'm hoping to collect pieces of advice that apply to all future
> developers on a wiki... I hope you're OK with that?
>
> gemini://transjovian.org/phoebe/page/Design
>
> The first post is a copy of Solderpunk's suggestion on how to do
> usernames and passwords.
>
> I'd love it if other people also helped collect these, or comment and
> refine them, as we all learn more.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200721/c7e50757/attachment.htm>

From alex at gnu.org  Tue Jul 21 22:01:43 2020
From: alex at gnu.org (Alex Schroeder)
Date: Tue, 21 Jul 2020 23:01:43 +0200
Subject: Collecting posts worth remembering on a wiki
In-Reply-To: <CAPk6LxTNPgm2f5FWhzQ5XXgr=xtpszN=2rw8ksTaJj=ciBOjQQ@mail.gmail.com>
References: <C4CHDCP3U13Q.3AKQH0I8PA045@stilgar>
 <653c26dde99f39bc61f57b96b0fa78219df37763.camel@gnu.org>
 <CAPk6LxTNPgm2f5FWhzQ5XXgr=xtpszN=2rw8ksTaJj=ciBOjQQ@mail.gmail.com>
Message-ID: <095aa3f1ec2193520f66255c2fe0e7508d542fb8.camel@gnu.org>

On Tue, 2020-07-21 at 21:48 +0100, Kevin Sangeelee wrote:
> I think the idea of collating mailing-list posts on particular
> subjects
> could be useful, though to add value it really needs commentary to
> summarise the posts and, perhaps more importantly, links to the
> relevant
> posts.

Yeah, absolutely.

> I'd certainly want to see links to my original posts if I'm mentioned
> in
> reference but otherwise, as far as I'm concerned, if you're happy to
> curate
> stuff, then great!

I'll try and remember to post the links. I've added a second post to
the Design page, with a longer thread summary and a post of mine I felt
was worth preserving:

https://transjovian.org:1965/phoebe/page/Design
https://transjovian.org:1965/phoebe/page/How%20to%20leave%20a%20comment

As it is a wiki, obviously everybody is invited. One way to edit
stories is using one of the options described here:

https://transjovian.org:1965/page/Writing



From pitr.vern at gmail.com  Tue Jul 21 22:53:57 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 21 Jul 2020 23:53:57 +0200
Subject: Username/password authentication strategy
In-Reply-To: <CAPk6LxTNPgm2f5FWhzQ5XXgr=xtpszN=2rw8ksTaJj=ciBOjQQ@mail.gmail.com>
References: <C4CHDCP3U13Q.3AKQH0I8PA045@stilgar>
 <653c26dde99f39bc61f57b96b0fa78219df37763.camel@gnu.org>
 <CAPk6LxTNPgm2f5FWhzQ5XXgr=xtpszN=2rw8ksTaJj=ciBOjQQ@mail.gmail.com>
Message-ID: <CAG-mZ3jTNqGoRMMV07Co4srjwQAXs6cAuJGrr-0-Ms=rs=0mEg@mail.gmail.com>

Thanks Alex for setting up the design patterns wiki page. Although I think
Kevin?s proposal is more complete with examples. I don?t necessary agree
that existing certificate should be deleted, which logs user out on their
other device, but of course it makes sense if server administrator wants to
keep it as simple as possible. Perhaps this is something that could be
configurable.

On Tue, Jul 21, 2020 at 22:48 Kevin Sangeelee <kevin at susa.net> wrote:

> I think the idea of collating mailing-list posts on particular subjects
> could be useful, though to add value it really needs commentary to
> summarise the posts and, perhaps more importantly, links to the relevant
> posts.
>
> I'd certainly want to see links to my original posts if I'm mentioned in
> reference but otherwise, as far as I'm concerned, if you're happy to curate
> stuff, then great!
>
> Kevin
>
>
> On Tue, 21 Jul 2020 at 20:37, Alex Schroeder <alex at gnu.org> wrote:
>
>> I'm hoping to collect pieces of advice that apply to all future
>> developers on a wiki... I hope you're OK with that?
>>
>> gemini://transjovian.org/phoebe/page/Design
>>
>> The first post is a copy of Solderpunk's suggestion on how to do
>> usernames and passwords.
>>
>> I'd love it if other people also helped collect these, or comment and
>> refine them, as we all learn more.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200721/48b21cd5/attachment.htm>

From alex at gnu.org  Wed Jul 22 08:55:24 2020
From: alex at gnu.org (Alex Schroeder)
Date: Wed, 22 Jul 2020 09:55:24 +0200
Subject: [SPECS text/gemini] Heading lines proposal
Message-ID: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>

Hi all
I want to return to a heading lines proposal raised by cage back in
June.
https://lists.orbitalfox.eu/archives/gemini/2020/001662.html

I would like headers to require a space after the #, at least for the
first level.

Headings:

# Foo
## Bar
### Baz
##Bar if you really want to
###Baz if you really want to

The reason being that I'd love to use hashtags in my posts and I'd love
to add them at the end, like this:

#Backup #Administration

I guess I can live with the requirement to add some filler text in
front of the first tag:

Tags: #Backup #Administration

But I think requiring a space after level 1 headings would make more
sense. What do you think?

Cheers
Alex



From benulo at systemli.org  Wed Jul 22 09:37:17 2020
From: benulo at systemli.org (Ben)
Date: Wed, 22 Jul 2020 13:07:17 +0430
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
Message-ID: <efc84957-2756-b2a7-a9cc-21b4bbaffc6a@systemli.org>

It should be rare for hashtags to appear at the beginning of a line 
(even in your example they didn't), but in such a case there could 
indeed be a conflict. In such cases perhaps something like \# could be 
used to start a line.

The space idea also seems good to me and maybe more efficient. 
Personally I always space my headers as you suggested.

Ben

-- 
gemini://kwiecien.us/

From bctnry at outlook.com  Wed Jul 22 09:45:54 2020
From: bctnry at outlook.com (Sebastian Higgins)
Date: Wed, 22 Jul 2020 08:45:54 +0000
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
Message-ID: <HK2PR01MB318582FDA0F4056EC177CF1ECC790@HK2PR01MB3185.apcprd01.prod.exchangelabs.com>

IMO a better (way better) option will be just use `=` for headings but that conflicts with current spec & all the existing software. Requiring (at least one) space after # is equally good as long as it's applied to all headings & not just level 1 headings; it is probably not a good idea to introduce new corner cases when doing changes like this in spec.
________________________________
From: Gemini <gemini-bounces at lists.orbitalfox.eu> on behalf of Alex Schroeder <alex at gnu.org>
Sent: Wednesday, July 22, 2020 7:55
To: Gemini <gemini at lists.orbitalfox.eu>
Subject: [SPECS text/gemini] Heading lines proposal

Hi all
I want to return to a heading lines proposal raised by cage back in
June.
https://lists.orbitalfox.eu/archives/gemini/2020/001662.html

I would like headers to require a space after the #, at least for the
first level.

Headings:

# Foo
## Bar
### Baz
##Bar if you really want to
###Baz if you really want to

The reason being that I'd love to use hashtags in my posts and I'd love
to add them at the end, like this:

#Backup #Administration

I guess I can live with the requirement to add some filler text in
front of the first tag:

Tags: #Backup #Administration

But I think requiring a space after level 1 headings would make more
sense. What do you think?

Cheers
Alex


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200722/2ed66f0a/attachment-0001.htm>

From lambdatronic at disroot.org  Wed Jul 22 20:24:44 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Wed, 22 Jul 2020 15:24:44 -0400
Subject: Does a cert need a Common Name matching the domain?
In-Reply-To: <55c06980fadf39e1c3018077d00d360505a3f364.camel@gnu.org>
References: <C4ANJ07KIGVB.PYCXWAK6SZIT@stilgar>
 <dac23e0e2fba70183785a6c3a4270c894059b74e.camel@gnu.org>
 <877duxa7fp.fsf@disroot.org>
 <55c06980fadf39e1c3018077d00d360505a3f364.camel@gnu.org>
Message-ID: <871rl35p4z.fsf@disroot.org>

Hi Alex,

I follow your rationale, and unfortunately, I don't know whether
matching CNs are required by the x509 spec. I think I'd like to hear
Solderpunk weigh in on this issue since it seems like a slightly
ambiguous area in the spec.

Cheers,
  Gary

Alex Schroeder <alex at gnu.org> writes:

> On Mon, 2020-07-20 at 23:11 -0400, Gary Johnson wrote:
>> I was under the impression that the Gemini spec already made it
>> mandatory to make CNs match the requested domain name. That's why I
>> implemented SNI in Space Age. Here's the relevant section of the
>> spec:
>> 
>> From gemini://gemini.circumlunar.space/docs/specification.gmi:
>> -----------------------------------------------------------------
>> 4 TLS
>> 
>> Use of TLS for Gemini transactions is mandatory.
>> 
>> Use of the Server Name Indication (SNI) extension to TLS is also
>> mandatory, to facilitate name-based virtual hosting.
>> -----------------------------------------------------------------
>> 
>> If I'm misunderstanding something here, please clarify.
>
> Hi Gary
>
> Thanks for your response.
>
> My thinking is this: SNI is how the client tells the server which host
> it wants to reach in case multiple hosts are hosted on the same IP.
> Thus, the spec says: in order to facilitate name-based virtual hosting,
> we want SNI to be part of the standard. That is, both users Alex and
> Gary could host their sites on a single server, and they could both use
> their own server certificates. The server would receive requests from
> clients for either Alex's site or Gary's site, know which certificate
> to send back to the client, and serve the appropriate content. This is
> the benefit of SNI.
>
> In my mind, this doesn't require hostname verification, though! Alex's
> certificate could have used the common name "Alex Schroeder" and Gary's
> certificate could have used the common name "Gary Johnson". All the
> client sees is a certificate, which it trusts on first use (TOFU).
> Users might decide to look at the common name of the certificate, or
> not. There's not even the need to provide a common name ? we could have
> generated our certificates using nothing but our email address, or our
> organization name.
>
> In short, I'm claiming all of these are valid certificates for a Gemini
> site at alexschroeder.ch, even if they are invalid certificates for a
> HTTPS site at alexschroeder.ch (maybe? I'm ignoring alt subject name):
>
> openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
>         Subject: emailAddress = alex at gnu.org
>
> openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
>         Subject: CN = Gemini Wiki
>
> openssl x509 -in /var/lib/dehydrated/certs/transjovian.org/cert.pem
> -noout -sha256 -text | grep Subject
>         Subject: CN = transjovian.org
>
> What do you think? Do you think SNI inherently mandates that the
> subject have a common name field that matches the domain? It would have
> to be implied in the X.509 spec somewhere, I guess?
>
> Cheers
> Alex


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From lambdatronic at disroot.org  Wed Jul 22 20:39:16 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Wed, 22 Jul 2020 15:39:16 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <HK2PR01MB318582FDA0F4056EC177CF1ECC790@HK2PR01MB3185.apcprd01.prod.exchangelabs.com>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
 <HK2PR01MB318582FDA0F4056EC177CF1ECC790@HK2PR01MB3185.apcprd01.prod.exchangelabs.com>
Message-ID: <87y2nb49wb.fsf@disroot.org>

I'm in favor of requiring at least one space after all headline levels for consistency.

Sebastian Higgins <bctnry at outlook.com> writes:

> IMO a better (way better) option will be just use `=` for headings but that conflicts with current spec & all the existing software. Requiring (at least one) space after # is equally good as long as it's applied to all headings & not just level 1 headings; it is probably not a good idea to introduce new corner cases when doing changes like this in spec.
> ________________________________
> From: Gemini <gemini-bounces at lists.orbitalfox.eu> on behalf of Alex Schroeder <alex at gnu.org>
> Sent: Wednesday, July 22, 2020 7:55
> To: Gemini <gemini at lists.orbitalfox.eu>
> Subject: [SPECS text/gemini] Heading lines proposal
>
> Hi all
> I want to return to a heading lines proposal raised by cage back in
> June.
> https://lists.orbitalfox.eu/archives/gemini/2020/001662.html
>
> I would like headers to require a space after the #, at least for the
> first level.
>
> Headings:
>
> # Foo
> ## Bar
> ### Baz
> ##Bar if you really want to
> ###Baz if you really want to
>
> The reason being that I'd love to use hashtags in my posts and I'd love
> to add them at the end, like this:
>
> #Backup #Administration
>
> I guess I can live with the requirement to add some filler text in
> front of the first tag:
>
> Tags: #Backup #Administration
>
> But I think requiring a space after level 1 headings would make more
> sense. What do you think?
>
> Cheers
> Alex


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From defdefred at protonmail.com  Wed Jul 22 21:06:25 2020
From: defdefred at protonmail.com (defdefred)
Date: Wed, 22 Jul 2020 20:06:25 +0000
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
Message-ID: <4X9w-y3JexN2lx03-sxYUkk6iEVHxKWSDeiJf7mcwHSeGbvQLwyVnIhk9kjkqeZTGDGwoSi_TqJJAeKtILPylIFKPNCraNtLOCg6CBvbx3Y=@protonmail.com>

On Wednesday, July 22, 2020 9:55 AM, Alex Schroeder <alex at gnu.org> wrote:
> #Backup #Administration

Seems that hashtag don't like to be alone...
Maybe 1 x #word could be a heading and several x #word could be hashtags...

freD.


From luna at owlsne.st  Thu Jul 23 00:57:39 2020
From: luna at owlsne.st (luna)
Date: Wed, 22 Jul 2020 19:57:39 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
Message-ID: <2776910.afomCHtBeY@thinkpad-e495>

I'm certainly in favor of this; It could help make parsing headers a bit
easier, make formatting more consistent and prevent problems with these
sort of situations.

~luna



-- Email domain proudly hosted at https://migadu.com


From alex at alexwennerberg.com  Thu Jul 23 01:48:44 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Wed, 22 Jul 2020 19:48:44 -0500
Subject: Open Source Proxy
Message-ID: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>

Hey all!

I'm experimenting with building a web app that includes some proxying of
Gemini content and I was wondering if anyone has put together an open
source proxy for Gemini. I am aware of https://portal.mozz.us/ and
https://proxy.vulpes.one/, but I can't find the code for either of them.

On a related note, I am working on a Python library to convert gmi files to
html which you all may find helpful: https://git.sr.ht/~alexwennerberg/gmi2html

All the best,

Alex

From acdw at acdw.net  Thu Jul 23 03:35:26 2020
From: acdw at acdw.net (acdw)
Date: Wed, 22 Jul 2020 21:35:26 -0500
Subject: Open Source Proxy
In-Reply-To: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>
References: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>
Message-ID: <d6e7fe9c-d29e-4d7f-82a8-a7928450977e@www.fastmail.com>

On 2020-07-22 (Wednesday) at 19:48, alex wennerberg <alex at alexwennerberg.com> wrote:

> Hey all!
> 
> I'm experimenting with building a web app that includes some proxying of
> Gemini content and I was wondering if anyone has put together an open
> source proxy for Gemini. I am aware of https://portal.mozz.us/ and
> https://proxy.vulpes.one/, but I can't find the code for either of them.

Though the vulpes code isn't easy to find, I did find it at https://git.feuerfuchs.dev/Feuerfuchs/gopherproxy. I look forward to your work! I've been wanting to include a proxy with breadpunk.club. 

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From alex at alexwennerberg.com  Thu Jul 23 04:01:40 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Wed, 22 Jul 2020 22:01:40 -0500
Subject: Open Source Proxy
In-Reply-To: <d6e7fe9c-d29e-4d7f-82a8-a7928450977e@www.fastmail.com>
Message-ID: <C4DO2ZU3OH0Y.20SU5B9Q2M3EK@debian-thinkpad>

Nice find! Thanks for the help :)

On Wed Jul 22, 2020 at 9:35 PM CDT, acdw wrote:
> On 2020-07-22 (Wednesday) at 19:48, alex wennerberg
> <alex at alexwennerberg.com> wrote:
>
> > Hey all!
> > 
> > I'm experimenting with building a web app that includes some proxying of
> > Gemini content and I was wondering if anyone has put together an open
> > source proxy for Gemini. I am aware of https://portal.mozz.us/ and
> > https://proxy.vulpes.one/, but I can't find the code for either of them.
>
> Though the vulpes code isn't easy to find, I did find it at
> https://git.feuerfuchs.dev/Feuerfuchs/gopherproxy. I look forward to
> your work! I've been wanting to include a proxy with breadpunk.club.
>
> --
> ~ acdw
> acdw.net | breadpunk.club/~breadw


From alex at gnu.org  Thu Jul 23 12:56:40 2020
From: alex at gnu.org (Alex Schroeder)
Date: Thu, 23 Jul 2020 13:56:40 +0200
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <4X9w-y3JexN2lx03-sxYUkk6iEVHxKWSDeiJf7mcwHSeGbvQLwyVnIhk9kjkqeZTGDGwoSi_TqJJAeKtILPylIFKPNCraNtLOCg6CBvbx3Y=@protonmail.com>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
 <4X9w-y3JexN2lx03-sxYUkk6iEVHxKWSDeiJf7mcwHSeGbvQLwyVnIhk9kjkqeZTGDGwoSi_TqJJAeKtILPylIFKPNCraNtLOCg6CBvbx3Y=@protonmail.com>
Message-ID: <c32beb91e216f1b4cf43eafe8b19abb6e885914f.camel@gnu.org>

On Wed Jul 22, 2020 at 10:06 PM CEST, defdefred wrote:
> Seems that hashtag don't like to be alone...
> Maybe 1 x #word could be a heading and several x #word could be
> hashtags...

I have my doubts. On my blog I have 4788 pages with tags but 2325 of
them have just one tag.

Cheers
Alex


From jmcbray at carcosa.net  Thu Jul 23 19:21:38 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 23 Jul 2020 14:21:38 -0400
Subject: Open Source Proxy
In-Reply-To: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad> (alex wennerberg's
 message of "Wed, 22 Jul 2020 19:48:44 -0500")
References: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>
Message-ID: <87v9iehz2l.fsf@dorothy.carcosa.net>

"alex wennerberg" <alex at alexwennerberg.com> writes:

> I'm experimenting with building a web app that includes some proxying of
> Gemini content and I was wondering if anyone has put together an open
> source proxy for Gemini. I am aware of https://portal.mozz.us/ and
> https://proxy.vulpes.one/, but I can't find the code for either of them.

This is cool, but when you stand it up, don't forget an appropriate
robots.txt! 

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From paper at tilde.institute  Thu Jul 23 19:39:05 2020
From: paper at tilde.institute (Paper)
Date: Thu, 23 Jul 2020 14:39:05 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
Message-ID: <20200723183905.wm7z3cmsdxvdjjg2@tilde.institute>

I think geminitext should be readable even when it is not being
rendered. Something like this isn't readable:

##something

but this is:

## something

So I like this proposal. I think everyone is using a space
even though it's not mandatory yet.

Paper

From defdefred at protonmail.com  Thu Jul 23 19:47:10 2020
From: defdefred at protonmail.com (defdefred)
Date: Thu, 23 Jul 2020 18:47:10 +0000
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <c32beb91e216f1b4cf43eafe8b19abb6e885914f.camel@gnu.org>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
 <4X9w-y3JexN2lx03-sxYUkk6iEVHxKWSDeiJf7mcwHSeGbvQLwyVnIhk9kjkqeZTGDGwoSi_TqJJAeKtILPylIFKPNCraNtLOCg6CBvbx3Y=@protonmail.com>
 <c32beb91e216f1b4cf43eafe8b19abb6e885914f.camel@gnu.org>
Message-ID: <AlDTicxFNXvttK99uIAX3f7JIoasbTEqpw-VPOYomwjRniJWpky2AKTF-7vL1Ybn2TcN2JJMRPSYrwdEIC32NTABI85DQl42SyF5lRnut4s=@protonmail.com>

On Thursday 23 July 2020 13:56, Alex Schroeder <alex at gnu.org> wrote:
> I have my doubts. On my blog I have 4788 pages with tags but 2325 of
> them have just one tag.
Leasiness?
:-)


From luna at owlsne.st  Thu Jul 23 00:50:53 2020
From: luna at owlsne.st (luna)
Date: Wed, 22 Jul 2020 19:50:53 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
References: <5082d514df056ea58a65ea8ed1f2f205b358001f.camel@gnu.org>
Message-ID: <1960255.EdmoDJtqBP@thinkpad-e495>

I'm certainly in favor of this; It could help make parsing headers a bit
easier, make formatting more consistent and prevent problems with these
sort of situations.

~luna



-- Email domain proudly hosted at https://migadu.com


From solderpunk at posteo.net  Thu Jul 23 20:33:43 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Thu, 23 Jul 2020 21:33:43 +0200
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <1960255.EdmoDJtqBP@thinkpad-e495>
Message-ID: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>

Okay, I am happy with this idea (in fact, for a minute or two I was
thinking "didn't we already do this?!" - no, that was with list items,
to avoid ambiguity with *this* kind of emphasis).

At this point it seems like we may as well go "whole hog" and insist on
at least one space after *all* the line type markers - that would mean
quote lines starting with "> " and link lines starting with "=> ".  Does
anybody object to *that*?  I strongly suspect that almost everybody is
actually writing their content that way anyway, but perhaps not...

Cheers,
Solderpunk

From petite.abeille at gmail.com  Thu Jul 23 20:43:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 23 Jul 2020 21:43:11 +0200
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
Message-ID: <1CEAD788-8C40-42AC-A551-F62FE334EAC0@gmail.com>



> On Jul 23, 2020, at 21:33, Solderpunk <solderpunk at posteo.net> wrote:
> 
> At this point it seems like we may as well go "whole hog" and insist on
> at least one space after *all* the line type markers - that would mean
> quote lines starting with "> " and link lines starting with "=> ". 

Amen.




From luna at owlsne.st  Thu Jul 23 20:47:52 2020
From: luna at owlsne.st (luna)
Date: Thu, 23 Jul 2020 15:47:52 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
Message-ID: <2725007.bYeTsQ7qQv@thinkpad-e495>

Sounds like a good plan to me :D

~luna



-- Email domain proudly hosted at https://migadu.com


From acdw at acdw.net  Thu Jul 23 21:08:19 2020
From: acdw at acdw.net (acdw)
Date: Thu, 23 Jul 2020 20:08:19 +0000
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
Message-ID: <e66f81ed-69f2-4ee6-8b37-ccdba920c686@www.fastmail.com>

On 2020-07-23 (Thursday) at 19:33, Solderpunk <solderpunk at posteo.net> wrote:

> Okay, I am happy with this idea (in fact, for a minute or two I was
> thinking "didn't we already do this?!" - no, that was with list items,
> to avoid ambiguity with *this* kind of emphasis).
> 
> At this point it seems like we may as well go "whole hog" and insist on
> at least one space after *all* the line type markers - that would mean
> quote lines starting with "> " and link lines starting with "=> ".  Does
> anybody object to *that*?  I strongly suspect that almost everybody is
> actually writing their content that way anyway, but perhaps not...


The only possible problem is that, with '###' lines, clients will have to read *four* characters from the beginning of a line to determine what it is -- but I don't think that's asking too much.

I am 100% on board with this proposal.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From cage-dev at twistfold.it  Thu Jul 23 21:27:08 2020
From: cage-dev at twistfold.it (cage)
Date: Thu, 23 Jul 2020 22:27:08 +0200
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
References: <1960255.EdmoDJtqBP@thinkpad-e495>
 <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
Message-ID: <20200723202708.GA6975@kurosawa.casa.net>

On Thu, Jul 23, 2020 at 09:33:43PM +0200, Solderpunk wrote:

Hi!

> At this point it seems like we may as well go "whole hog" and insist on
> at least one space after *all* the line type markers - that would mean
> quote lines starting with "> " and link lines starting with "=> ".

In my opinion this is the best thing to do!

(even if i have to change the parser a bit ;-D ;-D)

Bye!
C.

From sean at conman.org  Thu Jul 23 21:45:50 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 23 Jul 2020 16:45:50 -0400
Subject: Identifying robots (was Re: Open Source Proxy)
In-Reply-To: <87v9iehz2l.fsf@dorothy.carcosa.net>
References: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>
 <87v9iehz2l.fsf@dorothy.carcosa.net>
Message-ID: <20200723204549.GA32353@brevard.conman.org>

It was thus said that the Great Jason McBrayer once stated:
> 
> This is cool, but when you stand it up, don't forget an appropriate
> robots.txt! 

  Question---HTTP has the Use-Agent: header to help identify webbots, but
Gemini doesn't have that.  How do I instruct a Gemini bot with robots.txt,
when there's no way for a Gemini bot to identify itself?

  -spc


From petite.abeille at gmail.com  Thu Jul 23 22:10:03 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 23 Jul 2020 23:10:03 +0200
Subject: Identifying robots (was Re: Open Source Proxy)
In-Reply-To: <20200723204549.GA32353@brevard.conman.org>
References: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>
 <87v9iehz2l.fsf@dorothy.carcosa.net>
 <20200723204549.GA32353@brevard.conman.org>
Message-ID: <C4257740-D150-41C6-B623-B3B08822871A@gmail.com>



> On Jul 23, 2020, at 22:45, Sean Conner <sean at conman.org> wrote:
> 
> How do I instruct a Gemini bot with robots.txt,
> when there's no way for a Gemini bot to identify itself?

Through a side channel such as the TLS certificate? Robots could identify themselves there.

Otherwise, only User-agent: * wide rules apply.

Alternatively, some creative use of TLS fingerprinting.

From pitr.vern at gmail.com  Thu Jul 23 22:49:43 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Thu, 23 Jul 2020 23:49:43 +0200
Subject: Username/password authentication strategy
In-Reply-To: <CAG-mZ3jTNqGoRMMV07Co4srjwQAXs6cAuJGrr-0-Ms=rs=0mEg@mail.gmail.com>
References: <C4CHDCP3U13Q.3AKQH0I8PA045@stilgar>
 <653c26dde99f39bc61f57b96b0fa78219df37763.camel@gnu.org>
 <CAPk6LxTNPgm2f5FWhzQ5XXgr=xtpszN=2rw8ksTaJj=ciBOjQQ@mail.gmail.com>
 <CAG-mZ3jTNqGoRMMV07Co4srjwQAXs6cAuJGrr-0-Ms=rs=0mEg@mail.gmail.com>
Message-ID: <CAG-mZ3idGMZ0ptU6xtfKDHAdxuBChqQX=XYxriPFXPf3vVQxmw@mail.gmail.com>

For those who need this functionality, I have implemented the
suggested flow in Gig framework, see
https://github.com/pitr/gig#usernamepassword-authentication-middleware
for the guide on how to use it.

On Tue, Jul 21, 2020 at 11:53 PM Peter Vernigorov <pitr.vern at gmail.com> wrote:
>
> Thanks Alex for setting up the design patterns wiki page. Although I think Kevin?s proposal is more complete with examples. I don?t necessary agree that existing certificate should be deleted, which logs user out on their other device, but of course it makes sense if server administrator wants to keep it as simple as possible. Perhaps this is something that could be configurable.
>
> On Tue, Jul 21, 2020 at 22:48 Kevin Sangeelee <kevin at susa.net> wrote:
>>
>> I think the idea of collating mailing-list posts on particular subjects could be useful, though to add value it really needs commentary to summarise the posts and, perhaps more importantly, links to the relevant posts.
>>
>> I'd certainly want to see links to my original posts if I'm mentioned in reference but otherwise, as far as I'm concerned, if you're happy to curate stuff, then great!
>>
>> Kevin
>>
>>
>> On Tue, 21 Jul 2020 at 20:37, Alex Schroeder <alex at gnu.org> wrote:
>>>
>>> I'm hoping to collect pieces of advice that apply to all future
>>> developers on a wiki... I hope you're OK with that?
>>>
>>> gemini://transjovian.org/phoebe/page/Design
>>>
>>> The first post is a copy of Solderpunk's suggestion on how to do
>>> usernames and passwords.
>>>
>>> I'd love it if other people also helped collect these, or comment and
>>> refine them, as we all learn more.
>>>
>>>

From natpen at natpen.net  Thu Jul 23 23:01:03 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Thu, 23 Jul 2020 18:01:03 -0400
Subject: Identifying robots (was Re: Open Source Proxy)
In-Reply-To: <20200723204549.GA32353@brevard.conman.org>
References: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>
 <87v9iehz2l.fsf@dorothy.carcosa.net>
 <20200723204549.GA32353@brevard.conman.org>
Message-ID: <20200723220103.GB186796@goldfish.localdomain>

For the GUS crawl at least, the crawler doesn't identify itself _to_
crawled sites, but it does obey blocks of rules in robots.txt files
according to user-agent. So it works without needing a user-agent
header.

It obeys user-agent of `*`, `indexer`, and `gus` in order of
increasing importance.

There's been some talk of the generic sorts of user-agents in the
past, which I think is a really nice idea. If `indexer` is a
user-agent that both sites and crawlers had some sort of informal
consensus on, then sites wouldn't need to worry about keeping up with
any new indexers popping up.

Some other generic user-agent ideas, iirc, were `archiver` and
`proxy`.

On Thu, Jul 23, 2020 at 04:45:50PM -0400, Sean Conner wrote:
> It was thus said that the Great Jason McBrayer once stated:
> >
> > This is cool, but when you stand it up, don't forget an appropriate
> > robots.txt!
>
>   Question---HTTP has the Use-Agent: header to help identify webbots, but
> Gemini doesn't have that.  How do I instruct a Gemini bot with robots.txt,
> when there's no way for a Gemini bot to identify itself?
>
>   -spc
>

From colecmac at protonmail.com  Thu Jul 23 23:08:02 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 23 Jul 2020 22:08:02 +0000
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
Message-ID: <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>

> At this point it seems like we may as well go "whole hog" and insist on
> at least one space after all the line type markers - that would mean
> quote lines starting with "> " and link lines starting with "=> ". Does
> anybody object to that?


I do sort of object to this. I don't think there's much value in switching
the other definitions when a need hasn't been demonstrated. I have seen many
links that don't have a space after the "=>", and I don't see why there needs to
be a space after the quote marker either. It's nicer to read in both cases,
but I'm not in favour of creating changes when they don't seem to be required.

Why not just change the heading lines?

Cheers,
makeworld

From madogrit0 at gmail.com  Fri Jul 24 00:31:24 2020
From: madogrit0 at gmail.com (Mad Ogrit)
Date: Thu, 23 Jul 2020 19:31:24 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
 <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>
Message-ID: <CALRCexvC5q-h8RjGgVTGji5QOQbgbGdSzYjwvJS=OEXBYuFa_Q@mail.gmail.com>

Requiring a space for structural formatting seems wise. I don't believe the
proposal implied that navigational formatting (=>) would require one.

But regarding quotes, although the > prefix may be visually familiar from
text threads its use is inconsistent at best with regard to space before or
after. Requiring a space will definitely break multiply-nested multi-line
things (or make them redundant).

Which brings me to... If quotes are only meant for a single depth, but
represent semantic rather than structural formatting (sourced content,
could reasonably have an author or other meaningful attribution), would it
make more sense to treat them like preformatted lines (line toggled) and
retire the prefix entirely?

If they are really only for visual distinction... Well I guess I don't
think they ought to be.

So as long as you're talking about updating the spec...


Context:

Hi! Long time observer (nearly a week!) first time poster. I hadn't seen
deedum when I first began using my enthusiasm for both classic gopher and a
lighter better secure-er web to begin writing dart/flutter libraries for
Gemini.

I'm a very low vision user and this approach to content is very welcome.
It's been a fun exercise and there still seems to be room for a formal
library on pubget and so forth, and I am imagining a kind conversational
model where browsing and contributing are possible within the same
experience. Anywho...

Things I noticed in this process where I've tried to include robust edge
case tests and simulate workflows that may be common to streamline
anybody's ability to create content:
*  I actually do use # without spaces for headers but nobody else seems to
* Quoted content when visually distinct has more in common with
preformatted content in that, while it can be wrapped and flowed, you're
often quoting something by copy-pasting at which point the original layout
can be relevant
* Many things one might paste with one level of quote include multiple
levels with hideous line breaking
* And so realized I couldn't find many uses for > where ``` wasn't also at
least useful.
* So I began tinkering with a language param for pre that allowed one to
specify more quote-like behavior

I'll share links in a few days when the repo moves from embarrassing to
merely incomplete.


On Thu, Jul 23, 2020, 6:08 PM <colecmac at protonmail.com> wrote:

> > At this point it seems like we may as well go "whole hog" and insist on
> > at least one space after all the line type markers - that would mean
> > quote lines starting with "> " and link lines starting with "=> ". Does
> > anybody object to that?
>
>
> I do sort of object to this. I don't think there's much value in switching
> the other definitions when a need hasn't been demonstrated. I have seen
> many
> links that don't have a space after the "=>", and I don't see why there
> needs to
> be a space after the quote marker either. It's nicer to read in both cases,
> but I'm not in favour of creating changes when they don't seem to be
> required.
>
> Why not just change the heading lines?
>
> Cheers,
> makeworld
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200723/877a78ce/attachment-0001.htm>

From sean at conman.org  Fri Jul 24 01:44:28 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 23 Jul 2020 20:44:28 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <CALRCexvC5q-h8RjGgVTGji5QOQbgbGdSzYjwvJS=OEXBYuFa_Q@mail.gmail.com>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
 <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>
 <CALRCexvC5q-h8RjGgVTGji5QOQbgbGdSzYjwvJS=OEXBYuFa_Q@mail.gmail.com>
Message-ID: <20200724004428.GB32353@brevard.conman.org>

It was thus said that the Great Mad Ogrit once stated:
> Requiring a space for structural formatting seems wise. I don't believe the
> proposal implied that navigational formatting (=>) would require one.
> 
> But regarding quotes, although the > prefix may be visually familiar from
> text threads its use is inconsistent at best with regard to space before or
> after. Requiring a space will definitely break multiply-nested multi-line
> things (or make them redundant).

  The gemtext spec doesn't allow nesting at all, so multply-nested
multi-line things are already a problem (as I found out when trying to
convert HTML to gemtext).

> Which brings me to... If quotes are only meant for a single depth, but
> represent semantic rather than structural formatting (sourced content,
> could reasonably have an author or other meaningful attribution), would it
> make more sense to treat them like preformatted lines (line toggled) and
> retire the prefix entirely?

  No.  My blog (phlog, gemlog) makes extensive use of both <BLOCKQUOTE> and
<PRE> tags.  For instance this post from last year:

	gemini://gemini.conman.org/2019/03/31.1

In the originial HTML (http://boston.conman.org/2019/03/31.1), the format is
something long the lines of:

<BLOCKQUOTE>
  <P>...</P>

  <P>...</P>

</BLOCKQUOTE>

<P>...</P>

<PRE>
...
</PRE>

<P>...</P>

  And while I had to go back quite a bit to find an entry with both a
blockquote and preformatted text, I do use blockquotes and preformatted text
quite often, and they have different semantic meanings.

  That post, by the way, shows how I deal with ordered lists in HTML (when
gemtext only supports a type of unordered list).

> * Quoted content when visually distinct has more in common with
> preformatted content in that, while it can be wrapped and flowed, you're
> often quoting something by copy-pasting at which point the original layout
> can be relevant

  True.  Trying to quote preformatted text is not easy with gemtext.  That's
one of the reasons I still prefer HTML (which Gemini *can* serve, by the
way).

  -spc


From sean at conman.org  Fri Jul 24 01:59:03 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 23 Jul 2020 20:59:03 -0400
Subject: Identifying robots (was Re: Open Source Proxy)
In-Reply-To: <20200723220103.GB186796@goldfish.localdomain>
References: <C4DL97TJDLH0.19501Y7BSP92C@debian-thinkpad>
 <87v9iehz2l.fsf@dorothy.carcosa.net>
 <20200723204549.GA32353@brevard.conman.org>
 <20200723220103.GB186796@goldfish.localdomain>
Message-ID: <20200724005903.GC32353@brevard.conman.org>

It was thus said that the Great Natalie Pendragon once stated:
> For the GUS crawl at least, the crawler doesn't identify itself _to_
> crawled sites, but it does obey blocks of rules in robots.txt files
> according to user-agent. So it works without needing a user-agent
> header.
> 
> It obeys user-agent of `*`, `indexer`, and `gus` in order of
> increasing importance.
> 
> There's been some talk of the generic sorts of user-agents in the
> past, which I think is a really nice idea. If `indexer` is a
> user-agent that both sites and crawlers had some sort of informal
> consensus on, then sites wouldn't need to worry about keeping up with
> any new indexers popping up.
> 
> Some other generic user-agent ideas, iirc, were `archiver` and
> `proxy`.

  That's a decent idea, but that still doesn't help when I want to block a
particular bot for "misbehaving" (in some nebulous way).  For example,
there's this one bot, "The Knowledge AI" which sends requests like

	/%22http:/wesiseli.com/magician/%22 [1]

(and yes, that's an actual example, pulled straight off the log file).  It's
not quite yet annoying enough to block [2] but at least I have some chance
of blocking it via robots.txt (which it does request).  

  -spc

[1]	I can't quite figure out why it includes the quotes as part of the
	link.  *All* the links on my websites look like:

		<a href="http://example.com/">

	and for the most part, it can parse those links correctly.  And
	that's not limited to just *one* bot, but several of them have that
	behavior.

[2]	Although it's nearly impossible to find anything out about it as the
	user-agent string is literally "The Knowledge AI", so it might be
	worth blocking it just out of spite.


From sario528 at gmail.com  Fri Jul 24 02:25:26 2020
From: sario528 at gmail.com (Ryan Knipe)
Date: Thu, 23 Jul 2020 20:25:26 -0500
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
References: <1960255.EdmoDJtqBP@thinkpad-e495>
 <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
Message-ID: <CAGTwfRTtt0oey6W3HbEPOgy1BQsktHz4VHiY9L=AZniVZAUxRA@mail.gmail.com>

I'm on board. It improves human readability, and ensures consistency.

On Thu, Jul 23, 2020, 2:38 PM Solderpunk <solderpunk at posteo.net> wrote:

> Okay, I am happy with this idea (in fact, for a minute or two I was
> thinking "didn't we already do this?!" - no, that was with list items,
> to avoid ambiguity with *this* kind of emphasis).
>
> At this point it seems like we may as well go "whole hog" and insist on
> at least one space after *all* the line type markers - that would mean
> quote lines starting with "> " and link lines starting with "=> ".  Does
> anybody object to *that*?  I strongly suspect that almost everybody is
> actually writing their content that way anyway, but perhaps not...
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200723/be32a321/attachment.htm>

From madogrit0 at gmail.com  Fri Jul 24 15:14:17 2020
From: madogrit0 at gmail.com (Mad Ogrit)
Date: Fri, 24 Jul 2020 10:14:17 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <20200724004428.GB32353@brevard.conman.org>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
 <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>
 <CALRCexvC5q-h8RjGgVTGji5QOQbgbGdSzYjwvJS=OEXBYuFa_Q@mail.gmail.com>
 <20200724004428.GB32353@brevard.conman.org>
Message-ID: <CALRCexuToavQ0rkug4Yd=kpz+NNXSnZEh02i_955RW_OF7_1gA@mail.gmail.com>

On Thu, Jul 23, 2020, 8:44 PM Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great Mad Ogrit once stated:
> > Requiring a space for structural formatting seems wise. I don't believe
> the
> > proposal implied that navigational formatting (=>) would require one.
> >
> > But regarding quotes, although the > prefix may be visually familiar from
> > text threads its use is inconsistent at best with regard to space before
> or
> > after. Requiring a space will definitely break multiply-nested multi-line
> > things (or make them redundant).
>
>   The gemtext spec doesn't allow nesting at all, so multply-nested
> multi-line things are already a problem (as I found out when trying to
> convert HTML to gemtext).
>

Right, so unless I'm willing to manually clean up copy-pasted material I
end up with a bunch of individual lines treated as quote lines that then
also contain superfluous text like >>>, >> > >, and >|>>|.

>
> > Which brings me to... If quotes are only meant for a single depth, but
> > represent semantic rather than structural formatting (sourced content,
> > could reasonably have an author or other meaningful attribution), would
> it
> > make more sense to treat them like preformatted lines (line toggled) and
> > retire the prefix entirely?
>
>   No.  My blog (phlog, gemlog) makes extensive use of both <BLOCKQUOTE> and
> <PRE> tags.  For instance this post from last year:
>
>

Sorry, I think I was being imprecise. I wasn't proposing to not support
quotes as a separate concept from pre, but rather add an additional line
toggle, eg ___ or something unlikely to appear in nominal plaintext, which
would be handled in the same manner as pre - a toggle for blockquote,
allowing for things like:

So I tried
```lang=go
func primes ()...
```
But Hofstadter's paper said
___src=gemini://princip.ia/hoff.gmi?335
Remember to add a terminal case like
```lang=python
def isPrime()...
```
___

(The src= is just a silly example and definitely serves a different purpose
than lang=)

Of course, you made me realize this would significantly complicate the
toggle approach in the case of unmatched toggles overlapping and the
inevitable nesting of alternating toggles.

Come to think of it, I assume that pasting gemtext containing pre inside of
pre toggles would still require some manual editing, for instance to add
white space before the embedded pre. I'm guessing this is why nesting of
any kind is not supported :-)

I haven't fully grokked the archives yet so this may have already been
discussed.

>
>
>   True.  Trying to quote preformatted text is not easy with gemtext.
> That's
> one of the reasons I still prefer HTML (which Gemini *can* serve, by the
> way)
>

My hope with supporting and popularizing gemtext is specifically to
counteract the ways in which HTML has become very easy to make very
inaccessible - even just the semantics of layout and flow. I'm in it to
make and support an accessible client with font sizes I can read /
screen-read no matter what the content is :)

Even markdown, as many things do, has become just this side of easy to make
hard to read and hard to make easy to edit and copy paste universally, so I
do really value the notion of an intrinsic format that is easy to
understand and reliably forward only parse-able.

I originally felt the line toggle approach seemed like an odd burden on the
client given the simplicity and line orientedness of the rest of the
format, but I recognize it has the benefit of not requiring an an author to
touch up content, reducing the barrier to entry of copy paste or generally
including things that are otherwise hard to reformat (eg turn a funky table
into tsv and dump it in pre).

Obviously, the above silly example could just be decomposed into a single
quote line, a single pre-block, and a link. But doing that requires the
person composing this text to think about and do that decomposition
possibly from text that they are simply copy pasting an existing pre-block
in existing  gemtext.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200724/5993b2de/attachment.htm>

From lambdatronic at disroot.org  Fri Jul 24 16:25:09 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 24 Jul 2020 11:25:09 -0400
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <CAGTwfRTtt0oey6W3HbEPOgy1BQsktHz4VHiY9L=AZniVZAUxRA@mail.gmail.com>
References: <1960255.EdmoDJtqBP@thinkpad-e495>
 <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
 <CAGTwfRTtt0oey6W3HbEPOgy1BQsktHz4VHiY9L=AZniVZAUxRA@mail.gmail.com>
Message-ID: <87blk53pgq.fsf@disroot.org>

I also support the "spaces after all line type markers" idea, And I
agree with the other poster (Paper?) that one of gemtext's best
qualities is that it is intrinsically (and intuitively) human-readable
even without rendering. It is, in fact, a totally WYSIWYG format.

Into the future!
  Gary

P.S. Astrobotany is going to need to update its links though...


Ryan Knipe <sario528 at gmail.com> writes:

> I'm on board. It improves human readability, and ensures consistency.
>
> On Thu, Jul 23, 2020, 2:38 PM Solderpunk <solderpunk at posteo.net> wrote:
>
>> Okay, I am happy with this idea (in fact, for a minute or two I was
>> thinking "didn't we already do this?!" - no, that was with list items,
>> to avoid ambiguity with *this* kind of emphasis).
>>
>> At this point it seems like we may as well go "whole hog" and insist on
>> at least one space after *all* the line type markers - that would mean
>> quote lines starting with "> " and link lines starting with "=> ".  Does
>> anybody object to *that*?  I strongly suspect that almost everybody is
>> actually writing their content that way anyway, but perhaps not...
>>
>> Cheers,
>> Solderpunk
>>


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From cage-dev at twistfold.it  Fri Jul 24 17:02:38 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 24 Jul 2020 18:02:38 +0200
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>
References: <C4E96KAD3A6N.3A4HQ52R2JKQW@stilgar>
 <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>
Message-ID: <20200724160238.GA2376@kurosawa.casa.net>

On Thu, Jul 23, 2020 at 10:08:02PM +0000, colecmac at protonmail.com wrote:

Hi!

> > At this point it seems like we may as well go "whole hog" and insist on
> > at least one space after all the line type markers - that would mean
> > quote lines starting with "> " and link lines starting with "=> ". Does
> > anybody object to that?
>
>
> I do sort of object to this. I don't think there's much value in switching
> the other definitions when a need hasn't been demonstrated. I have seen many
> links that don't have a space after the "=>", and I don't see why there needs to
> be a space after the quote marker either. It's nicer to read in both cases,
> but I'm not in favour of creating changes when they don't seem to be required.
>
> Why not just change the heading lines?

This is a good question, let me show my opinion about why i agree with
these changes.

In short  to me, the reason  to put a space  after ">" or "=>"  is the
same that changed  "*" to "*<space>".  If, in a  distant future, a new
convention appears for identify a word, or a text starting with a word
using  ">"  (for   example)  the  gemini  parser  will   steps  in  an
inconvenience  like the  ones we  are discussing  in this  thread with
"#". Because  is (in  my opinion)  unlikely that a  person (i  mean an
human being  :-)) writing a text  that will be read  by other persons,
marks  a word  using a  string prefix  that include  a word  separator
(including space)  after and  before or  in the middle  of it  i think
would be a good  idea change the format to require a  space for any of
the symbols Solderpunk mentioned.

This is, of course, probably not  the only reason to make this changes
(and maybe is not very valid :)) but i can not find any better at this
time! ;D

I hope i was able to explain my point even with my bad English!

Bye!
C.

From sean at conman.org  Sat Jul 25 00:53:56 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 24 Jul 2020 19:53:56 -0400
Subject: Getting slammed by a client
Message-ID: <20200724235356.GD32353@brevard.conman.org>


  Is anyone else getting slammed by 70.113.100.216?  Does anyone know who
this is?  I don't mind my server being used by clients as a test platform,
but making a few hundred requests per second is a bit much.  Also, a bunch
of bogus requests.

  Sigh.

  I don't really want to block it, but whoever is responsible for it is
doing a bad job at parsing URLs and a request of "" is NOT a valid Gemini
request.

  On the plus side, it did flush out a bug in GLV-1.12556, so there's that.

  -spc


From ftrvxmtrx at gmail.com  Sat Jul 25 01:19:53 2020
From: ftrvxmtrx at gmail.com (=?ISO-8859-1?Q?Sigrid_Solveig_Hafl=EDnud=F3ttir?=)
Date: Sat, 25 Jul 2020 02:19:53 +0200
Subject: Getting slammed by a client
In-Reply-To: <20200724235356.GD32353@brevard.conman.org>
References: <20200724235356.GD32353@brevard.conman.org>
Message-ID: <B35AFDE1-F52B-4D17-B3BE-152B9026F434@gmail.com>

On 25 July 2020 01:53:56 CEST, Sean Conner <sean at conman.org> wrote:
>
>Is anyone else getting slammed by 70.113.100.216?  Does anyone know who
>this is?  I don't mind my server being used by clients as a test
>platform,
>but making a few hundred requests per second is a bit much.  Also, a
>bunch
>of bogus requests.
>
>  Sigh.
>
>  I don't really want to block it, but whoever is responsible for it is
>doing a bad job at parsing URLs and a request of "" is NOT a valid
>Gemini
>request.
>
>On the plus side, it did flush out a bug in GLV-1.12556, so there's
>that.
>
>  -spc

Getting that slam as well here.


From colecmac at protonmail.com  Sat Jul 25 01:46:29 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 25 Jul 2020 00:46:29 +0000
Subject: Getting slammed by a client
In-Reply-To: <20200724235356.GD32353@brevard.conman.org>
References: <20200724235356.GD32353@brevard.conman.org>
Message-ID: <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>

Same here, over 1494 requests since Jul 23 17:22:40. It ended
at Jul 24 19:41:05 for me. That's in EST timezone.

And yes, I can confirm the URL parsing was horribly done, approximately
300 of those requests (20%) resulted in 51 NOT FOUND errors, seemingly
all because of incorrectly constructed relative URLs. If this happens
again I will likely ban the IP.

Thanks for bringing this to my/our attention, I wasn't aware of until now.
Do you have some monitoring system in place? How did you find out?

Cheers,
makeworld

From boyd.paul2 at gmail.com  Sat Jul 25 01:54:33 2020
From: boyd.paul2 at gmail.com (Paul Boyd)
Date: Fri, 24 Jul 2020 20:54:33 -0400
Subject: Getting slammed by a client
In-Reply-To: <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>
References: <20200724235356.GD32353@brevard.conman.org>
 <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>
Message-ID: <CABuFWiJKyCOVF4Th_tBq4C0fMy6SNAinnY0ujZQoPz_Z2NgUnQ@mail.gmail.com>

I had a few of these too. Not nearly as many though. Request counts by
minute (UTC):

      3 2020-07-24T18:16
      2 2020-07-24T18:24
      1 2020-07-24T18:27
      1 2020-07-24T19:36
     29 2020-07-24T19:59
      1 2020-07-24T20:00
     22 2020-07-24T23:25
      3 2020-07-24T23:33
      2 2020-07-24T23:34
      1 2020-07-24T23:40
     24 2020-07-24T23:41

On Fri, Jul 24, 2020 at 8:46 PM <colecmac at protonmail.com> wrote:

> Same here, over 1494 requests since Jul 23 17:22:40. It ended
> at Jul 24 19:41:05 for me. That's in EST timezone.
>
> And yes, I can confirm the URL parsing was horribly done, approximately
> 300 of those requests (20%) resulted in 51 NOT FOUND errors, seemingly
> all because of incorrectly constructed relative URLs. If this happens
> again I will likely ban the IP.
>
> Thanks for bringing this to my/our attention, I wasn't aware of until now.
> Do you have some monitoring system in place? How did you find out?
>
> Cheers,
> makeworld
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200724/bdcfa50d/attachment.htm>

From btilley at gatech.edu  Sat Jul 25 02:09:08 2020
From: btilley at gatech.edu (btilley at gatech.edu)
Date: Sat, 25 Jul 2020 01:09:08 +0000
Subject: Getting slammed by a client
In-Reply-To: <B35AFDE1-F52B-4D17-B3BE-152B9026F434@gmail.com>
References: <20200724235356.GD32353@brevard.conman.org>
 <B35AFDE1-F52B-4D17-B3BE-152B9026F434@gmail.com>
Message-ID: <20200725010908.GA52416@beagle.local>

On Sat, Jul 25, 2020 at 02:19:53AM +0200, Sigrid Solveig Hafl?nud?ttir wrote:
> On 25 July 2020 01:53:56 CEST, Sean Conner <sean at conman.org> wrote:
> >
> >Is anyone else getting slammed by 70.113.100.216?  Does anyone know who
> >this is?  I don't mind my server being used by clients as a test
> >platform,
> >but making a few hundred requests per second is a bit much.  Also, a
> >bunch
> >of bogus requests.
> >
> >  Sigh.
> >
> >  I don't really want to block it, but whoever is responsible for it is
> >doing a bad job at parsing URLs and a request of "" is NOT a valid
> >Gemini
> >request.
> >
> >On the plus side, it did flush out a bug in GLV-1.12556, so there's
> >that.
> >
> >  -spc
> 
> Getting that slam as well here.

Same at my gemini server.

Brad

From cmccabe at rawtext.club  Sat Jul 25 02:25:20 2020
From: cmccabe at rawtext.club (cmccabe at rawtext.club)
Date: Sat, 25 Jul 2020 01:25:20 +0000
Subject: Getting slammed by a client
In-Reply-To: <CABuFWiJKyCOVF4Th_tBq4C0fMy6SNAinnY0ujZQoPz_Z2NgUnQ@mail.gmail.com>
References: <20200724235356.GD32353@brevard.conman.org>
 <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>
 <CABuFWiJKyCOVF4Th_tBq4C0fMy6SNAinnY0ujZQoPz_Z2NgUnQ@mail.gmail.com>
Message-ID: <20200725012520.GA463767@rawtext.club>

I had a few too:

      1 2020-07-23T21:13:27Z
      1 2020-07-24T18:16:29Z
     43 2020-07-24T18:16:27Z
     69 2020-07-24T18:16:28Z


On Fri, Jul 24, 2020 at 08:54:33PM -0400, Paul Boyd wrote:
> I had a few of these too. Not nearly as many though. Request counts by
> minute (UTC):
> 
>       3 2020-07-24T18:16
>       2 2020-07-24T18:24
>       1 2020-07-24T18:27
>       1 2020-07-24T19:36
>      29 2020-07-24T19:59
>       1 2020-07-24T20:00
>      22 2020-07-24T23:25
>       3 2020-07-24T23:33
>       2 2020-07-24T23:34
>       1 2020-07-24T23:40
>      24 2020-07-24T23:41
> 
> On Fri, Jul 24, 2020 at 8:46 PM <colecmac at protonmail.com> wrote:
> 
> > Same here, over 1494 requests since Jul 23 17:22:40. It ended
> > at Jul 24 19:41:05 for me. That's in EST timezone.
> >
> > And yes, I can confirm the URL parsing was horribly done, approximately
> > 300 of those requests (20%) resulted in 51 NOT FOUND errors, seemingly
> > all because of incorrectly constructed relative URLs. If this happens
> > again I will likely ban the IP.
> >
> > Thanks for bringing this to my/our attention, I wasn't aware of until now.
> > Do you have some monitoring system in place? How did you find out?
> >
> > Cheers,
> > makeworld
> >

From sean at conman.org  Sat Jul 25 02:26:35 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 24 Jul 2020 21:26:35 -0400
Subject: Getting slammed by a client
In-Reply-To: <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>
References: <20200724235356.GD32353@brevard.conman.org>
 <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>
Message-ID: <20200725012635.GF32353@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> Same here, over 1494 requests since Jul 23 17:22:40. It ended
> at Jul 24 19:41:05 for me. That's in EST timezone.

  You probably didn't have a large site.  Now that I have added 20 years of
blog entries, it only stopped when I finally blocked it at the firewall
about fifteen minutes ago.  230K packets (12M of network traffic) blocked,
and it shows no sign of letting up, which tells me it's not being monitored.

> Thanks for bringing this to my/our attention, I wasn't aware of until now.
> Do you have some monitoring system in place? How did you find out?

  It's rather unorthodox, but I forward my server logs to my home server
(not just Gemini, anything that's logged via syslog()). There, I have a
program that displays the logs in real time and color coded [1][2].  I'm not
*always* watching it, but enough to catch stuff like this.

  Ooh, it's still going, 400k packets, 21M bytes.

  -spc

[1]	I have two systems running, each with their own display.  I run the
	program on both, leaving the window open.  I use said windows as a
	type of "screen saver", but it's also useful to see what's going on
	with both my public server and home systems (ah, six different IP
	addresses tried to log in via SSH---they'll be blocked soon enough).

[2]	The custom syslog system I have is here:

		https://github.com/spc476/syslogintr

	The actual program is

		https://github.com/spc476/syslogintr/blob/master/realtime.lua


From hannu.hartikainen+gemini at gmail.com  Sat Jul 25 09:51:39 2020
From: hannu.hartikainen+gemini at gmail.com (Hannu Hartikainen)
Date: Sat, 25 Jul 2020 11:51:39 +0300
Subject: Getting slammed by a client
In-Reply-To: <20200725012635.GF32353@brevard.conman.org>
References: <20200724235356.GD32353@brevard.conman.org>
 <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>
 <20200725012635.GF32353@brevard.conman.org>
Message-ID: <CANmFPe=aHowoN8rLm1X_5rkHjaSYif7saar39qKWJqKattq05A@mail.gmail.com>

Thanks for pointing this out. I never read logs if everything works, so...

I'm getting lots of requests to urls like
gemini://hannuhartikainen.fi/twinwiki/Welcome,%20visitors%21/twinwiki/Welcome%252C%2520visitors%2521/_history/twinwiki/_edit/twinwiki/_create/twinwiki/_create/twinwiki/_help/twinwiki/_help/twinwiki/_index/twinwiki/_edit/twinwiki/_history/twinwiki/_edit/twinwiki/_create/twinwiki/_help/twinwiki/_history/twinwiki/_help/twinwiki/_create/twinwiki/_history/twinwiki/_history/twinwiki/_history/twinwiki/_create/twinwiki/_create/twinwiki/_index/twinwiki/_history/twinwiki/_edit/twinwiki/_edit/twinwiki/_history/twinwiki/_help/twinwiki/_help/twinwiki/_history/twinwiki/_create/twinwiki/_help/twinwiki/_edit/twinwiki/_index/twinwiki/_history

Oops, I've written bugs once again! I do have this robots.txt, though:

User-agent: gus
Allow: /

User-agent: *
Disallow: /

(I guess I should disallow even gus from twinwiki, or at least any
non-content pages.)

The crawler also breaks ansi.hrtk.in for other users while crawling
(which disallows even gus in robots.txt). I couldn't figure out how to
make Jetforce stop streaming if the client closes connection. The code
is here if someone has pointers:
https://github.com/dancek/ansimirror/blob/master/ansimirror.py

Anyone have experience fighting misbehaving crawlers? Should we
develop low-resource honeypots to exhaust crawler resources? Or start
maintaining a community blacklist?

-Hannu

From martin at no.ucant.org  Sat Jul 25 10:18:27 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sat, 25 Jul 2020 10:18:27 +0100 (BST)
Subject: Getting slammed by a client
In-Reply-To: <CANmFPe=aHowoN8rLm1X_5rkHjaSYif7saar39qKWJqKattq05A@mail.gmail.com>
References: <20200724235356.GD32353@brevard.conman.org>
 <hH0GxBmKiY6Fdr1BqoxQMuhhqoOWCfq6ON6xO_MNVqRV8CLD312c8ccj0YAW_SFdKtYgmB-GkP0X6hwi8C6VLoy5QLuPpBybqUFx8R59QwM=@protonmail.com>
 <20200725012635.GF32353@brevard.conman.org>
 <CANmFPe=aHowoN8rLm1X_5rkHjaSYif7saar39qKWJqKattq05A@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2007251013110.16057@pling.qwghlm.org>

On Sat, 25 Jul 2020, Hannu Hartikainen wrote:

> Should we develop low-resource honeypots to exhaust crawler resources? 
> Or start maintaining a community blacklist?

I'd start with hardening Gemini servers ...

The server I've written has a bunch of hard limits (in particular, on the 
duration of requests and the number of concurrent CGI processes). It might 
be advisable to add some more back-pressure for the case where user-agents 
are generating obviously redundant requests to an excessive degree. I'd 
put that before trying honeypots and blacklists.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From julien at typed-hole.org  Sat Jul 25 10:32:00 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 25 Jul 2020 11:32:00 +0200
Subject: Getting slammed by a client
In-Reply-To: <20200724235356.GD32353@brevard.conman.org>
Message-ID: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>

Got a little more than 9K requests in a few hours from this IP, at least
it's good to know that my server on a Pi Zero handled this "load"
gracefully.

From mojibake at riseup.net  Sat Jul 25 11:14:42 2020
From: mojibake at riseup.net (mojibake)
Date: Sat, 25 Jul 2020 11:14:42 +0100
Subject: Getting slammed by a client
In-Reply-To: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>
References: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>
Message-ID: <f99c1df9-2d15-c17f-aed9-d86c675a25bc@riseup.net>

Thanks for flagging - also getting slammed by this IP.

If anyone has any decent automated methods for picking up and banning this traffic from gemini servers, plz share. I wonder if it's possible to configure a fail2ban jail for gemini servers? Anyone tried this? I'm not familiar enough with the server-side yet to know how I might go about this.

On 25/07/2020 10:32, Julien Blanchard wrote:
> Got a little more than 9K requests in a few hours from this IP, at least
> it's good to know that my server on a Pi Zero handled this "load"
> gracefully.

From alex at gnu.org  Sat Jul 25 14:32:09 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sat, 25 Jul 2020 15:32:09 +0200
Subject: Getting slammed by a client
In-Reply-To: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>
References: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>
Message-ID: <608eb4f13d0720d9552c05488b380786b544e02d.camel@gnu.org>

(Resending because it seems that my mail disappeared somewhere.)

2200 hits in the last few days...

I'm going to setup a fail2ban rule.  Adapt the datepattern to your
logfiles. Basically any successful connection counts as "a failed login
attempt". Of these, you may have 20 in a 40s time window, which is what
I think is a reasonable upper limit for humans and bots. If you're
crawling the site faster than that, you get banned for 10min by the
firewall.


/etc/fail2ban/jail.d/alex.conf:

[alex-gemini]
enabled = true
port    = 1965
logpath = /home/alex/farm/gemini-wiki.log
findtime = 40
maxretry = 20


/etc/fail2ban/filter.d/alex-gemini.conf:

[Init]
# 2018/08/25-09:08:55 CONNECT TCP Peer: "[000.000.000.000]:56281"
Local: "[000.000.000.000]:70"
datepattern = ^%%Y/%%m/%%d-%%H:%%M:%%S

[Definition]
# ANY match in the logfile counts!
failregex = CONNECT TCP Peer: "\[<HOST>\]:\d+"


I also activated the recidive rule in fail2ban. This means that people
who get banned by fail2ban repeatedly get banned for even longer times
(hours instead of minutes). This is in the first file again:


/etc/fail2ban/jail.d/alex.conf:

[recidive]
enabled = true


I use this system for my websites, my gopher sites, and now for gemini,
too.

Cheers
Alex







From solderpunk at posteo.net  Sat Jul 25 15:52:48 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 25 Jul 2020 16:52:48 +0200
Subject: Getting slammed by a client
In-Reply-To: <alpine.DEB.2.20.2007251013110.16057@pling.qwghlm.org>
Message-ID: <C4FSGKGVZTTJ.2XODX0FNUY2YC@stilgar>

And my axe!

Errm, by which I mean, yes, gemini.circumlunar.space has not been left
out of this and I've seen just over 3,000 requests from that IP.

On Sat Jul 25, 2020 at 11:18 AM CEST, Martin Keegan wrote:

> I'd start with hardening Gemini servers ...

Yes, indeed.  The spec does have a status code (44) meaning "slow down!"
intended to allow machine-readable communication of a rate limiting
policy to bots.  Of course, it can be ignored by malicious bots, but it
should help against well-meaning but incompetent bots.  And, if nothing
else, serving up code 44 with no response body over and over again
rather than serving up actual resources should spare the server some
traffic, and also might slow down discovery of new URLs to hit by an
overactive crawler.

Anyway, to the best of my knowledge no server actually implements a rate
limiting scheme using this status code, but I suppose the time has come,
as it inevitably would.  Posts like this one have been common for years
on the gopher mailing list, which is precisely the reason I added such a
status code.  Let's see if it helps any...

Cheers,
Solderpunk

From solderpunk at posteo.net  Sat Jul 25 16:04:40 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 25 Jul 2020 17:04:40 +0200
Subject: Identifying robots (was Re: Open Source Proxy)
In-Reply-To: <20200723220103.GB186796@goldfish.localdomain>
Message-ID: <C4FSPNJXOE4U.3MZ79MYFSAQ51@stilgar>

On Fri Jul 24, 2020 at 12:01 AM CEST, Natalie Pendragon wrote:

> There's been some talk of the generic sorts of user-agents in the
> past, which I think is a really nice idea. If `indexer` is a
> user-agent that both sites and crawlers had some sort of informal
> consensus on, then sites wouldn't need to worry about keeping up with
> any new indexers popping up.
>
> Some other generic user-agent ideas, iirc, were `archiver` and
> `proxy`.

I still really like this idea.  It will be a long and tedious
undertaking to build up some kind of rough consensus on a set of
user-agents with good coverage and granularity of different scenarios,
but I think it might be worth the effort.

It would be great to finally get a proper "robots.txt for Gemini" side
spec written up.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sat Jul 25 16:06:49 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 25 Jul 2020 17:06:49 +0200
Subject: Identifying robots (was Re: Open Source Proxy)
In-Reply-To: <20200724005903.GC32353@brevard.conman.org>
Message-ID: <C4FSRAUYYOBX.HUGGN9LPC2BH@stilgar>

On Fri Jul 24, 2020 at 2:59 AM CEST, Sean Conner wrote:

> That's a decent idea, but that still doesn't help when I want to block a
> particular bot for "misbehaving" (in some nebulous way).

This is true, but at the end of the day, even if we had a user-agent
header, a badly written bot can always ignore robots.txt, or request
robots.txt and parse/respect it incorrectly, or just regularly change
its user-agent to evade restrictions.  There will *always* be scenarios
where admins simply have to resort to IP bans.  Gemini just bumps into
those scenarios slightly sooner than the web.

Some kind of official documentation on how to write good bots would
probably not go astray...

Cheers,
Solderpunk

From solderpunk at posteo.net  Sat Jul 25 16:30:40 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 25 Jul 2020 17:30:40 +0200
Subject: [SPECS text/gemini] Heading lines proposal
In-Reply-To: <6cMZiJtzHy3OHQHWg_a5drkQvOP7MXK4fcCASg6IMSWl71Med5svVcdQgedcA5uvQo7CGjnuWiaOvhty6g77xFAusuti2qqJtQtvXZLs4yk=@protonmail.com>
Message-ID: <C4FT9K3M2TAW.KNM5L566Q2YC@stilgar>

On Fri Jul 24, 2020 at 12:08 AM CEST,  wrote:

> Why not just change the heading lines?

I guess my main motivation was to make the spec more regular/consistent.
If half the line type markers require a space and half of them don't,
writing an correct client requires constant reference back to the spec
to double check these fine details.  Ideally Gemini should "fit in your
head" easily, as somebody else described it, and consistency goes a long
way toward that.

Cheres,
Solderpunk

From mojibake at riseup.net  Sat Jul 25 17:06:42 2020
From: mojibake at riseup.net (mojibake)
Date: Sat, 25 Jul 2020 17:06:42 +0100
Subject: Getting slammed by a client
In-Reply-To: <608eb4f13d0720d9552c05488b380786b544e02d.camel@gnu.org>
References: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>
 <608eb4f13d0720d9552c05488b380786b544e02d.camel@gnu.org>
Message-ID: <732f7eca-c72c-340f-8b5e-e73572f10eb0@riseup.net>

That's great - Thanks Alex. Will try this.

On 25/07/2020 14:32, Alex Schroeder wrote:
> (Resending because it seems that my mail disappeared somewhere.)
>
> 2200 hits in the last few days...
>
> I'm going to setup a fail2ban rule.  Adapt the datepattern to your
> logfiles. Basically any successful connection counts as "a failed login
> attempt". Of these, you may have 20 in a 40s time window, which is what
> I think is a reasonable upper limit for humans and bots. If you're
> crawling the site faster than that, you get banned for 10min by the
> firewall.
>
>
> /etc/fail2ban/jail.d/alex.conf:
>
> [alex-gemini]
> enabled = true
> port    = 1965
> logpath = /home/alex/farm/gemini-wiki.log
> findtime = 40
> maxretry = 20
>
>
> /etc/fail2ban/filter.d/alex-gemini.conf:
>
> [Init]
> # 2018/08/25-09:08:55 CONNECT TCP Peer: "[000.000.000.000]:56281"
> Local: "[000.000.000.000]:70"
> datepattern = ^%%Y/%%m/%%d-%%H:%%M:%%S
>
> [Definition]
> # ANY match in the logfile counts!
> failregex = CONNECT TCP Peer: "\[<HOST>\]:\d+"
>
>
> I also activated the recidive rule in fail2ban. This means that people
> who get banned by fail2ban repeatedly get banned for even longer times
> (hours instead of minutes). This is in the first file again:
>
>
> /etc/fail2ban/jail.d/alex.conf:
>
> [recidive]
> enabled = true
>
>
> I use this system for my websites, my gopher sites, and now for gemini,
> too.
>
> Cheers
> Alex
>
>
>
>
>
>

From alex at gnu.org  Sat Jul 25 11:34:25 2020
From: alex at gnu.org (Alex Schroeder)
Date: Sat, 25 Jul 2020 12:34:25 +0200
Subject: Getting slammed by a client
In-Reply-To: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>
References: <C4FLMXTHWXFT.2GWMECKT38OG1@t495.typed-hole.org>
Message-ID: <6cd24f19e5dd59cb10f767f80bc4d608a113fa7a.camel@gnu.org>

2200 hits in the last few days...

I'm going to setup a fail2ban rule.  Adapt the datepattern to your
logfiles. Basically any successful connection counts as "a failed login
attempt". Of these, you may have 20 in a 40s time window, which is what
I think is a reasonable upper limit for humans and bots. If you're
crawling the site faster than that, you get banned for 10min by the
firewall.


/etc/fail2ban/jail.d/alex.conf:

[alex-gemini]
enabled = true
port    = 1965
logpath = /home/alex/farm/gemini-wiki.log
findtime = 40
maxretry = 20


/etc/fail2ban/filter.d/alex-gemini.conf:

[Init]
# 2018/08/25-09:08:55 CONNECT TCP Peer: "[000.000.000.000]:56281"
Local: "[000.000.000.000]:70"
datepattern = ^%%Y/%%m/%%d-%%H:%%M:%%S

[Definition]
# ANY match in the logfile counts!
failregex = CONNECT TCP Peer: "\[<HOST>\]:\d+"


I also activated the recidive rule in fail2ban. This means that people
who get banned by fail2ban repeatedly get banned for even longer times
(hours instead of minutes). This is in the first file again:


/etc/fail2ban/jail.d/alex.conf:

[recidive]
enabled = true


I use this system for my websites, my gopher sites, and now for gemini,
too. The attached image shows what this looks like over time, using
Munin. As you can see, almost all the bans are due to the websites.

Cheers
Alex




-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image-X1D7N0.png
Type: image/png
Size: 36409 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200725/b32ea25d/attachment-0001.png>

From colecmac at protonmail.com  Sun Jul 26 00:55:14 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 25 Jul 2020 23:55:14 +0000
Subject: Getting slammed by a client
In-Reply-To: <C4FSGKGVZTTJ.2XODX0FNUY2YC@stilgar>
References: <C4FSGKGVZTTJ.2XODX0FNUY2YC@stilgar>
Message-ID: <SofgPdwN5UNKemblMAJm7As1YLOV5f8FiOcaTSN6YPORnmqi38DqWfWUqVnXx_s1BNaXa5aYmyT2OJPmET3a4ru6EUzETOtuJiY8yruBccw=@protonmail.com>

Solderpunk wrote:

> > I'd start with hardening Gemini servers ...
>
> [...]
>
> Anyway, to the best of my knowledge no server actually implements a rate
> limiting scheme using this status code, but I suppose the time has come,
> as it inevitably would.

I have filed a Jetforce issue to add this feature.

https://github.com/michael-lazar/jetforce/issues/39

I'd be happy to see it in Molly Brown as well, and lots of other Gemini
servers!


makeworld


From sean at conman.org  Sun Jul 26 02:02:29 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 25 Jul 2020 21:02:29 -0400
Subject: Getting slammed by a client
In-Reply-To: <20200724235356.GD32353@brevard.conman.org>
References: <20200724235356.GD32353@brevard.conman.org>
Message-ID: <20200726010229.GH32353@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
>   Is anyone else getting slammed by 70.113.100.216?  Does anyone know who
> this is?  I don't mind my server being used by clients as a test platform,
> but making a few hundred requests per second is a bit much.  Also, a bunch
> of bogus requests.

  Okay, I was able to track down the party responsible.  I won't go into how
I did, or who they are because I don't want anyone piling up on the party
responsible.  I sent a message to said party about the issues, and
hopefully, I should hear a resonse back, or at the very least, the issues
will be resolved silently.

  -spc


From cadey at firemail.cc  Sun Jul 26 20:27:21 2020
From: cadey at firemail.cc (Cadey Alicia Ratio)
Date: Sun, 26 Jul 2020 15:27:21 -0400
Subject: [ANN] A new flight journal! gemini://cetacean.club
Message-ID: <C4GSXBEX9413.214SG1XDM435S@shachi>

Hi all,

I've been hacking at gemini for a day or two and have decided to put my
own flight journal up at gemini://cetacean.club. I plan to have this be
more of a diary than my other blog https://christine.website/blog. Right
now it's being served using https://github.com/mbrubeck/agate, but I'm
working on making my own server based on a framework I'm building called
maj (https://tulpa.dev/cadey/maj). I also have a sketch of a curses
client I'm calling majc for now. You can find out more about it at
gemini://cetacean.club/maj/majc.gmi. It's currently pre-alpha, but
things are being implemented quickly.

I may also do some other fun things like making a gitea->gemini gateway,
but that will come in time.

The gemini protocol really can be implemented in the span of a weekend!

Really excited to be joining the community, I hope to help out how I
can!

Cadey Ratio
gemini://cetacean.club

From jmcbray at carcosa.net  Sun Jul 26 21:54:32 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Sun, 26 Jul 2020 16:54:32 -0400
Subject: [ANN] A new flight journal! gemini://cetacean.club
In-Reply-To: <C4GSXBEX9413.214SG1XDM435S@shachi> (Cadey Alicia Ratio's message
 of "Sun, 26 Jul 2020 15:27:21 -0400")
References: <C4GSXBEX9413.214SG1XDM435S@shachi>
Message-ID: <87a6zmj8tz.fsf@dorothy.carcosa.net>

"Cadey Alicia Ratio" <cadey at firemail.cc> writes:

> Really excited to be joining the community, I hope to help out how I
> can!

Welcome aboard!

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From petite.abeille at gmail.com  Mon Jul 27 06:13:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 27 Jul 2020 07:13:05 +0200
Subject: Getting slammed by a client
In-Reply-To: <20200726010229.GH32353@brevard.conman.org>
References: <20200724235356.GD32353@brevard.conman.org>
 <20200726010229.GH32353@brevard.conman.org>
Message-ID: <E50084BC-919C-46D2-A2F6-A336F37C1B59@gmail.com>



> On Jul 26, 2020, at 03:02, Sean Conner <sean at conman.org> wrote:
> 
> Okay, I was able to track down the party responsible.  

Well done! :)

From cadey at firemail.cc  Tue Jul 28 02:52:59 2020
From: cadey at firemail.cc (Cadey Alicia Ratio)
Date: Mon, 27 Jul 2020 21:52:59 -0400
Subject: [ANN] majc 0.2.0
Message-ID: <C4HVR4OJEDEC.3FL42Z8GCC533@shachi>

Hi all,

I have been working on a little gemini client and server framework in Rust I'm calling Maj[0]. One of the big parts of writing this has been to make a fancy curses frontend using a Rust package called cursive. I believe I have made something that could be considered somewhat stable called majc[1]. I have created an installable .deb version of majc[2] and am hosting it on a machine of mine. Please do let me know how it works out for you. It's a bit rough around the edges at the moment, but software that was hacked into existence over the span of a weekend tends to be rough like that.

I am working more on the server framework for Maj, and currently pass all the server torture tests[3] that I care to support. I'm still trying to get client certificate authentication working with rustls, but the async-tls adaptor doesn't easily expose the certficate chain of TLS clients.

Anyways, thanks much for being around and I hope I can give back as much as I have been given.

Be well,

Cadey Alicia Ratio
gemini://cetacean.club

=> gemini://cetacean.club/maj [0] - Maj
=> gemini://cetacean.club/maj/majc [1] - majc Homepage
=> https://xena.greedo.xeserv.us/pkg/maj/majc_0.2.0_amd64.deb [2] majc_0.2.0_amd64.deb
=> https://github.com/michael-lazar/gemini-diagnostics [3] Gemini Diagnostics

From matt at going-flying.com  Wed Jul 29 15:03:34 2020
From: matt at going-flying.com (Matthew Ernisse)
Date: Wed, 29 Jul 2020 10:03:34 -0400
Subject: [ANN] New Gemini capsule(?) at going-flying.com
Message-ID: <20200729140334.GA1281@ub3rgeek.net>

Greetings!
	I'd like to announce my new Gemini capsule: going-flying.com.
I'm not 100% sure what is going to ultimatly live there.  There is currently
a mirror of what passes for my microblog and the beginning of a gemlog
along with a couple novelty toys that I'll encourage visitors to discover.

=> gemini://going-flying.com/

There is also an atom feed available.

=> gemini://going-flying.com/~mernisse/atom.xml

Feedback is always welcome, and thank you to the hard work of those behind
the Gemini protocol and this community.  I've already had more fun building
this than I can remember having doing webstuff in ages.

--Matt

-- 
Matthew Ernisse
matt at going-flying.com
http://www.going-flying.com/

From hello at matthewgraybosch.com  Wed Jul 29 15:38:37 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 29 Jul 2020 10:38:37 -0400
Subject: [ANN] New Gemini capsule(?) at going-flying.com
In-Reply-To: <20200729140334.GA1281@ub3rgeek.net>
References: <20200729140334.GA1281@ub3rgeek.net>
Message-ID: <20200729103837.3840cd16@kether.phoenix.society>

On Wed, 29 Jul 2020 10:03:34 -0400
Matthew Ernisse <matt at going-flying.com> wrote:

> Greetings!
> 	I'd like to announce my new Gemini capsule: going-flying.com.
> I'm not 100% sure what is going to ultimatly live there.  There is
> currently a mirror of what passes for my microblog and the beginning
> of a gemlog along with a couple novelty toys that I'll encourage
> visitors to discover.
> 
> => gemini://going-flying.com/  

Congratulations on launching your capsule.

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>	gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From solderpunk at posteo.net  Wed Jul 29 18:29:08 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Wed, 29 Jul 2020 19:29:08 +0200
Subject: [ANN] New Gemini capsule(?) at going-flying.com
In-Reply-To: <20200729140334.GA1281@ub3rgeek.net>
Message-ID: <C4JAAFXOS0RT.3A70Q81Y3IPMZ@stilgar>

On Wed Jul 29, 2020 at 4:03 PM CEST, Matthew Ernisse wrote:
> Greetings!
> I'd like to announce my new Gemini capsule: going-flying.com.
> I'm not 100% sure what is going to ultimatly live there. There is
> currently
> a mirror of what passes for my microblog and the beginning of a gemlog
> along with a couple novelty toys that I'll encourage visitors to
> discover.
>
> => gemini://going-flying.com/
>
> There is also an atom feed available.
>
> => gemini://going-flying.com/~mernisse/atom.xml

Welcome to Geminispace!  I've added your feed to the CAPCOM generator.
Don't forget to submit your URL to gus.guru, if you haven't already!

Cheers,
Solderpunk

From jake at rmgr.dev  Fri Jul 31 02:57:18 2020
From: jake at rmgr.dev (Jake)
Date: Fri, 31 Jul 2020 01:57:18 +0000
Subject: [ANN] GemRing - A webring for the Gemini protocol
Message-ID: <5zcnhxFP_6DIwm12QhbDlEZLHMguGET02iucIVIiB1JkGtX4WRihGHXYNczctYOLREk-WDjw4G46aTwaB-OQoBHFkX5U_9_ySzBJ8PrM5vs=@rmgr.dev>

Hi all,

I'm new around here, I've been playing with the protocol for a few days. I sort of miss the webrings of the late 90s early 00s so I decided to try my hand at putting one together. I'd love some feedback on my code (this is my first foray in to Python sockets so I'm sure there's a variety of things I could do better). If anybody would like to join a gemring, send me a link and I'll add you to the list and give you a forward/backwards link to put on your capsule.

=> gemini://gem.rmgr.dev/blog/2020-07-31-ann-gemring.gmi Announcing Gemring
=> gemini://gem.rmgr.dev/files/gemring.py Gemring.py

jake/rmgr
gemini://gem.rmgr.dev

From hello at matthewgraybosch.com  Fri Jul 31 03:10:53 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 30 Jul 2020 22:10:53 -0400
Subject: [ANN] GemRing - A webring for the Gemini protocol
In-Reply-To: <5zcnhxFP_6DIwm12QhbDlEZLHMguGET02iucIVIiB1JkGtX4WRihGHXYNczctYOLREk-WDjw4G46aTwaB-OQoBHFkX5U_9_ySzBJ8PrM5vs=@rmgr.dev>
References: <5zcnhxFP_6DIwm12QhbDlEZLHMguGET02iucIVIiB1JkGtX4WRihGHXYNczctYOLREk-WDjw4G46aTwaB-OQoBHFkX5U_9_ySzBJ8PrM5vs=@rmgr.dev>
Message-ID: <20200730221053.4bd5d3fc@kether.phoenix.society>

On Fri, 31 Jul 2020 01:57:18 +0000
Jake <jake at rmgr.dev> wrote:

> Hi all,
> 
> I'm new around here, I've been playing with the protocol for a few
> days. I sort of miss the webrings of the late 90s early 00s so I
> decided to try my hand at putting one together. I'd love some
> feedback on my code (this is my first foray in to Python sockets so
> I'm sure there's a variety of things I could do better). If anybody
> would like to join a gemring, send me a link and I'll add you to the
> list and give you a forward/backwards link to put on your capsule.

This is a cool idea, and if there's a scifi-themed gemring I'd love to
see starbreaker.org on it. It's where I've been putting all of my old
science fantasy writing from the 2010s.

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>	gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From hello at matthewgraybosch.com  Fri Jul 31 05:40:39 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 31 Jul 2020 00:40:39 -0400
Subject: [ANN] New Gemini Site
Message-ID: <20200731004039.2f2942e0@kether.phoenix.society>

I've got another gemini site on tanelorn.city at
<gemini://tanelorn.city/~matthew/>. It's where I'll share material I'm
willing to admit to writing at my day job. :)

The feed for my gemlog is at
<gemini://tanelorn.city/~matthew/posts/atom.xml>.

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>	gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From linde.philip at gmail.com  Fri Jul 31 09:30:36 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 31 Jul 2020 10:30:36 +0200
Subject: Reopening: Stream status code
In-Reply-To: <5F137221.70404@marmaladefoo.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
 <5F137221.70404@marmaladefoo.com>
Message-ID: <20200731103036.8bb01d824af49461c2735fe3@gmail.com>

On Sat, 18 Jul 2020 23:05:21 +0100
Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> I would be against this - it would be a radical change from the existing 
> spec - section 1.1 says that the server closes the connection. At 
> present we have a simple model - client request-> server response and 
> close. Would it be an optional status code that some clients accept and 
> others reject (in which case it would seem to violate that you can just 
> check the first digit of the status).

I agree that this is a radical change. I think other protocols largely
cover potential use cases for indefinite text/gemini responses, and
Gemini can by design concede such functionality to other software via
e.g. ircs/ssh URLs instead of creating an additional burden on Gemini
client implementations.

A quite opposite change I'd much rather see, however radical, is some
kind of required content length indicator in the header, but I'm also
willing to hear what use cases people are envisioning for streaming
responses. There has been talk about whether it can be done, and AFAIK
a sort of half-IRC to demonstrate that it indeed works in some clients
as a side effect of their design, but I haven't heard of a really
compelling use case yet.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/90f59c9b/attachment.sig>

From gmym at coopdot.com  Fri Jul 31 11:03:42 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Fri, 31 Jul 2020 12:03:42 +0200
Subject: Reopening: Stream status code
In-Reply-To: <20200731103036.8bb01d824af49461c2735fe3@gmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
 <5F137221.70404@marmaladefoo.com>
 <20200731103036.8bb01d824af49461c2735fe3@gmail.com>
Message-ID: <CAObwWNg-rtM-rA0QdqPq9pSbP_oazk33XNxigDxykARMM0HzVQ@mail.gmail.com>

Philip Linde <linde.philip at gmail.com> wrote:

> A quite opposite change I'd much rather see, however radical, is some
> kind of required content length indicator in the header,
>

Are you proposing adding content lenght to the MIME type? That has been
rejected every time the topic has come up and has led to the discussion of
alternative ways to communicate such meta data.

The point is to not have an extendable header.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/8f419cf3/attachment.htm>

From linde.philip at gmail.com  Fri Jul 31 11:25:20 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 31 Jul 2020 12:25:20 +0200
Subject: Reopening: Stream status code
In-Reply-To: <CAObwWNg-rtM-rA0QdqPq9pSbP_oazk33XNxigDxykARMM0HzVQ@mail.gmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
 <5F137221.70404@marmaladefoo.com>
 <20200731103036.8bb01d824af49461c2735fe3@gmail.com>
 <CAObwWNg-rtM-rA0QdqPq9pSbP_oazk33XNxigDxykARMM0HzVQ@mail.gmail.com>
Message-ID: <20200731122520.3229d780fe045ee0c8145fe9@gmail.com>

On Fri, 31 Jul 2020 12:03:42 +0200
Katarina Eriksson <gmym at coopdot.com> wrote:
> Are you proposing adding content lenght to the MIME type? That has been
> rejected every time the topic has come up and has led to the discussion of
> alternative ways to communicate such meta data.

No, I'm suggesting in general a protocol-level way of communicating in
advance how many bytes will follow the header. I am not aware that MIME
types can be used for that purpose.

> The point is to not have an extendable header.

The header needn't be extensible to support this. It could be a
required part of the header (my original thinking, hence admitting that
this is quite a radical change) or it could be optional in the same way
that the MIME type is optional (which would not be nearly as useful and
probably would still break a fair amount of existing clients, but
would at least not require a change on servers).

The purpose would be to give clients some information that can serve as
a basis for timeout heuristics, when to close connections to misbehaving
servers and the means for a client to separate early close from
intentional end-of-document.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/f9fdbbf3/attachment-0001.sig>

From boyd.paul2 at gmail.com  Fri Jul 31 12:01:10 2020
From: boyd.paul2 at gmail.com (Paul Boyd)
Date: Fri, 31 Jul 2020 07:01:10 -0400
Subject: Reopening: Stream status code
In-Reply-To: <20200731122520.3229d780fe045ee0c8145fe9@gmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
 <5F137221.70404@marmaladefoo.com>
 <20200731103036.8bb01d824af49461c2735fe3@gmail.com>
 <CAObwWNg-rtM-rA0QdqPq9pSbP_oazk33XNxigDxykARMM0HzVQ@mail.gmail.com>
 <20200731122520.3229d780fe045ee0c8145fe9@gmail.com>
Message-ID: <CABuFWiKGLTK-dmL4Q27zZy5Ncpo3eEWabhWhyuNmz0cXJ+9Q1Q@mail.gmail.com>

Please don't. That would complicate generated responses. The server would
have to hold the response until the whole thing was rendered just to count
the number of bytes. It's a lot simpler to write the data as it's ready,
which also avoids (potentially large) temporary memory allocations.

Paul

On Fri, Jul 31, 2020, 6:34 AM Philip Linde <linde.philip at gmail.com> wrote:

> On Fri, 31 Jul 2020 12:03:42 +0200
> Katarina Eriksson <gmym at coopdot.com> wrote:
> > Are you proposing adding content lenght to the MIME type? That has been
> > rejected every time the topic has come up and has led to the discussion
> of
> > alternative ways to communicate such meta data.
>
> No, I'm suggesting in general a protocol-level way of communicating in
> advance how many bytes will follow the header. I am not aware that MIME
> types can be used for that purpose.
>
> > The point is to not have an extendable header.
>
> The header needn't be extensible to support this. It could be a
> required part of the header (my original thinking, hence admitting that
> this is quite a radical change) or it could be optional in the same way
> that the MIME type is optional (which would not be nearly as useful and
> probably would still break a fair amount of existing clients, but
> would at least not require a change on servers).
>
> The purpose would be to give clients some information that can serve as
> a basis for timeout heuristics, when to close connections to misbehaving
> servers and the means for a client to separate early close from
> intentional end-of-document.
>
> --
> Philip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/3bd836d8/attachment.htm>

From luke at marmaladefoo.com  Fri Jul 31 12:03:53 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 31 Jul 2020 12:03:53 +0100
Subject: [ANN] html2gemini and html2gmi-cli - A Go library and app for
 converting HTML to Gemini
Message-ID: <5F23FA99.7030704@marmaladefoo.com>

Hi Everyone

2 Gemini software announcements here, but they are related.

You can use them as-is, for example for file conversion or dual 
web/gemini publishing.

Or if you are consuming HTML from the internet, you might want to 
simplify the HTML first using Readability or other HTML simplifying 
libraries to remove extraneous navigational cruft.

Bug fixes and improvement suggestions welcomed.

Best Wishes

  - Luke

__________

# html2gemini - A Go library to convert HTML to text/gemini

I've forked and adapted an existing Go library html2text which outputs a 
flavour of markdown so that it instead outputs text/gemini. Main features:

- heading levels, bullets, blockquote, preformatted content
- links done using embedded numeric citations and gemini links
- tables prettified and wrapped in preformatted text

   https://github.com/LukeEmmet/html2gemini

__________

# html2gmi-cli - A command line app to convert HTML to text/gemini files

A simple command line application wrapping the html2gemini library you 
can put into your command line workflows.

   https://github.com/LukeEmmet/html2gmi-cli

From linde.philip at gmail.com  Fri Jul 31 12:18:58 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 31 Jul 2020 13:18:58 +0200
Subject: Reopening: Stream status code
In-Reply-To: <CABuFWiKGLTK-dmL4Q27zZy5Ncpo3eEWabhWhyuNmz0cXJ+9Q1Q@mail.gmail.com>
References: <_Rz4G0DrIJ1Fv8KDNg2aMa09EY7MYJfuracWOg_HeH1uocfio3lx_sa1kOI4jZzbH0hN5qC1aVraNVgPEKeGEu_swC13w2QMf9RtTohwGdk=@protonmail.com>
 <5F137221.70404@marmaladefoo.com>
 <20200731103036.8bb01d824af49461c2735fe3@gmail.com>
 <CAObwWNg-rtM-rA0QdqPq9pSbP_oazk33XNxigDxykARMM0HzVQ@mail.gmail.com>
 <20200731122520.3229d780fe045ee0c8145fe9@gmail.com>
 <CABuFWiKGLTK-dmL4Q27zZy5Ncpo3eEWabhWhyuNmz0cXJ+9Q1Q@mail.gmail.com>
Message-ID: <20200731131858.b3ee7b72acca87fc88290b7f@gmail.com>

On Fri, 31 Jul 2020 07:01:10 -0400
Paul Boyd <boyd.paul2 at gmail.com> wrote:
> Please don't. That would complicate generated responses. The server would
> have to hold the response until the whole thing was rendered just to count
> the number of bytes. It's a lot simpler to write the data as it's ready,
> which also avoids (potentially large) temporary memory allocations.

That is true. There are approaches to dynamically generated responses
that avoid the need for preallocation, but they are indeed quite
complex compared to having e.g. a CGI script simply dump some data on
its standard output.

Usually, when I need to determine a buffer size in advance, I implement
a "dry run" of whatever fills the buffer that instead of writing
anything simply tallies up the number of bytes that *would* be written
and run that to determine the size of the buffer before a "real" run. A
similar approach can be used to determine content length for CGI
scripts.

It's a good point nonetheless.

--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/7856c218/attachment.sig>

From hello at matthewgraybosch.com  Fri Jul 31 14:34:03 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 31 Jul 2020 09:34:03 -0400
Subject: [ANN] html2gemini and html2gmi-cli - A Go library and app for
 converting HTML to Gemini
In-Reply-To: <5F23FA99.7030704@marmaladefoo.com>
References: <5F23FA99.7030704@marmaladefoo.com>
Message-ID: <20200731093403.10efb2cc@kether.phoenix.society>

On Fri, 31 Jul 2020 12:03:53 +0100
Luke Emmet <luke at marmaladefoo.com> wrote:

> Hi Everyone
> 
> 2 Gemini software announcements here, but they are related.

Aside from all of the other stuff I want to do, I've been curious about
learning Go for a while. I'm tempted to take your code and see if I can
turn it around to generate HTML from gemini text.

There's no reason I shouldn't be able to do it; the existence of
portal.mozz.us proves that converting text/gemini to text/html is
possible. It's just a matter of implementing the function as a tool I
could use in a makefile.

(mostly thinking out loud. sorry.)

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>	gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From luke at marmaladefoo.com  Fri Jul 31 18:54:09 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 31 Jul 2020 18:54:09 +0100
Subject: [ANN] html2gemini and html2gmi-cli - A Go library and app for
 converting HTML to Gemini
In-Reply-To: <20200731093403.10efb2cc@kether.phoenix.society>
References: <5F23FA99.7030704@marmaladefoo.com>
 <20200731093403.10efb2cc@kether.phoenix.society>
Message-ID: <5F245AC1.8030507@marmaladefoo.com>



On 31-Jul-2020 14:34, Matthew Graybosch wrote:
> Aside from all of the other stuff I want to do, I've been curious about
> learning Go for a while. I'm tempted to take your code and see if I can
> turn it around to generate HTML from gemini text.
>
> There's no reason I shouldn't be able to do it; the existence of
> portal.mozz.us proves that converting text/gemini to text/html is
> possible. It's just a matter of implementing the function as a tool I
> could use in a makefile.
Hello Matthew

Gemini is a couple of orders of magnitude simpler than HTML, so you 
don't need to start from such a complex base as looking at an HTML 
parser and sanitiser. It is *much* simpler to go from Gemini to HTML.

Here is a very simple pseudocode for a gemini to html converter, you can 
tart it up as you wish:

for each line in lines
if the line starts with heading marker (#, ##, ###), output: <h1> 
{{line}} </h1> (for #, use h2 and h3 accordingly)
if the line starts with bullet marker (*) , output: <div> ? {{line}}</div>
if the line starts with link marker, split the line and output: <div><a 
href="{{target}}">{{display}}</a></div>
if the line starts ```, toggle a flag and output <pre> if the flag is 
now on, or </pre> if the flag is off
otherwise output: <div>{{line}}</div> unless the line is empty, 
otherwise <div>&nbsp;</div>
next

You'll need to escape the content (e.g. &, <,> etc)

You can play around with CSS styling if you want to make it look pretty.

voila!

Best Wishes

- Luke

P.S. I have a more detailed version of a gemini to html converter here, 
used within GemiNaut, it might be of interest to look at. But its not in 
Go, but Rebol:

https://github.com/LukeEmmet/GemiNaut/blob/master/GemiNaut/GmiConverters/GmiToHtml.r3

From luke at marmaladefoo.com  Sat Aug  1 10:21:32 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 01 Aug 2020 10:21:32 +0100
Subject: [ANN] html2gemini and html2gmi-cli - A Go library and app for
 converting HTML to Gemini
In-Reply-To: <5F23FA99.7030704@marmaladefoo.com>
References: <5F23FA99.7030704@marmaladefoo.com>
Message-ID: <5F25341C.40702@marmaladefoo.com>

I've renamed the command line app to html2gmi, so the correct links are now:

Go library:

https://github.com/LukeEmmet/html2gemini

Command line app:

https://github.com/LukeEmmet/html2gmi

Best Wishes

- Luke

From me at ecmelberk.com  Tue Aug  4 20:09:57 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Tue, 4 Aug 2020 22:09:57 +0300
Subject: Current status of Moonlander (was: [ANN] Moonlander: The fanciest
 Gemini client in the entire solar system)
In-Reply-To: <20200519154300.64815d02@socimda>
Message-ID: <20200804220957.726b56a9.me@ecmelberk.com>

I just wrote about why Moonlander hasn't seen any commits after it's
first 3 days. Might be interesting to some of you.

    gemini://ebc.li/posts/how-hard-can-it-be.gmi

tldr: Text is hard and Moonlander _might_ get abandoned.

ps: Not entirely sure on mailing list etiquette, so I made this a reply
of the original announcement. Hope that's fine!

pps: Funnily enough, Moonlander might not be able to load that page. At
least it didn't on my system. Probably some incompatibility with the
new server.

From luke at marmaladefoo.com  Tue Aug  4 21:29:00 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 04 Aug 2020 21:29:00 +0100
Subject: Current status of Moonlander
In-Reply-To: <20200804220957.726b56a9.me@ecmelberk.com>
References: <20200804220957.726b56a9.me@ecmelberk.com>
Message-ID: <5F29C50C.6070703@marmaladefoo.com>

On 04-Aug-2020 20:09, Ecmel Berk Canl?er wrote:
> I just wrote about why Moonlander hasn't seen any commits after it's
> first 3 days. Might be interesting to some of you.
>
>      gemini://ebc.li/posts/how-hard-can-it-be.gmi
That's a great post - thanks for the write up. Yes text rendering is 
really hard when you go beyond the basics, so I agree it saves a lot of 
frustration to use an existing library if you can.

If it is just text selection that is holding you back and you want to 
continue with your UI experiments, why not abandon text selection? If 
the user really wants text selection, you could offer a view-source of 
the raw content in a vanilla text window, and the user can select from 
there in a very straightforward way. You could even scroll to the line 
offset to help if you wanted.

Best Wishes

- Luke

From me at ecmelberk.com  Wed Aug  5 12:29:45 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Wed, 5 Aug 2020 14:29:45 +0300
Subject: Current status of Moonlander
In-Reply-To: <5F29C50C.6070703@marmaladefoo.com>
References: <20200804220957.726b56a9.me@ecmelberk.com>
 <5F29C50C.6070703@marmaladefoo.com>
Message-ID: <20200805142945.65c0e141.me@ecmelberk.com>

> If it is just text selection that is holding you back and you want to 
> continue with your UI experiments, why not abandon text selection? If 
> the user really wants text selection, you could offer a view-source
> of the raw content in a vanilla text window, and the user can select
> from there in a very straightforward way. You could even scroll to
> the line offset to help if you wanted.

Aside from being an interesting experiment, I want Moonlander to be
something polished. Having to open secondary windows to do something as
"basic" (in terms of user interaction) as copy/paste wouldn't be good
design.

Aside from that, the infrastructure for at least basic text selection
would be required to handle inline links in formats like Markdown, if
they were to get implemented.

From colecmac at protonmail.com  Fri Aug  7 01:10:58 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 07 Aug 2020 00:10:58 +0000
Subject: Proxying
Message-ID: <-JyDGpPaEe9f2vXBZfbORyq7V2GVeR-phMTyIfg0W9jsM3zN1gmYapISZlxxk-ZBryysCjuOzHgvgMieLfN9R1t6Bo5vxyeiA1G-zbqXGIk=@protonmail.com>

Hello Geminauts,

Earlier today I added proxy support to the master branch of gemget[1].
This allows you to specify a host like 1.2.3.4, or example.com:3000,
that will be sent the Gemini request instead of the host specified in
the URL.

This kind of proxying is explicitly support by the Gemini spec, you can read
more about it in section 2.

I will also be adding proxy support to Amfora as well, so that if enabled,
all requests will go through the proxy.

However to my knowledge, no such server exists that can act as a general proxy.
I'd be happy to hear about any, if I've missed something. I forsee that they
could be used in the same way Squid[2] is for the web, as a cache. I think this
could work even better for Gemini then it does for the web, as documents are more
compact and are much less dynamic.

They could also be used for privacy, as many web proxies are.

I have to wonder whether anyone would actually use this. What do you all think of
this workflow/feature? Is it potentially useful? I'm vaguely interested in writing
such a server, but I'd be happy if anyone else beats me to the punch. Keep in mind
that server should also cache and serve TLS certs, so that they match the domain
being requested.


1: https://github.com/makeworld-the-better-one/gemget/commit/23048d309ed7f75cab79bb5daecc4a60f3b1587f
2: http://www.squid-cache.org/


makeworld

P.S. See the FetchWithHost function in go-gemini for a code example of how
the proxying works.

From luke at marmaladefoo.com  Sat Aug  8 12:30:20 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 08 Aug 2020 12:30:20 +0100
Subject: [ANN] GemiNaut 0.8.7 is released
Message-ID: <5F2E8CCC.60109@marmaladefoo.com>

Hi everyone

I'm pleased to announce a new release of GemiNaut, a user friendly 
graphical client for Gemini on MS Windows.

The main change in this 0.8.7 release is that GemiNaut now opens images 
directly within the client, and linked files can be downloaded directly 
without use of a web proxy. This makes for a more fluid and natural 
experience browsing geminispace.
There are also some minor usability improvements, for example, menus can 
be accessed using keyboard shortcuts, File->New to open a new window, 
and minor theme improvements.

Blog post summarising the changes:

   
gemini://gemini.marmaladefoo.com/blog/8-Aug-2020_GemiNaut_v0_8_7_release.gmi

GemiNaut home pages, with links to binaries and source:

   gemini://gemini.marmaladefoo.com/geminaut/

   https://www.marmaladefoo.com/pages/geminaut

Feedback, bugs and improvement suggestions are welcomed.

Best Wishes

  - Luke


From jmcbray at carcosa.net  Sun Aug  9 18:55:21 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Sun, 09 Aug 2020 13:55:21 -0400
Subject: Proxying
In-Reply-To: <-JyDGpPaEe9f2vXBZfbORyq7V2GVeR-phMTyIfg0W9jsM3zN1gmYapISZlxxk-ZBryysCjuOzHgvgMieLfN9R1t6Bo5vxyeiA1G-zbqXGIk=@protonmail.com>
 (colecmac@protonmail.com's message of "Fri, 07 Aug 2020 00:10:58 +0000")
References: <-JyDGpPaEe9f2vXBZfbORyq7V2GVeR-phMTyIfg0W9jsM3zN1gmYapISZlxxk-ZBryysCjuOzHgvgMieLfN9R1t6Bo5vxyeiA1G-zbqXGIk=@protonmail.com>
Message-ID: <87tuxbr9fa.fsf@dorothy.carcosa.net>

colecmac at protonmail.com writes:

> I have to wonder whether anyone would actually use this. What do you
> all think of this workflow/feature? Is it potentially useful?

I do think a caching proxy would be potentially useful, especially as
few clients do caching themselves. I could also see it useful for
offline use (client spiders through local proxy while online, client reads
offline through local proxy).

The tricky bit is, of course, cache expiration. We don't provide as much
useful information to the cache as http does. You'll need to use
heuristics not only for how long to cache, but to provide a way to force
a refresh, which isn't covered in the spec.


-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From sotirisp at protonmail.com  Mon Aug 10 11:32:34 2020
From: sotirisp at protonmail.com (Sotiris Papatheodorou)
Date: Mon, 10 Aug 2020 10:32:34 +0000
Subject: Track spec changes in git
Message-ID: <20200810103231.GA2361@librem13.home>

Putting the spec in a git repo would make it easy to see what changed
between versions of the specification. This of course would be
complementary to the current spec on Gemini/web/gopher which would show
the latest spec (and could be generated from git?). Thoughts?

Sot


From cage-dev at twistfold.it  Mon Aug 10 16:23:36 2020
From: cage-dev at twistfold.it (cage)
Date: Mon, 10 Aug 2020 17:23:36 +0200
Subject: Track spec changes in git
In-Reply-To: <20200810103231.GA2361@librem13.home>
References: <20200810103231.GA2361@librem13.home>
Message-ID: <20200810152336.GA2209@kurosawa.casa.net>

On Mon, Aug 10, 2020 at 10:32:34AM +0000, Sotiris Papatheodorou wrote:

Hi!

> Putting the spec in a git repo would make it easy to see what changed
> between versions of the specification. This of course would be
> complementary to the current spec on Gemini/web/gopher which would show
> the latest spec (and could be generated from git?). Thoughts?

I like this idea!

Bye!
C.

From matilde.park at sunshinegardens.org  Mon Aug 10 16:38:48 2020
From: matilde.park at sunshinegardens.org (Matilde Park)
Date: Mon, 10 Aug 2020 11:38:48 -0400
Subject: Track spec changes in git
In-Reply-To: <20200810152336.GA2209@kurosawa.casa.net>
References: <20200810103231.GA2361@librem13.home>
 <20200810152336.GA2209@kurosawa.casa.net>
Message-ID: <FAF2B0B2-B012-49CF-81FA-2AEE4D208C19@sunshinegardens.org>

Specifications are not designed to change often; they thus should be well-versioned, well-defined as to anything breaking, and all versions should coexist in the same location.

Version control is for sites of rapid and subtle change with many authors. It isn?t necessary in my opinion, but it?s fine anyway.

Matilde

> On Aug 10, 2020, at 11:23 AM, cage <cage-dev at twistfold.it> wrote:
> 
> On Mon, Aug 10, 2020 at 10:32:34AM +0000, Sotiris Papatheodorou wrote:
> 
> Hi!
> 
>> Putting the spec in a git repo would make it easy to see what changed
>> between versions of the specification. This of course would be
>> complementary to the current spec on Gemini/web/gopher which would show
>> the latest spec (and could be generated from git?). Thoughts?
> 
> I like this idea!
> 
> Bye!
> C.


From solderpunk at posteo.net  Mon Aug 10 21:10:49 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 10 Aug 2020 22:10:49 +0200
Subject: Track spec changes in git
In-Reply-To: <FAF2B0B2-B012-49CF-81FA-2AEE4D208C19@sunshinegardens.org>
Message-ID: <C4TL8RZFI6DI.4I399BX7GCML@stilgar>

The spec (and FAQ, best practices, etc) do actually live in a git repo,
I have just been lazy so far about making it publically cloneable,
although people do keep asking.  I'm not opposed, just haven't gotten
around to it yet.  I will try to do so this week, though.

Cheers,
Solderpunk

From solderpunk at posteo.net  Mon Aug 10 21:12:09 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 10 Aug 2020 22:12:09 +0200
Subject: Proxying
In-Reply-To: <87tuxbr9fa.fsf@dorothy.carcosa.net>
Message-ID: <C4TL9SQKDW14.287DHT7EM6TZA@stilgar>

On Sun Aug 9, 2020 at 7:55 PM CEST, Jason McBrayer wrote:
> colecmac at protonmail.com writes:
>
> > I have to wonder whether anyone would actually use this. What do you
> > all think of this workflow/feature? Is it potentially useful?
>
> I do think a caching proxy would be potentially useful, especially as
> few clients do caching themselves. I could also see it useful for
> offline use (client spiders through local proxy while online, client
> reads
> offline through local proxy).
>
> The tricky bit is, of course, cache expiration. We don't provide as much
> useful information to the cache as http does. You'll need to use
> heuristics not only for how long to cache, but to provide a way to force
> a refresh, which isn't covered in the spec.

If nothing else, I think there's a small, useful role for a very simple
caching proxy which just maintains an in-memory cache of everything
visited which is valid for, say, five minutes.  The reason this is
useful is that navigating Gemini capsules often involves extensive use
of the "back button" (and, at least for me on AV-98, the "up" command,
which gets you from example.com/foo/bar/baz to to example.com/foo/bar/
even in the lack of an explicit link, and the "root" command, which gets
you from example.com/foo/bar/baz to to example.com), which often entails
loading the same page repeatedly in a relatively short window of time.
A very simple dumb local cache would cut down on transactions for this.

For people like me who often read something in Gemini/Gopherspace, then
want to reference a few days later but cannot remember where they read
it, a proxy which maintained full-text search of everything visited in
the past month or so would be *super* handy, but I have no idea how to
build such a thing.

I'm kind of attracted to the idea of small, simple, do-one-thing-well
proxies which can be chained together like "filter" programs in a
pipeline...but I guess the TLS overhead would stack up quickly,
encouraging a kind of highly configurable "Swiss army knife" proxy
instead.  Not as pretty, but potentially very useful...

Cheers,
Solderpunk

From jmcbray at carcosa.net  Mon Aug 10 21:54:38 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 10 Aug 2020 16:54:38 -0400
Subject: Proxying
In-Reply-To: <C4TL9SQKDW14.287DHT7EM6TZA@stilgar> (solderpunk@posteo.net's
 message of "Mon, 10 Aug 2020 22:12:09 +0200")
References: <C4TL9SQKDW14.287DHT7EM6TZA@stilgar>
Message-ID: <87a6z2b4s1.fsf@dorothy.carcosa.net>

"Solderpunk" <solderpunk at posteo.net> writes:

> For people like me who often read something in Gemini/Gopherspace,
> then want to reference a few days later but cannot remember where they
> read it, a proxy which maintained full-text search of everything
> visited in the past month or so would be *super* handy, but I have no
> idea how to build such a thing.

I wrote such a thing for HTTP 1.0 back around 2000. The performance was
terrible, and it quickly became obsolete (I wasn't up to implementing
HTTP 1.1 features like chunked transfer at the time), and the spread of
SSL put a final nail in its coffin. But it was fun at the time.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From colecmac at protonmail.com  Mon Aug 10 22:31:40 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 10 Aug 2020 21:31:40 +0000
Subject: Proxying
In-Reply-To: <C4TL9SQKDW14.287DHT7EM6TZA@stilgar>
References: <C4TL9SQKDW14.287DHT7EM6TZA@stilgar>
Message-ID: <4dmeBFmrdYtCZmVv-xsA3uCFZDeC9quTGcrsSkUwb8_PEGgZbLdx3RWt8Rd0k8IUNMG85V7ok0oXSPQZe1iXYT66AnJagrb1pzb0qnpapm8=@protonmail.com>

> If nothing else, I think there's a small, useful role for a very simple
> caching proxy which just maintains an in-memory cache of everything
> visited which is valid for, say, five minutes. The reason this is
> useful is that navigating Gemini capsules often involves extensive use
> of the "back button" (and, at least for me on AV-98, the "up" command,
> which gets you from example.com/foo/bar/baz to to example.com/foo/bar/
> even in the lack of an explicit link, and the "root" command, which gets
> you from example.com/foo/bar/baz to to example.com), which often entails
> loading the same page repeatedly in a relatively short window of time.
> A very simple dumb local cache would cut down on transactions for this.

I think this is often best relegated to the client, but I see how it's nice
for the client not to have to worry about it, and to have this other proxy instead.
I was originally picturing something longer lived, so that it would still be
useful along with any caches the client already has, but I'm not sure how much
sense that makes.

> For people like me who often read something in Gemini/Gopherspace, then
> want to reference a few days later but cannot remember where they read
> it, a proxy which maintained full-text search of everything visited in
> the past month or so would be super handy, but I have no idea how to
> build such a thing.

Me neither, but that definitely seems cool. I'm sure Natpen would have an
idea on how to do this :). It's also a nice way to keep history for clients
that don't do that (all of them?). The full text search also doubles as an
archive of all the sites you visit.


makeworld

From me at ecmelberk.com  Mon Aug 10 23:14:04 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Tue, 11 Aug 2020 01:14:04 +0300
Subject: Proxying
In-Reply-To: <C4TL9SQKDW14.287DHT7EM6TZA@stilgar>
References: <87tuxbr9fa.fsf@dorothy.carcosa.net>
 <C4TL9SQKDW14.287DHT7EM6TZA@stilgar>
Message-ID: <20200811011404.160f32cb.me@ecmelberk.com>

> For people like me who often read something in Gemini/Gopherspace,
> then want to reference a few days later but cannot remember where
> they read it, a proxy which maintained full-text search of everything
> visited in the past month or so would be *super* handy, but I have no
> idea how to build such a thing.

I assume downloading every page into a local cache and running
something like https://blevesearch.com/ on top of them when a
search request comes would work reasonably well.

I assume this wouldn't require _that much_ space, as most Gemini pages
(that I have encountered so far) are small, and text is really
compressible if the need comes up.

Changes to the cached pages could be stored with deltas/patches, so
that might be interesting for historical preservation too, assuming
most pages don't change that much, that often.

And all this can happen without leaving Gemini, like how GUS works.

> I'm kind of attracted to the idea of small, simple, do-one-thing-well
> proxies which can be chained together like "filter" programs in a
> pipeline...but I guess the TLS overhead would stack up quickly,

Since I am not exactly knowledgeable on TLS and other low-level
protocols (except knowing how to open a socket), how much would the TLS
overhead be if the proxy was hosted on the same machine as the client?
I assume modern CPUs can easily deal with the encryption work at
reasonable speeds, and the connection being local would probably get rid
of the majority of the network overhead.

Also another idea to throw into the pile: a "master" proxy that accepts
TLS connections, but delegates everything else into small filter
scripts. That way we can get rid of the TLS and networking overhead of
stacking multiple proxies on top of each other, while keeping the
flexibility and simplicity of the pipeline approach. The one drawback I
can think of is the scripts would no longer be regular proxies on their
own, and if someone wanted to use even just one of these scripts, they
would need to install the entire pipeline framework.

But at that point, why not build the pipelines into clients? Assuming
these scripts work via "stdin -> (script magic) -> stdout", even shell
clients could run them by piping their "gemini receive" command into
them. Long-running scripts could probably just be accessed via wrappers
with netcat, or something else I haven't thought of yet.

Anyway, these are all just some ideas that I am throwing here. I might
even try building some of them if there's any interest, but I am pretty
sure there will be some issues I haven't thought of. Let me know what
you all think!

-- 
Have a nice (day|night|week(end)?)
~ Ecmel B. Canl?er ~

From krispin at posteo.de  Tue Aug 11 09:06:26 2020
From: krispin at posteo.de (Krispin Schulz)
Date: Tue, 11 Aug 2020 10:06:26 +0200
Subject: Lovell - a Gemini server written for Node.js
Message-ID: <DFF45871-7A73-461F-860F-2EBE1D231347@posteo.de>

Hi geminauts,

I just wrote a super-simple server running with Node.js:

https://git.sr.ht/~kr1sp1n/lovell <https://git.sr.ht/~kr1sp1n/lovell>

It?s just a proof-of-concept for now and it serves only a static file.
But it was fun to write it and showed me again how simple it is to implement the Gemini protocol.
Please send me feature requests if you like and I am more than happy to implement it.

Have a "lovelly? day!


Krispin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200811/43367ab9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200811/43367ab9/attachment-0001.sig>

From sean at conman.org  Tue Aug 11 10:02:58 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 11 Aug 2020 05:02:58 -0400
Subject: Lovell - a Gemini server written for Node.js
In-Reply-To: <DFF45871-7A73-461F-860F-2EBE1D231347@posteo.de>
References: <DFF45871-7A73-461F-860F-2EBE1D231347@posteo.de>
Message-ID: <20200811090258.GC19556@brevard.conman.org>

It was thus said that the Great Krispin Schulz once stated:
> Hi geminauts,

  Hello.

> I just wrote a super-simple server running with Node.js:
> 
> https://git.sr.ht/~kr1sp1n/lovell <https://git.sr.ht/~kr1sp1n/lovell>
> 
> It?s just a proof-of-concept for now and it serves only a static file.
> But it was fun to write it and showed me again how simple it is to implement the Gemini protocol.
> Please send me feature requests if you like and I am more than happy to implement it.

  I tried taking a look at the project, but:

	Unauthorized

	The server could not verify that you are authorized to access the
	URL requested. You either supplied the wrong credentials (e.g. a bad
	password), or your browser doesn't understand how to supply the
	credentials required.

  This makes it a bit hard to look and try it out.

  -spc (But congratulations on writing a server!)


From krispin at posteo.de  Tue Aug 11 10:24:18 2020
From: krispin at posteo.de (Krispin Schulz)
Date: Tue, 11 Aug 2020 11:24:18 +0200
Subject: Lovell - a Gemini server written for Node.js
In-Reply-To: <20200811090258.GC19556@brevard.conman.org>
References: <DFF45871-7A73-461F-860F-2EBE1D231347@posteo.de>
 <20200811090258.GC19556@brevard.conman.org>
Message-ID: <FC32610B-A129-4090-924C-AB76120728E7@posteo.de>

Hi Sean,

> On 11. Aug 2020, at 11:02, Sean Conner <sean at conman.org> wrote:
> 
> It was thus said that the Great Krispin Schulz once stated:
>> Hi geminauts,
> 
>  Hello.
> 
>> I just wrote a super-simple server running with Node.js:
>> 
>> https://git.sr.ht/~kr1sp1n/lovell <https://git.sr.ht/~kr1sp1n/lovell>
>> 
>> It?s just a proof-of-concept for now and it serves only a static file.
>> But it was fun to write it and showed me again how simple it is to implement the Gemini protocol.
>> Please send me feature requests if you like and I am more than happy to implement it.
> 
>  I tried taking a look at the project, but:
> 
> 	Unauthorized
> 
> 	The server could not verify that you are authorized to access the
> 	URL requested. You either supplied the wrong credentials (e.g. a bad
> 	password), or your browser doesn't understand how to supply the
> 	credentials required.
> 
>  This makes it a bit hard to look and try it out.

I forgot to make the repo public. Shame on me!
Please try again and thanks for the hint ;)

> 
>  -spc (But congratulations on writing a server!)
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200811/99fbc13a/attachment.sig>

From kevin at susa.net  Tue Aug 11 13:53:44 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 11 Aug 2020 13:53:44 +0100
Subject: Lovell - a Gemini server written for Node.js
In-Reply-To: <DFF45871-7A73-461F-860F-2EBE1D231347@posteo.de>
References: <DFF45871-7A73-461F-860F-2EBE1D231347@posteo.de>
Message-ID: <CAPk6LxSQUcTpJp3JB1+=-A_Mo4RaVkD=-iXRV85-hnxu5nrtjQ@mail.gmail.com>

Well done. If you're looking for motivators to push your project
forward, I recommend running a gemini site using your own server,
assuming you have server/domain resources to do this.

If I were doing such a thing, I might start with some overview
articles, as well as some auto-generated stuff (e.g. a gemtext version
of the git log) which could eventually be invoked via CGI if or when
you choose to add this.

There's a bunch of implied feature requests right there!

On Tue, 11 Aug 2020 at 09:07, Krispin Schulz <krispin at posteo.de> wrote:
>
> Hi geminauts,
>
> I just wrote a super-simple server running with Node.js:
>
> https://git.sr.ht/~kr1sp1n/lovell
>
> It?s just a proof-of-concept for now and it serves only a static file.
> But it was fun to write it and showed me again how simple it is to implement the Gemini protocol.
> Please send me feature requests if you like and I am more than happy to implement it.
>
> Have a "lovelly? day!
>
>
> Krispin

From solderpunk at posteo.net  Tue Aug 11 19:00:38 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 11 Aug 2020 20:00:38 +0200
Subject: Proxying
In-Reply-To: <4dmeBFmrdYtCZmVv-xsA3uCFZDeC9quTGcrsSkUwb8_PEGgZbLdx3RWt8Rd0k8IUNMG85V7ok0oXSPQZe1iXYT66AnJagrb1pzb0qnpapm8=@protonmail.com>
Message-ID: <C4UD3MZ4XDXJ.32ERW125FYIVS@stilgar>

On Mon Aug 10, 2020 at 11:31 PM CEST,  wrote:

> I think this is often best relegated to the client, but I see how it's
> nice
> for the client not to have to worry about it, and to have this other
> proxy instead.
> I was originally picturing something longer lived, so that it would
> still be
> useful along with any caches the client already has, but I'm not sure
> how much
> sense that makes.

Yeah, this wouldn't be too hard to do in the client.  I guess I think of
it the same way I think of poor little rarely-used Agena: isn't it
necessarily hard to add Gopher support to a Gemini proxy, but also
what's the point of a dozen different client authors doing the same
thing a dozen different times when it fits so naturally into the proxy
concept?

But, sure, for a tiny in-memory short-lived cache perhaps this argument
is not so strong, certainly less though than for something larger and
longer lived.  I do think that gets tricky, though, it's hard to know
when to invalidate the cache without servers having any way to signal
it.

Cheers,
Solderpunk

From solderpunk at posteo.net  Tue Aug 11 19:18:39 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 11 Aug 2020 20:18:39 +0200
Subject: Proxying
In-Reply-To: <20200811011404.160f32cb.me@ecmelberk.com>
Message-ID: <C4UDHFOO5QTP.24D55BGZ0HAQQ@stilgar>

On Tue Aug 11, 2020 at 12:14 AM CEST, Ecmel Berk Canl?er wrote:

> But at that point, why not build the pipelines into clients? Assuming
> these scripts work via "stdin -> (script magic) -> stdout", even shell
> clients could run them by piping their "gemini receive" command into
> them. Long-running scripts could probably just be accessed via wrappers
> with netcat, or something else I haven't thought of yet.

This is a nice idea.  AV-98 almost supports it already, you can pipe the
body of Gemini responses to arbitrary pipelines based on their MIME
type, which allows for reformatting text and things like that, but
nothing in the pipeline gets access to the URL where the resource came
from, which would be required to make a lot of useful applications work.
But it probably wouldn't be hard at all to pass that information along
via environment variables.  Hmm...

Cheers,
Solderpunk

From cage-dev at twistfold.it  Tue Aug 11 20:00:46 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 11 Aug 2020 21:00:46 +0200
Subject: Track spec changes in git
In-Reply-To: <C4TL8RZFI6DI.4I399BX7GCML@stilgar>
References: <FAF2B0B2-B012-49CF-81FA-2AEE4D208C19@sunshinegardens.org>
 <C4TL8RZFI6DI.4I399BX7GCML@stilgar>
Message-ID: <20200811190046.GA9507@kurosawa.casa.net>

On Mon, Aug 10, 2020 at 10:10:49PM +0200, Solderpunk wrote:
> The spec (and FAQ, best practices, etc) do actually live in a git repo,
> I have just been lazy so far about making it publically cloneable,
> although people do keep asking.  I'm not opposed, just haven't gotten
> around to it yet.  I will try to do so this week, though.

Great! Thank you! :)

C.

From colecmac at protonmail.com  Tue Aug 11 20:02:22 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 11 Aug 2020 19:02:22 +0000
Subject: Proxying
In-Reply-To: <-JyDGpPaEe9f2vXBZfbORyq7V2GVeR-phMTyIfg0W9jsM3zN1gmYapISZlxxk-ZBryysCjuOzHgvgMieLfN9R1t6Bo5vxyeiA1G-zbqXGIk=@protonmail.com>
References: <-JyDGpPaEe9f2vXBZfbORyq7V2GVeR-phMTyIfg0W9jsM3zN1gmYapISZlxxk-ZBryysCjuOzHgvgMieLfN9R1t6Bo5vxyeiA1G-zbqXGIk=@protonmail.com>
Message-ID: <uGfx694ffHfxvdqpfKZuOvSirhHfuv7g3EXAIUlIeXDAVwQA0KdgPvI_364Sdf92x6d9TN4qdUmOiuc2PuTLUAM_XNhssgYp6ShiAC0yPzo=@protonmail.com>

> Keep in mind that server should also cache and serve TLS certs, so that they
> match the domain being requested.

I have changed this, as I don't think it makes sense anymore. Currently with
go-gemini v0.8.1, the proxy does not need to have a TLS cert that matches the
proxy resource. It just needs to serve a cert that matches its own hostname.

https://github.com/makeworld-the-better-one/go-gemini/commit/3d39237a5e912067bf436cf032bf2cc9f42e47ed

Thanks,
makeworld

From alex at gnu.org  Tue Aug 11 21:33:51 2020
From: alex at gnu.org (Alex Schroeder)
Date: Tue, 11 Aug 2020 22:33:51 +0200
Subject: Proxying
In-Reply-To: <C4UDHFOO5QTP.24D55BGZ0HAQQ@stilgar>
References: <C4UDHFOO5QTP.24D55BGZ0HAQQ@stilgar>
Message-ID: <cd0a78bf309ef6b22737a2a19238028f2b13f828.camel@gnu.org>

On Tue, 2020-08-11 at 20:18 +0200, Solderpunk wrote:
> AV-98 almost supports it already, you can pipe the
> body of Gemini responses to arbitrary pipelines based on their MIME
> type, which allows for reformatting text and things like that, but
> nothing in the pipeline gets access to the URL where the resource
> came
> from, which would be required to make a lot of useful applications
> work.
> But it probably wouldn't be hard at all to pass that information
> along
> via environment variables.  Hmm...

I wanted that to edit pages from within AV-98 as well. I'd like to
define a command that takes the current text, and the current URL,
calls $EDITOR, and reposts it somewhere (based on the current URL).

Cheers
Alex




From colecmac at protonmail.com  Wed Aug 12 15:05:45 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 12 Aug 2020 14:05:45 +0000
Subject: Go 1.15 requires changes to TLS code for Gemini!
Message-ID: <taY-SmXfhZ7JhaDygBE_jzOkU505aOI5SeGnbgv53Jl0-6sT6mpcI4bwgq930QFGSh6n2xC5-Ya-dXUyKIrxzgYyJNcxcrpXduUyvu3ZUEU=@protonmail.com>

Hello gophers,


If you have written (or are planning on writing) a Gemini application in Go
that validates the server/client cert, you will have to change your code.
Part of validation is validating the hostname, and this has changed in
Go 1.15.

> The deprecated, legacy behavior of treating the CommonName field on X.509
> certificates as a host name when no Subject Alternative Names are present
> is now disabled by default. It can be temporarily re-enabled by adding the
> value x509ignoreCN=0 to the GODEBUG environment variable.

https://golang.org/doc/go1.15#commonname

Apparently using CN without a SAN is deprecated by RFC, at least for
the web. I did not know that! So using cert.VerifyHostname will no longer
work on the majority of Gemini certs that just specify a CN and nothing else.

The solution is to check the CN manually, and then use VerifyHostname if that
fails. If both fail, then the cert is not valid.

If I have an x509.Certificate with the name `cert`, and a hostname called
`hostname`, I can do this to check:

if cert.Subject.CommonName == hostname || cert.VerifyHostname(hostname) == nil {
    // Do something
}


or of course:


if cert.Subject.CommonName != hostname && cert.VerifyHostname(hostname) != nil {
    // Exit, return an error, etc
}


Hope this helps! I will be implementing this in go-gemini (and therefore
gemget and Amfora), but until then do not compile them with Go 1.15.


Cheers,
makeworld



From andre at andregarzia.com  Wed Aug 12 23:57:54 2020
From: andre at andregarzia.com (Andre Garzia)
Date: Wed, 12 Aug 2020 23:57:54 +0100
Subject: [ANN] Fafi, a Racket-based client
Message-ID: <CAF3jwTnvMa-4A1TpkEucDJQ_z69fG05DOg1+VGH+3j+yLwjz4g@mail.gmail.com>

Hi Folks,

I'm new to this list, to Racket, and to Gemini, but I am quite happy to be
here because I have an interesting project to share. I have built a simple
Graphical Gemini client using Racket, it should run in any platform Racket
runs (I have tested it on Windows, macOS and Linux).

The most interesting parts of it are the fact that it supports tabs, which
is a feature I don't think is yet common among the clients, and that it
converts gemtext into a cute s-expression based representation.

At the moment it doesn't pass all the 51 tests in the client torture list
but IIRC it passes more than 40 of them. Anyway, I need to fix redirecton
loops and I can't support some of the TLS stuff because Racket is shipping
TLS 1.2.

So far I have written two blog posts about it:

  https://andregarzia.com/2020/05/toying-with-gemini.html

https://andregarzia.com/2020/08/fafi-browser-a-racket-based-gemini-client.html

The source code and issue tracker are in sourcehut:

  https://git.sr.ht/~soapdog/fafi-browser
  https://todo.sr.ht/~soapdog/racket-gemini

Hope to hear from you all and excited to be here.
A.



-- 
https://www.andregarzia.com <http://www.andregarzia.com>
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200812/ff23cd09/attachment.htm>

From dev.urandom at posteo.org  Fri Aug 14 09:59:40 2020
From: dev.urandom at posteo.org (/dev/urandom)
Date: Fri, 14 Aug 2020 11:59:40 +0300
Subject: Thoughts about the Gemini protocol
Message-ID: <be5bed891cff8a572902496308cde493@posteo.net>

Hello everyone,

The recent news about the layoffs at Mozilla have left me wondering as 
to whether the modern web has become too complex. I've heard people 
discuss the Gemini protocol as a simplified alternative that is way 
easier to work with. After checking it out (and even trying to write a 
small experimental client in C, which thanks to libtls, ended up way 
easier than I thought), it seems to be a really promising idea.

I was thinking about an idea similar to Gemini that could work as a 
protocol for not just websites, but also simple and functional web 
applications as well that could, to a reasonable extent, look and work 
well on lots of different devices (desktops, smartphones, feature 
phones, text-mode interfaces). After seeing how the Gemini protocol 
works, it seems to me that a lot of these ideas could be implemented in 
a backwards-compatible way or with minimal modifications to the 
protocol.

1. Basic form inputs / "widgets"

In addition to an "INPUT" response that only requests a line of text and 
returns the question as a single line in the <META> field, some sort of 
"extended input" could be useful. It could still be restricted to a 
single query, but it could provide software-interpretable hints as to 
what kind of input is preferable.

For example, a "check" input could provide a numbered list of options 
and then ask the user to submit a query consisting a list of the 
numbered items the user wants to select (or 0 if none). A more advanced 
client program would then display the entire request as a series of 
checkboxes or switches that the user can toggle. A "radio" or "button" 
input could demand a single number, and the client would display the 
items as a list of radio switches or buttons, of which only one can be 
selected.

(I can imagine the description of the inputs either being part of the 
<META> field, part of the previous page's text or maybe an "extended 
input" could have its own response body that they're written in.)

Or a "date" input could say that it expects a date in the YYYY-MM-DD 
format, but an advanced client could provide the user with a date picker 
instead.

Either way, the general idea is that a simple client could just ask the 
user to write the query as a line of text.

2. Continuous connections

A user might want to not just give commands to a service, but also to 
expect it to provide a continuous stream of information over a long 
term. Most modern web pages use scripting to accomplish something like 
that (and most web-browsers wait for a page to finish loading before 
displaying it), but a minimal version of this seems achievable without 
it.

An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE") 
or mime-type (say, "text/gemini-continuous") would indicate that the 
server will not give the entire response at once and then immediately 
close the connection, but instead the connection will continue for a 
long time, and instead of waiting for the entire text to be received, 
the client should look for whenever a complete line arrives and print 
that line.

The client could then use that connection to receive updates on the 
request, until either the client or the server actually decides to close 
the connection or it gets closed by some other means.

3. Append mode

This is just a little extra feature, but the idea is that a page 
(probably also via mime-type, like "text/gemini-append", or an 
additional parameter, like "text/gemini; append") could indicate that 
its contents should, if possible, be added at the end of the previous 
page, rather than replacing it entirely.

---

I would like to hear your opinions as to whether these ideas could, or 
should, be added to the Gemini protocol, and in which specific ways if 
so. Thank you all very much.

From alex at gnu.org  Fri Aug 14 11:50:57 2020
From: alex at gnu.org (Alex Schroeder)
Date: Fri, 14 Aug 2020 12:50:57 +0200
Subject: Thoughts about the Gemini protocol
In-Reply-To: <be5bed891cff8a572902496308cde493@posteo.net>
References: <be5bed891cff8a572902496308cde493@posteo.net>
Message-ID: <d93f8bfcbfd70f4ea3566c3822851237c9cd8ede.camel@gnu.org>

Hello and welcome!

On Fri, 2020-08-14 at 11:59 +0300, /dev/urandom wrote:
> For example, a "check" input could provide a numbered list of
> options 
> and then ask the user to submit a query consisting a list of the 
> numbered items the user wants to select (or 0 if none). A more
> advanced 
> client program would then display the entire request as a series of 
> checkboxes or switches that the user can toggle. A "radio" or
> "button" 
> input could demand a single number, and the client would display the 
> items as a list of radio switches or buttons, of which only one can
> be 
> selected.

It's interesting... but also a bit of a feature creep. My suspicion
would be that all of this could be handled by simple string input and
validation (your age, your zip code, your preferred choice from a
menu), or by using links to provide alternatives... I do wonder what
you have in mind though. I'd say if the goal is to write web apps,
perhaps Gemini is not the right way to do it. And every extension makes
it a bit more complicated and at the end people can't implement it in a
day. We'd be repeating all the iterations of HTTP and HTML, no?

> A user might want to not just give commands to a service, but also
> to 
> expect it to provide a continuous stream of information over a long 
> term. Most modern web pages use scripting to accomplish something
> like 
> that (and most web-browsers wait for a page to finish loading before 
> displaying it), but a minimal version of this seems achievable
> without 
> it.

I think you'll find a discussion of this in the archives. Look for the
thread "Reopening: Stream status code". I think the key message is this
one:
https://lists.orbitalfox.eu/archives/gemini/2020/002269.html
"This is mainly just an issue of what to do about timeouts, right? If
you don't have any timeout at all, streamed content works fine, but
buggy/overloaded servers hang the client, and that's bad.  If you have
a fixed timeout of 5 seconds, some streaming applications (like the
chat example mozz has done) break."

> This is just a little extra feature, but the idea is that a page 
> (probably also via mime-type, like "text/gemini-append", or an 
> additional parameter, like "text/gemini; append") could indicate
> that 
> its contents should, if possible, be added at the end of the
> previous 
> page, rather than replacing it entirely.

I think if you read the discussions regarding streaming, you'll see
that if the server doesn't hang up, and if clients don't implement
timeouts, all of this naturally just happens.

> I would like to hear your opinions as to whether these ideas could,
> or 
> should, be added to the Gemini protocol, and in which specific ways
> if 
> so.

Sorry to be a cold blanket here, but my answer is No to all of the
ideas. Instead, with respect to your ideas, let's focus on these two
points:

1. Clients without timeouts with an appropriate UI to help users
interpret what they are seeing.

2. Websites ("applications") with appropriate user interfaces such that
we don't need structured input.

I think it's doable, but it isn't as simple as it seems at first sight.

Cheers
Alex



From dev.urandom at posteo.org  Fri Aug 14 12:18:04 2020
From: dev.urandom at posteo.org (/dev/urandom)
Date: Fri, 14 Aug 2020 14:18:04 +0300
Subject: Thoughts about the Gemini protocol
In-Reply-To: <d93f8bfcbfd70f4ea3566c3822851237c9cd8ede.camel@gnu.org>
References: <be5bed891cff8a572902496308cde493@posteo.net>
 <d93f8bfcbfd70f4ea3566c3822851237c9cd8ede.camel@gnu.org>
Message-ID: <57548a262cd4fcdc5f67e12897c76252@posteo.net>

On Fri, 14 Aug 2020 12:50:57 +0200
Alex Schroeder <alex at gnu.org> wrote:

> It's interesting... but also a bit of a feature creep. My suspicion
> would be that all of this could be handled by simple string input and
> validation (your age, your zip code, your preferred choice from a
> menu), or by using links to provide alternatives... I do wonder what
> you have in mind though. I'd say if the goal is to write web apps,
> perhaps Gemini is not the right way to do it. And every extension makes
> it a bit more complicated and at the end people can't implement it in a
> day. We'd be repeating all the iterations of HTTP and HTML, no?

I understand. My intention was that, for a basic client, the input
would still work in the exact same way. You get a basic string, enter
something, it gets added as a query, and the server returns either a
2x or a 59. But the more advanced clients could provide an
alternate input method to make it easier for the user.

And, of course, repeating the mistakes of HTTP and HTML is something I
want to avoid as much as you.

> I think you'll find a discussion of this in the archives. Look for the
> thread "Reopening: Stream status code". I think the key message is this
> one:
> https://lists.orbitalfox.eu/archives/gemini/2020/002269.html
> "This is mainly just an issue of what to do about timeouts, right? If
> you don't have any timeout at all, streamed content works fine, but
> buggy/overloaded servers hang the client, and that's bad.  If you have
> a fixed timeout of 5 seconds, some streaming applications (like the
> chat example mozz has done) break."

I guess that ideally, any client would use threads or some other
mechanism to allow for the user to read the already-loaded parts of a
page while it's being loaded, while indicating that the page is
"incomplete" in some way in the user interface.

Then it wouldn't be necessary to specifically signal server-side
whether or not the page is streamed or loaded as a single piece.

> I think if you read the discussions regarding streaming, you'll see
> that if the server doesn't hang up, and if clients don't implement
> timeouts, all of this naturally just happens.

The third suggestion (appendable pages) was actually unrelated to
streaming. I was instead suggesting it as a way for applications to
send small messages in response to requests in a way that doesn't
require the server to re-send the original page every time.

> Sorry to be a cold blanket here, but my answer is No to all of the
> ideas. Instead, with respect to your ideas, let's focus on these two
> points:
> 
> 1. Clients without timeouts with an appropriate UI to help users
> interpret what they are seeing.
> 
> 2. Websites ("applications") with appropriate user interfaces such that
> we don't need structured input.
> 
> I think it's doable, but it isn't as simple as it seems at first sight.

It's all okay. I understand and appreciate your responses anyway.

> Cheers
> Alex

Thanks!
~ /dev/urandom


From kevin at susa.net  Fri Aug 14 14:26:26 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Fri, 14 Aug 2020 14:26:26 +0100
Subject: Thoughts about the Gemini protocol
In-Reply-To: <be5bed891cff8a572902496308cde493@posteo.net>
References: <be5bed891cff8a572902496308cde493@posteo.net>
Message-ID: <CAPk6LxTWgo6D=boJm-KgLLEv7J=v6aSrp4fY5Kg-sxRwP5ZB7A@mail.gmail.com>

Hi,

I think you're absolutely right that the scope of the web (or more
specifically, the web browser) has grown to the point that it might
soon be impractical to make use of it without Google's tech (and you
only need to look at Android to see how that will play out, and Apple
are little better). On the other hand, I don't think Gemini is the
place to address this; as I see it, Gemini stands on its own, with its
own purpose, which does happen to align with the original purpose of
the web, and is perhaps why it seems the obvious to modify in the ways
you suggest (similar types of ideas crossed my mind too).

I personally think that the way to revive the web is to run HTTP on a
different port so that content can be identified as separate from the
current web, and where this implies a reduced level of functionality
(e.g. content that can be rendered by Kristall, or Dillo, or Lynx,
etc.). I've put a lighttpd server on port 1993 of my Gemini server,
though I've had no reason to use it yet - I'm free to *not* use any
web features I don't want to. :-)

Well done on getting your C client running, if you're sharing the
code, I'd love to check it out!

Kevin
gemini://gemini.susa.net/

On Fri, 14 Aug 2020 at 09:59, /dev/urandom <dev.urandom at posteo.org> wrote:
>
> Hello everyone,
>
> The recent news about the layoffs at Mozilla have left me wondering as
> to whether the modern web has become too complex. I've heard people
> discuss the Gemini protocol as a simplified alternative that is way
> easier to work with. After checking it out (and even trying to write a
> small experimental client in C, which thanks to libtls, ended up way
> easier than I thought), it seems to be a really promising idea.
>
> I was thinking about an idea similar to Gemini that could work as a
> protocol for not just websites, but also simple and functional web
> applications as well that could, to a reasonable extent, look and work
> well on lots of different devices (desktops, smartphones, feature
> phones, text-mode interfaces). After seeing how the Gemini protocol
> works, it seems to me that a lot of these ideas could be implemented in
> a backwards-compatible way or with minimal modifications to the
> protocol.
>
> 1. Basic form inputs / "widgets"
>
> In addition to an "INPUT" response that only requests a line of text and
> returns the question as a single line in the <META> field, some sort of
> "extended input" could be useful. It could still be restricted to a
> single query, but it could provide software-interpretable hints as to
> what kind of input is preferable.
>
> For example, a "check" input could provide a numbered list of options
> and then ask the user to submit a query consisting a list of the
> numbered items the user wants to select (or 0 if none). A more advanced
> client program would then display the entire request as a series of
> checkboxes or switches that the user can toggle. A "radio" or "button"
> input could demand a single number, and the client would display the
> items as a list of radio switches or buttons, of which only one can be
> selected.
>
> (I can imagine the description of the inputs either being part of the
> <META> field, part of the previous page's text or maybe an "extended
> input" could have its own response body that they're written in.)
>
> Or a "date" input could say that it expects a date in the YYYY-MM-DD
> format, but an advanced client could provide the user with a date picker
> instead.
>
> Either way, the general idea is that a simple client could just ask the
> user to write the query as a line of text.
>
> 2. Continuous connections
>
> A user might want to not just give commands to a service, but also to
> expect it to provide a continuous stream of information over a long
> term. Most modern web pages use scripting to accomplish something like
> that (and most web-browsers wait for a page to finish loading before
> displaying it), but a minimal version of this seems achievable without
> it.
>
> An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE")
> or mime-type (say, "text/gemini-continuous") would indicate that the
> server will not give the entire response at once and then immediately
> close the connection, but instead the connection will continue for a
> long time, and instead of waiting for the entire text to be received,
> the client should look for whenever a complete line arrives and print
> that line.
>
> The client could then use that connection to receive updates on the
> request, until either the client or the server actually decides to close
> the connection or it gets closed by some other means.
>
> 3. Append mode
>
> This is just a little extra feature, but the idea is that a page
> (probably also via mime-type, like "text/gemini-append", or an
> additional parameter, like "text/gemini; append") could indicate that
> its contents should, if possible, be added at the end of the previous
> page, rather than replacing it entirely.
>
> ---
>
> I would like to hear your opinions as to whether these ideas could, or
> should, be added to the Gemini protocol, and in which specific ways if
> so. Thank you all very much.

From matilde.park at sunshinegardens.org  Fri Aug 14 14:35:33 2020
From: matilde.park at sunshinegardens.org (Matilde Park)
Date: Fri, 14 Aug 2020 09:35:33 -0400
Subject: Thoughts about the Gemini protocol
In-Reply-To: <CAPk6LxTWgo6D=boJm-KgLLEv7J=v6aSrp4fY5Kg-sxRwP5ZB7A@mail.gmail.com>
References: <be5bed891cff8a572902496308cde493@posteo.net>
 <CAPk6LxTWgo6D=boJm-KgLLEv7J=v6aSrp4fY5Kg-sxRwP5ZB7A@mail.gmail.com>
Message-ID: <01EBED55-F55F-4637-B2D2-DD9003A7F0DB@sunshinegardens.org>

I think this proposal misunderstands the utility of the Gemini protocol, though I may myself be mistaken.

The web itself shouldn?t have become a widget library, or a set of applications. The DOM is a poor replacement for something like GTK, et al., and HTML/JS/CSS has come pretty far in approximating it to an operating system by punting an operating system level of complexity to the client ? thus web browsers are unmaintainable by anyone other than corporations who can build an operating system to a specification.

In this regard, I think protocols like gemini:// or gopher:// aren?t meant to *supplant* the web, but have a specialised purpose. There can be a very small, human scale specification. Let HTTP do what it?s become specialised to do; and in our own projects, abandon it. In doing so, you can avoid the incentives that brought clearnet where it is now.

> On Aug 14, 2020, at 9:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> 
> Hi,
> 
> I think you're absolutely right that the scope of the web (or more
> specifically, the web browser) has grown to the point that it might
> soon be impractical to make use of it without Google's tech (and you
> only need to look at Android to see how that will play out, and Apple
> are little better). On the other hand, I don't think Gemini is the
> place to address this; as I see it, Gemini stands on its own, with its
> own purpose, which does happen to align with the original purpose of
> the web, and is perhaps why it seems the obvious to modify in the ways
> you suggest (similar types of ideas crossed my mind too).
> 
> I personally think that the way to revive the web is to run HTTP on a
> different port so that content can be identified as separate from the
> current web, and where this implies a reduced level of functionality
> (e.g. content that can be rendered by Kristall, or Dillo, or Lynx,
> etc.). I've put a lighttpd server on port 1993 of my Gemini server,
> though I've had no reason to use it yet - I'm free to *not* use any
> web features I don't want to. :-)
> 
> Well done on getting your C client running, if you're sharing the
> code, I'd love to check it out!
> 
> Kevin
> gemini://gemini.susa.net/
> 
> On Fri, 14 Aug 2020 at 09:59, /dev/urandom <dev.urandom at posteo.org> wrote:
>> 
>> Hello everyone,
>> 
>> The recent news about the layoffs at Mozilla have left me wondering as
>> to whether the modern web has become too complex. I've heard people
>> discuss the Gemini protocol as a simplified alternative that is way
>> easier to work with. After checking it out (and even trying to write a
>> small experimental client in C, which thanks to libtls, ended up way
>> easier than I thought), it seems to be a really promising idea.
>> 
>> I was thinking about an idea similar to Gemini that could work as a
>> protocol for not just websites, but also simple and functional web
>> applications as well that could, to a reasonable extent, look and work
>> well on lots of different devices (desktops, smartphones, feature
>> phones, text-mode interfaces). After seeing how the Gemini protocol
>> works, it seems to me that a lot of these ideas could be implemented in
>> a backwards-compatible way or with minimal modifications to the
>> protocol.
>> 
>> 1. Basic form inputs / "widgets"
>> 
>> In addition to an "INPUT" response that only requests a line of text and
>> returns the question as a single line in the <META> field, some sort of
>> "extended input" could be useful. It could still be restricted to a
>> single query, but it could provide software-interpretable hints as to
>> what kind of input is preferable.
>> 
>> For example, a "check" input could provide a numbered list of options
>> and then ask the user to submit a query consisting a list of the
>> numbered items the user wants to select (or 0 if none). A more advanced
>> client program would then display the entire request as a series of
>> checkboxes or switches that the user can toggle. A "radio" or "button"
>> input could demand a single number, and the client would display the
>> items as a list of radio switches or buttons, of which only one can be
>> selected.
>> 
>> (I can imagine the description of the inputs either being part of the
>> <META> field, part of the previous page's text or maybe an "extended
>> input" could have its own response body that they're written in.)
>> 
>> Or a "date" input could say that it expects a date in the YYYY-MM-DD
>> format, but an advanced client could provide the user with a date picker
>> instead.
>> 
>> Either way, the general idea is that a simple client could just ask the
>> user to write the query as a line of text.
>> 
>> 2. Continuous connections
>> 
>> A user might want to not just give commands to a service, but also to
>> expect it to provide a continuous stream of information over a long
>> term. Most modern web pages use scripting to accomplish something like
>> that (and most web-browsers wait for a page to finish loading before
>> displaying it), but a minimal version of this seems achievable without
>> it.
>> 
>> An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE")
>> or mime-type (say, "text/gemini-continuous") would indicate that the
>> server will not give the entire response at once and then immediately
>> close the connection, but instead the connection will continue for a
>> long time, and instead of waiting for the entire text to be received,
>> the client should look for whenever a complete line arrives and print
>> that line.
>> 
>> The client could then use that connection to receive updates on the
>> request, until either the client or the server actually decides to close
>> the connection or it gets closed by some other means.
>> 
>> 3. Append mode
>> 
>> This is just a little extra feature, but the idea is that a page
>> (probably also via mime-type, like "text/gemini-append", or an
>> additional parameter, like "text/gemini; append") could indicate that
>> its contents should, if possible, be added at the end of the previous
>> page, rather than replacing it entirely.
>> 
>> ---
>> 
>> I would like to hear your opinions as to whether these ideas could, or
>> should, be added to the Gemini protocol, and in which specific ways if
>> so. Thank you all very much.


From kevin at susa.net  Fri Aug 14 15:26:18 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Fri, 14 Aug 2020 15:26:18 +0100
Subject: Thoughts about the Gemini protocol
In-Reply-To: <01EBED55-F55F-4637-B2D2-DD9003A7F0DB@sunshinegardens.org>
References: <be5bed891cff8a572902496308cde493@posteo.net>
 <CAPk6LxTWgo6D=boJm-KgLLEv7J=v6aSrp4fY5Kg-sxRwP5ZB7A@mail.gmail.com>
 <01EBED55-F55F-4637-B2D2-DD9003A7F0DB@sunshinegardens.org>
Message-ID: <CAPk6LxS4mB_tVd89D-d2xYNH4--f4h1HmZrxudDisFTMG=MJKg@mail.gmail.com>

I'm not sure if you intended to reply to me, but if so, I think you
are indeed mistaken. To be clear, I get Gemini, its simplicity and
immediacy are everything. I'd be happy if it stayed exactly as it is.

Kevin

On Fri, 14 Aug 2020 at 14:35, Matilde Park
<matilde.park at sunshinegardens.org> wrote:
>
> I think this proposal misunderstands the utility of the Gemini protocol, though I may myself be mistaken.
>
> The web itself shouldn?t have become a widget library, or a set of applications. The DOM is a poor replacement for something like GTK, et al., and HTML/JS/CSS has come pretty far in approximating it to an operating system by punting an operating system level of complexity to the client ? thus web browsers are unmaintainable by anyone other than corporations who can build an operating system to a specification.
>
> In this regard, I think protocols like gemini:// or gopher:// aren?t meant to *supplant* the web, but have a specialised purpose. There can be a very small, human scale specification. Let HTTP do what it?s become specialised to do; and in our own projects, abandon it. In doing so, you can avoid the incentives that brought clearnet where it is now.
>
> > On Aug 14, 2020, at 9:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> >
> > Hi,
> >
> > I think you're absolutely right that the scope of the web (or more
> > specifically, the web browser) has grown to the point that it might
> > soon be impractical to make use of it without Google's tech (and you
> > only need to look at Android to see how that will play out, and Apple
> > are little better). On the other hand, I don't think Gemini is the
> > place to address this; as I see it, Gemini stands on its own, with its
> > own purpose, which does happen to align with the original purpose of
> > the web, and is perhaps why it seems the obvious to modify in the ways
> > you suggest (similar types of ideas crossed my mind too).
> >
> > I personally think that the way to revive the web is to run HTTP on a
> > different port so that content can be identified as separate from the
> > current web, and where this implies a reduced level of functionality
> > (e.g. content that can be rendered by Kristall, or Dillo, or Lynx,
> > etc.). I've put a lighttpd server on port 1993 of my Gemini server,
> > though I've had no reason to use it yet - I'm free to *not* use any
> > web features I don't want to. :-)
> >
> > Well done on getting your C client running, if you're sharing the
> > code, I'd love to check it out!
> >
> > Kevin
> > gemini://gemini.susa.net/
> >
> > On Fri, 14 Aug 2020 at 09:59, /dev/urandom <dev.urandom at posteo.org> wrote:
> >>
> >> Hello everyone,
> >>
> >> The recent news about the layoffs at Mozilla have left me wondering as
> >> to whether the modern web has become too complex. I've heard people
> >> discuss the Gemini protocol as a simplified alternative that is way
> >> easier to work with. After checking it out (and even trying to write a
> >> small experimental client in C, which thanks to libtls, ended up way
> >> easier than I thought), it seems to be a really promising idea.
> >>
> >> I was thinking about an idea similar to Gemini that could work as a
> >> protocol for not just websites, but also simple and functional web
> >> applications as well that could, to a reasonable extent, look and work
> >> well on lots of different devices (desktops, smartphones, feature
> >> phones, text-mode interfaces). After seeing how the Gemini protocol
> >> works, it seems to me that a lot of these ideas could be implemented in
> >> a backwards-compatible way or with minimal modifications to the
> >> protocol.
> >>
> >> 1. Basic form inputs / "widgets"
> >>
> >> In addition to an "INPUT" response that only requests a line of text and
> >> returns the question as a single line in the <META> field, some sort of
> >> "extended input" could be useful. It could still be restricted to a
> >> single query, but it could provide software-interpretable hints as to
> >> what kind of input is preferable.
> >>
> >> For example, a "check" input could provide a numbered list of options
> >> and then ask the user to submit a query consisting a list of the
> >> numbered items the user wants to select (or 0 if none). A more advanced
> >> client program would then display the entire request as a series of
> >> checkboxes or switches that the user can toggle. A "radio" or "button"
> >> input could demand a single number, and the client would display the
> >> items as a list of radio switches or buttons, of which only one can be
> >> selected.
> >>
> >> (I can imagine the description of the inputs either being part of the
> >> <META> field, part of the previous page's text or maybe an "extended
> >> input" could have its own response body that they're written in.)
> >>
> >> Or a "date" input could say that it expects a date in the YYYY-MM-DD
> >> format, but an advanced client could provide the user with a date picker
> >> instead.
> >>
> >> Either way, the general idea is that a simple client could just ask the
> >> user to write the query as a line of text.
> >>
> >> 2. Continuous connections
> >>
> >> A user might want to not just give commands to a service, but also to
> >> expect it to provide a continuous stream of information over a long
> >> term. Most modern web pages use scripting to accomplish something like
> >> that (and most web-browsers wait for a page to finish loading before
> >> displaying it), but a minimal version of this seems achievable without
> >> it.
> >>
> >> An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE")
> >> or mime-type (say, "text/gemini-continuous") would indicate that the
> >> server will not give the entire response at once and then immediately
> >> close the connection, but instead the connection will continue for a
> >> long time, and instead of waiting for the entire text to be received,
> >> the client should look for whenever a complete line arrives and print
> >> that line.
> >>
> >> The client could then use that connection to receive updates on the
> >> request, until either the client or the server actually decides to close
> >> the connection or it gets closed by some other means.
> >>
> >> 3. Append mode
> >>
> >> This is just a little extra feature, but the idea is that a page
> >> (probably also via mime-type, like "text/gemini-append", or an
> >> additional parameter, like "text/gemini; append") could indicate that
> >> its contents should, if possible, be added at the end of the previous
> >> page, rather than replacing it entirely.
> >>
> >> ---
> >>
> >> I would like to hear your opinions as to whether these ideas could, or
> >> should, be added to the Gemini protocol, and in which specific ways if
> >> so. Thank you all very much.
>

From matilde.park at sunshinegardens.org  Fri Aug 14 15:28:33 2020
From: matilde.park at sunshinegardens.org (Matilde Park)
Date: Fri, 14 Aug 2020 10:28:33 -0400
Subject: Thoughts about the Gemini protocol
In-Reply-To: <CAPk6LxS4mB_tVd89D-d2xYNH4--f4h1HmZrxudDisFTMG=MJKg@mail.gmail.com>
References: <be5bed891cff8a572902496308cde493@posteo.net>
 <CAPk6LxTWgo6D=boJm-KgLLEv7J=v6aSrp4fY5Kg-sxRwP5ZB7A@mail.gmail.com>
 <01EBED55-F55F-4637-B2D2-DD9003A7F0DB@sunshinegardens.org>
 <CAPk6LxS4mB_tVd89D-d2xYNH4--f4h1HmZrxudDisFTMG=MJKg@mail.gmail.com>
Message-ID: <88EA7032-A2A8-4512-AE57-69C10A88EB5B@sunshinegardens.org>

Was responding to OP, sorry. (Getting a handle on mailing lists.)

> On Aug 14, 2020, at 10:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> 
> I'm not sure if you intended to reply to me, but if so, I think you
> are indeed mistaken. To be clear, I get Gemini, its simplicity and
> immediacy are everything. I'd be happy if it stayed exactly as it is.
> 
> Kevin
> 
> On Fri, 14 Aug 2020 at 14:35, Matilde Park
> <matilde.park at sunshinegardens.org> wrote:
>> 
>> I think this proposal misunderstands the utility of the Gemini protocol, though I may myself be mistaken.
>> 
>> The web itself shouldn?t have become a widget library, or a set of applications. The DOM is a poor replacement for something like GTK, et al., and HTML/JS/CSS has come pretty far in approximating it to an operating system by punting an operating system level of complexity to the client ? thus web browsers are unmaintainable by anyone other than corporations who can build an operating system to a specification.
>> 
>> In this regard, I think protocols like gemini:// or gopher:// aren?t meant to *supplant* the web, but have a specialised purpose. There can be a very small, human scale specification. Let HTTP do what it?s become specialised to do; and in our own projects, abandon it. In doing so, you can avoid the incentives that brought clearnet where it is now.
>> 
>>> On Aug 14, 2020, at 9:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
>>> 
>>> Hi,
>>> 
>>> I think you're absolutely right that the scope of the web (or more
>>> specifically, the web browser) has grown to the point that it might
>>> soon be impractical to make use of it without Google's tech (and you
>>> only need to look at Android to see how that will play out, and Apple
>>> are little better). On the other hand, I don't think Gemini is the
>>> place to address this; as I see it, Gemini stands on its own, with its
>>> own purpose, which does happen to align with the original purpose of
>>> the web, and is perhaps why it seems the obvious to modify in the ways
>>> you suggest (similar types of ideas crossed my mind too).
>>> 
>>> I personally think that the way to revive the web is to run HTTP on a
>>> different port so that content can be identified as separate from the
>>> current web, and where this implies a reduced level of functionality
>>> (e.g. content that can be rendered by Kristall, or Dillo, or Lynx,
>>> etc.). I've put a lighttpd server on port 1993 of my Gemini server,
>>> though I've had no reason to use it yet - I'm free to *not* use any
>>> web features I don't want to. :-)
>>> 
>>> Well done on getting your C client running, if you're sharing the
>>> code, I'd love to check it out!
>>> 
>>> Kevin
>>> gemini://gemini.susa.net/
>>> 
>>> On Fri, 14 Aug 2020 at 09:59, /dev/urandom <dev.urandom at posteo.org> wrote:
>>>> 
>>>> Hello everyone,
>>>> 
>>>> The recent news about the layoffs at Mozilla have left me wondering as
>>>> to whether the modern web has become too complex. I've heard people
>>>> discuss the Gemini protocol as a simplified alternative that is way
>>>> easier to work with. After checking it out (and even trying to write a
>>>> small experimental client in C, which thanks to libtls, ended up way
>>>> easier than I thought), it seems to be a really promising idea.
>>>> 
>>>> I was thinking about an idea similar to Gemini that could work as a
>>>> protocol for not just websites, but also simple and functional web
>>>> applications as well that could, to a reasonable extent, look and work
>>>> well on lots of different devices (desktops, smartphones, feature
>>>> phones, text-mode interfaces). After seeing how the Gemini protocol
>>>> works, it seems to me that a lot of these ideas could be implemented in
>>>> a backwards-compatible way or with minimal modifications to the
>>>> protocol.
>>>> 
>>>> 1. Basic form inputs / "widgets"
>>>> 
>>>> In addition to an "INPUT" response that only requests a line of text and
>>>> returns the question as a single line in the <META> field, some sort of
>>>> "extended input" could be useful. It could still be restricted to a
>>>> single query, but it could provide software-interpretable hints as to
>>>> what kind of input is preferable.
>>>> 
>>>> For example, a "check" input could provide a numbered list of options
>>>> and then ask the user to submit a query consisting a list of the
>>>> numbered items the user wants to select (or 0 if none). A more advanced
>>>> client program would then display the entire request as a series of
>>>> checkboxes or switches that the user can toggle. A "radio" or "button"
>>>> input could demand a single number, and the client would display the
>>>> items as a list of radio switches or buttons, of which only one can be
>>>> selected.
>>>> 
>>>> (I can imagine the description of the inputs either being part of the
>>>> <META> field, part of the previous page's text or maybe an "extended
>>>> input" could have its own response body that they're written in.)
>>>> 
>>>> Or a "date" input could say that it expects a date in the YYYY-MM-DD
>>>> format, but an advanced client could provide the user with a date picker
>>>> instead.
>>>> 
>>>> Either way, the general idea is that a simple client could just ask the
>>>> user to write the query as a line of text.
>>>> 
>>>> 2. Continuous connections
>>>> 
>>>> A user might want to not just give commands to a service, but also to
>>>> expect it to provide a continuous stream of information over a long
>>>> term. Most modern web pages use scripting to accomplish something like
>>>> that (and most web-browsers wait for a page to finish loading before
>>>> displaying it), but a minimal version of this seems achievable without
>>>> it.
>>>> 
>>>> An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE")
>>>> or mime-type (say, "text/gemini-continuous") would indicate that the
>>>> server will not give the entire response at once and then immediately
>>>> close the connection, but instead the connection will continue for a
>>>> long time, and instead of waiting for the entire text to be received,
>>>> the client should look for whenever a complete line arrives and print
>>>> that line.
>>>> 
>>>> The client could then use that connection to receive updates on the
>>>> request, until either the client or the server actually decides to close
>>>> the connection or it gets closed by some other means.
>>>> 
>>>> 3. Append mode
>>>> 
>>>> This is just a little extra feature, but the idea is that a page
>>>> (probably also via mime-type, like "text/gemini-append", or an
>>>> additional parameter, like "text/gemini; append") could indicate that
>>>> its contents should, if possible, be added at the end of the previous
>>>> page, rather than replacing it entirely.
>>>> 
>>>> ---
>>>> 
>>>> I would like to hear your opinions as to whether these ideas could, or
>>>> should, be added to the Gemini protocol, and in which specific ways if
>>>> so. Thank you all very much.
>> 


From kevin at susa.net  Fri Aug 14 15:31:23 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Fri, 14 Aug 2020 15:31:23 +0100
Subject: Thoughts about the Gemini protocol
In-Reply-To: <88EA7032-A2A8-4512-AE57-69C10A88EB5B@sunshinegardens.org>
References: <be5bed891cff8a572902496308cde493@posteo.net>
 <CAPk6LxTWgo6D=boJm-KgLLEv7J=v6aSrp4fY5Kg-sxRwP5ZB7A@mail.gmail.com>
 <01EBED55-F55F-4637-B2D2-DD9003A7F0DB@sunshinegardens.org>
 <CAPk6LxS4mB_tVd89D-d2xYNH4--f4h1HmZrxudDisFTMG=MJKg@mail.gmail.com>
 <88EA7032-A2A8-4512-AE57-69C10A88EB5B@sunshinegardens.org>
Message-ID: <CAPk6LxQXwE64Jz2JZZC3DEi-YD6QGkXzJVw3BkHGmh2X5davYg@mail.gmail.com>

Ha, mailing lists have always filled me with dread - unretractable
faux pas being central to my worries!

On Fri, 14 Aug 2020 at 15:28, Matilde Park
<matilde.park at sunshinegardens.org> wrote:
>
> Was responding to OP, sorry. (Getting a handle on mailing lists.)
>
> > On Aug 14, 2020, at 10:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> >
> > I'm not sure if you intended to reply to me, but if so, I think you
> > are indeed mistaken. To be clear, I get Gemini, its simplicity and
> > immediacy are everything. I'd be happy if it stayed exactly as it is.
> >
> > Kevin
> >
> > On Fri, 14 Aug 2020 at 14:35, Matilde Park
> > <matilde.park at sunshinegardens.org> wrote:
> >>
> >> I think this proposal misunderstands the utility of the Gemini protocol, though I may myself be mistaken.
> >>
> >> The web itself shouldn?t have become a widget library, or a set of applications. The DOM is a poor replacement for something like GTK, et al., and HTML/JS/CSS has come pretty far in approximating it to an operating system by punting an operating system level of complexity to the client ? thus web browsers are unmaintainable by anyone other than corporations who can build an operating system to a specification.
> >>
> >> In this regard, I think protocols like gemini:// or gopher:// aren?t meant to *supplant* the web, but have a specialised purpose. There can be a very small, human scale specification. Let HTTP do what it?s become specialised to do; and in our own projects, abandon it. In doing so, you can avoid the incentives that brought clearnet where it is now.
> >>
> >>> On Aug 14, 2020, at 9:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I think you're absolutely right that the scope of the web (or more
> >>> specifically, the web browser) has grown to the point that it might
> >>> soon be impractical to make use of it without Google's tech (and you
> >>> only need to look at Android to see how that will play out, and Apple
> >>> are little better). On the other hand, I don't think Gemini is the
> >>> place to address this; as I see it, Gemini stands on its own, with its
> >>> own purpose, which does happen to align with the original purpose of
> >>> the web, and is perhaps why it seems the obvious to modify in the ways
> >>> you suggest (similar types of ideas crossed my mind too).
> >>>
> >>> I personally think that the way to revive the web is to run HTTP on a
> >>> different port so that content can be identified as separate from the
> >>> current web, and where this implies a reduced level of functionality
> >>> (e.g. content that can be rendered by Kristall, or Dillo, or Lynx,
> >>> etc.). I've put a lighttpd server on port 1993 of my Gemini server,
> >>> though I've had no reason to use it yet - I'm free to *not* use any
> >>> web features I don't want to. :-)
> >>>
> >>> Well done on getting your C client running, if you're sharing the
> >>> code, I'd love to check it out!
> >>>
> >>> Kevin
> >>> gemini://gemini.susa.net/
> >>>
> >>> On Fri, 14 Aug 2020 at 09:59, /dev/urandom <dev.urandom at posteo.org> wrote:
> >>>>
> >>>> Hello everyone,
> >>>>
> >>>> The recent news about the layoffs at Mozilla have left me wondering as
> >>>> to whether the modern web has become too complex. I've heard people
> >>>> discuss the Gemini protocol as a simplified alternative that is way
> >>>> easier to work with. After checking it out (and even trying to write a
> >>>> small experimental client in C, which thanks to libtls, ended up way
> >>>> easier than I thought), it seems to be a really promising idea.
> >>>>
> >>>> I was thinking about an idea similar to Gemini that could work as a
> >>>> protocol for not just websites, but also simple and functional web
> >>>> applications as well that could, to a reasonable extent, look and work
> >>>> well on lots of different devices (desktops, smartphones, feature
> >>>> phones, text-mode interfaces). After seeing how the Gemini protocol
> >>>> works, it seems to me that a lot of these ideas could be implemented in
> >>>> a backwards-compatible way or with minimal modifications to the
> >>>> protocol.
> >>>>
> >>>> 1. Basic form inputs / "widgets"
> >>>>
> >>>> In addition to an "INPUT" response that only requests a line of text and
> >>>> returns the question as a single line in the <META> field, some sort of
> >>>> "extended input" could be useful. It could still be restricted to a
> >>>> single query, but it could provide software-interpretable hints as to
> >>>> what kind of input is preferable.
> >>>>
> >>>> For example, a "check" input could provide a numbered list of options
> >>>> and then ask the user to submit a query consisting a list of the
> >>>> numbered items the user wants to select (or 0 if none). A more advanced
> >>>> client program would then display the entire request as a series of
> >>>> checkboxes or switches that the user can toggle. A "radio" or "button"
> >>>> input could demand a single number, and the client would display the
> >>>> items as a list of radio switches or buttons, of which only one can be
> >>>> selected.
> >>>>
> >>>> (I can imagine the description of the inputs either being part of the
> >>>> <META> field, part of the previous page's text or maybe an "extended
> >>>> input" could have its own response body that they're written in.)
> >>>>
> >>>> Or a "date" input could say that it expects a date in the YYYY-MM-DD
> >>>> format, but an advanced client could provide the user with a date picker
> >>>> instead.
> >>>>
> >>>> Either way, the general idea is that a simple client could just ask the
> >>>> user to write the query as a line of text.
> >>>>
> >>>> 2. Continuous connections
> >>>>
> >>>> A user might want to not just give commands to a service, but also to
> >>>> expect it to provide a continuous stream of information over a long
> >>>> term. Most modern web pages use scripting to accomplish something like
> >>>> that (and most web-browsers wait for a page to finish loading before
> >>>> displaying it), but a minimal version of this seems achievable without
> >>>> it.
> >>>>
> >>>> An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE")
> >>>> or mime-type (say, "text/gemini-continuous") would indicate that the
> >>>> server will not give the entire response at once and then immediately
> >>>> close the connection, but instead the connection will continue for a
> >>>> long time, and instead of waiting for the entire text to be received,
> >>>> the client should look for whenever a complete line arrives and print
> >>>> that line.
> >>>>
> >>>> The client could then use that connection to receive updates on the
> >>>> request, until either the client or the server actually decides to close
> >>>> the connection or it gets closed by some other means.
> >>>>
> >>>> 3. Append mode
> >>>>
> >>>> This is just a little extra feature, but the idea is that a page
> >>>> (probably also via mime-type, like "text/gemini-append", or an
> >>>> additional parameter, like "text/gemini; append") could indicate that
> >>>> its contents should, if possible, be added at the end of the previous
> >>>> page, rather than replacing it entirely.
> >>>>
> >>>> ---
> >>>>
> >>>> I would like to hear your opinions as to whether these ideas could, or
> >>>> should, be added to the Gemini protocol, and in which specific ways if
> >>>> so. Thank you all very much.
> >>
>

From hello at matthewgraybosch.com  Fri Aug 14 16:22:19 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Fri, 14 Aug 2020 11:22:19 -0400
Subject: Installing CAPCOM on FreeBSD 12.1 (need gusmobile)
Message-ID: <20200814112219.36a7cadd@kether.phoenix.society>

Hi. I'm trying to get CAPCOM running on tanelorn.city, and I'm having
trouble getting the gusmobile library installed. Where can I find it,
since it doesn't appear to be available via pypi, and where should I
put it?

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>	gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From jan6 at tilde.ninja  Fri Aug 14 16:43:16 2020
From: jan6 at tilde.ninja (jan6 at tilde.ninja)
Date: Fri, 14 Aug 2020 18:43:16 +0300
Subject: Thoughts about the Gemini protocol
In-Reply-To: <57548a262cd4fcdc5f67e12897c76252@posteo.net>
Message-ID: <e06ed9e6-07bf-49a9-93f0-605fc6e7cd0e@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200814/09882b9b/attachment-0001.htm>

From jmcbray at carcosa.net  Fri Aug 14 17:34:36 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 14 Aug 2020 12:34:36 -0400
Subject: Installing CAPCOM on FreeBSD 12.1 (need gusmobile)
In-Reply-To: <20200814112219.36a7cadd@kether.phoenix.society> (Matthew
 Graybosch's message of "Fri, 14 Aug 2020 11:22:19 -0400")
References: <20200814112219.36a7cadd@kether.phoenix.society>
Message-ID: <87pn7tmbj7.fsf@dorothy.carcosa.net>

Matthew Graybosch <hello at matthewgraybosch.com> writes:

> Hi. I'm trying to get CAPCOM running on tanelorn.city, and I'm having
> trouble getting the gusmobile library installed. Where can I find it,
> since it doesn't appear to be available via pypi, and where should I
> put it?

Sorry, it's at https://git.carcosa.net/jmcbray/gusmobile. You can put it
in your PYTHONPATH and/or use setup.py to install it.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From tomasino at lavabit.com  Sat Aug 15 00:39:20 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 14 Aug 2020 23:39:20 +0000
Subject: gemini+stream://
Message-ID: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>

Several of us had a fruitful discussion about gemini streaming over in the IRC channel tonight. For those of you who don't IRC, the full logs of the channel are available from my weechat logs, updated nightly at 0000UTC:

gemini://tilde.black:1965/users/fox/irc/log.txt

I strongly believe there's tangible value in having streaming support for the text/gemini mime-type. We have the lovely chatroom proof-of-concept out there already, and a few minutes of brainstorming came up with speech-to-text broadcast radio using Watson's speech-to-text engine. The cool ideas already floating around solderpunk's head in his gemlog about Gemini applications haven't been forgotten either. There's an untapped goldmine here.

That being said, the protocol has a very simple flow defined currently wherein a client makes a request, the server responds, ends the connection, then the client processes it. Changing that fundamental behavior to support streaming is not an insignificant thing to ask of client authors, and some will have no desire to do so at all.

We've talked in the past about possibly serving a different response code to signify to a client that this resource wants to stream, but that was countered with valid reasoning. Tonight I tried making the argument for a text/gemini+stream mime-type instead. Lukee challenged that, and ultimately I have to admit it leaves out one important aspect of serving streaming content: the user should be aware that the resource intends to stream.

Whether we serve a mime-type, response code, or somehow talk solderpunk into content-length information, none of these will be available as information to the user before they select a link. The only way to make it clear to a user that a stream is intended for a link, then, is a protocol indicator.

gemini+stream://

That's my recommendation for several reasons:

1. We're not changing much in the default gemini protocol. What we are indicating is that the client should not wait for a connection close to begin processing/displaying content. We are also signaling to the user that this resource intends to stream. Everything else about the connection remains otherwise default gemini behavior. Giving it a new protocol name would suggest there's more differences here and possibly open a doorway for other scope creep.

2. By keeping gemini in the protocol name still this tightly couples it with Gemini. This isn't something that is designed to go off and live on its own or be in any way confused as its own system. There was discussion about Titan when this idea came up. I personally still prefer gemini+write:// for that extension for the same reasons as above, but as Alex is doing literally all the work on it himself, I defer to him.

3. It's not gemini:// and therefore it is inherently not a part of the gemini core requirements for clients. I think streaming is fascinating, but I don't want to suggest that it be a requirement to support it like we have for the text/gemini mime-type. It represents a different way of consuming data and presenting it that would turn a weekend project into a two weekend project. Having a supplemental protocol fits better.

4. (sort of related to #3) Having "something" as a standard avoids the vagueness we have right now where people will try whatever makes sense to them in the moment. They'll get it working on their personal client and that's the extent of it. With something defined we all have a common target.

5. It doesn't inherently limit itself to the text/gemini mime-type since the streaming behavior is indicated by the protocol itself. It could also stream plain text, for instance, or even an mp3. The individual mime would have to make sense in a streaming context, but the door is technically open.

6. It is still a single client-initiated request happening in the foreground. We aren't creating background threads of who-know-what running services. We're getting an ongoing document in real-time, that's all.

I believe this answers all the concerns we've had voiced before about streaming. It allows for an optional extension of gemini that explicitly allows for a persistent streaming connection without breaking anything natural or inherent in the core protocol. But please chime in and correct me if I've missed something important.

This turned into quite the post! Yeesh


From luke at marmaladefoo.com  Sat Aug 15 09:51:06 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 15 Aug 2020 09:51:06 +0100
Subject: [ANN] Fafi, a Racket-based client
In-Reply-To: <CAF3jwTnvMa-4A1TpkEucDJQ_z69fG05DOg1+VGH+3j+yLwjz4g@mail.gmail.com>
References: <CAF3jwTnvMa-4A1TpkEucDJQ_z69fG05DOg1+VGH+3j+yLwjz4g@mail.gmail.com>
Message-ID: <5F37A1FA.1050903@marmaladefoo.com>

On 12-Aug-2020 23:57, Andre Garzia wrote:
> I'm new to this list, to Racket, and to Gemini, but I am quite happy 
> to be here because I have an interesting project to share. I have 
> built a simple Graphical Gemini client using Racket, it should run in 
> any platform Racket runs (I have tested it on Windows, macOS and Linux).
>
> The most interesting parts of it are the fact that it supports tabs, 
> which is a feature I don't think is yet common among the clients, and 
> that it converts gemtext into a cute s-expression based representation.
>
> At the moment it doesn't pass all the 51 tests in the client torture 
> list but IIRC it passes more than 40 of them. Anyway, I need to fix 
> redirecton loops and I can't support some of the TLS stuff because 
> Racket is shipping TLS 1.2.

Welcome to the ecosystem!

Its great to see another client. There are a couple of other clients 
that support tabs like Kristall and amfora (that I know of). Others take 
the approach of forking the browsing session with a new window (like my 
own, GemiNaut). Personally I like to be able to use the normal OS 
features to manage application windows, and each fork of the browsing 
session feels more to me like a separate thread through Geminispace to 
be independently minimised, maximised, etc. Some folk seem to prefer 
tabs though.

On a slightly separate note, I saw from your profile you have a 
background in FirefoxOS. I know it had its ups and downs, but it does 
live on in KaiOS which is gaining a wide user base particularly outside 
Europe and North America. I have a a Nokia 2720 which I love as a flip 
phone, for its relative simplicity and for its battery life. There is a 
simple marketplace of apps.

So a quick question - do you think it could be possible to write a 
gemini client for KaiOS? Personally, it would be great to be able to 
check a few pages when on the move. And more importantly, it would open 
gemini up to a wide and diverse range of potential new users who may 
have a lot to contribute.

Best Wishes

  - Luke

From luke at marmaladefoo.com  Sat Aug 15 10:47:36 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 15 Aug 2020 10:47:36 +0100
Subject: gemini+stream://
In-Reply-To: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
Message-ID: <5F37AF38.2020503@marmaladefoo.com>

On 15-Aug-2020 00:39, James Tomasino wrote:
> Several of us had a fruitful discussion about gemini streaming over in the IRC channel tonight. For those of you who don't IRC, the full logs of the channel are available from my weechat logs, updated nightly at 0000UTC:
>
> gemini://tilde.black:1965/users/fox/irc/log.txt

Yes fruitful and robust in a friendly way - I enjoyed it.

Thanks for your write up which is a good and fair summary of some of the 
key points.
> I strongly believe there's tangible value in having streaming support for the text/gemini mime-type. We have the lovely chatroom proof-of-concept out there already, and a few minutes of brainstorming came up with speech-to-text broadcast radio using Watson's speech-to-text engine. The cool ideas already floating around solderpunk's head in his gemlog about Gemini applications haven't been forgotten either. There's an untapped goldmine here.
Personally I don't have a horse in the streaming race in terms of 
needing it. I think perhaps a good degree of the use cases could be 
captured by client based polling, but not all. I think things like live 
streaming of audio over gemini and similar binary streaming is way out 
of scope and there are better clients and protocols for that. Text 
streaming maybe, but it is a bit niche IMO and there are other options 
like IRC.
> That being said, the protocol has a very simple flow defined currently wherein a client makes a request, the server responds, ends the connection, then the client processes it. Changing that fundamental behavior to support streaming is not an insignificant thing to ask of client authors, and some will have no desire to do so at all.
For me one of the key benefits and attractions of the gemini protocol is 
its simplicity, which eases diverse implementation. Client 
request->server response and close. You know to expect a fixed block of 
content from the server that is the payload.

Mixing in a stream mode with the standard document mode does muddy the 
waters somewhat in terms of what expectations a client will have of the 
server behaviour, but as you way perhaps the main challenge is that 
client behaviour needs to be different in each mode. For example, if 
streaming text, it might be better to use a fixed window size (10 lines 
or 1 line even).

And clients need to know the difference between a server that is 
slow/timed out vs one that might push you some more content later.
> We've talked in the past about possibly serving a different response code to signify to a client that this resource wants to stream, but that was countered with valid reasoning. Tonight I tried making the argument for a text/gemini+stream mime-type instead. Lukee challenged that, and ultimately I have to admit it leaves out one important aspect of serving streaming content: the user should be aware that the resource intends to stream.

Its not just that end users can benefit from advance knowledge of the 
upcoming interaction, but it is clients too that can take appropriate 
action, for example to switch rendering mode, to not abandon a long 
timed stream that might otherwise seem to be broken, to offer a choice 
to the user, or decide not to handle it further. As we know in gemini 
there are no other headers we can use to indicate content length or what 
modes the client can accept.

> Whether we serve a mime-type, response code, or somehow talk solderpunk into content-length information, none of these will be available as information to the user before they select a link. The only way to make it clear to a user that a stream is intended for a link, then, is a protocol indicator.
>
> gemini+stream://
>
> That's my recommendation for several reasons:
>
> <snip>
>
> I believe this answers all the concerns we've had voiced before about streaming. It allows for an optional extension of gemini that explicitly allows for a persistent streaming connection without breaking anything natural or inherent in the core protocol. But please chime in and correct me if I've missed something important.
I think this is a nice solution, in that it clearly indicates the 
expectation the client should have about server behaviour and can act 
accordingly. Similarly as users click/activate links in their clients 
they will get an indication of a shift in server mode.

I suspect there may still be some corner cases of a text streaming mode 
that might need to be thought through. For example the streaming display 
window from a UI point of view. Is this always in the gift of the client 
or is it something the server/app author would want to determine? I can 
think of both modes being appropriate for different use cases. One mode 
might be a news ticker, another a sort of twitter feed (shudder), or a 
third, to send a "virtual screen" of a formatted status picture.

Similarly for other kinds of binary streaming (if you really want to go 
down that road), are there other sorts of metadata necessary? I don't 
know I'm not a specialist in this area at all.

But generally I think its a good solution to give it another protocol name.

Best wishes

  - Luke

From cage-dev at twistfold.it  Sat Aug 15 11:47:22 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 15 Aug 2020 12:47:22 +0200
Subject: gemini+stream://
In-Reply-To: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
Message-ID: <20200815104722.GA8841@kurosawa.casa.net>

On Fri, Aug 14, 2020 at 11:39:20PM +0000, James Tomasino wrote:

Hi!

Honestly i  fail to understand  why a new  scheme is needed  here. The
protocol already supports  stream as discussed in  a previous messages
and i  do no  see a lott  of advantages for  using a  different scheme
except (as you wrote) to signal to  the user that the content will not
end.

Probably i am missing something, please help me to understand.

>  6. It is  still a single client-initiated request  happening in the
> foreground. We  aren't creating background threads  of who-know-what
> running services.  We're getting  an ongoing document  in real-time,
> that's all.

I do not think this is entirely  true if you want to update/keep alive
the  UI  of  the  client  while   the  content  is  flowing  from  the
server. Some kind of concurrent works enter in the equation, i think.

Bye!
C.

From benulo at systemli.org  Sat Aug 15 11:48:58 2020
From: benulo at systemli.org (Ben)
Date: Sat, 15 Aug 2020 15:18:58 +0430
Subject: [ANN] Fafi, a Racket-based client
In-Reply-To: <5F37A1FA.1050903@marmaladefoo.com>
References: <CAF3jwTnvMa-4A1TpkEucDJQ_z69fG05DOg1+VGH+3j+yLwjz4g@mail.gmail.com>
 <5F37A1FA.1050903@marmaladefoo.com>
Message-ID: <7a884ffb-ba5a-17fd-11b4-c6cb3a0c50c7@systemli.org>

On 8/15/20 1:21 PM, Luke Emmet wrote:
> Its great to see another client. There are a couple of other clients 
> that support tabs like Kristall and amfora (that I know of). Others take 
> the approach of forking the browsing session with a new window (like my 
> own, GemiNaut).

If I recall Alrisha and Deedum also do tabbing.

diohsc handles this in an interesting way by letting the user create and 
manage a queue. Not exactly the same thing as having multiple sessions 
at once, but it's good in a single session when are using tabs as just a 
"read later" function. Links can be added either to the top or the 
bottom of the queue (or inserted), allowing you to branch as you will.

Ben

-- 
gemini://kwiecien.us/

From alex at alexwennerberg.com  Sat Aug 15 01:24:54 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Fri, 14 Aug 2020 17:24:54 -0700
Subject: [ANN] Flounder - a Gemini site builder/host
Message-ID: <C4X55HSR0CFE.404TD1BAK2R8@debian-thinkpad>

Hey all!

I've been working on a project based on Gemini that you might be
interested in:

=> https://flounder.online/

It's a simple website builder, kind of like Geocities for Gemini. I have
really enjoyed Gemini and the Gemini network and I wanted to create a
platform that made building static Gemini sites easy and accessible. I
was inspired by Solderpunk's work on Shizaru
(https://tildegit.org/solderpunk/shizaru/), where files are limited to
32KiB in size, which provides some interesting restrictions. I think
it's a cool way to get people into the "small web" who might be
interested in its principles politically or philosophically but lack the
technical abilities to use some of the existing tools. 

I also implement twtxt -- The twtxt protocol fits really well with
Gemini. It seems to be almost entirely inactive, but I think it's neat.

Right now, I'm only serving static content on Gemini via Agate. I want
to create more dynamic content (e.g. the homepage), but I haven't
prioritized that work yet. I also have yet to find a great way of
translating links between gemini / https (right now it's via proxy) It's
still very early in development, but it's usable and people seem to be
having fun so far. Feel free to join if you're interested!

You can find the Rust code here:
https://github.com/alexwennerberg/flounder I'd love any feedback or
contributions.

All the best,

Alex

From colecmac at protonmail.com  Sat Aug 15 15:54:48 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 15 Aug 2020 14:54:48 +0000
Subject: [ANN] Flounder - a Gemini site builder/host
In-Reply-To: <C4X55HSR0CFE.404TD1BAK2R8@debian-thinkpad>
References: <C4X55HSR0CFE.404TD1BAK2R8@debian-thinkpad>
Message-ID: <65UZ0wgRg3Sp_dnnilcT0Ej1wLFOBWDyyoyu7scgH4YeDZLVQwlz-BsgtdVmhmh8wD2ukhp2Ng4xKZdAxLXw58RjKeV8SrszV9-uGitGpzE=@protonmail.com>

Hello,

Flounder looks awesome, nice work. It's a beautiful website, and
looks great on Gemini too. To my knowledge this is the first time
gemtext has been used like this outside Gemini, like as a generic
format.

> I want to create more dynamic content (e.g. the homepage), but
> I haven't prioritized that work yet.

That would be great, the first thing I tried to do was visit
flounder.online in my Gemini browser but it didn't work of course.
Otherwise it's a bit confusing.

> I also have yet to find a great way of translating links between
> gemini / https (right now it's via proxy)

Could you explain more? I don't know Rust but I'd be happy to
help idea-wise.

The twtxt protocol sounds cool, and good addition to the small web.

Finally, you should check out gemlog.blue if you haven't already, on
the Web and Gemini. It's a similar project, but with a slightly different
focus, as the posts are only available on Gemini.

Cheers,
makeworld

??????? Original Message ???????
On Friday, August 14, 2020 8:24 PM, alex wennerberg <alex at alexwennerberg.com> wrote:

> Hey all!
>
> I've been working on a project based on Gemini that you might be
> interested in:
>
> => https://flounder.online/
>
> It's a simple website builder, kind of like Geocities for Gemini. I have
> really enjoyed Gemini and the Gemini network and I wanted to create a
> platform that made building static Gemini sites easy and accessible. I
> was inspired by Solderpunk's work on Shizaru
> (https://tildegit.org/solderpunk/shizaru/), where files are limited to
> 32KiB in size, which provides some interesting restrictions. I think
> it's a cool way to get people into the "small web" who might be
> interested in its principles politically or philosophically but lack the
> technical abilities to use some of the existing tools.
>
> I also implement twtxt -- The twtxt protocol fits really well with
> Gemini. It seems to be almost entirely inactive, but I think it's neat.
>
> Right now, I'm only serving static content on Gemini via Agate. I want
> to create more dynamic content (e.g. the homepage), but I haven't
> prioritized that work yet. I also have yet to find a great way of
> translating links between gemini / https (right now it's via proxy) It's
> still very early in development, but it's usable and people seem to be
> having fun so far. Feel free to join if you're interested!
>
> You can find the Rust code here:
> https://github.com/alexwennerberg/flounder I'd love any feedback or
> contributions.
>
> All the best,
>
> Alex



From kevin at susa.net  Sat Aug 15 17:00:18 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Sat, 15 Aug 2020 17:00:18 +0100
Subject: gemini+stream://
In-Reply-To: <20200815104722.GA8841@kurosawa.casa.net>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
Message-ID: <CAPk6LxSAMWzJZqEE3w1ac+HTHfripZ-6ZwtzDRtRhA7yzw-n1Q@mail.gmail.com>

Gemini currently allows a fetch-then-process model, while a URL that
refers to a streaming resource forces me to: -

a) intercept the response and make a decision on how to proceed, or
b) wait for a timeout

There's plenty of tech for which implementing the above is trivial,
but it's currently not mandatory. If my client pipes the output to
another process, there's no reason for either process *not* to wait
till the server closes the connection - I currently have every reason
to expect that the server is sending me data for any Gemini request.

Knowing in advance that a server will not close a connection means
that steaming works, existing clients don't hang or break, new clients
aren't forced to add extra complexity, and unnecessary requests can be
avoided entirely.

This is just my take, anyway!

Kevin

On Sat, 15 Aug 2020 at 11:47, cage <cage-dev at twistfold.it> wrote:
>
> On Fri, Aug 14, 2020 at 11:39:20PM +0000, James Tomasino wrote:
>
> Hi!
>
> Honestly i  fail to understand  why a new  scheme is needed  here. The
> protocol already supports  stream as discussed in  a previous messages
> and i  do no  see a lott  of advantages for  using a  different scheme
> except (as you wrote) to signal to  the user that the content will not
> end.
>
> Probably i am missing something, please help me to understand.
>
> >  6. It is  still a single client-initiated request  happening in the
> > foreground. We  aren't creating background threads  of who-know-what
> > running services.  We're getting  an ongoing document  in real-time,
> > that's all.
>
> I do not think this is entirely  true if you want to update/keep alive
> the  UI  of  the  client  while   the  content  is  flowing  from  the
> server. Some kind of concurrent works enter in the equation, i think.
>
> Bye!
> C.

From alex at alexwennerberg.com  Sat Aug 15 17:13:25 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Sat, 15 Aug 2020 09:13:25 -0700
Subject: [ANN] Flounder - a Gemini site builder/host
In-Reply-To: <65UZ0wgRg3Sp_dnnilcT0Ej1wLFOBWDyyoyu7scgH4YeDZLVQwlz-BsgtdVmhmh8wD2ukhp2Ng4xKZdAxLXw58RjKeV8SrszV9-uGitGpzE=@protonmail.com>
References: <65UZ0wgRg3Sp_dnnilcT0Ej1wLFOBWDyyoyu7scgH4YeDZLVQwlz-BsgtdVmhmh8wD2ukhp2Ng4xKZdAxLXw58RjKeV8SrszV9-uGitGpzE=@protonmail.com>
Message-ID: <3b6fdd52-46e6-1ec1-aae9-3c7796a8861e@alexwennerberg.com>

> Flounder looks awesome, nice work. It's a beautiful website, and
> looks great on Gemini too. To my knowledge this is the first time
> gemtext has been used like this outside Gemini, like as a generic
> format.

Thank you/! /
> That would be great, the first thing I tried to do was visit
> flounder.online in my Gemini browser but it didn't work of course.
> Otherwise it's a bit confusing.

Based on my research, it looks like the most mature tool for this is Molly Brown with CGI --
getting it working might be a weekend project for me.

> Could you explain more? I don't know Rust but I'd be happy to
> help idea-wise.

Basically the issue is -- a common use case would be for someone to want to link another flounder page from their page, for example I might link
my friend juliet.flounder.online's page from alex.flounder.online. A user who is using Flounder through a web app may use the link https://juliet.flounder.online
which isn't ideal when accessing it through gemini, since the link brings them out of Gemini. I think the solution is to instruct users to use
gemini:// links for other Flounder pages (and maybe put something in the UI that encourages this) and then convert gemini://x.flounder.online
to https://x.flounder.online when rendering it over https (right now I use the mozz.us proxy). I could also force this translation by modifying users' text when they save a file with
an https://x.flounder.online link but I'm not a fan of that. Maybe I could create some sort of warning that explains this, or even better I could come up
with a way to let people use simple tags like @alex and then translate that into a gemini URL on gemini or an https url on https.

 ?> The twtxt protocol sounds cool, and good addition to the small web.

I think there was a discussion earlier in the mailing list that inspired my idea!

> Finally, you should check out gemlog.blue if you haven't already, on
> the Web and Gemini. It's a similar project, but with a slightly different
> focus, as the posts are only available on Gemini.

This is very cool! I'll definitely have to glean some ideas from this

Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200815/9d2a0762/attachment.htm>

From easeout at tilde.team  Sat Aug 15 18:25:37 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Sat, 15 Aug 2020 13:25:37 -0400
Subject: gemini+stream://
In-Reply-To: <20200815104722.GA8841@kurosawa.casa.net>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
Message-ID: <20200815172537.GA1328426@tilde.team>

On Sat, Aug 15, 2020 at 12:47:22PM +0200, cage wrote:
> Honestly i  fail to understand  why a new  scheme is needed  here. The
> protocol already supports  stream as discussed in  a previous messages
> and i  do no  see a lott  of advantages for  using a  different scheme
> except (as you wrote) to signal to  the user that the content will not
> end.
> 
> Probably i am missing something, please help me to understand.

In our IRC discussion, we raised some user-facing guarantees of Gemini:

- You know that when you open a link, you're just getting that one file,
  not an implicit bundle of child requests

- You know the connection will not remain open after you have begun to
  see its content

As users, these guarantees feel good to us. And we have confidence in
these guarantees whenever we see a gemini:// link. So we would like to
keep that user confidence high. For that reason, we like the idea of
leaving the gemini:// scheme for content you download and then consume,
and a separate scheme for content you consume while the connaection
remains open.

> >  6. It is  still a single client-initiated request  happening in the
> > foreground. We  aren't creating background threads  of who-know-what
> > running services.  We're getting  an ongoing document  in real-time,
> > that's all.
> 
> I do not think this is entirely  true if you want to update/keep alive
> the  UI  of  the  client  while   the  content  is  flowing  from  the
> server. Some kind of concurrent works enter in the equation, i think.

I think the "foreground" versus "background" concept was really more
about what the user is made aware of. In that sense, a "background"
operation would be one that happens without the user's knowledge. We
like the idea that in Gemini, even if streamed, you don't stream
anything you're not aware of. If a second process or thread did the
work, but the user can see that happening, that's no problem.

From colecmac at protonmail.com  Sat Aug 15 18:41:39 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 15 Aug 2020 17:41:39 +0000
Subject: [ANN] Flounder - a Gemini site builder/host
In-Reply-To: <3b6fdd52-46e6-1ec1-aae9-3c7796a8861e@alexwennerberg.com>
References: <65UZ0wgRg3Sp_dnnilcT0Ej1wLFOBWDyyoyu7scgH4YeDZLVQwlz-BsgtdVmhmh8wD2ukhp2Ng4xKZdAxLXw58RjKeV8SrszV9-uGitGpzE=@protonmail.com>
 <3b6fdd52-46e6-1ec1-aae9-3c7796a8861e@alexwennerberg.com>
Message-ID: <n_3OGdUsxgGhuZ-Z9cgkIf_9b7GTGMxgJdZYpYhNWZhBSw3pBltLpVicysiQBuHrcGzcmj1FLytnqSHhL47qOeRoZhx5KRe4XhCMQs54St4=@protonmail.com>

> > That would be great, the first thing I tried to do was visit
> > flounder.online in my Gemini browser but it didn't work of course.
> > Otherwise it's a bit confusing.
>
> Based on my research, it looks like the most mature tool for this
> is Molly Brown with CGI -- getting it working might be a weekend
> project for me.

Good luck! There's also the Jetforce server which supports CGI very
well. It's written in Python.

> [url discussion]

I think encouraging all users to write gemini:// is not the way to go.
I feel like it's a potentially annoying UX point, and isn't meaningful
to anyone using flounder but not Gemini.

Personally I'd suggest letting people use whatever they want, and
translating on the fly if they're using the "wrong" protocol for the
request.

> a way to let people use simple tags like @alex and then translate that
> into a gemini URL on gemini or an https url on https.

This sounds pretty cool! I still the above is useful though.

gemlog.blue source code is here btw:
https://git.rawtext.club/sloum/gemlog.blue


Cheers,
makeworld

??????? Original Message ???????
On Saturday, August 15, 2020 12:13 PM, alex wennerberg <alex at alexwennerberg.com> wrote:

> > Flounder looks awesome, nice work. It's a beautiful website, and
> > looks great on Gemini too. To my knowledge this is the first time
> > gemtext has been used like this outside Gemini, like as a generic
> > format.
>
> Thank you!
> > That would be great, the first thing I tried to do was visit
> > flounder.online in my Gemini browser but it didn't work of course.
> > Otherwise it's a bit confusing.
>
> Based on my research, it looks like the most mature tool for this is Molly Brown with CGI --
> getting it working might be a weekend project for me.
>
> > Could you explain more? I don't know Rust but I'd be happy to
> > help idea-wise.
>
> Basically the issue is -- a common use case would be for someone to want to link another flounder page from their page, for example I might link
> my friend juliet.flounder.online's page from alex.flounder.online. A user who is using Flounder through a web app may use the link https://juliet.flounder.online
> which isn't ideal when accessing it through gemini, since the link brings them out of Gemini. I think the solution is to instruct users to use
> gemini:// links for other Flounder pages (and maybe put something in the UI that encourages this) and then convert gemini://x.flounder.online
> to https://x.flounder.online when rendering it over https (right now I use the mozz.us proxy). I could also force this translation by modifying users' text when they save a file with
> an https://x.flounder.online link but I'm not a fan of that. Maybe I could create some sort of warning that explains this, or even better I could come up
> with a way to let people use simple tags like @alex and then translate that into a gemini URL on gemini or an https url on https.
>
> ?> The twtxt protocol sounds cool, and good addition to the small web.
>
> I think there was a discussion earlier in the mailing list that inspired my idea!
>
> > Finally, you should check out gemlog.blue if you haven't already, on
> > the Web and Gemini. It's a similar project, but with a slightly different
> > focus, as the posts are only available on Gemini.
>
> This is very cool! I'll definitely have to glean some ideas from this
>
> Alex



From alex at alexwennerberg.com  Sat Aug 15 19:12:00 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Sat, 15 Aug 2020 11:12:00 -0700
Subject: [ANN] Flounder - a Gemini site builder/host
In-Reply-To: <n_3OGdUsxgGhuZ-Z9cgkIf_9b7GTGMxgJdZYpYhNWZhBSw3pBltLpVicysiQBuHrcGzcmj1FLytnqSHhL47qOeRoZhx5KRe4XhCMQs54St4=@protonmail.com>
Message-ID: <C4XRUJ2H3RGO.6PBV20FJ50KB@debian-thinkpad>

On Sat Aug 15, 2020 at 10:41 AM PDT,  wrote:
> Personally I'd suggest letting people use whatever they want, and
> translating on the fly if they're using the "wrong" protocol for the
> request.
>
> > a way to let people use simple tags like @alex and then translate that
> > into a gemini URL on gemini or an https url on https.
>
> This sounds pretty cool! I still the above is useful though.

I'll experiment with some things and get some feedback from users. I
like the @ idea because it's consistent with the twtxt interface I
wrote. I appreciate your feedback!


> gemlog.blue source code is here btw:
> https://git.rawtext.club/sloum/gemlog.blue

Thanks!

Alex

From zach at anemon.es  Sat Aug 15 19:35:07 2020
From: zach at anemon.es (=?utf-8?B?WmFjaCDimIHvuI4=?=)
Date: Sat, 15 Aug 2020 13:35:07 -0500
Subject: [ANN] Flounder - a Gemini site builder/host
In-Reply-To: <mailman.57.1597513305.459.gemini@lists.orbitalfox.eu>
References: <mailman.57.1597513305.459.gemini@lists.orbitalfox.eu>
Message-ID: <6C633CA1-684A-473B-94C4-78B2DE5E134B@anemon.es>

Hey alex,

This looks super cool and almost exactly the kind of thing I?ve been meaning to build for my friends to use. Is there anywhere you?d particularly like help? I won?t pretend to be a rust expert (and def not a gemini expert), but I should be able to contribute here and there.

Also I?m wondering how flexible flounder could be? I?d love to modify it so anyone on the server could add + edit pages + folders anywhere on the server. Since it?d be used by a group of friends (who love + trust each other), you wouldn?t have to worry about people coming in destroying others? stuff. More just a fun way to collaboratively build a site rather than being segregated into separate user folders.

Let me know what you think, and obviously would be totally happy to implement that weirdness in a fork. Would love to jump in and contribute either way!

Cheers,
Zach

From cage-dev at twistfold.it  Sat Aug 15 19:45:26 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 15 Aug 2020 20:45:26 +0200
Subject: gemini+stream://
In-Reply-To: <CAPk6LxSAMWzJZqEE3w1ac+HTHfripZ-6ZwtzDRtRhA7yzw-n1Q@mail.gmail.com>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
 <CAPk6LxSAMWzJZqEE3w1ac+HTHfripZ-6ZwtzDRtRhA7yzw-n1Q@mail.gmail.com>
Message-ID: <20200815184526.GB19347@kurosawa.casa.net>

On Sat, Aug 15, 2020 at 05:00:18PM +0100, Kevin Sangeelee wrote:

Hi Kevin!

Thank  you  for your  reply,  Hope  you do  not  mind  that, to  avoid
repeating the  same concepts,  i wrote  a single  message that  try to
answer to you and easeout at the same time.

Bye!
C.

From cage-dev at twistfold.it  Sat Aug 15 19:41:24 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 15 Aug 2020 20:41:24 +0200
Subject: gemini+stream://
In-Reply-To: <20200815172537.GA1328426@tilde.team>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
 <20200815172537.GA1328426@tilde.team>
Message-ID: <20200815184124.GA19347@kurosawa.casa.net>

On Sat, Aug 15, 2020 at 01:25:37PM -0400, easeout at tilde.team wrote:

Hi!

Thank you for your reply!

With this message i try to give an answer both to you an Kevin because
i feel my answer try to address the arguments raised by both of you.

> On Sat, Aug 15, 2020 at 12:47:22PM +0200, cage wrote:
> > Honestly i  fail to understand  why a new  scheme is needed  here. The
> > protocol already supports  stream as discussed in  a previous messages
> > and i  do no  see a lott  of advantages for  using a  different scheme
> > except (as you wrote) to signal to  the user that the content will not
> > end.
> >
> > Probably i am missing something, please help me to understand.
>
> In our IRC discussion, we raised some user-facing guarantees of Gemini:
>
> - You know that when you open a link, you're just getting that one file,
>   not an implicit bundle of child requests
> - You know the connection will not remain open after you have begun to
>   see its content

OK, my honest question  is now is: "is the last  point true?".  Let me
give you an example (sorry i have to talk about my work, i hope you do
not feel this annoying).

When i  started my client i  assumed all the content  was non streamed
and then, when  i discovered it was not i  felt very depressed because
my code  would be  useless, then  reading a  previous message  in this
mailing list I  started to assume every content got  from server was a
stream. And started to code following this assumption.

Now, the code  is crude and not  complete but it works  quite nice for
endless flow of  gemini formatted lines (so you see  the contents of a
gemini  file  while  the  connection  is  still  open)  but  also  for
downloading a single file, so there  is no need for different code for
streamed contents and non streamed contents.

(At this time  i could not handle, for example,  an endless audio file
but  i consider  this  an issue  of  my  client not  an  issue in  the
protocol.)

At this moment (assuming no bug in  my code and that i have understood
the proposal  correctly, two generous  assumptions to be  honest! :-D)
all i  need to  support 'gemini+stream://'  is just  to treat  it like
'gemini://'.

> As users, these guarantees feel good to us.

As an user too i agree! :)

> And we have confidence in
> these guarantees whenever we see a gemini:// link. So we would like to
> keep that user confidence high. For that reason, we like the idea of
> leaving the gemini:// scheme for content you download and then consume,
> and a separate scheme for content you consume while the connaection
> remains open.

OK i think i  kind to understand the point, so what  you propose it to
enforce the  second "guarantee" of  your list for  'gemini://' scheme,
and  leave  the  "live"  (sorry  i  can  not  find  a  better  word)
connections to the 'gemini+stream://' right?

> > >  6. It is  still a single client-initiated request  happening in the
> > > foreground. We  aren't creating background threads  of who-know-what
> > > running services.  We're getting  an ongoing document  in real-time,
> > > that's all.
> >
> > I do not think this is entirely  true if you want to update/keep alive
> > the  UI  of  the  client  while   the  content  is  flowing  from  the
> > server. Some kind of concurrent works enter in the equation, i think.
>
> I think the "foreground" versus "background" concept was really more
> about what the user is made aware of. In that sense, a "background"
> operation would be one that happens without the user's knowledge. We
> like the idea that in Gemini, even if streamed, you don't stream
> anything you're not aware of. If a second process or thread did the
> work, but the user can see that happening, that's no problem.

So I was entirely missing the point here! Thank you for clarifying this
to me! :)

Bye!
C.

From bouncepaw2 at yandex.ru  Sat Aug 15 19:53:55 2020
From: bouncepaw2 at yandex.ru (Timur Ismagilov)
Date: Sat, 15 Aug 2020 23:53:55 +0500
Subject: [ANN] Flounder - a Gemini site builder/host
Message-ID: <6608841597517635@sas1-30406100349c.qloud-c.yandex.net>

> To my knowledge this is the first time gemtext has been used like this outside Gemini, like as a generic format.

I feel obliged to tell you that my wiki engine was, in fact, the first application to implement gemtext outside gemini :)

=> https://github.com/bouncepaw/mycorrhiza

Fun fact: my gemtext implementation kinda contradicts the specification so it can better fit the whole wiki idea. It supports transclusion (a feature not easily implemented in an actual geminisphere), handles link urls differently (so it is easier to link other wiki pages, I call such links wiki links) and empty lines are handler roughly (they are ignored (the spec recommends rendering them with vertical space)).

~

Tried out the Flounder, it is really good!

=> https://bouncepaw.flounder.online/ My site

From alex at alexwennerberg.com  Sat Aug 15 19:42:58 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Sat, 15 Aug 2020 11:42:58 -0700
Subject: [ANN] Flounder - a Gemini site builder/host
In-Reply-To: <6C633CA1-684A-473B-94C4-78B2DE5E134B@anemon.es>
Message-ID: <C4XSI8L218YE.N12TO5Z9BDXB@debian-thinkpad>

On Sat Aug 15, 2020 at 11:35 AM PDT, Zach ?? wrote:
> Hey alex,
>
> This looks super cool and almost exactly the kind of thing I?ve been
> meaning to build for my friends to use. Is there anywhere you?d
> particularly like help? I won?t pretend to be a rust expert (and def
> not a gemini expert), but I should be able to contribute here and there.

The Rust code is a little wonky -- I'm experimenting with writing a
little more "low-level" code than I usually would, not using an ORM,
relying less on libraries and frameworks, but I'd love some help. I put
together some GitHub issues. Side note -- I know GitHub is very
un-"small web", but I am not super happy with the alternatives yet, so
consider it a necessary evil for now.

> Also I?m wondering how flexible flounder could be? I?d love to
> modify it so anyone on the server could add + edit pages + folders
> anywhere on the server. Since it?d be used by a group of friends (who
> love + trust each other), you wouldn?t have to worry about people
> coming in destroying others? stuff. More just a fun way to
> collaboratively build a site rather than being segregated into separate
> user folders.

I had actually thought about this! My idea was that you could share a
page with other users so that they could edit it. It's a great idea, but
I also want to take an extremely conservative approach to adding new
features. Something I may implement down the road. Thanks for the
suggestion.


> Let me know what you think, and obviously would be totally happy to
> implement that weirdness in a fork. Would love to jump in and contribute
> either way!
>
> Cheers,
> Zach


From tomasino at lavabit.com  Sat Aug 15 20:59:18 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sat, 15 Aug 2020 19:59:18 +0000
Subject: gemini+stream://
In-Reply-To: <20200815184124.GA19347@kurosawa.casa.net>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
 <20200815172537.GA1328426@tilde.team>
 <20200815184124.GA19347@kurosawa.casa.net>
Message-ID: <0f0a745a-d26c-002d-8601-68886a1a2d00@lavabit.com>

On 8/15/20 6:41 PM, cage wrote:
> OK, my honest question  is now is: "is the last  point true?".  Let me
> give you an example (sorry i have to talk about my work, i hope you do
> not feel this annoying).

This was the original point I missed as well when I first started talking about streaming in Gemini. According to the specification section 1.1, here's the transaction summary:

C:   Opens connection
S:   Accepts connection
C/S: Complete TLS handshake (see section 4)
C:   Validates server certificate (see 4.2)
C:   Sends request (one CRLF terminated line) (see section 2)
S:   Sends response header (one CRLF terminated line), closes connection
     under non-success conditions (see 3.1 and 3.2)
S:   Sends response body (text or binary data) (see 3.3)
S:   Closes connection
C:   Handles response (see 3.4)

Notice that final "Closes connection" before "Handles response". If that were reversed then the protocol would effectively assume everything was a stream and everyone's clients would be built in the manner you've been working toward. Since it's explicit that the connection closes first in the spec it's understandable that client authors built clients the way they have.

Your technique of treating everything as a stream may "just work" for gemini:// and gemini+stream:// both, honestly. Time will tell!


From easeout at tilde.team  Sat Aug 15 21:28:50 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Sat, 15 Aug 2020 16:28:50 -0400
Subject: gemini+stream://
In-Reply-To: <20200815184124.GA19347@kurosawa.casa.net>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
 <20200815172537.GA1328426@tilde.team>
 <20200815184124.GA19347@kurosawa.casa.net>
Message-ID: <20200815202850.GB1328426@tilde.team>

On Sat, Aug 15, 2020 at 08:41:24PM +0200, cage wrote:
> > - You know the connection will not remain open after you have begun to
> >   see its content
> 
> OK, my honest question is now is: "is the last point true?"

@tomasino's reply reflects my understanding, so yes, I think so.

> OK i think i  kind to understand the point, so what  you propose it to
> enforce the  second "guarantee" of  your list for  'gemini://' scheme,
> and  leave  the  "live"  (sorry  i  can  not  find  a  better  word)
> connections to the 'gemini+stream://' right?

Right!

From cage-dev at twistfold.it  Sat Aug 15 21:31:47 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 15 Aug 2020 22:31:47 +0200
Subject: gemini+stream://
In-Reply-To: <0f0a745a-d26c-002d-8601-68886a1a2d00@lavabit.com>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
 <20200815172537.GA1328426@tilde.team>
 <20200815184124.GA19347@kurosawa.casa.net>
 <0f0a745a-d26c-002d-8601-68886a1a2d00@lavabit.com>
Message-ID: <20200815203147.GA23200@kurosawa.casa.net>

On Sat, Aug 15, 2020 at 07:59:18PM +0000, James Tomasino wrote:

Hi!!

> On 8/15/20 6:41 PM, cage wrote:
> > OK, my honest question  is now is: "is the last  point true?".  Let me
> > give you an example (sorry i have to talk about my work, i hope you do
> > not feel this annoying).

>  This was the  original point I missed as well  when I first started
> talking about  streaming in  Gemini. According to  the specification
> section 1.1, here's the transaction summary:

[...]

> Notice that final "Closes  connection" before "Handles response". If
> that  were  reversed  then  the protocol  would  effectively  assume
> everything was a stream and everyone's clients would be built in the
> manner  you've been  working toward.  Since it's  explicit that  the
> connection closes first in the  spec it's understandable that client
> authors built clients the way they have.

Thank  you  very  much!  Now  i understand  what  i  was  missing  and
everything is more clear!

Now i think it is better that  i think a bit about all the information
in this thread.

> Your technique  of treating everything  as a stream may  "just work"
> for gemini:// and gemini+stream:// both, honestly. Time will tell!

And, in the meanwhile, i have a lot of bugs to fix! :))

Bye!
C.

From sotirisp at protonmail.com  Sat Aug 15 21:40:48 2020
From: sotirisp at protonmail.com (Sotiris Papatheodorou)
Date: Sat, 15 Aug 2020 20:40:48 +0000
Subject: [ANN] Visit gemini from qutebrowser
Message-ID: <20200815204045.GA1863@librem13.home>

Hi all!

I wanted to be able to visit both the web and geminispace from a single
program so I wrote a small userscript for qutebrowser. It downloads the
gemini content, converts it to Markdown and then to HTML using Pandoc.
Yes, it's an ugly hack and not all of gemini is implemented, but it
works acceptably well for browsing gemini content. 

The code is based on gcat so many thanks to it's authors!

Get it here:

https://git.sr.ht/~sotirisp/qute-gemini

Best,
Sotiris



From cage-dev at twistfold.it  Sat Aug 15 21:43:00 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 15 Aug 2020 22:43:00 +0200
Subject: gemini+stream://
In-Reply-To: <20200815202850.GB1328426@tilde.team>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
 <20200815104722.GA8841@kurosawa.casa.net>
 <20200815172537.GA1328426@tilde.team>
 <20200815184124.GA19347@kurosawa.casa.net>
 <20200815202850.GB1328426@tilde.team>
Message-ID: <20200815204300.GA23939@kurosawa.casa.net>

On Sat, Aug 15, 2020 at 04:28:50PM -0400, easeout at tilde.team wrote:

> > OK i think i  kind to understand the point, so what  you propose it to
> > enforce the  second "guarantee" of  your list for  'gemini://' scheme,
> > and  leave  the  "live"  (sorry  i  can  not  find  a  better  word)
> > connections to the 'gemini+stream://' right?
>
> Right!

Thank you for help me to understand!

Bye!
C.

From andre at andregarzia.com  Sun Aug 16 18:24:22 2020
From: andre at andregarzia.com (Andre Garzia)
Date: Sun, 16 Aug 2020 18:24:22 +0100
Subject: [ANN] Fafi, a Racket-based client
In-Reply-To: <5F37A1FA.1050903@marmaladefoo.com>
References: <CAF3jwTnvMa-4A1TpkEucDJQ_z69fG05DOg1+VGH+3j+yLwjz4g@mail.gmail.com>
 <5F37A1FA.1050903@marmaladefoo.com>
Message-ID: <CAF3jwTnN=Bbeac+Qr8NsVa0HM39MsgXdDBJ520R9nq24kK4rKg@mail.gmail.com>

Hi Luke,

Thanks a lot for the kind words. I am brand new to the ecosystem. I started
writing Fafi just from reading the protocol specs, I had no exposure to
other browsers and content. Now, I am getting to know more about apps and
content and am liking it very much. It is an impressive coincidence that I
checked out GemiNaut a bit before sending my first email to this list. I
took a tour of Gemini Browsers and saw that your browser had REBOL code in
it and that made me smile. I used to work with REBOL in the early 2000s and
it is a language that is very dear to my heart. I think that a Gemini
browser using Red should be a fantastic project, maybe I'll try that as
well.

As for Firefox OS, that is a little flame in my heart that will never be
extinguished, I really liked it and still do. I think that a client is
possible but you won't be able to support all the status codes and use
cases as you won't be able to generate certificates (unless you write a
pure JS TLS implementation). I'm not sure which version of OpenSSL KaiOS is
linked against but you should be able to open a raw TCP secure socket to
port 1965 and read and write from it using "mozTCPSocket":

  https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/TPC_Socket_API

Another thing that put a smile on me was the surprise I got when I was
researching to write the reply to you (it has been a while since I last
touched FirefoxOS code). If I remember correctly in 2013 I took some time
adding FirefoxOS samples to MDN  and the sample linked to that article is a
Telnet client I wrote:

  https://github.com/soapdog/firefoxos-sample-app-telnet-client

You should be able to pick that telnet client and just tweak it a little to
test it against a Gemini server. Be aware that KaiOS has a different
keyboard based navigation system and you'll need to check their dev docs:

  https://developer.kaiostech.com/

I don't have any KaiOS device but I am intrigued by it. Some months ago I
had a meeting with their DevRel to talk about the old days of FirefoxOS and
how community was handled and encouraged, it was a fun meeting and I hope
they are investing more in building a community now.

Kind Regards
A.


> Welcome to the ecosystem!
>
> Its great to see another client. There are a couple of other clients
> that support tabs like Kristall and amfora (that I know of). Others take
> the approach of forking the browsing session with a new window (like my
> own, GemiNaut). Personally I like to be able to use the normal OS
> features to manage application windows, and each fork of the browsing
> session feels more to me like a separate thread through Geminispace to
> be independently minimised, maximised, etc. Some folk seem to prefer
> tabs though.
>
> On a slightly separate note, I saw from your profile you have a
> background in FirefoxOS. I know it had its ups and downs, but it does
> live on in KaiOS which is gaining a wide user base particularly outside
> Europe and North America. I have a a Nokia 2720 which I love as a flip
> phone, for its relative simplicity and for its battery life. There is a
> simple marketplace of apps.
>
> So a quick question - do you think it could be possible to write a
> gemini client for KaiOS? Personally, it would be great to be able to
> check a few pages when on the move. And more importantly, it would open
> gemini up to a wide and diverse range of potential new users who may
> have a lot to contribute.
>
> Best Wishes
>
>   - Luke
>


-- 
https://www.andregarzia.com <http://www.andregarzia.com>
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200816/b8f35cbc/attachment.htm>

From andre at andregarzia.com  Sun Aug 16 18:26:38 2020
From: andre at andregarzia.com (Andre Garzia)
Date: Sun, 16 Aug 2020 18:26:38 +0100
Subject: [ANN] Fafi, a Racket-based client
In-Reply-To: <7a884ffb-ba5a-17fd-11b4-c6cb3a0c50c7@systemli.org>
References: <CAF3jwTnvMa-4A1TpkEucDJQ_z69fG05DOg1+VGH+3j+yLwjz4g@mail.gmail.com>
 <5F37A1FA.1050903@marmaladefoo.com>
 <7a884ffb-ba5a-17fd-11b4-c6cb3a0c50c7@systemli.org>
Message-ID: <CAF3jwTkM9qzOR=r_7m1ZNfXYFD_ESy3jU6uJ_nqdpn15Rv8+vg@mail.gmail.com>

I'm discovering so many new browsers in this thread. It is very inspiring.
Thanks a ton for sharing these projects with me. I think I'll experiment
with some of these approaches as well.

On Sat, 15 Aug 2020 at 11:49, Ben <benulo at systemli.org> wrote:

> On 8/15/20 1:21 PM, Luke Emmet wrote:
> > Its great to see another client. There are a couple of other clients
> > that support tabs like Kristall and amfora (that I know of). Others take
> > the approach of forking the browsing session with a new window (like my
> > own, GemiNaut).
>
> If I recall Alrisha and Deedum also do tabbing.
>
> diohsc handles this in an interesting way by letting the user create and
> manage a queue. Not exactly the same thing as having multiple sessions
> at once, but it's good in a single session when are using tabs as just a
> "read later" function. Links can be added either to the top or the
> bottom of the queue (or inserted), allowing you to branch as you will.
>
> Ben
>
> --
> gemini://kwiecien.us/
>


-- 
https://www.andregarzia.com <http://www.andregarzia.com>
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200816/5f7dba7b/attachment.htm>

From solderpunk at posteo.net  Sun Aug 16 19:32:50 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 16 Aug 2020 20:32:50 +0200
Subject: Track spec changes in git
In-Reply-To: <20200811190046.GA9507@kurosawa.casa.net>
Message-ID: <C4YMX0MM2ABZ.2AS1EF1OQMTI0@stilgar>

On Tue Aug 11, 2020 at 9:00 PM CEST, cage wrote:
> On Mon, Aug 10, 2020 at 10:10:49PM +0200, Solderpunk wrote:
> > The spec (and FAQ, best practices, etc) do actually live in a git repo,
> > I have just been lazy so far about making it publically cloneable,
> > although people do keep asking.  I'm not opposed, just haven't gotten
> > around to it yet.  I will try to do so this week, though.
>
> Great! Thank you! :)
>
> C.

This is finally possible!  Sorry for the long wait, to everybody who has
been asking for this.  You should be able to:

git clone git://gemini.circumlunar.space/gemini-site

and end up with a repo which contains the entire
gemini://gemini.circumlunar.space site, except for the CAPCOM instance
(which is powered by a cronjob) and, of course, the user directories.
So, you'll find the current specification under docs/specification.gmi
in your cloned repo.

If you wind the history back far enough in time, it will jump from
containing the entire site to containing just the essential documents
and, at the very first commit, only the (then very rough!)
specification.

I hope people enjoy this glimpse into the history of the protocol!

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Aug 16 19:57:49 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 16 Aug 2020 20:57:49 +0200
Subject: [ANN] Fafi, a Racket-based client
In-Reply-To: <7a884ffb-ba5a-17fd-11b4-c6cb3a0c50c7@systemli.org>
Message-ID: <C4YNG5KW7PP2.2VS14H3IQEKME@stilgar>

On Sat Aug 15, 2020 at 12:48 PM CEST, Ben wrote:

> diohsc handles this in an interesting way by letting the user create and
> manage a queue. Not exactly the same thing as having multiple sessions
> at once, but it's good in a single session when are using tabs as just a
> "read later" function. Links can be added either to the top or the
> bottom of the queue (or inserted), allowing you to branch as you will.

Ah, this is nice.  I have been meaning for a long time to tweak the
`tour` command in AV-98 (and VF-1) to allow you to insert links at the
front of the queue rather than the end.  This would make the mechanism a
lot more flexible.

Cheers,
Solderpunk

From cage-dev at twistfold.it  Sun Aug 16 20:50:54 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 16 Aug 2020 21:50:54 +0200
Subject: Track spec changes in git
In-Reply-To: <C4YMX0MM2ABZ.2AS1EF1OQMTI0@stilgar>
References: <20200811190046.GA9507@kurosawa.casa.net>
 <C4YMX0MM2ABZ.2AS1EF1OQMTI0@stilgar>
Message-ID: <20200816195054.GA33000@kurosawa.casa.net>

On Sun, Aug 16, 2020 at 08:32:50PM +0200, Solderpunk wrote:

[...]

> I hope people enjoy this glimpse into the history of the protocol!

Thank you Solderpunk! Browsing  the changes happened to specifications
is not only useful but also fascinating someway!

Bye!
C.

From idf31 at memeware.net  Sun Aug 16 23:26:13 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Mon, 17 Aug 2020 01:26:13 +0300
Subject: Working on a gemini server
Message-ID: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>

Hello. I've recently discovered Gemini, and I am really interested in 
it! I have surfed the Gopherspace for some time, and I find Gemini very 
neat as a modern Small Internet Protocol. I have decided to make a 
server for the gemini protocol, more like an exercise. I want it to have 
a small codebase and be light on resources(my apologies if this sounds 
repetitive). I plan to use it in the future to host a bigger scale 
project in the gemini-space, so the end-goal is still an usable and 
secure server that could be used in real life. Any suggestion or help is 
appreciated, as this is my first attempt at making a server.

The source code is located here: https://github.com/IDF31/geminim

To build it you would need the Nim programming language. You can install 
it here: https://nim-lang.org/install.html.
Then to compile it you run "nimble -d:ssl build" in the source 
directory. For now it expects a certificate "mycert.pem" and a private 
key "mykey.pem" in the same directory as the binary for the TLS 
connection, a configuration system will be added soon(tm).
The server is(for now) looking for a directory named "pub" in the same 
directory as the binary.
It uses the default gemini port(1965).

From kevin at susa.net  Mon Aug 17 00:05:54 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 17 Aug 2020 00:05:54 +0100
Subject: Working on a gemini server
In-Reply-To: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
References: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
Message-ID: <CAPk6LxSwoYJ5eLEHZUZNB3k-G1GGu_JELVEeAc8NKBd2apr_qA@mail.gmail.com>

Your nimble file requires a more recent build of Nim (1.3.x) than the
latest binaries release (1.2.6), yet it seems to build fine on 1.2.6.
Was this just an oversight, or will I run into problems?

Interesting regardless, my first Nim compile - thanks!

Kevin

On Sun, 16 Aug 2020 at 23:26, <idf31 at memeware.net> wrote:
>
> Hello. I've recently discovered Gemini, and I am really interested in
> it! I have surfed the Gopherspace for some time, and I find Gemini very
> neat as a modern Small Internet Protocol. I have decided to make a
> server for the gemini protocol, more like an exercise. I want it to have
> a small codebase and be light on resources(my apologies if this sounds
> repetitive). I plan to use it in the future to host a bigger scale
> project in the gemini-space, so the end-goal is still an usable and
> secure server that could be used in real life. Any suggestion or help is
> appreciated, as this is my first attempt at making a server.
>
> The source code is located here: https://github.com/IDF31/geminim
>
> To build it you would need the Nim programming language. You can install
> it here: https://nim-lang.org/install.html.
> Then to compile it you run "nimble -d:ssl build" in the source
> directory. For now it expects a certificate "mycert.pem" and a private
> key "mykey.pem" in the same directory as the binary for the TLS
> connection, a configuration system will be added soon(tm).
> The server is(for now) looking for a directory named "pub" in the same
> directory as the binary.
> It uses the default gemini port(1965).

From ehmry at posteo.net  Mon Aug 17 07:40:20 2020
From: ehmry at posteo.net (Emery Hemingway)
Date: Mon, 17 Aug 2020 08:40:20 +0200
Subject: Working on a gemini server
In-Reply-To: <CAPk6LxSwoYJ5eLEHZUZNB3k-G1GGu_JELVEeAc8NKBd2apr_qA@mail.gmail.com>
References: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
 <CAPk6LxSwoYJ5eLEHZUZNB3k-G1GGu_JELVEeAc8NKBd2apr_qA@mail.gmail.com>
Message-ID: <75024736-3684-4038-91bc-b72c0ff18705@posteo.net>

Thats not a problem, the Nim tools will do the safest thing when
generating the Nimble metadata and peg the minimum required compiler
and standard library at the current version, but its generally fine
to walk back a few version.

E.

On Monday, August 17, 2020 1:05:54 AM CEST, Kevin Sangeelee wrote:
> Your nimble file requires a more recent build of Nim (1.3.x) than the
> latest binaries release (1.2.6), yet it seems to build fine on 1.2.6.
> Was this just an oversight, or will I run into problems?
>
> Interesting regardless, my first Nim compile - thanks!
>
> Kevin
>
> On Sun, 16 Aug 2020 at 23:26, <idf31 at memeware.net> wrote:
>> Hello. I've recently discovered Gemini, and I am really interested in
>> it! I have surfed the Gopherspace for some time, and I find Gemini very
>> neat as a modern Small Internet Protocol. I have decided to make a
>> server for the gemini protocol, more like an exercise. I want it to have
>> a small codebase and be light on resources(my apologies if this sounds ...
>
>


From alex at gnu.org  Mon Aug 17 09:10:50 2020
From: alex at gnu.org (Alex Schroeder)
Date: Mon, 17 Aug 2020 10:10:50 +0200
Subject: Working on a gemini server
In-Reply-To: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
References: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
Message-ID: <453beb064570dab163aca53d5cd67541b3b7c899.camel@gnu.org>

On Mon, 2020-08-17 at 01:26 +0300, idf31 at memeware.net wrote:
> I have decided to make a 
> server for the gemini protocol, more like an exercise.

This seems to be some sort of initiation rite for some people: to write
a client or a server for Gemini, in a programming language that hasn't
been taken, yet.

Welcome!

Where's the site you're hosting? ?



From idf31 at memeware.net  Mon Aug 17 09:50:31 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Mon, 17 Aug 2020 11:50:31 +0300
Subject: Working on a gemini server
In-Reply-To: <CAPk6LxSwoYJ5eLEHZUZNB3k-G1GGu_JELVEeAc8NKBd2apr_qA@mail.gmail.com>
References: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
 <CAPk6LxSwoYJ5eLEHZUZNB3k-G1GGu_JELVEeAc8NKBd2apr_qA@mail.gmail.com>
Message-ID: <da5ee1017ef89d4133c6437c2db2a37d@memeware.net>

On 2020-08-17 02:05, Kevin Sangeelee wrote:
> Your nimble file requires a more recent build of Nim (1.3.x) than the
> latest binaries release (1.2.6), yet it seems to build fine on 1.2.6.
> Was this just an oversight, or will I run into problems?
> 
> Interesting regardless, my first Nim compile - thanks!
> 
> Kevin
> 
> On Sun, 16 Aug 2020 at 23:26, <idf31 at memeware.net> wrote:
>> 
>> Hello. I've recently discovered Gemini, and I am really interested in
>> it! I have surfed the Gopherspace for some time, and I find Gemini 
>> very
>> neat as a modern Small Internet Protocol. I have decided to make a
>> server for the gemini protocol, more like an exercise. I want it to 
>> have
>> a small codebase and be light on resources(my apologies if this sounds
>> repetitive). I plan to use it in the future to host a bigger scale
>> project in the gemini-space, so the end-goal is still an usable and
>> secure server that could be used in real life. Any suggestion or help 
>> is
>> appreciated, as this is my first attempt at making a server.
>> 
>> The source code is located here: https://github.com/IDF31/geminim
>> 
>> To build it you would need the Nim programming language. You can 
>> install
>> it here: https://nim-lang.org/install.html.
>> Then to compile it you run "nimble -d:ssl build" in the source
>> directory. For now it expects a certificate "mycert.pem" and a private
>> key "mykey.pem" in the same directory as the binary for the TLS
>> connection, a configuration system will be added soon(tm).
>> The server is(for now) looking for a directory named "pub" in the same
>> directory as the binary.
>> It uses the default gemini port(1965).

You can use the 1.2.6 version just fine, atleast at the curent stage of 
my project. Nimble picks whatever my Nim version is as the minimum one 
when generating a .nimble, and I'm using a devel version because a lot 
of features(mostly related to optimisation) are being worked on. I guess 
it is an oversight, I'll change the minimum version to 1.2.6, as a devel 
version isnt really required. Also cool first Nim compile :D

From idf31 at memeware.net  Mon Aug 17 09:55:14 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Mon, 17 Aug 2020 11:55:14 +0300
Subject: Working on a gemini server
In-Reply-To: <453beb064570dab163aca53d5cd67541b3b7c899.camel@gnu.org>
References: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
 <453beb064570dab163aca53d5cd67541b3b7c899.camel@gnu.org>
Message-ID: <68bd98ad8cc4488764fa1548e27fe00c@memeware.net>

On 2020-08-17 11:10, Alex Schroeder wrote:
> On Mon, 2020-08-17 at 01:26 +0300, idf31 at memeware.net wrote:
>> I have decided to make a
>> server for the gemini protocol, more like an exercise.
> 
> This seems to be some sort of initiation rite for some people: to write
> a client or a server for Gemini, in a programming language that hasn't
> been taken, yet.
> 
> Welcome!
> 
> Where's the site you're hosting? ?

Thank you! I am not hosting a site *yet*, I'm planning to rent a VPS in 
the near future. I will update you when it will be up!
As for the initiation rite, my apologies if the Gemini software is a bit 
saturated :P.

From alex at gnu.org  Mon Aug 17 10:05:16 2020
From: alex at gnu.org (Alex Schroeder)
Date: Mon, 17 Aug 2020 11:05:16 +0200
Subject: Working on a gemini server
In-Reply-To: <68bd98ad8cc4488764fa1548e27fe00c@memeware.net>
References: <8cd76e85ff0da0662bcf38cd5e07cd70@memeware.net>
 <453beb064570dab163aca53d5cd67541b3b7c899.camel@gnu.org>
 <68bd98ad8cc4488764fa1548e27fe00c@memeware.net>
Message-ID: <0d2db94716527a52b351853756ebe14889c13ab1.camel@gnu.org>

On Mon, 2020-08-17 at 11:55 +0300, idf31 at memeware.net wrote:
> As for the initiation rite, my apologies if the Gemini software is a
> bit 
> saturated :P.

No worries! As far as I'm concerned, this is a sign that the design
goal has been achieved: a standard so simple that many people can make
the software necessary (unlike the browser behemoths most of us use as
well, which are essentially super cool virtual machines...) ? as far as
I'm concerned, the more the merrier. This is not a zero-sum game. ?

Cheers
Alex



From andre at andregarzia.com  Mon Aug 17 11:12:34 2020
From: andre at andregarzia.com (Andre Garzia)
Date: Mon, 17 Aug 2020 11:12:34 +0100
Subject: Vulnerability in GnuTLS discovered
Message-ID: <CAF3jwTnPwNybUrm=KL3cfpyCtw4v=Ob7G9VBBP0Cvo2-KtHpEg@mail.gmail.com>

I don't know if anyone here is using GnuTLS in their software here but a
new CVE shows that GnuTLS has been buggy (and thus not safe) for the past
10 releases:

https://anarc.at/blog/2020-06-10-gnutls-audit/


A.
-- 
https://www.andregarzia.com <http://www.andregarzia.com>
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200817/80cb8d7d/attachment.htm>

From benulo at systemli.org  Mon Aug 17 16:51:48 2020
From: benulo at systemli.org (Ben)
Date: Mon, 17 Aug 2020 20:21:48 +0430
Subject: Delta Chat Group
Message-ID: <978c0007-04de-cc6a-619f-8223dc8086eb@systemli.org>

Hey everybody, so I thought it would be in the Gemini spirit to create a 
friendly group on Delta Chat. It seemed logical since we are fans of 
e-mail and already have our own unique providers, this could be a good 
supplement to the mailing list. It can provide us a little space to 
socialize in semi-real-time, but it doesn't have to be fast-paced 
either. (So I recommend turning off read-receipts in the client.)

The group should be publicly listed at https://publicgroups.0x90.space/ 
however bear in mind the public group bot and corresponding site are 
still very buggy and it might randomly not work. Instead it is easier to 
just send me a message and ask me to add you.

Cheers,
Ben

-- 
gemini://kwiecien.us/

From epoch at enzo.thebackupbox.net  Mon Aug 17 17:17:27 2020
From: epoch at enzo.thebackupbox.net (epoch)
Date: Mon, 17 Aug 2020 11:17:27 -0500
Subject: gemini+stream://
In-Reply-To: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
Message-ID: <20200817161727.f3dfxsvpljzn4jj4@enzo.thebackupbox.net>

> gemini+stream://

I've said this on IRC, but just so it gets seen in the mailing list too...

Usage of a + in URI schemes is usually for when a protocol is being sent over another protocol.
For example svn+ssh:// (svn protocol over an ssh connection) [1] [2]
I think it should be gemini-stream://

[1] https://www.iana.org/assignments/uri-schemes/prov/svn
[2] https://github.com/whatwg/url/issues/230
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200817/a3d1aa20/attachment.sig>

From felix at masterq32.de  Mon Aug 17 19:28:24 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Mon, 17 Aug 2020 20:28:24 +0200
Subject: gemini+stream://
In-Reply-To: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
References: <5ae8b513-53f7-53a7-c95a-0ee6230781ae@lavabit.com>
Message-ID: <d7db725a-4415-9fac-a078-383daf2f2b7c@masterq32.de>

Heya!

> [Encoding the "is stream" information in the URL scheme]

I really love this idea! It's easy to recognize for the user and the
tools. Clients can just not support `gemini-stream://` and do their
default behaviour for `gemini://`.

I like it!

Regards
- xq

From luke at marmaladefoo.com  Tue Aug 18 09:39:36 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 18 Aug 2020 09:39:36 +0100
Subject: [ANN] Fafi, a Racket-based client
In-Reply-To: <CAF3jwTnN=Bbeac+Qr8NsVa0HM39MsgXdDBJ520R9nq24kK4rKg@mail.gmail.com>
References: <CAF3jwTnvMa-4A1TpkEucDJQ_z69fG05DOg1+VGH+3j+yLwjz4g@mail.gmail.com>
 <5F37A1FA.1050903@marmaladefoo.com>
 <CAF3jwTnN=Bbeac+Qr8NsVa0HM39MsgXdDBJ520R9nq24kK4rKg@mail.gmail.com>
Message-ID: <5F3B93C8.70304@marmaladefoo.com>

Hi Andre

thanks for your reply

On 16-Aug-2020 18:24, Andre Garzia wrote:
> I took a tour of Gemini Browsers and saw that your browser had REBOL 
> code in it and that made me smile. I used to work with REBOL in the 
> early 2000s and it is a language that is very dear to my heart. I 
> think that a Gemini browser using Red should be a fantastic project, 
> maybe I'll try that as well.

Yes REBOL/Red is very nice, but largely under-appreciated, and somewhat 
niche now I suppose.

A Red client would be cool - I think the TLS is WIP in Red, but 
apparently it is being developed. There is also a fork of REBOL which is 
being actively maintained and seems to include TLS. I've not 
investigated it much yet though.

https://github.com/Oldes/Rebol3

>
> As for Firefox OS, that is a little flame in my heart that will never 
> be extinguished, I really liked it and still do. I think that a client 
> is possible but you won't be able to support all the status codes and 
> use cases as you won't be able to generate certificates (unless you 
> write a pure JS TLS implementation). I'm not sure which version of 
> OpenSSL KaiOS is linked against but you should be able to open a raw 
> TCP secure socket to port 1965 and read and write from it using 
> "mozTCPSocket":
>
> https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/TPC_Socket_API
>
> Another thing that put a smile on me was the surprise I got when I was 
> researching to write the reply to you (it has been a while since I 
> last touched FirefoxOS code). If I remember correctly in 2013 I took 
> some time adding FirefoxOS samples to MDN  and the sample linked to 
> that article is a Telnet client I wrote:
>
> https://github.com/soapdog/firefoxos-sample-app-telnet-client
>
> You should be able to pick that telnet client and just tweak it a 
> little to test it against a Gemini server. Be aware that KaiOS has a 
> different keyboard based navigation system and you'll need to check 
> their dev docs:
>
> https://developer.kaiostech.com/
>
> I don't have any KaiOS device but I am intrigued by it. Some months 
> ago I had a meeting with their DevRel to talk about the old days of 
> FirefoxOS and how community was handled and encouraged, it was a fun 
> meeting and I hope they are investing more in building a community now.

Thanks for these links - I shall add this to my todo list and 
investigate further. It would be interesting to see how far it can go. I 
think the client generated certificates is only a minor limitation, as 
the overwhelming majority of content in geminispace is freely accessible.

Best Wishes

  - Luke


From ehmry at posteo.net  Tue Aug 18 13:50:03 2020
From: ehmry at posteo.net (Emery Hemingway)
Date: Tue, 18 Aug 2020 14:50:03 +0200
Subject: Dhall description of Gemini
Message-ID: <de3c1fbc-739b-4cb2-ad68-bb07e2c3ac68@posteo.net>

Hello,

I wrote a description of Gemini text using the total functional language
Dhall which can potentially be used for document generation. The
description is made with only the primitives of the language, and if
anyone else finds it useful, could lead to a canonical Dhall represenation
that can be used in reusable document generation libraries. Eventually I
plan to use the description for some self-documenting system stuff.

There are basically two components to the description, the type and
rendering function:

https://git.sr.ht/~ehmry/dhall-gemini/tree/master/Line.dhall
https://git.sr.ht/~ehmry/dhall-gemini/tree/master/render.dhall

I wrote a small example of how to use the description:

gemini://gemini.spam.works/users/emery/dhall-gemini.gmi

Cheers,
E.

From dave at ratfactor.com  Tue Aug 18 19:50:55 2020
From: dave at ratfactor.com (Dave Gauer)
Date: Tue, 18 Aug 2020 14:50:55 -0400
Subject: Thoughts about the Gemini protocol
In-Reply-To: <be5bed891cff8a572902496308cde493@posteo.net>
References: <be5bed891cff8a572902496308cde493@posteo.net>
Message-ID: <07ab8c62-1bf7-0397-e548-836f0654828b@ratfactor.com>

On 8/14/20 4:59 AM, /dev/urandom wrote:
> I was thinking about an idea similar to Gemini that could work as a 
> protocol for not just websites, but also simple and functional web 
> applications as well that could, to a reasonable extent, look and work 
> well on lots of different devices (desktops, smartphones, feature 
> phones, text-mode interfaces).


Gemini has hard conceptual/technical boundaries which make it pretty 
unsuitable for building general purpose applications. And that is, of 
course, on purpose.

I've thought for years that browsers should have entirely separate modes 
of operation: one presents content and the other is an application 
client. The user would have strict control over which mode was being 
used, so I could say that reddit.com can only do "displaying content" 
things, but gmail.com can do "application" things.

But I like even more the idea of having separate clients (and protocols) 
for these purposes.

I feel like Gemini "solves" the content mode.

We still need the application mode. Universal distributed applications 
are incredibly useful and cool (and that use of the Web keeps me 
employed). But the Web _sucks_ for making applications.

So, if I were to build the "Gemini of applications", I think I would 
take a hard look at two things:

* WASM for execution
* Existing UI languages for layout

https://en.wikipedia.org/wiki/WebAssembly
https://en.wikipedia.org/wiki/List_of_user_interface_markup_languages

I like your abstract input examples.  The client should be able to 
determine the best way to present this to the user.  Entering a date on 
a desktop computer should not use the same UI as a touchscreen kiosk or 
a voice-activated home assistant!  Nor should the application developer 
need to create these UIs from scratch each and every time.

Hmm, now we just need a good name for a "Gemini of applications"...

:-)


> 2. Continuous connections
> 3. Append mode

#3 is intriguing.  I suppose it's to allow the server to respond with 
messages such as "I didn't understand 'asdfklj' as a date!" or provide 
interactive feedback, such as a session with an Eliza-like chatbot or

-Dave

From anridellal at yandex.ru  Wed Aug 19 14:57:54 2020
From: anridellal at yandex.ru (-)
Date: Wed, 19 Aug 2020 16:57:54 +0300
Subject: Seeking for help with C Gemini client
Message-ID: <20200819165754.4db722e4cef2cc07625ffb51@yandex.ru>

Hello,

I've started writing a client for Gemini protocol, but since I've never been writing networking programs, I find myself at the dead end at the moment. Please could someone help me? When I send a request and get a response, the only thing I have in response is "gemini://" and nothing else. The code is given below:

#include <arpa/inet.h>
#include <locale.h>
#include <netdb.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>

#define STATUS_CODE_INPUT 10
#define STATUS_CODE_SENSITIVE_INPUT 11
#define STATUS_CODE_SUCCESS 20
#define STATUS_CODE_REDIRECT_TEMP 30
#define STATUS_CODE_REDIRECT_PERM 31
#define STATUS_CODE_TEMP_FAILURE 40
#define STATUS_CODE_SERVER_UNAVAILABLE 41
#define STATUS_CODE_CGI_ERROR 42
#define STATUS_CODE_PROXY_ERROR 43
#define STATUS_CODE_SLOW_DOWN 44
#define STATUS_CODE_PERM_FAILURE 50
#define STATUS_CODE_NOT_FOUND 51
#define STATUS_CODE_GONE 52
#define STATUS_CODE_PROXY_REQUEST_REFUSED 53
#define STATUS_CODE_BAD_REQUEST 59
#define STATUS_CODE_CLIENT_CERT_REQUIRED 60
#define STATUS_CODE_CERT_NO_AUTH 61
#define STATUS_CODE_CERT_NOT_VALID 62

#define GEMINI_PORT 1965

int main() {
	char *locale;
	locale = setlocale(LC_ALL, "");
	
	int sockfd = socket(AF_INET, SOCK_STREAM, 0);
	if (sockfd < 0) {
		perror("socket");
		exit(1);
	}
	char *url = malloc(sizeof(char)*1024);
	strcpy(url, "gemini://gemini.circumlunar.space/\r\n");
	char rec_buf[1029] = {0};
	struct hostent *host_entry;
	host_entry = gethostbyname(url);
	struct sockaddr_in addr;
	addr.sin_family = AF_INET;
	addr.sin_port = htons(GEMINI_PORT);
	addr.sin_addr.s_addr = htonl(INADDR_ANY);
	int opt = 1;
	if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) {
		perror("setsockopt");
		exit(1);
	}
	if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
		perror("bind");
		exit(2);
	}
	if (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
		perror("connect");
		exit(3);
	}
	send(sockfd, url, sizeof(url), 0);
	recv(sockfd, rec_buf, sizeof(rec_buf), 0);
	printf("%s\n", rec_buf);
	close(sockfd);
	shutdown(sockfd, SHUT_RDWR);
	free(url);
	return 0;
}


-- 
- <anridellal at yandex.ru>

From pwarren at pwarren.id.au  Wed Aug 19 12:36:18 2020
From: pwarren at pwarren.id.au (Paul Warren)
Date: Wed, 19 Aug 2020 21:36:18 +1000
Subject: Seeking for help with C Gemini client
In-Reply-To: <20200819165754.4db722e4cef2cc07625ffb51@yandex.ru>
References: <20200819165754.4db722e4cef2cc07625ffb51@yandex.ru>
Message-ID: <b6d7ddc4-392d-fd1d-f399-d81776a99af6@pwarren.id.au>

G'day!

Gemini, while simple, isn't quite that simple. All protocol commands and
responses are over TLS connections, so doing a send/recv on a raw
network socket will not work!

I'm not 100% sure on the best or simplest way to get a TLS stack going
in C, I've done some bits with OpenSSL, but it was not simple!

Cheers
--
Paul



On 19/8/20 11:57 pm, - wrote:
> Hello,
> 
> I've started writing a client for Gemini protocol, but since I've never been writing networking programs, I find myself at the dead end at the moment. Please could someone help me? When I send a request and get a response, the only thing I have in response is "gemini://" and nothing else. The code is given below:
> 
> #include <arpa/inet.h>
> #include <locale.h>
> #include <netdb.h>
> #include <netinet/in.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <unistd.h>
> 
> #define STATUS_CODE_INPUT 10
> #define STATUS_CODE_SENSITIVE_INPUT 11
> #define STATUS_CODE_SUCCESS 20
> #define STATUS_CODE_REDIRECT_TEMP 30
> #define STATUS_CODE_REDIRECT_PERM 31
> #define STATUS_CODE_TEMP_FAILURE 40
> #define STATUS_CODE_SERVER_UNAVAILABLE 41
> #define STATUS_CODE_CGI_ERROR 42
> #define STATUS_CODE_PROXY_ERROR 43
> #define STATUS_CODE_SLOW_DOWN 44
> #define STATUS_CODE_PERM_FAILURE 50
> #define STATUS_CODE_NOT_FOUND 51
> #define STATUS_CODE_GONE 52
> #define STATUS_CODE_PROXY_REQUEST_REFUSED 53
> #define STATUS_CODE_BAD_REQUEST 59
> #define STATUS_CODE_CLIENT_CERT_REQUIRED 60
> #define STATUS_CODE_CERT_NO_AUTH 61
> #define STATUS_CODE_CERT_NOT_VALID 62
> 
> #define GEMINI_PORT 1965
> 
> int main() {
> 	char *locale;
> 	locale = setlocale(LC_ALL, "");
> 	
> 	int sockfd = socket(AF_INET, SOCK_STREAM, 0);
> 	if (sockfd < 0) {
> 		perror("socket");
> 		exit(1);
> 	}
> 	char *url = malloc(sizeof(char)*1024);
> 	strcpy(url, "gemini://gemini.circumlunar.space/\r\n");
> 	char rec_buf[1029] = {0};
> 	struct hostent *host_entry;
> 	host_entry = gethostbyname(url);
> 	struct sockaddr_in addr;
> 	addr.sin_family = AF_INET;
> 	addr.sin_port = htons(GEMINI_PORT);
> 	addr.sin_addr.s_addr = htonl(INADDR_ANY);
> 	int opt = 1;
> 	if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) {
> 		perror("setsockopt");
> 		exit(1);
> 	}
> 	if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> 		perror("bind");
> 		exit(2);
> 	}
> 	if (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> 		perror("connect");
> 		exit(3);
> 	}
> 	send(sockfd, url, sizeof(url), 0);
> 	recv(sockfd, rec_buf, sizeof(rec_buf), 0);
> 	printf("%s\n", rec_buf);
> 	close(sockfd);
> 	shutdown(sockfd, SHUT_RDWR);
> 	free(url);
> 	return 0;
> }
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1003 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200819/d18da0bc/attachment.sig>

From anridellal at yandex.ru  Wed Aug 19 16:03:29 2020
From: anridellal at yandex.ru (-)
Date: Wed, 19 Aug 2020 18:03:29 +0300
Subject: Seeking for help with C Gemini client
In-Reply-To: <b6d7ddc4-392d-fd1d-f399-d81776a99af6@pwarren.id.au>
References: <20200819165754.4db722e4cef2cc07625ffb51@yandex.ru>
 <b6d7ddc4-392d-fd1d-f399-d81776a99af6@pwarren.id.au>
Message-ID: <20200819180329.9e7345adf97de7fbd9918d96@yandex.ru>

I think I misread some parts of specification. Thank you very much.

On Wed, 19 Aug 2020 21:36:18 +1000
Paul Warren <pwarren at pwarren.id.au> wrote:

> G'day!
> 
> Gemini, while simple, isn't quite that simple. All protocol commands and
> responses are over TLS connections, so doing a send/recv on a raw
> network socket will not work!
> 
> I'm not 100% sure on the best or simplest way to get a TLS stack going
> in C, I've done some bits with OpenSSL, but it was not simple!
> 
> Cheers
> --
> Paul
> 
> 
> 
> On 19/8/20 11:57 pm, - wrote:
> > Hello,
> > 
> > I've started writing a client for Gemini protocol, but since I've never been writing networking programs, I find myself at the dead end at the moment. Please could someone help me? When I send a request and get a response, the only thing I have in response is "gemini://" and nothing else. The code is given below:
> > 
> > #include <arpa/inet.h>
> > #include <locale.h>
> > #include <netdb.h>
> > #include <netinet/in.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <sys/types.h>
> > #include <sys/socket.h>
> > #include <unistd.h>
> > 
> > #define STATUS_CODE_INPUT 10
> > #define STATUS_CODE_SENSITIVE_INPUT 11
> > #define STATUS_CODE_SUCCESS 20
> > #define STATUS_CODE_REDIRECT_TEMP 30
> > #define STATUS_CODE_REDIRECT_PERM 31
> > #define STATUS_CODE_TEMP_FAILURE 40
> > #define STATUS_CODE_SERVER_UNAVAILABLE 41
> > #define STATUS_CODE_CGI_ERROR 42
> > #define STATUS_CODE_PROXY_ERROR 43
> > #define STATUS_CODE_SLOW_DOWN 44
> > #define STATUS_CODE_PERM_FAILURE 50
> > #define STATUS_CODE_NOT_FOUND 51
> > #define STATUS_CODE_GONE 52
> > #define STATUS_CODE_PROXY_REQUEST_REFUSED 53
> > #define STATUS_CODE_BAD_REQUEST 59
> > #define STATUS_CODE_CLIENT_CERT_REQUIRED 60
> > #define STATUS_CODE_CERT_NO_AUTH 61
> > #define STATUS_CODE_CERT_NOT_VALID 62
> > 
> > #define GEMINI_PORT 1965
> > 
> > int main() {
> > 	char *locale;
> > 	locale = setlocale(LC_ALL, "");
> > 	
> > 	int sockfd = socket(AF_INET, SOCK_STREAM, 0);
> > 	if (sockfd < 0) {
> > 		perror("socket");
> > 		exit(1);
> > 	}
> > 	char *url = malloc(sizeof(char)*1024);
> > 	strcpy(url, "gemini://gemini.circumlunar.space/\r\n");
> > 	char rec_buf[1029] = {0};
> > 	struct hostent *host_entry;
> > 	host_entry = gethostbyname(url);
> > 	struct sockaddr_in addr;
> > 	addr.sin_family = AF_INET;
> > 	addr.sin_port = htons(GEMINI_PORT);
> > 	addr.sin_addr.s_addr = htonl(INADDR_ANY);
> > 	int opt = 1;
> > 	if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) {
> > 		perror("setsockopt");
> > 		exit(1);
> > 	}
> > 	if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> > 		perror("bind");
> > 		exit(2);
> > 	}
> > 	if (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> > 		perror("connect");
> > 		exit(3);
> > 	}
> > 	send(sockfd, url, sizeof(url), 0);
> > 	recv(sockfd, rec_buf, sizeof(rec_buf), 0);
> > 	printf("%s\n", rec_buf);
> > 	close(sockfd);
> > 	shutdown(sockfd, SHUT_RDWR);
> > 	free(url);
> > 	return 0;
> > }
> > 
> > 
> 


-- 
- <anridellal at yandex.ru>

From kevin at susa.net  Wed Aug 19 15:55:00 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Wed, 19 Aug 2020 15:55:00 +0100
Subject: Seeking for help with C Gemini client
In-Reply-To: <b6d7ddc4-392d-fd1d-f399-d81776a99af6@pwarren.id.au>
References: <20200819165754.4db722e4cef2cc07625ffb51@yandex.ru>
 <b6d7ddc4-392d-fd1d-f399-d81776a99af6@pwarren.id.au>
Message-ID: <CAPk6LxQJRDR6Smg19DkPibgjQuu=JYZPKZ8+qswcq8KCE86kPw@mail.gmail.com>

This is something I had been tinkering with, before getting distracted
onto something else(!). I found two examples of simple echo servers,
one for GnuTLS and one OpenSSL. The code is here

    gemini://gemini.susa.net/c/

Both certainly compiled (I have binaries on disk), but I can't recall
any more detail than that, so just sharing this as a pointer to the
original poster.

Kevin

On Wed, 19 Aug 2020 at 12:36, Paul Warren <pwarren at pwarren.id.au> wrote:
>
> G'day!
>
> Gemini, while simple, isn't quite that simple. All protocol commands and
> responses are over TLS connections, so doing a send/recv on a raw
> network socket will not work!
>
> I'm not 100% sure on the best or simplest way to get a TLS stack going
> in C, I've done some bits with OpenSSL, but it was not simple!
>
> Cheers
> --
> Paul
>
>
>
> On 19/8/20 11:57 pm, - wrote:
> > Hello,
> >
> > I've started writing a client for Gemini protocol, but since I've never been writing networking programs, I find myself at the dead end at the moment. Please could someone help me? When I send a request and get a response, the only thing I have in response is "gemini://" and nothing else. The code is given below:
> >
> > #include <arpa/inet.h>
> > #include <locale.h>
> > #include <netdb.h>
> > #include <netinet/in.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <sys/types.h>
> > #include <sys/socket.h>
> > #include <unistd.h>
> >
> > #define STATUS_CODE_INPUT 10
> > #define STATUS_CODE_SENSITIVE_INPUT 11
> > #define STATUS_CODE_SUCCESS 20
> > #define STATUS_CODE_REDIRECT_TEMP 30
> > #define STATUS_CODE_REDIRECT_PERM 31
> > #define STATUS_CODE_TEMP_FAILURE 40
> > #define STATUS_CODE_SERVER_UNAVAILABLE 41
> > #define STATUS_CODE_CGI_ERROR 42
> > #define STATUS_CODE_PROXY_ERROR 43
> > #define STATUS_CODE_SLOW_DOWN 44
> > #define STATUS_CODE_PERM_FAILURE 50
> > #define STATUS_CODE_NOT_FOUND 51
> > #define STATUS_CODE_GONE 52
> > #define STATUS_CODE_PROXY_REQUEST_REFUSED 53
> > #define STATUS_CODE_BAD_REQUEST 59
> > #define STATUS_CODE_CLIENT_CERT_REQUIRED 60
> > #define STATUS_CODE_CERT_NO_AUTH 61
> > #define STATUS_CODE_CERT_NOT_VALID 62
> >
> > #define GEMINI_PORT 1965
> >
> > int main() {
> >       char *locale;
> >       locale = setlocale(LC_ALL, "");
> >
> >       int sockfd = socket(AF_INET, SOCK_STREAM, 0);
> >       if (sockfd < 0) {
> >               perror("socket");
> >               exit(1);
> >       }
> >       char *url = malloc(sizeof(char)*1024);
> >       strcpy(url, "gemini://gemini.circumlunar.space/\r\n");
> >       char rec_buf[1029] = {0};
> >       struct hostent *host_entry;
> >       host_entry = gethostbyname(url);
> >       struct sockaddr_in addr;
> >       addr.sin_family = AF_INET;
> >       addr.sin_port = htons(GEMINI_PORT);
> >       addr.sin_addr.s_addr = htonl(INADDR_ANY);
> >       int opt = 1;
> >       if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) {
> >               perror("setsockopt");
> >               exit(1);
> >       }
> >       if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> >               perror("bind");
> >               exit(2);
> >       }
> >       if (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> >               perror("connect");
> >               exit(3);
> >       }
> >       send(sockfd, url, sizeof(url), 0);
> >       recv(sockfd, rec_buf, sizeof(rec_buf), 0);
> >       printf("%s\n", rec_buf);
> >       close(sockfd);
> >       shutdown(sockfd, SHUT_RDWR);
> >       free(url);
> >       return 0;
> > }
> >
> >
>

From kevin at susa.net  Wed Aug 19 16:08:53 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Wed, 19 Aug 2020 16:08:53 +0100
Subject: GMail is putting some list messages in spam
Message-ID: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>

Folks,

I just noticed that I had ~10 emails from the Gemini list in my GMail
inbox. If anyone else is foolish enough to use Google to handle their
mail, please check and mark any false-positives as not spam.

Google also classified them as 'looks dangerous' (jeez! that irks me).

Kevin

From kevin at susa.net  Wed Aug 19 16:09:59 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Wed, 19 Aug 2020 16:09:59 +0100
Subject: GMail is putting some list messages in spam
In-Reply-To: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
References: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
Message-ID: <CAPk6LxQOE7x_+5V=GgteLGU2eWuyB4uB1m_XYV3R3syZ9uEJTQ@mail.gmail.com>

needless to say, I meant in my Spam folder, not my inbox (! now double irked)

On Wed, 19 Aug 2020 at 16:08, Kevin Sangeelee <kevin at susa.net> wrote:
>
> Folks,
>
> I just noticed that I had ~10 emails from the Gemini list in my GMail
> inbox. If anyone else is foolish enough to use Google to handle their
> mail, please check and mark any false-positives as not spam.
>
> Google also classified them as 'looks dangerous' (jeez! that irks me).
>
> Kevin

From matilde.park at sunshinegardens.org  Wed Aug 19 16:11:52 2020
From: matilde.park at sunshinegardens.org (Matilde Park)
Date: Wed, 19 Aug 2020 11:11:52 -0400
Subject: GMail is putting some list messages in spam
In-Reply-To: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
References: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
Message-ID: <BE4C7CCD-C774-4B89-AF3A-8F0ACBB81B7C@sunshinegardens.org>


> On Aug 19, 2020, at 11:08 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> 
> Folks,
> 
> I just noticed that I had ~10 emails from the Gemini list in my GMail
> inbox. If anyone else is foolish enough to use Google to handle their
> mail, please check and mark any false-positives as not spam.
> 
> Google also classified them as 'looks dangerous' (jeez! that irks me).
> 
> Kevin

Sounds like you?ve discovered a reason to use something else...

From gmym at coopdot.com  Wed Aug 19 16:22:29 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Wed, 19 Aug 2020 17:22:29 +0200
Subject: GMail is putting some list messages in spam
In-Reply-To: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
References: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
Message-ID: <CAObwWNha65c18VQ_sDFL71a42JtG7SWMNcLSraO+raBTSaW6VQ@mail.gmail.com>

That is why you set up a filter on day one with a checkmark on "don't send
to junk folder" or whatever it's phrased. I do that for all mailing lists,
since forever. Google insists on telling me I should remove that filter.

Sorry if my tone offends anyone, this was typed in a hurry.

-- 
Katarina

Den ons 19 aug. 2020 17:09Kevin Sangeelee <kevin at susa.net> skrev:

> Folks,
>
> I just noticed that I had ~10 emails from the Gemini list in my GMail
> inbox. If anyone else is foolish enough to use Google to handle their
> mail, please check and mark any false-positives as not spam.
>
> Google also classified them as 'looks dangerous' (jeez! that irks me).
>
> Kevin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200819/4000c2bf/attachment.htm>

From anridellal at yandex.ru  Wed Aug 19 19:26:01 2020
From: anridellal at yandex.ru (-)
Date: Wed, 19 Aug 2020 21:26:01 +0300
Subject: Seeking for help with C Gemini client
In-Reply-To: <CAPk6LxQJRDR6Smg19DkPibgjQuu=JYZPKZ8+qswcq8KCE86kPw@mail.gmail.com>
References: <20200819165754.4db722e4cef2cc07625ffb51@yandex.ru>
 <b6d7ddc4-392d-fd1d-f399-d81776a99af6@pwarren.id.au>
 <CAPk6LxQJRDR6Smg19DkPibgjQuu=JYZPKZ8+qswcq8KCE86kPw@mail.gmail.com>
Message-ID: <20200819212601.1c618ea45391e2f0f3a9b848@yandex.ru>

Thank you.
I managed to make it work with LibreSSL's libtls:

https://man.openbsd.org/tls_init.3

Sharing the code in case someone wants to take a look at an implementation (the code is far from perfection, but I'll fix it later):

#include <arpa/inet.h>
#include <locale.h>
#include <netdb.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <tls.h>
#include <unistd.h>

#define STATUS_CODE_INPUT "10"
#define STATUS_CODE_SENSITIVE_INPUT "11"
#define STATUS_CODE_SUCCESS "20"
#define STATUS_CODE_REDIRECT_TEMP "30"
#define STATUS_CODE_REDIRECT_PERM "31"
#define STATUS_CODE_TEMP_FAILURE "40"
#define STATUS_CODE_SERVER_UNAVAILABLE "41"
#define STATUS_CODE_CGI_ERROR "42"
#define STATUS_CODE_PROXY_ERROR "43"
#define STATUS_CODE_SLOW_DOWN "44"
#define STATUS_CODE_PERM_FAILURE "50"
#define STATUS_CODE_NOT_FOUND "51"
#define STATUS_CODE_GONE "52"
#define STATUS_CODE_PROXY_REQUEST_REFUSED "53"
#define STATUS_CODE_BAD_REQUEST "59"
#define STATUS_CODE_CLIENT_CERT_REQUIRED "60"
#define STATUS_CODE_CERT_NO_AUTH "61"
#define STATUS_CODE_CERT_NOT_VALID "62"

#define GEMINI_PORT "1965"

int main() {
	char *locale;
	locale = setlocale(LC_ALL, "");
	
	tls_init();
	struct tls_config *tlsconf = tls_config_new();

	struct tls *client = tls_client();
	tls_config_set_protocols(tlsconf, TLS_PROTOCOL_TLSv1_3);
	tls_configure(client, tlsconf);

	const char *hostname = "gemini.circumlunar.space";

	char *url = malloc(sizeof(char)*1024);
	strcpy(url, "gemini://gemini.circumlunar.space/");
	char rec_buf[1029];
	int writebytes = sprintf(url, "%s\r\n", url);
	tls_connect(client, hostname, GEMINI_PORT);
	while (writebytes > 0) {
		ssize_t outbytes;

		outbytes = tls_write(client, url, (size_t)writebytes);
		if (outbytes == TLS_WANT_POLLIN || outbytes == TLS_WANT_POLLOUT)
			continue;
		if (outbytes == -1) {
			perror("tls_write");
		}
		url += outbytes;
		writebytes -= outbytes;
	}
	// read header
	tls_read(client, rec_buf, sizeof(rec_buf));
	printf("%s\n", rec_buf);
	char status_code[3];
	strncpy(status_code, rec_buf, 2);
	if (strcmp(status_code, STATUS_CODE_SUCCESS) == 0) {
		writebytes = tls_read(client, rec_buf, (size_t)sizeof(rec_buf));
		printf("%d\n", writebytes);
		while (writebytes > 0) {
			printf(rec_buf);
			writebytes = tls_read(client, rec_buf, (size_t)writebytes);
			printf("\n%d\n", writebytes);
		}
		printf("\r\n");
	}

	tls_close(client);
	tls_free(client);
	return 0;
}

On Wed, 19 Aug 2020 15:55:00 +0100
Kevin Sangeelee <kevin at susa.net> wrote:

> This is something I had been tinkering with, before getting distracted
> onto something else(!). I found two examples of simple echo servers,
> one for GnuTLS and one OpenSSL. The code is here
> 
>     gemini://gemini.susa.net/c/
> 
> Both certainly compiled (I have binaries on disk), but I can't recall
> any more detail than that, so just sharing this as a pointer to the
> original poster.
> 
> Kevin
> 
> On Wed, 19 Aug 2020 at 12:36, Paul Warren <pwarren at pwarren.id.au> wrote:
> >
> > G'day!
> >
> > Gemini, while simple, isn't quite that simple. All protocol commands and
> > responses are over TLS connections, so doing a send/recv on a raw
> > network socket will not work!
> >
> > I'm not 100% sure on the best or simplest way to get a TLS stack going
> > in C, I've done some bits with OpenSSL, but it was not simple!
> >
> > Cheers
> > --
> > Paul
> >
> >
> >
> > On 19/8/20 11:57 pm, - wrote:
> > > Hello,
> > >
> > > I've started writing a client for Gemini protocol, but since I've never been writing networking programs, I find myself at the dead end at the moment. Please could someone help me? When I send a request and get a response, the only thing I have in response is "gemini://" and nothing else. The code is given below:
> > >
> > > #include <arpa/inet.h>
> > > #include <locale.h>
> > > #include <netdb.h>
> > > #include <netinet/in.h>
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <string.h>
> > > #include <sys/types.h>
> > > #include <sys/socket.h>
> > > #include <unistd.h>
> > >
> > > #define STATUS_CODE_INPUT 10
> > > #define STATUS_CODE_SENSITIVE_INPUT 11
> > > #define STATUS_CODE_SUCCESS 20
> > > #define STATUS_CODE_REDIRECT_TEMP 30
> > > #define STATUS_CODE_REDIRECT_PERM 31
> > > #define STATUS_CODE_TEMP_FAILURE 40
> > > #define STATUS_CODE_SERVER_UNAVAILABLE 41
> > > #define STATUS_CODE_CGI_ERROR 42
> > > #define STATUS_CODE_PROXY_ERROR 43
> > > #define STATUS_CODE_SLOW_DOWN 44
> > > #define STATUS_CODE_PERM_FAILURE 50
> > > #define STATUS_CODE_NOT_FOUND 51
> > > #define STATUS_CODE_GONE 52
> > > #define STATUS_CODE_PROXY_REQUEST_REFUSED 53
> > > #define STATUS_CODE_BAD_REQUEST 59
> > > #define STATUS_CODE_CLIENT_CERT_REQUIRED 60
> > > #define STATUS_CODE_CERT_NO_AUTH 61
> > > #define STATUS_CODE_CERT_NOT_VALID 62
> > >
> > > #define GEMINI_PORT 1965
> > >
> > > int main() {
> > >       char *locale;
> > >       locale = setlocale(LC_ALL, "");
> > >
> > >       int sockfd = socket(AF_INET, SOCK_STREAM, 0);
> > >       if (sockfd < 0) {
> > >               perror("socket");
> > >               exit(1);
> > >       }
> > >       char *url = malloc(sizeof(char)*1024);
> > >       strcpy(url, "gemini://gemini.circumlunar.space/\r\n");
> > >       char rec_buf[1029] = {0};
> > >       struct hostent *host_entry;
> > >       host_entry = gethostbyname(url);
> > >       struct sockaddr_in addr;
> > >       addr.sin_family = AF_INET;
> > >       addr.sin_port = htons(GEMINI_PORT);
> > >       addr.sin_addr.s_addr = htonl(INADDR_ANY);
> > >       int opt = 1;
> > >       if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) {
> > >               perror("setsockopt");
> > >               exit(1);
> > >       }
> > >       if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> > >               perror("bind");
> > >               exit(2);
> > >       }
> > >       if (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> > >               perror("connect");
> > >               exit(3);
> > >       }
> > >       send(sockfd, url, sizeof(url), 0);
> > >       recv(sockfd, rec_buf, sizeof(rec_buf), 0);
> > >       printf("%s\n", rec_buf);
> > >       close(sockfd);
> > >       shutdown(sockfd, SHUT_RDWR);
> > >       free(url);
> > >       return 0;
> > > }
> > >
> > >
> >


-- 
- <anridellal at yandex.ru>

From benulo at systemli.org  Wed Aug 19 17:37:17 2020
From: benulo at systemli.org (Ben)
Date: Wed, 19 Aug 2020 21:07:17 +0430
Subject: GMail is putting some list messages in spam
In-Reply-To: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
References: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
Message-ID: <11b2159c-cb03-52b8-0402-3aad2cbd6881@systemli.org>

Looks dangerous? Yikes! Must be those scary unknown gemini:// links!

-- 
gemini://kwiecien.us/

From jmcbray at carcosa.net  Wed Aug 19 17:41:14 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 19 Aug 2020 12:41:14 -0400
Subject: Delta Chat Group
In-Reply-To: <978c0007-04de-cc6a-619f-8223dc8086eb@systemli.org> (Ben's
 message of "Mon, 17 Aug 2020 20:21:48 +0430")
References: <978c0007-04de-cc6a-619f-8223dc8086eb@systemli.org>
Message-ID: <871rk2twph.fsf@dorothy.carcosa.net>

That sounds fun. I tried the link, but it didn't work.
-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From hello at matthewgraybosch.com  Wed Aug 19 17:49:25 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Wed, 19 Aug 2020 12:49:25 -0400
Subject: GMail is putting some list messages in spam
In-Reply-To: <CAObwWNha65c18VQ_sDFL71a42JtG7SWMNcLSraO+raBTSaW6VQ@mail.gmail.com>
References: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
 <CAObwWNha65c18VQ_sDFL71a42JtG7SWMNcLSraO+raBTSaW6VQ@mail.gmail.com>
Message-ID: <20200819124925.18b5cab4@kether.phoenix.society>

On Wed, 19 Aug 2020 17:22:29 +0200
Katarina Eriksson <gmym at coopdot.com> wrote:

> Sorry if my tone offends anyone, this was typed in a hurry.
 
I'm not offended. Hell, it's mild compared to some of the stuff I've
said about Google. There isn't a single f-bomb.

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>		gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From matilde.park at sunshinegardens.org  Wed Aug 19 17:59:42 2020
From: matilde.park at sunshinegardens.org (Matilde Park)
Date: Wed, 19 Aug 2020 12:59:42 -0400
Subject: GMail is putting some list messages in spam
In-Reply-To: <20200819124925.18b5cab4@kether.phoenix.society>
References: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
 <CAObwWNha65c18VQ_sDFL71a42JtG7SWMNcLSraO+raBTSaW6VQ@mail.gmail.com>
 <20200819124925.18b5cab4@kether.phoenix.society>
Message-ID: <AD35C671-A132-4734-ACE3-B1812A893B0E@sunshinegardens.org>


> On Aug 19, 2020, at 12:49 PM, Matthew Graybosch <hello at matthewgraybosch.com> wrote:
> 
> On Wed, 19 Aug 2020 17:22:29 +0200
> Katarina Eriksson <gmym at coopdot.com> wrote:
> 
>> Sorry if my tone offends anyone, this was typed in a hurry.
> 
> I'm not offended. Hell, it's mild compared to some of the stuff I've
> said about Google. There isn't a single f-bomb.
> 
> -- 
> Matthew Graybosch		https://matthewgraybosch.com
> #include <disclaimer.h>		gemini://starbreaker.org
> 	 			gemini://tanelorn.city
> "Out of order?! Even in the future nothing works.?

I believe that?s their signature on mobile, based on context.


From acdw at acdw.net  Wed Aug 19 18:10:30 2020
From: acdw at acdw.net (acdw)
Date: Wed, 19 Aug 2020 17:10:30 +0000
Subject: proxy.vulpes.one is down
Message-ID: <3779bbad-cb8f-408c-8cea-3249863afa4d@www.fastmail.com>

Just an FYI if anyone is using proxy.vulpes.one to view gemini/gopher content.

Looks like their site has been disabled:

> This account has been disabled. Please visit https://uberspace.de/support.
> Dieser Account wurde deaktiviert. Bitte besuche https://uberspace.de/support.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From benulo at systemli.org  Wed Aug 19 19:54:40 2020
From: benulo at systemli.org (Ben)
Date: Wed, 19 Aug 2020 23:24:40 +0430
Subject: Delta Chat Group
In-Reply-To: <871rk2twph.fsf@dorothy.carcosa.net>
References: <978c0007-04de-cc6a-619f-8223dc8086eb@systemli.org>
 <871rk2twph.fsf@dorothy.carcosa.net>
Message-ID: <c63ac25d-e386-ec16-6997-231d61dff85b@systemli.org>

Seems like the public groups bot is not doing well, I probably shouldn't 
have suggested using it since apparently they haven't fixed all the 
problems with it, or there's new problems we didn't have before!

Easiest way is once you're inside Delta Chat start a chat with 
benulo at systemli.org (my e-mail) and after I receive your message I'll 
add you to the group. Quite a few have joined already!

-- 
gemini://kwiecien.us/

From moody at posixcafe.org  Thu Aug 20 04:49:54 2020
From: moody at posixcafe.org (Jacob Moody)
Date: Wed, 19 Aug 2020 22:49:54 -0500
Subject: Gemini server for 9frnot
Message-ID: <b0534d2a-67ea-6c07-42c0-104db225c39d@posixcafe.org>

Hello all,

I wanted to share some code I am working on to serve gemini content on 
plan9(9front). It's written in the plan9 shell, rc, and is heavily 
inspired by the rc-httpd project that ships with 9front.

The source is posted up on sr.ht here:
https://git.sr.ht/~moody/rc-gemd


Thanks,

Moody

From gemini at mmn.name  Thu Aug 20 17:37:57 2020
From: gemini at mmn.name (=?utf-8?q?K=C3=A9vin_-_gemini=2Eis?=)
Date: Thu, 20 Aug 2020 16:37:57 +0000
Subject: =?utf-8?q?Re=3A?= GMail is putting some list messages in spam
In-Reply-To: <BE4C7CCD-C774-4B89-AF3A-8F0ACBB81B7C@sunshinegardens.org>
Message-ID: <50-5f3ea700-9-10fcfe00@113974422>


Le Mercredi, Ao?t 19, 2020 15:11 UTC, Matilde Park <matilde.park at sunshinegardens.org> a ?crit:
?
> On Aug 19, 2020, at 11:08 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> I just noticed that I had ~10 emails from the Gemini list in my GMail
> inbox. If anyone else is foolish enough to use Google to handle their
> mail, please check and mark any false-positives as not spam.
>
> Google also classified them as 'looks dangerous' (jeez! that irks me).
>
> Kevin

Sounds like you?ve discovered a reason to use something else...Have a look at tutanota.com, the best time to de-Google is when you realise that everything they do is totally arbitrary.

--?
gemini://gemini.is/gem/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200820/fc1afe32/attachment.htm>

From hello at matthewgraybosch.com  Thu Aug 20 16:58:53 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Thu, 20 Aug 2020 11:58:53 -0400
Subject: Delta Chat & Dreamhost
Message-ID: <20200820115853.5126e8b1@kether.phoenix.society>

Ben:

I wanted to tell you that your test worked, but Dreamhost refused to
send my reply to jupiter at transjovian.org

Apparently I ran into the SMTP quota of 100 outgoing messages per
hour since each message goes to every group member separately. :(

https://help.dreamhost.com/hc/en-us/articles/215730437-SMTP-quota-limits

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>		gemini://starbreaker.org
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From avalos at rawtext.club  Thu Aug 20 21:53:37 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Thu, 20 Aug 2020 20:53:37 +0000
Subject: Gemini on ESP32 and [suggestion] examples in spec
Message-ID: <20200820205337.GB2907465@rawtext.club>

Hello, everyone!
I've been trying to write my Gemini client for ESP32, and so far has
been extremely easy. Just wanted to know if anyone is building a
similar project.

And also, it would be nice to have some example requests/responses on
the protocol specification, or at least add some section in the main
{web,gem}site for that. What do you think?

Finally, it would be nice to have a CAPCOM instance to keep track of
Gemini-based projects around the Geminispace, I could even host it
myself, let me know if you think it's a good idea.

From kevin at susa.net  Thu Aug 20 23:56:46 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Thu, 20 Aug 2020 23:56:46 +0100
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <20200820205337.GB2907465@rawtext.club>
References: <20200820205337.GB2907465@rawtext.club>
Message-ID: <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>

> I've been trying to write my Gemini client for ESP32, and so far has
> been extremely easy. Just wanted to know if anyone is building a
> similar project.

This is quite interesting, would you mind writing it up somewhere? What
are you planning to use for input and output?

I've been toying with the idea of building a low-power Gemini terminal
to operate
over a LoRa network, and ESP32 is one of the options I'm considering for
the gateway.

I haven't yet found a touch-screen display for the client that can be
driven over SPI and supports 80 columns (e.g. 640px wide), at least not
anything readily available.

Kevin

From ech at emmah.net  Fri Aug 21 00:06:50 2020
From: ech at emmah.net (Emma Humphries)
Date: Thu, 20 Aug 2020 16:06:50 -0700
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
References: <20200820205337.GB2907465@rawtext.club>
 <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
Message-ID: <b1e2c149-a8f5-4c23-858d-de9a7b230f40@www.fastmail.com>

Please do, I have a couple of ESP32s with a display which would be fun to make a Gemini client that advertises itself via the display and bluetooth with. 

On Thu, Aug 20, 2020, at 15:56, Kevin Sangeelee wrote:
> > I've been trying to write my Gemini client for ESP32, and so far has
> > been extremely easy. Just wanted to know if anyone is building a
> > similar project.
> 
> This is quite interesting, would you mind writing it up somewhere? What
> are you planning to use for input and output?
> 
> I've been toying with the idea of building a low-power Gemini terminal
> to operate
> over a LoRa network, and ESP32 is one of the options I'm considering for
> the gateway.
> 
> I haven't yet found a touch-screen display for the client that can be
> driven over SPI and supports 80 columns (e.g. 640px wide), at least not
> anything readily available.
> 
> Kevin
>

From avalos at rawtext.club  Fri Aug 21 00:42:55 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Thu, 20 Aug 2020 23:42:55 +0000
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
References: <20200820205337.GB2907465@rawtext.club>
 <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
Message-ID: <20200820234255.GA2955979@rawtext.club>

> This is quite interesting, would you mind writing it up somewhere? What
> are you planning to use for input and output?

I'm just playing around with it. I'm planning to use the code for
another project, with an E-ink display, keyboard and buttons. I wrote
about it on my gemsite: gemini://avalos.me/articles/le-gemini-project.gmi

Here's the unfinished code from my experiment:
https://fossil.avalos.me/esp32-gemini

On Thu, Aug 20, 2020 at 11:56:46PM +0100, Kevin Sangeelee wrote:
> > I've been trying to write my Gemini client for ESP32, and so far has
> > been extremely easy. Just wanted to know if anyone is building a
> > similar project.
> 
> This is quite interesting, would you mind writing it up somewhere? What
> are you planning to use for input and output?
> 
> I've been toying with the idea of building a low-power Gemini terminal
> to operate
> over a LoRa network, and ESP32 is one of the options I'm considering for
> the gateway.
> 
> I haven't yet found a touch-screen display for the client that can be
> driven over SPI and supports 80 columns (e.g. 640px wide), at least not
> anything readily available.
> 
> Kevin

From stryan at saintnet.tech  Fri Aug 21 04:58:10 2020
From: stryan at saintnet.tech (Steve Ryan)
Date: Thu, 20 Aug 2020 23:58:10 -0400
Subject: GMail is putting some list messages in spam
In-Reply-To: <BE4C7CCD-C774-4B89-AF3A-8F0ACBB81B7C@sunshinegardens.org>
References: <CAPk6LxTXcBKY04FVw=4+0tF1aTA=mV46B6Ph6k2PO-GrdZipFQ@mail.gmail.com>
 <BE4C7CCD-C774-4B89-AF3A-8F0ACBB81B7C@sunshinegardens.org>
Message-ID: <20200821035810.66nedkyyemyx7fwg@vineta.saintnet.lan>

On 20/08/19 11:11AM, Matilde Park wrote:
> 
> > On Aug 19, 2020, at 11:08 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> > 
> > Folks,
> > 
> > I just noticed that I had ~10 emails from the Gemini list in my GMail
> > inbox. If anyone else is foolish enough to use Google to handle their
> > mail, please check and mark any false-positives as not spam.
> > 
> > Google also classified them as 'looks dangerous' (jeez! that irks me).
> > 
> > Kevin
> 
> Sounds like you?ve discovered a reason to use something else...

In Gmail's defense, Migadu also marks around some number of Gemini list
messages as spam, even though I have very low spam settings. I talked to
their engineers a while back and they said it was something to do with
one of the tilde's having questionable SPF records; I'll have to dig up
the ticket.

-- 
-Steve

From andre at andregarzia.com  Fri Aug 21 10:12:10 2020
From: andre at andregarzia.com (Andre Garzia)
Date: Fri, 21 Aug 2020 10:12:10 +0100
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
References: <20200820205337.GB2907465@rawtext.club>
 <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
Message-ID: <CAF3jwT=92TYfMKFw2tMFTc8tMc6c0xyreGCXAA6Arcjva06NkA@mail.gmail.com>

Kevin,

This feather wing might be what you want. The screen is not touch but it
comes with a kickass keyboard:

https://www.tindie.com/products/arturo182/keyboard-featherwing-qwerty-keyboard-26-lcd/

I wanted to use this and an ESP32 (or the Giant Board with ARM) to create a
small Gemini client but at the moment I can't really devote time to it.

Best
Andre

On Thu, 20 Aug 2020 at 23:57, Kevin Sangeelee <kevin at susa.net> wrote:

> > I've been trying to write my Gemini client for ESP32, and so far has
> > been extremely easy. Just wanted to know if anyone is building a
> > similar project.
>
> This is quite interesting, would you mind writing it up somewhere? What
> are you planning to use for input and output?
>
> I've been toying with the idea of building a low-power Gemini terminal
> to operate
> over a LoRa network, and ESP32 is one of the options I'm considering for
> the gateway.
>
> I haven't yet found a touch-screen display for the client that can be
> driven over SPI and supports 80 columns (e.g. 640px wide), at least not
> anything readily available.
>
> Kevin
>


-- 
https://www.andregarzia.com <http://www.andregarzia.com>
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200821/308f37d8/attachment-0001.htm>

From adrianhesketh at hushmail.com  Fri Aug 21 12:01:04 2020
From: adrianhesketh at hushmail.com (Adrian Hesketh)
Date: Fri, 21 Aug 2020 12:01:04 +0100
Subject: New Gemini Server
Message-ID: <20200821110104.5BE31803AE8@smtp.hushmail.com>

Hi folks,
I got inspired by the idea and wrote a Gemini server in Go and a set
of libraries for writing applications based on the Go HTTP interface,
including a router and some middleware for requiring authentication.
It supports hosting multiple domains on a single IP address using
different certificates.
I've tried to make it easy to use - you can grab the release binary
from Github (Windows / Mac / Linux / ARM Linux (for the Raspberry Pi))
and run it yourself, and I've also pushed a Docker container if that's
your thing.
Check it out at https://github.com/a-h/gemini
I'm planning to use the libraries to build a chat / forum app, and to
run a version of my blog. I think I've built everything I need now.
If anyone's interested in working on it / spots something wrong, let
me know. I'm planning to improve the logging a bit next. I want to
replace the unstructured log format I've used with structured logs to
make it easier to pull stats from the files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200821/08a82670/attachment.htm>

From colecmac at protonmail.com  Fri Aug 21 16:34:04 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 21 Aug 2020 15:34:04 +0000
Subject: New Gemini Server
In-Reply-To: <20200821110104.5BE31803AE8@smtp.hushmail.com>
References: <20200821110104.5BE31803AE8@smtp.hushmail.com>
Message-ID: <crh7uAzhdJiyXfg81MokYlX7CsfdmS8A-plcxoh_zY1xtOvyCBnpkbd-08BPH4bvrA8VwwjzPQjuXWwFqMHW__PCwH-VClQ5BitlhOYM-QI=@protonmail.com>

Nice work!

This reminds me of gig, mind giving us a comparison?

https://github.com/pitr/gig

Thanks,
makeworld

??????? Original Message ???????
On Friday, August 21, 2020 7:01 AM, Adrian Hesketh <adrianhesketh at hushmail.com> wrote:

> Hi folks,
>
> I got inspired by the idea and wrote a Gemini server in Go and a set of libraries for writing applications based on the Go HTTP interface, including a router and some middleware for requiring authentication.
>
> It supports hosting multiple domains on a single IP address using different certificates.
>
> I've tried to make it easy to use - you can grab the release binary from Github (Windows / Mac / Linux / ARM Linux (for the Raspberry Pi)) and run it yourself, and I've also pushed a Docker container if that's your thing.
>
> Check it out at?https://github.com/a-h/gemini
>
> I'm planning to use the libraries to build a chat / forum app, and to run a version of my blog. I think I've built everything I need now.
>
> If anyone's interested in working on it / spots something wrong, let me know. I'm planning to improve the logging a bit next. I want to replace the unstructured log format I've used with structured logs to make it easier to pull stats from the files.



From avalos at rawtext.club  Fri Aug 21 18:39:47 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Fri, 21 Aug 2020 17:39:47 +0000
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <CAF3jwT=92TYfMKFw2tMFTc8tMc6c0xyreGCXAA6Arcjva06NkA@mail.gmail.com>
References: <20200820205337.GB2907465@rawtext.club>
 <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
 <CAF3jwT=92TYfMKFw2tMFTc8tMc6c0xyreGCXAA6Arcjva06NkA@mail.gmail.com>
Message-ID: <20200821173947.GA3263656@rawtext.club>

Wow, that keyboard+screen is really cool! I want to order one, but
only for this experiment project. The one I wrote on my gemsite
requires extremely cheap components, so that they can be affordable
for people with low income in areas without a lot of infrastructure.

On Fri, Aug 21, 2020 at 10:12:10AM +0100, Andre Garzia wrote:
> Kevin,
> 
> This feather wing might be what you want. The screen is not touch but it
> comes with a kickass keyboard:
> 
> https://www.tindie.com/products/arturo182/keyboard-featherwing-qwerty-keyboard-26-lcd/
> 
> I wanted to use this and an ESP32 (or the Giant Board with ARM) to create a
> small Gemini client but at the moment I can't really devote time to it.
> 
> Best
> Andre
> 
> On Thu, 20 Aug 2020 at 23:57, Kevin Sangeelee <kevin at susa.net> wrote:
> 
> > > I've been trying to write my Gemini client for ESP32, and so far has
> > > been extremely easy. Just wanted to know if anyone is building a
> > > similar project.
> >
> > This is quite interesting, would you mind writing it up somewhere? What
> > are you planning to use for input and output?
> >
> > I've been toying with the idea of building a low-power Gemini terminal
> > to operate
> > over a LoRa network, and ESP32 is one of the options I'm considering for
> > the gateway.
> >
> > I haven't yet found a touch-screen display for the client that can be
> > driven over SPI and supports 80 columns (e.g. 640px wide), at least not
> > anything readily available.
> >
> > Kevin
> >
> 
> 
> -- 
> https://www.andregarzia.com <http://www.andregarzia.com>
> Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia

From kevin at susa.net  Fri Aug 21 19:03:26 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Fri, 21 Aug 2020 19:03:26 +0100
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <20200821173947.GA3263656@rawtext.club>
References: <20200820205337.GB2907465@rawtext.club>
 <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
 <CAF3jwT=92TYfMKFw2tMFTc8tMc6c0xyreGCXAA6Arcjva06NkA@mail.gmail.com>
 <20200821173947.GA3263656@rawtext.club>
Message-ID: <CAPk6LxTNcfVELN20or7Pk7AKJqPfiqwCjM1=oFHHsdvbe9JutA@mail.gmail.com>

The post linked below talks about basic accessible devices in terms of
sustainability, but I think the ideas are quite closely related to
your own. Essentially, it suggests that an existing ubiquitous source
of low-power networked computing is the plethora of Android phones in
circulation (that are only really made 'obsolete' for the purpose of
shareholder returns). It's quite a compelling case for applications in
which WiFi/GSM/Bluetooth/etc. is enough.

    gemini://gemini.circumlunar.space/~solderpunk/gemlog/the-standard-salvaged-computing-platform.gmi

Tied with something like Deedum (https://github.com/snoe/deedum),
perhaps modified to support older hardware and to also support sync
for offline viewing, this would seem to be a big head start in
achieving your goal, albeit from a different direction.

Kevin

On Fri, 21 Aug 2020 at 18:39, <avalos at rawtext.club> wrote:
>
> The one I wrote on my gemsite requires extremely cheap components,
> so that they can be affordable for people with low income in areas
> without a lot of infrastructure.

From avalos at rawtext.club  Fri Aug 21 20:31:43 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Fri, 21 Aug 2020 19:31:43 +0000
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <CAPk6LxTNcfVELN20or7Pk7AKJqPfiqwCjM1=oFHHsdvbe9JutA@mail.gmail.com>
References: <20200820205337.GB2907465@rawtext.club>
 <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
 <CAF3jwT=92TYfMKFw2tMFTc8tMc6c0xyreGCXAA6Arcjva06NkA@mail.gmail.com>
 <20200821173947.GA3263656@rawtext.club>
 <CAPk6LxTNcfVELN20or7Pk7AKJqPfiqwCjM1=oFHHsdvbe9JutA@mail.gmail.com>
Message-ID: <20200821193143.GA3287222@rawtext.club>


>     gemini://gemini.circumlunar.space/~solderpunk/gemlog/the-standard-salvaged-computing-platform.gmi

That Gemini link about `salvaged computing` is very interesting, it
addresses several key problems with modern `sustainable` computing and
I think it is indeed compatible with the concept and mission of my
project. Thanks for sharing!

> Tied with something like Deedum (https://github.com/snoe/deedum),
> perhaps modified to support older hardware and to also support sync
> for offline viewing, this would seem to be a big head start in
> achieving your goal, albeit from a different direction.

Honestly, I don't think Flutter is that suitable for salvage
computing. First of all, because it relies on Google a lot. Also
because it is not very efficient, especially the renderer, which
requires a relative lot of GPU in order to work smoothly.

On Fri, Aug 21, 2020 at 07:03:26PM +0100, Kevin Sangeelee wrote:
> The post linked below talks about basic accessible devices in terms of
> sustainability, but I think the ideas are quite closely related to
> your own. Essentially, it suggests that an existing ubiquitous source
> of low-power networked computing is the plethora of Android phones in
> circulation (that are only really made 'obsolete' for the purpose of
> shareholder returns). It's quite a compelling case for applications in
> which WiFi/GSM/Bluetooth/etc. is enough.
> 
>     gemini://gemini.circumlunar.space/~solderpunk/gemlog/the-standard-salvaged-computing-platform.gmi
> 
> Tied with something like Deedum (https://github.com/snoe/deedum),
> perhaps modified to support older hardware and to also support sync
> for offline viewing, this would seem to be a big head start in
> achieving your goal, albeit from a different direction.
> 
> Kevin
> 
> On Fri, 21 Aug 2020 at 18:39, <avalos at rawtext.club> wrote:
> >
> > The one I wrote on my gemsite requires extremely cheap components,
> > so that they can be affordable for people with low income in areas
> > without a lot of infrastructure.

From easrng at gmail.com  Fri Aug 21 22:34:02 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Fri, 21 Aug 2020 17:34:02 -0400
Subject: Thoughts about the Gemini protocol
In-Reply-To: <07ab8c62-1bf7-0397-e548-836f0654828b@ratfactor.com>
References: <be5bed891cff8a572902496308cde493@posteo.net>
 <07ab8c62-1bf7-0397-e548-836f0654828b@ratfactor.com>
Message-ID: <CAEzvDCXV9DumH08mVDrqeRKDgOJNDBwYvq+4bDWQprydoOCHFw@mail.gmail.com>

Yeah, I think what we need is a system with using sandboxed WASI with some
kind of file based GUI API. Apps would be run in a sandbox with a temporary
folder and a size limited persistent folder. I think the name Gravity
Runtime is good.

On Tue, Aug 18, 2020, 2:51 PM Dave Gauer <dave at ratfactor.com> wrote:

> On 8/14/20 4:59 AM, /dev/urandom wrote:
> > I was thinking about an idea similar to Gemini that could work as a
> > protocol for not just websites, but also simple and functional web
> > applications as well that could, to a reasonable extent, look and work
> > well on lots of different devices (desktops, smartphones, feature
> > phones, text-mode interfaces).
>
>
> Gemini has hard conceptual/technical boundaries which make it pretty
> unsuitable for building general purpose applications. And that is, of
> course, on purpose.
>
> I've thought for years that browsers should have entirely separate modes
> of operation: one presents content and the other is an application
> client. The user would have strict control over which mode was being
> used, so I could say that reddit.com can only do "displaying content"
> things, but gmail.com can do "application" things.
>
> But I like even more the idea of having separate clients (and protocols)
> for these purposes.
>
> I feel like Gemini "solves" the content mode.
>
> We still need the application mode. Universal distributed applications
> are incredibly useful and cool (and that use of the Web keeps me
> employed). But the Web _sucks_ for making applications.
>
> So, if I were to build the "Gemini of applications", I think I would
> take a hard look at two things:
>
> * WASM for execution
> * Existing UI languages for layout
>
> https://en.wikipedia.org/wiki/WebAssembly
> https://en.wikipedia.org/wiki/List_of_user_interface_markup_languages
>
> I like your abstract input examples.  The client should be able to
> determine the best way to present this to the user.  Entering a date on
> a desktop computer should not use the same UI as a touchscreen kiosk or
> a voice-activated home assistant!  Nor should the application developer
> need to create these UIs from scratch each and every time.
>
> Hmm, now we just need a good name for a "Gemini of applications"...
>
> :-)
>
>
> > 2. Continuous connections
> > 3. Append mode
>
> #3 is intriguing.  I suppose it's to allow the server to respond with
> messages such as "I didn't understand 'asdfklj' as a date!" or provide
> interactive feedback, such as a session with an Eliza-like chatbot or
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200821/85a700dc/attachment-0001.htm>

From krispin at posteo.de  Sat Aug 22 21:18:34 2020
From: krispin at posteo.de (Krispin Schulz)
Date: Sat, 22 Aug 2020 22:18:34 +0200
Subject: Gemini on ESP32 and [suggestion] examples in spec
In-Reply-To: <20200820234255.GA2955979@rawtext.club>
References: <20200820205337.GB2907465@rawtext.club>
 <CAPk6LxT7mSQKX6BvE7xukthNwqVNNQo+uEWSDP4MVYHfCxMDQQ@mail.gmail.com>
 <20200820234255.GA2955979@rawtext.club>
Message-ID: <84935BF0-86A3-4350-89E0-817A0B22FB5D@posteo.de>

Hi Kevin,

maybe the open book feather is also something for you:

https://hackaday.io/project/168761-the-open-book-feather <https://hackaday.io/project/168761-the-open-book-feather>

It?s based on Adafruit?s Feather and could be easily extended with wings (GPS, LoRA, WiFi, keyboard etc.).


Krispin


> On 21. Aug 2020, at 01:42, avalos at rawtext.club wrote:
> 
>> This is quite interesting, would you mind writing it up somewhere? What
>> are you planning to use for input and output?
> 
> I'm just playing around with it. I'm planning to use the code for
> another project, with an E-ink display, keyboard and buttons. I wrote
> about it on my gemsite: gemini://avalos.me/articles/le-gemini-project.gmi
> 
> Here's the unfinished code from my experiment:
> https://fossil.avalos.me/esp32-gemini
> 
> On Thu, Aug 20, 2020 at 11:56:46PM +0100, Kevin Sangeelee wrote:
>>> I've been trying to write my Gemini client for ESP32, and so far has
>>> been extremely easy. Just wanted to know if anyone is building a
>>> similar project.
>> 
>> This is quite interesting, would you mind writing it up somewhere? What
>> are you planning to use for input and output?
>> 
>> I've been toying with the idea of building a low-power Gemini terminal
>> to operate
>> over a LoRa network, and ESP32 is one of the options I'm considering for
>> the gateway.
>> 
>> I haven't yet found a touch-screen display for the client that can be
>> driven over SPI and supports 80 columns (e.g. 640px wide), at least not
>> anything readily available.
>> 
>> Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200822/deb2a585/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200822/deb2a585/attachment.sig>

From idf31 at memeware.net  Mon Aug 24 14:05:58 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Mon, 24 Aug 2020 16:05:58 +0300
Subject: Got my gemini server running
Message-ID: <c57454a7292aeb23821819419e4bc198@memeware.net>

Hello. Some people asked me if I have a gemini capsule. I just got mine 
running on a RPI here: gemini://idfcaps.geek.
This domain requires you to use OpenNIC(https://www.opennic.org/) as a 
DNS provider, as I dont yet have the means to get a standard domain.

From alex at gnu.org  Mon Aug 24 14:24:36 2020
From: alex at gnu.org (Alex Schroeder)
Date: Mon, 24 Aug 2020 15:24:36 +0200
Subject: The optional scheme in URLs
Message-ID: <84608df2f7aa61300b92c6d08608b3b1ce4cdd0b.camel@gnu.org>

A few sites out there offer both Gemini and web access. That's cool.
It's a bridge to Gemini space. At first, as a developer who had written
just such a tool, I was exasperated: should I be linking to Gemini URLs
or to web URLs, or both? Or translate them automatically in the
background?

It turns out, this is not required. Just now, for example, I added link
like the following:

=> //flounder.online/ Flounder, for simple web people

The magic of URLs is that the actual target depends on what you're
looking at: If you're looking at 
https://transjovian.org:1965/gemini/page/Sites then the link goes to 
https://flounder.online/ and when you're looking at
gemini://transjovian.org/gemini/page/Sites then the link goes to
gemini://flounder.online/.

Now I'm just taking extra care such that as many URLs as possible are
reachable using either scheme. If they are, then I can link to these
resources without specifying a scheme and it'll just work.

Cheers
Alex




From tva at fastmail.se  Mon Aug 24 14:41:26 2020
From: tva at fastmail.se (=?UTF-8?Q?=C3=96ppen?=)
Date: Mon, 24 Aug 2020 14:41:26 +0100
Subject: =?UTF-8?Q?New_Android_Client:_Tv=C3=A5_?=
Message-ID: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>

Hi all, I've been working on this in my spare time for the last week or two, still lots to do and it's buggy in places (especially tabs, and some pages aren't rendering (that _did_ work previously)) but it's shaping up nicely.

Download, more info, links to source etc: https://www.oppenlab.net/pr/tva/

From alex at alexwennerberg.com  Mon Aug 24 15:20:25 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Mon, 24 Aug 2020 07:20:25 -0700
Subject: The optional scheme in URLs
In-Reply-To: <84608df2f7aa61300b92c6d08608b3b1ce4cdd0b.camel@gnu.org>
References: <84608df2f7aa61300b92c6d08608b3b1ce4cdd0b.camel@gnu.org>
Message-ID: <159827882574.6537.17017066654347466849@debian-thinkpad>

Quoting Alex Schroeder (2020-08-24 06:24:36)
> It turns out, this is not required. Just now, for example, I added link
> like the following:
> 
> => //flounder.online/ Flounder, for simple web people
> 
> The magic of URLs is that the actual target depends on what you're
> looking at: If you're looking at 
> https://transjovian.org:1965/gemini/page/Sites then the link goes to 
> https://flounder.online/ and when you're looking at
> gemini://transjovian.org/gemini/page/Sites then the link goes to
> gemini://flounder.online/.

Ah, this is awesome -- I never knew this was part of the URL spec. 
Glad you're enjoying my site :)

Alex

From colecmac at protonmail.com  Mon Aug 24 15:25:01 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 24 Aug 2020 14:25:01 +0000
Subject: The optional scheme in URLs
In-Reply-To: <159827882574.6537.17017066654347466849@debian-thinkpad>
References: <84608df2f7aa61300b92c6d08608b3b1ce4cdd0b.camel@gnu.org>
 <159827882574.6537.17017066654347466849@debian-thinkpad>
Message-ID: <BS4w1Q1aUMsyinzjsd4yXE2kXWNWoTkUMf6reoqYTHgrL0H_jxH0vRpUXYnreNwazRjUYDsz-T7Igg-tK-TOrt5x8Gi4vhAS2V4XBt4yL6Y=@protonmail.com>

Happy you're seeing this Alex!

Sounds like you should encourage your users to do flounder URLs like that,
or potentially convert them to links like that yourself.

makeworld

??????? Original Message ???????
On Monday, August 24, 2020 10:20 AM, alex wennerberg <alex at alexwennerberg.com> wrote:

> Quoting Alex Schroeder (2020-08-24 06:24:36)
>
> > It turns out, this is not required. Just now, for example, I added link
> > like the following:
> > => //flounder.online/ Flounder, for simple web people
> > The magic of URLs is that the actual target depends on what you're
> > looking at: If you're looking at
> > https://transjovian.org:1965/gemini/page/Sites then the link goes to
> > https://flounder.online/ and when you're looking at
> > gemini://transjovian.org/gemini/page/Sites then the link goes to
> > gemini://flounder.online/.
>
> Ah, this is awesome -- I never knew this was part of the URL spec.
> Glad you're enjoying my site :)
>
> Alex



From alex at alexwennerberg.com  Mon Aug 24 15:35:29 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Mon, 24 Aug 2020 07:35:29 -0700
Subject: The optional scheme in URLs
In-Reply-To: <BS4w1Q1aUMsyinzjsd4yXE2kXWNWoTkUMf6reoqYTHgrL0H_jxH0vRpUXYnreNwazRjUYDsz-T7Igg-tK-TOrt5x8Gi4vhAS2V4XBt4yL6Y=@protonmail.com>
References: <84608df2f7aa61300b92c6d08608b3b1ce4cdd0b.camel@gnu.org>
 <159827882574.6537.17017066654347466849@debian-thinkpad>
 <BS4w1Q1aUMsyinzjsd4yXE2kXWNWoTkUMf6reoqYTHgrL0H_jxH0vRpUXYnreNwazRjUYDsz-T7Igg-tK-TOrt5x8Gi4vhAS2V4XBt4yL6Y=@protonmail.com>
Message-ID: <159827972995.7313.12013985306307547724@debian-thinkpad>

Quoting colecmac at protonmail.com (2020-08-24 07:25:01)
> Happy you're seeing this Alex!
> 
> Sounds like you should encourage your users to do flounder URLs like that,
> or potentially convert them to links like that yourself.
> 
> makeworld

I just updated the documentation pages to reference them as much as I can!

Alex

From dealpete at fastmail.com  Mon Aug 24 15:26:21 2020
From: dealpete at fastmail.com (Peter Deal)
Date: Mon, 24 Aug 2020 11:56:21 -0230
Subject: Got my gemini server running
In-Reply-To: <c57454a7292aeb23821819419e4bc198@memeware.net>
References: <c57454a7292aeb23821819419e4bc198@memeware.net>
Message-ID: <68F9012E-B473-4156-873E-0FA638ACA542@fastmail.com>

This is the first time I?ve actually needed to muck with my DNS settings to see a domain on the Internet. Interesting experience.

Peter

> On Aug 24, 2020, at 10:35 AM, idf31 at memeware.net wrote:
> 
> Hello. Some people asked me if I have a gemini capsule. I just got mine running on a RPI here: gemini://idfcaps.geek.
> This domain requires you to use OpenNIC(https://www.opennic.org/) as a DNS provider, as I dont yet have the means to get a standard domain.


From idf31 at memeware.net  Mon Aug 24 18:39:37 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Mon, 24 Aug 2020 20:39:37 +0300
Subject: Got my gemini server running
In-Reply-To: <68F9012E-B473-4156-873E-0FA638ACA542@fastmail.com>
References: <c57454a7292aeb23821819419e4bc198@memeware.net>
 <68F9012E-B473-4156-873E-0FA638ACA542@fastmail.com>
Message-ID: <53ebf6f7bdf72de9cbc887b2568e3dfe@memeware.net>

On 2020-08-24 17:26, Peter Deal wrote:
> This is the first time I?ve actually needed to muck with my DNS
> settings to see a domain on the Internet. Interesting experience.
> 
> Peter
> 
>> On Aug 24, 2020, at 10:35 AM, idf31 at memeware.net wrote:
>> 
>> Hello. Some people asked me if I have a gemini capsule. I just got 
>> mine running on a RPI here: gemini://idfcaps.geek.
>> This domain requires you to use OpenNIC(https://www.opennic.org/) as a 
>> DNS provider, as I dont yet have the means to get a standard domain.

Sorry for that, I just wanted to reply to my initial post that the 
server is now also running on the main DNS at idf.looting.uk.

From gemini at mmn.name  Mon Aug 24 20:13:56 2020
From: gemini at mmn.name (=?utf-8?q?K=C3=A9vin_-_gemini=2Eis?=)
Date: Mon, 24 Aug 2020 19:13:56 +0000
Subject: =?utf-8?q?Re=3A?= Got my gemini server running
In-Reply-To: <c57454a7292aeb23821819419e4bc198@memeware.net>
Message-ID: <4f-5f441180-7-28810a8@132230294>


Hey,

Have a look at freedns.afraid.org, there are loads of subdomains you can use.? I've got a couple of short ones on there, like ec.gy and ml.gy :

https://freedns.afraid.org/subdomain/edit.php?edit_domain_id=1299103?(ec.gy)
https://freedns.afraid.org/subdomain/edit.php?edit_domain_id=1310128?(ml.gy)

Another option for a freebie domain is freenom.com.

-K?vin

Le Lundi, Ao?t 24, 2020 13:05 UTC, idf31 at memeware.net a ?crit:
?Hello. Some people asked me if I have a gemini capsule. I just got mine
running on a RPI here: gemini://idfcaps.geek.
This domain requires you to use OpenNIC(https://www.opennic.org/) as a
DNS provider, as I dont yet have the means to get a standard domain.


?

--?
gemini://gemini.is/gem/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200824/3ac61021/attachment-0001.htm>

From idf31 at memeware.net  Mon Aug 24 20:27:43 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Mon, 24 Aug 2020 22:27:43 +0300
Subject: Got my gemini server running
In-Reply-To: <4f-5f441180-7-28810a8@132230294>
References: <4f-5f441180-7-28810a8@132230294>
Message-ID: <bf772b400e1b6be1c85e58c34046a924@memeware.net>

On 2020-08-24 22:13, K?vin - gemini.is wrote:
> Hey,
> 
> Have a look at freedns.afraid.org [1], there are loads of subdomains
> you can use.  I've got a couple of short ones on there, like ec.gy and
> ml.gy :
> 
> https://freedns.afraid.org/subdomain/edit.php?edit_domain_id=1299103
> (ec.gy)
> https://freedns.afraid.org/subdomain/edit.php?edit_domain_id=1310128
> (ml.gy)
> 
> Another option for a freebie domain is freenom.com [2].
> 
> -K?vin
> 
> Le Lundi, Ao?t 24, 2020 13:05 UTC, idf31 at memeware.net a ?crit:
> 
>> Hello. Some people asked me if I have a gemini capsule. I just got
>> mine
>> running on a RPI here: gemini://idfcaps.geek.
>> This domain requires you to use OpenNIC(https://www.opennic.org/) as
>> a
>> DNS provider, as I dont yet have the means to get a standard domain.
> 
> --
> gemini://gemini.is/gem/
> 
> Links:
> ------
> [1] https://freedns.afraid.org
> [2] https://freenom.com

thanks, I didn't know about freedns.afraid.org


also unrelated, i noticed the server crashes from time to time for the 
same error, but I can't seem to recreate. Did anybody have any trouble 
connecting. And if you did can you tell me what client did you use and 
what did you do exactly? Would help me a lot

From gemini at mmn.name  Mon Aug 24 20:32:31 2020
From: gemini at mmn.name (=?utf-8?q?K=C3=A9vin_-_gemini=2Eis?=)
Date: Mon, 24 Aug 2020 19:32:31 +0000
Subject: =?utf-8?q?Re=3A?= Got my gemini server running
In-Reply-To: <bf772b400e1b6be1c85e58c34046a924@memeware.net>
Message-ID: <4f-5f441600-b-28810a8@132230360>


Le Lundi, Ao?t 24, 2020 19:27 UTC, idf31 at memeware.net a ?crit:
?thanks, I didn't know about freedns.afraid.org


also unrelated, i noticed the server crashes from time to time for the
same error, but I can't seem to recreate. Did anybody have any trouble
connecting. And if you did can you tell me what client did you use and
what did you do exactly? Would help me a lot
I think it went out for me when I went to the GimiNim subcapsule, I was using a proxy though :?https://portal.mozz.us/gemini/idf.looting.uk/geminim

?

--?
gemini://gemini.is/gem/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200824/f17edc26/attachment.htm>

From adam at objectivegames.com  Tue Aug 25 00:40:12 2020
From: adam at objectivegames.com (Adam Thompson)
Date: Mon, 24 Aug 2020 18:40:12 -0500
Subject: Gemini browser in Node / Electron: spacewar
Message-ID: <CA+eEvSsLd=T4VYzQzDtULdN9cZgFNKwRq0rv2KruMChxM1v_dQ@mail.gmail.com>

Please excuse the irony of using Electron and NodeJS to implement a Gemini
client rendered as HTML in a Chromium view.  I'm escaping the complexity of
the modern web by using its best representatives!

That said, I'm trying to keep things simple in the spirit of this beautiful
protocol :)

It is not useful in any way yet:
https://github.com/ResonAtom/spacewar

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200824/1d93252e/attachment.htm>

From avalos at rawtext.club  Tue Aug 25 01:17:45 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Tue, 25 Aug 2020 00:17:45 +0000
Subject: Gemini browser in Node / Electron: spacewar
In-Reply-To: <CA+eEvSsLd=T4VYzQzDtULdN9cZgFNKwRq0rv2KruMChxM1v_dQ@mail.gmail.com>
References: <CA+eEvSsLd=T4VYzQzDtULdN9cZgFNKwRq0rv2KruMChxM1v_dQ@mail.gmail.com>
Message-ID: <20200825001745.GA468919@rawtext.club>

Okay, that's hilarious.

On Mon, Aug 24, 2020 at 06:40:12PM -0500, Adam Thompson wrote:
> Please excuse the irony of using Electron and NodeJS to implement a Gemini
> client rendered as HTML in a Chromium view.  I'm escaping the complexity of
> the modern web by using its best representatives!
> 
> That said, I'm trying to keep things simple in the spirit of this beautiful
> protocol :)
> 
> It is not useful in any way yet:
> https://github.com/ResonAtom/spacewar
> 
> -Adam

From peteyboy at sdf.org  Tue Aug 25 05:45:57 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Mon, 24 Aug 2020 21:45:57 -0700
Subject: Gemini Digest, Vol 13, Issue 28
In-Reply-To: <mailman.91.1598296445.459.gemini@lists.orbitalfox.eu>
References: <mailman.91.1598296445.459.gemini@lists.orbitalfox.eu>
Message-ID: <E94F3FD1-1E08-4D4D-B9D7-ED15C51D5E09@sdf.org>

I don't know, I like that Gemini is a different space. 

I like that there are parallel spaces, but I like even that Gemini.circumlinar.space http is not the same as the Gemini experience. It's missing stuff. Gemini is a different dimension, like the Shadowfell.

>Date: Mon, 24 Aug 2020 15:24:36 +0200
>From: Alex Schroeder <alex at gnu.org>
>To: Gemini <gemini at lists.orbitalfox.eu>
>Subject: The optional scheme in URLs
>Message-ID: <84608df2f7aa61300b92c6d08608b3b1ce4cdd0b.camel at gnu.org>
>Content-Type: text/plain; charset="UTF-8"
>
>A few sites out there offer both Gemini and web access. That's cool.
>It's a bridge to Gemini space. At first, as a developer who had written
>just such a tool, I was exasperated: should I be linking to Gemini URLs
>or to web URLs, or both? Or translate them automatically in the
>background?
>
>It turns out, this is not required. Just now, for example, I added link
>like the following:
>
>=> //flounder.online/ Flounder, for simple web people
>
>The magic of URLs is that the actual target depends on what you're
>looking at: If you're looking at 
>https://transjovian.org:1965/gemini/page/Sites then the link goes to 
>https://flounder.online/ and when you're looking at
>gemini://transjovian.org/gemini/page/Sites then the link goes to
>gemini://flounder.online/.
>
>Now I'm just taking extra care such that as many URLs as possible are
>reachable using either scheme. If they are, then I can link to these
>resources without specifying a scheme and it'll just work.
>
>Cheers
>Alex

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From Paul.Kosel at ruhr-uni-bochum.de  Tue Aug 25 06:09:18 2020
From: Paul.Kosel at ruhr-uni-bochum.de (Paul Kosel)
Date: Tue, 25 Aug 2020 07:09:18 +0200
Subject: Experimental SWI-Prolog Gemini Server
Message-ID: <2e1119cf0360fe64e8aaea9d11ff892d@ruhr-uni-bochum.de>

Greetings Geminauts!

I hope I'm doing this the right way, never used a mailing list before. 
Please correct me if I do anything stupid.
The gemini project really interested me and (un)fortunately I stumbled 
upon it during my Prolog phase so why not combine the two?
That's exactly what I thought, which is why we got Marami now ( 
https://github.com/MagnificentPako/Marami/ )!

It definitely is missing some features and not-so-gracefully handles 
some requests but I'm still happy with how it turned out so far.
I'll get up an instance running my example handler from the repo 
soon-ish (should I announce that here or not?)

Again, hopefully I'm not annoying anyone with this and I wish you all a 
great day/evening/night!

From joseph at xylon.me.uk  Tue Aug 25 06:17:00 2020
From: joseph at xylon.me.uk (Joseph Graham)
Date: Tue, 25 Aug 2020 06:17:00 +0100
Subject: =?UTF-8?Q?Re=3A_New_Android_Client=3A_Tv=C3=A5_?=
In-Reply-To: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
Message-ID: <6C72F903-1DAA-4376-B46B-D5335963E355@xylon.me.uk>

Nice! Works well for me!

On 24 August 2020 14:41:26 BST, "?ppen" <tva at fastmail.se> wrote:
>Hi all, I've been working on this in my spare time for the last week or
>two, still lots to do and it's buggy in places (especially tabs, and
>some pages aren't rendering (that _did_ work previously)) but it's
>shaping up nicely.
>
>Download, more info, links to source etc:
>https://www.oppenlab.net/pr/tva/

-- 
Sent from my Android device with K-9 Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200825/5e93d9fd/attachment.htm>

From alex at gnu.org  Tue Aug 25 07:20:18 2020
From: alex at gnu.org (Alex Schroeder)
Date: Tue, 25 Aug 2020 08:20:18 +0200
Subject: Collectively maintained lists of clients, servers, sites, etc
Message-ID: <aaa97b4d2ed6cc8748574bd68cfbfa76a481d699.camel@gnu.org>

I've tried to set up a wiki space for Gemini related links. It started
out as a copy of the lists we have on Circumlunar Space. In theory,
people could just add their own projects to these pages. If you're
interested in helping out, please do.

Gemini access:
gemini://transjovian.org/gemini/

If your client has Titan support you can edit those pages directly. If
not, you can use the web:
https://transjovian.org:1965/gemini/

I'm trying to go back through the list archive in order to add any
entries we might be missing... Happy for all the help I can get!

Cheers
Alex


If you're interested in how to use the wiki space, there are more pages
here:
https://transjovian.org:1965/page/How%20To



From krispin at posteo.de  Tue Aug 25 07:47:45 2020
From: krispin at posteo.de (Krispin Schulz)
Date: Tue, 25 Aug 2020 08:47:45 +0200
Subject: =?utf-8?Q?Re=3A_New_Android_Client=3A_Tv=C3=A5_?=
In-Reply-To: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
Message-ID: <67027F40-68CE-4402-BA99-8A6CDAAE5487@posteo.de>

Hi,

I started an ?awesome-gemini? list on GitHub to spread the idea of gemini and added your Android client as well:

https://github.com/kr1sp1n/awesome-gemini <https://github.com/kr1sp1n/awesome-gemini>

Please contribute if you wanna add something.


Have a great day,

Krispin

> On 24. Aug 2020, at 15:41, ?ppen <tva at fastmail.se> wrote:
> 
> Hi all, I've been working on this in my spare time for the last week or two, still lots to do and it's buggy in places (especially tabs, and some pages aren't rendering (that _did_ work previously)) but it's shaping up nicely.
> 
> Download, more info, links to source etc: https://www.oppenlab.net/pr/tva/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200825/c6327bd4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200825/c6327bd4/attachment-0001.sig>

From krispin at posteo.de  Tue Aug 25 08:06:23 2020
From: krispin at posteo.de (Krispin Schulz)
Date: Tue, 25 Aug 2020 09:06:23 +0200
Subject: Collectively maintained lists of clients, servers, sites, etc
In-Reply-To: <aaa97b4d2ed6cc8748574bd68cfbfa76a481d699.camel@gnu.org>
References: <aaa97b4d2ed6cc8748574bd68cfbfa76a481d699.camel@gnu.org>
Message-ID: <B429EDE1-AFDE-47D8-91C9-ECEE4D7D5E42@posteo.de>

Hi Alex,

many thanks for linking to the ?awesome-gemini? list on GitHub.
I linked your wiki space on the list as well.


Cheers,

Krispin

> On 25. Aug 2020, at 08:20, Alex Schroeder <alex at gnu.org> wrote:
> 
> I've tried to set up a wiki space for Gemini related links. It started
> out as a copy of the lists we have on Circumlunar Space. In theory,
> people could just add their own projects to these pages. If you're
> interested in helping out, please do.
> 
> Gemini access:
> gemini://transjovian.org/gemini/
> 
> If your client has Titan support you can edit those pages directly. If
> not, you can use the web:
> https://transjovian.org:1965/gemini/
> 
> I'm trying to go back through the list archive in order to add any
> entries we might be missing... Happy for all the help I can get!
> 
> Cheers
> Alex
> 
> 
> If you're interested in how to use the wiki space, there are more pages
> here:
> https://transjovian.org:1965/page/How%20To
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200825/3850e2c2/attachment.sig>

From idf31 at memeware.net  Tue Aug 25 09:31:24 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Tue, 25 Aug 2020 11:31:24 +0300
Subject: Got my gemini server running
In-Reply-To: <4f-5f441600-b-28810a8@132230360>
References: <4f-5f441600-b-28810a8@132230360>
Message-ID: <bf76f8f4488309d849f98a165510be41@memeware.net>

On 2020-08-24 22:32, K?vin - gemini.is wrote:
> Le Lundi, Ao?t 24, 2020 19:27 UTC, idf31 at memeware.net a ?crit:
> 
>> thanks, I didn't know about freedns.afraid.org
>> 
>> also unrelated, i noticed the server crashes from time to time for
>> the
>> same error, but I can't seem to recreate. Did anybody have any
>> trouble
>> connecting. And if you did can you tell me what client did you use
>> and
>> what did you do exactly? Would help me a lot
> 
> I think it went out for me when I went to the GimiNim subcapsule, I
> was using a proxy though :
> https://portal.mozz.us/gemini/idf.looting.uk/geminim
> 
> --
> gemini://gemini.is/gem/

Should be fixed by now, worst case the server doesn't crash at that 
error so a reconnection would still be possible.

From kevin at susa.net  Tue Aug 25 10:15:46 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 25 Aug 2020 10:15:46 +0100
Subject: Experimental SWI-Prolog Gemini Server
In-Reply-To: <2e1119cf0360fe64e8aaea9d11ff892d@ruhr-uni-bochum.de>
References: <2e1119cf0360fe64e8aaea9d11ff892d@ruhr-uni-bochum.de>
Message-ID: <CAPk6LxSod7=sVtpB-49GjffeGrqJwP_+y_tGd8=36nohMBKesQ@mail.gmail.com>

Genuinely magnificent (well, someone had to say it).

Great way to learn Prolog, but also a great way to teach it. Thanks for sharing!

Kevin

On Tue, 25 Aug 2020 at 06:09, Paul Kosel <Paul.Kosel at ruhr-uni-bochum.de> wrote:
>
> Greetings Geminauts!
>
> I hope I'm doing this the right way, never used a mailing list before.
> Please correct me if I do anything stupid.
> The gemini project really interested me and (un)fortunately I stumbled
> upon it during my Prolog phase so why not combine the two?
> That's exactly what I thought, which is why we got Marami now (
> https://github.com/MagnificentPako/Marami/ )!
>
> It definitely is missing some features and not-so-gracefully handles
> some requests but I'm still happy with how it turned out so far.
> I'll get up an instance running my example handler from the repo
> soon-ish (should I announce that here or not?)
>
> Again, hopefully I'm not annoying anyone with this and I wish you all a
> great day/evening/night!

From kevin at susa.net  Tue Aug 25 12:16:44 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 25 Aug 2020 12:16:44 +0100
Subject: =?UTF-8?Q?Re=3A_New_Android_Client=3A_Tv=C3=A5?=
In-Reply-To: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
Message-ID: <CAPk6LxQhdO=TjjjzxRtgb3i87iU10g1jXYkymvVTBe0MtAB=oQ@mail.gmail.com>

This is looking really nice, aesthetics are great and it's really fast.

Curiously, I noticed that it fails when fetching many CGI-generated URLs,
all mine yield a blank screen, other sites have missing data.

I did a little checking, and it seems that (at least some) servers don't
properly signal their intention to close the TLS session when sending the
output of CGI scripts.

I wonder if your client picks up this error and abandons the response
(which in fact was received correctly)? If so, perhaps it could instead
flush any input buffers and keep the response.

I have put a few notes below in case it's of use to you.

Kevin

---------------------------------------
# Example URL that fails in Tv?: gemini://gemini.susa.net/cgi-bin/twitter
# Response is received, but with an error.
kevin at kakapo:~/gemini/content$ echo -ne "gemini://
gemini.susa.net/cgi-bin/twitter\r\n"|gnutls-cli --no-ca-verification
--port=1965 gemini.susa.net
Processed 151 CA certificate(s).
Resolving 'gemini.susa.net:1965'...
Connecting to '78.46.186.193:1965'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=*.susa.net', issuer `CN=*.susa.net', serial
0x00af7f3177de559661, RSA key 4096 bits, signed using RSA-SHA256, activated
`2020-07-10 21:47:06 UTC', expires `2030-07-08 21:47:06 UTC',
pin-sha256="kUjkK2Oa2yhHsyFHokB3df7DqbTxgIwzah2bLzZFAjw="
        Public Key ID:
                sha1:c6b2cce3070eba096a2ddede1b65d8684bb04ff1

sha256:9148e42b639adb2847b32147a2407775fec3a9b4f1808c336a1d9b2f3645023c
        Public Key PIN:
                pin-sha256:kUjkK2Oa2yhHsyFHokB3df7DqbTxgIwzah2bLzZFAjw=

- Successfully sent 0 certificate(s) to server.
- Description: (TLS1.2-X.509)-(ECDHE-X25519)-(RSA-SHA512)-(AES-256-GCM)
- Session ID:
10:69:F0:70:F3:B6:9B:B2:9E:DA:A3:7E:02:99:B4:86:BE:54:9E:94:FB:30:1F:66:C6:B8:61:20:88:21:F8:FF
- Options: extended master secret, safe renegotiation,
- Handshake was completed

- Simple Client Mode:

20 text/gemini
#The Twitter Oracle spake thus, the words spoken were:

```
Fr u hoes WEAK is u serious??
```

Just a tiny sample of what you're missing out on - refresh for more!***
Fatal error: Error in the pull function.
*** Server has terminated the connection abnormally.


On Mon, 24 Aug 2020 at 14:42, ?ppen <tva at fastmail.se> wrote:

> Hi all, I've been working on this in my spare time for the last week or
> two, still lots to do and it's buggy in places (especially tabs, and some
> pages aren't rendering (that _did_ work previously)) but it's shaping up
> nicely.
>
> Download, more info, links to source etc: https://www.oppenlab.net/pr/tva/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200825/02291cd1/attachment.htm>

From tva at fastmail.se  Tue Aug 25 12:20:25 2020
From: tva at fastmail.se (=?UTF-8?Q?=C3=96ppen?=)
Date: Tue, 25 Aug 2020 12:20:25 +0100
Subject: =?UTF-8?Q?Re:_New_Android_Client:_Tv=C3=A5?=
In-Reply-To: <CAPk6LxQhdO=TjjjzxRtgb3i87iU10g1jXYkymvVTBe0MtAB=oQ@mail.gmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 <CAPk6LxQhdO=TjjjzxRtgb3i87iU10g1jXYkymvVTBe0MtAB=oQ@mail.gmail.com>
Message-ID: <08a2ffbd-9d57-430e-aed2-c473c0aaacf3@www.fastmail.com>

Thanks Kevin, and yes, something is afoot with some addresses. The client torture test at gemini://gemini.conman.org/test/torture/ used to render fine, but in later builds it's failing. I'll investigate for the next release.

On Tue, 25 Aug 2020, at 12:16 PM, Kevin Sangeelee wrote:
> This is looking really nice, aesthetics are great and it's really fast.
> 
> Curiously, I noticed that it fails when fetching many CGI-generated 
> URLs, all mine yield a blank screen, other sites have missing data.
> 
> I did a little checking, and it seems that (at least some) servers 
> don't properly signal their intention to close the TLS session when 
> sending the output of CGI scripts.
> 
> I wonder if your client picks up this error and abandons the response 
> (which in fact was received correctly)? If so, perhaps it could instead 
> flush any input buffers and keep the response.
> 
> I have put a few notes below in case it's of use to you.
> 
> Kevin
> 
> ---------------------------------------
> # Example URL that fails in Tv?: 
> gemini://gemini.susa.net/cgi-bin/twitter 
> # Response is received, but with an error.
> kevin at kakapo:~/gemini/content$ echo -ne 
> "gemini://gemini.susa.net/cgi-bin/twitter\r\n 
> <http://gemini.susa.net/cgi-bin/twitter/r/n>"|gnutls-cli 
> --no-ca-verification --port=1965 gemini.susa.net
> Processed 151 CA certificate(s).
> Resolving 'gemini.susa.net:1965'...
> Connecting to '78.46.186.193:1965'...
> - Certificate type: X.509
> - Got a certificate list of 1 certificates.
> - Certificate[0] info:
>  - subject `CN=*.susa.net', issuer `CN=*.susa.net', serial 
> 0x00af7f3177de559661, RSA key 4096 bits, signed using RSA-SHA256, 
> activated `2020-07-10 21:47:06 UTC', expires `2030-07-08 21:47:06 UTC', 
> pin-sha256="kUjkK2Oa2yhHsyFHokB3df7DqbTxgIwzah2bLzZFAjw="
>         Public Key ID:
>                 sha1:c6b2cce3070eba096a2ddede1b65d8684bb04ff1
>                 
> sha256:9148e42b639adb2847b32147a2407775fec3a9b4f1808c336a1d9b2f3645023c
>         Public Key PIN:
>                 pin-sha256:kUjkK2Oa2yhHsyFHokB3df7DqbTxgIwzah2bLzZFAjw=
> 
> - Successfully sent 0 certificate(s) to server.
> - Description: (TLS1.2-X.509)-(ECDHE-X25519)-(RSA-SHA512)-(AES-256-GCM)
> - Session ID: 
> 10:69:F0:70:F3:B6:9B:B2:9E:DA:A3:7E:02:99:B4:86:BE:54:9E:94:FB:30:1F:66:C6:B8:61:20:88:21:F8:FF
> - Options: extended master secret, safe renegotiation,
> - Handshake was completed
> 
> - Simple Client Mode:
> 
> 20 text/gemini
> #The Twitter Oracle spake thus, the words spoken were:
> 
> ```
> Fr u hoes WEAK is u serious??
> ```
> 
> Just a tiny sample of what you're missing out on - refresh for more!*** 
> Fatal error: Error in the pull function.
> *** Server has terminated the connection abnormally.
> 
> 
> On Mon, 24 Aug 2020 at 14:42, ?ppen <tva at fastmail.se> wrote:
> > Hi all, I've been working on this in my spare time for the last week or two, still lots to do and it's buggy in places (especially tabs, and some pages aren't rendering (that _did_ work previously)) but it's shaping up nicely.
> > 
> > Download, more info, links to source etc: https://www.oppenlab.net/pr/tva/

From idf31 at memeware.net  Tue Aug 25 14:20:36 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Tue, 25 Aug 2020 16:20:36 +0300
Subject: =?UTF-8?Q?Re=3A_New_Android_Client=3A_Tv=C3=A5?=
In-Reply-To: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
Message-ID: <27a59f6d0a49eac9f71b19e169a83e6b@memeware.net>

On 2020-08-24 16:41, ?ppen wrote:
> Hi all, I've been working on this in my spare time for the last week
> or two, still lots to do and it's buggy in places (especially tabs,
> and some pages aren't rendering (that _did_ work previously)) but it's
> shaping up nicely.
> 
> Download, more info, links to source etc: 
> https://www.oppenlab.net/pr/tva/

Great android client! Looking really neat.

From sean at conman.org  Tue Aug 25 21:19:00 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 25 Aug 2020 16:19:00 -0400
Subject: New Android Client: =?iso-8859-1?Q?Tv?=
	=?iso-8859-1?Q?=E5?=
In-Reply-To: <08a2ffbd-9d57-430e-aed2-c473c0aaacf3@www.fastmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 <CAPk6LxQhdO=TjjjzxRtgb3i87iU10g1jXYkymvVTBe0MtAB=oQ@mail.gmail.com>
 <08a2ffbd-9d57-430e-aed2-c473c0aaacf3@www.fastmail.com>
Message-ID: <20200825201900.GA11468@brevard.conman.org>

It was thus said that the Great ?ppen once stated:
> Thanks Kevin, and yes, something is afoot with some addresses. The client
> torture test at gemini://gemini.conman.org/test/torture/ used to render
> fine, but in later builds it's failing. I'll investigate for the next
> release.

  Is it all the tests, or just some of them?  I can investigate from my side
as well.

  -spc


From easrng at gmail.com  Wed Aug 26 00:52:11 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Tue, 25 Aug 2020 19:52:11 -0400
Subject: Collectively maintained lists of clients, servers, sites, etc
In-Reply-To: <B429EDE1-AFDE-47D8-91C9-ECEE4D7D5E42@posteo.de>
References: <aaa97b4d2ed6cc8748574bd68cfbfa76a481d699.camel@gnu.org>
 <B429EDE1-AFDE-47D8-91C9-ECEE4D7D5E42@posteo.de>
Message-ID: <CAEzvDCXaxyJnhP9uMb-78NQUaMwN56a=XUVrUggy0aqpb4x-Gw@mail.gmail.com>

What is titan support and what clients support it? I'm new to Gemini.

On Tue, Aug 25, 2020, 3:06 AM Krispin Schulz <krispin at posteo.de> wrote:

> Hi Alex,
>
> many thanks for linking to the ?awesome-gemini? list on GitHub.
> I linked your wiki space on the list as well.
>
>
> Cheers,
>
> Krispin
>
> > On 25. Aug 2020, at 08:20, Alex Schroeder <alex at gnu.org> wrote:
> >
> > I've tried to set up a wiki space for Gemini related links. It started
> > out as a copy of the lists we have on Circumlunar Space. In theory,
> > people could just add their own projects to these pages. If you're
> > interested in helping out, please do.
> >
> > Gemini access:
> > gemini://transjovian.org/gemini/
> >
> > If your client has Titan support you can edit those pages directly. If
> > not, you can use the web:
> > https://transjovian.org:1965/gemini/
> >
> > I'm trying to go back through the list archive in order to add any
> > entries we might be missing... Happy for all the help I can get!
> >
> > Cheers
> > Alex
> >
> >
> > If you're interested in how to use the wiki space, there are more pages
> > here:
> > https://transjovian.org:1965/page/How%20To
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200825/5d5a62df/attachment.htm>

From caranatar at riseup.net  Wed Aug 26 06:49:51 2020
From: caranatar at riseup.net (Caranatar)
Date: Wed, 26 Aug 2020 01:49:51 -0400
Subject: Experimental SWI-Prolog Gemini Server
In-Reply-To: <2e1119cf0360fe64e8aaea9d11ff892d@ruhr-uni-bochum.de>
References: <2e1119cf0360fe64e8aaea9d11ff892d@ruhr-uni-bochum.de>
Message-ID: <87o8my9csg.fsf@riseup.net>

This is really cool! I'm looking forward to seeing an instance!

Paul Kosel writes:

> Greetings Geminauts!
>
> I hope I'm doing this the right way, never used a mailing list
> before. Please correct me if I do anything stupid.
> The gemini project really interested me and (un)fortunately I stumbled
> upon it during my Prolog phase so why not combine the two?
> That's exactly what I thought, which is why we got Marami now (
> https://github.com/MagnificentPako/Marami/ )!
>
> It definitely is missing some features and not-so-gracefully handles
> some requests but I'm still happy with how it turned out so far.
> I'll get up an instance running my example handler from the repo
> soon-ish (should I announce that here or not?)
>
> Again, hopefully I'm not annoying anyone with this and I wish you all
> a great day/evening/night!


-- 
sent from emacs using mu4e

From alex at alexwennerberg.com  Wed Aug 26 07:04:48 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Tue, 25 Aug 2020 23:04:48 -0700
Subject: [ANN] Flounder - a Gemini site builder/host
In-Reply-To: <C4X55HSR0CFE.404TD1BAK2R8@debian-thinkpad>
Message-ID: <159842188858.21712.13384157039736211099@debian-thinkpad>

Hey all -- just wanted to update you all that I put together a simple
Gemini homepage for Flounder -- gemini://flounder.online

I've got a small group of (mostly non-technical) users, but there's a
few active blogs on there.

Alex

From alex at gnu.org  Wed Aug 26 08:57:52 2020
From: alex at gnu.org (Alex Schroeder)
Date: Wed, 26 Aug 2020 09:57:52 +0200
Subject: Collectively maintained lists of clients, servers, sites, etc
In-Reply-To: <CAEzvDCXaxyJnhP9uMb-78NQUaMwN56a=XUVrUggy0aqpb4x-Gw@mail.gmail.com>
References: <aaa97b4d2ed6cc8748574bd68cfbfa76a481d699.camel@gnu.org>
 <B429EDE1-AFDE-47D8-91C9-ECEE4D7D5E42@posteo.de>
 <CAEzvDCXaxyJnhP9uMb-78NQUaMwN56a=XUVrUggy0aqpb4x-Gw@mail.gmail.com>
Message-ID: <dac01296e5ffa0a724c6e74466e0fa5ec14df707.camel@gnu.org>

On Tue, 2020-08-25 at 19:52 -0400, A. E. Spencer-Reed wrote:
> What is titan support and what clients support it? I'm new to Gemini.

Titan is basically an extension of Gemini. In other words, it's
explicitly *not* Gemini. I use it to upload content to the server. In
the case of a wiki, uploading text to the right URL effectively edits
the page.

Here are some links to shell functions, tiny Perl scripts, and even
bare bones openssl invokations that implement it:
https://transjovian.org:1965/page/Writing

There really isn't much to it, so this page is rather small:
https://communitywiki.org/wiki/Titan

This is a slightly edited copy of an email I sent to the mailing list
explaining the rationale for it all:
https://transjovian.org:1965/page/Titan%20history

Cheers
Alex



From tva at fastmail.se  Wed Aug 26 09:13:12 2020
From: tva at fastmail.se (=?UTF-8?Q?=C3=96ppen?=)
Date: Wed, 26 Aug 2020 09:13:12 +0100
Subject: =?UTF-8?Q?Re:_New_Android_Client:_Tv=C3=A5?=
In-Reply-To: <20200825201900.GA11468@brevard.conman.org>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 <CAPk6LxQhdO=TjjjzxRtgb3i87iU10g1jXYkymvVTBe0MtAB=oQ@mail.gmail.com>
 <08a2ffbd-9d57-430e-aed2-c473c0aaacf3@www.fastmail.com>
 <20200825201900.GA11468@brevard.conman.org>
Message-ID: <c1f191c3-1fd2-481f-a731-1eb1dcb4bfa9@www.fastmail.com>

I've solved it. For some reason creating a second buffered reader from the socket was causing the socket to close - I'm now just reusing the same reader for content that checks the header. Thanks all for the feedback - I'll get a new release out in the next few days with the fixes.

On Tue, 25 Aug 2020, at 9:19 PM, Sean Conner wrote:
> It was thus said that the Great ?ppen once stated:
> > Thanks Kevin, and yes, something is afoot with some addresses. The client
> > torture test at gemini://gemini.conman.org/test/torture/ used to render
> > fine, but in later builds it's failing. I'll investigate for the next
> > release.
> 
>   Is it all the tests, or just some of them?  I can investigate from my side
> as well.
> 
>   -spc
> 
>

From idf31 at memeware.net  Thu Aug 27 11:58:27 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Thu, 27 Aug 2020 13:58:27 +0300
Subject: Hosting service
Message-ID: <156db073bc3a38566e1016aee3b496aa@memeware.net>

Hello! Sorry if this post looks more like an ad, but I'm proud to 
announce that after some time keeping the server down for fixes and 
improvments, I have decided to start a simple hosting service!
You can read more about it here: gemini://idf.looting.uk/hosting

From sebastian at vanwa.ch  Thu Aug 27 14:04:36 2020
From: sebastian at vanwa.ch (sebastian at vanwa.ch)
Date: Thu, 27 Aug 2020 15:04:36 +0200
Subject: [ANN] vanwa.ch - personal website
Message-ID: <c1ff5abb5951bc434c84666ec6e15f86@vanwa.ch>

Hi there

On gemini://vanwa.ch I mirrored my personal website (nothing too 
interesting but still thought I'd announce it here). It gets generated 
by hugo from the same sources as the http site, using a custom output 
format and some regex hacks to reformat markdown inline links (not 
perfect but works well enough).

So far I like that I don't worry about how exactly it looks client side 
:)

Have a nice day

Sebastian


From alex at gnu.org  Thu Aug 27 17:36:34 2020
From: alex at gnu.org (Alex Schroeder)
Date: Thu, 27 Aug 2020 18:36:34 +0200
Subject: [ANN] vanwa.ch - personal website
In-Reply-To: <c1ff5abb5951bc434c84666ec6e15f86@vanwa.ch>
References: <c1ff5abb5951bc434c84666ec6e15f86@vanwa.ch>
Message-ID: <15d968313266d67619e29a1be5e653e61188629c.camel@gnu.org>

On Thu, 2020-08-27 at 15:04 +0200, sebastian at vanwa.ch wrote:
> On gemini://vanwa.ch I mirrored my personal website (nothing too 
> interesting but still thought I'd announce it here).

Welcome to Gemini space! ?

When I went to take a look, my Gemini client kept waiting for a few
seconds before rendering it all. The reason appears to be that vanwa.ch
has a valid IPv6 number but it seems that your server is not serving
IPv6 requests. When my client switches to IPv4 after a timeout, it
works?

Cheers
Alex


From sebastian at vanwa.ch  Fri Aug 28 09:24:14 2020
From: sebastian at vanwa.ch (sebastian at vanwa.ch)
Date: Fri, 28 Aug 2020 10:24:14 +0200
Subject: [ANN] vanwa.ch - personal website
In-Reply-To: <15d968313266d67619e29a1be5e653e61188629c.camel@gnu.org>
References: <c1ff5abb5951bc434c84666ec6e15f86@vanwa.ch>
 <15d968313266d67619e29a1be5e653e61188629c.camel@gnu.org>
Message-ID: <87a0ff123130c7bd595fcea4fd06dbf7@vanwa.ch>

On 2020-08-27 18:36, Alex Schroeder wrote:
> When I went to take a look, my Gemini client kept waiting for a few
> seconds before rendering it all. The reason appears to be that vanwa.ch
> has a valid IPv6 number but it seems that your server is not serving
> IPv6 requests. When my client switches to IPv4 after a timeout, it
> works?
Whoops, I forgot to take out the AAAA record, thanks for catching that!
(though it would be a great opportunity to finally set up ipv6...)

From petite.abeille at gmail.com  Fri Aug 28 12:50:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 28 Aug 2020 13:50:28 +0200
Subject: [OT] RFC8890
Message-ID: <47AD7295-43BF-4EA9-92BB-DB2613A56CD7@gmail.com>

Perhaps of interest, courtesy of Mark Nottingham:

The Internet is for End Users 
https://www.mnot.net/blog/2020/08/28/for_the_users
https://tools.ietf.org/html/rfc8890


From martin at no.ucant.org  Fri Aug 28 13:12:00 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Fri, 28 Aug 2020 13:12:00 +0100 (BST)
Subject: [OT] RFC8890
In-Reply-To: <47AD7295-43BF-4EA9-92BB-DB2613A56CD7@gmail.com>
References: <47AD7295-43BF-4EA9-92BB-DB2613A56CD7@gmail.com>
Message-ID: <alpine.DEB.2.20.2008281256300.16057@pling.qwghlm.org>

On Fri, 28 Aug 2020, Petite Abeille wrote:

> Perhaps of interest, courtesy of Mark Nottingham:
>
> The Internet is for End Users
> https://www.mnot.net/blog/2020/08/28/for_the_users
> https://tools.ietf.org/html/rfc8890

Thank you for this link. I note that the blog posts references an 
"encrypted client hello proposal", at 
https://tools.ietf.org/html/draft-ietf-tls-esni-07

I thought I had posted to this list my long-standing opinion that TLS/SSL 
effectively forces a choice between confidentiality and anonymity: if you 
want encrypted communications you need to reveal to an eavesdropper the 
identity of any endpoint that wants to be authenticated to another 
endpoint. This has been part of an unease I've had with SSL since it was 
introduced 25 years ago, though until recently it was mainly that the 
overhead of PKI was too high for small-time servers. The overhead is 
*still* too high because LetsEncrypt is still somewhat immature.

Peter Vernigorov wrote on this list recently that SSL is actually a bit 
worse than most people expected: 
https://lists.orbitalfox.eu/archives/gemini/2020/002282.html

I ran a packet sniffer on some Gemini client (gcat?) and discovered to my 
horror that he was right: the subject identity of the client certificate 
is sent in plain text over the wire: SSL does indeed force the 
deanonymisation of an endpoint wishing to be relied upon in return for 
encrypting the non-metadata content of the communication.

The IETF draft RFC referenced the piece that the OP posted would seem to 
address this issue, which is critical for Gemini, as Gemini places more 
reliance on client certificates than is usual (hitherto) in customary 
Internet applications.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

From case at acdw.net  Fri Aug 28 16:44:38 2020
From: case at acdw.net (Case Duckworth)
Date: Fri, 28 Aug 2020 15:44:38 +0000
Subject: Announcing slice.breadpunk.club
Message-ID: <7fac270c-569e-43b4-a625-77ab151c0e01@www.fastmail.com>

(mirrored at gemini://breadpunk.club/bakers/breadw/slices/1598160221.gmi)

Thanks to sloum's wonderful work at
=> gemini://gemlog.blue
as well as their generosity in sharing their codebase with me, I'm pleased to announce that breadpunk.club now has a web-facing gemini authorship tool:
=> https://slice.breadpunk.club

Bakers at breadpunk.club are now able to author posts in their gemini capsules on the web, without using ssh, ftp, or other protocols that might be blocked (as is the case for me!).  As of now, all posts will appear in a slices/ subdirectory in bakers' user capsules, but I might try and change it to allow editing of any URL the baker owns.

If you're not already a baker at breadpunk.club, you can join through the instructions at https://breadpunk.club/join/.

To get started, ssh into breadpunk.club and create a sigil file at ~/.slice.  Immediately afterward, go to
=> https://slice.breadpunk.club/reg.php
to register your username and password with slice.  That should be it!  You can start posting immediately.

I hope this makes it easier for some of our bakers update their breadlogs (which don't necessarily have to be about bread, by the way!).  I know I will be.

# Notes

Much of slice's functionality is the same as gemlog.blue's -- you can add "slices," or posts; you can edit and delete them; and you can update your password or delete your whole slice directory.  In the future, I want to enable users to edit their slice index.gmi, add options to "auto-title" slices, and possibly edit anything in their public_gemini folders.

I'd love to hear what other ideas yall have, or thoughts or concerns or whatever!  I *think* my code is secure, but I'm pretty green, so who knows?  (Should I be admitting that on the internet?)

~ breadw (acdw)

From colecmac at protonmail.com  Fri Aug 28 19:07:10 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 28 Aug 2020 18:07:10 +0000
Subject: Announcing slice.breadpunk.club
In-Reply-To: <7fac270c-569e-43b4-a625-77ab151c0e01@www.fastmail.com>
References: <7fac270c-569e-43b4-a625-77ab151c0e01@www.fastmail.com>
Message-ID: <bQtIqNoiECBp_8mvHPmv9P-jOWy2Q9MRNSEId02HdDNobrhYsYmkdDW9Wo7gjScnnncCIYF9F5zVe7aTfO_heAmYZmOBLIbAJ5otQO6GsLQ=@protonmail.com>

This is cool! It's nice to see another thing similar to gemlog.blue,
although it'd be nice as well to not end up creating an ecosystem that
relies on this all the time. Two questions:

What do you mean by "create a sigil file"?

And is the source code of this site available? That'd be great.

Cheers,
makeworld

From acdw at acdw.net  Fri Aug 28 20:08:59 2020
From: acdw at acdw.net (acdw)
Date: Fri, 28 Aug 2020 19:08:59 +0000
Subject: Announcing slice.breadpunk.club
In-Reply-To: <bQtIqNoiECBp_8mvHPmv9P-jOWy2Q9MRNSEId02HdDNobrhYsYmkdDW9Wo7gjScnnncCIYF9F5zVe7aTfO_heAmYZmOBLIbAJ5otQO6GsLQ=@protonmail.com>
References: <7fac270c-569e-43b4-a625-77ab151c0e01@www.fastmail.com>
 <bQtIqNoiECBp_8mvHPmv9P-jOWy2Q9MRNSEId02HdDNobrhYsYmkdDW9Wo7gjScnnncCIYF9F5zVe7aTfO_heAmYZmOBLIbAJ5otQO6GsLQ=@protonmail.com>
Message-ID: <341762c5-c2c3-4a1c-bb9a-491e845e5549@www.fastmail.com>

On 2020-08-28 (Friday) at 18:07, colecmac at protonmail.com wrote:

> This is cool! It's nice to see another thing similar to gemlog.blue,
> although it'd be nice as well to not end up creating an ecosystem that
> relies on this all the time. 

This is a really fair point. I really just made this (and use gemlog.blue all the time) because I don't have ssh access at work, and I figure others don't either. Ideally, there'd be another server that's like Phoebe but non-wiki-fied, or something like it -- using a partner protocol to upload content "in-band," as it were. Maybe something for me to work on!

> 
> What do you mean by "create a sigil file"?

Hey, sorry this wasn't clear. Since I wanted to limit the users of this site to users of breadpunk.club, I have the user verification just look at the users on the system to see if it's valid. Of course, I realized that there needed to be a check when someone *creates* a user account -- since the user list is public, anyone could impersonate a current user and post as them, basically. The best idea I could come up with is a file, ~/.slice, to act as a sort of sigil or sign -- if a user wants to post using slices.breadpunk.club, they'll need to ssh in and add that file (and since only they can do that, it'll ensure it's them) before they sign up.

Of course, there's still some insecurities there: there's a lag between the creation of the slice file and signing up, for example. I admit I'm relying on the smallness of this space to keep secure, which ... isn't great.

> 
> And is the source code of this site available? That'd be great.

As of now, no -- let me "clean it up" and post it somewhere tonight or tomorrow, and I'll ping this thread again. I need to comb through it a little more and make sure it's as secure as I can make it.

This is the first "real" PHP I've written (copy-pasted), so I'm a little nervous! Thanks for the interest though :)

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From pitr.vern at gmail.com  Sat Aug 29 01:50:02 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sat, 29 Aug 2020 02:50:02 +0200
Subject: [ANN] glv.one - Gemini PaaS
Message-ID: <CAG-mZ3jd5wtAwWb-wbkmmvUbVgWMuRt6tqeDT3Afy0CWgWmHmw@mail.gmail.com>

This is slightly different from other capsule hosting sites. Instead
of hosting .gmi files, glv.one will run your Docker image with Gemini
service. Obviously the barrier of entry is higher than sftp-ing text
files to a server, but I see some folks here who want to build dynamic
gemini sites but not able to host them themselves.

It all started when I was annoyed with complicated deployment of my
gemini servers (egsam, wikipedia proxy, geddit) and wanted something
simple, like a `docker push`. So I've built a Platform-as-a-Service
(think Heroku, AWS Elastic Beanstalk etc). My sites have been running
on it for about a month now.

## What you get
- 1 docker container with 0.1  CPU shares and 10mb of RAM
- MySQL database with daily backups
- Domain MY_APP.glv.one with support for a custom (sub-)domain if you have one
- At no cost (my setup is pretty economical and I can easily support ~50 apps)

## How to use it
- Ping me for an account at this email address
- Login and create an app at gemini://glv.one (this is where you will
find an admin panel)
- Push your docker images to deploy.glv.one/USER/APP:VERSION

## Example
The following example deploys a simple Go app using gig framework, but
any language is supported as long as it can run inside Docker. To
start, create the following files:

### Dockerfile
```
FROM alpine:latest

ADD example /
ADD my.crt /my.crt
ADD my.key /my.key

CMD ["/example"]
```

### main.go
```
package main

import "github.com/pitr/gig"

func main() {
  g := gig.Default()

  g.Handle("/", func(c gig.Context) error {
    return c.Gemini("# Hello, World!")
  })

  g.Run("my.crt", "my.key")
}
```

Now run the following:
- `go mod init example`
- `GOOS=linux GOARCH=amd64 go build`
- `openssl req -x509 -out my.crt -keyout my.key -newkey rsa:2048
-nodes -sha256 -subj '/CN=example.glv.one' -extensions EXT -config <(
printf "[dn]\nCN=example.glv.one\n[req]\ndistinguished_name =
dn\n[EXT]\nsubjectAltName=DNS:example.glv.one\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")`
- `docker build -t deploy.glv.one/USER/example:v1 .`
- `docker push deploy.glv.one/USER/example:v1`

That's it, it's deployed. More information, such as how to access DB,
is available once authenticated at gemini://glv.one

From mbays at sdf.org  Sat Aug 29 14:59:24 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sat, 29 Aug 2020 15:59:24 +0200
Subject: [OT] RFC8890
In-Reply-To: <alpine.DEB.2.20.2008281256300.16057@pling.qwghlm.org>
References: <47AD7295-43BF-4EA9-92BB-DB2613A56CD7@gmail.com>
 <alpine.DEB.2.20.2008281256300.16057@pling.qwghlm.org>
Message-ID: <20200829135924.gvbndumpy3hynibx@localhost>

* Friday, 2020-08-28 at 13:12 +0100 - Martin Keegan <martin at no.ucant.org>:

> Peter Vernigorov wrote on this list recently that SSL is actually 
> a bit worse than most people expected: 
> https://lists.orbitalfox.eu/archives/gemini/2020/002282.html
> 
> I ran a packet sniffer on some Gemini client (gcat?) and discovered to my 
> horror that he was right: the subject identity of the client certificate is 
> sent in plain text over the wire: SSL does indeed force the deanonymisation 
> of an endpoint wishing to be relied upon in return for encrypting the 
> non-metadata content of the communication.
> 
> The IETF draft RFC referenced the piece that the OP posted would seem to 
> address this issue, which is critical for Gemini, as Gemini places more 
> reliance on client certificates than is usual (hitherto) in customary 
> Internet applications.

If I understand correctly (I'm not entirely confident, so I'd appreciate 
it if someone who is could confirm), this is already fixed in TLS 1.3.

Meanwhile in TLS <= 1.2, it seems it is possible to deal with the 
problem by sending the client certificate as part of a renegotiation 
after the initial handshake. But I don't know how common that is.

I'm considering having my client require explicit user confirmation 
before sending a client certificate to a TLS <= 1.2 server, or at least 
print a warning.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200829/c531371f/attachment.sig>

From colecmac at protonmail.com  Sat Aug 29 20:39:17 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 29 Aug 2020 19:39:17 +0000
Subject: [ANN] glv.one - Gemini PaaS
In-Reply-To: <CAG-mZ3jd5wtAwWb-wbkmmvUbVgWMuRt6tqeDT3Afy0CWgWmHmw@mail.gmail.com>
References: <CAG-mZ3jd5wtAwWb-wbkmmvUbVgWMuRt6tqeDT3Afy0CWgWmHmw@mail.gmail.com>
Message-ID: <kY3toTrTUOV_tdHvQbqXwoR2pM6q9fjBq4KQukPY2jGeV4ev34O5QIXCD8PjyAEOsFZYQxaw81PN-agvMypUgxmVYbbVR58iw6-jnN6jWpE=@protonmail.com>

Hello Peter,

This looks awesome! Thanks for making it free, it's a nice service for
the community. And using Docker images is an interesting way to do this,
was it your idea? I like it.

One thing I noticed is that in your example you show a docker container
on Alpine, and building the Linux binary like this:

> `GOOS=linux GOARCH=amd64 go build`

Beware, if you're building a Go app on Linux, on a platform that's not
Alpine, your code may fail to run! Because Alpine uses musl instead of
libc. Some solutions:

- Build the binary in the docker container, and use multi-stage builds
  to reduce size
- Build with CGO_ENABLED=0 to not link to any C libs
- Base your docker image on Debian/Ubuntu instead of Alpine

Hope that's helpful.


Two more things.

Are you thinking about putting these instructions up on
the capsule itself? Right now glv.one just says to email you, but it'd be
nice if you pasted your email on their to give people an idea of what
they could do.

And finally, is the source code of this platform available? I think I'm
becoming the Gemini source code guy at this point, but I think it's
important.

Cheers,
makeworld

From easeout at tilde.team  Sat Aug 29 21:15:18 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Sat, 29 Aug 2020 16:15:18 -0400
Subject: [ANN] glv.one - Gemini PaaS
In-Reply-To: <kY3toTrTUOV_tdHvQbqXwoR2pM6q9fjBq4KQukPY2jGeV4ev34O5QIXCD8PjyAEOsFZYQxaw81PN-agvMypUgxmVYbbVR58iw6-jnN6jWpE=@protonmail.com>
References: <CAG-mZ3jd5wtAwWb-wbkmmvUbVgWMuRt6tqeDT3Afy0CWgWmHmw@mail.gmail.com>
 <kY3toTrTUOV_tdHvQbqXwoR2pM6q9fjBq4KQukPY2jGeV4ev34O5QIXCD8PjyAEOsFZYQxaw81PN-agvMypUgxmVYbbVR58iw6-jnN6jWpE=@protonmail.com>
Message-ID: <20200829201518.GB2239112@tilde.team>

On Sat, Aug 29, 2020 at 07:39:17PM +0000, colecmac at protonmail.com wrote:
> Beware, if you're building a Go app on Linux, on a platform that's not
> Alpine, your code may fail to run! Because Alpine uses musl instead of
> libc. Some solutions:
> 
> - Build the binary in the docker container, and use multi-stage builds
>   to reduce size
> - Build with CGO_ENABLED=0 to not link to any C libs
> - Base your docker image on Debian/Ubuntu instead of Alpine

I agree, and I'll add one more option:

- While developing an application that will run in Docker, run your
  development builds in Docker too.

One advantage of Docker is that your development environment can closely
simulate your release environment. A nice way to do that is with a
multi-stage build and an optional bind-mounted volume:

- In the first stage, include what you need to build, adding your source
  files last.
- In the second stage, do a release build.
- In the third stage, restart with blank Alpine and add the binary.

For a release image, build to the last stage. For development, build up
to the first stage only, and supply a command to build and run. If you
supply a bind mount to your source folder, you can even combine a tool
like entr and a bind mount to build and run on source file changes from
your editor of choice on the host OS.

I've used this kind of workflow with multiple languages, hosting Alpine
containers on macOS. Go is particularly good at it due to its fast build
times. This would also work if you are not rebuilding software, but say,
rerunning a static site generator given new input files. I could trim
some project down to an example if you're interested.

From easrng at gmail.com  Sat Aug 29 21:36:37 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Sat, 29 Aug 2020 16:36:37 -0400
Subject: [ANN] glv.one - Gemini PaaS
In-Reply-To: <20200829201518.GB2239112@tilde.team>
References: <CAG-mZ3jd5wtAwWb-wbkmmvUbVgWMuRt6tqeDT3Afy0CWgWmHmw@mail.gmail.com>
 <kY3toTrTUOV_tdHvQbqXwoR2pM6q9fjBq4KQukPY2jGeV4ev34O5QIXCD8PjyAEOsFZYQxaw81PN-agvMypUgxmVYbbVR58iw6-jnN6jWpE=@protonmail.com>
 <20200829201518.GB2239112@tilde.team>
Message-ID: <CAEzvDCVBrf-A1haOrdgQUSX87u6bFU+qH2b-aLBkQokf4MCeFw@mail.gmail.com>

Could I host a SMTP server with the Gemini server an make a gemail service?

On Sat, Aug 29, 2020, 4:15 PM <easeout at tilde.team> wrote:

> On Sat, Aug 29, 2020 at 07:39:17PM +0000, colecmac at protonmail.com wrote:
> > Beware, if you're building a Go app on Linux, on a platform that's not
> > Alpine, your code may fail to run! Because Alpine uses musl instead of
> > libc. Some solutions:
> >
> > - Build the binary in the docker container, and use multi-stage builds
> >   to reduce size
> > - Build with CGO_ENABLED=0 to not link to any C libs
> > - Base your docker image on Debian/Ubuntu instead of Alpine
>
> I agree, and I'll add one more option:
>
> - While developing an application that will run in Docker, run your
>   development builds in Docker too.
>
> One advantage of Docker is that your development environment can closely
> simulate your release environment. A nice way to do that is with a
> multi-stage build and an optional bind-mounted volume:
>
> - In the first stage, include what you need to build, adding your source
>   files last.
> - In the second stage, do a release build.
> - In the third stage, restart with blank Alpine and add the binary.
>
> For a release image, build to the last stage. For development, build up
> to the first stage only, and supply a command to build and run. If you
> supply a bind mount to your source folder, you can even combine a tool
> like entr and a bind mount to build and run on source file changes from
> your editor of choice on the host OS.
>
> I've used this kind of workflow with multiple languages, hosting Alpine
> containers on macOS. Go is particularly good at it due to its fast build
> times. This would also work if you are not rebuilding software, but say,
> rerunning a static site generator given new input files. I could trim
> some project down to an example if you're interested.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200829/91168cdc/attachment.htm>

From pitr.vern at gmail.com  Sat Aug 29 23:18:59 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sun, 30 Aug 2020 00:18:59 +0200
Subject: [ANN] glv.one - Gemini PaaS
In-Reply-To: <CAEzvDCVBrf-A1haOrdgQUSX87u6bFU+qH2b-aLBkQokf4MCeFw@mail.gmail.com>
References: <CAG-mZ3jd5wtAwWb-wbkmmvUbVgWMuRt6tqeDT3Afy0CWgWmHmw@mail.gmail.com>
 <kY3toTrTUOV_tdHvQbqXwoR2pM6q9fjBq4KQukPY2jGeV4ev34O5QIXCD8PjyAEOsFZYQxaw81PN-agvMypUgxmVYbbVR58iw6-jnN6jWpE=@protonmail.com>
 <20200829201518.GB2239112@tilde.team>
 <CAEzvDCVBrf-A1haOrdgQUSX87u6bFU+qH2b-aLBkQokf4MCeFw@mail.gmail.com>
Message-ID: <CAG-mZ3h8CSFFBP=b_rgqD0Cnf9ZvLGGg_QBV5Siv=3qaur+k8w@mail.gmail.com>

> Beware, if you're building a Go app on Linux, on a platform that's not
Alpine, your code may fail to run! Because Alpine uses musl instead of
libc.

Yes, I compile my Go code with CGO_ENABLED=0, good point!

> Are you thinking about putting these instructions up on
the capsule itself?

Good idea, I added a link to a How To page.

> And finally, is the source code of this platform available?

There isn't much code to make available per se. I run a private Docker
registry with some limitations (eg. can't fetch images, only push).
Registry is configured with a webhook [1] that notifies a simple http
service of a push, which in turn checks user permissions, shuts down
any old Docker containers and starts one with a new image version.
Routing mesh is nginx built with ngx_stream_ssl_preread module [2] to
route requests based on ClientHello messages. Admin panel is a very
simple (200 lines) gemini app built with gig to create apps, view
logs, rollback to old versions, etc.

[1] https://docs.docker.com/registry/notifications/
[2] http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

> Could I host a SMTP server with the Gemini server an make a gemail service?

Why not! I am not entirely sure what you mean by gemail, but ping me
and we can try setting this up.

On Sat, Aug 29, 2020 at 10:37 PM A. E. Spencer-Reed <easrng at gmail.com> wrote:
>
> Could I host a SMTP server with the Gemini server an make a gemail service?
>
> On Sat, Aug 29, 2020, 4:15 PM <easeout at tilde.team> wrote:
>>
>> On Sat, Aug 29, 2020 at 07:39:17PM +0000, colecmac at protonmail.com wrote:
>> > Beware, if you're building a Go app on Linux, on a platform that's not
>> > Alpine, your code may fail to run! Because Alpine uses musl instead of
>> > libc. Some solutions:
>> >
>> > - Build the binary in the docker container, and use multi-stage builds
>> >   to reduce size
>> > - Build with CGO_ENABLED=0 to not link to any C libs
>> > - Base your docker image on Debian/Ubuntu instead of Alpine
>>
>> I agree, and I'll add one more option:
>>
>> - While developing an application that will run in Docker, run your
>>   development builds in Docker too.
>>
>> One advantage of Docker is that your development environment can closely
>> simulate your release environment. A nice way to do that is with a
>> multi-stage build and an optional bind-mounted volume:
>>
>> - In the first stage, include what you need to build, adding your source
>>   files last.
>> - In the second stage, do a release build.
>> - In the third stage, restart with blank Alpine and add the binary.
>>
>> For a release image, build to the last stage. For development, build up
>> to the first stage only, and supply a command to build and run. If you
>> supply a bind mount to your source folder, you can even combine a tool
>> like entr and a bind mount to build and run on source file changes from
>> your editor of choice on the host OS.
>>
>> I've used this kind of workflow with multiple languages, hosting Alpine
>> containers on macOS. Go is particularly good at it due to its fast build
>> times. This would also work if you are not rebuilding software, but say,
>> rerunning a static site generator given new input files. I could trim
>> some project down to an example if you're interested.

From easrng at gmail.com  Sun Aug 30 00:09:00 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Sat, 29 Aug 2020 19:09:00 -0400
Subject: [ANN] glv.one - Gemini PaaS
In-Reply-To: <CAG-mZ3h8CSFFBP=b_rgqD0Cnf9ZvLGGg_QBV5Siv=3qaur+k8w@mail.gmail.com>
References: <CAG-mZ3jd5wtAwWb-wbkmmvUbVgWMuRt6tqeDT3Afy0CWgWmHmw@mail.gmail.com>
 <kY3toTrTUOV_tdHvQbqXwoR2pM6q9fjBq4KQukPY2jGeV4ev34O5QIXCD8PjyAEOsFZYQxaw81PN-agvMypUgxmVYbbVR58iw6-jnN6jWpE=@protonmail.com>
 <20200829201518.GB2239112@tilde.team>
 <CAEzvDCVBrf-A1haOrdgQUSX87u6bFU+qH2b-aLBkQokf4MCeFw@mail.gmail.com>
 <CAG-mZ3h8CSFFBP=b_rgqD0Cnf9ZvLGGg_QBV5Siv=3qaur+k8w@mail.gmail.com>
Message-ID: <CAEzvDCWjudZ1D0q38A5SRCOF+kT4Pa5Ta37fbd3_aeiyTA8dkA@mail.gmail.com>

GemMail, without two Ms.

On Sat, Aug 29, 2020, 6:19 PM Peter Vernigorov <pitr.vern at gmail.com> wrote:

> > Beware, if you're building a Go app on Linux, on a platform that's not
> Alpine, your code may fail to run! Because Alpine uses musl instead of
> libc.
>
> Yes, I compile my Go code with CGO_ENABLED=0, good point!
>
> > Are you thinking about putting these instructions up on
> the capsule itself?
>
> Good idea, I added a link to a How To page.
>
> > And finally, is the source code of this platform available?
>
> There isn't much code to make available per se. I run a private Docker
> registry with some limitations (eg. can't fetch images, only push).
> Registry is configured with a webhook [1] that notifies a simple http
> service of a push, which in turn checks user permissions, shuts down
> any old Docker containers and starts one with a new image version.
> Routing mesh is nginx built with ngx_stream_ssl_preread module [2] to
> route requests based on ClientHello messages. Admin panel is a very
> simple (200 lines) gemini app built with gig to create apps, view
> logs, rollback to old versions, etc.
>
> [1] https://docs.docker.com/registry/notifications/
> [2] http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html
>
> > Could I host a SMTP server with the Gemini server an make a gemail
> service?
>
> Why not! I am not entirely sure what you mean by gemail, but ping me
> and we can try setting this up.
>
> On Sat, Aug 29, 2020 at 10:37 PM A. E. Spencer-Reed <easrng at gmail.com>
> wrote:
> >
> > Could I host a SMTP server with the Gemini server an make a gemail
> service?
> >
> > On Sat, Aug 29, 2020, 4:15 PM <easeout at tilde.team> wrote:
> >>
> >> On Sat, Aug 29, 2020 at 07:39:17PM +0000, colecmac at protonmail.com
> wrote:
> >> > Beware, if you're building a Go app on Linux, on a platform that's not
> >> > Alpine, your code may fail to run! Because Alpine uses musl instead of
> >> > libc. Some solutions:
> >> >
> >> > - Build the binary in the docker container, and use multi-stage builds
> >> >   to reduce size
> >> > - Build with CGO_ENABLED=0 to not link to any C libs
> >> > - Base your docker image on Debian/Ubuntu instead of Alpine
> >>
> >> I agree, and I'll add one more option:
> >>
> >> - While developing an application that will run in Docker, run your
> >>   development builds in Docker too.
> >>
> >> One advantage of Docker is that your development environment can closely
> >> simulate your release environment. A nice way to do that is with a
> >> multi-stage build and an optional bind-mounted volume:
> >>
> >> - In the first stage, include what you need to build, adding your source
> >>   files last.
> >> - In the second stage, do a release build.
> >> - In the third stage, restart with blank Alpine and add the binary.
> >>
> >> For a release image, build to the last stage. For development, build up
> >> to the first stage only, and supply a command to build and run. If you
> >> supply a bind mount to your source folder, you can even combine a tool
> >> like entr and a bind mount to build and run on source file changes from
> >> your editor of choice on the host OS.
> >>
> >> I've used this kind of workflow with multiple languages, hosting Alpine
> >> containers on macOS. Go is particularly good at it due to its fast build
> >> times. This would also work if you are not rebuilding software, but say,
> >> rerunning a static site generator given new input files. I could trim
> >> some project down to an example if you're interested.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200829/308ff2bd/attachment-0001.htm>

From peteyboy at sdf.org  Sun Aug 30 08:21:03 2020
From: peteyboy at sdf.org (Pete D.)
Date: Sun, 30 Aug 2020 00:21:03 -0700
Subject: Geminaut, anyone else have Antivirus rejecting the executable?
Message-ID: <bdad10ad-950d-f969-836e-37fd7a212769@sdf.org>

I've tried to download and expand the exe for GemiNaut a couple times, 
and my antivirus (Vipre) pulls out the executable every time saying it's 
"Virus.Generic" or something. Anyone else seeing this?

This is Geminaut 0.8.7 package from: 
https://www.marmaladefoo.com/pages/geminaut

From jake at rmgr.dev  Sun Aug 30 09:51:43 2020
From: jake at rmgr.dev (Jake)
Date: Sun, 30 Aug 2020 08:51:43 +0000
Subject: Geminaut, anyone else have Antivirus rejecting the executable?
In-Reply-To: <bdad10ad-950d-f969-836e-37fd7a212769@sdf.org>
References: <bdad10ad-950d-f969-836e-37fd7a212769@sdf.org>
Message-ID: <wf-RYnat75p5xzmpvTuJr5WsmQhJWF2yor-7xG4noW4_eamnNzlxRXx9sUvDpxgFAaGFMb5BBjvhVWGku1-hVS9o7KY5HT1T0z9EWa44uOo=@rmgr.dev>

This reminds me, I did have Malwarebytes freak out over the marmaladefoo domain but didn't care about Geminaut itself

-------- Original Message --------
On 30 Aug. 2020, 4:51 pm, Pete D. wrote:

> I've tried to download and expand the exe for GemiNaut a couple times,
> and my antivirus (Vipre) pulls out the executable every time saying it's
> "Virus.Generic" or something. Anyone else seeing this?
>
> This is Geminaut 0.8.7 package from:
> https://www.marmaladefoo.com/pages/geminaut
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200830/ce1018d2/attachment.htm>

From luke at marmaladefoo.com  Sun Aug 30 12:58:13 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 30 Aug 2020 12:58:13 +0100
Subject: Geminaut, anyone else have Antivirus rejecting the executable?
In-Reply-To: <wf-RYnat75p5xzmpvTuJr5WsmQhJWF2yor-7xG4noW4_eamnNzlxRXx9sUvDpxgFAaGFMb5BBjvhVWGku1-hVS9o7KY5HT1T0z9EWa44uOo=@rmgr.dev>
References: <bdad10ad-950d-f969-836e-37fd7a212769@sdf.org>
 <wf-RYnat75p5xzmpvTuJr5WsmQhJWF2yor-7xG4noW4_eamnNzlxRXx9sUvDpxgFAaGFMb5BBjvhVWGku1-hVS9o7KY5HT1T0z9EWa44uOo=@rmgr.dev>
Message-ID: <5F4B9455.1000405@marmaladefoo.com>

Hi Jake and Pete

Pete: Its likely to be a false positive, but if you can send me any 
further context privately I'll see if there is anything I can do. 
GemiNaut is compiled from source, you can do so yourself

https://github.com/LukeEmmet/GemiNaut

Also Jake, if there is any further context you can provide about the 
domain I'll take a look. But there is nothing strange going on as far as 
I am aware.

Mutter mutter, antivirus, mutter...

Best wishes

  - Luke

On 30-Aug-2020 09:51, Jake wrote:
> This reminds me, I did have Malwarebytes freak out over the 
> marmaladefoo domain but didn't care about Geminaut itself
>
>
>
>
>
>
> -------- Original Message --------
> On 30 Aug. 2020, 4:51 pm, Pete D. < peteyboy at sdf.org> wrote:
>
>
>     I've tried to download and expand the exe for GemiNaut a couple times,
>     and my antivirus (Vipre) pulls out the executable every time
>     saying it's
>     "Virus.Generic" or something. Anyone else seeing this?
>
>     This is Geminaut 0.8.7 package from:
>     https://www.marmaladefoo.com/pages/geminaut
>

From sandra.snan at idiomdrottning.org  Sun Aug 30 17:15:35 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Sun, 30 Aug 2020 18:15:35 +0200
Subject: Lang parameters
Message-ID: <87imd0un2w.fsf@idiomdrottning.org>

The protocol says that servers can emit lang paramenters but it's
difficult for the server to figure out the value of that parameter since
it's not in the gmi files. Have others figured out a best practice for
this?

From colecmac at protonmail.com  Sun Aug 30 17:21:51 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 30 Aug 2020 16:21:51 +0000
Subject: Geminaut, anyone else have Antivirus rejecting the executable?
In-Reply-To: <bdad10ad-950d-f969-836e-37fd7a212769@sdf.org>
References: <bdad10ad-950d-f969-836e-37fd7a212769@sdf.org>
Message-ID: <NgO_y2Mozo6q903SIgV_v8NslL6xvo677aseeJ73HG4jvf5K6NGeGs52X7Cbcknbx3e72RvUMRCznF1pHIgI8BPeSzGHzWqMEcwjtXK1OQ0=@protonmail.com>

Here are the results for the v0.8.7 GemiNaut ZIP[1] on VirusTotal:

https://www.virustotal.com/gui/file/304c7c7895843699c3c35fae961aaece2be46d6790eda9adb9c848cbecc0e8e6/detection

15 anti-virus engines detetected the file as something malicious,
mostly declaring it a Trojan or "Gen:Variant.Ursu.931094".

This is likely because the ZIP contains an EXE and some DLLs, which
triggers[2] many anti-viruses.

Here are the results for just the GemiNaut.exe file in the ZIP:

https://www.virustotal.com/gui/file/df4039fa3f7804c0035636ce0e2304a027652c050ecf9348f2974ef93d05538d/detection

10 engines detected it this time, almost all labelling it again as
"Gen:Variant.Ursu.931094".


Hope this is useful,
makeworld


1: https://www.marmaladefoo.com/vanilla/marmaladefoo/uploads/geminaut/GemiNaut_v0_8_7.zip
2: https://github.com/Fody/Costura/issues/294


From gmym at coopdot.com  Sun Aug 30 17:26:18 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sun, 30 Aug 2020 18:26:18 +0200
Subject: Lang parameters
In-Reply-To: <87imd0un2w.fsf@idiomdrottning.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
Message-ID: <CAObwWNgKAGTpg4bMmtsCXf0voMf4bZ4LWA_xJHUzTjrg3=zmMw@mail.gmail.com>

Sandra Snan <sandra.snan at idiomdrottning.org> wrote:

> The protocol says that servers can emit lang paramenters but it's
> difficult for the server to figure out the value of that parameter since
> it's not in the gmi files. Have others figured out a best practice for
> this?
>

It's up to the server author on how to do it. The best thing would be to
standardize the procedure so it's easy to migrate between servers, but that
has not been done yet.

>From what I've seen through my limited experience is using some meta data
file for files deviating from the default language.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200830/9dc0d68c/attachment.htm>

From linde.philip at gmail.com  Sun Aug 30 17:27:51 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sun, 30 Aug 2020 18:27:51 +0200
Subject: Lang parameters
In-Reply-To: <87imd0un2w.fsf@idiomdrottning.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
Message-ID: <20200830182751.a3690c202f36472733a8122b@gmail.com>

Hi Sandra,

On Sun, 30 Aug 2020 18:15:35 +0200
Sandra Snan <sandra.snan at idiomdrottning.org> wrote:

> The protocol says that servers can emit lang paramenters but it's
> difficult for the server to figure out the value of that parameter since
> it's not in the gmi files. Have others figured out a best practice for
> this?

You can use a sidecar file, like .htaccess for web servers. For example,
if you have cheval.gmi (in french) and horse.gmi (in english) you could
have a file beside them that lists the language parameter for each file.

 $ cat .language
 horse.gmi: fr
 cheval.gmi: en

Another approach is to have language extensions in the filename, for
example horse.gmi.en and cheval.gmi.fr and let the server interpret the
extensions to decide on the language parameter.

I think web servers like Apache 2 support both of these methods in
some form, so taking a look at how Apache 2 does it might be useful.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200830/0c88c53f/attachment.sig>

From luke at marmaladefoo.com  Sun Aug 30 19:35:44 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 30 Aug 2020 19:35:44 +0100
Subject: Geminaut, anyone else have Antivirus rejecting the executable?
In-Reply-To: <NgO_y2Mozo6q903SIgV_v8NslL6xvo677aseeJ73HG4jvf5K6NGeGs52X7Cbcknbx3e72RvUMRCznF1pHIgI8BPeSzGHzWqMEcwjtXK1OQ0=@protonmail.com>
References: <bdad10ad-950d-f969-836e-37fd7a212769@sdf.org>
 <NgO_y2Mozo6q903SIgV_v8NslL6xvo677aseeJ73HG4jvf5K6NGeGs52X7Cbcknbx3e72RvUMRCznF1pHIgI8BPeSzGHzWqMEcwjtXK1OQ0=@protonmail.com>
Message-ID: <5F4BF180.7020500@marmaladefoo.com>

Thanks makeworld thats really helpful.

It at least explains some of it. I guess I should crack on and build a 
proper installer, rather than simply circulate a zip. I've been meaning to.

Also the scanners can probably detect that GemiNaut will make calls to 
other applications (like gemget). Of course all of that is legitimate, 
but perhaps that in itself also looks suspicious.

sigh

  - Luke

On 30-Aug-2020 17:21, colecmac at protonmail.com wrote:
> Here are the results for the v0.8.7 GemiNaut ZIP[1] on VirusTotal:
>
> https://www.virustotal.com/gui/file/304c7c7895843699c3c35fae961aaece2be46d6790eda9adb9c848cbecc0e8e6/detection
>
> 15 anti-virus engines detetected the file as something malicious,
> mostly declaring it a Trojan or "Gen:Variant.Ursu.931094".
>
> This is likely because the ZIP contains an EXE and some DLLs, which
> triggers[2] many anti-viruses.
>
> Here are the results for just the GemiNaut.exe file in the ZIP:
>
> https://www.virustotal.com/gui/file/df4039fa3f7804c0035636ce0e2304a027652c050ecf9348f2974ef93d05538d/detection
>
> 10 engines detected it this time, almost all labelling it again as
> "Gen:Variant.Ursu.931094".
>
>
> Hope this is useful,
> makeworld
>
>
> 1: https://www.marmaladefoo.com/vanilla/marmaladefoo/uploads/geminaut/GemiNaut_v0_8_7.zip
> 2: https://github.com/Fody/Costura/issues/294
>

From sean at conman.org  Mon Aug 31 00:57:49 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 30 Aug 2020 19:57:49 -0400
Subject: Lang parameters
In-Reply-To: <87imd0un2w.fsf@idiomdrottning.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
Message-ID: <20200830235749.GA15566@brevard.conman.org>

It was thus said that the Great Sandra Snan once stated:
> The protocol says that servers can emit lang paramenters but it's
> difficult for the server to figure out the value of that parameter since
> it's not in the gmi files. Have others figured out a best practice for
> this?

  With GLV-1.12556, you can specify the MIME type of a file via it's
extension.  This will override the normal method of detecting the MIME type
by looking at the contents.  As a side-effect, you can also specify the
language parameter.

  GLV-1.12556 doesn't do this (yet) but another option is to have the server
lookg for a configuration option to always set the languate parameter to a
known value.

  -spc

From sean at conman.org  Mon Aug 31 01:11:53 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 30 Aug 2020 20:11:53 -0400
Subject: Minimum requirements for client certificates
Message-ID: <20200831001153.GB15566@brevard.conman.org>


  I just encounted this issue with my Gemini server (running GLV-1.12556)
and caused it to stop receiving requests.  Diagnosing the issue, I found it
was most likely caused by a request to an area requiring a client
certificate, only the client certificate did NOT have a subject field.  The
Gemini protocol specification does NOT state what must be in a client
certificate, and my server made the assumption that a client certificate
will always have one (and did not check to see if it was missing).  It will
now return an error of '62' if the subject field is missing.

  So that brings me to my question---what *IS* the minimum we can expect to
be in a client certificate?  Is a client certificate without a subject
field even legal?  What about a missing issuer?

  -spc



From colecmac at protonmail.com  Mon Aug 31 01:20:16 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 31 Aug 2020 00:20:16 +0000
Subject: Minimum requirements for client certificates
In-Reply-To: <20200831001153.GB15566@brevard.conman.org>
References: <20200831001153.GB15566@brevard.conman.org>
Message-ID: <8_IpPCBexvkPFl6WQyLp9Bo_aF2rxaHzRtlHqYVMGV7rtgEIYHuxsxoh7L9QFAHh1KlnLqrKNcT4MNZcargDTh2Ul386A_8OXlatJPaNphY=@protonmail.com>

This would be a nice thing to have standardized in the spec.

I don't see why client certs need to have a subject or issuer
though. As long as they are valid certs that can form TLS
connections, than why not? However, it would also make sense
for a service like Astrobotany that relies on the client cert
Common Name to reject certs that don't have one. But that's
application specific.

makeworld

From sandra.snan at idiomdrottning.org  Mon Aug 31 05:08:19 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Mon, 31 Aug 2020 06:08:19 +0200
Subject: Lang parameters
In-Reply-To: <20200830235749.GA15566@brevard.conman.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
 <20200830235749.GA15566@brevard.conman.org>
Message-ID: <877dtfv4ng.fsf@idiomdrottning.org>

Right, thank you all for your answers so far!?

I guess what I should've asked is to what extent servers already can do
this. Sean mentioned GLV-1.12556 but it's not in sample-conf.lua as far
as I can see. I guess with gig writing a custom router is also an
option.

I just don't wanna be reinventing any existing wheels.

I have a collection of texts in a mix of languages. Each file is written
in a single language.

I'm OK with a sidecar per file, a sidecar per directory, one big sidecar
for the entire site, or with renaming the files: for example the server
gets the request for foo.gmi, it finds foo.en.gmi and serves that up as
foo.gmi in English. (Or a similar convention, foo.gmi-en, foo-en.gmi,
foo.en, I can adapt my data to fit what the server wants.) For the
sidecar solutions, I obv don't want to serve up those sidecars via
Gemini requests, they're for the server's eyes only.

Any server so far do any one of those four things (with an already
existing module, plugin, configuration, or out of the box)?

I understand that Gig or GLV-1.12556 can do it with scripting; does
those scripts already exist?

This isn't a showstopper for me getting on Gemini, I'm plowing ahead and
just not putting any language parameters in, but, I'm almost done with
the "generating the site" part and am about to choose a server
implementation.

If it doesn't exist I'll put adding the language tags very far down on
the "someday/maybe" list. So exhausted RN...?

From sean at conman.org  Mon Aug 31 05:42:09 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 31 Aug 2020 00:42:09 -0400
Subject: Lang parameters
In-Reply-To: <877dtfv4ng.fsf@idiomdrottning.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
 <20200830235749.GA15566@brevard.conman.org>
 <877dtfv4ng.fsf@idiomdrottning.org>
Message-ID: <20200831044209.GC15566@brevard.conman.org>

It was thus said that the Great Sandra Snan once stated:
> Right, thank you all for your answers so far!?
> 
> I guess what I should've asked is to what extent servers already can do
> this. Sean mentioned GLV-1.12556 but it's not in sample-conf.lua as far
> as I can see. I guess with gig writing a custom router is also an
> option.

  Ah, I see I failed to give some good examples of this in sample-conf.lua.
You can certainly do this in GLV-1.12556 on a server-wide, host-wide, or
directory-wise or file-wise manner.  For example, if you have Swedish
material in a given directory, you can do:

hosts =
{
  ['example.com'] =
  {
    handlers =
    {
      {
        path      = "^(/Swedish-stuff/)(.*)",
        module    = "GLV-1.handlers.filesystem",
        directory = "/path/to/contents",
        index     = "index.gmi", -- GLV-1.12556 defaults to .gemini
        extension = ".gmi",
        mime =
        {
          gmi = "text/gemini; lang=se_NO", -- <<<< important bit
          txt = "text/plain; lang=se_NO",
        }
      }
    }
  }
}

  If you don't include the mime section, the server will (at least on Linux,
or any POSIX system with GNU's libmagic installed) return whatever it deems
is the MIME type for a given file (it uses magic values and huristics to
determine the MIME type).

  The sample-conf.lua file has several mime blocks scattered throughout to
show where it can be included.  

> I just don't wanna be reinventing any existing wheels.
> 
> I have a collection of texts in a mix of languages. Each file is written
> in a single language.
> 
> I'm OK with a sidecar per file, a sidecar per directory, one big sidecar
> for the entire site, or with renaming the files: for example the server
> gets the request for foo.gmi, it finds foo.en.gmi and serves that up as
> foo.gmi in English. (Or a similar convention, foo.gmi-en, foo-en.gmi,
> foo.en, I can adapt my data to fit what the server wants.) For the
> sidecar solutions, I obv don't want to serve up those sidecars via
> Gemini requests, they're for the server's eyes only.

  Hmmm ... good point.
  
> Any server so far do any one of those four things (with an already
> existing module, plugin, configuration, or out of the box)?
> 
> I understand that Gig or GLV-1.12556 can do it with scripting; does
> those scripts already exist?

  While the configuration file for GLV-1.12556 is a Lua script, you can
think of it more as a configuration file.  So in this case, GLV-1.12556 can
be configured to do this out of the box.

  On the downside, installing GLV-1.12556 might not be that easy, as it
relies upon LibreSSL instead of OpenSSL.  And GNU libmagic, which somes
stock on Linux, not sure about other systems.

  -spc

From sandra.snan at idiomdrottning.org  Mon Aug 31 10:25:54 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Mon, 31 Aug 2020 11:25:54 +0200
Subject: Lang parameters
In-Reply-To: <20200831044209.GC15566@brevard.conman.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
 <20200830235749.GA15566@brevard.conman.org>
 <877dtfv4ng.fsf@idiomdrottning.org>
 <20200831044209.GC15566@brevard.conman.org>
Message-ID: <87sgc3tbdp.fsf@idiomdrottning.org>

Thank you for the follow up, Sean!

Sean Conner <sean at conman.org> writes:
>   While the configuration file for GLV-1.12556 is a Lua script, you can
> think of it more as a configuration file.  So in this case, GLV-1.12556 can
> be configured to do this out of the box.

I don't mind writing some Lua, Go, CL or any other language but that
kinda fiddling will have to go on the back burner for now.

From solderpunk at posteo.net  Mon Aug 31 17:40:18 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 31 Aug 2020 18:40:18 +0200
Subject: Lang parameters
In-Reply-To: <877dtfv4ng.fsf@idiomdrottning.org>
Message-ID: <C5BBX0YSJJO7.F703880EVPVM@stilgar>

On Mon Aug 31, 2020 at 6:08 AM CEST, Sandra Snan wrote:

> I'm OK with a sidecar per file, a sidecar per directory, one big sidecar
> for the entire site, or with renaming the files: for example the server
> gets the request for foo.gmi, it finds foo.en.gmi and serves that up as
> foo.gmi in English. (Or a similar convention, foo.gmi-en, foo-en.gmi,
> foo.en, I can adapt my data to fit what the server wants.) For the
> sidecar solutions, I obv don't want to serve up those sidecars via
> Gemini requests, they're for the server's eyes only.
>
> Any server so far do any one of those four things (with an already
> existing module, plugin, configuration, or out of the box)?

Molly Brown will read settings from files named .molly, which are
analogous to Apache's .htaccess files.  One of the settings which are
valid in these files is `DefaultLang`.  The provided value will be
applied to any .gmi file in the same directory as the .molly file, or
any subdirectory of that directory - though another .molly file deeper
down the path might override this.  This works out of the box, all you
need to do is set `ReadMollyFiles` to True in the main config file to
enable it.

Cheers,
Solderpunk

From solderpunk at posteo.net  Mon Aug 31 17:44:06 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 31 Aug 2020 18:44:06 +0200
Subject: Minimum requirements for client certificates
In-Reply-To: <8_IpPCBexvkPFl6WQyLp9Bo_aF2rxaHzRtlHqYVMGV7rtgEIYHuxsxoh7L9QFAHh1KlnLqrKNcT4MNZcargDTh2Ul386A_8OXlatJPaNphY=@protonmail.com>
Message-ID: <C5BBZXSVBBC6.E8IVE4NCV9YS@stilgar>

I think it goes without saying that at the absolute minimum a Gemini
client certificate ought to be a valid x509 certificate.  I did look
into this at some stage and IIRC the Issuer needs to be non-empty but
the Subject does not.  If that is indeed the case, then I'm not sure we
should mandate anything further.  As makeworld said, such certificates
might not be suitable for particular applications which make use of the
Subject.  I guess the appropriate server response there would be 61?  62
doesn't seem to apply since the certificate is technically valid.  But
this does make the "CERTIFICATE NOT AUTHORISED" name for 61 misleading.
Perhaps it ought to be "CERTIFICATE NOT ACCEPTED"?

Cheers,
Solderpunk


From sean at conman.org  Mon Aug 31 20:48:43 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 31 Aug 2020 15:48:43 -0400
Subject: Lang parameters
In-Reply-To: <87sgc3tbdp.fsf@idiomdrottning.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
 <20200830235749.GA15566@brevard.conman.org>
 <877dtfv4ng.fsf@idiomdrottning.org>
 <20200831044209.GC15566@brevard.conman.org>
 <87sgc3tbdp.fsf@idiomdrottning.org>
Message-ID: <20200831194843.GD15566@brevard.conman.org>

It was thus said that the Great Sandra Snan once stated:
> Thank you for the follow up, Sean!
> 
> Sean Conner <sean at conman.org> writes:
> >   While the configuration file for GLV-1.12556 is a Lua script, you can
> > think of it more as a configuration file.  So in this case, GLV-1.12556 can
> > be configured to do this out of the box.
> 
> I don't mind writing some Lua, Go, CL or any other language but that
> kinda fiddling will have to go on the back burner for now.

  What kind of fiddling?  It's pretty much just configuration.

  -spc


From sean at conman.org  Mon Aug 31 21:08:21 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 31 Aug 2020 16:08:21 -0400
Subject: Minimum requirements for client certificates
In-Reply-To: <C5BBZXSVBBC6.E8IVE4NCV9YS@stilgar>
References: <8_IpPCBexvkPFl6WQyLp9Bo_aF2rxaHzRtlHqYVMGV7rtgEIYHuxsxoh7L9QFAHh1KlnLqrKNcT4MNZcargDTh2Ul386A_8OXlatJPaNphY=@protonmail.com>
 <C5BBZXSVBBC6.E8IVE4NCV9YS@stilgar>
Message-ID: <20200831200820.GE15566@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> I think it goes without saying that at the absolute minimum a Gemini
> client certificate ought to be a valid x509 certificate.  I did look
> into this at some stage and IIRC the Issuer needs to be non-empty but
> the Subject does not.  

  I was unaware of this and (incorrectly) assumed that the issuer and
subject fields would always be present.  Maybe mention somewhere in the
specification that servers could expect non-subject client certificates.

  -spc

From luke at marmaladefoo.com  Mon Aug 31 22:41:39 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 31 Aug 2020 22:41:39 +0100
Subject: [ANN] The Duckling Proxy
Message-ID: <5F4D6E93.5040305@marmaladefoo.com>

Hi All

I'm pleased to announce The Duckling Proxy ? - a scheme-specific proxy 
to access HTTP resources from normal Gemini clients.

Motivated by my recent discussion on the merits of opening up access to 
the Small Web in a sane way. One option is to plug an adapter into your 
client, the other is to use a scheme specific proxy.

gemini://gemini.marmaladefoo.com/blog/31-Aug-2020_The_Duckling_Proxy.gmi

So any Gemini client that supports scheme specific proxies should be 
able to connect to Duckling. Another example of a scheme-specific proxy 
is Solderpunk's Agena proxy which allows access to gopher:// resources. 
Duckling works in a similar way.

Once your proxy is in place and running, and you have configured your 
client to use it, you can request http resources using normal Gemini 
request:

Client: <http-url><crlf>
Server: 20 text/gemini
...continues...

Duckling translates all web pages into gemtext, so it is just a normal 
Gemini server, as far as your client is concerned.

View the Small Web using your favourite Gemini client, and benefit from:

* No tracking or cookies
* No javascript
* No server styling, just content
* No client headers

Obviously, not every web site will work as expected, especially those 
requiring client side javascript/cookies/forms in order to work 
effectively. In this case, just launch your normal web browser. Or maybe 
give those pages a miss anyway?

Currently the following clients can be used with Duckling Proxy

* AV-98 - apply the patch from the source repo then use `set http_proxy 
machine:port` to access
* diohsc - edit diohscrc config file
* gemget - use -p option
* GemiNaut (unreleased build, coming soon, PM me if you want early access)

Any other clients that implement proxy support in the future should be 
able to use it. I understand Amfora will be able to connect to it in an 
upcoming release. Let me know if you implement proxy support in your 
client and I'll add it to the list.

Best Wishes

  - Luke

From kevin at susa.net  Tue Sep  1 00:05:44 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 1 Sep 2020 00:05:44 +0100
Subject: Minimum requirements for client certificates
In-Reply-To: <C5BBZXSVBBC6.E8IVE4NCV9YS@stilgar>
References: <8_IpPCBexvkPFl6WQyLp9Bo_aF2rxaHzRtlHqYVMGV7rtgEIYHuxsxoh7L9QFAHh1KlnLqrKNcT4MNZcargDTh2Ul386A_8OXlatJPaNphY=@protonmail.com>
 <C5BBZXSVBBC6.E8IVE4NCV9YS@stilgar>
Message-ID: <CAPk6LxSj8Wx=EzkETop_uTesT850YOvKhUs6xuANKSwvUXhVFw@mail.gmail.com>

I think that, if a server requires a subject and no subject is given, then
it is sensible to say that the certificate is not authorised, in much the
same way that failing to provide a username would render a traditional
login unauthorised. I don't see that as misleading, and it would seem an
application specific matter to get appropriate credentials from the user.

Kevin

On Mon, 31 Aug 2020 at 17:52, Solderpunk <solderpunk at posteo.net> wrote:

> I think it goes without saying that at the absolute minimum a Gemini
> client certificate ought to be a valid x509 certificate.  I did look
> into this at some stage and IIRC the Issuer needs to be non-empty but
> the Subject does not.  If that is indeed the case, then I'm not sure we
> should mandate anything further.  As makeworld said, such certificates
> might not be suitable for particular applications which make use of the
> Subject.  I guess the appropriate server response there would be 61?  62
> doesn't seem to apply since the certificate is technically valid.  But
> this does make the "CERTIFICATE NOT AUTHORISED" name for 61 misleading.
> Perhaps it ought to be "CERTIFICATE NOT ACCEPTED"?
>
> Cheers,
> Solderpunk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200901/8f9cd668/attachment.htm>

From jake at rmgr.dev  Tue Sep  1 01:06:25 2020
From: jake at rmgr.dev (Jake)
Date: Tue, 01 Sep 2020 00:06:25 +0000
Subject: [ANN] The Duckling Proxy
In-Reply-To: <5F4D6E93.5040305@marmaladefoo.com>
References: <5F4D6E93.5040305@marmaladefoo.com>
Message-ID: <wKV7JeXLh_qivaamcH5fvq4yRycRylOz4QCzCXRvzr5o47Z9gbkIZzfQyBfkCv_71toq76M9P-H_uw-tQ3o0oBnMx2nJDOFS3nonuY9ZMQg=@rmgr.dev>

Literally just finished getting my own http proxy and AV98 patch together and decided to check my emails and see that you've beaten me to the punch! Your proxy is much better than mine (mine is basically Agena with a subprocess call to html2gmi) so I might just shelve mine! ;)
-------- Original Message --------
On 1 Sep. 2020, 7:11 am, Luke Emmet wrote:

> Hi All
>
> I'm pleased to announce The Duckling Proxy ? - a scheme-specific proxy
> to access HTTP resources from normal Gemini clients.
>
> Motivated by my recent discussion on the merits of opening up access to
> the Small Web in a sane way. One option is to plug an adapter into your
> client, the other is to use a scheme specific proxy.
>
> gemini://gemini.marmaladefoo.com/blog/31-Aug-2020_The_Duckling_Proxy.gmi
>
> So any Gemini client that supports scheme specific proxies should be
> able to connect to Duckling. Another example of a scheme-specific proxy
> is Solderpunk's Agena proxy which allows access to gopher:// resources.
> Duckling works in a similar way.
>
> Once your proxy is in place and running, and you have configured your
> client to use it, you can request http resources using normal Gemini
> request:
>
> Client: <http-url><crlf>
> Server: 20 text/gemini
> ...continues...
>
> Duckling translates all web pages into gemtext, so it is just a normal
> Gemini server, as far as your client is concerned.
>
> View the Small Web using your favourite Gemini client, and benefit from:
>
> * No tracking or cookies
> * No javascript
> * No server styling, just content
> * No client headers
>
> Obviously, not every web site will work as expected, especially those
> requiring client side javascript/cookies/forms in order to work
> effectively. In this case, just launch your normal web browser. Or maybe
> give those pages a miss anyway?
>
> Currently the following clients can be used with Duckling Proxy
>
> * AV-98 - apply the patch from the source repo then use `set http_proxy
> machine:port` to access
> * diohsc - edit diohscrc config file
> * gemget - use -p option
> * GemiNaut (unreleased build, coming soon, PM me if you want early access)
>
> Any other clients that implement proxy support in the future should be
> able to use it. I understand Amfora will be able to connect to it in an
> upcoming release. Let me know if you implement proxy support in your
> client and I'll add it to the list.
>
> Best Wishes
>
> - Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200901/4a8d3d3d/attachment-0001.htm>

From baschdel at disroot.org  Tue Sep  1 17:53:27 2020
From: baschdel at disroot.org (Baschdel)
Date: Tue, 1 Sep 2020 18:53:27 +0200
Subject: Minimum requirements for client certificates
In-Reply-To: <20200831001153.GB15566@brevard.conman.org>
References: <20200831001153.GB15566@brevard.conman.org>
Message-ID: <9a4871d4-34da-b42e-62a6-afdbf8ca6500@disroot.org>

Sorry, that could have been me, dragonstone still generates certificates 
without a subject (And it won't be updated since I'm currently working 
on it successor).
Also there should be s little information as possible stored in the 
client certificates since they get transmitted in the clear to avoid 
giving away extra data to someone who is "just" eavesdropping without 
messing with the connection itself (and therefore having a pretty good 
chance of staying undetected).

Have a nice day!
-? Baschdel

P.s. Apologies to Sean for sending a duplicated mail, I apparently still 
manage to hit the wrong reply button in thunderbird

On 31.08.20 02:11, Sean Conner wrote:
>    I just encounted this issue with my Gemini server (running GLV-1.12556)
> and caused it to stop receiving requests.  Diagnosing the issue, I found it
> was most likely caused by a request to an area requiring a client
> certificate, only the client certificate did NOT have a subject field.  The
> Gemini protocol specification does NOT state what must be in a client
> certificate, and my server made the assumption that a client certificate
> will always have one (and did not check to see if it was missing).  It will
> now return an error of '62' if the subject field is missing.
>
>    So that brings me to my question---what *IS* the minimum we can expect to
> be in a client certificate?  Is a client certificate without a subject
> field even legal?  What about a missing issuer?
>
>    -spc
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200901/f09a0384/attachment.htm>

From cel at celehner.com  Wed Sep  2 00:43:34 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Tue, 1 Sep 2020 19:43:34 -0400
Subject: Gemini Archiving and WARC
Message-ID: <20200901194334.0cbc23e4@celehner.com>

Hi Gemini List,

Has anyone thought about, or implemented, archiving of Gemini content/traffic?

WARC (Web ARChive)? is a standard format used for web archiving. It uses text headers for metadata like in HTTP and email. It looks to me like WARC could be adapted for Gemini. The WARC spec supports multiple URI schemes, although it doesn't specify any other than http/https, ftp, and dns?. Bespoke formats could also be used, of course, or just downloading files wget-style, but using a standard format could allow for interop with "the WARC ecosystem"?.

Archive Team? has also worked on archiving non-HTTP protocols like FTP? and Gopher?.

I think there is an opportunity for people to maintain high-quality archives of Gemini content, like what the Internet Archive? and archive.today? do for the HTTP(S) Web. Now is a good time to start, while many of the original Gemini hosts? are still online.

Regards,
Charles E. Lehner

? https://en.wikipedia.org/wiki/Web_ARChive
? https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/#ftp-scheme
? https://www.archiveteam.org/index.php?title=The_WARC_Ecosystem
? https://www.archiveteam.org/
  https://en.wikipedia.org/wiki/Archive_Team
? https://www.archiveteam.org/index.php?title=FTP
? https://www.archiveteam.org/index.php?title=Gopher
? https://en.wikipedia.org/wiki/Internet_Archive
  https://archive.org/
? https://archive.today
  https://en.wikipedia.org/wiki/Archive.today
? gemini://gemini.circumlunar.space/servers/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200901/916693f1/attachment.sig>

From acdw at acdw.net  Wed Sep  2 02:23:22 2020
From: acdw at acdw.net (acdw)
Date: Wed, 02 Sep 2020 01:23:22 +0000
Subject: Gemini Archiving and WARC
In-Reply-To: <20200901194334.0cbc23e4@celehner.com>
References: <20200901194334.0cbc23e4@celehner.com>
Message-ID: <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>

On 2020-09-01 (Tuesday) at 23:43, Charles E. Lehner <cel at celehner.com> wrote:

> Hi Gemini List,
> 
> Has anyone thought about, or implemented, archiving of Gemini content/traffic?
> 
> WARC (Web ARChive)? is a standard format used for web archiving. It 
> uses text headers for metadata like in HTTP and email. It looks to me 
> like WARC could be adapted for Gemini. The WARC spec supports multiple 
> URI schemes, although it doesn't specify any other than http/https, 
> ftp, and dns?. Bespoke formats could also be used, of course, or just 
> downloading files wget-style, but using a standard format could allow 
> for interop with "the WARC ecosystem"?.
> 
> Archive Team? has also worked on archiving non-HTTP protocols like FTP? 
> and Gopher?.
> 
> I think there is an opportunity for people to maintain high-quality 
> archives of Gemini content, like what the Internet Archive? and 
> archive.today? do for the HTTP(S) Web. Now is a good time to start, 
> while many of the original Gemini hosts? are still online.
> 
> Regards,
> Charles E. Lehner
> 
> ? https://en.wikipedia.org/wiki/Web_ARChive
> ? 
> https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/#ftp-scheme
> ? https://www.archiveteam.org/index.php?title=The_WARC_Ecosystem
> ? https://www.archiveteam.org/
>   https://en.wikipedia.org/wiki/Archive_Team
> ? https://www.archiveteam.org/index.php?title=FTP
> ? https://www.archiveteam.org/index.php?title=Gopher
> ? https://en.wikipedia.org/wiki/Internet_Archive
>   https://archive.org/
> ? https://archive.today
>   https://en.wikipedia.org/wiki/Archive.today
> ? gemini://gemini.circumlunar.space/servers/
>

I personally think this is a great idea, but I know some might not be so on-board with it. I'm thinking of solderpunk's post (in their gopherhole, actually): gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/the-individual-archivist-and-ghosts-of-gophers-past.txt

So is there a way to opt-out of archiving for publishers? Some in the community might want to know about it, though I personally am of the opinion that if you've published it, it's now the property of the commons.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From alex at alexwennerberg.com  Wed Sep  2 02:40:34 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Tue, 01 Sep 2020 18:40:34 -0700
Subject: Gemini Archiving and WARC
In-Reply-To: <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
References: <20200901194334.0cbc23e4@celehner.com>
 <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
Message-ID: <159901083495.24930.16728578978187428266@debian-thinkpad>

Quoting acdw (2020-09-01 18:23:22)
> On 2020-09-01 (Tuesday) at 23:43, Charles E. Lehner <cel at celehner.com> wrote:
> So is there a way to opt-out of archiving for publishers? Some in the community might want to know about it, though I personally am of the opinion that if you've published it, it's now the property of the commons.

Perhaps via robots.txt? I block ia_archiver from pages that I don't want
archived on http(s), for example.

Alex

From tgrom.automail at nuegia.net  Wed Sep  2 06:08:35 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Tue, 1 Sep 2020 22:08:35 -0700
Subject: Gemini Archiving and WARC
In-Reply-To: <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
References: <20200901194334.0cbc23e4@celehner.com>
 <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
Message-ID: <20200901220835.03259999@viridi>

On Wed, 02 Sep 2020 01:23:22 +0000
acdw <acdw at acdw.net> wrote:

> On 2020-09-01 (Tuesday) at 23:43, Charles E. Lehner
> <cel at celehner.com> wrote:
> 
> > Hi Gemini List,
> > 
> > Has anyone thought about, or implemented, archiving of Gemini
> > content/traffic?
> > 
> > WARC (Web ARChive)? is a standard format used for web archiving. It 
> > uses text headers for metadata like in HTTP and email. It looks to
> > me like WARC could be adapted for Gemini. The WARC spec supports
> > multiple URI schemes, although it doesn't specify any other than
> > http/https, ftp, and dns?. Bespoke formats could also be used, of
> > course, or just downloading files wget-style, but using a standard
> > format could allow for interop with "the WARC ecosystem"?.
> > 
> > Archive Team? has also worked on archiving non-HTTP protocols like
> > FTP? and Gopher?.
> > 
> > I think there is an opportunity for people to maintain high-quality 
> > archives of Gemini content, like what the Internet Archive? and 
> > archive.today? do for the HTTP(S) Web. Now is a good time to start, 
> > while many of the original Gemini hosts? are still online.
> > 
> > Regards,
> > Charles E. Lehner
> > 
> > ? https://en.wikipedia.org/wiki/Web_ARChive
> > ? 
> > https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/#ftp-scheme
> > ? https://www.archiveteam.org/index.php?title=The_WARC_Ecosystem
> > ? https://www.archiveteam.org/
> >   https://en.wikipedia.org/wiki/Archive_Team
> > ? https://www.archiveteam.org/index.php?title=FTP
> > ? https://www.archiveteam.org/index.php?title=Gopher
> > ? https://en.wikipedia.org/wiki/Internet_Archive
> >   https://archive.org/
> > ? https://archive.today
> >   https://en.wikipedia.org/wiki/Archive.today
> > ? gemini://gemini.circumlunar.space/servers/
> >  
> 
> I personally think this is a great idea, but I know some might not be
> so on-board with it. I'm thinking of solderpunk's post (in their
> gopherhole, actually):
> gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/the-individual-archivist-and-ghosts-of-gophers-past.txt
> 
> So is there a way to opt-out of archiving for publishers? Some in the
> community might want to know about it, though I personally am of the
> opinion that if you've published it, it's now the property of the
> commons.
> 

Ounce you publish something to the internet there is no retracting it.
This is one of the first things I was taught the first time I used the
net. Alongside never using your real name on the net unless your
publishing something.

-- 
 _______________________________________ 
/ Concentrate on th'cute, li'l CARTOON  \
| GUYS! Remember the SERIAL NUMBERS!!   |
| Follow the WHIPPLE AVE. EXIT!! Have a |
| FREE PEPSI!! Turn LEFT at th'HOLIDAY  |
| INN!! JOIN the CREDIT WORLD!! MAKE me |
\ an OFFER!!!                           /
 --------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

From sean at conman.org  Wed Sep  2 09:15:27 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 2 Sep 2020 04:15:27 -0400
Subject: Minimum requirements for client certificates
In-Reply-To: <9a4871d4-34da-b42e-62a6-afdbf8ca6500@disroot.org>
References: <20200831001153.GB15566@brevard.conman.org>
 <9a4871d4-34da-b42e-62a6-afdbf8ca6500@disroot.org>
Message-ID: <20200902081526.GF15566@brevard.conman.org>

It was thus said that the Great Baschdel once stated:
> Sorry, that could have been me, dragonstone still generates certificates 
> without a subject (And it won't be updated since I'm currently working 
> on it successor).

  There is no need to apologize, things happen, and in this case, my program
did the wrong thing due to a misunderstanding I had about client
certificates.  I'm just glad the bug was found.

> Also there should be s little information as possible stored in the 
> client certificates since they get transmitted in the clear to avoid 
> giving away extra data to someone who is "just" eavesdropping without 
> messing with the connection itself (and therefore having a pretty good 
> chance of staying undetected).
> 
> Have a nice day!

  You too.

> -? Baschdel
> 
> P.s. Apologies to Sean for sending a duplicated mail, I apparently still 
> manage to hit the wrong reply button in thunderbird

  No harm with that either.  

  -spc


From b__m__e at mailfence.com  Wed Sep  2 23:28:46 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Thu, 3 Sep 2020 00:28:46 +0200 (CEST)
Subject: Gemini Archiving and WARC
Message-ID: <810126065.222021.1599085726830@ichabod.co-bxl>

I can appreciate the instinct to archive, but I fall into the camp that 
would generally prefer that it not be done (while respecting that with
the way the technology is built, there is not a reasonable way to
prevent it).

I think a great tragedy of the internet is the inability to be forgotten
and to retract and change and not have your past mistakes dictate
your present. I dont have a technical solution for that in gemini, or
for that matter in gopher... but think that community norms and
expectations should develop around it organically (which is of
taking place currently in this discussion and will continue to do
so over time). I definitely support the commons for articles,
information, and "knowledge"... but hesitate to extend that to what
are sometimes the only personal outlets that some people may have.

I think if something like `robots.txt` were to be used for this
purpose I would recommend doing it at the directory level (and thus
break from how robots.txt works). In gemini many (most?) users are a
part of multiuser systems. If `robots.txt` at the root were used it 
would generally control the whole domain and not allow for
individual users to opt in or out. To that, I would also put in a vote for
an opt-in system rather than an opt-out system (like robots.txt). Opt-in
empowers all users to make choices whereas opt-out is often limited
to those that know to do so and have the technical know how to do
so.

There are also environmental and energy arguments against full
protocol archiving, though those costs may be small while gemini is
at or around its current size.

Anyway, just a few thoughts.

From jmcbray at carcosa.net  Wed Sep  2 23:42:34 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 02 Sep 2020 18:42:34 -0400
Subject: New Android Client: =?utf-8?Q?Tv=C3=A5?=
In-Reply-To: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 (=?utf-8?Q?=22=C3=96ppen=22's?= message of "Mon, 24 Aug 2020 14:41:26
 +0100")
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
Message-ID: <871rjj3in9.fsf@dorothy.carcosa.net>

?ppen <tva at fastmail.se> writes:

> Hi all, I've been working on this in my spare time for the last week or two,

Hey, this looks really great, visually/design-wise. I noticed that it
supports Android system dark/light themes. The light theme is, IMO, a
*little* low-contrast, though it looks nice.  Looking forward to seeing
things like bookmarks added.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From flexibeast at gmail.com  Thu Sep  3 05:59:50 2020
From: flexibeast at gmail.com (Alexis)
Date: Thu, 03 Sep 2020 14:59:50 +1000
Subject: New Android Client: =?utf-8?Q?Tv=C3=A5?=
In-Reply-To: <871rjj3in9.fsf@dorothy.carcosa.net>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 <871rjj3in9.fsf@dorothy.carcosa.net>
Message-ID: <87imcvwj3t.fsf@ada>


Jason McBrayer <jmcbray at carcosa.net> writes:

> Hey, this looks really great, visually/design-wise ... The light 
> theme is, IMO, a *little* low-contrast, though it looks nice.

Agreed on both points - i like the overall design, but currently 
find the the light theme too low-contrast. At any rate, i 
certainly appreciate the work so far!

A technical point which might already have been noted: the Gemini 
speculative spec page is truncated for me. The heading "5.4.3 
Preformatting toggle lines" is displayed, but the only text after 
that is a preformatted block containing the text "Preformatting 
toggle lines can be thought of as analogous to <pre> and </pre> 
tags in HTML." i'm guessing this might be connected with the 
presence of "```" in the first para of that section?


Alexis.

From luke at marmaladefoo.com  Thu Sep  3 08:11:17 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 03 Sep 2020 08:11:17 +0100
Subject: [ANN] The Duckling Proxy
In-Reply-To: <wKV7JeXLh_qivaamcH5fvq4yRycRylOz4QCzCXRvzr5o47Z9gbkIZzfQyBfkCv_71toq76M9P-H_uw-tQ3o0oBnMx2nJDOFS3nonuY9ZMQg=@rmgr.dev>
References: <5F4D6E93.5040305@marmaladefoo.com>
 <wKV7JeXLh_qivaamcH5fvq4yRycRylOz4QCzCXRvzr5o47Z9gbkIZzfQyBfkCv_71toq76M9P-H_uw-tQ3o0oBnMx2nJDOFS3nonuY9ZMQg=@rmgr.dev>
Message-ID: <5F509715.8070103@marmaladefoo.com>

Well I suppose you can't keep a good idea down!?

Maybe there is still a role for a proxy where you can plug in command 
line utilities, like html2gmi or others - could be a flexible solution, 
or preferred if people want to hack on a python flavoured proxy server.

I also fixed the link below which was broken for a while - the updated 
page is now here:

gemini://gemini.marmaladefoo.com/blog/1-Sep-2020_The_Duckling_Proxy.gmi

Best Wishes

  - Luke

On 01-Sep-2020 01:06, Jake wrote:
> Literally just finished getting my own http proxy and AV98 patch 
> together and decided to check my emails and see that you've beaten me 
> to the punch! Your proxy is much better than mine (mine is basically 
> Agena with a subprocess call to html2gmi) so I might just shelve mine! ;)
> -------- Original Message --------
> On 1 Sep. 2020, 7:11 am, Luke Emmet < luke at marmaladefoo.com> wrote:
>
>
>     Hi All
>
>     I'm pleased to announce The Duckling Proxy ? - a scheme-specific
>     proxy
>     to access HTTP resources from normal Gemini clients.
>
>     Motivated by my recent discussion on the merits of opening up
>     access to
>     the Small Web in a sane way. One option is to plug an adapter into
>     your
>     client, the other is to use a scheme specific proxy.
>
>     gemini://gemini.marmaladefoo.com/blog/31-Aug-2020_The_Duckling_Proxy.gmi
>     <http://marmaladefoo.com/blog/31-Aug-2020_The_Duckling_Proxy.gmi>
>
>     So any Gemini client that supports scheme specific proxies should be
>     able to connect to Duckling. Another example of a scheme-specific
>     proxy
>     is Solderpunk's Agena proxy which allows access to gopher://
>     resources.
>     Duckling works in a similar way.
>
>     Once your proxy is in place and running, and you have configured your
>     client to use it, you can request http resources using normal Gemini
>     request:
>
>     Client: <http-url><crlf>
>     Server: 20 text/gemini
>     ...continues...
>
>     Duckling translates all web pages into gemtext, so it is just a normal
>     Gemini server, as far as your client is concerned.
>
>     View the Small Web using your favourite Gemini client, and benefit
>     from:
>
>     * No tracking or cookies
>     * No javascript
>     * No server styling, just content
>     * No client headers
>
>     Obviously, not every web site will work as expected, especially those
>     requiring client side javascript/cookies/forms in order to work
>     effectively. In this case, just launch your normal web browser. Or
>     maybe
>     give those pages a miss anyway?
>
>     Currently the following clients can be used with Duckling Proxy
>
>     * AV-98 - apply the patch from the source repo then use `set
>     http_proxy
>     machine:port` to access
>     * diohsc - edit diohscrc config file
>     * gemget - use -p option
>     * GemiNaut (unreleased build, coming soon, PM me if you want early
>     access)
>
>     Any other clients that implement proxy support in the future should be
>     able to use it. I understand Amfora will be able to connect to it
>     in an
>     upcoming release. Let me know if you implement proxy support in your
>     client and I'll add it to the list.
>
>     Best Wishes
>
>     - Luke
>

From sotirisp at protonmail.com  Thu Sep  3 10:17:06 2020
From: sotirisp at protonmail.com (Sotiris Papatheodorou)
Date: Thu, 03 Sep 2020 09:17:06 +0000
Subject: Gemini Archiving and WARC
In-Reply-To: <810126065.222021.1599085726830@ichabod.co-bxl>
References: <810126065.222021.1599085726830@ichabod.co-bxl>
Message-ID: <GDcZQyPkMK__3DQLJq0IcyRI4zaEhj-SNgbSobhzc-L2YGqF6l63QsDnZVhBvW4YwYU6XVSG5QHzpbxmGSHQJjeiqYVR2-JXI1tCahLqeLw=@protonmail.com>

On Wednesday, September 2, 2020, Brian Evans wrote:
> I think if something like `robots.txt` were to be used for this
> purpose I would recommend doing it at the directory level (and thus
> break from how robots.txt works).

On Wednesday, September 2, 2020, Brian Evans wrote:
> To that, I would also put in a vote for
> an opt-in system rather than an opt-out system (like robots.txt).

Agreed on both points! I was thinking of implementing a personal archiving system like the one mentioned by Solderpunk in
gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/the-individual-archivist-and-ghosts-of-gophers-past.txt


From tva at fastmail.se  Thu Sep  3 11:23:13 2020
From: tva at fastmail.se (=?UTF-8?Q?=C3=96ppen?=)
Date: Thu, 03 Sep 2020 11:23:13 +0100
Subject: =?UTF-8?Q?Re:_New_Android_Client:_Tv=C3=A5?=
In-Reply-To: <87imcvwj3t.fsf@ada>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 <871rjj3in9.fsf@dorothy.carcosa.net> <87imcvwj3t.fsf@ada>
Message-ID: <eb1098ab-1b18-4b51-8d93-6d1aaed0b729@www.fastmail.com>

Thanks both. 

Yes, light theme could do with a little attention. My device is permanently in dark mode so it's been neglected and light theme uses the Android defaults. 

Jason; someone else alerted me to the nested ``` issue just yesterday when some ascii art they had contained it. Simple fix will be in next release. 

Next beta will be sometime in next few days. Lot's of small bug fixes, and an in-app MP3 player (you click a file, it plays, you can carry on browsing). I've also removed tabs, they didn't help the browsing experience and were buggy anyway. If I have time I'll incorporate the GUS trackback service so you can easily see which pages link where. 

That'll be the last release for a while while I concentrate on something that is needed: bookmarks. 

I also need to check GUS for the most common filetypes and add support for those (even if they're just passed to the OS to handle (eg. .pdf)).

I'm also thinking about a future aggregation feature, I'll do some research before clogging up this list but I think it should be possible for clients to detect a Gemtext document with a series of dates in and offer a 'follow' button. I keep finding interesting Gemlogs then losing them again, bookmarks will help with that, but an aggregated timeline would be a fantastic feature (I know Solderpunk has done some work with Atom feeds for Gemini but if it feasible I like the zero setup approach). 

On Thu, 3 Sep 2020, at 5:59 AM, Alexis wrote:
> 
> Jason McBrayer <jmcbray at carcosa.net> writes:
> 
> > Hey, this looks really great, visually/design-wise ... The light 
> > theme is, IMO, a *little* low-contrast, though it looks nice.
> 
> Agreed on both points - i like the overall design, but currently 
> find the the light theme too low-contrast. At any rate, i 
> certainly appreciate the work so far!
> 
> A technical point which might already have been noted: the Gemini 
> speculative spec page is truncated for me. The heading "5.4.3 
> Preformatting toggle lines" is displayed, but the only text after 
> that is a preformatted block containing the text "Preformatting 
> toggle lines can be thought of as analogous to <pre> and </pre> 
> tags in HTML." i'm guessing this might be connected with the 
> presence of "```" in the first para of that section?
> 
> 
> Alexis.
>

From easrng at gmail.com  Thu Sep  3 15:48:22 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Thu, 3 Sep 2020 10:48:22 -0400
Subject: =?UTF-8?Q?Re=3A_New_Android_Client=3A_Tv=C3=A5?=
In-Reply-To: <eb1098ab-1b18-4b51-8d93-6d1aaed0b729@www.fastmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 <871rjj3in9.fsf@dorothy.carcosa.net> <87imcvwj3t.fsf@ada>
 <eb1098ab-1b18-4b51-8d93-6d1aaed0b729@www.fastmail.com>
Message-ID: <CAEzvDCWb17rJwXX1xkom8q45HwDK2=9=i_shjTpVz1vfvnEhgA@mail.gmail.com>

Adding client certificates would be nice too, unless there's a system
setting I'm missing.

On Thu, Sep 3, 2020 at 6:23 AM ?ppen <tva at fastmail.se> wrote:

> Thanks both.
>
> Yes, light theme could do with a little attention. My device is
> permanently in dark mode so it's been neglected and light theme uses the
> Android defaults.
>
> Jason; someone else alerted me to the nested ``` issue just yesterday when
> some ascii art they had contained it. Simple fix will be in next release.
>
> Next beta will be sometime in next few days. Lot's of small bug fixes, and
> an in-app MP3 player (you click a file, it plays, you can carry on
> browsing). I've also removed tabs, they didn't help the browsing experience
> and were buggy anyway. If I have time I'll incorporate the GUS trackback
> service so you can easily see which pages link where.
>
> That'll be the last release for a while while I concentrate on something
> that is needed: bookmarks.
>
> I also need to check GUS for the most common filetypes and add support for
> those (even if they're just passed to the OS to handle (eg. .pdf)).
>
> I'm also thinking about a future aggregation feature, I'll do some
> research before clogging up this list but I think it should be possible for
> clients to detect a Gemtext document with a series of dates in and offer a
> 'follow' button. I keep finding interesting Gemlogs then losing them again,
> bookmarks will help with that, but an aggregated timeline would be a
> fantastic feature (I know Solderpunk has done some work with Atom feeds for
> Gemini but if it feasible I like the zero setup approach).
>
> On Thu, 3 Sep 2020, at 5:59 AM, Alexis wrote:
> >
> > Jason McBrayer <jmcbray at carcosa.net> writes:
> >
> > > Hey, this looks really great, visually/design-wise ... The light
> > > theme is, IMO, a *little* low-contrast, though it looks nice.
> >
> > Agreed on both points - i like the overall design, but currently
> > find the the light theme too low-contrast. At any rate, i
> > certainly appreciate the work so far!
> >
> > A technical point which might already have been noted: the Gemini
> > speculative spec page is truncated for me. The heading "5.4.3
> > Preformatting toggle lines" is displayed, but the only text after
> > that is a preformatted block containing the text "Preformatting
> > toggle lines can be thought of as analogous to <pre> and </pre>
> > tags in HTML." i'm guessing this might be connected with the
> > presence of "```" in the first para of that section?
> >
> >
> > Alexis.
> >
>


-- 
? <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200903/92a3b9cf/attachment.htm>

From tva at fastmail.se  Thu Sep  3 15:58:39 2020
From: tva at fastmail.se (=?UTF-8?Q?=C3=96ppen?=)
Date: Thu, 03 Sep 2020 15:58:39 +0100
Subject: =?UTF-8?Q?Re:_New_Android_Client:_Tv=C3=A5?=
In-Reply-To: <CAEzvDCWb17rJwXX1xkom8q45HwDK2=9=i_shjTpVz1vfvnEhgA@mail.gmail.com>
References: <96923037-97de-4641-b650-4f9a1ab7442f@www.fastmail.com>
 <871rjj3in9.fsf@dorothy.carcosa.net> <87imcvwj3t.fsf@ada>
 <eb1098ab-1b18-4b51-8d93-6d1aaed0b729@www.fastmail.com>
 <CAEzvDCWb17rJwXX1xkom8q45HwDK2=9=i_shjTpVz1vfvnEhgA@mail.gmail.com>
Message-ID: <035a63c6-4908-4cc6-8f8d-770bceae641e@www.fastmail.com>

> Adding client certificates would be nice too, unless there's a system setting I'm missing

That'll come as it matures. It's currently still using a basic network class derived from another (abandoned I think) proof-of-concept Android project. 



On Thu, 3 Sep 2020, at 3:48 PM, A. E. Spencer-Reed wrote:
> Adding client certificates would be nice too, unless there's a system setting I'm missing.
> 
> On Thu, Sep 3, 2020 at 6:23 AM ?ppen <tva at fastmail.se> wrote:
> > Thanks both. 
> > 
> > Yes, light theme could do with a little attention. My device is permanently in dark mode so it's been neglected and light theme uses the Android defaults. 
> > 
> > Jason; someone else alerted me to the nested ``` issue just yesterday when some ascii art they had contained it. Simple fix will be in next release. 
> > 
> > Next beta will be sometime in next few days. Lot's of small bug fixes, and an in-app MP3 player (you click a file, it plays, you can carry on browsing). I've also removed tabs, they didn't help the browsing experience and were buggy anyway. If I have time I'll incorporate the GUS trackback service so you can easily see which pages link where. 
> > 
> > That'll be the last release for a while while I concentrate on something that is needed: bookmarks. 
> > 
> > I also need to check GUS for the most common filetypes and add support for those (even if they're just passed to the OS to handle (eg. .pdf)).
> > 
> > I'm also thinking about a future aggregation feature, I'll do some research before clogging up this list but I think it should be possible for clients to detect a Gemtext document with a series of dates in and offer a 'follow' button. I keep finding interesting Gemlogs then losing them again, bookmarks will help with that, but an aggregated timeline would be a fantastic feature (I know Solderpunk has done some work with Atom feeds for Gemini but if it feasible I like the zero setup approach). 
> > 
> > On Thu, 3 Sep 2020, at 5:59 AM, Alexis wrote:
> > > 
> > > Jason McBrayer <jmcbray at carcosa.net> writes:
> > > 
> > > > Hey, this looks really great, visually/design-wise ... The light 
> > > > theme is, IMO, a *little* low-contrast, though it looks nice.
> > > 
> > > Agreed on both points - i like the overall design, but currently 
> > > find the the light theme too low-contrast. At any rate, i 
> > > certainly appreciate the work so far!
> > > 
> > > A technical point which might already have been noted: the Gemini 
> > > speculative spec page is truncated for me. The heading "5.4.3 
> > > Preformatting toggle lines" is displayed, but the only text after 
> > > that is a preformatted block containing the text "Preformatting 
> > > toggle lines can be thought of as analogous to <pre> and </pre> 
> > > tags in HTML." i'm guessing this might be connected with the 
> > > presence of "```" in the first para of that section?
> > > 
> > > 
> > > Alexis.
> > >
> 
> 
> -- 
> ? <https://www.google.com/teapot>

From caranatar at riseup.net  Fri Sep  4 04:54:08 2020
From: caranatar at riseup.net (Caranatar)
Date: Thu, 03 Sep 2020 23:54:08 -0400
Subject: Gemini Archiving and WARC
In-Reply-To: <20200901220835.03259999@viridi>
References: <20200901194334.0cbc23e4@celehner.com>
 <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
 <20200901220835.03259999@viridi>
Message-ID: <875z8udwnz.fsf@riseup.net>

This seems like an incredibly cynical and myopic take. It's also
expected that everything on the internet will track you, will be
constantly expanded for the purpose of commercialization instead of user
experience, etc.... Yet Gemini purposefully rejects those notions in
favor of something better. The idea that the same shouldn't apply here
is odd.

-caranatar


Tom writes:

> On Wed, 02 Sep 2020 01:23:22 +0000
> acdw <acdw at acdw.net> wrote:
>
>> On 2020-09-01 (Tuesday) at 23:43, Charles E. Lehner
>> <cel at celehner.com> wrote:
>> 
>> > Hi Gemini List,
>> > 
>> > Has anyone thought about, or implemented, archiving of Gemini
>> > content/traffic?
>> > 
>> > WARC (Web ARChive)? is a standard format used for web archiving. It 
>> > uses text headers for metadata like in HTTP and email. It looks to
>> > me like WARC could be adapted for Gemini. The WARC spec supports
>> > multiple URI schemes, although it doesn't specify any other than
>> > http/https, ftp, and dns?. Bespoke formats could also be used, of
>> > course, or just downloading files wget-style, but using a standard
>> > format could allow for interop with "the WARC ecosystem"?.
>> > 
>> > Archive Team? has also worked on archiving non-HTTP protocols like
>> > FTP? and Gopher?.
>> > 
>> > I think there is an opportunity for people to maintain high-quality 
>> > archives of Gemini content, like what the Internet Archive? and 
>> > archive.today? do for the HTTP(S) Web. Now is a good time to start, 
>> > while many of the original Gemini hosts? are still online.
>> > 
>> > Regards,
>> > Charles E. Lehner
>> > 
>> > ? https://en.wikipedia.org/wiki/Web_ARChive
>> > ? 
>> > https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/#ftp-scheme
>> > ? https://www.archiveteam.org/index.php?title=The_WARC_Ecosystem
>> > ? https://www.archiveteam.org/
>> >   https://en.wikipedia.org/wiki/Archive_Team
>> > ? https://www.archiveteam.org/index.php?title=FTP
>> > ? https://www.archiveteam.org/index.php?title=Gopher
>> > ? https://en.wikipedia.org/wiki/Internet_Archive
>> >   https://archive.org/
>> > ? https://archive.today
>> >   https://en.wikipedia.org/wiki/Archive.today
>> > ? gemini://gemini.circumlunar.space/servers/
>> >  
>> 
>> I personally think this is a great idea, but I know some might not be
>> so on-board with it. I'm thinking of solderpunk's post (in their
>> gopherhole, actually):
>> gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/the-individual-archivist-and-ghosts-of-gophers-past.txt
>> 
>> So is there a way to opt-out of archiving for publishers? Some in the
>> community might want to know about it, though I personally am of the
>> opinion that if you've published it, it's now the property of the
>> commons.
>> 
>
> Ounce you publish something to the internet there is no retracting it.
> This is one of the first things I was taught the first time I used the
> net. Alongside never using your real name on the net unless your
> publishing something.


-- 
sent from emacs using mu4e

From sean at conman.org  Fri Sep  4 06:22:17 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 4 Sep 2020 01:22:17 -0400
Subject: Gemini Archiving and WARC
In-Reply-To: <875z8udwnz.fsf@riseup.net>
References: <20200901194334.0cbc23e4@celehner.com>
 <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
 <20200901220835.03259999@viridi> <875z8udwnz.fsf@riseup.net>
Message-ID: <20200904052216.GH15566@brevard.conman.org>

It was thus said that the Great Caranatar once stated:
> Tom writes:
> 
> > Ounce you publish something to the internet there is no retracting it.
> > This is one of the first things I was taught the first time I used the
> > net. Alongside never using your real name on the net unless your
> > publishing something.
>
> This seems like an incredibly cynical and myopic take. 

  I also think it's an incredibly realistic take.

> It's also
> expected that everything on the internet will track you, will be
> constantly expanded for the purpose of commercialization instead of user
> experience, etc.... Yet Gemini purposefully rejects those notions in
> favor of something better. The idea that the same shouldn't apply here
> is odd.

  Even though Gemini (and gopher to an extent) reject those ideas, it
doesn't mean privacy or control over the content.  I wrote about this last
year:

	http://boston.conman.org/2019/10/29.2
	gopher://gopher.conman.org/0Phlog:2019/10/29.2
	gemini://gemini.conman.org/boston/2019/10/29.2

(take your pick of format)

  I even quote the same solderpunk article (and another one not by
solderpunk) about how they're ... well ... "wrong" is the wrong word here,
but it's close ... perhaps "misguided" is what I'm thinking of.  Information
that is publically available (and by any measure, most of Gemini is public)
can, and will, travel in mysterious ways, which I discuss in my post above.

  I can find stuff I posted to USENET in 1993 *today*.  I can still find my
first website from 1997.

  -spc (I think I seriously just dated myself ... )

From drskrzyk at tilde.team  Fri Sep  4 06:23:21 2020
From: drskrzyk at tilde.team (Dr. Otto Skrzyk)
Date: Fri, 4 Sep 2020 00:23:21 -0500
Subject: Gemini Archiving and WARC
In-Reply-To: <875z8udwnz.fsf@riseup.net>
References: <20200901194334.0cbc23e4@celehner.com>
 <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
 <20200901220835.03259999@viridi> <875z8udwnz.fsf@riseup.net>
Message-ID: <20200904052312.GA12109@raspberrypi>

On Thu, Sep 03, 2020 at 11:54:08PM -0400, Caranatar wrote:
> This seems like an incredibly cynical and myopic take. It's also
> expected that everything on the internet will track you, will be
> constantly expanded for the purpose of commercialization instead of user
> experience, etc.... Yet Gemini purposefully rejects those notions in
> favor of something better. The idea that the same shouldn't apply here
> is odd.
> 
> -caranatar


Calling it myopic is a bit harsh and probably misses a point that you
put forward as a support - one of the selling points of gemini is that
it rejects complexity and some of the concerns of a more commercialized
internet. One of those concerns is the potential for misuse of the
information or infrastructure beyond the intent of the content creator
or host. That or the right to retract that information. 

You'll have to forgive me seeing some irony that someone with a
riseup.net email address would speak against someone putting forth advice
about taking caution in what you post on the internet. Riseup exists
largely in part because others share this "cynical and myopic take."

Regardless, the issues being brought up here seem to circle around
content control and archival ethics and less about the protocol. 
> 
> 
> Tom writes:
> 
> > On Wed, 02 Sep 2020 01:23:22 +0000
> > acdw <acdw at acdw.net> wrote:
> >
> >> On 2020-09-01 (Tuesday) at 23:43, Charles E. Lehner
> >> <cel at celehner.com> wrote:
> >> 
> >> > Hi Gemini List,
> >> > 
> >> > Has anyone thought about, or implemented, archiving of Gemini
> >> > content/traffic?
> >> > 
> >> > WARC (Web ARChive)? is a standard format used for web archiving. It 
> >> > uses text headers for metadata like in HTTP and email. It looks to
> >> > me like WARC could be adapted for Gemini. The WARC spec supports
> >> > multiple URI schemes, although it doesn't specify any other than
> >> > http/https, ftp, and dns?. Bespoke formats could also be used, of
> >> > course, or just downloading files wget-style, but using a standard
> >> > format could allow for interop with "the WARC ecosystem"?.
> >> > 
> >> > Archive Team? has also worked on archiving non-HTTP protocols like
> >> > FTP? and Gopher?.
> >> > 
> >> > I think there is an opportunity for people to maintain high-quality 
> >> > archives of Gemini content, like what the Internet Archive? and 
> >> > archive.today? do for the HTTP(S) Web. Now is a good time to start, 
> >> > while many of the original Gemini hosts? are still online.
> >> > 
> >> > Regards,
> >> > Charles E. Lehner
> >> > 
> >> > ? https://en.wikipedia.org/wiki/Web_ARChive
> >> > ? 
> >> > https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/#ftp-scheme
> >> > ? https://www.archiveteam.org/index.php?title=The_WARC_Ecosystem
> >> > ? https://www.archiveteam.org/
> >> >   https://en.wikipedia.org/wiki/Archive_Team
> >> > ? https://www.archiveteam.org/index.php?title=FTP
> >> > ? https://www.archiveteam.org/index.php?title=Gopher
> >> > ? https://en.wikipedia.org/wiki/Internet_Archive
> >> >   https://archive.org/
> >> > ? https://archive.today
> >> >   https://en.wikipedia.org/wiki/Archive.today
> >> > ? gemini://gemini.circumlunar.space/servers/
> >> >  
> >> 
> >> I personally think this is a great idea, but I know some might not be
> >> so on-board with it. I'm thinking of solderpunk's post (in their
> >> gopherhole, actually):
> >> gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/the-individual-archivist-and-ghosts-of-gophers-past.txt
> >> 
> >> So is there a way to opt-out of archiving for publishers? Some in the
> >> community might want to know about it, though I personally am of the
> >> opinion that if you've published it, it's now the property of the
> >> commons.
> >> 
> >
> > Ounce you publish something to the internet there is no retracting it.
> > This is one of the first things I was taught the first time I used the
> > net. Alongside never using your real name on the net unless your
> > publishing something.
> 
> 
> -- 
> sent from emacs using mu4e

-- 
      Dr . Otto Skrzyk
  gemini : gemini://tilde.team/~drskrzyk
     web : https://drskrzyk.tilde.team/
mastodon : @docskrzyk at hackers.town

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200904/947df2a1/attachment-0001.sig>

From luke at marmaladefoo.com  Fri Sep  4 12:47:22 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 04 Sep 2020 12:47:22 +0100
Subject: NQ2 or NQ3 or NGQ3
Message-ID: <5F52294A.4080300@marmaladefoo.com>

Hi All

I've been growing in affection for the term NQ2 (I think originally 
coined by acdw) as another way to refer to the virtual space that is the 
gemisphere/gemspace/geminispace/geminiverse/etc. And the wikipedia page 
for Gemini, says it is in NQ2.

https://en.wikipedia.org/wiki/Gemini_(constellation)

I was then curious to see what is the definition of a galactic quadrant 
which led me to the wikipedia page about those. And on that page, it 
shows Gemini being in NGQ3 (NGQ3 - North Galactic Quadrant 3), together 
with a diagram which seems to indicate it clearly.

https://en.wikipedia.org/wiki/Galactic_quadrant

https://en.wikipedia.org/wiki/Galactic_quadrant#/media/File:Galactic_quadrants.png

Could it be the shocking truth one of these pages on wikipedia is wrong? 
Also its not unknown for my understanding to be deeply flawed. I'm 
inclined to go with the page about galactic quadrants as it has a 
diagram, but to be honest if anyone has expertise in this area, it would 
be great to clear this up, so normal service can continue.

Best wishes

  - Luke

From acdw at acdw.net  Fri Sep  4 16:16:38 2020
From: acdw at acdw.net (acdw)
Date: Fri, 04 Sep 2020 15:16:38 +0000
Subject: NQ2 or NQ3 or NGQ3
In-Reply-To: <5F52294A.4080300@marmaladefoo.com>
References: <5F52294A.4080300@marmaladefoo.com>
Message-ID: <b5732858-fc71-451b-a986-e34dac4e8655@www.fastmail.com>

On 2020-09-04 (Friday) at 11:47, Luke Emmet <luke at marmaladefoo.com> wrote:

> Hi All
> 
> I've been growing in affection for the term NQ2 (I think originally 
> coined by acdw) as another way to refer to the virtual space that is the 
> gemisphere/gemspace/geminispace/geminiverse/etc. And the wikipedia page 
> for Gemini, says it is in NQ2.

Hey! I think it was me --- I'm glad others have found it a useful shorthand :)
> 
> https://en.wikipedia.org/wiki/Gemini_(constellation)
> 
> I was then curious to see what is the definition of a galactic quadrant 
> which led me to the wikipedia page about those. And on that page, it 
> shows Gemini being in NGQ3 (NGQ3 - North Galactic Quadrant 3), together 
> with a diagram which seems to indicate it clearly.
> 
> https://en.wikipedia.org/wiki/Galactic_quadrant
> 
> https://en.wikipedia.org/wiki/Galactic_quadrant#/media/File:Galactic_quadrants.png
> 
> Could it be the shocking truth one of these pages on wikipedia is wrong? 
> Also its not unknown for my understanding to be deeply flawed. I'm 
> inclined to go with the page about galactic quadrants as it has a 
> diagram, but to be honest if anyone has expertise in this area, it would 
> be great to clear this up, so normal service can continue.

I had no idea about this, and lo and behold you're right -- though, with more research, I *think* (the astonomical writings I'll put below are hard to figure out) that it's due to a difference in frames of reference.

Apparently, most astronomical observations are made from the "equatorial coordinates" -- which are extensions of the terrestrial equator out into space. I'm guessing "NQ2" refers to Gemini with that system.

However, "galactic coordinates" use the plane of the galaxy (mostly) as the equator, which means that from that perspective, things are in different quadrants -- I think in this system, Gemini is in NGQ3.

I personally like NQ2, since it's a character shorter. But if everyone starts calling it the NGQ3 (or NQ3), I'll hop on the bandwagon!

REFERENCES

https://www.astro.rug.nl/~sctrager/teaching/OA/PositionalAstronomy.pdf
^ a presentation that walks through the different coordinate systems

https://www.daviddarling.info/encyclopedia/C/coordinate.html
^ a webpage that explains the differences

https://heasarc.gsfc.nasa.gov/cgi-bin/Tools/convcoord/convcoord.pl?CoordVal=gemini&CoordType=J2000&Resolver=GRB%2FSIMBAD%2BSesame%2FNED&NoCache=on&Epoch=
^ a NASA tool that ... does something? This just looked cool. I have no idea how to read it.

https://en.wikipedia.org/wiki/Celestial_coordinate_system
^ Wikipedia page on celestial coordinate systems.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From acdw at acdw.net  Fri Sep  4 17:43:42 2020
From: acdw at acdw.net (acdw)
Date: Fri, 04 Sep 2020 16:43:42 +0000
Subject: Gemini Archiving and WARC
In-Reply-To: <20200904052312.GA12109@raspberrypi>
References: <20200901194334.0cbc23e4@celehner.com>
 <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
 <20200901220835.03259999@viridi> <875z8udwnz.fsf@riseup.net>
 <20200904052312.GA12109@raspberrypi>
Message-ID: <9c0bbd97-ff6f-41fd-82f9-5b46fae0ba8c@www.fastmail.com>

I agree 100% with Sean's post (http://boston.conman.org/2019/10/29.2) -- the act of posting something to a gemini *is* publishing, so it's out there -- toothpaste-tube-style. That being said, I think any archiver or spider should also respect *robots.txt* files -- though them being opt-in vs. opt-out is kind of moot, since spiders gonna spider, you know? It's the very nature of the Internet to communicate.

However, I thought Dr. Otto brought up a vv good point as well:

> Regardless, the issues being brought up here seem to circle around
> content control and archival ethics and less about the protocol. 

Inasmuch as gemini is a technical specification/machine protocol, I think there's nothing to say about it vis-a-vis archiving. Socially, though, we have norms -- which are good to nail down in a nascent community.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From b__m__e at mailfence.com  Fri Sep  4 19:43:10 2020
From: b__m__e at mailfence.com (Brian Evans)
Date: Fri, 4 Sep 2020 20:43:10 +0200 (CEST)
Subject: Gemini Archiving and WARC
Message-ID: <808287158.370726.1599244990071@ichabod.co-bxl>

acdw writes:
> I think any archiver or spider should also respect *robots.txt* files -- though them being opt-in vs. opt-out is kind of moot, since spiders gonna spider, you know?

I think opt-in vs opt-out is definitely not moot. The web largely operates on an opt out basis (where there is an option at all). We are at a point where we can develop different norms for a different system, and I think we should.

I definitely agree that there is nothing that can be down about spiders that do not follow recommended community guidelines and that when you post something that is not behind a client cert requirement or the like that it is public.

However, I do think that using robots.txt for spiders of all sorts is a bad idea for gemini and will create less user choice in the long run. robots.txt is suggested often because it exists and is there... but it is not designed for multi-user systems (the predominant form of system on gemini at present) and is explicitly designed to opt you out... meaning that if users dont even know that spiders are a thing (as many non-technical people do not) then they do not get to have a choice. My suggestion as simply about community norms and trying to push, at least for spiders that are willing to respect a community standard, an opt in that works at the directory level and can be managed by users rather than by system administrators. The idea being that if someone does not have a document, lets call it `green-light.txt`, saying yes to various sorts of spidering that a well behaved spider should ignore content in that directory.

Having said all of that: I agree this is not a protocol issue and the conversation and is more about philosophical/ethical preferences and could be moved over to gemini posts rather than here on the mailing list. So I will likely not post more on it here... but maybe I'll write something up on my gemlog tonight.

From tgrom.automail at nuegia.net  Fri Sep  4 20:45:56 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Fri, 4 Sep 2020 12:45:56 -0700
Subject: Gemini Archiving and WARC
In-Reply-To: <9c0bbd97-ff6f-41fd-82f9-5b46fae0ba8c@www.fastmail.com>
References: <20200901194334.0cbc23e4@celehner.com>
 <3122f9e0-0a32-4095-87bc-7062cbce7323@www.fastmail.com>
 <20200901220835.03259999@viridi> <875z8udwnz.fsf@riseup.net>
 <20200904052312.GA12109@raspberrypi>
 <9c0bbd97-ff6f-41fd-82f9-5b46fae0ba8c@www.fastmail.com>
Message-ID: <20200904124556.7cb4eff2@viridi>

On Fri, 04 Sep 2020 16:43:42 +0000
acdw <acdw at acdw.net> wrote:

I want to clarify something. What I said does not purely revolve around
inevitable misuse of the data. It is also based on freedom of the user.
The only way you could prevent the user from doing something on his own
machine ounce the data has been copied over the net is with some kind
of rookit and spyware under the umbrella term Digital Restrictions
Management. I Hope we can all agree that DRM is heinous and a key point
in the downfall of the web. https://www.defectivebydesign.org/

The most you could do is ask someone not to unlist their
archive for some TTL period. I feel this would be a good compromise
between archivist and authors. Archivists are going to archive because
without an immutable content addressable storage back-end like IPFS or
the LoC ARC Resolver everything is fickle and could disappear at any
moment, lost to entropy.

-- 
 ________________________________________ 
/ telepression, n.:                      \
|                                        |
| The deep-seated guilt which stems from |
| knowing that you did not try           |
|                                        |
| hard enough to look up the number on   |
| your own and instead put the           |
|                                        |
| burden on the directory assistant.     |
|                                        |
\ -- "Sniglets", Rich Hall & Friends     /
 ---------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

From meff at meff.me  Fri Sep  4 22:14:28 2020
From: meff at meff.me (Koushik Roy)
Date: Fri, 04 Sep 2020 14:14:28 -0700
Subject: NQ2 or NQ3 or NGQ3
In-Reply-To: <b5732858-fc71-451b-a986-e34dac4e8655@www.fastmail.com>
Message-ID: <87o8mlz1l7.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

A non-text attachment was scrubbed...
Name: not available
Type: text/plain
 i think it's more "obvious" to the reader if words like "gemspace",
 "geminisphere", or whatnot are used. nq2 at first glance doesn't
 seem like it has anything to do with the protocol, and not all of
 us are particularly astronomically inclined. - meff
Size: 2784 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200904/58bceffd/attachment-0001.bin>

From dealpete at fastmail.com  Fri Sep  4 22:46:42 2020
From: dealpete at fastmail.com (Peter Deal)
Date: Fri, 4 Sep 2020 19:16:42 -0230
Subject: Right to be Forgotten and archiving
Message-ID: <25EABBBA-3F53-4E33-ACF4-F9F3A165EC0D@fastmail.com>

Hello Geminauts,

This is my first post here but I have been lurking for awhile.

The thread about archiving led me just now to read about the Right to be Forgotten for the first time. It?s not something that I?ve ever heard anyone talk about in Canada, didn?t realize it was an active controversy in Europe. It raises interesting questions - is it possible to take information off the internet? Is it effectively gone for most people when you remove it from Google? What is more important - the value of the public in knowing what happened, or the value to the individual in getting on with his life after making a mistake?

For Gemini protocol, I feel like if it becomes important enough to people, an archive is likely to be created whether we want it or not. There?s probably some value in the community itself proactively creating a sanctioned archive itself that respects creators? reasonable desires to have their content taken offline on demand.

Regards,
Peter

From cblte at envs.net  Sat Sep  5 14:32:10 2020
From: cblte at envs.net (cblte)
Date: Sat, 5 Sep 2020 15:32:10 +0200
Subject: Right to be Forgotten and archiving
In-Reply-To: <25EABBBA-3F53-4E33-ACF4-F9F3A165EC0D@fastmail.com>
References: <25EABBBA-3F53-4E33-ACF4-F9F3A165EC0D@fastmail.com>
Message-ID: <5ab4d884-6274-cfdb-2735-ec4355ac8780@envs.net>

Am 04.09.20 um 23:46 schrieb Peter Deal:
> Hello Geminauts,
>
> This is my first post here but I have been lurking for awhile.
>
> The thread about archiving led me just now to read about the Right to be Forgotten for the first time. It?s not something that I?ve ever heard anyone talk about in Canada, didn?t realize it was an active controversy in Europe. It raises interesting questions - is it possible to take information off the internet? Is it effectively gone for most people when you remove it from Google? What is more important - the value of the public in knowing what happened, or the value to the individual in getting on with his life after making a mistake?
>
> For Gemini protocol, I feel like if it becomes important enough to people, an archive is likely to be created whether we want it or not. There?s probably some value in the community itself proactively creating a sanctioned archive itself that respects creators? reasonable desires to have their content taken offline on demand.
>
> Regards,
> Peter

Hello Everyone, 
the right to be forgotten is something we here in Germany are discussing for quite some time. 
There is a semigood wikipedia article about it here https://en.wikipedia.org/wiki/Right_to_be_forgotten

Personally I think, if you put it up online visible to everyone, there is a chance, that someone will
take your content and save it. Either for himself or for others. You can not protect that other than
handing out passwords to people who want to read your content. But then it makes not much sense to put 
it up and online. Then you could also send it via email. 

I personally like the idea of an internet archive. Respecting the copyright. But if you give your copyright 
away by posting something unter a CC licencse or similiar, then you give away your content which could 
then be archived. 

-- Carsten

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200905/450b73dd/attachment.htm>

From luke at marmaladefoo.com  Sat Sep  5 16:17:22 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 05 Sep 2020 16:17:22 +0100
Subject: NQ2 or NQ3 or NGQ3
In-Reply-To: <b5732858-fc71-451b-a986-e34dac4e8655@www.fastmail.com>
References: <5F52294A.4080300@marmaladefoo.com>
 <b5732858-fc71-451b-a986-e34dac4e8655@www.fastmail.com>
Message-ID: <5F53AC02.6060103@marmaladefoo.com>

On 04-Sep-2020 16:16, acdw wrote:
> On 2020-09-04 (Friday) at 11:47, Luke Emmet<luke at marmaladefoo.com>  wrote:
>> https://en.wikipedia.org/wiki/Galactic_quadrant#/media/File:Galactic_quadrants.png
>>
>> Could it be the shocking truth one of these pages on wikipedia is wrong?
>> Also its not unknown for my understanding to be deeply flawed. I'm
>> inclined to go with the page about galactic quadrants as it has a
>> diagram, but to be honest if anyone has expertise in this area, it would
>> be great to clear this up, so normal service can continue.
> I had no idea about this, and lo and behold you're right -- though, with more research, I *think* (the astonomical writings I'll put below are hard to figure out) that it's due to a difference in frames of reference.
>
> Apparently, most astronomical observations are made from the "equatorial coordinates" -- which are extensions of the terrestrial equator out into space. I'm guessing "NQ2" refers to Gemini with that system.
>
> However, "galactic coordinates" use the plane of the galaxy (mostly) as the equator, which means that from that perspective, things are in different quadrants -- I think in this system, Gemini is in NGQ3.

Yes you're right there are different reference systems, so coordinates 
will vary accordingly. What I couldn't get from those links is anything 
to resolve the naming question or whether a constellation could be both 
in quadrants named both "NQ2" and "NGQ3" in different schemes.

In 50 years time the historians will wonder why there was a fundamental 
naming quirk within the hypertext system that replaced the web. No one 
will know about the wikipedia pages and the naming convention will 
become re-mythologised to take on other cultural symbolism.

Or maybe not.

  - L



From tgrom.automail at nuegia.net  Sat Sep  5 22:47:50 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Sat, 5 Sep 2020 14:47:50 -0700
Subject: Right to be Forgotten and archiving
In-Reply-To: <5ab4d884-6274-cfdb-2735-ec4355ac8780@envs.net>
References: <25EABBBA-3F53-4E33-ACF4-F9F3A165EC0D@fastmail.com>
 <5ab4d884-6274-cfdb-2735-ec4355ac8780@envs.net>
Message-ID: <20200905144750.061e4706@viridi>

On Sat, 5 Sep 2020 15:32:10 +0200
cblte <cblte at envs.net> wrote:

> Am 04.09.20 um 23:46 schrieb Peter Deal:
> > Hello Geminauts,
> >
> > This is my first post here but I have been lurking for awhile.
> >
> > The thread about archiving led me just now to read about the Right
> > to be Forgotten for the first time. It?s not something that I?ve
> > ever heard anyone talk about in Canada, didn?t realize it was an
> > active controversy in Europe. It raises interesting questions - is
> > it possible to take information off the internet? Is it effectively
> > gone for most people when you remove it from Google? What is more
> > important - the value of the public in knowing what happened, or
> > the value to the individual in getting on with his life after
> > making a mistake?
> >
> > For Gemini protocol, I feel like if it becomes important enough to
> > people, an archive is likely to be created whether we want it or
> > not. There?s probably some value in the community itself
> > proactively creating a sanctioned archive itself that respects
> > creators? reasonable desires to have their content taken offline on
> > demand.
> >
> > Regards,
> > Peter  
> 
> Hello Everyone, 
> the right to be forgotten is something we here in Germany are
> discussing for quite some time. There is a semigood wikipedia article
> about it here https://en.wikipedia.org/wiki/Right_to_be_forgotten
> 
> Personally I think, if you put it up online visible to everyone,
> there is a chance, that someone will take your content and save it.
> Either for himself or for others. You can not protect that other than
> handing out passwords to people who want to read your content. But
> then it makes not much sense to put it up and online. Then you could
> also send it via email. 
> 
> I personally like the idea of an internet archive. Respecting the
> copyright. But if you give your copyright away by posting something
> unter a CC licencse or similiar, then you give away your content
> which could then be archived. 
> 
> -- Carsten
> 

I strongly disagree. In the beginning of the web it was largely Open
Content as described here: http://www.opencontent.org/ . All work is
derivative work. People who make actual websites, not scrape together
random half-broken crap from stack overflow and wordpress plugins
surfed the web, saw something they liked, looked at the source and
added it to their own site.

Copyright, or more specifically Intellectual property is a completely
broken system and one that does not apply to cyberspace. All it serves
to do is prop up broken business models, justify censorship and spyware
in the name of saving reality a few reality tv shows.

The fundamental difference between meatspace and cyberspace is that
copying something is free in cyberspace. It takes effort to reproduce a
physical book. It does not cost anything at all to copy a digital book
or other digital work.

Intellectual Property law works on creating artificial scarcity. An
economy based on artificial scarcity is not a sustainable one. Nor
should we be designing technical specifications around something as
flimsy as that.

I would highly encourage you to watch Cory Doctorow's speech "The
coming war on general computation" as he explores these ideas in depth.
http://mirror.fem-net.de/CCC/28C3/mp4-h264-HQ/28c3-4848-en-the_coming_war_on_general_computation_h264.mp4

Any attempts to incorporate copyright into technical systems ultimately
leads to rootkits and malware. aka 'trusted computing/DRM'. As
engineers please try to understand the full ramifications of this. We
already live in an age where all post 9/11 CPUs manufactured by Intel
come with mandatory backdoors/hardware spyware implants you can't turn
off called Intel Management Engine. They implement a DRM called PAVP
(Protected Audio Video Path). It's wired directly into your onboard
Intel network interface and has hypervisor level access to all system
memory.

There are other ways to financially back projects. We live in the age
of self-publishing. A giant printing press is no longer required to get
your word out. The backing of a giant publishing corporation is no
longer required. We live in an age where individuals, not groups are
the primary producers of artistic goods. The thing we want to
incentive is the creation of these goods not the reproduction of
already existing goods. As the initial production is the costly part.
This is where business models like Patreon comes in. Now I'm not saying
Patreon themselves are good, but the business model here is that of
other individuals who like some content are able to directly fund the
creation of more of said content. No matter how niche that content may
be.

-- 
 ________________________________________ 
/ The other day I... uh, no, that wasn't \
| me.                                    |
|                                        |
\ -- Steven Wright                       /
 ---------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

From mbays at sdf.org  Sun Sep  6 09:48:32 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Sun, 6 Sep 2020 10:48:32 +0200
Subject: [ANN] diohsc-0.1.1
Message-ID: <20200906084832.gwdmvkcwx47ckr32@localhost>

This is the first actual release of my line-based terminal haskell 
client diohsc.

It's developed somewhat since my initial announcement here a few months 
ago. It now aims to be a "maximal-minimal" client: it has many features, 
but each is implemented in a simple way. It also aims to play nicely as 
part of the commandline ecosystem: it outputs no terminal escape codes 
which could interfere with the terminal's scrollback, can be scripted 
(using -f), behaves well in a pipeline, and offers many ways to call and 
pipe data to shell commands. It is quite configurable.

=> gemini://gemini.thegonz.net/diohsc/
=> https://mbays.sdf.org/diohsc/

The package now exists on hackage, which means you can install it once 
you have the cabal-install package with
```
cabal update && cabal install diohsc
```
Please let me know if that doesn't work for you.

I put together a little "asciicast" tutorial to demonstrate basic 
features, which you can find at the above links.

For Windows users: It is reportedly possible to compile and run diohsc 
on Windows, but Windows support is an afterthought and probably doesn't 
work very well.

For MetaARPA sdf users: It's installed as /meta/sdf/bin/diohsc on mab 
(there's an unresolved ghc bug which stops it working on the cluster for 
now).

Comments and suggestions welcome!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200906/97f8c3a2/attachment.sig>

From henderson.j at protonmail.com  Sun Sep  6 22:15:10 2020
From: henderson.j at protonmail.com (James Henderson)
Date: Sun, 06 Sep 2020 21:15:10 +0000
Subject: Feed format for gemini (alternative to rss feed)
Message-ID: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>

Hello everyone,

As content starts growing on gemini there may be cause for an rss style feed for the platform.

rss is fine but it?s fairly verbose and Allows for things like embedding images and the like which don?t seem to fit well with gemini.
My proposal is a simpler format where each line in a file is an item in a feed with fields separated by three colons and the line ending \r\n.
The four fields would be date, link, title, text description e.g.

yyyy/mm/dd ::: link_to_article ::: title ::: text describing the content \r\n

A format like this is easily parsed and displayed in a client. If the gemini protocol defines a mime type for it in the standard it would be easily recognised.

I am just throwing the idea out there, what do people think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200906/0dfdcd7d/attachment.htm>

From ranfdev at gmail.com  Sun Sep  6 23:43:26 2020
From: ranfdev at gmail.com (Ranf Dev)
Date: Mon, 7 Sep 2020 00:43:26 +0200
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
References: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
Message-ID: <CAMXq4zphiHd=5adwG9UacCW+1UuvCLmoiPmJhEx8uGpGA8ZtyA@mail.gmail.com>

Hello, It's the first time I post here, but I've been following the gemini
protocol for some time already, because I'm implementing a graphical
client, which I will release in some days...
Anyway:
I don't think we really need a new feed format.
Instead, I think we could add a paragraph to the Gemini best practices
page, describing some set of rules a Gemini feed should follow.
Using the usual Gemini syntax
```
=> link1 yyyy-mm-dd title1
Description1...
=> link2 yyyy-mm-dd title2
Description2...
```
This format is similar to what spacewalk and the capcom aggregator are
already using.
The description can't contain any link, but I think simple text is enough
for a little descriptive paragraph. You can always get the full article by
clicking at the link.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/13cbe07d/attachment.htm>

From luke at marmaladefoo.com  Mon Sep  7 00:20:48 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 07 Sep 2020 00:20:48 +0100
Subject: A proposed scheme for parsing preformatted alt text
Message-ID: <5F556ED0.4060504@marmaladefoo.com>

Hi All

We had an interesting discussion on the #Gemini IRC channel earlier 
today about a generalised scheme for parsing the alt text on 
preformatted regions, e.g.

```this is the alt text, not normally displayed to the end user
the preformatted content
```

It was a collective discussion, but I've written up some of the key 
points in a post here:

gemini://gemini.marmaladefoo.com/blog/7-Sep-2020_Parsing_preformatted_alt_text.gmi

Essentially the key design considerations are as follows:

1. By default the whole alt text can be used as a label (current behaviour)
2. Use CSS style syntax for the remainder, a familiar and low ritual syntax
3. Don't prescribe the attributes, allow practice to suggest them
4. Be backwards compatible and friendly to screen readers etc.

two initial attributes seem to have obvious initial utility and could be 
used to effectively label content in a practical way:

content-type
lang

Best Wishes

  - Luke

From sean at conman.org  Mon Sep  7 01:47:47 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 6 Sep 2020 20:47:47 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F556ED0.4060504@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
Message-ID: <20200907004747.GI15566@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
> Hi All
> 
> We had an interesting discussion on the #Gemini IRC channel earlier 
> today about a generalised scheme for parsing the alt text on 
> preformatted regions, e.g.
> 
> ```this is the alt text, not normally displayed to the end user
> the preformatted content
> ```
> 
> It was a collective discussion, but I've written up some of the key 
> points in a post here:
> 
> gemini://gemini.marmaladefoo.com/blog/7-Sep-2020_Parsing_preformatted_alt_text.gmi
> 
> Essentially the key design considerations are as follows:
> 
> 1. By default the whole alt text can be used as a label (current behaviour)
> 2. Use CSS style syntax for the remainder, a familiar and low ritual syntax

  I read the article linked, and I think a better format would be:

``` mumble mumble label text mumble; attribute1=value1; attribute2=value2

  Skip the CSS rules since they aren't used in Gemini, but the attributes
for MIME *are* used, and those use the format I've shown above.  If you can
parse MIME types, you can reuse *that* code to parse attributes.

```here is a table in CSV; content-type=text/csv; lang=en_US;

  The format for tables is *horrible* (at least in my opinion).  The format
I use to generate tables (ultimately in HTML) is the following:

*header1	header2	header3	header4
**footer1	footer2	footer3	footer4
row-11	row-12	row-13	row-14
row-21	row-22	row-23	row-24

  Basically, it's a TAB-delimeted text, so there's no worry about escaping
commas or dealing with quoted strings or any such nonsense.  I know, tabs
are horrible, don't ever use them, etc. etc. but it's *way* easier to deal
with tabs than just about any other character (short of the field separator
control characters).

  So your table example:

```Here is a table; content-type=text/tsv; lang=en
*+	1	2	3
1	2	3	4
2	3	4	5
3	4	5	6
```

  (Yeah, way eaiser to type than '|' between each field)

> 3. Don't prescribe the attributes, allow practice to suggest them
> 4. Be backwards compatible and friendly to screen readers etc.
> 
> two initial attributes seem to have obvious initial utility and could be 
> used to effectively label content in a practical way:
> 
> content-type
> lang

  Just my two zorkmids worth.  I don't really have a horse in this race, as
I don't really care for the current gemini text format anyway, and this is
adding complexity to a simple format, but that is solerpunk's call, not
mine.

  -spc


From mailinglists at ngalt.com  Mon Sep  7 01:53:45 2020
From: mailinglists at ngalt.com (mailinglists at ngalt.com)
Date: Sun, 06 Sep 2020 17:53:45 -0700
Subject: For consideration: JSON Feed
Message-ID: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>

I've been seeing people talk about syndication formats how we'd like something a little less annoying than RSS and Atom.

I'd like to suggest JSON Feed as a possible alternative:

https://jsonfeed.org/

Here's the Simple Example from the 1.1 version of the spec:

{
    "version": "https://jsonfeed.org/version/1.1",
    "title": "My Example Feed",
    "home_page_url": "https://example.org/",
    "feed_url": "https://example.org/feed.json",
    "items": [
        {
            "id": "2",
            "content_text": "This is a second item.",
            "url": "https://example.org/second-item"
        },
        {
            "id": "1",
            "content_html": "<p>Hello, world!</p>",
            "url": "https://example.org/initial-post"
        }
    ]
}

Obviously, we generally wouldn't use content_html. We could either use `content_text` or, if we're feeling particularly insular, `_gemini_text` (see the Extensions section of the spec)

Extensions: https://jsonfeed.org/version/1.1#extensions-a-name-extensions-a

I have a hunch that most people here, if not everyone, would prefer a strictly line-based format, but I wanted to suggest this, if only to be sure that we generally _don't_ want something like this.

From easeout at tilde.team  Mon Sep  7 03:30:17 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Sun, 6 Sep 2020 22:30:17 -0400
Subject: For consideration: JSON Feed
In-Reply-To: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
Message-ID: <20200907023017.GC2239112@tilde.team>

On Sun, Sep 06, 2020 at 05:53:45PM -0700, mailinglists at ngalt.com wrote:
> I've been seeing people talk about syndication formats how we'd like something a little less annoying than RSS and Atom.
> 
> I'd like to suggest JSON Feed as a possible alternative:
> 
> https://jsonfeed.org/

JSON Feed has a healthy amount of acceptance in the syndication space? enough acceptance to satisfy me, that is. And besides RSS, Atom, and JSON Feed, I don't know of any other common syndication formats at all! So I'm assuming there are no well-accepted syndication formats that are line-oriented. Given that, I don't think we need to invent a new syndication format. JSON feed is simple enough:

For a publisher, JSON feed should be easier to write than RSS or Atom, but not by a wide margin. If you're just filling out a text template, it may not make much of a difference to you. I maintain a tool that produces Atom feeds for Gemini blogs, and I would be happy to produce a JSON Feed as well.

For a consumer, the difference is probably bigger. I expect JSON Feed to be substantially easier to parse than RSS or Atom. Basic JSON parsing utilities are pervasive and usually just produce an object. The last time I did XML parsing, it was much more complex and involved responding to callbacks during an XML tree walk job.

So, I would like the consumers of feeds (CAPCOM and Spacewalk to name two) to give opinions about what feed format should be our de facto standard. I imagine it makes the most difference to them. But I'm inclined to think JSON Feed would be best. After all it might make me more likely to create a feed-consuming tool than if the standard was XML.

> Obviously, we generally wouldn't use content_html. We could either use `content_text` or, if we're feeling particularly insular, `_gemini_text` (see the Extensions section of the spec)

Using content_text sounds fine to me, but I don't know the spec well enough to make a call.

From cblte at envs.net  Mon Sep  7 08:36:27 2020
From: cblte at envs.net (cblte)
Date: Mon, 7 Sep 2020 09:36:27 +0200
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
References: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
Message-ID: <c008ea15-dcba-11cc-a2c9-f816dafa83a0@envs.net>

Am 06.09.20 um 23:15 schrieb James Henderson:
> Hello everyone,
>
> As content starts growing on gemini there may be cause for an rss 
> style feed for the platform.
>
> rss is fine but it?s fairly verbose and Allows for things like 
> embedding images and the like which don?t seem to fit well with gemini.
>
> My proposal is a simpler format where each line in a file is an item 
> in a feed with fields separated by three colons and the line ending \r\n.
> The four fields would be date, link, title, text description e.g.
>
> yyyy/mm/dd ::: link_to_article ::: title ::: text describing the 
> content \r\n
>
> A format like this is easily parsed and displayed in a client. If the 
> gemini protocol defines a mime type for it in the standard it would be 
> easily recognised.
>
> I am just throwing the idea out there, what do people think?
>
Good Morning,

I like your idea of simplicity, but what about a simple csv file?

A simple comma-seperated-file, working now for years in a a lot of 
situations and proven to bo in exchanging lots of data. Nothing new has 
to bb implemented. Libraries for writing csv files are existing for 
almost if not for every programming out there.

Why implementing something new?

--Carsten

From henderson.j at protonmail.com  Mon Sep  7 08:49:51 2020
From: henderson.j at protonmail.com (James Henderson)
Date: Mon, 07 Sep 2020 07:49:51 +0000
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <c008ea15-dcba-11cc-a2c9-f816dafa83a0@envs.net>
References: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
 <c008ea15-dcba-11cc-a2c9-f816dafa83a0@envs.net>
Message-ID: <N_nBid1Hb0eLC-pftynUo2ocRTEZOejGrJ4jtYYSePKqhbMUu7X9Z7qZcJuGZY7FAkDK2oaWfBwVcsfcGpN7Nm2daxt-czorL2LODDJs1_w=@protonmail.com>

The reason I went for non csv in this is that people might want to use commas in the description or title.

This can be solved by enclosing strings in quotations but then if people want to include quotations in their strings they need to be escaped.

The idea behind using ::: is that its rare enough to never really show up and therefore makes a fairly solid delimiter. It also makes manually writing a feed file easier because commas quotes and escapes are not a concern at all.

Basically its just more simple and clean, in my mind anyway.

On Mon, Sep 7, 2020 at 08:36, cblte <cblte at envs.net> wrote:

> Am 06.09.20 um 23:15 schrieb James Henderson:
>> Hello everyone,
>>
>> As content starts growing on gemini there may be cause for an rss
>> style feed for the platform.
>>
>> rss is fine but it?s fairly verbose and Allows for things like
>> embedding images and the like which don?t seem to fit well with gemini.
>>
>> My proposal is a simpler format where each line in a file is an item
>> in a feed with fields separated by three colons and the line ending \r\n.
>> The four fields would be date, link, title, text description e.g.
>>
>> yyyy/mm/dd ::: link_to_article ::: title ::: text describing the
>> content \r\n
>>
>> A format like this is easily parsed and displayed in a client. If the
>> gemini protocol defines a mime type for it in the standard it would be
>> easily recognised.
>>
>> I am just throwing the idea out there, what do people think?
>>
> Good Morning,
>
> I like your idea of simplicity, but what about a simple csv file?
>
> A simple comma-seperated-file, working now for years in a a lot of
> situations and proven to bo in exchanging lots of data. Nothing new has
> to bb implemented. Libraries for writing csv files are existing for
> almost if not for every programming out there.
>
> Why implementing something new?
>
> --Carsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/36654913/attachment.htm>

From meff at meff.me  Mon Sep  7 09:32:23 2020
From: meff at meff.me (Meff)
Date: Mon, 07 Sep 2020 01:32:23 -0700
Subject: For consideration: JSON Feed
In-Reply-To: <20200907023017.GC2239112@tilde.team>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team>
Message-ID: <871rjeyoko.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

easeout at tilde.team writes:

> So, I would like the consumers of feeds (CAPCOM and Spacewalk to name
> two) to give opinions about what feed format should be our de facto
> standard. I imagine it makes the most difference to them. But I'm
> inclined to think JSON Feed would be best. After all it might make me
> more likely to create a feed-consuming tool than if the standard was
> XML.

I've been grabbing feeds, running a script to rewrite Gemini URLs to a
URL that points to a local Gemini proxy, and then use that to get feeds
in my feed reader. I like using RSS because it's one less wheel to
reinvent. I might be in the minority of hand-rolled users though.
>

- meff

From kevin at susa.net  Mon Sep  7 10:06:23 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 7 Sep 2020 10:06:23 +0100
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F556ED0.4060504@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
Message-ID: <CAPk6LxSDu6X0ES8aEXo89L6_O17HeigO8b1BJeQ6rvg7EdYWXQ@mail.gmail.com>

Since my services have been retained by the Devil himself, I am obliged to
advocate on his behalf as follows:

Anything that adds text that's really only parseable by a machine is just a
teeny bit user-hostile.

The ideas being discussed go further, because (unless I misunderstand) it
encourages text in weird unaligned formats to be served up by default.

I would argue (on behalf of the Devil, of course) that mono-spaced
preformatted text is already perfect for aligning user-readable tables.
It's just awkward for machines to process semantically. There are however
reasonably reliable heuristics to figure out columns, should the client
want to add decoration. etc.

Perhaps the alt-text could be used to specify something like 'source:
/data/my_original.csv', to give a person-readable route to machine-readable
data that the client could use to fetch and render in-place on behalf of
the user.

Kevin

On Mon, 7 Sep 2020 at 00:21, Luke Emmet <luke at marmaladefoo.com> wrote:

> Hi All
>
> We had an interesting discussion on the #Gemini IRC channel earlier
> today about a generalised scheme for parsing the alt text on
> preformatted regions, e.g.
>
> ```this is the alt text, not normally displayed to the end user
> the preformatted content
> ```
>
> It was a collective discussion, but I've written up some of the key
> points in a post here:
>
> gemini://
> gemini.marmaladefoo.com/blog/7-Sep-2020_Parsing_preformatted_alt_text.gmi
>
> Essentially the key design considerations are as follows:
>
> 1. By default the whole alt text can be used as a label (current behaviour)
> 2. Use CSS style syntax for the remainder, a familiar and low ritual syntax
> 3. Don't prescribe the attributes, allow practice to suggest them
> 4. Be backwards compatible and friendly to screen readers etc.
>
> two initial attributes seem to have obvious initial utility and could be
> used to effectively label content in a practical way:
>
> content-type
> lang
>
> Best Wishes
>
>   - Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/073f5115/attachment.htm>

From Paul.Kosel at ruhr-uni-bochum.de  Mon Sep  7 14:50:41 2020
From: Paul.Kosel at ruhr-uni-bochum.de (Paul Kosel)
Date: Mon, 07 Sep 2020 15:50:41 +0200
Subject: Announcing gemini.wtf
Message-ID: <2ea547b96d47e5e84e52ef5d50461179@ruhr-uni-bochum.de>

Greetings Geminauts!

After putting some more work into my Prolog Gemini server I am happy to 
announce that I now have a working capsule running over at 
gemini://gemini.wtf.

This capsule also provides simple Gemtext hosting capabilities to 
everyone who's interested. The intention is to give anyone access to it 
tilde-style and the Prolog app serves whatever is inside the `public` 
directory in your home. Currently it only correctly serves .gmi files 
but if anyone is interested in making use of this and wants to serve 
content other than gemtext I'm happy to add more mime/extension 
mappings. Note that every user gets full SSH access to the box so you 
could set up cronjobs etc. It defaults to bash as shell for new users 
but again on request I can make other stuff available too. Same goes for 
scripting languages. There's the Ubuntu defaults like (ba)sh, perl, etc, 
but also SWI Prolog. Although it is missing other popular things like 
Python right now.

If anyone wants to get hooked up with an account all I need is your 
desired username and your public SSH key.

Have a nice day/evening/night,

~Paul Kosel

From easrng at gmail.com  Mon Sep  7 14:51:52 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Mon, 7 Sep 2020 09:51:52 -0400
Subject: For consideration: JSON Feed
In-Reply-To: <871rjeyoko.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team>
 <871rjeyoko.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <CAEzvDCUT9tqUsQk1znw=T1bw7xXYNfQsX_+r3HeU3TOjeRNvgw@mail.gmail.com>

I also like JSON Feed especially how easy it is to parse, but also it has
official easy to read docs, something that Atom and especially RSS seem to
lack. Re: other feed formats, there's also indieweb's h-feed, but that is
not applicable here.

On Mon, Sep 7, 2020, 4:32 AM Meff <meff at meff.me> wrote:

> easeout at tilde.team writes:
>
> > So, I would like the consumers of feeds (CAPCOM and Spacewalk to name
> > two) to give opinions about what feed format should be our de facto
> > standard. I imagine it makes the most difference to them. But I'm
> > inclined to think JSON Feed would be best. After all it might make me
> > more likely to create a feed-consuming tool than if the standard was
> > XML.
>
> I've been grabbing feeds, running a script to rewrite Gemini URLs to a
> URL that points to a local Gemini proxy, and then use that to get feeds
> in my feed reader. I like using RSS because it's one less wheel to
> reinvent. I might be in the minority of hand-rolled users though.
> >
>
> - meff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/afee8935/attachment.htm>

From dealpete at fastmail.com  Mon Sep  7 16:22:57 2020
From: dealpete at fastmail.com (Peter Deal)
Date: Mon, 7 Sep 2020 12:52:57 -0230
Subject: Labyrinth II
Message-ID: <5A1AAE4E-396B-4614-B0FF-6A6E72BCCA3C@fastmail.com>

Hi otrn,

I really like what you did with the ASCII art on Labyrinth II. I wonder if you could do something with client certificates to save the player?s state throughout the maze. I would be great to find a key in one room, and use it to open one of the doors.

Peter

From prisonpotato at tilde.team  Mon Sep  7 17:17:07 2020
From: prisonpotato at tilde.team (prisonpotato at tilde.team)
Date: Mon, 07 Sep 2020 16:17:07 +0000
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <mailman.1.1599476430.14074.gemini@lists.orbitalfox.eu>
References: <mailman.1.1599476430.14074.gemini@lists.orbitalfox.eu>
Message-ID: <da5239674d446986ee4bb0604ae1dfb2@tilde.team>

> The reason I went for non csv in this is that people might want to use commas in the description or
> title.
> 
> This can be solved by enclosing strings in quotations but then if people want to include quotations
> in their strings they need to be escaped.
> 
> The idea behind using ::: is that its rare enough to never really show up and therefore makes a
> fairly solid delimiter. It also makes manually writing a feed file easier because commas quotes and
> escapes are not a concern at all.
> 
> Basically its just more simple and clean, in my mind anyway.

Just my 2 cents -- I do like the idea of a line based format for this.
Maybe something even simpler, building on the idea of previous
proposals:

=> link1 date1 name1
=> link2 date2 name2
=> link3 date3 name3

Where link is a absolute gemini link, date is an ISO-8601 date,
and name is the human readable name of the article.  For example:

=> gemini://foo.bar/glog/1 2020-01-01 Happy New Years!

This way you get a valid gemini document that you can display to
humans without any changes, or you can parse it fairly easily.  So
you could mix two feeds together and keep them sorted by date, etc.

From luke at marmaladefoo.com  Mon Sep  7 17:28:14 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 07 Sep 2020 17:28:14 +0100
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200907004747.GI15566@brevard.conman.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907004747.GI15566@brevard.conman.org>
Message-ID: <5F565F9E.30701@marmaladefoo.com>


On 07-Sep-2020 01:47, Sean Conner wrote:
> I read the article linked, and I think a better format would be:
>
> ``` mumble mumble label text mumble; attribute1=value1; attribute2=value2
>
>    Skip the CSS rules since they aren't used in Gemini, but the attributes
> for MIME *are* used, and those use the format I've shown above.  If you can
> parse MIME types, you can reuse *that* code to parse attributes.
>
> ```here is a table in CSV; content-type=text/csv; lang=en_US;

That's a possibility. Either formats are simple enough to parse I think.

> The format for tables is *horrible* (at least in my opinion).  The format
> I use to generate tables (ultimately in HTML) is the following:
>
> *header1	header2	header3	header4
> **footer1	footer2	footer3	footer4
> row-11	row-12	row-13	row-14
> row-21	row-22	row-23	row-24

Yes I think people have jumped on the specific example of table parsing 
I gave. The example is a quote from Bouncepaw's original post, and was 
to illustrate primarily how the parameters are used in the alt text, not 
to propose a new format. Maybe that aspect wasn't clear enough.

The particular format for a table I don't endorse - CSV or TSV is more 
natural and the mime type is already defined.

I'll clarify the example so its clear I'm not proposing a new format for 
text based tables.

>    So your table example:
>
> ```Here is a table; content-type=text/tsv; lang=en
> *+	1	2	3
> 1	2	3	4
> 2	3	4	5
> 3	4	5	6
> ```
>
>    (Yeah, way eaiser to type than '|' between each field)

Yes I agree, as you illustrate, using TSV or CSV is probably better.

> Just my two zorkmids worth. I don't really have a horse in this race, as
> I don't really care for the current gemini text format anyway, and this is
> adding complexity to a simple format, but that is solerpunk's call, not
> mine.

I'm not proposing this needs to be institutionalised in the spec 
(although that would be cool).

Rather this is instead what I have in mind is more like a community 
practice. For example people are sometimes using unicode superscript or 
square bracket footnotes to indicate a citation marker for links.

Best Wishes

  - Luke



From luke at marmaladefoo.com  Mon Sep  7 17:36:08 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 07 Sep 2020 17:36:08 +0100
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <CAPk6LxSDu6X0ES8aEXo89L6_O17HeigO8b1BJeQ6rvg7EdYWXQ@mail.gmail.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <CAPk6LxSDu6X0ES8aEXo89L6_O17HeigO8b1BJeQ6rvg7EdYWXQ@mail.gmail.com>
Message-ID: <5F566178.3010103@marmaladefoo.com>

Hi Kevin

On 07-Sep-2020 10:06, Kevin Sangeelee wrote:
> Anything that adds text that's really only parseable by a machine is 
> just a teeny bit user-hostile.

Well the alt-text never gets shown to the user, it is invisible to them. 
Some clients might act on it (for example at the moment to show a tool tip).

My personal view is that the CSS style delimiters attribute1: value; is 
less hostile than others. So it was part of the design consideration. 
Those clients or users wanting a simple experience can just ignore it 
all anyway.

> The ideas being discussed go further, because (unless I misunderstand) 
> it encourages text in weird unaligned formats to be served up by default.
>
> I would argue (on behalf of the Devil, of course) that mono-spaced 
> preformatted text is already perfect for aligning user-readable 
> tables. It's just awkward for machines to process semantically. There 
> are however reasonably reliable heuristics to figure out columns, 
> should the client want to add decoration. etc.

Yes everyone seems to have noticed the strange table format of the 
example. That example is misleading, as the real intention was to show 
where the attribute lives in technical terms (quoting from Bouncepaw's 
original post). I'm not proposing a new table format - CSV or TSV is 
probably the most appropriate format.

> Perhaps the alt-text could be used to specify something like 'source: 
> /data/my_original.csv', to give a person-readable route to 
> machine-readable data that the client could use to fetch and render 
> in-place on behalf of the user.

That could be a possible attribute people could try out, which might be 
important in some contexts. Perhaps it might apply where source code is 
quoting from a larger source.

Best Wishes

  - Luke


From colecmac at protonmail.com  Mon Sep  7 17:37:40 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Sep 2020 16:37:40 +0000
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <c008ea15-dcba-11cc-a2c9-f816dafa83a0@envs.net>
References: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
 <c008ea15-dcba-11cc-a2c9-f816dafa83a0@envs.net>
Message-ID: <_u75tVVBXc5bGVl0CeWS66XIJZNhE0ymlxshWKYaMes50cD15PNKQznuSRW09XXjoIwjtg8QAoclpGmvk0-ytwLnS4XxpT1OCmu1C8_BucE=@protonmail.com>

(I cannot see any emails from James Henderson, not even in spam.
 I am not sure why. I'm using ProtonMail.)

Ranf Dev writes:
> I don't think we really need a new feed format.

cblte writes:
> Why implementing something new?

These are in response to James' original proposal for a new feed
format, but in your responses both of you seem to propose another
new one, in gemtext and CSV respectively.

We already have Atom (or the inferior (so I'm told) RSS), which
are established well specced feed formats with parsers for many
languages. These formats are designed for machine reading which is
their strength, and I think it completely fits within Gemini's
design of "radical familiarity" to continue using an existing
standard.

makeworld

From colecmac at protonmail.com  Mon Sep  7 17:42:07 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Sep 2020 16:42:07 +0000
Subject: For consideration: JSON Feed
In-Reply-To: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
Message-ID: <YcZpirJbLQdSoMqyGA7qE85AFFrfKwxkKaAiaceCy7mBPfMINxcsZ5pAx8XwQkMH-_2S518xxcBcqZE_D91H4NDhrzba27xVLkgQ4YXI170=@protonmail.com>

> I'd like to suggest JSON Feed as a possible alternative:

It's an interesting format. Definitely easier to write,
althogh I'm not that partial to it since I don't plain on
hand-writing my feeds anyway.

I do plan on supporting this in my client Amfora however,
along with subscribing to Atom and RSS feeds. If anyone else
is doing work in Go they will find the gofeed library helpful,
it just added support for JSON feeds in v1.1.0.

https://github.com/makeworld-the-better-one/amfora
https://github.com/mmcdole/gofeed

makeworld

From ranfdev at gmail.com  Mon Sep  7 18:55:30 2020
From: ranfdev at gmail.com (Ranf Dev)
Date: Mon, 7 Sep 2020 19:55:30 +0200
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <_u75tVVBXc5bGVl0CeWS66XIJZNhE0ymlxshWKYaMes50cD15PNKQznuSRW09XXjoIwjtg8QAoclpGmvk0-ytwLnS4XxpT1OCmu1C8_BucE=@protonmail.com>
References: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
 <c008ea15-dcba-11cc-a2c9-f816dafa83a0@envs.net>
 <_u75tVVBXc5bGVl0CeWS66XIJZNhE0ymlxshWKYaMes50cD15PNKQznuSRW09XXjoIwjtg8QAoclpGmvk0-ytwLnS4XxpT1OCmu1C8_BucE=@protonmail.com>
Message-ID: <CAMXq4zpaR_fZLHX6OUs2eRdGg__fDnKTJQiHDqbJQruZyi-o0Q@mail.gmail.com>

> These are in response to James' original proposal for a new feed
format, but in your responses both of you seem to propose another
new one, in gemtext and CSV respectively.

Indeed in my previous email I made a poor choice of words.
I will try to better explain my proposal here.

RSS, (and atom, json...) feeds are easily parsable by machines and are
already supported by
feed readers, but they aren't readable by gemini clients. Also they are
> fairly verbose and Allow[s] for things like embedding images

Introducing a completely new feed format with its own new syntax would require
writing more code to parse it, so I don't agree with that decision.

Considering the above, and taking Spacewalk
(gemini://rawtext.club:1965/~sloum/spacewalk.gmi) as an example, I'm proposing
to use a format that doesn't require writing any new code, so that it
can be displayed by already
available gemini clients.
```
=> link1 date1 title1
Description1...
=> link2 date2 title2
Description2...
```
(ISO-8601 date).
Indeed, it's a new format and has its quirks, but we don't need to
change anything to
use it.
Advanced clients can implement special features by taking advantage
of this format: for example they can aggregate multiple feeds, or notify users
of new items.
Older clients can still fallback and show the feed as nice simple gemtext.

From easeout at tilde.team  Mon Sep  7 19:16:10 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Mon, 7 Sep 2020 14:16:10 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F566178.3010103@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <CAPk6LxSDu6X0ES8aEXo89L6_O17HeigO8b1BJeQ6rvg7EdYWXQ@mail.gmail.com>
 <5F566178.3010103@marmaladefoo.com>
Message-ID: <20200907181610.GD2239112@tilde.team>

On Mon, Sep 07, 2020 at 05:36:08PM +0100, Luke Emmet wrote:
> On 07-Sep-2020 10:06, Kevin Sangeelee wrote:
> > Anything that adds text that's really only parseable by a machine is
> > just a teeny bit user-hostile.
> 
> Well the alt-text never gets shown to the user, it is invisible to them.
> Some clients might act on it (for example at the moment to show a tool tip).

I think it would be helpful to quote the spec here:

> Use of alt text is at the client's discretion, and simple clients may
> ignore it. Alt text is recommended for ASCII art or similar
> non-textual content which, for example, cannot be meaningfully
> understood when rendered through a screen reader or usefully indexed
> by a search engine. Alt text may also be used for computer source code
> to identify the programming language which advanced clients may use
> for syntax highlighting.

Alt text is recommended for, and I think named after, the role of alt
text in HTML <img>. That is, to be an alternative representation of the
content, like "Photograph of a woman on a horse". In that sense it is
meant to be text that users see! Just not every user in all
circumstances. HTML <img> alt text is meant in part for users that use
screen readers, but users nonetheless. So I would prefer we not go
adding extensions to alt text that prevent it from being always
human-readable.

(Refer to the alt attribute as documented here:)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img

The advanced use case cited in the spec matches the way in
GitHub-flavored Markdown you can write ```typescript to get TypeScript
syntax highlighting. While not an alternative content representation,
that is at least human-readable.

> My personal view is that the CSS style delimiters attribute1: value; is less
> hostile than others. So it was part of the design consideration. Those
> clients or users wanting a simple experience can just ignore it all anyway.

I agree it's less hostile than other possibilities, but if you're a user
who depends on alt text for content representation, it's going to be
jarring when some of the time you get code read aloud to you by a screen
reader, or??well, you get what I mean.

Really, I think what we have here is a field with two possible uses that
are at cross purposes, one for people and one for machines. Syntatically
it's based on something in Markdown that's for machine use, but it's
recommended for the human use. But the whole idea of it being for human
use is spoiled by the fact that it will grate on humans in cases when it
is not for their use.

I would rather the spec either make a call and pick one purpose, or omit
the field entirely, rather than leaving this conflict unresolved.

Re: machine-parseable tables in Gemtext, I acknowledge that was not
really your point :) But in general I think the discussion around tables
is a symptom of our wish to keep the spec small and not see it slowly
grow forever.

I believe that extensions, when popular enough, become de facto
standards and force the spec to grow more than we might otherwise
prefer, lest the de facto standard simply become the new spec. This
pressure is not necessarily a bad thing, but consider, an accessibility
feature like the human-oriented use of alt text is unlikely to become
popular enough to force its way in by a de facto standard, and would
therefore need the support of the base spec to see acceptance.

From mailinglists at ngalt.com  Mon Sep  7 19:27:07 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Mon, 7 Sep 2020 11:27:07 -0700
Subject: Language tags in Luke's "A proposed scheme for parsing preformatted
 alt text"
Message-ID: <40F71761-141E-4748-A07B-549DF13B03D6@ngalt.com>

Prior reading:

gemini://gemini.marmaladefoo.com/blog/7-Sep-2020_Parsing_preformatted_alt_text.gmi                                                  

I haven?t made up my mind on, well, most things in this proposal. I?m still chewing on them, and I may never have an opinion on them, much less a well-thought-out opinion.

That said, I think that if we?re writing language codes in text, we ought to allow for full IETF language tags instead of just two-letter codes, although roughly nobody?ll bother writing any more than ?lang:en-GB?. I might do `lang:en-Shaw` once or twice, but that?s about it.

https://en.wikipedia.org/wiki/IETF_language_tag

That way, if people want to express more than just a language, there?s a well-trodden path for them to do so. Likewise, if, say, a screen reader wants to pick the right accent for a particular bit of text, it can.

Nathan

From me at ecmelberk.com  Mon Sep  7 19:38:05 2020
From: me at ecmelberk.com (Ecmel Berk =?UTF-8?B?Q2FubMSxZXI=?=)
Date: Mon, 7 Sep 2020 21:38:05 +0300
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F556ED0.4060504@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
Message-ID: <20200907213805.2c119a34.me@ecmelberk.com>

I just had this interesting formating idea reading through this thread:


[modifiers...] [type] [:] <description>


This format lets the alt text be mostly human-readable while keeping
some semantics for machines to parse through.

As an example, all these lines should be valid:

"python code: Code to parse this format"
"table: Point leaderboard"
"Description without any machine readable parts"

The [modifiers...] part is a list of adjectives the pre-formatted text
has, like a programming language name, type of art (ascii / ansi /
unicode / whatever), or whatever else other people can think of. They are
all single words separated by spaces.

[type] is the type of the content in the pre-formatted text block. Like
"code", "table" or "art"

The [:] is just a separator between the machine-readable part and the
description. If a machine reads any ":", it will stop processing, as the
continuation of this line is for humans only.

<description> is the human-readable explanation of what's inside the
pre-formatted block. It can contain anything, including ":" characters
since the machines should stop parsing after the first one.

If a machine has any doubts (any unrecognized modifier or type, or maybe some 
other heuristic), it should halt parsing and display the entire line as
is, to make sure malformed input can still be understood by a human.



I am not entirely sure how well this would actually work "in
production", but I feel like this is definitely something to throw out
here.

-- 
Have a nice (day|night|week(end)?)
~ Ecmel B. Canl?er ~

From tgrom.automail at nuegia.net  Mon Sep  7 18:42:48 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Mon, 7 Sep 2020 10:42:48 -0700
Subject: For consideration: JSON Feed
In-Reply-To: <YcZpirJbLQdSoMqyGA7qE85AFFrfKwxkKaAiaceCy7mBPfMINxcsZ5pAx8XwQkMH-_2S518xxcBcqZE_D91H4NDhrzba27xVLkgQ4YXI170=@protonmail.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <YcZpirJbLQdSoMqyGA7qE85AFFrfKwxkKaAiaceCy7mBPfMINxcsZ5pAx8XwQkMH-_2S518xxcBcqZE_D91H4NDhrzba27xVLkgQ4YXI170=@protonmail.com>
Message-ID: <20200907104242.57e642c6@lappy.lan>

On Mon, 07 Sep 2020 16:42:07 +0000
colecmac at protonmail.com wrote:

> > I'd like to suggest JSON Feed as a possible alternative:  
> 
> It's an interesting format. Definitely easier to write,
> althogh I'm not that partial to it since I don't plain on
> hand-writing my feeds anyway.
> 
> I do plan on supporting this in my client Amfora however,
> along with subscribing to Atom and RSS feeds. If anyone else
> is doing work in Go they will find the gofeed library helpful,
> it just added support for JSON feeds in v1.1.0.
> 
> https://github.com/makeworld-the-better-one/amfora
> https://github.com/mmcdole/gofeed
> 
> makeworld

I'd really prefer a RSS feed over JSON. My 2 cents.

From luke at marmaladefoo.com  Mon Sep  7 20:31:58 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 07 Sep 2020 20:31:58 +0100
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200907181610.GD2239112@tilde.team>
References: <5F556ED0.4060504@marmaladefoo.com>
 <CAPk6LxSDu6X0ES8aEXo89L6_O17HeigO8b1BJeQ6rvg7EdYWXQ@mail.gmail.com>
 <5F566178.3010103@marmaladefoo.com> <20200907181610.GD2239112@tilde.team>
Message-ID: <5F568AAE.1070303@marmaladefoo.com>



On 07-Sep-2020 19:16, easeout at tilde.team wrote:
> I think it would be helpful to quote the spec here:
>> Use of alt text is at the client's discretion, and simple clients may
>> ignore it. Alt text is recommended for ASCII art or similar
>> non-textual content which, for example, cannot be meaningfully
>> understood when rendered through a screen reader or usefully indexed
>> by a search engine. Alt text may also be used for computer source code
>> to identify the programming language which advanced clients may use
>> for syntax highlighting.
> Alt text is recommended for, and I think named after, the role of alt
> text in HTML<img>. That is, to be an alternative representation of the
> content, like "Photograph of a woman on a horse". In that sense it is
> meant to be text that users see! Just not every user in all
> circumstances. HTML<img>  alt text is meant in part for users that use
> screen readers, but users nonetheless. So I would prefer we not go
> adding extensions to alt text that prevent it from being always
> human-readable.
>
> (Refer to the alt attribute as documented here:)
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img
>
> The advanced use case cited in the spec matches the way in
> GitHub-flavored Markdown you can write ```typescript to get TypeScript
> syntax highlighting. While not an alternative content representation,
> that is at least human-readable.

Whilst a reference to the HTML spec is interesting, we are defining 
Gemini here, so the Gemini spec isn't beholden to HTML.

The spec mentions both applications of the tail of the "mode switch 
line" (to avoid a normative gloss), both as an alt text and to identify 
the programming language. So this duality is already envisaged in the spec.

> Really, I think what we have here is a field with two possible uses that
> are at cross purposes, one for people and one for machines. Syntatically
> it's based on something in Markdown that's for machine use, but it's
> recommended for the human use. But the whole idea of it being for human
> use is spoiled by the fact that it will grate on humans in cases when it
> is not for their use.
>
> I would rather the spec either make a call and pick one purpose, or omit
> the field entirely, rather than leaving this conflict unresolved.

I prefer that the spec allows for multiple uses. Primarily it is a label 
for human benefit, but that is not to say it cannot be comprehended by a 
machine.

This sort of relates to the other thread on the ML right now - about 
whether there could be a feed format based on gemtext - it would be 
based on certain conventions in the use of the format, without breaking 
gemtext at all.

I don't see how the spec can mandate the content that is in an 
informative part of the content -i.e. a label on an element.

Best wishes

  - Luke


From sandra.snan at idiomdrottning.org  Mon Sep  7 21:15:43 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Mon, 07 Sep 2020 22:15:43 +0200
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200907213805.2c119a34.me@ecmelberk.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
Message-ID: <87r1rdjqc0.fsf@idiomdrottning.org>

This feels like the "hot comment" antipattern. Codifying a part of the
language that was meant for humans.
http://wiki.c2.com/?HotComments

As for table output, I've been really happy with how the unicode tables
from md2gemini look. I have used many many ASCII tables via org-mode and
pandoc markdown. Which I use depend on the source data.

For a table that's primarily meant to be seen and used (like the D&D
tables I've posted) by humans I think the unicode tables are great.

And, you _can_ extract the fields and records from them:
The fields are separated by ? characters and whitespace.

Screenreaders could set those characters to silent and then read off the
values in each row separately.

For data that's meant for computer usage, it's easy to convert the
unicode tables to computable data, but a separate TSV file (or
sexps, XML or even JSON) is better.

That's kind of how I see the gem files, and I mean the following as a
warm compliment: they're glorified index listings. The "one link per
line" is a great structure for actually linking to actual files.

While I'm on the topic of one link per line, the whole numbers in the
paragraphs to refer to line links style is not cool. Its as if you want
inline links. If you wanted inline links then why didn't you put them in
the spec?

The spec was designed by someone who wanted text paragraphs followed by
(or preceded by) lists of links. _Pages_ are hypertext, but the prose
isn't.

From easeout at tilde.team  Mon Sep  7 21:31:34 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Mon, 7 Sep 2020 16:31:34 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F568AAE.1070303@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <CAPk6LxSDu6X0ES8aEXo89L6_O17HeigO8b1BJeQ6rvg7EdYWXQ@mail.gmail.com>
 <5F566178.3010103@marmaladefoo.com>
 <20200907181610.GD2239112@tilde.team>
 <5F568AAE.1070303@marmaladefoo.com>
Message-ID: <20200907203134.GE2239112@tilde.team>

On Mon, Sep 07, 2020 at 08:31:58PM +0100, Luke Emmet wrote:
> On 07-Sep-2020 19:16, easeout at tilde.team wrote:
> > I think it would be helpful to quote the spec here:
> > > Use of alt text is at the client's discretion, and simple clients may
> > > ignore it. Alt text is recommended for ASCII art or similar
> > > non-textual content which, for example, cannot be meaningfully
> > > understood when rendered through a screen reader or usefully indexed
> > > by a search engine. Alt text may also be used for computer source code
> > > to identify the programming language which advanced clients may use
> > > for syntax highlighting.
> >
> > Alt text is recommended for, and I think named after, the role of alt
> > text in HTML<img>. That is, to be an alternative representation of the
> > content, like "Photograph of a woman on a horse". In that sense it is
> > meant to be text that users see! Just not every user in all
> > circumstances. HTML<img>  alt text is meant in part for users that use
> > screen readers, but users nonetheless. So I would prefer we not go
> > adding extensions to alt text that prevent it from being always
> > human-readable.
> > 
> > (Refer to the alt attribute as documented here:)
> > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img
> > 
> > The advanced use case cited in the spec matches the way in
> > GitHub-flavored Markdown you can write ```typescript to get TypeScript
> > syntax highlighting. While not an alternative content representation,
> > that is at least human-readable.
> 
> Whilst a reference to the HTML spec is interesting, we are defining Gemini
> here, so the Gemini spec isn't beholden to HTML.

To be clear, I'm not saying we are beholden to HTML. But it is the basis
for the spec's vocabulary: In this case "alt text" is a term from HTML.
I'm pointing to HTML's <img> alt attribute because that's what I believe
Solderpunk was talking about when the spec mentioned "alt text". I think
that, and the text of the spec ("Alt text is recommended for?"), support
the notion that human-readable alternative content representation is the
primary point of the field.

> The spec mentions both applications of the tail of the "mode switch line"
> (to avoid a normative gloss), both as an alt text and to identify the
> programming language. So this duality is already envisaged in the spec.

It does, but my next point was that this two-uses-for-one-field
situation creates conflict between the uses with negative consequences
for users. It would be better regarded as a mistake in the spec worth
amending.

> > Really, I think what we have here is a field with two possible uses that
> > are at cross purposes, one for people and one for machines. Syntatically
> > it's based on something in Markdown that's for machine use, but it's
> > recommended for the human use. But the whole idea of it being for human
> > use is spoiled by the fact that it will grate on humans in cases when it
> > is not for their use.
> > 
> > I would rather the spec either make a call and pick one purpose, or omit
> > the field entirely, rather than leaving this conflict unresolved.
> 
> I prefer that the spec allows for multiple uses. Primarily it is a label for
> human benefit, but that is not to say it cannot be comprehended by a
> machine.

I hear you, but I don't see how that addresses the problem create for
users by having the field work two ways.

> This sort of relates to the other thread on the ML right now - about whether
> there could be a feed format based on gemtext - it would be based on certain
> conventions in the use of the format, without breaking gemtext at all.

As I understand it, a feed format based on Gemtext would be usable as a
plain Gemtext page by a plain browser, which is great. And for a feed
aggregator to use it as a subscription mechanism, you'd have to
formalize some piece of it. All of that sounds OK for that purpose.

But in this thread, I think we're talking interpreting Gemtext alt text
differently, not for a special kind of client, but in regular
user-facing interactive browsers. And not on special documents like
feeds, but in general purpose Gemtext pages.

I think that difference makes these two cases not comparable. Adding
Gemtext-compatible formality for feed pages has no effect on other
Gemtext pages. Adding accessibility-incompatible formality for all
Gemtext pages could have a negative effect on particular users across
Gemini as a whole.

> I don't see how the spec can mandate the content that is in an informative
> part of the content -i.e. a label on an element.

I think what the spec can do is make a clearer recommendation. Maybe
we'd have two fields and they wouldn't have to step on each other's
toes.

From easrng at gmail.com  Mon Sep  7 22:29:51 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Mon, 7 Sep 2020 17:29:51 -0400
Subject: For consideration: JSON Feed
In-Reply-To: <20200907104242.57e642c6@lappy.lan>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <YcZpirJbLQdSoMqyGA7qE85AFFrfKwxkKaAiaceCy7mBPfMINxcsZ5pAx8XwQkMH-_2S518xxcBcqZE_D91H4NDhrzba27xVLkgQ4YXI170=@protonmail.com>
 <20200907104242.57e642c6@lappy.lan>
Message-ID: <CAEzvDCWg_rsqavczkXvBbXN5o_QQLh5m05ysUowHw6SPuMxxjg@mail.gmail.com>

>I'd really prefer a RSS feed over JSON. My 2 cents.
I'm curious why, is it just the existing ecosystem?

On Mon, Sep 7, 2020, 2:47 PM Tom <tgrom.automail at nuegia.net> wrote:

> On Mon, 07 Sep 2020 16:42:07 +0000
> colecmac at protonmail.com wrote:
>
> > > I'd like to suggest JSON Feed as a possible alternative:
> >
> > It's an interesting format. Definitely easier to write,
> > althogh I'm not that partial to it since I don't plain on
> > hand-writing my feeds anyway.
> >
> > I do plan on supporting this in my client Amfora however,
> > along with subscribing to Atom and RSS feeds. If anyone else
> > is doing work in Go they will find the gofeed library helpful,
> > it just added support for JSON feeds in v1.1.0.
> >
> > https://github.com/makeworld-the-better-one/amfora
> > https://github.com/mmcdole/gofeed
> >
> > makeworld
>
> I'd really prefer a RSS feed over JSON. My 2 cents.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/552bdf55/attachment.htm>

From sean at conman.org  Mon Sep  7 23:54:57 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 7 Sep 2020 18:54:57 -0400
Subject: Conversion of HTML to gemtext (was Re: A proposed scheme for parsing
 preformatted alt text)
In-Reply-To: <87r1rdjqc0.fsf@idiomdrottning.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
Message-ID: <20200907225457.GJ15566@brevard.conman.org>

It was thus said that the Great Sandra Snan once stated:
> 
> While I'm on the topic of one link per line, the whole numbers in the
> paragraphs to refer to line links style is not cool. Its as if you want
> inline links. If you wanted inline links then why didn't you put them in
> the spec?
>  
> The spec was designed by someone who wanted text paragraphs followed by
> (or preceded by) lists of links. _Pages_ are hypertext, but the prose
> isn't.

  Because it was clear that people *wanted* links in gopher?  Because there
are too many variations on Markdown already?  Because it's not that easy to
parse Markdown? [1]  Solderpunk wanted a way to include links and still make
it easy to parse.

  I do the numbering thing because I'm converting HTML to gemtext, and I
borrowed most of the code from my work in converting HTML to text for
gopher.  I like HTML for its hypertext capabilities.  But I found that it
was harder for me to convert HTML to gemtext tnan to plain text since
gemtext has *just* enough capabilities to make it seem easier, but not
enough to handle some of the seldom used tags (like <DL><DT><DD>) or even
simple nesting (a <BLOCKQUOTE> within a <BLOCKQUOTE>).

  I could serve HTML, but that would go against the grain of Gemini.

  So I'm looking at this post of mine:

        http://boston.conman.org/2020/07/28.1

and I'm wondering how I would do it differently.  I supposed instead of
(showing the rendered output, not the actual gemtext):

        On Saturday, I sent a message [1] to the party responsible for
        slamming my Gemini server [2] (one among several) and I've yet to
        receive any response.  I removed the block from the firewall, and I
        haven't seen any requests from said bot.  It looks to have been a
        one-off thing at this time.

        [1] /boston/2020/07/25.2
        [2] /boston/2020/07/24.2

        Weird.

        But then again, this is the Intarwebs, where weird things [1] happen
        all the time [2].

        [1] /boston/2006/10/30.1
        [2] /boston/2015/04/29.1

        At this point, I'm hoping it was fixed silently and it won't be an
        issue again.

I could do:

        On Saturday, I sent a message to the party responsible for slamming
        my Gemini server (one among several) and I've yet to receive any
        response.  I removed the block from the firewall, and I haven't seen
        any requests from said bot.  It looks to have been a one-off thing
        at this time.

        I sent a message
        slamming my Gemini server

        Weird.

        But then again, this is the Intarwebs, where weird things happen
        all the time.

        weird things
        all the time

        At this point, I'm hoping it was fixed silently and it won't be an
        issue again.

  I'm not sure how I fell about that.  It doesn't look as good to me as the
numbered links.  Would you prefer I just serve up text/html?  Not use HTML
at all?  Change the output to the sample above?

  And before I go, here are the links to all three versions (HTML, plain
text, gemtext):

	http://boston.conman.org/2020/07/28.1
	gopher://gopher.conman.org/0Phlog:2020/07/28.1
	gemini://gemini.conman.org/boston/2020/07/28.1

  -spc

[1]	Markdown, as initially defined by John Gruber also allowed arbitrary
	HTML.  I think most people either forget that detail, or don't know
	about it in the first place.

From lists at ryliejamesthomas.net  Tue Sep  8 08:58:16 2020
From: lists at ryliejamesthomas.net (rjt)
Date: Tue, 8 Sep 2020 17:58:16 +1000
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F556ED0.4060504@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
Message-ID: <8d1b2bc0-eefb-71e3-1333-8a8a10af65ff@ryliejamesthomas.net>

On 7/9/20 9:20 am, Luke Emmet wrote:
> Hi All
> 
> We had an interesting discussion on the #Gemini IRC channel earlier 
> today about a generalised scheme for parsing the alt text on 
> preformatted regions, e.g.
> 
> ```this is the alt text, not normally displayed to the end user
> the preformatted content
> ```
> 
> It was a collective discussion, but I've written up some of the key 
> points in a post here:
> 
> gemini://gemini.marmaladefoo.com/blog/7-Sep-2020_Parsing_preformatted_alt_text.gmi 
> 
> 
> Essentially the key design considerations are as follows:
> 
> 1. By default the whole alt text can be used as a label (current behaviour)
> 2. Use CSS style syntax for the remainder, a familiar and low ritual syntax
> 3. Don't prescribe the attributes, allow practice to suggest them
> 4. Be backwards compatible and friendly to screen readers etc.
> 
> two initial attributes seem to have obvious initial utility and could be 
> used to effectively label content in a practical way:
> 
> content-type
> lang
> 
> Best Wishes
> 
>  ?- Luke


It's interesting!, but I feel like transforming preformatted text (like 
in your example of adding borders to a table)  goes against the semantic 
idea of preformatted text. It becomes postformatted :) You've basically 
turned the preformatted text section into a general-purpose wrapper.

   --I keep going back-and-forth on whether-or-not it's a good idea
   though. On one hand: yeah, it's no longer preformatted; on the other
   it's not a dramatic change, and it makes tables actually legible; on
   the other, oh god, I see the return of table-based layouts--

Still, I think it's more within the spirit of Gemini to show the 
preformatted version, and link to a TSV/CSV/.ODS file for those that may 
want it.

Nitpick: I also think your examples misunderstand what alt text is for. 
'here is a table in csv' is not a useful description to a screenreader 
user. Alt text is not a 'simple label', but a description.

As an aside: Unfortunately I don't think there's enough semantic 
information in Gemtext to let screen readers describe tables well.

I'm all for a bit more discussion about adding metadata to Gemini files 
themselves (even if I suspect it would produce too much clutter). 
Perhaps a better approach is to not tie it to the preformatted text 
section though? Preformatted text doesn't need, say, a language 
attribute more than a quote or any other piece of text.

From easeout at tilde.team  Tue Sep  8 18:31:57 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Tue, 8 Sep 2020 13:31:57 -0400
Subject: Unadorned Gemtext instead of syndication formats
Message-ID: <20200908173157.GG2239112@tilde.team>

Recently on the mailing list and in #gemini we've been talking about
syndication, as in RSS / Atom. I want to begin by summarizing some of
our thoughts.

# Existing formats

RSS and Atom are well-supported formats. They are XML, but you can
probably import a parser / generator rather than having to write one
yourself.

JSON Feed is a well-supported format, and is regarded as simpler than
RSS / Atom. Even if you had to write your own parser, you would be able
to build off a JSON parser because those are available for basically
every language. They are also often simpler to build on than an XML
parser.

RSS, Atom, and JSON Feed publish not just Gemini, but other protocols.
They are commonly served over not just Gemini, but other protocols. And
existing feed readers generally expect feeds to be in one of these
formats. So if you want your site to be syndicated in the existing
internet feed reader ecosystem, using one of these formats is the price
of entry.

CAPCOM expects Atom, therefore Atom became a common way to publish
Gemini blogs. This works, and does not need to change unless an
alternative would be markedly better.

# Making syndication easier

However, some of us are concerned with the complexity of creating a feed
alongside creating Gemini content. If one of our goals is to make Gemini
content easy to publish, making it easy to syndicate is an attractive
goal too. And it is jarring to go from writing Gemtext, which is
remarkably simple and straightforward, to writing Atom XML, or to
finding a static site generator tool that will do it for you. This feels
like a cost. It might remind us of the bloat on the web we are trying to
do without. Or it might be a barrier to entry for users who would be
confident publishing Gemtext, but not confident publishing Atom, or for
that matter, a web page.

To address the fact that creating a feed is a few steps more difficult
than creating a Gemtext page, one idea is to make a new feed format
which is written in Gemtext and conforms to a pattern. While it's true
this would be easy to write, there is no existing parser ecosystem for
it, so it would be effectively Gemini-only. If you wanted to syndicate
to the broader internet, you would still need to publish something like
Atom. Furthermore, although parsing Gemtext is not as difficult as Atom
or JSON Feed if you had to start from plain text and work your way up,
existing formats have off-the-shelf parsers in many languages, so you
are not starting from the bottom. But with a brand new format based on
Gemtext, you would have to.

So we are not all sold on the idea of a Gemtext-based feed format.
However, one positive characteristic such a format is that it would be
browsable as a regular Gemtext page. And that got us thinking: 

If regular Gemtext pages are easy to parse, can we just treat any
Gemtext page as a feed? In fact, yes we can. You can poll plain Gemtext
pages, not feed format files, and detect the links on the page that are
new. And we don't need a Gemtext feed format pattern, because the
pattern of link lines beginning with "=>" is enough.

# Subscribing to any Gemtext page

To get a feel for that, I did a proof of concept that you can try out:

=> https://github.com/kconner/gemini-subscription-cli Proof of Concept

This repository contains a Makefile and a shell script. The script takes
a list of Gemini URLs to fetch, which are expected to be Gemtext pages.
It filters them down to just the link lines. It compares the set of link
lines with a previously-fetched set of link lines, and it identifies and
emits those that are new. It saves the new total set as the next run's
previous set for comparison.

If you want, you can clone the repo and then try it out.

Subscribe to some pages:

$ echo 'gemini://gemini.circumlunar.space:1965/servers/' >> subscribed-urls
$ echo 'gemini://tilde.team/~easeout/glog/' >> subscribed-urls

Fetch all the links, since we don't have a prior set to compare to:

$ make
fetched: gemini://gemini.circumlunar.space:1965/servers/                                                                   
fetched: gemini://tilde.team/~easeout/glog/                                                                                
wrote: new-links.gmi                                                                                                       
=> gemini://gus.guru/known-hosts Gemini hosts known to GUS                                                                 
=> gemini://gemini.conman.org                                                                                              
=> gemini://zaibatsu.circumlunar.space                                                                                     
=> gemini://carcosa.net                                                                                                    
?

Later, update again and identify what's new. (To test right away, you
can delete a few lines from cached-links.gmi.)

$ make
fetched: gemini://gemini.circumlunar.space:1965/servers/
fetched: gemini://tilde.team/~easeout/glog/
wrote: new-links.gmi
=> gemini://breadpunk.club
=> 2020-09-07-re-a-wordpress-confession.gmi 7 September 2020: Re: A Wordpress Confession

# Where does this functionality belong?

This proof of concept demonstrates that any Gemini page can already be
treated like a feed. This means that, if you don't mind not
participating in the broader internet feed reader ecosystem, and you
don't mind the occasional page redesign creating noise in subscription
results, you don't have to make a feed file at all. Syndication is
zero-cost.

In hindsight, why does RSS exist? What is "Really Simple" about it?
Well, it's simpler than HTML. If HTML was easy enough to parse, you
could just subscribe to web pages and not need feed files. But Gemtext
is already easy to parse. We don't our experience on the web to mislead
us into thinking a page, like your blog index page, is not already a
subscribable list of links.

It's been pointed out this is not very different from Spacewalk, which
(I think?) works by just polling Gemini pages and updating when they
change, as opposed to when their links change. Both of these are useful
and easy ways to subscribe to any Gemtext page.

# Closing

Gemtext authors could feel like they are not burdened with creating a
feed file if browsers, feed readers, and aggregators allowed subscribing
to Gemtext pages directly. When as an author you understand that a feed
file is unnecessary, the pressure to create a feed file is lifted. But
for that to happen, you have to see direct Gemtext subscription working
in the wild. One way that could work is for a browser to have a way to
treat a bookmark like a feed subscription. I also think if CAPCOM would
accept Gemtext pages as a feed URL option, that would go a long way.

From meff at meff.me  Tue Sep  8 19:17:42 2020
From: meff at meff.me (Meff)
Date: Tue, 08 Sep 2020 11:17:42 -0700
Subject: Unadorned Gemtext instead of syndication formats
In-Reply-To: <20200908173157.GG2239112@tilde.team>
References: <20200908173157.GG2239112@tilde.team>
Message-ID: <874ko8xhdl.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

easeout at tilde.team writes:

> However, some of us are concerned with the complexity of creating a feed
> alongside creating Gemini content. If one of our goals is to make Gemini
> content easy to publish, making it easy to syndicate is an attractive
> goal too. And it is jarring to go from writing Gemtext, which is
> remarkably simple and straightforward, to writing Atom XML, or to
> finding a static site generator tool that will do it for you. This feels
> like a cost. It might remind us of the bloat on the web we are trying to
> do without. Or it might be a barrier to entry for users who would be
> confident publishing Gemtext, but not confident publishing Atom, or for
> that matter, a web page.

At this point in time, how many folks can write Gemtext but aren't
confident writing HTML? Yes, for those that hand-author feeds, it's
certainly a bit of a bother writing XML by hand (I've screwed it up
myself a few times), but I'm not sure the
Gemini community is at the point where we have users that are confident
with Gemtext but not with HTML.

> # Subscribing to any Gemtext page
>
> To get a feel for that, I did a proof of concept that you can try out:
>
> => https://github.com/kconner/gemini-subscription-cli Proof of Concept
>
> This repository contains a Makefile and a shell script. The script takes
> a list of Gemini URLs to fetch, which are expected to be Gemtext pages.
> It filters them down to just the link lines. It compares the set of link
> lines with a previously-fetched set of link lines, and it identifies and
> emits those that are new. It saves the new total set as the next run's
> previous set for comparison.

If there's just a shell script parsing text and making socat commands, what's
stopping an author from using `jq` or `xidel` on the output to parse
JSON and XML respectively? I realize in code it's not that simple, but
most languages in general use have JSON and XML parsers easily available
and generally well documented.

> This proof of concept demonstrates that any Gemini page can already be
> treated like a feed. This means that, if you don't mind not
> participating in the broader internet feed reader ecosystem, and you
> don't mind the occasional page redesign creating noise in subscription
> results, you don't have to make a feed file at all. Syndication is
> zero-cost.

One of my favorite parts of Gemini is the attitude that it works with the
rest of the net, as opposed to trying to cloister itself like the Web
does. One of my pet peeves with the web is how it tries to reinvent
everything. Long-lived connections, push protocols, things that TCP has
had _forever_.

>
> In hindsight, why does RSS exist? What is "Really Simple" about it?
> Well, it's simpler than HTML. If HTML was easy enough to parse, you
> could just subscribe to web pages and not need feed files. But Gemtext
> is already easy to parse. We don't our experience on the web to mislead
> us into thinking a page, like your blog index page, is not already a
> subscribable list of links.

Small aside: Semantically annotated tags have been a dream for the W3C
for quite some time now, and annotating feed links and other tags is the
purpose behind Semantic Web initiatives. The web has definitely tried to
allow in-band feeds.

> Gemtext authors could feel like they are not burdened with creating a
> in the wild. One way that could work is for a browser to have a way to
> treat a bookmark like a feed subscription. I also think if CAPCOM would
> accept Gemtext pages as a feed URL option, that would go a long way.

I still feel like this is NIH, but I'm not a CAPCOM or Spacewalk author
so a decision like this  isn't my place. As long as we continue to have
Atom/RSS support, that's all I'd like. I guess if there is a broader
move to Gemtext feeds, there should be pretty simple methods available
to convert those into Atom-compatible feeds.

- meff

From moody at posixcafe.org  Tue Sep  8 19:45:27 2020
From: moody at posixcafe.org (Jacob Moody)
Date: Tue, 8 Sep 2020 13:45:27 -0500
Subject: Unadorned Gemtext instead of syndication formats
In-Reply-To: <20200908173157.GG2239112@tilde.team>
References: <20200908173157.GG2239112@tilde.team>
Message-ID: <8fbfcd96-38f9-4bab-1ad9-67f85bb7c4fa@posixcafe.org>

I talked about this a bit on #gemini but though I could collect some of 
my points here for posterity.

On 9/8/20 12:31 PM, easeout at tilde.team wrote:
> RSS and Atom are well-supported formats. They are XML, but you can
> probably import a parser / generator rather than having to write one
> yourself.

Part of the beauty of gemini to me is that there is really no bar to 
entry in terms of requirements of what the system has to have before you 
start. There is tls but I think having this encryption requirement is 
more then reasonable(even if I have reservations on the design of tls). 
The requirements on using something that uses XML would limit the 
ecosystems that gemini could exist on. I loved seeing the adaption in 
otherwise limited software stacks like plan9, in which the complexity of 
things like xml parsing has prevented a readily usable library to exist 
on the platform.

> This proof of concept demonstrates that any Gemini page can already be
> treated like a feed. This means that, if you don't mind not
> participating in the broader internet feed reader ecosystem, and you
> don't mind the occasional page redesign creating noise in subscription
> results, you don't have to make a feed file at all. Syndication is
> zero-cost.

This is fantastic. With just one page could be used for both a human 
readable index as well as something like a feed. Having a single page 
for both I think is really in the spirit of how I interpreted this 
protocol. The fact that you could whip up something this small to 
process feeds like is a testament to the simplicity of this type of 
system already.

> Gemtext authors could feel like they are not burdened with creating a
> feed file if browsers, feed readers, and aggregators allowed subscribing
> to Gemtext pages directly. When as an author you understand that a feed
> file is unnecessary, the pressure to create a feed file is lifted. But
> for that to happen, you have to see direct Gemtext subscription working
> in the wild. One way that could work is for a browser to have a way to
> treat a bookmark like a feed subscription. I also think if CAPCOM would
> accept Gemtext pages as a feed URL option, that would go a long way.

I don't think something like this would stop people from using something 
like atom or so on as their own feed system, which I find more then 
fine. If servers would like to, they could even offer an automated way 
of creating those types of feeds based on something like the Gemtext 
implementation. I would consider this type of feature to evolve over 
time for which ever feed system is chosen regardless. For me personally 
I think this satisfies the 'complexity when you want it and none if you 
dont' attitude that I find attractive. What I am trying to avoid here is 
the expectation that servers need to provide an xml based feed and the 
expectation that clients should parse it.

Thanks,
Moody

From tgrom.automail at nuegia.net  Tue Sep  8 21:15:09 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Tue, 8 Sep 2020 13:15:09 -0700
Subject: For consideration: JSON Feed
In-Reply-To: <CAEzvDCWg_rsqavczkXvBbXN5o_QQLh5m05ysUowHw6SPuMxxjg@mail.gmail.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <YcZpirJbLQdSoMqyGA7qE85AFFrfKwxkKaAiaceCy7mBPfMINxcsZ5pAx8XwQkMH-_2S518xxcBcqZE_D91H4NDhrzba27xVLkgQ4YXI170=@protonmail.com>
 <20200907104242.57e642c6@lappy.lan>
 <CAEzvDCWg_rsqavczkXvBbXN5o_QQLh5m05ysUowHw6SPuMxxjg@mail.gmail.com>
Message-ID: <20200908131509.162f28ed@viridi>

On Mon, 7 Sep 2020 17:29:51 -0400
"A. E. Spencer-Reed" <easrng at gmail.com> wrote:

> >I'd really prefer a RSS feed over JSON. My 2 cents.  
> I'm curious why, is it just the existing ecosystem?
> 
Well part of it. But mostly I think a lot of the JSON is better than
XML is more hype than merit. And It's not exactly hard to find a good
XML library on any platform I've used. And libexpact is very efficient.

I also like the TSV style approach but think it can potentially
limiting. Also could probably lead to less than desirable layouts in
the future as the only real way to expand that is adding another
column, leaving the old ones in and having positional parsers.

-- 
 _________________________________________ 
/ There's no such thing as pure pleasure; \
\ some anxiety always goes with it.       /
 ----------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

From tgrom.automail at nuegia.net  Tue Sep  8 21:30:52 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Tue, 8 Sep 2020 13:30:52 -0700
Subject: For consideration: JSON Feed
In-Reply-To: <20200907023017.GC2239112@tilde.team>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team>
Message-ID: <20200908133052.115faa06@viridi>

It is true that JSON usually resolves to an object, but that makes it a
bit more of a chore to deal with when using non-object-oriented
languages. I'm not sure why you had a difficult time writing XML
parsers, but it shouldn't be too different from something along the
lines of var = $root->array[n]->post;. I don't feel too strongly either
way, but I do feel that JSON being so much better than XML is largely
overhyped and while there are extreme edge-cases where some more
specialized interchange format could be more efficient than XML often
times there is just not that huge of a difference to warrant going in a
completely new direction and leaving behind decades of development into
XML based tools. To me the XML vs JSON argument is a lot like
bikeshedding, and I'd go with XML because it's what we already have and
doesn't have problems with non-javascript langs.

But if we really want to drag the XML vs JSON bikeshed all the way out,
might as well use an existing bikeshed blog than start up a new one.

This is linked to from XMPP.org myths & legends
https://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html
It explores the XML vs JSON debate in the most painstaking through
detail.


Abstract

We all know that XML is "fat" and JSON is the "thinner", "faster",
"smaller", "better" markup. We know this to be true because we've been
told it over and over. It's "obvious" and "inherently true" because XML
has redundant end tags, namespaces, entities and other extra "pounds of
fat" that JSON doesn't have. But where is the science supporting this?
What are the facts and what is myth? When people make design and
architecture decisions it should be supported by facts not speculation.
In this paper I show the results of an ongoing series of real world
tests of Markup performance in browsers across a wide variety of
devices, browsers and operating systems and attempt to quantify markup
performance with experimental results and maybe trim the fat myth one
calorie at a time.

-- 
 _________________________________________ 
/ There's no such thing as pure pleasure; \
\ some anxiety always goes with it.       /
 ----------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

From easeout at tilde.team  Tue Sep  8 23:27:27 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Tue, 8 Sep 2020 18:27:27 -0400
Subject: Unadorned Gemtext instead of syndication formats
In-Reply-To: <874ko8xhdl.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
References: <20200908173157.GG2239112@tilde.team>
 <874ko8xhdl.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <20200908222727.GA1825746@tilde.team>

On Tue, Sep 08, 2020 at 11:17:42AM -0700, Meff wrote:

> At this point in time, how many folks can write Gemtext but aren't
> confident writing HTML? Yes, for those that hand-author feeds, it's
> certainly a bit of a bother writing XML by hand (I've screwed it up
> myself a few times), but I'm not sure the
> Gemini community is at the point where we have users that are confident
> with Gemtext but not with HTML.

> If there's just a shell script parsing text and making socat commands, what's
> stopping an author from using `jq` or `xidel` on the output to parse
> JSON and XML respectively? I realize in code it's not that simple, but
> most languages in general use have JSON and XML parsers easily available
> and generally well documented.

It's true that us early adopters are comfortable enough to handle this,
and that publishing Atom or RSS has distinct advantages. But I hope we
get to the point where it's not just us early adopters. If we can make
it simpler for newcomers, we might get there sooner.

I think for Gemini to grow and thrive and have new content that sustains
it, the ecosystem needs to:

- Convert web readers to Gemini readers, so there is more audience
- Convert Gemini readers to Gemini publishers, so there is more content
- Convert Gemini publishers to Gemini hosts, so there are more domains

That's a funnel, basically. At each stage, some fraction of people will
stop and not move to the next stage. The simpler we make each step, the
farther through the funnel the average user will get. So I want to push
on all of these things. Today I'm attempting to make the syndication
part of publishing simpler.

There's also nothing wrong with continuing to publish Atom or RSS. I can
think of two big advantages: You would still have to use a feed format
in order to syndicate beyond Gemini. You could declare exactly which
links you wanted to publish, which is nicer for your readers, so readers
should prefer it when it's offered. In other words, incentives still
exist to make the upgrade. I just don't think there is a cost to
building clients that can subscribe to your Gemtext page even if you
haven't made a feed.

> One of my favorite parts of Gemini is the attitude that it works with the
> rest of the net, as opposed to trying to cloister itself like the Web
> does. One of my pet peeves with the web is how it tries to reinvent
> everything. Long-lived connections, push protocols, things that TCP has
> had _forever_.

I feel that. Do you think that, if we merely allowed RSS or Atom, and
did not lean into them as a standard, we would be heading toward a
compatibility problem because a smaller fraction of Gemini pages would
have RSS or Atom feeds? If so, could that be offset by the way
simplicity might encourage more users to create content?

> I still feel like this is NIH, but I'm not a CAPCOM or Spacewalk author
> so a decision like this  isn't my place. As long as we continue to have
> Atom/RSS support, that's all I'd like. I guess if there is a broader
> move to Gemtext feeds, there should be pretty simple methods available
> to convert those into Atom-compatible feeds.

I wouldn't say we're inventing anything??You maybe understood this
already, but I'm not sure whether I was clear: I'm not suggesting we
create a new feed format that happens to have syntax in common with
Gemtext. I'm suggesting that Gemtext, because it contains links, already
is a feed if you interpret it that way.

But anyway, yes, I think aggregators and feed readers should continue to
use RSS and Atom and JSON Feed and would not want that to change.

(Sorry for the repeat email; I failed to send it to the list address.)

From easeout at tilde.team  Tue Sep  8 23:30:06 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Tue, 8 Sep 2020 18:30:06 -0400
Subject: Unadorned Gemtext instead of syndication formats
In-Reply-To: <8fbfcd96-38f9-4bab-1ad9-67f85bb7c4fa@posixcafe.org>
References: <20200908173157.GG2239112@tilde.team>
 <8fbfcd96-38f9-4bab-1ad9-67f85bb7c4fa@posixcafe.org>
Message-ID: <20200908223006.GA1964344@tilde.team>

On Tue, Sep 08, 2020 at 01:45:27PM -0500, Jacob Moody wrote:
> I don't think something like this would stop people from using something
> like atom or so on as their own feed system, which I find more then fine. If
> servers would like to, they could even offer an automated way of creating
> those types of feeds based on something like the Gemtext implementation. I
> would consider this type of feature to evolve over time for which ever feed
> system is chosen regardless. For me personally I think this satisfies the
> 'complexity when you want it and none if you dont' attitude that I find
> attractive. What I am trying to avoid here is the expectation that servers
> need to provide an xml based feed and the expectation that clients should
> parse it.

Agreed, RSS et al are great and we shouldn't get rid of them. But they
could be viewed as an upgrade path from a basic but functional starting
point.

(Sorry for the repeat message; I failed to send to the list address.)

From mailinglists at ngalt.com  Wed Sep  9 05:04:13 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Tue, 8 Sep 2020 21:04:13 -0700
Subject: When thinking about feed formats, consider non-blog uses, too
Message-ID: <2FFB783D-FE63-4BA9-845B-DF17F09EF134@ngalt.com>

(warning: rambly, but the last paragraph actually has a point I wanted to make)

I think we ought to reexamine why people bother with publishing changes to a written body of work in a syndication format.

First, let?s explicitly set aside podcasts and torrented-tv-showcasts.

Correct me if I?m wrong, but most feeds today that people subscribe to are ones that are connected to some sort of time-ordered publication ? like a blog. An author writes a blog entry and then the blog software updates its most-recent-changes feed.

This sort of feed is:

- automatically generated by some preexisting software
- tied to a linearizable publishing flow

This isn?t the only kind of feed pipeline, though.

One of the things I wanted when starting my capsule was to _not_ have a blog or blog-generating software (like a static-site generator). Still, I wanted people to be able to have a computer automatically check back and see if I?d changed anything, so I figured I?d want _some_ kind of syndication format available to automated clients like CAPCOM and feed readers.

I?d written Atom. I?d also written things that generated Atom. While Prettier makes writing nice-looking Atom easier, I didn?t want to hand-write Atom myself.

Then I thought about JSON Feed. I never liked writing strict JSON (no comments, no trailing commas permitted), but I remembered that I have yj on my computers. This would let me write YAML (pleasant!) and generate JSON.

So I did just that, and now I have two lines in a Makefile for when I want to update the JSON version of the JSON Feed:

feed: feed.yaml
	cat feed.yaml | yj -i > feed.json

(the -i pretty-prints the JSON instead of leaving it all on one line. I _like_ having this sort of thing be at least somewhat human-readable, even if it bloats the payload for feed readers a bit.)

Now then. Let?s look at my changelog feed so we can all talk about it:

version:       https://jsonfeed.org/version/1.1
title:         my changelog thing
language:      en-US
home_page_url: gemini://gemini.whatever.example
feed_url:      gemini://gemini.whatever.example/feed.json

items:
-
  id: e98b2c33-0cde-4856-a0ea-8272005e3341
  url: gemini://gemini.whatever.example/
  content_text: Mention on the home page that I like ambient music.
  date_published: 2020-09-09T03:39:20Z
-
  id: 14f1a84c-df7e-43ce-b20c-5a40398188ef
  url: gemini://gemini.whatever.example/
  content_text: Added homepage.
  date_published: 2020-09-08T00:41:07Z

(I?ve set up a capsule. I haven?t quite managed to find hosting for it yet. Hence the .example TLD.)

I think we all want simplicity so we can get novice proto-nerds on board with Gemini, but I think it?s a minor hassle for a novice astronaut to manually write a correct JSON Feed feed for a changelog where any given page might show up repeatedly. Any given item?s `id` could just be a single number, but writing out a proper `date_published` in proper RFC 3339 is kind of a hassle unless you have a way to get the output of  date(1) in the proper format.

On the other hand, there are the various line-based gemtext file formats. I think that if we want to make yet another mini-format for link text, we ought to provide enough information so aggregators like CAPCOM and feed readers can tell when one page is being updated repeatedly.

yj: https://github.com/sclevine/yj

* ?Capsule? is Geminispeak for ?website?, yes?

From gemini at gkbrk.com  Tue Sep  8 14:58:56 2020
From: gemini at gkbrk.com (Leo)
Date: Tue, 8 Sep 2020 16:58:56 +0300
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <_u75tVVBXc5bGVl0CeWS66XIJZNhE0ymlxshWKYaMes50cD15PNKQznuSRW09XXjoIwjtg8QAoclpGmvk0-ytwLnS4XxpT1OCmu1C8_BucE=@protonmail.com>
References: <_u75tVVBXc5bGVl0CeWS66XIJZNhE0ymlxshWKYaMes50cD15PNKQznuSRW09XXjoIwjtg8QAoclpGmvk0-ytwLnS4XxpT1OCmu1C8_BucE=@protonmail.com>
Message-ID: <70267a11-5894-794e-1b1c-db63e1e3e143@gkbrk.com>

While I like the idea of simple line-delimited formats for feeds,
I have to agree that Atom or RSS is simply the way to go here.

The Gemini Protocol does not have to use the Gemini Document
Format for everything. That's why the protocol supports MIME
types, so you can send over JSON, HTML, Atom or RSS.

By adding support for the Gemini protocol as a transport option
to common tools, Gemini RSS feeds will also become
widespread. Reinventing the feed format, along with the transport
format, is too much work and would limit usability.

--
Leo


From easrng at gmail.com  Wed Sep  9 13:20:25 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Wed, 9 Sep 2020 08:20:25 -0400
Subject: For consideration: JSON Feed
In-Reply-To: <20200908133052.115faa06@viridi>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team> <20200908133052.115faa06@viridi>
Message-ID: <CAEzvDCWbgCDS+v=Hp0O4X8YPi3_McNm9-xRXNUmj7XkrqX2qKQ@mail.gmail.com>

Nah, I don't think JSON is always better. I like XML, I just personally
find JSON easier to work with. It's no longer tied to the JS ecosystem,
python, PHP, go and other languages all have support for it in their
respective stdlibs.

On Tue, Sep 8, 2020 at 4:30 PM Tom <tgrom.automail at nuegia.net> wrote:

> It is true that JSON usually resolves to an object, but that makes it a
> bit more of a chore to deal with when using non-object-oriented
> languages. I'm not sure why you had a difficult time writing XML
> parsers, but it shouldn't be too different from something along the
> lines of var = $root->array[n]->post;. I don't feel too strongly either
> way, but I do feel that JSON being so much better than XML is largely
> overhyped and while there are extreme edge-cases where some more
> specialized interchange format could be more efficient than XML often
> times there is just not that huge of a difference to warrant going in a
> completely new direction and leaving behind decades of development into
> XML based tools. To me the XML vs JSON argument is a lot like
> bikeshedding, and I'd go with XML because it's what we already have and
> doesn't have problems with non-javascript langs.
>
> But if we really want to drag the XML vs JSON bikeshed all the way out,
> might as well use an existing bikeshed blog than start up a new one.
>
> This is linked to from XMPP.org myths & legends
>
> https://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html
> It explores the XML vs JSON debate in the most painstaking through
> detail.
>
>
> Abstract
>
> We all know that XML is "fat" and JSON is the "thinner", "faster",
> "smaller", "better" markup. We know this to be true because we've been
> told it over and over. It's "obvious" and "inherently true" because XML
> has redundant end tags, namespaces, entities and other extra "pounds of
> fat" that JSON doesn't have. But where is the science supporting this?
> What are the facts and what is myth? When people make design and
> architecture decisions it should be supported by facts not speculation.
> In this paper I show the results of an ongoing series of real world
> tests of Markup performance in browsers across a wide variety of
> devices, browsers and operating systems and attempt to quantify markup
> performance with experimental results and maybe trim the fat myth one
> calorie at a time.
>
> --
>  _________________________________________
> / There's no such thing as pure pleasure; \
> \ some anxiety always goes with it.       /
>  -----------------------------------------
> \
>  \
>    /\   /\
>   //\\_//\\     ____
>   \_     _/    /   /
>    / * * \    /^^^]
>    \_\O/_/    [   ]
>     /   \_    [   /
>     \     \_  /  /
>      [ [ /  \/ _/
>     _[ [ \  /_/
>


-- 
? <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200909/eae2a802/attachment.htm>

From mbays at sdf.org  Wed Sep  9 18:38:56 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Wed, 9 Sep 2020 19:38:56 +0200
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <87r1rdjqc0.fsf@idiomdrottning.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
Message-ID: <20200909173856.xjqha43dru34fh2w@localhost>

* Monday, 2020-09-07 at 22:15 +0200 - Sandra Snan <sandra.snan at idiomdrottning.org>:

>This feels like the "hot comment" antipattern. Codifying a part of the
>language that was meant for humans.
>http://wiki.c2.com/?HotComments

Yes. IIUC, gemtext deliberately avoided having a comment line type in 
order to avoid this problem. It was designed to be non-extensible. But 
preformatting toggle lines -- both the opening ones we're talking about 
here, and (to my mind even more worryingly) the closing ones -- seem to 
have ended up as potential extensibility hooks anyway, because most 
clients ignore any data there. (I haven't researched this properly, but 
I checked that at least Amfora, AV-98, and Bombadillo ignore it by 
default.)

So, with apologies for hijacking this thread with something totally 
opposed to its original idea, I'd like to encourage client authors to 
close this extensibility hole by not suppressing text after the "```" in 
preformatting toggle lines.

For the opening line that means displaying the alt text by default 
somehow. Even if the alt text is primarily intended for screenreaders, 
it could well be interesting to visual readers.

For the closing line, the spec says
> Any text following the leading "```" of a preformat toggle line which 
> toggles preformatted mode off MUST be ignored by clients.
I believe the intention is that having text there is an error (though 
this could definitely be made clearer). So I suggest that when a client 
encounters some text there, it displays some sort of (unobtrusive, but 
not too unobtrusive) warning indicating that there is an error in the 
gemtext. I know that with html it's traditional for renderers to be 
forgiving about syntax errors, but since this and invalid uris are the 
only ways gemtext can be invalid, I think it makes sense to be strict. 
If most clients just ignore the error and suppress the extra text, one 
day people will start using it as an extension mechanism, e.g. embedding 
base64-encoded images.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200909/e397a6a3/attachment.sig>

From gmym at coopdot.com  Wed Sep  9 20:37:46 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Wed, 9 Sep 2020 21:37:46 +0200
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200909173856.xjqha43dru34fh2w@localhost>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
Message-ID: <CAObwWNjMmwBYjRNjo7WB5tVBx5C48+DjeS=PueNoYLVQOfnvCA@mail.gmail.com>

<mbays at sdf.org> wrote:

> If most clients just ignore the error and suppress the extra text, one
> day people will start using it as an extension mechanism, e.g. embedding
> base64-encoded images.
>

Or something like the end of this:
https://lists.orbitalfox.eu/archives/gemini/2020/000930.html

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200909/a6f26d84/attachment.htm>

From paper at tilde.institute  Wed Sep  9 21:02:14 2020
From: paper at tilde.institute (Paper)
Date: Wed, 9 Sep 2020 16:02:14 -0400
Subject: Escaping Gemtext
Message-ID: <20200909200214.seldjupsqkj5jtxq@tilde.institute>

I am building a feed reader, so I am outputting plain text which can
contain some gemtext markup. I want to print it, but the client
shouldn't consider it a gemini markup. I could return "text/plain", but
I need some gemini formatting in the same page. After some discussion on
IRC yesterday, we found three approaches:

1. putting preformatting toggle lines before and after the user input
```
user input
```
- 10 more characters for each line (6 normal characters + 2x\r + 2x\n)
- if user inputs ```, all content under it will have preformatting toggle
  reversed
+ supported in all clients

2. putting a single space in front of the user input
 user input
+ only 1 line
+ supported in all clients
- shifts the entire user input one character to the right

3. putting a single unicode invisible space in front of the user input
?user input
+ doesn't change the horizontal position of the text
- I am not sure what clients without support for outputting UTF-8 text
  will do with it

For now, I think the second option is best for me, am I missing some
options?

Paper

From tgrom.automail at nuegia.net  Wed Sep  9 21:10:27 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Wed, 9 Sep 2020 13:10:27 -0700
Subject: For consideration: JSON Feed
In-Reply-To: <CAEzvDCWbgCDS+v=Hp0O4X8YPi3_McNm9-xRXNUmj7XkrqX2qKQ@mail.gmail.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team>
 <20200908133052.115faa06@viridi>
 <CAEzvDCWbgCDS+v=Hp0O4X8YPi3_McNm9-xRXNUmj7XkrqX2qKQ@mail.gmail.com>
Message-ID: <20200909131027.3823a69a@viridi>

On Wed, 9 Sep 2020 08:20:25 -0400
"A. E. Spencer-Reed" <easrng at gmail.com> wrote:

> Nah, I don't think JSON is always better. I like XML, I just
> personally find JSON easier to work with. It's no longer tied to the
> JS ecosystem, python, PHP, go and other languages all have support
> for it in their respective stdlibs.
Sure, I know that. And yes it's pretty easy to find a JSON library for
many programming langs as well. I'm just saying that JSON doesn't as
cleanly map to language variable types for non object-oriented languages
than XML does.


-- 
 ________________________________________ 
/ There are three reasons for becoming a \
| writer: the first is that you need the |
| money; the second that you have        |
| something to say that you think the    |
| world should know; the third is that   |
| you can't think what to do with the    |
| long winter evenings.                  |
|                                        |
\ -- Quentin Crisp                       /
 ---------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

From paper at tilde.institute  Wed Sep  9 21:17:43 2020
From: paper at tilde.institute (Paper)
Date: Wed, 9 Sep 2020 16:17:43 -0400
Subject: Unadorned Gemtext instead of syndication formats
In-Reply-To: <20200908173157.GG2239112@tilde.team>
References: <20200908173157.GG2239112@tilde.team>
Message-ID: <20200909201743.r53nrvaqczss3c2n@tilde.institute>

I am an author of a feed reader and I thought about implementing this
after I read this, but there are some problems:

How should my feed reader behave if there are links to different paths
on the page? I think I should reject all links from a different domain
and from a different protocol, but there could be a link to the same
domain, but to a different path.

=> / back
=> /gemlog/1/ post 1
=> /gemlog/2/ post 2
=> /contact/ contact to me

Here, it is visible which ones are the blog entries and which ones are
something else, but a program would have to guess. I don't think it
would be a good idea to hardcode that everything with gemlog in the path
is a feed item, that would cause too much confusion. Also, different
clients would behave differently adding to the confusion.

It is a great idea, but I think we could instead write a script or a
cli-program which would output Atom/RSS/Json feed for a gemini URL
given. This program would do the neccessary guessing and parsing and
output something that can be understood by all RSS libraries and
clients. Some clients I know support running a command to get a feed.

Or we could just use gemfeed to generate Atom for us.

From idf31 at memeware.net  Wed Sep  9 22:11:12 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Thu, 10 Sep 2020 00:11:12 +0300
Subject: [ANN] Draft for kind-of a Gemini Fediverse.
Message-ID: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>

I have recently started writing a protocol that could be used for 
distributing gemini content among different servers. The final idea 
would be that people could share information in a distributed manner. 
You can find more about it here:

gemini://idf.looting.uk/capslog/invis.gemini

From luke at marmaladefoo.com  Wed Sep  9 22:41:12 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Wed, 09 Sep 2020 22:41:12 +0100
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200909173856.xjqha43dru34fh2w@localhost>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
Message-ID: <5F594BF8.7070904@marmaladefoo.com>



On 09-Sep-2020 18:38, mbays at sdf.org wrote:
>
> So, with apologies for hijacking this thread with something totally 
> opposed to its original idea, I'd like to encourage client authors to 
> close this extensibility hole by not suppressing text after the "```" 
> in preformatting toggle lines.

As far as I can see, the spec seems clear enough on this: "5.4.3: Any 
line whose first three characters are "```" (i.e. three consecutive back 
ticks with no leading whitespace) are preformatted toggle lines. These 
lines should NOT be included in the rendered output shown to the user."

  - Luke

From sean at conman.org  Wed Sep  9 23:22:45 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 9 Sep 2020 18:22:45 -0400
Subject: For consideration: JSON Feed
In-Reply-To: <20200909131027.3823a69a@viridi>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team> <20200908133052.115faa06@viridi>
 <CAEzvDCWbgCDS+v=Hp0O4X8YPi3_McNm9-xRXNUmj7XkrqX2qKQ@mail.gmail.com>
 <20200909131027.3823a69a@viridi>
Message-ID: <20200909222245.GA19614@brevard.conman.org>

It was thus said that the Great Tom once stated:
> 
> Sure, I know that. And yes it's pretty easy to find a JSON library for
> many programming langs as well. I'm just saying that JSON doesn't as
> cleanly map to language variable types for non object-oriented languages
> than XML does.

  I'm not sure what you mean by that---I can see writing a JSON library for
a dynamic langauge easier than a non-dynamic one (say, Lua vs. C) but I
don't see what OOP has to do with it.

  -spc


From leveck at leveck.us  Thu Sep 10 00:01:16 2020
From: leveck at leveck.us (Mr. Leveck)
Date: Wed, 9 Sep 2020 17:01:16 -0600
Subject: Gemini => HTTP Proxy image choking
In-Reply-To: <20200909222245.GA19614@brevard.conman.org>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team> <20200908133052.115faa06@viridi>
 <CAEzvDCWbgCDS+v=Hp0O4X8YPi3_McNm9-xRXNUmj7XkrqX2qKQ@mail.gmail.com>
 <20200909131027.3823a69a@viridi> <20200909222245.GA19614@brevard.conman.org>
Message-ID: <1a913ae7-a610-a5a1-fe1b-2e78698d35b1@leveck.us>

Greetings All!

My www site has for sometime been displaying a homespun gopher proxy 
(IE: my website displays my gopherhole). Since I recently installed a 
gemini server on my home network, I wanted to expand my proxy to gemini 
too. This is complete: https://leveck.us/gemini/1436.ninja/

I am having issues, however. With the gopher proxy, I hand binary files 
over to curl via php after sending the appropriate header. Curl doesn't 
currently support gemini, and I have been chasing my tail on getting 
images (and binary files such as my RPoD Palm OS Software Horde) to work 
with my proxy.

Anyone got ideas?

Here is the networky portion of the proxy source:
28  //Gemini Protocol Code 
 
             29  //Nathaniel Leveck September 2020 
 

30  $host = $host; 
 
             31  $port = 1965; 
 
                          32  $cert = '/var/www/cert/cert.pem'; 
 
                                       33  $context = 
stream_context_create(); 
                                                                      34 
  stream_context_set_option($context, 'ssl', 'local_cert', $cert); 
 

35  stream_context_set_option($context, 'ssl', 'verify_peer', false); 
 

36  stream_context_set_option($context, 'ssl', 'verify_peer_name', 
false); 

37  stream_context_set_option($context, 'ssl', 'allow_self_signed', 
true); 

38  $socket = stream_socket_client('ssl://'.$host.':'.$port, $error, 
$errorString, 2, 

39  STREAM_CLIENT_CONNECT, $context); 
 
             40  fwrite($socket, "gemini://" . $url . "\r\n"); 
 
                          41  fread($socket,8192); //disregard the 
status + meta 
 
  42  $content = fread($socket,8192000); //read a suitably large number 
of bytes

fread, I assume, is my issue. socketread showed me no love...

-- 
jynx
gopher://1436.ninja
gemini://1436.ninja
https://leveck.us

From leveck at leveck.us  Thu Sep 10 00:08:12 2020
From: leveck at leveck.us (Mr. Leveck)
Date: Wed, 9 Sep 2020 17:08:12 -0600
Subject: Gemini => HTTP Proxy image choking
In-Reply-To: <1a913ae7-a610-a5a1-fe1b-2e78698d35b1@leveck.us>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <20200907023017.GC2239112@tilde.team> <20200908133052.115faa06@viridi>
 <CAEzvDCWbgCDS+v=Hp0O4X8YPi3_McNm9-xRXNUmj7XkrqX2qKQ@mail.gmail.com>
 <20200909131027.3823a69a@viridi> <20200909222245.GA19614@brevard.conman.org>
 <1a913ae7-a610-a5a1-fe1b-2e78698d35b1@leveck.us>
Message-ID: <3835fe12-6b10-03a0-3091-608e42f34184@leveck.us>

On 9/9/20 5:01 PM, Mr. Leveck wrote:
> Greetings All!
> 
> My www site has for sometime been displaying a homespun gopher proxy 
> (IE: my website displays my gopherhole). Since I recently installed a 
> gemini server on my home network, I wanted to expand my proxy to gemini 
> too. This is complete: https://leveck.us/gemini/1436.ninja/
> 
> I am having issues, however. With the gopher proxy, I hand binary files 
> over to curl via php after sending the appropriate header. Curl doesn't 
> currently support gemini, and I have been chasing my tail on getting 
> images (and binary files such as my RPoD Palm OS Software Horde) to work 
> with my proxy.
> 
> Anyone got ideas?
> 
> Here is the networky portion of the proxy source:
> 28? //Gemini Protocol Code
> 29? //Nathaniel Leveck September 2020
> 30? $host = $host;
> 31? $port = 1965;
> 32? $cert = '/var/www/cert/cert.pem';
> 33? $context = stream_context_create(); 
> 34  stream_context_set_option($context, 'ssl', 'local_cert', $cert);
> 35? stream_context_set_option($context, 'ssl', 'verify_peer', false);
> 36? stream_context_set_option($context, 'ssl', 'verify_peer_name', false);
> 37? stream_context_set_option($context, 'ssl', 'allow_self_signed', true);
> 38? $socket = stream_socket_client('ssl://'.$host.':'.$port, $error, $errorString, 2,
> 39? STREAM_CLIENT_CONNECT, $context);
> 40? fwrite($socket, "gemini://" . $url . "\r\n");
> 41? fread($socket,8192); //disregard the status + meta
> 42? $content = fread($socket,8192000); //read a suitably large number of bytes
> 
> fread, I assume, is my issue. socketread showed me no love...
> 

The code was ill formatted. How about a retry?

-- 
jynx

From easeout at tilde.team  Thu Sep 10 00:28:14 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Wed, 9 Sep 2020 19:28:14 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F594BF8.7070904@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
Message-ID: <20200909232814.GB1964344@tilde.team>

On Wed, Sep 09, 2020 at 10:41:12PM +0100, Luke Emmet wrote:
> 
> 
> On 09-Sep-2020 18:38, mbays at sdf.org wrote:
> > 
> > So, with apologies for hijacking this thread with something totally
> > opposed to its original idea, I'd like to encourage client authors to
> > close this extensibility hole by not suppressing text after the "```" in
> > preformatting toggle lines.
> 
> As far as I can see, the spec seems clear enough on this: "5.4.3: Any line
> whose first three characters are "```" (i.e. three consecutive back ticks
> with no leading whitespace) are preformatted toggle lines. These lines
> should NOT be included in the rendered output shown to the user."

This is an interesting detail: 5.4.3 goes on to say,

> Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine.

So on one hand, alt text is not to be included in the rendered output of
the preformat block, but alt text is recommended as alternative output
for the preformat block, when the usual rendered output is not useful to
    the user.

I think that means clients should probably hide alt text normally, but
to make use of it, might have a way to reveal it. Tooltips or an alt
text visibility toggle function come to mind. Screen readers would want
to read alt text when focusing the preformat block.

From easeout at tilde.team  Thu Sep 10 00:54:12 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Wed, 9 Sep 2020 19:54:12 -0400
Subject: Unadorned Gemtext instead of syndication formats
In-Reply-To: <20200909201743.r53nrvaqczss3c2n@tilde.institute>
References: <20200908173157.GG2239112@tilde.team>
 <20200909201743.r53nrvaqczss3c2n@tilde.institute>
Message-ID: <20200909235412.GC1964344@tilde.team>

On Wed, Sep 09, 2020 at 04:17:43PM -0400, Paper wrote:
> I am an author of a feed reader and I thought about implementing this
> after I read this, but there are some problems:
> 
> How should my feed reader behave if there are links to different paths
> on the page? I think I should reject all links from a different domain
> and from a different protocol, but there could be a link to the same
> domain, but to a different path.
> 
> => / back
> => /gemlog/1/ post 1
> => /gemlog/2/ post 2
> => /contact/ contact to me
> 
> Here, it is visible which ones are the blog entries and which ones are
> something else, but a program would have to guess. I don't think it
> would be a good idea to hardcode that everything with gemlog in the path
> is a feed item, that would cause too much confusion. Also, different
> clients would behave differently adding to the confusion.

I'm suggesting only a bare bones, dead simple, worse-is-better,
get-what-you-can-with-what's-on-hand version of syndication. I would
just collect all links on the page and not devise an intelligent way to
filter them, as if we were scraping web pages for only the good stuff. I
agree that would lead to divergent behavior among clients.

So let it be just the simplest possible implementation. The upgrade path
to a nicer experience would be for the author to publish RSS or Atom in
order to select just the right links for readers.

> It is a great idea, but I think we could instead write a script or a
> cli-program which would output Atom/RSS/Json feed for a gemini URL
> given. This program would do the neccessary guessing and parsing and
> output something that can be understood by all RSS libraries and
> clients. Some clients I know support running a command to get a feed.
> 
> Or we could just use gemfeed to generate Atom for us.

Generating Atom et al is the kind of thing many Gemini authors are
already doing (like me!), and those folks certainly don't need to worry
about this idea. When a feed is offered, I think users will prefer to
use it.

But if this takes off, new authors who haven't taken the step of
generating a feed will be more tied into the conversation already. For
instance, I was not going to get any blog replies or readership until I
did the work to publish Atom so I could then submit to CAPCOM. An 80%
solution would have helped me get engaged as a newcomer. It would also
help future users as Gemini's audience slowly broadens to include a less
technical crowd.

One more benefit for us early adopters: If we lower the barrier to entry
for others, it will mean more content for us to read and engage with.

From kevin at susa.net  Thu Sep 10 00:59:55 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Thu, 10 Sep 2020 00:59:55 +0100
Subject: [ANN] Draft for kind-of a Gemini Fediverse.
In-Reply-To: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
References: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
Message-ID: <CAPk6LxSTw3kuC=vRhiTWOcrYbODQoz0av0Ckd0jOhdLRiRKqBw@mail.gmail.com>

It would be really helpful if you could mock up feeds for modules A, B, and
C, where A is joining, B & C are existing, and A attaches to B.

In particular, the feed content at the start, for A, B, and C, along with
artefacts produced during and after merge. This could be done dynamically
with actual code, or just visually with before/after file contents.

I think there's a lot of potential in the concept. Discovery is, in my
opinion, the biggest issue of the Internet, and it's been woefully
neglected (probably because algorithms stepped in and distracted us with
ruthless efficiency!)

While aggregators and search engines are good, they ultimately present us
with lists of stuff that's often only loosely related. This can be fun in
itself, but there's lots more we could innovate on.

Kevin


On Wed, 9 Sep 2020 at 22:11, <idf31 at memeware.net> wrote:

> I have recently started writing a protocol that could be used for
> distributing gemini content among different servers. The final idea
> would be that people could share information in a distributed manner.
> You can find more about it here:
>
> gemini://idf.looting.uk/capslog/invis.gemini
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/83dfd02d/attachment.htm>

From easeout at tilde.team  Thu Sep 10 01:04:58 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Wed, 9 Sep 2020 20:04:58 -0400
Subject: Unadorned Gemtext instead of syndication formats
In-Reply-To: <20200909235412.GC1964344@tilde.team>
References: <20200908173157.GG2239112@tilde.team>
 <20200909201743.r53nrvaqczss3c2n@tilde.institute>
 <20200909235412.GC1964344@tilde.team>
Message-ID: <20200910000458.GD1964344@tilde.team>

On Wed, Sep 09, 2020 at 07:54:12PM -0400, easeout at tilde.team wrote:

> I'm suggesting only a bare bones, dead simple, worse-is-better,
> get-what-you-can-with-what's-on-hand version of syndication. I would
> just collect all links on the page and not devise an intelligent way to
> filter them, as if we were scraping web pages for only the good stuff. I
> agree that would lead to divergent behavior among clients.

In hindsight I think I was unclear, so let me try to restate:

I would just collect every link on the page. I would not devise an
intelligent way to filter them. That would be like scraping web pages
with guesses and approximations, which we don't need to do. I would not
want clients to compete on differentiated Gemtext-subscribing behavior
when RSS / Atom are the right answer for an upgrade path.

From list at gkbrk.com  Thu Sep 10 06:39:52 2020
From: list at gkbrk.com (Leo)
Date: Thu, 10 Sep 2020 08:39:52 +0300
Subject: [ANN] Draft for kind-of a Gemini Fediverse.
In-Reply-To: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
References: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
Message-ID: <2be03b02-f400-4747-b8da-59601b1c63b9@www.fastmail.com>

twtxt seems more aligned with the mindset of Gemini, and is already supported by gemini servers and clients.

Can we adapt twtxt instead of reinventing the wheel, I don't think it gets simpler than that anyway. Just a text file with one line for tweets.

One advantage is that only the clients are involved and if I don't check your feed, there is no cost. Or is the plan for the servers to be more actively involved like Fedi?

--
Leo

From sandra.snan at idiomdrottning.org  Thu Sep 10 07:32:44 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 10 Sep 2020 08:32:44 +0200
Subject: Escaping Gemtext
In-Reply-To: <20200909200214.seldjupsqkj5jtxq@tilde.institute>
References: <20200909200214.seldjupsqkj5jtxq@tilde.institute>
Message-ID: <87bliei1kj.fsf@idiomdrottning.org>

If you go to four spaces you'll become compatible with markdown ? not
necessarily worth it! Don't shoot the messenger on this one ?

Paper <paper at tilde.institute> writes:

> I am building a feed reader, so I am outputting plain text which can
> contain some gemtext markup. I want to print it, but the client
> shouldn't consider it a gemini markup. I could return "text/plain", but
> I need some gemini formatting in the same page. After some discussion on
> IRC yesterday, we found three approaches:
>
> 1. putting preformatting toggle lines before and after the user input
> ```
> user input
> ```
> - 10 more characters for each line (6 normal characters + 2x\r + 2x\n)
> - if user inputs ```, all content under it will have preformatting toggle
>   reversed
> + supported in all clients
>
> 2. putting a single space in front of the user input
>  user input
> + only 1 line
> + supported in all clients
> - shifts the entire user input one character to the right
>
> 3. putting a single unicode invisible space in front of the user input
> ?user input
> + doesn't change the horizontal position of the text
> - I am not sure what clients without support for outputting UTF-8 text
>   will do with it
>
> For now, I think the second option is best for me, am I missing some
> options?
>
> Paper

From mbays at sdf.org  Thu Sep 10 07:40:07 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Thu, 10 Sep 2020 08:40:07 +0200
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F594BF8.7070904@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
Message-ID: <20200910064007.gytc42v4snepgmix@localhost>

* Wednesday, 2020-09-09 at 22:41 +0100 - Luke Emmet <luke at marmaladefoo.com>:

> On 09-Sep-2020 18:38, mbays at sdf.org wrote:
>> So, with apologies for hijacking this thread with something totally 
>> opposed to its original idea, I'd like to encourage client authors to 
>> close this extensibility hole by not suppressing text after the "```" 
>> in preformatting toggle lines.
> 
> As far as I can see, the spec seems clear enough on this: "5.4.3: Any line 
> whose first three characters are "```" (i.e. three consecutive back ticks 
> with no leading whitespace) are preformatted toggle lines. These lines 
> should NOT be included in the rendered output shown to the user."

That passage predates the later additions to the spec in the same 
section about what to do with text on these lines. I guess the intention 
was to make it clear that clients aren't expected to actually print 
"```". I don't think it should be read as ruling out printing the alt 
text.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/d603ae3c/attachment.sig>

From kevin at susa.net  Thu Sep 10 09:11:40 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Thu, 10 Sep 2020 09:11:40 +0100
Subject: [ANN] Draft for kind-of a Gemini Fediverse.
In-Reply-To: <2be03b02-f400-4747-b8da-59601b1c63b9@www.fastmail.com>
References: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
 <2be03b02-f400-4747-b8da-59601b1c63b9@www.fastmail.com>
Message-ID: <CAPk6LxSi2nSQc8Pgvrm0GRaB=TiuDdXmo3avO_Pe4zXpBvN39w@mail.gmail.com>

I'd argue that, for the moment at least, the more wheels being invented,
the better! As I see it, all current wheels are square (ok, maybe some are
octogonal).

What we have is many services copying Twitter and Facebook, yet
communication is a very nuanced thing - something they have taken and
distilled, genetically modified, mass-produced, and used to flood the
market.

Yet, real human communication is truly nuanced. Consider the difference
between a joke well told vs badly told, sometimes it's not even the words,
it's just the timing, or intonation. There's a lot to explore to move from
being merely 'engaging' to 'enriching'.

Kevin


On Thu, 10 Sep 2020 at 06:40, Leo <list at gkbrk.com> wrote:

> twtxt seems more aligned with the mindset of Gemini, and is already
> supported by gemini servers and clients.
>
> Can we adapt twtxt instead of reinventing the wheel, I don't think it gets
> simpler than that anyway. Just a text file with one line for tweets.
>
> One advantage is that only the clients are involved and if I don't check
> your feed, there is no cost. Or is the plan for the servers to be more
> actively involved like Fedi?
>
> --
> Leo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/bd8f6b85/attachment.htm>

From mailinglists at ngalt.com  Thu Sep 10 09:13:01 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 10 Sep 2020 01:13:01 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200909232814.GB1964344@tilde.team>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
Message-ID: <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>



> On Sep 9, 2020, at 4:28 PM, easeout at tilde.team wrote:
> 
> On Wed, Sep 09, 2020 at 10:41:12PM +0100, Luke Emmet wrote:
>> 
[snip]
>> Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine.
> 
> So on one hand, alt text is not to be included in the rendered output of
> the preformat block, but alt text is recommended as alternative output
> for the preformat block, when the usual rendered output is not useful to
>    the user.
> 
> I think that means clients should probably hide alt text normally, but
> to make use of it, might have a way to reveal it. Tooltips [?]

I strongly recommend against this. The W3C has been trying to get HTML authors and browser makers to _only_ display, in tooltips, text in `title` attributes.

Previously, HTML authors would write `alt` attribute values intending them to be read by sighted HTML readers who can already see the image. If we encourage Gemini-browser authors to put Gemini Alt Text in some kind of tooltip visible to people who can already see the ASCII art or code or whatever, then all but the most accessibility-conscious authors will stuff easter-egg-type text in Gemini Alt Text, similar to the `title` attribute contents on each XKCD comic strip.

(You might be thinking ?well, what about that Markdown meme where people write ?```javascript? to start off a JavaScript code block, with the idea that a syntax highlighter will read it and colorize the output?? I?d say that yes, that sort of thing _might_ be an imposition to blind users, but that sort of text is mercifully short and gives them a better idea of when they might want to hit a ?skip just past the end of the preformatted-text block? keystroke combination and get on with the rest of the page.)

From idf31 at memeware.net  Thu Sep 10 10:05:06 2020
From: idf31 at memeware.net (idf31 at memeware.net)
Date: Thu, 10 Sep 2020 12:05:06 +0300
Subject: [ANN] Draft for kind-of a Gemini Fediverse.
In-Reply-To: <2be03b02-f400-4747-b8da-59601b1c63b9@www.fastmail.com>
References: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
 <2be03b02-f400-4747-b8da-59601b1c63b9@www.fastmail.com>
Message-ID: <0e7881fcd2267477f3153ac312740b74@memeware.net>

On 2020-09-10 08:39, Leo wrote:
> twtxt seems more aligned with the mindset of Gemini, and is already
> supported by gemini servers and clients.
> 
> Can we adapt twtxt instead of reinventing the wheel, I don't think it
> gets simpler than that anyway. Just a text file with one line for
> tweets.
> 
> One advantage is that only the clients are involved and if I don't
> check your feed, there is no cost. Or is the plan for the servers to
> be more actively involved like Fedi?
> 
> --
> Leo

It seems I haven't really made the intent of the protocol clear, I 
apologise.
InVis is not an attempt to reinvent social media like twitter or 
facebook or whatever. And I agree with you that there are a lot of 
clones for these things. In more general terms, InVis should provide a 
way for Gemini servers to mirror each other's content. It should provide 
a way for Geminauts to  make their content available to a wider space, 
and to provide a nice way of archiving as a side-effect.

I think this could increase the discoverability of content, since a 
reader would be presented with a much wider library of content from 
other people than just the people that run that one server the reader 
stumbled upon. All that is needed to read an InVis module is a Gemini 
client, since all InVis would do is to mirror gemtext files between 
servers :)

Again, I apologise for the misunderstanding, I will try to update the 
draft soon.

From mailinglists at ngalt.com  Thu Sep 10 10:58:07 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 10 Sep 2020 02:58:07 -0700
Subject: [ANN] gemini.sublime-syntax
Message-ID: <04201570-464E-4134-BEC8-B45531695E44@ngalt.com>

I wanted bat(1) to colorize Gemini files nicely, so I made this.

Pull requests and bug reports welcome.

https://github.com/adiabatic/gemini.sublime-syntax

From sysop at 1436.ninja  Thu Sep 10 14:08:47 2020
From: sysop at 1436.ninja (Mr. Leveck)
Date: Thu, 10 Sep 2020 08:08:47 -0500
Subject: Gemini proxy image display
Message-ID: <1700601599743094@sas1-55829ddbd171.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/a262a090/attachment.htm>

From matt at going-flying.com  Thu Sep 10 15:58:07 2020
From: matt at going-flying.com (Matthew Ernisse)
Date: Thu, 10 Sep 2020 10:58:07 -0400
Subject: For consideration: JSON Feed
In-Reply-To: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
Message-ID: <20200910145807.GA1226@ub3rgeek.net>

On Sun, Sep 06, 2020 at 05:53:45PM -0700, mailinglists at ngalt.com said unto me:
> I've been seeing people talk about syndication formats how we'd 
> like something a little less annoying than RSS and Atom.
> 
> I'd like to suggest JSON Feed as a possible alternative:

Personally I'm happy with Atom and RSS as the defacto standards.

As background, I use tt-rss as a feed reader and it's pretty trivial to
simply subscribe to Atom/RSS feeds using a proxy 
(eg: https://proxy.vulpes.one/gemini/going-flying.com/~mernisse/atom.xml
gets my capsule's glog feed) or whipping up your own feed proxy.  I feel
that existing syndication formats are sufficiently mature, well supported
and flexible.

Since the user-agent side is the greenfield I'm more excited to see what
sort of text based feed readers will appear.

--Matt

-- 
Matthew Ernisse
matt at going-flying.com
http://www.going-flying.com/

From kevin at susa.net  Thu Sep 10 16:12:15 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Thu, 10 Sep 2020 16:12:15 +0100
Subject: Gemini proxy image display
In-Reply-To: <1700601599743094@sas1-55829ddbd171.qloud-c.yandex.net>
References: <1700601599743094@sas1-55829ddbd171.qloud-c.yandex.net>
Message-ID: <CAPk6LxS24X3mt1wa7aXSxaZ8YfDqypDAbdNZvS82Xh7CFU7+qQ@mail.gmail.com>

Do you mean to throw away the first 8k of content bytes?


Sent from phone

On Thu, 10 Sep 2020, 14:14 Mr. Leveck, <sysop at 1436.ninja> wrote:

> [repost in new thread]
>
> Greetings All!
>
>  My www site has for sometime been displaying a homespun gopher proxy
>  (IE: my website displays my gopherhole). Since I recently installed a
>  gemini server on my home network, I wanted to expand my proxy to gemini
>  too. This is complete: https://leveck.us/gemini/1436.ninja/
>
>  I am having issues, however. With the gopher proxy, I hand binary files
>  over to curl via php after sending the appropriate header. Curl doesn't
>  currently support gemini, and I have been chasing my tail on getting
>  images (and binary files such as my RPoD Palm OS Software Horde) to work
>  with my proxy.
>
>  Anyone got ideas?
>
>  Here is the networky portion of the proxy source (line #s from vim):
>  28  //Gemini Protocol Code
>  29  //Nathaniel Leveck September 2020
>  30  $host = $host;
>  31  $port = 1965;
>  32  $cert = '/var/www/cert/cert.pem';
>  33  $context = stream_context_create();
>  34 stream_context_set_option($context, 'ssl', 'local_cert', $cert);
>  35  stream_context_set_option($context, 'ssl', 'verify_peer', false);
>  36  stream_context_set_option($context, 'ssl', 'verify_peer_name', false);
>  37  stream_context_set_option($context, 'ssl', 'allow_self_signed', true);
>  38  $socket = stream_socket_client('ssl://'.$host.':'.$port, $error,
> $errorString, 2,
>  39  STREAM_CLIENT_CONNECT, $context);
>  40  fwrite($socket, "gemini://" . $url . "\r\n");
>  41  fread($socket,8192); //disregard the status + meta
>  42  $content = fread($socket,8192000); //read a suitably large number of
> bytes
>
>  fread, I assume, is my issue. socketread showed me no love...
>
> --
> jynx
> gopher://1436.ninja
> gemini://1436.ninja
> https://leveck.us
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/782f980e/attachment.htm>

From leveck at leveck.us  Thu Sep 10 16:19:19 2020
From: leveck at leveck.us (Mr. Leveck)
Date: Thu, 10 Sep 2020 09:19:19 -0600
Subject: Gemini proxy image display
In-Reply-To: <CAPk6LxS24X3mt1wa7aXSxaZ8YfDqypDAbdNZvS82Xh7CFU7+qQ@mail.gmail.com>
References: <1700601599743094@sas1-55829ddbd171.qloud-c.yandex.net>
 <CAPk6LxS24X3mt1wa7aXSxaZ8YfDqypDAbdNZvS82Xh7CFU7+qQ@mail.gmail.com>
Message-ID: <70d631f2-4a6e-04d0-6b21-d68ea350cd63@leveck.us>


On 9/10/20 9:12 AM, Kevin Sangeelee wrote:
> Do you mean to throw away the first 8k of content bytes?
> 
> 
> Sent from phone

Yes.

All this does is toss out the status and meta data. I could specify 8MB 
to toss out, and the result would be the same in PHP using this method.

This is alpha software. Later on I'll do something with the status and 
metadata, such as implement redirection, etc.

Right now, I just want to figure out binary files...

-- 
jynx
gopher://1436.ninja
gemini://1436.ninja
https://leveck.us

From cel at celehner.com  Thu Sep 10 16:28:06 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Thu, 10 Sep 2020 11:28:06 -0400
Subject: Gemini proxy image display
In-Reply-To: <70d631f2-4a6e-04d0-6b21-d68ea350cd63@leveck.us>
References: <1700601599743094@sas1-55829ddbd171.qloud-c.yandex.net>
 <CAPk6LxS24X3mt1wa7aXSxaZ8YfDqypDAbdNZvS82Xh7CFU7+qQ@mail.gmail.com>
 <70d631f2-4a6e-04d0-6b21-d68ea350cd63@leveck.us>
Message-ID: <20200910112806.51265697@celehner.com>

Hi Mr. Leveck,

On Thu, 10 Sep 2020 09:19:19 -0600
"Mr. Leveck" <leveck at leveck.us> wrote:

> On 9/10/20 9:12 AM, Kevin Sangeelee wrote:
> > Do you mean to throw away the first 8k of content bytes?
> > 
> > 
> > Sent from phone  
> 
> Yes.
> 
> All this does is toss out the status and meta data. I could specify
> 8MB to toss out, and the result would be the same in PHP using this

Perhaps you could use fgets($socket) instead, to read just the first line. The server might send the status + meta line in the same packet as the initial body data. In that case, reading just the first line with the buffered reader will save the rest of the body for later reading.

-- 
Regards,
Charles L.
gemini://celehner.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/9f1c7aaa/attachment.sig>

From leveck at leveck.us  Thu Sep 10 16:40:42 2020
From: leveck at leveck.us (Mr. Leveck)
Date: Thu, 10 Sep 2020 09:40:42 -0600
Subject: Gemini proxy image display
In-Reply-To: <20200910112806.51265697@celehner.com>
References: <1700601599743094@sas1-55829ddbd171.qloud-c.yandex.net>
 <CAPk6LxS24X3mt1wa7aXSxaZ8YfDqypDAbdNZvS82Xh7CFU7+qQ@mail.gmail.com>
 <70d631f2-4a6e-04d0-6b21-d68ea350cd63@leveck.us>
 <20200910112806.51265697@celehner.com>
Message-ID: <6e27f730-f09e-6e86-a84b-11bdb8d954dd@leveck.us>



On 9/10/20 9:28 AM, Charles E. Lehner wrote:
> Hi Mr. Leveck,
> 
> On Thu, 10 Sep 2020 09:19:19 -0600
> "Mr. Leveck" <leveck at leveck.us> wrote:
> 
>> On 9/10/20 9:12 AM, Kevin Sangeelee wrote:
>>> Do you mean to throw away the first 8k of content bytes?
>>>
>>>
>>> Sent from phone
>>
>> Yes.
>>
>> All this does is toss out the status and meta data. I could specify
>> 8MB to toss out, and the result would be the same in PHP using this
> 
> Perhaps you could use fgets($socket) instead, to read just the first line. The server might send the status + meta line in the same packet as the initial body data. In that case, reading just the first line with the buffered reader will save the rest of the body for later reading.
> 

I get all the content just fine...

I am looking for advice on serving binary files via my proxy.

-- 
jynx
gopher://1436.ninja
gemini://1436.ninja/
https://leveck.us

From alex at nytpu.com  Thu Sep 10 16:55:34 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Thu, 10 Sep 2020 09:55:34 -0600
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
Message-ID: <20200910155534.z7gml3adywayhqiw@GLaDOS>

>I strongly recommend against this. The W3C has been trying to get HTML
>authors and browser makers to _only_ display, in tooltips, text in
>`title` attributes.  Previously, HTML authors would write `alt`
>attribute values intending them to be read by sighted HTML readers who
>can already see the image.
I strongly agree. While I don't view the W3C's recommendations as the
gold standard of things gemini should look to emulate (EME anyone?), I
agree that if we make the alt text easily visible it will no longer be
accessibility text and will turn into a miscellaneous-purpose field.

>(You might be thinking ?well, what about that Markdown meme where
>people write ?```javascript? to start off a JavaScript code block, with
>the idea that a syntax highlighter will read it and colorize the
>output??
The original point of suggesting that it be displayed for all users was
to discourage turning text intended for humans into text intended for
machines anyways, but I believe an alternate solution other than
displaying it for everybody would still be preferable.

Rewriting that portion of the spec to emphasize that it is not to be
parsed in any way other than as natural language?  Maybe say that a
client *should be able to* completely replace the preformatted block
with the contents of the alt text without the document losing
significant meaning? That would work for ascii art and short code
snippets, but it might not be doable for longer code blocks.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://e-mail.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/70100d25/attachment-0001.sig>

From lambdatronic at disroot.org  Thu Sep 10 17:43:10 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Thu, 10 Sep 2020 12:43:10 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200910064007.gytc42v4snepgmix@localhost>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost>
Message-ID: <871rj9fuqp.fsf@disroot.org>

Just to throw another idea out there:

There has been some extended discussion now on the mailing list about a
conflict in machine-readable vs human-readable content being added after
the opening pre-formatting ``` characters. It seems that enough people
in the Gemini community see both of these kinds of information as
providing value, but the spec currently lacks a clear path forward for
differentiating between them.

Right now, anything written after the closing pre-formatting ``` chars
isn't being used as per the spec's instructions. I can't help but wonder
what would happen if we were able to put machine-readable instructions
(like "table", "image", "code:python") on the opening line (so that
clients could switch their line interpreter modes accordingly) and place
human-readable alt text (mainly for screen readers) on the closing line
(assuming the screen reader will probably just skip over the
pre-formatted block's contents anyway and then read the alt text if
provided).

I realize this would entail a fairly significant change to the spec, but
it seems - at least to me - to resolve the issue in a rather
straightforward fashion. If I'm missing something important here, please
let me know. I'm also interested in hearing anyone else's suggestions
for how to address this issue.

Onward Geminauts!
  Gary


mbays at sdf.org writes:

> * Wednesday, 2020-09-09 at 22:41 +0100 - Luke Emmet <luke at marmaladefoo.com>:
>
>> On 09-Sep-2020 18:38, mbays at sdf.org wrote:
>>> So, with apologies for hijacking this thread with something totally
>>> opposed to its original idea, I'd like to encourage client authors
>>> to close this extensibility hole by not suppressing text after the
>>> "```" in preformatting toggle lines.
>> As far as I can see, the spec seems clear enough on this: "5.4.3:
>> Any line whose first three characters are "```" (i.e. three
>> consecutive back ticks with no leading whitespace) are preformatted
>> toggle lines. These lines should NOT be included in the rendered
>> output shown to the user."
>
> That passage predates the later additions to the spec in the same
> section about what to do with text on these lines. I guess the
> intention was to make it clear that clients aren't expected to
> actually print "```". I don't think it should be read as ruling out
> printing the alt text.


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From easrng at gmail.com  Thu Sep 10 18:26:44 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Thu, 10 Sep 2020 13:26:44 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <871rj9fuqp.fsf@disroot.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost>
 <871rj9fuqp.fsf@disroot.org>
Message-ID: <CAEzvDCWYwUEYrA-8499SB-m3cCygbcK-V-KDZN=TEBtu0RGo=w@mail.gmail.com>

What if we use a human readable *and *machine parsable format, something
like "This is code in python. It does ..." or "This is a table from
/data.csv. It contains information about..." and parse it by using
something like /this\s+is\s+(?:an?\s+)?(\S+)\s+(in|of|from)\s+(\S+)\./i You
can then get structured data like what kind of data it contains while still
preserving it's use for assistive technologies.

On Thu, Sep 10, 2020 at 12:43 PM Gary Johnson <lambdatronic at disroot.org>
wrote:

> Just to throw another idea out there:
>
> There has been some extended discussion now on the mailing list about a
> conflict in machine-readable vs human-readable content being added after
> the opening pre-formatting ``` characters. It seems that enough people
> in the Gemini community see both of these kinds of information as
> providing value, but the spec currently lacks a clear path forward for
> differentiating between them.
>
> Right now, anything written after the closing pre-formatting ``` chars
> isn't being used as per the spec's instructions. I can't help but wonder
> what would happen if we were able to put machine-readable instructions
> (like "table", "image", "code:python") on the opening line (so that
> clients could switch their line interpreter modes accordingly) and place
> human-readable alt text (mainly for screen readers) on the closing line
> (assuming the screen reader will probably just skip over the
> pre-formatted block's contents anyway and then read the alt text if
> provided).
>
> I realize this would entail a fairly significant change to the spec, but
> it seems - at least to me - to resolve the issue in a rather
> straightforward fashion. If I'm missing something important here, please
> let me know. I'm also interested in hearing anyone else's suggestions
> for how to address this issue.
>
> Onward Geminauts!
>   Gary
>
>
> mbays at sdf.org writes:
>
> > * Wednesday, 2020-09-09 at 22:41 +0100 - Luke Emmet <
> luke at marmaladefoo.com>:
> >
> >> On 09-Sep-2020 18:38, mbays at sdf.org wrote:
> >>> So, with apologies for hijacking this thread with something totally
> >>> opposed to its original idea, I'd like to encourage client authors
> >>> to close this extensibility hole by not suppressing text after the
> >>> "```" in preformatting toggle lines.
> >> As far as I can see, the spec seems clear enough on this: "5.4.3:
> >> Any line whose first three characters are "```" (i.e. three
> >> consecutive back ticks with no leading whitespace) are preformatted
> >> toggle lines. These lines should NOT be included in the rendered
> >> output shown to the user."
> >
> > That passage predates the later additions to the spec in the same
> > section about what to do with text on these lines. I guess the
> > intention was to make it clear that clients aren't expected to
> > actually print "```". I don't think it should be read as ruling out
> > printing the alt text.
>
>
> --
> GPG Key ID: 7BC158ED
> Use `gpg --search-keys lambdatronic' to find me
> Protect yourself from surveillance: https://emailselfdefense.fsf.org
> =======================================================================
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
> Please avoid sending me MS-Office attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>


-- 
? <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/ffa376ac/attachment.htm>

From alex at gnu.org  Thu Sep 10 18:27:59 2020
From: alex at gnu.org (Alex Schroeder)
Date: Thu, 10 Sep 2020 19:27:59 +0200
Subject: Gemini proxy image display
In-Reply-To: <70d631f2-4a6e-04d0-6b21-d68ea350cd63@leveck.us>
Message-ID: <d216208f972c8d71670aa27da3e4cd70aa9b51db.camel@gnu.org>

On Thu Sep 10, 2020 at 11:19 AM CEST, Mr. Leveck wrote:
> On 9/10/20 9:12 AM, Kevin Sangeelee wrote:
> > Do you mean to throw away the first 8k of content bytes?
> 
> Yes.
> 
> All this does is toss out the status and meta data. I could specify
> 8MB
> to toss out, and the result would be the same in PHP using this
> method.

I'm thinking you're going to toss out 8K which is probably much more
than just the status and the meta data. fread is going to read past
the \r\n terminating the status and it'll keep reading... and then you
toss it all out. I think what you need to do is read everything, and
then search and toss all the bytes up to the first \n or something
like that.

Cheers
Alex



From leveck at leveck.us  Thu Sep 10 18:35:10 2020
From: leveck at leveck.us (Mr. Leveck)
Date: Thu, 10 Sep 2020 11:35:10 -0600
Subject: Gemini proxy image display
In-Reply-To: <d216208f972c8d71670aa27da3e4cd70aa9b51db.camel@gnu.org>
References: <d216208f972c8d71670aa27da3e4cd70aa9b51db.camel@gnu.org>
Message-ID: <c01479fd-c234-9191-de64-1f8966d4ddb8@leveck.us>



On 9/10/20 11:27 AM, Alex Schroeder wrote:

> I'm thinking you're going to toss out 8K which is probably much more
> than just the status and the meta data. fread is going to read past
> the \r\n terminating the status and it'll keep reading... and then you
> toss it all out. I think what you need to do is read everything, and
> then search and toss all the bytes up to the first \n or something
> like that.
> 
> Cheers
> Alex

One would think, but that is not the case. Since everyone is hung up on 
that instead of my actual query, I have captured that initial status and 
now display it on the top of gemini:// pages on the proxy. Prior to that 
I was 100% successful in capturing all the document content the proxy 
code was requesting. All I have done now is assigned it to a var named 
$status and print that in a displayed page header.

I am looking for advice on binary files. If anyone has any thoughts on 
that, it would be much appreciated.

-- 
jynx
gopher://1436.ninja
gemini://1436.ninja/
https://leveck.us

From cel at celehner.com  Thu Sep 10 18:38:27 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Thu, 10 Sep 2020 13:38:27 -0400
Subject: Gemini proxy image display
In-Reply-To: <c01479fd-c234-9191-de64-1f8966d4ddb8@leveck.us>
References: <d216208f972c8d71670aa27da3e4cd70aa9b51db.camel@gnu.org>
 <c01479fd-c234-9191-de64-1f8966d4ddb8@leveck.us>
Message-ID: <20200910133827.13f89aba@celehner.com>

Mr. Leveck,

I looked into it more, comparing this broken image:
https://leveck.us/gemini/1436.ninja/the_servers.png

with the good original:
gemini://1436.ninja/the_servers.png

The proxied one has this header "<!-- GEMINI! --><!-- 1436.ninja/the_servers.png --><!-- 192.168.0.45 -->". That breaks the image. Also, in the content at byte 24576 (0x6000), the files diverge. The proxied one seems to restart sending the PNG image there, with some bytes missing. Maybe a variable is incorrectly set in your code?

Charles

On Thu, 10 Sep 2020 11:35:10 -0600
"Mr. Leveck" <leveck at leveck.us> wrote:

> 
> 
> On 9/10/20 11:27 AM, Alex Schroeder wrote:
> 
> > I'm thinking you're going to toss out 8K which is probably much more
> > than just the status and the meta data. fread is going to read past
> > the \r\n terminating the status and it'll keep reading... and then
> > you toss it all out. I think what you need to do is read
> > everything, and then search and toss all the bytes up to the first
> > \n or something like that.
> > 
> > Cheers
> > Alex
> 
> One would think, but that is not the case. Since everyone is hung up
> on that instead of my actual query, I have captured that initial
> status and now display it on the top of gemini:// pages on the proxy.
> Prior to that I was 100% successful in capturing all the document
> content the proxy code was requesting. All I have done now is
> assigned it to a var named $status and print that in a displayed page
> header.
> 
> I am looking for advice on binary files. If anyone has any thoughts
> on that, it would be much appreciated.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/8baca035/attachment.sig>

From mbays at sdf.org  Thu Sep 10 18:47:03 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Thu, 10 Sep 2020 19:47:03 +0200
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200910155534.z7gml3adywayhqiw@GLaDOS>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
Message-ID: <20200910174703.ro5vnl6faaxrx422@localhost>

* Thursday, 2020-09-10 at 09:55 -0600 - Alex // nytpu <alex at nytpu.com>:

>>I strongly recommend against this. The W3C has been trying to get HTML 
>>authors and browser makers to _only_ display, in tooltips, text in 
>>`title` attributes.
>[...]if we make the alt text easily visible it will no longer be 
>accessibility text and will turn into a miscellaneous-purpose field.

Good point.

I guess it will be abused that way even if most clients offer no easy 
way to view it, as "easter egg" text for those who read the source. But 
yes, if the alt text is typically shown then this abuse could easily 
become normalised. So I retract my encouragement to always show alt 
text. Thanks for explaining my mistake!

How about if clients have an easily toggled switch between showing 
preformatted text and just showing alt text? I guess that would still 
lead to more easter-egging, but maybe not too much? It seems there's 
a tradeoff between discouraging inaccessible uses as human-readable 
text, and discouraging inaccessible uses as machine-readable text...

For the closing "```", I still think clients should enforce the rule 
that no further text on these lines is allowed.

But actually this suggests another possibility: adjust the spec to allow 
text on the closing line, and have it specifically interpreted as 
a subtitle to be rendered (however the client likes, e.g. centred). That 
could divert the pressure to misuse the alt text as a title, and would 
properly close the extensibility hole.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/8058774a/attachment-0001.sig>

From leveck at leveck.us  Thu Sep 10 18:50:02 2020
From: leveck at leveck.us (Mr. Leveck)
Date: Thu, 10 Sep 2020 11:50:02 -0600
Subject: Gemini proxy image display
In-Reply-To: <20200910133827.13f89aba@celehner.com>
References: <d216208f972c8d71670aa27da3e4cd70aa9b51db.camel@gnu.org>
 <c01479fd-c234-9191-de64-1f8966d4ddb8@leveck.us>
 <20200910133827.13f89aba@celehner.com>
Message-ID: <8b4aecf2-72c6-6aa4-fa56-7a4b1d04a598@leveck.us>

On 9/10/20 11:38 AM, Charles E. Lehner wrote:
> Mr. Leveck,
> 
> I looked into it more, comparing this broken image:
> https://leveck.us/gemini/1436.ninja/the_servers.png
> 
> with the good original:
> gemini://1436.ninja/the_servers.png
> 
> The proxied one has this header "<!-- GEMINI! --><!-- 1436.ninja/the_servers.png --><!-- 192.168.0.45 -->". That breaks the image. Also, in the content at byte 24576 (0x6000), the files diverge. The proxied one seems to restart sending the PNG image there, with some bytes missing. Maybe a variable is incorrectly set in your code?
> 
> Charles

Useful.

The comments were added during troubleshooting something else. I think I 
have fixed all the above, but that image is still broken. I'll keep digging.

-- 
jynx
gopher://1436.ninja
gemini://1436.ninja/
https://leveck.us

From tomasino at lavabit.com  Thu Sep 10 18:54:19 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 10 Sep 2020 17:54:19 +0000
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200910174703.ro5vnl6faaxrx422@localhost>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200910174703.ro5vnl6faaxrx422@localhost>
Message-ID: <a216340b-bf58-26f7-d02e-787fcdda5204@lavabit.com>

On 9/10/20 5:47 PM, mbays at sdf.org wrote:
> How about if clients have an easily toggled switch between showing
> preformatted text and just showing alt text? I guess that would still
> lead to more easter-egging, but maybe not too much? It seems there's a
> tradeoff between discouraging inaccessible uses as human-readable text,
> and discouraging inaccessible uses as machine-readable text...

I've been thinking about clients toggling the visibility of preformatted text. While it may not provide much value in a desktop client for sighted users, this could be very useful in mobile clients. Preformatted text is one of the troublesome areas that screws up displays on narrow screens. If a mobile client were to serve the alternate text instead then visitors could choose whether they want to expand it to see the preformatted content.

This sort of flow is exactly what a screen reader would be doing for a blind user. It serves up that alternate text first and the user then can decide whether it is worth the effort to dive into the contents further.

Maybe it will also help keep alt-text top-of-mind for content authors if they run into it themselves in the proper context.


From easrng at gmail.com  Thu Sep 10 19:07:38 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Thu, 10 Sep 2020 14:07:38 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <a216340b-bf58-26f7-d02e-787fcdda5204@lavabit.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200910174703.ro5vnl6faaxrx422@localhost>
 <a216340b-bf58-26f7-d02e-787fcdda5204@lavabit.com>
Message-ID: <CAEzvDCV-nPZu=GAKupVf0q20_UXmweVmks5+Hk2A7_FrGFBdZQ@mail.gmail.com>

When parsing closing lines with extra text after the "```", should
they just be treated as part of the block? ex. should
```Alt Text
1
```2
3
```
4

look like
+------------------------------+
| 1                            |
| ```2                         |
| 3                            |
+------------------------------+
4

or

+------------------------------+
| 1                            |
+------------------------------+
3
+------------------------------+
| 4                            |
+------------------------------+


On Thu, Sep 10, 2020 at 1:54 PM James Tomasino <tomasino at lavabit.com> wrote:
>
> On 9/10/20 5:47 PM, mbays at sdf.org wrote:
> > How about if clients have an easily toggled switch between showing
> > preformatted text and just showing alt text? I guess that would still
> > lead to more easter-egging, but maybe not too much? It seems there's a
> > tradeoff between discouraging inaccessible uses as human-readable text,
> > and discouraging inaccessible uses as machine-readable text...
>
> I've been thinking about clients toggling the visibility of preformatted text. While it may not provide much value in a desktop client for sighted users, this could be very useful in mobile clients. Preformatted text is one of the troublesome areas that screws up displays on narrow screens. If a mobile client were to serve the alternate text instead then visitors could choose whether they want to expand it to see the preformatted content.
>
> This sort of flow is exactly what a screen reader would be doing for a blind user. It serves up that alternate text first and the user then can decide whether it is worth the effort to dive into the contents further.
>
> Maybe it will also help keep alt-text top-of-mind for content authors if they run into it themselves in the proper context.
>


-- 
?

From sandra.snan at idiomdrottning.org  Thu Sep 10 19:36:58 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 10 Sep 2020 20:36:58 +0200
Subject: Lang parameters
In-Reply-To: <C5BBX0YSJJO7.F703880EVPVM@stilgar>
References: <C5BBX0YSJJO7.F703880EVPVM@stilgar>
Message-ID: <87imclh41h.fsf@idiomdrottning.org>

This is what I just implemented using Molly.
I had to put every gmi file in its own directory :(
Not really what I wanted but at least now files have the right lang.
That's important to people using screen readers.

Gemfeed doesn't work with this solution but I figured out a workaround.

From mailinglists at ngalt.com  Thu Sep 10 19:53:29 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 10 Sep 2020 11:53:29 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <a216340b-bf58-26f7-d02e-787fcdda5204@lavabit.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200910174703.ro5vnl6faaxrx422@localhost>
 <a216340b-bf58-26f7-d02e-787fcdda5204@lavabit.com>
Message-ID: <02512802-F6FA-4120-BDB5-880241BD17BB@ngalt.com>



> On Sep 10, 2020, at 10:54 AM, James Tomasino <tomasino at lavabit.com> wrote:
> 
> On 9/10/20 5:47 PM, mbays at sdf.org wrote:
>> How about if clients have an easily toggled switch between showing
>> preformatted text and just showing alt text? I guess that would still
>> lead to more easter-egging, but maybe not too much? It seems there's a
>> tradeoff between discouraging inaccessible uses as human-readable text,
>> and discouraging inaccessible uses as machine-readable text...
> 
> I've been thinking about clients toggling the visibility of preformatted text. While it may not provide much value in a desktop client for sighted users, this could be very useful in mobile clients. Preformatted text is one of the troublesome areas that screws up displays on narrow screens. If a mobile client were to serve the alternate text instead then visitors could choose whether they want to expand it to see the preformatted content.
> 
> This sort of flow is exactly what a screen reader would be doing for a blind user. It serves up that alternate text first and the user then can decide whether it is worth the effort to dive into the contents further.
> 
> Maybe it will also help keep alt-text top-of-mind for content authors if they run into it themselves in the proper context.
> 

True, but another (probably better in most cases) way for narrow screens to handle wide preformatted blocks is to have just those blocks be side-scrollable. I?d rather use a client that has the occasional side-scrollable block instead of a client that makes me tap on alt text to display ``` blocks. Oftentimes I can get a better idea of what?s in the block, and whether I want to scroll to the right, just by looking at the left edge.

From sandra.snan at idiomdrottning.org  Thu Sep 10 19:58:08 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 10 Sep 2020 20:58:08 +0200
Subject: For consideration: JSON Feed
In-Reply-To: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
Message-ID: <87een9h327.fsf@idiomdrottning.org>

What I don't like about JSON Feed in this context is that content is
mandatory. It can't be just a list of links a la gemfeed.

From sandra.snan at idiomdrottning.org  Thu Sep 10 20:00:36 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 10 Sep 2020 21:00:36 +0200
Subject: [ANN] Draft for kind-of a Gemini Fediverse.
In-Reply-To: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
References: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
Message-ID: <87blidh2y3.fsf@idiomdrottning.org>

What I kinda want when I hear the words "Gemini Fediverse" is a Gemini
interface to the existing Fediverse. Like Brutaldon, but for Gemini
instead of Lynx.

ActivityPub is a nightmare but that nightmare can be encapsulated server
side and clients only need to be able to do basic Gemini stuff?

From luke at marmaladefoo.com  Thu Sep 10 20:01:55 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 10 Sep 2020 20:01:55 +0100
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <02512802-F6FA-4120-BDB5-880241BD17BB@ngalt.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200910174703.ro5vnl6faaxrx422@localhost>
 <a216340b-bf58-26f7-d02e-787fcdda5204@lavabit.com>
 <02512802-F6FA-4120-BDB5-880241BD17BB@ngalt.com>
Message-ID: <5F5A7823.5070404@marmaladefoo.com>



On 10-Sep-2020 19:53, Nathan Galt wrote:
>> I've been thinking about clients toggling the visibility of preformatted text. While it may not provide much value in a desktop client for sighted users, this could be very useful in mobile clients. Preformatted text is one of the troublesome areas that screws up displays on narrow screens. If a mobile client were to serve the alternate text instead then visitors could choose whether they want to expand it to see the preformatted content.
>>
>> This sort of flow is exactly what a screen reader would be doing for a blind user. It serves up that alternate text first and the user then can decide whether it is worth the effort to dive into the contents further.
>>
>> Maybe it will also help keep alt-text top-of-mind for content authors if they run into it themselves in the proper context.
> True, but another (probably better in most cases) way for narrow screens to handle wide preformatted blocks is to have just those blocks be side-scrollable. I?d rather use a client that has the occasional side-scrollable block instead of a client that makes me tap on alt text to display ``` blocks. Oftentimes I can get a better idea of what?s in the block, and whether I want to scroll to the right, just by looking at the left edge.

The pleasure of Gemini is there can be a genuine diversity of clients - 
unlike the web.

We should not really be specifying client behaviour too much, but rather 
focus on Gemini as a protocol and exchange format intended for humans to 
be displayed in the way that makes sense for them. It is a real benefit 
that there is no server imposed presentation controls and styling 
(unlike HTML)

I'd love to see a Gemini client on KaiOS (offspring of FirefoxOS) which 
is growing rapidly as a simpler smart phone in many countries. In that 
case, an option to skip or keep preformatted text collapsed would make 
perfect sense to me.

What makes sense for one person on a large screen will be different to 
someone on a small phone, and so on for the myriad of users out there.

  - Luke



From mailinglists at ngalt.com  Thu Sep 10 20:05:07 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 10 Sep 2020 12:05:07 -0700
Subject: For consideration: JSON Feed
In-Reply-To: <87een9h327.fsf@idiomdrottning.org>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <87een9h327.fsf@idiomdrottning.org>
Message-ID: <0CAB536E-871A-41C4-BEE7-F810E89AB44B@ngalt.com>

On Sep 10, 2020, at 11:58 AM, Sandra Snan <sandra.snan at idiomdrottning.org> wrote:
> 
> What I don't like about JSON Feed in this context is that content is
> mandatory. It can't be just a list of links a la gemfeed.

True, but:

- titles are optional (this is a concession to microbloggers)
- The spec doesn?t explicitly disallow ?content_text?: ?? (pardon the auto-curled quotes) in feeds

From sandra.snan at idiomdrottning.org  Thu Sep 10 20:06:14 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 10 Sep 2020 21:06:14 +0200
Subject: Lang parameters
In-Reply-To: <20200831194843.GD15566@brevard.conman.org>
References: <87imd0un2w.fsf@idiomdrottning.org>
 <20200830235749.GA15566@brevard.conman.org>
 <877dtfv4ng.fsf@idiomdrottning.org>
 <20200831044209.GC15566@brevard.conman.org>
 <87sgc3tbdp.fsf@idiomdrottning.org>
 <20200831194843.GD15566@brevard.conman.org>
Message-ID: <878sdhh2op.fsf@idiomdrottning.org>

Sean Conner <sean at conman.org> writes:

> It was thus said that the Great Sandra Snan once stated:
>> Thank you for the follow up, Sean!
>> 
>> Sean Conner <sean at conman.org> writes:
>> >   While the configuration file for GLV-1.12556 is a Lua script, you can
>> > think of it more as a configuration file.  So in this case, GLV-1.12556 can
>> > be configured to do this out of the box.
>> 
>> I don't mind writing some Lua, Go, CL or any other language but that
>> kinda fiddling will have to go on the back burner for now.
>
>   What kind of fiddling?  It's pretty much just configuration.

Fiddling such as writing handlers. I was absolutely exhausted last
weekend and wanted my gem site up quickly.

From leveck at leveck.us  Thu Sep 10 20:08:27 2020
From: leveck at leveck.us (Mr. Leveck)
Date: Thu, 10 Sep 2020 13:08:27 -0600
Subject: Gemini proxy image display
In-Reply-To: <8b4aecf2-72c6-6aa4-fa56-7a4b1d04a598@leveck.us>
References: <d216208f972c8d71670aa27da3e4cd70aa9b51db.camel@gnu.org>
 <c01479fd-c234-9191-de64-1f8966d4ddb8@leveck.us>
 <20200910133827.13f89aba@celehner.com>
 <8b4aecf2-72c6-6aa4-fa56-7a4b1d04a598@leveck.us>
Message-ID: <8f4e543f-859f-3c27-68cf-69f3dc08cbc4@leveck.us>

On 9/10/20 11:50 AM, Mr. Leveck wrote:
> On 9/10/20 11:38 AM, Charles E. Lehner wrote:
>> Mr. Leveck,
>>
>> I looked into it more, comparing this broken image:
>> https://leveck.us/gemini/1436.ninja/the_servers.png
>>
>> with the good original:
>> gemini://1436.ninja/the_servers.png
>>
>> The proxied one has this header "<!-- GEMINI! --><!-- 
>> 1436.ninja/the_servers.png --><!-- 192.168.0.45 -->". That breaks the 
>> image. Also, in the content at byte 24576 (0x6000), the files diverge. 
>> The proxied one seems to restart sending the PNG image there, with 
>> some bytes missing. Maybe a variable is incorrectly set in your code?
>>
>> Charles

This led me to it. Thank you very much!

New code:

status = stream_get_line($socket,512,"\r\n");
content = stream_get_contents($socket);

The first line strips off 512 bytes, or until \r\n is encountered. The 
second is much better for my intended use than fread at acquiring the 
rest. Binary files now work.

Now I need to iron out some other things like relative URLs...

-- 
jynx
gopher://1436.ninja
gemini://1436.ninja/
https://leveck.us

From sandra.snan at idiomdrottning.org  Thu Sep 10 20:21:42 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 10 Sep 2020 21:21:42 +0200
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <70267a11-5894-794e-1b1c-db63e1e3e143@gkbrk.com>
References: <_u75tVVBXc5bGVl0CeWS66XIJZNhE0ymlxshWKYaMes50cD15PNKQznuSRW09XXjoIwjtg8QAoclpGmvk0-ytwLnS4XxpT1OCmu1C8_BucE=@protonmail.com>
 <70267a11-5894-794e-1b1c-db63e1e3e143@gkbrk.com>
Message-ID: <87363ph1yx.fsf@idiomdrottning.org>

James Henderson <henderson.j at protonmail.com> writes:
> The idea behind using ::: is that its rare enough to never really show
> up and therefore makes a fairly solid delimiter. It also makes
> manually writing a feed file easier because commas quotes and escapes
> are not a concern at all.

Betting that your delim is rare instead of providing escapes isn't a
great design principle in my experience. Gemini itself has already been
bit by this as we saw earlier with the unescapable ```

TSV or CSV exist and have clients that can help write and read them.

Leo <gemini at gkbrk.com> writes:
> While I like the idea of simple line-delimited formats for feeds,
> I have to agree that Atom or RSS is simply the way to go here.

I'm not 100% decided yet, but the position stated by Leo here is what
I'm currently leaning towards.

As I wrote on irc://irc.tilde.chat/#gemini :
> With the understanding that everyine got into Gemini for different
> reasons, I got into Gemini after reading this web page.
> https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html.
> Creating a new format, I see as increasing scope

I believe I also for some reason also linked to this old chestnut:
https://imgs.xkcd.com/comics/standards.png

I could maaaybe get suckered in into supporting a format where every
entry is one line. Link iso-8601-date title. No description.

But my 2? is for us to stick with a format similar to Gemfeed's output.

From sandra.snan at idiomdrottning.org  Thu Sep 10 21:12:59 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 10 Sep 2020 22:12:59 +0200
Subject: For consideration: JSON Feed
In-Reply-To: <0CAB536E-871A-41C4-BEE7-F810E89AB44B@ngalt.com>
References: <26bfa2ef-7b46-4933-95da-93b5d0f49a6b@www.fastmail.com>
 <87een9h327.fsf@idiomdrottning.org>
 <0CAB536E-871A-41C4-BEE7-F810E89AB44B@ngalt.com>
Message-ID: <87y2lhfl10.fsf@idiomdrottning.org>

Nathan Galt <mailinglists at ngalt.com> writes:
> - The spec doesn?t explicitly disallow ?content_text?: ?? (pardon the
> auto-curled quotes) in feeds

That is unfortunately completely wack.
I wanna live my life right?

"A. E. Spencer-Reed" <easrng at gmail.com> writes:
> Re: other feed formats, there's also indieweb's h-feed, but that is
> not applicable here.

Thank you for bringing up h-feed as kind of a cautionary tale of when an
insular community creates yet another feed format. I had forgotten about
h-feed :/

From sean at conman.org  Thu Sep 10 21:19:06 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 10 Sep 2020 16:19:06 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <CAEzvDCV-nPZu=GAKupVf0q20_UXmweVmks5+Hk2A7_FrGFBdZQ@mail.gmail.com>
References: <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200910174703.ro5vnl6faaxrx422@localhost>
 <a216340b-bf58-26f7-d02e-787fcdda5204@lavabit.com>
 <CAEzvDCV-nPZu=GAKupVf0q20_UXmweVmks5+Hk2A7_FrGFBdZQ@mail.gmail.com>
Message-ID: <20200910201906.GB19614@brevard.conman.org>

It was thus said that the Great A. E. Spencer-Reed once stated:
> When parsing closing lines with extra text after the "```", should
> they just be treated as part of the block? ex. should
> ```Alt Text
> 1
> ```2
> 3
> ```
> 4
> 
> look like
> +------------------------------+
> | 1                            |
> | ```2                         |
> | 3                            |
> +------------------------------+
> 4
> 
> or
> 
> +------------------------------+
> | 1                            |
> +------------------------------+
> 3
> +------------------------------+
> | 4                            |
> +------------------------------+

  The second example.  From the spec
(gemini://gemini.circumlunar.space/docs/specification.gmi):

	Any text following the leading "`" of a preformat toggle line which
	toggles preformatted mode off MUST be ignored by clients.

  -spc


From easeout at tilde.team  Fri Sep 11 00:46:17 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Thu, 10 Sep 2020 19:46:17 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <871rj9fuqp.fsf@disroot.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost>
 <871rj9fuqp.fsf@disroot.org>
Message-ID: <20200910234617.GE1964344@tilde.team>

On Thu, Sep 10, 2020 at 12:43:10PM -0400, Gary Johnson wrote:
> Just to throw another idea out there:
> 
> There has been some extended discussion now on the mailing list about a
> conflict in machine-readable vs human-readable content being added after
> the opening pre-formatting ``` characters. It seems that enough people
> in the Gemini community see both of these kinds of information as
> providing value, but the spec currently lacks a clear path forward for
> differentiating between them.
> 
> Right now, anything written after the closing pre-formatting ``` chars
> isn't being used as per the spec's instructions. I can't help but wonder
> what would happen if we were able to put machine-readable instructions
> (like "table", "image", "code:python") on the opening line (so that
> clients could switch their line interpreter modes accordingly) and place
> human-readable alt text (mainly for screen readers) on the closing line
> (assuming the screen reader will probably just skip over the
> pre-formatted block's contents anyway and then read the alt text if
> provided).

This is a possible solution to the conflict, and I don't mind it. I do
think machine-readable on the top line and human-readable on the bottom
line is natural too, because we put captions beneath figures, and
because the top slot is already used in e.g. GitHub Markdown for
language specifiers.

From easeout at tilde.team  Fri Sep 11 01:16:31 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Thu, 10 Sep 2020 20:16:31 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200910155534.z7gml3adywayhqiw@GLaDOS>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
Message-ID: <20200911001631.GF1964344@tilde.team>

On Thu, Sep 10, 2020 at 09:55:34AM -0600, Alex // nytpu wrote:
> >I strongly recommend against this. The W3C has been trying to get HTML
> >authors and browser makers to _only_ display, in tooltips, text in
> >`title` attributes.  Previously, HTML authors would write `alt`
> >attribute values intending them to be read by sighted HTML readers who
> >can already see the image.
> I strongly agree. While I don't view the W3C's recommendations as the
> gold standard of things gemini should look to emulate (EME anyone?), I
> agree that if we make the alt text easily visible it will no longer be
> accessibility text and will turn into a miscellaneous-purpose field.

Great points. My main goal is to address the fact that the spec
underdefines the alt text field. I want it to decide on one use such
that clients could depend on it always being suitable for that use.

Thanks for pointing out that what we think of as "alt text" in HTML is
not the same thing as the alternative representation used by screen
readers. In that light, I don't want Gemini's preformat alt text to be
machine-readable, nor do I want it to be an HTML alt text style tooltip
or caption.

I think it should behave like the "title" attribute. I want Gemini to
offer accessibility affordances where the nature of plain text does not
already provide them, and this seems like the right use for that. I
think it would also be suitable to change the name from "alt text" to
something like "accessibile description".

> >(You might be thinking ?well, what about that Markdown meme where
> >people write ?```javascript? to start off a JavaScript code block, with
> >the idea that a syntax highlighter will read it and colorize the
> >output??
> The original point of suggesting that it be displayed for all users was
> to discourage turning text intended for humans into text intended for
> machines anyways, but I believe an alternate solution other than
> displaying it for everybody would still be preferable.

Yep, that is what I meant, to drop machine-readability in favor of human
readability.

> Rewriting that portion of the spec to emphasize that it is not to be
> parsed in any way other than as natural language?  Maybe say that a
> client *should be able to* completely replace the preformatted block
> with the contents of the alt text without the document losing
> significant meaning? That would work for ascii art and short code
> snippets, but it might not be doable for longer code blocks.

An accessible description for a long code block seems like a non-goal,
though, because when code is text, I imagine that makes it accessible to
a screen reader.

When considering these details it is helping me to draw a clear line
between an accessible content description and a caption. I think we want
the former, not the latter.

From easeout at tilde.team  Fri Sep 11 01:28:24 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Thu, 10 Sep 2020 20:28:24 -0400
Subject: Vim Gemtext syntax
In-Reply-To: <04201570-464E-4134-BEC8-B45531695E44@ngalt.com>
References: <04201570-464E-4134-BEC8-B45531695E44@ngalt.com>
Message-ID: <20200911002824.GG1964344@tilde.team>

On Thu, Sep 10, 2020 at 02:58:07AM -0700, Nathan Galt wrote:
> I wanted bat(1) to colorize Gemini files nicely, so I made this.
> 
> Pull requests and bug reports welcome.
> 
> https://github.com/adiabatic/gemini.sublime-syntax

I whipped up this syntax mode for Vim as well.

https://github.com/kconner/vim-syntax-gemtext

From sean at conman.org  Fri Sep 11 01:30:42 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 10 Sep 2020 20:30:42 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200910234617.GE1964344@tilde.team>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
Message-ID: <20200911003042.GC19614@brevard.conman.org>

It was thus said that the Great easeout at tilde.team once stated:
> 
> This is a possible solution to the conflict, and I don't mind it. I do
> think machine-readable on the top line and human-readable on the bottom
> line is natural too, because we put captions beneath figures, and
> because the top slot is already used in e.g. GitHub Markdown for
> language specifiers.

  Luke Emmet wrote:

> The pleasure of Gemini is there can be a genuine diversity of clients -
> unlike the web.

  And back in the mid-90s, there *were* plenty of web clients.  Easily a
dozen that were easily available and that was back in time when it was easy
enough to parse HTML, there was no CSS and no Javascript, and it was
conceivable that someone could write a simple web browser in a weekend [1].

  Then Sandra Snan sent the following link:

	https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html

Wherein it's mentioned that the current "state of the web" is described by
114,000,000 words spread across 1,217 standards documents.  You get here by
incremental changes, all of which are "easy" and "it would be so nice."

  Also, don't forget that Gemini can *easily* serve up HTML documents.  And
Markdown documents.  And PDF.  And a host of other documentation formats
that all do what you want to do.  And then some.

  But hey, I can play this game.  I added the following non-standard
document:

	gemini://gemini.conman.org/test/preformat.gemini

that contains "machine readable text" at the opening preformatted marker,
and a "human readable text" on the ending preformatted marker, just to give
an indication of what it might look like and what might be done with it. 
Enough talk, *someone* has to do an implementation to scare the bejeezus out
of everyone (not that it's particularly scary in what I did).

  -spc (HTML people.  Seriously, HTML.  You want your format, you have it
	already ... )

[1]	https://en.wikipedia.org/wiki/ViolaWWW

From mailinglists at ngalt.com  Fri Sep 11 03:29:53 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 10 Sep 2020 19:29:53 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200911001631.GF1964344@tilde.team>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200911001631.GF1964344@tilde.team>
Message-ID: <15D1C9A9-4F92-4B4C-9C57-21B28E405C19@ngalt.com>



> On Sep 10, 2020, at 5:16 PM, easeout at tilde.team wrote:
> 
> On Thu, Sep 10, 2020 at 09:55:34AM -0600, Alex // nytpu wrote:
>>> I strongly recommend against this. The W3C has been trying to get HTML
>>> authors and browser makers to _only_ display, in tooltips, text in
>>> `title` attributes.  Previously, HTML authors would write `alt`
>>> attribute values intending them to be read by sighted HTML readers who
>>> can already see the image.
>> I strongly agree. While I don't view the W3C's recommendations as the
>> gold standard of things gemini should look to emulate (EME anyone?), I
>> agree that if we make the alt text easily visible it will no longer be
>> accessibility text and will turn into a miscellaneous-purpose field.
> 
> Great points. My main goal is to address the fact that the spec
> underdefines the alt text field. I want it to decide on one use such
> that clients could depend on it always being suitable for that use.
> 
> Thanks for pointing out that what we think of as "alt text" in HTML is
> not the same thing as the alternative representation used by screen
> readers. In that light, I don't want Gemini's preformat alt text to be
> machine-readable, nor do I want it to be an HTML alt text style tooltip
> or caption.
> 
> I think it should behave like the "title" attribute. I want Gemini to
> offer accessibility affordances where the nature of plain text does not
> already provide them, and this seems like the right use for that. I
> think it would also be suitable to change the name from "alt text" to
> something like "accessibile description?.

I think you?ve got the terminology backwards. In HTML, `alt` is for people who can?t see the image (didn?t download it, eyes don?t work right, etc.). In that light, renaming it to ?accessible description? changes nothing, and ?it should behave like the ?title? attribute? means, as far as I can tell, ?it should be accessory information for people who can already see the image?, which is not even _trying_ to be helpful for people who can?t see the image.

Let me show an example where the contents of `alt` and `title` differ wildly:

<img src='conned-eventually.jpeg' alt='Chio telling Link ?Ya know, if you keep doing everything everyone asks of you without question, you?re gonna get conned eventually??' title='Little does Chio know I?ve already met Purah.'>

The alt text describes the image (a screenshot of me playing The Legend of Zelda: Breath of the Wild).

The title text is a joke, hidden behind a tooltip in most browsers, that should make anyone who?s played BotW snicker briefly. (Purah treats Link as an errand-boy for a good portion of the game.)

> 
>>> (You might be thinking ?well, what about that Markdown meme where
>>> people write ?```javascript? to start off a JavaScript code block, with
>>> the idea that a syntax highlighter will read it and colorize the
>>> output??
>> The original point of suggesting that it be displayed for all users was
>> to discourage turning text intended for humans into text intended for
>> machines anyways, but I believe an alternate solution other than
>> displaying it for everybody would still be preferable.
> 
> Yep, that is what I meant, to drop machine-readability in favor of human
> readability.
> 
>> Rewriting that portion of the spec to emphasize that it is not to be
>> parsed in any way other than as natural language?  Maybe say that a
>> client *should be able to* completely replace the preformatted block
>> with the contents of the alt text without the document losing
>> significant meaning? That would work for ascii art and short code
>> snippets, but it might not be doable for longer code blocks.
> 
> An accessible description for a long code block seems like a non-goal,
> though, because when code is text, I imagine that makes it accessible to
> a screen reader.

I have a strong prior that most screen readers won?t read code text aloud in ways that would make sense to a (blind) programmer who?s familiar with that sort of code. For example, I would expect that most screen readers won?t read parentheses and single/double quotation marks out loud, and those sorts of punctuation marks tend to be superlatively important in roughly all programming languages.

And then there are blind non-programmers who might stumble across a bit of code, or blind programmers who don?t understand _that_ kind of code and would appreciate some short alternative text explaining what it does (this gives them a better idea of whether they should tough it out and listen to it all or just skip it).

> When considering these details it is helping me to draw a clear line
> between an accessible content description and a caption. I think we want
> the former, not the latter.

For what it?s worth, I?m pro-alt-text. Tightly-bound captions might also be nice (I?d use them if they were in the spec), but they?re much, _much_ less important.


From easeout at tilde.team  Fri Sep 11 03:49:59 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Thu, 10 Sep 2020 22:49:59 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <15D1C9A9-4F92-4B4C-9C57-21B28E405C19@ngalt.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200911001631.GF1964344@tilde.team>
 <15D1C9A9-4F92-4B4C-9C57-21B28E405C19@ngalt.com>
Message-ID: <20200911024959.GH1964344@tilde.team>

On Thu, Sep 10, 2020 at 07:29:53PM -0700, Nathan Galt wrote:
> 
> > On Sep 10, 2020, at 5:16 PM, easeout at tilde.team wrote:
> > 
> > I think it should behave like the "title" attribute. I want Gemini to
> > offer accessibility affordances where the nature of plain text does not
> > already provide them, and this seems like the right use for that. I
> > think it would also be suitable to change the name from "alt text" to
> > something like "accessibile description?.
> 
> I think you?ve got the terminology backwards. In HTML, `alt` is for people who can?t see the image (didn?t download it, eyes don?t work right, etc.). In that light, renaming it to ?accessible description? changes nothing, and ?it should behave like the ?title? attribute? means, as far as I can tell, ?it should be accessory information for people who can already see the image?, which is not even _trying_ to be helpful for people who can?t see the image.
>
> Let me show an example where the contents of `alt` and `title` differ wildly:
> 
> <img src='conned-eventually.jpeg' alt='Chio telling Link ?Ya know, if you keep doing everything everyone asks of you without question, you?re gonna get conned eventually??' title='Little does Chio know I?ve already met Purah.'>
> 
> The alt text describes the image (a screenshot of me playing The Legend of Zelda: Breath of the Wild).
> 
> The title text is a joke, hidden behind a tooltip in most browsers, that should make anyone who?s played BotW snicker briefly. (Purah treats Link as an errand-boy for a good portion of the game.)
> 

You're right, I did have the concepts reversed. Thanks for spelling it
out so clearly!

From mailinglists at ngalt.com  Fri Sep 11 03:59:33 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 10 Sep 2020 19:59:33 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200911003042.GC19614@brevard.conman.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
Message-ID: <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>


> On Sep 10, 2020, at 5:30 PM, Sean Conner <sean at conman.org> wrote:
> 
>  I added the following non-standard document:
> 
> 	gemini://gemini.conman.org/test/preformat.gemini
> 
> that contains "machine readable text" at the opening preformatted marker,
> and a "human readable text" on the ending preformatted marker, just to give
> an indication of what it might look like and what might be done with it. 
> Enough talk, *someone* has to do an implementation to scare the bejeezus out
> of everyone (not that it's particularly scary in what I did).
> 
>  -spc (HTML people.  Seriously, HTML.  You want your format, you have it
> 	already ... )

I like sets of concrete examples. Thanks for whipping this up.

What I dislike about this style of ??machine-readable? text up top? (for some definition of ?machine-readable?) is that the alt-text function has been entirely obliterated, at least in these examples.

For the two code bits at the top of the page, the alt text should be the contents of the captions at the bottom of each.

For the three ?images?, the alt-text should be something like:

- a dragon
- Merry Christmas
- a Christmas tree with a rabbit sitting near its base

It seems we have a ?pick two? problem. We have (at least!) three different annotation types that we?d like to adorn preformatted blocks with:

- machine-readable hints for how to parse a block (say, for syntax highlighting)
- alternative representations for people who can?t see (/understand?) the contents of the block
- captions of the block for people who can see it fine

And?we have two potential slots to fill. Constraints:

- preexisting Markdown parsers expect their what-language-is-this hint right after the first ```
- alt text probably ought to come first, just in case the user is on an oversaturated 2 KB/s modem connection?or something. Plus, the Gemini spec already says that This Is the Way?.

Personally, I think block captions (title-text equivalents) are the least important and should be the first to be shoved out the airlock. While HTML is better for their addition, people limped along OK before <aside> and <figure>+<figcaption> were added to HTML5.

From meff at meff.me  Fri Sep 11 06:31:51 2020
From: meff at meff.me (Meff)
Date: Thu, 10 Sep 2020 22:31:51 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200911003042.GC19614@brevard.conman.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
Message-ID: <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

(Apologies for the double email Sean, I forgot to Reply All)

Sean Conner <sean at conman.org> writes:

>   And back in the mid-90s, there *were* plenty of web clients.  Easily a
> dozen that were easily available and that was back in time when it was easy
> enough to parse HTML, there was no CSS and no Javascript, and it was
> conceivable that someone could write a simple web browser in a weekend [1].
>
>   Then Sandra Snan sent the following link:
>
> 	https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
>
> Wherein it's mentioned that the current "state of the web" is described by
> 114,000,000 words spread across 1,217 standards documents.  You get here by
> incremental changes, all of which are "easy" and "it would be so
> nice."

I agree with this. I understand that there's a couple points here that
the alt-text discussion is trying to solve:

* Formatting hints for non-human clients
** Specifically this benefits users that may be visually impaired and
   their use of tools such as screen readers
* Hints or descriptions for human readers

I don't see a way out of this without making Gemtext much more
complicated than it is now. As it is, parsing Gemtext preformatted
blocks requires holding onto state, which no other portion of Gemtext
requires. Adding hints will make parsing these blocks even more
complicated. And then the interpretation question comes in: how do we
interpret these blocks that adorn preformatted text. Will these blocks
be abused. Will complicated clients adopt a de-facto meaning for these,
leaving simpler clients to wither?

There are so many more questions that can come up. If I'm trying to
represent data, should Gemtext convey semantic information? If I'm
rendering the contents of longform text, should Gemtext convey layout
information? And how do we reify layouts between different languages and
their narrative structures? Should Gemtext support compression for large
payloads? What about caching? (ETags come to mind.) I mean, if I'm
distributing copies of Project Gutenberg books, I don't want to force
someone to download uncompressed text when they can get the same content
compressed in often half the time, especially in low/bad connectivity
situations. Oh and how about math? I see lots of discussion about code,
but how do we represent math? How do we give Gemini browsers rendering
hints for math? The potential here to add complexity is endless!

>
>   Also, don't forget that Gemini can *easily* serve up HTML documents.  And
> Markdown documents.  And PDF.  And a host of other documentation formats
> that all do what you want to do.  And then some.
>
>   But hey, I can play this game.  I added the following non-standard
> document:
>
> 	gemini://gemini.conman.org/test/preformat.gemini
>
> that contains "machine readable text" at the opening preformatted marker,
> and a "human readable text" on the ending preformatted marker, just to give
> an indication of what it might look like and what might be done with it. 
> Enough talk, *someone* has to do an implementation to scare the bejeezus out
> of everyone (not that it's particularly scary in what I did).

Thanks for putting the rubber to the road!

I'm just not a fan of trying to bundle more in Gemtext. I'd rather we
try to diversify the formats of content that are available. I think HTML
is a great fallback that can answer almost all the questions I posed
earlier, the questions that are under discussion for alt text, and 
most questions of document presentation. HTML doesn't need to be deeply
tied into a DOM with gobs of Javascript and CSS to work. And there's
plaintext, PDFs, XML, JSON, tons of formats for all sorts of use
cases. I'd rather not shove a round peg into a square hole, but that's
just me.

- meff

From mailinglists at ngalt.com  Fri Sep 11 07:17:19 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 10 Sep 2020 23:17:19 -0700
Subject: HTML as an escape hatch
Message-ID: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>

There?s a persistent worry on other threads that Gemini might become ?too complex?, for some definition of ?complex?.

This is a reasonable worry, considering the very complicated mess we?re all running from.

On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec:

?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.?

Thoughts? Counterarguments?

From contact at stacyharper.net  Fri Sep 11 07:59:38 2020
From: contact at stacyharper.net (Stacy Harper)
Date: Fri, 11 Sep 2020 08:59:38 +0200
Subject: HTML as an escape hatch
In-Reply-To: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
Message-ID: <20200911065938.a5wvh6lgmlhp7dlm@terminator>

Hello,

> On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec:

I think if you want additions, just use WWW. Gemini focus on content and
not formating.

> ?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.?

Yes you can create cool website using some standard html tags and a
little bit of css. But Gemini choosed its own gmi format specially to
prevent some implementations to add this kind of cool features.

> Thoughts? Counterarguments?

WWW decadence was fun, let's never do it again :)

From meff at meff.me  Fri Sep 11 08:28:12 2020
From: meff at meff.me (meff)
Date: Fri, 11 Sep 2020 00:28:12 -0700
Subject: HTML as an escape hatch
In-Reply-To: <20200911065938.a5wvh6lgmlhp7dlm@terminator>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
 <20200911065938.a5wvh6lgmlhp7dlm@terminator>
Message-ID: <87y2lgvkkz.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

For me, I see nothing wrong with Gemtext and HTML living side by
side. This isn't a zero-sum game, as much as the Web wants us to think
it is with its focus on hyperscale. As Stacy mentioned, Gemtext is great
for content and not formatting. If you want formatting, then use HTML!

- meff

Stacy Harper <contact at stacyharper.net> writes:

> Hello,
>
>> On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec:
>
> I think if you want additions, just use WWW. Gemini focus on content and
> not formating.
>
>> ?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.?
>
> Yes you can create cool website using some standard html tags and a
> little bit of css. But Gemini choosed its own gmi format specially to
> prevent some implementations to add this kind of cool features.
>
>> Thoughts? Counterarguments?
>
> WWW decadence was fun, let's never do it again :)

From sean at conman.org  Fri Sep 11 08:29:58 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Sep 2020 03:29:58 -0400
Subject: HTML as an escape hatch
In-Reply-To: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
Message-ID: <20200911072958.GD19614@brevard.conman.org>

It was thus said that the Great Nathan Galt once stated:
> There?s a persistent worry on other threads that Gemini might become ?too
> complex?, for some definition of ?complex?.
> 
> This is a reasonable worry, considering the very complicated mess we?re
> all running from.
> 
> On the other hand, I think there?s a fairly, if not fully, general
> counterargument to all sorts of additions that we might want to make to
> the spec:
> 
> ?There?s nothing wrong ? or even uncool ? about making a website with only
> HTML and, at most, 30 lines of CSS that looks great in Lynx.?
> 
> Thoughts? Counterarguments?

  It's one of the anti-Gemini arguments I've seen on sites like Hacker News
(https://news.ycombinator.com)---why not just use a stripped down HTML and
webservers that do what you want?  And yes, there is something to that
agument, but solderpunk has made it clear he doesn't want any crack that
will lead to the current web (and personally, I would love it if the
"application web" went via QUIC and the "original hypertext web" stayed on
TCP).

  The problem I see with gemtext (and having been on the mailing list from
the beginning, way over half the messages have been about the gemtext
format) is that people *want* their HTML, but it's mostly different subsets
of HTML.  About the only agreement is the absence of Javascript.

  Personally, I'm not a fan of the gemtext format as I find it restrictive
in a way that I don't find plain text or HTML, but it is what it is.  All I
do is put up pages with the proposed specification and see if there are
complaints (and there were---oh the surprise).

  Again, if you want formatting, HTML and Markdown are there for you to use
on Gemini.

  -spc


From sean at conman.org  Fri Sep 11 08:34:05 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Sep 2020 03:34:05 -0400
Subject: HTML as an escape hatch
In-Reply-To: <20200911065938.a5wvh6lgmlhp7dlm@terminator>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
 <20200911065938.a5wvh6lgmlhp7dlm@terminator>
Message-ID: <20200911073405.GE19614@brevard.conman.org>

It was thus said that the Great Stacy Harper once stated:
> Hello,
> 
> > On the other hand, I think there?s a fairly, if not fully, general
> > counterargument to all sorts of additions that we might want to make to
> > the spec:
> 
> I think if you want additions, just use WWW. Gemini focus on content and
> not formating.

  If gemtext was focused on content and not formatting, it wouldn't have
headers, lists, or pre-formatted areas.

  My own websites:

	http://www.conman.org/
	http://www.conman.org/people/spc/
	http://boston.conman.org/

uses straightforward HTML (4.01 if anyone cares), and while I do use some
CSS for formatting, it still has a structure that is visible if you strip
away the CSS (on Firefox, if you go "View ? Page Style ? No Style" it is
still readable).  And you would have to really hunt about my websites to
find the Javascript (it's there, just a very little bit of it).

> WWW decadence was fun, let's never do it again :)

  I think I'm one of the few left that actually like hypertext qua
hypertext.  Sad.  It's a neat concept.

  -spc


From sean at conman.org  Fri Sep 11 08:44:06 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Sep 2020 03:44:06 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>
Message-ID: <20200911074406.GF19614@brevard.conman.org>

It was thus said that the Great Nathan Galt once stated:
> 
> > On Sep 10, 2020, at 5:30 PM, Sean Conner <sean at conman.org> wrote:
> > 
> >  I added the following non-standard document:
> > 
> > 	gemini://gemini.conman.org/test/preformat.gemini
> > 
> > that contains "machine readable text" at the opening preformatted marker,
> > and a "human readable text" on the ending preformatted marker, just to give
> > an indication of what it might look like and what might be done with it. 
> > Enough talk, *someone* has to do an implementation to scare the bejeezus out
> > of everyone (not that it's particularly scary in what I did).
> > 
> >  -spc (HTML people.  Seriously, HTML.  You want your format, you have it
> > 	already ... )
> 
> I like sets of concrete examples. Thanks for whipping this up.
> 
> What I dislike about this style of ??machine-readable? text up top? (for
> some definition of ?machine-readable?) is that the alt-text function has
> been entirely obliterated, at least in these examples.
> 
> For the two code bits at the top of the page, the alt text should be the
> contents of the captions at the bottom of each.
> 
> For the three ?images?, the alt-text should be something like:
> 
> - a dragon
> - Merry Christmas
> - a Christmas tree with a rabbit sitting near its base

  Okay, check out

	gemini://gemini.conman.org/test/preformat-2.gemini

  -spc (Taking away my fun with the alt-text ... )


From linde.philip at gmail.com  Fri Sep 11 09:07:39 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 11 Sep 2020 10:07:39 +0200
Subject: HTML as an escape hatch
In-Reply-To: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
Message-ID: <20200911100739.061432e74f12186984e7a3cd@gmail.com>

On Thu, 10 Sep 2020 23:17:19 -0700
Nathan Galt <mailinglists at ngalt.com> wrote:

> On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec:
> 
> ?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.?
> 
> Thoughts? Counterarguments?

I agree with this notion. text/gemini has a very simple format, still.
I think there are several good reasons for that being the case:

1. It's easy to parse. You can write a parser in an afternoon, and a
   renderer for the terminal or your favorite GUI toolkit that same
   evening
2. It's easy to write pages. You can grasp every nuance of the document
   standard in an hour
3. It's human readable. You can easily read a text/gemini page as plain
   text because the markup is minimal
4. It has enough features to write very basic formatted documents, but
   not enough for the author to impose on the user

Similarly, for HTML, there are good reasons for it being structured as
it is. It supports nested documents that allow for greater control of
formatting, but at the expense of all the reasons I listed for Gemini.

If there is a good middle ground between HTML and Gemini, I'll happily
support that as its own MIME type, but I think the final most important
complexity that text/gemini should address is that it shouldn't be a
"living standard". That has a huge cost to site admins and developers.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200911/206a58ba/attachment.sig>

From andre at andregarzia.com  Fri Sep 11 14:50:44 2020
From: andre at andregarzia.com (Andre Garzia)
Date: Fri, 11 Sep 2020 14:50:44 +0100
Subject: Feed format for gemini (alternative to rss feed)
In-Reply-To: <CAMXq4zpaR_fZLHX6OUs2eRdGg__fDnKTJQiHDqbJQruZyi-o0Q@mail.gmail.com>
References: <gp0xDCGmXQCkzX2v43uxK8OEQkB4gdcW4op8aOtFE9w6tcwT4FjTX9RV7V2K5ph8tIW9AMYXXJskM1OTFVvbIv-w-BlpWNIclF9OvXGwOJw=@protonmail.com>
 <c008ea15-dcba-11cc-a2c9-f816dafa83a0@envs.net>
 <_u75tVVBXc5bGVl0CeWS66XIJZNhE0ymlxshWKYaMes50cD15PNKQznuSRW09XXjoIwjtg8QAoclpGmvk0-ytwLnS4XxpT1OCmu1C8_BucE=@protonmail.com>
 <CAMXq4zpaR_fZLHX6OUs2eRdGg__fDnKTJQiHDqbJQruZyi-o0Q@mail.gmail.com>
Message-ID: <CAF3jwT=DMTezc7QMTt8msnV6=Dr=fiQJe0bHQt4gea=UX7dboA@mail.gmail.com>

> RSS, (and atom, json...) feeds are easily parsable by machines and are
> already supported by
> feed readers, but they aren't readable by gemini clients. Also they are
> > fairly verbose and Allow[s] for things like embedding images
>
>
I just want to point out that given the amount of clients being launched we
can't be certain what they can or cannot support. Part of the charm of
Gemini is that clients can be proactive in how they provide the user
experience. For example, once I noted that many of those aggregators were
reading RSS/ATOM feeds I implemented a view for them in my own little GUI
client[1] which can be seen in action in this toot[2]. It is a naive
display but it allows the user a glimpse into the content and helps them
decide if they want to check the full link or not.

In my own subjective and biased view, people should use RSS and ATOM more
often. Generating a feed and a gemtext with links can be done from the same
source and should provide the best of both worlds.



[1]: Fafi Browser: https://git.sr.ht/~soapdog/fafi-browser
[2]: https://toot.cafe/@soapdog/104784951283677217

-- 
https://www.andregarzia.com <http://www.andregarzia.com>
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200911/3dfcb30e/attachment.htm>

From alex at nytpu.com  Fri Sep 11 16:05:02 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Fri, 11 Sep 2020 09:05:02 -0600
Subject: HTML as an escape hatch
Message-ID: <20200911150502.u2u5iuhd7uxiwv2a@GLaDOS>

> If there is a good middle ground between HTML and Gemini, I'll happily
> support that as its own MIME type
While I understand the desire to have something novel, there really is
no need to reinvent the wheel here. The whole point of having mimetypes
in gemini is so you can use whatever format you want to serve content.
If you want basic linking and sections, use gemtext. If you want rich
formatting (emphasis, boldface, etc) use markdown or asciidoc or any of
a million lightweight markup languages. If you want deep control over
the presentation of the document, use html. If you want no formatting at
all, use plaintext.  There's near certainty that there's an existing
format that generally suits your needs unless you're doing something
like math formulae, and even then you could just link to an image or use
a pdf and LaTeX.

The thing is, I think people have a misconstrued idea of what gemtext
is. The long and short of it is that it's a gophermap with headers and
code blocks. Sure, the syntax is different but at the end of the day
that's all it is. If you can't live without stronger control over the
styling and document structure you should just use a subset of html
(There's absolutely nothing wrong with that! You can still browse gemini
without having a gemini capsule yourself). You could even serve your
html over gemini if you so chose, although I'm not sure how well it'd be
supported by clients.

> but I think the final most important complexity that text/gemini
> should address is that it shouldn't be a "living standard". That has a
> huge cost to site admins and developers.
I think this should aim to be the highest priority over "making gemtext
better." Obviously there's an exception right now since it's in the
early stages and not finalized yet, but even now there shouldn't be
massive changes made to the spec at all, let alone changes that turn
gemtext into an ad hoc, impossible-to-parse implementation of half of
html.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://e-mail.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200911/3d685ed3/attachment.sig>

From jmcbray at carcosa.net  Fri Sep 11 16:18:27 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 11 Sep 2020 11:18:27 -0400
Subject: [ANN] Draft for kind-of a Gemini Fediverse.
In-Reply-To: <87blidh2y3.fsf@idiomdrottning.org> (Sandra Snan's message of
 "Thu, 10 Sep 2020 21:00:36 +0200")
References: <3f0f23a41c4eb5b59f287042c8a8a2b3@memeware.net>
 <87blidh2y3.fsf@idiomdrottning.org>
Message-ID: <87pn6sibp8.fsf@dorothy.carcosa.net>

Sandra Snan <sandra.snan at idiomdrottning.org> writes:

> What I kinda want when I hear the words "Gemini Fediverse" is a Gemini
> interface to the existing Fediverse. Like Brutaldon, but for Gemini
> instead of Lynx.

Hi, I'm the author of brutaldon :)

I've thought about writing a Gemini Mastodon/Pleroma client, like
brutaldon for Gemini. It would be extremely straightforward to do
read-only, public-timelines-only. Slightly less straightforward to do
read-only, personal timelines (need to handle Mastodon login process,
generate a client key, and link it to Mastodon auth token). Once you've
got that done, text-only posting with your default privacy level is
easy, but adding images, polls, and privacy settings becomes difficult
because of the intentional limitations of Gemini input fields.

IMO you're really better off using either Toot (TUI) or Tootstream
(CLI), though. I don't really love the idea of Gemini being used
intensively for applications, because it's intentionally not designed
for it. I feel like the 'Gemini way' for doing network application
development is to design an open, application-specific protocol, and
write native servers and clients for it. NNTP is the example I always
keep coming back to.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From lambdatronic at disroot.org  Fri Sep 11 18:28:55 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 11 Sep 2020 13:28:55 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <87zh5w9q94.fsf@disroot.org>

Thanks for putting together a simple example Gemtext file using the
machine-readable-on-top, alt-text-on-bottom approach I suggested
yesterday.

>From the recent mailing list responses, it looks like my proposal was
met with mixed feelings. Some of you liked it. Others didn't and
suggested using HTML or Markdown instead. There also appear to be
several folks harboring fears of a slippery slope situation in which the
Gemini protocol, by means of supporting a machine-readable text line on
its preformatted text blocks, is somehow going to become as complex as
the modern-day web. I'll try to address some of these concerns here.

Just stepping back to first principles, I believe Solderpunk's intention
with the Gemtext spec was to provide a slightly more structured markup
format than plain text that could look nice in a more complex client but
which would still render just fine in a client that did nothing more
than render text/gemini as text/plain.

While I believe that Gemtext accomplishes this purpose very well in its
current state, the preformatted text block is definitely overloaded at
the moment in terms of its purpose. Currently, it is the only way to
include images (as ASCII art), tables, or source-code blocks in a
guaranteed mono-spaced font. All of these provide valuable information
to readers of our Gemtext pages, and I personally am quite happy with
how simple the preformatted blocks make it to include them.

However, once of the issues I first wrote to Solderpunk about when I
became aware of Gemini was whether Gemtext would support optional syntax
highlighting (in advanced clients that chose to support it) by allowing
us to use the ```some-programming-language syntax from Github-flavored
Markdown on the opening line of preformatted blocks. He replied to me
saying that this had been considered already and was intended as one of
the uses of that slot. He also pointed me to the point in the Gemini
spec which mentions this. Here is the relevant paragraph from Section
5.4.3 Preformatting toggle lines:

> Any text following the leading "```" of a preformat toggle line which
> toggles preformatted mode on MAY be interpreted by the client as "alt
> text" pertaining to the preformatted text lines which follow the
> toggle line. Use of alt text is at the client's discretion, and simple
> clients may ignore it. Alt text is recommended for ASCII art or
> similar non-textual content which, for example, cannot be meaningfully
> understood when rendered through a screen reader or usefully indexed
> by a search engine. Alt text may also be used for computer source code
> to identify the programming language which advanced clients may use
> for syntax highlighting.

For the three use cases of preformatted blocks that I mentioned above
(ASCII art images, tables, source code), alt text (as an accessibility
option) could clearly be useful and is also obviously the intended
purpose of this slot. However, the last line of that paragraph indicates
the intention that the ```some-programming-language is meant as one
machine-readable use of the line's contents for the purpose syntax
highlighting.

To assuage any concerns about opening the door to endless possible
syntaxes for machine-readable processing of preformatted blocks being
introduced to Gemtext, I'll retract my previous suggestion of using the
top line for (generic) machine-readable purposes and the bottom line for
the alt text.

The only real machine-readable behavior I want to see in Gemini is
source code syntax highlighting anyway, and the spec already supports
and encourages that. In all other cases, alt text (which can clearly be
ignored or used "at the client's discretion" as per the spec) is just
fine on the top line of preformatted blocks. I suppose I don't really
see much machine-readable value in tagging a block as "image" or "table"
currently anyway. YMMV

To that end, maybe we just need some community agreement (and/or a
clearer codification in the Gemini spec) of how to use alt text "for
computer source code to identify the programming language which advanced
clients may use for syntax highlighting".

===========================================================================

Here's a simple proposal:

```clojure Source code implementing a non-tail-recursive factorial function
(defn fac [n]
  (if (= n 0)
    1
    (* n (fac (- n 1)))))
```

If the first word in a preformatted text block's alt text is the name of
a programming language recognized by the client, then it may (at its
discretion) apply syntax highlighting for that language to the block's
contents.

===========================================================================

This remains in line with both the spirit and content of Gemini
specification Section 5.4.3 Preformatting toggle lines. It also
explicitly allows clients to opt-in (or not). Whether or not syntax
highlighting is applied, the entire alt text line can still be used as
perfectly valid human-readable text for accessibility purposes.

There is no possibility of a slippery slope happening in the Gemtext
specification because this is just a non-extensible, optional-only
feature that is already in the Gemini spec anyway and is just being more
clearly codified, so it can be used reliably in the wild.

I yield the floor.

Thanks,
  Gary


Meff <meff at meff.me> writes:

> (Apologies for the double email Sean, I forgot to Reply All)
>
> Sean Conner <sean at conman.org> writes:
>
>>   And back in the mid-90s, there *were* plenty of web clients.  Easily a
>> dozen that were easily available and that was back in time when it was easy
>> enough to parse HTML, there was no CSS and no Javascript, and it was
>> conceivable that someone could write a simple web browser in a weekend [1].
>>
>>   Then Sandra Snan sent the following link:
>>
>> 	https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
>>
>> Wherein it's mentioned that the current "state of the web" is described by
>> 114,000,000 words spread across 1,217 standards documents.  You get here by
>> incremental changes, all of which are "easy" and "it would be so
>> nice."
>
> I agree with this. I understand that there's a couple points here that
> the alt-text discussion is trying to solve:
>
> * Formatting hints for non-human clients
> ** Specifically this benefits users that may be visually impaired and
>    their use of tools such as screen readers
> * Hints or descriptions for human readers
>
> I don't see a way out of this without making Gemtext much more
> complicated than it is now. As it is, parsing Gemtext preformatted
> blocks requires holding onto state, which no other portion of Gemtext
> requires. Adding hints will make parsing these blocks even more
> complicated. And then the interpretation question comes in: how do we
> interpret these blocks that adorn preformatted text. Will these blocks
> be abused. Will complicated clients adopt a de-facto meaning for these,
> leaving simpler clients to wither?
>
> There are so many more questions that can come up. If I'm trying to
> represent data, should Gemtext convey semantic information? If I'm
> rendering the contents of longform text, should Gemtext convey layout
> information? And how do we reify layouts between different languages and
> their narrative structures? Should Gemtext support compression for large
> payloads? What about caching? (ETags come to mind.) I mean, if I'm
> distributing copies of Project Gutenberg books, I don't want to force
> someone to download uncompressed text when they can get the same content
> compressed in often half the time, especially in low/bad connectivity
> situations. Oh and how about math? I see lots of discussion about code,
> but how do we represent math? How do we give Gemini browsers rendering
> hints for math? The potential here to add complexity is endless!
>
>>
>>   Also, don't forget that Gemini can *easily* serve up HTML documents.  And
>> Markdown documents.  And PDF.  And a host of other documentation formats
>> that all do what you want to do.  And then some.
>>
>>   But hey, I can play this game.  I added the following non-standard
>> document:
>>
>> 	gemini://gemini.conman.org/test/preformat.gemini
>>
>> that contains "machine readable text" at the opening preformatted marker,
>> and a "human readable text" on the ending preformatted marker, just to give
>> an indication of what it might look like and what might be done with it. 
>> Enough talk, *someone* has to do an implementation to scare the bejeezus out
>> of everyone (not that it's particularly scary in what I did).
>
> Thanks for putting the rubber to the road!
>
> I'm just not a fan of trying to bundle more in Gemtext. I'd rather we
> try to diversify the formats of content that are available. I think HTML
> is a great fallback that can answer almost all the questions I posed
> earlier, the questions that are under discussion for alt text, and 
> most questions of document presentation. HTML doesn't need to be deeply
> tied into a DOM with gobs of Javascript and CSS to work. And there's
> plaintext, PDFs, XML, JSON, tons of formats for all sorts of use
> cases. I'd rather not shove a round peg into a square hole, but that's
> just me.
>
> - meff


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From lambdatronic at disroot.org  Fri Sep 11 18:51:06 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 11 Sep 2020 13:51:06 -0400
Subject: HTML as an escape hatch
In-Reply-To: <20200911150502.u2u5iuhd7uxiwv2a@GLaDOS>
References: <20200911150502.u2u5iuhd7uxiwv2a@GLaDOS>
Message-ID: <87v9gk9p85.fsf@disroot.org>

It's true that the Gemini protocol is able to serve up a variety of file
formats given its explicit requirement of mime-types in response
metadata. I'm also happy with the simple stripped-down nature of the
Gemtext format and am not looking for any major changes to be made to it
at this time.

However, I do want to throw in a counterpoint to recommending people
abandon Gemtext and serve up more Markdown or HTML in Geminispace.

While it is true that they can all be served up by the Gemini protocol,
it is not currently the case that very many Gemini clients can render
anything other than Gemtext. If enough people start to publish in
Markdown and/or HTML, we may soon find our experience of surfing
Geminispace to largely be about downloading Markdown and HTML pages
whenever we click on links and then having to open the local files in
our format-specific renderers of choice. HTML pages also reintroduce the
issue of potentially requiring clients to download any number of
auxiliary pages in order to render them. While we could hope that Gemini
publishers will stick to a minimal subset of HTML (for each user's
varying definition of "minimal"), there is no way to enforce this.

This does not sound like much fun to me, and it would impose a much
higher development cost on each browser developer as they would have to
implement rendering engines for Gemtext, Markdown, HTML, etc. in order
to provide their users with a more seamless browsing experience. Given
uneven distribution of resources to maintain and extend clients, this
could drive us down a path in which a smaller and smaller number of
browsers come to dominate Geminispace as the number of requirements on
what they have to render continues to increase.

In a worst-case scenario, we ultimately end up recreating a post-web
monopoly of Geminispace.

Just my 2c, but I'd like to see more folks encouraging the use of
text/gemini or text/plain in Geminispace rather than punting to more
complex formats except in special cases. If anyone is feeling super
restricted by Gemtext, I'd encourage them to spend some time on
Astrobotany (gemini://astrobotany.mozz.us) for inspiration.

YMMV,
  Gary


Alex // nytpu <alex at nytpu.com> writes:

>> If there is a good middle ground between HTML and Gemini, I'll happily
>> support that as its own MIME type
> While I understand the desire to have something novel, there really is
> no need to reinvent the wheel here. The whole point of having mimetypes
> in gemini is so you can use whatever format you want to serve content.
> If you want basic linking and sections, use gemtext. If you want rich
> formatting (emphasis, boldface, etc) use markdown or asciidoc or any of
> a million lightweight markup languages. If you want deep control over
> the presentation of the document, use html. If you want no formatting at
> all, use plaintext.  There's near certainty that there's an existing
> format that generally suits your needs unless you're doing something
> like math formulae, and even then you could just link to an image or use
> a pdf and LaTeX.
>
> The thing is, I think people have a misconstrued idea of what gemtext
> is. The long and short of it is that it's a gophermap with headers and
> code blocks. Sure, the syntax is different but at the end of the day
> that's all it is. If you can't live without stronger control over the
> styling and document structure you should just use a subset of html
> (There's absolutely nothing wrong with that! You can still browse gemini
> without having a gemini capsule yourself). You could even serve your
> html over gemini if you so chose, although I'm not sure how well it'd be
> supported by clients.
>
>> but I think the final most important complexity that text/gemini
>> should address is that it shouldn't be a "living standard". That has a
>> huge cost to site admins and developers.
> I think this should aim to be the highest priority over "making gemtext
> better." Obviously there's an exception right now since it's in the
> early stages and not finalized yet, but even now there shouldn't be
> massive changes made to the spec at all, let alone changes that turn
> gemtext into an ad hoc, impossible-to-parse implementation of half of
> html.


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From luke at marmaladefoo.com  Fri Sep 11 19:36:39 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 11 Sep 2020 19:36:39 +0100
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <87zh5w9q94.fsf@disroot.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
 <87zh5w9q94.fsf@disroot.org>
Message-ID: <5F5BC3B7.6000000@marmaladefoo.com>



On 11-Sep-2020 18:28, Gary Johnson wrote:
> [...]
>
> To assuage any concerns about opening the door to endless possible
> syntaxes for machine-readable processing of preformatted blocks being
> introduced to Gemtext, I'll retract my previous suggestion of using the
> top line for (generic) machine-readable purposes and the bottom line for
> the alt text.
>
> The only real machine-readable behavior I want to see in Gemini is
> source code syntax highlighting anyway, and the spec already supports
> and encourages that. In all other cases, alt text (which can clearly be
> ignored or used "at the client's discretion" as per the spec) is just
> fine on the top line of preformatted blocks. I suppose I don't really
> see much machine-readable value in tagging a block as "image" or "table"
> currently anyway. YMMV
>
> To that end, maybe we just need some community agreement (and/or a
> clearer codification in the Gemini spec) of how to use alt text "for
> computer source code to identify the programming language which advanced
> clients may use for syntax highlighting".

Whilst I think it is nice to support a practice of source code language 
labelling (to assist syntax highlighting), I think it would be 
insufficient to cover current usage practice.

In particular, I'm thinking of ANSI markup that some authors sprinkle in 
their content.

ANSI codes are effectively platform-specific formatting instructions 
(for example foreground, background colours) that are unique to a 
terminal type client.

If authors wish to use these in preformatted regions, they really should 
be hinting this to the client so that the client can take appropriate 
steps to render (or ignore) the terminal ANSI codes. The interpretation 
of these terminal escape codes is not treating the content as plain 
text, but rather to take a particular content interpretation, to drive 
the visual UI. Similar to embedded <font> tags, you might say.

So this in itself suggests the need to be able to hint at content-type 
in the preformatted region.

e.g.

```text/x-ansi
(ANSI marked up content in color etc)
``

(or perhaps ```content-type: text/x-ansi to label it correctly)

Or are we going to say these implementation terminal escape codes are 
left as an ad-hoc convention? That seems to have its own risks as 
discussed on this thread and elsewhere.

Best Wishes


  - Luke

From meff at meff.me  Fri Sep 11 20:09:33 2020
From: meff at meff.me (meff)
Date: Fri, 11 Sep 2020 12:09:33 -0700
Subject: HTML as an escape hatch
In-Reply-To: <87v9gk9p85.fsf@disroot.org>
References: <20200911150502.u2u5iuhd7uxiwv2a@GLaDOS>
 <87v9gk9p85.fsf@disroot.org>
Message-ID: <87r1r8uo42.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

Gary Johnson <lambdatronic at disroot.org> writes:

> However, I do want to throw in a counterpoint to recommending people
> abandon Gemtext and serve up more Markdown or HTML in Geminispace.
>
> While it is true that they can all be served up by the Gemini protocol,
> it is not currently the case that very many Gemini clients can render
> anything other than Gemtext. If enough people start to publish in
> Markdown and/or HTML, we may soon find our experience of surfing
> Geminispace to largely be about downloading Markdown and HTML pages
> whenever we click on links and then having to open the local files in
> our format-specific renderers of choice.

I see this largely as a feature, not a bug. HTML desired to be just
this, the de facto and de jure landing spot on the web. It's now become
a vehicle for everything: for applications hooking into a Document
Object Model to modify state, for semantic markup, and for layout. This
has also largely driven innovation into HTML away from other formats,
because HTML is the format that everyone sees.

> This does not sound like much fun to me, and it would impose a much
> higher development cost on each browser developer as they would have to
> implement rendering engines for Gemtext, Markdown, HTML, etc. in order
> to provide their users with a more seamless browsing experience.

Lightweight markup formats like Markdown and ReST are readable without
your browser formatting anything. Lightweight clients can get away with
not parsing anything and dumping a set of MIME types directly to the
user (either on-screen, to stdout, or however the browser works). HTML
has high quality parser implementations on various platforms in various
languages. XML also usually has good quality parsers available on most
platforms/languages. HNGopher, a Hacker News Gopher mirror, uses w3m to
render HTML content into plain text. Nothing is stopping Gemini browsers
from shelling out to w3m on platforms that have it available and
rendering content this way.

- meff

From mailinglists at ngalt.com  Fri Sep 11 20:27:11 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Fri, 11 Sep 2020 12:27:11 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200911074406.GF19614@brevard.conman.org>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>
 <20200911074406.GF19614@brevard.conman.org>
Message-ID: <EA3D0234-21FF-470C-B3D5-AD480C776902@ngalt.com>


> On Sep 11, 2020, at 12:44 AM, Sean Conner <sean at conman.org> wrote:
> 
> It was thus said that the Great Nathan Galt once stated:
>> 
>>> On Sep 10, 2020, at 5:30 PM, Sean Conner <sean at conman.org> wrote:
>>> 
>>> I added the following non-standard document:
>>> 
>>> 	gemini://gemini.conman.org/test/preformat.gemini
>>> 
>>> that contains "machine readable text" at the opening preformatted marker,
>>> and a "human readable text" on the ending preformatted marker, just to give
>>> an indication of what it might look like and what might be done with it. 
>>> Enough talk, *someone* has to do an implementation to scare the bejeezus out
>>> of everyone (not that it's particularly scary in what I did).
>>> 
>>> -spc (HTML people.  Seriously, HTML.  You want your format, you have it
>>> 	already ... )
>> 
>> I like sets of concrete examples. Thanks for whipping this up.
>> 
>> What I dislike about this style of ??machine-readable? text up top? (for
>> some definition of ?machine-readable?) is that the alt-text function has
>> been entirely obliterated, at least in these examples.
>> 
>> For the two code bits at the top of the page, the alt text should be the
>> contents of the captions at the bottom of each.
>> 
>> For the three ?images?, the alt-text should be something like:
>> 
>> - a dragon
>> - Merry Christmas
>> - a Christmas tree with a rabbit sitting near its base
> 
>  Okay, check out
> 
> 	gemini://gemini.conman.org/test/preformat-2.gemini
> 
>  -spc (Taking away my fun with the alt-text ... )

Much better.

I don?t know if ?image? before the ASCII-art images is, or would be, useful to anything.

It seems a little weird to see ? code Lua? instead of ?lua?, and I don?t know how easy it would be to adjust syntax-coloring libraries to account for this, but this nitpick is largely immaterial.

Like with the last one, thanks for making a concrete example.

From mailinglists at ngalt.com  Fri Sep 11 20:56:08 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Fri, 11 Sep 2020 12:56:08 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <5F5BC3B7.6000000@marmaladefoo.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
 <87zh5w9q94.fsf@disroot.org> <5F5BC3B7.6000000@marmaladefoo.com>
Message-ID: <2BC23E3A-CDAF-46ED-9193-E2149A345C5A@ngalt.com>



> On Sep 11, 2020, at 11:36 AM, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> 
> 
> On 11-Sep-2020 18:28, Gary Johnson wrote:
>> [...]
>> 
>> To assuage any concerns about opening the door to endless possible
>> syntaxes for machine-readable processing of preformatted blocks being
>> introduced to Gemtext, I'll retract my previous suggestion of using the
>> top line for (generic) machine-readable purposes and the bottom line for
>> the alt text.
>> 
>> The only real machine-readable behavior I want to see in Gemini is
>> source code syntax highlighting anyway, and the spec already supports
>> and encourages that. In all other cases, alt text (which can clearly be
>> ignored or used "at the client's discretion" as per the spec) is just
>> fine on the top line of preformatted blocks. I suppose I don't really
>> see much machine-readable value in tagging a block as "image" or "table"
>> currently anyway. YMMV
>> 
>> To that end, maybe we just need some community agreement (and/or a
>> clearer codification in the Gemini spec) of how to use alt text "for
>> computer source code to identify the programming language which advanced
>> clients may use for syntax highlighting".
> 
> Whilst I think it is nice to support a practice of source code language labelling (to assist syntax highlighting), I think it would be insufficient to cover current usage practice.
> 
> In particular, I'm thinking of ANSI markup that some authors sprinkle in their content.
> 
> ANSI codes are effectively platform-specific formatting instructions (for example foreground, background colours) that are unique to a terminal type client.
> 
> If authors wish to use these in preformatted regions, they really should be hinting this to the client so that the client can take appropriate steps to render (or ignore) the terminal ANSI codes. The interpretation of these terminal escape codes is not treating the content as plain text, but rather to take a particular content interpretation, to drive the visual UI. Similar to embedded <font> tags, you might say.
> 
> So this in itself suggests the need to be able to hint at content-type in the preformatted region.
> 
> e.g.
> 
> ```text/x-ansi
> (ANSI marked up content in color etc)
> ``
> 
> (or perhaps ```content-type: text/x-ansi to label it correctly)
> 
> Or are we going to say these implementation terminal escape codes are left as an ad-hoc convention? That seems to have its own risks as discussed on this thread and elsewhere.
> 
> Best Wishes
> 
> 
> - Luke

[shock and horror that people are using ANSI codes for color]

Prior reading:

=> https://en.wikipedia.org/wiki/Escape_character#ASCII_escape_character
=> https://the.exa.website/ a modern ls(1) replacement

I think ANSI color codes are up to 24-bit color now. Not all terminals support them (Terminal.app doesn?t; iTerm2 does), but they?re out there. I was looking up color codes so I could make my EXA_COLORS variable nicer and the whole process wasn?t pleasant.

Sounds like a good reason to explicitly disallow U+001B in the text/gemini spec and:

- give dirty looks to any page author that uses it
- give dirty looks to any client author that doesn?t strip it out before presenting it to the user (whether the client is terminal-based or in a GUI)



From sean at conman.org  Fri Sep 11 20:57:48 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Sep 2020 15:57:48 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <EA3D0234-21FF-470C-B3D5-AD480C776902@ngalt.com>
References: <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>
 <20200911074406.GF19614@brevard.conman.org>
 <EA3D0234-21FF-470C-B3D5-AD480C776902@ngalt.com>
Message-ID: <20200911195748.GG19614@brevard.conman.org>

It was thus said that the Great Nathan Galt once stated:
> 
> > On Sep 11, 2020, at 12:44 AM, Sean Conner <sean at conman.org> wrote:
> > 
> >  Okay, check out
> > 
> > 	gemini://gemini.conman.org/test/preformat-2.gemini
> 
> Much better.
> 
> I don?t know if ?image? before the ASCII-art images is, or would be,
> useful to anything.

  It would prevent a screen reader from reading "circumflex circumflex next
line slash backslash slash slash backslash nextline ..."

> It seems a little weird to see ? code Lua? instead of ?lua?, and I don?t
> know how easy it would be to adjust syntax-coloring libraries to account
> for this, but this nitpick is largely immaterial.

  Do you really want a client to have to list all these languages?

	https://en.wikipedia.org/wiki/List_of_programming_languages

  At least with the prefix "code" the client can know it's source code, even
if it doesn't what the language is.  And having the language can let a
client syntax highlight for those languages it does know.  That was my
reasoning.

> Like with the last one, thanks for making a concrete example.

  You're welcome.

  -spc


From sean at conman.org  Fri Sep 11 21:16:03 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Sep 2020 16:16:03 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <2BC23E3A-CDAF-46ED-9193-E2149A345C5A@ngalt.com>
References: <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
 <87zh5w9q94.fsf@disroot.org> <5F5BC3B7.6000000@marmaladefoo.com>
 <2BC23E3A-CDAF-46ED-9193-E2149A345C5A@ngalt.com>
Message-ID: <20200911201603.GH19614@brevard.conman.org>

It was thus said that the Great Nathan Galt once stated:
> 
> On Sep 11, 2020, at 11:36 AM, Luke Emmet <luke at marmaladefoo.com> wrote:
> > 
> > Or are we going to say these implementation terminal escape codes are
> > left as an ad-hoc convention? That seems to have its own risks as
> > discussed on this thread and elsewhere.
> 
> [shock and horror that people are using ANSI codes for color]

  I've come across ECMA-48 [1] code usage on both gopher and Gemini.  It is
being done.

> Prior reading:
> 
> => https://en.wikipedia.org/wiki/Escape_character#ASCII_escape_character
> => https://the.exa.website/ a modern ls(1) replacement
> 
> I think ANSI color codes are up to 24-bit color now. Not all terminals
> support them (Terminal.app doesn?t; iTerm2 does), but they?re out there. I
> was looking up color codes so I could make my EXA_COLORS variable nicer
> and the whole process wasn?t pleasant.
> 
> Sounds like a good reason to explicitly disallow U+001B in the text/gemini
> spec and:

  Ban ESC and I can *still* send the codes.  The sequence '<ESC>[' is the
CONTROL SEQUENCE INTRODUCER and is only one of two ways it is represented. 
The other way is with codepoint 155 [2].  To be truely safe, you need to
filter out all control codes (control set 0, from 0 to 31, 127 (which is
technically not in any control set, and control set 1, from 128 to 159) with
the exception of HT (horizonantal tab), CR (carriage return) and LF (line
feed).

  -spc (Did a deep dive into a few years ago ... )

[1]	ECMA-48 is the actual standard describing these codes.  ANSI got out
	of the game in the 80s (or maybe very early 90s) if I recall
	correctly.

[2]	In any of the ISO 8-bit character sets, this is character 155.
	Unicode also uses this value, but when encoded as UTF-8, it's
	represented as the bytes 194,155.

From mailinglists at ngalt.com  Fri Sep 11 21:22:47 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Fri, 11 Sep 2020 13:22:47 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200911195748.GG19614@brevard.conman.org>
References: <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>
 <20200911074406.GF19614@brevard.conman.org>
 <EA3D0234-21FF-470C-B3D5-AD480C776902@ngalt.com>
 <20200911195748.GG19614@brevard.conman.org>
Message-ID: <D48DB569-FEB5-4790-B905-7E91AA6A3FF1@ngalt.com>



> On Sep 11, 2020, at 12:57 PM, Sean Conner <sean at conman.org> wrote:
> 
> It was thus said that the Great Nathan Galt once stated:
>> 
>>> On Sep 11, 2020, at 12:44 AM, Sean Conner <sean at conman.org> wrote:
>>> 
>>> Okay, check out
>>> 
>>> 	gemini://gemini.conman.org/test/preformat-2.gemini
>> 
>> Much better.
>> 
>> I don?t know if ?image? before the ASCII-art images is, or would be,
>> useful to anything.
> 
>  It would prevent a screen reader from reading "circumflex circumflex next
> line slash backslash slash slash backslash nextline ??

Oh, huh. My assumption would be that screenreaders wouldn?t read anything in preformatted-text blocks if there were any alt text available.

(Yes, my assumption is that 99.9999% of the time, the page will download faster than a screenreader can speak.)

Back in HTML land, if an image has no alt attribute at all, the usual screenreader behavior is to read the filename out loud. Because this is time-wasting noise 99.999% of the time, web authors are repeatedly urged to add `alt=??` (empty alt attributes) to images that blind people don?t need to care about (purely presentational ones, for example).

At any rate, if I were blind, I?d want a ?skip past the preformatted block I?m in? if my client were set to read out preformatted-text blocks. I have no idea how hard this would be to program in a GUI-based Gemini client, though, for any OS.

>> It seems a little weird to see ? code Lua? instead of ?lua?, and I don?t
>> know how easy it would be to adjust syntax-coloring libraries to account
>> for this, but this nitpick is largely immaterial.
> 
>  Do you really want a client to have to list all these languages?

Seems doable to me:

> bat --list-languages | wc -l
     147

?and <https://github.com/sharkdp/bat> is merely a supercharged cat(1) clone.

<https://pygments.org/> boasts support for ?over 500? languages/text formats.

> At least with the prefix "code" the client can know it's source code, even
> if it doesn't what the language is.  And having the language can let a
> client syntax highlight for those languages it does know.  That was my
> reasoning.

Good choice.

From mailinglists at ngalt.com  Fri Sep 11 21:30:23 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Fri, 11 Sep 2020 13:30:23 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200911201603.GH19614@brevard.conman.org>
References: <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
 <87zh5w9q94.fsf@disroot.org> <5F5BC3B7.6000000@marmaladefoo.com>
 <2BC23E3A-CDAF-46ED-9193-E2149A345C5A@ngalt.com>
 <20200911201603.GH19614@brevard.conman.org>
Message-ID: <385A4390-7F0E-4DAF-9BBB-198A17D433B0@ngalt.com>



> On Sep 11, 2020, at 1:16 PM, Sean Conner <sean at conman.org> wrote:
> 
> It was thus said that the Great Nathan Galt once stated:
>> 
>> On Sep 11, 2020, at 11:36 AM, Luke Emmet <luke at marmaladefoo.com> wrote:
>>> 
>>> Or are we going to say these implementation terminal escape codes are
>>> left as an ad-hoc convention? That seems to have its own risks as
>>> discussed on this thread and elsewhere.
>> 
>> [shock and horror that people are using ANSI codes for color]
> 
>  I've come across ECMA-48 [1] code usage on both gopher and Gemini.  It is
> being done.
> 
>> Prior reading:
>> 
>> => https://en.wikipedia.org/wiki/Escape_character#ASCII_escape_character
>> => https://the.exa.website/ a modern ls(1) replacement
>> 
>> I think ANSI color codes are up to 24-bit color now. Not all terminals
>> support them (Terminal.app doesn?t; iTerm2 does), but they?re out there. I
>> was looking up color codes so I could make my EXA_COLORS variable nicer
>> and the whole process wasn?t pleasant.
>> 
>> Sounds like a good reason to explicitly disallow U+001B in the text/gemini
>> spec and:
> 
>  Ban ESC and I can *still* send the codes.  The sequence '<ESC>[' is the
> CONTROL SEQUENCE INTRODUCER and is only one of two ways it is represented. 
> The other way is with codepoint 155 [2].  To be truely safe, you need to
> filter out all control codes (control set 0, from 0 to 31, 127 (which is
> technically not in any control set, and control set 1, from 128 to 159) with
> the exception of HT (horizonantal tab), CR (carriage return) and LF (line
> feed).
> 

=> https://en.wikipedia.org/wiki/C0_and_C1_control_codes

Ooh, good catch. Yeah, ban ?em all except \t, \r, and \n.

From tomasino at lavabit.com  Fri Sep 11 21:33:21 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 11 Sep 2020 20:33:21 +0000
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <D48DB569-FEB5-4790-B905-7E91AA6A3FF1@ngalt.com>
References: <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>
 <20200911074406.GF19614@brevard.conman.org>
 <EA3D0234-21FF-470C-B3D5-AD480C776902@ngalt.com>
 <20200911195748.GG19614@brevard.conman.org>
 <D48DB569-FEB5-4790-B905-7E91AA6A3FF1@ngalt.com>
Message-ID: <653a803d-39dd-dffc-0d74-df907cc7c352@lavabit.com>

On 9/11/20 8:22 PM, Nathan Galt wrote:
> Oh, huh. My assumption would be that screenreaders wouldn?t read anything in preformatted-text blocks if there were any alt text available.
> 
> (Yes, my assumption is that 99.9999% of the time, the page will download faster than a screenreader can speak.)
> 
> Back in HTML land, if an image has no alt attribute at all, the usual screenreader behavior is to read the filename out loud. Because this is time-wasting noise 99.999% of the time, web authors are repeatedly urged to add `alt=??` (empty alt attributes) to images that blind people don?t need to care about (purely presentational ones, for example).
> 
> At any rate, if I were blind, I?d want a ?skip past the preformatted block I?m in? if my client were set to read out preformatted-text blocks. I have no idea how hard this would be to program in a GUI-based Gemini client, though, for any OS.

I've invited the Rhapsode maintainer to join us on the mailing list so we can get the perspective of a dev of an actual accessible gemini client. I hope that will help guide our assumptions in this area better. My own expectations of how a screen reader would work differ a bit from what you're saying, but rather than muddy the waters more I'll wait and hope Adrian jumps in here.


From mailinglists at ngalt.com  Fri Sep 11 21:55:05 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Fri, 11 Sep 2020 13:55:05 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <653a803d-39dd-dffc-0d74-df907cc7c352@lavabit.com>
References: <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost> <871rj9fuqp.fsf@disroot.org>
 <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <0FDC124F-8F0E-4B80-99CF-D79CB095CF48@ngalt.com>
 <20200911074406.GF19614@brevard.conman.org>
 <EA3D0234-21FF-470C-B3D5-AD480C776902@ngalt.com>
 <20200911195748.GG19614@brevard.conman.org>
 <D48DB569-FEB5-4790-B905-7E91AA6A3FF1@ngalt.com>
 <653a803d-39dd-dffc-0d74-df907cc7c352@lavabit.com>
Message-ID: <BAAA6415-D15F-475E-A04F-742EB2C849BE@ngalt.com>


> On Sep 11, 2020, at 1:33 PM, James Tomasino <tomasino at lavabit.com> wrote:
> 
> On 9/11/20 8:22 PM, Nathan Galt wrote:
>> Oh, huh. My assumption would be that screenreaders wouldn?t read anything in preformatted-text blocks if there were any alt text available.
>> 
>> (Yes, my assumption is that 99.9999% of the time, the page will download faster than a screenreader can speak.)
>> 
>> Back in HTML land, if an image has no alt attribute at all, the usual screenreader behavior is to read the filename out loud. Because this is time-wasting noise 99.999% of the time, web authors are repeatedly urged to add `alt=??` (empty alt attributes) to images that blind people don?t need to care about (purely presentational ones, for example).
>> 
>> At any rate, if I were blind, I?d want a ?skip past the preformatted block I?m in? if my client were set to read out preformatted-text blocks. I have no idea how hard this would be to program in a GUI-based Gemini client, though, for any OS.
> 
> I've invited the Rhapsode maintainer to join us on the mailing list so we can get the perspective of a dev of an actual accessible gemini client. I hope that will help guide our assumptions in this area better. My own expectations of how a screen reader would work differ a bit from what you're saying, but rather than muddy the waters more I'll wait and hope Adrian jumps in here.

Good call. I?ve used VoiceOver occasionally on iOS (it can be difficult to see your phone?s screen when you?re donating platelets), but I?m mostly a tourist when it comes to designing things for blind people.

I have a lot more experience using voice _control_ on Windows Vista, but I haven?t noticed any potential issues with the format that might seriously impact people whose arms don?t work right for long periods of time.

From easeout at tilde.team  Sat Sep 12 00:23:13 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Fri, 11 Sep 2020 19:23:13 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200910064007.gytc42v4snepgmix@localhost>
 <871rj9fuqp.fsf@disroot.org> <20200910234617.GE1964344@tilde.team>
 <20200911003042.GC19614@brevard.conman.org>
 <87363ox4jc.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <20200911232313.GI1964344@tilde.team>

On Thu, Sep 10, 2020 at 10:31:51PM -0700, Meff wrote:
> (Apologies for the double email Sean, I forgot to Reply All)
> 
> Sean Conner <sean at conman.org> writes:
> 
> >   And back in the mid-90s, there *were* plenty of web clients.  Easily a
> > dozen that were easily available and that was back in time when it was easy
> > enough to parse HTML, there was no CSS and no Javascript, and it was
> > conceivable that someone could write a simple web browser in a weekend [1].
> >
> >   Then Sandra Snan sent the following link:
> >
> > 	https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
> >
> > Wherein it's mentioned that the current "state of the web" is described by
> > 114,000,000 words spread across 1,217 standards documents.  You get here by
> > incremental changes, all of which are "easy" and "it would be so
> > nice."
> 
> I agree with this. I understand that there's a couple points here that
> the alt-text discussion is trying to solve:
> 
> * Formatting hints for non-human clients
> ** Specifically this benefits users that may be visually impaired and
>    their use of tools such as screen readers
> * Hints or descriptions for human readers
> 
> I don't see a way out of this without making Gemtext much more
> complicated than it is now.

Here are a few options that avoid complicating Gemtext.

1. Use alt text only as an accessible content description for humans.
   (not a tooltip or caption)
2. Use alt text only as a formatting hint for machine use. Rename it.
3. Get rid of alt text entirely.

All of these options attempt to solve the problem that alt text
currently has multiple uses and would not be reliable to a user who
needed it for a particular use. Any of these options would mean altering
the spec. I like option 1 best.

The reason I didn't mind syntax-on-top, alt-on-bottom was that it solved
the problem of one field with multiple uses, by making them two fields.
However it would complicate Gemtext and I agree we don't need to
do that.

From bouncepaw2 at yandex.ru  Sat Sep 12 09:45:05 2020
From: bouncepaw2 at yandex.ru (Timur Ismagilov)
Date: Sat, 12 Sep 2020 13:45:05 +0500
Subject: A proposed scheme for parsing preformatted alt text
Message-ID: <830131599900305@myt6-6c65baa90efa.qloud-c.yandex.net>

I've written a gemlog post on the topic of extending gemtext and using something other than gemtext. I hope it'll be of an interest.
=> gemini://tanelorn.city/~bouncepaw/gemlog/html-over.gemini

From gmym at coopdot.com  Sat Sep 12 17:11:53 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sat, 12 Sep 2020 18:11:53 +0200
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200911001631.GF1964344@tilde.team>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200911001631.GF1964344@tilde.team>
Message-ID: <CAObwWNgo0BAAt_mFpfwmAmwrE81mrg9qNo361_BO7KLkjPGzvg@mail.gmail.com>

<easeout at tilde.team> wrote:

I think it would also be suitable to change the name from "alt text" to
something like "accessibile description".


Changing the name to something to do with accessibility is something I
agree with. While we're at it, let's also change the name of the "```"
lines to "plain text mode switch" so that it doesn't remind us of <pre>
elements which are blocks.

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200912/a9758cfd/attachment.htm>

From mailinglists at ngalt.com  Sat Sep 12 21:01:48 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sat, 12 Sep 2020 13:01:48 -0700
Subject: Critique my setup, please
Message-ID: <327BADF6-89C8-4F19-BDCD-9CAAD2142FDB@ngalt.com>

I?m setting up a capsule on a VPS served up with Molly Brown. I?d like to get some feedback on what I should be doing, in case I?m doing something egregiously wrong. The capsule isn?t intended to be permanent, at least not yet, so I?m giving it the domain name of beepbeepbeep.example.

(It was only after I decided I should post this that I remembered that the best way to get good advice on the Internet is to post bad advice?)

I wasn?t sure how to make/get certs, so I stumbled around and found this:

https://github.com/michael-lazar/jetforce#tls-certificates

And then there?s also

sudo certbot certonly --standalone

as shown on <https://certbot.eff.org/lets-encrypt/ubuntufocal-other>.

I?m waffling back and forth on whether I should stick everything in some unprivileged user?s home directory (much like I do here) or if I should put things in ?proper? places like /var/gemini. Opinions welcome. I do not intend for humans other than me to be inside this server ever.

Without further ado, the commands I used just now:

- - - - - - - - - 8< - - - - - - - - - 

#!/bin/bash
apt update
apt upgrade --yes

apt install --yes fish bat
ln -s /usr/bin/batcat /usr/local/bin/bat

mkdir /etc/skel/.ssh
cp ~/.ssh/authorized_keys /etc/skel/.ssh/

addgroup certview

# named after Gus Grissom, who named the Gemini 3 capsule ?Molly Brown?
adduser --shell /usr/bin/fish --disabled-password --gecos -- griss
usermod -aG certview griss

snap install --classic certbot
certbot certonly --standalone \
    --non-interactive \
    --agree-tos \
    --domains "gemini.beepbeepbeep.example" \
    --register-unsafely-without-email

chmod 0755     /etc/letsencrypt/{live,archive}
chmod g+r      /etc/letsencrypt/archive/gemini.beepbeepbeep.example/privkey1.pem
chgrp certview /etc/letsencrypt/archive/gemini.beepbeepbeep.example/privkey1.pem

cat << 'EOF' > /etc/molly.conf
Hostname = "gemini.beepbeepbeep.example"
DefaultLang = "en-US"

DocBase =   "/home/griss/public"
AccessLog = "/home/griss/access.log"
ErrorLog =  "/home/griss/error.log"

CertPath = "/etc/letsencrypt/live/gemini.beepbeepbeep.example/fullchain.pem"
KeyPath =  "/etc/letsencrypt/live/gemini.beepbeepbeep.example/privkey.pem"

[MimeOverrides]
"atom.xml$" = "application/atom+xml"
EOF

cat << 'EOF' > /etc/systemd/system/molly-brown.service
[Unit]
Description=Molly Brown gemini server
After=network.target

[Service]
Type=simple
Restart=on-failure
User=griss
ExecStart=/home/griss/go/bin/molly-brown

NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/home/griss/access.log /home/griss/error.log

[Install]
WantedBy=multi-user.target
EOF

systemctl enable molly-brown.service 

# Much later?
systemctl start molly-brown.service 

#######################################
# As griss?

wget https://golang.org/dl/go1.15.2.linux-amd64.tar.gz
tar xf go*
mv go go-dist
mkdir go

./go-dist/bin/go get tildegit.org/solderpunk/molly-brown

# openssl req -newkey rsa:2048 -nodes -keyout gemini.beepbeepbeep.example.key \
#    -nodes -x509 -out gemini.beepbeepbeep.example.crt -subj "/CN=gemini.beepbeepbeep.example"

mkdir public

printf "# It works!\n\nYour Gemini capsule is up and running.\n" > public/index.gmi




From easeout at tilde.team  Sat Sep 12 21:40:33 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Sat, 12 Sep 2020 16:40:33 -0400
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <CAObwWNgo0BAAt_mFpfwmAmwrE81mrg9qNo361_BO7KLkjPGzvg@mail.gmail.com>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com>
 <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200911001631.GF1964344@tilde.team>
 <CAObwWNgo0BAAt_mFpfwmAmwrE81mrg9qNo361_BO7KLkjPGzvg@mail.gmail.com>
Message-ID: <20200912204033.GJ1964344@tilde.team>

On Sat, Sep 12, 2020 at 06:11:53PM +0200, Katarina Eriksson wrote:
> <easeout at tilde.team> wrote:
> 
>> I think it would also be suitable to change the name from "alt text" to
>> something like "accessibile description".
> 
> Changing the name to something to do with accessibility is something I
> agree with.

For what it's worth, when I suggested the name change I thought that
HTML IMG "alt" was the tooltip and "title" was the accessible
description. But in fact that is backwards; alt text is the accessible
description. So at this point I don't think a name change is necessary.
I'm not opposed to renaming, though, if it would avoid repeating the
misunderstanding I had.

From colecmac at protonmail.com  Sun Sep 13 00:54:44 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 12 Sep 2020 23:54:44 +0000
Subject: Critique my setup, please
In-Reply-To: <327BADF6-89C8-4F19-BDCD-9CAAD2142FDB@ngalt.com>
References: <327BADF6-89C8-4F19-BDCD-9CAAD2142FDB@ngalt.com>
Message-ID: <YE1mG2DdsGq8ZoFZolqtt2_YLGvEpzAJRFeUzMv2Dh_TJl07ibX4YyChHbVTUfmotcRwFn9dXYluHhZ_BklQzT11SYQ9RIFs-T4c7xVEwAg=@protonmail.com>

Hello, welcome to Gemini!

I can't speak to your Molly Brown setup, as I don't use it,
but I can offer some advice for certificates. I've actually
written a whole post on how to generate nice Gemini certs
here:

gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi

The main difference from what you've done is that these certs
are valid for 5 years, so you'll change them less often, and
that they use EC keys, making the cert size (and therefore
request overhead) much smaller.

Cheers!
makeworld

From mailinglists at ngalt.com  Sun Sep 13 01:21:28 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sat, 12 Sep 2020 17:21:28 -0700
Subject: A proposed scheme for parsing preformatted alt text
In-Reply-To: <20200912204033.GJ1964344@tilde.team>
References: <5F556ED0.4060504@marmaladefoo.com>
 <20200907213805.2c119a34.me@ecmelberk.com>
 <87r1rdjqc0.fsf@idiomdrottning.org>
 <20200909173856.xjqha43dru34fh2w@localhost>
 <5F594BF8.7070904@marmaladefoo.com> <20200909232814.GB1964344@tilde.team>
 <C394CDCA-6CBB-4341-9D37-B92B810CF6D4@ngalt.com>
 <20200910155534.z7gml3adywayhqiw@GLaDOS>
 <20200911001631.GF1964344@tilde.team>
 <CAObwWNgo0BAAt_mFpfwmAmwrE81mrg9qNo361_BO7KLkjPGzvg@mail.gmail.com>
 <20200912204033.GJ1964344@tilde.team>
Message-ID: <1F1D5565-6F78-4B1C-84D9-253E8FD9B735@ngalt.com>


> On Sep 12, 2020, at 1:40 PM, easeout at tilde.team wrote:
> 
> On Sat, Sep 12, 2020 at 06:11:53PM +0200, Katarina Eriksson wrote:
>> <easeout at tilde.team> wrote:
>> 
>>> I think it would also be suitable to change the name from "alt text" to
>>> something like "accessibile description".
>> 
>> Changing the name to something to do with accessibility is something I
>> agree with.
> 
> For what it's worth, when I suggested the name change I thought that
> HTML IMG "alt" was the tooltip and "title" was the accessible
> description. But in fact that is backwards; alt text is the accessible
> description. So at this point I don't think a name change is necessary.
> I'm not opposed to renaming, though, if it would avoid repeating the
> misunderstanding I had.

=> https://stackoverflow.com/questions/1734806/ Background reading and linkage

Most graphical browsers displayed the contents of the `alt` attribute in a tooltip for a decade+, in addition to showing it when images hadn?t loaded (yet). People used to write ?alt text? for people who may or may not be able to see the image.

Then Firefox said ?No, we?re not doing that. It misleads HTML authors into thinking that the value of the  `alt` attribute is for people who can see the image already. If you want tooltips, put your tooltip text into the `title` attribute; Internet Explorer handles that just fine, too.?

Much wailing and gnashing of teeth ensued, but just about everyone got over it.

I don?t think many people today are liable to get their wires crossed like this. Referring to tooltip text as ?alt text? strikes me as a late-90s affectation, and I don?t think new authors are liable to slip into this mistake easily.

From dealpete at fastmail.com  Sun Sep 13 01:35:05 2020
From: dealpete at fastmail.com (Peter Deal)
Date: Sat, 12 Sep 2020 22:05:05 -0230
Subject: MacOS Gemini Client
Message-ID: <B6478A1F-387B-4AC1-AE44-0212A3ADE5B1@fastmail.com>

Hello Geminauts!

I?d like to announce that I?ve created a Gemini client for MacOS. It?s a graphical client that uses native OS UI elements. You can check it out at

https://github.com/dealpete/sputnik

I?ve written a little gemlog post about some of my design decisions here

gemini://gemini.circumlunar.space/users/dealpete/

It?s still a work in progress, missing a few features like client-side certificates, but it?s sufficient to explore the majority of the current Gemiverse. If anyone tries it out, I?m happy to receive feedback, and feel free to post issues on the Github page.

Best Regards,
Peter

From easeout at tilde.team  Sun Sep 13 02:47:12 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Sat, 12 Sep 2020 21:47:12 -0400
Subject: MacOS Gemini Client
In-Reply-To: <B6478A1F-387B-4AC1-AE44-0212A3ADE5B1@fastmail.com>
References: <B6478A1F-387B-4AC1-AE44-0212A3ADE5B1@fastmail.com>
Message-ID: <20200913014712.GK1964344@tilde.team>

On Sat, Sep 12, 2020 at 10:05:05PM -0230, Peter Deal wrote:
> Hello Geminauts!
> 
> I?d like to announce that I?ve created a Gemini client for MacOS. It?s a graphical client that uses native OS UI elements. You can check it out at
> 
> https://github.com/dealpete/sputnik

This is great! Please let me know if I can help you get unstuck on
anything; I know the Apple dev world pretty well.

> I?ve written a little gemlog post about some of my design decisions here
> 
> gemini://gemini.circumlunar.space/users/dealpete/

You mentioned in your post that SwiftUI lacks some capabilties compared
to AppKit, and that's true. In its first release year it has really been
kind of a preview. This year's release does a lot to make it feel more
complete. That's currently in Xcode 12 beta. Here's an introduction to
the changes (video + transcript):

https://developer.apple.com/videos/play/wwdc2020/10041/

From jansen.price at gmail.com  Sun Sep 13 03:12:28 2020
From: jansen.price at gmail.com (Jansen Price)
Date: Sat, 12 Sep 2020 21:12:28 -0500
Subject: Critique my setup, please
In-Reply-To: <mailman.187.1599957316.459.gemini@lists.orbitalfox.eu>
References: <mailman.187.1599957316.459.gemini@lists.orbitalfox.eu>
Message-ID: <CAJyFNOxJhLkvqTx8OfA+TVVnbMU3K20HU+0ra8vuQKbWY13TYA@mail.gmail.com>

> ExecStart=/home/griss/go/bin/molly-brown

Do you need to make the execution of molly brown to include -c?
e.g. ExecStart=/home/griss/go/bin/molly-brown -c /etc/molly.conf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200912/f7b8abae/attachment.htm>

From mailinglists at ngalt.com  Sun Sep 13 03:18:16 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sat, 12 Sep 2020 19:18:16 -0700
Subject: Critique my setup, please
In-Reply-To: <CAJyFNOxJhLkvqTx8OfA+TVVnbMU3K20HU+0ra8vuQKbWY13TYA@mail.gmail.com>
References: <mailman.187.1599957316.459.gemini@lists.orbitalfox.eu>
 <CAJyFNOxJhLkvqTx8OfA+TVVnbMU3K20HU+0ra8vuQKbWY13TYA@mail.gmail.com>
Message-ID: <DD21692D-E1E6-40E3-9B19-1C5BE45FE518@ngalt.com>


> On Sep 12, 2020, at 7:12 PM, Jansen Price <jansen.price at gmail.com> wrote:
> 
> > ExecStart=/home/griss/go/bin/molly-brown
> 
> Do you need to make the execution of molly brown to include -c?
> e.g. ExecStart=/home/griss/go/bin/molly-brown -c /etc/molly.conf

-c overrides the default of /etc/molly.conf.

From mailinglists at ngalt.com  Sun Sep 13 03:46:12 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sat, 12 Sep 2020 19:46:12 -0700
Subject: =?utf-8?Q?Optional/mandatory_whitespace_in_=C2=A75=2E5_Advanced_l?=
 =?utf-8?Q?ine_types?=
Message-ID: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>

Prior reading:

=> https://gemini.circumlunar.space/docs/specification.html The Spec, ?5.5 Advanced line types

I noticed that the spec has three different advanced line types and three different whitespace handling verbiages for each.

Heading lines: Start with 1?3 ?#?, then optional whitespace.
List items: Start with ?* ? (note the space!)
Quote lines: Start with ?>? 

Shouldn?t these three have the same whitespace rules, with the same phrasing?

Here?s my argument for ?mandatory whitespace for all? ([\t ]+):

- It lets authors write ?#3. I like eggs.? without accidentally getting that line parsed as if it were a heading (we don?t have backslash escapes like Markdown does)
- It?s better for some emoticons that, um, might be out there that start with > or *
- ?#Steak? looks like a hashtag, and I could see some fraction of authors writing ?#blah? _meaning_ for it to be a tag
- We shouldn?t be worried about backcompat at v0.14.2. I don?t have much gemini text, but I?m the sort who would reformat his own non-conformant documents to match something like this.

- - - -

I could see myself wanting an H4-equivalent or higher, but I?m not certain this is _quite_ the right time to mention it. Also the current spec already seems to say that clients should parse ?#### Eggs? as not-a-heading.

From flexibeast at gmail.com  Sun Sep 13 04:02:05 2020
From: flexibeast at gmail.com (Alexis)
Date: Sun, 13 Sep 2020 13:02:05 +1000
Subject: Optional/mandatory whitespace in =?utf-8?Q?=C2=A75=2E5?=
 Advanced line types
In-Reply-To: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
References: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
Message-ID: <87y2lextua.fsf@ada>


Nathan Galt <mailinglists at ngalt.com> writes:

> Shouldn?t these three have the same whitespace rules, with the 
> same phrasing?
>
> Here?s my argument for ?mandatory whitespace for all? ([\t ]+):

Fwiw, i support this. Lately i've been spending a lot of time and 
energy on format conversions, and the more consistent the syntax, 
the easier it is to parse, and the less i have to rely on kludgy 
heuristics.


Alexis.

From easeout at tilde.team  Sun Sep 13 04:20:46 2020
From: easeout at tilde.team (easeout at tilde.team)
Date: Sat, 12 Sep 2020 23:20:46 -0400
Subject: Optional/mandatory =?iso-8859-1?Q?whit?=
 =?iso-8859-1?Q?espace_in_=A75=2E5?= Advanced line types
In-Reply-To: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
References: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
Message-ID: <20200913032046.GL1964344@tilde.team>

On Sat, Sep 12, 2020 at 07:46:12PM -0700, Nathan Galt wrote:
> I noticed that the spec has three different advanced line types and three different whitespace handling verbiages for each.
> 
> Heading lines: Start with 1?3 ?#?, then optional whitespace.
> List items: Start with ?* ? (note the space!)
> Quote lines: Start with ?>? 
> 
> Shouldn?t these three have the same whitespace rules, with the same phrasing?

I'm inclined to agree.

> Here?s my argument for ?mandatory whitespace for all? ([\t ]+):
> 
> - It lets authors write ?#3. I like eggs.? without accidentally getting that line parsed as if it were a heading (we don?t have backslash escapes like Markdown does)
> - It?s better for some emoticons that, um, might be out there that start with > or *
> - ?#Steak? looks like a hashtag, and I could see some fraction of authors writing ?#blah? _meaning_ for it to be a tag
> - We shouldn?t be worried about backcompat at v0.14.2. I don?t have much gemini text, but I?m the sort who would reformat his own non-conformant documents to match something like this.

Let's also consider the other way these three cases could have the same
whitespace rules, which is to make that whitespace always optional
rather than always required.

Pros of all-optional whitespace:
- Parsing is one step simpler than requiring at least one whitespace
  character.
- Parsing is compatible with existing Gemtext. (I also think this is not
  that big of a deal, but let's list it.)

Cons:
- At the beginning of an intended plain text line, some common forms of
  expression like "*Foo*", "#Foo", and ">_<" would be interpreted as
  list items, headings, or quotations.

?and that's all I've got. Having thought through it, I think mandatory
whitespace sounds like a better choice.

From mailinglists at ngalt.com  Sun Sep 13 06:29:03 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sat, 12 Sep 2020 22:29:03 -0700
Subject: [ANN] gemini.sublime-syntax v0.2.0, now with .mollyhead support
Message-ID: <3E18CEBD-E28E-435F-A3CC-660004C6213D@ngalt.com>

I noticed that Molly Brown supports Gemini-syntax files named ?.mollyhead? so one can have text before a directory listing. So, I added support for .mollyhead files to the .sublime-syntax file I have.

I don?t know of any other similar file extensions that might have Gemini text in them. If you know of a (dot)file that does, let me know about it so I can add it to the list.

https://github.com/adiabatic/gemini.sublime-syntax



From sandra.snan at idiomdrottning.org  Sun Sep 13 06:37:05 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Sun, 13 Sep 2020 07:37:05 +0200
Subject: Optional/mandatory whitespace in =?utf-8?Q?=C2=A75=2E5?=
 Advanced line types
In-Reply-To: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
References: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
Message-ID: <87k0wydypq.fsf@idiomdrottning.org>

I agree with mandatory whitespace except for when quoting empty lines.

Nathan Galt <mailinglists at ngalt.com> writes:

> Prior reading:
>
> => https://gemini.circumlunar.space/docs/specification.html The Spec, ?5.5 Advanced line types
>
> I noticed that the spec has three different advanced line types and three different whitespace handling verbiages for each.
>
> Heading lines: Start with 1?3 ?#?, then optional whitespace.
> List items: Start with ?* ? (note the space!)
> Quote lines: Start with ?>? 
>
> Shouldn?t these three have the same whitespace rules, with the same phrasing?
>
> Here?s my argument for ?mandatory whitespace for all? ([\t ]+):
>
> - It lets authors write ?#3. I like eggs.? without accidentally getting that line parsed as if it were a heading (we don?t have backslash escapes like Markdown does)
> - It?s better for some emoticons that, um, might be out there that start with > or *
> - ?#Steak? looks like a hashtag, and I could see some fraction of authors writing ?#blah? _meaning_ for it to be a tag
> - We shouldn?t be worried about backcompat at v0.14.2. I don?t have much gemini text, but I?m the sort who would reformat his own non-conformant documents to match something like this.
>
> - - - -
>
> I could see myself wanting an H4-equivalent or higher, but I?m not certain this is _quite_ the right time to mention it. Also the current spec already seems to say that clients should parse ?#### Eggs? as not-a-heading.

From mailinglists at ngalt.com  Sun Sep 13 07:52:28 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sat, 12 Sep 2020 23:52:28 -0700
Subject: =?utf-8?Q?Re=3A_Optional/mandatory_whitespace_in_=C2=A75=2E5_Adva?=
 =?utf-8?Q?nced_line_types?=
In-Reply-To: <87k0wydypq.fsf@idiomdrottning.org>
References: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
 <87k0wydypq.fsf@idiomdrottning.org>
Message-ID: <3F535F4D-36B3-4FED-8A3E-179EEDA403D1@ngalt.com>

Ooh, good catch.

Agreed.

> On Sep 12, 2020, at 10:37 PM, Sandra Snan <sandra.snan at idiomdrottning.org> wrote:
> 
> I agree with mandatory whitespace except for when quoting empty lines.
> 
> Nathan Galt <mailinglists at ngalt.com> writes:
> 
>> Prior reading:
>> 
>> => https://gemini.circumlunar.space/docs/specification.html The Spec, ?5.5 Advanced line types
>> 
>> I noticed that the spec has three different advanced line types and three different whitespace handling verbiages for each.
>> 
>> Heading lines: Start with 1?3 ?#?, then optional whitespace.
>> List items: Start with ?* ? (note the space!)
>> Quote lines: Start with ?>? 
>> 
>> Shouldn?t these three have the same whitespace rules, with the same phrasing?
>> 
>> Here?s my argument for ?mandatory whitespace for all? ([\t ]+):
>> 
>> - It lets authors write ?#3. I like eggs.? without accidentally getting that line parsed as if it were a heading (we don?t have backslash escapes like Markdown does)
>> - It?s better for some emoticons that, um, might be out there that start with > or *
>> - ?#Steak? looks like a hashtag, and I could see some fraction of authors writing ?#blah? _meaning_ for it to be a tag
>> - We shouldn?t be worried about backcompat at v0.14.2. I don?t have much gemini text, but I?m the sort who would reformat his own non-conformant documents to match something like this.
>> 
>> - - - -
>> 
>> I could see myself wanting an H4-equivalent or higher, but I?m not certain this is _quite_ the right time to mention it. Also the current spec already seems to say that clients should parse ?#### Eggs? as not-a-heading.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200912/3e3c735c/attachment.htm>

From cage-dev at twistfold.it  Sun Sep 13 10:10:00 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 13 Sep 2020 11:10:00 +0200
Subject: Optional/mandatory =?iso-8859-1?Q?whit?=
 =?iso-8859-1?Q?espace_in_=A75=2E5?= Advanced line types
In-Reply-To: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
References: <E735D887-2453-44BB-8543-1A725B120420@ngalt.com>
Message-ID: <20200913091000.GA1755@kurosawa.casa.net>

On Sat, Sep 12, 2020 at 07:46:12PM -0700, Nathan Galt wrote:

Hi!

> Prior reading:
>
> => https://gemini.circumlunar.space/docs/specification.html The Spec, ?5.5 Advanced line types
>
> I noticed that the spec has three different advanced line types and three different whitespace handling verbiages for each.
>
> Heading lines: Start with 1?3 ?#?, then optional whitespace.
> List items: Start with ?* ? (note the space!)
> Quote lines: Start with ?>?
> Shouldn?t these three have the same whitespace rules, with the same phrasing?

Correct me if i am wrong but we already discussed that in the mailing list?

https://lists.orbitalfox.eu/archives/gemini/2020/002312.html

Bye!
C.

From gmym at coopdot.com  Sun Sep 13 14:40:24 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sun, 13 Sep 2020 15:40:24 +0200
Subject: MIME type toggle lines
Message-ID: <CAObwWNgoaStLpQhSZwu7vKBZ0k-ehZzoeh9Ax=2dV+bs3eA8fA@mail.gmail.com>

Hello Geminauts

While reading the alt text discussion, I noticed the use of MIME types in
the alt text. Without calling anyone out or accuse anyone for wanting this,
I want to point out a thing.

Consider this text/gemini document:

This text is text/gemini but soon enough we will encounter a toggle line
```
This is after the toggle line, so now we're in text/plain mode
```
Another toggle line, so we are back in text/gemini mode

[eof]

This interpretation of the spec is fine, how about this modification:

This text is text/gemini but soon enough we will encounter a toggle line
``` text/plain
This is after the toggle line, so now we're in text/plain mode
``` text/gemini
Another toggle line, so we are back in text/gemini mode

[eof]

The only change is adding information about the default behavior, let's dig
deeper:

This text is text/gemini but soon enough we will encounter a toggle line
``` text/csv
This is after the toggle line, but instead of defaulting to text/plain
mode, this is text/csv with 3 columns
```
Another toggle line, so we are back in text/gemini mode

[eof]

Here, the first toggle has been extended for use of other text types. This
is already outside of what I think is the intention of the spec, but there
is another level:

This text is text/gemini but soon enough we will encounter a toggle line
```
This is after the toggle line and since we left text/gemini, we're now in
text/plain mode
``` text/csv
Another toggle line, but instead of going back to text/gemini mode, this is
text/csv with 3 columns
```
Yet another toggle line and the previous mode wasn't text/gemini, so we are
finally back in text/gemini mode

[eof]

Here we have 4 sections: gemini, plain text, csv and then gemini again.
This behavior is not what the clients following the current spec would
expect but can be amended with an extra toggle line between the plain text
and csv sections.

This does not play nice with anything but is along the line of the previous
example.

I want .gmi/.gemini files to be mostly text/gemini with plain text mode
used sparsely and link to other content types. Want a bigger chunk of plain
text? Link it, maybe under an excerpt.

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200913/dfc33f6c/attachment.htm>

From dealpete at fastmail.com  Sun Sep 13 17:42:06 2020
From: dealpete at fastmail.com (Peter Deal)
Date: Sun, 13 Sep 2020 14:12:06 -0230
Subject: MacOS Gemini Client
In-Reply-To: <20200913014712.GK1964344@tilde.team>
References: <B6478A1F-387B-4AC1-AE44-0212A3ADE5B1@fastmail.com>
 <20200913014712.GK1964344@tilde.team>
Message-ID: <396A6CEA-7B78-430C-AFB8-C3677874F5B2@fastmail.com>


> On Sep 12, 2020, at 11:17 PM, easeout at tilde.team wrote:
> 
> On Sat, Sep 12, 2020 at 10:05:05PM -0230, Peter Deal wrote:
>> Hello Geminauts!
>> 
>> I?d like to announce that I?ve created a Gemini client for MacOS. It?s a graphical client that uses native OS UI elements. You can check it out at
>> 
>> https://github.com/dealpete/sputnik
> 
> This is great! Please let me know if I can help you get unstuck on
> anything; I know the Apple dev world pretty well.
> 
Thanks for the offer! I may have to take you up on the that at some point.

>> I?ve written a little gemlog post about some of my design decisions here
>> 
>> gemini://gemini.circumlunar.space/users/dealpete/
> 
> You mentioned in your post that SwiftUI lacks some capabilties compared
> to AppKit, and that's true. In its first release year it has really been
> kind of a preview. This year's release does a lot to make it feel more
> complete. That's currently in Xcode 12 beta. Here's an introduction to
> the changes (video + transcript):
> 
> https://developer.apple.com/videos/play/wwdc2020/10041/

I have seen some of the Xcode 12 updates and I?m looking forward to trying them out when it comes out of beta.

Peter

From kevin at bbs.ec  Sun Sep 13 20:39:28 2020
From: kevin at bbs.ec (Kevin)
Date: Sun, 13 Sep 2020 21:39:28 +0200
Subject: Subdomain for self hosting gemini servers
Message-ID: <1600025968.303.0@bbs.ec>

Hello all,

You can murder me if this is totally off topic and/or unwanted, but I figured I'd run it up 
the flag pole.

I've created a domain name to share via freedns.afraid.org for anybody who wants to 
setup and self host their own gemini server but doesn't want to / isn't able to register 
their own domain.  I made it short and sweet so subdomains look more like a domain in 
its own right.  

I've gone for tb.je, TB being "Text Based" (muy listo), JE being, well Jersey, one of the 
few ccTLDs with short domains left in 2020.

If you're interested you can register via https://tb.je or direct from the freedns registry 
(https://freedns.afraid.org/domain/registry/)

For those with dynamic IPs, freedns can also handle updating the record automatically 
for you : https://freedns.afraid.org/dynamic/

Any questions, I'm happy to take them !

-Kevin 

From kevin at bbs.ec  Sun Sep 13 20:39:28 2020
From: kevin at bbs.ec (Kevin)
Date: Sun, 13 Sep 2020 21:39:28 +0200
Subject: Subdomain for self hosting gemini servers
Message-ID: <1600025968.303.0@bbs.ec>

Hello all,

You can murder me if this is totally off topic and/or unwanted, but I figured I'd run it up 
the flag pole.

I've created a domain name to share via freedns.afraid.org for anybody who wants to 
setup and self host their own gemini server but doesn't want to / isn't able to register 
their own domain.  I made it short and sweet so subdomains look more like a domain in 
its own right.  

I've gone for tb.je, TB being "Text Based" (muy listo), JE being, well Jersey, one of the 
few ccTLDs with short domains left in 2020.

If you're interested you can register via https://tb.je or direct from the freedns registry 
(https://freedns.afraid.org/domain/registry/)

For those with dynamic IPs, freedns can also handle updating the record automatically 
for you : https://freedns.afraid.org/dynamic/

Any questions, I'm happy to take them !

-Kevin 

From skyjake at dengine.net  Sun Sep 13 21:25:12 2020
From: skyjake at dengine.net (skyjake)
Date: Sun, 13 Sep 2020 23:25:12 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
Message-ID: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>

Hello all,

This is my first post to the mailing list, so greetings everyone! I've been following Gemini for a couple of months now and really like the thinking behind it. The community has done lots of impressive work on an elegant, small foundation.

I would like to introduce you to a new desktop GUI client I've been writing. It is called "Lagrange", and me being a visual/gamedev kind of guy one of the main goals is to make it an aesthetically pleasing app. At the moment, I have binaries available for Windows and macOS, and a source tarball for compiling on Linux.

Short description and build instructions:

    gemini://skyjake.fi/lagrange/
  
Source code and releases:

    https://git.skyjake.fi/skyjake/lagrange

In the spirit of Gemini, the guiding principle has been to trim things down to the bare bones. To keep the app as portable and small as possible, it's written in C and doesn't depend on existing UI frameworks. Instead, SDL2 is used for low-level graphics/input and the rest is built on top of that. TLS is provided by OpenSSL.

Feature highlights:

* Beautiful typography using Unicode fonts
* Autogenerated page style and Unicode icon for each Gemini domain
* Smart suggestions when typing the URL ? search bookmarks, history, identities
* Sidebar for page outline, managing bookmarks and identities, and viewing history
* Multiple tabs
* Identity management ? create and use TLS client certificates

This is version 0.1 so it is not yet feature complete, but the commonly needed stuff should be working. Give it a spin if interested, and let me know if you have any comments or improvement ideas.

--jaakko

From luke at marmaladefoo.com  Sun Sep 13 22:05:21 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 13 Sep 2020 22:05:21 +0100
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
Message-ID: <5F5E8991.1070908@marmaladefoo.com>

Hi Jaakko

Very nice work - well done! I just took it for a spin on Win10. You 
might want to create an installer at some point, my anti virus seemed to 
look on it suspiciously and I had to retrieve it from quarantine.

A v minor comment - when using a http proxy, it seems to need the IP 
address (e.g. on local machine needs "127.0.0.1:port" using 
"localhost:port" didn't work for me).

Best wishes

  - Luke

On 13-Sep-2020 21:25, skyjake wrote:
> Hello all,
>
> This is my first post to the mailing list, so greetings everyone! I've been following Gemini for a couple of months now and really like the thinking behind it. The community has done lots of impressive work on an elegant, small foundation.
>
> I would like to introduce you to a new desktop GUI client I've been writing. It is called "Lagrange", and me being a visual/gamedev kind of guy one of the main goals is to make it an aesthetically pleasing app. At the moment, I have binaries available for Windows and macOS, and a source tarball for compiling on Linux.
>
> Short description and build instructions:
>
>      gemini://skyjake.fi/lagrange/
>
> Source code and releases:
>
>      https://git.skyjake.fi/skyjake/lagrange
>
> In the spirit of Gemini, the guiding principle has been to trim things down to the bare bones. To keep the app as portable and small as possible, it's written in C and doesn't depend on existing UI frameworks. Instead, SDL2 is used for low-level graphics/input and the rest is built on top of that. TLS is provided by OpenSSL.
>
> Feature highlights:
>
> * Beautiful typography using Unicode fonts
> * Autogenerated page style and Unicode icon for each Gemini domain
> * Smart suggestions when typing the URL ? search bookmarks, history, identities
> * Sidebar for page outline, managing bookmarks and identities, and viewing history
> * Multiple tabs
> * Identity management ? create and use TLS client certificates
>
> This is version 0.1 so it is not yet feature complete, but the commonly needed stuff should be working. Give it a spin if interested, and let me know if you have any comments or improvement ideas.
>
> --jaakko

From dealpete at fastmail.com  Sun Sep 13 23:58:26 2020
From: dealpete at fastmail.com (Peter Deal)
Date: Sun, 13 Sep 2020 20:28:26 -0230
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
Message-ID: <CDD91DAB-C585-4F2B-9B3A-266B33BECDCD@fastmail.com>

Hi jaakko,

It is a beautiful client - congratulations! I especially like how you use a different colour scheme for each domain, and make it clear in the links where you?re going. The only issue I had was it hangs when I try to navigate to gus.guru (I?m on a Mac, if that helps).

Peter

> On Sep 13, 2020, at 5:55 PM, skyjake <skyjake at dengine.net> wrote:
> 
> Hello all,
> 
> This is my first post to the mailing list, so greetings everyone! I've been following Gemini for a couple of months now and really like the thinking behind it. The community has done lots of impressive work on an elegant, small foundation.
> 
> I would like to introduce you to a new desktop GUI client I've been writing. It is called "Lagrange", and me being a visual/gamedev kind of guy one of the main goals is to make it an aesthetically pleasing app. At the moment, I have binaries available for Windows and macOS, and a source tarball for compiling on Linux.
> 
> Short description and build instructions:
> 
>    gemini://skyjake.fi/lagrange/
> 
> Source code and releases:
> 
>    https://git.skyjake.fi/skyjake/lagrange
> 
> In the spirit of Gemini, the guiding principle has been to trim things down to the bare bones. To keep the app as portable and small as possible, it's written in C and doesn't depend on existing UI frameworks. Instead, SDL2 is used for low-level graphics/input and the rest is built on top of that. TLS is provided by OpenSSL.
> 
> Feature highlights:
> 
> * Beautiful typography using Unicode fonts
> * Autogenerated page style and Unicode icon for each Gemini domain
> * Smart suggestions when typing the URL ? search bookmarks, history, identities
> * Sidebar for page outline, managing bookmarks and identities, and viewing history
> * Multiple tabs
> * Identity management ? create and use TLS client certificates
> 
> This is version 0.1 so it is not yet feature complete, but the commonly needed stuff should be working. Give it a spin if interested, and let me know if you have any comments or improvement ideas.
> 
> --jaakko


From ech at emmah.net  Mon Sep 14 00:42:28 2020
From: ech at emmah.net (Emma Humphries)
Date: Sun, 13 Sep 2020 16:42:28 -0700
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CDD91DAB-C585-4F2B-9B3A-266B33BECDCD@fastmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <CDD91DAB-C585-4F2B-9B3A-266B33BECDCD@fastmail.com>
Message-ID: <28003461-f777-4804-a9e7-af3397651efe@www.fastmail.com>

Jaakko, 

This is absolutely gorgeous. 

I had no trouble building it on Ubuntu Focal Fossa after installing prerequisites (add Cmake to that list.) 

I could not reproduce Peter's error when going to gus.guru. 

Here's a link to a screenshot https://magicalgirl.party/@emma/104860248161220415

-- Emma 

On Sun, Sep 13, 2020, at 15:58, Peter Deal wrote:
> Hi jaakko,
> 
> It is a beautiful client - congratulations! I especially like how you 
> use a different colour scheme for each domain, and make it clear in the 
> links where you?re going. The only issue I had was it hangs when I try 
> to navigate to gus.guru (I?m on a Mac, if that helps).
> 
> Peter
> 
> > On Sep 13, 2020, at 5:55 PM, skyjake <skyjake at dengine.net> wrote:
> > 
> > Hello all,
> > 
> > This is my first post to the mailing list, so greetings everyone! I've been following Gemini for a couple of months now and really like the thinking behind it. The community has done lots of impressive work on an elegant, small foundation.
> > 
> > I would like to introduce you to a new desktop GUI client I've been writing. It is called "Lagrange", and me being a visual/gamedev kind of guy one of the main goals is to make it an aesthetically pleasing app. At the moment, I have binaries available for Windows and macOS, and a source tarball for compiling on Linux.
> > 
> > Short description and build instructions:
> > 
> >    gemini://skyjake.fi/lagrange/
> > 
> > Source code and releases:
> > 
> >    https://git.skyjake.fi/skyjake/lagrange
> > 
> > In the spirit of Gemini, the guiding principle has been to trim things down to the bare bones. To keep the app as portable and small as possible, it's written in C and doesn't depend on existing UI frameworks. Instead, SDL2 is used for low-level graphics/input and the rest is built on top of that. TLS is provided by OpenSSL.
> > 
> > Feature highlights:
> > 
> > * Beautiful typography using Unicode fonts
> > * Autogenerated page style and Unicode icon for each Gemini domain
> > * Smart suggestions when typing the URL ? search bookmarks, history, identities
> > * Sidebar for page outline, managing bookmarks and identities, and viewing history
> > * Multiple tabs
> > * Identity management ? create and use TLS client certificates
> > 
> > This is version 0.1 so it is not yet feature complete, but the commonly needed stuff should be working. Give it a spin if interested, and let me know if you have any comments or improvement ideas.
> > 
> > --jaakko
> 
>

From kevin at susa.net  Mon Sep 14 00:43:17 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 14 Sep 2020 00:43:17 +0100
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CDD91DAB-C585-4F2B-9B3A-266B33BECDCD@fastmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <CDD91DAB-C585-4F2B-9B3A-266B33BECDCD@fastmail.com>
Message-ID: <CAPk6LxSnLLLA2z8EUW6sG_RJ-nrYeN+=OGNmxB-G9bZMfBzGOQ@mail.gmail.com>

It might be worth mentioning that a similar issue came up with a different
client, which turned out related to not handling relative URLs in
redirects, as I recall.

Kevin

On Sun, 13 Sep 2020 at 23:58, Peter Deal <dealpete at fastmail.com> wrote:

> Hi jaakko,
>
> It is a beautiful client - congratulations! I especially like how you use
> a different colour scheme for each domain, and make it clear in the links
> where you?re going. The only issue I had was it hangs when I try to
> navigate to gus.guru (I?m on a Mac, if that helps).
>
> Peter
>
> > On Sep 13, 2020, at 5:55 PM, skyjake <skyjake at dengine.net> wrote:
> >
> > Hello all,
> >
> > This is my first post to the mailing list, so greetings everyone! I've
> been following Gemini for a couple of months now and really like the
> thinking behind it. The community has done lots of impressive work on an
> elegant, small foundation.
> >
> > I would like to introduce you to a new desktop GUI client I've been
> writing. It is called "Lagrange", and me being a visual/gamedev kind of guy
> one of the main goals is to make it an aesthetically pleasing app. At the
> moment, I have binaries available for Windows and macOS, and a source
> tarball for compiling on Linux.
> >
> > Short description and build instructions:
> >
> >    gemini://skyjake.fi/lagrange/
> >
> > Source code and releases:
> >
> >    https://git.skyjake.fi/skyjake/lagrange
> >
> > In the spirit of Gemini, the guiding principle has been to trim things
> down to the bare bones. To keep the app as portable and small as possible,
> it's written in C and doesn't depend on existing UI frameworks. Instead,
> SDL2 is used for low-level graphics/input and the rest is built on top of
> that. TLS is provided by OpenSSL.
> >
> > Feature highlights:
> >
> > * Beautiful typography using Unicode fonts
> > * Autogenerated page style and Unicode icon for each Gemini domain
> > * Smart suggestions when typing the URL ? search bookmarks, history,
> identities
> > * Sidebar for page outline, managing bookmarks and identities, and
> viewing history
> > * Multiple tabs
> > * Identity management ? create and use TLS client certificates
> >
> > This is version 0.1 so it is not yet feature complete, but the commonly
> needed stuff should be working. Give it a spin if interested, and let me
> know if you have any comments or improvement ideas.
> >
> > --jaakko
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200914/1e916274/attachment.htm>

From kevin at susa.net  Mon Sep 14 00:50:46 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 14 Sep 2020 00:50:46 +0100
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
Message-ID: <CAPk6LxReWmqMX+6A1o9u7HTTFRdvON=OqMduXAOL=F8pw5YWkA@mail.gmail.com>

This is really nicely done, looks and feels fantastic. A couple of points:

For some reason, the opengl renderer was really messing up my display
(needed to switch to console and back to recover, even after quitting
lagrange). Recompiled with the software renderer, and it works beautifully.
I was running a Debian guest on a Windows 7 VirtualBox host.

The auto-enlarging of the first paragraph, while it looks nice, is jarring
with the reading of my docs.

The block-quotes text doesn't really stand out as a block quote to my eyes.

Please disregard my previous comment on GUS and redirects, it also works
fine for me.

Regardless, lovely work. Thanks!

Kevin


On Sun, 13 Sep 2020 at 21:25, skyjake <skyjake at dengine.net> wrote:

> Hello all,
>
> This is my first post to the mailing list, so greetings everyone! I've
> been following Gemini for a couple of months now and really like the
> thinking behind it. The community has done lots of impressive work on an
> elegant, small foundation.
>
> I would like to introduce you to a new desktop GUI client I've been
> writing. It is called "Lagrange", and me being a visual/gamedev kind of guy
> one of the main goals is to make it an aesthetically pleasing app. At the
> moment, I have binaries available for Windows and macOS, and a source
> tarball for compiling on Linux.
>
> Short description and build instructions:
>
>     gemini://skyjake.fi/lagrange/
>
> Source code and releases:
>
>     https://git.skyjake.fi/skyjake/lagrange
>
> In the spirit of Gemini, the guiding principle has been to trim things
> down to the bare bones. To keep the app as portable and small as possible,
> it's written in C and doesn't depend on existing UI frameworks. Instead,
> SDL2 is used for low-level graphics/input and the rest is built on top of
> that. TLS is provided by OpenSSL.
>
> Feature highlights:
>
> * Beautiful typography using Unicode fonts
> * Autogenerated page style and Unicode icon for each Gemini domain
> * Smart suggestions when typing the URL ? search bookmarks, history,
> identities
> * Sidebar for page outline, managing bookmarks and identities, and viewing
> history
> * Multiple tabs
> * Identity management ? create and use TLS client certificates
>
> This is version 0.1 so it is not yet feature complete, but the commonly
> needed stuff should be working. Give it a spin if interested, and let me
> know if you have any comments or improvement ideas.
>
> --jaakko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200914/8330236c/attachment.htm>

From ech at emmah.net  Mon Sep 14 00:35:07 2020
From: ech at emmah.net (Emma Humphries)
Date: Sun, 13 Sep 2020 16:35:07 -0700
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CDD91DAB-C585-4F2B-9B3A-266B33BECDCD@fastmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <CDD91DAB-C585-4F2B-9B3A-266B33BECDCD@fastmail.com>
Message-ID: <111b2078-a826-489b-95a4-784befb5a94c@www.fastmail.com>

Jaakko, 

This is absolutely gorgeous. 

I had no trouble building it on Ubuntu Focal Fossa after installing prerequisites (add Cmake to that list.) 

I've enclosed a screenshot. 

I could not reproduce Peter's error when going to gus.guru. 

-- Emma 

On Sun, Sep 13, 2020, at 15:58, Peter Deal wrote:
> Hi jaakko,
> 
> It is a beautiful client - congratulations! I especially like how you 
> use a different colour scheme for each domain, and make it clear in the 
> links where you?re going. The only issue I had was it hangs when I try 
> to navigate to gus.guru (I?m on a Mac, if that helps).
> 
> Peter
> 
> > On Sep 13, 2020, at 5:55 PM, skyjake <skyjake at dengine.net> wrote:
> > 
> > Hello all,
> > 
> > This is my first post to the mailing list, so greetings everyone! I've been following Gemini for a couple of months now and really like the thinking behind it. The community has done lots of impressive work on an elegant, small foundation.
> > 
> > I would like to introduce you to a new desktop GUI client I've been writing. It is called "Lagrange", and me being a visual/gamedev kind of guy one of the main goals is to make it an aesthetically pleasing app. At the moment, I have binaries available for Windows and macOS, and a source tarball for compiling on Linux.
> > 
> > Short description and build instructions:
> > 
> >    gemini://skyjake.fi/lagrange/
> > 
> > Source code and releases:
> > 
> >    https://git.skyjake.fi/skyjake/lagrange
> > 
> > In the spirit of Gemini, the guiding principle has been to trim things down to the bare bones. To keep the app as portable and small as possible, it's written in C and doesn't depend on existing UI frameworks. Instead, SDL2 is used for low-level graphics/input and the rest is built on top of that. TLS is provided by OpenSSL.
> > 
> > Feature highlights:
> > 
> > * Beautiful typography using Unicode fonts
> > * Autogenerated page style and Unicode icon for each Gemini domain
> > * Smart suggestions when typing the URL ? search bookmarks, history, identities
> > * Sidebar for page outline, managing bookmarks and identities, and viewing history
> > * Multiple tabs
> > * Identity management ? create and use TLS client certificates
> > 
> > This is version 0.1 so it is not yet feature complete, but the commonly needed stuff should be working. Give it a spin if interested, and let me know if you have any comments or improvement ideas.
> > 
> > --jaakko
> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lagrange-screenshot.png
Type: image/png
Size: 352577 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200913/c4b84111/attachment-0001.png>

From colecmac at protonmail.com  Mon Sep 14 01:46:17 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 14 Sep 2020 00:46:17 +0000
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
Message-ID: <FhCl2whb0kTSJJWmDRxaol4Z_FIaMxT7R5Y-sP0dCmPh4twLCZFzViD1E2PREPrRy2EQKdTFgmYVmKie2WXNqLpqOR8RBsn2QBfylIi6wlk=@protonmail.com>

Hello,

The screenshots I've seen look great! I'm was excited to try this client,
but instead I got a segfault staring back at me. Can you help me debug
this?

I'm on Arch Linux, and I'm pretty sure I have all the right libs installed.

Here's the output:

? ./lagrange
[the_Foundation] version: 1.0.0 cstd:201112
[the_Foundation] locale: en_US.UTF-8
Lagrange: A Beautiful Gemini Client
[1]    319881 segmentation fault (core dumped)  ./lagrange


And here are the strace lines right before the segfault:

rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
clone(child_stack=0x7fea702e4ef0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[319841], tls=0x7fea702e5640, child_tidptr=0x7fea702e5910) = 319841
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
access("/home/makeworld/.config/lagrange", R_OK) = 0
getcwd("/home/makeworld/Software/lagrange-0.1.0/build", 4096) = 46
stat("/home/makeworld/.config/lagrange/trusted.txt", 0x7ffd22276360) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/makeworld/.config/lagrange/trusted.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/makeworld/.config/lagrange/idents.binary", 0x7ffd22276360) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/makeworld/.config/lagrange/idents.binary", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/home/makeworld/.config/lagrange/idents", R_OK) = 0
stat("/home/makeworld/.config/lagrange/idents", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/home/makeworld/.config/lagrange/idents", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 17
fstat(17, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(17, 0x56014d354160 /* 2 entries */, 32768) = 48
getdents64(17, 0x56014d354160 /* 0 entries */, 32768) = 0
access("/home/makeworld/.config", R_OK) = 0
mkdir("/home/makeworld/.config/lagrange", 0755) = -1 EEXIST (File exists)
stat("/home/makeworld/.config/lagrange/prefs.cfg", 0x7ffd22276600) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/makeworld/.config/lagrange/prefs.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/makeworld/.config/lagrange/visited.txt", 0x7ffd22276500) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/makeworld/.config/lagrange/visited.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/makeworld/.config/lagrange/bookmarks.txt", 0x7ffd22276540) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/makeworld/.config/lagrange/bookmarks.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/makeworld/Software/lagrange-0.1.0/share/lagrange/resources.binary", 0x7ffd222765e0) = -1 ENOENT (No such file or directory)
stat("/home/makeworld/Software/lagrange-0.1.0/share/lagrange/resources.binary", 0x7ffd222765b0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/makeworld/Software/lagrange-0.1.0/share/lagrange/resources.binary", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/makeworld/Software/lagrange-0.1.0/build/resources.binary", {st_mode=S_IFREG|0644, st_size=9086132, ...}) = 0
stat("/home/makeworld/Software/lagrange-0.1.0/build/resources.binary", {st_mode=S_IFREG|0644, st_size=9086132, ...}) = 0
openat(AT_FDCWD, "/home/makeworld/Software/lagrange-0.1.0/build/resources.binary", O_RDONLY) = 18
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x56014b9fe980} ---
+++ killed by SIGSEGV (core dumped) +++
[1]    319831 segmentation fault (core dumped)  strace ./lagrange


I downloaded the specific .tar.gz from your releases that includes theFoundation.
Any idea what the issue is?


makeworld

From flexibeast at gmail.com  Mon Sep 14 04:46:26 2020
From: flexibeast at gmail.com (Alexis)
Date: Mon, 14 Sep 2020 13:46:26 +1000
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
Message-ID: <87k0wxxbot.fsf@ada>


skyjake <skyjake at dengine.net> writes:

> Source code and releases:
>
>     https://git.skyjake.fi/skyjake/lagrange

Unfortunately i haven't been able to build it on Void Linux, due 
to a problem when trying to build the_Foundation:

```
[ 80%] Building C object 
CMakeFiles/the_Foundation.dir/src/tlsrequest.c.o
/home/alexis/Downloads/src/the_Foundation/src/tlsrequest.c: In 
function 'validUntil_TlsCertificate':
/home/alexis/Downloads/src/the_Foundation/src/tlsrequest.c:268:9: 
error: implicit declaration of function 'ASN1_TIME_to_tm'; did you 
mean 'ASN1_TIME_set_tm'? [-Werror=implicit-function-declaration]
  268 |         ASN1_TIME_to_tm(X509_get0_notAfter(d->cert), 
  &time);
      |         ^~~~~~~~~~~~~~~
      |         ASN1_TIME_set_tm
cc1: all warnings being treated as errors
```


Alexis.

From skyjake at dengine.net  Mon Sep 14 09:18:42 2020
From: skyjake at dengine.net (skyjake)
Date: Mon, 14 Sep 2020 11:18:42 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <5F5E8991.1070908@marmaladefoo.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
Message-ID: <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>

Hi all,

many thanks for the kind words! :)

Collected replies follow:

> On 14. Sep 2020, at 0:05, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> Very nice work - well done! I just took it for a spin on Win10. You might want to create an installer at some point, my anti virus seemed to look on it suspiciously and I had to retrieve it from quarantine.
> 
> A v minor comment - when using a http proxy, it seems to need the IP address (e.g. on local machine needs "127.0.0.1:port" using "localhost:port" didn't work for me).

Yes, a Windows installer will be used in a future build, most likely using CMake's CPack module as that it relatively painless and I've done it before in another project.

I'll check the proxy address lookup, I believe it should work with domain names as well.


> On 14. Sep 2020, at 1:58, Peter Deal <dealpete at fastmail.com> wrote:
> 
> It is a beautiful client - congratulations! I especially like how you use a different colour scheme for each domain, and make it clear in the links where you?re going. The only issue I had was it hangs when I try to navigate to gus.guru (I?m on a Mac, if that helps).

I'm mostly developing this on a Mac myself. There is certainly some kind of weirdness with gus.guru, while it works most of the time for me sometimes I have to reload the page manually. Not exactly sure what's going on, will have to investigate. Seems pretty random.


> On 14. Sep 2020, at 2:50, Kevin Sangeelee <kevin at susa.net> wrote:
> 
> For some reason, the opengl renderer was really messing up my display (needed to switch to console and back to recover, even after quitting lagrange). Recompiled with the software renderer, and it works beautifully. I was running a Debian guest on a Windows 7 VirtualBox host.
> 
> The auto-enlarging of the first paragraph, while it looks nice, is jarring with the reading of my docs.
> 
> The block-quotes text doesn't really stand out as a block quote to my eyes.

Yeah, I suppose OpenGL issues can be rather common, especially under VMs. I will add an option to force software rendering in a future build. (See below how to do it manually.)

I have been considering adding a user preference for the enlarged first paragraph, along with other page style customization settings. Could you point me to / share an example page where it looks jarring? Perhaps I can still tweak things a little to detect when not to apply the effect.

Also curious about the block quote appearance, what would you consider a more distinctive appearance?


> On 14. Sep 2020, at 3:46, colecmac at protonmail.com wrote:
> 
> I'm on Arch Linux, and I'm pretty sure I have all the right libs installed.
> <strace output>
> 
> I downloaded the specific .tar.gz from your releases that includes theFoundation.
> Any idea what the issue is?

Hmm, at least it found the resources file, so that's good. My first guess is always that there is some problem with OpenGL. I'll add the software rendering option, but maybe in the meantime you could try going to src/ui/window.c:480 and uncomment "#define ENABLE_SWRENDER".

Hopefully that helps, but if not, we could try a debug build and run it under gdb to get a stack trace?


> On 14. Sep 2020, at 6:46, Alexis <flexibeast at gmail.com> wrote:
> 
> Unfortunately i haven't been able to build it on Void Linux, due to a problem when trying to build the_Foundation:
> 
> ```
> error: implicit declaration of function 'ASN1_TIME_to_tm'; did you mean 'ASN1_TIME_set_tm'? [-Werror=implicit-function-declaration]
> ```

It appears `ASN1_TIME_to_tm`  was added to OpenSSL 1.1.1, so I'll document that as a required dependency. If anyone wants to provide a workaround for older OpenSSL releases, I'll gladly accept a patch. :)

--jaakko

From flexibeast at gmail.com  Mon Sep 14 09:47:53 2020
From: flexibeast at gmail.com (Alexis)
Date: Mon, 14 Sep 2020 18:47:53 +1000
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
 <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
Message-ID: <87h7s0ycau.fsf@ada>


skyjake <skyjake at dengine.net> writes:

> It appears `ASN1_TIME_to_tm`  was added to OpenSSL 1.1.1, so 
> I'll document that as a required dependency. If anyone wants to 
> provide a workaround for older OpenSSL releases, I'll gladly 
> accept a patch. :)

Ah. This might not be an "older OpenSSL release" issue, but a 
LibreSSL issue: Void, OpenBSD, Dragonfly BSD and Hyperbola all use 
the LibreSSL fork of OpenSSL as their default TLS provider. i have 
no idea whether this function is deliberately omitted, or whether 
its absence is more due to a lack of resources.


Alexis.

From list at gkbrk.com  Mon Sep 14 15:10:00 2020
From: list at gkbrk.com (Leo)
Date: Mon, 14 Sep 2020 17:10:00 +0300
Subject: MIME type toggle lines
In-Reply-To: <CAObwWNgoaStLpQhSZwu7vKBZ0k-ehZzoeh9Ax=2dV+bs3eA8fA@mail.gmail.com>
References: <CAObwWNgoaStLpQhSZwu7vKBZ0k-ehZzoeh9Ax=2dV+bs3eA8fA@mail.gmail.com>
Message-ID: <8545775f-22b3-28d5-f5ec-e0570b7bd27c@gkbrk.com>

I think going down this route, you will eventually want to embed ``` in 
the different
mime types and end up with the MIME email format. Which is not a bad 
thing, just not Gemini.

Leo

From list at gkbrk.com  Mon Sep 14 15:30:07 2020
From: list at gkbrk.com (Leo)
Date: Mon, 14 Sep 2020 17:30:07 +0300
Subject: Firefox Add-on protocol schema
Message-ID: <2e9487b4-ba32-fbc7-9c48-400e42de5eb6@gkbrk.com>

Firefox has a hard-coded list of schemas that extensions are allowed to 
handle without the web+
or webext+ prefix. I believe gopher can be handled this way.

Has anyone got in touch or created an issue to add gemini to this list? 
While it defeats the purpose
of having a separate protocol and document format, it would be good to 
make all the gemini:// links
work in Firefox.

Leo

From kevin at susa.net  Mon Sep 14 16:04:48 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 14 Sep 2020 16:04:48 +0100
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
 <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
Message-ID: <CAPk6LxSaOmX_KH2jRLfDPcSp44sYdY3j=PJ6keX+56cb7OoMZA@mail.gmail.com>

On Mon, 14 Sep 2020 at 09:18, skyjake <skyjake at dengine.net> wrote:

> I have been considering adding a user preference for the enlarged first
> paragraph, along with other page style customization settings. Could you
> point me to / share an example page where it looks jarring? Perhaps I can
> still tweak things a little to detect when not to apply the effect.
>

Two pages that come to mind are a) my homepage that has an inane disclaimer
as the first paragraph, (definitely not worthy of prominence!) and b) a
page that seemed to have a line-break at the end of the paragraph, so it
showed in mixed fonts. There were others. I think the broader issue is that
styling judgements on arbitrary text without semantic hints are only going
to succeed in some cases.


> Also curious about the block quote appearance, what would you consider a
> more distinctive appearance?
>

Looking again, is the font colour different for block-quotes? I'm a bit
colour blind, and it's hard for me to tell. Traditional vertical bars or
italics tend to stand out for me, subtle colour differences (that most
people see clearly) tend not to.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200914/8d9b4de4/attachment.htm>

From acdw at acdw.net  Mon Sep 14 19:17:22 2020
From: acdw at acdw.net (acdw)
Date: Mon, 14 Sep 2020 18:17:22 +0000
Subject: Firefox Add-on protocol schema
In-Reply-To: <2e9487b4-ba32-fbc7-9c48-400e42de5eb6@gkbrk.com>
References: <2e9487b4-ba32-fbc7-9c48-400e42de5eb6@gkbrk.com>
Message-ID: <48be4717-7653-4733-b902-b5334825ba18@www.fastmail.com>

On 2020-09-14 (Monday) at 14:30, Leo <list at gkbrk.com> wrote:

> Firefox has a hard-coded list of schemas that extensions are allowed to 
> handle without the web+
> or webext+ prefix. I believe gopher can be handled this way.
> 
> Has anyone got in touch or created an issue to add gemini to this list? 
> While it defeats the purpose
> of having a separate protocol and document format, it would be good to 
> make all the gemini:// links
> work in Firefox.
> 
> Leo

I haven't, but I've come across this problem as well. Would it be possible for an add-on to just add "web+" to all <a> tags with href^=gemini:// ? Then define a protocol handler to web+gemini?

I was going to try this but my Javascript skills are sorely lacking.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From ech at emmah.net  Mon Sep 14 19:22:14 2020
From: ech at emmah.net (Emma Humphries)
Date: Mon, 14 Sep 2020 11:22:14 -0700
Subject: Firefox Add-on protocol schema
In-Reply-To: <48be4717-7653-4733-b902-b5334825ba18@www.fastmail.com>
References: <2e9487b4-ba32-fbc7-9c48-400e42de5eb6@gkbrk.com>
 <48be4717-7653-4733-b902-b5334825ba18@www.fastmail.com>
Message-ID: <191ff534-9a31-43e0-b6fa-e68914993c76@www.fastmail.com>

There's a couple of Bugzilla bugs to follow on that:

https://bugzilla.mozilla.org/show_bug.cgi?id=1385357 this looks like this got regressed as reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1629149.

I'll log in and update that.

-- Emma 


On Mon, Sep 14, 2020, at 11:17, acdw wrote:
> On 2020-09-14 (Monday) at 14:30, Leo <list at gkbrk.com> wrote:
> 
> > Firefox has a hard-coded list of schemas that extensions are allowed to 
> > handle without the web+
> > or webext+ prefix. I believe gopher can be handled this way.
> > 
> > Has anyone got in touch or created an issue to add gemini to this list? 
> > While it defeats the purpose
> > of having a separate protocol and document format, it would be good to 
> > make all the gemini:// links
> > work in Firefox.
> > 
> > Leo
> 
> I haven't, but I've come across this problem as well. Would it be 
> possible for an add-on to just add "web+" to all <a> tags with 
> href^=gemini:// ? Then define a protocol handler to web+gemini?
> 
> I was going to try this but my Javascript skills are sorely lacking.
> 
> -- 
> ~ acdw
> acdw.net | breadpunk.club/~breadw
>

From mailinglists at ngalt.com  Mon Sep 14 20:34:03 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Mon, 14 Sep 2020 12:34:03 -0700
Subject: Automatic hyphenation and the lang parameter to text/gemini  
Message-ID: <81942CE6-04DF-4248-9DA8-D18146895C2D@ngalt.com>

(Making a new post since this conversation finished up before I signed up for the mailing list?)

Previously:

=> https://lists.orbitalfox.eu/archives/gemini/2020/001107.html

> The two concerete motivations for adding this were:
> 
> 1. Screenreaders need to know this information to know which settings to
> use for their text-to-speech engine: the same letters correspond to
> different sounds in different languages.
> 
> 2. Search engines may want to to offer their users the ability to ask
> for results only in a particular set of languages.
> 
> Can anybody think of additional likey use cases besides these?

Automatic-hyphenation algorithms need to know what language text is in in order to know where it will, and won?t, be a good idea to stick hyphens.

From andre at andregarzia.com  Mon Sep 14 20:49:57 2020
From: andre at andregarzia.com (Andre Garzia)
Date: Mon, 14 Sep 2020 20:49:57 +0100
Subject: Firefox Add-on protocol schema
In-Reply-To: <191ff534-9a31-43e0-b6fa-e68914993c76@www.fastmail.com>
References: <2e9487b4-ba32-fbc7-9c48-400e42de5eb6@gkbrk.com>
 <48be4717-7653-4733-b902-b5334825ba18@www.fastmail.com>
 <191ff534-9a31-43e0-b6fa-e68914993c76@www.fastmail.com>
Message-ID: <CAF3jwTkqW-oMPtmuff3zttDFs0n4vptBQFUHgNLn8YBWHbDhmQ@mail.gmail.com>

I believe I was one of the last people  to get niche protocols in that list
as can be seen on this bugzilla issue[1]. I know that there is a
disconnection between that list and whatever is used by
"registerProtocolHanlder"[2], and that people at Igalia are working on
patches to webkit/blink and talking to Mozilla to make sure the
registerProtocolHandler works the same on all browser and has the dweb
protocols in it. We got SSB whitelisted in that work. You can learn a bit
more about it in [3]. I suspect that a simple patch like I did on [1] will
not work, but opening an issue and maybe attaching a patch like that might
be a good conversation opener with the maintainers. A message on one of the
channels outlined in [4] asking for help with it might be a good way to go
as well.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1428446
[2]:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
[3]: https://github.com/whatwg/html/issues/3935
[4]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Contact_us



On Mon, 14 Sep 2020 at 19:22, Emma Humphries <ech at emmah.net> wrote:

> There's a couple of Bugzilla bugs to follow on that:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1385357 this looks like this
> got regressed as reported in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1629149.
>
> I'll log in and update that.
>
> -- Emma
>
>
> On Mon, Sep 14, 2020, at 11:17, acdw wrote:
> > On 2020-09-14 (Monday) at 14:30, Leo <list at gkbrk.com> wrote:
> >
> > > Firefox has a hard-coded list of schemas that extensions are allowed
> to
> > > handle without the web+
> > > or webext+ prefix. I believe gopher can be handled this way.
> > >
> > > Has anyone got in touch or created an issue to add gemini to this
> list?
> > > While it defeats the purpose
> > > of having a separate protocol and document format, it would be good to
> > > make all the gemini:// links
> > > work in Firefox.
> > >
> > > Leo
> >
> > I haven't, but I've come across this problem as well. Would it be
> > possible for an add-on to just add "web+" to all <a> tags with
> > href^=gemini:// ? Then define a protocol handler to web+gemini?
> >
> > I was going to try this but my Javascript skills are sorely lacking.
> >
> > --
> > ~ acdw
> > acdw.net | breadpunk.club/~breadw
> >
>


-- 
https://www.andregarzia.com <http://www.andregarzia.com>
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200914/bac67dad/attachment.htm>

From skyjake at dengine.net  Mon Sep 14 21:02:09 2020
From: skyjake at dengine.net (skyjake)
Date: Mon, 14 Sep 2020 23:02:09 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CAPk6LxSaOmX_KH2jRLfDPcSp44sYdY3j=PJ6keX+56cb7OoMZA@mail.gmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
 <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
 <CAPk6LxSaOmX_KH2jRLfDPcSp44sYdY3j=PJ6keX+56cb7OoMZA@mail.gmail.com>
Message-ID: <7D54D35F-331F-4DCC-8167-29DE8F633B3E@dengine.net>

On 14. Sep 2020, at 18:04, Kevin Sangeelee <kevin at susa.net> wrote:

> I think the broader issue is that styling judgements on arbitrary text without semantic hints are only going to succeed in some cases.

Yeah there is surely no way to make this perfect in all cases without the author actually having a way to mark up a lead paragraph. In gemtext there is no such markup, and I don't think there should be. My goal is to make it work in most cases, so it 1) encourages/rewards the practice of having a brief and informative lead that stands out, while 2) being subtle enough not to be weird in other cases. Very long paragraphs, for example, can be detected and the effect could be disabled there.

The plan is to make this customizable in future builds.

> Looking again, is the font colour different for block-quotes? I'm a bit colour blind, and it's hard for me to tell. Traditional vertical bars or italics tend to stand out for me, subtle colour differences (that most people see clearly) tend not to.

The quotes use a different color and a thinner italic font. They also have their own indentation level. But yes, the vertical bar is pretty commonly used for quotes, having that as an option would be nice.

Thanks for the feedback. :)

--jaakko

From colecmac at protonmail.com  Tue Sep 15 01:52:00 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 15 Sep 2020 00:52:00 +0000
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
 <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
Message-ID: <Gl3uoJjAVoCR2P7SJVVMijgxc_HGj0bhH0bNC7quSAEphF6Gaa7eZ-0GPdcnazMVlDXkd4HadQ-FWMe5RyNh8_0WykTMDa2yhFdmr3HLeqE=@protonmail.com>

> > On 14. Sep 2020, at 3:46, colecmac at protonmail.com wrote:
> > I'm on Arch Linux, and I'm pretty sure I have all the right libs installed.
> > <strace output>
> > I downloaded the specific .tar.gz from your releases that includes theFoundation.
> > Any idea what the issue is?
>
> Hmm, at least it found the resources file, so that's good. My first guess is always that there is some problem with OpenGL. I'll add the software rendering option, but maybe in the meantime you could try going to src/ui/window.c:480 and uncomment "#define ENABLE_SWRENDER".
>
> Hopefully that helps, but if not, we could try a debug build and run it under gdb to get a stack trace?

This still crashed unfortunately. I was able to build a debug build with
-DCMAKE_BUILD_TYPE=Debug and launch gdb, but I don't know how to use
gdb and so I couldn't proceed. Can you explain more?

makeworld

From skyjake at dengine.net  Tue Sep 15 05:41:11 2020
From: skyjake at dengine.net (skyjake)
Date: Tue, 15 Sep 2020 07:41:11 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <Gl3uoJjAVoCR2P7SJVVMijgxc_HGj0bhH0bNC7quSAEphF6Gaa7eZ-0GPdcnazMVlDXkd4HadQ-FWMe5RyNh8_0WykTMDa2yhFdmr3HLeqE=@protonmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
 <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
 <Gl3uoJjAVoCR2P7SJVVMijgxc_HGj0bhH0bNC7quSAEphF6Gaa7eZ-0GPdcnazMVlDXkd4HadQ-FWMe5RyNh8_0WykTMDa2yhFdmr3HLeqE=@protonmail.com>
Message-ID: <B41C914A-0B93-464A-BC4B-11770285EAB5@dengine.net>

On 15. Sep 2020, at 3:52, colecmac at protonmail.com wrote:

>> you could try going to src/ui/window.c:480 and uncomment "#define ENABLE_SWRENDER".
>> 
>> Hopefully that helps, but if not, we could try a debug build and run it under gdb to get a stack trace?
> 
> This still crashed unfortunately. I was able to build a debug build with
> -DCMAKE_BUILD_TYPE=Debug and launch gdb, but I don't know how to use
> gdb and so I couldn't proceed. Can you explain more?

Once you have the Debug build, start gdb like this:

    gdb lagrange

And then when it crashes, type in the gdb prompt:

    bt

To print a backtrace. That'll show where the crash occurred.

However, I've already fixed one issue that could cause a crash at startup. It's currently in the "dev" branch, so you could alternatively do a git clone in an empty directory and try building that:

    git clone --recursive https://git.skyjake.fi/skyjake/lagrange

--jaakko

From hello at matthewgraybosch.com  Tue Sep 15 13:50:49 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Tue, 15 Sep 2020 08:50:49 -0400
Subject: HTML as an escape hatch
In-Reply-To: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
Message-ID: <20200915085049.7cf49c8c@kether>

On Thu, 10 Sep 2020 23:17:19 -0700
Nathan Galt <mailinglists at ngalt.com> wrote:

> There?s a persistent worry on other threads that Gemini might become
> ?too complex?, for some definition of ?complex?.

The only problem I've had with Gemtext is that it so closely resembles
Markdown that sometimes I use the wrong syntax for URLs when I'm drunk.

This isn't a bad thing, incidentally. Gemtext lends itself well to a
Gemini-first/Web-second approach where you write your content as
Gemtext first, then copy the file to the same name with a .md
or .markdown extension, change the link syntax, and add frontmatter if
you're using a static site generator like Jekyll, Hugo, or Pelican.
Hell, you could probably just use pandoc and a makefile if you know
what you're doing.

Or, you could just take your gemtext, change the extension, and
manually wrap everything in HTML tags.

> On the other hand, I think there?s a fairly, if not fully, general
> counterargument to all sorts of additions that we might want to make
> to the spec:
> 
> ?There?s nothing wrong ? or even uncool ? about making a website with
> only HTML and, at most, 30 lines of CSS that looks great in Lynx.?
> 
> Thoughts? Counterarguments?

I think a lot of people concerned about web bloat would benefit from
being directed to the following websites even if their names might be
offensive:

* http://motherfuckingwebsite.com/
* http://bettermotherfuckingwebsite.com/
* https://bestmotherfucking.website/

The first is just plain HTML with only browser default styles. The
second adds seven lines of inline CSS to the former. The third builds
upon the second and adds some server-side goodies like HTTPS, caching,
and gzip compression.

It's still not that hard to create a static website if that's what
people really want to do. I just wonder if they've forgotten how.

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>		https://starbreakersaga.com
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From colecmac at protonmail.com  Tue Sep 15 13:52:55 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 15 Sep 2020 12:52:55 +0000
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <B41C914A-0B93-464A-BC4B-11770285EAB5@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
 <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
 <Gl3uoJjAVoCR2P7SJVVMijgxc_HGj0bhH0bNC7quSAEphF6Gaa7eZ-0GPdcnazMVlDXkd4HadQ-FWMe5RyNh8_0WykTMDa2yhFdmr3HLeqE=@protonmail.com>
 <B41C914A-0B93-464A-BC4B-11770285EAB5@dengine.net>
Message-ID: <HJaIccb_61fMgkP61C4SbqP2ZJuVzsc1qUXbJnt_PZCyT1WG2n1ZHcvv0Gce_kWsh6Fqfu_H-5iNvVdzpstGuKmKssJXrJz1V2Srfrx8cwU=@protonmail.com>

> However, I've already fixed one issue that could cause a crash at startup. It's currently in the "dev" branch, so you could alternatively do a git clone in an empty directory and try building that:
>
> git clone --recursive https://git.skyjake.fi/skyjake/lagrange


This worked! Thanks for adding the libraries as submodules, it's very
helpful.

The client is beautiful, excellent work. Being able to see the domain
when hovering over links is a nice touch, and I was impressed by the
full-text search of pages I've already visited when I start typing in
the address bar.

The green padlock info is also nice. Also, it seems you've added client
certs just since you sent your first email? It would be nice if I could
import them though.

makeworld



From hello at matthewgraybosch.com  Tue Sep 15 13:53:47 2020
From: hello at matthewgraybosch.com (Matthew Graybosch)
Date: Tue, 15 Sep 2020 08:53:47 -0400
Subject: HTML as an escape hatch
In-Reply-To: <20200911065938.a5wvh6lgmlhp7dlm@terminator>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
 <20200911065938.a5wvh6lgmlhp7dlm@terminator>
Message-ID: <20200915085347.0689a62c@kether>

On Fri, 11 Sep 2020 08:59:38 +0200
Stacy Harper <contact at stacyharper.net> wrote:

> WWW decadence was fun, let's never do it again :)

This should be added to the fortune cookie databases used by the BSD
fortune utility. =^.^=

-- 
Matthew Graybosch		https://matthewgraybosch.com
#include <disclaimer.h>		https://starbreakersaga.com
	 			gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

From me at irth.pl  Tue Sep 15 14:25:16 2020
From: me at irth.pl (Wojciech Kwolek)
Date: Tue, 15 Sep 2020 15:25:16 +0200
Subject: HTML as an escape hatch
In-Reply-To: <20200915085049.7cf49c8c@kether>
References: <01ED90D4-640E-4AE9-961F-DC07E020679F@ngalt.com>
 <20200915085049.7cf49c8c@kether>
Message-ID: <483afaa7-3a8c-5ccf-ae48-cdc7e7622871@kwolek.xyz>

On 9/15/20 2:50 PM, Matthew Graybosch wrote:
> Hell, you could probably just use pandoc and a makefile if you know
> what you're doing.
I do that for my website (gemini://irth.pl / https://irth.pl).
Gemini is simple enough to write a converter for yourself in like, two
evenings:

 ? https://git.r23s.eu/wojciech/gm2html
 ? (I don't have a Gemini git front-end set up yet, excuse me :))

I run it with a Makefile to generate .html files, and I wrote some nice 
CSS to
style it: https://github.com/irth/website/blob/master/Makefile

For relative links it changes the .gmi extension to .html automatically, so
links work well on both versions.

If anyone wants, you can borrow my CSS, I'll probably add an MIT license 
and a
README to the repos when I find some time and willpower.


> It's still not that hard to create a static website if that's what
> people really want to do. I just wonder if they've forgotten how.
It is possible, but having a specification that forces you to do that allows
the reader to have some expectations before clicking a link. If I see a
gemini:// link, I know I won't have to sit through a few seconds of 
loading up
all the javascript before seeing the text :)

-- 
Wojciech ~irth Kwolek

- gemini://irth.pl
- https://irth.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200915/74ea37f5/attachment.htm>

From skyjake at dengine.net  Tue Sep 15 17:55:25 2020
From: skyjake at dengine.net (skyjake)
Date: Tue, 15 Sep 2020 19:55:25 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <HJaIccb_61fMgkP61C4SbqP2ZJuVzsc1qUXbJnt_PZCyT1WG2n1ZHcvv0Gce_kWsh6Fqfu_H-5iNvVdzpstGuKmKssJXrJz1V2Srfrx8cwU=@protonmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <5F5E8991.1070908@marmaladefoo.com>
 <FAFAA0ED-AB2A-4857-8AF5-EC1684AD66C6@dengine.net>
 <Gl3uoJjAVoCR2P7SJVVMijgxc_HGj0bhH0bNC7quSAEphF6Gaa7eZ-0GPdcnazMVlDXkd4HadQ-FWMe5RyNh8_0WykTMDa2yhFdmr3HLeqE=@protonmail.com>
 <B41C914A-0B93-464A-BC4B-11770285EAB5@dengine.net>
 <HJaIccb_61fMgkP61C4SbqP2ZJuVzsc1qUXbJnt_PZCyT1WG2n1ZHcvv0Gce_kWsh6Fqfu_H-5iNvVdzpstGuKmKssJXrJz1V2Srfrx8cwU=@protonmail.com>
Message-ID: <C28FD45D-225A-4CB4-BA22-C05416C23821@dengine.net>

On 15. Sep 2020, at 15:52, colecmac at protonmail.com wrote:

> Also, it seems you've added client certs just since you sent your first email? It would be nice if I could import them though.

Importing existing certificates is already possible, although there is no UI for it yet and there are some requirements for the files. I added this to the Help page:

```
### Importing existing certificates

At launch, Lagrange looks through its "idents" directory to see if any new certificates have been copied there. (See "Runtime files" below for the location.) The file format must be PEM. Both a certificate (.crt) and its private key (.key) must be found in "idents" and they must have matching file names. For example:
* mycert.crt
* mycert.key
Lagrange will add a note to the imported identities to mark them as "Imported".
```

On Linux, the directory is "~/.config/lagrange/idents/".

--jaakko

From mailinglists at ngalt.com  Fri Sep 18 08:32:40 2020
From: mailinglists at ngalt.com (mailinglists at ngalt.com)
Date: Fri, 18 Sep 2020 00:32:40 -0700
Subject: Should Gemini clients alert users upon redirect?
Message-ID: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>

Background reading:

=> https://alistapart.com/article/slashforward/

In the above article, Dan Bogan makes a case for adding slashes to the end of all URLs.? I thought it was convincing, so that's how I've been rolling for years.

One of my current favorite Gemini clients, by default, alerts the user when following a link and gives the user an option to continue or abort the navigation.

One of the capsules I visit from both CAPCOM and Spacewalk has links that are all trailing-slashless. Not only are the links in CAPCOM/Spacewalk slashless, but the intra-capsule links are as well.

Should I be sending a polite change request to the author of the capsule, to the maintainer of the Gemini client, to both, or neither? At least with the Gemini client, I could send along a patch to change the default.

----

? Time and CMS changes have not been good to the article. You'll need to hover over the links in the code snippets and look at your link-preview bar/popup to see what he's talking about.

From sandra.snan at idiomdrottning.org  Fri Sep 18 09:45:56 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Fri, 18 Sep 2020 10:45:56 +0200
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
Message-ID: <87pn6ja2wr.fsf@idiomdrottning.org>

That might be me.

I am already aware of Bogan's case, I read it back in 2002.
I find the arguments for slashless more convincing than the arguments against.

Please just change that setting in the client.

Thank you?



mailinglists at ngalt.com writes:

> Background reading:
>
> => https://alistapart.com/article/slashforward/
>
> In the above article, Dan Bogan makes a case for adding slashes to the end of all URLs.? I thought it was convincing, so that's how I've been rolling for years.
>
> One of my current favorite Gemini clients, by default, alerts the user when following a link and gives the user an option to continue or abort the navigation.
>
> One of the capsules I visit from both CAPCOM and Spacewalk has links that are all trailing-slashless. Not only are the links in CAPCOM/Spacewalk slashless, but the intra-capsule links are as well.
>
> Should I be sending a polite change request to the author of the capsule, to the maintainer of the Gemini client, to both, or neither? At least with the Gemini client, I could send along a patch to change the default.
>
> ----
>
> ? Time and CMS changes have not been good to the article. You'll need to hover over the links in the code snippets and look at your link-preview bar/popup to see what he's talking about.

From sean at conman.org  Fri Sep 18 10:17:34 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 18 Sep 2020 05:17:34 -0400
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <87pn6ja2wr.fsf@idiomdrottning.org>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <87pn6ja2wr.fsf@idiomdrottning.org>
Message-ID: <20200918091734.GK19614@brevard.conman.org>

It was thus said that the Great Sandra Snan once stated:
> That might be me.
> 
> I am already aware of Bogan's case, I read it back in 2002.
> I find the arguments for slashless more convincing than the arguments against.

  I'm curious as to what the argument against is, because the slash is
semantically important.

=> gemini://gemini.conman.org/test/doc1  This is not a directory.
=> gemini://gemini.conman.org/test/doc1/ And this is not the document you think it is

  See, this topic came up earlier this year:

	https://lists.orbitalfox.eu/archives/gemini/2020/001998.html

  And then there's the reason for the tailing slash that Solderpunk gives:

	https://lists.orbitalfox.eu/archives/gemini/2020/002000.html

  The whole thread starts here:

	https://lists.orbitalfox.eu/archives/gemini/2020/001964.html

  -spc

From sandra.snan at idiomdrottning.org  Fri Sep 18 10:27:21 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Fri, 18 Sep 2020 11:27:21 +0200
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <0e237d77-bdd4-4fcd-ad35-0595adfc96bb@www.fastmail.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <87pn6ja2wr.fsf@idiomdrottning.org>
 <0e237d77-bdd4-4fcd-ad35-0595adfc96bb@www.fastmail.com>
Message-ID: <87imcba0zq.fsf@idiomdrottning.org>

mailinglists at ngalt.com writes:
> It was.

Thank you so much for reading my stuff??
Much apprec?

> I'd be _very_ happy to read arguments in favor of slashless.

It is a way to write future-proof links that work on both dynamic and
static content.

This is a site that has survived several CMS changes and has been up
with the same look for 11 years.

Earlier version of Jekyll allowed slashless without redirecting, not
sure how it worked but it stopped working so I've altered my nginx conf
to just serve them as directories with index.html files, and Molly of
course has index.gmi out of the box. I didn't want to change my linking
style from the old site in the hopes that one day I'll have a CMS that
once more has slashless URLs.

The _counter_ argument to that, then, is that dynamic url routers could
be configured to add faux slashes back in to match. And that's a good
counter-argument. Anything you can do to make your site consistent is
good. And the dynamic portion of my site (the Fedi frontent) currently
does allow faux trailing slashes.

Bogan's text was written in 2002 and his own site has, as you point out,
had some rough times when it comes to consistency:
> Time and CMS changes have not been good to the article. You'll need to
> hover over the links in the code snippets and look at your
> link-preview bar/popup to see what he's talking about.

He wrote that before nginx came out, in the Apache era. Nginx just
serves the file right up without a bunch of redirects (hopefully?I
haven't triple checked that).

Now, I do appreciate you alerting me that Molly does do the similar
shenanigans that

Bogan describes:
> Just a minute; first I?ll try to find a file called ?subdirectory.? ?
> Wait a second; it?s not there! How about a directory called
> ?subdirectory?? ? Ah, here we go. Okay. And next time, please use a
> trailing slash.

That's something I would hope could change in future versions of Molly.

Also, my capsule might not always be on Molly. (Even though it's a
fantastic server.?)

The bottom line is that the indented external semantics is that requests
are asking for content, and those requests should be separated from the
specific implementation, such as file system representation.

From list at gkbrk.com  Fri Sep 18 11:20:58 2020
From: list at gkbrk.com (Leo)
Date: Fri, 18 Sep 2020 13:20:58 +0300
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
Message-ID: <61d33b75-4030-488b-c4e4-83eac1368855@gkbrk.com>

The client can do whatever it wants, and people can link to you in arbitrary ways.

> I could send along a patch to change the default

While it might be more ergonomic to only alert the user if the redirect is changing origin,
there is nothing inherently wrong with alerting for every redirect. Even if you send a patch to
fix (a non-broken) default for that client, there is no guarantee that people don't change the
default or simply use different clients.

> Should I be sending a polite change request to the author of the capsule

You can email the capsule author, but from their perspective, you are making a needless change to a
working URL. The correct way to handle this situation is to either keep redirecting and stop caring
about how different clients handle it, or to stop redirecting and give a not found error and le
people link you correctly.


From lambdatronic at disroot.org  Fri Sep 18 18:54:00 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 18 Sep 2020 13:54:00 -0400
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <87imcba0zq.fsf@idiomdrottning.org>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <87pn6ja2wr.fsf@idiomdrottning.org>
 <0e237d77-bdd4-4fcd-ad35-0595adfc96bb@www.fastmail.com>
 <87imcba0zq.fsf@idiomdrottning.org>
Message-ID: <87k0wr9djb.fsf@disroot.org>

Hi folks,

I am the author of a Gemini server called Space Age.

=> https://gitlab.com/lambdatronic/space-age/

When I submitted my server for inclusion on the "Gemini software" list
(gemini://gemini.circumlunar.space/software/), Solderpunk wrote to me to
explicitly verify that my server redirected clients who requested
slashless URLs to their slashed equivalents. He pointed out that any
relative URLs in the returned Gemtext would not behave as expected in
most clients when navigating away from a slashless parent page.
Therefore, server redirection of slashless URLs was mandatory for Gemini
servers.

Given this requirement, I believe the standing recommendation to authors
of Gemtext pages is to always include slashes in your links in order to
prevent page redirects and speed up loading time for your users.

Now you know, and knowing is half the battle!

Happy hacking,
  Gary


Sandra Snan <sandra.snan at idiomdrottning.org> writes:

> mailinglists at ngalt.com writes:
>> It was.
>
> Thank you so much for reading my stuff??
> Much apprec?
>
>> I'd be _very_ happy to read arguments in favor of slashless.
>
> It is a way to write future-proof links that work on both dynamic and
> static content.
>
> This is a site that has survived several CMS changes and has been up
> with the same look for 11 years.
>
> Earlier version of Jekyll allowed slashless without redirecting, not
> sure how it worked but it stopped working so I've altered my nginx conf
> to just serve them as directories with index.html files, and Molly of
> course has index.gmi out of the box. I didn't want to change my linking
> style from the old site in the hopes that one day I'll have a CMS that
> once more has slashless URLs.
>
> The _counter_ argument to that, then, is that dynamic url routers could
> be configured to add faux slashes back in to match. And that's a good
> counter-argument. Anything you can do to make your site consistent is
> good. And the dynamic portion of my site (the Fedi frontent) currently
> does allow faux trailing slashes.
>
> Bogan's text was written in 2002 and his own site has, as you point out,
> had some rough times when it comes to consistency:
>> Time and CMS changes have not been good to the article. You'll need to
>> hover over the links in the code snippets and look at your
>> link-preview bar/popup to see what he's talking about.
>
> He wrote that before nginx came out, in the Apache era. Nginx just
> serves the file right up without a bunch of redirects (hopefully?I
> haven't triple checked that).
>
> Now, I do appreciate you alerting me that Molly does do the similar
> shenanigans that
>
> Bogan describes:
>> Just a minute; first I?ll try to find a file called ?subdirectory.? ?
>> Wait a second; it?s not there! How about a directory called
>> ?subdirectory?? ? Ah, here we go. Okay. And next time, please use a
>> trailing slash.
>
> That's something I would hope could change in future versions of Molly.
>
> Also, my capsule might not always be on Molly. (Even though it's a
> fantastic server.?)
>
> The bottom line is that the indented external semantics is that requests
> are asking for content, and those requests should be separated from the
> specific implementation, such as file system representation.


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From dealpete at fastmail.com  Fri Sep 18 20:01:48 2020
From: dealpete at fastmail.com (Peter Deal)
Date: Fri, 18 Sep 2020 16:31:48 -0230
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
Message-ID: <9D4EDF01-8790-4564-A4B3-CD3329AF42E3@fastmail.com>

When I was creating my Gemini client for MacOS, I actually had some difficulty with this. The default Swift URL library automatically removes the slash from the end of a path when you?re converting from a string. It took me some effort to get it working properly for Gemini links - I ended up creating my own GeminiURL struct that puts the slashes back at the end of the path.

Peter

> On Sep 18, 2020, at 5:02 AM, mailinglists at ngalt.com wrote:
> 
> Background reading:
> 
> => https://alistapart.com/article/slashforward/
> 
> In the above article, Dan Bogan makes a case for adding slashes to the end of all URLs.? I thought it was convincing, so that's how I've been rolling for years.
> 
> One of my current favorite Gemini clients, by default, alerts the user when following a link and gives the user an option to continue or abort the navigation.
> 
> One of the capsules I visit from both CAPCOM and Spacewalk has links that are all trailing-slashless. Not only are the links in CAPCOM/Spacewalk slashless, but the intra-capsule links are as well.
> 
> Should I be sending a polite change request to the author of the capsule, to the maintainer of the Gemini client, to both, or neither? At least with the Gemini client, I could send along a patch to change the default.
> 
> ----
> 
> ? Time and CMS changes have not been good to the article. You'll need to hover over the links in the code snippets and look at your link-preview bar/popup to see what he's talking about.


From luke at marmaladefoo.com  Sat Sep 19 10:11:57 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 19 Sep 2020 10:11:57 +0100
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <61d33b75-4030-488b-c4e4-83eac1368855@gkbrk.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <61d33b75-4030-488b-c4e4-83eac1368855@gkbrk.com>
Message-ID: <5F65CB5D.1090200@marmaladefoo.com>

On 18-Sep-2020 11:20, Leo wrote:
> The client can do whatever it wants, and people can link to you in 
> arbitrary ways.
>
>> I could send along a patch to change the default
>
> While it might be more ergonomic to only alert the user if the 
> redirect is changing origin,
> there is nothing inherently wrong with alerting for every redirect. 
> Even if you send a patch to
> fix (a non-broken) default for that client, there is no guarantee that 
> people don't change the
> default or simply use different clients.
>
>> Should I be sending a polite change request to the author of the capsule
>
> You can email the capsule author, but from their perspective, you are 
> making a needless change to a
> working URL. The correct way to handle this situation is to either 
> keep redirecting and stop caring
> about how different clients handle it, or to stop redirecting and give 
> a not found error and le
> people link you correctly.
>
I largely agree. Whilst Gemini clearly has some differences from the web 
in this regard, for me this is an area of functionality where we should 
do by and large the same as the web. Both are path and text based 
hypertext systems and authors expectations will be already established.

Personally I think there is no reason for a client to request permission 
for a redirect to another page on the same server.

If the main concern is a "silent" traversal from a known location to an 
unknown one, a better fix is for the client to indicate the traversal, 
but not require an action from the user

In my own client GemiNaut it is obvious when you traverse from one 
domain to another as the theme changes, so there is never a case that 
the user is silently and unknowably redirected. Other clients without 
such a clear visual distinction between domains might think a user 
interaction is sensible. However, bear in mind that from a UI design 
point of view, interrupting the user to require them to click a button 
or press "OK" (or equivalent) is generally a sort of last resort to be 
avoided, because it brings them back into focus of the software tool, 
rather than focussing on their task at hand or their train of thought.

I don't think Gemini clients ought to always interrupt the user upon a 
server request. As usual with these things, it is finding a balance 
between visibility of system action, security considerations, usability 
and personal preference.

Best wishes

  - Luke

From luke at marmaladefoo.com  Sat Sep 19 10:15:24 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 19 Sep 2020 10:15:24 +0100
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <5F65CB5D.1090200@marmaladefoo.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <61d33b75-4030-488b-c4e4-83eac1368855@gkbrk.com>
 <5F65CB5D.1090200@marmaladefoo.com>
Message-ID: <5F65CC2C.9060204@marmaladefoo.com>

Perhaps an obvious typo fix, I meant to type: "I don't think Gemini 
clients ought to always interrupt the user upon a server [redirect]".

On 19-Sep-2020 10:11, Luke Emmet wrote:
> I don't think Gemini clients ought to always interrupt the user upon a 
> server request.

From list at gkbrk.com  Sat Sep 19 11:47:39 2020
From: list at gkbrk.com (Leo)
Date: Sat, 19 Sep 2020 13:47:39 +0300
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <5F65CB5D.1090200@marmaladefoo.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <61d33b75-4030-488b-c4e4-83eac1368855@gkbrk.com>
 <5F65CB5D.1090200@marmaladefoo.com>
Message-ID: <96032c46-c172-fbc8-f811-9770d4f06c61@gkbrk.com>

> Whilst Gemini clearly has some differences from the web 
> in this regard, for me this is an area of functionality where we should 
> do by and large the same as the web.

Using the web does not mean redirections happen seamlessly, or happen at
all. Users can have their browsers alert for redirects, or simply not
follow redirects. The HTTP spec seems to support this use case as well.

> If a Location header field is provided, the user agent MAY
> automatically redirect its request to the URI referenced by the
> Location field value

and also at

> The server SHOULD generate a Location header field in the response
> containing a URI reference for the different URI.  The user agent MAY
> use the Location field value for automatic redirection.

So common web browsers, like common gemini browsers, might redirect
seamlessly, but "User Agents" (instead of popular software that are
agents of someone else) still reserve the right to ask the user
what to do at any point.


From luke at marmaladefoo.com  Sat Sep 19 12:37:15 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 19 Sep 2020 12:37:15 +0100
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <96032c46-c172-fbc8-f811-9770d4f06c61@gkbrk.com>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <61d33b75-4030-488b-c4e4-83eac1368855@gkbrk.com>
 <5F65CB5D.1090200@marmaladefoo.com>
 <96032c46-c172-fbc8-f811-9770d4f06c61@gkbrk.com>
Message-ID: <5F65ED6B.1090506@marmaladefoo.com>



On 19-Sep-2020 11:47, Leo wrote:
>
> Using the web does not mean redirections happen seamlessly, or happen at
> all. Users can have their browsers alert for redirects, or simply not
> follow redirects. The HTTP spec seems to support this use case as well.

I don't know of any web client that generally implements browser alerts 
for redirects. Maybe they do exist though, or perhaps you can configure 
them to do so.

> So common web browsers, like common gemini browsers, might redirect
> seamlessly, but "User Agents" (instead of popular software that are
> agents of someone else) still reserve the right to ask the user
> what to do at any point.

I get your shift of emphasis here, but a Gemini client is a user agent 
(as is a web browser) in the protocol sense - it retrieves content on 
behalf of a user request. The web is so complex that most end users are 
not in a position to control the fine grained behaviour, beyond a few 
preferences here and there. Although in Firefox there are more 
parameters you can configure if you are willing to delve in about:config.

Due to its simplicity, one of the nice things about Gemini is the wide 
choice of clients. And of course the barriers to writing your own client 
that implements exactly the behaviour you want are much lower.

Best Wishes

  - Luke

From sir at cmpwn.com  Mon Sep 21 03:12:26 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sun, 20 Sep 2020 22:12:26 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque utility
 program
Message-ID: <C5SOLZDXEHW6.2JZPL0DZ8GM3S@homura>

Hiya! I felt that the Gemini space has a lot of cool browers, but was
missing the basic works-everywhere client with few-to-no dependencies.

gmni fills that role:

https://sr.ht/~sircmpwn/gmni

Here's a recording which shows off some of its features:

https://asciinema.org/a/Y7viodM01e0AXYyf40CwSLAVA

Two tools are provided: gmni, a curl-like utility which executes Gemini
requests and writes the response to stdout, and gmnlm, a line-mode
interactive browser. The latter is demonstrated in the recording above.

The whole thing clocks in at approximately 3,000 lines of C11. It'll
grow a little bit with TOFU and client-side certificate support, but
otherwise it's pretty close to done. The only dependencies are a
POSIX-like system and OpenSSL.

The Gemini protocol implementation is pretty concise and
straightforward:

https://git.sr.ht/~sircmpwn/gmni/tree/master/include/gmni.h
https://git.sr.ht/~sircmpwn/gmni/tree/master/src/client.c
https://git.sr.ht/~sircmpwn/gmni/tree/master/src/parser.c

If there's any demand for it, I'll package these up into a library you
can link to. I also plan on writing a Gemini server in C with a similar
design approach.

Enjoy!

From kevin at susa.net  Mon Sep 21 10:54:32 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 21 Sep 2020 10:54:32 +0100
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <C5SOLZDXEHW6.2JZPL0DZ8GM3S@homura>
References: <C5SOLZDXEHW6.2JZPL0DZ8GM3S@homura>
Message-ID: <CAPk6LxSdDKUXr1cNBY_3ax4xu3wSduatooEd08jxUHWfekLbuQ@mail.gmail.com>

 I get a weird sense of catharsis from stuff written in C - thanks for this.

I'm struck by the fact that URL parsing accounts for about half the code -
a stark reminder both of the effort required to handle formal
specifications properly, and of the value of the GPL.

Good stuff!

On Mon, 21 Sep 2020 at 03:30, Drew DeVault <sir at cmpwn.com> wrote:

> Hiya! I felt that the Gemini space has a lot of cool browers, but was
> missing the basic works-everywhere client with few-to-no dependencies.
>
> gmni fills that role:
>
> https://sr.ht/~sircmpwn/gmni
>
> Here's a recording which shows off some of its features:
>
> https://asciinema.org/a/Y7viodM01e0AXYyf40CwSLAVA
>
> Two tools are provided: gmni, a curl-like utility which executes Gemini
> requests and writes the response to stdout, and gmnlm, a line-mode
> interactive browser. The latter is demonstrated in the recording above.
>
> The whole thing clocks in at approximately 3,000 lines of C11. It'll
> grow a little bit with TOFU and client-side certificate support, but
> otherwise it's pretty close to done. The only dependencies are a
> POSIX-like system and OpenSSL.
>
> The Gemini protocol implementation is pretty concise and
> straightforward:
>
> https://git.sr.ht/~sircmpwn/gmni/tree/master/include/gmni.h
> https://git.sr.ht/~sircmpwn/gmni/tree/master/src/client.c
> https://git.sr.ht/~sircmpwn/gmni/tree/master/src/parser.c
>
> If there's any demand for it, I'll package these up into a library you
> can link to. I also plan on writing a Gemini server in C with a similar
> design approach.
>
> Enjoy!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200921/1d8dca04/attachment.htm>

From magnus at kalasarn.se  Mon Sep 21 12:01:37 2020
From: magnus at kalasarn.se (Magnus Wild)
Date: Mon, 21 Sep 2020 13:01:37 +0200
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <C5SOLZDXEHW6.2JZPL0DZ8GM3S@homura>
References: <C5SOLZDXEHW6.2JZPL0DZ8GM3S@homura>
Message-ID: <20200921110137.hsnca4oj7f62dhev@yasuna.kalasarn.se>

On Sun, Sep 20, 2020 at 10:12:26PM -0400, Drew DeVault wrote:
> Hiya! I felt that the Gemini space has a lot of cool browers, but was
> missing the basic works-everywhere client with few-to-no dependencies.

This is cool. I managed to build it on openbsd-current with a small
modification;

--- a/src/gmnlm.c
+++ b/src/gmnlm.c
@@ -10,6 +10,7 @@
 #include <sys/ioctl.h>
 #include <termios.h>
 #include <unistd.h>
+#include <limits.h>
 #include "gmni.h"
 #include "url.h"
 #include "util.h"

The error I got before this modification can be seen below.

openbsd-build$ make
CC      src/client.o
CC      src/escape.o
CC      src/gmni.o
CC      src/url.o
CCLD    gmni
CC      src/gmnlm.o
src/gmnlm.c:127:19: error: use of undeclared identifier 'PATH_MAX'
        static char path[PATH_MAX+1];
                         ^
src/gmnlm.c:155:19: error: use of undeclared identifier 'PATH_MAX'
        static char path[PATH_MAX+1];
                         ^
src/gmnlm.c:157:18: error: use of undeclared identifier 'PATH_MAX'
        static char url[PATH_MAX+1+7];
                        ^
3 errors generated.
*** Error 1 in /home/magnus/gmni/build (Makefile:25 'src/gmnlm.o': @cc -c -g  -std=c11  -D_XOPEN_SOURCE=700  -Wall  -Wextra  -Werror  -pedan...)

The program is really small and seems very useful. Thanks a lot for spending time on this and sharing it!

/Magnus

From sir at cmpwn.com  Mon Sep 21 12:56:33 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 21 Sep 2020 07:56:33 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <20200921110137.hsnca4oj7f62dhev@yasuna.kalasarn.se>
Message-ID: <C5T117NIBFV9.2D3U2U20H1OGU@homura>

On Mon Sep 21, 2020 at 7:01 AM EDT, Magnus Wild wrote:
> This is cool. I managed to build it on openbsd-current with a small
> modification;
>
> --- a/src/gmnlm.c
> +++ b/src/gmnlm.c
> @@ -10,6 +10,7 @@
> #include <sys/ioctl.h>
> #include <termios.h>
> #include <unistd.h>
> +#include <limits.h>
> #include "gmni.h"
> #include "url.h"
> #include "util.h"

Thanks, I just pushed this change upstream.

> The program is really small and seems very useful. Thanks a lot for
> spending time on this and sharing it!

Cheers!

From magnus at kalasarn.se  Mon Sep 21 19:08:23 2020
From: magnus at kalasarn.se (Magnus Wild)
Date: Mon, 21 Sep 2020 20:08:23 +0200
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <C5T117NIBFV9.2D3U2U20H1OGU@homura>
References: <20200921110137.hsnca4oj7f62dhev@yasuna.kalasarn.se>
 <C5T117NIBFV9.2D3U2U20H1OGU@homura>
Message-ID: <20200921180823.mpxhor3meaib3anb@winston.kalasarn.se>

On Mon, Sep 21, 2020 at 07:56:33AM -0400, Drew DeVault wrote:
> 
> Thanks, I just pushed this change upstream.
> 

Nice! That was quick. Thanks a lot! :)

/Magnus

From alex at nytpu.com  Mon Sep 21 20:04:22 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Mon, 21 Sep 2020 13:04:22 -0600
Subject: Using normal tls certificates with gemini
Message-ID: <20200921190422.gcrznea44ljk4my6@GLaDOS>

Hey everybody,

For my gemini capsule's tls setup, I just used my Let's Encrypt
certificate since I already had it set up for my web site. However,
after reading deeper into server setup with gemini, I discovered that
I'm probably adding a lot of extra request overhead by using a
certificate from a CA instead of self-signed. Now my problem is that if
I change out the certificate, then people that have previously visited
my site may think it is compromised because the certificate changed and
most clients are TOFU. Should I change out the certificate or is it fine
to leave it as is?

As an additional question, if I was writing a more advanced gemini
client, should I validate cert chains if they're availaible or only use
TOFU on the fingerprint and ignore chains entirely? The spec just says
to validate however you want, but what's the community's recommendation?

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://e-mail.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200921/2c288e16/attachment.sig>

From tcb913 at gmail.com  Mon Sep 21 20:26:05 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Mon, 21 Sep 2020 15:26:05 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <C5SOLZDXEHW6.2JZPL0DZ8GM3S@homura>
References: <C5SOLZDXEHW6.2JZPL0DZ8GM3S@homura>
Message-ID: <e363f0a8-46b1-42c2-91b0-9655b06edf10@gmail.com>

Hi! I read this message and thought I'd install the browser. To make a 
long story short:

I built and installed scdoc with no problems.

I ran configure in the gmni directory with no problems.

When I ran "make" in gmni directory, I got four errors:

     in client.c, line 126: implicit declaration of SSL_CTX_up_ref

     in client.c, line 128: implicit declaration of TLS_method

     in client.c, line 128: implicit conversion from int to pointer in 
arg to SSL_CTX_new

     in client.c, line 135: implicit declaration of SSL_up_ref

Seems like something's missing. I find no

BTW, you define CC as cc in config.sh. On my system cc is an alias for 
gcc-5.3.0. That should not be a problem.

Terry Brennan

On 09/20/2020 10:12 PM, Drew DeVault wrote:
> Hiya! I felt that the Gemini space has a lot of cool browers, but was
> missing the basic works-everywhere client with few-to-no dependencies.
>
> gmni fills that role:
>
> https://sr.ht/~sircmpwn/gmni
>
> Here's a recording which shows off some of its features:
>
> https://asciinema.org/a/Y7viodM01e0AXYyf40CwSLAVA
>
> Two tools are provided: gmni, a curl-like utility which executes Gemini
> requests and writes the response to stdout, and gmnlm, a line-mode
> interactive browser. The latter is demonstrated in the recording above.
>
> The whole thing clocks in at approximately 3,000 lines of C11. It'll
> grow a little bit with TOFU and client-side certificate support, but
> otherwise it's pretty close to done. The only dependencies are a
> POSIX-like system and OpenSSL.
>
> The Gemini protocol implementation is pretty concise and
> straightforward:
>
> https://git.sr.ht/~sircmpwn/gmni/tree/master/include/gmni.h
> https://git.sr.ht/~sircmpwn/gmni/tree/master/src/client.c
> https://git.sr.ht/~sircmpwn/gmni/tree/master/src/parser.c
>
> If there's any demand for it, I'll package these up into a library you
> can link to. I also plan on writing a Gemini server in C with a similar
> design approach.
>
> Enjoy!


From sir at cmpwn.com  Mon Sep 21 20:28:06 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 21 Sep 2020 15:28:06 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <e363f0a8-46b1-42c2-91b0-9655b06edf10@gmail.com>
Message-ID: <C5TAMYA5U7N3.215NYC5PC0X95@homura>

That's quite bizzare. Are you perhaps using a system with LibreSSL
instead of OpenSSL?

From acdw at acdw.net  Mon Sep 21 20:36:22 2020
From: acdw at acdw.net (acdw)
Date: Mon, 21 Sep 2020 19:36:22 +0000
Subject: Using normal tls certificates with gemini
In-Reply-To: <20200921190422.gcrznea44ljk4my6@GLaDOS>
References: <20200921190422.gcrznea44ljk4my6@GLaDOS>
Message-ID: <e985543a-526f-4548-b964-b5fa96426f7c@www.fastmail.com>

On 2020-09-21 (Monday) at 19:04, Alex // nytpu <alex at nytpu.com> wrote:

> Hey everybody,
> 
> For my gemini capsule's tls setup, I just used my Let's Encrypt
> certificate since I already had it set up for my web site. However,
> after reading deeper into server setup with gemini, I discovered that
> I'm probably adding a lot of extra request overhead by using a
> certificate from a CA instead of self-signed. Now my problem is that if
> I change out the certificate, then people that have previously visited
> my site may think it is compromised because the certificate changed and
> most clients are TOFU. Should I change out the certificate or is it fine
> to leave it as is?

IMHO, you're fine as-is. I think I changed out breadpunk.club's cert when the Let's Encrypt one for HTTPS updated/changed, but I don't think you have to worry about it til then, if even then. There might be  more advanced statistics for who has a full cert vs. self-signed around somewhere, though.

> 
> As an additional question, if I was writing a more advanced gemini
> client, should I validate cert chains if they're availaible or only use
> TOFU on the fingerprint and ignore chains entirely? The spec just says
> to validate however you want, but what's the community's recommendation?

Again, IMHO, but I'd just do TOFU validation on the fingerprint ... unless you want to maybe be the *most* advanced gemini client out there!

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From sir at cmpwn.com  Mon Sep 21 21:09:21 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 21 Sep 2020 16:09:21 -0400
Subject: Using normal tls certificates with gemini
In-Reply-To: <20200921190422.gcrznea44ljk4my6@GLaDOS>
Message-ID: <C5TBIIZOFZ3E.1Y0LQQFHANUJ2@homura>

On Mon Sep 21, 2020 at 3:04 PM EDT, Alex // nytpu wrote:
> As an additional question, if I was writing a more advanced gemini
> client, should I validate cert chains if they're availaible or only use
> TOFU on the fingerprint and ignore chains entirely? The spec just says
> to validate however you want, but what's the community's recommendation?

Coincidentally, I just finished a TOFU implementation in my client which
I'm relatively satisfied with. To answer your question directly, I chose
to disregard the certificate chain and *always* use TOFU. I don't think
the CA cabal is something Gemini needs to get used to supporting.

In more detail, the TOFU algorithm I decided to use is:

1. On startup, the client loads a list of known hosts from
   ~/.local/share/gmni/known_hosts (adjusted per XDG basedirs as
   appropriate), which is a plaintext file where each line is one host,
   with the following attributes in order, separated by spaces:

   hostname fingerprint-algorithm fingerprint expires

   fingerprint-algorithm is always "SHA-512"; if it's not, this
   known_hosts entry is discarded. The fingerprint is the SHA-512 digest
   of the X509 certificate, and expiry is the Unix timestamp of the
   certificate's notAfter time.
2. Upon receiving a request to validate a certificate:
   A. It confirms that the current time is within [notBefore, notAfter].
      If not, the trust state is INVALID, GOTO 3.
   B. Computes the fingerprint.
   C. Consults the list of known hosts for a matching host. If not
      found, the trust state is UNKNOWN, GOTO 3.
   D. If a matching host is found, and the fingerprint matches, the
      trust state is TRUSTED. GOTO 3.
   E. If a matching host is found, and the fingerprint does not match,
      the trust state is UNTRUSTED. GOTO 3.
3. If the trust state is TRUSTED, proceed with the request.
4. If the trust state is UNKNOWN, display the fingerprint to the user
   and ask them if they want to trust this certificate, now or always.
   If always, another entry is written to known_hosts.
5. If the trust state is INVALID, the user is told about the issue and
   given the option to continue (but not to update known_hosts).
6. If the trust state is UNTRUSTED, the user is told so and the request
   is aborted. The user must manually intervene in the known_hosts file
   to continue.

Code is here:

https://git.sr.ht/~sircmpwn/gmni/commit/02f6af661513683f0c6c1465c5ff1dd8f03a30c9

From tcb913 at gmail.com  Mon Sep 21 21:41:47 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Mon, 21 Sep 2020 16:41:47 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <C5TAMYA5U7N3.215NYC5PC0X95@homura>
References: <C5TAMYA5U7N3.215NYC5PC0X95@homura>
Message-ID: <3004de46-c11a-c341-eb29-e39f3d387c13@gmail.com>

No, definitely using openssl. Lots of library stuff, and header files.

BTW, error messages did not report missing header files.

My openssl lib is libgnutils-openssl.so.27.0.2, if this helps.

tb


On 09/21/2020 03:28 PM, Drew DeVault wrote:
> That's quite bizzare. Are you perhaps using a system with LibreSSL
> instead of OpenSSL?


From sir at cmpwn.com  Mon Sep 21 21:43:19 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 21 Sep 2020 16:43:19 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <3004de46-c11a-c341-eb29-e39f3d387c13@gmail.com>
Message-ID: <C5TC8J7500SI.174UXR7ASQIZ9@homura>

gnutls-openssl is not openssl.

From henderson.j at protonmail.com  Tue Sep 22 16:18:15 2020
From: henderson.j at protonmail.com (James Henderson)
Date: Tue, 22 Sep 2020 15:18:15 +0000
Subject: Genini requests with ncat
Message-ID: <i635v_2YJ3FgPKeqyJUB5XWa9uBLJ3K20m2Tv-fATFwb9zPCqbQj2JGMZzk7yInBP2Oz8T1T_dbTgjkYZFwSclHvIuOYyfdO48LM8sr6Puk=@protonmail.com>

Hi there,

I am trying to make gemini requests with ncat and have hit a bit of a stumbling block that I am not sure how to solve so was wondering if anyone here knew what was going on.

If i make a request as such:

echo -e ?gemini://gemini.conman.org\r\n? | ncat ?ssl ?gemini.conman.org? >page.out

I get the expected index page from gemini.conman.org printed into a file.

However if i try the same with

echo -e ?gemini://gemini.circumlunar.space\r\n? | ncat ?ssl ?gemini.circumlunar.space? >page.out

I get a 31 redirect. If i try that redirect address which is the same but with a / on the end of the url then the requests fails Where in would expect the gemini.circumlunar.space home page to be output to a file.

I feel like there is something obvious I am missing.

Anyone done this and know whats wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200922/4f70eac7/attachment.htm>

From julien at typed-hole.org  Tue Sep 22 16:30:31 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Tue, 22 Sep 2020 17:30:31 +0200
Subject: Genini requests with ncat
In-Reply-To: <i635v_2YJ3FgPKeqyJUB5XWa9uBLJ3K20m2Tv-fATFwb9zPCqbQj2JGMZzk7yInBP2Oz8T1T_dbTgjkYZFwSclHvIuOYyfdO48LM8sr6Puk=@protonmail.com>
References: <i635v_2YJ3FgPKeqyJUB5XWa9uBLJ3K20m2Tv-fATFwb9zPCqbQj2JGMZzk7yInBP2Oz8T1T_dbTgjkYZFwSclHvIuOYyfdO48LM8sr6Puk=@protonmail.com>
Message-ID: <723f24b9-b988-a850-4079-5cdbd39e5453@typed-hole.org>

On 22/09/2020 17:18, James Henderson wrote:
> Hi there,
> 
> I am trying to make gemini requests with ncat and have hit a bit of a 
> stumbling block that I am not sure how to solve so was wondering if 
> anyone here knew what was going on.
> 
> If i make a request as such:
> 
> echo -e ?gemini://gemini.conman.org\r\n? | ncat ?ssl ?gemini.conman.org? 
>  >page.out
> 
> I get the expected index page from gemini.conman.org printed into a file.
> 
> However if i try the same with
> 
> echo -e ?gemini://gemini.circumlunar.space\r\n? | ncat ?ssl 
> ?gemini.circumlunar.space? ?>page.out
> 
> I get a 31 redirect. If i try that redirect address which is the same 
> but with a / on the end of the url then the requests fails Where in 
> would expect the gemini.circumlunar.space home page to be output to a file.
> 
> I feel like there is something obvious I am missing.
> 
> Anyone done this and know whats wrong?

echo -e "gemini://gemini.circumlunar.space/\r\n" | ncat --ssl 
"gemini.circumlunar.space" 1965  >page.out
works here, just added the slash and the port.

From henderson.j at protonmail.com  Tue Sep 22 19:47:03 2020
From: henderson.j at protonmail.com (James Henderson)
Date: Tue, 22 Sep 2020 18:47:03 +0000
Subject: Genini requests with ncat
In-Reply-To: <723f24b9-b988-a850-4079-5cdbd39e5453@typed-hole.org>
References: <i635v_2YJ3FgPKeqyJUB5XWa9uBLJ3K20m2Tv-fATFwb9zPCqbQj2JGMZzk7yInBP2Oz8T1T_dbTgjkYZFwSclHvIuOYyfdO48LM8sr6Puk=@protonmail.com>
 <723f24b9-b988-a850-4079-5cdbd39e5453@typed-hole.org>
Message-ID: <1sRFt5B0es2XvX9aACukRujbuschab7DZy4Ss2_R9qTir7aRQix54BEB_9NiGLs5vTOqetOFGGS-x9LtKtM3Upr-Cf-eAWOet7SSZF-Kftw=@protonmail.com>

Aha I see what the problem was!

As it happened I had the port in the command but just neglected it in the message, my bad.

The fail was caused by putting the / on the end of the url being passed to ncat. With the / on the end of that the lookup fails it appears. Seeing your working command made it obvious.

Thanks.

On Tue, Sep 22, 2020 at 16:30, Julien Blanchard <julien at typed-hole.org> wrote:

> On 22/09/2020 17:18, James Henderson wrote:
>> Hi there,
>>
>> I am trying to make gemini requests with ncat and have hit a bit of a
>> stumbling block that I am not sure how to solve so was wondering if
>> anyone here knew what was going on.
>>
>> If i make a request as such:
>>
>> echo -e ?gemini://gemini.conman.org\r\n? | ncat ?ssl ?gemini.conman.org?
>> >page.out
>>
>> I get the expected index page from gemini.conman.org printed into a file.
>>
>> However if i try the same with
>>
>> echo -e ?gemini://gemini.circumlunar.space\r\n? | ncat ?ssl
>> ?gemini.circumlunar.space? >page.out
>>
>> I get a 31 redirect. If i try that redirect address which is the same
>> but with a / on the end of the url then the requests fails Where in
>> would expect the gemini.circumlunar.space home page to be output to a file.
>>
>> I feel like there is something obvious I am missing.
>>
>> Anyone done this and know whats wrong?
>
> echo -e "gemini://gemini.circumlunar.space/\r\n" | ncat --ssl
> "gemini.circumlunar.space" 1965 >page.out
> works here, just added the slash and the port.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200922/c4d07bc6/attachment.htm>

From icefox at dreamquest.io  Tue Sep 22 23:40:46 2020
From: icefox at dreamquest.io (Simon Heath)
Date: Tue, 22 Sep 2020 18:40:46 -0400
Subject: [ANN] Scalar, an experiment for a minimalist chat protocol inspired
 by Gemini
Message-ID: <fcec01c08b2a5cd0fa2dc4024d83c6858249746c.camel@dreamquest.io>

Hi, all.  Pardon me if this is a little off-topic, it was suggested I
share this here.  I got annoyed at Matrix's complexity and IRC's
idiosyncracies, and said "I wish there were something like Gemini for
chat protocols".  So I decided to take a weekend and try to make
something like that, and after going over my time budget by a factor of
eight or so I ended up with something I call Scalar: 
https://sr.ht/~icefox/scalar/

It's very WIP still, but there's a minimum viable product specification
and implementation, with much more emphasis on "minimum" than "viable".
However, it's proof that the idea works, and carrying on the design of
the protocol is pretty straightforward. I can't *quite* bring myself to
design something as hardcore minimalist as Gemini, but I still hope it
meets Gemini's design criteria.  No idea if I will keep working on it
in the immediate future, but maybe it will inspire interesting
discussion.

Thanks a lot,
Simon


From ranfdev at gmail.com  Tue Sep 22 23:51:41 2020
From: ranfdev at gmail.com (Ranf Dev)
Date: Wed, 23 Sep 2020 00:51:41 +0200
Subject: Fwd: [ANN] New gtk client, with colors
In-Reply-To: <CAMXq4zrQO_BhgFwMsxy_jAvSTw-i_Evp++o18PqRx0LDwf4UVA@mail.gmail.com>
References: <CAMXq4zrQO_BhgFwMsxy_jAvSTw-i_Evp++o18PqRx0LDwf4UVA@mail.gmail.com>
Message-ID: <CAMXq4zrLm=Rv=YfT-DyZH+ioez0Ci1dWvmHaT2CBWAZNP1JfjA@mail.gmail.com>

Excerpt from the file README.gemini:

# About geopard
Geopard is a gtk3 gemini client

## Some notable features
- Colors!
  The browser will have a different color for each domain you visit.

- Fast (async core).
  Streams content by default. That means you can open pages even when you have
  connection speeds of Kb/s.

- Can download binary files.
  The download will start as soon as you open the corresponding link.
  You can always cancel it by opening another page.

- It works. Until I find another bug


At the moment, it must be compiled from source.

More info here https://ranfdev.com/projects/Geopard/ and here
https://github.com/ranfdev/Geopard

From sean at conman.org  Wed Sep 23 00:54:35 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 22 Sep 2020 19:54:35 -0400
Subject: [ANN] Scalar,
 an experiment for a minimalist chat protocol inspired by Gemini
In-Reply-To: <fcec01c08b2a5cd0fa2dc4024d83c6858249746c.camel@dreamquest.io>
References: <fcec01c08b2a5cd0fa2dc4024d83c6858249746c.camel@dreamquest.io>
Message-ID: <20200922235435.GA5996@brevard.conman.org>

It was thus said that the Great Simon Heath once stated:
> Hi, all.  Pardon me if this is a little off-topic, it was suggested I
> share this here.

  A bit off topic, but I don't mind.  I can't answer for others though.  

> I got annoyed at Matrix's complexity and IRC's
> idiosyncracies, and said "I wish there were something like Gemini for
> chat protocols". ...
> I ended up with something I call Scalar: 
> https://sr.ht/~icefox/scalar/
> 
> It's very WIP still, but there's a minimum viable product specification
> and implementation, with much more emphasis on "minimum" than "viable".

  Very minimum, and it doesn't even both with DNS SRV records.  The use of
CBOR is neat (I think it's underrated personally) but you seem to be having
second thoughts about it:

	 One of the annoying things about CBOR is the variable-length
	encoding means it's hard to know what the heck you're doing with
	this until you've actually encoded your message.

  I don't understand what you complaining about here.  Is it the fact you
don't know how much space to use when encoding?  When decoding?  How do
decode in a language like Rust of C that make it difficult to deal with
dynamic data?

	Blob?: Now that I think of it, not sure there's anything terribly
	wrong with sticking small binary data in a message or such? CBOR can
	distinguish the two, though it's a bit of a pain. Consider it.

  Actually, that's one of the easier things to deal with because TEXT is
distinct from BIN in CBOR.  

    /// ALSO TODO: It might be nice to use serde's "internally tagged" format, for brevity, but
    /// that messes up with `cbor_serde`'s packed format, probably because serde's tags want to be
    /// strings and cb's packed format wants them to be integers.  We may just be hitting the
    /// limits of serde, cbor, or both.  Keep thinking about it!

  CBOR tags are integers, but they are semantic tags, not name tags. 
They're there to say "the following string is to be used as a timestamp in
RFC-3339 format" or "the following binary string is a positive big integer". 
I get the feeling you think tags are supposed to be like field names.

> However, it's proof that the idea works, and carrying on the design of
> the protocol is pretty straightforward. I can't *quite* bring myself to
> design something as hardcore minimalist as Gemini, 

  Gemini is basically HTTP/0.9 with 2 digit status codes.  Hardcore
minimalist is Gopher, which doesn't support MIME types, nor status codes.  A
hardcore, minimalist chat protocol would be "one server, one 'room'
everybody chats in."  I've done that in 100 lines of Lua.

> but I still hope it
> meets Gemini's design criteria.  No idea if I will keep working on it
> in the immediate future, but maybe it will inspire interesting
> discussion.

  Perhaps.  But as it stands now, there's not enough to even make a
"proof-of-concept".  Well, maybe, if one just goes ahead to design the
protocol themselves.

  Another comment I have is the use of DNS SRV records.  It's a great idea
(I like it personally) but it makes it just that much harder to use as a
protocol.  Setting up a Scalar server also means updating DNS records.  As
someone who runs their own DNS infrastructure [1] it's easy for me to add
SRV records.  I don't know about that in general (someone else might have to
speak up about that).

  Second, using SRV records in a client isn't easy either.  There's a
(POSIX) standard function getaddrinfo() for returning an A or AAAA record
(IP address), but not one for SRV records.  I think libc on Linux contains
functions one could use to get SRV records, but I don't know off the top of
my head what they might be.  I know there are libraries out there that can
deal with SRV records, but most are crap [2].

  Gemini's only real external requirement is a library for TLS.  So far,
Scalar requires CBOR and DNS, so it might not be so simple.

  -spc

[1]	Yes, I do.  I even had a hand in setting up my server provider's DNS
	infrastructure.  

[2]	I'm biased here.  I looked into half a dozen DNS libraries and found
	them all to be pure crap.  That's why I ended up writing my own [3],
	like I do [4].

[3]	https://github.com/spc476/SPCDNS

[4]	I even have a CBOR library:
	https://github.com/spc476/CBOR

From sandra.snan at idiomdrottning.org  Wed Sep 23 06:33:42 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Wed, 23 Sep 2020 07:33:42 +0200
Subject: Should Gemini clients alert users upon redirect?
In-Reply-To: <87imcba0zq.fsf@idiomdrottning.org>
References: <7fb60909-0699-4eec-9d20-9755f2298364@www.fastmail.com>
 <87pn6ja2wr.fsf@idiomdrottning.org>
 <0e237d77-bdd4-4fcd-ad35-0595adfc96bb@www.fastmail.com>
 <87imcba0zq.fsf@idiomdrottning.org>
Message-ID: <871rit9hvt.fsf@idiomdrottning.org>

I forgot to add that the reason I switched to foo/index.gmi from foo.gmi
is because I put .molly files in the foo that sets the lang (iff the
lang is not the site default).


From tcb913 at gmail.com  Wed Sep 23 13:40:08 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Wed, 23 Sep 2020 08:40:08 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <C5TC8J7500SI.174UXR7ASQIZ9@homura>
References: <C5TC8J7500SI.174UXR7ASQIZ9@homura>
Message-ID: <a342761a-d1c7-d322-2421-fb8d58030726@gmail.com>

OK.

The include files openssl/bio.h, openssl/err.h, and openssl/ssl.h are 
there. Which openssl library does your Makefile want? (It's not clear, 
but configure does not throw any errors.

tb


On 09/21/2020 04:43 PM, Drew DeVault wrote:
> gnutls-openssl is not openssl.


From sir at cmpwn.com  Wed Sep 23 17:40:45 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 23 Sep 2020 12:40:45 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <a342761a-d1c7-d322-2421-fb8d58030726@gmail.com>
Message-ID: <C5UWBWLYQM6W.2K8RH60BJP505@homura>

On Wed Sep 23, 2020 at 8:40 AM EDT, Terry Brennan wrote:
> Which openssl library does your Makefile want? (It's not clear, but
> configure does not throw any errors.

It wants OpenSSL. This should be evident by the fact that it calls for
OpenSSL, and not for any other library.

https://www.openssl.org

From sir at cmpwn.com  Wed Sep 23 19:49:05 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 23 Sep 2020 14:49:05 -0400
Subject: TOFU recommendations for Gemini clients
Message-ID: <C5UZ25UIIHW0.3WLZRYBKKHG4@homura>

I wrote up my client's TOFU procedure into an article here:

https://drewdevault.com/2020/09/21/Gemini-TOFU.html

I hope that this is useful to other client authors.

From jmcbray at carcosa.net  Thu Sep 24 15:01:13 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 24 Sep 2020 10:01:13 -0400
Subject: [ANN] Scalar, an experiment for a minimalist chat protocol
 inspired by Gemini
In-Reply-To: <fcec01c08b2a5cd0fa2dc4024d83c6858249746c.camel@dreamquest.io>
 (Simon Heath's message of "Tue, 22 Sep 2020 18:40:46 -0400")
References: <fcec01c08b2a5cd0fa2dc4024d83c6858249746c.camel@dreamquest.io>
Message-ID: <87wo0j1dg6.fsf@dorothy.carcosa.net>

Simon Heath <icefox at dreamquest.io> writes:

> Hi, all.  Pardon me if this is a little off-topic, it was suggested I
> share this here.  I got annoyed at Matrix's complexity and IRC's
> idiosyncracies, and said "I wish there were something like Gemini for
> chat protocols".

So, I'm pondering this, and wondering ? is IRC then the Gopher of chat
protocols? Could you give a quick summary of what your proposal offers
beyond IRC?

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Thu Sep 24 15:34:30 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 24 Sep 2020 10:34:30 -0400
Subject: Fwd: [ANN] New gtk client, with colors
In-Reply-To: <CAMXq4zrLm=Rv=YfT-DyZH+ioez0Ci1dWvmHaT2CBWAZNP1JfjA@mail.gmail.com>
 (Ranf Dev's message of "Wed, 23 Sep 2020 00:51:41 +0200")
References: <CAMXq4zrQO_BhgFwMsxy_jAvSTw-i_Evp++o18PqRx0LDwf4UVA@mail.gmail.com>
 <CAMXq4zrLm=Rv=YfT-DyZH+ioez0Ci1dWvmHaT2CBWAZNP1JfjA@mail.gmail.com>
Message-ID: <87sgb71bwp.fsf@dorothy.carcosa.net>

Ranf Dev <ranfdev at gmail.com> writes:

> At the moment, it must be compiled from source.
>
> More info here https://ranfdev.com/projects/Geopard/ and here
> https://github.com/ranfdev/Geopard

It looks very nice! A bit basic, maybe, but very, very fast. Build
process was very straightforward. I wanted to try downloading from
konpeito.media with it, but they seem to be down.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From ranfdev at gmail.com  Thu Sep 24 17:51:32 2020
From: ranfdev at gmail.com (Lorenzo Miglietta)
Date: Thu, 24 Sep 2020 18:51:32 +0200
Subject: Fwd: [ANN] New gtk client, with colors
In-Reply-To: <87sgb71bwp.fsf@dorothy.carcosa.net>
References: <CAMXq4zrQO_BhgFwMsxy_jAvSTw-i_Evp++o18PqRx0LDwf4UVA@mail.gmail.com>
 <CAMXq4zrLm=Rv=YfT-DyZH+ioez0Ci1dWvmHaT2CBWAZNP1JfjA@mail.gmail.com>
 <87sgb71bwp.fsf@dorothy.carcosa.net>
Message-ID: <d97fb680af5362ec7a9e2e703fc221b5e0f91090.camel@gmail.com>

> It looks very nice! A bit basic, maybe, but very, very fast. Build
> process was very straightforward.

I'm glad you like it! Feel free to send an email here or directly to me
if you find something breaking or if you think the client is missing a
basic feature.
Meanwhile, I'll try to implement TOFU Tls, so that connections are more
secure.


From me at ecmelberk.com  Thu Sep 24 18:31:08 2020
From: me at ecmelberk.com (Ecmel B. Canlier)
Date: Thu, 24 Sep 2020 20:31:08 +0300 (TRT)
Subject: [ANN] New gtk client, with colors
Message-ID: <322649777.64897.1600968668654@office.mailbox.org>

Tested it for a little bit and it seems really nice! The "user
experience" is definitely very close to what I imagined for Moonlander.

> The browser will have a different color for each domain you visit.

On dark GTK themes (specifically Arc-Dark in my case), the top UI color
on some pages look _very_ light and makes the important parts of the UI
hard to see?.

One suggestion would be to add a "dark mode" switch that tones down the
brightness of the generated colors. You might also want to add an option
to turn the coloring off entirely for people who want all their programs
to share the same look.

[1]: https://ebc.li/d665.png

> Streams content by default. That means you can open pages even when
> you have connection speeds of Kb/s.

My slow internet will thank you for this one :)
 
> It works. Until I find another bug

Here's one: Some quote lines are not parsed correctly?.

[2]: https://ebc.li/oyew.png
     The page in question: gemini://ebc.li/posts/alt-text-proposal.gmi



Lastly, if you want more stuff to do: a way to configure how the pages
are rendered would be a nice addition. As currently the text is too
small, and the lines go for too long without wrapping. Being able to set
the maximum line width (bonus points for centering), and font
configuration (preferably different for each line type) would be pretty
neat. Color customization would be neat too, but that's not as
important as being able to read things.

I might take a shot at implementing the customization stuff, but don't
count on me :p

-- 
Have a nice (day|night|week(end)?)
~ Ecmel B. Canl?er ~

From kevin at susa.net  Thu Sep 24 21:22:56 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Thu, 24 Sep 2020 21:22:56 +0100
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <3004de46-c11a-c341-eb29-e39f3d387c13@gmail.com>
References: <C5TAMYA5U7N3.215NYC5PC0X95@homura>
 <3004de46-c11a-c341-eb29-e39f3d387c13@gmail.com>
Message-ID: <CAPk6LxSQuHRhrkZpvuxMQgfQ6qAXdS7xuq0tSmSiJ9GL-NUGNQ@mail.gmail.com>

Hi Terry,

As has been alluded to elsewhere, you're not actually using OpenSSL, you
have GnuTLS with an OpenSSL compatibility layer (that's not fully
compatible, as you've seen).

On Debian, I have packages 'openssl' and 'libssl-dev' installed, you may
want to try installing these and then recompile gmni. I'm assuming OpenSSL
can co-exist with GnuTLS, but I haven't tried.

Kevin


On Mon, 21 Sep 2020 at 21:42, Terry Brennan <tcb913 at gmail.com> wrote:

> No, definitely using openssl. Lots of library stuff, and header files.
>
> BTW, error messages did not report missing header files.
>
> My openssl lib is libgnutils-openssl.so.27.0.2, if this helps.
>
> tb
>
>
> On 09/21/2020 03:28 PM, Drew DeVault wrote:
> > That's quite bizzare. Are you perhaps using a system with LibreSSL
> > instead of OpenSSL?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200924/2f346107/attachment.htm>

From ranfdev at gmail.com  Thu Sep 24 21:28:29 2020
From: ranfdev at gmail.com (Lorenzo Miglietta)
Date: Thu, 24 Sep 2020 22:28:29 +0200
Subject: [ANN] New gtk client, with colors
In-Reply-To: <322649777.64897.1600968668654@office.mailbox.org>
References: <322649777.64897.1600968668654@office.mailbox.org>
Message-ID: <a51fef2741665d1cef3383f26ab3324c3e266e87.camel@gmail.com>

> Tested it for a little bit and it seems really nice! The "user
> experience" is definitely very close to what I imagined for
> Moonlander.

Thank you, that means a lot to me :-)

> On dark GTK themes (specifically Arc-Dark in my case), the top UI
> color
> on some pages look _very_ light and makes the important parts of the
> UI
> hard to see?.

I'll add an option to disable colors for now, because that's easier to
implement and it's needed anyway. After that, I'll look into dark
themes/mode.

> Here's one: Some quote lines are not parsed correctly?.
> 
> [2]: https://ebc.li/oyew.png
>      The page in question: gemini://ebc.li/posts/alt-text-
> proposal.gmi

Sorry, I don't understand... what's the bug?

I don't remove '>' from quotes, so those lines start with that char.
Some quoted lines _dont't_ have '>', because they are not really new
lines. When a line is longer than the screen, it gets wrapped by the
program, but the program doesn't add '>'.

I don't think that's a bug, but if that creates confusion, I'm happy
to remove the first '>' char from quotes, so that every line is equal,
even when wrapped.

> Lastly, if you want more stuff to do [...]
I'll add a configuration file to disable colors, change fonts, etc...


From adrianhesketh at hushmail.com  Thu Sep 24 21:29:28 2020
From: adrianhesketh at hushmail.com (Adrian Hesketh)
Date: Thu, 24 Sep 2020 21:29:28 +0100
Subject: ANN: A new Gemini browser written in Go
Message-ID: <baa07718eba22908405ec974733b3391@smtp.hushmail.com>

I wrote a new Gemini browser.

It supports client certificates, input, TOFU certificates, non UTF-8
encodings, binary downloads, non Gemini links, has bookmarks, history
etc. with vim-style and cursor-y shortcuts.

I run it on my Mac, Raspberry Pi Zero W, Raspberry Pi 4 (Ubuntu).

Code and binaries is over at https://github.com/a-h/min if you want to
give it a go.

Thanks!


From me at ecmelberk.com  Thu Sep 24 21:40:49 2020
From: me at ecmelberk.com (Ecmel B. Canlier)
Date: Thu, 24 Sep 2020 23:40:49 +0300 (TRT)
Subject: [ANN] New gtk client, with colors
Message-ID: <230057340.65862.1600980049934@office.mailbox.org>

> Sorry, I don't understand... what's the bug?
> 
> I don't remove '>' from quotes, so those lines start with that char.
> Some quoted lines _dont't_ have '>', because they are not really new
> lines. When a line is longer than the screen, it gets wrapped by the
> program, but the program doesn't add '>'.
> 
> I don't think that's a bug, but if that creates confusion, I'm happy
> to remove the first '>' char from quotes, so that every line is equal,
> even when wrapped.

Ah wait, just checking again, the other pages that I thought rendered
correctly just didn't have any quote lines. I don't think this is an
issue, sorry!

-- 
Have a nice (day|night|week(end)?)
~ Ecmel B. Canl?er ~

From tcb913 at gmail.com  Fri Sep 25 16:27:53 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Fri, 25 Sep 2020 11:27:53 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <CAPk6LxSQuHRhrkZpvuxMQgfQ6qAXdS7xuq0tSmSiJ9GL-NUGNQ@mail.gmail.com>
References: <C5TAMYA5U7N3.215NYC5PC0X95@homura>
 <3004de46-c11a-c341-eb29-e39f3d387c13@gmail.com>
 <CAPk6LxSQuHRhrkZpvuxMQgfQ6qAXdS7xuq0tSmSiJ9GL-NUGNQ@mail.gmail.com>
Message-ID: <57082b29-bf86-b487-e7d1-b9e45fcb9a01@gmail.com>

Thanks, I'll try that.

tb


On 09/24/2020 04:22 PM, Kevin Sangeelee wrote:
> Hi Terry,
>
> As has been alluded to elsewhere, you're not actually using OpenSSL, 
> you have GnuTLS with an OpenSSL compatibility layer (that's not fully 
> compatible, as you've seen).
>
> On Debian, I have packages 'openssl' and 'libssl-dev' installed, you 
> may want to try installing these and then recompile gmni. I'm assuming 
> OpenSSL can co-exist with GnuTLS, but I haven't tried.
>
> Kevin
>
>
> On Mon, 21 Sep 2020 at 21:42, Terry Brennan <tcb913 at gmail.com 
> <mailto:tcb913 at gmail.com>> wrote:
>
>     No, definitely using openssl. Lots of library stuff, and header files.
>
>     BTW, error messages did not report missing header files.
>
>     My openssl lib is libgnutils-openssl.so.27.0.2, if this helps.
>
>     tb
>
>
>     On 09/21/2020 03:28 PM, Drew DeVault wrote:
>     > That's quite bizzare. Are you perhaps using a system with LibreSSL
>     > instead of OpenSSL?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200925/a88d3b56/attachment.htm>

From brad at w8rbt.org  Fri Sep 25 13:48:06 2020
From: brad at w8rbt.org (rbt)
Date: Fri, 25 Sep 2020 12:48:06 +0000
Subject: TOFU recommendations for Gemini clients
In-Reply-To: <C5UZ25UIIHW0.3WLZRYBKKHG4@homura>
References: <C5UZ25UIIHW0.3WLZRYBKKHG4@homura>
Message-ID: <20200925124806.GA68265@beagle.local>

On Wed, Sep 23, 2020 at 02:49:05PM -0400, Drew DeVault wrote:
> I wrote up my client's TOFU procedure into an article here:
> 
> https://drewdevault.com/2020/09/21/Gemini-TOFU.html
> 
> I hope that this is useful to other client authors.

Thank you Drew, this is very helpful. I keep trying to find time to work on a Gemini client and when I do, having well thought out TOFU notes will be great.

Brad

From tcb913 at gmail.com  Sat Sep 26 19:14:57 2020
From: tcb913 at gmail.com (Terry Brennan)
Date: Sat, 26 Sep 2020 14:14:57 -0400
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <CAPk6LxSQuHRhrkZpvuxMQgfQ6qAXdS7xuq0tSmSiJ9GL-NUGNQ@mail.gmail.com>
References: <C5TAMYA5U7N3.215NYC5PC0X95@homura>
 <3004de46-c11a-c341-eb29-e39f3d387c13@gmail.com>
 <CAPk6LxSQuHRhrkZpvuxMQgfQ6qAXdS7xuq0tSmSiJ9GL-NUGNQ@mail.gmail.com>
Message-ID: <ca5b0ad7-bfd9-c3ee-f81c-bedddd2332b1@gmail.com>

Kevin, thanks. I downloaded the ssl package from openssl.org, compiled 
and installed it, and the compile problems disappeared.

Interesting that Slackware does not offer openssl or libressl.

Terry Brennan


On 09/24/2020 04:22 PM, Kevin Sangeelee wrote:
> Hi Terry,
>
> As has been alluded to elsewhere, you're not actually using OpenSSL, 
> you have GnuTLS with an OpenSSL compatibility layer (that's not fully 
> compatible, as you've seen).
>
> On Debian, I have packages 'openssl' and 'libssl-dev' installed, you 
> may want to try installing these and then recompile gmni. I'm assuming 
> OpenSSL can co-exist with GnuTLS, but I haven't tried.
>
> Kevin
>
>
> On Mon, 21 Sep 2020 at 21:42, Terry Brennan <tcb913 at gmail.com 
> <mailto:tcb913 at gmail.com>> wrote:
>
>     No, definitely using openssl. Lots of library stuff, and header files.
>
>     BTW, error messages did not report missing header files.
>
>     My openssl lib is libgnutils-openssl.so.27.0.2, if this helps.
>
>     tb
>
>
>     On 09/21/2020 03:28 PM, Drew DeVault wrote:
>     > That's quite bizzare. Are you perhaps using a system with LibreSSL
>     > instead of OpenSSL?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200926/a4de7db4/attachment.htm>

From kevin at susa.net  Sat Sep 26 20:18:09 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Sat, 26 Sep 2020 20:18:09 +0100
Subject: Announcing gmni, a line-mode gemini browser and curl-esque
 utility program
In-Reply-To: <ca5b0ad7-bfd9-c3ee-f81c-bedddd2332b1@gmail.com>
References: <C5TAMYA5U7N3.215NYC5PC0X95@homura>
 <3004de46-c11a-c341-eb29-e39f3d387c13@gmail.com>
 <CAPk6LxSQuHRhrkZpvuxMQgfQ6qAXdS7xuq0tSmSiJ9GL-NUGNQ@mail.gmail.com>
 <ca5b0ad7-bfd9-c3ee-f81c-bedddd2332b1@gmail.com>
Message-ID: <CAPk6LxQQ6EdLw7S2Oqfocx9AdUSxa5XhzuP+SB85A6y3dWWjyA@mail.gmail.com>

Glad you got it compiled (though it was Drew who pointed you there), the
whole SSL/TLS thing is a bit of a complicated mess on lots of levels. It's
a slog to grok (I'm not sure that's even achievable!).

Kevin

On Sat, 26 Sep 2020 at 19:15, Terry Brennan <tcb913 at gmail.com> wrote:

> Kevin, thanks. I downloaded the ssl package from openssl.org, compiled
> and installed it, and the compile problems disappeared.
>
> Interesting that Slackware does not offer openssl or libressl.
>
> Terry Brennan
>
> On 09/24/2020 04:22 PM, Kevin Sangeelee wrote:
>
> Hi Terry,
>
> As has been alluded to elsewhere, you're not actually using OpenSSL, you
> have GnuTLS with an OpenSSL compatibility layer (that's not fully
> compatible, as you've seen).
>
> On Debian, I have packages 'openssl' and 'libssl-dev' installed, you may
> want to try installing these and then recompile gmni. I'm assuming OpenSSL
> can co-exist with GnuTLS, but I haven't tried.
>
> Kevin
>
>
> On Mon, 21 Sep 2020 at 21:42, Terry Brennan <tcb913 at gmail.com> wrote:
>
>> No, definitely using openssl. Lots of library stuff, and header files.
>>
>> BTW, error messages did not report missing header files.
>>
>> My openssl lib is libgnutils-openssl.so.27.0.2, if this helps.
>>
>> tb
>>
>>
>> On 09/21/2020 03:28 PM, Drew DeVault wrote:
>> > That's quite bizzare. Are you perhaps using a system with LibreSSL
>> > instead of OpenSSL?
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200926/8bac6322/attachment.htm>

From sir at cmpwn.com  Sat Sep 26 23:21:57 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sat, 26 Sep 2020 18:21:57 -0400
Subject: [ANN] gmnisrv: a Gemini server for POSIX systems
Message-ID: <C5XNGS9GRUYA.1AXE5TFXRZ0HT@homura>

As promised, I have implemented a Gemini server in C11 for POSIX
systems: gmnisrv.

gemini://drewdevault.com/gmnisrv.gmi

gmnisrv is a high-performance server which requires next to no
configuration. You just write a file like this:

	listen=0.0.0.0:1965 [::]:1965

	[:tls]
	store=/var/lib/gemini/certs
	organization=gmnisrv user

	[example.org]
	root=/srv/gemini/example.org

	[example.com]
	root=/srv/gemini/example.com

Stick it in /etc/gmnisrv.ini, start the daemon, and you're done. It
automatically generates and rotates certificates for you.

The only dependencies are a C11 compiler, a POSIX-like system, and
OpenSSL*. It clocks in at about 3,000 lines of code. In the future, I
would like to add support for some simple URL rewrites and reverse proxy
support.

* I actually mean OpenSSL when I say it, not LibreSSL or GNUTLS or
  anything else.

Development info can be found here:

https://sr.ht/~sircmpwn/gmni/

Enjoy!

From meff at meff.me  Sun Sep 27 01:58:10 2020
From: meff at meff.me (Meff)
Date: Sat, 26 Sep 2020 17:58:10 -0700
Subject: [ANN] GemGoHaNe -- Gemini Gopher HackerNews Mirror
Message-ID: <873634ujbx.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>


Hey all,

I've made a HackerNews mirror for Gemini. You can access the mirror at
gemini://dioskouroi.xyz. I have a post on my Gemlog going into some
details at gemini://acidic.website/musings/gemgohane-release.gmi .

Thanks,
meff

From luke.emmet at gmail.com  Sun Sep 27 09:18:01 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sun, 27 Sep 2020 09:18:01 +0100
Subject: [ANN] GemGoHaNe -- Gemini Gopher HackerNews Mirror
In-Reply-To: <873634ujbx.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
References: <873634ujbx.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <00A7E2A1-07A7-4095-A3CF-49C109561970@gmail.com>



> On 27 Sep 2020, at 01:58, Meff <meff at meff.me> wrote:
> 
> 
> Hey all,
> 
> I've made a HackerNews mirror for Gemini. You can access the mirror at
> gemini://dioskouroi.xyz. I have a post on my Gemlog going into some
> details at gemini://acidic.website/musings/gemgohane-release.gmi

Thanks for creating that.

A minor comment - it seems that some of the heading 3s in these comments section are missing a space.

###content

Should be

### content

Best wishes

Luke

From persist at localhost  Sun Sep 27 13:48:14 2020
From: persist at localhost (persist at localhost)
Date: Sun, 27 Sep 2020 12:48:14 +0000
Subject: Ditch URL. Uniform Resource Names ftw!
Message-ID: <mailman.0.1601211989.473.gemini@lists.orbitalfox.eu>

I'm searching for the like-minded people that agree that URL syntax for hyperlinks means desperately clinging to the mistakes of the past. It seems that in a world of rapidly expanding browser scope some fundamentals are set in stone even for known violators. And the current opposition seems to be all ...return to the Tim Berners-Lee era of the WWW. As if few to none want to go further than attempting a reaction to certain annoyances and privacy encroachments that the Web has, without considering the features the Web never realized.

Of course it's somewhat breaking away from a paradigm, but I strongly feel that consistent support for URNs in preference to URLs in electronic documents will further the reach of hypertext beyond the always online crowd, by introducing a layer of indirection that greatly simplifies eliminating single points of failure the URL-cross-referenced documents are infamous for, contributing to the perception that electronic resources must be transient.

And I'm not saying it's good to base on a legacy URN specification that obeys RFC3986 either, as evidenced by the mess that magnet: URIs present because of ugly percent encoding.

From lel at envs.net  Sun Sep 27 16:24:18 2020
From: lel at envs.net (lel)
Date: Sun, 27 Sep 2020 11:24:18 -0400
Subject: [ANN] GemGoHaNe -- Gemini Gopher HackerNews Mirror
In-Reply-To: <00A7E2A1-07A7-4095-A3CF-49C109561970@gmail.com>
References: <873634ujbx.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
 <00A7E2A1-07A7-4095-A3CF-49C109561970@gmail.com>
Message-ID: <20200927152418.GA4572@commie.my.domain>

On Sun, Sep 27, 2020 at 09:18:01AM +0100, Luke Emmet wrote:
> A minor comment - it seems that some of the heading 3s in these comments section are missing a space.
> 
> ###content
> 
> Should be
> 
> ### content

The whitespace is actually optional in the spec! This came about
because solderpunk's goal was to create a spec for text/gemini
where line type can be inferred from the first three
characters of a line.

~lel

From luke.emmet at gmail.com  Sun Sep 27 16:31:22 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Sun, 27 Sep 2020 16:31:22 +0100
Subject: [ANN] GemGoHaNe -- Gemini Gopher HackerNews Mirror
In-Reply-To: <20200927152418.GA4572@commie.my.domain>
References: <873634ujbx.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
 <00A7E2A1-07A7-4095-A3CF-49C109561970@gmail.com>
 <20200927152418.GA4572@commie.my.domain>
Message-ID: <3C406C74-A8E9-4B3F-A64D-77BAC34BDCF0@gmail.com>



> On 27 Sep 2020, at 16:24, lel <lel at envs.net> wrote:
> 
>> On Sun, Sep 27, 2020 at 09:18:01AM +0100, Luke Emmet wrote:
>> A minor comment - it seems that some of the heading 3s in these comments section are missing a space.
>> 
>> ###content
>> 
>> Should be
>> 
>> ### content
> 
> The whitespace is actually optional in the spec! This came about
> because solderpunk's goal was to create a spec for text/gemini
> where line type can be inferred from the first three
> characters of a line.

Well, if that's what the spec says....

But it is stylistically inconsistent given that all other headings and visible line types need a space.

Luke

From cowan at ccil.org  Sun Sep 27 20:05:08 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Sep 2020 15:05:08 -0400
Subject: Ditch URL. Uniform Resource Names ftw!
In-Reply-To: <20200927130630.C427AAA15D8@orbitalfox.eu>
References: <20200927130630.C427AAA15D8@orbitalfox.eu>
Message-ID: <CAD2gp_SOYo6gknbrdrAAXkWXEoV3o0X4D+aBWf0gvLv=fnJDMw@mail.gmail.com>

On Sun, Sep 27, 2020 at 9:06 AM <persist at localhost> (really??) wrote:

Of course it's somewhat breaking away from a paradigm, but I strongly feel
> that consistent support for URNs in preference to URLs in electronic
> documents will further the reach of hypertext beyond the always online
> crowd, by introducing a layer of indirection that greatly simplifies
> eliminating single points of failure the URL-cross-referenced documents are
> infamous for, contributing to the perception that electronic resources must
> be transient.
>

In practice, given the existence of doi.org and similar systems, as well as
URL shorteners (I often use them to generate de facto URNs), and the fact
that HTTP and Gemini both allow protocol-level redirection, I think what we
have is as good as it's going to get.  DNS is the most successful and
widespread federated database system in the world, and attempting to
replace it is likely to be a pipe dream.  Link rot is a thing, but so is
database rot and protocol rot.  As the French proverb has it, "tout passe,
tout lasse, tout casse et tout se remplace" (Everything passes, everything
grows weary, everything breaks, and everything gets replaced).

And I say this as a person who has dealt with SGML/XML public ids and URNs,
and even wrote RFC 3305 to define a mapping from the former to the latter.
It's a dead end.  Of course, I'm certainly open to the idea that my
conclusions were premature, but the burden of persuasion is on you.  I know
the merits of stable names, you needn't convince me of that.  You need at
least a sketch of a system that is clearly superior to URLs as we know them
today.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Your worships will perhaps be thinking that it is an easy thing
to blow up a dog? [Or] to write a book?
    --Don Quixote, Introduction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200927/533f40d4/attachment.htm>

From kevin at susa.net  Sun Sep 27 20:56:34 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Sun, 27 Sep 2020 20:56:34 +0100
Subject: [ANN] gmnisrv: a Gemini server for POSIX systems
In-Reply-To: <C5XNGS9GRUYA.1AXE5TFXRZ0HT@homura>
References: <C5XNGS9GRUYA.1AXE5TFXRZ0HT@homura>
Message-ID: <CAPk6LxT779Z9M31djAjdrKk-OoFfaKyH9bogvh=AyNoQM81GDw@mail.gmail.com>

Thanks again! This tiny server has around a 3MB resident footprint.

I think having a server capable of managing its own certificates is a great
idea - there have been plenty of issues where a certificate anomaly turned
out to be the problem.

One minor issue - I don't think that C11, as per the readme, supports the
single argument version of static_assert, as used in include/server.h. The
following is suggested: -

8< ----------
diff --git a/include/server.h b/include/server.h
index c6f4a38..c4ea470 100644
--- a/include/server.h
+++ b/include/server.h
@@ -27,7 +27,7 @@ struct gmnisrv_client {
        BIO *bio, *sbio;

        char buf[4096];
-       static_assert(GEMINI_MAX_URL + 3 < 4096);
+       static_assert(GEMINI_MAX_URL + 3 < 4096, "GEMINI_MAX_URL is too
large");
        size_t bufix, bufln;

        enum response_state state;
8< ----------

Kevin




On Sat, 26 Sep 2020 at 23:36, Drew DeVault <sir at cmpwn.com> wrote:

> As promised, I have implemented a Gemini server in C11 for POSIX
> systems: gmnisrv.
>
> gemini://drewdevault.com/gmnisrv.gmi
>
> gmnisrv is a high-performance server which requires next to no
> configuration. You just write a file like this:
>
>         listen=0.0.0.0:1965 [::]:1965
>
>         [:tls]
>         store=/var/lib/gemini/certs
>         organization=gmnisrv user
>
>         [example.org]
>         root=/srv/gemini/example.org
>
>         [example.com]
>         root=/srv/gemini/example.com
>
> Stick it in /etc/gmnisrv.ini, start the daemon, and you're done. It
> automatically generates and rotates certificates for you.
>
> The only dependencies are a C11 compiler, a POSIX-like system, and
> OpenSSL*. It clocks in at about 3,000 lines of code. In the future, I
> would like to add support for some simple URL rewrites and reverse proxy
> support.
>
> * I actually mean OpenSSL when I say it, not LibreSSL or GNUTLS or
>   anything else.
>
> Development info can be found here:
>
> https://sr.ht/~sircmpwn/gmni/
>
> Enjoy!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200927/9fe94936/attachment.htm>

From meff at meff.me  Sun Sep 27 20:57:36 2020
From: meff at meff.me (Koushik Roy)
Date: Sun, 27 Sep 2020 12:57:36 -0700
Subject: [ANN] GemGoHaNe -- Gemini Gopher HackerNews Mirror
In-Reply-To: <3C406C74-A8E9-4B3F-A64D-77BAC34BDCF0@gmail.com>
References: <873634ujbx.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
 <00A7E2A1-07A7-4095-A3CF-49C109561970@gmail.com>
 <20200927152418.GA4572@commie.my.domain>
 <3C406C74-A8E9-4B3F-A64D-77BAC34BDCF0@gmail.com>
Message-ID: <87tuvjt2kv.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

Luke Emmet <luke.emmet at gmail.com> writes:

>> On 27 Sep 2020, at 16:24, lel <lel at envs.net> wrote:
>> 
>>> On Sun, Sep 27, 2020 at 09:18:01AM +0100, Luke Emmet wrote:
>>> A minor comment - it seems that some of the heading 3s in these comments section are missing a space.
>>> 
>>> ###content
>>> 
>>> Should be
>>> 
>>> ### content
>> 
>> The whitespace is actually optional in the spec! This came about
>> because solderpunk's goal was to create a spec for text/gemini
>> where line type can be inferred from the first three
>> characters of a line.
>
> Well, if that's what the spec says....
>
> But it is stylistically inconsistent given that all other headings and
> visible line types need a space.

For the most part, this is a bug on my part. I intended for there to be
a space after the heading. Thanks for bringing this to my attention,
I'll push a fix.

- meff

From sir at cmpwn.com  Sun Sep 27 20:57:25 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sun, 27 Sep 2020 15:57:25 -0400
Subject: [ANN] gmnisrv: a Gemini server for POSIX systems
In-Reply-To: <CAPk6LxT779Z9M31djAjdrKk-OoFfaKyH9bogvh=AyNoQM81GDw@mail.gmail.com>
Message-ID: <C5YF0NUYSEP9.30PAK135PB5SV@homura>

On Sun Sep 27, 2020 at 3:56 PM EDT, Kevin Sangeelee wrote:
> Thanks again! This tiny server has around a 3MB resident footprint.
>
> I think having a server capable of managing its own certificates is a
> great idea - there have been plenty of issues where a certificate
> anomaly turned out to be the problem.
>
> One minor issue - I don't think that C11, as per the readme, supports
> the single argument version of static_assert, as used in
> include/server.h. The following is suggested: -

Thanks for the head's up! Could you rephrase this in the form of a git
patch sent to ~sircmpwn/gmni-devel at lists.sr.ht? See
https://git-send-email.io

From sandra.snan at idiomdrottning.org  Sun Sep 27 22:45:03 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Sun, 27 Sep 2020 23:45:03 +0200
Subject: Ditch URL. Uniform Resource Names ftw!
In-Reply-To: <CAD2gp_SOYo6gknbrdrAAXkWXEoV3o0X4D+aBWf0gvLv=fnJDMw@mail.gmail.com>
References: <20200927130630.C427AAA15D8@orbitalfox.eu>
 <CAD2gp_SOYo6gknbrdrAAXkWXEoV3o0X4D+aBWf0gvLv=fnJDMw@mail.gmail.com>
Message-ID: <87zh5a51y8.fsf@idiomdrottning.org>

Agree with John.

All that is solid melts into air?

John Cowan <cowan at ccil.org> writes:

> On Sun, Sep 27, 2020 at 9:06 AM <persist at localhost> (really??) wrote:
>
> Of course it's somewhat breaking away from a paradigm, but I strongly feel
>> that consistent support for URNs in preference to URLs in electronic
>> documents will further the reach of hypertext beyond the always online
>> crowd, by introducing a layer of indirection that greatly simplifies
>> eliminating single points of failure the URL-cross-referenced documents are
>> infamous for, contributing to the perception that electronic resources must
>> be transient.
>>
>
> In practice, given the existence of doi.org and similar systems, as well as
> URL shorteners (I often use them to generate de facto URNs), and the fact
> that HTTP and Gemini both allow protocol-level redirection, I think what we
> have is as good as it's going to get.  DNS is the most successful and
> widespread federated database system in the world, and attempting to
> replace it is likely to be a pipe dream.  Link rot is a thing, but so is
> database rot and protocol rot.  As the French proverb has it, "tout passe,
> tout lasse, tout casse et tout se remplace" (Everything passes, everything
> grows weary, everything breaks, and everything gets replaced).
>
> And I say this as a person who has dealt with SGML/XML public ids and URNs,
> and even wrote RFC 3305 to define a mapping from the former to the latter.
> It's a dead end.  Of course, I'm certainly open to the idea that my
> conclusions were premature, but the burden of persuasion is on you.  I know
> the merits of stable names, you needn't convince me of that.  You need at
> least a sketch of a system that is clearly superior to URLs as we know them
> today.
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
> Your worships will perhaps be thinking that it is an easy thing
> to blow up a dog? [Or] to write a book?
>     --Don Quixote, Introduction

From cowan at ccil.org  Mon Sep 28 01:22:34 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Sep 2020 20:22:34 -0400
Subject: Dioscuri, another application layer protocol
Message-ID: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>

Dioscuri is a protocol intended to supplement Gemini for doing things like
uploading files, performing remote actions, and running an application
server.  It is the POST to Gemini's GET.  Dioscuri servers will run on a
different port altogether, so that they do not interfere with Gemini
servers.  Dioscuri, unlike Gemini, absolutely *requires* the use of client
certificates.

Great thanks to the members of irc://tilde.chat/gemini, especially lukee
and aravk.

The name "Dioscuri" is the Latinized spelling of the Greek name for the
Heavenly Twins, Castor and Pollux/Polydeukes, who were called Gemini in
Latin; the constellation is named after them.  I say dee-OH-skoo-ree, but
Greeks, classicists, and others should feel free to pronounce the name
their way.

=======

A Dioscuri request starts out with the client sending a single line,
<URL><SP><MEDIA-TYPE><CR><LF>.  This indicates that a body follows which
should be interpreted according to the media type.  For example, "gemini://
example.org/foo text/gemini\r\n" means that the Dioscuri server should do
something with the following body, which is of type text/gemini.  Exactly
what happens depends on the server and the URL.  For example, it might
replace the contents of "foo" with the uploaded body.  Alternatively,
"gemini://example.org/do/this text/javascript\r\n" might cause the
JavaScript in the uploaded body to be executed on the server.

As a special case, a client can send a Dioscuri header without a media type
or separating space, in which case no request body is allowed or expected.
This can be used if the contents of the URL are sufficient to tell the
server what to do.

=======

When Dioscuri has received the header and body, then it does whatever it
does and returns a regular Gemini header with some extensions.  If the
server is going to be conversational, it will process the uploaded body
with whatever semantics it assigns to it and then send a regular Gemini
response header.  For example, an application server might be sent a
header "<URL> application/json\r\n" followed by a JSON value, compute
something, and return "20 application/json\r\n" followed by the computed
JSON value.

If the server has nothing to send to the client, as in the case of an
upload, it can respond with "20\r\n", which means that there is no response
body.

=======

By mutual agreement between the client and the server, the server may
return "70 <URL>\r\n" not  followed by a body.  This code means that the
request has succeeded, but rather than the server sending a response body
in the same TCP connection, the response body can be found at <URL>.

A use case for this is that the client wishes to add a new file to a
container (directory or whatever) in the server but leaves it up to the
server to choose the new URL according to some algorithm (random,
timestamp, etc.)  So a request of "<container-URL> text/gemini\r\n"
followed by the body would in such a case respond "60 <object-URL>\r\n",
meaning that the new resource can be found at <object-URL>.

All other 2-digit response codes have the same meaning in Dioscuri as in
Germini.  The reason for not using the 30 code in place of 60 is that 30
would mean "redirect the request", as for all other cases of 30, whereas 60
means "the response can be found here."  I thought of using 21, but that
would make the second status digit an essential part of the protocol.  Note
that like 2x, 6x is considered a success.

=======

Finally, an implementation note: the TCP library used to implement Dioscuri
clients must be able to separately close the input and the output sides of
the TCP connection to the server.  So in the application server discussed
above, the client closes the output side of its socket when it has sent the
body, and the server receives EOF when it attempts to read more body.
However,  the input side on the client must remain open so that the
server's response can be read.

Comments?



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
And it was said that ever after, if any man looked in that Stone,
unless he had a great strength of will to turn it to other purpose,
he saw only two aged hands withering in flame.   --"The Pyre of Denethor"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200927/1020e3cd/attachment.htm>

From meff at meff.me  Mon Sep 28 02:59:45 2020
From: meff at meff.me (Meff)
Date: Sun, 27 Sep 2020 18:59:45 -0700
Subject: Dioscuri, another application layer protocol
In-Reply-To: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
Message-ID: <87o8lqu0dq.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>

John Cowan <cowan at ccil.org> writes:

> A Dioscuri request starts out with the client sending a single line,
> <URL><SP><MEDIA-TYPE><CR><LF>.  This indicates that a body follows which
> should be interpreted according to the media type.  For example, "gemini://
> example.org/foo text/gemini\r\n" means that the Dioscuri server should do
> something with the following body, which is of type text/gemini.  Exactly
> what happens depends on the server and the URL.  For example, it might
> replace the contents of "foo" with the uploaded body.  Alternatively,
> "gemini://example.org/do/this text/javascript\r\n" might cause the
> JavaScript in the uploaded body to be executed on the server.

Does Dioscuri have the same line-length limits as Gemini?

>
> By mutual agreement between the client and the server, the server may
> return "70 <URL>\r\n" not  followed by a body.  This code means that the
> request has succeeded, but rather than the server sending a response body
> in the same TCP connection, the response body can be found at <URL>.
>
> A use case for this is that the client wishes to add a new file to a
> container (directory or whatever) in the server but leaves it up to the
> server to choose the new URL according to some algorithm (random,
> timestamp, etc.)  So a request of "<container-URL> text/gemini\r\n"
> followed by the body would in such a case respond "60 <object-URL>\r\n",
> meaning that the new resource can be found at <object-URL>.
>

Do you mean "70" here instead of "60"?

>
> Finally, an implementation note: the TCP library used to implement Dioscuri
> clients must be able to separately close the input and the output sides of
> the TCP connection to the server.  So in the application server discussed
> above, the client closes the output side of its socket when it has sent the
> body, and the server receives EOF when it attempts to read more body.
> However,  the input side on the client must remain open so that the
> server's response can be read.

Are there any limits on payload length from the client? Are there any
plans for the client to indicate to the server the length of the
payload? What happens if the server encounters a fault while reading in
the entire client payload?

Is there any guidance on timeouts? Should implementors assume that
timeouts are quick and the server should hangup quickly if nothing is
found on the client's send stream, or is this application dependent so
that it's up to the server/endpoint to determine timeouts (e.g. for a
streaming application)? My worry is that opening connections to the
server and keeping the server send connection open can quickly exhaust
the number of sockets/fds the server has available.

- meff

From neil at mckillop.org  Mon Sep 28 04:39:13 2020
From: neil at mckillop.org (Neil McKillop)
Date: Mon, 28 Sep 2020 04:39:13 +0100
Subject: [ANN] gemini-php: A Gemini server written in PHP
Message-ID: <CAEgwzvLepA63hYJ4OyOPmT8EVmZvSHbqMuOySKzVEZQatJiETQ@mail.gmail.com>

I wrote a simple implementation of a Gemini server in PHP.  It's very easy
to get up and running.

It was intended as one of the examples to help me teach socket programming
at a local open source workshop I run but I've enjoyed learning about the
protocol so I'm working on making it more featureful.

Full instructions at gemini://glasgow.social/gemini-php (or
https://opensource.glasgow.social/gemini-php)

Neil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/d6584522/attachment-0001.htm>

From sandra.snan at idiomdrottning.org  Mon Sep 28 07:35:08 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Mon, 28 Sep 2020 08:35:08 +0200
Subject: Dioscuri, another application layer protocol
In-Reply-To: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
Message-ID: <87tuvi4der.fsf@idiomdrottning.org>

Complexity inside the server I don't particularly fear.
My biggest fear for Gemini has been a proliferation of protocols.
"Protocols" defined loosely, not just as foo:// but as whenever a
computer asks something of another and expects a reply in a particular
format.

That fear was behind my hesitiation re codifying behavior in the alt
text strings earlier.

As for whatever a server does on its own, I leave great allowance.
Requests being files in a file system or routes in an MVC. But when two
computers talk to each other, that's the point when two giant spinning
spheres of grinding greebles speeding through space need to make
contact. Need to get on the same page on what they are doing.

We'll look back years from now when gemspace collective standards have a
complexity that overshadows that of the W3C specifications, and maybe
we'll recognize that this moment, this post was the Rubicon. Maybe we'll
think that the Pandora lid was already peeked through to the point of no
salvation, since an arbitrary sequence of GET requests could become a
protocol.

Even if the future disastrous level of complexity is inevitable, I'm not
convinced it needs to be parallel. When we are proposing protocols that
could already be done through existing standards (such as https) I ask
that there is very good reason why.

"Oh, it's chill, any particular client and any particular server can use
this for ANY semantics" only makes me more concerned, since it's the
foundation for a hundred hundreds of protocols.

I see how we want [comments, posting, uploading, interaction, talking]
between the clients and the server. The equiv of "textarea" and dinky
li'l radio buttons, and POST requests are necessary for that. But where
are the fences? Slippery slope? More like abyss sans railing.

Sometimes there IS very good reason to scrap and start over. To
voluntarily do a https://imgs.xkcd.com/comics/standards.png because you
have experience with possible use cases, good and bad, and you know how
to implement a simpler, coherent solution to sit beside the palimpsest
of wire hangers and chewing gum that preceded and inspired it.

Starting a new pile of junk next to the old pile of junk because you've
started having a hard time finding things in the old pile will
ultimately just leave you with two piles of junk.

The question raised by this isn't just "why Dioscuri?" It's "why should
we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
for this problem?" That isn't rhetorical. There could be good answers. I
just can't think of them.

The road to reckless complexity is spelled NIH with a ribbon bookmark.

From sean at conman.org  Mon Sep 28 08:15:12 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 28 Sep 2020 03:15:12 -0400
Subject: Dioscuri, another application layer protocol
In-Reply-To: <87tuvi4der.fsf@idiomdrottning.org>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org>
Message-ID: <20200928071512.GA10142@brevard.conman.org>

It was thus said that the Great Sandra Snan once stated:
> We'll look back years from now when gemspace collective standards have a
> complexity that overshadows that of the W3C specifications, and maybe
> we'll recognize that this moment, this post was the Rubicon. Maybe we'll
> think that the Pandora lid was already peeked through to the point of no
> salvation, since an arbitrary sequence of GET requests could become a
> protocol.

  Nope.  The Rubicon was passed earlier this year with talk of the titan:
protocol which allowed people to upload content to a Gemini server and has
already been implemented by at least one Gemini server.  Just go to this
link:

	https://lists.orbitalfox.eu/archives/gemini/2020/thread.html

and search for "titan".  You'll find the threads.  Also search for the
thread "Uploading Gemini Content".  Again, you'll find the threads.

  What I find sad is that this appears to be separate approach from the
titan: proposal, which either means the designers of this were not aware of
of the previous work, or have rejected the previous work for some unstated
reason---I'm hoping it's the former.

> The question raised by this isn't just "why Dioscuri?" It's "why should
> we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
> for this problem?" That isn't rhetorical. There could be good answers. I
> just can't think of them.

  Again, check the history of this list. It has been discussed before.

  -spc (Who fears that no one realizes that links to the mailing list
	archives are sent in the headers to every message ... )


From sandra.snan at idiomdrottning.org  Mon Sep 28 09:45:29 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Mon, 28 Sep 2020 10:45:29 +0200
Subject: Dioscuri, another application layer protocol
In-Reply-To: <20200928071512.GA10142@brevard.conman.org>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org>
 <20200928071512.GA10142@brevard.conman.org>
Message-ID: <87pn6647di.fsf@idiomdrottning.org>

In which case please reapply my rant to _that_ Rubicon


Sean Conner <sean at conman.org> writes:

> It was thus said that the Great Sandra Snan once stated:
>> We'll look back years from now when gemspace collective standards have a
>> complexity that overshadows that of the W3C specifications, and maybe
>> we'll recognize that this moment, this post was the Rubicon. Maybe we'll
>> think that the Pandora lid was already peeked through to the point of no
>> salvation, since an arbitrary sequence of GET requests could become a
>> protocol.
>
>   Nope.  The Rubicon was passed earlier this year with talk of the titan:
> protocol which allowed people to upload content to a Gemini server and has
> already been implemented by at least one Gemini server.  Just go to this
> link:
>
> 	https://lists.orbitalfox.eu/archives/gemini/2020/thread.html
>
> and search for "titan".  You'll find the threads.  Also search for the
> thread "Uploading Gemini Content".  Again, you'll find the threads.
>
>   What I find sad is that this appears to be separate approach from the
> titan: proposal, which either means the designers of this were not aware of
> of the previous work, or have rejected the previous work for some unstated
> reason---I'm hoping it's the former.
>
>> The question raised by this isn't just "why Dioscuri?" It's "why should
>> we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
>> for this problem?" That isn't rhetorical. There could be good answers. I
>> just can't think of them.
>
>   Again, check the history of this list. It has been discussed before.
>
>   -spc (Who fears that no one realizes that links to the mailing list
> 	archives are sent in the headers to every message ... )

From kevin at susa.net  Mon Sep 28 11:06:43 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Mon, 28 Sep 2020 11:06:43 +0100
Subject: [ANN] gemini-php: A Gemini server written in PHP
In-Reply-To: <CAEgwzvLepA63hYJ4OyOPmT8EVmZvSHbqMuOySKzVEZQatJiETQ@mail.gmail.com>
References: <CAEgwzvLepA63hYJ4OyOPmT8EVmZvSHbqMuOySKzVEZQatJiETQ@mail.gmail.com>
Message-ID: <CAPk6LxTfuLGGH1581WmH_boOmOqs8yYqmhv_U77q1mHkn3-ang@mail.gmail.com>

Great stuff - it's hard not to have a soft spot for such a pragmatic
language as PHP!

I measured performance at around 35 requests per second for the index page
vs 105 for gemserv (Rust, native binary). Resident RAM use was ~25MB vs
~7MB for gemserv.

I'd say that's pretty respectable for an interpreted language with a
runtime, that's forking connections. My own Java server weighs in at ~100MB
RAM, I must measure throughput, for fun.

Thanks for sharing!

Kevin


On Mon, 28 Sep 2020 at 04:39, Neil McKillop <neil at mckillop.org> wrote:

> I wrote a simple implementation of a Gemini server in PHP.  It's very easy
> to get up and running.
>
> It was intended as one of the examples to help me teach socket programming
> at a local open source workshop I run but I've enjoyed learning about the
> protocol so I'm working on making it more featureful.
>
> Full instructions at gemini://glasgow.social/gemini-php (or
> https://opensource.glasgow.social/gemini-php)
>
> Neil.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/e074e40f/attachment.htm>

From jmcbray at carcosa.net  Mon Sep 28 13:31:38 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 28 Sep 2020 08:31:38 -0400
Subject: Dioscuri, another application layer protocol
In-Reply-To: <87tuvi4der.fsf@idiomdrottning.org> (Sandra Snan's message of
 "Mon, 28 Sep 2020 08:35:08 +0200")
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org>
Message-ID: <878scuw09h.fsf@dorothy.carcosa.net>

Sandra Snan <sandra.snan at idiomdrottning.org> writes:

> "Oh, it's chill, any particular client and any particular server can use
> this for ANY semantics" only makes me more concerned, since it's the
> foundation for a hundred hundreds of protocols.

I strongly agree with you.

IMO, we should resist the temptation to make Gemini a general-purpose
application platform, and the like temptation to build a general purpose
application platform alongside it.

I prefer the idea of writing protocols that are specific to applications
(or classes of applications). A protocol for email; a protocol for
message boards; a protocol for file transfer. And a proliferation of
both clients and servers for each protocol. The use of HTTP for
everything has led to every site being an incompatible siloed
application... I'll save the rest of the rant for a gemlog post.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Mon Sep 28 13:41:27 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 28 Sep 2020 08:41:27 -0400
Subject: [ANN] gemini-php: A Gemini server written in PHP
In-Reply-To: <CAPk6LxTfuLGGH1581WmH_boOmOqs8yYqmhv_U77q1mHkn3-ang@mail.gmail.com>
 (Kevin Sangeelee's message of "Mon, 28 Sep 2020 11:06:43 +0100")
References: <CAEgwzvLepA63hYJ4OyOPmT8EVmZvSHbqMuOySKzVEZQatJiETQ@mail.gmail.com>
 <CAPk6LxTfuLGGH1581WmH_boOmOqs8yYqmhv_U77q1mHkn3-ang@mail.gmail.com>
Message-ID: <874knivzt4.fsf@dorothy.carcosa.net>

Kevin Sangeelee <kevin at susa.net> writes:

> Great stuff - it's hard not to have a soft spot for such a pragmatic language as PHP!
>
> I measured performance at around 35 requests per second for the index
> page vs 105 for gemserv (Rust, native binary). Resident RAM use was
> ~25MB vs ~7MB for gemserv.
>
> I'd say that's pretty respectable for an interpreted language with a
> runtime, that's forking connections. My own Java server weighs in at
> ~100MB RAM, I must measure throughput, for fun.

What did you use to measure requests per second? Is there some
equivalent to ab(1) for Gemini? I'm curious about the performance of my
own server ? it's a pretty naive implementation.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From cowan at ccil.org  Mon Sep 28 13:52:11 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 28 Sep 2020 08:52:11 -0400
Subject: Dioscuri, another application layer protocol
In-Reply-To: <87o8lqu0dq.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87o8lqu0dq.fsf@pop-os.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <CAD2gp_RcNzW+A+aEZwqRnZz6p75qpm7-gTn_zykQtGfywCzw1Q@mail.gmail.com>

On Sun, Sep 27, 2020 at 9:59 PM Meff <meff at meff.me> wrote:


> Does Dioscuri have the same line-length limits as Gemini?
>

Yes.  That means that you can't have quite as long an URL as in Gemini.
However, I suspect few people will do Gopher/Gemini-style searches through
Dioscuri.

Do you mean "70" here instead of "60"?
>

I picked 70 more or less at random, then went back and saw that 5x is the
highest Gemini status code, so I'll go with 60.  I didn't quite consummate
the change.


> Are there any limits on payload length from the client?


No, any more than there are limits on payload length from the server in
Gemini (or Dioscuri).


> Are there any
> plans for the client to indicate to the server the length of the
> payload?


That's the point of the one-sided close.  If we had to batch requests on
the same TCP connection, Content-Length would be indispensable, but as
things stand, closing the write side of the socket conveys that information.


> What happens if the server encounters a fault while reading in
> the entire client payload?
>

That's pretty vague: what kind of a fault?  The safe answer for the server
is "Close the connection", at which point the client will figure out (after
TCP timeout) that the request didn't work and apply its general policy
(abort, retry, or ignore) for such events.


> Is there any guidance on timeouts? Should implementors assume that
> timeouts are quick and the server should hangup quickly if nothing is
> found on the client's send stream, or is this application dependent so
> that it's up to the server/endpoint to determine timeouts (e.g. for a
> streaming application)?


The latter, I think.  The Gemini protocol definition mentions timeouts only
in connection with CGI.


> My worry is that opening connections to the
> server and keeping the server send connection open can quickly exhaust
> the number of sockets/fds the server has available.
>

With the Internet the way it is, servers must be written to defend
themselves against both intentional and unintentional attacks in any case.
But the difference between use and abuse depends on the use.  Sockets can
equally be overwhelmed by a Gemini attack.  DDOS protection helps here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/1af67ced/attachment.htm>

From cowan at ccil.org  Mon Sep 28 14:07:01 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 28 Sep 2020 09:07:01 -0400
Subject: Dioscuri, another application layer protocol
In-Reply-To: <20200928071512.GA10142@brevard.conman.org>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org>
 <20200928071512.GA10142@brevard.conman.org>
Message-ID: <CAD2gp_SY4FVu3XwgLwofx196KCT9s_sETL1iax4QJ9WS8OBkKA@mail.gmail.com>

On Mon, Sep 28, 2020 at 3:15 AM Sean Conner <sean at conman.org> wrote:

Nope.  The Rubicon was passed earlier this year with talk of the titan:
> protocol which allowed people to upload content to a Gemini server and has
> already been implemented by at least one Gemini server.


You could with equal justice say that publishing Gemini crossed the
Rubicon, since I would certainly never have thought of Dioscuri without
first hearing of Gemini (and being fascinated, since it was clearly a very
nice extension of Gopher's ideas, which I have always loved).


>   What I find sad is that this appears to be separate approach from the
> titan: proposal, which either means the designers of this were not aware of
> of the previous work, or have rejected the previous work for some unstated
> reason---I'm hoping it's the former.
>

I wrote down an early version of Dioscuri when I had barely heard of
Titan.  Later, #gemini pointed me to Titan and I looked at it.  I wasn't
able to find a protocol description and had to reverse engineer it from the
Bash code, but it seemed to me that it was too limited: it provided upload
only, rather than a conversational protocol like I wanted in which
responses were symmetrical with requests.  So I have not so much rejected
Titan as decided that my goals were sufficiently different.


> > The question raised by this isn't just "why Dioscuri?" It's "why should
> > we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
> > for this problem?" That isn't rhetorical. There could be good answers. I
> > just can't think of them.
>

(S)FTP was in fact part of the inspiration for Dioscuri, but I wanted
something much similar.  My earlier version of D. had GET/PUT/POST/DELETE
verbs and the possibility of extensions, but #gemini participants convinced
me that POST was sufficient, provided three cases were well handled:  (a)
no request body (b) no response body (c) the ability to respond with an URL
rather than an anonymous body.  I think I have done that.

JSON, XML, and S-expressions are formats and are all fine: I mentioned JSON
for familiarity, but exchanging information in .INI file format is
perfectly fine (and in fact it can be made isomorphic with XML).

Above all, DIoscuri is both simple and general.  That's not an easy target
to hit, and it's clear to me that Gemini has hit it.  I might quibble about
some details, but I won't.  I have done my best to hit the (slightly
different) target too.

  Again, check the history of this list. It has been discussed before.
>

I read through as much of this year's archives as I could, and I haven't
seen anything bidirectional like this.  Please point me to appropriate
emails if there are any.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
He who would do good to another must do it in Minute Particulars;
General Good is the plea of the scoundrel, hypocrite and flatterer:
For Art and Science cannot exist but in minutely organized Particulars.
  --William Blake, il miglior fabbro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/9c15807f/attachment.htm>

From martin at no.ucant.org  Mon Sep 28 14:09:59 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Mon, 28 Sep 2020 14:09:59 +0100 (BST)
Subject: Dioscuri, another application layer protocol
In-Reply-To: <878scuw09h.fsf@dorothy.carcosa.net>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org> <878scuw09h.fsf@dorothy.carcosa.net>
Message-ID: <alpine.DEB.2.20.2009281404110.16057@pling.qwghlm.org>

On Mon, 28 Sep 2020, Jason McBrayer wrote:

> IMO, we should resist the temptation to make Gemini a general-purpose
> application platform, and the like temptation to build a general purpose
> application platform alongside it.

The ease and enjoyment of creating a reasonably good server or client for 
the Gemini protocol/format has led to perhaps more clients and servers 
than we need; a positive consequence has been to increase the amount of
caution with which spec changes are now approached.

I think however there is a negative consequence: attention is diverted 
from complementary aspects of the Gemini ecosystem, namely Gemini-native 
content itself, and the tooling connected with it, such as distribution, 
discovery and syndication tools. If there were a simple, fun standard/spec 
for some aspect of these tools, that might attract the same useful energy 
as the Gemini spec itself does.

(As indicated above, I am pretty sceptical about additional 
Gemini-adjacent protocols as such)

Mk

From petite.abeille at gmail.com  Mon Sep 28 14:22:15 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Sep 2020 15:22:15 +0200
Subject: Dioscuri, another application layer protocol
In-Reply-To: <CAD2gp_SY4FVu3XwgLwofx196KCT9s_sETL1iax4QJ9WS8OBkKA@mail.gmail.com>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org>
 <20200928071512.GA10142@brevard.conman.org>
 <CAD2gp_SY4FVu3XwgLwofx196KCT9s_sETL1iax4QJ9WS8OBkKA@mail.gmail.com>
Message-ID: <96D71F46-6FCC-4319-8888-366A2F788270@gmail.com>



> On Sep 28, 2020, at 15:07, John Cowan <cowan at ccil.org> wrote:
> 
> I read through as much of this year's archives as I could, and I haven't seen anything bidirectional like this.  Please point me to appropriate emails if there are any.
> 


Look for inimeg (gemini spelled backward :P, circa June '00, re: gemini+submit:// (was Re: Uploading Gemini content ) )

From jmcbray at carcosa.net  Mon Sep 28 15:52:53 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 28 Sep 2020 10:52:53 -0400
Subject: Dioscuri, another application layer protocol
In-Reply-To: <alpine.DEB.2.20.2009281404110.16057@pling.qwghlm.org> (Martin
 Keegan's message of "Mon, 28 Sep 2020 14:09:59 +0100 (BST)")
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org> <878scuw09h.fsf@dorothy.carcosa.net>
 <alpine.DEB.2.20.2009281404110.16057@pling.qwghlm.org>
Message-ID: <87v9fyuf5m.fsf@dorothy.carcosa.net>

Martin Keegan <martin at no.ucant.org> writes:

> I think however there is a negative consequence: attention is diverted from
> complementary aspects of the Gemini ecosystem, namely Gemini-native content
> itself, and the tooling connected with it, such as distribution, discovery and
> syndication tools. If there were a simple, fun standard/spec for some aspect of
> these tools, that might attract the same useful energy as the Gemini spec itself
> does.

Yeah, I think there's potentially a lot to be done here. Even just some
examples, like a desktop app that lets you write and publish a journal
with no server knowledge.


-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From tva at fastmail.se  Mon Sep 28 16:55:16 2020
From: tva at fastmail.se (=?UTF-8?Q?=C3=96ppen?=)
Date: Mon, 28 Sep 2020 16:55:16 +0100
Subject: =?UTF-8?Q?Android_client_Tv=C3=A5_is_now_Ariane._1.0.0_release?=
Message-ID: <97b0c26a-33cf-46ef-b1c5-30b13e681025@www.fastmail.com>

1.0.0 available: https://oppenlab.net/pr/ariane/

New easier and friendlier name, and a more traditional app icon. 

Big fix for Android 11 which changed socket handling subtly and broke the previous app. This version also adds bookmarks.

I've not had as much time to work on this lately as I'd like (young family and day job pressures), but hope to add proper cert handling very soon and tidy up a few rough edges.

As ever feedback and suggestions welcome: oppen at fastmail.se

From me at svmhdvn.name  Mon Sep 28 17:38:29 2020
From: me at svmhdvn.name (Siva Mahadevan)
Date: Mon, 28 Sep 2020 12:38:29 -0400
Subject: Android client =?utf-8?Q?Tv=C3=A5?= is now Ariane. 1.0.0 release
In-Reply-To: <97b0c26a-33cf-46ef-b1c5-30b13e681025@www.fastmail.com>
References: <97b0c26a-33cf-46ef-b1c5-30b13e681025@www.fastmail.com>
Message-ID: <87k0wd97qy.fsf@svmhdvn.name>

?ppen <tva at fastmail.se> said:
> 1.0.0 available: https://oppenlab.net/pr/ariane/

I would like to try this out, but I think the link is broken right now
(it's giving me a forbidden error).

From jansen.price at gmail.com  Mon Sep 28 20:18:26 2020
From: jansen.price at gmail.com (Jansen Price)
Date: Mon, 28 Sep 2020 14:18:26 -0500
Subject: [ANN] Orbit: Gemini server written in PHP
Message-ID: <CAJyFNOzJd_sT=OekCP3vdjwhR6a5-yfQo12q1W21YTbB9GXUaw@mail.gmail.com>

Hello all,

After becoming intrigued by gemini and spending some time learning
and using it, I thought it would be fun to create a server in PHP because
why not? I present to you orbit: https://tildegit.org/sumpygump/orbit

It currently passes all the tests from gemini-diagnostics (
https://github.com/michael-lazar/gemini-diagnostics). I have included some
details to install it as a GNU/linux service using systemd. It also has an
option to auto-generate self-signed certificates.

I have had issues trying to support client certificates, due to how PHP
internally manages sockets invoked with `stream_socket_server` but I
haven't exhausted all possibilities yet.

Currently it only serves static assets, but my plan next is to add some
support for dynamic content via cgi scripts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/12688596/attachment.htm>

From kevin at susa.net  Tue Sep 29 00:04:10 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 29 Sep 2020 00:04:10 +0100
Subject: [ANN] Orbit: Gemini server written in PHP
In-Reply-To: <CAJyFNOzJd_sT=OekCP3vdjwhR6a5-yfQo12q1W21YTbB9GXUaw@mail.gmail.com>
References: <CAJyFNOzJd_sT=OekCP3vdjwhR6a5-yfQo12q1W21YTbB9GXUaw@mail.gmail.com>
Message-ID: <CAPk6LxQ0f-84=qD2=G-7K_r3Qe-cs5=7dDaih914Ow5k6K9hNw@mail.gmail.com>

It's like my nan used to say - you hang around for ages waiting for a PHP
Gemini Server, then two come along at once. (in case you're wondering,
another PHP server was announced earlier today - who'd have thought).

I was curious about how PHP might give access to the client certificate,
and discovered this example that might be of use
https://freek.dev/530-validating-ssl-certificates-with-php - it seems based
on the stream socket approach that you also use, and if so it shows how to
get the X509 certificate that you can use to generate an SHA-256 signature.

In any case, thanks for sharing!  Are you currently running any sites on
this?

Kevin

On Mon, 28 Sep 2020 at 20:18, Jansen Price <jansen.price at gmail.com> wrote:

> Hello all,
>
> After becoming intrigued by gemini and spending some time learning
> and using it, I thought it would be fun to create a server in PHP because
> why not? I present to you orbit: https://tildegit.org/sumpygump/orbit
>
> It currently passes all the tests from gemini-diagnostics (
> https://github.com/michael-lazar/gemini-diagnostics). I have included
> some details to install it as a GNU/linux service using systemd. It also
> has an option to auto-generate self-signed certificates.
>
> I have had issues trying to support client certificates, due to how PHP
> internally manages sockets invoked with `stream_socket_server` but I
> haven't exhausted all possibilities yet.
>
> Currently it only serves static assets, but my plan next is to add some
> support for dynamic content via cgi scripts.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200929/fa410259/attachment-0001.htm>

From mailinglists at ngalt.com  Tue Sep 29 07:22:21 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Mon, 28 Sep 2020 23:22:21 -0700
Subject: Dioscuri, another application layer protocol
In-Reply-To: <alpine.DEB.2.20.2009281404110.16057@pling.qwghlm.org>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org> <878scuw09h.fsf@dorothy.carcosa.net>
 <alpine.DEB.2.20.2009281404110.16057@pling.qwghlm.org>
Message-ID: <07ACE135-FF1A-4544-9B70-554D5205C421@ngalt.com>



> On Sep 28, 2020, at 6:09 AM, Martin Keegan <martin at no.ucant.org> wrote:
> 
> On Mon, 28 Sep 2020, Jason McBrayer wrote:
> 
>> IMO, we should resist the temptation to make Gemini a general-purpose
>> application platform, and the like temptation to build a general purpose
>> application platform alongside it.
> 
> The ease and enjoyment of creating a reasonably good server or client for the Gemini protocol/format has led to perhaps more clients and servers than we need; a positive consequence has been to increase the amount of
> caution with which spec changes are now approached.
> 
> I think however there is a negative consequence: attention is diverted from complementary aspects of the Gemini ecosystem, namely Gemini-native content itself, and the tooling connected with it, such as distribution, discovery and syndication tools. If there were a simple, fun standard/spec for some aspect of these tools, that might attract the same useful energy as the Gemini spec itself does.

I think a lot of us would rather work on Gemini things rather than served-up-over-Gemini things. Might be a pent-up-demand kind of thing.

(says the guy who?s splitting his time between a static-gemlog generator and actually writing stuff for his capsule when he really should just do the latter)

From me at shadowfacts.net  Wed Sep 30 04:13:32 2020
From: me at shadowfacts.net (Shadowfacts)
Date: Tue, 29 Sep 2020 23:13:32 -0400
Subject: [ANN] Rocketeer, a Gemini browser for iOS
Message-ID: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>

Hey all,

I?ve been working on a native Gemini browser app for iOS and macOS called Rocketeer for a little while now, and I decided to finally release a public alpha for the iOS version.

It?s written entirely from scratch with no dependencies aside from the OS, so it?s very lightweight. The feature set is pretty slim right now, but I wanted to have something out there while I continue working on it. It of course makes Gemini requests and renders text/gemini documents. Rocketeer also registers itself as a gemini:// protocol handler, so links tapped in other apps will open it.

There are a few screenshots here:
https://social.shadowfacts.net/media/28bfba91-b609-4433-ba26-36f40fd793eb/Rocketeer.png <https://social.shadowfacts.net/media/28bfba91-b609-4433-ba26-36f40fd793eb/Rocketeer.png>

And you can try the app by joining the beta through TestFlight:
https://testflight.apple.com/join/LAs1URxM <https://testflight.apple.com/join/LAs1URxM>

If anyone has any issues, suggestions, or other feedback, please let me know! You can of course email me at this address, and I?m also on the fediverse as @shadowfacts at social.shadowfacts.net.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200929/2dad97dc/attachment.htm>

From mailinglists at ngalt.com  Wed Sep 30 06:43:45 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Tue, 29 Sep 2020 22:43:45 -0700
Subject: Feature requests/bug reports for Rocketeer (was: Re: [ANN] Rocketeer, 
 a Gemini browser for iOS)
In-Reply-To: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
References: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
Message-ID: <A6B3AB72-36BD-4662-9A3B-C5A43159DB0D@ngalt.com>


> On Sep 29, 2020, at 8:13 PM, Shadowfacts <me at shadowfacts.net> wrote:
> 
> Hey all,
> 
> I?ve been working on a native Gemini browser app for iOS and macOS called Rocketeer for a little while now, and I decided to finally release a public alpha for the iOS version.
> 
> It?s written entirely from scratch with no dependencies aside from the OS, so it?s very lightweight. The feature set is pretty slim right now, but I wanted to have something out there while I continue working on it. It of course makes Gemini requests and renders text/gemini documents. Rocketeer also registers itself as a gemini:// protocol handler, so links tapped in other apps will open it.
> 
> There are a few screenshots here:
> https://social.shadowfacts.net/media/28bfba91-b609-4433-ba26-36f40fd793eb/Rocketeer.png
> 
> And you can try the app by joining the beta through TestFlight:
> https://testflight.apple.com/join/LAs1URxM
> 
> If anyone has any issues, suggestions, or other feedback, please let me know! You can of course email me at this address, and I?m also on the fediverse as @shadowfacts at social.shadowfacts.net.

Oh, wow. This is _great_. Dark mode right out of the gate? Be still, my beating heart.

Requests, in no particular order:

- The link-color/background color contrast is a little low in dark mode. I generally don?t have issues with contrast, but link text is a bit dark to read easily. Could you make the link text a bit lighter?

- Add titles to the buttons. Right now, when I turn on Voice Control (?hey Siri, turn on Voice Control?) and say ?show names? the buttons on the bottom have names like ?Arrow.clockwise?. Could these be changed to ?Back?, ?Forward, ?Reload?, ?Share?, and ?Settings? (what both Overcast and PCalc use)?

(I cannot wait to browse Geminispace when my hands are coated in partially-mixed hamburger meat)

- swipe-from-edge behavior to go back and forward

- Consider having a minimum 44-point height for links (this may be ugly and/or a lot of work to not be ugly). While almost all links are two rows high on my 1st-generation iPhone SE, most links are only one line on my 10.5? iPad when it?s in landscape mode. It?s kind of tough to aim for a single line on, say, CAPCOM when any given link has two close-by neighbors. For one way to do this sort of thing, have a look at the screenshot associated with ?The Best Comments Experience? on https://apolloapp.io/ ? the currently-being-swiped comment is basically all one link, but there?s a nice, easy-to-hit button for it. (For Gemini, having the link _be_ that minimum-height button would probably be best, since we don?t have to worry about a bunch of consecutive words in a sentence being separate links.)

- I visited <gemini://gemini.circumlunar.space/users/adiabatic/tracker.webp?on=/> and the error message got ellipsis-truncated, not wrapped. I had to rotate my phone 90? to read the entire message. (I?m not sure _why_ it failed, but WebP is the new kid on the block when it comes to WebKit support. I blame its newness.)

- Fix the share-button crash that seems to happen only on my iPad (Apple should get those crash reports to you; if not, ping me and I?ll see if I can dig them out of my iPad the old-fashioned way).

And in the ?_much_ less important requests? pile?

- Aim assist (that?s what console FPS players call it, at least; Apple seems to call it ?Magnetism") doesn?t seem to work for trackpad cursors. That is, the proxy fingertip won?t snap to the outline of the bottom-bar buttons like it will for Safari?s buttons. You can (kinda) see this effect on https://support.apple.com/en-us/HT211008 on the second screenshot, er, screenmovie.

Apparently only a handful of buttons get this feature for free; in Overcast?s UI, only the buttons on the left half of the screen (pick-a-playlist and pick-an-episode-in-a-playlist) have auto-aim enabled.

=> https://developer.apple.com/videos/play/wwdc2020/10640/ I?m not sure I?d even bother for myself, but if you?re bored?


??

Once again, Rocketeer is absolutely wonderful. Thank you again for making it.

From linde.philip at gmail.com  Wed Sep 30 08:31:16 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 30 Sep 2020 09:31:16 +0200
Subject: [ANN] Rocketeer, a Gemini browser for iOS
In-Reply-To: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
References: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
Message-ID: <20200930093116.c55f4e08afa3b5b489058446@gmail.com>

> Hey all,
> 
> I?ve been working on a native Gemini browser app for iOS and macOS called Rocketeer for a little while now, and I decided to finally release a public alpha for the iOS version.

That looks great!

I'd be happy to try it out, but my device is stuck on iOS 12.x (because
iPhone 5S). I have no idea how much effort would be involved in
supporting iOS<13, but would appreciate it if it isn't going to be a
hassle.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200930/98119865/attachment.sig>

From mieum at tilde.team  Wed Sep 30 08:36:55 2020
From: mieum at tilde.team (mieum)
Date: Wed, 30 Sep 2020 16:36:55 +0900
Subject: [ANN] Rocketeer, a Gemini browser for iOS
In-Reply-To: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
Message-ID: <C60J5BXSJ16P.38PWTD58GTK1L@maclibre>

Wow, thanks for making this! I'm excited to see this project develop :)
I especially like that preformatted text displays well, even special
characters like braille~ I also like that it's from scratch. I had been
"test flying" the client called "Gemini," but it would crash constantly
on my device =\ 

I think a good iOS client would help to recruit some new geminauts. It
will certainly help me evangelize Gemini in my circles~

I will send a few comments about bugs and things directly to your email
:)

Thanks again!
~mieum

From ajc at apintandaparma.club  Wed Sep 30 09:00:53 2020
From: ajc at apintandaparma.club (Andrew J Cosgriff)
Date: Wed, 30 Sep 2020 18:00:53 +1000
Subject: [ANN] Rocketeer, a Gemini browser for iOS
In-Reply-To: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
 (Shadowfacts's message of "Tue, 29 Sep 2020 23:13:32 -0400")
References: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
Message-ID: <86blhnr8wa.fsf@jaki.h.ajcos.net>

Shadowfacts wrote :

> Hey all,
>
> I?ve been working on a native Gemini browser app for iOS and macOS
> called Rocketeer for a little while now, and I decided to finally
> release a public alpha for the iOS version.

Oh my lord, thank you so much for this!

As much as I enjoy Elpher and amfora, being able to peek at a gemini
link from my phone is mega-handy. I really appreciate your work. I?ve
installed it, and will give more feedback later.

Cheers,
 Cos.
-- 
 Andrew J Cosgriff | gemini://apintandaparma.club/~ajc

From tildebeast at envs.net  Wed Sep 30 09:42:25 2020
From: tildebeast at envs.net (tildebeast at envs.net)
Date: Wed, 30 Sep 2020 08:42:25 -0000
Subject: Notes on Molly Brown in FreeBSD
Message-ID: <20200930084225.1539.37206@mail.envs.net>

HI geminauts,

This is my first post so apologies if I fluff the etiquette. I have posted some notes on installing and running Molly Brown on FreeBSD 12. You can find them here:

gemini://envs.net/~tildebeast/technology/mollybrown-freebsd.gmi

They were based on notes jotted down during the setup of an as-yet unlisted Gemini server. Steps may be in the wrong order or missing.

Please let me know if anything is obviously dangerous/bad practice and I'll try to fix it ASAP!

Tildebeast

From me at shadowfacts.net  Wed Sep 30 14:14:42 2020
From: me at shadowfacts.net (Shadowfacts)
Date: Wed, 30 Sep 2020 09:14:42 -0400
Subject: [ANN] Rocketeer, a Gemini browser for iOS
In-Reply-To: <20200930093116.c55f4e08afa3b5b489058446@gmail.com>
References: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
 <20200930093116.c55f4e08afa3b5b489058446@gmail.com>
Message-ID: <DECC5679-4888-4004-9502-D160FA8EE8E5@shadowfacts.net>

> I'd be happy to try it out, but my device is stuck on iOS 12.x (because
> iPhone 5S). I have no idea how much effort would be involved in
> supporting iOS<13, but would appreciate it if it isn't going to be a
> hassle.

Ah, that?s too bad. It?s written entirely using SwiftUI, the UI framework Apple introduced in iOS 13. So, unfortunately, back porting to earlier OS versions isn?t really feasible. This may change in the future, since there are a number of limitations SwiftUI imposes that aren?t easy to work around, and if it does, I?ll definitely look into supporting earlier OS?s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200930/dbcea7f8/attachment.htm>

From artyr3 at pm.me  Wed Sep 30 14:58:35 2020
From: artyr3 at pm.me (artyr3)
Date: Wed, 30 Sep 2020 13:58:35 +0000
Subject: [ANN] Rocketeer, a Gemini browser for iOS
In-Reply-To: <DECC5679-4888-4004-9502-D160FA8EE8E5@shadowfacts.net>
References: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
 <20200930093116.c55f4e08afa3b5b489058446@gmail.com>
 <DECC5679-4888-4004-9502-D160FA8EE8E5@shadowfacts.net>
Message-ID: <QWESJzrOYTB8x244MlFd6420vS_rJ9lK482BldqVT3K5wr5X_00Zx0cpleaJEhkZuBUhPXKgm67k8w8sKseCCrgQzJcG9bjfDVm8kaDGEwI=@pm.me>

I read your lengthy and very detailed blogpost about implementing a Gemini client in Swift. I?d love to try it out...

On Wed, Sep 30, 2020 at 6:14 AM, Shadowfacts <me at shadowfacts.net> wrote:

>> I'd be happy to try it out, but my device is stuck on iOS 12.x (because
>>
>> iPhone 5S). I have no idea how much effort would be involved in
>> supporting iOS<13, but would appreciate it if it isn't going to be a
>> hassle.
>
> Ah, that?s too bad. It?s written entirely using SwiftUI, the UI framework Apple introduced in iOS 13. So, unfortunately, back porting to earlier OS versions isn?t really feasible. This may change in the future, since there are a number of limitations SwiftUI imposes that aren?t easy to work around, and if it does, I?ll definitely look into supporting earlier OS?s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200930/aa973d43/attachment.htm>

From me at shadowfacts.net  Wed Sep 30 15:11:13 2020
From: me at shadowfacts.net (Shadowfacts)
Date: Wed, 30 Sep 2020 10:11:13 -0400
Subject: Feature requests/bug reports for Rocketeer (was: Re: [ANN]
 Rocketeer,  a Gemini browser for iOS)
In-Reply-To: <A6B3AB72-36BD-4662-9A3B-C5A43159DB0D@ngalt.com>
References: <791D6EF5-E38B-43A8-8322-3D193AC08891@shadowfacts.net>
 <A6B3AB72-36BD-4662-9A3B-C5A43159DB0D@ngalt.com>
Message-ID: <FD91B1C7-6485-4564-A736-816B004E3DF1@shadowfacts.net>

> Requests, in no particular order:
> 
> - The link-color/background color contrast is a little low in dark mode. I generally don?t have issues with contrast, but link text is a bit dark to read easily. Could you make the link text a bit lighter?
> 
> - Add titles to the buttons. Right now, when I turn on Voice Control (?hey Siri, turn on Voice Control?) and say ?show names? the buttons on the bottom have names like ?Arrow.clockwise?. Could these be changed to ?Back?, ?Forward, ?Reload?, ?Share?, and ?Settings? (what both Overcast and PCalc use)?

Definitely.

> - swipe-from-edge behavior to go back and forward

This is slightly more complicated, as I?m not using the normal iOS mechanisms that would provide this behavior, but I?ll look into it.

> - Consider having a minimum 44-point height for links (this may be ugly and/or a lot of work to not be ugly). While almost all links are two rows high on my 1st-generation iPhone SE, most links are only one line on my 10.5? iPad when it?s in landscape mode. It?s kind of tough to aim for a single line on, say, CAPCOM when any given link has two close-by neighbors. For one way to do this sort of thing, have a look at the screenshot associated with ?The Best Comments Experience? on https://apolloapp.io/ ? the currently-being-swiped comment is basically all one link, but there?s a nice, easy-to-hit button for it. (For Gemini, having the link _be_ that minimum-height button would probably be best, since we don?t have to worry about a bunch of consecutive words in a sentence being separate links.)

Absolutely.

> - I visited <gemini://gemini.circumlunar.space/users/adiabatic/tracker.webp?on=/> and the error message got ellipsis-truncated, not wrapped. I had to rotate my phone 90? to read the entire message. (I?m not sure _why_ it failed, but WebP is the new kid on the block when it comes to WebKit support. I blame its newness.)

I?ll look into the error message being truncated, but WebP isn?t supported at all by iOS.

> - Fix the share-button crash that seems to happen only on my iPad (Apple should get those crash reports to you; if not, ping me and I?ll see if I can dig them out of my iPad the old-fashioned way).

I haven?t seen that crash report, but I know what the issue is.

> - Aim assist (that?s what console FPS players call it, at least; Apple seems to call it ?Magnetism") doesn?t seem to work for trackpad cursors. That is, the proxy fingertip won?t snap to the outline of the bottom-bar buttons like it will for Safari?s buttons. You can (kinda) see this effect on https://support.apple.com/en-us/HT211008 on the second screenshot, er, screenmovie.

Definitely doable.

> Once again, Rocketeer is absolutely wonderful. Thank you again for making it.

Thanks, I?m glad you?re enjoying it! I?ll try to push a new beta later today with fixes for most of these.


From sandra.snan at idiomdrottning.org  Wed Sep 30 17:14:03 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Wed, 30 Sep 2020 18:14:03 +0200
Subject: Dioscuri, another application layer protocol
In-Reply-To: <878scuw09h.fsf@dorothy.carcosa.net>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org> <878scuw09h.fsf@dorothy.carcosa.net>
Message-ID: <87r1qj2qes.fsf@idiomdrottning.org>

Jason McBrayer <jmcbray at carcosa.net> writes:
> IMO, we should resist the temptation to make Gemini a general-purpose
> application platform, and the like temptation to build a general purpose
> application platform alongside it.

The good old days when we had separate apps for everything was paradise
for me, and, well, still is because I can still happily live in that
world in my li'l Debian bubble.

You've seen me rant against web apps before, for example on here:
https://github.com/w3c/web-share/issues/173

But it was not easy for most people to ./configure, make, make install
things. Using web apps is something they can do.

As an example, email exploded once web-interfaces to email became
available.

If Gemini and adjacent protocols turn into a general-purpose application
platform, there need to be some sort of purpose or guiding light or
boundaries or reason for starting a new pile instead of working on the
already existing pile of junk.

Dioscuri doesn't have a client-side, server-served programming language.
Such things are the cause of a lot of the web's problems so that's not
what I'm proposing, but, the consequence of _not_ having it means that
every Dioscuri?app needs to have its own implementation.

Talk about complexity in the client! With SSH I can have an app on the
remote and call it from my client.

ssh some-server-name 'ls|tail'

The SSH client doesn't need to know or implement the semantics of ls or
tail. With Dioscuro, there is a lot of responsibilty for both sides to
be on the same page with regards to semantics.

Sandra

PS.
Here's an idea, in the mindset of green hat "thinking out loud":

*If* there were to be a new general-purpose application platform
along-side Gemini, client side should be "dumb" and the protocol (i.e.
the interface between client and server) also needs to be simple and
specific.

A handful of standard UI elements communicating with server back and
forth in a straight-forward way according to one specific protocol.

The following is not gonna sound retro, but? if parts of the page could
update without reloading the entire page, that'd go a long way to
alleviate a lot of people's desire for JavaScript, AJAX etc. One button,
one checkbox, one text field etc could be sent without having to send
the entire form, and one local UI area could be updated without having
to refetch the entire page.

I.e. the client holds only the view and the user inputs. It should be
like pushing on remote buttons with a ten foot pole on the other side of
a chasm.

PPS.
OTOH, what I just described sounds like it could turn a FOSS nightmare
that there ain't no AGPL strong enough to prevent, so uh, don't hold me
to that idea. Just thinking out loud.

From jmcbray at carcosa.net  Wed Sep 30 18:31:12 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 30 Sep 2020 13:31:12 -0400
Subject: Dioscuri, another application layer protocol
In-Reply-To: <87r1qj2qes.fsf@idiomdrottning.org> (Sandra Snan's message of
 "Wed, 30 Sep 2020 18:14:03 +0200")
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org> <878scuw09h.fsf@dorothy.carcosa.net>
 <87r1qj2qes.fsf@idiomdrottning.org>
Message-ID: <87362z893z.fsf@dorothy.carcosa.net>

Sandra Snan <sandra.snan at idiomdrottning.org> writes:

> The following is not gonna sound retro, but? if parts of the page
> could update without reloading the entire page, that'd go a long way
> to alleviate a lot of people's desire for JavaScript, AJAX etc. One
> button, one checkbox, one text field etc could be sent without having
> to send the entire form, and one local UI area could be updated
> without having to refetch the entire page.

You might be interested in looking at intercooler.js
(https://intercoolerjs.org/) and HTMX (https://htmx.org/), which
implement this pattern in the browser. Of course, browsers don't
natively support HTMX, so it's written in JavaScript; but a browser
*could* implement almost all of it without also implementing JavaScript.

Of course, it seems to me that this is also how IBM 3270 terminals
worked, more or less.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From colecmac at protonmail.com  Thu Oct  1 22:38:37 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 01 Oct 2020 21:38:37 +0000
Subject: Using normal tls certificates with gemini
In-Reply-To: <20200921190422.gcrznea44ljk4my6@GLaDOS>
References: <20200921190422.gcrznea44ljk4my6@GLaDOS>
Message-ID: <NmAH95DQUW0qPfRCtyX2yRk0atcJ6XaAmHeX9eIb6TGhWAboo4bH7K6-q-r8TU7jf1iwLbtUJ2MalYGLd_tpWDHlyIXLNA0XnQSXXOTvmGw=@protonmail.com>

> For my gemini capsule's tls setup, I just used my Let's Encrypt
> certificate since I already had it set up for my web site. However,
> after reading deeper into server setup with gemini, I discovered that
> I'm probably adding a lot of extra request overhead by using a
> certificate from a CA instead of self-signed. Now my problem is that if
> I change out the certificate, then people that have previously visited
> my site may think it is compromised because the certificate changed and
> most clients are TOFU. Should I change out the certificate or is it fine
> to leave it as is?

I had the same problem for my capsule, gemini://makeworld.gq. What I did
was wait until the Let's Encrypt cert expired for a clean transition, and
then created my own small 5-year cert. See my gemlog post for details on
how to generate these:

gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi

There is also the gemcert tool:
https://tildegit.org/solderpunk/gemcert


> As an additional question, if I was writing a more advanced gemini
> client, should I validate cert chains if they're availaible or only use
> TOFU on the fingerprint and ignore chains entirely? The spec just says
> to validate however you want, but what's the community's recommendation?

Only validate the certificate in the chain that applies to the host you're
visiting, ignore all the others. Most servers do not send chains anyway,
as it adds needless extra bytes. But that does not mean fingerprints shouldn't
be used, you can still take the fingerprint of the last cert in the chain.

Cheers,
makeworld

From sir at cmpwn.com  Thu Oct  1 22:43:33 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 01 Oct 2020 17:43:33 -0400
Subject: Using normal tls certificates with gemini
In-Reply-To: <NmAH95DQUW0qPfRCtyX2yRk0atcJ6XaAmHeX9eIb6TGhWAboo4bH7K6-q-r8TU7jf1iwLbtUJ2MalYGLd_tpWDHlyIXLNA0XnQSXXOTvmGw=@protonmail.com>
Message-ID: <C61VS3PMRWRP.168R828QJ2WSA@homura>

I think server software should handle certificates for you and clients
should TOFU them. Dealing with certificates is annoying and dumb and the
CAs are a cabal and we don't need any of that noise in our brave new
gemini future.

My server implementation generates 1-year certificates on startup for
any domain its configured to service, and automatically rotates them.
The admin isn't involved in this in any capacity, except to copy+paste
the certificate store if they move between servers.

From colecmac at protonmail.com  Thu Oct  1 22:55:13 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 01 Oct 2020 21:55:13 +0000
Subject: TOFU recommendations for Gemini clients
In-Reply-To: <C5UZ25UIIHW0.3WLZRYBKKHG4@homura>
References: <C5UZ25UIIHW0.3WLZRYBKKHG4@homura>
Message-ID: <oEZCohkYMaHSHUtCuUYzi7wkq7QlRePKovcli9NLQFiNeKvePhnyNGzY_i7RSPQrNseaA7DQtHdizEpXOU0Wsm9pTY1mTyJsl93JULj2xAE=@protonmail.com>

Hello Drew,

You might be interested in a gemlog post I wrote a while back, with basically
the same topic, it's my TOFU recommendations for Gemini.

gemini://makeworld.gq/gemlog/2020-07-03-tofu-rec.gmi

My recommendations are pretty similar to yours. A few differences:

- I don't specify a file/storage format
- The cert fingerprint is generated from just the SPKI section of the cert,
   not the entire thing. See the post for rationale.
- The port is also stored (host vs hostname) so that different ports can
   use different certs
- I don't make any distinction between temporary and always trust
- I mention SHA-256, but that's just an implementation detail

I also noticed that your flow doesn't seem to update the host data if the
cert has expired, it just allows the request to continue. I assume that's
an error? Or maybe I'm misreading.

Would be happy to hear about what you think of my recommendations! I hope
they're useful, I've been trying to spread them on Gemini since I wrote them.

Cheers,
makeworld

From sir at cmpwn.com  Thu Oct  1 22:58:24 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 01 Oct 2020 17:58:24 -0400
Subject: TOFU recommendations for Gemini clients
In-Reply-To: <oEZCohkYMaHSHUtCuUYzi7wkq7QlRePKovcli9NLQFiNeKvePhnyNGzY_i7RSPQrNseaA7DQtHdizEpXOU0Wsm9pTY1mTyJsl93JULj2xAE=@protonmail.com>
Message-ID: <C61W3H1XWNZW.20ID3FRCKEQ72@homura>

On Thu Oct 1, 2020 at 5:55 PM EDT,  wrote:
> - I don't specify a file/storage format

Yeah, it's not necessary for us to standardize, but for what it's worth
at least one other client has implemented my known_hosts format and I
moved it to a more general location (~/.local/share/gemini), so we have
a chance to establish a software agnostic trust store if we so desire.

> - The cert fingerprint is generated from just the SPKI section of the
> cert, not the entire thing. See the post for rationale.

Aye, your rationale is good. Like I mentioned, the reason I hash the
whole thing is to match the output of openssl x509 -sha512 -fingerprint,
so that it's easier to independently verify the fingerprint.

The ability for the server operator to replace the cert with a fresh one
with the same PK and have the TOFU entry remain trusted is interesting,
but seems fraught with some risk. In any case, I'm of the opinion that
operators should never directly handle certificate maintenance in a TOFU
system.

> - The port is also stored (host vs hostname) so that different ports can
> use different certs

Good call, I'll think about this.

> - I mention SHA-256, but that's just an implementation detail

I just went with SHA-256 because I don't expect these files to be
hand-edited often and the hash, while longer and more cumbersome, is
more likely to be useful for longer.

> I also noticed that your flow doesn't seem to update the host data if
> the cert has expired, it just allows the request to continue. I assume
> that's an error? Or maybe I'm misreading.

The first step is to validate the certificate independently of the trust
store. If it has expired, it would fail this step. Other things checked
here include the valid hostnames, desired hashing algorithms, or
anything else you find it useful to validate. Technically we don't even
need to store the expiration.

So yeah, the known hosts data does not get updated when the cert
expires, but the expired cert would not be trusted anyway.

> Would be happy to hear about what you think of my recommendations! I
> hope they're useful, I've been trying to spread them on Gemini since I
> wrote them.

Thanks for sharing! I'll add a link to my article.

From mieum at tilde.team  Sat Oct  3 08:26:01 2020
From: mieum at tilde.team (mieum)
Date: Sat, 03 Oct 2020 16:26:01 +0900
Subject: Asian Text in URLs
Message-ID: <C632SMCUEJ2E.3RW5RALSWIXNJ@maclibre>

Hi Everyone,

I recently decided to start an experimental Gemlog written in Korean. I
found, however, that some clients do not like having Asian text in the
path of the URL---either as the name of a folder or a file.

What is the general consensus about non-latin characters in URLs? The
Gemini Spec doesn't say anything that would lead me to believe I
shouldn't name my files and folders in Korean. Also, for most clients it
is apparently a non-issue. 

For an example, you can point your client to gemini://namu.blue/??/

Some clients will crash, some will not attempt to load the page, and
some will just return a Permanent Failure. Some will even crash 
attempting to parse the link to that page on gemini://namu.blue/. 

Anyway, I just wanted to see what everyone thinks about the best 
practice in this situation. 

Thanks!
~mieum

gemini://rawtext.club/~mieum/

From sandra.snan at idiomdrottning.org  Sat Oct  3 08:52:54 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Sat, 03 Oct 2020 09:52:54 +0200
Subject: Asian Text in URLs
In-Reply-To: <C632SMCUEJ2E.3RW5RALSWIXNJ@maclibre>
References: <C632SMCUEJ2E.3RW5RALSWIXNJ@maclibre>
Message-ID: <87362v21bd.fsf@idiomdrottning.org>

https://stackoverflow.com/questions/2742852/unicode-characters-in-urls
Gemini uses URLs.

So ? ??, but, percent encoded.

"mieum" <mieum at tilde.team> writes:

> Hi Everyone,
>
> I recently decided to start an experimental Gemlog written in Korean. I
> found, however, that some clients do not like having Asian text in the
> path of the URL---either as the name of a folder or a file.
>
> What is the general consensus about non-latin characters in URLs? The
> Gemini Spec doesn't say anything that would lead me to believe I
> shouldn't name my files and folders in Korean. Also, for most clients it
> is apparently a non-issue. 
>
> For an example, you can point your client to gemini://namu.blue/??/
>
> Some clients will crash, some will not attempt to load the page, and
> some will just return a Permanent Failure. Some will even crash 
> attempting to parse the link to that page on gemini://namu.blue/. 
>
> Anyway, I just wanted to see what everyone thinks about the best 
> practice in this situation. 
>
> Thanks!
> ~mieum
>
> gemini://rawtext.club/~mieum/

From sean at conman.org  Sat Oct  3 08:53:17 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 3 Oct 2020 03:53:17 -0400
Subject: Asian Text in URLs
In-Reply-To: <C632SMCUEJ2E.3RW5RALSWIXNJ@maclibre>
References: <C632SMCUEJ2E.3RW5RALSWIXNJ@maclibre>
Message-ID: <20201003075317.GA17454@brevard.conman.org>

It was thus said that the Great mieum once stated:
> Hi Everyone,
> 
> I recently decided to start an experimental Gemlog written in Korean. I
> found, however, that some clients do not like having Asian text in the
> path of the URL---either as the name of a folder or a file.
> 
> What is the general consensus about non-latin characters in URLs? 

  The actual specification for URLs is RFC-3986, and that lists the valid
characters for the path portion of a URL, which are:

	abcdefghijklmnopqrstuvwxyz
	ABCDEFGHIJKLMNOPQRSTUVWXYZ
	0123456789
	-._~
	!$&'()*+,;=:@

  ANY OTHER CHARACTER has to be percent-encoded.  


> For an example, you can point your client to gemini://namu.blue/??/

  It should be:

	gemini://namu.blue/%EC%8C%8D%EB%A1%9D/

The server will then have to decode the percent-encoded data to get the
proper file to use.
  
> Anyway, I just wanted to see what everyone thinks about the best 
> practice in this situation. 

  Ensure you are using UTF-8 on the server, and percent-encode the path when
generating the URL.

  -spc


From mieum at tilde.team  Sat Oct  3 09:03:04 2020
From: mieum at tilde.team (mieum)
Date: Sat, 03 Oct 2020 17:03:04 +0900
Subject: Asian Text in URLs
In-Reply-To: <87362v21bd.fsf@idiomdrottning.org>
Message-ID: <C633KZJLS0BJ.215IWB4LUY70U@maclibre>

Thank you, Sandra! I was unaware of this!
Sorry to ask such a basic question here!

~mieum

From mieum at tilde.team  Sat Oct  3 09:05:40 2020
From: mieum at tilde.team (mieum)
Date: Sat, 03 Oct 2020 17:05:40 +0900
Subject: Asian Text in URLs
In-Reply-To: <20201003075317.GA17454@brevard.conman.org>
Message-ID: <C633MYYXUTHR.2S9F0R683VTB9@maclibre>

Thanks Sean, I appreciate your thorough response! I'll look into
properly encoding everything :)

From gustavo at gsthnz.com  Sat Oct  3 15:06:42 2020
From: gustavo at gsthnz.com (Gustavo Heinz)
Date: Sat, 03 Oct 2020 11:06:42 -0300
Subject: [ANN] Satellite, yet another gemini server
Message-ID: <C63BBEE0FQPP.DNV2H62RBN53@valkyrie>

Hi there,

I just "finished" creating a gemini server to serve my own
geminilog on gemini://gsthnz.com

https://sr.ht/~gsthnz/satellite

It's passing the gemini-diagnostics test suite from michael-lazar on
github.

There's some improvements to be made still, one of them is the automatic
management of self-signed certificates. The idea is to be super simple
to use, only requiring a root directory to serve and a domain to work,
and everything else is managed for you.

I had A LOT of fun making this.

Hope you guys like it!

--
Gustavo Heinz

From sandra.snan at idiomdrottning.org  Mon Oct  5 09:25:46 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Mon, 05 Oct 2020 10:25:46 +0200
Subject: Asian Text in URLs
In-Reply-To: <87362v21bd.fsf@idiomdrottning.org>
References: <C632SMCUEJ2E.3RW5RALSWIXNJ@maclibre>
 <87362v21bd.fsf@idiomdrottning.org>
Message-ID: <87lfglyt85.fsf@idiomdrottning.org>

Now, I wouldn't be opposed to Gemini instead using iris with utf8mb4
supported both RTL and LTR. I rail against change on here but that would
be a welcome change. There are some severe security risks that come with
such a change so it's not undertaken lightly. As discussed earlier with
the NN/.. issue.

Sandra Snan <sandra.snan at idiomdrottning.org> writes:

> https://stackoverflow.com/questions/2742852/unicode-characters-in-urls
> Gemini uses URLs.
>
> So ? ??, but, percent encoded.
>
> "mieum" <mieum at tilde.team> writes:
>
>> Hi Everyone,
>>
>> I recently decided to start an experimental Gemlog written in Korean. I
>> found, however, that some clients do not like having Asian text in the
>> path of the URL---either as the name of a folder or a file.
>>
>> What is the general consensus about non-latin characters in URLs? The
>> Gemini Spec doesn't say anything that would lead me to believe I
>> shouldn't name my files and folders in Korean. Also, for most clients it
>> is apparently a non-issue. 
>>
>> For an example, you can point your client to gemini://namu.blue/??/
>>
>> Some clients will crash, some will not attempt to load the page, and
>> some will just return a Permanent Failure. Some will even crash 
>> attempting to parse the link to that page on gemini://namu.blue/. 
>>
>> Anyway, I just wanted to see what everyone thinks about the best 
>> practice in this situation. 
>>
>> Thanks!
>> ~mieum
>>
>> gemini://rawtext.club/~mieum/

From ranfdev at gmail.com  Tue Oct  6 15:21:39 2020
From: ranfdev at gmail.com (Lorenzo Miglietta)
Date: Tue, 06 Oct 2020 16:21:39 +0200
Subject: [ANN] New gtk client, with colors
In-Reply-To: <230057340.65862.1600980049934@office.mailbox.org>
References: <230057340.65862.1600980049934@office.mailbox.org>
Message-ID: <27996e0279c21a598cb87f477ce8903af8982904.camel@gmail.com>

I've updated the program. Now you can change fonts and disable colors.
Also, it now caches pages in the history.


From mail at jannisr.de  Wed Oct  7 11:16:08 2020
From: mail at jannisr.de (Jannis R)
Date: Wed, 7 Oct 2020 12:16:08 +0200
Subject: Gemini ALPN ID
Message-ID: <0DA55B64-A977-4F84-B14B-BC75FA27D520@jannisr.de>

hey,

I was wondering what you think about using TLS with ALPN [1][2]? It eliminate doubt about which protocols a server speaks.

In my Node.js Gemini client & server [3], I use the ALPN protocol identification sequence `gemini` for now, but that seems to be incompatible with all other clients & servers not using it. [4]

Jannis

[1] https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation
[2] https://tools.ietf.org/html/rfc7301
[3] https://github.com/derhuerst/gemini
[4] https://github.com/derhuerst/gemini/issues/5

From boringcactus at gmail.com  Wed Oct  7 21:07:22 2020
From: boringcactus at gmail.com (boringcactus)
Date: Wed, 7 Oct 2020 14:07:22 -0600
Subject: [ANN] gemifedi, a gemini frontend to the fediverse
Message-ID: <24b0f9b9-851d-a8e8-535d-3ec92bc5de51@gmail.com>

if you use Mastodon or Pleroma and you want to be able to use those over 
gemini, i built a thing to allow for that.

source code: https://git.sr.ht/~boringcactus/gemifedi
demo instance: gemini://gemifedi.boringcactus.com/about

the code is bad - partially because tls libraries with good client cert 
support are rare, and partially because i'm too lazy to do anything the 
right way - but it *works*. mostly.

(if your client of choice hasn't implemented client certs yet, you can 
run gemifedi locally with the --horribly-insecure flag and it will just 
trust all requests. don't do that for very long at a time, though.)

as an exercise, i think designing gemifedi was really interesting: 
gemini has constraints i'm not used to working within, and i had to get 
creative to build what i wanted. for example, while drafting this 
paragraph in this email, i thought of a better solution to the problem 
of "well if everything is GET then everything needs to be idempotent" 
than i previously had.

i'm not sure how gemini-ish this sort of service is, but given that it's 
possible to build with gemini as it already exists, it might be a useful 
data point in ongoing discussions about building Applications? on top of 
gemini.

-??

From sandra.snan at idiomdrottning.org  Thu Oct  8 11:48:42 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Thu, 08 Oct 2020 12:48:42 +0200
Subject: [ANN] gemifedi, a gemini frontend to the fediverse
In-Reply-To: <24b0f9b9-851d-a8e8-535d-3ec92bc5de51@gmail.com>
References: <24b0f9b9-851d-a8e8-535d-3ec92bc5de51@gmail.com>
Message-ID: <87blhdvvqt.fsf@idiomdrottning.org>

It kinda fails to find the master branch. Maybe that's just me being
pebkac on cargo.

boringcactus <boringcactus at gmail.com> writes:

> if you use Mastodon or Pleroma and you want to be able to use those over 
> gemini, i built a thing to allow for that.
>
> source code: https://git.sr.ht/~boringcactus/gemifedi
> demo instance: gemini://gemifedi.boringcactus.com/about
>
> the code is bad - partially because tls libraries with good client cert 
> support are rare, and partially because i'm too lazy to do anything the 
> right way - but it *works*. mostly.
>
> (if your client of choice hasn't implemented client certs yet, you can 
> run gemifedi locally with the --horribly-insecure flag and it will just 
> trust all requests. don't do that for very long at a time, though.)
>
> as an exercise, i think designing gemifedi was really interesting: 
> gemini has constraints i'm not used to working within, and i had to get 
> creative to build what i wanted. for example, while drafting this 
> paragraph in this email, i thought of a better solution to the problem 
> of "well if everything is GET then everything needs to be idempotent" 
> than i previously had.
>
> i'm not sure how gemini-ish this sort of service is, but given that it's 
> possible to build with gemini as it already exists, it might be a useful 
> data point in ongoing discussions about building Applications? on top of 
> gemini.
>
> -??

From premysl at vyhnal.net  Thu Oct  8 13:19:44 2020
From: premysl at vyhnal.net (=?UTF-8?Q?P=C5=99emysl_Vyhnal?=)
Date: Thu, 8 Oct 2020 14:19:44 +0200
Subject: [ANN] gemifedi, a gemini frontend to the fediverse
In-Reply-To: <87blhdvvqt.fsf@idiomdrottning.org>
References: <24b0f9b9-851d-a8e8-535d-3ec92bc5de51@gmail.com>
 <87blhdvvqt.fsf@idiomdrottning.org>
Message-ID: <CAJystH2j7k-bso7wzksXmLHwqA-TJuNx2EhkMAUjofZpAf-6Vg@mail.gmail.com>

Looks like the branch is called main:

cargo install --git https://git.sr.ht/~boringcactus/gemifedi --branch main



On Thu, Oct 8, 2020 at 12:49 PM Sandra Snan <sandra.snan at idiomdrottning.org>
wrote:

> It kinda fails to find the master branch. Maybe that's just me being
> pebkac on cargo.
>
> boringcactus <boringcactus at gmail.com> writes:
>
> > if you use Mastodon or Pleroma and you want to be able to use those over
> > gemini, i built a thing to allow for that.
> >
> > source code: https://git.sr.ht/~boringcactus/gemifedi
> > demo instance: gemini://gemifedi.boringcactus.com/about
> >
> > the code is bad - partially because tls libraries with good client cert
> > support are rare, and partially because i'm too lazy to do anything the
> > right way - but it *works*. mostly.
> >
> > (if your client of choice hasn't implemented client certs yet, you can
> > run gemifedi locally with the --horribly-insecure flag and it will just
> > trust all requests. don't do that for very long at a time, though.)
> >
> > as an exercise, i think designing gemifedi was really interesting:
> > gemini has constraints i'm not used to working within, and i had to get
> > creative to build what i wanted. for example, while drafting this
> > paragraph in this email, i thought of a better solution to the problem
> > of "well if everything is GET then everything needs to be idempotent"
> > than i previously had.
> >
> > i'm not sure how gemini-ish this sort of service is, but given that it's
> > possible to build with gemini as it already exists, it might be a useful
> > data point in ongoing discussions about building Applications? on top of
> > gemini.
> >
> > -??
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201008/3d3b8143/attachment.htm>

From boringcactus at gmail.com  Thu Oct  8 17:27:31 2020
From: boringcactus at gmail.com (boringcactus)
Date: Thu, 8 Oct 2020 10:27:31 -0600
Subject: [ANN] gemifedi, a gemini frontend to the fediverse
In-Reply-To: <CAJystH2j7k-bso7wzksXmLHwqA-TJuNx2EhkMAUjofZpAf-6Vg@mail.gmail.com>
References: <24b0f9b9-851d-a8e8-535d-3ec92bc5de51@gmail.com>
 <87blhdvvqt.fsf@idiomdrottning.org>
 <CAJystH2j7k-bso7wzksXmLHwqA-TJuNx2EhkMAUjofZpAf-6Vg@mail.gmail.com>
Message-ID: <48876c28-f83e-41a6-4a8f-fe3028596afd@gmail.com>

On 2020-10-08 6:19 AM, P?emysl Vyhnal wrote:
> Looks like the branch is called main:
> 
> cargo install --git https://git.sr.ht/~boringcactus/gemifedi --branch main

oh, i'll go make the docs reflect that. didn't know cargo assumed the 
default branch was always named master.


From sandra.snan at idiomdrottning.org  Thu Oct  8 23:04:20 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Fri, 09 Oct 2020 00:04:20 +0200
Subject: Dioscuri, another application layer protocol
In-Reply-To: <96D71F46-6FCC-4319-8888-366A2F788270@gmail.com>
Message-ID: <87v9fkv0gr.fsf@idiomdrottning.org>

June '00? Wow, I was later to the Gemini party than I thought.

Sandra

PS I feel bad for shooting down Dioscuri so harshly, I hate being such a
parade-rainer. jcowan is one of my idols


Petite Abeille <petite.abeille at gmail.com> writes:

>> On Sep 28, 2020, at 15:07, John Cowan <cowan at ccil.org> wrote:
>> 
>> I read through as much of this year's archives as I could, and I haven't seen anything bidirectional like this.  Please point me to appropriate emails if there are any.
>> 
>
>
> Look for inimeg (gemini spelled backward :P, circa June '00, re: gemini+submit:// (was Re: Uploading Gemini content ) )

From cowan at ccil.org  Fri Oct  9 03:17:31 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 8 Oct 2020 22:17:31 -0400
Subject: Dioscuri, another application layer protocol
In-Reply-To: <87r1qj2qes.fsf@idiomdrottning.org>
References: <CAD2gp_R79Os_ur+fz0fb+Rvo6tTk1BWwTLZQ8br=jasu1aoBRA@mail.gmail.com>
 <87tuvi4der.fsf@idiomdrottning.org> <878scuw09h.fsf@dorothy.carcosa.net>
 <87r1qj2qes.fsf@idiomdrottning.org>
Message-ID: <CAD2gp_TpPGy09Qt_R9r50k6q-AYsQ7UinEKgsLzYFSDB2vkMBg@mail.gmail.com>

On Wed, Sep 30, 2020 at 12:14 PM Sandra Snan <sandra.snan at idiomdrottning.org>
wrote:


> The good old days when we had separate apps for everything was paradise
> for me, and, well, still is because I can still happily live in that
> world in my li'l Debian bubble.
>

I live in that world too.  But there are only a few of them: ftp, ssh and
friends, mail, etc.  I have no trouble learning them all.  But they are
very inconsistent, much like Posix command-line tools.


> As an example, email exploded once web-interfaces to email became
> available.
>

I'm not sure if you think that's good or bad.  See <
http://www.catb.org/jargon/html/S/September-that-never-ended.html>.


> If Gemini and adjacent protocols turn into a general-purpose application
> platform, there need to be some sort of purpose or guiding light or
> boundaries or reason for starting a new pile instead of working on the
> already existing pile of junk.
>

Well, why work on Gemini instead of just using HTML and HTTP?  Simplicity
Gemini and text/gemini are simple enough without being too simple.  I
believe that Dioscuri is too.


> Dioscuri doesn't have a client-side, server-served programming language.
>

There's no reason Gemini can't ship JavaScript, or Scheme for that matter.
"JavaScript: The Good Parts" actually describes a very nice little language.

Talk about complexity in the client! With SSH I can have an app on the
> remote and call it from my client.
>
> ssh some-server-name 'ls|tail'
>

Yes, you can, but the server is at risk if it allows you to ssh and run
arbitrary shell commands.  Posix systems are better defended than most, but
the firewall is far from complete.

*If* there were to be a new general-purpose application platform
> along-side Gemini, client side should be "dumb" and the protocol (i.e.
> the interface between client and server) also needs to be simple and
> specific.
>

The trouble is that for decades now almost all the CPU power in the world
has been client-side, most of it underused.  Downloadable smart clients
keep the strain off the servers.  That fact will be with us for the
foreseeable future (phones are somewhat weaker, but there are a lot more of
them).


> A handful of standard UI elements communicating with server back and
> forth in a straight-forward way according to one specific protocol.
>

That's how HTML/HTTP began, and we know where that led to.  I was striving
for something different, *starting* from a smart client, downloadable or
not, and a fairly dumb server, which is where the web is moving now (see
"single-page application").  In particular, this means that the client
doesn't have to be a GUI or a TUI like lynx/w3m/etc.  It can be a CLI or a
batch job or any number of other things.  "Pages? What pages?  We don't
need no steenking pages!"

Intercooler does look interesting: I'm going to explore it further.

I once saw an application that had been converted from 3270 to a Windows
desktop product. I had been asked to give it a quick tryout to see how the
UI worked.  I went back to the programmers and told them that no Windows
user would put up with this complete lack of control.  The back end needed
to be event-driven.  Of course, the browser restored the 3270 model
completely.

PS I feel bad for shooting down Dioscuri so harshly, I hate being such a
> parade-rainer. jcowan is one of my idols


No problem.  Idols often have feet of clay, after all.




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Using RELAX NG compact syntax to develop schemas is one of the simple
pleasures in life....          --Jeni Tennison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201008/054f44b9/attachment.htm>

From sandra.snan at idiomdrottning.org  Fri Oct  9 10:14:14 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Fri, 09 Oct 2020 11:14:14 +0200
Subject: [ANN] gemifedi, a gemini frontend to the fediverse
In-Reply-To: <CAJystH2j7k-bso7wzksXmLHwqA-TJuNx2EhkMAUjofZpAf-6Vg@mail.gmail.com>
References: <24b0f9b9-851d-a8e8-535d-3ec92bc5de51@gmail.com>
 <87blhdvvqt.fsf@idiomdrottning.org>
 <CAJystH2j7k-bso7wzksXmLHwqA-TJuNx2EhkMAUjofZpAf-6Vg@mail.gmail.com>
Message-ID: <87lfgfvk0p.fsf@idiomdrottning.org>

This is awesome! Also I didn't know cargo could do this. So this means
that if I wanna make mods, all I have to do is make them in a repo?
For example I wanna change URLs that lead to stuff that is bihosted on
https and gemini to be Gemini URLs.

P?emysl Vyhnal <premysl at vyhnal.net> writes:

> Looks like the branch is called main:
>
> cargo install --git https://git.sr.ht/~boringcactus/gemifedi --branch main
>
>
>
> On Thu, Oct 8, 2020 at 12:49 PM Sandra Snan <sandra.snan at idiomdrottning.org>
> wrote:
>
>> It kinda fails to find the master branch. Maybe that's just me being
>> pebkac on cargo.
>>
>> boringcactus <boringcactus at gmail.com> writes:
>>
>> > if you use Mastodon or Pleroma and you want to be able to use those over
>> > gemini, i built a thing to allow for that.
>> >
>> > source code: https://git.sr.ht/~boringcactus/gemifedi
>> > demo instance: gemini://gemifedi.boringcactus.com/about
>> >
>> > the code is bad - partially because tls libraries with good client cert
>> > support are rare, and partially because i'm too lazy to do anything the
>> > right way - but it *works*. mostly.
>> >
>> > (if your client of choice hasn't implemented client certs yet, you can
>> > run gemifedi locally with the --horribly-insecure flag and it will just
>> > trust all requests. don't do that for very long at a time, though.)
>> >
>> > as an exercise, i think designing gemifedi was really interesting:
>> > gemini has constraints i'm not used to working within, and i had to get
>> > creative to build what i wanted. for example, while drafting this
>> > paragraph in this email, i thought of a better solution to the problem
>> > of "well if everything is GET then everything needs to be idempotent"
>> > than i previously had.
>> >
>> > i'm not sure how gemini-ish this sort of service is, but given that it's
>> > possible to build with gemini as it already exists, it might be a useful
>> > data point in ongoing discussions about building Applications? on top of
>> > gemini.
>> >
>> > -??
>>

From luke at marmaladefoo.com  Fri Oct  9 23:22:22 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 09 Oct 2020 23:22:22 +0100
Subject: [ANN] GemiNaut 0.8.8 is released
Message-ID: <5F80E29E.9050806@marmaladefoo.com>

Hi All

Just to let you know there is a new release out this week of GemiNaut, 
the user friendly Gemini client for Windows.

The main changes in this release are:

1. Simple website browsing - view most simple websites directly in 
GemiNaut, and only launch your system browser when you have to. Uses 
Html2Gmi utility to convert web pages to GMI files, or you can also 
connect to an Http-to-gemini proxy such as Duckling. A good majority of 
sites linked from Gemini are within the so called Small Web (document 
not application centric sites), and these will generally display well 
enough to get a good sense of the content.

2. Signed application binary and new installer. Some folk reported 
getting false positives from anti-virus utilities, incorrectly marking 
GemiNaut as malware. The official installer and application binary are 
now signed. So it should produce fewer scary warnings when you install 
and run it.

3. Minor UI improvements, including better readability with increased 
line spacing, scroll bars on preformatted areas only added on hover, can 
display text/html pages on Gemini sites.

Further details and links to installer and github repo on project 
website and gemsite

https://www.marmaladefoo.com/pages/geminaut

gemini://gemini.marmaladefoo.com/geminaut/

Any feedback and bug reports welcomed.

Best Wishes

  - Luke


From ehmry at posteo.net  Sat Oct 10 11:06:58 2020
From: ehmry at posteo.net (Emery)
Date: Sat, 10 Oct 2020 12:06:58 +0200
Subject: [ANN] Collection of Gemini related Nix packages
Message-ID: <bc51a0f1-0f62-49bd-b177-6c7b19c82cf3@posteo.net>

I've created a collection of Gemini software that can be installed with
the Nix package manager. Most of these packages are in the main Nix
repositiory but there are collected here for convience. Since the Gemini
protocol is still experimental, it may be better to first submit packages
to a staging area like this.

=> https://git.sr.ht/~ehmry/gemini-flake

I don't have time to package every client and server, but I'm happy to
accept patches, and I can also review packages in the main repository.

Also, for anyone using NixOS who hasn't noticed, there is a configuration
module for molly-brown.
=> gemini://gemini.spam.works/~emery/nixos-hosting.gmi

The current dump of the package list:
```
git+https://git.sr.ht/~ehmry/gemini-flake?ref=master&rev=d67a4e923b9bf9e37b9b302ed4face2c491a1755
????nixosModules
?   ????molly-brown: NixOS module
????packages
    ????aarch64-linux
    ?   ????amfora: package 'amfora-1.5.0'
    ?   ????asuka: package 'asuka-0.8.1'
    ?   ????av-98: package 'av-98-1.0.2dev'
    ?   ????castor: package 'castor-0.8.16'
    ?   ????gacme: package 'gacme-unstable-2020-07-07'
    ?   ????kristall: package 'kristall-0.3'
    ?   ????molly-brown: package 'molly-brown-unstable-2020-07-06'
    ?   ????ncgopher: package 'ncgopher-0.1.5'
    ????x86_64-linux
        ????amfora: package 'amfora-1.5.0'
        ????asuka: package 'asuka-0.8.1'
        ????av-98: package 'av-98-1.0.2dev'
        ????castor: package 'castor-0.8.16'
        ????gacme: package 'gacme-unstable-2020-07-07'
        ????kristall: package 'kristall-0.3'
        ????molly-brown: package 'molly-brown-unstable-2020-07-06'
        ????ncgopher: package 'ncgopher-0.1.5'
```

From skyjake at dengine.net  Sat Oct 10 13:56:49 2020
From: skyjake at dengine.net (skyjake)
Date: Sat, 10 Oct 2020 15:56:49 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
Message-ID: <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>

Hello all,

Here's a brief update on what's been happening with Lagrange since the initial v0.1 release.

I've just released v0.4 today with preliminary audio playback support. You can now listen to Ogg Vorbis and WAV files using an inline audio player. It works the same way as the image viewer.

=> https://skyjake.fi/@jk/105010413773282229  Screenshot of audio player UI

I call this preliminary because it still lacks basic features like volume control and seeking. The plan is to add more audio codecs as well, although that will require adding new (optional) dependencies to the build.

The other notable change in v0.4 is support for Windows HiDPI displays, including respecting the Windows UI scaling factor.

In the earlier builds v0.2 and v0.3, the new features were:

* saving files to the downloads folder
* quotes have an icon for clearer visual distinction
* macOS touch bar support
* improved context menus and text selection
* mailto links
* style customization: font, line width, color saturation
* page outline that appears when hovering over the scroll bar (off by default)
* site icon and heading in the left margin (wide windows)

=> https://skyjake.fi/@jk/104938360727578010  Screenshot of site icon and hover outline

Binaries are available for Windows (7 or later, 64-bit only) and macOS 10.13+:

=> https://git.skyjake.fi/skyjake/lagrange/releases  Prebuilt binaries, source repo
=> gemini://skyjake.fi/lagrange/  Project page

--jaakko


From benulo at systemli.org  Sat Oct 10 16:07:16 2020
From: benulo at systemli.org (Ben)
Date: Sat, 10 Oct 2020 18:37:16 +0330
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
Message-ID: <815651c1-80d3-b6b5-b71d-25bc130da572@systemli.org>

On 10/10/20 4:26 PM, skyjake wrote:
> audio playback support

This is really nice! I tested it on my own site and it starts playback 
while the file is downloading, so it's really streaming. :)

I ran into a quirk where if I tried to open another ogg file one one was 
already playing, I get two players playing simultaneously. When I try to 
hit x to close the first one it doesn't close the player it just 
restarts it as if I had clicked on the link again.

Ben

-- 
gemini://kwiecien.us/

From skyjake at dengine.net  Sat Oct 10 18:58:40 2020
From: skyjake at dengine.net (skyjake)
Date: Sat, 10 Oct 2020 20:58:40 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <815651c1-80d3-b6b5-b71d-25bc130da572@systemli.org>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <815651c1-80d3-b6b5-b71d-25bc130da572@systemli.org>
Message-ID: <39628D15-FAFF-4C76-9D36-72614BF128EB@dengine.net>

On 10. Oct 2020, at 18:07, Ben <benulo at systemli.org> wrote:

> I ran into a quirk where if I tried to open another ogg file one one was already playing, I get two players playing simultaneously. When I try to hit x to close the first one it doesn't close the player it just restarts it as if I had clicked on the link again.

Ah, it appears that it doesn't let you close a player that's still streaming more content. I'll fix it... 

Thanks for testing!

--jaakko

From cowan at ccil.org  Sat Oct 10 19:59:17 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 10 Oct 2020 14:59:17 -0400
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
Message-ID: <CAD2gp_T=A00zzKD-h345xxS+u2KPdtXXDnE2+xFmhA5W0BzRTA@mail.gmail.com>

I just wanted to say that I tried this client for the first time today on a
Mac, and it is indeed classically beautiful: ????? ???? (nothing in excess)
as Apollo said at Delphi.  I found everything I needed or wanted and
nothing I didn't, or more accurately nothing that I couldn't see someone
else who is aligned with the spirit of Gemini wanting, like dark mode.

Nevertheless, as a visually impaired person (not so much so that I need a
screen reader, however), I would ask for two things:

1) A mode in which the background is white (which you already have) and all
colors except in icons are mapped to black.  Even though your colors are
subtle, black print on white paper, as God and Gutenburg intended, is the
most readable.  In particular, grayscale text blends into the background,
and using less saturated colors in subheadings combined with smaller font
sizes, makes them hard, harder, hardest to interpret.  (Colors in icons are
fine: I don't have to read them, just look at them.)

2) A nice serif font.  Characters with serifs are much easier to recognize
because the letters look more different.  The worst case for sans-serif
fonts is l (lower case L) and I (uppercase I).  Here they are together:
IlIIl.  That looks in a sans-serif font like five tally marks, but in fact
it is I-L-I-I-L with lower case L, as a serif font will show.

There is nothing inherently old-fashioned about serif fonts:  Georgia
(which is web-safe) is a good candidate for lightweight minimalism, and so
are any of those shown at <
https://www.dtelepathy.com/blog/design/21-stunning-serif-fonts-websites>.
Whatever floats your boat, but with serifs!

Without these things I have to magnify the text even more than I normally
do (150%) and get less and less content per screen.  This is a matter of
pure practicality: I'm not asking for the ability to render pages in Comic
Sans <http://www.identifont.com/find?font=comic+sans&q=Go> or in STOP <
http://www.identifont.com/show?374>, a font which combines the virtues of
ugliness with those of illegibility.

A very minor third point:

3) It would be nice if, after opening a new tab, the cursor was in the
address bar.  This is convenient:  Cmd-T immediately followed by typing the
URL, without having to mouse about.


On Sat, Oct 10, 2020 at 8:56 AM skyjake <skyjake at dengine.net> wrote:

> Hello all,
>
> Here's a brief update on what's been happening with Lagrange since the
> initial v0.1 release.
>
> I've just released v0.4 today with preliminary audio playback support. You
> can now listen to Ogg Vorbis and WAV files using an inline audio player. It
> works the same way as the image viewer.
>
> => https://skyjake.fi/@jk/105010413773282229  Screenshot of audio player
> UI
>
> I call this preliminary because it still lacks basic features like volume
> control and seeking. The plan is to add more audio codecs as well, although
> that will require adding new (optional) dependencies to the build.
>
> The other notable change in v0.4 is support for Windows HiDPI displays,
> including respecting the Windows UI scaling factor.
>
> In the earlier builds v0.2 and v0.3, the new features were:
>
> * saving files to the downloads folder
> * quotes have an icon for clearer visual distinction
> * macOS touch bar support
> * improved context menus and text selection
> * mailto links
> * style customization: font, line width, color saturation
> * page outline that appears when hovering over the scroll bar (off by
> default)
> * site icon and heading in the left margin (wide windows)
>
> => https://skyjake.fi/@jk/104938360727578010  Screenshot of site icon and
> hover outline
>
> Binaries are available for Windows (7 or later, 64-bit only) and macOS
> 10.13+:
>
> => https://git.skyjake.fi/skyjake/lagrange/releases  Prebuilt binaries,
> source repo
> => gemini://skyjake.fi/lagrange/  Project page
>
> --jaakko
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201010/42cee1d0/attachment.htm>

From colecmac at protonmail.com  Sun Oct 11 00:32:41 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 10 Oct 2020 23:32:41 +0000
Subject: Gemini ALPN ID
In-Reply-To: <0DA55B64-A977-4F84-B14B-BC75FA27D520@jannisr.de>
References: <0DA55B64-A977-4F84-B14B-BC75FA27D520@jannisr.de>
Message-ID: <Owx2JnXa-UAC3YvtKe50ct6dxqRgjYqsoMg8-sxCNEegRhz53Bkoe5bqGheW3YOMBkqoQrlmfUU1NtmUmaI5Oi8lAV9FyoKO2FJ_oCt2_YA=@protonmail.com>

It seems like a hack that just exists so that HTTP2 can work
efficiently while still keeping the old http:// scheme. What
would the purpose be for Gemini, especially with it having its
own port?

makeworld

From linde.philip at gmail.com  Sun Oct 11 02:53:44 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sun, 11 Oct 2020 03:53:44 +0200
Subject: Gemini ALPN ID
In-Reply-To: <Owx2JnXa-UAC3YvtKe50ct6dxqRgjYqsoMg8-sxCNEegRhz53Bkoe5bqGheW3YOMBkqoQrlmfUU1NtmUmaI5Oi8lAV9FyoKO2FJ_oCt2_YA=@protonmail.com>
References: <0DA55B64-A977-4F84-B14B-BC75FA27D520@jannisr.de>
 <Owx2JnXa-UAC3YvtKe50ct6dxqRgjYqsoMg8-sxCNEegRhz53Bkoe5bqGheW3YOMBkqoQrlmfUU1NtmUmaI5Oi8lAV9FyoKO2FJ_oCt2_YA=@protonmail.com>
Message-ID: <20201011035344.599d2a6b09e7b2e06ed49b76@gmail.com>

On Sat, 10 Oct 2020 23:32:41 +0000
colecmac at protonmail.com wrote:

> It seems like a hack that just exists so that HTTP2 can work
> efficiently while still keeping the old http:// scheme.

Agreed. The client already knows that it has accessed a gemini:// URI.
The server knows what the client is asking for. There is no need change
protocol from that point, thus no ALPN necessary. From what I
understand, ALPN was invented (by Google) pretty much just for clients
and servers to decide early whether to user HTTP2 or not. For as long
as there's no Gemini 3.11 or whatever, there's nothing to negotiate.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201011/397ea15a/attachment-0001.sig>

From mailinglists at ngalt.com  Sun Oct 11 03:04:39 2020
From: mailinglists at ngalt.com (mailinglists at ngalt.com)
Date: Sat, 10 Oct 2020 19:04:39 -0700
Subject: =?UTF-8?Q?Bug_reports:_Multiple_spaces_in_links;
 _=E2=8C=98S_unreliable_(?=
 =?UTF-8?Q?was:_Re:_[ANN]_Lagrange_-_A_Beautiful_Gemini_Client)?=
In-Reply-To: <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
Message-ID: <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>

On Sat, Oct 10, 2020, at 5:56 AM, skyjake wrote:
> Hello all,
> 
> Here's a brief update on what's been happening with Lagrange since the 
> initial v0.1 release.
> 
> I've just released v0.4 today with preliminary audio playback support. 
> You can now listen to Ogg Vorbis and WAV files using an inline audio 
> player. It works the same way as the image viewer.

First and by far the most important, I'd like to echo John Cowan's effusive praise. Lagrange is nothing short of insanely great.

I noticed a couple odd things, though:

First, in the category of "I don't know if it's wrong, but it _is_ different and I'm not sure I like it": I went to <gemini://gemini.circumlunar.space/users/> and multiple spaces in link text are being collapsed into one space. In the source, the link lines look like:

=> / ..
=> 0xgem/ 0xgem/                                                 Jul  7 2020
=> acdw/ acdw/                                                  Jul 25 2020
=> adiabatic/ adiabatic/                                             Oct  6 2020
=> alchemist/ alchemist/                                             Jun 21 2020
=> b/ b/                                                     Oct  6 2020
=> bentsai/ bentsai/                                               Jul  7 2020
=> chance/ chance/                                                Sep  6 2020

In amfora, a command-line TUI client, the dates are right-aligned if you've got a wide-enough terminal, but in Lagrange, multiple spaces are collapsed into one and each line is kind of hard to read because of the raggedyness of it all.

For the second, I noticed that the ASCII art at "midnight.pub" didn't look right compared to amfora. I wanted to check the source text at <gemini://tilde.team/~m15o/> to see what was going on, but when I hit ?S, I got:

```
ERROR SAVING PAGE
Read-only file system
[Continue]
```

I wasn't expecting this error message at all, considering it's (1) only my ~/Downloads and (2) <gemini://gemini.circumlunar.space/users/> downloads just fine to it from Lagrange and (3) amfora saves "~m15o.gmi" just fine there when I hit C-s in it.

?and hm. The ASCII art there isn't backticked. I should go pester the author to wrap it all in

```Midnight
?
```
.

? Nathan

From skyjake at dengine.net  Sun Oct 11 07:56:05 2020
From: skyjake at dengine.net (skyjake)
Date: Sun, 11 Oct 2020 09:56:05 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CAD2gp_T=A00zzKD-h345xxS+u2KPdtXXDnE2+xFmhA5W0BzRTA@mail.gmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <CAD2gp_T=A00zzKD-h345xxS+u2KPdtXXDnE2+xFmhA5W0BzRTA@mail.gmail.com>
Message-ID: <24A7BB9A-BB67-42F0-AC5F-44E5B219424A@dengine.net>

On 10. Oct 2020, at 21:59, John Cowan <cowan at ccil.org> wrote:

> I just wanted to say that I tried this client for the first time today on a Mac, and it is indeed classically beautiful: ????? ???? (nothing in excess) as Apollo said at Delphi.

Thank you!

> 1) A mode in which the background is white (which you already have) and all colors except in icons are mapped to black.

I agree this would be a useful setting. My plan is to add more user-selectable color themes in Preferences, so a high-contrast one can be one of them.

> 2) A nice serif font.

Consider it done. Ultimately I would like to allow picking a custom font, but before that a small set of nice fonts should suffice.

> 3) It would be nice if, after opening a new tab, the cursor was in the address bar.

I have now implemented this in the dev branch.

--jaakko

From skyjake at dengine.net  Sun Oct 11 08:29:45 2020
From: skyjake at dengine.net (skyjake)
Date: Sun, 11 Oct 2020 10:29:45 +0300
Subject: Bug reports: Multiple spaces in links; Cmd+S unreliable (was: Re:
 [ANN] Lagrange - A Beautiful Gemini Client) 
In-Reply-To: <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>
Message-ID: <29DDFE8D-1036-41E7-BAE3-7B7F6D17CB10@dengine.net>

On 11. Oct 2020, at 5:04, mailinglists at ngalt.com wrote:

> First and by far the most important, I'd like to echo John Cowan's effusive praise. Lagrange is nothing short of insanely great.

Thanks, glad to hear you like it. :)

> First, in the category of "I don't know if it's wrong, but it _is_ different and I'm not sure I like it": I went to <gemini://gemini.circumlunar.space/users/> and multiple spaces in link text are being collapsed into one space.

Hmm, interesting. The Gemini spec doesn't seem to weigh in on whitespace normalization in link text (only in regular text lines), although it does say "clients can present links to users in whatever fashion the client author wishes".

The way the right-aligning is done here assumes a fixed-width font. While it isn't appropriate to show all links using a fixed-width font, perhaps this use case of whitespace padding could be detected by the client and it could switch to fixed-width for those links only? Seems a little fiddly, though, since it also assumes a specific line width.

Maybe a better way would be to take the whitespace padding as a signal to align the remaining text separately, although that could get complicated.

> when I hit ?S, I got:
> 
> ```
> ERROR SAVING PAGE
> Read-only file system
> [Continue]
> ```

This is a bug in Lagrange's save path. It gets confused by the tilde in "~m15o" and ignores the Downloads directory set in Preferences. Will fix.

Thanks for reporting!

--jaakko

From cowan at ccil.org  Sun Oct 11 09:01:36 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 11 Oct 2020 04:01:36 -0400
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <24A7BB9A-BB67-42F0-AC5F-44E5B219424A@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <CAD2gp_T=A00zzKD-h345xxS+u2KPdtXXDnE2+xFmhA5W0BzRTA@mail.gmail.com>
 <24A7BB9A-BB67-42F0-AC5F-44E5B219424A@dengine.net>
Message-ID: <CAD2gp_T2F8uG5v1KicAUp_7LoXiwABYHY9RVMd3KsUyUWAs4Lg@mail.gmail.com>

On Sun, Oct 11, 2020 at 2:56 AM skyjake <skyjake at dengine.net> wrote:

> > 1) A mode in which the background is white (which you already have) and
> all colors except in icons are mapped to black.
>
> I agree this would be a useful setting. My plan is to add more
> user-selectable color themes in Preferences, so a high-contrast one can be
> one of them.
>

I notice that in Settings / Colors there is a selector for Saturation with
options Full, Reduced, Minimal, Monochrome.  But this doesn't seem to do
anything.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Rather than making ill-conceived suggestions for improvement based on
uninformed guesses about established conventions in a field of study with
which familiarity is limited, it is sometimes better to stick to merely
observing the usage and listening to the explanations offered, inserting
only questions as needed to fill in gaps in understanding. --Peter Constable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201011/843141d4/attachment.htm>

From jaakko.keranen at iki.fi  Sun Oct 11 08:26:48 2020
From: jaakko.keranen at iki.fi (=?utf-8?Q?Jaakko_Ker=C3=A4nen?=)
Date: Sun, 11 Oct 2020 10:26:48 +0300
Subject: Bug reports: Multiple spaces in links; Cmd+S unreliable (was: Re:
 [ANN] Lagrange - A Beautiful Gemini Client)
In-Reply-To: <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>
Message-ID: <22C1780C-F67D-40BA-8B48-94BF2256CFEA@iki.fi>

On 11. Oct 2020, at 5:04, mailinglists at ngalt.com wrote:

> First and by far the most important, I'd like to echo John Cowan's effusive praise. Lagrange is nothing short of insanely great.

Thanks, glad to hear you like it. :)

> First, in the category of "I don't know if it's wrong, but it _is_ different and I'm not sure I like it": I went to <gemini://gemini.circumlunar.space/users/> and multiple spaces in link text are being collapsed into one space.

Hmm, interesting. The Gemini spec doesn't seem to weigh in on whitespace normalization in link text (only in regular text lines), although it does say "clients can present links to users in whatever fashion the client author wishes".

The way the right-aligning is done here assumes a fixed-width font. While it isn't appropriate to show all links using a fixed-width font, perhaps this use case of whitespace padding could be detected by the client and it could switch to fixed-width for those links only? Seems a little fiddly, though, since it also assumes a specific line width.

Maybe a better way would be to take the whitespace padding as a signal to align the remaining text separately, although that could get complicated.

> when I hit ?S, I got:
> 
> ```
> ERROR SAVING PAGE
> Read-only file system
> [Continue]
> ```

This is a bug in Lagrange's save path. It gets confused by the tilde in "~m15o" and ignores the Downloads directory set in Preferences. Will fix.

Thanks for reporting!

--jaakko

From sir at cmpwn.com  Sun Oct 11 18:51:08 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sun, 11 Oct 2020 13:51:08 -0400
Subject: [ANN] Kineto, an HTTP to Gemini proxy/gateway
Message-ID: <C6A93LGU5SBN.2ESI779URGULF@homura>

Kineto is designed to service a single Gemini domain, so that you can,
for example, serve your Gemini site available over HTTP.

Development information is available here:

https://sr.ht/~sircmpwn/kineto/

Project info here:

gemini://drewdevault.com/kineto.gmi

And a live demo, if you're curious:

https://portal.drewdevault.com/

Enjoy!

From mailinglists at ngalt.com  Mon Oct 12 01:38:57 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sun, 11 Oct 2020 17:38:57 -0700
Subject: Bug reports: Multiple spaces in links; Cmd+S unreliable (was: Re:
 [ANN] Lagrange - A Beautiful Gemini Client)
In-Reply-To: <29DDFE8D-1036-41E7-BAE3-7B7F6D17CB10@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>
 <29DDFE8D-1036-41E7-BAE3-7B7F6D17CB10@dengine.net>
Message-ID: <BA956464-54D6-4A11-B20D-B530DD34DE60@ngalt.com>


> On Oct 11, 2020, at 12:29 AM, skyjake <skyjake at dengine.net> wrote:
> 
> On 11. Oct 2020, at 5:04, mailinglists at ngalt.com wrote:
> 
>> First and by far the most important, I'd like to echo John Cowan's effusive praise. Lagrange is nothing short of insanely great.
> 
> Thanks, glad to hear you like it. :)
> 
>> First, in the category of "I don't know if it's wrong, but it _is_ different and I'm not sure I like it": I went to <gemini://gemini.circumlunar.space/users/> and multiple spaces in link text are being collapsed into one space.
> 
> Hmm, interesting. The Gemini spec doesn't seem to weigh in on whitespace normalization in link text (only in regular text lines), although it does say "clients can present links to users in whatever fashion the client author wishes".
> 
> The way the right-aligning is done here assumes a fixed-width font. While it isn't appropriate to show all links using a fixed-width font, perhaps this use case of whitespace padding could be detected by the client and it could switch to fixed-width for those links only? Seems a little fiddly, though, since it also assumes a specific line width.

Eh. I wouldn?t wish that on a client author. That user listing already looks kind of bad in amfora(1) already with my fairly-narrow text-width settings. I don?t think there?s a good solution here for properly-aligned text (all the preexisting proposals have been shot down or deferred or something), so my hunch is that the best option is to do nothing special.

Situations like these are why I prefaced this whole thing with ?I don?t know if it?s wrong, but??.

? Nathan

From lazar.michael22 at gmail.com  Mon Oct 12 04:39:29 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sun, 11 Oct 2020 23:39:29 -0400
Subject: crawling, proxies, and robots.txt
Message-ID: <CAFTy05Yfw0kBRPVNai3W2B==TgyDPi1s2L7U9KJhy0Pz51=2vQ@mail.gmail.com>

Hi all,

I have a few topics concerning crawling geminispace that I would like to bring
up.

First, I have recently updated my web proxy @ https://portal.mozz.us to respect
robots.txt files placed at the root of a gemini capsule. The proxy will follow
rules for either the "webproxy" or "webproxy-mozz" user agents. My feelings
have gone back and forth on this point because I'm not convinced that a web
proxy falls into the category of a "crawler"; it's a network client that makes
requests on behalf of real users. Nonetheless, geminispace has been growing and
I have started to see links to gemlog articles via proxy show up on twitter and
the typical tech discussion boards. This clashing of communities makes me
nervous on a personal level so I want to give folks a chance to opt-out of it,
at least for my proxy.

Second, I have *slowly* been building a crawler for gemini [0]. My goal is to
create a historical archive of geminispace and submit it somewhere for
long-term preservation. This was inspired by Charles Lehner's recent email to
the list [0]. I've spent a fair amount of time in gopher, and I am deeply
saddened that so many of the important gopher servers from the 90's have been
lost forever. Currently my crawler is respecting robots.txt files using the
"mozz-archiver" user agent. I will probably standardize this to match my proxy
(i.e. "archiver" and "archiver-mozz"). I am not 100% decided that I will even
respect robots files for this project (archive.org doesn't [2]), but right now
I'm leaning towards "yes". If you are currently mirroring a large website like
wikipedia over gemini, I would greatly appreciate if you setup a robots.txt to
block one of the above user-agents from those paths to make my life a bit
easier.

best,
mozz

[0] https://github.com/michael-lazar/mozz-archiver
[1] https://lists.orbitalfox.eu/archives/gemini/2020/002544.html
[2] https://blog.archive.org/2017/04/17/robots-txt-meant-for-search-engines-dont-work-well-for-web-archives/

From sean at conman.org  Mon Oct 12 05:06:01 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 12 Oct 2020 00:06:01 -0400
Subject: crawling, proxies, and robots.txt
In-Reply-To: <CAFTy05Yfw0kBRPVNai3W2B==TgyDPi1s2L7U9KJhy0Pz51=2vQ@mail.gmail.com>
References: <CAFTy05Yfw0kBRPVNai3W2B==TgyDPi1s2L7U9KJhy0Pz51=2vQ@mail.gmail.com>
Message-ID: <20201012040559.GA11270@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> Hi all,
> 
> Second, I have *slowly* been building a crawler for gemini [0]. My goal is to
> create a historical archive of geminispace and submit it somewhere for
> long-term preservation. This was inspired by Charles Lehner's recent email to
> the list [0]. I've spent a fair amount of time in gopher, and I am deeply
> saddened that so many of the important gopher servers from the 90's have been
> lost forever. Currently my crawler is respecting robots.txt files using the
> "mozz-archiver" user agent. I will probably standardize this to match my proxy
> (i.e. "archiver" and "archiver-mozz"). I am not 100% decided that I will even
> respect robots files for this project (archive.org doesn't [2]), but right now
> I'm leaning towards "yes". If you are currently mirroring a large website like
> wikipedia over gemini, I would greatly appreciate if you setup a robots.txt to
> block one of the above user-agents from those paths to make my life a bit
> easier.

  So I've added the following:

User-agent: archiver
User-agent: archiver-mozz
User-agent: mozz-archiver
Disallow: /boston

to my /robots.txt file.  I assume this will catch your archiver and prevent
my blog from being archived, given that my blog is primarily web-based (and
mirrored to Gemini and gopher) it is already archived (by existing web
archives).

  Now a question: when people can check the archive, how will the missing
portions of a Gemini site be presented?  I'm blocking the above because it's
a mirror of an existing web site (and might fit your "large" category, what
with 20 years of content there), but there's no indication in the robots.txt
file of that.

  -spc


From skyjake at dengine.net  Mon Oct 12 07:14:23 2020
From: skyjake at dengine.net (skyjake)
Date: Mon, 12 Oct 2020 09:14:23 +0300
Subject: Bug reports: Multiple spaces in links; Cmd+S unreliable (was: Re:
 [ANN] Lagrange - A Beautiful Gemini Client)
In-Reply-To: <BA956464-54D6-4A11-B20D-B530DD34DE60@ngalt.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>
 <29DDFE8D-1036-41E7-BAE3-7B7F6D17CB10@dengine.net>
 <BA956464-54D6-4A11-B20D-B530DD34DE60@ngalt.com>
Message-ID: <6F7456E3-4A43-4413-87DA-B130BD3E1B32@dengine.net>

On 12. Oct 2020, at 3:38, Nathan Galt <mailinglists at ngalt.com> wrote:

> Eh. I wouldn?t wish that on a client author. That user listing already looks kind of bad in amfora(1) already with my fairly-narrow text-width settings. I don?t think there?s a good solution here for properly-aligned text (all the preexisting proposals have been shot down or deferred or something), so my hunch is that the best option is to do nothing special.
> 
> Situations like these are why I prefaced this whole thing with ?I don?t know if it?s wrong, but??.

I recognize that in gemtext one cannot use spaces like this for alignment, while also permitting variable-width fonts and whitespace normalization. Nevertheless, I was curious about the idea of normalizing multiple spaces differently. A simple rule of 8+ spaces becoming a tab character produced nice results:

=> http://media.skyjake.fi/normalized_to_tabs.png

It was also quite simple to implement (of course, Lagrange uses a custom text renderer so stuff like this is possible without extra effort):

=> https://git.skyjake.fi/skyjake/lagrange/commit/4a3cda29bbf2494061fb1090698cf1230e43a280

I'm not advocating for this to be standard practice in clients, but I'll keep it at least for the time being in Lagrange and see if it produces adverse effects elsewhere.

--jaakko

From adrian at openwork.nz  Mon Oct 12 08:36:22 2020
From: adrian at openwork.nz (Adrian Lyall Cochrane)
Date: Mon, 12 Oct 2020 20:36:22 +1300
Subject: Hello!
Message-ID: <1602488182.2517.1@smtp.fastmail.com>

Hi Gemini folks!

I thought I might introduce myself. My name is Adrian Cochrane, and I'm 
implementing an auditory web/gemini browser I call "Rhapsode". Rhapsode 
communicates purely through sound (and arrow keys for input) with no 
visual output!

My goal is to show the potential for a simpler JS-free web to work 
beautifully on any device, and when I was shown Gemini I liked the 
ideas and found it absolutely trivial to throw in support for that!

You can find Rhapsode's code at https://rhapsode.adrian.geek.nz/ , 
which is written primarily in Haskell.

Cheers,

Adrian Cochrane
OpenWork Ltd

Lead developer of:
libdggs geospatial analysis
Odysseus & Rhapsode web browsers

P.S. Any advice configuring OpenSSL for Gemini?


From benulo at systemli.org  Mon Oct 12 13:19:47 2020
From: benulo at systemli.org (Ben)
Date: Mon, 12 Oct 2020 15:49:47 +0330
Subject: Hello!
In-Reply-To: <1602488182.2517.1@smtp.fastmail.com>
References: <1602488182.2517.1@smtp.fastmail.com>
Message-ID: <b06ba52f-af4b-500d-1c1e-bd2cf65f992e@systemli.org>

Haskell, you say? I'm in!

-- 
gemini://kwiecien.us/

From cowan at ccil.org  Tue Oct 13 04:10:53 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 12 Oct 2020 23:10:53 -0400
Subject: Bug reports: Multiple spaces in links; Cmd+S unreliable (was: Re:
 [ANN] Lagrange - A Beautiful Gemini Client)
In-Reply-To: <6F7456E3-4A43-4413-87DA-B130BD3E1B32@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <12310e89-4329-4134-87f6-436dae2de121@www.fastmail.com>
 <29DDFE8D-1036-41E7-BAE3-7B7F6D17CB10@dengine.net>
 <BA956464-54D6-4A11-B20D-B530DD34DE60@ngalt.com>
 <6F7456E3-4A43-4413-87DA-B130BD3E1B32@dengine.net>
Message-ID: <CAD2gp_Th=TiWaB+FauejrLPyokaD-W2M+LKsW2EXoFa_1-F61A@mail.gmail.com>

On Mon, Oct 12, 2020 at 2:14 AM skyjake <skyjake at dengine.net> wrote:


> I recognize that in gemtext one cannot use spaces like this for alignment,
> while also permitting variable-width fonts and whitespace normalization.
> Nevertheless, I was curious about the idea of normalizing multiple spaces
> differently.


Another possibility would be to render a link name that contains more than
2 consecutive spaces in a monowidth font, the same one used for ``` mode.
That would be very clean, I think.

A simple rule of 8+ spaces becoming a tab character produced nice results:
>

That's worth keeping too.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Heh, heh: ... or three pairs of wheels? I wonder what would have happened
if Ravna had just read a little further. In some weird way, Twirlip
knows the Secret of the Riders.   --Vernor Vinge, note 601
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201012/3575d200/attachment.htm>

From lazar.michael22 at gmail.com  Tue Oct 13 04:56:25 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Mon, 12 Oct 2020 23:56:25 -0400
Subject: crawling, proxies, and robots.txt
In-Reply-To: <20201012040559.GA11270@brevard.conman.org>
References: <CAFTy05Yfw0kBRPVNai3W2B==TgyDPi1s2L7U9KJhy0Pz51=2vQ@mail.gmail.com>
 <20201012040559.GA11270@brevard.conman.org>
Message-ID: <CAFTy05bNDuPdH5z3vvTbuX2d4rtinHtxmdB0RRQA9fz_7DE1fg@mail.gmail.com>

On Mon, Oct 12, 2020 at 12:06 AM Sean Conner <sean at conman.org> wrote:
> So I've added the following:
>
> User-agent: archiver
> User-agent: archiver-mozz
> User-agent: mozz-archiver
> Disallow: /boston
>
> to my /robots.txt file. I assume this will catch your archiver and prevent
> my blog from being archived, given that my blog is primarily web-based (and
> mirrored to Gemini and gopher) it is already archived (by existing web
> archives).
>
>  Now a question: when people can check the archive, how will the missing
> portions of a Gemini site be presented? I'm blocking the above because it's
> a mirror of an existing web site (and might fit your "large" category, what
> with 20 years of content there), but there's no indication in the robots.txt
> file of that.

I plan on always archiving the /robots.txt file if it exists, even if it's
excluded by the parsing rules. So you could always add your comments there
using the "#" syntax which is part of the 1994 robots.txt standard [0].

> User-agent: archiver
> Disallow: /boston  # Content is a mirror of https://...

I also plan on recording failed requests as part of the archive; so you can
tell the difference between a bad DNS lookup and a connection timeout, etc.
I'll see if I can add a robots exclusion type error t to make it
transparent why the resource is missing.

(By the way, something like your blog archive does not fit my definition of
large :D)

[0] https://www.robotstxt.org/orig.html

- mozz

From callum at calcuode.com  Sat Oct 17 18:02:01 2020
From: callum at calcuode.com (Callum Brown)
Date: Sat, 17 Oct 2020 18:02:01 +0100
Subject: [ANN] gmsfn - a feed builder for Gemini
Message-ID: <C6FBT996QZOB.25I7XJXF57N3G@callum-computer>

Hello!

I've made a program which constructs a feed of new links found around
Geminispace. It's a bit like spacewalk in that the author of a gemlog
doesn't need to generate an Atom/RSS feed, and a bit like CAPCOM in that
it links directly to new posts. I wanted something a bit different to
both of the existing tools and a project to learn C with, so that's why
gmsfn exists. Maybe other people will find it useful too :-)

The name comes from the Manned Space Flight Network (MSFN) - a set of
tracking stations that were used to support the Mercury, Gemini, Apollo
and Skylab space programs.

gmsfn uses Drew DeVault's Gemini client gmni for all the more difficult
protocol and parsing bits, so I didn't have to do all that for my first
real C program - thanks Drew! If you want to try it yourself I suggest
checking the Makefile to ensure it's not going to do anything weird
(I still don't really get Makefiles), and I don't know how well it's
going to deal with lots of source pages and lots of history.

More information is available at gemini://calcuode.com/gmsfn-readme.gmi
Source is at https://git.sr.ht/~callum/gmsfn
Live example is at gemini://calcuode.com/feed.gmi

My gmsfn generated feed hasn't really got going yet; there haven't been
any new links since the first run. I'm planning to do a little exploring
soon and find some more gemlogs to add.	Any particular reccomendations
are welcome!

Callum

From avalonw at posteo.net  Sun Oct 18 10:33:53 2020
From: avalonw at posteo.net (Avalon Woodard)
Date: Sun, 18 Oct 2020 04:33:53 -0500
Subject: New gemini content :) 
Message-ID: <20201018093353.o3a6c7bmsvyuabtf@Dream.attlocal.net>

Hello all, 

Just wanted to drop in, say hi and let you all know that I've just 
gotten a small server up on a raspberry pi at gemini://whirling.top
It's hosting a couple of capsules, and while some of the content is 
mirrored to the web and/or gopher, some of it is likely to be 
gemini-only eventually. 

Thanks everyone for the hard work in getting this protocol up and 
running!
-Avalon Woodard

From benulo at systemli.org  Sun Oct 18 16:07:24 2020
From: benulo at systemli.org (Ben)
Date: Sun, 18 Oct 2020 18:37:24 +0330
Subject: New gemini content :)
In-Reply-To: <20201018093353.o3a6c7bmsvyuabtf@Dream.attlocal.net>
References: <20201018093353.o3a6c7bmsvyuabtf@Dream.attlocal.net>
Message-ID: <d5e90852-aff5-9aa6-3008-6b5e25d67b15@systemli.org>

Cool domain!

-- 
gemini://kwiecien.us/

From luke at marmaladefoo.com  Sun Oct 18 17:46:42 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 18 Oct 2020 17:46:42 +0100
Subject: New gemini content :)
In-Reply-To: <20201018093353.o3a6c7bmsvyuabtf@Dream.attlocal.net>
References: <20201018093353.o3a6c7bmsvyuabtf@Dream.attlocal.net>
Message-ID: <5F8C7172.3090004@marmaladefoo.com>

Hello Avalon

On your home page you have a preformatted area, but it doesn't display 
correctly as you need to use three back ticks ``` not three quotes ''' 
to delimit the preformatted content (a nice bit of ascii art - a 
whirling top I think?)

Otherwise, nice to see another server up!

  - Luke

On 18-Oct-2020 10:33, Avalon Woodard wrote:
> Hello all,
> Just wanted to drop in, say hi and let you all know that I've just 
> gotten a small server up on a raspberry pi at gemini://whirling.top
> It's hosting a couple of capsules, and while some of the content is 
> mirrored to the web and/or gopher, some of it is likely to be 
> gemini-only eventually.
> Thanks everyone for the hard work in getting this protocol up and 
> running!
> -Avalon Woodard

From avalonw at posteo.net  Mon Oct 19 01:43:51 2020
From: avalonw at posteo.net (Avalon Woodard)
Date: Sun, 18 Oct 2020 19:43:51 -0500
Subject: New gemini content :)
In-Reply-To: <5F8C7172.3090004@marmaladefoo.com>
References: <20201018093353.o3a6c7bmsvyuabtf@Dream.attlocal.net>
 <5F8C7172.3090004@marmaladefoo.com>
Message-ID: <20201019004351.zfjx4jxomgtpveyy@Dream.attlocal.net>


 Luke Emmet wrote:
>On your home page you have a preformatted area, but it doesn't display 
>correctly as you need to use three back ticks ``` not three quotes ''' 
>to delimit the preformatted content (a nice bit of ascii art - a 
>whirling top I think?)

Thank you for letting me know! I totally missed that, but have fixed it 
now :) 

-Avalon

From singletona082 at gmail.com  Mon Oct 19 22:33:40 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Mon, 19 Oct 2020 16:33:40 -0500
Subject: Can the default colors for the gemini http site be changed?
Message-ID: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>

https://gemini.circumlunar.space/

Maybe it's due to my poor eyesite but 'dark text on a light olive
background with red links.'

Guys we can do better. Seriously. I get wanting to avoid 'white background
with black text' but that site is visually offensive and actively makes my
eyes hurt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201019/1bd4aaef/attachment.htm>

From luke at marmaladefoo.com  Mon Oct 19 23:38:56 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 19 Oct 2020 23:38:56 +0100
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
References: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
Message-ID: <5F8E1580.706@marmaladefoo.com>


On 19-Oct-2020 22:33, Andrew Singleton wrote:
> https://gemini.circumlunar.space/
>
> Maybe it's due to my poor eyesite but 'dark text on a light olive 
> background with red links.'
>
> Guys we can do better. Seriously. I get wanting to avoid 'white 
> background with black text' but that site is visually offensive and 
> actively makes my eyes hurt.

Hi Andrew

Please accept my apologies in advance for this suggestion, but you could 
use this version, it can have whatever styling suits you best, if you go 
with a client that offers user controlled content styling :)

gemini://gemini.circumlunar.space/

My understanding is that solderpunk keeps the website is purposefully 
rustic and light of content, to draw the curious into gemini space 
itself. As for the actual colour scheme - yes it is a bit arbitrary and 
probably is a turn off for anyone expecting gemini to be a graphic 
designer's playground.

  - Luke



From martin at no.ucant.org  Tue Oct 20 01:14:08 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 20 Oct 2020 01:14:08 +0100 (BST)
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <5F8E1580.706@marmaladefoo.com>
References: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
 <5F8E1580.706@marmaladefoo.com>
Message-ID: <alpine.DEB.2.20.2010200113430.1522@pling.qwghlm.org>

On Mon, 19 Oct 2020, Luke Emmet wrote:

> the actual colour scheme - yes it is a bit arbitrary and probably is a turn 
> off for anyone expecting gemini to be a graphic designer's playground.

I wonder if that's partly intentional ;)

Mk

-- 
Martin Keegan, @mk270, https://mk.ucant.org/

From singletona082 at gmail.com  Tue Oct 20 03:54:04 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Mon, 19 Oct 2020 21:54:04 -0500
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <alpine.DEB.2.20.2010200113430.1522@pling.qwghlm.org>
References: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
 <5F8E1580.706@marmaladefoo.com>
 <alpine.DEB.2.20.2010200113430.1522@pling.qwghlm.org>
Message-ID: <CAPBeim6BpAetOWJF+r7yfZrbsWxKnKuAsgw+g06ruWeoL7hNsg@mail.gmail.com>

There is a difference between 'may have turn off for people expecting
grwphics' and making thigs activly difficult to read. Do not hide behind
'lol stop expecting graphics scrub' to have horrific coloration.

On Mon, Oct 19, 2020, 7:14 PM Martin Keegan <martin at no.ucant.org> wrote:

> On Mon, 19 Oct 2020, Luke Emmet wrote:
>
> > the actual colour scheme - yes it is a bit arbitrary and probably is a
> turn
> > off for anyone expecting gemini to be a graphic designer's playground.
>
> I wonder if that's partly intentional ;)
>
> Mk
>
> --
> Martin Keegan, @mk270, https://mk.ucant.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201019/d4d32c2e/attachment.htm>

From cowan at ccil.org  Tue Oct 20 04:33:05 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 19 Oct 2020 23:33:05 -0400
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <CAPBeim6BpAetOWJF+r7yfZrbsWxKnKuAsgw+g06ruWeoL7hNsg@mail.gmail.com>
References: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
 <5F8E1580.706@marmaladefoo.com>
 <alpine.DEB.2.20.2010200113430.1522@pling.qwghlm.org>
 <CAPBeim6BpAetOWJF+r7yfZrbsWxKnKuAsgw+g06ruWeoL7hNsg@mail.gmail.com>
Message-ID: <CAD2gp_R7qtX1pZCWQZxL2ZKzNjOT7J3sdbRSnZTYs9oLiRFi_A@mail.gmail.com>

On Mon, Oct 19, 2020 at 10:54 PM Andrew Singleton <singletona082 at gmail.com>
wrote:

There is a difference between 'may have turn off for people expecting
> grwphics' and making thigs activly difficult to read.
>

I agree absolutely.

Do not hide behind 'lol stop expecting graphics scrub' to have horrific
> coloration
>

Fortunately there's Just Read <https://github.com/ZachSaucier/Just-Read>,
which is a plugin for Firefox and Chrome that applies a sensible CSS to any
web site you like: black print on white paper, as God and Gutenburg
intended.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Work hard / play hard,                                      cowan at ccil.org
die young / rot quickly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201019/9e0237ff/attachment.htm>

From sir at cmpwn.com  Tue Oct 20 13:28:11 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Tue, 20 Oct 2020 08:28:11 -0400
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <CAD2gp_R7qtX1pZCWQZxL2ZKzNjOT7J3sdbRSnZTYs9oLiRFi_A@mail.gmail.com>
Message-ID: <C6HPV8LSJZRX.25Z4T6LXWO1XC@taiga>

Emphasizing that Gemini user agents can adjust the presentation to suit
the user's preferences is entirely fine, but making accessibility
choices which discriminates against users with visual impairments is a
much less agreeable choice. The site should strive to be plain and
readable.

It's pretty accessible through my Gemini portal, if anyone needs it:

https://portal.drewdevault.com/x/gemini.circumlunar.space/

From adrian at apetre.sc  Wed Oct 21 02:34:37 2020
From: adrian at apetre.sc (Adrian Petrescu)
Date: Tue, 20 Oct 2020 21:34:37 -0400
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <C6HPV8LSJZRX.25Z4T6LXWO1XC@taiga>
References: <CAD2gp_R7qtX1pZCWQZxL2ZKzNjOT7J3sdbRSnZTYs9oLiRFi_A@mail.gmail.com>
 <C6HPV8LSJZRX.25Z4T6LXWO1XC@taiga>
Message-ID: <20201021013437.jjuvtrctwtgs2xze@Coxeter.localdomain>

On 10/20 08:28AM, Drew DeVault wrote:
>Emphasizing that Gemini user agents can adjust the presentation to suit
>the user's preferences is entirely fine, but making accessibility
>choices which discriminates against users with visual impairments is a
>much less agreeable choice. The site should strive to be plain and
>readable.

I agree with everyone's overall sentiment about accessibility and having
a good default color scheme, etc., but am genuinely puzzled by the
specific hate for gemini.circumlunar.space's look. Nobody would ever
accuse me of having excellent vision, and I find it positively
delightful?

The light olive seems just muted enough to be a better contrast than
glaring white. Maybe the red is a little too bold but it's mostly fine
and used sparingly. I don't get the sense at *all* that solderpunk made
it intentionally bad to emphasize client styling. It feels carefully and
well chosen to me.

What am I missing?

-- 
Adrian

From adrian at apetre.sc  Wed Oct 21 02:21:11 2020
From: adrian at apetre.sc (Adrian Petrescu)
Date: Tue, 20 Oct 2020 21:21:11 -0400
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
Message-ID: <20201021012031.aci4awlgnuc56cce@Coxeter.localdomain>

Let me add my voice to the chorus of praise - this is hands-down the
best Gemini client I've seen yet. It makes me actively seek out more
Gemini content just so I can enjoy it.

My one request/wishlist item is for further configurable keybindings. In
my particular case, I like to use vim-like motions (j/k for scrolling, /
for search, etc) everywhere possible. I've modified the source code
directly to add those, and it works great for me, but it will probably
get annoying maintaining those patches as new versions come up.

(And I don't think you'll want my patches upstream, since not everyone
wants the exact keybindings I happen to have chosen for myself...)


Thank you so much, again, for this amazing contribution to the
community!

-- 
Adrian

From skyjake at dengine.net  Wed Oct 21 08:07:27 2020
From: skyjake at dengine.net (skyjake)
Date: Wed, 21 Oct 2020 10:07:27 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <20201021012031.aci4awlgnuc56cce@Coxeter.localdomain>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <20201021012031.aci4awlgnuc56cce@Coxeter.localdomain>
Message-ID: <BDD1D964-2205-4765-936A-5F75ED72B37B@dengine.net>

On 21. Oct 2020, at 4:21, Adrian Petrescu <adrian at apetre.sc> wrote:

> Let me add my voice to the chorus of praise - this is hands-down the
> best Gemini client I've seen yet. It makes me actively seek out more
> Gemini content just so I can enjoy it.

Glad to hear it, thank you. :)

> My one request/wishlist item is for further configurable keybindings. In
> my particular case, I like to use vim-like motions (j/k for scrolling, /
> for search, etc) everywhere possible.

Ok, request noted. I can see how configuring the keybindings would be useful.

I'm currently putting together v0.6 where I'm focusing on adding new color themes and some bug fixes, but after that configurable bindings could be a nice next thing to work on.

--jaakko

https://gmi.skyjake.fi/lagrange/

From premysl at vyhnal.net  Wed Oct 21 09:39:01 2020
From: premysl at vyhnal.net (=?UTF-8?Q?P=C5=99emysl_Vyhnal?=)
Date: Wed, 21 Oct 2020 10:39:01 +0200
Subject: gus stopped indexing?
Message-ID: <CAJystH3fGa1S2X5qZ=A_eNTzgVOJn-Y+f8_qaXyP5+6G=aW-yg@mail.gmail.com>

Hi, is everything ok with GUS? It says that the last index update was on
2020-09-25 and it doesn't show any new pages/hosts.

Regards
Premek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201021/af41f831/attachment.htm>

From sandra.snan at idiomdrottning.org  Wed Oct 21 10:34:51 2020
From: sandra.snan at idiomdrottning.org (Sandra Snan)
Date: Wed, 21 Oct 2020 11:34:51 +0200
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CAD2gp_T=A00zzKD-h345xxS+u2KPdtXXDnE2+xFmhA5W0BzRTA@mail.gmail.com>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <CAD2gp_T=A00zzKD-h345xxS+u2KPdtXXDnE2+xFmhA5W0BzRTA@mail.gmail.com>
Message-ID: <87tuunncqs.fsf@idiomdrottning.org>

John Cowan <cowan at ccil.org> writes:
> Even though your colors are subtle, black print on white paper, as God
> and Gutenberg intended, is the most readable.

Yes. Matthew 6:28-31, Proverbs 8:11, Tao Te Ching 27.?

From linde.philip at gmail.com  Wed Oct 21 12:57:51 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 21 Oct 2020 13:57:51 +0200
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
References: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
Message-ID: <20201021135751.99db627e130a26339b9c7ad1@gmail.com>

On Mon, 19 Oct 2020 16:33:40 -0500
Andrew Singleton <singletona082 at gmail.com> wrote:

> Guys we can do better. Seriously. I get wanting to avoid 'white background
> with black text' but that site is visually offensive and actively makes my
> eyes hurt.

I just want to make sure we're all on the same page; are we discussing
aesthetics or accessibility (in terms of legibility I guess)? Both?

Aesthetically I think it looks great.

I took a look at it with a plugin that simulates different kinds of
color vision impairments. With red- or green blindness the link text is
quite hard to read. Maybe greater luminance contrast could be useful.
It's hard to account for all kinds of impairment, but red-green
blindness is common so orange-on-olive is perhaps not the best choice.

For contrasts, there is apparently a "prefer-contrast" media query
parameter which can be used by clients to signal their preference.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201021/e60314db/attachment.sig>

From list at gkbrk.com  Wed Oct 21 13:03:22 2020
From: list at gkbrk.com (Leo)
Date: Wed, 21 Oct 2020 15:03:22 +0300
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <C6HPV8LSJZRX.25Z4T6LXWO1XC@taiga>
Message-ID: <C6IJYRY3G3W2.WK32V4ZD4YXQ@rath>

> making accessibility choices which discriminates against users with
> visual impairments

Can we not expect a user with visual impairments to already have their
browser settings / extensions set up in a way to assist them? Surely if
you can't read certain foreground and background combinations, you would
be aware of Reader Mode at least.

From tomasino at lavabit.com  Wed Oct 21 13:23:01 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Wed, 21 Oct 2020 12:23:01 +0000
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <C6IJYRY3G3W2.WK32V4ZD4YXQ@rath>
References: <C6IJYRY3G3W2.WK32V4ZD4YXQ@rath>
Message-ID: <9bb66405-d7f0-6e9e-f475-7a279837dc18@lavabit.com>

On 10/21/20 12:03 PM, Leo wrote:
>> making accessibility choices which discriminates against users with
>> visual impairments
> Can we not expect a user with visual impairments to already have their
> browser settings / extensions set up in a way to assist them? Surely if
> you can't read certain foreground and background combinations, you would
> be aware of Reader Mode at least.

My business these last few months has been redressing websites to comply with WCAG 2.1 AA standards as a result of lawsuits in the US filed under the ADA. Color contrast is only one small part of that, but let me assure you it is having very real financial impact on businesses right now. While a personal website may not be a target for litigation, following these standards is something we should all strive for if it is within our means.

With regard to color schemes, if you are not yourself very good at design it may be helpful to know you can find and generate color palettes using Adobe's Color website, which will also give guidance on accessibility. https://color.adobe.com/create/color-accessibility

Furthermore, both Chrome and Firefox have means of seeing the WCAG color contrast ratios using their respective inspectors. AAA is great, but shoot for AA at least.

And finally, let me say that since this is about the Gemini website on circumlunar in particular, Solderpunk, if you find this stuff difficult or tedious or otherwise don't have time for it gimme a holler and I'll see what I can do to help.


From jmcbray at carcosa.net  Wed Oct 21 13:49:15 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 21 Oct 2020 08:49:15 -0400
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <CAPBeim6BpAetOWJF+r7yfZrbsWxKnKuAsgw+g06ruWeoL7hNsg@mail.gmail.com>
 (Andrew Singleton's message of "Mon, 19 Oct 2020 21:54:04 -0500")
References: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
 <5F8E1580.706@marmaladefoo.com>
 <alpine.DEB.2.20.2010200113430.1522@pling.qwghlm.org>
 <CAPBeim6BpAetOWJF+r7yfZrbsWxKnKuAsgw+g06ruWeoL7hNsg@mail.gmail.com>
Message-ID: <871rhrvj5g.fsf@dorothy.carcosa.net>

Andrew Singleton <singletona082 at gmail.com> writes:

> There is a difference between 'may have turn off for people expecting
> grwphics' and making thigs activly difficult to read. Do not hide
> behind 'lol stop expecting graphics scrub' to have horrific
> coloration.

Agreed ? it should have a color scheme that at least has accessible
contrast. IMO, browser default with a light CSS typography reset would
be fine. But beyond fixing the accessibility issue, this would be
bikeshedding. 

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Wed Oct 21 13:51:47 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 21 Oct 2020 08:51:47 -0400
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <20201021013437.jjuvtrctwtgs2xze@Coxeter.localdomain> (Adrian
 Petrescu's message of "Tue, 20 Oct 2020 21:34:37 -0400")
References: <CAD2gp_R7qtX1pZCWQZxL2ZKzNjOT7J3sdbRSnZTYs9oLiRFi_A@mail.gmail.com>
 <C6HPV8LSJZRX.25Z4T6LXWO1XC@taiga>
 <20201021013437.jjuvtrctwtgs2xze@Coxeter.localdomain>
Message-ID: <87wnzju4gs.fsf@dorothy.carcosa.net>

Adrian Petrescu <adrian at apetre.sc> writes:

> On 10/20 08:28AM, Drew DeVault wrote:
>>Emphasizing that Gemini user agents can adjust the presentation to suit
>>the user's preferences is entirely fine, but making accessibility
>>choices which discriminates against users with visual impairments is a
>>much less agreeable choice. The site should strive to be plain and
>>readable.
>
> I agree with everyone's overall sentiment about accessibility and having
> a good default color scheme, etc., but am genuinely puzzled by the
> specific hate for gemini.circumlunar.space's look. Nobody would ever
> accuse me of having excellent vision, and I find it positively
> delightful?

The background and text are fine, actually. The red links on the light
olive background do not meet WCAG standards for accessible text,
according to the checker I ran.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From list at gkbrk.com  Wed Oct 21 15:16:11 2020
From: list at gkbrk.com (Leo)
Date: Wed, 21 Oct 2020 17:16:11 +0300
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <9bb66405-d7f0-6e9e-f475-7a279837dc18@lavabit.com>
Message-ID: <C6IMSGTFQ3P5.1QFW00O6HBOVO@rath>

> following these standards is something we should all strive for

Instead of trying to fix millions of web pages and putting the burden
on all the content producers, wouldn't it be easier to fix browsers to
automatically assign suitable colours when the contrast is too low?
After all, a user agent has no obligation to use the colours recommended by
the website and it's stylesheets.

> both Chrome and Firefox have means of seeing the WCAG color contrast
> ratios.

And since Chrome and Firefox both have code for calculating colour contrast
ratios, a lot of the work is already done.

If we are disregarding user agents being able to pick colours as a valid
thing to do, should we also add styling to the Gemini document format so
content producers can make sure their text is displayed correctly and is
accessible?

From singletona082 at gmail.com  Wed Oct 21 15:27:05 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Wed, 21 Oct 2020 09:27:05 -0500
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <87wnzju4gs.fsf@dorothy.carcosa.net>
References: <CAD2gp_R7qtX1pZCWQZxL2ZKzNjOT7J3sdbRSnZTYs9oLiRFi_A@mail.gmail.com>
 <C6HPV8LSJZRX.25Z4T6LXWO1XC@taiga>
 <20201021013437.jjuvtrctwtgs2xze@Coxeter.localdomain>
 <87wnzju4gs.fsf@dorothy.carcosa.net>
Message-ID: <CAPBeim7dAn54yjDGp=EGJS0W6ADuGOtfq+DQkZWaLN5ORjmzVg@mail.gmail.com>

Lighten the olive a touch and it should be better. Agree it's better
than glaring white but touching it up a couple clicks could fix it.

> The background and text are fine, actually. The red links on the light olive background do not meet WCAG standards for accessible text, according to the checker I ran.

From tomasino at lavabit.com  Wed Oct 21 15:37:42 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Wed, 21 Oct 2020 14:37:42 +0000
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <C6IMSGTFQ3P5.1QFW00O6HBOVO@rath>
References: <C6IMSGTFQ3P5.1QFW00O6HBOVO@rath>
Message-ID: <435674ee-0215-36a2-d884-d2dc3c542a02@lavabit.com>

On 10/21/20 2:16 PM, Leo wrote:
> If we are disregarding user agents being able to pick colours as a valid
> thing to do, should we also add styling to the Gemini document format so
> content producers can make sure their text is displayed correctly and is
> accessible?

It's the lack of styling in the gemini document format working in our favor. On http browsers pass the buck for styling saying it's the content author's responsibility. In gemini we can do away with that nonsense and build clients better. Accessible clients are first-class citizens.


From singletona082 at gmail.com  Wed Oct 21 15:47:52 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Wed, 21 Oct 2020 09:47:52 -0500
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <435674ee-0215-36a2-d884-d2dc3c542a02@lavabit.com>
References: <C6IMSGTFQ3P5.1QFW00O6HBOVO@rath>
 <435674ee-0215-36a2-d884-d2dc3c542a02@lavabit.com>
Message-ID: <CAPBeim7kjigmXQ75gjPZwuW6TN_8k4p9POPugEJS-ovg_MBU6w@mail.gmail.com>

Oooooooh. Look guys, I'm sorry for not keeping up with the
discussions. However the technical side, in spite of best efforts,
kinda flies over my head. So the fact gemini clients have
user-definable EVERYTHING is honestly a huge win in my book. I prefer
dark background/light text. Other people with low vision like blue
background with white text (personally I don't get it, but eh.) Others
like a beige/cream background with dark text.

The 'let the end user define what page elements present as' is
honestly a step forward, especially with the idea of gemini being a
middlepoint between gopher and full blown html.

However I was viewing through a traditional browser, so I'm unsure how
to square that problem.

On 10/21/20, James Tomasino <tomasino at lavabit.com> wrote:
> On 10/21/20 2:16 PM, Leo wrote:
>> If we are disregarding user agents being able to pick colours as a valid
>> thing to do, should we also add styling to the Gemini document format so
>> content producers can make sure their text is displayed correctly and is
>> accessible?
>
> It's the lack of styling in the gemini document format working in our favor.
> On http browsers pass the buck for styling saying it's the content author's
> responsibility. In gemini we can do away with that nonsense and build
> clients better. Accessible clients are first-class citizens.
>
>

From sean at conman.org  Wed Oct 21 20:53:42 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 21 Oct 2020 15:53:42 -0400
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <87tuunncqs.fsf@idiomdrottning.org>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <FD4AA376-E847-4F9F-89FF-18EEC32AC741@dengine.net>
 <CAD2gp_T=A00zzKD-h345xxS+u2KPdtXXDnE2+xFmhA5W0BzRTA@mail.gmail.com>
 <87tuunncqs.fsf@idiomdrottning.org>
Message-ID: <20201021195342.GD30302@brevard.conman.org>

It was thus said that the Great Sandra Snan once stated:
> John Cowan <cowan at ccil.org> writes:
> > Even though your colors are subtle, black print on white paper, as God
> > and Gutenberg intended, is the most readable.
> 
> Yes. Matthew 6:28-31, Proverbs 8:11, Tao Te Ching 27.?

=> gemini://gemini.conman.org/bible/Matthew.6:28-31	Matthew 6:28-31
=> gemini://gemini.conman.org/bible/Proverbs.8:11	Proverbs 8:11

  -spc(Sadly, I do not know of a Gemini link to the Tao Te Ching)

From zephryn at owlsne.st  Wed Oct 21 22:21:27 2020
From: zephryn at owlsne.st (zephryn)
Date: Wed, 21 Oct 2020 17:21:27 -0400
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <20201021135751.99db627e130a26339b9c7ad1@gmail.com>
References: <CAPBeim6o3v97f4PGwhrin3w5D1SVmJpwbP4Xdet1gVf_3m+uug@mail.gmail.com>
 <20201021135751.99db627e130a26339b9c7ad1@gmail.com>
Message-ID: <96710355-e362-2992-68f9-b7194b59024d@owlsne.st>

 > For contrasts, there is apparently a "prefer-contrast" media query
 > parameter which can be used by clients to signal their preference.

I think that using what you mentioned (prefers-contrast) along with
prefers-color-scheme should definitely be considered! The former is
still pretty experimental, but both could help web clients have a bit of 
choice without having any scripting involved.

~zeph

From raiz at stellarbound.space  Thu Oct 22 15:32:41 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Thu, 22 Oct 2020 14:32:41 +0000
Subject: Spec proposal
Message-ID: <074c84c3153c2bc50db694083768f6af@stellarbound.space>

Greetings follows, I just found out about gemini recently and I got
interested in the project and wanted to be involved, In the process of
setting up my gempod (that's how you call them?), I wanted to be able
to have an HTML/HTTP mirror for my gempod and I haven't found a gemtext
to HTML converter so I decided to write my own, and in the middle of
the process I thought if I'm going write a full parser for gemtext,
I might as well make the code reusable and package it as a library, so
the project shifted from a gemtext to HTML tool to a gemtext processing
library, and here I am.

However, throughout implementing the parser, I got into many questions
about the spec, I can't really recall all of them right now but here
are a few:

- In 5.5.2 it is stated that lines beginning with "* " are elements of
an unordered list, and I assumed the space after '*' is required since 
it
is included in the double quotes, when I asked for clarification on IRC,
others suggested I handle '*' with or without space afterwards, so I 
did.

- In 5.5.3, I had the same question with quotes, the spec says ">" which
sounds like there should be no space after ">", and if there is a space,
I should treat it like a part of the quote, I asked on IRC if I should
follow that behaviour but others also recommended that I should handle
spaces after ">" just in case, which leaves me to think again if the
spec intended that or not.

- In 5.5.1, It is not explicitly stated how many heading levels are
allowed within the spec, I assumed it followed the same way markdown
does it allowing up to 6 levels, however, after asking on IRC, I was
told 3 is max, so I went with that.

As of now, my implementation is complete, It is almost usable for
anyone willing to test it, I wrote manpages for all functions currently
implemented, but not for the data types yet, I'm going to work on that,
and as part of my project, I want to write a manpage for the text/gemini
format (gemtext(5)) and I want it to be precise and spec compliant,
if you don't mind, I'll go ahead and write the manpage as a proposal to
standardize some of the unclear cases of the spec, if the rest of the
community agrees, maybe get the spec updated too?

Attached is a tarball of my current implementation (WIP)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgemtext.tar.gz
Type: application/x-gzip
Size: 59403 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201022/fef7c467/attachment-0001.bin>

From mieum at tilde.team  Thu Oct 22 16:56:45 2020
From: mieum at tilde.team (mieum)
Date: Fri, 23 Oct 2020 00:56:45 +0900
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <20201021195342.GD30302@brevard.conman.org>
Message-ID: <C6JJK0RSM886.JZYS2YB7NET1@maclibre>

> -spc(Sadly, I do not know of a Gemini link to the Tao Te Ching)

Sean, after reading your comment, I was tempted to throw up the James
Legge version on my capsule, but on a whim I reached out to Roger Ames,
who allowed me to house his translation on Gemini! 

=> gemini://namu.blue/~mieum/library/ddj/

I wrote about it a little on Allok Dallok:

=> gemini://rawtext.club/~mieum/dallok/2020-10.gmi

The chapter Sandra referenced (27) appears as so in this translation:

> Able travelers leave no ruts or tracks along the way;
> Able speakers make no gaffes that might occasion reproach;
> Able reckoners have no use for tallies or counting sticks;
> Able sealers make no use of bolts or latches yet what they close off cannot be opened.
> Able cinchers make no use of ropes or cords yet their knots cannot be undone.
>
> It is for this reason that the sages in being really good at turning others to account
> Have no need to reject anyone,
> And in dealing with property,
> Have no need to reject anything.
> This is what is called following their natural acuity (ming).
>
> Thus able persons are teachers of the able
> While the inept provide them with raw materials.
>
> While perhaps wise enough,
> Those who fail to honor their teachers and to be sparing with their raw materials
> Have gotten themselves utterly lost.
> This is what is called being subtle and getting to the essentials.

From sean at conman.org  Thu Oct 22 23:01:34 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 22 Oct 2020 18:01:34 -0400
Subject: Spec proposal
In-Reply-To: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
References: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
Message-ID: <20201022220133.GE30302@brevard.conman.org>

It was thus said that the Great Ali Fardan once stated:
> Greetings follows, I just found out about gemini recently and I got
> interested in the project and wanted to be involved, In the process of
> setting up my gempod (that's how you call them?), I wanted to be able
> to have an HTML/HTTP mirror for my gempod and I haven't found a gemtext
> to HTML converter 

  Given how easy it is, I'm surprised there aren't more.  But by searching
the mailing list, I did fine reference to two Gemini-text-to-HTML
converters:

	https://github.com/LukeEmmet/GemiNaut/blob/master/GemiNaut/GmiConverters/GmiToHtml.r3
	(written in Rebol, a blast from the past)

	https://git.sr.ht/~sotirisp/qute-gemini
	(Gemini text to Markdown to HTML in python3)

> so I decided to write my own, and in the middle of
> the process I thought if I'm going write a full parser for gemtext,
> I might as well make the code reusable and package it as a library, so
> the project shifted from a gemtext to HTML tool to a gemtext processing
> library, and here I am.

  Hello.

> As of now, my implementation is complete, It is almost usable for
> anyone willing to test it, I wrote manpages for all functions currently
> implemented, but not for the data types yet, I'm going to work on that,
> and as part of my project, I want to write a manpage for the text/gemini
> format (gemtext(5)) and I want it to be precise and spec compliant,
> if you don't mind, I'll go ahead and write the manpage as a proposal to
> standardize some of the unclear cases of the spec, if the rest of the
> community agrees, maybe get the spec updated too?
> 
> Attached is a tarball of my current implementation (WIP)

  And here are some comments from trying it out.  I wrote a simple Gemini
text file (with very long lines) and ran your test program over it.  In the
output you have some garbage data on the very first line:

00000000: 88 DB CB 23 20 4C 6F 72 65 6D 20 69 70 73 75 6D ...# Lorem ipsum
00000010: 20 64 6F 6C 6F 72 20 73 69 74 20 61 6D 65 74 2C  dolor sit amet,

  Thoughts:  sounds like you have some unitialized memory.  Aside from the
garbage bytes, the output did not match the input as the pre-formatted block
input did not have the ``` guards.  And the last blank line was not included
in the output either.

  I also ran it under valgrind [1] and found a leak in the happy path:

[spc]lucy:/tmp/libgemtext>valgrind --show-reachable=yes --leak-check=full ./test </tmp/text.gemini >/tmp/t.gmi
==26859== Memcheck, a memory error detector.
==26859== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==26859== Using LibVEX rev 1575, a library for dynamic binary translation.
==26859== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==26859== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==26859== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==26859== For more details, rerun with: -v
==26859== 
==26859== Conditional jump or move depends on uninitialised value(s)
==26859==    at 0x804A2C1: strlcat (strlcat.c:38)
==26859==    by 0x8049C7E: _line_append (encode.c:198)
==26859==    by 0x8049EF5: gemtext_encode (encode.c:263)
==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
==26859==    by 0x804867A: main (test.c:15)
==26859== 
==26859== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 1)
==26859== malloc/free: in use at exit: 7,200 bytes in 1 blocks.
==26859== malloc/free: 86 allocs, 85 frees, 84,247 bytes allocated.
==26859== For counts of detected errors, rerun with: -v
==26859== searching for pointers to 1 not-freed blocks.
==26859== checked 55,588 bytes.
==26859== 
==26859== 
==26859== 7,200 bytes in 1 blocks are possibly lost in loss record 1 of 1
==26859==    at 0x400579F: realloc (vg_replace_malloc.c:306)
==26859==    by 0x8049C56: _line_append (encode.c:194)
==26859==    by 0x8049D5D: gemtext_encode (encode.c:224)
==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
==26859==    by 0x804867A: main (test.c:15)
==26859== 
==26859== LEAK SUMMARY:
==26859==    definitely lost: 0 bytes in 0 blocks.
==26859==      possibly lost: 7,200 bytes in 1 blocks.
==26859==    still reachable: 0 bytes in 0 blocks.
==26859==         suppressed: 0 bytes in 0 blocks.

  You will also want to check the non-happy paths for memory leaks.  In my
experience, memory leaks are more likely in the non-happy path because
programmers rarely think through the non-happy path, and it's annoying to
write code to properly handle the non-happy paths in C.

  But I think it's wonderful that there was only one leak, and possibly an
easy one to fix.  The library itself appears easy to use (if you know C). 
Good job.

  -spc

[1]	If you are doing C, and have access to valgrind (it's almost always
	installed on every Linux system, or available to be installed), use
	it.  It is a fantastic tool to find memory leaks and issues with
	unitialized memory.  Yes, it's annoying having to track all the
	issues down, but I feel it's worth it.


From raiz at stellarbound.space  Fri Oct 23 04:09:56 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Fri, 23 Oct 2020 06:09:56 +0300
Subject: Spec proposal
In-Reply-To: <20201022220133.GE30302@brevard.conman.org>
References: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
 <20201022220133.GE30302@brevard.conman.org>
Message-ID: <6160c52e6af5a8df300bd6510b80205c@stellarbound.space>

On 2020-10-23 01:01, Sean Conner wrote:
>   Given how easy it is, I'm surprised there aren't more.  But by 
> searching
> the mailing list, I did fine reference to two Gemini-text-to-HTML
> converters:
> 
> 	https://github.com/LukeEmmet/GemiNaut/blob/master/GemiNaut/GmiConverters/GmiToHtml.r3
> 	(written in Rebol, a blast from the past)
> 
> 	https://git.sr.ht/~sotirisp/qute-gemini
> 	(Gemini text to Markdown to HTML in python3)

Interesting, still would like to have my own.

>   And here are some comments from trying it out.  I wrote a simple 
> Gemini
> text file (with very long lines) and ran your test program over it.  In 
> the
> output you have some garbage data on the very first line:
> 
> 00000000: 88 DB CB 23 20 4C 6F 72 65 6D 20 69 70 73 75 6D ...# Lorem 
> ipsum
> 00000010: 20 64 6F 6C 6F 72 20 73 69 74 20 61 6D 65 74 2C  dolor sit 
> amet,
> 
>   Thoughts:  sounds like you have some unitialized memory.  Aside from 
> the
> garbage bytes, the output did not match the input as the pre-formatted 
> block
> input did not have the ``` guards.  And the last blank line was not 
> included
> in the output either.

Thanks for taking the time, I'm going to write tests for the code now,
I haven't done that yet, I should probably be able to encounter that
bug again.  However, just in case I don't would you like to send me the
file you used to test with?

>   I also ran it under valgrind [1] and found a leak in the happy path:
> 
> [spc]lucy:/tmp/libgemtext>valgrind --show-reachable=yes
> --leak-check=full ./test </tmp/text.gemini >/tmp/t.gmi
> ==26859== Memcheck, a memory error detector.
> ==26859== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et 
> al.
> ==26859== Using LibVEX rev 1575, a library for dynamic binary 
> translation.
> ==26859== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==26859== Using valgrind-3.1.1, a dynamic binary instrumentation 
> framework.
> ==26859== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et 
> al.
> ==26859== For more details, rerun with: -v
> ==26859==
> ==26859== Conditional jump or move depends on uninitialised value(s)
> ==26859==    at 0x804A2C1: strlcat (strlcat.c:38)
> ==26859==    by 0x8049C7E: _line_append (encode.c:198)
> ==26859==    by 0x8049EF5: gemtext_encode (encode.c:263)
> ==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
> ==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
> ==26859==    by 0x804867A: main (test.c:15)
> ==26859==
> ==26859== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 
> 1)
> ==26859== malloc/free: in use at exit: 7,200 bytes in 1 blocks.
> ==26859== malloc/free: 86 allocs, 85 frees, 84,247 bytes allocated.
> ==26859== For counts of detected errors, rerun with: -v
> ==26859== searching for pointers to 1 not-freed blocks.
> ==26859== checked 55,588 bytes.
> ==26859==
> ==26859==
> ==26859== 7,200 bytes in 1 blocks are possibly lost in loss record 1 of 
> 1
> ==26859==    at 0x400579F: realloc (vg_replace_malloc.c:306)
> ==26859==    by 0x8049C56: _line_append (encode.c:194)
> ==26859==    by 0x8049D5D: gemtext_encode (encode.c:224)
> ==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
> ==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
> ==26859==    by 0x804867A: main (test.c:15)
> ==26859==
> ==26859== LEAK SUMMARY:
> ==26859==    definitely lost: 0 bytes in 0 blocks.
> ==26859==      possibly lost: 7,200 bytes in 1 blocks.
> ==26859==    still reachable: 0 bytes in 0 blocks.
> ==26859==         suppressed: 0 bytes in 0 blocks.
> 
>   You will also want to check the non-happy paths for memory leaks.  In 
> my
> experience, memory leaks are more likely in the non-happy path because
> programmers rarely think through the non-happy path, and it's annoying 
> to
> write code to properly handle the non-happy paths in C.
> 
>   But I think it's wonderful that there was only one leak, and possibly 
> an
> easy one to fix.  The library itself appears easy to use (if you know 
> C).
> Good job.

Oh yeah, I ran valgrind, on my test file though, which didn't trigger
that, I wouldn't call it a real test file because it was the end of the
day, I just wanted to see if it works.

From raiz at stellarbound.space  Fri Oct 23 07:03:53 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Fri, 23 Oct 2020 09:03:53 +0300
Subject: Spec proposal
In-Reply-To: <20201022220133.GE30302@brevard.conman.org>
References: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
 <20201022220133.GE30302@brevard.conman.org>
Message-ID: <cb917ff9a89c5b4fe54a7d0d5a3408eb@stellarbound.space>

On 2020-10-23 01:01, Sean Conner wrote:
>   I also ran it under valgrind [1] and found a leak in the happy path:
> 
> [spc]lucy:/tmp/libgemtext>valgrind --show-reachable=yes
> --leak-check=full ./test </tmp/text.gemini >/tmp/t.gmi
> ==26859== Memcheck, a memory error detector.
> ==26859== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et 
> al.
> ==26859== Using LibVEX rev 1575, a library for dynamic binary 
> translation.
> ==26859== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==26859== Using valgrind-3.1.1, a dynamic binary instrumentation 
> framework.
> ==26859== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et 
> al.
> ==26859== For more details, rerun with: -v
> ==26859==
> ==26859== Conditional jump or move depends on uninitialised value(s)
> ==26859==    at 0x804A2C1: strlcat (strlcat.c:38)
> ==26859==    by 0x8049C7E: _line_append (encode.c:198)
> ==26859==    by 0x8049EF5: gemtext_encode (encode.c:263)
> ==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
> ==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
> ==26859==    by 0x804867A: main (test.c:15)
> ==26859==
> ==26859== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 
> 1)
> ==26859== malloc/free: in use at exit: 7,200 bytes in 1 blocks.
> ==26859== malloc/free: 86 allocs, 85 frees, 84,247 bytes allocated.
> ==26859== For counts of detected errors, rerun with: -v
> ==26859== searching for pointers to 1 not-freed blocks.
> ==26859== checked 55,588 bytes.
> ==26859==
> ==26859==
> ==26859== 7,200 bytes in 1 blocks are possibly lost in loss record 1 of 
> 1
> ==26859==    at 0x400579F: realloc (vg_replace_malloc.c:306)
> ==26859==    by 0x8049C56: _line_append (encode.c:194)
> ==26859==    by 0x8049D5D: gemtext_encode (encode.c:224)
> ==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
> ==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
> ==26859==    by 0x804867A: main (test.c:15)
> ==26859==
> ==26859== LEAK SUMMARY:
> ==26859==    definitely lost: 0 bytes in 0 blocks.
> ==26859==      possibly lost: 7,200 bytes in 1 blocks.
> ==26859==    still reachable: 0 bytes in 0 blocks.
> ==26859==         suppressed: 0 bytes in 0 blocks.

Leak is fixed, thank you. I missed that.
https://git.tilde.institute/raiz/libgemtext/commit/?id=2024b2562ad83a04fbfb6699ca8dc4b877a676e4

From flexibeast at gmail.com  Fri Oct 23 08:57:16 2020
From: flexibeast at gmail.com (Alexis)
Date: Fri, 23 Oct 2020 18:57:16 +1100
Subject: proxy.vulpes.one not displaying preformatted text
Message-ID: <875z71ml2b.fsf@ada>


Hi all,

It appears proxy.vulpes.one won't display preformatted text if 
it's the first thing in a document:

  https://proxy.vulpes.one/gemini/republic.circumlunar.space/users/flexibeast/preformatted-1.gmi

Adding leading text results in the preformatted text being 
displayed:

  https://proxy.vulpes.one/gemini/republic.circumlunar.space/users/flexibeast/preformatted-2.gmi

The issue doesn't appear when using portal.mozz.us:

  https://portal.mozz.us/gemini/republic.circumlunar.space/users/flexibeast/preformatted-1.gmi

  https://portal.mozz.us/gemini/republic.circumlunar.space/users/flexibeast/preformatted-2.gmi

No contact details are listed at https://proxy.vulpes.one/; does 
anyone know who i should contact about this?

(Also, the text of https://proxy.vulpes.one/ refers to 
"startpage:// in the top left corner", but the actual text is 
"start://".)


Alexis.

From luke at marmaladefoo.com  Fri Oct 23 10:07:29 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 23 Oct 2020 10:07:29 +0100
Subject: Relegated Wikipedia entry on Gemini (protocol)
Message-ID: <5F929D51.1040101@marmaladefoo.com>

Hi All

There is (or was) a page on vestigial Gemini on wikipedia that various 
people have contributed to - perhaps you are on this mailing list and 
can comment.

https://en.wikipedia.org/wiki/Gemini_(protocol)

Recently I noticed it has been removed or relegated to a draft page 
only, stating it does not cite any reliable sources and thus Wikipedia 
does not consider that Gemini (protocol) does not meet the notability 
criteria

https://en.wikipedia.org/wiki/Draft:Gemini_(protocol)

It seems a useful page to have up, particularly for newcomers. Is there 
a fix for this?

Regards

  - Luke

From mbays at sdf.org  Fri Oct 23 12:39:31 2020
From: mbays at sdf.org (Martin Bays)
Date: Fri, 23 Oct 2020 13:39:31 +0200
Subject: Spec proposal
In-Reply-To: <20201022220133.GE30302@brevard.conman.org>
References: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
 <20201022220133.GE30302@brevard.conman.org>
Message-ID: <20201023113931.GC32677@localhost>

* Thursday, 2020-10-22 at 18:01 -0400 - Sean Conner <sean at conman.org>:

>Given how easy it is, I'm surprised there aren't more.  But by 
>searching the mailing list, I did find reference to two 
>Gemini-text-to-HTML converters

Here's another which I didn't bother announcing to the list at the time:
gemini://gemini.thegonz.net/gmi2html.sed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201023/d4d3af31/attachment.sig>

From baschdel at disroot.org  Fri Oct 23 14:22:32 2020
From: baschdel at disroot.org (Baschdel)
Date: Fri, 23 Oct 2020 15:22:32 +0200
Subject: proxy.vulpes.one not displaying preformatted text
In-Reply-To: <875z71ml2b.fsf@ada>
References: <875z71ml2b.fsf@ada>
Message-ID: <e6cae7c8-2b43-00d0-a78f-26ab1d8cb07d@disroot.org>

Hello,
me again.
> It appears proxy.vulpes.one won't display preformatted text if it's 
> the first thing in a document:
Already forwarded that one to Feuerfuchs, he'll look into it.

> No contact details are listed at https://proxy.vulpes.one/; does 
> anyone know who i should contact about this?
You can contact him via E-Mail to me [at] vulpes.one or send a message 
to @Feuerfuchs at fedi.vulpes.one on the Fediverse.

Have a nice weekend!
- Baschdel

From crunklord420 at lolcow.email  Fri Oct 23 15:21:17 2020
From: crunklord420 at lolcow.email (CrunkLord420)
Date: Fri, 23 Oct 2020 07:21:17 -0700
Subject: [ANN] GemBoard - Anonymous Textboard
Message-ID: <c4c13b20-c185-e1cf-fedb-ef217be4b3b1@lolcow.email>

I wrote an anonymous textboard for the Gemini protocol. Written in Rust
using Tokio to provide high performance asynchronous and multithreaded
processing. PostgreSQL is used for a database.

Source: https://git.kiwifarms.net/CrunkLord420/gemboard

Test Instance: gemini://matrix.kiwifarms.net/

Future plans include more robust spam detection, post throttling and
optional/multiple TLS certificate support for use behind a reverse proxy
to facilitate dual clearnet and tor onion domains.


From acdw at acdw.net  Fri Oct 23 15:25:46 2020
From: acdw at acdw.net (acdw)
Date: Fri, 23 Oct 2020 14:25:46 +0000
Subject: Relegated Wikipedia entry on Gemini (protocol)
In-Reply-To: <5F929D51.1040101@marmaladefoo.com>
References: <5F929D51.1040101@marmaladefoo.com>
Message-ID: <c15686c7-dd00-487e-b2a0-816c1cb966fe@www.fastmail.com>

On 2020-10-23 (Friday) at 09:07, Luke Emmet <luke at marmaladefoo.com> wrote:

> Hi All
> 
> There is (or was) a page on vestigial Gemini on wikipedia that various 
> people have contributed to - perhaps you are on this mailing list and 
> can comment.
> 
> https://en.wikipedia.org/wiki/Gemini_(protocol)
> 
> Recently I noticed it has been removed or relegated to a draft page 
> only, stating it does not cite any reliable sources and thus Wikipedia 
> does not consider that Gemini (protocol) does not meet the notability 
> criteria
> 
> https://en.wikipedia.org/wiki/Draft:Gemini_(protocol)
> 
> It seems a useful page to have up, particularly for newcomers. Is there 
> a fix for this?
> 
> Regards
> 
>   - Luke
>

It looks like the page needs more citations, from "reliable secondary sources that are independent of the topic" --- so if we could find (or rustle up) articles on other sites *about* gemini, that might help. I'm not very versed in Wikipedia's guidelines, but maybe these?

https://samsai.eu/post/introduction-to-gemini/
https://www.susa.net/wordpress/2020/06/gemini-protocol-markup/

Etc....

If anyone has in-roads at like, Wired or another magazine (maybe Low-Tech Magazine would be interested?), that'd be dope.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From cowan at ccil.org  Fri Oct 23 15:35:08 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 23 Oct 2020 10:35:08 -0400
Subject: Relegated Wikipedia entry on Gemini (protocol)
In-Reply-To: <5F929D51.1040101@marmaladefoo.com>
References: <5F929D51.1040101@marmaladefoo.com>
Message-ID: <CAD2gp_SL5UD73zYKC3iZdv6J_MX6vE=b4hEz6z13xxrYu1FOeg@mail.gmail.com>

On Fri, Oct 23, 2020 at 5:07 AM Luke Emmet <luke at marmaladefoo.com> wrote:

https://en.wikipedia.org/wiki/Draft:Gemini_(protocol)
>
> It seems a useful page to have up, particularly for newcomers. Is there
> a fix for this?
>

Fixing the *article* can never change the notability of the *topic*.   A
topic is not notable unless it is described or discussed in multiple
independent reliable sources -- independent not only of each other but of
the inventor(s) and their fans.  The only way to make that happen is to do
things like write an article that gets published in a scholarly journal
(not one that publishes indiscriminately) or arrange for detailed coverage
in a well-known newspaper or magazine or their Web equivalents.  Generally
speaking, blog posts by randoms do not count as such sources.

<
https://en.wikipedia.org/wiki/Wikipedia:Notability#General_notability_guideline
>

<https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources#Overview>

<
https://en.wikipedia.org/wiki/Wikipedia:Independent_sources#Why_independent_sources_are_required
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201023/5ca5f74d/attachment.htm>

From alex at nytpu.com  Fri Oct 23 17:04:43 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Fri, 23 Oct 2020 10:04:43 -0600
Subject: Relegated Wikipedia entry on Gemini (protocol)
Message-ID: <20201023160443.g5cx5vkyhbvzwcz6@GLaDOS>

Hey everybody,

I just posted on the talk page:
https://en.wikipedia.org/wiki/Draft_talk:Gemini_(protocol) but I'll
quote what I put there:
> This article has one source (the gemini homepage), but there are lots
> of available sources. Using Wikipedia's suggested search of "Gemini"
> protocol -Wikipedia, I turned up: [1], [2], [3], and [4]. Also,
> looking at Gopher's article[5] as an example, you can cite links to
> the project pages/repos when necessary in the "Notes" section in [6].
> I could add the things I linked here to the article if everyone wants.

[1]: https://www.susa.net/wordpress/2020/06/gemini-protocol-markup/
[2]: https://www.gkbrk.com/wiki/Gemini/
[3]: https://samsai.eu/post/introduction-to-gemini/
[4]: https://news.ycombinator.com/item?id=23042424
[5]: https://en.wikipedia.org/wiki/Gopher_(protocol)#Web_browsers
[6]: https://en.wikipedia.org/wiki/Draft:Gemini_(protocol)#Browsers

I'm probably just going to make those changes, but if anyone has any
additional links it'd only make the article better to add them. I think
with these though it should at least make it a *candidate* for
publishing. If anyone has any exemplary links in geminispace itself,
those would be good to add to "External Links" but I don't think
wikipedia likes cross-scheme stuff in references.

Thanks,
Alex

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201023/21600139/attachment.sig>

From tomasino at lavabit.com  Fri Oct 23 17:17:01 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 23 Oct 2020 16:17:01 +0000
Subject: Relegated Wikipedia entry on Gemini (protocol)
In-Reply-To: <20201023160443.g5cx5vkyhbvzwcz6@GLaDOS>
References: <20201023160443.g5cx5vkyhbvzwcz6@GLaDOS>
Message-ID: <d7fc9c25-7927-4580-815d-11608d1df08c@lavabit.com>

On 10/23/20 4:04 PM, Alex // nytpu wrote:
> but if anyone has any
> additional links it'd only make the article better

I'm not sure it qualifies for what Wikipedia needs, but I do have a "What is Gemini?" video on YouTube. https://www.youtube.com/watch?v=DoEI6VzybDk


From nihilazo at protonmail.com  Fri Oct 23 18:32:06 2020
From: nihilazo at protonmail.com (jan Niko (Nico))
Date: Fri, 23 Oct 2020 17:32:06 +0000
Subject: Preferred convention for converting inline links?
Message-ID: <73pqAJHUQdLzxvifF5ZqRnY140Us6nVpXvMPlKjCnD4rwEYGKsmddYPaCy3gqeknZHyKQ-cBDxCw8uS2pMEaDFbvWX5-GGqK3c3OyAFQ3Zw=@protonmail.com>

Hi,
I'm new to gemini and I'd like to make my website (https://itwont.work) also available as a gemini site (capsule? Not sure what the terminology is).
The site is a wiki-style site and as a result of that contains a lot of inline links. I'm not sure what the convention for converting that to gemini text is, given that there is no inline links in text in gemini. The two ideas I have for this are making them like footnotes or just putting them the line after.

For example, if I have a markdown line like this:

Mine is running arch linux, with a GUI built around sway, waybar, and [sike](sike.md). The on-screen keyboard is [squeekboard](https://source.puri.sm/Librem5/squeekboard) with a custom split layout. (if people are interested in the UI setup, I'll make a page for it)

Would it be better to turn it into gemini text like this:

Mine is running arch linux, with a GUI built around sway, waybar, and sike. The on-screen keyboard is squeekboard with a custom split layout. (if people are interested in the UI setup, I'll make a page for it)

=> https://source.puri.sm/Librem5/squeekboard Squeekboard
=> gemini://itwont.work/sike.gmi sike

or more like this?

Mine is running arch linux, with a GUI built around sway, waybar, and sike[1]. The on-screen keyboard is squeekboard[2] with a custom split layout. (if people are interested in the UI setup, I'll make a page for it)

[...rest of file here...]

=> https://source.puri.sm/Librem5/squeekboard [1] Squeekboard
=> gemini://itwont.work/sike.gmi [2] sike

Or is there another convention for this?

Thanks,
Nico

From sir at cmpwn.com  Fri Oct 23 18:32:36 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Fri, 23 Oct 2020 13:32:36 -0400
Subject: Preferred convention for converting inline links?
In-Reply-To: <73pqAJHUQdLzxvifF5ZqRnY140Us6nVpXvMPlKjCnD4rwEYGKsmddYPaCy3gqeknZHyKQ-cBDxCw8uS2pMEaDFbvWX5-GGqK3c3OyAFQ3Zw=@protonmail.com>
Message-ID: <C6KG7Y6TKSWH.8QBVXNMB7SBF@taiga>

On Fri Oct 23, 2020 at 1:32 PM EDT, jan Niko (Nico) wrote:
> Mine is running arch linux, with a GUI built around sway, waybar, and
> sike. The on-screen keyboard is squeekboard with a custom split layout.
> (if people are interested in the UI setup, I'll make a page for it)
>
> => https://source.puri.sm/Librem5/squeekboard Squeekboard
> => gemini://itwont.work/sike.gmi sike

I prefer this approach. Sometimes if I have a lot of references, I'll
make use of unicode superscript numerals to prepare a list of footnotes:

https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts#Superscripts_and_subscripts_block

However, in general, I avoid numbered links, because many clients assign
a number to each link for keyboard shortcuts and ease of use, and if my
numbering doesn't line up it could lead to confusion.

But also, as a general rule, I don't do automated conversions of
non-Gemini content to Gemtext. Instead, I manually reformat it as
Gemtext so that I can use editorial descretion to adjust the content to
better express itself in the conventions of the new medium.

From colecmac at protonmail.com  Fri Oct 23 19:12:45 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 23 Oct 2020 18:12:45 +0000
Subject: crawling, proxies, and robots.txt
In-Reply-To: <CAFTy05Yfw0kBRPVNai3W2B==TgyDPi1s2L7U9KJhy0Pz51=2vQ@mail.gmail.com>
References: <CAFTy05Yfw0kBRPVNai3W2B==TgyDPi1s2L7U9KJhy0Pz51=2vQ@mail.gmail.com>
Message-ID: <Yt6rT7icUkHMxyl4p8ET9dGGYcCn72ZFgvL-GTvYAhuMlfB7zf_eNLyPIfPXlmscURCMu5ZwXTzcjURl35WMPhM_DBc7e9r-lZbLJDCEH7Y=@protonmail.com>

Hello,

Both of these projects and ideas sound great! Maybe it's obvious, but just in
case: Make sure you respect the user agent of * as well, which signifies any
robot.


makeworld

From colecmac at protonmail.com  Fri Oct 23 19:48:27 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 23 Oct 2020 18:48:27 +0000
Subject: Spec proposal
In-Reply-To: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
References: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
Message-ID: <D46iIwVyjdRooIycMdUWYT4pD2CK-OtWscR622DN2Py2fBz9FhmFanxv2QRStB9fNuEwl8atDnQPi5qJio2XURXLasJWFI_AgjerUMgeep8=@protonmail.com>

> - In 5.5.2 it is stated that lines beginning with "* " are elements of
> an unordered list, and I assumed the space after '*' is required since
> it is included in the double quotes, when I asked for clarification on IRC,
> others suggested I handle '*' with or without space afterwards, so I
> did.

I would disagree with this. Originally there was no space required in the
spec, but this was changed, because some people may start lines with
asterisks as an "ASCII-art" way to show emphasis. To allow this writing
style to continue, you should require the space after the asterisk. This is
what the spec defines.

> - In 5.5.3, I had the same question with quotes, the spec says ">" which
> sounds like there should be no space after ">", and if there is a space,
> I should treat it like a part of the quote, I asked on IRC if I should
> follow that behaviour but others also recommended that I should handle
> spaces after ">" just in case, which leaves me to think again if the
> spec intended that or not.

Initially no line markers required a space after them. The list line marker
now does, as I described above, but the quote line marker was not changed,
as there doesn't seem to be a reason to. There doesn't seem to be writing
styles that start lines with a '>', but aren't referring to a quote. Working
without the space also follows markdown, which is a plus.

Cheers,
makeworld

From raiz at stellarbound.space  Fri Oct 23 20:06:23 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Fri, 23 Oct 2020 22:06:23 +0300
Subject: Spec proposal
In-Reply-To: <D46iIwVyjdRooIycMdUWYT4pD2CK-OtWscR622DN2Py2fBz9FhmFanxv2QRStB9fNuEwl8atDnQPi5qJio2XURXLasJWFI_AgjerUMgeep8=@protonmail.com>
References: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
 <D46iIwVyjdRooIycMdUWYT4pD2CK-OtWscR622DN2Py2fBz9FhmFanxv2QRStB9fNuEwl8atDnQPi5qJio2XURXLasJWFI_AgjerUMgeep8=@protonmail.com>
Message-ID: <3adf8b271ffd362060e1ef154b4842c4@stellarbound.space>

On 2020-10-23 21:48, colecmac at protonmail.com wrote:
>> - In 5.5.2 it is stated that lines beginning with "* " are elements of
>> an unordered list, and I assumed the space after '*' is required since
>> it is included in the double quotes, when I asked for clarification on 
>> IRC,
>> others suggested I handle '*' with or without space afterwards, so I
>> did.
> 
> I would disagree with this. Originally there was no space required in 
> the
> spec, but this was changed, because some people may start lines with
> asterisks as an "ASCII-art" way to show emphasis. To allow this writing
> style to continue, you should require the space after the asterisk. 
> This is
> what the spec defines.

I'm with you on that, also, mandatory whitespace makes it look cleaner
anyway, however, I'll keep handling both cases until the spec updates
to a clarified version.

>> - In 5.5.3, I had the same question with quotes, the spec says ">" 
>> which
>> sounds like there should be no space after ">", and if there is a 
>> space,
>> I should treat it like a part of the quote, I asked on IRC if I should
>> follow that behaviour but others also recommended that I should handle
>> spaces after ">" just in case, which leaves me to think again if the
>> spec intended that or not.
> 
> Initially no line markers required a space after them. The list line 
> marker
> now does, as I described above, but the quote line marker was not 
> changed,
> as there doesn't seem to be a reason to. There doesn't seem to be 
> writing
> styles that start lines with a '>', but aren't referring to a quote. 
> Working
> without the space also follows markdown, which is a plus.

Again, I'll keep handling both cases for this too, until the spec
clears out.

From luke at marmaladefoo.com  Fri Oct 23 21:37:50 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 23 Oct 2020 21:37:50 +0100
Subject: Preferred convention for converting inline links?
In-Reply-To: <73pqAJHUQdLzxvifF5ZqRnY140Us6nVpXvMPlKjCnD4rwEYGKsmddYPaCy3gqeknZHyKQ-cBDxCw8uS2pMEaDFbvWX5-GGqK3c3OyAFQ3Zw=@protonmail.com>
References: <73pqAJHUQdLzxvifF5ZqRnY140Us6nVpXvMPlKjCnD4rwEYGKsmddYPaCy3gqeknZHyKQ-cBDxCw8uS2pMEaDFbvWX5-GGqK3c3OyAFQ3Zw=@protonmail.com>
Message-ID: <5F933F1E.1090000@marmaladefoo.com>

On 23-Oct-2020 18:32, jan Niko (Nico) wrote:
> I'm new to gemini and I'd like to make my website (https://itwont.work) also available as a gemini site (capsule? Not sure what the terminology is).
> The site is a wiki-style site and as a result of that contains a lot of inline links. I'm not sure what the convention for converting that to gemini text is, given that there is no inline links in text in gemini. The two ideas I have for this are making them like footnotes or just putting them the line after.

Hi Nico

I think both are fine - there is no single established convention on 
this. Perhaps from gopher, the square bracket or unicode superscript 
footnote convention is reasonably well established, but simply emitting 
them after the relevant paragraph is OK too. Personally I prefer there 
to be a citation marker, as it makes it easier to see where the citation 
is made. Others prefer to just list the links without citation 
placemarkers, perhaps not even numbered.

I have a utility html2gmi which has to solve the same problem - it 
provides a number of options, including whether to number the citation 
placeholders, to number the footnote links, and the frequency of 
emitting the links within the document.

https://github.com/LukeEmmet/html2gmi

So horses for courses you might say.

  - Luke

From avalos at rawtext.club  Sat Oct 24 03:47:07 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Sat, 24 Oct 2020 02:47:07 +0000
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
Message-ID: <20201024024707.GA429718@rawtext.club>

Hi! I'm a huge fan of Lagrange, it's so far my favorite desktop Gemini
browser, it's just so visually perfect and has the right amount of
features! It's been working perfectly fine on macOS, I'm following the
latest updates. However, in Manjaro ARM (Pinebook Pro), sites like
gemini://circumlunar.space/ and gemini://gus.guru/ for some reason
don't seem to load at all. Maybe it has something to do with TLS, I'm
not sure how to debug, but I'd like to help. Here are the commands I
used to build version 0.5.0:

cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
cmake --build . --target install

Anyway, thanks for creating Lagrange, it's all I was expecting to find
in a Gemini browser, it gives such Aesthetics to the Gemini
experience! And the best part: it's free of Web components! Written in
C with beautiful SDL graphics, something rare in 2020. I hope to see
more improvements, without adding bloat and keeping the minimalist and
modern look and feel!

From skyjake at dengine.net  Sat Oct 24 12:56:32 2020
From: skyjake at dengine.net (skyjake)
Date: Sat, 24 Oct 2020 14:56:32 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <20201024024707.GA429718@rawtext.club>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
Message-ID: <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>

On 24. Oct 2020, at 5:47, avalos at rawtext.club wrote:

> However, in Manjaro ARM (Pinebook Pro), sites like
> gemini://circumlunar.space/ and gemini://gus.guru/ for some reason
> don't seem to load at all. Maybe it has something to do with TLS, I'm
> not sure how to debug, but I'd like to help.

(Suppose you mean gemini://gemini.circumlunar.space/ ?)

Hmm, if it isn't getting any response that could indicate a network connectivity issue. Unfortunately this is not my greatest area of expertise, but one possible reason might be some IPv4/IPv6 glitch? I've done very little testing with IPv6 so far.

I suppose other clients work for you on the Pinebook? That would mean it's definitely a bug in Lagrange.

What is the network configuration like on your Pinebook?

I'll play around with IPv6 on my end to see if anything seems obviously out of place. For what it's worth, on Raspberry Pi 3 w/Raspbian things seem to work OK.

> Anyway, thanks for creating Lagrange, it's all I was expecting to find
> in a Gemini browser, it gives such Aesthetics to the Gemini
> experience! And the best part: it's free of Web components! Written in
> C with beautiful SDL graphics, something rare in 2020. I hope to see
> more improvements, without adding bloat and keeping the minimalist and
> modern look and feel!

Thank you, and that's the plan! There's a number of smaller refinements on my todo list but in terms of big features it's getting close to v1.0, i.e., the first "feature complete" release.

--jaakko

https://gmi.skyjake.fi/lagrange/

From zachdecook at librem.one  Sat Oct 24 13:43:03 2020
From: zachdecook at librem.one (Zach DeCook)
Date: Sat, 24 Oct 2020 08:43:03 -0400
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
Message-ID: <B4655AC4-089B-4950-8D0D-1527C8919870@librem.one>

On October 24, 2020 7:56:32 AM EDT, skyjake <skyjake at dengine.net> wrote:
>On 24. Oct 2020, at 5:47, avalos at rawtext.club wrote:
>
>> However, in Manjaro ARM (Pinebook Pro), sites like
>> ... gemini://gus.guru/ for some reason
>> don't seem to load at all. Maybe it has something to do with TLS, I'm
>> not sure how to debug, but I'd like to help.
>
>
>Hmm, if it isn't getting any response that could indicate a network
>connectivity issue. Unfortunately this is not my greatest area of
>expertise, but one possible reason might be some IPv4/IPv6 glitch? I've
>done very little testing with IPv6 so far.
>
>I suppose other clients work for you on the Pinebook? That would mean
>it's definitely a bug in Lagrange.

I have the same issue loading gemini://gus.guru in Lagrange.
It may have something to do with trusted certificates:

Clients which don't work: castor 0.8.2-0.8.15 (connection refused (os error 111)), lagrange 0.5 (no error message given), jemini/jemini-sh (no error message given)

Clients which work: gmnlm (offers to trust certificate), gemini-demo-1

From solderpunk at posteo.net  Fri Oct 23 22:56:38 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Fri, 23 Oct 2020 23:56:38 +0200
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <87wnzju4gs.fsf@dorothy.carcosa.net>
Message-ID: <C6KLU3VDL0B3.YYR1BSNPO6C8@stilgar>

> > On 10/20 08:28AM, Drew DeVault wrote:
> >>Emphasizing that Gemini user agents can adjust the presentation to suit
> >>the user's preferences is entirely fine, but making accessibility
> >>choices which discriminates against users with visual impairments is a
> >>much less agreeable choice. The site should strive to be plain and
> >>readable.

I completely agree, the site should be readily accessible to visitors
with visual impairments, and I'm suitably embarrassed that I didn't
consider this.  The current design was certainly *not* deliberately
chosen to emphasise the fact (although naturally I think it's a great
fact to emphasise) that Gemini's lack of author-controlled styling for
content makes this kind of problem impossible.  I just chose some
colours, probably fairly quickly, which looked nice enough according to
my own personal tastes...

> > I agree with everyone's overall sentiment about accessibility and having
> > a good default color scheme, etc., but am genuinely puzzled by the
> > specific hate for gemini.circumlunar.space's look. Nobody would ever
> > accuse me of having excellent vision, and I find it positively
> > delightful?

...which I'm glad some other people share!

On Wed Oct 21, 2020 at 2:51 PM CEST, Jason McBrayer wrote:

> The background and text are fine, actually. The red links on the light
> olive background do not meet WCAG standards for accessible text,
> according to the checker I ran.

Would that be https://contrastchecker.com/?  Thanks for making me aware
that suck checkers exist, I didn't realise there were tools like that
out there for handling this.  I will change the colours this weekend to
a scheme which meets accessibility standards.

Cheers,
Solderpunk

From avalos at rawtext.club  Sat Oct 24 20:01:09 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Sat, 24 Oct 2020 19:01:09 +0000
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
Message-ID: <20201024190109.GA442018@rawtext.club>

On Sat, Oct 24, 2020 at 02:56:32PM +0300, skyjake wrote:
> On 24. Oct 2020, at 5:47, avalos at rawtext.club wrote:
> 
> > However, in Manjaro ARM (Pinebook Pro), sites like
> > gemini://circumlunar.space/ and gemini://gus.guru/ for some reason
> > don't seem to load at all. Maybe it has something to do with TLS, I'm
> > not sure how to debug, but I'd like to help.
> 
> (Suppose you mean gemini://gemini.circumlunar.space/ ?)
> 
> Hmm, if it isn't getting any response that could indicate a network connectivity issue. Unfortunately this is not my greatest area of expertise, but one possible reason might be some IPv4/IPv6 glitch? I've done very little testing with IPv6 so far.
> 
> I suppose other clients work for you on the Pinebook? That would mean it's definitely a bug in Lagrange.

Yes, I can access those sites on other clients, such as Castor and
amfora. It's probably a bug in Lagrange.

> What is the network configuration like on your Pinebook?
> 
> I'll play around with IPv6 on my end to see if anything seems obviously out of place. For what it's worth, on Raspberry Pi 3 w/Raspbian things seem to work OK.

I'm always connected to my WireGuard instance, but I haven't had any
problems so far. As I said, I'm able to access those sites from other clients.


From 0xwille at gmail.com  Sat Oct 24 20:25:00 2020
From: 0xwille at gmail.com (Guillermo Ramos)
Date: Sat, 24 Oct 2020 21:25:00 +0200
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <20201024190109.GA442018@rawtext.club>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
 <20201024190109.GA442018@rawtext.club>
Message-ID: <2b669ec6-e9b9-9535-fbd2-ee8283cd9bb5@gmail.com>

El 24/10/20 a las 21:01, avalos at rawtext.club escribi?:
> On Sat, Oct 24, 2020 at 02:56:32PM +0300, skyjake wrote:
>> On 24. Oct 2020, at 5:47, avalos at rawtext.club wrote:
>>
>>> However, in Manjaro ARM (Pinebook Pro), sites like
>>> gemini://circumlunar.space/ and gemini://gus.guru/ for some reason
>>> don't seem to load at all. Maybe it has something to do with TLS, I'm
>>> not sure how to debug, but I'd like to help.
>>
>> (Suppose you mean gemini://gemini.circumlunar.space/ ?)
>>
>> Hmm, if it isn't getting any response that could indicate a network connectivity issue. Unfortunately this is not my greatest area of expertise, but one possible reason might be some IPv4/IPv6 glitch? I've done very little testing with IPv6 so far.
>>
>> I suppose other clients work for you on the Pinebook? That would mean it's definitely a bug in Lagrange.
> 
> Yes, I can access those sites on other clients, such as Castor and
> amfora. It's probably a bug in Lagrange.

It is working for me (gemini://gus.guru/) in both Lagrange 0.5.0 and 
0.6.0. Running Gentoo amd64 with the following library versions:

- openssl-1.1.1g
- libpcre-8.44
- libunistring-0.9.10
- cmake-3.17.4
- libsdl2-2.0.12
- zlib-1.2.11
- mpg123-1.25.13


Btw, just started exploring Gemini and I found Lagrange to be a quite 
nice client, thanks skyjake!

From skyjake at dengine.net  Sat Oct 24 21:10:14 2020
From: skyjake at dengine.net (skyjake)
Date: Sat, 24 Oct 2020 23:10:14 +0300
Subject: [ANN] Lagrange - A Beautiful Gemini Client
In-Reply-To: <B4655AC4-089B-4950-8D0D-1527C8919870@librem.one>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
 <B4655AC4-089B-4950-8D0D-1527C8919870@librem.one>
Message-ID: <C1E930AE-EAAE-4382-8199-4EB859008A68@dengine.net>

On 24. Oct 2020, at 15:43, Zach DeCook <zachdecook at librem.one> wrote:

> I have the same issue loading gemini://gus.guru in Lagrange.
> It may have something to do with trusted certificates:
> 
> Clients which don't work: castor 0.8.2-0.8.15 (connection refused (os error 111)), lagrange 0.5 (no error message given), jemini/jemini-sh (no error message given)
> 
> Clients which work: gmnlm (offers to trust certificate), gemini-demo-1

This is very interesting. I'll dive into the gmnlm sources and see how it's using OpenSSL differently than Lagrange. It's entirely possible that I haven't gotten all the parameters right.

--jaakko

From flexibeast at gmail.com  Sun Oct 25 02:16:42 2020
From: flexibeast at gmail.com (Alexis)
Date: Sun, 25 Oct 2020 13:16:42 +1100
Subject: proxy.vulpes.one not displaying preformatted text
In-Reply-To: <e6cae7c8-2b43-00d0-a78f-26ab1d8cb07d@disroot.org>
References: <875z71ml2b.fsf@ada>
 <e6cae7c8-2b43-00d0-a78f-26ab1d8cb07d@disroot.org>
Message-ID: <87pn5782yd.fsf@ada>


Baschdel <baschdel at disroot.org> writes:

> Already forwarded that one to Feuerfuchs, he'll look into it.

Thank you!

> You can contact him via E-Mail to me [at] vulpes.one or send a 
> message
> to @Feuerfuchs at fedi.vulpes.one on the Fediverse.

Thanks, i'll note these for future reference. :-)


Alexis.

From singletona082 at gmail.com  Sun Oct 25 05:49:27 2020
From: singletona082 at gmail.com (Andrew Singleton)
Date: Sun, 25 Oct 2020 00:49:27 -0500
Subject: Trying to play catch-up on clients, authoring, and hosting.
Message-ID: <CAPBeim4B8c_he7j867CLTVQgoerU0YXRFA5-js5ezRZ6RTZyAQ@mail.gmail.com>

As the title suggests, I have been kinda out of the loop with the mailing
list. Partially because the technical aspects kinda go over my head, and
partially because I had been somewhat preoccupied with a home move that has
stalled out for reasons out of my control.

Is there a concise write-up for newbies?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201025/5b97e1f9/attachment-0001.htm>

From raiz at stellarbound.space  Sun Oct 25 11:02:15 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 25 Oct 2020 14:02:15 +0300
Subject: A question regarding the spec
Message-ID: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>

Yeah, I know I'm asking a lot at this point, bear with me please, I'd
just like have a little clarification.

I was browsing gemspace using netcat just to get a feel the typical
responses, and how others write gemtext, and first thing I noticed is in
gemini://gemini.circumlunar.space/ the index page has link lines with
label separators of multiple whitespace characters, so I referred back
to the spec to see if I missed something, and indeed I did, 5.4.2 says
"<whitespace> is any non-zero number of consecutive spaces or tabs",
and I noted that, now I'm wondering if this applies to headings to,
as in the whitespace after #, ## and ###.

From skyjake at dengine.net  Sun Oct 25 11:15:07 2020
From: skyjake at dengine.net (skyjake)
Date: Sun, 25 Oct 2020 13:15:07 +0200
Subject: Debugging Lagrange (was Re: [ANN] Lagrange - A Beautiful Gemini
 Client)
In-Reply-To: <20201024190109.GA442018@rawtext.club>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
 <20201024190109.GA442018@rawtext.club>
Message-ID: <C4F2121F-78FB-43CC-B4B6-6BFFC432E91D@dengine.net>

On 24. Oct 2020, at 22:01, avalos at rawtext.club wrote:

> On 24. Oct 2020, at 5:47, avalos at rawtext.club wrote:
> 
>> However, in Manjaro ARM (Pinebook Pro), sites like
>> gemini://circumlunar.space/ and gemini://gus.guru/ for some reason
>> don't seem to load at all. Maybe it has something to do with TLS, I'm
>> not sure how to debug, but I'd like to help.
> 
> Yes, I can access those sites on other clients, such as Castor and
> amfora. It's probably a bug in Lagrange.

Which version of OpenSSL is being used on the Pinebook?

So far I haven't had any luck reproducing this issue nor do I have a clearer picture of why it might be failing, but here's something we can try. On the Pinebook, run this openssl command and let's compare the output:

    openssl s_client -connect gus.guru:1965 -debug -tlsextdebug

Output from OpenSSL 1.1.1h on a Mac:

=> https://media.skyjake.fi/openssl_debug.txt

--jaakko

From me at adnano.co  Sun Oct 25 02:33:23 2020
From: me at adnano.co (Adnan Maolood)
Date: Sat, 24 Oct 2020 22:33:23 -0400
Subject: Announcing go-gemini, a Go library implementing the Gemini protocol
Message-ID: <C6LMCJV4AEG7.P1TD8IEQP1U3@nitro>

Hello! I wrote a Gemini library for Go similar to net/http.

https://sr.ht/~adnano/go-gemini

On the client side, it provides an easy-to-use TOFU implementation using
a list of known hosts (located at $XDG_DATA_HOME/gemini/known_hosts by
default). It also makes it easy for clients to provide client-side
certificates when servers request them.

TOFU is implemented following these guidelines:
https://drewdevault.com/2020/09/21/Gemini-TOFU.html
Drew and I have since agreed to conform to using
$XDG_DATA_HOME/gemini/known_hosts (or ~/.local/share/gemini/known_hosts
if $XDG_DATA_HOME is not set) as the default known hosts path, to
make it consistent between clients.

On the server side, it supports handling different schemes and hosts
(including wildcard hostnames). There is also support for parsing
gemtext and outputting it as HTML, which is useful for HTTP to Gemini
proxies.

Enjoy!

From avalos at rawtext.club  Sun Oct 25 18:35:10 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Sun, 25 Oct 2020 18:35:10 +0000
Subject: Debugging Lagrange (was Re: [ANN] Lagrange - A Beautiful Gemini
 Client)
In-Reply-To: <C4F2121F-78FB-43CC-B4B6-6BFFC432E91D@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
 <20201024190109.GA442018@rawtext.club>
 <C4F2121F-78FB-43CC-B4B6-6BFFC432E91D@dengine.net>
Message-ID: <20201025183510.GA459032@rawtext.club>

On Sun, Oct 25, 2020 at 01:15:07PM +0200, skyjake wrote:
> On 24. Oct 2020, at 22:01, avalos at rawtext.club wrote:
> 
> > On 24. Oct 2020, at 5:47, avalos at rawtext.club wrote:
> > 
> >> However, in Manjaro ARM (Pinebook Pro), sites like
> >> gemini://circumlunar.space/ and gemini://gus.guru/ for some reason
> >> don't seem to load at all. Maybe it has something to do with TLS, I'm
> >> not sure how to debug, but I'd like to help.
> > 
> > Yes, I can access those sites on other clients, such as Castor and
> > amfora. It's probably a bug in Lagrange.
> 
> Which version of OpenSSL is being used on the Pinebook?

I'm using OpenSSL 1.1.1h as well.

> So far I haven't had any luck reproducing this issue nor do I have a clearer picture of why it might be failing, but here's something we can try. On the Pinebook, run this openssl command and let's compare the output:
> 
>     openssl s_client -connect gus.guru:1965 -debug -tlsextdebug
> 
> Output from OpenSSL 1.1.1h on a Mac:
> 
> => https://media.skyjake.fi/openssl_debug.txt

Here's my output:
https://cryptpad.avalos.me/code/#/2/code/view/52l0LbI+Fo8xPNa1k8bggAOr2MTQOSIr-St+J+ceBhY/

The OpenSSL command took a lot of time to finish and print the output.

From skyjake at dengine.net  Sun Oct 25 19:47:03 2020
From: skyjake at dengine.net (skyjake)
Date: Sun, 25 Oct 2020 21:47:03 +0200
Subject: Debugging Lagrange (was Re: [ANN] Lagrange - A Beautiful Gemini
 Client)
In-Reply-To: <20201025183510.GA459032@rawtext.club>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
 <20201024190109.GA442018@rawtext.club>
 <C4F2121F-78FB-43CC-B4B6-6BFFC432E91D@dengine.net>
 <20201025183510.GA459032@rawtext.club>
Message-ID: <BDC6A439-7F74-4B17-ABA8-DF28C1F5F047@dengine.net>

On 25. Oct 2020, at 20:35, avalos at rawtext.club wrote:

>> So far I haven't had any luck reproducing this issue nor do I have a clearer picture of why it might be failing, but here's something we can try. On the Pinebook, run this openssl command and let's compare the output:
>> 
>>    openssl s_client -connect gus.guru:1965 -debug -tlsextdebug
>> 
>> Output from OpenSSL 1.1.1h on a Mac:
>> 
>> => https://media.skyjake.fi/openssl_debug.txt
> 
> Here's my output:
> https://cryptpad.avalos.me/code/#/2/code/view/52l0LbI+Fo8xPNa1k8bggAOr2MTQOSIr-St+J+ceBhY/

So far so good. At least we've verified that the behavior is indeed identical and we are using the same version of OpenSSL.

I've made some small tweaks to my TLS code. If you have a chance, could you try it with this commit: https://git.skyjake.fi/skyjake/lagrange/commit/f83ef8bfbaa5558aca5759c92c481642ac312000 

> The OpenSSL command took a lot of time to finish and print the output.

Perhaps Lagrange thinks the connection has timed out? If you run it with the "--echo" option, is there a "document.request.timeout" logged when trying to open gus.guru?

--jaakko

From vee at vnsf.xyz  Sun Oct 25 21:22:58 2020
From: vee at vnsf.xyz (vee)
Date: Sun, 25 Oct 2020 17:22:58 -0400
Subject: gus stopped indexing?
In-Reply-To: <CAJystH3fGa1S2X5qZ=A_eNTzgVOJn-Y+f8_qaXyP5+6G=aW-yg@mail.gmail.com>
References: <CAJystH3fGa1S2X5qZ=A_eNTzgVOJn-Y+f8_qaXyP5+6G=aW-yg@mail.gmail.com>
Message-ID: <42e1149a-72fb-4e45-9130-9a057c26f8ba@www.fastmail.com>

GUS is crawling right now! It takes a couple days to complete a full crawl, so I would recommend checking back in 3-5 days or so to see if it successfully updated.

After one full crawl, it should be possible to keep it updating more frequently again. It only hadn't been updated in a month because I needed a bit of a break from computers and building search engines :)

V

On Wed, Oct 21, 2020, at 04:39, P?emysl Vyhnal wrote:
> Hi, is everything ok with GUS? It says that the last index update was 
> on 2020-09-25 and it doesn't show any new pages/hosts.
> 
> Regards
> Premek

From jmcbray at carcosa.net  Mon Oct 26 00:48:24 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Sun, 25 Oct 2020 20:48:24 -0400
Subject: Can the default colors for the gemini http site be changed?
In-Reply-To: <C6KLU3VDL0B3.YYR1BSNPO6C8@stilgar> (solderpunk@posteo.net's
 message of "Fri, 23 Oct 2020 23:56:38 +0200")
References: <C6KLU3VDL0B3.YYR1BSNPO6C8@stilgar>
Message-ID: <87a6w9ak2v.fsf@cassilda.carcosa.net>

"Solderpunk" <solderpunk at posteo.net> writes:
> On Wed Oct 21, 2020 at 2:51 PM CEST, Jason McBrayer wrote:

>> The background and text are fine, actually. The red links on the
>> light olive background do not meet WCAG standards for accessible
>> text, according to the checker I ran.

> Would that be https://contrastchecker.com/? Thanks for making me aware
> that suck checkers exist, I didn't realise there were tools like that
> out there for handling this. I will change the colours this weekend to
> a scheme which meets accessibility standards.

Firefox actually has a built-in checker in the developer tools, and I
used that. It checks for some other accessibility issues, too, but that
was the only one that it found.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From cel at celehner.com  Mon Oct 26 16:17:35 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Mon, 26 Oct 2020 12:17:35 -0400
Subject: Gemini-text-to-HTML converters (was: Spec proposal)
In-Reply-To: <20201022220133.GE30302@brevard.conman.org>
References: <074c84c3153c2bc50db694083768f6af@stellarbound.space>
 <20201022220133.GE30302@brevard.conman.org>
Message-ID: <20201026121735.5ed70ae4@celehner.com>

On Thu, 22 Oct 2020 18:01:34 -0400
Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great Ali Fardan once stated:
> > Greetings follows, I just found out about gemini recently and I got
> > interested in the project and wanted to be involved, In the process
> > of setting up my gempod (that's how you call them?), I wanted to be
> > able to have an HTML/HTTP mirror for my gempod and I haven't found
> > a gemtext to HTML converter   
> 
>   Given how easy it is, I'm surprised there aren't more.  But by
> searching the mailing list, I did fine reference to two
> Gemini-text-to-HTML converters:
> 
> 	https://github.com/LukeEmmet/GemiNaut/blob/master/GemiNaut/GmiConverters/GmiToHtml.r3
> 	(written in Rebol, a blast from the past)
> 
> 	https://git.sr.ht/~sotirisp/qute-gemini
> 	(Gemini text to Markdown to HTML in python3)

dillo-gemini (gemini://celehner.com/dillo-gemini/) includes one using AWK. I pulled out the current version and put it here:
=> gemini://celehner.com/gemini-utils/gmi2html

There is also this one in Go, a previous version of which is used by the Kineto proxy I think:
=> https://git.sr.ht/~adnano/go-gemini/tree/master/text.go

Other Gemini-web proxies like Mozz.us, Vulpes, and RPoD would also have their own Gemini-text-to-HTML converters - but I don't know where the source is for those.

-- 
Charles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/f006da1c/attachment.sig>

From sir at cmpwn.com  Mon Oct 26 16:19:10 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 26 Oct 2020 12:19:10 -0400
Subject: Gemini-text-to-HTML converters (was: Spec proposal)
In-Reply-To: <20201026121735.5ed70ae4@celehner.com>
Message-ID: <C6MYJCPPBM3T.C37ZPN67RB40@taiga>

On Mon Oct 26, 2020 at 12:17 PM EDT, Charles E. Lehner wrote:
> There is also this one in Go, a previous version of which is used by the
> Kineto proxy I think:
> => https://git.sr.ht/~adnano/go-gemini/tree/master/text.go

Kineto doesn't use this. I wrote my own HTML converter:

https://git.sr.ht/~sircmpwn/kineto/tree/master/main.go

I think anything related to HTML is out of scope for a generic Gemini
library like go-gemini, and should not be included.

From me at adnano.co  Mon Oct 26 16:55:52 2020
From: me at adnano.co (Adnan Maolood)
Date: Mon, 26 Oct 2020 12:55:52 -0400
Subject: Gemini-text-to-HTML converters (was: Spec proposal)
In-Reply-To: <20201026121735.5ed70ae4@celehner.com>
Message-ID: <C6MZBGKSHVWB.2VOS6QRKTO8YM@nitro>

On Mon Oct 26, 2020 at 8:17 AM EDT, Charles E. Lehner wrote:
> There is also this one in Go, a previous version of which is used by the
> Kineto proxy I think:
> => https://git.sr.ht/~adnano/go-gemini/tree/master/text.go

I have moved this function out of the package to an example as it is
somewhat out of scope. It can now be found here:
https://git.sr.ht/~adnano/go-gemini/tree/master/examples/html.go

From cel at celehner.com  Mon Oct 26 17:16:56 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Mon, 26 Oct 2020 13:16:56 -0400
Subject: Gemini-text-to-HTML converters
In-Reply-To: <C6MYJCPPBM3T.C37ZPN67RB40@taiga>
References: <20201026121735.5ed70ae4@celehner.com>
 <C6MYJCPPBM3T.C37ZPN67RB40@taiga>
Message-ID: <20201026131656.57528d82@celehner.com>

On Mon, 26 Oct 2020 12:19:10 -0400
"Drew DeVault" <sir at cmpwn.com> wrote:

> Kineto doesn't use this. I wrote my own HTML converter:
> 
> https://git.sr.ht/~sircmpwn/kineto/tree/master/main.go

Thank you for the correction.

Also here is another Gemtext-HTML converter in Go:

https://github.com/boomlinde/gemini/blob/master/gemini/html.go

Used in https://github.com/boomlinde/gemini.filter.dpi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/6f5ef75b/attachment.sig>

From avalos at rawtext.club  Mon Oct 26 17:25:45 2020
From: avalos at rawtext.club (avalos at rawtext.club)
Date: Mon, 26 Oct 2020 17:25:45 +0000
Subject: Debugging Lagrange (was Re: [ANN] Lagrange - A Beautiful Gemini
 Client)
In-Reply-To: <BDC6A439-7F74-4B17-ABA8-DF28C1F5F047@dengine.net>
References: <C5E867F6-DC37-4E49-9414-2C4DD5056F40@dengine.net>
 <20201024024707.GA429718@rawtext.club>
 <CB5F0A3F-9E75-4115-88E9-31A066F91761@dengine.net>
 <20201024190109.GA442018@rawtext.club>
 <C4F2121F-78FB-43CC-B4B6-6BFFC432E91D@dengine.net>
 <20201025183510.GA459032@rawtext.club>
 <BDC6A439-7F74-4B17-ABA8-DF28C1F5F047@dengine.net>
Message-ID: <20201026172545.GA472190@rawtext.club>


> I've made some small tweaks to my TLS code. If you have a chance, could you try it with this commit: https://git.skyjake.fi/skyjake/lagrange/commit/f83ef8bfbaa5558aca5759c92c481642ac312000 
> 
> > The OpenSSL command took a lot of time to finish and print the output.
> 
> Perhaps Lagrange thinks the connection has timed out? If you run it with the "--echo" option, is there a "document.request.timeout" logged when trying to open gus.guru?

I tried with that commit, and with --echo option. Both gus.guru and
gemini.circumlunar.space get stuck in that command:

[command] document.request.started doc:0xaaaadb096170 url:gemini://gus.guru
[command] document.request.started doc:0xaaaadb16b930 url:gemini://gemini.circumlunar.space/

The program is still running, but it doesn't echo anything else
related to the requests. The request only starts but never updates or
finishes.

For example, this is what my gemsite shows:

[command] open url:gemini://avalos.me
[command] document.request.started doc:0xaaaadb1aa0d0 url:gemini://avalos.me
[command] document.request.updated doc:0xaaaadb1aa0d0
request:0xaaaadb1577d0 ptr:0xaaaadb1aa0d0
[command] document.request.finished doc:0xaaaadb1aa0d0
request:0xaaaadb1577d0 ptr:0xaaaadb1aa0d0
[command] open redirect:1 url:gemini://avalos.me/
[command] document.request.started doc:0xaaaadb1aa0d0 url:gemini://avalos.me/
[command] document.request.updated doc:0xaaaadb1aa0d0
request:0xaaaadb1577d0 ptr:0xaaaadb1aa0d0
[command] document.request.finished doc:0xaaaadb1aa0d0
request:0xaaaadb1577d0 ptr:0xaaaadb1aa0d0
[command] document.changed url:gemini://avalos.me/


From epoch at enzo.thebackupbox.net  Mon Oct 26 21:10:39 2020
From: epoch at enzo.thebackupbox.net (epoch)
Date: Mon, 26 Oct 2020 16:10:39 -0500
Subject: SNI
Message-ID: <20201026211039.gqeuznxo7klkckt5@enzo.thebackupbox.net>

"Use of the Server Name Indication (SNI) extension to TLS is also mandatory, to facilitate name-based virtual hosting."

Should I be refusing client requests that don't have SNI?
If so, with code 59?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/2ff03193/attachment.sig>

From sean at conman.org  Tue Oct 27 01:42:45 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 26 Oct 2020 21:42:45 -0400
Subject: Redirection limits
Message-ID: <20201027014245.GH30302@brevard.conman.org>


  At some point the limit of redirections has apparently been removed from
the Gemini specification.  I only say this because the client at
185.240.246.12 has been caught in my Redirection From Hell test for some
time (a steady pace---I'm not complaining about how fast it's doing it).

  The specification *used* to have a limit of 5 total redirections.  I think
that needs to be added back into the specificaiton.

  -spc


From cowan at ccil.org  Tue Oct 27 02:01:40 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 26 Oct 2020 22:01:40 -0400
Subject: Redirection limits
In-Reply-To: <20201027014245.GH30302@brevard.conman.org>
References: <20201027014245.GH30302@brevard.conman.org>
Message-ID: <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>

It seems to me that the limit on redirection should be purely a client
issue rather than a hardwired part of the spec.  Some clients won't want to
redirect at all, others will want to retry 1 or 5 or 100 times, depending
on what they are being used for.

On Mon, Oct 26, 2020 at 9:42 PM Sean Conner <sean at conman.org> wrote:

>
>   At some point the limit of redirections has apparently been removed from
> the Gemini specification.  I only say this because the client at
> 185.240.246.12 has been caught in my Redirection From Hell test for some
> time (a steady pace---I'm not complaining about how fast it's doing it).
>
>   The specification *used* to have a limit of 5 total redirections.  I
> think
> that needs to be added back into the specificaiton.
>
>   -spc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/5e6df582/attachment.htm>

From sean at conman.org  Tue Oct 27 02:16:30 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 26 Oct 2020 22:16:30 -0400
Subject: Redirection limits
In-Reply-To: <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>
References: <20201027014245.GH30302@brevard.conman.org>
 <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>
Message-ID: <20201027021630.GI30302@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> It seems to me that the limit on redirection should be purely a client
> issue rather than a hardwired part of the spec.  Some clients won't want to
> redirect at all, others will want to retry 1 or 5 or 100 times, depending
> on what they are being used for.

  The original limit was 5.  But 9,015 (at the precise moment) is a bit
excessive.  The limit of 5 was to help prevent the creation URL shortners
that are so prevelant on the web.

  Ah, I see that the limit is now mentioned in the Best Practices document,
not the specification.  Still, a clent *should* give up redirections past
some amount (11,329 as of now).

  -spc (11430 ... )




From cowan at ccil.org  Tue Oct 27 02:34:39 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 26 Oct 2020 22:34:39 -0400
Subject: Redirection limits
In-Reply-To: <20201027021630.GI30302@brevard.conman.org>
References: <20201027014245.GH30302@brevard.conman.org>
 <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>
 <20201027021630.GI30302@brevard.conman.org>
Message-ID: <CAD2gp_ROpOO5dqz7R9xj39+MFPvPkf7pZiwm8b3cFaaPH+N_OQ@mail.gmail.com>

A good point.  But a well-written Gemini shortener would retrieve the URL
it is being asked to shorten and make sure that it is not already a
redirection; if so, it can either reject or snap the link (although Gemini
redirects are officially temporary, there may be exceptions in practice).

On Mon, Oct 26, 2020 at 10:16 PM Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great John Cowan once stated:
> > It seems to me that the limit on redirection should be purely a client
> > issue rather than a hardwired part of the spec.  Some clients won't want
> to
> > redirect at all, others will want to retry 1 or 5 or 100 times, depending
> > on what they are being used for.
>
>   The original limit was 5.  But 9,015 (at the precise moment) is a bit
> excessive.  The limit of 5 was to help prevent the creation URL shortners
> that are so prevelant on the web.
>
>   Ah, I see that the limit is now mentioned in the Best Practices document,
> not the specification.  Still, a clent *should* give up redirections past
> some amount (11,329 as of now).
>
>   -spc (11430 ... )
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/bce0211e/attachment.htm>

From cowan at ccil.org  Tue Oct 27 02:38:28 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 26 Oct 2020 22:38:28 -0400
Subject: Empty results
Message-ID: <CAD2gp_SGJAMWfBqpLWTgHuQ0qWsRmQHmA1JtmPbpiYP-gprRzw@mail.gmail.com>

If there is ever a reason to return an empty result, the semi-official MIME
type is inode/x-empty, as "touch /tmp/empty; file --mime /tmp/empty" will
report.  But of course empty text/plain, text/gemini, text/html, etc. are
perfectly valid too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/8e16ce75/attachment.htm>

From gmym at coopdot.com  Tue Oct 27 03:36:19 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Tue, 27 Oct 2020 04:36:19 +0100
Subject: A question regarding the spec
In-Reply-To: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
References: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
Message-ID: <CAObwWNgYAaE0UrDukFgc1NM+eTpKqnMb_7LeUaLS84Cz1gCpNQ@mail.gmail.com>

Ali Fardan <raiz at stellarbound.space> wrote:

>
> now I'm wondering if this applies to headings to,
> as in the whitespace after #, ## and ###.
>

Yes, you can line them up if you want. Like so:

```
#   Heading 1
##  Heading 1:1
### Heading 1:1:1
```

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/6a1e81e1/attachment.htm>

From raiz at stellarbound.space  Tue Oct 27 08:02:48 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 27 Oct 2020 11:02:48 +0300
Subject: A question regarding the spec
In-Reply-To: <CAObwWNgYAaE0UrDukFgc1NM+eTpKqnMb_7LeUaLS84Cz1gCpNQ@mail.gmail.com>
References: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
 <CAObwWNgYAaE0UrDukFgc1NM+eTpKqnMb_7LeUaLS84Cz1gCpNQ@mail.gmail.com>
Message-ID: <26e28e8fef6198bac6c2faa51339dd54@stellarbound.space>

On 2020-10-27 06:36, Katarina Eriksson wrote:
> Ali Fardan <raiz at stellarbound.space> wrote:
> 
>> 
>> now I'm wondering if this applies to headings to,
>> as in the whitespace after #, ## and ###.
>> 
> 
> Yes, you can line them up if you want. Like so:
> 
> ```
> #   Heading 1
> ##  Heading 1:1
> ### Heading 1:1:1
> ```

Thanks for clarifying.

From kevin at susa.net  Tue Oct 27 11:04:20 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 27 Oct 2020 11:04:20 +0000
Subject: Redirection limits
In-Reply-To: <20201027021630.GI30302@brevard.conman.org>
References: <20201027014245.GH30302@brevard.conman.org>
 <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>
 <20201027021630.GI30302@brevard.conman.org>
Message-ID: <CAPk6LxTTUT7CRXe4ijDH5yyzuWzFTLG+duXt1L9WsJMeQLV9BQ@mail.gmail.com>

If your test is simulating a faulty server, there's as much responsibility
on your code to give some indication of failure as there is on a client to
detect the condition.

I'd suggest something less than 11,430, were I to be asked.

Kevin

Sent from phone

On Tue, 27 Oct 2020, 02:16 Sean Conner, <sean at conman.org> wrote:

> It was thus said that the Great John Cowan once stated:
> > It seems to me that the limit on redirection should be purely a client
> > issue rather than a hardwired part of the spec.  Some clients won't want
> to
> > redirect at all, others will want to retry 1 or 5 or 100 times, depending
> > on what they are being used for.
>
>   The original limit was 5.  But 9,015 (at the precise moment) is a bit
> excessive.  The limit of 5 was to help prevent the creation URL shortners
> that are so prevelant on the web.
>
>   Ah, I see that the limit is now mentioned in the Best Practices document,
> not the specification.  Still, a clent *should* give up redirections past
> some amount (11,329 as of now).
>
>   -spc (11430 ... )
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/3066bbdd/attachment.htm>

From linde.philip at gmail.com  Tue Oct 27 17:28:17 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 27 Oct 2020 18:28:17 +0100
Subject: Redirection limits
In-Reply-To: <20201027014245.GH30302@brevard.conman.org>
References: <20201027014245.GH30302@brevard.conman.org>
Message-ID: <20201027182817.a62f919850fa1472cc7730d5@gmail.com>

On Mon, 26 Oct 2020 21:42:45 -0400
Sean Conner <sean at conman.org> wrote:

>   The specification *used* to have a limit of 5 total redirections.  I think
> that needs to be added back into the specificaiton.

Perhaps <=5 should be specified. For now, there is at least a
recommendation for it in the best practices document:
gemini://gemini.circumlunar.space/docs/best-practices.gmi

I'm not entirely convinced that automatic redirects are good. Manual
redirects that present the users with a link to the redirection target
could be unlimited and still make it more obvious to users when they're
thrown about.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/9cfa7f9f/attachment.sig>

From cowan at ccil.org  Tue Oct 27 17:31:36 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 27 Oct 2020 13:31:36 -0400
Subject: Redirection limits
In-Reply-To: <20201027182817.a62f919850fa1472cc7730d5@gmail.com>
References: <20201027014245.GH30302@brevard.conman.org>
 <20201027182817.a62f919850fa1472cc7730d5@gmail.com>
Message-ID: <CAD2gp_QZ3ZEgzdNUJfr_1T0c2yLr6s+k+_9M6TQ7zrGs9C=u6w@mail.gmail.com>

On Tue, Oct 27, 2020 at 1:28 PM Philip Linde <linde.philip at gmail.com> wrote:


> I'm not entirely convinced that automatic redirects are good. Manual
> redirects that present the users with a link to the redirection target
> could be unlimited and still make it more obvious to users when they're
> thrown about.
>

Not all clients have human users attached, though.  Crawlers and other
automated applications need to make their own decisions when to stop.

Which reminds me: what is the best thing for such an application to do when
it gets a 1x response?



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Heh, heh: ... or three pairs of wheels? I wonder what would have happened
if Ravna had just read a little further. In some weird way, Twirlip
knows the Secret of the Riders.   --Vernor Vinge, note 601
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/d3a8dfc8/attachment.htm>

From linde.philip at gmail.com  Tue Oct 27 17:54:24 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 27 Oct 2020 18:54:24 +0100
Subject: Redirection limits
In-Reply-To: <CAD2gp_QZ3ZEgzdNUJfr_1T0c2yLr6s+k+_9M6TQ7zrGs9C=u6w@mail.gmail.com>
References: <20201027014245.GH30302@brevard.conman.org>
 <20201027182817.a62f919850fa1472cc7730d5@gmail.com>
 <CAD2gp_QZ3ZEgzdNUJfr_1T0c2yLr6s+k+_9M6TQ7zrGs9C=u6w@mail.gmail.com>
Message-ID: <20201027185424.a997e6cb021947d68732ddc6@gmail.com>

On Tue, 27 Oct 2020 13:31:36 -0400
John Cowan <cowan at ccil.org> wrote:

> Not all clients have human users attached, though.  Crawlers and other
> automated applications need to make their own decisions when to stop.

Yes, I think its reasonable for a crawler to decide for itself how many
redirects it wants to follow, in the same sense that it's reasonable for
a user.

> Which reminds me: what is the best thing for such an application to do when
> it gets a 1x response?

To interpret the spec strictly, a client should display the query to
the user, and should then request the same resource with the user's
input included. This is impossible for a client that doesn't interact
with a user, so a crawler should just ignore 1x responses.

This seems like the best approach practically as well. There is no set
of standard queries that the crawler can safely interpret to mean
something it can answer.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/1250e0f5/attachment.sig>

From cage-dev at twistfold.it  Tue Oct 27 18:23:07 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 27 Oct 2020 19:23:07 +0100
Subject: [ANN] tinmop 0.3.0 released
Message-ID: <20201027182307.GA4732@kurosawa.casa.net>

Hi!

I just released a new version (0.3.0) of tinmop, an opinionated client
for  pleroma (using  the  mastodon  API) and  gemini  with a  terminal
interface.

https://www.autistici.org/interzona/tinmop.html

This version added  client authentication for gemini  and include some
bugfixes (and the client passes the client torture tests, again! :)).

Tinmop is free software released under GPLv3 or later.

Enjoy!
C.

From sean at conman.org  Tue Oct 27 18:27:59 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 27 Oct 2020 14:27:59 -0400
Subject: Redirection limits
In-Reply-To: <CAPk6LxTTUT7CRXe4ijDH5yyzuWzFTLG+duXt1L9WsJMeQLV9BQ@mail.gmail.com>
References: <20201027014245.GH30302@brevard.conman.org>
 <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>
 <20201027021630.GI30302@brevard.conman.org>
 <CAPk6LxTTUT7CRXe4ijDH5yyzuWzFTLG+duXt1L9WsJMeQLV9BQ@mail.gmail.com>
Message-ID: <20201027182759.GJ30302@brevard.conman.org>

It was thus said that the Great Kevin Sangeelee once stated:
> If your test is simulating a faulty server, 

  It's not so much simulating a faulty server as it is simulating an
infinite nymber of redirects.  It could possibly be server A -> server B ->
server C -> server D -> server E -> server A (repeat).

> there's as much responsibility
> on your code to give some indication of failure as there is on a client to
> detect the condition.

  How?  Given that a redirection loop can exist across servers.

> I'd suggest something less than 11,430, were I to be asked.

  So would I.

  -spc


From kevin at susa.net  Tue Oct 27 20:27:36 2020
From: kevin at susa.net (Kevin Sangeelee)
Date: Tue, 27 Oct 2020 20:27:36 +0000
Subject: Redirection limits
In-Reply-To: <20201027182759.GJ30302@brevard.conman.org>
References: <20201027014245.GH30302@brevard.conman.org>
 <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>
 <20201027021630.GI30302@brevard.conman.org>
 <CAPk6LxTTUT7CRXe4ijDH5yyzuWzFTLG+duXt1L9WsJMeQLV9BQ@mail.gmail.com>
 <20201027182759.GJ30302@brevard.conman.org>
Message-ID: <CAPk6LxQ4v7-YY1HCePVPxJn+98=pfkduTVS2zqw0wRfs5=hUGg@mail.gmail.com>

It was consequently queried by the Kind and Honourable Sean Conner:

  How?  Given that a redirection loop can exist across servers.
>

The link '/test/redirhell/' generates some unique hex for each new redirect
path, which could alternatively have the hex preserved across redirects,
but with a counter that's incremented instead. If the counter exceeds, say
11428, then return a '50 YOU ARE DRIVING ME NUTS' response code.

As I understand it, the redirhell test redirects back to itself, not across
servers - my reply was more in sympathy with your server than with the
unrelenting client. I'm grateful for your implement of torture, it's been
very useful!

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/8e661808/attachment.htm>

From sean at conman.org  Tue Oct 27 22:07:30 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 27 Oct 2020 18:07:30 -0400
Subject: Redirection limits
In-Reply-To: <CAPk6LxQ4v7-YY1HCePVPxJn+98=pfkduTVS2zqw0wRfs5=hUGg@mail.gmail.com>
References: <20201027014245.GH30302@brevard.conman.org>
 <CAD2gp_R25MVpOe37o9zT2aAezpNqMvQVzB5k+qvW7muu+D2v9w@mail.gmail.com>
 <20201027021630.GI30302@brevard.conman.org>
 <CAPk6LxTTUT7CRXe4ijDH5yyzuWzFTLG+duXt1L9WsJMeQLV9BQ@mail.gmail.com>
 <20201027182759.GJ30302@brevard.conman.org>
 <CAPk6LxQ4v7-YY1HCePVPxJn+98=pfkduTVS2zqw0wRfs5=hUGg@mail.gmail.com>
Message-ID: <20201027220730.GK30302@brevard.conman.org>

It was thus said that the Great Kevin Sangeelee once stated:
> It was consequently queried by the Kind and Honourable Sean Conner:
> 
> >  How?  Given that a redirection loop can exist across servers.
> 
> The link '/test/redirhell/' generates some unique hex for each new redirect
> path, which could alternatively have the hex preserved across redirects,
> but with a counter that's incremented instead. If the counter exceeds, say
> 11428, then return a '50 YOU ARE DRIVING ME NUTS' response code.
> 
> As I understand it, the redirhell test redirects back to itself, not across
> servers - my reply was more in sympathy with your server than with the
> unrelenting client. 

  It wasn't "driving me nuts" as in "oh my God!  My server is melting under
the load!" but more of a "oh, it looks like someone wrote an automated
client and didn't limit redirections."  Yes, I'll see clients being tested
and get caught in the Redirection Hell test, but those tend to make perhaps
a few dozen requests before stopping.  It was clear to me that the author of
the particular client didn't test for infinite redirections, and the only
way I can bring the issue up is on the mailing list.

> I'm grateful for your implement of torture, it's been very useful!

  You're welcome.  If you can think of any other tests that might be
helpful, please don't hesitate to let me know.

  -spc

From root at thesudorm.com  Wed Oct 28 11:28:51 2020
From: root at thesudorm.com (Joseph Bauer)
Date: Wed, 28 Oct 2020 07:28:51 -0400 (EDT)
Subject: [ANN] New Personal Server: thesudorm.com
Message-ID: <1104878226.511737.1603884531991@privateemail.com>

Hello all,

I just recently found out about Gemini and set up a server on a whim. You can find it on gemini://thesudorm.com . I don't have any grand plans for this space. I think it will mostly be a blog about whatever I find interesting at the moment. I'm looking forward to lurking and contributing what I can.

Shoutout to the author of agate. Set up was a breeze. :)

joey

From jrhorn424 at gmail.com  Wed Oct 28 14:58:44 2020
From: jrhorn424 at gmail.com (Jeffrey Horn)
Date: Wed, 28 Oct 2020 10:58:44 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
References: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
Message-ID: <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>

On Sun, Oct 25, 2020 at 7:02 AM Ali Fardan <raiz at stellarbound.space> wrote:
> I was browsing gemspace using netcat ...

This made me curious so I started up netcat. According to the spec,
the request is `<URI> <CR> <LF>`. I thought this was correct, but I
just lose the connection when sending the line feed:

```
$ nc gemini.circumlunar.space 1965
gemini://gemini.circumlunar.space/
$
```

Any suggestions?

-- 
jeff

From sir at cmpwn.com  Wed Oct 28 15:00:12 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 28 Oct 2020 11:00:12 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>
Message-ID: <C6OM3ZO1SACY.3E3LLYYVC5LQD@taiga>

On Wed Oct 28, 2020 at 10:58 AM EDT, Jeffrey Horn wrote:
> On Sun, Oct 25, 2020 at 7:02 AM Ali Fardan <raiz at stellarbound.space>
> wrote:
> > I was browsing gemspace using netcat ...
>
> This made me curious so I started up netcat. According to the spec,
> the request is `<URI> <CR> <LF>`. I thought this was correct, but I
> just lose the connection when sending the line feed:

SSL. Try this:

openssl s_client -servername example.org -connect example.org:1965

From jrhorn424 at gmail.com  Wed Oct 28 15:08:41 2020
From: jrhorn424 at gmail.com (Jeffrey Horn)
Date: Wed, 28 Oct 2020 11:08:41 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <C6OM3ZO1SACY.3E3LLYYVC5LQD@taiga>
References: <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>
 <C6OM3ZO1SACY.3E3LLYYVC5LQD@taiga>
Message-ID: <CA+K2SAzbN5nKu3hURKEzF1s+NKnqh7cbncuMSUz5655YWJ-1qA@mail.gmail.com>

On Wed, Oct 28, 2020 at 11:00 AM Drew DeVault <sir at cmpwn.com> wrote:
> openssl s_client -servername example.org -connect example.org:1965

This worked well, thank you!

-- 
jeff

From smallick.dev at gmail.com  Wed Oct 28 15:57:11 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Wed, 28 Oct 2020 21:27:11 +0530
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>
References: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
 <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>
Message-ID: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>

On OpenBSD, I tried (after having a quick read of nc manpage) this:


$ nc -cv -Tnoverify gemini.circumlunar.space 1965


Well, when first I typed in

gemini.circumlunar.space

in that, I got an 53. Then I tried

gemini://gemini.circumlunar.space

and got

31 gemini://gemini.circumlunar.space/

and then did ''as directed'' to get the real page.

Why was I getting 53 there? Any idea?

From chris at vittal.dev  Wed Oct 28 16:04:28 2020
From: chris at vittal.dev (Chris Vittal)
Date: Wed, 28 Oct 2020 12:04:28 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>
Message-ID: <C6ONH747WEIK.34JIV4PZ2U75X@enki>

On Wed Oct 28, 2020 at 11:57 AM EDT, Sudipto Mallick wrote:
> On OpenBSD, I tried (after having a quick read of nc manpage) this:
>
> Well, when first I typed in
>
> gemini.circumlunar.space
>
> in that, I got an 53. Then I tried
>
> Why was I getting 53 there? Any idea?

A properly formed gemini request is a fully qualified URL with a scheme
and authority.

Hope that helps!

Chris

From smallick.dev at gmail.com  Wed Oct 28 16:48:15 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Wed, 28 Oct 2020 22:18:15 +0530
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <C6ONH747WEIK.34JIV4PZ2U75X@enki>
References: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>
 <C6ONH747WEIK.34JIV4PZ2U75X@enki>
Message-ID: <CAFaUHvJiryPXO1BLwg6fyD6bJRkixctU3QjRNnCLbCTMNfRN9g@mail.gmail.com>

On 10/28/20, Chris Vittal <chris at vittal.dev> wrote:
> A properly formed gemini request is a fully qualified URL with a scheme
> and authority.

Let me quote from the Gemini protocol specification:

2 Gemini Requests

Gemini requests are a single CRLF-terminated line with the following structure:

<URL><CR><LF>

<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
**If the scheme of the URL is not specified, a scheme of gemini:// is
implied.**
(Emphasis mine.)

Please clarify what should it be.

From linde.philip at gmail.com  Wed Oct 28 16:49:49 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 28 Oct 2020 17:49:49 +0100
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <C6ONH747WEIK.34JIV4PZ2U75X@enki>
References: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>
 <C6ONH747WEIK.34JIV4PZ2U75X@enki>
Message-ID: <20201028174949.3aacb57db999f1cc8247b764@gmail.com>

On Wed, 28 Oct 2020 12:04:28 -0400
"Chris Vittal" <chris at vittal.dev> wrote:

> A properly formed gemini request is a fully qualified URL with a scheme
> and authority.

Not in this case. In a request, it is only necessary to specify the
authority and optionally a path. From the spec (0.14.2):

> If the scheme of the URL is not specified, a scheme of gemini:// is
> implied.

So the server really should treat both requests as equivalent.

Furthermore, I think it's wrong of the server not to serve the same
resource for "gemini.circumlunar.space" and "gemini.circumlunar.space/".
The spec says that the URI is syntactically compatible with the generic
URI syntax except that the userinfo subcomponent of the generic
authority is not allowed. Serving different content for "/" and
unspecified path is another difference from the generic URI syntax that
is not specified. RFC 3986:

> In general, a URI that uses the generic syntax for authority with an
> empty path should be normalized to a path of "/".

This is a should and not a must, but I also think it's bad behavior
practically to force a client to make another request for something
that should really be an implementation detail in the server. I also
don't see any practical reasons one might want to distinguish the two.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201028/31efaa61/attachment.sig>

From me at adnano.co  Wed Oct 28 17:07:31 2020
From: me at adnano.co (Adnan Maolood)
Date: Wed, 28 Oct 2020 13:07:31 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <20201028174949.3aacb57db999f1cc8247b764@gmail.com>
Message-ID: <C6OOTGX1NN38.MLM370QFCJNJ@nitro>

On Wed Oct 28, 2020 at 1:49 PM EDT, Philip Linde wrote:
> On Wed, 28 Oct 2020 12:04:28 -0400
> "Chris Vittal" <chris at vittal.dev> wrote:
>
> > A properly formed gemini request is a fully qualified URL with a scheme
> > and authority.
>
> Not in this case. In a request, it is only necessary to specify the
> authority and optionally a path. From the spec (0.14.2):
>
> > If the scheme of the URL is not specified, a scheme of gemini:// is
> > implied.
>
> So the server really should treat both requests as equivalent.

I believe that the reason this doesn't work is because
"gemini.circumlunar.space" is treated as a relative path with no
authority. Making a request for "//gemini.circumlunar.space" works.
Perhaps this should be clarified in the specification.
Or perhaps schemes should always be required to avoid confusion.

From chris at vittal.dev  Wed Oct 28 17:51:50 2020
From: chris at vittal.dev (Chris Vittal)
Date: Wed, 28 Oct 2020 13:51:50 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <CAFaUHvJiryPXO1BLwg6fyD6bJRkixctU3QjRNnCLbCTMNfRN9g@mail.gmail.com>
References: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>
 <C6ONH747WEIK.34JIV4PZ2U75X@enki>
 <CAFaUHvJiryPXO1BLwg6fyD6bJRkixctU3QjRNnCLbCTMNfRN9g@mail.gmail.com>
Message-ID: <0e750eba-b2c1-e30a-1a98-5c2cb52a1e88@vittal.dev>

> **If the scheme of the URL is not specified, a scheme of gemini:// is
> implied.**
> (Emphasis mine.)

That is correct. I misspoke. Apologies

The issue here is that the URL text of 'gemini.circumlunar.space' is not 
an absolute URL. It has no scheme, no authority, and a path of 
'gemini.circumlunar.space'. The spec does state that the scheme is 
unnecessary, but the authority is.

 From the spec:
> This scheme is syntactically compatible with the generic URI syntax defined in RFC 3986, but does not support all components of the generic syntax. In particular, the authority component is allowed and required
Even setting the scheme to gemini, 'gemini.circumlunar.space' would be 
treated as 'gemini:gemini.circumlunar.space', so still with no 
authority, rather than what we want, which would be 
'gemini://gemini.circumlunar.space' stripping the scheme off of this, we 
get '//gemini.circumlunar.space' which I have no idea if servers will 
properly handle.

Chris

From linde.philip at gmail.com  Wed Oct 28 18:22:13 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 28 Oct 2020 19:22:13 +0100
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <0e750eba-b2c1-e30a-1a98-5c2cb52a1e88@vittal.dev>
References: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>
 <C6ONH747WEIK.34JIV4PZ2U75X@enki>
 <CAFaUHvJiryPXO1BLwg6fyD6bJRkixctU3QjRNnCLbCTMNfRN9g@mail.gmail.com>
 <0e750eba-b2c1-e30a-1a98-5c2cb52a1e88@vittal.dev>
Message-ID: <20201028192213.87054eb0c574641030efbcff@gmail.com>

On Wed, 28 Oct 2020 13:51:50 -0400
Chris Vittal <chris at vittal.dev> wrote:

> The issue here is that the URL text of 'gemini.circumlunar.space' is not 
> an absolute URL. It has no scheme, no authority, and a path of 
> 'gemini.circumlunar.space'. The spec does state that the scheme is 
> unnecessary, but the authority is.

I think the confusion around this stems from the phrasing in the Gemini
spec where on one hand it says that the scheme may be omitted but on
the other hand that in that case "gemini://" is implied, which in its
whole is more than just the scheme.

Strictly speaking, ":" is not part of the scheme, (and "//" is not part
of the authority), so what we'd really end up with when omitting the
scheme from the absolute URI is "://gemini.circumlunar.space".

"//gemini.circumlunar.space" is only defined in RFC 3986 as a "relative
reference" as opposed to an "absolute URI".

The Gemini spec could really use some clarification here, guided by a
careful reading of RFC 3986 in order to get the terminology right and
define the allowed syntax in those terms.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201028/76f79d98/attachment.sig>

From anothersms at gmail.com  Wed Oct 28 15:11:46 2020
From: anothersms at gmail.com (=?utf-8?Q?Nicol=C3=B2?= Balzarotti)
Date: Wed, 28 Oct 2020 16:11:46 +0100
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>
References: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
 <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>
Message-ID: <875z6umll9.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>

Jeffrey Horn <jrhorn424 at gmail.com> writes:

Hi, I don't think netcat does tls.  One thing you could do is to use
openssl:

#+begin_src bash
echo -e "gemini://gemini.circumlunar.space:1965/\r\n" | openssl s_client -connect gemini.circumlunar.space:1965 -ign_eof
#+end_src

this command establishes a connection, sends <URL><CR><LF> and then
reads the response ("20 text/gemini")



> On Sun, Oct 25, 2020 at 7:02 AM Ali Fardan <raiz at stellarbound.space> wrote:
>> I was browsing gemspace using netcat ...
>
> This made me curious so I started up netcat. According to the spec,
> the request is `<URI> <CR> <LF>`. I thought this was correct, but I
> just lose the connection when sending the line feed:
>
> ```
> $ nc gemini.circumlunar.space 1965
> gemini://gemini.circumlunar.space/
> $
> ```
>
> Any suggestions?
>
> -- 
> jeff

From lambdatronic at disroot.org  Wed Oct 28 19:20:53 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Wed, 28 Oct 2020 15:20:53 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <C6OOTGX1NN38.MLM370QFCJNJ@nitro>
References: <20201028174949.3aacb57db999f1cc8247b764@gmail.com>
 <C6OOTGX1NN38.MLM370QFCJNJ@nitro>
Message-ID: <87mu06nomi.fsf@disroot.org>

Netcat (ncat) does support SSL connections with the --ssl flag.

Here's my little "gemget" Guile script I wrote that lets me poke around
Geminispace from the command line whenever I'm not inside a proper
Gemini client. It's also useful for scripting in situations where you
might use wget with HTTP(S).

-----------------------------------------------------------------------------
#!/usr/bin/env guile
!#

(let ((args (command-line)))
  (if (not (= 2 (length args)))
      (display "Usage: gemget <GEMINI_URL>\n")
      (let ((url (cadr args)))
        (if (not (string-prefix? "gemini://" url))
            (display "GEMINI_URL should begin with gemini://\n")
            (let ((server (caddr (string-split url #\/))))
              (system (simple-format #f "echo ~S | ncat --ssl ~S 1965" url server)))))))
-----------------------------------------------------------------------------

Just save this in a file called gemget somewhere on your PATH and you
can use it like this:

-----------------------------------------------------------------------------
gjohnson at euclid ~ $ gemget gemini://gemini.circumlunar.space/
20 text/gemini
# Project Gemini

## Overview

Gemini is a new internet protocol which:

* Is heavier than gopher
* Is lighter than the web
* Will not replace either
* Strives for maximum power to weight ratio
* Takes user privacy very seriously

## Resources

=> docs/	Gemini documentation
=> software/	Gemini software
=> servers/	Known Gemini servers
=> https://lists.orbitalfox.eu/listinfo/gemini	Gemini mailing list
=> gemini://gemini.conman.org/test/torture/	Gemini client torture test

## Web proxies

=> https://portal.mozz.us/?url=gemini%3A%2F%2Fgemini.circumlunar.space%2F&fmt=fixed	Gemini-to-web proxy service
=> https://proxy.vulpes.one/gemini/gemini.circumlunar.space	Another Gemini-to-web proxy service

## Search engines

=> gemini://gus.guru/	Gemini Universal Search engine
=> gemini://houston.coder.town	Houston search engine

## Geminispace aggregators

=> capcom/	CAPCOM
=> gemini://rawtext.club:1965/~sloum/spacewalk.gmi	Spacewalk

## Gemini mirrors of web resources

=> gemini://gempaper.strangled.net/mirrorlist/	A list of mirrored services

## Free Gemini hosting

=> users/	Users with Gemini content on this server
-----------------------------------------------------------------------------

Have fun and happy hacking!
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From sir at cmpwn.com  Wed Oct 28 19:23:04 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 28 Oct 2020 15:23:04 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <87mu06nomi.fsf@disroot.org>
Message-ID: <C6ORP96VL04N.1V59ENC3HF0GJ@taiga>

On Wed Oct 28, 2020 at 3:20 PM EDT, Gary Johnson wrote:
> Netcat (ncat) does support SSL connections with the --ssl flag.

Only GNU netcat, also known as worst netcat.

From smallick.dev at gmail.com  Wed Oct 28 20:01:33 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Thu, 29 Oct 2020 01:31:33 +0530
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <C6ORP96VL04N.1V59ENC3HF0GJ@taiga>
References: <87mu06nomi.fsf@disroot.org> <C6ORP96VL04N.1V59ENC3HF0GJ@taiga>
Message-ID: <CAFaUHvKjBMoP3Tfqy85xXnEQj5i9qi2XKjtFQ0pBCPVLeYePkg@mail.gmail.com>

On 10/29/20, Drew DeVault <sir at cmpwn.com> wrote:
> On Wed Oct 28, 2020 at 3:20 PM EDT, Gary Johnson wrote:
>> Netcat (ncat) does support SSL connections with the --ssl flag.
>
> Only GNU netcat, also known as worst netcat.
>
The OpenBSD netcat supports TLS with the -c flag.

By the way, how lucky am I?! https://builds.sr.ht/~smallick/job/330000

From sir at cmpwn.com  Wed Oct 28 20:03:48 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 28 Oct 2020 16:03:48 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <CAFaUHvKjBMoP3Tfqy85xXnEQj5i9qi2XKjtFQ0pBCPVLeYePkg@mail.gmail.com>
Message-ID: <C6OSKFMH2YWV.2PYU61AWL9982@taiga>

On Wed Oct 28, 2020 at 4:01 PM EDT, Sudipto Mallick wrote:
> The OpenBSD netcat supports TLS with the -c flag.

Hm, not my distribution of OpenBSD netcat.

> By the way, how lucky am I?! https://builds.sr.ht/~smallick/job/330000

Not as lucky as 333333 will be

From sean at conman.org  Wed Oct 28 21:59:21 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 28 Oct 2020 17:59:21 -0400
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <20201028174949.3aacb57db999f1cc8247b764@gmail.com>
References: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>
 <C6ONH747WEIK.34JIV4PZ2U75X@enki>
 <20201028174949.3aacb57db999f1cc8247b764@gmail.com>
Message-ID: <20201028215921.GL30302@brevard.conman.org>

It was thus said that the Great Philip Linde once stated:
> On Wed, 28 Oct 2020 12:04:28 -0400
> "Chris Vittal" <chris at vittal.dev> wrote:
> 
> > A properly formed gemini request is a fully qualified URL with a scheme
> > and authority.
> 
> Not in this case. In a request, it is only necessary to specify the
> authority and optionally a path. From the spec (0.14.2):
> 
> > If the scheme of the URL is not specified, a scheme of gemini:// is
> > implied.
> 
> So the server really should treat both requests as equivalent.

  The specification is technically incorrect, at least in my reading of the
RFC and specifically of the BNF of the URL (I say, having written a URL
parser based closely on the BNF [1]).  The BNF starts [2]

   URI-reference = URI / relative-ref

   URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty

   relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

   relative-part = "//" authority path-abempty
                 / path-absolute
                 / path-noscheme
                 / path-empty

  The specification should say:

	If the scheme of the URL is not specified, a scheme of gemini: is
	implied.

> Furthermore, I think it's wrong of the server not to serve the same
> resource for "gemini.circumlunar.space" and "gemini.circumlunar.space/".

  I'm not aware of any server that does otherwise.  There are servers out
there that play around with trailing '/'  elsewhere in the URL [3], but not
at the root.

  -spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

[2]	The URI-reference rule is listed third---I think this is a mistake
	on the part of the RFC,

[3]	gemini://gemini.conman.org/test/doc1
	gemini://gemini.conman.org/test/doc1/

From linde.philip at gmail.com  Wed Oct 28 23:31:09 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Thu, 29 Oct 2020 00:31:09 +0100
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <20201028215921.GL30302@brevard.conman.org>
References: <CAFaUHvKU24zm7gKqDE7us7G+k4b1caOsCdi1p+ebDPS4dJnH2w@mail.gmail.com>
 <C6ONH747WEIK.34JIV4PZ2U75X@enki>
 <20201028174949.3aacb57db999f1cc8247b764@gmail.com>
 <20201028215921.GL30302@brevard.conman.org>
Message-ID: <20201029003109.ac9266d2e5b032b602820651@gmail.com>

On Wed, 28 Oct 2020 17:59:21 -0400
Sean Conner <sean at conman.org> wrote:

>   The specification should say:
> 
> 	If the scheme of the URL is not specified, a scheme of gemini: is
> 	implied.
>

The colon also isn't part of the scheme, but the URI as a whole. If one
can omit both the scheme and the colon, then the slightly adjusted
"absolute URL" becomes what RFC 3986 calls a "relative reference",
e.g. "//gemini.circumlunar.space". Omitting the scheme from an absolute
URI (which I assume is what the Gemini spec refers to with
"absolute URL") would leave us with "://gemini.circumlunar.space".

Both our conclusions require similarly liberal interpretation of the
Gemini spec, though your interpretation is easier to describe in terms
of modifications to the rules already defined in RFC 3986.

>   I'm not aware of any server that does otherwise.  There are servers out
> there that play around with trailing '/'  elsewhere in the URL [3], but not
> at the root.

As demonstrated by Sudipto Mallick above, gemini.circumlunar.space does
otherwise. Request "gemini://gemini.circumlunar.space" and you get one
response (a 31 redirect code), but if you request
"gemini://gemini.circumlunar.space/" you get a code 20 response with
the landing page. The URIs are not treated as equivalent, which they
should be after normalization.

The path isn't normalized in the same way, so it's not a concern there.

> [2]	The URI-reference rule is listed third---I think this is a mistake
> 	on the part of the RFC,

The order of the ABNF rules in the appendix bears no significance to
their interpretation. The rule named "URI" defines the URI syntax. The
rule named "URI-reference" defines a syntax for a sequence that is
either a URI or a relative reference. Gemini requests by my
interpretation uses neither, but the rule named "absolute-URI" (to
disallow fragments?), modified so that

  authority = host [ ":" port ]

and with the note about implied scheme, which interpreted literally
would normalize "://example.com" to "gemini://://example.com" and would
accept neither "example.com" nor "//example.com".

By your interpretation (which I agree makes most sense) it is more
succinct and correct to describe the Gemini URL as an RFC 3986 "URI"
with the rules modified so that

  URI           = [ scheme ":" ] hier-part [ "?" query ]
  authority     = host [ ":" port ]

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201029/0b5b9bec/attachment-0001.sig>

From jhiggs at eml.cc  Fri Oct 30 04:40:43 2020
From: jhiggs at eml.cc (Jon Higgs)
Date: Fri, 30 Oct 2020 15:40:43 +1100
Subject: [ANN] New Personal Server: thesudorm.com
In-Reply-To: <1104878226.511737.1603884531991@privateemail.com>
References: <1104878226.511737.1603884531991@privateemail.com>
Message-ID: <20201030044043.7ywwf445dool6a7x@devbox>

On 28/10/20 07:28, Joseph Bauer wrote:
> Hello all,
> 
> I just recently found out about Gemini and set up a server on a whim.
> You can find it on gemini://thesudorm.com . I don't have any grand
> plans for this space. I think it will mostly be a blog about whatever
> I find interesting at the moment. I'm looking forward to lurking and
> contributing what I can.
> 
> Shoutout to the author of agate. Set up was a breeze. :)
> 
> joey

I spent a few hours today in setting up Gemini blog too
(gemini://shit.cx). I choose agate based on your recommendation and I
completely agree; its a breeze. What's more, its a 2MB statically
compiled rust binary. I have committed the binary to the repo with the
articles. Deploying changes to either the content or infra is as simple
as a `git pull && systemctl agate.service restart`.

Thank you for the recommendation, and if the author of agate is here,
thank you for agate.

-- 
Jon

From raiz at stellarbound.space  Fri Oct 30 08:46:54 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Fri, 30 Oct 2020 11:46:54 +0300
Subject: Using netcat with gemini (was Re: A question regarding the spec)
In-Reply-To: <875z6umll9.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
References: <16c281202004cce21a05c27d5ee59d13@stellarbound.space>
 <CA+K2SAw28vKHONt1NJJK5A58Cgc_6thV6DEOz6B12F8GsXqcJw@mail.gmail.com>
 <875z6umll9.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <451311723fed30be498059700fbac80e@stellarbound.space>

On 2020-10-28 18:11, Nicol? Balzarotti wrote:
> Jeffrey Horn <jrhorn424 at gmail.com> writes:
> Hi, I don't think netcat does tls.

It does: https://man.openbsd.org/nc#c

From bjorn.warmedal at gmail.com  Fri Oct 30 11:50:24 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Fri, 30 Oct 2020 12:50:24 +0100
Subject: Content length, EOF -- ways to resolve whether we received everything
Message-ID: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>

There's been a lot of discussions about the lack of an end-of-message
indicator in the protocol. Clearly it's something that a lot of client and
server implementers are missing.

A proposal that arose (I think acdw may have been the first to suggest it;
correct me if I'm wrong) was to include a "content-length: <nr of bytes>"
in the <META> of a status 20 response. It's a simple thing to add, that
doesn't extend the protocol into bloat.

"But, ew0k! The <META> is for MIME types! That's not a MIME type!"

Yes, this is true. Would that cause an issue? In that case calling it
"x-gemi-content-length" should resolve it, as the "x-" prefix is for
experimental types and any receiver that doesn't recognize it will ignore
it. I'm aware that it still doesn't convey info on the *type* of content,
and thereby doesn't belong among MIME type info, but it's a compromise I'm
willing to make.

Are you?

Cheers,
BW/ew0k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201030/a9a59223/attachment.htm>

From martin at no.ucant.org  Fri Oct 30 12:02:27 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Fri, 30 Oct 2020 12:02:27 +0000 (GMT)
Subject: Content length, EOF -- ways to resolve whether we received
 everything
In-Reply-To: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
References: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2010301202170.31140@pling.qwghlm.org>

On Fri, 30 Oct 2020, Bj?rn W?rmedal wrote:

> it. I'm aware that it still doesn't convey info on the *type* of content,
> and thereby doesn't belong among MIME type info, but it's a compromise I'm
> willing to make.
>
> Are you?

No.

Mk

-- 
Martin Keegan, @mk270, https://mk.ucant.org/

From nothien at uber.space  Thu Oct 29 11:11:28 2020
From: nothien at uber.space (Arav K.)
Date: Thu, 29 Oct 2020 12:11:28 +0100
Subject: Proposal about content-size and hash
Message-ID: <C6PBVE9Q0280.2IIFY1GUSJY2S@gux>

Hi, Gemini peoples!

I have two main proposals for getting information like content-size
(which, as has been discussed previously, would be very useful for even
slightly big responses).

1. Define specific additional MIME type parameters.  For example, one
   could return '20 application/gzip; content-size=42069420' as the
   response line.  This could also be used for giving the client a hash
   of the data (parameter name e.g. 'content-hash-sha256'), useful for
   verification and for checking against local caches of the same page.

   To just check the MIME type (now possibly with size and hash), as
   jmcbray had mentioned on a previous thread on the topic, the best
   solution is to just request the page and terminate the connection
   after the request line.  Perhaps it should be specified in the spec
   that clients may do this, and servers may want to be prepared for
   this outcome.

   A possible issue is that the hash will not fit within the META line,
   given the 1024 byte limitation (this is especially problematic for
   things like SHA 512 hashes).  We could work around this either by
   increasing the mandated maximum META line size (probably not
   possible), or by providing this information using the second proposal
   but still using this proposal (or both) for content-size.

   A potential drawback is that we open ourselves up to further
   extension this way, but I would argue that this avenue has always
   been around.  If the spec defined only these two fields, and mandated
   that aside from them only parameters defined by the MIME spec may be
   included, then it _should_ be fine.

2. Define an additional endpoint for retrieving meta info.

   On ~chat, bjorn.warmedal layed out the possibility of using the
   '/.content' URL to return a content hash.  This would function like a
   normal URL, one which accepts as input the URL of the page to
   retrieve content information about.

   I propose that the response from a '/.content?/<path>' request
   returns the MIME type of the URL '/<path>', optionally including
   content-size and content-hash-* parameters (this works because there
   are no size restrictions for the content, unlike the META line).  Its
   MIME type can be bikeshed if this proposal is agreed upon.  The
   response format may be exactly an MIME type (i.e. no CR LF or
   anything).

   Unfortunately, extension becomes possible simply by using a different
   MIME type.  I don't know how to prevent this.

I think that proposal #1 is definitely doable, but I understand that #2
can be more problematic for some.  I suppose #2 would be beneficial if
we determine that content-hash is really necessary, but further
extensibility is unwanted and should be prevented somehow.

~aravk | ~nothien

From gemini at ur.gs  Fri Oct 30 13:00:25 2020
From: gemini at ur.gs (Nick Thomas)
Date: Fri, 30 Oct 2020 13:00:25 +0000
Subject: Content length, EOF -- ways to resolve whether we received
 everything
In-Reply-To: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
References: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
Message-ID: <21c29bc6d6749bde866ab44cee9fdc135765b771.camel@ur.gs>

On Fri, 2020-10-30 at 12:50 +0100, Bj?rn W?rmedal wrote:
> 
> "But, ew0k! The <META> is for MIME types! That's not a MIME type!"

I predict this is not going to be popular ^^.

The HTTP approach to the specific problem of no content-length header
is (was) chunked transfer-encoding: 
https://en.wikipedia.org/wiki/Chunked_transfer_encoding

Perhaps signalling this is more acceptable in the <META> area?
Transfer-encoding is at least directly about the format of the returned
bytes.

Signalling support from the client side is more difficult, though. It
could be an opt-in thing with server-side state when authenticated, but
that's a bit niche.

I predict adding it as a requirement to the spec will not be popular
either ;).

/Nick



From cowan at ccil.org  Fri Oct 30 13:38:29 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 30 Oct 2020 09:38:29 -0400
Subject: Content length,
 EOF -- ways to resolve whether we received everything
In-Reply-To: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
References: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
Message-ID: <CAD2gp_R9v2tPJhi8MXYzaFW5CeZYDcXjTNJ_jy7K33nkXK-HWg@mail.gmail.com>

On Fri, Oct 30, 2020 at 7:50 AM Bj?rn W?rmedal <bjorn.warmedal at gmail.com>
wrote:


> There's been a lot of discussions about the lack of an end-of-message
> indicator in the protocol. Clearly it's something that a lot of client and
> server implementers are missing.
>

I confess to not having read these discussions.  But what's the problem?
The server writes an entity-body to the socket and closes it.  The client
reads from the socket until it gets EOF (a zero-length return from read or
recv).  Done.  Gopher has been transmitting binary files like this forever,
and the cognate protocols finger and whois also do it this way: no length
or in-band EOF sequence.

It is the particular mime-type that declares what parameters are meaningful
to it.  Writing "text/plain;charset=utf-8;content-length=32767" will not
mean anything to anyone outside the Gemini world and will probably confuse
them.

Let's not go there.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
One art / There is / No less / No more
To do / All things / With sparks / Galore   --Douglas Hofstadter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201030/bdb556f3/attachment.htm>

From nothien at uber.space  Fri Oct 30 16:13:05 2020
From: nothien at uber.space (Arav K.)
Date: Fri, 30 Oct 2020 17:13:05 +0100
Subject: Content length, EOF -- ways to resolve whether we received
 everything
In-Reply-To: <CAD2gp_R9v2tPJhi8MXYzaFW5CeZYDcXjTNJ_jy7K33nkXK-HWg@mail.gmail.com>
Message-ID: <C6QCWVTAHJHZ.1T0PJMBZBVRN7@gux>

On Fri Oct 30, 2020 at 2:38 PM WAT, John Cowan wrote:
> I confess to not having read these discussions. But what's the
> problem?  The server writes an entity-body to the socket and closes
> it. The client reads from the socket until it gets EOF (a zero-length
> return from read or recv). Done. Gopher has been transmitting binary
> files like this forever, and the cognate protocols finger and whois
> also do it this way: no length or in-band EOF sequence.

The problem is that clients have no way to know how much stuff they're
receiving.  This would be helpful for interactive clients, so that they
can tell the user some indication of progress, and it would be helpful
for more constrained programs to know whether or not they can store all
their input.  Both of these points were raised in previous discussions.

> It is the particular mime-type that declares what parameters are
> meaningful to it. Writing
> "text/plain;charset=utf-8;content-length=32767" will not mean anything
> to anyone outside the Gemini world and will probably confuse them.

AFAIK, all MIME parsers know to ignore additional MIME parameters.  Even
if someone who did not know about this concept were to see such an MIME
type, the idea is clear.  I don't see how including this is a problem.

~aravk | ~nothien

From ehmry at posteo.net  Fri Oct 30 16:28:40 2020
From: ehmry at posteo.net (Emery Hemingway)
Date: Fri, 30 Oct 2020 17:28:40 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <C6PBVE9Q0280.2IIFY1GUSJY2S@gux>
References: <C6PBVE9Q0280.2IIFY1GUSJY2S@gux>
Message-ID: <82614ffd-87c1-49a9-8297-9b609d309856@posteo.net>

I'd also like to see optional content hashes to aid caching and archiving.

What I miss about the pre-HTTPs days was that personalizing the web
experience was something that could be done independently of the browser
via proxies, be it caching, ad-blocking, or text manipulation.

I'd like to see proxies make a comeback, and local caching proxies seem
like good place a good start.

E.

From anothersms at gmail.com  Fri Oct 30 21:43:16 2020
From: anothersms at gmail.com (=?utf-8?Q?Nicol=C3=B2_Balzarotti?=)
Date: Fri, 30 Oct 2020 22:43:16 +0100
Subject: [ANN] Gemini Anonymous Board (and julia server)
Message-ID: <87tuubl79n.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>

Hi!

I discovered Gemini quite recently, and I decided to explore the
protocol a bit, writing my own server.  I wrote it in Julia, it's called
Gemenon.jl and it's available here [1]. (I must warn you it's still
alpha quality).

I implemented a simple anonymous board running on it.  It's hosted on a
home-server, I hope to keep uptime as high as possible.
It's called DNA and it's available here: gemini://nixo.xyz/

When posting, first line is the title, following lines are the message
content.  To save and post the message you can insert "!save"
(unquoted), or "!discard" (unquoted) to delete the draft.

In order to post, clients need to have a certificate (any certificate
will work right now).
(User names are generated by using the client certificate)

That's it!

Nicol?

[1] https://git.nixo.xyz/nixo/Gemenon.jl

From sean at conman.org  Fri Oct 30 22:06:42 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 30 Oct 2020 18:06:42 -0400
Subject: Proposal about content-size and hash
In-Reply-To: <C6PBVE9Q0280.2IIFY1GUSJY2S@gux>
References: <C6PBVE9Q0280.2IIFY1GUSJY2S@gux>
Message-ID: <20201030220642.GP30302@brevard.conman.org>

It was thus said that the Great Arav K. once stated:
> Hi, Gemini peoples!
> 
> I have two main proposals for getting information like content-size
> (which, as has been discussed previously, would be very useful for even
> slightly big responses).
> 
> 1. Define specific additional MIME type parameters.  For example, one
>    could return '20 application/gzip; content-size=42069420' as the
>    response line.  This could also be used for giving the client a hash
>    of the data (parameter name e.g. 'content-hash-sha256'), useful for
>    verification and for checking against local caches of the same page.

  Ah yes ... this is something I proposed back in August of 2019:

	gemini://gemini.conman.org/gRFC/0003

  Solderpunk has always rejected it when it comes up, mumbling "simplicity"
and "not HTTP again" under his breath.  Another issue with this is that the
server might not know how big a given response is---think dynamic output
(via CGI/SCGI or similar).  It would have to be optional in any case.

> 2. Define an additional endpoint for retrieving meta info.

  I also proposed something along these lines in August of 2019:

	https://lists.orbitalfox.eu/archives/gemini/2019/000016.html

  Read the thread to see how that turned out.

  -spc


From sean at conman.org  Fri Oct 30 22:07:49 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 30 Oct 2020 18:07:49 -0400
Subject: Content length,
 EOF -- ways to resolve whether we received everything
In-Reply-To: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
References: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
Message-ID: <20201030220749.GQ30302@brevard.conman.org>

It was thus said that the Great Bj?rn W?rmedal once stated:
> Yes, this is true. Would that cause an issue? In that case calling it
> "x-gemi-content-length" should resolve it, as the "x-" prefix is for
> experimental types and any receiver that doesn't recognize it will ignore
> it. 

  RFC-6648 deprecates the whole "X-" thing.

  -spc




From colecmac at protonmail.com  Fri Oct 30 22:17:33 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 30 Oct 2020 22:17:33 +0000
Subject: SNI
In-Reply-To: <20201026211039.gqeuznxo7klkckt5@enzo.thebackupbox.net>
References: <20201026211039.gqeuznxo7klkckt5@enzo.thebackupbox.net>
Message-ID: <prwMDJ4T9DUqTexYmeCpLZqIm7YrO2V7-7w_QF-bgg70fvOYlm4b8bebV5c7a35r9oVAafLvNiekIwtc0m4CkewHE7t6o5YoauOLA0tRiGM=@protonmail.com>

This is a great question, hmm. I think you probably should, but I
wonder what the status of clients are, if most are doing it. My
clients (gemget, amfora) are all in Go, which doesn't seem to have
an option to set SNI myself? I think it does it automatically.

I would love to have Solderpunk's input on this, but I would wait
until many clients are tested before you start refusing requests.
Definitely this should be added to the existing client torture tests.

Cheers,
makeworld

From sean at conman.org  Fri Oct 30 22:25:46 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 30 Oct 2020 18:25:46 -0400
Subject: SNI
In-Reply-To: <prwMDJ4T9DUqTexYmeCpLZqIm7YrO2V7-7w_QF-bgg70fvOYlm4b8bebV5c7a35r9oVAafLvNiekIwtc0m4CkewHE7t6o5YoauOLA0tRiGM=@protonmail.com>
References: <20201026211039.gqeuznxo7klkckt5@enzo.thebackupbox.net>
 <prwMDJ4T9DUqTexYmeCpLZqIm7YrO2V7-7w_QF-bgg70fvOYlm4b8bebV5c7a35r9oVAafLvNiekIwtc0m4CkewHE7t6o5YoauOLA0tRiGM=@protonmail.com>
Message-ID: <20201030222546.GR30302@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> 
> I would love to have Solderpunk's input on this, but I would wait
> until many clients are tested before you start refusing requests.
> Definitely this should be added to the existing client torture tests.

  I'll have to see if the TLS library I use has a way to check SNI---it's
not something I've had to deal with explicitly.

  -spc


From sir at cmpwn.com  Fri Oct 30 22:26:17 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Fri, 30 Oct 2020 18:26:17 -0400
Subject: SNI
In-Reply-To: <20201030222546.GR30302@brevard.conman.org>
Message-ID: <C6QKUMDVQV0L.YWDHPJFOYUDF@taiga>

My Gemini server requires SNI.

From mailinglists at ngalt.com  Fri Oct 30 22:34:00 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Fri, 30 Oct 2020 15:34:00 -0700
Subject: External SHA hashes instead? (was: Re: Content length, EOF -- ways to
 resolve whether we received everything)
In-Reply-To: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
References: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
Message-ID: <15D03E04-3F5E-496D-9924-C8C1B9772AC8@ngalt.com>



> On Oct 30, 2020, at 4:50 AM, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
> There's been a lot of discussions about the lack of an end-of-message indicator in the protocol. Clearly it's something that a lot of client and server implementers are missing.
> 
> A proposal that arose (I think acdw may have been the first to suggest it; correct me if I'm wrong) was to include a "content-length: <nr of bytes>" in the <META> of a status 20 response. It's a simple thing to add, that doesn't extend the protocol into bloat.
> 
> "But, ew0k! The <META> is for MIME types! That's not a MIME type!"
> 
> Yes, this is true. Would that cause an issue? In that case calling it "x-gemi-content-length" should resolve it, as the "x-" prefix is for experimental types and any receiver that doesn't recognize it will ignore it. I'm aware that it still doesn't convey info on the *type* of content, and thereby doesn't belong among MIME type info, but it's a compromise I'm willing to make.
> 
> Are you?
> 
> Cheers,
> BW/ew0k


If you?re worried whether the occasional big(gish) file transferred correctly and don?t want to stand up an HTTP server, have you considered publishing SHA-256 or -512 hashes, like one does for Linux-distribution .iso files?

From nothien at uber.space  Fri Oct 30 22:27:10 2020
From: nothien at uber.space (Arav K.)
Date: Fri, 30 Oct 2020 23:27:10 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <20201030220642.GP30302@brevard.conman.org>
Message-ID: <C6QKVASKBZ2U.3IFUDQN2O0ZS8@gux>

On Fri Oct 30, 2020 at 12:06 PM UTC, Sean Conner wrote:
> Ah yes ... this is something I proposed back in August of 2019:
>
> gemini://gemini.conman.org/gRFC/0003
>
> Solderpunk has always rejected it when it comes up, mumbling
> "simplicity" and "not HTTP again" under his breath.

It would be a useful optional header that simply requires a few lines of
info in the spec - I don't know what solderpunk is going on about.
Clients (that conform to the MIME parsing guidelines) will ignore it if
they don't recognize it.  It's not affecting anything else in the spec.

I understand to some extent solderpunk's fear of MIME type parameters
becoming the new HTTP header fields (or whatever they're called), but
this has always been around as an avenue of extension.  We can't even
specify that unrecognized MIME type parameters be considered errors,
because the MIME spec itself leaves open the possibility of adding more
parameters later.  I argue that if this avenue of extension is open, and
it cannot be closed, then may as well make (optional) use of it.

> Another issue with this is that the server might not know how big a
> given response is---think dynamic output (via CGI/SCGI or similar). It
> would have to be optional in any case.

For things like CGI, the server is expected to execute the CGI stuff
before sending a success response (in case the CGI fails; see the
CGI-specific error code in the spec).  Immediately after execution, it
would have the full response to send, so it can still provide the
content size.  Even then, it would still be optional to provide, as no
servers currently provide it.

> I also proposed something along these lines in August of 2019:
>
> https://lists.orbitalfox.eu/archives/gemini/2019/000016.html
>
> Read the thread to see how that turned out.

>From what it seems, you suggested the same thing I have a year back, and
solderpunk said 'ah' and then it was forgotten.

Here's what solderpunk's last response to the idea from that thread had
been:

> Yeah, I think we can leave this for now.  It was a hypothetical
> concern that somebody had.  Not necessarily a bad one, but until it's
> observed actually creating significant trouble for actual users on
> actual clients I think we can just table this issue.  If it does come
> up as a practical concern, we can resume discussion of some of the
> ideas here.

The problem has come up again, and more clients are looking for ways to
report this information.  I think we should 'officially' resume
discussion of this, and we can start by figuring out issues with this
MIME type parameter proposal.

In addition, someone reminded me how short content hashes are in
comparison to the available space in the META line.  Even SHA-512 takes
up only 140 characters out of the 1024 available on META, so we can
actually encode content-hash as well in the MIME type.  I understand
this is even more controversional than content-length, but I'm leaving
it out there for discussion.

~aravk | ~nothien

From escondida at iff.ink  Fri Oct 30 23:12:10 2020
From: escondida at iff.ink (Ivy Foster)
Date: Fri, 30 Oct 2020 18:12:10 -0500
Subject: Content length, EOF -- ways to resolve whether we received
 everything
In-Reply-To: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
References: <C6PBVE9Q0280.2IIFY1GUSJY2S@gux>
 <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
Message-ID: <20201030231210.GA31935@thrax.localdomain>

On 30 Oct 2020, at 12:50 pm +0100, Bj?rn W?rmedal wrote:
> A proposal that arose (I think acdw may have been the first to suggest it;
> correct me if I'm wrong) was to include a "content-length: <nr of bytes>"
> in the <META> of a status 20 response. It's a simple thing to add, that
> doesn't extend the protocol into bloat.

> "But, ew0k! The <META> is for MIME types! That's not a MIME type!"

> Yes, this is true. Would that cause an issue? In that case calling it
> "x-gemi-content-length" should resolve it, as the "x-" prefix is for
> experimental types and any receiver that doesn't recognize it will ignore
> it. I'm aware that it still doesn't convey info on the *type* of content,
> and thereby doesn't belong among MIME type info, but it's a compromise I'm
> willing to make.

Alternately, as I [previously pointed out][1], there is [an
established RFC][2] for including size as a parameter to a MIME type.
Specifically, it's part of the specification for email: if any
"attachment" is actually an external part to be fetched rather than an
actual attachment, you specify
"content-type:foo/bar;access-type:how-you-get-it;(optionally)size:octets".
Solderpunk did shoot it down, granted, but since the conversation's
come up again I figure I should point this out instead of having us
come up with new MIME extensions.

[1]: https://lists.orbitalfox.eu/archives/gemini/2020/001534.html
[2]: https://tools.ietf.org/html/rfc1341

From colecmac at protonmail.com  Fri Oct 30 23:26:00 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 30 Oct 2020 23:26:00 +0000
Subject: Announcing go-gemini,
 a Go library implementing the Gemini protocol
In-Reply-To: <C6LMCJV4AEG7.P1TD8IEQP1U3@nitro>
References: <C6LMCJV4AEG7.P1TD8IEQP1U3@nitro>
Message-ID: <KkVXWUs-4QoUvgI0Q88XHEmSAbwrcxE7GEClRE0mxwEoAiKFmfBrr5gnAJjC3cEB1_31yyuAFlScDyfg4iYcltxouwlgohEN6HzhgqGkTmk=@protonmail.com>

https://github.com/makeworld-the-better-one/go-gemini


You're infringing on my namespace there pal ;)

No real worries of course, it's just too bad to have the same name
like that. Your library definitely looks a lot more featureful though.
I might think about switching to using it, but I'm pretty comfortable
with mine right now. It's mostly a personal library.

Nice work! I will add a link to yours on my README.


Cheers,
makeworld

From sir at cmpwn.com  Fri Oct 30 23:26:45 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Fri, 30 Oct 2020 19:26:45 -0400
Subject: Announcing go-gemini, a Go library implementing the Gemini
 protocol
In-Reply-To: <KkVXWUs-4QoUvgI0Q88XHEmSAbwrcxE7GEClRE0mxwEoAiKFmfBrr5gnAJjC3cEB1_31yyuAFlScDyfg4iYcltxouwlgohEN6HzhgqGkTmk=@protonmail.com>
Message-ID: <C6QM4X0E373F.1GDZJGHCF9VL5@taiga>

Should have put it on sourcehut for better discoverability :)

From colecmac at protonmail.com  Fri Oct 30 23:53:13 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 30 Oct 2020 23:53:13 +0000
Subject: SNI
In-Reply-To: <C6QKUMDVQV0L.YWDHPJFOYUDF@taiga>
References: <C6QKUMDVQV0L.YWDHPJFOYUDF@taiga>
Message-ID: <_ojExq8LwldsLWxnmbY03whKvQB0W6k4thqtv_FyvjekRxkOmPpupU6hoxJ8disMdiFLvlY9xaZgtO3V6RRlnyS0gccn1FK1r9MxXuAaxQg=@protonmail.com>

??????? Original Message ???????
On Friday, October 30, 2020 6:26 PM, Drew DeVault <sir at cmpwn.com> wrote:

> My Gemini server requires SNI.


Well, there's the test! My client connected with gemini://drewdevault.com
sucessfully, so looks SNI works. :)


makeworld



From jordan at crowesnest.io  Sat Oct 31 01:07:51 2020
From: jordan at crowesnest.io (Jordan)
Date: Sat, 31 Oct 2020 01:07:51 +0000
Subject: [ANN] Gemini Anonymous Board (and julia server)
In-Reply-To: <87tuubl79n.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
References: <87tuubl79n.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <3P1ELd0wkobsPxy6nOofQQr4oaIi6PTqPxjsPyoU@cp4-web-037.plabs.ch>

Hey,

I'm liking the site you are hosting, and am interested in see more posts
one day. However, to post to the server you talk about needing a client
certificate. Myself being a newb to all this, I was wondering if you
could add a little more detail to the info section of your site for
future people like me.

Goodluck with DNA (awesome name btw) and your server software!

Thanks,

Jordan


From jordan at crowesnest.io  Sat Oct 31 01:11:11 2020
From: jordan at crowesnest.io (Jordan)
Date: Sat, 31 Oct 2020 01:11:11 +0000
Subject: Announcing go-gemini,
 a Go library implementing the Gemini protocol
In-Reply-To: <C6QM4X0E373F.1GDZJGHCF9VL5@taiga>
References: <C6QM4X0E373F.1GDZJGHCF9VL5@taiga>
Message-ID: <y4MLnRqQ9Bv2vbnhTCrwBv2Qyk8ObS9Ba5VIPNwIEM@cp4-web-027.plabs.ch>

Awesome and congrats! I'm interested in checking this out soon. Also, I
totally agree, it needs to be on sr.ht.

Thanks,

Jordan


From marcx2 at welz.org.za  Sat Oct 31 08:42:53 2020
From: marcx2 at welz.org.za (marc)
Date: Sat, 31 Oct 2020 09:42:53 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <20201030220642.GP30302@brevard.conman.org>
References: <C6PBVE9Q0280.2IIFY1GUSJY2S@gux>
 <20201030220642.GP30302@brevard.conman.org>
Message-ID: <20201031084253.GA10873@localhost.localdomain>


Hi

>   Ah yes ... this is something I proposed back in August of 2019:
> 
> 	gemini://gemini.conman.org/gRFC/0003
> 
>   Solderpunk has always rejected it when it comes up, mumbling "simplicity"
> and "not HTTP again" under his breath.  Another issue with this is that the
> server might not know how big a given response is---think dynamic output
> (via CGI/SCGI or similar).  It would have to be optional in any case.
> 
> > 2. Define an additional endpoint for retrieving meta info.
> 
>   I also proposed something along these lines in August of 2019:
> 
> 	https://lists.orbitalfox.eu/archives/gemini/2019/000016.html
> 
>   Read the thread to see how that turned out.


The list has been full of little proposals to add just one
more protocol element to make things look a bit more like http
or one more tag to make things look a bit more like html.

In a way this is understandable - the features of http+html
are well known, and part of ones mental problem solving kit, and
everybody uses gemini a bit differently, so when encountering
a limitation, suggesting bits of http+html is easy...

But (and I don't speak for solderpunk) I view gemini as a
reaction against http/html - the thesis is that there might
have technical aspects of that stack which has made surveillance
capitalism easier. So I don't see gemini as http+html lite - I
see it as its antithesis.

If people want to see gemini evolve, don't have it converge
on http+html, have it work towards a better world.

For instance: In this thread people worry about partially
downloaded data - we don't know if a gemini document has
been transferred completely. We also have the problem that
people are writing gemini to web gateways but other people
would like to keep their content in gemini-space only.
And then Emery Hemingway astutely points out that the modern
web has forgotten about caching and replication.

So: If (and it is a big if) there extension proposals to be
made, how about an (optional) footer in the document markup
(not the transfer protocol) which improves on the mean:

  "(c) Joe Soap, all rights reserved"

to something which states under what conditions that document
might be distributed, if it is a cachable static page or one which
updates and who should be credited as author. There are many
parts of the small web which contain a snippet of valuable
information, and often it is unclear how to rescue those
if the original site disappears. A line like

  -- CC-SA: Joe Soap

for creative commons, share alike or

  -- GMI,DYN,NOC: Joe Soap

for gemini space only, dynamic content not to be cached, or just

  --

for end of document. So this mechanism then solves multiple
problems (I think /robots.txt is an ugly afterthought) and
opens the way for people to cache/curate/remix/reuse each others
ideas. The -- could be a different tag, but -- is in common
use to denote a signature, so a footer, already.

However, having just written all that, it is still good to
consider the following:

  "Perfection isn't achieved when nothing more can be added, it
   is achieved when nothing more can be taken away"

                                - An impressive author and aviator

regards

marc

From nothien at uber.space  Sat Oct 31 09:13:21 2020
From: nothien at uber.space (Arav K.)
Date: Sat, 31 Oct 2020 10:13:21 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <20201031084253.GA10873@localhost.localdomain>
Message-ID: <C6QYM1SHRUC3.28TGLQR6GIJE@gux>

> The list has been full of little proposals to add just one
> more protocol element to make things look a bit more like http
> or one more tag to make things look a bit more like html.
>
> In a way this is understandable - the features of http+html
> are well known, and part of ones mental problem solving kit, and
> everybody uses gemini a bit differently, so when encountering
> a limitation, suggesting bits of http+html is easy...
>
> But (and I don't speak for solderpunk) I view gemini as a
> reaction against http/html - the thesis is that there might
> have technical aspects of that stack which has made surveillance
> capitalism easier. So I don't see gemini as http+html lite - I
> see it as its antithesis.
> 
> If people want to see gemini evolve, don't have it converge
> on http+html, have it work towards a better world.

This is an orthogonal point.  Yes, I agree that there are elements of
HTTP+HTML that allow for surveillance, and yes, we don't want them, but
a content-size header is not wandering in that direction at all.  It is
an optional extension that allows clients to show progress bars and
potentially give ETAs for downloads.  Period.  Please tell me about what
aspects of surveillance capitalism content-size allows for.

> For instance: In this thread people worry about partially
> downloaded data - we don't know if a gemini document has
> been transferred completely. We also have the problem that
> people are writing gemini to web gateways but other people
> would like to keep their content in gemini-space only.
> And then Emery Hemingway astutely points out that the modern
> web has forgotten about caching and replication.
>
> So: If (and it is a big if) there extension proposals to be
> made, how about an (optional) footer in the document markup
> (not the transfer protocol) which improves on the mean:
>
> "(c) Joe Soap, all rights reserved"
>
> to something which states under what conditions that document
> might be distributed, if it is a cachable static page or one which
> updates and who should be credited as author. There are many
> parts of the small web which contain a snippet of valuable
> information, and often it is unclear how to rescue those
> if the original site disappears. A line like
>
> -- CC-SA: Joe Soap
>
> for creative commons, share alike or
>
> -- GMI,DYN,NOC: Joe Soap
>
> for gemini space only, dynamic content not to be cached, or just
>
> --
>
> for end of document. So this mechanism then solves multiple
> problems (I think /robots.txt is an ugly afterthought) and
> opens the way for people to cache/curate/remix/reuse each others
> ideas. The -- could be a different tag, but -- is in common
> use to denote a signature, so a footer, already.

It doesn't solve the original problem I was trying to address, as I've
pointed out above (i.e. it doesn't allow for progress bars or ETAs).
What you're suggesting is an orthogonal idea that can be implemented in
conjunction with my proposal.  And it's not a bad idea you've got here!
But it is in no way an argument against my proposal.  Even if you didn't
mean it in that way, I want to make this clear.

~aravk | ~nothien

From bjorn.warmedal at gmail.com  Sat Oct 31 09:21:33 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Sat, 31 Oct 2020 10:21:33 +0100
Subject: External SHA hashes instead? (was: Re: Content length, EOF --
 ways to resolve whether we received everything)
In-Reply-To: <15D03E04-3F5E-496D-9924-C8C1B9772AC8@ngalt.com>
References: <CAJScK0LkrDMreoUZ9tt4wjMyuD1cirmRTidt0jUA6SgRxNr39g@mail.gmail.com>
 <15D03E04-3F5E-496D-9924-C8C1B9772AC8@ngalt.com>
Message-ID: <CAJScK0LHo5KYd2tpQFJa3zvw67Gvx3SCZFTYyH4R4ua2bv1EjA@mail.gmail.com>

It wouldn't just be about content integrity; it's also about caching. If
the client has fetched a file before, and it hasn't changed since, there's
no need to waste time and bandwidth fetching it again.

On Fri, 30 Oct 2020 at 23:34, Nathan Galt <mailinglists at ngalt.com> wrote:

>
>
> > On Oct 30, 2020, at 4:50 AM, Bj?rn W?rmedal <bjorn.warmedal at gmail.com>
> wrote:
> >
> > There's been a lot of discussions about the lack of an end-of-message
> indicator in the protocol. Clearly it's something that a lot of client and
> server implementers are missing.
> >
> > A proposal that arose (I think acdw may have been the first to suggest
> it; correct me if I'm wrong) was to include a "content-length: <nr of
> bytes>" in the <META> of a status 20 response. It's a simple thing to add,
> that doesn't extend the protocol into bloat.
> >
> > "But, ew0k! The <META> is for MIME types! That's not a MIME type!"
> >
> > Yes, this is true. Would that cause an issue? In that case calling it
> "x-gemi-content-length" should resolve it, as the "x-" prefix is for
> experimental types and any receiver that doesn't recognize it will ignore
> it. I'm aware that it still doesn't convey info on the *type* of content,
> and thereby doesn't belong among MIME type info, but it's a compromise I'm
> willing to make.
> >
> > Are you?
> >
> > Cheers,
> > BW/ew0k
>
>
> If you?re worried whether the occasional big(gish) file transferred
> correctly and don?t want to stand up an HTTP server, have you considered
> publishing SHA-256 or -512 hashes, like one does for Linux-distribution
> .iso files?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201031/7c8cfad0/attachment.htm>

From nothien at uber.space  Sat Oct 31 09:25:09 2020
From: nothien at uber.space (Arav K.)
Date: Sat, 31 Oct 2020 10:25:09 +0100
Subject: External SHA hashes instead? (was: Re: Content length, EOF --
 ways to resolve whether we received everything)
In-Reply-To: <15D03E04-3F5E-496D-9924-C8C1B9772AC8@ngalt.com>
Message-ID: <C6QYV30BCUG5.2OT6QRUIAFWOB@gux>

On Fri Oct 30, 2020 at 12:34 PM UTC, Nathan Galt wrote:
> If you?re worried whether the occasional big(gish) file transferred
> correctly and don?t want to stand up an HTTP server, have you
> considered publishing SHA-256 or -512 hashes, like one does for
> Linux-distribution .iso files?

The issue with this is twofold:
 * Clients generally don't want the hashes of all files, only of the
   they are trying to download.  It is better to only provide this hash,
   which can be done for individual files (either as a MIME type param
   or from a special access point which takes the file name as input).
 * The server would have to constantly update the hash list (or keep it
   in memory and still keep updating it).  This is all the more
   difficult for servers running CGI scripts, as their output can vary.
   Further complications arise if servers change their output based on
   client certs.  Better to serve the hash along with the content
   itself, as then all the details about the content are known (e.g. the
   client cert used to request the content, and the state of databases
   and CGI output which affect the response).

~aravk | ~nothien

From solderpunk at posteo.net  Sun Nov  1 13:39:16 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 01 Nov 2020 14:39:16 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <20201030220642.GP30302@brevard.conman.org>
Message-ID: <C6RYW789F726.ZSL119S0I898@stilgar>

On Fri Oct 30, 2020 at 11:06 PM CET, Sean Conner wrote:

> Ah yes ... this is something I proposed back in August of 2019:
>
> gemini://gemini.conman.org/gRFC/0003
>
> Solderpunk has always rejected it when it comes up, mumbling
> "simplicity"
> and "not HTTP again" under his breath.

Well, that's not quite fair.  What I usually mumble, in the context of
people wanting to add this stuff as part of the MIME type in a status 20
response, is something like this:

1) The parameters which may be legitimately appended to a MIME media
type are those registered in that media type's formal definition.
You can't just stick whatever you want on there.  We can define
parameters for text/gemini, but we can't do anything about other media
types whose definitions are beyond our control.

2) A media type is supposed to specify, well, what *type* of thing a
file is.  They are *categories*, which a client can use to decide how to
handle a given file.  From RFC 2045, section 5:

> The purpose of the Content-Type field is to describe the data
> contained in the body fully enough that the receiving user agent can
> pick an appropriate agent or mechanism to present the data to the
> user, or otherwise deal with the data in an appropriate manner.

It seems very clear to me that information which is unique to a specific
individual file - like its size, hash, last update time, etc. - is just
not semantically appropriate here.

TLDR; MIME types aren't big trucks that you just dump something on.
They have a clearly limited semantic scope, and each media type and
subtype is constrained by a formal definition.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Nov  1 14:14:50 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 01 Nov 2020 15:14:50 +0100
Subject: Redirection limits
In-Reply-To: <20201027021630.GI30302@brevard.conman.org>
Message-ID: <C6RZNFC3PYX4.2NVJ9LWU78Q76@stilgar>

On Tue Oct 27, 2020 at 3:16 AM CET, Sean Conner wrote:

> Ah, I see that the limit is now mentioned in the Best Practices
> document,
> not the specification.

I could certainly be wrong, but my recollection is that this limit was
*always* in the Best Practices document, never in the spec itself.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Nov  1 14:01:50 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 01 Nov 2020 15:01:50 +0100
Subject: FAQ updates
Message-ID: <C6RZDHBGABS0.2U4ZBVJ68YSSM@stilgar>

Hi folks,

I've pushed a few updates to the FAQ today for the first time in quite a
while.  Nothing which long time list members, or careful archive
readers, won't have heard before, but it is stuff that I am frequently
asked via direct emails so figured I should finally get around to
writing up.  The new questions are 2.8, 2.9, 2.10, 2.11 and 2.12.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Nov  1 14:26:32 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 01 Nov 2020 15:26:32 +0100
Subject: External SHA hashes instead? (was: Re: Content length, EOF --
 ways to resolve whether we received everything)
In-Reply-To: <CAJScK0LHo5KYd2tpQFJa3zvw67Gvx3SCZFTYyH4R4ua2bv1EjA@mail.gmail.com>
Message-ID: <C6RZWDUBY17L.2U983D38AEJ2S@stilgar>

On Sat Oct 31, 2020 at 10:21 AM CET, Bj?rn W?rmedal wrote:
> It wouldn't just be about content integrity; it's also about caching. If
> the client has fetched a file before, and it hasn't changed since,
> there's
> no need to waste time and bandwidth fetching it again.

I'm not philosophically opposed to caching or anything - far from it -
but it comes with a complexity cost and whether or not that cost is
worth paying depends upon the benefits it brings.

On the web, caching is a win, because webpages are composed of many
different parts (style sheets, background images, tracking scripts,
sometimes even content!), some of those parts are re-used across
multiple pages, and some of those parts can be fairly large.

In Geminispace, the majority of content is small (a kilobyte or so),
and visiting a single URL only means downloading an individual resource,
so there's no way for a resource to be frequently re-used like a large
background image might be on a website.  I'm not sure the cost to
benefit ratio is quite so clearly favourable.

It's true that frequent use of "the back button" or similar
navigational strategies to get around Geminispace means that certain
individual pages may be loaded several times within a browsing session
(one might go back and forth between a page listing entries in a gemlog
and those individual entries), and that can be a little wasteful.
Smarter navigation tools (like AV-98's "tours") can reduce this waste,
but it's also easily fixed by clients doing something simple like
keeping the 5 or 10 most recently visited pages cached in memory, with
cached pages expiring after 10 minutes or so (AV-98 does this, although
I don't think I've done a release since adding it).  Clients doing this
would obviously have problems with content which updated more frequently
than every 10 minutes, but that kind of content is - and I would argue
*should* be - very rare in Geminispace.  Apps are the one obvious place
where this strategy might fail, which is perhaps yet another argument in
favour of having different clients optimised for reading and for apps.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Nov  1 14:47:12 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 01 Nov 2020 15:47:12 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <C6QKVASKBZ2U.3IFUDQN2O0ZS8@gux>
Message-ID: <C6S0C7E84B8A.39JZJX7717IRV@stilgar>

On Fri Oct 30, 2020 at 11:27 PM CET, Arav K. wrote:
> On Fri Oct 30, 2020 at 12:06 PM UTC, Sean Conner wrote:
> > Ah yes ... this is something I proposed back in August of 2019:
> >
> > gemini://gemini.conman.org/gRFC/0003
> >
> > Solderpunk has always rejected it when it comes up, mumbling
> > "simplicity" and "not HTTP again" under his breath.
>
> It would be a useful optional header that simply requires a few lines of
> info in the spec - I don't know what solderpunk is going on about.
> Clients (that conform to the MIME parsing guidelines) will ignore it if
> they don't recognize it. It's not affecting anything else in the spec.

I've explained in another email why I don't think it's okay to put this
information into the MIME type.

The other option is to stick it *after* the MIME type, separated by a
tab or some other delimiter, and I don't like that idea because as soon
as the precedent is set that extra bits of optional information can be
tacked on after the MIME type and simpler clients can ignore them, it
opens the gateway to endless such extensions, and the risk that some of
them will become so popular and widely implemented that clients which
don't do so are considered "outdated" or "broken", and these "optional"
extensions are now de-facto obligatory spec features.

> > Yeah, I think we can leave this for now.  It was a hypothetical
> > concern that somebody had.  Not necessarily a bad one, but until it's
> > observed actually creating significant trouble for actual users on
> > actual clients I think we can just table this issue.  If it does come
> > up as a practical concern, we can resume discussion of some of the
> > ideas here.
>
> The problem has come up again

I'm behind on my mailing list reading (to put it lightly), so forgive me
if I should know this: but has the problem *actually* come up, as in
people are actually observing real problems in the wild where Gemini
transactions are terminated early and the situation isn't immediately
very obvious to either the client or the human user?  Or has it come up
in the sense that more people have noticed it as an abstract possibility
and are just looking for a way to fix it on principle because we're all
geeks here and enjoy designing perfect things?

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Nov  1 15:22:25 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 01 Nov 2020 16:22:25 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <C6S0C7E84B8A.39JZJX7717IRV@stilgar>
Message-ID: <C6S136HG3ZPW.2X4HX0V7PRNVP@stilgar>

On Sun Nov 1, 2020 at 3:47 PM CET, Solderpunk wrote:

> The other option is to stick it *after* the MIME type, separated by a
> tab or some other delimiter, and I don't like that idea because as soon
> as the precedent is set that extra bits of optional information can be
> tacked on after the MIME type and simpler clients can ignore them, it
> opens the gateway to endless such extensions, and the risk that some of
> them will become so popular and widely implemented that clients which
> don't do so are considered "outdated" or "broken", and these "optional"
> extensions are now de-facto obligatory spec features.

...I suspect I'll regret sharing this, but intellectual honesty compels
me.  It's just occurred to me that this problem can actually be avoided by
having the <META> value for status code 20 be the content size in bytes,
followed by arbitrary whitespace, followed by the MIME type.  With this
approach, the designated separator between the size and the MIME type
is whitespace, but because MIME types may themselves contain whitespace
(to e.g. separate type/subtype from parameter values), it would be
extremely problematic to attempt to add any optional extensions on after
the MIME type using that same designated separator.  Having the
separator possibly occur inside the final element of the list makes the
list self-terminating, which completely addresses my greatest fear with
having a list at all, as opposed to just a single bit of information.

So, this is actually solvable, in principle.  It would require a
backward-compatibility breaking change to the protocol, which would
probably throw the Geminiverse into a period of chaos as clients and
servers made the change at different rates.  I haven't done anything
like this since the early days when you could count Gemini
implementations on your fingers and I had pre-existing relationships
with all the authors, so the chaotic period was measured in mere days
before we achieved perfect unity again.  I have no idea how it would go
down this time now that everybody and their dog has written some Gemini
tooling, and I'm not at all convinced that the lack of Content-Size is
such a big practical problem that it's worth this kind of upheaval.

But if content size is ever going to make it in, this seems like the
best approach to me.  It doesn't abuse MIME types at all and it doesn't
provide an obvious place for would-be extenders of the protocol to add
additional content to the response header.  No other previous proposal
has had both those properties, to the best of my knowledge.

Cheers,
Solderpunk

From nothien at uber.space  Sun Nov  1 15:56:46 2020
From: nothien at uber.space (Arav K.)
Date: Sun, 01 Nov 2020 16:56:46 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <C6S136HG3ZPW.2X4HX0V7PRNVP@stilgar>
Message-ID: <C6S1THBGH5GN.29NDCEHLD55IE@gux>

> So, this is actually solvable, in principle. It would require a
> backward-compatibility breaking change to the protocol, which would
> probably throw the Geminiverse into a period of chaos as clients and
> servers made the change at different rates. I haven't done anything
> like this since the early days when you could count Gemini
> implementations on your fingers and I had pre-existing relationships
> with all the authors, so the chaotic period was measured in mere days
> before we achieved perfect unity again. I have no idea how it would go
> down this time now that everybody and their dog has written some
> Gemini tooling, and I'm not at all convinced that the lack of
> Content-Size is such a big practical problem that it's worth this kind
> of upheaval.

This is a great idea, but Gemini seems to be beyond the point where this
is feasible.  Oh well.  I guess content-size won't be getting in after
all.

~aravk | ~nothien

From cowan at ccil.org  Sun Nov  1 16:54:16 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 1 Nov 2020 11:54:16 -0500
Subject: FAQ updates
In-Reply-To: <C6RZDHBGABS0.2U4ZBVJ68YSSM@stilgar>
References: <C6RZDHBGABS0.2U4ZBVJ68YSSM@stilgar>
Message-ID: <CAD2gp_Sza0Ow8ONw8j_WmziRxsRCBaOuYn3WR34KdVg3AW_ZSg@mail.gmail.com>

Thanks for doing this.  I think it is a particularly strong point that
unexpected EOFs are better detected by TLS than by byte-counting.

On Sun, Nov 1, 2020 at 10:05 AM Solderpunk <solderpunk at posteo.net> wrote:

> Hi folks,
>
> I've pushed a few updates to the FAQ today for the first time in quite a
> while.  Nothing which long time list members, or careful archive
> readers, won't have heard before, but it is stuff that I am frequently
> asked via direct emails so figured I should finally get around to
> writing up.  The new questions are 2.8, 2.9, 2.10, 2.11 and 2.12.
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201101/53bd001a/attachment-0001.htm>

From sean at conman.org  Mon Nov  2 02:00:39 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 1 Nov 2020 21:00:39 -0500
Subject: External SHA hashes instead? (was: Re: Content length,
 EOF -- ways to resolve whether we received everything)
In-Reply-To: <C6RZWDUBY17L.2U983D38AEJ2S@stilgar>
References: <CAJScK0LHo5KYd2tpQFJa3zvw67Gvx3SCZFTYyH4R4ua2bv1EjA@mail.gmail.com>
 <C6RZWDUBY17L.2U983D38AEJ2S@stilgar>
Message-ID: <20201102020039.GU30302@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> It's true that frequent use of "the back button" or similar
> navigational strategies to get around Geminispace means that certain
> individual pages may be loaded several times within a browsing session
> (one might go back and forth between a page listing entries in a gemlog
> and those individual entries), and that can be a little wasteful.
> Smarter navigation tools (like AV-98's "tours") can reduce this waste,
> but it's also easily fixed by clients doing something simple like
> keeping the 5 or 10 most recently visited pages cached in memory, with
> cached pages expiring after 10 minutes or so (AV-98 does this, although
> I don't think I've done a release since adding it).  Clients doing this
> would obviously have problems with content which updated more frequently
> than every 10 minutes, but that kind of content is - and I would argue
> *should* be - very rare in Geminispace.  Apps are the one obvious place
> where this strategy might fail, which is perhaps yet another argument in
> favour of having different clients optimised for reading and for apps.

  For my gopher client, I cache files that are fetched for the session. 
They're stored to disk, and when I quit out of the gopher client, the files
are deleted.  There is an option to reload an already loaded page, but I
don't think I use that all that often.

  -spc


From petite.abeille at gmail.com  Mon Nov  2 09:55:13 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 2 Nov 2020 10:55:13 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <C6RYW789F726.ZSL119S0I898@stilgar>
References: <C6RYW789F726.ZSL119S0I898@stilgar>
Message-ID: <B3E52EFF-75A1-427E-BD54-E05375F7955D@gmail.com>



> On Nov 1, 2020, at 14:39, Solderpunk <solderpunk at posteo.net> wrote:
> 
> It seems very clear to me that information which is unique to a specific
> individual file - like its size, hash, last update time, etc. - is just
> not semantically appropriate here.

This of course depend on the MIME type itself. For example, multipart's boundary is very much unique to that content type specific instance.



From petite.abeille at gmail.com  Mon Nov  2 10:03:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 2 Nov 2020 11:03:12 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <C6S136HG3ZPW.2X4HX0V7PRNVP@stilgar>
References: <C6S136HG3ZPW.2X4HX0V7PRNVP@stilgar>
Message-ID: <B2E803F2-2765-4507-A86D-E7632B6F8B45@gmail.com>



> On Nov 1, 2020, at 16:22, Solderpunk <solderpunk at posteo.net> wrote:
> 
> upheaval

On the plus side, providing some sort of content length/end-of-content indicator would open the door to persistent connections, mitigating the cost of ephemeral TLS  connections, making gemini a bit more nimble altogether.

Alternatively to a content length, perhaps gemini could consider some sort of end-of-content marker, ala chunked transfer encoding, or such.

From petite.abeille at gmail.com  Mon Nov  2 10:54:14 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 2 Nov 2020 11:54:14 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <C6S0C7E84B8A.39JZJX7717IRV@stilgar>
References: <C6S0C7E84B8A.39JZJX7717IRV@stilgar>
Message-ID: <855118C6-1631-49DC-9E44-6157119E19EA@gmail.com>



> On Nov 1, 2020, at 15:47, Solderpunk <solderpunk at posteo.net> wrote:
> 
> I've explained in another email why I don't think it's okay to put this
> information into the MIME type.

Actually, one could use a Message/External-Body content type, sporting a SIZE parameter, e.g:

message/external-body; access-type=URL; URL="gemini://example.com/foo"; SIZE=1024

could != should :D


From cowan at ccil.org  Mon Nov  2 12:52:06 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 2 Nov 2020 07:52:06 -0500
Subject: Proposal about content-size and hash
In-Reply-To: <855118C6-1631-49DC-9E44-6157119E19EA@gmail.com>
References: <C6S0C7E84B8A.39JZJX7717IRV@stilgar>
 <855118C6-1631-49DC-9E44-6157119E19EA@gmail.com>
Message-ID: <CAD2gp_Syd0RO_zTuDaVsGOQv50gco6zXgHODyWPTg_zh2crZHA@mail.gmail.com>

This is wonderful and just what I need for Dioscuri, which needs to be able
to return new content as the URL where it is now stored.  I was going to do
that with a new response code, but this is much better.

The Dioscuri spec is at <tinyurl.com/dioscuri-spec>.   Reviews are
welcome.  And it does include content-length, because TLS 1.2 is not able
to close just one side of a connection.


On Mon, Nov 2, 2020 at 5:54 AM Petite Abeille <petite.abeille at gmail.com>
wrote:

>
>
> > On Nov 1, 2020, at 15:47, Solderpunk <solderpunk at posteo.net> wrote:
> >
> > I've explained in another email why I don't think it's okay to put this
> > information into the MIME type.
>
> Actually, one could use a Message/External-Body content type, sporting a
> SIZE parameter, e.g:
>
> message/external-body; access-type=URL; URL="gemini://example.com/foo";
> SIZE=1024
>
> could != should :D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201102/6bbba2a0/attachment.htm>

From sir at cmpwn.com  Mon Nov  2 14:34:42 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 02 Nov 2020 10:34:42 -0400
Subject: Licensing content for your capsule
Message-ID: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>

Hey folks, just dropping a quick note to ask everyone who operates a
Gemini site to take a moment to choose a license for their content and
add a note to their index page to this effect.

I recommend creative commons. My capsule is CC-BY-SA, which allows my
content to be shared freely so long as it's attributed to me, and
adapted or revised so long as the new work is also shared with CC-BY-SA.

This tool can help you pick a CC license:

https://creativecommons.org/share-your-work/

Cheers!

From jmcbray at carcosa.net  Mon Nov  2 14:37:11 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 02 Nov 2020 09:37:11 -0500
Subject: External SHA hashes instead?
In-Reply-To: <C6QYV30BCUG5.2OT6QRUIAFWOB@gux> (Arav K.'s message of "Sat, 31
 Oct 2020 10:25:09 +0100")
References: <C6QYV30BCUG5.2OT6QRUIAFWOB@gux>
Message-ID: <87r1pb965k.fsf@dorothy.carcosa.net>

"Arav K." <nothien at uber.space> writes:

> On Fri Oct 30, 2020 at 12:34 PM UTC, Nathan Galt wrote:
>> If you?re worried whether the occasional big(gish) file transferred
>> correctly and don?t want to stand up an HTTP server, have you
>> considered publishing SHA-256 or -512 hashes, like one does for
>> Linux-distribution .iso files?
>
> The issue with this is twofold:
>  * Clients generally don't want the hashes of all files, only of the
>    they are trying to download.  It is better to only provide this hash,
>    which can be done for individual files (either as a MIME type param
>    or from a special access point which takes the file name as input).
>  * The server would have to constantly update the hash list (or keep it
>    in memory and still keep updating it).  This is all the more
>    difficult for servers running CGI scripts, as their output can vary.
>    Further complications arise if servers change their output based on
>    client certs.  Better to serve the hash along with the content
>    itself, as then all the details about the content are known (e.g. the
>    client cert used to request the content, and the state of databases
>    and CGI output which affect the response).

I believe the suggestion was 1) to do this only for known large files
(like the audio files on konpeito.media) and 2) Provide hashes and/or
signatures for the purpose of manual, not automatic, validation.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From steve at swinslow.net  Mon Nov  2 14:48:16 2020
From: steve at swinslow.net (Steve Winslow)
Date: Mon, 2 Nov 2020 09:48:16 -0500
Subject: Licensing content for your capsule
In-Reply-To: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
Message-ID: <20201102144816.GA1132@clariel.local>

On Mon, Nov 02, 2020 at 10:34:42AM -0400, Drew DeVault wrote:
> I recommend creative commons. My capsule is CC-BY-SA, which allows my
> content to be shared freely so long as it's attributed to me, and
> adapted or revised so long as the new work is also shared with CC-BY-SA.

Echoing everything Drew said -- and also, if you do choose a license for
your capsule's content, I'd encourage specifying the version number for
the license if it has one.

For Creative Commons licenses like CC-BY-SA (or CC-BY or the others) they
are currently at version 4.0, so that would be CC-BY-SA-4.0, or CC-BY-4.0,
etc. if you're using the most current versions.

Steve

From anothersms at gmail.com  Mon Nov  2 13:44:04 2020
From: anothersms at gmail.com (=?utf-8?Q?Nicol=C3=B2_Balzarotti?=)
Date: Mon, 02 Nov 2020 14:44:04 +0100
Subject: Specs and 0-length <META>
Message-ID: <87wnz398m3.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>

Hello!

MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed
length for the <META> field.

MasterQ32: To my understanding, <META> should be non-empty in any case,
but it may not contain useful information.

ew0k: My interpretation after re-reading the specification is that 1) A
browser should be able to handle a zero-length meta field, because the
specification does not un-ambigously state a minimum length - and 2) you
should post a request for clarification on the mailing list, so that the
specification is updated to be clear on the topic

me: In section 3.1 there's a maximum length, but not a minimum, and
under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be
an empty string.

Can the specs be changed so that it is stated exactly if/when an empty
<meta> is allowed?


Thanks!
Nicol?

From prisonpotato at tilde.team  Mon Nov  2 18:54:32 2020
From: prisonpotato at tilde.team (prisonpotato at tilde.team)
Date: Mon, 02 Nov 2020 18:54:32 +0000
Subject: Proposal about content-size and hash
In-Reply-To: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
Message-ID: <45ec4611abe3271483e3f109486256ad@tilde.team>

> ...I suspect I'll regret sharing this, but intellectual honesty compels
> me. It's just occurred to me that this problem can actually be avoided by
> having the <META> value for status code 20 be the content size in bytes,
> followed by arbitrary whitespace, followed by the MIME type. With this
> approach, the designated separator between the size and the MIME type
> is whitespace, but because MIME types may themselves contain whitespace
> (to e.g. separate type/subtype from parameter values), it would be
> extremely problematic to attempt to add any optional extensions on after
> the MIME type using that same designated separator. Having the
> separator possibly occur inside the final element of the list makes the
> list self-terminating, which completely addresses my greatest fear with
> having a list at all, as opposed to just a single bit of information.

This seems like a neat solution to this problem to me, but I'm not sure if it would work at this stage of gemini's life cycle.  There are also of course the issues with dynamically sized responses as generated by CGI scripts and stuff like that, so maybe we could introduce a new response code, like 22: Response with size.

20 text/gemini
22 100 text/gemini

This solves both problems by making content length optional again, but exposes a risk that this type of extension could be used to add more fields

From easrng at gmail.com  Mon Nov  2 19:04:57 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Mon, 2 Nov 2020 14:04:57 -0500
Subject: Proposal about content-size and hash
In-Reply-To: <45ec4611abe3271483e3f109486256ad@tilde.team>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
Message-ID: <CAEzvDCUSv2tZQix5c58n2sUhq2y4cN_CkrTd5TPmETN-r35Mcg@mail.gmail.com>

Wait, what defines whitespace? I have a terrible idea...

On Mon, Nov 2, 2020 at 1:54 PM <prisonpotato at tilde.team> wrote:
>
> > ...I suspect I'll regret sharing this, but intellectual honesty compels
> > me. It's just occurred to me that this problem can actually be avoided by
> > having the <META> value for status code 20 be the content size in bytes,
> > followed by arbitrary whitespace, followed by the MIME type. With this
> > approach, the designated separator between the size and the MIME type
> > is whitespace, but because MIME types may themselves contain whitespace
> > (to e.g. separate type/subtype from parameter values), it would be
> > extremely problematic to attempt to add any optional extensions on after
> > the MIME type using that same designated separator. Having the
> > separator possibly occur inside the final element of the list makes the
> > list self-terminating, which completely addresses my greatest fear with
> > having a list at all, as opposed to just a single bit of information.
>
> This seems like a neat solution to this problem to me, but I'm not sure if it would work at this stage of gemini's life cycle.  There are also of course the issues with dynamically sized responses as generated by CGI scripts and stuff like that, so maybe we could introduce a new response code, like 22: Response with size.
>
> 20 text/gemini
> 22 100 text/gemini
>
> This solves both problems by making content length optional again, but exposes a risk that this type of extension could be used to add more fields



-- 
?

From gmym at coopdot.com  Mon Nov  2 21:38:03 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Mon, 2 Nov 2020 22:38:03 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <45ec4611abe3271483e3f109486256ad@tilde.team>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
Message-ID: <CAObwWNiL+qQ5_hHa-9u-P4d-rqKd0mf6qymbjcga2WvVjAzBRA@mail.gmail.com>

<prisonpotato at tilde.team> wrote:

> This seems like a neat solution to this problem to me, but I'm not sure if
> it would work at this stage of gemini's life cycle.  There are also of
> course the issues with dynamically sized responses as generated by CGI
> scripts and stuff like that, so maybe we could introduce a new response
> code, like 22: Response with size.
>
> 20 text/gemini
> 22 100 text/gemini
>
> This solves both problems by making content length optional again, but
> exposes a risk that this type of extension could be used to add more fields
>

Remember, simple clients might only read the first "2" and treat it like a
"20".

If this was a year ago, maybe we could have gone with
"20<sp><size><sp><meta>" but what would be a valid size? Byte count only?
Approximate sizes like "20k" and "42M"? Ignoring trailing characters like
"5744267;<other_headers>"?

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201102/bf79534d/attachment-0001.htm>

From linde.philip at gmail.com  Mon Nov  2 22:44:32 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 2 Nov 2020 23:44:32 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <45ec4611abe3271483e3f109486256ad@tilde.team>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
Message-ID: <20201102234432.963c5bfaa6a2bdaa5317c608@gmail.com>

On Mon, 02 Nov 2020 18:54:32 +0000
prisonpotato at tilde.team wrote:

> a new response code, like 22: Response with size.
> 
> 20 text/gemini
> 22 100 text/gemini

The spec currently explicitly prohibits this kind of use of the status
codes, but it could be a new first-digit response code, e.g. 7x. This
would naturally take some time for the implementations to adopt.

I personally don't miss content-length in practice, but I think the
fact that it wasn't included in the protocol from the beginning is the
most compelling argument against it. That said, I'd happily implement,
something like a new status code to account for such a change in my
client. When would servers dare use it, though?

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201102/fc048477/attachment.sig>

From linde.philip at gmail.com  Mon Nov  2 22:49:56 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 2 Nov 2020 23:49:56 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <CAEzvDCUSv2tZQix5c58n2sUhq2y4cN_CkrTd5TPmETN-r35Mcg@mail.gmail.com>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <CAEzvDCUSv2tZQix5c58n2sUhq2y4cN_CkrTd5TPmETN-r35Mcg@mail.gmail.com>
Message-ID: <20201102234956.202c66f5887a93d94d33abd7@gmail.com>

On Mon, 2 Nov 2020 14:04:57 -0500
"A. E. Spencer-Reed" <easrng at gmail.com> wrote:

> Wait, what defines whitespace? I have a terrible idea...

A single space...I presume that by "terrible idea" you mean something
like a tab+space binary encoding of content length, if the whitespace
separating status from meta was an arbitrary sequence of spaces and/or
tabs. Alas, the spec is quite clear on this and we can only dream
(nightmares?) about hacks like that.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201102/0e5af548/attachment.sig>

From sean at conman.org  Tue Nov  3 00:21:29 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 2 Nov 2020 19:21:29 -0500
Subject: Proposal about content-size and hash
In-Reply-To: <20201102234432.963c5bfaa6a2bdaa5317c608@gmail.com>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201102234432.963c5bfaa6a2bdaa5317c608@gmail.com>
Message-ID: <20201103002129.GV30302@brevard.conman.org>

It was thus said that the Great Philip Linde once stated:
> On Mon, 02 Nov 2020 18:54:32 +0000
> prisonpotato at tilde.team wrote:
> 
> > a new response code, like 22: Response with size.
> > 
> > 20 text/gemini
> > 22 100 text/gemini
> 
> The spec currently explicitly prohibits this kind of use of the status
> codes, but it could be a new first-digit response code, e.g. 7x. This
> would naturally take some time for the implementations to adopt.
> 
> I personally don't miss content-length in practice, but I think the
> fact that it wasn't included in the protocol from the beginning is the
> most compelling argument against it. That said, I'd happily implement,
> something like a new status code to account for such a change in my
> client. When would servers dare use it, though?

  Now.

  As I'm wont to do, I will often code up some weird "proof-of-concept" for
my Gemini server, and if anyone wants to play around with this concept,
there's a server for that:

	gemini://gemini.conman.org/test/testsize.gemini

  The above page will return a normal 20, but all the links on it will
return a 22 with a size, then MIME type.

  -spc (Will implement dodgy specs on a whim for $200, Alex)


From me at adnano.co  Tue Nov  3 01:47:43 2020
From: me at adnano.co (Adnan Maolood)
Date: Mon, 02 Nov 2020 20:47:43 -0500
Subject: Using Common Name in certificates
Message-ID: <C6T90H9ZFURY.1QIO6R0ZL5L31@nitro>

The documentation for the Go crypto/tls package has this to say about
using the Common Name field in certificates:

>  The legacy Common Name field is ignored unless it's a valid hostname,
>  the certificate doesn't have any Subject Alternative Names, and the
>  GODEBUG environment variable is set to "x509ignoreCN=0". Support for
>  Common Name is deprecated will be entirely removed in the future.

https://golang.org/pkg/crypto/x509/#Certificate.VerifyHostname

In light of this, should Gemini servers avoid using the Common Name for
certificates, or at least provide a Subject Alternative Name as well?
For go-gemini I had to vendor in the hostname verification code from
crypto/tls and modify it to accept common names without setting the
GODEBUG environment variable.

From colecmac at protonmail.com  Tue Nov  3 02:04:40 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 03 Nov 2020 02:04:40 +0000
Subject: Using Common Name in certificates
In-Reply-To: <C6T90H9ZFURY.1QIO6R0ZL5L31@nitro>
References: <C6T90H9ZFURY.1QIO6R0ZL5L31@nitro>
Message-ID: <PSxRJujkaIvzxwG5mgn6yF9pAHOPOoK-NcCdJ4I7GPwUnf8rj244gWgBe6Utc5OJtCq6jymAk4OomHv5Snv0LB9JlSAYfecIt82DtylMLxo=@protonmail.com>

I had to fix this in my go-gemini library. I don't think telling
people to not use CommonName is a good solution, and I don't really
see the issue with it anyway.

When I made the fix, I posted about it on the mailing list:

https://lists.orbitalfox.eu/archives/gemini/2020/002391.html


Cheers,
makeworld



From me at adnano.co  Tue Nov  3 02:07:08 2020
From: me at adnano.co (Adnan Maolood)
Date: Mon, 02 Nov 2020 21:07:08 -0500
Subject: Using Common Name in certificates
In-Reply-To: <PSxRJujkaIvzxwG5mgn6yF9pAHOPOoK-NcCdJ4I7GPwUnf8rj244gWgBe6Utc5OJtCq6jymAk4OomHv5Snv0LB9JlSAYfecIt82DtylMLxo=@protonmail.com>
Message-ID: <C6T9FCKQWFJ8.SU0F1NM4LIAT@nitro>

On Mon Nov 2, 2020 at 9:04 PM EST,  wrote:
> When I made the fix, I posted about it on the mailing list:
>
> https://lists.orbitalfox.eu/archives/gemini/2020/002391.html

Using `==` to compare the common name with the domain name doesn't
handle all cases though. The common name could contain a wildcard
hostname.

To resolve this I simply vendored in the parts of crypto/tls responsible
for hostname verification, and removed the GODEBUG variable check. You
can find the code here:

https://git.sr.ht/~adnano/go-gemini/tree/master/vendor.go

From marcx2 at welz.org.za  Tue Nov  3 07:33:34 2020
From: marcx2 at welz.org.za (marc)
Date: Tue, 3 Nov 2020 08:33:34 +0100
Subject: Licensing content for your capsule
In-Reply-To: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
Message-ID: <20201103073334.GA19302@localhost.localdomain>

> Hey folks, just dropping a quick note to ask everyone who operates a
> Gemini site to take a moment to choose a license for their content and
> add a note to their index page to this effect.
> 
> I recommend creative commons. My capsule is CC-BY-SA, which allows my
> content to be shared freely so long as it's attributed to me, and
> adapted or revised so long as the new work is also shared with CC-BY-SA.
> 
> This tool can help you pick a CC license:
> 
> https://creativecommons.org/share-your-work/


A final line in any .gmi file of the form

  "-- CC-BY-SA: Your Name"

would have the added benefit that it would survive being
copied around, and stay in place even if the original site
disappears. 

regards

marc

From raiz at stellarbound.space  Tue Nov  3 11:49:05 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 3 Nov 2020 14:49:05 +0300
Subject: Proposal about content-size and hash
In-Reply-To: <45ec4611abe3271483e3f109486256ad@tilde.team>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
Message-ID: <20201103144701.4c311b41@home>

On Mon, 02 Nov 2020 18:54:32 +0000
prisonpotato at tilde.team wrote:
> This seems like a neat solution to this problem to me, but I'm not
> sure if it would work at this stage of gemini's life cycle.  There
> are also of course the issues with dynamically sized responses as
> generated by CGI scripts and stuff like that, so maybe we could
> introduce a new response code, like 22: Response with size.
> 
> 20 text/gemini
> 22 100 text/gemini
> 
> This solves both problems by making content length optional again,
> but exposes a risk that this type of extension could be used to add
> more fields

The protocol allows minimalist clients to parse only the first digit of
response code and handle it, if such thing were to be implemented,
those clients would break since they'd treat '2' as '20', so I'm not in
favor of that.

Not to mention how it will start complicate the protocol, since now it
is accepted for certain response codes to have an alternative header
instead of the unified one specified in the spec, this opens the door
for other feature seekers to want to have their own set of response
codes with custom headers, and the simple implementations of the
protocol that used to be are obsolete and now are required to handle
many many cases of custom headers.

If so many people are not satisfied with the protocol as is without an
insane amount of features, why don't you move to a different protocol
that satisfies your needs?  Or rather, define your own, the only reason
I'm interested in the Gemini protocol in the first place is the lack of
features, yet ever since I joined this community the majority of
discussion is all about feature proposals, why don't we get creative
with what we have?

Petite Abeille have suggested the use of message/external-body MIME
type defined in RFC 1873 for such thing, and I know this looks like an
ugly solution, Guess what? so is adding content length to response
headers, the protocol was designed to make it impossible to do such
thing, lets keep it that way.  And by the way, you could outsource
certain operations to external protocols if you really need that,
gemtext allows a clean way of specifying links to different protocol
schemes by design.

From bjorn.warmedal at gmail.com  Tue Nov  3 12:11:16 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Tue, 3 Nov 2020 13:11:16 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <20201103144701.4c311b41@home>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team> <20201103144701.4c311b41@home>
Message-ID: <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>

On Tue, 3 Nov 2020 at 12:49, Ali Fardan <raiz at stellarbound.space> wrote:

>
> If so many people are not satisfied with the protocol as is without an
> insane amount of features, why don't you move to a different protocol
> that satisfies your needs?  Or rather, define your own, the only reason
> I'm interested in the Gemini protocol in the first place is the lack of
> features, yet ever since I joined this community the majority of
> discussion is all about feature proposals, why don't we get creative
> with what we have?
>

I assume the majority of people who suggest a feature want "gemini + X",
but everyone has their own idea of what X is :) If everyone built their own
protocol instead, almost all of those would be doomed from the get-go. To
get traction a potential new protocol needs to be appealing to as many as
possible -- and the creator needs to *reach out* to as many as possible at
that!

The most sold pie in the US is apple pie. It's pretty much nobody's
favourite, but it's virtually everyone's second-favourite.

The fact that so many feature proposals drop in suggests that Gemini has
done mostly everything right and appeals to a whole truckload of people.
It's a good thing, and it doesn't mean people *aren't* getting creative
with what they have (see
https://portal.mozz.us/gemini/mozz.us/files/rfc_gemini_favicon.gmi for
example). The lack of content-size or hash is by no means a deal-breaker
for me; I'll find other ways to reduce bandwidth usage for my use case if
need be. But that doesn't mean it *wouldn't be useful*, for my use case or
others'.


>
> Petite Abeille have suggested the use of message/external-body MIME
> type defined in RFC 1873 for such thing, and I know this looks like an
> ugly solution, Guess what? so is adding content length to response
> headers, the protocol was designed to make it impossible to do such
> thing, lets keep it that way.  And by the way, you could outsource
> certain operations to external protocols if you really need that,
> gemtext allows a clean way of specifying links to different protocol
> schemes by design.
>

Well, if all I want is gemini + X, then using protocol Y with its bloat of
features I *don't* need is less tempting than sending a feature proposal to
the gemini ML. And again, that's a good thing! It means people are engaging
and shaping the trajectory of their own internet future. A rejected
proposal is a hundred times better than one that was never discussed for
fear of ridicule or social repercussions. The community is alive and
vibrant :D

Cheers,
ew0k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201103/d1c1bb61/attachment.htm>

From petite.abeille at gmail.com  Tue Nov  3 12:27:57 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 3 Nov 2020 13:27:57 +0100
Subject: Proposal about content-size and hash
In-Reply-To: <20201103144701.4c311b41@home>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team> <20201103144701.4c311b41@home>
Message-ID: <CBAE52A3-7364-4C6D-AE51-819721B7B8A1@gmail.com>



> On Nov 3, 2020, at 12:49, Ali Fardan <raiz at stellarbound.space> wrote:
> 
> gemtext allows a clean way of specifying links to different protocol
> schemes by design

It also allows embedding content through data URI magic. Which may still be giving Solderpunk heartburns :D

C'est la vie.

From khuxkm at tilde.team  Tue Nov  3 12:56:31 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Tue, 03 Nov 2020 12:56:31 +0000
Subject: Using Common Name in certificates
In-Reply-To: <C6T90H9ZFURY.1QIO6R0ZL5L31@nitro>
References: <C6T90H9ZFURY.1QIO6R0ZL5L31@nitro>
Message-ID: <86669807a8dfeedaa64d189cd9127893@tilde.team>

November 2, 2020 8:47 PM, "Adnan Maolood" <me at adnano.co> wrote:

> The documentation for the Go crypto/tls package has this to say about
> using the Common Name field in certificates:
> 
>> The legacy Common Name field is ignored unless it's a valid hostname,
>> the certificate doesn't have any Subject Alternative Names, and the
>> GODEBUG environment variable is set to "x509ignoreCN=0". Support for
>> Common Name is deprecated will be entirely removed in the future.
> 
> https://golang.org/pkg/crypto/x509/#Certificate.VerifyHostname
> 
> In light of this, should Gemini servers avoid using the Common Name for
> certificates, or at least provide a Subject Alternative Name as well?
> For go-gemini I had to vendor in the hostname verification code from
> crypto/tls and modify it to accept common names without setting the
> GODEBUG environment variable.

I recently started work on my own Gemini server (still a work in progress), and I needed a certificate to test my server. So I fired up ye olde DuckDuckGo and searched "create self signed certificate openssl" and found:

> It's important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can't avoid using the Subject Alternate Name.

Now, of course, this doesn't have to apply to Gemini, but I wanted something that was as future-proof as I could make it, so I found a command to put names in the SAN without creating a config file, which got me:

> openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes \
>  -keyout localhost.key -out localhost.crt -subj "/CN=7f000001.nip.io" \
>  -addext "subjectAltName=DNS:7f000001.nip.io"

(I was testing localhost, so I used 7f000001.nip.io, which points to 127.0.0.1. RSA is fine enough security as is.)

This actually isn't that hard to do; I'm not sure what the equivalent would be in other SSL libraries, but at least in OpenSSL it's pretty simple. We don't necessarily have to say "don't use the CN", but people should configure their certificates so that clients don't have to mess around with stdlib code just to accept them.

Just my two cents,
Robert "khuxkm" Miles

From raiz at stellarbound.space  Tue Nov  3 13:28:46 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 3 Nov 2020 16:28:46 +0300
Subject: Proposal about content-size and hash
In-Reply-To: <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
Message-ID: <20201103162846.77a9821f@home>

On Tue, 3 Nov 2020 13:11:16 +0100
Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> I assume the majority of people who suggest a feature want "gemini +
> X", but everyone has their own idea of what X is :) If everyone built
> their own protocol instead, almost all of those would be doomed from
> the get-go. To get traction a potential new protocol needs to be
> appealing to as many as possible -- and the creator needs to *reach
> out* to as many as possible at that!

I agree on the fact the if everyone rolled their own protocol it'll be
a mess, however, the appeal of Gemini would fade away if it starts
growing in terms of features, the way I see to grow the community is
hosting more content in the gemspace and going forward with refining
the spec to a final paper that is more precise and easier for newcomers
to get a grasp on because the protocol has evolved along with the
current spec paper and stuff has been added that wasn't intended to be
there from the beginning.

It would be discouraging for people to have their implementations break
so often because the protocol is never stable and features get
added/removed with stuff changing all the time.

The way I see it, Gemini is complete, the only way going forward is
tidying up the spec and growing the gemspace with more content, and in
the meantime, Gemini implementations will mature and become more
appealing for newcomers.

> Well, if all I want is gemini + X, then using protocol Y with its
> bloat of features I *don't* need is less tempting than sending a
> feature proposal to the gemini ML. And again, that's a good thing! It
> means people are engaging and shaping the trajectory of their own
> internet future. A rejected proposal is a hundred times better than
> one that was never discussed for fear of ridicule or social
> repercussions. The community is alive and vibrant :D

You wouldn't want to add revision control to Gemini, that's what Git is
for, just like you wouldn't add remote shell to Gemini because that's
what SSH is for, this should apply to everything, use the right tool
for the right task.

From khuxkm at tilde.team  Tue Nov  3 14:07:49 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Tue, 03 Nov 2020 14:07:49 +0000
Subject: Proposal about content-size and hash
In-Reply-To: <20201103162846.77a9821f@home>
References: <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
Message-ID: <9babe2484660e30a2de2a70eed5ff774@tilde.team>

November 3, 2020 8:28 AM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> On Tue, 3 Nov 2020 13:11:16 +0100
> Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
>> I assume the majority of people who suggest a feature want "gemini +
>> X", but everyone has their own idea of what X is :) If everyone built
>> their own protocol instead, almost all of those would be doomed from
>> the get-go. To get traction a potential new protocol needs to be
>> appealing to as many as possible -- and the creator needs to *reach
>> out* to as many as possible at that!
> 
> I agree on the fact the if everyone rolled their own protocol it'll be
> a mess, however, the appeal of Gemini would fade away if it starts
> growing in terms of features, the way I see to grow the community is
> hosting more content in the gemspace and going forward with refining
> the spec to a final paper that is more precise and easier for newcomers
> to get a grasp on because the protocol has evolved along with the
> current spec paper and stuff has been added that wasn't intended to be
> there from the beginning.

I don't really think this is a scenario where there are things that weren't "intended"; what was intended was to create a protocol, lighter than the Web and heavier than Gopher, for serving content securely (at least, from where I sit and what I see). Obviously, the protocol isn't perfect, so sometimes it needs things added that may not have been there at the beginning, but fit the intent of the protocol.

> It would be discouraging for people to have their implementations break
> so often because the protocol is never stable and features get
> added/removed with stuff changing all the time.

The spec was created around August of 2019 (at least, the list was first posted to in mid-August). It's only a year old. If a breaking change *needs* to be made, it's not too late yet.

> The way I see it, Gemini is complete, the only way going forward is
> tidying up the spec and growing the gemspace with more content, and in
> the meantime, Gemini implementations will mature and become more
> appealing for newcomers.

I'm willing to agree with you on this point; it seems like we don't *need* this breaking change, at least not yet.

>> Well, if all I want is gemini + X, then using protocol Y with its
>> bloat of features I *don't* need is less tempting than sending a
>> feature proposal to the gemini ML. And again, that's a good thing! It
>> means people are engaging and shaping the trajectory of their own
>> internet future. A rejected proposal is a hundred times better than
>> one that was never discussed for fear of ridicule or social
>> repercussions. The community is alive and vibrant :D
> 
> You wouldn't want to add revision control to Gemini, that's what Git is
> for, just like you wouldn't add remote shell to Gemini because that's
> what SSH is for, this should apply to everything, use the right tool
> for the right task.

That's not really a good comparison. Obviously you wouldn't add revision control and/or a remote shell to Gemini; that has nothing to do with serving content. But if the X in "gemini + X" has to do with content (serving it, etc.), it's worth considering.

Just my two cents,
Robert "khuxkm" Miles

From raiz at stellarbound.space  Tue Nov  3 15:22:04 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 3 Nov 2020 18:22:04 +0300
Subject: Proposal about content-size and hash
In-Reply-To: <9babe2484660e30a2de2a70eed5ff774@tilde.team>
References: <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
 <9babe2484660e30a2de2a70eed5ff774@tilde.team>
Message-ID: <20201103182204.2cefe578@home>

On Tue, 03 Nov 2020 14:07:49 +0000
khuxkm at tilde.team wrote:
> I don't really think this is a scenario where there are things that
> weren't "intended"; what was intended was to create a protocol,
> lighter than the Web and heavier than Gopher, for serving content
> securely (at least, from where I sit and what I see). Obviously, the
> protocol isn't perfect, so sometimes it needs things added that may
> not have been there at the beginning, but fit the intent of the
> protocol.

Let me reword... weren't considered from the beginning, here is an
example: 5.4.2 from the spec goes into great detail even defining what
whitespace is, while 5.5.2 and 5.5.3 aren't defined in the same style
as 5.4.2 was defined, there's nothing wrong with that, the protocol
evolved and these were added later, though they weren't considered at
the very beginning, that's what I meant by weren't "intended".

> The spec was created around August of 2019 (at least, the list was
> first posted to in mid-August). It's only a year old. If a breaking
> change *needs* to be made, it's not too late yet.

If a crucial change were to be made, of course, I'm all for it, but in
my opinion, it seems that there is no need for any more features to be
added, and the way I see it is moving towards stabilizing the spec
without any breaking changes, that's just my opinion.

> That's not really a good comparison. Obviously you wouldn't add
> revision control and/or a remote shell to Gemini; that has nothing to
> do with serving content. But if the X in "gemini + X" has to do with
> content (serving it, etc.), it's worth considering.

I may have went to the extreme with this, but take a look at web land,
there's applications written to entirely run on the web, those include
mail readers, video and music players (implemented in JS), document
editors (Google docs and whatnot), and finally, control panels which
serve the purpose of a remote shell, obviously, that's not SSH, but if
more and more features get accepted to the protocol, how long until
that becomes possible?

Applications can be implemented in Gemini currently, using CGI, these
applications don't have to do with serving content, you could implement
a calculator, a banner generator, and a git repository viewer, all
using what is currently available, I have no argument against
implementing such applications using CGI which currently allows
extending the protocol without requiring more features to be added.

From cowan at ccil.org  Tue Nov  3 15:32:11 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 3 Nov 2020 10:32:11 -0500
Subject: Licensing content for your capsule
In-Reply-To: <20201103073334.GA19302@localhost.localdomain>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103073334.GA19302@localhost.localdomain>
Message-ID: <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>

On Tue, Nov 3, 2020 at 2:33 AM marc <marcx2 at welz.org.za> wrote:


> A final line in any .gmi file of the form
>
>   "-- CC-BY-SA: Your Name"
>
> would have the added benefit that it would survive being
> copied around, and stay in place even if the original site
> disappears.
>

Agreed.  But it's advisable to have an actual copyright notice using either
? or the English word "Copyright" and the current year.  If you make it a
link line, you can also link to the exact license you are using.

Note that there is no reason to update the copyright date when you make a
change, much less to make a change *just* to update the date.  Doing so
will not extend your copyright, and most companies don't have any reason to
care about the status of their IP in 2210.

I am not a lawyer and this is not legal advice -- but it is not the
unauthorized practice of law, either.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Cash registers don't really add and subtract;
        they only grind their gears.
But then they don't really grind their gears, either;
        they only obey the laws of physics.  --Unknown


> regards
>
> marc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201103/a7d16211/attachment.htm>

From khuxkm at tilde.team  Tue Nov  3 15:33:31 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Tue, 03 Nov 2020 15:33:31 +0000
Subject: Proposal about content-size and hash
In-Reply-To: <20201103182204.2cefe578@home>
References: <20201103182204.2cefe578@home> <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
 <9babe2484660e30a2de2a70eed5ff774@tilde.team>
Message-ID: <c826571ccee1b85ecadebb49e83ae371@tilde.team>

November 3, 2020 10:22 AM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> On Tue, 03 Nov 2020 14:07:49 +0000
> khuxkm at tilde.team wrote:
> 
>> I don't really think this is a scenario where there are things that
>> weren't "intended"; what was intended was to create a protocol,
>> lighter than the Web and heavier than Gopher, for serving content
>> securely (at least, from where I sit and what I see). Obviously, the
>> protocol isn't perfect, so sometimes it needs things added that may
>> not have been there at the beginning, but fit the intent of the
>> protocol.
> 
> Let me reword... weren't considered from the beginning, here is an
> example: 5.4.2 from the spec goes into great detail even defining what
> whitespace is, while 5.5.2 and 5.5.3 aren't defined in the same style
> as 5.4.2 was defined, there's nothing wrong with that, the protocol
> evolved and these were added later, though they weren't considered at
> the very beginning, that's what I meant by weren't "intended".

I think this is an apples to oranges comparison; 5.5.2 has to do with the text/gemini media type, which, while it is a part of the spec, isn't protocol based (i.e; I could serve text/gemini on a web server if I really wanted to)

>> The spec was created around August of 2019 (at least, the list was
>> first posted to in mid-August). It's only a year old. If a breaking
>> change *needs* to be made, it's not too late yet.
> 
> If a crucial change were to be made, of course, I'm all for it, but in
> my opinion, it seems that there is no need for any more features to be
> added, and the way I see it is moving towards stabilizing the spec
> without any breaking changes, that's just my opinion.

I agreed with you on that point though; this isn't needed, at least not yet. But if the breaking change needed to be made, like you said, it should be made. This attitude of "oh, we don't need anything else" might convince some people who otherwise would have had good suggestions to back away; after all, if we aren't adding new features, why bother giving your suggestion?

>> That's not really a good comparison. Obviously you wouldn't add
>> revision control and/or a remote shell to Gemini; that has nothing to
>> do with serving content. But if the X in "gemini + X" has to do with
>> content (serving it, etc.), it's worth considering.
> 
> I may have went to the extreme with this, but take a look at web land,
> there's applications written to entirely run on the web, those include
> mail readers, video and music players (implemented in JS), document
> editors (Google docs and whatnot), and finally, control panels which
> serve the purpose of a remote shell, obviously, that's not SSH, but if
> more and more features get accepted to the protocol, how long until
> that becomes possible?

Just for the sake of it, I really want to try and make a remote shell in Gemini CGI, just to prove a point. You can do it already, with the protocol as-is; send the command as a query to a CGI endpoint

> Applications can be implemented in Gemini currently, using CGI, these
> applications don't have to do with serving content, you could implement
> a calculator, a banner generator, and a git repository viewer, all
> using what is currently available, I have no argument against
> implementing such applications using CGI which currently allows
> extending the protocol without requiring more features to be added.

Okay, but with all due respect, what does that have to do with content size? CGI isn't going to help the fact that the protocol currently has no way to indicate "this is how big the response will be" or "this is the hash of the file". Those questions, at least in my opinion, need to be answered at the protocol level, unless we're going to make a .well-known for Gemini.

Just my two cents,
Robert "khuxkm" Miles

From raiz at stellarbound.space  Tue Nov  3 15:42:19 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 3 Nov 2020 18:42:19 +0300
Subject: Proposal about content-size and hash
In-Reply-To: <c826571ccee1b85ecadebb49e83ae371@tilde.team>
References: <20201103182204.2cefe578@home> <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
 <9babe2484660e30a2de2a70eed5ff774@tilde.team>
 <c826571ccee1b85ecadebb49e83ae371@tilde.team>
Message-ID: <20201103184219.08703b67@home>

On Tue, 03 Nov 2020 15:33:31 +0000
khuxkm at tilde.team wrote:
> I think this is an apples to oranges comparison; 5.5.2 has to do with
> the text/gemini media type, which, while it is a part of the spec,
> isn't protocol based (i.e; I could serve text/gemini on a web server
> if I really wanted to)

I'm referring to this in the context of the spec, not the protocol
itself.

> Just for the sake of it, I really want to try and make a remote shell
> in Gemini CGI, just to prove a point. You can do it already, with the
> protocol as-is; send the command as a query to a CGI endpoint

Great, that'd be a creative way to make use of the limitations of a
protocol instead of suggesting adding more.

> Okay, but with all due respect, what does that have to do with
> content size? CGI isn't going to help the fact that the protocol
> currently has no way to indicate "this is how big the response will
> be" or "this is the hash of the file". Those questions, at least in
> my opinion, need to be answered at the protocol level, unless we're
> going to make a .well-known for Gemini.

With all due respect, EOF should be an indicator.


From martin at no.ucant.org  Tue Nov  3 15:43:17 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Tue, 3 Nov 2020 15:43:17 +0000 (GMT)
Subject: Proposal about content-size and hash
In-Reply-To: <20201103144701.4c311b41@home>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team> <20201103144701.4c311b41@home>
Message-ID: <alpine.DEB.2.21.2011031533580.31140@pling.qwghlm.org>

On Tue, 3 Nov 2020, Ali Fardan wrote:

> If so many people are not satisfied with the protocol as is without an
> insane amount of features, why don't you move to a different protocol
> that satisfies your needs?  Or rather, define your own, the only reason

The problem, as I see it, is that some people want there *not* to be a 
simple protocol, and will propose modifications to make it extensible. The 
minimalist attitude is perceived, wrongly, by some people as 
self-righteous and worthy of being taken down a peg or two; there are also 
other reasons for wanting to drive up the cost of information sharing 
online.

If the lack of features in Gemini means people go off and use some other, 
possibly new or incompatible, protocol, that's not too much of a problem, 
and more people's preferences will be satisfied. It may be that those who 
want a minimalist protocol should spec up a non-minimalist protocol and 
implement that, and then tell everyone who wants Gemini not to be 
minimalist to go and use this other protocol. In the presence of a viable 
alternative protocol to Gemini, the remaining arguments in favour of 
extending Gemini would much more obviously be in bad faith.

On the other hand, if eventually Solderpunk gives in and makes Gemini 
extensible, then the supporters of a minimalist protocol will just go and 
make their own new protocol and the cycle of agitation against minimalism 
will repeat, so one's just competing for the Gemini name and mindshare.

Mk

-- 
Martin Keegan, @mk270, https://mk.ucant.org/

From phoebe at slub.co  Tue Nov  3 15:48:14 2020
From: phoebe at slub.co (phoebe jenkins)
Date: Tue, 3 Nov 2020 10:48:14 -0500
Subject: Licensing content for your capsule
In-Reply-To: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
Message-ID: <20201103154814.GA16063@star.local>

On Mon, Nov 02, 2020 at 10:34:42AM -0400, Drew DeVault wrote:
> Hey folks, just dropping a quick note to ask everyone who operates a
> Gemini site to take a moment to choose a license for their content and
> add a note to their index page to this effect.
> 
> I recommend creative commons. My capsule is CC-BY-SA, which allows my
> content to be shared freely so long as it's attributed to me, and
> adapted or revised so long as the new work is also shared with CC-BY-SA.
> 
> This tool can help you pick a CC license:
> 
> https://creativecommons.org/share-your-work/
> 
> Cheers!

because i am the person i am, i included my typical licensing on my capsule:

  license/copyright:
  it is illegal for anyone to look at any of this or use any of this for any
  purposes, especially me


From khuxkm at tilde.team  Tue Nov  3 15:51:20 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Tue, 03 Nov 2020 15:51:20 +0000
Subject: Proposal about content-size and hash
In-Reply-To: <20201103184219.08703b67@home>
References: <20201103184219.08703b67@home> <20201103182204.2cefe578@home>
 <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
 <9babe2484660e30a2de2a70eed5ff774@tilde.team>
 <c826571ccee1b85ecadebb49e83ae371@tilde.team>
Message-ID: <36aa36810939bea805e631ed2c39b401@tilde.team>

November 3, 2020 10:42 AM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> On Tue, 03 Nov 2020 15:33:31 +0000
> khuxkm at tilde.team wrote:
> 
>> I think this is an apples to oranges comparison; 5.5.2 has to do with
>> the text/gemini media type, which, while it is a part of the spec,
>> isn't protocol based (i.e; I could serve text/gemini on a web server
>> if I really wanted to)
> 
> I'm referring to this in the context of the spec, not the protocol
> itself.

Alright, fine, I'll cede that point. Still, if anything, 5.5.2 and 5.5.3 show that new features that have been suggested have, in fact, made it into the spec. If we tell people not to suggest new features at all, we might miss out on some things we otherwise may have wanted.

>> Okay, but with all due respect, what does that have to do with
>> content size? CGI isn't going to help the fact that the protocol
>> currently has no way to indicate "this is how big the response will
>> be" or "this is the hash of the file". Those questions, at least in
>> my opinion, need to be answered at the protocol level, unless we're
>> going to make a .well-known for Gemini.
> 
> With all due respect, EOF should be an indicator.

But how can I differentiate "EOF, the file is over" vs "EOF, the socket died"?

Just my two cents,
Robert "khuxkm" Miles

From tomasino at lavabit.com  Tue Nov  3 15:54:56 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 3 Nov 2020 15:54:56 +0000
Subject: Licensing content for your capsule
In-Reply-To: <20201103154814.GA16063@star.local>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103154814.GA16063@star.local>
Message-ID: <7299b608-be99-0a3b-7f2e-2da92813f3cb@lavabit.com>

On 11/3/20 3:48 PM, phoebe jenkins wrote:
> because i am the person i am, i included my typical licensing on my capsule:
> 
>   license/copyright:
>   it is illegal for anyone to look at any of this or use any of this for any
>   purposes, especially me

Sounds like you might like Schrodinger's License

https://github.com/benlk/misc-licenses/blob/master/schrodinger-license.md


From raiz at stellarbound.space  Tue Nov  3 16:04:43 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 3 Nov 2020 19:04:43 +0300
Subject: Proposal about content-size and hash
In-Reply-To: <36aa36810939bea805e631ed2c39b401@tilde.team>
References: <20201103184219.08703b67@home> <20201103182204.2cefe578@home>
 <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
 <9babe2484660e30a2de2a70eed5ff774@tilde.team>
 <c826571ccee1b85ecadebb49e83ae371@tilde.team>
 <36aa36810939bea805e631ed2c39b401@tilde.team>
Message-ID: <20201103190443.4feb675e@home>

On Tue, 03 Nov 2020 15:51:20 +0000
khuxkm at tilde.team wrote:
> Alright, fine, I'll cede that point. Still, if anything, 5.5.2 and
> 5.5.3 show that new features that have been suggested have, in fact,
> made it into the spec. If we tell people not to suggest new features
> at all, we might miss out on some things we otherwise may have wanted.

I'm absolutely not against these two gemtext features, I'm just
suggesting that for the spec paper to be finalized, there has to be an
agreement within the community that the protocol is ready and there's
no more to be added.  Until of course, a newer version of the protocol
gets released, but that's for the far future when technology evolves,
for example, when TLS becomes obsolete.

> But how can I differentiate "EOF, the file is over" vs "EOF, the
> socket died"?

Suppose you have content length in the header and the content received
didn't match the content length, what would you do then? What purpose
would it serve to know if it's a socket dying EOF or end of stream EOF?

From jordan at crowesnest.io  Tue Nov  3 16:26:30 2020
From: jordan at crowesnest.io (Jordan)
Date: Tue, 03 Nov 2020 16:26:30 +0000
Subject: FAQ updates
In-Reply-To: <C6RZDHBGABS0.2U4ZBVJ68YSSM@stilgar>
References: <C6RZDHBGABS0.2U4ZBVJ68YSSM@stilgar>
Message-ID: <rfxvH9XRNYGN2ml6p5F8ZxpOejkKnUr707VExSQKdHc@cp7-web-043.plabs.ch>

Awesome, thanks!


From sean at conman.org  Tue Nov  3 16:26:51 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 3 Nov 2020 11:26:51 -0500
Subject: Proposal about content-size and hash
In-Reply-To: <20201103190443.4feb675e@home>
References: <20201103182204.2cefe578@home> <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team> <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
 <9babe2484660e30a2de2a70eed5ff774@tilde.team>
 <c826571ccee1b85ecadebb49e83ae371@tilde.team>
 <36aa36810939bea805e631ed2c39b401@tilde.team> <20201103190443.4feb675e@home>
Message-ID: <20201103162651.GW30302@brevard.conman.org>

It was thus said that the Great Ali Fardan once stated:
> On Tue, 03 Nov 2020 15:51:20 +0000
> khuxkm at tilde.team wrote:
> 
> > But how can I differentiate "EOF, the file is over" vs "EOF, the
> > socket died"?
> 
> Suppose you have content length in the header and the content received
> didn't match the content length, what would you do then? What purpose
> would it serve to know if it's a socket dying EOF or end of stream EOF?

  Then one of the following is true if the content size doesn't match:

	1. The server has a bug in that it sent a malformed size.

	2. The server send a malformed file.

	2. The connction was dropped during the transfer.

	3. The client has a bug in counting the bytes being received.

  In any case, what you have may not be complete and an error (or warning)
should be presented to the operator to decide what to do next.

  -spc


From me at adnano.co  Tue Nov  3 20:20:45 2020
From: me at adnano.co (Adnan Maolood)
Date: Tue, 03 Nov 2020 15:20:45 -0500
Subject: Torture test 0026
Message-ID: <C6TWOOHZCD87.13WBX3NAJVBOA@nitro>

Currently torture test 0025 and 0026 on gemini.conman.org both lead to
/test/redirhell4. I believe that test 0026 should lead to
/test/redirhell5, as the next test leads to /test/redirhell6.

From phoebe at slub.co  Tue Nov  3 20:58:54 2020
From: phoebe at slub.co (phoebe jenkins)
Date: Tue, 3 Nov 2020 15:58:54 -0500
Subject: Licensing content for your capsule
In-Reply-To: <7299b608-be99-0a3b-7f2e-2da92813f3cb@lavabit.com>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103154814.GA16063@star.local>
 <7299b608-be99-0a3b-7f2e-2da92813f3cb@lavabit.com>
Message-ID: <20201103205854.GA24031@star.local>

On Tue, Nov 03, 2020 at 03:54:56PM +0000, James Tomasino wrote:
> On 11/3/20 3:48 PM, phoebe jenkins wrote:
> > because i am the person i am, i included my typical licensing on my capsule:
> > 
> >   license/copyright:
> >   it is illegal for anyone to look at any of this or use any of this for any
> >   purposes, especially me
> 
> Sounds like you might like Schrodinger's License
> 
> https://github.com/benlk/misc-licenses/blob/master/schrodinger-license.md
> 

hah, i like that! i was basically looking for a version of the "don't be evil"
license that i thought would actually work - basically, if you are a person that
needs to care about copyright, you can't use it :p 

From gmym at coopdot.com  Tue Nov  3 21:35:14 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Tue, 3 Nov 2020 22:35:14 +0100
Subject: Gemini file downloading client - a thought experiment
Message-ID: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>

This is in response to the thread on content length. I propose making a
supporting specification separate from the Gemini specification.

Feel free to extend the experiment with more problems and scenarios or
point out if I made the wrong conclusion.

Problem A: clients don't have enough information to show a progress bar

Scenario 1: download a tiny file

The user clicks the download button and the download is completed within a
second. No need to show progress.

Scenario 2: download a medium sized file

The user clicks the download button and the download starts. The client
shows the number of bytes downloaded, download speed and elapsed time. A
button labeled "show progress" appears after 5 seconds or so. The download
completes before the user is tempted to click that button.

Scenario 3: download a big file

Like scenario 2 except the user gets impatient enough to click the "show
progress" button. The client makes a separate request to a standardized
endpoint to get the needed information. If the server supports this
standard, the information is sent and the client can show the progress bar
to the user.

Problem B: we can't tell if the download succeed

Scenario 4: the TLS session terminated cleanly but we don't have full
confidence the download succeed

Verify the file using the information we have (from scenario 3) or present
the user with the option to fetch a hash from the standardized endpoint.

--
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201103/ac41f38e/attachment.htm>

From marcx2 at welz.org.za  Tue Nov  3 22:44:36 2020
From: marcx2 at welz.org.za (marc)
Date: Tue, 3 Nov 2020 23:44:36 +0100
Subject: Licensing content for your capsule
In-Reply-To: <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103073334.GA19302@localhost.localdomain>
 <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>
Message-ID: <20201103224436.GA32224@localhost.localdomain>

Hi - me again

> > A final line in any .gmi file of the form
> >
> >   "-- CC-BY-SA: Your Name"
> >
> > would have the added benefit that it would survive being
> > copied around, and stay in place even if the original site
> > disappears.
> >
> 
> Agreed.  But it's advisable to have an actual copyright notice using either
> ?? or the English word "Copyright" and the current year.  If you make it a
> link line, you can also link to the exact license you are using.
> 
> Note that there is no reason to update the copyright date when you make a
> change, much less to make a change *just* to update the date.  Doing so
> will not extend your copyright, and most companies don't have any reason to
> care about the status of their IP in 2210.

So I was under the impression that a creative work
is covered by copyright as soon as it is fixed in
a tangible medium... no special "copyright" word
required. Statues and paintings don't have 
a (c) sign on them, yet they are still covered.

Then again, I might have been misinformed - and
I am not lawyer either...

But my motivation for suggesting a format for
a license notice at the end of a .gmi file
is a bit different. It is not there to 
make prosecution of "pirates" easier, but to
facilitate reuse.

The corporate world likes to hold on to all
its rights ("all rights reserved") but
we don't have to - things like BSD, GPL and
CC-* are people saying that they are happy
to contribute to something shared, on certain terms. 
And if these statements are embedded in .gmi files,
tools can be built which parse this. 

Imagine a "greatest quotes in gemini-space"
site/capsule. Or "my favourite sites, long
lost". Or "a temporary mirror of a slow capsule
about to be slashdotted by me linking to it".

All these things could be done if the copyright
holders are fine with it... they just need to 
tell us.

regards

marc

From ehmry at posteo.net  Tue Nov  3 23:06:09 2020
From: ehmry at posteo.net (Emery)
Date: Wed, 04 Nov 2020 00:06:09 +0100
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
References: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
Message-ID: <14848efc-ab9c-44bf-9ad6-072cef37f27e@posteo.net>

On Dienstag, 3. November 2020 22:35:14 CET, Katarina Eriksson wrote:
> This is in response to the thread on content length. I propose making a
> supporting specification separate from the Gemini specification.
>
> Feel free to extend the experiment with more problems and scenarios or
> point out if I made the wrong conclusion.

Please, just use http or rsync or even better, magnet links for
directing to bulk data. GUS stats already show that there are ~1.5
octet-stream links for each Gemini page.

Cheers
E.

From sean at conman.org  Tue Nov  3 23:12:17 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 3 Nov 2020 18:12:17 -0500
Subject: Torture test 0026
In-Reply-To: <C6TWOOHZCD87.13WBX3NAJVBOA@nitro>
References: <C6TWOOHZCD87.13WBX3NAJVBOA@nitro>
Message-ID: <20201103231217.GY30302@brevard.conman.org>

It was thus said that the Great Adnan Maolood once stated:
> Currently torture test 0025 and 0026 on gemini.conman.org both lead to
> /test/redirhell4. I believe that test 0026 should lead to
> /test/redirhell5, as the next test leads to /test/redirhell6.

  It has been fixed.  Thank you for the report.

  -spc


From cowan at ccil.org  Tue Nov  3 23:31:01 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 3 Nov 2020 18:31:01 -0500
Subject: Licensing content for your capsule
In-Reply-To: <20201103224436.GA32224@localhost.localdomain>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103073334.GA19302@localhost.localdomain>
 <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>
 <20201103224436.GA32224@localhost.localdomain>
Message-ID: <CAD2gp_RJpPijgZ2hT4Nhjy1LE1LpM3gegfs1QLQbBAP=7bwCoA@mail.gmail.com>

On Tue, Nov 3, 2020 at 5:44 PM marc <marcx2 at welz.org.za> wrote:


> So I was under the impression that a creative work
> is covered by copyright as soon as it is fixed in
> a tangible medium... no special "copyright" word
> required. Statues and paintings don't have
> a (c) sign on them, yet they are still covered.
>

That's quite true.  But the advantage of a notice is that a license
violator can't claim "I didn't know". This is useful not only if you need
to go to court, but just to get them to take down their copy of your
content.  This often comes up when someone posts a copy with your name
removed, which of course CC-BY(-SA) does not allow.  If there is a notice,
you can send them an email saying very politely that they are willful
infringers of your copyright and may be liable for up to US$150,000 for
each illegally copied work.  They generally take it down fast.

The corporate world likes to hold on to all
> its rights ("all rights reserved")
>

By the way, that phrase has no legal meaning and can be completely
ignored.  It is neither a license nor a copyright notice.

> we don't have to - things like BSD, GPL and
> CC-* are people saying that they are happy
> to contribute to something shared, on certain terms.
> And if these statements are embedded in .gmi files,
> tools can be built which parse this.
>

+1, absolutely



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
People go through the bother of Christmas because Christmas helps them
to understand why they go through the bother of living out their lives
the rest of the year. For one brief instant, we see human society as it
should and could be, a world in which business has become the exchanging
of presents and in which nothing is important except the happiness and
well-being of the ultimate consumer.  --Northrop Frye (1948)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201103/715c6d32/attachment.htm>

From raiz at stellarbound.space  Wed Nov  4 01:15:02 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Wed, 4 Nov 2020 04:15:02 +0300
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
References: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
Message-ID: <20201104041502.230484e2@home>

On Tue, 3 Nov 2020 22:35:14 +0100
Katarina Eriksson <gmym at coopdot.com> wrote:
> Problem A: clients don't have enough information to show a progress
> bar

It is stated in
gemini://gemini.circumlunar.space/docs/best-practices.gmi that Gemini
is not well suited for large files, and the transmission of these could
be done using an external protocol.

> Scenario 3: download a big file
> 
> Like scenario 2 except the user gets impatient enough to click the
> "show progress" button. The client makes a separate request to a
> standardized endpoint to get the needed information. If the server
> supports this standard, the information is sent and the client can
> show the progress bar to the user.

Implementing this would be tricky on the server side, this would add
unnecessary complexity, what I would suggest instead if you really
insist on using Gemini for large file transfers is specifying file size
in the link label like so:

=> gemini://example.tld/large_file.bin Download (140 MB)

and then have the client show how much of the file is downloaded, now
that you know the file size, and know how much is downloaded, you don't
need a progress indicator to be implemented within the protocol.  Of
course this is on the client to implement, but wouldn't be tricky at
all.

> Scenario 4: the TLS session terminated cleanly but we don't have full
> confidence the download succeed
> 
> Verify the file using the information we have (from scenario 3) or
> present the user with the option to fetch a hash from the
> standardized endpoint.

This does not have to be embedded in the protocol, just do this:

SHA1: ad7ff785f989c9ff9cec92bd3d0bab035a54e997
SHA256: d2af944fe8b3af5cf5a9d8c3226d06ac6369d036fc591363dedc85344bc4daa7
=> gemini://example.tld/large_file.bin Download (140 MB)

now the user can verify their downloaded file, this is done all the
time even in HTTP land.

From gmym at coopdot.com  Wed Nov  4 01:25:47 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Wed, 4 Nov 2020 02:25:47 +0100
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <14848efc-ab9c-44bf-9ad6-072cef37f27e@posteo.net>
References: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
 <14848efc-ab9c-44bf-9ad6-072cef37f27e@posteo.net>
Message-ID: <CAObwWNhJ1NN1xJj+VBKs4qBO9ptDRrZrtyAAFun217ysu86Z=w@mail.gmail.com>

Emery <ehmry at posteo.net> wrote:

> On Dienstag, 3. November 2020 22:35:14 CET, Katarina Eriksson wrote:
> > This is in response to the thread on content length. I propose making a
> > supporting specification separate from the Gemini specification.
> >
> > Feel free to extend the experiment with more problems and scenarios or
> > point out if I made the wrong conclusion.
>
> Please, just use http or rsync or even better, magnet links for
> directing to bulk data. GUS stats already show that there are ~1.5
> octet-stream links for each Gemini page.
>
> Cheers
> E.
>

Yes, I agree. There are plenty of other protocols to choose from which are
better suited for transferring large files. But that's beside the point.

The purpose of this thought experiment is to find a use case where you
can't work within the constraints and have to add a content length header.

My expectation is that there are no such use case, certainly not one worth
braking compatibility for, but I'm keeping an open mind.

New people will join and ask for a content length header again in a few
months. It has happened before, more than once, in this very young mailing
list. If we would have a supporting specification which deals with this, we
would have something to point at.

Anyone who want to join me in my experiment?

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201104/c4adcd1a/attachment.htm>

From jordan at crowesnest.io  Wed Nov  4 03:30:54 2020
From: jordan at crowesnest.io (Jordan)
Date: Wed, 04 Nov 2020 03:30:54 +0000
Subject: Plain-text email
Message-ID: <QhREEttP8fCFTPlJLxyVj9ZftK01iYtWBtcvRSgA8U@cp7-web-039.plabs.ch>

Hello all,

Hope all is having a good day/night. I've noticed several emails on the
mailing lists are using html. Is there prehaps a suggestion in the
mailing list "rules" for using plain-text, so that everyone may be able
to read the emails?

If not, may we add it as a recommendation for partcipating in the
mailing list to use plain-text (if your email client/provider allows
it)? It sucks I can't read a few of the mails since I use a
terminal/plain-text only email client.

Thank you,

Jordan


From jordan at crowesnest.io  Wed Nov  4 03:37:34 2020
From: jordan at crowesnest.io (Jordan)
Date: Wed, 04 Nov 2020 03:37:34 +0000
Subject: Licensing content for your capsule
In-Reply-To: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
Message-ID: <SG0kmMpiZor6PPzj8YolZQwvdzF35lEleWREEy57uz8@cp3-web-024.plabs.ch>

On Mon Nov 2, 2020 at 9:34 AM EST, Drew DeVault wrote:
> --f7ceb9e8209701b61de27f66baf11d7ea731a827a4f69596fb9d8f0d9bf5
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain
>
> Hey folks, just dropping a quick note to ask everyone who operates a
> Gemini site to take a moment to choose a license for their content and
> add a note to their index page to this effect.
>
> I recommend creative commons. My capsule is CC-BY-SA, which allows my
> content to be shared freely so long as it's attributed to me, and
> adapted or revised so long as the new work is also shared with CC-BY-SA.
>
> This tool can help you pick a CC license:
>
> https://creativecommons.org/share-your-work/
>
> Cheers!
>
> --f7ceb9e8209701b61de27f66baf11d7ea731a827a4f69596fb9d8f0d9bf5--

Hello Mr. Devault,

Thanks for the reminder and the suggestion for CC-BY-SA. I'll have to do
a little research on the different licenses before I decide. Some
content will be copyright, but other content I wouldn't mind being
CC-BY-SA.

Thank you,

Jordan


From steve at swinslow.net  Wed Nov  4 03:37:45 2020
From: steve at swinslow.net (Steve Winslow)
Date: Tue, 3 Nov 2020 22:37:45 -0500
Subject: Licensing content for your capsule
In-Reply-To: <20201103224436.GA32224@localhost.localdomain>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103073334.GA19302@localhost.localdomain>
 <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>
 <20201103224436.GA32224@localhost.localdomain>
Message-ID: <20201104033745.GA13584@clariel.local>

Hi marc,

On Tue, Nov 03, 2020 at 11:44:36PM +0100, marc wrote:
> 
> But my motivation for suggesting a format for
> a license notice at the end of a .gmi file
> is a bit different. It is not there to 
> make prosecution of "pirates" easier, but to
> facilitate reuse.
> 
> <snip>
>
> And if these statements are embedded in .gmi files,
> tools can be built which parse this. 
>

Some FOSS licensing minutiae that most folks might not care about,
but sharing anyway  :)

If you're looking for a way to embed machine-parseable license info,
I'd suggest using SPDX short-form identifiers [1]. This is a
standardized way to embed one of the SPDX license IDs [2] into a work
in a way that is easily greppable, in a format such as the following
-- showing CC-BY-SA-4.0 as Drew suggested earlier:

  SPDX-License-Identifier: CC-BY-SA-4.0

The Linux kernel and several other FOSS projects have started adopting
identifiers like this, among other reasons to minimize the cruft of
multi-line comments with license headers and the like.

(Disclosure: I'm involved with the SPDX project, so I'm biased and
also interested in this stuff more than is probably healthy.)

Steve

[1] https://spdx.dev/ids
[2] https://spdx.org/licenses

From steve at swinslow.net  Wed Nov  4 04:50:23 2020
From: steve at swinslow.net (Steve Winslow)
Date: Tue, 3 Nov 2020 23:50:23 -0500
Subject: [ANN] gemini.swinslow.net - personal capsule
Message-ID: <20201104045023.GA79497@telemachus>

Hi all,

I've stopped lurking and replied to a couple of messages earlier today, so
figured I may as well share:

I've set up a personal Gemini capsule at gemini://gemini.swinslow.net/,
with a (short) gemlog at gemini://gemini.swinslow.net/gemlog/index.gmi.

Not sure whether this is in-scope for an announcement on this list,
apologies if not.

Steve

From tgrom.automail at nuegia.net  Wed Nov  4 05:42:50 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Tue, 3 Nov 2020 21:42:50 -0800
Subject: Right to be Forgotten and archiving (slightly changing my stance)
In-Reply-To: <20200905144750.061e4706@viridi>
References: <25EABBBA-3F53-4E33-ACF4-F9F3A165EC0D@fastmail.com>
 <5ab4d884-6274-cfdb-2735-ec4355ac8780@envs.net>
 <20200905144750.061e4706@viridi>
Message-ID: <20201103214250.2ac8cfb8@viridi>

On Sat, 5 Sep 2020 14:47:50 -0700
Tom <tgrom.automail at nuegia.net> wrote:

> On Sat, 5 Sep 2020 15:32:10 +0200
> cblte <cblte at envs.net> wrote:
> 
> > Am 04.09.20 um 23:46 schrieb Peter Deal:  
> > > Hello Geminauts,
> > >
> > > This is my first post here but I have been lurking for awhile.
> > >
> > > The thread about archiving led me just now to read about the Right
> > > to be Forgotten for the first time. It?s not something that I?ve
> > > ever heard anyone talk about in Canada, didn?t realize it was an
> > > active controversy in Europe. It raises interesting questions - is
> > > it possible to take information off the internet? Is it
> > > effectively gone for most people when you remove it from Google?
> > > What is more important - the value of the public in knowing what
> > > happened, or the value to the individual in getting on with his
> > > life after making a mistake?
> > >
> > > For Gemini protocol, I feel like if it becomes important enough to
> > > people, an archive is likely to be created whether we want it or
> > > not. There?s probably some value in the community itself
> > > proactively creating a sanctioned archive itself that respects
> > > creators? reasonable desires to have their content taken offline
> > > on demand.
> > >
> > > Regards,
> > > Peter    
> > 
> > Hello Everyone, 
> > the right to be forgotten is something we here in Germany are
> > discussing for quite some time. There is a semigood wikipedia
> > article about it here
> > https://en.wikipedia.org/wiki/Right_to_be_forgotten
> > 
> > Personally I think, if you put it up online visible to everyone,
> > there is a chance, that someone will take your content and save it.
> > Either for himself or for others. You can not protect that other
> > than handing out passwords to people who want to read your content.
> > But then it makes not much sense to put it up and online. Then you
> > could also send it via email. 
> > 
> > I personally like the idea of an internet archive. Respecting the
> > copyright. But if you give your copyright away by posting something
> > unter a CC licencse or similiar, then you give away your content
> > which could then be archived. 
> > 
> > -- Carsten
> >   
> 
> I strongly disagree. In the beginning of the web it was largely Open
> Content as described here: http://www.opencontent.org/ . All work is
> derivative work. People who make actual websites, not scrape together
> random half-broken crap from stack overflow and wordpress plugins
> surfed the web, saw something they liked, looked at the source and
> added it to their own site.
> 
> Copyright, or more specifically Intellectual property is a completely
> broken system and one that does not apply to cyberspace. All it serves
> to do is prop up broken business models, justify censorship and
> spyware in the name of saving reality a few reality tv shows.
> 
> The fundamental difference between meatspace and cyberspace is that
> copying something is free in cyberspace. It takes effort to reproduce
> a physical book. It does not cost anything at all to copy a digital
> book or other digital work.
> 
> Intellectual Property law works on creating artificial scarcity. An
> economy based on artificial scarcity is not a sustainable one. Nor
> should we be designing technical specifications around something as
> flimsy as that.
> 
> I would highly encourage you to watch Cory Doctorow's speech "The
> coming war on general computation" as he explores these ideas in
> depth.
> http://mirror.fem-net.de/CCC/28C3/mp4-h264-HQ/28c3-4848-en-the_coming_war_on_general_computation_h264.mp4
> 
> Any attempts to incorporate copyright into technical systems
> ultimately leads to rootkits and malware. aka 'trusted
> computing/DRM'. As engineers please try to understand the full
> ramifications of this. We already live in an age where all post 9/11
> CPUs manufactured by Intel come with mandatory backdoors/hardware
> spyware implants you can't turn off called Intel Management Engine.
> They implement a DRM called PAVP (Protected Audio Video Path). It's
> wired directly into your onboard Intel network interface and has
> hypervisor level access to all system memory.
> 
> There are other ways to financially back projects. We live in the age
> of self-publishing. A giant printing press is no longer required to
> get your word out. The backing of a giant publishing corporation is no
> longer required. We live in an age where individuals, not groups are
> the primary producers of artistic goods. The thing we want to
> incentive is the creation of these goods not the reproduction of
> already existing goods. As the initial production is the costly part.
> This is where business models like Patreon comes in. Now I'm not
> saying Patreon themselves are good, but the business model here is
> that of other individuals who like some content are able to directly
> fund the creation of more of said content. No matter how niche that
> content may be.
> 

Hello, I just wanted to followup with a middle-ground, or a re-word
rather on the proposed no-archive tag. Rather than a no-archive tag I
think a private-archive-only, no-public-archive, or
request-no-public-republish tag would do the same thing, and also
reflect reality better.

Even with a no-archive tag there's nothing you can practically do to
stop someone from doing something with the data ounce it is copied over
the network to their computer, however you REQUEST that whoever made
that archive, kindly do to republish publicly this specific tagged
document in a public archive.

This says nothing about what the individual choose to do on their own
hard drive or private members server or intranet, Private Library, or
what have you. Archival or cataloging software could very easily take
this into account and unlist content from publicly available indexes,
but still leave it up to the software operator if they want to also
unlist those documents for logged-in users, admins, or private library
members.

If we had to vote on the name of that tag, I personally prefer
no-public-archive.
-- 
 ________________________________________ 
/ You may be marching to the beat of a   \
| different drummer, but you're still in |
\ the parade.                            /
 ---------------------------------------- 
\
 \
   /\   /\   
  //\\_//\\     ____
  \_     _/    /   /
   / * * \    /^^^]
   \_\O/_/    [   ]
    /   \_    [   /
    \     \_  /  /
     [ [ /  \/ _/
    _[ [ \  /_/

From bjorn.warmedal at gmail.com  Wed Nov  4 07:59:06 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Wed, 4 Nov 2020 08:59:06 +0100
Subject: Plain-text email
In-Reply-To: <QhREEttP8fCFTPlJLxyVj9ZftK01iYtWBtcvRSgA8U@cp7-web-039.plabs.ch>
References: <QhREEttP8fCFTPlJLxyVj9ZftK01iYtWBtcvRSgA8U@cp7-web-039.plabs.ch>
Message-ID: <CAJScK0L-OY0yFkgu+boByAvxXBHKEUuX_JH54E0GNH59o8puTQ@mail.gmail.com>

On Wed, 4 Nov 2020 at 04:31, Jordan <jordan at crowesnest.io> wrote:
>
> Hello all,
>
> Hope all is having a good day/night. I've noticed several emails on the
> mailing lists are using html. Is there prehaps a suggestion in the
> mailing list "rules" for using plain-text, so that everyone may be able
> to read the emails?

Guilty as charged :)

Rules or not, I'll try to remember to switch to plain text mode in
gmail when writing to this ML. And don't be afraid to remind me again
:)

For anyone else using gmail and having a hard time finding this
option: in compose mode there's a three-dot menu button in the lower
right corner. That's where it's found.

From jbauer at paritybit.ca  Wed Nov  4 08:07:02 2020
From: jbauer at paritybit.ca (Jake Bauer)
Date: Wed, 04 Nov 2020 03:07:02 -0500
Subject: Plain-text email
In-Reply-To: <CAJScK0L-OY0yFkgu+boByAvxXBHKEUuX_JH54E0GNH59o8puTQ@mail.gmail.com>
Message-ID: <C6UBPGG8K8QQ.2PL400AHQX7I1@hades>

On Wed Nov 4, 2020 at 2:59 AM EST, Bj?rn W?rmedal wrote:
> For anyone else using gmail and having a hard time finding this
> option: in compose mode there's a three-dot menu button in the lower
> right corner. That's where it's found.

For others also wanting to use plaintext email, here is a website which
has instructions on setting up plaintext in various email clients and
web UIs, as well as an explanation of why plaintext is preferred by
many:

https://useplaintext.email/

--
Jake Bauer (~jbauer)
Web: https://www.paritybit.ca
Gem: gemini://paritybit.ca
PGP: 8A55 347B 2845 6BA7 0E43 B864 C3EB 9CAF 610B B4FB

ASCII ribbon campaign ? against HTML e-mail
http://www.asciiribbon.org | https://useplaintext.email

From bjorn.warmedal at gmail.com  Wed Nov  4 09:40:38 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Wed, 4 Nov 2020 10:40:38 +0100
Subject: Is anyone working on a libcurl PR for gemini support?
Message-ID: <CAJScK0+Yd15xKwYxHigVEGEhAuiv7nv-oLu0ExsbRkuD2vue4A@mail.gmail.com>

The discussion came up on IRC recently, so I thought I should ask.

Cheers,
ew0k

From julien at typed-hole.org  Wed Nov  4 10:19:42 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Wed, 4 Nov 2020 11:19:42 +0100
Subject: Is anyone working on a libcurl PR for gemini support?
In-Reply-To: <CAJScK0+Yd15xKwYxHigVEGEhAuiv7nv-oLu0ExsbRkuD2vue4A@mail.gmail.com>
References: <CAJScK0+Yd15xKwYxHigVEGEhAuiv7nv-oLu0ExsbRkuD2vue4A@mail.gmail.com>
Message-ID: <9c3eb1f3-d3d8-ee65-e024-7f41c1da6adb@typed-hole.org>

There was this curl fork https://git.burwell.io/mirrors/curl/ which 
hasn't been updated in a while but works pretty well.


From marcx2 at welz.org.za  Wed Nov  4 11:35:49 2020
From: marcx2 at welz.org.za (marc)
Date: Wed, 4 Nov 2020 12:35:49 +0100
Subject: Licensing content for your capsule
In-Reply-To: <20201104033745.GA13584@clariel.local>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103073334.GA19302@localhost.localdomain>
 <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>
 <20201103224436.GA32224@localhost.localdomain>
 <20201104033745.GA13584@clariel.local>
Message-ID: <20201104113549.GA9365@localhost.localdomain>

Hello Steve

> If you're looking for a way to embed machine-parseable license info,
> I'd suggest using SPDX short-form identifiers [1]. This is a
> standardized way to embed one of the SPDX license IDs [2] into a work
> in a way that is easily greppable, in a format such as the following
> -- showing CC-BY-SA-4.0 as Drew suggested earlier:
> 
>   SPDX-License-Identifier: CC-BY-SA-4.0

<snip>

> (Disclosure: I'm involved with the SPDX project, so I'm biased and
> also interested in this stuff more than is probably healthy.)

Hey, good to learn about the SPDX project,
it is great that people care about these things.

As a first (maybe incorrect) impression: One thing that
gives me pause is that its documents come with a, for lack
of a better word, corporate "All other rights expressly
reserved" blurb. 

Also, even though the list of licenses they have collected is
long, I can't spot (and let me know if otherwise)
any newer ethical licenses - the ones one
can find by following links on writing.kemitchell.com

For instance, one could imagine somebody publishing
their capsule under a "free but no surveillance, no deduction
of personal information" license, and if there is a
gatekeeper who approves an "acceptable" license, then
this might be harder. Maybe if there is an open
process on how license names can be added to the
curated list (does anybody claim to own the database ?), 
this concern would be reduced...

Then there is the (quite) unusual matter of the gemini
syntax - how to accommodate the "SPDX-License-Identifier" 
token in gemini files. The gemini markup doesn't 
have a "label: value" format, and no comments - its
markup are things like "*" or "##' and maybe even
informally "--". Noting that this lack of extensibility is 
deemed a feature, not a bug... and correctly so in my
view. 

regards

marc

From sir at cmpwn.com  Wed Nov  4 13:44:34 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 04 Nov 2020 09:44:34 -0400
Subject: Plain-text email
In-Reply-To: <QhREEttP8fCFTPlJLxyVj9ZftK01iYtWBtcvRSgA8U@cp7-web-039.plabs.ch>
Message-ID: <C6UIVVYZPRGL.PU63DRVX0US8@taiga>

https://useplaintext.email may be helpful.

From easrng at gmail.com  Wed Nov  4 16:50:50 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Wed, 4 Nov 2020 11:50:50 -0500
Subject: Proposal about content-size and hash
In-Reply-To: <20201103162651.GW30302@brevard.conman.org>
References: <20201103182204.2cefe578@home> <20201103162846.77a9821f@home>
 <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201103144701.4c311b41@home>
 <CAJScK0LswwhbktiWnmSW0USVzcgV_L5KV7_vBSuL9-_g9XLAGA@mail.gmail.com>
 <9babe2484660e30a2de2a70eed5ff774@tilde.team>
 <c826571ccee1b85ecadebb49e83ae371@tilde.team>
 <36aa36810939bea805e631ed2c39b401@tilde.team> <20201103190443.4feb675e@home>
 <20201103162651.GW30302@brevard.conman.org>
Message-ID: <CAEzvDCWfBYjuEAyi-4sk2dphsZ6mjqSRaKq2kPKCZm5h86QmKA@mail.gmail.com>

Another solution might be to send a single part multipart/mixed
response, which IIRC can do headers.

On Tue, Nov 3, 2020 at 11:27 AM Sean Conner <sean at conman.org> wrote:
>
> It was thus said that the Great Ali Fardan once stated:
> > On Tue, 03 Nov 2020 15:51:20 +0000
> > khuxkm at tilde.team wrote:
> >
> > > But how can I differentiate "EOF, the file is over" vs "EOF, the
> > > socket died"?
> >
> > Suppose you have content length in the header and the content received
> > didn't match the content length, what would you do then? What purpose
> > would it serve to know if it's a socket dying EOF or end of stream EOF?
>
>   Then one of the following is true if the content size doesn't match:
>
>         1. The server has a bug in that it sent a malformed size.
>
>         2. The server send a malformed file.
>
>         2. The connction was dropped during the transfer.
>
>         3. The client has a bug in counting the bytes being received.
>
>   In any case, what you have may not be complete and an error (or warning)
> should be presented to the operator to decide what to do next.
>
>   -spc
>


-- 
?

From acdw at acdw.net  Wed Nov  4 17:10:07 2020
From: acdw at acdw.net (acdw)
Date: Wed, 04 Nov 2020 17:10:07 +0000
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <CAObwWNhJ1NN1xJj+VBKs4qBO9ptDRrZrtyAAFun217ysu86Z=w@mail.gmail.com>
References: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
 <14848efc-ab9c-44bf-9ad6-072cef37f27e@posteo.net>
 <CAObwWNhJ1NN1xJj+VBKs4qBO9ptDRrZrtyAAFun217ysu86Z=w@mail.gmail.com>
Message-ID: <cc905d85-4c8a-47f8-85c3-3e141b29e5d8@www.fastmail.com>

On 2020-11-04 (Wednesday) at 01:25, Katarina Eriksson <gmym at coopdot.com> wrote:
> 
> Yes, I agree. There are plenty of other protocols to choose from which 
> are better suited for transferring large files. But that's beside the 
> point.

I'd say that's precisely the point -- Gemini is built for the serving of text files.. It'd be like (pardon the HTTP-only metaphor) if you decided to tweet out the contents of /War and Peace/ -- you could do it, but why would you want to?

> 
> The purpose of this thought experiment is to find a use case where you 
> can't work within the constraints and have to add a content length 
> header.
> 
> My expectation is that there are no such use case, certainly not one 
> worth braking compatibility for, but I'm keeping an open mind.

I agree that there's not enough of a use case for a Content-Length: header -- see above on the purpose of Gemini.  I mean, people can host whatever they'd like (I love the Konpeito mixtapes as much as anyone, for example), but I don't think anyone should *expect* to easily download large files from Gemini capsules.

> 
> New people will join and ask for a content length header again in a few 
> months. It has happened before, more than once, in this very young 
> mailing list. If we would have a supporting specification which deals 
> with this, we would have something to point at.

There was some talke about adding something addressing Content-Length in the FAQ, which I 1000% support.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From cowan at ccil.org  Wed Nov  4 20:00:21 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 4 Nov 2020 15:00:21 -0500
Subject: Licensing content for your capsule
In-Reply-To: <20201104113549.GA9365@localhost.localdomain>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103073334.GA19302@localhost.localdomain>
 <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>
 <20201103224436.GA32224@localhost.localdomain>
 <20201104033745.GA13584@clariel.local>
 <20201104113549.GA9365@localhost.localdomain>
Message-ID: <CAD2gp_QUA1K7OjAS+RN2b5dofW3ErP+fdbcZ-yt_hsyTxpETQA@mail.gmail.com>

On Wed, Nov 4, 2020 at 6:35 AM marc <marcx2 at welz.org.za> wrote:

Also, even though the list of licenses they have collected is
> long, I can't spot (and let me know if otherwise)
> any newer ethical licenses - the ones one
> can find by following links on writing.kemitchell.com


The first sentence on that page says: "The SPDX License List is a list of
commonly found licenses and exceptions used in free and open source and
other collaborative software or documentation."  That excludes licenses
that are not commonly used and those that are not free/open source
licenses.  SPDX looks through various sources to determine what's commonly
used, but probably can't find anything that's not on the Web.  It defers to
the OSI and the FSF to determine what is a free and open source license,
though it does make its own judgments of the form "Oh, this is the same as
the 2-clause BSD" and includes them.



> For instance, one could imagine somebody publishing
> their capsule under a "free but no surveillance, no deduction
> of personal information" license, and if there is a
> gatekeeper who approves an "acceptable" license, then
> this might be harder.


Such a license is neither free nor open source, and as such it is outside
the SPDX remit.  Some CC licenses aren't either, but they are included
because they are commonly used for documentation.

Then there is the (quite) unusual matter of the gemini
> syntax - how to accommodate the "SPDX-License-Identifier"
> token in gemini files.
>

That's why I think it is a good idea to make the copyright notice a link
line, like this:

=> https://spdx.org/licenses/CC0-1.0.html Copyright 2020 by John Cowan
under CC0-1.0



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Using RELAX NG compact syntax to develop schemas is one of the simple
pleasures in life....          --Jeni Tennison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201104/4bd195bb/attachment.htm>

From solderpunk at posteo.net  Wed Nov  4 19:48:26 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Wed, 04 Nov 2020 20:48:26 +0100
Subject: Specs and 0-length <META>
In-Reply-To: <87wnz398m3.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <C6UQMHBRJHU9.1F3X9WV6WI20K@stilgar>

Hi,

Good questions!

The spec says (at the end of Section 3.3) that:

> If <META> is an empty string, the MIME type MUST default to
> "text/gemini; charset=utf-8". The text/gemini media type is defined in
> section 5.

which implies quite clearly that an empty <META> is possible, at least
in the case of a status code of 20.  It's pretty vague, though, about
exactly what this means, and when else it might be allowed.

Since a response header is defined as:

> <STATUS><SPACE><META><CR><LF>

an empty <META> strictly means "20 \r\n", with "20\r\n" being totally
invalid.  This probably was not what I had in mind at the time.

It seems to me that an empty <META> with a status code of 3x must
necessarily be invalid as it makes no sense to redirect to nowhere.

An empty <META> with a status code of 1x could in principle be handled
by using a client-specific default input prompt, but I think it would be
quite poor design to actually return such a response.  Users should
always know what it is they're being asked to input, even if they visit
the URL that leads to the prompt directly, without the context of some
other URL which linked to it.

Simplicity would dictate that either <META> may always be empty or must
never be empty.  There are two good reasons above not to allow <META> to
be empty in some cases, so maximum simplicity argues for it never be
allowed.  We *could* just remove the final paragraph of Section 3.3
which specifies a default media type for successful responses.  Has
anybody written a server which actually makes use of this default?  Does
anybody see a particularly compelling reason to keep it in there?  It
saves only 11 bytes which is trivial compared to TLS overhead and TCP
overhead.

Cheers,
Solderpunk

On Mon Nov 2, 2020 at 2:44 PM CET, Nicol? Balzarotti wrote:
> Hello!
>
> MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed
> length for the <META> field.
>
> MasterQ32: To my understanding, <META> should be non-empty in any case,
> but it may not contain useful information.
>
> ew0k: My interpretation after re-reading the specification is that 1) A
> browser should be able to handle a zero-length meta field, because the
> specification does not un-ambigously state a minimum length - and 2) you
> should post a request for clarification on the mailing list, so that the
> specification is updated to be clear on the topic
>
> me: In section 3.1 there's a maximum length, but not a minimum, and
> under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be
> an empty string.
>
> Can the specs be changed so that it is stated exactly if/when an empty
> <meta> is allowed?
>
>
> Thanks!
> Nicol?


From steve at swinslow.net  Wed Nov  4 22:07:05 2020
From: steve at swinslow.net (Steve Winslow)
Date: Wed, 4 Nov 2020 17:07:05 -0500
Subject: Licensing content for your capsule
In-Reply-To: <CAD2gp_QUA1K7OjAS+RN2b5dofW3ErP+fdbcZ-yt_hsyTxpETQA@mail.gmail.com>
References: <C6SUP6LLZZF5.1E6Y1P6DXPORG@taiga>
 <20201103073334.GA19302@localhost.localdomain>
 <CAD2gp_St1JBeCHczwUpZnNJ=e48U_bq6pkOnug3G1TgkUn9ybA@mail.gmail.com>
 <20201103224436.GA32224@localhost.localdomain>
 <20201104033745.GA13584@clariel.local>
 <20201104113549.GA9365@localhost.localdomain>
 <CAD2gp_QUA1K7OjAS+RN2b5dofW3ErP+fdbcZ-yt_hsyTxpETQA@mail.gmail.com>
Message-ID: <20201104220704.GA28312@clariel.local>

On Wed, Nov 04, 2020 at 03:00:21PM -0500, John Cowan wrote:
> On Wed, Nov 4, 2020 at 6:35 AM marc <marcx2 at welz.org.za> wrote:
> 
> Also, even though the list of licenses they have collected is
> > long, I can't spot (and let me know if otherwise)
> > any newer ethical licenses - the ones one
> > can find by following links on writing.kemitchell.com
> 
> 
> The first sentence on that page says: "The SPDX License List is a list of
> commonly found licenses and exceptions used in free and open source and
> other collaborative software or documentation."  That excludes licenses
> that are not commonly used and those that are not free/open source
> licenses.  SPDX looks through various sources to determine what's commonly
> used, but probably can't find anything that's not on the Web.  It defers to
> the OSI and the FSF to determine what is a free and open source license,
> though it does make its own judgments of the form "Oh, this is the same as
> the 2-clause BSD" and includes them.

Thanks marc, and thanks John for the details. One more point to clarify:

Earlier this year SPDX updated its guidelines to permit the inclusion on the
list of _some_ source-available licenses that don't meet OSI / FSF requirements
for their respective definitions. The guidelines are at [1] if you are
interested.

Under the revised guidelines, a few licenses that have been called "ethical
source" licenses are on the list. For instance, the Hippocratic License 2.1
was added to the list earlier this year. [2] As John noted, the SPDX community
does not aim to establish its own definitions for terms like free or open 
source software, and tries to defer to other groups that are focused on those
topics.

I realize I've taken things far afield from Gemini, so I'll hold off from
further licensing trivia on this list  :)  Happy to chat offline if folks
have questions about any of this.

Steve

[1] https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md
[2] https://spdx.org/licenses/Hippocratic-2.1.html

From cowan at ccil.org  Thu Nov  5 03:36:37 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 4 Nov 2020 22:36:37 -0500
Subject: Plain-text email
In-Reply-To: <QhREEttP8fCFTPlJLxyVj9ZftK01iYtWBtcvRSgA8U@cp7-web-039.plabs.ch>
References: <QhREEttP8fCFTPlJLxyVj9ZftK01iYtWBtcvRSgA8U@cp7-web-039.plabs.ch>
Message-ID: <CAD2gp_QrjWntycVcrA16H_f6z5-Uw9xc+zHWCpu7OvW9oBBK1A@mail.gmail.com>

On Tue, Nov 3, 2020 at 10:31 PM Jordan <jordan at crowesnest.io> wrote:


> Hope all is having a good day/night. I've noticed several emails on the
> mailing lists are using html. Is there prehaps a suggestion in the
> mailing list "rules" for using plain-text, so that everyone may be able
> to read the emails?
>

After almost three decades of preaching and practicing the "plain text
only, no more than 80 columns, no top-posting EVAR" gospel of email, I have
concluded that it is now obsolete.

1) A sender that can *only* send text/html should definitely be off limits
still.  But one that sends the message in both text/html and text/plain (in
a multipart/alternative wrapper) is legitimate.  If the receiver's client
cannot cope with multipart/alternative and pull the text/plain version out
of it, the receiver really does need a new client at this point.  For
example, if I send a Gmail email (which has both formats) to myself at a
different account and read it with Mutt, I see the plain text properly.

2) If the receiver's window to read mail is less than 80
columns,
then the mail will look something like this, which is very
difficult to
read, especially when there is a lot of it.

3) Top-posting is still controversial, but I'll do it if I am making a
completely general and short reply, like "Can you give me more details?"



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
"Hacking is the true football."  --F.W. Campbell (1863) in response to a
successful attempt to ban shin-kicking from soccer.  Today, it's biting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201104/1cdb7dcd/attachment.htm>

From bjorn.warmedal at gmail.com  Thu Nov  5 07:50:00 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 5 Nov 2020 08:50:00 +0100
Subject: Specs and 0-length <META>
In-Reply-To: <C6UQMHBRJHU9.1F3X9WV6WI20K@stilgar>
References: <87wnz398m3.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
 <C6UQMHBRJHU9.1F3X9WV6WI20K@stilgar>
Message-ID: <CAJScK0+yi4Y2Zw37KH4qg3gcof71FfTqu05jQcQZeuw0uHxdCg@mail.gmail.com>

Clarity, simplicity, consistency :)

As you say, there are cases where an empty META makes no sense at all
(redirection). For me that's enough of a reason to say that META must
never be empty, for the three above mentioned reasons :) Your argument
is sound.

Cheers,
ew0k


On Wed, 4 Nov 2020 at 21:41, Solderpunk <solderpunk at posteo.net> wrote:
>
> Hi,
>
> Good questions!
>
> The spec says (at the end of Section 3.3) that:
>
> > If <META> is an empty string, the MIME type MUST default to
> > "text/gemini; charset=utf-8". The text/gemini media type is defined in
> > section 5.
>
> which implies quite clearly that an empty <META> is possible, at least
> in the case of a status code of 20.  It's pretty vague, though, about
> exactly what this means, and when else it might be allowed.
>
> Since a response header is defined as:
>
> > <STATUS><SPACE><META><CR><LF>
>
> an empty <META> strictly means "20 \r\n", with "20\r\n" being totally
> invalid.  This probably was not what I had in mind at the time.
>
> It seems to me that an empty <META> with a status code of 3x must
> necessarily be invalid as it makes no sense to redirect to nowhere.
>
> An empty <META> with a status code of 1x could in principle be handled
> by using a client-specific default input prompt, but I think it would be
> quite poor design to actually return such a response.  Users should
> always know what it is they're being asked to input, even if they visit
> the URL that leads to the prompt directly, without the context of some
> other URL which linked to it.
>
> Simplicity would dictate that either <META> may always be empty or must
> never be empty.  There are two good reasons above not to allow <META> to
> be empty in some cases, so maximum simplicity argues for it never be
> allowed.  We *could* just remove the final paragraph of Section 3.3
> which specifies a default media type for successful responses.  Has
> anybody written a server which actually makes use of this default?  Does
> anybody see a particularly compelling reason to keep it in there?  It
> saves only 11 bytes which is trivial compared to TLS overhead and TCP
> overhead.
>
> Cheers,
> Solderpunk
>
> On Mon Nov 2, 2020 at 2:44 PM CET, Nicol? Balzarotti wrote:
> > Hello!
> >
> > MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed
> > length for the <META> field.
> >
> > MasterQ32: To my understanding, <META> should be non-empty in any case,
> > but it may not contain useful information.
> >
> > ew0k: My interpretation after re-reading the specification is that 1) A
> > browser should be able to handle a zero-length meta field, because the
> > specification does not un-ambigously state a minimum length - and 2) you
> > should post a request for clarification on the mailing list, so that the
> > specification is updated to be clear on the topic
> >
> > me: In section 3.1 there's a maximum length, but not a minimum, and
> > under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be
> > an empty string.
> >
> > Can the specs be changed so that it is stated exactly if/when an empty
> > <meta> is allowed?
> >
> >
> > Thanks!
> > Nicol?
>

From anothersms at gmail.com  Thu Nov  5 08:25:54 2020
From: anothersms at gmail.com (=?utf-8?Q?Nicol=C3=B2?= Balzarotti)
Date: Thu, 05 Nov 2020 09:25:54 +0100
Subject: Specs and 0-length <META>
In-Reply-To: <C6UQMHBRJHU9.1F3X9WV6WI20K@stilgar>
References: <C6UQMHBRJHU9.1F3X9WV6WI20K@stilgar>
Message-ID: <87361o43cd.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>

Hi Solderpunk,

thanks for the reply.  

> It seems to me that an empty <META> with a status code of 3x must
> necessarily be invalid as it makes no sense to redirect to nowhere.
>
I agree on it either be optional or mandatory.  And (unless implying
some default-value like "/", "./" or something) you are right on "3X
\r\n" being meaningless.

In the wild we saw 5X status without meta (example [1]).
I myself when implementing a server after reading the specs decided that
"51 \r\n" was fine (because adding "Resource not found" after 51 seemed
to me like a repetition), but on the other side "20 text/gemini" was
just better than "20 ".

Indeed, removing the paragraph of Section 3.3 would help, but I'd also
replace _may_ (i.e.  The contents of <META> _may_ provide additional
information on the failure) with _should_.

Thanks!
Nicol?

[1] https://github.com/MasterQ32/kristall/issues/43

"Solderpunk" <solderpunk at posteo.net> writes:

> Hi,
>
> Good questions!
>
> The spec says (at the end of Section 3.3) that:
>
>> If <META> is an empty string, the MIME type MUST default to
>> "text/gemini; charset=utf-8". The text/gemini media type is defined in
>> section 5.
>
> which implies quite clearly that an empty <META> is possible, at least
> in the case of a status code of 20.  It's pretty vague, though, about
> exactly what this means, and when else it might be allowed.
>
> Since a response header is defined as:
>
>> <STATUS><SPACE><META><CR><LF>
>
> an empty <META> strictly means "20 \r\n", with "20\r\n" being totally
> invalid.  This probably was not what I had in mind at the time.
>
> It seems to me that an empty <META> with a status code of 3x must
> necessarily be invalid as it makes no sense to redirect to nowhere.
>
> An empty <META> with a status code of 1x could in principle be handled
> by using a client-specific default input prompt, but I think it would be
> quite poor design to actually return such a response.  Users should
> always know what it is they're being asked to input, even if they visit
> the URL that leads to the prompt directly, without the context of some
> other URL which linked to it.
>
> Simplicity would dictate that either <META> may always be empty or must
> never be empty.  There are two good reasons above not to allow <META> to
> be empty in some cases, so maximum simplicity argues for it never be
> allowed.  We *could* just remove the final paragraph of Section 3.3
> which specifies a default media type for successful responses.  Has
> anybody written a server which actually makes use of this default?  Does
> anybody see a particularly compelling reason to keep it in there?  It
> saves only 11 bytes which is trivial compared to TLS overhead and TCP
> overhead.
>
> Cheers,
> Solderpunk
>
> On Mon Nov 2, 2020 at 2:44 PM CET, Nicol? Balzarotti wrote:
>> Hello!
>>
>> MasterQ32, ew0k, jcowan and I were wondering about the _minimum_ allowed
>> length for the <META> field.
>>
>> MasterQ32: To my understanding, <META> should be non-empty in any case,
>> but it may not contain useful information.
>>
>> ew0k: My interpretation after re-reading the specification is that 1) A
>> browser should be able to handle a zero-length meta field, because the
>> specification does not un-ambigously state a minimum length - and 2) you
>> should post a request for clarification on the mailing list, so that the
>> specification is updated to be clear on the topic
>>
>> me: In section 3.1 there's a maximum length, but not a minimum, and
>> under 3.2.4,5,6 there's "may provide", and under 3.3 it says it can be
>> an empty string.
>>
>> Can the specs be changed so that it is stated exactly if/when an empty
>> <meta> is allowed?
>>
>>
>> Thanks!
>> Nicol?

From me at adnano.co  Thu Nov  5 15:05:43 2020
From: me at adnano.co (Adnan Maolood)
Date: Thu, 05 Nov 2020 10:05:43 -0500
Subject: Problems with CRLF
Message-ID: <C6VF8K8M43A0.10XF7N6RP93S1@nitro>

Using CRLF to terminate response headers allows a server to get away
with the following response:

	10 This META is more than one line long\n
	I bet your client can't handle this\n
	The end\r\n

I propose that response headers should be LF-terminated lines.
This would remove this loophole, but should also be a
backwards-compatible change as the last CR could be ignored.

From me at adnano.co  Thu Nov  5 15:25:00 2020
From: me at adnano.co (Adnan Maolood)
Date: Thu, 05 Nov 2020 10:25:00 -0500
Subject: TLS recommendations
Message-ID: <C6VFNBUAWMK9.30SZC4Q9TYXN2@nitro>

I think that the following should be added to the best practices, to aid
newcomers in setting up TLS certificates properly:

- Certificates should use ECDSA, as Ed25519 is not widely supported.
- Certificates should specify both a Common Name and a Subject Alternative
  Name.

From nothien at uber.space  Thu Nov  5 15:23:17 2020
From: nothien at uber.space (Arav K.)
Date: Thu, 05 Nov 2020 16:23:17 +0100
Subject: Problems with CRLF
In-Reply-To: <C6VF8K8M43A0.10XF7N6RP93S1@nitro>
Message-ID: <C6VFM0O7GUEH.W4S92ZG4A6ZE@gux>

On Thu Nov 5, 2020 at 4:05 PM WAT, Adnan Maolood wrote:
> Using CRLF to terminate response headers allows a server to get away
> with the following response:
>
> 10 This META is more than one line long\n
> I bet your client can't handle this\n
> The end\r\n

I will check myself, but I don't think most clients would throw up when
faced with input like this.  I thought it's a common way to present
multi-line input prompts.  If it's not, that's also fine, but I don't
see this being so big of an issue that the spec needs to be changed.

Most 'proper' clients (i.e. not shell scripts) should have absolutely no
problem dealing with this.  Shell scripts will certainly have to be wary
with assuming it's a single line, but even then, no biggie.  Perhaps we
can provide this as a Gemini torture test (if it isn't already one), as
I know many clients do check against that.

~aravk | ~nothien

From me at adnano.co  Thu Nov  5 15:28:23 2020
From: me at adnano.co (Adnan Maolood)
Date: Thu, 05 Nov 2020 10:28:23 -0500
Subject: Problems with CRLF
In-Reply-To: <C6VFM0O7GUEH.W4S92ZG4A6ZE@gux>
Message-ID: <C6VFPX61SGUS.3CC61UQUEB8AK@nitro>

On Thu Nov 5, 2020 at 11:23 AM EST, Arav K. wrote:
> I will check myself, but I don't think most clients would throw up when
> faced with input like this. I thought it's a common way to present
> multi-line input prompts. If it's not, that's also fine, but I don't
> see this being so big of an issue that the spec needs to be changed.
>
> Most 'proper' clients (i.e. not shell scripts) should have absolutely no
> problem dealing with this. Shell scripts will certainly have to be wary
> with assuming it's a single line, but even then, no biggie. Perhaps we
> can provide this as a Gemini torture test (if it isn't already one), as
> I know many clients do check against that.

I was not aware that this was a common thing to do.
If it is, and it is desirable, then I agree that it should be a client
torture test. It could also be mentioned in the specification so that
client authors can be aware.

As a side-note, are clients expected to append a colon to the end of the
input prompt? I have seen some clients do that, and wasn't sure if that
was a standard thing.

From colecmac at protonmail.com  Thu Nov  5 15:40:50 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 05 Nov 2020 15:40:50 +0000
Subject: Problems with CRLF
In-Reply-To: <C6VFPX61SGUS.3CC61UQUEB8AK@nitro>
References: <C6VFPX61SGUS.3CC61UQUEB8AK@nitro>
Message-ID: <639tcyxdRyPXCUxLv8jqbDYDciN_l6XnW5mq56k-Dmk5M0D8X_5y97i12RhrI5VJ8_JJ15yWhsynTg1ZOhvYeuR6L7JproamsWO5QtmWlI8=@protonmail.com>

> As a side-note, are clients expected to append a colon to the end of the
> input prompt? I have seen some clients do that, and wasn't sure if that
> was a standard thing.

Definitely not expected, no. Personally, I don't think it's a good idea,
as input prompts can turn out like this:

What is your name?:

Enter your name::

Secret passcode, please.:


In my opinion it's much better to just make it obvious to the user that
input is being asked for, and let the server send what it chooses.


makeworld

From linde.philip at gmail.com  Thu Nov  5 15:57:45 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Thu, 5 Nov 2020 16:57:45 +0100
Subject: Problems with CRLF
In-Reply-To: <C6VFM0O7GUEH.W4S92ZG4A6ZE@gux>
References: <C6VF8K8M43A0.10XF7N6RP93S1@nitro> <C6VFM0O7GUEH.W4S92ZG4A6ZE@gux>
Message-ID: <20201105165745.169408e29195335ac72312e0@gmail.com>

On Thu, 05 Nov 2020 16:23:17 +0100
"Arav K." <nothien at uber.space> wrote:

> On Thu Nov 5, 2020 at 4:05 PM WAT, Adnan Maolood wrote:
> > Using CRLF to terminate response headers allows a server to get away
> > with the following response:
> >
> > 10 This META is more than one line long\n
> > I bet your client can't handle this\n
> > The end\r\n
> 
> I will check myself, but I don't think most clients would throw up when
> faced with input like this.  I thought it's a common way to present
> multi-line input prompts.  If it's not, that's also fine, but I don't
> see this being so big of an issue that the spec needs to be changed.

If there is some ambiguity, I think it should be addressed. According
to the spec, a response consists of a "single CRLF-terminated header
line". Semantically, "\n" (line feed) feeds a new line. In that sense
a response per that example contains multiple lines of which only one
is "CRLF terminated".

Because the exact definition of a line is not specified, I guess there
*is* some ambiguity. I have however assumed that META won't contain
line feeds and I think other implementers should too because it's
clearly not in the spirit of the spec that a status line should
represent more than a single line.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201105/c0964ca9/attachment.sig>

From colecmac at protonmail.com  Thu Nov  5 16:11:44 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 05 Nov 2020 16:11:44 +0000
Subject: Client certificate expiry dates
Message-ID: <BQjvaaAmVcG7oY1V-Wp5SZtWld6N6yAgLATk3s1S6HhRsF_S3qcK3UO3ExkQzVfjbLFS9rhjDP6rdaK7cbu6K7e49ssfQHTf4O_4O5TXkv0=@protonmail.com>

Hello gemheads,

Amfora recently got some basic client cert support, and it has me
wondering: What to do about expiry dates? Should servers not care
if client certs expire? Should clients and users be generating
certs that last for 100 years? I'm not sure what the best practice
is, but I want to get it right.

It seems to me that while having an expiry date on client certs might
be useful for security, it will become a UX problem a few years down
the line, when apps need to have some way to associate a new cert with
the same previous account.

On the other hand, if a cert gets compromised and never expires, the
server then needs to have some sort of revocation mechanism I guess.

It seems to me the former is a more prominent issue.

makeworld

From cowan at ccil.org  Thu Nov  5 16:53:33 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 5 Nov 2020 11:53:33 -0500
Subject: Client certificate expiry dates
In-Reply-To: <BQjvaaAmVcG7oY1V-Wp5SZtWld6N6yAgLATk3s1S6HhRsF_S3qcK3UO3ExkQzVfjbLFS9rhjDP6rdaK7cbu6K7e49ssfQHTf4O_4O5TXkv0=@protonmail.com>
References: <BQjvaaAmVcG7oY1V-Wp5SZtWld6N6yAgLATk3s1S6HhRsF_S3qcK3UO3ExkQzVfjbLFS9rhjDP6rdaK7cbu6K7e49ssfQHTf4O_4O5TXkv0=@protonmail.com>
Message-ID: <CAD2gp_SZ0YSoj_JuSOWcrjUweitmKX4fXsBrb9hZr-8MSbXeHA@mail.gmail.com>

On Thu, Nov 5, 2020 at 11:12 AM <colecmac at protonmail.com> wrote:

> Hello gemheads,
>
> Amfora recently got some basic client cert support, and it has me
> wondering: What to do about expiry dates? Should servers not care
> if client certs expire? Should clients and users be generating
> certs that last for 100 years?
>

That totally depends on how much the server cares about the client's
identity.

> It seems to me that while having an expiry date on client certs might
> be useful for security, it will become a UX problem a few years down
> the line, when apps need to have some way to associate a new cert with
> the same previous account.
>

A simple approach is to send a SHA256 hash of the new cert out of
band, signed with the old cert.  Certificates are too big for a rainbow
attack, so this is safe against everything but MITM.  (In the end, MITM is
unpreventable: if Alice controls all of Bob's network connections, she can
make him believe anything she wants him to.)

On the other hand, if a cert gets compromised and never expires, the
> server then needs to have some sort of revocation mechanism I guess.
>

There's already a concept of Certificate Revocation Lists in X.509.
Victims post their compromised certs to the list; verifiers make sure the
cert presented is not on the list.  See <
https://searchsecurity.techtarget.com/definition/Certificate-Revocation-List>
for details.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Not to perambulate the corridors during the hours of repose
in the boots of ascension.       --Sign in Austrian ski-resort hotel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201105/0406e33f/attachment-0001.htm>

From gmym at coopdot.com  Thu Nov  5 21:09:54 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Thu, 5 Nov 2020 22:09:54 +0100
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <20201104041502.230484e2@home>
References: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
 <20201104041502.230484e2@home>
Message-ID: <CAObwWNjaa7JzScSmOAy8NG0RZvMHzH9ThM+nUb+VBTQ45v_boQ@mail.gmail.com>

Ali Fardan <raiz at stellarbound.space> wrote:

> > Scenario 3: download a big file
>

[...]

Implementing this would be tricky on the server side, this would add
> unnecessary complexity,


Yes, the server would need to be able to accept and respond to other
connections while the file is transmitted. It also needs either be able to
run CGI scripts or have custom code for that endpoint.

what I would suggest instead if you really insist on using Gemini for large
> file transfers is specifying file size
> in the link label like so:
>
> => gemini://example.tld/large_file.bin Download (140 MB)
>
> and then have the client show how much of the file is downloaded, now
> that you know the file size, and know how much is downloaded, you don't
> need a progress indicator to be implemented within the protocol.  Of
> course this is on the client to implement, but wouldn't be tricky at
> all.
>

Foster an environment where capsule authors are good enough internet
citizens to always provide the file size on the page? Sure, that wouldn't
be tricky at
all.

Corrected:
Scenario 3.1: download a big file and the capsule author neglected to
provide a file size

> Scenario 4: the TLS session terminated cleanly but we don't have full
>
> confidence the download succeed
> >
> > Verify the file using the information we have (from scenario 3) or
> > present the user with the option to fetch a hash from the
> > standardized endpoint.
>
> This does not have to be embedded in the protocol, just do this:
>
> SHA1: ad7ff785f989c9ff9cec92bd3d0bab035a54e997
> SHA256: d2af944fe8b3af5cf5a9d8c3226d06ac6369d036fc591363dedc85344bc4daa7
> => gemini://example.tld/large_file.bin Download (140 MB)
>
> now the user can verify their downloaded file, this is done all the
> time even in HTTP land.
>

I would personally prefer the way we did it with FTP and provide a
large_file.bin.md5sum or now large_file.bin.sha1sum, but I would use
another protocol for large files.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201105/b7853464/attachment.htm>

From raiz at stellarbound.space  Thu Nov  5 22:02:22 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Fri, 6 Nov 2020 01:02:22 +0300
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <CAObwWNjaa7JzScSmOAy8NG0RZvMHzH9ThM+nUb+VBTQ45v_boQ@mail.gmail.com>
References: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
 <20201104041502.230484e2@home>
 <CAObwWNjaa7JzScSmOAy8NG0RZvMHzH9ThM+nUb+VBTQ45v_boQ@mail.gmail.com>
Message-ID: <20201106010222.02819af4@home>

On Thu, 5 Nov 2020 22:09:54 +0100
Katarina Eriksson <gmym at coopdot.com> wrote:
> Yes, the server would need to be able to accept and respond to other
> connections while the file is transmitted. It also needs either be
> able to run CGI scripts or have custom code for that endpoint.

Not only that, but how would a request sent separately tell the server
which connection of its dozen is the one that we want progress on?

That kills a nice feature of the protocol which is being able to serve
connections on a queue instead of forking for each connection because
once a transmission is over, the connection is over too, this
simplifies server code A LOT.

> Foster an environment where capsule authors are good enough internet
> citizens to always provide the file size on the page? Sure, that
> wouldn't be tricky at all.

If that becomes a guideline or an etiquette everyone should follow,
this is not an environment of division, lets take this mailing list as
an example, or for that matter, almost all mailing lists, plaintext
emails are a guideline, its a part of the culture, sending HTML email
can be seen as disrespectful at times, this is a result of social rules
that have evolved over time, I don't see how it would be any different
for Gemini.

Also, if capsule authors insist on serving large content over this
protocol they should make it not so annoying, the protocol should not
accommodate such people by serving them more features, if you want
HTTP, you know where to find it.

> Corrected:
> Scenario 3.1: download a big file and the capsule author neglected to
> provide a file size

Bummer.

> I would personally prefer the way we did it with FTP and provide a
> large_file.bin.md5sum or now large_file.bin.sha1sum

Brilliant, I don't see anything wrong with that.

> but I would use another protocol for large files.

Ok then, there's nothing to discuss further.



From sir at cmpwn.com  Thu Nov  5 22:03:18 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 05 Nov 2020 18:03:18 -0400
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <20201106010222.02819af4@home>
Message-ID: <C6VO4AHMZJE1.150XRCSBL6PE0@cirno>

Weighing in after reading 1/3rd of the discussion and getting somewhat
tired of having it bubble back up to my inbox all the time:

TCP is pretty good. I've been tethered to my phone for a few days, and
I've had my connection drop out for minutes at a time, and my TCP
connections aren't dying.

=> /foo.mp3 foo.mp3 (14 MiB) SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

This is good enough for me. Implement a progress viewer in your client
that shows the total amount downloaded so far and prints out the
checksum at the end and that'll do just fine.

From jordan at crowesnest.io  Thu Nov  5 22:42:20 2020
From: jordan at crowesnest.io (Jordan)
Date: Thu, 05 Nov 2020 22:42:20 +0000
Subject: Gemini file downloading client - a thought experiment
In-Reply-To: <20201106010222.02819af4@home>
References: <CAObwWNiMO-u182iKj1eHznwYYGQNGi-VZi_Nwpt8hWif0DVW5Q@mail.gmail.com>
 <20201104041502.230484e2@home>
 <CAObwWNjaa7JzScSmOAy8NG0RZvMHzH9ThM+nUb+VBTQ45v_boQ@mail.gmail.com>
 <20201106010222.02819af4@home>
Message-ID: <LdSXqzy7VyGK0bYtMXJuH7rDx36ufPjzBlp7u0uNIw@cp4-web-014.plabs.ch>

On Thu Nov 5, 2020 at 5:02 PM EST, Ali Fardan wrote:
>
> > I would personally prefer the way we did it with FTP and provide a
> > large_file.bin.md5sum or now large_file.bin.sha1sum
>
> Brilliant, I don't see anything wrong with that.
>
> > but I would use another protocol for large files.
>
> Ok then, there's nothing to discuss further.

The client displaying and verifying the checksum seems like a way to go
as long as the host provides the checksum. Though, as Ali Fardan (I
think it was this person) stated another protocol would be safer and
easier to download the file.

Jordan


From bie at 202x.moe  Fri Nov  6 05:52:17 2020
From: bie at 202x.moe (bie)
Date: Fri, 6 Nov 2020 14:52:17 +0900
Subject: Caching and status codes
Message-ID: <20201106055217.GA4163@202x.moe>

Hello everyone!

There's been some light discussion on the gemini irc channel about if
and how clients should cache gemini responses, and I'd love to hear how
people here think about the issue...

Personally I feel like caching adds a ton of complexity, so the default
behavior should be not to cache anything. There's no way to know if the
response from a server is the product of a dynamic CGI script or a static
file, and trying to guess at what's what will definitely introduce some
weird behavior. Just to give some examples - on my personal site I have
a script that returns a random jpeg, a guestbook and a simple gemlog,
none of which should be cached!

Now, I don't see the need for caching at all when it comes to
gemini, but if it's something the gemini community wants or needs then
I'd like to suggest a 2x status code that let's a client know that the
response is unlikely to change and thus cacheable. This could even kind
of match how the temporary/permanent redirect status codes are defined:

20 - SUCCESS
21 - "PERMANENT" SUCCESS (Feel free to cache this)

This allows simple clients to keep doing what they're doing now (send a
request, show the response) and allows more complex clients to play
around with caching without breaking compatibility with what we already
have.

Another suggestion made on irc was to do the opposite and create a "do
not cache" 2x status code, but I'm not really sold on that. Caching
introduces a lot of complexity even without a separate status code (how
should query strings be handled, 1x responses, redirects?) and these
issues don't go away if you add a "do not cache" code.

Any thoughts...?

bie

From smallick.dev at gmail.com  Fri Nov  6 07:27:11 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Fri, 6 Nov 2020 12:57:11 +0530
Subject: Caching and status codes
In-Reply-To: <20201106055217.GA4163@202x.moe>
References: <20201106055217.GA4163@202x.moe>
Message-ID: <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>

Instead of "permanent" caching (what is permanent?) I am thinking
about using timestamps.

So, for a requested resource, (if it is available) return a timestamp
which denotes when the resource was last changed.

When requesting the resource again, send that timestamp with it and
the server checks if the cache is stale or not and responds
accordingly (either "resource is modified after $(old_timestamp) so
here is the new resource and it was modified on $(new_timestamp)" or
"the resource was not changed after $(timestamp)").

But the problem is, where does the timestamp goes in the request and response?


~smlckz

From bjorn.warmedal at gmail.com  Fri Nov  6 07:43:39 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Fri, 6 Nov 2020 08:43:39 +0100
Subject: Caching and status codes
In-Reply-To: <20201106055217.GA4163@202x.moe>
References: <20201106055217.GA4163@202x.moe>
Message-ID: <CAJScK0+tVmGf0yPRiQxj4pSMp0utk8QrHwQgTaB4t3wH-Qfj3Q@mail.gmail.com>

I *love* it when clients cache stuff, for performance and environmental reasons.

But I think that's something that each individual client (or client
dev, I suppose) should deal with in their own fashion and only if they
want to. As mentioned before most files served on gemini:// are small
text files, and it's likely to remain that way for the foreseeable
future. I don't think caching is something that the protocol should
care about or cater to specifically, as it adds complexity and
ambiguity.

> Now, I don't see the need for caching at all when it comes to
> gemini, but if it's something the gemini community wants or needs then
> I'd like to suggest a 2x status code that let's a client know that the
> response is unlikely to change and thus cacheable. This could even kind
> of match how the temporary/permanent redirect status codes are defined:
>
> 20 - SUCCESS
> 21 - "PERMANENT" SUCCESS (Feel free to cache this)

Adding a response code like that is counterproductive, I believe, as
there's really no way for a server to determine what sort of file or
data is unlikely to change, and there's no way for a client to
determine what a flag of "unlikely to change" means. Does it mean it
won't change in the next hour? The next month?

As mentioned in previous discussions on caching and checksums, there's
not really room in the protocol specification for the needed
information unless you start misusing MIME type info. I've come around
to thinking that the added complexity, ambiguity, and possibly
breaking changes far outweigh the added benefit.

On a side note I am (somewhat slowly) playing around with
python3/Tkinter to make a client, and my current thinking for the
design of that is that when the user clicks a link that returns an
image I'll display it inline and cache it (based on its path)
*forever*, though it will be clearly marked as a cached resource in
the UI somehow as of yet undetermined. As for text/gemini I don't see
a reason to cache them for more than very short periods: they're too
small and frequently changed. No changes are needed in the protocol
for this sort of behaviour, and I'm not really convinced it's a
behaviour most clients should adopt either. Client-side caching is
something that users have strong opinions about.

The only real benefit of caching would be on the server side; whether
it's in a proxying situation or some type of mirror, or just a server
that wants to be speedier when serving dynamic data. I don't see a
need for a protocol change for that, though; if someone wants to make
a super fancy app server they're free to do it as long as it looks the
same to clients :)

Cheers,
ew0k

From bie at 202x.moe  Fri Nov  6 07:44:00 2020
From: bie at 202x.moe (bie)
Date: Fri, 6 Nov 2020 16:44:00 +0900
Subject: Caching and status codes
In-Reply-To: <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
References: <20201106055217.GA4163@202x.moe>
 <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
Message-ID: <20201106074400.GA20117@202x.moe>

For me personally, that brings the protocol a bit too close to the
complexity of HTTP, but I'd be curious to hear what the use-cases for
something like that would be...?

When I used the word "permanent" it was just to draw a comparison to the
31 status code (REDIRECT - PERMANENT). The idea is just to let the
client know that if it wants to cache the response for a session or
however long it wants to... it's unlikely to cause any issues.

bie

On Fri, Nov 06, 2020 at 12:57:11PM +0530, Sudipto Mallick wrote:
> Instead of "permanent" caching (what is permanent?) I am thinking
> about using timestamps.
> 
> So, for a requested resource, (if it is available) return a timestamp
> which denotes when the resource was last changed.
> 
> When requesting the resource again, send that timestamp with it and
> the server checks if the cache is stale or not and responds
> accordingly (either "resource is modified after $(old_timestamp) so
> here is the new resource and it was modified on $(new_timestamp)" or
> "the resource was not changed after $(timestamp)").
> 
> But the problem is, where does the timestamp goes in the request and response?
> 
> 
> ~smlckz


From bie at 202x.moe  Fri Nov  6 08:10:14 2020
From: bie at 202x.moe (bie)
Date: Fri, 6 Nov 2020 17:10:14 +0900
Subject: Caching and status codes
In-Reply-To: <CAJScK0+tVmGf0yPRiQxj4pSMp0utk8QrHwQgTaB4t3wH-Qfj3Q@mail.gmail.com>
References: <20201106055217.GA4163@202x.moe>
 <CAJScK0+tVmGf0yPRiQxj4pSMp0utk8QrHwQgTaB4t3wH-Qfj3Q@mail.gmail.com>
Message-ID: <20201106081014.GA43030@202x.moe>

> Adding a response code like that is counterproductive, I believe, as
> there's really no way for a server to determine what sort of file or
> data is unlikely to change, and there's no way for a client to
> determine what a flag of "unlikely to change" means. Does it mean it
> won't change in the next hour? The next month?

If there's no way for a server to determine what's unlikely to change
then it's *definitely* no way for a client to know, in which case
caching the response is just plain bad-mannered.

> On a side note I am (somewhat slowly) playing around with
> python3/Tkinter to make a client, and my current thinking for the
> design of that is that when the user clicks a link that returns an
> image I'll display it inline and cache it (based on its path)
> *forever*, though it will be clearly marked as a cached resource in
> the UI somehow as of yet undetermined. As for text/gemini I don't see
> a reason to cache them for more than very short periods: they're too
> small and frequently changed. No changes are needed in the protocol
> for this sort of behaviour, and I'm not really convinced it's a
> behaviour most clients should adopt either. Client-side caching is
> something that users have strong opinions about.

I definitely have strong opinions about this, yeah - this would, like I
mentioned earlier, mean that my script returning a random photo wouldn't
work in your client, and that a lot of the tools and toys I was hoping to use
the gemini protocol for are probably suited for something else,
at least if the consensus among the gemini community is that arbitrary
caching is fine.

??
bie

From bjorn.warmedal at gmail.com  Fri Nov  6 09:01:55 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Fri, 6 Nov 2020 10:01:55 +0100
Subject: Caching and status codes
In-Reply-To: <20201106081014.GA43030@202x.moe>
References: <20201106055217.GA4163@202x.moe>
 <CAJScK0+tVmGf0yPRiQxj4pSMp0utk8QrHwQgTaB4t3wH-Qfj3Q@mail.gmail.com>
 <20201106081014.GA43030@202x.moe>
Message-ID: <CAJScK0+Wx05cXVw6KYj2EvLdYjtgqQkWrNEqpQe=trnYNr_JcA@mail.gmail.com>

> I definitely have strong opinions about this, yeah - this would, like I
> mentioned earlier, mean that my script returning a random photo wouldn't
> work in your client, and that a lot of the tools and toys I was hoping to use
> the gemini protocol for are probably suited for something else,
> at least if the consensus among the gemini community is that arbitrary
> caching is fine.

I wouldn't worry about that if I were you -- I'm pretty sure I'm the
only one on the planet dumb enough to cache like this :D There's a
fair chance I'll change that stance when my browser is ready enough to
be tested.

From linde.philip at gmail.com  Fri Nov  6 10:11:04 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 6 Nov 2020 11:11:04 +0100
Subject: Caching and status codes
In-Reply-To: <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
References: <20201106055217.GA4163@202x.moe>
 <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
Message-ID: <20201106111104.a2110d1019b2c1f216bf692e@gmail.com>

On Fri, 6 Nov 2020 12:57:11 +0530
Sudipto Mallick <smallick.dev at gmail.com> wrote:

> But the problem is, where does the timestamp goes in the request and response?

I think that's the advantage of bie's suggested solution. It doesn't
require any breaking changes, and a client that doesn't recognize the
difference between codes 20 and 21 will still be fully compatible with
a server that does.

There can be different codes roughly representing different cache
lifetimes. "PERMANENT" for things that should stick on the disk until
the user (or user configured policy) removes them. "SESSION" for things
that stick for the lifetime of a browsing session.

A HTTP HEAD Last-Modified like solution also provides little advantage
for the smaller documents people typically serve on Gemini. A lot of
overhead exists in TLS negotiation, so one request is almost certainly
better than two for small blog posts or articles.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/c4531315/attachment.sig>

From linde.philip at gmail.com  Fri Nov  6 10:24:00 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 6 Nov 2020 11:24:00 +0100
Subject: Caching and status codes
In-Reply-To: <CAJScK0+tVmGf0yPRiQxj4pSMp0utk8QrHwQgTaB4t3wH-Qfj3Q@mail.gmail.com>
References: <20201106055217.GA4163@202x.moe>
 <CAJScK0+tVmGf0yPRiQxj4pSMp0utk8QrHwQgTaB4t3wH-Qfj3Q@mail.gmail.com>
Message-ID: <20201106112400.e72a557abc2de8d83fce0424@gmail.com>

On Fri, 6 Nov 2020 08:43:39 +0100
Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:

> Adding a response code like that is counterproductive, I believe, as
> there's really no way for a server to determine what sort of file or
> data is unlikely to change, and there's no way for a client to
> determine what a flag of "unlikely to change" means. Does it mean it
> won't change in the next hour? The next month?

Why does the server need to determine this? It should be up to the
server admin to determine it. If I have some file I want to serve that
I anticipate will never change, I configure the server to respond to
reqeusts for it with code 21. The client can take this to mean a week,
a day or forever depending on how sure the user wants to be that the
information is current. The client could override this behavior by
allowing the user to force a cache entry to be purged.

> As mentioned in previous discussions on caching and checksums, there's
> not really room in the protocol specification for the needed
> information unless you start misusing MIME type info.

This doesn't at all address the suggested solution, which there *is*
room for in the protocol. No need to misuse MIME type info. No need for
breaking changes to the specification. As suggested, this is entirely
backwards-compatible, older clients and servers are entirely
forwards-compatible and the change to the spec would be entirely
additive.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/dab57087/attachment.sig>

From linde.philip at gmail.com  Fri Nov  6 10:41:41 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 6 Nov 2020 11:41:41 +0100
Subject: Caching and status codes
In-Reply-To: <20201106055217.GA4163@202x.moe>
References: <20201106055217.GA4163@202x.moe>
Message-ID: <20201106114141.ca8321368a69b40160c4b477@gmail.com>

On Fri, 6 Nov 2020 14:52:17 +0900
bie <bie at 202x.moe> wrote:

> Another suggestion made on irc was to do the opposite and create a "do
> not cache" 2x status code, but I'm not really sold on that. Caching
> introduces a lot of complexity even without a separate status code (how
> should query strings be handled, 1x responses, redirects?) and these
> issues don't go away if you add a "do not cache" code.
> 
> Any thoughts...?

My own (end-user facing) client is a browser plugin and I inherit the
caching policy from it. Practically, this means for me that everything
is cached throughout the browsing session. An entry can be purged from
the cache by a "force reload" that the user can issue. I find this to
be a good all round policy for documents. For CGI I usually have to
issue a force reload. There could be three 2x codes:

20 (unspecified caching; unchanged from current spec)
21 ("permanent" caching)
22 (no caching)

A server that knows 21 and 22 can use them as appropriate on documents
that will never change and will always change respectively. A client
that doesn't understand them will still behave well because 2x is still
2x.

Then there's the question of whether this is something I've missed as a
user and implementer. Not really? I suppose being able to specify "no
caching" in particular is useful for CGI, but I spend most of my time
on Gemini reading documents that rarely change.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/87229e49/attachment.sig>

From trevor at rocketnine.space  Thu Nov  5 20:08:34 2020
From: trevor at rocketnine.space (trevor at rocketnine.space)
Date: Thu, 05 Nov 2020 20:08:34 +0000
Subject: [ANN] twins, a Gemini server written in Go
Message-ID: <1c220a89213393c9fa02dd2c1b5a245e@rocketnine.space>

twins, a Gemini server written in Go, is now available.

Features:
- Serve static files
  - List directories (when enabled)
- Reverse proxy requests
  - TCP
  - FastCGI
- Serve system command output
- Reload configuration on SIGHUP

twins makes it easy to host a Gemini site. Domains, paths and resources are
specified via YAML. Dynamic sites powered by PHP, Python, etc. may be hosted
using FastCGI.

twins includes the response body size in the media type header by default. This
enables user experience improvements in Gemini clients, such as indicating
download progress. It is possible to disable this feature.

Website: gemini://twins.rocketnine.space
Repository: https://gitlab.com/tslocum/twins

From garritfranke at gmail.com  Fri Nov  6 09:21:43 2020
From: garritfranke at gmail.com (Garrit Franke)
Date: Fri, 6 Nov 2020 10:21:43 +0100
Subject: Default document for root
Message-ID: <CAD16O86JCuyH_t0+M4NCqH0X4zKDEvctUgULg2jnmfzdwiS9DQ@mail.gmail.com>

Hi,

I'm currently in the midst of writing a gemini server, and stumbled
upon presumably undefined behavior in the specification: What file
should be served when requesting "/", or any directory?

I tried it out on several servers using index.gmi, and sure enough
this seems to be the accepted case. However, this is not part of the
specification. Maybe I overlooked something, or this is intentional?
Otherwise, it would be nice to have a small hint to this in the spec.

Thanks for making gemini great!

Regards
Garrit

From linde.philip at gmail.com  Fri Nov  6 12:41:27 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 6 Nov 2020 13:41:27 +0100
Subject: Default document for root
In-Reply-To: <CAD16O86JCuyH_t0+M4NCqH0X4zKDEvctUgULg2jnmfzdwiS9DQ@mail.gmail.com>
References: <CAD16O86JCuyH_t0+M4NCqH0X4zKDEvctUgULg2jnmfzdwiS9DQ@mail.gmail.com>
Message-ID: <20201106134127.ab59d087698a5508a6a36627@gmail.com>

On Fri, 6 Nov 2020 10:21:43 +0100
Garrit Franke <garritfranke at gmail.com> wrote:

> I'm currently in the midst of writing a gemini server, and stumbled
> upon presumably undefined behavior in the specification: What file
> should be served when requesting "/", or any directory?

Hi Garrit,

This is an implementation detail that the protocol specification should
not be concerned with; which file exactly you choose to serve for any
given path (if a file at all) has no bearing on the implementation of
the protocol.

It is however somewhat touched on in the best practices document, at
least if you consider "/" a directory:
gemini://gemini.circumlunar.space/docs/best-practices.gmi

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/7c12d235/attachment.sig>

From jmcbray at carcosa.net  Fri Nov  6 13:27:02 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 06 Nov 2020 08:27:02 -0500
Subject: Default document for root
In-Reply-To: <CAD16O86JCuyH_t0+M4NCqH0X4zKDEvctUgULg2jnmfzdwiS9DQ@mail.gmail.com>
 (Garrit Franke's message of "Fri, 6 Nov 2020 10:21:43 +0100")
References: <CAD16O86JCuyH_t0+M4NCqH0X4zKDEvctUgULg2jnmfzdwiS9DQ@mail.gmail.com>
Message-ID: <87361mmx95.fsf@cassilda.carcosa.net>

Garrit Franke <garritfranke at gmail.com> writes:

> I tried it out on several servers using index.gmi, and sure enough
> this seems to be the accepted case. However, this is not part of the
> specification. Maybe I overlooked something, or this is intentional?
> Otherwise, it would be nice to have a small hint to this in the spec.

This is server-defined behavior ? how a server maps URLs to files, and
how a server determines the MIME-type of a file, etc. are all up to the
server author. This is the same as with http, actually; it's just that
the conventions for http servers have been established for so long that
we forget they're not part of the standard.

Anyway, the convention for a directory appears to be: serve either
index.gmi or index.gemini if they exist; serve a directory listing if
they don't. But it's perfectly reasonable for a server to not do this,
or make it configurable behavior, etc.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From mbays at sdf.org  Fri Nov  6 15:24:20 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Fri, 6 Nov 2020 16:24:20 +0100
Subject: Caching and status codes
In-Reply-To: <20201106055217.GA4163@202x.moe>
References: <20201106055217.GA4163@202x.moe>
Message-ID: <20201106152420.qww6mppzv3mtz6uy@localhost>

* Friday, 2020-11-06 at 14:52 +0900 - bie <bie at 202x.moe>:

>There's been some light discussion on the gemini irc channel about if
>and how clients should cache gemini responses, and I'd love to hear how
>people here think about the issue...

Since gemini requests have no guarantee of idempotency, I think it's 
crucial that the user always knows whether an action will cause 
a request or not. That means simple consistent rules on whether to 
retrieve from cache or make a request, that don't depend on subtleties 
like the current time or RAM availability. One simple way to achieve 
this is to always make a fresh request *except* when navigating history 
("back" or "forward"). You could also interpret navigating to an url 
which is in (linear) history as navigation of history, so load from 
cache (in theory this does require unbounded memory use to store the 
urls of an unboundedly long history list, but in practice this is 
unlikely to be more than a few KB). If the page you want to load from 
cache has been deleted due to memory constraints, I'd say you should 
present an error and offer to let the user make the request again, 
rather than doing it automatically. But if all but the tail is 
text/gemini, probably you can afford to store everything anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/378c00b5/attachment.sig>

From sean at conman.org  Fri Nov  6 20:13:14 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 6 Nov 2020 15:13:14 -0500
Subject: Default document for root
In-Reply-To: <CAD16O86JCuyH_t0+M4NCqH0X4zKDEvctUgULg2jnmfzdwiS9DQ@mail.gmail.com>
References: <CAD16O86JCuyH_t0+M4NCqH0X4zKDEvctUgULg2jnmfzdwiS9DQ@mail.gmail.com>
Message-ID: <20201106201314.GZ30302@brevard.conman.org>

It was thus said that the Great Garrit Franke once stated:
> Hi,
> 
> I'm currently in the midst of writing a gemini server, and stumbled
> upon presumably undefined behavior in the specification: What file
> should be served when requesting "/", or any directory?
> 
> I tried it out on several servers using index.gmi, and sure enough
> this seems to be the accepted case. However, this is not part of the
> specification. Maybe I overlooked something, or this is intentional?
> Otherwise, it would be nice to have a small hint to this in the spec.

  As others have mentioned, it's a server implementation detail.  The two
popular conventions are:

	index.gemini
	index.gmi

  I know for my own server, GLV-1.12556, you can configure the basename
('index') and extension ('.gemini') to be anything you want.  So if I wanted
to, I could change the default of 'index.gemini' to 'guide.html'.

  -spc


From cowan at ccil.org  Fri Nov  6 22:19:18 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 6 Nov 2020 17:19:18 -0500
Subject: Caching and status codes
In-Reply-To: <20201106111104.a2110d1019b2c1f216bf692e@gmail.com>
References: <20201106055217.GA4163@202x.moe>
 <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
 <20201106111104.a2110d1019b2c1f216bf692e@gmail.com>
Message-ID: <CAD2gp_QOae7p6VrdAn7OYJwukvhjESsx2aDYX04-Z7Uws8YNeg@mail.gmail.com>

On Fri, Nov 6, 2020 at 5:11 AM Philip Linde <linde.philip at gmail.com> wrote:


> I think that's the advantage of bie's suggested solution. It doesn't
> require any breaking changes, and a client that doesn't recognize the
> difference between codes 20 and 21 will still be fully compatible with
> a server that does.
>

I agree, except that I am in favor of code 22 meaning "It is inadvisable to
cache this", on the assumption that most Gemini documents are static and
will continue to be so.  Even on the Web, most documents are static.  If
there is to be just one new code, better it should be 22.  If people feel
strongly about 21, then both 21 and 22.


> There can be different codes roughly representing different cache
> lifetimes. "PERMANENT" for things that should stick on the disk until
> the user (or user configured policy) removes them. "SESSION" for things
> that stick for the lifetime of a browsing session.
>

That seems to me too complex for a client to interpret.  What is a browsing
session, if I always keep my client running?  Note that "don't cache" can
also be interpreted as "don't mirror", which is often an important point
when dealing with living documents.  There are an awful lot of broken
mirrors of Wikipedia out there.




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
But that, he realized, was a foolish thought; as no one knew better than
he that the Wall had no other side.
        --Arthur C. Clarke, "The Wall of Darkness"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/4b5c5ae5/attachment-0001.htm>

From cel at celehner.com  Sat Nov  7 00:00:51 2020
From: cel at celehner.com (Charles E. Lehner)
Date: Fri, 6 Nov 2020 19:00:51 -0500
Subject: [ANN] Gemini feed expanding proxy
Message-ID: <20201106190051.50396069@celehner.com>

Dear List,

I present a Gemini-HTTP proxy that performs expansion of Atom/RSS feeds.

Proxying feeds is useful for feed readers that only support HTTP(S).

Feed expansion means taking feeds whose entries contain only titles/summaries, and fetching and inserting the full page content for each entry. This allows one to read the full content in one's feed reader. It is useful for offline browsing and other purposes.

The proxy caches fetched page contents for entries and only re-fetches them when the entry's updated/lastPubDate property changes.

This implementation is in PHP and uses streaming XML parsing.

Source and more info:
=> gemini://celehner.com/proxy/

Regards,
Charles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/a7349159/attachment.sig>

From gustavo at gsthnz.com  Sat Nov  7 00:15:03 2020
From: gustavo at gsthnz.com (Gustavo Heinz)
Date: Fri, 6 Nov 2020 21:15:03 -0300
Subject: [ANN] Announcing cyberpunksin.space
Message-ID: <4c15926a-df4c-ec4f-a7b0-0a35d86f464d@gsthnz.com>

Hi guys,

I've started working on cyberpunksin.space, a project to explore and 
document cyberpunk media and culture in gemini.

There's only a intro page at the moment, but I should be adding some 
content soon! I also plan on creating a space for people to host 
personal gemlogs on it :)

Lot's of work to be done!

Enjoy,

--
Gustavo Heinz

From cowan at ccil.org  Sat Nov  7 00:28:16 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 6 Nov 2020 19:28:16 -0500
Subject: libmagic
Message-ID: <CAD2gp_T43c1Jyay=Nm9zMfbbdRQgBpXeXwUY0HvGYQMMi07KNA@mail.gmail.com>

This post is to suggest that servers currently using file extensions to
determine MIME-types switch to libmagic.  This C library analyzes the
content of a file (by name, by file descriptor, or by looking at a buffer
containing the content) and can provide a MIME-type and an encoding.  This
library is behind the `file` command on Linux, FreeBSD, and NetBSD (but not
OpenBSD), and there are interfaces for at least Python, Rust, and Go, plus
a version for Windows.  If you are testing (or serving!) on a Mac, use
Homebrew or Guix.  Googling for "libmagic" and some keyword will probably
find more.

Obviously, using libmagic is slower than just comparing a file extension to
a list of known extensions.  But Gemini servers are not, in general,
high-volume, and it has the advantage of being maintained by an outside
group that is quite good about accepting information about new file
formats.  This means that Gemini servers can serve content in most formats
without a problem.

Unfortunately, at the moment `file --mime`  will report either "text/plain;
charset=utf-8" or "text/plain; charset=us-ascii" instead of text/gemini.
So an interesting question is: how can a text/gemini file best be
identified by its content? It doesn't have to be infallible, because it can
be backed up by checking the extension.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING.  Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/a3ebaca9/attachment.htm>

From sean at conman.org  Sat Nov  7 01:08:31 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 6 Nov 2020 20:08:31 -0500
Subject: libmagic
In-Reply-To: <CAD2gp_T43c1Jyay=Nm9zMfbbdRQgBpXeXwUY0HvGYQMMi07KNA@mail.gmail.com>
References: <CAD2gp_T43c1Jyay=Nm9zMfbbdRQgBpXeXwUY0HvGYQMMi07KNA@mail.gmail.com>
Message-ID: <20201107010831.GA30302@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> This post is to suggest that servers currently using file extensions to
> determine MIME-types switch to libmagic.  

  The first Gemini server, GLV-1.12556, uses libmagic, and always has.  I
consider that an implementation detail.

> Unfortunately, at the moment `file --mime`  will report either "text/plain;
> charset=utf-8" or "text/plain; charset=us-ascii" instead of text/gemini.
> So an interesting question is: how can a text/gemini file best be
> identified by its content? It doesn't have to be infallible, because it can
> be backed up by checking the extension.

  GLV-1.12556 allows one to specify MIME type by extension; if no such
information is available, it will then fall back to libmagic for the MIME
type.  You can also spcify such an extension mapping for the entire server,
per host, per directory or per file [1].

  -spc (You can check the sample-conf.lua file for more information [2])
  
[1]	It also cascades---the various levels are merged at configuration
	file to avoid processing overhead during normal operations.

[2]	https://github.com/spc476/GLV-1.12556

From cowan at ccil.org  Sat Nov  7 01:21:50 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 6 Nov 2020 20:21:50 -0500
Subject: libmagic
In-Reply-To: <20201107010831.GA30302@brevard.conman.org>
References: <CAD2gp_T43c1Jyay=Nm9zMfbbdRQgBpXeXwUY0HvGYQMMi07KNA@mail.gmail.com>
 <20201107010831.GA30302@brevard.conman.org>
Message-ID: <CAD2gp_QGGh5-_2BNBgW5OWMUL5Uu0Qw82EdW3-W3vbQX4k3HrQ@mail.gmail.com>

On Fri, Nov 6, 2020 at 8:08 PM Sean Conner <sean at conman.org> wrote:


>   The first Gemini server, GLV-1.12556, uses libmagic, and always has.  I
> consider that an implementation detail.
>

Absolutely.  But lots of people don't know about libmagic, and it is not
mentioned in the Best Practices document, whereas extension processing *is*
mentioned.  This is an environment where we will probably continue to have
lots of servers.
Any ideas for identifying text/gemini by regex?



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
We pledge allegiance to the penguin and to the intellectual property
regime for which he stands, one world under Linux, with free music
and open source software for all.  --Julian Dibbell on Brazil, edited
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/ea6e05f8/attachment.htm>

From bie at 202x.moe  Sat Nov  7 03:48:00 2020
From: bie at 202x.moe (bie)
Date: Sat, 7 Nov 2020 12:48:00 +0900
Subject: Caching and status codes
In-Reply-To: <CAD2gp_QOae7p6VrdAn7OYJwukvhjESsx2aDYX04-Z7Uws8YNeg@mail.gmail.com>
References: <20201106055217.GA4163@202x.moe>
 <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
 <20201106111104.a2110d1019b2c1f216bf692e@gmail.com>
 <CAD2gp_QOae7p6VrdAn7OYJwukvhjESsx2aDYX04-Z7Uws8YNeg@mail.gmail.com>
Message-ID: <20201107034800.GA66299@202x.moe>

On Fri, Nov 06, 2020 at 05:19:18PM -0500, John Cowan wrote:
> On Fri, Nov 6, 2020 at 5:11 AM Philip Linde <linde.philip at gmail.com> wrote:
> 
> 
> > I think that's the advantage of bie's suggested solution. It doesn't
> > require any breaking changes, and a client that doesn't recognize the
> > difference between codes 20 and 21 will still be fully compatible with
> > a server that does.
> >
> 
> I agree, except that I am in favor of code 22 meaning "It is inadvisable to
> cache this", on the assumption that most Gemini documents are static and
> will continue to be so.  Even on the Web, most documents are static.  If
> there is to be just one new code, better it should be 22.  If people feel
> strongly about 21, then both 21 and 22.
> 

This reduces gemini to a simple file sharing protocol and basically says
that dynamic content is out (unless only targeting advanced clients).

Ultimately, I like the gemini protocol just the way it is (and wouldn't
be opposed to even a 1000 year feature freeze) but arbitrary caching by
clients kills a whole host of use-cases around generated and dynamic
responses.

bie

From cowan at ccil.org  Sat Nov  7 03:55:50 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 6 Nov 2020 22:55:50 -0500
Subject: Caching and status codes
In-Reply-To: <20201107034800.GA66299@202x.moe>
References: <20201106055217.GA4163@202x.moe>
 <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
 <20201106111104.a2110d1019b2c1f216bf692e@gmail.com>
 <CAD2gp_QOae7p6VrdAn7OYJwukvhjESsx2aDYX04-Z7Uws8YNeg@mail.gmail.com>
 <20201107034800.GA66299@202x.moe>
Message-ID: <CAD2gp_S4zU5=3XHgo8k=MtueN=Qm=mjdPFasNOyiiLERCymkUw@mail.gmail.com>

On Fri, Nov 6, 2020 at 10:48 PM bie <bie at 202x.moe> wrote:


> This reduces gemini to a simple file sharing protocol and basically says
> that dynamic content is out (unless only targeting advanced clients).
>

Here are my assumptions.

1) Clients are going to cache, like it or not.  Some already do.

2) Servers are in the best position to say whether content is dynamic or
not. "Dynamic" in this case is not just CGI-generated; it's also static
files that change often.  (I post a static file on the Web that is
recomputed every ten minutes by a cron job.)

3) If the server can communicate "don't cache this", the client can provide
a better UX.

Ultimately, I like the gemini protocol just the way it is (and wouldn'
> be opposed to even a 1000 year feature freeze) but arbitrary caching by
> clients kills a whole host of use-cases around generated and dynamic
> responses.
>

That horse has sailed and that ship is out of the barn.  "The world will go
as it will, and not as you or I would have it."


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
weirdo:    When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/b73ad739/attachment-0001.htm>

From sean at conman.org  Sat Nov  7 04:04:03 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 6 Nov 2020 23:04:03 -0500
Subject: libmagic
In-Reply-To: <CAD2gp_QGGh5-_2BNBgW5OWMUL5Uu0Qw82EdW3-W3vbQX4k3HrQ@mail.gmail.com>
References: <CAD2gp_T43c1Jyay=Nm9zMfbbdRQgBpXeXwUY0HvGYQMMi07KNA@mail.gmail.com>
 <20201107010831.GA30302@brevard.conman.org>
 <CAD2gp_QGGh5-_2BNBgW5OWMUL5Uu0Qw82EdW3-W3vbQX4k3HrQ@mail.gmail.com>
Message-ID: <20201107040403.GC30302@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> On Fri, Nov 6, 2020 at 8:08 PM Sean Conner <sean at conman.org> wrote:
> 
> 
> >   The first Gemini server, GLV-1.12556, uses libmagic, and always has.  I
> > consider that an implementation detail.
> >
> 
> Absolutely.  But lots of people don't know about libmagic, and it is not
> mentioned in the Best Practices document, whereas extension processing *is*
> mentioned.  This is an environment where we will probably continue to have
> lots of servers.
> Any ideas for identifying text/gemini by regex?

  /^\=\>/ anywhere in the file?

  -spc


From colecmac at protonmail.com  Sat Nov  7 04:15:27 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 07 Nov 2020 04:15:27 +0000
Subject: [ANN] twins, a Gemini server written in Go
In-Reply-To: <1c220a89213393c9fa02dd2c1b5a245e@rocketnine.space>
References: <1c220a89213393c9fa02dd2c1b5a245e@rocketnine.space>
Message-ID: <r-YXIDM_iC27leRmYytmmgNb7iGcgu_T23MITK1oiNGeN94X1W42gWepk4pcUt97w610uumNBG7YR3JW23TfX35Xbhpq2uu6v2Ee0w8mvvY=@protonmail.com>


>     twins includes the response body size in the media type header by default. This
>     enables user experience improvements in Gemini clients, such as indicating
>     download progress. It is possible to disable this feature.

For anyone wondering what that looks like:

? gemget --header -o- gemini://twins.rocketnine.space/
Info: Started gemini://twins.rocketnine.space/
Header: 20 text/gemini; charset=utf-8; size=1128


It looks like a nice server, but to be honest I would remove this.
Serving non-standards is not what Gemini is about imo, and it's how
the Web became what it is today. And clients in general should be
strict and not accept things out-of-spec. For example Amfora won't
allow non-standard status codes, even if the first digit matches a
known code. It doesn't check for non-standard MIME params, but maybe
it should?

Anyway, thanks for sharing. How was the experience of the server
development?


makeworld



From bie at 202x.moe  Sat Nov  7 04:32:56 2020
From: bie at 202x.moe (bie)
Date: Sat, 7 Nov 2020 13:32:56 +0900
Subject: Caching and status codes
In-Reply-To: <CAD2gp_S4zU5=3XHgo8k=MtueN=Qm=mjdPFasNOyiiLERCymkUw@mail.gmail.com>
References: <20201106055217.GA4163@202x.moe>
 <CAFaUHv+ZDrM76s1hBQbNvSohWbpmJ3h52weLtWnfgRA_bbm0_w@mail.gmail.com>
 <20201106111104.a2110d1019b2c1f216bf692e@gmail.com>
 <CAD2gp_QOae7p6VrdAn7OYJwukvhjESsx2aDYX04-Z7Uws8YNeg@mail.gmail.com>
 <20201107034800.GA66299@202x.moe>
 <CAD2gp_S4zU5=3XHgo8k=MtueN=Qm=mjdPFasNOyiiLERCymkUw@mail.gmail.com>
Message-ID: <20201107043256.GA38951@202x.moe>

On Fri, Nov 06, 2020 at 10:55:50PM -0500, John Cowan wrote:
> On Fri, Nov 6, 2020 at 10:48 PM bie <bie at 202x.moe> wrote:
> 
> 
> > This reduces gemini to a simple file sharing protocol and basically says
> > that dynamic content is out (unless only targeting advanced clients).
> >
> 
> Here are my assumptions.
> 
> 1) Clients are going to cache, like it or not.  Some already do.
> 
> 2) Servers are in the best position to say whether content is dynamic or
> not. "Dynamic" in this case is not just CGI-generated; it's also static
> files that change often.  (I post a static file on the Web that is
> recomputed every ten minutes by a cron job.)
> 
> 3) If the server can communicate "don't cache this", the client can provide
> a better UX.

1) Rude clients are going to cache, yes.

2/3) Totally agree, just not about what the default should be ?

And just to keep this "grounded", here are some examples of stuff that
arbitrary caching would break:

- Adventure games that keep state in the client cert and update the
  response not only on user input
- The URL on my personal gemini site that responds with a random photo
- Guestbooks
- Streaming content

Meanwhile, a default of not caching anything doesn't break anything. All
it does is degrade the UX (minimally, IMO).

> Ultimately, I like the gemini protocol just the way it is (and wouldn'
> > be opposed to even a 1000 year feature freeze) but arbitrary caching by
> > clients kills a whole host of use-cases around generated and dynamic
> > responses.
> >
> 
> That horse has sailed and that ship is out of the barn.  "The world will go
> as it will, and not as you or I would have it."

Well, yes, fair enough. But gemini is only a tiny part of the world. If
the aesthetic sensibilities of the community turn out to conflict with
mine it's easy to look away ;)

bie

From sean at conman.org  Sat Nov  7 05:17:29 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 7 Nov 2020 00:17:29 -0500
Subject: [ANN] twins, a Gemini server written in Go
In-Reply-To: <r-YXIDM_iC27leRmYytmmgNb7iGcgu_T23MITK1oiNGeN94X1W42gWepk4pcUt97w610uumNBG7YR3JW23TfX35Xbhpq2uu6v2Ee0w8mvvY=@protonmail.com>
References: <1c220a89213393c9fa02dd2c1b5a245e@rocketnine.space>
 <r-YXIDM_iC27leRmYytmmgNb7iGcgu_T23MITK1oiNGeN94X1W42gWepk4pcUt97w610uumNBG7YR3JW23TfX35Xbhpq2uu6v2Ee0w8mvvY=@protonmail.com>
Message-ID: <20201107051729.GD30302@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> 
> >     twins includes the response body size in the media type header by default. This
> >     enables user experience improvements in Gemini clients, such as indicating
> >     download progress. It is possible to disable this feature.
> 
> For anyone wondering what that looks like:
> 
> ? gemget --header -o- gemini://twins.rocketnine.space/
> Info: Started gemini://twins.rocketnine.space/
> Header: 20 text/gemini; charset=utf-8; size=1128
> 
> 
> It looks like a nice server, but to be honest I would remove this.
> Serving non-standards is not what Gemini is about imo, and it's how
> the Web became what it is today. And clients in general should be
> strict and not accept things out-of-spec. For example Amfora won't
> allow non-standard status codes, even if the first digit matches a
> known code. It doesn't check for non-standard MIME params, but maybe
> it should?

  So what are the standard MIME parameters for text/plain?  text/markdown? 
text/html?  multipart/alternate?  And what should a client do when it
encounters a non-standard MIME parameter?

  -spc


From khuxkm at tilde.team  Sat Nov  7 05:45:41 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Sat, 07 Nov 2020 05:45:41 +0000
Subject: [ANN] twins, a Gemini server written in Go
In-Reply-To: <r-YXIDM_iC27leRmYytmmgNb7iGcgu_T23MITK1oiNGeN94X1W42gWepk4pcUt97w610uumNBG7YR3JW23TfX35Xbhpq2uu6v2Ee0w8mvvY=@protonmail.com>
References: <r-YXIDM_iC27leRmYytmmgNb7iGcgu_T23MITK1oiNGeN94X1W42gWepk4pcUt97w610uumNBG7YR3JW23TfX35Xbhpq2uu6v2Ee0w8mvvY=@protonmail.com>
 <1c220a89213393c9fa02dd2c1b5a245e@rocketnine.space>
Message-ID: <ed40a9bd7545f53d886994aa5450cea3@tilde.team>

November 6, 2020 11:15 PM, colecmac at protonmail.com wrote:

> It looks like a nice server, but to be honest I would remove this.
> Serving non-standards is not what Gemini is about imo, and it's how
> the Web became what it is today. And clients in general should be
> strict and not accept things out-of-spec. For example Amfora won't
> allow non-standard status codes, even if the first digit matches a
> known code. It doesn't check for non-standard MIME params, but maybe
> it should?

I don't agree that clients should be strict, because that adds more trouble onto a client. Take 2 minutes and try to find how to parse MIME types and parameters in Python.

...

See how easy that was? Just use a method in the cgi module, or maybe even a third party lib. Now take 2 minutes and try to find a Python library that can tell when a non-standard mimetype parameter is used.

...

You probably couldn't find anything. I sure couldn't. This doesn't even take into account the lack of forward compatibility (what happens if a new mimetype gets defined with new parameters? now what, every client *must* update to handle it?)

Just my 2 cents,
Robert "khuxkm" Miles

From list at gkbrk.com  Sat Nov  7 07:17:20 2020
From: list at gkbrk.com (Leo)
Date: Sat, 07 Nov 2020 10:17:20 +0300
Subject: Caching and status codes
In-Reply-To: <20201107043256.GA38951@202x.moe>
Message-ID: <C6WUJ19LK6H2.4WRJONR5923B@rath>

> > Clients are going to cache, like it or not.  Some already do.
> Rude clients are going to cache, yes.

I don't understand why a client caching responses is rude. Or rather, I
don't understand who it is being rude to. When I configure my HTTP or
Gemini browser to cache every response, is my browser now being rude to
me? Is it being rude to the server?

How can something that causes less resource usage on the server be rude
to the server, or something I configured or downloaded as a "client that
has caching" be rude to me for using it?

Is not doing everything a server sends being rude to the server
operator? If a server sends a 100000000x100000000 image, is my image
viewer being rude for refusing to decode/display it?

--
Leo

From linde.philip at gmail.com  Sat Nov  7 14:44:36 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sat, 7 Nov 2020 15:44:36 +0100
Subject: libmagic
In-Reply-To: <CAD2gp_QGGh5-_2BNBgW5OWMUL5Uu0Qw82EdW3-W3vbQX4k3HrQ@mail.gmail.com>
References: <CAD2gp_T43c1Jyay=Nm9zMfbbdRQgBpXeXwUY0HvGYQMMi07KNA@mail.gmail.com>
 <20201107010831.GA30302@brevard.conman.org>
 <CAD2gp_QGGh5-_2BNBgW5OWMUL5Uu0Qw82EdW3-W3vbQX4k3HrQ@mail.gmail.com>
Message-ID: <20201107154436.089e2cc49403972678602841@gmail.com>

On Fri, 6 Nov 2020 20:21:50 -0500
John Cowan <cowan at ccil.org> wrote:

> Any ideas for identifying text/gemini by regex?

There are none that aren't likely to produce either false positives or
false negatives. Consider this valid, plausibly realistic text/gemini
document (indented):

  # Hello
  
  This is the first paragraph.
  
  This is the second.

  * List item 1
  * List item 2
  
  ## Subsection 1
  
  This is a subsection.

  ```
  This is some pre-formatted text
  ```

This is also a valid text/markdown and text/plain document. I'd say
that the most easily identifiable trait of text-gemini is the link
arrows, but plenty of documents contain no links, and (less likely)
examples that would generate false positives/negatives can still be
created.

IMO, solutions like libmagic should be used as a last resort. Let the
server admin associate file types with extensions (for example via a
system provided MIME database, or in a cascading fashion starting with
manual associations in the server configuration file, and using the MIME
database if that fails). If no such association exists, by all means
utilize libmagic and hope for the best.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201107/d27f4ba2/attachment.sig>

From raiz at stellarbound.space  Sat Nov  7 16:43:58 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sat, 7 Nov 2020 19:43:58 +0300
Subject: Caching and status codes
In-Reply-To: <C6WUJ19LK6H2.4WRJONR5923B@rath>
References: <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
Message-ID: <20201107194358.61b66e19@home>

On Sat, 07 Nov 2020 10:17:20 +0300
"Leo" <list at gkbrk.com> wrote:
> I don't understand why a client caching responses is rude. Or rather,
> I don't understand who it is being rude to. When I configure my HTTP
> or Gemini browser to cache every response, is my browser now being
> rude to me? Is it being rude to the server?

The rude thing here would be having to serve large files over Gemini
and expect them to be served often, the protocol operates under the
assumption that caching does not exist, it's by convention, this
simplifies the client a LOT and removes such uncertainty when writing
dynamic content for Gemini.  Consider reading 2.1.1 in
gemini://gemini.circumlunar.space/docs/faq.gmi

> How can something that causes less resource usage on the server be
> rude to the server, or something I configured or downloaded as a
> "client that has caching" be rude to me for using it?

Because the server operates under the assumption that content is not
cached, if you're serving large files over Gemini you should look
somewhere else, this is not bittorrent, and if your server is eating up
a lot of resources, you're doing Gemini wrong, Gemini servers don't
have to be complicated, that's your own problem.  Consider using
connection queue and serving connections one by instead of forking or
multithreading because the protocol allows such simple design by
closing the connection right after the transaction, it's not like in
HTTP land where you have keep-alive.

> Is not doing everything a server sends being rude to the server
> operator? If a server sends a 100000000x100000000 image, is my image
> viewer being rude for refusing to decode/display it?

No, its being sane, this does not apply here.

Does everyone here require a lecture on why their desired features
aren't in the protocol yet? seems to be the common point of discussion
here, as if the protocol is NOT ENOUGH, I don't know what brought your
interest here, did you see it as a great way of avoiding the current
scope creep of the modern web, or as a playground to satisfy your bad
ideas?

Do you have anything else to help the community with? perhaps hosting
content in the Gemini space? or helping in the development of tools
interacting with the protocol? or is your interest just satisfied when
the spec becomes ten times of its current size, then you can MAYBE
decide to use the protocol for yourself.

If any feature does not add a great value at an acceptable cost to the
simplicity of the protocol, consider it rejected before even proposing
it, I don't want to have a different experience browsing Gemini space
using netcat than using Kristall.

From martin at no.ucant.org  Sat Nov  7 17:08:54 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sat, 7 Nov 2020 17:08:54 +0000 (GMT)
Subject: Caching and status codes
In-Reply-To: <20201107194358.61b66e19@home>
References: <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <20201107194358.61b66e19@home>
Message-ID: <alpine.DEB.2.21.2011071705570.31140@pling.qwghlm.org>

On Sat, 7 Nov 2020, Ali Fardan wrote:

> Does everyone here require a lecture on why their desired features
> aren't in the protocol yet? seems to be the common point of discussion
> here, as if the protocol is NOT ENOUGH, I don't know what brought your
> interest here, did you see it as a great way of avoiding the current
> scope creep of the modern web, or as a playground to satisfy your bad
> ideas?

As I've said too many times: Gemini offends people. Don't let them see you 
being annoyed when they try to provoke you.

Mk

From fluxion at monocles.de  Sat Nov  7 17:45:10 2020
From: fluxion at monocles.de (fluxion)
Date: Sat, 7 Nov 2020 18:45:10 +0100
Subject: hello
In-Reply-To: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
Message-ID: <20201107174510.GB8281@TARS.localdomain>

Hello gemini people.

My first time here so I thought it would be appropriate to send 
a message.

I have discovered gemini thanks to unicorn. I have been reading
some articles about it, explored clients, visited sites...
Loved the ssh kiosk by the way.
And fell in love with bombadillo, both the client and the name.

I don't know if I could browse the mailing history so as not
to ask redundant questions, but as I don't know such search
feature, here I go. Please correct me otherwise and feel free
to teach/guide me.

I am no developer, so let me ask a few naive questions. Not with
the intention of being critic with it. I love the idea for what
I have learned. So sometimes it will seem criticism, but in 
fact it will be ignorance on my behalf.

1) I agree that browsers are a nightmare, and I am worried that
Mozilla falls or shrinks and firefox with it. They are having
some financial troubles, I am told. So the idea of a beginning
from scratch is GREAT.

2) I love simplicity, and plain text (and vim). So I find 
that making the effort to retain such simplicity is worth
and not easy, since the easy is to ask for more and more.
I find minimalism great, and also hard. It requires 
constant self-reminding of why is so important. At least
I require such reminders.

3) I am a mathematical physicist and use a lot of equations
and data visualization. As a scientist, how can I use gemini?
For equations, I usually use MathJax. Talk about bloating!!!
It is great but it is huge. There are alternatives, but none
is near close to a plain text solution. We also have a set
of utilities like tex2mail, which converts LaTeX into ascii
or unicode art, but... it is really ugly and inconvenient.
We could just use raw LaTeX code, which for some expressions
would be fine:

\frac{a+b}{x^2+x-2}

or 

(x+y^2)^n

but what about a matrix or a more involved code? 
Is this up to us or is there a way to integrate this without
adding excessive complication?

What about data? The only thing that comes to me now is to
use Python's Sympy, which can render LaTeX equations in
ascii and also data graphics.

4) What about musicians, or artists? I am not talking about
music score, which even in html has never been offered a nice
solution (that I know of). But audio? Is it possible to 
have audio? I mean, no need for the browser to play it, but
to link it? And what about artistic expression? As much as
I love plain text and black and white, many Sapiens consider
design and style a very important thing. Will these communities
feel excluded from gemini because of extreme (I like extreme)
simplicity? I am sure I still have a lot to learn here.
Sometimes I use ncurses just to have some nice colors in my
terminal. My question here is: is the style and design of
the page enforced by the protocol, the client or the page
itself? IMHO a plain text browser in which each page could
define background and text color would be really awesome.

5) I love design and colors, but most of all I love content,
and I think that gemini is a refocus on content. And I love
it, with or without colors, with or without math. But my dream?
A minimalistic browsing with page-defined colors and with
some easiness to integrate math and graphics with plain text.

Thanks for all the work. I will keep learning from you.
And I will also write less words next time (`:

fluxion


From fluxion at monocles.de  Sat Nov  7 18:08:39 2020
From: fluxion at monocles.de (fluxion)
Date: Sat, 7 Nov 2020 19:08:39 +0100
Subject: examples with Sympy
In-Reply-To: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
Message-ID: <20201107180839.GC8281@TARS.localdomain>

I thought it could be nice to show some examples rendered
with Sympy.
With unicode:

pprint(Integral(sqrt((1+x)/(x**2+3)),x)+Sum(1/j**2,(j,1,n)))

                       n     
                      ____   
?                     ?      
?      ________        ?   1 
?     ? x + 1           ?  ??
?    ?  ??????  dx +    ?   2
?   ?    2             ?   j 
? ??    x  + 3        ?      
?                     ????   
                     j = 1 


With ascii:

pprint(Integral(sqrt((1+x)/(x**2+3)),x)+Sum(1/j**2,(j,1,n)), use_unicode=False)

                        n     
  /                   ____    
 |                    \   `   
 |      ________       \    1 
 |     / x + 1          \   --
 |    /  ------  dx +   /    2
 |   /    2            /    j 
 | \/    x  + 3       /___,   
 |                    j = 1   
/

By comparison, the LaTeX text could be
\int{\sqrt{\frac{x+1}{x^2+3}}dx+\sum_{j=1}^n\frac{1}{j^2}
which I don't have a problem reading it, but... for non-LaTeX users...

Finally, an example of a graphic:

plot(sin(x),(x,-2*pi,2*pi))

0.99830 |       ...                        ...                   
        |      /   \                      /   \                  
        |     /     .                    /     .                 
        |    .                          .                        
        |            .                          .                
        |   .                          .                         
        |             .                          .               
        |  .                          .                          
0.05872 | -------------.--------------------------.--------------
        | .             .            .             .            /
        |                           .                          . 
        |                .                          .            
        |                          .                          .  
        |                 .                          .           
        |                         .                          .   
        |                  .     /                    .     /    
        |                   \   /                      \   /     
-0.9983 |                    ...                        ...      
          -6.28319                   0                          6.28319

In this case we seem to get the same result with ascii and unicode,
or maybe Sympy does not distinguish for plotting, although both
pprint(plot(sin(x),(x,-2*pi,2*pi)),use_unicode=False)
and 
pprint(plot(sin(x),(x,-2*pi,2*pi)))
seem to be accepted by Sympy.

Is this enough for math & data? What do you think?



From raiz at stellarbound.space  Sat Nov  7 18:10:10 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sat, 7 Nov 2020 21:10:10 +0300
Subject: hello
In-Reply-To: <20201107174510.GB8281@TARS.localdomain>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107174510.GB8281@TARS.localdomain>
Message-ID: <20201107211010.0540edf1@home>

On Sat, 7 Nov 2020 18:45:10 +0100
fluxion <fluxion at monocles.de> wrote:
> 1) I agree that browsers are a nightmare, and I am worried that
> Mozilla falls or shrinks and firefox with it. They are having
> some financial troubles, I am told. So the idea of a beginning
> from scratch is GREAT.

Lower your expectations, this probably wont replace the web, but I
hope it does one day.

> 3) I am a mathematical physicist and use a lot of equations
> and data visualization. As a scientist, how can I use gemini?
> For equations, I usually use MathJax. Talk about bloating!!!
> It is great but it is huge. There are alternatives, but none
> is near close to a plain text solution. We also have a set
> of utilities like tex2mail, which converts LaTeX into ascii
> or unicode art, but... it is really ugly and inconvenient.
>
> [...]
>
> what about a matrix or a more involved code? 
> Is this up to us or is there a way to integrate this without
> adding excessive complication?
> 
> What about data? The only thing that comes to me now is to
> use Python's Sympy, which can render LaTeX equations in
> ascii and also data graphics.

I get it... You're confused, Gemini is a protocol, not a document
format, gemtext (text/gemini) is the document format used by default
within the Gemini protocol, but there's nothing stopping you from
serving LaTeX formatted PDFs through Gemini, or for that matter, any
format.

> 4) What about musicians, or artists? I am not talking about
> music score, which even in html has never been offered a nice
> solution (that I know of). But audio? Is it possible to 
> have audio? I mean, no need for the browser to play it, but
> to link it? And what about artistic expression? As much as
> I love plain text and black and white, many Sapiens consider
> design and style a very important thing. Will these communities
> feel excluded from gemini because of extreme (I like extreme)
> simplicity? I am sure I still have a lot to learn here.
> Sometimes I use ncurses just to have some nice colors in my
> terminal. My question here is: is the style and design of
> the page enforced by the protocol, the client or the page
> itself? IMHO a plain text browser in which each page could
> define background and text color would be really awesome.

Read the FAQ: gemini://gemini.circumlunar.space/docs/faq.gmi
Gemtext is just a document format, styling is left for the client to
decide, stylesheets are not a thing here, unless you want to use Gemini
to serve HTML+CSS which you can do, but I wouldn't recommend.

For example, here's what Gemini looks like on my client:
https://ttm.sh/dt8.png, this page could look totally different on
someone else's client, they decide how to style content displayed on
their client, not the author.

> 5) I love design and colors, but most of all I love content,
> and I think that gemini is a refocus on content. And I love
> it, with or without colors, with or without math. But my dream?
> A minimalistic browsing with page-defined colors and with
> some easiness to integrate math and graphics with plain text.

No.

From fluxion at monocles.de  Sat Nov  7 18:34:27 2020
From: fluxion at monocles.de (fluxion)
Date: Sat, 7 Nov 2020 19:34:27 +0100
Subject: hello
In-Reply-To: <20201107211010.0540edf1@home>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107174510.GB8281@TARS.localdomain>
 <20201107211010.0540edf1@home>
Message-ID: <20201107183427.GA43445@TARS.localdomain>

> Read the FAQ: gemini://gemini.circumlunar.space/docs/faq.gmi
> Gemtext is just a document format, styling is left for the client to
> decide, stylesheets are not a thing here, unless you want to use Gemini
> to serve HTML+CSS which you can do, but I wouldn't recommend.

OK, thanks for the reply. I had already read the FAQ, but being such
a new concept to me I got confused in many aspects. 

I'll keep learning.



From cowan at ccil.org  Sat Nov  7 18:42:57 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 7 Nov 2020 13:42:57 -0500
Subject: Caching and status codes
In-Reply-To: <20201107194358.61b66e19@home>
References: <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <20201107194358.61b66e19@home>
Message-ID: <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>

On Sat, Nov 7, 2020 at 11:44 AM Ali Fardan <raiz at stellarbound.space> wrote:

The rude thing here would be having to serve large files over Gemini
> and expect them to be served often, the protocol operates under the
> assumption that caching does not exist
>

If clients aren't free to cache, then I'm not free to save a .gmi file on
my file system.  That's all a client-side cache is.

> Consider using
> connection queue and serving connections one by instead of forking or
> multithreading because the protocol allows such simple design by
> closing the connection right after the transaction, it's not like in
> HTTP land where you have keep-alive.
>

The advantages of not serving connections one by one is that it provides
better service to clients on a heavily-used server.  Right now there are no
heavily-used servers, but there's nothing in the Gemini ethos that says
"documents should only be of interest to a few".  That's sheer elitism.

> Does everyone here require a lecture on why their desired features
> aren't in the protocol yet?


Client caching has nothing to do with the protocol.  The idea of 22 is that
authors (not servers) may want to advise clients against caching in a
particular case.

Do you have anything else to help the community with?
>

"I'm thinking!  I'm thinking!"  --Jack Benny during a holdup

> If any feature does not add a great value at an acceptable cost to the
> simplicity of the protocol, consider it rejected before even proposing
> it, I don't want to have a different experience browsing Gemini space
> using netcat than using Kristall.
>

If you are browsing with netcat, caching is not even an issue.  If nobody
wanted to serve dynamic content, 22 wouldn't be useful.  It is handy for
those who do want to, to communicate their intent.  No client and no server
has to implement this.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
A witness cannot give evidence of his age unless he can remember being born.
                --Judge Blagden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201107/7ccd309e/attachment.htm>

From khuxkm at tilde.team  Sat Nov  7 19:35:02 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Sat, 07 Nov 2020 19:35:02 +0000
Subject: Caching and status codes
In-Reply-To: <20201107194358.61b66e19@home>
References: <20201107194358.61b66e19@home>
 <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
Message-ID: <6bf932f1c4ae5c1aa49dfc195abb0687@tilde.team>

November 7, 2020 11:43 AM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> On Sat, 07 Nov 2020 10:17:20 +0300
> "Leo" <list at gkbrk.com> wrote:
> 
>> I don't understand why a client caching responses is rude. Or rather,
>> I don't understand who it is being rude to. When I configure my HTTP
>> or Gemini browser to cache every response, is my browser now being
>> rude to me? Is it being rude to the server?
> 
> The rude thing here would be having to serve large files over Gemini
> and expect them to be served often, the protocol operates under the
> assumption that caching does not exist, it's by convention, this
> simplifies the client a LOT and removes such uncertainty when writing
> dynamic content for Gemini. Consider reading 2.1.1 in
> gemini://gemini.circumlunar.space/docs/faq.gmi

Alright, bet. 2.1.1 in the FAQ says:

> Gemini aims to be simple, but not too simple. Gopher is simpler at
> a protocol level, but as a consequence the client is eternally
> uncertain: what character encoding is this text in? Is this text the
> intended content or an error message from the server? What kind of 
> file is this binary data? Because of this, a robust Gopher client is
> made less simple by needing to infer or guess missing information. 
> Early Gemini discussion included three clear goals with regard to
> simplicity:
>
> * It should be possible for somebody who had no part in designing
> the protocol to accurately hold the entire protocol spec in their
> head after reading a well-written description of it once or twice.
> * A basic but usable (not ultra-spartan) client should fit
> comfortably within 50 or so lines of code in a modern high-level
> language. Certainly not more than 100.
> * A client comfortable for daily use which implements every single
> protocol feature should be a feasible weekend programming project
> for a single developer.

Adding separate 2x status codes for "feel free to cache this" and 
"don't cache this" would follow:

* It's literally just 2 more numbers to remember, shouldn't be much 
harder than remembering the status codes that exist today.
* A basic but usable client can just ignore 21/22 and act like it
got a 20 response code (that's the point of the 2-digit response
code, AFAICT).
* Implementing some form of caching wouldn't be too hard to add to
a client that "implements every single protocol feature".

>> How can something that causes less resource usage on the server be
>> rude to the server, or something I configured or downloaded as a
>> "client that has caching" be rude to me for using it?
> 
> Because the server operates under the assumption that content is not
> cached, if you're serving large files over Gemini you should look
> somewhere else, this is not bittorrent, and if your server is eating up
> a lot of resources, you're doing Gemini wrong, Gemini servers don't
> have to be complicated, that's your own problem. Consider using
> connection queue and serving connections one by instead of forking or
> multithreading because the protocol allows such simple design by
> closing the connection right after the transaction, it's not like in
> HTTP land where you have keep-alive.

Elitism much? Let me read you 2.1.3, from the very same FAQ you quoted:

> The "first class" application of Gemini is human consumption of
> predominantly written material - to facilitate something like
> gopherspace, or like "reasonable webspace" (e.g. something which is
> comfortably usable in Lynx or Dillo). But, just like HTTP can be, and
> is, used for much, much more than serving HTML, Gemini should be able to
> be used for as many other purposes as possible without compromising the
> simplicity and privacy criteria above. This means taking into account
> possible applications built around non-text files and non-human clients.

I'm not sure how you read this section, but it seems to me like the intent
is to be able to serve large files if you can.

>> Is not doing everything a server sends being rude to the server
>> operator? If a server sends a 100000000x100000000 image, is my image
>> viewer being rude for refusing to decode/display it?
> 
> No, its being sane, this does not apply here.

Let me rephrase the question: if a server tells you you can cache the 
response, is your client being rude for refusing to cache it?

> Does everyone here require a lecture on why their desired features
> aren't in the protocol yet? seems to be the common point of discussion
> here, as if the protocol is NOT ENOUGH, I don't know what brought your
> interest here, did you see it as a great way of avoiding the current
> scope creep of the modern web, or as a playground to satisfy your bad
> ideas?

Again, your elitism is showing. I feel like adding a way to signal 
whether or not you can safely cache a response isn't really sacrificing 
any of the Gemini ethos: simplicity, privacy, or generality.

> If any feature does not add a great value at an acceptable cost to the
> simplicity of the protocol, consider it rejected before even proposing
> it, I don't want to have a different experience browsing Gemini space
> using netcat than using Kristall.

I fail to see how adding "safe to cache" and "do not cache" status codes 
would make using netcat different from Kristall or any other client. Just 
treat it as a 2x success status code, and move on.

Just my two cents,
Robert "khuxkm" Miles

From mailinglists at ngalt.com  Sat Nov  7 21:13:12 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Sat, 7 Nov 2020 13:13:12 -0800
Subject: Caching and status codes
In-Reply-To: <20201106055217.GA4163@202x.moe>
References: <20201106055217.GA4163@202x.moe>
Message-ID: <F17151BE-7D19-4008-9C1D-9FF52A98E27A@ngalt.com>



> On Nov 5, 2020, at 9:52 PM, bie <bie at 202x.moe> wrote:
> 
> Now, I don't see the need for caching at all when it comes to
> gemini, but if it's something the gemini community wants or needs then
> I'd like to suggest a 2x status code that let's a client know that the
> response is unlikely to change and thus cacheable. This could even kind
> of match how the temporary/permanent redirect status codes are defined:
> 
> 20 - SUCCESS
> 21 - "PERMANENT" SUCCESS (Feel free to cache this)

Bit of a bikeshed comment, but ?permanent success?, especially the ?permanent? part, makes me think of Cache-Control: immutable. That is, the server is claiming that the file will not change, ever. (Gemini doesn?t have conditional revalidation.)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

From tgrom.automail at nuegia.net  Sat Nov  7 21:28:51 2020
From: tgrom.automail at nuegia.net (Tom)
Date: Sat, 7 Nov 2020 13:28:51 -0800
Subject: Potential preloading of MIME?
In-Reply-To: <20201107174510.GB8281@TARS.localdomain>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107174510.GB8281@TARS.localdomain>
Message-ID: <20201107132842.61111d16@lappy.lan>


> 3) I am a mathematical physicist and use a lot of equations
> and data visualization. As a scientist, how can I use gemini?
> For equations, I usually use MathJax. Talk about bloating!!!
> It is great but it is huge. There are alternatives, but none
> is near close to a plain text solution. We also have a set
> of utilities like tex2mail, which converts LaTeX into ascii
> or unicode art, but... it is really ugly and inconvenient.
> We could just use raw LaTeX code, which for some expressions
> would be fine:
> 
> \frac{a+b}{x^2+x-2}
> 
> or 
> 
> (x+y^2)^n
> 
> but what about a matrix or a more involved code? 
> Is this up to us or is there a way to integrate this without
> adding excessive complication?
> 
> What about data? The only thing that comes to me now is to
> use Python's Sympy, which can render LaTeX equations in
> ascii and also data graphics.
> 
> 4) What about musicians, or artists? I am not talking about
> music score, which even in html has never been offered a nice
> solution (that I know of). But audio? Is it possible to 
> have audio? I mean, no need for the browser to play it, but
> to link it? And what about artistic expression? As much as
> I love plain text and black and white, many Sapiens consider
> design and style a very important thing. Will these communities
> feel excluded from gemini because of extreme (I like extreme)
> simplicity? I am sure I still have a lot to learn here.
> Sometimes I use ncurses just to have some nice colors in my
> terminal. My question here is: is the style and design of
> the page enforced by the protocol, the client or the page
> itself? IMHO a plain text browser in which each page could
> define background and text color would be really awesome.
> 
> 5) I love design and colors, but most of all I love content,
> and I think that gemini is a refocus on content. And I love
> it, with or without colors, with or without math. But my dream?
> A minimalistic browsing with page-defined colors and with
> some easiness to integrate math and graphics with plain text.
> 
> Thanks for all the work. I will keep learning from you.
> And I will also write less words next time (`:
> 
> fluxion
> 

Hello,

I understand your concern completely and share some of it. One of the
biggest reasons not to use gemini over XHTML is the lack of MathML. And
a reason to use MathML over others such as just exporting a scalable
vector graphic is so that MathML can be read as Nemeth code so that
disabled people may still view the math. Talking about accessibility
this super important.

Now I'm not a fan of not being able to insert objects inline in gemini,
but the compromise of just having a link on a single line to do not
feel serves this side particularly well. Take a more general thing like
images. Clients that do want to display images the only way they have
of determining which links contains images is be following each one of
them, which in a form can trigger unwanted actions and certainly
increase overall network load. Some clients look at the extension at
the end of the file name, for example .jpg or .png and preload if the
filename ends in that. I do not think this is a good option. For one we
have MIME, and secondly using filenames for determining file type is a
relic of DOS we really should leave behind, and we have left behind on
every operating system besides DOS and NT. Replacing with magic(5).

Many files to not even have a .something at the end of their name as
magic(5) takes care of type recognition.

I don't think it would be practical to have Gemini clients need to
check the magic of every link and instead think a much more robust
solution would be simple to optionally (or mandatory) add an expected
MIME for links in Gemini. This way clients could decide what they are
capable of rendering and decide to go get that content if it wants it.

This however I feel is still only a half-solution for expressing
mathematical and scientific formulas as it is still not inline, which
is how scientific papers often use formulas.

Looking for more commentary on this topic.

From list at gkbrk.com  Sat Nov  7 21:41:10 2020
From: list at gkbrk.com (Leo)
Date: Sun, 08 Nov 2020 00:41:10 +0300
Subject: Caching and status codes
In-Reply-To: <20201107194358.61b66e19@home>
Message-ID: <C6XCWFHU26R2.3JV3F81N8FZ5Y@rath>

I apologise if anyone got this email twice. I forgot to switch out my
email address before submitting to the list. Following is my original
reply.


Ok when I replied I thought you were going to argue about something
ideological about how the content creator should get the final say in
how their content is accessed, but it looks like you are arguing on a
technical viewpoint. What you are saying does not make a lot of sense to
me though.

> Rude clients are going to cache.

This is the statement that bothered me because it seemed very weird to
consider a client "rude" for not making requests. So I asked about it
for clarification.

> > I don't understand why a client caching responses is rude. Or rather,
> > I don't understand who it is being rude to. When I configure my HTTP
> > or Gemini browser to cache every response, is my browser now being
> > rude to me? Is it being rude to the server?
> The rude thing here would be having to serve large files over Gemini
> and expect them to be served often,

But here you are saying that the rude thing here is having to serve
large files over gemini and expecting them to be served often. This
would be the server being rude, and clients caching or not caching
resources would not have an impact on how large a server's reponses are.

If anything, it would result in less traffic and at least partially
mitigate the issue. If your server is being _rude_ and sending large
responses, my client is not gonna make it worse by requesting it every
single time. Your server might have a lot of bandwidth, my client does
not.

> the protocol operates under the assumption that caching does not exist,
> it's by convention, this simplifies the client a LOT and removes such
> uncertainty when writing dynamic content for Gemini. Consider reading
> 2.1.1 in gemini://gemini.circumlunar.space/docs/faq.gmi

The protocol operates under the assumption that caching does not exist
in order to make clients and servers simpler. A client adding caching
would NOT affect a server negatively. If you consider caching clients to
be rude clients, too bad, you will never notice them because instead of
making extra requests, they are making less. I suppose you can ask them
to apologise for not making you spend money on compute/bandwidth etc.

> > How can something that causes less resource usage on the server be
> > rude to the server, or something I configured or downloaded as a
> > "client that has caching" be rude to me for using it?
> Because the server operates under the assumption that content is not
> cached, if you're serving large files over Gemini you should look
> somewhere else, this is not bittorrent, and if your server is eating up
> a lot of resources, you're doing Gemini wrong, Gemini servers don't
> have to be complicated, that's your own problem. Consider using
> connection queue and serving connections one by instead of forking or
> multithreading because the protocol allows such simple design by
> closing the connection right after the transaction, it's not like in
> HTTP land where you have keep-alive.

Again, you are talking about making servers more complicated. If my
client does not cache and your server sends large responses, this is
indeed a problem and you might have to make your server more complex to
handle it. Caching clients would make simpler server code possible, as
performance tricks would not be necessary. But even ignoring that, a
client that caches responses would not make your server more complex.

> > Is not doing everything a server sends being rude to the server
> > operator? If a server sends a 100000000x100000000 image, is my image
> > viewer being rude for refusing to decode/display it?
> No, its being sane, this does not apply here.

So it is being sane when a server says "display this monstrous image"
and the client refuses, but it is insane when the server says "please
download this resource that you downloaded 3 seconds ago" and the client
says "I'll just use the response I have cached"?

> Does everyone here require a lecture on why their desired features
> aren't in the protocol yet? seems to be the common point of discussion
> here, as if the protocol is NOT ENOUGH, I don't know what brought your
> interest here, did you see it as a great way of avoiding the current
> scope creep of the modern web, or as a playground to satisfy your bad
> ideas?

The whole point of the discussion is that clients WILL cache resources.
Gemini benefits a lot from having a wide range of different clients. You
simply can't control everyone's use case to fit the way you think they
should consume content.

Just like some browsers/proxies cache HTTP and Gopher responses, some
people who are bandwidth constrained or simply not wasteful will choose
to cache their Gemini responses too. The discussion throws out the idea
of client HINTS that will say "This might be a dynamic response, maybe
don't cache it". Neither the server nor the client needs to take
advantage of this, a client can always cache or never cache, and a
server can expect everything to be cached or not cached. Just like
before.

I understand the desire to keep the spec short, and actually agree with
people on this. I believe a new response code for this is not necessary.
But a client that caches something is not being rude, at least not more
than a client that offers to save the resource to the disk or to send it
to a printer.

> Do you have anything else to help the community with? perhaps hosting
> content in the Gemini space? or helping in the development of tools
> interacting with the protocol? or is your interest just satisfied when
> the spec becomes ten times of its current size, then you can MAYBE
> decide to use the protocol for yourself.

Disagreeing with someone is one thing, but you don't have to attack them
like this. Before you shame other people, please enlighten us with the
tangible value that you have provided to the greater Gemini community.

> If any feature does not add a great value at an acceptable cost to the
> simplicity of the protocol, consider it rejected before even proposing
> it, I don't want to have a different experience browsing Gemini space
> using netcat than using Kristall.

I agree with this completely.

--
Leo

From anothersms at gmail.com  Sat Nov  7 21:37:27 2020
From: anothersms at gmail.com (=?utf-8?Q?Nicol=C3=B2?= Balzarotti)
Date: Sat, 07 Nov 2020 22:37:27 +0100
Subject: Potential preloading of MIME?
In-Reply-To: <20201107132842.61111d16@lappy.lan>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107174510.GB8281@TARS.localdomain>
 <20201107132842.61111d16@lappy.lan>
Message-ID: <87eel4lug8.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>

Hi, citing the specs, 5.4.2:

Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. gemini://, gopher://, https://, ftp://, etc.).

So, mime is useless as human has the final say, not the client

Nicol?

Tom <tgrom.automail at nuegia.net> writes:

>> 3) I am a mathematical physicist and use a lot of equations
>> and data visualization. As a scientist, how can I use gemini?
>> For equations, I usually use MathJax. Talk about bloating!!!
>> It is great but it is huge. There are alternatives, but none
>> is near close to a plain text solution. We also have a set
>> of utilities like tex2mail, which converts LaTeX into ascii
>> or unicode art, but... it is really ugly and inconvenient.
>> We could just use raw LaTeX code, which for some expressions
>> would be fine:
>> 
>> \frac{a+b}{x^2+x-2}
>> 
>> or 
>> 
>> (x+y^2)^n
>> 
>> but what about a matrix or a more involved code? 
>> Is this up to us or is there a way to integrate this without
>> adding excessive complication?
>> 
>> What about data? The only thing that comes to me now is to
>> use Python's Sympy, which can render LaTeX equations in
>> ascii and also data graphics.
>> 
>> 4) What about musicians, or artists? I am not talking about
>> music score, which even in html has never been offered a nice
>> solution (that I know of). But audio? Is it possible to 
>> have audio? I mean, no need for the browser to play it, but
>> to link it? And what about artistic expression? As much as
>> I love plain text and black and white, many Sapiens consider
>> design and style a very important thing. Will these communities
>> feel excluded from gemini because of extreme (I like extreme)
>> simplicity? I am sure I still have a lot to learn here.
>> Sometimes I use ncurses just to have some nice colors in my
>> terminal. My question here is: is the style and design of
>> the page enforced by the protocol, the client or the page
>> itself? IMHO a plain text browser in which each page could
>> define background and text color would be really awesome.
>> 
>> 5) I love design and colors, but most of all I love content,
>> and I think that gemini is a refocus on content. And I love
>> it, with or without colors, with or without math. But my dream?
>> A minimalistic browsing with page-defined colors and with
>> some easiness to integrate math and graphics with plain text.
>> 
>> Thanks for all the work. I will keep learning from you.
>> And I will also write less words next time (`:
>> 
>> fluxion
>> 
>
> Hello,
>
> I understand your concern completely and share some of it. One of the
> biggest reasons not to use gemini over XHTML is the lack of MathML. And
> a reason to use MathML over others such as just exporting a scalable
> vector graphic is so that MathML can be read as Nemeth code so that
> disabled people may still view the math. Talking about accessibility
> this super important.
>
> Now I'm not a fan of not being able to insert objects inline in gemini,
> but the compromise of just having a link on a single line to do not
> feel serves this side particularly well. Take a more general thing like
> images. Clients that do want to display images the only way they have
> of determining which links contains images is be following each one of
> them, which in a form can trigger unwanted actions and certainly
> increase overall network load. Some clients look at the extension at
> the end of the file name, for example .jpg or .png and preload if the
> filename ends in that. I do not think this is a good option. For one we
> have MIME, and secondly using filenames for determining file type is a
> relic of DOS we really should leave behind, and we have left behind on
> every operating system besides DOS and NT. Replacing with magic(5).
>
> Many files to not even have a .something at the end of their name as
> magic(5) takes care of type recognition.
>
> I don't think it would be practical to have Gemini clients need to
> check the magic of every link and instead think a much more robust
> solution would be simple to optionally (or mandatory) add an expected
> MIME for links in Gemini. This way clients could decide what they are
> capable of rendering and decide to go get that content if it wants it.
>
> This however I feel is still only a half-solution for expressing
> mathematical and scientific formulas as it is still not inline, which
> is how scientific papers often use formulas.
>
> Looking for more commentary on this topic.

From list at gkbrk.com  Sat Nov  7 21:47:19 2020
From: list at gkbrk.com (Leo)
Date: Sun, 08 Nov 2020 00:47:19 +0300
Subject: examples with Sympy
In-Reply-To: <20201107180839.GC8281@TARS.localdomain>
Message-ID: <C6XD15B1EJVO.1GF8DLPJOPDEW@rath>

Wow! These look amazing on the terminal. I am not quote-replying as I
don't want to mess with the beautiful monospace rendering.

I would love to read a maths/science/CS related blog that uses this
kind of rendering. This is so pleasant to look at on both a terminal and
a GUI client.

I hope someone will take the time to write either a latex-to-gemtext
compiler that can generate this, or a server that does it dynamically.

--
Leo

From cowan at ccil.org  Sat Nov  7 22:48:33 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 7 Nov 2020 17:48:33 -0500
Subject: Caching and status codes
In-Reply-To: <6bf932f1c4ae5c1aa49dfc195abb0687@tilde.team>
References: <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <20201107194358.61b66e19@home>
 <6bf932f1c4ae5c1aa49dfc195abb0687@tilde.team>
Message-ID: <CAD2gp_Sa1ViyqK0Q-1QTpw=FxYAeXLaHKN7jhVptvp0+RA-6Ew@mail.gmail.com>

On Sat, Nov 7, 2020 at 2:35 PM <khuxkm at tilde.team> wrote:


> Again, your elitism is showing. I feel like adding a way to signal
> whether or not you can safely cache a response isn't really sacrificing
> any of the Gemini ethos: simplicity, privacy, or generality.
>

+1

> I fail to see how adding "safe to cache" and "do not cache" status codes
> would make using netcat different from Kristall or any other client. Just
> treat it as a 2x success status code, and move on.
>

In addition, if you click on a link saying "Random cool picture!", first of
all that's safe (no pixel bug in it), and second, if you notice that it's
the same picture as last time, you do a refresh, causing your client to
override its cache, and you see a different picture.  Everybody wins.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
There is no real going back.  Though I may come to the Shire, it will
not seem the same; for I shall not be the same.  I am wounded with
knife, sting, and tooth, and a long burden.  Where shall I find rest?
                --Frodo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201107/6ba6a604/attachment-0001.htm>

From raiz at stellarbound.space  Sun Nov  8 01:15:44 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 8 Nov 2020 04:15:44 +0300
Subject: Caching and status codes
In-Reply-To: <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
References: <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
Message-ID: <20201107222315.0f596e83@home>

On Sat, 7 Nov 2020 13:42:57 -0500
John Cowan <cowan at ccil.org> wrote:
> If clients aren't free to cache, then I'm not free to save a .gmi
> file on my file system.  That's all a client-side cache is.

You're free to save your served documents, just don't operate under the
assumption that they're permanent, that's how caching can break current
assumptions.

> The advantages of not serving connections one by one is that it
> provides better service to clients on a heavily-used server.  Right
> now there are no heavily-used servers, but there's nothing in the
> Gemini ethos that says "documents should only be of interest to a
> few".  That's sheer elitism.

I'm not telling you how to implement your server, I just don't like
raising the barrier to entry for server implementations, right now, I
can use inetd to serve Gemini, if keeping a connection alive is a
requirement in the future that wouldn't be the case.

> Client caching has nothing to do with the protocol.  The idea of 22
> is that authors (not servers) may want to advise clients against
> caching in a particular case.

How would gemtext author instruct the server not to cache their gemtext
document? do we now resort to writing response headers in gemtext? is
that the solution?

Or suppose you allowed an undefined implementation detail to the server
for allowing the distinction of static versus dynamic content, and
every server goes their way of implementing it whether it be through
configuration files or some other means, now 20 becomes obsolete
because existing implementations of servers can't be sure that clients
will not cache their dynamic content, brilliant.

> If you are browsing with netcat, caching is not even an issue.  If
> nobody wanted to serve dynamic content, 22 wouldn't be useful.  It is
> handy for those who do want to, to communicate their intent.  No
> client and no server has to implement this.

If 22 is explicit no caching response, how would 20 be redefined?

Whenever something becomes optional, but de-facto implementations cover
it, and the whole ecosystem operates under the assumption of its
presence, the feature shifts from being optional to being a barrier to
entry.

From gmi1 at scotdoyle.com  Sun Nov  8 01:20:21 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Sat, 7 Nov 2020 19:20:21 -0600
Subject: Adding close_notify to the spec ?
Message-ID: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>

Does anyone have any concerns about amending the spec to state that a TLS
close_notify message should be sent before closing the TCP connection?
While TLS guarantees the integrity of the data from the server, it does
not guarantee completeness until a close_notify is received by the client.
Interested and able clients could then determine that they received a
complete response.

The sending of close_notify is discussed in section 6.1 of RFC 8446 [1].

This approach was previously discussed on the list by Michael Lazar and
solderpunk [2] [3] and kooda [4].

I have been testing various software and configurations to find out the
feasibility of this approach. The ability to send close_notify is part of
the TLS 1.2 and 1.3 specs, and is widely available for server authors to
use. The OpenSSL C library provides the SSL_shutdown function which sends
close_notify. The LibreSSL C library has had the same function since its
first release. The libtls library included with LibreSSL provides this
functionality in the tls_close function. I've verified the effectiveness of
Python's SSLSocket.unwrap method. Ruby seems to handle this with
SSLObject.sysclose and Go with the Close method in crypto/tls/conn.go.

Every TLS 1.2 or 1.3 client I've seen will automatically handle TLS
close_notify messages. Non-blocking clients will make a poll/select/etc
call and wait for data from the server. When the close_notify message is
received by the TLS library used by the client software, it will indicate
that data is ready to be read/received. So whether the client is blocking
or non-blocking, it will eventually perform a read/receive call since it
cannot yet know that there is no more data from the server. The
close_notify message from the server will causes the TLS library to return
0 bytes from the read/receive call. Some libraries will also return an
error message or status code indicating that a close_notify was received.
In any case, the connection with the server is automatically closed
(completely in TLS 1.2, and at a minimum from further reads in TLS 1.3).

So, why can't we just use a read/receive of 0 bytes to always know that a
close_notify was received? Because if the TCP connection is closed before a
close_notify, the read/receive call will also return 0 bytes. Some clients
do not have a way to distinguish between TCP disconnect and close_notify.

But should a client author wish to use this feature, those written in C and
using OpenSSL/LibreSSL can use the SSL_read and SSL_get_error functions to
obtain the SSL_ERROR_ZERO_RETURN value. Those written in C and using libtls
can use the tls_read and tls_get_error functions. Python clients can use
the demonstrated method [6]. And while there is no assured way to do this
in Ruby or Go currently, patching Ruby's SSLSocket.sysread or Go's
crypto/tls/conn.go readRecord to use the information already available in
those source files might be possible.

You can inspect the TLS messages received from any server, including
the close_notify message, with the included Python script [6].

130 out of 208 servers listed on GUS [5] send the close_notify
message before disconnecting.


[1] https://tools.ietf.org/html/rfc8446
[2] https://lists.orbitalfox.eu/archives/gemini/2019/000037.html
[3] https://lists.orbitalfox.eu/archives/gemini/2020/002150.html
[4] https://lists.orbitalfox.eu/archives/gemini/2020/002243.html
[5] gemini://gus.guru/known-hosts
[6] I dedicate this script to the public domain.
 ??? To query a different server, modify the second line.


import socket, ssl, time
server, port, path = 'gemini.circumlunar.space', 1965, '/'
start, out, cn = time.time(), [], False
def log(m): out.append('\n--- %f %s' % (time.time()-start, m))
def callback(connection, direction, v, c, m, data):
 ? p = [str(i)[str(i).find('.')+1:] for i in [direction, v, c, m]]
 ? log(''.join([i.ljust(j, ' ').lower()
 ????????????? for i, j in zip(p, [6, 8, 19, 20])]))
 ? if m == ssl._TLSAlertType.CLOSE_NOTIFY and direction == 'read':
 ??? global cn; cn = True
context = ssl.SSLContext(ssl.PROTOCOL_TLS)
context.verify_mode = ssl.CERT_NONE
context.check_hostname = False
context._msg_callback = callback
sock = socket.socket(socket.AF_INET)
sock.settimeout(5)
connection = context.wrap_socket(sock, server_hostname=server)
connection.connect((server, port))
log('SENDING GEMINI REQUEST TO SERVER')
connection.send(b'gemini://'+server.encode()+path.encode()+b'\r\n')
log('RECEIVING GEMINI RESPONSE FROM SERVER')
sameline = False
while True:
 ? try:
 ??? data = connection.recv().decode()
 ??? if len(data) < 1:
 ????? if cn: log('COMPLETE RESPONSE RECEIVED')
 ????? if not cn: log('COMPLETE RESPONSE MAY NOT HAVE BEEN RECEIVED')
 ????? break
 ??? if not sameline:
 ????? data = '\n' + data
 ??? out.append(data.rstrip().replace('\n', '\n'+' '*4))
 ??? sameline, data = (data[-1] != '\n'), ''
 ? except Exception as e:
 ??? log(str(e).upper())
connection.close()
print((''.join(out))[1:])

From raiz at stellarbound.space  Sun Nov  8 01:33:51 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 8 Nov 2020 04:33:51 +0300
Subject: Caching and status codes
In-Reply-To: <6bf932f1c4ae5c1aa49dfc195abb0687@tilde.team>
References: <20201107194358.61b66e19@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <6bf932f1c4ae5c1aa49dfc195abb0687@tilde.team>
Message-ID: <20201108043351.375d3f53@home>

On Sat, 07 Nov 2020 19:35:02 +0000
khuxkm at tilde.team wrote:
> Elitism much? Let me read you 2.1.3, from the very same FAQ you
> quoted:
> 
> > The "first class" application of Gemini is human consumption of
> > predominantly written material - to facilitate something like
> > gopherspace, or like "reasonable webspace" (e.g. something which is
> > comfortably usable in Lynx or Dillo). But, just like HTTP can be,
> > and is, used for much, much more than serving HTML, Gemini should
> > be able to be used for as many other purposes as possible without
> > compromising the simplicity and privacy criteria above. This means
> > taking into account possible applications built around non-text
> > files and non-human clients.  
> 
> I'm not sure how you read this section, but it seems to me like the
> intent is to be able to serve large files if you can.

Indeed, no arguments here, however, large files typically wouldn't need
any caching, you download once and save to your disk, these include
ISOs, FLACs, JPEGs and so on.

And again:

> The "first class" application of Gemini is human consumption of
> predominantly written material

Written material in gemtext wouldn't need caching because it's a few
kilobytes.

> > Does everyone here require a lecture on why their desired features
> > aren't in the protocol yet? seems to be the common point of
> > discussion here, as if the protocol is NOT ENOUGH, I don't know
> > what brought your interest here, did you see it as a great way of
> > avoiding the current scope creep of the modern web, or as a
> > playground to satisfy your bad ideas?  
> 
> Again, your elitism is showing. I feel like adding a way to signal 
> whether or not you can safely cache a response isn't really
> sacrificing any of the Gemini ethos: simplicity, privacy, or
> generality.

If you consider keeping the core philosophy (what I suppose it should
be) from solutions to non-existent problems elitism, then have fun
comforting each other and entertaining bad design choices.

Once caching becomes standard, there's nothing stopping servers from
serving large content just because major client implementations will
cache it anyway, and this turns from optional to *if you don't support
it, your client is limited*, what next?

And I'm gonna say it again, if the protocol is centered around serving
plain text documents, why would caching be a concern? seems to me that
just invites extension and the possibility of generalizing the protocol
the same way HTTP went.

From raiz at stellarbound.space  Sun Nov  8 02:04:09 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 8 Nov 2020 05:04:09 +0300
Subject: Caching and status codes
In-Reply-To: <C6XCWFHU26R2.3JV3F81N8FZ5Y@rath>
References: <20201107194358.61b66e19@home>
 <C6XCWFHU26R2.3JV3F81N8FZ5Y@rath>
Message-ID: <20201108050409.5db9ab3f@home>

On Sun, 08 Nov 2020 00:41:10 +0300
"Leo" <list at gkbrk.com> wrote:
> This is the statement that bothered me because it seemed very weird to
> consider a client "rude" for not making requests. So I asked about it
> for clarification.

Because as of currently, there's no way to indicate if content is
dynamic or static.

> But here you are saying that the rude thing here is having to serve
> large files over gemini and expecting them to be served often. This
> would be the server being rude, and clients caching or not caching
> resources would not have an impact on how large a server's reponses
> are.
>
> If anything, it would result in less traffic and at least partially
> mitigate the issue. If your server is being _rude_ and sending large
> responses, my client is not gonna make it worse by requesting it every
> single time. Your server might have a lot of bandwidth, my client does
> not.

Gemini responses should typically be in the kilobytes range as they are
plain text, unless you're serving MP3s or ISOs which are saved to the
disk permanently, there's no point of having caching here.

> The protocol operates under the assumption that caching does not exist
> in order to make clients and servers simpler. A client adding caching
> would NOT affect a server negatively. If you consider caching clients
> to be rude clients, too bad, you will never notice them because
> instead of making extra requests, they are making less. I suppose you
> can ask them to apologise for not making you spend money on
> compute/bandwidth etc.

Again, the protocol by convention should not go in the direction of
bittorrent, plain text documents aren't large.

> Again, you are talking about making servers more complicated. If my
> client does not cache and your server sends large responses, this is
> indeed a problem and you might have to make your server more complex
> to handle it. Caching clients would make simpler server code
> possible, as performance tricks would not be necessary. But even
> ignoring that, a client that caches responses would not make your
> server more complex.

They won't take burden off the server, instead, they add more, now the
server have to tell the client which content to cache and which it
should not.

> So it is being sane when a server says "display this monstrous image"
> and the client refuses, but it is insane when the server says "please
> download this resource that you downloaded 3 seconds ago" and the
> client says "I'll just use the response I have cached"?

Resources are identified using URIs, that's all the client knows, how
does it know that the resource haven't been altered since the last time
it got accessed? the client could be showing an outdated document in
the case of dynamic content.

> The whole point of the discussion is that clients WILL cache
> resources. Gemini benefits a lot from having a wide range of
> different clients. You simply can't control everyone's use case to
> fit the way you think they should consume content.

Different use cases can be satisfied with different protocols.

> Just like some browsers/proxies cache HTTP and Gopher responses, some
> people who are bandwidth constrained or simply not wasteful will
> choose to cache their Gemini responses too. The discussion throws out
> the idea of client HINTS that will say "This might be a dynamic
> response, maybe don't cache it". Neither the server nor the client
> needs to take advantage of this, a client can always cache or never
> cache, and a server can expect everything to be cached or not cached.
> Just like before.

Again, there shouldn't be a point where caching is mandatory if plain
text documents are being served.

> Disagreeing with someone is one thing, but you don't have to attack
> them like this.

I'm sorry you feel offended.

> Before you shame other people, please enlighten us
> with the tangible value that you have provided to the greater Gemini
> community.

Not proposing solutions to non-existent problems.

> > If any feature does not add a great value at an acceptable cost to
> > the simplicity of the protocol, consider it rejected before even
> > proposing it, I don't want to have a different experience browsing
> > Gemini space using netcat than using Kristall.  
> 
> I agree with this completely.

Then there's nothing to discuss further.

From khuxkm at tilde.team  Sun Nov  8 04:33:26 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Sun, 08 Nov 2020 04:33:26 +0000
Subject: Caching and status codes
In-Reply-To: <20201107222315.0f596e83@home>
References: <20201107222315.0f596e83@home>
 <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
Message-ID: <34ef18e0125ed964e6a726c15d89fc47@tilde.team>

Just wanted to pop in:

November 7, 2020 8:15 PM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> On Sat, 7 Nov 2020 13:42:57 -0500
> John Cowan <cowan at ccil.org> wrote:
> 
> -snip-
> 
>> If you are browsing with netcat, caching is not even an issue. If
>> nobody wanted to serve dynamic content, 22 wouldn't be useful. It is
>> handy for those who do want to, to communicate their intent. No
>> client and no server has to implement this.
> 
> If 22 is explicit no caching response, how would 20 be redefined?

20 wouldn't be redefined. A status code of 20 would simply have no assumptions as to the cacheability of a resource (i.e; cache at your own risk). Meanwhile, 21 and 22 would be there for CGI, etc. that can return them.

Just my two cents,
Robert "khuxkm" Miles

From sean at conman.org  Sun Nov  8 05:18:44 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 8 Nov 2020 00:18:44 -0500
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
Message-ID: <20201108051844.GF30302@brevard.conman.org>

It was thus said that the Great khuxkm at tilde.team once stated:
> November 7, 2020 8:15 PM, "Ali Fardan" <raiz at stellarbound.space> wrote:
> > On Sat, 7 Nov 2020 13:42:57 -0500
> > John Cowan <cowan at ccil.org> wrote:
> > 
> >> If you are browsing with netcat, caching is not even an issue. If
> >> nobody wanted to serve dynamic content, 22 wouldn't be useful. It is
> >> handy for those who do want to, to communicate their intent. No
> >> client and no server has to implement this.
> > 
> > If 22 is explicit no caching response, how would 20 be redefined?
> 
> 20 wouldn't be redefined. A status code of 20 would simply have no
> assumptions as to the cacheability of a resource (i.e; cache at your own
> risk). Meanwhile, 21 and 22 would be there for CGI, etc. that can return
> them.

  Ah, clashing proposals!  How wonderful!

  In another thread, not at all related to caching, we have prisonpotato at
tilde.team who said:

> This seems like a neat solution to this problem to me, but I'm not sure if
> it would work at this stage of gemini's life cycle.  There are also of
> course the issues with dynamically sized responses as generated by CGI
> scripts and stuff like that, so maybe we could introduce a new response
> code, like 22: Response with size.
> 
> 20 text/gemini
> 22 100 text/gemini
> 
> This solves both problems by making content length optional again, but
> exposes a risk that this type of extension could be used to add more fields

(https://lists.orbitalfox.eu/archives/gemini/2020/003010.html)

and John Cowan, who said this in this thread:

> I agree, except that I am in favor of code 22 meaning "It is inadvisable
> to cache this", on the assumption that most Gemini documents are static
> and will continue to be so.  Even on the Web, most documents are static. 
> If there is to be just one new code, better it should be 22.  If people
> feel strongly about 21, then both 21 and 22.

  So, which is it?  Sizes?  Or caching?  Or I suppose we could all the
above:

	20	status, no size
	22	status, size
	21	cache, no size
	22	cache, size
	23	no-cache, no size
	24	no-cache, size

and before you know it:

	20	status, no size, no future feature
	22	status, size, no future feature
	21	cache, no size, no future feature
	22	cache, size, no future feature
	23	no-cache, no size, no future feature
	24	no-cache, size, no future feature

	25	status, no size, future feature
	26	status, size, future feature
	27	cache, no size, future feature
	28	cache, size, future feature
	29	no-cache, no size, future feature
	30	no-cache, size, future feature ... oh, wait a second ...

  We're done out of status codes and crashing into the next block.  It may
seem silly to worry about future feature now, but hey, the future comes
eventually.  Even *if* the size doesn't get its own status code, I think my
argument stands---features can mix, and if they can mix, the number of
status code explodes:

	20	status
	21	cache
	22	no-cache
	23	status, future feature 1
	24	cache, future feature 1
	25	no-cache, future feature 1
	26	status, no future feature 1, future feature 2
	27	cache, no future feature 1, future feature 2
	28	no-cache, no future feature 1, future feature 2
	29	status, future feature 1, future feature 2
	30	... uh oh ...

  I have my own ideas about caching, but I want to cobble up a
proof-of-concept first before I talk about it more, because from where I
come from, working code is worth more than talk.

  -spc

From khuxkm at tilde.team  Sun Nov  8 05:32:27 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Sun, 08 Nov 2020 05:32:27 +0000
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201108051844.GF30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
Message-ID: <6890ca83b3980a32a900371b7ebd710a@tilde.team>

November 8, 2020 12:18 AM, "Sean Conner" <sean at conman.org> wrote:

> It was thus said that the Great khuxkm at tilde.team once stated:
> 
>> November 7, 2020 8:15 PM, "Ali Fardan" <raiz at stellarbound.space> wrote:
>> On Sat, 7 Nov 2020 13:42:57 -0500
>> John Cowan <cowan at ccil.org> wrote:
>> 
>> If you are browsing with netcat, caching is not even an issue. If
>> nobody wanted to serve dynamic content, 22 wouldn't be useful. It is
>> handy for those who do want to, to communicate their intent. No
>> client and no server has to implement this.
>> 
>> If 22 is explicit no caching response, how would 20 be redefined?
>> 
>> 20 wouldn't be redefined. A status code of 20 would simply have no
>> assumptions as to the cacheability of a resource (i.e; cache at your own
>> risk). Meanwhile, 21 and 22 would be there for CGI, etc. that can return
>> them.
> 
> Ah, clashing proposals! How wonderful!
> 
> In another thread, not at all related to caching, we have prisonpotato at
> tilde.team who said:
> 
>> This seems like a neat solution to this problem to me, but I'm not sure if
>> it would work at this stage of gemini's life cycle. There are also of
>> course the issues with dynamically sized responses as generated by CGI
>> scripts and stuff like that, so maybe we could introduce a new response
>> code, like 22: Response with size.
>> 
>> 20 text/gemini
>> 22 100 text/gemini
>> 
>> This solves both problems by making content length optional again, but
>> exposes a risk that this type of extension could be used to add more fields
> 
> (https://lists.orbitalfox.eu/archives/gemini/2020/003010.html)
> 
> and John Cowan, who said this in this thread:
> 
>> I agree, except that I am in favor of code 22 meaning "It is inadvisable
>> to cache this", on the assumption that most Gemini documents are static
>> and will continue to be so. Even on the Web, most documents are static.
>> If there is to be just one new code, better it should be 22. If people
>> feel strongly about 21, then both 21 and 22.
> 
> So, which is it? Sizes? Or caching? Or I suppose we could all the
> above:
> 
> 20 status, no size
> 22 status, size
> 21 cache, no size
> 22 cache, size
> 23 no-cache, no size
> 24 no-cache, size
> 
> and before you know it:
> 
> 20 status, no size, no future feature
> 22 status, size, no future feature
> 21 cache, no size, no future feature
> 22 cache, size, no future feature
> 23 no-cache, no size, no future feature
> 24 no-cache, size, no future feature
> 
> 25 status, no size, future feature
> 26 status, size, future feature
> 27 cache, no size, future feature
> 28 cache, size, future feature
> 29 no-cache, no size, future feature
> 30 no-cache, size, future feature ... oh, wait a second ...
> 
> We're done out of status codes and crashing into the next block. It may
> seem silly to worry about future feature now, but hey, the future comes
> eventually. Even *if* the size doesn't get its own status code, I think my
> argument stands---features can mix, and if they can mix, the number of
> status code explodes:
> 
> 20 status
> 21 cache
> 22 no-cache
> 23 status, future feature 1
> 24 cache, future feature 1
> 25 no-cache, future feature 1
> 26 status, no future feature 1, future feature 2
> 27 cache, no future feature 1, future feature 2
> 28 no-cache, no future feature 1, future feature 2
> 29 status, future feature 1, future feature 2
> 30 ... uh oh ...
> 
> I have my own ideas about caching, but I want to cobble up a
> proof-of-concept first before I talk about it more, because from where I
> come from, working code is worth more than talk.
> 
> -spc

This can't happen, though, because the first proposal breaks the compatibility of <META> in response codes within a block, and the second one is just debating which of the codes we should add.

Cache/no-cache would be 2 (at most) response codes. That's all.

I'm also going to try and put together some basic code to demonstrate how I think this should work. Maybe, then, it'll be a bit clearer.

Just my two cents,
Robert "khuxkm" Miles

From sean at conman.org  Sun Nov  8 05:50:18 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 8 Nov 2020 00:50:18 -0500
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <6890ca83b3980a32a900371b7ebd710a@tilde.team>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
Message-ID: <20201108055017.GG30302@brevard.conman.org>

It was thus said that the Great khuxkm at tilde.team once stated:
> 
> This can't happen, though, because the first proposal breaks the
> compatibility of <META> in response codes within a block, and the second
> one is just debating which of the codes we should add.

  This *did* happen, back on November 3rd.  

	https://lists.orbitalfox.eu/archives/gemini/2020/003015.html

  And it's already received over a hundred hits.

> Cache/no-cache would be 2 (at most) response codes. That's all.

  And my argument, even with the size response code removed, can *still*
lead to a combinatoric explosion of response codes.  Today it's just *two*,
but what about tomorrow?

  -spc



From zachdecook at librem.one  Sun Nov  8 05:52:11 2020
From: zachdecook at librem.one (Zach DeCook)
Date: Sun, 08 Nov 2020 00:52:11 -0500
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <20201108051844.GF30302@brevard.conman.org>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
Message-ID: <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one>

>We're done out of status codes and crashing into the next block.  It
>may
>seem silly to worry about future feature now, but hey, the future comes
>eventually.  Even *if* the size doesn't get its own status code, I
>think my
>argument stands---features can mix, and if they can mix, the number of
>status code explodes:

>  from where
>I
>come from, working code is worth more than talk.

I think there's still a long way for gemini clients to come before demanding the Future Inevitable Feature. Like, the more thought that goes into this, the less likely we'll run out of status codes.
One way a client could implement caching is by loading the cached version of a page, and telling the user when it was downloaded, next to a 'refresh' button. A gemini client could even offer a diff view between the current page and the cached copy. All of that *empowers the users* over the servers, and doesn't rely on adding anything to the spec.
A "please don't cache" response code would be (ab)used by servers who desire to track their users.
-Zach

From smallick.dev at gmail.com  Sun Nov  8 05:59:09 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Sun, 8 Nov 2020 11:29:09 +0530
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <6890ca83b3980a32a900371b7ebd710a@tilde.team>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
Message-ID: <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>

This is what I *think* how *should* clients work with caching:

The clients with history support and supports going ''backwards'' and
''forwards'' through history should cache text/* responses in memory
for that browsing session. When the user browses through the history
using ''forward'' and ''backward'' action, no reloading should happen.
But, when a user clicks the link for a resource already in cache or
writes the link by hand or selects the link from previously visited
links or asks for reload: the cache is purged and the resource
reloaded. It is assumed that requests with query part are idempotent.
Now, when a page is dynamic, it should be stated as such so that the
user would reload that page.
With that, no new response codes.

~smlckz

From zachdecook at librem.one  Sun Nov  8 06:08:19 2020
From: zachdecook at librem.one (Zach DeCook)
Date: Sun, 08 Nov 2020 01:08:19 -0500
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
Message-ID: <57BBA5F4-C3E8-4B5F-A445-683669467F10@librem.one>

On November 8, 2020 12:59:09 AM EST, Sudipto Mallick <smallick.dev at gmail.com> wrote:
>It is assumed that requests with query part ...

That client-implementation could lead to strange uses of the query part...
But if it's a result of a 10 or 11 response, it would make sense to make the request fresh.
mbays at sdf.org is right, the user should be in control.
A caching client could simply split links to cached resources into two parts: clicking one part would pull the cached version, clicking the other would make a new request.
-Zach

From khuxkm at tilde.team  Sun Nov  8 06:14:02 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Sun, 08 Nov 2020 06:14:02 +0000
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one>
References: <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
Message-ID: <2ca928d7d9778006fd780a595315aef2@tilde.team>

November 8, 2020 12:52 AM, "Zach DeCook" <zachdecook at librem.one> wrote:

>> We're done out of status codes and crashing into the next block. It
>> may
>> seem silly to worry about future feature now, but hey, the future comes
>> eventually. Even *if* the size doesn't get its own status code, I
>> think my
>> argument stands---features can mix, and if they can mix, the number of
>> status code explodes:
>> 
>> from where
>> I
>> come from, working code is worth more than talk.
> 
> I think there's still a long way for gemini clients to come before demanding the Future Inevitable
> Feature. Like, the more thought that goes into this, the less likely we'll run out of status codes.
> One way a client could implement caching is by loading the cached version of a page, and telling
> the user when it was downloaded, next to a 'refresh' button. A gemini client could even offer a
> diff view between the current page and the cached copy. All of that *empowers the users* over the
> servers, and doesn't rely on adding anything to the spec.
> A "please don't cache" response code would be (ab)used by servers who desire to track their users.
> -Zach

Again, clients are free to ignore the "do not cache" response code as they wish. It would be considered bad form, and it may confuse the everloving hell out of somebody who's requesting a random picture and keeps getting the same one, but you're free to do it, just as you're free to cache any response now.

Just my two cents,
Robert "khuxkm" Miles

(PS: still working on that implementation)

From khuxkm at tilde.team  Sun Nov  8 06:29:01 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Sun, 08 Nov 2020 06:29:01 +0000
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201108051844.GF30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
Message-ID: <954134263ab38c016102dca4efcb04d6@tilde.team>

November 8, 2020 12:18 AM, "Sean Conner" <sean at conman.org> wrote:

> I have my own ideas about caching, but I want to cobble up a
> proof-of-concept first before I talk about it more, because from where I
> come from, working code is worth more than talk.
> 
> -spc

Speaking of cobbling up proof-of-concepts, I've created a proof-of-concept of how I feel these cache-hint success codes would work:

https://gist.github.com/febd3f5ae2308e8b55449a92c6e58a65

(Yes, I know it's on GitHub, but I have a shell script to make Gists from the command line and so I want to use it.)

This includes a spartan client (it literally just spits the raw protocol response out at you) with caching behavior influenced by 21/22 (in practice, it caches all 2x responses except for 22 responses), as well as examples of endpoints to hit that return each code.

Hopefully my working code will prove my point better than I could in words.

Just my two cents,
Robert "khuxkm" Miles

From sean at conman.org  Sun Nov  8 07:49:46 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 8 Nov 2020 02:49:46 -0500
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <954134263ab38c016102dca4efcb04d6@tilde.team>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <954134263ab38c016102dca4efcb04d6@tilde.team>
Message-ID: <20201108074946.GH30302@brevard.conman.org>

It was thus said that the Great khuxkm at tilde.team once stated:
> November 8, 2020 12:18 AM, "Sean Conner" <sean at conman.org> wrote:
> 
> > I have my own ideas about caching, but I want to cobble up a
> > proof-of-concept first before I talk about it more, because from where I
> > come from, working code is worth more than talk.
> > 
> > -spc
> 
> Speaking of cobbling up proof-of-concepts, I've created a proof-of-concept
> of how I feel these cache-hint success codes would work:
> 
> https://gist.github.com/febd3f5ae2308e8b55449a92c6e58a65
> 
> (Yes, I know it's on GitHub, but I have a shell script to make Gists from
> the command line and so I want to use it.)
> 
> This includes a spartan client (it literally just spits the raw protocol
> response out at you) with caching behavior influenced by 21/22 (in
> practice, it caches all 2x responses except for 22 responses), as well as
> examples of endpoints to hit that return each code.
> 
> Hopefully my working code will prove my point better than I could in words.

  And I have my "proof-of-concept" up at well.  It's at

	gemini://gemini.conman.org/test/testcache.gemini

  My approach is a bit different, probably a bit harder to implement server
side, but deals not only with the caching issue, but with repeated requests. 
I'm not sure how popular it will be, but hey, it's out there, and it only
adds one general purpose status code (23 for now) that means:

	okay, request was okay, but there is no data to serve you.

  How it works:  A plain request:

	gemini://gemini.conman.org/test/cachefile.txt

will always return the content.  However, if you include a timestamp using a
path parameter (which is *NOT* the same as a query paramter, and is in the
ISO-8601 format):

	gemini://gemini.conman.org/test/cachefile.txt;2020-11-08T00:00:00

If the file is *newer* than that timestamp, you get the normal response of
20 and all the content; otherwise you get a response of 23 (with the normal
MIME type) and no content, meaning it hasn't changed since the given date.

  This means a client that doesn't with to deal with caching at all will
never see any difference.  A client that does, or (in the case of feeds) not
want to always download content that hasn't changed, can do that as well.

  -spc


From boringcactus at gmail.com  Sun Nov  8 08:17:02 2020
From: boringcactus at gmail.com (boringcactus)
Date: Sun, 8 Nov 2020 01:17:02 -0700
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201108074946.GH30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <954134263ab38c016102dca4efcb04d6@tilde.team>
 <20201108074946.GH30302@brevard.conman.org>
Message-ID: <fa57d8c4-e277-7927-80e6-c12363611ef2@gmail.com>

On 2020-11-08 12:49 AM, Sean Conner wrote:
>    My approach is a bit different, probably a bit harder to implement server
> side, but deals not only with the caching issue, but with repeated requests.
> I'm not sure how popular it will be, but hey, it's out there, and it only
> adds one general purpose status code (23 for now) that means:
> 
> 	okay, request was okay, but there is no data to serve you.
You could get a similar effect with 44 SLOW DOWN as it already exists, 
and boom, now the protocol doesn't need to know about caching at all.

From linde.philip at gmail.com  Sun Nov  8 11:26:58 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sun, 8 Nov 2020 12:26:58 +0100
Subject: Adding close_notify to the spec ?
In-Reply-To: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>
References: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>
Message-ID: <20201108122658.ffb1063807940d688d8102f7@gmail.com>

On Sat, 7 Nov 2020 19:20:21 -0600
Scot <gmi1 at scotdoyle.com> wrote:

> Does anyone have any concerns about amending the spec to state that a TLS
> close_notify message should be sent before closing the TCP connection?
> While TLS guarantees the integrity of the data from the server, it does
> not guarantee completeness until a close_notify is received by the client.
> Interested and able clients could then determine that they received a
> complete response.

A close_notify alert "MUST" be sent prior to closing the write side
of the connection in both TLS 1.2 and 1.3. I should think it's
redundant to mention this in the Gemini spec since it's already
required by the TLS specs, but the number of servers that don't
implement TLS properly is alarmingly high, so maybe a reminder is
necessary.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/01ddd6da/attachment-0001.sig>

From linde.philip at gmail.com  Sun Nov  8 12:40:14 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sun, 8 Nov 2020 13:40:14 +0100
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201108055017.GG30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <20201108055017.GG30302@brevard.conman.org>
Message-ID: <20201108134014.81668d09abe353de20010f8c@gmail.com>

On Sun, 8 Nov 2020 00:50:18 -0500
Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great khuxkm at tilde.team once stated:
> > 
> > This can't happen, though, because the first proposal breaks the
> > compatibility of <META> in response codes within a block, and the second
> > one is just debating which of the codes we should add.
> 
>   This *did* happen, back on November 3rd.  
> 
> 	https://lists.orbitalfox.eu/archives/gemini/2020/003015.html
> 
>   And it's already received over a hundred hits.

You're mistaking the sense in which khuxkm is saying that it can't
happen. It did happen in the sense that you implemented a server for a
protocol that works like this.

It can't happen in the sense that it fundamentally breaks compatibility
with clients that only concern themselves with the first digit of the
response code. That you've implemented the resulting protocol of your
suggested change has no bearing on the argument.

The overflowing of 2x code resulting from a combinatorial hell is
entirely self-inflicted through your choice to ignore this aspect of
the existing specification.

I've already suggested to you a way to avoid this (use a different
first digit). This additionally avoids having to rewrite 3.2 of the
spec and invalidate existing clients that take for granted that "the
first digit alone provides enough information for a client to determine
how to handle the response".

Moreover, with TLS already having a mechanism to signal the intended
end of a connection, I don't think that content size is a pressing
issue. It would allow for download progress bars, but adds nothing
over TLS in terms of ensuring that the content is fully received.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/213ba640/attachment.sig>

From raiz at stellarbound.space  Sun Nov  8 15:44:13 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 8 Nov 2020 18:44:13 +0300
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
Message-ID: <20201108184330.1e24339f@home>

On Sun, 8 Nov 2020 11:29:09 +0530
Sudipto Mallick <smallick.dev at gmail.com> wrote:
> This is what I *think* how *should* clients work with caching:
> 
> The clients with history support and supports going ''backwards'' and
> ''forwards'' through history should cache text/* responses in memory
> for that browsing session. When the user browses through the history
> using ''forward'' and ''backward'' action, no reloading should happen.
> But, when a user clicks the link for a resource already in cache or
> writes the link by hand or selects the link from previously visited
> links or asks for reload: the cache is purged and the resource
> reloaded. It is assumed that requests with query part are idempotent.
> Now, when a page is dynamic, it should be stated as such so that the
> user would reload that page.
> With that, no new response codes.


This is the creativity I like to see when dealing with limited
environments, this is a solution that requires no change in the
protocol, if a client developer feels the urge to have caching which I
still don't understand why it should be necessary for Gemini. (everybody
refused to give me an answer)

Great solution, but I doubt anyone would listen to you considering the
current climate of discussion being focused heavily on adding more.

From alex at nytpu.com  Sun Nov  8 16:13:18 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Sun, 8 Nov 2020 09:13:18 -0700
Subject: [ANN] Project Gemini Gemini Archive
Message-ID: <20201108161318.s5qejbemesjiddx7@GLaDOS>

Hey everybody,

I've set up an archive about Project Gemini (the space program). So far
I've ported Virtual AGC's technical write-up of the Gemini On-Board
Computer to gemtext and am mirroring a selection of images, documents,
and software. I'm also going to add some Mercury and Apollo stuff in the
future once I get the Gemini archive to my satisfaction.

The archive is accessible here:
gemini://nytpu.com/geminiarchive/

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/2445da34/attachment.sig>

From tomasino at lavabit.com  Sun Nov  8 16:21:03 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Sun, 8 Nov 2020 16:21:03 +0000
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201108184330.1e24339f@home>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
 <20201108184330.1e24339f@home>
Message-ID: <d7c4231c-8d17-c134-6fa0-28e737ca78ed@lavabit.com>

On 11/8/20 3:44 PM, Ali Fardan wrote:
> if a client developer feels the urge to have caching which I
> still don't understand why it should be necessary for Gemini. (everybody
> refused to give me an answer)

I'm not 100% sure if it requires caching or not, but what I would want from a client with a back button is to take me back to where I was in the document's scroll position before I clicked. Some clients are already handling this use case (hooray!). This may be a greater concern for graphical clients than text ones, unless the client is handling paging itself. Losing your place can be frustrating when moving through a series of inter-linked documents. Imagine going through older CAPCOM articles, for instance. Every time you click back needing to scroll back down to wherever you were becomes obnoxious and a reason to just stop. 

Again, I'm not sure if caching is involved in it or not, but that's the best thing I could come up with as an answer to your question.


From raiz at stellarbound.space  Sun Nov  8 16:27:48 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 8 Nov 2020 19:27:48 +0300
Subject: [ANN] Project Gemini Gemini Archive
In-Reply-To: <20201108161318.s5qejbemesjiddx7@GLaDOS>
References: <20201108161318.s5qejbemesjiddx7@GLaDOS>
Message-ID: <20201108192748.4462f300@home>

On Sun, 8 Nov 2020 09:13:18 -0700
Alex // nytpu <alex at nytpu.com> wrote:
> Hey everybody,
> 
> I've set up an archive about Project Gemini (the space program). So
> far I've ported Virtual AGC's technical write-up of the Gemini
> On-Board Computer to gemtext and am mirroring a selection of images,
> documents, and software. I'm also going to add some Mercury and
> Apollo stuff in the future once I get the Gemini archive to my
> satisfaction.
> 
> The archive is accessible here:
> gemini://nytpu.com/geminiarchive/
> 

Amazing work, I really like how you did the tables there in the
document.

From raiz at stellarbound.space  Sun Nov  8 16:31:21 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 8 Nov 2020 19:31:21 +0300
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <d7c4231c-8d17-c134-6fa0-28e737ca78ed@lavabit.com>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
 <20201108184330.1e24339f@home>
 <d7c4231c-8d17-c134-6fa0-28e737ca78ed@lavabit.com>
Message-ID: <20201108193121.6a5af8a8@home>

On Sun, 8 Nov 2020 16:21:03 +0000
James Tomasino <tomasino at lavabit.com> wrote:
> Again, I'm not sure if caching is involved in it or not, but that's
> the best thing I could come up with as an answer to your question.

This can be done by remembering the offset percentage-wise in the
client for each previous page, however, this could be broken if caching
wasn't involved in case document changes meanwhile, if this is a
compelling reason to have caching, I'd suggest Mallick's method, as it
won't involve any changes to the protocol and it fits the context very
well.

From jordan at crowesnest.io  Sun Nov  8 16:44:26 2020
From: jordan at crowesnest.io (Jordan)
Date: Sun, 08 Nov 2020 16:44:26 +0000
Subject: [ANN] Project Gemini Gemini Archive
In-Reply-To: <20201108161318.s5qejbemesjiddx7@GLaDOS>
References: <20201108161318.s5qejbemesjiddx7@GLaDOS>
Message-ID: <s12STkjOr1A3G1ixIVP6vpz9bzd9vJ2tkDnt1b0yNwQ@cp3-web-021.plabs.ch>

That is pretty cool, thanks for the work you're putting into it!


From smallick.dev at gmail.com  Sun Nov  8 17:20:10 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Sun, 8 Nov 2020 22:50:10 +0530
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <d7c4231c-8d17-c134-6fa0-28e737ca78ed@lavabit.com>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
 <20201108184330.1e24339f@home>
 <d7c4231c-8d17-c134-6fa0-28e737ca78ed@lavabit.com>
Message-ID: <CAFaUHvLeOC95ren8uqFAvc=u1E-G_=LK36_G9TogxQXhnq-ngQ@mail.gmail.com>

On 11/8/20, James Tomasino <tomasino at lavabit.com> wrote:
> I'm not 100% sure if it requires caching or not, but what I would want from
> a client with a back button is to take me back to where I was in the
> document's scroll position before I clicked. Some clients are already
> handling this use case (hooray!). This may be a greater concern for
> graphical clients than text ones, unless the client is handling paging
> itself. Losing your place can be frustrating when moving through a series of
> inter-linked documents. Imagine going through older CAPCOM articles, for
> instance. Every time you click back needing to scroll back down to wherever
> you were becomes obnoxious and a reason to just stop.

Now in that case, if the client does not cache, the page is reloaded.
Even if the client remembers the position where you were before in
that page, imagine the scenario where the page gets changed before
reloading (say, new links added to (or removed in) that page), then
you have to scroll anyway. (In the worst case, imagine the link you
clicked does not exist in the new page.)

> Again, I'm not sure if caching is involved in it or not, but that's the best
> thing I could come up with as an answer to your question.
So caching is required. Your client must keep that page in cache along
with your last position in that page for the feature you want.
~smlckz

From waweic at protonmail.com  Sun Nov  8 17:21:17 2020
From: waweic at protonmail.com (Waweic)
Date: Sun, 08 Nov 2020 17:21:17 +0000
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <20201108184330.1e24339f@home>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
 <20201108184330.1e24339f@home>
Message-ID: <WgHeEaJAI01eWTvynpG66u0ULt969sgzlEe63M8RS2SrHdnciLx_AiTjexXm5CL_lOTzoweeu44TnDspa9elrXPOaJccVus12enu_A6KCPA=@protonmail.com>

> This is the creativity I like to see when dealing with limited
> environments, this is a solution that requires no change in the
> protocol, if a client developer feels the urge to have caching which I
> still don't understand why it should be necessary for Gemini. (everybody
> refused to give me an answer)
>
> Great solution, but I doubt anyone would listen to you considering the
> current climate of discussion being focused heavily on adding more.

I really like this approach, as I like the protocol as-is. I am currently working on a client for Android, and I am planning to make heavy use of caching, although I do not think a change in the protocol is necessary. In my usecase, I have a dataplan that's free, but just gives me flaky 32kbit/s at best, usually far less. (It's called "messaging option"). Loading a page on Gemini usually takes multiple seconds. This would be similar for packet radio and similar applications. Without caching, this is a huge PITA. I will take care to have a "Reload" button once I use caching, so the users themselves can decide when new content should be fetched.

I want to stress that caching is neccessary in my usecase. It's a much more needed feature than, say, client certificate support. At the moment, the majority of Content on Gemini is static and I believe it will continue to be.

- Waweic

From raiz at stellarbound.space  Sun Nov  8 17:26:46 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 8 Nov 2020 20:26:46 +0300
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <WgHeEaJAI01eWTvynpG66u0ULt969sgzlEe63M8RS2SrHdnciLx_AiTjexXm5CL_lOTzoweeu44TnDspa9elrXPOaJccVus12enu_A6KCPA=@protonmail.com>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
 <20201108184330.1e24339f@home>
 <WgHeEaJAI01eWTvynpG66u0ULt969sgzlEe63M8RS2SrHdnciLx_AiTjexXm5CL_lOTzoweeu44TnDspa9elrXPOaJccVus12enu_A6KCPA=@protonmail.com>
Message-ID: <20201108202646.7fea965c@home>

On Sun, 08 Nov 2020 17:21:17 +0000
Waweic <waweic at protonmail.com> wrote:
> I really like this approach, as I like the protocol as-is.

Wonderful.

> I want to stress that caching is neccessary in my usecase. It's a
> much more needed feature than, say, client certificate support. At
> the moment, the majority of Content on Gemini is static and I believe
> it will continue to be.

Go for it.

From justin at abrah.ms  Sun Nov  8 19:17:27 2020
From: justin at abrah.ms (Justin Abrahms)
Date: Sun, 08 Nov 2020 11:17:27 -0800
Subject: org-mode export to gemini
Message-ID: <8085cce1-ff2d-4d5b-bca9-0d08f9c65dfa@www.fastmail.com>

Hey all.

I've just created a utility which hooks into emacs's org-mode to publish gemini sites. My own gemini site at gemini://sunshinegardens.org/~abrahms/ is built with it. 

Would love for folks to shoot me feedback and bug reports if you find things.

https://git.sr.ht/~abrahms/ox-gemini

Thanks!
  - abrahms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/83bc645c/attachment.htm>

From sir at cmpwn.com  Sun Nov  8 19:18:25 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sun, 08 Nov 2020 15:18:25 -0400
Subject: Gemini to Hacker News portal
Message-ID: <C6Y4HOO0042G.3JQHVZT6RMVTL@taiga>

It also includes an HTML to Gemtext converter which works surprisingly
well, and which I will probably expand into a general purpose
Gemini-to-web portal in the future.

The portal:

gemini://drewdevault.com/cgi-bin/hn.py

A blog post explaining the implementation:

gemini://drewdevault.com/2020/11/08/HN-over-Gemini.gmi

Enjoy.

From carsten at strotmann.de  Sun Nov  8 19:22:29 2020
From: carsten at strotmann.de (Carsten Strotmann)
Date: Sun, 08 Nov 2020 20:22:29 +0100
Subject: org-mode export to gemini
In-Reply-To: <8085cce1-ff2d-4d5b-bca9-0d08f9c65dfa@www.fastmail.com>
References: <8085cce1-ff2d-4d5b-bca9-0d08f9c65dfa@www.fastmail.com>
Message-ID: <8C4B3E7E-66DB-4F2C-9EDB-C4C4D5E7C4B4@strotmann.de>

Hi Justin,

On 8 Nov 2020, at 20:17, Justin Abrahms wrote:

> Hey all.
>
> I've just created a utility which hooks into emacs's org-mode to 
> publish gemini sites. My own gemini site at 
> gemini://sunshinegardens.org/~abrahms/ is built with it.
>
> Would love for folks to shoot me feedback and bug reports if you find 
> things.
>
> https://git.sr.ht/~abrahms/ox-gemini
>

this is really great. Thank you for this work.

I will test-drive and report.

Greetings

Carsten

From sean at conman.org  Sun Nov  8 22:22:56 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 8 Nov 2020 17:22:56 -0500
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <20201108134014.81668d09abe353de20010f8c@gmail.com>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <20201108055017.GG30302@brevard.conman.org>
 <20201108134014.81668d09abe353de20010f8c@gmail.com>
Message-ID: <20201108222256.GI30302@brevard.conman.org>

It was thus said that the Great Philip Linde once stated:
> 
> The overflowing of 2x code resulting from a combinatorial hell is
> entirely self-inflicted through your choice to ignore this aspect of
> the existing specification.

  I don't agree that this is self-inflicted on me---what I'm trying (and
failing) to point out is that adding mroe success calls *could* lead to 
combinatorial hell.  HTTP already has 10 success codes in the 200 range, and
none of them relate to caching status (since caching status is passed along 
in headers).  Granted, none of the HTTP success statuses (with the exception
of 200, which is mapped to 20 in Gemini) apply to Gemini, but in another
universe where HTTP *did* have separate success code for caching
information, I can see some combinatoric increase, say for 204, 205 and 206
with nothing said, cache and no-caching of results (that's nine new ones   
right there).

> I've already suggested to you a way to avoid this (use a different 
> first digit). 

  No, that was to prisonpotato at tilde.team---they were the first to come up
with the idea, not me.  I just implemented it first (much the same way I
implemented the first Gemini server even before solderpunk did [1]).  Also,
the size breaking code is only active on one link on my site, not everwhere.

> This additionally avoids having to rewrite 3.2 of the
> spec and invalidate existing clients that take for granted that "the   
> first digit alone provides enough information for a client to determine
> how to handle the response".
> 
> Moreover, with TLS already having a mechanism to signal the intended
> end of a connection, I don't think that content size is a pressing
> issue. It would allow for download progress bars, but adds nothing
> over TLS in terms of ensuring that the content is fully received.

  The concern is over large responses.  It wasn't much of a concern until
gemini://konpeito.media/ was created and serving up large audio files (and
archives of said audio files).  I can envision a client being configured to
abort the download if say, a 10 megabyte file is being downloaded.  It
*sucked* when my DSL went down in late September/early October (yes, about
three weeks) and I had to rely upon my cellphone hot spot.  I didn't have a
large data plan for the cell phone becuase I didn't need it, until I did. 
It would have been nice to configure my web browser to not download anything
over 5M at that point.

  -spc

[1]     I did it completely ignoring the status codes defined at the time,
        because I felt they were too limiting (single digit).  It took some
        back and forth, along with a few other implementations (that did
        follow the spec), before the current two-digit scheme was defined.

From luke at marmaladefoo.com  Sun Nov  8 23:37:16 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 08 Nov 2020 23:37:16 +0000
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201108222256.GI30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <20201108055017.GG30302@brevard.conman.org>
 <20201108134014.81668d09abe353de20010f8c@gmail.com>
 <20201108222256.GI30302@brevard.conman.org>
Message-ID: <5FA8812C.8080504@marmaladefoo.com>

On 08-Nov-2020 22:22, Sean Conner wrote:
>
>   The concern is over large responses.  It wasn't much of a concern until
> gemini://konpeito.media/ was created and serving up large audio files (and
> archives of said audio files).  I can envision a client being configured to
> abort the download if say, a 10 megabyte file is being downloaded.  It
> *sucked* when my DSL went down in late September/early October (yes, about
> three weeks) and I had to rely upon my cellphone hot spot.  I didn't have a
> large data plan for the cell phone becuase I didn't need it, until I did.
> It would have been nice to configure my web browser to not download anything
> over 5M at that point.

(At the risk of wading into this thread - I should know better)

Yes that is a sensible client design IMO, since you cannot know how long 
to wait. In my client GemiNaut (Windows only atm sorry folks), there are 
two options:

  - abandon download after X Mb or after Y seconds

The gemget client/utility also implements this approach, which is what 
GemiNaut uses under the hood.

The values are tunable according to the desires of the user. Mostly I 
have mine set to 5mb or 10 seconds. If something times out beyond that I 
make a judgement whether I really want to up the threshold temporarily 
to let it through. Or maybe go look elsewhere ;)

By and large tex/gemini content is very small and fast which is one of 
its great selling points. Other binary files are more "meh".

  - Luke

From me at adnano.co  Mon Nov  9 01:26:36 2020
From: me at adnano.co (Adnan Maolood)
Date: Sun, 08 Nov 2020 20:26:36 -0500
Subject: [ANN] astronaut - a Gemini browser for the terminal
Message-ID: <C6YCBL66BJJL.3RAY048IO3RGK@nitro>

I've been working on a Gemini client for the terminal:

https://sr.ht/~adnano/astronaut

It has tabs, mouse support, and support for custom user styles.

It also passes all of the torture tests (except 0050, which causes
unicode artifacts for some reason).

There's still a lot of work to be done, including client certificate
management, bookmarks, custom key bindings, and some documentation.

Enjoy!

From sean at conman.org  Mon Nov  9 01:48:29 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 8 Nov 2020 20:48:29 -0500
Subject: [ANN] astronaut - a Gemini browser for the terminal
In-Reply-To: <C6YCBL66BJJL.3RAY048IO3RGK@nitro>
References: <C6YCBL66BJJL.3RAY048IO3RGK@nitro>
Message-ID: <20201109014829.GK30302@brevard.conman.org>

It was thus said that the Great Adnan Maolood once stated:
> I've been working on a Gemini client for the terminal:
> 
> https://sr.ht/~adnano/astronaut
> 
> It has tabs, mouse support, and support for custom user styles.
> 
> It also passes all of the torture tests (except 0050, which causes
> unicode artifacts for some reason).

  The title for that particular test is "Format-long line with UTF-8 with
conbining chars and soft-hypen" so it could be your terminal is having
issues with combining characters.  It's about the worst (if not the worst)
case scenario for supporting Unicode.

  -spc


From zach at anemon.es  Mon Nov  9 01:49:37 2020
From: zach at anemon.es (=?utf-8?B?WmFjaCDimIHvuI4=?=)
Date: Sun, 8 Nov 2020 17:49:37 -0800
Subject: more juicy gemini content to marinate your brain
Message-ID: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>

Hi

//e-worm.club is now on gemini

It?s mostly an aggressively unpolished look into the minds of hot twenty-somethings living rent free in the strangely vibrant hollow shell that is 2020 San Francisco.

Also there are some good critiques of ?progressive? software buried in there, but I?ll let you find those on your own.

xoxo
Zach

PS: feel free to email me / any of us in response to any of the writings? I refuse to take the time to aggregate server logs, so it?s the only way we have of knowing whether anyone reads our stuff

From cowan at ccil.org  Mon Nov  9 01:49:45 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 8 Nov 2020 20:49:45 -0500
Subject: [ANN] astronaut - a Gemini browser for the terminal
In-Reply-To: <20201109014829.GK30302@brevard.conman.org>
References: <C6YCBL66BJJL.3RAY048IO3RGK@nitro>
 <20201109014829.GK30302@brevard.conman.org>
Message-ID: <CAD2gp_STkfZvjwCqnOcWLsanxRS7_EN5zCbuU3Jad5uW8Pmj2g@mail.gmail.com>

There's always traditional Mongolian script, which is written top-to-bottom
starting at the right side of the page and working towards the left side.

:-)

On Sun, Nov 8, 2020 at 8:48 PM Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great Adnan Maolood once stated:
> > I've been working on a Gemini client for the terminal:
> >
> > https://sr.ht/~adnano/astronaut
> >
> > It has tabs, mouse support, and support for custom user styles.
> >
> > It also passes all of the torture tests (except 0050, which causes
> > unicode artifacts for some reason).
>
>   The title for that particular test is "Format-long line with UTF-8 with
> conbining chars and soft-hypen" so it could be your terminal is having
> issues with combining characters.  It's about the worst (if not the worst)
> case scenario for supporting Unicode.
>
>   -spc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/1bcf4f1d/attachment.htm>

From bie at 202x.moe  Mon Nov  9 02:22:47 2020
From: bie at 202x.moe (bie)
Date: Mon, 9 Nov 2020 11:22:47 +0900
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <WgHeEaJAI01eWTvynpG66u0ULt969sgzlEe63M8RS2SrHdnciLx_AiTjexXm5CL_lOTzoweeu44TnDspa9elrXPOaJccVus12enu_A6KCPA=@protonmail.com>
References: <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
 <20201108184330.1e24339f@home>
 <WgHeEaJAI01eWTvynpG66u0ULt969sgzlEe63M8RS2SrHdnciLx_AiTjexXm5CL_lOTzoweeu44TnDspa9elrXPOaJccVus12enu_A6KCPA=@protonmail.com>
Message-ID: <20201109022247.GA69919@202x.moe>

On Sun, Nov 08, 2020 at 05:21:17PM +0000, Waweic wrote:
> I really like this approach, as I like the protocol as-is. I am currently working on a client for Android, and I am planning to make heavy use of caching, although I do not think a change in the protocol is necessary. In my usecase, I have a dataplan that's free, but just gives me flaky 32kbit/s at best, usually far less. (It's called "messaging option"). Loading a page on Gemini usually takes multiple seconds. This would be similar for packet radio and similar applications. Without caching, this is a huge PITA. I will take care to have a "Reload" button once I use caching, so the users themselves can decide when new content should be fetched.
> 
> I want to stress that caching is neccessary in my usecase. It's a much more needed feature than, say, client certificate support. At the moment, the majority of Content on Gemini is static and I believe it will continue to be.

I should add that in cases where there's an actual need for caching like
this, caching is totally fine by me, but I hope you can find a way to
add some kind of indicator to make it clear to the user whether you're
showing fresh or cached content!

bie

From cowan at ccil.org  Mon Nov  9 04:41:06 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 8 Nov 2020 23:41:06 -0500
Subject: [ANN] twins, a Gemini server written in Go
In-Reply-To: <20201107051729.GD30302@brevard.conman.org>
References: <1c220a89213393c9fa02dd2c1b5a245e@rocketnine.space>
 <r-YXIDM_iC27leRmYytmmgNb7iGcgu_T23MITK1oiNGeN94X1W42gWepk4pcUt97w610uumNBG7YR3JW23TfX35Xbhpq2uu6v2Ee0w8mvvY=@protonmail.com>
 <20201107051729.GD30302@brevard.conman.org>
Message-ID: <CAD2gp_Qd+QXUxUDY4g3dz5uH2BpPMBrZCSRkfV+emCeK=6ozgQ@mail.gmail.com>

On Sat, Nov 7, 2020 at 12:17 AM Sean Conner <sean at conman.org> wrote:

So what are the standard MIME parameters for text/plain?


If you go to <https://www.iana.org/assignments/media-types/media-types.xhtml>,
the IANA registration for MIME-types, you'll find links under text/plain to
RFCs 2046 (optional charset parameter), 3676 (optional format and delsp
parameters), and 5147 (not sure why it's here; no parameters).

text/markdown?
>

The same process gets you to RFC 7763 (mandatory charset, optional variant).

text/html?


Charset (optional).

> multipart/alternate?


Boundary (required)

> And what should a client do when it
> encounters a non-standard MIME parameter?
>

Ah.  Now that's from RFC 2045:

   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content.  The set of
   meaningful parameters depends on the media type and subtype.  Most
   parameters are associated with a single specific subtype.  However, a
   given top-level media type may define parameters which are applicable
   to any subtype of that type.  Parameters may be required by their
   defining media type or subtype or they may be optional.  MIME
   implementations must also ignore any parameters whose names they do
   not recognize.

The last sentence is the critical one.  Add any parameters you want,
because clients must ignore them.

As for parsing, per RFC 2045 just use split() to split by semicolons; the
first result is the type/subtype, and on each of the rest, strip out all
spaces and then split them on the equal sign to separate name from value.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Do what you will / this Life's a Fiction
And is made up of / Contradiction.  --William Blake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/6d29b6f6/attachment.htm>

From jordan at crowesnest.io  Mon Nov  9 05:39:42 2020
From: jordan at crowesnest.io (Jordan)
Date: Mon, 09 Nov 2020 05:39:42 +0000
Subject: more juicy gemini content to marinate your brain
In-Reply-To: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>
References: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>
Message-ID: <YVCr9vSmgza3P367At7KzzkyFl1stTY8O9cVMcQDw@cp3-web-029.plabs.ch>

On Sun Nov 8, 2020 at 8:49 PM EST, Zach ?? wrote:
> Hi
>
> //e-worm.club is now on gemini
>
> It=E2=80=99s mostly an aggressively unpolished look into the minds of
> hot t=
> wenty-somethings living rent free in the strangely vibrant hollow shell
> tha=
> t is 2020 San Francisco.
>
> Also there are some good critiques of =E2=80=98progressive=E2=80=99
> softwar=
> e buried in there, but I=E2=80=99ll let you find those on your own.
>
> xoxo
> Zach
>
> PS: feel free to email me / any of us in response to any of the
> I refuse to take the time to aggregate server logs, so
> it=E2=80=99s =
> the only way we have of knowing whether anyone reads our stuff

Sounds terrifying.

Jordan


From marcx2 at welz.org.za  Mon Nov  9 07:53:56 2020
From: marcx2 at welz.org.za (marc)
Date: Mon, 9 Nov 2020 08:53:56 +0100
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
Message-ID: <20201109075356.GA10576@localhost.localdomain>

> This is what I *think* how *should* clients work with caching:
> 
> The clients with history support and supports going ''backwards'' and
> ''forwards'' through history should cache text/* responses in memory
> for that browsing session. When the user browses through the history
> using ''forward'' and ''backward'' action, no reloading should happen.
> But, when a user clicks the link for a resource already in cache or
> writes the link by hand or selects the link from previously visited
> links or asks for reload: the cache is purged and the resource
> reloaded. It is assumed that requests with query part are idempotent.
> Now, when a page is dynamic, it should be stated as such so that the
> user would reload that page.
> With that, no new response codes.

I think your proposal is excellent. I am sure a browser
could add a command "press r to reload" for any page.

I have to say I am really puzzled by the protracted
discussion about caching. The difference between returning
the full document and a message saying "document hasn't
changed" is really small in the greater scheme of things:

The tcp 3 way handshake plus the tls negotiation
consume quite a number of packets, and add round trip
latency. Network load is often measured in number of frames
rather than bytes, and there is space for 1500 or even
9000 bytes per frame - this means that if your document is
below that size (I'd venture most good ones are), then a
"not changed" response doesn't even change the number of
packets sent. That even suggests another heuristic: If
your content is dynamic, try generating a short document,
the implication being that larger ones should be cached,
as there might be an actual benefit.

I really think this is a holdover people still thinking
in http+html instead of gemini:

Plaintext http allowed several parties to share
a cache. This isn't the case there, as things are
encrypted. Html often includes other urls ("img src"),
which might be shared across pages. Gemini doesn't do
that either.

And *if* caching should be done, then it seems
a poor idea to have the caching clues live in the
transfer/session/transport layer. Instead it should be in
the document markup. 

Even http+html finally realised that with the messy
"http-meta-equiv" fields in the markup. At least that
provides a better path for the document author to
tell is how long the document might be valid for. And
with a machine readable license that would allow for
aggregation/replication/archiving/broadcast/etc which seems a
much better way to save bandwidth and have persistent documents.

TLDR: Don't think in http+html, do better

regards

marc


From sir at cmpwn.com  Mon Nov  9 14:18:32 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 09 Nov 2020 10:18:32 -0400
Subject: Statement of intent regarding TLS server name identification (SNI)
Message-ID: <C6YSQM8AGZG7.RFHRTHMJV08X@taiga>

Hiya! On behalf of the gmnisrv server software
(https://git.sr.ht/~sircmpwn/gmnisrv), I'm writing to inform client
authors that our intention is to *require* clients to enable server name
identification (SNI) when making TLS connections. We will drop
connections which do not provide SNI.

It's pretty easy to add to your cilent, so please double check that
yours does it! My server, gemini://drewdevault.com, is running gmnisrv
with this requirement enabled if you want something to test against.

From acdw at acdw.net  Mon Nov  9 15:33:39 2020
From: acdw at acdw.net (acdw)
Date: Mon, 09 Nov 2020 15:33:39 +0000
Subject: org-mode export to gemini
In-Reply-To: <8085cce1-ff2d-4d5b-bca9-0d08f9c65dfa@www.fastmail.com>
References: <8085cce1-ff2d-4d5b-bca9-0d08f9c65dfa@www.fastmail.com>
Message-ID: <1f4fcefc-4992-4e03-bae2-4010b8999f34@www.fastmail.com>

On 2020-11-08 (Sunday) at 19:17, Justin Abrahms <justin at abrah.ms> wrote:


> https://git.sr.ht/~abrahms/ox-gemini
> 
> Thanks!
>   - abrahms

Oh wonderful!!! I will also try this and report. :)

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From acdw at acdw.net  Mon Nov  9 15:42:49 2020
From: acdw at acdw.net (acdw)
Date: Mon, 09 Nov 2020 15:42:49 +0000
Subject: Gemini to Hacker News portal
In-Reply-To: <C6Y4HOO0042G.3JQHVZT6RMVTL@taiga>
References: <C6Y4HOO0042G.3JQHVZT6RMVTL@taiga>
Message-ID: <eb6ee306-0ff4-44d3-9af9-4e91f6cab786@www.fastmail.com>

On 2020-11-08 (Sunday) at 19:18, Drew DeVault <sir at cmpwn.com> wrote:

> It also includes an HTML to Gemtext converter which works surprisingly
> well, and which I will probably expand into a general purpose
> Gemini-to-web portal in the future.

It seems as though, at least for me, arbitrary websites aren't being fetched/converted.  I either see a blank page after the disclaimer that it was generated automatically, or a CGI or gateway error.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From op at omarpolo.com  Mon Nov  9 15:54:57 2020
From: op at omarpolo.com (Omar Polo)
Date: Mon, 09 Nov 2020 16:54:57 +0100
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <C6YSQM8AGZG7.RFHRTHMJV08X@taiga>
References: <C6YSQM8AGZG7.RFHRTHMJV08X@taiga>
Message-ID: <87o8k68qzy.fsf@omarpolo.com>


Drew DeVault <sir at cmpwn.com> writes:

> Hiya! On behalf of the gmnisrv server software
> (https://git.sr.ht/~sircmpwn/gmnisrv), I'm writing to inform client
> authors that our intention is to *require* clients to enable server name
> identification (SNI) when making TLS connections. We will drop
> connections which do not provide SNI.
>
> It's pretty easy to add to your cilent, so please double check that
> yours does it! My server, gemini://drewdevault.com, is running gmnisrv
> with this requirement enabled if you want something to test against.

This explain why I wasn't able to visit your server today, as it seems
elpher doesn't do SNI.

(please excuse my ignorance on the matter) what?s the rationale for this
requirement? (other than allowing virtual hosts.)  I'm asking because
I'm curious if I need to follow the same behaviour in my server too.

From sir at cmpwn.com  Mon Nov  9 16:17:59 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 09 Nov 2020 12:17:59 -0400
Subject: Gemini to Hacker News portal
In-Reply-To: <eb6ee306-0ff4-44d3-9af9-4e91f6cab786@www.fastmail.com>
Message-ID: <C6YVA2T8YU2Z.3IBX7MWY3TLXV@taiga>

It doesn't always work well for all web pages. It works best with
articles.

From linde.philip at gmail.com  Mon Nov  9 16:18:21 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 9 Nov 2020 17:18:21 +0100
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201108222256.GI30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <20201108055017.GG30302@brevard.conman.org>
 <20201108134014.81668d09abe353de20010f8c@gmail.com>
 <20201108222256.GI30302@brevard.conman.org>
Message-ID: <20201109171821.135855a1ebda5aa7dafbdf08@gmail.com>

On Sun, 8 Nov 2020 17:22:56 -0500
Sean Conner <sean at conman.org> wrote:

>   I don't agree that this is self-inflicted on me---what I'm trying (and
> failing) to point out is that adding mroe success calls *could* lead to 
> combinatorial hell.

This is unavoidable in any case of adding a sufficient number of
features that can be combined. If every feature proposal should be
evaluated in terms of the slippery slope of "what if we add more" there
wouldn't be a point to discussing additions to the protocol, a notion
that I'm actually partial to, but that I think shouldn't be used as a
basis for judging against individual feature proposals.

>   No, that was to prisonpotato at tilde.team---they were the first to come up
> with the idea, not me.  I just implemented it first (much the same way I
> implemented the first Gemini server even before solderpunk did [1]).  Also,
> the size breaking code is only active on one link on my site, not everwhere.

Okay, I'm glad that you picked it up even when it wasn't addressed
directly at you. Consider the option, and why I believe that using the
2x range is inappropriate.

>   The concern is over large responses.  It wasn't much of a concern until
> gemini://konpeito.media/ was created and serving up large audio files (and
> archives of said audio files).  I can envision a client being configured to
> abort the download if say, a 10 megabyte file is being downloaded.  It
> *sucked* when my DSL went down in late September/early October (yes, about
> three weeks) and I had to rely upon my cellphone hot spot.  I didn't have a
> large data plan for the cell phone becuase I didn't need it, until I did. 
> It would have been nice to configure my web browser to not download anything
> over 5M at that point.

That would be a nice feature, but is it nice enough to warrant breakage
across the growing number of implementations? text/gemini documents can
display an estimated size for linked files, and a user can configure
their automatic client to abort at a certain point or choose in their
interactive client to cancel a request. Not a complete solution by any
means, but worth considering as it is much cheaper.

No-cache/please-cache 2x responses however seem like they can add a lot
of value for very little cost. Existing client implementations will be
compatible, and the idea of the second digit as a hint from the server
that can be ignored by a simpler client is retained.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/695c2fca/attachment-0001.sig>

From jb55 at jb55.com  Mon Nov  9 16:18:19 2020
From: jb55 at jb55.com (William Casarin)
Date: Mon, 09 Nov 2020 08:18:19 -0800
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <87o8k68qzy.fsf@omarpolo.com>
References: <C6YSQM8AGZG7.RFHRTHMJV08X@taiga> <87o8k68qzy.fsf@omarpolo.com>
Message-ID: <878sbajygk.fsf@jb55.com>

Omar Polo <op at omarpolo.com> writes:
> Drew DeVault <sir at cmpwn.com> writes:
>
>> Hiya! On behalf of the gmnisrv server software
>> (https://git.sr.ht/~sircmpwn/gmnisrv), I'm writing to inform client
>> authors that our intention is to *require* clients to enable server name
>> identification (SNI) when making TLS connections. We will drop
>> connections which do not provide SNI.
>>
>> It's pretty easy to add to your cilent, so please double check that
>> yours does it! My server, gemini://drewdevault.com, is running gmnisrv
>> with this requirement enabled if you want something to test against.
>
> This explain why I wasn't able to visit your server today, as it seems
> elpher doesn't do SNI.

The Gemini iOS app?? I was using also doesn't load Drew's server. I get the
error message "The operation couldn't be completed. (OSStatus error -9806.)"

Perhaps this could be clarified in the spec?

Cheers,
Will

? https://testflight.apple.com/join/ln6yTtqK
? https://github.com/pitr/gemini-ios

-- 
https://jb55.com

From sir at cmpwn.com  Mon Nov  9 16:18:21 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 09 Nov 2020 12:18:21 -0400
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <87o8k68qzy.fsf@omarpolo.com>
Message-ID: <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>

To enable virtual hosts and automatic certificate generation.

From op at omarpolo.com  Mon Nov  9 16:48:16 2020
From: op at omarpolo.com (Omar Polo)
Date: Mon, 09 Nov 2020 17:48:16 +0100
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>
References: <87o8k68qzy.fsf@omarpolo.com> <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>
Message-ID: <87lffa8oj3.fsf@omarpolo.com>


Drew DeVault <sir at cmpwn.com> writes:

> To enable virtual hosts and automatic certificate generation.

Seems fair.  But, since also another user complained that his client
didn?t support SNI as well, would you mind relaxing this requirement for
a bit?  I really like reading your blog :)

In the meantime I guess I?ll try to figure out how to teach SNI to
elpher.

From lokesh at low-key.me  Mon Nov  9 17:15:41 2020
From: lokesh at low-key.me (Lokesh Krishna)
Date: Mon, 09 Nov 2020 22:45:41 +0530
Subject: =?US-ASCII?Q?Re=3A_Statement_of_intent_regarding_T?=
 =?US-ASCII?Q?LS_server_name_identification_=28SNI=29?=
In-Reply-To: <87lffa8oj3.fsf@omarpolo.com>
References: <87o8k68qzy.fsf@omarpolo.com> <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>
 <87lffa8oj3.fsf@omarpolo.com>
Message-ID: <AE52AAF2-5B49-4AB3-8B05-53444412A587@low-key.me>

Since their server is meant to be something others can test their clients against, I think you could just use an alternative client like amfora until elpher can do this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/57bcca58/attachment.htm>

From raiz at stellarbound.space  Mon Nov  9 17:16:18 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Mon, 9 Nov 2020 20:16:18 +0300
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201109171821.135855a1ebda5aa7dafbdf08@gmail.com>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <20201108055017.GG30302@brevard.conman.org>
 <20201108134014.81668d09abe353de20010f8c@gmail.com>
 <20201108222256.GI30302@brevard.conman.org>
 <20201109171821.135855a1ebda5aa7dafbdf08@gmail.com>
Message-ID: <20201109201618.22f87dce@home>

On Mon, 9 Nov 2020 17:18:21 +0100
Philip Linde <linde.philip at gmail.com> wrote:
> On Sun, 8 Nov 2020 17:22:56 -0500
> This is unavoidable in any case of adding a sufficient number of
> features that can be combined. If every feature proposal should be
> evaluated in terms of the slippery slope of "what if we add more"
> there wouldn't be a point to discussing additions to the protocol, a
> notion that I'm actually partial to, but that I think shouldn't be
> used as a basis for judging against individual feature proposals.

Lets not look at it this way, lets look at it for the way of what does
caching truly enable, I've discussed this many times, no one seemed to
address my concerns, if in-protocol caching mechanism exists, it opens
the window for serving complex document formats that are resource
heavy, see HTML pulling stylesheets and images for example, it is
discouraged to use anything other than gemtext for documents in Gemini.

In the case of serving media files like music, video, and even large
PDFs, these are downloaded to be saved on disk anyway, so caching
wouldn't be a concern.

The only convincing reasoning for caching is Waweic's use case using
Mallick's method, and even that doesn't introduce any new protocol
features.

> That would be a nice feature, but is it nice enough to warrant
> breakage across the growing number of implementations? text/gemini
> documents can display an estimated size for linked files, and a user
> can configure their automatic client to abort at a certain point or
> choose in their interactive client to cancel a request. Not a
> complete solution by any means, but worth considering as it is much
> cheaper.

While to each their own, and implementations can behave the way they
desire, I'm against this feature as it breaks certain sites that are
slow to load, I'd have to refresh once again and get it to load fast if
I don't want it to timeout, what you could do instead is have in the
bottom (or top) status bar or any information indicator a display of
how much is downloaded of the requested file, the user then judges if
they want to stop or not by hitting a cancel button.

From rlwestlund at gmail.com  Mon Nov  9 17:06:34 2020
From: rlwestlund at gmail.com (Ryan Westlund)
Date: Mon, 9 Nov 2020 12:06:34 -0500
Subject: Question about TLS certificate policy
Message-ID: <CAKSVUBLK8_h0aKOS50OLT+hLK_GYj5s0AGAktqsfOBtXja0OMg@mail.gmail.com>

I've been reading about Gemini and part of me likes the decision to
abandon certificate authorities in favor of TOFU, but I have a
question about how this works. The Gemini specification says:

> If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.

Doesn't this mean that the replacement certificate must be deployed at
*exactly* the right time to avoid errors? If you deploy it even a day
ahead of time, users will see errors? And users will see errors if you
are late to replace it?

From me at adnano.co  Mon Nov  9 17:40:04 2020
From: me at adnano.co (Adnan Maolood)
Date: Mon, 09 Nov 2020 12:40:04 -0500
Subject: Question about TLS certificate policy
In-Reply-To: <CAKSVUBLK8_h0aKOS50OLT+hLK_GYj5s0AGAktqsfOBtXja0OMg@mail.gmail.com>
Message-ID: <C6YX0X7HQRKR.3BAIVTOGLSYX0@nitro>

On Mon Nov 9, 2020 at 7:06 AM EST, Ryan Westlund wrote:
> I've been reading about Gemini and part of me likes the decision to
> abandon certificate authorities in favor of TOFU, but I have a
> question about how this works. The Gemini specification says:
>
> > If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.
>
> Doesn't this mean that the replacement certificate must be deployed at
> *exactly* the right time to avoid errors? If you deploy it even a day
> ahead of time, users will see errors? And users will see errors if you
> are late to replace it?

Yes, it does. Some servers automatically generate certificates to avoid
this issue, ensuring that an expired certificate is never used.

From lambdatronic at disroot.org  Mon Nov  9 18:06:25 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Mon, 09 Nov 2020 13:06:25 -0500
Subject: examples with Sympy
In-Reply-To: <C6XD15B1EJVO.1GF8DLPJOPDEW@rath>
References: <20201107180839.GC8281@TARS.localdomain>
 <C6XD15B1EJVO.1GF8DLPJOPDEW@rath>
Message-ID: <871rh2l80u.fsf@disroot.org>

Leo <list at gkbrk.com> writes:

> Wow! These look amazing on the terminal. I am not quote-replying as I
> don't want to mess with the beautiful monospace rendering.
>
> I would love to read a maths/science/CS related blog that uses this
> kind of rendering. This is so pleasant to look at on both a terminal and
> a GUI client.
>
> I hope someone will take the time to write either a latex-to-gemtext
> compiler that can generate this, or a server that does it dynamically.

I agree. To fluxion, I would remind you that the text/gemini format is
meant to be served as Unicode by default, so if you were to simply stick
those result graphics in a preformatted (```) block, they should look
great in any gemini client.

Thanks for the examples with Sympy. Very inspiring indeed!

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From jmcbray at carcosa.net  Mon Nov  9 18:15:06 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 09 Nov 2020 13:15:06 -0500
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one> (Zach DeCook's
 message of "Sun, 08 Nov 2020 00:52:11 -0500")
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one>
Message-ID: <87o8k6xuqd.fsf@dorothy.carcosa.net>

Zach DeCook <zachdecook at librem.one> writes:

> A "please don't cache" response code would be (ab)used by servers who
> desire to track their users.

I think this is an important point which has been largely overlooked. We
do not have (many?) bad actors on the gemiverse for now, but this can't
continue forever.

I'm also wondering whether we shouldn't state outright that Gemini
requests are expected to be idempotent. I know this would break dynamic
pages that people are already using and enjoying (astrobotany,
guestbooks), but other types of dynamic pages with user input would
still be relevant, like searches and local weather.

I dislike the idea of adding caching-related result codes. That's one of
the things that drove the increasing complexification of HTTP during the
HTTP/1.0 era (i.e., before HTTP/1.1). If we're not doing full-fledged
application development on top of Gemini, we don't need server-side
cache control.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Mon Nov  9 19:11:00 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 09 Nov 2020 14:11:00 -0500
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
 (Sudipto Mallick's message of "Sun, 8 Nov 2020 11:29:09 +0530")
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <6890ca83b3980a32a900371b7ebd710a@tilde.team>
 <CAFaUHvJ6t8G=LxgUAy2z-UC_F9cvHfp+W6=Aj00zKGSnfpUyDw@mail.gmail.com>
Message-ID: <87h7pyxs57.fsf@dorothy.carcosa.net>

Sudipto Mallick <smallick.dev at gmail.com> writes:

> The clients with history support and supports going ''backwards'' and
> ''forwards'' through history should cache text/* responses in memory
> for that browsing session. When the user browses through the history
> using ''forward'' and ''backward'' action, no reloading should happen.
> But, when a user clicks the link for a resource already in cache or
> writes the link by hand or selects the link from previously visited
> links or asks for reload: the cache is purged and the resource
> reloaded. It is assumed that requests with query part are idempotent.

I also believe that this is the correct approach, and should be
considered a client 'best practice'.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From lambdatronic at disroot.org  Mon Nov  9 19:46:08 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Mon, 09 Nov 2020 14:46:08 -0500
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <87lffa8oj3.fsf@omarpolo.com>
References: <87o8k68qzy.fsf@omarpolo.com> <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>
 <87lffa8oj3.fsf@omarpolo.com>
Message-ID: <87y2jajou7.fsf@disroot.org>

Omar Polo <op at omarpolo.com> writes:

> In the meantime I guess I?ll try to figure out how to teach SNI to
> elpher.

I use elpher as my Gemini client, and gemini://drewdevault.com loads
just fine for me. I'm running elpher version 2.10.0.

Cheers,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From thomas5max at gmail.com  Mon Nov  9 20:00:51 2020
From: thomas5max at gmail.com (Thomas M)
Date: Mon, 09 Nov 2020 20:00:51 +0000
Subject: Serious writing (in the Latin script) needs italics
Message-ID: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>

Hi all,

I'm very impressed with this project. I'm using the Lagrange client by
Jaakko Ker?nen and it's very beautiful. But I noticed an oversight.

Lagrange handles images absolutely great: they're only downloaded when I
click on them. And I can (barely) live without inline links. But italics
are just too important for writing in the Latin script (note that I
don't really care about bold face). Other writing systems may have their
own way of conveying emphasis, but for the Latin script it's italics.

The Gemini FAQ [1] itself already shows the issue: the heading for
section 2.3 needed italics, but none were available, so it uses
asterisks for emphasis. This does not look good in the otherwise very
slick Lagrange.

I don't think the ability to mark emphasis is likely to lead to abuse.
Also, even if you plan on primarily interacting with Gemini in your
terminal, let me point out that a lot of terminals support italics
nowadays. And if your terminal doesn't, it can just ignore it.

Now, one way out of this problem is to use Unicode's support for italics
[2]. You could maybe argue that it should be the job of the text
encoding to encode emphasis and not the job of the markup. But I don't
have the impression that this is particularly well encoded in Unicode.
And I think, for example, Cyrillic is missing from it.

So, I hope you'll consider adding markup for emphasis, even if it will
complicate the client implementation.

One option is maybe to just make rendering emphasis *optional*. The
specification could say that surrounding asterisks (*like this*) denote
emphasis, but if a client doesn't want to render it, they could just
display the asterisks.

Cheers,
Thomas

[1]: gemini://gemini.circumlunar.space/docs/faq.gmi
[2]: https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols

From cowan at ccil.org  Mon Nov  9 20:53:36 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 9 Nov 2020 15:53:36 -0500
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one>
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one>
Message-ID: <CAD2gp_Q_j9Str_pJiTLAU=Mi7paZ6r-qr60gMMJvBB+bMbWX3A@mail.gmail.com>

On Sun, Nov 8, 2020 at 12:52 AM Zach DeCook <zachdecook at librem.one> wrote:


> A "please don't cache" response code would be (ab)used by servers who
> desire to track their users.
>

I don't understand your reasoning there.  What does a server learn by
sending a 21 YOU CAN CACHE  or 22 YOU SHOULD NOT CACHE response back
instead of a plain 20 response?  (I'm not a security expert and I know
there are loopholes I don't see.)



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
So they play that [tune] on their fascist banjos, eh?
        --Great-Souled Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/8317e59c/attachment.htm>

From alex at nytpu.com  Mon Nov  9 20:56:06 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Mon, 9 Nov 2020 13:56:06 -0700
Subject: Statement of intent regarding TLS server name identification (SNI)
Message-ID: <20201109205606.o44up5kpwv6oqq73@GLaDOS>

See ?4 of the Gemini Specification:
> Use of the Server Name Indication (SNI) extension to TLS is also
> mandatory, to facilitate name-based virtual hosting.

If your client does not support SNI, then it is in violation of the
specification.

I make a motion that SNI should actually be mandatory to ensure clients
are following the specification (as apparently elpher and other clients
aren't). I don't want a flip-flopped version of tag soup where servers
have to cater to the lowest common denominator of clients even though
they are in clear violation of the specification.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/4d4e0409/attachment.sig>

From sean at conman.org  Mon Nov  9 21:18:42 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 9 Nov 2020 16:18:42 -0500
Subject: Proposal about content-size and hash
In-Reply-To: <20201103002129.GV30302@brevard.conman.org>
References: <mailman.56.1604249673.476.gemini@lists.orbitalfox.eu>
 <45ec4611abe3271483e3f109486256ad@tilde.team>
 <20201102234432.963c5bfaa6a2bdaa5317c608@gmail.com>
 <20201103002129.GV30302@brevard.conman.org>
Message-ID: <20201109211842.GM30302@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
> 	gemini://gemini.conman.org/test/testsize.gemini
> 
>   The above page will return a normal 20, but all the links on it will
> return a 22 with a size, then MIME type.

  The above page no longer exists.  It's clear that this method (using a
separate status code to signal size data) is not popular (and I wasn't even
a fan of it myself).

  -spc (Will remove dodgy proof-of-concepts on a whim for $400, Alex)

From linde.philip at gmail.com  Mon Nov  9 21:20:47 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 9 Nov 2020 22:20:47 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
Message-ID: <20201109222047.054ab7fc74544ed8fee961df@gmail.com>

On Mon, 09 Nov 2020 20:00:51 +0000
"Thomas M" <thomas5max at gmail.com> wrote:

> So, I hope you'll consider adding markup for emphasis, even if it will
> complicate the client implementation.

It would be the only markup that isn't entirely line prefix based and
would complicate parsing a lot potentially invalidating straight forward
techniques that clients are already using. Rendering something like
*this* as italic text may also be surprisingly error prone, considering
other contexts in which one might want to use "*" and the different
sequences of text one might want to emphasize. It's something Markdown
parsers frequently get wrong, or at the very least causes unintuitive
problems.

I agree that Unicode is not a good solution to the problem since the
italic blocks are intended for mathematical use, not emphasis. Unicode
deliberately avoids repeating the work of what the consortium thinks
belongs to a markup language (but does not show the same apprehension
for pictures of levitating men in business suits).

Perhaps some clients could optionally choose to interpret "*-encoded"
italics in the way you suggest in a way that's easy to toggle. Such a
feature is either allowed ("Text lines may be presented to the user in
a visually pleasing manner for general reading, the precise meaning of
which is at the client's discretion.") or prohibited ("Authors should
not expect to exercise any control over the precise rendering of their
text lines, only of their actual textual content.") depending on your
reading of the spec. But do consider the way in which I might started
an emphasis block earlier in this paragrah, which I'll now complete: *

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/0f41c00a/attachment.sig>

From cowan at ccil.org  Mon Nov  9 21:28:01 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 9 Nov 2020 16:28:01 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
Message-ID: <CAD2gp_Qbbz45EqOcLFP3Lzb+iQbfWeHR2qXXU5TWxExKdOdfyw@mail.gmail.com>

On Mon, Nov 9, 2020 at 3:41 PM Thomas M <thomas5max at gmail.com> wrote:


> Now, one way out of this problem is to use Unicode's support for italics
>

??? ??????, ?????? ?? ??? ???? ?? ?? ?????!

I don't know how that's going to look to you, but for me the word "really"
is just horribly badly kerned.  What is more, the ! is completely upright
because it has no math-italic equivalent.  I think the client needs to
decide whether to interpret ASCII inline markup of this kind.  The spec
says "Authors should not expect to exercise any control over the precise
rendering of their text lines, only of their actual textual content", but a
hint is not exercising precise control IMO.

Any client that does this must leave the asterisks (or slashes, or
whatever) in place, though; otherwise it has failed its basic duty of
displaying all the content, subject only to resource limitations.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
The competent programmer is fully aware of the strictly limited size of his
own
skull; therefore he approaches the programming task in full humility, and
among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/ce1abd77/attachment-0001.htm>

From sean at conman.org  Mon Nov  9 21:33:08 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 9 Nov 2020 16:33:08 -0500
Subject: Caching and sizes,
 the explosion of responise codes (was Re: Caching and status codes)
In-Reply-To: <20201108074946.GH30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <954134263ab38c016102dca4efcb04d6@tilde.team>
 <20201108074946.GH30302@brevard.conman.org>
Message-ID: <20201109213308.GN30302@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
>   And I have my "proof-of-concept" up at well.  It's at
> 
> 	gemini://gemini.conman.org/test/testcache.gemini

  I have removed this "proof-of-concept" after some thought about the
approach.  I agree with Ali Fardan that Mallick's method is the way to
handle caching (or not at all).

  Now, on with destroying my own idea here ...

>   How it works:  A plain request:
> 
> 	gemini://gemini.conman.org/test/cachefile.txt
> 
> will always return the content.  However, if you include a timestamp using a
> path parameter (which is *NOT* the same as a query paramter, and is in the
> ISO-8601 format):
> 
> 	gemini://gemini.conman.org/test/cachefile.txt;2020-11-08T00:00:00
> 
> If the file is *newer* than that timestamp, you get the normal response of
> 20 and all the content; otherwise you get a response of 23 (with the normal
> MIME type) and no content, meaning it hasn't changed since the given date.

  The major problem here is timezones.  Time zone information is
complicated, and from what I've seen, operating system specific (the C
standard doesn't mention it; POSIX does it one way; Windows another) so
that's a complication for both servers and clients.

Also, does the concept apply to each path component?  Or only the end?  For
example:

	gemini://gemini.conman.org/test;2020-11-08T00:00:00/cachefile.txt 

return 23 if the directory test hasn't changed, even if cachefile.txt has? 
Or is it ignored *unless* it's the last path component?  My gut instinct is
to say "last component" but it get messy:

	gemini://gemini.coman.org/test;2020-11-08T00:00:00

will result in a redirect (or should), but

	gemini://gemini.coman.org/test;2020-11-08T00:00:00/

won't.

  So, for these reasons, nah.  I won't push this.

  -spc


From tomasino at lavabit.com  Mon Nov  9 21:57:02 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 9 Nov 2020 21:57:02 +0000
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
Message-ID: <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>

On 11/9/20 9:20 PM, Philip Linde wrote:
> Rendering something like
> *this* as italic text may also be surprisingly error prone, considering
> other contexts in which one might want to use "*" and the different
> sequences of text one might want to emphasize. It's something Markdown
> parsers frequently get wrong, or at the very least causes unintuitive
> problems.

Thunderbird has a nice collection of issues logged over the years related to text formatting in plain text messages. It is indeed quite tricky, but if a client wanted to implement it I'd suggest looking into the Thunderbird test suite as a starting point.

Also on the subject of *this* being italic I do want to point out that that choice of formatting for the markup is uniquely Markdown oriented. Most other plain text systems interpret *this* as bold and /this/ as italic and _this_ as underlined. We have a lot of Markdown influence in gemtext, but authors coming from other domains may find some surprises in various clients.

If a client does choose to implement this as an optional add-on, please continue to show the characters when you style the text. In the case your parsing algorithm is incorrect the content will still be present and we can figure it out.


From raingloom at riseup.net  Mon Nov  9 21:44:31 2020
From: raingloom at riseup.net (raingloom)
Date: Mon, 9 Nov 2020 22:44:31 +0100
Subject: examples with Sympy
In-Reply-To: <20201107180839.GC8281@TARS.localdomain>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107180839.GC8281@TARS.localdomain>
Message-ID: <20201109224431.78912d63@riseup.net>

On Sat, 7 Nov 2020 19:08:39 +0100
fluxion <fluxion at monocles.de> wrote:

> I thought it could be nice to show some examples rendered
> with Sympy.

I have only one question: how will screen readers handle this?

From cowan at ccil.org  Mon Nov  9 22:52:36 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 9 Nov 2020 17:52:36 -0500
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <20201109213308.GN30302@brevard.conman.org>
References: <20201108051844.GF30302@brevard.conman.org>
 <20201107222315.0f596e83@home>
 <20201107043256.GA38951@202x.moe> <C6WUJ19LK6H2.4WRJONR5923B@rath>
 <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <954134263ab38c016102dca4efcb04d6@tilde.team>
 <20201108074946.GH30302@brevard.conman.org>
 <20201109213308.GN30302@brevard.conman.org>
Message-ID: <CAD2gp_RUcrJK3qHRy4Ncj2ENYLEhvKAUnLQgAR=eogvB5QcrkA@mail.gmail.com>

On Mon, Nov 9, 2020 at 4:33 PM Sean Conner <sean at conman.org> wrote:


> The major problem here is timezones.  Time zone information is
> complicated, and from what I've seen, operating system specific (the C
> standard doesn't mention it; POSIX does it one way; Windows another) so
> that's a complication for both servers and clients.
>

ISO 8601 doesn't use named timezones, only offsets, but the best policy is
to do everything in UTC, which is pretty universally available on all
operating systems now.  It's perfectly fine to just write
"2020-11-09T22:14:05Z".


> Also, does the concept apply to each path component?  Or only the end?
>

I would say "The end", but I would write it as a query term:  gemini://
example.com/test?since=2020-11-09T22:14:05Z.  After all, the path elements
aren't necessarily actual objects with modification dates (in Amazon S3,
for example, they are just part of the name).

In addition, you could use the "inode/x-empty" MIME-type instead of a
different protocol response.

But, like you, I doubt this is worth doing.  Servers should advise clients
about whether the author thinks the result should be cached, and clients
can do what they like about it.  (There are any number of ways for the
author to communicate this intent; it doesn't have to be part of the
content.)



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
I am expressing my opinion.  When my honorable and gallant friend is
called, he will express his opinion.  This is the process which we
call Debate.                   --Winston Churchill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/e35508dc/attachment.htm>

From jmcbray at carcosa.net  Mon Nov  9 23:02:41 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 09 Nov 2020 18:02:41 -0500
Subject: Caching and sizes, the explosion of responise codes (was Re:
 Caching and status codes)
In-Reply-To: <CAD2gp_Q_j9Str_pJiTLAU=Mi7paZ6r-qr60gMMJvBB+bMbWX3A@mail.gmail.com>
 (John Cowan's message of "Mon, 9 Nov 2020 15:53:36 -0500")
References: <20201107222315.0f596e83@home> <20201107043256.GA38951@202x.moe>
 <C6WUJ19LK6H2.4WRJONR5923B@rath> <20201107194358.61b66e19@home>
 <CAD2gp_Q1sfGCKonkM=c8xMm3vWzwrcOymEteFhAf_hWJvmvefg@mail.gmail.com>
 <34ef18e0125ed964e6a726c15d89fc47@tilde.team>
 <20201108051844.GF30302@brevard.conman.org>
 <A67603C2-3846-4F07-B028-8A8CB82B5566@librem.one>
 <CAD2gp_Q_j9Str_pJiTLAU=Mi7paZ6r-qr60gMMJvBB+bMbWX3A@mail.gmail.com>
Message-ID: <87mtzqp20e.fsf@cassilda.carcosa.net>

John Cowan <cowan at ccil.org> writes:

> I don't understand your reasoning there. What does a server learn by
> sending a 21 YOU CAN CACHE or 22 YOU SHOULD NOT CACHE response back
> instead of a plain 20 response? (I'm not a security expert and I know
> there are loopholes I don't see.)

The server operator gets a decent guess at whether the user has visited
the page before (within a reasonable caching window), because if you
sent a 21 YOU CAN CACHE, and they made the request, that means they
hadn't seen it recently. Combine this with query strings, IP addresses,
and/or fragment identifiers, and you can identify individual users, even
users who have refused to set a client certificate when you asked. It's
a pretty minor information leak, since it can't be used for cross-site
tracking. But give techbros an inch, and they'll take a mile.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Mon Nov  9 23:05:41 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 09 Nov 2020 18:05:41 -0500
Subject: examples with Sympy
In-Reply-To: <20201109224431.78912d63@riseup.net> (raingloom@riseup.net's
 message of "Mon, 9 Nov 2020 22:44:31 +0100")
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107180839.GC8281@TARS.localdomain>
 <20201109224431.78912d63@riseup.net>
Message-ID: <87imaep1ve.fsf@cassilda.carcosa.net>

raingloom <raingloom at riseup.net> writes:

> I have only one question: how will screen readers handle this?

Probably very badly. Which is why I'm somewhat critical of using fixed
format blocks for ASCII art.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From johann.galle at protonmail.com  Mon Nov  9 23:15:54 2020
From: johann.galle at protonmail.com (Johann Galle)
Date: Mon, 09 Nov 2020 23:15:54 +0000
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
Message-ID: <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>

> I don't think the ability to mark emphasis is likely to lead to abuse.
> Also, even if you plan on primarily interacting with Gemini in your
> terminal, let me point out that a lot of terminals support italics
> nowadays. And if your terminal doesn't, it can just ignore it.

I don't know if this has been pointed out before, but you can get
rendering similar to man pages (which has things like bold and underline
IIRC) by using troff; it should I think be fairly easy to parse,
although I have not tried it myself. The beautiful thing of troff
in this context is that there is also a designated MIME type
text/troff [RFC4263]; they also have a https-site [TROFF].

[RFC4263] https://www.iana.org/go/rfc4263
[TROFF] https://troff.org/

From jmcbray at carcosa.net  Mon Nov  9 23:25:17 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 09 Nov 2020 18:25:17 -0500
Subject: more juicy gemini content to marinate your brain
In-Reply-To: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es> ("Zach
 =?utf-8?B?4piB77iOIidz?=
 message of "Sun, 8 Nov 2020 17:49:37 -0800")
References: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>
Message-ID: <87eel2p0yq.fsf@cassilda.carcosa.net>

Zach ?? <zach at anemon.es> writes:

> //e-worm.club is now on gemini
>
> It?s mostly an aggressively unpolished look into the minds of hot
> twenty-somethings living rent free in the strangely vibrant hollow
> shell that is 2020 San Francisco.

This is good content, but is it a mirror of a web site? I caught a
'home' link on one of the pages that tried to send me to an http link. 

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From linde.philip at gmail.com  Mon Nov  9 23:46:11 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 00:46:11 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
Message-ID: <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>

On Mon, 9 Nov 2020 21:57:02 +0000
James Tomasino <tomasino at lavabit.com> wrote:

> Thunderbird has a nice collection of issues logged over the years related to text formatting in plain text messages. It is indeed quite tricky, but if a client wanted to implement it I'd suggest looking into the Thunderbird test suite as a starting point.

That seems like a very good starting point.

> Also on the subject of *this* being italic I do want to point out that that choice of formatting for the markup is uniquely Markdown oriented. Most other plain text systems interpret *this* as bold and /this/ as italic and _this_ as underlined. We have a lot of Markdown influence in gemtext, but authors coming from other domains may find some surprises in various clients.

The /italics/ style has the unfortunate side effect of producing false
positives for quite plausible Unix paths, e.g. /etc/. This has never
been a problem in the settings I use this style of implying typography
(mostly IRC) because the input isn't typically transformed and is
presented as written. For transformed text, I personally prefer a style
where the notion of emphasis is decoupled from the typographical choice
of how to represent it.

> If a client does choose to implement this as an optional add-on, please continue to show the characters when you style the text. In the case your parsing algorithm is incorrect the content will still be present and we can figure it out.

Another good suggestion. From my reading there is no question that such
an implementation would conform to the existing spec. As a more general
solution, a client could allow the user to specify formatting for
different sequences within the normal text lines using regular
expressions.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/0e617f40/attachment.sig>

From acdw at acdw.net  Mon Nov  9 23:51:43 2020
From: acdw at acdw.net (acdw)
Date: Mon, 09 Nov 2020 23:51:43 +0000
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
Message-ID: <c253b6c4-3e9d-4eb5-9882-375b95ce904e@www.fastmail.com>

Just to add a wrinkle, another terribly hacky thing you can do is use raw terminal escapes to encode when you want italic and bold and underline, as well as different colors, if you just want to.

However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text.  Use syntax, word choice, and punctuation to express your intent!

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From cowan at ccil.org  Tue Nov 10 00:31:43 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 9 Nov 2020 19:31:43 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
Message-ID: <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>

On Mon, Nov 9, 2020 at 6:46 PM Philip Linde <linde.philip at gmail.com> wrote:


> The /italics/ style has the unfortunate side effect of producing false
> positives for quite plausible Unix paths, e.g. /etc/.


Such markup should really only be recognized if there is whitespace or the
beginning of the line before it and whitespace, the end of the line, or
sentence-ending punctuation after it.  One advantage of _ is that it is not
normally used in running text.

This has never
> been a problem in the settings I use this style of implying typography
> (mostly IRC) because the input isn't typically transformed and is
> presented as written


There are IRC clients that interpret it.

On Mon, Nov 9, 2020 at 6:52 PM acdw <acdw at acdw.net> wrote:


> However, I think it is a sign of stronger writing if an author is able to
> convey their meaning without resorting to what's essentially metadata in
> their text.  Use syntax, word choice, and punctuation to express your
> intent!


Contexts where that doesn't work, from WP (and yes, I'm being pedantic):

1) Titles of books, movies, magazines, and other stand-alone works.

2) Scientific names of plants and animals.

3) Terms being introduced for the first time.

4) In narrative, the thoughts of a character.

5) Words being used as examples of themselves.  ("The word _the_ is a
definite article.")

6) Names of ships.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
When I'm stuck in something boring where reading would be impossible or
rude, I often set up math problems for myself and solve them as a way
to pass the time.      --John Jenkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/e5059e7f/attachment.htm>

From linde.philip at gmail.com  Tue Nov 10 00:38:00 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 01:38:00 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <c253b6c4-3e9d-4eb5-9882-375b95ce904e@www.fastmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <c253b6c4-3e9d-4eb5-9882-375b95ce904e@www.fastmail.com>
Message-ID: <20201110013800.d7962e3a1bd348226b8a69bc@gmail.com>

On Mon, 09 Nov 2020 23:51:43 +0000
acdw <acdw at acdw.net> wrote:

> Just to add a wrinkle, another terribly hacky thing you can do is use raw terminal escapes to encode when you want italic and bold and underline, as well as different colors, if you just want to.

I enjoy the idea for its ingenuity, but I don't particularly look
forward to having to implement a terminal emulation layer in my GUI
client :)

> However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text.  Use syntax, word choice, and punctuation to express your intent!

Good point.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/cb2b250c/attachment-0001.sig>

From sean at conman.org  Tue Nov 10 00:59:57 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 9 Nov 2020 19:59:57 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
Message-ID: <20201110005957.GO30302@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> 
> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
> 
> 1) Titles of books, movies, magazines, and other stand-alone works.
> 
> 2) Scientific names of plants and animals.
> 
> 3) Terms being introduced for the first time.
> 
> 4) In narrative, the thoughts of a character.
> 
> 5) Words being used as examples of themselves.  ("The word _the_ is a
> definite article.")
> 
> 6) Names of ships.

7) Foreign words

8) Direct thoughts---example: _Is a gom jabbar something of Arrakis I must
   know before I go there?_ he wondered.

  -spc (The example is from Dune, of which about a third is the direct
	thoughts of the characters ... )


From rlwestlund at gmail.com  Tue Nov 10 01:38:08 2020
From: rlwestlund at gmail.com (Ryan Westlund)
Date: Mon, 9 Nov 2020 20:38:08 -0500
Subject: Escaping in gemtext
Message-ID: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>

According to the Gemtext specification, any line that starts with
"```" is a preformatting toggle. This makes it impossible to have such
a line as part of a preformatted block. I understand the design goals
of Gemtext, but I believe the Markdown solution to the same problem
can be lifted straight into Gemtext relatively easily: allow more than
3 backticks to open a preformatted block, and require the same number
to close it as the number that opened it. This way, any possible text
can be included in a preformatted block. Thoughts?

The same issue exists with text lines (it's impossible to display "=>"
or "#" at the beginning of a line of text), but I'm not concerned
about that because having to prefix such lines with a space is not a
big deal for plain text, whereas it is for code.

From zach at anemon.es  Tue Nov 10 01:54:07 2020
From: zach at anemon.es (=?utf-8?B?WmFjaCDimIHvuI4=?=)
Date: Mon, 9 Nov 2020 17:54:07 -0800
Subject: more juicy gemini content to marinate your brain
In-Reply-To: <87eel2p0yq.fsf@cassilda.carcosa.net>
References: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>
 <87eel2p0yq.fsf@cassilda.carcosa.net>
Message-ID: <768C829C-CEBB-4FEA-9925-D9739111AD04@anemon.es>


> This is good content, but is it a mirror of a web site? I caught a
> 'home' link on one of the pages that tried to send me to an http link. 

Yup! My e-worm friends aren?t technical enough to use gemini, so they (and our many friends who keep tabs on e-worm) access it through http. Sorry if that?s a faux pas in this community. Though to be fair, outside of a few form elements that you?ll never even see, the http site is basically the same as accessing the gemini site through a web portal.


From raiz at stellarbound.space  Tue Nov 10 02:03:30 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 10 Nov 2020 05:03:30 +0300
Subject: Escaping in gemtext
In-Reply-To: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
Message-ID: <20201110050330.4877d47d@home>

On Mon, 9 Nov 2020 20:38:08 -0500
Ryan Westlund <rlwestlund at gmail.com> wrote:

> According to the Gemtext specification, any line that starts with
> "```" is a preformatting toggle. This makes it impossible to have such
> a line as part of a preformatted block. I understand the design goals
> of Gemtext, but I believe the Markdown solution to the same problem
> can be lifted straight into Gemtext relatively easily: allow more than
> 3 backticks to open a preformatted block, and require the same number
> to close it as the number that opened it. This way, any possible text
> can be included in a preformatted block. Thoughts?

No, I don't like that idea.

> The same issue exists with text lines (it's impossible to display "=>"
> or "#" at the beginning of a line of text), but I'm not concerned
> about that because having to prefix such lines with a space is not a
> big deal for plain text, whereas it is for code.

I have suggested this in IRC as I've considered that someone might have
use for this, I agree with your argument, and since gemtext processing
happens only by reading the first few bytes of each line, it is
possible to introduce a new line format that is '\' which is escaped
line, where it discards line formatting that is based on the first few
characters so

>	\=> this is escaped

will print

>	=> this is escaped

also keep in mind that '\' does not only escape the character after it,
it disables line formatting, because in the example above, if '=' is
escaped, '>' is right after it and can be interpreted as a quote.

Now, even pre-formatted text toggle characters can be escaped by adding
a rule in your parser to consider '\```' within a pre-formatted text
block and translate it to literal '```'.

Anyone else who might find my suggestion unappealing or have a better
idea, feel free to share, I think this is a flaw with the gemtext
document format not to have a way to escape certain characters to
disable them from being interpreted mistakenly, all other formats do
have a mechanism for doing this.

From sean at conman.org  Tue Nov 10 02:08:34 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 9 Nov 2020 21:08:34 -0500
Subject: Escaping in gemtext
In-Reply-To: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
Message-ID: <20201110020833.GP30302@brevard.conman.org>

It was thus said that the Great Ryan Westlund once stated:
> According to the Gemtext specification, any line that starts with
> "```" is a preformatting toggle. This makes it impossible to have such
> a line as part of a preformatted block. I understand the design goals
> of Gemtext, but I believe the Markdown solution to the same problem
> can be lifted straight into Gemtext relatively easily: allow more than
> 3 backticks to open a preformatted block, and require the same number
> to close it as the number that opened it. This way, any possible text
> can be included in a preformatted block. Thoughts?
> 
> The same issue exists with text lines (it's impossible to display "=>"
> or "#" at the beginning of a line of text), but I'm not concerned
> about that because having to prefix such lines with a space is not a
> big deal for plain text, whereas it is for code.

  I was about to recommend the zero-width space, and I even created a
document for this:

	gemini://gemini.conman.org/test/escape.gemini

but I did notice that when the text is selected, the zero-width space is
also selected (as it should).  I have a second file

	gemini://gemini.conman.org/test/escape2.gemini

that uses " \b" (space, backspace character) which didn't work with
cut-n-paste (at least on Firefox on Mac OS-X) but if I viewed the resulting
file in a terminal and then did a cut-n-paste, the output was as expected.

  So the question is---how often are you going to quote material where a
line starts with ```?  Is it often enough to worry about it?  Or could you
place the example as a plain text file and link to it?

  -spc


From acdw at acdw.net  Tue Nov 10 02:19:50 2020
From: acdw at acdw.net (acdw)
Date: Tue, 10 Nov 2020 02:19:50 +0000
Subject: Escaping in gemtext
In-Reply-To: <20201110020833.GP30302@brevard.conman.org>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110020833.GP30302@brevard.conman.org>
Message-ID: <0fb9d263-9c2e-4598-b592-b7686b34d1b8@www.fastmail.com>

On 2020-11-10 (Tuesday) at 02:08, Sean Conner <sean at conman.org> wrote:

>   So the question is---how often are you going to quote material where a
> line starts with ```?  Is it often enough to worry about it?  Or could you
> place the example as a plain text file and link to it?
> 
>   -spc

10000%.  The escaping suggestion has been brought up a lot, but I have no idea when writing a line starting with ``` is 100% necessary, and couldn't be prefixed with a zero-width space or even a normal space.  Even the various "getting started with gemtext" posts, which are the only ones that might conceivably actually have need to do it (from my understanding the escaping rules in other markup are really only there so you can talk about the markup in the markup), get by just fine without doing so.  Like Sean said, if it's *really* *that* *necessary* you can just put it in a file marked text/plain.  But I really doubt that it is.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From gmym at coopdot.com  Tue Nov 10 02:25:36 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Tue, 10 Nov 2020 03:25:36 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
Message-ID: <CAObwWNgXi_Hqt80fT_=drD7Mw3fj7a5tWc0nwz=kzxbEu7AL4Q@mail.gmail.com>

Thomas M <thomas5max at gmail.com> wrote:

> Other writing systems may have their
> own way of conveying emphasis, but for the Latin script it's italics.
>

Other ways of conveying emphasis include: (in no particular order)

* Capitalization: if you're writing in a language which doesn't capitalize
all nouns.
* All-uppercase: mostly interpreted as SHOUTING.
* Letter-spacing: which looks  c h o p p y  and I don't know how a screen
reader would interpret that.
* Extra space around the word: awkward to write if your input device
insists to convert the first space into a period, like some smart phones
do. Same with  extra  space  between  all  the  words  in a sequence of
words.
* Extra space around a sentence: looks like the convention from texts with
monospace fonts where you make the transition between sentences more
visible by adding an extra space.
* One word per line: interrupts the flow of the text.
(I might have forgotten one more)

None of these can be automatically converted to italics and it's the author
who determines which notation will fit best for each document within the
constraints of the medium.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/c62666f0/attachment.htm>

From zachdecook at librem.one  Tue Nov 10 02:30:00 2020
From: zachdecook at librem.one (Zach DeCook)
Date: Mon, 09 Nov 2020 21:30:00 -0500
Subject: examples with Sympy
In-Reply-To: <87imaep1ve.fsf@cassilda.carcosa.net>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107180839.GC8281@TARS.localdomain> <20201109224431.78912d63@riseup.net>
 <87imaep1ve.fsf@cassilda.carcosa.net>
Message-ID: <0DE0419F-1EE9-4A56-8A1C-E35C7BD93A62@librem.one>

On November 9, 2020 6:05:41 PM EST, Jason McBrayer <jmcbray at carcosa.net> wrote:
>raingloom <raingloom at riseup.net> writes:
>
>> I have only one question: how will screen readers handle this?
>
>Probably very badly. Which is why I'm somewhat critical of using fixed
>format blocks for ASCII art.

>Anything which comes after the ``` characters of a line which toggles preformatted line *on* (i.e. the first, third, fifth, etc. toggling lines in a document) may be treated as "alt text" for the preformatted content.

gemini://gemini.circumlunar.space/docs/gemtext.gmi

Like

```ascii art READERS are LEADERS, which my parents used to tell me whenever I wasn't reading a book.
  _   _   .    _   _  _  _
 |_) |_  /_\  | \ |_ |_) \
 | \ |_ /   \ |_/ |_ | \ _\

            ARE
      _   .    _   _  _  _
 |   |_  /_\  | \ |_ |_) \
 |__ |_ /   \ |_/ |_ | \ _\
```

From raiz at stellarbound.space  Tue Nov 10 02:41:59 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 10 Nov 2020 05:41:59 +0300
Subject: Escaping in gemtext
In-Reply-To: <20201110020833.GP30302@brevard.conman.org>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110020833.GP30302@brevard.conman.org>
Message-ID: <20201110054159.242d7a41@home>

On Mon, 9 Nov 2020 21:08:34 -0500
Sean Conner <sean at conman.org> wrote:
>   I was about to recommend the zero-width space, and I even created a
> document for this:
> 
> 	gemini://gemini.conman.org/test/escape.gemini
> 
> but I did notice that when the text is selected, the zero-width space
> is also selected (as it should).  I have a second file
> 
> 	gemini://gemini.conman.org/test/escape2.gemini
> 
> that uses " \b" (space, backspace character) which didn't work with
> cut-n-paste (at least on Firefox on Mac OS-X) but if I viewed the
> resulting file in a terminal and then did a cut-n-paste, the output
> was as expected.

Here you're making assumptions about how \b will be rendered, I'm not
all against your approach, but I'm not also confident that all
implementations will render this properly.

>   So the question is---how often are you going to quote material
> where a line starts with ```?  Is it often enough to worry about it?
> Or could you place the example as a plain text file and link to it?

Indeed, you could also provide it in a separate text/plain file as acdw
suggested, my point is it is just annoying that no matter what I do, I
can't have a line that starts with '>', '#', '=>', '*', in gemtext,
regardless of how often anyone is gonna ever need that.

However, until I explicitly have an example of a use case that might
require that, I'm not going to propose anything at all, even if others
did, it's up to Solderpunk to approve it.

From acdw at fastmail.com  Tue Nov 10 02:14:10 2020
From: acdw at fastmail.com (Case Duckworth)
Date: Mon, 9 Nov 2020 20:14:10 -0600
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201110005957.GO30302@brevard.conman.org>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
 <20201110005957.GO30302@brevard.conman.org>
Message-ID: <73d24fec-06a7-ace5-d83d-c307946e6133@fastmail.com>

On 11/9/20 6:59 PM, Sean Conner wrote:
> It was thus said that the Great John Cowan once stated:
>>
>> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
>>
>> 1) Titles of books, movies, magazines, and other stand-alone works.
>>
>> 2) Scientific names of plants and animals.
>>
>> 3) Terms being introduced for the first time.
>>
>> 4) In narrative, the thoughts of a character.
>>
>> 5) Words being used as examples of themselves.  ("The word _the_ is a
>> definite article.")
>>
>> 6) Names of ships.
> 
> 7) Foreign words
> 
> 8) Direct thoughts---example: _Is a gom jabbar something of Arrakis I must
>     know before I go there?_ he wondered.
> 
>    -spc (The example is from Dune, of which about a third is the direct
> 	thoughts of the characters ... )
> 

Fair enough on all this --- but you know what's funny?  I can tell where 
the thoughts begin and end by the use of the formatting characters _ or 
*... and the same goes for titles of other works.  Foreign words can go 
in "'" or "*" as well, and scientific names of plants & animals are 
usually just two words, so no need.  Plus they're usually foreign 
(unless you're writing Latin) so why does it matter?  Maybe we should 
trust our readers to be smart.

AND if you really want to get into  it, italics is a little over-used, 
wouldn't you say?  We have 8 things already listed that it's for, most 
of which are barely related --- that seems like a pretty poor use of 
formatting if you ask me.  With plain text, we can use different 
characters for different things:

1) Titles of books, movies, magazines, and other stand-alone works: THE 
GREAT GATSBY.

2) Scientific names of plants and animals: Homo erectus, or `Homo 
erectus` (like verbatim)

3) Terms being introduced for the first time: 'Single quotes' are those 
which stand out enough from regular things that they're fairly obvious.

4) In narrative, the thoughts of a character: see 8

5) Words being used as examples of themselves.  ("The word _the_ is a
  definite article.") -- You could use _ here, or if you don't want 
overlap with thoughts, use *, or use ^, or use "

6) Names of ships -- (a) how often is this a thing? (b) just capitalize 
-- it's just a name. Same goes for books. Or hell, capitalize: THE DAWN 
TREADER.

7) Foreign words -- see 5, or even 2.

8) Direct thoughts---example: _Is a gom jabbar something of Arrakis I 
must know before I go there?_ he wondered. -- or put it in quotes, or 
set it off with dashes -- he thought.

What I'm saying is, I don't think emphasis markers are needed in Gemini. 
  It's pretty clear what the author is saying, and extra formatting 
isn't necessary.

~ Case

From tomasino at lavabit.com  Tue Nov 10 02:56:52 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 10 Nov 2020 02:56:52 +0000
Subject: Escaping in gemtext
In-Reply-To: <20201110054159.242d7a41@home>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110020833.GP30302@brevard.conman.org> <20201110054159.242d7a41@home>
Message-ID: <0e818f10-2cb7-1aa0-c90e-bb0b9592dcfa@lavabit.com>

On 11/10/20 2:41 AM, Ali Fardan wrote:
> However, until I explicitly have an example of a use case that might
> require that, I'm not going to propose anything at all, even if others
> did, it's up to Solderpunk to approve it.

I actually have encountered a need to write ``` literals in a gemtext file in the past. You can see such an example here:

gemini://tilde.team/~tomasino/journal/20200601-accessibility.gmi

I just used a space at the start of each line in the block. It's pretty intuitive and very easy for non-technical people to figure out.


From colecmac at protonmail.com  Tue Nov 10 02:56:48 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 10 Nov 2020 02:56:48 +0000
Subject: Escaping in gemtext
In-Reply-To: <20201110054159.242d7a41@home>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110020833.GP30302@brevard.conman.org> <20201110054159.242d7a41@home>
Message-ID: <rwEqb3pgTSm2mPOJH9Hows7VMKV3hZJQ7tYZutrB88JjNF33rj_yqnqnKw_nKxGdWj5-CK9nfA4m4qd9W2gdLtXjR-Thu_5hvMfe8CX0xh8=@protonmail.com>

> > gemini://gemini.conman.org/test/escape2.gemini
> > that uses " \b" (space, backspace character) which didn't work with
> > cut-n-paste (at least on Firefox on Mac OS-X) but if I viewed the
> > resulting file in a terminal and then did a cut-n-paste, the output
> > was as expected.
>
> Here you're making assumptions about how \b will be rendered, I'm not
> all against your approach, but I'm not also confident that all
> implementations will render this properly.

Agreed. In my client (Amfora), the \b is rendered as a space for some
unknown reason. However this seems to be an issue with terminal UI
toolkit used, as a simple command like

printf '\btest'

renders as expected on the command line, as just the word 'test'.

I find using zero width spaces to be a cool hack, and using separate files
to be an elegant solution.

makeworld


From mailinglists at ngalt.com  Tue Nov 10 03:03:21 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Mon, 9 Nov 2020 19:03:21 -0800
Subject: examples with Sympy
In-Reply-To: <20201109224431.78912d63@riseup.net>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107180839.GC8281@TARS.localdomain> <20201109224431.78912d63@riseup.net>
Message-ID: <8E25C8D4-BD59-4FE4-A92A-E27F209B3CC3@ngalt.com>



> On Nov 9, 2020, at 1:44 PM, raingloom <raingloom at riseup.net> wrote:
> 
> On Sat, 7 Nov 2020 19:08:39 +0100
> fluxion <fluxion at monocles.de> wrote:
> 
>> I thought it could be nice to show some examples rendered
>> with Sympy.
> 
> I have only one question: how will screen readers handle this?

Here?s how I would do it:

```An equation of two terms. They?re added together. The first term is an integral with respect to dx. It?s of the square root of a single fraction. The numerator of the fraction is x plus 1. The denominator of the fraction is x squared plus 3. The second term is a summation. It starts at j equals 1 and goes to n. It sums up 1 divided by j squared.
                      n     
                     ____   
?                     ?      
?      ________        ?   1 
?     ? x + 1           ?  ??
?    ?  ??????  dx +    ?   2
?   ?    2             ?   j 
? ??    x  + 3        ?      
?                     ????   
                    j = 1 
```

It?s been a long time since I?ve heard anyone talk college-level math aloud and you _definitely_ shouldn?t trust how I read the first term aloud, but this is roughly how I?d put it on my capsule.

From smallick.dev at gmail.com  Tue Nov 10 03:06:03 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Tue, 10 Nov 2020 08:36:03 +0530
Subject: Escaping in gemtext
In-Reply-To: <rwEqb3pgTSm2mPOJH9Hows7VMKV3hZJQ7tYZutrB88JjNF33rj_yqnqnKw_nKxGdWj5-CK9nfA4m4qd9W2gdLtXjR-Thu_5hvMfe8CX0xh8=@protonmail.com>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110020833.GP30302@brevard.conman.org> <20201110054159.242d7a41@home>
 <rwEqb3pgTSm2mPOJH9Hows7VMKV3hZJQ7tYZutrB88JjNF33rj_yqnqnKw_nKxGdWj5-CK9nfA4m4qd9W2gdLtXjR-Thu_5hvMfe8CX0xh8=@protonmail.com>
Message-ID: <CAFaUHvLfazKegcWSZ0j_L8oV8DFqU+aPQD+UttF9gHh4pC254Q@mail.gmail.com>

Use whitespace before the preformatted text and give warning to your
reader to be careful when copying such text.

Maybe clients could do '''Maximum Common Frontal White Space
Elimination''' in preformatted text blocks :P

~smlckz


On 11/10/20, colecmac at protonmail.com <colecmac at protonmail.com> wrote:
>> > gemini://gemini.conman.org/test/escape2.gemini
>> > that uses " \b" (space, backspace character) which didn't work with
>> > cut-n-paste (at least on Firefox on Mac OS-X) but if I viewed the
>> > resulting file in a terminal and then did a cut-n-paste, the output
>> > was as expected.
>>
>> Here you're making assumptions about how \b will be rendered, I'm not
>> all against your approach, but I'm not also confident that all
>> implementations will render this properly.
>
> Agreed. In my client (Amfora), the \b is rendered as a space for some
> unknown reason. However this seems to be an issue with terminal UI
> toolkit used, as a simple command like
>
> printf '\btest'
>
> renders as expected on the command line, as just the word 'test'.
>
> I find using zero width spaces to be a cool hack, and using separate files
> to be an elegant solution.
>
> makeworld
>
>

From rlwestlund at gmail.com  Tue Nov 10 05:19:53 2020
From: rlwestlund at gmail.com (Ryan Westlund)
Date: Tue, 10 Nov 2020 00:19:53 -0500
Subject: Escaping in gemtext
Message-ID: <CAKSVUBJorsSq0vo2=5pFNofs_zMYAJe3KEVpQYghkVz2A1dTdQ@mail.gmail.com>

So if I understand Ali Fardan's suggestion, it is to introduce starting with '\'
as a signal for a new line type which could accomodate all of these issues. I
admit I like that it solves both the issues I mentioned with one change, even
the one I didn't think really needed a solution.

The main reason I don't prefer it to my own suggestion is that it would still
mean that preformatted lines might need to be altered in some way (if the
preformatted lines contain "\```" or something), instead of allowing to paste
them in unmodified and only have to modify the prefomatting toggle lines.

And that is if escaping only considers syntax that would be interpreted anyway.
If it implemented in a context-insensitive way, meaning a line starting with
"\#" is still translated to "#" inside preformatted text, it could actually
make the problem worse by increasing the number of preformatted lines that
must be modified.

One comment on that same message:

> also keep in mind that '\' does not only escape the character after it,
> it disables line formatting, because in the example above, if '=' is
> escaped, '>' is right after it and can be interpreted as a quote.

I don't see how this is correct? A quote line must start with >, not =>.
If in "\=>", the \ escapes the = so that the resulting text is =>,
I don't see how it could be interpreted as a quote.

Ali's comment on the idea of using zero-width space
or ASCII backspace voices my own thoughts:

> Here you're making assumptions about how \b will be rendered, I'm not
> all against your approach, but I'm not also confident that all
> implementations will render this properly.

This is definitely my concern. Including invisible characters
that are outside of normal consideration seems like a bad idea.

In response to message from Sudipto Mallick:

> Use whitespace before the preformatted text and give warning
> to your reader to be careful when copying such text.

I don't like anything that requires "give warning to your reader", because
that's an admission that the markup is getting in the way. A markup format
shouldn't require telling your reader "I had to format this weirdly because
of the markup; you need to correct it".

> Maybe clients could do '''Maximum Common Frontal White Space
> Elimination''' in preformatted text blocks :P

But that could alter the meaning, for example if writing about indentation.

For the sake of use case: I write Python tutorials in Markdown, as well as
the specification for Sanemark, a variant of Markdown. Several similar issues
have come up for me before with Markdown (this specific one would've been a
major obstacle for the Sanemark spec if Markdown didn't implement what
I suggest, because leading space is significant).

From peteyboy at sdf.org  Tue Nov 10 05:45:57 2020
From: peteyboy at sdf.org (peteyboy at sdf.org)
Date: Mon, 09 Nov 2020 21:45:57 -0800
Subject: Gemtext is great...
In-Reply-To: <mailman.150.1604975402.476.gemini@lists.orbitalfox.eu>
References: <mailman.150.1604975402.476.gemini@lists.orbitalfox.eu>
Message-ID: <E2C1C942-5975-4CFE-8471-4950AAA96154@sdf.org>

I vote we leave it alone. I had all these ideas when I saw it, too, but it's really just fine as it is. As others have said, gemtext isn't the only doc format if it doesn't work for you. But for what it does, I think the design arguments ended up in a totally sweet spot for writing gemtext pages by hand.

On November 9, 2020 6:30:02 PM PST, 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: Serious writing (in the Latin script) needs italics
>      (Sean Conner)
>   2. Escaping in gemtext (Ryan Westlund)
>   3. Re: more juicy gemini content to marinate your brain (Zach ??)
>   4. Re: Escaping in gemtext (Ali Fardan)
>   5. Re: Escaping in gemtext (Sean Conner)
>   6. Re: Escaping in gemtext (acdw)
>   7. Re: Serious writing (in the Latin script) needs italics
>      (Katarina Eriksson)
>   8. Re: examples with Sympy (Zach DeCook)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 9 Nov 2020 19:59:57 -0500
>From: Sean Conner <sean at conman.org>
>To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>Subject: Re: Serious writing (in the Latin script) needs italics
>Message-ID: <20201110005957.GO30302 at brevard.conman.org>
>Content-Type: text/plain; charset=us-ascii
>
>It was thus said that the Great John Cowan once stated:
>> 
>> Contexts where that doesn't work, from WP (and yes, I'm being
>pedantic):
>> 
>> 1) Titles of books, movies, magazines, and other stand-alone works.
>> 
>> 2) Scientific names of plants and animals.
>> 
>> 3) Terms being introduced for the first time.
>> 
>> 4) In narrative, the thoughts of a character.
>> 
>> 5) Words being used as examples of themselves.  ("The word _the_ is a
>> definite article.")
>> 
>> 6) Names of ships.
>
>7) Foreign words
>
>8) Direct thoughts---example: _Is a gom jabbar something of Arrakis I
>must
>   know before I go there?_ he wondered.
>
>  -spc (The example is from Dune, of which about a third is the direct
>	thoughts of the characters ... )
>
>
>
>------------------------------
>
>Message: 2
>Date: Mon, 9 Nov 2020 20:38:08 -0500
>From: Ryan Westlund <rlwestlund at gmail.com>
>To: gemini at lists.orbitalfox.eu
>Subject: Escaping in gemtext
>Message-ID:
>	<CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw at mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>According to the Gemtext specification, any line that starts with
>"```" is a preformatting toggle. This makes it impossible to have such
>a line as part of a preformatted block. I understand the design goals
>of Gemtext, but I believe the Markdown solution to the same problem
>can be lifted straight into Gemtext relatively easily: allow more than
>3 backticks to open a preformatted block, and require the same number
>to close it as the number that opened it. This way, any possible text
>can be included in a preformatted block. Thoughts?
>
>The same issue exists with text lines (it's impossible to display "=>"
>or "#" at the beginning of a line of text), but I'm not concerned
>about that because having to prefix such lines with a space is not a
>big deal for plain text, whereas it is for code.
>
>
>------------------------------
>
>Message: 3
>Date: Mon, 9 Nov 2020 17:54:07 -0800
>From: Zach ?? <zach at anemon.es>
>To: Jason McBrayer <jmcbray at carcosa.net>
>Cc: gemini at lists.orbitalfox.eu
>Subject: Re: more juicy gemini content to marinate your brain
>Message-ID: <768C829C-CEBB-4FEA-9925-D9739111AD04 at anemon.es>
>Content-Type: text/plain;	charset=utf-8
>
>
>> This is good content, but is it a mirror of a web site? I caught a
>> 'home' link on one of the pages that tried to send me to an http
>link. 
>
>Yup! My e-worm friends aren?t technical enough to use gemini, so they
>(and our many friends who keep tabs on e-worm) access it through http.
>Sorry if that?s a faux pas in this community. Though to be fair,
>outside of a few form elements that you?ll never even see, the http
>site is basically the same as accessing the gemini site through a web
>portal.
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 10 Nov 2020 05:03:30 +0300
>From: Ali Fardan <raiz at stellarbound.space>
>To: Ryan Westlund <rlwestlund at gmail.com>
>Cc: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>Subject: Re: Escaping in gemtext
>Message-ID: <20201110050330.4877d47d at home>
>Content-Type: text/plain; charset=US-ASCII
>
>On Mon, 9 Nov 2020 20:38:08 -0500
>Ryan Westlund <rlwestlund at gmail.com> wrote:
>
>> According to the Gemtext specification, any line that starts with
>> "```" is a preformatting toggle. This makes it impossible to have
>such
>> a line as part of a preformatted block. I understand the design goals
>> of Gemtext, but I believe the Markdown solution to the same problem
>> can be lifted straight into Gemtext relatively easily: allow more
>than
>> 3 backticks to open a preformatted block, and require the same number
>> to close it as the number that opened it. This way, any possible text
>> can be included in a preformatted block. Thoughts?
>
>No, I don't like that idea.
>
>> The same issue exists with text lines (it's impossible to display
>"=>"
>> or "#" at the beginning of a line of text), but I'm not concerned
>> about that because having to prefix such lines with a space is not a
>> big deal for plain text, whereas it is for code.
>
>I have suggested this in IRC as I've considered that someone might have
>use for this, I agree with your argument, and since gemtext processing
>happens only by reading the first few bytes of each line, it is
>possible to introduce a new line format that is '\' which is escaped
>line, where it discards line formatting that is based on the first few
>characters so
>
>>	\=> this is escaped
>
>will print
>
>>	=> this is escaped
>
>also keep in mind that '\' does not only escape the character after it,
>it disables line formatting, because in the example above, if '=' is
>escaped, '>' is right after it and can be interpreted as a quote.
>
>Now, even pre-formatted text toggle characters can be escaped by adding
>a rule in your parser to consider '\```' within a pre-formatted text
>block and translate it to literal '```'.
>
>Anyone else who might find my suggestion unappealing or have a better
>idea, feel free to share, I think this is a flaw with the gemtext
>document format not to have a way to escape certain characters to
>disable them from being interpreted mistakenly, all other formats do
>have a mechanism for doing this.
>
>
>------------------------------
>
>Message: 5
>Date: Mon, 9 Nov 2020 21:08:34 -0500
>From: Sean Conner <sean at conman.org>
>To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>Subject: Re: Escaping in gemtext
>Message-ID: <20201110020833.GP30302 at brevard.conman.org>
>Content-Type: text/plain; charset=us-ascii
>
>It was thus said that the Great Ryan Westlund once stated:
>> According to the Gemtext specification, any line that starts with
>> "```" is a preformatting toggle. This makes it impossible to have
>such
>> a line as part of a preformatted block. I understand the design goals
>> of Gemtext, but I believe the Markdown solution to the same problem
>> can be lifted straight into Gemtext relatively easily: allow more
>than
>> 3 backticks to open a preformatted block, and require the same number
>> to close it as the number that opened it. This way, any possible text
>> can be included in a preformatted block. Thoughts?
>> 
>> The same issue exists with text lines (it's impossible to display
>"=>"
>> or "#" at the beginning of a line of text), but I'm not concerned
>> about that because having to prefix such lines with a space is not a
>> big deal for plain text, whereas it is for code.
>
>  I was about to recommend the zero-width space, and I even created a
>document for this:
>
>	gemini://gemini.conman.org/test/escape.gemini
>
>but I did notice that when the text is selected, the zero-width space
>is
>also selected (as it should).  I have a second file
>
>	gemini://gemini.conman.org/test/escape2.gemini
>
>that uses " \b" (space, backspace character) which didn't work with
>cut-n-paste (at least on Firefox on Mac OS-X) but if I viewed the
>resulting
>file in a terminal and then did a cut-n-paste, the output was as
>expected.
>
> So the question is---how often are you going to quote material where a
>line starts with ```?  Is it often enough to worry about it?  Or could
>you
>place the example as a plain text file and link to it?
>
>  -spc
>
>
>
>------------------------------
>
>Message: 6
>Date: Tue, 10 Nov 2020 02:19:50 +0000
>From: acdw <acdw at acdw.net>
>To: gemini at lists.orbitalfox.eu
>Subject: Re: Escaping in gemtext
>Message-ID: <0fb9d263-9c2e-4598-b592-b7686b34d1b8 at www.fastmail.com>
>Content-Type: text/plain
>
>On 2020-11-10 (Tuesday) at 02:08, Sean Conner <sean at conman.org> wrote:
>
>>   So the question is---how often are you going to quote material
>where a
>> line starts with ```?  Is it often enough to worry about it?  Or
>could you
>> place the example as a plain text file and link to it?
>> 
>>   -spc
>
>10000%.  The escaping suggestion has been brought up a lot, but I have
>no idea when writing a line starting with ``` is 100% necessary, and
>couldn't be prefixed with a zero-width space or even a normal space. 
>Even the various "getting started with gemtext" posts, which are the
>only ones that might conceivably actually have need to do it (from my
>understanding the escaping rules in other markup are really only there
>so you can talk about the markup in the markup), get by just fine
>without doing so.  Like Sean said, if it's *really* *that* *necessary*
>you can just put it in a file marked text/plain.  But I really doubt
>that it is.
>
>-- 
>~ acdw
>acdw.net | breadpunk.club/~breadw
>
>
>------------------------------
>
>Message: 7
>Date: Tue, 10 Nov 2020 03:25:36 +0100
>From: Katarina Eriksson <gmym at coopdot.com>
>To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
>Subject: Re: Serious writing (in the Latin script) needs italics
>Message-ID:
>	<CAObwWNgXi_Hqt80fT_=drD7Mw3fj7a5tWc0nwz=kzxbEu7AL4Q at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Thomas M <thomas5max at gmail.com> wrote:
>
>> Other writing systems may have their
>> own way of conveying emphasis, but for the Latin script it's italics.
>>
>
>Other ways of conveying emphasis include: (in no particular order)
>
>* Capitalization: if you're writing in a language which doesn't
>capitalize
>all nouns.
>* All-uppercase: mostly interpreted as SHOUTING.
>* Letter-spacing: which looks  c h o p p y  and I don't know how a
>screen
>reader would interpret that.
>* Extra space around the word: awkward to write if your input device
>insists to convert the first space into a period, like some smart
>phones
>do. Same with  extra  space  between  all  the  words  in a sequence of
>words.
>* Extra space around a sentence: looks like the convention from texts
>with
>monospace fonts where you make the transition between sentences more
>visible by adding an extra space.
>* One word per line: interrupts the flow of the text.
>(I might have forgotten one more)
>
>None of these can be automatically converted to italics and it's the
>author
>who determines which notation will fit best for each document within
>the
>constraints of the medium.
>
>-- 
>Katarina
>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/c62666f0/attachment-0001.htm>
>
>------------------------------
>
>Message: 8
>Date: Mon, 09 Nov 2020 21:30:00 -0500
>From: Zach DeCook <zachdecook at librem.one>
>To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>,
>	Jason McBrayer <jmcbray at carcosa.net>, raingloom <raingloom at riseup.net>
>Cc: gemini at lists.orbitalfox.eu
>Subject: Re: examples with Sympy
>Message-ID: <0DE0419F-1EE9-4A56-8A1C-E35C7BD93A62 at librem.one>
>Content-Type: text/plain; charset=utf-8
>
>On November 9, 2020 6:05:41 PM EST, Jason McBrayer
><jmcbray at carcosa.net> wrote:
>>raingloom <raingloom at riseup.net> writes:
>>
>>> I have only one question: how will screen readers handle this?
>>
>>Probably very badly. Which is why I'm somewhat critical of using fixed
>>format blocks for ASCII art.
>
>>Anything which comes after the ``` characters of a line which toggles
>preformatted line *on* (i.e. the first, third, fifth, etc. toggling
>lines in a document) may be treated as "alt text" for the preformatted
>content.
>
>gemini://gemini.circumlunar.space/docs/gemtext.gmi
>
>Like
>
>```ascii art READERS are LEADERS, which my parents used to tell me
>whenever I wasn't reading a book.
>  _   _   .    _   _  _  _
> |_) |_  /_\  | \ |_ |_) \
> | \ |_ /   \ |_/ |_ | \ _\
>
>            ARE
>      _   .    _   _  _  _
> |   |_  /_\  | \ |_ |_) \
> |__ |_ /   \ |_/ |_ | \ _\
>```
>
>
>------------------------------
>
>Subject: Digest Footer
>
>Gemini mailing list
>Gemini at lists.orbitalfox.eu
>https://lists.orbitalfox.eu/listinfo/gemini
>
>
>------------------------------
>
>End of Gemini Digest, Vol 16, Issue 31
>**************************************

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/5be964e7/attachment-0001.htm>

From smallick.dev at gmail.com  Tue Nov 10 06:38:08 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Tue, 10 Nov 2020 12:08:08 +0530
Subject: Escaping in gemtext
In-Reply-To: <CAKSVUBJorsSq0vo2=5pFNofs_zMYAJe3KEVpQYghkVz2A1dTdQ@mail.gmail.com>
References: <CAKSVUBJorsSq0vo2=5pFNofs_zMYAJe3KEVpQYghkVz2A1dTdQ@mail.gmail.com>
Message-ID: <CAFaUHvJR8gkmNjwz9Zo-4pSccFceovQ93xMRhg8c_V8wrbHYOg@mail.gmail.com>

MCFWSE (hehe) wouldn't alter meaning for most of the cases if you
think about it for a moment.

If you have a line which is *not* indented in some codeblock which has
some other lines indented, no problem: because the MCFWS (hah) is just
"" because of that non-indented line.

Now, if all of the lines in a codeblock is indented, then you have to
add some more indent, at least a space, at the front of each line, and
add another line with only that newly added indent, so that that newly
added indent is removed and rest of the indent is preserved.

[So complex. Uh! Anyone want to implement this?]
I think that the use of Zero-Width Space to escape constructs other
than code blocks is okay as they wouldn't usually be copy pasted.

~smlckz

From sean at conman.org  Tue Nov 10 07:15:56 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 10 Nov 2020 02:15:56 -0500
Subject: Escaping in gemtext
In-Reply-To: <CAKSVUBJorsSq0vo2=5pFNofs_zMYAJe3KEVpQYghkVz2A1dTdQ@mail.gmail.com>
References: <CAKSVUBJorsSq0vo2=5pFNofs_zMYAJe3KEVpQYghkVz2A1dTdQ@mail.gmail.com>
Message-ID: <20201110071556.GQ30302@brevard.conman.org>


  There's quite a bit to unpack here.

  First, let me say that the issue here is in-band signalling.  You get this
issue whenever you use some value (or characater in this case) to signal
some change in interpretation of data, and you need to use the value (or
character) *as* data and not a signal.

  HTML has this issue as well, in that it needs a way to designate a markup
tag, and it uses '<' for that (based upon its use in SGML).  But if one
needs to use '<' in regular text it needs to be escaped.  So (again, from
SGML) they use the '&' character to introduce named entities---a
representation of a character that could not otherwise be typed.  But that
means if you want to use '&' as a character, it too, needs to be escaped. 
So that means in HTML, if you want to display a '&' you escape it as "&amp;"
[1].  And to display a '<' you escape it as "&gt;".

  Gemtext does *not* have such a facility, as it complicates the processing
of the text, which is something solderpunk wanted to keep simple.  Escaping
data complicates this (I've seen complications with the proper encoding of
URLs for instance).  There is no solution (aside from serving up a plain
text file) that will easily solve this issue.

  Now on with the rest of the commentary ... 

It was thus said that the Great Ryan Westlund once stated:
> The main reason I don't prefer it to my own suggestion is that it would
> still mean that preformatted lines might need to be altered in some way
> (if the preformatted lines contain "\```" or something), instead of
> allowing to paste them in unmodified and only have to modify the
> prefomatting toggle lines.

  Sorry, no way around that.  I mean, one *could* use HTML entities:

```
Blah blah blah blah.  And now a preformatted block of code:

&DiacriticalGrave;`` 
This is a diagram
&DiacriticalGrave;`` 

```

but then the processing becomes harder as the client would then have to scan
character by character, converting entities to characters.  Or perhaps use
the standard '\' as an escape character:

```
Blah blah blah blah.  And now a preformatted block of code:

\```
This is a diagram
``\`
```

as long as at least one of the grave characters is escaped, it won't trigger
block mode (on or off).  But again, you have to process everything character
by character to handle the '\' character.  Or just decide that the following
four characters at the start of a line

	\```

is to be presented, verbatim, as 

	```

and *not* trigger block mode.  As mentioned earlier, one could just use more
than three such characters:

````````````
Look Ma!  Block mode!

It's defined as

```
...

See?

````````

But it's not really defined as three, but more than three, and again, you
have issues.  Other possibilities---use the first non ` character as a final
delimeter:

```|
To define a block mode, use three grave accents in a row, with another
character that doesn't appear in the text; said character will then end the
block mode.  For example:

```@
this is block mode
@

See?
|

Or perhaps a sequence of characters?

```end-of-line
To define a block mode, use three grave accents in a row, followed by a
sequence of non-blank characters; said sequence will end the block mode:

```EOF
This is block mode
EOF

See?
end-of-line

  Or how about this variant:

```end-of-line
Blah blah blah
```EOF
This is a sample block mode
```EOF
See?
```end-of-line

  I mean, you can go crazy with this stuff.  But every option involves more
processing than happens now.

  This is also not to say I endorse or condemn any of these methods.

> For the sake of use case: I write Python tutorials in Markdown, as well as
> the specification for Sanemark, a variant of Markdown.  

  Do you know that Markdown was created by John Gruber as an easy way to
create HTML pages, with shortcuts for the tags he used the most often,
leaving the more obscure or harder to support tags to HTML itself?  I mean,
why else would his Markdown include the ability to include HTML?  If he
needed an image (and I don't think he includes many images) he would type
the <IMG ...  > tag by hand.  The varitions come when people wanted to
*replace* all HTML with this weird shorthand notation (and then go on to
generate HTML from it) [2].

> Several similar
> issues have come up for me before with Markdown (this specific one
> would've been a major obstacle for the Sanemark spec if Markdown didn't
> implement what I suggest, because leading space is significant).

  So I looked up Sanemark, because I was curious.  And I came across this
bit where you said: [9]

> The rules for HTML blocks are overcomplicated as hell.  The spec defines 7
> different kinds of them, including support for obscure bullshit that
> should never have been invented like <?php and CDATA, and a fucking
> hardcoded list of all block-level HTML tags.  Nevermind future-proofing, I
> guess custom elements can go fuck themselves?

  The reason that abominations like "<?php" and "<![CDATA[" exist is becuase
*people wanted support for it!*  You might consider them abominations (I'll
agree with PHP [6]) but not everybody, and they do solve real issues [7]. 
And isn't trying to change the Gemini text specification a form of
contravariance? [8]  I'm just asking ...

  I'm also reminded of this quote from Bjarne Stroustrup, creator of C++:

	There are just two kinds of [programming] languages: the ones
	everybody complains about and the ones nobody uses.

  -spc (But the nice thing about standards is that there are so many to
	choose from ... )

[1]	Yes, there are four more ways to get that as well, "&#38;",
	"&#X26;", "&#x26" and "<![CDATA[&]]>", but I don't want to digress
	too much here ...

[2]	Personally, I'm not a fan of Markdown (to the degree that I rejected a
	pull request for GLV-1.12556 [3]) and *I* even created my own markup
	language [4] to make it easier for me to write blog posts.  But I
	don't *store* the blog entries in this markup language, but in their
	final HTML form.  That way, I can modify the language (it's already
	happened at least once) without having to maintain backwards
	compatability nor having to update dozens, perhaps hundreds, of
	previously written entries.

	If you are curious enough, here's the code to format it [5].

[3]	https://github.com/spc476/GLV-1.12556/pull/2

[4]	https://github.com/spc476/mod_blog/blob/master/NOTES/testmsg

[5]	https://github.com/spc476/mod_blog/blob/master/Lua/format.lua

[6]	I personally hate the language, but I can't deny that it lets many
	people who would otherwise not be able to express themselves,
	express themselves.  I console myself with the fact that I don't
	have to maintain such code, thank God.

[7]	You want to easily embed HTML sample code in HTML?  You don't have
	to entity escape every '<' and '&' and "'" but instead drop that
	mess into a single <![CDATA[ ...  ]]> block and there you go. 
	Sample HTML code in an HTML page without pain (as long as there
	isn't a <![CDATA[ ]]> block inside, which in that case, you can
	escape the leading '<' and trailing '>' with entities, which is
	*still* a lot less work than trying to safely convert HTML with
	entities.

[8]	https://yujiri.xyz/software/specs_are_contravariant

[9]	https://yujiri.xyz/sanemark

From raiz at stellarbound.space  Tue Nov 10 07:32:21 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 10 Nov 2020 10:32:21 +0300
Subject: Escaping in gemtext
In-Reply-To: <CAKSVUBJorsSq0vo2=5pFNofs_zMYAJe3KEVpQYghkVz2A1dTdQ@mail.gmail.com>
References: <CAKSVUBJorsSq0vo2=5pFNofs_zMYAJe3KEVpQYghkVz2A1dTdQ@mail.gmail.com>
Message-ID: <20201110103221.44d530f6@home>

On Tue, 10 Nov 2020 00:19:53 -0500
Ryan Westlund <rlwestlund at gmail.com> wrote:
> The main reason I don't prefer it to my own suggestion is that it
> would still mean that preformatted lines might need to be altered in
> some way (if the preformatted lines contain "\```" or something),
> instead of allowing to paste them in unmodified and only have to
> modify the prefomatting toggle lines.

Indeed it is ugly, one other workaround to this is having

>	```
>	```

interpreted as literal '```' to avoid altering preformatted text, and
to be clear, this does not apply to the case of having multiple
preformatted text blocks next to each other, this only applies to a
single preformatted text block that contains nothing.

> And that is if escaping only considers syntax that would be
> interpreted anyway. If it implemented in a context-insensitive way,
> meaning a line starting with "\#" is still translated to "#" inside
> preformatted text, it could actually make the problem worse by
> increasing the number of preformatted lines that must be modified.

I suggested a special parser rule for preformatted text blocks that is
separate for the rule used for all other text, and this rule only
applies to '^\```', though I agree with your concerns.

> > also keep in mind that '\' does not only escape the character after
> > it, it disables line formatting, because in the example above, if
> > '=' is escaped, '>' is right after it and can be interpreted as a
> > quote.  
> 
> I don't see how this is correct? A quote line must start with >, not
> =>. If in "\=>", the \ escapes the = so that the resulting text is =>,
> I don't see how it could be interpreted as a quote.

I'm pointing out to those writing parsers to avoid the pitfall of just
skipping the character after that escape character and continuing as
normal from there, I do that myself so I thought it might be worth
noting, to clarify, if the parser ignores the character that is escaped
and continues as normal from there, then:

>	\=>

escaped only the '=' which means now that '>' is the first character in
the line and can be interpreted as a quote block, of course, this is
implementation specific, and I don't know how others have implemented
their parsers.

From bie at 202x.moe  Tue Nov 10 08:12:19 2020
From: bie at 202x.moe (bie)
Date: Tue, 10 Nov 2020 17:12:19 +0900
Subject: Gemtext is great...
In-Reply-To: <E2C1C942-5975-4CFE-8471-4950AAA96154@sdf.org>
References: <mailman.150.1604975402.476.gemini@lists.orbitalfox.eu>
 <E2C1C942-5975-4CFE-8471-4950AAA96154@sdf.org>
Message-ID: <20201110081219.GA51254@202x.moe>

On Mon, Nov 09, 2020 at 09:45:57PM -0800, peteyboy at sdf.org wrote:
> I vote we leave it alone. I had all these ideas when I saw it, too, but it's really just fine as it is. As others have said, gemtext isn't the only doc format if it doesn't work for you. But for what it does, I think the design arguments ended up in a totally sweet spot for writing gemtext pages by hand.

Agreed! Adding escape characters or (especially!) inline markup would not
only make implementations more complex, it would make writing gemtext
harder to read and write, too.
I just don't feel like the trade-off is worth it. Gemtext currently
feels like a very "human" format - and even something as minor as an escape
character would move it out of that category, IMO... ?

bie

From op at omarpolo.com  Tue Nov 10 09:47:26 2020
From: op at omarpolo.com (Omar Polo)
Date: Tue, 10 Nov 2020 10:47:26 +0100
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <87y2jajou7.fsf@disroot.org>
References: <87o8k68qzy.fsf@omarpolo.com> <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>
 <87lffa8oj3.fsf@omarpolo.com> <87y2jajou7.fsf@disroot.org>
Message-ID: <87tutxr1ap.fsf@omarpolo.com>


Gary Johnson <lambdatronic at disroot.org> writes:

> Omar Polo <op at omarpolo.com> writes:
>
>> In the meantime I guess I?ll try to figure out how to teach SNI to
>> elpher.
>
> I use elpher as my Gemini client, and gemini://drewdevault.com loads
> just fine for me. I'm running elpher version 2.10.0.
>
> Cheers,
>   Gary

and it?s working indeed.  I don?t know why, but yesterday I was unable
to visit it, and elpher was failing with a timeout error.  Given the
timing, I assumed was related to this.  As I found later, elpher is
doing SNI correctly (lesson learned: when in doubt, first check the
code.)  Must have been a connection error on my end or PEBCAK.

Sorry for the noise I guess?

From pitr.vern at gmail.com  Tue Nov 10 11:06:17 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 10 Nov 2020 12:06:17 +0100
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <87tutxr1ap.fsf@omarpolo.com>
References: <87o8k68qzy.fsf@omarpolo.com> <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>
 <87lffa8oj3.fsf@omarpolo.com> <87y2jajou7.fsf@disroot.org>
 <87tutxr1ap.fsf@omarpolo.com>
Message-ID: <CAG-mZ3iFFAmXcqzdgbAJMo8_tJZRtJr7nwKD7MsJp==4pfzS7w@mail.gmail.com>

Same here with the iOS client. I could not reproduce the error William saw,
everything loads just fine.

On Tue, Nov 10, 2020 at 10:47 Omar Polo <op at omarpolo.com> wrote:

>
> Gary Johnson <lambdatronic at disroot.org> writes:
>
> > Omar Polo <op at omarpolo.com> writes:
> >
> >> In the meantime I guess I?ll try to figure out how to teach SNI to
> >> elpher.
> >
> > I use elpher as my Gemini client, and gemini://drewdevault.com loads
> > just fine for me. I'm running elpher version 2.10.0.
> >
> > Cheers,
> >   Gary
>
> and it?s working indeed.  I don?t know why, but yesterday I was unable
> to visit it, and elpher was failing with a timeout error.  Given the
> timing, I assumed was related to this.  As I found later, elpher is
> doing SNI correctly (lesson learned: when in doubt, first check the
> code.)  Must have been a connection error on my end or PEBCAK.
>
> Sorry for the noise I guess?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/62d5a76f/attachment.htm>

From trevor at rocketnine.space  Tue Nov 10 04:30:51 2020
From: trevor at rocketnine.space (trevor at rocketnine.space)
Date: Tue, 10 Nov 2020 04:30:51 +0000
Subject: Cache duration and response body size proposals
Message-ID: <bcc6368de08e053a15ef26470c445909@rocketnine.space>

Proposal: Cache duration

Gemini servers MAY include a duration (in seconds) which a client SHOULD cache
a resource when the request is successful. When a cache duration of 0 or
less is provided, clients SHOULD NOT cache the resource.

Cache for one week:

  20 text/gemini; charset=utf-8; cache=604800

Do not cache:

  20 text/gemini; charset=utf-8; cache=0

Proposal: Response body size

Gemini servers SHOULD include the size (in bytes) of the response body when the
request is successful. Clients SHOULD utilize this information when downloading
files to indicate progress.

  20 text/gemini; charset=utf-8; size=1108

These proposals are available at gemini://twins.rocketnine.space/proposals.gmi

From nothien at uber.space  Tue Nov 10 12:46:30 2020
From: nothien at uber.space (Arav K.)
Date: Tue, 10 Nov 2020 13:46:30 +0100
Subject: Cache duration and response body size proposals
In-Reply-To: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
References: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
Message-ID: <20201110124630.7xka2xsnvfxmpqof@gux>

We just had massive discussions about both of these on the ML.  I'll
provide you with some of my thoughts and consensuses(?) from the
conversations in the ML:

> Caching
> Content-Size / Content-Length

Both of these proposals and the general idea around them focuses on
the transmission of large files.  Caching is geared towards reducing
request times, and content-size/length aims to provide progress bars and
size verification.  Content hashing, which you've not discussed, is also
toward content verification.

Gemini is focused on serving small textual files.  They clearly do not
need caching.  Clients that do wish to cache should only cache backward
and forward in history (i.e. pages that the user had visited in the
current session), and should provide a reload button at least for these
pages so that they can be refreshed when needed.  In addition, large
files are not expected to be requested repeatedly (at least, Gemini is
not the protocol to do it in), so they do not need to be cached.  Small
text files are also small enough that their size does not need to be
known (as they load quickly enough to remove the need for progress bars)
and they can easily be verified by hand just by reading them (the
underlying connection is already over TLS, so receiving bad data is hard
enough as it is).

Gemini is just not good at large transmissions, and this is intentional.
If you need to do large transmissions, use other protocols that already
support content-size (and perhaps content-hash), as they are geared
towards such transmissions and will support it better.

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/af871fb9/attachment.sig>

From johann.galle at protonmail.com  Tue Nov 10 12:49:29 2020
From: johann.galle at protonmail.com (Johann Galle)
Date: Tue, 10 Nov 2020 12:49:29 +0000
Subject: Cache duration and response body size proposals
In-Reply-To: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
References: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
Message-ID: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>

Both of these proposals sound very much like introducing MIME type parameters
as geminis version of headers, which is something to be avoided if I read
the [FAQ] correctly.

> Proposal: Cache duration

This has been discussed at length in this mailing list and I personally do
not see a convincing case as to why this is necessary with typical small
gemini documents.

> Proposal: Response body size

There is a section in the FAQ specifically on why gemini does not have this:

tl;dr: It's not sensible for the small gemini documents, for larger files
you should use something else, e.g. torrent, IPFS etc.

> section 2.11 of the FAQ
> ...
> It is true that the inability for clients to tell users how much more of
> a large file still has to be downloaded and to estimate how long this may
> take means Gemini cannot provide a very user-friendly experience for large
> file downloads. However, this would be the case even if Content-length were
> specified, as such an experience would also require other complications to be
> added to the protocol e.g. the ability to resume interrupted downloads.
> Gemini documents can of course straightforwardly link to resources hosted via
> HTTPS, BitTorrent, IPFS, DAT, etc. and this may be the best option for
> very large files.

[FAQ]: gemini://gemini.circumlunar.space/docs/faq.gmi

From linde.philip at gmail.com  Tue Nov 10 12:51:58 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 13:51:58 +0100
Subject: Cache duration and response body size proposals
In-Reply-To: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
References: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
Message-ID: <20201110135158.0d77c7d12d4280a038e09a8f@gmail.com>

On Tue, 10 Nov 2020 04:30:51 +0000
trevor at rocketnine.space wrote:

> Proposal: Cache duration

> Proposal: Response body size

As suggested these basically reinvent HTTP headers in a way that's not
easily distinguishable from MIME parameters OR add exactly the kind of
global MIME parameters that RFC 2045 prohibits:

> There are NO globally-meaningful parameters that apply to all media
> types.  Truly global mechanisms are best addressed, in the MIME
> model, by the definition of additional Content-* header fields.

It's clean in implementation (old clients should be forwards
compatible insofar that they ignore MIME parameters that they don't
know, as mandated by RFC 2045) but it still doesn't conform to RFC 2045
and strikes me as a hacky solution to the problem, and at worst, a
potentially balkanizing vector for protocol extensions.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/d7cbf0cc/attachment.sig>

From jmcbray at carcosa.net  Tue Nov 10 12:52:25 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 10 Nov 2020 07:52:25 -0500
Subject: more juicy gemini content to marinate your brain
In-Reply-To: <768C829C-CEBB-4FEA-9925-D9739111AD04@anemon.es> ("Zach
 =?utf-8?B?4piB77iOIidz?=
 message of "Mon, 9 Nov 2020 17:54:07 -0800")
References: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>
 <87eel2p0yq.fsf@cassilda.carcosa.net>
 <768C829C-CEBB-4FEA-9925-D9739111AD04@anemon.es>
Message-ID: <87361hxtkm.fsf@dorothy.carcosa.net>

Zach ?? <zach at anemon.es> writes:

> Yup! My e-worm friends aren?t technical enough to use gemini, so they (and our
> many friends who keep tabs on e-worm) access it through http. Sorry if that?s a
> faux pas in this community.

It's not really a faux pas; many people mirror their blogs from the web
to Gemini (and gopher), and it's fine. I just love to see
Gemini-exclusive content.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Tue Nov 10 13:19:01 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 10 Nov 2020 08:19:01 -0500
Subject: Cache duration and response body size proposals
In-Reply-To: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 (trevor@rocketnine.space's message of "Tue, 10 Nov 2020 04:30:51 +0000")
References: <bcc6368de08e053a15ef26470c445909@rocketnine.space>
Message-ID: <87v9edwdru.fsf@dorothy.carcosa.net>

trevor at rocketnine.space writes:

>   20 text/gemini; charset=utf-8; cache=604800
>   20 text/gemini; charset=utf-8; size=1108

I think we've already discussed abusing the MIME type to hold extra
"headers", and the idea has been generally rejected.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From garritfranke at gmail.com  Tue Nov 10 13:34:23 2020
From: garritfranke at gmail.com (Garrit Franke)
Date: Tue, 10 Nov 2020 14:34:23 +0100
Subject: [ANN] Taurus - A concurrent gemini server
Message-ID: <CAD16O85hPWR54EEt5yaK08wm6opJrQnqbazT6k6kf9zHuissgQ@mail.gmail.com>

Hi all,

Taurus is my take on a gemini server.
It is written in Rust, and focuses on simplicity.
There are still some topics in the backlog [1],
but it is already very usable.

Check the project out here:
https://sr.ht/~garritfra/taurus/

Patches are always welcome!

[1]: https://todo.sr.ht/~garritfra/taurus

Regards
Garrit

From khuxkm at tilde.team  Tue Nov 10 14:17:13 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Tue, 10 Nov 2020 14:17:13 +0000
Subject: Cache duration and response body size proposals
In-Reply-To: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
References: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
Message-ID: <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>

November 10, 2020 7:49 AM, "Johann Galle" <johann.galle at protonmail.com> wrote:

> Both of these proposals sound very much like introducing MIME type parameters
> as geminis version of headers, which is something to be avoided if I read
> the [FAQ] correctly.
> 
>> Proposal: Cache duration
> 
> This has been discussed at length in this mailing list and I personally do
> not see a convincing case as to why this is necessary with typical small
> gemini documents.
> 
>> Proposal: Response body size
> 
> There is a section in the FAQ specifically on why gemini does not have this:
> 
> tl;dr: It's not sensible for the small gemini documents, for larger files
> you should use something else, e.g. torrent, IPFS etc.
> 
> - SNIP -
> 
> [FAQ]: gemini://gemini.circumlunar.space/docs/faq.gmi

I keep hearing this argument and I don't agree with it one bit. (I'm not necessarily disagreeing with *you*, Johann, just in general.)

One design criterion of Gemini is generality. As the FAQ puts it:

> But, just like HTTP can be, and is, used for much, much more than serving HTML, Gemini should be able to be used for as many other purposes as possible without compromising the simplicity and privacy criteria above.

It's *possible* to serve large files over Gemini. I can make a script that generates a large image (or I can just have a large image to serve). Therefore, you should be able to use Gemini to serve large files. The main draw I can see for a Content-Length header is being able to see if the whole file comes across the wire. The ability to resume an interrupted download need not exist; just retry the request if all of the content doesn't get across.

That being said, I am wary of making it even a SHOULD. If the file needs it (i.e; it's a big file that probably could get interrupted mid-download), then go ahead, but those of us who don't care about Content-Length or Cache duration shouldn't feel "pressured" to do it.

Just my two cents,
Robert "khuxkm" Miles (I should really set up an identity in my email client so my name shows up on the mailing list archive next to my email)

From bie at 202x.moe  Tue Nov 10 14:34:24 2020
From: bie at 202x.moe (bie)
Date: Tue, 10 Nov 2020 23:34:24 +0900
Subject: Cache duration and response body size proposals
In-Reply-To: <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
References: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
Message-ID: <20201110143424.GA67253@202x.moe>

On Tue, Nov 10, 2020 at 02:17:13PM +0000, khuxkm at tilde.team wrote:

> It's *possible* to serve large files over Gemini. I can make a script that generates a large image (or I can just have a large image to serve). Therefore, you should be able to use Gemini to serve large files. The main draw I can see for a Content-Length header is being able to see if the whole file comes across the wire. The ability to resume an interrupted download need not exist; just retry the request if all of the content doesn't get across.
> 
> That being said, I am wary of making it even a SHOULD. If the file needs it (i.e; it's a big file that probably could get interrupted mid-download), then go ahead, but those of us who don't care about Content-Length or Cache duration shouldn't feel "pressured" to do it.

I'm far from a TLS expert, so I might be completely wrong here, but
can't the client rely on the server's TLS close_notify signal to decide if
the download was interrupted? As far as I can tell, the entire point of
close_notify is to guard against data truncation...?

bie

From rlwestlund at gmail.com  Tue Nov 10 15:00:17 2020
From: rlwestlund at gmail.com (Ryan Westlund)
Date: Tue, 10 Nov 2020 10:00:17 -0500
Subject: Escaping in gemtext
Message-ID: <CAKSVUB+PPKrxAGP7CNwXUnTNi+XxU0ABTqjTTDz9gdk4gbCh=w@mail.gmail.com>

Sean Conner wrote:
>It was thus said that the Great Ryan Westlund once stated:
>> The main reason I don't prefer it to my own suggestion is that it would
>> still mean that preformatted lines might need to be altered in some way
>> (if the preformatted lines contain "\```" or something), instead of
>> allowing to paste them in unmodified and only have to modify the
>> prefomatting toggle lines.

>  Sorry, no way around that.  I mean, one *could* use HTML entities:

The point of that paragraph was that my proposal makes it so that you
only have to modify the preformatting toggle lines to paste in
arbitrary content, not the content itself. It does achieve that.
(CDATA does not because the string "]]>" ends it and there is no rule
about matching the number about brackets used to open it, so a CDATA
section cannot include "]]>".)

For what it's worth, the reason I don't think HTML needs this as much
as gemtext is because HTML already has a general escaping mechanism,
and is not necessarily meant to be written by hand anyway.



Ali Fardan wrote:
> Indeed it is ugly, one other workaround to this is having
>
>>       ```
>>       ```
>
> interpreted as literal '```' to avoid altering preformatted text, and
> to be clear, this does not apply to the case of having multiple
> preformatted text blocks next to each other, this only applies to a
> single preformatted text block that contains nothing..

Interesting. Clarification: is this like PostgreSQL string escapes,
where two consecutive toggle lines inside a block come out as a
literal "```"? Or does it only apply to empty blocks (and not the same
pattern within a block with other content), so that embedding a
literal "```" requires four in a row (one to end the current block,
then two for the literal sequence, then the fourth to open another
preformatting block - assuming two adjacent blocks will be merged)?

From khuxkm at tilde.team  Tue Nov 10 15:11:54 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Tue, 10 Nov 2020 15:11:54 +0000
Subject: Cache duration and response body size proposals
In-Reply-To: <20201110143424.GA67253@202x.moe>
References: <20201110143424.GA67253@202x.moe>
 <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
Message-ID: <4180c3480c6a37ce5898158d15b8cdd8@tilde.team>

November 10, 2020 9:34 AM, "bie" <bie at 202x.moe> wrote:

> On Tue, Nov 10, 2020 at 02:17:13PM +0000, khuxkm at tilde.team wrote:
> 
>> It's *possible* to serve large files over Gemini. I can make a script that generates a large image
>> (or I can just have a large image to serve). Therefore, you should be able to use Gemini to serve
>> large files. The main draw I can see for a Content-Length header is being able to see if the whole
>> file comes across the wire. The ability to resume an interrupted download need not exist; just
>> retry the request if all of the content doesn't get across.
>> 
>> That being said, I am wary of making it even a SHOULD. If the file needs it (i.e; it's a big file
>> that probably could get interrupted mid-download), then go ahead, but those of us who don't care
>> about Content-Length or Cache duration shouldn't feel "pressured" to do it.
> 
> I'm far from a TLS expert, so I might be completely wrong here, but
> can't the client rely on the server's TLS close_notify signal to decide if
> the download was interrupted? As far as I can tell, the entire point of
> close_notify is to guard against data truncation...?
> 
> bie

I mean, yes, that's the point of close_notify, but what if the connection dies *after* the data is sent but *before* the close_notify can be sent? Then it turns into an unsolvable two-generals problem.

I'm not *advocating* for either proposal, I'm just sick and tired of people acting like "Gemini is meant for small text files" is a good excuse to ignore proposals that could help UX when downloading larger files.

Just my two cents,
Robert "khuxkm" Miles

From johann.galle at protonmail.com  Tue Nov 10 15:18:37 2020
From: johann.galle at protonmail.com (Johann Galle)
Date: Tue, 10 Nov 2020 15:18:37 +0000
Subject: Cache duration and response body size proposals
In-Reply-To: <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
References: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
Message-ID: <wir9vCEs68VAYLYK7BTt11H7IIPZyTL8cj3H25dbSyj-SwIjlwXlnyptzwTtFOg-_hS_KApI3G_35itLa5NiEfOMkyYvyvBOYBKME-ZikK8=@protonmail.com>

On Tuesday, 10 November 2020 15:17, <khuxkm at tilde.team> wrote:
> It's possible to serve large files over Gemini.

Yes, I agree that it is possible, but I think it is not desirable to do so.
Just because you can does not mean you should.

> Therefore, you should be able to use Gemini to serve large files.

Did you not just say that it is possible?

> The main draw I can see for a Content-Length header is being able to see if
> the whole file comes across the wire.

This is really not something gemini should be worried about, that is the job of
TLS, as bie already pointed out.

> The ability to resume an interrupted download need not exist; just retry the
> request if all of the content doesn't get across.

I agree with you here too, I think the FAQ might be a bit quick to jump to
this conclusion.

> That being said, I am wary of making it even a SHOULD.
> If the file needs it ...

... you should probably use another protocol which is better suited for
transferring files, may I suggest FTP ;)

From khuxkm at tilde.team  Tue Nov 10 15:25:36 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Tue, 10 Nov 2020 15:25:36 +0000
Subject: Cache duration and response body size proposals
In-Reply-To: <wir9vCEs68VAYLYK7BTt11H7IIPZyTL8cj3H25dbSyj-SwIjlwXlnyptzwTtFOg-_hS_KApI3G_35itLa5NiEfOMkyYvyvBOYBKME-ZikK8=@protonmail.com>
References: <wir9vCEs68VAYLYK7BTt11H7IIPZyTL8cj3H25dbSyj-SwIjlwXlnyptzwTtFOg-_hS_KApI3G_35itLa5NiEfOMkyYvyvBOYBKME-ZikK8=@protonmail.com>
 <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
Message-ID: <d82047651dd8e91d81885d3c14ec159e@tilde.team>

November 10, 2020 10:18 AM, "Johann Galle" <johann.galle at protonmail.com> wrote:

> On Tuesday, 10 November 2020 15:17, <khuxkm at tilde.team> wrote:
> 
> -snip-
> 
>> The main draw I can see for a Content-Length header is being able to see if
>> the whole file comes across the wire.
> 
> This is really not something gemini should be worried about, that is the job of
> TLS, as bie already pointed out.

And as I pointed out, relying on a close_notify to determine whether the entire response was received becomes a Two Generals problem.
 
>> That being said, I am wary of making it even a SHOULD.
>> If the file needs it ...
> 
> ... you should probably use another protocol which is better suited for
> transferring files, may I suggest FTP ;)

For the last time, "just use another protocol" isn't a valid excuse. The sentence I quoted from the FAQ doesn't say "Gemini should be used for things we think it should be used for and nothing more". It says that Gemini should be used for as many things as possible, while still staying with simplicity and privacy as the other ethos. You can serve large files over Gemini, so if there's a way to make downloading large files over Gemini better for the client without massively complicating things, we should at the very least consider it.

If I need to distribute text, I should use a protocol which is better suited for transferring plain text.

May I suggest Gopher? ;)

Just my two cents,
Robert "khuxkm" Miles

From linde.philip at gmail.com  Tue Nov 10 15:29:46 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 16:29:46 +0100
Subject: Cache duration and response body size proposals
In-Reply-To: <4180c3480c6a37ce5898158d15b8cdd8@tilde.team>
References: <20201110143424.GA67253@202x.moe>
 <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
 <4180c3480c6a37ce5898158d15b8cdd8@tilde.team>
Message-ID: <20201110162946.d5cb465b7e1cb2e706b382ed@gmail.com>

On Tue, 10 Nov 2020 15:11:54 +0000
"Robert \"khuxkm\" Miles" <khuxkm at tilde.team> wrote:

> I mean, yes, that's the point of close_notify, but what if the connection dies *after* the data is sent but *before* the close_notify can be sent? Then it turns into an unsolvable two-generals problem.

Then you don't know that you received the complete data. You can
safely apply the same strategy as you would if you *did* know that you
didn't receive the complete data. It's only a problem if you make it
one.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/718daa37/attachment.sig>

From khuxkm at tilde.team  Tue Nov 10 15:36:01 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Tue, 10 Nov 2020 15:36:01 +0000
Subject: Cache duration and response body size proposals
In-Reply-To: <20201110162946.d5cb465b7e1cb2e706b382ed@gmail.com>
References: <20201110162946.d5cb465b7e1cb2e706b382ed@gmail.com>
 <20201110143424.GA67253@202x.moe>
 <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
 <4180c3480c6a37ce5898158d15b8cdd8@tilde.team>
Message-ID: <c80ad8bd426b8b2338913977815bc261@tilde.team>

November 10, 2020 10:29 AM, "Philip Linde" <linde.philip at gmail.com> wrote:

> On Tue, 10 Nov 2020 15:11:54 +0000
> "Robert \"khuxkm\" Miles" <khuxkm at tilde.team> wrote:
> 
>> I mean, yes, that's the point of close_notify, but what if the connection dies *after* the data is
>> sent but *before* the close_notify can be sent? Then it turns into an unsolvable two-generals
>> problem.
> 
> Then you don't know that you received the complete data. You can
> safely apply the same strategy as you would if you *did* know that you
> didn't receive the complete data. It's only a problem if you make it
> one.
> 
> --
> Philip

But then this goes back to the whole discussion we had about caching: sure, the overhead of a TLS connection is low, but it's not zero. If I know for a fact that the response I got has as many bytes as I was told I had, then even in the absence of a close_notify, I know for a fact I have the whole response and can be sure in that. (If I get a close_notify while not having as many bytes, I can just assume the server either lied or something else broke, and I can ask my user what to do.)

Just my two cents,
Robert "khuxkm" Miles

From phoebe at slub.co  Tue Nov 10 15:40:08 2020
From: phoebe at slub.co (phoebe jenkins)
Date: Tue, 10 Nov 2020 10:40:08 -0500
Subject: more juicy gemini content to marinate your brain
In-Reply-To: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>
References: <2DCCB7A1-2728-4AAC-AB1B-F66858F649A6@anemon.es>
Message-ID: <20201110154008.GA82427@star.local>

On Sun, Nov 08, 2020 at 05:49:37PM -0800, Zach ?? wrote:
> Hi
> 
> //e-worm.club is now on gemini
> 
> It?s mostly an aggressively unpolished look into the minds of hot twenty-somethings living rent free in the strangely vibrant hollow shell that is 2020 San Francisco.
> 
> Also there are some good critiques of ?progressive? software buried in there, but I?ll let you find those on your own.
> 
> xoxo
> Zach
> 
> PS: feel free to email me / any of us in response to any of the writings? I refuse to take the time to aggregate server logs, so it?s the only way we have of knowing whether anyone reads our stuff

i love this, makes me happy. sf felt really fucked up to me every time i
visited. happy that people are surviving out there.

From lambdatronic at disroot.org  Tue Nov 10 15:41:40 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Tue, 10 Nov 2020 10:41:40 -0500
Subject: examples with Sympy
In-Reply-To: <8E25C8D4-BD59-4FE4-A92A-E27F209B3CC3@ngalt.com>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107180839.GC8281@TARS.localdomain>
 <20201109224431.78912d63@riseup.net>
 <8E25C8D4-BD59-4FE4-A92A-E27F209B3CC3@ngalt.com>
Message-ID: <87y2j9md6z.fsf@disroot.org>

> Here?s how I would do it:
>
> ```An equation of two terms. They?re added together. The first term is an integral with respect to dx. It?s of the square root of a single fraction. The numerator of the fraction is x plus 1. The denominator of the fraction is x squared plus 3. The second term is a summation. It starts at j equals 1 and goes to n. It sums up 1 divided by j squared.
>                       n     
>                      ____   
> ?                     ?      
> ?      ________        ?   1 
> ?     ? x + 1           ?  ??
> ?    ?  ??????  dx +    ?   2
> ?   ?    2             ?   j 
> ? ??    x  + 3        ?      
> ?                     ????   
>                     j = 1 
> ```
>
> It?s been a long time since I?ve heard anyone talk college-level math aloud and you _definitely_ shouldn?t trust how I read the first term aloud, but this is roughly how I?d put it on my capsule.

+1 Nicely done.

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From wklew at mailbox.org  Tue Nov 10 15:55:15 2020
From: wklew at mailbox.org (Walter Lewis)
Date: Tue, 10 Nov 2020 10:55:15 -0500
Subject: [ANN] Project Gemini Gemini Archive
In-Reply-To: <20201108161318.s5qejbemesjiddx7@GLaDOS>
References: <20201108161318.s5qejbemesjiddx7@GLaDOS>
Message-ID: <193A140D-DF5A-4C03-B5FA-61633D22CACC@mailbox.org>

I just wanted to say this is a very inspiring project and I love what you?ve done.  Lagrange makes for a great browse of the archive, with in-line image, nicely rendered tables and the like.

Makes me want to host an archive gem too!!

From matt at going-flying.com  Tue Nov 10 16:04:37 2020
From: matt at going-flying.com (Matthew Ernisse)
Date: Tue, 10 Nov 2020 11:04:37 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>
Message-ID: <20201110160437.GA1224@ub3rgeek.net>

On Mon, Nov 09, 2020 at 11:15:54PM +0000, Johann Galle said unto me:
> I don't know if this has been pointed out before, but you can get
> rendering similar to man pages (which has things like bold and underline
> IIRC) by using troff; it should I think be fairly easy to parse,
> although I have not tried it myself. The beautiful thing of troff
> in this context is that there is also a designated MIME type
> text/troff [RFC4263]; they also have a https-site [TROFF].

I think that it's reasonable to suggest that clients implement a form of
rich text other than text/gemini.  I don't think we need to bloat text/gemini
to support every use case, instead I think we should encourage a set of
alternatives.

Reviewing the Wikipedia list of document markup languages[1] I'd lean towards
TROFF or LaTeX.  They are both mature and reasonably well defined formats.
LaTeX has the advantage of being a target for several document preprocessors
(eg: pandoc[2]) so it need not be authored in directly.

--Matt


[1]: https://en.wikipedia.org/wiki/List_of_document_markup_languages
[2]: https://pandoc.org

-- 
Matthew Ernisse
matt at going-flying.com
https://www.going-flying.com/
gemini://going-flying.com/

From mbays at sdf.org  Tue Nov 10 16:17:29 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Tue, 10 Nov 2020 17:17:29 +0100
Subject: Escaping in gemtext
In-Reply-To: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
Message-ID: <20201110161729.uvsojrpe3agobvv3@localhost>

Here's a possible solution to the problem of escapes which I don't think 
has been mentioned.

Currently each of the line types is introduced by a 1-3 char prefix with 
two exceptions: the default text line type, and the preformatted line 
type. We can deal with the escaping problem by adding prefixes for these 
too. So there's a sense in which this actually makes gemtext *simpler*, 
more regular, even as it adds more notation. As a nice side-effect, it 
also lets one- and two-liner preformatted blocks take less vertical 
space. 

The prefix for text line could be just a backslash, roughly in line with 
the suggestion elsewhere in this thread. Examples:

\#Bold# text is sometimes denoted this way.

\=> HELLO! <=

\* is the multiplication operator

\\n refers to the newline character.

\This is just an ordinary text line, the initial backslash is ignored.


And for preformatted lines, it could e.g. be "`` ":

`` $ make install

`` ```   rain
``  ```   drops

`` `` ... '' she replied, speechless.


That leaves the problem (if we're to be completist) of associating 
alt-text to a sequence of preformatted lines using this notation. We 
could say that such a sequence immediately following a preformatted 
block using "```" is considered part of the block:

``` rain drops
```
`` ```
``  ```

Alternatively (neater?) we could consider "`` " as magic even when it's 
within a preformatted block:

``` rain drops
`` ```
``  ```
```
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/3517c648/attachment.sig>

From linde.philip at gmail.com  Tue Nov 10 16:23:29 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 17:23:29 +0100
Subject: Cache duration and response body size proposals
In-Reply-To: <c80ad8bd426b8b2338913977815bc261@tilde.team>
References: <20201110162946.d5cb465b7e1cb2e706b382ed@gmail.com>
 <20201110143424.GA67253@202x.moe>
 <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
 <4180c3480c6a37ce5898158d15b8cdd8@tilde.team>
 <c80ad8bd426b8b2338913977815bc261@tilde.team>
Message-ID: <20201110172329.7b1474c0d199c534105e6051@gmail.com>

On Tue, 10 Nov 2020 15:36:01 +0000
"Robert \"khuxkm\" Miles" <khuxkm at tilde.team> wrote:

> But then this goes back to the whole discussion we had about caching: sure, the overhead of a TLS connection is low, but it's not zero. If I know for a fact that the response I got has as many bytes as I was told I had, then even in the absence of a close_notify, I know for a fact I have the whole response and can be sure in that.

Sure, but as an argument for inclusion this is not compelling enough to
warrant the proposed change IMO. Knowing for sure that you don't know
whether you have received a full response is almost as good as knowing
for sure that you have in this context. It's only in the unlikely edge
case that a server might want to send close_notify but the client fails
to receive it (and only it) that it's useful to save an additional
request, and considering the hacky piggybacking on MIME parameters the
proposal entails (that RFC 2045 in the most forgiving interpretation at
least advises against), it's a small win.

A more compelling argument IMO is that knowing the expected size in
advance, you can support progress bars and time estimates. Another
compelling argument might be that a lot of servers apparently ignore
the fact that they *have to* close_notify, which also seems like par for
the course for web servers.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/18ca7a46/attachment.sig>

From lambdatronic at disroot.org  Tue Nov 10 16:33:13 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Tue, 10 Nov 2020 11:33:13 -0500
Subject: Cache duration and response body size proposals
In-Reply-To: <20201110143424.GA67253@202x.moe>
References: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
 <20201110143424.GA67253@202x.moe>
Message-ID: <87pn4lmat2.fsf@disroot.org>

bie <bie at 202x.moe> writes:

> I'm far from a TLS expert, so I might be completely wrong here, but
> can't the client rely on the server's TLS close_notify signal to decide if
> the download was interrupted? As far as I can tell, the entire point of
> close_notify is to guard against data truncation...?
>
> bie

That's right. Here's a summary of the issues and solutions proposed on
the mailing list over the past couple of weeks regarding various
content-size and content-hash response header proposals:

1. What about caching?

   This should either be performed by clients for links visited within a
   single session or not at all. If a client performs caching, it should
   provide some way to signal that you want to clear the current page
   from the cache and reload it.

2. How do I know if I got the entire response body?

   Your client will receive a TLS close_notify message when the server
   has finished sending the response. If you don't get one, the
   connection was broken. Retry your request or don't. It's up to you.

3. What if I'm impatient and am prone to canceling requests that take a
   long time?

   Outside of network latency issues or buggy servers, this should
   really only be happening when requesting large files. Content authors
   should consider including the file size for such files in their link
   descriptions, so the user will know generally how long they might
   have to wait.

   => /foo.mp3 foo.mp3 (14 MiB)

4. Okay, the link told me it was a big file, so I waited long enough for
   it to finish, and I know I got the whole file because I received a
   TLS close_notify message...but...how do I know I got all the intended
   bytes?

   If content validation is desirable, authors should provide a content
   hash in the link description or provide a separate link to a file
   containing the content hash (e.g., foo.mp3.md5 or foo.mp3.sha256):

   => /foo.mp3 foo.mp3 (14 MiB) SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

5. Now can we add my proposal for sending content-size, content-hash,
   and cache-duration headers to Gemini responses?

   See 1-4 above.

That's all, folks!
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From sir at cmpwn.com  Tue Nov 10 16:47:07 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Tue, 10 Nov 2020 12:47:07 -0400
Subject: Statement of intent regarding document encodings
Message-ID: <C6ZQIXBYFFVB.1SN6H06XF63ZU@taiga>

I am stopping by to clarify another intepretation of the Gemini spec
made by my implementations.

https://git.sr.ht/~sircmpwn/gmni
https://git.sr.ht/~sircmpwn/kineto

With respect to the charset parameter of the document mimetype for
text/gemini documents, it is our intention to ONLY support UTF-8, and to
raise an error if any other content encoding is specified.

We won't refuse other text/* documents with an arbitrary encoding,
though we won't display them - we'll just let the user download them.
All text/gemini documents are new, and can be expected to be written in
a sane text encoding. Other text documents may use other encodings for
historical reasons, and therefore will not be refused outright.

It's 2020, and I have a zero tolerance policy for dumb encodings.

From linde.philip at gmail.com  Tue Nov 10 16:59:29 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 17:59:29 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201110160437.GA1224@ub3rgeek.net>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>
 <20201110160437.GA1224@ub3rgeek.net>
Message-ID: <20201110175929.b6316a87613ac3fdee09e883@gmail.com>

On Tue, 10 Nov 2020 11:04:37 -0500
Matthew Ernisse <matt at going-flying.com> wrote:

> I think that it's reasonable to suggest that clients implement a form of
> rich text other than text/gemini.  I don't think we need to bloat text/gemini
> to support every use case, instead I think we should encourage a set of
> alternatives.

Does the client itself really need to do this? Allow the configuration
of MIME type handlers that delegate the task to other applications and
it's no longer strictly necessary, but would the user experience suffer?

> Reviewing the Wikipedia list of document markup languages[1] I'd lean towards
> TROFF or LaTeX.  They are both mature and reasonably well defined formats.
> LaTeX has the advantage of being a target for several document preprocessors
> (eg: pandoc[2]) so it need not be authored in directly.

Those formats would both be a hard no for me. If the goal of Gemini is
to be a protocol that makes the implementation of a client and server
simple, I don't think that recommending the inclusion of full
typesetting systems is reasonable. A full distribution of LaTeX in
particular can easily eat hundreds of megabytes, even gigabytes.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/db2c77ab/attachment.sig>

From linde.philip at gmail.com  Tue Nov 10 17:09:21 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 18:09:21 +0100
Subject: Statement of intent regarding document encodings
In-Reply-To: <C6ZQIXBYFFVB.1SN6H06XF63ZU@taiga>
References: <C6ZQIXBYFFVB.1SN6H06XF63ZU@taiga>
Message-ID: <20201110180921.1d30a3baa7690446989d709f@gmail.com>

On Tue, 10 Nov 2020 12:47:07 -0400
"Drew DeVault" <sir at cmpwn.com> wrote:

> With respect to the charset parameter of the document mimetype for
> text/gemini documents, it is our intention to ONLY support UTF-8, and to
> raise an error if any other content encoding is specified.

I have opted to only support UTF-8 in my client, as well. This is
allowed by the spec. I'm not sure that I've ever come across a document
in Gemini space that uses a different encoding.

Allowing alternative encodings is a shortcoming of the spec IMO. If you
want to serve old documents, you can transcode them in advance. If your
client needs to render to a device that only supports some
non-utf8/ascii encoding (say, an old terminal), let it do the
transcoding from UTF-8 to its preferred encoding rather than burdening
every other client author with that problem.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/3f0d8b1f/attachment.sig>

From jb55 at jb55.com  Tue Nov 10 17:14:20 2020
From: jb55 at jb55.com (William Casarin)
Date: Tue, 10 Nov 2020 09:14:20 -0800
Subject: Statement of intent regarding TLS server name identification (SNI)
In-Reply-To: <CAG-mZ3iFFAmXcqzdgbAJMo8_tJZRtJr7nwKD7MsJp==4pfzS7w@mail.gmail.com>
References: <87o8k68qzy.fsf@omarpolo.com> <C6YVAD3R44AV.2CJC6O2ZC7JR8@taiga>
 <87lffa8oj3.fsf@omarpolo.com> <87y2jajou7.fsf@disroot.org>
 <87tutxr1ap.fsf@omarpolo.com>
 <CAG-mZ3iFFAmXcqzdgbAJMo8_tJZRtJr7nwKD7MsJp==4pfzS7w@mail.gmail.com>
Message-ID: <87v9eduob7.fsf@jb55.com>

Peter Vernigorov <pitr.vern at gmail.com> writes:
> Same here with the iOS client. I could not reproduce the error William
> saw, everything loads just fine.

Yup it looked like a transient issue unrelated to SNI, all good. Also
apparently it's required? by the TLS spec anyways so it seems reasonable
to enforce it.

? id:20201109205606.o44up5kpwv6oqq73 at GLaDOS

From linde.philip at gmail.com  Tue Nov 10 17:30:07 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 10 Nov 2020 18:30:07 +0100
Subject: Escaping in gemtext
In-Reply-To: <20201110161729.uvsojrpe3agobvv3@localhost>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110161729.uvsojrpe3agobvv3@localhost>
Message-ID: <20201110183007.4e7a3b907f545ab74c840d32@gmail.com>

On Tue, 10 Nov 2020 17:17:29 +0100
mbays at sdf.org wrote:

> Here's a possible solution to the problem of escapes which I don't think 
> has been mentioned.
> 
> Currently each of the line types is introduced by a 1-3 char prefix with 
> two exceptions: the default text line type, and the preformatted line 
> type. We can deal with the escaping problem by adding prefixes for these 
> too. So there's a sense in which this actually makes gemtext *simpler*, 
> more regular, even as it adds more notation. As a nice side-effect, it 
> also lets one- and two-liner preformatted blocks take less vertical 
> space.

Another side effect is that a change like this would immediately
invalidate nearly every text/gemini document in existence. Only
documents that currently don't use plain text lines or preformatted
blocks would be unaffected. Every client would also be invalidated
insofar that they would display the backslashes verbatim until they
were updated. That is a huge cost for a problem that's so far largely
hypothetical.

This looks to me like a solution waiting for a problem. Unless someone
can demonstrate a real case where the obvious workarounds (e.g.
leading whitespace) didn't suffice I don't think it warrants a change,
certainly not one that's so fundamental.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/c96607b7/attachment.sig>

From acdw at acdw.net  Tue Nov 10 17:38:50 2020
From: acdw at acdw.net (acdw)
Date: Tue, 10 Nov 2020 17:38:50 +0000
Subject: Escaping in gemtext
In-Reply-To: <20201110183007.4e7a3b907f545ab74c840d32@gmail.com>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110161729.uvsojrpe3agobvv3@localhost>
 <20201110183007.4e7a3b907f545ab74c840d32@gmail.com>
Message-ID: <daf7d894-d47d-477b-83d6-50f3cbfa25a8@www.fastmail.com>

On 2020-11-10 (Tuesday) at 17:30, Philip Linde <linde.philip at gmail.com> wrote:

> 
> This looks to me like a solution waiting for a problem. Unless someone
> can demonstrate a real case where the obvious workarounds (e.g.
> leading whitespace) didn't suffice I don't think it warrants a change,
> certainly not one that's so fundamental.

Hear, hear.  I'm tempted to buy one of those vanity domains like willgeminisupportescaping.com that just says "NO," for easy linking when this invariably comes up again.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From sir at cmpwn.com  Tue Nov 10 17:39:31 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Tue, 10 Nov 2020 13:39:31 -0400
Subject: Escaping in gemtext
In-Reply-To: <daf7d894-d47d-477b-83d6-50f3cbfa25a8@www.fastmail.com>
Message-ID: <C6ZRN1LAP7HG.3DSU8IEIXD96Y@taiga>

On Tue Nov 10, 2020 at 1:38 PM EDT, acdw wrote:
> Hear, hear. I'm tempted to buy one of those vanity domains like
> willgeminisupportescaping.com that just says "NO," for easy linking when
> this invariably comes up again.

willgeminisupport.com would be the more general solution to all of these
questions

From johann.galle at protonmail.com  Tue Nov 10 17:48:35 2020
From: johann.galle at protonmail.com (Johann Galle)
Date: Tue, 10 Nov 2020 17:48:35 +0000
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201110175929.b6316a87613ac3fdee09e883@gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>
 <20201110160437.GA1224@ub3rgeek.net>
 <20201110175929.b6316a87613ac3fdee09e883@gmail.com>
Message-ID: <4SDyg7L785XvCXRPJcTImbiQj3EPKt2PW7P2sOQUXxCZ3S-LCcZmaO5v9YYTHVUX-5lCNlkVvSY2NYOlgL_0-OLIev9kvxCJTVT8aIKkAzA=@protonmail.com>

>> I think that it's reasonable to suggest that clients implement a form of
>> rich text other than text/gemini. I don't think we need to bloat text/gemini
>> to support every use case, instead I think we should encourage a set of
>> alternatives.
>
> Does the client itself really need to do this?

No, I don't think that clients need to do this themself. They could if they want
to, but they could just as well delegate it to existing programs. To that end my
original verbalisation was not really good because the gemini client should not
be concerned with how easy it is to parse a different markup language.

> Allow the configuration of MIME type handlers that delegate the task to other
> applications and it's no longer strictly necessary,

Exactly that. For example with text/troff a client could use nroff as a backend.

> but would the user experience suffer?

I don't see how the user experience should suffer, except for maybe installation
on a platform where troff/nroff/groff/etc. is not available. That said, there is
even a version of groff for Windows. And unixoids should also covered obviously.

Of course it would probably be easier for terminal-based gemini clients than for
graphical based clients to implement something like this.

>> Reviewing the Wikipedia list of document markup languages[1] I'd lean towards
>> TROFF or LaTeX. They are both mature and reasonably well defined formats.
>> LaTeX has the advantage of being a target for several document preprocessors
>> (eg: pandoc[2]) so it need not be authored in directly.
>
> Those formats would both be a hard no for me.
...
> A full distribution of LaTeX in particular can easily eat hundreds of
> megabytes, even gigabytes.

I agree that LaTeX is probably overkill for this but seeing that troff or better
nroff were designed pretty similar to text/gemini, macros start at the start of
the line etc. its really quite simple.

> If the goal of Gemini is to be a protocol that makes the implementation of a
> client and server simple, I don't think that recommending the inclusion of
> full typesetting systems is reasonable.

At least for me this was not the point at all. It was more a recommendation that
people who want other formatting with italics etc. could use another MIME type
and not have to discuss endlessly on the mailing list and getting nowhere.
The degree of including it into the standard to be able to use it is already big
enough: You can specify which MIME type the response is. It is only a problem if
the respective client does not implement that. And I think it depends on how
deeply people want to use other formatting than provided by text/gemini if this
gets more widespread usage in documents, and if that happens, clients will start
to implement it too.

From gmi1 at scotdoyle.com  Tue Nov 10 17:53:07 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Tue, 10 Nov 2020 11:53:07 -0600
Subject: Cache duration and response body size proposals
In-Reply-To: <87pn4lmat2.fsf@disroot.org>
References: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
 <20201110143424.GA67253@202x.moe> <87pn4lmat2.fsf@disroot.org>
Message-ID: <6588ab3c-3f1d-0a0f-c47b-a47b75640f1d@scotdoyle.com>

On 11/10/20 10:33 AM, Gary Johnson wrote:
> bie <bie at 202x.moe> writes:
>
>> I'm far from a TLS expert, so I might be completely wrong here, but
>> can't the client rely on the server's TLS close_notify signal to decide if
>> the download was interrupted? As far as I can tell, the entire point of
>> close_notify is to guard against data truncation...?
>>
>> bie
> That's right. Here's a summary of the issues and solutions proposed on
> the mailing list over the past couple of weeks regarding various
> content-size and content-hash response header proposals:
>
> 1. What about caching?
>
>     This should either be performed by clients for links visited within a
>     single session or not at all. If a client performs caching, it should
>     provide some way to signal that you want to clear the current page
>     from the cache and reload it.
>
> 2. How do I know if I got the entire response body?
>
>     Your client will receive a TLS close_notify message when the server
>     has finished sending the response. If you don't get one, the
>     connection was broken. Retry your request or don't. It's up to you.
>
> 3. What if I'm impatient and am prone to canceling requests that take a
>     long time?
>
>     Outside of network latency issues or buggy servers, this should
>     really only be happening when requesting large files. Content authors
>     should consider including the file size for such files in their link
>     descriptions, so the user will know generally how long they might
>     have to wait.
>
>     => /foo.mp3 foo.mp3 (14 MiB)
>
> 4. Okay, the link told me it was a big file, so I waited long enough for
>     it to finish, and I know I got the whole file because I received a
>     TLS close_notify message...but...how do I know I got all the intended
>     bytes?
>
>     If content validation is desirable, authors should provide a content
>     hash in the link description or provide a separate link to a file
>     containing the content hash (e.g., foo.mp3.md5 or foo.mp3.sha256):
>
>     => /foo.mp3 foo.mp3 (14 MiB) SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
To further reduce the opportunity for undetected data corruption,
clients could also keep an in-memory hash of the received data and
compare this to a hash of the stored file.
> 5. Now can we add my proposal for sending content-size, content-hash,
>     and cache-duration headers to Gemini responses?
>
>     See 1-4 above.
>
> That's all, folks!
>    Gary
>


From me at adnano.co  Tue Nov 10 18:15:45 2020
From: me at adnano.co (Adnan Maolood)
Date: Tue, 10 Nov 2020 13:15:45 -0500
Subject: [ANN] astronaut - a Gemini browser for the terminal
In-Reply-To: <20201109014829.GK30302@brevard.conman.org>
Message-ID: <C6ZSESJHG8T4.1IIRNJMJ5MB7J@nitro>

On Sun Nov 8, 2020 at 3:48 PM EST, Sean Conner wrote:
> It was thus said that the Great Adnan Maolood once stated:
> > I've been working on a Gemini client for the terminal:
> > 
> > https://sr.ht/~adnano/astronaut
> > 
> > It has tabs, mouse support, and support for custom user styles.
> > 
> > It also passes all of the torture tests (except 0050, which causes
> > unicode artifacts for some reason).
>
> The title for that particular test is "Format-long line with UTF-8 with
> conbining chars and soft-hypen" so it could be your terminal is having
> issues with combining characters. It's about the worst (if not the
> worst)
> case scenario for supporting Unicode.
>
> -spc

Hmmm, it seems that my terminal emulator (alacritty) is at fault.
I just tried it in another terminal emulator, kitty, and the problem
doesn't show up.

From simon at wydooghe.com  Tue Nov 10 19:06:56 2020
From: simon at wydooghe.com (Simon Wydooghe)
Date: Tue, 10 Nov 2020 20:06:56 +0100
Subject: [ANN] Taurus - A concurrent gemini server
In-Reply-To: <CAD16O85hPWR54EEt5yaK08wm6opJrQnqbazT6k6kf9zHuissgQ@mail.gmail.com>
References: <CAD16O85hPWR54EEt5yaK08wm6opJrQnqbazT6k6kf9zHuissgQ@mail.gmail.com>
Message-ID: <160503521656.1795218.2305459139068338396@aramaki>

You probably know, but for your information, there is a load testing
tool out there called Taurus as well:
https://github.com/Blazemeter/taurus

-- 
Simon Wydooghe
+32 (0)472 83 22 30
simon at wydooghe.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/e330bfb1/attachment.sig>

From matt at going-flying.com  Tue Nov 10 20:47:46 2020
From: matt at going-flying.com (Matthew Ernisse)
Date: Tue, 10 Nov 2020 15:47:46 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201110175929.b6316a87613ac3fdee09e883@gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>
 <20201110160437.GA1224@ub3rgeek.net>
 <20201110175929.b6316a87613ac3fdee09e883@gmail.com>
Message-ID: <20201110204746.GB1224@ub3rgeek.net>

On Tue, Nov 10, 2020 at 05:59:29PM +0100, Philip Linde said unto me:
> Does the client itself really need to do this? Allow the configuration
> of MIME type handlers that delegate the task to other applications and
> it's no longer strictly necessary, but would the user experience suffer?

I'd say it's perfectly reasonable to leave the implementation details up
to the client.  I'd be perfectly happy if a terminal client went and supported
mailcap(5) for example.

> Those formats would both be a hard no for me. If the goal of Gemini is
> to be a protocol that makes the implementation of a client and server
> simple, I don't think that recommending the inclusion of full
> typesetting systems is reasonable. A full distribution of LaTeX in
> particular can easily eat hundreds of megabytes, even gigabytes.

The implementation details ultimatly are up to the client author, as I say
above if they want to just shell out to a command that's fine.  The point is
that it seems like the desire to extend text/gemini keeps coming up, so to
avoid continuing to kick the can in a circle an alternate path may be to
provide guidance to client authors so we can also provide guidance to textual
authors that desire/require the extra expression.

--Matt


-- 
Matthew Ernisse
matt at going-flying.com
https://www.going-flying.com/

From rwagner at rw-net.de  Tue Nov 10 21:22:56 2020
From: rwagner at rw-net.de (=?UTF-8?Q?Ren=C3=A9=20Wagner?=)
Date: Tue, 10 Nov 2020 22:22:56 +0100 (CET)
Subject: Escaping in gemtext
In-Reply-To: <C6ZRN1LAP7HG.3DSU8IEIXD96Y@taiga>
References: <C6ZRN1LAP7HG.3DSU8IEIXD96Y@taiga>
Message-ID: <20201110212256.530B863C080B@dd22736.kasserver.com>

> willgeminisupport.com would be the more general solution to all of these
> questions
This seems like a valid request, here we go: gemini://when.willgemini.support/?escaping


From sean at conman.org  Tue Nov 10 21:24:11 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 10 Nov 2020 16:24:11 -0500
Subject: Statement of intent regarding document encodings
In-Reply-To: <C6ZQIXBYFFVB.1SN6H06XF63ZU@taiga>
References: <C6ZQIXBYFFVB.1SN6H06XF63ZU@taiga>
Message-ID: <20201110212411.GR30302@brevard.conman.org>

It was thus said that the Great Drew DeVault once stated:
> I am stopping by to clarify another intepretation of the Gemini spec
> made by my implementations.
> 
> https://git.sr.ht/~sircmpwn/gmni
> https://git.sr.ht/~sircmpwn/kineto
> 
> With respect to the charset parameter of the document mimetype for
> text/gemini documents, it is our intention to ONLY support UTF-8, and to
> raise an error if any other content encoding is specified.

  You may want to revisit that decision and allow US-ASCII as well.  It's a
strict subset of UTF-8, and about half the text pages return that encoding:

	https://portal.mozz.us/gemini/gus.guru/statistics
	(bottom of page, by charset)

  -spc


From raiz at stellarbound.space  Tue Nov 10 22:14:42 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Wed, 11 Nov 2020 01:14:42 +0300
Subject: Cache duration and response body size proposals
In-Reply-To: <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
References: <Wt_JOONw2X60Vaq3Ld4Xgpc48Vq9K534j7EzvzZANVbde6-tPrSWcUvGUov8fdWOQV6KOim7gL9hcNXaUq76gysvSAek8qsJQxx0FIz_7cs=@protonmail.com>
 <bcc6368de08e053a15ef26470c445909@rocketnine.space>
 <f5e7e2a962aec2d6af2a1c89d0690767@tilde.team>
Message-ID: <20201111011442.67bacc3c@home>

On Tue, 10 Nov 2020 14:17:13 +0000
khuxkm at tilde.team wrote:
> I keep hearing this argument and I don't agree with it one bit. (I'm
> not necessarily disagreeing with *you*, Johann, just in general.)
> 
> One design criterion of Gemini is generality. As the FAQ puts it:
> 
> > But, just like HTTP can be, and is, used for much, much more than
> > serving HTML, Gemini should be able to be used for as many other
> > purposes as possible without compromising the simplicity and
> > privacy criteria above.  
> 
> It's *possible* to serve large files over Gemini. I can make a script
> that generates a large image (or I can just have a large image to
> serve). Therefore, you should be able to use Gemini to serve large
> files. The main draw I can see for a Content-Length header is being
> able to see if the whole file comes across the wire. The ability to
> resume an interrupted download need not exist; just retry the request
> if all of the content doesn't get across.

Just because it is possible to do this within the protocol doesn't mean
it should accommodate every use case, your use case is possible, but
not recommended, the protocol is designed for serving small text
documents, I said this million times, you just skip it and continue
your push for the "solutions" to non-existent problems in Gemini.

If you believe the protocol is limited, THAT IS BY DESIGN, if it gets
extended to allow the frequent serving of large files then nothing
stopping anyone from developing a new markup language that is meant for
Gemini that serves stylesheets and what not, I know this is against the
Gemini philosophy, but if it is, then the protocol should not provide
means for its possibility.

You have to appreciate that the community give each other a slap on the
wrist for when someone thinks that their proposal is acceptable, for
example, look at my recent suggestion to add escaped lines to gemtext,
it got rejected with valid criticism, It was explained to me it was a
bad idea so I backed off and agreed, I'm thankful for that.

Yet you refuse to address the common concerns brought to you against
your proposal, it seems that every time the mailing list moves on you
come back advocating for such feature again and again, and you get the
exact same replies... move on.

Let me quote Arav K. for you, as he brought up the same points I
brought up previously that you seemed to have ignored anyway:
On Tue, 10 Nov 2020 13:46:30 +0100
"Arav K." <nothien at uber.space> wrote:
> We just had massive discussions about both of these on the ML.  I'll
> provide you with some of my thoughts and consensuses(?) from the
> conversations in the ML:
> 
> > Caching
> > Content-Size / Content-Length  
> 
> Both of these proposals and the general idea around them focuses on
> the transmission of large files.  Caching is geared towards reducing
> request times, and content-size/length aims to provide progress bars
> and size verification.  Content hashing, which you've not discussed,
> is also toward content verification.
> 
> Gemini is focused on serving small textual files.  They clearly do not
> need caching.  Clients that do wish to cache should only cache
> backward and forward in history (i.e. pages that the user had visited
> in the current session), and should provide a reload button at least
> for these pages so that they can be refreshed when needed.  In
> addition, large files are not expected to be requested repeatedly (at
> least, Gemini is not the protocol to do it in), so they do not need
> to be cached.  Small text files are also small enough that their size
> does not need to be known (as they load quickly enough to remove the
> need for progress bars) and they can easily be verified by hand just
> by reading them (the underlying connection is already over TLS, so
> receiving bad data is hard enough as it is).
> 
> Gemini is just not good at large transmissions, and this is
> intentional. If you need to do large transmissions, use other
> protocols that already support content-size (and perhaps
> content-hash), as they are geared towards such transmissions and will
> support it better.

From ehmry at posteo.net  Tue Nov 10 23:36:07 2020
From: ehmry at posteo.net (Emery)
Date: Wed, 11 Nov 2020 00:36:07 +0100
Subject: A hack to support content length and content hash
Message-ID: <ec6fe9ac-fd51-40a4-83e3-ad7834410355@posteo.net>

Hey folks,

I've found a solution to the great content length dilema that I may have
unwisely contributed to, magnet links!

magnet:?xs=gemini://gemini.spam.works/mirrors/lainzine/lainzine.org/txt-releases/lainzine-1.txt&xl=60132&xt=urn:sha256:9e7b437857cd3939e39e0a1c953f73da3f9045fb0b878014e9917110f8652afd

Cheers,
E.

From me at adnano.co  Tue Nov 10 23:30:54 2020
From: me at adnano.co (Adnan Maolood)
Date: Tue, 10 Nov 2020 18:30:54 -0500
Subject: Spec freeze
Message-ID: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>

There seems to have been a lot of discussion recently about extending
the protocol with various features.

I propose that the spec be frozen again for some time to allow people
to be creative within the existing limitations of Gemini instead of
trying to extend the protocol.

From raiz at stellarbound.space  Tue Nov 10 23:57:13 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Wed, 11 Nov 2020 02:57:13 +0300
Subject: Spec freeze
In-Reply-To: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
Message-ID: <20201111025713.4d140a59@home>

On Tue, 10 Nov 2020 18:30:54 -0500
"Adnan Maolood" <me at adnano.co> wrote:
> There seems to have been a lot of discussion recently about extending
> the protocol with various features.
> 
> I propose that the spec be frozen again for some time to allow people
> to be creative within the existing limitations of Gemini instead of
> trying to extend the protocol.

I second that, it seems some people are invested in working within the
limitations with their creativity, see Emery's post:

On Wed, 11 Nov 2020 00:36:07 +0100
Emery <ehmry at posteo.net> wrote:
> I've found a solution to the great content length dilema that I may
> have unwisely contributed to, magnet links!
> 
> magnet:?xs=gemini://gemini.spam.works/mirrors/lainzine/lainzine.org/txt-releases/lainzine-1.txt&xl=60132&xt=urn:sha256:9e7b437857cd3939e39e0a1c953f73da3f9045fb0b878014e9917110f8652afd

From tom.karpiniec at outlook.com  Wed Nov 11 00:02:21 2020
From: tom.karpiniec at outlook.com (Thomas Karpiniec)
Date: Wed, 11 Nov 2020 00:02:21 +0000
Subject: Spec freeze
In-Reply-To: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
Message-ID: <5631EAB7-6BDE-473E-A77D-CB03DD324F02@outlook.com>


> On 11 Nov 2020, at 10:30 am, Adnan Maolood <me at adnano.co> wrote:
> 
> There seems to have been a lot of discussion recently about extending
> the protocol with various features.

It is a truism of this list that if you pop in on any given month there will be at at least one fresh proposal for including content length in the MIME type, somebody else being cheeky with non-gemini URIs, a discussion about escaping the preformatting characters, and possibly a request to remove the TLS requirement. :)

I'm not blaming anyone in particular - a lot of design discussion is buried in the mailing list archives - but many of the common themes are addressed pretty comprehensively in the FAQ and maybe we could save everybody's energy if we promoted it more: https://gemini.circumlunar.space/docs/faq.html

Cheers, Tom


From gmi1 at scotdoyle.com  Wed Nov 11 00:41:35 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Tue, 10 Nov 2020 18:41:35 -0600
Subject: Spec freeze
In-Reply-To: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
Message-ID: <d03a32d4-25da-773e-e866-2d9202c29d21@scotdoyle.com>

On 11/10/20 5:30 PM, Adnan Maolood wrote:
> There seems to have been a lot of discussion recently about extending
> the protocol with various features.
>
> I propose that the spec be frozen again for some time to allow people
> to be creative within the existing limitations of Gemini instead of
> trying to extend the protocol.
Since no one voiced an objection to my proposal of November 7th perhaps
it could still be considered for inclusion?

Something in section 1.1 or 4 to communicate that servers should/must
send a TLS close_notify message before closing the TCP connection.

From sean at conman.org  Wed Nov 11 00:48:08 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 10 Nov 2020 19:48:08 -0500
Subject: A hack to support content length and content hash
In-Reply-To: <ec6fe9ac-fd51-40a4-83e3-ad7834410355@posteo.net>
References: <ec6fe9ac-fd51-40a4-83e3-ad7834410355@posteo.net>
Message-ID: <20201111004808.GS30302@brevard.conman.org>

It was thus said that the Great Emery once stated:
> Hey folks,
> 
> I've found a solution to the great content length dilema that I may have
> unwisely contributed to, magnet links!
> 
> magnet:?xs=gemini://gemini.spam.works/mirrors/lainzine/lainzine.org/txt-releases/lainzine-1.txt&xl=60132&xt=urn:sha256:9e7b437857cd3939e39e0a1c953f73da3f9045fb0b878014e9917110f8652afd

  As a concept, this is cool, but in practice, I don't think this will work
all that well.  I thought I might try to create an alternative index page
for my Gemini site (gemini://gemini.conman.org/) with magnet: links, but ...

=> http://boston.conman.org/                    Blog
=> gopher://gopher.conman.org/1phlog.gopher     Phlog
=> gemini://gemini.conman.org/boston.gemini     Gemlog
=> mailto:sean at conman.org                       Email
=> http://www.conman.org/people/spc/            Web

  Mostly non-gemini links here, and for those, I have no control over the
size or the hash, so they would have to remain as is (unless I want to
burden my server with retrieving the size/hash of each target, which could
lead to stale information in the time between serving you the link and the
time it's actually checked).

  The one gemini link I do control, but it changes size whenever I post, so
that link would have to be updated whenever that file changes else I serve
up outdated information.

=> boston.gemini                                The Boston Diaries Feed
=> /boston/                                     The Boston Diaries Archive
=> boston.atom                                  The Boston Diaries ATOM feed
=> news.txt                                     News about this server
=> /gRFC/                                       Gemini Request For Comments
=> gemini://gemini.conman.org/sourcecode/       Source Code
=> https://github.com/spc476/GLV-1.12556        Source Code on Github
=> /extensions/                                 Custom Extensions to the Source 
=> /sourcecode/                                 Alternative Link
=> /source-code/                                Old link

  Most of these pages are dynamic in nature (although they don't change all
that often).  So this section will have to be updated as well.

  I'll spare you the rest of the links, which are more of the same.  Each
change to the server would require a near complete rebuilding of the site. 
It's a similar issue to the one I have with gopher, where the file type is
part of the URL instead of being associated with the actual content.

  -spc (That's just my take---if you like it, go ahead with it ... )


From raiz at stellarbound.space  Wed Nov 11 01:23:26 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Wed, 11 Nov 2020 04:23:26 +0300
Subject: A hack to support content length and content hash
In-Reply-To: <20201111004808.GS30302@brevard.conman.org>
References: <ec6fe9ac-fd51-40a4-83e3-ad7834410355@posteo.net>
 <20201111004808.GS30302@brevard.conman.org>
Message-ID: <20201111042326.29624a5e@home>

On Tue, 10 Nov 2020 19:48:08 -0500
Sean Conner <sean at conman.org> wrote:
>   As a concept, this is cool, but in practice, I don't think this
> will work all that well.  I thought I might try to create an
> alternative index page for my Gemini site
> (gemini://gemini.conman.org/) with magnet: links, but ...

Hypothetically, those interested in serving large files over Gemini can
write software that generates and parses magnet links for Gemini hosted
content without cluttering the protocol with features.

Hypothetically...

From lazar.michael22 at gmail.com  Wed Nov 11 02:39:58 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 10 Nov 2020 21:39:58 -0500
Subject: Adding close_notify to the spec ?
In-Reply-To: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>
References: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>
Message-ID: <CAFTy05YR99pc6Z=+EeOZhMqoGbC_KMOa8a6A8wt6PVH4oDuNLw@mail.gmail.com>

On Sat, Nov 7, 2020 at 8:19 PM Scot <gmi1 at scotdoyle.com> wrote:
>
> Does anyone have any concerns about amending the spec to state that a TLS
> close_notify message should be sent before closing the TCP connection?
> While TLS guarantees the integrity of the data from the server, it does
> not guarantee completeness until a close_notify is received by the client.
> Interested and able clients could then determine that they received a
> complete response.
>
> The sending of close_notify is discussed in section 6.1 of RFC 8446 [1].
>
> This approach was previously discussed on the list by Michael Lazar and
> solderpunk [2] [3] and kooda [4].
>
> <snip>
>
> You can inspect the TLS messages received from any server, including
> the close_notify message, with the included Python script [6].
>
> 130 out of 208 servers listed on GUS [5] send the close_notify
> message before disconnecting.

Thank you so much for this fantastic writeup! I agree with your conclusion
that close_notify should be explicitly called out in the gemini spec,
particularly in the transaction diagram under section 1.1.

I don't fault server authors for not implementing this correctly. If anything,
it just goes to show that TLS libraries are almost universally crappy and
unintuitive. We can't expect newcomers to gemini, many of whom are writing
their first server or trying out a new language, to know the inner workings of
TLS.

I took your code snippet and added to my gemini portal at https://portal.mozz.us
Now anyone can view their TLS connection details, including if the `send_alert`
message was sent, by clicking on the [view cert] link at the top of the page.
Hopefully this helps out as a quick way to test connections.

- mozz

From marcx2 at welz.org.za  Wed Nov 11 03:09:45 2020
From: marcx2 at welz.org.za (marc)
Date: Wed, 11 Nov 2020 04:09:45 +0100
Subject: Spec freeze
In-Reply-To: <d03a32d4-25da-773e-e866-2d9202c29d21@scotdoyle.com>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
 <d03a32d4-25da-773e-e866-2d9202c29d21@scotdoyle.com>
Message-ID: <20201111030945.GA17249@localhost.localdomain>

> Since no one voiced an objection to my proposal of November 7th perhaps
> it could still be considered for inclusion?
> 
> Something in section 1.1 or 4 to communicate that servers should/must
> send a TLS close_notify message before closing the TCP connection.

FWIW I support that proposal. And if it can't be included in the spec, at
least include it in the best practices document.

Why use TLS at all, if we are fine with chance or a bad guy
truncating a message ? Either use TLS properly or don't use
it at all.

regards

marc

From jordan at crowesnest.io  Wed Nov 11 04:26:35 2020
From: jordan at crowesnest.io (Jordan)
Date: Wed, 11 Nov 2020 04:26:35 +0000
Subject: [ANN] New server gemini.crowesnest.io
Message-ID: <BrfADcVjexr12D6FAWCg6Hp4WceWguVjsQFQLgC0bI@cp4-web-030.plabs.ch>

Good evening all,

I started self-hosting my own Gemini server a few weeks ago and kept
forgetting to make the ANN (annoucement). Pretty much like everyone
else this server is more personal blog like crap. I post random stuff
concerning my adventures into new hobbies such as 3d-printing. Also, I
post a few school papers; some essays, narratives, research, but only
after they are submitted and graded. Sometimes I may post some rants 
or gripes. Who knows what direction (if any direction) I will go with 
this server, for now it's for me to post anything. If you are truly 
bored I suggest checking it out. Oh! Also, like 80% of the content is
Gemini only content and I do plan on keeping a lot of ramblings Gemini
exclusive.

gemini://gemini.crowesnest.io

Thanks,

Jordan


From mbays at sdf.org  Wed Nov 11 08:00:28 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Wed, 11 Nov 2020 09:00:28 +0100
Subject: Escaping in gemtext
In-Reply-To: <20201111081814.ccbc280d18340b4a95764340@gmail.com>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110161729.uvsojrpe3agobvv3@localhost>
 <20201110183007.4e7a3b907f545ab74c840d32@gmail.com>
 <20201111062615.jomk2bkgqth7cv5x@localhost>
 <20201111081814.ccbc280d18340b4a95764340@gmail.com>
Message-ID: <20201111080028.xqdg3hdg2fx7b6cg@localhost>

[The quoted messages below didn't go to the list, but were meant to] 

* Wednesday, 2020-11-11 at 08:18 +0100 - Philip Linde <linde.philip at gmail.com>:

>On Wed, 11 Nov 2020 07:26:15 +0100
>mbays at sdf.org wrote:
>
>> Ah no, I didn't mean to remove the current rule that the default
>> interpretation of a line is as a text line, nor to remove the
>> preformatted toggle lines. So the only documents whose meaning would be
>> changed are those which have lines beginning with '\' or '`` '. I don't
>> know of any.
>
>In that case it doesn't make gemtext simpler, more regular, which is
>probably why I misunderstood you. It just adds an additional parsing
>case to the existing ones.

So it is a bit strained, but the idea is that you can describe gemtext 
in the following terms: there are various line types, each line type 
except Text and Preformatted is introduced by a 1-3 char prefix; any 
line which doesn't start with one of the prefixes is considered to be 
Text; [rules about toggling to preformatted mode]. Then this change 
would delete the "except Text and Preformatted" from this summary.

It's even more strained because alt-text doesn't fit with this "list of 
lines" interpretation of a gemtext.

Anyway, this change would be pretty close to backwards-compatible. The 
only real downside is that it adds two new magic prefixes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201111/2c94959b/attachment.sig>

From felix at masterq32.de  Wed Nov 11 08:25:37 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Wed, 11 Nov 2020 09:25:37 +0100
Subject: Escaping in gemtext
In-Reply-To: <20201110020833.GP30302@brevard.conman.org>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110020833.GP30302@brevard.conman.org>
Message-ID: <34c79466-6962-05c7-870b-3bdc7f3d5ba5@masterq32.de>

Hey!

I just tested both of your approaches with Kristall:

>   I was about to recommend the zero-width space, and I even created a
> document for this:
>
> 	gemini://gemini.conman.org/test/escape.gemini
>
> but I did notice that when the text is selected, the zero-width space
> is also selected (as it should).

https://mq32.de/public/05851bad5b5e23d9e24bcaa7f259ab6de55c17d0.png
Looks okay, works as expected

>I have a second file
>
> 	gemini://gemini.conman.org/test/escape2.gemini
>
> that uses " \b" (space, backspace character) which didn't work with
> cut-n-paste (at least on Firefox on Mac OS-X) but if I viewed the
> resulting file in a terminal and then did a cut-n-paste, the output
> was as expected.

https://mq32.de/public/2a35ca5e121d2373f9390315c4857dd58c198ca8.png

I think the zero-width space solution is okay, using
'<SPACE><BACKSPACE>' is not, as it's not rendered correctly in anything
that is not a plain terminal:

vi, vim, and nano display that file as ' ^H'

gedit will display ' ?' where ? is a replacement character:
https://mq32.de/public/be09184d3c095251bf2f31ad2bd0685a8a2f0741.png

castor displays the same replacement character:
https://mq32.de/public/408e8c8b1fdc92c70d601c6def64bb5121d64754.png

Regards
- xq

From sean at conman.org  Wed Nov 11 08:44:32 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 11 Nov 2020 03:44:32 -0500
Subject: Escaping in gemtext
In-Reply-To: <34c79466-6962-05c7-870b-3bdc7f3d5ba5@masterq32.de>
References: <CAKSVUB+k7UTkO7Gz0USBfzL_vdj3Vv+tt7WcuSemGNu+xukxqw@mail.gmail.com>
 <20201110020833.GP30302@brevard.conman.org>
 <34c79466-6962-05c7-870b-3bdc7f3d5ba5@masterq32.de>
Message-ID: <20201111084431.GT30302@brevard.conman.org>

It was thus said that the Great Felix Quei?ner once stated:
> Hey!
> 
> I just tested both of your approaches with Kristall:
> 
> >   I was about to recommend the zero-width space, and I even created a
> > document for this:
> >
> > 	gemini://gemini.conman.org/test/escape.gemini
> >
> > but I did notice that when the text is selected, the zero-width space
> > is also selected (as it should).
> 
> https://mq32.de/public/05851bad5b5e23d9e24bcaa7f259ab6de55c17d0.png
> Looks okay, works as expected

  Yes, but select the text, paste it elsewhere and see if the zero-width
space character show up.  It did when I tried it.

  -spc


From ehmry at posteo.net  Wed Nov 11 09:50:05 2020
From: ehmry at posteo.net (Emery)
Date: Wed, 11 Nov 2020 10:50:05 +0100
Subject: Spec freeze
In-Reply-To: <5631EAB7-6BDE-473E-A77D-CB03DD324F02@outlook.com>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
 <5631EAB7-6BDE-473E-A77D-CB03DD324F02@outlook.com>
Message-ID: <48a34b93-4fe2-466f-9c88-4ee0a7ebc64e@posteo.net>

On Mittwoch, 11. November 2020 01:02:21 CET, Thomas Karpiniec wrote:
> It is a truism of this list that if you pop in on any given 
> month there will be at at least one fresh proposal for including 
> content length in the MIME type, somebody else being cheeky with 
> non-gemini URIs, a discussion about escaping the preformatting 
> characters, and possibly a request to remove the TLS 
> requirement. :)

I'm also in favor of freezing the spec. I think the meaningful
experiments that haven't happened are higher-level, and the protocol
discussions feel like a distraction.

Emery

From bjorn.warmedal at gmail.com  Wed Nov 11 09:50:29 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Wed, 11 Nov 2020 10:50:29 +0100
Subject: Spec freeze
In-Reply-To: <20201111030945.GA17249@localhost.localdomain>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
 <d03a32d4-25da-773e-e866-2d9202c29d21@scotdoyle.com>
 <20201111030945.GA17249@localhost.localdomain>
Message-ID: <CAJScK0JKta3rfk4NANhBnX7PvjG9ugeGY+11oivo_vQbEuX76Q@mail.gmail.com>

I'm against a protocol freeze for two reasons.

1. I don't see any feature creep as of yet. Many *suggestions*, but so
far none that have been accepted.
2. There are parts of the specification that need clarification. I.e.
the "Empty META" question a short while back. I would much rather see
an engaged discussion about finding and clarifying ambiguity in the
protocol specification than suggestions of new features, honestly. I
think that's where the large gains are to be made. The community at
large seems to have agreed that the protocol is very close to final,
and feature suggestions are often met with "solve it with a different
protocol" or "use a different filetype" (in the case of gemtext
questions).

Cheers,
ew0k

From raiz at stellarbound.space  Wed Nov 11 10:03:30 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Wed, 11 Nov 2020 13:03:30 +0300
Subject: Spec freeze
In-Reply-To: <CAJScK0JKta3rfk4NANhBnX7PvjG9ugeGY+11oivo_vQbEuX76Q@mail.gmail.com>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
 <d03a32d4-25da-773e-e866-2d9202c29d21@scotdoyle.com>
 <20201111030945.GA17249@localhost.localdomain>
 <CAJScK0JKta3rfk4NANhBnX7PvjG9ugeGY+11oivo_vQbEuX76Q@mail.gmail.com>
Message-ID: <20201111130330.4c4027af@home>

On Wed, 11 Nov 2020 10:50:29 +0100
Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 2. There are parts of the specification that need clarification. I.e.
> the "Empty META" question a short while back. I would much rather see
> an engaged discussion about finding and clarifying ambiguity in the
> protocol specification than suggestions of new features, honestly. I
> think that's where the large gains are to be made.

As far as I can remember if my memory serves me right, solderpunk said
he'd update the spec for that, this is an acceptable change.

This and the TLS related proposals.

From fluxion at monocles.de  Wed Nov 11 10:08:32 2020
From: fluxion at monocles.de (fluxion)
Date: Wed, 11 Nov 2020 11:08:32 +0100
Subject: examples with Sympy
In-Reply-To: <87y2j9md6z.fsf@disroot.org>
References: <mailman.3.1604750415.23154.gemini@lists.orbitalfox.eu>
 <20201107180839.GC8281@TARS.localdomain>
 <20201109224431.78912d63@riseup.net>
 <8E25C8D4-BD59-4FE4-A92A-E27F209B3CC3@ngalt.com>
 <87y2j9md6z.fsf@disroot.org>
Message-ID: <20201111100832.GA8134@TARS.localdomain>

> >
> > ```An equation of two terms. They?re added together. The first term is an integral with respect to dx. It?s of the square root of a single fraction. The numerator of the fraction is x plus 1. The denominator of the fraction is x squared plus 3. The second term is a summation. It starts at j equals 1 and goes to n. It sums up 1 divided by j squared.
> >                       n     
> >                      ____   
> > ?                     ?      
> > ?      ________        ?   1 
> > ?     ? x + 1           ?  ??
> > ?    ?  ??????  dx +    ?   2
> > ?   ?    2             ?   j 
> > ? ??    x  + 3        ?      
> > ?                     ????   
> >                     j = 1 
> > ```
> >
> > It?s been a long time since I?ve heard anyone talk college-level math aloud and you _definitely_ shouldn?t trust how I read the first term aloud, but this is roughly how I?d put it on my capsule.
> 
> +1 Nicely done.
> 
I also love this. Sometimes we are blind to the most simple and nice way
of doing something. Thanks!

From gmym at coopdot.com  Wed Nov 11 12:32:50 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Wed, 11 Nov 2020 13:32:50 +0100
Subject: Spec freeze
In-Reply-To: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
Message-ID: <CAObwWNie6NGSen3CsdFXTtCA4f23Bm7hb5QTnQkD-J_+hakv3A@mail.gmail.com>

Solderpunk proposed a plan for spec freezes in the beginning of March
https://lists.orbitalfox.eu/archives/gemini/2020/000463.html

Permanent freeze
https://lists.orbitalfox.eu/archives/gemini/2020/001708.html


Den ons 11 nov. 2020 00:40Adnan Maolood <me at adnano.co> skrev:

> There seems to have been a lot of discussion recently about extending
> the protocol with various features.
>
> I propose that the spec be frozen again for some time to allow people
> to be creative within the existing limitations of Gemini instead of
> trying to extend the protocol.
>

As far as I know, we are already in a spec freeze since the middle of June.

If we go by the original plan, presented by Solderpunk when we entered the
first freeze back in the beginning of March[1], the second freeze would end
in the middle of December. However, it seems like Solderpunk changed his
mind when we entered the second freeze in the middle of June[2], going for
a permanent freeze instead. This permanent freeze is only on non-trivial
new features.

The way I interpreted this is that we will not add features and we have to
wait until December to clear things up in the spec. Please let me know if I
missed something.

--
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201111/29603208/attachment.htm>

From gmym at coopdot.com  Wed Nov 11 12:38:05 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Wed, 11 Nov 2020 13:38:05 +0100
Subject: Spec freeze
In-Reply-To: <CAObwWNie6NGSen3CsdFXTtCA4f23Bm7hb5QTnQkD-J_+hakv3A@mail.gmail.com>
References: <C6ZZ431SVOCS.3HQNGFO6K643E@nitro>
 <CAObwWNie6NGSen3CsdFXTtCA4f23Bm7hb5QTnQkD-J_+hakv3A@mail.gmail.com>
Message-ID: <CAObwWNimYKGeznrUa0aDav_0Sb+JJW0QObjx9u8Y+URZ+nRqZA@mail.gmail.com>

Oops, I sent the reply before moving the footnotes to the bottom.


[1]

> https://lists.orbitalfox.eu/archives/gemini/2020/000463.html
>

[2]

> https://lists.orbitalfox.eu/archives/gemini/2020/001708.html
>

-- 
Katarina

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201111/d7b3163d/attachment.htm>

From gmi1 at scotdoyle.com  Wed Nov 11 12:55:20 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Wed, 11 Nov 2020 06:55:20 -0600
Subject: Adding close_notify to the spec ?
In-Reply-To: <CAFTy05YR99pc6Z=+EeOZhMqoGbC_KMOa8a6A8wt6PVH4oDuNLw@mail.gmail.com>
References: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>
 <CAFTy05YR99pc6Z=+EeOZhMqoGbC_KMOa8a6A8wt6PVH4oDuNLw@mail.gmail.com>
Message-ID: <95445f0f-9537-5c96-e347-67fe6cc3f243@scotdoyle.com>

On 11/10/20 8:39 PM, Michael Lazar wrote:
> On Sat, Nov 7, 2020 at 8:19 PM Scot <gmi1 at scotdoyle.com> wrote:
>
> Does anyone have any concerns about amending the spec to state that a TLS
> close_notify message should be sent before closing the TCP connection?
> While TLS guarantees the integrity of the data from the server, it does
> not guarantee completeness until a close_notify is received by the client.
> Interested and able clients could then determine that they received a
> complete response.
>
> The sending of close_notify is discussed in section 6.1 of RFC 8446 [1].
>
> This approach was previously discussed on the list by Michael Lazar and
> solderpunk [2] [3] and kooda [4].
>
> <snip>
>
> You can inspect the TLS messages received from any server, including
> the close_notify message, with the included Python script [6].
>
> 130 out of 208 servers listed on GUS [5] send the close_notify
> message before disconnecting.
> Thank you so much for this fantastic writeup! I agree with your conclusion
> that close_notify should be explicitly called out in the gemini spec,
> particularly in the transaction diagram under section 1.1.
>
> I don't fault server authors for not implementing this correctly. If anything,
> it just goes to show that TLS libraries are almost universally crappy and
> unintuitive. We can't expect newcomers to gemini, many of whom are writing
> their first server or trying out a new language, to know the inner workings of
> TLS.
I agree. Even Python's TLS library does not send it by default when
closing an SSLSocket connection. Maybe now that the TLS 1.3 spec allows
unidirectional close_notify the library situation will slowly improve.
>
> I took your code snippet and added to my gemini portal at https://portal.mozz.us
> Now anyone can view their TLS connection details, including if the `send_alert`
> message was sent, by clicking on the [view cert] link at the top of the page.
> Hopefully this helps out as a quick way to test connections.
https://portal.mozz.us looks useful. Of the five servers I tested there
our results match.
>
> - mozz


From jonas-mueller at mailbox.org  Wed Nov 11 07:24:21 2020
From: jonas-mueller at mailbox.org (=?utf-8?q?Jonas_M=C3=BCller?=)
Date: Wed, 11 Nov 2020 08:24:21 +0100
Subject: Escaping in gemtext
In-Reply-To: <20201110212256.530B863C080B@dd22736.kasserver.com>
Message-ID: <C7096L8VQO3S.2POQLD4SUZ8R9@tigger-mp>

On Tue Nov 10, 2020, Ren? Wagner wrote:
> This seems like a valid request, here we go:
> gemini://when.willgemini.support/?escaping

Nicely done :)

From me at rwv.io  Wed Nov 11 08:08:08 2020
From: me at rwv.io (Remco)
Date: Wed, 11 Nov 2020 09:08:08 +0100
Subject: Adding close_notify to the spec ?
In-Reply-To: <CAFTy05YR99pc6Z=+EeOZhMqoGbC_KMOa8a6A8wt6PVH4oDuNLw@mail.gmail.com>
References: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>
 <CAFTy05YR99pc6Z=+EeOZhMqoGbC_KMOa8a6A8wt6PVH4oDuNLw@mail.gmail.com>
Message-ID: <87ft5g1fkn.fsf@rwv.io>

2020/11/11 03:39, Michael Lazar:

> I took your code snippet and added to my gemini portal at https://portal.mozz.us
> Now anyone can view their TLS connection details, including if the `send_alert`
> message was sent, by clicking on the [view cert] link at the top of the page.
> Hopefully this helps out as a quick way to test connections.

Thanks that's very helpful!

R.

From me at adnano.co  Wed Nov 11 12:50:21 2020
From: me at adnano.co (Adnan Maolood)
Date: Wed, 11 Nov 2020 07:50:21 -0500
Subject: Clarifications to the Spec
Message-ID: <C70G46VKAIWA.2O918IYGKC9FI@nitro>

Based on recent discussion, I believe the following clarifications
should be made to the spec:

- Is it valid for META to contain the line feed character?
	10 Is\nThis\nValid?\r\n
- Is it valid for META to be empty?
- Should servers be required to send TLS close_notify?

From cowan at ccil.org  Wed Nov 11 15:15:12 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 11 Nov 2020 10:15:12 -0500
Subject: Statement of intent regarding document encodings
In-Reply-To: <20201110212411.GR30302@brevard.conman.org>
References: <C6ZQIXBYFFVB.1SN6H06XF63ZU@taiga>
 <20201110212411.GR30302@brevard.conman.org>
Message-ID: <CAD2gp_QnHphg+ECeyXOUePiFUve=rydM3Dm66koE3mrHW=cGoA@mail.gmail.com>

+1.  Even Google does not distinguish them when it spiders the web, which
means that more than 95% of all pages are UTF-8 (by actual inspection, not
by Content-Type: declaration).

On Tue, Nov 10, 2020 at 4:24 PM Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great Drew DeVault once stated:
> > I am stopping by to clarify another intepretation of the Gemini spec
> > made by my implementations.
> >
> > https://git.sr.ht/~sircmpwn/gmni
> > https://git.sr.ht/~sircmpwn/kineto
> >
> > With respect to the charset parameter of the document mimetype for
> > text/gemini documents, it is our intention to ONLY support UTF-8, and to
> > raise an error if any other content encoding is specified.
>
>   You may want to revisit that decision and allow US-ASCII as well.  It's a
> strict subset of UTF-8, and about half the text pages return that encoding:
>
>         https://portal.mozz.us/gemini/gus.guru/statistics
>         (bottom of page, by charset)
>
>   -spc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201111/1b7f8732/attachment-0001.htm>

From escondida at iff.ink  Wed Nov 11 15:46:36 2020
From: escondida at iff.ink (Ivy Foster)
Date: Wed, 11 Nov 2020 09:46:36 -0600
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201110204746.GB1224@ub3rgeek.net>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>
 <20201110160437.GA1224@ub3rgeek.net>
 <20201110175929.b6316a87613ac3fdee09e883@gmail.com>
 <20201110204746.GB1224@ub3rgeek.net>
Message-ID: <20201111154636.GA653@thrax.localdomain>

Matthew Ernisse <matt at going-flying.com> wrote:
> On Mon, Nov 09, 2020 at 11:15:54PM +0000, Johann Galle said unto me:
> > I don't know if this has been pointed out before, but you can get
> > rendering similar to man pages (which has things like bold and
> > underline IIRC) by using troff; it should I think be fairly easy to
> > parse, although I have not tried it myself. The beautiful thing of
> > troff in this context is that there is also a designated MIME type
> > text/troff [RFC4263]; they also have a https-site [TROFF].

> I think that it's reasonable to suggest that clients implement a form
> of rich text other than text/gemini.  I don't think we need to bloat
> text/gemini to support every use case, instead I think we should
> encourage a set of alternatives.

The further discussion of this point has seemed to assume a need to
implement all of troff (and then spun off into LaTeX). I'd like to
propose an alternative: the tiniest subset of it. Specifically:

.I "italic text" optional-suffix optional-prefix

E.g., this contrived example with a poor use of parentheses:

----
"I think we should represent italics
.I "somehow" !"
she said.
.I "After all, this is a medium designed for writing." ) (
----

would yield (where *this* is italicized):

----
"I think we should represent italics *somehow*!" she said.
(*After all, this is a medium designed for writing.*)
----

As with troff, .I would *not* add line breaks. Unlike troff, this
should *only* have the line-based option, and not the option to make
it apply to all further text until the next line beginning with ".R".
That does make writing a whole italicized paragraph or page more
cumbersome, but that's a pretty unusual use case.

Incidentally, troff is a topic likely to interest those into gemini:
it's a far more lightweight typesetting system than LaTeX, though it
has its limitations, and like text/gemini it is very much line-based.
It also follows the rule that (almost) any formatting command should
be short and at the start of the line.

Also, I do recognize that this idea is going to get shot down as
paving the way for more extensibility, though we already have things
like verbatim blocks and what have you (which are more esoteric than
italic, so I don't buy the "we shouldn't support every use case"
argument. It's far more common to emphasize words, to write titles of
works, and so forth, than it is to do ASCII art (not that there's
anything wrong with ASCII art; it's great) or present code blocks (the
current demographics of the medium notwithstanding)).

As to using CAPS LOCK as a substitute for italics, that is just not
feasible for anything longer than a word or two.

OBSERVE, AS YOU READ THIS PARAGRAPH, THAT IT IS LESS COMFORTABLE TO
READ THAN ONE WRITTEN WITH STANDARD TYPOGRAPHY. EVEN THE ROMANS
FINALLY GAVE IN AND INVENTED MINISCULE LETTERS FOR THEIR ALPHABET, AND
THAT'S AFTER RESISTING FOR CENTURIES THE IDEA OF EVEN USING SPACES
OR CLAUDIAN DOTS BETWEEN WORDS, SO LITTLE DID THEY CARE ABOUT
READABILITY.

Using *emphasis* is a pretty acceptable solution most of the time, I
think, but it does fall apart a bit with longer passages or titles:
*Doctor Strangelove, or How I Learned to Stop Worrying and Love the
Bomb*, for instance.

Finally, before anybody asks, I would argue that we *don't* need bold
text or bold italic. Bold is rarely used in serious writing; it's used
far more often in graphic design and advertising, neither of which
fields is going to have much fun with gemini, I'm glad to say. If they
were to try, they'd basically just need to serve whole pictures,
anyway.

Just some thoughts on the matter.

Cheers,
Ivy Foster
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201111/9d1f467c/attachment.sig>

From johann.galle at protonmail.com  Wed Nov 11 15:47:42 2020
From: johann.galle at protonmail.com (Johann Galle)
Date: Wed, 11 Nov 2020 15:47:42 +0000
Subject: Clarifications to the Spec
In-Reply-To: <C70G46VKAIWA.2O918IYGKC9FI@nitro>
References: <C70G46VKAIWA.2O918IYGKC9FI@nitro>
Message-ID: <briUs5E76gBds8SgbeQw44EO4rStvQDN09WrPjoe3GjfIxQl9tXTB89asXuA6lKSt6S5ugqIRuUM54GjxzzG2uSlOQX0Uc-a6LfQVXbFlmU=@protonmail.com>

> -   Is it valid for META to contain the line feed character?
>     10 Is\nThis\nValid?\r\n

As it stands, it should be legal because \n can be distinguished from \r\n. But
I think not many clients are as strictly written to the spec as to handle this
correctly, most would probably consider the meta ended after the first \n.

My personal opinion is that it should not be allowed and that the line ending
should be just \n, but maybe this is a use case that was considered when writing
the gemni spec?

> -   Is it valid for META to be empty?

I do not see a reason why it should never be allowed to be empty from the spec.
It only states a max length of 1024 bytes and UTF-8 encoding. (?3.1)
In some cases I would consider it illegal in context with 3x status codes.

Reasonable behaviour of a client for empty META would be IMHO:
????????????????????????????????????????????????????????????????????????????????
?1x?Display as normal, but the user gets no message. This might look strange,  ?
?  ?but that is something the particular server admin should fix, not gemini.  ?
????????????????????????????????????????????????????????????????????????????????
?2x?Assume a default MIME type of text/gemini.                                 ?
????????????????????????????????????????????????????????????????????????????????
?3x?This should be a hard error, the sentence in ?3.2.3 might be rephrased as: ?
?  ?"<META> MUST be a new URL for the requested resource."                     ?
????????????????????????????????????????????????????????????????????????????????
?4x?Show a default error message, which might be based on the exact status code?
?5x?                                                                           ?
????????????????????????????????????????????????????????????????????????????????
?6x?No difference, META is only informational.                                 ?
????????????????????????????????????????????????????????????????????????????????

> -   Should servers be required to send TLS close_notify?

I think it has been laid out that this is included in the TLS spec and thus it
is non-optional. Also, the spec explicitly states that the server closes the
connection which - with TLS - includes sending close_notify.

From smallick.dev at gmail.com  Wed Nov 11 16:32:05 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Wed, 11 Nov 2020 22:02:05 +0530
Subject: Clarifications to the Spec
In-Reply-To: <briUs5E76gBds8SgbeQw44EO4rStvQDN09WrPjoe3GjfIxQl9tXTB89asXuA6lKSt6S5ugqIRuUM54GjxzzG2uSlOQX0Uc-a6LfQVXbFlmU=@protonmail.com>
References: <C70G46VKAIWA.2O918IYGKC9FI@nitro>
 <briUs5E76gBds8SgbeQw44EO4rStvQDN09WrPjoe3GjfIxQl9tXTB89asXuA6lKSt6S5ugqIRuUM54GjxzzG2uSlOQX0Uc-a6LfQVXbFlmU=@protonmail.com>
Message-ID: <CAFaUHvKtAF3qqjQ2JRH==eFhy+AU8tztYpCJOGEOMDL4Kd2j9A@mail.gmail.com>

In my opinion, we should not allow empty META because it's not worth it.

For those who want to know about why CR LF is used in internet
protocol, here's a little bit of history:
https://www.rfc-editor.org/old/EOLstory.txt

~smlckz

From johann.galle at protonmail.com  Wed Nov 11 19:13:32 2020
From: johann.galle at protonmail.com (Johann150)
Date: Wed, 11 Nov 2020 19:13:32 +0000
Subject: Clarifications to the Spec
In-Reply-To: <briUs5E76gBds8SgbeQw44EO4rStvQDN09WrPjoe3GjfIxQl9tXTB89asXuA6lKSt6S5ugqIRuUM54GjxzzG2uSlOQX0Uc-a6LfQVXbFlmU=@protonmail.com>
References: <C70G46VKAIWA.2O918IYGKC9FI@nitro>
 <briUs5E76gBds8SgbeQw44EO4rStvQDN09WrPjoe3GjfIxQl9tXTB89asXuA6lKSt6S5ugqIRuUM54GjxzzG2uSlOQX0Uc-a6LfQVXbFlmU=@protonmail.com>
Message-ID: <GvtmEpHpM_K-jF6G-Ti7COZgs1Gng4TwdTod9Inrfif96HmkTdLEi_Aj0s_4lBfNU8hAEe9yAYv-LGQI6RD3wl1zsyJHU0ANd9M1d2WWy-A=@protonmail.com>

> Reasonable behaviour of a client for empty META would be IMHO:
> -SNIP-

I just wanted to add that there is a thread regarding this topic -
"0-length META" to be exact - in the mailing list archive and that thread might
be interesting to read too:
<https://lists.orbitalfox.eu/archives/gemini/2020/003009.html>

From ben at benaaron.dev  Thu Nov 12 06:26:30 2020
From: ben at benaaron.dev (Ben Goldberg)
Date: Thu, 12 Nov 2020 01:26:30 -0500
Subject: [ANN] stargazer - A new gemini server
Message-ID: <ae96aca6-b8be-6728-ba3b-422d84a33403@benaaron.dev>

Hello everyone,

I'd like to announce the initial release of the gemini server I've 
written which I have dubbed stargazer[1].  It's concurrent using 
asynchronous IO, auto generates certificates, and is configured through 
a single config file for ease of use.  It also has a *dev* mode to 
server files out of the current directory with no configuration.  It's 
design it largely inspired by gmnisrv[2].

It's written in Rust and uses rustls instead of openssl for TLS.  As a 
result, stargazer has no runtime dependencies (if compiled with musl libc).

[1] https://sr.ht/~zethra/stargazer/
[2] https://sr.ht/~sircmpwn/gmnisrv/

From benulo at systemli.org  Thu Nov 12 09:26:15 2020
From: benulo at systemli.org (Ben)
Date: Thu, 12 Nov 2020 12:56:15 +0330
Subject: [ANN] stargazer - A new gemini server
In-Reply-To: <ae96aca6-b8be-6728-ba3b-422d84a33403@benaaron.dev>
References: <ae96aca6-b8be-6728-ba3b-422d84a33403@benaaron.dev>
Message-ID: <b2065cb4-1fe2-1834-f6e3-71605805d30f@systemli.org>

Very nice!

-- 
gemini://kwiecien.us/

From jmcbray at carcosa.net  Thu Nov 12 14:18:15 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 12 Nov 2020 09:18:15 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201111154636.GA653@thrax.localdomain> (Ivy Foster's message of
 "Wed, 11 Nov 2020 09:46:36 -0600")
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <ta7tQ5wMtPgRih1lTplBs0BcEzgeRMRx2PlqGDer_lcAJO-muTqyQDs2I_Cl-X8uhEbI4NI6aeyhyY9tpG4ORPRfBiNLZ8uR-cPuMisfsg0=@protonmail.com>
 <20201110160437.GA1224@ub3rgeek.net>
 <20201110175929.b6316a87613ac3fdee09e883@gmail.com>
 <20201110204746.GB1224@ub3rgeek.net>
 <20201111154636.GA653@thrax.localdomain>
Message-ID: <877dqqirq0.fsf@cassilda.carcosa.net>

Ivy Foster <escondida at iff.ink> writes:

> Also, I do recognize that this idea is going to get shot down as
> paving the way for more extensibility, though we already have things
> like verbatim blocks and what have you (which are more esoteric than
> italic, so I don't buy the "we shouldn't support every use case"
> argument. It's far more common to emphasize words, to write titles of
> works, and so forth, than it is to do ASCII art (not that there's
> anything wrong with ASCII art; it's great) or present code blocks (the
> current demographics of the medium notwithstanding)).

Early on, before gemtext existed in its current form, I was pushing to
include inline emphasis (like Markdown; in fact, I was pushing to use a
strict subset of Markdown for Gemini documents). The reason I lost that
argument was because it substantially complicates the implementation of
clients, and if you use "*" both for inline emphasis and links, then you
run into a lot of ambiguities that various Markdown implementations
face. But it's not that it's not wanted, or out of scope (in the way
that, for example, color specification would be).

Thought experiment: we agree to implement inline emphasis, using some
set of markers on either side of a range of text. To simplify
implementation, the emphasis must be within a single line of text (not a
problem since we use long lines and let clients wrap them). Emphasis
markers are not allowed in any line types except plain and list. The
markers should be ones that are commonly/historically used in plain-text
emails. Which markers should we use?

We can't use '*', because it would be ambiguous at the beginning of
lines. We can't use '/', because it is ambiguous with Unix paths. We can
use '_', but it's less used (to imply underlines). I'm open to
suggestions. 

Clients would be free to represent this emphasis in any way suitable for
their display, including but not limited to italics. Not doing anything,
and leaving the emphasis markers in place, remains a valid
implementation. Implementations that _do_ use some kind of text
properties, like italics, are free to leave the emphasis markers in the
output, or remove them.

Any thoughts on this? It shouldn't be too much of a barrier to
implementation, because a) existing clients that do nothing are all
still in-spec, and b) the restriction on emphasis crossing lines means
that you can simply implement it with a regex, after you first determine
the line type.

A reminder: this is just a thought experiment, not yet an argument that
it should be implemented.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Thu Nov 12 14:26:42 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 12 Nov 2020 09:26:42 -0500
Subject: Adding close_notify to the spec ?
In-Reply-To: <CAFTy05YR99pc6Z=+EeOZhMqoGbC_KMOa8a6A8wt6PVH4oDuNLw@mail.gmail.com>
 (Michael Lazar's message of "Tue, 10 Nov 2020 21:39:58 -0500")
References: <51e34fb4-1718-046f-f172-295c8edd292d@scotdoyle.com>
 <CAFTy05YR99pc6Z=+EeOZhMqoGbC_KMOa8a6A8wt6PVH4oDuNLw@mail.gmail.com>
Message-ID: <87361eirbx.fsf@cassilda.carcosa.net>

Michael Lazar <lazar.michael22 at gmail.com> writes:

> I took your code snippet and added to my gemini portal at
> https://portal.mozz.us Now anyone can view their TLS connection
> details, including if the `send_alert` message was sent, by clicking
> on the [view cert] link at the top of the page.

Thanks, this is particularly useful to me. Now the question remains as
to whether I can actually get the TLS library I'm using to do this.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From cage-dev at twistfold.it  Thu Nov 12 14:59:01 2020
From: cage-dev at twistfold.it (cage)
Date: Thu, 12 Nov 2020 15:59:01 +0100
Subject: adding space after heading and more
Message-ID: <20201112145901.GA4535@kurosawa.casa.net>

Hi folks!

as there  has been a discussion  about freezing the specs  i wonder if
the gemini file  format could be changed as discussed  in this message
(in this thread actually):

https://lists.orbitalfox.eu/archives/gemini/2020/002312.html

I have read people  wondering if a space is needed  after "#" here and
there and  if there  is agreement  on the  conclusions in  the message
above now is, in my opinion, a good time to amend the specs.

Bye!
C.

From me at ecmelberk.com  Thu Nov 12 14:58:52 2020
From: me at ecmelberk.com (=?utf-8?q?Ecmel_Berk_Canl=C4=B1er?=)
Date: Thu, 12 Nov 2020 17:58:52 +0300
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <877dqqirq0.fsf@cassilda.carcosa.net>
Message-ID: <C71DH4WB9NRE.2D5RZOZ7467CN@fistik>

On Thu Nov 12, 2020 at 12:18 PM +03, Jason McBrayer wrote:
> Which markers should we use? [...] We can use '_', but it's less used
> (to imply underlines). I'm open to suggestions.

Using '_' would also conflict with snake_cased_variables in various
programming contexts, which would also require the addition of a "inline
preformatted" marker, which probably would complicate this even more.

--
Have a nice /(day|night|week(end)?)/
~ Ecmel B. Canl?er ~

From petite.abeille at gmail.com  Thu Nov 12 15:15:51 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 12 Nov 2020 16:15:51 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <C71DH4WB9NRE.2D5RZOZ7467CN@fistik>
References: <C71DH4WB9NRE.2D5RZOZ7467CN@fistik>
Message-ID: <6B41C9A8-5683-47DD-A2DA-AF7EB56E6B71@gmail.com>



> On Nov 12, 2020, at 15:58, Ecmel Berk Canl?er <me at ecmelberk.com> wrote:
> 
> On Thu Nov 12, 2020 at 12:18 PM +03, Jason McBrayer wrote:
>> Which markers should we use? [...] We can use '_', but it's less used
>> (to imply underlines). I'm open to suggestions.
> 
> Using '_' would also conflict with snake_cased_variables in various
> programming contexts, which would also require the addition of a "inline
> preformatted" marker, which probably would complicate this even more.

Considering we have the full power of Unicode at our disposal -Thomas mentioned italicized math symbols previously- perhaps one could use some fancy combining diacritic ala "combining low line" at U+0332 to achieve the same effect:

https://en.wikipedia.org/wiki/Underscore#Unicode

My 2?: enough fidgeting with text/gemini. Let us try to use what we have in creative, forward looking ways ??

From khuxkm at tilde.team  Thu Nov 12 18:19:56 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 12 Nov 2020 18:19:56 +0000
Subject: adding space after heading and more
In-Reply-To: <20201112145901.GA4535@kurosawa.casa.net>
References: <20201112145901.GA4535@kurosawa.casa.net>
Message-ID: <4ebf49c09a8a5165091adfab26a27aa8@tilde.team>

November 12, 2020 9:59 AM, "cage" <cage-dev at twistfold.it> wrote:

> Hi folks!
> 
> as there has been a discussion about freezing the specs i wonder if
> the gemini file format could be changed as discussed in this message
> (in this thread actually):
> 
> https://lists.orbitalfox.eu/archives/gemini/2020/002312.html
> 
> I have read people wondering if a space is needed after "#" here and
> there and if there is agreement on the conclusions in the message
> above now is, in my opinion, a good time to amend the specs.
> 
> Bye!
> C.

I'm not a big fan of *requiring* whitespace after the hash. Markdown, for instance, doesn't require whitespace. That being said, in lieu of an escape character, it would make more sense.

Regardless, I would throw the eternal refrain of the ML back at it on this one: "Work within the limitations of the spec, instead of trying to change the spec."

Just my two cents,
Robert "khuxkm" Miles

From cowan at ccil.org  Fri Nov 13 01:03:52 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 12 Nov 2020 20:03:52 -0500
Subject: Supporting optional underscores for italics
Message-ID: <CAD2gp_S=ZuYjNJuJL5L6Nx+7EJ=AnQ==24Gf13JejA+XEumbjQ@mail.gmail.com>

Given that we are *not* going to change the definition of text/gemini, but
that many people want italics (including me), I have prepared some
instructions aimed at programmers of client software who would like to
support the _underscore emphasis_ convention.

0.  Under no circumstances are underscores to be removed from the text.
That compensates for less-than-infallible algorithms.

1.  If an underscore appears outside an emphasized text section, and is at
the beginning of a text line or after the # characters in a header line, or
is preceded by a whitespace character, then it marks the beginning of an
emphasized-text section (rendered as italics or in some other way).

2.  If an underscore appears inside an emphasized text section, and is at
the end of a line, or is followed by whitespace, sentence-terminating
punctuation, or parenthesis- or quotation-terminating punctuation, then it
marks the end of the emphasized-text section.

These rules exclude underscores in things like snake_case_variables, while
supporting most actual uses.

3.  An emphasized-text section ends unconditionally at the end of a line.

The attached file specifies all the Unicode whitespace and terminating
punctuation, from the Unicode Character Database.  There are quite a few,
but you don't even need a regular expression, just a list of the characters.

I hope this is helpful and/or inspirational.




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
People go through the bother of Christmas because Christmas helps them
to understand why they go through the bother of living out their lives
the rest of the year. For one brief instant, we see human society as it
should and could be, a world in which business has become the exchanging
of presents and in which nothing is important except the happiness and
well-being of the ultimate consumer.  --Northrop Frye (1948)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201112/9d0022fa/attachment-0001.htm>
-------------- next part --------------
0009..000D    ; White_Space # Cc   [5] <control-0009>..<control-000D>
0020          ; White_Space # Zs       SPACE
0085          ; White_Space # Cc       <control-0085>
00A0          ; White_Space # Zs       NO-BREAK SPACE
1680          ; White_Space # Zs       OGHAM SPACE MARK
2000..200A    ; White_Space # Zs  [11] EN QUAD..HAIR SPACE
2028          ; White_Space # Zl       LINE SEPARATOR
2029          ; White_Space # Zp       PARAGRAPH SEPARATOR
202F          ; White_Space # Zs       NARROW NO-BREAK SPACE
205F          ; White_Space # Zs       MEDIUM MATHEMATICAL SPACE
3000          ; White_Space # Zs       IDEOGRAPHIC SPACE

# Total code points: 25

# ================================================

0021          ; STerm # Po       EXCLAMATION MARK
003F          ; STerm # Po       QUESTION MARK
0589          ; STerm # Po       ARMENIAN FULL STOP
061E..061F    ; STerm # Po   [2] ARABIC TRIPLE DOT PUNCTUATION MARK..ARABIC QUESTION MARK
06D4          ; STerm # Po       ARABIC FULL STOP
0700..0702    ; STerm # Po   [3] SYRIAC END OF PARAGRAPH..SYRIAC SUBLINEAR FULL STOP
07F9          ; STerm # Po       NKO EXCLAMATION MARK
0837          ; STerm # Po       SAMARITAN PUNCTUATION MELODIC QITSA
0839          ; STerm # Po       SAMARITAN PUNCTUATION QITSA
083D..083E    ; STerm # Po   [2] SAMARITAN PUNCTUATION SOF MASHFAAT..SAMARITAN PUNCTUATION ANNAAU
0964..0965    ; STerm # Po   [2] DEVANAGARI DANDA..DEVANAGARI DOUBLE DANDA
104A..104B    ; STerm # Po   [2] MYANMAR SIGN LITTLE SECTION..MYANMAR SIGN SECTION
1362          ; STerm # Po       ETHIOPIC FULL STOP
1367..1368    ; STerm # Po   [2] ETHIOPIC QUESTION MARK..ETHIOPIC PARAGRAPH SEPARATOR
166E          ; STerm # Po       CANADIAN SYLLABICS FULL STOP
1735..1736    ; STerm # Po   [2] PHILIPPINE SINGLE PUNCTUATION..PHILIPPINE DOUBLE PUNCTUATION
1803          ; STerm # Po       MONGOLIAN FULL STOP
1809          ; STerm # Po       MONGOLIAN MANCHU FULL STOP
1944..1945    ; STerm # Po   [2] LIMBU EXCLAMATION MARK..LIMBU QUESTION MARK
1AA8..1AAB    ; STerm # Po   [4] TAI THAM SIGN KAAN..TAI THAM SIGN SATKAANKUU
1B5A..1B5B    ; STerm # Po   [2] BALINESE PANTI..BALINESE PAMADA
1B5E..1B5F    ; STerm # Po   [2] BALINESE CARIK SIKI..BALINESE CARIK PAREREN
1C3B..1C3C    ; STerm # Po   [2] LEPCHA PUNCTUATION TA-ROL..LEPCHA PUNCTUATION NYET THYOOM TA-ROL
1C7E..1C7F    ; STerm # Po   [2] OL CHIKI PUNCTUATION MUCAAD..OL CHIKI PUNCTUATION DOUBLE MUCAAD
203C..203D    ; STerm # Po   [2] DOUBLE EXCLAMATION MARK..INTERROBANG
2047..2049    ; STerm # Po   [3] DOUBLE QUESTION MARK..EXCLAMATION QUESTION MARK
2E2E          ; STerm # Po       REVERSED QUESTION MARK
2E3C          ; STerm # Po       STENOGRAPHIC FULL STOP
3002          ; STerm # Po       IDEOGRAPHIC FULL STOP
A4FF          ; STerm # Po       LISU PUNCTUATION FULL STOP
A60E..A60F    ; STerm # Po   [2] VAI FULL STOP..VAI QUESTION MARK
A6F3          ; STerm # Po       BAMUM FULL STOP
A6F7          ; STerm # Po       BAMUM QUESTION MARK
A876..A877    ; STerm # Po   [2] PHAGS-PA MARK SHAD..PHAGS-PA MARK DOUBLE SHAD
A8CE..A8CF    ; STerm # Po   [2] SAURASHTRA DANDA..SAURASHTRA DOUBLE DANDA
A92F          ; STerm # Po       KAYAH LI SIGN SHYA
A9C8..A9C9    ; STerm # Po   [2] JAVANESE PADA LINGSA..JAVANESE PADA LUNGSI
AA5D..AA5F    ; STerm # Po   [3] CHAM PUNCTUATION DANDA..CHAM PUNCTUATION TRIPLE DANDA
AAF0..AAF1    ; STerm # Po   [2] MEETEI MAYEK CHEIKHAN..MEETEI MAYEK AHANG KHUDAM
ABEB          ; STerm # Po       MEETEI MAYEK CHEIKHEI
FE56..FE57    ; STerm # Po   [2] SMALL QUESTION MARK..SMALL EXCLAMATION MARK
FF01          ; STerm # Po       FULLWIDTH EXCLAMATION MARK
FF1F          ; STerm # Po       FULLWIDTH QUESTION MARK
FF61          ; STerm # Po       HALFWIDTH IDEOGRAPHIC FULL STOP
10A56..10A57  ; STerm # Po   [2] KHAROSHTHI PUNCTUATION DANDA..KHAROSHTHI PUNCTUATION DOUBLE DANDA
10F55..10F59  ; STerm # Po   [5] SOGDIAN PUNCTUATION TWO VERTICAL BARS..SOGDIAN PUNCTUATION HALF CIRCLE WITH DOT
11047..11048  ; STerm # Po   [2] BRAHMI DANDA..BRAHMI DOUBLE DANDA
110BE..110C1  ; STerm # Po   [4] KAITHI SECTION MARK..KAITHI DOUBLE DANDA
11141..11143  ; STerm # Po   [3] CHAKMA DANDA..CHAKMA QUESTION MARK
111C5..111C6  ; STerm # Po   [2] SHARADA DANDA..SHARADA DOUBLE DANDA
111CD         ; STerm # Po       SHARADA SUTRA MARK
111DE..111DF  ; STerm # Po   [2] SHARADA SECTION MARK-1..SHARADA SECTION MARK-2
11238..11239  ; STerm # Po   [2] KHOJKI DANDA..KHOJKI DOUBLE DANDA
1123B..1123C  ; STerm # Po   [2] KHOJKI SECTION MARK..KHOJKI DOUBLE SECTION MARK
112A9         ; STerm # Po       MULTANI SECTION MARK
1144B..1144C  ; STerm # Po   [2] NEWA DANDA..NEWA DOUBLE DANDA
115C2..115C3  ; STerm # Po   [2] SIDDHAM DANDA..SIDDHAM DOUBLE DANDA
115C9..115D7  ; STerm # Po  [15] SIDDHAM END OF TEXT MARK..SIDDHAM SECTION MARK WITH CIRCLES AND FOUR ENCLOSURES
11641..11642  ; STerm # Po   [2] MODI DANDA..MODI DOUBLE DANDA
1173C..1173E  ; STerm # Po   [3] AHOM SIGN SMALL SECTION..AHOM SIGN RULAI
11944         ; STerm # Po       DIVES AKURU DOUBLE DANDA
11946         ; STerm # Po       DIVES AKURU END OF TEXT MARK
11A42..11A43  ; STerm # Po   [2] ZANABAZAR SQUARE MARK SHAD..ZANABAZAR SQUARE MARK DOUBLE SHAD
11A9B..11A9C  ; STerm # Po   [2] SOYOMBO MARK SHAD..SOYOMBO MARK DOUBLE SHAD
11C41..11C42  ; STerm # Po   [2] BHAIKSUKI DANDA..BHAIKSUKI DOUBLE DANDA
11EF7..11EF8  ; STerm # Po   [2] MAKASAR PASSIMBANG..MAKASAR END OF SECTION
16A6E..16A6F  ; STerm # Po   [2] MRO DANDA..MRO DOUBLE DANDA
16AF5         ; STerm # Po       BASSA VAH FULL STOP
16B37..16B38  ; STerm # Po   [2] PAHAWH HMONG SIGN VOS THOM..PAHAWH HMONG SIGN VOS TSHAB CEEB
16B44         ; STerm # Po       PAHAWH HMONG SIGN XAUS
16E98         ; STerm # Po       MEDEFAIDRIN FULL STOP
1BC9F         ; STerm # Po       DUPLOYAN PUNCTUATION CHINOOK FULL STOP
1DA88         ; STerm # Po       SIGNWRITING FULL STOP

# Total code points: 140

# ================================================

0022          ; Close # Po       QUOTATION MARK
0027          ; Close # Po       APOSTROPHE
0028          ; Close # Ps       LEFT PARENTHESIS
0029          ; Close # Pe       RIGHT PARENTHESIS
005B          ; Close # Ps       LEFT SQUARE BRACKET
005D          ; Close # Pe       RIGHT SQUARE BRACKET
007B          ; Close # Ps       LEFT CURLY BRACKET
007D          ; Close # Pe       RIGHT CURLY BRACKET
00AB          ; Close # Pi       LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
00BB          ; Close # Pf       RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
0F3A          ; Close # Ps       TIBETAN MARK GUG RTAGS GYON
0F3B          ; Close # Pe       TIBETAN MARK GUG RTAGS GYAS
0F3C          ; Close # Ps       TIBETAN MARK ANG KHANG GYON
0F3D          ; Close # Pe       TIBETAN MARK ANG KHANG GYAS
169B          ; Close # Ps       OGHAM FEATHER MARK
169C          ; Close # Pe       OGHAM REVERSED FEATHER MARK
2018          ; Close # Pi       LEFT SINGLE QUOTATION MARK
2019          ; Close # Pf       RIGHT SINGLE QUOTATION MARK
201A          ; Close # Ps       SINGLE LOW-9 QUOTATION MARK
201B..201C    ; Close # Pi   [2] SINGLE HIGH-REVERSED-9 QUOTATION MARK..LEFT DOUBLE QUOTATION MARK
201D          ; Close # Pf       RIGHT DOUBLE QUOTATION MARK
201E          ; Close # Ps       DOUBLE LOW-9 QUOTATION MARK
201F          ; Close # Pi       DOUBLE HIGH-REVERSED-9 QUOTATION MARK
2039          ; Close # Pi       SINGLE LEFT-POINTING ANGLE QUOTATION MARK
203A          ; Close # Pf       SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
2045          ; Close # Ps       LEFT SQUARE BRACKET WITH QUILL
2046          ; Close # Pe       RIGHT SQUARE BRACKET WITH QUILL
207D          ; Close # Ps       SUPERSCRIPT LEFT PARENTHESIS
207E          ; Close # Pe       SUPERSCRIPT RIGHT PARENTHESIS
208D          ; Close # Ps       SUBSCRIPT LEFT PARENTHESIS
208E          ; Close # Pe       SUBSCRIPT RIGHT PARENTHESIS
2308          ; Close # Ps       LEFT CEILING
2309          ; Close # Pe       RIGHT CEILING
230A          ; Close # Ps       LEFT FLOOR
230B          ; Close # Pe       RIGHT FLOOR
2329          ; Close # Ps       LEFT-POINTING ANGLE BRACKET
232A          ; Close # Pe       RIGHT-POINTING ANGLE BRACKET
275B..2760    ; Close # So   [6] HEAVY SINGLE TURNED COMMA QUOTATION MARK ORNAMENT..HEAVY LOW DOUBLE COMMA QUOTATION MARK ORNAMENT
2768          ; Close # Ps       MEDIUM LEFT PARENTHESIS ORNAMENT
2769          ; Close # Pe       MEDIUM RIGHT PARENTHESIS ORNAMENT
276A          ; Close # Ps       MEDIUM FLATTENED LEFT PARENTHESIS ORNAMENT
276B          ; Close # Pe       MEDIUM FLATTENED RIGHT PARENTHESIS ORNAMENT
276C          ; Close # Ps       MEDIUM LEFT-POINTING ANGLE BRACKET ORNAMENT
276D          ; Close # Pe       MEDIUM RIGHT-POINTING ANGLE BRACKET ORNAMENT
276E          ; Close # Ps       HEAVY LEFT-POINTING ANGLE QUOTATION MARK ORNAMENT
276F          ; Close # Pe       HEAVY RIGHT-POINTING ANGLE QUOTATION MARK ORNAMENT
2770          ; Close # Ps       HEAVY LEFT-POINTING ANGLE BRACKET ORNAMENT
2771          ; Close # Pe       HEAVY RIGHT-POINTING ANGLE BRACKET ORNAMENT
2772          ; Close # Ps       LIGHT LEFT TORTOISE SHELL BRACKET ORNAMENT
2773          ; Close # Pe       LIGHT RIGHT TORTOISE SHELL BRACKET ORNAMENT
2774          ; Close # Ps       MEDIUM LEFT CURLY BRACKET ORNAMENT
2775          ; Close # Pe       MEDIUM RIGHT CURLY BRACKET ORNAMENT
27C5          ; Close # Ps       LEFT S-SHAPED BAG DELIMITER
27C6          ; Close # Pe       RIGHT S-SHAPED BAG DELIMITER
27E6          ; Close # Ps       MATHEMATICAL LEFT WHITE SQUARE BRACKET
27E7          ; Close # Pe       MATHEMATICAL RIGHT WHITE SQUARE BRACKET
27E8          ; Close # Ps       MATHEMATICAL LEFT ANGLE BRACKET
27E9          ; Close # Pe       MATHEMATICAL RIGHT ANGLE BRACKET
27EA          ; Close # Ps       MATHEMATICAL LEFT DOUBLE ANGLE BRACKET
27EB          ; Close # Pe       MATHEMATICAL RIGHT DOUBLE ANGLE BRACKET
27EC          ; Close # Ps       MATHEMATICAL LEFT WHITE TORTOISE SHELL BRACKET
27ED          ; Close # Pe       MATHEMATICAL RIGHT WHITE TORTOISE SHELL BRACKET
27EE          ; Close # Ps       MATHEMATICAL LEFT FLATTENED PARENTHESIS
27EF          ; Close # Pe       MATHEMATICAL RIGHT FLATTENED PARENTHESIS
2983          ; Close # Ps       LEFT WHITE CURLY BRACKET
2984          ; Close # Pe       RIGHT WHITE CURLY BRACKET
2985          ; Close # Ps       LEFT WHITE PARENTHESIS
2986          ; Close # Pe       RIGHT WHITE PARENTHESIS
2987          ; Close # Ps       Z NOTATION LEFT IMAGE BRACKET
2988          ; Close # Pe       Z NOTATION RIGHT IMAGE BRACKET
2989          ; Close # Ps       Z NOTATION LEFT BINDING BRACKET
298A          ; Close # Pe       Z NOTATION RIGHT BINDING BRACKET
298B          ; Close # Ps       LEFT SQUARE BRACKET WITH UNDERBAR
298C          ; Close # Pe       RIGHT SQUARE BRACKET WITH UNDERBAR
298D          ; Close # Ps       LEFT SQUARE BRACKET WITH TICK IN TOP CORNER
298E          ; Close # Pe       RIGHT SQUARE BRACKET WITH TICK IN BOTTOM CORNER
298F          ; Close # Ps       LEFT SQUARE BRACKET WITH TICK IN BOTTOM CORNER
2990          ; Close # Pe       RIGHT SQUARE BRACKET WITH TICK IN TOP CORNER
2991          ; Close # Ps       LEFT ANGLE BRACKET WITH DOT
2992          ; Close # Pe       RIGHT ANGLE BRACKET WITH DOT
2993          ; Close # Ps       LEFT ARC LESS-THAN BRACKET
2994          ; Close # Pe       RIGHT ARC GREATER-THAN BRACKET
2995          ; Close # Ps       DOUBLE LEFT ARC GREATER-THAN BRACKET
2996          ; Close # Pe       DOUBLE RIGHT ARC LESS-THAN BRACKET
2997          ; Close # Ps       LEFT BLACK TORTOISE SHELL BRACKET
2998          ; Close # Pe       RIGHT BLACK TORTOISE SHELL BRACKET
29D8          ; Close # Ps       LEFT WIGGLY FENCE
29D9          ; Close # Pe       RIGHT WIGGLY FENCE
29DA          ; Close # Ps       LEFT DOUBLE WIGGLY FENCE
29DB          ; Close # Pe       RIGHT DOUBLE WIGGLY FENCE
29FC          ; Close # Ps       LEFT-POINTING CURVED ANGLE BRACKET
29FD          ; Close # Pe       RIGHT-POINTING CURVED ANGLE BRACKET
2E00..2E01    ; Close # Po   [2] RIGHT ANGLE SUBSTITUTION MARKER..RIGHT ANGLE DOTTED SUBSTITUTION MARKER
2E02          ; Close # Pi       LEFT SUBSTITUTION BRACKET
2E03          ; Close # Pf       RIGHT SUBSTITUTION BRACKET
2E04          ; Close # Pi       LEFT DOTTED SUBSTITUTION BRACKET
2E05          ; Close # Pf       RIGHT DOTTED SUBSTITUTION BRACKET
2E06..2E08    ; Close # Po   [3] RAISED INTERPOLATION MARKER..DOTTED TRANSPOSITION MARKER
2E09          ; Close # Pi       LEFT TRANSPOSITION BRACKET
2E0A          ; Close # Pf       RIGHT TRANSPOSITION BRACKET
2E0B          ; Close # Po       RAISED SQUARE
2E0C          ; Close # Pi       LEFT RAISED OMISSION BRACKET
2E0D          ; Close # Pf       RIGHT RAISED OMISSION BRACKET
2E1C          ; Close # Pi       LEFT LOW PARAPHRASE BRACKET
2E1D          ; Close # Pf       RIGHT LOW PARAPHRASE BRACKET
2E20          ; Close # Pi       LEFT VERTICAL BAR WITH QUILL
2E21          ; Close # Pf       RIGHT VERTICAL BAR WITH QUILL
2E22          ; Close # Ps       TOP LEFT HALF BRACKET
2E23          ; Close # Pe       TOP RIGHT HALF BRACKET
2E24          ; Close # Ps       BOTTOM LEFT HALF BRACKET
2E25          ; Close # Pe       BOTTOM RIGHT HALF BRACKET
2E26          ; Close # Ps       LEFT SIDEWAYS U BRACKET
2E27          ; Close # Pe       RIGHT SIDEWAYS U BRACKET
2E28          ; Close # Ps       LEFT DOUBLE PARENTHESIS
2E29          ; Close # Pe       RIGHT DOUBLE PARENTHESIS
2E42          ; Close # Ps       DOUBLE LOW-REVERSED-9 QUOTATION MARK
3008          ; Close # Ps       LEFT ANGLE BRACKET
3009          ; Close # Pe       RIGHT ANGLE BRACKET
300A          ; Close # Ps       LEFT DOUBLE ANGLE BRACKET
300B          ; Close # Pe       RIGHT DOUBLE ANGLE BRACKET
300C          ; Close # Ps       LEFT CORNER BRACKET
300D          ; Close # Pe       RIGHT CORNER BRACKET
300E          ; Close # Ps       LEFT WHITE CORNER BRACKET
300F          ; Close # Pe       RIGHT WHITE CORNER BRACKET
3010          ; Close # Ps       LEFT BLACK LENTICULAR BRACKET
3011          ; Close # Pe       RIGHT BLACK LENTICULAR BRACKET
3014          ; Close # Ps       LEFT TORTOISE SHELL BRACKET
3015          ; Close # Pe       RIGHT TORTOISE SHELL BRACKET
3016          ; Close # Ps       LEFT WHITE LENTICULAR BRACKET
3017          ; Close # Pe       RIGHT WHITE LENTICULAR BRACKET
3018          ; Close # Ps       LEFT WHITE TORTOISE SHELL BRACKET
3019          ; Close # Pe       RIGHT WHITE TORTOISE SHELL BRACKET
301A          ; Close # Ps       LEFT WHITE SQUARE BRACKET
301B          ; Close # Pe       RIGHT WHITE SQUARE BRACKET
301D          ; Close # Ps       REVERSED DOUBLE PRIME QUOTATION MARK
301E..301F    ; Close # Pe   [2] DOUBLE PRIME QUOTATION MARK..LOW DOUBLE PRIME QUOTATION MARK
FD3E          ; Close # Pe       ORNATE LEFT PARENTHESIS
FD3F          ; Close # Ps       ORNATE RIGHT PARENTHESIS
FE17          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT WHITE LENTICULAR BRACKET
FE18          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET
FE35          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT PARENTHESIS
FE36          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT PARENTHESIS
FE37          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT CURLY BRACKET
FE38          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT CURLY BRACKET
FE39          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT TORTOISE SHELL BRACKET
FE3A          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT TORTOISE SHELL BRACKET
FE3B          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT BLACK LENTICULAR BRACKET
FE3C          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT BLACK LENTICULAR BRACKET
FE3D          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT DOUBLE ANGLE BRACKET
FE3E          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT DOUBLE ANGLE BRACKET
FE3F          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT ANGLE BRACKET
FE40          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT ANGLE BRACKET
FE41          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT CORNER BRACKET
FE42          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT CORNER BRACKET
FE43          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT WHITE CORNER BRACKET
FE44          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT WHITE CORNER BRACKET
FE47          ; Close # Ps       PRESENTATION FORM FOR VERTICAL LEFT SQUARE BRACKET
FE48          ; Close # Pe       PRESENTATION FORM FOR VERTICAL RIGHT SQUARE BRACKET
FE59          ; Close # Ps       SMALL LEFT PARENTHESIS
FE5A          ; Close # Pe       SMALL RIGHT PARENTHESIS
FE5B          ; Close # Ps       SMALL LEFT CURLY BRACKET
FE5C          ; Close # Pe       SMALL RIGHT CURLY BRACKET
FE5D          ; Close # Ps       SMALL LEFT TORTOISE SHELL BRACKET
FE5E          ; Close # Pe       SMALL RIGHT TORTOISE SHELL BRACKET
FF08          ; Close # Ps       FULLWIDTH LEFT PARENTHESIS
FF09          ; Close # Pe       FULLWIDTH RIGHT PARENTHESIS
FF3B          ; Close # Ps       FULLWIDTH LEFT SQUARE BRACKET
FF3D          ; Close # Pe       FULLWIDTH RIGHT SQUARE BRACKET
FF5B          ; Close # Ps       FULLWIDTH LEFT CURLY BRACKET
FF5D          ; Close # Pe       FULLWIDTH RIGHT CURLY BRACKET
FF5F          ; Close # Ps       FULLWIDTH LEFT WHITE PARENTHESIS
FF60          ; Close # Pe       FULLWIDTH RIGHT WHITE PARENTHESIS
FF62          ; Close # Ps       HALFWIDTH LEFT CORNER BRACKET
FF63          ; Close # Pe       HALFWIDTH RIGHT CORNER BRACKET
1F676..1F678  ; Close # So   [3] SANS-SERIF HEAVY DOUBLE TURNED COMMA QUOTATION MARK ORNAMENT..SANS-SERIF HEAVY LOW DOUBLE COMMA QUOTATION MARK ORNAMENT

# Total code points: 187

From sir at cmpwn.com  Fri Nov 13 01:05:47 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 12 Nov 2020 21:05:47 -0400
Subject: Supporting optional underscores for italics
In-Reply-To: <CAD2gp_S=ZuYjNJuJL5L6Nx+7EJ=AnQ==24Gf13JejA+XEumbjQ@mail.gmail.com>
Message-ID: <C71QDTQH88UQ.1DK381ZAX9EQS@taiga>

Can you guys give it a rest already? NACK on behalf of my client. Gemini
is good because it's not going to change. We don't need italics for
"serious writing". Everyone has something different that they NEED very
BADLY or else they can't SERIOUSLY use gemini, yak, yak, yak.

Stop it.

Gemini is good because it's simple.

From cowan at ccil.org  Fri Nov 13 01:12:12 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 12 Nov 2020 20:12:12 -0500
Subject: Supporting optional underscores for italics
In-Reply-To: <C71QDTQH88UQ.1DK381ZAX9EQS@taiga>
References: <CAD2gp_S=ZuYjNJuJL5L6Nx+7EJ=AnQ==24Gf13JejA+XEumbjQ@mail.gmail.com>
 <C71QDTQH88UQ.1DK381ZAX9EQS@taiga>
Message-ID: <CAD2gp_Q9mO4rqRn05jEufQct3raxyU0MMg8XUbXw2ObyAaQFfw@mail.gmail.com>

On Thu, Nov 12, 2020 at 8:07 PM Drew DeVault <sir at cmpwn.com> wrote:

Stop it.
>

Y'know, if you hadn't written your message, I wouldn't have written this
reply and that would be two less messages on the list.  But knock yourself
out.

Gemini is good because it's simple.
>

I agree.  Some clients are bare-bones, others add all sorts of bells and
whistles.  That doesn't affect the simplicity of the protocol *or* the
format.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
The penguin geeks is happy / As under the waves they lark
The closed-source geeks ain't happy / They sad cause they in the dark
But geeks in the dark is lucky / They in for a worser treat
One day when the Borg go belly-up / Guess who wind up on the street.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201112/49cddd73/attachment.htm>

From sean at conman.org  Fri Nov 13 02:02:30 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 12 Nov 2020 21:02:30 -0500
Subject: Supporting optional underscores for italics
In-Reply-To: <CAD2gp_S=ZuYjNJuJL5L6Nx+7EJ=AnQ==24Gf13JejA+XEumbjQ@mail.gmail.com>
References: <CAD2gp_S=ZuYjNJuJL5L6Nx+7EJ=AnQ==24Gf13JejA+XEumbjQ@mail.gmail.com>
Message-ID: <20201113020229.GV30302@brevard.conman.org>


  Oooh!  A bike sheeding thread!  I know Drew DeVault might complain, but
hey, this list wouldn't be this list unless the majority of messages were
about text formatting (seriously---over half the messages are not about the
protocol at all, but about text formatting).

  So with my introduction out of the way, let me nitpick [1] this proposal
with a bunch of corner cases I can already see ...

It was thus said that the Great John Cowan once stated:
> Given that we are *not* going to change the definition of text/gemini, but
                    ^^^^^ shouldn't that be _not_?  Or are you going for
strong emphasis here?  

> 1.  If an underscore appears outside an emphasized text section, and is at
> the beginning of a text line or after the # characters in a header line, or
> is preceded by a whitespace character, then it marks the beginning of an
> emphasized-text section

  Pattern wise, it's like:

	(start_of_line ?('#'*) | whitespace) '_'

> (rendered as italics or in some other way).

  Such as bold, a larger font, a smaller font, or some other way other than
using italics.  Okay, got it.  

> 2.  If an underscore appears inside an emphasized text section, and is at
> the end of a line, or is followed by whitespace, sentence-terminating
> punctuation, or parenthesis- or quotation-terminating punctuation, then it
> marks the end of the emphasized-text section.

  I've found that terminating italic sections before sentence-terminating
punctuation can lead to very ugly output.  For example:

	He asked about _blandit_?

  Here, the italic t will run into the trailing question mark, which I feel
looks terrible.  That's why I tend to include sentence terminating marks
within the italic section:

	He asked about _blandit?_

This is of less concern with periods and commas, since there isn't much of a
difference, stylistic wise, between a normal period and italic period.

  It also sounds like you are expecting users to write stuff like

	_lorem ipsum dolor sit amet_

or

	_lorem_ipsum_dolor_sit_amet_

else, why not just say that once in an emphasized text section, the next
underscore ends it.  Much easier to deal with, and a bit easier to deal with
when wrapping text (although I suppose one can add '_' to the list, along
with whitespace and hypens).

> These rules exclude underscores in things like snake_case_variables, while
> supporting most actual uses.
> 
> 3.  An emphasized-text section ends unconditionally at the end of a line.

  Odd, but I can see why you say so, given the nature of parsing gemtext. 
But one unaware of that might end up writing:

	blah blabh _lorem ipsum dolor
	sit amet_ blah blah blah

  and wonder why the italicised text is all wrong.

> The attached file specifies all the Unicode whitespace and terminating
> punctuation, from the Unicode Character Database.  There are quite a few,
> but you don't even need a regular expression, just a list of the characters.

  All 352 of the characters.  

  For now.

  That might be updated at the next Unicode revision.

  Got it.

> I hope this is helpful and/or inspirational.

  -spc (Unicode is hard!  Let's do rocketry!)

[1]	Can we still say that term?

From cowan at ccil.org  Fri Nov 13 02:38:52 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 12 Nov 2020 21:38:52 -0500
Subject: Supporting optional underscores for italics
In-Reply-To: <20201113020229.GV30302@brevard.conman.org>
References: <CAD2gp_S=ZuYjNJuJL5L6Nx+7EJ=AnQ==24Gf13JejA+XEumbjQ@mail.gmail.com>
 <20201113020229.GV30302@brevard.conman.org>
Message-ID: <CAD2gp_Sxb7FiLAaLLWW-CYQkHBgJaYmSheN8r=a9m=v5iGddAQ@mail.gmail.com>

On Thu, Nov 12, 2020 at 9:02 PM Sean Conner <sean at conman.org> wrote:

  Oooh!  A bike sheeding thread!


Yup.  Let's sheed some bikes together!

> So with my introduction out of the way, let me nitpick [1]


Yes, you can say that.  Head lice do not yet have a pressure group
insisting that you call their eggs something more polite.

> t> Given that we are *not* going to change the definition of text/gemini,
> but
>                     ^^^^^ shouldn't that be _not_?  Or are you going for
> strong emphasis here?
>

No, just habit.  I write a *lot* of git-flavored Markdown.

>   I've found that terminating italic sections before sentence-terminating
> punctuation can lead to very ugly output.


Yes, though that's up to the content author.  But this isn't about
terminating the italic section; it's about deciding whether an underscore
actually does terminate it.  See below.

> why not just say that once in an emphasized text section, the next
> underscore ends it.


So that lines like "It is important to understand that _although the
standard in C is to use snake_case for variables, C compilers do not
support numbers like 123_456_789_." are interpreted correctly.  To put it
in HTML terms, the first underscore is preceded by whitespace, so it is an
<i>, and the last one is followed by terminating punctuation, so it is an
</i>.  The others, however, don't satisfy either rule 1 or rule 2, so the
emphatic text just goes on right through them.

>         blah blabh _lorem ipsum dolor
>         sit amet_ blah blah blah
>

They will quickly find out that that doesn't work.  Text/gemini lines are
typically used in prose for paragraphs, and italic text doesn't normally
cross paragraph boundaries.

>   That might be updated at the next Unicode revision.
>

That's true.  But as time goes by, the new scripts with script-specific
punctuation become fewer and harder to find.  Until we join the Galactic
Federation, there just aren't many more scripts out there.  Newly invented
ones tend to use Latin/Greek/Cyrillic/etc. punctuation.


>   -spc (Unicode is hard!  Let's do rocketry!)
>

You kidding?  This is one of the easy bits!  All the work has been done for
us.  We don't even need regular expressions to figure it out, just keep the
352 characters in two arrays.  Unless your browser runs on an Arduino, that
is practically free.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
I amar prestar aen, han mathon ne nen,    http://vrici.lojban.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, LOTR:FOTR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201112/41d67d1f/attachment.htm>

From lazar.michael22 at gmail.com  Fri Nov 13 03:23:09 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 12 Nov 2020 22:23:09 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <6B41C9A8-5683-47DD-A2DA-AF7EB56E6B71@gmail.com>
References: <C71DH4WB9NRE.2D5RZOZ7467CN@fistik>
 <6B41C9A8-5683-47DD-A2DA-AF7EB56E6B71@gmail.com>
Message-ID: <CAFTy05YdbDd=aTb2jCm7iy5eScd9rAnDtjNRDGExvD8ekRmoRg@mail.gmail.com>

On Thu, Nov 12, 2020 at 10:16 AM Petite Abeille
<petite.abeille at gmail.com> wrote:
>
> > On Nov 12, 2020, at 15:58, Ecmel Berk Canl?er <me at ecmelberk.com> wrote:
> >
> > On Thu Nov 12, 2020 at 12:18 PM +03, Jason McBrayer wrote:
> >> Which markers should we use? [...] We can use '_', but it's less used
> >> (to imply underlines). I'm open to suggestions.
> >
> > Using '_' would also conflict with snake_cased_variables in various
> > programming contexts, which would also require the addition of a "inline
> > preformatted" marker, which probably would complicate this even more.
>
> Considering we have the full power of Unicode at our disposal -Thomas mentioned italicized math symbols previously- perhaps one could use some fancy combining diacritic ala "combining low line" at U+0332 to achieve the same effect:
>
> https://en.wikipedia.org/wiki/Underscore#Unicode
>
> My 2?: enough fidgeting with text/gemini. Let us try to use what we have in creative, forward looking ways ?

It's ? 2020 ? we ? don't ? need ? italics ? to ? show ? emphasis.

From cowan at ccil.org  Fri Nov 13 04:49:08 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 12 Nov 2020 23:49:08 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <CAFTy05YdbDd=aTb2jCm7iy5eScd9rAnDtjNRDGExvD8ekRmoRg@mail.gmail.com>
References: <C71DH4WB9NRE.2D5RZOZ7467CN@fistik>
 <6B41C9A8-5683-47DD-A2DA-AF7EB56E6B71@gmail.com>
 <CAFTy05YdbDd=aTb2jCm7iy5eScd9rAnDtjNRDGExvD8ekRmoRg@mail.gmail.com>
Message-ID: <CAD2gp_S6Yu3uT4MfPFspV-dWiufDoBG_kdnV37u_1=zSVK1qHg@mail.gmail.com>

On Thu, Nov 12, 2020 at 10:23 PM Michael Lazar <lazar.michael22 at gmail.com>
wrote:

It's ? 2020 ? we ? don't ? need ? italics ? to ? show ? emphasis.
>

?.

It'll be quite a bit later than 2020 before you see that kind of emphasis
in textbooks or novels.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201112/c1b6495d/attachment.htm>

From sean at conman.org  Fri Nov 13 07:45:20 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 13 Nov 2020 02:45:20 -0500
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <CAFTy05YdbDd=aTb2jCm7iy5eScd9rAnDtjNRDGExvD8ekRmoRg@mail.gmail.com>
References: <C71DH4WB9NRE.2D5RZOZ7467CN@fistik>
 <6B41C9A8-5683-47DD-A2DA-AF7EB56E6B71@gmail.com>
 <CAFTy05YdbDd=aTb2jCm7iy5eScd9rAnDtjNRDGExvD8ekRmoRg@mail.gmail.com>
Message-ID: <20201113074520.GA18016@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> 
> It's ? 2020 ? we ? don't ? need ? italics ? to ? show ? emphasis.

  It took me two operating systems and three programs to see what unoly
Unicode you were trying to unleash here.  If you want styled text, you have
options, but they are *NOT* text/gemini.  Oh, sorry, ? NOT ? text/gemini.

  -spc (God, there are times when I absolutely hate Unicode, and this is one
	of them ... )


From petite.abeille at gmail.com  Fri Nov 13 12:06:41 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 13 Nov 2020 13:06:41 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <20201113074520.GA18016@brevard.conman.org>
References: <C71DH4WB9NRE.2D5RZOZ7467CN@fistik>
 <6B41C9A8-5683-47DD-A2DA-AF7EB56E6B71@gmail.com>
 <CAFTy05YdbDd=aTb2jCm7iy5eScd9rAnDtjNRDGExvD8ekRmoRg@mail.gmail.com>
 <20201113074520.GA18016@brevard.conman.org>
Message-ID: <51687477-6B19-4485-BCD9-27CA012EF6A1@gmail.com>



> On Nov 13, 2020, at 08:45, Sean Conner <sean at conman.org> wrote:
> 
>  -spc (God, there are times when I absolutely hate Unicode, and this is one
> 	of them ... )

And yet... perhaps this is one area where gemini could make a difference... sane unicode support for the people! THE PEOPLE!

Thanks for playing.

From text at sdfeu.org  Fri Nov 13 13:41:27 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Fri, 13 Nov 2020 14:41:27 +0100
Subject: Geminisphere
Message-ID: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>

If clients would send referers, servers could collect (cache) and 
present those to clients asking for links _to_ the current page 
("backlinks" in wiki parlance), thus creating an interconnected gemini 
sphere.

Although not simple, I would enjoy bi-directional linking in Gemini.

From sir at cmpwn.com  Fri Nov 13 13:42:03 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Fri, 13 Nov 2020 08:42:03 -0500
Subject: Geminisphere
In-Reply-To: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
Message-ID: <C726GV0HEFR4.2XG45PIPOXLVM@taiga>

Webrings would be better.

From luke.emmet at gmail.com  Fri Nov 13 14:04:34 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Fri, 13 Nov 2020 14:04:34 +0000
Subject: Geminisphere
In-Reply-To: <C726GV0HEFR4.2XG45PIPOXLVM@taiga>
References: <C726GV0HEFR4.2XG45PIPOXLVM@taiga>
Message-ID: <BCF17048-CF23-42B5-93B7-74FDB423E0FC@gmail.com>

GUS already holds the back link graph and you can query it.

Luke

> On 13 Nov 2020, at 13:42, Drew DeVault <sir at cmpwn.com> wrote:
> 
> Webrings would be better.

From text at sdfeu.org  Fri Nov 13 14:36:48 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Fri, 13 Nov 2020 15:36:48 +0100
Subject: Geminisphere
In-Reply-To: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
References: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
Message-ID: <3254d27184afafc56cb53d691f916185@sdfeu.org>

Webrings form a nice gemini sphere, too. True.

As I understand backlinks, they are more fine-grained, operating on page 
level.

Gemini Universal Search (GUS) seems like a great central index, thanks!

Clients be like: list the 3 pages known to link here ;)

From unicorn at disroot.org  Fri Nov 13 14:47:55 2020
From: unicorn at disroot.org (Unicorn)
Date: Fri, 13 Nov 2020 15:47:55 +0100
Subject: Geminisphere
In-Reply-To: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
References: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
Message-ID: <7827fe630974221c0cc04fa5a7a0ae4217ce6c03.camel@disroot.org>

> If clients would send referers, servers could collect [...]

If a client sends a referer, it is sharing information about the
user's browsing behaviour with a party that does not technically need
to know this information. I personally always felt like this is one of
the web's aspects that have more privacy downsides than uses, and as a
consequence, probably shouldn't be part of a protocol that "takes
privacy seriously".

In practice it's more of a "nice to have" feature for analytics, which
I think goes against the goal of Gemini of keeping things limited to
what's necessary to achieve its purpose, both for complexity's and
privacy's sake. :)


From lambdatronic at disroot.org  Fri Nov 13 17:34:49 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 13 Nov 2020 12:34:49 -0500
Subject: adding space after heading and more
In-Reply-To: <4ebf49c09a8a5165091adfab26a27aa8@tilde.team>
References: <20201112145901.GA4535@kurosawa.casa.net>
 <4ebf49c09a8a5165091adfab26a27aa8@tilde.team>
Message-ID: <87y2j5duti.fsf@disroot.org>

November 12, 2020 9:59 AM, "cage" <cage-dev at twistfold.it> wrote:

> Hi folks!
> 
> as there has been a discussion about freezing the specs i wonder if
> the gemini file format could be changed as discussed in this message
> (in this thread actually):
> 
> https://lists.orbitalfox.eu/archives/gemini/2020/002312.html
> 
> I have read people wondering if a space is needed after "#" here and
> there and if there is agreement on the conclusions in the message
> above now is, in my opinion, a good time to amend the specs.
> 
> Bye!
> C.

I support the required space after each of the line types, which it
appears that Solderpunk agrees with according to the archive message
linked in this thread. Having watched that conversation play out some
time back, I think I remember someone pointing out that requiring the
space for headers would make it possible to include #hashtags on their
own line without any prefix characters.

It would be good if Solderpunk could go ahead and clarify this point in
the spec once and for all.

My 2c,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From sir at cmpwn.com  Fri Nov 13 17:36:01 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Fri, 13 Nov 2020 12:36:01 -0500
Subject: adding space after heading and more
In-Reply-To: <87y2j5duti.fsf@disroot.org>
Message-ID: <C72BG09TOPTE.13XVH8APYPFO5@taiga>

I also support requiring the space, because it's a pretty simple change
that makes the document format and interpretation more strict.

However, to preserve the ability to use the first three characters to
identify the interpretation of a line, it should be required that "###",
with or without a space, is interpreted as a heading.

From cowan at ccil.org  Fri Nov 13 18:02:14 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 13 Nov 2020 13:02:14 -0500
Subject: adding space after heading and more
In-Reply-To: <C72BG09TOPTE.13XVH8APYPFO5@taiga>
References: <87y2j5duti.fsf@disroot.org> <C72BG09TOPTE.13XVH8APYPFO5@taiga>
Message-ID: <CAD2gp_TPCuuJF9DbfBLJTD158NVeZZg4Ui-NAy52b_QNh3QJCg@mail.gmail.com>

On Fri, Nov 13, 2020 at 12:37 PM Drew DeVault <sir at cmpwn.com> wrote:

I also support requiring the space, because it's a pretty simple change
> that makes the document format and interpretation more strict.
>

What happened to "Don't change the spec"?  As written it is very clear: a
line beginning with "#" is a heading, and it can take one of three forms:
"#" + optional whitespace + heading text, "##" + optional whitespace +
heading text, or "###" + optional whitespace + heading text.  It is the
heading text that should be displayed: whether the rest of the line is kept
is completely up to the client.

So the six cases "#foo", "##foo", "###foo", "# foo", "## foo", "### foo"
(and so on for more spaces) all have the same heading text.  Disallowing
the first three cases is a backwards-incompatible change.  In addition,
presumably you would want to disallow "#  foo" (two spaces) as well, which
is an even more backwards-incompatible change.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Tautology is something that is tautological.  --Francois-Rene Rideau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201113/1039a9fa/attachment-0001.htm>

From sir at cmpwn.com  Fri Nov 13 18:06:19 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Fri, 13 Nov 2020 13:06:19 -0500
Subject: adding space after heading and more
In-Reply-To: <CAD2gp_TPCuuJF9DbfBLJTD158NVeZZg4Ui-NAy52b_QNh3QJCg@mail.gmail.com>
Message-ID: <C72C3750Y1MH.TGW295D90Z84@taiga>

I've never really said "Don't change the spec", at least as far as I'm
aware. I'm against the introduction of new features. Clarifications and
refinements of the existing specification would be valuable.

From cowan at ccil.org  Fri Nov 13 18:19:02 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 13 Nov 2020 13:19:02 -0500
Subject: adding space after heading and more
In-Reply-To: <C72C3750Y1MH.TGW295D90Z84@taiga>
References: <CAD2gp_TPCuuJF9DbfBLJTD158NVeZZg4Ui-NAy52b_QNh3QJCg@mail.gmail.com>
 <C72C3750Y1MH.TGW295D90Z84@taiga>
Message-ID: <CAD2gp_T-tH7Nc-wX5aVU038P2Qda2AYvNkXfFtNWJTkK0tU5rQ@mail.gmail.com>

Okay, my bad.  But why is the spec in need of clarification here?

On Fri, Nov 13, 2020 at 1:06 PM Drew DeVault <sir at cmpwn.com> wrote:

> I've never really said "Don't change the spec", at least as far as I'm
> aware. I'm against the introduction of new features. Clarifications and
> refinements of the existing specification would be valuable.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201113/a22d663a/attachment.htm>

From stanner at posteo.de  Fri Nov 13 18:37:47 2020
From: stanner at posteo.de (Philipp Stanner)
Date: Fri, 13 Nov 2020 19:37:47 +0100
Subject: Why not use the markdown way to deal with long lines?
Message-ID: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>

I stumbled over Gemini a while ago and today tried to setup my first
blog post.

I take issue with the fact that a paragraph has to be one long line. I
think the markdown way is perfect: Two newlines create a paragraph.
Period. This way, everyone can write maintaining the common width of 80
characters, and it will still be displayed as intended.

For the first time in a long while I started to search neovim's help to
find out if there's any way to have long lines and still work with them
productively. Softwrap on or off doesn't do the trick, it's rather
annoying when you want to edit something in the mid of a huge
paragraph. `30w cw`...

My life would be more easy if I could just do what I always did and
wrap at 80. Considering Gemini will mostly target software people, I
think that's appropriate.

But if anyone here can provide me with a clever (neovim) trick to deal
with these long lines, I'm open to hear about it.

P.


From sir at cmpwn.com  Fri Nov 13 18:38:24 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Fri, 13 Nov 2020 13:38:24 -0500
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
Message-ID: <C72CRRULHIJ7.2FUY3ZH6N0WR1@taiga>

It simplifies the client design this way.

On Fri Nov 13, 2020 at 1:37 PM EST, Philipp Stanner wrote:
> But if anyone here can provide me with a clever (neovim) trick to deal
> with these long lines, I'm open to hear about it.

Plugin 'https://tildegit.org/sloum/gemini-vim-syntax'
autocmd FileType gmi set wrap linebreak

From tomasino at lavabit.com  Fri Nov 13 18:45:37 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 13 Nov 2020 18:45:37 +0000
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
Message-ID: <b881b6d6-d9f6-d65d-528a-69dbb9d6f3f5@lavabit.com>

On 11/13/20 6:37 PM, Philipp Stanner wrote:
> For the first time in a long while I started to search neovim's help to
> find out if there's any way to have long lines and still work with them
> productively. Softwrap on or off doesn't do the trick, it's rather
> annoying when you want to edit something in the mid of a huge
> paragraph. `30w cw`...

I'm a neovim user. The Pencil plugins are extremely useful for dealing with text in better ways. It provides modes such as :PencilSoft which does exactly what you'd need for gemtext. Without such a plugin, though, you can still use wordwrap with some regular vim settings to break on whole words. For navigating vertically in softwraps you can use gj and gk, or set that as the default with:

noremap <silent> <expr> j (v:count == 0 ? 'gj' : 'j')
noremap <silent> <expr> k (v:count == 0 ? 'gk' : 'k')

It's quite nice to work with once you have the settings in place.


From cowan at ccil.org  Fri Nov 13 19:34:42 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 13 Nov 2020 14:34:42 -0500
Subject: Geminisphere
In-Reply-To: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
References: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
Message-ID: <CAD2gp_QKF-FbPMRhDpxjBYke-72q+x2SYkqcPWuieCAXc5356A@mail.gmail.com>

On Fri, Nov 13, 2020 at 8:41 AM <text at sdfeu.org> wrote:


> If clients would send referers, servers could collect (cache) and
> present those to clients asking for links _to_ the current page
> ("backlinks" in wiki parlance), thus creating an interconnected gemini
> sphere.
>

A more Gemini-style approach would be to have the client keep this
information and add backlinks to the top or bottom of a text/gemini page
when it displays one.  That would give each page three kinds of links: a
backlink, a forward link (one that the user has followed already), and a
blue-sky link (one that the user has never followed).


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Not to perambulate the corridors during the hours of repose
in the boots of ascension.       --Sign in Austrian ski-resort hotel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201113/4b431e1a/attachment.htm>

From stanner at posteo.de  Sat Nov 14 11:06:08 2020
From: stanner at posteo.de (Philipp Stanner)
Date: Sat, 14 Nov 2020 12:06:08 +0100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <C72CRRULHIJ7.2FUY3ZH6N0WR1@taiga>
References: <C72CRRULHIJ7.2FUY3ZH6N0WR1@taiga>
Message-ID: <04ed23eb7a43042ea7a4aa47b1193aee7770fe82.camel@posteo.de>

Am Freitag, den 13.11.2020, 13:38 -0500 schrieb Drew DeVault:
> It simplifies the client design this way.

I guess it does.
But it also almost requires people to install plugins for their
standard tools (or to mouse-click in their editors).
I'm not sure whether I like that ? Gemini is supposed to make
everything more easy and leightweight, after all.

> Plugin 'https://tildegit.org/sloum/gemini-vim-syntax'
> autocmd FileType gmi set wrap linebreak

I'll check it out, thank you.


From tva at fastmail.se  Sat Nov 14 11:08:41 2020
From: tva at fastmail.se (=?UTF-8?Q?=C3=96ppen?=)
Date: Sat, 14 Nov 2020 11:08:41 +0000
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
Message-ID: <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>

> Period. This way, everyone can write maintaining the common width of 80

Mobile phones beg to differ.

From linde.philip at gmail.com  Sat Nov 14 11:33:09 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sat, 14 Nov 2020 12:33:09 +0100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <04ed23eb7a43042ea7a4aa47b1193aee7770fe82.camel@posteo.de>
References: <C72CRRULHIJ7.2FUY3ZH6N0WR1@taiga>
 <04ed23eb7a43042ea7a4aa47b1193aee7770fe82.camel@posteo.de>
Message-ID: <20201114123309.d7b814bce95fa10f6a293a19@gmail.com>

On Sat, 14 Nov 2020 12:06:08 +0100
Philipp Stanner <stanner at posteo.de> wrote:

> But it also almost requires people to install plugins for their
> standard tools (or to mouse-click in their editors).

It doesn't require you to install anything, nor does it require you to
click your mouse. Perhaps you should read the NeoVim manual on
configuring wrapping behavior and display line oriented motions.

Quick guide:

Enable wrapping: set wrap lbr
Display line oriented motions: gj, gk, g^, g$, g0, ...

> I'm not sure whether I like that ? Gemini is supposed to make
> everything more easy and leightweight, after all.

It rather seems like you are overwhelmed by your editor here, not
Gemini. If you want easy, use tools that are easy to you.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201114/094dcd5a/attachment.sig>

From stanner at posteo.de  Sat Nov 14 11:40:48 2020
From: stanner at posteo.de (Philipp Stanner)
Date: Sat, 14 Nov 2020 12:40:48 +0100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
 <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
Message-ID: <c148b409a50f03cc7b52f861e1400a597e421d51.camel@posteo.de>

Am Samstag, den 14.11.2020, 11:08 +0000 schrieb ?ppen:
> > Period. This way, everyone can write maintaining the common width
> > of 80
> 
> Mobile phones beg to differ.

Clients could still render it as desired on the phone.
Just like Markdown:
A single line feed is not printed as a new line by a gemini client, two
are.


From stanner at posteo.de  Sat Nov 14 11:40:32 2020
From: stanner at posteo.de (Philipp Stanner)
Date: Sat, 14 Nov 2020 12:40:32 +0100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
 <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
Message-ID: <bb4971a0c48afa0fb1f4993d4995f059eacb7bbf.camel@posteo.de>

Am Samstag, den 14.11.2020, 11:08 +0000 schrieb ?ppen:
> > Period. This way, everyone can write maintaining the common width
> > of 80
> 
> Mobile phones beg to differ.

Clients could still render it as desired on the phone.
Just like Markdown:
A single line feed is not printed as a new line by a gemini client, two
are.


From flexibeast at gmail.com  Sat Nov 14 12:21:53 2020
From: flexibeast at gmail.com (Alexis)
Date: Sat, 14 Nov 2020 23:21:53 +1100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <c148b409a50f03cc7b52f861e1400a597e421d51.camel@posteo.de>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
 <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
 <c148b409a50f03cc7b52f861e1400a597e421d51.camel@posteo.de>
Message-ID: <874kls3z8e.fsf@ada>


Philipp Stanner <stanner at posteo.de> writes:

> Just like Markdown:
> A single line feed is not printed as a new line by a gemini 
> client, two
> are.

So the 30?000+ text/gemini pages (and maybe a number of the 
80?000+ text/plain pages that are actually gemtext?) currently 
reported by GUS would need to be reformatted by their authors?


Alexis.

From op at omarpolo.com  Sat Nov 14 12:22:32 2020
From: op at omarpolo.com (Omar Polo)
Date: Sat, 14 Nov 2020 13:22:32 +0100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
Message-ID: <871rgwxh4n.fsf@omarpolo.com>


Philipp Stanner <stanner at posteo.de> writes:

> I stumbled over Gemini a while ago and today tried to setup my first
> blog post.
>
> I take issue with the fact that a paragraph has to be one long line. I
> think the markdown way is perfect: Two newlines create a paragraph.
> Period. This way, everyone can write maintaining the common width of 80
> characters, and it will still be displayed as intended.

I think the reason for this choice is due to the fact that in
text/gemini you have different kinds of lines: paragraphs, links,
quotations, items and the ``` marker to switch to verbatim.  If you add
a rule to ?join? sequential non-blank ?simple? lines into one paragraph,
it can cause weird effects.

Let?s say you change some text in the paragraph and you reformat it:
your editor may decide to break a long line so that the next now starts
with a ?*? or with a ?>??  You can change the gemtext spec again so that
items and quotation needs a blank line before but? is ugly, isn?t it?

(this point is also aggravated by the fact that it isn?t clear if a
space after ?*?, ?=>? etc. is required or not, so clients can misbehave,
at least in theory)

I am not a fan of long lines and visual folding either, but it simplify
the syntax (good for parsers) and makes it difficult *for humans* to
introduce errors in their documents.

> For the first time in a long while I started to search neovim's help to
> find out if there's any way to have long lines and still work with them
> productively. Softwrap on or off doesn't do the trick, it's rather
> annoying when you want to edit something in the mid of a huge
> paragraph. `30w cw`...
>
> My life would be more easy if I could just do what I always did and
> wrap at 80. Considering Gemini will mostly target software people, I
> think that's appropriate.
>
> But if anyone here can provide me with a clever (neovim) trick to deal
> with these long lines, I'm open to hear about it.
>
> P.

From stanner at posteo.de  Sat Nov 14 14:37:32 2020
From: stanner at posteo.de (Philipp Stanner)
Date: Sat, 14 Nov 2020 15:37:32 +0100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <874kls3z8e.fsf@ada>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
 <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
 <c148b409a50f03cc7b52f861e1400a597e421d51.camel@posteo.de>
 <874kls3z8e.fsf@ada>
Message-ID: <19ca1dcc0a2097f6f454f8a433ebef2fe98e61ae.camel@posteo.de>

Am Samstag, den 14.11.2020, 23:21 +1100 schrieb Alexis:
> So the 30?000+ text/gemini pages (and maybe a number of the 
> 80?000+ text/plain pages that are actually gemtext?) currently 
> reported by GUS would need to be reformatted by their authors?

In theory, better now than later.
Just think about all the other things which can't be improved or
changed anymore because they were established decades ago and now have
countless users and standards.
Gemini has no RFC yet (or does it?) so if there's a time when
adjustments are still reasonable, then it is now.

In theory.

But Polo's answer sounds rather reasonable anyways.

P.


From linde.philip at gmail.com  Sat Nov 14 15:12:53 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sat, 14 Nov 2020 16:12:53 +0100
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <19ca1dcc0a2097f6f454f8a433ebef2fe98e61ae.camel@posteo.de>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
 <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
 <c148b409a50f03cc7b52f861e1400a597e421d51.camel@posteo.de>
 <874kls3z8e.fsf@ada>
 <19ca1dcc0a2097f6f454f8a433ebef2fe98e61ae.camel@posteo.de>
Message-ID: <20201114161253.ff4feda4564bfc2991490403@gmail.com>

On Sat, 14 Nov 2020 15:37:32 +0100
Philipp Stanner <stanner at posteo.de> wrote:

> In theory, better now than later.

Consider the advantages of a third option: never. To be frank, the
argument you've presented for this change is fundamentally that you
don't know how to use your editor to deal with soft wrapped lines, and
that it makes your life easier not having to learn it. What's the
advantage for the rest of us?

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201114/5e3bfb5b/attachment.sig>

From alex at nytpu.com  Sat Nov 14 16:35:15 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Sat, 14 Nov 2020 09:35:15 -0700
Subject: Geminisphere
In-Reply-To: <CAD2gp_QKF-FbPMRhDpxjBYke-72q+x2SYkqcPWuieCAXc5356A@mail.gmail.com>
References: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
 <CAD2gp_QKF-FbPMRhDpxjBYke-72q+x2SYkqcPWuieCAXc5356A@mail.gmail.com>
Message-ID: <20201114163515.les7dmx2ttcou2wv@GLaDOS>

> If clients would send referers, servers could collect (cache) and
> present those to clients asking for links _to_ the current page
> ("backlinks" in wiki parlance), thus creating an interconnected
> gemini sphere.
I'm gonna call a no on one of the worst parts of http. While we're at it
lets add cookies so servers can preserve state across sessions, which is
very useful functionality and definitely not something that already is
possible to do without substantial privacy invasions. It's funny
because http actually had client certificates first too (TLS RFC dated
August 2008) and then decided that cookies were definitely needed
(Cookies RFC dated April 2011).

> A more Gemini-style approach would be to have the client keep this
> information and add backlinks to the top or bottom of a text/gemini
> page when it displays one. That would give each page three kinds of
> links: a backlink, a forward link (one that the user has followed
> already), and a blue-sky link (one that the user has never followed).
This is an excellent idea, and you don't even need to extend the spec
for this.

I feel the need to reiterate this again: there are lots of creative
things clients (and servers) can do, that don't require *any* changes to
the spec. Caching? Done. Backlinks? Of course! Even if you can't code
I'm sure some client authors would welcome nifty and creative
suggestions like this.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201114/0fba99c5/attachment.sig>

From lel at envs.net  Sat Nov 14 16:44:00 2020
From: lel at envs.net (lel)
Date: Sat, 14 Nov 2020 11:44:00 -0500
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <20201114161253.ff4feda4564bfc2991490403@gmail.com>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
 <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
 <c148b409a50f03cc7b52f861e1400a597e421d51.camel@posteo.de>
 <874kls3z8e.fsf@ada>
 <19ca1dcc0a2097f6f454f8a433ebef2fe98e61ae.camel@posteo.de>
 <20201114161253.ff4feda4564bfc2991490403@gmail.com>
Message-ID: <20201114164400.GA7249@commie.my.domain>

A solution to this problem for those who think this is an issue:

Just write a server that pulls single linebreaks back into one
line in source files before sending them to clients. Then you can
use vim more effectively or whatever without imposing change on a
spec already followed by oodles of clients and servers and
thousands upon thousands of pages of content.

Our options back when softwrap was decided were:

1) hardwrapping at some crazy small number of characters that
would only look good on a phone
2) optionally doing error-prone text reflowing that so it might
look good on something other than a phone
3) what actually happened

Each of these is still less complex than this markdown suggestion
and was done at a time when there was basically no content on the
protocol and even still didn't require anything to be rewritten,
because hard-wrapped content is still viewablw with softwrap.

What is being suggested would require substantial rewrites for 
literally every single thing ever created related to gemini, and
even if we accepted that, would require some means for new
clients to know the difference between the new spec and the old
one, either giving us a new mime type or some kind of version
header, and now we're in solderpunk's nightmare scenario.

So no, I don't think this will happen, but you could always write
a server that autoconverts your markdown-y content into gemtext!

best,
lel

From smlckz at tilde.pink  Sat Nov 14 17:07:30 2020
From: smlckz at tilde.pink (smlckz at tilde.pink)
Date: Sat, 14 Nov 2020 17:07:30 +0000 (UTC)
Subject: (proposal) on metadata in documents
Message-ID: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>

I am proposing a convention of putting human and machine readable metadata 
in documents (in ''geminisphere''). This is completely optional for 
document writers.

The metadata should be placed at the end of the document so that the 
viewers can view the content first.

For now, I am proposing the following metadata for inclusion in documents 
(all of which is optional):

*  the date (and maybe time) when the document was published

*  the date (and maybe time) when the document was last modified

*  copyright information and/or license of the document

IMO, we should use ISO 8601 for the date/time in metadata.

The clients may use the information, but may not hide the metadata.
The spiders/bots can also use the information
(when indexing/archiving documents) as well.

Now the question for you is how the metadata is formatted?
Please share your thoughts on it.


~smlckz

From sir at cmpwn.com  Sat Nov 14 17:08:19 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sat, 14 Nov 2020 12:08:19 -0500
Subject: (proposal) on metadata in documents
In-Reply-To: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
Message-ID: <C735HCE79MV2.O2TC3SOXF8HQ@taiga>

On Sat Nov 14, 2020 at 12:07 PM EST,  wrote:
> * the date (and maybe time) when the document was published
>
> * the date (and maybe time) when the document was last modified

Can already pull this out of RSS

From henderson.j at protonmail.com  Sat Nov 14 17:16:00 2020
From: henderson.j at protonmail.com (James Henderson)
Date: Sat, 14 Nov 2020 17:16:00 +0000
Subject: Why not use the markdown way to deal with long lines?
In-Reply-To: <19ca1dcc0a2097f6f454f8a433ebef2fe98e61ae.camel@posteo.de>
References: <2346073a5487f45dce0004163540c433537be7dd.camel@posteo.de>
 <75547d64-9da2-428a-b812-939a7e32b348@www.fastmail.com>
 <c148b409a50f03cc7b52f861e1400a597e421d51.camel@posteo.de>
 <874kls3z8e.fsf@ada>
 <19ca1dcc0a2097f6f454f8a433ebef2fe98e61ae.camel@posteo.de>
Message-ID: <S3JKQzPcEGYu_E5vIpWQe6bL_unEnJqAqr4NusFaHvemhsIrIq2lZF4fEQwgjiytGujbcXR1UZINY7lWlJeodildhBQs_OOk98ssUg1pvD0=@protonmail.com>

> In theory, better now than later.

Or not at all. If you want markdowns line ends then use markdown.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201114/c745b7f7/attachment.htm>

From gustavo at gsthnz.com  Sat Nov 14 18:43:02 2020
From: gustavo at gsthnz.com (Gustavo Heinz)
Date: Sat, 14 Nov 2020 15:43:02 -0300
Subject: [ANN] Satellite, yet another gemini server
In-Reply-To: <C63BBEE0FQPP.DNV2H62RBN53@valkyrie>
Message-ID: <C737HUZETZYK.3FOAIOPRFDSJR@valkyrie>

Hello there,

I've pushed an update to Satellite with some new features! I've added
configuration file support, virtual hosts and SSL certificate
(re)generation.

I'm currently hosting gemini://gsthnz.com and
gemini://cyberpunksin.space on it. It's working nicely for my needs.

If you do check it out, let me know what you think!

Enjoy,

--
Gustavo Heinz

From luke at marmaladefoo.com  Sat Nov 14 19:46:14 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sat, 14 Nov 2020 19:46:14 +0000
Subject: [ANN] Satellite, yet another gemini server
In-Reply-To: <C737HUZETZYK.3FOAIOPRFDSJR@valkyrie>
References: <C737HUZETZYK.3FOAIOPRFDSJR@valkyrie>
Message-ID: <5FB03406.3070305@marmaladefoo.com>



On 14-Nov-2020 18:43, Gustavo Heinz wrote:
> I'm currently hosting gemini://gsthnz.com and
> gemini://cyberpunksin.space on it. It's working nicely for my needs.
>
> If you do check it out, let me know what you think!

Hi Gustavo

Welcome to Gemini - great to see some new content. I look forward to 
reading more about Gibson. A very minor comment - on cyberpunksin.space 
you have some lists of things, but you use a hyphen not an asterisk as 
the line prefix. If you switch to an asterisk, all the gemini clients 
will render the lists in a pretty way.

Best Wishes

  - Luke

From cowan at ccil.org  Sat Nov 14 20:16:11 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 14 Nov 2020 15:16:11 -0500
Subject: Geminisphere
In-Reply-To: <20201114163515.les7dmx2ttcou2wv@GLaDOS>
References: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
 <CAD2gp_QKF-FbPMRhDpxjBYke-72q+x2SYkqcPWuieCAXc5356A@mail.gmail.com>
 <20201114163515.les7dmx2ttcou2wv@GLaDOS>
Message-ID: <CAD2gp_THCP5VT-wALcZ_OgYGv8UKyg3wr24dfGvrssBrc=0XzA@mail.gmail.com>

On Sat, Nov 14, 2020 at 11:35 AM Alex // nytpu <alex at nytpu.com> wrote:


> It's funny
> because http actually had client certificates first too (TLS RFC dated
> August 2008) and then decided that cookies were definitely needed
> (Cookies RFC dated April 2011).
>

Standardization in the HTTP/HTML world has until very recently been a
matter of trying to catch up with what the browser authors are doing.  Now
the standardizers (the WhatWG) *are* the browser authors.

> This is an excellent idea, and you don't even need to extend the spec
> for this.
>

Thank you.  It's something I've been thinking about since Gopher days, but
Gemini makes it much easier.  Another addition is for a client to add a
link to a page that you jumped away from by manually entering an URL that
points to the page you went to (this would be a forward link).

> Caching? Done. Backlinks? Of course!


There's another idea that goes with the above; have an "itinerary server"
that has access to a specific user's backlinks and cache.  That way you can
publish your personal view of Geminispace, with the pages as they were when
you saw them and your whole path traceable by whoever you give access to
the server.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Schlingt dreifach einen Kreis vom dies!
Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau,
Und trank die Milch vom Paradies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201114/5c196ea7/attachment.htm>

From gustavo at gsthnz.com  Sat Nov 14 20:31:57 2020
From: gustavo at gsthnz.com (Gustavo Heinz)
Date: Sat, 14 Nov 2020 17:31:57 -0300
Subject: [ANN] Satellite, yet another gemini server
In-Reply-To: <5FB03406.3070305@marmaladefoo.com>
Message-ID: <C739T9BULWJ8.CI7S5DW03IIH@valkyrie>

On Sat Nov 14, 2020 at 4:46 PM -03, Luke Emmet wrote:
> you have some lists of things, but you use a hyphen not an asterisk as
> the line prefix. If you switch to an asterisk, all the gemini clients
> will render the lists in a pretty way.

Thanks for the heads up! Fixed.

--
Gustavo Heinz

From sean at conman.org  Sat Nov 14 22:52:22 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 14 Nov 2020 17:52:22 -0500
Subject: (proposal) on metadata in documents
In-Reply-To: <C735HCE79MV2.O2TC3SOXF8HQ@taiga>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <C735HCE79MV2.O2TC3SOXF8HQ@taiga>
Message-ID: <20201114225222.GB19536@brevard.conman.org>

It was thus said that the Great Drew DeVault once stated:
> On Sat Nov 14, 2020 at 12:07 PM EST,  wrote:
> > * the date (and maybe time) when the document was published
> >
> > * the date (and maybe time) when the document was last modified
> 
> Can already pull this out of RSS

  Which version?  There are around half a dozen variations that are not all
compatible with each other.

  -spc (And that also assumes you have an RSS feed for every page on the
	site)


From sean at conman.org  Sat Nov 14 22:57:34 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 14 Nov 2020 17:57:34 -0500
Subject: (proposal) on metadata in documents
In-Reply-To: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
Message-ID: <20201114225734.GC19536@brevard.conman.org>

It was thus said that the Great smlckz at tilde.pink once stated:
> I am proposing a convention of putting human and machine readable metadata 
> in documents (in ''geminisphere''). This is completely optional for 
> document writers.
> 
> The metadata should be placed at the end of the document so that the 
> viewers can view the content first.
> 
> For now, I am proposing the following metadata for inclusion in documents 
> (all of which is optional):
> 
> *  the date (and maybe time) when the document was published
> 
> *  the date (and maybe time) when the document was last modified
> 
> *  copyright information and/or license of the document
> 
> IMO, we should use ISO 8601 for the date/time in metadata.
> 
> The clients may use the information, but may not hide the metadata.
> The spiders/bots can also use the information
> (when indexing/archiving documents) as well.
> 
> Now the question for you is how the metadata is formatted?
> Please share your thoughts on it.

  Okay.

Created 2020-11-14T17:34:19-0500
Modified 2020-11-14T17:50:03-0500
Copyright 2020 by Sean Conner.

  The timestamp was created with the following Unix command: "date +%FT%T%z"
so that's pretty easy.  And you know, if you move the lines to the top of
the document, put the Modified: header first, a client would only have to
read the first 34 bytes of the document to see if it's modified, and if it
hasn't since the client last read it, the client can close the connection. 
Caching solved!

  -spc (Add a Size header and you solve the size problem as well!)

From petite.abeille at gmail.com  Sat Nov 14 23:10:55 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 15 Nov 2020 00:10:55 +0100
Subject: (proposal) on metadata in documents
In-Reply-To: <20201114225734.GC19536@brevard.conman.org>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
Message-ID: <B8CAB795-FD19-4715-86ED-93C617B4F18C@gmail.com>



> On Nov 14, 2020, at 23:57, Sean Conner <sean at conman.org> wrote:
> 
> And you know, if you move the lines to the top of the document

Furthermore, if you add an empty line after all these, hmmm, lines, you have reinvented MIME! Hurray! Smells like 1982 all over again! Long live RFC822!

From petite.abeille at gmail.com  Sat Nov 14 23:24:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 15 Nov 2020 00:24:39 +0100
Subject: (proposal) on metadata in documents
In-Reply-To: <20201114225222.GB19536@brevard.conman.org>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <C735HCE79MV2.O2TC3SOXF8HQ@taiga> <20201114225222.GB19536@brevard.conman.org>
Message-ID: <34E36CE2-83FF-495E-8AE2-0E85C700F0B4@gmail.com>



> On Nov 14, 2020, at 23:52, Sean Conner <sean at conman.org> wrote:
> 
>  Which version?

Atom (Web standard), RFC 4287, December 2005.

>  There are around half a dozen variations that are not all compatible with each other.

Ignore them. No point in replaying a decade of bickering. 

> 
>  -spc (And that also assumes you have an RSS feed for every page on the
> 	site)

...

From khuxkm at tilde.team  Sun Nov 15 04:00:05 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Sun, 15 Nov 2020 04:00:05 +0000
Subject: [ANN] -- kinda? LEO, Molniya, and the greater question of Gemini
 webrings
Message-ID: <d4e7eb830464fe83b0ee3e46963ea75e@tilde.team>

Hey all,

I've been working on an idea today and I'd like to share it with you all.

Earlier we were discussing webrings, and I've created something I think will satisfy some (not all, but you can't please everybody) people's ideas of how a webring would work. I'm calling it an "orbit" (in keeping with the space theme), and the basic idea is pages that want to participate link to a special page that redirects people to the last page, the next page, or even a random page in the orbit. I've also created a software setup for doing it, and a public version people can join.

Introducing LEO, a public orbit that anyone* can join: all you have to do is follow the instructions at gemini://tilde.team/~khuxkm/leo/, and whenever GUS catches on that you've linked to LEO, you should be added to the list! Along with the release of LEO, I'm also releasing Molniya, the code which runs LEO, so that others can start their own orbits without having to worry about coding it themselves.

(*) People who are blocked by GUS or are not indexed by GUS for some reason *can* join LEO but it's a more involved process that involves emailing me. Luckily, if you're not blocked by GUS you can add your capsule to GUS's index pretty easily.

Just my two cents,
Robert "khuxkm" Miles

From sebastian1231alejandro at gmail.com  Sun Nov 15 04:08:14 2020
From: sebastian1231alejandro at gmail.com (Sebastian Alejandro)
Date: Sat, 14 Nov 2020 23:08:14 -0500
Subject: [ANN] -- kinda? LEO, Molniya, and the greater question of
 Gemini webrings
In-Reply-To: <d4e7eb830464fe83b0ee3e46963ea75e@tilde.team>
Message-ID: <C73JIM5YOU23.2S1DCW32XQABN@helios>

Awesome! I'll be sure to join very soon.

- Sebastian

From raiz at stellarbound.space  Sun Nov 15 08:34:12 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 15 Nov 2020 11:34:12 +0300
Subject: A question regarding section 1.2 of the spec
Message-ID: <20201115113412.4a6860aa@home>

1.2:
> The path, query and fragment components are allowed and have no
> special meanings beyond those defined by the generic syntax.

We know that the query portion of URIs is reserved for response code 10
and 11, but fragment is never used anywhere in the protocol.

So both query and fragment are dealt with absolutely differently in the
protocol, but both are categorized under the same "allowed and have no
special meanings", may I ask in what context do they have no special
meanings? I'm confused a bit.

Also, what does "defined by the generic syntax" refer to? what syntax?

From cbabcock at asciiking.com  Sun Nov 15 09:13:54 2020
From: cbabcock at asciiking.com (cbabcock at asciiking.com)
Date: Sun, 15 Nov 2020 09:13:54 +0000
Subject: A question regarding section 1.2 of the spec
In-Reply-To: <20201115113412.4a6860aa@home>
References: <20201115113412.4a6860aa@home>
Message-ID: <b1b68a199c91baa1392081793b21d00f@asciiking.com>

New here, but that never stops me from jumping in...

November 15, 2020 1:34 AM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> 1.2:
> 
>> The path, query and fragment components are allowed and have no
>> special meanings beyond those defined by the generic syntax.
> 
> We know that the query portion of URIs is reserved for response code 10
> and 11, but fragment is never used anywhere in the protocol.

Your use of "reserved" here probably reflects a misunderstanding. You can have a URI with a query indicator without getting a 1x response code first. The word "reserved" in the spec only ever refers to characters that must be escaped.

> So both query and fragment are dealt with absolutely differently in the
> protocol, but both are categorized under the same "allowed and have no
> special meanings", may I ask in what context do they have no special
> meanings? I'm confused a bit.

A URI is best thought of as an opaque identifier. If it happens to have semantic or functional purpose for the server that mechanisms can leverage to improve the reader experience, great, but it's just a way to identify the desired content for delivery. There's a feedback mechanism to refine a query, but no corresponding mechanism for fragments. If there was, it would be something like the anchor tag in HTML.

> Also, what does "defined by the generic syntax" refer to? what syntax?

The generic URI syntax as defined in RFC 3986.

Chris

From raiz at stellarbound.space  Sun Nov 15 11:28:55 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Sun, 15 Nov 2020 14:28:55 +0300
Subject: A question regarding section 1.2 of the spec
In-Reply-To: <b1b68a199c91baa1392081793b21d00f@asciiking.com>
References: <20201115113412.4a6860aa@home>
 <b1b68a199c91baa1392081793b21d00f@asciiking.com>
Message-ID: <20201115142855.09945ec5@home>

On Sun, 15 Nov 2020 09:13:54 +0000
cbabcock at asciiking.com wrote:
> Your use of "reserved" here probably reflects a misunderstanding. You
> can have a URI with a query indicator without getting a 1x response
> code first.

To clarify, I was referring to being reserved for the use in a
standardized protocol specific function.

> The word "reserved" in the spec only ever refers to characters that
> must be escaped.

The word "reserved" refers to characters that must be escaped in RFC
3986, not in the Gemini spec, I was specifically referring to the case
where the query portion of the URI in 1X requests is reserved
specifically for user input therefore it can't be used for other
purpose in that specific case.

I was pointing out the fact that the Gemini spec referred to the query
portion of URI as "allowed and have no special meanings beyond those
defined by the generic syntax", this is confusing because A) the query
portion does have meaning in the context of user input responses, and in
that case it is actually reserved and can not be used for other purpose
B) "the generic syntax" is vague term.

What were you referring to by "the spec", did you mean RFC 3986 or the
Gemini spec?

From andy at andygrn.co.uk  Sun Nov 15 14:35:34 2020
From: andy at andygrn.co.uk (Andy Green)
Date: Sun, 15 Nov 2020 14:35:34 +0000
Subject: [ANN] Aquarius, a PHP app framework for Gemini CGI
Message-ID: <eec1da52-ca8e-b359-6037-74444724620f@andygrn.co.uk>

Hi folks,

Speaking as a jaded web developer, Gemini is truly a delight. I thought 
I'd contribute Aquarius, a PHP framework for creating CGI 'apps'.

Featuring:

* Simple header/body response model, with 'middleware' capability.
* Regex routing, with optional named or unnamed parameters.
* Automatic $_SESSION linking to client certificates (requires 
TLS_CLIENT_HASH env).
* Everything in a single file.

Essentially boring boilerplate, so you can concentrate on building the 
fun stuff!

More info at https://github.com/andygrn/aquarius

...or see a small example app running at 
gemini://andygrn.co.uk/apps/aquarius

From text at sdfeu.org  Sun Nov 15 16:08:43 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Sun, 15 Nov 2020 17:08:43 +0100
Subject: Geminisphere
In-Reply-To: <7827fe630974221c0cc04fa5a7a0ae4217ce6c03.camel@disroot.org>
References: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
 <7827fe630974221c0cc04fa5a7a0ae4217ce6c03.camel@disroot.org>
Message-ID: <a87978bc1cf38bcd9d62eb77dc099dc3@sdfeu.org>

>> If clients would send referers, servers could collect [...]
> 
> [...] sharing information about the user's browsing behaviour with a 
> party that does not technically need to know this information [...] 
> shouldn't be part of a protocol that "takes privacy seriously".

Thanks, privacy and simplicity are very good arguments against 
collecting referers which I fabulated to be useful for establishing 
(back-)links to external pages that cite the currently viewed page.

Getting the impression "backlink" got interpreted differently in other 
comments of this thread, a quote from 
https://en.wikipedia.org/wiki/Backlink#Wikis:
> Backlinks are offered in Wikis, but usually only within the bounds of 
> the Wiki itself and enabled by the database backend. MediaWiki, 
> specifically offers the "What links here" tool, some older Wikis, 
> especially the first WikiWikiWeb, had the backlink functionality 
> exposed in the page title.

Also https://en.wikipedia.org/wiki/Blogosphere:
> The blogosphere is made up of all blogs and their interconnections.

From petite.abeille at gmail.com  Sun Nov 15 16:17:30 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 15 Nov 2020 17:17:30 +0100
Subject: Geminisphere
In-Reply-To: <a87978bc1cf38bcd9d62eb77dc099dc3@sdfeu.org>
References: <157076343ad69ee6833f16684b5a0c2f@sdfeu.org>
 <7827fe630974221c0cc04fa5a7a0ae4217ce6c03.camel@disroot.org>
 <a87978bc1cf38bcd9d62eb77dc099dc3@sdfeu.org>
Message-ID: <D5730982-E204-4233-A276-83A98F151B31@gmail.com>



> On Nov 15, 2020, at 17:08, text at sdfeu.org wrote:
> 
> Also https://en.wikipedia.org/wiki/Blogosphere:
>> The blogosphere is made up of all blogs and their interconnections.

Alternatively:

https://www.eod.com/devil/archive/blogosphere.html



From smlckz at tilde.pink  Sun Nov 15 19:15:54 2020
From: smlckz at tilde.pink (smlckz at tilde.pink)
Date: Sun, 15 Nov 2020 19:15:54 +0000 (UTC)
Subject: (proposal) on metadata in documents
In-Reply-To: <C735HCE79MV2.O2TC3SOXF8HQ@taiga>
References: <C735HCE79MV2.O2TC3SOXF8HQ@taiga>
Message-ID: <alpine.NEB.2.22.394.2011151852230.29956@tilde.pink>

On Sat, 14 Nov 2020, Drew DeVault wrote:
> Can already pull this out of RSS

Every document does not and need not have to have a RSS feed associated with it.
In those pages which have a RSS feed, you need to parse XML and who likes that?
The proposed convention is meant to be simple to parse, write and understand. 
No need for another library.

~smlckz


From smlckz at tilde.pink  Sun Nov 15 19:41:47 2020
From: smlckz at tilde.pink (smlckz at tilde.pink)
Date: Sun, 15 Nov 2020 19:41:47 +0000 (UTC)
Subject: (proposal) on metadata in documents
In-Reply-To: <20201114225734.GC19536@brevard.conman.org>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
Message-ID: <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>

On Sat, 14 Nov 2020, Sean Conner wrote:
>  Okay.
>
> Created 2020-11-14T17:34:19-0500
> Modified 2020-11-14T17:50:03-0500
> Copyright 2020 by Sean Conner.
>
>  The timestamp was created with the following Unix command: "date +%FT%T%z"
> so that's pretty easy.

That's one way of doing that. Can we do better than that?

> And you know, if you move the lines to the top of
> the document, put the Modified: header first, a client would only have to
> read the first 34 bytes of the document to see if it's modified, and if it
> hasn't since the client last read it, the client can close the connection.
> Caching solved!
>
>  -spc (Add a Size header and you solve the size problem as well!)
>

We don't want or need anything like that. That is a breaking change to the spec so breaks all existing clients.

Let me change my wordings a little bit.

>> The metadata should be placed at the end of the document so that the
>> viewers can view the content first.
I should have said ''must'' instead of ''should''.
>> The clients may use the information, but may not hide the metadata.
''must'' not hide.

mmmh..

~smlckz



From jon at shit.cx  Sun Nov 15 23:36:06 2020
From: jon at shit.cx (Jon)
Date: Mon, 16 Nov 2020 10:36:06 +1100
Subject: (proposal) on metadata in documents
In-Reply-To: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
Message-ID: <20201115233606.5oytludaedl3uqd2@devbox>

On 14/11/20 17:07, smlckz at tilde.pink wrote:
> For now, I am proposing the following metadata for inclusion in
> documents (all of which is optional):
> 
> *  the date (and maybe time) when the document was published
> 
> *  the date (and maybe time) when the document was last modified
> 
> *  copyright information and/or license of the document

I would also like a field for the source of the document. This will
allow people to take local copies of documents without loosing track of
where they came from and where updated versions may be found. It may
also simplify mirroring sites too, especially given their is a field for
the license information.

I've had a dilemma about whether I should be placing the sites name at
the top-level heading or elsewhere. If there were a location field, I
would avoid placing the site's name at the top-most header, reclaiming
another layer of heading depth in the process.

Regardless of whether this becomes an official standard, I will probably
adopt this or something like it because it makes so much sense.

I would additionally like a field for the author and authors email
address, but that's less important to me.

I'm also proposing that these additional fields are optional.

-- 
Jon

From sean at conman.org  Mon Nov 16 01:43:03 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 15 Nov 2020 20:43:03 -0500
Subject: (proposal) on metadata in documents
In-Reply-To: <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
 <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>
Message-ID: <20201116014302.GF19536@brevard.conman.org>

It was thus said that the Great smlckz at tilde.pink once stated:
> On Sat, 14 Nov 2020, Sean Conner wrote:
> > Okay.
> >
> >Created 2020-11-14T17:34:19-0500
> >Modified 2020-11-14T17:50:03-0500
> >Copyright 2020 by Sean Conner.
> >
> > The timestamp was created with the following Unix command: "date +%FT%T%z"
> >so that's pretty easy.
> 
> That's one way of doing that. Can we do better than that?

  What's wrong with that format?  It's an ISO standard, it's locale neutral,
easy to parse, and it's easy for humans to read.  I don't think you really
can do better than that.  Unless you really want to parse dates like

	vuos, sk?b 16. b. 2020 02:27:32 CET

> >And you know, if you move the lines to the top of
> >the document, put the Modified: header first, a client would only have to
> >read the first 34 bytes of the document to see if it's modified, and if it
> >hasn't since the client last read it, the client can close the connection.
> >Caching solved!
> >
> > -spc (Add a Size header and you solve the size problem as well!)
> >
> 
> We don't want or need anything like that. That is a breaking change to the 
> spec so breaks all existing clients.

  Like adding headers isn't a breaking change?  And I'm not adding the size
to the MIME type, but to the other "fields", something like:

Created 2020-11-15T20:29:01-0500
Modifie 2020-11-15T20:29:01-0500
Copyright 2020 by Sean Conner
Size 806
Cache not-on-your-life
User-Agent myGeminiClient-1.13
MD5sum fd888c3218f34e71dc57221143d44ccb

> Let me change my wordings a little bit.
> 
> >>The metadata should be placed at the end of the document so that the
> >>viewers can view the content first.
> I should have said ''must'' instead of ''should''.

  Kill joy.

> >>The clients may use the information, but may not hide the metadata.
> ''must'' not hide.
> 
> mmmh..

  Mmmmmh indeed ...

  -spc


From bjorn.warmedal at gmail.com  Mon Nov 16 07:55:16 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Mon, 16 Nov 2020 08:55:16 +0100
Subject: [ANN] Aquarius, a PHP app framework for Gemini CGI
In-Reply-To: <eec1da52-ca8e-b359-6037-74444724620f@andygrn.co.uk>
References: <eec1da52-ca8e-b359-6037-74444724620f@andygrn.co.uk>
Message-ID: <CAJScK0LdfLXWvo6_-=wVLiskaBMHKc-bX_Kim_hUbt6OqmRmpw@mail.gmail.com>

> Speaking as a jaded web developer, Gemini is truly a delight. I thought
> I'd contribute Aquarius, a PHP framework for creating CGI 'apps'.
>
> Featuring:
>
> * Simple header/body response model, with 'middleware' capability.
> * Regex routing, with optional named or unnamed parameters.
> * Automatic $_SESSION linking to client certificates (requires
> TLS_CLIENT_HASH env).
> * Everything in a single file.

Well done!

I started learning Lumen/Laravel a couple of months before I stumbled
into geminispace. Been wondering if it would be long before app
frameworks would be available for gemini :D

Cheers,
ew0k

From linde.philip at gmail.com  Mon Nov 16 08:47:56 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 16 Nov 2020 09:47:56 +0100
Subject: (proposal) on metadata in documents
In-Reply-To: <20201114225734.GC19536@brevard.conman.org>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
Message-ID: <20201116094756.8571873acbf789884747acb3@gmail.com>

On Sat, 14 Nov 2020 17:57:34 -0500
Sean Conner <sean at conman.org> wrote:

> -spc (Add a Size header and you solve the size problem as well!)

Nope, not for as long as it's optional (can never reliably tell that
you've received the complete document if the connection dies before
receiving the full header) and only part of text/gemini (can never tell
what the size is for other document types, which IMO are more likely
to be a concern size-wise; a photo's size easily exceeds that of a
Bible sized text/gemini document).

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201116/801c6031/attachment.sig>

From linde.philip at gmail.com  Mon Nov 16 09:04:26 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 16 Nov 2020 10:04:26 +0100
Subject: (proposal) on metadata in documents
In-Reply-To: <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
 <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>
Message-ID: <20201116100426.3d2dd9e912958a506ac2d2ce@gmail.com>

On Sun, 15 Nov 2020 19:41:47 +0000 (UTC)
smlckz at tilde.pink wrote:

> We don't want or need anything like that. That is a breaking change to the spec so breaks all existing clients.

How so? My client will never interpret such meta-data, and I see the
lack of provisions for it in text/gemini as a feature, but I don't see
how adding it would break my client. To my client, it's regular text
lines in the document body.

The main advantage of this proposal is that the spec really doesn't need
to be concerned with it. It's still text/gemini and there are no
changes to the protocol. That makes it a great honeypot. Hopefully,
most future suggestions for changes to the protocol can instead be
added to an evergrowing list of in-document header fields that no one
will implement.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201116/8397e6ff/attachment.sig>

From smlckz at tilde.pink  Mon Nov 16 10:56:28 2020
From: smlckz at tilde.pink (smlckz at tilde.pink)
Date: Mon, 16 Nov 2020 10:56:28 +0000 (UTC)
Subject: (proposal) on metadata in documents
In-Reply-To: <20201116100426.3d2dd9e912958a506ac2d2ce@gmail.com>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
 <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>
 <20201116100426.3d2dd9e912958a506ac2d2ce@gmail.com>
Message-ID: <alpine.NEB.2.22.394.2011161052370.11041@tilde.pink>

On Mon, 16 Nov 2020, Philip Linde wrote:

> On Sun, 15 Nov 2020 19:41:47 +0000 (UTC)
> smlckz at tilde.pink wrote:
>
>> We don't want or need anything like that. That is a breaking change to the spec so breaks all existing clients.
>
> How so? My client will never interpret such meta-data, and I see the
> lack of provisions for it in text/gemini as a feature, but I don't see
> how adding it would break my client. To my client, it's regular text
> lines in the document body.
What I thought was that if header metadata were to be introduced, they need to
be hidden (at least) as they degrade user experience. You as a visitor do not want
to see the document is X bytes in size or the md5sum or sha512sum of the
document before actual content.

And if they need to be hidden, the spec needs to be changed and that
would break existing clients. Hopefully you can see what I meant.

For this reason, I had to be ''Kill joy'' and amend my proposal so that
the metadata must be placed at the end of the document.

> The main advantage of this proposal is that the spec really doesn't need
> to be concerned with it. It's still text/gemini and there are no
> changes to the protocol. That makes it a great honeypot. Hopefully,
> most future suggestions for changes to the protocol can instead be
> added to an evergrowing list of in-document header fields that no one
> will implement.

Not only text/gemini, but also any other text/* format. I have clearly
stated that this is just metadata. As each field is optional, 
unrecognised fields would be ignored.

> -- 
> Philip
>

~smlckz



From smlckz at tilde.pink  Mon Nov 16 11:17:10 2020
From: smlckz at tilde.pink (smlckz at tilde.pink)
Date: Mon, 16 Nov 2020 11:17:10 +0000 (UTC)
Subject: (proposal) on metadata in documents
In-Reply-To: <20201116014302.GF19536@brevard.conman.org>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
 <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>
 <20201116014302.GF19536@brevard.conman.org>
Message-ID: <alpine.NEB.2.22.394.2011161114320.11041@tilde.pink>

On Sun, 15 Nov 2020, Sean Conner wrote:

>  What's wrong with that format?  It's an ISO standard, it's locale neutral,
> easy to parse, and it's easy for humans to read.  I don't think you really
> can do better than that.  Unless you really want to parse dates like
>
> 	vuos, sk?b 16. b. 2020 02:27:32 CET

I am not against ISO 8601 format and don't want to dive into l10n mess. 
I wonder if we need a seperator between content and metadata or not, or
it'd be better to put the whole metadata into a preformatted text block
with alt-text of `metadata`, or using some prefix for each line of metadata
field. What do you think?


~smlckz



From ranfdev at gmail.com  Mon Nov 16 12:03:22 2020
From: ranfdev at gmail.com (Lorenzo Miglietta)
Date: Mon, 16 Nov 2020 13:03:22 +0100
Subject: On input and uploading of user content
Message-ID: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>

So, I want to make an app to view and edit gemini content. My objective
is to create a blogging platform alternative to medium.com, with
gemini.

I don't understand how I'm suppesed to upload things when using gemini.
By reading the mailing list archive, I've found the following ways:
- Gemini input (max input of 1024B - sizeof(url))
- Titan
- Dioscuri
- Inimeg
- FTP, SFTP, Rsync, ... (Implementing these protocols in the app
requires too much work)

Is there a recommended way to do this? Or should I just look away,
implement everything in http and offer a gemini proxy to read blog
posts?


From tomasino at lavabit.com  Mon Nov 16 12:11:36 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 16 Nov 2020 12:11:36 +0000
Subject: On input and uploading of user content
In-Reply-To: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
Message-ID: <75e86956-0119-8bf7-fd04-0804a642785d@lavabit.com>

On 11/16/20 12:03 PM, Lorenzo Miglietta wrote:
> Is there a recommended way to do this? Or should I just look away,
> implement everything in http and offer a gemini proxy to read blog
> posts?

The recommended way is to use another protocol for uploading content. You can choose which one works best for your needs. Those solutions you mentioned in the email are all valid in their own way, even including HTTP, but you can use whatever is easiest for you. Someone recently shared a post-via-email solution, for instance.

Good luck with your app!


From waweic at activ.ism.rocks  Mon Nov 16 13:18:15 2020
From: waweic at activ.ism.rocks (Waweic)
Date: Mon, 16 Nov 2020 14:18:15 +0100
Subject: On input and uploading of user content
In-Reply-To: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
Message-ID: <31816a0786336a956d9c1e7eb8f474aa8025fde5.camel@activ.ism.rocks>

> So, I want to make an app to view and edit gemini content. My
> objective
> is to create a blogging platform alternative to medium.com, with
> gemini.

I was also thinking about this. I think, if I were to do this, I would
probably settle on one of the already established standards, probably
SFTP or E-Mail. For E-Mail, you could prepare something to your liking
in the App and then use a mailto:-Link to send it over to the server,
for SFTP you could use an already available library and put an ED25519
pubkey on the server using Gemini input. This is especially cool,
because it might work with already existing servers.

Thinking about it, if you are going to build an App around a
centralized service anyways, you could also just build a REST API and
use that one, this is also what HTTP was built for



From lambdatronic at disroot.org  Mon Nov 16 19:03:24 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Mon, 16 Nov 2020 14:03:24 -0500
Subject: [ANN] -- kinda? LEO, Molniya, and the greater question of
 Gemini webrings
In-Reply-To: <d4e7eb830464fe83b0ee3e46963ea75e@tilde.team>
References: <d4e7eb830464fe83b0ee3e46963ea75e@tilde.team>
Message-ID: <87ima586pv.fsf@disroot.org>

Very cool. Thanks for setting this up, Robert. I really love the "orbit"
name for Gemini webrings. Let's hope it gains more widespread usage.

Cheers,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From lambdatronic at disroot.org  Mon Nov 16 19:47:22 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Mon, 16 Nov 2020 14:47:22 -0500
Subject: On input and uploading of user content
In-Reply-To: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
Message-ID: <87eekt84ol.fsf@disroot.org>

> I don't understand how I'm suppesed to upload things when using gemini.
> By reading the mailing list archive, I've found the following ways:
> - Gemini input (max input of 1024B - sizeof(url))
> - Titan
> - Dioscuri
> - Inimeg
> - FTP, SFTP, Rsync, ... (Implementing these protocols in the app
> requires too much work)
>
> Is there a recommended way to do this? Or should I just look away,
> implement everything in http and offer a gemini proxy to read blog
> posts?

Consider that another solution that would be simple for your Gemini app
to handle natively would be to upload your files to a file sharing
service like Nextcloud or Lufi and then to use Gemini response code 10
to prompt your user for the URL of the file they want your app to
import.

Your Gemini server can then make the necessary connection to the file
sharing service to download the file and do whatever it wants with it
before sending a response back to your user.

Nextcloud: https://nextcloud.com/
Lufi:      https://framagit.org/fiat-tux/hat-softwares/lufi

If you want to test it out quickly, there's a public Lufi instance
running on Disroot's servers (please don't abuse it):

  https://upload.disroot.org/

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From cbabcock at asciiking.com  Mon Nov 16 20:30:15 2020
From: cbabcock at asciiking.com (cbabcock at asciiking.com)
Date: Mon, 16 Nov 2020 20:30:15 +0000
Subject: (proposal) on metadata in documents
In-Reply-To: <alpine.NEB.2.22.394.2011161114320.11041@tilde.pink>
References: <alpine.NEB.2.22.394.2011161114320.11041@tilde.pink>
 <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <20201114225734.GC19536@brevard.conman.org>
 <alpine.NEB.2.22.394.2011151922150.29956@tilde.pink>
 <20201116014302.GF19536@brevard.conman.org>
Message-ID: <b08b3b6949c68b2cbe4e80ee1d34fb8c@asciiking.com>

November 16, 2020 4:17 AM, smlckz at tilde.pink wrote:

> I am not against ISO 8601 format and don't want to dive into l10n mess. I wonder if we need a
> seperator between content and metadata or not, or
> it'd be better to put the whole metadata into a preformatted text block
> with alt-text of `metadata`, or using some prefix for each line of metadata
> field. What do you think?
> 
> ~smlckz

The least friction way to implement metadata would be to present it a preformatted yaml:

``` yaml
title:  'This is the title: it contains a colon'
author:
- Author One
- Author Two
keywords: [nothing, nothingness]
abstract: |
  This is the abstract.

  It consists of two paragraphs.
```

A variation that I believe would have utility the most utility in clients would be a new syntactic feature called metadata implemented similar to preformatted blocks, like:

--- yaml
title:  'This is the title: it contains a colon'
author:
- Author One
- Author Two
keywords: [nothing, nothingness]
abstract: |
  This is the abstract.

  It consists of two paragraphs.
---

Not evangelizing yaml in this context, though it's not a bad fit. Just taking my example from Pandoc documentation - https://pandoc.org/MANUAL.html#metadata-blocks 

Obviously document writers *can* include metadata in any document they write, so the question would be whether the value added by encouraging a uniform presentation is worth defining a metadata line type in the specification. I think doing so enables interesting options for client code, and that creating a line type as opposed to dictating page placement is more idiomatically gemini text

Chris

From andy at andygrn.co.uk  Mon Nov 16 22:34:20 2020
From: andy at andygrn.co.uk (Andy Green)
Date: Mon, 16 Nov 2020 22:34:20 +0000
Subject: [ANN] Aquarius, a PHP app framework for Gemini CGI
In-Reply-To: <CAJScK0LdfLXWvo6_-=wVLiskaBMHKc-bX_Kim_hUbt6OqmRmpw@mail.gmail.com>
References: <eec1da52-ca8e-b359-6037-74444724620f@andygrn.co.uk>
 <CAJScK0LdfLXWvo6_-=wVLiskaBMHKc-bX_Kim_hUbt6OqmRmpw@mail.gmail.com>
Message-ID: <bb9c5769-9eca-68dc-c890-12648e3b7dc7@andygrn.co.uk>


> Well done!
> 
> I started learning Lumen/Laravel a couple of months before I stumbled
> into geminispace. Been wondering if it would be long before app
> frameworks would be available for gemini :D
Thanks! PHP and CGI are old friends, you can get a lot out of a small 
library like this. I'm not aspiring to Laravel (or even Lumen) levels of 
complexity, there's enough of that in my day job :D

From sir at cmpwn.com  Mon Nov 16 23:01:38 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 16 Nov 2020 18:01:38 -0500
Subject: Regarding non-finite response bodies
Message-ID: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>

A discussion took place in August that was revisited on IRC today:

https://lists.orbitalfox.eu/archives/gemini/2020/002404.html

I disagree very strongly with the suggestion of gemini+stream://. It
relies upon a presumption about the specification which is poorly
supported: that all Gemini requests are finite.

The supporting text for this is supposedly that section 1.1 lists "C:
Handles response" last. However:

1. Section 1.1 reads like an informative summary of the authoritative
   text which follows
2. There is no explicit specification that these steps are ordered or
   cannot be completed in parallel, and aren't even numbered.

The other relevant piece of text is in 3.3:

> The server closes the connection after the final byte, there is no
> "end of response" signal like gopher's lonely dot.

There is no statement anywhere that there actually has to *be* a final
byte; only a clarification on how the final byte is signalled if
present.

Nothing in the specification prohibits Gemini responses from being
non-finite, and in fact if clients presume this will be the case then
they'll be easily exploited by servers which simply forward /dev/zero
into the connection and never terminate, leading to OOM crashes or disk
space exhaustion.

If you want to stream content, the protocol permits it as-is. And
remember the one big rule:

Do not.
Extend.
Gemini.

From acdw at acdw.net  Mon Nov 16 23:29:46 2020
From: acdw at acdw.net (acdw)
Date: Mon, 16 Nov 2020 23:29:46 +0000
Subject: Regarding non-finite response bodies
In-Reply-To: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
Message-ID: <616b2edb-a148-44d9-9425-aecb7a52858c@www.fastmail.com>

On 2020-11-16 (Monday) at 23:01, Drew DeVault <sir at cmpwn.com> wrote:

> 
> If you want to stream content, the protocol permits it as-is. And
> remember the one big rule:
> 
> Do not.
> Extend.
> Gemini.
>

Hear, hear.  Let's put this to rest.  Clients either will or won't handle streaming; while some problems with UI might deserve solutions (how does a client handle a long-time request?  How to download/stream/save a thing? etc.), I'm sure the smart people on this list and around Geminispace can do so.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From acdw at acdw.net  Mon Nov 16 23:39:19 2020
From: acdw at acdw.net (acdw)
Date: Mon, 16 Nov 2020 23:39:19 +0000
Subject: Scheme Section 2 quibble
Message-ID: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>

Hi gemilist (listini?),

I've got a minor quibble with the spec, section 2, paragraph ... 3(?), which I'll quote here.

> <URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes. If the scheme of the URL is not specified, a scheme of gemini:// is implied.

Specifically, the "scheme of gemini:// is implied" clause is confusing.  According to the URL spec (https://tools.ietf.org/html/rfc3986), 

> The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.

Meaning that the scheme does not, in fact, include a "//" at the end, but rather that "//" is a separator between the scheme and the authority.  In fact, to actually encode a scheme-agnostic URL in a link, an author needs to write "//example.com/path".  For an example, see the links in flounder.online.

I bring this issue up because there have been instances of geminauts linking like this:

=> example.com/path An example link

Which resolves, not to gemini://example.com/path, but to ./example.com/path on the current server.

To resolve this confusion, I propose is to either

(a) strip the "//" (and probably ":", though I found no particular reference to it in the spec) from the "scheme of gemini:// is implied" portion of the above paragraph, or

(b) remove the scheme bit altogether.  I personally prefer this because it's maximally precise.

I'd love to hear your thoughts on the matter.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw 

From colecmac at protonmail.com  Mon Nov 16 23:39:55 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 16 Nov 2020 23:39:55 +0000
Subject: (proposal) on metadata in documents
In-Reply-To: <34E36CE2-83FF-495E-8AE2-0E85C700F0B4@gmail.com>
References: <alpine.NEB.2.22.394.2011141622530.16092@tilde.pink>
 <C735HCE79MV2.O2TC3SOXF8HQ@taiga> <20201114225222.GB19536@brevard.conman.org>
 <34E36CE2-83FF-495E-8AE2-0E85C700F0B4@gmail.com>
Message-ID: <CaA8Zw3B2e0P_QTWiUNGsnFBAFVx6VNQkmKROyo2CFVMZnangYhwN6zKY4AbHSce4KfDQ1H94m7oFIR9WVuUl6IlcTlvSRRhi3K_SxEzFb0=@protonmail.com>

On Saturday, November 14, 2020 6:24 PM, Petite Abeille <petite.abeille at gmail.com> wrote:

> > On Nov 14, 2020, at 23:52, Sean Conner sean at conman.org wrote:
> > Which version?
>
> Atom (Web standard), RFC 4287, December 2005.
>
> > There are around half a dozen variations that are not all compatible with each other.
>
> Ignore them. No point in replaying a decade of bickering.


Seconded. Atom is a strong spec and has not other versions, extensions, date issues, etc
to deal with. It's already used for much of Gemini, thanks to CAPCOM.


makeworld



From tomasino at lavabit.com  Mon Nov 16 23:43:13 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Mon, 16 Nov 2020 23:43:13 +0000
Subject: SPOOFED: Regarding non-finite response bodies
In-Reply-To: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
Message-ID: <ea0c60dd-9d91-d0c2-e973-922d0ae47102@lavabit.com>

On 11/16/20 11:01 PM, Drew DeVault wrote:
> I disagree very strongly with the suggestion of gemini+stream://. It
> relies upon a presumption about the specification which is poorly
> supported: that all Gemini requests are finite.

As the original author of the gemini+stream proposal I want to just jump in with my agreement of Drew's response. Everything I had stated was based on my *incorrect* assumption that the spec was clear that our connection ended before processing data. If that is not the case then any and all Gemini clients can support streaming and we have no need for a +stream add-on.

Hooray for streaming!

> Do not.
> Extend.
> Gemini.

Agreed.


From colecmac at protonmail.com  Mon Nov 16 23:51:33 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 16 Nov 2020 23:51:33 +0000
Subject: Scheme Section 2 quibble
In-Reply-To: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
Message-ID: <wqH14QT5dEcQBR0ypsZv20pQgJi_DhcZjobFSGyPmdJsElswqRUXlNPiHTRf3jGSyUL7Nxo9LmwuTuD6q82bLjuv4UATCumPALpwMp_M-Fg=@protonmail.com>

I think you're confusing what that section is talking about. I believe it is
referring to sending a URL for a request only. It's saying, "when you make a
request, you can leave the gemini:// part out". I don't think it speaks to
links in documents at all, which are governed by the URL RFC.

I agree it's confusing however, because of the use of the word "scheme", while also
including the colon and slashes. I think it's totally fine that those characters
can be left off in the request, but this line should be more clear. How
about saying:

> If the URL does not begin with `gemini://`, then that prefix is implied.
> Leaving off just the `gemini:` portion and starting with `//` also implies
> the gemini scheme, in accordance with the URL spec.

That might be too wordy, and perhaps requiring that all request URLs have a //
would be better. But I don't want to break backwards compatibility.


makeworld


From bie at 202x.moe  Mon Nov 16 23:57:56 2020
From: bie at 202x.moe (bie)
Date: Tue, 17 Nov 2020 08:57:56 +0900
Subject: SPOOFED: Regarding non-finite response bodies
In-Reply-To: <ea0c60dd-9d91-d0c2-e973-922d0ae47102@lavabit.com>
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
 <ea0c60dd-9d91-d0c2-e973-922d0ae47102@lavabit.com>
Message-ID: <20201116235756.GA64479@202x.moe>

On Mon, Nov 16, 2020 at 11:43:13PM +0000, James Tomasino wrote:
> On 11/16/20 11:01 PM, Drew DeVault wrote:
> > I disagree very strongly with the suggestion of gemini+stream://. It
> > relies upon a presumption about the specification which is poorly
> > supported: that all Gemini requests are finite.
> 
> As the original author of the gemini+stream proposal I want to just jump in with my agreement of Drew's response. Everything I had stated was based on my *incorrect* assumption that the spec was clear that our connection ended before processing data. If that is not the case then any and all Gemini clients can support streaming and we have no need for a +stream add-on.
> 
> Hooray for streaming!
> 
> > Do not.
> > Extend.
> > Gemini.
> 
> Agreed.

100% agreed

I'll update my server to no longer respond to gemini+stream:// requests
(it was already responding to them the exact same way as gemini://
requests, so my gemini-backed streaming radio will, of course, remain
"on air")

bie

From cowan at ccil.org  Tue Nov 17 00:02:06 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 16 Nov 2020 19:02:06 -0500
Subject: SPOOFED: Regarding non-finite response bodies
In-Reply-To: <ea0c60dd-9d91-d0c2-e973-922d0ae47102@lavabit.com>
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
 <ea0c60dd-9d91-d0c2-e973-922d0ae47102@lavabit.com>
Message-ID: <CAD2gp_TUQJ9NUdTm_PzLyz7CgfOQvaiE=DBsAEKgi_99Tv1Ytg@mail.gmail.com>

On Mon, Nov 16, 2020 at 6:43 PM James Tomasino <tomasino at lavabit.com> wrote:

As the original author of the gemini+stream proposal I want to just jump in
> with my agreement of Drew's response. Everything I had stated was based on
> my *incorrect* assumption that the spec was clear that our connection ended
> before processing data. If that is not the case then any and all Gemini
> clients can support streaming and we have no need for a +stream add-on.
>

What concerns me, though, is that this suggests that it is forbidden for
any client to drop a connection when nothing has been sent for a while or
the client believes too much data has been sent.  I think we have to make
it clear that not all clients need to be able to accept streaming
transmissions.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
A mosquito cried out in his pain,
"A chemist has poisoned my brain!"
The cause of his sorrow / Was para-dichloro-
Diphenyltrichloroethane.                                (aka DDT)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201116/c07989df/attachment-0001.htm>

From sir at cmpwn.com  Tue Nov 17 00:02:57 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 16 Nov 2020 19:02:57 -0500
Subject: SPOOFED: Regarding non-finite response bodies
In-Reply-To: <CAD2gp_TUQJ9NUdTm_PzLyz7CgfOQvaiE=DBsAEKgi_99Tv1Ytg@mail.gmail.com>
Message-ID: <C753JW5YDW4B.1NVOIIU51ZAEW@taiga>

On Mon Nov 16, 2020 at 7:02 PM EST, John Cowan wrote:
> What concerns me, though, is that this suggests that it is forbidden for
> any client to drop a connection when nothing has been sent for a while
> or the client believes too much data has been sent. I think we have to
> make it clear that not all clients need to be able to accept streaming
> transmissions.

Not accepting streaming transmissions is not really something the client
can do and be a spec-compliant implementation. You can set a maximum
size on the response, or you could set a minimum transfer throughput (I
recommend being generous with that one), and you should let the user
cancel an in-progress request.

From cowan at ccil.org  Tue Nov 17 00:11:19 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 16 Nov 2020 19:11:19 -0500
Subject: SPOOFED: Regarding non-finite response bodies
In-Reply-To: <C753JW5YDW4B.1NVOIIU51ZAEW@taiga>
References: <CAD2gp_TUQJ9NUdTm_PzLyz7CgfOQvaiE=DBsAEKgi_99Tv1Ytg@mail.gmail.com>
 <C753JW5YDW4B.1NVOIIU51ZAEW@taiga>
Message-ID: <CAD2gp_RRUnraRb_3nAGuM+VqR62H0AeCnL87qt=RGhjo-_=OPA@mail.gmail.com>

On Mon, Nov 16, 2020 at 7:04 PM Drew DeVault <sir at cmpwn.com> wrote:

> Not accepting streaming transmissions is not really something the client
> can do and be a spec-compliant implementation. You can set a maximum
> size on the response, or you could set a minimum transfer throughput (I
> recommend being generous with that one),


I'm sorry, all those negations break my poor monkey brain.  The first
sentence seems to say that the client must continue reading to the end of
the response, the second sentence says that it may break it off.  Malicious
servers are, or will be, a fact of life; connection problems are already a
fact of life.

you should let the user
> cancel an in-progress request.
>

Not all clients are interactive.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
We pledge allegiance to the penguin and to the intellectual property
regime for which he stands, one world under Linux, with free music
and open source software for all.  --Julian Dibbell on Brazil, edited
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201116/7a4f7c4d/attachment.htm>

From sir at cmpwn.com  Tue Nov 17 00:12:20 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 16 Nov 2020 19:12:20 -0500
Subject: SPOOFED: Regarding non-finite response bodies
In-Reply-To: <CAD2gp_RRUnraRb_3nAGuM+VqR62H0AeCnL87qt=RGhjo-_=OPA@mail.gmail.com>
Message-ID: <C753R30AJHRZ.1C3A4FM7EC91C@taiga>

On Mon Nov 16, 2020 at 7:11 PM EST, John Cowan wrote:
> I'm sorry, all those negations break my poor monkey brain. The first
> sentence seems to say that the client must continue reading to the end
> of the response, the second sentence says that it may break it off.
> Malicious servers are, or will be, a fact of life; connection problems
> are already a fact of life.

I'm saying that the server could send you a streaming response, and
there's no way for you to stop it from doing so, so you have to be aware
of it and do SOMETHING to make sure it's dealt with properly. And
whatever you choose to do about it should probably be with the best
UI applicable to your use-case.

From cowan at ccil.org  Tue Nov 17 00:57:45 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 16 Nov 2020 19:57:45 -0500
Subject: SPOOFED: Regarding non-finite response bodies
In-Reply-To: <C753R30AJHRZ.1C3A4FM7EC91C@taiga>
References: <CAD2gp_RRUnraRb_3nAGuM+VqR62H0AeCnL87qt=RGhjo-_=OPA@mail.gmail.com>
 <C753R30AJHRZ.1C3A4FM7EC91C@taiga>
Message-ID: <CAD2gp_SeO+dMaydwVq17kOBPZevF7JhEoqiNByV-c7dGJAo3Lw@mail.gmail.com>

On Mon, Nov 16, 2020 at 7:13 PM Drew DeVault <sir at cmpwn.com> wrote:


> I'm saying that the server could send you a streaming response, and
> there's no way for you to stop it from doing so, so you have to be aware
> of it and do SOMETHING to make sure it's dealt with properly. And
> whatever you choose to do about it should probably be with the best
> UI applicable to your use-case.


Ah, then we agree.  Good.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
        Raffiniert ist der Herrgott, aber boshaft ist er nicht.
                --Albert Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201116/1566556f/attachment.htm>

From raiz at stellarbound.space  Tue Nov 17 01:47:45 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 17 Nov 2020 04:47:45 +0300
Subject: Scheme Section 2 quibble
In-Reply-To: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
Message-ID: <20201117044745.7ce92cf7@home>

On Mon, 16 Nov 2020 23:39:19 +0000
acdw <acdw at acdw.net> wrote:
> > The authority component is preceded by a double slash ("//") and is
> > terminated by the next slash ("/"), question mark ("?"), or number
> > sign ("#") character, or by the end of the URI.  
> 
> Meaning that the scheme does not, in fact, include a "//" at the end,
> but rather that "//" is a separator between the scheme and the
> authority.  In fact, to actually encode a scheme-agnostic URL in a
> link, an author needs to write "//example.com/path".  For an example,
> see the links in flounder.online.
> 
> I bring this issue up because there have been instances of geminauts
> linking like this:
> 
> => example.com/path An example link  
> 
> Which resolves, not to gemini://example.com/path, but
> to ./example.com/path on the current server.

This is wrong, even by web standards, when referencing to a different
host, one must explicitly write a valid URL, you DON'T see:

>	<a href="example.tld/index.html"></a>

> To resolve this confusion, I propose is to either
> 
> (a) strip the "//" (and probably ":", though I found no particular
> reference to it in the spec) from the "scheme of gemini:// is
> implied" portion of the above paragraph, or

In my humble opinion, I think that "//example.tld/" is an
implementation specific hack and has no place in the protocol, a URI
like that is invalid and should not be respected by servers, what
should actually work is providing authority and path like so:
"example.tld/path/", this is discouraged by RFC 3986 (section 4.5) but
it actually makes sense if context is defined, in this case, context is
gemini so a scheme of gemini is implied.

Also, this is the default behavior for web browsers implying scheme of
http(s), which I think is acceptable and convenient behavior, so I
agree with you on that, assuming that's what you meant.

> (b) remove the scheme bit altogether.  I personally prefer this
> because it's maximally precise.

The scheme bit in requests allows for proxies to work, for example,
when I host a proxy instance at "gemini://raiz.proxy/" someone sends a
request of "https://example.tld/", my proxy can fetch the page and send
it back to the client through gemini, I think that's why it's there.

Perhaps there are many many other use cases for this that I haven't
thought of.

From sean at conman.org  Tue Nov 17 02:07:54 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 16 Nov 2020 21:07:54 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
Message-ID: <20201117020752.GM19536@brevard.conman.org>

It was thus said that the Great acdw once stated:
> I've got a minor quibble with the spec, section 2, paragraph ... 3(?),
> which I'll quote here.
> 
> > <URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes. If
> > the scheme of the URL is not specified, a scheme of gemini:// is
> > implied.

  [ snip ]

> To resolve this confusion, I propose is to either
> 
> (a) strip the "//" (and probably ":", though I found no particular
> reference to it in the spec) from the "scheme of gemini:// is implied"
> portion of the above paragraph, or
> 
> (b) remove the scheme bit altogether.  I personally prefer this because
> it's maximally precise.
> 
> I'd love to hear your thoughts on the matter.

  This has come up before [1][2], and as I have stated [3][4], the '//' is
considered part of the host (or at least, a marker for the host portion of a
URL) and thus, I think the wording of section 2 should be changed to read

	<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
	If the scheme of the URL is not specified, a scheme of gemini: is
	implied.

  -spc

[1]	https://lists.orbitalfox.eu/archives/gemini/2020/001006.html

[2]	https://lists.orbitalfox.eu/archives/gemini/2020/002954.html

[3]	https://lists.orbitalfox.eu/archives/gemini/2020/001009.html

[4]	https://lists.orbitalfox.eu/archives/gemini/2020/002964.html

From sean at conman.org  Tue Nov 17 02:19:16 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 16 Nov 2020 21:19:16 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117044745.7ce92cf7@home>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
Message-ID: <20201117021911.GN19536@brevard.conman.org>

It was thus said that the Great Ali Fardan once stated:
> On Mon, 16 Nov 2020 23:39:19 +0000
> acdw <acdw at acdw.net> wrote:
> > > The authority component is preceded by a double slash ("//") and is
> > > terminated by the next slash ("/"), question mark ("?"), or number
> > > sign ("#") character, or by the end of the URI.  
> > 
> > Meaning that the scheme does not, in fact, include a "//" at the end,
> > but rather that "//" is a separator between the scheme and the
> > authority.  In fact, to actually encode a scheme-agnostic URL in a
> > link, an author needs to write "//example.com/path".  For an example,
> > see the links in flounder.online.
> > 
> > I bring this issue up because there have been instances of geminauts
> > linking like this:
> > 
> > => example.com/path An example link  
> > 
> > Which resolves, not to gemini://example.com/path, but
> > to ./example.com/path on the current server.
> 
> This is wrong, even by web standards, when referencing to a different
> host, one must explicitly write a valid URL, you DON'T see:
> 
> >	<a href="example.tld/index.html"></a>
> 
> > To resolve this confusion, I propose is to either
> > 
> > (a) strip the "//" (and probably ":", though I found no particular
> > reference to it in the spec) from the "scheme of gemini:// is
> > implied" portion of the above paragraph, or
> 
> In my humble opinion, I think that "//example.tld/" is an
> implementation specific hack and has no place in the protocol, a URI
> like that is invalid and should not be respected by servers, 

  It *is* allowed though---it's a schemeless URI and in a given context, it
can be inferred.  Check out RFC-3986 section 5.2.2 (Transforming
Rreferences, aka, resolving a URL with a base URL) and section 5.3
(Component Recomposision) where ':' is appended to the scheme, and '//' is
prefixed to the authority (host) section.

  So, given a URL like this:

	//example.net/path/to/resource

in a resource, if the resource was served up via HTTP, then the scheme is
'http:'; if HTTPS, then 'https:' and if gemini, 'gemini:'.  

  A URL like this:

	example.net/path/to/resource

is, again, per RFC-3986 parsing rules, to be interpreted as a path, not an
authority section then path.  Need I create an example to show this?  I can.

  -spc


From raiz at stellarbound.space  Tue Nov 17 02:28:37 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 17 Nov 2020 05:28:37 +0300
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117021911.GN19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117021911.GN19536@brevard.conman.org>
Message-ID: <20201117052837.5bc19065@home>

On Mon, 16 Nov 2020 21:19:16 -0500
Sean Conner <sean at conman.org> wrote:
>   It *is* allowed though---it's a schemeless URI and in a given
> context, it can be inferred.  Check out RFC-3986 section 5.2.2
> (Transforming Rreferences, aka, resolving a URL with a base URL) and
> section 5.3 (Component Recomposision) where ':' is appended to the
> scheme, and '//' is prefixed to the authority (host) section.
> 
>   So, given a URL like this:
> 
> 	//example.net/path/to/resource
> 
> in a resource, if the resource was served up via HTTP, then the
> scheme is 'http:'; if HTTPS, then 'https:' and if gemini, 'gemini:'.  
> 
>   A URL like this:
> 
> 	example.net/path/to/resource
> 
> is, again, per RFC-3986 parsing rules, to be interpreted as a path,
> not an authority section then path.  Need I create an example to show
> this?  I can.

You are correct.

From bjorn.warmedal at gmail.com  Tue Nov 17 08:35:42 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Tue, 17 Nov 2020 09:35:42 +0100
Subject: Regarding non-finite response bodies
In-Reply-To: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
Message-ID: <CAJScK0JS4WA2gLCHgEd1qft3x8PqcNGgs17C46h1dMUtnF9FnQ@mail.gmail.com>

> [...] It
> relies upon a presumption about the specification which is poorly
> supported: that all Gemini requests are finite.
> [...]
> Nothing in the specification prohibits Gemini responses from being
> non-finite, and in fact if clients presume this will be the case then
> they'll be easily exploited by servers which simply forward /dev/zero
> into the connection and never terminate, leading to OOM crashes or disk
> space exhaustion.

This is interesting. I'm writing a python lib for handling gemini
requests, to simplify browser development. I just assumed that
responses are finite, and as my code works now a method initiates a
request, receives the response, builds a response object and returns
it to the caller.

If responses can be infinite this will indeed cause OOM errors and
crash, and the caller won't know what hit 'em. Should I be reading the
header and return a response object that contains an open socket
instead of a byte array? Can we assume that browser developers
understand this ambiguity and handle it correctly?

- ew0k

From felix at masterq32.de  Tue Nov 17 08:41:07 2020
From: felix at masterq32.de (=?UTF-8?Q?Felix_Quei=c3=9fner?=)
Date: Tue, 17 Nov 2020 09:41:07 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117021911.GN19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home> <20201117021911.GN19536@brevard.conman.org>
Message-ID: <1e2c09e7-0e0d-3f46-6760-2e84fadce0fd@masterq32.de>

Heya!

>   It *is* allowed though---it's a schemeless URI and in a given context, it
> can be inferred.  Check out RFC-3986 section 5.2.2 (Transforming
> Rreferences, aka, resolving a URL with a base URL) and section 5.3
> (Component Recomposision) where ':' is appended to the scheme, and '//' is
> prefixed to the authority (host) section.
> 
>   So, given a URL like this:
> 
> 	//example.net/path/to/resource
> 
> in a resource, if the resource was served up via HTTP, then the scheme is
> 'http:'; if HTTPS, then 'https:' and if gemini, 'gemini:'.  

I'm using this on gemini sites that are also hosted in web space. This
allows cross-server linking without changing protocol, it's very convenient.

>   A URL like this:
>
> 	example.net/path/to/resource
>
> is, again, per RFC-3986 parsing rules, to be interpreted as a path, not an
> authority section then path.  Need I create an example to show this?
I can.

Exactly.

From linde.philip at gmail.com  Tue Nov 17 09:19:52 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 17 Nov 2020 10:19:52 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117044745.7ce92cf7@home>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
Message-ID: <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>

On Tue, 17 Nov 2020 04:47:45 +0300
Ali Fardan <raiz at stellarbound.space> wrote:

> In my humble opinion, I think that "//example.tld/" is an
> implementation specific hack and has no place in the protocol, a URI
> like that is invalid and should not be respected by servers, what
> should actually work is providing authority and path like so:
> "example.tld/path/", this is discouraged by RFC 3986 (section 4.5) but
> it actually makes sense if context is defined, in this case, context is
> gemini so a scheme of gemini is implied.

With respect to RFC3986, it's not a matter of opinion.

It's very much not an implementation specific hack. It's defined in RFC
3986 as "relative-ref", a "network-path reference" specifically.
Non-URIs of the "example.com/hello" style on the other hand are an
implementation specific hack, as you've noted, discouraged by RFC 3986
and not specified in any of the syntaxes it defines. It's obviously
unsuitable for links because it's ambiguous with relative-ref.

Gemini however explicitly only allows "absolute URL" in requests. It
also says that "If the scheme of the URL is not specified, a scheme of
gemini:// is implied."

In terms of RFC 3986, this is nonsense. "gemini://" isn't the scheme.
"gemini" is the scheme, "//" is the beginning of hier-part or
relative-part, and ":" separates the scheme from hier-part.

I've previously called for clarification on this point. One might read
that last sentence as requests by suffix references are allowed,
(which is what you get when you omit "gemini://") or that some
relative-ref are allowed (which is what you get if you literally omit
the scheme and scheme separator).

I'd prefer if the spec could just refer to an expected syntax as
defined in RFC 3986. This would reduce confusion significantly. Skip
all the hacks and allow only e.g. the URI syntax (which does not
include relative-ref) for requests and URI-reference syntax (which
includes URI and relative-ref) for links. Adopt the language of RFC
3986 to describe them.

Last I checked, if you connect to gemini://gemini.circumlunar.space and
request "gemini.circumlunar.space/" you get an error. You may however
request "//gemini.circumlunar.space/" and get the appropriate 20
response. Should gemini.circumlunar.space be considered to be running a
canonical implementation of Gemini?

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201117/6ace088e/attachment.sig>

From linde.philip at gmail.com  Tue Nov 17 09:37:45 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 17 Nov 2020 10:37:45 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117020752.GM19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117020752.GM19536@brevard.conman.org>
Message-ID: <20201117103745.5ebdb01fb30c54dba253c18d@gmail.com>

On Mon, 16 Nov 2020 21:07:54 -0500
Sean Conner <sean at conman.org> wrote:

>   This has come up before [1][2], and as I have stated [3][4], the '//' is
> considered part of the host (or at least, a marker for the host portion of a
> URL) and thus, I think the wording of section 2 should be changed to read
> 
> 	<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
> 	If the scheme of the URL is not specified, a scheme of gemini: is
> 	implied.
> 

"gemini:" is not a valid scheme. ":" is part of the URI and
absolute-URI syntaxes defined in RFC 3986, not the scheme. The spec
should be able to express any sensible acceptable URI syntax in terms of
the syntaxes and terminology defined in RFC 3986. There's no need to add
weird exceptions outside RFC 3986 that aren't already covered in it.

For example, the spec can read: "<URL> is an UTF-8 encoded URI or
network-path reference as defined in RFC 3986" (requests) and "<URL> is
an UTF-8 encoded URI-reference as defined in RFC 3986" (links).

If we want requests like "gemini.circumlunar.space/" to be valid, it
can additionally read that <URL> allows suffix references.

To call it an "absolute URL" is especially concerning since Gemini
apparently allows fragments, but RFC 3986 defines an "absolute-URI"
syntax which does not.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201117/53a8277c/attachment.sig>

From colecmac at protonmail.com  Tue Nov 17 13:13:07 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 17 Nov 2020 13:13:07 +0000
Subject: Regarding non-finite response bodies
In-Reply-To: <CAJScK0JS4WA2gLCHgEd1qft3x8PqcNGgs17C46h1dMUtnF9FnQ@mail.gmail.com>
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
 <CAJScK0JS4WA2gLCHgEd1qft3x8PqcNGgs17C46h1dMUtnF9FnQ@mail.gmail.com>
Message-ID: <dpWA5UWVKPvTPbG4EHIzTvFCHdxNxjFtosn1PFtVgrxuLEvyDmxeTdtsD9p3oWHEJGweZ_YLPrTYzvX9Yd77gYtLU6Q3llo6a9rV0oXyGtA=@protonmail.com>

> Should I be reading the header and return a response object that
> contains an open socket instead of a byte array?

Yes. This is what I've seen from Go libraries as well, and it provides
a simple solution that gives the developer the most power.


makeworld

From ben at benaaron.dev  Tue Nov 17 14:03:59 2020
From: ben at benaaron.dev (Ben Goldberg)
Date: Tue, 17 Nov 2020 09:03:59 -0500
Subject: Regarding non-finite response bodies
In-Reply-To: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
Message-ID: <25492900-d096-a7b0-d8c7-d8c1d69b07d1@benaaron.dev>

When I read the spec I did not understand this.  I'd be nice if this was 
stated explicitly in the the spec if that was in fact the intention.

From raiz at stellarbound.space  Tue Nov 17 14:42:54 2020
From: raiz at stellarbound.space (Ali Fardan)
Date: Tue, 17 Nov 2020 17:42:54 +0300
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
Message-ID: <20201117174254.1d75318f@home>

On Tue, 17 Nov 2020 10:19:52 +0100
Philip Linde <linde.philip at gmail.com> wrote:
> With respect to RFC3986, it's not a matter of opinion.
> 
> It's very much not an implementation specific hack. It's defined in
> RFC 3986 as "relative-ref", a "network-path reference" specifically.
> Non-URIs of the "example.com/hello" style on the other hand are an
> implementation specific hack, as you've noted, discouraged by RFC 3986
> and not specified in any of the syntaxes it defines. It's obviously
> unsuitable for links because it's ambiguous with relative-ref.

I don't know about that, section 3.2 states that authority should be
preceded by a "//", not that it is a part of the authority component,
also, the ABNF representation has no "//" in it.

Suffix references (section 4.5) are only discouraged because of
possible misinterpretation, however in the case of Gemini requests,
people can write their code to handle them just like they write their
code to handle "//example.tld", it's not that hard and looks much much
cleaner, the argument that it could be interpreted as path should also
apply for "//example.tld" too, because it could be interpreted as a
path too, however if the author decided to handle such case, it'll be
handled just fine, you can have your parser treat the text before the
first occurrence of '/' as host subcomponent of authority component if
scheme is not specified just like you have your parser treat the first
occurrence of '/' after the "//" prefix as host subcomponent in the
current way of handling schemeless requests in Gemini, the Gemini
protocol requires passing full URL in requests, therefore, such should
not be interpreted as path because Gemini requests don't allow path
without stating host.

So yeah, I'm not changing my mind, "//example.tld" is a hack because
that is not a valid URI and "//" is supposed to be only present when
scheme is specified, however, "example.tld" is while discouraged,
acceptable for this use case and the RFC even acknowledged it.

Let me quote to you why it is that RFC 3986 discourages its use:

> Although this practice of using suffix references is common, it
> should be avoided whenever possible and should never be used in
> situations where long-term references are expected.

In the case of Gemini requests, they are not a 'long-term' reference,
they're one-time requests, I don't see any downside to not doing it.

> Last I checked, if you connect to gemini://gemini.circumlunar.space
> and request "gemini.circumlunar.space/" you get an error. You may
> however request "//gemini.circumlunar.space/" and get the appropriate
> 20 response. Should gemini.circumlunar.space be considered to be
> running a canonical implementation of Gemini?

You shouldn't look at any particular implementation as a reference for
the spec, I'm assuming gemini.circumlunar.space is running molly-brown,
do you know that molly-brown treats single '\n' as valid request
terminators instead of explicit '\r\n'? (see:
https://tildegit.org/solderpunk/molly-brown/src/branch/master/handler.go#L138),
do you know that if a transaction is finished, molly-brown waits for
the client to close the connection instead of closing it from the
server side, is that spec compliant?

The reason I think molly-brown accepted "//example.tld" in the first
place is because the Go standard library URL parser implementation
accepted this, I don't know if this was a bug or it is intended design,
but that's what it is, other URI parsers that are more strict with
compliance to the RFC will refuse to parse a URI without scheme
present, here is an excerpt from the library's documentation that might
give an idea of how they treat URLs:

> A URL represents a parsed URL (technically, a URI reference).
>
> The general form represented is:
>
> [scheme:][//[userinfo@]host][/]path[?query][#fragment]
>
> URLs that do not start with a slash after the scheme are
> interpreted as:
>
> scheme:opaque[?query][#fragment]

Notice that [scheme:] is enclosed in brackets implying that it is
optional, while [//host] is optional too, the "//" is considered a part
of the authority component by the Go URL parser implementation, this is
why "//example.tld" is accepted while "example.tld" is not, try passing
both strings to url.Parse() and see what you get.

From jmcbray at carcosa.net  Tue Nov 17 15:29:49 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 17 Nov 2020 10:29:49 -0500
Subject: Regarding non-finite response bodies
In-Reply-To: <CAJScK0JS4WA2gLCHgEd1qft3x8PqcNGgs17C46h1dMUtnF9FnQ@mail.gmail.com>
 (=?utf-8?Q?=22Bj=C3=B6rn=09W=C3=A4rmedal=22's?= message of "Tue, 17 Nov
 2020 09:35:42 +0100")
References: <C7528Y7BF1AR.BMLOTJSTZSUO@taiga>
 <CAJScK0JS4WA2gLCHgEd1qft3x8PqcNGgs17C46h1dMUtnF9FnQ@mail.gmail.com>
Message-ID: <87blfwxaqa.fsf@dorothy.carcosa.net>

Bj?rn W?rmedal <bjorn.warmedal at gmail.com> writes:

> This is interesting. I'm writing a python lib for handling gemini
> requests, to simplify browser development. I just assumed that
> responses are finite, and as my code works now a method initiates a
> request, receives the response, builds a response object and returns
> it to the caller.

If you get this lib to a good place, let me know, and I will deprecate
`gusmobile'. I've done a pretty terrible job maintaining it because I'm
not actually using it for anything.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From me at rwv.io  Tue Nov 17 15:42:05 2020
From: me at rwv.io (Remco)
Date: Tue, 17 Nov 2020 16:42:05 +0100
Subject: [ANN] =?utf-8?B?RMqSyZttyapuaSw=?= a gemini server
Message-ID: <87ft58f0s2.fsf@rwv.io>

Announcing d??m?ni, a gemini server.  It's new, it's free, it's my first
application written in racket (feedback about racket style welcome!),
and works pretty well, if I may say so myself.

D??m?ni has the following features:

* serve static files
* CGI scripts
* content type from file extensions
* ability to add own mime.types file to add extensions
* automatically generates a server certificate (using openssl)
* no directory listings (but serving index.gmi instead)
* no configuration file

It's written in Racket and does not depend on any external modules.

=> https://sr.ht/~rwv/dezhemini/

A shout out to Michael Lazar for sharing gemini-diagnostics and making
writing a gemini server much easier!

=> https://github.com/michael-lazar/gemini-diagnostics

A hat tip to Drew DeVault for nagging me about auto generating
certificates even before I was ready to make a proper announcement.

And much praise for solderpunk for keeping it simple and making me want
to write my own server, and of course the racket community for providing
an awesome platform to write software on.

I hope some of you will find d??m?ni useful.

Cheers,
R.

From sean at conman.org  Tue Nov 17 22:10:41 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 17 Nov 2020 17:10:41 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117174254.1d75318f@home>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home>
Message-ID: <20201117221041.GO19536@brevard.conman.org>

It was thus said that the Great Ali Fardan once stated:
> On Tue, 17 Nov 2020 10:19:52 +0100
> Philip Linde <linde.philip at gmail.com> wrote:
> > With respect to RFC3986, it's not a matter of opinion.
> > 
> > It's very much not an implementation specific hack. It's defined in
> > RFC 3986 as "relative-ref", a "network-path reference" specifically.
> > Non-URIs of the "example.com/hello" style on the other hand are an
> > implementation specific hack, as you've noted, discouraged by RFC 3986
> > and not specified in any of the syntaxes it defines. It's obviously
> > unsuitable for links because it's ambiguous with relative-ref.
> 
> I don't know about that, section 3.2 states that authority should be
> preceded by a "//", not that it is a part of the authority component,
> also, the ABNF representation has no "//" in it.
> 
> Suffix references (section 4.5) are only discouraged because of
> possible misinterpretation, however in the case of Gemini requests,
> people can write their code to handle them just like they write their
> code to handle "//example.tld", it's not that hard and looks much much
> cleaner, the argument that it could be interpreted as path should also
> apply for "//example.tld" too, because it could be interpreted as a
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> path too, however if the author decided to handle such case, it'll be
  ^^^^^^^^^
  Citation needed.

  I'm sorry, this just isn't the case.  From the full ABNF in Appendix A:

   URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   hier-part     = "//" authority path-abempty
                 / path-absolute 
                 / path-rootless 
                 / path-empty

   URI-reference = URI / relative-ref
   
   absolute-URI  = scheme ":" hier-part [ "?" query ]

   relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

   relative-part = "//" authority path-abempty
                 / path-absolute
                 / path-noscheme
                 / path-empty 

[ NON-PATH RELATED RULES OMITTED FOR SPACE I REPEAT NON-PATH RELATED RULES OMITTED FOR SPACE ]

   path          = path-abempty    ; begins with "/" or is empty
                 / path-absolute   ; begins with "/" but not "//"
                 / path-noscheme   ; begins with a non-colon segment
                 / path-rootless   ; begins with a segment
                 / path-empty      ; zero characters

   path-abempty  = *( "/" segment )
   path-absolute = "/" [ segment-nz *( "/" segment ) ]
   path-noscheme = segment-nz-nc *( "/" segment )
   path-rootless = segment-nz *( "/" segment )
   path-empty    = 0<pchar>

  The path parsing rules state a single slash.  Not '/'+, nor '/'*, but a
single '/'.  The only place where more than a single slash is allowed PER
THE @#%@#$@$ ABNF is just prior to the authority, which contains the
hostname.  THE ONLY PLACE!  

  I will also draw your attention to the URI-reference rule, which is there
for some reason, which allows both a full URI, or a RELATIVE URI, which
means that

		//example.com/path/to/resource

IS A VALID URI!  IT IS NOT A HACK!  What part of the ABNF do you not
understand?

> handled just fine, you can have your parser treat the text before the
> first occurrence of '/' as host subcomponent of authority component if
> scheme is not specified just like you have your parser treat the first
> occurrence of '/' after the "//" prefix as host subcomponent in the
> current way of handling schemeless requests in Gemini, the Gemini
> protocol requires passing full URL in requests, therefore, such should
> not be interpreted as path because Gemini requests don't allow path
> without stating host.

  No, the spec allows both the full URI, and a relative URI as long as it
starts with '//' (it has the authority section).  The wording in the spec is
bad and should be changed to clarify it, but that's the current
specification.  

  Again,

		//example.com/path/to/resource

IS NOT A HACK!

> So yeah, I'm not changing my mind, "//example.tld" is a hack because
> that is not a valid URI and "//" is supposed to be only present when
> scheme is specified, however, "example.tld" is while discouraged,
> acceptable for this use case and the RFC even acknowledged it.
> 
> Let me quote to you why it is that RFC 3986 discourages its use:
> 
> > Although this practice of using suffix references is common, it
> > should be avoided whenever possible and should never be used in
> > situations where long-term references are expected.
> 
> In the case of Gemini requests, they are not a 'long-term' reference,
> they're one-time requests, I don't see any downside to not doing it.
> 
> > Last I checked, if you connect to gemini://gemini.circumlunar.space
> > and request "gemini.circumlunar.space/" you get an error. You may
> > however request "//gemini.circumlunar.space/" and get the appropriate
> > 20 response. Should gemini.circumlunar.space be considered to be
> > running a canonical implementation of Gemini?
> 
> You shouldn't look at any particular implementation as a reference for
> the spec, 

  I believe Philip used gemini.circumlunar.space because that's the server
written by solderpunk, author of the specification.  

> I'm assuming gemini.circumlunar.space is running molly-brown,

  Also written by solderpunk.  The bastard!  Writing a Gemini server that
doesn't follow his specification!

> do you know that molly-brown treats single '\n' as valid request
> terminators instead of explicit '\r\n'? (see:
> https://tildegit.org/solderpunk/molly-brown/src/branch/master/handler.go#L138),
> do you know that if a transaction is finished, molly-brown waits for
> the client to close the connection instead of closing it from the
> server side, is that spec compliant?
> 
> The reason I think molly-brown accepted "//example.tld" in the first
> place is because the Go standard library URL parser implementation
> accepted this, I don't know if this was a bug or it is intended design,

  It's by design---see the ABNF above.  

> but that's what it is, other URI parsers that are more strict with
> compliance to the RFC will refuse to parse a URI without scheme
> present, 

  If it does, it's broken by design.  Again, see the ABNF above.

> here is an excerpt from the library's documentation that might
> give an idea of how they treat URLs:
> 
> > A URL represents a parsed URL (technically, a URI reference).
> >
> > The general form represented is:
> >
> > [scheme:][//[userinfo@]host][/]path[?query][#fragment]
> >
> > URLs that do not start with a slash after the scheme are
> > interpreted as:
> >
> > scheme:opaque[?query][#fragment]
> 
> Notice that [scheme:] is enclosed in brackets implying that it is
> optional, while [//host] is optional too, the "//" is considered a part
> of the authority component by the Go URL parser implementation, this is
> why "//example.tld" is accepted while "example.tld" is not, try passing
> both strings to url.Parse() and see what you get.

  Yes, exactly.  Again, that's per the ABNF above.  Why do you not get this? 
Here, have one more excerpt from RFC-3986, this time from section 3:

   The following are two example URIs and their component parts:

         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         / \ /                        \
         urn:example:animal:ferret:nose

and the URL parsing library I have parses those as:

['foo://example.com:8042/over/there?name=ferret#nose'] =
{
  fragment = "nose",
  query = "name=ferret",
  path = "/over/there",
  scheme = "foo",
  port = 8042.000000,
  host = "example.com",
}

['urn:example:animal:ferret:nose'] =
{
  path = "example:animal:ferret:nose",
  scheme = "urn",
}

and because I like belaboring the inanimate equus pleonastically:

["//example.com/path/to/resource"] =
{
  host = "example.com",
  path = "/path/to/resource",
}

["/example.com/path/to/resource"] =
{
  path = "/example.com/path/to/resource",
}

["example.com/path/to/resource"] =
{
  path = "example.com/path/to/resource",
}

  You should try those with the Go URL parser you use and see what YOU get.

  -spc

From acdw at acdw.net  Tue Nov 17 22:28:27 2020
From: acdw at acdw.net (acdw)
Date: Tue, 17 Nov 2020 22:28:27 +0000
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117221041.GO19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
Message-ID: <fd3cd128-2cab-43ff-b60e-897da616d015@www.fastmail.com>

On 2020-11-17 (Tuesday) at 22:10, Sean Conner <sean at conman.org> wrote:

> 
> 		//example.com/path/to/resource
> 
> IS A VALID URI!  IT IS NOT A HACK!  What part of the ABNF do you not
> understand?
[snip]
>   Again,
> 
> 		//example.com/path/to/resource
> 
> IS NOT A HACK!
[snip]
>   -spc
>

Hear, hear!  I was only going to list the Regex implementation[1] at the end of the RFC as proof that this wasn't a hack, but I appreciate your thoroughness in explanation.

This is, in fact, why I brought it up (apparently, again, sorry about that) at all -- the current gemini spec is incompatible in this way with the URI spec.  Since a goal of gemini is stated as not reinventing the wheel (okay, citation needed, but I think it's pretty much the ~feeling~ around here), we should stick to the pre-existing spec as much as possible.  I liked the suggested solution from spc (the multiple ones, they're all fine, in fact!) for the update in the spec.

I sincerely hope that 99% of geminauts are using URLs as we've discussed here, and I just want the spec to reflect their correct usage.

[1]: https://tools.ietf.org/html/rfc3986#appendix-B

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From cowan at ccil.org  Tue Nov 17 22:45:50 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 17 Nov 2020 17:45:50 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117221041.GO19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
Message-ID: <CAD2gp_QaK+qvkph2ykywg7B_--Em51+kei2tgdSVmOQOn0txGA@mail.gmail.com>

On Tue, Nov 17, 2020 at 5:10 PM Sean Conner <sean at conman.org> wrote:

  The path parsing rules state a single slash.  Not '/'+, nor '/'*, but a
> single '/'.  The only place where more than a single slash is allowed PER
> THE @#%@#$@$ ABNF is just prior to the authority, which contains the
> hostname.  THE ONLY PLACE!
>

Correct.

> I will also draw your attention to the URI-reference rule, which is there
> for some reason, which allows both a full URI, or a RELATIVE URI, which
> means that
>
>                 //example.com/path/to/resource
>
> IS A VALID URI!  IT IS NOT A HACK!  What part of the ABNF do you not
> understand?
>

Nope.  It is a valid URI reference, because it is a valid relative
reference.  It is *not* a valid URI.

In what follows, I am going to assume that "URL" and "URI" are synonymous,
which they have been for 15 years since RFC 3986 was published.

> No, the spec allows both the full URI, and a relative URI as long as it
> starts with '//' (it has the authority section).  The wording in the spec
> is
> bad and should be changed to clarify it, but that's the current
> specification.
>

There are two cases:

1) In a Gemini-protocol request line (section 2), the second sentence says
that an absolute URL (that is, a URI without a fragment identifier) is
required.  The third sentence says that if the "scheme://" portion is
missing (in which case it is not a URI, much less an absolute URI), it
should be prefixed with "gemini://" and presumably reparsed.  That's
straightforward.

2) In a link line (section 5.4.2), we are told that there may be an
absolute or a relative URL.  There are no relative URIs, so we can only
interpret this as meaning a relative reference.  We are also told that if
the URL lacks a scheme (which is impossible: a URI always has a scheme)
then the scheme is "gemini".

Now suppose a link line in a resource that is available from "gemini://
example.com/public/this.gmi" has the form "foo/bar/baz.gmi".  We can
interpret this in one of two incompatible ways:

2a) a truncated version of "gemini://foo/bar/baz.gmi".  Note that "foo" is
a perfectly valid host name.

2b) a relative reference, in which case it resolves to "gemini://
example.com/public/foo/bar/baz.gmi".

So the spec is self-contradictory.  In my view interpretation 2a is bogus
and the sentence "If the URL does not include a scheme, a scheme of
gemini:// is implied" in section 5.4.2 should be removed.  What is more, I
would like to see the equivalent sentence "If the scheme of the URL is not
specified, a scheme of gemini:// is implied" removed as well.

> but that's what it is, other URI parsers that are more strict with
> > compliance to the RFC will refuse to parse a URI without scheme
> > present,
>
>   If it does, it's broken by design.  Again, see the ABNF above.
>

It is precisely the ABNF line in RFC 3986 section 3 that says a URI (as
opposed to a URI reference) has to begin with a scheme.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
It's the old, old story.  Droid meets droid.  Droid becomes chameleon.
Droid loses chameleon, chameleon becomes blob, droid gets blob back
again.  It's a classic tale.  --Kryten, Red Dwarf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201117/9818505a/attachment.htm>

From petite.abeille at gmail.com  Tue Nov 17 22:49:44 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 17 Nov 2020 23:49:44 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117221041.GO19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
Message-ID: <FB3D62AD-B9CA-4866-A167-5B81C6CDB715@gmail.com>



> On Nov 17, 2020, at 23:10, Sean Conner <sean at conman.org> wrote:
> 
> belaboring the inanimate equus

Ohhh... pig latin, my favorite! Oggingflay away eadday orsehay!

Quidquid latine dictum sit, altum sonatur!


From alex at nytpu.com  Tue Nov 17 23:07:08 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Tue, 17 Nov 2020 16:07:08 -0700
Subject: Scheme Section 2 quibble
Message-ID: <20201117230708.i26wwzuxuwau6hl6@GLaDOS>

I'm going to use a real-world example here because people seem to not
get why this may be a problem.

Let's say I want to start hosting the git repo for my utility
gemlog.sh[a] on gemini. I make a directory on my site, so the full url
would be `gemini://nytpu.com/gemlog.sh/`. Now, say I put a link in my
root index.gmi (`/`) linking to `gemlog.sh`[b]. This is a perfectly
valid link to a directory on my server, but this would instead be
interpreted as the url `gemini://gemlog.sh/` if you use the faulty
method of parsing. (`.sh` is a valid TLD[c] so it wouldn't work even if
you have a whitelist of tlds).


Now, there's a few options to prevent this from happening:

1) Ban periods in all file & directory names. You'd also have to ban it
in filenames, because what if I make the relative link to a file called
`command.com`? Requires large, breaking spec changes.

2) Instead of documents being served as-is and having clients parse
urls, instead force servers to rewrite all urls, checking if it is a
valid directory or not before serving. All clients only expect well-
formed, full urls, and all existing server implementations are in
violation. Requires large, breaking spec changes.

3) Require that links to directories must not be relative if they could
be confused as a uri host. This is an inconsistent, quick fix that is
very ambiguous, because one client may think it's a valid host while
others may not. It also puts the burden on the authors of documents,
because now they have to remember when relative links are allowed and
when they aren't, and test their documents on a variety of clients to
ensure that it is compatible with all their parsing methods. Requires
large, breaking spec changes.

4) Follow the carefully and clearly defined specification[d] that is
over 15 years old and is well-adopted by existing uri parsing libraries.
Requires minimal, non-breaking spec changes, purely for clarity.


I know which one I'd choose. Obviously option 1 is the only real option
here, the outlandish ones like option 4 just make no sense.

[a]: https://tildegit.org/nytpu/gemlog.sh
[b]: so the full line would read:
     `=> gemlog.sh a utility for managing gemlogs from the command line`
[c]: https://en.wikipedia.org/wiki/.sh
[d]: https://tools.ietf.org/html/rfc3986

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201117/be609ab7/attachment-0001.sig>

From linde.philip at gmail.com  Tue Nov 17 23:18:22 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 18 Nov 2020 00:18:22 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <CAD2gp_QaK+qvkph2ykywg7B_--Em51+kei2tgdSVmOQOn0txGA@mail.gmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home>
 <20201117221041.GO19536@brevard.conman.org>
 <CAD2gp_QaK+qvkph2ykywg7B_--Em51+kei2tgdSVmOQOn0txGA@mail.gmail.com>
Message-ID: <20201118001822.59cb0211f558cb1e76762787@gmail.com>

On Tue, 17 Nov 2020 17:45:50 -0500
John Cowan <cowan at ccil.org> wrote:

> In what follows, I am going to assume that "URL" and "URI" are synonymous,
> which they have been for 15 years since RFC 3986 was published.

That may not be an entirely uncontroversial assumption. URLs were
AFAIK last defined by the IETF in RFC 1808, where relative URLs were
first specified and the distinction became necessary. In RFC 1808, an
URL is either an absolute URL or a relative URL (analogous to
relative-ref). In that sense, an URL is rather analogous with
URI-reference of RFC 3986.

I completely agree on all other points, and the point above is only
further reason for clarification. What is and isn't an URL is a bit
loosey-goosey throughout, which is why RFC 3986 is welcome.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201118/9286d79b/attachment.sig>

From cowan at ccil.org  Tue Nov 17 23:23:31 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 17 Nov 2020 18:23:31 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117230708.i26wwzuxuwau6hl6@GLaDOS>
References: <20201117230708.i26wwzuxuwau6hl6@GLaDOS>
Message-ID: <CAD2gp_Qf7jVzaOx=GT+AaZUViWcE4JViU1JXvBhVzZvCt8ix5g@mail.gmail.com>

On Tue, Nov 17, 2020 at 6:07 PM Alex // nytpu <alex at nytpu.com> wrote:


> Let's say I want to start hosting the git repo for my utility
> gemlog.sh[a] on gemini. I make a directory on my site, so the full url
> would be `gemini://nytpu.com/gemlog.sh/` <http://nytpu.com/gemlog.sh/>.
> Now, say I put a link in my
> root index.gmi (`/`) linking to `gemlog.sh`[b]. This is a perfectly
> valid link to a directory on my server, but this would instead be
> interpreted as the url `gemini://gemlog.sh/` <http://gemlog.sh/> if you
> use the faulty
> method of parsing. (`.sh` is a valid TLD[c] so it wouldn't work even if
> you have a whitelist of tlds).
>

In any case, nothing says a hostname has to be absolute.  If your hostname
is "client.example.com" then you can refer to "server.example.com" as
simply "server".  The only way to tell if "server" is a meaningful host is
to ask the DNS, and the answer can change.

> 4) Follow the carefully and clearly defined specification[d] that is
> over 15 years old and is well-adopted by existing uri parsing libraries.
> Requires minimal, non-breaking spec changes, purely for clarity.
>

Requires a small breaking spec change to remove the sentence about
defaulting to "gemini://" in 5.4.2 and preferably in 2 as well.  But 5.4.2
is self-contradictory and has to be fixed.

My proposal is to rewrite section 2 to say this:

<URL> is an absolute URL according to RFC 3986, of maximum length 1024
bytes.

And to rewrite section 5.4.2 to say this:

<URL> is a URI reference according to RFC 3986.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201117/8bc74bd0/attachment.htm>

From linde.philip at gmail.com  Tue Nov 17 23:33:45 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 18 Nov 2020 00:33:45 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117230708.i26wwzuxuwau6hl6@GLaDOS>
References: <20201117230708.i26wwzuxuwau6hl6@GLaDOS>
Message-ID: <20201118003345.a2d33fe0f1dc90e7a3aee63e@gmail.com>

On Tue, 17 Nov 2020 16:07:08 -0700
Alex // nytpu <alex at nytpu.com> wrote:

> I'm going to use a real-world example here because people seem to not
> get why this may be a problem.
> 
> Let's say I want to start hosting the git repo for my utility
> gemlog.sh[a] on gemini. I make a directory on my site, so the full url
> would be `gemini://nytpu.com/gemlog.sh/`. Now, say I put a link in my
> root index.gmi (`/`) linking to `gemlog.sh`[b]. This is a perfectly
> valid link to a directory on my server, but this would instead be
> interpreted as the url `gemini://gemlog.sh/` if you use the faulty
> method of parsing. (`.sh` is a valid TLD[c] so it wouldn't work even if
> you have a whitelist of tlds).

I think that we all actually agree that this can't possibly work for
links. What Ali Fardan is suggesting is to allow suffix references only
in requests, where the ambiguity could be avoided for the simple reason
that the request must contain an authority.

I completely disagree that suffix references should be used anywhere,
but the suggestion is not quite so outlandish as to require any of
options 1-3. It should be avoided for the simple reason that it
precludes option 4.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201118/3a7d4b0d/attachment.sig>

From sean at conman.org  Tue Nov 17 23:46:21 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 17 Nov 2020 18:46:21 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <CAD2gp_Qf7jVzaOx=GT+AaZUViWcE4JViU1JXvBhVzZvCt8ix5g@mail.gmail.com>
References: <20201117230708.i26wwzuxuwau6hl6@GLaDOS>
 <CAD2gp_Qf7jVzaOx=GT+AaZUViWcE4JViU1JXvBhVzZvCt8ix5g@mail.gmail.com>
Message-ID: <20201117234621.GP19536@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> 
> Requires a small breaking spec change to remove the sentence about
> defaulting to "gemini://" in 5.4.2 and preferably in 2 as well.  But 5.4.2
> is self-contradictory and has to be fixed.
> 
> My proposal is to rewrite section 2 to say this:
> 
> <URL> is an absolute URL according to RFC 3986, of maximum length 1024
> bytes.
> 
> And to rewrite section 5.4.2 to say this:
> 
> <URL> is a URI reference according to RFC 3986.

  I've gone over the path month of logs [1] on my Gemini server and pulled
some stats.

	Total number of requests:		103,422
	Total number of schemeless requests:	    275

And of the schemeless requests:

	client #1	  2 requests
	client #2	  3 requests
	client #3	270 requests

  Given the relative rarity of such requests (0.2% of all requests) and the
number of clients requesting schemeless requests (between 0.3% to 8% [2]) I
would agree with this proposal.  A Gemini request is an absolute URL (per
RFC-3986).

  -spc

[1]	It's all I keep

[2]	Okay, on the Gemini software page [3], I count 37 known clients. 
	There are some others not listed, like CAPCOM, Spacewalk and GUS,
	but even excluding those, 3 out of 37 is 8%.  And assuming that all
	1,187 unique IP addresses were using a unique client, then the
	percentage falls to 0.3%.  The truth is somewhere in between.

	Also, my server probably gets hit by *every* client, as it serves up
	the Gemini Client Torture test.

[3]	https://portal.mozz.us/gemini/gemini.circumlunar.space/software/

From waweic at activ.ism.rocks  Wed Nov 18 00:51:23 2020
From: waweic at activ.ism.rocks (Waweic)
Date: Wed, 18 Nov 2020 01:51:23 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201117221041.GO19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
Message-ID: <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>

Sean Connor wrote:

> ? The path parsing rules state a single slash.? Not '/'+, nor '/'*,
> but a
> single '/'.? The only place where more than a single slash is allowed
> PER
> THE @#%@#$@$ ABNF is just prior to the authority, which contains the
> hostname.? THE ONLY PLACE!?

I am currently working on a bug in lagrange concerning this question.
It appeared to me, that multiple consecutive slashes might also be
allowed in the query, according to the ABNF, but I may be very wrong
there.


From sean at conman.org  Wed Nov 18 02:02:09 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 17 Nov 2020 21:02:09 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
Message-ID: <20201118020209.GQ19536@brevard.conman.org>

It was thus said that the Great Waweic once stated:
> Sean Connor wrote:
> 
> > ? The path parsing rules state a single slash.? Not '/'+, nor '/'*,
> > but a
> > single '/'.? The only place where more than a single slash is allowed
> > PER
> > THE @#%@#$@$ ABNF is just prior to the authority, which contains the
> > hostname.? THE ONLY PLACE!?
> 
> I am currently working on a bug in lagrange concerning this question.
> It appeared to me, that multiple consecutive slashes might also be
> allowed in the query, according to the ABNF, but I may be very wrong
> there.

  In the query section, yes, it should be.  In the path section, it should
be disallowed.  Unfortunately, I checked the ABNF in RFC-3986 and it does
appear to allow double slashes in the path section.  The rules in question:

   path-abempty  = *( "/" segment )
   path-absolute = "/" [ segment-nz *( "/" segment ) ]
   path-noscheme = segment-nz-nc *( "/" segment )
   path-rootless = segment-nz *( "/" segment )

   segment       = *pchar

  A segment can be 0 or more characters, so per the spec, you could end up
with muliple slashes, and the URL parsing library I use, written against the
ABNF of RFC-3986, does in fact, accept it:

	["path//to//resource"] =
	{
	  path = "path//to//resource",
	}

  There's nothing in the errata [1] about this, but it seems like it should
be fixed.

  -spc

[1]	https://www.rfc-editor.org/errata_search.php?rfc=3986

From lazar.michael22 at gmail.com  Wed Nov 18 03:30:31 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 17 Nov 2020 22:30:31 -0500
Subject: [ANN] Gemini historical snapshot
Message-ID: <CAFTy05akj1EPt=j1AU0o4zqzu7pfX1S6KoaiFYEf8kwTGXY2wA@mail.gmail.com>

Greetings,

I'm happy to report that I have finished my effort to create a historical
snapshot of geminispace and upload it to the Internet Archive. I ended up
running three separate crawls in total, spaced over a few months. In total
there were 115,223 unique gemini URLs captured. Here are some general
statistics and download links:

Crawl           | September  | October    | November
---             | ---        | ---        | ---
Date            | 2020-09-24 | 2020-10-31 | 2020-11-07
Size            | 9.3 GB     | 12.9 GB    | 13.5 GB
Domains seen    | 283        | 276        | 314
Total Responses | 51,995     | 71,632     | 65,347
2x Responses    | 43,425     | 61,771     | 56,680

https://archive.org/details/mozz-gemini-crawl-2020-1
https://archive.org/details/mozz-gemini-crawl-2020-2
https://archive.org/details/mozz-gemini-crawl-2020-3

More information on the crawls can be found here:

gemini://mozz.us/archive/

The crawling software and related tools can be found here:

https://github.com/michael-lazar/mozz-archiver

I am also temporarily hosting a mirror of this snapshot on my gemini server.
It works using proxy URLs (which I thought was a neat idea). You can send any
request for a gemini URL to mozz.us:1966, and the server will attempt to
retrieve that URL from the snapshot.

Example using gemget:

$ gemget --proxy mozz.us:1966 -o - gemini://gemini.circumlunar.space/capcom/

Best,
Michael

From colecmac at protonmail.com  Wed Nov 18 04:29:13 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 18 Nov 2020 04:29:13 +0000
Subject: [ANN] Gemini historical snapshot
In-Reply-To: <CAFTy05akj1EPt=j1AU0o4zqzu7pfX1S6KoaiFYEf8kwTGXY2wA@mail.gmail.com>
References: <CAFTy05akj1EPt=j1AU0o4zqzu7pfX1S6KoaiFYEf8kwTGXY2wA@mail.gmail.com>
Message-ID: <VpNmoRWPimUjEyvbU28CURrLtKup9JQoVJDNfvBHk1k5Dv2TdYf8beXUmIH-4pT82rNO8ROTmrw4yRvpytn-hOsPAnfR1_fOC7iE2ydP2kA=@protonmail.com>

This is amazing! As an amateur archivist, I really appreciate this.
I predict geminispace will only grow, and this will be more and more
valuable as time goes on. Will be seeding all three :)

The more I look into this, the more pleased I am. Thanks for doing it
so well.

* Doing multiple crawls
* Uploading to the Internet Archive
* Making the archiving software reproducible and open source
* Writing a detailed description on IA
* Using WARC (first gemini usage afaik)

The proxy server is also a really cool idea, what a cool usage of proxying.
And thanks for the gemget shoutout!

Cheers,
makeworld

From linde.philip at gmail.com  Wed Nov 18 07:33:01 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 18 Nov 2020 08:33:01 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201118020209.GQ19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home>
 <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
Message-ID: <20201118083301.240968d3c2694df5168a196b@gmail.com>

On Tue, 17 Nov 2020 21:02:09 -0500
Sean Conner <sean at conman.org> wrote:

>   There's nothing in the errata [1] about this, but it seems like it should
> be fixed.

Nothing needs to be fixed. Zero length path segments are allowed in
some circumstances, but they are never allowed in a circumstance where
they could cause ambiguities. For this purpose, there are multiple
definitions of path segments, with -nz (non-empty) and -nz-nc
(non-empty, no colon) suffixes"

   path-abempty  = *( "/" segment )
   path-absolute = "/" [ segment-nz *( "/" segment ) ]
   path-noscheme = segment-nz-nc *( "/" segment )
   path-rootless = segment-nz *( "/" segment )
   path-empty    = 0<pchar>

You can see that relative-ref is designed in such a way as to disallow
any ambiguity, by only allowing path-absolute (which starts with a
single slash and a non-empty segment), path-noscheme (which starts with
a non-empty segment not containing a colon) or path-empty (which is
zero characters):

      relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

      relative-part = "//" authority path-abempty
                    / path-absolute
                    / path-noscheme
                    / path-empty

The "path" definition itself can not be distinguished from a
relative-ref or relative-part, but the path definition is never used by
any other definition in the document. If parsing a relative-ref or
URI-reference, this is never a problem.

--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201118/e4b084e7/attachment.sig>

From smallick.dev at gmail.com  Wed Nov 18 07:52:36 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Wed, 18 Nov 2020 13:22:36 +0530
Subject: Scheme Section 2 quibble
In-Reply-To: <20201118083301.240968d3c2694df5168a196b@gmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
Message-ID: <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>

While you are discussing about the specs, please have a look at how
the servers are currently responding to the edge cases.

http://ix.io/2EyQ

Request -> Response (first line only)
The list of known servers from gemini://gus.guru/known-hosts : removed
all non existent servers and *.flounder.online
Test yourself: http://ix.io/2Etk

And if you can, forgive my madness.

From sean at conman.org  Wed Nov 18 08:42:57 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 18 Nov 2020 03:42:57 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
Message-ID: <20201118084257.GR19536@brevard.conman.org>

It was thus said that the Great Sudipto Mallick once stated:
> While you are discussing about the specs, please have a look at how
> the servers are currently responding to the edge cases.
> 
> http://ix.io/2EyQ
> 
> Request -> Response (first line only)
> The list of known servers from gemini://gus.guru/known-hosts : removed
> all non existent servers and *.flounder.online
> Test yourself: http://ix.io/2Etk
> 
> And if you can, forgive my madness.

  Thank you for running this and reporting the results.  I can describe why
you got the results for my server: gemini.conman.org

	gemini.conman.org -> 59 Bad Request
	gemini.conman.org/ -> 59 Bad Request
	gemini.conman.org// -> 59 Bad Request

  These are bad because there's no scheme nor authority (missing a '//') and
thus, these are marked as a bad request.

	//gemini.conman.org -> 20 text/gemini
	//gemini.conman.org/ -> 20 text/gemini
	//gemini.conman.org// -> 59 Bad Request

  These are missing the scheme, but have an authority section [1].  The URL
parser I use adds a '/' for the path if the path does not exist.  That's why
my server does not do a 31-redirect with a missing '/' at the end.  The
double slash at the end is being checked by a modified path-abempty rule. 
The ABNF from the RFC is:

	   path-abempty  = *( "/" segment )

while the URL parser I'm using is doing:

	   path_abempty <- {~ ( '/' segment)+ ~}
                        /  '' -> '/'

  The parsing code is in LPEG [2] and is equivalent to

	   path-abempty = +( "/" segment)
			/ 0<pchar> # and return a '/'

and was written that way to fix an issue inherent with the ABNF of
"0<pchar>" and how parsing works with LPEG.  I can go into details of LPEG
if anyone is interested, but suffice to say, the path_abempty of LPEG is
different from the ABNF of the RFC for a good reason, and this is why the
trailing '//' from the authority section is not parsing.

	gemini://gemini.conman.org -> 20 text/gemini
	gemini://gemini.conman.org/ -> 20 text/gemini
	gemini://gemini.conman.org// -> 59 Bad Request

  A more normal request, and the same explanation from above.  No surprises
for my server (at least, to me).  A more interesting response is from
blekksprut.net and cadence.moe:

	blekksprut.net -> 20 text/gemini
	blekksprut.net/ -> 20 text/gemini
	blekksprut.net// -> 20 text/gemini
	//blekksprut.net -> 51 not found
	//blekksprut.net/ -> 51 not found
	//blekksprut.net// -> 51 not found
	gemini://blekksprut.net -> 20 text/gemini
	gemini://blekksprut.net/ -> 20 text/gemini
	gemini://blekksprut.net// -> 20 text/gemini

	cadence.moe -> 20 text/gemini; charset=utf-8; lang=en
	cadence.moe/ -> 20 text/gemini; charset=utf-8; lang=en
	cadence.moe// -> 20 text/gemini; charset=utf-8; lang=en
	//cadence.moe -> 50 Bliz server: Not found: //cadence.moe
	//cadence.moe/ -> 50 Bliz server: Not found: //cadence.moe/
	//cadence.moe// -> 50 Bliz server: Not found: //cadence.moe//
	gemini://cadence.moe -> 20 text/gemini; charset=utf-8; lang=en
	gemini://cadence.moe/ -> 20 text/gemini; charset=utf-8; lang=en
	gemini://cadence.moe// -> 20 text/gemini; charset=utf-8; lang=en

  These results probably stem from a same issue, but possibly different
servers.  Just going quickly through the results, if there was no problem
with the first grouping (just the domain name), it seems the servers *have* an
issue with the second grouping (leading '//').  Odd.

  Again, thanks for this.

  -spc

[1]	I've been debating if I should mark a missing scheme as a "bad
	request" as I've come around to support that a Gemini server should
	ONLY accept an absolute URL.  I haven't ... yet.

[2]	Lua Parsing Expression Grammar

From bie at 202x.moe  Wed Nov 18 09:09:37 2020
From: bie at 202x.moe (bie)
Date: Wed, 18 Nov 2020 18:09:37 +0900
Subject: Scheme Section 2 quibble
In-Reply-To: <20201118084257.GR19536@brevard.conman.org>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home>
 <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
 <20201118084257.GR19536@brevard.conman.org>
Message-ID: <20201118090937.GA42221@202x.moe>

On Wed, Nov 18, 2020 at 03:42:57AM -0500, Sean Conner wrote:

>   A more normal request, and the same explanation from above.  No surprises
> for my server (at least, to me).  A more interesting response is from
> blekksprut.net and cadence.moe:
>
> [...] 
>
>   These results probably stem from a same issue, but possibly different
> servers.

They're definitely different servers - blekksprut.net is running on my
own code...
The results were a little surprising, so I'm going to be doing some
bugfixing again tonight ;)

>   Again, thanks for this.

Seconding the thanks, this is great stuff!

bie

From benulo at systemli.org  Wed Nov 18 09:09:55 2020
From: benulo at systemli.org (Ben)
Date: Wed, 18 Nov 2020 12:39:55 +0330
Subject: =?UTF-8?B?UmU6IFtBTk5dIETKksmbbcmqbmksIGEgZ2VtaW5pIHNlcnZlcg==?=
In-Reply-To: <87ft58f0s2.fsf@rwv.io>
References: <87ft58f0s2.fsf@rwv.io>
Message-ID: <4a971851-bcb8-c022-5c7c-5ddf039ddde9@systemli.org>

Sounds very nice!

-- 
gemini://kwiecien.us/

From smallick.dev at gmail.com  Wed Nov 18 15:29:53 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Wed, 18 Nov 2020 20:59:53 +0530
Subject: Scheme Section 2 quibble
In-Reply-To: <20201118090937.GA42221@202x.moe>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
 <20201118084257.GR19536@brevard.conman.org> <20201118090937.GA42221@202x.moe>
Message-ID: <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>

Statistics from the data I collected:

request
    response code -> percentange
    :
    :

"$host"
    59 -> 55%
    53 -> 22%
    20 -> 4.8%

"$host/"
    59 -> 55%
    53 -> 22%
    51 -> 7.7%
    20 -> 6.8%

"$host//"
    59 -> 55%
    53 -> 22%
    51 -> 7.7%
    20 -> 6.4%

"//$host"
    31 -> 55% (!)
    20 -> 29%
    59 -> 12%
    51 -> 7.7%

"//$host/"
    20 -> 67%
    59 -> 12%
    51 -> 7%
    53 -> 2%
    50 -> 2%

"//$host/"
    20 -> 61%
    59 -> 15%
    51 -> 10%

"gemini://$host"
    31 -> 57.6% (!!)
    20 -> 34%
    30 -> 1.6%

"gemini://$host/"
    20 -> 93%

"gemini://$host//"
    20 -> 84%
    51 -> 6%
out of http://ix.io/2EzQ

From smallick.dev at gmail.com  Wed Nov 18 15:35:31 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Wed, 18 Nov 2020 21:05:31 +0530
Subject: Scheme Section 2 quibble
In-Reply-To: <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
 <20201118084257.GR19536@brevard.conman.org> <20201118090937.GA42221@202x.moe>
 <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>
Message-ID: <CAFaUHvKA_Yf0imr0LaY8pgOW-SuBkzYFnywe4+nL2h9md=4Q+g@mail.gmail.com>

Clicked send button too fast...
the second "//$host/" should be "//$host//"

From linde.philip at gmail.com  Wed Nov 18 15:46:53 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 18 Nov 2020 16:46:53 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home>
 <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
 <20201118084257.GR19536@brevard.conman.org>
 <20201118090937.GA42221@202x.moe>
 <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>
Message-ID: <20201118164653.d9c882713471774c2119ee99@gmail.com>

On Wed, 18 Nov 2020 20:59:53 +0530
Sudipto Mallick <smallick.dev at gmail.com> wrote:

Very interesting and good summary, Sudipto.

> "//$host"
>     31 -> 55% (!)
>     20 -> 29%
>     59 -> 12%
>     51 -> 7.7%

There is probably some overlap here with hosts that generally serve
redirects for empty paths.

> "gemini://$host"
>     31 -> 57.6% (!!)
>     20 -> 34%
>     30 -> 1.6%
> 
> "gemini://$host/"
>     20 -> 93%

This is alarming IMO. I have expressed it before in the mailing list,
but because of the normalization rules of RFC 3986, an empty path is
*equivalent* to the path "/". Serving a 3x redirect on one and a page on
the other is wrong.

In this case it's likely rather benign that they serve different
content, because I assume that a client will arrive at the same resource
after following a redirect, but it has to be understood that a client
might make these generalizations as well, in which case that client
can't access the resource that's served when requesting an empty path.

It would be interesting to figure out which server software is the
culprit.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201118/d05d497b/attachment.sig>

From me at rwv.io  Wed Nov 18 16:16:36 2020
From: me at rwv.io (Remco)
Date: Wed, 18 Nov 2020 17:16:36 +0100
Subject: Scheme Section 2 quibble
In-Reply-To: <20201118164653.d9c882713471774c2119ee99@gmail.com>
References: <1af8862a-24db-413d-aa4a-ffee87ac9a33@www.fastmail.com>
 <20201117044745.7ce92cf7@home>
 <20201117101952.968dfa718b19a2dfaaff7d86@gmail.com>
 <20201117174254.1d75318f@home> <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
 <20201118084257.GR19536@brevard.conman.org>
 <20201118090937.GA42221@202x.moe>
 <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>
 <20201118164653.d9c882713471774c2119ee99@gmail.com>
Message-ID: <871rgqfxnf.fsf@rwv.io>

2020/11/18 16:46, Philip Linde:

>> "gemini://$host"
>>     31 -> 57.6% (!!)
>>     20 -> 34%
>>     30 -> 1.6%
>>
>> "gemini://$host/"
>>     20 -> 93%
>
> This is alarming IMO. I have expressed it before in the mailing list,
> but because of the normalization rules of RFC 3986, an empty path is
> *equivalent* to the path "/". Serving a 3x redirect on one and a page on
> the other is wrong.
>
> In this case it's likely rather benign that they serve different
> content, because I assume that a client will arrive at the same resource
> after following a redirect, but it has to be understood that a client
> might make these generalizations as well, in which case that client
> can't access the resource that's served when requesting an empty path.
>
> It would be interesting to figure out which server software is the
> culprit.

If you want to point fingers:

  https://github.com/michael-lazar/gemini-diagnostics/blob/master/gemini-diagnostics#L440

That's what I based my implementation on and I suspect many others did
so too.

R.

From sean at conman.org  Wed Nov 18 21:09:39 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 18 Nov 2020 16:09:39 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <871rgqfxnf.fsf@rwv.io>
References: <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
 <20201118084257.GR19536@brevard.conman.org> <20201118090937.GA42221@202x.moe>
 <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>
 <20201118164653.d9c882713471774c2119ee99@gmail.com> <871rgqfxnf.fsf@rwv.io>
Message-ID: <20201118210938.GS19536@brevard.conman.org>

It was thus said that the Great Remco once stated:
> 2020/11/18 16:46, Philip Linde:
> 
> >> "gemini://$host"
> >>     31 -> 57.6% (!!)
> >>     20 -> 34%
> >>     30 -> 1.6%
> >>
> >> "gemini://$host/"
> >>     20 -> 93%
> >
> > This is alarming IMO. I have expressed it before in the mailing list,
> > but because of the normalization rules of RFC 3986, an empty path is
> > *equivalent* to the path "/". Serving a 3x redirect on one and a page on
> > the other is wrong.
> >
> > In this case it's likely rather benign that they serve different
> > content, because I assume that a client will arrive at the same resource
> > after following a redirect, but it has to be understood that a client
> > might make these generalizations as well, in which case that client
> > can't access the resource that's served when requesting an empty path.
> >
> > It would be interesting to figure out which server software is the
> > culprit.
> 
> If you want to point fingers:
> 
>   https://github.com/michael-lazar/gemini-diagnostics/blob/master/gemini-diagnostics#L440
> 
> That's what I based my implementation on and I suspect many others did
> so too.

  The test isn't *wrong* per se, it's just testing at the wrong level.  My
server will return:

	gemini://gemini.conman.org	-> 20
	gemini://gemini.conman.org/	-> 20

but

	gemini://gemini.conman.org/test	-> 31 gemini://gemini.conman.org/test/

  which is what that test is testing.  

  -spc

From emilis at emilis.net  Thu Nov 19 01:12:42 2020
From: emilis at emilis.net (Emilis)
Date: Thu, 19 Nov 2020 03:12:42 +0200
Subject: Again on feeds in Gemini format
Message-ID: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>

Hi,

I am developing a generator and a parser for the 
frequently-discussed-but-never-agreed-on feeds in Gemini format.

I would like to share my code, see your similar code and later discuss 
(over IRC?) what format could work best for our use cases.

My code:

Gemlog generator: gemini://tilde.team/~emilis/Makefile
Aggregator: https://tildegit.org/emilis/gmi-feed-aggregator


The motivation (taken from this post: 
gemini://tilde.team/~emilis/2020/11/19-on-feeds-in-gemini-format.gmi ):


I looked through the discussions on Gemini list, read the posts by ~ew0k 
and Drew DeVault.

I wholeheartedly disagree with the opinion that Atom/RSS (or JSON feeds) 
should be enough for everybody.

The point is - some of us are not thinking about running feed 
generators, parsers and aggregators on developer laptops, workstations, 
modern servers we own, etc..

We are thinking about running these programs on computers where we have 
limited permissions, OpenWRT routers, experimental SBCs, old netbooks 
and rooted phones that cannot be updated to any recent distros, etc..

In these situations even Python (widespread as it is) may not be 
available, may be too resource-hungry or may not have the option to be 
updated or extended with libraries.

What we need is the ability to process feeds with a bare minimum of 
tools (e.g. a POSIX shell, BusyBox, etc.). Parsing XML and JSON is not 
feasible in these situations.

Therefore we want a plain Gemini feed format. Seeing how easy it is to 
generate and parse Gemini files with just plain shell script, makes us 
want it badly. We also have hopes it would have more uses than just 
gemlogging.

## What should we do about it

I think we should start by just building the tools for ourselves and 
sharing them (probably on the Gemini list). After we have a few 
implementations, we can discuss on the formal spec between the developers.

The main criteria should probably be the amount of effort and knowledge 
needed to implement a parser.

What I found in the discussions is that this may be the lowest common 
denominator at the moment:

```
=> URL ISO-TIMESTAMP TITLE-MAYBE-WITH-AUTHOR
```

We can start from this and agree that our parsers will rely on just 
these lines and ignore the rest for the moment. It could be done by this 
command:

```
grep -E '^=>\s*gemini://[^ ]+ 
[0-9]{4}-[0-9]{2}-[0-9]{2}(T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|\+[0-9]{1,2}:[0-9]{2}))?\s+.*$'
```


Looking forward to seeing your implementations. Please share them!


--
Emilis Dambauskas
gemini://tilde.team/~emilis/


From acdw at acdw.net  Thu Nov 19 02:45:44 2020
From: acdw at acdw.net (acdw (Case))
Date: Wed, 18 Nov 2020 20:45:44 -0600
Subject: Again on feeds in Gemini format
In-Reply-To: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
References: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
Message-ID: <3d747e3e-55ac-2803-1eca-25339c61e8b4@acdw.net>

On 11/18/20 7:12 PM, Emilis wrote:

> I wholeheartedly disagree with the opinion that Atom/RSS (or JSON feeds) 
> should be enough for everybody.
> 
> The point is - some of us are not thinking about running feed 
> generators, parsers and aggregators on developer laptops, workstations, 
> modern servers we own, etc..
> 
> We are thinking about running these programs on computers where we have 
> limited permissions, OpenWRT routers, experimental SBCs, old netbooks 
> and rooted phones that cannot be updated to any recent distros, etc..
> 
> In these situations even Python (widespread as it is) may not be 
> available, may be too resource-hungry or may not have the option to be 
> updated or extended with libraries.
> 
> What we need is the ability to process feeds with a bare minimum of 
> tools (e.g. a POSIX shell, BusyBox, etc.). Parsing XML and JSON is not 
> feasible in these situations.

Just as a proof of concept, at least generating Atom feeds using plain 
shell script (plus a little extra) is possible.  See my new project, 
gemshimfeed:

https://git.sr.ht/~acdw/gemshimfeed

It only depends on GNU find and stat, both of which can be replaced 
easily at run time.  Or hell, it's a shell script, you can edit it 
yourself :)

As far as parsing an Atom feed goes, that's a little tricker -- but I 
think gemshimfeed shows it's not hard to generate the feed.  I 
implemented this without even reading the spec, I think; I just read the 
Wikipedia article on the protocol.

-- 
~acdw (Case)
www.acdw.net | breadpunk.club/~breadw

From khuxkm at tilde.team  Thu Nov 19 04:12:54 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 19 Nov 2020 04:12:54 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <3d747e3e-55ac-2803-1eca-25339c61e8b4@acdw.net>
References: <3d747e3e-55ac-2803-1eca-25339c61e8b4@acdw.net>
 <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
Message-ID: <f285dbdaee3fa34aff8fb9dddbbfaf5d@tilde.team>

November 18, 2020 9:45 PM, "acdw (Case)" <acdw at acdw.net> wrote:

-quote of Emilis' email snipped-
> Just as a proof of concept, at least generating Atom feeds using plain shell script (plus a little
> extra) is possible. See my new project, gemshimfeed:
> 
> https://git.sr.ht/~acdw/gemshimfeed
> 
> It only depends on GNU find and stat, both of which can be replaced easily at run time. Or hell,
> it's a shell script, you can edit it yourself :)
> 
> As far as parsing an Atom feed goes, that's a little tricker -- but I think gemshimfeed shows it's
> not hard to generate the feed. I implemented this without even reading the spec, I think; I just
> read the Wikipedia article on the protocol.

Generating a feed was never the hard part. Make a shell script that's a) simple and b) parses an Atom feed correctly and then we'll talk about how easy parsing an Atom feed with the bare minimum of tools is.

Meanwhile, we don't need to talk about how easy parsing the plain gemtext feed is, because it's *that* easy. Of course it's easy to parse gemtext; the entire point of gemtext is to be easy to parse.

Just my two cents,
Robert "khuxkm" Miles

From colecmac at protonmail.com  Thu Nov 19 04:48:08 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 19 Nov 2020 04:48:08 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
References: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
Message-ID: <CixUL1WTpVhkJlUiJmtOM9PbHgDYwrXculASTOnznaSwHhEsus1pRDzWp1enD7KHp9btmlJzFHbpXOH6ZlFESj4AKmgNUljEKsYjiMDVXI4=@protonmail.com>

I still am not a fan of this format[1] and I think your rationale
here doesn't really make sense.

> running feed generators, parsers and aggregators

I will limit this to just parsers, as acdw has pointed out how easy
generation is. And the main difficulty of aggregating is just parsing.

> We are thinking about running these programs on computers where we have
> limited permissions, OpenWRT routers, experimental SBCs, old netbooks
> and rooted phones that cannot be updated to any recent distros, etc..

I don't see how any of these can't run C code that parses feeds. We must
remember, there is a lower bound to anything Gemini can use: it has to
be able to handle TLS. See 2.13 of the FAQ[2].

If your machine can do TLS, I don't see why it can't parse some XML.

> What we need is the ability to process feeds with a bare minimum of
> tools (e.g. a POSIX shell, BusyBox, etc.). Parsing XML and JSON is not
> feasible in these situations.

Not sure exactly what you're picturing, but can you not run compiled code
here? Do you mean the only code you can run is POSIX shell, maybe awk?
What real world environment is this?


1: gemini://makeworld.gq/gemlog/2020-11-16-re_aggregator_idea.gmi
2: gemini://gemini.circumlunar.space/docs/faq.gmi


makeworld

From rkumar at rkumar-dekstop  Thu Nov 19 07:08:10 2020
From: rkumar at rkumar-dekstop (Rohan Kumar)
Date: Wed, 18 Nov 2020 23:08:10 -0800
Subject: [ANN] seirdy.one live on Geminispace (+questions)
Message-ID: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>

Hello, Geminispace!

TLDR:
- Gemini capsule: gemini://seirdy.one
- Code: https://sr.ht/~seirdy/seirdy.one

I recently set up my weblog and gemlog. Both have mostly the same 
content, with some differences to better suit the medium (most 
differences come down to breaking up paragraphs to better accommodate 
Gemini's lack of inline links. A feature, not a bug.).

You can find my twinlogs at gemini://seirdy.one and https://seirdy.one.  
Is "twinlog" a word? I know I saw someone on here mention twinlogs. Well 
if it wasn't a word before, it is now.

I re-purposed my tilde (envs.net/~seirdy, available over both Gemini and 
the WWW) to serve as a staging area to dump rough drafts and ask for 
review before publishing.

I also set up a mailing list on Sourcehut (like, just now) to leave 
comments.  I've linked the mailing list at the bottom of my weblog 
entries, but I'm not sure if I should do the same for my gemlog. Do 
people generally prefer mailing lists or gemlog entries with backlinks?  
Or both?

One last question: Gemininauts (please oh please let that be a word) 
with twinlogs, how do you decide what to cross-post and what to keep 
{WWW,gemini,gopher}-exclusive? I'm leaning towards keeping my weblog 
more "professional" and my gemlog less filtered, leaving the shortest 
bits for the Fediverse. I'm curious to know how you all handle this.

I just started writing a series on resilient git-based project setup, 
inspired by Sourcehut and all the conversations since the youtube-dl 
takedown (and subsequent re-instatement).

Next up: set up a Gemini ring and web ring. Then maybe complete the 
trifecta with a Gopher hole.

Anyway, thanks for making Gemini awesome.


/Seirdy (gemini://seirdy.one)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 902 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201118/4e82a238/attachment.sig>

From sean at conman.org  Thu Nov 19 07:58:32 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 19 Nov 2020 02:58:32 -0500
Subject: [ANN] seirdy.one live on Geminispace (+questions)
In-Reply-To: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
References: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
Message-ID: <20201119075832.GV19536@brevard.conman.org>

It was thus said that the Great Rohan Kumar once stated:
> Hello, Geminispace!

  Hello!

> One last question: Gemininauts (please oh please let that be a word) 
> with twinlogs, how do you decide what to cross-post and what to keep 
> {WWW,gemini,gopher}-exclusive? I'm leaning towards keeping my weblog 
> more "professional" and my gemlog less filtered, leaving the shortest 
> bits for the Fediverse. I'm curious to know how you all handle this.

  Anything I post to the web [1] is also mirrored via gopher [2] and Gemini
[3].  It also has the effect of dumping twenty years of content into gopher
and Gemini.

  -spc

[1]	http://boston.conman.org/

[2]	gopher://gopher.conman.org/1Phlog:

[3]	gemini://gemini.conman.org/boston/


From op at omarpolo.com  Thu Nov 19 08:35:41 2020
From: op at omarpolo.com (Omar Polo)
Date: Thu, 19 Nov 2020 09:35:41 +0100
Subject: [ANN] seirdy.one live on Geminispace (+questions)
In-Reply-To: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
References: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
Message-ID: <87lfexvj4y.fsf@omarpolo.com>


Rohan Kumar <rkumar at rkumar-dekstop> writes:

> Hello, Geminispace!

Yo,

welcome to gemini!

>
> [?]
>
> One last question: Gemininauts (please oh please let that be a word)
> with twinlogs, how do you decide what to cross-post and what to keep
> {WWW,gemini,gopher}-exclusive? I'm leaning towards keeping my weblog
> more "professional" and my gemlog less filtered, leaving the shortest
> bits for the Fediverse. I'm curious to know how you all handle this.

I?m serving the exact same content on both the HTTP and gemini version
(and, when I?ll eventually start serving the site under gopher I?ll
serve the exact same content there), but I see why one would like to
differentiate the content.  In my case, I have a clojure script to
generate the sites and a edn file (think of it like a JSON if you
prefer) with a list of posts and pages, I think I can add a
:gemini-only? or :http-only? key to each post to decide where to post
to.

I see that you maintain two different version of each post, one in
markdown and one in gemtext and, if that?s fine for you, cool.  I?m too
lazy to maintain two different version of the same content, so I?m
writing all the ?new? entries in text/gemini and converting them to HTML
for WWW consumption.

I?m happy with the replacement of markdown with gemtext, in my use case
at least.  Before, I always had to double ? or triple ? check the posts
before publishing in a web browser to ensure that what I wrote was
exactly what the markdown parser thought (I cannot remember the correct
syntax for images/links and I always forget to put an empty line before
the lists, for instance).  With gemtext I can write and publish directly
from my editor, and I?m confident that both the gemini and the WWW
version are OK.  Another thing is the lack of inline formatting
(emphasis, code, etc).  At first I found it limiting, but after I while
I got used to, and now I can see that I was exaggerating with the
formatting.  The entries are more clear now, I think.

The result isn?t bad, the ?one link per line? can still be weird at
times, but with a bit of CSS it?s too bad, and my converter has a
heuristic: link to *(png|jpg) gets converted to inline images (I?m
serving less than 10 images, and all from my domain, so it works for
me).

> I just started writing a series on resilient git-based project setup,
> inspired by Sourcehut and all the conversations since the youtube-dl
> takedown (and subsequent re-instatement).

looking forward to it ;)

> Next up: set up a Gemini ring and web ring. Then maybe complete the
> trifecta with a Gopher hole.

it?s also on my todo-list

> Anyway, thanks for making Gemini awesome.
>
>
> /Seirdy (gemini://seirdy.one)

From op at omarpolo.com  Thu Nov 19 10:04:23 2020
From: op at omarpolo.com (Omar Polo)
Date: Thu, 19 Nov 2020 11:04:23 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
References: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
Message-ID: <87y2ixoe6w.fsf@omarpolo.com>


Emilis <emilis at emilis.net> writes:

> Hi,
>
> I am developing a generator and a parser for the
> frequently-discussed-but-never-agreed-on feeds in Gemini format.
>
> I would like to share my code, see your similar code and later discuss
> (over IRC?) what format could work best for our use cases.
>
> My code:
>
> Gemlog generator: gemini://tilde.team/~emilis/Makefile
> Aggregator: https://tildegit.org/emilis/gmi-feed-aggregator
>
>
> The motivation (taken from this post:
> gemini://tilde.team/~emilis/2020/11/19-on-feeds-in-gemini-format.gmi
> ):
>
>
> I looked through the discussions on Gemini list, read the posts by
> ~ew0k and Drew DeVault.
>
> I wholeheartedly disagree with the opinion that Atom/RSS (or JSON
> feeds) should be enough for everybody.
>
> The point is - some of us are not thinking about running feed
> generators, parsers and aggregators on developer laptops,
> workstations, modern servers we own, etc..
>
> We are thinking about running these programs on computers where we
> have limited permissions, OpenWRT routers, experimental SBCs, old
> netbooks and rooted phones that cannot be updated to any recent
> distros, etc..
>
> In these situations even Python (widespread as it is) may not be
> available, may be too resource-hungry or may not have the option to be
> updated or extended with libraries.
>
> What we need is the ability to process feeds with a bare minimum of
> tools (e.g. a POSIX shell, BusyBox, etc.). Parsing XML and JSON is not
> feasible in these situations.

With all the due respect, this is a bullshit.  Leaving aside that gemini
requires TLS by the spec, even if you don?t have root privileges on a
machine, there is a C compiler on it (how you?re gonna build a shell
without one?), and with that you can build a parser.  (I once wrote a
parser with a friend: a couple of hours of fun pair programming and we
had a JSON parser that was able to parse json objects over a socket,
without blocking etc, and was like ~200-300 lines of c code? ? ok, it
wasn?t 100% complete and spec compliant, but you get the idea).

anyway?

> Therefore we want a plain Gemini feed format. Seeing how easy it is to
> generate and parse Gemini files with just plain shell script, makes us
> want it badly. We also have hopes it would have more uses than just
> gemlogging.

I really like the idea!  A plain (but structured) text/gemini file would
be better IMHO.  It fits the goal of the protocol well: it?s simple,
effective, usable ?as it is? without special client support, easy to
generate (and consume) by humans etc?

> ## What should we do about it
>
> I think we should start by just building the tools for ourselves and
> sharing them (probably on the Gemini list). After we have a few
> implementations, we can discuss on the formal spec between the developers.

I?ve just adapted my static site generator to generate a gemini feed.
The commit for it was just ?3 files changed, 26 insertions, 5
deletions?, as git says.  It?s hosted here

=> gemini://gemini.omarpolo.com/rss.gmi

> The main criteria should probably be the amount of effort and
> knowledge needed to implement a parser.
>
> What I found in the discussions is that this may be the lowest common
> denominator at the moment:
>
> ```
> => URL ISO-TIMESTAMP TITLE-MAYBE-WITH-AUTHOR
> ```
>
> We can start from this and agree that our parsers will rely on just
> these lines and ignore the rest for the moment. It could be done by
> this command:

ignoring anything besides the links can be a good idea.  For instance,
in my feed I?ve included a title and a quote before the list of feeds:
this can improve the human consumption, but can also let advance clients
to improve the UI: for instance, they could (optionally) extract the
title of the page (the first ?#? title) and use it as a prefix for the
titles, or improve the search, or ?

> ```
> grep -E '^=>\s*gemini://[^ ]+
> [0-9]{4}-[0-9]{2}-[0-9]{2}(T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|\+[0-9]{1,2}:[0-9]{2}))?\s+.*$'
> ```
>
>
> Looking forward to seeing your implementations. Please share them!

From petite.abeille at gmail.com  Thu Nov 19 10:22:55 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 19 Nov 2020 11:22:55 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
References: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
Message-ID: <A36F13EE-1E4C-446D-A388-BB0B3B57EBFA@gmail.com>



> On Nov 19, 2020, at 02:12, Emilis <emilis at emilis.net> wrote:
> 
> What we need is the ability to process feeds with a bare minimum of tools (e.g. a POSIX shell, BusyBox, etc.). Parsing XML and JSON is not feasible in these situations.

xmllint & xml2 & jq & etc would do just fine in such context.

[1] http://xmlsoft.org/xmllint.html
[2] https://command-not-found.com/2xml
[3] https://stedolan.github.io/jq/


From luke at marmaladefoo.com  Thu Nov 19 12:19:48 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 19 Nov 2020 12:19:48 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
References: <6cf7601b-4592-d77a-c57a-272ec15730fc@emilis.net>
Message-ID: <5FB662E4.8050506@marmaladefoo.com>


On 19-Nov-2020 01:12, Emilis wrote:
> I wholeheartedly disagree with the opinion that Atom/RSS (or JSON 
> feeds) should be enough for everybody.
>
> The point is - some of us are not thinking about running feed 
> generators, parsers and aggregators on developer laptops, 
> workstations, modern servers we own, etc..
>
> We are thinking about running these programs on computers where we 
> have limited permissions, OpenWRT routers, experimental SBCs, old 
> netbooks and rooted phones that cannot be updated to any recent 
> distros, etc..
>
> In these situations even Python (widespread as it is) may not be 
> available, may be too resource-hungry or may not have the option to be 
> updated or extended with libraries.
>
> What we need is the ability to process feeds with a bare minimum of 
> tools (e.g. a POSIX shell, BusyBox, etc.). Parsing XML and JSON is not 
> feasible in these situations.
>
> Therefore we want a plain Gemini feed format. Seeing how easy it is to 
> generate and parse Gemini files with just plain shell script, makes us 
> want it badly. We also have hopes it would have more uses than just 
> gemlogging.

I see no harm in using Atom as a machine readable format, but from my 
point of view the main downside is expecting end users to author it, or 
have the skills to run some command line application to generate it. 
Probably fine for early adopters, but not so good for "normal" users.

Anyway a while back, I wrote a CGI script that emits Atom by parsing 
plain gmi feed listing. Details are here:

gemini://gemini.marmaladefoo.com/blog/2-Jul-2020_GMI_based_feed_generator.gmi

The parser is in Rebol, but parsing GMI is easy enough in most languages.

If we use raw GMI for feeds, one difficulty perhaps will be how the 
feeds can be discovered, particularly if they have to match some 
specification. But from an end user point of view, GMI is much nicer 
than XML for all the reasons we understand, so I think it is better way 
for authors to express their feed and can be used to generate the XML 
for automated feed clients that need it.

  - Luke

From khuxkm at tilde.team  Thu Nov 19 12:50:02 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 19 Nov 2020 12:50:02 +0000
Subject: [ANN] seirdy.one live on Geminispace (+questions)
In-Reply-To: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
References: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
Message-ID: <a88000c74d9941cdc18fa00960222d55@tilde.team>

November 19, 2020 2:08 AM, "Rohan Kumar" <rkumar at rkumar-dekstop> wrote:

> Hello, Geminispace!
> 
> TLDR:
> - Gemini capsule: gemini://seirdy.one
> - Code: https://sr.ht/~seirdy/seirdy.one
> 
> I recently set up my weblog and gemlog. Both have mostly the same 
> content, with some differences to better suit the medium (most 
> differences come down to breaking up paragraphs to better accommodate 
> Gemini's lack of inline links. A feature, not a bug.).
> 
> You can find my twinlogs at gemini://seirdy.one and https://seirdy.one. 
> Is "twinlog" a word? I know I saw someone on here mention twinlogs. Well 
> if it wasn't a word before, it is now.

I second the addition of "twinlog" to the lexicon.

> I re-purposed my tilde (envs.net/~seirdy, available over both Gemini and 
> the WWW) to serve as a staging area to dump rough drafts and ask for 
> review before publishing.

Ooh, good idea!

> I also set up a mailing list on Sourcehut (like, just now) to leave 
> comments. I've linked the mailing list at the bottom of my weblog 
> entries, but I'm not sure if I should do the same for my gemlog. Do 
> people generally prefer mailing lists or gemlog entries with backlinks? 
> Or both?

That's pretty cool. I don't mind either way.

> One last question: Gemininauts (please oh please let that be a word) 
> with twinlogs, how do you decide what to cross-post and what to keep 
> {WWW,gemini,gopher}-exclusive? I'm leaning towards keeping my weblog 
> more "professional" and my gemlog less filtered, leaving the shortest 
> bits for the Fediverse. I'm curious to know how you all handle this.

Usually, I keep my gemini/gopher content to either ports of things I do on HTTP land (i.e; gemini://tilde.team/~khuxkm/ao3proxy/) or written content (i.e; gemini://tilde.team/~khuxkm/writing/, gemini://tilde.team/~khuxkm/gemlog/)

> I just started writing a series on resilient git-based project setup, 
> inspired by Sourcehut and all the conversations since the youtube-dl 
> takedown (and subsequent re-instatement).

Nice! I'll be sure to check it out.

> Next up: set up a Gemini ring and web ring. Then maybe complete the 
> trifecta with a Gopher hole.

LEO's out there (gemini://tilde.team/~khuxkm/leo/), as is the code that runs it if you want your own (https://tildegit.org/khuxkm/molniya). Of course, if you want to write your own, multiple implementations is a good thing!

> Anyway, thanks for making Gemini awesome.

It's people like you who help make it so.

Just my two cents,
Robert "khuxkm" Miles

From jmcbray at carcosa.net  Thu Nov 19 16:00:46 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 19 Nov 2020 11:00:46 -0500
Subject: [ANN] seirdy.one live on Geminispace (+questions)
In-Reply-To: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop> (Rohan Kumar's
 message of "Wed, 18 Nov 2020 23:08:10 -0800")
References: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
Message-ID: <87wnyh72vl.fsf@dorothy.carcosa.net>

Rohan Kumar <rkumar at rkumar-dekstop.carcosa.net> writes:


> I also set up a mailing list on Sourcehut (like, just now) to leave comments.
> I've linked the mailing list at the bottom of my weblog entries, but I'm not
> sure if I should do the same for my gemlog. Do people generally prefer mailing
> lists or gemlog entries with backlinks?  Or both?

There's no real consensus. I do most of my replying by gemlog entries
with backlinks, but for actually discovering them, I don't in practice
search for backlinks; instead, I just look on CAPCOM and Spacewalk.

Reply-by-mail is a good idea and good practice, though.

> One last question: Gemininauts (please oh please let that be a word) with
> twinlogs, how do you decide what to cross-post and what to keep
> {WWW,gemini,gopher}-exclusive? I'm leaning towards keeping my weblog more
> "professional" and my gemlog less filtered, leaving the shortest bits for the
> Fediverse. I'm curious to know how you all handle this.

I don't cross-post very much between Gemini and WWW. My gopher hole is a
mirror of my website, just because when I made my gopher hole I was
blogging on the web regularly, and configured my static site generator
to make gophermaps. My weblog mostly has things of general
interest/reference ? technical how-tos and recipes. My gemlog has more
personal bits, rants, general computer stuff. I have a separate gemlog
for politics, which is intended to be in a gonzo journalism style.

Short bits go either on the fediverse, or in a single file that's
periodically updated in my journal, inspired by Shufei's Weiphlog.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From ranfdev at gmail.com  Thu Nov 19 16:12:20 2020
From: ranfdev at gmail.com (Lorenzo Miglietta)
Date: Thu, 19 Nov 2020 17:12:20 +0100
Subject: On input and uploading of user content
In-Reply-To: <87eekt84ol.fsf@disroot.org>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
 <87eekt84ol.fsf@disroot.org>
Message-ID: <f749c381ad9f4aaa9f44866ad74bd4a9143939dd.camel@gmail.com>

> Consider that another solution that would be simple for your Gemini
> app
> to handle natively would be to upload your files to a file sharing
> service like Nextcloud or Lufi and then to use Gemini response code
> 10
> to prompt your user for the URL of the file they want your app to
> import.

Thanks for the idea, but I wanted to integrate uploading in my app.
Telling the user to upload a file into another service temporarily is
more of a workaround than a real solution.

> 


From steve at rawhex.com  Thu Nov 19 16:21:58 2020
From: steve at rawhex.com (Steve Lord)
Date: Thu, 19 Nov 2020 16:21:58 +0000
Subject: User authentication approaches
Message-ID: <43DA5C5A-22BF-4FC2-A73B-7E6907E2F3B1@rawhex.com>

Hi all, long time lurker, first time caller.

I was wondering how/if people are handling user authentication? I recognise that certificates could probably work, but these would authenticate a device rather than person. If the person loses the cert I imagine recovery would be difficult.

Is this a problem that has already been solved and my grep-fu on the gemini archive is just too weak? Has anyone implemented user authentication on any Gemini tools? I had a look at flounder?s code on sourcehut but using the web to do user stuff on Gemini seems a little counterintuitive.

I just wanted to see if it?s possible before I start writing stuff. It?s not unreasonable for Gemini to do things differently to the web. We just have to change our thinking to match.

Cheers,
Steve

From sir at cmpwn.com  Thu Nov 19 16:22:41 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 19 Nov 2020 11:22:41 -0500
Subject: User authentication approaches
In-Reply-To: <43DA5C5A-22BF-4FC2-A73B-7E6907E2F3B1@rawhex.com>
Message-ID: <C77DN4D40YOZ.3O3XAR2E5V6H5@taiga>

On Thu Nov 19, 2020 at 11:21 AM EST, Steve Lord wrote:
> I was wondering how/if people are handling user authentication? I
> recognise that certificates could probably work, but these would
> authenticate a device rather than person. If the person loses the cert I
> imagine recovery would be difficult.

I think we should normalize having to take care of your certificates,
and user agents should provide easy tools for doing so. Certs are much
better than, say, username & password.

If it becomes a problem in practice, perhaps we could do something like
handling certificate resets over email, similar to password resets are
done on the web.

Or you could just get in touch with the owner of the capsule if you get
locked out. Gemini is small and the human touch is still there, and I'll
be happy if we can hold the cold, unfeeling machine-governed
interactions at bay for a bit longer.

From julien at typed-hole.org  Thu Nov 19 16:25:17 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Thu, 19 Nov 2020 17:25:17 +0100
Subject: User authentication approaches
In-Reply-To: <43DA5C5A-22BF-4FC2-A73B-7E6907E2F3B1@rawhex.com>
References: <43DA5C5A-22BF-4FC2-A73B-7E6907E2F3B1@rawhex.com>
Message-ID: <247ac4e4-411a-560b-1d3d-005e6dce31d1@typed-hole.org>

On 19/11/2020 17:21, Steve Lord wrote:
> Hi all, long time lurker, first time caller.
> 
> I was wondering how/if people are handling user authentication? I recognise that certificates could probably work, but these would authenticate a device rather than person. If the person loses the cert I imagine recovery would be difficult.
> 
> Is this a problem that has already been solved and my grep-fu on the gemini archive is just too weak? Has anyone implemented user authentication on any Gemini tools? I had a look at flounder?s code on sourcehut but using the web to do user stuff on Gemini seems a little counterintuitive.
> 
> I just wanted to see if it?s possible before I start writing stuff. It?s not unreasonable for Gemini to do things differently to the web. We just have to change our thinking to match.
> 
> Cheers,
> Steve
> 

The only examples I konow of is gemini://astrobotany.mozz.us/ which uses 
a user certificate for authentication and it works pretty nicely.

From solderpunk at posteo.net  Thu Nov 19 15:44:06 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Thu, 19 Nov 2020 16:44:06 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <5FB662E4.8050506@marmaladefoo.com>
Message-ID: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>

Hi Geminauts,

On Thu Nov 19, 2020 at 1:19 PM CET, Luke Emmet wrote:

> I see no harm in using Atom as a machine readable format, but from my
> point of view the main downside is expecting end users to author it, or
> have the skills to run some command line application to generate it.
> Probably fine for early adopters, but not so good for "normal" users.

I quite agree with this perspective.  The biggest drawback to using Atom
as the standard way to subscribe to serial content on Gemini is not the
difficulty of parsing, but that it requires the authors of such content
to generate the feed file.  I thought this could be addressed with good
tooling, such as my gemfeed program, but real world experience in
helping people use it, and using it myself, has proven this is not
actually straightforward.  The sticking point is the need for
timestamps.  File system timestamps are too easily accidentally changed
to be really useful for this.  Of course the problem is trivially solved
by some kind of static site generator which keeps its own database of
creation/update times and generates the feed, but IMHO it absolutely
should be necessary to use such a system just to make your content
subscribable.  If somebody wants to use such a tool, more power to them,
but ideally one should be able to manage a capsule entirely by hand with
nothing more than a standard text editor if that's what one wants to do,
and still participate in Geminispace as a first class citizen.  Atom
feeds don't fit well with this ideal.

Systems like Spacewalk or Moku Pona (recently updated to support
Gemini!) *do* fit with this ideal.  The content author does not need to
do anything special at all, and users can subscribe to anything at all.
These are extremely desirable properties.  The downside is that these
change-detection systems are fragile (and will erroneously declare a
site to have been updated if all the author did is change a typo or add
some ASCII art above their post list), and provide no meta-data - you
can't see post titles in Spacewalk the way you can in CAPCOM.

I have been thinking for some time now about how to get the best of both
these worlds, and have had Fediverse/email discussions with a few
people about this subject.  Recently I settled on a design and had been
meaning to make some kind of post about it.  Reading this thread, I
realise now I've independently reinvented exactly the same scheme that
Luke Emmet has already implemented!

I would be strongly in favour of some kind of "sidekick standard" (like
robots.txt) defining a process by which *any* text/gemini document can
be interpreted as a feed and subscribed to.  The details would look
roughly like this:

* The text of the first heading line (e.g. # My gemlog) to appear in the
  document is equivalent to the <feed><title> element of an Atom feed.
  All other heading lines are ignored.
* All other lines which are not link lines are ignored.
* All link lines with labels where the first whitespace-separated
  component of the label is a recognised datestamp are treated as
  equivalent to an Atom <entry> element, where:
    - The link's URL provides <entry><link>
    - The datestamp provides <entry><updated>
    - The content of the label after the datestamp provides
      <entry><title>
* All other link lines are ignored

Ignoring link lines without a datestamp allows for the presence of
"Home" or "Next page in LEO" (I only learned about LEO yesterday - love
it!) links in a subscribable page without having them turn up as entries
in the feed.

All this requires to become a fairly complete spec is a specification of
acceptable datestamp formats.  It seems like Luke Emmet's implementation
of this is flexible in this regard.  I would argue strongly in favour of
supporting only a single format, namely the ISO 8601 format (in which
today is 2020-11-19).  The advantages of this format are:

* There's a complete formal spec for it already available, written and
  maintained by somebody else
* It's linguistically neutral (e.g. does not use English-specific
  abbreviations like "Jun" or "Mon")
* It's very easily recognised via a simple regex
* Lexicographic sorting is equivalent to chronological sorting.

If all feeds use this format, then an aggregator which subscribes to
multiple feeds (and I realise that Luke's tool is *not* one of these,
so the fact that it is flexible on dates should not be perceived as a
failing) can fetch all its feeds and sort the entries it finds from most
recent to oldest without even having to actually parse the datestamps at
all - they can just be treated as dumb strings.  This substantially
simplifies aggregator design compared to a standard which allows
multiple date formats, or which mandates any other date format.

I am aware this approach does not provide as much information as an Atom
feed does (e.g. it cannot convey per-entry authorship), but it should be
adequate for a majority of real-world cases.  Certainly it would be
adequate for something like the CAPCOM and Spacewalk aggregators
currently in popular use.

I don't want to be perceived as forcing this design upon the community,
but I have given it quite some thought and I really think it's hard to
significantly improve upon.  It would allow for aggregators with all the
best parts of CAPCOM (high resistance to false alarm updates, providing
feed and entry titles in aggregated output) with implementation burdens
much closer to Spacewalk, for both aggregator authors and content
authors.  That's a very Gemini kind of solution. :)  A quick browse of
CAPCOM and Spacewalk suggest the majority of gemlogs are already 100%
compatible with this method of subscription (including all those at
gemlog.blue).  Many which aren't could be very quickly and easily made
so (e.g. by changing 2020/11/19 to 2020-11-19), without any nasty side
effects like changing URLs.

So, if somebody can see serious shortcomings with this approach or needs
clarification of some small details, I'm very happy to discuss it, but
otherwise it would be nice to avoid this becoming yet another endless
bikeshedding expedition, and I'd be happy to bless this approach or one
very similar as "official" quite quickly.  CAPCOM is rapidly approaching
100 feeds, and I would love to see the community move toward norms of
people either running their own private aggregators to read only what
they like, and/or people setting up curated public aggregators specific
to particular special interests, rather than encouraging everybody to
read everything that anybody ever says.  Making subscription
substantially easier could help push us in that direction.

Cheers,
Solderpunk


From bjorn.warmedal at gmail.com  Thu Nov 19 17:56:20 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 19 Nov 2020 18:56:20 +0100
Subject: On input and uploading of user content
In-Reply-To: <f749c381ad9f4aaa9f44866ad74bd4a9143939dd.camel@gmail.com>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
 <87eekt84ol.fsf@disroot.org>
 <f749c381ad9f4aaa9f44866ad74bd4a9143939dd.camel@gmail.com>
Message-ID: <CAJScK0J80X6wNQOe0Zu5AV1Z4t6c5agEEm1WcCwj9uRe+yHSig@mail.gmail.com>

Hi,

I compiled a bunch of arguments on this subject in two posts on my
gemlog not long ago:
gemini://tilde.team/~ew0k/gemini-and-post.gmi
gemini://tilde.team/~ew0k/gemini-and-post-part2.gmi

The tl;dr of it is that there is no standardized way of
posting/uploading content in geminispace, and you are encouraged to
design a solution that works best for your use case.

Cheers,
ew0k

From jmcbray at carcosa.net  Thu Nov 19 17:59:55 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 19 Nov 2020 12:59:55 -0500
Subject: Again on feeds in Gemini format
In-Reply-To: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar> (solderpunk@posteo.net's
 message of "Thu, 19 Nov 2020 16:44:06 +0100")
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
Message-ID: <87sg956xd0.fsf@dorothy.carcosa.net>

"Solderpunk" <solderpunk at posteo.net> writes:

> All this requires to become a fairly complete spec is a specification
> of acceptable datestamp formats. It seems like Luke Emmet's
> implementation of this is flexible in this regard. I would argue
> strongly in favour of supporting only a single format, namely the ISO
> 8601 format (in which today is 2020-11-19). The advantages of this
> format are:

Should the datestamp be *just* a date? Or should it include a timestamp?
This would be useful mainly for posts in the same day that have some
natural ordering (ie replies to one another). If it has a timestamp,
should it be 2020-11-19T17:01:26+00:00, 2020-11-19T17:01:26Z, or
20201119T170126Z, or are any of these good?

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From sir at cmpwn.com  Thu Nov 19 18:00:34 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 19 Nov 2020 13:00:34 -0500
Subject: Again on feeds in Gemini format
In-Reply-To: <87sg956xd0.fsf@dorothy.carcosa.net>
Message-ID: <C77FQ2AR11T0.2QZ8ZJQ6B8PPI@taiga>

On Thu Nov 19, 2020 at 12:59 PM EST, Jason McBrayer wrote:
> Should the datestamp be *just* a date? Or should it include a timestamp?
> This would be useful mainly for posts in the same day that have some
> natural ordering (ie replies to one another). If it has a timestamp,
> should it be 2020-11-19T17:01:26+00:00, 2020-11-19T17:01:26Z, or
> 20201119T170126Z, or are any of these good?

Timestamps are not human readable and your use-case is not a feed.

NACK.

Yes, it will break use-cases. Thus is the wisdom of Gemini.

From callum at calcuode.com  Thu Nov 19 17:48:40 2020
From: callum at calcuode.com (Callum Brown)
Date: Thu, 19 Nov 2020 17:48:40 +0000
Subject: Again on feeds in Gemini format
Message-ID: <C77FGYBG89HW.2D0IAGD6H0NE@callum-computer>

On Thu Nov 19, 2020 15:44:06 GMT Solderpunk wrote:
> * The text of the first heading line (e.g. # My gemlog) to appear in the
>   document is equivalent to the <feed><title> element of an Atom feed.
>   All other heading lines are ignored.
> * All other lines which are not link lines are ignored.
> * All link lines with labels where the first whitespace-separated
>   component of the label is a recognised datestamp are treated as
>   equivalent to an Atom <entry> element, where:
>     - The link's URL provides <entry><link>
>     - The datestamp provides <entry><updated>
>     - The content of the label after the datestamp provides
>       <entry><title>
> * All other link lines are ignored

I like this approach. The only thing I would point out is that the
example heading "# My gemlog" should probably be "# <author>'s gemlog"
instead so aggregators get some kind of author information.

> I would argue strongly in favour of supporting only a single format,
> namely the ISO 8601 format (in which today is 2020-11-19).

The exact time of posts is rarely relevant, so I think this makes
sense. If authors want to include a timestamp or written date
(e.g. Thursday 19 November 2020) I suppose they could put that in the
title section but it may turn out a bit messy.

Callum

From colecmac at protonmail.com  Thu Nov 19 18:09:38 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 19 Nov 2020 18:09:38 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
Message-ID: <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>

Overall this seems like a great solution, thanks a lot for chiming in.

> So, if somebody can see serious shortcomings with this approach or needs
> clarification of some small details, I'm very happy to discuss it, but
> otherwise it would be nice to avoid this becoming yet another endless
> bikeshedding expedition, and I'd be happy to bless this approach or one
> very similar as "official" quite quickly.

Please. I would be happy to see this discussion come to a rest. I'd appreciate
if you could publish a spec for this on the Web and Gemini, and maybe something
in the guide and/or FAQ to help onboard new authors, and explain whether they
should do Atom too, etc. I understand publishing the spec would probably create
more discussion, but at least it would be in a more helpful direction.

I've been told ew0k is about to send an email covering timestamps, which would
be the biggest issue I see. The largest timezone difference in the world is 26
hours, and even for smaller differences, taking dates as UTC can mess with
continuity, and have replies show up before the original posts, or have day
specific posts (like for a holiday) show up as on the wrong day.

> I would argue strongly in favour of supporting only a single format, namely
> the ISO 8601 format (in which today is 2020-11-19).

To further make my point and be annoying, I'd like to point out that today is
2020-11-20 for all the Australians out there. ;)


The other small issue I see is people who naturally separate the date and post
with some other character. Like this:

2020-02-01 - Some other post
2020-01-01 - My first post


This would mean their title starts with a dash. Not great, but I'd say that's a
acceptable issue to have. It would be nice if the spec excluded certain characters
from the beginning maybe, like all whitespace, dashes, colons, etc.


Cheers,
makeworld

From colecmac at protonmail.com  Thu Nov 19 18:11:25 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 19 Nov 2020 18:11:25 +0000
Subject: User authentication approaches
In-Reply-To: <247ac4e4-411a-560b-1d3d-005e6dce31d1@typed-hole.org>
References: <43DA5C5A-22BF-4FC2-A73B-7E6907E2F3B1@rawhex.com>
 <247ac4e4-411a-560b-1d3d-005e6dce31d1@typed-hole.org>
Message-ID: <MlUX8cSR00rFIB2znSgySES_4p2PTWoIIYDHD1gWDgPr8WjsObmlJVJODGD3A7hvfqaqYIQeCv7Kos9lvKbMXuL8K_y_EBM1vj-BN95xTTg=@protonmail.com>

> The only examples I konow of is gemini://astrobotany.mozz.us/ which uses
> a user certificate for authentication and it works pretty nicely.

Astrobotany also supports setting a password to change certs if needed, which
I think is pretty relevant here. Not really sure how it works though, maybe
Mozz can chime in.


makeworld



From acdw at acdw.net  Thu Nov 19 18:16:01 2020
From: acdw at acdw.net (acdw)
Date: Thu, 19 Nov 2020 18:16:01 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>
Message-ID: <8cfea0ed-e819-4e89-8093-ba8d6592bdcf@www.fastmail.com>

On 2020-11-19 (Thursday) at 18:09, colecmac at protonmail.com wrote:

> I've been told ew0k is about to send an email covering timestamps, which would
> be the biggest issue I see. The largest timezone difference in the world is 26
> hours, and even for smaller differences, taking dates as UTC can mess with
> continuity, and have replies show up before the original posts, or have day
> specific posts (like for a holiday) show up as on the wrong day.

I honestly don't see the problem with this.  As has been pointed out, CAPCOM and Spacewalk, and as has been said, this format, all have "problems" with ordering replies before the original post.  I've never not been able to figure out which actually comes first.

Now that I'm thinking about it, the same problem comes up with Twitter and other social medias.  People are smart.  One thing I like about Gemini is it's a protocol that assumes people are smart.  We can figure things out.

Let's not over-engineer something because we think people *might* be confused for 1/2 of a second.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From khuxkm at tilde.team  Thu Nov 19 18:19:11 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 19 Nov 2020 18:19:11 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <87sg956xd0.fsf@dorothy.carcosa.net>
References: <87sg956xd0.fsf@dorothy.carcosa.net>
 <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
Message-ID: <a8ecdab4c5822c991a49d6114f81e3dd@tilde.team>

November 19, 2020 12:59 PM, "Jason McBrayer" <jmcbray at carcosa.net> wrote:

> Should the datestamp be *just* a date? Or should it include a timestamp?
> This would be useful mainly for posts in the same day that have some
> natural ordering (ie replies to one another). If it has a timestamp,
> should it be 2020-11-19T17:01:26+00:00, 2020-11-19T17:01:26Z, or
> 20201119T170126Z, or are any of these good?

Seconding this. Post order *within* a day is important when it comes to post replies. While this may not be a feed usecase, it IS a feed aggregator usecase, which should be considered. Even in the case of, say, just a client feed reader, it'd be easier to handle posts and their replies if there was some sort of intra-day sort.

I would say that timestamps should be restricted to a certain timezone (i.e; UTC), just to maintain that idea of "you can just treat this date as a dumb string".

Just my two cents,
Robert "khuxkm" Miles

From luke at marmaladefoo.com  Thu Nov 19 18:27:05 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 19 Nov 2020 18:27:05 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>
Message-ID: <5FB6B8F9.5030601@marmaladefoo.com>

On 19-Nov-2020 18:09, colecmac at protonmail.com wrote:
> The other small issue I see is people who naturally separate the date 
> and post
> with some other character. Like this:
>
> 2020-02-01 - Some other post
> 2020-01-01 - My first post
>
>
> This would mean their title starts with a dash. Not great, but I'd say that's a
> acceptable issue to have. It would be nice if the spec excluded certain characters
> from the beginning maybe, like all whitespace, dashes, colons, etc.

I support this optional hyphen (not sure the others are really needed 
though tbh). My own implementation does this. It feels to me a very 
natural way to write the gemlog entry title.

I'll have to get my mind around the year/month/date format - it feels 
less natural since no one uses that in normal speech, but I'll 
definitely get there if this is conventionalised. I see it is probably 
the best way to prevent ambiguity about whether 2/1/2020 is 2nd Jan or 
1st of Feb.

On the timestamp issue, I think we can live without them, but if some 
users really want to put them in for disambiguation, we shouldn't shout 
it down. But please the *recommendation* should be just to use the date 
in almost all instances.

  - Luke


From colecmac at protonmail.com  Thu Nov 19 18:30:28 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 19 Nov 2020 18:30:28 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <8cfea0ed-e819-4e89-8093-ba8d6592bdcf@www.fastmail.com>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>
 <8cfea0ed-e819-4e89-8093-ba8d6592bdcf@www.fastmail.com>
Message-ID: <5yr1mnC_FxPnyOW5b1jkZ6C5A70MJNH-zh1W128Fy69dkvwrmSxH_1Z8sv5xx2vD5351ex9XWPM6icg-sSolwE-jrrok-zxR1Ktjs6X4Rr8=@protonmail.com>

On Thursday, November 19, 2020 1:16 PM, acdw <acdw at acdw.net> wrote:

> On 2020-11-19 (Thursday) at 18:09, colecmac at protonmail.com wrote:
>
> > I've been told ew0k is about to send an email covering timestamps, which would
> > be the biggest issue I see. The largest timezone difference in the world is 26
> > hours, and even for smaller differences, taking dates as UTC can mess with
> > continuity, and have replies show up before the original posts, or have day
> > specific posts (like for a holiday) show up as on the wrong day.
>
> I honestly don't see the problem with this. As has been pointed out, CAPCOM and Spacewalk, and as has been said, this format, all have "problems" with ordering replies before the original post. I've never not been able to figure out which actually comes first.
>
> Now that I'm thinking about it, the same problem comes up with Twitter and other social medias. People are smart. One thing I like about Gemini is it's a protocol that assumes people are smart. We can figure things out.
>
> Let's not over-engineer something because we think people might be confused for 1/2 of a second.

I agree, I'm not saying to dump the whole idea. I just think that if there's
a solution to be found to this, let's find it. If not, well that's too bad,
and we can use this but also encourage people to support Atom where possible.

Maybe a solution to have an *optional* line that reads: "Timezone: EST" or
something similar? Maybe "Timezone: America/Toronto" instead?

That way authors can specify it, but existing pages will work fine and just
be interpreted as UTC.


makeworld

From rkumar at rkumar-dekstop  Thu Nov 19 18:36:11 2020
From: rkumar at rkumar-dekstop (Rohan Kumar)
Date: Thu, 19 Nov 2020 10:36:11 -0800
Subject: Again on feeds in Gemini format
In-Reply-To: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
References: <5FB662E4.8050506@marmaladefoo.com>
 <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
Message-ID: <20201119183611.ib722i7zskkqksx6@rkumar-dekstop>

On Thu, Nov 19, 2020 at 04:44:06PM +0100, Solderpunk wrote:
>I quite agree with this perspective.  The biggest drawback to using Atom
>as the standard way to subscribe to serial content on Gemini is not the
>difficulty of parsing, but that it requires the authors of such content
>to generate the feed file.  I thought this could be addressed with good
>tooling, such as my gemfeed program, but real world experience in
>helping people use it, and using it myself, has proven this is not
>actually straightforward.

It is true that authors generally have to run a program to generate an 
RSS/ATOM feed, but how is this different from self-hosting Spacewalk? 
Either way, if you want to own your feed, you'll have to run a command. 
The difference seems to be that the former (plain RSS/ATOM) takes the 
static-site-gen route while the latter (Spacewalk & co.) takes the route 
of dynamically-generated content. The merits and use-cases for static 
and dynamic sites is a slightly different discussion that's been going 
on for decades.

>If somebody wants to use such a tool, more power to them, but ideally 
>one should be able to manage a capsule entirely by hand with nothing 
>more than a standard text editor if that's what one wants to do, and 
>still participate in Geminispace as a first class citizen.  Atom feeds 
>don't fit well with this ideal.

I agree, but I don't think this means that we should move away from Atom 
feeds. I think that exposing an Atom feed (or newsletter) to let users 
get new posts sent to them and saved offline is a bit different than 
having a Gemini service run by someone else aggregate links. The two can 
co-exist without competing.

That being said, I find the new proposals interesting. I'm more than 
willing to revise my statements if they prove to be better. But having a 
single program (my RSS/Atom reader) from which to get updates from all 
the *logs I follow is something I hope doesn't go away. It's the main 
reason why I use Sloum's bombadillo as my main client, since it mostly 
eliminates the need to juggle multiple clients for multiple protocols.

TLDR: the new alternatives to RSS/Atom are nice, and I hope they succeed 
without making me use more than one client for browsing and one client 
for fetching updates across the text-based Internet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 902 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201119/cecac775/attachment.sig>

From dimitri at dmerej.info  Thu Nov 19 18:17:24 2020
From: dimitri at dmerej.info (Dimitri Merejkowsky)
Date: Thu, 19 Nov 2020 19:17:24 +0100
Subject: [ANN] dmerej.info capsule
Message-ID: <c93e37ff-c27a-e8d2-813d-e250f46692fc@dmerej.info>

Hi there,

I'm happy to announce I've just launch a Gemini-powered version of my 
personal website (which is still hosted at https://dmerej.info by the way)

See you at gemini://dmerej.info!

You may want to start with the latest article:

gemini://dmerej.info/blog/0114-dmerej-info-now-on-the-gemini-space.gmi

Cheers,

Dimitri Merejkowsky

From colecmac at protonmail.com  Thu Nov 19 18:43:51 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 19 Nov 2020 18:43:51 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <20201119183611.ib722i7zskkqksx6@rkumar-dekstop>
References: <5FB662E4.8050506@marmaladefoo.com>
 <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <20201119183611.ib722i7zskkqksx6@rkumar-dekstop>
Message-ID: <ssKo8stkDVhOG9NyfiS7fkhOdhVYJ7pZCtkGzHYeTNmlUARr0D-Vtmi4QXc0bv_5Otouh7iHsGjQ5X2yw_xYNK-_GpXN5tNLPZlmX-_adjg=@protonmail.com>

> It is true that authors generally have to run a program to generate
> an RSS/ATOM feed, but how is this different from self-hosting Spacewalk?

There are more content authors then there are people who want to self-host
aggregators. The proposal helps content authors who want their posts to
be interpreted properly by public aggregators without having to generate
an Atom feed themselves, which can be difficult.


makeworld

From bjorn.warmedal at gmail.com  Thu Nov 19 18:44:04 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 19 Nov 2020 19:44:04 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <hu2AplSmX6XHKVKtrBR2oetwJB1Bu2QXcv4SeXwOyhz7CNk_oYAYVLN8fhu_cCLC08MG3zIhJyPq25aUjJvaixHlr-cUmFE_-4BNTaZFT-w=@protonmail.com>
Message-ID: <CAJScK0KTgzxWY1Fsdce8K5Td9-C1dREF7KcpoB2LWtuBtixnXQ@mail.gmail.com>

So I wrote a gemlog about a gemini feed a few days ago, way before I
even knew it was an ongoing discussion:
gemini://tilde.team/~ew0k/is-this-aggregator-idea-good.gmi

Obviously I'd given the matter a thorough 10 or so minutes before
sharing my thoughts :) I've thought a lot more on it since, and
received a great amount of feedback.

The format I proposed was this:

=> FULLURLTOPOST TIMESTAMP, AUTHOR NAME, TITLE
For example:
=> gemini://billsdomain.com/gemlog/posts/is-this-aggregator-idea-good.gmi
2020-11-14T22:03:12+00:00, Bill P. Jones, Is This Aggregator Idea
Good?

Obviously my intended use case is *very* specific: I intended for a
feed aggregator to in turn produce a feed of the same format that it
was parsing to begin with, in order to allow recursive aggregation. In
that case the author's name becomes important, but if my "feed" is a
bunch of links from my own index page then putting my own name on
every link looks weird and feels redundant.

And timestamp... well... I hate it when posts end up in the wrong
order, but I have issues with the timestamp format I proposed myself
too:
- it's hardly human readable. Too long.
- The inclusion of a timezone makes lexicographic sort fallible. I
don't see how we can make everyone set a timestamp in UTC, though.
People will (and should, since it feels more natural to them) use
their own local time.

I don't want to be bikeshedding this issue, and I clearly see how my
own proposed format has flaws that are insurmountable if we want to
gain widespread adoption.

However... I don't see how an overly simplified format makes any sense
at all. I'd rather parse a bunch of atom feeds than aggregate a bunch
of link lists that will end up looking like this:

[1] 2020-11-21 - Re: My thoughts
[2] 2020-11-20 - My thoughts
[3] 2020-11-20 RE: My thoughts
[4] 2020-11-19 ~ew0k, A post!
[5] 2020-11-19 Diary Entry, ~someone

Cheers,
~ew0k

From sir at cmpwn.com  Thu Nov 19 18:45:16 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 19 Nov 2020 13:45:16 -0500
Subject: Again on feeds in Gemini format
In-Reply-To: <CAJScK0KTgzxWY1Fsdce8K5Td9-C1dREF7KcpoB2LWtuBtixnXQ@mail.gmail.com>
Message-ID: <C77GOATAGFX1.1U0RBM0ZP5LEF@taiga>

On Thu Nov 19, 2020 at 1:44 PM EST, Bj?rn W?rmedal wrote:
> However... I don't see how an overly simplified format makes any sense
> at all. I'd rather parse a bunch of atom feeds than aggregate a bunch
> of link lists that will end up looking like this:
>
> [1] 2020-11-21 - Re: My thoughts
> [2] 2020-11-20 - My thoughts
> [3] 2020-11-20 RE: My thoughts
> [4] 2020-11-19 ~ew0k, A post!
> [5] 2020-11-19 Diary Entry, ~someone

This has been rubbing me the wrong way for a while now, and I mentioned
it here:

gemini://drewdevault.com/2020/11/15/RE-Is-this-aggregator-idea-good.gmi

Gemini is simply not well-suited to discussions like this. There's a
reason this ended up on the mailing list instead of continuing to
pollute our gemlogs.

We don't need Gemini to solve every problem. In fact, we shouldn't want
it to. This is one of the main appeals of Gemini.

So yes, lack of timestamps makes this use-case break. So what? Every
use-case isn't entiteld to working well on Gemini.

From solderpunk at posteo.net  Thu Nov 19 18:35:36 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Thu, 19 Nov 2020 19:35:36 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <87sg956xd0.fsf@dorothy.carcosa.net>
Message-ID: <C77GGW8LU960.13IF0G5GFMV1@stilgar>

On Thu Nov 19, 2020 at 6:59 PM CET, Jason McBrayer wrote:

> Should the datestamp be *just* a date? Or should it include a timestamp?
> This would be useful mainly for posts in the same day that have some
> natural ordering (ie replies to one another). If it has a timestamp,
> should it be 2020-11-19T17:01:26+00:00, 2020-11-19T17:01:26Z, or
> 20201119T170126Z, or are any of these good?

I did wonder about this.  ISO 8601 does make the time format clear.
However, a big part of the appeal for me of this approach is that it
allows a single text/gemini index to function for both machine
subscription and ordinary reading by human eyeballs.  I agree with Drew
that full blown timestamps like 2020-11-19T17:01:26+00:00 are not very
human readable.  Requiring this would make gemlog indices look ugly and
cluttered for human users, which would be a shame - especially as the
time information does not strike me as terribly important.  The
majority of phlogs and gemlogs do not receive more than one update a
day.  In the majority of exceptions to this, the two posts on the same
day do not make important references to each other and so reading them
out of order is not a big deal.  It's true this may cause occasional
problems with response threads.  But scope for serious confusion doesn't
appear until we have multiple posts in the same thread by the same
author on the same day, and I don't think it's the worst thing in the
world if some features of Geminispace act to discourage that kind of
high-paced discussion.  Most of us are here to discover a slower way of
computing, and there's always mailing lists or IRC for lengthy
discussions.

So, I think we'll probably be just fine with date stamps only.

Cheers,
Solderpunk

From lazar.michael22 at gmail.com  Thu Nov 19 19:04:50 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 19 Nov 2020 14:04:50 -0500
Subject: User authentication approaches
In-Reply-To: <MlUX8cSR00rFIB2znSgySES_4p2PTWoIIYDHD1gWDgPr8WjsObmlJVJODGD3A7hvfqaqYIQeCv7Kos9lvKbMXuL8K_y_EBM1vj-BN95xTTg=@protonmail.com>
References: <43DA5C5A-22BF-4FC2-A73B-7E6907E2F3B1@rawhex.com>
 <247ac4e4-411a-560b-1d3d-005e6dce31d1@typed-hole.org>
 <MlUX8cSR00rFIB2znSgySES_4p2PTWoIIYDHD1gWDgPr8WjsObmlJVJODGD3A7hvfqaqYIQeCv7Kos9lvKbMXuL8K_y_EBM1vj-BN95xTTg=@protonmail.com>
Message-ID: <CAFTy05Z=T3FhD+Xzzjv-vzf4RvzuOr86Snh=ekirB5dAiqR8Kw@mail.gmail.com>

On Thu, Nov 19, 2020 at 1:11 PM <colecmac at protonmail.com> wrote:
>
> > The only examples I konow of is gemini://astrobotany.mozz.us/ which uses
> > a user certificate for authentication and it works pretty nicely.
>
> Astrobotany also supports setting a password to change certs if needed, which
> I think is pretty relevant here. Not really sure how it works though, maybe
> Mozz can chime in.

Here's how astrobotany is currently doing authentication.

You create a self-signed certificate and make a request to astrobotany. The
server detects that the cert is unrecognized, and asks you if you are a new
user or an existing user.

If you are a new user, you are prompted to enter a unique username. This name
used to be pulled directly from the subject CN of the certificate, but that
lead to some unfortunate UX issues with duplicate users so I changed it to be
separate instead. At this point, your certificate is registered and you can
access the application. Any future requests to the server with that certificate
will automatically log you in. Everything past this point is strictly optional.

Once logged in, you can open the astrobotany settings page where you can define
a secret password. The password allows you to attach additional certificates to
the same user account.

Going back to step one, if you are an existing user and you provide an
unrecognized certificate, the server will prompt you to enter your username and
password from above. If verified, the new cert will be attached to your account.

You can repeat this process as many times as you want to add new certificates.
All of the certificates can be viewed and deleted from the settings inside of
the application (with the exception that the currently active cert can't be
deleted, to prevent lockout).

My personal astrobotany user currently has two certificates; one on my laptop
that I use with av-98 and one on my phone that I use with Petr Vernigorov's iOS
gemini client (which is an awesome client that doesn't get enough praise). I
like this method because otherwise there would be no way to copy an existing
certificate into the iOS client.

There was one time when somebody lost their astrobotany cert so they sent me an
email. I was able to reset their password for them so they could generate and
upload a new certificate. This was very straightforward and a lot easier than
it would have been to pass certificates back and forth via email.

- Michael

From cowan at ccil.org  Thu Nov 19 19:05:33 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 19 Nov 2020 14:05:33 -0500
Subject: Again on feeds in Gemini format
In-Reply-To: <C77FQ2AR11T0.2QZ8ZJQ6B8PPI@taiga>
References: <87sg956xd0.fsf@dorothy.carcosa.net>
 <C77FQ2AR11T0.2QZ8ZJQ6B8PPI@taiga>
Message-ID: <CAD2gp_QzyOy1j0OocrSGxbMN4ghEkgvRNL1XNYSshsQq3fh=dA@mail.gmail.com>

On Thu, Nov 19, 2020 at 1:01 PM Drew DeVault <sir at cmpwn.com> wrote:

Timestamps are not human readable


Lots and lots of people around the world are extremely used to dates
written 2020-11-19, notably in China where it is the national standard.
It's very easy for U.S. folks to interpret as a variant of their
11/19/2020, and probably not all that much work for Europeans (yes, the UK
is in Europe, just like Switzerland) with their 19/11/2020 either, as it is
consistently big-endian whereas the native format is consistently
little-endian.  A number of countries are switching over, at least for
official purposes.

I think it is very important that timestamps are sent in Universal Time
only.  Resolving local times, especially after the fact, is a Very Big Deal
involving a complex C library and timezone data files that change at least
once a year and typically more often.

But I do favor standard punctuation, so I would support the following fixed
format:  2020-11-19T18:12:00Z where Z means Universal Time.  20
characters.  Period.  If you don't have time information, use 00:00:00Z.

Feed aggregators should probably add the feed name in square brackets after
the date and before the title, so that the user can peruse the "Famous
Foovians" feed while ignoring links to the "Foovian Politicians" gemlog,
say.  This would be obtained from the first-level heading in the feed
file.  The only reason for standardizing the square brackets is so as not
to have two entries on second-level aggregations.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Your worships will perhaps be thinking that it is an easy thing
to blow up a dog? [Or] to write a book?
    --Don Quixote, Introduction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201119/232a5446/attachment.htm>

From emilis at emilis.net  Thu Nov 19 19:09:15 2020
From: emilis at emilis.net (Emilis)
Date: Thu, 19 Nov 2020 21:09:15 +0200
Subject: Again on feeds in Gemini format
In-Reply-To: <ssKo8stkDVhOG9NyfiS7fkhOdhVYJ7pZCtkGzHYeTNmlUARr0D-Vtmi4QXc0bv_5Otouh7iHsGjQ5X2yw_xYNK-_GpXN5tNLPZlmX-_adjg=@protonmail.com>
References: <5FB662E4.8050506@marmaladefoo.com>
 <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <20201119183611.ib722i7zskkqksx6@rkumar-dekstop>
 <ssKo8stkDVhOG9NyfiS7fkhOdhVYJ7pZCtkGzHYeTNmlUARr0D-Vtmi4QXc0bv_5Otouh7iHsGjQ5X2yw_xYNK-_GpXN5tNLPZlmX-_adjg=@protonmail.com>
Message-ID: <a3423292-74ea-6dd7-d1ee-f18eb55c08f8@emilis.net>

On 11/19/20 8:43 PM, colecmac at protonmail.com wrote:
>> It is true that authors generally have to run a program to generate
>> an RSS/ATOM feed, but how is this different from self-hosting Spacewalk?
> There are more content authors then there are people who want to self-host
> aggregators. The proposal helps content authors who want their posts to
> be interpreted properly by public aggregators without having to generate
> an Atom feed themselves, which can be difficult.
I agree that it could be the job of aggregators to convert between the 
feed formats and re-share the feeds.

The Gemini feed format then could be more oriented to be human readable 
and writable.

The ISO8601 timestamps could be both short (e.g. 2020-11-19) and long, 
UTC based (e.g. 2020-11-19T18:51:31+00:00).

It would be up to the author to order the post links in order.

The format would work more like an index and would prevent the common 
problems with using file creation/modification times.

The aggregators could then take these index files/feeds and fill in the 
missing time parts if needed and according to their own implementations 
(e.g. keep a database of when links appeared / add "T00:00:00Z" to the 
date before sorting and so on).

--
Emilis Dambauskas

From marcx2 at welz.org.za  Thu Nov 19 19:09:56 2020
From: marcx2 at welz.org.za (marc)
Date: Thu, 19 Nov 2020 20:09:56 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
References: <5FB662E4.8050506@marmaladefoo.com>
 <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
Message-ID: <20201119190956.GA18856@localhost.localdomain>

Hi

Would it be useful to include something which tells
the software polling the feed when the next post could
be expected ? It doesn't imply an obligation, it is
just a hint...

I concede this adds more complexity in the markup, but
has the benefit that those polling the site don't need to hammer
it as much - that might be important as tls connections
are moderately expensive, and many sites run on very
small, shared or personal systems.

Maybe just the first/last link (pointing nowhere, or
to itself or some other distinguished name) with a timestamp
in the future could tell us when to poll again,
and if there is no future timestamp, the polling interval
could be some sort of backoff (eg the difference
between the newest post and the current time) so that
abandoned sites don't get polled needlessly, while
those wanting to be polled often just update their
future timestamps regularly ?

regards

marc

From emilis at runbox.com  Thu Nov 19 19:06:53 2020
From: emilis at runbox.com (Emilis Dambauskas)
Date: Thu, 19 Nov 2020 21:06:53 +0200 (EET)
Subject: Again on feeds in Gemini format
Message-ID: <E1kfpGf-0003IW-OW@rmmprod07.runbox>

2020-11-19 20:43 GMT+02:00 colecmac at protonmail.com:
>> It is true that authors generally have to run a program to generate
>> an RSS/ATOM feed, but how is this different from self-hosting Spacewalk?
> 
> There are more content authors then there are people who want to self-host
> aggregators. The proposal helps content authors who want their posts to
> be interpreted properly by public aggregators without having to generate
> an Atom feed themselves, which can be difficult.

I agree that it could be the job of aggregators to convert between the feed formats and re-share the feeds.

The Gemini feed format then could be more oriented to be human readable and writable.

The ISO8601 timestamps could be both short (e.g. 2020-11-19) and long, UTC based (e.g. 2020-11-19T18:51:31+00:00).

It would be up to the author to order the post links in order.

The format would work more like an index and would prevent the common problems with using file creation/modification times.

The aggregators could then take these index files/feeds and fill in the missing time parts if needed and according to their own implementations (e.g. keep a database of when links appeared / add "T00:00:00Z" to the date before sorting and so on).

--
Emilis Dambauskas

From solderpunk at posteo.net  Thu Nov 19 19:08:35 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Thu, 19 Nov 2020 20:08:35 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <C77GOATAGFX1.1U0RBM0ZP5LEF@taiga>
Message-ID: <C77H653ZK56Z.1QCPYJBV26TEE@stilgar>

On Thu Nov 19, 2020 at 7:45 PM CET, Drew DeVault wrote:

> This has been rubbing me the wrong way for a while now, and I mentioned
> it here:
>
> gemini://drewdevault.com/2020/11/15/RE-Is-this-aggregator-idea-good.gmi
>
> Gemini is simply not well-suited to discussions like this.

I'm not sure I agree that gemlog posts written in response to other
gemlog posts is not a good format, but the idea that something like feed
aggregation is the best way to follow this kind of discussion, and that
it should reliably provide a time-ordered list of all contributions to
the discussion, is clearly problematic.  It doesn't scale.  It's worked
quite well so far in both Gopherspace and Geminispace, but only because
both are so small that services like CAPCOM which follow everything are
still manageable.  If growth continues at current rates this will soon
start breaking down.  CAPCOM will become an indigestible fire hose.
People will start following only their own small set of feeds, and once
that happens the probability that you see anything other than a small
random slice of the conversation becomes very small and the whole thing
breaks even if posts appear in precisely the right order.

I still think it's a good idea when writing a non-trivial response to
something in Geminispace to reach out to the original author via email,
XMPP, Fediverse, whatever, to let them know.  Authors should feel free
to add a list of links at the end of their posts to responses which they
think are worthwhile interested readers reading.  People can pick up and
follow threads of conversation this way if they want.

I don't want to tell anybody how to live their life, but Gemini indeed
can't work equally well for all use-cases, and I personally (and I get
the impression most people in the Gemini community would agree) would be
happier if we designed things to work best for the case of somebody who
has subscribed to a dozen or so gemlogs on things they're particularly
interested in or by people they think of as friends, rather than for
somebody who feels a desperate need to read every last thing anybody
on the internet says in response to something.

Cheers,
Solderpunk


From smallick.dev at gmail.com  Thu Nov 19 19:30:38 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Fri, 20 Nov 2020 01:00:38 +0530
Subject: Again on feeds in Gemini format
In-Reply-To: <20201119190956.GA18856@localhost.localdomain>
References: <5FB662E4.8050506@marmaladefoo.com>
 <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <20201119190956.GA18856@localhost.localdomain>
Message-ID: <CAFaUHvKEZ5ht-jCpQUe7sVFsU16swMJ4=sBnedhi56d+cke2+g@mail.gmail.com>

What do you think about this alternate format?

# <title of the feed>
## (by)? <author>
bla bla...
### YYYY-MM-DD
=> <link> <title> (HH:MM)?
=> <link> <title> (HH:MM)?
.
.
.
### YYYY-MM-DD
=> <link> <title> (HH:MM)?
.
.
.

--- gemini feed ---
EOF
I think this is more human readable. And that --- gemini feed --- or
anything like that which will tell the crawlers etc. that this is a
feed.

From lazar.michael22 at gmail.com  Thu Nov 19 19:37:34 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 19 Nov 2020 14:37:34 -0500
Subject: Scheme Section 2 quibble
In-Reply-To: <20201118210938.GS19536@brevard.conman.org>
References: <20201117221041.GO19536@brevard.conman.org>
 <118a173f44f1a364ccb52a987ee3a91dca17a63d.camel@activ.ism.rocks>
 <20201118020209.GQ19536@brevard.conman.org>
 <20201118083301.240968d3c2694df5168a196b@gmail.com>
 <CAFaUHvLgAzbaNFuFSQgJqqjkZXfCsfG8TE1d5BV5nBSiEXNbig@mail.gmail.com>
 <20201118084257.GR19536@brevard.conman.org> <20201118090937.GA42221@202x.moe>
 <CAFaUHvKCr9o8AFj+EjrNjx0bFbeayoacDH87L1ue2he6_H7kHw@mail.gmail.com>
 <20201118164653.d9c882713471774c2119ee99@gmail.com> <871rgqfxnf.fsf@rwv.io>
 <20201118210938.GS19536@brevard.conman.org>
Message-ID: <CAFTy05bwJE26ks7YYKoOtgr4dm2S=U_oS1DxwSmKAeuiP9Qeig@mail.gmail.com>

On Wed, Nov 18, 2020 at 4:10 PM Sean Conner <sean at conman.org> wrote:
>
> It was thus said that the Great Remco once stated:
> >
> > If you want to point fingers:
> >
> > https://github.com/michael-lazar/gemini-diagnostics/blob/master/gemini-diagnostics#L440
> >
> > That's what I based my implementation on and I suspect many others did
> > so too.
>
>  The test isn't *wrong* per se, it's just testing at the wrong level. My
> server will return:
>
>     gemini://gemini.conman.org   -> 20
>     gemini://gemini.conman.org/   -> 20
>
> but
>
>     gemini://gemini.conman.org/test -> 31 gemini://gemini.conman.org/test/
>
>   which is what that test is testing.
>
>   -spc

Yes that's probably what I meant to do. It was difficult to write many of the
tests because they can't assume that any particular directory exists on the
server. I didn't realize that the root URL was special in this regard.

I think this is an interesting problem for the gemini protocol. In HTTP you
typically only have one way to write out this request so it's never a problem:

GET / HTTP/1.1

Even though "gemini://example.com" and "gemini://example.com/" are supposed to
be identical per the URL definition, good luck getting gemini developers to
read through 100+ pages of RFCs and implement this correctly.

- Michael

From colecmac at protonmail.com  Thu Nov 19 19:39:40 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 19 Nov 2020 19:39:40 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <CAFaUHvKEZ5ht-jCpQUe7sVFsU16swMJ4=sBnedhi56d+cke2+g@mail.gmail.com>
References: <5FB662E4.8050506@marmaladefoo.com>
 <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <20201119190956.GA18856@localhost.localdomain>
 <CAFaUHvKEZ5ht-jCpQUe7sVFsU16swMJ4=sBnedhi56d+cke2+g@mail.gmail.com>
Message-ID: <zLq6J5Bjk8NdB7lVXEk81N0FQ4akgCM-bQ_iVscXC4UH5dh9_fSie9xqU_3gAPMXXUubQaXBZmrTjh-KSxNp74Rmh8uWGSWIVcF4JaN4AWw=@protonmail.com>

On Thursday, November 19, 2020 2:30 PM, Sudipto Mallick <smallick.dev at gmail.com> wrote:

> What do you think about this alternate format?
<snipped>
> I think this is more human readable. And that --- gemini feed --- or
> anything like that which will tell the crawlers etc. that this is a
> feed.

The main advantage of Solderpunk's proposal was that it works with
existing pages and feeds. There's no point in creating this new format
if it needs to be written in a strict way that isn't already in use.

makeworld


From dan at palm93.com  Thu Nov 19 19:42:01 2020
From: dan at palm93.com (Dan)
Date: Thu, 19 Nov 2020 19:42:01 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <CAFaUHvKEZ5ht-jCpQUe7sVFsU16swMJ4=sBnedhi56d+cke2+g@mail.gmail.com>
References: <5FB662E4.8050506@marmaladefoo.com>
 <20201119190956.GA18856@localhost.localdomain>
 <CAFaUHvKEZ5ht-jCpQUe7sVFsU16swMJ4=sBnedhi56d+cke2+g@mail.gmail.com>
Message-ID: <16729370.szb07cveKC@apollo>

On Thursday, 19 November 2020 19:30:38 GMT Sudipto Mallick wrote:
> What do you think about this alternate format?

> I think this is more human readable. And that --- gemini feed --- or

It's human readable yeh, but is this not _just as hard_ as atom to parse?

Having the information line-by-line ( link by link in this case) keeps parsing 
insanely simple. 

- Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201119/31c9a72e/attachment.sig>

From seirdy at seirdy.one  Thu Nov 19 19:42:12 2020
From: seirdy at seirdy.one (Rohan Kumar)
Date: Thu, 19 Nov 2020 11:42:12 -0800
Subject: Again on feeds in Gemini format
In-Reply-To: <C77H653ZK56Z.1QCPYJBV26TEE@stilgar>
References: <C77GOATAGFX1.1U0RBM0ZP5LEF@taiga>
 <C77H653ZK56Z.1QCPYJBV26TEE@stilgar>
Message-ID: <20201119194212.vuu4ger3bzd3fmad@rkumar-dekstop>

On Thu, Nov 19, 2020 at 08:08:35PM +0100, Solderpunk wrote:
>It doesn't scale [...] CAPCOM will become an indigestible fire hose.  
>People will start following only their own small set of feeds, and once 
>that happens the probability that you see anything other than a small 
>random slice of the conversation becomes very small and the whole thing 
>breaks even if posts appear in precisely the right order.
Agreed; I think that we should split feeds into two use-cases: personal 
use for receiving new content from selected gemlogs (RSS/ATOM or 
similar), and discovery of new content. For the latter, I think 
blogrolls/gemrings are the way to go. Thoughts?

(Also my neomutt config on this machine was out of date, and I've been 
sending the wrong FROM: header this whole time. Ugh.)

/Seirdy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201119/3579693e/attachment-0001.sig>

From solderpunk at posteo.net  Thu Nov 19 19:42:42 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Thu, 19 Nov 2020 20:42:42 +0100
Subject: Again on feeds in Gemini format
In-Reply-To: <20201119190956.GA18856@localhost.localdomain>
Message-ID: <C77HW9UVIJ0N.1WZNNXW7C5REQ@stilgar>

On Thu Nov 19, 2020 at 8:09 PM CET, marc wrote:

> Would it be useful to include something which tells
> the software polling the feed when the next post could
> be expected ? It doesn't imply an obligation, it is
> just a hint...

...

> Maybe just the first/last link (pointing nowhere, or
> to itself or some other distinguished name) with a timestamp
> in the future could tell us when to poll again,

This would ruin the human-readability of the page, though.  I would much
rather we just included a recommendation that pages not be polled more
than two or three times a day.

I do think it would be neat if feed readers tried to learn this
themselves, by taking note of how often polls result in something new...

Cheers,
Solderpunk


From mailinglists at ngalt.com  Thu Nov 19 23:51:43 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Thu, 19 Nov 2020 15:51:43 -0800
Subject: "ISO 8601" nitpick (was: Re: Again on feeds in Gemini format)
In-Reply-To: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
Message-ID: <208C6D03-E10E-4BB7-92F1-FE87D6007459@ngalt.com>



> On Nov 19, 2020, at 7:44 AM, Solderpunk <solderpunk at posteo.net> wrote:
> 
> I would argue strongly in favour of
> supporting only a single format, namely the ISO 8601 format (in which
> today is 2020-11-19).

You mean like 2020-11-19T23:48:17Z? Maybe including milliseconds, too? Or maybe something like 2020-11-19T15:49:57-0800?

I remember seeing a list of "ISO 8601" formats that this one newsreader had to deal with. The list of formats was about a dozen elements long.

From seirdy at seirdy.one  Fri Nov 20 00:19:42 2020
From: seirdy at seirdy.one (Rohan Kumar)
Date: Thu, 19 Nov 2020 16:19:42 -0800
Subject: "ISO 8601" nitpick (was: Re: Again on feeds in Gemini format)
In-Reply-To: <208C6D03-E10E-4BB7-92F1-FE87D6007459@ngalt.com>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
 <208C6D03-E10E-4BB7-92F1-FE87D6007459@ngalt.com>
Message-ID: <20201120001942.zu33mdfsdde473bz@rkumar-dekstop>

On Thu, Nov 19, 2020 at 03:51:43PM -0800, Nathan Galt wrote:
>> On Nov 19, 2020, at 7:44 AM, Solderpunk <solderpunk at posteo.net> 
>> wrote:
>>
>> I would argue strongly in favour of
>> supporting only a single format, namely the ISO 8601 format (in which
>> today is 2020-11-19).
>
>You mean like 2020-11-19T23:48:17Z? Maybe including milliseconds, too?  
>Or maybe something like 2020-11-19T15:49:57-0800?
>
>I remember seeing a list of "ISO 8601" formats that this one newsreader 
>had to deal with. The list of formats was about a dozen elements long.

It might be a better idea to use RFC 3339, a profile of the ISO 8601 
date format.  See https://tools.ietf.org/html/rfc3339.
It was also mentioned in the Wikipedia article for ISO 8601: 
https://en.wikipedia.org/wiki/ISO_8601. Its main difference, according 
to section 5.6 of the spec:

>NOTE: ISO 8601 defines date and time separated by "T".
>Applications using this syntax may choose, for the sake of
>readability, to specify a full-date and full-time separated by
>(say) a space character.

It also has a provision for unknown local offsets:

>If the time in UTC is known, but the offset to local time is unknown,
>this can be represented with an offset of "-00:00".  This differs
>semantically from an offset of "Z" or "+00:00", which imply that UTC
>is the preferred reference point for the specified time.  RFC2822
>[IMAIL-UPDATE] describes a similar convention for email.

If you aren't familiar with either format but you have GNU date 
installed, you can give them both a spin. For ISO 8601:

	date -I{date,hours,minutes,seconds,ns}

For RFC 3339:

	date --rfc-3339={date,seconds,ns}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201119/7659be57/attachment.sig>

From emilis at emilis.net  Fri Nov 20 01:58:26 2020
From: emilis at emilis.net (Emilis)
Date: Fri, 20 Nov 2020 03:58:26 +0200
Subject: Again on feeds in Gemini format
In-Reply-To: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
References: <C77CTKZB05Z0.2W444SW8X2PG2@stilgar>
Message-ID: <2e4883d3-1c39-373d-03dd-27af29c75dc2@emilis.net>

On 11/19/20 5:44 PM, Solderpunk wrote:
> * The text of the first heading line (e.g. # My gemlog) to appear in the
>    document is equivalent to the <feed><title> element of an Atom feed.
>    All other heading lines are ignored.
> * All other lines which are not link lines are ignored.
> * All link lines with labels where the first whitespace-separated
>    component of the label is a recognised datestamp are treated as
>    equivalent to an Atom <entry> element, where:
>      - The link's URL provides <entry><link>
>      - The datestamp provides <entry><updated>
>      - The content of the label after the datestamp provides
>        <entry><title>
> * All other link lines are ignored

So I went and updated my aggregator code to match this format. Then went 
to SpaceWalk to look for pages to parse.

The output:
gemini://tilde.team/~emilis/aggregated-test.gmi

The code:
https://tildegit.org/emilis/gmi-feed-aggregator

Some notes:

1. I added support for relative URLs to my aggregator. At the moment it 
became the most complex part of the code.

2. Due to relative URL support it is possible to just parse Home/index 
pages of some of the gemlogs -- no separate feed file is needed.

3. Some gemlogs are missing the h1 or it is too generic ("Blog", 
"Updates"). I skipped those.

4. Some gemlogs have characters added to date. E.g. "2020-11-19: And 
then the title". I had to skip these too.

5. I removed the timestamps from link text and prefixed the feed-titles 
to the entry-titles to separate between sources. Seems OK, but one may 
need to hover over the link to be sure of where the link is coming from. 
I think I could add hostnames to link text. Not sure if link text will 
become too long.


--
Emilis Dambauskas


From etienne at depar.is  Fri Nov 20 09:23:44 2020
From: etienne at depar.is (=?utf-8?Q?=C3=89tienne?= Deparis)
Date: Fri, 20 Nov 2020 10:23:44 +0100
Subject: [ANN] Hello world! New gemininaut there :)
Message-ID: <87k0ugz8in.fsf@depar.is>

Hi all!

I first heard about Gemini a week ago and agree all of its manifesto. I
love it so much I immediatly began to work on some implementation for
it. I must admit, as a ruby developer, having a new ecosystem where
??gem?? is a corner stone is quite exciting ;)

Thus, I can confirm the Gemini motto ??every one should be able to
release an MVP over a week-end??: I quickly wrote two new Ruby gem to
give tools to other ruby devs.

- ruby-net-text, which is an addendum to the standard Net::* and URI::*
  libs to support the Gemini protocol
- diamant, which is a Gemini server in ruby, already powering my own
  capsule.

=> gemini://alltext.umaneti.net/ My little capsule in the gemini space
=> gemini://alltext.umaneti.net/ruby-net-text.gmi ruby-net-text page
=> https://git.umaneti.net/ruby-net-text/ ruby-net-text git repository
=> gemini://alltext.umaneti.net/diamant.gmi diamant page
=> https://git.umaneti.net/diamant/ diamant git repository

It?s a pleasure to build a whole new space on clean roots, having
privacy and simplicity in mind. A space where we are not just users or
consumers, but actors.

Have all a good day,

--
?tienne Deparis

https://etienne.depar.is/
xmpp: etienne at depar.is

From cbabcock at asciiking.com  Fri Nov 20 09:33:57 2020
From: cbabcock at asciiking.com (cbabcock at asciiking.com)
Date: Fri, 20 Nov 2020 09:33:57 +0000
Subject: Again on feeds in Gemini format
In-Reply-To: <C77H653ZK56Z.1QCPYJBV26TEE@stilgar>
References: <C77H653ZK56Z.1QCPYJBV26TEE@stilgar>
Message-ID: <2de86570507ea3edec61887d7b30585f@asciiking.com>

November 19, 2020 12:08 PM, "Solderpunk" <solderpunk at posteo.net> wrote:

> On Thu Nov 19, 2020 at 7:45 PM CET, Drew DeVault wrote:
> 
>> This has been rubbing me the wrong way for a while now, and I mentioned
>> it here:
>> 
>> gemini://drewdevault.com/2020/11/15/RE-Is-this-aggregator-idea-good.gmi
>> 
>> Gemini is simply not well-suited to discussions like this.
> 
> I'm not sure I agree that gemlog posts written in response to other
> gemlog posts is not a good format, but the idea that something like feed
> aggregation is the best way to follow this kind of discussion, and that
> it should reliably provide a time-ordered list of all contributions to
> the discussion, is clearly problematic. It doesn't scale. It's worked
> quite well so far in both Gopherspace and Geminispace, but only because
> both are so small that services like CAPCOM which follow everything are
> still manageable. If growth continues at current rates this will soon
> start breaking down. CAPCOM will become an indigestible fire hose.
> People will start following only their own small set of feeds, and once
> that happens the probability that you see anything other than a small
> random slice of the conversation becomes very small and the whole thing
> breaks even if posts appear in precisely the right order.

You can't always give everyone what they want, but this might be an exception. Use date-only on the original post. Use T and time - minute granularity, author is responsible for converting to UTC, no TZ indicator needed or allowed (in the spirit of 'we use this spec, but not all of it') - when referencing a reply. Original posts will always sort ahead of replies, while replies generally sort in order and can be easily removed from a feed

Chris

From jmcbray at carcosa.net  Fri Nov 20 18:05:37 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 20 Nov 2020 13:05:37 -0500
Subject: Again on feeds in Gemini format
In-Reply-To: <C77GGW8LU960.13IF0G5GFMV1@stilgar> (solderpunk@posteo.net's
 message of "Thu, 19 Nov 2020 19:35:36 +0100")
References: <C77GGW8LU960.13IF0G5GFMV1@stilgar>
Message-ID: <87wnyfdhu6.fsf@dorothy.carcosa.net>

"Solderpunk" <solderpunk at posteo.net> writes:

> So, I think we'll probably be just fine with date stamps only.

Fair. A feed reader application that wanted to reconstruct reply-to
information could use GUS to do it.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Fri Nov 20 18:08:26 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 20 Nov 2020 13:08:26 -0500
Subject: Again on feeds in Gemini format
In-Reply-To: <C77HW9UVIJ0N.1WZNNXW7C5REQ@stilgar> (solderpunk@posteo.net's
 message of "Thu, 19 Nov 2020 20:42:42 +0100")
References: <C77HW9UVIJ0N.1WZNNXW7C5REQ@stilgar>
Message-ID: <87sg93dhph.fsf@dorothy.carcosa.net>

"Solderpunk" <solderpunk at posteo.net> writes:

> This would ruin the human-readability of the page, though.  I would much
> rather we just included a recommendation that pages not be polled more
> than two or three times a day.
>
> I do think it would be neat if feed readers tried to learn this
> themselves, by taking note of how often polls result in something new...

You could probably just use exponential back-off for this, without
the feed reader really having to 'learn' anything.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From me at ecmelberk.com  Fri Nov 20 18:21:08 2020
From: me at ecmelberk.com (=?utf-8?q?Ecmel_Berk_Canl=C4=B1er?=)
Date: Fri, 20 Nov 2020 21:21:08 +0300
Subject: [ANN] seirdy.one live on Geminispace (+questions)
In-Reply-To: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
References: <20201119070810.z2gu23atxtwofkm5@rkumar-dekstop>
Message-ID: <C78ASCW6L8EU.1E0O8LFT9S97O@fistik>

> I also set up a mailing list on Sourcehut (like, just now) to leave
> comments.  I've linked the mailing list at the bottom of my weblog
> entries,

Thinking about it, I should do that too.

> One last question: Gemininauts (please oh please let that be a word)
> with twinlogs, how do you decide what to cross-post and what to keep
> {WWW,gemini,gopher}-exclusive? I'm leaning towards keeping my weblog
> more "professional" and my gemlog less filtered, [...] I'm curious
> to know how you all handle this.

I separate my posts into three (for now, at least) categories, being
"experiments", "posts" and "micro logs".

Experiments are where I mess around with Gemini/Gemtext, so it only
makes sense for them to be Gemini-exclusive.

"Micro Logs" are stuff I post every now and then that contain
(sometimes multiple) short posts that I feel are too short for normal
posts. These are also Gemini-exclusive.

"Posts", are the (somewhat) more polished stuff I write. They are
accessible via HTTP "by default", but for some stuff I will intentionally
make them Gemini-exclusive, depending on their content.

(I also have "reply" posts (just one for now). They are also
Gemini-exclusive by nature)

"Posts" are actually special, in that they will always have HTML versions
available, even if not listed. This was originally a bug until I decided
it could be great for sharing and turned it into a feature.

Everything I talked about also gets uploaded into a public Git repo and
both versions of the site get built from the same sources, with HTML
being the "afterthought" (All posts are written in Gemtext)

https://git.ebc.li/admicos/blog

> leaving the shortest bits for the Fediverse.

I have a CGI script to show the most recent (20 i think) fediverse
messages I posted as Gemtext. It might be useful for you too, assuming
you can run Python CGI scripts in your server:

https://git.ebc.li/admicos/blog/src/branch/main/cgi/thoughts.py

It should work on any reasonably modern version of Python assuming
`requests` is installed.

--
Have a nice /(day|night|week(end)?)/
~ Ecmel B. Canl?er

From cowan at ccil.org  Fri Nov 20 18:56:11 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 20 Nov 2020 13:56:11 -0500
Subject: On input and uploading of user content
In-Reply-To: <CAJScK0J80X6wNQOe0Zu5AV1Z4t6c5agEEm1WcCwj9uRe+yHSig@mail.gmail.com>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
 <87eekt84ol.fsf@disroot.org>
 <f749c381ad9f4aaa9f44866ad74bd4a9143939dd.camel@gmail.com>
 <CAJScK0J80X6wNQOe0Zu5AV1Z4t6c5agEEm1WcCwj9uRe+yHSig@mail.gmail.com>
Message-ID: <CAD2gp_R=ZpMOAqLg05AC9=R1Lo66oosJ+SFQ_XinzZTAyrSbZw@mail.gmail.com>

Minor correction:

Titan is a PUT protocol that can send something to a server.  Dioscuri is a
true POST protocol: you send something to the server, and then you get
either a response or an URL pointing to the true response (thanks to the
magic of MIME-type message/external-body).  Dioscuri isn't really intended
as a file-upload protocol, though it could be used that way, but as an
application protocol for requests that won't fit into an URL.  It is in no
way intended for use with forms, but with specialized clients.


On Thu, Nov 19, 2020 at 12:56 PM Bj?rn W?rmedal <bjorn.warmedal at gmail.com>
wrote:

> Hi,
>
> I compiled a bunch of arguments on this subject in two posts on my
> gemlog not long ago:
> gemini://tilde.team/~ew0k/gemini-and-post.gmi
> gemini://tilde.team/~ew0k/gemini-and-post-part2.gmi
>
> The tl;dr of it is that there is no standardized way of
> posting/uploading content in geminispace, and you are encouraged to
> design a solution that works best for your use case.
>
> Cheers,
> ew0k
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201120/70f95ba0/attachment.htm>

From me at adnano.co  Fri Nov 20 20:07:44 2020
From: me at adnano.co (Adnan Maolood)
Date: Fri, 20 Nov 2020 15:07:44 -0500
Subject: [ANN] kiln - a static site generator for Gemini sites
Message-ID: <C78D1ZBT37BE.33S3W0I0PM8PK@nitro>

Hello,

I made a static site generator for Gemini sites.
Currently, it supports the following:

- Go templating
- Generating Gemini feeds
- Optionally outputting your site as HTML

You can find it at https://sr.ht/~adnano/kiln

Enjoy!

From etienne at depar.is  Fri Nov 20 21:21:04 2020
From: etienne at depar.is (=?utf-8?Q?=C3=89tienne?= Deparis)
Date: Fri, 20 Nov 2020 22:21:04 +0100
Subject: [ANN] Hello world! New gemininaut there :)
In-Reply-To: <C78DLEYG9ZCO.3EPLCFO88IOGH@tigger-mp>
References: <87k0ugz8in.fsf@depar.is> <C78DLEYG9ZCO.3EPLCFO88IOGH@tigger-mp>
Message-ID: <87o8jrvi67.fsf@depar.is>

ven. 20 nov. 2020 ? 21:33, jonas-mueller at mailbox.org a ?crit?:

> Hi Etienne,
>
> just in case you are interested - here is my take on Gemini in Ruby:
>
> https://git.sr.ht/~muellerj/gemini-rb

Oh, that?s very interesting. I don?t find them during my first
look. I very like your KnownHostStore class and may reuse it in my
server: I certainly miss a lot of thing in my implementation. Your class
just make me saw that I don?t check the certificate date validity?

Thank you very much for showing your work to me!

Have a good week-end

--
?tienne Deparis

https://etienne.depar.is/
xmpp: etienne at depar.is

From gemini at mmn.name  Sat Nov 21 01:55:56 2020
From: gemini at mmn.name (=?UTF-8?Q?K=c3=a9vin_=28Gemini_List=29?=)
Date: Sat, 21 Nov 2020 02:55:56 +0100
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <C78D1ZBT37BE.33S3W0I0PM8PK@nitro>
References: <C78D1ZBT37BE.33S3W0I0PM8PK@nitro>
Message-ID: <c7226c8a-3206-dca6-c0ce-9045b78d1d71@mmn.name>

Hey Adnan,

I've just downloaded and gave it a go, it looks like a good option for
me to avoid duplicating my blog on the web and the content I want to
post to my capsule.

But I've run into a bit of a snag, since my choice of Gemini server
doesn't redirect /dir to /dir/ so I'm getting errors on the gemini
content.? Is there a way to change that in the output for kiln ?? I
imagine I'm missing something obvious in the template file...

Thanks !

-K?vin

Le 20/11/2020 ? 21:07, Adnan Maolood a ?crit?:
> Hello,
>
> I made a static site generator for Gemini sites.
> Currently, it supports the following:
>
> - Go templating
> - Generating Gemini feeds
> - Optionally outputting your site as HTML
>
> You can find it at https://sr.ht/~adnano/kiln
>
> Enjoy!

From me at adnano.co  Sat Nov 21 02:53:15 2020
From: me at adnano.co (Adnan Maolood)
Date: Fri, 20 Nov 2020 21:53:15 -0500
Subject: Designing a simpler alternative to TLS
Message-ID: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>

I've been working on a simpler alternative to TLS, mostly for fun and
also as a learning excersize to have a better understanding of how TLS
works.

You can find it here:
https://sr.ht/~adnano/miso/

Obviously this has not undergone any security audits, so don't use it
for anything serious.

Biggest differences from TLS:

- No certificate authorities; use TOFU instead
- No version negotiation
- No session resumption
- Encrypted server name indication
- Much simpler

Let me know what you think!

From benulo at systemli.org  Sat Nov 21 07:07:51 2020
From: benulo at systemli.org (Ben)
Date: Sat, 21 Nov 2020 10:37:51 +0330
Subject: Designing a simpler alternative to TLS
In-Reply-To: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
References: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
Message-ID: <b72c52e5-9945-76ed-908b-25ad11406f56@systemli.org>

It would be cool if Gemini dumped TLS and went with something simpler, 
but on the other hand it would make Gemini software a lot harder to 
implement since there's lots of TLS libraries out there for developers 
to use, whereas if we make a new thing (GLS?) code needs to be written 
in many different languages to support it.

On the other hand, if it's simple enough, implementing functions or a 
library in your language of choice might not be too far-fetched.

Ben

-- 
gemini://kwiecien.us/

From sean at conman.org  Sat Nov 21 08:30:22 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 21 Nov 2020 03:30:22 -0500
Subject: Designing a simpler alternative to TLS
In-Reply-To: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
References: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
Message-ID: <20201121083022.GA9837@brevard.conman.org>

It was thus said that the Great Adnan Maolood once stated:
> I've been working on a simpler alternative to TLS, mostly for fun and also
> as a learning excersize to have a better understanding of how TLS works.
> 
> You can find it here:
> https://sr.ht/~adnano/miso/
> 
> Obviously this has not undergone any security audits, so don't use it for
> anything serious.
> 
> Biggest differences from TLS:
> 
> - No certificate authorities; use TOFU instead
> - No version negotiation
> - No session resumption
> - Encrypted server name indication
> - Much simpler
> 
> Let me know what you think!

  First off, the specification does not give enough detail to actually
implement the protocol.  There's nothing about the wire format, and I had to
check the implementation to see you are using BARE message Encoding [1], yet
*another* encoding scheme like JSON, BSON, CBOR, MsgPack, CapnProto,
Protobuf, etc. etc. [2]

  Second, TLS libraries come with the cryptographic primitives required, and
yes, there is negotiation that happens, but that's because as cryptographic
primitives are broken, new ones can be slotted in and used.  Here, if (and
it could happen) Ed25519 is "broken" then what?  At least with several
supported primitives, the protocol can still be used while the broken
primitive is removed.

  Even so, anyone attempting to implement Ed25519 is a fool for the pitfalls
are subtle and *will* be exploited; I'm guessing you are assuming the use of
libsodium (or God help you, libnacl) with this protocol, right?

  I'm no crytographic expert, but I don't see how this protocol prevents
MITM attacks; the details in the key share (section 2.2.1) don't go into
enough detail for my liking.  How do I know I'm talking to the server in
question, and not being invisibly proxied by Eve or Mal?  And how does each
side determine an insecure key share?  What exactly goes over the wire?

  Also, some pseudocode would be nice as not everybody knows Go.

  -spc

[1]	https://baremessages.org/

[2]	Groan.

From linde.philip at gmail.com  Sat Nov 21 10:29:49 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sat, 21 Nov 2020 11:29:49 +0100
Subject: Designing a simpler alternative to TLS
In-Reply-To: <20201121083022.GA9837@brevard.conman.org>
References: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
 <20201121083022.GA9837@brevard.conman.org>
Message-ID: <20201121112949.f2225a730477fd954038290f@gmail.com>

On Sat, 21 Nov 2020 03:30:22 -0500
Sean Conner <sean at conman.org> wrote:

>   I'm no crytographic expert, but I don't see how this protocol prevents
> MITM attacks; the details in the key share (section 2.2.1) don't go into
> enough detail for my liking.  How do I know I'm talking to the server in
> question, and not being invisibly proxied by Eve or Mal?  And how does each
> side determine an insecure key share?  What exactly goes over the wire?

It seems to prevent this only to the same extent that the Gemini TOFU
(mis-)use of TLS does. First, ephemeral keys are generated and the
public keys are exchanged. The rest of communication is encrypted
using these keys. The server then sends the client an Authentication
message which contains the certificate and a corresponding signature of
the ephemeral public keys. The client verifies that the signature of the
public keys is correct according to the public key of the certificate.

You could then just pin that certificate on first use if you trust that
there is not a man in the middle at that moment. From that point, you
can verify that it's the same certificate in all future exchanges. This
is a weakness, but in principle the same weakness exists in the use of
self-signed non-preshared certificates in Gemini.

I think it's an interesting exercise, however unlikely to replace the
use of TLS in Gemini. For Gemini, I'd much rather see conventions for
peer verification of certificates where servers can share lists of
certificates they use for different hosts, and self-revocation lists
that contained self-signed revocation messages whereby a certificate
can revoke itself.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201121/d69f00dc/attachment.sig>

From ehmry at posteo.net  Sat Nov 21 10:55:05 2020
From: ehmry at posteo.net (Emery)
Date: Sat, 21 Nov 2020 11:55:05 +0100
Subject: Designing a simpler alternative to TLS
In-Reply-To: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
References: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
Message-ID: <bf4a61ff-1bc8-4b89-a6d6-2cca81dc4f9c@posteo.net>

This is a problem solved many times over. You will need to do better than
the Noise protocol, which is the most compelling alternative to TLS.

http://noiseprotocol.org/
https://noiseexplorer.com/

https://verifpal.com/ - Formal proofs or GTFO

E.

From gmi1 at scotdoyle.com  Sat Nov 21 13:31:02 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Sat, 21 Nov 2020 07:31:02 -0600
Subject: Designing a simpler alternative to TLS
In-Reply-To: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
References: <C78LOGPPM1MM.2X3YNRGE8LO5E@nitro>
Message-ID: <4ece57fe-b0e9-d29f-62eb-826ab1a8fa71@scotdoyle.com>

On 11/20/20 8:53 PM, Adnan Maolood wrote:
> I've been working on a simpler alternative to TLS, mostly for fun and
> also as a learning excersize to have a better understanding of how TLS
> works.
>
> You can find it here:
> https://sr.ht/~adnano/miso/
>
> Obviously this has not undergone any security audits, so don't use it
> for anything serious.
>
> Biggest differences from TLS:
>
> - No certificate authorities; use TOFU instead
> - No version negotiation
> - No session resumption
> - Encrypted server name indication
> - Much simpler
>
> Let me know what you think!

# 2.1 Protocol Overview
Application Data:
   C <- Status 0 <- S
   C <- App Data <- S
   C -> Status 0 -> S
   C -> App Data -> S
   ...
   C <- Status 1 <- S
   -- Connection closed


## 2.4 Close Notify
The client and server MUST send the status code FINISHED before closing the connection.


2.1 shows only the server sending a 'finished' status, but 2.4 says both sides must do so?


From jonas-mueller at mailbox.org  Fri Nov 20 20:33:07 2020
From: jonas-mueller at mailbox.org (=?utf-8?q?Jonas_M=C3=BCller?=)
Date: Fri, 20 Nov 2020 21:33:07 +0100
Subject: [ANN] Hello world! New gemininaut there :)
In-Reply-To: <87k0ugz8in.fsf@depar.is>
Message-ID: <C78DLEYG9ZCO.3EPLCFO88IOGH@tigger-mp>

Hi Etienne,

just in case you are interested - here is my take on Gemini in Ruby:

https://git.sr.ht/~muellerj/gemini-rb

Kind regards,
Jonas


On Fri Nov 20, 2020, ?tienne Deparis wrote:
> Hi all!
>
> I first heard about Gemini a week ago and agree all of its manifesto. I
> love it so much I immediatly began to work on some implementation for
> it. I must admit, as a ruby developer, having a new ecosystem where
> ? gem ? is a corner stone is quite exciting ;)
>
> Thus, I can confirm the Gemini motto ? every one should be able to
> release an MVP over a week-end ?: I quickly wrote two new Ruby gem to
> give tools to other ruby devs.
>
> - ruby-net-text, which is an addendum to the standard Net::* and URI::*
> libs to support the Gemini protocol
> - diamant, which is a Gemini server in ruby, already powering my own
> capsule.
>
> => gemini://alltext.umaneti.net/ My little capsule in the gemini space
> => gemini://alltext.umaneti.net/ruby-net-text.gmi ruby-net-text page
> => https://git.umaneti.net/ruby-net-text/ ruby-net-text git repository
> => gemini://alltext.umaneti.net/diamant.gmi diamant page
> => https://git.umaneti.net/diamant/ diamant git repository
>
> It?s a pleasure to build a whole new space on clean roots, having
> privacy and simplicity in mind. A space where we are not just users or
> consumers, but actors.
>
> Have all a good day,
>
> --
> ?tienne Deparis
>
> https://etienne.depar.is/
> xmpp: etienne at depar.is


From mail at talon.computer  Sat Nov 21 02:05:31 2020
From: mail at talon.computer (Talon)
Date: Sat, 21 Nov 2020 02:05:31 +0000
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <c7226c8a-3206-dca6-c0ce-9045b78d1d71@mmn.name>
References: <C78D1ZBT37BE.33S3W0I0PM8PK@nitro>
 <c7226c8a-3206-dca6-c0ce-9045b78d1d71@mmn.name>
Message-ID: <UtjrUMKNrDAKjx_zsmfUnnc3dAVhyEkdqtW3_VqsFizjhiQj9apWs5ZSpaCBMIwzO8_cjmYwjU8bu7rn2LKqyBer98rhEORd8SoPMXuh1QU=@talon.computer>

I also had this problem and I updated the template directly to add the 

trailing slash. Should probably be fixed upstream in .Path though.

Love this project BTW. Just updated from about a month ago. 

Everything I was  having friction with before is resolved! I'm curious 

if the standard for .gmi feeds is published and if I can still create 

an atom.xml?

- talon

??????? Original Message ???????
On Friday, November 20, 2020 6:55 PM, K?vin <gemini at mmn.name> wrote:

> Hey Adnan,
> 

> I've just downloaded and gave it a go, it looks like a good option for
> me to avoid duplicating my blog on the web and the content I want to
> post to my capsule.
> 

> But I've run into a bit of a snag, since my choice of Gemini server
> doesn't redirect /dir to /dir/ so I'm getting errors on the gemini
> content.? Is there a way to change that in the output for kiln ?? I
> imagine I'm missing something obvious in the template file...
> 

> Thanks !
> 

> -K?vin
> 

> Le 20/11/2020 ? 21:07, Adnan Maolood a ?crit?:
> 

> > Hello,
> > I made a static site generator for Gemini sites.
> > Currently, it supports the following:
> > 

> > -   Go templating
> > -   Generating Gemini feeds
> > -   Optionally outputting your site as HTML
> > 

> > You can find it at https://sr.ht/~adnano/kiln
> > Enjoy!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - mail at talon.computer - 0x5B3DC486.asc
Type: application/pgp-keys
Size: 728 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201121/d8c40502/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201121/d8c40502/attachment.sig>

From gemini at mmn.name  Sat Nov 21 14:34:58 2020
From: gemini at mmn.name (=?UTF-8?Q?K=c3=a9vin_=28Gemini_List=29?=)
Date: Sat, 21 Nov 2020 15:34:58 +0100
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <UtjrUMKNrDAKjx_zsmfUnnc3dAVhyEkdqtW3_VqsFizjhiQj9apWs5ZSpaCBMIwzO8_cjmYwjU8bu7rn2LKqyBer98rhEORd8SoPMXuh1QU=@talon.computer>
References: <C78D1ZBT37BE.33S3W0I0PM8PK@nitro>
 <c7226c8a-3206-dca6-c0ce-9045b78d1d71@mmn.name>
 <UtjrUMKNrDAKjx_zsmfUnnc3dAVhyEkdqtW3_VqsFizjhiQj9apWs5ZSpaCBMIwzO8_cjmYwjU8bu7rn2LKqyBer98rhEORd8SoPMXuh1QU=@talon.computer>
Message-ID: <481773be-8c25-095a-65cd-4f9c3417aebd@mmn.name>

Le 21/11/2020 ? 03:05, Talon a ?crit?:

> I also had this problem and I updated the template directly to add the 
>
> trailing slash. Should probably be fixed upstream in .Path though.

I knew it was something obvious, I think I over complicated by fix and
made it barf everywhere with errors, but it's now sorted, thanks !

> Love this project BTW. Just updated from about a month ago. 

Honestly, same here it's everything I've been looking for but never
realise I've needed until now.

-K?vin


From me at adnano.co  Sat Nov 21 14:42:20 2020
From: me at adnano.co (Adnan Maolood)
Date: Sat, 21 Nov 2020 09:42:20 -0500
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <UtjrUMKNrDAKjx_zsmfUnnc3dAVhyEkdqtW3_VqsFizjhiQj9apWs5ZSpaCBMIwzO8_cjmYwjU8bu7rn2LKqyBer98rhEORd8SoPMXuh1QU=@talon.computer>
Message-ID: <C790RDV74L0K.2B8VNGL02LBZ0@nitro>

On Fri Nov 20, 2020 at 9:05 PM EST, Talon wrote:
> I also had this problem and I updated the template directly to add the
> trailing slash. Should probably be fixed upstream in .Path though.
> Love this project BTW. Just updated from about a month ago.
> Everything I was having friction with before is resolved! I'm curious
> if the standard for .gmi feeds is published and if I can still create
> an atom.xml?

The Gemini feed standard was discussed on the mailing list a few days
ago.

I removed support for atom feeds in the last update, but if it's a
popular request then I can add them back.

From colecmac at protonmail.com  Sat Nov 21 17:57:18 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 21 Nov 2020 17:57:18 +0000
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <C790RDV74L0K.2B8VNGL02LBZ0@nitro>
References: <C790RDV74L0K.2B8VNGL02LBZ0@nitro>
Message-ID: <AEYxzsO8tRfmy3uM8S7quPE-KYNX1B0UHLQ7CYftXgrO5ePn-hs214ShyRcNBbkmX7Q_FfRv_HKKtSgBQYbswi0fWvZeQqmuE4SSP62tOp0=@protonmail.com>

> I removed support for atom feeds in the last update, but if it's a
> popular request then I can add them back.

Definitely you should add it back! I don't see Atom feeds going anyway
any time soon, especially since the Gemini feed is only an idea and not
standardized yet. Even when it is, Atom is still useful. I don't see
why there's any need to remove it.

Cool project!


Cheers,
makeworld



From me at adnano.co  Sat Nov 21 17:57:38 2020
From: me at adnano.co (Adnan Maolood)
Date: Sat, 21 Nov 2020 12:57:38 -0500
Subject: Designing a simpler alternative to TLS
In-Reply-To: <bf4a61ff-1bc8-4b89-a6d6-2cca81dc4f9c@posteo.net>
Message-ID: <C794WWVWNNB3.3IUQXRICLOIB9@nitro>

On Sat Nov 21, 2020 at 5:55 AM EST, Emery wrote:
> This is a problem solved many times over. You will need to do better
> than
> the Noise protocol, which is the most compelling alternative to TLS.
>
> http://noiseprotocol.org/
> https://noiseexplorer.com/
>
> https://verifpal.com/ - Formal proofs or GTFO
>

Thanks for the resources! Noise looks interesting indeed.

From me at adnano.co  Sat Nov 21 18:52:44 2020
From: me at adnano.co (Adnan Maolood)
Date: Sat, 21 Nov 2020 13:52:44 -0500
Subject: Designing a simpler alternative to TLS
In-Reply-To: <20201121083022.GA9837@brevard.conman.org>
Message-ID: <C79633QYW8EG.4OZBP7FHHLTS@nitro>

On Sat Nov 21, 2020 at 3:30 AM EST, Sean Conner wrote:
> First off, the specification does not give enough detail to actually
> implement the protocol. There's nothing about the wire format, and I had
> to
> check the implementation to see you are using BARE message Encoding [1],
> yet
> *another* encoding scheme like JSON, BSON, CBOR, MsgPack, CapnProto,
> Protobuf, etc. etc. [2]

The specification is still a very rough draft.

> Second, TLS libraries come with the cryptographic primitives required,
> and
> yes, there is negotiation that happens, but that's because as
> cryptographic
> primitives are broken, new ones can be slotted in and used. Here, if
> (and
> it could happen) Ed25519 is "broken" then what? At least with several
> supported primitives, the protocol can still be used while the broken
> primitive is removed.

If Ed25519 is broken, then it would be considered insecure, and a new
KeyShare message could be added in a backwards-compatible way.

> Even so, anyone attempting to implement Ed25519 is a fool for the
> pitfalls
> are subtle and *will* be exploited; I'm guessing you are assuming the
> use of
> libsodium (or God help you, libnacl) with this protocol, right?

Yes, I assume that you would not implement the cryptography yourself.

> I'm no crytographic expert, but I don't see how this protocol prevents
> MITM attacks; the details in the key share (section 2.2.1) don't go into
> enough detail for my liking. How do I know I'm talking to the server in
> question, and not being invisibly proxied by Eve or Mal?

MITM protection is covered in section 2.2.4. Essentially, the server
signs the key share messages with its certificate private key, and the
client verifies this signature.

> And how does each
> side determine an insecure key share? What exactly goes over the wire?

A key share would be insecure if it is later "broken" as you said.

I don't expect anyone to use this instead of TLS, it is mostly just for
educational purposes and to gather ideas of what a simpler TLS could
look like.

From me at adnano.co  Sat Nov 21 19:14:29 2020
From: me at adnano.co (Adnan Maolood)
Date: Sat, 21 Nov 2020 14:14:29 -0500
Subject: Designing a simpler alternative to TLS
In-Reply-To: <4ece57fe-b0e9-d29f-62eb-826ab1a8fa71@scotdoyle.com>
Message-ID: <C796JRASC8L7.2RASMKPQOXGM1@nitro>

On Sat Nov 21, 2020 at 8:31 AM EST, Scot wrote:
> # 2.1 Protocol Overview
> Application Data:
> C <- Status 0 <- S
> C <- App Data <- S
> C -> Status 0 -> S
> C -> App Data -> S
> ...
> C <- Status 1 <- S
> -- Connection closed
>
> 2.1 shows only the server sending a 'finished' status, but 2.4 says both
> sides must do so?

Only one side has to send the status code for the connection to be
closed. I'll clarify that in the specification.

From zachdecook at librem.one  Sat Nov 21 22:31:03 2020
From: zachdecook at librem.one (Zach DeCook)
Date: Sat, 21 Nov 2020 17:31:03 -0500
Subject: On input and uploading of user content
Message-ID: <C79AQ99A4PJM.22ZCHFP49MBRV@zach-macbookpro121>

In-Reply-To: <f749c381ad9f4aaa9f44866ad74bd4a9143939dd.camel at gmail.com>

> Thanks for the idea, but I wanted to integrate uploading in my app.

Probably not a perfect solution, but one thing I'm going with (for a text-editing application) is having a mailto link for the user to email me. Then, the server just needs to read the email through imap.

Assuming your expected uploads are not larger than the email servers can handle, this should work fine. (You can also check the email address against the email address from the user's certificate for validation)

=> https://git.sr.ht/~earboxer/prosongsa/commit/61ad5c86 Here's a little example I coded up in PHP for editing text files, if you're curious.

-Zach

From cbabcock at asciiking.com  Sat Nov 21 23:02:30 2020
From: cbabcock at asciiking.com (cbabcock at asciiking.com)
Date: Sat, 21 Nov 2020 23:02:30 +0000
Subject: On input and uploading of user content
In-Reply-To: <C79AQ99A4PJM.22ZCHFP49MBRV@zach-macbookpro121>
References: <C79AQ99A4PJM.22ZCHFP49MBRV@zach-macbookpro121>
Message-ID: <712bef296a4a00ce5de9521224e3d9f3@asciiking.com>

> (You can also check the email address against the email address from the user's certificate
> for validation)

You can offer the email address from the certificate as a default for the reader to confirm, refuse, or replace as linked to some notion of an account, but it's necessary to have explicit permission to link the identity of a user to that information... and you shouldn't make any positive assumption about user supplied data, including unsigned or self-signed certificates

Also, don't trust the "From" address in an email. Insist on end to end encryption if the content transmitted is actually sensitive. If the contents aren't actually sensitive, processing is reversible, and volume is sufficiently low, then you can use a token inserted in either the subject or the from address to transmit session information. In either case, a receipt is required for email transactions

Chris

From ranfdev at gmail.com  Sun Nov 22 11:39:11 2020
From: ranfdev at gmail.com (Lorenzo Miglietta)
Date: Sun, 22 Nov 2020 12:39:11 +0100
Subject: On input and uploading of user content
In-Reply-To: <CAJScK0J80X6wNQOe0Zu5AV1Z4t6c5agEEm1WcCwj9uRe+yHSig@mail.gmail.com>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
 <87eekt84ol.fsf@disroot.org>
 <f749c381ad9f4aaa9f44866ad74bd4a9143939dd.camel@gmail.com>
 <CAJScK0J80X6wNQOe0Zu5AV1Z4t6c5agEEm1WcCwj9uRe+yHSig@mail.gmail.com>
Message-ID: <c295601fca16a77938f47e9acccd84e60f7c5d99.camel@gmail.com>

> I compiled a bunch of arguments on this subject in two posts on my
> gemlog not long ago:
> gemini://tilde.team/~ew0k/gemini-and-post.gmi
> gemini://tilde.team/~ew0k/gemini-and-post-part2.gmi

Thank you, these are really great resources!


From solderpunk at posteo.net  Sun Nov 22 16:31:26 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 22 Nov 2020 17:31:26 +0100
Subject: robots.txt for Gemini formalised
Message-ID: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>

Hi folks,

There is now (finally!) an official reference on the use of robots.txt
files in Geminispace.  Please see:

gemini://gemini.circumlunar.space/docs/companion/robots.gmi

I attempted to take into account previous discussions on the mailing
list and the currently declared practices of various well-known Gemini
bots (broadly construed).

I don't consider this "companion spec" to necessarily be finalised at
this point, but I am primarily interested in hearing suggestions for
change from either authors of software which tries to respect robots.txt
who are having problems caused by the current specification, or from
server admins who are having bot problems who feel that the current
specification is not working for them.

The biggest gap that I can currently see is that there is no advice on
how often bots should re-query robots.txt to check for policy changes.
I could find no clear advice on this for the web, either.  I would be
happy to hear from people who've written software that uses robots.txt
with details on what their current practices are in this respect.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Nov 22 17:12:07 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 22 Nov 2020 18:12:07 +0100
Subject: Capping CAPCOM, calling for more aggregators
Message-ID: <C79YKLUH7HSD.3RNUGE6N86F9R@stilgar>

Ahoy!

CAPCOM is currently aggregating 98 feeds from across Geminispace.  I
intend to cap the number of feeds at 100.  The situation is not quite
as urgent as it sounds - I can cull some feeds which haven't
successfully been fetched in a long time because the servers appear to
disappeared, and perhaps I will also remove feeds which have not been
updated in, say, over six months.

My motivation for doing this is to encourage a decentralised
Geminispace.  As software support for the new lightweight subscription
idea increases, it's going to become easier than ever before for people
to decide whose content to follow for themselves, and to set up their
own aggregators - either for their own private use, or as public
instances.

If anybody has been looking for a nice Gemini project to help contribute
to the development of the community, setting up a themed public
aggregator is something worth considering.  You could set up aggregators
of tech gemlogs (or non-tech gemlogs), of political gemlogs (or
non-political gemlogs), gemlogs in non-English languages, gemlogs
written by people in particular parts of the world, gemlogs written by
minority groups whom you'd like to give visibility to, solarpunk
gemlogs, photography gemlogs, whatever you like.  Setting up such
aggregators not only makes it easier for people to find the content they
like, it sends a clear message to would-be content creators that
interest exists, and encourages people to start writing knowing they'll
have an audience.

If you set up a themed public aggregator, feel free to let me know and I
will add links to the main gemini.circumlunar.space in the "Geminispace
aggregators" section after CAPCOM and Spacewalk.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Nov 22 16:40:46 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 22 Nov 2020 17:40:46 +0100
Subject: Lightweight subscription to Gemini pages
Message-ID: <C79XWLKKPI13.1EJVE4J837XND@stilgar>

Howdy Geminauts,

As per recent discussions, I have now published a "companion
specification" for lightweight subscription to Gemini pages which do not
have Atom feeds.  Please see:

gemini://gemini.circumlunar.space/docs/companion/subscription.gmi

I ended up wording some things slightly differently from my earlier
proposal.  Link items now represent feed entires if the first 10
characters of their label match the YYYY-MM-DD format, and their title
is derived from everything after the first whitespace-separated
component (with mention that implementations may clean up separating
hyphens, etc.).  This is slightly more flexible and means that all of
the following label formats will be recognised as entries:

2020-11-22: A post title
2020-11-22  A post title
2020-11-22 - A post title
2020-11-22T17:45:20: A post title
2020-11-22T17:45:20 A post title
2020-11-22T17:45:20 - A post title

Note that the timestamps in the latter three formats will not be
interpreted according to this specification, but since I have actually
seen at least one use of full-blown ISO 8601 timestamps in the wild
it seemed wise to permit them to be recognised as entries.  I don't
expect or encourage people to adopt this style as it results in ugly
pages from the perspective of human readers.

Cheers,
Solderpunk


From colecmac at protonmail.com  Sun Nov 22 18:04:25 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 22 Nov 2020 18:04:25 +0000
Subject: Lightweight subscription to Gemini pages
In-Reply-To: <C79XWLKKPI13.1EJVE4J837XND@stilgar>
References: <C79XWLKKPI13.1EJVE4J837XND@stilgar>
Message-ID: <0ccrG2eAfi6NBfMWbwvgmCqjAULnFm4xjfwqHVutFFE2U26qkncJ0xjCOVD73WGiHI6jdTMxXLByBqVZZfoyHzxNa05hXYZbrvMFGFSveJs=@protonmail.com>

Hello Solderpunk,

Thanks a lot for posting a full spec on this. I will be supporting this format
in Amfora's upcoming subscription feature. Hopefully this will put this
discussion to rest.

> Link items now represent feed entires if the first 10
> characters of their label match the YYYY-MM-DD format, and their title
> is derived from everything after the first whitespace-separated
> component (with mention that implementations may clean up separating
> hyphens, etc.).

Thanks for this fix!


Cheers,
makeworld

From colecmac at protonmail.com  Sun Nov 22 18:15:01 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 22 Nov 2020 18:15:01 +0000
Subject: Capping CAPCOM, calling for more aggregators
In-Reply-To: <C79YKLUH7HSD.3RNUGE6N86F9R@stilgar>
References: <C79YKLUH7HSD.3RNUGE6N86F9R@stilgar>
Message-ID: <bRYQHYKYRMnwHpRA5rVJLsTATgJG3-SIMSh1NmkpjS2NtN_g-tnudYwBjOuWN4tRGsKjqYYV20fgWc7j5FtiAptqrlgN9Zr-z4Z8Bi7O0Wo=@protonmail.com>

One on hand, I think it's too bad that CAPCOM won't work so much as the
defacto homepage, but I understand that this was always a precarious
position as Gemini grows. I will be happy to see more aggregators pop up,
and I think linking to them on CAPCOM's page is 100% the right way to do
it.

On the other side of things, I encourage client authors to add aggregation
to their clients, as I've written about[1]. This is coming in Amfora[2] and
I'm very excited about it. I've been working on it recently.

One thing I'm wondering about this CAPCOM culling is whether favouring the
old gemlogs is a good idea. CAPCOM will become more and more "dated" as time
goes on. Would it be better if periodically CAPCOM updated to tracking the
newest gemlogs in Geminispace? So it would allow new people's capsules and
gemlogs to be discovered. I'm not sure how well this fits with the current
method of emailing you to be added to CAPCOM, but I think it's an interesting
idea.


1: gemini://makeworld.gq/gemlog/2020-08-02-personal-feeds.gmi
2: https://github.com/makeworld-the-better-one/amfora/issues/61


Cheers,
makeworld

From solderpunk at posteo.net  Sun Nov 22 18:04:21 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 22 Nov 2020 19:04:21 +0100
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <AEYxzsO8tRfmy3uM8S7quPE-KYNX1B0UHLQ7CYftXgrO5ePn-hs214ShyRcNBbkmX7Q_FfRv_HKKtSgBQYbswi0fWvZeQqmuE4SSP62tOp0=@protonmail.com>
Message-ID: <C79ZOLU7RNWH.3O8JA6RC7XGGY@stilgar>

On Sat Nov 21, 2020 at 6:57 PM CET,  wrote:
> > I removed support for atom feeds in the last update, but if it's a
> > popular request then I can add them back.
>
> Definitely you should add it back! I don't see Atom feeds going anyway
> any time soon, especially since the Gemini feed is only an idea and not
> standardized yet. Even when it is, Atom is still useful. I don't see
> why there's any need to remove it.

This is correct!  The new lightweight feed idea is *not* supposed to
replace Atom, which is considerably more powerful and flexible.  The
idea is simply to make it possible to subscribe to even very simple
static gemlogs which are maintained by hand, so people are not forced to
choose between tedious handwriting of XML, running fragile scripts which
attempt to guess a post's timestamp from the filesystem metadata (which
is too easily changed by accident) or the filename (which encourages
longer, uglier URLs), or running a CMS or static site generator (which
they might perceive as over-complicated or over-opinionated), just to
make sure people are able to follow their writing.

If a site *is* being generated by a CMS or static site generator,
there's no reason for it not to provide Atom feeds.

Cheers,
Solderpunk


From gustavo at gsthnz.com  Sun Nov 22 18:07:27 2020
From: gustavo at gsthnz.com (Gustavo Heinz)
Date: Sun, 22 Nov 2020 15:07:27 -0300
Subject: [ANN] gssg: a gemini static site generator
Message-ID: <C79ZQZBJKY53.371W7X7QGTLJ4@odin>

Hey guys,

I wrote a little ssg for gemini for fun and games (and to practice Go).
I had a inspiration from kiln, but I added a few personal touches.

A few features worth mentioning:
* Go templates
* Date sourcing from filename or the page content.
* Atom feeds
* A init command to startup a new gemlog.

My idea here is to make it as simple as possible to start a gemlog.
There's default templates which (should) just work.

(The default index template should be compatible with the subscription
format solderpunk just announced, btw)

I'm using it now to generate my website.

The code needs some cleanups, but it's working.

If you do check it out, feel free to point me at stupid code or bugs :)

Enjoy,

--
Gustavo Heinz

From colecmac at protonmail.com  Sun Nov 22 18:26:00 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 22 Nov 2020 18:26:00 +0000
Subject: [ANN] gssg: a gemini static site generator
In-Reply-To: <C79ZQZBJKY53.371W7X7QGTLJ4@odin>
References: <C79ZQZBJKY53.371W7X7QGTLJ4@odin>
Message-ID: <imnCHQXemEka3j4qE4QCY__qn0JzzRdqdxPTHx2AYvRWjDsGJE__4l0wk2QsL5tpxqCslEJ0oS807E9FHrh8bCvka5JVMjiM-6crT1Brjls=@protonmail.com>

All we need now is a link :)


makeworld

From gustavo at gsthnz.com  Sun Nov 22 18:29:18 2020
From: gustavo at gsthnz.com (Gustavo Heinz)
Date: Sun, 22 Nov 2020 15:29:18 -0300
Subject: [ANN] gssg: a gemini static site generator
In-Reply-To: <imnCHQXemEka3j4qE4QCY__qn0JzzRdqdxPTHx2AYvRWjDsGJE__4l0wk2QsL5tpxqCslEJ0oS807E9FHrh8bCvka5JVMjiM-6crT1Brjls=@protonmail.com>
Message-ID: <C7A07P65SGKX.1C1ON0993JXAD@odin>

On Sun Nov 22, 2020 at 3:26 PM -03,  wrote:
> All we need now is a link :)

Sorry,

https://sr.ht/~gsthnz/gssg :)

From wklew at mailbox.org  Sun Nov 22 18:34:53 2020
From: wklew at mailbox.org (Walter Lewis)
Date: Sun, 22 Nov 2020 13:34:53 -0500
Subject: jacobin covid article
Message-ID: <9D6A7A59-F138-46BF-84D5-2F00516626E7@mailbox.org>

https://jacobinmag.com/2020/03/coronavirus-workplace-organizing-bakeri-layoffs-unemployment

From solderpunk at posteo.net  Sun Nov 22 18:25:12 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 22 Nov 2020 19:25:12 +0100
Subject: Capping CAPCOM, calling for more aggregators
In-Reply-To: <bRYQHYKYRMnwHpRA5rVJLsTATgJG3-SIMSh1NmkpjS2NtN_g-tnudYwBjOuWN4tRGsKjqYYV20fgWc7j5FtiAptqrlgN9Zr-z4Z8Bi7O0Wo=@protonmail.com>
Message-ID: <C7A04K59COPW.B2C4IW21OO7O@stilgar>

On Sun Nov 22, 2020 at 7:15 PM CET,  wrote:

> One thing I'm wondering about this CAPCOM culling is whether favouring
> the
> old gemlogs is a good idea. CAPCOM will become more and more "dated" as
> time
> goes on. Would it be better if periodically CAPCOM updated to tracking
> the
> newest gemlogs in Geminispace? So it would allow new people's capsules
> and
> gemlogs to be discovered. I'm not sure how well this fits with the
> current
> method of emailing you to be added to CAPCOM, but I think it's an
> interesting
> idea.

The burden of me manually maintaining CAPCOM in response to emails is a
(small) additional motivation to put in a 100 feed cap.  I guess I could
look into setting up a submission system using status code 10 to let
people add URLs, and have CAPCOM aggregate, say, 100 feeds selected at
random from the pool, with a new 100 being selected on the 1st of each
month.  This way it would become some kind of "Geminispace rotating
sampler"...

Cheers,
Solderpunk

From me at adnano.co  Sun Nov 22 19:55:08 2020
From: me at adnano.co (Adnan Maolood)
Date: Sun, 22 Nov 2020 14:55:08 -0500
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <C79ZOLU7RNWH.3O8JA6RC7XGGY@stilgar>
Message-ID: <C7A21F91P5Q5.2ZV2MXFHK1QPP@nitro>

On Sun Nov 22, 2020 at 1:04 PM EST, Solderpunk wrote:
> On Sat Nov 21, 2020 at 6:57 PM CET, wrote:
> > > I removed support for atom feeds in the last update, but if it's a
> > > popular request then I can add them back.
> >
> > Definitely you should add it back! I don't see Atom feeds going anyway
> > any time soon, especially since the Gemini feed is only an idea and not
> > standardized yet. Even when it is, Atom is still useful. I don't see
> > why there's any need to remove it.
>
> This is correct! The new lightweight feed idea is *not* supposed to
> replace Atom, which is considerably more powerful and flexible. The
> idea is simply to make it possible to subscribe to even very simple
> static gemlogs which are maintained by hand, so people are not forced to
> choose between tedious handwriting of XML, running fragile scripts which
> attempt to guess a post's timestamp from the filesystem metadata (which
> is too easily changed by accident) or the filename (which encourages
> longer, uglier URLs), or running a CMS or static site generator (which
> they might perceive as over-complicated or over-opinionated), just to
> make sure people are able to follow their writing.
>
> If a site *is* being generated by a CMS or static site generator,
> there's no reason for it not to provide Atom feeds.
>
> Cheers,
> Solderpunk

Okay, I will go ahead and re-implement them.

Question: is it okay for Atom feeds to use relative URLs instead of
absolute URLs? That would make it easier to have a feed that works over
Gemini and HTML. It would also make generating the feed simpler.

From alex at nytpu.com  Sun Nov 22 20:54:49 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Sun, 22 Nov 2020 13:54:49 -0700
Subject: Lightweight subscription to Gemini pages
Message-ID: <20201122205449.ttglnppooc7cjmmc@GLaDOS>

Hi,

I have a minor suggestion to make when parsing the feed title from
headers.

I use ASCII art as headers for all my sites, with alt text with a
plaintext header. If you tried to use a feed reader on my gemlog
(gemini://nytpu.com/gemlog/) it would consider the title to be ?2020?
rather than the ?yet another tech gemlog? indicated by the alt text in
my header. I suggest that a reader should get the title from *either*
the first header on the page, or the first preformatted text line. For
example, with regex you could search for "^[`#]+\s*(.*)$" (with the
capture group being the title).

A minor change, but I know there's a few other pages I've seen around
that also use a header in the same way, so I'd think it'd be helpful.

nytpu

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201122/2c731f57/attachment.sig>

From me at adnano.co  Sun Nov 22 20:56:33 2020
From: me at adnano.co (Adnan Maolood)
Date: Sun, 22 Nov 2020 15:56:33 -0500
Subject: Lightweight subscription to Gemini pages
In-Reply-To: <20201122205449.ttglnppooc7cjmmc@GLaDOS>
Message-ID: <C7A3CFX0ULJI.33K306GNW09D0@nitro>

On Sun Nov 22, 2020 at 3:54 PM EST, Alex // nytpu wrote:
> Hi,
>
> I have a minor suggestion to make when parsing the feed title from
> headers.
>
> I use ASCII art as headers for all my sites, with alt text with a
> plaintext header. If you tried to use a feed reader on my gemlog
> (gemini://nytpu.com/gemlog/) it would consider the title to be
> ?2020?
> rather than the ?yet another tech gemlog? indicated by the alt text
> in
> my header. I suggest that a reader should get the title from *either*
> the first header on the page, or the first preformatted text line. For
> example, with regex you could search for "^[`#]+\s*(.*)$" (with the
> capture group being the title).
>
> A minor change, but I know there's a few other pages I've seen around
> that also use a header in the same way, so I'd think it'd be helpful.

I would recommend putting an actual header along with the preformatted
text. That would make it clear what the intention is.

From colecmac at protonmail.com  Sun Nov 22 21:16:03 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 22 Nov 2020 21:16:03 +0000
Subject: Lightweight subscription to Gemini pages
In-Reply-To: <20201122205449.ttglnppooc7cjmmc@GLaDOS>
References: <20201122205449.ttglnppooc7cjmmc@GLaDOS>
Message-ID: <kKd4ECNnaR-odzo7HvahKEX2w82ZkuDAhH7diVx5v0qDpJcxvJsuSBrxsVdez_TJ186N3hobqwYlMBbHytB55wgxT1XQmETz4joyN7C8MiE=@protonmail.com>

> it would consider the title to be ?2020?

It would not. The spec only sets level one header lines as
the title. Level two headers can be the subtitle, but that's only if
there's already a level one header.

See
gemini://gemini.circumlunar.space/docs/companion/subscription.gmi
for more details.

I agree with Adnan that you should just provide a header line.


makeworld


From sean at conman.org  Sun Nov 22 22:09:21 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 22 Nov 2020 17:09:21 -0500
Subject: [ANN] kiln - a static site generator for Gemini sites
In-Reply-To: <C7A21F91P5Q5.2ZV2MXFHK1QPP@nitro>
References: <C79ZOLU7RNWH.3O8JA6RC7XGGY@stilgar>
 <C7A21F91P5Q5.2ZV2MXFHK1QPP@nitro>
Message-ID: <20201122220921.GA1721@brevard.conman.org>

It was thus said that the Great Adnan Maolood once stated:
> On Sun Nov 22, 2020 at 1:04 PM EST, Solderpunk wrote:
> > On Sat Nov 21, 2020 at 6:57 PM CET, wrote:
> > > > I removed support for atom feeds in the last update, but if it's a
> > > > popular request then I can add them back.
> > >
> > > Definitely you should add it back! I don't see Atom feeds going anyway
> > > any time soon, especially since the Gemini feed is only an idea and not
> > > standardized yet. Even when it is, Atom is still useful. I don't see
> > > why there's any need to remove it.
> >
> > This is correct! The new lightweight feed idea is *not* supposed to
> > replace Atom, which is considerably more powerful and flexible. The
> > idea is simply to make it possible to subscribe to even very simple
> > static gemlogs which are maintained by hand, so people are not forced to
> > choose between tedious handwriting of XML, running fragile scripts which
> > attempt to guess a post's timestamp from the filesystem metadata (which
> > is too easily changed by accident) or the filename (which encourages
> > longer, uglier URLs), or running a CMS or static site generator (which
> > they might perceive as over-complicated or over-opinionated), just to
> > make sure people are able to follow their writing.
> >
> > If a site *is* being generated by a CMS or static site generator,
> > there's no reason for it not to provide Atom feeds.
> >
> > Cheers,
> > Solderpunk
> 
> Okay, I will go ahead and re-implement them.
> 
> Question: is it okay for Atom feeds to use relative URLs instead of
> absolute URLs? That would make it easier to have a feed that works over
> Gemini and HTML. It would also make generating the feed simpler.

  Yes, but you can also have multiple <link> elements per entry.  From my
own Atom feed:

	<entry>
	  <id>tag:boston.conman.org,2020-11-22:/2020/11/22.1</id>
	  <title type="text">All I wanted was a surreal email conversation with a confused recipient</title>
	  <updated>2020-11-22T03:35:05-05:00</updated>
	  <link rel="alternate" type="text/html"   hreflang="en-US" href="http://boston.conman.org/2020/11/22.1" />
	  <link rel="alternate" type="text/gemini" hreflang="en-US" href="gemini://gemini.conman.org/boston/2020/11/22.1"  />
	  <link rel="alternate" type="text/plain"  hreflang="en-US" href="gopher://gopher.conman.org/0Phlog:/2020/11/22.1" />
	  <content type="html">...</content>
	</entry>

  There can be only one <content> tag, so you'll have to decide if you want
this to contain HTML or plain text (it is also optional).

  -spc

From sean at conman.org  Sun Nov 22 22:59:42 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 22 Nov 2020 17:59:42 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
Message-ID: <20201122225942.GB1721@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> Hi folks,
> 
> There is now (finally!) an official reference on the use of robots.txt
> files in Geminispace.  Please see:
> 
> gemini://gemini.circumlunar.space/docs/companion/robots.gmi

  Nice.

> I attempted to take into account previous discussions on the mailing
> list and the currently declared practices of various well-known Gemini
> bots (broadly construed).
> 
> I don't consider this "companion spec" to necessarily be finalised at
> this point, but I am primarily interested in hearing suggestions for
> change from either authors of software which tries to respect robots.txt
> who are having problems caused by the current specification, or from
> server admins who are having bot problems who feel that the current
> specification is not working for them.

  Right now, there are two things I would change.

	1. Add "allow".  While the initial spec [1] did not have an allow
	   rule, a subsequent draft proposal [2] did, which Google is
	   pushing (as of 2019) to become an RFC [3].

	2. I would specify virtual agents as:

		Virtual-agent: archiver
		Virtual-agent: indexer

	   This makes it easier to add new virtual agents, separates the
	   namespace of agents from the namespace of virtual agents, and is
	   allowed by all current and proposed standards [4].

	   The rule I would follow is:

		Definitions:  
			specific user agent is one that is not '*'
			specific virtual agent is one that is not '*'
			generic user agent is one that is specified as '*'
			generic virtual agent is one that is '*'

		A crawler should use a block of rules:

			if it finds a specific user agent (most targetted)
			or it finds a specific virtual agent
			or it finds a generic virtual agent
			or it finds a generic user agent (least targetted)

	   I'm wavering on the generic virtual agent bit, so if you think
	   that makes this too complicated, fine, I think it can go.

> The biggest gap that I can currently see is that there is no advice on
> how often bots should re-query robots.txt to check for policy changes.
> I could find no clear advice on this for the web, either.  I would be
> happy to hear from people who've written software that uses robots.txt
> with details on what their current practices are in this respect.

  The Wikipedia page [5] lists a non-standard extension "Crawl-delay" which
informs a crawler how often they should make requests.  It might be easy to
add a field saying how often to fetch a resource.  A sample file:

# The GUS agent, plus any agent that identifies as an "indexer" is allowed
# one path in an otherwise disallowed place, and only fetch items in 10
# second increments.

User-agent: GUS
Virtual-agent: indexer
Allow: /private/butpublic
Disallow: /private
Crawl-delay: 10

# Agents that fetch feeds, should only grab every 6 hours.  "Check" is
# allowed as agents should ignore fields it doesn't understand.

Virtual-agent: feed
Disallow: /private
Check: 21600

# And a fallback.  Here we don't allow any old crawler into the private
# space, and we force them to use 20 seonds between fetches.

User-agent: *
Disallow: /private
Crawl-delay: 20

  -spc

[1]	gemini://gemini.circumlunar.space/docs/companion/robots.gmi

[2]	http://www.robotstxt.org/norobots-rfc.txt

[3]	https://developers.google.com/search/reference/robots_txt

[4]	Any field not understood by a crawler should be ignored.

[5]	https://en.wikipedia.org/wiki/Robots_exclusion_standard

From sir at cmpwn.com  Sun Nov 22 23:02:18 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sun, 22 Nov 2020 18:02:18 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
Message-ID: <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>

Feedback:

A web portal is a regular user agent, not a robot.

Maybe we could normalize robots fetching robots.txt with the query
string set to some useful identifiying information? This would allow
gemini administrators to make bot-specific rules, understand the
behavior of their logs, and get in touch with the operator if
necessary.

From cowan at ccil.org  Mon Nov 23 00:30:01 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 22 Nov 2020 19:30:01 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>
Message-ID: <CAD2gp_ToHLfz8P4g3u6=RDaNcY+75BNP1OgK-XAj8gZqp+mFBg@mail.gmail.com>

On Sun, Nov 22, 2020 at 6:03 PM Drew DeVault <sir at cmpwn.com> wrote:


> A web portal is a regular user agent, not a robot.
>

Agreed.  However, The spec says "publicly serve the result", and a *public*
proxy can pound a Gemini server if a lot of Web clients are accessing it
concurrently.  It should be able to find out whether the server is robust
to such operations or not.

By the same token, a public Gopher proxy (if there are any) should respect
"Disallow: gopherproxy".

Other points:
+1 for Allow:
+1 for Virtual-Agent
+1 for ignoring unknown lines
Unsure what the difference is between Crawl-Delay: and Check:, but having a
retry delay is a Good Thing

Additionally:  "Agent:" should specify a SHA-256 hash of the client cert
used by particular crawlers rather than a random easy-to-forge name.  Thus
GUS should crawl using a cert and publicly post the hash of this cert.
Then callers with that cert are necessarily GUS, since the cert itself is
not published.  (Of course it's still possible for a server to steal GUS's
client cert.)


> Maybe we could normalize robots fetching robots.txt with the query
> string set to some useful identifiying information? This would allow
> gemini administrators to make bot-specific rules, understand the
> behavior of their logs, and get in touch with the operator if
> necessary.
>

The trouble is that completely different pages can be returned with
different query strings that are entirely unrelated to actual searching, so
it's inappropriate to usurp the query string for this purpose.  That's not
to say that agent control can't rely on the query string.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Gules six bars argent on a canton azure 50 mullets argent
six five six five six five six five and six
   --blazoning the U.S. flag <http://web.meson.org/blazonserver>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201122/f4d1e563/attachment.htm>

From me at adnano.co  Mon Nov 23 00:38:11 2020
From: me at adnano.co (Adnan Maolood)
Date: Sun, 22 Nov 2020 19:38:11 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <CAD2gp_ToHLfz8P4g3u6=RDaNcY+75BNP1OgK-XAj8gZqp+mFBg@mail.gmail.com>
Message-ID: <C7A8253W74PS.3J3SBB2IKJCAE@nitro>

On Sun Nov 22, 2020 at 7:30 PM EST, John Cowan wrote:
> Additionally: "Agent:" should specify a SHA-256 hash of the client cert
> used by particular crawlers rather than a random easy-to-forge name.
> Thus
> GUS should crawl using a cert and publicly post the hash of this cert.
> Then callers with that cert are necessarily GUS, since the cert itself
> is
> not published. (Of course it's still possible for a server to steal
> GUS's
> client cert.)

This doesn't seem very useful, as bad robots can simply ignore the rules
in robots.txt.

From cowan at ccil.org  Mon Nov 23 00:44:40 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 22 Nov 2020 19:44:40 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C7A8253W74PS.3J3SBB2IKJCAE@nitro>
References: <CAD2gp_ToHLfz8P4g3u6=RDaNcY+75BNP1OgK-XAj8gZqp+mFBg@mail.gmail.com>
 <C7A8253W74PS.3J3SBB2IKJCAE@nitro>
Message-ID: <CAD2gp_RHZ760cmJsr5TFbYwDRfpLUjiDsTSTv0ZMU-oYvb4D+w@mail.gmail.com>

Of course they can: that's always true, as the pre-spec already says.   The
idea is to give crawlers (etc.) that want to keep to the rules some way to
clearly and uniquely identify themselves to servers.

On Sun, Nov 22, 2020 at 7:39 PM Adnan Maolood <me at adnano.co> wrote:

> On Sun Nov 22, 2020 at 7:30 PM EST, John Cowan wrote:
> > Additionally: "Agent:" should specify a SHA-256 hash of the client cert
> > used by particular crawlers rather than a random easy-to-forge name.
> > Thus
> > GUS should crawl using a cert and publicly post the hash of this cert.
> > Then callers with that cert are necessarily GUS, since the cert itself
> > is
> > not published. (Of course it's still possible for a server to steal
> > GUS's
> > client cert.)
>
> This doesn't seem very useful, as bad robots can simply ignore the rules
> in robots.txt.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201122/4c9e06ec/attachment.htm>

From natpen at natpen.net  Mon Nov 23 01:40:01 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sun, 22 Nov 2020 20:40:01 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
Message-ID: <X7sS8dSqOUjSqvYX@goldfish.localdomain>

This looks great! I'm excited to see this companion spec become more
formalized, and really like the categorical virtual agent design. One
thing that stuck out to me after a first read was the `webproxy` user
agent. What would you think of something like the following instead:

`proxy`
`proxy-web`
`proxy-gopher`

The prefixed design doesn't have any drawbacks as far as I can tell,
and would allow for more intuitively designed blocking/allowing
hierarchies. E.g., if there were 4 different types of proxies in use,
and you only wanted to allow one, you could be more restrictive with
`proxy` and less restrictive with the more precise, suffixed user
agent of the type you are okay with (e.g., `proxy-gopher`).

Emphasis on "more intuitively designed" - I realize you could
technically accomplish this in the current design by simply adding
`proxy` to the mix, but I think the prefix-based organization makes it
clearer and a bit more intuitive.

Warm regards,
Natalie

From khuxkm at tilde.team  Mon Nov 23 01:56:16 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Mon, 23 Nov 2020 01:56:16 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>
References: <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>
Message-ID: <fc318c9a12adbe40159c501c002c5681@tilde.team>

November 22, 2020 6:02 PM, "Drew DeVault" <sir at cmpwn.com> wrote:

> Feedback:
> 
> A web portal is a regular user agent, not a robot.

Just throwing in here for consideration that I agree with Drew, a proxy is not a robot by default. Are we implying that a browser must also follow robots.txt to be well-behaved? If so, I might just block AV-98 from reading my capsule. :)

What I would recommend in lieu of robots.txt proxy rules is normalizing using robots.txt on the web side of a proxy to prevent web spiders from inadvertantly crawling gemspace. For instance, proxy.vulpes.one blocks every robot user agent from indexing any part of the site.

Is there any good usecase for a proxy User-Agent in robots.txt, other than blocking web spiders from being able to crawl gemspace? If not, I would be in favor of dropping that part of the definition.

Just my two cents,
Robert "khuxkm" Miles

From sean at conman.org  Mon Nov 23 02:05:41 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 22 Nov 2020 21:05:41 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <fc318c9a12adbe40159c501c002c5681@tilde.team>
References: <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>
 <fc318c9a12adbe40159c501c002c5681@tilde.team>
Message-ID: <20201123020541.GE1721@brevard.conman.org>

It was thus said that the Great Robert khuxkm Miles once stated:
> 
> Is there any good usecase for a proxy User-Agent in robots.txt, other than
> blocking web spiders from being able to crawl gemspace? If not, I would be
> in favor of dropping that part of the definition.

  I'm in favor of dropping that part of the definition as it doesn't make
sense at all.  Given a web based proxy at <https://example.com/gemini>, web
crawlers will check for <https://example.com/robots.txt> for guidance, not
<https://example.com/gemini?gemini.conman.org/robots.txt>.  Web crawlers
will not be able to crawl gemini space for two main reasons:

        1. Most server certificates are self-signed and opt out of the CA
           business.  And even if a crawler where to accept self-signed
          (or non-standard CA signed) certificates, then---

        2. The Gemini protocol is NOT HTTP, so all such HTTP requests will
           fail anyway.

  -spc

From khuxkm at tilde.team  Mon Nov 23 02:13:11 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Mon, 23 Nov 2020 02:13:11 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201123020541.GE1721@brevard.conman.org>
References: <20201123020541.GE1721@brevard.conman.org>
 <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>
 <fc318c9a12adbe40159c501c002c5681@tilde.team>
Message-ID: <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>

November 22, 2020 9:05 PM, "Sean Conner" <sean at conman.org> wrote:

> It was thus said that the Great Robert khuxkm Miles once stated:
> 
>> Is there any good usecase for a proxy User-Agent in robots.txt, other than
>> blocking web spiders from being able to crawl gemspace? If not, I would be
>> in favor of dropping that part of the definition.
> 
> I'm in favor of dropping that part of the definition as it doesn't make
> sense at all. Given a web based proxy at <https://example.com/gemini>, web
> crawlers will check for <https://example.com/robots.txt> for guidance, not
> <https://example.com/gemini?gemini.conman.org/robots.txt>. Web crawlers
> will not be able to crawl gemini space for two main reasons:
> 
> 1. Most server certificates are self-signed and opt out of the CA
> business. And even if a crawler where to accept self-signed
> (or non-standard CA signed) certificates, then---
> 
> 2. The Gemini protocol is NOT HTTP, so all such HTTP requests will
> fail anyway.
> 
> -spc

Well, the argument is that the crawler would access <https://example.com/gemini?gemini://gemini.conman.org/>, and from there it could access <https://example.com/gemini?gemini://zaibatsu.circumlunar.space/>, and then <https://example.com/gemini?gemini://gemini.circumlunar.space/>, and so on. However, I'd argue that the onus falls on example.com to set a robots.txt rule in <https://example.com/robots.txt> to prevent web crawlers from indexing anything with their proxy.

Just my two cents,
Robert "khuxkm" Miles

From sir at cmpwn.com  Mon Nov 23 03:05:46 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sun, 22 Nov 2020 22:05:46 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
Message-ID: <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>

A web portal is a one-to-one mapping of a user request to a gemini
request. It's not an automated process. It's a genuine user agent, an
agent of a user. The level of traffic you'd receive from a web portal is
similar to the amount of traffic you'd receive from any other user
agent, and rate controls or access blocking don't make sense.

As the maintainer of such a web portal, I officially NACK any suggestion
that it should obey robots.txt, and will not introduce such a feature.

From sean at conman.org  Mon Nov 23 03:31:09 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 22 Nov 2020 22:31:09 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
References: <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
Message-ID: <20201123033109.GF1721@brevard.conman.org>

It was thus said that the Great Drew DeVault once stated:
> A web portal is a one-to-one mapping of a user request to a gemini
> request. It's not an automated process. It's a genuine user agent, an
> agent of a user. The level of traffic you'd receive from a web portal is
> similar to the amount of traffic you'd receive from any other user
> agent, and rate controls or access blocking don't make sense.
> 
> As the maintainer of such a web portal, I officially NACK any suggestion
> that it should obey robots.txt, and will not introduce such a feature.

  What's the IP address of your web portal, so I can block it and prevent
the various webbots that will go through your web portal and index the
Gemini content without my consent?

  -spc




From khuxkm at tilde.team  Mon Nov 23 03:37:43 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Mon, 23 Nov 2020 03:37:43 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201123033109.GF1721@brevard.conman.org>
References: <20201123033109.GF1721@brevard.conman.org>
 <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
Message-ID: <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>

November 22, 2020 10:31 PM, "Sean Conner" <sean at conman.org> wrote:

> It was thus said that the Great Drew DeVault once stated:
> 
>> A web portal is a one-to-one mapping of a user request to a gemini
>> request. It's not an automated process. It's a genuine user agent, an
>> agent of a user. The level of traffic you'd receive from a web portal is
>> similar to the amount of traffic you'd receive from any other user
>> agent, and rate controls or access blocking don't make sense.
>> 
>> As the maintainer of such a web portal, I officially NACK any suggestion
>> that it should obey robots.txt, and will not introduce such a feature.
> 
> What's the IP address of your web portal, so I can block it and prevent
> the various webbots that will go through your web portal and index the
> Gemini content without my consent?
> 
> -spc

I assume Drew's smart enough to block web bots from crawling his gemini portal. Just saying.

Just my two cents,
Robert "khuxkm" Miles

From sir at cmpwn.com  Mon Nov 23 03:44:48 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Sun, 22 Nov 2020 22:44:48 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201123033109.GF1721@brevard.conman.org>
Message-ID: <C7AC110NKPTT.240NYV5BJ3KTL@taiga>

On Sun Nov 22, 2020 at 10:31 PM EST, Sean Conner wrote:
> What's the IP address of your web portal, so I can block it and prevent
> the various webbots that will go through your web portal and index the
> Gemini content without my consent?

It's not an indexer. It's a user agent. And its IP address is
173.195.146.137.

Dick.

From cowan at ccil.org  Mon Nov 23 04:51:03 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 22 Nov 2020 23:51:03 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
References: <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
Message-ID: <CAD2gp_TjRggAZLvi8WFL+XR6nqG4iTnwj_jyni-zc3JwK_FzSA@mail.gmail.com>

On Sun, Nov 22, 2020 at 10:07 PM Drew DeVault <sir at cmpwn.com> wrote:

A web portal is a one-to-one mapping of a user request to a gemini
> request. It's not an automated process. It's a genuine user agent, an
> agent of a user.
>

It is the agent of an arbitrarily large number of users.  That's the
difference between, say, an email user agent and an email gateway to a
non-Internet email system.  There is no reason to impose even soft
regulation on the former.  There is every reason to allow regulation of the
latter.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
The experiences of the past show that there has always been a discrepancy
between plans and performance.        --Emperor Hirohito, August 1945
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201122/7e1d280a/attachment.htm>

From sean at conman.org  Mon Nov 23 04:56:19 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 22 Nov 2020 23:56:19 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>
References: <20201123033109.GF1721@brevard.conman.org>
 <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
 <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>
Message-ID: <20201123045619.GG1721@brevard.conman.org>

It was thus said that the Great Robert khuxkm Miles once stated:
> November 22, 2020 10:31 PM, "Sean Conner" <sean at conman.org> wrote:
> 
> > It was thus said that the Great Drew DeVault once stated:
> > 
> >> A web portal is a one-to-one mapping of a user request to a gemini
> >> request. It's not an automated process. It's a genuine user agent, an
> >> agent of a user. The level of traffic you'd receive from a web portal is
> >> similar to the amount of traffic you'd receive from any other user
> >> agent, and rate controls or access blocking don't make sense.
> >> 
> >> As the maintainer of such a web portal, I officially NACK any suggestion
> >> that it should obey robots.txt, and will not introduce such a feature.
> > 
> > What's the IP address of your web portal, so I can block it and prevent
> > the various webbots that will go through your web portal and index the
> > Gemini content without my consent?
> > 
> > -spc
> 
> I assume Drew's smart enough to block web bots from crawling his gemini
> portal. Just saying.
> 
> Just my two cents,

  Drew's proxy is a webserver in its own right:

	https://git.sr.ht/~sircmpwn/kineto/tree/master/main.go

  It checks for a GET request for "/favicon.ico" but not to "/robots.txt".
Every other GET request is immediately proxied to a gemini server.  I think
it was meant to run locally, but he made an instance available on the public
Internet.

  -spc
  

From sir at cmpwn.com  Mon Nov 23 05:01:31 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 23 Nov 2020 00:01:31 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <CAD2gp_TjRggAZLvi8WFL+XR6nqG4iTnwj_jyni-zc3JwK_FzSA@mail.gmail.com>
Message-ID: <C7ADNRBHP020.3J0RKW0UMS3JC@taiga>

On Sun Nov 22, 2020 at 11:51 PM EST, John Cowan wrote:
> It is the agent of an arbitrarily large number of users.

So is every other user agent. It will never make more requests than
there are users who are asking for content. It is not special.

From bjorn.warmedal at gmail.com  Mon Nov 23 08:23:33 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Mon, 23 Nov 2020 09:23:33 +0100
Subject: On input and uploading of user content
In-Reply-To: <CAD2gp_R=ZpMOAqLg05AC9=R1Lo66oosJ+SFQ_XinzZTAyrSbZw@mail.gmail.com>
References: <38acc6bf82efb965ba8a58c91d7daf38794cf9de.camel@gmail.com>
 <87eekt84ol.fsf@disroot.org>
 <f749c381ad9f4aaa9f44866ad74bd4a9143939dd.camel@gmail.com>
 <CAJScK0J80X6wNQOe0Zu5AV1Z4t6c5agEEm1WcCwj9uRe+yHSig@mail.gmail.com>
 <CAD2gp_R=ZpMOAqLg05AC9=R1Lo66oosJ+SFQ_XinzZTAyrSbZw@mail.gmail.com>
Message-ID: <CAJScK0+eY4aajrMsOStpzgGM+6rEyLxfR9ocaFXYJ0GdofoXpA@mail.gmail.com>

On Fri, 20 Nov 2020 at 19:56, John Cowan <cowan at ccil.org> wrote:
>
> Minor correction:
>
> Titan is a PUT protocol that can send something to a server.  Dioscuri is a true POST protocol: you send something to the server, and then you get either a response or an URL pointing to the true response (thanks to the magic of MIME-type message/external-body).  Dioscuri isn't really intended as a file-upload protocol, though it could be used that way, but as an application protocol for requests that won't fit into an URL.  It is in no way intended for use with forms, but with specialized clients.

Thank you! I just thought of them both as "ways to send data to the
server", but there is definitely a point to clarifying the difference.
I've added a clarification to my finishing post on the subject:
gemini://tilde.team/~ew0k/gemini-and-post-part2.gmi

Cheers,
ew0k

From emilis at emilis.net  Mon Nov 23 23:09:18 2020
From: emilis at emilis.net (Emilis)
Date: Tue, 24 Nov 2020 01:09:18 +0200
Subject: robots.txt for Gemini formalised
In-Reply-To: <CAD2gp_ToHLfz8P4g3u6=RDaNcY+75BNP1OgK-XAj8gZqp+mFBg@mail.gmail.com>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <C7A60Q2JCSQP.3UAHW6DREZ4RD@taiga>
 <CAD2gp_ToHLfz8P4g3u6=RDaNcY+75BNP1OgK-XAj8gZqp+mFBg@mail.gmail.com>
Message-ID: <08fde749-b8f8-9ddc-2e8c-9b7e6af459f6@emilis.net>

On 11/23/20 2:30 AM, John Cowan wrote:
>
> By the same token, a public Gopher proxy (if there are any) should 
> respect "Disallow: gopherproxy".
>
> Other points:
> +1 for Allow:
> +1 for Virtual-Agent
> +1 for ignoring unknown lines
> Unsure what the difference is between Crawl-Delay: and Check:, but 
> having a retry delay is a Good Thing

A small nit-pick: if we use "Virtual-Agent" and "Crawl-Delay", we should 
at least use "gopher-proxy" instead of "gopherproxy".


--
Emilis Dambauskas
gemini://tilde.team/~emilis/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201124/de97bb6b/attachment.htm>

From sir at cmpwn.com  Mon Nov 23 23:10:45 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Mon, 23 Nov 2020 18:10:45 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <08fde749-b8f8-9ddc-2e8c-9b7e6af459f6@emilis.net>
Message-ID: <C7B0TQPHY8QB.2U0TVW8ZG9KPZ@taiga>

-1 to Virtual-Agent

I think that this is best formalized as an addendum to the existing
robots.txt conventions, which simply details a gemini-specific
interpretation as such.

From marcx2 at welz.org.za  Tue Nov 24 10:29:02 2020
From: marcx2 at welz.org.za (marc)
Date: Tue, 24 Nov 2020 11:29:02 +0100
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201123045619.GG1721@brevard.conman.org>
References: <20201123033109.GF1721@brevard.conman.org>
 <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
 <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>
 <20201123045619.GG1721@brevard.conman.org>
Message-ID: <20201124102902.GA17441@localhost.localdomain>

Hi

I suppose I am chipping it a bit too late here, but I think
the robots.txt thing was always a rather ugly mechanism - a
bit of an afterthought.

Consider the gemini://example.com/~somebody/personal.gmi -
if somebody wishes to exclude personal.gmi from being
crawled they need write access to example.com/robots.txt,
and how do we go about making sure that ~somebodyelse,
also on example.com doesn't overwrite robots.txt with
their own rules ?

Then there is the problem of transitivity - if we
have a portal, proxy or archive - how does it relay
the information to its downstream users ? See also
the exchange between Sean and Drew...

So the way I remember it, robots.txt was a quick hack
to prevent spiders getting trapped in a maze of
cgi generated data, and so hammering the server.
It wasn't designed to solve matters of privacy
and redistribution.

I have pitched this idea before: I think a footer containing
the license/rules under which a page can be distributed/cached
is more sensible than robots.txt. This approach is:

* local to the page (no global /robots.txt)
* persistent (survives being copied, mirrored & re-exported)
* sound (one knows the conditions under which this can be redistributed)

I speak under correction, but I believe a decent amount of the
public web was mined for faces to train the neural networks
that now make totalitarian surveillance possible. Had these
been labelled "CC ND (no derivative work)" then there
would be legal impediment - not to the regimes now, but to
the universities and research labs which pioneered this.

We now have people more aware of this problem, and some
of us wish to put up material limited to gemini-space only,
and not export it to the web. A footer line "-- GMI: A. User"
could prohibit export to the web, while one "-- CC-SA: J. Soap"
would permit it...

regards

marc

From johann at qwertqwefsday.eu  Tue Nov 24 11:06:20 2020
From: johann at qwertqwefsday.eu (Johann Galle)
Date: Tue, 24 Nov 2020 12:06:20 +0100
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201124102902.GA17441@localhost.localdomain>
References: <20201123033109.GF1721@brevard.conman.org>
 <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
 <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>
 <20201123045619.GG1721@brevard.conman.org>
 <20201124102902.GA17441@localhost.localdomain>
Message-ID: <df7439d5-fafd-a070-4762-16c30033e15c@qwertqwefsday.eu>


On 24.11.2020, marc wrote:
> I suppose I am chipping it a bit too late here, but I think
> the robots.txt thing was always a rather ugly mechanism - a
> bit of an afterthought.

+1 that the robots.txt solution feels a lot like a hack.
  
> So the way I remember it, robots.txt was a quick hack
> to prevent spiders getting trapped in a maze of
> cgi generated data, and so hammering the server.
> It wasn't designed to solve matters of privacy
> and redistribution.

There is a more modern alternative to robots.txt which is the X-Robots-Tag
HTTP header and sounds like what you are trying to do here.

That said, there are probably people who will not want special headers to be
added [1], altough I personally think that something like you suggest would not
be that "exploitable". Especially because it is just part of the documents text.

[1] See the first sentence of ?2.4 of the Gemini FAQ
     gemini://gemini.circumlunar.space/docs/faq.gmi
     https://gemini.circumlunar.space/docs/faq.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201124/ebbb436e/attachment.sig>

From linde.philip at gmail.com  Tue Nov 24 11:31:09 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 24 Nov 2020 12:31:09 +0100
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201124102902.GA17441@localhost.localdomain>
References: <20201123033109.GF1721@brevard.conman.org>
 <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
 <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>
 <20201123045619.GG1721@brevard.conman.org>
 <20201124102902.GA17441@localhost.localdomain>
Message-ID: <20201124123109.b08d27b9dbe0285829cd51b2@gmail.com>

On Tue, 24 Nov 2020 11:29:02 +0100
marc <marcx2 at welz.org.za> wrote:

> Consider the gemini://example.com/~somebody/personal.gmi -
> if somebody wishes to exclude personal.gmi from being
> crawled they need write access to example.com/robots.txt,
> and how do we go about making sure that ~somebodyelse,
> also on example.com doesn't overwrite robots.txt with
> their own rules ?

How the server produces responses to robots.txt requests is an
implementation detail. robots.txt can easily be implemented such that
the server responds with access information provided by files in
subdirectories. For example: a system directory corresponding to
/~somebody/ contains a file named ".disallow" containing
"personal.gmi". When the server builds a response to /robots.txt, it
considers the content of all ".disallow" files and includes Disallow
lines corresponding to their content. This way, individual users on a
multi-user system can decide for themselves the access policy for their
content without shared access to a canonical robots.txt.

> I have pitched this idea before: I think a footer containing
> the license/rules under which a page can be distributed/cached
> is more sensible than robots.txt. This approach is:
> 
> * local to the page (no global /robots.txt)
> * persistent (survives being copied, mirrored & re-exported)
> * sound (one knows the conditions under which this can be redistributed)

What if my document is a binary file of some sort that I can not add a
footer to? The only ways to address this consistently for all document
types are to

a) Include the information in the response, *distinct* from its body
b) Provide the information in a sidecar file or sideband communication
   channel

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201124/fb819cb7/attachment.sig>

From gemini at ur.gs  Tue Nov 24 11:42:26 2020
From: gemini at ur.gs (Nick Thomas)
Date: Tue, 24 Nov 2020 11:42:26 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
Message-ID: <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>

Hi,

On Sun, 2020-11-22 at 17:31 +0100, Solderpunk wrote:
> Hi folks,
> 
> There is now (finally!) an official reference on the use of
> robots.txt
> files in Geminispace.  Please see:
> 
> gemini://gemini.circumlunar.space/docs/companion/robots.gmi

Thanks for this. One change that I'd be interested in is adding a
statement that if there is no `robots.txt` for the site, we assume an
implicit disallow-all for all the virtual-agents except proxies.

Presumed consent, with opt-outs for the tiny minority of people who
have the time and mental space to work out how to get those opt-outs to
apply, is standard behaviour on the web, but it's not behaviour I like.
GitHub recently dumped code of mine into an arctic vault, for instance;
the archive.org snapshots of geminispace have similar dynamics. We can
do better by asking people to opt *in* to these kinds of things if they
want it, rather than to opt *out* if they don't.

I exclude Virtual-Agent: webproxy here because the likely use of such a
proxy is transient, rather than persistent. It seems odd to me that it
sits alongside indexing, archival, and research, all of which lead to
durable artifacts on success. It does complicate things a little to
treat it differently, thought.

Thoughts? I appreciate this would impact on the ability of archivists
or researchers to capture geminispace, but I see that as a feature,
rather than an unfortunate side-effect :). 

/Nick


From easrng at gmail.com  Tue Nov 24 13:15:03 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Tue, 24 Nov 2020 08:15:03 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
Message-ID: <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>

On Tue, Nov 24, 2020 at 6:42 AM Nick Thomas <gemini at ur.gs> wrote:

> Thoughts? I appreciate this would impact on the ability of archivists
> or researchers to capture geminispace, but I see that as a feature,
> rather than an unfortunate side-effect :).

I don't agree with archiving being disallowed by default. archive.org
and others have saved me so many times, I can't imagine why one would
not want an archive. If there is a reason I would much prefer an
opt-out system for it.
Why do you dislike archival?

From tomasino at lavabit.com  Tue Nov 24 13:31:20 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 24 Nov 2020 13:31:20 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
Message-ID: <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>

Just an FYI on the recent discussion around implied license for search engines and archival: These aren't rules baked into a spec, they're implications of the DMCA in the US and relevant case law, such as BLAKE A. FIELD vs GOOGLE (2016). The existence of a mechanism to disallow indexing was vital to that decision establishing implied license. Search engines, whether they be our lovely friend GUS or some future behemoth, can gather, index, and cache as they see fit because there is a mechanism for you to say no. That mechanism is the robots.txt and they have a strong case saying that the rules which govern it are already well established.

As much as I'd love to wave a magic wand and say, "it's all opt-in here" we don't really have any legal footing to do so.


From jmcbray at carcosa.net  Tue Nov 24 14:06:58 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 24 Nov 2020 09:06:58 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <C7AB750HR1S5.12F8WY1S6S2PQ@taiga> (Drew DeVault's message of
 "Sun, 22 Nov 2020 22:05:46 -0500")
References: <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
Message-ID: <87wnyasvb1.fsf@dorothy.carcosa.net>

"Drew DeVault" <sir at cmpwn.com> writes:

> A web portal is a one-to-one mapping of a user request to a gemini
> request. It's not an automated process. It's a genuine user agent, an
> agent of a user.

I believe the concern is not that a web portal will archive pages, or
run on its own as an automated process, but that it will be used by a
third-party web bot (i.e., one not run by the owner of the portal) to
crawl Gemini sites and index them on the web.

> As the maintainer of such a web portal, I officially NACK any
> suggestion that it should obey robots.txt, and will not introduce such
> a feature.

It seems to me that the correct thing is for people that run web portals
to have a very strong robots.txt on /their/ web site, and additionally,
to be proactive about blocking web bots that don't observe robots.txt. I
think people want to block web portals in their Gemini robots.txt
because they don't trust web portal authors to do those two things. I
understand the feeling, but they're still trusting web portal authors to
obey robots.txt, which is honestly more work.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From sir at cmpwn.com  Tue Nov 24 14:07:45 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Tue, 24 Nov 2020 09:07:45 -0500
Subject: robots.txt for Gemini formalised
In-Reply-To: <87wnyasvb1.fsf@dorothy.carcosa.net>
Message-ID: <C7BJWJDU98AZ.AJ6OKBU5HUEO@taiga>

On Tue Nov 24, 2020 at 9:06 AM EST, Jason McBrayer wrote:
> I believe the concern is not that a web portal will archive pages, or
> run on its own as an automated process, but that it will be used by a
> third-party web bot (i.e., one not run by the owner of the portal) to
> crawl Gemini sites and index them on the web.

Aha, this is a much better point. One which should probably be addressed
in the robots.txt specification.

> It seems to me that the correct thing is for people that run web portals
> to have a very strong robots.txt on /their/ web site, and additionally,
> to be proactive about blocking web bots that don't observe robots.txt. I
> think people want to block web portals in their Gemini robots.txt
> because they don't trust web portal authors to do those two things. I
> understand the feeling, but they're still trusting web portal authors to
> obey robots.txt, which is honestly more work.

Web portals are users, plain and simple. Anyone who blocks a web portal
is blocking legitimate users who are engaging in legitimate activity.
This is a dick move and I won't stand up for anyone who does it.

However, the issue of web crawlers hitting geminispace through a web
portal is NOT that, and I'm glad you brought it up. I'm going to forbid
web crawlers from crawling my gemini portal.

From tomasino at lavabit.com  Tue Nov 24 14:26:44 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 24 Nov 2020 14:26:44 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
Message-ID: <dff8f69a-2d26-015b-3a36-50076151249b@lavabit.com>

On 11/24/20 1:15 PM, A. E. Spencer-Reed wrote:
> On Tue, Nov 24, 2020 at 6:42 AM Nick Thomas <gemini at ur.gs> wrote:
> 
>> Thoughts? I appreciate this would impact on the ability of archivists
>> or researchers to capture geminispace, but I see that as a feature,
>> rather than an unfortunate side-effect :).
> I don't agree with archiving being disallowed by default. archive.org
> and others have saved me so many times, I can't imagine why one would
> not want an archive. If there is a reason I would much prefer an
> opt-out system for it.
> Why do you dislike archival?

Denying archival is already possible with robots.txt in its present form. We don't need to edit the spec for that either. If you want to avoid the internet archive you can use:

User-agent: ia_archiver
Disallow: /


From marcx2 at welz.org.za  Tue Nov 24 15:16:49 2020
From: marcx2 at welz.org.za (marc)
Date: Tue, 24 Nov 2020 16:16:49 +0100
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201124123109.b08d27b9dbe0285829cd51b2@gmail.com>
References: <20201123033109.GF1721@brevard.conman.org>
 <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
 <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>
 <20201123045619.GG1721@brevard.conman.org>
 <20201124102902.GA17441@localhost.localdomain>
 <20201124123109.b08d27b9dbe0285829cd51b2@gmail.com>
Message-ID: <20201124151649.GA20449@localhost.localdomain>

Hi

> How the server produces responses to robots.txt requests is an
> implementation detail. robots.txt can easily be implemented such that
> the server responds with access information provided by files in
> subdirectories. For example: a system directory corresponding to
> /~somebody/ contains a file named ".disallow" containing
> "personal.gmi". When the server builds a response to /robots.txt, it
> considers the content of all ".disallow" files and includes Disallow
> lines corresponding to their content. This way, individual users on a
> multi-user system can decide for themselves the access policy for their
> content without shared access to a canonical robots.txt.

Note that the apache people worry about just doing a
stat() for .htaccess along a path. This proposal requires an
opendir() for *every* directory in the exported hierarchy.

I concede that this isn't impossible - it is potentially expensive,
messy or nonstandard (and yes, there are inotify tricks or
serving the entire site out of a database, but that isn't a
common thing).

> > I have pitched this idea before: I think a footer containing
> > the license/rules under which a page can be distributed/cached
> > is more sensible than robots.txt. This approach is:
> > 
> > * local to the page (no global /robots.txt)
> > * persistent (survives being copied, mirrored & re-exported)
> > * sound (one knows the conditions under which this can be redistributed)
> 
> What if my document is a binary file of some sort that I can not add a
> footer to? The only ways to address this consistently for all document
> types are to
> 
> a) Include the information in the response, *distinct* from its body
> b) Provide the information in a sidecar file or sideband communication
>    channel

So I think this is the interesting bit of the discussion -
the tradeoff of keeping this information inside the file or
in a sidechannel. You are of course correct that not every
file format permits embedding such information, and that
is the one side of the tradeoff.... the other side is
the argument for persistence - having the data in another
file (or in a protocol header) means that is likely to be
lost.

And my view is that caching/archiving/aggregating/protocol
translation all involve making copies, where a careless or
inconsiderate intermediate is likely to discard information
not embedded in the file. For instance, if a web frontend
serves gemini://example.org/private.gmi as
https://example.com/gemini/example.org/private.gmi
how good are the odds that this frontend fetches
gemini://example.org/robots.txt, rewrites the urls in there
from /private.gmi to /gemini/example.org/private.gmi and
merges it into its own /robots.txt ? And does it before
any crawler request is made... 

A pragmatist's argument: The web and geminispace are a graph
of links, and all the interior nodes have to be markup, so those
are covered, and they control the reachability - without
a link you can't get to the terminal/leaf node. And even if
this is bypassed (robots.txt isn't really a defence against hotlinking
either) most other terminal nodes are images or video, which typically have
ways of adding meta information (exif, etc).

regards

marc

From gemini at ur.gs  Tue Nov 24 16:49:41 2020
From: gemini at ur.gs (Nick Thomas)
Date: Tue, 24 Nov 2020 16:49:41 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
Message-ID: <c81a0b58f64239ddc35ef4c8f45fd0d01ca342aa.camel@ur.gs>

(I could be a lot better at using mailing lists. I think this message
was sent privately in error).

On Tue, 2020-11-24 at 08:15 -0500, A. E. Spencer-Reed wrote:
> Why do you dislike archival?

Thanks for weighing in!

In short, because the purposes to which the archive can be put, and the
motives of the archiver, are not clear at time of robots.txt-mediated
archival.

For myself, I'm happy with some types of archival, and not happy with
some other types. Some people would be happy to be included in every
archive going; others, in none of them. Given this variability, we must
take a stance on what to assume if robots.txt isn't present. I also I
don't think this variability is amenable to capture with more fine-
grained virtual agents. 

The current internet-draft for robots.txt says, in 2.2.1:

>  If no group satisfies either condition, or no groups are present at
> all, no rules apply.

( https://tools.ietf.org/html/draft-koster-rep-00 )

This is pretty standard on the Web and, entirely coincidentally, a huge
boon to Google et al. Importing robots.txt the way we do in the
companion specification also imports this line.

However, unlike the Web, Gemini "takes user privacy very seriously".
Archives *can* be injurious to user privacy - if you need convincing on
this point, there are a range of cases and examples around GDPR "right
to be forgotten" stuff. To my perspective, Gemini is important a line
from the internet-draft that is directly contrary to its mission.

Combining Gemini's mission with that realisation means that if no
statement has been made about whether the given user (server operator
in this specific case) is OK with their content being archived, the
presumption should be that they are not OK with it. We should value
user privacy above archiver convenience.

In affect, we add a second exception to the protocal that amends 2.2.1
to end "if no rules are specified, this robots.txt file MUST be
assumed".

On a practical level, being excluded from search engines by-default
drives the discoverability of robots.txt, and server software could
easily include flags like --permit-indexing or --permit-archival to
streamline that discoverability. I don't think that opt-in rates would
be similar to current opt-out rates on the Web.

/Nick


From johann at qwertqwefsday.eu  Tue Nov 24 17:06:32 2020
From: johann at qwertqwefsday.eu (Johann Galle)
Date: Tue, 24 Nov 2020 18:06:32 +0100
Subject: robots.txt for Gemini formalised
In-Reply-To: <c81a0b58f64239ddc35ef4c8f45fd0d01ca342aa.camel@ur.gs>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <c81a0b58f64239ddc35ef4c8f45fd0d01ca342aa.camel@ur.gs>
Message-ID: <a1773196-446b-8984-da84-3908e4a37fa7@qwertqwefsday.eu>

Nick Thomas wrote:> I don't think that opt-in rates would be similar to current opt-out rates
> on the Web.
This can probably be summed up with one question:
Why do we want a robots.txt in the first place? After all, if there were no
reasons against archival et al., we would not need a robots.txt at all. And
IMHO this also is the reason why it should rather be an opt-in system.

-- 
You can verify the digital signature on this email with the public key available
through web key discovery.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201124/944dd2b6/attachment.sig>

From gemini at ur.gs  Tue Nov 24 17:12:40 2020
From: gemini at ur.gs (Nick Thomas)
Date: Tue, 24 Nov 2020 17:12:40 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
Message-ID: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>

On Tue, 2020-11-24 at 13:31 +0000, James Tomasino wrote:
> 
> As much as I'd love to wave a magic wand and say, "it's all opt-in
> here" we don't really have any legal footing to do so.
> 

James and I talked a bit more about this one on IRC. Key to this
argument, AIUI, is how robots.txt (or the lack of it) is treated for
FTP, which lacks any mention of it in the spec but has apparently been
given weight in DMCA-related rulings involving it.

I'm not sure I agree with the reasoning, which goes something like "the
robots.txt Internet-Draft is already de-jure part of Gemini, and we
can't change that", but IANAL ^^. In particular, I've been thinking
about this almost entirely in GDPR terms so far, and have a bunch of
DMCA-related reading to do now.

In the event that it *is* accurate, we talked about an alternative way
to implement the functionality.  Rather than having the gemini
robots.txt spec say "if the client doesn't receive a robots.txt, it
must assume this one", the *server* could be made to return a defined
robots.txt response body if it would otherwise issue a 51 response to
`/robots.txt`

(51 may be too specific, it could be 5x, but I don't *think* it would
be appropriate in response to 4x responses, which crawlers would be
expected to retry).

Of course, any server could do that already today, so the ask is to put
a recommendation about it into "server best practice", perhaps
incorporating the `--permit-indexing` and `--permit-archiving` flags I
talked about in another post.

Another advantage of this approach is that it becomes opaque to crawler
authors whether the user has explicitly selected a preference or not.
I'm also inclined to trust server implementors over crawler
implementors.

/Nick

p.s. there was also some question as to whether someone hosting gemini
content was a "gemini user", in the way we use that term on the project
homepage. To me, it seems like a reasonable extrapolation, but perhaps
it's a topic that deserves more debate or clarification.


From tomasino at lavabit.com  Tue Nov 24 17:27:27 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 24 Nov 2020 17:27:27 +0000
Subject: robots.txt for Gemini formalised
In-Reply-To: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
References: <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
Message-ID: <27fb8ce5-6a52-a105-7740-be04cc4ba3c1@lavabit.com>

On 11/24/20 5:12 PM, Nick Thomas wrote:
> On Tue, 2020-11-24 at 13:31 +0000, James Tomasino wrote:
>> As much as I'd love to wave a magic wand and say, "it's all opt-in
>> here" we don't really have any legal footing to do so.
>>
> James and I talked a bit more about this one on IRC. Key to this
> argument, AIUI, is how robots.txt (or the lack of it) is treated for
> FTP, which lacks any mention of it in the spec but has apparently been
> given weight in DMCA-related rulings involving it.
> 
> I'm not sure I agree with the reasoning, which goes something like "the
> robots.txt Internet-Draft is already de-jure part of Gemini, and we
> can't change that", but IANAL ^^. In particular, I've been thinking
> about this almost entirely in GDPR terms so far, and have a bunch of
> DMCA-related reading to do now.

In addition to FTP, gopher adopted the robots.txt standard almost immediately:

https://groups.google.com/g/comp.internet.net-happenings/c/Iv8ylGxvoh8?pli=1

You can read the IETF spec for the Robots Exclusion Protocol here:
https://tools.ietf.org/html/draft-rep-wg-topic-00

As you'll note in "2.3.  Access method", their documentation isn't scheme specific and they even list FTP as a valid option.

This is the document that will be used in court by anyone defending an indexer and any exclusion you want to obtain for Gemini would need to happen there. Having a contradictory statement in the Gemini spec will not stand up against the history and precedence of this one.

If you want to implement stronger protections in Gemini then I'd suggest adding a note in the best-practices document for server creators to (as Nick suggested) serve a robots.txt if no such file exists with the contents:

User-agent: *
Disallow: /

That achieves your aim of block-by-default and the opt-in would be the creation of a robots.txt file of your own.


From khuxkm at tilde.team  Tue Nov 24 19:08:57 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Tue, 24 Nov 2020 19:08:57 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
Message-ID: <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>

I am personally against this idea of forcing (or even normalizing) browsers giving special treatment to a request for a URL based on what the server would normally respond (I'm not even going to entertain the idea of pretending the internet draft doesn't apply to us). This is what I assume it would look like in spec (or best practices, or wherever you want to put it):

> When a client makes a request for a URI with a path component of "/robots.txt", and the server would normally respond to such a request with a 51 Not Found status code, it should instead respond with a 20 status code, a MIME type of text/plain, and content of "User-Agent: *\r\nDisallow: /\r\n". This prevents capsules from being indexed without consent.

Doesn't that just *feel* like a hack to you?

I did some research with GUS's known-hosts list. Of the 362 hosts known to GUS, only 36 have a robots.txt file, so any choice made as to what the default robots.txt should be will affect around 90% of Geminispace (not to mention any new hosts to come). Notably, of the 36 hosts to impose a robots.txt, 7 of them completely block archiving (although that number is skewed, as I know that at least 3 of those hosts are ran by the same person, and 2 of those hosts are ran by another person). This means that anywhere between 2% (all of the hosts who don't have a robots.txt are fine with being archived) to 20% (the sample of people who have robots.txt is representative of the whole population), or even 91% (everybody without a robots.txt doesn't want to be archived). I don't feel comfortable making a declaration either way, but this is food for thought.

Just my two cents,
Robert "khuxkm" Miles

From trevor at rocketnine.space  Tue Nov 24 17:53:46 2020
From: trevor at rocketnine.space (trevor at rocketnine.space)
Date: Tue, 24 Nov 2020 17:53:46 +0000
Subject: [ANN] gmitohtml, a Gemini to HTML proxy written in Go
Message-ID: <056358978df691cd4a6108014d833132@rocketnine.space>

gmitohtml, a Gemini to HTML proxy, is now available. It can run as a daemon,
which allows browsing Gemini pages using a standard web browser. It can also run
as a document conversion tool, reading from standard input.

gmitohtml is available on Android devices as Xenia.

https://gitlab.com/tslocum/gmitohtml
https://gitlab.com/tslocum/xenia

From solderpunk at posteo.net  Tue Nov 24 19:03:28 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 24 Nov 2020 20:03:28 +0100
Subject: robots.txt for Gemini formalised
In-Reply-To: <C7BJWJDU98AZ.AJ6OKBU5HUEO@taiga>
Message-ID: <C7BQ6YBE90F9.AS7TK1X4E9BF@stilgar>

On Tue Nov 24, 2020 at 3:07 PM CET, Drew DeVault wrote:

> Web portals are users, plain and simple. Anyone who blocks a web portal
> is blocking legitimate users who are engaging in legitimate activity.
> This is a dick move and I won't stand up for anyone who does it.

This has actually long been a bit of a contentious point in the
Gopherverse, and we have inherited a bit of the controversy, if I
remember much earlier discussions accurately.  There are some people
(a vocal minority?  I'm not sure), who feel that public web proxies
exposing their Gopherhole/capsule to the entire browser-using world are
negating the agency they exercised in very deliberately putting some
content up only on Gopher/Gemini and not the web.  Web proxies force
them to be visible in (and linkable from) a space that they are actively
trying not to participate in.

While I am aware of the ultimate futility of trying to control where
publically served online content ends up, I have some sympathy for this
perspective (perhaps even more so now that we have very nice tools like
your own Kineto by which people who *do* want their content to be
accessible from a browser can achieve this easily).  When the first web
portals for Gemini turned up, some people expressed interest in being
able to opt out, to keep their Gemini-only content truly Gemini-only,
and at least one of those early web portals (portal.mozz.us) agreed to
respect those wishes.  The webproxy user agent I put into the first
robots.txt draft is actually just codifying what portal.mozz.us has
already been doing for many months.  I did not expect its inclusion to
be so controversial.  I *did* try to word it carefully so that personal
webproxies which, e.g. run on a user's local machine and are not
publically accessible need not abide by robots.txt, as those are really
just roundabout Gemini clients.

Cheers,
Solderpunk


From gemini at ur.gs  Tue Nov 24 20:25:05 2020
From: gemini at ur.gs (Nick Thomas)
Date: Tue, 24 Nov 2020 20:25:05 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
Message-ID: <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>

On Tue, 2020-11-24 at 19:08 +0000, Robert "khuxkm" Miles wrote:

> Doesn't that just *feel* like a hack to you?

It definitely feels hackish when worded like this :).

The precise technical form is secondary to the outcome (as I see it) of
protecting users from a privacy-hostile default in the robots.txt
specification. I appreciate that you're currently an opt-out, rather
than opt-in, advocate, but I'd still appreciate any ideas you have to
make it nicer *if* gemini ends up going for opt-in.

An alternative form that just came to mind is a server implementation
recommendation like this:

```
Geminispace crawlers use the /robots.txt request path to determine
whether a capsule can be accessed for archival, indexing, research, and
other purposes. This can have privacy implications for the user, so
servers should not start unless they have an explicit signal on how to
handle requests to the /robots.txt path.

For example, this signal may be the availability of any content for the
/robots.txt path, a user-added database entry indicating that the path
should receive a 5x response, or a non-default configuration parameter
specifying that it's OK to skip the check.

If no such signal is present, the server should emit an error message
and either exit immediately, or allow the user to specify how the path
should be handled.
```

As a new server operator with no idea about `robots.txt`, I'd run, say:

```
$ agate [::]:1995 mysite cert.pem key.rsa ur.gs

No robots.txt file present! Please create mysite/robots.txt, or re-run
Agate with --permit-robots to allow your content to be archived,
indexed, or otherwise used by automated crawlers of Geminispace
```

*I'd* think "hang on, I don't want my content to be archived" and go
off to learn about this robots.txt thing; others might shrug and just
add the --permit-robots flag. 

>  Of the 362 hosts known to GUS, only 36 have a robots.txt file, so
> any choice made as to what the default robots.txt should be will
> affect around 90% of Geminispace 

Thanks for running the numbers on this. I agree with everything you
said based on them. That any change affects such a large proportion of
existing geminispace is especially worth emphasising.

/Nick


From me at adnano.co  Tue Nov 24 21:44:07 2020
From: me at adnano.co (Adnan Maolood)
Date: Tue, 24 Nov 2020 16:44:07 -0500
Subject: Requiring schemes in Gemini requests
Message-ID: <C7BTLYBN1DIB.3SC92SWK7TFJV@nitro>

Not requiring schemes in Gemini requests has led to lots of confusion.
I propose that Gemini requests must contain a scheme.

This will make things simpler for server authors, who will not have to
check for the scheme "gemini" as well as check for an empty scheme.
Some servers do not properly handle this anyways.

Linking to a URL without a scheme should still work. It would be up to
the client to resolve the URL reference before making the request. This
functionality should already be provided by whatever library the client
uses to handle relative URLs.

From acdw at acdw.net  Tue Nov 24 22:27:34 2020
From: acdw at acdw.net (acdw)
Date: Tue, 24 Nov 2020 22:27:34 +0000
Subject: Requiring schemes in Gemini requests
In-Reply-To: <C7BTLYBN1DIB.3SC92SWK7TFJV@nitro>
References: <C7BTLYBN1DIB.3SC92SWK7TFJV@nitro>
Message-ID: <5d0b3eab-2437-4c0c-9836-0abd13d27bb0@www.fastmail.com>

On 2020-11-24 (Tuesday) at 21:44, Adnan Maolood <me at adnano.co> wrote:

> Not requiring schemes in Gemini requests has led to lots of confusion.
> I propose that Gemini requests must contain a scheme.
> 
> This will make things simpler for server authors, who will not have to
> check for the scheme "gemini" as well as check for an empty scheme.
> Some servers do not properly handle this anyways.
> 
> Linking to a URL without a scheme should still work. It would be up to
> the client to resolve the URL reference before making the request. This
> functionality should already be provided by whatever library the client
> uses to handle relative URLs.
>

I very much agree with this, and there's recently been a long discussion on the very matter: https://lists.orbitalfox.eu/archives/gemini/2020/003361.html

I don't recall it being resolved, however.  I think the Gemini spec should be revised to be compliant with the URL RFCs.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From ben at benaaron.dev  Tue Nov 24 23:30:52 2020
From: ben at benaaron.dev (Ben Goldberg)
Date: Tue, 24 Nov 2020 18:30:52 -0500
Subject: Requiring schemes in Gemini requests
In-Reply-To: <5d0b3eab-2437-4c0c-9836-0abd13d27bb0@www.fastmail.com>
References: <C7BTLYBN1DIB.3SC92SWK7TFJV@nitro>
 <5d0b3eab-2437-4c0c-9836-0abd13d27bb0@www.fastmail.com>
Message-ID: <e908ec94-aa54-fddc-2f05-5c17a8ab3a9c@benaaron.dev>

I also agree. I just finished implementing this in my gemini server and 
it was a pain. I had to switch from a URL parser to a URI parser.

From gemini at ur.gs  Tue Nov 24 23:30:56 2020
From: gemini at ur.gs (Nick Thomas)
Date: Tue, 24 Nov 2020 23:30:56 +0000
Subject: [ANN] Capsule announcement - ur.gs
Message-ID: <1742f23998f67c42d40a2638cd0e5dad1eaa95cb.camel@ur.gs>

It's been intermittently up and down for ages now, but I finally got
around to deploying gemini://ur.gs properly with TOFU TLS, and
(manually) converted my old blogs and so on. It's not very interesting,
but it is present. I've said this about it many times in the past, but
I'll see if I can add new items on a semi-regular basis for a while.

Special bonus feature: each page served directly from a box in my
hallway, up here in Shetland.

I'm using Ages + Kiln; overall, very nice, although I struggled to work
out what Kiln expected of me inside src/ to begin with.

I *couldn't* quickly work out how to get the /img, /pdf, and /traces
entries not to appear in the automatic listing in /index.gmi. So I
created `index.gmi` files for each, so the links would at least not be
broken. I expected that to result in autogenerated links to each of the
(non-gmi) files, but that didn't happen either, so it's a bit of a
weird halfway situation.

I'm a heavy user of inline links in prose, but I found that it (mostly)
converted in a natural style, without needing a great deal of
restructuring. I think there's still a bunch of inline preformatted
text (`like this`) that I need to reformat, though.

Need to work out the feeds.

Of course, gemini://ur.gs/robots.txt is present and correct ;)

I was intending to have https://ur.gs issue redirects to the matching
gemini pages, but I've realised I host a bunch of Very Large GIFs there
that are externally linked, so I've got to untangle that knot first.

/Nick


From cowan at ccil.org  Tue Nov 24 23:44:23 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 24 Nov 2020 18:44:23 -0500
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
Message-ID: <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>

On Tue, Nov 24, 2020 at 3:25 PM Nick Thomas <gemini at ur.gs> wrote:


> >  Of the 362 hosts known to GUS, only 36 have a robots.txt file, so
> > any choice made as to what the default robots.txt should be will
> > affect around 90% of Geminispace
>
> Thanks for running the numbers on this. I agree with everything you
> said based on them. That any change affects such a large proportion of
> existing geminispace is especially worth emphasising.
>

Why is that a Good Thing?  It's another piece of bureaucracy: 90% of hosts
were happy to be archived before, so now they have to write a robots.txt
file.  Although small for any one server operator, it is large when
multiplied by the number of servers there *will be*.  "Small Internet" does
not mean "Internet with only a few servers", AFAIK.

Two things about the Internet Archive:

1) It is a U.S. public library, which gives it special rights when it comes
to making copies.

2) Though it does not respect robots.txt, it is happy to make your content
invisible to archive users by informal request (or, of course, by a DCMA
takedown notice).



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Gules six bars argent on a canton azure 50 mullets argent
six five six five six five six five and six
   --blazoning the U.S. flag <http://web.meson.org/blazonserver>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201124/cf7c7400/attachment.htm>

From tomasino at lavabit.com  Tue Nov 24 23:47:29 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Tue, 24 Nov 2020 23:47:29 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
Message-ID: <e6706f44-88c1-91c6-f705-6528d4d7a1ee@lavabit.com>

On 11/24/20 11:44 PM, John Cowan wrote:
> 2) Though it does not respect robots.txt, it is happy to make your
> content invisible to archive users by informal request (or, of course,
> by a DCMA takedown notice).

The Internet Archive does respect robots.txt, though they're not happy
about it and have written on the subject a few times. I included a
snippet in an earlier email with their user-agent.


From gemini at ur.gs  Wed Nov 25 00:18:16 2020
From: gemini at ur.gs (Nick Thomas)
Date: Wed, 25 Nov 2020 00:18:16 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
Message-ID: <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>

On Tue, 2020-11-24 at 18:44 -0500, John Cowan wrote:
> On Tue, Nov 24, 2020 at 3:25 PM Nick Thomas <gemini at ur.gs> wrote:
> 
> > Thanks for running the numbers on this. I agree with everything you
> > said based on them. That any change affects such a large proportion
> > of
> > existing geminispace is especially worth emphasising.
> > 
> 
> Why is that a Good Thing? 

I very intentionally *didn't* say it was a good thing :). There are
many ways to interpret the data, but I'm still glad we have it.

> It's another piece of bureaucracy: 90% of hosts
> were happy to be archived before

You're presuming consent here. We don't actually *know* that said 90%
of hosts are happy to be archived; we only know that 90% of hosts
haven't included a robots.txt file, which could be for any one of a
multitude of reasons.

*If* a not-insignificant proportion of those hosts without robots.txt
files would actually prefer not to be included in archives when asked,
the current situation is not serving their privacy well, and gemini is
suppose to be protective of user privacy. *If* an overwhelming majority
of them simply don't care, then sure, the argument for it starts to
look a bit niche. Talking in IRC earlier today, I hand-waved a 5%
threshold for the first condition and 1% for the second.

A personal example: *I* didn't have a robots.txt on my capsule file
until today, but I don't want to be included in archives for various
reasons. Presuming consent from the lack of a robots.txt file would
have incorrectly guessed my preference, and harmed my privacy. Who else
in that 90% is like me? We don't know.

> so now they have to write a robots.txt
> file.  Although small for any one server operator, it is large when
> multiplied by the number of servers there *will be*.  "Small
> Internet" does
> not mean "Internet with only a few servers", AFAIK.

Yes, there is a convenience/privacy trade-off here. I interpret
gemini's mission to favour privacy over convenience when the two come
into conflict.

> Two things about the Internet Archive:
> 
> 1) It is a U.S. public library, which gives it special rights when it
> comes
> to making copies.

Certainly true, and there will be cases where, even when you do have
wonderfully hand-crafted robots.txt file like the one I made today, an
archiver determines that they can legally scrape you anyway. Others
will scrape illegally, whether through malice or ignorance.

Meanwhile, Google, the Internet Archive, and a bunch of other people
respect robots.txt even when they might not be legally *required* to
via GDPR-like provisions. A control doesn't have to be perfect to be
desirable. This argument comes up in the context of "right to be
forgotten" quite a lot ^^.

> 2) Though it does not respect robots.txt, it is happy to make your
> content
> invisible to archive users by informal request (or, of course, by a
> DCMA
> takedown notice).

As I understand it, archive.org does respect robots.txt in general, but
has exceptions for certain sites it's identified it has a public
interest justification for. That includes the US military, but probably
doesn't include any currently-existing gemini site.

/Nick


From me at adnano.co  Wed Nov 25 00:54:42 2020
From: me at adnano.co (Adnan Maolood)
Date: Tue, 24 Nov 2020 19:54:42 -0500
Subject: [ANN] Capsule announcement - ur.gs
In-Reply-To: <1742f23998f67c42d40a2638cd0e5dad1eaa95cb.camel@ur.gs>
Message-ID: <C7BXNVML5HZO.1EMG4F37HST5E@nitro>

On Tue Nov 24, 2020 at 6:30 PM EST, Nick Thomas wrote:
> I'm using Ages + Kiln; overall, very nice, although I struggled to work
> out what Kiln expected of me inside src/ to begin with.
>
> I *couldn't* quickly work out how to get the /img, /pdf, and /traces
> entries not to appear in the automatic listing in /index.gmi. So I
> created `index.gmi` files for each, so the links would at least not be
> broken. I expected that to result in autogenerated links to each of the
> (non-gmi) files, but that didn't happen either, so it's a bit of a
> weird halfway situation.

Thanks for the feedback! I'll work on improving the documentation.

The default index template includes links to directories by default.
I wasn't sure if this would be a desired feature, and I can remove it.

The default template also only includes links for any Gemini files in a
directory. I could expose the non-Gemini files to the template so you
could list them manually if you desire.

You can always create your own templates if the default ones don't work
well. The default templates can be found at
https://git.sr.ht/~adnano/kiln/tree/master/templates/

From sean at conman.org  Wed Nov 25 02:57:25 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 24 Nov 2020 21:57:25 -0500
Subject: Requiring schemes in Gemini requests
In-Reply-To: <e908ec94-aa54-fddc-2f05-5c17a8ab3a9c@benaaron.dev>
References: <C7BTLYBN1DIB.3SC92SWK7TFJV@nitro>
 <5d0b3eab-2437-4c0c-9836-0abd13d27bb0@www.fastmail.com>
 <e908ec94-aa54-fddc-2f05-5c17a8ab3a9c@benaaron.dev>
Message-ID: <20201125025725.GK1721@brevard.conman.org>

It was thus said that the Great Ben Goldberg once stated:
> I also agree. I just finished implementing this in my gemini server and 
> it was a pain. I had to switch from a URL parser to a URI parser.

  Agree.  As I mentioned earlier [1], 0.2% of all requests were schemeless
to my server, and only three clients accounted for that traffic.  Make the
Gemini request a full URL.

  -spc

[1]	https://lists.orbitalfox.eu/archives/gemini/2020/003392.html


From me at adnano.co  Wed Nov 25 05:02:35 2020
From: me at adnano.co (Adnan Maolood)
Date: Wed, 25 Nov 2020 00:02:35 -0500
Subject: On the use of %20 instead of + in URIs
Message-ID: <C7C2XO98PIDB.15J56R2JVFINO@nitro>

Section 1.2 of the Gemini specification says:

> Spaces in gemini URIs should be encoded as %20, not +.

I noticed that some servers do not properly handle +, treating it as a
literal plus sign. Since this is a recommendation and not a must,
shouldn't servers treat plus signs as spaces? Not allowing spaces makes
it slightly more difficult to use URL parsing libraries which use plus
signs.

If servers should not treat plus signs as spaces, then I think that this
portion of the specification should be changed to say:

> Spaces in gemini URIs MUST be encoded as %20, not +.

Otherwise, I think an additional clarification is in order:

> Spaces in gemini URIs should be encoded as %20, not +.
> However, software should still treat + as a space.

From gemini at ur.gs  Wed Nov 25 11:32:37 2020
From: gemini at ur.gs (Nick Thomas)
Date: Wed, 25 Nov 2020 11:32:37 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
Message-ID: <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>

(Received off-list, but I assume it was *meant* for the list, so
replying there)

On Wed, 2020-11-25 at 00:36 -0500, John Cowan wrote:
> 
> I understand "user privacy" to mean the privacy of people using
> clients.
> What privacy do server operators expect to have, unless they are
> using
> client certs, firewalls, or other such blockers?  Barring those, they
> are
> serving content to all the world.

Yes, I've got a p.s. somewhere on the list around this potential
objection.

I don't think that server operators (perhaps better: "capsule authors")
have been explicitly ruled in when talking about user privacy in gemini
so far; but I also don't think they've been explicitly ruled out - it
just hadn been a live issue until the first archiver showed up and
(presumably in response to that) the robots.txt spec was published.

I don't find it a stretch at all to see capsule authors as gemini
users, but if we were to end up excluding them from the category for
some reason, my proposal certainly looks a lot less interesting.

Whatever the outcome of the opt-in vs opt-out part of this discussion,
the robots.txt spec gives weight to the expressed preferences of
capsule authors.. Crawler authors are being asked to respect those
preferences, and one of the possible motivations for that is a
recognition that the privacy of capsule authors is harmed by not
respecting their preferences.

Saying "I want to be in search indexes but not archives" is likely to
be motivated by privacy concerns, and an explicit robots.txt is one way
that I, as a capsule author, can expect to have privacy from archives.
If it's true for people with an explicit preference, it can also be
true for people who haven't expressed a preference yet. Since Gemini
has a higher standard for user privacy than the web, it can also have a
higher standard for these preferences - one that does not rely on
presumed consent - if we want it to.

> > As I understand it, archive.org does respect robots.txt in general,
> 
> Not since 2018.  See <
> https://help.archive.org/hc/en-us/articles/360004651732-Using-The-Wayback-Machine>;,
> which was updated 5 days ago and says:

The FAQ immediately above the one you quoted reads:

> Why isn't the site I'm looking for in the archive?*

> Some sites may not be included because the automated crawlers were
> unaware of their existence at the time of the crawl. It's also 
> possible that some sites were not archived because they were 
> password protected, blocked by robots.txt, or otherwise inaccessible 
> to our automated systems. Site owners might have also requested that 
> their sites be excluded from the Wayback Machine.

If archive.org didn't respect robots.txt at all, it would lend a lot of
flavour to the "archiver" virtual user-agent idea in the companion
spec, in addition to this discussion. Do you still have doubts after
reading this section?

/Nick


From gemini at ur.gs  Wed Nov 25 11:38:37 2020
From: gemini at ur.gs (Nick Thomas)
Date: Wed, 25 Nov 2020 11:38:37 +0000
Subject: [ANN] Capsule announcement - ur.gs
In-Reply-To: <C7BXNVML5HZO.1EMG4F37HST5E@nitro>
References: <C7BXNVML5HZO.1EMG4F37HST5E@nitro>
Message-ID: <6208c1b423c4b75076baae925c1a1b9af7a9ec45.camel@ur.gs>

Hi,

On Tue, 2020-11-24 at 19:54 -0500, Adnan Maolood wrote:
> 
> The default index template includes links to directories by default.
> I wasn't sure if this would be a desired feature, and I can remove
> it.

The problems I encountered with this default were:

* My index.gmi came with links that gave a 51 when clicked
* The link text is not configurable except by creating an index.gmi
* Vendoring the template with some changes is a big step up :D

Since it's easy to create an `index.gmi` in the subdirectory to cause
the link to appear, I'd definitely prefer it if subdirectories without
one didn't get a link by default \o/

> The default template also only includes links for any Gemini files in
> a
> directory. I could expose the non-Gemini files to the template so you
> could list them manually if you desire.

I think the current behaviour is the right call here - I don't actually
want my /img to have an autogenerated index. It would be good to make
it easy to generate one if desired though, since I can easily see other
people wanting to do simple galleries this way.

/Nick


From bjorn.warmedal at gmail.com  Wed Nov 25 12:58:19 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Wed, 25 Nov 2020 13:58:19 +0100
Subject: On certificates and validation
Message-ID: <CAJScK0KNOv=E2B2Qo8sU=pHE8DFROoFs-7rgyGufR92=xNr-rA@mail.gmail.com>

I'm building a lib to simplify gemini client development in python,
and my current headache is certification handling. There's a few
things that come to mind, some more philosophical than technical in
nature.

* Should I support verification of CA-issued certificates, or
self-signed only? Doing both at the same time leads to a "try this, if
fail then try this" sort of situation which isn't very pretty. How
common are CA-issued certificates in geminispace, and should they be
handled differently than TOFU?
* How does one even validate a self-signed cert? If ew0k.example.com
serves a certificate with the Common Name "ew0k's Awesome Site" and no
Subject Alternative Names, is that less valid than one that includes
the hostname? Or the IP? Does expiration time matter at all for a
self-signed cert?
* When a browser has accepted one cert for example.com but is
presented another on the next visit, it shows a warning to the user
who will then decide whether to accept the new cert. What information
allows a user to make an informed decision in this case? Does it
matter that the last cert would still be valid for another 3 years? Or
2 months?

Any opinions or advice welcomed :)

Cheers,
ew0k

From sir at cmpwn.com  Wed Nov 25 12:58:55 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 25 Nov 2020 07:58:55 -0500
Subject: On certificates and validation
In-Reply-To: <CAJScK0KNOv=E2B2Qo8sU=pHE8DFROoFs-7rgyGufR92=xNr-rA@mail.gmail.com>
Message-ID: <C7CD2DP18NIT.2OAI6N8UP237F@taiga>

On Wed Nov 25, 2020 at 7:58 AM EST, Bj?rn W?rmedal wrote:
> I'm building a lib to simplify gemini client development in python,
> and my current headache is certification handling. There's a few
> things that come to mind, some more philosophical than technical in
> nature.
>
> * Should I support verification of CA-issued certificates, or
> self-signed only? Doing both at the same time leads to a "try this, if
> fail then try this" sort of situation which isn't very pretty. How
> common are CA-issued certificates in geminispace, and should they be
> handled differently than TOFU?

I strongly recommend not checking for CA-signed certificates, and only
supporting TOFU.

> * How does one even validate a self-signed cert? If ew0k.example.com
> serves a certificate with the Common Name "ew0k's Awesome Site" and no
> Subject Alternative Names, is that less valid than one that includes
> the hostname? Or the IP? Does expiration time matter at all for a
> self-signed cert?

Yes, test the common name and/or alternative names, and the expiration
time.

> * When a browser has accepted one cert for example.com but is
> presented another on the next visit, it shows a warning to the user
> who will then decide whether to accept the new cert. What information
> allows a user to make an informed decision in this case? Does it
> matter that the last cert would still be valid for another 3 years? Or
> 2 months?

The SHA-256 of the certificate is helpful in this, because they use it
to verify the certificate's authenticity out of band (e.g. email the
operator, call a friend on a different ISP, etc).

You may find this article I wrote on TOFU helpful:

gemini://drewdevault.com/2020/09/21/Gemini-TOFU.gmi

From bjorn.warmedal at gmail.com  Wed Nov 25 13:16:15 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Wed, 25 Nov 2020 14:16:15 +0100
Subject: On certificates and validation
In-Reply-To: <C7CD2DP18NIT.2OAI6N8UP237F@taiga>
References: <CAJScK0KNOv=E2B2Qo8sU=pHE8DFROoFs-7rgyGufR92=xNr-rA@mail.gmail.com>
 <C7CD2DP18NIT.2OAI6N8UP237F@taiga>
Message-ID: <CAJScK0K0bXOWdzqgOsHjRAyxb7LkuCD0sAp+dYZ8wKPfus-pbQ@mail.gmail.com>

> > * How does one even validate a self-signed cert? If ew0k.example.com
> > serves a certificate with the Common Name "ew0k's Awesome Site" and no
> > Subject Alternative Names, is that less valid than one that includes
> > the hostname? Or the IP? Does expiration time matter at all for a
> > self-signed cert?
>
> Yes, test the common name and/or alternative names, and the expiration
> time.

So basically at least one of Common Name and Subject Alternative Names
should match the hostname provided? What if it doesn't, but it matches
the IP?

I guess I could press this issue even more, really. There's a
technical difficulty in parsing wildcards, for example, depending on
the libs available. If I request some.subdomain.example.com and the
certificate lists "some.*.example.com" the ssl._dnsname_match() method
in python3 won't be able to match it despite it being a valid wildcard
(afaik). I don't really know what the certificate specification says
here, but with self-signed certs we can write pretty much anything. My
example of a Common Name that doesn't have a hostname would fail under
your validation algorithm, but is it objectively *wrong*?

Under a TOFU scheme I could also encounter a situation where a cert I
have accepted has now expired, but the server still provides it. Is it
*wrong* to still accept it?

> You may find this article I wrote on TOFU helpful:
>
> gemini://drewdevault.com/2020/09/21/Gemini-TOFU.gmi

Thank you for this!

From sir at cmpwn.com  Wed Nov 25 13:17:23 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 25 Nov 2020 08:17:23 -0500
Subject: On certificates and validation
In-Reply-To: <CAJScK0K0bXOWdzqgOsHjRAyxb7LkuCD0sAp+dYZ8wKPfus-pbQ@mail.gmail.com>
Message-ID: <C7CDGIP2CKQQ.39HSXJN808TB8@taiga>

On Wed Nov 25, 2020 at 8:16 AM EST, Bj?rn W?rmedal wrote:
> So basically at least one of Common Name and Subject Alternative Names
> should match the hostname provided? What if it doesn't, but it matches
> the IP?

Hm, I'm not sure. Check the spec? I have never put an IP address into a
certificate.

> I guess I could press this issue even more, really. There's a
> technical difficulty in parsing wildcards, for example, depending on
> the libs available. If I request some.subdomain.example.com and the
> certificate lists "some.*.example.com" the ssl._dnsname_match() method
> in python3 won't be able to match it despite it being a valid wildcard
> (afaik). I don't really know what the certificate specification says
> here, but with self-signed certs we can write pretty much anything.

Technically you can make up your own CA and sign whatever bullshit certs
you want. So what? That doesn't change the interpretation of the
specification.

> My example of a Common Name that doesn't have a hostname would fail
> under your validation algorithm, but is it objectively *wrong*?

Yes.

> Under a TOFU scheme I could also encounter a situation where a cert I
> have accepted has now expired, but the server still provides it. Is it
> *wrong* to still accept it?

Yes.

From sir at cmpwn.com  Wed Nov 25 13:22:38 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Wed, 25 Nov 2020 08:22:38 -0500
Subject: On certificates and validation
In-Reply-To: <CAJScK0K0bXOWdzqgOsHjRAyxb7LkuCD0sAp+dYZ8wKPfus-pbQ@mail.gmail.com>
Message-ID: <C7CDKJ6DX8QY.5Y94X6Y1GZZF@taiga>

Something worth mentioning is that the reason I discourage the use of
CAs and encourage some baseline sanity checks on certificate validity is
because I don't expect sysadmins to be handling certificates at all.

Certificates are annoying and easily fucked up. That easily-fucked-up
bit is probably why you're hand-wringing over whether or not to accept
invalid certificates. However, with TOFU, there's no reason for
sysadmins to generate their own certificates at all. My server software
(gmnisrv) handles certificate generation and rotation entirely
automatically, without any help from the sysadmin whatsoever. They
cannot make a mistake because the software does it for them, and the
software does it correctly.

With a TOFU system like Gemini, there's no reason whatsoever that we
should bring along the legacy nonsense of certificate authorities and
manual human-operated certificate maintanence.

From cowan at ccil.org  Wed Nov 25 15:10:44 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 25 Nov 2020 10:10:44 -0500
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
Message-ID: <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>

On Wed, Nov 25, 2020 at 6:32 AM Nick Thomas <gemini at ur.gs> wrote:

> (Received off-list, but I assume it was *meant* for the list, so
> replying there)
>

It was, so thanks.  My private messages are labeled (Private message) at
the top because I make this mistake a lot.

Whatever the outcome of the opt-in vs opt-out part of this discussion,
>

That's the only part that concerns me.  A robots.txt spec is good and
crawlers/archivers that respect it are fine too, though of course some
won't.

I once wrote to the author of a magazine article who had published a simple
crawler that it would hammer whatever server it was crawling, since it did
not delay between requests or intersperse them with requests to other
servers, but simply walked the server's tree depth-first. and that it
should respect robots.txt.  He wrote back saying "That's the Internet
today; deal with it."  I could have answered (but I didn't) that hits are a
cost to the server operator, and anyone running his dumb crawler was not
only DDOSing, but spending my money for his own purposes.

But I do think that once robots.txt support is in place, no robots.txt = no
expressed preference.

If it's true for people with an explicit preference, it can also be
> true for people who haven't expressed a preference yet. Since Gemini
> has a higher standard for user privacy than the web, it can also have a
> higher standard for these preferences - one that does not rely on
> presumed consent - if we want it to.
>

By this logic, nobody should be able to access a Gemini server at all
unless the capsule author has expressed a preference for them to do so.
But to publish is to expose your work to the public.

> The FAQ immediately above the one you quoted reads:
>
> > Why isn't the site I'm looking for in the archive?*
>
> > Some sites may not be included because the automated crawlers were
> > unaware of their existence at the time of the crawl. It's also
> > possible that some sites were not archived because they were
> > password protected, blocked by robots.txt, or otherwise inaccessible
> > to our automated systems. Site owners might have also requested that
> > their sites be excluded from the Wayback Machine.
>

I interpret that to mean that some sites were not crawled during the period
when the Archive was paying attention to robots.txt, and so their content
as of that date is unavailable.  Note the past tense:  "were [...]
protected by robots.txt" as opposed to "are protected".

> If archive.org didn't respect robots.txt at all, it would lend a lot of
> flavour to the "archiver" virtual user-agent idea in the companion
> spec, in addition to this discussion. Do you still have doubts after
> reading this section?
>

I have no doubt whatever that the crawler doesn't respect robots.txt.  I
could do a little experiment, though.

John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
The competent programmer is fully aware of the strictly limited size of his
own
skull; therefore he approaches the programming task in full humility, and
among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201125/7813ec46/attachment-0001.htm>

From me at adnano.co  Wed Nov 25 15:00:37 2020
From: me at adnano.co (Adnan Maolood)
Date: Wed, 25 Nov 2020 10:00:37 -0500
Subject: [ANN] Capsule announcement - ur.gs
In-Reply-To: <6208c1b423c4b75076baae925c1a1b9af7a9ec45.camel@ur.gs>
Message-ID: <C7CFNKB2K8EZ.3L5Z2OML06OOJ@nitro>

On Wed Nov 25, 2020 at 6:38 AM EST, Nick Thomas wrote:
> The problems I encountered with this default were:
>
> * My index.gmi came with links that gave a 51 when clicked
> * The link text is not configurable except by creating an index.gmi
> * Vendoring the template with some changes is a big step up :D
>
> Since it's easy to create an `index.gmi` in the subdirectory to cause
> the link to appear, I'd definitely prefer it if subdirectories without
> one didn't get a link by default \o/

I think I'll go ahead and remove the directory listings, then.
You can link to any directory in the contents of the index.gmi file, and
the link will show up above the page links.

From marcx2 at welz.org.za  Wed Nov 25 15:22:36 2020
From: marcx2 at welz.org.za (marc)
Date: Wed, 25 Nov 2020 16:22:36 +0100
Subject: On certificates and validation
In-Reply-To: <C7CD2DP18NIT.2OAI6N8UP237F@taiga>
References: <CAJScK0KNOv=E2B2Qo8sU=pHE8DFROoFs-7rgyGufR92=xNr-rA@mail.gmail.com>
 <C7CD2DP18NIT.2OAI6N8UP237F@taiga>
Message-ID: <20201125152236.GA5853@localhost.localdomain>

> I strongly recommend not checking for CA-signed certificates, and only
> supporting TOFU.

+1

However, an observation: If one goes for TOFU, please
make the key expiry times decades or even centuries long.

The expiry date is the point at which a man in the middle
attack is certain to work [*] - the weakness of TOFU. This is a
much graver concern than a hypothetical key compromise or
similar.

My cynical view is that expiration dates were added to
guarantee certification authorities a steady revenue
stream.

Ssh doesn't expire its keys, and isn't worse for that.

[*] If you can use the old key to validate the new one, then this 
is a different matter.

regards

marc


From gemini at ur.gs  Wed Nov 25 17:00:46 2020
From: gemini at ur.gs (Nick Thomas)
Date: Wed, 25 Nov 2020 17:00:46 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
Message-ID: <d820f6c0f12afa0a20bd207779097dca864b9882.camel@ur.gs>

On Wed, 2020-11-25 at 10:10 -0500, John Cowan wrote:
> On Wed, Nov 25, 2020 at 6:32 AM Nick Thomas <gemini at ur.gs> wrote:
> > If it's true for people with an explicit preference, it can also be
> > true for people who haven't expressed a preference yet. Since
> > Gemini
> > has a higher standard for user privacy than the web, it can also
> > have a
> > higher standard for these preferences - one that does not rely on
> > presumed consent - if we want it to.
> > 
> 
> By this logic, nobody should be able to access a Gemini server at all
> unless the capsule author has expressed a preference for them to do
> so.
> But to publish is to expose your work to the public.

Browsing, indexing, research crawling, and archiving, are all distinct
things with distinct impacts on capsule author privacy. This is why my
opening email proposed that we retain presumed consent for browing via
a proxy - it's a clear case of "one of these things is not like the
others", and the same is true for individual browsing.

This section was mostly aimed at establishing that capsule authors
should be thought of as gemini users, so it took some shortcuts on
presumed consent verbiage, which might not have been helpful.

For clarity: I think it's fine to presume consent for browsing (whether
through a proxy or not), and not fine to presume consent for archiving.
If adopted, this represents a significant enhancement to capsule author
privacy compared to web norms.

Presumed consent for indexing, I'm actually fairly marginal about. I do
think it's more appropriate to forbid than permit it, but not very
strongly.

> > > Why isn't the site I'm looking for in the archive?*
> > > Some sites may not be included because the automated crawlers
> > > were
> > > unaware of their existence at the time of the crawl. It's also
> > > possible that some sites were not archived because they were
> > > password protected, blocked by robots.txt, or otherwise
> > > inaccessible
> > > to our automated systems. Site owners might have also requested
> > > that
> > > their sites be excluded from the Wayback Machine.
> 
> I interpret that to mean that some sites were not crawled during the
> period
> when the Archive was paying attention to robots.txt, and so their
> content
> as of that date is unavailable.  Note the past tense:  "were [...]
> protected by robots.txt" as opposed to "are protected".

I don't see any space at all to read it like that, not least due to the
references to "password protected" and "otherwise inaccessible" content
in exactly the same tense.

To me, it's crystal clear that the past tense is used here simply
because the crawl happened in the past.

I do have this blog post from April 2018, referencing archived blogs
from December 2017, where robots.txt being respected is a plot point:

https://blog.archive.org/2018/04/24/addressing-recent-claims-of-manipulated-blog-posts-in-the-wayback-machine/

The blog.archive.org rant about robots.txt not being suitable for
archivers was April 2017. that's the one that mentions they may not
respect robots.txt in-general in the future; I'd really very strongly
expect a futher blog post to appear if they start taking steps in that
direction.

It would definitely be interesting if you had an experiment or
reference demonstrating that archive.org ignores robots.txt in general,
but this page simply isn't it.

/Nick


From linde.philip at gmail.com  Wed Nov 25 18:15:37 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 25 Nov 2020 19:15:37 +0100
Subject: robots.txt for Gemini formalised
In-Reply-To: <20201124151649.GA20449@localhost.localdomain>
References: <20201123033109.GF1721@brevard.conman.org>
 <3d8fa90114f88eb4daabf8e5298bbe99@tilde.team>
 <C7AB750HR1S5.12F8WY1S6S2PQ@taiga>
 <4785addcaf3ad9e9aeef53924f1ddcbd@tilde.team>
 <20201123045619.GG1721@brevard.conman.org>
 <20201124102902.GA17441@localhost.localdomain>
 <20201124123109.b08d27b9dbe0285829cd51b2@gmail.com>
 <20201124151649.GA20449@localhost.localdomain>
Message-ID: <20201125191537.ed5f74098e7469e28b39efa6@gmail.com>

On Tue, 24 Nov 2020 16:16:49 +0100
marc <marcx2 at welz.org.za> wrote:

> Note that the apache people worry about just doing a
> stat() for .htaccess along a path. This proposal requires an
> opendir() for *every* directory in the exported hierarchy.

Apache is designed to be able to serve large enterprises with high
request loads. The cause for their concern seems unlikely to apply to
multi-user Gemini hosts.

> I concede that this isn't impossible - it is potentially expensive,
> messy or nonstandard (and yes, there are inotify tricks or
> serving the entire site out of a database, but that isn't a
> common thing).

It's very much a matter of implementation. For example, if high
performance is a concern you can regenerate the information once per
minute rather than on a per-request basis, or on request from the users,
via a Gemini endpoint.

That's however a good argument for an Allow directive corresponding to
Disallow, to be able to disallow by default and only allowing resources
lower down in the hierarchy explicitly, which allows for a "better safe
than sorry" approach to "prevent" a crawler from picking up resources
before the new robot rules have been picked up.

> So I think this is the interesting bit of the discussion -
> the tradeoff of keeping this information inside the file or
> in a sidechannel. You are of course correct that not every
> file format permits embedding such information, and that
> is the one side of the tradeoff.... the other side is
> the argument for persistence - having the data in another
> file (or in a protocol header) means that is likely to be
> lost.

What you're proposing is doubly effective in that data that isn't there
*can't* be lost! :)

I appreciate your point, but "not every file format" is an
understatement. It's really only one file format that is controlled by
the Gemini spec right now: text/gemini. That's where we could add such
information and define it to be meaningful.

> And my view is that caching/archiving/aggregating/protocol
> translation all involve making copies, where a careless or
> inconsiderate intermediate is likely to discard information
> not embedded in the file.

A careless or inconsiderate intermediate is likely to discard
information, full stop. It's only respectful and considerate robots
that will recognize either approach.

> For instance, if a web frontend
> serves gemini://example.org/private.gmi as
> https://example.com/gemini/example.org/private.gmi
> how good are the odds that this frontend fetches
> gemini://example.org/robots.txt, rewrites the urls in there
> from /private.gmi to /gemini/example.org/private.gmi and
> merges it into its own /robots.txt ? And does it before
> any crawler request is made...

On the other hand, how likely is it that a web crawler will interpret
robot instructions from text/gemini-turned-html documents?

> A pragmatist's argument: The web and geminispace are a graph
> of links, and all the interior nodes have to be markup, so those
> are covered, and they control the reachability - without
> a link you can't get to the terminal/leaf node. And even if
> this is bypassed (robots.txt isn't really a defence against hotlinking
> either) most other terminal nodes are images or video, which typically have
> ways of adding meta information (exif, etc).

Do you propose to standardize extensions to Exif/ID3/Vorbis
comments/PDF metadata etc. as well as text/gemini? Neither these
currently have a standard way to specify a robots policy; it seems
understood that it's not a concern of the file itself whether a crawler
should be able to download it if the file is ever served over a
crawlable graph.

Hotlinking is a different concern altogether. The purpose of robots.txt
is not to disallow hotlinking.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201125/d706df49/attachment.sig>

From solderpunk at posteo.net  Wed Nov 25 19:10:33 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Wed, 25 Nov 2020 20:10:33 +0100
Subject: Requiring schemes in Gemini requests
In-Reply-To: <20201125025725.GK1721@brevard.conman.org>
Message-ID: <C7CKYX7HRP06.3NQMEJTNAX9SF@stilgar>

On Wed Nov 25, 2020 at 3:57 AM CET, Sean Conner wrote:
>
> Agree. As I mentioned earlier [1], 0.2% of all requests were schemeless
> to my server, and only three clients accounted for that traffic. Make
> the
> Gemini request a full URL.

I think I'm happy with this, does anybody object?

Cheers,
Solderpunk

From ben at bendb.com  Wed Nov 25 23:03:01 2020
From: ben at bendb.com (Ben Bader)
Date: Wed, 25 Nov 2020 16:03:01 -0700
Subject: [ANN] Twink, a CLI Gemini client
Message-ID: <CADkMQxW_cF2FoYBi4DCW9yvCMupR=bMNNOFTTxhzhB=jNuT97Q@mail.gmail.com>

Hi Geminauts,

I've been working on a new Gemini client, tentatively called "Twink".  It
was going to be "Twin" until I realized just how many servers/libraries/etc
use that name already :)  It's very early still for this codebase, but it's
functional-enough that I wanted to share it.  It's CLI-only for now, though
I intend to build a Qt program around the core library in the near future.

At present it is more or less cURL + TOFU validation + ANSI formatting.

=> https://git.sr.ht/~bendb/twink

If anyone cares to leave comments, I'd be glad to hear from you!

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201125/56edec23/attachment.htm>

From sean at conman.org  Wed Nov 25 23:36:16 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 25 Nov 2020 18:36:16 -0500
Subject: On Web-proxies (was Re: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised))
In-Reply-To: <d820f6c0f12afa0a20bd207779097dca864b9882.camel@ur.gs>
References: <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <d820f6c0f12afa0a20bd207779097dca864b9882.camel@ur.gs>
Message-ID: <20201125233616.GL1721@brevard.conman.org>

It was thus said that the Great Nick Thomas once stated:
> > 
> For clarity: I think it's fine to presume consent for browsing (whether
> through a proxy or not), and not fine to presume consent for archiving.
> If adopted, this represents a significant enhancement to capsule author
> privacy compared to web norms.

  The issue with proxying (especially via the web) is the web side.  Using a
webproxy that runs locally to browse Gemini sites via a browser is fine, but
it becomes problematic if said proxy is listening on a public IP address. 
It's not a matter of *if* but *WHEN* webbots of all types start hitting it,
and *those* are a mixture of indexer, archiver, research and other [1].  At
the very least, any web proxy should respond to "/robots.txt" and either
serve up a file, or have command line options to generate a response to
"/robots.txt" or at the very least (or as a default), send this:

	User-agent: *
	Disallow: /

  This is the crux of the diagreement between myself and Drew---I didn't
explain my concerns very well, and he didn't pick up on the actual issue I
had (so my fault here).  A web proxy can inadvertently allow indexers,
archivers, researchers and others access to Gemini content.

  -spc

[1]	Indexers, archivers and research bots tend to respect robots.txt.
	It's the "other" class that don't.  These "other" bots are typically
	looking for exploits and there's not much you can do about these
	other than outright ban the IP they're coming from [2].  

[2]	And even then it's a game of "whack-a-mole", although if a web proxy
	sees a bunch of requests from a single IP address that result in a
	bunch of "not found" errors from Gemini (say, a threshhold of 10
	such results in a row) then that IP is automatically banned for a
	period of time (say, 48 hours---enough to let it finish its job, but
	not forever since the list of IPs will grow).

From cowan at ccil.org  Thu Nov 26 00:57:49 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 25 Nov 2020 19:57:49 -0500
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <d820f6c0f12afa0a20bd207779097dca864b9882.camel@ur.gs>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <d820f6c0f12afa0a20bd207779097dca864b9882.camel@ur.gs>
Message-ID: <CAD2gp_QODRMA0qiZHbc-z6AHOcdFgCJ0ZBb2SBFV5tJZMYaUDg@mail.gmail.com>

On Wed, Nov 25, 2020 at 12:01 PM Nick Thomas <gemini at ur.gs> wrote:

It would definitely be interesting if you had an experiment or
> reference demonstrating that archive.org ignores robots.txt in general,
> but this page simply isn't it.


Okay, I rediscovered the page I was looking for: <
https://webmasters.stackexchange.com/questions/71377/how-to-properly-disallow-the-archive-org-bot-did-things-change-if-so-when/
>.

Search on that page for "random item on eBay".  This test shows that as of
May 2017, the IA was supporting robots.txt.  I tried this myself, and it
shows three crawls, two in 2019 and one in 2020, that agree with what you
see ("Unknown item") if you follow the direct link.  This agrees with the
claim that robots.txt was turned off in 2018 for all sites; however,
apparently the IA is not announcing this.  My guess (only a guess) is that
IA thinks that people who don't want to be archived will start using less
reliable mechanisms like blocking IP addresses.

Now search farther down the page for "just did a quick test".  This shows
that as of March 2017 the IA was refusing to display pages put off-limits
by robots.txt, consistently with the above.  However, when the robots.txt
entry was removed, crawls from 2010 through 2017 suddenly appeared!  So
even in the pre-2018 regime, the IA was crawling the pages but hiding them.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
If I have seen farther than others, it is because I was looking through a
spyglass with my one good eye, with a parrot standing on my shoulder. --"Y"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201125/d8d889c9/attachment.htm>

From krixano at protonmail.com  Thu Nov 26 06:09:54 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 06:09:54 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
Message-ID: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>

Gaah, ok, I hit reply instead of reply all... so my messages were sent directly to the people, lol. I'll repost them here:

I want to point out that making the assumption that a lack of robots.txt
is because servers don't mind they're content being archived is a leap in logic
that doesn't actually follow/make sense. A server/user could have just forgotten
to put a robots.txt, *or* they could have just not known about it.

> A personal example: *I* didn't have a robots.txt on my capsule file until today, but I don't want to be included in archives for various reasons. Presuming consent from the lack of a robots.txt file would have incorrectly guessed my preference, and harmed my privacy. Who else in that 90% is like me? We don't know.

Exactly! When I first got my server up, I didn't have a robots.txt for the longest time. Some of my content was actually not supposed to be archived because it was dynamic stuff. And other stuff I didn't necessarily want archived.

Christian Seibold

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

??????? Original Message ???????
On Wednesday, November 25th, 2020 at 9:10 AM, John Cowan <cowan at ccil.org> wrote:

> On Wed, Nov 25, 2020 at 6:32 AM Nick Thomas <gemini at ur.gs> wrote:
>
>> (Received off-list, but I assume it was *meant* for the list, so
>> replying there)
>
> It was, so thanks. My private messages are labeled (Private message) at the top because I make this mistake a lot.
>
>> Whatever the outcome of the opt-in vs opt-out part of this discussion,
>
> That's the only part that concerns me. A robots.txt spec is good and crawlers/archivers that respect it are fine too, though of course some won't.
>
> I once wrote to the author of a magazine article who had published a simple crawler that it would hammer whatever server it was crawling, since it did not delay between requests or intersperse them with requests to other servers, but simply walked the server's tree depth-first. and that it should respect robots.txt. He wrote back saying "That's the Internet today; deal with it." I could have answered (but I didn't) that hits are a cost to the server operator, and anyone running his dumb crawler was not only DDOSing, but spending my money for his own purposes.
>
> But I do think that once robots.txt support is in place, no robots.txt = no expressed preference.
>
>> If it's true for people with an explicit preference, it can also be
>> true for people who haven't expressed a preference yet. Since Gemini
>> has a higher standard for user privacy than the web, it can also have a
>> higher standard for these preferences - one that does not rely on
>> presumed consent - if we want it to.
>
> By this logic, nobody should be able to access a Gemini server at all unless the capsule author has expressed a preference for them to do so. But to publish is to expose your work to the public.
>
>> The FAQ immediately above the one you quoted reads:
>>
>>> Why isn't the site I'm looking for in the archive?*
>>
>>> Some sites may not be included because the automated crawlers were
>>> unaware of their existence at the time of the crawl. It's also
>>> possible that some sites were not archived because they were
>>> password protected, blocked by robots.txt, or otherwise inaccessible
>>> to our automated systems. Site owners might have also requested that
>>> their sites be excluded from the Wayback Machine.
>
> I interpret that to mean that some sites were not crawled during the period when the Archive was paying attention to robots.txt, and so their content as of that date is unavailable. Note the past tense: "were [...] protected by robots.txt" as opposed to "are protected".
>
>> If archive.org didn't respect robots.txt at all, it would lend a lot of
>> flavour to the "archiver" virtual user-agent idea in the companion
>> spec, in addition to this discussion. Do you still have doubts after
>> reading this section?
>
> I have no doubt whatever that the crawler doesn't respect robots.txt. I could do a little experiment, though.
>
> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
> The competent programmer is fully aware of the strictly limited size of his own
> skull; therefore he approaches the programming task in full humility, and among
> other things he avoids clever tricks like the plague. --Edsger Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/ae3e48ea/attachment.htm>

From krixano at protonmail.com  Thu Nov 26 06:12:06 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 06:12:06 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
Message-ID: <jOm9unucX6Xf9h3vEYcS4l4aZFM_VMnZZ49htvQczsv_G04PArocbvAlSa8fggNAM1obmJLwYGqTzw6zvpNnPGx7WjcSSHMqvH2E6GhadkU=@protonmail.com>

I'm not sure why Internet Archive matters here. Just because they do something doesn't mean
it's the right thing to do. Seems like an appeal to authority to me.

Christian Seibold

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

??????? Original Message ???????
On Wednesday, November 25th, 2020 at 9:10 AM, John Cowan <cowan at ccil.org> wrote:

> On Wed, Nov 25, 2020 at 6:32 AM Nick Thomas <gemini at ur.gs> wrote:
>
>> (Received off-list, but I assume it was *meant* for the list, so
>> replying there)
>
> It was, so thanks. My private messages are labeled (Private message) at the top because I make this mistake a lot.
>
>> Whatever the outcome of the opt-in vs opt-out part of this discussion,
>
> That's the only part that concerns me. A robots.txt spec is good and crawlers/archivers that respect it are fine too, though of course some won't.
>
> I once wrote to the author of a magazine article who had published a simple crawler that it would hammer whatever server it was crawling, since it did not delay between requests or intersperse them with requests to other servers, but simply walked the server's tree depth-first. and that it should respect robots.txt. He wrote back saying "That's the Internet today; deal with it." I could have answered (but I didn't) that hits are a cost to the server operator, and anyone running his dumb crawler was not only DDOSing, but spending my money for his own purposes.
>
> But I do think that once robots.txt support is in place, no robots.txt = no expressed preference.
>
>> If it's true for people with an explicit preference, it can also be
>> true for people who haven't expressed a preference yet. Since Gemini
>> has a higher standard for user privacy than the web, it can also have a
>> higher standard for these preferences - one that does not rely on
>> presumed consent - if we want it to.
>
> By this logic, nobody should be able to access a Gemini server at all unless the capsule author has expressed a preference for them to do so. But to publish is to expose your work to the public.
>
>> The FAQ immediately above the one you quoted reads:
>>
>>> Why isn't the site I'm looking for in the archive?*
>>
>>> Some sites may not be included because the automated crawlers were
>>> unaware of their existence at the time of the crawl. It's also
>>> possible that some sites were not archived because they were
>>> password protected, blocked by robots.txt, or otherwise inaccessible
>>> to our automated systems. Site owners might have also requested that
>>> their sites be excluded from the Wayback Machine.
>
> I interpret that to mean that some sites were not crawled during the period when the Archive was paying attention to robots.txt, and so their content as of that date is unavailable. Note the past tense: "were [...] protected by robots.txt" as opposed to "are protected".
>
>> If archive.org didn't respect robots.txt at all, it would lend a lot of
>> flavour to the "archiver" virtual user-agent idea in the companion
>> spec, in addition to this discussion. Do you still have doubts after
>> reading this section?
>
> I have no doubt whatever that the crawler doesn't respect robots.txt. I could do a little experiment, though.
>
> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
> The competent programmer is fully aware of the strictly limited size of his own
> skull; therefore he approaches the programming task in full humility, and among
> other things he avoids clever tricks like the plague. --Edsger Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/fd3e3fb9/attachment-0001.htm>

From krixano at protonmail.com  Thu Nov 26 06:18:48 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 06:18:48 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <jOm9unucX6Xf9h3vEYcS4l4aZFM_VMnZZ49htvQczsv_G04PArocbvAlSa8fggNAM1obmJLwYGqTzw6zvpNnPGx7WjcSSHMqvH2E6GhadkU=@protonmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <jOm9unucX6Xf9h3vEYcS4l4aZFM_VMnZZ49htvQczsv_G04PArocbvAlSa8fggNAM1obmJLwYGqTzw6zvpNnPGx7WjcSSHMqvH2E6GhadkU=@protonmail.com>
Message-ID: <mDbsJSJQkE93j18RMjjlQezgrX7tTZpSN5xuAUfUzDbrQyIIT5f9fkBjOgVMQJPAjUndpu97H1aXkUzitmdCN2JkX83UmQWtJzsgzB-9ZnI=@protonmail.com>

One more thing I want to point out... copyright law isn't opt-in. It's opt-out.
If you don't have a copyright statement or any other licensing information,
then "all rights reserved" is automatically assumed, afaik. You can't just copy
something just because the author didn't explicitly disallow you from doing that.

Christian Seibold

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

??????? Original Message ???????
On Thursday, November 26th, 2020 at 12:12 AM, Krixano <krixano at protonmail.com> wrote:

> I'm not sure why Internet Archive matters here. Just because they do something doesn't mean
> it's the right thing to do. Seems like an appeal to authority to me.
>
> Christian Seibold
>
> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>
> ??????? Original Message ???????
> On Wednesday, November 25th, 2020 at 9:10 AM, John Cowan <cowan at ccil.org> wrote:
>
>> On Wed, Nov 25, 2020 at 6:32 AM Nick Thomas <gemini at ur.gs> wrote:
>>
>>> (Received off-list, but I assume it was *meant* for the list, so
>>> replying there)
>>
>> It was, so thanks. My private messages are labeled (Private message) at the top because I make this mistake a lot.
>>
>>> Whatever the outcome of the opt-in vs opt-out part of this discussion,
>>
>> That's the only part that concerns me. A robots.txt spec is good and crawlers/archivers that respect it are fine too, though of course some won't.
>>
>> I once wrote to the author of a magazine article who had published a simple crawler that it would hammer whatever server it was crawling, since it did not delay between requests or intersperse them with requests to other servers, but simply walked the server's tree depth-first. and that it should respect robots.txt. He wrote back saying "That's the Internet today; deal with it." I could have answered (but I didn't) that hits are a cost to the server operator, and anyone running his dumb crawler was not only DDOSing, but spending my money for his own purposes.
>>
>> But I do think that once robots.txt support is in place, no robots.txt = no expressed preference.
>>
>>> If it's true for people with an explicit preference, it can also be
>>> true for people who haven't expressed a preference yet. Since Gemini
>>> has a higher standard for user privacy than the web, it can also have a
>>> higher standard for these preferences - one that does not rely on
>>> presumed consent - if we want it to.
>>
>> By this logic, nobody should be able to access a Gemini server at all unless the capsule author has expressed a preference for them to do so. But to publish is to expose your work to the public.
>>
>>> The FAQ immediately above the one you quoted reads:
>>>
>>>> Why isn't the site I'm looking for in the archive?*
>>>
>>>> Some sites may not be included because the automated crawlers were
>>>> unaware of their existence at the time of the crawl. It's also
>>>> possible that some sites were not archived because they were
>>>> password protected, blocked by robots.txt, or otherwise inaccessible
>>>> to our automated systems. Site owners might have also requested that
>>>> their sites be excluded from the Wayback Machine.
>>
>> I interpret that to mean that some sites were not crawled during the period when the Archive was paying attention to robots.txt, and so their content as of that date is unavailable. Note the past tense: "were [...] protected by robots.txt" as opposed to "are protected".
>>
>>> If archive.org didn't respect robots.txt at all, it would lend a lot of
>>> flavour to the "archiver" virtual user-agent idea in the companion
>>> spec, in addition to this discussion. Do you still have doubts after
>>> reading this section?
>>
>> I have no doubt whatever that the crawler doesn't respect robots.txt. I could do a little experiment, though.
>>
>> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
>> The competent programmer is fully aware of the strictly limited size of his own
>> skull; therefore he approaches the programming task in full humility, and among
>> other things he avoids clever tricks like the plague. --Edsger Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/625adbc1/attachment.htm>

From krixano at protonmail.com  Thu Nov 26 07:06:39 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 07:06:39 +0000
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
Message-ID: <bCwdC-hrWfqEcVPoqD49hlzWMkLLcADAvDoX5JUwRoaRQkpAsNktCrokUZSuuetIywY66qh6FqN2d9yZCs11Sp3u5KrUHi9C1rgKN9Tyk5I=@protonmail.com>

> However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent!

This makes absolutely no sense.
What's the difference between regular letters and letters that have diacritics?
What's the difference between capitals and lowercase? What about Hebrew
Vowels? Are all those "metadata" also?
Italics conveys data itself.
Italics is part of the writing system. It's not "metadata"
It's literally no different from using punctuation, or capitals.

Christian Seibold

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

??????? Original Message ???????
On Monday, November 9th, 2020 at 6:31 PM, John Cowan <cowan at ccil.org> wrote:

> On Mon, Nov 9, 2020 at 6:46 PM Philip Linde <linde.philip at gmail.com> wrote:
>
>> The /italics/ style has the unfortunate side effect of producing false
>> positives for quite plausible Unix paths, e.g. /etc/.
>
> Such markup should really only be recognized if there is whitespace or the beginning of the line before it and whitespace, the end of the line, or sentence-ending punctuation after it. One advantage of _ is that it is not normally used in running text.
>
>> This has never
>> been a problem in the settings I use this style of implying typography
>> (mostly IRC) because the input isn't typically transformed and is
>> presented as written
>
> There are IRC clients that interpret it.
> On Mon, Nov 9, 2020 at 6:52 PM acdw <acdw at acdw.net> wrote:
>
>> However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent!
>
> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
>
> 1) Titles of books, movies, magazines, and other stand-alone works.
>
> 2) Scientific names of plants and animals.
>
> 3) Terms being introduced for the first time.
>
> 4) In narrative, the thoughts of a character.
>
> 5) Words being used as examples of themselves. ("The word _the_ is a definite article.")
>
> 6) Names of ships.
>
> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
> When I'm stuck in something boring where reading would be impossible or
> rude, I often set up math problems for myself and solve them as a way
> to pass the time. --John Jenkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/f49e1da4/attachment-0001.htm>

From khuxkm at tilde.team  Thu Nov 26 07:09:11 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 26 Nov 2020 07:09:11 +0000
Subject: Assuming disallow-all, and some research on robots.txt in   
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
References: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
 <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
Message-ID: <81c36e52af1ae4266da1458448971e6c@tilde.team>

Hi Krixano,

A few thoughts. First of all, please use plaintext email in future
(https://useplaintext.email/#protonmail, as your signature clearly indicated you use protonmail I
can give you the direct link). It's easier for a lot of us to access.

Regarding your first email:

November 26, 2020 1:09 AM, "Krixano" <krixano at protonmail.com> wrote:

> I want to point out that making the assumption that a lack of robots.txt
> is because servers don't mind they're content being archived is a leap in logic
> that doesn't actually follow/make sense. A server/user could have just forgotten
> to put a robots.txt, *or* they could have just not known about it.
> 
>> A personal example: *I* didn't have a robots.txt on my capsule file until today, but I don't want
> 
> to be included in archives for various reasons. Presuming consent from the lack of a robots.txt
> file would have incorrectly guessed my preference, and harmed my privacy. Who else in that 90% is
> like me? We don't know.
> 
> Exactly! When I first got my server up, I didn't have a robots.txt for the longest time. Some of my
> content was actually not supposed to be archived because it was dynamic stuff. And other stuff I
> didn't necessarily want archived.

It may be a leap of logic, sure, but it's the same leap of logic that has been all but codified as
law (see court cases like Field v. Google, where judges have determined that not including a
robots.txt or no-archive tag grants an implied license to archive). As stated in the case summary of Field v. Google:

> Author granted operator of Internet search engine implied license to display "cached" links to web pages containing his copyrighted works when author consciously chose not to include no-archive meta-tag on pages of his website, despite knowing that including meta-tag would have informed operator not to display "cached" links to his pages and that absence of meta-tag would be interpreted by operator as permission to allow access to his web pages via "cached" links.

Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap of logic if even a court of law comes to the same decision?

November 26, 2020 1:12 AM, "Krixano" <krixano at protonmail.com> wrote:

> I'm not sure why Internet Archive matters here. Just because they do something doesn't mean
> it's the right thing to do. Seems like an appeal to authority to me.

It is an appeal to authority, but not a fallacious one. The Internet Archive is (as far as I know)
the biggest archiving group on the Internet. If they do something, it's not entirely beyond reason
to assume other people do the same. A wide variety of people who do archiving that I've spoken to
have the same attitude: they'll still archive it, but they won't make the archive available to the
public if they aren't supposed to.

November 26, 2020 1:18 AM, "Krixano" <krixano at protonmail.com> wrote:

> One more thing I want to point out... copyright law isn't opt-in. It's opt-out.
> If you don't have a copyright statement or any other licensing information,
> then "all rights reserved" is automatically assumed, afaik. You can't just copy
> something just because the author didn't explicitly disallow you from doing that.

Again, see above; the law is on the side of the person assuming robots.txt is a system for opting out of indexing/archiving/etc. 

Just my two cents,
Robert "khuxkm" Miles

From krixano at protonmail.com  Thu Nov 26 07:11:37 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 07:11:37 +0000
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <bCwdC-hrWfqEcVPoqD49hlzWMkLLcADAvDoX5JUwRoaRQkpAsNktCrokUZSuuetIywY66qh6FqN2d9yZCs11Sp3u5KrUHi9C1rgKN9Tyk5I=@protonmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
 <bCwdC-hrWfqEcVPoqD49hlzWMkLLcADAvDoX5JUwRoaRQkpAsNktCrokUZSuuetIywY66qh6FqN2d9yZCs11Sp3u5KrUHi9C1rgKN9Tyk5I=@protonmail.com>
Message-ID: <Ue0YLojaEA74m46D0lKTuwKWuIPRc-crszF5u7DmSdEFC2Ixo-PpWE8TZ4zCN_AQU1SrvVCaZJ6cSUYTVZLzn2C2QYz0AZZgkJOJ21Cmay4=@protonmail.com>

To further what I'm saying. Italics often conveys emphasis,
which is conveyed in speech with intonation. Intonation is
data itself. Italics is one of the few methods we can convey
that in writing.

Italics can also convey other information. A new word, for example.
You do the same thing in speech. In speech when you introduce a new
word you might put extra emphasis on the word, slow down your speaking,
etc. This is also linguistic data.

Christian Seibold

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

??????? Original Message ???????
On Thursday, November 26th, 2020 at 1:06 AM, Krixano <krixano at protonmail.com> wrote:

>> However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent!
>
> This makes absolutely no sense.
> What's the difference between regular letters and letters that have diacritics?
> What's the difference between capitals and lowercase? What about Hebrew
> Vowels? Are all those "metadata" also?
> Italics conveys data itself.
> Italics is part of the writing system. It's not "metadata"
> It's literally no different from using punctuation, or capitals.
>
> Christian Seibold
>
> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>
> ??????? Original Message ???????
> On Monday, November 9th, 2020 at 6:31 PM, John Cowan <cowan at ccil.org> wrote:
>
>> On Mon, Nov 9, 2020 at 6:46 PM Philip Linde <linde.philip at gmail.com> wrote:
>>
>>> The /italics/ style has the unfortunate side effect of producing false
>>> positives for quite plausible Unix paths, e.g. /etc/.
>>
>> Such markup should really only be recognized if there is whitespace or the beginning of the line before it and whitespace, the end of the line, or sentence-ending punctuation after it. One advantage of _ is that it is not normally used in running text.
>>
>>> This has never
>>> been a problem in the settings I use this style of implying typography
>>> (mostly IRC) because the input isn't typically transformed and is
>>> presented as written
>>
>> There are IRC clients that interpret it.
>> On Mon, Nov 9, 2020 at 6:52 PM acdw <acdw at acdw.net> wrote:
>>
>>> However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent!
>>
>> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
>>
>> 1) Titles of books, movies, magazines, and other stand-alone works.
>>
>> 2) Scientific names of plants and animals.
>>
>> 3) Terms being introduced for the first time.
>>
>> 4) In narrative, the thoughts of a character.
>>
>> 5) Words being used as examples of themselves. ("The word _the_ is a definite article.")
>>
>> 6) Names of ships.
>>
>> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
>> When I'm stuck in something boring where reading would be impossible or
>> rude, I often set up math problems for myself and solve them as a way
>> to pass the time. --John Jenkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/9f98baa3/attachment.htm>

From krixano at protonmail.com  Thu Nov 26 07:24:27 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 07:24:27 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <81c36e52af1ae4266da1458448971e6c@tilde.team>
References: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
Message-ID: <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>

> Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap of logic if even a court of law comes to the same decision?

Yes, the court clearly made a leap in logic. Courts don't always follow logic,
because it's not efficient to do so.

Btw, the court case is only in the district of Nevada. And I'm honestly surprised
by this, considering that you do *not* have to explicitly assert your copyright
in order for copyright to apply. It seems this particular court thought caching
was an exception, unfortunately. Pretty disgusting.

Anyways, if I find any site archiving any of the stuff from my server, I'll be
looking into DMCA takedowns, because I don't tolerate utter disrespect for users'
content like that. It's disgusting.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 1:09 AM, Robert "khuxkm" Miles <khuxkm at tilde.team> wrote:

> Hi Krixano,
>
> A few thoughts. First of all, please use plaintext email in future
>
> (https://useplaintext.email/#protonmail, as your signature clearly indicated you use protonmail I
>
> can give you the direct link). It's easier for a lot of us to access.
>
> Regarding your first email:
>
> November 26, 2020 1:09 AM, "Krixano" krixano at protonmail.com wrote:
>
> > I want to point out that making the assumption that a lack of robots.txt
> >
> > is because servers don't mind they're content being archived is a leap in logic
> >
> > that doesn't actually follow/make sense. A server/user could have just forgotten
> >
> > to put a robots.txt, or they could have just not known about it.
> >
> > > A personal example: I didn't have a robots.txt on my capsule file until today, but I don't want
> >
> > to be included in archives for various reasons. Presuming consent from the lack of a robots.txt
> >
> > file would have incorrectly guessed my preference, and harmed my privacy. Who else in that 90% is
> >
> > like me? We don't know.
> >
> > Exactly! When I first got my server up, I didn't have a robots.txt for the longest time. Some of my
> >
> > content was actually not supposed to be archived because it was dynamic stuff. And other stuff I
> >
> > didn't necessarily want archived.
>
> It may be a leap of logic, sure, but it's the same leap of logic that has been all but codified as
>
> law (see court cases like Field v. Google, where judges have determined that not including a
>
> robots.txt or no-archive tag grants an implied license to archive). As stated in the case summary of Field v. Google:
>
> > Author granted operator of Internet search engine implied license to display "cached" links to web pages containing his copyrighted works when author consciously chose not to include no-archive meta-tag on pages of his website, despite knowing that including meta-tag would have informed operator not to display "cached" links to his pages and that absence of meta-tag would be interpreted by operator as permission to allow access to his web pages via "cached" links.
>
> Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap of logic if even a court of law comes to the same decision?
>
> November 26, 2020 1:12 AM, "Krixano" krixano at protonmail.com wrote:
>
> > I'm not sure why Internet Archive matters here. Just because they do something doesn't mean
> >
> > it's the right thing to do. Seems like an appeal to authority to me.
>
> It is an appeal to authority, but not a fallacious one. The Internet Archive is (as far as I know)
>
> the biggest archiving group on the Internet. If they do something, it's not entirely beyond reason
>
> to assume other people do the same. A wide variety of people who do archiving that I've spoken to
>
> have the same attitude: they'll still archive it, but they won't make the archive available to the
>
> public if they aren't supposed to.
>
> November 26, 2020 1:18 AM, "Krixano" krixano at protonmail.com wrote:
>
> > One more thing I want to point out... copyright law isn't opt-in. It's opt-out.
> >
> > If you don't have a copyright statement or any other licensing information,
> >
> > then "all rights reserved" is automatically assumed, afaik. You can't just copy
> >
> > something just because the author didn't explicitly disallow you from doing that.
>
> Again, see above; the law is on the side of the person assuming robots.txt is a system for opting out of indexing/archiving/etc.
>
> Just my two cents,
>
> Robert "khuxkm" Miles

From krixano at protonmail.com  Thu Nov 26 07:26:56 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 07:26:56 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
References: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
Message-ID: <xkFrv3LmxIf2UqsLNLrQ8M5kEDPZTeUjjVV5kJWgmMWWGzl4AqWIL3udW3aOpxuL7nbq1zN25is8vx7s_6uipvlCRN6ZXqT4QD0PlBKXlZQ=@protonmail.com>

My emails, afaik, should already be in plaintext. Not sure if something got messed up with a previous email, but anyways.... It shows Plain Text as being selected, so yeah.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 1:24 AM, Krixano <krixano at protonmail.com> wrote:

> > Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap of logic if even a court of law comes to the same decision?
>
> Yes, the court clearly made a leap in logic. Courts don't always follow logic,
>
> because it's not efficient to do so.
>
> Btw, the court case is only in the district of Nevada. And I'm honestly surprised
>
> by this, considering that you do not have to explicitly assert your copyright
>
> in order for copyright to apply. It seems this particular court thought caching
>
> was an exception, unfortunately. Pretty disgusting.
>
> Anyways, if I find any site archiving any of the stuff from my server, I'll be
>
> looking into DMCA takedowns, because I don't tolerate utter disrespect for users'
>
> content like that. It's disgusting.
>
> Christian Seibold
>
> Sent with ProtonMail Secure Email.
>
> ??????? Original Message ???????
>
> On Thursday, November 26th, 2020 at 1:09 AM, Robert "khuxkm" Miles khuxkm at tilde.team wrote:
>
> > Hi Krixano,
> >
> > A few thoughts. First of all, please use plaintext email in future
> >
> > (https://useplaintext.email/#protonmail, as your signature clearly indicated you use protonmail I
> >
> > can give you the direct link). It's easier for a lot of us to access.
> >
> > Regarding your first email:
> >
> > November 26, 2020 1:09 AM, "Krixano" krixano at protonmail.com wrote:
> >
> > > I want to point out that making the assumption that a lack of robots.txt
> > >
> > > is because servers don't mind they're content being archived is a leap in logic
> > >
> > > that doesn't actually follow/make sense. A server/user could have just forgotten
> > >
> > > to put a robots.txt, or they could have just not known about it.
> > >
> > > > A personal example: I didn't have a robots.txt on my capsule file until today, but I don't want
> > >
> > > to be included in archives for various reasons. Presuming consent from the lack of a robots.txt
> > >
> > > file would have incorrectly guessed my preference, and harmed my privacy. Who else in that 90% is
> > >
> > > like me? We don't know.
> > >
> > > Exactly! When I first got my server up, I didn't have a robots.txt for the longest time. Some of my
> > >
> > > content was actually not supposed to be archived because it was dynamic stuff. And other stuff I
> > >
> > > didn't necessarily want archived.
> >
> > It may be a leap of logic, sure, but it's the same leap of logic that has been all but codified as
> >
> > law (see court cases like Field v. Google, where judges have determined that not including a
> >
> > robots.txt or no-archive tag grants an implied license to archive). As stated in the case summary of Field v. Google:
> >
> > > Author granted operator of Internet search engine implied license to display "cached" links to web pages containing his copyrighted works when author consciously chose not to include no-archive meta-tag on pages of his website, despite knowing that including meta-tag would have informed operator not to display "cached" links to his pages and that absence of meta-tag would be interpreted by operator as permission to allow access to his web pages via "cached" links.
> >
> > Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap of logic if even a court of law comes to the same decision?
> >
> > November 26, 2020 1:12 AM, "Krixano" krixano at protonmail.com wrote:
> >
> > > I'm not sure why Internet Archive matters here. Just because they do something doesn't mean
> > >
> > > it's the right thing to do. Seems like an appeal to authority to me.
> >
> > It is an appeal to authority, but not a fallacious one. The Internet Archive is (as far as I know)
> >
> > the biggest archiving group on the Internet. If they do something, it's not entirely beyond reason
> >
> > to assume other people do the same. A wide variety of people who do archiving that I've spoken to
> >
> > have the same attitude: they'll still archive it, but they won't make the archive available to the
> >
> > public if they aren't supposed to.
> >
> > November 26, 2020 1:18 AM, "Krixano" krixano at protonmail.com wrote:
> >
> > > One more thing I want to point out... copyright law isn't opt-in. It's opt-out.
> > >
> > > If you don't have a copyright statement or any other licensing information,
> > >
> > > then "all rights reserved" is automatically assumed, afaik. You can't just copy
> > >
> > > something just because the author didn't explicitly disallow you from doing that.
> >
> > Again, see above; the law is on the side of the person assuming robots.txt is a system for opting out of indexing/archiving/etc.
> >
> > Just my two cents,
> >
> > Robert "khuxkm" Miles

From bjorn.warmedal at gmail.com  Thu Nov 26 07:32:01 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 26 Nov 2020 08:32:01 +0100
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
References: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
Message-ID: <CAJScK0K5ziQS8JjA93eCGaiPkHfZdWfm8t3xjB0pSssp72E0Xg@mail.gmail.com>

> > Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap of logic if even a court of law comes to the same decision?
>
> Yes, the court clearly made a leap in logic. Courts don't always follow logic,
> because it's not efficient to do so.

Courts don't always follow logic, but they often follow precedent.

> Anyways, if I find any site archiving any of the stuff from my server, I'll be
> looking into DMCA takedowns, because I don't tolerate utter disrespect for users'
> content like that. It's disgusting.

And a DMCA takedown notice is a legal measure, which needs a legal
footing. And it would get that by using robots.txt files as
established in precedent.

From krixano at protonmail.com  Thu Nov 26 07:39:21 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 07:39:21 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <CAJScK0K5ziQS8JjA93eCGaiPkHfZdWfm8t3xjB0pSssp72E0Xg@mail.gmail.com>
References: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
 <CAJScK0K5ziQS8JjA93eCGaiPkHfZdWfm8t3xjB0pSssp72E0Xg@mail.gmail.com>
Message-ID: <hK99qF-nwt1aga0xsJ8uMgM2cqntdCDD35CbL0P-iq2QOIHOP_aGd8DC3bmCs0sFvx7eQkSa2IrN0-Gejxlj53TILngz08T7JxTiiOleMhU=@protonmail.com>

The court case (Field v. Google) was only in the district of Nevada. It doesn't apply
to all of the US, and it doesn't apply to people outside of the US.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 1:32 AM, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:

> > > Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap of logic if even a court of law comes to the same decision?
> >
> > Yes, the court clearly made a leap in logic. Courts don't always follow logic,
> >
> > because it's not efficient to do so.
>
> Courts don't always follow logic, but they often follow precedent.
>
> > Anyways, if I find any site archiving any of the stuff from my server, I'll be
> >
> > looking into DMCA takedowns, because I don't tolerate utter disrespect for users'
> >
> > content like that. It's disgusting.
>
> And a DMCA takedown notice is a legal measure, which needs a legal
>
> footing. And it would get that by using robots.txt files as
>
> established in precedent.

From khuxkm at tilde.team  Thu Nov 26 07:41:04 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 26 Nov 2020 07:41:04 +0000
Subject: Assuming disallow-all, and some research on robots.txt in  
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
References: <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
 <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
Message-ID: <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>

November 26, 2020 2:24 AM, "Krixano" <krixano at protonmail.com> wrote:

>> Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap
>> of logic if even a court of law comes to the same decision?
> 
> Yes, the court clearly made a leap in logic. Courts don't always follow logic,
> because it's not efficient to do so.
> 
> Btw, the court case is only in the district of Nevada. And I'm honestly surprised
> by this, considering that you do *not* have to explicitly assert your copyright
> in order for copyright to apply. It seems this particular court thought caching
> was an exception, unfortunately. Pretty disgusting.
> 
> Anyways, if I find any site archiving any of the stuff from my server, I'll be
> looking into DMCA takedowns, because I don't tolerate utter disrespect for users'
> content like that. It's disgusting.
> 
> Christian Seibold

Obviously, Bj?rn's counter-argument is correct. The courts follow precedent, and this precedent already exists.

The only thing I want to add is: notice how the plaintiff Field didn't appeal. If he truly had a case, like you seem to believe he did, surely he would have appealed?

Just my two cents,
Robert "khuxkm" Miles

From krixano at protonmail.com  Thu Nov 26 07:47:00 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 07:47:00 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>
References: <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>
Message-ID: <18SGYDdOONekoGQrwBGDV3d91-W9vzrTUR5YA602hJ3JuFWhDMb1SYwsM1thiwkgVVJkw5VmATMiKQ-iIEapszD5daWMeLl07KIvRzZ6idY=@protonmail.com>

He didn't have a case because courts rule on multiple things, not just one thing.
Stop trying to twist information. This is what the court ruled:

--------------------------------------

The District Court, Jones, J., held that:

    1.) Operator did not directly infringe on author's copyrighted works;
    2.) Author granted operator implied license to display "cached" links to web pages containing his copyrighted works;
    3.) Author was estopped from asserting copyright infringement claim against operator;
    4.) Fair use doctrine protected operator's use of author's works; and
    5.) Search engine fell within protection of safe harbor provision of Digital Millennium Copyright Act (DMCA).

Summary judgment for operator.

The court held that "Field decided to manufacture a claim for copyright infringement against Google in the hopes of making-money from Google's standard practice." The court then went on to rule in Google's favor on all of its defense theories.

--------------------------------------

What does this tell us? It tells us that even if he won the implied license,
he would have lost the case anyways because Google had Fair Use.

Anyways, you're the one who brought up this court case, not me. I don't agree with
the court, and I don't have to agree with the court, and neither does any other
gemini user. Mind you, the spec isn't for legality, it's for gemini users and what
they think. The gemini spec won't affect any legal things at all.


Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 1:41 AM, Robert "khuxkm" Miles <khuxkm at tilde.team> wrote:

> November 26, 2020 2:24 AM, "Krixano" krixano at protonmail.com wrote:
>
> > > Google's "cached" pages system is essentially an archive under a different name. Is it truly a leap
> > >
> > > of logic if even a court of law comes to the same decision?
> >
> > Yes, the court clearly made a leap in logic. Courts don't always follow logic,
> >
> > because it's not efficient to do so.
> >
> > Btw, the court case is only in the district of Nevada. And I'm honestly surprised
> >
> > by this, considering that you do not have to explicitly assert your copyright
> >
> > in order for copyright to apply. It seems this particular court thought caching
> >
> > was an exception, unfortunately. Pretty disgusting.
> >
> > Anyways, if I find any site archiving any of the stuff from my server, I'll be
> >
> > looking into DMCA takedowns, because I don't tolerate utter disrespect for users'
> >
> > content like that. It's disgusting.
> >
> > Christian Seibold
>
> Obviously, Bj?rn's counter-argument is correct. The courts follow precedent, and this precedent already exists.
>
> The only thing I want to add is: notice how the plaintiff Field didn't appeal. If he truly had a case, like you seem to believe he did, surely he would have appealed?
>
> Just my two cents,
>
> Robert "khuxkm" Miles

From khuxkm at tilde.team  Thu Nov 26 07:48:30 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 26 Nov 2020 07:48:30 +0000
Subject: Assuming disallow-all, and some research on robots.txt in 
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <hK99qF-nwt1aga0xsJ8uMgM2cqntdCDD35CbL0P-iq2QOIHOP_aGd8DC3bmCs0sFvx7eQkSa2IrN0-Gejxlj53TILngz08T7JxTiiOleMhU=@protonmail.com>
References: <hK99qF-nwt1aga0xsJ8uMgM2cqntdCDD35CbL0P-iq2QOIHOP_aGd8DC3bmCs0sFvx7eQkSa2IrN0-Gejxlj53TILngz08T7JxTiiOleMhU=@protonmail.com>
 <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
 <CAJScK0K5ziQS8JjA93eCGaiPkHfZdWfm8t3xjB0pSssp72E0Xg@mail.gmail.com>
Message-ID: <16ada38bb59b65f52f741198941fb7a6@tilde.team>

November 26, 2020 2:39 AM, "Krixano" <krixano at protonmail.com> wrote:

> The court case (Field v. Google) was only in the district of Nevada. It doesn't apply
> to all of the US, and it doesn't apply to people outside of the US.

A precedent is a precedent is a precedent. A district court is, in fact, a federal court, meaning
that any district court in the US could see Field as a precedent they should follow.

I'm sure there are other cases like Field v Google that hold the same thing to be true, even in a European court; it's just
that Field v Google was brought up earlier in this thread, so it's the one I know about.

Just my two cents,
Robert "khuxkm" Miles

From krixano at protonmail.com  Thu Nov 26 07:50:22 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 07:50:22 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <16ada38bb59b65f52f741198941fb7a6@tilde.team>
References: <hK99qF-nwt1aga0xsJ8uMgM2cqntdCDD35CbL0P-iq2QOIHOP_aGd8DC3bmCs0sFvx7eQkSa2IrN0-Gejxlj53TILngz08T7JxTiiOleMhU=@protonmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
 <CAJScK0K5ziQS8JjA93eCGaiPkHfZdWfm8t3xjB0pSssp72E0Xg@mail.gmail.com>
 <16ada38bb59b65f52f741198941fb7a6@tilde.team>
Message-ID: <VJeZIm-QnX9Z7mHOLT3hNN7bCYYmj_dRYDPzzA10ZLj7yj4c7UfPWdxbbCWJN7YncEryxcBhCz30PAyImi3hJHvZ2ec_pmCW8jpmfON40y0=@protonmail.com>

I never argued it wasn't a precedent. However, it hasn't gone up to the
supreme court yet, who is the final arbiter for federal concerns.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 1:48 AM, Robert "khuxkm" Miles <khuxkm at tilde.team> wrote:

> November 26, 2020 2:39 AM, "Krixano" krixano at protonmail.com wrote:
>
> > The court case (Field v. Google) was only in the district of Nevada. It doesn't apply
> >
> > to all of the US, and it doesn't apply to people outside of the US.
>
> A precedent is a precedent is a precedent. A district court is, in fact, a federal court, meaning
>
> that any district court in the US could see Field as a precedent they should follow.
>
> I'm sure there are other cases like Field v Google that hold the same thing to be true, even in a European court; it's just
>
> that Field v Google was brought up earlier in this thread, so it's the one I know about.
>
> Just my two cents,
>
> Robert "khuxkm" Miles

From khuxkm at tilde.team  Thu Nov 26 07:57:26 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 26 Nov 2020 07:57:26 +0000
Subject: Assuming disallow-all, and some research on robots.txt in 
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <18SGYDdOONekoGQrwBGDV3d91-W9vzrTUR5YA602hJ3JuFWhDMb1SYwsM1thiwkgVVJkw5VmATMiKQ-iIEapszD5daWMeLl07KIvRzZ6idY=@protonmail.com>
References: <18SGYDdOONekoGQrwBGDV3d91-W9vzrTUR5YA602hJ3JuFWhDMb1SYwsM1thiwkgVVJkw5VmATMiKQ-iIEapszD5daWMeLl07KIvRzZ6idY=@protonmail.com>
 <YnZ562bMFxRPzBJ1TA34pzjXGZTb0yKw0B3c7IOwHXqHaLp7aQDvmbdZHHz49kTCGm2bRdNbB6O0lQV_kM0o6B1dHc7GDCurCCetRt649E0=@protonmail.com>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>
Message-ID: <6ab9f2dfa8baf65e889a7ef43633206b@tilde.team>

November 26, 2020 2:47 AM, "Krixano" <krixano at protonmail.com> wrote:

> He didn't have a case because courts rule on multiple things, not just one thing.
> Stop trying to twist information. This is what the court ruled:

I'm not trying to twist information. I feel like your argument hinges on him having been able to
also successfully argue the fair use angle.

> What does this tell us? It tells us that even if he won the implied license,
> he would have lost the case anyways because Google had Fair Use.

So an archive counts as fair use then. A non commercial archive can use Field as precedent: it's
for archival purposes, the work is available for free online, it may be a complete archive but the
full work is available for free online, and there's no market for someone's random prose that they
make available for free.

Ergo, anyone can make an archive of anything they aren't explicitly told not to via robots.txt (at
least in the US) and get away with it.

> Anyways, you're the one who brought up this court case, not me. I don't agree with
> the court, and I don't have to agree with the court, and neither does any other
> gemini user. Mind you, the spec isn't for legality, it's for gemini users and what
> they think. The gemini spec won't affect any legal things at all.

Okay, but "gemini users and what they think" won't matter. The only place to seek relief is a court
of law, and the court of law is firmly against you here.

While I was drafting this you responded to my other email, so I'll merge the two replies here:

November 26, 2020 2:50 AM, "Krixano" <krixano at protonmail.com> wrote:

> I never argued it wasn't a precedent. However, it hasn't gone up to the
> supreme court yet, who is the final arbiter for federal concerns.

Well, if the case never made it to the Supreme Court, then the lower court's ruling stands. Ergo, it's still a precedent and most courts in the US would still follow it.

Just my two cents,
Robert "khuxkm" Miles

From sean at conman.org  Thu Nov 26 08:09:34 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 26 Nov 2020 03:09:34 -0500
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <tERpVvSbQ6NQwl_n8E2nXv-QW3Nt8Mp6YvKCfiVGcwEkI27sWXw3eCc39qXTJqLnTv4HmhORWinNQHxC0A_kFXUewEoW4GG4s3eKiFYopiI=@protonmail.com>
Message-ID: <20201126080934.GP1721@brevard.conman.org>

It was thus said that the Great Krixano once stated:
> 
> Exactly! When I first got my server up, I didn't have a robots.txt for the
> longest time. Some of my content was actually not supposed to be archived
> because it was dynamic stuff. And other stuff I didn't necessarily want
> archived.

  It is weird to think of autonomous agents crawling the Internet, but they
exist.  They can make requests just as humans (using a program) can make
requests.  The server has no concept of who or what is behind any given
request, and this is expecially true for Gemini (as it has no concept of a
user-agent identifier being sent).  This was a problem with HTTP in the
early days as well, and in 1994 (only five years after HTTP was created) an
ad-hoc method was developed to help guide autonomous agents in avoiding
particular areas that could lead to infinite holes of requests.

  Yes, it's sad that you had to learn about this the hard way.  Yes, the
Gemini spec should make mention of the robots.txt standard, and perhaps
servers can issue a warning if a robots.txt file is missing.  Or perhaps
they can include a sample robots.txt file for the end user to modify.  I
just recently added a sample robots.txt file to my server source code [1].

  I first learned of robots.txt in the 90s.  I started seeing requests to
"/robots.txt" in the logs, and curious about it, found it was an ad-hoc
standard to control autonomous agents.  I wonder if making an autonomous
agent to *just* request /robots.txt, making it show up in logs [2], will do
any good.  This is how I also found out about /humans.txt [3] (and about a
bazillion ways a web server can be exploited, but I digress).

  -spc

[1]	https://github.com/spc476/GLV-1.12556

	It's under the share directory.  But I can see that I should clarify
	one of the comments in that file, because it will only block
	autonomous agents that follow robots.txt, as it's advisory and not
	something that can be automatically enforced.

[2]	I know logging is also pretty contentious in Geminispace.

[3]	http://humanstxt.org/

From krixano at protonmail.com  Thu Nov 26 08:11:29 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 08:11:29 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <6ab9f2dfa8baf65e889a7ef43633206b@tilde.team>
References: <18SGYDdOONekoGQrwBGDV3d91-W9vzrTUR5YA602hJ3JuFWhDMb1SYwsM1thiwkgVVJkw5VmATMiKQ-iIEapszD5daWMeLl07KIvRzZ6idY=@protonmail.com>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>
 <6ab9f2dfa8baf65e889a7ef43633206b@tilde.team>
Message-ID: <gBGmvPVlt4rw9TbSZEFgj2HjIqO_54dHFOgzr-OervqCIgXTj1HXPH9-sXNDKXfB03J7c5PwNtag79kqW7aoYD32CeM6sHPbiJNEazyitOI=@protonmail.com>

First of all, lets not conflate a spec with law. The spec
doesn't have to follow law. A spec is a guideline, it doesn't
have to match law, and it doesn't have to be adhered to either.

Secondly, let's actually look at what the court ruled here, on the implied license front:
> consent to use the copyrighted work need not be manifested verbally and may be inferred based on silence where the copyright holder knows of the use and encourages it.

Notice the "where the copyright holder knows of the use and encourages it."
That's not necessarily the case in this discussion. It was the case in that court case.
That court case literally doesn't apply here. Especially since Field explicitly added code
so that search engines would index *the URL* of the page. This is not the case in this discussion as the
absence of robots.txt would *not* be explicitly allowing search engines to index the URL of the page, and each
server that doesn't have a robots.txt would not "know of the use and encourage it".

Finally, precedents can be challenged by the Supreme Court. For example, the current Supreme Court case of Google v. Oracle dismissed everything the district courts and the Circuits had to say, because the Supreme Court looks at things freshly.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 1:57 AM, Robert "khuxkm" Miles <khuxkm at tilde.team> wrote:

> November 26, 2020 2:47 AM, "Krixano" krixano at protonmail.com wrote:
>
> > He didn't have a case because courts rule on multiple things, not just one thing.
> >
> > Stop trying to twist information. This is what the court ruled:
>
> I'm not trying to twist information. I feel like your argument hinges on him having been able to
>
> also successfully argue the fair use angle.
>
> > What does this tell us? It tells us that even if he won the implied license,
> >
> > he would have lost the case anyways because Google had Fair Use.
>
> So an archive counts as fair use then. A non commercial archive can use Field as precedent: it's
>
> for archival purposes, the work is available for free online, it may be a complete archive but the
>
> full work is available for free online, and there's no market for someone's random prose that they
>
> make available for free.
>
> Ergo, anyone can make an archive of anything they aren't explicitly told not to via robots.txt (at
>
> least in the US) and get away with it.
>
> > Anyways, you're the one who brought up this court case, not me. I don't agree with
> >
> > the court, and I don't have to agree with the court, and neither does any other
> >
> > gemini user. Mind you, the spec isn't for legality, it's for gemini users and what
> >
> > they think. The gemini spec won't affect any legal things at all.
>
> Okay, but "gemini users and what they think" won't matter. The only place to seek relief is a court
>
> of law, and the court of law is firmly against you here.
>
> While I was drafting this you responded to my other email, so I'll merge the two replies here:
>
> November 26, 2020 2:50 AM, "Krixano" krixano at protonmail.com wrote:
>
> > I never argued it wasn't a precedent. However, it hasn't gone up to the
> >
> > supreme court yet, who is the final arbiter for federal concerns.
>
> Well, if the case never made it to the Supreme Court, then the lower court's ruling stands. Ergo, it's still a precedent and most courts in the US would still follow it.
>
> Just my two cents,
>
> Robert "khuxkm" Miles

From khuxkm at tilde.team  Thu Nov 26 08:22:46 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 26 Nov 2020 08:22:46 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <gBGmvPVlt4rw9TbSZEFgj2HjIqO_54dHFOgzr-OervqCIgXTj1HXPH9-sXNDKXfB03J7c5PwNtag79kqW7aoYD32CeM6sHPbiJNEazyitOI=@protonmail.com>
References: <gBGmvPVlt4rw9TbSZEFgj2HjIqO_54dHFOgzr-OervqCIgXTj1HXPH9-sXNDKXfB03J7c5PwNtag79kqW7aoYD32CeM6sHPbiJNEazyitOI=@protonmail.com>
 <18SGYDdOONekoGQrwBGDV3d91-W9vzrTUR5YA602hJ3JuFWhDMb1SYwsM1thiwkgVVJkw5VmATMiKQ-iIEapszD5daWMeLl07KIvRzZ6idY=@protonmail.com>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>
 <6ab9f2dfa8baf65e889a7ef43633206b@tilde.team>
Message-ID: <057535d375aaa21d35f387d751a3f149@tilde.team>

This conversation is getting away from Gemini, so I'm going to wrap it up here and let us agree to disagree.

November 26, 2020 3:11 AM, "Krixano" <krixano at protonmail.com> wrote:

> First of all, lets not conflate a spec with law. The spec
> doesn't have to follow law. A spec is a guideline, it doesn't
> have to match law, and it doesn't have to be adhered to either.

Okay but if you wanted something for the law being broken (i.e; your copyright being infringed), you have to go in front of a court of law.

> Secondly, let's actually look at what the court ruled here, on the implied license front:
> 
>> consent to use the copyrighted work need not be manifested verbally and may be inferred based on
>> silence where the copyright holder knows of the use and encourages it.
> 
> Notice the "where the copyright holder knows of the use and encourages it."
> That's not necessarily the case in this discussion. It was the case in that court case.
> That court case literally doesn't apply here. Especially since Field explicitly added code
> so that search engines would index *the URL* of the page. This is not the case in this discussion
> as the
> absence of robots.txt would *not* be explicitly allowing search engines to index the URL of the
> page, and each
> server that doesn't have a robots.txt would not "know of the use and encourage it".

I don't know where you got the idea that Field added code to make the engine index the URL-- that's what a search engine does-- but I don't care at this point.

> Finally, precedents can be challenged by the Supreme Court. For example, the current Supreme Court
> case of Google v. Oracle dismissed everything the district courts and the Circuits had to say,
> because the Supreme Court looks at things freshly.

Google v Oracle is an *ongoing* case. No precedent was set, because the case never actually came to rest. See the EFF's page on it:

https://www.eff.org/cases/oracle-v-google

Just my two cents,
Robert "khuxkm" Miles

From krixano at protonmail.com  Thu Nov 26 08:25:55 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 08:25:55 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <057535d375aaa21d35f387d751a3f149@tilde.team>
References: <gBGmvPVlt4rw9TbSZEFgj2HjIqO_54dHFOgzr-OervqCIgXTj1HXPH9-sXNDKXfB03J7c5PwNtag79kqW7aoYD32CeM6sHPbiJNEazyitOI=@protonmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>
 <6ab9f2dfa8baf65e889a7ef43633206b@tilde.team>
 <057535d375aaa21d35f387d751a3f149@tilde.team>
Message-ID: <UZ5_hC2V7bbqufhjErwQ9PAVJ286mL_VF8NYobx_ECGBk-yilNKIeyo-fNKH0yu_vIthH3QUhU6rHwtk0loo2Alu0umv8DTBttjFxDaCX4c=@protonmail.com>

Yes, it's an ongoing case, but I actually read the whole case, and I'm almost 100% positive they are going to rule more in favor of Oracle, because Google made stupid claims, one of which is that software is patentable, btw.

If you want to learn more about this, I would suggest this video series: https://caseorcontroversy.com/

Btw, there *was* precedent set in the lower districts of this case. To say there was no precedent set is misinformation.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 2:22 AM, Robert "khuxkm" Miles <khuxkm at tilde.team> wrote:

> This conversation is getting away from Gemini, so I'm going to wrap it up here and let us agree to disagree.
>
> November 26, 2020 3:11 AM, "Krixano" krixano at protonmail.com wrote:
>
> > First of all, lets not conflate a spec with law. The spec
> >
> > doesn't have to follow law. A spec is a guideline, it doesn't
> >
> > have to match law, and it doesn't have to be adhered to either.
>
> Okay but if you wanted something for the law being broken (i.e; your copyright being infringed), you have to go in front of a court of law.
>
> > Secondly, let's actually look at what the court ruled here, on the implied license front:
> >
> > > consent to use the copyrighted work need not be manifested verbally and may be inferred based on
> > >
> > > silence where the copyright holder knows of the use and encourages it.
> >
> > Notice the "where the copyright holder knows of the use and encourages it."
> >
> > That's not necessarily the case in this discussion. It was the case in that court case.
> >
> > That court case literally doesn't apply here. Especially since Field explicitly added code
> >
> > so that search engines would index the URL of the page. This is not the case in this discussion
> >
> > as the
> >
> > absence of robots.txt would not be explicitly allowing search engines to index the URL of the
> >
> > page, and each
> >
> > server that doesn't have a robots.txt would not "know of the use and encourage it".
>
> I don't know where you got the idea that Field added code to make the engine index the URL-- that's what a search engine does-- but I don't care at this point.
>
> > Finally, precedents can be challenged by the Supreme Court. For example, the current Supreme Court
> >
> > case of Google v. Oracle dismissed everything the district courts and the Circuits had to say,
> >
> > because the Supreme Court looks at things freshly.
>
> Google v Oracle is an ongoing case. No precedent was set, because the case never actually came to rest. See the EFF's page on it:
>
> https://www.eff.org/cases/oracle-v-google
>
> Just my two cents,
>
> Robert "khuxkm" Miles

From krixano at protonmail.com  Thu Nov 26 08:28:42 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 08:28:42 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <UZ5_hC2V7bbqufhjErwQ9PAVJ286mL_VF8NYobx_ECGBk-yilNKIeyo-fNKH0yu_vIthH3QUhU6rHwtk0loo2Alu0umv8DTBttjFxDaCX4c=@protonmail.com>
References: <gBGmvPVlt4rw9TbSZEFgj2HjIqO_54dHFOgzr-OervqCIgXTj1HXPH9-sXNDKXfB03J7c5PwNtag79kqW7aoYD32CeM6sHPbiJNEazyitOI=@protonmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <81c36e52af1ae4266da1458448971e6c@tilde.team>
 <d885bb53bccfcd81c739f6aa464e3a6a@tilde.team>
 <6ab9f2dfa8baf65e889a7ef43633206b@tilde.team>
 <057535d375aaa21d35f387d751a3f149@tilde.team>
 <UZ5_hC2V7bbqufhjErwQ9PAVJ286mL_VF8NYobx_ECGBk-yilNKIeyo-fNKH0yu_vIthH3QUhU6rHwtk0loo2Alu0umv8DTBttjFxDaCX4c=@protonmail.com>
Message-ID: <SS4I688IE02ixsiiDQnO0EQdqOCQko3I0E5diti-A2yPNd_dLpjuK6UH_pLKEhmu2DNU-tyyOW91XxgUiqUcsjfOPcpMpUBc1nGIkalU884=@protonmail.com>

Correction, google made the case that APIs are patentable. Same difference, but still.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 2:25 AM, Krixano <krixano at protonmail.com> wrote:

> Yes, it's an ongoing case, but I actually read the whole case, and I'm almost 100% positive they are going to rule more in favor of Oracle, because Google made stupid claims, one of which is that software is patentable, btw.
>
> If you want to learn more about this, I would suggest this video series: https://caseorcontroversy.com/
>
> Btw, there was precedent set in the lower districts of this case. To say there was no precedent set is misinformation.
>
> Christian Seibold
>
> Sent with ProtonMail Secure Email.
>
> ??????? Original Message ???????
>
> On Thursday, November 26th, 2020 at 2:22 AM, Robert "khuxkm" Miles khuxkm at tilde.team wrote:
>
> > This conversation is getting away from Gemini, so I'm going to wrap it up here and let us agree to disagree.
> >
> > November 26, 2020 3:11 AM, "Krixano" krixano at protonmail.com wrote:
> >
> > > First of all, lets not conflate a spec with law. The spec
> > >
> > > doesn't have to follow law. A spec is a guideline, it doesn't
> > >
> > > have to match law, and it doesn't have to be adhered to either.
> >
> > Okay but if you wanted something for the law being broken (i.e; your copyright being infringed), you have to go in front of a court of law.
> >
> > > Secondly, let's actually look at what the court ruled here, on the implied license front:
> > >
> > > > consent to use the copyrighted work need not be manifested verbally and may be inferred based on
> > > >
> > > > silence where the copyright holder knows of the use and encourages it.
> > >
> > > Notice the "where the copyright holder knows of the use and encourages it."
> > >
> > > That's not necessarily the case in this discussion. It was the case in that court case.
> > >
> > > That court case literally doesn't apply here. Especially since Field explicitly added code
> > >
> > > so that search engines would index the URL of the page. This is not the case in this discussion
> > >
> > > as the
> > >
> > > absence of robots.txt would not be explicitly allowing search engines to index the URL of the
> > >
> > > page, and each
> > >
> > > server that doesn't have a robots.txt would not "know of the use and encourage it".
> >
> > I don't know where you got the idea that Field added code to make the engine index the URL-- that's what a search engine does-- but I don't care at this point.
> >
> > > Finally, precedents can be challenged by the Supreme Court. For example, the current Supreme Court
> > >
> > > case of Google v. Oracle dismissed everything the district courts and the Circuits had to say,
> > >
> > > because the Supreme Court looks at things freshly.
> >
> > Google v Oracle is an ongoing case. No precedent was set, because the case never actually came to rest. See the EFF's page on it:
> >
> > https://www.eff.org/cases/oracle-v-google
> >
> > Just my two cents,
> >
> > Robert "khuxkm" Miles

From luke at marmaladefoo.com  Thu Nov 26 10:15:49 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 26 Nov 2020 10:15:49 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace
 (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
Message-ID: <5FBF8055.4050204@marmaladefoo.com>



On 25-Nov-2020 00:18, Nick Thomas wrote:
>
> You're presuming consent here. We don't actually *know* that said 90%
> of hosts are happy to be archived; we only know that 90% of hosts
> haven't included a robots.txt file, which could be for any one of a
> multitude of reasons.
>
> *If* a not-insignificant proportion of those hosts without robots.txt
> files would actually prefer not to be included in archives when asked,
> the current situation is not serving their privacy well, and gemini is
> suppose to be protective of user privacy. *If* an overwhelming majority
> of them simply don't care, then sure, the argument for it starts to
> look a bit niche. Talking in IRC earlier today, I hand-waved a 5%
> threshold for the first condition and 1% for the second.
>
> A personal example: *I* didn't have a robots.txt on my capsule file
> until today, but I don't want to be included in archives for various
> reasons. Presuming consent from the lack of a robots.txt file would
> have incorrectly guessed my preference, and harmed my privacy. Who else
> in that 90% is like me? We don't know.
>
Hello all

Personally, I'm not really that interested in the legal arguments back 
and forth about archiving and access. Yes there are some legal case 
precedents in this area in some jurisdictions, but I would say that by 
and large that ship has sailed. Sorry about that folks. The web is the 
de-facto baseline reference in this respect, whether we like it or not.

If you *publish* information on the internet, there *will* be actors who 
will re-purpose it. Gemini is no different to the web in this.

If any of us have information that is to be preserved as private, I 
cannot see how you can expect that to be achieved if you publish on the 
public internet (i.e. servers that do not require authentication). If 
you want to hide something, use authentication or a private channel.

Yes there is robots.txt which is an opt-out mechanism, from general 
robot access to a server's content. It is established practice and good 
actors will respect it. But it cannot be a mechanism to preserve privacy.

My take on the whole "Gemini preserves privacy better" is really about 
clients. We don't have extended headers, cookies or agent names in 
requests. So to that extent, client privacy is maintained better than 
the web, where the expectation is of long term, cross-session tracking. 
We dont thankfully have that.

I don't see it as Gemini's role to attempt to set a cultural/legal 
privacy framework for servers who are choosing to publish on Gemini. We 
cannot imagine we can break new ground in this respect. We can however 
do our efforts to have this as a side effect of technical design in the 
protocol itself, and within the Gemini community we can look out for 
risks in exposing such personal information via the protocol.

If Gemini ever becomes interesting enough to the outside world that some 
case goes to court (what a publicity success that would be!), surely the 
existing infrastructure of public server hypertext systems, namely the 
web, will be the established precedent.

So I support use of robots.txt, but if none exists, the presumption - 
like the web -  is that access and usage is allowed. If some actor 
doesn't follow a server's robots.txt, I'm sad about it, but we should 
ultimately expect it.

  - Luke


From marcx2 at welz.org.za  Thu Nov 26 10:18:11 2020
From: marcx2 at welz.org.za (marc)
Date: Thu, 26 Nov 2020 11:18:11 +0100
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <mDbsJSJQkE93j18RMjjlQezgrX7tTZpSN5xuAUfUzDbrQyIIT5f9fkBjOgVMQJPAjUndpu97H1aXkUzitmdCN2JkX83UmQWtJzsgzB-9ZnI=@protonmail.com>
References: <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <jOm9unucX6Xf9h3vEYcS4l4aZFM_VMnZZ49htvQczsv_G04PArocbvAlSa8fggNAM1obmJLwYGqTzw6zvpNnPGx7WjcSSHMqvH2E6GhadkU=@protonmail.com>
 <mDbsJSJQkE93j18RMjjlQezgrX7tTZpSN5xuAUfUzDbrQyIIT5f9fkBjOgVMQJPAjUndpu97H1aXkUzitmdCN2JkX83UmQWtJzsgzB-9ZnI=@protonmail.com>
Message-ID: <20201126101811.GA23971@localhost.localdomain>


Hello Christian

> One more thing I want to point out... copyright law isn't opt-in. It's opt-out.
> If you don't have a copyright statement or any other licensing information,
> then "all rights reserved" is automatically assumed, afaik. You can't just copy
> something just because the author didn't explicitly disallow you from doing that.

Yes - copyright legislation hasn't been repealed :-)

*But* by putting things on the web, the creator has granted the
world some implied license. The convention which has evolved for
the web is that without a robots.txt forbidding it, crawlers
are free to index and cache, and some other things too. The
boundaries of this are fuzzy, because the conditions weren't
stated at the outset.

But gemini isn't the web, and gemini is new, so maybe we can
do better and *not* rely on an implied license (all humans may
visit this capsule), and then a robots.txt for just one single
bit of extra information (autonomous software can crawl it too,
if not forbidden).

So many thoughtful people are hesitant to put their data
online - they fear that this may disadvantage them in
future - maybe they worry about employer discrimination, doxxing
or biometric harvesting (from facial detail to writing style)
or things not yet invented.

Given that everybody has different tolerances, a mechanism
whereby people can state their preferences would be a good
thing.

Blindly copying the web robots.txt mechanism seems to be too
coarse/too vague, and too easily decoupled.

regards

marc

-- CC-SA

From krixano at protonmail.com  Thu Nov 26 10:22:51 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 10:22:51 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <5FBF8055.4050204@marmaladefoo.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <5FBF8055.4050204@marmaladefoo.com>
Message-ID: <_MlwWaJv1RqLJ_aLuOlJo04ZyexXidF00axz4dxtIks9dd3iBRfZkJ4OGs8r3JKk1-IBBVMaSF0JqA3FFLWAKAyIogdOsgy3LF0D9aQMvhA=@protonmail.com>

My arguments weren't just about privacy. They were also about copyright.
Sharing on the internet is fine, but copyright still applies.

Secondly, You can share something for free online for a short period of time, and
then remove it after that time limit. This was done with a lot of books during a
portion of the Covid pandemic we are in. To say that archives should be able to permanently
cache this without explicit permission makes no logical sense.

Anyways, back to my original argument, caching should be opt-in. It makes the most sense.
*Granting permission* to use, modify, distribute something should be opt-in. Not opt-out.

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 4:15 AM, Luke Emmet <luke at marmaladefoo.com> wrote:

> On 25-Nov-2020 00:18, Nick Thomas wrote:
>
> > You're presuming consent here. We don't actually know that said 90%
> >
> > of hosts are happy to be archived; we only know that 90% of hosts
> >
> > haven't included a robots.txt file, which could be for any one of a
> >
> > multitude of reasons.
> >
> > If a not-insignificant proportion of those hosts without robots.txt
> >
> > files would actually prefer not to be included in archives when asked,
> >
> > the current situation is not serving their privacy well, and gemini is
> >
> > suppose to be protective of user privacy. If an overwhelming majority
> >
> > of them simply don't care, then sure, the argument for it starts to
> >
> > look a bit niche. Talking in IRC earlier today, I hand-waved a 5%
> >
> > threshold for the first condition and 1% for the second.
> >
> > A personal example: I didn't have a robots.txt on my capsule file
> >
> > until today, but I don't want to be included in archives for various
> >
> > reasons. Presuming consent from the lack of a robots.txt file would
> >
> > have incorrectly guessed my preference, and harmed my privacy. Who else
> >
> > in that 90% is like me? We don't know.
>
> Hello all
>
> Personally, I'm not really that interested in the legal arguments back
>
> and forth about archiving and access. Yes there are some legal case
>
> precedents in this area in some jurisdictions, but I would say that by
>
> and large that ship has sailed. Sorry about that folks. The web is the
>
> de-facto baseline reference in this respect, whether we like it or not.
>
> If you publish information on the internet, there will be actors who
>
> will re-purpose it. Gemini is no different to the web in this.
>
> If any of us have information that is to be preserved as private, I
>
> cannot see how you can expect that to be achieved if you publish on the
>
> public internet (i.e. servers that do not require authentication). If
>
> you want to hide something, use authentication or a private channel.
>
> Yes there is robots.txt which is an opt-out mechanism, from general
>
> robot access to a server's content. It is established practice and good
>
> actors will respect it. But it cannot be a mechanism to preserve privacy.
>
> My take on the whole "Gemini preserves privacy better" is really about
>
> clients. We don't have extended headers, cookies or agent names in
>
> requests. So to that extent, client privacy is maintained better than
>
> the web, where the expectation is of long term, cross-session tracking.
>
> We dont thankfully have that.
>
> I don't see it as Gemini's role to attempt to set a cultural/legal
>
> privacy framework for servers who are choosing to publish on Gemini. We
>
> cannot imagine we can break new ground in this respect. We can however
>
> do our efforts to have this as a side effect of technical design in the
>
> protocol itself, and within the Gemini community we can look out for
>
> risks in exposing such personal information via the protocol.
>
> If Gemini ever becomes interesting enough to the outside world that some
>
> case goes to court (what a publicity success that would be!), surely the
>
> existing infrastructure of public server hypertext systems, namely the
>
> web, will be the established precedent.
>
> So I support use of robots.txt, but if none exists, the presumption -
>
> like the web - is that access and usage is allowed. If some actor
>
> doesn't follow a server's robots.txt, I'm sad about it, but we should
>
> ultimately expect it.
>
> -   Luke

From krixano at protonmail.com  Thu Nov 26 10:27:03 2020
From: krixano at protonmail.com (Krixano)
Date: Thu, 26 Nov 2020 10:27:03 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace (Was: Re: robots.txt
 for Gemini formalised)
In-Reply-To: <20201126101811.GA23971@localhost.localdomain>
References: <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <jOm9unucX6Xf9h3vEYcS4l4aZFM_VMnZZ49htvQczsv_G04PArocbvAlSa8fggNAM1obmJLwYGqTzw6zvpNnPGx7WjcSSHMqvH2E6GhadkU=@protonmail.com>
 <mDbsJSJQkE93j18RMjjlQezgrX7tTZpSN5xuAUfUzDbrQyIIT5f9fkBjOgVMQJPAjUndpu97H1aXkUzitmdCN2JkX83UmQWtJzsgzB-9ZnI=@protonmail.com>
 <20201126101811.GA23971@localhost.localdomain>
Message-ID: <vtv-oLtjOfrhcNPK-M_jvMopoiWWhxhs1yZKXmtLHerV0HV3pBVmdYjWx76xPxqktbXyLtviJ36Ips366sTRs4LDbQ6kooShxtzmyi0zzwU=@protonmail.com>

> *But* by putting things on the web, the creator has granted the
world some implied license.

This is not true. The only implied license is to view
the thing put online. Redistributing it is not implied by putting
something online, and neither is modifying, unless it's
under Fair Use (a transformative work).

Christian Seibold

Sent with ProtonMail Secure Email.

??????? Original Message ???????

On Thursday, November 26th, 2020 at 4:18 AM, marc <marcx2 at welz.org.za> wrote:

> Hello Christian
>
> > One more thing I want to point out... copyright law isn't opt-in. It's opt-out.
> >
> > If you don't have a copyright statement or any other licensing information,
> >
> > then "all rights reserved" is automatically assumed, afaik. You can't just copy
> >
> > something just because the author didn't explicitly disallow you from doing that.
>
> Yes - copyright legislation hasn't been repealed :-)
>
> But by putting things on the web, the creator has granted the
>
> world some implied license. The convention which has evolved for
>
> the web is that without a robots.txt forbidding it, crawlers
>
> are free to index and cache, and some other things too. The
>
> boundaries of this are fuzzy, because the conditions weren't
>
> stated at the outset.
>
> But gemini isn't the web, and gemini is new, so maybe we can
>
> do better and not rely on an implied license (all humans may
>
> visit this capsule), and then a robots.txt for just one single
>
> bit of extra information (autonomous software can crawl it too,
>
> if not forbidden).
>
> So many thoughtful people are hesitant to put their data
>
> online - they fear that this may disadvantage them in
>
> future - maybe they worry about employer discrimination, doxxing
>
> or biometric harvesting (from facial detail to writing style)
>
> or things not yet invented.
>
> Given that everybody has different tolerances, a mechanism
>
> whereby people can state their preferences would be a good
>
> thing.
>
> Blindly copying the web robots.txt mechanism seems to be too
>
> coarse/too vague, and too easily decoupled.
>
> regards
>
> marc
>
> -- CC-SA

From bjorn.warmedal at gmail.com  Thu Nov 26 11:02:12 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 26 Nov 2020 12:02:12 +0100
Subject: On certificates and validation
In-Reply-To: <20201125152236.GA5853@localhost.localdomain>
References: <CAJScK0KNOv=E2B2Qo8sU=pHE8DFROoFs-7rgyGufR92=xNr-rA@mail.gmail.com>
 <C7CD2DP18NIT.2OAI6N8UP237F@taiga>
 <20201125152236.GA5853@localhost.localdomain>
Message-ID: <CAJScK0KXtGZSWbTLTA8GL4PCECvagxA60EHCu8GhWwOaQ=h89A@mail.gmail.com>

> Ssh doesn't expire its keys, and isn't worse for that.

This is the analogue I was looking for. SSH doesn't care about Common
Name or other cruft in the cert, either.

I agree that some sort of sanity check is nice, but at the same time I
have trouble finding a philosophical or practical reason for doing any
sort of validation on first use, and any beyond "same as last time" on
subsequent visits.

Yes, Drew says I should. But are there any arguments supporting that position?

Cheers,
ew0k

From gmym at coopdot.com  Thu Nov 26 12:19:46 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Thu, 26 Nov 2020 13:19:46 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <Ue0YLojaEA74m46D0lKTuwKWuIPRc-crszF5u7DmSdEFC2Ixo-PpWE8TZ4zCN_AQU1SrvVCaZJ6cSUYTVZLzn2C2QYz0AZZgkJOJ21Cmay4=@protonmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
 <bCwdC-hrWfqEcVPoqD49hlzWMkLLcADAvDoX5JUwRoaRQkpAsNktCrokUZSuuetIywY66qh6FqN2d9yZCs11Sp3u5KrUHi9C1rgKN9Tyk5I=@protonmail.com>
 <Ue0YLojaEA74m46D0lKTuwKWuIPRc-crszF5u7DmSdEFC2Ixo-PpWE8TZ4zCN_AQU1SrvVCaZJ6cSUYTVZLzn2C2QYz0AZZgkJOJ21Cmay4=@protonmail.com>
Message-ID: <CAObwWNisf9QA7SyAxELHRcBK+MctAmkeonJ8BCATvqenz8XWjw@mail.gmail.com>

Krixano <krixano at protonmail.com> wrote:

> To further what I'm saying. Italics often conveys emphasis,
> which is conveyed in speech with intonation. Intonation is
> data itself. Italics is one of the few methods we can convey
> that in writing.
>

Gemtext is limited similarly to typewriters in that they don't typically
support italics. How did they express emphasis on typewriters? On the other
hand, the output of typewriters wasn't meant to be accessible to screen
readers.

I have already listed a bunch of different ways to convey the same thing as
you would with italics and their drawbacks.

Sidenote:
Since gemtext is UTF-8 by default and lack a way to suggest a custom font,
you could probably extend UTF-8 in the range <U+F0000> to <U+10FFFF> for
markup, like <U+F7777> for emphasis. I really don't like that idea, but you
get away from clashing with snake_case and the like.

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/3e1477a5/attachment.htm>

From sir at cmpwn.com  Thu Nov 26 13:01:44 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 26 Nov 2020 08:01:44 -0500
Subject: On certificates and validation
In-Reply-To: <CAJScK0KXtGZSWbTLTA8GL4PCECvagxA60EHCu8GhWwOaQ=h89A@mail.gmail.com>
Message-ID: <C7D7R32PHPGZ.A5AQXP8VGQGQ@taiga>

On Thu Nov 26, 2020 at 6:02 AM EST, Bj?rn W?rmedal wrote:
> > Ssh doesn't expire its keys, and isn't worse for that.
>
> This is the analogue I was looking for. SSH doesn't care about Common
> Name or other cruft in the cert, either.

We use TLS, not SSH.

> I agree that some sort of sanity check is nice, but at the same time I
> have trouble finding a philosophical or practical reason for doing any
> sort of validation on first use, and any beyond "same as last time" on
> subsequent visits.
>
> Yes, Drew says I should. But are there any arguments supporting that
> position?

These are configurable parameters. If they are configured incorrectly,
then we should reject the certificate. Someone may have configured them
with an expiration, for example, by design, knowing that their server
would soon disappear, and that certificate reuse signals that something
stinky is going on. Or the common name could be set because the admin
has chosen to set up their own certificate authority, perhaps complete
with signed client-side certificates, and the common name is used to
strongly identify the server.

Consider that the stakes are leaking your user's private information and
do your goddamn job as a responsible steward of their needs.

From tomasino at lavabit.com  Thu Nov 26 13:04:58 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Thu, 26 Nov 2020 13:04:58 +0000
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <vtv-oLtjOfrhcNPK-M_jvMopoiWWhxhs1yZKXmtLHerV0HV3pBVmdYjWx76xPxqktbXyLtviJ36Ips366sTRs4LDbQ6kooShxtzmyi0zzwU=@protonmail.com>
References: <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <CAD2gp_Txtsj6sJF+Eget-6CK-EnBj=njGxMQZhExcRSSjDhurQ@mail.gmail.com>
 <0cc4e20410ecc7e98e048a2a54216068c8c71612.camel@ur.gs>
 <CAD2gp_QG-c7mTSoiUOzdjuAmfG3kW6cUziHVAEd47Ww9PjnDeg@mail.gmail.com>
 <jOm9unucX6Xf9h3vEYcS4l4aZFM_VMnZZ49htvQczsv_G04PArocbvAlSa8fggNAM1obmJLwYGqTzw6zvpNnPGx7WjcSSHMqvH2E6GhadkU=@protonmail.com>
 <mDbsJSJQkE93j18RMjjlQezgrX7tTZpSN5xuAUfUzDbrQyIIT5f9fkBjOgVMQJPAjUndpu97H1aXkUzitmdCN2JkX83UmQWtJzsgzB-9ZnI=@protonmail.com>
 <20201126101811.GA23971@localhost.localdomain>
 <vtv-oLtjOfrhcNPK-M_jvMopoiWWhxhs1yZKXmtLHerV0HV3pBVmdYjWx76xPxqktbXyLtviJ36Ips366sTRs4LDbQ6kooShxtzmyi0zzwU=@protonmail.com>
Message-ID: <96cf4723-dd71-6a31-c136-a199c86efa09@lavabit.com>

On 11/26/20 10:27 AM, Krixano wrote:
>> *But* by putting things on the web, the creator has granted the
> world some implied license.
> 
> This is not true. The only implied license is to view
> the thing put online. Redistributing it is not implied by putting
> something online, and neither is modifying, unless it's
> under Fair Use (a transformative work).
> 
> Christian Seibold

Wow this thread blew up overnight. Anyway, I was the one that first posted about Field v. Google as one example case about litigation related to search engines and copyright. In an effort to avoid more "someone is wrong on the internet" arguments, here's the crux:

- If you as a copyright holder want to deny your content being cached and served by a 3rd party (for instance a search engine) you have a well known mechanism to do so in robots.txt.

- If your content is archived or cached against your desires your means of remediation are legal ones. Taking the issue to court will result in a court deciding if you are within your rights to protect your content or if the searcher/archiver/indexer is under fair use.

- The rules around copyright and media protections are established in each country, but are nearly universally applied worldwide via the Berne Convention and/or agreements like the Electronic Commerce Directive. 

- Existing legal precedent suggests you can expect a ruling in favor of implied consent if you do not have a robots.txt. 

All of this is to suggest we save ourselves the trouble down the road and just use robots.txt as-is.


Finally, and completely unrelated to everything: it was Oracle who tried to claim their APIs via patent rather than the other way around. See:
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.#First_phase:_API_copyrightability_and_patents


From marcx2 at welz.org.za  Thu Nov 26 16:24:40 2020
From: marcx2 at welz.org.za (marc)
Date: Thu, 26 Nov 2020 17:24:40 +0100
Subject: Assuming disallow-all, and some research on robots.txt in
 Geminispace (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <5FBF8055.4050204@marmaladefoo.com>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <5FBF8055.4050204@marmaladefoo.com>
Message-ID: <20201126162440.GA27406@localhost.localdomain>

Hi

> I don't see it as Gemini's role to attempt to set a cultural/legal privacy
> framework for servers who are choosing to publish on Gemini. We cannot
> imagine we can break new ground in this respect.

That seems ... rather defeatist. 

Alasdair Gray provides an inspirational quote for a situation like this:

  "Work as if you live in the early days of a better nation"

(apparently later he wanted to say world, but nation had stuck...)

Gemini is still a young project, where a different culture
and nicer norms could be established...

Long ago, before the web, when the internet was young
somebody grabbed the jokes from rec.humor.funny (I think, might
have been another newsgroup) and published them in book form. Some
posters were outraged at the copyright violation, others
flattered. 

Had the individual posters just had a way of telling us
how their material could have been re-used, there would
have been no controversy, and maybe this would have
laid the groundwork for a different way of aggregating
online material, with internet editors neatly assembling
"best-ofs" or "my conversations-with-..." and people
optimising their comments for quotability or adding
footnotes and expansions to posts they were keen to
improve... instead of just feeble likes.

TLDR: I can imagine it. 

regards

marc

From alex at nytpu.com  Thu Nov 26 16:28:58 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Thu, 26 Nov 2020 09:28:58 -0700
Subject: Please stop top posting
Message-ID: <20201126162858.yn2z3lhngy7safby@GLaDOS>

Hi all,

I've noticed that some people top-post, and when it's only once in a
while it's tolerable, but when I wake up and my email digests total up
to 100KiB because half of the emails are copying and pasting all the
previous emails in the entire chain, it gets very arduous to read.

A polite request/reminder asking for people to bottom post.
Being able to quote whoever you're addressing makes it easier to write
your responses too, so bottom posting makes it easier for both the
author and the readers.

~nytpu

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/7a2ad458/attachment.sig>

From list at gkbrk.com  Thu Nov 26 16:40:18 2020
From: list at gkbrk.com (Leo)
Date: Thu, 26 Nov 2020 19:40:18 +0300
Subject: Please stop top posting
In-Reply-To: <20201126162858.yn2z3lhngy7safby@GLaDOS>
References: <20201126162858.yn2z3lhngy7safby@GLaDOS>
Message-ID: <04d5001a-745e-1f68-4b2a-2df11bfa887e@gkbrk.com>

On a similar note on email etiquette; I'd also like to either get the 
mailing list switched
to plain text only, or for everyone participating to configure their 
email clients properly.

There are lots of guides online to do either of those, and it will 
massively clean up the
discussions here.

-- Leo

From roy at royniang.com  Thu Nov 26 16:43:43 2020
From: roy at royniang.com (roy niang)
Date: Thu, 26 Nov 2020 17:43:43 +0100
Subject: Please stop top posting
In-Reply-To: <04d5001a-745e-1f68-4b2a-2df11bfa887e@gkbrk.com>
References: <20201126162858.yn2z3lhngy7safby@GLaDOS>
 <04d5001a-745e-1f68-4b2a-2df11bfa887e@gkbrk.com>
Message-ID: <20d8ca17-2792-43d9-abab-71ce1e4be231@www.fastmail.com>

> There are lots of guides online to do either of those, and it will 
> massively clean up the
> discussions here.

BTW, your lines are strangely wrapped.

From ehmry at posteo.net  Thu Nov 26 16:45:33 2020
From: ehmry at posteo.net (Emery)
Date: Thu, 26 Nov 2020 17:45:33 +0100
Subject: Please stop top posting
In-Reply-To: <20d8ca17-2792-43d9-abab-71ce1e4be231@www.fastmail.com>
References: <20201126162858.yn2z3lhngy7safby@GLaDOS>
 <04d5001a-745e-1f68-4b2a-2df11bfa887e@gkbrk.com>
 <20d8ca17-2792-43d9-abab-71ce1e4be231@www.fastmail.com>
Message-ID: <12972a2d-be12-45d4-832c-31b744e62b0f@posteo.net>

On Donnerstag, 26. November 2020 17:43:43 CET, roy niang wrote:
>> There are lots of guides online to do either of those, and it will 
>> massively clean up the
>> discussions here.
>
> BTW, your lines are strangely wrapped.
>
>

What's a bottom post?

From roy at royniang.com  Thu Nov 26 16:49:28 2020
From: roy at royniang.com (roy niang)
Date: Thu, 26 Nov 2020 17:49:28 +0100
Subject: Please stop top posting
In-Reply-To: <12972a2d-be12-45d4-832c-31b744e62b0f@posteo.net>
References: <20201126162858.yn2z3lhngy7safby@GLaDOS>
 <04d5001a-745e-1f68-4b2a-2df11bfa887e@gkbrk.com>
 <20d8ca17-2792-43d9-abab-71ce1e4be231@www.fastmail.com>
 <12972a2d-be12-45d4-832c-31b744e62b0f@posteo.net>
Message-ID: <621de948-7903-4bc7-905e-4bf2aec9234f@www.fastmail.com>

> What's a bottom post?

Here are some posting conventions: 

https://en.wikipedia.org/wiki/Posting_style#Bottom-posting

From luke at marmaladefoo.com  Thu Nov 26 17:18:59 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 26 Nov 2020 17:18:59 +0000
Subject: Assuming disallow-all,
 and some research on robots.txt in Geminispace
 (Was: Re: robots.txt for Gemini formalised)
In-Reply-To: <20201126162440.GA27406@localhost.localdomain>
References: <88e2d72e36fe044250c6bb8b28fb901d0de57af6.camel@ur.gs>
 <C79XPGLWFE5E.3L6WKME61MN8U@stilgar>
 <9204cd8ffec11727b17764729e60e69be7b8517d.camel@ur.gs>
 <CAEzvDCUbHEVujhRzMD9uGhNLCKa454K_GN=6ELOdjwNbrnn6SQ@mail.gmail.com>
 <b0cde998-0ce5-9442-795a-ece30e89f18d@lavabit.com>
 <a75cf3477ad8e01859ea55cb1c87d937@tilde.team>
 <9cea8f8a58cf006ec109b235e5a891aebb68681b.camel@ur.gs>
 <CAD2gp_RFkZTho34Vad3KnNROxCwqbaKj9NBWt-ceBRjd-ubQxQ@mail.gmail.com>
 <cfd687d61a8c3a685c4e74682403918404135710.camel@ur.gs>
 <5FBF8055.4050204@marmaladefoo.com>
 <20201126162440.GA27406@localhost.localdomain>
Message-ID: <5FBFE383.10608@marmaladefoo.com>



On 26-Nov-2020 16:24, marc wrote:
>> I don't see it as Gemini's role to attempt to set a cultural/legal privacy
>> framework for servers who are choosing to publish on Gemini. We cannot
>> imagine we can break new ground in this respect.
> That seems ... rather defeatist.
>
> Alasdair Gray provides an inspirational quote for a situation like this:
>
>    "Work as if you live in the early days of a better nation"
Well, I wasn't expecting to have my Utopian credentials questioned ;-)

After all, I am a proponent of Gemini like everyone else here, pushing 
against the flow.

But its true I'm probably towards the pragmatic end of the scale, and I 
like to see people discussing subjects I find to be productive. Trying 
to establish alternative IPR legal precedents, contrary to the flow of 
what happens on the web seems like a lot of work to me and we can spin a 
lot of cycles doing so. But if it rings your bell, by all means continue.

I'm all for building a nice culture among the gemini-folk, but wider 
cultural changes happen slowly in my experience.

  - Luke

From list at gkbrk.com  Thu Nov 26 17:19:28 2020
From: list at gkbrk.com (Leo)
Date: Thu, 26 Nov 2020 20:19:28 +0300
Subject: Please stop top posting
In-Reply-To: <20d8ca17-2792-43d9-abab-71ce1e4be231@www.fastmail.com>
Message-ID: <C7DD8EU8NYY1.1531PNQJF8EI3@rath>

> BTW, your lines are strangely wrapped.

Whelp, this is what I get for switching to Thunderbird occasionally. I
think for some reason the editor component of Thunderbird does not
represent what is going to be sent even when my emails are set to Plain
Text.

Thanks for bringing it to my attention.

-- Leo

From lazar.michael22 at gmail.com  Thu Nov 26 18:41:11 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 26 Nov 2020 13:41:11 -0500
Subject: On certificates and validation
In-Reply-To: <C7D7R32PHPGZ.A5AQXP8VGQGQ@taiga>
References: <CAJScK0KXtGZSWbTLTA8GL4PCECvagxA60EHCu8GhWwOaQ=h89A@mail.gmail.com>
 <C7D7R32PHPGZ.A5AQXP8VGQGQ@taiga>
Message-ID: <CAFTy05bA3fLjR5imUpn2X=g0vKR01nK7UWryVZc=+28GtBjeJw@mail.gmail.com>

On Thu, Nov 26, 2020 at 6:02 AM Bj?rn W?rmedal <bjorn.warmedal at gmail.com>
wrote:
>
> > Ssh doesn't expire its keys, and isn't worse for that.
>
> This is the analogue I was looking for. SSH doesn't care about Common
> Name or other cruft in the cert, either.
>
> I agree that some sort of sanity check is nice, but at the same time I
> have trouble finding a philosophical or practical reason for doing any
> sort of validation on first use, and any beyond "same as last time" on
> subsequent visits.
>
> Yes, Drew says I should. But are there any arguments supporting that
position?
>

I fully agree that the expiration date is useless in TOFU schemes. I brought
this up on the mailing list a while ago and I didn't see any rebuttals that
really convinced me otherwise. The mailing list settled on recommending a
long
expiration times of several years, but that was just dodging the fundamental
problem IMO. I think it will still take folks a while to come around to this
conclusion. Thank you for giving me some hope :)

I didn't make the logical jump at the time, but certificate hostnames are
similarly useless in TOFU for the same reason. They don't verify anything
since
they can be trivially forged.

On Thu, Nov 26, 2020 at 8:04 AM Drew DeVault <sir at cmpwn.com> wrote:
> These are configurable parameters. If they are configured incorrectly,
> then we should reject the certificate. Someone may have configured them
> with an expiration, for example, by design, knowing that their server
> would soon disappear, and that certificate reuse signals that something
> stinky is going on.

The expiration date does not protect against anything in this scenario. An
attacker can trivially generate a new certificate to send to the client if
they see the old one has expired.

> Or the common name could be set because the admin
> has chosen to set up their own certificate authority, perhaps complete
> with signed client-side certificates, and the common name is used to
> strongly identify the server.

Now you're talking about CA verified certificates. There's nothing wrong
with
using self-signed CAs, but it's a completely different security model than
TOFU and shouldn't be confused with it.

- Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/f8b64432/attachment-0001.htm>

From sir at cmpwn.com  Thu Nov 26 18:42:36 2020
From: sir at cmpwn.com (Drew DeVault)
Date: Thu, 26 Nov 2020 13:42:36 -0500
Subject: On certificates and validation
In-Reply-To: <CAFTy05bA3fLjR5imUpn2X=g0vKR01nK7UWryVZc=+28GtBjeJw@mail.gmail.com>
Message-ID: <C7DF02E1XGPB.33MW79F8VG7UW@taiga>

On Thu Nov 26, 2020 at 1:41 PM EST, Michael Lazar wrote:
> Now you're talking about CA verified certificates. There's nothing
> wrong with using self-signed CAs, but it's a completely different
> security model than TOFU and shouldn't be confused with it.

Mostly correct. What we have is TOFU on top of TLS, not just TOFU. And
because these parameters are present, it's likely that someone may rely
on them. And if they do, and put their personal security on the line for
it, then we can hardly call that a mistake.

Gemini uses TLS. That comes with warts. That's life.

From lazar.michael22 at gmail.com  Thu Nov 26 19:32:24 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Thu, 26 Nov 2020 14:32:24 -0500
Subject: On certificates and validation
In-Reply-To: <C7DF02E1XGPB.33MW79F8VG7UW@taiga>
References: <CAFTy05bA3fLjR5imUpn2X=g0vKR01nK7UWryVZc=+28GtBjeJw@mail.gmail.com>
 <C7DF02E1XGPB.33MW79F8VG7UW@taiga>
Message-ID: <CAFTy05bxjxuJVmxnjObaEeZ3kuWN5Pcv75M7c7zvTU+YW1Z0kA@mail.gmail.com>

On Thu, Nov 26, 2020 at 1:43 PM Drew DeVault <sir at cmpwn.com> wrote:
>
> On Thu Nov 26, 2020 at 1:41 PM EST, Michael Lazar wrote:
> > Now you're talking about CA verified certificates. There's nothing
> > wrong with using self-signed CAs, but it's a completely different
> > security model than TOFU and shouldn't be confused with it.
>
> Mostly correct. What we have is TOFU on top of TLS, not just TOFU. And
> because these parameters are present, it's likely that someone may rely
> on them. And if they do, and put their personal security on the line for
> it, then we can hardly call that a mistake.
>
> Gemini uses TLS. That comes with warts. That's life.

I like to think of gemini as TLS + TOFU whereas the web uses TLS + PKI. TLS by
itself is not a complete security model without something on top of it to
establish trust.

We're talking about validating x509 certs here which were literally designed to
work with PKI [0]. Using them in any other context is throwing the whole
security model out the window. Nobody can "rely" on x509 parameters in
that sense. They might think they can, and giving them that false sense of
security is the wrong thing to do.

(are there other types of certs that can be used with TLS? I have no idea, but
if so I bet they aren't supported by openssl...)

- Michael

[0] https://tools.ietf.org/html/rfc5280

From bjorn.warmedal at gmail.com  Thu Nov 26 19:41:15 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 26 Nov 2020 20:41:15 +0100
Subject: On certificates and validation
In-Reply-To: <C7DF02E1XGPB.33MW79F8VG7UW@taiga>
References: <CAFTy05bA3fLjR5imUpn2X=g0vKR01nK7UWryVZc=+28GtBjeJw@mail.gmail.com>
 <C7DF02E1XGPB.33MW79F8VG7UW@taiga>
Message-ID: <CAJScK0+9YCSqYXVntp5qZgE6WB65cnWcjcp9cX-gqPsJ0ubByA@mail.gmail.com>

> These are configurable parameters. If they are configured incorrectly,
> then we should reject the certificate.

First of all, you're completely right. They are configurable
parameters. Which also means that a matching hostname or valid date
range means absolute zilch, sadly. It's just letters and numbers.

Secondly, I'd be much obliged if you could define "incorrectly" in
some objective manner. I see how it's more informative to use my
hostname as Common Name or SAN, but I don't see that it gives any more
*security* or objective *correctness* than, say, "ew0k's Server" or
even just "ew0k". If I decide that my client requires the hostname to
match one of those provided by the cert that's an entirely arbitrary
decision. In the best case it just gives me some more code to write,
while in the worst case it lulls users into a false sense of security.

> Someone may have configured them
> with an expiration, for example, by design, knowing that their server
> would soon disappear, and that certificate reuse signals that something
> stinky is going on.

Let's say I as a sysadmin did that. Then my cert and domain
registration expired, and someone else snatched it up and presented
their own certificate. The gemini browsers would now tell users that
"there's a new cert here, and the previous had expired". What security
did we achieve in this scenario?

> Or the common name could be set because the admin
> has chosen to set up their own certificate authority, perhaps complete
> with signed client-side certificates, and the common name is used to
> strongly identify the server.

I don't see how this is an argument for clients attempting to validate
the server certs... Did I misunderstand something here?

Consider this scenario: I have the domain tinyrabbit.ml (not serving
much of anything on any protocol, but still). Say I create a cert with
the CN "tinyrabbit.ml" and set up a gemini server there. I get
recurring visitors. After a few months I want to set up a subdomain
app.tinyrabbit.ml. Oh, shoot, I should have made that cert a wildcard.
Oh, well.

My choices are now to either create another certificate strictly for
app.tinyrabbit.ml, and then have two certs to keep track of. Or I
create a new certificate for "*.tinyrabbit.ml" to future proof it, and
serve this on the full domain. But now I opened a window for a MitM
attack -- or at least a lot of questions from concerned users who
wonder why my cert suddenly changed. Both of these are avoided if I
can just keep using the old certificate for the full domain, and no
security is lost.

> Mostly correct. What we have is TOFU on top of TLS, not just TOFU. And
> because these parameters are present, it's likely that someone may rely
> on them. And if they do, and put their personal security on the line for
> it, then we can hardly call that a mistake.
>
> Gemini uses TLS. That comes with warts. That's life.

I probably have huge blindspots concerning cert handling in TLS
specifically, but I don't understand at all what this means in this
case o.?

> Consider that the stakes are leaking your user's private information and
> do your goddamn job as a responsible steward of their needs.

I'm trying to do it. No need to be snarky.

Cheers,
ew0k

From ben at benaaron.dev  Thu Nov 26 22:17:05 2020
From: ben at benaaron.dev (Ben Goldberg)
Date: Thu, 26 Nov 2020 17:17:05 -0500
Subject: Please stop top posting
In-Reply-To: <04d5001a-745e-1f68-4b2a-2df11bfa887e@gkbrk.com>
References: <20201126162858.yn2z3lhngy7safby@GLaDOS>
 <04d5001a-745e-1f68-4b2a-2df11bfa887e@gkbrk.com>
Message-ID: <b8ab5abd-d31b-98e2-050e-6985f73484d4@benaaron.dev>

> There are lots of guides online to do either of those, and it will 
> massively clean up the
> discussions here.

For anyone who needs help with this: https://useplaintext.email/


From cowan at ccil.org  Fri Nov 27 00:04:14 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 26 Nov 2020 19:04:14 -0500
Subject: On certificates and validation
In-Reply-To: <CAFTy05bA3fLjR5imUpn2X=g0vKR01nK7UWryVZc=+28GtBjeJw@mail.gmail.com>
References: <CAJScK0KXtGZSWbTLTA8GL4PCECvagxA60EHCu8GhWwOaQ=h89A@mail.gmail.com>
 <C7D7R32PHPGZ.A5AQXP8VGQGQ@taiga>
 <CAFTy05bA3fLjR5imUpn2X=g0vKR01nK7UWryVZc=+28GtBjeJw@mail.gmail.com>
Message-ID: <CAD2gp_SYR-CnwW5STRffP=-2PMLTjE1kFwoXVVzC_109jVo-qw@mail.gmail.com>

On Thu, Nov 26, 2020 at 1:41 PM Michael Lazar <lazar.michael22 at gmail.com>
wrote:


> I fully agree that the expiration date is useless in TOFU schemes.
>

However, they make all kinds of sense in client certs. If you see an
expired cert coming from a client, it is most likely a replay attack (or a
broken client).  If the client cert is meant for user identification, you
will of course need to provide the hash of the newly created cert to the
server administrator.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
How comes city and country to be filled with drones and rogues, our highways
with hackers, and all places with sloth and wickedness?
                --W. Blith, Eng. Improver Improved, 1652
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/60221352/attachment.htm>

From gemini at ur.gs  Fri Nov 27 00:56:22 2020
From: gemini at ur.gs (Nick Thomas)
Date: Fri, 27 Nov 2020 00:56:22 +0000
Subject: Translation service
Message-ID: <b4367dcced30b873a8c2a183607f9e92fe43be89.camel@ur.gs>

Hola mis amigos!

I didn't find a capsule offering translation services in Geminispace,
so I've put one together. It's linked from gemini://ur.gs, or you can
construct a translation request URL manually, like so:

gemini://ur.gs/cgi-bin/translate/en/es?Hello%20world

Only en->es and es->en are supported right now; he estado aprendiendo
espa?ol casi dos a?os ahora.

You can visit gemini://ur.gs/cgi-bin/translate to get a 10 prompt for
translation.

It's using apertium, running on the same machine as the gemini server. 
If people like the service, I'll set up a babel.ur.gs or so somewhere,
with more language pairs.

Improvements... well, visiting /translate could prompt for the source
language, and /translate/en could prompt for the destination language.
It could also, conceivably, take a URL to perform translation for.

Let me know what you think. I'm especially interested in translation
quality and responsiveness - I only learned about apertium todaym and
I've managed to get some pretty bad translations out of it so far :D.
If you have suggestions for alternatives, I'm all ears, although
apertium was pleasingly simple to set up. I might never visit deepl
again!

Source code for the cgi-bin script is here: 
https://code.ur.gs/lupine/capsule/src/branch/main/src/cgi-bin/translate
- it relies on the apertium and aperium-en-es packages being installed
on the same machine, and on everything being UTF-8 throughout.

/Nick


From cowan at ccil.org  Fri Nov 27 03:23:35 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 26 Nov 2020 22:23:35 -0500
Subject: On the use of %20 instead of + in URIs
In-Reply-To: <C7C2XO98PIDB.15J56R2JVFINO@nitro>
References: <C7C2XO98PIDB.15J56R2JVFINO@nitro>
Message-ID: <CAD2gp_SyyjdooaACzUNcrtd-2zeRgA_Oqa_X9pnLG4r0eYR=hw@mail.gmail.com>

On Wed, Nov 25, 2020 at 12:14 AM Adnan Maolood <me at adnano.co> wrote:

If servers should not treat plus signs as spaces, then I think that this
> portion of the specification should be changed to say:
>
> > Spaces in gemini URIs MUST be encoded as %20, not +.
>

+1  (not to be confused with " 1").  The usual use of x-www-form-urlencoded
format, as its name indicates, has to do with forms, which Gemini clients
don't do.  (Not that they couldn't in principle, to be sure.)




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
As you read this, I don't want you to feel sorry for me, because,
I believe everyone will die someday.
               --From a Nigerian-type scam spam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/58896fb8/attachment-0001.htm>

From lazar.michael22 at gmail.com  Fri Nov 27 05:06:27 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Fri, 27 Nov 2020 00:06:27 -0500
Subject: On certificates and validation
In-Reply-To: <CAD2gp_SYR-CnwW5STRffP=-2PMLTjE1kFwoXVVzC_109jVo-qw@mail.gmail.com>
References: <CAJScK0KXtGZSWbTLTA8GL4PCECvagxA60EHCu8GhWwOaQ=h89A@mail.gmail.com>
 <C7D7R32PHPGZ.A5AQXP8VGQGQ@taiga>
 <CAFTy05bA3fLjR5imUpn2X=g0vKR01nK7UWryVZc=+28GtBjeJw@mail.gmail.com>
 <CAD2gp_SYR-CnwW5STRffP=-2PMLTjE1kFwoXVVzC_109jVo-qw@mail.gmail.com>
Message-ID: <CAFTy05ah4XiwBDAfVFQL-ZvEuS0t7EVFyaukopjuhHoSH9T8MA@mail.gmail.com>

On Thu, Nov 26, 2020 at 7:04 PM John Cowan <cowan at ccil.org> wrote:
>
> On Thu, Nov 26, 2020 at 1:41 PM Michael Lazar <lazar.michael22 at gmail.com> wrote:
>
>> I fully agree that the expiration date is useless in TOFU schemes.
>
> However, they make all kinds of sense in client certs. If you see an expired
> cert coming from a client, it is most likely a replay attack (or a broken
> client). If the client cert is meant for user identification, you will of
> course need to provide the hash of the newly created cert to the server
> administrator.

I think you're referring to a compromised client certificate and not a replay
attack [0]. If you truly mean replay attack as in a MITM where neither the
client or server has been compromised, I would be *very* interested in learning
more about this because I thought the TLS handshake was resistant to this type
of replay.

On compromised client certificates: A compromised client certificate is in the
same boat that a compromised server certificate would be in. There is no
recourse within the TOFU model. You can rotate the cert, but the expiration
date doesn't protect you against anything. Sending new fingerprints to the
server administrator out-of-band would surely work, but you are no longer using
trust on first use.

You can argue that TOFU is a crappy model for client certificates since client
certs are typically used to grant access to verified identities. I would
mostly agree with that, although working on astrobotany has shown me that there
*are* at least some valid use cases for client TOFU schemes.

What this comes down to - *I think* - is that people are conflating trust on
first use with "anything but the web's root CAs". There are many valid
ways to establish trust, each with their own tradeoffs:

- PKI with a small number of universally recognized root CAs (the web)
- PKI with self-managed CAs
- Trust on first use
- Passing around certificate fingerprints over email
- ...

These can be mixed and matched between the server and client sides of the
connection, too.

- Michael

[0] https://en.wikipedia.org/wiki/Replay_attack

From krispin at posteo.de  Fri Nov 27 09:00:30 2020
From: krispin at posteo.de (Krispin Schulz)
Date: Fri, 27 Nov 2020 10:00:30 +0100
Subject: Translation service
In-Reply-To: <b4367dcced30b873a8c2a183607f9e92fe43be89.camel@ur.gs>
References: <b4367dcced30b873a8c2a183607f9e92fe43be89.camel@ur.gs>
Message-ID: <E8EBC6D6-7910-4276-9DB4-A076BD062347@posteo.de>

Hi Nick,

great work with the translation service!

I added it to https://github.com/kr1sp1n/awesome-gemini#services <https://github.com/kr1sp1n/awesome-gemini#services> and hope that much more services
will pop up in the foreseeable future.


@all: 	Does anyone know how to make links from gemini URLs in Markdown files so it will render in the browser?
	Is that even possible as long as the browser does not recognize the gemini schema?


Cheers,

Krispin

> On 27. Nov 2020, at 01:56, Nick Thomas <gemini at ur.gs> wrote:
> 
> Hola mis amigos!
> 
> I didn't find a capsule offering translation services in Geminispace,
> so I've put one together. It's linked from gemini://ur.gs, or you can
> construct a translation request URL manually, like so:
> 
> gemini://ur.gs/cgi-bin/translate/en/es?Hello%20world
> 
> Only en->es and es->en are supported right now; he estado aprendiendo
> espa?ol casi dos a?os ahora.
> 
> You can visit gemini://ur.gs/cgi-bin/translate to get a 10 prompt for
> translation.
> 
> It's using apertium, running on the same machine as the gemini server.
> If people like the service, I'll set up a babel.ur.gs or so somewhere,
> with more language pairs.
> 
> Improvements... well, visiting /translate could prompt for the source
> language, and /translate/en could prompt for the destination language.
> It could also, conceivably, take a URL to perform translation for.
> 
> Let me know what you think. I'm especially interested in translation
> quality and responsiveness - I only learned about apertium todaym and
> I've managed to get some pretty bad translations out of it so far :D.
> If you have suggestions for alternatives, I'm all ears, although
> apertium was pleasingly simple to set up. I might never visit deepl
> again!
> 
> Source code for the cgi-bin script is here:
> https://code.ur.gs/lupine/capsule/src/branch/main/src/cgi-bin/translate
> - it relies on the apertium and aperium-en-es packages being installed
> on the same machine, and on everything being UTF-8 throughout.
> 
> /Nick
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201127/f0c6e3cf/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201127/f0c6e3cf/attachment.sig>

From luke at marmaladefoo.com  Fri Nov 27 09:22:50 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 27 Nov 2020 09:22:50 +0000
Subject: Rendering html and markdown on Gemini (was Re: Translation service)
In-Reply-To: <E8EBC6D6-7910-4276-9DB4-A076BD062347@posteo.de>
References: <b4367dcced30b873a8c2a183607f9e92fe43be89.camel@ur.gs>
 <E8EBC6D6-7910-4276-9DB4-A076BD062347@posteo.de>
Message-ID: <5FC0C56A.1000204@marmaladefoo.com>


On 27-Nov-2020 09:00, Krispin Schulz wrote:
 >
 >
 > @all:  Does anyone know how to make links from gemini URLs in 
Markdown files so it will render in the browser?
 > Is that even possible as long as the browser does not recognize the 
gemini schema?
 >

For markdown or html files to work correctly, they would have to be 
rendered by the client. The default trick that most clients have to deal 
with unknown mime format is to open them in an external application. But 
that won't work properly - any relative path links won't work correctly.

There is a fair amount of html being served in gemini and the occasional 
bit of markdown too. GUS has some content type statistics here:

   gemini://gus.guru/statistics

There are a couple of clients that directly support these formats, but 
much less so compared to text/gemini which is supported by all. The ones 
I know of (there may well be others) are:

render text/html: Kristall, GemiNaut, Diohsc (via converter)
render text/markdown: Kristall

Client authors could plug in an converter into their pipeline if they 
wish, as a way to display such content in a client that only supports 
gemtext. There are converters you can use, such as md2gemini and 
html2gmi for that.

But I think for now, most clients will simply render text/html and 
text/markdown as plain text (not interpreted).

  - Luke

From linde.philip at gmail.com  Fri Nov 27 11:10:28 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 27 Nov 2020 12:10:28 +0100
Subject: On the use of %20 instead of + in URIs
In-Reply-To: <C7C2XO98PIDB.15J56R2JVFINO@nitro>
References: <C7C2XO98PIDB.15J56R2JVFINO@nitro>
Message-ID: <20201127121028.08ea8e9be54e3bc43fbc800e@gmail.com>

On Wed, 25 Nov 2020 00:02:35 -0500
"Adnan Maolood" <me at adnano.co> wrote:

> Section 1.2 of the Gemini specification says:
> 
> > Spaces in gemini URIs should be encoded as %20, not +.
> 
> I noticed that some servers do not properly handle +, treating it as a
> literal plus sign. Since this is a recommendation and not a must,
> shouldn't servers treat plus signs as spaces? Not allowing spaces makes
> it slightly more difficult to use URL parsing libraries which use plus
> signs.

"+" doesn't generally have a special meaning that implies synonymity
with spaces. The sentence you're referring to should be considered a
clarifying point (because it's an easy mistake to make I guess), not a
difference from the standard it adopts (RFC 3986)

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201127/e891b617/attachment.sig>

From tomasino at lavabit.com  Fri Nov 27 11:37:27 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 27 Nov 2020 11:37:27 +0000
Subject: On the use of %20 instead of + in URIs
In-Reply-To: <20201127121028.08ea8e9be54e3bc43fbc800e@gmail.com>
References: <C7C2XO98PIDB.15J56R2JVFINO@nitro>
 <20201127121028.08ea8e9be54e3bc43fbc800e@gmail.com>
Message-ID: <68acd192-c2f2-4cdc-8bee-0c5f182f1e2d@lavabit.com>

On 11/27/20 11:10 AM, Philip Linde wrote:
> "+" doesn't generally have a special meaning that implies synonymity
> with spaces. The sentence you're referring to should be considered a
> clarifying point (because it's an easy mistake to make I guess), not a
> difference from the standard it adopts (RFC 3986)

Philip is correct, but to add on, the '+' specifically has a semantic meaning as a space in query strings and form encodings (application/x-www-form-urlencoded) according to RFC 1866, but NOT in the rest of the URL itself. If you have a URL library that is parsing +'s as spaces in the URL outside of a query string, that library is incorrect. Only %20 is valid as a space in that context.

+ signs are listed as a sub-delimiter (RFC 3986 Section 2.2) and part of the reserved character set, meaning they should be encoded if not doing so would create confusion in the URL schema. Encoding a + sign would be %2B. You're welcome to do that if you want to avoid confusion, but it really shouldn't be necessary.


From nothien at uber.space  Fri Nov 27 15:44:52 2020
From: nothien at uber.space (Arav K.)
Date: Fri, 27 Nov 2020 16:44:52 +0100
Subject: Requiring schemes in Gemini requests
In-Reply-To: <C7CKYX7HRP06.3NQMEJTNAX9SF@stilgar>
References: <20201125025725.GK1721@brevard.conman.org>
 <C7CKYX7HRP06.3NQMEJTNAX9SF@stilgar>
Message-ID: <20201127154452.xks5aobc3b5cdvjp@gux>

> I think I'm happy with this, does anybody object?

No, this is a great idea.  It's also been confusing a lot of people
(iirc) about what is a valid URL without a scheme (e.g. //example.com)
so making it absolutely clearly is a win.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201127/97651335/attachment.sig>

From acdw at acdw.net  Fri Nov 27 15:50:47 2020
From: acdw at acdw.net (acdw (Case))
Date: Fri, 27 Nov 2020 09:50:47 -0600
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <bCwdC-hrWfqEcVPoqD49hlzWMkLLcADAvDoX5JUwRoaRQkpAsNktCrokUZSuuetIywY66qh6FqN2d9yZCs11Sp3u5KrUHi9C1rgKN9Tyk5I=@protonmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
 <bCwdC-hrWfqEcVPoqD49hlzWMkLLcADAvDoX5JUwRoaRQkpAsNktCrokUZSuuetIywY66qh6FqN2d9yZCs11Sp3u5KrUHi9C1rgKN9Tyk5I=@protonmail.com>
Message-ID: <800bcdd4-0b69-f046-943c-c69c2bf467c3@acdw.net>

On 11/26/20 1:06 AM, Krixano wrote:
>> However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent!
> 
> This makes absolutely no sense.
> What's the difference between regular letters and letters that have diacritics?

A phonemic distinction -- a diacritic'd letter vs. a plain letter can 
differentiate words.  The same is not true of italics, which are 
typographic in nature.

> What's the difference between capitals and lowercase? 

This point is more warranted, I think.  After all, a lot of scripts 
don't differentiate between capitals and minuscules at all, and in fact 
the Roman alphabet didn't have it for much of its history.

However, the distinction is already "supported" in ASCII/UTF, which is 
why I suggested its use in lieu of the poorly-supported italic 
convention.  Use the tools we have, and all that.

> What about Hebrew
> Vowels? Are all those "metadata" also?

I don't know enough about Hebrew to comment, but I would think it'd fall 
under my previous paragraph.

> Italics conveys data itself.
> Italics is part of the writing system. It's not "metadata"
> It's literally no different from using punctuation, or capitals.

The thing is -- if we were to include italics in the spec for 
text/gemini, it'd be set off *using* punctuation, a la Markdown or 
BBText or even HTML.  So why not just use that naked punctuation?  I 
think it's just as easy to understand that *this* is italic as if it 
were actually *in* italics.

-- 
~acdw (Case)
www.acdw.net | breadpunk.club/~breadw

From me at adnano.co  Fri Nov 27 16:20:31 2020
From: me at adnano.co (Adnan Maolood)
Date: Fri, 27 Nov 2020 11:20:31 -0500
Subject: On the use of %20 instead of + in URIs
In-Reply-To: <68acd192-c2f2-4cdc-8bee-0c5f182f1e2d@lavabit.com>
Message-ID: <C7E6LTVIEYQD.1U6TTI8XYMW1G@nitro>

On Fri Nov 27, 2020 at 6:37 AM EST, James Tomasino wrote:
> On 11/27/20 11:10 AM, Philip Linde wrote:
> > "+" doesn't generally have a special meaning that implies synonymity
> > with spaces. The sentence you're referring to should be considered a
> > clarifying point (because it's an easy mistake to make I guess), not a
> > difference from the standard it adopts (RFC 3986)
>
> Philip is correct, but to add on, the '+' specifically has a semantic
> meaning as a space in query strings and form encodings
> (application/x-www-form-urlencoded) according to RFC 1866, but NOT in
> the rest of the URL itself. If you have a URL library that is parsing
> +'s as spaces in the URL outside of a query string, that library is
> incorrect. Only %20 is valid as a space in that context.
>
> + signs are listed as a sub-delimiter (RFC 3986 Section 2.2) and part of
> the reserved character set, meaning they should be encoded if not doing
> so would create confusion in the URL schema. Encoding a + sign would be
> %2B. You're welcome to do that if you want to avoid confusion, but it
> really shouldn't be necessary.

The Go URL library encodes spaces in the query string as '+'. Is this
correct behavior?

From cowan at ccil.org  Fri Nov 27 16:33:10 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 27 Nov 2020 11:33:10 -0500
Subject: Rendering html and markdown on Gemini (was Re: Translation
 service)
In-Reply-To: <5FC0C56A.1000204@marmaladefoo.com>
References: <b4367dcced30b873a8c2a183607f9e92fe43be89.camel@ur.gs>
 <E8EBC6D6-7910-4276-9DB4-A076BD062347@posteo.de>
 <5FC0C56A.1000204@marmaladefoo.com>
Message-ID: <CAD2gp_Qdsx0uV4qCL5hUZ8azNNMbst0BL+fz1R20vmcb-7BimQ@mail.gmail.com>

On Fri, Nov 27, 2020 at 4:23 AM Luke Emmet <luke at marmaladefoo.com> wrote:


> For markdown or html files to work correctly, they would have to be
> rendered by the client.


Another approach is for clients to allow a Gemini-Gemini proxy, and then
write one that does whatever translations you want.  Since many clients
support proxies for HTML on HTTP, it shouldn't be that hard to add this
support, or to modify an HTTP proxy to speak Gemini instead.  I would
expect that these would normally be private proxies, as they need to share
the current cert with the client to avoid what looks like a MITM attack.

The default trick that most clients have to deal
> with unknown mime format is to open them in an external application. But
> that won't work properly - any relative path links won't work correctly.
>

Well, most formats other than HTML and Markdown don't have hyperlinks,
though I admit they are the most pressing cases.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its
population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201127/8ca66847/attachment.htm>

From text at sdfeu.org  Fri Nov 27 17:27:39 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Fri, 27 Nov 2020 18:27:39 +0100
Subject: Serious writing (in the Latin script) needs italics
In-Reply-To: <CAObwWNisf9QA7SyAxELHRcBK+MctAmkeonJ8BCATvqenz8XWjw@mail.gmail.com>
References: <C6Z00Q23YBCO.2QNUHJZTH4LEL@m900382.inf.susx.ac.uk>
 <20201109222047.054ab7fc74544ed8fee961df@gmail.com>
 <c756b3f1-36a4-0fff-a198-8e2cb4dba941@lavabit.com>
 <20201110004611.bf0d32664936eb1db997d2ff@gmail.com>
 <CAD2gp_RMmzwFe1Ks16baXykZ_9CRjrcB+RHP==6ZwQXrus31LQ@mail.gmail.com>
 <bCwdC-hrWfqEcVPoqD49hlzWMkLLcADAvDoX5JUwRoaRQkpAsNktCrokUZSuuetIywY66qh6FqN2d9yZCs11Sp3u5KrUHi9C1rgKN9Tyk5I=@protonmail.com>
 <Ue0YLojaEA74m46D0lKTuwKWuIPRc-crszF5u7DmSdEFC2Ixo-PpWE8TZ4zCN_AQU1SrvVCaZJ6cSUYTVZLzn2C2QYz0AZZgkJOJ21Cmay4=@protonmail.com>
 <CAObwWNisf9QA7SyAxELHRcBK+MctAmkeonJ8BCATvqenz8XWjw@mail.gmail.com>
Message-ID: <98cc254e7c29e36935365ba39f4d71ee@sdfeu.org>

On 2020-11-26 13:19, Katarina Eriksson wrote:
> Gemtext is limited similarly to typewriters in that they don't
> typically support italics. How did they express emphasis on
> typewriters? On the other hand, the output of typewriters wasn't meant
> to be accessible to screen readers.
> 
> I have already listed a bunch of different ways to convey the same
> thing as you would with italics and their drawbacks.

This Nov 10 post contains a fine list, mentioning capitalization, 
all-uppercase, letter-spacing, extra space/newline around word/sentence 
? similar ideas as listed in Wikipedia on methods of typographic 
emphasis:
https://en.wikipedia.org/wiki/Emphasis_(typography)#Methods_and_use

I wouldn't mind clients opting for a distinctive rendering like e. g. 
Thunderbird's so-called Structured Text in plain text e-mail, which 
suggests *bold* and /italic/ and _underlined_ text ? optionally 
(mail.display_struct, default:true) rendered bold/italic/underlined, but 
without deleting any chars as I experience it. Jargon File "Hacker 
Writing Style" is mentionend following a ref there:

http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29#Structured_Text
http://kb.mozillazine.org/Mail_and_news_settings ? mail.display_struct


From tomasino at lavabit.com  Fri Nov 27 17:53:36 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Fri, 27 Nov 2020 17:53:36 +0000
Subject: On the use of %20 instead of + in URIs
In-Reply-To: <C7E6LTVIEYQD.1U6TTI8XYMW1G@nitro>
References: <C7E6LTVIEYQD.1U6TTI8XYMW1G@nitro>
Message-ID: <0b696f2a-21ac-4c24-6efa-8dbe7353ef2b@lavabit.com>

On 11/27/20 4:20 PM, Adnan Maolood wrote:
> The Go URL library encodes spaces in the query string as '+'. Is this
> correct behavior?

It's correct, but be careful:

- x-www-form-urlencoded *should* use +
- query string *may* use either + or %20 (%20 is notable in mailto link subject values)
- remainder of URL *must* use %20

That last bit is the important one for this discussion. Any spaces before the ? must be %20.


From colecmac at protonmail.com  Fri Nov 27 18:30:43 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 27 Nov 2020 18:30:43 +0000
Subject: On the use of %20 instead of + in URIs
In-Reply-To: <C7E6LTVIEYQD.1U6TTI8XYMW1G@nitro>
References: <C7E6LTVIEYQD.1U6TTI8XYMW1G@nitro>
Message-ID: <K6YpSVb5toEFiEwzxAX3i4cq0rg4CfFZkCQ4uSAL0tT7UX6L5A32sJNiwNDENt_Il2jf-JJL7WLQu-nlte2T0QoI0GWmI_8m0XmuLyqnqF0=@protonmail.com>

(My initial email only went to Adnan, sorry.)


> The Go URL library encodes spaces in the query string as '+'. Is this
> correct behavior?

Not for Gemini, no. According to RFCs it is okay, I believe. Whether or
not this should be changed, here's how my go-gemini library handles it.
These funcs should be used in place of the "net/url" ones.


func QueryEscape(query string) string {
    return strings.ReplaceAll(url.PathEscape(query), "+", "%2B")
}


func QueryUnescape(query string) (string, error) {
    return url.PathUnescape(query)
}



I hope that's helpful.


makeworld

From sean at conman.org  Sat Nov 28 04:49:46 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 27 Nov 2020 23:49:46 -0500
Subject: Requiring schemes in Gemini requests
In-Reply-To: <20201127154452.xks5aobc3b5cdvjp@gux>
References: <20201125025725.GK1721@brevard.conman.org>
 <C7CKYX7HRP06.3NQMEJTNAX9SF@stilgar> <20201127154452.xks5aobc3b5cdvjp@gux>
Message-ID: <20201128044946.GU1721@brevard.conman.org>

It was thus said that the Great Arav K. once stated:
> > I think I'm happy with this, does anybody object?
> 
> No, this is a great idea.  It's also been confusing a lot of people
> (iirc) about what is a valid URL without a scheme (e.g. //example.com)
> so making it absolutely clearly is a win.

  I've gone ahead and removed the schemeless support from GLV-1.12556 in the
hopes this pushes other people to do the same, and get Solderpunk to update
the specification.

  -spc


From khuxkm at tilde.team  Sat Nov 28 10:49:22 2020
From: khuxkm at tilde.team (khuxkm at tilde.team)
Date: Sat, 28 Nov 2020 10:49:22 +0000
Subject: [ANN] Stream of Consciousness - a fancy twtxt frontend in Gemini
Message-ID: <57634abfe146a3e4bf192a19f214de36@tilde.team>

I wrote a couple Python scripts to create a twtxt feed I could post to from Gemini! I'm currently using it for a place to dump thoughts as they come, if I can open up amfora and get them out. My instance is:

gemini://tilde.team/~khuxkm/consciousness/

And the code can be found at:

From khuxkm at tilde.team  Sat Nov 28 10:52:48 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Sat, 28 Nov 2020 10:52:48 +0000
Subject: [ANN] Stream of Consciousness - fancy single-user twtxt frontend
 in gemini
Message-ID: <1b096589b1bbce52a62c6c95e3936865@tilde.team>

I wrote a few Python scripts to create a twtxt frontend to allow me to write twtxt posts from Gemini! I'm currently using it as a place to dump thoughts, if I can get Amfora open and get them out. My instance is available at:

gemini://tilde.team/~khuxkm/consciousness/

And the code is available at:

https://github.com/MineRobber9000/stream-of-consciousness

Just my ~~two cents~~ three scripts,
Robert "khuxkm" Miles

From khuxkm at tilde.team  Sat Nov 28 10:53:08 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Sat, 28 Nov 2020 10:53:08 +0000
Subject: [ANN] Stream of Consciousness - a fancy twtxt frontend in Gemini
In-Reply-To: <57634abfe146a3e4bf192a19f214de36@tilde.team>
References: <57634abfe146a3e4bf192a19f214de36@tilde.team>
Message-ID: <b4a131ae0eafc0097e5c7973130d7622@tilde.team>

Disregard this post, my client sent the post early.

Just my two cents,
Robert "khuxkm" Miles

November 28, 2020 5:49 AM, khuxkm at tilde.team wrote:

> I wrote a couple Python scripts to create a twtxt feed I could post to from Gemini! I'm currently
> using it for a place to dump thoughts as they come, if I can open up amfora and get them out. My
> instance is:
> 
> gemini://tilde.team/~khuxkm/consciousness/
> 
> And the code can be found at:

From emilis at emilis.net  Sat Nov 28 14:28:37 2020
From: emilis at emilis.net (Emilis)
Date: Sat, 28 Nov 2020 16:28:37 +0200
Subject: Does TOFU actually work?
Message-ID: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>

Hi,

I wanted to set up my own Gemini server today. I think I got 
MITM-attacked by China.

This highlights the question I wanted to ask for some time: can't TOFU 
be easily MITM-ed by state actors?

Is it actually any better than CA certificates or does it only replace 
trust in CAs with trust in all ISPs and hardware in between the server 
and the client?

How would TOFU work for someone out of a country that firewalls the 
internet and can replace all self-signed certificates for port 1965 on 
the fly?

If TOFU fails in this scenario (which is common for hundreds of millions 
of people today) can we really say that Gemini protects privacy?


Details:

I am in Vilnius, Lithuania. My IP is in this range:

```
inetnum:??????? 78.59.128.0 - 78.59.255.255
netname:??????? Telia-Lietuva
descr:????????? Telia Lietuva, AB
country:??????? LT
```

I got a VPS with Debian 9 in the same city. It's current hostname is 
naujenai.lt and IP is in this range:

```
inetnum:??????? 94.176.232.0 - 94.176.239.255
netname:??????? LT-LITHUANIA-20080814
country:??????? LT
```

I downloaded, compiled and installed https://git.sr.ht/~sircmpwn/gmnisrv 
on the VPS.

Commit:

```
gmnisrv$ git log
commit cb2c84b0ad9aadd4c92d8ef978c2bfca578cd3c4
Author: Mark Dain <mark at markdain.net>
Date:?? Sat Nov 21 13:56:37 2020 +0000
```

I use a locally built https://github.com/skyjake/lagrange to browse 
gemini://

Commit:

```
commit ca89eeab5c89107f675bd4d8de97ede364d8d902 (HEAD -> release, tag: 
v0.10.0, origin/release)
Merge: 6e1e7d0 b9f7a12
Author: Jaakko Ker?nen <jaakko.keranen at iki.fi>
Date:?? Sat Nov 21 22:25:57 2020 +0200
```

I opened my new server URL in Lagrange. Then tried a non-existing URL (I 
was trying to configure URL rewriting for gmnisrv).

I got this in my gmnisrv console:

```
$ gmnisrv
[gmnisrv] generating certificate for naujenai.lt
[gmnisrv] generating certificate for localhost
[gmnisrv] listening on [::]:1965
[gmnisrv] listening on 0.0.0.0:1965
[gmnisrv] gmnisrv started
36.130.78.59 naujenai.lt /? 57ms??? 39 20 text/gemini
154.170.78.59 naujenai.lt /test.gmi? 67ms???? 0 51 Not found
^C[gmnisrv] gmnisrv terminating
```

```
$ gmnisrv
[gmnisrv] loaded certificate for naujenai.lt
[gmnisrv] loaded certificate for localhost
[gmnisrv] listening on [::]:1965
[gmnisrv] listening on 0.0.0.0:1965
[gmnisrv] gmnisrv started
39.92.78.59 naujenai.lt /? 58ms??? 39 20 text/gemini
143.238.78.59 naujenai.lt /asdf.gmi? 66ms???? 0 51 Not found
```

Whois queries for the IPs in the gmnisrv log:

```
$ whois 36.130.78.59
...
inetnum:??????? 36.128.0.0 - 36.191.255.255
netname:??????? CMNET
descr:????????? China Mobile Communications Corporation
descr:????????? Mobile Communications Network Operator in China
descr:????????? Internet Service Provider in China
country:??????? CN
```

```
$ whois 39.92.78.59
...
inetnum:??????? 39.64.0.0 - 39.95.255.255
netname:??????? UNICOM-SD
descr:????????? China Unicom Shandong province network
descr:????????? China Unicom
country:??????? CN
```

```
$ whois 143.238.78.59
...
NetRange:?????? 143.238.0.0 - 143.238.255.255
CIDR:?????????? 143.238.0.0/16
NetName:??????? APNIC-ERX-143-238-0-0
NetHandle:????? NET-143-238-0-0-1
Parent:???????? NET143 (NET-143-0-0-0-0)
NetType:??????? Early Registrations, Transferred to APNIC
OriginAS:
Organization:?? Asia Pacific Network Information Centre (APNIC)
...
Country:??????? AU
```

```
$ whois 154.170.78.59
...
inetnum:??????? 154.160.0.0 - 154.175.255.255
netname:??????? GH-SPACEFON
descr:????????? Scancom Ltd.
country:??????? GH
```

Note that IP addresses change between requests from the same browser to 
the same server.


I suspect my Huawei 4G router. I bought it locally a few years ago when 
very few options were available. I was planning to replace it for some time.


--
Emilis Dambauskas
gemini://tilde.team/~emilis/


From gemini at benburwell.com  Sat Nov 28 15:14:34 2020
From: gemini at benburwell.com (Ben Burwell)
Date: Sat, 28 Nov 2020 10:14:34 -0500
Subject: Does TOFU actually work?
In-Reply-To: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
Message-ID: <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>

On 2020-11-28 at 09:28 -05:00, Emilis <emilis at emilis.net> wrote:
> can't TOFU be easily MITM-ed by state actors?
>
> Is it actually any better than CA certificates or does it only replace 
> trust in CAs with trust in all ISPs and hardware in between the server 
> and the client?

TOFU could be MITM'd. It replaces the CA mechanism by the assumption
that the first time you connect to a host, you get the right key/cert,
and will ensure that any subsequent connection uses the same key pair.

So if the first connection is MITM'd, your client will accept the phony
cert but all subsequent connections will need to be MITM'd with the
same phony cert in order to keep you client quiet.

If the first connection is NOT MITM'd, then any subsequent MITM attempt
would then raise alarm bells.

> How would TOFU work for someone out of a country that firewalls the 
> internet and can replace all self-signed certificates for port 1965 on 
> the fly?
> 
> If TOFU fails in this scenario (which is common for hundreds of millions 
> of people today) can we really say that Gemini protects privacy?

You're right - it wouldn't protect the privacy of people under that
scenario (assuming the state actor is sufficiently motivated to do this
interception/replacement under TOFU constraints).

I'm not sure what a good solution to this is.

> Note that IP addresses change between requests from the same browser to 
> the same server.

Those logs do look a little funky, but luckily we don't need to rely on
IP addresses to check your hypothesis: all you need to do is match the
fingerprint/hash of the cert being presented by Lagrange with the hash
of the cert generated on your server. If they don't match, then you have
definitively been MITM'd.

From marcx2 at welz.org.za  Sat Nov 28 15:23:44 2020
From: marcx2 at welz.org.za (marc)
Date: Sat, 28 Nov 2020 16:23:44 +0100
Subject: Does TOFU actually work?
In-Reply-To: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
Message-ID: <20201128152344.GA30577@localhost.localdomain>

> Hi,

Hello

> I wanted to set up my own Gemini server today. I think I got MITM-attacked
> by China.

snip

> I am in Vilnius, Lithuania. My IP is in this range:
> inetnum:?????????????? 78.59.128.0 - 78.59.255.255

snip

> 36.130.78.59 naujenai.lt /?? 57ms?????? 39 20 text/gemini
> 154.170.78.59 naujenai.lt /test.gmi?? 67ms???????? 0 51 Not found

So we can't blame the PRC on this. It is a bug in
gmnisrv. I mailed Drew the following in September, but
it seems my fix got ignored. I suppose it only affects 
certain architectures, and only ipv4. What is happening
is that the address decoding routine input is shifted 
by 2bytes, hence your 78.59 appears in the wrong place, and 
the first two bytes are bogus. 

Your general point about TOFU/MITM still stands though. 
We can reduce the risk by not expiring keys, and by
maybe showing fingerprints in the browser, in 
various caches and maybe even in the links occasionally.

> I noticed on some platforms the logging logic for the
> server (log.c:23) uses addr->sa_data which is not aligned,
> as the short is only 2 bytes long, and the char[] happens
> immediately after that:
> 
>     eg addr=0xb6e01014, fam=0xb6e01014, data=0xb6e01016
> 
> and so doesn't map directly on to the address structure.
> I solved this with a horrible
> 
>     const char *addrs = inet_ntop(addr->sa_family, (void *)&(((struct sockaddr_in *)addr)->sin_addr), abuf, sizeof(abuf));

For completeness, the proper fix would involve doing a 
switch on sa_family, and grabbing the proper location 
on a per address family basis - things that a type safe
language would have insisted on, but which C (a very
sharp tool requires sharp users) allows us to bypass.

regards

marc

PS: Comments from the peanut gallery advocating for a 
newer language are of course wrong. C is still the better 
choice ;-) I suspect Emilis test system doesn't have enough
RAM to be even supported by some shinier runtimes, nevermind
the CPU architecture...

-- CC-SA

From emilis at emilis.net  Sat Nov 28 16:39:58 2020
From: emilis at emilis.net (Emilis)
Date: Sat, 28 Nov 2020 18:39:58 +0200
Subject: Does TOFU actually work?
In-Reply-To: <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
 <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
Message-ID: <0b972395-3995-f617-e107-4effd6254763@emilis.net>

On 11/28/20 5:14 PM, Ben Burwell wrote:
> Those logs do look a little funky, but luckily we don't need to rely on
> IP addresses to check your hypothesis: all you need to do is match the
> fingerprint/hash of the cert being presented by Lagrange with the hash
> of the cert generated on your server. If they don't match, then you have
> definitively been MITM'd.

I can't match the server certificate to it's browser fingerprint.

I am not sure I am using the correct methods.

My Lagrange `.config/lagrange/trusted.txt` has this line:

```
naujenai.lt 1638096010 
95c34bf23ad26f64627138875ce2b251048fcfea9be905a7c9915325fb0e3546

```

I attached my `naujenai.lt.crt` which was generated by gmnisrv.


I ran these commands on the certificate file:

```
$ openssl x509 -in naujenai.lt.crt -noout -fingerprint -sha256
SHA256 
Fingerprint=83:D8:96:B8:83:2B:D7:04:A2:E1:36:78:15:4B:1D:4F:30:A1:13:22:79:57:AD:68:A8:70:2B:49:9F:1D:D0:65
```

```
$ openssl x509 -in naujenai.lt.crt -outform DER -out naujenai.lt.der
$ sha256sum naujenai.lt.der
83d896b8832bd704a2e13678154b1d4f30a113227957ad68a8702b499f1dd065 
naujenai.lt.der
```

Lagrange seems to be using sha256 fingerprints, but I am not a C 
developer so I can't be sure:
https://git.skyjake.fi/skyjake/the_Foundation/src/branch/master/src/tlsrequest.c#L310

--
Emilis Dambauskas
gemini://tilde.team/~emilis/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: naujenai.lt.crt
Type: application/pkix-cert
Size: 574 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/c0186d84/attachment.cer>

From emilis at emilis.net  Sat Nov 28 17:19:45 2020
From: emilis at emilis.net (Emilis)
Date: Sat, 28 Nov 2020 19:19:45 +0200
Subject: Does TOFU actually work?
In-Reply-To: <0b972395-3995-f617-e107-4effd6254763@emilis.net>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
 <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
 <0b972395-3995-f617-e107-4effd6254763@emilis.net>
Message-ID: <ff85e340-abc1-7410-c6c1-8f99d5612667@emilis.net>

Sorry,

I found another certificate on my VPS which matches the fingerprint used 
by Lagrange browser.

So I think I can confirm, that I was NOT MITM-ed and it must be the bug 
in gmnisrv.


I had two sets of certificates, because I ran gmnisrv with a changed 
configuration. I had attached the other, matching certificate for the 
curious.

```
$ openssl x509 -noout -fingerprint -sha256 -in naujenai-2.lt.crt
SHA256 
Fingerprint=95:C3:4B:F2:3A:D2:6F:64:62:71:38:87:5C:E2:B2:51:04:8F:CF:EA:9B:E9:05:A7:C9:91:53:25:FB:0E:35:46
```


On 11/28/20 6:39 PM, Emilis wrote:
> On 11/28/20 5:14 PM, Ben Burwell wrote:
>> Those logs do look a little funky, but luckily we don't need to rely on
>> IP addresses to check your hypothesis: all you need to do is match the
>> fingerprint/hash of the cert being presented by Lagrange with the hash
>> of the cert generated on your server. If they don't match, then you have
>> definitively been MITM'd.
>
> I can't match the server certificate to it's browser fingerprint.
>
> I am not sure I am using the correct methods.
>
> My Lagrange `.config/lagrange/trusted.txt` has this line:
>
> ```
> naujenai.lt 1638096010 
> 95c34bf23ad26f64627138875ce2b251048fcfea9be905a7c9915325fb0e3546
>
> ```
>
> I attached my `naujenai.lt.crt` which was generated by gmnisrv.
>
>
> I ran these commands on the certificate file:
>
> ```
> $ openssl x509 -in naujenai.lt.crt -noout -fingerprint -sha256
> SHA256 
> Fingerprint=83:D8:96:B8:83:2B:D7:04:A2:E1:36:78:15:4B:1D:4F:30:A1:13:22:79:57:AD:68:A8:70:2B:49:9F:1D:D0:65
> ```
>
> ```
> $ openssl x509 -in naujenai.lt.crt -outform DER -out naujenai.lt.der
> $ sha256sum naujenai.lt.der
> 83d896b8832bd704a2e13678154b1d4f30a113227957ad68a8702b499f1dd065 
> naujenai.lt.der
> ```
>
> Lagrange seems to be using sha256 fingerprints, but I am not a C 
> developer so I can't be sure:
> https://git.skyjake.fi/skyjake/the_Foundation/src/branch/master/src/tlsrequest.c#L310 
>
>
> -- 
> Emilis Dambauskas
> gemini://tilde.team/~emilis/
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: naujenai-2.lt.crt
Type: application/pkix-cert
Size: 574 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/20eb072c/attachment.cer>

From emilis at emilis.net  Sat Nov 28 18:13:02 2020
From: emilis at emilis.net (Emilis)
Date: Sat, 28 Nov 2020 20:13:02 +0200
Subject: Does TOFU actually work?
In-Reply-To: <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
 <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
Message-ID: <1da74435-3703-d0d5-b62a-3b79bc61e7f8@emilis.net>

It seems there also is an issue with my browser's UI: the warning color 
on the security icon matched the primary color of the built-in theme I 
am using:

https://github.com/skyjake/lagrange/issues/72#issuecomment-735268218

I didn't notice that Lagrange was actually warning me about the changed 
certificate.


Gemini spec says (4.2):

 > If the certificate is not the one previously received, but the 
previous certificate's expiry date has not passed, the user is shown a 
warning, analogous to the one web browser users are shown when receiving 
a certificate without a signature chain leading to a trusted CA.

I think we would all benefit if someone went through the known browsers, 
checked how they implement this and published the results.

--
Emilis Dambauskas
gemini://tilde.team/~emilis/


From me at adnano.co  Sat Nov 28 18:07:45 2020
From: me at adnano.co (Adnan Maolood)
Date: Sat, 28 Nov 2020 13:07:45 -0500
Subject: Standard fingerprint format for TLS certificates
Message-ID: <C7F3IGYQ6EHX.2GCVWGGX99UEI@nitro>

Gemini software is currently fragmented with regards to certificate
fingerprints. It would be nice if there was an agreed upon way to
calculate fingerprints so that users can easily compare fingerprints
across different software.

Here are some potential fingerprint methods.

- Sha512 hash of the certificate, encoded in hex with ':' between each
  octet.
  Pros: matches the output of openssl x509 -sha512 -fingerprint
  Cons: the resulting fingerprint is very long
- Sha512 hash of the certificate, encoded in base64.
  Pros: easy to encode and decode
  Cons: still somewhat long
- Sha256 hash of the certificate, encoded in base64.
  Pros: shorter than the Sha512 hash
  Cons: less secure than Sha512?

Note that this is the hash of the entire certificate, not just the
public key.

I think we should choose a fingerprint method and stick with it for
consistency.

From ben at bendb.com  Sat Nov 28 21:28:53 2020
From: ben at bendb.com (Ben Bader)
Date: Sat, 28 Nov 2020 14:28:53 -0700
Subject: Standard fingerprint format for TLS certificates
In-Reply-To: <C7F3IGYQ6EHX.2GCVWGGX99UEI@nitro>
References: <C7F3IGYQ6EHX.2GCVWGGX99UEI@nitro>
Message-ID: <CADkMQxXS_i64cxNP7aRXY2dqq=LPpSVKrYPb5xkS_mYQcVWoXg@mail.gmail.com>

> Gemini software is currently fragmented with regards to certificate
fingerprints. It would be nice if there was an agreed upon way to
calculate fingerprints so that users can easily compare fingerprints
across different software.

What?s the use case for comparing fingerprints themselves?  I may be
missing something important, but I don't understand the need.

In my opinion, certificates themselves are the lingua franca and
fingerprints are merely a client implementation detail.  Unless we are
considering standardizing a known-hosts file format, I would prefer leaving
fingerprint formats to the discretion of client implementations.

There?s nothing stopping anyone today from using OpenSSL to compute
fingerprints using any algorithm one could wish, if comparisons are desired.

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/b11221b3/attachment.htm>

From me at adnano.co  Sat Nov 28 21:57:43 2020
From: me at adnano.co (Adnan Maolood)
Date: Sat, 28 Nov 2020 16:57:43 -0500
Subject: Standard fingerprint format for TLS certificates
In-Reply-To: <CY4PR14MB1141E145534D906625BAE213A0F70@CY4PR14MB1141.namprd14.prod.outlook.com>
Message-ID: <C7F8EJYM0R10.20F3S0NUGRT0U@nitro>

On Sat Nov 28, 2020 at 2:43 PM EST, Ben Bader wrote:
> What?s the use case for comparing fingerprints themselves? I may be
> missing something important.

Fingerprints are used to compare certificates. Instead of comparing the
certificates directly, you would essentially be comparing their hashes.
Fingerprints are also useful as a unique identifier for a certificate.

Let's say I use a tool to create a client certificate, and it tells me
the certificate fingerprint. I should then be able to configure my
server software to allow the certificate with this fingerprint. This 
would only work if the fingerprint format is the same across software.

> In my opinion, certificates themselves are the lingua franca and
> fingerprints are merely a client implementation detail. Unless we are
> considering standardizing a known-hosts file format, I would prefer
> leaving fingerprint formats to the discretion of client implementations.

To clarify, I don't think this should be added to the Gemini
specification, but rather it should be an informal specification or best
practice that can be listed on the project website.

From khuxkm at tilde.team  Sat Nov 28 23:08:47 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Sat, 28 Nov 2020 23:08:47 +0000
Subject: Standard fingerprint format for TLS certificates
In-Reply-To: <C7F3IGYQ6EHX.2GCVWGGX99UEI@nitro>
References: <C7F3IGYQ6EHX.2GCVWGGX99UEI@nitro>
Message-ID: <ad1a13561a7c2de9c8d4151dcce9d5ca@tilde.team>

November 28, 2020 1:07 PM, "Adnan Maolood" <me at adnano.co> wrote:

> Gemini software is currently fragmented with regards to certificate
> fingerprints. It would be nice if there was an agreed upon way to
> calculate fingerprints so that users can easily compare fingerprints
> across different software.
> 
> Here are some potential fingerprint methods.
> 
> - Sha512 hash of the certificate, encoded in hex with ':' between each
> octet.
> Pros: matches the output of openssl x509 -sha512 -fingerprint
> Cons: the resulting fingerprint is very long
> - Sha512 hash of the certificate, encoded in base64.
> Pros: easy to encode and decode
> Cons: still somewhat long
> - Sha256 hash of the certificate, encoded in base64.
> Pros: shorter than the Sha512 hash
> Cons: less secure than Sha512?
> 
> Note that this is the hash of the entire certificate, not just the
> public key.
> 
> I think we should choose a fingerprint method and stick with it for
> consistency.

The one I prefer is `HASH_METHOD:HASH`, where `HASH_METHOD` is the method of the hash (like
`SHA256` or `SHA512`) and `HASH` is the fingerprint with that hash method (without any `:`
separators).

Just my two cents,
Robert "khuxkm" Miles

From cowan at ccil.org  Sat Nov 28 23:18:24 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 28 Nov 2020 18:18:24 -0500
Subject: Standard fingerprint format for TLS certificates
In-Reply-To: <C7F3IGYQ6EHX.2GCVWGGX99UEI@nitro>
References: <C7F3IGYQ6EHX.2GCVWGGX99UEI@nitro>
Message-ID: <CAD2gp_SiocjuhLSjida9ZtyopQpWm0U05gZq8TbaSD8VDZUa5g@mail.gmail.com>

On Sat, Nov 28, 2020 at 1:23 PM Adnan Maolood <me at adnano.co> wrote:


>   Cons: still somewhat long
> - Sha256 hash of the certificate, encoded in base64.
>   Pros: shorter than the Sha512 hash
>   Cons: less secure than Sha512?
>

IMO (and I am no expert, but I have taken expert advice), the *relative*
security weakness of SHA-256 over SHA-512 matters only if practical quantum
computing is developed during the life of the cert.  And all security is
relative: if you want to *secure* a computer, you should disconnect all
wires from it, drop it down a deep well, and fill the well with concrete.

The CLI program sha256sum produces a SHA-256 of an arbitrary file.

I think we should choose a fingerprint method and stick with it for
> consistency.
>

100% agreement.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
        Is it not written, "That which is written, is written"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/d2c55127/attachment.htm>

From caolan at caolan.uk  Sun Nov 29 08:47:01 2020
From: caolan at caolan.uk (Caolan McMahon)
Date: Sun, 29 Nov 2020 08:47:01 +0000
Subject: Appetite for Gemini users mailing list?
Message-ID: <AEC55E80-C782-4947-894A-1D8528A6A64B@caolan.uk>

I've been lurking here for a while but I'm less interested in bike shedding the spec and mostly just want to see what people can build with Gemini today.

I've noticed new capsule announcements on here are sometimes tentative - people (myself included) are not sure if it's on-topic, I think.

I'd like either another mailing list or a subject tag to highlight new capsules, software releases, and novel uses for the spec as it stands. There should be an accompanying statement that explicitly allows these announcements.

That doesn't mean discussion of the spec should stop. I'm just wading through a lot of it to find what *I* want right now and maybe we can welcome new users better if we organised things differently.

From stephane at sources.org  Sun Nov 29 13:47:32 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 29 Nov 2020 14:47:32 +0100
Subject: RFC for languages and/or discussion about the specification
Message-ID: <20201129134732.GA5870@sources.org>

Hello,

[Warning, beginner]

I've noticed in
<https://gemini.circumlunar.space/docs/specification.html> the text
"Valid values for the lang parameter are comma-separated lists of one
or more language tags as defined in RFC4646". RFC 4646 has been
replaced eleven years ago. I suggest to change the specification and,
instead of using the actual RFC number, use the "BCP" reference which
is stable. "BCP 47" pointed to RFC 4646 before and now to the current
one, 5646.

But may be this is not the best place to talk about the specification?


From rwagner at rw-net.de  Sun Nov 29 14:08:16 2020
From: rwagner at rw-net.de (=?UTF-8?Q?Ren=C3=A9=20Wagner?=)
Date: Sun, 29 Nov 2020 15:08:16 +0100 (CET)
Subject: [ANN] orrg: rss/atom feed renderer for gemini
Message-ID: <20201129140816.0A69063C02BF@dd22736.kasserver.com>

Hi,

I'm still really excited about gemini and it's community and was eager to try out a few things. 
As a long time perl dude I started hacking a few cgi scripts, one of them i'd like to introduce now: 
orrg

orrg is a script that renders rss/atom feeds fetched over gemini or https as gemtext pages. 
It also includes a list of recently visited and most popular feeds on a particular instance.

My public instance is running at gemini://orrg.clttr.info

further ressources:

source: https://git.sr.ht/~rwa/orrg
mailing list: https://lists.sr.ht/~rwa/gmni-perl-cgi

Feedback welcome.

kind regards
Ren?

From gmym at coopdot.com  Sun Nov 29 14:46:23 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sun, 29 Nov 2020 15:46:23 +0100
Subject: RFC for languages and/or discussion about the specification
In-Reply-To: <20201129134732.GA5870@sources.org>
References: <20201129134732.GA5870@sources.org>
Message-ID: <CAObwWNj3_mNzr=5JM2TYxeGtcafdQEMvnfMPrkgk-nL5VcNnPg@mail.gmail.com>

Stephane Bortzmeyer <stephane at sources.org> wrote:

> I've noticed in
> <https://gemini.circumlunar.space/docs/specification.html> the text
> "Valid values for the lang parameter are comma-separated lists of one
> or more language tags as defined in RFC4646". RFC 4646 has been
> replaced eleven years ago. I suggest to change the specification and,
> instead of using the actual RFC number, use the "BCP" reference which
> is stable. "BCP 47" pointed to RFC 4646 before and now to the current
> one, 5646.
>

Nice catch. I agree with this change.

But may be this is not the best place to talk about the specification?
>

It's good that you brought it up, thank you.

We are resisting big changes to the spec since it's close to finalized, but
this is along the line of "getting it right the first time" so this is good.

Here's the HTTPS URL to BCP 47: <https://tools.ietf.org/html/bcp47>
Anyone know if it's mirrored in Gemini?

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201129/783affe1/attachment.htm>

From stephane at sources.org  Sun Nov 29 15:17:27 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 29 Nov 2020 16:17:27 +0100
Subject: Registering the URI scheme?
Message-ID: <20201129151727.GB21568@nic.fr>

As noted by the author and maintainer of curl, in a discussion about a
patch to add Gemini support to curl, the URI scheme gemini: is not
registered in the official registry
<https://www.iana.org/assignments/uri-schemes/uri-schemes.xml>.

The procedure is not too complex and is probably worth it. This
procedure is documented in RFC 7595 and, basically, you need to fill a
simple form, discuss it on an IETF mailing list and discuss with the
appointed expert.

I know about IETF procedures so, if someone more knowledgeable  about
Gemini wants to work with me, it could be done.

-------------- next part --------------
An embedded message was scrubbed...
From: Daniel Stenberg via curl-library <curl-library at cool.haxx.se>
Subject: Re: [PATCH] New protocol: gemini
Date: Sat, 28 Nov 2020 20:54:34 +0100 (CET)
Size: 11670
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201129/3ab2ae14/attachment.eml>

From johann at qwertqwefsday.eu  Sun Nov 29 15:26:19 2020
From: johann at qwertqwefsday.eu (Johann Galle)
Date: Sun, 29 Nov 2020 16:26:19 +0100
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <AEC55E80-C782-4947-894A-1D8528A6A64B@caolan.uk>
References: <AEC55E80-C782-4947-894A-1D8528A6A64B@caolan.uk>
Message-ID: <8bc79de0-47a9-5aa3-14b4-863031b3ffcf@qwertqwefsday.eu>

On 29.11.2020 09:47, Caolan McMahon wrote:
> I'd like either another mailing list or a subject tag to highlight new
> capsules, software releases, and novel uses for the spec as it stands.
> There should be an accompanying statement that explicitly allows these
> announcements.

We have the [ANN] subject tag for that I think. But that is currently used
for both new software and new capsules. Maybe it would be an improvement to
differentiate these two.

And maybe this thread is also interesting:
https://lists.orbitalfox.eu/archives/gemini/2019/000060.html

That said I think it would not be worth setting up a separate mailing list.

---
You can verify the digital signature on this email with the public key
available through web key discovery. Try `gpg --locate-keys ...`

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201129/ae30b1d9/attachment-0001.sig>

From emilis at emilis.net  Sun Nov 29 16:04:31 2020
From: emilis at emilis.net (Emilis)
Date: Sun, 29 Nov 2020 18:04:31 +0200
Subject: [ANN] gebase: PoC Gemini server in shell
Message-ID: <ea597d0d-b2be-74db-5309-6d1717ba77bb@emilis.net>

Hi,

proud to show that it is possible to run a Gemini server on a router:

https://tildegit.org/emilis/gebase


I was able to run this on one of my boxes with OpenWRT.

I had to install ncat for this to work and generated the certs on my 
laptop before running it. Make is also used, but can be replaced by 
plain shell scripts. All the other commands are provided by BusyBox.

Uses a single Awk file to match URLs.

Takes 1-2s to generate a page on the router :)


The code is very PoC at the moment. I intend to refactor it and use for 
some real-world projects in the future.


--
Emilis Dambauskas
gemini://tilde.team/~emilis/


From me at rwv.io  Sun Nov 29 16:58:43 2020
From: me at rwv.io (Remco)
Date: Sun, 29 Nov 2020 17:58:43 +0100
Subject: CGI and client certificate, or do we need a CGI spec
Message-ID: <87k0u4xfp8.fsf@rwv.io>

Hi,

I've been working on a gemini server and implemented CGI by skimming
through the CGI/1.1 spec (RFC 3875) and looking through some gemini
server implementations a couple of weeks ago, to figure out what
environment variables to provide.

=> https://git.sr.ht/~rwv/dezhemini/tree/bf5b0ec4/dezhmnsrv.rkt#L253

Currently I'm playing around with client certificates (having learned a
lot more about libopenssl and racket ffi than I bargained for) and was
wondering what environment variables I want to expose to bring that
information into CGI scripts.  So I visited the list of gemini server
software again, browsed some code and found 4 servers supporting both
CGI and client certificates.

Here's what the expose.

# Jetforce

=> https://github.com/michael-lazar/jetforce/blob/d2d1f63f/jetforce/protocol.py#L180

* AUTH_TYPE : "CERTIFICATE".
* REMOTE_USER : client certificate X509 subject common name
* TLS_CLIENT_HASH : certificate fingerprint
* TLS_CLIENT_NOT_BEFORE :  certificate start date
* TLS_CLIENT_NOT_AFTER : certificate end date
* TLS_CLIENT_SERIAL_NUMBER : certificate X509 serial number
* TLS_CLIENT_AUTHORISED : "true" if certificate is validated by server CA store

# GLV-1.12556

=> https://github.com/spc476/GLV-1.12556/blob/13d52b63/Lua/GLV-1/gateway.lua#L156

* AUTH_TYPE : "Certificate"
* REMOTE_USER : client certificate X509 subject common name
* TLS_CLIENT_HASH : certificate fingerprint
* TLS_CLIENT_ISSUER : certificate X509 issuer
* TLS_CLIENT_ISSUER_* : certificate X509 issuer sub fields
* TLS_CLIENT_NOT_AFTER : certificate end date
* TLS_CLIENT_NOT_BEFORE : certificate start date
* TLS_CLIENT_REMAIN : certificate days left
* TLS_CLIENT_SUBJECT : certificate X509 subject
* TLS_CLIENT_SUBJECT_* : certificate X509 subject sub fields

# Gemserv

=> https://git.sr.ht/~int80h/gemserv/tree/ebc22964/src/cgi.rs#L42

* AUTH_TYPE : "Certificate"
* REMOTE_USER : client certificate X509 subject common name
* TLS_CLIENT_HASH : certificate fingerprint

# The Unsinkable Molly Brown

=> https://tildegit.org/solderpunk/molly-brown/src/commit/48f9a206c03c0470e1c132b9667c6daa3583dada/dynamic.go#L151

* TLS_CLIENT_HASH : certificate fingerprint
* TLS_CLIENT_ISSUER : certificate X509 issuer
* TLS_CLIENT_ISSUER_CN : certificate X509 issuer common name
* TLS_CLIENT_SUBJECT : certificate X509 subject
* TLS_CLIENT_SUBJECT_CN : certificate X509 subject common name

Looking at these it's obvious everybody is looking at everybody else to
see how they implemented it and just pick whatever they like, so it
seems I am on the right track.  ;-)  Personally I like this minimal
approach of the latter two and will probably go with no more than:

* REMOTE_USER : client certificate X509 subject common name
* TLS_CLIENT_HASH : certificate fingerprint

Because when writing a CGI scripts these are the only things I would
really need: a way to communicate with the user about their certificate
(REMOTE_USER) and a way to distinguish between offered certificates
(TLS_CLIENT_HASH).  I won't need AUTH_TYPE because if I do get a
TLS_CLIENT_HASH I'll know I can authenticate the user.

But that brings me to the real question here.  Does gemini need a CGI
spec?  Given status code 42 for CGI errors, it kinda committed to
something CGI-ish without actually stating what that is.  The only
server making the effort to implement CGI/1.1 is GLV but, IMHO, that
isn't the kind of simplicity I am here for and it's a bit of a hack to
be honest.

GLV does manage to make CGI scripts more portable, whereas other servers
don't really make the effort.  For instance, some don't provide
PATH_INFO but do provide PATH_TRANSLATED and others provide neither.  I
would like to share my CGI-scripts and have them run anywhere but to
make sharing easier something like a spec would be nice.  What do you
think?

Anyway, back to libopenssl and racket ffi..

Cheers,
Remco

From trevor at rocketnine.space  Wed Nov 25 04:40:42 2020
From: trevor at rocketnine.space (trevor at rocketnine.space)
Date: Wed, 25 Nov 2020 04:40:42 +0000
Subject: [ANN] Rocket Nine Labs gemlog (First post: How to create a gemlog
 with gssg)
Message-ID: <2b39cb04ef4a6b3833b57603a6e15205@rocketnine.space>

The Rocket Nine Labs gemlog is now available.

The first post, How to create a gemlog with gssg, guides new Gemini site
administrators through the process of creating their first gemlog post.

Future posts will also feature technical subjects.

gemini://rocketnine.space/

From Z2VtaW5pQGxpc3RzLm9yYml0YWxmb3guZXU=#v1 at kaction.cc  Sun Nov 29 00:10:19 2020
From: Z2VtaW5pQGxpc3RzLm9yYml0YWxmb3guZXU=#v1 at kaction.cc (Z2VtaW5pQGxpc3RzLm9yYml0YWxmb3guZXU=#v1 at kaction.cc)
Date: Sat, 28 Nov 2020 19:10:19 -0500
Subject: Registering GEMINI scheme
Message-ID: <20201129001019.GA1392@localhost.fios-router.home>

Hello.

I started discussion about adding support for gemini into curl. In
addition technical issues with my patch, curl maintainer was concerned
that gemini scheme is not registered by IANA, and sceptical of gemini in
general.

Given how widely curl library is used, mainlining gemini support into it
would give us wide range of applications working transparently with
gemini: git, RSS readers, mirroring tools, source location for package
managers and so on.

For that reason I think we should take the trouble of registering gemini
scheme with IANA. I can probably draft review request, but we will
likely need to adjust specification (e.g s/URL/URI/ and other boring
stuff). According to registration process documentation, it will take
around four weeks of discussion.

solderpunk: What do you think? Are you willing to work on this?

https://tools.ietf.org/html/rfc7595
https://curl.se/mail/lib-2020-11/0083.html

From ben at benaaron.dev  Sun Nov 29 18:02:49 2020
From: ben at benaaron.dev (Ben Goldberg)
Date: Sun, 29 Nov 2020 13:02:49 -0500
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <87k0u4xfp8.fsf@rwv.io>
References: <87k0u4xfp8.fsf@rwv.io>
Message-ID: <dce7cc5e-5e58-cf95-ac20-694db7c75ad4@benaaron.dev>

As someone else trying to write a gemini server with CGI support, I 
wouldn't be opposed to some standardization. It would be nice if CGI 
scripts were portable between instances.

From rwagner at rw-net.de  Sun Nov 29 18:17:00 2020
From: rwagner at rw-net.de (=?UTF-8?Q?Ren=C3=A9=20Wagner?=)
Date: Sun, 29 Nov 2020 19:17:00 +0100 (CET)
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <dce7cc5e-5e58-cf95-ac20-694db7c75ad4@benaaron.dev>
References: <87k0u4xfp8.fsf@rwv.io><dce7cc5e-5e58-cf95-ac20-694db7c75ad4@benaaron.dev>
Message-ID: <20201129181700.61EBD63C09AB@dd22736.kasserver.com>

I totally agree that we need a definition of what information has to be passed to a CGI script by the server. Adjust scripts to honor specific server implementations is a no-go.

For my part i don't care of this is part of the spec itself or a companion spec as long as it is something that is agreed on and written down.

Ren?

Ben Goldberg schrieb am 29.11.2020 19:02 (GMT +01:00):

> As someone else trying to write a gemini server with CGI support, I 
> wouldn't be opposed to some standardization. It would be nice if CGI 
> scripts were portable between instances.
> 
> 

From seirdy at seirdy.one  Sun Nov 29 19:14:11 2020
From: seirdy at seirdy.one (Rohan Kumar)
Date: Sun, 29 Nov 2020 11:14:11 -0800
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <8bc79de0-47a9-5aa3-14b4-863031b3ffcf@qwertqwefsday.eu>
References: <AEC55E80-C782-4947-894A-1D8528A6A64B@caolan.uk>
 <8bc79de0-47a9-5aa3-14b4-863031b3ffcf@qwertqwefsday.eu>
Message-ID: <20201129191411.wzassbmdkibbpqch@rkumar-dekstop>

On Sun, Nov 29, 2020 at 04:26:19PM +0100, Johann Galle wrote:
>We have the [ANN] subject tag for that I think. But that is currently 
>used for both new software and new capsules. Maybe it would be an 
>improvement to differentiate these two.

Agreed that filtering by the [ANN] subject tag is pretty good for now; 
however, I do think that it would be helpful to encourage members to 
*optionally* refine this, e.g. with a subject of "[ANN] [CAPSULE] ..." 
or "[ANN] [SOFTWARE] ...".

Since the line between a capsule and software isn't always super clear-- 
especially if a capsule serves as a demo of a piece of software (e.g.  
CAPCOM)--I do think that plain old "[ANN] ..." subject lines still have 
a place.

(also, I accidentally replied to Johann directly instead of this list 
because muscle memory refuses to die. Sorry!)

/Seirdy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201129/7d06f19d/attachment.sig>

From gemini#lists.orbitalfox.eu#v1 at kaction.cc  Sun Nov 29 19:27:39 2020
From: gemini#lists.orbitalfox.eu#v1 at kaction.cc (gemini#lists.orbitalfox.eu#v1 at kaction.cc)
Date: Sun, 29 Nov 2020 14:27:39 -0500
Subject: Registering GEMINI scheme
Message-ID: <20201129192739.GA23386@localhost.fios-router.home>

Hello.

I started discussion about adding support for gemini into curl. In
addition technical issues with my patch, curl maintainer was concerned
that gemini scheme is not registered by IANA, and sceptical of gemini in
general.

Given how widely curl library is used, mainlining gemini support into it
would give us wide range of applications working transparently with
gemini: git, RSS readers, mirroring tools, source location for package
managers and so on.

For that reason I think we should take the trouble of registering gemini
scheme with IANA. I can probably draft review request, but we will
likely need to adjust specification (e.g s/URL/URI/ and other boring
stuff). According to registration process documentation, it will take
around four weeks of discussion.

Thoughts?

https://tools.ietf.org/html/rfc7595
https://curl.se/mail/lib-2020-11/0083.html

From khuxkm at tilde.team  Sun Nov 29 19:30:56 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Sun, 29 Nov 2020 19:30:56 +0000
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <87k0u4xfp8.fsf@rwv.io>
References: <87k0u4xfp8.fsf@rwv.io>
Message-ID: <8925fcd625a5f2bc7927b399a4ef9be5@tilde.team>

November 29, 2020 11:58 AM, "Remco" <me at rwv.io> wrote:

> Hi,
> 
> I've been working on a gemini server and implemented CGI by skimming
> through the CGI/1.1 spec (RFC 3875) and looking through some gemini
> server implementations a couple of weeks ago, to figure out what
> environment variables to provide.
> 
> => https://git.sr.ht/~rwv/dezhemini/tree/bf5b0ec4/dezhmnsrv.rkt#L253
> 
> Currently I'm playing around with client certificates (having learned a
> lot more about libopenssl and racket ffi than I bargained for) and was
> wondering what environment variables I want to expose to bring that
> information into CGI scripts. So I visited the list of gemini server
> software again, browsed some code and found 4 servers supporting both
> CGI and client certificates.
> 
> Here's what the expose.
> 
> # Jetforce
> 
> => https://github.com/michael-lazar/jetforce/blob/d2d1f63f/jetforce/protocol.py#L180
> 
> * AUTH_TYPE : "CERTIFICATE".
> * REMOTE_USER : client certificate X509 subject common name
> * TLS_CLIENT_HASH : certificate fingerprint
> * TLS_CLIENT_NOT_BEFORE : certificate start date
> * TLS_CLIENT_NOT_AFTER : certificate end date
> * TLS_CLIENT_SERIAL_NUMBER : certificate X509 serial number
> * TLS_CLIENT_AUTHORISED : "true" if certificate is validated by server CA store
> 
> # GLV-1.12556
> 
> => https://github.com/spc476/GLV-1.12556/blob/13d52b63/Lua/GLV-1/gateway.lua#L156
> 
> * AUTH_TYPE : "Certificate"
> * REMOTE_USER : client certificate X509 subject common name
> * TLS_CLIENT_HASH : certificate fingerprint
> * TLS_CLIENT_ISSUER : certificate X509 issuer
> * TLS_CLIENT_ISSUER_* : certificate X509 issuer sub fields
> * TLS_CLIENT_NOT_AFTER : certificate end date
> * TLS_CLIENT_NOT_BEFORE : certificate start date
> * TLS_CLIENT_REMAIN : certificate days left
> * TLS_CLIENT_SUBJECT : certificate X509 subject
> * TLS_CLIENT_SUBJECT_* : certificate X509 subject sub fields
> 
> # Gemserv
> 
> => https://git.sr.ht/~int80h/gemserv/tree/ebc22964/src/cgi.rs#L42
> 
> * AUTH_TYPE : "Certificate"
> * REMOTE_USER : client certificate X509 subject common name
> * TLS_CLIENT_HASH : certificate fingerprint
> 
> # The Unsinkable Molly Brown
> 
> =>
> https://tildegit.org/solderpunk/molly-brown/src/commit/48f9a206c03c0470e1c132b9667c6daa3583dada/dyna
> ic.go#L151
> 
> * TLS_CLIENT_HASH : certificate fingerprint
> * TLS_CLIENT_ISSUER : certificate X509 issuer
> * TLS_CLIENT_ISSUER_CN : certificate X509 issuer common name
> * TLS_CLIENT_SUBJECT : certificate X509 subject
> * TLS_CLIENT_SUBJECT_CN : certificate X509 subject common name
> 
> Looking at these it's obvious everybody is looking at everybody else to
> see how they implemented it and just pick whatever they like, so it
> seems I am on the right track. ;-) Personally I like this minimal
> approach of the latter two and will probably go with no more than:
> 
> * REMOTE_USER : client certificate X509 subject common name
> * TLS_CLIENT_HASH : certificate fingerprint
> 
> Because when writing a CGI scripts these are the only things I would
> really need: a way to communicate with the user about their certificate
> (REMOTE_USER) and a way to distinguish between offered certificates
> (TLS_CLIENT_HASH). I won't need AUTH_TYPE because if I do get a
> TLS_CLIENT_HASH I'll know I can authenticate the user.
> 
> But that brings me to the real question here. Does gemini need a CGI
> spec? Given status code 42 for CGI errors, it kinda committed to
> something CGI-ish without actually stating what that is. The only
> server making the effort to implement CGI/1.1 is GLV but, IMHO, that
> isn't the kind of simplicity I am here for and it's a bit of a hack to
> be honest.
> 
> GLV does manage to make CGI scripts more portable, whereas other servers
> don't really make the effort. For instance, some don't provide
> PATH_INFO but do provide PATH_TRANSLATED and others provide neither. I
> would like to share my CGI-scripts and have them run anywhere but to
> make sharing easier something like a spec would be nice. What do you
> think?
> 
> Anyway, back to libopenssl and racket ffi..
> 
> Cheers,
> Remco

Some thoughts:

1. My gemini CGI library for Python assumes AUTH_TYPE is available because it should be. I could technically edit it to test for the existence of TLS_CLIENT_HASH but why should I, when AUTH_TYPE is how you're supposed to check?
2. I kinda like the idea of having as much info as we can give about the cert, although I do think there's something to be said about minimalism and finding a balance.

That being said, my proposal:

 - `AUTH_TYPE`: Certificate
 - `REMOTE_USER`: certificate subject CN
 - `TLS_CLIENT_HASH`: Hash of the client cert (with `ALGO:HASHBYTESGOHERE` format)
 - `TLS_CLIENT_NOT_AFTER`: End date
 - `TLS_CLIENT_NOT_BEFORE`: Start date
 - `TLS_CLIENT_ISSUER`: Issuer
 - `TLS_CLIENT_SUBJECT`: Subject

The assumption is that TLS_CLIENT_ISSUER and TLS_CLIENT_SUBJECT are in forms where the info can easily be parsed out (so no need for the sub-field variables, apart from REMOTE_USER being the subject CN). TLS_CLIENT_REMAINING isn't needed, either, since any programming language worth its salt is going to have a way to get the days between today and TLS_CLIENT_NOT_AFTER.

Just my two cents,
Robert "khuxkm" Miles

From solderpunk at posteo.net  Sun Nov 29 18:38:21 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 29 Nov 2020 19:38:21 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
Message-ID: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>

Greetings Geminauts!

As per recent mailing list discovery, I've made a very small change to
the specification.  Previously, Gemini requests and links in text/gemini
documents could both omit the scheme, and servers/clients were expected
to add an implicit scheme of "gemini".  This has been changed and now
schemes are mandatory in URLs in both these contexts.

This is a trivial simplification of the spec, reflecting observations
from multiple people that schemeless URLs are both very rarely used and
very rarely understood (a leading "//" is required to disambiguate
schemeless URLs from relative URLs, but nobody knows that because
informal use of notation like gemini:// and https:// has caused us all
to mistakenly believe the "//" is associated with the scheme when it is
actually part of the authority).  The implicit scheme idea dates back to
very early stages of Gemini when I was unduly concerned with minimising
protocol overhead relative to Gopher.  As soon as mandatory TLS was
added, saving the 7 bytes of "gemini:" became of no practical concern
and getting rid of this idea just eliminates a confusing edge case.

On a related note, the spec was also changed in various places so that
it does not perpetuate the misunderstanding of URL structure by talking
about "a scheme of gemini://".

Server authors MAY update their servers to return status 59 ("bad
request") upon receipt of a request with no scheme in the URL, but this
should not be considered an urgent change, as leaving existing behaviour
of assuming a scheme of gemini in place could be considered a valid
application of Postel's law.

Client authors MUST update their clients so that if a user manually
enters a URL without a scheme, a scheme of gemini is included in the
request (many clients likely do this anyway).  Clients MAY treat
schemeless links in text/gemini documents as errors, but again assuming
a scheme of gemini may be considered a valid application of Postel's
law.

Authors of Gemini content or software which generates Gemini content
MUST add explicit schemes to any schemeless links.

Cheers,
Solderpunk


From khuxkm at tilde.team  Sun Nov 29 20:04:03 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Sun, 29 Nov 2020 20:04:03 +0000
Subject: Registering GEMINI scheme
In-Reply-To: <20201129192739.GA23386@localhost.fios-router.home>
References: <20201129192739.GA23386@localhost.fios-router.home>
Message-ID: <d48dabf5380cf87b0cc111dcea4212ef@tilde.team>

November 29, 2020 2:27 PM, gemini#lists.orbitalfox.eu#v1 at kaction.cc wrote:

> Hello.
> 
> I started discussion about adding support for gemini into curl. In
> addition technical issues with my patch, curl maintainer was concerned
> that gemini scheme is not registered by IANA, and sceptical of gemini in
> general.
> 
> Given how widely curl library is used, mainlining gemini support into it
> would give us wide range of applications working transparently with
> gemini: git, RSS readers, mirroring tools, source location for package
> managers and so on.
> 
> For that reason I think we should take the trouble of registering gemini
> scheme with IANA. I can probably draft review request, but we will
> likely need to adjust specification (e.g s/URL/URI/ and other boring
> stuff). According to registration process documentation, it will take
> around four weeks of discussion.
> 
> Thoughts?

We can file for a provisional registration without spending the time discussing it on the uri-review mailing list. The things we need for a registration request:

 - Name: `gemini` works, and follows the syntax required.
 - No duplicate: There isn't a gemini registration yet.
 - Contact information: I feel like along with solderpunk, we should also register someone else as another point of contact, just in case solderpunk disappears for a while.
 - Permanent, citable specification: The Gemini spec, maybe specifically link the section where the URI scheme is defined?
 - Security considerations: mention TOFU?
 - Differences from Section 3: none that I know of?

Just my two cents,
Robert "khuxkm" Miles

From sean at conman.org  Sun Nov 29 20:08:10 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 15:08:10 -0500
Subject: Heads up about a Gemini client @ 198.12.83.123
Message-ID: <20201129200810.GW1721@brevard.conman.org>


  It's not threatening my server or anything, but who ever is responsible
for the client at 198.12.83.123, your client is currently stuck in the
Redirection From Hell test and has been for some time.  From the length of
time, it appears to be running autonomously so perhaps a leftover thread, or
an autonomous client that doesn't read robots.txt, or didn't follow the spec
carefully enough.

  Anyway, just a heads up.

  -spc


From sean at conman.org  Sun Nov 29 20:25:46 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 15:25:46 -0500
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <87k0u4xfp8.fsf@rwv.io>
References: <87k0u4xfp8.fsf@rwv.io>
Message-ID: <20201129202546.GX1721@brevard.conman.org>

It was thus said that the Great Remco once stated:
> Here's what the expose.
> 
> # GLV-1.12556
> 
> => https://github.com/spc476/GLV-1.12556/blob/13d52b63/Lua/GLV-1/gateway.lua#L156
> 
> * AUTH_TYPE : "Certificate"
> * REMOTE_USER : client certificate X509 subject common name
> * TLS_CLIENT_HASH : certificate fingerprint
> * TLS_CLIENT_ISSUER : certificate X509 issuer
> * TLS_CLIENT_ISSUER_* : certificate X509 issuer sub fields
> * TLS_CLIENT_NOT_AFTER : certificate end date
> * TLS_CLIENT_NOT_BEFORE : certificate start date
> * TLS_CLIENT_REMAIN : certificate days left
> * TLS_CLIENT_SUBJECT : certificate X509 subject
> * TLS_CLIENT_SUBJECT_* : certificate X509 subject sub fields

  When I wrote the CGI module for GLV-1.12556, I modelled mine after what
Apache did, but renamed the TLS environment variables to better names.  I
figured why not?  And it's not as if all of it is needed, but I was able to
send it.

  Another aspect of GLV-1.12556 is that unless configured otherwise, a CGI
script called with a client certificate will *only* get AUTH_TYPE and
REMOTE_USER set.  AUTH_TYPE and REMOTE_USER are required by the CGI spec.

> But that brings me to the real question here.  Does gemini need a CGI
> spec?  Given status code 42 for CGI errors, it kinda committed to
> something CGI-ish without actually stating what that is.  The only
> server making the effort to implement CGI/1.1 is GLV but, IMHO, that
> isn't the kind of simplicity I am here for and it's a bit of a hack to
> be honest.

  Don't be mislead by GLV-1.12556.  Supporting CGI/1.1 isn't hard---the
complexity I have is in supporting CGI scripts meant for the web and
possibly Apache.  I did add the following variables for convenience:

	GEMINI_DOCUMENT_ROOT   = directory
	GEMINI_SCRIPT_FILENAME = full_path_to_script
	GEMINI_URL_PATH        = location.path
	GEMINI_URL             = request

> GLV does manage to make CGI scripts more portable, whereas other servers
> don't really make the effort.  For instance, some don't provide
> PATH_INFO but do provide PATH_TRANSLATED and others provide neither.  I
> would like to share my CGI-scripts and have them run anywhere but to
> make sharing easier something like a spec would be nice.  What do you
> think?

  I think it's easy enough to follow RFC-3875 (the CGI/1.1 spec).  It's not
that hard.  It's just:

	GATEWAY_INTERFACE      = "CGI/1.1"
	QUERY_STRING           = location.query or "" -- Must be set
	REMOTE_ADDR            = auth._remote
	REMOTE_HOST            = auth._remote
	SCRIPT_NAME            = base
	SERVER_NAME            = location.host
	SERVER_PORT            = tostring(location.port)
	SERVER_SOFTWARE        = "GLV-1.12556/1"
	AUTH_TYPE              = "Certificate" -- only if client cert
	REMOTE_USER            = auth.subject.CN or "" -- only if client cert
	PATH_INFO              = ... okay, some explanation required [1]
	PATH_TRANSLATED        = ... okay, some explanation required [1]

  Other variables are possible, but should be prefixed by the protocol name.

  -spc

[1]	These last two require a bit more explanation to set correctly that
	I don't have time for in this message.  I'll circle back to this
	later tonight when I have a bit more time.

From sean at conman.org  Sun Nov 29 20:27:14 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 15:27:14 -0500
Subject: Heads up about a Gemini client @ 198.12.83.123
In-Reply-To: <20201129200810.GW1721@brevard.conman.org>
References: <20201129200810.GW1721@brevard.conman.org>
Message-ID: <20201129202713.GY1721@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
>   It's not threatening my server or anything, but who ever is responsible
> for the client at 198.12.83.123, your client is currently stuck in the
> Redirection From Hell test and has been for some time.  From the length of
> time, it appears to be running autonomously so perhaps a leftover thread, or
> an autonomous client that doesn't read robots.txt, or didn't follow the spec
> carefully enough.
> 
>   Anyway, just a heads up.
> 
>   -spc

  Sorry, this was sent to an additional address by mistake, and said other
address has no relation to what the client is doing.

  -spc

From colecmac at protonmail.com  Sun Nov 29 21:15:09 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 29 Nov 2020 21:15:09 +0000
Subject: Heads up about a Gemini client @ 198.12.83.123
In-Reply-To: <20201129200810.GW1721@brevard.conman.org>
References: <20201129200810.GW1721@brevard.conman.org>
Message-ID: <044nxu1qwMF4iklvkcHvVZkccfhnfjARKjSIj7wG3IXUP2K9cGGUgAr3OC1ewCD6jplEaGkXr0k4cbDHalxTdn1k9ouo3naEozad7C9lZR4=@protonmail.com>

(Resent to the list, not just spc)

> 198.12.83.123

? dig -x 198.12.83.123 +short
phlox.titmouse.org.

https://phlox.titmouse.org/about.html mentions a Discordian by
the name of "Benedict T. Eyen, the T stands for Teeth." Unfortunately
there's no email address, so we can't contact him. Curiously, there
is a Gemini server running on that domain, but accessing it just gives
me Proxy Request Refused.

makeworld

From cowan at ccil.org  Sun Nov 29 21:33:32 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 29 Nov 2020 16:33:32 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
Message-ID: <CAD2gp_Qu7A5uL5FdkvqjFyyd4=Hp1w79Ks=nbNe3Yz=D2o7A_A@mail.gmail.com>

On Sun, Nov 29, 2020 at 2:33 PM Solderpunk <solderpunk at posteo.net> wrote:

100% agreement up to this point.

Clients MAY treat
> schemeless links in text/gemini documents as errors, but again assuming
> a scheme of gemini may be considered a valid application of Postel's
> law.
>

They aren't errors: they are relative references.  If a file "gemini://
example.net/this/that/file1.gmi" has a link saying "
example.com/path/to/file2.gmi", for example, that does *not* mean in RFC
3986 "gemini://example.com/path/to/file2.gmi" but rather "gemini://
example.net/this/that/example.com/path/to/file2.gmi".  So this is a Big
Bang change in the interpretation of text/gemini files.  But I am still for
it, not against it.




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
At the end of the Metatarsal Age, the dinosaurs abruptly vanished.
The theory that a single catastrophic event may have been responsible
has been strengthened by the recent discovery of a worldwide layer of
whipped cream marking the Creosote-Tutelary boundary.  --Science Made Stupid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201129/57e60681/attachment-0001.htm>

From me at adnano.co  Sun Nov 29 21:48:03 2020
From: me at adnano.co (Adnan Maolood)
Date: Sun, 29 Nov 2020 16:48:03 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <CAD2gp_Qu7A5uL5FdkvqjFyyd4=Hp1w79Ks=nbNe3Yz=D2o7A_A@mail.gmail.com>
Message-ID: <C7G2TOVCKDZS.32HN7FB9HCSCQ@nitro>

On Sun Nov 29, 2020 at 4:33 PM EST, John Cowan wrote:
> > Clients MAY treat
> > schemeless links in text/gemini documents as errors, but again assuming
> > a scheme of gemini may be considered a valid application of Postel's
> > law.
>
> They aren't errors: they are relative references. If a file "gemini://
> example.net/this/that/file1.gmi" has a link saying "
> example.com/path/to/file2.gmi", for example, that does *not* mean in RFC
> 3986 "gemini://example.com/path/to/file2.gmi" but rather "gemini://
> example.net/this/that/example.com/path/to/file2.gmi". So this is a Big
> Bang change in the interpretation of text/gemini files. But I am still
> for it, not against it.

I think that schemeless links in text/gemini documents should not be
considered errors. Clients should resolve the relative reference before
sending the request.

From easrng at gmail.com  Sun Nov 29 21:53:14 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Sun, 29 Nov 2020 16:53:14 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
Message-ID: <CAEzvDCVcSiiQnus2QGPdE60bMB8kyfGAiMqWmESu3cMWEeU+2A@mail.gmail.com>

On Sunday, November 29, 2020, Solderpunk <solderpunk at posteo.net> wrote:

> ... links in text/gemini
> documents could both omit the scheme, and servers/clients were expected
> to add an implicit scheme of "gemini".  This has been changed and now
> schemes are mandatory
>
This makes sense for requests because you are supposed to send an absolute
URI anyway, but I strongly disagree with this change for documents. It is
useful for those who serve the same content on HTTP and Gemini to be able
to have links that work on both. I would appreciate it if schemeless links
in gemtext continued to be allowed.

PS: When replying to emails on the list do I reply to the person I am
replying to and cc the list or just send to the list?


-- 
? <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201129/cae45bdd/attachment.htm>

From colecmac at protonmail.com  Sun Nov 29 21:54:53 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 29 Nov 2020 21:54:53 +0000
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
Message-ID: <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>

(I keep replying only to the author and not the list, sorry.)


I agree with everything up to this:

> Clients MAY treat
> schemeless links in text/gemini documents as errors, but again assuming
> a scheme of gemini may be considered a valid application of Postel's
> law.
>
> Authors of Gemini content or software which generates Gemini content
> MUST add explicit schemes to any schemeless links.

What is the issue with scheme-less link lines? These are perfectly valid,
and any client with a good URL parsing library should support them. They
are already in use by authors, and are of particular importance to sites
that support bi-hosting on the Web and on Gemini, like flounder.online.
That way the links users make will work in both spaces automatically.

I believe this part of the change should be reversed, and schemeless links
should be allowed. It is only the request part of the spec that was
previously ambiguous.

I'm sorry for not bringing this up earlier, I misunderstood the earlier
discussion an did not realize that removing schemeless link support was on
the table.


makeworld

From me at adnano.co  Sun Nov 29 22:00:31 2020
From: me at adnano.co (Adnan Maolood)
Date: Sun, 29 Nov 2020 17:00:31 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
Message-ID: <C7G338OV2FQK.25XPO313LO3DT@nitro>

On Sun Nov 29, 2020 at 4:54 PM EST,  wrote:
> What is the issue with scheme-less link lines? These are perfectly valid,
> and any client with a good URL parsing library should support them. They
> are already in use by authors, and are of particular importance to sites
> that support bi-hosting on the Web and on Gemini, like flounder.online.
> That way the links users make will work in both spaces automatically.
>
> I believe this part of the change should be reversed, and schemeless links
> should be allowed. It is only the request part of the spec that was
> previously ambiguous.
>
> I'm sorry for not bringing this up earlier, I misunderstood the earlier
> discussion an did not realize that removing schemeless link support was on
> the table.

I agree. When I proposed this change, I mentioned that schemeless links
should still work:

https://lists.orbitalfox.eu/archives/gemini/2020/003534.html

> Linking to a URL without a scheme should still work. It would be up to
> the client to resolve the URL reference before making the request. This
> functionality should already be provided by whatever library the client
> uses to handle relative URLs.

From luke at marmaladefoo.com  Sun Nov 29 22:06:56 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 29 Nov 2020 22:06:56 +0000
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
Message-ID: <5FC41B80.4070304@marmaladefoo.com>



On 29-Nov-2020 21:54, colecmac at protonmail.com wrote:
> (I keep replying only to the author and not the list, sorry.)
>
>
> I agree with everything up to this:
>
>> Clients MAY treat
>> schemeless links in text/gemini documents as errors, but again assuming
>> a scheme of gemini may be considered a valid application of Postel's
>> law.
>>
>> Authors of Gemini content or software which generates Gemini content
>> MUST add explicit schemes to any schemeless links.
> What is the issue with scheme-less link lines? These are perfectly valid,
> and any client with a good URL parsing library should support them. They
> are already in use by authors, and are of particular importance to sites
> that support bi-hosting on the Web and on Gemini, like flounder.online.
> That way the links users make will work in both spaces automatically.

I think there is some confusion in this thread. Here is my 
interpretation, maybe it can help clarify the conversation.

There are two "types" of link we are talking about.

1. The link lines in gemtext files (the line types beginning =>)

In the first case, if you want a "schemeless" link (i.e. one that works 
for HTTP and Gemini) use the following form:

\\server\path\to\endpoint

If there is no scheme or double slash, the client should interpret the 
link as a relative path with respect to the current location.

2. The URL submitted to the server with the client request.

This is where there is a change to the spec, which is now that the URL 
sent to the server must be a fully qualified link with a scheme.

> Clients MAY treat
> schemeless links in text/gemini documents as errors, but again assuming
> a scheme of gemini may be considered a valid application of Postel's
> law.

Solderpunk mentioned (pasted text above) if there is no scheme, the 
*client* may raise an error. I think to clarify, if there is no scheme 
on the URL sent to the server, it is the *server* that should respond 
with an error (after all it is not a valid full URL that is submitted).

If there is no scheme on the expressed link in the gemtext (type 1 
above), the client should interpret it as a relative path, unless it 
starts "//"

  - Luke



From luke at marmaladefoo.com  Sun Nov 29 22:08:42 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 29 Nov 2020 22:08:42 +0000
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <5FC41B80.4070304@marmaladefoo.com>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
 <5FC41B80.4070304@marmaladefoo.com>
Message-ID: <5FC41BEA.5020700@marmaladefoo.com>



On 29-Nov-2020 22:06, Luke Emmet wrote:
>
>
> On 29-Nov-2020 21:54, colecmac at protonmail.com wrote:
>> (I keep replying only to the author and not the list, sorry.)
>>
>>
>> I agree with everything up to this:
>>
>>> Clients MAY treat
>>> schemeless links in text/gemini documents as errors, but again assuming
>>> a scheme of gemini may be considered a valid application of Postel's
>>> law.
>>>
>>> Authors of Gemini content or software which generates Gemini content
>>> MUST add explicit schemes to any schemeless links.
>> What is the issue with scheme-less link lines? These are perfectly 
>> valid,
>> and any client with a good URL parsing library should support them. They
>> are already in use by authors, and are of particular importance to sites
>> that support bi-hosting on the Web and on Gemini, like flounder.online.
>> That way the links users make will work in both spaces automatically.
>
> I think there is some confusion in this thread. Here is my 
> interpretation, maybe it can help clarify the conversation.
>
> There are two "types" of link we are talking about.
>
> 1. The link lines in gemtext files (the line types beginning =>)
>
> In the first case, if you want a "schemeless" link (i.e. one that 
> works for HTTP and Gemini) use the following form:
>
> \\server\path\to\endpoint
>

Oops - did you spot the obvious error (too many hours spent on UNC paths 
in Windows methinks)

Of course, I meant:

//server/path/to/endpoint

  - Luke

From colecmac at protonmail.com  Sun Nov 29 22:22:44 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 29 Nov 2020 22:22:44 +0000
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <5FC41B80.4070304@marmaladefoo.com>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
 <5FC41B80.4070304@marmaladefoo.com>
Message-ID: <Zo29_VYSA_0K30f9IIrrBdSpXOXtRht1NaAN0shA_ExvI5gikJUgqO1-GGSi_hCKaQzouqFJ46wcgdQ_PALV845DQwGCAj70DMWx237XnkY=@protonmail.com>

> I think there is some confusion in this thread. Here is my
> interpretation, maybe it can help clarify the conversation.
>
> There are two "types" of link we are talking about.
> 1.  The link lines in gemtext files (the line types beginning =>)
> [snip]
> 2. The URL submitted to the server with the client request.

I was only talking about the first kind in my email. I'm fine with
the change to the request URL.

> I think to clarify, if there is no scheme
> on the URL sent to the server, it is the server that should respond
> with an error (after all it is not a valid full URL that is submitted).
>
> If there is no scheme on the expressed link in the gemtext (type 1
> above), the client should interpret it as a relative path, unless it
> starts "//"

Yes, I agree with all of this. I take issue with two parts:

> Clients MAY treat schemeless links in text/gemini documents as errors

and

> Authors of Gemini content or software which generates Gemini content
> MUST add explicit schemes to any schemeless links.

I think both of these changes are not great, as I explained in my original
email. It effectively disallows schemeless links in gemtext, which I'm
not in favour of.


makeworld


From luke at marmaladefoo.com  Sun Nov 29 22:43:31 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 29 Nov 2020 22:43:31 +0000
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <Zo29_VYSA_0K30f9IIrrBdSpXOXtRht1NaAN0shA_ExvI5gikJUgqO1-GGSi_hCKaQzouqFJ46wcgdQ_PALV845DQwGCAj70DMWx237XnkY=@protonmail.com>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
 <5FC41B80.4070304@marmaladefoo.com>
 <Zo29_VYSA_0K30f9IIrrBdSpXOXtRht1NaAN0shA_ExvI5gikJUgqO1-GGSi_hCKaQzouqFJ46wcgdQ_PALV845DQwGCAj70DMWx237XnkY=@protonmail.com>
Message-ID: <5FC42413.8030400@marmaladefoo.com>



On 29-Nov-2020 22:22, colecmac at protonmail.com wrote:
>
> [...]  I take issue with two parts:
>> Clients MAY treat schemeless links in text/gemini documents as errors
> and
>
>> Authors of Gemini content or software which generates Gemini content
>> MUST add explicit schemes to any schemeless links.
> I think both of these changes are not great, as I explained in my original
> email. It effectively disallows schemeless links in gemtext, which I'm
> not in favour of.

Ok - I'm following you now, and I think I agree about not needing this 
restriction in gemtext itself.

on the first point, schemeless links of the form

//authority/path

in the gemtext are quite valid and will be mapped to 
gemini://authority/path in a gemini client and http://authority/path in  
a web client

schemeless links of the form

server.foo/path

are not schemeless links, but rather relative paths with respect to the 
current URL.

On the second point, gemtext generating software should allow for the 
//authority/path form of links.

  - Luke

From cowan at ccil.org  Sun Nov 29 22:55:47 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 29 Nov 2020 17:55:47 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <tc0udtcPcjakhaytouaPIZlkaF8Bk7gYMM-WYobOsGYvC3vqEITjNbQ3iLM8x2bqVI5yDUspGT9qM_rafWOf126pN8Vk9KF0mHxuRmZYiDw=@protonmail.com>
Message-ID: <CAD2gp_QP2gKb0Y+mA0R2uvbbAQk77_RG4R6R8U5N7QDStUZZ8A@mail.gmail.com>

On Sun, Nov 29, 2020 at 4:55 PM <colecmac at protonmail.com> wrote:


> They are already in use by authors, and are of particular importance to
> sites
> that support bi-hosting on the Web and on Gemini, like flounder.online.
> That way the links users make will work in both spaces automatically.
>

They are also important for capsules (or websites) with many internal
links, as it makes them portable to other Internet locations.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Mark Twain on Cecil Rhodes: I admire him, I freely admit it,
and when his time comes I shall buy a piece of the rope for a keepsake.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201129/0b9376a3/attachment.htm>

From colecmac at protonmail.com  Mon Nov 30 01:32:14 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 30 Nov 2020 01:32:14 +0000
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <87k0u4xfp8.fsf@rwv.io>
References: <87k0u4xfp8.fsf@rwv.io>
Message-ID: <Ml1olaxUU9fDMSRWdkOS2v1QuE4PMkM5dHHV2XEcH_rbLOHak4Hh5_1Qku_vn7rjA4upB2oEX1mrHajW2-E0D1iWpCxhvwpMl8DJWuitjFY=@protonmail.com>

One important thing to standardize is how TLS_CLIENT_HASH is
calculated. Otherwise CGI scripts will not be able to recognize
clients again if the server software changes.

makeworld

From colecmac at protonmail.com  Mon Nov 30 01:34:19 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 30 Nov 2020 01:34:19 +0000
Subject: RFC for languages and/or discussion about the specification
In-Reply-To: <CAObwWNj3_mNzr=5JM2TYxeGtcafdQEMvnfMPrkgk-nL5VcNnPg@mail.gmail.com>
References: <20201129134732.GA5870@sources.org>
 <CAObwWNj3_mNzr=5JM2TYxeGtcafdQEMvnfMPrkgk-nL5VcNnPg@mail.gmail.com>
Message-ID: <KkfRzO4Wd7nKrndbCmjvdzf67RBJjZNX9vmd4tUpUYqtr8M-GvCdH6qsuRtWmPFWLNmVktkYCrwklhFwWw-enYk9YSwaZvwuGtl6HbEvGH0=@protonmail.com>

> Here's the HTTPS URL to BCP 47: <https://tools.ietf.org/html/bcp47>
> Anyone know if it's mirrored in Gemini?

It is now.

gemini://makeworld.gq/files/bcp47.txt


makeworld



From sean at conman.org  Mon Nov 30 02:25:18 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 21:25:18 -0500
Subject: Web proxies and robots.txt (was Re: Heads up about a Gemini client @
 198.12.83.123)
In-Reply-To: <20201129200810.GW1721@brevard.conman.org>
References: <20201129200810.GW1721@brevard.conman.org>
Message-ID: <20201130022518.GA1721@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
>   It's not threatening my server or anything, but who ever is responsible
> for the client at 198.12.83.123, your client is currently stuck in the
> Redirection From Hell test and has been for some time.  From the length of
> time, it appears to be running autonomously so perhaps a leftover thread, or
> an autonomous client that doesn't read robots.txt, or didn't follow the spec
> carefully enough.
> 
>   Anyway, just a heads up.
> 
>   -spc

  So the client in question was most likely a web proxy.  I'm not sure what
site, nor the software used, but it did response to a Gemini request with
"53 Proxy Requet Refused" so there *is* a Gemini server there.  And given
that it made 137,060 requests before I shut down my own server told me that
it was an autonomous agent that no one was watching.  Usually, I may see a
client hit 20 or 30 times before it stops.  Not this one.

  Now granted, my server is a bit unique in that I have tests set up
specifically for clients to test against, and several of them involve
infinite redirects.  And yes, that was 137,060 *unique* requests.

  So first up, Solderpunk, if you could please add a redirection follow
limit to the specification and make it mandatory.  You can specify some
two, heck, even three digit number to follow, but please, *please*, add it
to the specification and *not* just the best practices document to make
programmers aware of the issue.  It seems like it's too easy to overlook
this potential trap (I see it often enough).

  Second, had the proxy in question fetched robots.txt, I had this area
specifically marked out:

User-agent: *
Disallow: /test/redirehell 

  I have that for a reason, and had the autonomous client in question read
it, this wouldn't have happened in the first place.  Even if you disagree
with this, it may be difficult to stop an autonomous agent once the user of
said web proxy has dropped the web connection.  I don't know, I haven't
written a web proxy, and this is one more thing to keep in mind when writing
one.  I think it would be easier to follow robots.txt.

  -spc (To the person who called me a dick for blocking a web proxy---yes,
	there *are* reasons to block them)

From lazar.michael22 at gmail.com  Mon Nov 30 02:32:41 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sun, 29 Nov 2020 21:32:41 -0500
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <Ml1olaxUU9fDMSRWdkOS2v1QuE4PMkM5dHHV2XEcH_rbLOHak4Hh5_1Qku_vn7rjA4upB2oEX1mrHajW2-E0D1iWpCxhvwpMl8DJWuitjFY=@protonmail.com>
References: <87k0u4xfp8.fsf@rwv.io>
 <Ml1olaxUU9fDMSRWdkOS2v1QuE4PMkM5dHHV2XEcH_rbLOHak4Hh5_1Qku_vn7rjA4upB2oEX1mrHajW2-E0D1iWpCxhvwpMl8DJWuitjFY=@protonmail.com>
Message-ID: <CAFTy05a=gMsV=qNEN_JqSZxMnvW3GKtyA1jXAy0DJWfk2NfEkA@mail.gmail.com>

On Sun, Nov 29, 2020 at 8:32 PM <colecmac at protonmail.com> wrote:
>
> One important thing to standardize is how TLS_CLIENT_HASH is
> calculated. Otherwise CGI scripts will not be able to recognize
> clients again if the server software changes.
>
> makeworld

I think that jetforce is the odd duckling here. I'm the only one using base64
for hashes. This was discussed a while ago on the mailing list and I declared
that I would switch if a consensus was reached [0]. IIRC the discussion kind of
petered out after that...

So I will say right now, unless there's strong opposition, that I'm going to
change TLS_CLIENT_HASH to "SHA256:<HASH>" where <HASH> is the uppercase hex
representation of the certificate hash, with *no* colons in it. This change
will be made in the next release of jetforce, with TLS_CLIENT_HASH_B64 being
as a backwards compatible env var to make the transition easier for any existing
CGI scripts.

Is anybody currently using the certificate hash in their CGI scripts? I am very
curious because I haven't seen many real uses of client certs in gemini thus
far.

- Michael

[0] https://lists.orbitalfox.eu/archives/gemini/2020/001529.html

From khuxkm at tilde.team  Mon Nov 30 02:35:14 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Mon, 30 Nov 2020 02:35:14 +0000
Subject: Web proxies and robots.txt (was Re: Heads up about a Gemini
 client @ 198.12.83.123)
In-Reply-To: <20201130022518.GA1721@brevard.conman.org>
References: <20201130022518.GA1721@brevard.conman.org>
 <20201129200810.GW1721@brevard.conman.org>
Message-ID: <d04a40a820b312e7b465a21785676fce@tilde.team>

November 29, 2020 9:25 PM, "Sean Conner" <sean at conman.org> wrote:

> It was thus said that the Great Sean Conner once stated:
> 
>> It's not threatening my server or anything, but who ever is responsible
>> for the client at 198.12.83.123, your client is currently stuck in the
>> Redirection From Hell test and has been for some time. From the length of
>> time, it appears to be running autonomously so perhaps a leftover thread, or
>> an autonomous client that doesn't read robots.txt, or didn't follow the spec
>> carefully enough.
>> 
>> Anyway, just a heads up.
>> 
>> -spc
> 
> So the client in question was most likely a web proxy. I'm not sure what
> site, nor the software used, but it did response to a Gemini request with
> "53 Proxy Requet Refused" so there *is* a Gemini server there. And given
> that it made 137,060 requests before I shut down my own server told me that
> it was an autonomous agent that no one was watching. Usually, I may see a
> client hit 20 or 30 times before it stops. Not this one.
> 
> Now granted, my server is a bit unique in that I have tests set up
> specifically for clients to test against, and several of them involve
> infinite redirects. And yes, that was 137,060 *unique* requests.
> 
> So first up, Solderpunk, if you could please add a redirection follow
> limit to the specification and make it mandatory. You can specify some
> two, heck, even three digit number to follow, but please, *please*, add it
> to the specification and *not* just the best practices document to make
> programmers aware of the issue. It seems like it's too easy to overlook
> this potential trap (I see it often enough).
> 
> Second, had the proxy in question fetched robots.txt, I had this area
> specifically marked out:
> 
> User-agent: *
> Disallow: /test/redirehell
> 
> I have that for a reason, and had the autonomous client in question read
> it, this wouldn't have happened in the first place. Even if you disagree
> with this, it may be difficult to stop an autonomous agent once the user of
> said web proxy has dropped the web connection. I don't know, I haven't
> written a web proxy, and this is one more thing to keep in mind when writing
> one. I think it would be easier to follow robots.txt.
> 
> -spc (To the person who called me a dick for blocking a web proxy---yes,
> there *are* reasons to block them)

I recently wrote a gemini to web proxy as a simple side-project to see how easy it would be to create, and one thing I implemented that I feel should be a standard for web proxies is not handling redirects internally. If you tell my gemini proxy to request a page that offers a redirect (say, the next page link for LEO), it will send you back a small web page saying "hey, the site at this URL wants to send you to this other URL, do you want to follow that redirect or nah?" (not exact wording but you get my drift). That is, if you attempt to access the Redirection from Hell test using my proxy, each and every redirect would be a "confirm redirect" page served to the user. After about 20 pages, you'd think the user would catch on. That being said, my gemini proxy is not linked anywhere on my website (and if it were in a place I would link publically I would use robots.txt to prevent web crawlers from accessing it), so perhaps I'm not the target of this message.

I still maintain that a proxy is a direct agent of a user, and not an automated client. Proxy authors should use robots.txt on the web side to block crawlers from accessing the proxy, but proxies shouldn't have to follow robots.txt.

It's actually easier to just write your web proxy in such a way that this doesn't happen to you.

Just my two cents,
Robert "khuxkm" Miles

From khuxkm at tilde.team  Mon Nov 30 02:37:41 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Mon, 30 Nov 2020 02:37:41 +0000
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <CAFTy05a=gMsV=qNEN_JqSZxMnvW3GKtyA1jXAy0DJWfk2NfEkA@mail.gmail.com>
References: <CAFTy05a=gMsV=qNEN_JqSZxMnvW3GKtyA1jXAy0DJWfk2NfEkA@mail.gmail.com>
 <87k0u4xfp8.fsf@rwv.io>
 <Ml1olaxUU9fDMSRWdkOS2v1QuE4PMkM5dHHV2XEcH_rbLOHak4Hh5_1Qku_vn7rjA4upB2oEX1mrHajW2-E0D1iWpCxhvwpMl8DJWuitjFY=@protonmail.com>
Message-ID: <102a365366061963704b8bae3726cf87@tilde.team>

November 29, 2020 9:32 PM, "Michael Lazar" <lazar.michael22 at gmail.com> wrote:

> Is anybody currently using the certificate hash in their CGI scripts? I am very
> curious because I haven't seen many real uses of client certs in gemini thus
> far.
> 
> - Michael

I'm using the certificate hash in my Stream of Consciousness script[0], to maintain a list of allowed certificates that can post to a given stream. My planned port of a text adventure to Gemini is on hold, but such a port would likely use client certificates to keep track of what game state exists for what user.

Just my two cents,
Robert "khuxkm" Miles

[0]: https://github.com/MineRobber9000/stream-of-consciousness

From lazar.michael22 at gmail.com  Mon Nov 30 02:55:19 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sun, 29 Nov 2020 21:55:19 -0500
Subject: Heads up about a Gemini client @ 198.12.83.123
In-Reply-To: <044nxu1qwMF4iklvkcHvVZkccfhnfjARKjSIj7wG3IXUP2K9cGGUgAr3OC1ewCD6jplEaGkXr0k4cbDHalxTdn1k9ouo3naEozad7C9lZR4=@protonmail.com>
References: <20201129200810.GW1721@brevard.conman.org>
 <044nxu1qwMF4iklvkcHvVZkccfhnfjARKjSIj7wG3IXUP2K9cGGUgAr3OC1ewCD6jplEaGkXr0k4cbDHalxTdn1k9ouo3naEozad7C9lZR4=@protonmail.com>
Message-ID: <CAFTy05aMa1iiA1BWVNuK0Fb8O0gzHvwGB26vF9FU1jRXJiYxyA@mail.gmail.com>

On Sun, Nov 29, 2020 at 4:15 PM <colecmac at protonmail.com> wrote:
>
> (Resent to the list, not just spc)
>
> > 198.12.83.123
>
> ? dig -x 198.12.83.123 +short
> phlox.titmouse.org.
>
> https://phlox.titmouse.org/about.html mentions a Discordian by
> the name of "Benedict T. Eyen, the T stands for Teeth." Unfortunately
> there's no email address, so we can't contact him. Curiously, there
> is a Gemini server running on that domain, but accessing it just gives
> me Proxy Request Refused.
>
> makeworld

I'm not trying to call anyone out, but since this situation has come up on the
mailing list a few times it's helpful to look at the TLS cert.

```
openssl s_client -connect 198.12.83.123:1965
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = lignumvitae.org
verify return:1
---
Certificate chain
 0 s:/CN=lignumvitae.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
```

gemini://lignumvitae.org/ returns the same proxy error, but they're using a
Let's Encrypt cert so presumably they have a HTTPS server running too.

https://lignumvitae.org/ redirects to https://gj.libraryoferis.org/

from there, I recognized library of eris as an one of the early (and totally
awesome) gemini servers so I tried

gemini://libraryoferis.org/

There's an email address listed on that capsule.

- Michael

From sean at conman.org  Mon Nov 30 03:14:37 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 22:14:37 -0500
Subject: Heads up about a Gemini client @ 198.12.83.123
In-Reply-To: <CAFTy05aMa1iiA1BWVNuK0Fb8O0gzHvwGB26vF9FU1jRXJiYxyA@mail.gmail.com>
References: <20201129200810.GW1721@brevard.conman.org>
 <044nxu1qwMF4iklvkcHvVZkccfhnfjARKjSIj7wG3IXUP2K9cGGUgAr3OC1ewCD6jplEaGkXr0k4cbDHalxTdn1k9ouo3naEozad7C9lZR4=@protonmail.com>
 <CAFTy05aMa1iiA1BWVNuK0Fb8O0gzHvwGB26vF9FU1jRXJiYxyA@mail.gmail.com>
Message-ID: <20201130031437.GD1721@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> On Sun, Nov 29, 2020 at 4:15 PM <colecmac at protonmail.com> wrote:
> >
> > (Resent to the list, not just spc)
> >
> > > 198.12.83.123
> >
> > ? dig -x 198.12.83.123 +short
> > phlox.titmouse.org.
> >
> > https://phlox.titmouse.org/about.html mentions a Discordian by
> > the name of "Benedict T. Eyen, the T stands for Teeth." Unfortunately
> > there's no email address, so we can't contact him. Curiously, there
> > is a Gemini server running on that domain, but accessing it just gives
> > me Proxy Request Refused.
> >
> > makeworld
> 
> I'm not trying to call anyone out, but since this situation has come up on the
> mailing list a few times it's helpful to look at the TLS cert.

  It never occured to me to look at the certificate [1].

> There's an email address listed on that capsule.

  Thanks for the information.

  -spc

[1]	I had been away for hours at that point, and came back to the web
	proxy *still* going, and a much of ssh bots attempting to log onto
	the server and my automatic blocking system not fully working [2],
	so I was a bit preoccupied at the time.

[2]	Checking 0.0.0.0 and 0.0.0.0/0 are two entirely different things.


From sean at conman.org  Mon Nov 30 03:30:42 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 22:30:42 -0500
Subject: Web proxies and robots.txt (was Re: Heads up about a Gemini
 client @ 198.12.83.123)
In-Reply-To: <d04a40a820b312e7b465a21785676fce@tilde.team>
References: <20201130022518.GA1721@brevard.conman.org>
 <20201129200810.GW1721@brevard.conman.org>
 <d04a40a820b312e7b465a21785676fce@tilde.team>
Message-ID: <20201130033042.GA24194@brevard.conman.org>

It was thus said that the Great Robert khuxkm Miles once stated:
> November 29, 2020 9:25 PM, "Sean Conner" <sean at conman.org> wrote:
> 
> > It was thus said that the Great Sean Conner once stated:
> > 
> >> It's not threatening my server or anything, but who ever is responsible
> >> for the client at 198.12.83.123, your client is currently stuck in the
> >> Redirection From Hell test and has been for some time. From the length of
> >> time, it appears to be running autonomously so perhaps a leftover thread, or
> >> an autonomous client that doesn't read robots.txt, or didn't follow the spec
> >> carefully enough.
> >> 
> >> Anyway, just a heads up.
> >> 
> >> -spc
> > 
> > So the client in question was most likely a web proxy. I'm not sure what
> > site, nor the software used, but it did response to a Gemini request with
> > "53 Proxy Requet Refused" so there *is* a Gemini server there. And given
> > that it made 137,060 requests before I shut down my own server told me that
> > it was an autonomous agent that no one was watching. Usually, I may see a
> > client hit 20 or 30 times before it stops. Not this one.
> > 
> > Now granted, my server is a bit unique in that I have tests set up
> > specifically for clients to test against, and several of them involve
> > infinite redirects. And yes, that was 137,060 *unique* requests.
> > 
> > So first up, Solderpunk, if you could please add a redirection follow
> > limit to the specification and make it mandatory. You can specify some
> > two, heck, even three digit number to follow, but please, *please*, add it
> > to the specification and *not* just the best practices document to make
> > programmers aware of the issue. It seems like it's too easy to overlook
> > this potential trap (I see it often enough).
> > 
> > Second, had the proxy in question fetched robots.txt, I had this area
> > specifically marked out:
> > 
> > User-agent: *
> > Disallow: /test/redirehell
> > 
> > I have that for a reason, and had the autonomous client in question read
> > it, this wouldn't have happened in the first place. Even if you disagree
> > with this, it may be difficult to stop an autonomous agent once the user of
> > said web proxy has dropped the web connection. I don't know, I haven't
> > written a web proxy, and this is one more thing to keep in mind when writing
> > one. I think it would be easier to follow robots.txt.
> > 
> > -spc (To the person who called me a dick for blocking a web proxy---yes,
> > there *are* reasons to block them)
> 
> I recently wrote a gemini to web proxy as a simple side-project to see how
> easy it would be to create, and one thing I implemented that I feel should
> be a standard for web proxies is not handling redirects internally. If you
> tell my gemini proxy to request a page that offers a redirect (say, the
> next page link for LEO), it will send you back a small web page saying
> "hey, the site at this URL wants to send you to this other URL, do you
> want to follow that redirect or nah?" (not exact wording but you get my
> drift). That is, if you attempt to access the Redirection from Hell test
> using my proxy, each and every redirect would be a "confirm redirect" page
> served to the user. After about 20 pages, you'd think the user would catch
> on. That being said, my gemini proxy is not linked anywhere on my website
> (and if it were in a place I would link publically I would use robots.txt
> to prevent web crawlers from accessing it), so perhaps I'm not the target
> of this message.

  You, specifically, weren't the target for my last bit, but I am addressing
in general those who write webproxies for Gemini.  Your proxy's method of
handing redirects works.  I was just a bit upset that an agent out there
made 137,000 requests [1] before anyone did anything about it.

> I still maintain that a proxy is a direct agent of a user, and not an
> automated client. Proxy authors should use robots.txt on the web side to
> block crawlers from accessing the proxy, but proxies shouldn't have to
> follow robots.txt.

  I understand the argument, but I can't say I'm completely on board with it
either, because ...

> It's actually easier to just write your web proxy in such a way that this
> doesn't happen to you.

you would probably be amazed at just how often clients *don't* limit
following redirects.  Most of the time, someone is sitting there, watching
their client and stopping it after perhaps 30 seconds, fix the first
redirect issue (redirecting back to itself) only to get trapped at the next
step.

  And to think I brought this upon myself for wanting redirects in the first
place.

  -spc (How ironic)

[1]	For the record, it was NOT placing an undue burden on my server,
	just cluttering the log files.  It's only an issue when the log file
	gets to 2G in size, then logging stops for everything.

From sean at conman.org  Mon Nov 30 03:32:38 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 22:32:38 -0500
Subject: Web proxies and robots.txt (was Re: Heads up about a Gemini
 client @ 198.12.83.123)
In-Reply-To: <20201130033042.GA24194@brevard.conman.org>
References: <20201130022518.GA1721@brevard.conman.org>
 <20201129200810.GW1721@brevard.conman.org>
 <d04a40a820b312e7b465a21785676fce@tilde.team>
 <20201130033042.GA24194@brevard.conman.org>
Message-ID: <20201130033238.GB24194@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> 
> you would probably be amazed at just how often clients *don't* limit
> following redirects.  Most of the time, someone is sitting there, watching
> their client and stopping it after perhaps 30 seconds, fix the first
> redirect issue (redirecting back to itself) only to get trapped at the next
> step.

  I want to clarify that this usually happens when a new client is being
tested.  Somehow, the web proxy in question wasn't tested.

  -spc


From sean at conman.org  Mon Nov 30 04:33:43 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 29 Nov 2020 23:33:43 -0500
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <20201129181700.61EBD63C09AB@dd22736.kasserver.com>
References: <dce7cc5e-5e58-cf95-ac20-694db7c75ad4@benaaron.dev>
 <20201129181700.61EBD63C09AB@dd22736.kasserver.com>
Message-ID: <20201130043343.GD24194@brevard.conman.org>

It was thus said that the Great Ren? Wagner once stated:
> I totally agree that we need a definition of what information has to be
> passed to a CGI script by the server. Adjust scripts to honor specific
> server implementations is a no-go.

  I used RFC-3875 for the basis of my CGI support.  It defines the following
variables to be passed to the script.

	AUTH_TYPE

		Only set if a client certificate is present, and if so, I
		set this to "Certificate".  There's another server that sets
		this to "CERTIFICATE".

	CONTENT_LENGTH
	CONTENT_TYPE

		These two don't apply to Gemini, and are thus not set (which
		is allowed per the RFC).

	GATEWAY_INTERFACE

		Always set to "CGI/1.1"

	PATH_INFO

		This is only set if there's additional text past the CGI
		script in the path segment of the request.  If the CGI
		script is "/example/foo" and the request is
		
			gemini://example.net/example/foo

		then this isn't set.  If the request is

			gemini://example.net/example/foo/path/to/something

		then this would be set to

			/path/to/something

	PATH_TRANSLATED

		This is only set if there's additional text past the CGI
		script in the path segment of the request.  This is defined
		as taking the above, and mapping it to the server's document
		structure.  So, if the base directory of the site is
		
			/var/exaple.net/gemini/

		and PATH_INFO is set from the request
		
			gemini://example.net/example/foo/path/to/something

		then this would be set to
		
			/var/example.com/gemini/path/to/something

	QUERY_STRING

		Must always be set.  If no query string is defined, it's set
		to ""

	REMOTE_ADDR
	REMOTE_HOST

		I set these to the IP address of the client (allowed per the
		RFC).  An alternative I've suggested in the past is the use
		of "127.0.0.1" or "::" for these two fields.

	REMOTE_IDENT

		I don't bother with this one---no one runs ident anymore.

	REMOTE_USER

		Only set if a client certificate is present, and if so, the
		concensus seems to be to use the CN field of the subject of
		the certificate, or "" if that isn't present.

	REQUEST_METHOD

		I set this to "", as a request method isn't defined.  Most
		use "GET", which is what Gemini *is*, but personally, I feel
		"" is better as there is no method sent at all.

	SCRIPT_NAME

		If the request is

			gemini://example.net/example/foo

		Then this is set to

			/example/foo

		If the request is:

			gemini://example.net/example/foo/path/to/something

		Then this is still set to:

			/example/foo


	SERVER_NAME
	SERVER_PORT

		Set to the server name and port.

	SERVER_PROTOCOL

		I set this to "GEMINI".  

	SERVER_SOFTWARE

		Up to the server to set as it sees fit.

  And that's it as far as RFC-3875 goes.  Not much to it.  I currently
define only four Gemini specific variables (allowed by the RFC):

	GEMINI_DOCUMENT_ROOT

		Base directory of the site.

	GEMINI_SCRIPT_FILENAME

		This is the full path to the CGI script.

	GEMINI_URL_PATH

		This is the path portion of the Gemini request.

	GEMINI_URL

		This is the request as sent by the client.

  I also define some TLS variables, but those are under discussion elsewhere
on this thread.  These (the TLS and GEMINI variables) can be described in a
companion document, but the base I think should be RFC-3875.  It fits quite
well to Gemini.

  -spc


From waweic at activ.ism.rocks  Mon Nov 30 05:51:23 2020
From: waweic at activ.ism.rocks (Waweic)
Date: Mon, 30 Nov 2020 06:51:23 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
Message-ID: <7784a0d2afdf26d812b0c02e03d49549d0903610.camel@activ.ism.rocks>

I can't find the change concerning the text/gemini media type reflected
in the spec. Is there some version history which I could diff? This
would simplify things a bit.
So far, this part of the spec seems fine in my opinion, I would
disagree with said change. RFC 3986 has a section on reference
resolution (section 5) and even a pseudocode algorithm and a regex,
this should be implemented anyway. I do not think the right way to go
here is adapting the spec to mistakes people make, I rather think those
mistakes should be fixed.

RFC 3986 defines an unambigous set of valid URIs and their meaning. As
I see it, the difference between URIs and URI References is important
here. In Gemini requests, we ask for a specific, resource, so only a
URI makes sense here, complete with a scheme, authority, path and
query. This is now reflected in the spec, which I quite like!

In Gemini documents however, where we refer to different resources, we
use an URI Reference. Here, omitting the scheme has valid usecases, as
have relative URI References. This is unambiguously defined in RFC
3986, I do not see a point in adding limitations where there is no
ambiguity.

In theory, software which generates Gemini content doesn't know over
what protocol this content will be served, it may, for example, be
HTTP. Thus, it can't possibly add an explicit scheme

Furthermore, I do not know whether RFC 3986 even allows this
limitation. It may well be that this is not our decision to make,
following the RFC, although this is just speculation.


From stephane at sources.org  Mon Nov 30 08:25:31 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 30 Nov 2020 09:25:31 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
Message-ID: <20201130082531.GA4964@sources.org>

On Sun, Nov 29, 2020 at 07:38:21PM +0100,
 Solderpunk <solderpunk at posteo.net> wrote 
 a message of 42 lines which said:

> leaving existing behaviour of assuming a scheme of gemini in place
> could be considered a valid application of Postel's law.

Note that one of the reasons why the Web became so bloated is
precisely Postel's law (the robustness principle). Browsers and
servers violate the spec, these violations soon became
de-facto-mandatory-to-support and one after the other, the "unofficial
spec" became much larger than the real one.

That's one of the reasons why Postel's law is quite criticized today
<https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/>.


From caolan at caolan.uk  Mon Nov 30 09:06:29 2020
From: caolan at caolan.uk (Caolan McMahon)
Date: Mon, 30 Nov 2020 09:06:29 +0000
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <8bc79de0-47a9-5aa3-14b4-863031b3ffcf@qwertqwefsday.eu>
References: <AEC55E80-C782-4947-894A-1D8528A6A64B@caolan.uk>
 <8bc79de0-47a9-5aa3-14b4-863031b3ffcf@qwertqwefsday.eu>
Message-ID: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>

> We have the [ANN] subject tag for that I think. But that is currently used
> for both new software and new capsules. Maybe it would be an improvement to
> differentiate these two.

Sure, I'd be fine with filtering on the [ANN] tag, the filter might miss some discussion of interesting use cases, but it would catch 80% of what I'm interested in.

What do you think about guidance on what's considered on-topic for the list? And perhaps guidance on when to use subject tags? This could be a couple of sentences in the Mailman page 'about' section

Caolan

From bjorn.warmedal at gmail.com  Mon Nov 30 09:18:36 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Mon, 30 Nov 2020 10:18:36 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <20201130082531.GA4964@sources.org>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <20201130082531.GA4964@sources.org>
Message-ID: <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>

> > leaving existing behaviour of assuming a scheme of gemini in place
> > could be considered a valid application of Postel's law.
>
> Note that one of the reasons why the Web became so bloated is
> precisely Postel's law (the robustness principle). Browsers and
> servers violate the spec, these violations soon became
> de-facto-mandatory-to-support and one after the other, the "unofficial
> spec" became much larger than the real one.

I agree with the general principle that you should be conservative
(even draconian) in your implementation. Stick to the specification,
and keep the specification concise and unambiguous. If you receive
requests or answers that don't adhere to the specification these
should be treated as errors. A liberal or lenient interpretation of
the spec leads to problems down the line.

On the topic of explicit scheme in gemtext links I have one opinion
and one question.

Opinion: when cross-hosting between the web and geminispace I think
the publisher can reasonably be expected to run a search-replace. If I
host on both https://tilde.team/~ew0k/ and gemini://tilde.team/~ew0k/
I can easily make sure to replace that particular line in links. I see
that there may be an issue if I link to someone else who also
cross-posts, though... I'm willing to admit that the scheme should NOT
be required in gemtext links.

Question: How does this work with relative links in gemtext documents?

Cheers,
ew0k

From sean at conman.org  Mon Nov 30 10:07:23 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 30 Nov 2020 05:07:23 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <20201130082531.GA4964@sources.org>
 <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>
Message-ID: <20201130100723.GE24194@brevard.conman.org>

It was thus said that the Great Bj?rn W?rmedal once stated:
> On the topic of explicit scheme in gemtext links I have one opinion
> and one question.
> 
> Opinion: when cross-hosting between the web and geminispace I think
> the publisher can reasonably be expected to run a search-replace. If I
> host on both https://tilde.team/~ew0k/ and gemini://tilde.team/~ew0k/
> I can easily make sure to replace that particular line in links. I see
> that there may be an issue if I link to someone else who also
> cross-posts, though... I'm willing to admit that the scheme should NOT
> be required in gemtext links.
> 
> Question: How does this work with relative links in gemtext documents?

  Luke Emmet mentioned this, but I think it got lost.  In text/gemini, the
following are all legal links:

=> gemini://example.net/path/foo.gemini Absolute URL - fully specified
=> //example.net/path/foo.gemini        relative URL - no scheme
=> /path/foo.gemini                     relative URL - no host
=> foo.gemini                           relative URL - no path
=> ../path/foo.gemini                   relative URL - relative

  It is up to the client to resolve these, using rules specified in RFC-3986
section 5.2.

  What Solderpunk just changed was the request *TO* a Gemini server.  It
used to be the following two forms were allowed when making a request to a
Gemini server:

gemini://example.net/path/foo.gemini
//example.net/path/foo.gemini

  This was confusing, and so the schemeless format is no longer allowed when
making a request to a Gemini server.  The only form that is now allowed when
making a request to a Gemini server is:

gemini://example.net/path/foo.gemini

  -spc

  

From etienne at depar.is  Mon Nov 30 11:56:40 2020
From: etienne at depar.is (=?utf-8?Q?=C3=89tienne?= Deparis)
Date: Mon, 30 Nov 2020 12:56:40 +0100
Subject: [ANN] Emacs org-mode to gemini export back-end
Message-ID: <87k0u32h3b.fsf@depar.is>

Hi all

I?ve just pushed a first version of an org-mode export back-end for
gemini. It is based on the Markdown export back-end, but also requires
some functions from the Ascii back-end, both being provided by default
by org-mode.

The canonical repository is at https://git.umaneti.net/ox-gmi.el/
however, I also open a mirror on https://github.com/milouse/ox-gmi.el if
you prefer.

As always, all feedbacks will be welcomed, per email or on github :)

Have a nice day,

--
?tienne

gemini://alltext.umaneti.net/

From khuxkm at tilde.team  Mon Nov 30 12:45:47 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Mon, 30 Nov 2020 12:45:47 +0000
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <20201130100723.GE24194@brevard.conman.org>
References: <20201130100723.GE24194@brevard.conman.org>
 <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar> <20201130082531.GA4964@sources.org>
 <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>
Message-ID: <3ee1a9ea455b073da77d75492a604308@tilde.team>

November 30, 2020 5:07 AM, "Sean Conner" <sean at conman.org> wrote:

> Luke Emmet mentioned this, but I think it got lost. In text/gemini, the
> following are all legal links:
> 
> => gemini://example.net/path/foo.gemini Absolute URL - fully specified
> => //example.net/path/foo.gemini relative URL - no scheme
> => /path/foo.gemini relative URL - no host
> => foo.gemini relative URL - no path
> => ../path/foo.gemini relative URL - relative
> 
> It is up to the client to resolve these, using rules specified in RFC-3986
> section 5.2.
> 
> What Solderpunk just changed was the request *TO* a Gemini server. It
> used to be the following two forms were allowed when making a request to a
> Gemini server:
> 
> gemini://example.net/path/foo.gemini
> //example.net/path/foo.gemini
> 
> This was confusing, and so the schemeless format is no longer allowed when
> making a request to a Gemini server. The only form that is now allowed when
> making a request to a Gemini server is:
> 
> gemini://example.net/path/foo.gemini
> 
> -spc

Not so. From Solderpunk's email that started the whole chain (emphasis mine):

> Previously, Gemini requests *and links in text/gemini documents* could both omit the scheme, and servers/clients were expected to add an implicit scheme of "gemini".  This has been changed and now schemes are mandatory in URLs in *both* these contexts.

Correct me if I'm wrong (perhaps this is just an ambiguous statement I didn't pick up on), but the implication I got is that links now also need the gemini scheme. Also from Solderpunk's email (again, emphasis mine):

> Authors of Gemini content or software which generates Gemini content MUST add explicit schemes to *any schemeless links*.

Again, if all that was changed was the request side of things, this wouldn't need to be in the email. I'm all for getting rid of the ambiguity of schemeless URLs in requests, but not for link lines.

Just my two cents,
Robert "khuxkm" Miles

From jmcbray at carcosa.net  Mon Nov 30 14:51:01 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Mon, 30 Nov 2020 09:51:01 -0500
Subject: Does TOFU actually work?
In-Reply-To: <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com> (Ben
 Burwell's message of "Sat, 28 Nov 2020 10:14:34 -0500")
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
 <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
Message-ID: <87sg8q7vai.fsf@dorothy.carcosa.net>

"Ben Burwell" <gemini at benburwell.com> writes:
> On 2020-11-28 at 09:28 -05:00, Emilis <emilis at emilis.net> wrote:
>> How would TOFU work for someone out of a country that firewalls the 
>> internet and can replace all self-signed certificates for port 1965 on 
>> the fly?

> You're right - it wouldn't protect the privacy of people under that
> scenario (assuming the state actor is sufficiently motivated to do this
> interception/replacement under TOFU constraints).
>
> I'm not sure what a good solution to this is.

One option would be a 'certificate observatory', where various clients
around the world submit the fingerprints they receive for various hosts.
You can then compare the cert you receive with the consensus of the
observatory. This doesn't protect you from MITM, but it makes you aware
of it.

If you need to *actually* access content without a MITM, you'll need to
use TOR or a VPN. That's still true under the CA system; it's just more
obvious because your connections fail verification.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From cowan at ccil.org  Mon Nov 30 15:07:30 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 30 Nov 2020 10:07:30 -0500
Subject: Postel's Law
In-Reply-To: <20201130082531.GA4964@sources.org>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <20201130082531.GA4964@sources.org>
Message-ID: <CAD2gp_SVxStz_WWsxoxfAJZPgkdSs55gVGA0cXWYTB87qxWoOQ@mail.gmail.com>

On Mon, Nov 30, 2020 at 3:28 AM Stephane Bortzmeyer <stephane at sources.org>
wrote:

Note that one of the reasons why the Web became so bloated is
> precisely Postel's law (the robustness principle). Browsers and
> servers violate the spec, these violations soon became
> de-facto-mandatory-to-support and one after the other, the "unofficial
> spec" became much larger than the real one.
>

Not that I was there at the time, but I firmly believe that Postel's law
has always meant "Don't exploit obscure features of the protocol when
sending; but do be prepared for them, as well as for outright errors, when
receiving", and so has nothing to do with trying to make sense of received
but invalid transmissions.  RFC 1122 (1989) section 1.1.2 agrees with this
interpretation:

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability:

                "Be liberal in what you accept, and
                 conservative in what you send"

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption
         will lead to suitable protective design, although the most
         serious problems in the Internet have been caused by
         unenvisaged mechanisms triggered by low-probability events;
         mere human malice would never have taken so devious a course!

         Adaptability to change must be designed into all levels of
         Internet [...] software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged [...],
         but it must not cause a failure.

         The second part of the principle is almost as important:
         software on other hosts may contain deficiencies that make it
         unwise to exploit legal but obscure protocol features.  It is
         unwise to stray far from the obvious and simple, lest untoward
         effects result elsewhere.  A corollary of this is "watch out
         for misbehaving hosts"; host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility.

I think that implementers have in effect misunderstood the phrase "deal
with every conceivable error" as if it meant "accept every conceivable
error and try to act on it", but the context makes it clear (to me, at
least) that what is meant is "not crash on any conceivable error".


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Almost all theorems are true, but almost all proofs have bugs.
        --Paul Pedersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/b8d15260/attachment.htm>

From cowan at ccil.org  Mon Nov 30 15:19:47 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 30 Nov 2020 10:19:47 -0500
Subject: Does TOFU actually work?
In-Reply-To: <87sg8q7vai.fsf@dorothy.carcosa.net>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
 <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
 <87sg8q7vai.fsf@dorothy.carcosa.net>
Message-ID: <CAD2gp_SDx-Yb5aPdu7UfEG_6Y90LOjOyCxpojLD+W05xp4UEJA@mail.gmail.com>

On Mon, Nov 30, 2020 at 9:51 AM Jason McBrayer <jmcbray at carcosa.net> wrote:

> "Ben Burwell" <gemini at benburwell.com> writes:
> > On 2020-11-28 at 09:28 -05:00, Emilis <emilis at emilis.net> wrote:
> >> How would TOFU work for someone out of a country that firewalls the
> >> internet and can replace all self-signed certificates for port 1965 on
> >> the fly?
>

A more practical version of this scenario is a MITMing corporate firewall.
In general, there is no right of privacy for what you do using your
employer's equipment, at least in the U.S.

> One option would be a 'certificate observatory', where various clients
> around the world submit the fingerprints they receive for various hosts.
> You can then compare the cert you receive with the consensus of the
> observatory. This doesn't protect you from MITM, but it makes you aware
> of it.
>

Unless, of course, the MITMer is aware of the observatory and alters what
you receive from it.

In general, if someone controls *all* your connections to the outside
world, they can make you believe whatever they want, and crypto doesn't
help in the slightest.  The reason the Great Firewall of China doesn't
block or MITM outbound VPN connections is that China doesn't want it to:
VPN connections are very expensive in China, so they are generally used
only by foreigners there on business, which China has no desire to alienate
and who are unlikely to have Chinese political motives.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Mos Eisley spaceport.  You will never see a more wretched hive of scum
and villainy --unless you watch the Jerry Springer Show.
        --georgettesworld.com



> If you need to *actually* access content without a MITM, you'll need to
> use TOR or a VPN. That's still true under the CA system; it's just more
> obvious because your connections fail verification.
>
> --
> +-----------------------------------------------------------+
> | Jason F. McBrayer                    jmcbray at carcosa.net  |
> | A flower falls, even though we love it; and a weed grows, |
> | even though we do not love it.            -- Dogen        |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/59d3856d/attachment-0001.htm>

From anothersms at gmail.com  Mon Nov 30 14:57:20 2020
From: anothersms at gmail.com (=?utf-8?Q?Nicol=C3=B2?= Balzarotti)
Date: Mon, 30 Nov 2020 15:57:20 +0100
Subject: Does TOFU actually work?
In-Reply-To: <87sg8q7vai.fsf@dorothy.carcosa.net>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
 <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
 <87sg8q7vai.fsf@dorothy.carcosa.net>
Message-ID: <87360qzycv.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>

Jason McBrayer <jmcbray at carcosa.net> writes:

> One option would be a 'certificate observatory', where various clients
> around the world submit the fingerprints they receive for various hosts.
> You can then compare the cert you receive with the consensus of the
> observatory. This doesn't protect you from MITM, but it makes you aware
> of it.

If there's a MITM, you cannot be sure the observatory is trusted just by
using TOFU.

From waweic at activ.ism.rocks  Mon Nov 30 17:33:31 2020
From: waweic at activ.ism.rocks (Waweic)
Date: Mon, 30 Nov 2020 18:33:31 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <20201130100723.GE24194@brevard.conman.org>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <20201130082531.GA4964@sources.org>
 <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>
 <20201130100723.GE24194@brevard.conman.org>
Message-ID: <bcd46da1627118171aa52429be63332ab5f30098.camel@activ.ism.rocks>

Hi, if I am not mistaken there are some errors in your list of valid
URI References.

> => gemini://example.net/path/foo.gemini Absolute URL - fully
> specified
> => //example.net/path/foo.gemini??????? relative URL - no scheme
> => /path/foo.gemini???????????????????? relative URL - no host
> => foo.gemini?????????????????????????? relative URL - no path
> => ../path/foo.gemini?????????????????? relative URL - relative

First of, these are not URLs, RFC 3986 specifies URIs and URI
References. As we are speaking about links, we need to speak about URI
References rather then URLs or URIs. Note that this does not apply to
requests, there we speak about URIs.

So instead, this would be the terminology I would use:

=> gemini://example.net/path/foo.gemini URI Reference
=> //example.net/path/foo.gemini        relative URI reference - no
scheme, absolute path
=> /path/foo.gemini                     relative URI Reference - no
host, absolute path
=> foo.gemini                           relative URI Reference - no
host, relative path (Note that this is not a reference without a
specified path, for that, it would have to begin with //.)
=> ../path/foo.gemini                   relative URI Reference - no
host, relative path

The following examples would also be valid:

=> gemini://example.net			URI Reference - empty path
=> //example.net			relative URI Reference - no
scheme, empty path
=> /					relative URI Reference - no
host, absolute path

Looking at the ABNF in Appendix A of RFC 3986, this gets pretty clear.
IMO the current solution is pretty good, requiring a URI for requests
and a URI Reference for links, this is as it should be.

If I read the spec change email correctly, now text/gemini documents
also require full URIs in the links, I don't think of this as a good
idea


From waweic at activ.ism.rocks  Mon Nov 30 17:45:23 2020
From: waweic at activ.ism.rocks (Waweic)
Date: Mon, 30 Nov 2020 18:45:23 +0100
Subject: Suggestion: ABNF in spec
Message-ID: <af563aebbcfb9d1d065ed0cbc44e0a361a0b49d5.camel@activ.ism.rocks>

Hi Geminauts,

in the past, we've had discussions about possible amiguities in the
spec. To resolve these abiguities, how would you think about adding an
appendix to the spec, containing ABNF for the protocol and the
text/gemini media type? This wouldn't mean any additional complexity
for the implementations, but would make the spec somewhat longer and
possibly harder to read. I would also think that this removal of any
ambiguity might help with a possible later standardization process.

How would you think about this? This isn't anything close to my heart,
I just thought of it as something nice-to-have.

Greetings,

Waweic


From easrng at gmail.com  Mon Nov 30 18:05:14 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Mon, 30 Nov 2020 13:05:14 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <bcd46da1627118171aa52429be63332ab5f30098.camel@activ.ism.rocks>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <20201130082531.GA4964@sources.org>
 <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>
 <20201130100723.GE24194@brevard.conman.org>
 <bcd46da1627118171aa52429be63332ab5f30098.camel@activ.ism.rocks>
Message-ID: <CAEzvDCWRq_h01+bjobxcGXgZ1DDRPOvQHWRgyVS5jGrLK+dCGA@mail.gmail.com>

On Monday, November 30, 2020, Waweic <waweic at activ.ism.rocks> wrote:

> The following examples would also be valid:
>
> => gemini://example.net                 URI Reference - empty path
> => //example.net                        relative URI Reference - no
> scheme, empty path
> => /                                    relative URI Reference - no
> host, absolute path

What would
=> .                                    relative URI Reference - no
host, relative path
do? Reload the current page?


-- 
? <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/7f1f13c6/attachment.htm>

From cage-dev at twistfold.it  Mon Nov 30 18:17:41 2020
From: cage-dev at twistfold.it (cage)
Date: Mon, 30 Nov 2020 19:17:41 +0100
Subject: [ANN] Emacs org-mode to gemini export back-end
In-Reply-To: <87k0u32h3b.fsf@depar.is>
References: <87k0u32h3b.fsf@depar.is>
Message-ID: <20201130181741.GA2929@kurosawa.casa.net>

On Mon, Nov 30, 2020 at 12:56:40PM +0100, ?tienne Deparis wrote:
> Hi all

Hi!

> I?ve just pushed a first version of an org-mode export back-end for
> gemini. It is based on the Markdown export back-end, but also requires
> some functions from the Ascii back-end, both being provided by default
> by org-mode.

Wow, this  is just  great! I  already use org-mode  to export  my html
site, i could try to do the same in gemini format! :)

Any change this could be added to "official" org package?

Anyway, thank you for writing this! :)

Bye!
C.

From waweic at activ.ism.rocks  Mon Nov 30 18:25:28 2020
From: waweic at activ.ism.rocks (Waweic)
Date: Mon, 30 Nov 2020 19:25:28 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <CAEzvDCWRq_h01+bjobxcGXgZ1DDRPOvQHWRgyVS5jGrLK+dCGA@mail.gmail.com>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <20201130082531.GA4964@sources.org>
 <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>
 <20201130100723.GE24194@brevard.conman.org>
 <bcd46da1627118171aa52429be63332ab5f30098.camel@activ.ism.rocks>
 <CAEzvDCWRq_h01+bjobxcGXgZ1DDRPOvQHWRgyVS5jGrLK+dCGA@mail.gmail.com>
Message-ID: <5800438132231261414032917a777f5312ac1125.camel@activ.ism.rocks>

> What would
> => .??????????????????????????????????? relative URI Reference - no
> host, relative path
> do? Reload the current page?

If I am not mistaken, it should load the current directory.

So if you are currently at ```gemini://example.net/a/b/c.gmi```

It would read ```gemini://example.net/a/b/.``` which would be
normalized as ```gemini://example.net/a/b/```

In theory, it should be possible to have an empty path as a URI
Reference, or an empty path with a query and / or a fragment. I don't
think it's possible to have this situation in Gemini.


From colecmac at protonmail.com  Mon Nov 30 18:27:15 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 30 Nov 2020 18:27:15 +0000
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <7784a0d2afdf26d812b0c02e03d49549d0903610.camel@activ.ism.rocks>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <7784a0d2afdf26d812b0c02e03d49549d0903610.camel@activ.ism.rocks>
Message-ID: <CVZyUasQ8Mj3bjJbT2dIYjLpLA2qBVsEG4u88pAslzUR0zc-XsRckPpksvinkT1jj5r07E9kH7CaVCPHqW4Y3iOiPA3axfZkrS3vZXmLLz8=@protonmail.com>

On Monday, November 30, 2020 12:51 AM, Waweic <waweic at activ.ism.rocks> wrote:

> I can't find the change concerning the text/gemini media type reflected
> in the spec. Is there some version history which I could diff? This
> would simplify things a bit.

Solderpunk made a git repo a while back...

? curl -sSL https://lists.orbitalfox.eu/archives/gemini/2020.txt.gz | gzip -dc | grep 'git://'
git clone git://gemini.circumlunar.space/gemini-site


Ah, there it is. If you clone that you'll get the full site, including the spec changes.
The scheme change is commit e7b5c52. I've attached the diff for easy viewing as well.

The important part is that when describing links lines in section 5.4.2, this change
was made:

-* <URL> is a URL, which may be absolute or relative.  If the URL does not include a scheme, a scheme of gemini:// is implied.
+* <URL> is a URL, which may be absolute or relative.

Two things:

As other emails have mentioned, this should be a URI reference,
not a URL. And if a scheme of 'gemini' is not there, it SHOULD be
implied. But this is already covered by the URI spec, afaik.

makeworld
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scheme_change.diff
Type: text/x-patch
Size: 3649 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/83ec537b/attachment-0001.bin>

From solene at perso.pw  Mon Nov 30 18:43:36 2020
From: solene at perso.pw (Solene Rapenne)
Date: Mon, 30 Nov 2020 19:43:36 +0100
Subject: Gemini over i2p or tor
Message-ID: <20201130194336.4908db19@kongroo.lan>

Hello,

I'm new to gemini and I was looking to host my gemini server behind
i2p (or as a Tor hidden service, that would work the same).

I wrote a server that doesn't do TLS but uses a relayd daemon in
front of it to take care about TLS the right way.

I've read that TLS is mandatory, the only configuration I can imagine
for gemini over i2p/tor would be to expose my relayd over these
networks, but then the TLS hostname won't match the hostname in the
URI. I'm not even sure this would work for all clients.

Is there a solution for this or am I supposed to accept non matching
certificates for this use case?

Regards
Sol?ne

From seirdy at seirdy.one  Mon Nov 30 18:53:39 2020
From: seirdy at seirdy.one (Rohan Kumar)
Date: Mon, 30 Nov 2020 10:53:39 -0800
Subject: Does TOFU actually work?
In-Reply-To: <87sg8q7vai.fsf@dorothy.carcosa.net>
References: <aa2906c1-8834-ba30-5649-cd5bee60366e@emilis.net>
 <8e5f15f2-946f-40e3-bbe5-b5418c701b74@www.fastmail.com>
 <87sg8q7vai.fsf@dorothy.carcosa.net>
Message-ID: <20201130185339.ewxxba7zjs7rtbe7@rkumar-dekstop>

Warning: uninformed opinions follow; feedback welcome.

On Mon, Nov 30, 2020 at 09:51:01AM -0500, Jason McBrayer wrote:
>One option would be a 'certificate observatory', where various clients 
>around the world submit the fingerprints they receive for various 
>hosts. You can then compare the cert you receive with the consensus of 
>the observatory. This doesn't protect you from MITM, but it makes you 
>aware of it.

There are multiple solutions, each with different sets of flaws. An 
observatory's flaws don't necessarily signify that it's a bad idea; they 
could also signify that it shouldn't be out *only* idea.

An idea related to an observatory: I think that it would be awesome if 
crawlers like GUS saved certs and allowed people to search through them 
in a variety of ways or over a variety of protocols: Tor, i2p, 
downloading limited dump over bittorrent...I'm spitballing 
MITM-resistant protocols. I don't know the "best" ways to go about this 
while avoiding the negative privacy-related consequences of opening up 
the index, but offering cert-checking over multiple other MITM-resistent 
protocols could help vulnerable users who'd like to be extra careful 
during the first connection.

Hmm...Gemini-over-i2p actually sounds *awesome*, especially since the 
tiny footprint of Gemini pages could pair well with its speed loss.
/Seirdy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/425ebff1/attachment.sig>

From johann at qwertqwefsday.eu  Mon Nov 30 18:55:43 2020
From: johann at qwertqwefsday.eu (Johann Galle)
Date: Mon, 30 Nov 2020 19:55:43 +0100
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
References: <AEC55E80-C782-4947-894A-1D8528A6A64B@caolan.uk>
 <8bc79de0-47a9-5aa3-14b4-863031b3ffcf@qwertqwefsday.eu>
 <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
Message-ID: <d5910f62-aa0c-307b-fa7b-c07f8fe6e77b@qwertqwefsday.eu>

At 2020-11-30T10:06+01:00, Caolan McMahon wrote:
 > What do you think about guidance on what's considered on-topic for the list?

As the current "About" information says that the list is about gemini, I think
it is as well about new capsules, new software as about protocol discussion.
Although I would consider protocol decision the normal thing to be found here.

 > And perhaps guidance on when to use subject tags?

I could not find it last time, but the tag was "formally" introduced here:
<https://lists.orbitalfox.eu/archives/gemini/2020/000748.html>
I hope that answers some questions.

---
You can verify the digital signature on this email with the public key
available through web key discovery. Try `gpg --locate-keys ...`

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/618eb502/attachment.sig>

From cage-dev at twistfold.it  Mon Nov 30 19:20:41 2020
From: cage-dev at twistfold.it (cage)
Date: Mon, 30 Nov 2020 20:20:41 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <7784a0d2afdf26d812b0c02e03d49549d0903610.camel@activ.ism.rocks>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
 <7784a0d2afdf26d812b0c02e03d49549d0903610.camel@activ.ism.rocks>
Message-ID: <20201130192041.GA6675@kurosawa.casa.net>

On Mon, Nov 30, 2020 at 06:51:23AM +0100, Waweic wrote:

Hi!

> I can't find the change concerning the text/gemini media type reflected
> in the spec. Is there some version history which I could diff? This
> would simplify things a bit.

Sure!

https://lists.orbitalfox.eu/archives/gemini/2020/002428.html

Hope this was what you was looking for! :)

Bye!
C.

From solderpunk at posteo.net  Mon Nov 30 19:05:21 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 30 Nov 2020 20:05:21 +0100
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
Message-ID: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>

On Mon Nov 30, 2020 at 10:06 AM CET, Caolan McMahon wrote:

> > We have the [ANN] subject tag for that I think. But that is currently used
> > for both new software and new capsules. Maybe it would be an improvement to
> > differentiate these two.
>
> Sure, I'd be fine with filtering on the [ANN] tag, the filter might miss
> some discussion of interesting use cases, but it would catch 80% of what
> I'm interested in.
>
> What do you think about guidance on what's considered on-topic for the
> list? And perhaps guidance on when to use subject tags? This could be a
> couple of sentences in the Mailman page 'about' section

I am actually extremely open to the idea of splitting the list into
several separate lists, as commonly seen in large software projects like
operating systems.  Something like:

* gemini-users: for everyday Gemini users without any special interest
  in the technical side of things.  Announcements of new capsules,
  projects like aggregators and "gemrings", authorship conventions,
  advocacy/outreach, etc.  Maybe announcements of initial releases of
  new user-oriented software.  Probably the busiest list?
* gemini-dev: for people authoring Gemini software.  Discussion of
  technical best practices, etc.
* gemini-admin: for people running Gemini servers.  Do we actually need
  this?  Probably low traffic, for sharing e.g. IP addresses of
  misbehaving clients.
* gemini-spec: for spec finalisation.  Ideally low traffic, limited
  membership, guaranteed in advance to be permanently set read-only
  within a few months of creation.
* gemini-announce: very low traffic list only I can post to with
  important announcements.

How do people feel about this?  I don't know how the list hosts feel so
can't guarantee this is possible, but I'm very happy to make enquires if
there's broad support for this.  I for one think it's a good idea.  I
know multiple people who have unsubscribed from this list after heavy
early involvement because it's just become too much to follow.

Cheers,
Solderpunk

From solderpunk at posteo.net  Mon Nov 30 19:22:02 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 30 Nov 2020 20:22:02 +0100
Subject: Registering GEMINI scheme
In-Reply-To: <20201129001019.GA1392@localhost.fios-router.home>
Message-ID: <C7GUCFYGUKZP.SKPH2U88LKXA@stilgar>

On Sun Nov 29, 2020 at 1:10 AM CET,  wrote:

> solderpunk: What do you think? Are you willing to work on this?

I am, but I think it's too soon.  I am hoping to use time off at the end
of December to work through the mailing list backlog and then finalise
the spec.  One that's done, submitting it to IETF/IANA etc. can be a
goal for 2021.

Cheers,
Solderpunk


From cowan at ccil.org  Mon Nov 30 19:44:25 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 30 Nov 2020 14:44:25 -0500
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
References: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
 <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
Message-ID: <CAD2gp_S0vz5GTtoV0r76aRCV_T4MYx5VA9f7JnX_QTW_8dDsPQ@mail.gmail.com>

On Mon, Nov 30, 2020 at 2:26 PM Solderpunk <solderpunk at posteo.net> wrote:

* gemini-spec: for spec finalisation.  Ideally low traffic, limited
>   membership, guaranteed in advance to be permanently set read-only
>   within a few months of creation.
>

If you don't have an open(able) list, further spec errors similar to
the "gemini://" issue and schemelessness will never come to your
attention.  It's one thing to have a feature freeze, but supposing there
will never be any errata is to ask too much of human spec writers. (I am
one, and I know.)  Even RFCs are frozen in a purely textual sense, but they
can be superseded as a whole or in part, and there is an out-of-band formal
errata mechanism.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Clear?  Huh!  Why a four-year-old child could understand this report.
Run out and find me a four-year-old child.  I can't make head or tail
out of it.        --Rufus T. Firefly on government reports
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/136038a8/attachment-0001.htm>

From cowan at ccil.org  Mon Nov 30 20:15:59 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 30 Nov 2020 15:15:59 -0500
Subject: What should I do for Geminiworld?
Message-ID: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>

Gemini work is nowhere near top priority for me because it's not a
responsibility, but I'd like to pay the community back a bit and these are
the ideas that come to mind:

1) Write (and possibly host) a Project Gutenberg server that will allow you
to search PG's plain-text etexts and serve them up.  This would provide
large amounts of (admittedly non-unique) content in Geminispace.  I've done
some preliminary work on this.

2) Write (and not host) a server front-end that provides cert-controlled
access to a capsule or portions thereof.  Currently I think only Molly
Brown supports this facility, but this facility would allow someone wanting
to provide such private support to run any Gemini server as long as it was
not directly accessible from the Internet and then aim the front end at
it.  I have a good idea how this would work, but haven't done any
preliminary work yet.

Preferences, suggested project names, comments?



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Possession is said to be nine points of the law,
but that's not saying how many points the law might have.
        --Thomas A. Cowan (law professor and my father)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/06638bbf/attachment.htm>

From sario528 at ctrl-c.club  Mon Nov 30 20:26:30 2020
From: sario528 at ctrl-c.club (sario528 at ctrl-c.club)
Date: Mon, 30 Nov 2020 15:26:30 -0500
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <mailman.396.1606765480.476.gemini@lists.orbitalfox.eu>
References: <mailman.396.1606765480.476.gemini@lists.orbitalfox.eu>
Message-ID: <20201130202630.GA12833@ctrl-c.club>

> I am actually extremely open to the idea of splitting the list into
> several separate lists, as commonly seen in large software projects like
> operating systems.  Something like:
> 
> * gemini-users: for everyday Gemini users without any special interest
>   in the technical side of things.  Announcements of new capsules,
>   projects like aggregators and "gemrings", authorship conventions,
>   advocacy/outreach, etc.  Maybe announcements of initial releases of
>   new user-oriented software.  Probably the busiest list?
> * gemini-dev: for people authoring Gemini software.  Discussion of
>   technical best practices, etc.
> * gemini-admin: for people running Gemini servers.  Do we actually need
>   this?  Probably low traffic, for sharing e.g. IP addresses of
>   misbehaving clients.
> * gemini-spec: for spec finalisation.  Ideally low traffic, limited
>   membership, guaranteed in advance to be permanently set read-only
>   within a few months of creation.
> * gemini-announce: very low traffic list only I can post to with
>   important announcements.
> 
> How do people feel about this?  I don't know how the list hosts feel so
> can't guarantee this is possible, but I'm very happy to make enquires if
> there's broad support for this.  I for one think it's a good idea.  I
> know multiple people who have unsubscribed from this list after heavy
> early involvement because it's just become too much to follow.
> 
> Cheers,
> Solderpunk

I am very much in support of this idea. I recently switched to the
digest format to reduce the number of incoming messages, but that has
it's own issues. 

Sario

From sean at conman.org  Mon Nov 30 20:32:00 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 30 Nov 2020 15:32:00 -0500
Subject: What should I do for Geminiworld?
In-Reply-To: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
Message-ID: <20201130203200.GF24194@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> 
> 2) Write (and not host) a server front-end that provides cert-controlled
> access to a capsule or portions thereof.  Currently I think only Molly
> Brown supports this facility, 

  GLV-1.12556 also has this capability if I understand you
correctly---protect different portions of a Gemini server with different
client certificates.  Or are you talking about something different?

  -spc (An example of what you want would be nice)

From easrng at gmail.com  Mon Nov 30 20:33:03 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Mon, 30 Nov 2020 15:33:03 -0500
Subject: Gemini over i2p or tor
In-Reply-To: <20201130194336.4908db19@kongroo.lan>
References: <20201130194336.4908db19@kongroo.lan>
Message-ID: <CAEzvDCXWA+jN=YGGTWtzjEV6rqq4CoMND7z-J2dvQeFjoYiVLA@mail.gmail.com>

>
> but then the TLS hostname won't match the hostname in the URI
>
Gemini uses TOFU (Trust on First Use) with self signed certs for TLS, so
you can make a TLS cert for your onion/i2p name.


-- 
? <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/3f9b908c/attachment.htm>

From sean at conman.org  Mon Nov 30 21:27:24 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 30 Nov 2020 16:27:24 -0500
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <3ee1a9ea455b073da77d75492a604308@tilde.team>
References: <20201130100723.GE24194@brevard.conman.org>
 <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar> <20201130082531.GA4964@sources.org>
 <CAJScK0+WAaEBaokDa_U7tu5kMU5fyDC+6FWa+pcQtbnCOX1X9g@mail.gmail.com>
 <3ee1a9ea455b073da77d75492a604308@tilde.team>
Message-ID: <20201130212724.GG24194@brevard.conman.org>

It was thus said that the Great Robert khuxkm Miles once stated:
> November 30, 2020 5:07 AM, "Sean Conner" <sean at conman.org> wrote:
> 
> > What Solderpunk just changed was the request *TO* a Gemini server. It
> > used to be the following two forms were allowed when making a request to a
> > Gemini server:
> > 
> > gemini://example.net/path/foo.gemini
> > //example.net/path/foo.gemini
> > 
> > This was confusing, and so the schemeless format is no longer allowed when
> > making a request to a Gemini server. The only form that is now allowed when
> > making a request to a Gemini server is:
> > 
> > gemini://example.net/path/foo.gemini
> > 
> Not so. From Solderpunk's email that started the whole chain (emphasis
> mine):
> 
> > Previously, Gemini requests *and links in text/gemini documents* could
> > both omit the scheme, and servers/clients were expected to add an
> > implicit scheme of "gemini".  This has been changed and now schemes are
> > mandatory in URLs in *both* these contexts.
> 
> Correct me if I'm wrong (perhaps this is just an ambiguous statement I
> didn't pick up on), but the implication I got is that links now also need
> the gemini scheme. Also from Solderpunk's email (again, emphasis mine):

  No, you are right, I misread his email.  I personally think he made a
mistake here in removing relative links (which include schemeless links)
from text/gemini.

  -spc


From emilis at emilis.net  Mon Nov 30 21:57:50 2020
From: emilis at emilis.net (Emilis)
Date: Mon, 30 Nov 2020 23:57:50 +0200
Subject: What should I do for Geminiworld?
In-Reply-To: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
Message-ID: <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>

Both of them sound awesome.


On the Gutenberg: could you also split the books into smaller pages (a 
couple of screens length)?

A few years ago I made a website which served full book text in a single 
HTML page and had a tiny script which remembered the scroll position 
(saved it in a cookie).

What I learned from the project:

1. Just scrolling was more comfortable for reading than paging on my 
smartphone.
2. You can return to a middle of a book after ~a year and continue 
reading from the saved position without a problem.

Since cookies, JS and scroll positions do not work with Gemini, smaller 
pages could serve the same function.

Side question: has anyone tried to hack something Gemini-related on 
e-book readers?


On 11/30/20 10:15 PM, John Cowan wrote:
> Gemini work is nowhere near top priority for me because it's not a 
> responsibility, but I'd like to pay the community back a bit and these 
> are the ideas that come to mind:
>
> 1) Write (and possibly host) a Project Gutenberg server that will 
> allow you to search PG's plain-text etexts and serve them up.? This 
> would provide large amounts of (admittedly non-unique) content in 
> Geminispace. I've done some preliminary work on this.
>
> 2) Write (and not host) a server front-end that provides 
> cert-controlled access to a capsule or portions thereof.? Currently I 
> think?only Molly Brown supports this facility, but this facility would 
> allow someone wanting to provide such private support to run any 
> Gemini server as long as it was not directly accessible from the 
> Internet and then aim the front end at it.? I have a good idea how 
> this would work, but haven't done any preliminary work yet.
>
> Preferences, suggested project names, comments?
>
>
>
> John Cowan http://vrici.lojban.org/~cowan 
> <http://vrici.lojban.org/~cowan> cowan at ccil.org <mailto:cowan at ccil.org>
> Possession is said to be nine points of the law,
> but that's not saying how many points the law might have.
> ? ? ? ? --Thomas A. Cowan (law professor and my father)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/3134ab2c/attachment.htm>

From solderpunk at posteo.net  Mon Nov 30 22:03:52 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 30 Nov 2020 23:03:52 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <20201130212724.GG24194@brevard.conman.org>
Message-ID: <C7GXSC9EV6EY.372KD0YF3FR29@stilgar>

On Mon Nov 30, 2020 at 10:27 PM CET, Sean Conner wrote:

> No, you are right, I misread his email. I personally think he made a
> mistake here in removing relative links (which include schemeless links)
> from text/gemini.

Oh, gosh darn it.  I obviously didn't mean to do that.  This is what I
get for trying to squeeze spec changes into small slices of free time.
Sorry, everyone.  I will fix this tomorrow.

Cheers,
Solderpunk

From caolan at caolan.uk  Mon Nov 30 23:19:39 2020
From: caolan at caolan.uk (Caolan McMahon)
Date: Mon, 30 Nov 2020 23:19:39 +0000
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
References: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
Message-ID: <C2611528-879A-40AC-BEC9-93806F69B697@caolan.uk>



>I for one think it's a good idea.  I
>know multiple people who have unsubscribed from this list after heavy
>early involvement because it's just become too much to follow.

And, just to be clear, it's not only the volume of messages that prompted by suggestion. I think it would be good to consider what a friendly onboarding looks like for new users and content creators - be that on this list or a separate one.

From waweic at activ.ism.rocks  Mon Nov 30 23:51:36 2020
From: waweic at activ.ism.rocks (Waweic)
Date: Tue, 01 Dec 2020 00:51:36 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7GXSC9EV6EY.372KD0YF3FR29@stilgar>
References: <C7GXSC9EV6EY.372KD0YF3FR29@stilgar>
Message-ID: <d64d2df643339ce7714a7eb4e38255d5c542ef47.camel@activ.ism.rocks>

> Oh, gosh darn it.  I obviously didn't mean to do that.  This is what
> I
> get for trying to squeeze spec changes into small slices of free
> time.
> Sorry, everyone.  I will fix this tomorrow.

I think the actual change in the spec is fine, it doesn't disallow
relative URI References, (called Relative URLs in the spec, which
should be changed imo) it even explicitly allows them. Assuming a
scheme of gemini:// (which was removed) would be wrong, since a
text/gemini document could be accessed via other protocols.

So, apart from the URL / URI / URI Reference stuff, I think the spec is
on point here



From cowan at ccil.org  Tue Dec  1 00:20:18 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 30 Nov 2020 19:20:18 -0500
Subject: What should I do for Geminiworld?
In-Reply-To: <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
Message-ID: <CAD2gp_TjmWTz4V-jHGc8wbOfL-dufTnc4Ot3bFcFTSyVjC6jyQ@mail.gmail.com>

On Mon, Nov 30, 2020 at 4:58 PM Emilis <emilis at emilis.net> wrote:

Both of them sound awesome.
>

Thanks!

> On the Gutenberg: could you also split the books into smaller pages (a
> couple of screens length)?
>

I think it would be hard to read 80-column plain text on a phone
footprint.  I could try to convert it to text/gemini, but there would be
issues with figuring out where to insert ``` lines.  Gutenberg texts are
from 1991 to the present, and they don't all have exactly the same internal
layout.

> Since cookies, JS and scroll positions do not work with Gemini, smaller
> pages could serve the same function.
>

I would think that a GUI Gemini browser should be able to remember the
scroll position.  Lagrange definitely does: open it on a long page, close
it, reopen it: the page will be in the same position.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201130/22e8e18b/attachment.htm>

From skyjake at dengine.net  Tue Dec  1 05:15:18 2020
From: skyjake at dengine.net (skyjake)
Date: Tue, 1 Dec 2020 07:15:18 +0200
Subject: What should I do for Geminiworld?
In-Reply-To: <CAD2gp_TjmWTz4V-jHGc8wbOfL-dufTnc4Ot3bFcFTSyVjC6jyQ@mail.gmail.com>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
 <CAD2gp_TjmWTz4V-jHGc8wbOfL-dufTnc4Ot3bFcFTSyVjC6jyQ@mail.gmail.com>
Message-ID: <319E82E6-EFC4-435D-A75E-A5553800E09C@dengine.net>

On 1. Dec 2020, at 2:20, John Cowan <cowan at ccil.org> wrote:

> I would think that a GUI Gemini browser should be able to remember the scroll position.  Lagrange definitely does: open it on a long page, close it, reopen it: the page will be in the same position.

A bit of clarification: Lagrange remembers scroll positions in navigation history (so for back/forward and app restore), but not in bookmarks.

The scroll position is reset to the top when opening a link, even if a scroll position is saved for the page in history. I think it would be a bit confusing to land somewhere in the middle/bottom of a page just because you visited it sometime in the past. (Web browsers don't do this but I haven't tried it in practice, maybe I should?)

For the book reading use case, a bookmark that saves scroll position could work.

--jaakko

From justin at abrah.ms  Tue Dec  1 05:39:50 2020
From: justin at abrah.ms (Justin Abrahms)
Date: Mon, 30 Nov 2020 21:39:50 -0800
Subject: [ANN] Emacs org-mode to gemini export back-end
In-Reply-To: <87k0u32h3b.fsf@depar.is>
References: <87k0u32h3b.fsf@depar.is>
Message-ID: <867dq213vd.fsf@abrah.ms>


?tienne Deparis writes:
> I?ve just pushed a first version of an org-mode export back-end for
> gemini. It is based on the Markdown export back-end, but also requires
> some functions from the Ascii back-end, both being provided by default
> by org-mode.


Very cool. I had a similar idea when I wrote ox-gemini which you can
find here: https://git.sr.ht/~abrahms/ox-gemini

I'll poke around on yours. I'd love to figure out how we can have one
package instead of two. :)

 -abrahms

From emilis at emilis.net  Tue Dec  1 06:04:59 2020
From: emilis at emilis.net (Emilis)
Date: Tue, 1 Dec 2020 08:04:59 +0200
Subject: What should I do for Geminiworld?
In-Reply-To: <319E82E6-EFC4-435D-A75E-A5553800E09C@dengine.net>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
 <CAD2gp_TjmWTz4V-jHGc8wbOfL-dufTnc4Ot3bFcFTSyVjC6jyQ@mail.gmail.com>
 <319E82E6-EFC4-435D-A75E-A5553800E09C@dengine.net>
Message-ID: <6d85c21b-bb8b-9876-015c-363585ecc911@emilis.net>

On 12/1/20 7:15 AM, skyjake wrote:
> For the book reading use case, a bookmark that saves scroll position could work.
>
And this is where one starts to wonder if this should be a feature of a 
browser or a feature of some browser extension/plugin.


--
Emilis Dambauskas
gemini://tilde.team/~emilis/


From linde.philip at gmail.com  Tue Dec  1 11:18:17 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 1 Dec 2020 12:18:17 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
References: <C7FYSG7UY1V1.37JQFPTNE82MG@stilgar>
Message-ID: <20201201121817.3d5a02a74fe3847b0abe7047@gmail.com>

On Sun, 29 Nov 2020 19:38:21 +0100
"Solderpunk" <solderpunk at posteo.net> wrote:

> On a related note, the spec was also changed in various places so that
> it does not perpetuate the misunderstanding of URL structure by talking
> about "a scheme of gemini://".

This is a welcome change! I also want to suggest clarifying the meaning
of absolute/relative URLs by referring to the corresponding concepts in
RFC 3986. The primary reason for this suggestion is that it may be
unclear whether an "absolute URL" is what RFC 3986 calls an "URI", an
"absolute-URI" or what RFC 1808 calls an "absolute URL", all of which
are subtly different:

* RFC 3986 "URI" may include a fragment
* RFC 3986 "absolute-URI" may not include a fragment
* RFC 1808 "absolute URL" may include a fragment

My understanding is that the intent of the language in the Gemini spec
is to prevent path-only requests (a subset of "relative-ref"). In this
case "URI" or "absolute-URI" are sufficient. If we additionally don't
want to include fragments in requests "absolute-URI" is the only option.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201201/7c8e273d/attachment-0001.sig>

From bjorn.warmedal at gmail.com  Tue Dec  1 12:03:56 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Tue, 1 Dec 2020 13:03:56 +0100
Subject: What should I do for Geminiworld?
In-Reply-To: <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
Message-ID: <CAJScK0+Mz+--DhRYrcO5wtBHkdkcHxB3L7zjnC+rEnoOkpsVYg@mail.gmail.com>

> Side question: has anyone tried to hack something Gemini-related on e-book readers?

Somewhere on my (extensive) todo list is an item that says "convert
gemtext to epub"... Just not sure when I'll get to it or how I'll do
it :D

- ew0k

From come at chilliet.eu  Tue Dec  1 13:21:36 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me_Chilliet?=)
Date: Tue, 01 Dec 2020 14:21:36 +0100
Subject: [ANN] Play Tic Tac Toe through gemini
Message-ID: <CB8F9BAF-8BFF-45B8-8696-1AA32EA293B2@chilliet.eu>

Hello,

I've put this silly thing on gemini: gemini://tictactoe.lanterne.chilliet.eu

MCMic

From jmcbray at carcosa.net  Tue Dec  1 13:28:25 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 01 Dec 2020 08:28:25 -0500
Subject: What should I do for Geminiworld?
In-Reply-To: <CAJScK0+Mz+--DhRYrcO5wtBHkdkcHxB3L7zjnC+rEnoOkpsVYg@mail.gmail.com>
 (=?utf-8?Q?=22Bj=C3=B6rn=09W=C3=A4rmedal=22's?= message of "Tue, 1 Dec 2020
 13:03:56 +0100")
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
 <CAJScK0+Mz+--DhRYrcO5wtBHkdkcHxB3L7zjnC+rEnoOkpsVYg@mail.gmail.com>
Message-ID: <87im9lr6yu.fsf@dorothy.carcosa.net>

Bj?rn W?rmedal <bjorn.warmedal at gmail.com> writes:

>> Side question: has anyone tried to hack something Gemini-related on e-book readers?
>
> Somewhere on my (extensive) todo list is an item that says "convert
> gemtext to epub"... Just not sure when I'll get to it or how I'll do
> it :D

There's already tooling to go gemtext -> html -> epub, so it's just a
matter of chaining it together.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Tue Dec  1 13:33:42 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 01 Dec 2020 08:33:42 -0500
Subject: What should I do for Geminiworld?
In-Reply-To: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 (John Cowan's message of "Mon, 30 Nov 2020 15:15:59 -0500")
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
Message-ID: <87eek9r6q1.fsf@dorothy.carcosa.net>

John Cowan <cowan at ccil.org> writes:

> 1) Write (and possibly host) a Project Gutenberg server that will
> allow you to search PG's plain-text etexts and serve them up. This
> would provide large amounts of (admittedly non-unique) content in
> Geminispace. I've done some preliminary work on this.

Be sure to check out gemini://booksin.space/. They're working on a more
curated approach, I think, similar to Standard Ebooks, but they'd
probably appreciate work on tooling.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From lypanov at gmail.com  Mon Nov 30 23:31:12 2020
From: lypanov at gmail.com (Alexander Kellett)
Date: Tue, 1 Dec 2020 00:31:12 +0100
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
References: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
 <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
Message-ID: <CAGFm8pYz4abXrwxEm+AoOKVLdyTk+pVK07FomoSmtz2esYCALQ@mail.gmail.com>

On Mon, Nov 30, 2020, 20:26 Solderpunk <solderpunk at posteo.net> wrote:

> On Mon Nov 30, 2020 at 10:06 AM CET, Caolan McMahon wrote:
> > Sure, I'd be fine with filtering on the [ANN] tag, the filter might miss
> > some discussion of interesting use cases, but it would catch 80% of what
> > I'm interested in.
>

Same here. But, it's very likely to be forgotten alas. As such, I prefer
solderpunks suggestion.

I am actually extremely open to the idea of splitting the list into
> several separate lists, as commonly seen in large software projects like
> operating systems.  Something like:

[SNIP]


How do people feel about this? [SNIP]
>

Love this list. My personal use cases are covered by announce + user.
Specifically, I'd like to read about gemini content, and software/service
(e.g GUS) announcements.

Alex

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201201/1deaabe6/attachment.htm>

From cowan at ccil.org  Tue Dec  1 14:03:33 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 1 Dec 2020 09:03:33 -0500
Subject: [ANN] Play Tic Tac Toe through gemini
In-Reply-To: <CB8F9BAF-8BFF-45B8-8696-1AA32EA293B2@chilliet.eu>
References: <CB8F9BAF-8BFF-45B8-8696-1AA32EA293B2@chilliet.eu>
Message-ID: <CAD2gp_Qq_Jx=LqDYYKRerd9QK+aXMJ39WDatp-1D3CtjK3hB3g@mail.gmail.com>

On Tue, Dec 1, 2020 at 8:21 AM C?me Chilliet <come at chilliet.eu> wrote:


> I've put this silly thing on gemini: gemini://
> tictactoe.lanterne.chilliet.eu


Very nice!

Just a suggestion: put numbers in the boxes that are still empty.  That way
you just have to choose a number rather than figure it out from the
horizontal displays in the link.  It provides a much smoother user
experience.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!
  --Joyce, Ulysses, "Oxen of the Sun"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201201/0b2de16d/attachment.htm>

From etienne at depar.is  Tue Dec  1 16:10:21 2020
From: etienne at depar.is (=?utf-8?Q?=C3=89tienne?= Deparis)
Date: Tue, 01 Dec 2020 17:10:21 +0100
Subject: [ANN] Emacs org-mode to gemini export back-end
In-Reply-To: <20201130181741.GA2929@kurosawa.casa.net>
References: <87k0u32h3b.fsf@depar.is> <20201130181741.GA2929@kurosawa.casa.net>
Message-ID: <87czzty0b6.fsf@depar.is>

lun. 30 nov. 2020 ? 19:17, cage-dev at twistfold.it a ?crit?:

> On Mon, Nov 30, 2020 at 12:56:40PM +0100, ?tienne Deparis wrote:
>
> Wow, this  is just  great! I  already use org-mode  to export  my html
> site, i could try to do the same in gemini format! :)

Thank you very much for your warm comment!

>
> Any change this could be added to "official" org package?

I don?t think so: there is a lot of other export backend in the wild, it
would not make much sense to have one more than another and it would be
a pain for the org mode maintainer to always make sure a back-end is
still supported or not.

The best way to improve its distribution would be to make it available
on MELPA. I?m willing to do it at some point, but I?d prefer to have
some feedback before: there is no point to push an alpha-quality piece
of code on MELPA.

>
> Anyway, thank you for writing this! :)

Thanks to you!

--
?tienne

From etienne at depar.is  Tue Dec  1 16:14:06 2020
From: etienne at depar.is (=?utf-8?Q?=C3=89tienne?= Deparis)
Date: Tue, 01 Dec 2020 17:14:06 +0100
Subject: [ANN] Emacs org-mode to gemini export back-end
In-Reply-To: <867dq213vd.fsf@abrah.ms>
References: <87k0u32h3b.fsf@depar.is> <867dq213vd.fsf@abrah.ms>
Message-ID: <87a6uxy04x.fsf@depar.is>

mar. 01 d?c. 2020 ? 06:39, justin at abrah.ms a ?crit?:
> Very cool. I had a similar idea when I wrote ox-gemini which you can
> find here: https://git.sr.ht/~abrahms/ox-gemini

Thank you for your quick reply. I must admit I quickly searched around
the internet to look for some previous attempt, but didn?t find yours
(didn?t find any in fact).

>
> I'll poke around on yours. I'd love to figure out how we can have one
> package instead of two. :)

Yep, I?ll do the same to see if we can converge at some point or if both
approach are worth to exist :)

--
?tienne

From caolan at caolan.uk  Tue Dec  1 16:19:35 2020
From: caolan at caolan.uk (Caolan McMahon)
Date: Tue, 01 Dec 2020 16:19:35 +0000
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <CAGFm8pYz4abXrwxEm+AoOKVLdyTk+pVK07FomoSmtz2esYCALQ@mail.gmail.com>
References: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
 <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
 <CAGFm8pYz4abXrwxEm+AoOKVLdyTk+pVK07FomoSmtz2esYCALQ@mail.gmail.com>
Message-ID: <8996b643-aece-42cb-9ac9-1ec29205952e@www.fastmail.com>

> My personal use cases are covered by announce + user. 
> Specifically, I'd like to read about gemini content, and 
> software/service (e.g GUS) announcements.

Yes, announce + user is what I'd subscribe to. Solderpunk's description of gemini-users is exactly what I had in mind.

From unicorn at disroot.org  Tue Dec  1 16:44:36 2020
From: unicorn at disroot.org (Unicorn)
Date: Tue, 01 Dec 2020 17:44:36 +0100
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <8996b643-aece-42cb-9ac9-1ec29205952e@www.fastmail.com>
References: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
 <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
 <CAGFm8pYz4abXrwxEm+AoOKVLdyTk+pVK07FomoSmtz2esYCALQ@mail.gmail.com>
 <8996b643-aece-42cb-9ac9-1ec29205952e@www.fastmail.com>
Message-ID: <0eb8a3ad7bcc0c4abaaf515c3d6323004d6325e3.camel@disroot.org>

On Tue, 2020-12-01 at 16:19 +0000, Caolan McMahon wrote:
> > My personal use cases are covered by announce + user. 
> > Specifically, I'd like to read about gemini content, and 
> > software/service (e.g GUS) announcements.
> 
> Yes, announce + user is what I'd subscribe to. Solderpunk's
> description of gemini-users is exactly what I had in mind.

Just wanted to add my agreement with splitting into several lists. I
will likely unsubscribe from this list and I know one more person that
already did due to the volume of technical discussion and the manner
in which it is conducted.

I feel that it really would be a much nicer experience for users if
the two are kept separate. :)


From cowan at ccil.org  Tue Dec  1 16:47:40 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 1 Dec 2020 11:47:40 -0500
Subject: What should I do for Geminiworld?
In-Reply-To: <87eek9r6q1.fsf@dorothy.carcosa.net>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <87eek9r6q1.fsf@dorothy.carcosa.net>
Message-ID: <CAD2gp_QF0nH5EFWBS+NzWwvRJywO8L3oNR9_gtFSnNUX6Dxh7g@mail.gmail.com>

Cool, thanks!

On Tue, Dec 1, 2020 at 8:33 AM Jason McBrayer <jmcbray at carcosa.net> wrote:

> John Cowan <cowan at ccil.org> writes:
>
> > 1) Write (and possibly host) a Project Gutenberg server that will
> > allow you to search PG's plain-text etexts and serve them up. This
> > would provide large amounts of (admittedly non-unique) content in
> > Geminispace. I've done some preliminary work on this.
>
> Be sure to check out gemini://booksin.space/. They're working on a more
> curated approach, I think, similar to Standard Ebooks, but they'd
> probably appreciate work on tooling.
>
> --
> +-----------------------------------------------------------+
> | Jason F. McBrayer                    jmcbray at carcosa.net  |
> | A flower falls, even though we love it; and a weed grows, |
> | even though we do not love it.            -- Dogen        |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201201/95797f57/attachment.htm>

From solderpunk at posteo.net  Tue Dec  1 19:49:40 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 01 Dec 2020 20:49:40 +0100
Subject: [SPEC-CHANGE] Mandatory scheme in request and link URLs
In-Reply-To: <C7GXSC9EV6EY.372KD0YF3FR29@stilgar>
Message-ID: <C7HPK4Z8TL4P.3I6WMB60Z0Z57@stilgar>

On Mon Nov 30, 2020 at 11:03 PM CET, Solderpunk wrote:

> > No, you are right, I misread his email. I personally think he made a
> > mistake here in removing relative links (which include schemeless links)
> > from text/gemini.
>
> Oh, gosh darn it. I obviously didn't mean to do that. This is what I
> get for trying to squeeze spec changes into small slices of free time.
> Sorry, everyone. I will fix this tomorrow.

...wait.  I didn't actually remove relative links at all.  That's a
relief.  I was tired when I saw Sean's email and assumed the first!

I just went through everything again.  My email to this list explaining
the changes I made didn't square up with the actual changes I made to
the spec.  Sorry for the confusion.  To be very clear, relative links
are absolutely still permitted in text/gemini documents, and in fact
even schemeless links are still permitted in text/gemini documents.  The
only actual change to the spec that pertains to => links is that I
removed the part saying that if there was no scheme the client should
assume one of gemini://.  This, I think, is actually fine - see Alex
Schroeder's post on the nice use of these rare kind of link for serving
text/gemini over other protocols:
gemini://alexschroeder.ch/page/2020-11-30_Gemini_specification_changes_in_a_disagreeable_way

Schemeless links are only forbidden in requests, i.e. what a client
sends to a server.

Sorry again for the confusion.  I hope this won't happen again, and I
hope it would also be obvious, but for the record, where a change to the
spec and my announcement to the spec don't match up, the actual spec
document is, of course, authoritative.

Cheers,
Solderpunk


From text at sdfeu.org  Tue Dec  1 21:40:32 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Tue, 01 Dec 2020 22:40:32 +0100
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
References: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
Message-ID: <b3139925c6367e68b27422adbe9ffaf3@sdfeu.org>

On 2020-11-30 20:05, Solderpunk wrote:
> people who have unsubscribed from this list after heavy
> early involvement because it's just become too much to follow.

The mailing list is mirrored at nntps://gmane.io, so one could follow 
via ones favorite usenet news reader, e. g. Pan, tin, Thunderbird, etc.

Wikipedia on Gmane:
> Messages posted to the list by email will appear in the Gmane 
> newsgroup, and vice versa.

From come at chilliet.eu  Tue Dec  1 21:52:41 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Tue, 01 Dec 2020 22:52:41 +0100
Subject: [ANN] Play Tic Tac Toe through gemini
In-Reply-To: <CAD2gp_Qq_Jx=LqDYYKRerd9QK+aXMJ39WDatp-1D3CtjK3hB3g@mail.gmail.com>
References: <CB8F9BAF-8BFF-45B8-8696-1AA32EA293B2@chilliet.eu>
 <CAD2gp_Qq_Jx=LqDYYKRerd9QK+aXMJ39WDatp-1D3CtjK3hB3g@mail.gmail.com>
Message-ID: <1926720.mN26kCthrP@tempete>

Le mardi 1 d?cembre 2020, 15:03:33 CET John Cowan a ?crit :
> Just a suggestion: put numbers in the boxes that are still empty.  That way
> you just have to choose a number rather than figure it out from the
> horizontal displays in the link.  It provides a much smoother user
> experience.

Good idea, this is now done.
I use subscript numbers because fullwidth ones where too big compared to filled squares.

I also added highlight of winning row (which was quite complicated using unicode lines), and fixed a few bugs.



From norm at iwritethe.codes  Wed Dec  2 01:37:47 2020
From: norm at iwritethe.codes (=?UTF-8?Q?Norm_MacLennan?=)
Date: Wed, 2 Dec 2020 01:37:47 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
Message-ID: <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>

Ahoy there Geminauts,

I've been loosely following Gemini for a few months waiting for
inspiration to strike. And a couple nights ago it finally happened.

The aesthetics of Gemini have always put me in mind of classic
interactive fiction, which is something I've always loved - from the
classic Infocom games up to today's Twine games.

For a long time I've had a dream of writing a good interactive fiction
game the way some people dream of writing a novel. I've started in on
Twine games a few times in the past few years, but always get
side-tracked with all of the features and my brain running in a million
directions adding more and more complexity, I can't actually get
anything worthwhile out.

Anyway, I figured it might be fun to get to learn Gemini and Golang
_and_ build myself a limited-functionality framework for interactive
fiction. And that's what GemIF is going to be.

Basically you use a YAML file to configure your scenes and transitions
and GemIF takes care of the rendering and user interaction. The only
user interaction is following links to move between scenes. There are a
few more features I'm looking to add (basic conditionals, mostly), but
I'm very much looking to keep it simple purposely. Then hopefully I can
get to actually telling a story finally - probably not, though.

I've gone on about this for long enough, here's some links:

* Demo site: gemini://gemif.fedi.farm
* Source: https://git.sr.ht/~nromdotcom/GemIF

Lemme know what you think or if there's anything you'd like to see here.
The code is pretty rough due to (a) me still being a Go novice and (b)
kinda rushing through to get a proof of concept together, but if you're
willing to dive into the code I wouldn't turn away any collaborators.

Thanks,
Norm


From justin at abrah.ms  Wed Dec  2 04:54:38 2020
From: justin at abrah.ms (Justin Abrahms)
Date: Tue, 01 Dec 2020 20:54:38 -0800
Subject: [ANN] Emacs org-mode to gemini export back-end
In-Reply-To: <87a6uxy04x.fsf@depar.is>
References: <87k0u32h3b.fsf@depar.is> <867dq213vd.fsf@abrah.ms>
 <87a6uxy04x.fsf@depar.is>
Message-ID: <86360o24fl.fsf@abrah.ms>


>> I'll poke around on yours. I'd love to figure out how we can have one
>> package instead of two. :)
>
> Yep, I?ll do the same to see if we can converge at some point or if both
> approach are worth to exist :)

I spent a bit of time with yours yesterday. Mostly taking my gemini site
and seeing how ours compare. Here were my thoughts:


1. I link all of my documents with file: directives. Your links appear
to add `(file)` to the end of the link, which doesn't make a lot of
sense to me.

2. I like my linking behavior a little better (bias alert!)

3. I don't like how either of us output lists of links.

Source:
```org
* [[link text][example.org]]
```

Yours:

```gemini
* link text[1]

=> example.org [1] link text
```

Mine:

```gemini
* [link text]

=> example.org link text
```

Ideal:

```gemini
=> example.org link text
```

4. Your renders dates oddly.

If I have `<2020-11-11 Wed>` in a post (org timestamp), it shows up as:

```gemini
<span class="timestamp-wrapper"><span class="timestamp">&lt;2020-11-11
Wed&gt;</span></span>
```

I'm guessing this is because you inherit from markdown and it pulls in
some unhelpful html escaping. Mine, by comparison, renders it as the
plaintext string `<2020-11-11 Wed>`.

That's what I got so far. Would love to hear your impression of mine.

 -abrahms

From gmym at coopdot.com  Wed Dec  2 07:23:46 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Wed, 2 Dec 2020 08:23:46 +0100
Subject: What should I do for Geminiworld?
In-Reply-To: <319E82E6-EFC4-435D-A75E-A5553800E09C@dengine.net>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <def5ae92-c180-fbde-8b1a-ece2b0808e5d@emilis.net>
 <CAD2gp_TjmWTz4V-jHGc8wbOfL-dufTnc4Ot3bFcFTSyVjC6jyQ@mail.gmail.com>
 <319E82E6-EFC4-435D-A75E-A5553800E09C@dengine.net>
Message-ID: <CAObwWNjxSXEmO6XJ93gtaCynZDQ9=K18m=qvgP9FXJy8yTuWVg@mail.gmail.com>

skyjake <skyjake at dengine.net> wrote:

> For the book reading use case, a bookmark that saves scroll position could
> work.
>

If I ever get around to writing the client I dreamed of 6 months ago, it
would only bookmark specific lines in a document (with a bias to
bookmarking the first line)

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201202/7acc756d/attachment.htm>

From mieum at namu.blue  Wed Dec  2 07:31:55 2020
From: mieum at namu.blue (mieum)
Date: Wed, 02 Dec 2020 16:31:55 +0900
Subject: What should I do for Geminiworld?
In-Reply-To: <87eek9r6q1.fsf@dorothy.carcosa.net>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <87eek9r6q1.fsf@dorothy.carcosa.net>
Message-ID: <C7I4HTJ8VV77.1O1OLBVLKRUGS@maclibre>

> Be sure to check out gemini://booksin.space. They're working on a more
> curated approach, I think similar to Standard Ebooks, but they'd
> probably appreciate work on tooling.

I initiated the project a while back, but I've been too busy to actually
work on it. I've been waiting for things to settle down around here, but
I don't know if they are going to haha

Anyone who wants to contribute is more than welcome. I had considered
doing a PG mirror in the past and actually downloaded their archives to
see what it would entail. I think that will be a fun project for John
and for Geminispace in general.

I think Jason is right that booksin.space is/will be more curated, at
least in that its shelves will be populated with books people directly
contribute. Also, I plan to include non-public domain works as well--
things like preprints of academic articles, sheet music, or whatever
other works whose copyright owners allow me to publish them.

If a PG mirror existed in Geminispace, then contributing your favorite
books to booksin.space would as simple as sending me a link :b

Looking forward to seeing more things like this grow in Geminispace (and
also looking forward to having some more time to play here myself!)

~mieum

gemini://rawtext.club/~mieum/

From luke at marmaladefoo.com  Wed Dec  2 09:12:56 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Wed, 02 Dec 2020 09:12:56 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
Message-ID: <5FC75A98.4000602@marmaladefoo.com>



On 02-Dec-2020 01:37, Norm MacLennan wrote:
> I've gone on about this for long enough, here's some links:
>
> * Demo site: gemini://gemif.fedi.farm
> * Source: https://git.sr.ht/~nromdotcom/GemIF
>
> Lemme know what you think or if there's anything you'd like to see here.
> The code is pretty rough due to (a) me still being a Go novice and (b)
> kinda rushing through to get a proof of concept together, but if you're
> willing to dive into the code I wouldn't turn away any collaborators.

Hi Norm

Its great to see a gemini interactive fiction engine. I had a walk 
around the demo instance to get a feel for it.

Its a great start, but I'm afraid it breaks the forward and back 
navigation in my client, and might affect other clients too. This is 
because each rendered page has the same URL.

I would suggest some sort of simple modification should fix it, for 
example a simple step number, like this maybe

gemini://server/path/sessionguid/step

e.g.

gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/1
gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/2
gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/3
etc

Or some other marker - it doesn't have to be an incrementing index. This 
would then work in a wider range of clients and they'd be able to back 
and forward through their session.

Regards

  - Luke

From come at chilliet.eu  Wed Dec  2 10:17:41 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Wed, 02 Dec 2020 11:17:41 +0100
Subject: Hosting several sites on the same host
Message-ID: <3167385.IEBFgDKfjZ@tempete>

Hello,

I?m lost with how sockets and TLS works, how can I host several gemini sites on the same host?

I cannot read the request before setting up TLS, but I need to know which hostname is requested to serve the correct certificate.

So I guess either:
1) It?s possible to have several programs listen on the same port using different hostname?
2) It?s possible for a program which listen on a port to know which hostname was requested before TLS handshake?

I use stream_socket_server and stream_socket_accept in PHP and did not find how to get requested hostname.

I did not find good documentation on the purpose of the target in the socket name. I use tcp://[::]:1965 currently.
I do not understand what it does to put a hostname instead of [::] in there.

C?me



From op at omarpolo.com  Wed Dec  2 10:25:25 2020
From: op at omarpolo.com (Omar Polo)
Date: Wed, 02 Dec 2020 11:25:25 +0100
Subject: Hosting several sites on the same host
In-Reply-To: <3167385.IEBFgDKfjZ@tempete>
References: <3167385.IEBFgDKfjZ@tempete>
Message-ID: <87mtywo67e.fsf@omarpolo.com>


C?me Chilliet <come at chilliet.eu> writes:

> Hello,
>
> I?m lost with how sockets and TLS works, how can I host several gemini sites on the same host?
>
> I cannot read the request before setting up TLS, but I need to know which hostname is requested to serve the correct certificate.
>
> So I guess either:
> 1) It?s possible to have several programs listen on the same port using different hostname?
> 2) It?s possible for a program which listen on a port to know which hostname was requested before TLS handshake?
>
> I use stream_socket_server and stream_socket_accept in PHP and did not find how to get requested hostname.
>
> I did not find good documentation on the purpose of the target in the socket name. I use tcp://[::]:1965 currently.
> I do not understand what it does to put a hostname instead of [::] in there.
>
> C?me

You should use the Server Name Indication (SNI) TLS extension.  Gemini
clients have to support SNI, by the spec.  Basically, clients in the TLS
handshake will tell you to which hostname they want to talk to, so you
can use the appropriate certificate.

Unfortunately I am not knowledgable in PHP, so I cannot help you further.

From come at chilliet.eu  Wed Dec  2 10:42:16 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Wed, 02 Dec 2020 11:42:16 +0100
Subject: Hosting several sites on the same host
In-Reply-To: <87mtywo67e.fsf@omarpolo.com>
References: <3167385.IEBFgDKfjZ@tempete> <87mtywo67e.fsf@omarpolo.com>
Message-ID: <2248433.n8l4AnvsTd@tempete>

Le mercredi 2 d?cembre 2020, 11:25:25 CET Omar Polo a ?crit :
> You should use the Server Name Indication (SNI) TLS extension.  Gemini
> clients have to support SNI, by the spec.  Basically, clients in the TLS
> handshake will tell you to which hostname they want to talk to, so you
> can use the appropriate certificate.

Thank you for the pointer, there is an SNI_enabled boolean I can set to true in SSL options: https://www.php.net/manual/en/context.ssl.php

I will keep searching in this direction then.

C?me



From stephane at sources.org  Wed Dec  2 11:14:31 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 2 Dec 2020 12:14:31 +0100
Subject: Mirror of RFCs in Geminispace
Message-ID: <20201202111431.GA933@sources.org>

Not a lot of content on my capsule but I've made a mirror
(automatically kept up-to-date) of the RFCs
<https://www.rfc-editor.org/>. Not only they are very important texts
but, since they have a plain text version, they fit well in the
geminispace. There is no text/gemini index yet, you
have to make the URL
'gemini://gemini.bortzmeyer.org/rfc-mirror/rfcNNNN.txt'. Two examples:

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8947.txt RFC 8947 (on MAC
addresses assignment through DHCP, published a few hours ago) from its
number

gemini://gemini.bortzmeyer.org/rfc-mirror/bcp/bcp47.txt BCP 47 (Best
Current Practice) about language tags, a pointer to the relevant RFC,
which is used in Gemini's specification.

From petite.abeille at gmail.com  Wed Dec  2 11:31:10 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 2 Dec 2020 12:31:10 +0100
Subject: [ANN] Play Tic Tac Toe through gemini
In-Reply-To: <CB8F9BAF-8BFF-45B8-8696-1AA32EA293B2@chilliet.eu>
References: <CB8F9BAF-8BFF-45B8-8696-1AA32EA293B2@chilliet.eu>
Message-ID: <79A3EC67-E459-423C-863C-E9C0F0EE5105@gmail.com>



> On Dec 1, 2020, at 14:21, C?me Chilliet <come at chilliet.eu> wrote:
> 
> I've put this silly thing on gemini: gemini://tictactoe.lanterne.chilliet.eu

Cool. Sudoku next? :D

From petite.abeille at gmail.com  Wed Dec  2 11:34:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 2 Dec 2020 12:34:11 +0100
Subject: Mirror of RFCs in Geminispace
In-Reply-To: <20201202111431.GA933@sources.org>
References: <20201202111431.GA933@sources.org>
Message-ID: <EA2809DA-989C-4462-8941-87EA0387439D@gmail.com>



> On Dec 2, 2020, at 12:14, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> a pointer to the relevant RFC, which is used in Gemini's specification

Cool. Another interesting project could trace the dependencies & lineage of all the RFCs Gemini depends on.


From norm at iwritethe.codes  Wed Dec  2 12:05:27 2020
From: norm at iwritethe.codes (=?UTF-8?Q?Norm_MacLennan?=)
Date: Wed, 2 Dec 2020 12:05:27 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com> 
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> 
 <mail.5fc78306.199c.52793b6a0ad00bf3@storage.wm.amazon.com>
Message-ID: <010001762357d621-26349d57-b6a7-4b1e-ab10-d01934ffe469-000000@email.amazonses.com>

On 12/2/20 4:13 AM, Luke Emmet wrote:
> Its a great start, but I'm afraid it breaks the forward and back 
> navigation in my client, and might affect other clients too. This is 
> because each rendered page has the same URL.
>
> I would suggest some sort of simple modification should fix it, for 
> example a simple step number, like this maybe
>
> gemini://server/path/sessionguid/step
>
> e.g.
>
> gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/1
> gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/2
> gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/3
> etc
>
> Or some other marker - it doesn't have to be an incrementing index. This 
> would then work in a wider range of clients and they'd be able to back 
> and forward through their session.

Hey Luke,

Thanks for checking it out and thanks for the feedback. Since I was
always opening a new Amfora tab to test, I hadn't considered how it
breaks back/forward but you're completely right.

Due to the nature of how the application currently works, I'm going to
have to do some noodling on how to fix this. Though your suggestion will
likely be some part of it.

If I wanted to keep the low complexity of the app as it is now, I could
even do away with the notion of "games" completely and just have it move
you between a static URI for each room. That is,

```
# GemIF

This is the homepage.

=> gemini://gemif.fedi.farm/room/the_beginning start the game
```

And on the next page

```
# The Beginning

Some description.

=> gemini://gemif.fedi.farm/room/the_middle_a make choice a
=> gemini://gemif.fedi.farm/room/the_middle_b make choice b
```

That would probably be the most straightforward way of not hijacking
history for the clients as the user could freely jump back and forward
due to stable URLs and lack of server-side state.

However, it becomes a little problematic if I want to introduce actual
game state (e.g. you have the key because you made choice b). So I'll
need to do some thinking on how important such state is to me (and
anyone else interested). It originally seemed fairly integral to the
ability to create a branching narrative without forcing the author to
repeat themselves, but maybe it's not actually necessary or just not
something I need to think about yet.

If I do decide to implement simple game state, I'll likely play with
your suggestion. But in stories where game state is used have it render
something like the below when the user goes back to a previous page:

```
# Invalid Game State

This story doesn't allow time travel.

=> gemini://gemif.fedi.farm/game/my_game_id/latest_recorded_step Go back
to the current scene
=> gemini://gemif.fedi.farm/ Exit game
```

Because otherwise I'm stuck selectively rolling back game state on the
server side. While it's not ideal and some users will find the messages
annoying, it should at least be a bit more pleasant than their clients
throwing error messages about non-existent exits or whatever it's doing
now. And it means I don't need to worry about server-side needing to be
able to selectively roll-back game state (or at least not immediately
and I can add that feature later).

Thanks again for the feedback, it has definitely been useful. If you
think of anything else let me know.

Thanks,
Norm


From jplebreton at gmail.com  Wed Dec  2 06:20:57 2020
From: jplebreton at gmail.com (JP LeBreton)
Date: Tue, 1 Dec 2020 22:20:57 -0800
Subject: variable indentation levels / hierarchy in lists
Message-ID: <CAEBBUWgH7Xr8U9jsQsZLjQCD7ai2A1M9Mjp4WMqSpopdT4ueFQ@mail.gmail.com>

I've been writing gemini text for about a month now, and as a former
plaintext stickler I've found it easy, sensible, and pleasant. The
spec avoids the "formatting traps" of many rich text formats that
tempt authors into fussing with cosmetic issues.

The one thing I'm really missing is the ability to have hierarchical
lists that display in an indented form, like so:

* Top-level item 1
** Subsection 1A
** Subsection 1B
*** Sub-subsection i
*** Sub-subsection ii
** Subsection 1C
* Top-level item 2
** Subsection 2A
* Top-level item 3

I think hierarchies like this are a uniquely useful way of structuring
ideas, and adding something like this - which, to be clear, clients
would be as free to ignore as any of the other optional line types -
would expand the kinds of information that people would be able to
usefully write on Gemini. I'm curious as to how many people agree.

Markdown seems to use whitespace to indicate indent level, but I know
people have strong feelings about significant whitespace. I don't feel
too strongly about the syntax; I'm not as experienced with shaping
specifications as many folks here and defer to that expertise.

Rendering these properly would add some complexity to client logic,
but in thinking through how I'd implement one it doesn't seem like
it'd be a deal-breaker; clients already have to use some state-like
concept to correctly handle preformatted blocks, lists etc.

I've read a significant portion of the archives of this mailing list
to get a feel for how spec-related discussions have gone thus far, and
so I could make my case here persuasively. If this has already been
hashed out and I missed it, I apologize. I also totally understand if
line type complexity is something where folks feel they must "hold the
line" against further complexity. I'm speaking mostly as someone who's
enjoyed exploring Gemini space and building a small presence here.
Thanks for your time!

- JP
gemini://gem.vectorpoem.com

From stephane at sources.org  Wed Dec  2 13:59:56 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 2 Dec 2020 14:59:56 +0100
Subject: Hosting several sites on the same host
In-Reply-To: <3167385.IEBFgDKfjZ@tempete>
References: <3167385.IEBFgDKfjZ@tempete>
Message-ID: <20201202135956.GA7698@sources.org>

On Wed, Dec 02, 2020 at 11:17:41AM +0100,
 C?me Chilliet <come at chilliet.eu> wrote 
 a message of 23 lines which said:

> I?m lost with how sockets and TLS works, how can I host several
> gemini sites on the same host?

The gemserv server <https://git.sr.ht/~int80h/gemserv/> has virtual
hosts and certs per virtual host so reading its source code may be
useful.

From stephane at sources.org  Wed Dec  2 14:26:01 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 2 Dec 2020 15:26:01 +0100
Subject: *Curated* list of servers?
Message-ID: <20201202142601.GA8350@sources.org>

The list of possible server software at
<gemini://gemini.circumlunar.space/software/> does not provide any
details about their status, their features, their strengths and
weaknesses. Choosing software for a server is therefore a long and
tedious task.

Is there a better list somewhere? I think that, for Gemini deployment,
it would be better to have it, since newbies sysadmins may be
discouraged by the very differente states of maturity of programs in
the current list. After my (very incomplete) tests, I find that:

* Agate : Static files. Works OK but not way to set the lang.
* Shavit : bind IP address hardwired as localhost.
* Blizanci : no commit in the last six months
* GeGoBi : seems only suitable for people who already have a Gopher
  server and want to serve with Gemini immediately
* Geminid : written in C, which scares me. There are so many ways to
  be wrong when programming an Internet server in C. Otherwise, works
  OK. No commit in the last five months.
* Gemserv : Works OK and has vhosts. Seems cool. It fails with error 31 when the URI
  has no trailing / unlike other servers. 
* Molly-brown : perfect in everything (but no vhosts)
* Net-gemini : not a server but a library to develop custom servers,
  for instance with CGI, it seems.
* Northstar : the same
* Pollux : apparently very limited, can serve only one file.  no
  commit in the last six months
* Twins : Works OK. Very feature-rich. But no way to set the language in the
  answers?


From acdw at acdw.net  Wed Dec  2 15:10:27 2020
From: acdw at acdw.net (acdw)
Date: Wed, 02 Dec 2020 15:10:27 +0000
Subject: *Curated* list of servers?
In-Reply-To: <20201202142601.GA8350@sources.org>
References: <20201202142601.GA8350@sources.org>
Message-ID: <d78b891d-85e0-4bc8-a29b-ac69fe5c9e5f@www.fastmail.com>

On 2020-12-02 (Wednesday) at 14:26, Stephane Bortzmeyer <stephane at sources.org> wrote:

> The list of possible server software at
> <gemini://gemini.circumlunar.space/software/> does not provide any
> details about their status, their features, their strengths and
> weaknesses. Choosing software for a server is therefore a long and
> tedious task.
> 
> Is there a better list somewhere? I think that, for Gemini deployment,
> it would be better to have it, since newbies sysadmins may be
> discouraged by the very differente states of maturity of programs in
> the current list. After my (very incomplete) tests, I find that:
> 

There is https://github.com/kr1sp1n/awesome-gemini, which is one of those "Awesome" lists of curated software.  I don't know how "curated" it is though --- but it might be a good place to start for a PR/fork.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From gemini at ur.gs  Wed Dec  2 15:27:57 2020
From: gemini at ur.gs (Nick Thomas)
Date: Wed, 02 Dec 2020 15:27:57 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
Message-ID: <ebe871fc50db9b9b70edcd1e6e797a51927ee7d5.camel@ur.gs>

Hi,

On Wed, 2020-12-02 at 01:37 +0000, Norm MacLennan wrote:
> Ahoy there Geminauts,
> 
> I've been loosely following Gemini for a few months waiting for
> inspiration to strike. And a couple nights ago it finally happened.
> 
> The aesthetics of Gemini have always put me in mind of classic
> interactive fiction, which is something I've always loved - from the
> classic Infocom games up to today's Twine games.

I recently got sucked into Stay: https://ejadelomax.itch.io/stay -
which is built using a not-web-specific IF engine called Ink: 
https://www.inklestudios.com/ink/

While reading up on the language, I did find it quite gemini-like.
GemIF looks interesting, but I'm curious what you think of the ink
approach, and whether a gemini exporter (like the existing web
exporter) for the existing editors would make more sense? If not, you
might find the language used by Ink more compelling than a  yaml file.

I do find myself thinking that it would be fun to play Stay on Gemini
rather than the web ^^.

/Nick


From stephane at sources.org  Wed Dec  2 16:26:39 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 2 Dec 2020 17:26:39 +0100
Subject: *Curated* list of servers?
In-Reply-To: <d78b891d-85e0-4bc8-a29b-ac69fe5c9e5f@www.fastmail.com>
References: <20201202142601.GA8350@sources.org>
 <d78b891d-85e0-4bc8-a29b-ac69fe5c9e5f@www.fastmail.com>
Message-ID: <20201202162639.GA28501@sources.org>

On Wed, Dec 02, 2020 at 03:10:27PM +0000,
 acdw <acdw at acdw.net> wrote 
 a message of 19 lines which said:

> There is https://github.com/kr1sp1n/awesome-gemini, which is one of
> those "Awesome" lists of curated software.  I don't know how
> "curated" it is though

It seems that the one-liners describing the programs are just taken
verbatim from the official descriptions of each program. Shavit, for
instance, is unusable for an Internet server since it binds to
localhost and this is hardwired in the source code but this important
restriction does not appear in the list.

From norm at iwritethe.codes  Wed Dec  2 18:55:36 2020
From: norm at iwritethe.codes (=?UTF-8?Q?Norm_MacLennan?=)
Date: Wed, 2 Dec 2020 18:55:36 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com> 
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <ebe871fc50db9b9b70edcd1e6e797a51927ee7d5.camel@ur.gs> 
 <mail.5fc7e327.2b92.056d00f60143b28e@storage.wm.amazon.com>
Message-ID: <0100017624cf55b3-cbb3a89d-e7f2-4733-8ee4-4abb2a3a490b-000000@email.amazonses.com>

On 12/2/20 10:28 AM, Nick Thomas wrote:
> I recently got sucked into Stay: https://ejadelomax.itch.io/stay -
> which is built using a not-web-specific IF engine called Ink: 
> https://www.inklestudios.com/ink/
>
> While reading up on the language, I did find it quite gemini-like.
> GemIF looks interesting, but I'm curious what you think of the ink
> approach, and whether a gemini exporter (like the existing web
> exporter) for the existing editors would make more sense? If not, you
> might find the language used by Ink more compelling than a  yaml file.
>
> I do find myself thinking that it would be fun to play Stay on Gemini
> rather than the web ^^.
>
> /Nick

Hey Nick,

I'm not familiar with Ink, but it looks pretty cool.

I haven't looked into how the project is persisted on disk nor how
exporters work, but I bet making an exporter for simple Ink stories into
a Gemini static site would be possible. But it looks like Ink has some
more advanced features like conditions and variables which wouldn't lend
themselves to a static site format and would require a server to keep
track of gamestate (where I assume the web exporter does everything
client-side with Javascript).

In that case, unless I'm missing something, a Gemini exporter would
basically need to scaffold and generate the entire server for each story
- at least for stories that require conditions and variables. In which
case it might make sense to build a pre-made server to be the engine and
just generate configuration for the individual stories to keep the
exporter relatively simple. Probably you can see where I'm going with
this, but once GemIF has rough feature parity with Ink it might be
interesting to look into making a GemIF exporter that generates the YAML
from your Ink project.

But I haven't really looked into the structure of Ink projects or the
full feature-set beyond basic syntax to know what that might look like
or if it's even feasible. Maybe once I do I'll find a better
configuration format than YAML, cause I agree giant YAML files are the
worst. But I figured it was halfway between human readable and machine
readable and I could build some tooling to generate it from something
easier to read and maintain in the future.

Thanks for linking me to this, if nothing else it will give me more
prior art to draw from but potentially also shows a valuable integration
for the future.

Thanks,
Norm


From bouncepaw2 at yandex.ru  Wed Dec  2 19:03:38 2020
From: bouncepaw2 at yandex.ru (Timur Ismagilov)
Date: Thu, 03 Dec 2020 00:03:38 +0500
Subject: *Curated* list of servers?
In-Reply-To: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
Message-ID: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201203/4f53960e/attachment.htm>

From mbays at sdf.org  Wed Dec  2 19:22:05 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Wed, 2 Dec 2020 19:22:05 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <5FC75A98.4000602@marmaladefoo.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com>
Message-ID: <20201202192205.GA4592@SDF.ORG>

* Wednesday, 2020-12-02 at 09:12 +0000 - Luke Emmet <luke at marmaladefoo.com>:

> Its a great start, but I'm afraid it breaks the forward and back navigation
> in my client, and might affect other clients too. This is because each
> rendered page has the same URL.

Isn't it that this has exposed an incorrect assumption in the client,
rather than a problem with (the original implementation of) GemIF?

There's no assumption of idempotence in gemini, two requests to the
same url might well return different responses. So I'd have thought
that consecutive requests to the same url should get separate history
items, at least if the responses aren't identical (and then to
minimise surprise, also if they are).

From gemini at ur.gs  Wed Dec  2 19:22:17 2020
From: gemini at ur.gs (Nick Thomas)
Date: Wed, 02 Dec 2020 19:22:17 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <0100017624cf55b3-cbb3a89d-e7f2-4733-8ee4-4abb2a3a490b-000000@email.amazonses.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <ebe871fc50db9b9b70edcd1e6e797a51927ee7d5.camel@ur.gs>
 <mail.5fc7e327.2b92.056d00f60143b28e@storage.wm.amazon.com>
 <0100017624cf55b3-cbb3a89d-e7f2-4733-8ee4-4abb2a3a490b-000000@email.amazonses.com>
Message-ID: <178e2430d1a785cfeac4df84856749d2324c44f0.camel@ur.gs>

On Wed, 2020-12-02 at 18:55 +0000, Norm MacLennan wrote:
> 
> In that case, unless I'm missing something, a Gemini exporter would
> basically need to scaffold and generate the entire server for each
> story
> - at least for stories that require conditions and variables. In
> which
> case it might make sense to build a pre-made server to be the engine 

Hmm. Perhaps the best way to go about this would be a cgi-bin script
that can take a compiled ink story (turns out it compiles to json) and
use client certificates + a persistent server-side data store for user
state. The script would be the same for every story, it'd "just" need a
way to store per-user state.

If you want to focus on GemIF specifically, I might have a crack at
this, it sounds fun.

> Maybe once I do I'll find a better
> configuration format than YAML, cause I agree giant YAML files are
> the worst.

I've not actually looked at *how* ink's language compiles down to json,
but I wonder how many unique ways there really are to represent a
branching storyline in this kind of format. It'd be amazing if the two
formats ended up being compatible just through convergent evolution :D.


> Thanks for linking me to this, if nothing else it will give me more
> prior art to draw from but potentially also shows a valuable
> integration
> for the future.

Best of luck! Keep us updated on exciting new stories as they arise :).


From lokesh at low-key.me  Wed Dec  2 19:30:00 2020
From: lokesh at low-key.me (Lokesh Krishna)
Date: Thu, 03 Dec 2020 01:00:00 +0530
Subject: *Curated* list of servers?
In-Reply-To: <20201202162639.GA28501@sources.org>
References: <20201202142601.GA8350@sources.org>
 <d78b891d-85e0-4bc8-a29b-ac69fe5c9e5f@www.fastmail.com>
 <20201202162639.GA28501@sources.org>
Message-ID: <DA278AA4-8D1B-4FB5-9987-149925AEFBEA@low-key.me>


On 2 December 2020 9:56:39 pm IST, Stephane Bortzmeyer <stephane at sources.org> wrote:
>On Wed, Dec 02, 2020 at 03:10:27PM +0000,
> acdw <acdw at acdw.net> wrote 
> a message of 19 lines which said:
>
>> There is https://github.com/kr1sp1n/awesome-gemini, which is one of
>> those "Awesome" lists of curated software.  I don't know how
>> "curated" it is though
>
>It seems that the one-liners describing the programs are just taken
>verbatim from the official descriptions of each program. Shavit, for
>instance, is unusable for an Internet server since it binds to
>localhost and this is hardwired in the source code but this important
>restriction does not appear in the list.

>It seems that the one-liners describing the programs are just taken
>verbatim from the official descriptions of each program. 

Maybe open an issue discussing how this is an opportunity to present servers in a manner that makes picking them easier for end-users.  

The list as a whole is quite barebones but if somebody has a vision of what it could be then maybe it could be shaped up to be that?
? Lokesh Krishna

From alex at nytpu.com  Wed Dec  2 19:55:24 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Wed, 2 Dec 2020 12:55:24 -0700
Subject: variable indentation levels / hierarchy in lists
Message-ID: <20201202195524.wa5luicqom4e27rz@GLaDOS>

I would say that you can actually just use variable depth lists anyways,
like this:

* item 1
  * item 2
* item 3
  * item 4
    * etc.

But the main thing I'd be worried about is clients that do render
regular bullets with fancy bullets wouldn't work properly. I threw
together a test document with different styles here:
gemini://nytpu.com/experiments/deep-list.gmi

Apparently Lagrange strips out all leading whitespace, Kristall indents
first-level items, making second-level look further left, and Bombadillo
(and presumably other tui clients) render it properly.

Screenshots of all the clients I tested on: https://imgur.com/a/A7CvGC6

I am not speaking in favor of any change or non-change to the spec. I
just did this to test how it would be rendered if you decided to try to
do it anyways (I'd heed "Authors should not expect to exercise any
control over the precise rendering of their text lines").

I actually would appreciate multi-level lists up to three levels deep,
indented with one space, or with multiple stars.

* level 1
 * level 2
  * level 3
OR
* level 1
** level 2
*** level 3

It maintains the "check only the first three characters" limit, is
non-breaking, and is not required for clients to implement. I am merely
suggesting it as a *possible* change, but I am unsure whether I even
should mention it or not because I'm generally in the "don't change the
spec" crowd, but I feel I should at least put it forward for discussion.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201202/bd75045b/attachment.sig>

From come at chilliet.eu  Wed Dec  2 20:53:24 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Wed, 02 Dec 2020 21:53:24 +0100
Subject: [ANN] chess puzzles on gemini
Message-ID: <15174901.RmvKAXdgQ5@tempete>

Hello,

After Tic Tac Toe, I worked on rendering a chess board in Unicode.

I did not find a nice way to color black squares, but it works.
Also, most gemini clients use dark themes and as a result inverse white and black colors on chess pieces.

You can get a random chess puzzle on gemini://chess.lanterne.chilliet.eu

The puzzle is taken from chess.com using their API. I looked into lichess API but did not find an endpoint for puzzles, and lichess returns PGN and my code was only supporting FEN.
Note that the API does not give the solution, so you cannot know if you succeeded without using HTTP.
But you can still use this page to work on your chess skills.

The page is not interactive. Note that implementing an interactive chess board could be done by using an input field and Algebraic notation.
But this would mean running a chess engine, and keep a server-side session, which I do not want to get into yet.

C?me

PS: and yes, it does mean I managed to use SNI to host several domain on the same server.



From me at adnano.co  Wed Dec  2 21:13:56 2020
From: me at adnano.co (Adnan Maolood)
Date: Wed, 02 Dec 2020 21:13:56 GMT
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <15174901.RmvKAXdgQ5@tempete>
Message-ID: <C7ILQC02FPBH.1M0VC97TVRHUS@nitro>


On Wed Dec 2, 2020 at 3:53 PM EST, C?me Chilliet wrote:
> Hello,
>
> After Tic Tac Toe, I worked on rendering a chess board in Unicode.
>
> I did not find a nice way to color black squares, but it works.
> Also, most gemini clients use dark themes and as a result inverse white
> and black colors on chess pieces.
>
> You can get a random chess puzzle on gemini://chess.lanterne.chilliet.eu
>
> The puzzle is taken from chess.com using their API. I looked into
> lichess API but did not find an endpoint for puzzles, and lichess
> returns PGN and my code was only supporting FEN.
> Note that the API does not give the solution, so you cannot know if you
> succeeded without using HTTP.
> But you can still use this page to work on your chess skills.
>
> The page is not interactive. Note that implementing an interactive chess
> board could be done by using an input field and Algebraic notation.
> But this would mean running a chess engine, and keep a server-side
> session, which I do not want to get into yet.
>
> C?me
>
> PS: and yes, it does mean I managed to use SNI to host several domain on
> the same server.

Looks cool!

You could use an approach similar to the one for Tic Tac Toe to avoid
having to keep track of server side state. There are only so many
possible combinations of chess pieces. You could encode the current
combination in a compact binary format and put that in the URL.
I might give it a try if I get a chance.

From tomasino at lavabit.com  Wed Dec  2 21:16:50 2020
From: tomasino at lavabit.com (James Tomasino)
Date: Wed, 2 Dec 2020 21:16:50 +0000
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <C7ILQC02FPBH.1M0VC97TVRHUS@nitro>
References: <C7ILQC02FPBH.1M0VC97TVRHUS@nitro>
Message-ID: <f932dc47-5387-3ad5-3606-eda9bb9ac0b7@lavabit.com>

On 12/2/20 9:13 PM, Adnan Maolood wrote:
> You could use an approach similar to the one for Tic Tac Toe to avoid
> having to keep track of server side state. There are only so many
> possible combinations of chess pieces. You could encode the current
> combination in a compact binary format and put that in the URL.
> I might give it a try if I get a chance.

Perhaps you could use an FEN?

https://en.wikipedia.org/wiki/Forsyth%E2%80%93Edwards_Notation

Here's an example from a game I'm playing now:

r3kb1r/ppp3pp/2p5/4P3/3Pn1Bq/4B1P1/PPP4P/RN1QK2R b KQkq - 0 11


From come at chilliet.eu  Wed Dec  2 21:28:27 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Wed, 02 Dec 2020 22:28:27 +0100
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <f932dc47-5387-3ad5-3606-eda9bb9ac0b7@lavabit.com>
References: <C7ILQC02FPBH.1M0VC97TVRHUS@nitro>
 <f932dc47-5387-3ad5-3606-eda9bb9ac0b7@lavabit.com>
Message-ID: <2333890.YaU1AjbS5T@tempete>

Le mercredi 2 d?cembre 2020, 22:16:50 CET James Tomasino a ?crit :
> Perhaps you could use an FEN?

As I explained in the first email I do use FEN, this is what I parse from chess.com to place the pieces.

But I thought FEN in URI would be ugly since it contains spaces.
Also it would make more sense to store the game in a session and have the moves history like what most chess programs are doing.

Something which should be easy to do is allow to spectate chess games on gemini using this board, and asking the user to reload the page when he wants an update.
Maybe when the candidates tournament starts again I?ll work on that.

C?me



From acdw at acdw.net  Wed Dec  2 22:13:04 2020
From: acdw at acdw.net (acdw)
Date: Wed, 02 Dec 2020 22:13:04 +0000
Subject: *Curated* list of servers?
In-Reply-To: <DA278AA4-8D1B-4FB5-9987-149925AEFBEA@low-key.me>
References: <20201202142601.GA8350@sources.org>
 <d78b891d-85e0-4bc8-a29b-ac69fe5c9e5f@www.fastmail.com>
 <20201202162639.GA28501@sources.org>
 <DA278AA4-8D1B-4FB5-9987-149925AEFBEA@low-key.me>
Message-ID: <cf16c15b-8ca6-48c9-8e12-8ce513261444@www.fastmail.com>

On 2020-12-02 (Wednesday) at 19:30, Lokesh Krishna <lokesh at low-key.me> wrote:

> 
> On 2 December 2020 9:56:39 pm IST, Stephane Bortzmeyer 
> <stephane at sources.org> wrote:
>
> >It seems that the one-liners describing the programs are just taken
> >verbatim from the official descriptions of each program. Shavit, for
> >instance, is unusable for an Internet server since it binds to
> >localhost and this is hardwired in the source code but this important
> >restriction does not appear in the list.
> 
> >It seems that the one-liners describing the programs are just taken
> >verbatim from the official descriptions of each program. 
> 
> Maybe open an issue discussing how this is an opportunity to present 
> servers in a manner that makes picking them easier for end-users.  
> 
> The list as a whole is quite barebones but if somebody has a vision of 
> what it could be then maybe it could be shaped up to be that?
> ? Lokesh Krishna
>

Right, I just linked to it as a resource I knew about, so you wouldn't have to start from scratch.  AFAIK nothing really comprehensive exists, just this list.

-- 
~ acdw
acdw.net | breadpunk.club/~breadw

From alex at alexwennerberg.com  Wed Dec  2 22:43:55 2020
From: alex at alexwennerberg.com (Alex)
Date: Wed, 02 Dec 2020 22:43:55 GMT
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <15174901.RmvKAXdgQ5@tempete>
References: <15174901.RmvKAXdgQ5@tempete>
Message-ID: <F883767E-EB65-4E05-BCB1-7059AE97818D@alexwennerberg.com>

Very cool! For you or anyone else interested, I put together a simple server that enables interactive chess games, but haven?t gotten around to deploying it ? https://git.sr.ht/~alexwennerberg/gemchess 

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201202/8f4f3510/attachment.htm>

From come at chilliet.eu  Wed Dec  2 23:03:55 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Thu, 03 Dec 2020 00:03:55 +0100
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <15174901.RmvKAXdgQ5@tempete>
References: <15174901.RmvKAXdgQ5@tempete>
Message-ID: <1648146.GX1b5dPeqx@tempete>

Hello,

There is now a webpage listing available games at gemini://games.lanterne.chilliet.eu/

And the code can be directly consulted on gemini://code.lanterne.chilliet.eu/

The server in there is getting more and more complete, if anyone is interested I could split MCMic\Gemini from the rest so that it can be used as a base for other PHP projects.
It?s still far from complete/perfect though.

Has anyone worked on content available in multiple language on gemini?
What is the most common practice, some /en at start/end of path, and links at the page bottom to switch language?

C?me



From cowan at ccil.org  Wed Dec  2 23:36:42 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 2 Dec 2020 18:36:42 -0500
Subject: What should I do for Geminiworld?
In-Reply-To: <C7I4HTJ8VV77.1O1OLBVLKRUGS@maclibre>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <87eek9r6q1.fsf@dorothy.carcosa.net> <C7I4HTJ8VV77.1O1OLBVLKRUGS@maclibre>
Message-ID: <CAD2gp_SBgb=6ERgPeKMfWxQCPEoVAbHUnpMphxTbqxxrH9UN+w@mail.gmail.com>

On Wed, Dec 2, 2020 at 2:32 AM mieum <mieum at namu.blue> wrote:


> Anyone who wants to contribute is more than welcome.
>

I tried posting to the mailing list, but it's sooooo picky, I'm not sure if
my email went through.  (Several previous tries failed.)


> If a PG mirror existed in Geminispace, then contributing your favorite
> books to booksin.space would as simple as sending me a link :b
>

Gutengemi will serve text/plain; it will be up to someone else to convert
to text/gemini if that is desired.  However, I will be converting all
encodings to UTF-8.

Note that it is not an archive, but fetches and converts text on the fly.
That way I don't have to obey the rules about setting up a PG mirror.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201202/39ab3874/attachment.htm>

From come at chilliet.eu  Wed Dec  2 23:38:55 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Thu, 03 Dec 2020 00:38:55 +0100
Subject: [ANN] Play Tic Tac Toe through gemini
In-Reply-To: <00983C5D-DC67-4E4D-8309-DB0A1FD46349@gmail.com>
References: <CB8F9BAF-8BFF-45B8-8696-1AA32EA293B2@chilliet.eu>
 <00983C5D-DC67-4E4D-8309-DB0A1FD46349@gmail.com>
Message-ID: <2859230.oL71azy1yd@tempete>

Le mercredi 2 d?cembre 2020, 12:29:11 CET Petite Abeille a ?crit :
> Cool. Sudoku next? :D
> 

Actually, I?ve found sudokus on gemini here: gemini://bleyble.com/users/quokka/games/sudoku/



From sean at conman.org  Wed Dec  2 23:53:34 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 2 Dec 2020 18:53:34 -0500
Subject: Multiple Language support (was Re: [ANN] chess puzzles on gemini)
In-Reply-To: <1648146.GX1b5dPeqx@tempete>
References: <15174901.RmvKAXdgQ5@tempete> <1648146.GX1b5dPeqx@tempete>
Message-ID: <20201202235334.GH24194@brevard.conman.org>

It was thus said that the Great C?me Chilliet once stated:
> Hello,

  Hello.

> Has anyone worked on content available in multiple language on gemini?
> What is the most common practice, some /en at start/end of path, and links
> at the page bottom to switch language?

  I'm working on that right now for GLV-1.12556 [1].  The planned support
(which should be available in an hour or so) is to allow a person to set
both the default language [2] and character set [3][4] server wide, per
host, per directory or per file [5] in the configuration file.

  There are other ways of solving this (special file extensions, a map of
filenames to languages, etc.) but that's how I'm solving this particular
issue.

  -spc

[1]	https://github.com/spc476/GLV-1.12556

[2]	No default.  If not set, the lang paramter for text/* MIME types
	will not be set.

[3]	Also no default, and I suspect no one will really use this except
	for maybe at the directory or file level for legacy text files.  But
	as long as I was doing the lang= parameter, I thought I might as
	well do the charset= parameter.

[4]	These two settings cascade down through the configuration file.  You
	can set it server wide and override it at the host, directory or
	file levels.

[5]	Technically, per content handler.  The built-in handlers for
	GLV-1.12556 include a directory handler, a file handler (so you can
	reference individual files not in the main diretory) and
	userdirectories.

From cowan at ccil.org  Thu Dec  3 01:52:15 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 2 Dec 2020 20:52:15 -0500
Subject: Multiple Language support (was Re: [ANN] chess puzzles on gemini)
In-Reply-To: <20201202235334.GH24194@brevard.conman.org>
References: <15174901.RmvKAXdgQ5@tempete> <1648146.GX1b5dPeqx@tempete>
 <20201202235334.GH24194@brevard.conman.org>
Message-ID: <CAD2gp_TDZx6nttSHzGu9CE_pxCJnvik4W9x9m64R9GSjLO1Xxw@mail.gmail.com>

On Wed, Dec 2, 2020 at 6:53 PM Sean Conner <sean at conman.org> wrote:


> [2]     No default.  If not set, the lang paramter for text/* MIME types
>         will not be set.
>

I can't find any documentation on a lang= parameter.  Not that you need
any; most MIME-type processors don't pay attention to required vs. optional
vs. unknown parameters.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Your worships will perhaps be thinking that it is an easy thing
to blow up a dog? [Or] to write a book?
    --Don Quixote, Introduction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201202/56c4daa1/attachment-0001.htm>

From sean at conman.org  Thu Dec  3 02:05:49 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 2 Dec 2020 21:05:49 -0500
Subject: Multiple Language support (was Re: [ANN] chess puzzles on gemini)
In-Reply-To: <CAD2gp_TDZx6nttSHzGu9CE_pxCJnvik4W9x9m64R9GSjLO1Xxw@mail.gmail.com>
References: <15174901.RmvKAXdgQ5@tempete> <1648146.GX1b5dPeqx@tempete>
 <20201202235334.GH24194@brevard.conman.org>
 <CAD2gp_TDZx6nttSHzGu9CE_pxCJnvik4W9x9m64R9GSjLO1Xxw@mail.gmail.com>
Message-ID: <20201203020549.GJ24194@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> On Wed, Dec 2, 2020 at 6:53 PM Sean Conner <sean at conman.org> wrote:
> 
> > [2]     No default.  If not set, the lang paramter for text/* MIME types
> >         will not be set.
> 
> I can't find any documentation on a lang= parameter.  Not that you need
> any; most MIME-type processors don't pay attention to required vs. optional
> vs. unknown parameters.

  It's mentioned in the Gemini specification section 5.2 for text/gemini.  I
perhaps was a bit too broad setting it for all text types (and it's an easy
fix to just restrict the lang parameter to just text/gemini in my case).  It
probably won't hurt other text/* types as consumers may just ignore the
lang= parameter.

  -spc


From mieum at namu.blue  Thu Dec  3 02:17:18 2020
From: mieum at namu.blue (mieum)
Date: Thu, 03 Dec 2020 11:17:18 +0900
Subject: What should I do for Geminiworld?
In-Reply-To: <CAD2gp_SBgb=6ERgPeKMfWxQCPEoVAbHUnpMphxTbqxxrH9UN+w@mail.gmail.com>
References: <CAD2gp_QjXZxXwzf8axZVNCR-8Uq5dx_UK0krOvNw0XB0VGBndg@mail.gmail.com>
 <87eek9r6q1.fsf@dorothy.carcosa.net> <C7I4HTJ8VV77.1O1OLBVLKRUGS@maclibre>
 <CAD2gp_SBgb=6ERgPeKMfWxQCPEoVAbHUnpMphxTbqxxrH9UN+w@mail.gmail.com>
Message-ID: <C7ISFH340316.1YJXWDX8RG6LS@maclibre>

> I tried posting to the mailing list, but it's sooooo picky, I'm not 
> sure if my email went through.  (Several previous tries failed.)

Interesting. I did receive your post to the list, not sure what caused
that.

> Note that it is not an archive, but fetches and converts text on the
> fly. That way I don't have to obey the rules about setting up a PG 
> mirror.

Oh! That's clever! Those "rules" were a concern of mine as well. There
is nothing wrong with them per se, it's just that it requires a certain
level of commitment to being a steward of their data and service.


~mieum

gemini://rawtext.club/~mieum/

From stephane at sources.org  Thu Dec  3 08:22:50 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 3 Dec 2020 09:22:50 +0100
Subject: *Curated* list of servers?
In-Reply-To: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
References: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
 <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
Message-ID: <20201203082250.GA3704@sources.org>

On Thu, Dec 03, 2020 at 12:03:38AM +0500,
 Timur Ismagilov <bouncepaw2 at yandex.ru> wrote 
 a message of 1 lines which said:

>    See the Servers page on the Gemini wiki.
> 
>    => https://transjovian.org:1965/gemini/page/Servers

But it does not offer more than
<gemini://gemini.circumlunar.space/software/>. Same list and no more
curation.


From bouncepaw2 at yandex.ru  Thu Dec  3 08:36:26 2020
From: bouncepaw2 at yandex.ru (Timur Ismagilov)
Date: Thu, 03 Dec 2020 13:36:26 +0500
Subject: *Curated* list of servers?
In-Reply-To: <20201203082250.GA3704@sources.org>
References: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
 <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
 <20201203082250.GA3704@sources.org>
Message-ID: <22939451606984586@iva8-03ad76494624.qloud-c.yandex.net>

But it's a wiki and you can edit it, that's the point. Community curation is cool!

From rwagner at rw-net.de  Thu Dec  3 08:45:37 2020
From: rwagner at rw-net.de (=?UTF-8?Q?Ren=C3=A9=20Wagner?=)
Date: Thu,  3 Dec 2020 09:45:37 +0100 (CET)
Subject: *Curated* list of servers?
In-Reply-To: <DA278AA4-8D1B-4FB5-9987-149925AEFBEA@low-key.me>
References: <20201202142601.GA8350@sources.org>
 <d78b891d-85e0-4bc8-a29b-ac69fe5c9e5f@www.fastmail.com>
 <20201202162639.GA28501@sources.org><DA278AA4-8D1B-4FB5-9987-149925AEFBEA@low-key.me>
Message-ID: <20201203084537.9D82C63C05D9@dd22736.kasserver.com>

>>> There is https://github.com/kr1sp1n/awesome-gemini, which is one of
>>> those "Awesome" lists of curated software.  I don't know how
>>> "curated" it is though
>>
>>It seems that the one-liners describing the programs are just taken
>>verbatim from the official descriptions of each program. Shavit, for
>>instance, is unusable for an Internet server since it binds to
>>localhost and this is hardwired in the source code but this important
>>restriction does not appear in the list.
> 
>>It seems that the one-liners describing the programs are just taken
>>verbatim from the official descriptions of each program. 
> 
> Maybe open an issue discussing how this is an opportunity to present servers in
> a manner that makes picking them easier for end-users.  

I'd like to second that:
jump in and start a discussion if this list could be developed into a "curated list". 
I think it's important to approach such a list as a community effort.

Things have to be tested and facts compiled to a comprehensive list, 
i don't see how this could work longterm if it's crafted by a single person only.

kind regards
Ren?

From gmym at coopdot.com  Thu Dec  3 10:33:35 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Thu, 3 Dec 2020 11:33:35 +0100
Subject: Appetite for Gemini users mailing list?
In-Reply-To: <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
References: <6815cac9-a1e8-448f-8314-dfe2728a723a@www.fastmail.com>
 <C7GTZO00D3MN.15CHLTZP8AAON@stilgar>
Message-ID: <CAObwWNiJBJJ1FRcMq-adPanQVS3BgMCXRaCWfmfSwd1FfacLQQ@mail.gmail.com>

Solderpunk <solderpunk at posteo.net> wrote:

> * gemini-users: for everyday Gemini users without any special interest
>   in the technical side of things.  Announcements of new capsules,
>   projects like aggregators and "gemrings", authorship conventions,
>   advocacy/outreach, etc.  Maybe announcements of initial releases of
>   new user-oriented software.  Probably the busiest list?
>

It would be great if this was its own list. Seems like it could encourage
more activity on the protocol. I'm in favor of this being created right
away.

* gemini-dev: for people authoring Gemini software.  Discussion of
>   technical best practices, etc.
> * gemini-admin: for people running Gemini servers.  Do we actually need
>   this?  Probably low traffic, for sharing e.g. IP addresses of
>   misbehaving clients.
> * gemini-spec: for spec finalisation.  Ideally low traffic, limited
>   membership, guaranteed in advance to be permanently set read-only
>   within a few months of creation.
>

Wait to see what happens with the current list after the -users list have
been created before separating these.

* gemini-announce: very low traffic list only I can post to with
>   important announcements.
>

Where should we turn to if we have questions about an announcement?
Directly to you? Anyway, seems like a good idea.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201203/426ab496/attachment.htm>

From bjorn.warmedal at gmail.com  Thu Dec  3 13:19:28 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 3 Dec 2020 14:19:28 +0100
Subject: [ANN] Garden Gnome Society!
Message-ID: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>

AstroBotany is a thing[1], and I want to make it easier for *you* to
help out in the community garden. To do so I've created a companion
service: gemini://gardengnome.ml

It's a simple thing, but fun. Every four hours it does a slow crawl
through the community garden (I don't want to DOS AstroBotany, so
there's a lot of sleep between requests) and compiles a report on the
plants in need.

Join me in caring for the more neglected plants!

Cheers,
ew0k

[1] gemini://astrobotany.mozz.us

From luke at marmaladefoo.com  Thu Dec  3 16:07:31 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 03 Dec 2020 16:07:31 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <20201202192205.GA4592@SDF.ORG>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
Message-ID: <5FC90D43.4010207@marmaladefoo.com>



On 02-Dec-2020 19:22, mbays at sdf.org wrote:
> * Wednesday, 2020-12-02 at 09:12 +0000 - Luke Emmet<luke at marmaladefoo.com>:
>
>> Its a great start, but I'm afraid it breaks the forward and back navigation
>> in my client, and might affect other clients too. This is because each
>> rendered page has the same URL.
> Isn't it that this has exposed an incorrect assumption in the client,
> rather than a problem with (the original implementation of) GemIF?
>
> There's no assumption of idempotence in gemini, two requests to the
> same url might well return different responses. So I'd have thought
> that consecutive requests to the same url should get separate history
> items, at least if the responses aren't identical (and then to
> minimise surprise, also if they are).

I'm firmly of the camp that thinks that although there are many things 
the web got wrong ultimately, the hypertext model is basically right 
(see Roy Fieldin thesis and HATEOS etc). And indeed it is the 
established mental model for textual hypertext. Breaking the "back" 
button on the web is generally considered a bad idea and I think it is 
true on Gemini too for the same reasons.

Rather, I think we should/can make a defacto assumption of idempotence 
in Gemini. Gemini requests are incredibly similar to HTTP GET requests, 
which are the "idempotent" and dominant method of hypertext on the web. 
We don't have the equivalent of the non-idempotent POST methods in 
Gemini. But maybe there are other solutions for that, or it might come 
one day.

So repeatedly reloading the same resource, is the equivalent to a 
reload, hence when you go "back" it is back to the previous URL.

  - Luke

From me at rwv.io  Thu Dec  3 16:23:46 2020
From: me at rwv.io (Remco)
Date: Thu, 03 Dec 2020 17:23:46 +0100
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <20201130043343.GD24194@brevard.conman.org>
References: <dce7cc5e-5e58-cf95-ac20-694db7c75ad4@benaaron.dev>
 <20201129181700.61EBD63C09AB@dd22736.kasserver.com>
 <20201130043343.GD24194@brevard.conman.org>
Message-ID: <87360mrh7x.fsf@rwv.io>


2020/11/30 05:33, Sean Conner:

> It was thus said that the Great Ren? Wagner once stated:
>> I totally agree that we need a definition of what information has to be
>> passed to a CGI script by the server. Adjust scripts to honor specific
>> server implementations is a no-go.
>
>   I used RFC-3875 for the basis of my CGI support.  It defines the following
> variables to be passed to the script.
>>snip<<
>   I also define some TLS variables, but those are under discussion elsewhere
> on this thread.  These (the TLS and GEMINI variables) can be described in a
> companion document, but the base I think should be RFC-3875.  It fits quite
> well to Gemini.

Thanks for the explanation!  I'm considering adding some extra headers
to nudge closer to the spec but I still feel CGI is too HTTP focused to
just "fully" adapt it and having a clearly defined subset could be
helpful for people building servers.

Cheers,
R.

From me at rwv.io  Thu Dec  3 16:30:31 2020
From: me at rwv.io (Remco)
Date: Thu, 03 Dec 2020 17:30:31 +0100
Subject: CGI and client certificate, or do we need a CGI spec
In-Reply-To: <CAFTy05a=gMsV=qNEN_JqSZxMnvW3GKtyA1jXAy0DJWfk2NfEkA@mail.gmail.com>
References: <87k0u4xfp8.fsf@rwv.io>
 <Ml1olaxUU9fDMSRWdkOS2v1QuE4PMkM5dHHV2XEcH_rbLOHak4Hh5_1Qku_vn7rjA4upB2oEX1mrHajW2-E0D1iWpCxhvwpMl8DJWuitjFY=@protonmail.com>
 <CAFTy05a=gMsV=qNEN_JqSZxMnvW3GKtyA1jXAy0DJWfk2NfEkA@mail.gmail.com>
Message-ID: <87zh2uq2c8.fsf@rwv.io>


2020/11/30 03:32, Michael Lazar:

> On Sun, Nov 29, 2020 at 8:32 PM <colecmac at protonmail.com> wrote:
>>
>> One important thing to standardize is how TLS_CLIENT_HASH is
>> calculated. Otherwise CGI scripts will not be able to recognize
>> clients again if the server software changes.
>>
>> makeworld
>
> I think that jetforce is the odd duckling here. I'm the only one using base64
> for hashes. This was discussed a while ago on the mailing list and I declared
> that I would switch if a consensus was reached [0]. IIRC the discussion kind of
> petered out after that...
>
> So I will say right now, unless there's strong opposition, that I'm going to
> change TLS_CLIENT_HASH to "SHA256:<HASH>" where <HASH> is the uppercase hex
> representation of the certificate hash, with *no* colons in it. This change
> will be made in the next release of jetforce, with TLS_CLIENT_HASH_B64 being
> as a backwards compatible env var to make the transition easier for any existing
> CGI scripts.

I like the TLS_CLIENT_HASH to "SHA256:<HASH>" format and have
implemented that.  Thanks for the link into the archives, I missed that.

BTW, shouldn't your TLS_CLIENT_HASH_B64 be TLS_CLIENT_HASH_SHA256_B64?
I am guessing it is a SHA256 hash?

Cheers,
R.

From lambdatronic at disroot.org  Thu Dec  3 17:24:52 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Thu, 03 Dec 2020 12:24:52 -0500
Subject: variable indentation levels / hierarchy in lists
In-Reply-To: <20201202195524.wa5luicqom4e27rz@GLaDOS>
References: <20201202195524.wa5luicqom4e27rz@GLaDOS>
Message-ID: <87tut2n6or.fsf@disroot.org>


> I actually would appreciate multi-level lists up to three levels deep,
> indented with one space, or with multiple stars.
>
> * level 1
>  * level 2
>   * level 3
> OR
> * level 1
> ** level 2
> *** level 3
>
> It maintains the "check only the first three characters" limit, is
> non-breaking, and is not required for clients to implement. I am merely
> suggesting it as a *possible* change, but I am unsure whether I even
> should mention it or not because I'm generally in the "don't change the
> spec" crowd, but I feel I should at least put it forward for discussion.

I concur for all the reasons listed here. I'd prefer the multiple stars
approach (*, **, ***) though since that allows us to avoid making
leading whitespace significant and aligns well with the multiple hashes
approach that we use for headlines (#, ##, ###).

My 2c,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From lambdatronic at disroot.org  Thu Dec  3 17:44:21 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Thu, 03 Dec 2020 12:44:21 -0500
Subject: [ANN] Garden Gnome Society!
In-Reply-To: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>
References: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>
Message-ID: <87r1o6n5sa.fsf@disroot.org>

Brilliant work, Bj?rn! I try to water another community garden plant
each day, but I usually have to pick a bunch of them at random before I
find one that needs watering. Thanks for making this a MUCH easier
process.

Happy AstroGardening!
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From jordan at crowesnest.io  Thu Dec  3 22:18:23 2020
From: jordan at crowesnest.io (Jordan)
Date: Thu, 03 Dec 2020 22:18:23 +0000
Subject: *Curated* list of servers?
In-Reply-To: <22939451606984586@iva8-03ad76494624.qloud-c.yandex.net>
References: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
 <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
 <20201203082250.GA3704@sources.org>
 <22939451606984586@iva8-03ad76494624.qloud-c.yandex.net>
Message-ID: <7zZnfwuEF90zZD1QKCNy8zdf0SlNjc95JyrFAdO62Es@cp4-web-028.plabs.ch>

On Thu Dec 3, 2020 at 3:36 AM EST, Timur Ismagilov wrote:
> But it's a wiki and you can edit it, that's the point. Community
> curation i=
> s cool!
>
If it's a wiki then that is awesome, and as you said able to be edited
by the community. Also, I noticed Jetforce was not mentioned as an
option. It's a pretty good and easy to setup server software.

Jordan


From text at sdfeu.org  Thu Dec  3 22:28:24 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Thu, 03 Dec 2020 23:28:24 +0100
Subject: *Curated* list of servers?
In-Reply-To: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
References: <6642111606935601@vla5-344e18ef0bef.qloud-c.yandex.net>
Message-ID: <0cbb4ee94e594074097c268e2230a580@sdfeu.org>

On 2020-12-02 20:03, Timur Ismagilov wrote:
> See the Servers page on the Gemini wiki.
> 
> => https://transjovian.org:1965/gemini/page/Servers
> 

It seems there was an article on Wikipedia, too; still maintained as 
Draft:
https://en.wikipedia.org/wiki/Draft:Gemini_(protocol)

From norm at iwritethe.codes  Thu Dec  3 23:11:56 2020
From: norm at iwritethe.codes (=?UTF-8?Q?Norm_MacLennan?=)
Date: Thu, 3 Dec 2020 23:11:56 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <5FC90D43.4010207@marmaladefoo.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com> 
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG> 
 <5FC90D43.4010207@marmaladefoo.com> 
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
Message-ID: <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>

On Thu, 3 Dec 2020, Luke Emmet wrote:
>
> I'm firmly of the camp that thinks that although there are many things the 
> web got wrong ultimately, the hypertext model is basically right (see Roy 
> Fieldin thesis and HATEOS etc). And indeed it is the established mental model 
> for textual hypertext. Breaking the "back" button on the web is generally 
> considered a bad idea and I think it is true on Gemini too for the same 
> reasons.
>
> Rather, I think we should/can make a defacto assumption of idempotence in 
> Gemini. Gemini requests are incredibly similar to HTTP GET requests, which 
> are the "idempotent" and dominant method of hypertext on the web. We don't 
> have the equivalent of the non-idempotent POST methods in Gemini. But maybe 
> there are other solutions for that, or it might come one day.
>
> So repeatedly reloading the same resource, is the equivalent to a reload, 
> hence when you go "back" it is back to the previous URL.
>
> - Luke
>

I love a lot of the self-imposed "limitations" and simplicity of Gemini 
and I definitely still have a lot of unlearning of HTTP-based habits 
and instincts still to do.

But I will also suggest that for some folks, the best part in working in 
systems with self-imposed limitations is figuring out how to push the 
boundaries, test the limits, and basically apply creative hacks to subvert 
those limitations.

All of that being said, in the particular case of GemIF, I've already 
started "Gemini-ifying" it a bit. At the suggestion of a user who emailed 
me directly rather than replying to the thread (perhaps accidentally), I've 
converted to using "state tokens". Serialized and encoded game state in 
the URL simplifies the server side and _shouldn't_ break navigation.

There's still a "pseudo-PUT" on every action you take to update your game 
state and return to you your new state token in the form of a redirect. I 
intend to have the server pre-calculate state tokens for every exit to 
construct direct links on every page and prevent the extra 
request/redirect each time.

So in this case, I would say you are absolutely right and I just needed to 
do some unlearning of habits from other protocols, but I'm not sure I'm 
willing to categorically state all requests must be idempotent. Or perhaps
I'm just willing to agree that such a thing makes sense for the spec and 
then being surprised at the crazy things people come up with when they 
start pushing the limits.


From gemini at ur.gs  Thu Dec  3 23:20:05 2020
From: gemini at ur.gs (Nick Thomas)
Date: Thu, 03 Dec 2020 23:20:05 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
 <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
Message-ID: <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>

On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote:

> I'm not sure I'm  willing to categorically state all requests must be
> idempotent.

I have the same feeling, but I think it's well-founded. Gemini requests
don't map well to HTTP GET semantics at all - we just don't have the
safety guarantees we need for it.

A simple example - imagine I build a gemini client that prefetches all
links on the current page in the background, for performance. If
they're all HTTP GETs in principle, this is fine.

However, like any bad web 1.0 application that used links + GET instead
of form buttons + POST for actions, my browser will make astrobotany no
fun to play at all, as I simultaneously water, shake, and feed my plant
each time I visit it.

Any given Gemini link may or may not change server-side state, and it's
impossible to tell from protocol-level information. It's not a bad
thing, per se, it just isn't like GETs.

/Nick


From vidak at riseup.net  Fri Dec  4 00:21:38 2020
From: vidak at riseup.net (Blair Vidakovich)
Date: Fri, 04 Dec 2020 08:21:38 +0800
Subject: [ANN] Garden Gnome Society!
References: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>
 <mailman.1213.1607001584.477.gemini@lists.orbitalfox.eu>
Message-ID: <87blfa8lpp.fsf@riseup.net>

Bj?rn W?rmedal <bjorn.warmedal at gmail.com> writes:

> AstroBotany is a thing[1], and I want to make it easier for *you* to
> help out in the community garden. To do so I've created a companion
> service: gemini://gardengnome.ml
>
> It's a simple thing, but fun. Every four hours it does a slow crawl
> through the community garden (I don't want to DOS AstroBotany, so
> there's a lot of sleep between requests) and compiles a report on the
> plants in need.
>
> Join me in caring for the more neglected plants!
>
> Cheers,
> ew0k
>
> [1] gemini://astrobotany.mozz.us

This is awesome! I know botany from the tildeverse, but have never used
it! I was wondering, could you, or someone else, teach me how to attach
my output from astrobotany to my index page of my gemini capsule?

My gemini capsule is here: gemini://tanelorn.city/~vidak.

I notice that some people, like Shufei, on their gmiphlog, have been
able to attach their ASCII-art picture of their astrobotany plant to
their index page--I want to as well!

Or is Shufei, and others, copying and pasting the output from
astrobotany every day? Is it automatic?

Thanks in advance!

Vidak.

From bjorn.warmedal at gmail.com  Fri Dec  4 07:10:07 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Fri, 4 Dec 2020 08:10:07 +0100
Subject: [ANN] Garden Gnome Society!
In-Reply-To: <87blfa8lpp.fsf@riseup.net>
References: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>
 <mailman.1213.1607001584.477.gemini@lists.orbitalfox.eu>
 <87blfa8lpp.fsf@riseup.net>
Message-ID: <CAJScK0Kqq=H_XyJ6MweiWHZY+R3Ey_kTX-xF960kF_=t9g-c8Q@mail.gmail.com>

> Brilliant work, Bj?rn! I try to water another community garden plant
> each day, but I usually have to pick a bunch of them at random before I
> find one that needs watering. Thanks for making this a MUCH easier
> process.

Thank you, Gary! It was exactly that problem I intended to solve :)

> This is awesome! I know botany from the tildeverse, but have never used
> it! I was wondering, could you, or someone else, teach me how to attach
> my output from astrobotany to my index page of my gemini capsule?

Hey, Vidak! Good question, and I'm happy to help :)

It's surprisingly simple, actually! There are a few curl-like command
line utilities for gemini out there. When I was planning on making
this I looked at https://github.com/makeworld-the-better-one/gemget at
first. It ended up not working for me for two reasons: it doesn't
(yet) support client certificates -- which AstroBotany requires to let
you walk the community garden or visit your own plant -- and the Go
version on my Raspberry Pi was incompatible (that's probably a
solvable problem, but I would still need the client cert support).

I ended up writing my own in python3:
https://github.com/makeworld-the-better-one/gemget

Python3 is great for me, because it works on my laptop and my RPi
without needing to compile anything. This tool is *really* basic for
now. There's no error checking, it decodes everything to UTF-8 before
pushing it to stdout, and the response header line is included in the
output. And there's no server cert validation of any kind (i.e. no
known-hosts database). But it works for the purpose of fetching
AstroBotany info!

Basically: find where your browser keeps your client cert, run
"gemcall -c <path to cert> -k <path to cert key> -u
gemini://astrobotany.mozz.us/app/plant" and you'll get text output. Be
sure to not have the colour setting turned on for that client cert, as
that will ruin the experience for some people visiting your capsule.
Then you just have to figure out which lines from the output you want!
Put it in a cron job or systemd.timer if you can, and it's fully
automated.

Cheers,
ew0k

From luke at marmaladefoo.com  Fri Dec  4 07:53:47 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 04 Dec 2020 07:53:47 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
 <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
Message-ID: <5FC9EB0B.3040305@marmaladefoo.com>



On 03-Dec-2020 23:20, Nick Thomas wrote:
> On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote:
>
>> I'm not sure I'm  willing to categorically state all requests must be
>> idempotent.
> I have the same feeling, but I think it's well-founded. Gemini requests
> don't map well to HTTP GET semantics at all - we just don't have the
> safety guarantees we need for it.
>
> A simple example - imagine I build a gemini client that prefetches all
> links on the current page in the background, for performance. If
> they're all HTTP GETs in principle, this is fine.
>
> However, like any bad web 1.0 application that used links + GET instead
> of form buttons + POST for actions, my browser will make astrobotany no
> fun to play at all, as I simultaneously water, shake, and feed my plant
> each time I visit it.

Well for all its retro quirky ascii art cuteness, Astrobotany is a bit 
of an outlier in this respect. It can get away with "abusing" gemini 
links only because it sits behind a layer of authentication, that 
restricts access to the links within the application. It would be a much 
safer application to implement in Gemini had a proper non-cacheable 
non-idempotent method.

For example, consider that GUS (and other agents) visit all our sites on 
a semi-regular basis. this means that all the links will be activated 
many times. If there is a link somewhere

=> liveendpoint click this link if you liked my article

this will be activated an aribitrary number of times, and is a mismatch 
for gemini as links in a public hypertext system are - in general - 
idempotent.

If some other contrarian gemini author put 20 (or 1000) links to that 
live end point on their gemsite, whenever GUS comes to visit, I'm going 
to get 20 new "likes"

One other point that is relevant here is that the "input" method (meta 
10 and 11) do not really help, since again they are implemented as 
parameterised links (/path/to/endpoint?inputcontent). As such they can 
be reused as persistable links.

But this is all we have in Gemini, so authors and developers do their 
best to work around the natural restrictions.

Its the same on the web - there is a limit to the types of application 
you can implement with just normal links. If you want to change state, 
you need a post method (or equivalent/JSON etc).

I'd be interested in what a non-cacheable, non-persistable, 
non-idempotent "post" type method would look like in Gemini, but at the 
moment we just have sort of hacks to try to fake it as best we can in 
some limited scenarios.

  - Luke


______________________________________

From come at chilliet.eu  Fri Dec  4 09:55:43 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Fri, 04 Dec 2020 10:55:43 +0100
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
Message-ID: <32807836.rMiUFspvT1@tempete>

Le vendredi 4 d?cembre 2020, 00:20:05 CET Nick Thomas a ?crit :
> A simple example - imagine I build a gemini client that prefetches all
> links on the current page in the background, for performance.

I just wanted to point out that this is forbidden by the specification:
?Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.).?

C?me



From petite.abeille at gmail.com  Fri Dec  4 10:03:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 11:03:18 +0100
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <32807836.rMiUFspvT1@tempete>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <32807836.rMiUFspvT1@tempete>
Message-ID: <183A985A-B649-4F36-BA3E-F29F95E1DB81@gmail.com>



> On Dec 4, 2020, at 10:55, C?me Chilliet <come at chilliet.eu> wrote:
> 
> I just wanted to point out that this is forbidden by the specification:

Go ahead, try to stop me :D

P.S. Has something changed in the Reply-To behavior of the mailing list? It seems to be missing the Reply-To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> header now, which it uses to sport. Accidental? On purpose? What gives?


From petite.abeille at gmail.com  Fri Dec  4 10:30:50 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 11:30:50 +0100
Subject: Reply-To mailing list?
In-Reply-To: <183A985A-B649-4F36-BA3E-F29F95E1DB81@gmail.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <32807836.rMiUFspvT1@tempete>
 <183A985A-B649-4F36-BA3E-F29F95E1DB81@gmail.com>
Message-ID: <27D32D42-20C9-49A2-84F5-9651C4DCD7E4@gmail.com>



> On Dec 4, 2020, at 11:03, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> P.S. Has something changed in the Reply-To behavior of the mailing list? It seems to be missing the Reply-To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> header now, which it used to sport. Accidental? On purpose? What gives?

The change seems to have occurred silently around November 22nd, end-of-day... thoughts?
 
( And please, let's not drag Mr Rosenthal into this :)

From me at dejanstrbac.com  Fri Dec  4 11:28:03 2020
From: me at dejanstrbac.com (Dejan Strbac)
Date: Fri, 04 Dec 2020 11:28:03 GMT
Subject: Reply-To mailing list?
In-Reply-To: <27D32D42-20C9-49A2-84F5-9651C4DCD7E4@gmail.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <32807836.rMiUFspvT1@tempete>
 <183A985A-B649-4F36-BA3E-F29F95E1DB81@gmail.com>
 <27D32D42-20C9-49A2-84F5-9651C4DCD7E4@gmail.com>
Message-ID: <2fd03f08-8e6a-dfac-593b-331ae3ee4b35@dejanstrbac.com>


On 04.12.20 11:30, Petite Abeille wrote:
> 
> 
>> On Dec 4, 2020, at 11:03, Petite Abeille <petite.abeille at gmail.com> wrote:
>>
>> P.S. Has something changed in the Reply-To behavior of the mailing list? It seems to be missing the Reply-To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> header now, which it used to sport. Accidental? On purpose? What gives?
> 
> The change seems to have occurred silently around November 22nd, end-of-day... thoughts?
>   
> ( And please, let's not drag Mr Rosenthal into this :)
> 

We've suggested that change to the postmaster (as migadu.com).

Reply-To header gets DKIM signed. Modifying or appending the Reply-To 
header breaks DKIM signature which along with failing SPF will make for 
certain DMARC failure and possibly rejection. That has lead to forced 
unsubscribing.

The mailing list (mailman) does not know the reason for message 
rejection (DMARC policy) and threats that as if the subscriber is 
unreachable.


--
????? ??????


From petite.abeille at gmail.com  Fri Dec  4 11:43:51 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 12:43:51 +0100
Subject: Reply-To mailing list?
In-Reply-To: <2fd03f08-8e6a-dfac-593b-331ae3ee4b35@dejanstrbac.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <32807836.rMiUFspvT1@tempete>
 <183A985A-B649-4F36-BA3E-F29F95E1DB81@gmail.com>
 <27D32D42-20C9-49A2-84F5-9651C4DCD7E4@gmail.com>
 <2fd03f08-8e6a-dfac-593b-331ae3ee4b35@dejanstrbac.com>
Message-ID: <6624647B-A587-4688-A86F-6948D9463B92@gmail.com>



> On Dec 4, 2020, at 12:28, Dejan Strbac <me at dejanstrbac.com> wrote:
> 
> We've suggested that change to the postmaster (as migadu.com).

( Who is "we"? )

Very unfortunate move, for the wrong reasons, with unfortunate consequences.

DKIM+DMARC+SPF configuration quirks aside -and ignoring the reality that all/most other mailing lists do seem to manage just fine- assuming this list is a DISCUSSION list, replies should go to the list. 










From me at dejanstrbac.com  Fri Dec  4 11:53:38 2020
From: me at dejanstrbac.com (Dejan Strbac)
Date: Fri, 04 Dec 2020 11:53:38 GMT
Subject: Reply-To mailing list?
In-Reply-To: <6624647B-A587-4688-A86F-6948D9463B92@gmail.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <32807836.rMiUFspvT1@tempete>
 <183A985A-B649-4F36-BA3E-F29F95E1DB81@gmail.com>
 <27D32D42-20C9-49A2-84F5-9651C4DCD7E4@gmail.com>
 <2fd03f08-8e6a-dfac-593b-331ae3ee4b35@dejanstrbac.com>
 <6624647B-A587-4688-A86F-6948D9463B92@gmail.com>
Message-ID: <630a017c-3ab0-1ec1-5ff6-951d4ae91fdd@dejanstrbac.com>



> DKIM+DMARC+SPF configuration quirks aside -and ignoring the reality that all/most other mailing lists do seem to manage just fine- assuming this list is a DISCUSSION list, replies should go to the list.

SPF / DMARC aside, at least DKIM should not fail when mails get 
forwarded through a mailing list, proving authenticity.

Email client should detect it's a mailing list and offer a "Reply-List" 
option. I am not sure Apple Mail (your client?) supports that, there is 
an open question there:

https://discussions.apple.com/thread/251508297

e.g. Thunderbird handles mailing list messages correctly and provides 
automatically a Reply-List option based on the List- headers.



--
????? ??????


From petite.abeille at gmail.com  Fri Dec  4 12:10:38 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 13:10:38 +0100
Subject: Reply-To mailing list?
In-Reply-To: <630a017c-3ab0-1ec1-5ff6-951d4ae91fdd@dejanstrbac.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <32807836.rMiUFspvT1@tempete>
 <183A985A-B649-4F36-BA3E-F29F95E1DB81@gmail.com>
 <27D32D42-20C9-49A2-84F5-9651C4DCD7E4@gmail.com>
 <2fd03f08-8e6a-dfac-593b-331ae3ee4b35@dejanstrbac.com>
 <6624647B-A587-4688-A86F-6948D9463B92@gmail.com>
 <630a017c-3ab0-1ec1-5ff6-951d4ae91fdd@dejanstrbac.com>
Message-ID: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>



> On Dec 4, 2020, at 12:53, Dejan Strbac <me at dejanstrbac.com> wrote:
> 
> Apple Mail

( Apple's Mail helpfully detects 'List-Unsubscribe:' and tantalizingly  dare you to :^)

Irrespectively of MUA, could we revert back to the setup pre November 22nd, and fix the rest of the stack instead.



From luke at marmaladefoo.com  Fri Dec  4 12:25:10 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 04 Dec 2020 12:25:10 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <32807836.rMiUFspvT1@tempete>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <32807836.rMiUFspvT1@tempete>
Message-ID: <5FCA2AA6.6080200@marmaladefoo.com>



On 04-Dec-2020 09:55, C?me Chilliet wrote:
> Le vendredi 4 d?cembre 2020, 00:20:05 CET Nick Thomas a ?crit :
>> A simple example - imagine I build a gemini client that prefetches all
>> links on the current page in the background, for performance.
> I just wanted to point out that this is forbidden by the specification:
> ?Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.).?

I get the strong recommendation on this - and I take this to be a strong 
recommendation/exhortation for human facing clients behaviour. Its not a 
protocol invariant that must be preserved to ensure correct transmission 
or anything.

Some user facing clients (for example one of the web proxies) load 
linked images as an "experimental" feature.

But I get that there is a strong cultural exhortation against the 
expectation that images will be loaded. Personally for a human facing 
client I prefer that the images are not automatically loaded, or 
expected by the author that they will be loaded (unlike the web).

And we need to consider that the ecosystem does not just contain human 
facing clients - there are proxies, archivers, indexers, which are also 
Gemini clients. They will be traversing geminispace as well, at their 
own time, schedule and frequency.

  - Luke

From fox at orbitalfox.eu  Fri Dec  4 13:28:57 2020
From: fox at orbitalfox.eu (=?UTF-8?B?b3JiaWZ4IPCfpoo=?=)
Date: Fri, 4 Dec 2020 13:28:57 +0000
Subject: Reply-To mailing list?
In-Reply-To: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
Message-ID: <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>

> Irrespectively of MUA, could we revert back to the setup pre November 22nd, and fix the rest of the stack instead.

I don't think the point for the change was understood here.

When Mailman is set to assert the Reply-To header to "list", it will invalidate the mail signature by many servers making others regard the email as forged. This was a slip up on this list; other lists on this server as set to not alter the Reply-To header.

It is my opinion, and that of others, that this is best solved by mail clients observing the List-* headers.

Further more, I recommend the use of "reply-all" as a default, because it is possible for a list to receive an email from someone who is not subscribed. With reply-all, your email client shall include both the person and the list, thus eliminating the reply-to issue. It also let's the recipient know they were being addressed in the response (commonly known as "mentioned").

From stephane at sources.org  Fri Dec  4 13:51:38 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 4 Dec 2020 14:51:38 +0100
Subject: IDN with Gemini?
Message-ID: <20201204135138.GA684@sources.org>

The specification
<gemini://gemini.circumlunar.space/docs/specification.gmi> seems
silent about IDN (Internationalized Domain Names, domains in Unicode,
see RFC 5890). The spec mentions URI (not 3986) but not IRI
(Internationalized Resource Identifiers, RFC 3987).

Therefore, it is not clear what servers and clients should do (send an
IRI, or accept IRI but convert it to URI or something else). A test
with some clients seem to indicate it does not work (tested at
<gemini://g?meaux.bortzmeyer.org/>):

* Amfora claims the domain name does not exist (it does exist),
"Failed to connect to the server: dial tcp: lookup
g?meaux.bortzmeyer.org: no such host."

* AV-98 does not protest and sends the IRI but the server I use
(Gemserv) fails to match either using the UTF-8 form (U-label) or the
Punycode one (A-label),

- Bombadillo says "Found "?", expected EOF"

What is the normal behaviour?


From petite.abeille at gmail.com  Fri Dec  4 14:03:10 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 15:03:10 +0100
Subject: Reply-To mailing list?
In-Reply-To: <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
 <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
Message-ID: <5A425D01-CC82-48A8-A04A-01D8EB216B3F@gmail.com>


> On Dec 4, 2020, at 14:28, orbifx ? <fox at orbitalfox.eu> wrote:
> 
> it will invalidate the mail signature

True. But this will happen anyway (e.g. attachment stripping or whatnot). remove_dkim_headers to the rescue? Sender Rewriting Scheme (SRS)?

> best solved by mail clients observing the List-* headers

True. Sadly, List-* headers support is, hmmm, uneven.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/d8832674/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pacman.gif
Type: image/gif
Size: 2025 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/d8832674/attachment.gif>

From petite.abeille at gmail.com  Fri Dec  4 14:18:52 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 15:18:52 +0100
Subject: Reply-To mailing list?
In-Reply-To: <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
 <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
Message-ID: <F881FA79-F7A2-4637-ADF7-C92233CD5DB0@gmail.com>



> On Dec 4, 2020, at 14:28, orbifx ? <fox at orbitalfox.eu <mailto:fox at orbitalfox.eu>> wrote:
> 
> use of "reply-all" as a default

mwahahaha , I presume you never witnessed an email storm :D

https://en.wikipedia.org/wiki/Email_storm <https://en.wikipedia.org/wiki/Email_storm>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/f8b770d7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: he-replied-all-new-yorker-cartoon_u-l-pysimf0.jpg
Type: image/jpeg
Size: 23656 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/f8b770d7/attachment-0001.jpg>

From delta.mu.alpha at gmail.com  Fri Dec  4 14:40:38 2020
From: delta.mu.alpha at gmail.com (David Ashby)
Date: Fri, 4 Dec 2020 09:40:38 -0500
Subject: Reply-To mailing list?
In-Reply-To: <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
 <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
Message-ID: <CAO2WFq8mZXbOc-tZO3Uctyzz35M8PNna7qJ8jzzg2drJPjaoBw@mail.gmail.com>

Ah, that would explain why so many of the emails to this list were getting
thrown into my spam folder before now. Leaving it as it is help
alleviate that, right?

On Fri, Dec 4, 2020 at 8:30 AM orbifx ? <fox at orbitalfox.eu> wrote:

> > Irrespectively of MUA, could we revert back to the setup pre November
> 22nd, and fix the rest of the stack instead.
>
> I don't think the point for the change was understood here.
>
> When Mailman is set to assert the Reply-To header to "list", it will
> invalidate the mail signature by many servers making others regard the
> email as forged. This was a slip up on this list; other lists on this
> server as set to not alter the Reply-To header.
>
> It is my opinion, and that of others, that this is best solved by mail
> clients observing the List-* headers.
>
> Further more, I recommend the use of "reply-all" as a default, because it
> is possible for a list to receive an email from someone who is not
> subscribed. With reply-all, your email client shall include both the person
> and the list, thus eliminating the reply-to issue. It also let's the
> recipient know they were being addressed in the response (commonly known as
> "mentioned").
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/6b904e32/attachment.htm>

From cowan at ccil.org  Fri Dec  4 14:46:40 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 4 Dec 2020 09:46:40 -0500
Subject: IDN with Gemini?
In-Reply-To: <20201204135138.GA684@sources.org>
References: <20201204135138.GA684@sources.org>
Message-ID: <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>

On Fri, Dec 4, 2020 at 8:53 AM Stephane Bortzmeyer <stephane at sources.org>
wrote:

Therefore, it is not clear what servers and clients should do (send an
> IRI, or accept IRI but convert it to URI or something else).
>

It seems clear from the behavior of web browsers that the Right Thing is to
convert all IDNs to Punycode before putting them on the wire.  By the same
token, all non-ASCII characters in other parts should be UTF-8 encoded and
then %-encoded before transmission.  This applies both to IRIs entered by
hand and IRIs appearing in links.


> * Amfora claims the domain name does not exist (it does exist),
> "Failed to connect to the server: dial tcp: lookup
> g?meaux.bortzmeyer.org <http://xn--gmeaux-bva.bortzmeyer.org>: no such
> host."
>

I'm pretty sure this is because no punycoding is being done in the DNS, and
it's probably getting the UTF-8 encoding instead of "
xn--gmeaux-bva.bortzmeyer.org".  When I ask Lagrange to connect to the
punycoded form explicitly, your server does not recognize it as "self" and
replies with "Proxy Request Refused".

I can't account for the behavior of the other servers easily.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
One art / There is / No less / No more
To do / All things / With sparks / Galore   --Douglas Hofstadter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/77b4431f/attachment.htm>

From petite.abeille at gmail.com  Fri Dec  4 14:56:36 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 15:56:36 +0100
Subject: Reply-To mailing list?
In-Reply-To: <CAO2WFq8mZXbOc-tZO3Uctyzz35M8PNna7qJ8jzzg2drJPjaoBw@mail.gmail.com>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
 <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
 <CAO2WFq8mZXbOc-tZO3Uctyzz35M8PNna7qJ8jzzg2drJPjaoBw@mail.gmail.com>
Message-ID: <0F2F3DBC-4EC4-495C-8246-1D2C80891790@gmail.com>



> On Dec 4, 2020, at 15:40, David Ashby <delta.mu.alpha at gmail.com> wrote:
> 
> ... why so many of the emails to this list were getting thrown into my spam folder ...

As seen through the lenses of gmail's web ui presumably?

FWIW, accessing gmail through IMAP doesn't have such shortcoming.


From stephane at sources.org  Fri Dec  4 15:00:30 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 4 Dec 2020 16:00:30 +0100
Subject: IDN with Gemini?
In-Reply-To: <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
Message-ID: <20201204150029.GA4584@sources.org>

On Fri, Dec 04, 2020 at 09:46:40AM -0500,
 John Cowan <cowan at ccil.org> wrote 
 a message of 93 lines which said:

> It seems clear from the behavior of web browsers that the Right Thing is to
> convert all IDNs to Punycode before putting them on the wire.

I disagree. This is not because HTTP does it that way that everyone
else should. IMHO, the right behaviour would be:

* parse the IRI and extract the domain name
* convert it to Punycode
* do the DNS lookup
* connect to the IP address and send the IRI as request

This leaves open interesting issues such as Unicode normalization but
it would be more natural for a new protocol, free of HTTP legacy.

From cowan at ccil.org  Fri Dec  4 15:08:07 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 4 Dec 2020 10:08:07 -0500
Subject: Reply-To mailing list?
In-Reply-To: <CAO2WFq8mZXbOc-tZO3Uctyzz35M8PNna7qJ8jzzg2drJPjaoBw@mail.gmail.com>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
 <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
 <CAO2WFq8mZXbOc-tZO3Uctyzz35M8PNna7qJ8jzzg2drJPjaoBw@mail.gmail.com>
Message-ID: <CAD2gp_TZ10qWqpvH49XNfOHemLoGdydKmtd_Eqewnzy6pz3oGA@mail.gmail.com>

On Fri, Dec 4, 2020 at 9:40 AM David Ashby <delta.mu.alpha at gmail.com> wrote:

> Ah, that would explain why so many of the emails to this list were getting
> thrown into my spam folder before now. Leaving it as it is help
> alleviate that, right?
>

I had to tell Gmail that traffic sent to this list is never spam.  So far I
haven't been bothered, but it's annoying to get the big gray warning on
many (not all) messages.

> On Fri, Dec 4, 2020 at 8:30 AM orbifx ? <fox at orbitalfox.eu> wrote:
>
>> > Irrespectively of MUA, could we revert back to the setup pre November
>> 22nd, and fix the rest of the stack instead.
>>
>> I don't think the point for the change was understood here.
>>
>> When Mailman is set to assert the Reply-To header to "list", it will
>> invalidate the mail signature by many servers making others regard the
>> email as forged. This was a slip up on this list; other lists on this
>> server as set to not alter the Reply-To header.
>>
>
Quite apart from this point, the arguments of Chip Rosenthal's classic
"Reply-to Munging Considered Harmful" <
https://unicom.crosenthal.com/pw/reply-to-harmful.html> are still as sound
as ever, though the problem of "brain-dead mailers" that don't support both
Reply and Reply All is probably no longer an issue.  I QFT his summary,
though I recommend reading the document in full:

Many people want to munge Reply-To headers. They believe it makes
reply-to-list easier, and it encourages more list traffic. It really does
neither, and is a very poor idea. Reply-To munging suffers from the
following problems:

   - It violates the principle of minimal munging.
   - It provides no benefit to the user of a reasonable mailer.
   - It limits a subscriber's freedom to choose how he or she will direct a
   response.
   - It actually reduces functionality for the user of a reasonable mailer.
   - It removes important information, which can make it impossible to get
   back to the message sender.
   - It penalizes the person with a reasonable mailer in order to coddle
   those running brain-dead software.
   - It violates the principle of least work because it complicates the
   procedure for replying to messages.
   - It violates the principle of least surprise because it changes the way
   a mailer works.
   - It violates the principle of least damage, and it encourages a failure
   mode that can be extremely embarrassing -- or worse.
   - Your subscribers don't want you to do it. Or, at least the ones who
   have bothered to read the docs for their mailer don't want you to do it.

For this list I will emphasize the next to last point.  I frequently screw
up and choose Reply instead of Reply All.  The recipient often asks me if I
meant to send it to the list, and one of us then does it: the situation is
fully recovered from.  Choosing Reply All in place of Reply cannot be
recovered from, and can have social consequences anywhere from temporary
embarrassment up to a "career-limiting move".

(For future reference, if you get an email from me beginning with "(Private
Message)" in response to a list posting it is truly private; if not, it is
me screwing up.)

In addition to Chip's points, I would add the weight of RFC 2822, "Internet
Message Format" (which didn't yet exist when Chip wrote):  "When the
"Reply-To:" field is present, it indicates the mailbox(es) to which the
author of the message suggests that replies be sent."  Mailing list
software is not "the author of the message".



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time.     --robison who's at texas
dot net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/6084f3d5/attachment-0001.htm>

From petite.abeille at gmail.com  Fri Dec  4 15:20:16 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 4 Dec 2020 16:20:16 +0100
Subject: Reply-To mailing list?
In-Reply-To: <CAD2gp_TZ10qWqpvH49XNfOHemLoGdydKmtd_Eqewnzy6pz3oGA@mail.gmail.com>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
 <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
 <CAO2WFq8mZXbOc-tZO3Uctyzz35M8PNna7qJ8jzzg2drJPjaoBw@mail.gmail.com>
 <CAD2gp_TZ10qWqpvH49XNfOHemLoGdydKmtd_Eqewnzy6pz3oGA@mail.gmail.com>
Message-ID: <7837F909-08D9-4F24-A7AD-9FB510EB70BD@gmail.com>



> On Dec 4, 2020, at 16:08, John Cowan <cowan at ccil.org> wrote:
> 
>  Chip Rosenthal's classic "Reply-to Munging Considered Harmful" 

Let him rest in peace. 

?Considered Harmful? Essays Considered Harmful
https://meyerweb.com/eric/comment/chech.html

>  Mailing list software is not "the author of the message".

What's the PURPOSE of a mailing list but to foster DISCUSSION?

Why to impede its raison d'?tre?

IOTD (Idiom of the day):

https://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_the_face

From cowan at ccil.org  Fri Dec  4 15:58:35 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 4 Dec 2020 10:58:35 -0500
Subject: Reply-To mailing list?
In-Reply-To: <7837F909-08D9-4F24-A7AD-9FB510EB70BD@gmail.com>
References: <47C0FC2D-B142-4640-B3D8-FA5108778963@gmail.com>
 <010b3087-bd0d-2abc-c496-0519f308f674@orbitalfox.eu>
 <CAO2WFq8mZXbOc-tZO3Uctyzz35M8PNna7qJ8jzzg2drJPjaoBw@mail.gmail.com>
 <CAD2gp_TZ10qWqpvH49XNfOHemLoGdydKmtd_Eqewnzy6pz3oGA@mail.gmail.com>
 <7837F909-08D9-4F24-A7AD-9FB510EB70BD@gmail.com>
Message-ID: <CAD2gp_Q=8xHeZpruR9v6B0T30WBAaqx-CBnr+khn0ibpcvFGAw@mail.gmail.com>

On Fri, Dec 4, 2020 at 10:20 AM Petite Abeille <petite.abeille at gmail.com>
wrote:


> >  Chip Rosenthal's classic "Reply-to Munging Considered Harmful"
>
> Let him rest in peace.
>

"Death will not release you.  (Even if you die.)"  --rule 0 of the Los
Angeles Science Fantasy Society

(Has he in fact died since 2016?  He has a common name, but I can't find
anything that looks like an obituary.)

?Considered Harmful? Essays Considered Harmful
> https://meyerweb.com/eric/comment/chech.html


I respond to that with the two laws of FidoNet:

1. Thou shalt not be excessively annoying.
2. Thou shalt not be too easily annoyed.

> >  Mailing list software is not "the author of the message".
>
> What's the PURPOSE of a mailing list but to foster DISCUSSION?
>

True.  But not all discussion is best held in public.  Some is off-topic,
some would offend certain list members, some is potentially slander.

In any case, this is a religious issue, and I have no desire to start a
religious war, so this is my last post on this topic.




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/5df384ea/attachment.htm>

From mbays at sdf.org  Fri Dec  4 18:24:58 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Fri, 4 Dec 2020 19:24:58 +0100
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <5FC9EB0B.3040305@marmaladefoo.com>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
 <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <5FC9EB0B.3040305@marmaladefoo.com>
Message-ID: <20201204182458.46e73i6dcwzqphat@localhost>

* Friday, 2020-12-04 at 07:53 +0000 - Luke Emmet <luke at marmaladefoo.com>:

> On 03-Dec-2020 23:20, Nick Thomas wrote:
> > On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote:
> > > I'm not sure I'm  willing to categorically state all requests must 
> > > be idempotent.
> 
> Astrobotany is a bit of an outlier in this respect. It can get away 
> with "abusing" gemini links only because it sits behind a layer of 
> authentication, that restricts access to the links within the 
> application.

Actually, this might be a good convention: we could declare that any 
gemini request should be treated as idempotent, i.e. GETlike, *unless* 
the server is sent a client certificate as part of the connection 
handshake (for the original connection, in the case of session 
resumption).

It's a little arbitrary as a dividing line, and could cause difficulties 
on both sides. But it does make sense that unauthenticated connections 
shouldn't cause state changes, and although there have been experiments 
with alternatives, client certificates seem to be the accepted 
geminiacal method for authentication.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/d1369e4e/attachment.sig>

From colecmac at protonmail.com  Fri Dec  4 18:36:00 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 04 Dec 2020 18:36:00 +0000
Subject: IDN with Gemini?
In-Reply-To: <20201204150029.GA4584@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
Message-ID: <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>

> -   parse the IRI and extract the domain name
> -   convert it to Punycode
> -   do the DNS lookup
> -   connect to the IP address and send the IRI as request

I feel like this is probably the most intuitive method. Only
use punycoding when it's a necessity, like for DNS lookups.

What about link lines though? I think that clients should
accept both punycoded and Unicode domains in links. Convert
all links' domain to punycode for DNS, then convert all links'
domain to Unicode for sending. That seems a bit complicated,
but from an author perspective it makes sense to support both.

makeworld

From vidak at riseup.net  Fri Dec  4 00:21:38 2020
From: vidak at riseup.net (Blair Vidakovich)
Date: Fri, 04 Dec 2020 08:21:38 +0800
Subject: [ANN] Garden Gnome Society!
References: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>
 <mailman.1213.1607001584.477.gemini@lists.orbitalfox.eu>
Message-ID: <87blfa8lpp.fsf@riseup.net>

Bj?rn W?rmedal <bjorn.warmedal at gmail.com> writes:

> AstroBotany is a thing[1], and I want to make it easier for *you* to
> help out in the community garden. To do so I've created a companion
> service: gemini://gardengnome.ml
>
> It's a simple thing, but fun. Every four hours it does a slow crawl
> through the community garden (I don't want to DOS AstroBotany, so
> there's a lot of sleep between requests) and compiles a report on the
> plants in need.
>
> Join me in caring for the more neglected plants!
>
> Cheers,
> ew0k
>
> [1] gemini://astrobotany.mozz.us

This is awesome! I know botany from the tildeverse, but have never used
it! I was wondering, could you, or someone else, teach me how to attach
my output from astrobotany to my index page of my gemini capsule?

My gemini capsule is here: gemini://tanelorn.city/~vidak.

I notice that some people, like Shufei, on their gmiphlog, have been
able to attach their ASCII-art picture of their astrobotany plant to
their index page--I want to as well!

Or is Shufei, and others, copying and pasting the output from
astrobotany every day? Is it automatic?

Thanks in advance!

Vidak.

From gemini at ur.gs  Fri Dec  4 19:40:57 2020
From: gemini at ur.gs (Nick Thomas)
Date: Fri, 04 Dec 2020 19:40:57 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <20201204182458.46e73i6dcwzqphat@localhost>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
 <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <5FC9EB0B.3040305@marmaladefoo.com>
 <20201204182458.46e73i6dcwzqphat@localhost>
Message-ID: <C191AE1F-A7BE-4455-A393-2EA69D403DFE@ur.gs>



On 4 December 2020 18:24:58 GMT+00:00, mbays at sdf.org wrote:
>* Friday, 2020-12-04 at 07:53 +0000 - Luke Emmet
><luke at marmaladefoo.com>:
>
>> On 03-Dec-2020 23:20, Nick Thomas wrote:
>> > On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote:
>> > > I'm not sure I'm  willing to categorically state all requests
>must 
>> > > be idempotent.
>> 
>> Astrobotany is a bit of an outlier in this respect. It can get away 
>> with "abusing" gemini links only because it sits behind a layer of 
>> authentication, that restricts access to the links within the 
>> application.
>
>Actually, this might be a good convention: we could declare that any 
>gemini request should be treated as idempotent, i.e. GETlike, *unless* 
>the server is sent a client certificate as part of the connection 
>handshake (for the original connection, in the case of session 
>resumption).

I've been mulling over this one a bit - the search engine example is very good.

Client certificates aren't the worst heuristic here, but i do see the potential for false positives & negatives.

Now we have robots.txt, we *could* say that non-idempotent requests (state-changing ones in general, really) ought to be protected in there. That ups the importance of any crawler actually paying attention to it - and my hypothetical, but spec-forbidden, eager loading client could use it to behave safely too (it could be reimagined as a local caching proxy to work around the prohibition on following links without user interaction, i guess).

This feels more appropriate to me than the client certificate heuristic, since it's *possible* for robots.txt to make conforming clients be safe 100% of the time.

/Nick

From sean at conman.org  Fri Dec  4 21:28:24 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 4 Dec 2020 16:28:24 -0500
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <20201204182458.46e73i6dcwzqphat@localhost>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
 <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <5FC9EB0B.3040305@marmaladefoo.com>
 <20201204182458.46e73i6dcwzqphat@localhost>
Message-ID: <20201204212824.GK24194@brevard.conman.org>

It was thus said that the Great mbays at sdf.org once stated:
> 
> Actually, this might be a good convention: we could declare that any 
> gemini request should be treated as idempotent, i.e. GETlike, *unless* 
> the server is sent a client certificate as part of the connection 
> handshake (for the original connection, in the case of session 
> resumption).

  Define "state change", because this link on my server:

	gemini://gemini.conman.org/qotd

literally makes a state change on every request (it pulls up the next
quote, and it tracks the number across restarts).

  -spc


From colecmac at protonmail.com  Fri Dec  4 21:42:29 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 04 Dec 2020 21:42:29 +0000
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <15174901.RmvKAXdgQ5@tempete>
References: <15174901.RmvKAXdgQ5@tempete>
Message-ID: <xIqRtF4da9wVo6MZx9ag7MUQQ651su6gypaxrMT_6r8qpRXYlEYEyWFxGGf7ty-ZTHZc0ziyQKN4ygwKbqJ76SP1I_msOT7Ow0I0ILIZxYc=@protonmail.com>

This is super cool! Nice idea, and good use of Unicode and the chess.com
API. The chess icons are kinda of thin in my terminal, but that's on me I
guess.

> PS: and yes, it does mean I managed to use SNI to host several domain
> on the same server.

How did you do this? I've seen some general SNI proxies that would probably
work, but I'm interested in your specific setup.


Cheers,
makeworld

From sean at conman.org  Fri Dec  4 22:12:48 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 4 Dec 2020 17:12:48 -0500
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <xIqRtF4da9wVo6MZx9ag7MUQQ651su6gypaxrMT_6r8qpRXYlEYEyWFxGGf7ty-ZTHZc0ziyQKN4ygwKbqJ76SP1I_msOT7Ow0I0ILIZxYc=@protonmail.com>
References: <15174901.RmvKAXdgQ5@tempete>
 <xIqRtF4da9wVo6MZx9ag7MUQQ651su6gypaxrMT_6r8qpRXYlEYEyWFxGGf7ty-ZTHZc0ziyQKN4ygwKbqJ76SP1I_msOT7Ow0I0ILIZxYc=@protonmail.com>
Message-ID: <20201204221248.GL24194@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> > PS: and yes, it does mean I managed to use SNI to host several domain
> > on the same server.
> 
> How did you do this? I've seen some general SNI proxies that would probably
> work, but I'm interested in your specific setup.

  My server [1] uses libtls [2] and to support multiple hosts, you need to
assign multiple cert/key pairs per interface.  you first call
tls_config_set_keypair_file() for the first cert/key, then call
tls_config_add_keypair_file() for each additional cert/key you want to
support.  I expect it to be similar to other TLS libraries out there.

  -spc

[1]	https://github.com/spc476/GLV-1.12556

[2]	From the LibreSSL distribution

From come at chilliet.eu  Fri Dec  4 22:32:23 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Fri, 04 Dec 2020 23:32:23 +0100
Subject: [ANN] chess puzzles on gemini
In-Reply-To: <xIqRtF4da9wVo6MZx9ag7MUQQ651su6gypaxrMT_6r8qpRXYlEYEyWFxGGf7ty-ZTHZc0ziyQKN4ygwKbqJ76SP1I_msOT7Ow0I0ILIZxYc=@protonmail.com>
References: <15174901.RmvKAXdgQ5@tempete>
 <xIqRtF4da9wVo6MZx9ag7MUQQ651su6gypaxrMT_6r8qpRXYlEYEyWFxGGf7ty-ZTHZc0ziyQKN4ygwKbqJ76SP1I_msOT7Ow0I0ILIZxYc=@protonmail.com>
Message-ID: <2133385.O43zesUHzD@tempete>

Le vendredi 4 d?cembre 2020, 22:42:29 CET colecmac at protonmail.com a ?crit :
> > PS: and yes, it does mean I managed to use SNI to host several domain
> > on the same server.
> 
> How did you do this? I've seen some general SNI proxies that would probably
> work, but I'm interested in your specific setup.

I used the SNI_server_certs of the SSL context of the PHP stream, instead of the local_cert/local_key pair.
Sadly this option is not documented in the PHP documentation but I?ve found information about it on the web.

For each domain you need to cat the cert and the key together in a unique pem file, and then in SNI_server_certs you pass an array with domains as key and certificate path as value.

You can read my code here: gemini://code.lanterne.chilliet.eu/
The SNI bit is in gemini://code.lanterne.chilliet.eu/vendor/mcmic/gemini-server/src/Server.php

C?me



From lokesh at low-key.me  Sat Dec  5 01:22:11 2020
From: lokesh at low-key.me (Lokesh Krishna)
Date: Sat, 05 Dec 2020 06:52:11 +0530
Subject: [ANN] Garden Gnome Society!
In-Reply-To: <CAJScK0Kqq=H_XyJ6MweiWHZY+R3Ey_kTX-xF960kF_=t9g-c8Q@mail.gmail.com>
References: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>
 <mailman.1213.1607001584.477.gemini@lists.orbitalfox.eu>
 <87blfa8lpp.fsf@riseup.net>
 <CAJScK0Kqq=H_XyJ6MweiWHZY+R3Ey_kTX-xF960kF_=t9g-c8Q@mail.gmail.com>
Message-ID: <148F02E4-480E-4849-888C-1A6C0C908EAA@low-key.me>


On 4 December 2020 12:40:07 pm IST, "Bj?rn W?rmedal" <bjorn.warmedal at gmail.com> wrote:
>> Brilliant work, Bj?rn! I try to water another community garden plant
>> each day, but I usually have to pick a bunch of them at random before I
>> find one that needs watering. Thanks for making this a MUCH easier
>> process.
>
>Thank you, Gary! It was exactly that problem I intended to solve :)
>
>> This is awesome! I know botany from the tildeverse, but have never used
>> it! I was wondering, could you, or someone else, teach me how to attach
>> my output from astrobotany to my index page of my gemini capsule?
>
>Hey, Vidak! Good question, and I'm happy to help :)
>
>It's surprisingly simple, actually! There are a few curl-like command
>line utilities for gemini out there. When I was planning on making
>this I looked at https://github.com/makeworld-the-better-one/gemget at
>first. It ended up not working for me for two reasons: it doesn't
>(yet) support client certificates -- which AstroBotany requires to let
>you walk the community garden or visit your own plant -- and the Go
>version on my Raspberry Pi was incompatible (that's probably a
>solvable problem, but I would still need the client cert support).
>
>I ended up writing my own in python3:
>https://github.com/makeworld-the-better-one/gemget
>
>Python3 is great for me, because it works on my laptop and my RPi
>without needing to compile anything. This tool is *really* basic for
>now. There's no error checking, it decodes everything to UTF-8 before
>pushing it to stdout, and the response header line is included in the
>output. And there's no server cert validation of any kind (i.e. no
>known-hosts database). But it works for the purpose of fetching
>AstroBotany info!
>
>Basically: find where your browser keeps your client cert, run
>"gemcall -c <path to cert> -k <path to cert key> -u
>gemini://astrobotany.mozz.us/app/plant" and you'll get text output. Be
>sure to not have the colour setting turned on for that client cert, as
>that will ruin the experience for some people visiting your capsule.
>Then you just have to figure out which lines from the output you want!
>Put it in a cron job or systemd.timer if you can, and it's fully
>automated.
>
>Cheers,
>ew0k

Hello,


>I ended up writing my own in python3:
>https://github.com/makeworld-the-better-one/gemget

Um, it looks like you linked to gemget again. Could you please link to the one you created because I too would love to be able to do this.

Thanks!
? Lokesh Krishna

From cowan at ccil.org  Sat Dec  5 01:33:51 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 4 Dec 2020 20:33:51 -0500
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <20201204212824.GK24194@brevard.conman.org>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com>
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
 <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <5FC9EB0B.3040305@marmaladefoo.com>
 <20201204182458.46e73i6dcwzqphat@localhost>
 <20201204212824.GK24194@brevard.conman.org>
Message-ID: <CAD2gp_TxiNdZu7pBCA4EZT4ZwE8LLeqQ8SBP40sXy7Q_iDsbqw@mail.gmail.com>

On Fri, Dec 4, 2020 at 4:28 PM Sean Conner <sean at conman.org> wrote:

  Define "state change", because this link on my server:
>
>         gemini://gemini.conman.org/qotd
>
> literally makes a state change on every request (it pulls up the next
> quote, and it tracks the number across restarts).
>

I'm with Sean here.  There are a large number of very simple services that
Gemini systems could easily provide that would be banned under an
idempotent-only rule.  Historically, quote-of-the-day could be gotten from
a server by connecting on port 17 with either TCP or UDP; see the
/etc/services file and RFC 865.  (Sean, you might want to support port 17
just for hack value; if anybody connects to it, forget TLS: just blast back
the first 512 bytes of the next quote and close the connection.)

Other examples that could be geminized are:

1. The current time in a human readable (including HTTP and ISO) format per
RFC 867 (historically on port 13).

2. The current list of users connected to the server (for some definition
of "users", "connected" and "server"), one on each line per RFC 866
(historically on port 11).

3. An endless stream of characters for testing streaming clients per RFC
864 (historically on port 19).  I once set up a whole lot of workstations
after working hours to connect to this port (using gopher://foo:19/0 via a
test firewall) in order to see how much of this the firewall could take
without crashing.  It held up fine, though the browsers eventually crashed.

4. The current phase of the moon (no RFC).

5. The Really Big ASCII Button That Doesn't Do Anything (see <
https://krystalrose.com/rosewood/library/BigButton.htm>; copies of this
page date back to 1993).

Finally, if you look at RFC 7231, HTTP 1.1, you'll find that all of these
*are* idempotent in the sense of that RFC.  That is, you will always get
the same "intended effect".  Going to Sean's URL will always return the
quote of the day, even though the quote will be different the next time you
try.  GET is about this kind of conceptual idempotence rather than
byte-for-byte idempotence.  Although GETting the Big Red Button page
exhibits both.    :-)



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Consider the matter of Analytic Philosophy.  Dennett and Bennett are
well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites
Dennett.
There is also one Dummett.  By their works shall ye know them.  However,
just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is
hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the
function
of this and other e-mail messages, therefore, to do what they can to create
him.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/e290b4d2/attachment.htm>

From sean at conman.org  Sat Dec  5 02:13:15 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 4 Dec 2020 21:13:15 -0500
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <CAD2gp_TxiNdZu7pBCA4EZT4ZwE8LLeqQ8SBP40sXy7Q_iDsbqw@mail.gmail.com>
References: <5FC75A98.4000602@marmaladefoo.com>
 <20201202192205.GA4592@SDF.ORG> <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <5FC9EB0B.3040305@marmaladefoo.com>
 <20201204182458.46e73i6dcwzqphat@localhost>
 <20201204212824.GK24194@brevard.conman.org>
 <CAD2gp_TxiNdZu7pBCA4EZT4ZwE8LLeqQ8SBP40sXy7Q_iDsbqw@mail.gmail.com>
Message-ID: <20201205021315.GM24194@brevard.conman.org>

It was thus said that the Great John Cowan once stated:
> On Fri, Dec 4, 2020 at 4:28 PM Sean Conner <sean at conman.org> wrote:
> 
>   Define "state change", because this link on my server:
> >
> >         gemini://gemini.conman.org/qotd
> >
> > literally makes a state change on every request (it pulls up the next
> > quote, and it tracks the number across restarts).
> 
> I'm with Sean here.  There are a large number of very simple services that
> Gemini systems could easily provide that would be banned under an
> idempotent-only rule.  Historically, quote-of-the-day could be gotten from
> a server by connecting on port 17 with either TCP or UDP; see the
> /etc/services file and RFC 865.  (Sean, you might want to support port 17
> just for hack value; if anybody connects to it, forget TLS: just blast back
> the first 512 bytes of the next quote and close the connection.)

  Did you try it?  Because I do run a QOTD server on port TCP port 17.  In
fact, the Gemini link gets the quote from my QOTD server (and the same with
my gopher server, only the quote is on the main page).  I don't quite follow
the RFC (it will send a quote longer than 512 bytes) but hey, this is 2020,
not 1983.

  I used to support QOTD via UDP until I found out it was used in
amplification attacks and had to drop UDP support (this is why we can't have
nice things on the Internet).

  -spc (We now resume our regularly scheduled bikeshedding, currently in
	progress ... )

From cowan at ccil.org  Sat Dec  5 03:31:07 2020
From: cowan at ccil.org (John Cowan)
Date: Fri, 4 Dec 2020 22:31:07 -0500
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <20201205021315.GM24194@brevard.conman.org>
References: <5FC75A98.4000602@marmaladefoo.com> <20201202192205.GA4592@SDF.ORG>
 <5FC90D43.4010207@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012031747250.580109@nlap>
 <010001762ae05f81-cc39600e-17af-498d-9628-d24aed47d0fa-000000@email.amazonses.com>
 <fb1f237676a47792a46c298ee6a8c6396c2be54b.camel@ur.gs>
 <5FC9EB0B.3040305@marmaladefoo.com>
 <20201204182458.46e73i6dcwzqphat@localhost>
 <20201204212824.GK24194@brevard.conman.org>
 <CAD2gp_TxiNdZu7pBCA4EZT4ZwE8LLeqQ8SBP40sXy7Q_iDsbqw@mail.gmail.com>
 <20201205021315.GM24194@brevard.conman.org>
Message-ID: <CAD2gp_Rrt8sNWGV2X-zQBd7bAahaSoTZfSmto30JM-JYSHFpzw@mail.gmail.com>

On Fri, Dec 4, 2020 at 9:13 PM Sean Conner <sean at conman.org> wrote:


>  Did you try it? Because I do run a QOTD server on port TCP port 17.


I confess I did not.  And I certainly did not expect the Oblique
Strategies!  ("Nobody expects ...")  Kudos.  I once designed (but didn't
get a chance to implement) an IRC bot named teddybot[*] that most of the
time said nothing when you addressed it, but occasionally would hand you a
Strategy instead.

[*] http://www.unconsciousagile.com/teddy_bear_effect



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
I should say generally that that marriage was best auspiced, for the
achievement of happiness, which contemplated a relation between a man and a
woman in which the independence was equal, the dependence mutual, and the
obligations reciprocal.  --Louis Anspacher (1944)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/d0a6d32e/attachment-0001.htm>

From colecmac at protonmail.com  Sat Dec  5 04:48:25 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 05 Dec 2020 04:48:25 +0000
Subject: [ANN] Garden Gnome Society!
In-Reply-To: <CAJScK0Kqq=H_XyJ6MweiWHZY+R3Ey_kTX-xF960kF_=t9g-c8Q@mail.gmail.com>
References: <CAJScK0KGxKjfFVknAJoVisfxn_eqFjTo1D4pJ7hJdZe-jzKT_A@mail.gmail.com>
 <mailman.1213.1607001584.477.gemini@lists.orbitalfox.eu>
 <87blfa8lpp.fsf@riseup.net>
 <CAJScK0Kqq=H_XyJ6MweiWHZY+R3Ey_kTX-xF960kF_=t9g-c8Q@mail.gmail.com>
Message-ID: <GxQztXYTV0d3X6yql4Q5FyASJBo_7jjOH12u8GrPTC-boO4zJYgKkPj5cN1eFdaF4W4QbB9G5OkS7ANCdbgpwgIzigsZZ6bI8ldlEeDNE84=@protonmail.com>

> It's surprisingly simple, actually! There are a few curl-like command
> line utilities for gemini out there. When I was planning on making
> this I looked at https://github.com/makeworld-the-better-one/gemget at
> first. It ended up not working for me for two reasons: it doesn't
> (yet) support client certificates -- which AstroBotany requires to let
> you walk the community garden or visit your own plant -- and the Go
> version on my Raspberry Pi was incompatible (that's probably a
> solvable problem, but I would still need the client cert support).

Happy to hear you looked at gemget first, but it's too bad you moved on!
gemget should be able to do everything you want. It *does* have client cert
support, using the --cert and --key flags. And while it might require a
higher version of Go (1.12 maybe? 1.13?) to build it yourself, you can
download an ARM binary easily from the releases page.

Hope this helps!
makeworld


From bjorn.warmedal at gmail.com  Sat Dec  5 10:17:50 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Sat, 5 Dec 2020 11:17:50 +0100
Subject: [ANN] Garden Gnome Society!
In-Reply-To: <GxQztXYTV0d3X6yql4Q5FyASJBo_7jjOH12u8GrPTC-boO4zJYgKkPj5cN1eFdaF4W4QbB9G5OkS7ANCdbgpwgIzigsZZ6bI8ldlEeDNE84=@protonmail.com>
References: <GxQztXYTV0d3X6yql4Q5FyASJBo_7jjOH12u8GrPTC-boO4zJYgKkPj5cN1eFdaF4W4QbB9G5OkS7ANCdbgpwgIzigsZZ6bI8ldlEeDNE84=@protonmail.com>
Message-ID: <E6C1C36B-EC11-4AB9-94C8-D90597D4D759@gmail.com>


I did indeed link to gemget twice (it?s *that* good! ;) )

This is my tool:
https://notabug.org/tinyrabbit/gemcall

makeworld: Sorry, there was a bit of confusion on my part. I scrolled way down the README on gemget and saw ?Support client certificates? under ?Features to add? ? I didn?t notice that the checkbox in front of it is actually checked.

I highly recommend gemget above my own gemcall; gemget does a lot more and is less likely to fail arbitrarily. As mentioned I haven?t even implemented any form of error handling yet :)

Cheers,
ew0k

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201205/80c8b196/attachment.htm>

From callum at calcuode.com  Sat Dec  5 18:50:21 2020
From: callum at calcuode.com (Callum Brown)
Date: Sat, 05 Dec 2020 18:50:21 GMT
Subject: [ANN] gmisub - Subscribe to gemini pages
Message-ID: <C7L2D0YS0EN7.1AQPWTODIRMBZ@callum-computer>


Hello all,

I've written a program which aggregates feeds formatted according to the
"Subscribing to Gemini pages" specification. Extremely similar
functionality to Emilis' gmi-feed-aggregator, just implemented differently.

https://tildegit.org/emilis/gmi-feed-aggregator
gemini://gemini.circumlunar.space/docs/companion/subscription.gmi

You can find more details here:
gemini://calcuode.com/gemlog/gmisub.gmi

And an aggregate generated by it here:
gemini://calcuode.com/gmisub-aggregate.gmi

I'm planning to have the above page aggregate all the feeds I can find so
it can be a reference for anyone setting up their own more focused
aggregator. If you know of any feeds I'd appreciate a link!

There are some pages I've found that almost follow the specification but
have a slightly different date format or non-descriptive title, so I'll
probably try contact a few of those people to see if they would be up for
changing.


Have a good day/evening/night,
Callum

From norm at iwritethe.codes  Sun Dec  6 03:28:26 2020
From: norm at iwritethe.codes (=?UTF-8?Q?Norm_MacLennan?=)
Date: Sun, 6 Dec 2020 03:28:26 +0000
Subject: [ANN] GemIF - Simple Interactive Fiction engine for Gemini
In-Reply-To: <178e2430d1a785cfeac4df84856749d2324c44f0.camel@ur.gs>
References: <mail.5fc6efea.0aa7.395666ed3a7d9a34@storage.wm.amazon.com> 
 <0100017621193034-c0bc8cc5-de1e-4d2f-949d-a7d792e50a05-000000@email.amazonses.com>
 <ebe871fc50db9b9b70edcd1e6e797a51927ee7d5.camel@ur.gs> 
 <mail.5fc7e327.2b92.056d00f60143b28e@storage.wm.amazon.com> 
 <0100017624cf55b3-cbb3a89d-e7f2-4733-8ee4-4abb2a3a490b-000000@email.amazonses.com>
 <178e2430d1a785cfeac4df84856749d2324c44f0.camel@ur.gs> 
 <alpine.DEB.2.22.394.2012052159080.916365@nlap>
Message-ID: <010001763617ecb5-7254797c-79fd-4c63-8841-9791b58ffe16-000000@email.amazonses.com>

On Wed, 2 Dec 2020, Nick Thomas wrote:
> Hmm. Perhaps the best way to go about this would be a cgi-bin script
> that can take a compiled ink story (turns out it compiles to json) and
> use client certificates + a persistent server-side data store for user
> state. The script would be the same for every story, it'd "just" need a
> way to store per-user state.

That's a neat idea. I haven't yet had a chance to inspect Ink's file 
format, but I'll keep that in mind once I finally get around to it. Right 
now I'm working on the project foundation because, well, it's fun. But 
also so the project is healthy and maintainable if/when I try to add Ink 
integration.

What I _have_ done is simplify the server-side by making use of state 
tokens in the URL. Rather than tracking games and state in-memory server 
side, the server instead serializes the game state out into a token
(configurable as JSON or Protobuf) in the URL.

That way, each action link on the page just contains a "speculative" state 
token. This also wildly simplifies state rollback when the user navigates 
backward in their client since the state token contains everything anyway.

It also means games still work across server restarts (and theoretically 
even across _servers_ with the same stories)  without having to 
persist sessions anywhere.

Another new addition is writing stories in `.gemif` format rather than 
YAML format and "compiling" to YAML via a new `gemifc` command.

Right now, it's just a very minor abstraction over the YAML, but it's a 
start and does make writing a little more pleasant.

Scene metadata and transitions are still written in YAML format in 
(essentially) YAML frontmatter, while scene descriptions are now just 
plaintext. Each `.gemif` file can contain one or more scenes and
each story can contain one or more .gemif file.

Anyway, you can see some examples in the repo [1], so I don't take up too 
much space trying to explain it.

The other thing the samples demonstrate is the use of conditions. 
Transitions can attach conditions to the game state, which can then be 
used for conditional rendering in the scene descriptions as well as 
allowing or disallowing the use other transitions based on which 
conditions are present.

There's still a ways to go since I'm just learning a lot of these 
technologies, but I'm pretty happy with how things are shaping up so far.

[1] https://git.sr.ht/~nromdotcom/gemif/tree/master/stories/src/conditions

From stephane at sources.org  Sun Dec  6 16:56:19 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 6 Dec 2020 17:56:19 +0100
Subject: IDN with Gemini?
In-Reply-To: <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
Message-ID: <20201206165619.GA19670@sources.org>

On Fri, Dec 04, 2020 at 06:36:00PM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 15 lines which said:

> I feel like this is probably the most intuitive method. Only
> use punycoding when it's a necessity, like for DNS lookups.

I don't know what is the process for proposing and discussing changes
in Gemini specification (or to follow the points in discussion).

In the mean time, I've summarized the discussion here:

gemini://gemini.bortzmeyer.org/gemini/idn.gmi

From stephane at sources.org  Sun Dec  6 17:02:50 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 6 Dec 2020 18:02:50 +0100
Subject: TOFU, OK, but even with an expired certificate?
Message-ID: <20201206170250.GA20274@sources.org>

The page <gemini://gemini.circumlunar.space/> lists a "Houston search
engine", whose certificate expired months ago. Is it supposed to be
accepted? Amfora rejects it.

% gnutls-cli -p 1965 houston.coder.town
...
- subject `EMAIL=k at kvn.dev,CN=houston.coder.town,O=Internet Widgits Pty Ltd,ST=CA,C=US', issuer `EMAIL=k at kvn.dev,CN=houston.coder.town,O=Internet Widgits Pty Ltd,ST=CA,C=US', serial 0x04a4388eea0fd69cb645ac15a6117912cdf35ca9, RSA key 2048 bits, signed using RSA-SHA1 (broken!), activated `2020-05-20 21 21:48:19 UTC', expires `2020-06-19 21:48:19 UTC'

From colecmac at protonmail.com  Sun Dec  6 17:11:48 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 06 Dec 2020 17:11:48 +0000
Subject: IDN with Gemini?
In-Reply-To: <20201206165619.GA19670@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
Message-ID: <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>

> I don't know what is the process for proposing and discussing changes
> in Gemini specification (or to follow the points in discussion).

It's basically what we're doing. At some point Solderpunk will chime in
hopefully, and make a permanent change.

> In the mean time, I've summarized the discussion here:
>
> gemini://gemini.bortzmeyer.org/gemini/idn.gmi

Thanks for this. I forgot about certificates. I feel like for the most
compatibility, clients should support both the punycoded and Unicode
version of the domain in certs. Anyone disagree?

As for Unicode normalization, I feel like that's complex, annoying, and
hopefully out-of-scope. There should be one Unicode string for each domain
only, and I really don't want to have to deal with anything else.


Cheers
makeworld

From stephane at sources.org  Sun Dec  6 17:22:06 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 6 Dec 2020 18:22:06 +0100
Subject: IDN with Gemini?
In-Reply-To: <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
Message-ID: <20201206172206.GA20822@sources.org>

On Sun, Dec 06, 2020 at 05:11:48PM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 21 lines which said:

> As for Unicode normalization, I feel like that's complex, annoying,
> and hopefully out-of-scope. There should be one Unicode string for
> each domain only, and I really don't want to have to deal with
> anything else.

Well, OK so let's settle with NFC for everybody? (Since this is what
RFC 5198 says.)



From colecmac at protonmail.com  Sun Dec  6 17:24:49 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 06 Dec 2020 17:24:49 +0000
Subject: TOFU, OK, but even with an expired certificate?
In-Reply-To: <20201206170250.GA20274@sources.org>
References: <20201206170250.GA20274@sources.org>
Message-ID: <KswN-xR6FzKxz6HJM2m4AQdXaDGopBbg52yi1pc14Uzr1l2VrvKwy8moJAFA_vXWiqUx7LAwyInCcRB7-IZ0D5SYtAARUeKFizzYiRZKCWs=@protonmail.com>

It is indeed expired and should be rejected, as you saw with gnutls and
Amfora. Hopefully the sysadmin will update it, maybe you could email them.
Looks like the address is k at kvn.dev.


makeworld

From colecmac at protonmail.com  Sun Dec  6 17:30:16 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 06 Dec 2020 17:30:16 +0000
Subject: IDN with Gemini?
In-Reply-To: <20201206172206.GA20822@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
Message-ID: <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>

> > As for Unicode normalization, I feel like that's complex, annoying,
> > and hopefully out-of-scope. There should be one Unicode string for
> > each domain only, and I really don't want to have to deal with
> > anything else.
>
> Well, OK so let's settle with NFC for everybody? (Since this is what
> RFC 5198 says.)

Do you mean all clients should do NFC? That seems to me like would make
Gemini quite a bit more complex. I feel like NFC should be on the user,
if that's possible. Also I wonder how often this issue actually occurs,
are users really typing U+0065 U+0301 (e?) instead of U+00E9 (?) ?

makeworld


From gemini at g-n.site  Sun Dec  6 23:11:08 2020
From: gemini at g-n.site (Simon)
Date: Mon, 7 Dec 2020 00:11:08 +0100
Subject: [ANN] Geminiserver ASM
Message-ID: <34f72846-8b25-2630-d1a7-2b6b9ef3e9c1@g-n.site>

Hello!

I just want to announce a very little server written in ASM for linux 
x64. It uses only syscalls. Why did I do that? Just for fun :)

More details on (in?) my (new) capsule :
gemini://g-n.site/en/2020-12-03-geminiserver_asm.gmi

Have a nice day,

Simon

From colecmac at protonmail.com  Sun Dec  6 23:27:11 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 06 Dec 2020 23:27:11 +0000
Subject: IDN with Gemini?
In-Reply-To: <CAEzvDCVEwLBShk6K7=b68eUTBoDPCvP9R7ODBb4u2N=nM+zmtw@mail.gmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
 <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
 <CAEzvDCVEwLBShk6K7=b68eUTBoDPCvP9R7ODBb4u2N=nM+zmtw@mail.gmail.com>
Message-ID: <Zzs6T3gxvGQTtLiIzxvtTv_vWQzJpCPUz3hRCxR7yWJiWr4PSZcM-JWH3nb0kaT4Lh8n1C9UYiZS3RqCcum12UPcM6yKAlwOLoYZJ2UD08M=@protonmail.com>

On Sunday, December 6, 2020 6:05 PM, A. E. Spencer-Reed <easrng at gmail.com> wrote:

> > are users really typing U+0065 U+0301 (e?) instead of U+00E9 (?) ?
>
> In links, probably not, but maybe in the address bar. However, I was
> under the impression that precomposed characters are no longer
> supposed to be used, am I horribly wrong?

I don't know about that, but I hope that's true. It helps reinforce my
idea that normalization is way out of scope for Gemini clients.


makeworld

(Note I've CC'ed the gemini list, I think you forgot to Reply All in your message)

From colecmac at protonmail.com  Sun Dec  6 23:29:41 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 06 Dec 2020 23:29:41 +0000
Subject: IDN with Gemini?
In-Reply-To: <20201204135138.GA684@sources.org>
References: <20201204135138.GA684@sources.org>
Message-ID: <AukjZG2RP69Nra-xxXqO-LTKzgDVUE6VfaPF01tURjt6A8X7dWfts4D3H1GYPWQj75peyO9nndLbFbqGfZiYsBgvWJeYZmf4v2jEaQAjHU0=@protonmail.com>

I'm not sure if the first email is the right one to reply to in
this case, but I've summarized the suggestions of this thread here:

https://github.com/makeworld-the-better-one/go-gemini/issues/10

I hope this makes it easier for other client authors to figure out
what to do, as well as for Solderpunk to make an official decision.


Cheers,
makeworld

From colecmac at protonmail.com  Mon Dec  7 00:52:50 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 00:52:50 +0000
Subject: IDN with Gemini?
In-Reply-To: <CAEzvDCXuJmR3_5U6f9K9u=mpDtPzN=5ycVM46Pmq-voH3eP_Kg@mail.gmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
 <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
 <CAEzvDCXuJmR3_5U6f9K9u=mpDtPzN=5ycVM46Pmq-voH3eP_Kg@mail.gmail.com>
Message-ID: <ifHtJkERjwTRmxLxIAhOQtYtaN0f7m1W9qT3jPWLlT_WBW4MDjg39gvivZPKlJ9fptJqgcE9vmvfrVCtkcUJjqR6H66MXs6QLKghH4B7HN8=@protonmail.com>

On Sunday, December 6, 2020 7:40 PM, A. E. Spencer-Reed <easrng at gmail.com> wrote:

> > Do you mean all clients should do NFC? That seems to me like would make
> > Gemini quite a bit more complex.
>
> Isn't that usually handled by the standard library anyway?

I suppose, yeah. Many languages might need to import a package, but it won't be
something the programmer is doing themselves, just like TLS.

I'm just wary of bringing in another large dependency, and I know Unicode to
be something complex, and something that will require updates. I would very
much like to hear Solderpunk's opinion on this.

makeworld

(You forgot to use Reply-All again, I've CC'ed the list.)

From colecmac at protonmail.com  Mon Dec  7 01:04:56 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 01:04:56 +0000
Subject: IDN with Gemini?
In-Reply-To: <ifHtJkERjwTRmxLxIAhOQtYtaN0f7m1W9qT3jPWLlT_WBW4MDjg39gvivZPKlJ9fptJqgcE9vmvfrVCtkcUJjqR6H66MXs6QLKghH4B7HN8=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
 <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
 <CAEzvDCXuJmR3_5U6f9K9u=mpDtPzN=5ycVM46Pmq-voH3eP_Kg@mail.gmail.com>
 <ifHtJkERjwTRmxLxIAhOQtYtaN0f7m1W9qT3jPWLlT_WBW4MDjg39gvivZPKlJ9fptJqgcE9vmvfrVCtkcUJjqR6H66MXs6QLKghH4B7HN8=@protonmail.com>
Message-ID: <D2pMHC6AUXFVTmmsYZ5lzy8a4k5AJk3-Q4LJgFKdmTC51D9MtIyqWCONsjVihwFUX-6CBM6MsSgOMD9Kjd_pxK3GNqTKO57SylG7gYdMozw=@protonmail.com>

> > > Do you mean all clients should do NFC? That seems to me like would make
> > > Gemini quite a bit more complex.
> >
> > Isn't that usually handled by the standard library anyway?
>
> I suppose, yeah. Many languages might need to import a package, but it won't be
> something the programmer is doing themselves, just like TLS.
>
> I'm just wary of bringing in another large dependency, and I know Unicode to
> be something complex, and something that will require updates. I would very
> much like to hear Solderpunk's opinion on this.

Having looked into it[1], it doesn't look that complicated, for Go anyway.
Perhaps it should be recommended for clients to do, but not required. While
the other things like punycoding and sending the IDN to the server would be
required.


makeworld

1: https://github.com/makeworld-the-better-one/go-gemini/issues/10#issuecomment-739604051

From bie at 202x.moe  Mon Dec  7 02:16:41 2020
From: bie at 202x.moe (bie)
Date: Mon, 7 Dec 2020 11:16:41 +0900
Subject: IDN with Gemini?
In-Reply-To: <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
Message-ID: <20201207021641.GA30912@202x.moe>

> I feel like this is probably the most intuitive method. Only
> use punycoding when it's a necessity, like for DNS lookups.
> 
> What about link lines though? I think that clients should
> accept both punycoded and Unicode domains in links. Convert
> all links' domain to punycode for DNS, then convert all links'
> domain to Unicode for sending. That seems a bit complicated,
> but from an author perspective it makes sense to support both.

Allowing IRIs is a *really big and breaking change*.

Right now, checking whether a gemini request is valid can be done really
easily, even in a language like C and with no external dependencies.

Converting the IRI to an URI in the client and having the server
configured with the punycode seems like a much cleaner, simpler and even
robust solution to me.

bie

From colecmac at protonmail.com  Mon Dec  7 03:24:25 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 03:24:25 +0000
Subject: IDN with Gemini?
In-Reply-To: <20201207021641.GA30912@202x.moe>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
Message-ID: <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>

bie wrote:
> Allowing IRIs is a really big and breaking change.

Stephane Bortzmeyer mentioned IRIs in an earlier email in this thread.
I think that was probably a mistake, and if not, then I don't support it.
I should have caught it at the time but I didn't, sorry. All I have been
talking about the entire time, in this thread and in the GitHub issue[1]
you quote from, is IDNs -- Internationalized Domain Names.

You're right that using IRIs over URIs would be a big change, and a bad
one. I'm only talking about converting and messing with domains. In my
opinion, to keep things simple, no client should deal with IRIs at all.

I hope that sets the record straight. I'm only talking about domains.
Thanks for allowing me to clarify that.

>> What about link lines though?

This quote from the issue has been removed now. It was in reference to how
Amfora should work interally, not what low-level clients should do. I hope the
issue is more clear now. No IRIs! :)

Cheers,
makeworld

1: https://github.com/makeworld-the-better-one/go-gemini/issues/10



From colecmac at protonmail.com  Mon Dec  7 04:06:18 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 04:06:18 +0000
Subject: Small spec change required by RFC for lang params
Message-ID: <j1Z3z1j0QYKv0_UD8zlxxLtUpMoFQj0M8ypAvFnCYoiWdY50qAmQeaNr19p0iC48VYbejoo-YNkhMP_SawrDEkxyI7T2f83zjwB9jJ26G0g=@protonmail.com>

Hello Geminauts,

A small spec change is required by RFC for the "lang" parameter in the
text/gemini mediatype.

Section 5.2 of the spec states:

> Valid values for the "lang" parameter are comma-separated lists of one
> or more language tags as defined in RFC4646. For example:
>
> - "text/gemini; lang=en" Denotes a text/gemini document written in English
> - "text/gemini; lang=fr" Denotes a text/gemini document written in French
> - "text/gemini; lang=en,fr" Denotes a text/gemini document written in a mixture of English and French
> - "text/gemini; lang=de-CH" Denotes a text/gemini document written in Swiss German
> - "text/gemini; lang=sr-Cyrl" Denotes a text/gemini document written in Serbian using the Cyrllic script
> - "text/gemini; lang=zh-Hans-CN" Denotes a text/gemini document written in Chinese using the Simplified script as used in mainland China

However, as can been seen in Go, the multi-language examples here are
not compliant with the relevant RFCs.

https://play.golang.org/p/7j0z3iORRmP

Attempting to parse the third example in the spec gives an error. After
digging through the Go source code, I eventually found a reference to
RFC 2045. On both page 12 and page 31, we see this relevant ABNF:


     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="
                   ; Must be in quoted-string,
                   ; to use within parameter values


This clearly denotes that commas cannot be in a lang parameter without
quoting. Indeed, this is what we find when using the Go stdlib parser
again:

https://play.golang.org/p/L4qh1Qev-TS


My simple suggestion is to change these examples so the ones with commas
use quotes. Perhaps explicitly mention how quotes must be used for those
types of lang parameters.


Thanks,
makeworld

From bjorn.warmedal at gmail.com  Mon Dec  7 06:48:04 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Mon, 7 Dec 2020 07:48:04 +0100
Subject: TOFU, OK, but even with an expired certificate?
In-Reply-To: <KswN-xR6FzKxz6HJM2m4AQdXaDGopBbg52yi1pc14Uzr1l2VrvKwy8moJAFA_vXWiqUx7LAwyInCcRB7-IZ0D5SYtAARUeKFizzYiRZKCWs=@protonmail.com>
References: <20201206170250.GA20274@sources.org>
 <KswN-xR6FzKxz6HJM2m4AQdXaDGopBbg52yi1pc14Uzr1l2VrvKwy8moJAFA_vXWiqUx7LAwyInCcRB7-IZ0D5SYtAARUeKFizzYiRZKCWs=@protonmail.com>
Message-ID: <CAJScK0L-7jyQPbvCGi6hgPvuWP1_10S_LzyUab-Dk_3gbqVLng@mail.gmail.com>

On Sun, 6 Dec 2020 at 18:25, <colecmac at protonmail.com> wrote:
>
> It is indeed expired and should be rejected, as you saw with gnutls and
> Amfora.

I disagree with makeworld on this.

The idea of expiration comes from the Certificate Authority scheme of
certificate validation. A certificate authority will not lend their
trust to someone indefinitely, because that would eventually lead to a
horrible mess of billions of rejected certificates. Instead they put a
time limit on their certificates to say that "if we haven't vouched
for this person/organisation in the last X months, just assume we no
longer do".

With a self-signed certificate the date is just a setting that the
certificate issuer can set arbitrarily, which means a middle-man
attacker can too. A valid date range doesn't in any way affect the
security of the certificate. The *only* valid question is "Do I trust
this?" which is somewhat of a catch 22. This is where TOFU comes in:
we assume that the certificate is correct the first time it's
presented to us, and subsequent checks are just a matter of "is this
the same certificate already presented to me for this host?"

Incidentally I wrote a gemlog post on the subject last night (after
the original mail in this thread was sent, but before I'd seen it --
my post had been in the brewing for a few days). Tell me if there's
anything that can be clarified in that post:
gemini://tilde.team/~ew0k/posts/certificate-security.gmi

Cheers,
ew0k

From petite.abeille at gmail.com  Mon Dec  7 08:12:34 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 09:12:34 +0100
Subject: IDN with Gemini?
In-Reply-To: <Zzs6T3gxvGQTtLiIzxvtTv_vWQzJpCPUz3hRCxR7yWJiWr4PSZcM-JWH3nb0kaT4Lh8n1C9UYiZS3RqCcum12UPcM6yKAlwOLoYZJ2UD08M=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
 <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
 <CAEzvDCVEwLBShk6K7=b68eUTBoDPCvP9R7ODBb4u2N=nM+zmtw@mail.gmail.com>
 <Zzs6T3gxvGQTtLiIzxvtTv_vWQzJpCPUz3hRCxR7yWJiWr4PSZcM-JWH3nb0kaT4Lh8n1C9UYiZS3RqCcum12UPcM6yKAlwOLoYZJ2UD08M=@protonmail.com>
Message-ID: <2D3E0AD1-5E6B-4A64-97A5-4A3B6A7B1BF1@gmail.com>



> On Dec 7, 2020, at 00:27, colecmac at protonmail.com wrote:
> 
> (Note I've CC'ed the gemini list, I think you forgot to Reply All in your message)

Sigh. 

From come at chilliet.eu  Mon Dec  7 08:24:08 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me_Chilliet?=)
Date: Mon, 07 Dec 2020 09:24:08 +0100
Subject: IDN with Gemini?
In-Reply-To: <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
Message-ID: <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>

It's 2020, can we please be allowed to use french in our links?

It makes no sense I'd need to know two weird translitteration schemes by heart before I can link to ?checs.fr/fran?ais

I get that we need to encode spaces and other special delimiter characters, but other than that, what's the rationnal in limiting to ascii?
MCMic

From stephane at sources.org  Mon Dec  7 09:02:43 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 10:02:43 +0100
Subject: [ANN] A Nagios (and compatible) monitoring plugin for Gemini servers
Message-ID: <20201207090243.GA14015@sources.org>

You manage Gemini servers? Despite the fact that the protocol is still
quite experimental, you want to do a serious job, which means
*monitoring*? You use a monitoring system that can use external plugin
using the Nagios API (like Nagios itself, Icinga and many others)?

Then Manisha is here to help. It it a monitoring plugin for Gemini
servers. It follows the usual rules of the Nagios API and will allow
you to be informed of what happends to your Gemini server(s).

gemini://gemini.bortzmeyer.org/software/manisha/ on the geminispace

https://framagit.org/bortzmeyer/manisha on the Web


From bie at 202x.moe  Mon Dec  7 09:29:34 2020
From: bie at 202x.moe (bie)
Date: Mon, 7 Dec 2020 18:29:34 +0900
Subject: IDN with Gemini?
In-Reply-To: <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
Message-ID: <20201207092934.GA11501@202x.moe>

On Mon, Dec 07, 2020 at 09:24:08AM +0100, C?me Chilliet wrote:
> It's 2020, can we please be allowed to use french in our links?
> 
> It makes no sense I'd need to know two weird translitteration schemes by heart before I can link to ?checs.fr/fran?ais
> 
> I get that we need to encode spaces and other special delimiter characters, but other than that, what's the rationnal in limiting to ascii?
> MCMic

There is one really good reason - it won't work well with existing
servers and clients.

Most servers (and especially servers that follow the spec) currently
only accept requests that provide a valid URI - so a request that
contains something outside the set of valid 84 characters should not be
accepted. Asking for servers to start accepting IRIs is a big change,
and a breaking change in my opinion, one that adds a lot of complexity
for very little value added.

Allowing such links in text/gemini, but asking clients to handle the
percent-encoding in the background has a similar problem - it goes
against what every single client is doing now.

The best solution, in my opinion, is to stick to URIs. If someone really
wants to be able to type links like your example into their text/gemini
files, there's even a solution for that - create as server that processes
the .gmi files on the fly and sends punycode/percent-encoded links to
the client.

bie

From come at chilliet.eu  Mon Dec  7 09:59:06 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Mon, 07 Dec 2020 10:59:06 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207092934.GA11501@202x.moe>
References: <20201204135138.GA684@sources.org>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207092934.GA11501@202x.moe>
Message-ID: <1648037.flocbd0D07@tempete>

Le lundi 7 d?cembre 2020, 10:29:34 CET bie a ?crit :
> > I get that we need to encode spaces and other special delimiter characters, but other than that, what's the rationnal in limiting to ascii?
> > MCMic
> 
> There is one really good reason - it won't work well with existing
> servers and clients.
> 
> Most servers (and especially servers that follow the spec) currently
> only accept requests that provide a valid URI - so a request that
> contains something outside the set of valid 84 characters should not be
> accepted. Asking for servers to start accepting IRIs is a big change,
> and a breaking change in my opinion, one that adds a lot of complexity
> for very little value added.

I have to disagree that using my own language to name files and pages on my own server is of ?very little value?.

Servers already have to output utf-8, why not accept utf-8 in the input?

> Allowing such links in text/gemini, but asking clients to handle the
> percent-encoding in the background has a similar problem - it goes
> against what every single client is doing now.

I am not asking clients to handle percent-encoding, I expect my server to receive the utf-8 I put in the link.
I just tried, my server handles gemini://gemlog.lanterne.chilliet.eu/fran?ais-test.gmi with no problem. (I coded the server myself, but I did not put any effort into supporting this, I never tried it before).
Most clients will percent encode the request, but with lagrange if I enter it like this in the adress bar my server does receive the request not percent encoded and reacts well. (It also reacts well if percent encoded of course since it decodes to the same name).

> The best solution, in my opinion, is to stick to URIs. If someone really
> wants to be able to type links like your example into their text/gemini
> files, there's even a solution for that - create as server that processes
> the .gmi files on the fly and sends punycode/percent-encoded links to
> the client.

Gemini has taken steps in the right direction by defaulting to uft-8 and specifying that there is no default value for lang. It would make a lot of sense to accept utf-8 in request as well and not arbitrarly limit to ascii, just because of web history.

I understand that punycode will have to be used for the DNS lookup, but that?s on DNS specification, not Gemini?s reponsibility. But I fail to see why the Gemini request should be punycoded, or percent encoded except for special delimiter characters.

MCMic



From stephane at sources.org  Mon Dec  7 10:39:07 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 11:39:07 +0100
Subject: IDN with Gemini?
In-Reply-To: <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
 <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
Message-ID: <20201207103907.GA17138@sources.org>

On Sun, Dec 06, 2020 at 05:30:16PM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 15 lines which said:

> I feel like NFC should be on the user, if that's possible. Also I
> wonder how often this issue actually occurs, are users really typing
> U+0065 U+0301 (e?) instead of U+00E9 (?) ?

Users don't input Unicode code points! They input characters (using
various methods), and, behind the scene, the input methods they use
produce code points. This is typically not under the control of the
user.

From stephane at sources.org  Mon Dec  7 10:47:19 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 11:47:19 +0100
Subject: IDN with Gemini?
In-Reply-To: <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
Message-ID: <20201207104719.GC17138@sources.org>

On Mon, Dec 07, 2020 at 03:24:25AM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 28 lines which said:

> Stephane Bortzmeyer mentioned IRIs in an earlier email in this thread.
> I think that was probably a mistake,

No, it wasn't. But it's true that there are two technically different
issues, the domain name and the path which, unfortunately, may require
different treatments.

>From the point of view of users, I believe it will be hard to explain
that Unicode characters are allowed in the domain name but not in the
path, or vice-versa.

From stephane at sources.org  Mon Dec  7 10:44:38 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 11:44:38 +0100
Subject: IDN with Gemini?
In-Reply-To: <Zzs6T3gxvGQTtLiIzxvtTv_vWQzJpCPUz3hRCxR7yWJiWr4PSZcM-JWH3nb0kaT4Lh8n1C9UYiZS3RqCcum12UPcM6yKAlwOLoYZJ2UD08M=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
 <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
 <CAEzvDCVEwLBShk6K7=b68eUTBoDPCvP9R7ODBb4u2N=nM+zmtw@mail.gmail.com>
 <Zzs6T3gxvGQTtLiIzxvtTv_vWQzJpCPUz3hRCxR7yWJiWr4PSZcM-JWH3nb0kaT4Lh8n1C9UYiZS3RqCcum12UPcM6yKAlwOLoYZJ2UD08M=@protonmail.com>
Message-ID: <20201207104437.GB17138@sources.org>

On Sun, Dec 06, 2020 at 11:27:11PM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 18 lines which said:

> > However, I was under the impression that precomposed characters
> > are no longer supposed to be used, am I horribly wrong?
> 
> I don't know about that, but I hope that's true.

Quite the contrary. RFC 5198 mandates NFC, which maps many characters
to the precomposed form.

From stephane at sources.org  Mon Dec  7 10:50:22 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 11:50:22 +0100
Subject: IDN with Gemini?
In-Reply-To: <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
Message-ID: <20201207105021.GD17138@sources.org>

On Mon, Dec 07, 2020 at 09:24:08AM +0100,
 C?me Chilliet <come at chilliet.eu> wrote 
 a message of 8 lines which said:

> It's 2020, can we please be allowed to use french in our links?

And it is even more important for people who use scripts like arabic,
chinese, devanageri, etc.

> what's the rationnal in limiting to ascii?

Well, properly handling IRI require to change the specification, and
also to change software. One of the points of Gemini being to be
simple to implement, this certainly requires consideration. However, it
is an issue similar to the TLS one: TLS is big and complicated
(certainly even more than Unicode) and yet Gemini *requires* it. After
all, it will typically be handled by a library, not by the guy or gal
who writes yet another Gemini server. Same thing for Unicode.


From stephane at sources.org  Mon Dec  7 10:53:10 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 11:53:10 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207092934.GA11501@202x.moe>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207092934.GA11501@202x.moe>
Message-ID: <20201207105309.GE17138@sources.org>

On Mon, Dec 07, 2020 at 06:29:34PM +0900,
 bie <bie at 202x.moe> wrote 
 a message of 29 lines which said:

> There is one really good reason - it won't work well with existing
> servers and clients.

This is a bad reason since the specification is not stabilized yet and
Gemini is basically very experimental. Nothing is cast in stone and we
don't have to maintain compatibility.

> for very little value added.

I strongly disagree. If Gemini is only for the world elites who speak
english, it is much less interesting.

From bie at 202x.moe  Mon Dec  7 11:19:07 2020
From: bie at 202x.moe (bie)
Date: Mon, 7 Dec 2020 20:19:07 +0900
Subject: IDN with Gemini?
In-Reply-To: <20201207105309.GE17138@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207092934.GA11501@202x.moe>
 <20201207105309.GE17138@sources.org>
Message-ID: <20201207111907.GA53725@202x.moe>

> > for very little value added.
> 
> I strongly disagree. If Gemini is only for the world elites who speak
> english, it is much less interesting.

It's not, though.

I've got servers running on international domain names, and the majority
of the pages I'm serving have Japanese characters in the paths.
This works *today* in every single gemini client I've tried, because the
paths are valid URIs (percent-encoded) and the domains work with
punycode.

Nice clients can show decoded paths and decoded domains, but the beauty
of the current approach is that they don't have to.

bie

From marcx2 at welz.org.za  Mon Dec  7 12:30:41 2020
From: marcx2 at welz.org.za (marc)
Date: Mon, 7 Dec 2020 13:30:41 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207105021.GD17138@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
Message-ID: <20201207123041.GA17160@localhost.localdomain>

Hi

> > It's 2020, can we please be allowed to use french in our links?
> 
> And it is even more important for people who use scripts like arabic,
> chinese, devanageri, etc.

I am to be convinced that unicode URLs are a good thing.

And I say that as a native speaker of a language which
includes glyphs which aren't in US ASCII.

An URL is an address, in the same way that a phone
number or an IP is an address. Ideally these are globally
unique, unambiguous and representable everywhere.
This address scheme should be independent of a localisation.

We don't insist that phone numbers are rendered in roman
numerals either. My dialing prefix isn't +XXVII. The
gemini:// prefix isn't tweeling:// in dutch.

Using unicode in addresses balkanises this global space into
separate little domains, with subtle ambiguities (is the
cyrilic C the same as a latin - C, who knows ?), reducing
security, and making crossover harder. If somebody points
me at an url in kanji or ethiopian, I would have great
difficulty remembering nevermind recreating it, even if the 
photo there is useful to the rest of the world. If you 
are saying what about the guy from Ethiopia - well, I suspect he
would have trouble with kanji too... without a common
denominator this is an N^2 problem.

I appreciate that many languages are in decline and even
facing extinction - but interacting with the internet requires
a jargon or specialisation anyway, in the same way that botanists
invoke latin names, mathematicians write about eigenvectors
and brain surgeons talk about the hippocampus, all regardless
of which languages they speak at home.

TLDR: The words after the gemini => link can be unicode, the
link itself should not.

regards

marc

From stephane at sources.org  Mon Dec  7 12:30:21 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 13:30:21 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207104719.GC17138@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <20201207104719.GC17138@sources.org>
Message-ID: <20201207123021.GA7382@sources.org>

On Mon, Dec 07, 2020 at 11:47:19AM +0100,
 Stephane Bortzmeyer <stephane at sources.org> wrote 
 a message of 14 lines which said:

> No, it wasn't. But it's true that there are two technically different
> issues, the domain name and the path which, unfortunately, may require
> different treatments.
> 
> From the point of view of users, I believe it will be hard to explain
> that Unicode characters are allowed in the domain name but not in the
> path, or vice-versa.

An example of an IRI issue with the Lagrange client
<https://github.com/skyjake/lagrange/issues/73>


From bie at 202x.moe  Mon Dec  7 13:09:39 2020
From: bie at 202x.moe (bie)
Date: Mon, 7 Dec 2020 22:09:39 +0900
Subject: IDN with Gemini?
In-Reply-To: <20201207123041.GA17160@localhost.localdomain>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
Message-ID: <20201207130939.GA29595@202x.moe>

> > And it is even more important for people who use scripts like arabic,
> > chinese, devanageri, etc.
> 
> I am to be convinced that unicode URLs are a good thing.
> 
> And I say that as a native speaker of a language which
> includes glyphs which aren't in US ASCII.
> 
> An URL is an address, in the same way that a phone
> number or an IP is an address. Ideally these are globally
> unique, unambiguous and representable everywhere.
> This address scheme should be independent of a localisation.
> 
> We don't insist that phone numbers are rendered in roman
> numerals either. My dialing prefix isn't +XXVII. The
> gemini:// prefix isn't tweeling:// in dutch.
> 
> Using unicode in addresses balkanises this global space into
> separate little domains, with subtle ambiguities (is the
> cyrilic C the same as a latin - C, who knows ?), reducing
> security, and making crossover harder. If somebody points
> me at an url in kanji or ethiopian, I would have great
> difficulty remembering nevermind recreating it, even if the 
> photo there is useful to the rest of the world. If you 
> are saying what about the guy from Ethiopia - well, I suspect he
> would have trouble with kanji too... without a common
> denominator this is an N^2 problem.
> 
> I appreciate that many languages are in decline and even
> facing extinction - but interacting with the internet requires
> a jargon or specialisation anyway, in the same way that botanists
> invoke latin names, mathematicians write about eigenvectors
> and brain surgeons talk about the hippocampus, all regardless
> of which languages they speak at home.
> 
> TLDR: The words after the gemini => link can be unicode, the
> link itself should not.

I mostly agree with this in the sense that the protocol and text/gemini
should stick to URLs that are URI-safe (nothing outside the safe
80-something characters).

That said, I don't think there's anything wrong with a friendly client
showing percent-decoded unicode representations of a path or
punycode-decoded representations of an international domain name in the
address bar or anywhere else in the interface.

In the same vein, if a server wants to be extra friendly to gmi file
authors, it can, like I suggested earlier, allow users to name and link
to files in unicode, but percent-encode everything before sending it to
over the wire. I actually implemented this in my personal gemini server
today, and it was a trivial change (especially when compared to what I'd
have to do to properly validate IRIs...), allowing me to write "=> ??/
??" and have it sent to the client as "=> %e%9b%91%e5%bf%b5/ ??".

bie

From easrng at gmail.com  Mon Dec  7 13:26:19 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Mon, 7 Dec 2020 08:26:19 -0500
Subject: TOFU, OK, but even with an expired certificate?
In-Reply-To: <CAJScK0L-7jyQPbvCGi6hgPvuWP1_10S_LzyUab-Dk_3gbqVLng@mail.gmail.com>
References: <20201206170250.GA20274@sources.org>
 <KswN-xR6FzKxz6HJM2m4AQdXaDGopBbg52yi1pc14Uzr1l2VrvKwy8moJAFA_vXWiqUx7LAwyInCcRB7-IZ0D5SYtAARUeKFizzYiRZKCWs=@protonmail.com>
 <CAJScK0L-7jyQPbvCGi6hgPvuWP1_10S_LzyUab-Dk_3gbqVLng@mail.gmail.com>
Message-ID: <CAEzvDCWC09uNfAh_Tcq=wiekxYtSCXi+PP4H02ES9QZMHxNHGw@mail.gmail.com>

> With a self-signed certificate the date is just a setting that the
> certificate issuer can set arbitrarily

Then server owners can set an expiration date in the far future. If
they set a close expiration date, then they are expecting it to
expire.

From colecmac at protonmail.com  Mon Dec  7 13:33:41 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 13:33:41 +0000
Subject: IDN with Gemini?
In-Reply-To: <20201207104437.GB17138@sources.org>
References: <20201204135138.GA684@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201206165619.GA19670@sources.org>
 <oOmH6R27Z85sMIawBYvC78hyj1pugXW-S1f3hrlTnpUHPYam06GUygSa69JPbrL5XkVw_GSxmvzr1Xn8Mvoe_phclR2TFnnoQhpEWWPAPps=@protonmail.com>
 <20201206172206.GA20822@sources.org>
 <7HrEaf5f--B7Uq-RjgSef14P3b7S-W31md494YHv9nRUCHt2Hul3fasxkNw1olYZatGb3MQ6uVJzh50ENGqLAk9rZZLutPc8evUeZicJXAM=@protonmail.com>
 <CAEzvDCVEwLBShk6K7=b68eUTBoDPCvP9R7ODBb4u2N=nM+zmtw@mail.gmail.com>
 <Zzs6T3gxvGQTtLiIzxvtTv_vWQzJpCPUz3hRCxR7yWJiWr4PSZcM-JWH3nb0kaT4Lh8n1C9UYiZS3RqCcum12UPcM6yKAlwOLoYZJ2UD08M=@protonmail.com>
 <20201207104437.GB17138@sources.org>
Message-ID: <qdlbGwXufEs5tfUuo-DEk_sUFC9g0QmSuvW1tI0mAbAz4m0aYyCJfK3pN0Lo8XgJl7if-Z8S6EQiz2BtmJpUzPb4pQ7iDWYUossjGJQtaPA=@protonmail.com>

On Monday, December 7, 2020 5:44 AM, Stephane Bortzmeyer <stephane at sources.org> wrote:

> On Sun, Dec 06, 2020 at 11:27:11PM +0000,
> colecmac at protonmail.com colecmac at protonmail.com wrote
> a message of 18 lines which said:
>
> > > However, I was under the impression that precomposed characters
> > > are no longer supposed to be used, am I horribly wrong?
> >
> > I don't know about that, but I hope that's true.
>
> Quite the contrary. RFC 5198 mandates NFC, which maps many characters
> to the precomposed form.

Yep, you're right. I misread and thought this was being said about
the decomposed form.


makeworld


From colecmac at protonmail.com  Mon Dec  7 13:56:25 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 13:56:25 +0000
Subject: IDN with Gemini?
In-Reply-To: <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
Message-ID: <oSB5tZNeZdmH7qimGHNq1gBYjFFh9COmcbhgK7DLpm1jffs0RennwNet6NoxSdMsPLIynJJU95aPxTyOgJygkR_af2CGCJ6WBT7nKSZiGhw=@protonmail.com>

Not sure exactly where to jump in, so I'm gonna share my thoughts here.
I thinking having IRIs would be nice, and I feel bad that currently
non-english authors are second-classed in this manner. But from the
beginning Gemini has been about being simple -- not for authors, but
for programmers. It was intended to be able to implemented in a weekend,
in a few hundred lines, ideally without even needing libraries outside
your language's stdlib.

Supporting IRIs is *not* simple. For example, in Python it requires a
third-party library[1], and in Go I wasn't even able to find one. This
means that in many programming languages, no one would be able to even
begin writing a Gemini client before writing a library that parses and
conforms to the complex specification that is IRIs.

Secondly, this would be a large breaking change for Gemini. Even if IRIs
were supported in all programming languages, I don't think making breaking
changes to Gemini is feasible at this point. Things are too set, and
attempting to do this would break the ecosystem.

Lower down in the thread, Stephane Bortzmeyer mentions:

> From the point of view of users, I believe it will be hard to explain
> that Unicode characters are allowed in the domain name but not in the
> path, or vice-versa.

This is true and unfortunate. My proposal[2] is only about domain names,
and so this would have to be explained to users. But as I've outlined
above, using IRIs would be virtually impossible, and so I think supporting
IDNs in link lines is the best we can give non-english authors.


1: https://stackoverflow.com/a/12565315/7361270
2: https://github.com/makeworld-the-better-one/go-gemini/issues/10


Thanks,
makeworld

From colecmac at protonmail.com  Mon Dec  7 14:07:11 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 14:07:11 +0000
Subject: TOFU, OK, but even with an expired certificate?
In-Reply-To: <CAJScK0L-7jyQPbvCGi6hgPvuWP1_10S_LzyUab-Dk_3gbqVLng@mail.gmail.com>
References: <20201206170250.GA20274@sources.org>
 <KswN-xR6FzKxz6HJM2m4AQdXaDGopBbg52yi1pc14Uzr1l2VrvKwy8moJAFA_vXWiqUx7LAwyInCcRB7-IZ0D5SYtAARUeKFizzYiRZKCWs=@protonmail.com>
 <CAJScK0L-7jyQPbvCGi6hgPvuWP1_10S_LzyUab-Dk_3gbqVLng@mail.gmail.com>
Message-ID: <m4Apcl10gSbXLUVTROpxkoNpraLZIbdb4mI1MpkWzskmQm47hhI1M2PWqJidgw_gS-1uNmOectw8HsepSLf95shUA7EeLQTC5vpGkBzHAzk=@protonmail.com>

On Monday, December 7, 2020 1:48 AM, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:

> On Sun, 6 Dec 2020 at 18:25, colecmac at protonmail.com wrote:
>
> > It is indeed expired and should be rejected, as you saw with gnutls and
> > Amfora.
>
> I disagree with makeworld on this.

The advantage of having expiry dates is that if the server admin
loses the key, or their hardware, or something like that, they know
that clients will accept the new cert after a  certain period of time,
with no issues or scary warnings. Now, I know that this becomes a bit
counter-intuitive when certs expire 5 years in the future, but I still
think it's a good quality to have.


makeworld

From petite.abeille at gmail.com  Mon Dec  7 14:07:49 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 15:07:49 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207130939.GA29595@202x.moe>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207130939.GA29595@202x.moe>
Message-ID: <D139A87A-1982-4D99-B226-C0CA94799AC9@gmail.com>



> On Dec 7, 2020, at 14:09, bie <bie at 202x.moe> wrote:
> 
> That said, I don't think there's anything wrong with a friendly client
> showing percent-decoded unicode representations of a path or
> punycode-decoded representations of an international domain name in the
> address bar or anywhere else in the interface.
> 
> In the same vein, if a server wants to be extra friendly to gmi file
> authors, it can, like I suggested earlier, allow users to name and link
> to files in unicode, but percent-encode everything before sending it to
> over the wire.

This.

It's the job of the internationally minded client and server to do the proper legwork for the end user so the over-the-wire format is correct.

No need to change anything in the protocol itself, but rather an opportunity for clients and servers to distinguish themselves.

Alternatively: 

Unidecode! 
https://interglacial.com/tpj/22/
Sean M. Burke, Winter, 2001



From colecmac at protonmail.com  Mon Dec  7 14:30:37 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 14:30:37 +0000
Subject: IDN with Gemini?
In-Reply-To: <oSB5tZNeZdmH7qimGHNq1gBYjFFh9COmcbhgK7DLpm1jffs0RennwNet6NoxSdMsPLIynJJU95aPxTyOgJygkR_af2CGCJ6WBT7nKSZiGhw=@protonmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <oSB5tZNeZdmH7qimGHNq1gBYjFFh9COmcbhgK7DLpm1jffs0RennwNet6NoxSdMsPLIynJJU95aPxTyOgJygkR_af2CGCJ6WBT7nKSZiGhw=@protonmail.com>
Message-ID: <58Pnvuo4m6geXEZ74r6qTIla6eZ0thHNQ_vani6z9l2tEfOJSF_SWYUF6ZhQntINnJr750RtcBixiYksSd5Txyrijzezw4VsUrVO7S5eNZ4=@protonmail.com>

On Monday, December 7, 2020 8:56 AM, <colecmac at protonmail.com> wrote:

> Not sure exactly where to jump in, so I'm gonna share my thoughts here.
> <snip>

One last thing to add to this email:

Now that I've outlined the issues with IRIs, could we get back to talking
about the original IDN idea? Does anyone have issues with this proposal[1]?
I'm hoping to consolidate everything there, and Solderpunk can look at that
and make his decision.


1: https://github.com/makeworld-the-better-one/go-gemini/issues/10


Cheers,
makeworld

From smallick.dev at gmail.com  Mon Dec  7 14:53:32 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Mon, 7 Dec 2020 20:23:32 +0530
Subject: [ANN] Geminiserver ASM
In-Reply-To: <34f72846-8b25-2630-d1a7-2b6b9ef3e9c1@g-n.site>
References: <34f72846-8b25-2630-d1a7-2b6b9ef3e9c1@g-n.site>
Message-ID: <CAFaUHv+g7y=7nnvvDiFhc_GRaN7+pMDH=PFiG3XXr9wWPVyHrA@mail.gmail.com>

On 12/7/20, Simon <gemini at g-n.site> wrote:
> Hello!
>
> I just want to announce a very little server written in ASM for linux
> x64. It uses only syscalls. Why did I do that? Just for fun :)
>
> More details on (in?) my (new) capsule :
> gemini://g-n.site/en/2020-12-03-geminiserver_asm.gmi
>
> Have a nice day,
>
> Simon
>
Yay! Gemini server written in (linux-amd64-nolibc-nasm) assembly.
Really, this is what we were expecting to see given the simplicity of
the protocol. Great job.
I'd suggest two things:

* use $-label trick instead of hardcoding string length and
* a simple way of configuration instead of editing that file: say
using a symbol that would be defined when assembling like -D
host=my.host.tld -D port=1955 -D errpath=/error etc.


Cheers,
~smlckz

From stephane at sources.org  Mon Dec  7 15:09:54 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 16:09:54 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207111907.GA53725@202x.moe>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207092934.GA11501@202x.moe>
 <20201207105309.GE17138@sources.org>
 <20201207111907.GA53725@202x.moe>
Message-ID: <20201207150954.GA24884@sources.org>

On Mon, Dec 07, 2020 at 08:19:07PM +0900,
 bie <bie at 202x.moe> wrote 
 a message of 17 lines which said:

> I've got servers running on international domain names, and the majority
> of the pages I'm serving have Japanese characters in the paths.
> This works *today* in every single gemini client I've tried,

I don't know which ones you tried but Amfora, AV-98, Bombadillo and
Lagrange all fail on such names.

From stephane at sources.org  Mon Dec  7 15:32:16 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 16:32:16 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207123041.GA17160@localhost.localdomain>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
Message-ID: <20201207153216.GA25299@sources.org>

On Mon, Dec 07, 2020 at 01:30:41PM +0100,
 marc <marcx2 at welz.org.za> wrote 
 a message of 45 lines which said:

> An URL is an address, in the same way that a phone number or an IP
> is an address. Ideally these are globally unique, unambiguous and
> representable everywhere.  This address scheme should be independent
> of a localisation.

This theory, in the world of domain names, is wrong. RFC 2277 says
that "protocol elements" (basically, the things the user does not see
such as the MIME type text/gemini) do not have to be
internationalized. Everything else ("text", says the RFC) must be
internationalized, simply because the world is like that, with
multiple scripts and languages. Now, identifiers, like domain names,
are a complicated case, since they are both protocol elements and
text. But, since they are widely visible (in advertisments, business
cards, etc), I believe they should be internationalized, too.

> Using unicode in addresses balkanises this global space

The english-speaking space is not a global space: it is the space of a
minority of the world population.

> subtle ambiguities (is the cyrilic C the same as a latin - C, who
> knows ?),

There is no ambiguity, U+0421 is different from  U+0043.

> reducing security,

That's false. I stil wait to see an actual phishing email with
Unicode. Most of the time, the phisher does not even bother to have a
realistic URL, they advertise <http://evil.example/famousbank> and it
works (few people check URL).

Anyway, the goal of Gemini is not to do onli banking so this is not
really an issue.

> If somebody points me at an url in kanji or ethiopian, I would have
> great difficulty remembering nevermind recreating it,

It is safe to assume that a URL in ethiopian is for people who speak
the relevant language so it is not a problem. 

> without a common denominator this is an N^2 problem.

There is no common denominator (unless someone decided that everybody
must use english but I don't remember such decision).

> but interacting with the internet requires
> a jargon or specialisation anyway, in the same way that botanists
> invoke latin names, mathematicians write about eigenvectors
> and brain surgeons talk about the hippocampus, all regardless
> of which languages they speak at home.

OK, then let's all use Hangul for URL. (It's a nice script, very
regular, so it is convenient for computer programs.)

From stephane at sources.org  Mon Dec  7 15:34:22 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 7 Dec 2020 16:34:22 +0100
Subject: IDN with Gemini?
In-Reply-To: <D139A87A-1982-4D99-B226-C0CA94799AC9@gmail.com>
References: <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207130939.GA29595@202x.moe>
 <D139A87A-1982-4D99-B226-C0CA94799AC9@gmail.com>
Message-ID: <20201207153422.GB25299@sources.org>

On Mon, Dec 07, 2020 at 03:07:49PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 31 lines which said:

> It's the job of the internationally minded client and server to do
> the proper legwork for the end user so the over-the-wire format is
> correct.
 
> No need to change anything in the protocol itself, but rather an
> opportunity for clients and servers to distinguish themselves.

This is what gives us the current situation. There is no
interoperability because each client and server did it in a different
way, or not at all.

Since Gemini (for good reasons) have no User-Agent, no negotiation of
options, we must specify clearly how Unicode is handled or the
geminispace won't be safe for Unicode.

From bie at 202x.moe  Mon Dec  7 15:41:55 2020
From: bie at 202x.moe (bie)
Date: Tue, 8 Dec 2020 00:41:55 +0900
Subject: IDN with Gemini?
In-Reply-To: <20201207150954.GA24884@sources.org>
References: <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207092934.GA11501@202x.moe>
 <20201207105309.GE17138@sources.org>
 <20201207111907.GA53725@202x.moe>
 <20201207150954.GA24884@sources.org>
Message-ID: <20201207154155.GA64142@202x.moe>

> > I've got servers running on international domain names, and the majority
> > of the pages I'm serving have Japanese characters in the paths.
> > This works *today* in every single gemini client I've tried,
> 
> I don't know which ones you tried but Amfora, AV-98, Bombadillo and
> Lagrange all fail on such names.

You cut off the important part of my reply, which specifies that the
names are percent-encoded or punycoded... here are some examples, all
work in Amfora, AV-98 and Lagrange (probably Bombadillo too):

gemini://blekksprut.net/%e6%97%a5%e5%b8%b8%e9%91%91%e8%b3%9e/ (a
friendly client could choose to display this as
gemini://blekksprut.net/????)

gemini://xn--td2a.jp/ (a friendly client could choose to display this as
gemini://?.jp/)

Even in the simplest of user-agents, these URIs work, and more advanced
clients clients can choose to display them in more user-friendly ways.

bie

From petite.abeille at gmail.com  Mon Dec  7 16:26:38 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 17:26:38 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207153422.GB25299@sources.org>
References: <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207130939.GA29595@202x.moe>
 <D139A87A-1982-4D99-B226-C0CA94799AC9@gmail.com>
 <20201207153422.GB25299@sources.org>
Message-ID: <6DD14A91-EA52-43BB-A0DD-8C81FD75A0A6@gmail.com>



> On Dec 7, 2020, at 16:34, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> This is what gives us the current situation. There is no
> interoperability because each client and server did it in a different
> way, or not at all.

As pointed out -and demonstrated- by <bie> multiple time, all is good... as long as one bothers to properly encode everything :)

And of course, clients and servers may want to go the extra length to facilitate the encoding for the end users.








From petite.abeille at gmail.com  Mon Dec  7 16:33:23 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 17:33:23 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207153216.GA25299@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207153216.GA25299@sources.org>
Message-ID: <49D28606-6F90-437F-9508-F5CEA33EF038@gmail.com>



> On Dec 7, 2020, at 16:32, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> The english-speaking space is not a global space

No, but the internet plumbing is de facto US-ASCII. 

This doesn't have to be a problem if one doesn't make it so.

?How can you govern a planet which has 1,965,246 varieties of encoding?? 
? Charlie de la Gaule

From solene at perso.pw  Mon Dec  7 17:01:26 2020
From: solene at perso.pw (Solene Rapenne)
Date: Mon, 7 Dec 2020 18:01:26 +0100
Subject: IDN with Gemini?
In-Reply-To: <49D28606-6F90-437F-9508-F5CEA33EF038@gmail.com>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207153216.GA25299@sources.org>
 <49D28606-6F90-437F-9508-F5CEA33EF038@gmail.com>
Message-ID: <20201207180126.69934602@kongroo.lan>

On Mon, 7 Dec 2020 17:33:23 +0100
Petite Abeille <petite.abeille at gmail.com>:

> > On Dec 7, 2020, at 16:32, Stephane Bortzmeyer <stephane at sources.org> wrote:
> > 
> > The english-speaking space is not a global space  
> 
> No, but the internet plumbing is de facto US-ASCII. 

If you don't start somewhere, that will never improve.
 
> This doesn't have to be a problem if one doesn't make it so.
> 
> ?How can you govern a planet which has 1,965,246 varieties of encoding?? 
> ? Charlie de la Gaule

I'm pretty sure it was about cheeses in the original quote :)

From come at chilliet.eu  Mon Dec  7 17:35:26 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Mon, 07 Dec 2020 18:35:26 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201204135138.GA684@sources.org>
References: <20201204135138.GA684@sources.org>
Message-ID: <5803930.odQ0NCZWSD@tempete>

Hi,

Some thoughts on answers on the topic of unicode links. (I will focus on unicode in path rather than in domain here).

First, I wanted to point out that almost no-one uses them on the french Web. Some used that as an argument against having unicode in URIs, but I think no one uses them because of the punycode and percent encoding weirdness.

I read part of the RFC 3987 (IRI) and part of RFC 3986 (URI) and still do not understand what is the horrible added complexity you are talking about.
Could people asserting IRI is a complex hell impossible to implement point to the exact problems with IRI?

Here is the life cycle of a link in a page:

1 - The author writes it
2 - The server saves it
3 - A client requires the page to the server
4 - The server sends it
5 - The client display it
6 - The user click it
7 - The client resolve the hostname
8 - The client sends it as request to the server
9 - The server fetches the associated page

I think we can safely assume that the author will not write percent encoding without help.

So, with bie suggestions that clients and servers help by percent-encoding, but the author/user only have to deal with unicode, it means:
1 - somewhere between step 1 and step 4, the server have to percent-encode the link
2 - somewhere between step 4 and 5 the client needs to decode it
3 - In 8 either the client stored the encoded link or has to reencode again, or if someone copy/paste he has to reencode.
4 - In 9 the server needs to decode it to get the real target path

If we just use the utf-8 path all along, points 1 throuh 3 are not needed. 4 still is, because some links will still be percent encoded and the server needs to understand them.

> Petite Abeille <petite.abeille at gmail.com>:
> No, but the internet plumbing is de facto US-ASCII. 

If this is true, why bother with responses in utf-8?

Regarding the breaking change argument, I think it is a bit weak, testing shows there is no consistency in how different clients/servers handles unicode currently.

> bie:
> I actually implemented this in my personal gemini server
> today, and it was a trivial change (especially when compared to what I'd0
> have to do to properly validate IRIs...), allowing me to write "=> ??/
> ??" and have it sent to the client as "=> %e%9b%91%e5%bf%b5/ ??".

If you are all this confortable with links that looks like ?%e%9b%91%e5%bf%b5? lets go the whole way and percent-encode ascii as well.
Let?s see how long before you change your mind after using this kind of stuff on a daily basis. And at least this would put all languages at the same point.
	
> colecmac at protonmail.com
> Supporting IRIs is *not* simple. For example, in Python it requires a
> third-party library[1], and in Go I wasn't even able to find one. This
> means that in many programming languages, no one would be able to even
> begin writing a Gemini client before writing a library that parses and
> conforms to the complex specification that is IRIs.

On the server I wrote in PHP, getting a request in UTF-8 worked without me doing anything for it. Not accepting IRI would actually require me to *add* code, it seems. (again I might have missed a whole lot of edgecases IRI)
In these languages, it means they are actively checking for non-ascii characters? Or are they using string format which is not compatible with utf-8?
They need to speak UTF-8 for the response anyway.
I get that *validating* an IRI might be hard, but is it the job of the server to validate it? I just use whatever input is thrown at me and suppose it is valid.
(Note that these are real non-rethorical questions, I?m not trying to deny that handling IRI would be hard, I?m trying to understand why)

(On a more general note, I guess everyone understood english is not my mother tongue, sorry if I?m being rude or something like that, I?m not trying to. I just really believe using utf-8 here would be better, but I understand there are complex technical questions involved)

MCMic



From colecmac at protonmail.com  Mon Dec  7 18:00:02 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 18:00:02 +0000
Subject: IDN with Gemini?
In-Reply-To: <5803930.odQ0NCZWSD@tempete>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
Message-ID: <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>

C?me's reply here asserts that a client would never need to parse
IRIs, and so there's no added complexity. Just copy the IRI from the
link line, do DNS, and send the IRI to the server. But this is not
true, a client would need to do parsing.

What parsing would a client have to do?

- Extracting the domain, so it can be punycoded for DNS lookups
- Resolving relative IRIs would require parsing the current IRI,
   and the provided one, and combining them. You cannot just copy it
   to make the request.
- When receiving an input status code on a page that already has a
   query string, the IRI has to be parsed to detect that there is a
   query string, and then remove and replace it with the new input of
   the user.
- Extracting the path to get a name for downloading files
- Etc.

There are many reasons why a client would need to be able to parse an
IRI, the relative link one and DNS one being the most important.

This would then require IRI parsing libraries, and as I have explained
earlier, these don't exist in likely many programming languages, and
when they do, they are third-party.

For this reason, as well as the previously stated reason of this being
a large breaking change, I can't support a switch to IRIs.

IDNs, on the other hand... :)

Cheers,
makeworld

From me at adnano.co  Mon Dec  7 18:13:17 2020
From: me at adnano.co (Adnan Maolood)
Date: Mon, 07 Dec 2020 18:13:17 GMT
Subject: IDN with Gemini?
In-Reply-To: <20201207123041.GA17160@localhost.localdomain>
Message-ID: <C7MR5KNJX2EY.3UMY8TWYZHWDX@nitro>


On Mon Dec 7, 2020 at 7:30 AM EST, marc wrote:
> Using unicode in addresses balkanises this global space into
> separate little domains, with subtle ambiguities (is the
> cyrilic C the same as a latin - C, who knows ?), reducing
> security, and making crossover harder.

I don't think that using unicode in addresses would decrease security
because of the way that Gemini handles client authentication. Since
client certificates are limited to certain domains and paths, the
certificate will never be applied to the wrong domain, even if it looks
the same to the user.

From petite.abeille at gmail.com  Mon Dec  7 19:44:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 20:44:37 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207180126.69934602@kongroo.lan>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207153216.GA25299@sources.org>
 <49D28606-6F90-437F-9508-F5CEA33EF038@gmail.com>
 <20201207180126.69934602@kongroo.lan>
Message-ID: <0D4E52FA-2936-47A7-B7CB-50F7C6652AAB@gmail.com>



> On Dec 7, 2020, at 18:01, Solene Rapenne <solene at perso.pw> wrote:
> 
>> No, but the internet plumbing is de facto US-ASCII. 
> 
> If you don't start somewhere, that will never improve.

Would it make it less controversial if we refer to it as ISO-IR-006 encoding? :D


From petite.abeille at gmail.com  Mon Dec  7 20:23:57 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 21:23:57 +0100
Subject: IDN with Gemini?
In-Reply-To: <5803930.odQ0NCZWSD@tempete>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
Message-ID: <983CFE8D-7564-4E87-AD48-5E0319B01BE2@gmail.com>



> On Dec 7, 2020, at 18:35, C?me Chilliet <come at chilliet.eu> wrote:
> 
> If this is true, why bother with responses in utf-8?

The response has a textual part at time, which is UTF-8 encoded. Assuming a 2x response code,  the content itself is defined by its content-type, which can be anything, in any encoding, following any relevant  convention. UTF-8 (aka Universal Coded Character Set Transformation Format ? 8-bit) itself is an encoding of Unicode. There is no such things as plain text in 2020.

But this is about URLs, no? 

As long as gemini follows established standards, then one must deal with encodings as defined by those standards.

Not sure why this is controversial. The tooling exists. No one writes UTF-8 by hand. Ditto for URLs encoding/decoding.

Use the Tools, Luke.

P.S.
There is perhaps a bit of a sleight of hands running through gemini's rhetoric about how "simple" everything is. But nothing is *that* simple once one looks at the details. The rabbit hole runs deep. Rome was not build in one day. Nor are gemini's foundations. 

P.P.S.
For entertainment purpose, the DNS RFC dependency graph [pdf]:
https://emaillab.jp/wp/wp-content/uploads/2017/11/RFC-DNS.pdf




From petite.abeille at gmail.com  Mon Dec  7 20:36:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 21:36:09 +0100
Subject: IDN with Gemini?
In-Reply-To: <5803930.odQ0NCZWSD@tempete>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
Message-ID: <694FFA5E-886C-4853-86BD-7D9FF2651E12@gmail.com>



> On Dec 7, 2020, at 18:35, C?me Chilliet <come at chilliet.eu> wrote:
> 
> First, I wanted to point out that almost no-one uses them on the french Web. Some used that as an argument against having unicode in URIs, but I think no one uses them because of the punycode and percent encoding weirdness.

Your very own email address is a good example of where tooling makes a difference.

It nicely reads as C?me Chilliet <come at chilliet.eu> -with accent circonflexe & all- but of course is ISO-IR-006 encoded under the hood as =?ISO-8859-1?Q?C=F4me?= Chilliet <come at chilliet.eu>.

I suspect you didn't type the encoding by hand, nor thing about it twice. It "just" works :)


From gmi1 at scotdoyle.com  Mon Dec  7 21:00:33 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Mon, 7 Dec 2020 15:00:33 -0600
Subject: IDN with Gemini?
In-Reply-To: <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
Message-ID: <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>

On 12/7/20 12:00 PM, colecmac at protonmail.com wrote:
> What parsing would a client have to do?
>
> - Extracting the domain, so it can be punycoded for DNS lookups
>

Can we be sure gemini host resolution will always use the global DNS?

Section 4 of RFC 6055 cautions against assuming that all name resolution
is using the global DNS and therefore that querying with punycode
domain names will succeed:

 ? It is inappropriate for an application that calls a general-purpose
   name resolution library to convert a name to an A-label unless the
   application is absolutely certain that, in all environments where the
   application might be used, only the global DNS that uses IDNA
   A-labels actually will be used to resolve the name.

Conversely, querying with utf8 domain names fails on Ubuntu 20.04
using systemd-resolved [1].

Some languages/libraries such as Python convert utf8 requests to
punycode silently before submitting the request to the resolver [2].



[1] C program fails without punycode conversion
#include <netdb.h>
#include <stdio.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
int show_ip(char *name) {
   struct hostent *entry;
   entry = gethostbyname(name);
   if (entry) {
     printf("name '%s' has ip address\n", entry->h_name);
     printf("ip: %s\n\n",inet_ntoa(*(struct in_addr*)entry->h_name));
   } else {
     printf("error querying '%s': %s\n", name, hstrerror(h_errno));
   }
}
int main() {
   show_ip("xn--td2a.jp");
   show_ip("?.jp");
}


[2] Python program succeeds with *implicit* punycode conversion
import socket
def show_ip(name):
   print("name '%s' has ip '%s'" % (name, (socket.gethostbyname(name))))
show_ip('xn--td2a.jp')
show_ip('?.jp')


From petite.abeille at gmail.com  Mon Dec  7 21:20:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 22:20:58 +0100
Subject: IDN with Gemini?
In-Reply-To: <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
Message-ID: <A540A850-5C3B-4BE9-B5E6-DDBD85745F79@gmail.com>



> On Dec 7, 2020, at 19:00, colecmac at protonmail.com wrote:
> 
> IDNs, on the other hand... :)

The "Internationalized Domain Names (IDN) FAQ" makes for entertaining reading:

https://unicode.org/faq/idn.html

Special mention of our very own St?phane Bortzmeyer under "Doesn't the removal of symbols and punctuation in IDNA2008 help security?":

Le hame?onnage n'a pas de rapport avec les IDN
https://www.bortzmeyer.org/idn-et-phishing.html

(short answer: no)

All encrypted in French sadly :P

Happy hame?onnage.

Fun, fun, fun.


From colecmac at protonmail.com  Mon Dec  7 21:46:06 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 21:46:06 +0000
Subject: IDN with Gemini?
In-Reply-To: <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
Message-ID: <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>

On Monday, December 7, 2020 4:00 PM, Scot <gmi1 at scotdoyle.com> wrote:

> On 12/7/20 12:00 PM, colecmac at protonmail.com wrote:
>
> > What parsing would a client have to do?
> >
> > -   Extracting the domain, so it can be punycoded for DNS lookups
>
> Can we be sure gemini host resolution will always use the global DNS?
>
> Section 4 of RFC 6055 cautions against assuming that all name resolution
> is using the global DNS and therefore that querying with punycode
> domain names will succeed:
>
> ? It is inappropriate for an application that calls a general-purpose
>   name resolution library to convert a name to an A-label unless the
>   application is absolutely certain that, in all environments where the
>   application might be used, only the global DNS that uses IDNA
>   A-labels actually will be used to resolve the name.

That's interesting, thanks for sharing. However, it seems obvious to me
that punycoding is a necessity, since the global DNS system won't work
without it. I've worked with offline mesh network systems, but never
had to handle Unicode domain names. However, all of our stack was software
that was intended to work on the Internet, as well as any other network.
Standard DNS servers, standard OS and stdlib DNS resolvers, etc. So
punycoding would be the right way to do it in that network too.

Despite what this RFC says, I don't see what situation would actually
completely fail on punycoded domains. I guess the spec could mandate trying
with punycode first, than Unicode, but that seems needless to me. Do you
have an example of a system/network that fails on punycode?

> Conversely, querying with utf8 domain names fails on Ubuntu 20.04
> using systemd-resolved [1].

Yep, that's what I meant when I called it a necessity.

> Some languages/libraries such as Python convert utf8 requests to
> punycode silently before submitting the request to the resolver [2].

That's pretty handy, but it doesn't change my advice. The spec can state
that all domains must by punycoded for DNS, and maybe your library
will handle that or not. Even if an unware Pythonista manually punycodes
the domain, nothing bad will happen when the library tries again.

Cheers,
makeworld

From petite.abeille at gmail.com  Mon Dec  7 21:49:24 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 7 Dec 2020 22:49:24 +0100
Subject: Crocker's Rules (was Re: IDN with Gemini?)
In-Reply-To: <5803930.odQ0NCZWSD@tempete>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
Message-ID: <08073F7F-049A-4EA3-9089-F88E8BEFD8D5@gmail.com>



> On Dec 7, 2020, at 18:35, C?me Chilliet <come at chilliet.eu> wrote:
> 
> (On a more general note, I guess everyone understood english is not my mother tongue, sorry if I?m being rude or something like that, I?m not trying to. I just really believe using utf-8 here would be better, but I understand there are complex technical questions involved)

(hopefully) this space operates under the so-called "Crocker's Rules"*:

(perhaps) worthwhile quoting in full:

Declaring yourself to be operating by "Crocker's Rules" means that other people are allowed to optimize their messages for information, not for being nice to you.  Crocker's Rules means that you have accepted full responsibility for the operation of your own mind - if you're offended, it's your fault.  Anyone is allowed to call you a moron and claim to be doing you a favor.  (Which, in point of fact, they would be.  One of the big problems with this culture is that everyone's afraid to tell you you're wrong, or they think they have to dance around it.)  Two people using Crocker's Rules should be able to communicate all relevant information in the minimum amount of time, without paraphrasing or social formatting.  Obviously, don't declare yourself to be operating by Crocker's Rules unless you have that kind of mental discipline.
Note that Crocker's Rules does not mean you can insult people; it means that other people don't have to worry about whether they are insulting you.  Crocker's Rules are a discipline, not a privilege.  Furthermore, taking advantage of Crocker's Rules does not imply reciprocity.  How could it?  Crocker's Rules are something you do for yourself, to maximize information received - not something you grit your teeth over and do as a favor.

"Crocker's Rules" are named after Lee Daniel Crocker.

http://sl4.org/crocker.html
https://en.wikipedia.org/wiki/Lee_Daniel_Crocker

* Link curtesy of St?phane Bortzmeyer. Thanks St?phane.



From sean at conman.org  Mon Dec  7 23:37:51 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 7 Dec 2020 18:37:51 -0500
Subject: IDN with Gemini?
In-Reply-To: <5803930.odQ0NCZWSD@tempete>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
Message-ID: <20201207233751.GN24194@brevard.conman.org>

It was thus said that the Great C?me Chilliet once stated:
> Hi,
> 
> Some thoughts on answers on the topic of unicode links. (I will focus on
> unicode in path rather than in domain here).
> 
> First, I wanted to point out that almost no-one uses them on the french
> Web. Some used that as an argument against having unicode in URIs, but I
> think no one uses them because of the punycode and percent encoding
> weirdness.
> 
> I read part of the RFC 3987 (IRI) and part of RFC 3986 (URI) and still do
> not understand what is the horrible added complexity you are talking
> about. Could people asserting IRI is a complex hell impossible to
> implement point to the exact problems with IRI?

  I'm reading through RFC-3987, and sections 4 and 5 give me pause.  Section
4 relates to bidirectional IRIs (right-to-left languages).  This is mostly a
client issue (I think) with the displaying of such.

  Section 5 is the scarier of the two---normalization and comparison, and
would most likely affect servers than clients (again, I think).  There are
two examples given:

	http://www.example.org/r&#xE9;sum&#xE9;.html
	http://www.example.org/re&#x301;sume&#x301;.html

  The first uses a precomposed character and the second uses a combining
character.  I'm looking at the Unicode normalization standard [1], and the
first thing that struck me was I had *not* thought of the order of multiple
combining characters.  Oh, there's also Hangul and conjoining jamo.  And
then ... well, I'll spare the horrors of that 32k document, but the upshot
is---yes, that's yet *another* library I have to track down (and update as
the Unicode standard is regularly updated).

  Also, related question---what's the filename on the server?

  The "horrible added complexity" is not RFC-3987 per se, but the "horrible
added complexity" of Unicode normalization that is required.  Is that a
valid excuse?  Perhaps not.  But there *is* the issue that a lot of people
are having with Python 3 and filenames.  If you hit a filename that isn't
UTF-8 and the Python 3 script breaks badly.  Yes, there *is* a link in my
mind between these two issues but I'm not sure I can verbalize it coherently
at this time.  Perhaps "I will focus on unicode in the path" reminided me of
the Python 3 issue.

> Regarding the breaking change argument, I think it is a bit weak, testing
> shows there is no consistency in how different clients/servers handles
> unicode currently.

 ...

> (Note that these are real non-rethorical questions, I?m not trying to deny
> that handling IRI would be hard, I?m trying to understand why)

  Methinks you inadverantly answered your own question---Unicode is *not*
easy [1][2][3][4].

  -spc

[1]	https://www.unicode.org/reports/tr15/tr15-50.html

[2]	https://www.unicode.org/reports/tr9/tr9-42.html

[3]	https://www.unicode.org/reports/tr14/tr14-45.html

[4]	Among others.  The full current standard:

	http://www.unicode.org/versions/Unicode13.0.0/


From come at chilliet.eu  Mon Dec  7 23:40:43 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Tue, 08 Dec 2020 00:40:43 +0100
Subject: IDN with Gemini?
In-Reply-To: <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
Message-ID: <4308633.o1BF5sGNnQ@tempete>

Le lundi 7 d?cembre 2020, 19:00:02 CET colecmac at protonmail.com a ?crit :
> C?me's reply here asserts that a client would never need to parse
> IRIs, and so there's no added complexity. Just copy the IRI from the
> link line, do DNS, and send the IRI to the server. But this is not
> true, a client would need to do parsing.
> 
> What parsing would a client have to do?
> 
> - Extracting the domain, so it can be punycoded for DNS lookups

True, thanks for pointing that out.

> - Resolving relative IRIs would require parsing the current IRI,
>    and the provided one, and combining them. You cannot just copy it
>    to make the request.

Also true, but it should be the same value that is extracted for DNS.

> - When receiving an input status code on a page that already has a
>    query string, the IRI has to be parsed to detect that there is a
>    query string, and then remove and replace it with the new input of
>    the user.

Good to know, I did not think of query string situation.

> - Extracting the path to get a name for downloading files
> - Etc.
> 
> There are many reasons why a client would need to be able to parse an
> IRI, the relative link one and DNS one being the most important.
> 
> This would then require IRI parsing libraries, and as I have explained
> earlier, these don't exist in likely many programming languages, and
> when they do, they are third-party.

From what you said on irc, the situation is different between URI and IRI because most languages have URI parsing either in their stdlib or in a well tested known library.
But, if no project use IRI, of course no one will write a library for it, this is a chicken and egg situation here.

Also, for the purpose of a client, it seems to me the parsing needed (domain and query extraction) is only to search for the first "/" and the last "?", and some minor tweaks on the scheme maybe (which does not contain unicode, I will leave the scheme alone, promise).

Note: Just tried gemini://gemini.circumlunar.space/%64%6f%63%73/%66%61%71%2e%67%6d%69 in lagrange, it does work.

C?me



From colecmac at protonmail.com  Mon Dec  7 23:54:24 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Mon, 07 Dec 2020 23:54:24 +0000
Subject: IDN with Gemini?
In-Reply-To: <4308633.o1BF5sGNnQ@tempete>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <4308633.o1BF5sGNnQ@tempete>
Message-ID: <q7qS0ixprcnlFN6CAm3ZO5xd0DlATrZyrnf8GFntjju6BDDPXiSffMw8YdoDlNsKKdXUdlvbTOKzcjXKyKECvRN3gc-chprwI-ipf2FJikE=@protonmail.com>

Glad to hear that you realize how it's more complex than you originally
thought.

> > -   Resolving relative IRIs would require parsing the current IRI,
> >     and the provided one, and combining them. You cannot just copy it
> >     to make the request.
> >
>
> Also true, but it should be the same value that is extracted for DNS.

No. I'm referring to things like this:

=> /docs/
=> example.gmi
=> dir/test/foo.gmi
=> //gus.guru/

These are all relative in some way, and they must be resolved in reference
to the IRI (or for Gemini right now, the URI) of the current page. This is not
the same as the domain that was extracted for DNS, and requires a full
parser.

> From what you said on irc, the situation is different between URI and IRI
> because most languages have URI parsing either in their stdlib or in a well
> tested known library. But, if no project use IRI, of course no one will
> write a library for it, this is a chicken and egg situation here.

Yep, it's a shame. But we must live with it, and so URIs are the way forward.

> Also, for the purpose of a client, it seems to me the parsing needed
> (domain and query extraction) is only to search for the first "/" and the last
> "?", and some minor tweaks on the scheme maybe (which does not contain unicode,
> I will leave the scheme alone, promise).

It's always more complex than that. I'm a bit too tired to go dig into the RFCs
to prove it right now, but I would not trust software that just matches some
characters instead of compliantly parsing things in their entirety. This method
would make Gemini more complex and easily introduce bugs. If we use URIs, we don't
have to resort to this.

> Note: Just tried gemini://gemini.circumlunar.space/%64%6f%63%73/%66%61%71%2e%67%6d%69
> in lagrange, it does work.

Works in Amfora too, and note that also the server software (Molly Brown) is accepting
and parsing it correctly into a file path. But that's expected, because it's
perfectly valid to percent-encode ASCII in a URL path.

Cheers,
makeworld

From sean at conman.org  Tue Dec  8 00:04:51 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 7 Dec 2020 19:04:51 -0500
Subject: IDN with Gemini?
In-Reply-To: <4308633.o1BF5sGNnQ@tempete>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <4308633.o1BF5sGNnQ@tempete>
Message-ID: <20201208000451.GO24194@brevard.conman.org>

It was thus said that the Great C?me Chilliet once stated:
> Le lundi 7 d?cembre 2020, 19:00:02 CET colecmac at protonmail.com a ?crit :
> > 
> > This would then require IRI parsing libraries, and as I have explained
> > earlier, these don't exist in likely many programming languages, and
> > when they do, they are third-party.
> 
> From what you said on irc, the situation is different between URI and IRI
> because most languages have URI parsing either in their stdlib or in a
> well tested known library. But, if no project use IRI, of course no one
> will write a library for it, this is a chicken and egg situation here.

  I'm looking at RFC-3987 [1] and the changes from RFC-3986 [2] are minimal,
and it would be easy to modify my own URI parsing library [3] (which is
based directly off the BNF of RFC-3986) but that only gets me so far.  The
other issue is Unicode normalization and punycode support, both of which I
would have to track down existing libraries or (and I shudder to think this)
write my own.

> Also, for the purpose of a client, it seems to me the parsing needed
> (domain and query extraction) is only to search for the first "/" and the
> last "?", and some minor tweaks on the scheme maybe (which does not
> contain unicode, I will leave the scheme alone, promise).

  And then do some Unicode normalization to match how filenames are stored
on your server:

	http://www.example.org/r&#xE9;sum&#xE9;.html
	http://www.example.org/re&#x301;sume&#x301;.html

  -spc

[1]	https://tools.ietf.org/html/rfc3987

[2]	https://tools.ietf.org/html/rfc3986

[3]	https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

From linde.philip at gmail.com  Tue Dec  8 00:18:07 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 8 Dec 2020 01:18:07 +0100
Subject: IDN with Gemini?
In-Reply-To: <C7MR5KNJX2EY.3UMY8TWYZHWDX@nitro>
References: <20201207123041.GA17160@localhost.localdomain>
 <C7MR5KNJX2EY.3UMY8TWYZHWDX@nitro>
Message-ID: <20201208011807.2907c25c7f0cf93db12ad837@gmail.com>

On Mon, 07 Dec 2020 18:13:17 GMT
"Adnan Maolood" <me at adnano.co> wrote:

> I don't think that using unicode in addresses would decrease security
> because of the way that Gemini handles client authentication. Since
> client certificates are limited to certain domains and paths, the
> certificate will never be applied to the wrong domain, even if it looks
> the same to the user.

Security might also mean knowing that I'm not unintendedly divulging
any details of my browsing habits to some unknown third party, or
knowing that no one can impersonate your server and pages to mislead
your readers. Neither of those necessarily involve client certificates
at all but are a real possibility when multiple code points can
represent similar or identical glyphs.

I can see how IRI and IDN may be a good idea in terms of including
languages with bigger or altogether different alphabets or
non-alphabets, but from the perspective of an implementer, it does add
a lot of complexity and opens up to homograph attacks in an area where
ASCII transliteration is already the norm. Some browsers deal with
homograph attacks by displaying punycode directly based on some basic
heuristic (e.g. when a hostname contains both cyrillic and latin codes).

I don't know much about IRI. Web browsers for example sort of skipped on
this standard in favor of the WHATWG URL spec.

Personally, I think some concessions need to be made to maintain the
simplicity of the protocol. The currently mandated standard is
(relatively) short and simple to implement, and transliteration is
already pervasive in the area of internet names and URIs. Octet
encoded ASCII does have the nice property that there are no homographs,
there's no normalization, there's nobidirectional text etc. and there
is no database of rules that have to be applied to handle these things.

That said, I think a lot can be improved on the client side without
changing the standard. Clients can optionally do the ToASCII/ToUnicode
dance and correspondingly automatically percent encode input and display
"un-percented" paths in some circumstances. The standard only specifies
what needs to be sent to the server to request a resource, and what
text/gemini documents need to contain to produce a link. This opens up
a lot of quality of life improvements on the user interface level.

RFC 4690 is a good read on the topic of IDNs.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/55dad39f/attachment.sig>

From gmi1 at scotdoyle.com  Tue Dec  8 02:21:18 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Mon, 7 Dec 2020 20:21:18 -0600
Subject: IDN with Gemini?
In-Reply-To: <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
 <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
Message-ID: <045cd0f5-4569-4b2c-cb58-e3ab6211cd25@scotdoyle.com>

On 12/7/20 3:46 PM, colecmac at protonmail.com wrote:
> On Monday, December 7, 2020 4:00 PM, Scot<gmi1 at scotdoyle.com>  wrote:
>
>> On 12/7/20 12:00 PM,colecmac at protonmail.com  wrote:
>>
>>> What parsing would a client have to do?
>>>
>>> -   Extracting the domain, so it can be punycoded for DNS lookups
>> Can we be sure gemini host resolution will always use the global DNS?
>>
>> Section 4 of RFC 6055 cautions against assuming that all name resolution
>> is using the global DNS and therefore that querying with punycode
>> domain names will succeed:
>>
>>  ? It is inappropriate for an application that calls a general-purpose
>>    name resolution library to convert a name to an A-label unless the
>>    application is absolutely certain that, in all environments where the
>>    application might be used, only the global DNS that uses IDNA
>>    A-labels actually will be used to resolve the name.
> ... Do you have an example of a system/network that fails on punycode?
>
Yes, an organization's internal network resolver or a user's local
resolver could reply to utf8 queries but not punycode queries.

For example, adding the line:

 ? 10.99.99.1? ??.jp

to /etc/hosts on Ubuntu 20.04 with resolver systemd-resolved
and running the test program [1] gives this output:

 ? error querying 'xn--td2aa.jp': Unknown server error

 ? name '??.jp' has ip address 10.99.99.1


[1]
#include <netdb.h>
#include <stdio.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>

int show_ip(char *name) {
 ? struct hostent *entry;
 ? entry = gethostbyname(name);
 ? if (entry) {
 ??? printf("name '%s' has ip address %s\n\n", entry->h_name,
 ?????????? inet_ntoa(*((struct in_addr*)entry->h_addr)));
 ? } else {
 ??? printf("error querying '%s': %s\n\n", name, hstrerror(h_errno));
 ? }
}

int main() {
 ? show_ip("xn--td2aa.jp");
 ? show_ip("??.jp");
}

From cowan at ccil.org  Tue Dec  8 02:37:28 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 7 Dec 2020 21:37:28 -0500
Subject: Three possible uses for IRIs
Message-ID: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>

(Starting a separate thread for this)

I think there are three possible places where IRIs could possibly appear in
Gemini:

1) In client inputs (the address bar or CLI analogue) and outputs
(revealing a link)

2) In the Gemini protocol

3) In text/gemini link lines

I think it's important to disentangle these three cases.  Case 1 just
affects individual clients and can be left up to them, except that there is
some best-practice advice about when *n?t* to display an IRI, specifically
when there are cross-script confusables involved.  For example,
"gemini://gemini.circumlunar.xn--spce-63d/" should not be displayed as
"gemini://gemini.circumlunar.sp?ce", because that would be deceptive, even
in Gemini: you might be pointed to the Evil Version of the Gemini spec and
not realize it.

I think everyone agrees that Case 2 is a mistake: the protocol elements
should continue to be URIs.

Case 3 is the difficult one.  Should authors be allowed to write
text/gemini links with IRI references? It's not that hard for a client to
convert them to URI references.  No normalization is needed except as part
of punycoding.  However, everyone has to agree on whether this should work
or not; we don't want a user trying to follow a link and sending the Wrong
Thing to the server.

Gemini isn't just supposed to be easy to program for, it's supposed to be
easy to author, too.  Unfortunately these objectives are in conflict here.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Lope de Vega: "It wonders me I can speak at all.  Some caitiff rogue
did rudely yerk me on the knob, wherefrom my wits yet wander."
An Englishman: "Ay, belike a filchman to the nab'll leave you
crank for a spell." --Harry Turtledove, Ruled Britannia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201207/ed25588c/attachment.htm>

From colecmac at protonmail.com  Tue Dec  8 02:38:57 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 02:38:57 +0000
Subject: IDN with Gemini?
In-Reply-To: <045cd0f5-4569-4b2c-cb58-e3ab6211cd25@scotdoyle.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
 <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
 <045cd0f5-4569-4b2c-cb58-e3ab6211cd25@scotdoyle.com>
Message-ID: <SgWfWNgllXgxeUico-eCECaw0hzePkhCsdiC6TgksDmUdaRPu8sz2T-V-9eBWcXjM45L1B1-ucxQxyGVakKynS5tNh-2NnozZ_oDUrKuuBE=@protonmail.com>

> > > ... Do you have an example of a system/network that fails on punycode?
>
> Yes, an organization's internal network resolver or a user's local
> resolver could reply to utf8 queries but not punycode queries.
>
> For example, adding the line:
>
> ? 10.99.99.1? ??.jp
>
> to /etc/hosts on Ubuntu 20.04 with resolver systemd-resolved
> and running the test program [1] gives this output:
>
> ? error querying '??.jp': Unknown server error
>
> ? name '??.jp' has ip address 10.99.99.1

Thanks for the example, although it seems very contrived to me. Firefox
will punycode the domain right after putting it into the address bar,
for example, so any network that wants to support web browsing must use
a punycoded version. I'm sure there are many other pieces of software
that do the same.

Your example doesn't really convince me that a Gemini browser is going
to encounter a situation where doing a lookup using the punycoded domain
name will be the wrong thing to do. It's not literally impossible for
that to be the case, but I don't really see it being an issue at all.


makeworld

From colecmac at protonmail.com  Tue Dec  8 02:47:22 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 02:47:22 +0000
Subject: Three possible uses for IRIs
In-Reply-To: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
Message-ID: <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>

> (Starting a separate thread for this)

Thanks, that's helpful. Hopefully all IRI discussion can move here.

> Case 3 is the difficult one.? Should authors be allowed to write text/gemini
> links with IRI references??It's not that hard for a client to convert them
> to URI references.? No normalization is needed except as part of punycoding.
> However, everyone has to agree on whether this should work or not; we don't
> want a user trying to follow a link and sending the Wrong Thing to the server.

"It's not that hard for a client to convert them to URI references. No
normalization is needed except as part of punycoding."

I don't think that's true. To convert them to a URI reference, the domain needs
to be extracted and punycoded, then the path and query string needs to be
extracted and percent-encoded in the blessed Gemini way that doesn't allow plus
signs. Doing all this requires parsing, and as I explained a couple times in the
other thread, IRI parsing is not feasible across multiple programming languages
at this time, the libraries just don't exist.

And what if the IRI is a relative reference? As I explained in the other thread,
this will definitely require IRI parsing.

Furthermore, it's breaking change to Gemini. I don't think that's a good idea in
any case with the possible exception of TLS security. Gemini must be reliable,
and it's too late for a breaking change.

> Gemini isn't just supposed to be easy to program for, it's supposed to be easy to
> author, too.? Unfortunately these objectives are in conflict here.

Yes, and that's unfortunate. But I think it makes sense for the stability of Gemini
and the ease of programming to come first.


Cheers,
makeworld


From cowan at ccil.org  Tue Dec  8 04:00:01 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 7 Dec 2020 23:00:01 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
Message-ID: <CAD2gp_QH6VdrmATGO55bdFMtBn3eZZg+Rp_h2L9tPhqm6ubhsQ@mail.gmail.com>

On Mon, Dec 7, 2020 at 9:47 PM <colecmac at protonmail.com> wrote:


> I don't think that's true. To convert them to a URI reference, the domain
> needs
> to be extracted and punycoded,


Agreed.  But if you have a Punycode encoder, then the following steps will
convert an IRI reference to a URI reference, without regard to whether it
is an IRI or a relative reference:

1) Look in the IRI reference for a "//" and a following "/"; if they exist,
pass the characters in between through your encoder and substitute the
result into the IRI reference.

2) Start over from the beginning.  If a character is ASCII, leave it
unchanged.  Otherwise, take the character, convert it to UTF-8 bytes (easy)
and each byte to hex digits (trivial), decorate it with leading %
(trivial), and move on.  When you come to the end, stop.


> Furthermore, it's breaking change to Gemini. I don't think that's a good
> idea in
> any case with the possible exception of TLS security. Gemini must be
> reliable,
> and it's too late for a breaking change.
>

Probably true.  ~~sigh~~



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Normally I can handle panic attacks on my own; but panic is, at the moment,
a way of life.                 --Joseph Zitt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201207/67b23603/attachment.htm>

From ech at emmah.net  Tue Dec  8 04:06:27 2020
From: ech at emmah.net (Emma Humphries)
Date: Mon, 07 Dec 2020 20:06:27 -0800
Subject: Three possible uses for IRIs
In-Reply-To: <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
Message-ID: <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>

On Mon, Dec 7, 2020, at 18:47, colecmac at protonmail.com wrote:

> 
> Yes, and that's unfortunate. But I think it makes sense for the 
> stability of Gemini
> and the ease of programming to come first.

I'm perplexed that "ease of programming" is considered more important than "ease of adoption."

You mention that not every language supports the libraries needed for internationalized URLs. 

What does that lose the project vs. accessibility and broader adoption by non-English-speaking users for who Gemini would be a boon with limited bandwidth and hardware?

I feel like I'm missing something with the emphasis on ease of client implementation over adoption.

Emma Humphries
gemini://gemini.djinn.party/

From colecmac at protonmail.com  Tue Dec  8 04:40:53 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 04:40:53 +0000
Subject: Three possible uses for IRIs
In-Reply-To: <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
Message-ID: <AC2-XhtC64uTE6tl4L0nbLMPu_HcGA7EpnqTjHpCcmBkm6KRs7BUr8M1gJaeXoSAGnARrgsrA799ECgdtxwy9YWke6Mi-lBf3A1dhb1g_m8=@protonmail.com>

> > Yes, and that's unfortunate. But I think it makes sense for the
> > stability of Gemini
> > and the ease of programming to come first.
>
> I'm perplexed that "ease of programming" is considered more important than "ease of adoption."
>
> You mention that not every language supports the libraries needed for internationalized URLs.
>
> What does that lose the project vs. accessibility and broader adoption by non-English-speaking users for who Gemini would be a boon with limited bandwidth and hardware?
>
> I feel like I'm missing something with the emphasis on ease of client implementation over adoption.


I was unsure when I wrote that, and I was worried it would be controversial.
But I still think it makes sense. For Gemini to be accessible, have "broader
adoption", and be "a boon" as you mention, clients need to be easy to write
and maintain. Otherwise, what will these non-English speaking users browse
and serve their content with? A few clients and servers, likely not written
in their native language?

Gemini is a non-commercial hobby project for all the developers I am aware of,
and there are advantages to that. But it also means that if the protocol is hard
to implement, the whole community suffers, because there will be fewer clients
and servers.

The fact that writing URLs for non-English languages is difficult sucks. But
due the complexity, and most of all the fact that this would be a breaking
change, I don't see IRIs as an option.


makeworld


P.S. I'll admit I'm biased. I write more code for Gemini than I do content, and
primarily use my native language English.

From sean at conman.org  Tue Dec  8 08:36:20 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 8 Dec 2020 03:36:20 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <AC2-XhtC64uTE6tl4L0nbLMPu_HcGA7EpnqTjHpCcmBkm6KRs7BUr8M1gJaeXoSAGnARrgsrA799ECgdtxwy9YWke6Mi-lBf3A1dhb1g_m8=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
 <AC2-XhtC64uTE6tl4L0nbLMPu_HcGA7EpnqTjHpCcmBkm6KRs7BUr8M1gJaeXoSAGnARrgsrA799ECgdtxwy9YWke6Mi-lBf3A1dhb1g_m8=@protonmail.com>
Message-ID: <20201208083619.GP24194@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> 
> The fact that writing URLs for non-English languages is difficult sucks. But
> due the complexity, and most of all the fact that this would be a breaking
> change, I don't see IRIs as an option.

  I thought I might see what's involved with handling IRIs.

  The actual differences between RFC-3986 (URI) and RFC-3987 (IRI) besides
one being a standard (URI) and one being a proposed standard (IRI) comes
down to the characters that are accepted---the unreserved set 

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

becomes

   iunreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
   ucschar        = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
                  / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
                  / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
                  / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
                  / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
                  / %xD0000-DFFFD / %xE1000-EFFFD

and the query portion changes from

   query         = *( pchar / "/" / "?" )
   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"


to

   iquery         = *( ipchar / iprivate / "/" / "?" )
   ipchar         = iunreserved / pct-encoded / sub-delims / ":" / "@" 
   iprivate       = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD

and that's it as far as the RFCs go (aside from the rule name changes).  As
a quick proof-of-concept, I just accepted all non-control UTF-8 characters
as unreserved (including the private space) as that was the easiest thing to
do, and yes, it works (but does allow potentially bad IRIs through).  

  But the code to *build* a URL from the parsed representation [2] ssumes
US-ASCII.  Again, it would take just a few small changes to allow UTF-8
characters on input and escape them properly for a URL.  That's something
I'll try working on tomorrow.

  That still leaves the question of punycode [3] and Unicode normalization
(ugh).

> P.S. I'll admit I'm biased. I write more code for Gemini than I do content, and
> primarily use my native language English.

  I am biased too, as a monolingual US mutt, but I do want to try this stuff
out.

  -spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

[2]	https://github.com/spc476/GLV-1.12556/blob/master/Lua/GLV-1/url-util.lua

[3]	RFC-3492, which includes C code to encode and decode punycode text,
	which is valgrind clean (I checked).

From linde.philip at gmail.com  Tue Dec  8 09:29:32 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 8 Dec 2020 10:29:32 +0100
Subject: Three possible uses for IRIs
In-Reply-To: <CAD2gp_QH6VdrmATGO55bdFMtBn3eZZg+Rp_h2L9tPhqm6ubhsQ@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <CAD2gp_QH6VdrmATGO55bdFMtBn3eZZg+Rp_h2L9tPhqm6ubhsQ@mail.gmail.com>
Message-ID: <20201208102932.0af192497ecadb3c6ab6c691@gmail.com>

On Mon, 7 Dec 2020 23:00:01 -0500
John Cowan <cowan at ccil.org> wrote:
 
> Agreed.  But if you have a Punycode encoder, then the following steps will
> convert an IRI reference to a URI reference, without regard to whether it
> is an IRI or a relative reference:
> 
> 1) Look in the IRI reference for a "//" and a following "/"; if they exist,
> pass the characters in between through your encoder and substitute the
> result into the IRI reference.
> 
> 2) Start over from the beginning.  If a character is ASCII, leave it
> unchanged.  Otherwise, take the character, convert it to UTF-8 bytes (easy)
> and each byte to hex digits (trivial), decorate it with leading %
> (trivial), and move on.  When you come to the end, stop.

There's a "drawl the owl" step somewhere here regarding Unicode
normalization. Does the server like your ?:s fully composed or
decomposed, or should the server itself be responsible for
normalization?

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/cf4dc147/attachment.sig>

From petite.abeille at gmail.com  Tue Dec  8 10:10:38 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 8 Dec 2020 11:10:38 +0100
Subject: Three possible uses for IRIs
In-Reply-To: <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
Message-ID: <97CFBCED-D8E0-4FEB-88BA-43AC57FA5957@gmail.com>



> On Dec 8, 2020, at 05:06, Emma Humphries <ech at emmah.net> wrote:
> 
> I'm perplexed that "ease of programming" is considered more important than "ease of adoption."

Or basic use for that matter.

Gemini's narrative is build upon the fallacy that everything is "just-oh-so-trivial": any Dick and Jane can fire up the most bare bone of telnet over their trusty dial-up modem and be done. Some sort of citizen-programmer-publisher nirvana, without any barriers to entry whatsoever. 

Admirable.

But not quite practical. The internet stack is deep, old, and brittle. Tooling matter. 

Still, all very admirable :)

Long live Gemini.



From linde.philip at gmail.com  Tue Dec  8 10:11:28 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 8 Dec 2020 11:11:28 +0100
Subject: Three possible uses for IRIs
In-Reply-To: <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
Message-ID: <20201208111128.8c4b52f715d06f7b52de2e30@gmail.com>

On Mon, 07 Dec 2020 20:06:27 -0800
"Emma Humphries" <ech at emmah.net> wrote:

> I'm perplexed that "ease of programming" is considered more important than "ease of adoption."

Consider "ease of programming" and in particular stability a subset of
"ease of adoption". There are numerous client and server
implementations because it is easy to implement, and easy to maintain
because the protocol is relatively stable even in these early stages.
The different software allows people with different goals to adopt the
protocol, and helps in weeding out shortcomings of clarity in the
specification by analysis of the subtle differences between
implementations.

> You mention that not every language supports the libraries needed for internationalized URLs. 
> 
> What does that lose the project vs. accessibility and broader adoption by non-English-speaking users for who Gemini would be a boon with limited bandwidth and hardware?

It seems more likely that a change to this end would hurt adoption.
Numerous pieces of existing Gemini software would immediately be
invalidated. Not all of them will be updated to accommodate the change.
I could perhaps see a more pressing need for the change if internet
users worldwide weren't already used to transliteration. It's such a
small part as well. UTF-8 is acceptable (and default) in text/gemini
documents, and the text content of a capsule can indeed be written in
any of the scripts supported by Unicode.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/e5119f33/attachment.sig>

From stephane at sources.org  Tue Dec  8 10:27:44 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 8 Dec 2020 11:27:44 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201208011807.2907c25c7f0cf93db12ad837@gmail.com>
References: <20201207123041.GA17160@localhost.localdomain>
 <C7MR5KNJX2EY.3UMY8TWYZHWDX@nitro>
 <20201208011807.2907c25c7f0cf93db12ad837@gmail.com>
Message-ID: <20201208102744.GA11926@sources.org>

On Tue, Dec 08, 2020 at 01:18:07AM +0100,
 Philip Linde <linde.philip at gmail.com> wrote 
 a message of 69 lines which said:

> homograph attacks

Homograph attacks are basically a good way to make an english-speaking
audience laugh when you show them funny Unicode problems (I've seen
that several times in several meetings: the languages and scripts of
other people are always funny). No bad guy use them in real life,
probably because users typically never check the URI or IRI.

And they exist with ASCII, too (goog1e.com...)

> Some browsers deal with homograph attacks by displaying punycode
> directly based on some basic heuristic (e.g. when a hostname
> contains both cyrillic and latin codes).

Which is awful for the UX. Note that such mangling is never done for
ASCII, which clearly shows a provincial bias toward english.

> Octet encoded ASCII does have the nice property that there are no
> homographs, there's no normalization,

This is not true. Since percent-encoding encodes bytes, there are
still several ways to represent "the same" string of characters and
therefore normalization remains an issue.

> RFC 4690 is a good read on the topic of IDNs.

No, it is a one-sided anti-internationalization rant.


From stephane at sources.org  Tue Dec  8 10:29:24 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 8 Dec 2020 11:29:24 +0100
Subject: IDN with Gemini?
In-Reply-To: <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
Message-ID: <20201208102924.GB11926@sources.org>

On Mon, Dec 07, 2020 at 06:00:02PM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 32 lines which said:

> What parsing would a client have to do?
...
> This would then require IRI parsing libraries, and as I have explained
> earlier, these don't exist in likely many programming languages, and
> when they do, they are third-party.

For Python (a common programming language), this is not true, standard
library's urlparse has no problem:

% ./test-urlparse.py gemini://g?meaux.bortzmeyer.org:8965/caf?\?foo=bar
Host name: g?meaux.bortzmeyer.org
Port: 8965
Path: /caf?
Query: foo=bar

% cat test-urlparse.py
#!/usr/bin/env python3

import sys
import urllib.parse

for url in sys.argv[1:]:
    components = urllib.parse.urlparse(url)
    print("Host name: %s" % components.hostname)
    if components.port is not None:
        print("Port: %s" % components.port)
    print("Path: %s" % components.path)
    if components.query != "":
        print("Query: %s" % components.query)

From stephane at sources.org  Tue Dec  8 10:32:08 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 8 Dec 2020 11:32:08 +0100
Subject: IDN with Gemini?
In-Reply-To: <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
 <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
Message-ID: <20201208103208.GC11926@sources.org>

On Mon, Dec 07, 2020 at 09:46:06PM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 49 lines which said:

> Despite what this RFC says, I don't see what situation would actually
> completely fail on punycoded domains. I guess the spec could mandate trying
> with punycode first, than Unicode, but that seems needless to me. Do you
> have an example of a system/network that fails on punycode?

mDNS (used in Apple's Bonjour). Despite its name, it has little to do
with DNS, and it requires UTF-8 (and does not use Punycode).

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc6762.txt

From stephane at sources.org  Tue Dec  8 10:37:58 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 8 Dec 2020 11:37:58 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207233751.GN24194@brevard.conman.org>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <20201207233751.GN24194@brevard.conman.org>
Message-ID: <20201208103757.GD11926@sources.org>

On Mon, Dec 07, 2020 at 06:37:51PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 69 lines which said:

> The "horrible added complexity" is not RFC-3987 per se, but the
> "horrible added complexity" of Unicode normalization that is
> required. [...]  Methinks you inadverantly answered your own
> question---Unicode is *not* easy

It would be hard to claim that Unicode is easy :-) But, to be fair,
the complexity is in human scripts (for instance the
lowercase/uppercase difference, which creates a lot of
problems). Unicode just reflects this complexity of human writings.

From stephane at sources.org  Tue Dec  8 10:47:00 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 8 Dec 2020 11:47:00 +0100
Subject: Three possible uses for IRIs
In-Reply-To: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
Message-ID: <20201208104700.GA12575@sources.org>

On Mon, Dec 07, 2020 at 09:37:28PM -0500,
 John Cowan <cowan at ccil.org> wrote 
 a message of 117 lines which said:

> I think there are three possible places where IRIs could possibly appear in
> Gemini:

A fourth one is server configuration. (When you declare the virtual
host, for instance.)

> some best-practice advice about when *n?t* to display an IRI, specifically
> when there are cross-script confusables involved.  For example,
> "gemini://gemini.circumlunar.xn--spce-63d/" should not be displayed as
> "gemini://gemini.circumlunar.sp?ce", because that would be deceptive, even
> in Gemini: you might be pointed to the Evil Version of the Gemini spec and
> not realize it.

As I said, I regard "homograph attacks" as mostly a tale to discourage
people to use Unicode. They are not a real-world problem.


From stephane at sources.org  Tue Dec  8 10:51:06 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 8 Dec 2020 11:51:06 +0100
Subject: Three possible uses for IRIs
In-Reply-To: <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
Message-ID: <20201208105106.GB12575@sources.org>

On Tue, Dec 08, 2020 at 02:47:22AM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 50 lines which said:

> Furthermore, it's breaking change to Gemini. I don't think that's a
> good idea in any case with the possible exception of TLS
> security. Gemini must be reliable, and it's too late for a breaking
> change.

Hold on. I'm a newbie in Gemini and I was under the impression that
Gemini is still experimental and the specification still in flux. If
it is not true, if Gemini is frozen and "take it or leave it", that's
a different matter, and we could save some time by rejecting many
discussions.


From sean at conman.org  Tue Dec  8 11:13:08 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 8 Dec 2020 06:13:08 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <20201208105106.GB12575@sources.org>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
Message-ID: <20201208111308.GR24194@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Tue, Dec 08, 2020 at 02:47:22AM +0000,
>  colecmac at protonmail.com <colecmac at protonmail.com> wrote 
>  a message of 50 lines which said:
> 
> > Furthermore, it's breaking change to Gemini. I don't think that's a
> > good idea in any case with the possible exception of TLS
> > security. Gemini must be reliable, and it's too late for a breaking
> > change.
> 
> Hold on. I'm a newbie in Gemini and I was under the impression that
> Gemini is still experimental and the specification still in flux. If
> it is not true, if Gemini is frozen and "take it or leave it", that's
> a different matter, and we could save some time by rejecting many
> discussions.

  I know Solderpunk wants to do a series of freezes then thaws as things are
worked on, but I think things progress a bit faster than he can deal with,
or wants to deal with, given his long absences on the list.

  For me personally, I think this should be worked out, and I'm working
towards that with my own server [1].  I've had to make changes to
GLV-1.12556 in the past when the protocol changed, I can change it again.

  -spc

[1]	https://github.com/spc476/GLV-1.12556

From linde.philip at gmail.com  Tue Dec  8 11:42:29 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 8 Dec 2020 12:42:29 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201208102924.GB11926@sources.org>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <20201208102924.GB11926@sources.org>
Message-ID: <20201208124229.312ee29c8d190207da4db483@gmail.com>

On Tue, 8 Dec 2020 11:29:24 +0100
Stephane Bortzmeyer <stephane at sources.org> wrote:

> For Python (a common programming language), this is not true, standard
> library's urlparse has no problem:

Similar results in Go:


--- code
package main

import (
	"fmt"
	"net/url"
	"os"
)

func main() {
	for _, arg := range os.Args[1:] {
		u, err := url.Parse(arg)
		if err != nil {
			panic(err)
		}
		fmt.Printf("%q %q %q\n", u.Hostname(), u.Path, u.Query)
	}
}
---

However, this still leaves the problem of punycoding and worse,
normalization, to some other piece of code. In Go, normalization is in
the text package. ToASCII/ToUnicode implementations are in 
golang.org/x/net/idna

Not sure if Python will normalize by default.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/fc404c5c/attachment-0001.sig>

From will at worrbase.com  Tue Dec  8 11:46:47 2020
From: will at worrbase.com (William Orr)
Date: Tue, 08 Dec 2020 12:46:47 +0100
Subject: Three possible uses for IRIs
In-Reply-To: <20201208111128.8c4b52f715d06f7b52de2e30@gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
 <20201208111128.8c4b52f715d06f7b52de2e30@gmail.com>
Message-ID: <87zh2owme0.fsf@locke.worr.haus>


Philip Linde writes:

> On Mon, 07 Dec 2020 20:06:27 -0800
> "Emma Humphries" <ech at emmah.net> wrote:
>
>> I'm perplexed that "ease of programming" is considered more important than "ease of adoption."
>
> Consider "ease of programming" and in particular stability a subset of
> "ease of adoption". There are numerous client and server
> implementations because it is easy to implement, and easy to maintain
> because the protocol is relatively stable even in these early stages.
> The different software allows people with different goals to adopt the
> protocol, and helps in weeding out shortcomings of clarity in the
> specification by analysis of the subtle differences between
> implementations.
>
>> You mention that not every language supports the libraries needed for internationalized URLs. 
>> 
>> What does that lose the project vs. accessibility and broader adoption by non-English-speaking users for who Gemini would be a boon with limited bandwidth and hardware?
>
> It seems more likely that a change to this end would hurt adoption.
> Numerous pieces of existing Gemini software would immediately be
> invalidated. Not all of them will be updated to accommodate the change.
> I could perhaps see a more pressing need for the change if internet
> users worldwide weren't already used to transliteration. It's such a
> small part as well. UTF-8 is acceptable (and default) in text/gemini
> documents, and the text content of a capsule can indeed be written in
> any of the scripts supported by Unicode.

Hey,

I'm new to this list, and a new Gemini user, but this topic is fairly important to me. It's discouraging to see a lot of fear-mongering around this topic already.

Some points that have come up a few times already in this thread as well as the IDN thread that I think are worth addressing:

1. Homograph attacks

Stephane has already mentioned in a different response that homograph attacks are fairly rare. I don't have the knowledge to say whether or not that's accurate, but I can speak to how they're mitigated.

In general, browsers will render the domain in the URI bar if all of the characters in the each section belong to the same script. As an example, https://?pple.com will not render correctly in Firefox in the URI bar, but https://?????.com/ will render correctly (both domains do not exist if you want to check).

The other half of this comes down to domain registrars not allowing registrations of domains with homographs (depends on the TLD, of course).

What this comes down to, is that Gemini clients, if they wish to mitigate this type of attack, should apply the same algorithm as web browsers. Again, given the preference for client certs for authenticating sessions, it doesn't seem like this attack would have dire consequences anyway.

I also think I saw someone mention that they're worried about it from the IRI side as well? That attack doesn't seem like much of a realistic case, since if they direct you to a different page on the same server, you're well, still on the same server. This only becomes problematic in the case of shared hosting of untrusted tenants.

2. Normalization

There's been a bit of fear-mongering about normalization which I can totally understand, since a first look at Unicode technical reports and the 4 normalization forms looks intimidating at first glance.

However, as pointed out in a few RFCs, NFC is more or less the only normalization form that you need to worry about in *most* circumstances. Typed URIs should be normalized in NFC, both on server-side and client-side. When resolving files to the filesystem, the filename should be normalized to NFC. (this all assumes that your fs supports Unicode paths).

NFKC becomes more relevant in the case that you want to implement something like search, or find in page, or something. You may want a user to be able to type in something like 'e' have their find include everything whose NFKC form is basically an 'e' (see the full set here: https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%3ANFKC_Casefold%3De%3A%5D&g=&i=).

3. Language support

Normalization is generally supported across different languages p easily.

Python has it in its stdlib: https://docs.python.org/3/library/unicodedata.html#unicodedata.normalize

Golang has support: https://pkg.go.dev/golang.org/x/text/unicode/norm

Rust: https://unicode-rs.github.io/unicode-normalization/unicode_normalization/index.html

C get its support through the venerable libicu library (you're already using libs for TLS): https://unicode-org.github.io/icu/userguide/transforms/normalization/

I will say that I don't know of any explicit IRI-handling libraries, nor do I know what the state of support is in different URI-handling libraries, but it will be something I play with as I work on gemini projects. I'm happy to share my experiences when I have more of them. :)

-

To address some non-technical points, I don't think that starting a new protocol and then deciding to ignore internationalization is necessarily the right way to go. In a lot of cases, internationalization sucks because of legacy support, and gemini doesn't *have* legacy to preserve compatibility. As I understand it, that's why TLS is mandatory, even though it arguably locks out some retro systems from being able to use it.

Personally, I'd like to see the spec say something about how this is handled before any type of freeze takes place.

--
worr

From bie at 202x.moe  Tue Dec  8 11:49:35 2020
From: bie at 202x.moe (bie)
Date: Tue, 8 Dec 2020 20:49:35 +0900
Subject: Three possible uses for IRIs
In-Reply-To: <20201208111308.GR24194@brevard.conman.org>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org>
Message-ID: <20201208114935.GA47643@202x.moe>

>   I know Solderpunk wants to do a series of freezes then thaws as things are
> worked on, but I think things progress a bit faster than he can deal with,
> or wants to deal with, given his long absences on the list.

I'd love to see a spec freeze, too. There are already a lot of gemini
servers, clients and other tools out there and breaking changes should
be avoided unless absolutely necessary.

>   For me personally, I think this should be worked out, and I'm working
> towards that with my own server [1].  I've had to make changes to
> GLV-1.12556 in the past when the protocol changed, I can change it again.

How about waiting for a consensus to develop, *at the very least*?

If the protocol were to change to allow IRIs, that's a *major breaking* 
change that to me, as someone actually serving non-English content, is
not only completely unnecessary but harmful.

1. I would still have to percent-encode my links to stay compatible with
existing clients.
2. With clients now potentially sending IRIs and not encoded URIs as
requests I would have to change the request handling in my server code
to allow for this, possibly having to add third-party dependencies.
3. I'm still not convinced this would help anyone - IRIs still have
reserved characters that have to be properly encoded - so completely 
non-technical text/gemini authors will still have to rely on proper
tooling.

bie

From easrng at gmail.com  Tue Dec  8 13:17:49 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Tue, 8 Dec 2020 08:17:49 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <97CFBCED-D8E0-4FEB-88BA-43AC57FA5957@gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
 <97CFBCED-D8E0-4FEB-88BA-43AC57FA5957@gmail.com>
Message-ID: <CAEzvDCUKc2_Cm06EPO2hvhrGuB0muKmacmTw2Fd5w6-xz8o58g@mail.gmail.com>

On Tue, Dec 8, 2020 at 5:10 AM Petite Abeille <petite.abeille at gmail.com> wrote:
> Gemini's narrative is build upon the fallacy that everything is "just-oh-so-trivial": any Dick and Jane can fire up the most bare bone of telnet over their trusty dial-up modem and be done. Some sort of citizen-programmer-publisher nirvana, without any barriers to entry whatsoever.
Well, not telnet, because of TLS, but openssl-s_client at least.

From gemini#lists.orbitalfox.eu#v1 at kaction.cc  Tue Dec  8 13:22:20 2020
From: gemini#lists.orbitalfox.eu#v1 at kaction.cc (Dmitry Bogatov)
Date: Tue, 8 Dec 2020 08:22:20 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <87zh2owme0.fsf@locke.worr.haus>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
 <20201208111128.8c4b52f715d06f7b52de2e30@gmail.com>
 <87zh2owme0.fsf@locke.worr.haus>
Message-ID: <20201208132220.GA1375@localhost.fios-router.home>

On Tue, Dec 08, 2020 at 12:46:47PM +0100, William Orr wrote:

> In general, browsers will render the domain in the URI bar if all of
> the characters in the each section belong to the same script. As an
> example, https://?pple.com will not render correctly in Firefox in the
> URI bar, but https://?????.com/ will render correctly (both domains do
> not exist if you want to check).

A lot of extra complexity for very little value.

FWIW, first url you showed looks absolutely the same as legit
"https://apple.com" I typed manually in my vim in TERM=linux.

I came to gemini because for web I, inhabitant of /dev/tty1, is
third-class citizen. Please, don't bring this to Gemini. If "curl
gemini://foo.example/" is not good enough, than your feature is too
complicated.

My native language is Russian (which is not even latin-based), and
goverment website has URL of "https://gosuslugi.ru", and everything
works fine. If you ask me, IRI is a huge mistake.

From petite.abeille at gmail.com  Tue Dec  8 13:26:08 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 8 Dec 2020 14:26:08 +0100
Subject: #gemini logs (was Re: Three possible uses for IRIs)
In-Reply-To: <20201208114935.GA47643@202x.moe>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
Message-ID: <8A020DD6-09B1-46DB-8219-BB8259AD4758@gmail.com>


> On Dec 8, 2020, at 12:49, bie <bie at 202x.moe> wrote:

[2020-12-08T11:31:16.041Z] <bie> fff
[2020-12-08T11:52:29.189Z] <bie> fuck this
[2020-12-08T11:52:32.918Z] <bie> lol
[2020-12-08T11:52:45.090Z] <bie> time to unsubscribe
...

[2020-12-08T12:51:08.517Z] <khuxkm> my favorite was whoever's response to you saying that was "oh we're a frozen spec now?"
[2020-12-08T12:51:16.729Z] <khuxkm> like YES we've been a frozen spec since, like, June
...

[2020-12-08T12:51:45.154Z] <makeworld> khuxkm: I pinged Solderpunk on Masto and he got back to me very quickly saying he had read the IDN thread and was going to come to a decision soon
[2020-12-08T12:51:52.567Z] <makeworld> Yeah lol
[2020-12-08T12:52:08.982Z] <makeworld> I think spc is getting nerd sniped
...

etc, etc, etc...

Certainly you must be aware that the logs from #gemini on tilde.chat are fully accessible to everyone who can be bothered, snarky comments & all. For posterity.

https://portal.mozz.us/gemini/makeworld.gq/cgi-bin/gemini-irc











From petite.abeille at gmail.com  Tue Dec  8 13:36:57 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 8 Dec 2020 14:36:57 +0100
Subject: Three possible uses for IRIs
In-Reply-To: <CAEzvDCUKc2_Cm06EPO2hvhrGuB0muKmacmTw2Fd5w6-xz8o58g@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <945c35b2-be27-4fb0-960a-e8bb936e27eb@www.fastmail.com>
 <97CFBCED-D8E0-4FEB-88BA-43AC57FA5957@gmail.com>
 <CAEzvDCUKc2_Cm06EPO2hvhrGuB0muKmacmTw2Fd5w6-xz8o58g@mail.gmail.com>
Message-ID: <12953DD7-60D2-4604-9479-279228192BCF@gmail.com>



> On Dec 8, 2020, at 14:17, A. E. Spencer-Reed <easrng at gmail.com> wrote:
> 
> Well, not telnet, because of TLS, but openssl-s_client at least.

TLS-based Telnet Security
https://tools.ietf.org/html/draft-ietf-tn3270e-telnet-tls-00

But yes, some sort of TLS layer of one kind or another  :)

From stephane at sources.org  Tue Dec  8 13:36:56 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 8 Dec 2020 14:36:56 +0100
Subject: Crawlers on Gemini and best practices
Message-ID: <20201208133656.GA17700@sources.org>

I just developed a simple crawler for Gemini. Its goal is not to build
another search engine but to perform some surveys of the
geminispace. A typical result will be something like (real data, but
limited in size):

gemini://gemini.bortzmeyer.org/software/crawler/

Currently, I did not yet let it loose on the Internet, because there
are some questions I have.

Is it "good practice" to follow robots.txt? There is no mention of it
in the specification but it could work for Gemini as well as for the
Web and I notice that some programs query this name on my server.

Since Gemini (and rightly so) has no User-Agent, how can a bot
advertise its policy and a point of contact?

From solene at perso.pw  Tue Dec  8 13:58:40 2020
From: solene at perso.pw (Solene Rapenne)
Date: Tue, 8 Dec 2020 14:58:40 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201208133656.GA17700@sources.org>
References: <20201208133656.GA17700@sources.org>
Message-ID: <20201208145840.5738718e@kongroo.lan>

On Tue, 8 Dec 2020 14:36:56 +0100
Stephane Bortzmeyer <stephane at sources.org>:

> I just developed a simple crawler for Gemini. Its goal is not to build
> another search engine but to perform some surveys of the
> geminispace. A typical result will be something like (real data, but
> limited in size):
> 
> gemini://gemini.bortzmeyer.org/software/crawler/
> 
> Currently, I did not yet let it loose on the Internet, because there
> are some questions I have.
> 
> Is it "good practice" to follow robots.txt? There is no mention of it
> in the specification but it could work for Gemini as well as for the
> Web and I notice that some programs query this name on my server.
> 
> Since Gemini (and rightly so) has no User-Agent, how can a bot
> advertise its policy and a point of contact?

depending on what you try, you may add your contact info
in the query.

First contact with a new server before you start crawling you
could get gemini://hostname/CRAWLER_FROM_SOMEONE_AT_HOST_DOT_COM

This is what I do for a gopher connectivity check.

I have to admit, it's a really poor solution but I didn't
find better way.

From petite.abeille at gmail.com  Tue Dec  8 14:05:42 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 8 Dec 2020 15:05:42 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201208145840.5738718e@kongroo.lan>
References: <20201208133656.GA17700@sources.org>
 <20201208145840.5738718e@kongroo.lan>
Message-ID: <67E2BFB7-1D5C-405D-9B31-778E06E91EA8@gmail.com>



> On Dec 8, 2020, at 14:58, Solene Rapenne <solene at perso.pw> wrote:
> 
> depending on what you try, you may add your contact info
> in the query.

Like so?

gemini://example.com/robots.txt?user-agent=DetailsOfTheRobot ?

Previously on the list:

https://lists.orbitalfox.eu/archives/gemini/2020/000511.html

From natpen at natpen.net  Tue Dec  8 14:47:57 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Tue, 8 Dec 2020 09:47:57 -0500
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201208133656.GA17700@sources.org>
References: <20201208133656.GA17700@sources.org>
Message-ID: <X8+SHYMaq2V/625D@goldfish.localdomain>

Yes, you should respect robots.txt in my opinion. It's not compulsory,
but it's currently the best way we have to respect servers' wishes and
bandwidth constraints. There is even a companion spec for doing so,
which accompanies the main Gemini spec.

gemini://gemini.circumlunar.space/docs/companion/robots.gmi

Read the companion spec for more detail, but you're indeed correct
that bots don't advertise who they are since there's no user-agent.
Instead, we have some agreed-upon crawler categories, like
`researcher`, `indexer`, `archiver`. It sounds like you may want to
respect `researcher` and call it a day :)

Nat

On Tue, Dec 08, 2020 at 02:36:56PM +0100, Stephane Bortzmeyer wrote:
> I just developed a simple crawler for Gemini. Its goal is not to build
> another search engine but to perform some surveys of the
> geminispace. A typical result will be something like (real data, but
> limited in size):
>
> gemini://gemini.bortzmeyer.org/software/crawler/
>
> Currently, I did not yet let it loose on the Internet, because there
> are some questions I have.
>
> Is it "good practice" to follow robots.txt? There is no mention of it
> in the specification but it could work for Gemini as well as for the
> Web and I notice that some programs query this name on my server.
>
> Since Gemini (and rightly so) has no User-Agent, how can a bot
> advertise its policy and a point of contact?

From gemini at g-n.site  Tue Dec  8 15:03:46 2020
From: gemini at g-n.site (Simon)
Date: Tue, 8 Dec 2020 16:03:46 +0100
Subject: [ANN] Geminiserver ASM
In-Reply-To: <CAFaUHv+g7y=7nnvvDiFhc_GRaN7+pMDH=PFiG3XXr9wWPVyHrA@mail.gmail.com>
References: <34f72846-8b25-2630-d1a7-2b6b9ef3e9c1@g-n.site>
 <CAFaUHv+g7y=7nnvvDiFhc_GRaN7+pMDH=PFiG3XXr9wWPVyHrA@mail.gmail.com>
Message-ID: <94a6b61f-e3f2-4c6d-7087-e43c2336bfae@g-n.site>


> I'd suggest two things:
>
> * use $-label trick instead of hardcoding string length and
> * a simple way of configuration instead of editing that file: say
> using a symbol that would be defined when assembling like -D
> host=my.host.tld -D port=1955 -D errpath=/error etc.

Thanks for the advises ! The domain, redirection path and max page size 
are now defined with macros :). I've just seen I have forgotten the 
port, I'll do it later.


Cheers,

Simon


From cowan at ccil.org  Tue Dec  8 15:57:33 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 8 Dec 2020 10:57:33 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <20201208114935.GA47643@202x.moe>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org>
 <20201208114935.GA47643@202x.moe>
Message-ID: <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>

On Tue, Dec 8, 2020 at 6:49 AM bie <bie at 202x.moe> wrote:


> If the protocol were to change to allow IRIs, that's a *major breaking*
> change that to me, as someone actually serving non-English content, is
> not only completely unnecessary but harmful.
>

As I said at the beginning of this thread, I don't think anyone is actually
arguing for a change to the protocol.  What does warrant discussion is
allowing IRI references as links in the text/gemini format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/2c557dee/attachment.htm>

From benulo at systemli.org  Tue Dec  8 16:16:25 2020
From: benulo at systemli.org (Ben)
Date: Tue, 8 Dec 2020 19:46:25 +0330
Subject: [ANN] Geminiserver ASM
In-Reply-To: <94a6b61f-e3f2-4c6d-7087-e43c2336bfae@g-n.site>
References: <34f72846-8b25-2630-d1a7-2b6b9ef3e9c1@g-n.site>
 <CAFaUHv+g7y=7nnvvDiFhc_GRaN7+pMDH=PFiG3XXr9wWPVyHrA@mail.gmail.com>
 <94a6b61f-e3f2-4c6d-7087-e43c2336bfae@g-n.site>
Message-ID: <bf324ce6-b883-49ec-2dce-3d4aed165372@systemli.org>

Any chance it will get ported to BSD?

-- 
gemini://kwiecien.us/

From gemini at g-n.site  Tue Dec  8 17:27:34 2020
From: gemini at g-n.site (Simon)
Date: Tue, 8 Dec 2020 18:27:34 +0100
Subject: [ANN] Geminiserver ASM
In-Reply-To: <bf324ce6-b883-49ec-2dce-3d4aed165372@systemli.org>
References: <34f72846-8b25-2630-d1a7-2b6b9ef3e9c1@g-n.site>
 <CAFaUHv+g7y=7nnvvDiFhc_GRaN7+pMDH=PFiG3XXr9wWPVyHrA@mail.gmail.com>
 <94a6b61f-e3f2-4c6d-7087-e43c2336bfae@g-n.site>
 <bf324ce6-b883-49ec-2dce-3d4aed165372@systemli.org>
Message-ID: <7cedd4a9-68fc-1d78-7afd-befdde93a861@g-n.site>


On 12/8/20 5:16 PM, Ben wrote:
> Any chance it will get ported to BSD?
>
If you want to, changing the syscall numbers would probably enough. You 
can find a table here to do the conversion : 
https://www.lurklurk.org/concordance.html

The syscall numbers are the `mov rax, number` and the syscalls used are 
: getpid, socket, setsockopt, bind, listen, accept, fork, getppid, read, 
write, open and exit.

Let us know, or do a PR if you do it :)


From lambdatronic at disroot.org  Tue Dec  8 17:31:16 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Tue, 08 Dec 2020 12:31:16 -0500
Subject: IDN with Gemini?
In-Reply-To: <20201208124229.312ee29c8d190207da4db483@gmail.com>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <20201208102924.GB11926@sources.org>
 <20201208124229.312ee29c8d190207da4db483@gmail.com>
Message-ID: <87pn3kp5ln.fsf@disroot.org>

As yet another data point, Java's standard library contains a class
(java.net.URI) that correctly parses URIs with non-ASCII characters in
their paths and query params, but it chokes when they are in the domain
name.

Therefore, URIs like this should work fine with Space Age:

gemini://gemeaux.bortzmeyer.org:8965/caf??foo?y=bar?y

But this is a non-starter:

gemini://g?meaux.bortzmeyer.org:8965/caf??foo?y=bar?y

It looks like there is an incomplete and poorly documented
implementation of RFC 3987 (IRI) and RFC 3986 (URI) in Apache Jena
(https://jena.apache.org/documentation/notes/iri.html), but it's a
rather heavyweight addition to an otherwise very concise Gemini server.

I'll keep an eye on this thread to see what the community ultimately
decides to do about IRI/IDN.

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From colecmac at protonmail.com  Tue Dec  8 17:55:09 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 17:55:09 +0000
Subject: #gemini logs (was Re: Three possible uses for IRIs)
In-Reply-To: <8A020DD6-09B1-46DB-8219-BB8259AD4758@gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <8A020DD6-09B1-46DB-8219-BB8259AD4758@gmail.com>
Message-ID: <Du1NXkiEBzMpB2v4xzGwbSf1Qx-j7Q3ySrj67-Ss-oKsDHEyXk73JTecGdp9fCYPMbcVi7C_IdI2CZau4pdk7obPQcdOfKXveADpyKsyGxQ=@protonmail.com>

[2020-12-08T15:01:30.527Z] <makeworld> Hello, Petite Abeille. Apparently you're watching the logs, courtesy of my server, so that you can send them back on to the mailing list.
[2020-12-08T15:01:50.519Z] <makeworld> I don't see the point, other than trying to stir the pot. Please stop.
[2020-12-08T15:02:34.637Z] <bie> ?
[2020-12-08T15:02:39.645Z] <makeworld> The fact that this channel is logged is in the topic, it is known. None of the comments you sent were rude, as well.

From colecmac at protonmail.com  Tue Dec  8 18:16:27 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 18:16:27 +0000
Subject: IDN with Gemini?
In-Reply-To: <87pn3kp5ln.fsf@disroot.org>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <20201208102924.GB11926@sources.org>
 <20201208124229.312ee29c8d190207da4db483@gmail.com>
 <87pn3kp5ln.fsf@disroot.org>
Message-ID: <6o3Vr0bEClFLKB0YQOktpUXvgrXkz9EqWzoOkmUfkhRxpPwyk96WcT_26PZPcKXbupCACLDmPLzJoEB8dm6m7HtvtqrqOhIQCPoY40GLTtI=@protonmail.com>

So far Python, Go, and Java libs have been mentioned as sort
of working with IRI.

It's cool the Python and Go ones seem to work, but I wouldn't
trust them, because they aren't intended to support IRIs. The
term IRI appears nowhere in either of their docs, and so there
could easily be subtle bugs. The Java one is literally called
URI, and as Gary Johnson explained, it has issues.

However, these issues are all irrelevant in the face two things:

- This is the IDN thread, there's a separate thread for IRI :)
- IRIs would be a breaking change to Gemini, which is not
   feasible or a good idea.


Cheers,
makeworld

From colecmac at protonmail.com  Tue Dec  8 19:09:18 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 19:09:18 +0000
Subject: Three possible uses for IRIs
In-Reply-To: <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
Message-ID: <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>

On Tuesday, December 8, 2020 10:57 AM, John Cowan <cowan at ccil.org> wrote:

> On Tue, Dec 8, 2020 at 6:49 AM bie <bie at 202x.moe> wrote:
> ?
>
> > If the protocol were to change to allow IRIs, that's a *major breaking*
> > change that to me, as someone actually serving non-English content, is
> > not only completely unnecessary but harmful.
>
> As I said at the beginning of this thread, I don't think anyone is actually
> arguing for a change to the protocol.? What does warrant discussion is
> allowing IRI references as links in the text/gemini format.


I think some people really were calling for a breaking change to the protocol.
But I'm glad you're not, and I hope we can move on and stop talking about it.
What you propose here is allowing IRIs in link lines only? Or do you mean allowing
only IRIs for relative references?

I'm unsure whether that would require an IRI parser or not, but I'd feel more
confident with one. However, there is already a client torture test that *sort of*
covers this. It's not designed as an IRI test, but it includes invalid
characters in a link line.

gemini://gemini.conman.org/test/torture/0031

That page contains a link line that looks like this:

=> <0032> "Beware the bad link"

And the Go stdlib will actually correct this link and output a correct
absolute one. So in Amfora, it will go to the correct URL, which is
gemini://gemini.conman.org/test/torture/%3C0032%3E

I've set up my own test that contains a more complex Unicode character: ?.
It tests the path, as well as Unicode in the query strings.
You can access it at: gemini://makeworld.gq/test/iri-link.gmi

Go also corrects the link in that one, and it works. Allowing IRIs in link
lines (maybe only for relative links to ease parsing) would solve all
multi-lingual author problems.

But this is still a somewhat-breaking change, as once authors start using
these, other non-Go clients will likely begin to fail. And the correction
that Go does is not even complete, because it will not work on query strings.
And even if it did, it would not work in the Gemini way that doesn't allow
pluses, etc etc.

We're almost there with this one, but I still think it's a mistake, and it'll
make Gemini more complex. :/


makeworld

From petite.abeille at gmail.com  Tue Dec  8 19:59:21 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 8 Dec 2020 20:59:21 +0100
Subject: #gemini logs (was Re: Three possible uses for IRIs)
In-Reply-To: <Du1NXkiEBzMpB2v4xzGwbSf1Qx-j7Q3ySrj67-Ss-oKsDHEyXk73JTecGdp9fCYPMbcVi7C_IdI2CZau4pdk7obPQcdOfKXveADpyKsyGxQ=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <8A020DD6-09B1-46DB-8219-BB8259AD4758@gmail.com>
 <Du1NXkiEBzMpB2v4xzGwbSf1Qx-j7Q3ySrj67-Ss-oKsDHEyXk73JTecGdp9fCYPMbcVi7C_IdI2CZau4pdk7obPQcdOfKXveADpyKsyGxQ=@protonmail.com>
Message-ID: <56B44385-A1FB-4BFA-BAB5-7D0938BE8EEF@gmail.com>



> On Dec 8, 2020, at 18:55, colecmac at protonmail.com wrote:
> 
> [2020-12-08T15:01:50.519Z] <makeworld> I don't see the point, other than trying to stir the pot. Please stop.
> [2020-12-08T15:02:39.645Z] <makeworld> The fact that this channel is logged is in the topic, it is known. None of the comments you sent were rude, as well.

Did I touch a nerve? Apologies. Back to our regular program then.


From cowan at ccil.org  Tue Dec  8 20:30:10 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 8 Dec 2020 15:30:10 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org>
 <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
Message-ID: <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>

On Tue, Dec 8, 2020 at 2:09 PM <colecmac at protonmail.com> wrote:


> I think some people really were calling for a breaking change to the
> protocol.
> But I'm glad you're not, and I hope we can move on and stop talking about
> it.
> What you propose here is allowing IRIs in link lines only?


Yes.

> Or do you mean allowing
> only IRIs for relative references?
>

No.

> I'm unsure whether that would require an IRI parser or not,


It will not, because conversion can be done before parsing, other than the
trivial parsing required to find the hostname and punycode it.  Once that
is done, converting an IRI reference to a URI reference is as
straightforward as transcoding from one character set to another, and
totally indifferent to the IRI format.  So my two steps for IRI->URI
conversion become three:

1)  NFC normalization.

2) Punycode conversion of the hostname.

3) Percent-encoding: find non-ASCII characters and convert them to %nn%nn,
or %nn%nn%nn, or %nn%nn%nn%nn sequences, where nn is two hex digits.

It turns out that all of this is spelled out in more detail at <
https://tools.ietf.org/html/rfc3987#section-3.1>.  That section says not to
normalize unless you have the IRI in non-digital or non-UTF* format, but
since the world is not full of editors that normalize, I think Gemini
clients need to do it themselves.   That said, most keyboard drivers (even
for hard cases like Vietnamese, which has way too many vowels to dedicate a
key to each) now deliver normalized text to applications.

It's good to know that some existing URI libraries support IRIs, but that
section should be convincing evidence that you can change an IRI to a URI
without parsing it (always excepting the domain name, which is trivial to
find).

But this is still a somewhat-breaking change, as once authors start using
> these, other non-Go clients will likely begin to fail. And the correction
> that Go does is not even complete, because it will not work on query
> strings.
> And even if it did, it would not work in the Gemini way that doesn't allow
> pluses, etc etc.
>

The above transformation will work, however.  Sometimes DIY is the Right
Thing.

> We're almost there with this one, but I still think it's a mistake, and
> it'll
> make Gemini more complex. :/
>

It will.  But in the end, if Gemini succeeds even modestly there will be
more authors than programmers.

[*] 72 lower-case vowel letters: 6 vowels without diacritics plus 6 vowels
with vowel-quality diacritics, as in French, times 6 tone marks (one of
which is "no mark") as in Chinese.  And the same number in upper case.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
It's like if you meet an really old, really rich guy covered in liver
spots and breathing with an oxygen tank, and you say, "I want to be
rich, too, so I'm going to start walking with a cane and I'm going to
act crotchety and I'm going to get liver disease. --Wil Shipley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/6720d39c/attachment.htm>

From colecmac at protonmail.com  Tue Dec  8 20:43:54 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 20:43:54 +0000
Subject: Small spec change required by RFC for lang params
In-Reply-To: <j1Z3z1j0QYKv0_UD8zlxxLtUpMoFQj0M8ypAvFnCYoiWdY50qAmQeaNr19p0iC48VYbejoo-YNkhMP_SawrDEkxyI7T2f83zjwB9jJ26G0g=@protonmail.com>
References: <j1Z3z1j0QYKv0_UD8zlxxLtUpMoFQj0M8ypAvFnCYoiWdY50qAmQeaNr19p0iC48VYbejoo-YNkhMP_SawrDEkxyI7T2f83zjwB9jJ26G0g=@protonmail.com>
Message-ID: <XxWn825VvjL1YLm_j4nTGVGPsnYOBO9lT_wkE2xmMr3FUbVY8sdRkWROCaeV079kxi0v8wA_rMd3v-VKIsbIGZhrnAVGHcJJ9qs-DUWuiGQ=@protonmail.com>

I found another small error in this section, might as well put it here.

It says:

> Valid values for the "lang" parameter are comma-separated lists of one
> or more language tags as defined in RFC4646.

But RFC4646[1] is obsoleted by RFC5646, which is more commonly known as
BCP47[2]. The spec should be updated to reflect this, saying:

> Valid values for the "lang" parameter are comma-separated lists of one
> or more language tags as defined in BCP47.

It would be nice if it linked to BCP47 as well.

1: https://tools.ietf.org/html/rfc4646
2: https://tools.ietf.org/html/bcp47


Thanks,
makeworld

From colecmac at protonmail.com  Tue Dec  8 21:09:58 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 21:09:58 +0000
Subject: Three possible uses for IRIs
In-Reply-To: <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
 <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
Message-ID: <7gHr7A3tbjpjqXBYkkFu8_sauc8YJq7GP-zF-kiQ0Y3CFwtAKm3J4vDP34GoUAe3FOHqrep4qHDfWBx6SVnwqbP5bCyso4ku3ojFdCf-FgE=@protonmail.com>

> > We're almost there with this one, but I still think it's a mistake, and it'll
> > make Gemini more complex. :/
>
> It will.  But in the end, if Gemini succeeds even modestly there will be more
> authors than programmers.

This is the point that sticks out to me. Perhaps I was wrong.

The method you outlined does not seem that complex, and it really would benefit
authors. It's still a breaking change, but all existing links would still work.

The most difficult part of what you outlined is the Unicode normalization,
which maybe not all languages have libraries for, and would also require
updating every so often. But it wouldn't be a requirement for clients at all,
just something nice to have.

However, it does raise a few questions:

I assume you mean NFC normalization? Any other option seems nonsensical to me,
but I'm also new to this in general. Would be happy to be corrected.

What if the user named a domain/file/folder in a non-NFC way? Now does the server
need to support NFC as well, and apply it to vhost recognition or local file paths
to correctly match requests? That seems wrong. But so does the user entering
something visually identical to what the the the sysadmin typed, and things not
working.

I'm not keen to muddle up the threads again, but it seems like this proposal
completely covers IDNs as well, which is handy.

Overall, I like it. The biggest thing holding me back is the fact that it will
break clients, over time. But perhaps that's worth it for the ease-of-writing
gain for non-English speakers.

I wouldn't mind updating Amfora to support this. As I explained in my previous email,
it sort of already does this by accident.


Cheers,
makeworld

From sean at conman.org  Tue Dec  8 21:20:04 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 8 Dec 2020 16:20:04 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
Message-ID: <20201208212004.GS24194@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> 
> I'm unsure whether that would require an IRI parser or not, but I'd feel more
> confident with one. However, there is already a client torture test that *sort of*
> covers this. It's not designed as an IRI test, but it includes invalid
> characters in a link line.
> 
> gemini://gemini.conman.org/test/torture/0031
> 
> That page contains a link line that looks like this:
> 
> => <0032> "Beware the bad link"
> 
> And the Go stdlib will actually correct this link and output a correct
> absolute one. So in Amfora, it will go to the correct URL, which is
> gemini://gemini.conman.org/test/torture/%3C0032%3E

  What you failed to quote from that test is:

	I'm not entirely sure what the proper response should be ...

  And it was a last minute thing to add the link to %3C0032%3E---I was
thinking it was more of an Easter Egg type of thing than what the actual
result should be.  

> I've set up my own test that contains a more complex Unicode character: ?.
> It tests the path, as well as Unicode in the query strings.
> You can access it at: gemini://makeworld.gq/test/iri-link.gmi

  I tried both the Gemini Client Torture Test 31, and your link with the
Gemini portal at portal.mozz.us.  The results were interesting.  If failed
the Gemini Client Torture Test, but loaded the page with the Unicode
character on your site.  So at least it supports percent encoding of
characters outside the ASCII range.

  -spc (So that's one more data point ... )


From sean at conman.org  Tue Dec  8 21:33:58 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 8 Dec 2020 16:33:58 -0500
Subject: #gemini logs (was Re: Three possible uses for IRIs)
In-Reply-To: <8A020DD6-09B1-46DB-8219-BB8259AD4758@gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <8A020DD6-09B1-46DB-8219-BB8259AD4758@gmail.com>
Message-ID: <20201208213358.GT24194@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> [2020-12-08T12:52:08.982Z] <makeworld> I think spc is getting nerd sniped

  I don't know if I'm being nerd sniped or not, but I do think this has
brought to my attention some encoding bugs I have---namely, I don't encode
data with non-US-ASCII characters.  Fixing bugs is always A Good Thing (TM). 
I'm also looking into just how hard it would be to support IRIs.  Except for
the normalization thing, it looks to be fairly straightforward, but I
haven't worked on it that much yet.  I've already had my preconceived
notions of DNS blown out of the water over this thread (and I've implemented
a DNS library [1] so that's saying something).

  -spc (What it says, I don't know)

[1]	https://github.com/spc476/SPCDNS

From colecmac at protonmail.com  Tue Dec  8 21:42:54 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 21:42:54 +0000
Subject: Three possible uses for IRIs
In-Reply-To: <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
 <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
Message-ID: <pdPeB_0Sd49FtPyCTC-T_wpJ4pH6dJ2GGJHy3-HtyUjuic9QlxLqbLs8dR2c88ufC3JI2CrUIlWHDHoGhE1BJoDKs1R7ievvnOicaLX7ScA=@protonmail.com>

> 3) Percent-encoding: find non-ASCII characters and convert them to %nn%nn,
> or %nn%nn%nn, or %nn%nn%nn%nn sequences, where nn is two hex digits.

One extra thing: Gemini will need it's own list of reserved characters.
The URI spec defines[1] this list:

gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"


(It also defines a list called sub-delims, but that only applies to query
strings I believe, and is irrelevant to the way Gemini uses them.)

These characters are reserved because of their use in other parts of
a URI. But Gemini does not use all those parts, such as userinfo. I
believe a reserved character list for Gemini could look like this:

":" / "/" / "#" / "?" / "[" / "]"

I left fragments ("#") in, so that clients can add support for them later,
if/when a header-to-fragment algorithm is defined, like exists for Markdown.
But that character could be removed too, which would prevent it ever being
used in that manner.

1: https://tools.ietf.org/html/rfc3986#section-2.2


makeworld

From cowan at ccil.org  Tue Dec  8 21:45:57 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 8 Dec 2020 16:45:57 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <7gHr7A3tbjpjqXBYkkFu8_sauc8YJq7GP-zF-kiQ0Y3CFwtAKm3J4vDP34GoUAe3FOHqrep4qHDfWBx6SVnwqbP5bCyso4ku3ojFdCf-FgE=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org>
 <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
 <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
 <7gHr7A3tbjpjqXBYkkFu8_sauc8YJq7GP-zF-kiQ0Y3CFwtAKm3J4vDP34GoUAe3FOHqrep4qHDfWBx6SVnwqbP5bCyso4ku3ojFdCf-FgE=@protonmail.com>
Message-ID: <CAD2gp_TbhcHxaf1r21YHgDnpfApPLwT95k1yLQPP+r597fF2_A@mail.gmail.com>

On Tue, Dec 8, 2020 at 4:10 PM <colecmac at protonmail.com> wrote:


> The most difficult part of what you outlined is the Unicode normalization,
> which maybe not all languages have libraries for, and would also require
> updating every so often. But it wouldn't be a requirement for clients at
> all,
> just something nice to have.
>

If a client has an unnormalized IRI, it needs to normalize it before
sending it to the server.  That said, a 2009 study looked at a sample of
700 million HTML documents, of which only 0.02% were not in NFC already,
which suggests that NFC text is already pretty dominant.

I assume you mean NFC normalization?
>

Yes.  When I speak of normalization, I mean NFC normalization exclusively.

> What if the user named a domain/file/folder in a non-NFC way? Now does the
> server
> need to support NFC as well, and apply it to vhost recognition or local
> file paths
> to correctly match requests? That seems wrong. But so does the user
> entering
> something visually identical to what the sysadmin typed, and things not
> working.
>

I'm okay with that just failing, as file names are not really part of
text/gemini content.  The difference will be obvious to the admin by
checking the requested URIs from the server log against the %-encoded names
of the folders.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
                I am a member of a civilization. --David Brin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/6b45b640/attachment.htm>

From cowan at ccil.org  Tue Dec  8 21:52:38 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 8 Dec 2020 16:52:38 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <pdPeB_0Sd49FtPyCTC-T_wpJ4pH6dJ2GGJHy3-HtyUjuic9QlxLqbLs8dR2c88ufC3JI2CrUIlWHDHoGhE1BJoDKs1R7ievvnOicaLX7ScA=@protonmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org>
 <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
 <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
 <pdPeB_0Sd49FtPyCTC-T_wpJ4pH6dJ2GGJHy3-HtyUjuic9QlxLqbLs8dR2c88ufC3JI2CrUIlWHDHoGhE1BJoDKs1R7ievvnOicaLX7ScA=@protonmail.com>
Message-ID: <CAD2gp_Q2cGT1pTerB+nO+r2z+a_jSti1MngJv6V_1VgfNpmUdA@mail.gmail.com>

On Tue, Dec 8, 2020 at 4:42 PM <colecmac at protonmail.com> wrote:


> (It also defines a list called sub-delims, but that only applies to query
> strings I believe, and is irrelevant to the way Gemini uses them.)
>

Gemini query strings can certainly be formatted like Web query strings if
the client knows that's what the server expects.  Simple free text isn't
the only possibility.  I'm going to talk about that in a posting at some
point.

These characters are reserved because of their use in other parts of
> a URI. But Gemini does not use all those parts, such as userinfo. I
> believe a reserved character list for Gemini could look like this:
>
> ":" / "/" / "#" / "?" / "[" / "]"
>

We still need the square brackets for the rare case when the host-part is
an IPv6 address.  The only character we could leave out with complete
safety is @, and I don't think that's worth special-casing for Gemini.
It's simpler and better to have the same rules for all URIs.

> I left fragments ("#") in, so that clients can add support for them later,
> if/when a header-to-fragment algorithm is defined, like exists for
> Markdown.
>

+1 to leaving # reserved, not only for that reason but for the same reason
as @; it's not worth making a special rule for Gemini to avoid a trivial
amount of %-encoding, especially given that most file names don't have
either one in their names.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
weirdo:    When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/47393bea/attachment.htm>

From colecmac at protonmail.com  Tue Dec  8 21:56:57 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 08 Dec 2020 21:56:57 +0000
Subject: Three possible uses for IRIs
In-Reply-To: <CAD2gp_TbhcHxaf1r21YHgDnpfApPLwT95k1yLQPP+r597fF2_A@mail.gmail.com>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
 <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
 <7gHr7A3tbjpjqXBYkkFu8_sauc8YJq7GP-zF-kiQ0Y3CFwtAKm3J4vDP34GoUAe3FOHqrep4qHDfWBx6SVnwqbP5bCyso4ku3ojFdCf-FgE=@protonmail.com>
 <CAD2gp_TbhcHxaf1r21YHgDnpfApPLwT95k1yLQPP+r597fF2_A@mail.gmail.com>
Message-ID: <IdNipzIlMuD9MeFCzj7fCU2NF3ijC2ygMHJ7KOOWnhu7Pb6-RkEWcwPQlbZBkbuPyLGGXJuWcSwIjojR2KZFJ4TuTVHRVxgRBXGlzrL0szg=@protonmail.com>

> > The most difficult part of what you outlined is the Unicode normalization,
> > which maybe not all languages have libraries for, and would also require
> > updating every so often. But it wouldn't be a requirement for clients at all,
> > just something nice to have.
>
> If a client has an unnormalized IRI, it needs to normalize it before sending
> it to the server.

Could you justify this? It's a good thing to have, but it feels like a big ask,
as Unicode support and especially things like normalization are not straightforward
in all languages. I don't see why it can't just be recommended and not required.

> > I assume you mean NFC normalization?
>
> Yes.? When I speak of normalization, I mean NFC normalization exclusively.

Sounds good!

> > What if the user named a domain/file/folder in a non-NFC way? Now does the server
> > need to support NFC as well, and apply it to vhost recognition or local file paths
> > to correctly match requests? That seems wrong. But so does the user entering
> > something visually identical to what the sysadmin typed, and things not
> > working.
>
> I'm okay with that just failing, as file names are not really part of text/gemini
> content.? The difference will be obvious to the admin by checking the requested
> URIs from the server log against the %-encoded names of the folders.

The issue is that admins are not the only ones who create folders and files.
Non-technical people will as well, and a bug like this will be very confusing.
Everything will look right, but it just won't work. However, I doubt this will
occur very often, and it's an acceptable tradeoff to supporting Unicode.


makeworld

From sean at conman.org  Tue Dec  8 22:13:19 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 8 Dec 2020 17:13:19 -0500
Subject: IDN with Gemini?
In-Reply-To: <20201208102744.GA11926@sources.org>
References: <20201207123041.GA17160@localhost.localdomain>
 <C7MR5KNJX2EY.3UMY8TWYZHWDX@nitro>
 <20201208011807.2907c25c7f0cf93db12ad837@gmail.com>
 <20201208102744.GA11926@sources.org>
Message-ID: <20201208221319.GU24194@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Tue, Dec 08, 2020 at 01:18:07AM +0100,
>  Philip Linde <linde.philip at gmail.com> wrote 
>  a message of 69 lines which said:
> 
> > homograph attacks
> 
> Homograph attacks are basically a good way to make an english-speaking
> audience laugh when you show them funny Unicode problems (I've seen
> that several times in several meetings: the languages and scripts of
> other people are always funny). No bad guy use them in real life,
> probably because users typically never check the URI or IRI.

  True, there's no need currently for homograph attacks if other, simpler
means are available.

> And they exist with ASCII, too (goog1e.com...)

  True.  But a more concerning attack is bitsquatting [1], a much harder
attack to thwart.  Is it widely used?  Hard to say actually.

> > Some browsers deal with homograph attacks by displaying punycode
> > directly based on some basic heuristic (e.g. when a hostname
> > contains both cyrillic and latin codes).
> 
> Which is awful for the UX. Note that such mangling is never done for
> ASCII, which clearly shows a provincial bias toward english.
> 
> > Octet encoded ASCII does have the nice property that there are no
> > homographs, there's no normalization,
> 
> This is not true. Since percent-encoding encodes bytes, there are
> still several ways to represent "the same" string of characters and
> therefore normalization remains an issue.

  Yes, but by "normalization" they mean precomosed characters (like
"\u{00E9}") vs. combining characters (like "e\u{0301}"), along with the
ordering of consecutive combining characters.

> > RFC 4690 is a good read on the topic of IDNs.
> 
> No, it is a one-sided anti-internationalization rant.

  Aside from the "internationalization is hard", what's so bad about the
document?  Remember, they *are* (or *were*) trying to retrofit
internationalization into protocols that were never designed for it.

  -spc

[1]	http://www.dinaburg.org/bitsquatting.html

From sean at conman.org  Tue Dec  8 22:20:38 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 8 Dec 2020 17:20:38 -0500
Subject: IDN with Gemini?
In-Reply-To: <20201208103208.GC11926@sources.org>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
 <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
 <20201208103208.GC11926@sources.org>
Message-ID: <20201208222038.GV24194@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Mon, Dec 07, 2020 at 09:46:06PM +0000,
>  colecmac at protonmail.com <colecmac at protonmail.com> wrote 
>  a message of 49 lines which said:
> 
> > Despite what this RFC says, I don't see what situation would actually
> > completely fail on punycoded domains. I guess the spec could mandate trying
> > with punycode first, than Unicode, but that seems needless to me. Do you
> > have an example of a system/network that fails on punycode?
> 
> mDNS (used in Apple's Bonjour). Despite its name, it has little to do
> with DNS, and it requires UTF-8 (and does not use Punycode).

  I was curious about this, having written a DNS library [1].  Saying it has
nothing to do with DNS while being called "Multicast DNS", using the same
encoding scheme as DNS, and covers a portion of the DNS namespace, saying it
has "little to do with DNS" is a bit uncharitable (in my opinion).  It *is*
DNS, over UDP---it just uses a special IP address and different port.

  I was also surprised that UTF-8 characters *are* possible in DNS packets
[2].  I was, however, a bit disappointed that "g?meaux.bortzmeyer.org" and
"xn--gmeaux-bva.bortzmeyer.org" didn't exist.

  -spc

[1]	https://github.com/spc476/SPCDNS

[2]	And I was happy to see my library could successfully deal with such,
	even as I wasn't conseciously aware of doing so.

From sean at conman.org  Wed Dec  9 00:19:48 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 8 Dec 2020 19:19:48 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <20201208114935.GA47643@202x.moe>
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org> <20201208114935.GA47643@202x.moe>
Message-ID: <20201209001948.GX24194@brevard.conman.org>

It was thus said that the Great bie once stated:
> >   I know Solderpunk wants to do a series of freezes then thaws as things are
> > worked on, but I think things progress a bit faster than he can deal with,
> > or wants to deal with, given his long absences on the list.
> 
> I'd love to see a spec freeze, too. There are already a lot of gemini
> servers, clients and other tools out there and breaking changes should
> be avoided unless absolutely necessary.
> 
> >   For me personally, I think this should be worked out, and I'm working
> > towards that with my own server [1].  I've had to make changes to
> > GLV-1.12556 in the past when the protocol changed, I can change it again.
> 
> How about waiting for a consensus to develop, *at the very least*?

  If I waited for consensus, Gemini would not be where it is today [1].
Also, it brought out a what I consider a bug in my code (generating links
from filenames) that it doesn't properly URL encode data [2].

> If the protocol were to change to allow IRIs, that's a *major breaking* 
> change that to me, as someone actually serving non-English content, is
> not only completely unnecessary but harmful.

  I don't expect that an IRI will be allowed for a request, but that an IRI
could be in a Gemini text file and it's up to the client to do the
conversion.  And it's that bit that I'm currently exploring.  

> 3. I'm still not convinced this would help anyone - IRIs still have
> reserved characters that have to be properly encoded - so completely 
> non-technical text/gemini authors will still have to rely on proper
> tooling.

  And we won't know until somebody tries.

  -spc

[1]	There's a reason why GLV-1.12556 and gemini.conman.org were the
	first Gemini server software and server in existance, becauxe I just
	went ahead and implemented it while solderpunk was still talking
	about it.  And I think the presense of GLV-1.12556 and
	gemini.conman.org sparked others to get busy.  And GLV-1.12556 was
	*NOT* following the specification at the time, as I disagreed with
	parts of the specification.

[2]	I don't have any non-ASCII file names, so it never crossed my mind
	to handle such things.  That is a blind spot as far as I'm
	concerned.

From jmcbray at carcosa.net  Wed Dec  9 02:02:57 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 08 Dec 2020 21:02:57 -0500
Subject: Three possible uses for IRIs
In-Reply-To: <IdNipzIlMuD9MeFCzj7fCU2NF3ijC2ygMHJ7KOOWnhu7Pb6-RkEWcwPQlbZBkbuPyLGGXJuWcSwIjojR2KZFJ4TuTVHRVxgRBXGlzrL0szg=@protonmail.com>
 (colecmac@protonmail.com's message of "Tue, 08 Dec 2020 21:56:57 +0000")
References: <CAD2gp_TtBMWDkoPT-dd+GR8Sga0L9xGbtgnrUyu=wj1Tg4A8Eg@mail.gmail.com>
 <vFMTQmjQK-noG5xFb3kzWBvY7qwuA3fxT9X5SjpbracBlxQlsSFzHc_WVRpESBtQRcERS9ZC2hAAwU6GZb2KHEKjAKXEccmduSJ6DI3Gorg=@protonmail.com>
 <20201208105106.GB12575@sources.org>
 <20201208111308.GR24194@brevard.conman.org>
 <20201208114935.GA47643@202x.moe>
 <CAD2gp_T3YQVzB5-H2RcwDL9U8MAJ2soYc0bbGPAq3gJ559765Q@mail.gmail.com>
 <-3t12qvMLwAVPFhWjhGXG6gSivbaSJzluBlXXhOalSm5y4XW3S1zGdt--PcMNZHmLHB6txbcvyJcEtQkpGC4xSxCHIQYZ1ynhnOS8UXYZzo=@protonmail.com>
 <CAD2gp_Ti=yKG7VOBi2M5Y-OE1QX=ug0LWMEsBzGOVLe6R4MMkA@mail.gmail.com>
 <7gHr7A3tbjpjqXBYkkFu8_sauc8YJq7GP-zF-kiQ0Y3CFwtAKm3J4vDP34GoUAe3FOHqrep4qHDfWBx6SVnwqbP5bCyso4ku3ojFdCf-FgE=@protonmail.com>
 <CAD2gp_TbhcHxaf1r21YHgDnpfApPLwT95k1yLQPP+r597fF2_A@mail.gmail.com>
 <IdNipzIlMuD9MeFCzj7fCU2NF3ijC2ygMHJ7KOOWnhu7Pb6-RkEWcwPQlbZBkbuPyLGGXJuWcSwIjojR2KZFJ4TuTVHRVxgRBXGlzrL0szg=@protonmail.com>
Message-ID: <87im9bu46m.fsf@dorothy.carcosa.net>

colecmac at protonmail.com writes:

> The issue is that admins are not the only ones who create folders and files.
> Non-technical people will as well, and a bug like this will be very confusing.
> Everything will look right, but it just won't work. However, I doubt this will
> occur very often, and it's an acceptable tradeoff to supporting Unicode.

It's arguably worse than that; consider the case where your filesystem
doesn't store filenames in UTF-8 ? notably Windows stores them in UCS2.
If you're treating filenames as Unicode strings and not byte arrays, and
your language provides good abstractions for that, you're okay, but the
upshot is that both the client and the server really do need to be
Unicode aware.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From jmcbray at carcosa.net  Wed Dec  9 02:49:50 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 08 Dec 2020 21:49:50 -0500
Subject: Some reading on IRIs and IDNs
Message-ID: <87blf3u20h.fsf@dorothy.carcosa.net>

Hi, all. The discussion on IRIs and IDNs is a little intense, and I
thought I would take a step back and do some reading on it. I'm not
monolingual, but I am ISO-8859-1-lingual, if that makes sense, so some
of the issues are new to me.

So, there's an overview of all the issues involved here:
https://www.w3.org/International/articles/idn-and-iri/. This article
(from 2008) goes over the things you need to do to implement support for
IRIs, without going too much into the technical details. It makes things
look pretty straightforward and cut-and-dried, but...

In terms of actual standardization, things are kind of a mess. See this
page: https://www.w3.org/International/wiki/IRIStatus. This page brings
up the real issues with the standard.

It seems like the effort to standardize IRIs in the same framework as
URLs, URNs, and URIs fell apart in 2014. The effort was picked up by the
HTML5 WHATWG, which has their own "living standard" called URL:
http://url.spec.whatwg.org/. The URL standard focuses somewhat on
parsing/processing/serializing international URLs, which is useful to
us, but it is also *extremely* WWW-centric. It doesn't really take into
account non-HTTP(S) URLs, especially ones that are not very web-like,
like mailto or schemes where the authority field is not a domain name. 
Much of the spec focuses on things like how a web browser should
represent URLs in the address bar and in text.

This *probably* contributes to the lack of IRI-parsing libraries for
various languages: there's no standard for them to implement!

Given all that... maybe we should just consider our use cases and see
what the minimum we have to do is?

As I see it, the main requirement is that authors want to be able to use
non-ASCII characters in both the domain part and the path part of the
links in their documents, and have that work with no problems. IMO this
is a *reasonable expectation* for a retrofuturistic protocol like
Gemini.

Now, what does that require of client authors and server authors?

What is the *absolute minimum* we can require of client and server
authors and have things work?

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From sean at conman.org  Wed Dec  9 05:26:51 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 9 Dec 2020 00:26:51 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87blf3u20h.fsf@dorothy.carcosa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
Message-ID: <20201209052651.GY24194@brevard.conman.org>

It was thus said that the Great Jason McBrayer once stated:
>   
> Now, what does that require of client authors and server authors?
> 
> What is the *absolute minimum* we can require of client and server
> authors and have things work?

  As I've stated, I've created an IRI parser per RFC-3987 [1] and it was a
very minimal change to my original URL parser per RFC-3986 [2].  Basically,
it allows any UTF-8 character past codepoint 128 to used, as is in the IRI. 
Languages that have URL parsers may or may not support UTF-8 data.  So IRI
parsing may or may not be an issue (aside from Unicode normalization) on a
per-language basis.

  I've also started down the punycode rabit hole.  As Stephane has stated,
DNS *can* support UTF-8, but such support isn't wide, nor is it a standard. 
Punycode was developed to encode UTF-8 with ASCII in a most Byzantine way. 
It does have an RFC (RFC-3492) and said RFC does contain code for encoding
and decoding punycode (but it's in C, and the API is ... not what I would
define but it can be worked with).  IDN support, from my experience over the
past two days, is *harder* than IRI, although the concern was mostly the
other way.  I haven't actually *gotten* to the part of converting a domain
name to punycode but in general, to convert a domain name:

	for each label [3]:
		if label has non-ASCII characters
			convert to punycode, prepend "xn--" to result

so a domain name like "??.english.s?d?r.???" is converted thusly:

	?? 	-> 99zt52a -> xn--99zt52a
	english	-> (no conversion required)
	s?d?r 	-> sdr-rlad -> xn--sdr-rlad

	???

		-> wgbh1c -> xn--wgbh1c

to become "xn--99zt52a.english.xn--sdr-rlad.xn--wgbh1c" (and that last
segment is giving my editor fits because it's right-to-left).  The example
is extreme but it's just there to serve as an example of how to go about it.

  So given my experiences so far, I would say the easiest way to deal with
all this is to make it a client issue.  Hold off on IDN support for now (see
below for some more questions about it), but UTF-8 in the path and query
should be allowed in text/gemini, but encoded before making a request.  A
client, given a link like:

=> gemini://gemini.bortzmeyer.org:8965/caf??foo=bar Order from the Caf?

should be able to parse it with the UTF-8 characters, but convert it to:

	gemini://gemini.bortzmeyer.org:8965/caf%C3%A9?foo=bar

before making the request.  At the very least, tools could be developed to
encode links in text/gemini before publishing them if no one wants the spec
to change at all.  

I feel that would be the easiest, less breaking, thing to do now.  Making
IDN (punycode) mandatory might require a bit more discussion as I'm not sure
of the language support.  I'm not even sure what name should be in a
certificate for an IDN---the full UTF-8 version, or the punycode version, or
both?  What's currently done in HTTP land about this? (answering this will
at least point in a direction, even if we don't want to go that direction).

  -spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/iri.lua

[2]	https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

[3]	The domain name "gemini.conman.org" has three labels, "gemini",
	"conman" and "org".  The term "label" is DNS lingo.

From stephane at sources.org  Wed Dec  9 08:12:20 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 9 Dec 2020 09:12:20 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201208222038.GV24194@brevard.conman.org>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
 <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
 <20201208103208.GC11926@sources.org>
 <20201208222038.GV24194@brevard.conman.org>
Message-ID: <20201209081219.GA14045@sources.org>

On Tue, Dec 08, 2020 at 05:20:38PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 29 lines which said:

>   I was also surprised that UTF-8 characters *are* possible in DNS packets
> [2].

It is possible from the beginning, and it has been explicitely said in
RFC 2181, twenty-three years ago. "any binary string whatever can be
used as the label of any resource record".

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc2181.txt

> I was, however, a bit disappointed that "g?meaux.bortzmeyer.org" and
> "xn--gmeaux-bva.bortzmeyer.org" didn't exist.

Then it means your DNS resolver is broken because
xn--gmeaux-bva.bortzmeyer.org (the A-label, the Punycode form) is in
the DNS.

% dig AAAA +noidnout xn--gmeaux-bva.bortzmeyer.org  

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> AAAA +noidnout xn--gmeaux-bva.bortzmeyer.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18694
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 7, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;xn--gmeaux-bva.bortzmeyer.org. IN AAAA

;; ANSWER SECTION:
xn--gmeaux-bva.bortzmeyer.org. 86400 IN	CNAME radia.bortzmeyer.org.
xn--gmeaux-bva.bortzmeyer.org. 86400 IN	RRSIG CNAME 8 3 86400 (
				20201218215750 20201204120249 10731 bortzmeyer.org.
				gKtCZZKsjTLdFsSKYtgvz1S+pRkZbxweG+6XOxVhJgYG
				gRzfWB8lhjSPaQ6BNK6YyGQreonObF1R43MDY5oQ66ti
				hNOfPp3/gz4wm5eAy3uzFi7xiwclshsLd0yZEaOPsTo6
				fYKfRp5XCG/yZOg85YdZxJB9LK9q+RIyOycGmI0= )
radia.bortzmeyer.org.	86400 IN AAAA 2001:41d0:302:2200::180
...

From stephane at sources.org  Wed Dec  9 08:13:40 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 9 Dec 2020 09:13:40 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87blf3u20h.fsf@dorothy.carcosa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
Message-ID: <20201209081339.GB14045@sources.org>

On Tue, Dec 08, 2020 at 09:49:50PM -0500,
 Jason McBrayer <jmcbray at carcosa.net> wrote 
 a message of 48 lines which said:

[Thanks for the detailed analysis of the issue]

> this is a *reasonable expectation* for a retrofuturistic protocol
> like Gemini.

I love "retrofuturistic" and I hope it will be used in the official
specification.

From stephane at sources.org  Wed Dec  9 08:38:45 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 9 Dec 2020 09:38:45 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209052651.GY24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
Message-ID: <20201209083845.GC14045@sources.org>

On Wed, Dec 09, 2020 at 12:26:51AM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 73 lines which said:

> DNS *can* support UTF-8, but such support isn't wide, nor is it a
> standard.

Wrong. DNS 2181, which clarifies that "any binary string whatever can
be used as the label of any resource record" is part of the Standards
Track. The reasons why few people use UTF-8 in domain names are:

* Ignorance and lack of care for internationalization,

* Non-DNS reasons such as the fact that existing libraries and applications
  may react badly to non-ASCII domain names,

* As often, the problem of normalization. DNS has normalization of
  names (the case-insensitivity rule) but it does not extend to
  Unicode.

> It does have an RFC (RFC-3492) and said RFC does contain code for
> encoding and decoding punycode (but it's in C, and the API is
> ... not what I would define but it can be worked with).

There is an implemention of Punycode in every standard library,
whatever your language.

> so a domain name like "??.english.s?d?r.???" is converted thusly:

In Python (but it is as simple in any other language):

>>> print(codecs.encode("??.English.s?d?r.???", encoding="idna"))
b'xn--99zt52a.English.xn--sdr-rlad.xn--wgbh1c'

(Note that the encodings.idna library of Python standard library is
limited to IDN v1.)

So, almost nothing to do for the programmer. I don't agree with your
assessment that IDN is simpler than IRI.

> I'm not even sure what name should be in a certificate for an
> IDN---the full UTF-8 version, or the punycode version, or both?
> What's currently done in HTTP land about this? (answering this will
> at least point in a direction, even if we don't want to go that
> direction).

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8399.txt

But it depends on the CA. It seems Let's Encrypt does not want to
handle UTF-8 and requires Punycode.

> [3]	The domain name "gemini.conman.org" has three labels, "gemini",
> 	"conman" and "org".  The term "label" is DNS lingo.

Let's be picky, there are four, there is also the root :-)

From stephane at sources.org  Wed Dec  9 09:19:39 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 9 Dec 2020 10:19:39 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <X8+SHYMaq2V/625D@goldfish.localdomain>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
Message-ID: <20201209091939.GA16874@sources.org>

On Tue, Dec 08, 2020 at 09:47:57AM -0500,
 Natalie Pendragon <natpen at natpen.net> wrote 
 a message of 32 lines which said:

> Yes, you should respect robots.txt in my opinion. It's not compulsory,
> but it's currently the best way we have to respect servers' wishes and
> bandwidth constraints.

It is interesting to note that some robots.txt are quite broken (see
gemini://houston.coder.town/robots.txt)


From marcx2 at welz.org.za  Wed Dec  9 12:20:46 2020
From: marcx2 at welz.org.za (marc)
Date: Wed, 9 Dec 2020 13:20:46 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201207153216.GA25299@sources.org>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207153216.GA25299@sources.org>
Message-ID: <20201209122046.GA22453@localhost.localdomain>

Hello again

> > An URL is an address, in the same way that a phone number or an IP
> > is an address. Ideally these are globally unique, unambiguous and
> > representable everywhere. This address scheme should be independent
> > of a localisation.
> >
> > We don't insist that phone numbers are rendered in roman
> > numerals either. My dialing prefix isn't +XXVII. The
> > gemini:// prefix isn't tweeling:// in dutch.
> 
> This theory, in the world of domain names, is wrong. RFC 2277 says...

Your reliance on one RFC as an authority while rejecting
another RFC as "a one-sided anti-internationalization rant"
does not strike me as being consistent.

> > reducing security,
> 
> That's false. I stil wait to see an actual phishing email with
> Unicode. Most of the time, the phisher does not even bother to have a
> realistic URL, they advertise <http://evil.example/famousbank> and it
> works (few people check URL).
> 
> Anyway, the goal of Gemini is not to do onli banking so this is not
> really an issue.

There exists a neat quote by a certain B. Russel on
people who are so very sure of themselves.

The gemini spec fixes the url length in octets. Various 
ways of encoding internationalised data may make it possible 
for a bad guy to shrink and grow urls in unexpected ways 
and clobber this buffer.

The interaction between filesystems, archiving software or
protocol gateways generates many more aliasing problems.

> Now, identifiers, like domain names,
> are a complicated case, since they are both protocol elements and
> text. But, since they are widely visible (in advertisments, business
> cards, etc), I believe they should be internationalized, too.

Imagine a slightly different world where people don't exchange
business cards, but a small amount of sheet music - their own
personal jingle (retrofuturism, right ?). It turns out sheet
music music is annotated in Italian - I think it can say things like
"forte" or "pianissimo".  Would you ago around and angrily
cross out those words to replace them with your local language ?

> > subtle ambiguities (is the cyrilic C the same as a latin - C, who
> > knows ?),
> 
> There is no ambiguity, U+0421 is different from  U+0043.

There are various insults starting with latin C. Rewriting
them to start with cyrilic C doesn't make them any
less insulting.

> > Using unicode in addresses balkanises this global space
> 
> The english-speaking space is not a global space: it is the space of a
> minority of the world population.

[WARNING: wall of text ahead]

I think here we are heading to core of the argument...
of what a language is. And it is a big split
that many don't know how to articulate:

Some see language as a core part of their identity
(who they are) - others see language as a tool for
communicating (a protocol).

I think tying ones identity to a nation/ethnicity and
its language sets one up for conflict both internally
(who one is) and externally (between states). It
is also silly - languages actually evolve quite
rapidly and leave significant imprints on each
other, while people migrate (or get conquered, sadly).

So I think it is better *not* to view english as
the property of a particular ethnicity, but as
as a popular communications protocol - an earlier
protocol might have been latin, which left significant
influences on english - and if mandarin (or hindi,
or whatever) ends up displacing english in turn, then I 
expect there to be many traces of english to be left there
too.

It is easy to envy native english speakers - that
they have it easier. But that is not true - being
multilingual is a real advantage, in so many ways:
Being able to speak an extra language, for instance,
is a major protective factor against dementia... and
every extra language one learns makes it easier
to learn the next. Bible scholars have no issues
acquiring a decent grasp of Hebrew and Ancient Greek,
philosophers might try to read Imanuel Kant in German.

Most of us have arbitrarily tied our identities to
a nation state and thus a that nation's language - it
really doesn't have to be that way.

regards

marc

From petite.abeille at gmail.com  Wed Dec  9 12:56:30 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 9 Dec 2020 13:56:30 +0100
Subject: IDN with Gemini?
In-Reply-To: <20201209122046.GA22453@localhost.localdomain>
References: <20201204135138.GA684@sources.org>
 <CAD2gp_R04+q+jF9YzyCn9igdzMpPnsTTTkOFigDRUj4+_WoNig@mail.gmail.com>
 <20201204150029.GA4584@sources.org>
 <x65XLf_e3T8DG1oRRP2Ym-TvFpFpw_QI76CqkZfrDlXQKJruBiXdIrEulbkdM6-el2ungItLVKD1_yHi3kzJaxVQhFzfrrLjT1C--m-fw0s=@protonmail.com>
 <20201207021641.GA30912@202x.moe>
 <hWeAN9oi-mRzle353Rh7UG_v29IhcvPmabPZzz7QV9v-2dCGOFASVi1s9O2e-FNamuLQw1kBAKWiA2O0uFdp-nerHgXSVz5ccSA0vFM_tAc=@protonmail.com>
 <CFF9112F-D4A8-4D24-B713-99CD5C93D1D1@chilliet.eu>
 <20201207105021.GD17138@sources.org>
 <20201207123041.GA17160@localhost.localdomain>
 <20201207153216.GA25299@sources.org>
 <20201209122046.GA22453@localhost.localdomain>
Message-ID: <A20208A5-5403-4C55-AF58-E4DAE9308AB1@gmail.com>



> On Dec 9, 2020, at 13:20, marc <marcx2 at welz.org.za> wrote:
> 
> Most of us have arbitrarily tied our identities to
> a nation state and thus a that nation's language - it
> really doesn't have to be that way.
> 

Amen to that. International provincialism of sort. 

"That gibberish he talked was Cityspeak, gutter talk, a mishmash of Japanese, Spanish, German, what have you. I didn?t really need a translator. I knew the lingo, every good cop did. But I wasn?t going to make it easier for him."

?Rick Deckard

Nevertheless, it would be nice to be able to type UTF-8 directly in gemini requests & text/gemini links and have everything magically work without much ado. That would be progress for once.

Word of the week:
https://en.wikipedia.org/wiki/Retrofuturism


From jmcbray at carcosa.net  Wed Dec  9 15:08:25 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 09 Dec 2020 10:08:25 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209083845.GC14045@sources.org> (Stephane Bortzmeyer's
 message of "Wed, 9 Dec 2020 09:38:45 +0100")
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
Message-ID: <87r1nzrp92.fsf@dorothy.carcosa.net>

Stephane Bortzmeyer <stephane at sources.org> writes:

> On Wed, Dec 09, 2020 at 12:26:51AM -0500,
>  Sean Conner <sean at conman.org> wrote 
>  a message of 73 lines which said:
>
>> DNS *can* support UTF-8, but such support isn't wide, nor is it a
>> standard.
>
> Wrong. DNS 2181, which clarifies that "any binary string whatever can
> be used as the label of any resource record" is part of the Standards
> Track. The reasons why few people use UTF-8 in domain names are:

How widespread is support in client resolver libraries and in servers,
though? It's one thing to say, "yes, the standard is to support
non-ASCII names", and another entirely to say "just sending non-ASCII
names to your DNS server will work".

> There is an implemention of Punycode in every standard library,
> whatever your language.

Not strictly true. There isn't one in Common Lisp's standard library,
for example. There is one in Quicklisp, the widely used package
repository though, so that's okay for me.

I kind of feel like we should just bite the bullet and admit that a
fully-compliant client needs to punycode domains when looking them up,
and encode URLs when sending them to the server, and that
fully-compliant servers need to decode URLs when resolving them.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From cage-dev at twistfold.it  Wed Dec  9 17:41:44 2020
From: cage-dev at twistfold.it (cage)
Date: Wed, 9 Dec 2020 18:41:44 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87r1nzrp92.fsf@dorothy.carcosa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <87r1nzrp92.fsf@dorothy.carcosa.net>
Message-ID: <X9EMWG8e4HDUoHB1@kurosawa.casa.net>

On Wed, Dec 09, 2020 at 10:08:25AM -0500, Jason McBrayer wrote:

[punycode library]

> There is one in Quicklisp,

Glad to hear that! :)

Bye!
C.

From petite.abeille at gmail.com  Wed Dec  9 20:17:22 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 9 Dec 2020 21:17:22 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209083845.GC14045@sources.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
Message-ID: <387CA516-D6EC-4DF8-8C49-1BD34988F225@gmail.com>



> On Dec 9, 2020, at 09:38, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> There is an implemention of Punycode in every standard library,
> whatever your language.

There is also GNU Libidn (idn):

# idn --quiet r?ksm?rg?s.se bl?b?rgr?d.no
xn--rksmrgs-5wao1o.se
xn--blbrgrd-fxak7p.no

https://www.gnu.org/software/libidn/manual/html_node/Invoking-idn.html


From sean at conman.org  Wed Dec  9 21:44:28 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 9 Dec 2020 16:44:28 -0500
Subject: IDN with Gemini?
In-Reply-To: <20201209081219.GA14045@sources.org>
References: <20201204135138.GA684@sources.org> <5803930.odQ0NCZWSD@tempete>
 <iIXf-z3biGRra9gj3JGk0WG5KeIzGA9-cdc5Nl0Vq60d73CmJpEudabaUC3otA28PxEaO9q_uFNYihAtlSg2C_dkRHihqEJsLDu5N5zR4l0=@protonmail.com>
 <c03e5926-1403-00ac-0969-19725384680c@scotdoyle.com>
 <Ws3Z7nDYW2kvGmorJxRyyF0gsAF5LPEdqudKBxY2QnwtvYq-MLAAQWIDcSjmSHSNeyIgYZacmwEBPM93gsdik0cfSSFlltYtbT2F_Ga3KVo=@protonmail.com>
 <20201208103208.GC11926@sources.org>
 <20201208222038.GV24194@brevard.conman.org>
 <20201209081219.GA14045@sources.org>
Message-ID: <20201209214427.GZ24194@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Tue, Dec 08, 2020 at 05:20:38PM -0500,
>  Sean Conner <sean at conman.org> wrote 
>  a message of 29 lines which said:
> 
> > I was, however, a bit disappointed that "g?meaux.bortzmeyer.org" and
> > "xn--gmeaux-bva.bortzmeyer.org" didn't exist.
> 
> Then it means your DNS resolver is broken because
> xn--gmeaux-bva.bortzmeyer.org (the A-label, the Punycode form) is in
> the DNS.

  Then I'm going to say this was operator error because I was able to look
up xn--gmeaux-bva.bortzmeyer.org.

  -spc


From sean at conman.org  Wed Dec  9 22:17:49 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 9 Dec 2020 17:17:49 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209083845.GC14045@sources.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
Message-ID: <20201209221749.GA24194@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Wed, Dec 09, 2020 at 12:26:51AM -0500,
>  Sean Conner <sean at conman.org> wrote 
>  a message of 73 lines which said:
> 
> > It does have an RFC (RFC-3492) and said RFC does contain code for
> > encoding and decoding punycode (but it's in C, and the API is
> > ... not what I would define but it can be worked with).
> 
> There is an implemention of Punycode in every standard library,
> whatever your language.
> 
> > so a domain name like "??.english.s?d?r.???" is converted thusly:
> 
> In Python (but it is as simple in any other language):
> 
> >>> print(codecs.encode("??.English.s?d?r.???", encoding="idna"))
> b'xn--99zt52a.English.xn--sdr-rlad.xn--wgbh1c'
> 
> (Note that the encodings.idna library of Python standard library is
> limited to IDN v1.)
> 
> So, almost nothing to do for the programmer. I don't agree with your
> assessment that IDN is simpler than IRI.

  I'm sorry, but the two languages I work in do *not* have an implementation
of punycode in their standard library.  I *was* able to find code for C
(from the RFC, which at least I know will work per the RFC) and could not
find one for Lua.  There's a reason why I'm having to muck with this.  The
API I have for C is *not* set up to handle domain names (breaking out the
labels, prepending or removing the "xn--", etc.).

  It's wonderful that the language you use comes with punycode support in
its standard library.  Not all languages have that.  I'm looking at the list
of clients [1] and there's one client written in a language I haven't heard
of before (Vala).  Other languages used are Nim, scheme and Tcl.  I would be
surprised if Vala or Nim have a punycode implementation.

  -spc (But hey, write your own client that does eveything you want and show
	us all how easy it is)

[1]	gemini://gemini.circumlunar.space/software/

From colecmac at protonmail.com  Wed Dec  9 22:31:32 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 09 Dec 2020 22:31:32 +0000
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209221749.GA24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
Message-ID: <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>

> I'm sorry, but the two languages I work in donot have an implementation
> of punycode in their standard library.

Isn't this somewhat irrelevant in this case? It's unfortunate they don't
have an implementation, but as it stands right now, most Gemini clients
will not handle Unicode domain names at all. Punycoding domains will
solve that issue, and languages that don't have it in their stdlib
can either use a third-party library, or if that's not possible then
those languages will just ignore punycoding entirely. Obviously that's
not great for those languages, but it doesn't make sense to me to not
have punycoding at all because of that.

At the end of the day, Gemini clients must be allowed to support Unicode
domains. Perhaps the term "SHOULD" as defined by RFC2119 should be used
in the spec in this case.


makeworld

From petite.abeille at gmail.com  Wed Dec  9 23:00:16 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 00:00:16 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209221749.GA24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
Message-ID: <AE0DF613-6924-46E4-868A-9481A4368DF6@gmail.com>



> On Dec 9, 2020, at 23:17, Sean Conner <sean at conman.org> wrote:
> 
> could not find one for Lua

Would this suit?

https://github.com/haste/lua-idn/blob/master/idn.lua

From sean at conman.org  Wed Dec  9 23:23:03 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 9 Dec 2020 18:23:03 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <AE0DF613-6924-46E4-868A-9481A4368DF6@gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <AE0DF613-6924-46E4-868A-9481A4368DF6@gmail.com>
Message-ID: <20201209232303.GB24194@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> > On Dec 9, 2020, at 23:17, Sean Conner <sean at conman.org> wrote:
> > 
> > could not find one for Lua
> 
> Would this suit?
> 
> https://github.com/haste/lua-idn/blob/master/idn.lua

  Huh ... turns out I should have searched for 'IDN' instead of 'punycode'. 
The code is for Lua 5.2---it will take a bit of work to get it working for
Lua 5.3 but that still leaves normalization issues.  I'm working with the
GNU libidn right now because it can do normailzation, otherwise, I can get
two different IDNs for the same (visually) domain:

	r?sum?	resume-jxde
	r?sum?	rsum-bpad

  -spc


From petite.abeille at gmail.com  Wed Dec  9 23:45:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 00:45:11 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209232303.GB24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <AE0DF613-6924-46E4-868A-9481A4368DF6@gmail.com>
 <20201209232303.GB24194@brevard.conman.org>
Message-ID: <19DFA53F-B3A4-40D7-A557-DA88F761E666@gmail.com>



> On Dec 10, 2020, at 00:23, Sean Conner <sean at conman.org> wrote:
> 
> 	r?sum?	resume-jxde
> 	r?sum?	rsum-bpad

Talking of which:

Lua Parser for Punycode/IDN Homograph Attack
https://community.rsa.com/community/products/netwitness/blog/2017/04/24/lua-parser-for-punycodeidn-homograph-attack

From will at worrbase.com  Thu Dec 10 00:01:26 2020
From: will at worrbase.com (William Orr)
Date: Thu, 10 Dec 2020 00:01:26 +0000 (UTC)
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201209232303.GB24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <AE0DF613-6924-46E4-868A-9481A4368DF6@gmail.com>
 <20201209232303.GB24194@brevard.conman.org>
Message-ID: <649cac27-6c30-491c-88be-a589dc4363a7@worrbase.com>

The lua wiki has various libs for normalization: http://lua-users.org/wiki/LuaUnicode

I also mentioned libicu earlier, which is a very commonly used lib for unicode handling, and the wiki even mentions a lua library that provides bindings to libicu (although the bindings may be out of date).

https://github.com/unicode-org/icu

Hope that helps

From petite.abeille at gmail.com  Thu Dec 10 00:20:25 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 01:20:25 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <649cac27-6c30-491c-88be-a589dc4363a7@worrbase.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <AE0DF613-6924-46E4-868A-9481A4368DF6@gmail.com>
 <20201209232303.GB24194@brevard.conman.org>
 <649cac27-6c30-491c-88be-a589dc4363a7@worrbase.com>
Message-ID: <A5F1A4C9-0366-4756-88A1-AC37101645E7@gmail.com>



> On Dec 10, 2020, at 01:01, William Orr <will at worrbase.com> wrote:
> 
> The lua wiki has various libs for normalization: http://lua-users.org/wiki/LuaUnicode

Indeed, ustring sports some normalization routines:

https://github.com/wikimedia/mediawiki-extensions-Scribunto/tree/master/includes/engines/LuaCommon/lualib/ustring

While on the topic, do people validate all UTF-8 coming their way? Ala iconv -f UTF-8 -t UTF-8?

From sean at conman.org  Thu Dec 10 01:16:34 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 9 Dec 2020 20:16:34 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
Message-ID: <20201210011634.GC24194@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> > I'm sorry, but the two languages I work in donot have an implementation
> > of punycode in their standard library.
> 
> Isn't this somewhat irrelevant in this case? 

  It was more a comment about this quote:

> There is an implemention of Punycode in every standard library,
> whatever your language.

  There is *not* an implementation of punycode in every standard library,
whatever your language.  In a lot of currently in-use languages?  Probably,
but not *all*.  

> It's unfortunate they don't
> have an implementation, but as it stands right now, most Gemini clients
> will not handle Unicode domain names at all. 

  And I'm not seeing anyone else trying to update clients to do this, even
if in an exploratory nature.  What?  Are they just waiting for a decree?

> Punycoding domains will
> solve that issue, and languages that don't have it in their stdlib
> can either use a third-party library, or if that's not possible then
> those languages will just ignore punycoding entirely. 

  Poking around the GNU libidn documentation, I found Appendix B [1]
worrisome because the IDN rabbit hole just got deeper with U+2024 (ONE DOT
LEADER) and U+2485 (DIGIT FIVE FULL STOP).  Should I worry about it?  I
don't know.  This internationalization stuff is complex and makes me want to
throw up hands in the air, scream a bit, and go back to the simplicity of
ASCII.

  In the end, I'll probably just do Unicode normalization, then punycode and
call it a day.

> Obviously that's
> not great for those languages, but it doesn't make sense to me to not
> have punycoding at all because of that.
> 
> At the end of the day, Gemini clients must be allowed to support Unicode
> domains. Perhaps the term "SHOULD" as defined by RFC2119 should be used
> in the spec in this case.

  So when are you going to update gemget and Amfora to support punycode? 
I've heard it's easy to do.  Or are you waiting for a spec change first?

  -spc (Seriously, I feel like I'm the only one *doing* anything here)

[1]	https://www.gnu.org/software/libidn/manual/html_node/On-Label-Separators.html


From colecmac at protonmail.com  Thu Dec 10 02:00:20 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 10 Dec 2020 02:00:20 +0000
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210011634.GC24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
Message-ID: <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>

> > It's unfortunate they don't
> > have an implementation, but as it stands right now, most Gemini clients
> > will not handle Unicode domain names at all.
>
> And I'm not seeing anyone else trying to update clients to do this, even
> if in an exploratory nature. What? Are they just waiting for a decree?
>
> [snip]
>
> So when are you going to update gemget and Amfora to support punycode?
> I've heard it's easy to do. Or are you waiting for a spec change first?
>
> -spc (Seriously, I feel like I'm the only one doing anything here)

Yes, I am waiting for Solderpunk. On the subject of IDNs, it seems obvious
to me that punycode will accepted as the thing to do for DNS, and that
Unicode should be sent to the server, but some questions around certs
and normalization still remain. I've outlined them here[1].

I suppose you're correct about being the only one doing anything, but I
don't feel like it makes sense to do anything yet. The solution is simple
code-wise (for IDNs), and so I don't feel the need to experiment, and I'd
rather implement this once, in-line with the spec, rather than multiple
times if Solderpunk says something different.

I guess this is just two different approaches to handling issues with a spec.
Gemini is intended to be very strict and not extensible, and is driven by
its spec rather than what people end up doing in the wild, like on the Web.

I don't think you're doing something wrong or bad by publicly experimenting,
but I'd rather not make things more uncertain by implementing something
in non-toy/demo clients before it's official.

1: https://github.com/makeworld-the-better-one/go-gemini/issues/10

Cheers,
makeworld

From sean at conman.org  Thu Dec 10 03:25:40 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 9 Dec 2020 22:25:40 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
Message-ID: <20201210032540.GD24194@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> > > It's unfortunate they don't
> > > have an implementation, but as it stands right now, most Gemini clients
> > > will not handle Unicode domain names at all.
> >
> > And I'm not seeing anyone else trying to update clients to do this, even
> > if in an exploratory nature. What? Are they just waiting for a decree?
> >
> > [snip]
> >
> > So when are you going to update gemget and Amfora to support punycode?
> > I've heard it's easy to do. Or are you waiting for a spec change first?
> >
> > -spc (Seriously, I feel like I'm the only one doing anything here)
> 
> Yes, I am waiting for Solderpunk. On the subject of IDNs, it seems obvious
> to me that punycode will accepted as the thing to do for DNS,

  And why would Solderpunk choose this if no one has bothered to even look
into the possible issues wit respect to coding?  

> and that
> Unicode should be sent to the server, 

and that would be a breaking change on the protocol.  Just having the client
accept IRIs and send URIs wouldn't change the protocol.  But aside for me,
NO ONE bothered to even test this out!

> but some questions around certs
> and normalization still remain. I've outlined them here[1].
> 
> I suppose you're correct about being the only one doing anything, but I
> don't feel like it makes sense to do anything yet. The solution is simple
> code-wise (for IDNs), and so I don't feel the need to experiment, 

  And if it's so simple, why not do it? But I get it, you'd rather wait
until a yeah/nay decision is made.  I mean, who wouldn't like

	single digit resonse codes
	no client certificates
	a link line of [text|url]
	no virtual hosting
	a request format ala gopher (including TABs!)
	no rediection
	no indication of pages are actually gone vs not found
	no MIME parameters

  That's pretty much what the Gemini spec *would have been* had some people
*cough cough* not bothered with doing any implementations.  But i get it. 
Bikeshedding with talk is easy, bikeshedding with an implementation is
tedious.

  -spc

From lazar.michael22 at gmail.com  Thu Dec 10 04:16:30 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Wed, 9 Dec 2020 23:16:30 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210032540.GD24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
Message-ID: <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>

I've been following along with my own software in the background.

First of all, my domain registrar won't even let me put unicode characters
in an A record without automatically converting them to punycode for me.

caf?.mozz.us -> xn--caf-dma.mozz.us

Next, my naive python test client just kind of works as-is [0][1]. It will
convert unicode DNS names to punycode under the hood before doing the lookup.
Any unicode in the URL (IRI?) is left alone because.. why would a
client ever muck
around with the URL that the user gives them? That sounds like a bad idea to
me.

My server (running jetforce) also works as-is. All I had to do was add an entry
for "caf?.mozz.us" as a recognized hostname, and there you go.

```
jetforce-client gemini://caf?.mozz.us
Welcome to AV-98!
Enjoy your patrol through Geminispace...
?? WELCOME TO MOZZ.US ??
```

Requesting unicode path names also works with no changes on my part

```
jetforce-client gemini://caf?.mozz.us/files/?????.txt
20 text/plain
This is a test file with unicode characters in the name.?
```

As do quoted path names (the server will unquote the URL before it
attempts to load the file)

```
jetforce-client
gemini://caf?.mozz.us/files/%F0%9D%92%BB%F0%9D%92%B6%F0%9D%93%83%F0%9D%92%B8%F0%9D%93%8E.txt
20 text/plain
This is a test file with unicode characters in the name.
```

Does this mean my server is already compliant? What else should I try?

- Michael

[0] https://github.com/michael-lazar/jetforce/blob/master/jetforce_client.py
[1] It's nice to finally get a win for python after fighting with TLS
for so long

From sean at conman.org  Thu Dec 10 05:45:01 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 10 Dec 2020 00:45:01 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
Message-ID: <20201210054501.GE24194@brevard.conman.org>

It was thus said that the Great Michael Lazar once stated:
> I've been following along with my own software in the background.

  Thank you.  Without an implementation it is difficult to see where the
landmines are.  So, with that said ...

> First of all, my domain registrar won't even let me put unicode characters
> in an A record without automatically converting them to punycode for me.
> 
> caf?.mozz.us -> xn--caf-dma.mozz.us

  Okay.

> Next, my naive python test client just kind of works as-is [0][1]. It will
> convert unicode DNS names to punycode under the hood before doing the lookup.
> Any unicode in the URL (IRI?) is left alone because.. why would a
> client ever muck
> around with the URL that the user gives them? That sounds like a bad idea to
> me.

  That's debatable.  The percent encoding doesn't change the meaning, just
the "envelope" so-to-speak.  

> My server (running jetforce) also works as-is. All I had to do was add an entry
> for "caf?.mozz.us" as a recognized hostname, and there you go.

  Okay, about that.  I modified my own stupid-simple client to support IRIs
and to convert the hostname via punycode (finally!).  The code changes in
the client weren't that large (once I got the punycode module written, it
was one line to switch from URI parsing to IRI parsing, one line to add the
punycode module, and one line modified to punycode the host when making a
connection) but I'm encountering an issue.  If I use:

	gemini://caf?.mozz.us/files/?????.txt

(and send that as the request) It works, and I get the file.  But when I go
to:

	gemini://xn--caf-dma.mozz.us/files/%F0%9D%92%BB%F0%9D%92%B6%F0%9D%93%83%F0%9D%92%B8%F0%9D%93%8E.txt

(and send that as the request) I get an error 53 (no proxy allowed).  When I
go to:

	gemini://caf?.mozz.us/files/%F0%9D%92%BB%F0%9D%92%B6%F0%9D%93%83%F0%9D%92%B8%F0%9D%93%8E.txt

(and send that as the request) it works as well.  I would expect the second
example to work along with the first and third examples. They all reference
the same resource in the same server.

  Another issue that I've thought of, the length of each request---the first
is 53 bytes, the second is 99 bytes and the third is 93 bytes.  This *could*
be an issue with respect to the the overall limit of 1024 bytes for a
request.

  As far as servers go, GLV-1.12556 still uses the URL parser, and would
choke on an IRI being given as a request (since it expects non-ASCII
characters to be encoded per RFC-3986).  That would be an easy fix for me
(just switch to the IRI parser) but allowing IRIs would be an actual change
to the protocol.  I'm just saying.

> Does this mean my server is already compliant? What else should I try?

  Perhaps allow "xn--caf-dma.mozz.us" as a hostname?

  -spc

> [0] https://github.com/michael-lazar/jetforce/blob/master/jetforce_client.py
> [1] It's nice to finally get a win for python after fighting with TLS
> for so long

From petite.abeille at gmail.com  Thu Dec 10 08:06:55 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 09:06:55 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210011634.GC24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
Message-ID: <AB9E4AB1-9C1B-46B4-88D7-82AD3849EA34@gmail.com>



> On Dec 10, 2020, at 02:16, Sean Conner <sean at conman.org> wrote:
> 
>  -spc (Seriously, I feel like I'm the only one *doing* anything here)

:))

To be is to do. ?Socrates
To do is to be. ?Plato
Do-be-do-be-do. ?Sinatra

https://quoteinvestigator.com/2015/01/26/doing/



From petite.abeille at gmail.com  Thu Dec 10 08:12:22 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 09:12:22 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
Message-ID: <31AF9943-2864-472E-BA3A-A44B844A234D@gmail.com>



> On Dec 10, 2020, at 05:16, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> Next, my naive python test client just kind of works as-is [0][1]. It will
> convert unicode DNS names to punycode under the hood before doing the lookup.

Perhaps of interest:

How do I know when to do a UTF8 or punycode DNS query?
https://stackoverflow.com/questions/16837513/how-do-i-know-when-to-do-a-utf8-or-punycode-dns-query



From sean at conman.org  Thu Dec 10 08:22:25 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 10 Dec 2020 03:22:25 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <AB9E4AB1-9C1B-46B4-88D7-82AD3849EA34@gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <AB9E4AB1-9C1B-46B4-88D7-82AD3849EA34@gmail.com>
Message-ID: <20201210082225.GF24194@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Dec 10, 2020, at 02:16, Sean Conner <sean at conman.org> wrote:
> > 
> >  -spc (Seriously, I feel like I'm the only one *doing* anything here)
> 
> :))
> 
> To be is to do. ?Socrates
> To do is to be. ?Plato
> Do-be-do-be-do. ?Sinatra

  You forgot:

  Do-do-do-do. -Serling

  -spc (There is a fifth dimension, beyond that which is known to man ...)

From petite.abeille at gmail.com  Thu Dec 10 08:28:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 09:28:48 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210082225.GF24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <AB9E4AB1-9C1B-46B4-88D7-82AD3849EA34@gmail.com>
 <20201210082225.GF24194@brevard.conman.org>
Message-ID: <1E5BB88D-E5A0-400B-A262-A041DF88988D@gmail.com>



> On Dec 10, 2020, at 09:22, Sean Conner <sean at conman.org> wrote:
> 
>  Do-do-do-do. -Serling

?It may be said with a degree of assurance that not everything that meets the eye is as it appears.? 
? Rod Serling, The Twilight Zone

From stephane at sources.org  Thu Dec 10 09:05:35 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 10:05:35 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210011634.GC24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
Message-ID: <20201210090535.GA17911@sources.org>

On Wed, Dec 09, 2020 at 08:16:34PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 51 lines which said:

> This internationalization stuff is complex and makes me want to
> throw up hands in the air, scream a bit, and go back to the
> simplicity of ASCII.

ASCII is not simple (think of case-insensitivity) and then only for
people whose latin is the first script they learned.

From stephane at sources.org  Thu Dec 10 09:07:12 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 10:07:12 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
Message-ID: <20201210090712.GB17911@sources.org>

On Wed, Dec 09, 2020 at 11:16:30PM -0500,
 Michael Lazar <lazar.michael22 at gmail.com> wrote 
 a message of 55 lines which said:

> First of all, my domain registrar won't even let me put unicode
> characters in an A record without automatically converting them to
> punycode for me.

Small detail: it is an issue with the DNS *hoster*. Which may be the
same as the registrar or not (if you host your own authoritative name
servers).

> My server (running jetforce) also works as-is.

But not Gemserv (I have to figure out why).


From stephane at sources.org  Thu Dec 10 09:15:42 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 10:15:42 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210032540.GD24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
Message-ID: <20201210091542.GA18084@sources.org>

On Wed, Dec 09, 2020 at 10:25:40PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 53 lines which said:

>   And if it's so simple, why not do it? But I get it, you'd rather wait
> until a yeah/nay decision is made.

It is reasonable to discuss it first because we need a *standard* way
of doing it. Clients and servers must agree or there will be no
interoperability.

Also, I suspect the problem is partially a social one:  programs are
written by programmers. Most programmers are familiar with english and
with the latin script. Therefore, the issue does not seem pressing for
most of them.


From marcx2 at welz.org.za  Thu Dec 10 13:12:59 2020
From: marcx2 at welz.org.za (marc)
Date: Thu, 10 Dec 2020 14:12:59 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210090535.GA17911@sources.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <20201210090535.GA17911@sources.org>
Message-ID: <20201210131259.GA17167@localhost.localdomain>

Hi

> > This internationalization stuff is complex and makes me want to
> > throw up hands in the air, scream a bit, and go back to the
> > simplicity of ASCII.
> 
> ASCII is not simple (think of case-insensitivity) and then only for
> people whose latin is the first script they learned.

I am struggling to take that statement seriously,
and not just because it breaks set theory :-)

Case conversion in ascii is xor 0x20 - that doesn't
even require a branch/comparison and can compile down
to a single assembly instruction.

This versus *many* tens or even hundreds of thousands of
lines of puny/unicode/etc logic.

But lets assume upper/lowercase characters in ascii
are confusing. That would be an argument to restrict
a simple system such as gemini urls to a subset of ascii
which excludes uppercase characters. Which I could support,
and which is effectively what dns ends up doing - as
do the majority of http urls. "Lowest common denominator
for maximum interoperability" is a good maxim.

If ascii case conversion is confusing, then this isn't
an excuse to grow this confusion by many orders of
magnitude. That makes the problem a lot worse.

  "Oops, I've burnt my toast - I know, lets solve that
   by burning down the house"

regards

marc

From stephane at sources.org  Thu Dec 10 13:43:11 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 14:43:11 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <X8+SHYMaq2V/625D@goldfish.localdomain>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
Message-ID: <20201210134311.GA28808@sources.org>

On Tue, Dec 08, 2020 at 09:47:57AM -0500,
 Natalie Pendragon <natpen at natpen.net> wrote 
 a message of 32 lines which said:

> Yes, you should respect robots.txt in my opinion. It's not compulsory,
> but it's currently the best way we have to respect servers' wishes and
> bandwidth constraints. There is even a companion spec for doing so,
> which accompanies the main Gemini spec.
> 
> gemini://gemini.circumlunar.space/docs/companion/robots.gmi

The spec is quite vague about the *order* of directives. For instance,
<gemini://gempaper.strangled.net/robots.txt> is:

User-agent: *
Disallow: /credentials.txt
User-agent: archiver
Disallow: /

The intented semantics is probably to disallow archivers but my parser
regarded the site as available because it stopped at the first match,
the star. Who is right?

<gemini://gemini.circumlunar.space/docs/companion/robots.gmi> and
<http://www.robotstxt.org/robotstxt.html> are unclear.



From petite.abeille at gmail.com  Thu Dec 10 14:00:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 15:00:28 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210134311.GA28808@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
Message-ID: <90DAA1EF-2ED5-4616-BF4A-E119165F8391@gmail.com>



> On Dec 10, 2020, at 14:43, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> The spec is quite vague about the *order* of directives.

Perhaps of interest:

While by standard implementation the first matching robots.txt pattern always wins, Google's implementation differs in that Allow patterns with equal or more characters in the directive path win over a matching Disallow pattern. Bing uses the Allow or Disallow directive which is the most specific.

In order to be compatible to all robots, if one wants to allow single files inside an otherwise disallowed directory, it is necessary to place the Allow directive(s) first, followed by the Disallow.

http://en.wikipedia.org/wiki/Robots_exclusion_standard

Also:

https://developers.google.com/search/reference/robots_txt

From come at chilliet.eu  Thu Dec 10 14:07:50 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me_Chilliet?=)
Date: Thu, 10 Dec 2020 15:07:50 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210134311.GA28808@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
Message-ID: <9F99A46F-837A-4968-8C0A-87A6755CAAD6@chilliet.eu>

I don't see anything in the spec saying to stop at first match. I think you should read the whole response and apply all lines that matches your virtual user agent.
So in this case for an archiver, all lines.

From stephane at sources.org  Thu Dec 10 14:09:10 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 15:09:10 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <90DAA1EF-2ED5-4616-BF4A-E119165F8391@gmail.com>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
 <90DAA1EF-2ED5-4616-BF4A-E119165F8391@gmail.com>
Message-ID: <20201210140910.GA29781@sources.org>

On Thu, Dec 10, 2020 at 03:00:28PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 24 lines which said:

> Perhaps of interest:

Not exactly the same thing since my email was about order of
User-Agent (when there is both "*" and "archiver") but, yes, Robot
Exclusion Standard is a mess.

> In order to be compatible to all robots, if one wants to allow
> single files inside an otherwise disallowed directory, it is
> necessary to place the Allow directive(s) first, followed by the
> Disallow.

Note that Allow is not even
standard. <http://www.robotstxt.org/robotstxt.html>: 

there is no "Allow" field. 

From stephane at sources.org  Thu Dec 10 14:15:54 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 15:15:54 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <9F99A46F-837A-4968-8C0A-87A6755CAAD6@chilliet.eu>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
 <9F99A46F-837A-4968-8C0A-87A6755CAAD6@chilliet.eu>
Message-ID: <20201210141554.GA30103@sources.org>

On Thu, Dec 10, 2020 at 03:07:50PM +0100,
 C?me Chilliet <come at chilliet.eu> wrote 
 a message of 4 lines which said:

> I don't see anything in the spec saying to stop at first match. I think you should read the whole response and apply all lines that matches your virtual user agent.
> So in this case for an archiver, all lines.

Then this example in <http://www.robotstxt.org/robotstxt.html> would
not work:

User-agent: Google
Disallow:
User-agent: *
Disallow: /

Because with your algorithm, Google would be disallowed (while the
comment in the page says "To allow a single robot[Google]").


From petite.abeille at gmail.com  Thu Dec 10 14:18:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 15:18:31 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210140910.GA29781@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
 <90DAA1EF-2ED5-4616-BF4A-E119165F8391@gmail.com>
 <20201210140910.GA29781@sources.org>
Message-ID: <949C3108-E8F4-4B64-A1B5-9E01891C2054@gmail.com>



> On Dec 10, 2020, at 15:09, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Not exactly the same thing since my email was about order of
> User-Agent (when there is both "*" and "archiver") but, yes, Robot
> Exclusion Standard is a mess.

Right. Perhaps best to look at how things are actually implemented in the wild :)

Given your example -and a user agent of archiver- robots.txt Validator and Testing Tool at https://technicalseo.com/tools/robots-txt/ says Disallow.



From jmcbray at carcosa.net  Thu Dec 10 14:20:06 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 10 Dec 2020 09:20:06 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <31AF9943-2864-472E-BA3A-A44B844A234D@gmail.com> (Petite
 Abeille's message of "Thu, 10 Dec 2020 09:12:22 +0100")
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
 <31AF9943-2864-472E-BA3A-A44B844A234D@gmail.com>
Message-ID: <87im99spyh.fsf@dorothy.carcosa.net>

Petite Abeille <petite.abeille at gmail.com> writes:

>> On Dec 10, 2020, at 05:16, Michael Lazar <lazar.michael22 at gmail.com> wrote:
>> 
>> Next, my naive python test client just kind of works as-is [0][1]. It will
>> convert unicode DNS names to punycode under the hood before doing the lookup.
>
> Perhaps of interest:
>
> How do I know when to do a UTF8 or punycode DNS query?
> https://stackoverflow.com/questions/16837513/how-do-i-know-when-to-do-a-utf8-or-punycode-dns-query

You can unconditionally just run the punycode encoder over domain names,
though ? an all-ASCII domain name will be unchanged. The stackoverflow
question deals with non-internet domain names in Active Directory, which
we don't have to support.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From petite.abeille at gmail.com  Thu Dec 10 14:20:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 15:20:18 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210141554.GA30103@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
 <9F99A46F-837A-4968-8C0A-87A6755CAAD6@chilliet.eu>
 <20201210141554.GA30103@sources.org>
Message-ID: <D9A86061-1A74-48B1-BDC6-86C53D0FEB4F@gmail.com>



> On Dec 10, 2020, at 15:15, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Because with your algorithm, Google would be disallowed

An empty Disallow means allow all, no?


From linde.philip at gmail.com  Thu Dec 10 14:20:35 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Thu, 10 Dec 2020 15:20:35 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210134311.GA28808@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
Message-ID: <20201210152035.a98827e3750ada180d0d9f35@gmail.com>

On Thu, 10 Dec 2020 14:43:11 +0100
Stephane Bortzmeyer <stephane at sources.org> wrote:

> The spec is quite vague about the *order* of directives. For instance,
> <gemini://gempaper.strangled.net/robots.txt> is:
> 
> User-agent: *
> Disallow: /credentials.txt
> User-agent: archiver
> Disallow: /
> 
> The intented semantics is probably to disallow archivers but my parser
> regarded the site as available because it stopped at the first match,
> the star. Who is right?

According to the spec, lines beginning with "User-agent:" indicate a
user agent to which subsequent lines apply

My interpretation is that your example expresses:

For any user agent:
disallow access to /credentials.txt
For archiver user agents:
disallow access to /

It is unclear from that specification alone whether the user agent
applies to all Disallow lines after it, or only until the next
User-agent line. The spec refers to the web standard for robot
exclusion. In the web standard, you can think of 1+ User-agent lines
followed by 1+ Allow/Disallow lines as a single record which specifies
that all the the user agents should follow the Allow/Disallow rules
that follow them. For example:

User-agent: archiver
User-agent: search engine
Disallow /articles
Disallow /uploads
User-agent: something
User-agent: someother
Disallow /whatever

This expresses:

For user agent archiver or search engine:
disallow access to /articles,
disallow access to /uploads
For user agent something or someother:
disallow access to /whatever

Refer to: http://www.robotstxt.org/norobots-rfc.txt

The way "robots.txt for Gemini" specifies it is rather confusing. It's
not indicated exactly how it differs from the web robot exclusion
standard and taken alone it is ambiguous.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201210/4885ad20/attachment.sig>

From petite.abeille at gmail.com  Thu Dec 10 14:36:17 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 15:36:17 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87im99spyh.fsf@dorothy.carcosa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <CAFTy05ZY3HhLErTvX_cHVMyFn2=tXYo9mE-OG_jXcEn6xW-7cw@mail.gmail.com>
 <31AF9943-2864-472E-BA3A-A44B844A234D@gmail.com>
 <87im99spyh.fsf@dorothy.carcosa.net>
Message-ID: <F8AAF3E9-130E-4D0E-BCD6-FE4129F598C3@gmail.com>



> On Dec 10, 2020, at 15:20, Jason McBrayer <jmcbray at carcosa.net> wrote:
> 
> non-internet domain names in Active Directory, which
> we don't have to support.

Hmmm... so... no .local queries ala Cheshire?

https://tools.ietf.org/html/rfc6762#appendix-F

Perhaps worthwhile quoting in full:

Appendix F.  Use of UTF-8

   After many years of debate, as a result of the perceived need to
   accommodate certain DNS implementations that apparently couldn't
   handle any character that's not a letter, digit, or hyphen (and
   apparently never would be updated to remedy this limitation), the
   Unicast DNS community settled on an extremely baroque encoding called
   "Punycode".  Punycode is a remarkably ingenious encoding
   solution, but it is complicated, hard to understand, and hard to
   implement, using sophisticated techniques including insertion unsort
   coding, generalized variable-length integers, and bias adaptation.
   The resulting encoding is remarkably compact given the constraints,
   but it's still not as good as simple straightforward UTF-8, and it's
   hard even to predict whether a given input string will encode to a
   Punycode string that fits within DNS's 63-byte limit, except by
   simply trying the encoding and seeing whether it fits.  Indeed, the
   encoded size depends not only on the input characters, but on the
   order they appear, so the same set of characters may or may not
   encode to a legal Punycode string that fits within DNS's 63-byte
   limit, depending on the order the characters appear.  This is
   extremely hard to present in a user interface that explains to users
   why one name is allowed, but another name containing the exact same
   characters is not.  Neither Punycode nor any other of the "ASCII-
   Compatible Encodings" proposed for Unicast DNS may be used
   in Multicast DNS messages.  Any text being represented internally in
   some other representation must be converted to canonical precomposed
   UTF-8 before being placed in any Multicast DNS message.



From cage-dev at twistfold.it  Thu Dec 10 15:54:52 2020
From: cage-dev at twistfold.it (cage)
Date: Thu, 10 Dec 2020 16:54:52 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210091542.GA18084@sources.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
Message-ID: <X9JEzJQPK42PoSNl@kurosawa.casa.net>

On Thu, Dec 10, 2020 at 10:15:42AM +0100, Stephane Bortzmeyer wrote:

Hi folks!

> On Wed, Dec 09, 2020 at 10:25:40PM -0500,
>  Sean Conner <sean at conman.org> wrote
>  a message of 53 lines which said:
>
> >   And if it's so simple, why not do it? But I get it, you'd rather wait
> > until a yeah/nay decision is made.
>
> It is reasonable to discuss it first because we need a *standard* way
> of doing it. Clients and servers must agree or there will be no
> interoperability.

I have read most of the messages in this thread, i would just say that
one  of  the  problems  with  WWW is  that  browser  are  getting  not
manageable by a single user or a hobbyist programmer.

This  issue  lead to  centralization  (see  chromium and  the  company
behind) as most of us can easily see.

Adding  more complexity  and more  responsibility to  software authors
will shrink diversity in the gemini software landscape.

Of  course i  talk here  as  a client  author  here but  in the  niche
language i  chose (common lisp) i  was forced to write  my URL parsing
procedure, adding i18n domains will require  a lot of work because the
third party library  (the only one) Jason McBrayer  wrote some message
above does  not implement  punycode->unicode conversion (if  i checked
the right library, thanks to the author anyway, better than nothing!).

Probably many of you just thinking "who cares about CL?", and probably
this is the mindset that lead to the mess it is now the web.

Internationalized  hostname  has  advantages  but  how  this  adding
complexity impact software author? Is this complexity needed?

I have no answer, just would want to express some of my concerns.

Bye!
C.

PS: i am not a native English speaker (as you can see :-) )

From petite.abeille at gmail.com  Thu Dec 10 16:27:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 17:27:05 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <X9JEzJQPK42PoSNl@kurosawa.casa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org> <X9JEzJQPK42PoSNl@kurosawa.casa.net>
Message-ID: <C9EBE9CE-2ED9-4EAA-ACFE-361144612273@gmail.com>



> On Dec 10, 2020, at 16:54, cage <cage-dev at twistfold.it> wrote:
> 
> Internationalized  hostname  has  advantages  but  how  this  adding
> complexity impact software author? Is this complexity needed?

Ah, yes, le charme discret du r?gionalisme.

It all boils down to the unmeasurable joy of Unicode ?

> I have no answer, just would want to express some of my concerns.

Archibald 'Harry' Tuttle had about 3 lines in Terry Gilliam's' Brazil:

? Well, that's a pipe of a different color.
? Listen, this whole system of yours could be on fire and I couldn't even turn on the kitchen tap without filling out a twenty-seven B stroke six... bloody paperwork.
? Listen, kid, we're all in it together.

This sums it up in terms of retrofitting Unicode into ASCII:

https://www.youtube.com/watch?v=VRfoIyx8KfU

Perhaps Unicode should be abandoned altogether, and we all move back to to the original simplicity of ASCII. 

From retro to retrograde. Sigh. 

It's all about the plumbing.




From stephane at sources.org  Thu Dec 10 16:24:30 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 17:24:30 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <D9A86061-1A74-48B1-BDC6-86C53D0FEB4F@gmail.com>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
 <9F99A46F-837A-4968-8C0A-87A6755CAAD6@chilliet.eu>
 <20201210141554.GA30103@sources.org>
 <D9A86061-1A74-48B1-BDC6-86C53D0FEB4F@gmail.com>
Message-ID: <20201210162427.GA870@sources.org>

On Thu, Dec 10, 2020 at 03:20:18PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 8 lines which said:

> > On Dec 10, 2020, at 15:15, Stephane Bortzmeyer <stephane at sources.org> wrote:
> > 
> > Because with your algorithm, Google would be disallowed
> 
> An empty Disallow means allow all, no?

Yes, but the next Disallow add a restriction to everything.

From petite.abeille at gmail.com  Thu Dec 10 16:36:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 17:36:18 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210162427.GA870@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
 <9F99A46F-837A-4968-8C0A-87A6755CAAD6@chilliet.eu>
 <20201210141554.GA30103@sources.org>
 <D9A86061-1A74-48B1-BDC6-86C53D0FEB4F@gmail.com>
 <20201210162427.GA870@sources.org>
Message-ID: <263A12BA-1FB9-46E0-8DD0-7DEACF262960@gmail.com>



> On Dec 10, 2020, at 17:24, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Yes, but the next Disallow add a restriction to everything.

User-agent: Google
Disallow:
User-agent: *
Disallow: /

mwahahaha. a work of beauty indeed. this would seem to read as disallow everything, for everyone, but  google. go figure.




From stephane at sources.org  Thu Dec 10 16:35:12 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 17:35:12 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210134311.GA28808@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
Message-ID: <20201210163512.GA1390@sources.org>

On Thu, Dec 10, 2020 at 02:43:11PM +0100,
 Stephane Bortzmeyer <stephane at sources.org> wrote 
 a message of 26 lines which said:

> The spec is quite vague about the *order* of directives.

Another example of the fact that you cannot rely on robots.txt:
regexps. The official site <http://www.robotstxt.org/robotstxt.html>
is crystal-clear: "Note also that globbing and regular expression are
not supported in either the User-agent or Disallow lines".

But in the wild you find things like
<gemini://drewdevault.com/robots.txt>:

User-Agent: gus
Disallow: /cgi-bin/web.sh?*

Opinion: may be we should specify a syntax for Gemini's robots.txt,
not relying on the broken Web one?

From stephane at sources.org  Thu Dec 10 16:42:20 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 10 Dec 2020 17:42:20 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <949C3108-E8F4-4B64-A1B5-9E01891C2054@gmail.com>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
 <90DAA1EF-2ED5-4616-BF4A-E119165F8391@gmail.com>
 <20201210140910.GA29781@sources.org>
 <949C3108-E8F4-4B64-A1B5-9E01891C2054@gmail.com>
Message-ID: <20201210164220.GA1648@sources.org>

On Thu, Dec 10, 2020 at 03:18:31PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 16 lines which said:

> Perhaps best to look at how things are actually implemented in the
> wild :)

I have a big disagreement with this approach. As a matter of principle
(this approach allow big actors to set de facto standards and forcing
the others into a race which was precisely what made the Web the
bloated horror it is) and also because you cannot check every possible
implementation, and, anyway, they disagree among them.

So, no, I want a clear specification of what a crawler is supposed to
do.

> Given your example -and a user agent of archiver- robots.txt
> Validator and Testing Tool at
> https://technicalseo.com/tools/robots-txt/ says Disallow.

I was not able to make it work. It keeps telling me that
http://t.example/foo is "Invalid URL" and I find no way to enter an
arbitrary User-Agent. And, anyway, it will not be an official test,
just one implementation with some proprietary extensions.

From petite.abeille at gmail.com  Thu Dec 10 17:00:46 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 10 Dec 2020 18:00:46 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210164220.GA1648@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
 <90DAA1EF-2ED5-4616-BF4A-E119165F8391@gmail.com>
 <20201210140910.GA29781@sources.org>
 <949C3108-E8F4-4B64-A1B5-9E01891C2054@gmail.com>
 <20201210164220.GA1648@sources.org>
Message-ID: <C5EA5390-E90C-48C7-89E2-F3ABF30E81B7@gmail.com>



> On Dec 10, 2020, at 17:42, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> So, no, I want a clear specification of what a crawler is supposed to do.

Admirable :D

This is perhaps why academics should not write software. Practically speaking :P

Let's face it... there is none... it's all a gigantic sausage machine... haphazardly scotch-taped together... barely holding up, if at all...

That said, circa 2004, this is what Mark Pilgrim had to say about the matter:

Why Specs Matter
https://pwn.ersh.io/notes/why_specs_matter/



Here is a copy for your enjoyment. It never gets old:



Most developers are morons, and the rest are assholes. I have at various times counted myself in both groups, so I can say this with the utmost confidence.

Assholes

Assholes read specs with a fine-toothed comb, looking for loopholes, oversights, or simple typos. Then they write code that is meticulously spec-compliant, but useless. If someone yells at them for writing useless software, they smugly point to the sentence in the spec that clearly spells out how their horribly broken software is technically correct, and then they crow about it on their blogs.

There is a faction of assholes that write test cases. These people are good to have around while writing a spec, because they can occasionally be managed into channeling their infinite time and energy into finding loopholes before the spec is final. Unfortunately, managing assholes is even harder and more time-consuming than it sounds. This is why writing good specs takes so long: most of the time is frittered away on asshole management.

Morons

Morons, on the other hand, don?t read specs until someone yells at them. Instead, they take a few examples that they find ?in the wild? and write code that seems to work based on their limited sample. Soon after they ship, they inevitably get yelled at because their product is nowhere near conforming to the part of the spec that someone else happens to be using. Someone points them to the sentence in the spec that clearly spells out how horribly broken their software is, and they fix it.

Besides the run-of-the-mill morons, there are two factions of morons that are worth special mention. The first work from examples, and ship code, and get yelled at, just like all the other morons. But then when they finally bother to read the spec, they magically turn into assholes and argue that the spec is ambiguous, or misleading in some way, or ignoreable because nobody else implements it, or simply wrong. These people are called sociopaths. They will never write conformant code regardless of how good the spec is, so they can safely be ignored.

The second faction of morons work from examples, ship code, and get yelled at. But when they get around to reading the spec, they magically turn into advocates and write up tutorials on what they learned from their mistakes. These people are called experts. Virtually every useful tutorial in the world was written by a moron-turned-expert.

Angels

Some people would argue that not all developers are morons or assholes, but they are mistaken. For example, some people posit the existence of what I will call the ?angel? developer. ?Angels? read specs closely, write code, and then thoroughly test it against the accompanying test suite before shipping their product. Angels do not actually exist, but they are a useful fiction to make spec writers to feel better about themselves.

Why specs matter

If your spec isn?t good enough, morons have no chance of ever getting things right. For everyone who complains that their software is broken, there will be two assholes who claim that it?s not. The spec, whose primary purpose is to arbitrate disputes between morons and assholes, will fail to resolve anything, and the arguments will smolder for years.

If your spec is good enough, morons have a fighting chance of getting things right the second time around, without being besieged by assholes. Meanwhile, the assholes who have nothing better to do than look for loopholes won?t find any, and they?ll eventually get bored and wander off in search of someone else to harass.

?






From cage-dev at twistfold.it  Thu Dec 10 17:25:03 2020
From: cage-dev at twistfold.it (cage)
Date: Thu, 10 Dec 2020 18:25:03 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <C9EBE9CE-2ED9-4EAA-ACFE-361144612273@gmail.com>
References: <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <C9EBE9CE-2ED9-4EAA-ACFE-361144612273@gmail.com>
Message-ID: <X9JZ7y8sluWNd7lo@kurosawa.casa.net>

On Thu, Dec 10, 2020 at 05:27:05PM +0100, Petite Abeille wrote:
>
>
> > On Dec 10, 2020, at 16:54, cage <cage-dev at twistfold.it> wrote:
> >
> > Internationalized  hostname  has  advantages  but  how  this  adding
> > complexity impact software author? Is this complexity needed?
>
> Ah, yes, le charme discret du r?gionalisme.
>
> It all boils down to the unmeasurable joy of Unicode ?
>
> > I have no answer, just would want to express some of my concerns.
>
> Archibald 'Harry' Tuttle had about 3 lines in Terry Gilliam's' Brazil:

One of my favourite movie! I  love the "retr? style" terminal shown in
the office! :)

Bye!
C.

From smallick.dev at gmail.com  Thu Dec 10 18:07:34 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Thu, 10 Dec 2020 23:37:34 +0530
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210163512.GA1390@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org> <20201210163512.GA1390@sources.org>
Message-ID: <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>

On 12/10/20, Stephane Bortzmeyer <stephane at sources.org> wrote:
> Opinion: may be we should specify a syntax for Gemini's robots.txt,
> not relying on the broken Web one?
Here it is:

'bots.txt' for gemini bots and crawlers.

- know who you are: archiver, indexer, feed-reader, researcher etc.
- ask for /bots.txt
- if 20 text/plain then
-- allowed = set()
-- denied = set()
-- split response by newlines, for each line
--- split by spaces and tabs into fields
---- paths = field[0] split by ','
---- if fields[2] is "allowed" and you in field[1] split by ',' then
allowed = allowed union paths
----- if field[3] is "but" and field[5] is "denied" and you in
field[4] split by ',' then denied = denied union paths
---- if fields[2] is "denied" and you in field[1] split by ',' then
denied = denied union paths
you always match all, never match none
union of paths is special:
    { "/a/b" } union { "/a/b/c" } ==> { "/a/b" }

when you request for path, find the longest match from allowed and
denied; if it is in allowed you're allowed, otherwise not;; when a
tie: undefined behaviour, do what you want.

examples:
default, effectively:
    / all allowed
or
    / none denied
complex example:
    /priv1,/priv2,/login all denied
    /cgi-bin indexer allowed but archiver denied
    /priv1/pub researcher allowed but blabla,meh,heh,duh denied

what do you think?

From cowan at ccil.org  Thu Dec 10 20:02:44 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 10 Dec 2020 15:02:44 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <X9JEzJQPK42PoSNl@kurosawa.casa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
Message-ID: <CAD2gp_R4SMmC8bdrY2padb7bSps9hxXFSw-Jhnqv+OohYHj0MA@mail.gmail.com>

On Thu, Dec 10, 2020 at 10:55 AM cage <cage-dev at twistfold.it> wrote:


> I have read most of the messages in this thread, i would just say that
> one  of  the  problems  with  WWW is  that  browser  are  getting  not
> manageable by a single user or a hobbyist programmer.
>

This is not strictly a Web issue: it is a DNS issue and affects all
protocols, including FTP, email, Gopher, etc.

> Probably many of you just thinking "who cares about CL?"
>

As a Schemer, I definitely do care about it.


> Internationalized  hostname  has  advantages  but  how  this  adding
> complexity impact software author? Is this complexity needed?
>

It's a balancing act between the needs of software authors and the needs of
content authors.  If Gemini succeeds, the latter will be much more common.
I think that internationalized link lines (which will have to become part
of the definition of text/gemini) are very important to authors.  Whether
clients accept IRIs in the address bar (or equivalent) is up to the client
author.  And I very strongly feel that changing the Gemini *protocol* to
pass IRIs serves nobody and shouldn't even be considered.


> PS: i am not a native English speaker (as you can see :-) )
>

Good.  As the saying is, if you want to know if there is antisemitism in a
particular place, ask the Jews who live there.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
I now introduce Professor Smullyan, who will prove to you that either
he doesn't exist or you don't exist, but you won't know which.
                               --Melvin Fitting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201210/38ec235c/attachment.htm>

From cowan at ccil.org  Thu Dec 10 21:09:19 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 10 Dec 2020 16:09:19 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <C9EBE9CE-2ED9-4EAA-ACFE-361144612273@gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <C9EBE9CE-2ED9-4EAA-ACFE-361144612273@gmail.com>
Message-ID: <CAD2gp_RMF6pMGJhDt4M7seAm5JJB=TG2xO21GeD8EymUM=d_Kw@mail.gmail.com>

On Thu, Dec 10, 2020 at 11:27 AM Petite Abeille <petite.abeille at gmail.com>
wrote:


> It all boils down to the unmeasurable joy of Unicode ?
>

As someone who is intimately familiar with i18n in the pre-Unicode era, I
can say that things were 100 times worse then.  Unicode is flawed because
it had to compromise with existing encodings, which is why we need
normalization.  But without that compromise (which permits 1-1
convertibility from almost all encodings to and from Unicode), it would
never have been so widely adopted.


> Perhaps Unicode should be abandoned altogether, and we all move back to to
> the original simplicity of ASCII.


Perhaps we should abandon all modern languages and just use Latin on the
Internet.

John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Gules six bars argent on a canton azure 50 mullets argent
six five six five six five six five and six
   --blazoning the U.S. flag <http://web.meson.org/blazonserver>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201210/69159af2/attachment-0001.htm>

From solene at perso.pw  Thu Dec 10 21:12:41 2020
From: solene at perso.pw (=?UTF-8?Q?Sol=C3=A8ne_Rapenne?=)
Date: Thu, 10 Dec 2020 22:12:41 +0100
Subject: Good practices regarding MIME type
Message-ID: <58075e0531c143f67902c9bfacc70f3a@perso.pw>

Hi,

I wrote a gemini server in C and I currently use an hardcoded list of 
file extensions <-> MIME type assocation.
This isn't great because it relies on file extension which can be wrong, 
but a file without extension would
use a default.

I chose to set a default text/gemini in case the extension is unknown or 
if the file has no extension.

What are the good practices to determine a file MIME type?

regards
Sol?ne

From cowan at ccil.org  Thu Dec 10 21:23:07 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 10 Dec 2020 16:23:07 -0500
Subject: Good practices regarding MIME type
In-Reply-To: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
Message-ID: <CAD2gp_T0nB7ZcPDNx51mj7pKpNcuM_vFNCNoJPkGr5VUWA_cNw@mail.gmail.com>

You can use the file(1) command or its library libmagic.  These are
excellent for binary files and support some text file formats, and are
extensible.  There are libmagic bindings for at least Perl, Python, Go,
Rust, Lua, Common Lisp, and Chicken Scheme.

On Thu, Dec 10, 2020 at 4:12 PM Sol?ne Rapenne <solene at perso.pw> wrote:

> Hi,
>
> I wrote a gemini server in C and I currently use an hardcoded list of
> file extensions <-> MIME type assocation.
> This isn't great because it relies on file extension which can be wrong,
> but a file without extension would
> use a default.
>
> I chose to set a default text/gemini in case the extension is unknown or
> if the file has no extension.
>
> What are the good practices to determine a file MIME type?
>
> regards
> Sol?ne
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201210/2452b843/attachment.htm>

From op at omarpolo.com  Thu Dec 10 21:26:05 2020
From: op at omarpolo.com (Omar Polo)
Date: Thu, 10 Dec 2020 22:26:05 +0100
Subject: Good practices regarding MIME type
In-Reply-To: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
Message-ID: <875z59z72q.fsf@omarpolo.com>


Sol?ne Rapenne <solene at perso.pw> writes:

> Hi,
>
> I wrote a gemini server in C and I currently use an hardcoded list of
> file extensions <-> MIME type assocation.
> This isn't great because it relies on file extension which can be
> wrong, but a file without extension would
> use a default.
>
> I chose to set a default text/gemini in case the extension is unknown
> or if the file has no extension.
>
> What are the good practices to determine a file MIME type?
>
> regards
> Sol?ne

I'm using the same approach in my server, but there are two alternatives
I know:

 - using /usr/share/misc/mime.types (still a list, but probably more
   complete than a manual one).  Don't know if it's widespread, but
   it's present in base on OpenBSD :)
 - using libmagic: it's a library to detect the MIME type by reading the
   file.  it powers the file(1) command on some unices.  The drawback is
   that it needs to open and read the file, whereas guessing from the
   extension doesn't.

From will at worrbase.com  Thu Dec 10 21:28:17 2020
From: will at worrbase.com (William Orr)
Date: Thu, 10 Dec 2020 21:28:17 +0000 (UTC)
Subject: Good practices regarding MIME type
In-Reply-To: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
Message-ID: <c43bd763-1b22-4a1c-a755-71084ff73c85@worrbase.com>

Hey,

Afaik, OpenBSD doesn't ship a libmagic implementation by default, but it does ship a version of file(1) as well as a magic(5) db that you can look at. If you look at the source of the file command, you might be able to work out how to make use of the file(5) db or just lift the code from there.

Alternatively, libmagic is in ports.

Hope that helps!

From solene at perso.pw  Thu Dec 10 21:29:13 2020
From: solene at perso.pw (=?UTF-8?Q?Sol=C3=A8ne_Rapenne?=)
Date: Thu, 10 Dec 2020 22:29:13 +0100
Subject: Good practices regarding MIME type
In-Reply-To: <875z59z72q.fsf@omarpolo.com>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
 <875z59z72q.fsf@omarpolo.com>
Message-ID: <578cd787bc570c1a5e08a24222a63219@perso.pw>

Le 2020-12-10 22:26, Omar Polo a ?crit?:
> Sol?ne Rapenne <solene at perso.pw> writes:
> 
>> Hi,
>> 
>> I wrote a gemini server in C and I currently use an hardcoded list of
>> file extensions <-> MIME type assocation.
>> This isn't great because it relies on file extension which can be
>> wrong, but a file without extension would
>> use a default.
>> 
>> I chose to set a default text/gemini in case the extension is unknown
>> or if the file has no extension.
>> 
>> What are the good practices to determine a file MIME type?
>> 
>> regards
>> Sol?ne
> 
> I'm using the same approach in my server, but there are two 
> alternatives
> I know:
> 
>  - using /usr/share/misc/mime.types (still a list, but probably more
>    complete than a manual one).  Don't know if it's widespread, but
>    it's present in base on OpenBSD :)
>  - using libmagic: it's a library to detect the MIME type by reading 
> the
>    file.  it powers the file(1) command on some unices.  The drawback 
> is
>    that it needs to open and read the file, whereas guessing from the
>    extension doesn't.

I already did use that exact mime.types file, but I hardcoded it. I will
take a look at file(1) code. I target OpenBSD first but I'll see if
it can be ported easily.

From cowan at ccil.org  Thu Dec 10 21:30:47 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 10 Dec 2020 16:30:47 -0500
Subject: Good practices regarding MIME type
In-Reply-To: <875z59z72q.fsf@omarpolo.com>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
 <875z59z72q.fsf@omarpolo.com>
Message-ID: <CAD2gp_Q6VvV4F1oXCMxg4+1Z-JuEijy9xs20BZVuDkEJsVYs2w@mail.gmail.com>

libmagic uses the local mime-types file(s) but is conditionalized to know
where they are on different operating systems, so it's better to use it,
even if it is not installed by default.

On Thu, Dec 10, 2020 at 4:26 PM Omar Polo <op at omarpolo.com> wrote:

>
> Sol?ne Rapenne <solene at perso.pw> writes:
>
> > Hi,
> >
> > I wrote a gemini server in C and I currently use an hardcoded list of
> > file extensions <-> MIME type assocation.
> > This isn't great because it relies on file extension which can be
> > wrong, but a file without extension would
> > use a default.
> >
> > I chose to set a default text/gemini in case the extension is unknown
> > or if the file has no extension.
> >
> > What are the good practices to determine a file MIME type?
> >
> > regards
> > Sol?ne
>
> I'm using the same approach in my server, but there are two alternatives
> I know:
>
>  - using /usr/share/misc/mime.types (still a list, but probably more
>    complete than a manual one).  Don't know if it's widespread, but
>    it's present in base on OpenBSD :)
>  - using libmagic: it's a library to detect the MIME type by reading the
>    file.  it powers the file(1) command on some unices.  The drawback is
>    that it needs to open and read the file, whereas guessing from the
>    extension doesn't.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201210/df9c7b33/attachment.htm>

From colecmac at protonmail.com  Thu Dec 10 21:31:12 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 10 Dec 2020 21:31:12 +0000
Subject: Good practices regarding MIME type
In-Reply-To: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
Message-ID: <NVkKvU8oJPFTwJxbdWRfxZOOeCf67XnMs70ilEqkRV2hAGqp0qlSCr6xfxdnbGh2eJIIq7qpJrD8EWmIexUxoh7sXEg_ll6a5MXFZLdHVmc=@protonmail.com>

> I chose to set a default text/gemini in case the extension is unknown or
> if the file has no extension.

This is not a good idea for any unrecognized file, extension or not. If you
know the file is UTF-8 text, serve it as "text/plain", otherwise you should
serve it as "application/octet-stream", indicating a generic binary file.

Jetforce used to default to text/plain for all files[1], and it was a problem
because clients will try to display binary data as text, resulting in garbled
data. For example, try running `cat /dev/urandom` and see how that looks.

1: https://github.com/michael-lazar/jetforce/issues/38#issuecomment-659688602


Cheers,
makeworld

P.S. The more accurate term is media type, not MIME type. See
https://www.iana.org/assignments/media-types/media-types.xhtml, or
just Wikipedia :)



From khuxkm at tilde.team  Thu Dec 10 21:44:50 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Thu, 10 Dec 2020 21:44:50 +0000
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201210134311.GA28808@sources.org>
References: <20201210134311.GA28808@sources.org>
 <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
Message-ID: <8bcb4b7117ce5f4ebe22b476146aec0a@tilde.team>

December 10, 2020 8:43 AM, "Stephane Bortzmeyer" <stephane at sources.org> wrote:

> - snip -
> 
> The spec is quite vague about the *order* of directives. For instance,
> <gemini://gempaper.strangled.net/robots.txt> is:
> 
> User-agent: *
> Disallow: /credentials.txt
> User-agent: archiver
> Disallow: /
> 
> The intented semantics is probably to disallow archivers but my parser
> regarded the site as available because it stopped at the first match,
> the star. Who is right?

Not you. The idea is that you start with the most direct User-Agent that applies to you (in this case, `archiver`), and then if that doesn't say you can't access the file, go up a level (in this case, `*`), and if *that* doesn't say you can't access the file, go up another level, and so on. If you run out of levels and haven't been told you can't access a file (or a parent directory of the file) then go ahead and access the file. In this case, a web proxy has no specific rules, so it would follow the `*` rule and not serve credentials.txt. However, an archiver *does* have specific rules: don't access anything, and so the archiver doesn't access anything.

An example in "A Standard For Robot Exclusion" (as archived by robotstxt.org[1]) uses an ordering like this and insinuates that the intent is to (in this case) allow `cybermapper` to access everything but block anyone else from accessing the cyberworld application:

```
# robots.txt for http://www.example.com/

User-agent: *
Disallow: /cyberworld/map/ # This is an infinite virtual URL space

# Cybermapper knows where to go.
User-agent: cybermapper
Disallow:
```

Just my 2 cents,
Robert "khuxkm" Miles

From sean at conman.org  Thu Dec 10 22:06:19 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 10 Dec 2020 17:06:19 -0500
Subject: Good practices regarding MIME type
In-Reply-To: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
Message-ID: <20201210220619.GG24194@brevard.conman.org>

It was thus said that the Great Sol?ne Rapenne once stated:
> Hi,
> 
> I wrote a gemini server in C and I currently use an hardcoded list of 
> file extensions <-> MIME type assocation.
> This isn't great because it relies on file extension which can be wrong, 
> but a file without extension would
> use a default.
> 
> I chose to set a default text/gemini in case the extension is unknown or 
> if the file has no extension.
> 
> What are the good practices to determine a file MIME type?

  For my server [1] you can configure a mapping of extensions to MIME type. 
If a file's extension isn't found in that mapping, then I use libmagic to
determine the MIME type.

  -spc

[1]	https://github.com/spc476/GLV-1.12556

From sean at conman.org  Fri Dec 11 00:35:01 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 10 Dec 2020 19:35:01 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201210091542.GA18084@sources.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
Message-ID: <20201211003501.GI24194@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Wed, Dec 09, 2020 at 10:25:40PM -0500,
>  Sean Conner <sean at conman.org> wrote 
>  a message of 53 lines which said:
> 
> >   And if it's so simple, why not do it? But I get it, you'd rather wait
> > until a yeah/nay decision is made.
> 
> It is reasonable to discuss it first because we need a *standard* way
> of doing it. Clients and servers must agree or there will be no
> interoperability.

  Okay,  Here's a IRI:

	gemini://caf?.mozz.us/files/?????.txt

  Please specify what a client and server MUST do to properly handle this.

  -spc

From lambdatronic at disroot.org  Fri Dec 11 01:12:04 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Thu, 10 Dec 2020 20:12:04 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201211003501.GI24194@brevard.conman.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org>
Message-ID: <87a6ul404b.fsf@disroot.org>

Sean Conner <sean at conman.org> writes:

>   Okay,  Here's a IRI:
>
> 	gemini://caf?.mozz.us/files/?????.txt
>
>   Please specify what a client and server MUST do to properly handle this.

Well, if I'm following all of these conversations correctly to date, I
believe the procedure looks like this:

1. Punycode the hostname.

2. Percent-encode reserved characters and non-US-ASCII characters in the
   path, query, and fragment components.

3. Make a DNS query with the punycoded hostname.

4. Send the punycode + percent-encoded URI as the request to the Gemini
   server.

5. The server parses the URI into scheme, host, port, path, query, and
   fragment components and then percent-decodes the path, query, and
   fragment strings.

6. The parsed and decoded URI information can then either be used to
   perform a file retrieval, generate a directory listing, or run a CGI
   script, ultimately sending back a valid Gemini response to the
   client. Redirect responses should make sure to percent-encode the
   path, query, and fragment components of the redirected URI.

My Gemini server (Space Age) handles steps 5 and 6 as described here (as
I suspect most Gemini servers do). Clients should already be performing
step 2 as per the Gemini spec.

I suspect the missing piece of the puzzle here is *just* having client
authors implement steps 1, 3, and 4 (for some definition of "just"). I
don't think these client changes would require any changes to the
current Gemini spec.

There is also the open question of whether servers should convert
punycoded hostnames back into unicode hostnames for the purposes of
virtual hosting (either via SNI or post-handshake). Since at least one
poster has indicated that the widespread unevenness in DNS support for
unicode has lead to the need to store A records in their punycoded form,
this suggests to me that virtual hosting may be performed most
universally by just directly matching the received punycoded domain
names.

Of course, YMMV.

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From cowan at ccil.org  Fri Dec 11 02:45:55 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 10 Dec 2020 21:45:55 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87a6ul404b.fsf@disroot.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
Message-ID: <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>

On Thu, Dec 10, 2020 at 8:12 PM Gary Johnson <lambdatronic at disroot.org>
wrote:

1. Punycode the hostname.
>

If there is one.  You can look for "//" on the left and the next "/" on the
right, so you don't need full parsing.

> 2. Percent-encode reserved characters and non-US-ASCII characters in the
>    path, query, and fragment components.
>

You don't want to escape the ASCII reserved characters, because they should
already be escaped.  Changing the path /foo/bar.gmi to %25foo%25bar.gmi
would be Evil and Wrong.  If you really want that path, you have to encode
it yourself.

In addition, you can safely %-encode the whole IRI reference without
parsing it, since Punycode names are always safe.
2.5. If the IRI is a relative reference, resolve it against the URI of the
text/gemini file that contains it.

3. Make a DNS query with the punycoded hostname.
>
> 4. Send the punycode + percent-encoded URI as the request to the Gemini
>    server.
>

Note that fragments must not be sent, so if there is one, chop it off.


> 5. The server parses the URI into scheme, host, port, path, query, and
>    fragment components and then percent-decodes the path, query, and
>    fragment strings.
>

Consequently, the server will not get a fragment string.  There would be no
need for fragment strings if they were understood on the server side;
they'd just be part of the path.

Whether it %-decodes or not is up to the server.  If it's serving a
conventional file system, then it needs to document whether it does such
decoding.  If it isn't, it can do whatever it wants to with the paths.


>  6. The parsed and decoded URI information can then either be used to

   perform a file retrieval, generate a directory listing, or run a CGI
>    script, ultimately sending back a valid Gemini response to the
>    client. Redirect responses should make sure to percent-encode the
>    path, query, and fragment components of the redirected URI.
>

Except not the fragment.

> Since at least one
> poster has indicated that the widespread unevenness in DNS support for
> unicode has lead to the need to store A records in their punycoded form,
>

Indeed, I don't think that any registrar using the standard DNS root will
even register non-punycoded names.  MS Active Directory DNS servers are
another story.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201210/33b59f84/attachment.htm>

From colecmac at protonmail.com  Fri Dec 11 03:00:59 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 11 Dec 2020 03:00:59 +0000
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87a6ul404b.fsf@disroot.org>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
Message-ID: <emVnXZL--ERdzoT0Delh7ItBUPK3QyKv7KsIIOlXlN2Mu862rbdyxteEx7qRFs7Hl-9VlZP6-dAnx1f_hkQtOaKDV53-73T4HMNBb6PgHao=@protonmail.com>

> 4.  Send the punycode + percent-encoded URI as the request to the Gemini
>     server.

This probably makes sense since IRIs aren't being used. I originally
advocated for sending Unicode to the server, for the domain only, but that's
just a weird mix isn't it.

Good server software should be taking the admin's hostname input (from config)
and punycoding it though, so that the admin can enter the Unicode domain name
and not have to worry. Obviously this is outside of the spec, but I think
it's a good thing to implement.


makeworld

From will at worrbase.com  Fri Dec 11 06:07:38 2020
From: will at worrbase.com (William Orr)
Date: Fri, 11 Dec 2020 06:07:38 +0000 (UTC)
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
 <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>
Message-ID: <39da4f03-d8dd-446c-9a85-92b8671efd92@worrbase.com>

Before percent-encoding/punycoding, the URI needs to be NFC normalized.

As a matter of course, I'd say that servers should normalize the path before doing fs lookups/proxying it as well.

From stephane at sources.org  Fri Dec 11 08:20:25 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 09:20:25 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <67E2BFB7-1D5C-405D-9B31-778E06E91EA8@gmail.com>
References: <20201208133656.GA17700@sources.org>
 <20201208145840.5738718e@kongroo.lan>
 <67E2BFB7-1D5C-405D-9B31-778E06E91EA8@gmail.com>
Message-ID: <20201211082025.GA5933@sources.org>

On Tue, Dec 08, 2020 at 03:05:42PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 14 lines which said:

> Like so?
> 
> gemini://example.com/robots.txt?user-agent=DetailsOfTheRobot ?

Good idea, this is what I do now.



From stephane at sources.org  Fri Dec 11 08:26:54 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 09:26:54 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
 <20201210163512.GA1390@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
Message-ID: <20201211082654.GB5933@sources.org>

On Thu, Dec 10, 2020 at 11:37:34PM +0530,
 Sudipto Mallick <smallick.dev at gmail.com> wrote 
 a message of 40 lines which said:

> 'bots.txt' for gemini bots and crawlers.

Interesting. The good thing is that it moves away from robots.txt
(underspecified, full of variants, impossible to know what a good bot
should do).

> - know who you are: archiver, indexer, feed-reader, researcher etc.
> - ask for /bots.txt
> - if 20 text/plain then
> -- allowed = set()
> -- denied = set()
> -- split response by newlines, for each line
> --- split by spaces and tabs into fields
> ---- paths = field[0] split by ','
> ---- if fields[2] is "allowed" and you in field[1] split by ',' then
> allowed = allowed union paths
> ----- if field[3] is "but" and field[5] is "denied" and you in
> field[4] split by ',' then denied = denied union paths
> ---- if fields[2] is "denied" and you in field[1] split by ',' then
> denied = denied union paths
> you always match all, never match none
> union of paths is special:
>     { "/a/b" } union { "/a/b/c" } ==> { "/a/b" }
> 
> when you request for path, find the longest match from allowed and
> denied; if it is in allowed you're allowed, otherwise not;; when a
> tie: undefined behaviour, do what you want.

It seems perfect.


From stephane at sources.org  Fri Dec 11 08:46:47 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 09:46:47 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <8bcb4b7117ce5f4ebe22b476146aec0a@tilde.team>
References: <20201210134311.GA28808@sources.org>
 <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <8bcb4b7117ce5f4ebe22b476146aec0a@tilde.team>
Message-ID: <20201211084647.GC5933@sources.org>

On Thu, Dec 10, 2020 at 09:44:50PM +0000,
 Robert "khuxkm" Miles <khuxkm at tilde.team> wrote 
 a message of 24 lines which said:

> Not you. The idea is that you start with the most direct User-Agent
> that applies to you (in this case, `archiver`), and then if that
> doesn't say you can't access the file, go up a level (in this case,
> `*`),

Reasonable interpretation (more-specific to less-specific). Too bad
the "standard" is so vague.

From stephane at sources.org  Fri Dec 11 08:57:02 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 09:57:02 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <X9JEzJQPK42PoSNl@kurosawa.casa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
Message-ID: <20201211085702.GA7129@sources.org>

On Thu, Dec 10, 2020 at 04:54:52PM +0100,
 cage <cage-dev at twistfold.it> wrote 
 a message of 44 lines which said:

> Adding more complexity and more responsibility to software authors
> will shrink diversity in the gemini software landscape.

The idea is that it will not be done by the programmer (Unicode is
complicated) of the Gemini client but mostly by the libraries she or
he uses. It is the same with TLS: TLS is very complicated but most
people do not program it by themselves (and rightly so).

> Internationalized  hostname  has  advantages  but  how  this  adding
> complexity impact software author? Is this complexity needed?

Since I write Gemini clients, I have sympathy for this point of
view. However, let me quote RFC 8890

=> gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8890.txt

4.5.  Deprioritizing Internal Needs

   There are several needs that are very visible to us as specification
   authors but should explicitly not be prioritized over the needs of
   end users.

   These include convenience for document editors, IETF process matters,
   and "architectural purity" for its own sake.


=> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies See aso this statement by W3C

From stephane at sources.org  Fri Dec 11 09:00:43 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 10:00:43 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAD2gp_RMF6pMGJhDt4M7seAm5JJB=TG2xO21GeD8EymUM=d_Kw@mail.gmail.com>
References: <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <C9EBE9CE-2ED9-4EAA-ACFE-361144612273@gmail.com>
 <CAD2gp_RMF6pMGJhDt4M7seAm5JJB=TG2xO21GeD8EymUM=d_Kw@mail.gmail.com>
Message-ID: <20201211090043.GB7129@sources.org>

On Thu, Dec 10, 2020 at 04:09:19PM -0500,
 John Cowan <cowan at ccil.org> wrote 
 a message of 76 lines which said:

> Unicode is flawed because it had to compromise with existing
> encodings,

And also because human scripts (and languages) are a mess and Unicode
choosed, a long time ago, to deal with it instead of whining "why
can't they just speak english?"

> Perhaps we should abandon all modern languages and just use Latin on the
> Internet.

=> https://en.wikipedia.org/wiki/Lojban No, Lojban

From stephane at sources.org  Fri Dec 11 09:04:44 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 10:04:44 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87a6ul404b.fsf@disroot.org>
References: <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org>
 <87a6ul404b.fsf@disroot.org>
Message-ID: <20201211090444.GC7129@sources.org>

On Thu, Dec 10, 2020 at 08:12:04PM -0500,
 Gary Johnson <lambdatronic at disroot.org> wrote 
 a message of 69 lines which said:

> 1. Punycode the hostname.

Not always, for the reasons explained in RFC 6055. To summarize: the
application does not always know which name resolution system will be used.

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc6055.txt

> 3. Make a DNS query with the punycoded hostname.

Most applications don't do DNS queries, both because DNS is
complicated and because there are other name resolutions system. They
call a system routine (getaddrinfo() in C) to do the resolution.

> There is also the open question of whether servers should convert
> punycoded hostnames back into unicode hostnames for the purposes of
> virtual hosting (either via SNI or post-handshake). Since at least one
> poster has indicated that the widespread unevenness in DNS support for
> unicode has lead to the need to store A records in their punycoded form,
> this suggests to me that virtual hosting may be performed most
> universally by just directly matching the received punycoded domain
> names.

This is what Apache and Nginx do in the Web world (which does not mean
they are right).

From stephane at sources.org  Fri Dec 11 09:09:00 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 10:09:00 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>
References: <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org>
 <87a6ul404b.fsf@disroot.org>
 <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>
Message-ID: <20201211090859.GD7129@sources.org>

On Thu, Dec 10, 2020 at 09:45:55PM -0500,
 John Cowan <cowan at ccil.org> wrote 
 a message of 177 lines which said:

> Indeed, I don't think that any registrar using the standard DNS root
> will even register non-punycoded names.

Counter-example about a similar case: the registry of .ws accepts
names with emojis, which are forbidden by the standard (because they
are symbols, not letters). So, anything can happen.

=> https://www.worldsite.ws/idn/emoji.dhtml?sponsor=index.dhtml And they boast about it

(Also, not all name registration goes through a registrar: when I edit
bortzmeyer.org, I can add what I want without any intermediary.)

From linde.philip at gmail.com  Fri Dec 11 09:41:37 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Fri, 11 Dec 2020 10:41:37 +0100
Subject: Good practices regarding MIME type
In-Reply-To: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
Message-ID: <20201211104137.1b6d88875a03a9428cc2e65f@gmail.com>

On Thu, 10 Dec 2020 22:12:41 +0100
Sol?ne Rapenne <solene at perso.pw> wrote:

> Hi,
> 
> I wrote a gemini server in C and I currently use an hardcoded list of 
> file extensions <-> MIME type assocation.
> This isn't great because it relies on file extension which can be wrong, 
> but a file without extension would
> use a default.
> 
> I chose to set a default text/gemini in case the extension is unknown or 
> if the file has no extension.
> 
> What are the good practices to determine a file MIME type?

There is no way that will work completely reliably without implementing
full parsers of the different file types. For a complete server I'd
expect to be able to determine file type for a certain served resource
myself without relying on an extension-type mapping. For example, to be
able to say that every file under /text/ is text/plain.

John Cowan suggests libmagic and file. AFAIK utilities/libraries like
this can operate using matching rules on some-few bytes of a file to
determine the file type with a limited degree of accuracy

I suggest a procedure like this to determine the file type:

1. Check if there is a configuration rule for this particular file to
   determine its file type. If so, use that.
2. If there is not, check if the server extension-type mapping
   configuration contains the file extension. If so, use that.
3. If there is not, check the system level mime type database if there
   is a type assigned to the extension. If so, use that.
4. If there is not, you can now optionally use some heuristic approach
   to determine the file type. This can be via a library like
   libmagic, or a simpler approach as suggested by makeworld to
   determine whether you can defer to text/plain or not. If so, use
   that.
5. If not, assume application/octet-stream and use that.

You could cache the results in memory and drop the cache on e.g. SIGHUP

As for extension-less files, if you don't want extensions visible to
the client, you can still use extensions on the server side, which the
server optionally strips off.

Overall I think it's fair to expect some level of effort from the
server operator in making sure that the static files have sensible
extensions. Any smartness beyond extension mapping is at best a bonus
AFAIC, at worst a potentially nasty surprise.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201211/818212f4/attachment-0001.sig>

From cage-dev at twistfold.it  Fri Dec 11 09:47:13 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 11 Dec 2020 10:47:13 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201211085702.GA7129@sources.org>
References: <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <20201211085702.GA7129@sources.org>
Message-ID: <X9NAIRiKEPomfeUy@kurosawa.casa.net>

On Fri, Dec 11, 2020 at 09:57:02AM +0100, Stephane Bortzmeyer wrote:

Hi!

> On Thu, Dec 10, 2020 at 04:54:52PM +0100,
>  cage <cage-dev at twistfold.it> wrote
>  a message of 44 lines which said:
>
> > Adding more complexity and more responsibility to software authors
> > will shrink diversity in the gemini software landscape.
>
> The idea is that it will not be done by the programmer (Unicode is
> complicated) of the Gemini client but mostly by the libraries she or
> he uses.

If such library does exists, otherwise  more and more works is needed,
and this will exclude the programmers  that have no time or skills (to
me very likely the former) to do the all the work.

> It is the same with TLS: TLS is very complicated but most
> people do not program it by themselves (and rightly so).

This  is matter  of  balance,  the advantages  of  TLS  are worth  the
complexity added, IDN? I am not sure.

> > Internationalized  hostname  has  advantages  but  how  this  adding
> > complexity impact software author? Is this complexity needed?
>
> Since I write Gemini clients, I have sympathy for this point of
> view. However, let me quote RFC 8890

OK the point is  valid to me, for TLS, but not for  IDN. Anyway i have
the impression i am in a minority  here, and i think i should start to
do a minimal wrapping of libidn at this point. :-)

Bye!
C.

From cage-dev at twistfold.it  Fri Dec 11 09:58:15 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 11 Dec 2020 10:58:15 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAD2gp_R4SMmC8bdrY2padb7bSps9hxXFSw-Jhnqv+OohYHj0MA@mail.gmail.com>
References: <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <CAD2gp_R4SMmC8bdrY2padb7bSps9hxXFSw-Jhnqv+OohYHj0MA@mail.gmail.com>
Message-ID: <X9NCt2YuMAC+fHFA@kurosawa.casa.net>

On Thu, Dec 10, 2020 at 03:02:44PM -0500, John Cowan wrote:

Hi!

> On Thu, Dec 10, 2020 at 10:55 AM cage <cage-dev at twistfold.it> wrote:
>
>
> > I have read most of the messages in this thread, i would just say that
> > one  of  the  problems  with  WWW is  that  browser  are  getting  not
> > manageable by a single user or a hobbyist programmer.
> >
>
> This is not strictly a Web issue: it is a DNS issue and affects all
> protocols, including FTP, email, Gopher, etc.

Correct, i meant  that this is a client issue  deriving from debatable
choices.

> > Probably many of you just thinking "who cares about CL?"
> >
>
> As a Schemer, I definitely do care about it.

[OT] Nice! Do  yo have a preferred  dialect? I like Guile a  lot but i
fear i  end missing CLOS  (GOOPS is  not the same,  unfortunately) and
condition system.

>
> > Internationalized  hostname  has  advantages  but  how  this  adding
> > complexity impact software author? Is this complexity needed?
> >
>
> It's a balancing act between the needs of software authors and the needs of
> content authors.  If Gemini succeeds, the latter will be much more common.
> I think that internationalized link lines (which will have to become part
> of the definition of text/gemini) are very important to authors.  Whether
> clients accept IRIs in the address bar (or equivalent) is up to the client
> author.  And I very strongly feel that changing the Gemini *protocol* to
> pass IRIs serves nobody and shouldn't even be considered.

I agree!  My only concerns is  i have the impression  that client that
will  not supports  IRI will  be second  class citizen  in the  gemini
space, and they will die slowly.

So i think that IRI will be a de facto standard. :/

Bye!
C.

From come at chilliet.eu  Fri Dec 11 10:18:00 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Fri, 11 Dec 2020 11:18:00 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201211082654.GB5933@sources.org>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org>
Message-ID: <803842604.RZAbtYdCJc@tempete>

Le vendredi 11 d?cembre 2020, 09:26:54 CET Stephane Bortzmeyer a ?crit :
> > - know who you are: archiver, indexer, feed-reader, researcher etc.
> > - ask for /bots.txt
> > - if 20 text/plain then
> > -- allowed = set()
> > -- denied = set()
> > -- split response by newlines, for each line
> > --- split by spaces and tabs into fields
> > ---- paths = field[0] split by ','
> > ---- if fields[2] is "allowed" and you in field[1] split by ',' then
> > allowed = allowed union paths
> > ----- if field[3] is "but" and field[5] is "denied" and you in
> > field[4] split by ',' then denied = denied union paths
> > ---- if fields[2] is "denied" and you in field[1] split by ',' then
> > denied = denied union paths
> > you always match all, never match none
> > union of paths is special:
> >     { "/a/b" } union { "/a/b/c" } ==> { "/a/b" }
> > 
> > when you request for path, find the longest match from allowed and
> > denied; if it is in allowed you're allowed, otherwise not;; when a
> > tie: undefined behaviour, do what you want.
> 
> It seems perfect.

I guess I?m not the only one needing some examples to fully understand how this would work?

If I get it it?s something like so:
path1,path2 archiver,crawler allowed but path3 denied
path4 * denied



From stephane at sources.org  Fri Dec 11 10:16:05 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 11:16:05 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
 <20201210163512.GA1390@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
Message-ID: <20201211101605.GA9357@sources.org>

On Thu, Dec 10, 2020 at 11:37:34PM +0530,
 Sudipto Mallick <smallick.dev at gmail.com> wrote 
 a message of 40 lines which said:

> - ask for /bots.txt

Speaking of this, I suggest it could be better to have a /.well-known
(or equivalent) to put all these "meta" files. The Web does it (RFC
5785) and it's cool since it avoids colliding with "real"
resources. (Also, crawling the geminispace shows strange robots.txt
which are probably "wildcards" or "catchall", created by a program
which replies for every possible path. Having a /.well-known would
allow to define an exception.)

It requires no change in clients (except bots) or servers, it is just
a convention.

=> gemini://gemini.bortzmeyer.org/rfc-mirror/rfc5785.txt RFC 5785 "Defining Well-Known URIs"

Meta-remark: is there a place with all the "Gemini good practices" or
"Gemini conventions", which do not change the protocol or the format
but are useful?

From petite.abeille at gmail.com  Fri Dec 11 10:25:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 11 Dec 2020 11:25:31 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201211101605.GA9357@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
 <20201210163512.GA1390@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211101605.GA9357@sources.org>
Message-ID: <B4AFCA95-C4AF-4A49-B6C8-1B5251CCF19D@gmail.com>



> On Dec 11, 2020, at 11:16, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
>  I suggest it could be better to have a /.well-known

+1 for the /.well-known convention.

This was mentioned several time previously, but inertia is strong with that one. Go figure.

From stephane at sources.org  Fri Dec 11 10:27:42 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 11:27:42 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <803842604.RZAbtYdCJc@tempete>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org> <803842604.RZAbtYdCJc@tempete>
Message-ID: <20201211102742.GA10716@sources.org>

On Fri, Dec 11, 2020 at 11:18:00AM +0100,
 C?me Chilliet <come at chilliet.eu> wrote 
 a message of 33 lines which said:

> I guess I?m not the only one needing some examples to fully understand how this would work?

There were examples at the end of the original message.

From stephane at sources.org  Fri Dec 11 10:31:53 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 11 Dec 2020 11:31:53 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <B4AFCA95-C4AF-4A49-B6C8-1B5251CCF19D@gmail.com>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain>
 <20201210134311.GA28808@sources.org>
 <20201210163512.GA1390@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211101605.GA9357@sources.org>
 <B4AFCA95-C4AF-4A49-B6C8-1B5251CCF19D@gmail.com>
Message-ID: <20201211103153.GB10716@sources.org>

On Fri, Dec 11, 2020 at 11:25:31AM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 11 lines which said:

> This was mentioned several time previously, but inertia is strong
> with that one. Go figure.

This is one of the interesting things with Gemini: it is a social
experience, more than a technical one. I love observing how Gemini
governance works (or fails).


From petite.abeille at gmail.com  Fri Dec 11 10:54:44 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 11 Dec 2020 11:54:44 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201211103153.GB10716@sources.org>
References: <20201208133656.GA17700@sources.org>
 <X8+SHYMaq2V/625D@goldfish.localdomain> <20201210134311.GA28808@sources.org>
 <20201210163512.GA1390@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211101605.GA9357@sources.org>
 <B4AFCA95-C4AF-4A49-B6C8-1B5251CCF19D@gmail.com>
 <20201211103153.GB10716@sources.org>
Message-ID: <7EF2C893-3EA7-439A-B652-9A95156D7A89@gmail.com>



> On Dec 11, 2020, at 11:31, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> This is one of the interesting things with Gemini: it is a social
> experience, more than a technical one. I love observing how Gemini
> governance works (or fails).

Huis clos meets Lord of the Flies? :D

From come at chilliet.eu  Fri Dec 11 10:59:59 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Fri, 11 Dec 2020 11:59:59 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201211101605.GA9357@sources.org>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211101605.GA9357@sources.org>
Message-ID: <2726552.I94GnHpBYK@tempete>

Le vendredi 11 d?cembre 2020, 11:16:05 CET Stephane Bortzmeyer a ?crit :
> Meta-remark: is there a place with all the "Gemini good practices" or
> "Gemini conventions", which do not change the protocol or the format
> but are useful?

Some are listed in gemini://gemini.circumlunar.space/docs/

So I?d expect this page to regroup all validated specifications, and best/common practices/conventions.

I also started gemini://gemlog.lanterne.chilliet.eu/specifications.en.gmi to list actual specifications and proposals without mixing them with best practice documents.

C?me



From smallick.dev at gmail.com  Fri Dec 11 12:57:28 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Fri, 11 Dec 2020 18:27:28 +0530
Subject: Crawlers on Gemini and best practices
In-Reply-To: <803842604.RZAbtYdCJc@tempete>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org> <803842604.RZAbtYdCJc@tempete>
Message-ID: <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>

what i wrote was a rough algorithm, now here is a human readable
description for bots.txt:

every line has the following format:

    <paths> <bots> ("allowed" | "denied")
OR
    <paths> <bots> "allowed" "but" <bots> "denied"
<paths> is comma seperated paths to be allowed or denied
<bots> is comma seperated bot ''descriptors'' (think of better word
for this) matching [A-Za-z][A-Za-z0-9_-]*
* the paths should not contain comma or spaces, percent encode if that
is the case
* word in "quotes" is written literally without the quotes
* every field is seperated by whitespace i.e. [ \t]+

an ideal bot creates a set of allowed and denied paths for it from its
real and virtual user agent and the "all" group.
before requesting for a path, this ideal bot finds the longest match
from both the allowed and denied path sets. if the longest match is
from the allowed set, it proceeds to request that path. if both sets
have the longest match, then follow the most specific match of the
"descriptor" (name of bot > virtual agent > "all")
for example:

    /a,/p all denied
    /a/b,/p/q indexer,researcher allowed
    /a/b/c researcher denied
    /a/b/c heh allowed

now the researcher 'heh' may access /p/q/* and and /a/b/c and it may
not access /a/b/{X} when {X} != 'c'
other researchers may only access /p/q and /a/b/{Z} when {Z} != 'c' so
they may not access /a/b/c
indexers may access /a/b and /p/q
* real bots would try to behave as close as possible to the ideal bot

Q. do we need to support comments in bots.txt

From smallick.dev at gmail.com  Fri Dec 11 13:15:42 2020
From: smallick.dev at gmail.com (Sudipto Mallick)
Date: Fri, 11 Dec 2020 18:45:42 +0530
Subject: Crawlers on Gemini and best practices
In-Reply-To: <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org> <803842604.RZAbtYdCJc@tempete>
 <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>
Message-ID: <CAFaUHvJ7Pyrr+QgytM7sHMuYs1nrH9QVS5Wx5OnBsN392uuZJw@mail.gmail.com>

> for example:
>
>     /a,/p all denied
>     /a/b,/p/q indexer,researcher allowed
>     /a/b/c researcher denied
>     /a/b/c heh allowed
>
now the researcher 'heh' may access /p/q/* and and /a/b/*
> and it may not access /a/b/{X} when {X} != 'c'
err. sorry. that should be: may not access /a/{X} when {X} != 'b' and
/p/{Y} when {Y} != 'q' (for all indexers and researchers, hmm.)
every one other that researchers and indexers may not access /a/* and /p/*

> other researchers may only access /p/q and /a/b/{Z} when {Z} != 'c' so
> they may not access /a/b/c
indexers may access /a/b/* and /p/q/*
ah.

From glenda at typed-hole.org  Fri Dec 11 12:30:51 2020
From: glenda at typed-hole.org (glenda at typed-hole.org)
Date: Fri, 11 Dec 2020 13:30:51 +0100
Subject: [ANN] Castor9 gemini browser for Plan 9
Message-ID: <D7FA53453DA2E3E8E8C124C91D90DCB8@typed-hole.org>

Hello geminauts,
I made another Gemini browser but this time for Plan 9/9front.
Named it Castor9 because I felt very inspired :)
It's just a basic browser at the moment but more features should come.

You can get it:
- on sourcehut https://git.sr.ht/~julienxx/castor9
- on shithub.us http://shithub.us/git/julienxx/castor9/HEAD/info.html
- via 9p `9fs 9til.de`

Cheers,

From julien at typed-hole.org  Fri Dec 11 12:36:27 2020
From: julien at typed-hole.org (julien at typed-hole.org)
Date: Fri, 11 Dec 2020 13:36:27 +0100
Subject: [ANN] Castor9 gemini browser for Plan 9
Message-ID: <DFC8D234DF2BD50A04B9032A61150695@typed-hole.org>

(Sorry if this comes twice I think I messed up the first mail so sending again)

Hello geminauts,
I made another Gemini browser but this time for Plan 9/9front.
Named it Castor9 because I felt very inspired :)
It's just a basic browser at the moment but more features should come.

You can get it:
- on sourcehut https://git.sr.ht/~julienxx/castor9
- on shithub.us http://shithub.us/git/julienxx/castor9/HEAD/info.html
- via 9p `9fs 9til.de`

Cheers,
julienxx


From jmcbray at carcosa.net  Fri Dec 11 14:18:37 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 11 Dec 2020 09:18:37 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <emVnXZL--ERdzoT0Delh7ItBUPK3QyKv7KsIIOlXlN2Mu862rbdyxteEx7qRFs7Hl-9VlZP6-dAnx1f_hkQtOaKDV53-73T4HMNBb6PgHao=@protonmail.com>
 (colecmac@protonmail.com's message of "Fri, 11 Dec 2020 03:00:59 +0000")
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
 <emVnXZL--ERdzoT0Delh7ItBUPK3QyKv7KsIIOlXlN2Mu862rbdyxteEx7qRFs7Hl-9VlZP6-dAnx1f_hkQtOaKDV53-73T4HMNBb6PgHao=@protonmail.com>
Message-ID: <87k0tobf42.fsf@cassilda.carcosa.net>

colecmac at protonmail.com writes:

> Good server software should be taking the admin's hostname input (from config)
> and punycoding it though, so that the admin can enter the Unicode domain name
> and not have to worry. Obviously this is outside of the spec, but I think
> it's a good thing to implement.

To implement, *and* to document ? if not in the spec, then in a 'best
practices for implementers' document.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Fri Dec 11 14:21:23 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 11 Dec 2020 09:21:23 -0500
Subject: Good practices regarding MIME type
In-Reply-To: <20201210220619.GG24194@brevard.conman.org> (Sean Conner's
 message of "Thu, 10 Dec 2020 17:06:19 -0500")
References: <58075e0531c143f67902c9bfacc70f3a@perso.pw>
 <20201210220619.GG24194@brevard.conman.org>
Message-ID: <87ft4cbezg.fsf@cassilda.carcosa.net>

Sean Conner <sean at conman.org> writes:

>   For my server [1] you can configure a mapping of extensions to MIME
> type. If a file's extension isn't found in that mapping, then I use
> libmagic to determine the MIME type.

My server (Germinal) does the same thing, largely because that's what
the MIME library I'm using does by default.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From easrng at gmail.com  Fri Dec 11 16:04:31 2020
From: easrng at gmail.com (A. E. Spencer-Reed)
Date: Fri, 11 Dec 2020 11:04:31 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201211090859.GD7129@sources.org>
References: <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
 <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>
 <20201211090859.GD7129@sources.org>
Message-ID: <CAEzvDCXx5bRfdfK6hFSQFFN6dPfygsriCxx9epeUBzdWa+Lz7A@mail.gmail.com>

On Fri, Dec 11, 2020 at 4:13 AM Stephane Bortzmeyer
<stephane at sources.org> wrote:
> Counter-example about a similar case: the registry of .ws accepts
> names with emojis, which are forbidden by the standard (because they
> are symbols, not letters). So, anything can happen.
However, those names are still punycoded. Most registries will not
accept punycoded emojis, but .ws does.

From lambdatronic at disroot.org  Fri Dec 11 18:32:21 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 11 Dec 2020 13:32:21 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
 <20201209052651.GY24194@brevard.conman.org>
 <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
 <CAD2gp_TTxOAzao2PFN52c9GHntQjnFTjm0syBd_EMK1F92fiBA@mail.gmail.com>
Message-ID: <874kksqjm2.fsf@disroot.org>

John Cowan <cowan at ccil.org> writes:

>> 2. Percent-encode reserved characters and non-US-ASCII characters in the
>>    path, query, and fragment components.

> You don't want to escape the ASCII reserved characters, because they should
> already be escaped.  Changing the path /foo/bar.gmi to %25foo%25bar.gmi
> would be Evil and Wrong.  If you really want that path, you have to encode
> it yourself.

Yes, that is quite right. I suppose we are using a different
interpretation of the phrase "reserved characters" here. For clarity, I
meant characters such as those in the string " ?#", which are either
forbidden (when unencoded) within the path, query, and fragment
components or are used to delimit them.

> 2.5. If the IRI is a relative reference, resolve it against the URI of the
> text/gemini file that contains it.

Yep.

>> 4. Send the punycode + percent-encoded URI as the request to the Gemini
>>    server.
>
> Note that fragments must not be sent, so if there is one, chop it off.

I'm not sure that is the case here. To quote the Gemini spec:

========================================================================
1.2 Gemini URI scheme

Resources hosted via Gemini are identified using URIs with the scheme
"gemini". This scheme is syntactically compatible with the generic URI
syntax defined in RFC 3986, but does not support all components of the
generic syntax. In particular, the authority component is allowed and
required, but its userinfo subcomponent is NOT allowed. The host
subcomponent is required. The port subcomponent is optional, with a
default value of 1965. The path, query and fragment components are
allowed and have no special meanings beyond those defined by the generic
syntax. Spaces in gemini URIs should be encoded as %20, not +.
========================================================================

Please note the text about fragment components being allowed. I'm not
currently aware of any good uses for them in Gemini, but the spec
supports them, so I've included that support in my server.

>> 5. The server parses the URI into scheme, host, port, path, query, and
>>    fragment components and then percent-decodes the path, query, and
>>    fragment strings.
>
> Consequently, the server will not get a fragment string.  There would be no
> need for fragment strings if they were understood on the server side;
> they'd just be part of the path.

See above.

>>  6. The parsed and decoded URI information can then either be used to
>>     perform a file retrieval, generate a directory listing, or run a
>>     CGI script, ultimately sending back a valid Gemini response to
>>     the client. Redirect responses should make sure to percent-encode
>>     the path, query, and fragment components of the redirected URI.
>>
>
> Except not the fragment.

Again, see above.

Yada yada...spec compliance...yada yada.

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From colecmac at protonmail.com  Fri Dec 11 20:38:12 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 11 Dec 2020 20:38:12 +0000
Subject: Crawlers on Gemini and best practices
In-Reply-To: <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org> <803842604.RZAbtYdCJc@tempete>
 <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>
Message-ID: <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>

(Sorry if this is the wrong place to reply.)

Why are we defining new standards and filenames? bots.txt, .well-know, etc.
We don't need this.

Gemini is based around the idea of radical familiarity. Creating a new robots
standard breaks that, and makes things more complicated. There are existing
complete robots.txt standards, are there not? I admit I'm not well-versed in
this, but let's just pick a standard that works and make it offical.

After doing some quick research, I found that Google has submitted a draft
spec for robots.txt to the IETF. The original draft was submitted on July 07,
2019, and the most recent draft was submitted ~3 days ago, on the 8th.

https://developers.google.com/search/reference/robots_txt
https://tools.ietf.org/html/draft-koster-rep-04

I am no big fan of Google, but they are the kings of crawling and it makes sense
to go with them here.

The spec makes many example references to HTTP, but note that it is fully
protocol-agnostic, so it works fine for Gemini.


makeworld

From colecmac at protonmail.com  Fri Dec 11 20:49:45 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Fri, 11 Dec 2020 20:49:45 +0000
Subject: Some reading on IRIs and IDNs
In-Reply-To: <X9NCt2YuMAC+fHFA@kurosawa.casa.net>
References: <20201209052651.GY24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org> <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <CAD2gp_R4SMmC8bdrY2padb7bSps9hxXFSw-Jhnqv+OohYHj0MA@mail.gmail.com>
 <X9NCt2YuMAC+fHFA@kurosawa.casa.net>
Message-ID: <miHm0gJWpGYRghNPXdE6bkAE9C1I-UbM_d0ax0yU3UB_cWmL8pORwzRyotxJGy_VmE6c93bly_wZ3HWEJHcqKqzX6jz6_I8TrYNl3BOQz6Y=@protonmail.com>

On Friday, December 11, 2020 4:58 AM, cage <cage-dev at twistfold.it> wrote:

> I agree! My only concerns is i have the impression that client that
> will not supports IRI will be second class citizen in the gemini
> space, and they will die slowly.
>
> So i think that IRI will be a de facto standard. :/


I do not think this will happen, and if it starts to happen I will
fight against it. I don't think the idea of "de facto standards" fits within
the Gemini ethos at all. It's not supposed to be extensible and clients
aren't supposed go off and do random things while others have to decide
what to do and play catch-up. That is how the Web grew and became more complex,
and it's why we have only a few browsers today.

The ecosystem benefits when we all just stick to the standard, with the perhaps
obvious exception of demos and toys.

Stay united, Gemini!

Cheers,
makeworld


From petite.abeille at gmail.com  Fri Dec 11 22:40:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 11 Dec 2020 23:40:05 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org> <803842604.RZAbtYdCJc@tempete>
 <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>
 <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>
Message-ID: <DDF9E0BD-D05F-4D5B-850E-16A2C080EB8A@gmail.com>



> On Dec 11, 2020, at 21:38, colecmac at protonmail.com wrote:
> 
> We don't need this.

hmmm? who are you again? rhetorical.

From sean at conman.org  Fri Dec 11 23:14:47 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Dec 2020 18:14:47 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201211090444.GC7129@sources.org>
References: <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
 <20201211090444.GC7129@sources.org>
Message-ID: <20201211231447.GJ24194@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Thu, Dec 10, 2020 at 08:12:04PM -0500,
>  Gary Johnson <lambdatronic at disroot.org> wrote 
>  a message of 69 lines which said:
> 
> > 1. Punycode the hostname.
> 
> Not always, for the reasons explained in RFC 6055. To summarize: the
> application does not always know which name resolution system will be used.

  Yes, this is why I hata the incessent talking.  If you bothered to try it
on a few systems, you may have encountered *not* encoding with punycode
*also* fails.  I know, because I tried on a few systems I have access to,
and they all failed to look up "caf?.mozz.us" (yes, via getaddrinfo() even). 
They all worked when I looked up "xn--caf-dma.mozz.us".

  So now that I've injected some ugly reality in to a nice theoretical
discussion, what's next?

  -spc

From sean at conman.org  Fri Dec 11 23:43:06 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Dec 2020 18:43:06 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <miHm0gJWpGYRghNPXdE6bkAE9C1I-UbM_d0ax0yU3UB_cWmL8pORwzRyotxJGy_VmE6c93bly_wZ3HWEJHcqKqzX6jz6_I8TrYNl3BOQz6Y=@protonmail.com>
References: <20201209052651.GY24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org> <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <CAD2gp_R4SMmC8bdrY2padb7bSps9hxXFSw-Jhnqv+OohYHj0MA@mail.gmail.com>
 <X9NCt2YuMAC+fHFA@kurosawa.casa.net>
 <miHm0gJWpGYRghNPXdE6bkAE9C1I-UbM_d0ax0yU3UB_cWmL8pORwzRyotxJGy_VmE6c93bly_wZ3HWEJHcqKqzX6jz6_I8TrYNl3BOQz6Y=@protonmail.com>
Message-ID: <20201211234306.GK24194@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> On Friday, December 11, 2020 4:58 AM, cage <cage-dev at twistfold.it> wrote:
> 
> > I agree! My only concerns is i have the impression that client that
> > will not supports IRI will be second class citizen in the gemini
> > space, and they will die slowly.
> >
> > So i think that IRI will be a de facto standard. :/
> 
> I do not think this will happen, and if it starts to happen I will
> fight against it. 

  There's a reason why UTF-8 was selected as the default character set for
text/gemini, and one of those is to allow other people than English speakers
a means of expressing themsevles [1].  I don't think it's entirely
unreasonable to expect such a person to use Unicode for both domain name and
filenames [2].  Yes, tooling could be made to handle "canonicalizing" links
[3] but why not look into allowing IRIs?  Without an attempt at it, it would
be difficult to know what would work, what doesn't and where the difficulty,
if any, lie.  *That's* why I'm so insistent on coding up
"proof-of-concepts".  Just decreeing "this is how it shall be done" rarely
works out well [4].  And decreeing "this shall NOT be done" could put off
non-technical, non-English speaking people. [5]

> I don't think the idea of "de facto standards" fits within the Gemini
> ethos at all. It's not supposed to be extensible and clients aren't
> supposed go off and do random things while others have to decide what to
> do and play catch-up. That is how the Web grew and became more complex,
> and it's why we have only a few browsers today.

  And this is working out if the specification should be ammended to allow
IRIs, and if not, at at least have a jutification.

> The ecosystem benefits when we all just stick to the standard, with the
> perhaps obvious exception of demos and toys.

  One more point of reference.  The Gopher RFC (RFC-1436) states the use of
ISO-8859-1 for a character set.  It is wrong then, for gopher servers to
serve up UTF-8 documents even though it's not standard?  Yes, gopher is not
Gemini, but UTF-8 does seem to be a modern "de facto standard" in
gopherspace.

  -spc

[1]	For example, gemini://blekksprut.net/

[2]	Otherwise, punycode wouldn't exist.

[3]	Conversion from IRI to URI, with Unicode normalization,  prior to
	publication.

[4]	Such as X.200---lovingly developed and standardized but no one used
	it.  Or Xanadu.  Over 60 years of design work and still not working.

[5]	And I'm saying this being a thoroughly American mut that speaks only
	English.

From sean at conman.org  Fri Dec 11 23:49:17 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 11 Dec 2020 18:49:17 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <X9NAIRiKEPomfeUy@kurosawa.casa.net>
References: <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org> <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <20201211085702.GA7129@sources.org> <X9NAIRiKEPomfeUy@kurosawa.casa.net>
Message-ID: <20201211234917.GL24194@brevard.conman.org>

It was thus said that the Great cage once stated:
> On Fri, Dec 11, 2020 at 09:57:02AM +0100, Stephane Bortzmeyer wrote:
> 
> > Since I write Gemini clients, I have sympathy for this point of
> > view. However, let me quote RFC 8890
> 
> OK the point is  valid to me, for TLS, but not for  IDN. Anyway i have
> the impression i am in a minority  here, and i think i should start to
> do a minimal wrapping of libidn at this point. :-)

  Here's the code I wrote to wrap libidn:

	https://github.com/spc476/lua-conmanorg/blob/master/src/idn.c

It's geared for Lua, but the code itself is in C, but it should be pretty
easy to see what is going on.

  -spc


From list at gkbrk.com  Sat Dec 12 09:46:45 2020
From: list at gkbrk.com (Leo)
Date: Sat, 12 Dec 2020 12:46:45 +0300
Subject: Crawlers on Gemini and best practices
In-Reply-To: <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>
Message-ID: <C7QPMIESH8HA.1EJ893KFUI0RF@rath>

> Why are we defining new standards and filenames? bots.txt, .well-known,
> etc.

Just want to point out that the .well-known path for machine-readable
data about an origin is a proposed IETF standard that has relatively
widespread use today. It is filed under RFC8615, and is definitely not a
standard that was invented in this thread.

The first paragraph of the introduction even references the robots file.

While I don't necessarily agree with the naming of bots.txt, I see no
problem with putting these files under a .well-known directory.

> We don't need this.

Thanks for making this mailing list a lot more efficient and talking
about what the Gemini community needs in a 4-word sentence.

Even if the original path of /robots.txt is kept, I think it makes sense
to clarify an algorithm in non-ambiguous steps in order to get rid of
the disagreements in edge-cases.

> let's just pick a standard that works and make it offical.

The point is that the standard works for simple cases, but leaves a lot
to be desired when it comes to clarifying more complex cases. This
results in a lot of robots.txt implementations disagreeing about what is
allowed and not allowed.

Additionally by crawling the Web, you can see that people tend to extend
robots.txt in non-standard ways and this only gets incorporated into
Google's crawlers if the website is important enough.

> I am no big fan of Google, but they are the kings of crawling and it
> makes sense to go with them here.

The kings of crawling deemed HTTP and AMP the most suitable protocol and
markup format for content to be crawled, why don't we stop inventing
standards like Gemini and Gemtext and go with them here.

> The spec makes many example references to HTTP, but note that it is
> fully protocol-agnostic, so it works fine for Gemini.

Gemtext spec makes references to Gemini, but it is fully
protocol-agnostic, so it works fine with HTTP. Similarly, Gemini makes
many references to Gemtext, but it is content-type agnostic so it works
fine with HTML. But we thought we could be better off shedding
historical baggage and reinvented not one, but two main concepts of the
traditional Web.

--
Leo

From bjorn.warmedal at gmail.com  Sat Dec 12 11:52:29 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Sat, 12 Dec 2020 12:52:29 +0100
Subject: How do You publish to your gemlog?
Message-ID: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>

I?m curious about how authors structure their workflows in geminispace. My own is somewhat of a work in progress ?

I write my posts in vim, manually add an entry to my archive gemini feed and then run a bash script that updates my capsule index page and my atom feed. It?s a bit clunky, and I?m pondering how to make it less cumbersome.

What?s your workflow like?

Cheers
ew0k


Sent from my TI-83

From cage-dev at twistfold.it  Sat Dec 12 11:24:49 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 12 Dec 2020 12:24:49 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <miHm0gJWpGYRghNPXdE6bkAE9C1I-UbM_d0ax0yU3UB_cWmL8pORwzRyotxJGy_VmE6c93bly_wZ3HWEJHcqKqzX6jz6_I8TrYNl3BOQz6Y=@protonmail.com>
References: <20201209052651.GY24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <CAD2gp_R4SMmC8bdrY2padb7bSps9hxXFSw-Jhnqv+OohYHj0MA@mail.gmail.com>
 <X9NCt2YuMAC+fHFA@kurosawa.casa.net>
 <miHm0gJWpGYRghNPXdE6bkAE9C1I-UbM_d0ax0yU3UB_cWmL8pORwzRyotxJGy_VmE6c93bly_wZ3HWEJHcqKqzX6jz6_I8TrYNl3BOQz6Y=@protonmail.com>
Message-ID: <X9Sogc75PBAysFEh@kurosawa.casa.net>

On Fri, Dec 11, 2020 at 08:49:45PM +0000, colecmac at protonmail.com wrote:

[...]

> >
> > So i think that IRI will be a de facto standard. :/
>
>
> I do not think this will happen, and if it starts to happen I will
> fight against it. I don't think the idea of "de facto standards" fits within
> the Gemini ethos at all. It's not supposed to be extensible and clients
> aren't supposed go off and do random things while others have to decide
> what to do and play catch-up. That is how the Web grew and became more complex,
> and it's why we have only a few browsers today.

I am with you  with this but i think the only way  to let not developers
do their own way is to clarify  issues in the specs as much as possible.

> The ecosystem benefits when we all just stick to the standard, with the perhaps
> obvious exception of demos and toys.

Totally agree of course! I am trying to do so! :)

> Stay united, Gemini!

:) ?

Bye!
C.

From cage-dev at twistfold.it  Sat Dec 12 11:10:48 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 12 Dec 2020 12:10:48 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201211234917.GL24194@brevard.conman.org>
References: <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <20201211085702.GA7129@sources.org>
 <X9NAIRiKEPomfeUy@kurosawa.casa.net>
 <20201211234917.GL24194@brevard.conman.org>
Message-ID: <X9SlOHmQk8ZnJvHS@kurosawa.casa.net>

On Fri, Dec 11, 2020 at 06:49:17PM -0500, Sean Conner wrote:

[...]

>
>   Here's the code I wrote to wrap libidn:
>
> 	https://github.com/spc476/lua-conmanorg/blob/master/src/idn.c
>
> It's geared for Lua, but the code itself is in C, but it should be pretty
> easy to see what is going on.

Thank  you Sean!   I am,  in fact  starting to  wrap libidn  (actually
libidn2) so far seems that i got a working unicode->ascii function. Of
course i will be happy to share  the results and maybe, if some people
are going to be  interested (and if i succeed!  :))  i could extract a
library from this code (it is integrated in the client at moment).

Bye!
C.

From nico at itwont.work  Sat Dec 12 11:56:33 2020
From: nico at itwont.work (Nico)
Date: Sat, 12 Dec 2020 11:56:33 GMT
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <b2cbdb35-4188-1af2-31ff-085410f6e586@itwont.work>


On 12/12/2020 11:52, Bj?rn W?rmedal wrote:
> I?m curious about how authors structure their workflows in geminispace. My own is somewhat of a work in progress ?
> 
> I write my posts in vim, manually add an entry to my archive gemini feed and then run a bash script that updates my capsule index page and my atom feed. It?s a bit clunky, and I?m pondering how to make it less cumbersome.
> 
> What?s your workflow like?
> 
> Cheers
> ew0k
> 
> 
> Sent from my TI-83
> 

My site isn't a gemlog per se, but I write in gemtext using acme and 
then I have built a small site generator tool I use to generate feeds, 
indexes and an HTML version: https://tildegit.org/nihilazo/sitegenerator.
It's not great and probably would be difficult to deploy for any capsule 
other than mine, but that's my workflow.

Nico

From benulo at systemli.org  Sat Dec 12 12:28:30 2020
From: benulo at systemli.org (Ben)
Date: Sat, 12 Dec 2020 15:58:30 +0330
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <ae571276-51a6-f55a-b3a2-ddaf1c7d22cf@systemli.org>

On 12/12/20 3:22 PM, Bj?rn W?rmedal wrote:
> I?m curious about how authors structure their workflows in geminispace.

The thing I've worked out so far for myself is based on the use of a 
content management system called Logarion (written in Ocaml by Orbifx). 
I first run it to create a new document based on a title I give. Once 
the file is made I edit it locally with nano, basically in Gemini format 
minus Logarion's header. (The documents are meant to be in Markdown, but 
Gemini is like a subset of that anyway.)

When the document is written and marked for publication in its header, I 
run a script which calls Logarion to export them to GMI along with an 
index listing ordered by date (date.gmi) that Logarion itself provides. 
The script then copies the generated content into a directory on my 
server, and as such it is published.

I've been thinking about devising a minimalist alternative to this 
workflow because it's a little bit overkill for what I'm doing. My 
thought is that the least a Gemini site or log requires is:

* A server-generated directory listening in reverse alphabetical order
* Hand-written files whose names begin with their ISO date at least, 
hopefully with a title after.

This way all you really need is a text editor and nothing more, and just 
create an entry by running `nano '2020-12-10 Hello, World!.gmi'` (OK not 
sure if putting an exclamation point in a file name is reasonable, but 
whatever.)

The idea is people will go to the root directory of your log and get a 
nice and tidy human-readable index that they can browse from the top 
down... you just write content and don't worry about navigation.

Ben

-- 
gemini://kwiecien.us/

From guy.godfroy at gugod.fr  Sat Dec 12 12:40:26 2020
From: guy.godfroy at gugod.fr (Guy Godfroy)
Date: Sat, 12 Dec 2020 12:40:26 +0000 (UTC)
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <576ba08f-9aac-4bf5-87b5-b280f52830f4@gugod.fr>

I use a basic static site generator I coded. This is still WIP though https://github.com/raspbeguy/geminer

I first wrote it to convert from my PicoCMS markdown sources.

This way it generates also index by tags, by author, by whatever you want.

From come at chilliet.eu  Sat Dec 12 12:56:30 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Sat, 12 Dec 2020 13:56:30 +0100
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <3424910.bZe9qUfpET@tempete>

Le samedi 12 d?cembre 2020, 12:52:29 CET Bj?rn W?rmedal a ?crit :
> I?m curious about how authors structure their workflows in geminispace. My own is somewhat of a work in progress ?
> 
> I write my posts in vim, manually add an entry to my archive gemini feed and then run a bash script that updates my capsule index page and my atom feed. It?s a bit clunky, and I?m pondering how to make it less cumbersome.
> 
> What?s your workflow like?

I just use vim through ssh to write directly on the server.

The gemlog index is dynamic and just lists the files in the folder.

The downside is that the name of the file is used as post name, I may update the generated index to fetch the first line of posts and use that as link name, not sure.
I decided against using the file creation date automatically as post date, because I want to be able to write dateless pages, which will be updated in the future, while a gemlog post with a date is supposed to be a one shot.

C?me



From me at ecmelberk.com  Sat Dec 12 13:04:10 2020
From: me at ecmelberk.com (=?utf-8?q?Ecmel_Berk_Canl=C4=B1er?=)
Date: Sat, 12 Dec 2020 16:04:10 +0300
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <C7QTTNRSYHOD.73DKJMIO9WBV@fistik>

I probably have the hackiest setup here, based on shell scripts, duct
tape, and some JS on the deployment parts.

https://git.ebc.li/admicos/blog

I create a new `.gmi` file under `pages/<category>` and add some
boilerplate header and footer lines (for my shell-based templating
thing)

Then I edit the `post_list` file to add the new page. If I put the `.gmi`
extension on the filename here, the page becomes Gemini-exclusive.

Finally, I push my changes into the repo above, which pings a HTTP
endpoint I am listening to via https://nodered.org, clones the repo and
runs the shell script inside the `.makeshift.yml` file, that runs the
site generator scripts and pushes the results into the proper place.

I would make the Node-RED script thing public too, but the only proper
way to do so locks you into a single project (And also there probably
are some personal information in them). There is an outdated version
at https://git.ebc.li/makeshift/makeshift, but it went through some
changes at my end, mainly adding error handling and notifications.

There are a few screenshots on my Mastodon if you want to visualize the
jank going on here: https://toot.ebc.li/@admi/105132131906807252

--
Have a nice /(day|night|week(end)?)/
~ Ecmel B. Canl?er

From julien at typed-hole.org  Sat Dec 12 12:28:53 2020
From: julien at typed-hole.org (julien at typed-hole.org)
Date: Sat, 12 Dec 2020 13:28:53 +0100
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <6F9731CF4CAFA42D7EC9DB629EF0AD20@typed-hole.org>

I have a very slow workflow, basically I do everything by hand: edit the post, add to the index and to the feed. I like it to take some time and effort for some reason.

--

From roy at royniang.com  Sat Dec 12 14:10:23 2020
From: roy at royniang.com (roy niang)
Date: Sat, 12 Dec 2020 15:10:23 +0100
Subject: How do You publish to your gemlog?
In-Reply-To: <6F9731CF4CAFA42D7EC9DB629EF0AD20@typed-hole.org>
References: <6F9731CF4CAFA42D7EC9DB629EF0AD20@typed-hole.org>
Message-ID: <7f044904-39bf-4217-b5fc-4c4c100e88a9@www.fastmail.com>

I write my micrologs by hand. One document hosts every little
updates under subheadings.

My wiki outputs its feeds to www and gmi[0][1]. I have no intention to
port the whole wiki to gemini, but I began a log last week. Since it's
mostly text, I just convert them manually to gmi[2].

I use rsync to upload everything, but I'm trying to find something smart
that could also do it from 9front.

[0]: gemini://royniang.com/feed.gmi
[1]: gemini://royniang.com/journal.gmi
[2]: gemini://royniang.com/log/

From stephane at sources.org  Sat Dec 12 14:28:34 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sat, 12 Dec 2020 15:28:34 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201211082025.GA5933@sources.org>
References: <20201208133656.GA17700@sources.org>
 <20201208145840.5738718e@kongroo.lan>
 <67E2BFB7-1D5C-405D-9B31-778E06E91EA8@gmail.com>
 <20201211082025.GA5933@sources.org>
Message-ID: <20201212142833.GA11212@sources.org>

On Fri, Dec 11, 2020 at 09:20:25AM +0100,
 Stephane Bortzmeyer <stephane at sources.org> wrote 
 a message of 10 lines which said:

> > Like so?
> > 
> > gemini://example.com/robots.txt?user-agent=DetailsOfTheRobot ?
> 
> Good idea, this is what I do now.

Note that it is not guaranteed to work because of broken (IMHO)
servers. For instance,
<gemini://alexschroeder.ch/robots.txt?robot=true> redirects to
<gemini://alexschroeder.ch/page/robots.txt?robot=true> which returns a
code 50 :-(


From norm at iwritethe.codes  Sat Dec 12 14:57:58 2020
From: norm at iwritethe.codes (=?UTF-8?Q?Norm_MacLennan?=)
Date: Sat, 12 Dec 2020 14:57:58 +0000
Subject: How do You publish to your gemlog?
In-Reply-To: <7f044904-39bf-4217-b5fc-4c4c100e88a9@www.fastmail.com>
References: <6F9731CF4CAFA42D7EC9DB629EF0AD20@typed-hole.org> 
 <7f044904-39bf-4217-b5fc-4c4c100e88a9@www.fastmail.com> 
 <alpine.DEB.2.22.394.2012120937560.1508083@nlap>
Message-ID: <0100017657756075-34bbef2f-7873-49f8-b9a8-fd134e25e8b7-000000@email.amazonses.com>

I use gssg [1]. It's the first thing I tried for this and have only been 
using it for a few days now for my shiny new gemlog [2]. So I can't really 
compare and contrast other solutions, but I've been enjoying it so far.

Basically, I make a new post in `./content/posts/YYYY-MM-DD-title.gmi` and 
write the things that I want. Then I commit and push to sr.ht. The build 
runs a generate and pushes the `./public/` output up to S3. Then my server 
runs a sync every hour to pull down any new posts.

So it's relatively low-touch from my end, which I like. I think there's 
still some enahncements I can make, but overall I can't complain.

[1] https://sr.ht/~gsthnz/gssg/
[2] gemini://gem.iwritethe.codes/

From alex at nytpu.com  Sat Dec 12 16:15:09 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Sat, 12 Dec 2020 09:15:09 -0700
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <20201212161509.cmhforo3ze7to5ms@GLaDOS>

On 2020-12-12 12:52PM, Bj?rn W?rmedal wrote:
> I write my posts in vim, manually add an entry to my archive gemini
> feed and then run a bash script that updates my capsule index page and
> my atom feed. It?s a bit clunky, and I?m pondering how to make it less
> cumbersome.

This is basically what I do. I have a `template.gmi`[a] that has the
footers and such that I like, so I just copy that, and write my post in
(neo)vim, replacing the placeholders in my template. I then just run my
gemlog.sh utility[b] to generate the atom feed and index. I don't find
it particularly cumbersome, and I actually manage the entirety of the
rest of my site 100% manually, without any scripts at all. I think a big
strength of gemini is that a full capsule can be managed manually, or
with very simple scripts. I've never felt the need for blog generators
or md->gemtext anything like that.

I've been considering using CGI for my index and atom feed, so I don't
even need to run a script after writing a post, but I've never gotten
around to it. A while ago I patched bashblog to include gemini
support[c], if anyone is interested in adapting that and writing a cgi
atom feed then feel free, and send it to the list when it's done :)

[a]: https://github.com/nytpu/gemini.nytpu.com/blob/master/gemlog/template.gmi
[b]: https://git.sr.ht/~nytpu/gemlog.sh
[c]: https://tildegit.org/team/bashblog/src/branch/master/bb.sh#L892

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201212/f80c85d6/attachment-0001.sig>

From stephane at sources.org  Sat Dec 12 16:27:07 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sat, 12 Dec 2020 17:27:07 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org> <803842604.RZAbtYdCJc@tempete>
 <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>
 <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>
Message-ID: <20201212162707.GA13459@sources.org>

On Fri, Dec 11, 2020 at 08:38:12PM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 29 lines which said:

> Gemini is based around the idea of radical familiarity. Creating a
> new robots standard breaks that, and makes things more
> complicated. There are existing complete robots.txt standards

The problem is precisely the final S. I can add that most of the
"standards" are poorly written and very incomplete.

> but let's just pick a standard that works and make it offical.

OK, that's fine with me.

> https://tools.ietf.org/html/draft-koster-rep-04

(Better to indicate the URL without the version number, to get the
latest version.)

It seems well-specified, although quite rich, so more difficult to
implement.


From petite.abeille at gmail.com  Sat Dec 12 16:52:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 12 Dec 2020 17:52:39 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <20201212142833.GA11212@sources.org>
References: <20201208133656.GA17700@sources.org>
 <20201208145840.5738718e@kongroo.lan>
 <67E2BFB7-1D5C-405D-9B31-778E06E91EA8@gmail.com>
 <20201211082025.GA5933@sources.org> <20201212142833.GA11212@sources.org>
Message-ID: <655886B6-452C-47AD-99EB-79B8618BC8E4@gmail.com>



> On Dec 12, 2020, at 15:28, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Note that it is not guaranteed to work because of broken (IMHO)
> servers. For instance,
> <gemini://alexschroeder.ch/robots.txt?robot=true> redirects to
> <gemini://alexschroeder.ch/page/robots.txt?robot=true> which returns a
> code 50 :-(

Bummer. But to be expected. Specially from Alex who likes to, hmmm, experiment wildly :)

Still seems to be a reasonable approach. Sean mentioned using #fragment to the same effect.

From stephane at sources.org  Sat Dec 12 16:57:32 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sat, 12 Dec 2020 17:57:32 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <655886B6-452C-47AD-99EB-79B8618BC8E4@gmail.com>
References: <20201208133656.GA17700@sources.org>
 <20201208145840.5738718e@kongroo.lan>
 <67E2BFB7-1D5C-405D-9B31-778E06E91EA8@gmail.com>
 <20201211082025.GA5933@sources.org>
 <20201212142833.GA11212@sources.org>
 <655886B6-452C-47AD-99EB-79B8618BC8E4@gmail.com>
Message-ID: <20201212165732.GA14633@sources.org>

On Sat, Dec 12, 2020 at 05:52:39PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 17 lines which said:

> But to be expected.

I had to add blacklist support in my crawler to explicitely exclude
some... creative capsules.

> Sean mentioned using #fragment to the same effect.

That would be wrong since URI fragments are not sent to the server,
unlike queries.


From petite.abeille at gmail.com  Sat Dec 12 17:12:21 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 12 Dec 2020 18:12:21 +0100
Subject: moral imperative (was Re: Some reading on IRIs and IDNs)
In-Reply-To: <20201211234306.GK24194@brevard.conman.org>
References: <20201209052651.GY24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org> <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <CAD2gp_R4SMmC8bdrY2padb7bSps9hxXFSw-Jhnqv+OohYHj0MA@mail.gmail.com>
 <X9NCt2YuMAC+fHFA@kurosawa.casa.net>
 <miHm0gJWpGYRghNPXdE6bkAE9C1I-UbM_d0ax0yU3UB_cWmL8pORwzRyotxJGy_VmE6c93bly_wZ3HWEJHcqKqzX6jz6_I8TrYNl3BOQz6Y=@protonmail.com>
 <20201211234306.GK24194@brevard.conman.org>
Message-ID: <D6C61B93-3473-45AA-ABA5-B8294FB99973@gmail.com>



> On Dec 12, 2020, at 00:43, Sean Conner <sean at conman.org> wrote:
> 
> There's a reason why UTF-8 was selected as the default character set for
> text/gemini, and one of those is to allow other people than English speakers
> a means of expressing themsevles [1].  I don't think it's entirely
> unreasonable to expect such a person to use Unicode for both domain name and
> filenames [2]

Yes. agree. People should be able to express themselves in the most idiomatic -and frictionless- way they see fit. 

It's a moral imperative -and duty- for Gemini to make it so.

The year is 2020, no more easy and lazy excuses. This is not a technical choice, but a moral one. 

Timely article in The Economist:

Accent discrimination betrays a small mind
https://www.economist.com/books-and-arts/2020/12/12/accent-discrimination-betrays-a-small-mind

History will judge you: be one the right side.

Do the right thing Solderpunk.




From benulo at systemli.org  Sat Dec 12 17:31:38 2020
From: benulo at systemli.org (Ben)
Date: Sat, 12 Dec 2020 21:01:38 +0330
Subject: [ANN] Geminiserver ASM
In-Reply-To: <7cedd4a9-68fc-1d78-7afd-befdde93a861@g-n.site>
References: <34f72846-8b25-2630-d1a7-2b6b9ef3e9c1@g-n.site>
 <CAFaUHv+g7y=7nnvvDiFhc_GRaN7+pMDH=PFiG3XXr9wWPVyHrA@mail.gmail.com>
 <94a6b61f-e3f2-4c6d-7087-e43c2336bfae@g-n.site>
 <bf324ce6-b883-49ec-2dce-3d4aed165372@systemli.org>
 <7cedd4a9-68fc-1d78-7afd-befdde93a861@g-n.site>
Message-ID: <7ad41df2-982d-7145-10ee-2a01c34d6911@systemli.org>

I haven't tried it yet, but it just occurred to me that it probably 
already works with FreeBSD's Linux binary compatibility anyway (and 
other BSD's that have this feature), so it may not even need to be recoded.

-- 
gemini://kwiecien.us/

From kevin at mmn.on.ca  Sat Dec 12 20:56:27 2020
From: kevin at mmn.on.ca (=?UTF-8?B?S8Opdmlu?=)
Date: Sat, 12 Dec 2020 21:56:27 +0100
Subject: How do You publish to your gemlog?
In-Reply-To: <mailman.1520.1607773956.477.gemini@lists.orbitalfox.eu>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
 <mailman.1520.1607773956.477.gemini@lists.orbitalfox.eu>
Message-ID: <kcnfahx76fm1.ln2@francesco.mmn.on.ca>

Le 12/12/2020 ? 12:52, Bj?rn W?rmedal a ?crit?:
> I?m curious about how authors structure their workflows in geminispace. My own is somewhat of a work in progress ?
> 
> What?s your workflow like?


I use somewhat of a complicated system for the lolz, but the content
itself is managed through kiln (https://git.sr.ht/~adnano/kiln) which
makes life much easier for writing (I also use nano because I'm that
kind of person).

Then I rclone / rsync / sitecopy parts of the generated content into
three DreamObjects buckets (some to an FTP server) to get served from
different self-hosted servers that I've mounted those buckets to serve
the content in to the wild.

If you're interested to get a bit of an idea of what kind of wild system
I've got up, I've got some info here :

gemini://oh.mg/project/
https://oh.mg/project/

-K?vin




From sean at conman.org  Sat Dec 12 21:29:42 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 12 Dec 2020 16:29:42 -0500
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <20201212212942.GM24194@brevard.conman.org>

It was thus said that the Great Bj?rn W?rmedal once stated:
> I?m curious about how authors structure their workflows in geminispace. My
> own is somewhat of a work in progress ?

 ...

> What?s your workflow like?

  I email my entries in.  A program accepts the email and adds the entry to
the archive, which makes it available for the web, gopher and gemini.

  -spc


From seirdy at seirdy.one  Sun Dec 13 06:15:26 2020
From: seirdy at seirdy.one (Rohan Kumar)
Date: Sat, 12 Dec 2020 22:15:26 -0800
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <20201213061526.qbjp3igqs2ngc5oq@rkumar-dekstop>

On Sat, Dec 12, 2020 at 12:52:29PM +0100, Bj?rn W?rmedal wrote:
>What?s your workflow like?

I have a pretty typical setup for git + static sitegen.

I just finished switching my weblog and gemlog (seirdy.one) from a shell 
script to a proper Makefile; code at https://sr.ht/~seirdy/seirdy.one

I use Hugo to build both sites, but I tailor the Markdown/Gemtext 
sources to flow well. Handling multiple output formats is one of Hugo's 
main advantages.

Essentially, Hugo reads output formats for each page and generates the 
results (inc. an RSS feed)in the build directory. "make build deploy" 
builds and deploys both sites with rsync + zstd.

I don't actually run "make build deploy" myself; that command runs in 
CI. So I guess you could say that I publish to my gemlog by running "git 
commit && git push" and waiting for CI to run "make build deploy"

I went with a Hugo-based setup when I was building an earlier version of 
my site with Hugo and I found a post in Drew Devault's gemlog about 
Gemini and Hugo:

gemini://drewdevault.com/2020/09/27/Gemini-and-Hugo.gmi

I wouldn't recommend this setup unless you share content between a 
weblog and gemlog; Hugo is great for websites, but overkill for a simple 
gemlog.

My VPS runs either agate or gmnisrv, depending on my mood.

I should probably do an obligatory "meta" post sometime to explain the 
whole process.

/Seirdy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201212/25638c43/attachment.sig>

From kevin at mmn.on.ca  Sat Dec 12 20:56:27 2020
From: kevin at mmn.on.ca (=?UTF-8?B?S8Opdmlu?=)
Date: Sat, 12 Dec 2020 21:56:27 +0100
Subject: How do You publish to your gemlog?
In-Reply-To: <mailman.1520.1607773956.477.gemini@lists.orbitalfox.eu>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
 <mailman.1520.1607773956.477.gemini@lists.orbitalfox.eu>
Message-ID: <kcnfahx76fm1.ln2@francesco.mmn.on.ca>

Le 12/12/2020 ? 12:52, Bj?rn W?rmedal a ?crit?:
> I?m curious about how authors structure their workflows in geminispace. My own is somewhat of a work in progress ?
> 
> What?s your workflow like?


I use somewhat of a complicated system for the lolz, but the content
itself is managed through kiln (https://git.sr.ht/~adnano/kiln) which
makes life much easier for writing (I also use nano because I'm that
kind of person).

Then I rclone / rsync / sitecopy parts of the generated content into
three DreamObjects buckets (some to an FTP server) to get served from
different self-hosted servers that I've mounted those buckets to serve
the content in to the wild.

If you're interested to get a bit of an idea of what kind of wild system
I've got up, I've got some info here :

gemini://oh.mg/project/
https://oh.mg/project/

-K?vin




From come at chilliet.eu  Sun Dec 13 17:12:05 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Sun, 13 Dec 2020 18:12:05 +0100
Subject: Supporting TLS client certificate in PHP?
Message-ID: <3489664.TY8R3EpOMY@tempete>

Hello,

My server is implemented in PHP and I would like add client certificate support, but I cannot seem to find the right option for this.

I tried setting capture_peer_cert to true in the context options, but it does not seem to work, and the documentation is, well, sporadic.

You can read my code on gemini://code.lanterne.chilliet.eu/vendor/mcmic/gemini-server/src/Server.php

Are there any Gemini server in PHP with client cert support?

C?me



From jansen.price at gmail.com  Sun Dec 13 17:28:38 2020
From: jansen.price at gmail.com (Jansen Price)
Date: Sun, 13 Dec 2020 11:28:38 -0600
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <3489664.TY8R3EpOMY@tempete>
References: <3489664.TY8R3EpOMY@tempete>
Message-ID: <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>

I ran into the same problem when trying to add client certificate support
on my PHP server (https://tildegit.org/sumpygump/orbit)

I think that `capture_peer_cert` is intended to only work
with stream_socket_client and not with socket servers. I started looking at
the source code of PHP to see if I could find the part that handles the TLS
handshake to find out if there is any way to get access to the cert that
came along with the connection, but I have not been successful in my search
yet.

On Sun, Dec 13, 2020 at 11:12 AM C?me Chilliet <come at chilliet.eu> wrote:

> Hello,
>
> My server is implemented in PHP and I would like add client certificate
> support, but I cannot seem to find the right option for this.
>
> I tried setting capture_peer_cert to true in the context options, but it
> does not seem to work, and the documentation is, well, sporadic.
>
> You can read my code on gemini://
> code.lanterne.chilliet.eu/vendor/mcmic/gemini-server/src/Server.php
>
> Are there any Gemini server in PHP with client cert support?
>
> C?me
>
>
>

-- 
Jansen Price
612-886-5065
jansen.price at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201213/ef9a0e94/attachment.htm>

From luke at marmaladefoo.com  Sun Dec 13 19:05:19 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 13 Dec 2020 19:05:19 +0000
Subject: [ANN] SmolNetSharp - C# library for building Gemini/Gopher clients
Message-ID: <5FD665EF.5090308@marmaladefoo.com>

Hi Everyone

Perhaps I can offer some partial respite from some of the other long 
running mailing list threads...

I'm pleased to announce SmolNetSharp - a new client library for building 
your own Smolnet client.

   https://github.com/LukeEmmet/SmolNetSharp

Key features include:

* Client code for Gemini and Gopher, using a common interface
* Option to set a timeout/max size to abandon long or large downloads
* Converts Gopher item types to mime types
* Support for Gemini proxies
* Compiles on Windows and probably Linux too (since .NET Core, but not 
not tested on Linux yet)

There is a simple 100 line Gemini/Gopher simple demo interactive client 
in the repository, to illustrate usage.

It is now the client library in GemiNaut, a new release of which is also 
coming soon.

   - Luke

From jon at shit.cx  Sun Dec 13 23:09:50 2020
From: jon at shit.cx (Jon)
Date: Mon, 14 Dec 2020 10:09:50 +1100
Subject: How do You publish to your gemlog?
In-Reply-To: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
References: <56CF1D1D-B521-49D4-BED1-F8F0CF04F4AE@gmail.com>
Message-ID: <20201213230950.53i52fzs35q26xtb@devbox>

I create a new post using `make new TITLE="the title"`. It sends a
template through envsubst to pre-fill some things then writes it to a
well-named file in a drafts folder.

When I'm finished writing, I move the document to the proper directory.
I then run `make update` to generate updated indexes and atom feed. Then
I commit and push the changes.

To deploy, I run `make publish` which ssh's into the server with agent
forwarding and does a git pull.

I don't do http or gopher, so there is none of that to deal with.

-- 
Jon

From norm at iwritethe.codes  Sun Dec 13 23:11:08 2020
From: norm at iwritethe.codes (=?UTF-8?Q?Norm_MacLennan?=)
Date: Sun, 13 Dec 2020 23:11:08 +0000
Subject: [ANN] SmolNetSharp - C# library for building Gemini/Gopher clients
In-Reply-To: <5FD665EF.5090308@marmaladefoo.com>
References: <5FD665EF.5090308@marmaladefoo.com> 
 <alpine.DEB.2.22.394.2012131807060.1508083@nlap>
Message-ID: <010001765e5f3c81-75ae8344-3826-4026-b47e-074130488b13-000000@email.amazonses.com>

On Sun, 13 Dec 2020, Luke Emmet wrote:
> Perhaps I can offer some partial respite from some of the other long running 
> mailing list threads...

Oh, God. Thank you!

> * Compiles on Windows and probably Linux too (since .NET Core, but not not 
> tested on Linux yet)

For what it's worth, I can confirm it compiles and runs just fine on Linux 
(after I installed 3.1, previously I only had 5.0 installed).

My background is in C#, but I haven't really used it since 2013 or so. 
I've checked out dotnet core a couple of times, but never really 
"returned" to the language despite intending to.

Always nice to see new open source projects using the language.


From luke at marmaladefoo.com  Sun Dec 13 23:53:20 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 13 Dec 2020 23:53:20 +0000
Subject: [ANN] SmolNetSharp - C# library for building Gemini/Gopher clients
In-Reply-To: <010001765e5f3c81-75ae8344-3826-4026-b47e-074130488b13-000000@email.amazonses.com>
References: <5FD665EF.5090308@marmaladefoo.com>
 <alpine.DEB.2.22.394.2012131807060.1508083@nlap>
 <010001765e5f3c81-75ae8344-3826-4026-b47e-074130488b13-000000@email.amazonses.com>
Message-ID: <5FD6A970.80202@marmaladefoo.com>


On 13-Dec-2020 23:11, Norm MacLennan wrote:
>> * Compiles on Windows and probably Linux too (since .NET Core, but not not
>> tested on Linux yet)
> For what it's worth, I can confirm it compiles and runs just fine on Linux
> (after I installed 3.1, previously I only had 5.0 installed).

Many thanks for confirming this - I'll update the readme to say it is 
possible.

  - Luke



From linde.philip at gmail.com  Mon Dec 14 10:46:49 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 14 Dec 2020 11:46:49 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201211231447.GJ24194@brevard.conman.org>
References: <20201209083845.GC14045@sources.org>
 <20201209221749.GA24194@brevard.conman.org>
 <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org>
 <87a6ul404b.fsf@disroot.org> <20201211090444.GC7129@sources.org>
 <20201211231447.GJ24194@brevard.conman.org>
Message-ID: <20201214114649.03d20afc957b0a27059b3585@gmail.com>

On Fri, 11 Dec 2020 18:14:47 -0500
Sean Conner <sean at conman.org> wrote:

> I know, because I tried on a few systems I have access to,
> and they all failed to look up "caf?.mozz.us" (yes, via getaddrinfo() even). 
> They all worked when I looked up "xn--caf-dma.mozz.us".

I don't think Stephane means different systems in the sense of
different computers, but different systems as in different name
resolution systems. On my computer, for example, there are at least
three sources for names: DNS, mDNS and /etc/hosts. getaddrinfo() can
resolve using any of these systems via the name service switch, but IDN
only concerns DNS names.

caf?.mozz.us in your tests probably always resolved via DNS, but if you
had a caf?.local mDNS name or "caf?" in your hosts file you might not
be able to use IDN. I don't know about the hosts file, but mDNS for
example uses UTF-8 encoded names directly.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201214/b3d7ae31/attachment-0001.sig>

From stephane at sources.org  Mon Dec 14 14:13:22 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 14 Dec 2020 15:13:22 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201214114649.03d20afc957b0a27059b3585@gmail.com>
References: <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org>
 <87a6ul404b.fsf@disroot.org> <20201211090444.GC7129@sources.org>
 <20201211231447.GJ24194@brevard.conman.org>
 <20201214114649.03d20afc957b0a27059b3585@gmail.com>
Message-ID: <20201214141322.GA20004@sources.org>

On Mon, Dec 14, 2020 at 11:46:49AM +0100,
 Philip Linde <linde.philip at gmail.com> wrote 
 a message of 45 lines which said:

> but different systems as in different name resolution systems.

Yes.

> caf?.mozz.us in your tests probably always resolved via DNS, but if
> you had a caf?.local mDNS name or "caf?" in your hosts file you
> might not be able to use IDN. I don't know about the hosts file, but
> mDNS for example uses UTF-8 encoded names directly.

I just tested with a Debian box and it seems getaddrinfo (both from a
Python program and from a C one, ping), requires the name in
/etc/hosts to be present in Punycode form (A-label).

The good news is that the Python program does not have to do
punycoding itself, it is handled automatically by the standard
library.


From cage-dev at twistfold.it  Mon Dec 14 15:09:53 2020
From: cage-dev at twistfold.it (cage)
Date: Mon, 14 Dec 2020 16:09:53 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <X9SlOHmQk8ZnJvHS@kurosawa.casa.net>
References: <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <20201211085702.GA7129@sources.org>
 <X9NAIRiKEPomfeUy@kurosawa.casa.net>
 <20201211234917.GL24194@brevard.conman.org>
 <X9SlOHmQk8ZnJvHS@kurosawa.casa.net>
Message-ID: <X9eAQYXqnRKyf6+c@kurosawa.casa.net>

On Sat, Dec 12, 2020 at 12:10:48PM +0100, cage wrote:
> On Fri, Dec 11, 2020 at 06:49:17PM -0500, Sean Conner wrote:
>
> [...]
>
> >
> >   Here's the code I wrote to wrap libidn:
> >
> > 	https://github.com/spc476/lua-conmanorg/blob/master/src/idn.c
> >
> > It's geared for Lua, but the code itself is in C, but it should be pretty
> > easy to see what is going on.
>
> Thank  you Sean!   I am,  in fact  starting to  wrap libidn  (actually
> libidn2) so far seems that i got a working unicode->ascii function. Of
> course i will be happy to share  the results and maybe, if some people
> are going to be  interested (and if i succeed!  :))  i could extract a
> library from this code (it is integrated in the client at moment).

FWIW i managed to  switch from URI to IRI in  my client, fortunately i
was able to reuse  most of the URL parser. For Punycode  i wrapped a C
library.

Not sure if i did everything right but have met no regression so far.

If other  lisper (CL) are interested  we could arrange a  library from
this code.

Bye!
C.

From petite.abeille at gmail.com  Mon Dec 14 15:37:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 14 Dec 2020 16:37:19 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <X9eAQYXqnRKyf6+c@kurosawa.casa.net>
References: <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org> <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <20201211085702.GA7129@sources.org> <X9NAIRiKEPomfeUy@kurosawa.casa.net>
 <20201211234917.GL24194@brevard.conman.org>
 <X9SlOHmQk8ZnJvHS@kurosawa.casa.net> <X9eAQYXqnRKyf6+c@kurosawa.casa.net>
Message-ID: <ECC0D99B-83E6-4066-955A-852F5342A8EA@gmail.com>



> On Dec 14, 2020, at 16:09, cage <cage-dev at twistfold.it> wrote:
> 
> FWIW i managed to  switch from URI to IRI in  my client,

Bravo! :)

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it."
? Alan Kay

From cage-dev at twistfold.it  Mon Dec 14 16:21:36 2020
From: cage-dev at twistfold.it (cage)
Date: Mon, 14 Dec 2020 17:21:36 +0100
Subject: Some reading on IRIs and IDNs
In-Reply-To: <ECC0D99B-83E6-4066-955A-852F5342A8EA@gmail.com>
References: <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <X9JEzJQPK42PoSNl@kurosawa.casa.net>
 <20201211085702.GA7129@sources.org>
 <X9NAIRiKEPomfeUy@kurosawa.casa.net>
 <20201211234917.GL24194@brevard.conman.org>
 <X9SlOHmQk8ZnJvHS@kurosawa.casa.net>
 <X9eAQYXqnRKyf6+c@kurosawa.casa.net>
 <ECC0D99B-83E6-4066-955A-852F5342A8EA@gmail.com>
Message-ID: <X9eREIpTyXJs158J@kurosawa.casa.net>

On Mon, Dec 14, 2020 at 04:37:19PM +0100, Petite Abeille wrote:
>
>
> > On Dec 14, 2020, at 16:09, cage <cage-dev at twistfold.it> wrote:
> >
> > FWIW i managed to  switch from URI to IRI in  my client,
>
> Bravo! :)

Thank you! :)

Honestly  most of  the  hard work  has  been done  by  libidn and  two
excellent lisp libraries; sometimes people complains that CL is full of
half-baked  libraries but  there are  some high  quality too,  FFI and
parser generator are  two that excels, in my opinion.  Also the author
of the latter actually helped me spotting a bug in the code. :)

Bye!
C.

From alex at nytpu.com  Tue Dec 15 01:48:26 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Mon, 14 Dec 2020 18:48:26 -0700
Subject: Proposal: Rabbits in gemtext
Message-ID: <20201215014826.doa34rpynuiye7zz@GLaDOS>

I physically cannot create content on gemini without the ability to
insert ascii art of a rabbit arbitrarily in gemtext. I *demand* that
gemtext be amended to support both inline and standalone rabbits
posthaste. There is no humanly possible way for me to ever make anything
on gemini until this is implemented. It's not like I could be out
writing meaningful content on gemini instead of writing incessant emails
to the list, that's crazy talk.


The proposal:
A inline rabbit is indicated with the unicode string U+003a U+0072
U+0430 U+0062 U+0062 U+0069 U+03a4 U+003a (":r?bbi?:") appearing
anywhere on the line. Even though it is literally impossible for the
majority of users to type, who really types text out manually anymore?
Copying and pasting is the future.

A "standalone" rabbit is delimited by the unicode string U+003b U+0072
U+0430 U+0062 U+0069 U+03a4 U+003b (";r?bbi?;") appearing on it's own
line. Why is it different from an inline rabbit? Well gemtext isn't
designed to be easy to parse, it's not the spec writers' job to make it
easier on the developers. I've never ever written useful gemini software
myself, so it's not like it bothers me anyways!

What do you mean I can use stuff that already exists in gemini to add
ascii art of rabbits? The preformatted text block was really ambiguous
(i.e. I couldn't understand it), as it doesn't explain what
"preformatted" means, and I couldn't be bothered to look at the first
result on any search engine to find the meaning. Since I just don't like
the existing options, this MUST be implemented by all clients
immediately and the existing preformatted text toggles MUST be removed
from all implementations, because I never use them which means they are
useless.

Before you go crying with your worthless arguments like "it doesn't
provide provide enough benefit to justify the technical and manpower
cost of implementing it," it is important to not look at the technical
aspects of this. You're not supposed to look at the technical
considerations of implementing something when amending a fundamentally
technical internet protocol's formal specification, instead you should
look at the morals of it. On that front, if solderpunk doesn't
immediately add this change to the spec that means that he is
discriminating against everyone that likes rabbits, and that anyone who
gives well reasoned arguments on why this is a bad change will be judged
the same as hitler in the history books. Don't believe me? Look at this
random article that isn't even related to my argument in all but the
most surface level:
https://www.nytpu.com/files/really-really-really-really-really-really-long-url.html


An important thing to note before replying:
If anyone disagrees with me, instead of providing well reasoned
counterarguments I will instead resort to repeating already refuted
arguments, ad hominem, and by moving the goalposts. I will also
deliberately misunderstand and ignore your argument to make it easier
for me to strawman.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201214/9c7d3558/attachment.sig>

From sean at conman.org  Tue Dec 15 02:45:40 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 14 Dec 2020 21:45:40 -0500
Subject: Some reading on IRIs and IDNs
In-Reply-To: <20201214114649.03d20afc957b0a27059b3585@gmail.com>
References: <cMh0igZHDOzuyU75fuDnBKkUolOKKwuV6zmbXKm9081hXt0n6XV_TTy4swo7FLHaNYz1TyHhy9E26nOZbknPhDfsc3wdoUxSwDYbFiBTJck=@protonmail.com>
 <20201210011634.GC24194@brevard.conman.org>
 <7ExzueowqR_vFV8ACFkFZRVZKpBCSSc8CyrJNrd_wlkYtsdNbh2PT0vSc2uIH_KBd0y7twD5pYBGPhd2s55PgBY0oGcRY2pe50RCDGRcvvU=@protonmail.com>
 <20201210032540.GD24194@brevard.conman.org>
 <20201210091542.GA18084@sources.org>
 <20201211003501.GI24194@brevard.conman.org> <87a6ul404b.fsf@disroot.org>
 <20201211090444.GC7129@sources.org>
 <20201211231447.GJ24194@brevard.conman.org>
 <20201214114649.03d20afc957b0a27059b3585@gmail.com>
Message-ID: <20201215024540.GP24194@brevard.conman.org>

It was thus said that the Great Philip Linde once stated:
> On Fri, 11 Dec 2020 18:14:47 -0500
> Sean Conner <sean at conman.org> wrote:
> 
> > I know, because I tried on a few systems I have access to,
> > and they all failed to look up "caf?.mozz.us" (yes, via getaddrinfo() even). 
> > They all worked when I looked up "xn--caf-dma.mozz.us".
> 
> I don't think Stephane means different systems in the sense of
> different computers, but different systems as in different name
> resolution systems. 

  Yes, I understand that, but on the systems I used, all FAILED to resolve
"caf?.mozz.us".  Does that mean the client just gives up and says "domain
not found?" because local configuration doesn't work with UTF-8 domain
names?  That, to me, sounds like what Stephane is advocating for when they
say "no conversion to punycode".  It's wonderful that Stephane's language
du jour will apparently handle it for the user, but are the rest of us out
of luck? [1]  THIS is what I'm asking about.

  -spc

[1]	And a response of "here's a nickel, get yourself a real computer
	language" is NOT a valid resonse.

From lazar.michael22 at gmail.com  Tue Dec 15 06:34:12 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 15 Dec 2020 01:34:12 -0500
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <20201215014826.doa34rpynuiye7zz@GLaDOS>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
Message-ID: <CAFTy05YwfWU073=VWzK+XOxx=ZL0hSRw+OKYs4ruv2=w6TFgcw@mail.gmail.com>

On Mon, Dec 14, 2020 at 8:48 PM Alex // nytpu <alex at nytpu.com> wrote:
>
> I physically cannot create content on gemini without the ability to
> insert ascii art of a rabbit arbitrarily in gemtext. I *demand* that
> gemtext be amended to support both inline and standalone rabbits
> posthaste. There is no humanly possible way for me to ever make anything
> on gemini until this is implemented. It's not like I could be out
> writing meaningful content on gemini instead of writing incessant emails
> to the list, that's crazy talk.

Greetings,

I think this is a neat proposal. I too cannot function without cute, furry
animals in my life. I added support for your rabbit spec to my gemini proxy
server as a proof of concept:

https://portal.mozz.us/gemini/mozz.us/files/rabbit_formatting.gmi

Cheers!

- Michael

From petite.abeille at gmail.com  Tue Dec 15 07:51:06 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 08:51:06 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <20201215014826.doa34rpynuiye7zz@GLaDOS>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
Message-ID: <98A1C086-ABFA-4EB1-9A8F-7F2F0B372D54@gmail.com>



> On Dec 15, 2020, at 02:48, Alex // nytpu <alex at nytpu.com> wrote:
> 
> ascii art of a rabbit

Fantastic. Would make PETA proud. Very inclusive and cuddly.

Question: any special handling needed for The Killer Rabbit of Caerbannog?




From stephane at sources.org  Tue Dec 15 07:56:16 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 15 Dec 2020 08:56:16 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <20201215014826.doa34rpynuiye7zz@GLaDOS>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
Message-ID: <20201215075616.GA5495@sources.org>

On Mon, Dec 14, 2020 at 06:48:26PM -0700,
 Alex // nytpu <alex at nytpu.com> wrote 
 a message of 92 lines which said:

> An important thing to note before replying:
> If anyone disagrees with me,

I won't. My mother told me not to feed the trolls (specially the ugly
and stupid ones).

From lists at gph.dk  Tue Dec 15 08:05:24 2020
From: lists at gph.dk (=?UTF-8?Q?K=C3=A9vin?=)
Date: Tue, 15 Dec 2020 09:05:24 +0100 (CET)
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <20201215075616.GA5495@sources.org>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org>
Message-ID: <MO_QDLh--3-2@gph.dk>

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

? gemini at lists.orbitalfox.eu
??? host fluffy.bunny[127.168.255.71]
??? SMTP error from remote mail server after RCPT TO:<gemini at lists.orbitalfox.eu>:
??? 450 4.7.1 Client host rejected: does not include enough cuddly bunnies.? Hoppity hop

????????? /|
??? /\?? //
?? |/\'-'/ .::.
???? /^Y^\::''.
???? \_ /=| `'
??? /`_)=( \
??? \ /=/'-/
?? {/ |/? \
? __\? _? /__
'----' '----'

-- 
Envoi s?curis? avec Tutanota. Obtenez votre propre adresse email chiffr?e : 
https://tutanota.com


From petite.abeille at gmail.com  Tue Dec 15 08:13:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 09:13:05 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <MO_QDLh--3-2@gph.dk>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org> <MO_QDLh--3-2@gph.dk>
Message-ID: <9A96B6BD-EB3A-48D1-8683-3283BAA97CEF@gmail.com>



> On Dec 15, 2020, at 09:05, K?vin <lists at gph.dk> wrote:
> 
>     450 4.7.1 Client host rejected: does not include enough cuddly bunnies.  Hoppity hop

Damn! Same! 

Fixed:

{\_/}
( ?.?)
/ >?? u want this?

From guy.godfroy at gugod.fr  Tue Dec 15 08:31:01 2020
From: guy.godfroy at gugod.fr (Guy Godfroy)
Date: Tue, 15 Dec 2020 09:31:01 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <9A96B6BD-EB3A-48D1-8683-3283BAA97CEF@gmail.com>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org> <MO_QDLh--3-2@gph.dk>
 <9A96B6BD-EB3A-48D1-8683-3283BAA97CEF@gmail.com>
Message-ID: <eb28cf5c-2c7e-e5cf-f7f9-b618e7539b6c@gugod.fr>

And that's exactly how to make people unsubscribe to the ML because of
too much useless noise, and to shrink even more the reputation of Gemini
community.

Congratulations.

Le 15/12/2020 ? 09:13, Petite Abeille a ?crit?:
> 
> 
>> On Dec 15, 2020, at 09:05, K?vin <lists at gph.dk> wrote:
>>
>>     450 4.7.1 Client host rejected: does not include enough cuddly bunnies.  Hoppity hop
> 
> Damn! Same! 
> 
> Fixed:
> 
> {\_/}
> ( ?.?)
> / >?? u want this?
> 

From petite.abeille at gmail.com  Tue Dec 15 08:34:21 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 09:34:21 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <CAFTy05YwfWU073=VWzK+XOxx=ZL0hSRw+OKYs4ruv2=w6TFgcw@mail.gmail.com>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <CAFTy05YwfWU073=VWzK+XOxx=ZL0hSRw+OKYs4ruv2=w6TFgcw@mail.gmail.com>
Message-ID: <947A6B70-0008-42AA-8E12-7E27DEC7631D@gmail.com>



> On Dec 15, 2020, at 07:34, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> https://portal.mozz.us/gemini/mozz.us/files/rabbit_formatting.gmi

Genius. 

Isn't text/gemini mostly bunny friendly out-of-the-box though? 

What about a native bunny host name? ?.mozz.us

Or perhaps a bunny friendly link? => gemini://?.mozz.us/?.gmi ?Hoppity hop?





From petite.abeille at gmail.com  Tue Dec 15 08:45:07 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 09:45:07 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <eb28cf5c-2c7e-e5cf-f7f9-b618e7539b6c@gugod.fr>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org> <MO_QDLh--3-2@gph.dk>
 <9A96B6BD-EB3A-48D1-8683-3283BAA97CEF@gmail.com>
 <eb28cf5c-2c7e-e5cf-f7f9-b618e7539b6c@gugod.fr>
Message-ID: <606FFCE7-6B28-4C35-93D2-E2CE2541D7EF@gmail.com>



> On Dec 15, 2020, at 09:31, Guy Godfroy <guy.godfroy at gugod.fr> wrote:
> 
> shrink even more

Indeed. 

So... IRI or URI? Inclusive or discriminatory? Bunnies or no bunnies? 

Such choices are not _solely_ technical. They are moral as well.

Such holier-than-thou community should be able to make an informed choice in keeping with its own values.

Or not.




From unicorn at disroot.org  Tue Dec 15 09:01:27 2020
From: unicorn at disroot.org (Unicorn)
Date: Tue, 15 Dec 2020 09:01:27 +0000 (UTC)
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <eb28cf5c-2c7e-e5cf-f7f9-b618e7539b6c@gugod.fr>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org> <MO_QDLh--3-2@gph.dk>
 <9A96B6BD-EB3A-48D1-8683-3283BAA97CEF@gmail.com>
 <eb28cf5c-2c7e-e5cf-f7f9-b618e7539b6c@gugod.fr>
Message-ID: <4faf3118-e39f-41fe-9809-1d513b9ea1c4@disroot.org>


15 Dec 2020 09:31:23 Guy Godfroy <guy.godfroy at gugod.fr>:

> And that's exactly how to make people unsubscribe to the ML because of
> too much useless noise, and to shrink even more the reputation of 
Gemini
> community.
>
> Congratulations.

Interesting, I wanted to unsubscribe for quite a while due to all the 
often rude technical back-and-forths and I found this quite pleasant and 
worth reading for a change. Silly things, banter and what people in these 
circles often call "offtopic" builds community, which is perhaps even 
more important than the endless technical details of the spec or 
software.

From unicorn at disroot.org  Tue Dec 15 09:06:38 2020
From: unicorn at disroot.org (Unicorn)
Date: Tue, 15 Dec 2020 09:06:38 +0000 (UTC)
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <4faf3118-e39f-41fe-9809-1d513b9ea1c4@disroot.org>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org> <MO_QDLh--3-2@gph.dk>
 <9A96B6BD-EB3A-48D1-8683-3283BAA97CEF@gmail.com>
 <eb28cf5c-2c7e-e5cf-f7f9-b618e7539b6c@gugod.fr>
 <4faf3118-e39f-41fe-9809-1d513b9ea1c4@disroot.org>
Message-ID: <810cf8b8-7b7d-4cb3-ba48-10d1000484b9@disroot.org>

????????????????????? /|????? __
*???????????? +????? / |?? ,-~ /???????????? +
???? .????????????? Y :|? //? /??????????????? .???????? *
???????? .????????? | jj /( .^???? *
?????????????? *??? >-"~"-v"????????????? .??????? *??????? .
*????????????????? /?????? Y
?? .???? .??????? jo? o??? |???? .??????????? +
???????????????? ( ~T~???? j???????????????????? +???? .
????? +?????????? >._-' _./???????? +
?????????????? /| ;-"~ _? l?????????????? .
? .?????????? / l/ ,-"~??? \???? +
????????????? \//\/????? .- \
?????? +?????? Y??????? /??? Y
?????????????? l?????? I???? !
?????????????? ]\????? _\??? /"\
????????????? (" ~----( ~?? Y.? )
????????? ~~~~~~~~~~~~~~~~~~~~~~~~~~

Forgot the bunny, forgive me. Here's a seasonal one from Germany.

Best,
Unicorn

From petite.abeille at gmail.com  Tue Dec 15 09:10:50 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 10:10:50 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <810cf8b8-7b7d-4cb3-ba48-10d1000484b9@disroot.org>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org> <MO_QDLh--3-2@gph.dk>
 <9A96B6BD-EB3A-48D1-8683-3283BAA97CEF@gmail.com>
 <eb28cf5c-2c7e-e5cf-f7f9-b618e7539b6c@gugod.fr>
 <4faf3118-e39f-41fe-9809-1d513b9ea1c4@disroot.org>
 <810cf8b8-7b7d-4cb3-ba48-10d1000484b9@disroot.org>
Message-ID: <0C404EA3-2730-4DC4-A7FC-503A020708D3@gmail.com>



> On Dec 15, 2020, at 10:06, Unicorn <unicorn at disroot.org> wrote:
> 
> Forgot the bunny, forgive me. Here's a seasonal one from Germany.

??

{\__/}
( ? .?)
/ > ? u want this?

{\__/}? ?{\__/}
( ? ??) ??(? . ?)
/  > >???< \

{\__/}  ???? {\__/}
( ? ??) ??? ?(?? ? )
/  > ? ???? < < \

{\__/}  ?????? {\__/}
( ? ??) ??? ???(?? ? )
/  > > ????? ? ? < \


From petite.abeille at gmail.com  Tue Dec 15 10:17:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 11:17:31 +0100
Subject: Crawlers on Gemini and best practices
In-Reply-To: <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>
References: <20201208133656.GA17700@sources.org>
 <CAFaUHv+d+cbREnz+XPtWzd3Cf4bY_PkmhK+m1yEqT5_7dTvJoQ@mail.gmail.com>
 <20201211082654.GB5933@sources.org> <803842604.RZAbtYdCJc@tempete>
 <CAFaUHvLRqi2aPAApaq8wu7berX2n5ttguaos0+=BTodB+LYVvg@mail.gmail.com>
 <eyT9XfA9rzC9DM7o1Iw5PvFbN40wEP5IpO31eBwIeVm0S1B6Rupefj8JsG_SIagM3_TF2vaYGrSHsJcss-Bm0T73PdigBCmzTyqzJ2gjVDE=@protonmail.com>
Message-ID: <5160847F-69AC-4218-A1F0-6D37C8D3CD58@gmail.com>



> On Dec 11, 2020, at 21:38, colecmac at protonmail.com wrote:
> 
> I am no big fan of Google, but they are the kings of crawling and it makes sense
> to go with them here.

Interesting read:

Google?s Got A Secret
https://knuckleheads.club

TL;DR: There Should Be A Public Cache Of The Web



From petite.abeille at gmail.com  Tue Dec 15 10:42:01 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 11:42:01 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <20201215014826.doa34rpynuiye7zz@GLaDOS>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
Message-ID: <2969596E-7F54-4A29-BCD4-F64A569D6925@gmail.com>



> On Dec 15, 2020, at 02:48, Alex // nytpu <alex at nytpu.com> wrote:
> 
> https://www.nytpu.com/files/really-really-really-really-really-really-long-url.html

Tangentially unrelated:

The Truth Is Paywalled But The Lies Are Free
https://www.currentaffairs.org/2020/08/the-truth-is-paywalled-but-the-lies-are-free/



From petite.abeille at gmail.com  Tue Dec 15 10:53:55 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 11:53:55 +0100
Subject: Proposal: Rabbits in gemtext
In-Reply-To: <20201215075616.GA5495@sources.org>
References: <20201215014826.doa34rpynuiye7zz@GLaDOS>
 <20201215075616.GA5495@sources.org>
Message-ID: <C9DA04B0-072C-43B0-AE0C-D65A6A2FEDD5@gmail.com>



> On Dec 15, 2020, at 08:56, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> I won't. My mother told me not to feed the trolls (specially the ugly and stupid ones).

Let's not such triviality prevent us from enjoying some good reads!

Consider the Hare
https://www.lrb.co.uk/the-paper/v42/n13/katherine-rundell/consider-the-hare

??


From petite.abeille at gmail.com  Tue Dec 15 13:27:36 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 15 Dec 2020 14:27:36 +0100
Subject: Unicode vs. the World
Message-ID: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>

[In the spirit of Scott Pilgrim vs. the World]

There has been a handful of  intertwingled* conversation about the topic.


To recap:

2020-12-04 Stephane Bortzmeyer got the ball rolling with "IDN with Gemini?": https://lists.orbitalfox.eu/archives/gemini/2020/003788.html
2020-12-08 John Cowan followed with "Three possible uses for IRIs": https://lists.orbitalfox.eu/archives/gemini/2020/003873.html
2020-12-09 Jason McBrayer contributed "Some reading on IRIs and IDNs": https://lists.orbitalfox.eu/archives/gemini/2020/003923.html

?? To be charitable, we can also include Alex's self-described "shitpost"  dated 2020-12-15 : https://lists.orbitalfox.eu/archives/gemini/2020/004055.html

[2020-12-15T01:47:20.412Z] <nytpu> sending an message to the ML making fun of the long-running spec-changing threads. i'll probably regret it, but here goes
[2020-12-15T07:05:14.499Z] <nytpu> i've bitched about it but this is the first time i've really addressed the points other than in passing
[2020-12-15T07:05:42.682Z] <nytpu> and even then it's more a shitpost than a real rebuttal, don't take it too seriously


So what's the issue making Alex lose his marbles, thin-skin aside?

It boils down to this:

 => gemini://?.mozz.us/?.gmi ?Hoppity hop?

What do do with such a construct? Possible? Not possible? Allowed? Not allowed? First class citizen? Afterthought? How do deal with it, if at all? 

Decisions, decisions, decisions.

Technically speaking, while text/gemini is Unicode friendly by default, the links are not. The location part must be encoded, following idiosyncratic, local customs, perhaps such as:

 => gemini://xn--4o8h.mozz.us/%F0%9F%90%87.gmi ?Hoppity hop?

In other words, a bit of punycode + percent encoding + glossing over normalization + other niceties. Everything must be US-ASCII clean at the end of the day.

Some will make the distinction between "content" vs. "addressing":

[2020-12-15T07:35:09.590Z] <bie> also... this was never about internationalized content, but a lot of people like to pretend that it is
[2020-12-15T07:36:40.861Z] <bie> addressing != content

While there are some merits about such hair splitting -as it has be handled at different level of the stack- it distracts from the crux of the problem:

=> gemini://?.mozz.us/?.gmi ?Hoppity hop? 
vs.
=> gemini://xn--4o8h.mozz.us/%F0%9F%90%87.gmi ?Hoppity hop?

As it stands, the first variant cannot be handled by gemini -neither in text/gemini, nor in the protocol itself- with further technical gotchas such as address resolution and what not along the way. 

It must be converted to the second variant, the US-ASCII one.

So, what to do? This is what these various conversations are about. Exploring what the scope of the problem is, and what to do about it, if anything. So one can eventually reach an informed decision.

For example:

[2020-12-14T22:12:14.914Z] <remyabel> I lurk this channel and the mailing lists and keep seeing people trying to extend gemini or make it web-like, there's just no point in arguing against it
[2020-12-14T22:12:28.578Z] <CoopDot> I used to be in the US-ASCII only camp but now it's more "do the bare mininum to not forbid UTF-8 'URLs' in the spec and make strong recommendations in best-practices.gmi"

^Those are the "cannot be arsed" camp: things are the way they are, and cannot be bothered to changed anything, technically speaking... we are done. The "not-my-problem" camp.


[2020-12-15T07:30:13.193Z] <khuxkm> honestly my issue with the iri thread was the whole "we NEED this" and "we MUST do this it's our MORAL DUTY"
[2020-12-15T07:30:52.931Z] <khuxkm> like forcing everybody to use IRIs or be non-compliant with the spec is somehow going to solve discrimination

^Those are the... hmmm... oh-so-fragile "entitled" camp.


To summarize: this is a genuine choice for gemini. And not so much a technical issue.


-- 
?????


Tangentially unrelated, as always:

The Internet is for End Users
https://tools.ietf.org/html/rfc8890

Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs
https://tools.ietf.org/id/draft-knodel-terminology-04.html


* https://en.wikipedia.org/wiki/Intertwingularity



From bjorn.warmedal at gmail.com  Tue Dec 15 15:05:14 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Tue, 15 Dec 2020 16:05:14 +0100
Subject: Unicode vs. the World
In-Reply-To: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
Message-ID: <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>

Thank you so much for the summary! I lost track of the ML for a few
days and... it was just too much >.<

My contention is this: I want us to support internationalization as
best we can. And as far as I understand it the web has done this with
punycoded domain names and percent encoded paths for years. And after
a few hours of fiddling with my own cli tool gemcall
(https://notabug.org/tinyrabbit/gemcall/src/master/gemcall) it doesn't
look like it's too hard. Check line 35:

parsed = up.urlparse(url).encode("idna")

As far as I can tell gemcall can now handle gemini://[rabbit emoji
that I don't know how to include...].mozz.us/

As for the path that follows, that must be percent encoded in the
gemtext document. There is no way for a client to know if a path is
already percent encoded or not, and percent encoding twice breaks the
link. Consider this:
=> gemini://example.com/why-space-is-%20-in-urls.gmi We see that this
needs to be percent encoded, but a tool can't reliably tell if it does
or if it is already.

Requiring clients to punycode domain names will break existing
clients. Sorry about that, but let's just fix them instead of
complaining about it.

Cheers,
ew0k

Oh! Mandatory rabbit!

 ()_()
 (^.^)
_(| |)_

From alex at nytpu.com  Tue Dec 15 15:28:00 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Tue, 15 Dec 2020 08:28:00 -0700
Subject: Unicode vs. the World
Message-ID: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>

This is the only time I'm going to reply to one of these threads, but I
should actually say what I think: Supporting IDNs and IRIs is something
I can get behind, but it simply doesn't require a spec change. Maybe a
"Gemini Best Practices" change, or even (in the extreme) a companion
spec detailing the basics of punycoding and percent encoding, but that's
it.


Firstly, on IRIs: there is literally no reason not to support them. You
already percent-encode half of ascii anyways, why not just encode the
rest? 100% on board.

IDNs I also agree with, as long as it doesn't get too out of hand with
what you're requiring from people, and as long as at least some
consideration is given to people's more obscure languages that may or
may not have various necessary libraries. I still think it should be
supported, but I'd say to heed the robustness principle: "Be liberal in
what you accept, and conservative in what you send."


I support allowing people to write in unicode in gemtext, including in
link lines, but the client should convert it (transparently or not) for
the server, no spec change required. Look at what Lagrange did for
v0.13! It even displays the unicode URL in the address bar, and deals
with all the conversions so the content authors and users don't even
have to think about it. That's the optimal change for an "advanced"
client I'd say, and a "simple" client could just convert it to
punycode/percent encoded once and display and work with that afterwards
so they don't have to worry about the unicode version internally.
https://gmi.skyjake.fi/lagrange/

My main complaint I have is how long these threads run, and how they
completely overtake the mailing list, drowning out pretty much
everything else. Even if they were arguing about something I
passionately argue for, I'd still make fun of them because they're so
long that they're farcical. They're full of people misreading everything
that's being said (I'm within that group), people that argue about
something else that's vaguely related but not really. The first thread
was about IDNs and people immediately started talking about IRIs
instead! (or maybe vice-versa? I can't keep the two terms straight).

***

The main reason I wrote this is to clarify that I am firmly against
changing the spec, no matter how noble the causes, for anything other
than clarification or typos. There are lots of possibilities that don't
require a spec change, both in internationalization support and the
other common mailing list complaints that were long like this thread in
the past (usually about gemtext's "weaknesses").

Just go and do your own thing, experiment, chat on the mailing list
about something if it requires client/server support, and maybe people
will support it! You can use their experience to guide you before
actually suggesting any real best practice changes, companion specs,
etc. For instance, Lagrange really changed my opinion. Its change to
support the full suite of Iwhatevers was much simpler than I expected,
which lightened up my opinion, because I was worried it would result in
web-browser levels of just annoying and impossible for an individual to
write. ("TLS is bad enough, but at least all but the most esoteric
languages have a library somewhere.") Lagrange showed it's actually not
that bad, adding it in was no worse than regular URI parsing.

In summary, Just experiment, chat on the ML (preferably on multiple
topics...) and just do cool stuff! It's what gemini is all about, isn't
it?

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201215/aef6462f/attachment.sig>

From come at chilliet.eu  Tue Dec 15 15:41:27 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Tue, 15 Dec 2020 16:41:27 +0100
Subject: Unicode vs. the World
In-Reply-To: <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>
Message-ID: <1691977.GtXugi2lUL@tempete>

Le mardi 15 d?cembre 2020, 16:05:14 CET Bj?rn W?rmedal a ?crit :
> As for the path that follows, that must be percent encoded in the
> gemtext document. There is no way for a client to know if a path is
> already percent encoded or not, and percent encoding twice breaks the
> link. Consider this:
> => gemini://example.com/why-space-is-%20-in-urls.gmi We see that this
> needs to be percent encoded, but a tool can't reliably tell if it does
> or if it is already.

This is not true, even when using IRI, reserved characters such as spaces HAVE to be percent-encoded.

So, if you see a "%", it is percent encoding. If you want to link to a path containing a percent, you have to percent encode the percent, resulting in %25.

As a result, percent encoding twice does not break the link, as you only percent encode what is not percent encoded already.

C?me



From linde.philip at gmail.com  Tue Dec 15 16:30:20 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Tue, 15 Dec 2020 17:30:20 +0100
Subject: Unicode vs. the World
In-Reply-To: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>
References: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>
Message-ID: <20201215173020.a7d95f461af710ee99e67396@gmail.com>

On Tue, 15 Dec 2020 08:28:00 -0700
Alex // nytpu <alex at nytpu.com> wrote:

> My main complaint I have is how long these threads run, and how they
> completely overtake the mailing list, drowning out pretty much
> everything else. Even if they were arguing about something I
> passionately argue for, I'd still make fun of them because they're so
> long that they're farcical. They're full of people misreading everything
> that's being said (I'm within that group), people that argue about
> something else that's vaguely related but not really. The first thread
> was about IDNs and people immediately started talking about IRIs
> instead! (or maybe vice-versa? I can't keep the two terms straight).

I highly recommend using a client with a clearly threaded overview of
incoming messages. For example, if I am not interested in a particular
thread of discussion, or it has become hard to follow, I can just fold
it away. We should perhaps be better at changing the subject line in
cases where discussion delves into details or strays from the original
topic.

I believe that misreading fills an important function when discussing a
specification; even a fundamentally bad-faith reading is useful. In my
opinion a spec should leave as little room for interpretation as
possible, and misreading exposes these little ambiguities at an earlier
stage where they would otherwise later cause divergent implementations.
It also makes it clear when ideas are more complex than anticipated. I
think we hit an iceberg with IDN/IRI, and we've failed to properly
separate discussion about its rationale from discussion about its
implementation, possibly because Gemini is explicit in that its
rationale also concerns its implementation details (paraphrased: it
should be simple and easy to implement).

> The main reason I wrote this is to clarify that I am firmly against
> changing the spec, no matter how noble the causes, for anything other
> than clarification or typos. There are lots of possibilities that don't
> require a spec change, both in internationalization support and the
> other common mailing list complaints that were long like this thread in
> the past (usually about gemtext's "weaknesses").

I agree with this, at least to the point that changes, if any, should
guarantee forward compatibility with older implementations. Breaking
changes have a high cost and so should be reserved for breaking bugs,
not nice-to-haves or workable practical shortcomings. There are many
features that I think would improve the protocol when thought of as
just features, but would be detrimental when considering the social
burden of formalizing and implementing them. I'll happily trade those
features for a stable and clear spec.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201215/8e8d01d7/attachment.sig>

From stephane at sources.org  Tue Dec 15 17:26:14 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 15 Dec 2020 18:26:14 +0100
Subject: Unicode vs. the World
In-Reply-To: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>
References: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>
Message-ID: <20201215172614.GB21868@sources.org>

On Tue, Dec 15, 2020 at 08:28:00AM -0700,
 Alex // nytpu <alex at nytpu.com> wrote 
 a message of 100 lines which said:

> My main complaint I have is how long these threads run, and how they
> completely overtake the mailing list, drowning out pretty much
> everything else.

[I agree with Philip: reading email without a threaded email reader is
a bad idea.]

I'm relatively new here, so I used the mailing list but if there are
other ways to discuss and follow the work on the specification (or in
companion documents, such as robots.txt standard), I'd be happy to use
them. Issues on a ticket tracker at a Gitlab?

From stephane at sources.org  Tue Dec 15 17:23:07 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 15 Dec 2020 18:23:07 +0100
Subject: Unicode vs. the World
In-Reply-To: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
Message-ID: <20201215172307.GA21868@sources.org>

On Tue, Dec 15, 2020 at 02:27:36PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 122 lines which said:

> To summarize: this is a genuine choice for gemini. And not so much a
> technical issue.

It is quite possible that there is unanimity on these two points. So,
at least, we all agree on something.


From text at sdfeu.org  Tue Dec 15 18:38:38 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Tue, 15 Dec 2020 18:38:38 -0000 (UTC)
Subject: Unicode vs. the World
References: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>
 <20201215172614.GB21868@sources.org>
Message-ID: <rravre$ian$1@ciao.gmane.io>

On Tue, 15 Dec 2020 18:26:14 +0100, Stephane Bortzmeyer wrote:

> [I agree with Philip: reading email without a threaded email reader is a
> bad idea.]
> 
> [?] other ways to discuss and follow the work on the specification [?]
> Issues on a ticket tracker at a Gitlab?

Not sure if Usenet newsgroups are still a thing to start these days, but 
I like that news does not clutter personal e-mail accounts.

No idea how and where  comp.protocols.gemini  could be established.


From pjvm742 at disroot.org  Tue Dec 15 19:11:12 2020
From: pjvm742 at disroot.org (PJ vM)
Date: Tue, 15 Dec 2020 20:11:12 +0100
Subject: Unicode vs. the World
In-Reply-To: <1691977.GtXugi2lUL@tempete>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>
 <1691977.GtXugi2lUL@tempete>
Message-ID: <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>

On 12/15/20 4:41 PM, C?me Chilliet wrote:
> So, if you see a "%", it is percent encoding. If you want to link to 
> a path containing a percent, you have to percent encode the percent, 
> resulting in %25.
> 
> As a result, percent encoding twice does not break the link, as you 
> only percent encode what is not percent encoded already.

So that would define a special percent-encoding for clients, where
they'd encode everything except percent signs, right? So in this link:
=>gemini://example.com/????-why-space-is-%20-in-urls.gmi
, a client would have to percent-encode the emojis, but leave the "%20"
bit alone? This seems very confusing; it's also not one-to-one (encoding
then decoding "%20" gives " " back)... And if you just skip
percent-encoding when the only "encodable" characters in the path are
percent signs, that's confusing too. That rule also doesn't work on
=>gemini://example.com/%XY.gmi

Also, if an author wants to link to "why-space-is-%20-in-urls.gmi" at
example.com, the only option would be to write
=>gemini://example.com/why-space-is-%2520-in-urls.gmi
This introduces a pitfall for authors: they never have to think about
percent-encoding, *except* when there are percent signs in the path.

How is this better than agreeing that link paths in gemtext are always
completely percent-encoded? In that case, clients can percent-decode the
path and display that. Authors could use a tool that 'fully' (as in, it
also turns every "%" into "%25") percent-encodes a link for them.

Counterintuitively, in this way I think mandating completely
percent-encoded paths in gemtext link lines might actually result in
easier linking for authors.

The same (clients may/should display, authors use tool) could be done
with internationalised domain names (could be the same tool that does
the percent-encoding), but crucially there is no ambiguity there,
because an ascii domain name with "xn--" is unrepresentable in punycode
and disallowed (I think). On the other hand, allowing anything
whatsoever in the domain name and nothing in the path would be strange
and a bit inconsistent.

Assuming we don't do IRI paths in gemtext link lines, I don't really
have an clear opinion regarding IDNs, the choice is between:
* all clients need to convert to punycode when following a link, authors
can easily link to IDNs without a tool (though they're already using a
tool for unicode paths), somewhat inconsistent/strange
* fancy clients will convert from punycode when displaying a link,
authors need a tool to be able to easily make links to IDNs (though
they're already using a tool for unicode paths)

--
pjvm

From come at chilliet.eu  Tue Dec 15 20:00:33 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Tue, 15 Dec 2020 21:00:33 +0100
Subject: Unicode vs. the World
In-Reply-To: <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <1691977.GtXugi2lUL@tempete>
 <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
Message-ID: <1929208.OtTX6HifbA@tempete>

Le mardi 15 d?cembre 2020, 20:11:12 CET PJ vM a ?crit :
> So that would define a special percent-encoding for clients, where
> they'd encode everything except percent signs, right? So in this link:
> =>gemini://example.com/????-why-space-is-%20-in-urls.gmi
> , a client would have to percent-encode the emojis, but leave the "%20"
> bit alone? This seems very confusing; it's also not one-to-one (encoding
> then decoding "%20" gives " " back)... And if you just skip
> percent-encoding when the only "encodable" characters in the path are
> percent signs, that's confusing too. That rule also doesn't work on
> =>gemini://example.com/%XY.gmi

Because this is not a valid link, neither URI nor IRI.

> Also, if an author wants to link to "why-space-is-%20-in-urls.gmi" at
> example.com, the only option would be to write
> =>gemini://example.com/why-space-is-%2520-in-urls.gmi
> This introduces a pitfall for authors: they never have to think about
> percent-encoding, *except* when there are percent signs in the path.

Yes, and spaces, and delimiter characters, such as "/".

> How is this better than agreeing that link paths in gemtext are always
> completely percent-encoded? In that case, clients can percent-decode the
> path and display that. Authors could use a tool that 'fully' (as in, it
> also turns every "%" into "%25") percent-encodes a link for them.

Because a completely percent encoded link is hell to read and to write, for instance:
gemini://gemini.circumlunar.space/%64%6f%63%73/%66%61%71%2e%67%6d%69

So I think you do not mean ?completely percent-encoded?, you mean percent encode non-ascii non-reserved text, and you feel like this is better because you are use to english and ascii.
But you will always need to remember which chars you need to percent encode. You will never be able to use "/" in a file name without percent encoding. Or "?".

> Counterintuitively, in this way I think mandating completely
> percent-encoded paths in gemtext link lines might actually result in
> easier linking for authors.

No, it is just a different set of characters to percent encode.

> The same (clients may/should display, authors use tool) could be done
> with internationalised domain names (could be the same tool that does
> the percent-encoding), but crucially there is no ambiguity there,
> because an ascii domain name with "xn--" is unrepresentable in punycode
> and disallowed (I think). On the other hand, allowing anything
> whatsoever in the domain name and nothing in the path would be strange
> and a bit inconsistent.

Yes, IDN are covered by punycode, but the question remains whether I am allowed to use the unicode form in a link line.
=> gemini://g?meaux.example.com Is that legal?
 
> Assuming we don't do IRI paths in gemtext link lines, I don't really
> have an clear opinion regarding IDNs, the choice is between:
> * all clients need to convert to punycode when following a link, authors
> can easily link to IDNs without a tool (though they're already using a
> tool for unicode paths), somewhat inconsistent/strange
> * fancy clients will convert from punycode when displaying a link,
> authors need a tool to be able to easily make links to IDNs (though
> they're already using a tool for unicode paths)

Yes.
I am for IDN in link lines, but I am also in favor of IRI in link lines.
And I would be supportive of using IRI in request line also for that matter. And redirect responses.

C?me



From come at chilliet.eu  Tue Dec 15 20:19:36 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Tue, 15 Dec 2020 21:19:36 +0100
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
References: <3489664.TY8R3EpOMY@tempete>
 <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
Message-ID: <1857962.TKIm2rkbc4@tempete>

Le dimanche 13 d?cembre 2020, 18:28:38 CET Jansen Price a ?crit :
> I ran into the same problem when trying to add client certificate support
> on my PHP server (https://tildegit.org/sumpygump/orbit)
> 
> I think that `capture_peer_cert` is intended to only work
> with stream_socket_client and not with socket servers. I started looking at
> the source code of PHP to see if I could find the part that handles the TLS
> handshake to find out if there is any way to get access to the cert that
> came along with the connection, but I have not been successful in my search
> yet.

I tried posting on php-internals ML, but no answer so far:
https://news-web.php.net/php.internals/112495

We can try the bug tracker but I?ve seen bugs related to streams and/or encryption with no answer since a long time :-/

I think the best solution is to try to come with a PR.

C?me



From come at chilliet.eu  Tue Dec 15 21:08:16 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Tue, 15 Dec 2020 22:08:16 +0100
Subject: Synchronizing bookmarks - Request for comments
Message-ID: <3303060.5uuezQRsQv@tempete>

Hello,

I?ve put together an idea of simple specification to allow clients to synchronize bookmarks and feeds across Gemini, as this is something that I?m currently missing in my daily Gemini use.

You can read it at gemini://gemlog.lanterne.chilliet.eu/2020-12-15%20link-sync-rev-1.en.gmi

I?m particularly interested in comments from client authors:
* Would you consider implementing support for something like this?
* Does your client have some kind of plugin system which would allow a third-party to add support?

C?me



From colecmac at protonmail.com  Tue Dec 15 21:32:15 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Tue, 15 Dec 2020 21:32:15 +0000
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <3303060.5uuezQRsQv@tempete>
References: <3303060.5uuezQRsQv@tempete>
Message-ID: <eS3kJhV4uVRqulFZbF7bjCK3M08UdAmljQrtsohWCU960CUGTfobApJ7Knt3UmD7a_NvSZfq7pL4T2k_eW5btCnMxPTZIFwVcSxvVCE-e0M=@protonmail.com>

Hello,

I was initially excited by this email because I thought it was proposal
for how to share bookmarks across clients on the same machine, similar to
Drew's idea for TOFU. But it seems it's about synchronizing bookmarks and
subscriptions across the network, using the Gemini protocol.

First off I appreciate the write up, it's nice to have these longer-form
ideas in Gemini. Secondly, I think this misusing the Gemini the protocol
and is outside its scope. I think this is similar to how Gemini doesn't have
a clear way for authors to send files to a server. If you want to push data
to a server, I think Gemini is not the thing to use.

While I personally don't have the need to synchronize my Gemini bookmarks
and subscriptions, several Amfora users have told me that they synchronize
their Amfora data and settings, and they do so through external means as one
might expect. Git repos mainly, but I wouldn't be surprised to hear about people
using sftp, rsync, etc. I don't think this bespoke protocol would be advantageous
to these people.

Obvious these are technical solutions, but I'm biased because Amfora is a terminal
based client. But I think that synchronizing files across the network is already
a technical operation, and a more user-friendly option like syncthing would
still work fine for people.


To answer the questions directly asked:

> Would you consider implementing support for something like this?

Not really, for the reasons I explained above. I'd be happy to hear why you think
I'm wrong though.

> Does your client have some kind of plugin system which would allow a third-party
> to add support?

Amfora does not. It's an interesting idea and I'm open to it, but I'm not entirely
sure how it would work, or what sort of things the plugins would hook in to.


Now, I don't want to hijack your thread... but if anyone is interested in a common
format for Gemini bookmarks as I mentioned earlier, an Amfora user proposed[1]
XBEL[2] to me, and I plan on implementing it in the next-next release, replacing the
TOML format being currently used, which was a bad choice for that purpose. Is
this something other client authors would like to do as well?


1: https://github.com/makeworld-the-better-one/amfora/issues/68#issuecomment-674424896
2: http://xbel.sourceforge.net/


Cheers,
makeworld

From adrianhesketh at hushmail.com  Tue Dec 15 22:38:54 2020
From: adrianhesketh at hushmail.com (Adrian Hesketh)
Date: Tue, 15 Dec 2020 22:38:54 +0000
Subject: Hosting several sites on the same host
In-Reply-To: <2248433.n8l4AnvsTd@tempete>
References: <3167385.IEBFgDKfjZ@tempete> <87mtywo67e.fsf@omarpolo.com>
 <2248433.n8l4AnvsTd@tempete> 
Message-ID: <20201215223854.4C915804B8B@smtp.hushmail.com>

I don't know if it will help you, but here's a walkthrough of how my
Go implementation. It's quite tied to the Go implementation, but there
may be similar capabilities in PHP.
Firstly, the server keeps a map of the domain name to the underlying
Gemini handler (the code that processes the request), and the TLS
certificate to be used for that domain. The Go TLS library allows a
"GetCertificate" function to be added to the TLS configuration. This
"GetCertificate" function is called during the TLS handshake and
returns the certificate to present to the client (dh.KeyPair) based on
the hostname being requested during the handshake.
https://github.com/a-h/gemini/blob/598044444c08befc3c01bafe5558a5decb83ab40/server.go#L180
With that configuration in place, the server enters a loop that
listens for new incoming connections:
https://github.com/a-h/gemini/blob/598044444c08befc3c01bafe5558a5decb83ab40/server.go#L197
When a new connection is received, it's handled in another goroutine
(similar to a thread) by the handleTLS function. This allows the loop
to listen for new connections while content is being served by the
goroutine.
https://github.com/a-h/gemini/blob/598044444c08befc3c01bafe5558a5decb83ab40/server.go#L211
Now that the handshake is over, but the Gemini request/response needs
to take place, the handleTLS function has to read the domain name
again to look up which Gemini handler to use for the domain that was
accessed:
https://github.com/a-h/gemini/blob/598044444c08befc3c01bafe5558a5decb83ab40/server.go#L235
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201215/7988798b/attachment-0001.htm>

From sean at conman.org  Tue Dec 15 22:42:28 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 15 Dec 2020 17:42:28 -0500
Subject: On mailing lists (was Re: Unicode vs. the World)
In-Reply-To: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>
References: <20201215152800.6hn34r3rcvapfi3o@GLaDOS>
Message-ID: <20201215224228.GQ24194@brevard.conman.org>

It was thus said that the Great Alex // nytpu once stated:
> 
> My main complaint I have is how long these threads run, and how they
> completely overtake the mailing list, drowning out pretty much
> everything else. 

  You haven't been here long, have you?  Becaus for *months* this list
talked almost exclusively about text/gemini.  Just check the threaded
archives [1] and look upon the threads, ye mighty, and despair!  Take
special note how long the thread "Text reflow woes" goes (from 2019 well
into 2020).

  It's also worth to note that different people have different expectations
as to volume of email.  I've been on lists where people freak out if they
get more than 1 email per day.  Personally, I consider the volume of this
list to be low-to-mid levels of volume.  One list I was one (it is no longer
around) would typically get around double digits of email per day, and on
one memerable day, hit 500 messages (yes, 500 email in a single day---that
set my expectations on what a "high-volume mailing list" is).

  -spc

[1]	https://lists.orbitalfox.eu/archives/gemini/2019/thread.html
	https://lists.orbitalfox.eu/archives/gemini/2020/thread.html

From me at adnano.co  Tue Dec 15 22:42:29 2020
From: me at adnano.co (Adnan Maolood)
Date: Tue, 15 Dec 2020 22:42:29 GMT
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <eS3kJhV4uVRqulFZbF7bjCK3M08UdAmljQrtsohWCU960CUGTfobApJ7Knt3UmD7a_NvSZfq7pL4T2k_eW5btCnMxPTZIFwVcSxvVCE-e0M=@protonmail.com>
Message-ID: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro>

On Tue Dec 15, 2020 at 4:32 PM EST,  wrote:
> Now, I don't want to hijack your thread... but if anyone is interested in a common
> format for Gemini bookmarks as I mentioned earlier, an Amfora user proposed[1]
> XBEL[2] to me, and I plan on implementing it in the next-next release, replacing the
> TOML format being currently used, which was a bad choice for that purpose. Is
> this something other client authors would like to do as well?

What about using a plain Gemini text file for storing bookmarks? That
would make it very easy for people to manage their bookmarks externally.
You could implement folders as level 1 or 2 headings in the file.

For example:

# Folder 1
=> gemini://gemini.circumlunar.space Project Gemini
=> gemini://example.com Example Bookmark

# Folder 2
=> gemini://example.org Example Bookmark

From come at chilliet.eu  Tue Dec 15 22:47:52 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Tue, 15 Dec 2020 23:47:52 +0100
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <eS3kJhV4uVRqulFZbF7bjCK3M08UdAmljQrtsohWCU960CUGTfobApJ7Knt3UmD7a_NvSZfq7pL4T2k_eW5btCnMxPTZIFwVcSxvVCE-e0M=@protonmail.com>
References: <3303060.5uuezQRsQv@tempete>
 <eS3kJhV4uVRqulFZbF7bjCK3M08UdAmljQrtsohWCU960CUGTfobApJ7Knt3UmD7a_NvSZfq7pL4T2k_eW5btCnMxPTZIFwVcSxvVCE-e0M=@protonmail.com>
Message-ID: <5643435.0kOH9MyLex@tempete>

Le mardi 15 d?cembre 2020, 22:32:15 CET colecmac at protonmail.com a ?crit :
> To answer the questions directly asked:
> 
> > Would you consider implementing support for something like this?
> 
> Not really, for the reasons I explained above. I'd be happy to hear why you think
> I'm wrong though.

From what I gather from your answer, your take on the synchronizing bookmarks across clients/computers is to use a common format (like xbel), and to use an external system to synchronize this file across computers.

I can appreciate the KISS aspect of this.

My usecase is more like synchronizing lagrange and a client on my mobile phone (currently ariane, but I may change if another one come up), and I?m not convinced it will be one day possible/easy to do it like you suggested, given how files are handled on Android.

An other answer to my problem would be using something like https://github.com/kensanata/moku-pona and use it though any client, but I like having my feeds and bookmarks well integrated into my brower lagrange, so I?d really prefer a solution which fits in the client and not only a Gemini capsule with some interaction.

My solution is also inspired by web browser addons like wallabag and pocket which adds a read-it-later feature well integrated in the browser.

C?me



From skyjake at dengine.net  Wed Dec 16 06:57:49 2020
From: skyjake at dengine.net (skyjake)
Date: Wed, 16 Dec 2020 08:57:49 +0200
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <3303060.5uuezQRsQv@tempete>
References: <3303060.5uuezQRsQv@tempete>
Message-ID: <48F18C46-520A-4E5B-AD3D-7DE743B68737@dengine.net>

On 15. Dec 2020, at 23:08, C?me Chilliet <come at chilliet.eu> wrote:

> I?ve put together an idea of simple specification to allow clients to synchronize bookmarks and feeds across Gemini, as this is something that I?m currently missing in my daily Gemini use.
> 
> You can read it at gemini://gemlog.lanterne.chilliet.eu/2020-12-15%20link-sync-rev-1.en.gmi

I think this is a valid use case, and it's something I have been thinking about myself just running Lagrange on a number of different computers. When you bring in a mix of different clients and desktop/mobile operating systems, sync is even more important.

The lowest common denominator should be export to/import from a .gmi file. Such a file (that Adnan Maolood suggested, for example) is guaranteed to be at least viewable by all clients. It supports folders, has no line length limitations, and can support tags as well (e.g., an optional line/bullet/quote following a link).  The user can then manually manage the files via any means they see fit.

However, the UX of doing that on an ongoing basis to sync your bookmarks/feeds isn't great. An automated mechanism is certainly more desirable.

When it comes to basing sync on the Gemini protocol, it makes a certain amount of sense (clients know how to do Gemini requests) but it's not a perfect fit:

* one add/del per request ? what if you have a 100 bookmarks to sync?
* request URL length limit
* does not address tags, folders, manual ordering

> * Would you consider implementing support for something like this?

Something like this, yes.

The current proposal needs revising, though. I suggest creating a mechanism that allows using Gemini subscriptions as a core part of the sync. A client would view and/or subscribe to a bookmarks page served by the bookmark sync server. Client-side, the subscription would track all links instead of dated links, and ensure that all links on the bookmarks page have copies in the local set of bookmarks. (And somehow get rid of deleted bookmarks, too.)

This way,  a public bookmarks feed could be served as a static file by any Gemini server.

It's a good idea that a client cert is used to ensure privacy of the served bookmarks, unless they are meant to be public.

The upload part is where it's gets tricky, and I don't think the Gemini protocol should be used for that. As a client author what I'd like to see is that I just export the bookmarks .gmi file as usual, and then send it to the server, perhaps via a TLS socket at a port specifically reserved for uploads ? just open a socket, set a client cert, and write the .gmi file to the socket. The client cert would be required for user identification. It would be up to the server to merge the bookmarks and get rid of deleted ones on server-side.

This does make things a bit more difficult for the server implementation, but keeping things easy for clients at least encourages wider support.

> * Does your client have some kind of plugin system which would allow a third-party to add support?

Not currently. However, Lagrange's MIME hooks could be extended to allow manual activation, so you could run an external program on your "about:bookmarks" page to do the sync. It would need to edit the internal bookmarks.txt file, and Lagrange would then need to detect that the file has changed after the hook program finishes. I wouldn't prefer going down this route, though. It's better to have a mechanism that benefits all clients equally.

So let's keep working on this! Automatic bookmark (and client cert?) sync would be great features for Gemini clients.

--jaakko

From bjorn.warmedal at gmail.com  Wed Dec 16 07:59:07 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Wed, 16 Dec 2020 08:59:07 +0100
Subject: Unicode vs. the World
In-Reply-To: <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>
 <1691977.GtXugi2lUL@tempete>
 <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
Message-ID: <CAJScK0Jri4oMXEZL1Ve1jsZVdm6_1RqW_sapmVacGpor0ZZGtg@mail.gmail.com>

> How is this better than agreeing that link paths in gemtext are always
> completely percent-encoded? In that case, clients can percent-decode the
> path and display that. Authors could use a tool that 'fully' (as in, it
> also turns every "%" into "%25") percent-encodes a link for them.
>
> Counterintuitively, in this way I think mandating completely
> percent-encoded paths in gemtext link lines might actually result in
> easier linking for authors.

This is -- as I read it -- what the spec requires now. I think that's
the best solution. The wording in the spec can (and maybe should) be
clarified, though.

> * all clients need to convert to punycode when following a link, authors
> can easily link to IDNs without a tool (though they're already using a
> tool for unicode paths), somewhat inconsistent/strange
> * fancy clients will convert from punycode when displaying a link,
> authors need a tool to be able to easily make links to IDNs (though
> they're already using a tool for unicode paths)

I think that all clients *should* convert links to punycode. If they
did authors could write punycoded or unicode domains in their links
and both would work.

Right now authors can't expect clients to punycode for them, so the
safest recourse is to punycode links yourself before publishing.

Note that none of this requires a spec change (except for maybe
clarifying the percent encoding of links in gemtext). I think it's
fair to assume that IDNs will just work, and if they don't work in a
browser/client we can report that as a bug (or send a PR that fixes
it). After all IDNs have existed for some years, and URL libs across
languages are very likely to support it.

Cheers,
ew0k

??

From jmcbray at carcosa.net  Wed Dec 16 14:13:37 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 16 Dec 2020 09:13:37 -0500
Subject: Unicode vs. the World
In-Reply-To: <CAJScK0Jri4oMXEZL1Ve1jsZVdm6_1RqW_sapmVacGpor0ZZGtg@mail.gmail.com>
 (=?utf-8?Q?=22Bj=C3=B6rn=09W=C3=A4rmedal=22's?= message of "Wed, 16 Dec
 2020 08:59:07 +0100")
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>
 <1691977.GtXugi2lUL@tempete>
 <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
 <CAJScK0Jri4oMXEZL1Ve1jsZVdm6_1RqW_sapmVacGpor0ZZGtg@mail.gmail.com>
Message-ID: <87k0thj0tq.fsf@dorothy.carcosa.net>

Bj?rn W?rmedal <bjorn.warmedal at gmail.com> writes:

>> How is this better than agreeing that link paths in gemtext are always
>> completely percent-encoded? In that case, clients can percent-decode the
>> path and display that. Authors could use a tool that 'fully' (as in, it
>> also turns every "%" into "%25") percent-encodes a link for them.
>>
>> Counterintuitively, in this way I think mandating completely
>> percent-encoded paths in gemtext link lines might actually result in
>> easier linking for authors.
>
> This is -- as I read it -- what the spec requires now. I think that's
> the best solution. The wording in the spec can (and maybe should) be
> clarified, though.

I don't think this is going to be acceptable for authors. It's
unreasonable to ask authors to use a tool other than their favorite text
editor to write gemtext. Why is it reasonable for the client to have to
punycode the domain (an uncommon encoding for which not every common
language has a library), but unreasonable for it to have to urlencode
the path (a common encoding for which libraries are ubiquitous)? Why is
it so hard to convince people to just do the right thing?

???

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From pjvm742 at disroot.org  Wed Dec 16 14:22:33 2020
From: pjvm742 at disroot.org (PJ vM)
Date: Wed, 16 Dec 2020 15:22:33 +0100
Subject: Unicode vs. the World
In-Reply-To: <1929208.OtTX6HifbA@tempete>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <1691977.GtXugi2lUL@tempete>
 <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
 <1929208.OtTX6HifbA@tempete>
Message-ID: <8c7ba0e1-29a3-ab57-a625-28a678c6ffe9@disroot.org>

On 12/15/20 9:00 PM, C?me Chilliet wrote:
>> =>gemini://example.com/%XY.gmi
> Because this is not a valid link, neither URI nor IRI.

My thinking was that it is a valid link after percent-encoding.

But OK, so the client would percent-encode exactly those characters that
are not reserved but not in ascii. That would indeed be unambiguous. It
would not be one-to-one with percent-decoding, though, which is
unavoidable with this approach to IRIs.

> a completely percent encoded link ...

Yes, that was a misuse of the word "completely" on my part

> you feel like this is better because you are use to english and
> ascii.

That is a failed attempt at mind-reading.

> But you will always need to remember which chars you need to percent
> encode. You will never be able to use "/" in a file name without
> percent encoding. Or "?".

Yes, when someone wants to link to a resource with "?", "/" or "#" in
the filename, that will basically always require manual intervention.

One error in my previous email was that of course, you can also use a
tool to percent-encode just spaces and percent signs for you. There's
not much difference in what the author has to think about, then.

Still, with both IRI paths and IDNs, I'm not really seeing the "added
value" of having them in the spec. I'm quite sure they will be there
either way: if it doesn't get into the spec, it is still possible for
clients to provide the same experience with (seemingly) about the same
amount of programming effort - and it seems plenty of client authors
would -, and authors would not be much worse off if they use a tool.

Meanwhile, the negatives are rather visible to me: they're breaking
changes, they increase the complexity that a client *must* have.

-- 
pjvm

From stephane at sources.org  Wed Dec 16 15:05:50 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 16 Dec 2020 16:05:50 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
Message-ID: <20201216150549.GA19202@sources.org>

I'm running a Gemini crawler, which gathers metadata about the
geminispace. The goal is not to make a search engine but to survey the
geminispace.

You can find the current results (the crawler did not crawl the entire
space yet):

gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

The reference site:

gemini://gemini.bortzmeyer.org/software/lupa/

The source code, with an issue tracker (bug reports and improvment
requests are very welcome):

https://framagit.org/bortzmeyer/lupa

From jmcbray at carcosa.net  Wed Dec 16 17:16:28 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 16 Dec 2020 12:16:28 -0500
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro> (Adnan Maolood's message of
 "Tue, 15 Dec 2020 22:42:29 GMT")
References: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro>
Message-ID: <87czz9iscz.fsf@dorothy.carcosa.net>

"Adnan Maolood" <me at adnano.co> writes:

> On Tue Dec 15, 2020 at 4:32 PM EST,  wrote:
>> Now, I don't want to hijack your thread... but if anyone is interested in a common
>> format for Gemini bookmarks as I mentioned earlier, an Amfora user proposed[1]
>> XBEL[2] to me, and I plan on implementing it in the next-next release, replacing the
>> TOML format being currently used, which was a bad choice for that purpose. Is
>> this something other client authors would like to do as well?
>
> What about using a plain Gemini text file for storing bookmarks? That
> would make it very easy for people to manage their bookmarks externally.
> You could implement folders as level 1 or 2 headings in the file.

This makes sense. It would also let you delegate the syncing to
something more appropriate, like NextCloud, syncthing, unison, or simply
rsync. 

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From come at chilliet.eu  Wed Dec 16 18:26:27 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Wed, 16 Dec 2020 19:26:27 +0100
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <48F18C46-520A-4E5B-AD3D-7DE743B68737@dengine.net>
References: <3303060.5uuezQRsQv@tempete>
 <48F18C46-520A-4E5B-AD3D-7DE743B68737@dengine.net>
Message-ID: <2261352.L1yFFNoKtc@tempete>

Le mercredi 16 d?cembre 2020, 07:57:49 CET skyjake a ?crit :
> I think this is a valid use case, and it's something I have been thinking about myself just running Lagrange on a number of different computers. When you bring in a mix of different clients and desktop/mobile operating systems, sync is even more important.
> 
> The lowest common denominator should be export to/import from a .gmi file. Such a file (that Adnan Maolood suggested, for example) is guaranteed to be at least viewable by all clients. It supports folders, has no line length limitations, and can support tags as well (e.g., an optional line/bullet/quote following a link).  The user can then manually manage the files via any means they see fit.

I did not put folders and tag in the specification to start with something as simple as possible, but it could of course be added, to the gmi format at least.

> However, the UX of doing that on an ongoing basis to sync your bookmarks/feeds isn't great. An automated mechanism is certainly more desirable.
> 
> When it comes to basing sync on the Gemini protocol, it makes a certain amount of sense (clients know how to do Gemini requests) but it's not a perfect fit:
> 
> * one add/del per request ? what if you have a 100 bookmarks to sync?

This seems like an uncommon case, most likely you will sync 100 bookmarks from server to client, not the other way. It does not bother me if the initialization of the system is a bit under-optimized if after this it?s okay for everyday use.

> * request URL length limit

Yeah that may be a problem, especially if we start adding tags and such. It?s not clear how big a limit that would be.

> * does not address tags, folders, manual ordering

I did not think of ordering, indeed it may be needed.

> > * Would you consider implementing support for something like this?
> 
> Something like this, yes.
> 
> The current proposal needs revising, though. I suggest creating a mechanism that allows using Gemini subscriptions as a core part of the sync. A client would view and/or subscribe to a bookmarks page served by the bookmark sync server. Client-side, the subscription would track all links instead of dated links, and ensure that all links on the bookmarks page have copies in the local set of bookmarks. (And somehow get rid of deleted bookmarks, too.)
> 
> This way,  a public bookmarks feed could be served as a static file by any Gemini server.

This is intended by the spec and is why the only MUST is the text/gemini link list.

> It's a good idea that a client cert is used to ensure privacy of the served bookmarks, unless they are meant to be public.
> 
> The upload part is where it's gets tricky, and I don't think the Gemini protocol should be used for that. As a client author what I'd like to see is that I just export the bookmarks .gmi file as usual, and then send it to the server, perhaps via a TLS socket at a port specifically reserved for uploads ? just open a socket, set a client cert, and write the .gmi file to the socket. The client cert would be required for user identification. It would be up to the server to merge the bookmarks and get rid of deleted ones on server-side.
> 
> This does make things a bit more difficult for the server implementation, but keeping things easy for clients at least encourages wider support.

I thought it was easier for clients if they can reuse their Gemini handling code instead of adding support for another protocol. Same thing for server actually.

> > * Does your client have some kind of plugin system which would allow a third-party to add support?
> 
> Not currently. However, Lagrange's MIME hooks could be extended to allow manual activation, so you could run an external program on your "about:bookmarks" page to do the sync. It would need to edit the internal bookmarks.txt file, and Lagrange would then need to detect that the file has changed after the hook program finishes. I wouldn't prefer going down this route, though. It's better to have a mechanism that benefits all clients equally.
> 
> So let's keep working on this! Automatic bookmark (and client cert?) sync would be great features for Gemini clients.

If I?m not mistaking, lagrange has no support for folders, ordering and tagging bookmarks/feeds?
This is also why I did not put such things in the spec, to start with the minimal common denominator among clients features.

C?me



From bjorn.warmedal at gmail.com  Wed Dec 16 19:39:25 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Wed, 16 Dec 2020 20:39:25 +0100
Subject: Unicode vs. the World
In-Reply-To: <87k0thj0tq.fsf@dorothy.carcosa.net>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
Message-ID: <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>


> I don't think this is going to be acceptable for authors.

Maybe not. I don?t really know.

> It's
> unreasonable to ask authors to use a tool other than their favorite text
> editor to write gemtext.

Is it? Unreasonable is a strong word here.

I assume there would be some servers out there that would do this on the fly when serving gemtext, but I can?t know that for sure. There could also be a CLI tool you can run on your file that fixes links. Or some other solution.

> Why is it reasonable for the client to have to
> punycode the domain (an uncommon encoding for which not every common
> language has a library),

I made the assumption that most languages dealing in stuff like URLs would have support for it. I may be in the wrong there. I also made the assumption that punycoding was common, but I may be in the wrong there too. Which method *is* common?

> but unreasonable for it to have to urlencode
> the path (a common encoding for which libraries are ubiquitous)?

Because ? as I tried to point out ? there is no reasonably simple heuristic for determining whether a URL is already percent encoded or not. And percent encoding a URL that is already percent encoded exchanges all % characters with %25. Attempting to punycode a domain name that is already punycoded, however, changes nothing at all. No heuristics are needed, the client can just punycode everything.

> Why is
> it so hard to convince people to just do the right thing?

Why are you so adamantly convinced that *you* are arguing for ?the right thing?? Is there an objective measurement here that you may share with me?

????

From cowan at ccil.org  Wed Dec 16 20:49:29 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 16 Dec 2020 15:49:29 -0500
Subject: Unicode vs. the World
In-Reply-To: <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>
 <1691977.GtXugi2lUL@tempete>
 <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
Message-ID: <CAD2gp_SUpKsat3b9toMsXx04WUcdTN6XmkEQ8trXDR6Yf6dD1A@mail.gmail.com>

On Tue, Dec 15, 2020 at 2:11 PM PJ vM <pjvm742 at disroot.org> wrote:


> This introduces a pitfall for authors: they never have to think about
> percent-encoding, *except* when there are percent signs in the path.
>

Or spaces, because in a link line a space terminates the URI.  So if the
author wants to link to "gemini://example.com/foo bar", the author *must*
write gemini://example.com/foo%20.bar.  In principle you have the same
problem with wanting line endings in a URI, though they are much less
likely to be an issue.

All this boils down to this question:  Who should pay the price for i18n in
links, clients or authors?"  Any third alternative is hacky at best (there
is typically no library routine for "encode everything that needs to be
encoded except in the sequences %20 and %25") and broken at worst.

How is this better than agreeing that link paths in gemtext are always
> completely percent-encoded?


I don't understand.  Do you mean "link paths are already %-encoded when you
get them" (status quo) or "link paths must be %-encoded when you get them"
(IRIs in link lines)?

On Tue, Dec 15, 2020 at 3:00 PM C?me Chilliet <come at chilliet.eu> wrote:

Because a completely percent encoded link is hell to read and to write, for
> instance:
> gemini://gemini.circumlunar.space/%64%6f%63%73/%66%61%71%2e%67%6d%69


+1


> Yes.
> I am for IDN in link lines, but I am also in favor of IRI in link lines.
>

+1


> And I would be supportive of using IRI in request line also for that
> matter. And redirect responses.
>

-1.  That's a change to the protocol, and only protocol agents (clients,
servers) should see such lines; it doesn't matter how ugly they are.  So
"machines speak URIs, humans speak IRIs".




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201216/87991be9/attachment-0001.htm>

From colecmac at protonmail.com  Wed Dec 16 21:08:16 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 16 Dec 2020 21:08:16 +0000
Subject: Some reading on IRIs and IDNs
In-Reply-To: <87blf3u20h.fsf@dorothy.carcosa.net>
References: <87blf3u20h.fsf@dorothy.carcosa.net>
Message-ID: <gfslRoWBSM67U2ardcdvqbMJJ0NGQqB52e_DWijNt-UUlrOVCkKhn5ESIo75gXPrmID5_67r_hpq9LPfcBizFfbGYQPt6xNgug8aE9_YY6I=@protonmail.com>

Hello,

I didn't see any email mentioning this so I thought I'd share the
link here. Lagrange[1] has gone ahead with IDN support, and the details
are found in this post[2] by skyjake.

The relevant points are as follows.

> * The full URL is NFC normalized before sending it to a server.
> * Domain names with non-ASCII characters are encoded to Punycode before
>   doing a DNS lookup. The Punycode version of the domain name is sent to
>   the server in the request URL, and also used for verifying the server
>   certificate.

This is what I plan on doing in Amfora as well. I will defer to Solderpunk's
judgement, which is coming[3], but until then that's my plan. The only
difference is that I was planning on allowing both punycoded domains and IDNs
in certs, to simplify things for sysadmins. But if Lagrange isn't allowing
it, then maybe I shouldn't... this is quickly approaching "de facto standard"
territory.

For now I will err on the permissive side in that case, allowing both, but this
is something I'd like hear from Solderpunk on.

gemget will do the same, as it uses the go-gemini[4] library as well.


1: https://gmi.skyjake.fi/lagrange/
2: gemini://skyjake.fi/gemlog/2020-12_idns-in-lagrange.gmi
3: gemini://gemini.circumlunar.space/~solderpunk/pikkulog/2020-12.gmi
4: https://github.com/makeworld-the-better-one/go-gemini/issues/10


Cheers,
makeworld

From ew.gemini at nassur.net  Wed Dec 16 21:18:11 2020
From: ew.gemini at nassur.net (ew.gemini)
Date: Wed, 16 Dec 2020 22:18:11 +0100
Subject: Unicode vs. the World
In-Reply-To: <87k0thj0tq.fsf@dorothy.carcosa.net>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAJScK0K7VRXhOfmc9DmURxpVXRmUZYeN+j-x1Vbs==EY0ixw1A@mail.gmail.com>
 <1691977.GtXugi2lUL@tempete>
 <3fb66b2e-7d62-0447-c4c1-3ba14588183d@disroot.org>
 <CAJScK0Jri4oMXEZL1Ve1jsZVdm6_1RqW_sapmVacGpor0ZZGtg@mail.gmail.com>
 <87k0thj0tq.fsf@dorothy.carcosa.net>
Message-ID: <82y2hx8n70.fsf@nassur.net>


Hello,

Jason McBrayer writes:

> It's unreasonable to ask authors to use a tool other than
> their favorite text editor to write gemtext.

Yepp. 1+

Cheers,
Erich

-- 
Keep it simple!

From colecmac at protonmail.com  Wed Dec 16 21:24:27 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 16 Dec 2020 21:24:27 +0000
Subject: Crawlers on Gemini and best practices
In-Reply-To: <C7QPMIESH8HA.1EJ893KFUI0RF@rath>
References: <C7QPMIESH8HA.1EJ893KFUI0RF@rath>
Message-ID: <bW5YadQFC31b9fcacSpzA7w7BXp8M46OIYnYYjrWtVSWNbKDohkWavRJu5aowSC8Bo-weLSo_ivgsXaaLxG7AxhxtLBMUWdqG0EA0Fnnahc=@protonmail.com>

On Saturday, December 12, 2020 4:46 AM, Leo <list at gkbrk.com> wrote:

> > Why are we defining new standards and filenames? bots.txt, .well-known,
> > etc.
>
> Just want to point out that the .well-known path for machine-readable
> data about an origin is a proposed IETF standard that has relatively
> widespread use today. It is filed under RFC8615, and is definitely not a
> standard that was invented in this thread.

Yes, I'm aware of .well-known. I meant that using it to hold a robots.txt-type
file would be a new filepath.

> The first paragraph of the introduction even references the robots file.
>
> While I don't necessarily agree with the naming of bots.txt, I see no
> problem with putting these files under a .well-known directory.

My only problem was that it would be reinventing something that already
exists, but I likewise have no issue with the idea of .well-known in general.

> > We don't need this.
>
> Thanks for making this mailing list a lot more efficient and talking
> about what the Gemini community needs in a 4-word sentence.

Sorry, perhaps that was too curt. I don't intend to speak for everyone,
it's only my opinion. However it wasn't just a 4-word sentence, I backed
up my opinion with the rest of my email.

> Even if the original path of /robots.txt is kept, I think it makes sense
> to clarify an algorithm in non-ambiguous steps in order to get rid of
> the disagreements in edge-cases.
>
> > let's just pick a standard that works and make it offical.
>
> The point is that the standard works for simple cases, but leaves a lot
> to be desired when it comes to clarifying more complex cases. This
> results in a lot of robots.txt implementations disagreeing about what is
> allowed and not allowed.

I agree, that's why I was trying to pick a standard instead of developing
our own. Picking a well-written standard will cover all these cases.

> Additionally by crawling the Web, you can see that people tend to extend
> robots.txt in non-standard ways and this only gets incorporated into
> Google's crawlers if the website is important enough.

Ok? I don't see how that's relevant. By picking a standard here and sticking
to it, we can avoid that.

> > I am no big fan of Google, but they are the kings of crawling and it
> > makes sense to go with them here.
>
> The kings of crawling deemed HTTP and AMP the most suitable protocol and
> markup format for content to be crawled, why don't we stop inventing
> standards like Gemini and Gemtext and go with them here.

Again I don't see how that's relevant. Yes "we" don't like AMP here, yes
we don't like HTTP, etc. This doesn't make the robots.txt standard I sent
a bad one.

> > The spec makes many example references to HTTP, but note that it is
> > fully protocol-agnostic, so it works fine for Gemini.
>
> Gemtext spec makes references to Gemini, but it is fully
> protocol-agnostic, so it works fine with HTTP. Similarly, Gemini makes
> many references to Gemtext, but it is content-type agnostic so it works
> fine with HTML. But we thought we could be better off shedding
> historical baggage and reinvented not one, but two main concepts of the
> traditional Web.
>

This quote, along with this line:

> why don't we stop inventing standards like Gemini and Gemtext and go with
> them [Google] here.

makes me think you misunderstand some of Gemini's ideas. Solderpunk has
talked about the idea of "radical familiarity" on here, and how Gemini uses
well known (ha) protocols as much as possible, like TLS, media types, URLs,
etc. Gemini tries to *avoid* re-inventing! Obviously the protocol itself
and gemtext are the exceptions to this, but otherwise, making niche protocols
only for Gemini is not the way to go (in my opinion). It makes things harder
to implement and understand for developers.


Cheers,
makeworld

From colecmac at protonmail.com  Wed Dec 16 22:41:49 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 16 Dec 2020 22:41:49 +0000
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro>
References: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro>
Message-ID: <eLtb0pMLH2dKRNU1AqcRtiAoq9DhqfeSxhN55bIX0ZgcxC_O2KiVl-5MVIoBt52pVR7N1cvP0xyH4MXUawiEpk0vq6plpUxjytPNxm4z8L8=@protonmail.com>

On Tuesday, December 15, 2020 5:42 PM, Adnan Maolood <me at adnano.co> wrote:

> [snip]
>
> What about using a plain Gemini text file for storing bookmarks? That
> would make it very easy for people to manage their bookmarks externally.
> You could implement folders as level 1 or 2 headings in the file.
>
> For example:
>
> # Folder 1
>
> => gemini://gemini.circumlunar.space Project Gemini
> => gemini://example.com Example Bookmark
>
> # Folder 2
>
> => gemini://example.org Example Bookmark

I agree that people being able to manage their own bookmarks easily in
a text editor is attractive. However I think I'd rather stick with a more
strict format rather than one that's endlessly extensible like this one.

Maybe one browser will use text lines as comments, and another will use
them as descriptions, and Amfora will ignore all text lines, but then one
day someone will want Amfora to support descriptions, but it can't tell
what's what, etc.

XML and the XBEL spec prevents these issues at the expense of user writing.
I'm not sure how many users really are going to be writing their own
bookmarks though, and of those, how many are going to have trouble with XML.

Often re-using gemtext is useful because of rendering, but in this case
the gemtext would have to be interpreted and then rendered in a different
format, which seems counter-intuitive. I think gemtext works best as a
markup format as it was designed, rather than for data storage.


Cheers,
makeworld

From sean at conman.org  Wed Dec 16 23:16:53 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 16 Dec 2020 18:16:53 -0500
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201216150549.GA19202@sources.org>
References: <20201216150549.GA19202@sources.org>
Message-ID: <20201216231652.GA9267@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> I'm running a Gemini crawler, which gathers metadata about the
> geminispace. The goal is not to make a search engine but to survey the
> geminispace.
> 
> You can find the current results (the crawler did not crawl the entire
> space yet):
> 
> gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
> 
> The reference site:
> 
> gemini://gemini.bortzmeyer.org/software/lupa/
> 
> The source code, with an issue tracker (bug reports and improvment
> requests are very welcome):
> 
> https://framagit.org/bortzmeyer/lupa

  Very cool!  Thanks for the work.

  One stat I haven't seen yet (yours or from GUS) is a breakdown of
langauge.  How many pages had a lang parameter, then a breakdown by
language, how many multiple languages per parameters (for example,
"lang=en,fr").

  -spc


From sean at conman.org  Wed Dec 16 23:41:27 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 16 Dec 2020 18:41:27 -0500
Subject: Unicode vs. the World
In-Reply-To: <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
Message-ID: <20201216234127.GB9267@brevard.conman.org>

It was thus said that the Great Bj?rn W?rmedal once stated:
> 
> > but unreasonable for it to have to urlencode the path (a common encoding
> > for which libraries are ubiquitous)?
> 
> Because ? as I tried to point out ? there is no reasonably simple
> heuristic for determining whether a URL is already percent encoded or not.
> And percent encoding a URL that is already percent encoded exchanges all %
> characters with %25. Attempting to punycode a domain name that is already
> punycoded, however, changes nothing at all. No heuristics are needed, the
> client can just punycode everything.

  I can't say for certain what most clients do, but I'm under the impression
that some (the majority?) use some existing library to parse links.  The
specification states that relative links are allowed in text/gemini:

=> ../%F0%9D%92%BB%F0%9D%92%B6%F0%9D%93%83%F0%9D%92%B8%F0%9D%93%8E.txt Some ????? stuff here

but a full URI needs to be sent to the server, so some processing of the
link is required (specifically, section 5.2 of RFC-3986).  And existing
libraries help here.  The library I'm currently using will parse the above
link into the following structure:

	{
	  path = "../?????.txt"
	}

  Note how the text has been translated and any percent encoding has been
decoded.  Next, the base URL of the page:

	gemini://example.com/files/others/

has previously parsed (because it was needed to retrieve the page currently
being viewed):

	{
	  path = "/files/others/",
	  port = 1965.000000,
	  host = "example.com",
	  scheme = "gemini",
	}

  The two are then merged into a single reference:

	{
	  path = "/files/?????.txt"
	  port = 1965.000000,
	  host = "example.com",
	  scheme = "gemini",
	}

  Then to make a request, this new link is converted into a URI to make the
request:

	gemini://example.com/files/%F0%9D%92%BB%F0%9D%92%B6%F0%9D%93%83%F0%9D%92%B8%F0%9D%93%8E.txt

  As you can see, that process has re-encoded the path, percent-encoding it.
I would expect that some (the majority?) of clients are doing something
similar to this---doing a conversion from percent-encoding, marging
references, then converting to percent-encoding (except for the host, which
needs to be converted to punycode).

  It would be instructive to know how clients are handling this---do they
decode percent-encoded data, merge the base link to the relative link and
re-encode?  Or something different?

  -spc


From colecmac at protonmail.com  Wed Dec 16 23:57:15 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 16 Dec 2020 23:57:15 +0000
Subject: Unicode vs. the World
In-Reply-To: <20201216234127.GB9267@brevard.conman.org>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
Message-ID: <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>

> It would be instructive to know how clients are handling this---do they
> decode percent-encoded data, merge the base link to the relative link and
> re-encode? Or something different?
>
> -spc


My clients (gemget, Amfora) are in Go, so I just `Parse` both the base link
and the relative link, and then use `base.ResolveReference(rel)`. This means
I don't have to do any decoding or anything at all.

URL.Path and URL.RawPath can be used to get the decoded and encoded path
respectively, although I have no need in this context.

https://golang.org/pkg/net/url/#URL
https://golang.org/pkg/net/url/#Parse
https://golang.org/pkg/net/url/#URL.ResolveReference


makeworld

From skyjake at dengine.net  Thu Dec 17 06:38:42 2020
From: skyjake at dengine.net (skyjake)
Date: Thu, 17 Dec 2020 08:38:42 +0200
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <2261352.L1yFFNoKtc@tempete>
References: <3303060.5uuezQRsQv@tempete>
 <48F18C46-520A-4E5B-AD3D-7DE743B68737@dengine.net>
 <2261352.L1yFFNoKtc@tempete>
Message-ID: <519FD72B-3413-4D85-AA57-37C53BD1B42E@dengine.net>

On 16. Dec 2020, at 20:26, C?me Chilliet <come at chilliet.eu> wrote:

> If I?m not mistaking, lagrange has no support for folders, ordering and tagging bookmarks/feeds?

Lagrange lets you enter tags for bookmarks/feeds as a free-format string of text. In fact, a feed is a tagged bookmark. The quick search feature looks through bookmark tags.

Folders and ordering are on my to-do list. I'm getting a bit annoyed using the simple alphabetically ordered flat list of bookmarks. :)

--jaakko

From skyjake at dengine.net  Thu Dec 17 07:04:07 2020
From: skyjake at dengine.net (skyjake)
Date: Thu, 17 Dec 2020 09:04:07 +0200
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <eLtb0pMLH2dKRNU1AqcRtiAoq9DhqfeSxhN55bIX0ZgcxC_O2KiVl-5MVIoBt52pVR7N1cvP0xyH4MXUawiEpk0vq6plpUxjytPNxm4z8L8=@protonmail.com>
References: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro>
 <eLtb0pMLH2dKRNU1AqcRtiAoq9DhqfeSxhN55bIX0ZgcxC_O2KiVl-5MVIoBt52pVR7N1cvP0xyH4MXUawiEpk0vq6plpUxjytPNxm4z8L8=@protonmail.com>
Message-ID: <DD6E4BA2-D8E7-4E95-9667-688B90425BC8@dengine.net>

On 17. Dec 2020, at 0:41, colecmac at protonmail.com wrote:

> I agree that people being able to manage their own bookmarks easily in
> a text editor is attractive. However I think I'd rather stick with a more
> strict format rather than one that's endlessly extensible like this one.

I think the primary advantage of this bookmarks .gmi format would be interchange between clients (and instances of the same client) without humans editing the file. I don't think a client would want to store their bookmarks in this format, as there may be additional (possible internal) metadata to deal with, too.

When it comes to manual editing, I could see reordering and tagging your existing bookmarks as real-world use cases, and a simple line-based format makes these quite straightforward. But in any case, I'd probably prefer doing this via the client GUI myself.

> Maybe one browser will use text lines as comments, and another will use
> them as descriptions, and Amfora will ignore all text lines, but then one
> day someone will want Amfora to support descriptions, but it can't tell
> what's what, etc.

A simple companion spec for client bookmark exchange similar to the Gemini subscriptions one should solve this problem adequately by defining what is meaningful and what should be ignored. Another format like XBEL could still be used if one's client supports additional information per bookmark.

> XML and the XBEL spec prevents these issues at the expense of user writing.
> I'm not sure how many users really are going to be writing their own
> bookmarks though, and of those, how many are going to have trouble with XML.

XBEL is certainly an existing solution to exchanging bookmarks, and but it would be nice to have something that is compatible with the Gemini ethos. Personally I would even prefer JSON-based formats to XML (easier to parser, easier for humans to read), but gemtext has the unique advantage of being viewable by all clients even if they have no concept of importing bookmarks, or bookmarks in general.

--jaakko

From benulo at systemli.org  Thu Dec 17 07:07:37 2020
From: benulo at systemli.org (Ben)
Date: Thu, 17 Dec 2020 10:37:37 +0330
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <3303060.5uuezQRsQv@tempete>
References: <3303060.5uuezQRsQv@tempete>
Message-ID: <7cca8945-960a-5319-787c-71db6deb00d9@systemli.org>

If you want to synchronize bookmarks over the Internet for all clients, 
this feature is already built into Gemini.

Basically all you need to do is create a gemdoc with links to the things 
you would like to bookmark/sync, then place that file on a Gemini server 
somewhere. You can then direct any client to open this file, and then 
you've got your bookmarks.

Also you can update the file any time and it will automatically 
propagate across all clients.

Ben

-- 
gemini://kwiecien.us/

From bjorn.warmedal at gmail.com  Thu Dec 17 07:39:36 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Thu, 17 Dec 2020 08:39:36 +0100
Subject: Unicode vs. the World
In-Reply-To: <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
 <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
Message-ID: <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>

How does a client handle a link like the following:
=> essays/why-spaces-are-%20-in-URLs.gmi

The assumption here is that the author has not percent encoded
themselves -- this is the actual filename, %20 and all.

How can the client tell if it's percent encoded or not? If you start
by decoding it you distort the filename. If you just assume it isn't
percent encoded and go ahead and do that you will handle this link
correctly but break any links that are already percent encoded. I've
only done this in python, using the urllib.parse library. I can tell
that to encode or decode, but it will do what I tell it to without
exception. It's up to me to build logic that avoids breaking the edge
cases.

We can decide to *always* percent encode links in gemtext (as the spec
states now) or to *never* do it, but I don't see how we can reasonably
have both. And never doing it means we can never link to a file with
spaces in the URL, and will have to percent decode anything we copy
paste from web browser's address bar. There will be extra work for
authors either way.

Consider another hypothetical case:
=> teddybearoftheyear.com/vote?ew0k%20The%20Great Vote for me!

How would you solve that?

However much I *want* to have IRIs and IDNs in gemtext and leave the
work to clients and servers, I don't have a solution for that as an
implementer.

Cheers,
ew0k

From text at sdfeu.org  Thu Dec 17 09:07:34 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Thu, 17 Dec 2020 09:07:34 -0000 (UTC)
Subject: Synchronizing bookmarks - Request for comments
References: <3303060.5uuezQRsQv@tempete>
 <7cca8945-960a-5319-787c-71db6deb00d9@systemli.org>
Message-ID: <rrf74m$m3o$1@ciao.gmane.io>

On Thu, 17 Dec 2020 10:37:37 +0330, Ben wrote:

> If you want to synchronize bookmarks over the Internet for all clients,
> this feature is already built into Gemini.
> 
> Basically all you need to do is create a gemdoc with links to the things
> you would like to bookmark/sync, then place that file on a Gemini server
> somewhere. You can then direct any client to open this file, and then
> you've got your bookmarks.
> 
> Also you can update the file any time and it will automatically
> propagate across all clients.
> 
> Ben

Brilliant! (No need for JSON, TOML, XML (XBEL, OPML) ? I guess)


From sean at conman.org  Thu Dec 17 09:48:43 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 17 Dec 2020 04:48:43 -0500
Subject: Unicode vs. the World
In-Reply-To: <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
 <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
 <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
Message-ID: <20201217094843.GC9267@brevard.conman.org>

It was thus said that the Great Bj?rn W?rmedal once stated:
> How does a client handle a link like the following:
> => essays/why-spaces-are-%20-in-URLs.gmi
> 
> The assumption here is that the author has not percent encoded
> themselves -- this is the actual filename, %20 and all.
> 
> How can the client tell if it's percent encoded or not? If you start
> by decoding it you distort the filename. If you just assume it isn't
> percent encoded and go ahead and do that you will handle this link
> correctly but break any links that are already percent encoded. I've
> only done this in python, using the urllib.parse library. I can tell
> that to encode or decode, but it will do what I tell it to without
> exception. It's up to me to build logic that avoids breaking the edge
> cases.
> 
> We can decide to *always* percent encode links in gemtext (as the spec
> states now) or to *never* do it, but I don't see how we can reasonably
> have both. And never doing it means we can never link to a file with
> spaces in the URL, and will have to percent decode anything we copy
> paste from web browser's address bar. There will be extra work for
> authors either way.
> 
> Consider another hypothetical case:
> => teddybearoftheyear.com/vote?ew0k%20The%20Great Vote for me!
> 
> How would you solve that?
> 
> However much I *want* to have IRIs and IDNs in gemtext and leave the
> work to clients and servers, I don't have a solution for that as an
> implementer.

  I don't have a solution either, and while trying to nail down every
possible corner case is admirable, sometimes, you just have to say, "don't
do that!" (or in other words, document or warn about the corner case).

  It's already the case on Unix systems where a file name can technically
have any character other than '/' (because it's the path separator) and NUL
(marks the end of the string), but I doubt you'll find any filenames with
control characters [1] or even "problematic characters because of the shell"
like "&", "?", or "*" in them.  People just kind of learn what they can and
can't use for filenames over time.  In fact, that might be an interesting
thing for Lupa [2] or GUS to report on---characters found in filenames [3].

  I'm not sure how apropos this is, but years ago, when I was at university
studying Computer Science, I was writing a program (for a friend, not course
related) where I wanted to log errors so they would later be seen (as the
program would run unattended, and any messages to the display would not be
seen).  I could log to a file, but the disk could fill up.  Okay, if that
happened, I could log to the printer, but there might not be a printer (or
it could be turned off---this back when printers were hooked directly to a
computer).  I asked one of my instructors (who worked at IBM, and was on the
team for one of the first Fortran compilers for IBM) what I should do.  His
advice was (and as sad as this is, it's pretty true), if you don't know how
to handle an error, don't bother looking for it.

  -spc

> Cheers,
> ew0k

[1]	Unless it's for pranking someone, not that I would know that.

[2]	St?phane's new research crawler for Gemini.

[3]	This reminds me, I have a new feature on my own server that allows
	one to dive into a ZIP file:

		gemini://gemini.conman.org/test/UCSD-Pascal-source.zip/

		vs.

		gemini://gemini.conman.org/test/UCSD-Pascal-source.zip

	Right now it's not much of an issue since the filenames for the
	"proof-of-concept" file are just plain ASCII, but in the general
	case, I suppose I should support conversion of filenames to UTF-8,
	but that might be a hard case as well, as character encodings aren't
	readily recorded in ZIP files.

From sean at conman.org  Thu Dec 17 09:59:24 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 17 Dec 2020 04:59:24 -0500
Subject: Unicode vs. the World
In-Reply-To: <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
 <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
 <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
Message-ID: <20201217095924.GD9267@brevard.conman.org>

It was thus said that the Great Bj?rn W?rmedal once stated:
> How does a client handle a link like the following:
> => essays/why-spaces-are-%20-in-URLs.gmi
> 
> The assumption here is that the author has not percent encoded
> themselves -- this is the actual filename, %20 and all.

  And speaking of this, test #31 of the Gemini Client Torture Test [1] has
this exact case---the link contains characters that should be encoded but
aren't.  It's been interesting to see which clients get an error, and which
ones encode the bad characters.  And for this test, there is no right
answer---it's there to inform implementors that you'll encounter wrong stuff
all the time, and you better be prepared to do *something* [2].

  -spc

[1]	gemini://gemini.conman.org/test/torture/0031

[2]	Not withstanding the advice I presented in my previous reply to
	this.  Sometimes, crashing *is* a valid response to some unknown
	state, but it really depends upon the context of the program [3].

[3]	I can expand on this if anyone cares.

From jmcbray at carcosa.net  Thu Dec 17 13:31:38 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 17 Dec 2020 08:31:38 -0500
Subject: Unicode vs. the World
In-Reply-To: <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 (=?utf-8?Q?=22Bj=C3=B6rn=09W=C3=A4rmedal=22's?= message of "Wed, 16 Dec
 2020 20:39:25 +0100")
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
Message-ID: <87v9d0sgn9.fsf@cassilda.carcosa.net>

Bj?rn W?rmedal <bjorn.warmedal at gmail.com> writes:

> Because ? as I tried to point out ? there is no reasonably simple
> heuristic for determining whether a URL is already percent encoded or
> not. And percent encoding a URL that is already percent encoded
> exchanges all % characters with %25.

It's not that hard. All you have to do is percent decode the path *first*,
then percent encode it. Consider this URL, which is a worst-case for
what you're talking about:

gemini://example.com/?%20?.gmi

Unquoting the path gives you 'gemini://example.com/? ?.gmi', of
course. And then quoting it gives you 

'gemini://example.com/%F0%9F%90%87%20%F0%9F%A5%95.gmi'

which decodes correctly.

Unquoting a path that is already plain ASCII does nothing to it.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From jmcbray at carcosa.net  Thu Dec 17 13:55:38 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Thu, 17 Dec 2020 08:55:38 -0500
Subject: Unicode vs. the World
In-Reply-To: <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
 (=?utf-8?Q?=22Bj=C3=B6rn=09W=C3=A4rmedal=22's?= message of "Thu, 17 Dec
 2020 08:39:36 +0100")
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
 <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
 <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
Message-ID: <87o8issfj9.fsf@cassilda.carcosa.net>

Bj?rn W?rmedal <bjorn.warmedal at gmail.com> writes:

> How does a client handle a link like the following:
> => essays/why-spaces-are-%20-in-URLs.gmi
>
> The assumption here is that the author has not percent encoded
> themselves -- this is the actual filename, %20 and all.

This doesn't work in HTML/HTTP, either.

Go to https://jfm.carcosa.net/testme.html, look at the source, see what
happens with each link. The web server is Apache.

The upshot is that to include %, or any other reserved character in the
link, you do need to pre-encode it in your source. That's obvious for
' ', because of the syntax of links in gemtext. But it's also true of %,
etc. 

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From trevor at rocketnine.space  Thu Dec 17 01:50:01 2020
From: trevor at rocketnine.space (Trevor Slocum)
Date: Thu, 17 Dec 2020 01:50:01 GMT
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <1857962.TKIm2rkbc4@tempete>
References: <1857962.TKIm2rkbc4@tempete>
Message-ID: <fd4ad812-bf3f-6144-5a51-fa94cc03e3f9@rocketnine.space>

twins provides client certificate hashes via $_SERVER.

https://gitlab.com/tslocum/twins/blob/master/CONFIGURATION.md#fastcgi


From colecmac at protonmail.com  Thu Dec 17 22:31:38 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 17 Dec 2020 22:31:38 +0000
Subject: Synchronizing bookmarks - Request for comments
In-Reply-To: <DD6E4BA2-D8E7-4E95-9667-688B90425BC8@dengine.net>
References: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro>
 <eLtb0pMLH2dKRNU1AqcRtiAoq9DhqfeSxhN55bIX0ZgcxC_O2KiVl-5MVIoBt52pVR7N1cvP0xyH4MXUawiEpk0vq6plpUxjytPNxm4z8L8=@protonmail.com>
 <DD6E4BA2-D8E7-4E95-9667-688B90425BC8@dengine.net>
Message-ID: <Q2MvZmW523LQ2FGuHyNCiHL6JarlG5uu_kpyZ6RHjRfEGzRcUUtIM3Fy7RM9iWzxmwNroBgz3hiGHVJquiy2qfs5a5c6OVG7ZoMZjUTJOXQ=@protonmail.com>

> I think the primary advantage of this bookmarks .gmi format would be interchange
> between clients (and instances of the same client) without humans editing the file.
> I don't think a client would want to store their bookmarks in this format, as there
> may be additional (possible internal) metadata to deal with, too.

Well, that works for me. Amfora already has support for file:// URIs in master, so
in the next release you'll be able to just open any gemtext file and use it as your
free-form bookmarks.


makeworld


From cowan at ccil.org  Thu Dec 17 22:47:45 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 17 Dec 2020 17:47:45 -0500
Subject: Unicode vs. the World
In-Reply-To: <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
 <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
 <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
Message-ID: <CAD2gp_To25+oUmywJ-TyGHCoR+gzi+1oA+ZfMVaT17cFE+BzRw@mail.gmail.com>

On Thu, Dec 17, 2020 at 2:39 AM Bj?rn W?rmedal <bjorn.warmedal at gmail.com>
wrote:\

How can the client tell if it's percent encoded or not? If you start
> by decoding it you distort the filename. If you just assume it isn't
> percent encoded and go ahead and do that you will handle this link
> correctly but break any links that are already percent encoded.

Exactly.  To make things worse, space is a protocol element in link lines
and *can't* be left unencoded by the author, whichever way we choose.


> We can decide to *always* percent encode links in gemtext (as the spec
> states now) or to *never* do it, but I don't see how we can reasonably
> have both.


I agree.  But what we can have (and it's messy, but not as messy as the
alternatives) is "authors encode percent and space" and "clients encode all
other reserved and non-ASCII characters."

> Consider another hypothetical case:

=> teddybearoftheyear.com/vote?ew0k%20The%20Great Vote for me!
>

That's the best you can do.  But in the case where the link line is

> => teddybearoftheyear.com/vote?????%20???????
> <http://teddybearoftheyear.com/vote?ew0k%20The%20Great> ??????? ?? ????! [1]
> [2] [3]
>
then the client must translate it for sending over the wire into

gemini://
teddybearoftheyear.com/vote?%D0%98%D0%B2%D0%B0%D0%BD%20%D0%93%D1%80%D0%BE%D0%B7%D0%BD%D1%8B%D0%B9
<http://teddybearoftheyear.com/vote?ew0k%20The%20Great>

because making the author type all that is wholly abominable.  Online
URL-encoders are not that helpful, because they give you + instead of %20.

[1] This is Ivan the Terrible, who for most of his life was actually a
quite effective tsar despite his (occupational) paranoia and a serious
outbreak of madness just before he died; a better translation would be
"Ivan the Formidable".  Still, nobody would call him a teddy bear (and so
his ukase "Vote for me!" would probably be in vain).

[2] The latest spec change makes this line incorrect unless "
teddybearoftheyear.com/vote" is to be interpreted as a relative path.  It
needs to be prefixed by "gemini://" or at the very least "//".

[3] If the space had not been %-encoded by the author, the Tsar's second
name would be part of the link name and not part of the IRI.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
'My young friend, if you do not now, immediately and instantly, pull
as hard as ever you can, it is my opinion that your acquaintance in the
large-pattern leather ulster' (and by this he meant the Crocodile) 'will
jerk you into yonder limpid stream before you can say Jack Robinson.'
        --the Bi-Coloured-Python-Rock-Snake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201217/7e968ab6/attachment.htm>

From gmym at coopdot.com  Fri Dec 18 06:13:24 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Fri, 18 Dec 2020 07:13:24 +0100
Subject: Unicode vs. the World
In-Reply-To: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
Message-ID: <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>

Help! I'm getting pulled in!

On IRC, I wrote:

[2020-12-14T21:26:44Z] <CoopDot> I'm staying out of debating IDN/IRI on the
ML. What I've had to say has already been said more than once. My position
have even shifted a bit since the threads started

Some discussion happened and then I wrote something that got quoted here:


Petite Abeille <petite.abeille at gmail.com> wrote:

For example:

[2020-12-14T22:12:14.914Z] <remyabel> I lurk this channel and the mailing
lists and keep seeing people trying to extend gemini or make it web-like,
there's just no point in arguing against it
[2020-12-14T22:12:28.578Z] <CoopDot> I used to be in the US-ASCII only camp
but now it's more "do the bare mininum to not forbid UTF-8 'URLs' in the
spec and make strong recommendations in best-practices.gmi"

^Those are the "cannot be arsed" camp: things are the way they are, and
cannot be bothered to changed anything, technically speaking... we are
done. The "not-my-problem" camp.


I'm assuming including me here was intentional. I truly can't tell if that
is an accurate description of my possession.

"I used to be in the US-ASCII only camp" refers to me no longer thinking
requiring everything to be encoded to pass as US-ASCII is the best idea.
This is me moving away from the status quo towards a possible compromise.
Or am I missing where we're going?

"Do [...] not forbid UTF-8 'URLs' in the spec". Not forbidding is almost
like allowing. We should attempt to not paint our selfs into a corner or
bet on the wrong horse. ?

"Make strong recommendations in best-practices.gmi" because we have to
address it somewhere.

Earlier in the same email, Petite Abeille <petite.abeille at gmail.com> wrote:

It boils down to this:

 => gemini://?.mozz.us/?.gmi ?Hoppity hop?

What do do with such a construct? Possible? Not possible? Allowed? Not
allowed? First class citizen? Afterthought? How do deal with it, if at all?


[...]

=> gemini://?.mozz.us/?.gmi ?Hoppity hop?
vs.
=> gemini://xn--4o8h.mozz.us/%F0%9F%90%87.gmi ?Hoppity hop?

As it stands, the first variant cannot be handled by gemini -neither in
text/gemini, nor in the protocol itself- with further technical gotchas
such as address resolution and what not along the way.

It must be converted to the second variant, the US-ASCII one.


Let's examine the situation: ?

The capsule author writes this link line in their text editor:

=> gemini://?.mozz.us/?.gmi ?Hoppity hop?

The text editor may or may not change the syntax highlight to indicate an
error with the URL. When saving the file, the text editor has an
opportunity to "correct" the error by itself.

Let's say the text editor is oblivious and the capsule author doesn't run
the file through a linter. The file is ready to be served.

A visitor requests the file. The server has an opportunity to scan the file
before serving, but that would in most cases be a complete waste of
resources, so it doesn't.

The client parses the file. It has a choice to render the link line as a
link or as text. (It could also brake at the first sight of bunny, but
let's assume it doesn't.) The link is only a problem if the visitor is
following it.

At this point, it doesn't matter if the visitor follows a link or writes
the URL in the address bar. The client has a choice to translate or not
translate the URL before making the request.

Domain name resolution is outside of the scope of the Gemini specification,
we don't know if it can handle UTF-8 or not. If the visitor's network
administrator has set up name resolution to accept UTF-8, they should
probably also accept the punycoded version for compatibility.

Let's assume "always punycode" is a safe option, the client has a choice of
being proactive and do the translation or ignore it and let it fail if it
will. I say both options are valid and the Gemini specification should at
most refer to other specifications on this. (The third option to just
refuse to connect is bad.)

Moving on: (We will go back later.)

We have the IP address and the request has reached the server. Let's assume
this is over the regular internet and a punycoded domain is a must.

The server compares "xn--4o8h.mozz.us
<http://xn--4o8h.mozz.us/%F0%9F%90%87.gmi>" with whatever virtual hosts the
server administrator has set up in the configuration file. Is it
unreasonable for the administrator to expect the server software to match
"?.mozz.us" in the configuration file to "xn--4o8h.mozz.us
<http://xn--4o8h.mozz.us/%F0%9F%90%87.gmi>" coming in over the wire?

How about the other way around? It's a local network and ASCII
non-conforming bunnies hops into the server and the administratior has only
specified the punicode in the configuration file. Is it unreasonable to
expect it to match?

Reasonable or not, let's assume the virtual host is set up properly and go
back in time to the client making the request. What do we do about the path?

Should the client "help" the visitor by %-encoding non-ASCII bytes or send
it as is and hope for the best?

Should the client %-encode reserved characters the visitor writes in the
address bar or let them fail?

Anyway, the request reaches the server. "%20" become space and "%2b" become
plus. I see no reason why it would be hard to also convert
"%F0%9F%90%87" into bytes, so I will assume it isn't and wait for server
software programmers to tell me how wrong I am.

So now we have a string of bytes that we can use to fetch the bunny file.
Wait. What happened with the case where the bunny isn't %-encoded? Why
can't servers just blindly accept non-ASCII bytes as is? Is it a library
thing? Anyway, I really should test this in a bunch of languages but I'm
writing this on my phone on my way to work, so instead I present you this
pseudo code:

```
"%F0%9F%90%87".url_decode() == "\xF0\x9F\x90\x87".url_decode()
"%F0%9F%90%87".url_decode() == "\xF0\x9F\x90\x87"
"\xF0\x9F\x90\x87" == "?"
```

If these 3 lines are all true for the server software, I see no reason to
%-encode those non-ASCII bytes in the client or anywhere else. Surely I
have missed something obvious somewhere. Can anyone help me?

Maybe I just need coffee... ?

-- 
Katarina
(Please regard these ramblings as non-rhetorical)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201218/0a0ba47e/attachment-0001.htm>

From stephane at sources.org  Fri Dec 18 09:13:03 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 18 Dec 2020 10:13:03 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201216231652.GA9267@brevard.conman.org>
References: <20201216150549.GA19202@sources.org>
 <20201216231652.GA9267@brevard.conman.org>
Message-ID: <20201218091303.GA7381@sources.org>

On Wed, Dec 16, 2020 at 06:16:53PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 27 lines which said:

> > You can find the current results (the crawler did not crawl the entire
> > space yet):
> > 
> > gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

>   One stat I haven't seen yet (yours or from GUS) is a breakdown of
> langauge.  How many pages had a lang parameter, then a breakdown by
> language, how many multiple languages per parameters (for example,
> "lang=en,fr").

Just ask :-) Now done:

gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

I note:

* French is the second language after english. Cocorico, as we say in
France.

* There is one page in finnish.

* There are more HTML than Markdown pages on the geminispace, which I
find suprising.

* There is one page in EBCDIC and one in CP-437 :-)

From petite.abeille at gmail.com  Fri Dec 18 09:47:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 18 Dec 2020 10:47:47 +0100
Subject: Unicode vs. the World
In-Reply-To: <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
Message-ID: <AB43F403-52DF-4356-8F66-ECAC1899E5A9@gmail.com>


> On Dec 18, 2020, at 07:13, Katarina Eriksson <gmym at coopdot.com> wrote:
> 
> Help! I'm getting pulled in! 

Katarina! Thanks for dropping by! Welcome to the party!  ? ?

> I'm assuming including me here was intentional. I truly can't tell if that is an accurate description of my possession.

Thanks for noticing. Timing is everything. See Cunningham's Law ?

> "I used to be in the US-ASCII only camp" refers to me no longer thinking requiring everything to be encoded to pass as US-ASCII is the best idea. This is me moving away from the status quo towards a possible compromise. Or am I missing where we're going?

Indeed, this is the crux of the issue, the notorious IRI vs. URI chasm: native UTF vs ASCII encoded. 

> I see no reason to %-encode those non-ASCII bytes in the client or anywhere else. Surely I have missed something obvious somewhere. Can anyone help me?

Genau. As it stands, the spec mandates URIs -therefore ASCII only- making UTF IRIs V E R B O T E N! NICHT GUT! NOT COMPLIANT! ? ?

Now that we all took time to survey the lay of the land, the question is: should the  specification be amended to refer to IRI (urn:ietf:rfc:3987), instead of URI (urn:ietf:rfc:3986)? 

As simple as that.

That's all folks! ????



 





From bjorn.warmedal at gmail.com  Fri Dec 18 09:59:58 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Fri, 18 Dec 2020 10:59:58 +0100
Subject: Unicode vs. the World
In-Reply-To: <CAD2gp_To25+oUmywJ-TyGHCoR+gzi+1oA+ZfMVaT17cFE+BzRw@mail.gmail.com>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
 <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
 <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
 <CAD2gp_To25+oUmywJ-TyGHCoR+gzi+1oA+ZfMVaT17cFE+BzRw@mail.gmail.com>
Message-ID: <CAJScK0+miqv-s401EKThiT-pr=UX+cW6ZV3d7EDqWTrBqX01=g@mail.gmail.com>

>> => teddybearoftheyear.com/vote?????%20??????? ??????? ?? ????! [1] [2] [3]

On a technical note: in some libraries you may have to split the URL
and encode the path, fragment, query string and parameters separately.
Otherwise the separators (#, ?, ;) may be encoded as part of the path.

... For me as an implementer this is starting to look a bit
frustrating. I want to please people, but I also don't want to have
all the lifejoy sucked out of me because I have to twist myself into
knots in order to properly understand and implement the protocol.

I'll bow out of this discussion now and follow it from a distance,
hoping that whatever decision is reached isn't too complicated to
implement.

Cheers,
ew0k

From petite.abeille at gmail.com  Fri Dec 18 10:35:17 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 18 Dec 2020 11:35:17 +0100
Subject: Unicode vs. the World
In-Reply-To: <CAJScK0+miqv-s401EKThiT-pr=UX+cW6ZV3d7EDqWTrBqX01=g@mail.gmail.com>
References: <87k0thj0tq.fsf@dorothy.carcosa.net>
 <F4B9E40A-B900-47A6-B7BE-BB001B30D845@gmail.com>
 <20201216234127.GB9267@brevard.conman.org>
 <QeE6KgToaR9dpBWXKntJFef_rpsHZwoSC09j_1Rfz7rnWqD0w1wertogaCrQC2dlnlLJYhp2zRvP3_76edQGUh_aAMg1SDrV27PiMgKRhBQ=@protonmail.com>
 <CAJScK0+pT9z9HdsWKy9ok+H=swaHmN8ZuYxLOQ9Fu395HGG6ug@mail.gmail.com>
 <CAD2gp_To25+oUmywJ-TyGHCoR+gzi+1oA+ZfMVaT17cFE+BzRw@mail.gmail.com>
 <CAJScK0+miqv-s401EKThiT-pr=UX+cW6ZV3d7EDqWTrBqX01=g@mail.gmail.com>
Message-ID: <7795DC8B-9BDD-438A-B504-AF0C853C8F48@gmail.com>



> On Dec 18, 2020, at 10:59, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
> I'll bow out of this discussion now and follow it from a distance,
> hoping that whatever decision is reached isn't too complicated to
> implement.

The /mild/ complexity arises from URI escaping rules. If anything, IRI simplify things a bit for all concerned.

Consider the following URIs (as per the current spec, which all MUST support one way or another):

=> gemini://rabbit.hole/bunny%20%26%20carrot.gmi Bunny & Carrot: Down The Rabbit Hole, a journey.
=> gemini://rabbit.hole/%F0%9F%90%B0%20%26%20%F0%9F%A5%95.gmi ? & ?: Down The Rabbit Hole, a journey.
=> gemini://xn--yn8h.hole/%F0%9F%90%B0%20%26%20%F0%9F%A5%95.gmi ? & ?: Down The Rabbit Hole, a journey.

vs. IRIs:

=> gemini://rabbit.hole/bunny%20%26%20carrot.gmi Bunny & Carrot: Down The Rabbit Hole, a journey.
=> gemini://rabbit.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey.
=> gemini://?.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey.





From luke at marmaladefoo.com  Fri Dec 18 12:12:47 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 18 Dec 2020 12:12:47 +0000
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201216150549.GA19202@sources.org>
References: <20201216150549.GA19202@sources.org>
Message-ID: <5FDC9CBF.8010804@marmaladefoo.com>


On 16-Dec-2020 15:05, Stephane Bortzmeyer wrote:
> I'm running a Gemini crawler, which gathers metadata about the
> geminispace. The goal is not to make a search engine but to survey the
> geminispace.
>
> You can find the current results (the crawler did not crawl the entire
> space yet):
>
> gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
(Due to user error, my reply was supposed to go to the list, but was 
sent privately, so I'm re-posting)

This is very interesting thank you.

Could it be possible to show the distribution of page sizes in 
geminispace? I know you show the average page size, but to get a better 
view of what is typical and the range would be good. For example does it 
follow a power law etc...

Is there any raw data available?

  - Luke


From petite.abeille at gmail.com  Fri Dec 18 14:37:00 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 18 Dec 2020 15:37:00 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201216150549.GA19202@sources.org>
References: <20201216150549.GA19202@sources.org>
Message-ID: <D40D494A-03E5-433B-9490-E3CE7F07D749@gmail.com>



> On Dec 16, 2020, at 16:05, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> I'm running a Gemini crawler, which gathers metadata about the
> geminispace.

Along those lines, a couple of one-liners to gather various host & content information:


# IP address(es)
# dig +short mozz.us
174.138.124.169


# geolocation
# curl --silent https://tools.keycdn.com/geo.json?host=174.138.124.169 | jq | gron
json = {};
json.data = {};
json.data.geo = {};
json.data.geo.asn = 14061;
json.data.geo.city = "North Bergen";
json.data.geo.continent_code = "NA";
json.data.geo.continent_name = "North America";
json.data.geo.country_code = "US";
json.data.geo.country_name = "United States";
json.data.geo.datetime = "2020-12-18 09:04:57";
json.data.geo.host = "174.138.124.169";
json.data.geo.ip = "174.138.124.169";
json.data.geo.isp = "DIGITALOCEAN-ASN";
json.data.geo.latitude = 40.793;
json.data.geo.longitude = -74.0247;
json.data.geo.metro_code = 501;
json.data.geo.postal_code = "07047";
json.data.geo.rdns = "174.138.124.169";
json.data.geo.region_code = "NJ";
json.data.geo.region_name = "New Jersey";
json.data.geo.timezone = "America/New_York";
json.description = "Data successfully received.";
json.status = "success";


# certificate info
# cfssl certinfo -domain mozz.us | jq | gron
json = {};
json.authority_key_id = "A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1";
json.issuer = {};
json.issuer.common_name = "Let's Encrypt Authority X3";
json.issuer.country = "US";
json.issuer.names = [];
json.issuer.names[0] = "US";
json.issuer.names[1] = "Let's Encrypt";
json.issuer.names[2] = "Let's Encrypt Authority X3";
json.issuer.organization = "Let's Encrypt";
json.not_after = "2021-01-21T01:36:54Z";
json.not_before = "2020-10-23T01:36:54Z";
json.pem = "-----BEGIN CERTIFICATE-----\nMIIGJzCCBQ+gAwIBAgISBAK7/ku/XjgmczVT7mmM1cEcMA0GCSqGSIb3DQEBCwUA\nMEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD\nExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDEwMjMwMTM2NTRaFw0y\nMTAxMjEwMTM2NTRaMBIxEDAOBgNVBAMTB21venoudXMwggEiMA0GCSqGSIb3DQEB\nAQUAA4IBDwAwggEKAoIBAQDZ4pi5q0QlIxAo8sKNBgInG1BGH584lRghCdnrBsZD\n68IuFlJ3V3wrnfsaNv8IZOHRkvxN2uxDo/oVxCCSNug/Ne4b+Pqw7U8thB9zL46A\nMbrHVtAmloykToDRlOHv/OLp2YRQiW7cD57lxot+9+TPlHsAuMccQXQDMbmhT6bf\nirO4m6F6gRf478YLLVOmpxkLd87dhHa7gO3NwmRroIB/DMLdQRAVAMbdDGTjdCrA\nlToWeHOnPNBLKPmI6M9DCqEXoTbIa9OhpJmo+txlS85O8/RHzXu2fVkgnEnBIcsE\n/ZEh5ytov1SogIXzNQgIJFesaWCqgBPLun4molEnfcq5AgMBAAGjggM9MIIDOTAO\nBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwG\nA1UdEwEB/wQCMAAwHQYDVR0OBBYEFI3x/VWfHHCG1IfE32kGHZPG4RC6MB8GA1Ud\nIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMwYTAuBggr\nBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9yZzAvBggr\nBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9yZy8wgfIG\nA1UdEQSB6jCB54ILYXBpLm1venoudXOCE2FzdHJvYm90YW55Lm1venoudXOCDGNo\nYXQubW96ei51c4ILZGV2Lm1venoudXOCDmdlbWluaS5tb3p6LnVzggtnaXQubW96\nei51c4IRZ29vZHZpYmVzLm1venoudXOCDmdvcGhlci5tb3p6LnVzghRtYWlsLWFy\nY2hpdmUubW96ei51c4IMbWFpbC5tb3p6LnVzgg9taWNoYWVsLm1venoudXOCB21v\nenoudXOCDnBvcnRhbC5tb3p6LnVzgg1wcm94eS5tb3p6LnVzggt3d3cubW96ei51\nczBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUF\nBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQQGCisGAQQB1nkCBAIE\ngfUEgfIA8AB3AJQgvB6O1Y1siHMfgosiLA3R2k1ebE+UPWHbTi9YTaLCAAABdVNQ\n7ygAAAQDAEgwRgIhALmUv4K/i3UcPYCIseckN2nfpk8g+Gi4MZRq6Ybr8/JXAiEA\n00kRkd+19OB2j4VASwsoQatWKasN+yTMnkQWOf2YMbsAdQB9PvL4j/+IVWgkwsDK\nnlKJeSvFDngJfy5ql2iZfiLw1wAAAXVTUO9TAAAEAwBGMEQCICOymh52Ogxx/wjJ\ngo5TEIgfEDtgXvKdfBsVtibLeZQWAiAyiUPq2MBPxn9+KJFhhxE8LRI9VIhpWnHV\n5JlOp2dIYzANBgkqhkiG9w0BAQsFAAOCAQEARqt9QyY4Fq7SBindKcHyrsQ9JtqB\nvfZy5yDKzFwuQZKmk2pxOzapCNRLNeyiEalfIFzrtHI11gr1ZEFHL1rA7pO3ud/j\nM2r0lmvNf8W+kUVf4Gng0TqGyRRh28RDNDCaz8uaYeg5C6BPUIZtHbO6qJBNme2W\noS4Qp0fjjAUvSQwTKDEh5GKnZv4AnJifMRqSXgZ+HgsamqydODRRTszwCMTMGBhO\naUOf+wF9l90T9N3MLDxSdixh4/qMuE0LpIsyeLJJ08ZsmOvOPtar0zxUw8AXMtGG\n62wmZhlY+vXD4Nk6cKTepSCVEHmCLTtckbHfn518wCQEvJZYYVApG0y1QQ==\n-----END CERTIFICATE-----\n";
json.sans = [];
json.sans[0] = "api.mozz.us";
json.sans[1] = "astrobotany.mozz.us";
json.sans[2] = "chat.mozz.us";
json.sans[3] = "dev.mozz.us";
json.sans[4] = "gemini.mozz.us";
json.sans[5] = "git.mozz.us";
json.sans[6] = "goodvibes.mozz.us";
json.sans[7] = "gopher.mozz.us";
json.sans[8] = "mail-archive.mozz.us";
json.sans[9] = "mail.mozz.us";
json.sans[10] = "michael.mozz.us";
json.sans[11] = "mozz.us";
json.sans[12] = "portal.mozz.us";
json.sans[13] = "proxy.mozz.us";
json.sans[14] = "www.mozz.us";
json.serial_number = "349379594475839169414317025618006180741404";
json.sigalg = "SHA256WithRSA";
json.subject = {};
json.subject.common_name = "mozz.us";
json.subject.names = [];
json.subject.names[0] = "mozz.us";
json.subject_key_id = "8D:F1:FD:55:9F:1C:70:86:D4:87:C4:DF:69:06:1D:93:C6:E1:10:BA";


# retrieve content type
# openssl s_client -quiet -crlf -connect mozz.us:1965 <<< gemini://mozz.us/ 2>/dev/null | head -1
20 text/gemini; lang=en


# double check content type
# openssl s_client -quiet -crlf -connect mozz.us:1965 <<< gemini://mozz.us/ 2>/dev/null | file --brief --mime-type --mime-encoding -
text/plain; charset=utf-8


# validate encoding
# openssl s_client -quiet -crlf -connect mozz.us:1965 <<< gemini://mozz.us/ 2>/dev/null | iconv -f utf-8 -t utf-8 > /dev/null; echo $?
0


# guess language
# echo $(openssl s_client -quiet -crlf -connect mozz.us:1965 <<< gemini://mozz.us/ 2>/dev/null ) | polyglot detect | cut -d' ' -f1 | uniq
English



From stephane at sources.org  Fri Dec 18 16:08:41 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 18 Dec 2020 17:08:41 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <5FDC9CBF.8010804@marmaladefoo.com>
References: <20201216150549.GA19202@sources.org>
 <5FDC9CBF.8010804@marmaladefoo.com>
Message-ID: <20201218160841.GA2019@sources.org>

On Fri, Dec 18, 2020 at 12:12:47PM +0000,
 Luke Emmet <luke at marmaladefoo.com> wrote 
 a message of 23 lines which said:

> > gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

> Could it be possible to show the distribution of page sizes in geminispace?

Like this (the page was updated)?

* Less than 1 kbyte: 18465 URLs (48.7 %)
* 1 to 1000 kbytes: 15865 URLs (41.9 %)
* More than 1000 kbytes: 3559 URLs (9.4 %)

> Is there any raw data available?

The code is available. For the data, I'm not decided yet. True, it is
only public data, and there is not even the content of the pages, but
I don't know yet if there isn't some privacy/ethical problem. Let me
check.

From petite.abeille at gmail.com  Fri Dec 18 17:04:07 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 18 Dec 2020 18:04:07 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <D40D494A-03E5-433B-9490-E3CE7F07D749@gmail.com>
References: <20201216150549.GA19202@sources.org>
 <D40D494A-03E5-433B-9490-E3CE7F07D749@gmail.com>
Message-ID: <26DF118B-C613-4907-AE73-BE9CFC8A5E28@gmail.com>



> On Dec 18, 2020, at 15:37, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> # geolocation
> # curl --silent https://tools.keycdn.com/geo.json?host=174.138.124.169 | jq | gron

# while at it
# whois mozz.us | grep @
e-mail:       technical1 at registry.neustar
e-mail:       registrytechnical2 at neustar.biz
Registrar Abuse Contact Email: registrar-abuse at google.com
Registrant Email: lazar.michael22 at gmail.com
Admin Email: lazar.michael22 at gmail.com
Tech Email: lazar.michael22 at gmail.com

From lambdatronic at disroot.org  Fri Dec 18 17:16:43 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 18 Dec 2020 12:16:43 -0500
Subject: Unicode vs. the World
In-Reply-To: <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
Message-ID: <87sg83uj9g.fsf@disroot.org>

Katarina Eriksson <gmym at coopdot.com> writes:
>
> Anyway, the request reaches the server. "%20" become space and "%2b" become
> plus. I see no reason why it would be hard to also convert
> "%F0%9F%90%87" into bytes, so I will assume it isn't and wait for server
> software programmers to tell me how wrong I am.
>
> So now we have a string of bytes that we can use to fetch the bunny file.
> Wait. What happened with the case where the bunny isn't %-encoded? Why
> can't servers just blindly accept non-ASCII bytes as is? Is it a library
> thing? Anyway, I really should test this in a bunch of languages but I'm
> writing this on my phone on my way to work, so instead I present you this
> pseudo code:
>
> *ELIDED TEXT HERE*
>
> If these 3 lines are all true for the server software, I see no reason to
> %-encode those non-ASCII bytes in the client or anywhere else. Surely I
> have missed something obvious somewhere. Can anyone help me?

The Space Age server uses java.net.URI to parse incoming URI strings
into their component parts. It can accept URIs with unencoded UTF-8
path, query, and fragment parts (except that spaces must be
percent-encoded as %20). Unicode is not allowed in the hostname part.

One more data point for you,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From petite.abeille at gmail.com  Fri Dec 18 21:26:44 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 18 Dec 2020 22:26:44 +0100
Subject: Unicode vs. the World
In-Reply-To: <87sg83uj9g.fsf@disroot.org>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
 <87sg83uj9g.fsf@disroot.org>
Message-ID: <5A732F58-06EB-42C3-A885-4B48F17328D0@gmail.com>



> On Dec 18, 2020, at 18:16, Gary Johnson <lambdatronic at disroot.org> wrote:
> 
> The Space Age server uses java.net.URI to parse incoming URI strings
> into their component parts. It can accept URIs with unencoded UTF-8
> path, query, and fragment parts (except that spaces must be
> percent-encoded as %20). Unicode is not allowed in the hostname part.

Perhaps of interest:
xbib/net: Sane URL, URI, IRI implementations for Java
https://github.com/xbib/net


From luke at marmaladefoo.com  Fri Dec 18 22:03:00 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Fri, 18 Dec 2020 22:03:00 +0000
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201218160841.GA2019@sources.org>
References: <20201216150549.GA19202@sources.org>
 <5FDC9CBF.8010804@marmaladefoo.com> <20201218160841.GA2019@sources.org>
Message-ID: <5FDD2714.5040402@marmaladefoo.com>


>> Could it be possible to show the distribution of page sizes in geminispace?
> Like this (the page was updated)?
>
> * Less than 1 kbyte: 18465 URLs (48.7 %)
> * 1 to 1000 kbytes: 15865 URLs (41.9 %)
> * More than 1000 kbytes: 3559 URLs (9.4 %)

Those bands are very wide.

How about in increments of 10^n? e.g. 1kb, 10kb, 100kb....

Also we can have a good general idea of other media types, but to filter 
on text/gemini would be ideal. If you are inclined!

> The code is available. For the data, I'm not decided yet. True, it is
> only public data, and there is not even the content of the pages, but
> I don't know yet if there isn't some privacy/ethical problem. Let me
> check.

How about if the data was anonymised, like to remove IP address, domain 
name, path and file name and replaced by anonymous labels, like this

  - Domain name: "Domain1" ... "DomainN"
  - path: "Path1" ..."PathN"

but then still to include other details like:

resource size, media type, encoding, etc

That would still be a very useful for statistical analysis in the 
aggregate, without revealing any identifiable info?

  - Luke

From sean at conman.org  Fri Dec 18 22:45:33 2020
From: sean at conman.org (Sean Conner)
Date: Fri, 18 Dec 2020 17:45:33 -0500
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201218091303.GA7381@sources.org>
References: <20201216150549.GA19202@sources.org>
 <20201216231652.GA9267@brevard.conman.org>
 <20201218091303.GA7381@sources.org>
Message-ID: <20201218224533.GF9267@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Wed, Dec 16, 2020 at 06:16:53PM -0500,
>  Sean Conner <sean at conman.org> wrote 
>  a message of 27 lines which said:
> 
> > > You can find the current results (the crawler did not crawl the entire
> > > space yet):
> > > 
> > > gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
> 
> >   One stat I haven't seen yet (yours or from GUS) is a breakdown of
> > langauge.  How many pages had a lang parameter, then a breakdown by
> > language, how many multiple languages per parameters (for example,
> > "lang=en,fr").
> 
> Just ask :-) Now done:

  Thanks.

> gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
> 
> I note:
> 
> * French is the second language after english. Cocorico, as we say in
> France.
> 
> * There is one page in finnish.

  And I see one page that is both English and Japanese.

> * There are more HTML than Markdown pages on the geminispace, which I
> find suprising.

  Not really, as I've come across one Gemini site that only serves up HTML.

> * There is one page in EBCDIC and one in CP-437 :-)

  Now *THAT* is surprising.

  -spc


From lambdatronic at disroot.org  Fri Dec 18 23:38:55 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Fri, 18 Dec 2020 18:38:55 -0500
Subject: Unicode vs. the World
In-Reply-To: <5A732F58-06EB-42C3-A885-4B48F17328D0@gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
 <87sg83uj9g.fsf@disroot.org>
 <5A732F58-06EB-42C3-A885-4B48F17328D0@gmail.com>
Message-ID: <87mtya8z1s.fsf@disroot.org>

Petite Abeille <petite.abeille at gmail.com> writes:
> Perhaps of interest:
> xbib/net: Sane URL, URI, IRI implementations for Java
> https://github.com/xbib/net

Thanks for the link. I gave it a shot, but it appears to be buggy and
doesn't have any documentation. I ended up reading through the source
code on Github to figure out how to call its API, but sadly it looks
like it can't correctly identify the host part of the incoming string.
Instead, it thinks it is part of the path, which is obviously no good.

space-age.requests> (parse-url "gemini://?.mozz.us/%20?.gmi?some-key=?&?=some-value#?-fragment")
{:path "/?.mozz.us/ ?.gmi",
 :raw-query "some-key=%F0%9F%90%87&%F0%9F%90%87=some-value",
 :fragment "?-fragment",
 :params ["some-key=?" "?=some-value"],
 :port 1965,
 :host "",
 :raw-fragment "%F0%9F%90%87-fragment",
 :uri
 "gemini://?.mozz.us/%20?.gmi?some-key=?&?=some-value#?-fragment",
 :query "some-key=?&?=some-value",
 :raw-path "/%F0%9F%90%87.mozz.us/%20%F0%9F%90%87.gmi",
 :raw-host "",
 :scheme "gemini"}

Oh well, I guess I'll stick with java.net.URI for now.

Cheers,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From sario528 at ctrl-c.club  Sat Dec 19 01:06:05 2020
From: sario528 at ctrl-c.club (sario528 at ctrl-c.club)
Date: Fri, 18 Dec 2020 20:06:05 -0500
Subject: [ANN] Gemini client list and reviews
Message-ID: <20201219010605.GA22408@ctrl-c.club>

I am announcing a new list of Gemini clients. My list is focused on
"full" clients, rather than libraries like go-gemini or tool like
gcat. As of this time I have all the clients listed on Gemini spec
software page, but I'm hoping that people will let me know about any
that I've missed.

As a companion to the list, I am also collecting client reviews.
Anyone is free to send in a review, please email the review to me
directly. Hopefully the combination of the list and reviews will make
for a good resource for finding new clients that fit your needs.

The list and reviews are both located at my capsule:

gemini://gemini.ctrl-c.club/~sario528/


Sario

From benulo at systemli.org  Sat Dec 19 06:17:49 2020
From: benulo at systemli.org (Ben)
Date: Sat, 19 Dec 2020 09:47:49 +0330
Subject: [ANN] Gemini client list and reviews
In-Reply-To: <20201219010605.GA22408@ctrl-c.club>
References: <20201219010605.GA22408@ctrl-c.club>
Message-ID: <e575f532-9607-18df-f5a7-283a7d0ba6a0@systemli.org>

Nice list! There's a few in there I haven't seen before.

Tinmop is one that I haven't tried yet because I've been unable to 
figure out how to compile or run it.

-- 
gemini://kwiecien.us/

From ew.gemini at nassur.net  Sat Dec 19 08:52:47 2020
From: ew.gemini at nassur.net (ew.gemini)
Date: Sat, 19 Dec 2020 09:52:47 +0100
Subject: [ANN] Gemini client list and reviews
In-Reply-To: <20201219010605.GA22408@ctrl-c.club>
References: <20201219010605.GA22408@ctrl-c.club>
Message-ID: <82lfdukwio.fsf@nassur.net>


sario528 at ctrl-c.club writes:

> I am announcing a new list of Gemini clients.
Nice!

The elpher source code is located here
=> https://thelambdalab.xyz/elpher/

Cheers,
~ew

-- 
Keep it simple!

From cage-dev at twistfold.it  Sat Dec 19 09:08:43 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 19 Dec 2020 10:08:43 +0100
Subject: [ANN] Gemini client list and reviews
In-Reply-To: <20201219010605.GA22408@ctrl-c.club>
References: <20201219010605.GA22408@ctrl-c.club>
Message-ID: <X93DG1f+Rqk/8kR1@kurosawa.casa.net>

On Fri, Dec 18, 2020 at 08:06:05PM -0500, sario528 at ctrl-c.club wrote:

[...]

>
> As a companion to the list, I am also collecting client reviews.
> Anyone is free to send in a review, please email the review to me
> directly. Hopefully the combination of the list and reviews will make
> for a good resource for finding new clients that fit your needs.

I find this expecially nice and useful, thanks! :)

Bye!
C.

From julien at typed-hole.org  Sat Dec 19 09:49:05 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Sat, 19 Dec 2020 10:49:05 +0100
Subject: [ANN] Gemini client list and reviews
In-Reply-To: <20201219010605.GA22408@ctrl-c.club>
References: <20201219010605.GA22408@ctrl-c.club>
Message-ID: <965BD72F-E6FE-45EF-BD08-DE4D80D47E46@typed-hole.org>


> Le 19 d?c. 2020 ? 02:06, sario528 at ctrl-c.club a ?crit :
> 
> ?I am announcing a new list of Gemini clients. My list is focused on
> "full" clients, rather than libraries like go-gemini or tool like
> gcat. As of this time I have all the clients listed on Gemini spec
> software page, but I'm hoping that people will let me know about any
> that I've missed.
> 
> As a companion to the list, I am also collecting client reviews.
> Anyone is free to send in a review, please email the review to me
> directly. Hopefully the combination of the list and reviews will make
> for a good resource for finding new clients that fit your needs.
> 
> The list and reviews are both located at my capsule:
> 
> gemini://gemini.ctrl-c.club/~sario528/
> 
> 
> Sario

Nice list!
The lr87 source code is located here: http://git.rainbow-100.com/cgit.cgi/LR-87/tree/network.F90

Also I have two more clients for you (both for plan9):
- gemnine (text) https://git.sr.ht/~ft/gemnine
- castor9 (GUI) https://git.sr.ht/~julienxx/castor9

Cheers,
julienxx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201219/fe7fa05e/attachment.htm>

From littlejohn at SDF.ORG  Sat Dec 19 10:17:46 2020
From: littlejohn at SDF.ORG (littlejohn at SDF.ORG)
Date: Sat, 19 Dec 2020 10:17:46 +0000
Subject: [ANN] The Saturday Morning Gemzine
Message-ID: <20201219101746.GA28385@SDF.ORG>

Dear Gemini fans,

It is well-established that, in 2020, a technology cannot be said to
be "for hipsters" unless someone is using it to run an e-zine. Since I
don't know of anyone who does that with Gemini, and I do not wish to
Hacker News to be disappointed with us, I took it upon myself to run
an e-zine on Gemini.

I am therefore writing to tell you about Smog: the Saturday MOrning
Gemzine. Smog is an independent, non-commercial, tech-focused but
non-tech-curious zine that seeks to encourage its readers to share
their ideas, to make new things and tinker with old ones, and to
challenge the publishing culture that's currently prevalent on the
WWW. It is likely to be labeled as either pointless or uselessly
contrarian by the Silicon Valley audience -- that was not deliberate
but we can't change it now, and Smog is too big to fail.

Smog is published at:

gemini://gemini.trans-neptunian.space/~smog/

and you can read its first issue here:

gemini://gemini.trans-neptunian.space/~smog/20201219-SmogIssue1.gmi

The first issue is deliberately slim and devoid of grand statements of
vision (or even tiny ones). Given the ephemeral nature of most
e-zines, I figured it's best to save those for the second issue.

Smog is published weekly. News and announcements will be present in
every issue. Every fourth issue will be slightly bigger than the other
ones and will include more reviews, tutorials and stories.

I will gladly publish letters from my readers, and will gladly publish
or re-publish any technical or non-technical articles that might be of
interest to the community. There are a few more details inside if
you're curious.

As a cultural hunch/experiment of sorts, I'm also running ads in Smog,
with a few catches: ads are ran for free, they're text-only but I
encourage clever ASCII hacks, and calls for donations & co. will
always get priority.

Please excuse any obvious hosting/server protocol compliance
problems. They will be remedied swiftly as soon as someone lets me
know about them -- if there are any, it's only because yours truly has
been lurking Gemini space for about an year and a half now but hasn't
*actually* tried hosting anything on Gemini before!

Thank you very much for your attention, and fingers crossed that the
second issue of Smog will have more than one reader even without me
spamming this list!

-- 
Little John <littlejohn at sdf.org>
Find me on Gemini: gemini://gemini.trans-neptunian.space/~littlejohn/
Via the SDF Public Access UNIX System - https://sdf.org

From bjorn.warmedal at gmail.com  Sat Dec 19 10:59:07 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Sat, 19 Dec 2020 11:59:07 +0100
Subject: [ANN] The Saturday Morning Gemzine
In-Reply-To: <20201219101746.GA28385@SDF.ORG>
References: <20201219101746.GA28385@SDF.ORG>
Message-ID: <98154D0F-F19C-48B4-9ED4-09544074C3FB@gmail.com>

YES!! ???????

Awesome initiative! I love zines!

Cheers
ew0k

Sent from my Nintendo Entertainment System

From ew.gemini at nassur.net  Sat Dec 19 12:17:27 2020
From: ew.gemini at nassur.net (ew.gemini)
Date: Sat, 19 Dec 2020 13:17:27 +0100
Subject: [ANN] The Saturday Morning Gemzine
In-Reply-To: <20201219101746.GA28385@SDF.ORG>
References: <20201219101746.GA28385@SDF.ORG>
Message-ID: <82lfdudm7c.fsf@nassur.net>

Dear littlejohn,

> gemini://gemini.trans-neptunian.space/~smog/20201219-SmogIssue1.gmi
Hilarious!

Linux eh, Gemini Weekly News, sort of? :)

Keep going!

Cheers,
Erich


-- 
Keep it simple!

From joseph at xylon.me.uk  Sat Dec 19 13:07:51 2020
From: joseph at xylon.me.uk (Joseph Graham)
Date: Sat, 19 Dec 2020 13:07:51 +0000
Subject: [ANN] The Saturday Morning Gemzine
In-Reply-To: <20201219101746.GA28385@SDF.ORG>
References: <20201219101746.GA28385@SDF.ORG>
Message-ID: <20201219130751.qn53rnbqcjc5jphm@future.joseph>

Wow I'll definitely be reading it. Thanks!

On Sat, Dec 19, 2020 at 10:17:46AM +0000, littlejohn at SDF.ORG wrote:
> Dear Gemini fans,
> 
> It is well-established that, in 2020, a technology cannot be said to
> be "for hipsters" unless someone is using it to run an e-zine. Since I
> don't know of anyone who does that with Gemini, and I do not wish to
> Hacker News to be disappointed with us, I took it upon myself to run
> an e-zine on Gemini.
> 
> I am therefore writing to tell you about Smog: the Saturday MOrning
> Gemzine. Smog is an independent, non-commercial, tech-focused but
> non-tech-curious zine that seeks to encourage its readers to share
> their ideas, to make new things and tinker with old ones, and to
> challenge the publishing culture that's currently prevalent on the
> WWW. It is likely to be labeled as either pointless or uselessly
> contrarian by the Silicon Valley audience -- that was not deliberate
> but we can't change it now, and Smog is too big to fail.
> 
> Smog is published at:
> 
> gemini://gemini.trans-neptunian.space/~smog/
> 
> and you can read its first issue here:
> 
> gemini://gemini.trans-neptunian.space/~smog/20201219-SmogIssue1.gmi
> 
> The first issue is deliberately slim and devoid of grand statements of
> vision (or even tiny ones). Given the ephemeral nature of most
> e-zines, I figured it's best to save those for the second issue.
> 
> Smog is published weekly. News and announcements will be present in
> every issue. Every fourth issue will be slightly bigger than the other
> ones and will include more reviews, tutorials and stories.
> 
> I will gladly publish letters from my readers, and will gladly publish
> or re-publish any technical or non-technical articles that might be of
> interest to the community. There are a few more details inside if
> you're curious.
> 
> As a cultural hunch/experiment of sorts, I'm also running ads in Smog,
> with a few catches: ads are ran for free, they're text-only but I
> encourage clever ASCII hacks, and calls for donations & co. will
> always get priority.
> 
> Please excuse any obvious hosting/server protocol compliance
> problems. They will be remedied swiftly as soon as someone lets me
> know about them -- if there are any, it's only because yours truly has
> been lurking Gemini space for about an year and a half now but hasn't
> *actually* tried hosting anything on Gemini before!
> 
> Thank you very much for your attention, and fingers crossed that the
> second issue of Smog will have more than one reader even without me
> spamming this list!
> 
> -- 
> Little John <littlejohn at sdf.org>
> Find me on Gemini: gemini://gemini.trans-neptunian.space/~littlejohn/
> Via the SDF Public Access UNIX System - https://sdf.org

-- 
Joseph Graham; a tech-rights advocate from England.

My PGP key: 0x8cd7227da467d3ed404f6eefdb590f739e5ac458

I have three blogs:
  - my blog about the ethics of technology: http://www.technologicallyadvancedhuman.uk
  - my blog about computing and electronics: http://www.naughtycomputer.uk/
  - my blog about scooters and cafe reviews: http://cafereview.xylon.me.uk
I write software: https://www.suckmore.uk/
I run a public Taskenizer installation: https://taskenizer.xylon.me.uk

From pitr.vern at gmail.com  Sat Dec 19 13:16:14 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Sat, 19 Dec 2020 14:16:14 +0100
Subject: [ANN] Gemini client list and reviews
In-Reply-To: <965BD72F-E6FE-45EF-BD08-DE4D80D47E46@typed-hole.org>
References: <20201219010605.GA22408@ctrl-c.club>
 <965BD72F-E6FE-45EF-BD08-DE4D80D47E46@typed-hole.org>
Message-ID: <CAG-mZ3giT5efsaTav1veAiVM-2qAOzbaizks5AN3NhDuOveFCA@mail.gmail.com>

Please consider adding the iOS client -
https://github.com/pitr/gemini-ios - it has been recently released in the
App Store.

On Sat, Dec 19, 2020 at 10:49 Julien Blanchard <julien at typed-hole.org>
wrote:

>
> Le 19 d?c. 2020 ? 02:06, sario528 at ctrl-c.club a ?crit :
>
> ?I am announcing a new list of Gemini clients. My list is focused on
>
>
> "full" clients, rather than libraries like go-gemini or tool like
> gcat. As of this time I have all the clients listed on Gemini spec
> software page, but I'm hoping that people will let me know about any
> that I've missed.
>
> As a companion to the list, I am also collecting client reviews.
> Anyone is free to send in a review, please email the review to me
> directly. Hopefully the combination of the list and reviews will make
> for a good resource for finding new clients that fit your needs.
>
> The list and reviews are both located at my capsule:
>
> gemini://gemini.ctrl-c.club/~sario528/
>
>
> Sario
>
>
> Nice list!
> The lr87 source code is located here:
> http://git.rainbow-100.com/cgit.cgi/LR-87/tree/network.F90
>
> Also I have two more clients for you (both for plan9):
> - gemnine (text) https://git.sr.ht/~ft/gemnine
> - castor9 (GUI) https://git.sr.ht/~julienxx/castor9
>
> Cheers,
> julienxx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201219/5178bb7f/attachment.htm>

From fkfd at macaw.me  Sat Dec 19 15:05:19 2020
From: fkfd at macaw.me (Frederick Yin)
Date: Sat, 19 Dec 2020 23:05:19 +0800
Subject: [ANN] Sophon, a wiki protocol and implementation
Message-ID: <C7WUS8KWR1UB.1C8J1V0LDFCZV@fakefred>

Hi List,

I have been developing a new wiki protocol for Gemini over the past few
weeks and core, basic functions are finally implemented. On the
protocol's eponymous implementation, a user can do the following:

* see what pages there are on a server
* read a wiki page
* edit a section of a wiki page

(that't it)

The core concepts are that, a wiki page must following an order of some
kind and must not be in a state of anarchy. For example, section levels
only go as deep as Gemini header levels go (2nd- and 3rd-level for
sections and subsections), and that the contents of a page is editable
through a diff algorithm that generates and parses a unidiff-like
string (in this implementation, diff-match-patch:
https://github.com/google/diff-match-patch/).

Sophon also copied a few characteristics from MediaWiki in that a "meta"
section can be present before a ToC. Other features will be introduced
later.

The git repository is https://git.sr.ht/~fkfd/sophon

You can try it out by running test/demo_client.py in the repo, with flag
"-s gemini://fkfd.me". (Availability is temporary.)

This is my first project in Go, so please point out if any of my
practices are not recommended. However, in that case, it is preferred
that you use the project's mailing list, ~fkfd/gemini at lists.sr.ht.

Thank you for your attention, have a good day.
~fkfd

From stephane at sources.org  Sat Dec 19 16:47:37 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sat, 19 Dec 2020 17:47:37 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201218224533.GF9267@brevard.conman.org>
References: <20201216150549.GA19202@sources.org>
 <20201216231652.GA9267@brevard.conman.org>
 <20201218091303.GA7381@sources.org>
 <20201218224533.GF9267@brevard.conman.org>
Message-ID: <20201219164737.GB18243@sources.org>

On Fri, Dec 18, 2020 at 05:45:33PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 40 lines which said:

> > * There are more HTML than Markdown pages on the geminispace, which I
> > find suprising.
> 
>   Not really, as I've come across one Gemini site that only serves
>   up HTML.

Yes, but Gemini was supposed to be about lightness and soberness. So,
Markdown seems a better fit.

> > * There is one page in EBCDIC and one in CP-437 :-)
> 
>   Now *THAT* is surprising.

It is actually a capsule dedicated to tests <gemini://egsam.pitr.ca/>.


From solderpunk at posteo.net  Sat Dec 19 15:00:45 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 19 Dec 2020 16:00:45 +0100
Subject: Introducing list "topics"
Message-ID: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>

Greetings Geminauts!

Following on (finally!) from semi-recent discussion about the
possibility of splitting the mailing list up into multiple smaller lists
to allow people to follow only the subset(s) of discussion that re
interesting or relevant to them, I am happy to announce that we're ready
to begin testing something in this spirit.  I know some people have been
waiting for something like this for quite a while - thanks for your
patience.

The GNU Mailman software which powers this list has support for
something called "topics", and I've set some of these up just now.  For
example, any post to the list which has "[users]" in its subject or in
the first 5 lines of its body will be included in the "users" topic
(I'll say more below about the available topics and their intended
purposes below).  If you subscribe to one or more topics, then you will
*only* receive posts to the list which match the corresponding topics.
On the other hand, if you do not subscribe to any topics then you will
receive any and all posts, as if nothing had changed.  This basically
means nothing will change for you unless you opt-in to the new system by
subscribing to some subset of the available topics.  You can change your
subscription settings at any time by visiting
https://lists.orbitalfox.eu/listinfo/gemini.

The catch is that all of this only works if people remember to include
topic tags in their subjects, or early in their message bodies.  This is
mostly an issue for people starting new threads - once a topic tag is
included in the subject of a post, all replies will be included too
unless the person replying edits the subject to remove the topic.  If
you start a new thread and forget to add a topic, relatively few people
will actually see it - only those brave souls who follow the entire
list, or people who have subscribed to some topics but also made the
choice to still receive topicless posts (this is the option immediately
after the topic choices at the subscription options page).  This may
take a little getting used to, but hopefully it will not prove too hard
for us to pick up the habit.

Without further ado, the four currently defined topics are below.  I've
started out with just four to keep things relatively simple, but if over
time it becomes clear that we would benefit from more fine-grained
distinctions, I'm not opposed to moving in that direction.

# Users

Any post containing "[users]" in its subject belongs to the Users topic.
This topic is supposed to be used for discussion relevant to people
consuming and publishing content in Gemini-space, and is supposed to be
fairly non-technical.  Announcements of new capsules, new search
engines, new public resources (e.g. games like Astrobotany or
aggregators like CAPCOM or Spacewalk), and of new user-oriented software
(like clients, or site generators) is welcome here.

# Tech

Any post containing "[tech]" in its subject belongs to the Tech topic.
This topic is supposed to be used for discussion relevant to people
implementing Gemini software, running Gemini servers, or who are
generally interested in the technical side of things.  For example,
questions about the best way to implement some aspect of Gemini in a
particular language or environment, announcements of new libraries or
other developer/admin-oriented software, or discussion of advanced
subjects like building applications which use client certificates to
maintain state, are all welcome here.

# Spec

Any post containing "[spec]" in its subject belongs to the Spec topic.
This topic is supposed to be used for discussion towards finalising the
spec and the process of moving toward formally standardising Gemini with
bodies like IETF and IANA.  This is not a place to propose random
additions to the spec, but to address ambiguities and inconsistencies in
the existing spec and to resolve the few outstanding issues which have
already been raised.  It is possible (although hopefully increasingly
unlikely) that there are still important outstanding issues which
haven't been discovered yet - my sincere hope is that this kind of thing
will "bubble up" to [spec] after thorough discussion on [tech].

# Announce

Finally, any post containing "[announce]" in its subject belongs to the
Announce topic.  This is intended as a tool for me to make official,
important and infrequent announcements about the entire project which I
expect to be of very broad interest.  This will be a very low-traffic
topic, suitable for people who just want to keep loose tabs on the
project without trying to keep up with a daily stream of messages.  Note
that there's no access control on any of the topics, which means in
principle anybody can post to [announce].  I ask you to please not abuse
this, and don't post to [announce] unless you're me or I've told you
that you can do so.

That's all for now.  I hope that this change will help make the mailing
list a more manageable and more relevant resource for people.  Please be
patient and helpful during the transitional period (people are sure to
forget to include topics in their posts while the change is still new).
If this change does not seem to make the situation better we can
consider a proper splitting of the list in future, but this seems like a
less disruptive first step which we can try first.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sat Dec 19 18:55:05 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 19 Dec 2020 19:55:05 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201216150549.GA19202@sources.org>
Message-ID: <C7WZO5HZHIIM.3S6Y69UGY64IZ@stilgar>

On Wed Dec 16, 2020 at 4:05 PM CET, Stephane Bortzmeyer wrote:
> I'm running a Gemini crawler, which gathers metadata about the
> geminispace. The goal is not to make a search engine but to survey the
> geminispace.

This is very cool, thanks for your work!

I would be curious to see more thorough statistics on TLS certificates
in Geminispace.  It's nice that you have the Let's Encrypt percentage on
there, but I'd also like to know about self-signed certificates, what
the distribution of sizes, key types, lifepans etc. is.  But I know this
information is *not* easy to get at in Python without external
dependencies, so don't feel obligated to bang your head against it.

I have plans to write a certificate observatory daemon in 2021, with a
simple Gemini interface so that TOFU clients can query it regarding new
certs.  It should be straightforward to generate this kind of
information as a side-effect, so my curiosity on this front will be
satisfied one way or another sooner or later.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sat Dec 19 18:51:13 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 19 Dec 2020 19:51:13 +0100
Subject: [ANN] The Saturday Morning Gemzine
In-Reply-To: <20201219101746.GA28385@SDF.ORG>
Message-ID: <C7WZL6YP2H34.2OE1KNANZ6VS3@stilgar>

On Sat Dec 19, 2020 at 11:17 AM CET,  wrote:

> Smog is published at:
>
> gemini://gemini.trans-neptunian.space/~smog/
>
> and you can read its first issue here:
>
> gemini://gemini.trans-neptunian.space/~smog/20201219-SmogIssue1.gmi

This promises to be a lot of fun!  Best of luck with keeping it up and
running and thanks for your contribution to the community.

Cheers,
Solderpunk

From stephane at sources.org  Sat Dec 19 19:18:10 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sat, 19 Dec 2020 20:18:10 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <C7WZO5HZHIIM.3S6Y69UGY64IZ@stilgar>
References: <20201216150549.GA19202@sources.org>
 <C7WZO5HZHIIM.3S6Y69UGY64IZ@stilgar>
Message-ID: <20201219191810.GA22160@sources.org>

On Sat, Dec 19, 2020 at 07:55:05PM +0100,
 Solderpunk <solderpunk at posteo.net> wrote 
 a message of 22 lines which said:

> I'd also like to know about self-signed certificates,

I'm not expert enough on X.509 but do note that the obvious algorithm
to detect self-signed certificates (checking that issuer == subject)
does not work well in the geminispace where many certs are signed
by... someone (not a known CA but not the subject).

> But I know this information is *not* easy to get at in Python
> without external dependencies,

Most of it is easy to get
<https://framagit.org/bortzmeyer/lupa/-/issues/7>

> I have plans to write a certificate observatory daemon in 2021, with
> a simple Gemini interface so that TOFU clients can query it
> regarding new certs.

If it is just for surveying, fine. If it is to turn it into a security
system, be careful, there are many traps. Who can put new
certificates, how to be sure that clients will check it, etc.

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc6962.txt

From stephane at sources.org  Sat Dec 19 19:20:18 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sat, 19 Dec 2020 20:20:18 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <5FDD2714.5040402@marmaladefoo.com>
References: <20201216150549.GA19202@sources.org>
 <5FDC9CBF.8010804@marmaladefoo.com>
 <20201218160841.GA2019@sources.org>
 <5FDD2714.5040402@marmaladefoo.com>
Message-ID: <20201219192018.GA22552@sources.org>

On Fri, Dec 18, 2020 at 10:03:00PM +0000,
 Luke Emmet <luke at marmaladefoo.com> wrote 
 a message of 34 lines which said:

> How about if the data was anonymised, like to remove IP address, domain
> name, path and file name and replaced by anonymous labels, like this

Note that you did not receive my private message since your email server denies access to mine.

<luke at marmaladefoo.com>: host mx1.mythic-beasts.com[2a00:1098:0:86:1000:0:2:1]
    said: 550 Block listed: https://www.spamhaus.org/sbl/query/SBLCSS (in reply
    to MAIL FROM command)

(And, no, I do not intend to start begging Spamhaus to unlist me.)

From alex at nytpu.com  Sat Dec 19 19:31:50 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Sat, 19 Dec 2020 12:31:50 -0700
Subject: Introducing list "topics"
In-Reply-To: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
Message-ID: <20201219193150.54hmzkohxtzqpz6g@GLaDOS>

This is a very welcome change, thanks! I was worried that the list
wasn't big enough to justify there being multiple entirely separate
lists (gemini-users, gemini-spec, etc.), and this solves the problem
neatly without having to manage multiple lists.

I'm going to try to be a brave soul and stay subscribed to the full list
until I can no longer stand it, but there are many people on gemini that
will definitely appreciate this change.

Thanks for all your work on gemini solderpunk!

~nytpu

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201219/cee01224/attachment.sig>

From solderpunk at posteo.net  Sat Dec 19 20:11:41 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 19 Dec 2020 21:11:41 +0100
Subject: Introducing list "topics"
In-Reply-To: <20201219193150.54hmzkohxtzqpz6g@GLaDOS>
Message-ID: <C7X1ASQK7MTG.2UOE2KLGLLD19@stilgar>

On Sat Dec 19, 2020 at 8:31 PM CET, Alex // nytpu wrote:

> I'm going to try to be a brave soul and stay subscribed to the full list
> until I can no longer stand it, but there are many people on gemini that
> will definitely appreciate this change.

I plan to limit my attention, at least for the time being, just to
[spec] so I can focus on getting things finalised as soon as possible.
But I'll keep a loose eye on the other topics via the web archive, and
might expand my subscription again once my real life has settled down a
little bit and I've worked through my large existing backlog of things
to take care of.

However, I will probably have the option to receive topicless posts
turned on for, say, the rest of 2020, just because I expect the transition
period to be a little rough - e.g. there are still live threads which
obviously lack topics, and changing the subject to insert a topic now
might break thread display in some email clients.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sat Dec 19 22:29:33 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 19 Dec 2020 23:29:33 +0100
Subject: Unicode vs. the World
In-Reply-To: <87mtya8z1s.fsf@disroot.org>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
 <87sg83uj9g.fsf@disroot.org> <5A732F58-06EB-42C3-A885-4B48F17328D0@gmail.com>
 <87mtya8z1s.fsf@disroot.org>
Message-ID: <963BE2E3-130F-440C-93FF-6FAEC7DB33E6@gmail.com>



> On Dec 19, 2020, at 00:38, Gary Johnson <lambdatronic at disroot.org> wrote:
> 
> Thanks for the link. I gave it a shot, but it appears to be buggy

Right. It appears to know a fixed list of schemes. See SchemeRegistry:

https://github.com/xbib/net/blob/master/net-url/src/main/java/org/xbib/net/scheme/SchemeRegistry.java#L18

Perhaps one needs to register its own to extend it. perhaps something similar to HttpScheme:

https://github.com/xbib/net/blob/master/net-url/src/main/java/org/xbib/net/scheme/HttpScheme.java#L27



From sean at conman.org  Sat Dec 19 22:38:04 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 19 Dec 2020 17:38:04 -0500
Subject: Introducing list "topics"
In-Reply-To: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
Message-ID: <20201219223804.GL9267@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> 
> Without further ado, the four currently defined topics are below.  I've
> started out with just four to keep things relatively simple, but if over
> time it becomes clear that we would benefit from more fine-grained
> distinctions, I'm not opposed to moving in that direction.
> 
> # Users
> # Tech
> # Spec> 
> # Announce

  You might want to add a topic "[ann]" to allow users to announce new
sites or projects.  That's already being done by users.

  Also, are these topic markers compared case insensitively?  Is "[USERS]"
and "[users]" the same topic?  

  It's a cool idea, and I much prefer this to separate lists.

  -spc


From sean at conman.org  Sat Dec 19 22:39:13 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 19 Dec 2020 17:39:13 -0500
Subject: Introducing list "topics"
In-Reply-To: <20201219223804.GL9267@brevard.conman.org>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
 <20201219223804.GL9267@brevard.conman.org>
Message-ID: <20201219223913.GM9267@brevard.conman.org>

It was thus said that the Great Sean Conner once stated:
> It was thus said that the Great Solderpunk once stated:
> > 
> > Without further ado, the four currently defined topics are below.  I've
> > started out with just four to keep things relatively simple, but if over
> > time it becomes clear that we would benefit from more fine-grained
> > distinctions, I'm not opposed to moving in that direction.
> > 
> > # Users
> > # Tech
> > # Spec> 
> > # Announce
> 
>   You might want to add a topic "[ann]" to allow users to announce new
> sites or projects.  That's already being done by users.
> 
>   Also, are these topic markers compared case insensitively?  Is "[USERS]"
> and "[users]" the same topic?  

  Oh, and can an email be in two or more topics?  Like "[ann] [tech]"?

  -spc


From solderpunk at posteo.net  Sat Dec 19 22:51:39 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 19 Dec 2020 23:51:39 +0100
Subject: Introducing list "topics"
In-Reply-To: <20201219223913.GM9267@brevard.conman.org>
Message-ID: <C7X4PA02UOWF.3F9TPYSIDSVWD@stilgar>

On Sat Dec 19, 2020 at 11:39 PM CET, Sean Conner wrote:
> >   Also, are these topic markers compared case insensitively?  Is "[USERS]"
> > and "[users]" the same topic?  
>
> Oh, and can an email be in two or more topics? Like "[ann] [tech]"?

They're case insensitive.  The GNU Mailman docs don't actually seem to
answer your second question.  I would tentatively guess that an email
*can* be in two topics.  The topic markers are specified as regular
expressions, so if a subject matches against both expressions I don't
see why it wouldn't get sorted into both categories, but we'd have to
actually test it out...

Cheers,
Solderpunk


From text at sdfeu.org  Sat Dec 19 23:11:55 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Sat, 19 Dec 2020 23:11:55 -0000 (UTC)
Subject: Introducing list "topics"
References: <20201219223913.GM9267@brevard.conman.org>
 <C7X4PA02UOWF.3F9TPYSIDSVWD@stilgar>
Message-ID: <rrm1br$1187$1@ciao.gmane.io>

On Sat, 19 Dec 2020 23:51:39 +0100, Solderpunk wrote:
> On Sat Dec 19, 2020 at 11:39 PM CET, Sean Conner wrote:
>> Oh, and can an email be in two or more topics? Like "[ann] [tech]"?
> 
> They're case insensitive. The GNU Mailman docs don't actually seem to
> answer your second question. I would tentatively guess that an email
> *can* be in two topics.

Mailman code confirms, if I'm not mistaken:

https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/
Mailman/Handlers/Tagger.py

    for name, pattern, desc, emptyflag in mlist.topics:
        pattern = OR.join(pattern.splitlines())
        cre = re.compile(pattern, re.IGNORECASE)
        for line in matchlines:
            if cre.search(line):
                hits[name] = 1
                break

This list currently run by mailman 2.1.34; V3 is still working on topics:
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/
member_recipients.py#L92


From text at sdfeu.org  Sat Dec 19 23:43:06 2020
From: text at sdfeu.org (text at sdfeu.org)
Date: Sat, 19 Dec 2020 23:43:06 -0000 (UTC)
Subject: [tech] Mail client as Gemini browser?
Message-ID: <rrm36a$1187$2@ciao.gmane.io>

Emacs, mutt, aerc, ? users will probably smile at the following thought ?

I wondered whether it might be fun to have a Thunderbird plugin for 
browsing Gemini content.

Readers could thus mail comments to the content authors from within the 
same client ? with some wall.cgi comments could go online seemlessly? 
  gemini://perplexing.space/2020/post-to-my-wall.gmi

Still, I would not really want Thunderbird to be a browser, wondering 
about its many features like chat, twitter, etc. while neglecting CardDAV.


From petite.abeille at gmail.com  Sun Dec 20 00:39:42 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 01:39:42 +0100
Subject: [tech] /.well-known/capability ehlo
Message-ID: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>

Older protocols such as SMTP, POP3, IMAP, and NNTP have developed extension mechanism overtime:

SMTP has EHLO.
POP3 has CAPA.
IMAP has CAPABILITY.
NNTP has CAPABILITIES.

The principle is always the same: the client invoke a well known server command to list the server capabilities. The client can then use these extensions in coordination with the server.

The server capabilities are represented as a set of keywords, such as 8BITMIME, CHUNKING, PIPELINING, SIZE, etc, etc...

For example, in SMTP:

C: EHLO
S: 250-8BITMIME

This tell the client the server supports 8 bit data transmission, enabling the client to send such data, in addition to the 7bit defined by the standard.

In Gemini, a consenting client-server pair would use a similar mechanism to discover and negotiate new capabilities; above and beyond the ones defined by the standard itself.

Upon receiving a request at /.well-known/capability, a compatible server would respond with a text listing its capabilities, as keywords, one per line:

C: gemini://mozz.us/.well-known/capability
S: text
IRI

For example, the IRI keyword tells the client the server can understand and generate IRIs for both request and text/gemini links; in addition to the regular URIs defined by the specification itself.

Another capability could be EHLO.

EHLO tells the client it can extend the initial Gemini request with further keywords, after the URI:

C: gemini://mozz.us/bunny.gmi IRI
S: text/gemini
=> gemini://?.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey.

Another server extension could be CHUNK, telling the client to expect chunked transfer encoding.

Another server extension could be SIZE, telling the client to expect an additional size parameter, as part of the content type.

Another server extension could be PERSIST, informing the client the connection can be maintained after a response, allowing the client to issue further requests over the same connection.

Putting this together:

C: gemini://mozz.us/.well-known/capability
S: text
EHLO
IRI
PERSISTENT
SIZE
<server drops connection>
C: gemini://mozz.us/????.gmi IRI PERSIST SIZE
S: text/gemini; size=90
=> gemini://?.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey.
<server maintains connection, awaiting a further request>

In other words -after checking the server capabilities- the client request a persistent connection, with  content size, and IRIs.

That's all folks.

Thoughts? Opinions? Likes? Dislikes? Something?







From sean at conman.org  Sun Dec 20 01:26:23 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 19 Dec 2020 20:26:23 -0500
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
Message-ID: <20201220012623.GN9267@brevard.conman.org>


  I will say this was the most annoying message to reply to as my preferred
editor kept freaking out over the UTF-8 characters in this message.  Yes, I
am a aware that I might need to update some stuff around here, but please be
aware that the Unicode standard changes yearly.

  I'm just saying ...

  Anyway, on with the show.

It was thus said that the Great Petite Abeille once stated:
> Older protocols such as SMTP, POP3, IMAP, and NNTP have developed extension mechanism overtime:

  [ snip ]

> Putting this together:
> 
> C: gemini://mozz.us/.well-known/capability
> S: text
> EHLO
> IRI
> PERSISTENT
> SIZE
> <server drops connection>
> C: gemini://mozz.us/?.gmi IRI PERSIST SIZE
> S: text/gemini; size=90
> => gemini://?.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey.
> <server maintains connection, awaiting a further request>
> 
> In other words -after checking the server capabilities- the client request
> a persistent connection, with content size, and IRIs.

  HTTP is down the hall to the left.  This is Gemini, it's different.  I
don't think this will fly with the community.

> That's all folks.

  You forgot IFMODIFIEDSINCE, BYTERANGE, TITANSUPPORT, and STREAMING.  This
can get out of hand.  Again, HTTP is down the hall to the left.

> Thoughts? Opinions? Likes? Dislikes? Something?

  Not much.  Strong opinion.  Not at all.  Yes.  And nothing else to add.

  -spc


From lokesh at low-key.me  Sun Dec 20 01:37:33 2020
From: lokesh at low-key.me (Lokesh Krishna)
Date: Sun, 20 Dec 2020 01:37:33 GMT
Subject: [ANN] Gemini client list and reviews
In-Reply-To: <20201219010605.GA22408@ctrl-c.club>
References: <20201219010605.GA22408@ctrl-c.club>
Message-ID: <48505776-E41E-4FD3-A924-59D3F01870B6@low-key.me>

> As of this time I have all the clients listed on Gemini spec software page, but I'm hoping that people will let me know about any that I've missed.

Could you please also add Ariane? It's the best Gemini browser for Android that I know of.  

Its source is available at: https://codeberg.org/oppenlab/Ariane
? Lokesh Krishna

From petite.abeille at gmail.com  Sun Dec 20 01:41:02 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 02:41:02 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <20201220012623.GN9267@brevard.conman.org>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
Message-ID: <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>



> On Dec 20, 2020, at 02:26, Sean Conner <sean at conman.org> wrote:
> 
>> Thoughts? Opinions? Likes? Dislikes? Something?
> 
>  Not much.  Strong opinion.  Not at all.  Yes.  And nothing else to add.

Brief, concise, and clear. Thank you.

Cultural issues aside, such mechanism completely bypass the need for any protocol changes, while opening the door to infinite extensibility.

Q.E.D. 


From colecmac at protonmail.com  Sun Dec 20 01:44:41 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 20 Dec 2020 01:44:41 +0000
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
Message-ID: <GLtWkifsxXDhlFqkBZ6i5xNjmC_Drv-Dx9aE9rgRKh9Mc6nRVVAEWT4D0lfMoiFFMV5E1GFxwZxIbHzIWJklWgB28rvmTejeNLsxFaVojPI=@protonmail.com>

> while opening the door to infinite extensibility.


I mean no disrespect, but this is complete anti-feature to me. I agree with spc.


makeworld


From gmym at coopdot.com  Sun Dec 20 01:45:19 2020
From: gmym at coopdot.com (Katarina Eriksson)
Date: Sun, 20 Dec 2020 02:45:19 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
Message-ID: <CAObwWNhi1DGPgnKHk8cxwW2sx5iGRfx6dU+hvEi70Rnk3ZV-jA@mail.gmail.com>

Petite Abeille <petite.abeille at gmail.com> wrote:

> Cultural issues aside, such mechanism completely bypass the need for any
> protocol changes, while opening the door to infinite extensibility.
>

Isn't infinite extensibility a thing we're trying to get away from?

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201220/f4b69df5/attachment.htm>

From petite.abeille at gmail.com  Sun Dec 20 01:47:35 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 02:47:35 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <GLtWkifsxXDhlFqkBZ6i5xNjmC_Drv-Dx9aE9rgRKh9Mc6nRVVAEWT4D0lfMoiFFMV5E1GFxwZxIbHzIWJklWgB28rvmTejeNLsxFaVojPI=@protonmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
 <GLtWkifsxXDhlFqkBZ6i5xNjmC_Drv-Dx9aE9rgRKh9Mc6nRVVAEWT4D0lfMoiFFMV5E1GFxwZxIbHzIWJklWgB28rvmTejeNLsxFaVojPI=@protonmail.com>
Message-ID: <A362081E-11D3-4173-9B03-64F2A5F1B2C7@gmail.com>



> On Dec 20, 2020, at 02:44, colecmac at protonmail.com wrote:
> 
>> while opening the door to infinite extensibility.
> 
> 
> I mean no disrespect, but this is complete anti-feature to me. I agree with spc.

Fair enough. Time will tell how the protocol usage will evolve.


From petite.abeille at gmail.com  Sun Dec 20 01:52:06 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 02:52:06 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <CAObwWNhi1DGPgnKHk8cxwW2sx5iGRfx6dU+hvEi70Rnk3ZV-jA@mail.gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
 <CAObwWNhi1DGPgnKHk8cxwW2sx5iGRfx6dU+hvEi70Rnk3ZV-jA@mail.gmail.com>
Message-ID: <937965D2-C846-4697-A3F1-1522541D99F5@gmail.com>



> On Dec 20, 2020, at 02:45, Katarina Eriksson <gmym at coopdot.com> wrote:
> 
>> Cultural issues aside, such mechanism completely bypass the need for any protocol changes, while opening the door to infinite extensibility.
>> 
> Isn't infinite extensibility a thing we're trying to get away from?
> 

It is indeed, culturally speaking, at this point in time. But no amount of protocolar straitjacket can prevent evolution and change. Eventually. Even gopher evolved. A bit.

From cowan at ccil.org  Sun Dec 20 01:56:58 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 19 Dec 2020 20:56:58 -0500
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
Message-ID: <CAD2gp_QCHiQGz_VeMR5wfo_oy+ebmH+To4qoQGzfo6q0+5T8cw@mail.gmail.com>

On Sat, Dec 19, 2020 at 7:39 PM Petite Abeille <petite.abeille at gmail.com>
wrote:

Older protocols such as SMTP, POP3, IMAP, and NNTP have developed extension
> mechanism overtime:
>

However, some have not.  Multiple versions of NTP exist, but backward
compatibility is complete and there are no named extensions.
FTP, which is actually older than TCP/IP, likewise has neither extensions
nor versioning: new commands have been added and older ones have become
unnecessary, but that's all. Gopher+ was backward compatible with Gopher,
but was never widely adopted.

The principle is always the same: the client invoke a well known server
> command to list the server capabilities. The client can then use these
> extensions in coordination with the server.
>

Note however that this is not normally bilateral.  There is no way (like
Telnet WILL/WONT/DO/DONT) for the server to find out what extensions the
client supports.  Consequently, servers either have to exploit no client
extensions, or just use whatever client extensions they would like, and if
clients don't support them, tough turkey for the user.

The spirit of Gemini is that that clients and servers agree because they
all voluntarily comply with the current standard.  (Solderpunk keeps
talking about a permanent freeze, but _haud credo_.  What matters is that
evolution of the protocol document stays controlled and that software
authors have no incentive to ignore it.)

(The .sig below was chosen at random.)

John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
The competent programmer is fully aware of the strictly limited size of his
own
skull; therefore he approaches the programming task in full humility, and
among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201219/688048ff/attachment.htm>

From sebastian1231alejandro at gmail.com  Sun Dec 20 01:55:57 2020
From: sebastian1231alejandro at gmail.com (Sebastian Alejandro)
Date: Sat, 19 Dec 2020 20:55:57 -0500
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <937965D2-C846-4697-A3F1-1522541D99F5@gmail.com>
Message-ID: <C7X8ME8E7CX5.15HOIE28ERJFN@helios>

On Sat Dec 19, 2020 at 8:52 PM EST, Petite Abeille wrote:
> It is indeed, culturally speaking, at this point in time. But no amount
> of protocolar straitjacket can prevent evolution and change. Eventually.
> Even gopher evolved. A bit.

Sure, it did. But at this point in time, we don't need these changes.
Let's stick to what we have, and just let Gemini be Gemini.

From petite.abeille at gmail.com  Sun Dec 20 01:57:35 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 02:57:35 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <20201220012623.GN9267@brevard.conman.org>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
Message-ID: <EAEAC49E-4B4D-452D-82CF-B9D684A7D770@gmail.com>



> On Dec 20, 2020, at 02:26, Sean Conner <sean at conman.org> wrote:
> 
> And nothing else to add.

Another aspect of such mechanism, is allowing for safe experimentations, keeping esoteric interactions between consenting parties only. 


From petite.abeille at gmail.com  Sun Dec 20 02:03:44 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 03:03:44 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <CAD2gp_QCHiQGz_VeMR5wfo_oy+ebmH+To4qoQGzfo6q0+5T8cw@mail.gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <CAD2gp_QCHiQGz_VeMR5wfo_oy+ebmH+To4qoQGzfo6q0+5T8cw@mail.gmail.com>
Message-ID: <C4781C60-C8AD-4C79-A5F5-58205D518388@gmail.com>



> On Dec 20, 2020, at 02:56, John Cowan <cowan at ccil.org> wrote:
> 
> Note however that this is not normally bilateral.  There is no way (like Telnet WILL/WONT/DO/DONT) for the server to find out what extensions the client supports.  Consequently, servers either have to exploit no client extensions, or just use whatever client extensions they would like, and if clients don't support them, tough turkey for the user.

All is client driven, the server merely advertises its capabilities. Of course, the client could do the same:

C: gemini://mozz.us/.well-known/capability?persist+size 

> The spirit of Gemini is that that clients and servers agree because they all voluntarily comply with the current standard.  (Solderpunk keeps talking about a permanent freeze, but _haud credo_.  What matters is that evolution of the protocol document stays controlled and that software authors have no incentive to ignore it.)

The standard becoming the baseline.

> (The .sig below was chosen at random.)

Lucky draw.



From petite.abeille at gmail.com  Sun Dec 20 02:07:16 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 03:07:16 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <C7X8ME8E7CX5.15HOIE28ERJFN@helios>
References: <C7X8ME8E7CX5.15HOIE28ERJFN@helios>
Message-ID: <E1766087-9560-48EC-BDE8-48C2E02ED153@gmail.com>



> On Dec 20, 2020, at 02:55, Sebastian Alejandro <sebastian1231alejandro at gmail.com> wrote:
> 
> On Sat Dec 19, 2020 at 8:52 PM EST, Petite Abeille wrote:
>> It is indeed, culturally speaking, at this point in time. But no amount
>> of protocolar straitjacket can prevent evolution and change. Eventually.
>> Even gopher evolved. A bit.
> 
> Sure, it did. But at this point in time, we don't need these changes.
> Let's stick to what we have, and just let Gemini be Gemini.

Sure thing. But no one can foresee what Gemini will be. Time will tell.


From petite.abeille at gmail.com  Sun Dec 20 03:29:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 04:29:31 +0100
Subject: [ANN] The Saturday Morning Gemzine
In-Reply-To: <20201219101746.GA28385@SDF.ORG>
References: <20201219101746.GA28385@SDF.ORG>
Message-ID: <5A59874C-D133-40BC-983A-D2C2DE5DB948@gmail.com>



> On Dec 19, 2020, at 11:17, littlejohn at sdf.org wrote:
> 
> Smog is published at:
> 
> gemini://gemini.trans-neptunian.space/~smog/
> 

subscribed. thanks. great start.

From petite.abeille at gmail.com  Sun Dec 20 05:13:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 06:13:11 +0100
Subject: [tech] the duplo protocol
Message-ID: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>

Duplo: We are from the planet Duplo, and we're here to destroy you. 
Emmet: Oh, man.
-- The LEGO Movie, 2014


Gemini is build around 4 major blocks: TLS, URI, MIME,  and UTF8. As standard as they come. The bread and butter of the modern internet.

Furthermore, the gemini protocol and the text/gemini format are meant to be easy to assemble -both in term of implementations, and content creation- given the stated familiarity of the building blocks. 

Finally, the entire construct is meant to be immutable and immovable. All i's are dotted and all t's are crossed. No change shall happen. Ever. This is the way.

Everything Is AWESOME!!!
-- The LEGO Movie, 2014


Turns out, each of the blocks have their own share of idiosyncrasies, ambiguities, and, well, complications:

TLS:  overhead, complexity, support, tofu, no tofu, how to tofu, what is tofu?, seitan?, noise? etc, etc, etc... 
URI: URL vs. URI vs. IRI vs. URN vs... data:... userinfo... segment... query... reserved characters... encoding... transliteration... dns... etc, etc, etc...
MIME: to size or not to size? extendable or not? parameters or not? Postel or not?
UTF8: Unicode! Normalization! Validation! Internationalization! Globalization! IRI! IDN! Emoji! Punycode! Would rather use ASCII in practice, considering. Be the rest of the world damned.

"In theory there is no difference between theory and practice - in practice there is" 
-- Yogi Berra, allegedly


Then there is the commune. Where contrarian/questioning views are frown upon, borderline rude, if not outright insulting.  This is meant as a safe space; with trigger warning, cancel culture, and all.

The sum of all these technical realities and social dynamics make it at time difficult to communicate constructively about gemini's truths.

Just saying.







From sean at conman.org  Sun Dec 20 06:01:29 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 20 Dec 2020 01:01:29 -0500
Subject: [tech] the duplo protocol
In-Reply-To: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
Message-ID: <20201220060129.GQ9267@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> Turns out, each of the blocks have their own share of idiosyncrasies,
> ambiguities, and, well, complications:
> 
> TLS:  overhead, complexity, support, tofu, no tofu, how to tofu, what is
> tofu?, seitan?, noise? etc, etc, etc...

> URI: URL vs. URI vs. IRI vs. URN vs... data:... userinfo... segment...
> query... reserved characters... encoding... transliteration... dns... etc,
> etc, etc...

> MIME: to size or not to size? extendable or not? parameters or not? Postel
> or not?

> UTF8: Unicode! Normalization! Validation! Internationalization!
> Globalization! IRI! IDN! Emoji! Punycode! Would rather use ASCII in
> practice, considering. Be the rest of the world damned.
> 
> Just saying.

  Okay.  Now what?

  Remove TLS, URIs, MIME and UTF-8 and you are basically left with gopher
(that's down the hall to the right, by the way).

  -spc


From petite.abeille at gmail.com  Sun Dec 20 06:06:13 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 07:06:13 +0100
Subject: [tech] the duplo protocol
In-Reply-To: <20201220060129.GQ9267@brevard.conman.org>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
 <20201220060129.GQ9267@brevard.conman.org>
Message-ID: <0FE6510F-CF96-4F1F-ABDB-5A3259F269A3@gmail.com>



> On Dec 20, 2020, at 07:01, Sean Conner <sean at conman.org> wrote:
> 
> (that's down the hall to the right, by the way).

where do you live? your place sounds awesome.


From sean at conman.org  Sun Dec 20 06:13:03 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 20 Dec 2020 01:13:03 -0500
Subject: [tech] the duplo protocol
In-Reply-To: <0FE6510F-CF96-4F1F-ABDB-5A3259F269A3@gmail.com>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
 <20201220060129.GQ9267@brevard.conman.org>
 <0FE6510F-CF96-4F1F-ABDB-5A3259F269A3@gmail.com>
Message-ID: <20201220061303.GR9267@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Dec 20, 2020, at 07:01, Sean Conner <sean at conman.org> wrote:
> > 
> > (that's down the hall to the right, by the way).
> 
> where do you live? your place sounds awesome.

  Right across the street from the Argument Clinic, which is next door to
the Ministry of Silly Walks.

  -spc (You can't miss it---there's a cheese shop on the corner, right next
	to a pet shop)

From petite.abeille at gmail.com  Sun Dec 20 06:14:26 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 07:14:26 +0100
Subject: [tech] the duplo protocol
In-Reply-To: <20201220061303.GR9267@brevard.conman.org>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
 <20201220060129.GQ9267@brevard.conman.org>
 <0FE6510F-CF96-4F1F-ABDB-5A3259F269A3@gmail.com>
 <20201220061303.GR9267@brevard.conman.org>
Message-ID: <F00A0BDC-BC45-4D10-BD73-15BAF8AA00E5@gmail.com>



> On Dec 20, 2020, at 07:13, Sean Conner <sean at conman.org> wrote:
> 
>  -spc (You can't miss it---there's a cheese shop on the corner, right next
> 	to a pet shop)

:)


From petite.abeille at gmail.com  Sun Dec 20 06:42:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 07:42:04 +0100
Subject: [tech] the duplo protocol
In-Reply-To: <20201220060129.GQ9267@brevard.conman.org>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
 <20201220060129.GQ9267@brevard.conman.org>
Message-ID: <2BC58147-56F8-4BB4-AB06-DBC94F953025@gmail.com>



> On Dec 20, 2020, at 07:01, Sean Conner <sean at conman.org> wrote:
> 
>> Just saying.
> 
>  Okay.  Now what?

[NPR STYLE TRIGGER WARNING: THE FOLLOWING CONTENT MAY OFFEND SOME]

At a more practical level: gemini must man up. 

The specification is more akin to an animal rights activist manifesto than a formal protocol. Daniel Stenberg couldn't help but laugh at it in its current shape. Bad omen.

Stephane Bortzmeyer brought up good points about the sorry state of affairs of the protocol governance. Don't ignore him.

People are overwhelmed by all these discussions because the place is utter chaos. Organization wise. 

No amount of groupthink will get gemini out of this. A protocol is meant to be technical, not poetic..




From alex at nytpu.com  Sun Dec 20 06:52:18 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Sat, 19 Dec 2020 23:52:18 -0700
Subject: [Spec] Spec (un)freezes and the spec's future
Message-ID: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>

Hey everyone,

Solderpunk at some point mentioned a temporary spec freeze, unfreezing
for early 2021, then permanently finalizing the spec. I have no idea if
this is still the plan or not, but I still feel it would be a good idea
to discuss: what modifications would be made to the spec in an
"unfrozen" period, if any; what modifications would be made to the spec
in its permanent finalization stage; and how companion specs and the
like would be dealt with, both now and in the finalization stage.


Firstly, how spec changes should be approached in an unfrozen period, if
any of those pop up. We may be in one now, since Solderpunk updated the
spec to fix schemes? But at any rate, I believe most would agree that
the current state of debate is probably not the best in terms of
actually coming to an agreement. Not that you'll ever reach 100%
consensus, but most current debates seem pretty evenly divided which
isn't conductive to actually choosing a side to reflect in the spec. I'm
unsure how to remedy this, but I'm bringing it up.

On what changes should actually be made, in my opinion the only changes
that should be made at this point should be to fix glaring problems in
the spec. I guess that creates another problem, because people can't
even agree what a "glaring problem" is! Solderpunk's been pretty
reasonable, so I'll leave it up to them to actually decide what's a
problem and what's not, but it's a rule of thumb to say that things that
"would be nice" shouldn't be included at this point (I'm saying this as
someone who has a few would-be-nices of my own[a]). As a second rule of
thumb, I'd say no breaking changes, even if they do fix a problem in the
spec. Backwards compatibility is painful, but luckily we only have a
year and a half to deal with as opposed to the decades some projects
have to be compatible with, so hopefully it isn't as much of a hardship
as it possibly could've been.


Onto a permanent spec freeze, if such a thing would occur. I believe
making the spec totally immutable would be arrogant on our part, because
you can't pretend that it is 100% perfect. I'd say that no feature
changes, and few to no major changes in general should be made. I'd say
that there should only be three classes of changes in a finalized spec:
technological upgrades, clarifications, and error corrections.
Technological upgrades would be if a component of the stack has an
upgrade or a replacement, particularly when there's security involved.
To use TLS as an example, it would be removing TLSv2 support when TLSv3
reaches wide support. Clarifications would be just that, clarifications
of the spec in areas that are unclear or create ambiguity. Error
corrections would be fixing minor errors and edge cases that can be
fixed without breaking anything, and add no new features. This is
breaking so wouldn't count, but an example of error correction would be
the most recent spec change that adds a mandatory scheme to requests.


Finally, I'd like to address companion specs. Especially if the spec is
permanently finalized, there will be companion specs popping up all over
the place. This can be viewed as good, because it means that each spec
is nice and unix-y, doing only one thing each. This creates the problem
the web has though, where authors are expected to support an amorphous
and constantly changing group of specs and results in huge applications
that are impossible to maintain. Even if companion specs like Titan are
fine now, it leaves a huge opening for the web-ification of gemini in
the future WHEN (not if) FAANG-inspired malicious actors take an
interest in it. There are a few ways to address this, from the hardliner
approach of completely disallowing companions to the 100% inclusive
approach of creating a dedicated RFC listing. Obviously a middle ground
will have to be found, but a discussion on where exactly that may be is
warranted. You don't want to cut out useful things like titan, but you
also don't want to leave a huge extensibility window open.


A long rambling of my thoughts, but there's some discussion points (that
in hindsight should've been broken up into multiple emails) that IMO
should be addressed before any firm decisions are made regarding the
future of the spec.

~nytpu


[a]: https://lists.orbitalfox.eu/archives/gemini/2020/003748.html

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201219/5311299b/attachment-0001.sig>

From ew.gemini at nassur.net  Sun Dec 20 08:19:30 2020
From: ew.gemini at nassur.net (ew.gemini)
Date: Sun, 20 Dec 2020 09:19:30 +0100
Subject: [tech] the duplo protocol
In-Reply-To: <2BC58147-56F8-4BB4-AB06-DBC94F953025@gmail.com>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
 <20201220060129.GQ9267@brevard.conman.org>
 <2BC58147-56F8-4BB4-AB06-DBC94F953025@gmail.com>
Message-ID: <82v9cwdh4d.fsf@nassur.net>

Hello,

Petite Abeille writes:

> ... Daniel Stenberg couldn't help but laugh at it [the gemini
> protocol specification] in its current shape. ...

Would you (or anyone else or several?) be able to /start/ writing
it down in a form that would make Daniel Stenberg smile?

Cheers,
Erich

-- 
Keep it simple!

From stephane at sources.org  Sun Dec 20 09:59:43 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 20 Dec 2020 10:59:43 +0100
Subject: [tech] the duplo protocol
In-Reply-To: <2BC58147-56F8-4BB4-AB06-DBC94F953025@gmail.com>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
 <20201220060129.GQ9267@brevard.conman.org>
 <2BC58147-56F8-4BB4-AB06-DBC94F953025@gmail.com>
Message-ID: <20201220095943.GA5303@sources.org>

On Sun, Dec 20, 2020 at 07:42:04AM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 26 lines which said:

> The specification is more akin to an animal rights activist
> manifesto than a formal protocol.

Could you be more specific? The specification is not perfect (as the
discussion on IDN and IRI demonstrated) but, as an author of a few
specs and a reader of many more, I can say that it is certainly not
ridiculous. I wrote a client just from it, without reading other
clients' source code, something which is not possible with other
specs.

> Daniel Stenberg couldn't help but laugh at it in its current shape.

Being a reader of the curl mailing list, I don't think it is a good
assessment. Daniel criticized the lack of registration of the scheme
but he mostly criticized actual code (TOFU by default, and the lack of
test cases), not the specification.

> Stephane Bortzmeyer brought up good points about the sorry state of
> affairs of the protocol governance. Don't ignore him.

But I can add that I don't have a ready-made solution. True, I wish
there were a clearer way of discussing, approving and rejecting
changes in the spec, but it is not obvious how to do so. I certainly
don't advocate a formal process ("Gemini Foundation" or "Gemini
Consortium") right now, the Gemini system being too recent an, IMHO,
not done yet.

> People are overwhelmed by all these discussions because the place is
> utter chaos.

Wait until you've been in an IETF working group :-)

> No amount of groupthink will get gemini out of this. A protocol is
> meant to be technical, not poetic..

But a protocol also have goals, and goals are political, not
technical. We already have HTTP, which works fine. If we spend time on
Gemini, it is not because HTTP is technically broken (it is not) but
because we have goals that we find important (simplicity, lightness,
power consumption, reject of tracking, no distractions, etc) and which
are not reachable with HTTP.

From stephane at sources.org  Sun Dec 20 10:12:23 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 20 Dec 2020 11:12:23 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
Message-ID: <20201220101223.GB5303@sources.org>

On Sat, Dec 19, 2020 at 11:52:18PM -0700,
 Alex // nytpu <alex at nytpu.com> wrote 
 a message of 113 lines which said:

> On what changes should actually be made, in my opinion the only
> changes that should be made at this point should be to fix glaring
> problems in the spec. I guess that creates another problem, because
> people can't even agree what a "glaring problem" is!

The lack of any mention of IDN and IRI in the spec (and how to handle
them) is certainly a glaring problem. We are in 2020, we start a
completely new system, internationalization should not be an option.

> Solderpunk's been pretty reasonable, so I'll leave it up to them to
> actually decide what's a problem and what's not,

The way, I understand it, Gemini's governance is basically "Solderpunk
decides". This has good properties (it allows to keep the spec
consistent, and it avoids the committee effect) and bad ones, too
(when Solderpunk is busy with his relocation). But I agree that there
is no obvious alternative.

> As a second rule of thumb, I'd say no breaking changes, even if they
> do fix a problem in the spec. Backwards compatibility is painful,

I disagree here. I don't think that backward compatibility should be a
goal.

* Gemini starts from zero, this is an opportunity (one of the
strengths of Gemini, when compared to, say, HTTP).

* Gemini has few users and most are passionnate enough to handle a few
changes.

* Gemini is simple so modifying the existing clients and servers would
not be too complicated.

> the 100% inclusive approach of creating a dedicated RFC listing.

This approach seems reasonable. This is what the christian church did,
after all, write a canon, a list of approved texts
<https://en.wikipedia.org/wiki/Biblical_canon>.




From sean at conman.org  Sun Dec 20 10:17:17 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 20 Dec 2020 05:17:17 -0500
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220101223.GB5303@sources.org>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <20201220101223.GB5303@sources.org>
Message-ID: <20201220101717.GS9267@brevard.conman.org>

It was thus said that the Great Stephane Bortzmeyer once stated:
> On Sat, Dec 19, 2020 at 11:52:18PM -0700,
>  Alex // nytpu <alex at nytpu.com> wrote 
>  a message of 113 lines which said:
> 
> > As a second rule of thumb, I'd say no breaking changes, even if they
> > do fix a problem in the spec. Backwards compatibility is painful,
> 
> I disagree here. I don't think that backward compatibility should be a
> goal.

  I agree with Stephane (as much as I might have hemmed and hawed over
supporting IDN/IDI).  If we don't fix this now, it will be *years* before
it's fixed.  Gemini is still a young protocol.

  -spc

From stephane at sources.org  Sun Dec 20 10:17:06 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 20 Dec 2020 11:17:06 +0100
Subject: [Tech] Outages discussion (Was: Introducing list "topics"
In-Reply-To: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
Message-ID: <20201220101706.GA6094@sources.org>

[Replying with Tech as it seems the most reasonable.]

On Sat, Dec 19, 2020 at 04:00:45PM +0100,
 Solderpunk <solderpunk at posteo.net> wrote 
 a message of 100 lines which said:

> # Tech
> 
> Any post containing "[tech]" in its subject belongs to the Tech topic.
> This topic is supposed to be used for discussion relevant to people
> implementing Gemini software, running Gemini servers, or who are
> generally interested in the technical side of things.

Or discussions about outages and other operational events? For
instance, gus.guru is down for some times and this may be of general
interest. (Imagine the Web with Google Search down.)

From linde.philip at gmail.com  Sun Dec 20 10:40:12 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Sun, 20 Dec 2020 11:40:12 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <20201220012623.GN9267@brevard.conman.org>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
Message-ID: <20201220114012.c85368055ae9e081d2833165@gmail.com>

On Sat, 19 Dec 2020 20:26:23 -0500
Sean Conner <sean at conman.org> wrote:

> 
>   I will say this was the most annoying message to reply to as my preferred
> editor kept freaking out over the UTF-8 characters in this message.  Yes, I
> am a aware that I might need to update some stuff around here, but please be
> aware that the Unicode standard changes yearly.

Your editor doesn't need to be aware of the latest changes to the
Unicode code points to be able to edit UTF-8 without freaking out. In
UTF-8, a code point can easily be identified without knowing what it
means and the text rendering system can display a fallback character.

>   HTTP is down the hall to the left.  This is Gemini, it's different.  I
> don't think this will fly with the community.

Agreed. "Non-extensibility of the protocol was a major design principle
for Gemini." (Gemini FAQ)

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201220/7924b6e9/attachment.sig>

From lokesh at low-key.me  Sun Dec 20 12:28:00 2020
From: lokesh at low-key.me (Lokesh Krishna)
Date: Sun, 20 Dec 2020 12:28:00 GMT
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <E1766087-9560-48EC-BDE8-48C2E02ED153@gmail.com>
References: <C7X8ME8E7CX5.15HOIE28ERJFN@helios>
 <E1766087-9560-48EC-BDE8-48C2E02ED153@gmail.com>
Message-ID: <9CF502DB-8DB3-4960-9F48-8E866D8201AD@low-key.me>

> But no one can foresee what Gemini will be. 

Agreed but we do know there's a strong and clear vision for what we want Gemini to be.
? Lokesh Krishna

From luke at marmaladefoo.com  Sun Dec 20 13:03:43 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Sun, 20 Dec 2020 13:03:43 +0000
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201219192018.GA22552@sources.org>
References: <20201216150549.GA19202@sources.org>
 <5FDC9CBF.8010804@marmaladefoo.com> <20201218160841.GA2019@sources.org>
 <5FDD2714.5040402@marmaladefoo.com> <20201219192018.GA22552@sources.org>
Message-ID: <5FDF4BAF.9080603@marmaladefoo.com>


On 19-Dec-2020 19:20, Stephane Bortzmeyer wrote:
> Note that you did not receive my private message since your email 
> server denies access to mine.
> <luke at marmaladefoo.com>: host mx1.mythic-beasts.com[2a00:1098:0:86:1000:0:2:1]
>      said: 550 Block listed: https://www.spamhaus.org/sbl/query/SBLCSS (in reply
>      to MAIL FROM command)
>
> (And, no, I do not intend to start begging Spamhaus to unlist me.)
Sorry about that - my domain ISP runs a fairly typical setup - I don't 
usually have problems getting email from people. I certainly don't have 
the skills or inclination to run my own mail server, so I'm not in a 
position to adjust the email server.

Feel free to reply to the list, or if you want to send a personal email, 
you might try a different email address: luke [dot] emmet [at] gmail 
[dot] com

  - Luke

From skyjake at dengine.net  Sun Dec 20 13:21:50 2020
From: skyjake at dengine.net (skyjake)
Date: Sun, 20 Dec 2020 15:21:50 +0200
Subject: [tech] Synchronizing bookmarks - Request for comments
In-Reply-To: <Q2MvZmW523LQ2FGuHyNCiHL6JarlG5uu_kpyZ6RHjRfEGzRcUUtIM3Fy7RM9iWzxmwNroBgz3hiGHVJquiy2qfs5a5c6OVG7ZoMZjUTJOXQ=@protonmail.com>
References: <C7TPUWUBQ7BK.3C4ARXQIWRXGI@nitro>
 <eLtb0pMLH2dKRNU1AqcRtiAoq9DhqfeSxhN55bIX0ZgcxC_O2KiVl-5MVIoBt52pVR7N1cvP0xyH4MXUawiEpk0vq6plpUxjytPNxm4z8L8=@protonmail.com>
 <DD6E4BA2-D8E7-4E95-9667-688B90425BC8@dengine.net>
 <Q2MvZmW523LQ2FGuHyNCiHL6JarlG5uu_kpyZ6RHjRfEGzRcUUtIM3Fy7RM9iWzxmwNroBgz3hiGHVJquiy2qfs5a5c6OVG7ZoMZjUTJOXQ=@protonmail.com>
Message-ID: <17D4615A-5728-4467-8CCC-BBBEC7CEA9B1@dengine.net>

On 18. Dec 2020, at 0:31, colecmac at protonmail.com wrote:

>> I think the primary advantage of this bookmarks .gmi format would be interchange
>> between clients (and instances of the same client) without humans editing the file.
>> I don't think a client would want to store their bookmarks in this format, as there
>> may be additional (possible internal) metadata to deal with, too.
> 
> Well, that works for me. Amfora already has support for file:// URIs in master, so
> in the next release you'll be able to just open any gemtext file and use it as your
> free-form bookmarks.

Great! I've also added support for using bookmark .gmi files/pages in Lagrange (v1.0).


On 15. Dec 2020, at 23:08, C?me Chilliet <come at chilliet.eu> wrote:

> I?ve put together an idea of simple specification to allow clients to synchronize bookmarks and feeds across Gemini, as this is something that I?m currently missing in my daily Gemini use.
> * Would you consider implementing support for something like this?

I'm changing my previous answer now with Lagrange v1.0 having support for remote bookmarks. It solves 80% of the problem, especially if you throw in Dropbox/etc. to sync your bookmark files across devices, or get them via your existing Gemini server.

So what remains is automated upload of added/deleted bookmarks, and for that it seems setting up a custom server might be overkill. The UX benefits of automation are still there, but maybe there is something even simpler that could do the trick.

I'll give it some thought.

--jaakko


From chasmaticvoid at gmail.com  Sun Dec 20 13:35:29 2020
From: chasmaticvoid at gmail.com (starlit)
Date: Sun, 20 Dec 2020 15:35:29 +0200
Subject: [ANN] a tiny Gemini server written in Ruby
Message-ID: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>


hello all, starlit here with a humble announcement about a Gemini server 
written in ruby. i have no experience with mailing lists so please bear 
with me.

all the code can be found on source hut 
(https://git.sr.ht/~starlit/gemini-ruby-server). [insert lots of caveats 
here about how it's WIP and how ruby purists will hate it, etc. etc. etc.]

it started as a ruby port of Satellite, but i am trying to take it in 
the direction of a library that you can extend, so you can provide 
custom responses. kind of like a CGI hook, but directly inside of ruby. 
the server does all the validation and handles responses, but gives you 
the request to respond to as you like. (the current version just serves 
files from a directory.)

why did i make this? well,

1. i love ruby for 0 rational reasons (basically still running off of 
the excitement that _why stirred up back in the day), and i have vague 
ideas for what i would do with it (some kind of Weird art project or 
something), and it would be cool to have that in ruby
2. i think it will appeal to cryptids like myself (_ghostly apparitions 
begin snaking into the network_)
3. maybe it will enrich the toolset and breadth of where Gemini and 
related technology can be found
4. "look ma, i'm useful!" it would be cool if i could give something 
back to the amorphous concept of "open software"

i'm really excited and thankful to be doing something "creative" 
especially during these extremely difficult times. i hope this is 
interesting to someone. i'm open to any and all feedback, but please be 
gentle because as the prophet PeePee once said, "i Amn just........... a 
litle creacher. Thatse It . I Canot change this."

-starlit <chasmaticvoid at gmail.com>

@starlit_void at twitter, @starlit at glitch.social, @starlit at oulipo.social




From natpen at natpen.net  Sun Dec 20 13:58:53 2020
From: natpen at natpen.net (Natalie Pendragon)
Date: Sun, 20 Dec 2020 08:58:53 -0500
Subject: [Tech] Outages discussion (Was: Introducing list "topics"
In-Reply-To: <20201220101706.GA6094@sources.org>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
 <20201220101706.GA6094@sources.org>
Message-ID: <X99YncWfv6Uslmcw@goldfish.localdomain>

On Sun, Dec 20, 2020 at 11:17:06AM +0100, Stephane Bortzmeyer wrote:
> For instance, gus.guru is down

Yikes! GUS lives again. Thank you for the heads up.

...maybe it's time I took a look at Manisha, your Nagios plugin for
Gemini :)

From skyjake at dengine.net  Sun Dec 20 14:14:25 2020
From: skyjake at dengine.net (skyjake)
Date: Sun, 20 Dec 2020 16:14:25 +0200
Subject: [users] [ANN] Lagrange v1.0
Message-ID: <49056B57-1172-4EDC-95E6-7B4EF8D0E123@dengine.net>

Hello all,

Lagrange is a cross-platform desktop GUI client for browsing Geminispace. It is written in C and uses an SDL2-based custom UI toolkit with no dependencies on existing GUI frameworks. The app is designed to be lightweight, fast, and nice to use.

=> gemini://skyjake.fi/lagrange/

After five months of coding, version 1.0 is here.

Version numbers can be pretty arbitrary but the switch from major version zero to one has special significance. In the case of this project it denotes a shift of gears, as the initial rapid iteration phase ends and things should proceed in a calmer and more orderly fashion. In other words, version 1.0 is the first stable release.

While version 1.0 should be feature-rich enough to be comfortable to use, I have a long list of improvement ideas for the existing features and for adding new ones. Now is a time to take stock and reprioritize ? after a while it should become clear which areas are lacking and what can wait until later.

Version 1.0 introduces a couple of bookmark related features. For example, you can use a Gemini page as a source of remote bookmarks. You can read more about this here:

=> gemini://skyjake.fi/gemlog/2020-12_lagrange-1.0.gmi

--jaakko

From cage-dev at twistfold.it  Sun Dec 20 14:52:28 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 20 Dec 2020 15:52:28 +0100
Subject: Introducing list "topics"
In-Reply-To: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
Message-ID: <X99lLDzQAR2PIOg4@kurosawa.casa.net>

On Sat, Dec 19, 2020 at 04:00:45PM +0100, Solderpunk wrote:
> Greetings Geminauts!

Hi!

[...]

I wonder if could  be a good idea to send this email  (or a summary of
it) with  stable frequency on the  mailing list so that  newcomers can
understand how topics works and which ones are valid here.

Bye!
C.

From solderpunk at posteo.net  Sun Dec 20 14:00:00 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 20 Dec 2020 15:00:00 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
Message-ID: <C7XO0RQ3BUJF.QXXWD9KAZLTF@stilgar>

On Sun Dec 20, 2020 at 7:52 AM CET, Alex // nytpu wrote:

> Solderpunk at some point mentioned a temporary spec freeze, unfreezing
> for early 2021, then permanently finalizing the spec. I have no idea if
> this is still the plan or not, but I still feel it would be a good idea
> to discuss: what modifications would be made to the spec in an
> "unfrozen" period, if any; what modifications would be made to the spec
> in its permanent finalization stage; and how companion specs and the
> like would be dealt with, both now and in the finalization stage.

To be honest, I don't at this point remember precisely what I said
previously, but my hope is still to have this whole thing finalised in
the first half of 2021, and even better in the first quarter.  I'm not
sure there's much value at this point to establishing an exact schedule
with clearly demarcated frozen/unfrozen states.  The permanent freeze on
non-trivial new features I announced several months ago is, well, still
in place because that's what permanent means.  There are a few issues
under consideration right now (the IRI/IDN issue, a desire for clarity
on "streaming" responses, and some finicky point about URLs which I need
to remind myself of), and I'm preparing to start finally addressing
these things during my time off between Christmas and the New Year
(expect me to finally offer some thoughts on the IRI/IDN thing in the
new few days).  I don't envision anything else being given serious
consideration.

> Onto a permanent spec freeze, if such a thing would occur. I believe
> making the spec totally immutable would be arrogant on our part, because
> you can't pretend that it is 100% perfect.

Things don't need to be 100% perfect to be useful.  I think it's
arrogant to *aim* for perfection.  I know it's very much going against
the grain to declare than any kind of software project is "done"; I know
that people nowadays explicitly avoid using or recommending software for
the sole reason that it is no longer being actively developed.  I
honestly think this is all very strange and backwards.  If, after an
initial busy development period of a year or so, each new release of a
program does not come out after a longer delay than the last one, it
probably means either the program is poorly designed and each fix or
improvement introduces more problems than it solves, so it's doomed to be
unreliable and/or inefficient forever, or else the program's scope is
too wide or too poorly defined, in which case it is doomed to expand
forever, growing ever more complex and featureful until it inevitably
becomes poorly designed and faces the same fate above.  There's no reason
that network protocols with humble aspirations should be any different.
Things can be "finished" and remain useful as-is for decades.  Perhaps
not forever, but certainly for decades.

Gopher is a great example here.  RFC 1436 is coming up on 28 years old
now.  There are very few changes/extensions to that specification which
are so widely used in Gopherspace today as to be considered basically
mandatory.  All those changes are themselves at least 20 years old at
this point, and they're minor enough that if the RFC were updated to
include them, it would likely not grow in length by more than 10%, and
90% of the lines would remain unchanged.  Despite this fossilised
status, Gopher remains useful, in use and well-loved today, and is in
fact undergoing a small resurgence.  It's proof that if you keep things
simple enough, you can get close enough to "right" the first time, which
is very much what I'd like Gemini to achieve.  It's true Gemini is more
complicated than Gopher - but it's also, I imagine, been designed by a
larger group of people over a longer period of time than Gopher was, and
at this point has received non-trivial real-world testing.

All of which is to say that I really do want to attempt a permanent spec
freeze.  I suppose I reserve the right to change my mind if cold hard
reality proves me wrong, but for now I don't really want to bother
making plans for how to handle this.

> Finally, I'd like to address companion specs. Especially if the spec is
> permanently finalized, there will be companion specs popping up all over
> the place. This can be viewed as good, because it means that each spec
> is nice and unix-y, doing only one thing each. This creates the problem
> the web has though, where authors are expected to support an amorphous
> and constantly changing group of specs and results in huge applications
> that are impossible to maintain. Even if companion specs like Titan are
> fine now, it leaves a huge opening for the web-ification of gemini in
> the future WHEN (not if) FAANG-inspired malicious actors take an
> interest in it. There are a few ways to address this, from the hardliner
> approach of completely disallowing companions to the 100% inclusive
> approach of creating a dedicated RFC listing. Obviously a middle ground
> will have to be found, but a discussion on where exactly that may be is
> warranted. You don't want to cut out useful things like titan, but you
> also don't want to leave a huge extensibility window open.

I don't see how completely disallowing companion specs is really
possible.  I could refuse to host them or to bless them as "official",
but if they're popular enough, people will implement them anyway.  Our
strongest possible defense here, IMHO, is keeping the core protocol so
easy to implement that there is always likely to be a wide variety of
clients in popular use.  That way, companion protocols cannot gain
traction unless multiple independent client developers all agree they
are worth supporting.  Anything contentious is doomed to never achieve
more than minority support.  The wider the variety of clients in use,
the harder it is for individual actors to push divisive expansions.

This is really a two-part defense strategy.  There's a technical part,
addressed through the spec itself, which is to make sure that client
implementation remains as easy as possible, but also a cultural part.
The cultural part is to cherish diversity and encourage a DIY ethic.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Dec 20 13:11:05 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 20 Dec 2020 14:11:05 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220101223.GB5303@sources.org>
Message-ID: <C7XMZB2B991I.1YD3P001149FS@stilgar>

On Sun Dec 20, 2020 at 11:12 AM CET, Stephane Bortzmeyer wrote:

> The way, I understand it, Gemini's governance is basically "Solderpunk
> decides". This has good properties (it allows to keep the spec
> consistent, and it avoids the committee effect) and bad ones, too
> (when Solderpunk is busy with his relocation). But I agree that there
> is no obvious alternative.

This is, indeed, pretty much the model.  I admit it is in many ways far
from ideal (although so-called "benevolent dictatorship" has a long and
not unsuccessful history in the FOSS world), although it's far from
clear to me what else can work well with a project that's supposed to be
small and simple with a clear, finite scope.

This model is clearly not sustainable in the long term (I might get hit
by a bus tomorrow), but I think this is okay because I don't view this
as a long term project.  This is a "Perfection is achieved, not when
there is nothing more to add, but when there is nothing left to take
away" kind of project.  I have no interest in regularly adding new
features or upgrading parts of stack.  So, there's no need for stable
long-term governance because at some point, and hopefully not too far
from now, things will be "done".

More on that point shortly...

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Dec 20 14:59:53 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 20 Dec 2020 15:59:53 +0100
Subject: Introducing list "topics"
In-Reply-To: <X99lLDzQAR2PIOg4@kurosawa.casa.net>
Message-ID: <C7XPALZTVTIN.3ABOUEUCDYKYZ@stilgar>

On Sun Dec 20, 2020 at 3:52 PM CET, cage wrote:

> I wonder if could be a good idea to send this email (or a summary of
> it) with stable frequency on the mailing list so that newcomers can
> understand how topics works and which ones are valid here.

Probably not a bad idea, and I should also link to this post from the
Gemini homepage right after linking to the mailing list...

Cheers,
Solderpunk


From petite.abeille at gmail.com  Sun Dec 20 15:39:54 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 20 Dec 2020 16:39:54 +0100
Subject: [tech] the duplo protocol
In-Reply-To: <82v9cwdh4d.fsf@nassur.net>
References: <2CBDC95B-4A11-406E-9787-F3952763058C@gmail.com>
 <20201220060129.GQ9267@brevard.conman.org>
 <2BC58147-56F8-4BB4-AB06-DBC94F953025@gmail.com> <82v9cwdh4d.fsf@nassur.net>
Message-ID: <9255FC1D-95C0-483C-A817-68624B24B691@gmail.com>



> On Dec 20, 2020, at 09:19, ew.gemini <ew.gemini at nassur.net> wrote:
> 
> Would you (or anyone else or several?) be able to /start/ writing
> it down in a form that would make Daniel Stenberg smile?

Actually, this has prompted Daniel to somewhat formalize what to expect from new protocols wishing to be included in curl:

https://curl.se/mail/lib-2020-11/0088.html
https://github.com/curl/curl/pull/6263





From cage-dev at twistfold.it  Sun Dec 20 16:17:42 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 20 Dec 2020 17:17:42 +0100
Subject: Introducing list "topics"
In-Reply-To: <C7XPALZTVTIN.3ABOUEUCDYKYZ@stilgar>
References: <X99lLDzQAR2PIOg4@kurosawa.casa.net>
 <C7XPALZTVTIN.3ABOUEUCDYKYZ@stilgar>
Message-ID: <X995JhWapTS6SQl0@kurosawa.casa.net>

On Sun, Dec 20, 2020 at 03:59:53PM +0100, Solderpunk wrote:

[...]

> I should also link to this post from the
> Gemini homepage right after linking to the mailing list...

Good idea! :)

Bye!
C.

From stephane at sources.org  Sun Dec 20 18:00:19 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Sun, 20 Dec 2020 19:00:19 +0100
Subject: [Users] Bug in the gemtext documentation?
Message-ID: <20201220180019.GA20070@sources.org>

<gemini://gemini.circumlunar.space/docs/gemtext.gmi> says:

=>https://example.com A cool website

But the specification <gemini://gemini.circumlunar.space/docs/specification.gmi> says:

=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]
...
* <whitespace> is any non-zero number of consecutive spaces or tabs

So, this link is illegal, no?

From lazar.michael22 at gmail.com  Sun Dec 20 18:28:00 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Sun, 20 Dec 2020 13:28:00 -0500
Subject: [Users] Bug in the gemtext documentation?
In-Reply-To: <20201220180019.GA20070@sources.org>
References: <20201220180019.GA20070@sources.org>
Message-ID: <CAFTy05ZqTtqczNTK3aZ=DMuVVdbappBQW-0vkcYnBDzg93thAA@mail.gmail.com>

On Sun, Dec 20, 2020 at 1:03 PM Stephane Bortzmeyer
<stephane at sources.org> wrote:
>
> <gemini://gemini.circumlunar.space/docs/gemtext.gmi> says:
>
> =>https://example.com A cool website
>
> But the specification <gemini://gemini.circumlunar.space/docs/specification.gmi> says:
>
> =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]
> ...
> * <whitespace> is any non-zero number of consecutive spaces or tabs
>
> So, this link is illegal, no?

Immediately below that line in the spec:

"Square brackets indicate that the enclosed content is optional."

So while <whitespace> itself can't be empty, the token can be omitted
which allows for link lines of the form

=><URL>[<whitespace><USER-FRIENDLY LINK NAME>]

- Michael

From come at chilliet.eu  Sun Dec 20 21:15:34 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Sun, 20 Dec 2020 22:15:34 +0100
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
References: <3489664.TY8R3EpOMY@tempete>
 <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
Message-ID: <2049934.y2d09Pv1c3@tempete>

Le dimanche 13 d?cembre 2020, 18:28:38 CET Jansen Price a ?crit :
> I ran into the same problem when trying to add client certificate support
> on my PHP server (https://tildegit.org/sumpygump/orbit)
> 
> I think that `capture_peer_cert` is intended to only work
> with stream_socket_client and not with socket servers. I started looking at
> the source code of PHP to see if I could find the part that handles the TLS
> handshake to find out if there is any way to get access to the cert that
> came along with the connection, but I have not been successful in my search
> yet.

So, I found something, it does work if you set verify_peer to true in the ssl context options.

The problem is that if you do so, a request without a client certificate will fail, even before you can know what is the request.

I?m not sure if you can change the context once a connection is accepted, if yes maybe you can attempt stream_socket_enable_crypto once with verify_peer and if it fails run it again without it, but it feels non-optimized.

This is related to the openssl behavior of https://www.openssl.org/docs/man1.1.1/man3/SSL_get_peer_certificate.html
It says: "Due to the protocol definition, a TLS/SSL server will always send a certificate, if present. A client will only send a certificate when explicitly requested to do so by the server (see SSL_CTX_set_verify(3))."

According to https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_verify.html , a client certificate request is sent by the server only if SSL_VERIFY_PEER is set, which php will only set if verify_peer is true.

However, even if I was implementing this in C it is not clear to me how to request a client certificate without making it mandatory, is that what SSL_VERIFY_CLIENT_ONCE is for?
Are there Gemini servers in C with client certificate support of which I could read the code out there?

C?me



From sean at conman.org  Sun Dec 20 22:11:50 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 20 Dec 2020 17:11:50 -0500
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <2049934.y2d09Pv1c3@tempete>
References: <3489664.TY8R3EpOMY@tempete>
 <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
 <2049934.y2d09Pv1c3@tempete>
Message-ID: <20201220221150.GT9267@brevard.conman.org>

It was thus said that the Great C?me Chilliet once stated:
> 
> However, even if I was implementing this in C it is not clear to me how to
> request a client certificate without making it mandatory, is that what
> SSL_VERIFY_CLIENT_ONCE is for? Are there Gemini servers in C with client
> certificate support of which I could read the code out there?

  You might want to check out the source code to LibreSSL (a fork of
OpenSSL).  It comes with a TLS wrapper in the form of libtls (in the tls/
directory), which has the function tlsconf_verify_client_optional().  You
might be able to follow the logic of that function (vs.
tlsconf_verify_client()) to see how it works.

  -spc

From cowan at ccil.org  Mon Dec 21 01:48:14 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 20 Dec 2020 20:48:14 -0500
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <C7XO0RQ3BUJF.QXXWD9KAZLTF@stilgar>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <C7XO0RQ3BUJF.QXXWD9KAZLTF@stilgar>
Message-ID: <CAD2gp_Q+LtXBVSEb6yU5o9xS9WzyvNDikEYynT8APy5f2PDh-g@mail.gmail.com>

On Sun, Dec 20, 2020 at 9:58 AM Solderpunk <solderpunk at posteo.net> wrote:

Things don't need to be 100% perfect to be useful.  I think it's
> arrogant to *aim* for perfection.


Author:  "I know there are some mistakes in my book; after all, it is 777
pages long!"

Editor: "If you know there are mistakes, why don't you _fix_ them?"

I know it's very much going against
> the grain to declare than any kind of software project is "done"; I know
> that people nowadays explicitly avoid using or recommending software for
> the sole reason that it is no longer being actively developed.
>

"Some software is abandoned; other software is merely finished."  --me

(If you don't care about companion protocols and Dioscuri, skip the rest.)


> Our strongest possible defense here, IMHO, is keeping the core protocol so

easy to implement that there is always likely to be a wide variety of
> clients in popular use.  That way, companion protocols cannot gain
> traction unless multiple independent client developers all agree they
> are worth supporting.


As someone whose proposed extension protocol has probably made the most
noise, I would point out that Dioscuri clients and servers will typically
*not* be Gemini clients and servers, as they don't share the same use cases
at all.  Dioscuri native applications and front-end engines are not
browsers, and Dioscuri servers are more like Tomcat than like Apache.

To hold down on the number of posts, I'll just mention that the spec for
Dioscuri is now at <
https://gist.github.com/johnwcowan/d3211496ad89125c77297c6586ebe176>.  I
will probably edit it further, especially if there are changes in the
Gemini spec that also make sense for Dioscuri.  The TL;dr version of the
protocol is that the client sends a media type along with the URL; and
follows it with an appropriate body; otherwise it is the same as Gemini.

I want to specially acknowledge Sandra Snan, who said that Dioscuri needed
a server-served, client-executed programming language to make a front-end
engine programmable.  I agree, and I'm now working on just such a
language.  My sources so far are ABC (the ancestor of Python), PROMAL (a
programming language for Apple II and Commodore systems), Perl 1.0,
Microsoft Small Basic, and the libplot library, plus the ability to execute
REST requests at least via Gemini and Dioscuri.  It will have much the same
goals as Gemini (see the FAQ) insofar as they are applicable to language
design, and will be aimed at beginning and perpetual-intermediate
programmers without being too excruciating for advanced programmers.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Her he asked if O'Hare Doctor tidings sent from far coast and she with
grameful sigh him answered that O'Hare Doctor in heaven was.  Sad was the
man that word to hear that him so heavied in bowels ruthful.  All she
there told him, ruing death for friend so young, algate sore unwilling
God's rightwiseness to withsay.   Joyce, Ulysses, "Oxen of the Sun"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201220/9718ffe3/attachment-0001.htm>

From cowan at ccil.org  Mon Dec 21 02:28:02 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 20 Dec 2020 21:28:02 -0500
Subject: [ANN] a tiny Gemini server written in Ruby
In-Reply-To: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>
References: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>
Message-ID: <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>

On Sun, Dec 20, 2020 at 8:35 AM starlit <chasmaticvoid at gmail.com> wrote:


> hello all, starlit here with a humble announcement about a Gemini server
> written in ruby. i have no experience with mailing lists so please bear
> with me.
>

Alas, it is not free/libre or Open Source, due to the restrictive license.

> it started as a ruby port of Satellite,


Unless you no longer have any code left that is a direct translation of
Satellite, you have written a derivative work, but aren't in compliance
with Satellite's AGPL license, which requires derivative works to be
licensed under the AGPL.

You have a few choices: continue to rewrite until no code translated from
Satellite remains, or relicense under the AGPL, or ask Satellite's author
for a waiver.  I hope you choose the second option, personally, as I would
like to use it as the core server of one of my projects, but I just can't
use it under your license.

Note: I am not a lawyer, and this is not legal advice, but it is not the
unauthorized practice of law either.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Work hard / play hard,                                      cowan at ccil.org
die young / rot quickly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201220/17548eea/attachment.htm>

From lists at gph.dk  Mon Dec 21 06:06:28 2020
From: lists at gph.dk (=?UTF-8?Q?K=C3=A9vin?=)
Date: Mon, 21 Dec 2020 07:06:28 +0100 (CET)
Subject: [Tech] Outages discussion (Was: Introducing list "topics"
In-Reply-To: <X99YncWfv6Uslmcw@goldfish.localdomain>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
 <20201220101706.GA6094@sources.org> <X99YncWfv6Uslmcw@goldfish.localdomain>
Message-ID: <MP2to1i--3-2@gph.dk>

20 d?c. 2020 ? 14:58 de natpen at natpen.net:

> On Sun, Dec 20, 2020 at 11:17:06AM +0100, Stephane Bortzmeyer wrote:
>
>> For instance, gus.guru is down
>>
>
> Yikes! GUS lives again. Thank you for the heads up.
>
Have a look at?http://updown.io/?with the free welcome credit and setting checks hourly, you can get a good few years of monitoring + notifications for free without too much leg work

From benulo at systemli.org  Mon Dec 21 07:30:26 2020
From: benulo at systemli.org (Ben)
Date: Mon, 21 Dec 2020 11:00:26 +0330
Subject: [ANN] a tiny Gemini server written in Ruby
In-Reply-To: <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>
References: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>
 <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>
Message-ID: <48f1e0c9-92b9-9eae-895d-2e13a1c56516@systemli.org>

On 12/21/20 5:58 AM, John Cowan wrote:
> Alas, it is not free/libre or Open Source, due to the restrictive license.

I'm not sure if you are just confused about what AGPL is or if you are 
intentionally making deceptive and misleading statements. It is very 
clear that Satellite is FOSS under AGPL, which is a free and open source 
license. There's no problem for this Ruby server to be based on Satellite.

Ben

-- 
gemini://kwiecien.us/

From stephane at sources.org  Mon Dec 21 08:16:28 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 21 Dec 2020 09:16:28 +0100
Subject: [Tech] Outages discussion (Was: Introducing list "topics"
In-Reply-To: <MP2to1i--3-2@gph.dk>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
 <20201220101706.GA6094@sources.org>
 <X99YncWfv6Uslmcw@goldfish.localdomain> <MP2to1i--3-2@gph.dk>
Message-ID: <20201221081628.GA5206@sources.org>

On Mon, Dec 21, 2020 at 07:06:28AM +0100,
 K?vin <lists at gph.dk> wrote 
 a message of 12 lines which said:

> Have a look at?http://updown.io/?

Besides the fact that it is a cloud-based (cloud = someone else's
computer) solution, it seems from their documentation that it works
only with HTTP. Did anyone try it with Gemini?

From lists at gph.dk  Mon Dec 21 08:21:33 2020
From: lists at gph.dk (=?UTF-8?Q?K=C3=A9vin?=)
Date: Mon, 21 Dec 2020 09:21:33 +0100 (CET)
Subject: [Tech] Outages discussion (Was: Introducing list "topics"
In-Reply-To: <20201221081628.GA5206@sources.org>
References: <C7WUOQK1QYER.RR6URGOE9EK8@stilgar>
 <20201220101706.GA6094@sources.org> <X99YncWfv6Uslmcw@goldfish.localdomain>
 <MP2to1i--3-2@gph.dk> <20201221081628.GA5206@sources.org>
Message-ID: <MP3Np6U--B-2@gph.dk>

21 d?c. 2020 ? 09:16 de stephane at sources.org:

> On Mon, Dec 21, 2020 at 07:06:28AM +0100,
> K?vin <lists at gph.dk> wrote 
> a message of 12 lines which said:
>
>> Have a look at?http://updown.io/?
>>
>
> Besides the fact that it is a cloud-based (cloud = someone else's
> computer) solution, it seems from their documentation that it works
> only with HTTP. Did anyone try it with Gemini?
>
I've not yet tried it with Gemini, but I do have it checking my Gopher server?https://updown.io/kvci?so it's not totally limited to HTTP/S (granted I do have a Gemini check but I have used it via HTTPS to check Kineto when I used to use that in full production for Geminin <=> HTTP/S -?https://updown.io/sfpa)

-K?vin

From op at omarpolo.com  Mon Dec 21 08:21:55 2020
From: op at omarpolo.com (Omar Polo)
Date: Mon, 21 Dec 2020 09:21:55 +0100
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <2049934.y2d09Pv1c3@tempete>
References: <3489664.TY8R3EpOMY@tempete>
 <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
 <2049934.y2d09Pv1c3@tempete>
Message-ID: <871rfjd0ws.fsf@omarpolo.com>


C?me Chilliet <come at chilliet.eu> writes:
> [snip]
> However, even if I was implementing this in C it is not clear to me how to request a client certificate without making it mandatory, is that what SSL_VERIFY_CLIENT_ONCE is for?
> Are there Gemini servers in C with client certificate support of which I could read the code out there?
>
> C?me

I've written my server[0] using LibreSSL (a fork of OpenSSL) and it
supports client certs.  The code is quite short (a bit more than 1k
lines) but the key points for your question are these two lines[1]:

	/* optionally accept client certs, but don't try to verify them */
	tls_config_verify_client_optional(conf);
	tls_config_insecure_noverifycert(conf);

you need to enable optionally the client certs and the tell the library
to not verify the certs.

I don't know how to help you in PHP, but I hope this can help a bit :)

[0]: https://github.com/omar-polo/gmid
[1]: https://github.com/omar-polo/gmid/blob/master/gmid.c#L1076-L1078

From stephane at sources.org  Mon Dec 21 08:25:27 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Mon, 21 Dec 2020 09:25:27 +0100
Subject: [Users] Bug in the gemtext documentation?
In-Reply-To: <CAFTy05ZqTtqczNTK3aZ=DMuVVdbappBQW-0vkcYnBDzg93thAA@mail.gmail.com>
References: <20201220180019.GA20070@sources.org>
 <CAFTy05ZqTtqczNTK3aZ=DMuVVdbappBQW-0vkcYnBDzg93thAA@mail.gmail.com>
Message-ID: <20201221082527.GA5559@sources.org>

On Sun, Dec 20, 2020 at 01:28:00PM -0500,
 Michael Lazar <lazar.michael22 at gmail.com> wrote 
 a message of 25 lines which said:

> Immediately below that line in the spec:
> 
> "Square brackets indicate that the enclosed content is optional."

You're right, I've read the spec too quickly. Thanks.

Why not using a BNF like ABNF (RFC 5234) in the spec, so we have a
formal grammar?

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc5234.txt


From op at omarpolo.com  Mon Dec 21 08:29:51 2020
From: op at omarpolo.com (Omar Polo)
Date: Mon, 21 Dec 2020 09:29:51 +0100
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <871rfjd0ws.fsf@omarpolo.com>
References: <3489664.TY8R3EpOMY@tempete>
 <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
 <2049934.y2d09Pv1c3@tempete> <871rfjd0ws.fsf@omarpolo.com>
Message-ID: <87y2hrblz4.fsf@omarpolo.com>


Omar Polo <op at omarpolo.com> writes:

> C?me Chilliet <come at chilliet.eu> writes:
>> [snip]
>> However, even if I was implementing this in C it is not clear to me how to request a client certificate without making it mandatory, is that what SSL_VERIFY_CLIENT_ONCE is for?
>> Are there Gemini servers in C with client certificate support of which I could read the code out there?
>>
>> C?me
>
> I've written my server[0] using LibreSSL (a fork of OpenSSL) and it
> supports client certs.  The code is quite short (a bit more than 1k
> lines) but the key points for your question are these two lines[1]:
>
> 	/* optionally accept client certs, but don't try to verify them */
> 	tls_config_verify_client_optional(conf);
> 	tls_config_insecure_noverifycert(conf);
>
> you need to enable optionally the client certs and the tell the library
> to not verify the certs.
>
> I don't know how to help you in PHP, but I hope this can help a bit :)
>
> [0]: https://github.com/omar-polo/gmid
> [1]: https://github.com/omar-polo/gmid/blob/master/gmid.c#L1076-L1078

I forgot to address a point

> I?m not sure if you can change the context once a connection is accepted, if yes maybe you can attempt stream_socket_enable_crypto once with verify_peer and if it fails run it again without it, but it feels non-optimized.

I don't think you can do this.  Once a connection is established, the
certificates have already been checked, so you need to act before.

and I also forgot to mention that I'm not using directly the libressl
api, but I'm using instead libtls (a wrapper with nicer APIs)

From sean at conman.org  Mon Dec 21 08:45:40 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 21 Dec 2020 03:45:40 -0500
Subject: [ANN] a tiny Gemini server written in Ruby
In-Reply-To: <48f1e0c9-92b9-9eae-895d-2e13a1c56516@systemli.org>
References: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>
 <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>
 <48f1e0c9-92b9-9eae-895d-2e13a1c56516@systemli.org>
Message-ID: <20201221084540.GW9267@brevard.conman.org>

It was thus said that the Great Ben once stated:
> On 12/21/20 5:58 AM, John Cowan wrote:
> >Alas, it is not free/libre or Open Source, due to the restrictive license.
> 
> I'm not sure if you are just confused about what AGPL is or if you are 
> intentionally making deceptive and misleading statements. It is very 
> clear that Satellite is FOSS under AGPL, which is a free and open source 
> license. There's no problem for this Ruby server to be based on Satellite.

  John isn't talking about satellite, but about starlit, which has the
"Anti-Capitalist Software License."

  -spc


From benulo at systemli.org  Mon Dec 21 09:22:41 2020
From: benulo at systemli.org (Ben)
Date: Mon, 21 Dec 2020 12:52:41 +0330
Subject: [ANN] a tiny Gemini server written in Ruby
In-Reply-To: <20201221084540.GW9267@brevard.conman.org>
References: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>
 <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>
 <48f1e0c9-92b9-9eae-895d-2e13a1c56516@systemli.org>
 <20201221084540.GW9267@brevard.conman.org>
Message-ID: <9cd2ccee-6fae-bc8c-4498-40096d9c9599@systemli.org>

On 12/21/20 12:15 PM, Sean Conner wrote:
> John isn't talking about satellite, but about starlit, which has the
> "Anti-Capitalist Software License."

You're right, I did misunderstand what he was talking about. I apologize 
for that! At first I thought he was talking about Satellite's licensing, 
saying it should be changed. It didn't cross my mind that the Ruby 
server itself was not licensed under AGPL, since I just assumed it was. 
That's why I didn't understand why he wanted the license to change.

Ben

-- 
gemini://kwiecien.us/

From petite.abeille at gmail.com  Mon Dec 21 09:36:57 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 10:36:57 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <20201220114012.c85368055ae9e081d2833165@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <20201220114012.c85368055ae9e081d2833165@gmail.com>
Message-ID: <30AD59FD-46E3-416D-AC7D-E2953C7E11A5@gmail.com>



> On Dec 20, 2020, at 11:40, Philip Linde <linde.philip at gmail.com> wrote:
> 
> Agreed. "Non-extensibility of the protocol was a major design principle
> for Gemini." (Gemini FAQ)

True. And mostly achieved when viewed through a narrow enough lens. Tunnel vision is key.

There are few moving parts to play. So, yes, from a strictly protocolar point of view, it's mostly done: a retrofuturistic goldilocks of sort. Nothing much to add or remove. Would make Saint-Exup?ry proud.

Of course, this says nothing about actual use of the protocol. Which can be combined in all sort of weird and wonderful ways to fully subvert such grand "design principle" if needed.

Perhaps the only cognitive dissonance is the idealistic narrative around the protocol: trivial to implement and use, non-extensible, one-trick pony. 

Your progressive grandma could whip it up in no time and run it out of her trusty gramophone to share haikus without much ado.

These statements are misleading, naive, or outright wrong. 

The building blocks are chunky and complicate enough on their own to make it complex, both in terms of implementation and actual usage. Not to mention unattended consequences.

The protocol can be trivially extended through conventions.

And there is more to life than publishing samizdat poetry.

A bit of realism would help. That's all. Nothing to lose sleep over. All is good in the grand scheme of things :)

Happy holidays.

Public Work | #EFF2020: A Holiday Campaign (Uncensored)
https://www.youtube.com/watch?v=SWYnVepM8VM









 




From come at chilliet.eu  Mon Dec 21 09:42:31 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me_Chilliet?=)
Date: Mon, 21 Dec 2020 10:42:31 +0100
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <871rfjd0ws.fsf@omarpolo.com>
References: <3489664.TY8R3EpOMY@tempete>
 <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
 <2049934.y2d09Pv1c3@tempete> <871rfjd0ws.fsf@omarpolo.com>
Message-ID: <5CDC9D0B-5A0F-4F74-BC10-F72866F902FD@chilliet.eu>

From what I've seen in libtls source, it sets a custom certificate checking callback function to be able to bypass certificate check while still asking for it when you use these insecure_ family of functions.

Current PHP cannot do that. Not sure what would be the best API for this feature if it was added. Most likely a new context option for ssl which says the client cert is optional. I guess to be complete it would allow disabling client cert validation all together, or only when client cert is absent.
An other solution is to allow PHP code to set its own callback, but it seems to be dangerous and hard to use.

From petite.abeille at gmail.com  Mon Dec 21 10:16:16 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 11:16:16 +0100
Subject: [Users] Bug in the gemtext documentation?
In-Reply-To: <20201221082527.GA5559@sources.org>
References: <20201220180019.GA20070@sources.org>
 <CAFTy05ZqTtqczNTK3aZ=DMuVVdbappBQW-0vkcYnBDzg93thAA@mail.gmail.com>
 <20201221082527.GA5559@sources.org>
Message-ID: <43F072EE-2C38-4B11-996C-102E4D8B58A4@gmail.com>



> On Dec 21, 2020, at 09:25, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Why not using a BNF like ABNF (RFC 5234) in the spec, so we have a
> formal grammar?

Hopefully this is the kind of formalization the protocol can go through once fully finalized and ready for publication.

Due diligence & all.

From crayon to typewriter.


From me at rwv.io  Mon Dec 21 10:35:36 2020
From: me at rwv.io (Remco)
Date: Mon, 21 Dec 2020 11:35:36 +0100
Subject: Supporting TLS client certificate in PHP?
In-Reply-To: <5CDC9D0B-5A0F-4F74-BC10-F72866F902FD@chilliet.eu>
References: <3489664.TY8R3EpOMY@tempete>
 <CAJyFNOzDH2iCsiWs0t5icnXLN-xnH19a8FGoasH5oSSne_mHHQ@mail.gmail.com>
 <2049934.y2d09Pv1c3@tempete> <871rfjd0ws.fsf@omarpolo.com>
 <5CDC9D0B-5A0F-4F74-BC10-F72866F902FD@chilliet.eu>
Message-ID: <877dpb30qv.fsf@rwv.io>

2020/12/21 10:42, C?me Chilliet:

> Current PHP cannot do that. Not sure what would be the best API for
> this feature if it was added. Most likely a new context option for ssl
> which says the client cert is optional. I guess to be complete it
> would allow disabling client cert validation all together, or only
> when client cert is absent.
>
> An other solution is to allow PHP code to set its own callback, but it
> seems to be dangerous and hard to use.

I feel your pain, client certs seem to be not very widely used so a lot
for platforms don't support them out of the box.  For d??m?ni, I
have/had a similar problem with racket, its standard ssl implementation
does not handle client certificates at all, so I ended up breaking it
open and allowing SSL_CTX_set_verify to be set with SSL_VERIFY_PEER.

Access to the actual client certificate from the connection context
turned out a lot harder in openssl racket setup, so, yes, I went with
dangerous and hard (passing certificate info through a thread local).  I
already had fiddle with thread locals to do SNI (another thing
apparently not very popular in racket) so I kinda got used to that..

For details see:

  https://git.sr.ht/~rwv/dezhemini/tree/client-cert/item/openssl-extra.rkt

and search for verify-callback in:

  https://git.sr.ht/~rwv/dezhemini/tree/client-cert/item/dezhmnsrv.rkt

Cheers,
R.

From chasmaticvoid at gmail.com  Mon Dec 21 11:08:52 2020
From: chasmaticvoid at gmail.com (starlit)
Date: Mon, 21 Dec 2020 13:08:52 +0200
Subject: [ANN] a tiny Gemini server written in Ruby
In-Reply-To: <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>
References: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>
 <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>
Message-ID: <06488db8-f4f8-ca20-ce38-eab79612f8a8@gmail.com>


On 21/12/2020 4:28, John Cowan wrote:
> Unless you no longer have any code left that is a direct translation 
> of Satellite, you have written a derivative work, but aren't in 
> compliance with Satellite's AGPL license, which requires derivative 
> works to be licensed under the AGPL.

thank you for your concern. i have updated the license to AGPL.

-starlit


From petite.abeille at gmail.com  Mon Dec 21 11:21:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 12:21:28 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220101223.GB5303@sources.org>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <20201220101223.GB5303@sources.org>
Message-ID: <0DF97AC4-A02F-40B2-93E3-F2BB3D0C642F@gmail.com>



> On Dec 20, 2020, at 11:12, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
>> the 100% inclusive approach of creating a dedicated RFC listing.
> 
> This approach seems reasonable. This is what the christian church did,
> after all, write a canon, a list of approved texts
> <https://en.wikipedia.org/wiki/Biblical_canon>.

Dogmatism aside, this sounds like a great, pragmatic,  way to organize the inevitable.

Cat Herders
https://www.youtube.com/watch?v=m_MaJDK3VNE

From petite.abeille at gmail.com  Mon Dec 21 12:49:21 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 13:49:21 +0100
Subject: [tech] dumb vs. dumber
Message-ID: <A4BAA5F3-5524-46E1-B11D-DCD88D69958F@gmail.com>

Meanwhile, on IRC:

[2020-12-21T11:12:29.422Z] <login> The one thing gemini should not do is allow the client to be 'smart', i.e., javascript 

Not allowed! But technically possible today.

Any text/gemini document can embed any number of attachments, curtesy of the data URI scheme:

https://en.wikipedia.org/wiki/Data_URI_scheme

It would take a trivial amount of work for a client to start acting on, say, text/javascript (or, more likely, something akin to text/css to start with). Or some cute image/gif. 

The horror.

Of course, Solderpunk could ban such heresies by pontifical decree. Alongside the evil authority's userinfo. And segments. And... whatever else doesn't toe the political line.

Such edicts will most likely have the same net  effect as the Pope's unwelcome intrusion into other people's bedroom.

Have faith.


N.B.  Previously on Gemini: 

The Problems of Transclusion (was Re: More silly text/gemini spec proposals)
https://lists.orbitalfox.eu/archives/gemini/2020/001195.html





From petite.abeille at gmail.com  Mon Dec 21 13:14:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 14:14:37 +0100
Subject: [tech] omnichannel discussions
Message-ID: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>

[2020-12-21T13:06:11.301Z] <bie> petite abeille still monitoring the irc channel to post hot (really, lukewarm) takes to the mailing list 
[2020-12-21T13:09:01.260Z] <bie> i know that this channel is being logged, buuuut... it's just straight up rude imo

Why rude? 

The IRC channel contains, at time, interesting content. Ditto for the mailing list. Or vis-versa.

This is all about Gemini. All the channels are public. Gemlogs. Web pages. What not.

Why the segregation? Why rude? Care to elaborate?


From petite.abeille at gmail.com  Mon Dec 21 13:28:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 14:28:37 +0100
Subject: [tech] omnichannel discussions
In-Reply-To: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
Message-ID: <64DF1DF3-5A7D-44F3-AEAD-1F7FF6AB337F@gmail.com>



> On Dec 21, 2020, at 14:14, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> [2020-12-21T13:06:11.301Z] <bie> petite abeille still monitoring the irc channel to post hot (really, lukewarm) takes to the mailing list 
> [2020-12-21T13:09:01.260Z] <bie> i know that this channel is being logged, buuuut... it's just straight up rude imo
> 
> Why rude? 
> 
> The IRC channel contains, at time, interesting content. Ditto for the mailing list. Or vis-versa.
> 
> This is all about Gemini. All the channels are public. Gemlogs. Web pages. What not.
> 
> Why the segregation? Why rude? Care to elaborate?

[2020-12-21T13:09:01.260Z] <bie> i know that this channel is being logged, buuuut... it's just straight up rude imo
[2020-12-21T13:10:10.876Z] <bie> aaaand maybe me complaining about it here is rude in the same way, so i'll leave it at that and let it go ;)
[2020-12-21T13:15:22.564Z] <bie> ...
[2020-12-21T13:15:31.380Z] <nihilazo> ....
[2020-12-21T13:17:04.682Z] <benk> ......
[2020-12-21T13:17:26.681Z] <nihilazo> ..........
[2020-12-21T13:18:04.593Z] <bie> petite abeille: since you wanted me to elaborate, i posted something in another public place - good luck finding it <3

Ohhh... a treasure hunt. Delightful. :D

Additionally:

[2020-12-21T13:19:37.064Z] <CommunistWolf> sometimes people just don't have an understanding of social niceties
[2020-12-21T13:19:43.214Z] <CommunistWolf> such is life

Enlighten us.

All these channels are public & related to gemini. Furthermore, the IRC channel seems to have a lot of opinion about the ML. Nothing wrong with that either.

Why no cross-pollination? Why the segregation? What unspeakable social faux-pas has been committed be quoting one channel in another one?










From bjorn.warmedal at gmail.com  Mon Dec 21 13:36:50 2020
From: bjorn.warmedal at gmail.com (=?UTF-8?B?QmrDtnJuIFfDpHJtZWRhbA==?=)
Date: Mon, 21 Dec 2020 14:36:50 +0100
Subject: [tech] dumb vs. dumber
In-Reply-To: <A4BAA5F3-5524-46E1-B11D-DCD88D69958F@gmail.com>
References: <A4BAA5F3-5524-46E1-B11D-DCD88D69958F@gmail.com>
Message-ID: <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>

> Of course, Solderpunk could ban such heresies by pontifical decree. Alongside the evil authority's userinfo. And segments. And... whatever else doesn't toe the political line.
>
> Such edicts will most likely have the same net  effect as the Pope's unwelcome intrusion into other people's bedroom.

This is becoming ridiculous. The front and foremost reason that gemini
is unlikely to be extended over time is that *almost all features
proposed are actually already in HTTP*, and that protocol has been
around for a very long time and does these things way more efficiently
than can be adapted to gemini.

You can wish all you want that gemini should be extended, and believe
all you want that it will be over time, but the fact is that gemini
itself is basically one step up from gopher (which hasn't been
extended for decades, and only extended very slightly after its
inception). Yes, gemini *will* change. Things like TLS will evolve,
and internationalization may require changes over time too. But most
feature requests fall on the same technical arguments.

* Gemini will not get a PUT/POST feature, because there isn't a
reasonable way to fit it in. Instead you'll see lots of competing
"companion protocols" that do this, and I honestly don't believe that
any of them will gain great enough traction that more than one browser
will pick any up. HTTP does this better, after all, and you can always
build specialized tools for your particular platform too.
* Gemtext will not get feature X, because it's actually just a
somewhat souped-up text/plain. If you want more out of it there are
already formats that support that a lot better -- markdown, html, pdf,
odt to name a few. Solderpunk mentioned (a long time ago now?) that he
was pondering an even simpler format that would just be plain text
lines and link lines. That point is moot now, because gemtext is so
easily parsed and brings so much more readability at such a low cost
that I think people would just write gemtext anyway.
* Gemini will not inline things or transclude things, because gemini
transactions are expensive in that regard. We don't reuse connections,
and that's a *big* thing about the philosophy and simplicity of
implementations. I get that some people will want to add this, but why
fight that uphill battle when HTTP already has it and does it better?

A lot of other feature requests will rightly fall on the same logic --
why re-implement something that HTTP already does better?

There are features I, too, would *love* to see in gemini. But they
fall on the same criteria. Gemini isn't meant to be a reinvention of
the wheel, just a nicer pair of hiking boots.

Cheers,
ew0k

From petite.abeille at gmail.com  Mon Dec 21 13:50:42 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 14:50:42 +0100
Subject: [tech] dumb vs. dumber
In-Reply-To: <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>
References: <A4BAA5F3-5524-46E1-B11D-DCD88D69958F@gmail.com>
 <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>
Message-ID: <4F08D07A-4D82-4F31-8533-A6E5CD07A23E@gmail.com>



> On Dec 21, 2020, at 14:36, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
> You can wish all you want that gemini should be extended

Apologies. Perhaps it was not clear: Gemini can be extended in its current shape. That bridge was crossed long ago by introducing full-fledged URIs into the protocol. 

If people are going to actually use such esoteric capabilities has to be seen. Or not. But it could be done, technically speaking.

It's crystal clear the commune is not interested leveraging such capabilities at this conjuncture. Fair enough. But this doesn't make them go away.







From bjorn.warmedal at gmail.com  Mon Dec 21 14:09:15 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Mon, 21 Dec 2020 15:09:15 +0100
Subject: [tech] dumb vs. dumber
In-Reply-To: <4F08D07A-4D82-4F31-8533-A6E5CD07A23E@gmail.com>
References: <4F08D07A-4D82-4F31-8533-A6E5CD07A23E@gmail.com>
Message-ID: <09BD95E0-FA4E-4C3F-9A3F-AEE147D98D24@gmail.com>


> Apologies. Perhaps it was not clear: Gemini can be extended in its current shape. That bridge was crossed long ago by introducing full-fledged URIs into the protocol. 

I?m not well enough versed in the capabilities of URIs to know what this means. Can you give an example?

Cheers,
ew0k

Sent from my Lego Mindstorms set

From petite.abeille at gmail.com  Mon Dec 21 14:12:34 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 15:12:34 +0100
Subject: [tech] dumb vs. dumber
In-Reply-To: <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>
References: <A4BAA5F3-5524-46E1-B11D-DCD88D69958F@gmail.com>
 <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>
Message-ID: <9B18F89A-FE09-4DC6-9502-9FFC3EDA5DC6@gmail.com>



> On Dec 21, 2020, at 14:36, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
> * Gemini will not inline things or transclude things, because gemini
> transactions are expensive in that regard. We don't reuse connections,
> and that's a *big* thing about the philosophy and simplicity of
> implementations.

As this is meant to be a [tech] topic, I have to point out that data: URIs are fully embedded in the text/gemini document itself. Not further network connection is required (assuming self-contained resources).

To illustrate the point, a popular Gemini custom requires an additional network connection to retrieve a favicon.txt  document containing one UTF8 character for decorative purpose*. Fantastic.

An alternative approach would embed such decorative emoji in a data: URI link:

=> data:text/plain;charset=utf-8;base64,8J+QsA== favicon.txt
=> data:text/plain;charset=utf-8,%F0%9F%90%B0 favicon.txt

Monstrous, I know. Oh well.

[1] https://gemini.rootkey.co.uk/x/mozz.us/files/rfc_gemini_favicon.gmi


From benulo at systemli.org  Mon Dec 21 14:37:08 2020
From: benulo at systemli.org (Ben)
Date: Mon, 21 Dec 2020 18:07:08 +0330
Subject: [tech] omnichannel discussions
In-Reply-To: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
Message-ID: <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>

On 12/21/20 4:44 PM, Petite Abeille wrote:
> channel is being logged

Since we have the ML for official correspondence, it might make more 
sense not to log the IRC chat. Chat is meant to be transient, as a medium.

-- 
gemini://kwiecien.us/

From bjorn.warmedal at gmail.com  Mon Dec 21 14:47:39 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Mon, 21 Dec 2020 15:47:39 +0100
Subject: [tech] dumb vs. dumber
In-Reply-To: <9B18F89A-FE09-4DC6-9502-9FFC3EDA5DC6@gmail.com>
References: <9B18F89A-FE09-4DC6-9502-9FFC3EDA5DC6@gmail.com>
Message-ID: <96CACCBF-389C-40F4-ACB4-B510532C69CA@gmail.com>


> As this is meant to be a [tech] topic, I have to point out that data: URIs are fully embedded in the text/gemini document itself. Not further network connection is required (assuming self-contained resources).
> 
> To illustrate the point, a popular Gemini custom requires an additional network connection to retrieve a favicon.txt  document containing one UTF8 character for decorative purpose*. Fantastic.

Ugh. Yeah, I?ve seen that. As far as I know only one client supports this (not by default, but by toggling a setting in config). I hope it doesn?t gain traction. Even if it looks nice it seems pretty preposterous to do a full TLS handshake to send a single character at most.

Experiments like this will pop up, but I still think the general gemini community is pretty resilient to it because ? as I mentioned earlier ? another protocol just does this better.

> An alternative approach would embed such decorative emoji in a data: URI link:
> 
> => data:text/plain;charset=utf-8;base64,8J+QsA== favicon.txt
> => data:text/plain;charset=utf-8,%F0%9F%90%B0 favicon.txt

A better approach, but I think you?d have a hard time getting browser implementers to adopt it.

But yeah, experimentation will happen and that?s a good thing. I just believe that almost none of those experiments will lead to de facto changes of the protocol or gemtext. It?s too hard to convince enough implementers to adopt something. Not like the web world, where Chrome *is* the de facto standard.

Cheers,
ew0k

Sent from my Roomba


From petite.abeille at gmail.com  Mon Dec 21 14:48:13 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 15:48:13 +0100
Subject: [tech] omnichannel discussions
In-Reply-To: <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
Message-ID: <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>



> On Dec 21, 2020, at 15:37, Ben <benulo at systemli.org> wrote:
> 
>> channel is being logged
> 
> Since we have the ML for official correspondence, it might make more sense not to log the IRC chat. Chat is meant to be transient, as a medium.

Hmmm... colored me confused... the ML is for "official correspondence"? What are "official correspondence"?!?  It's a random mailing list on the interweb. 

Let's put things in perspective: 

(1) there is a gemini IRC channel hosted by mozz.us, prominently advertised on the main portal page:

https://portal.mozz.us/gemini/mozz.us/

https://portal.mozz.us/gemini/chat.mozz.us/

(2) Furthermore, there is a nice gemini chat log for it, again linked from that same portal page:

https://portal.mozz.us/gemini/makeworld.gq/cgi-bin/gemini-irc

(3) Furthermore, the IRC channel advertises the fact it's public

And yet, somehow, it's morally wrong to even refer to the public gemini conversation happening on the gemini IRC channel?!?

What gives?






From benulo at systemli.org  Mon Dec 21 14:54:44 2020
From: benulo at systemli.org (Ben)
Date: Mon, 21 Dec 2020 18:24:44 +0330
Subject: [tech] omnichannel discussions
In-Reply-To: <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
 <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
Message-ID: <64cb761a-aa77-ccdd-b093-05964d234b43@systemli.org>

On 12/21/20 6:18 PM, Petite Abeille wrote:
> What are "official correspondence"?!?  It's a random mailing list on the interweb.

In my view this means don't send anything to the ML unless it's 
important enough to warrant sincere, thoughtful discussion or merit 
attention by the whole community and be archived for posterity as part 
of the Gemini project.

It's good to keep the ML serious and a little bit restrained. Being able 
to post to it is a privilege we should try not to abuse. Random or 
insignificant stuff can go elsewhere. There's always IRC, or posting it 
to your gemlog.

Ben

-- 
gemini://kwiecien.us/

From petite.abeille at gmail.com  Mon Dec 21 14:55:29 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 15:55:29 +0100
Subject: [tech] dumb vs. dumber
In-Reply-To: <96CACCBF-389C-40F4-ACB4-B510532C69CA@gmail.com>
References: <9B18F89A-FE09-4DC6-9502-9FFC3EDA5DC6@gmail.com>
 <96CACCBF-389C-40F4-ACB4-B510532C69CA@gmail.com>
Message-ID: <3A1E523C-3E7D-45F2-A9C3-9B73741772B5@gmail.com>



> On Dec 21, 2020, at 15:47, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
> But yeah, experimentation will happen and that?s a good thing.

Yes.

> I just believe that almost none of those experiments will lead to de facto changes of the protocol or gemtext.

There is nothing to change. The protocol and document format can be used 'as is'. The capabilities of each is defined by their building blocks. The only limit is your imagination. See Astrobotany* for an illustration.

> It?s too hard to convince enough implementers to adopt something. Not like the web world, where Chrome *is* the de facto standard.

Ironically, I for one, never use Chrome :)

* https://portal.mozz.us/gemini/astrobotany.mozz.us/

From remyabel at tilde.team  Mon Dec 21 15:03:30 2020
From: remyabel at tilde.team (remyabel at tilde.team)
Date: Mon, 21 Dec 2020 15:03:30 +0000
Subject: [tech] omnichannel discussions
In-Reply-To: <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
 <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
Message-ID: <20201221150330.GA1720454@tilde.team>

On Mon, Dec 21, 2020 at 03:48:13PM +0100, Petite Abeille wrote:
> ...snip...
> 
> And yet, somehow, it's morally wrong to even refer to the public gemini conversation happening on the gemini IRC channel?!?
> 
> What gives?
 
The users in the IRC channel don't feel comfortable having their
messages singled out and responded to in a different medium. The
consensus seems to be mailing list discussion should stay on the ML and
IRC discussion should stay in IRC. In either case, if they're not
comfortable with you doing it, it's probably a good idea to stop. It's
considered "rude" because it would be like taking a personal argument
and loudly responding in an airport.

From petite.abeille at gmail.com  Mon Dec 21 15:05:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 16:05:04 +0100
Subject: [tech] omnichannel discussions
In-Reply-To: <64cb761a-aa77-ccdd-b093-05964d234b43@systemli.org>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
 <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
 <64cb761a-aa77-ccdd-b093-05964d234b43@systemli.org>
Message-ID: <2124F124-F3C9-42BF-A18E-7A458A86895B@gmail.com>



> On Dec 21, 2020, at 15:54, Ben <benulo at systemli.org> wrote:
> 
> On 12/21/20 6:18 PM, Petite Abeille wrote:
>> What are "official correspondence"?!?  It's a random mailing list on the interweb.
> 
> In my view this means don't send anything to the ML unless it's important enough to warrant sincere, thoughtful discussion or merit attention by the whole community and be archived for posterity as part of the Gemini project.
> 
> It's good to keep the ML serious and a little bit restrained. Being able to post to it is a privilege we should try not to abuse. Random or insignificant stuff can go elsewhere. There's always IRC, or posting it to your gemlog.

Hmmm... I see... for the record though... since when such chasm has emerged in public communication channels? 

More specifically, since when is gemini at lists.orbitalfox.eu deemed the journal of record of Gemini officialdom? Whatever that is. And is it actually?

Again, I don't specially mind either way. But could someone actually spell it out? Without all the passive aggressive angst.

FWIW, I personally find omnichannel enriching. 

Your house, your rules though.  




From alex at nytpu.com  Mon Dec 21 15:07:58 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Mon, 21 Dec 2020 08:07:58 -0700
Subject: [tech] omnichannel discussions
In-Reply-To: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
Message-ID: <20201221150758.t2egpvqnp5i52b4t@GLaDOS>

I'm not going to say that you can't, or even that you shouldn't, it's
pretty reasonable to quote a relevant irc convo that had good discussion
if you're moving the discussion to the mailing list. I think the main
reason it gets on people's nerves though is that it's generally
considered very rude to publish irc logs, *even if the server is logged
publicly*.

Also, IRC is generally geared toward casual chat, people just shoot the
shit on there and don't expect half the discussions to go anywhere,
whereas on the mailing list it is generally expected that most
discussions are worthwhile in some way. Except for a few times that
#gemini is on-topic (and I promise you, that's rarer than you'd expect),
there's not a whole lot that would be worthwhile to actually discuss
wider on the mailing list.


~nytpu

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201221/ccb52f3d/attachment-0001.sig>

From petite.abeille at gmail.com  Mon Dec 21 15:14:29 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 16:14:29 +0100
Subject: [tech] omnichannel discussions
In-Reply-To: <20201221150330.GA1720454@tilde.team>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
 <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
 <20201221150330.GA1720454@tilde.team>
Message-ID: <67863335-F439-4D2D-AC1A-AB0560B44643@gmail.com>



> On Dec 21, 2020, at 16:03, remyabel at tilde.team wrote:
> 
> The users in the IRC channel don't feel comfortable having their
> messages singled out and responded to in a different medium. The
> consensus seems to be mailing list discussion should stay on the ML and
> IRC discussion should stay in IRC.

Aha. The obscure Ghostbusters reference: "Don't cross the streams. It would be bad."

http://quotegeek.com/quotes-from-movies/ghostbusters/206/

> In either case, if they're not comfortable with you doing it, it's probably a good idea to stop.

Fair enough. A split then. The two shall never cross path ever again.

> It's considered "rude" because it would be like taking a personal argument and loudly responding in an airport.

Hmmm... you lost me here. All these channels are publicly visible. And logged. And recorded. There is no material differences. But, ok.

Irrespectively, thanks for taking the time to spell it out.

Apology for the faux-pas.


From petite.abeille at gmail.com  Mon Dec 21 15:21:52 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 16:21:52 +0100
Subject: [tech] omnichannel discussions
In-Reply-To: <20201221150758.t2egpvqnp5i52b4t@GLaDOS>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <20201221150758.t2egpvqnp5i52b4t@GLaDOS>
Message-ID: <24713AF2-82E4-4E5F-84A1-A7593838EBB7@gmail.com>



> On Dec 21, 2020, at 16:07, Alex // nytpu <alex at nytpu.com> wrote:
> 
> I'm not going to say that you can't, or even that you shouldn't, it's
> pretty reasonable to quote a relevant irc convo that had good discussion
> if you're moving the discussion to the mailing list. I think the main
> reason it gets on people's nerves though is that it's generally
> considered very rude to publish irc logs, *even if the server is logged
> publicly*.
> 
> Also, IRC is generally geared toward casual chat, people just shoot the
> shit on there and don't expect half the discussions to go anywhere,
> whereas on the mailing list it is generally expected that most
> discussions are worthwhile in some way. Except for a few times that
> #gemini is on-topic (and I promise you, that's rarer than you'd expect),
> there's not a whole lot that would be worthwhile to actually discuss
> wider on the mailing list.

Alright. Thanks for taking the time to explain the finer point of the cultural divide. 

I will refrain from quoting "irc logs" verbatim from now on.

Apology for any distress caused.

Thanks again for taking the time.
 



From petite.abeille at gmail.com  Mon Dec 21 15:26:40 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 16:26:40 +0100
Subject: [tech] omnichannel discussions
In-Reply-To: <20201221150758.t2egpvqnp5i52b4t@GLaDOS>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <20201221150758.t2egpvqnp5i52b4t@GLaDOS>
Message-ID: <A2025657-AC72-4739-A55A-A53E8374DA9F@gmail.com>



> On Dec 21, 2020, at 16:07, Alex // nytpu <alex at nytpu.com> wrote:
> 
> whereas on the mailing list it is generally expected that most discussions are worthwhile in some way

This is not meant to be snappy, but... since when are discussions on a mailing list expected to be "worthwhile"?! What does "worthwhile" mean in such context? And worthwhile for whom?

Perhaps this is yet another cultural divide worthwhile spelling out.



From alex at nytpu.com  Mon Dec 21 15:45:53 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Mon, 21 Dec 2020 08:45:53 -0700
Subject: [tech] omnichannel discussions
In-Reply-To: <A2025657-AC72-4739-A55A-A53E8374DA9F@gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <20201221150758.t2egpvqnp5i52b4t@GLaDOS>
 <A2025657-AC72-4739-A55A-A53E8374DA9F@gmail.com>
Message-ID: <20201221154553.ogb3jzmuh5goanqe@GLaDOS>

Instead of ?worthwhile? I should've said ?on-topic,? as in a mailing
list thread is expected to be at least tangentially related to gemini.

At some point mailing lists were decided to be more ?serious,? and a
medium like IRC suited more for initial feedback. This stems from
software projects where they'd be dealing with patches and code review
on the ML and off-topic (or ?low quality,? the criterion for which
depends on the project) discussion was frowned upon. Basically, there
are ?formal? software mailing lists with very rigid culture and
guidelines, and that culture partially wafts over into mailing lists in
general.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201221/f3dfb240/attachment.sig>

From lazar.michael22 at gmail.com  Mon Dec 21 16:36:47 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Mon, 21 Dec 2020 11:36:47 -0500
Subject: [tech] omnichannel discussions
In-Reply-To: <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
 <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
Message-ID: <CAFTy05amz96Yc_x9XF_2Fxjr_j_+uRdHqBL3rV6JmAh=pxrMsw@mail.gmail.com>

On Mon, Dec 21, 2020 at 9:48 AM Petite Abeille <petite.abeille at gmail.com> wrote:
>
> > On Dec 21, 2020, at 15:37, Ben <benulo at systemli.org> wrote:
> >
> >> channel is being logged
> >
> > Since we have the ML for official correspondence, it might make more sense not to log the IRC chat. Chat is meant to be transient, as a medium.
>
> Hmmm... colored me confused... the ML is for "official correspondence"? What are "official correspondence"?!?  It's a random mailing list on the interweb.
>
> Let's put things in perspective:
>
> (1) there is a gemini IRC channel hosted by mozz.us, prominently advertised on the main portal page:
>
> https://portal.mozz.us/gemini/mozz.us/
>
> https://portal.mozz.us/gemini/chat.mozz.us/
>
> (2) Furthermore, there is a nice gemini chat log for it, again linked from that same portal page:
>
> https://portal.mozz.us/gemini/makeworld.gq/cgi-bin/gemini-irc

This is totally incorrect.

gemini://chat.mozz.us is not IRC and has nothing to do with #gemini.
It's a demo for streaming gemini connections that nobody uses.

The #gemini IRC channel that you are referring to is hosted on
https://tilde.chat/. I don't know who owns it and I have no
affiliation with them.

gemini://mozz.us is my personal gemini capsule and is no more special
than any other random site on the internet or gemini.

https://portal.mozz.us/ is a gemini web proxy that I run. I have no
clue what you mean by "main portal page". You are simply linking to my
gemini server via my web proxy.

- Michael (mozz)

From petite.abeille at gmail.com  Mon Dec 21 16:49:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 17:49:43 +0100
Subject: [tech] omnichannel discussions
In-Reply-To: <CAFTy05amz96Yc_x9XF_2Fxjr_j_+uRdHqBL3rV6JmAh=pxrMsw@mail.gmail.com>
References: <EBC74B3F-5581-433C-A315-ABE6F8E4A258@gmail.com>
 <8fe451c0-f192-3321-68a6-d9818ca1795a@systemli.org>
 <59E02881-A8E9-42C5-B1A2-C0A3694767DD@gmail.com>
 <CAFTy05amz96Yc_x9XF_2Fxjr_j_+uRdHqBL3rV6JmAh=pxrMsw@mail.gmail.com>
Message-ID: <DC8566A6-52D9-460A-AC92-FE607B3AB8A7@gmail.com>



> On Dec 21, 2020, at 17:36, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> https://portal.mozz.us/ is a gemini web proxy that I run. I have no
> clue what you mean by "main portal page". You are simply linking to my
> gemini server via my web proxy.

D'oh. Apologies. You are totally correct. Too many layers of indirections blending into each other. Eyes hurt.

To recap:

gemini://mozz.us/ 
aka https://portal.mozz.us/gemini/mozz.us/ 

lists the Gemini IRC Logs at gemini://makeworld.gq/cgi-bin/gemini-irc
aka https://portal.mozz.us/gemini/makeworld.gq/cgi-bin/gemini-irc

The IRC itself is hosted on tilde.chat (Mastodon?).

Phew. Hopefully got the chain of custody right. Irrespectively, apology for the misattribution.



From linde.philip at gmail.com  Mon Dec 21 17:07:06 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 21 Dec 2020 18:07:06 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <30AD59FD-46E3-416D-AC7D-E2953C7E11A5@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <20201220114012.c85368055ae9e081d2833165@gmail.com>
 <30AD59FD-46E3-416D-AC7D-E2953C7E11A5@gmail.com>
Message-ID: <20201221180706.5636042f951631d7ad40fea6@gmail.com>

On Mon, 21 Dec 2020 10:36:57 +0100
Petite Abeille <petite.abeille at gmail.com> wrote:

> Of course, this says nothing about actual use of the protocol. Which can be combined in all sort of weird and wonderful ways to fully subvert such grand "design principle" if needed.

Yes, and when that happens in practice in such a way that the
specification no longer represents actual use, I guess it's reasonable
that the difference between specification and implementations in the
wild should be discussed here.

> The building blocks are chunky and complicate enough on their own to make it complex, both in terms of implementation and actual usage. Not to mention unattended consequences.

Agreed, but I don't see how inviting additional complexity through
extensions will improve that situation.

> The protocol can be trivially extended through conventions.

The non-trivial part is convincing enough implementers to adopt such
conventions that it becomes a problem for compliant implementations.
That compliant extension is only possible through ugly, subversive
hacks should add some resistance to the notion.

Regarding the parts about retrofuturistic goldilocks, Saint-Exup?ry, my
progressive grandma and her samizdat poetry etc.: as a response to my
post it strikes me as inane and distracting. I'm not totally humorless,
but it feels like a brain DoS when I have to sift through more than a
handful of it to find some actual, fully expressed points that I can
consider and respond to.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201221/e2461aed/attachment-0001.sig>

From petite.abeille at gmail.com  Mon Dec 21 17:14:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 18:14:58 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <20201221180706.5636042f951631d7ad40fea6@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <20201220114012.c85368055ae9e081d2833165@gmail.com>
 <30AD59FD-46E3-416D-AC7D-E2953C7E11A5@gmail.com>
 <20201221180706.5636042f951631d7ad40fea6@gmail.com>
Message-ID: <21A88FB9-0988-4DAF-94D8-3C846B401108@gmail.com>


> On Dec 21, 2020, at 18:07, Philip Linde <linde.philip at gmail.com> wrote:
> 
> strikes me as inane and distracting.

Ok. Bone dry technical then. So be it.

Thanks for taking the time to spell it out. We can surely accommodate.

From luke at marmaladefoo.com  Mon Dec 21 20:16:40 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 21 Dec 2020 20:16:40 +0000
Subject: [tech] dumb vs. dumber
In-Reply-To: <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>
References: <A4BAA5F3-5524-46E1-B11D-DCD88D69958F@gmail.com>
 <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>
Message-ID: <5FE102A8.4010002@marmaladefoo.com>



On 21-Dec-2020 13:36, Bj?rn W?rmedal wrote:
>
> * Gemini will not get a PUT/POST feature, because there isn't a
> reasonable way to fit it in. Instead you'll see lots of competing
> "companion protocols" that do this, and I honestly don't believe that
> any of them will gain great enough traction that more than one browser
> will pick any up. HTTP does this better, after all, and you can always
> build specialized tools for your particular platform too.
> * Gemtext will not get feature X, because it's actually just a
> somewhat souped-up text/plain. If you want more out of it there are
> already formats that support that a lot better -- markdown, html, pdf,
> odt to name a few. Solderpunk mentioned (a long time ago now?) that he
> was pondering an even simpler format that would just be plain text
> lines and link lines. That point is moot now, because gemtext is so
> easily parsed and brings so much more readability at such a low cost
> that I think people would just write gemtext anyway.
> * Gemini will not inline things or transclude things, because gemini
> transactions are expensive in that regard. We don't reuse connections,
> and that's a *big* thing about the philosophy and simplicity of
> implementations. I get that some people will want to add this, but why
> fight that uphill battle when HTTP already has it and does it better?
Hi ew0k

Let's not leap to too quickly to unsubstantiated assertions - otherwise 
I shall feel obliged to mutter some opaque comment about the realm of 
the possible being indeed wider than it may seem at first. :)

  - Luke

From petite.abeille at gmail.com  Mon Dec 21 20:18:56 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 21:18:56 +0100
Subject: [tech] text explanation (was Re: [tech] /.well-known/capability ehlo)
In-Reply-To: <20201221180706.5636042f951631d7ad40fea6@gmail.com>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <20201220114012.c85368055ae9e081d2833165@gmail.com>
 <30AD59FD-46E3-416D-AC7D-E2953C7E11A5@gmail.com>
 <20201221180706.5636042f951631d7ad40fea6@gmail.com>
Message-ID: <3F09D90A-5983-4F6C-AE84-400E56307C66@gmail.com>



> On Dec 21, 2020, at 18:07, Philip Linde <linde.philip at gmail.com> wrote:
> 
> Regarding the parts about retrofuturistic goldilocks, Saint-Exup?ry, my progressive grandma and her samizdat poetry etc.:

Perhaps this deserves further text explanations.


> On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> retrofuturistic goldilocks


/retrofuturistic/ Retrofuturism (adjective retrofuturistic or retrofuture) is a movement in the creative arts showing the influence of depictions of the future produced in an earlier era.

This refers to the very description of this mailing list: "A protocol that is slightly more complex than gopher, but significantly simpler than HTTP" 

Gopher being the "retro" part. HTTP the futuristic one;  from the point of view of gopher (circa ~1991). 

This term has been used previously on the mailing list to describe the Gemini protocol, notably by Jason F. McBrayer on December 9th 2020 in  "Some reading on IRIs and IDNs".

/goldilocks/ The Goldilocks principle is named by analogy to the children's story "The Three Bears", in which a young girl named Goldilocks tastes three different bowls of porridge and finds that she prefers porridge that is neither too hot nor too cold, but has just the right temperature

This also  refers to the description of this mailing list.

Too hot: HTTP
Too cold :Gopher
Just right: Gemini

Therefore, the Gemini protocol  is looking for that retrofuturistic, but elusive, goldilocks nirvana.

/elusive/ difficult to find, catch, or achieve.

/nirvana/  (in Buddhism) a transcendent state in which there is neither suffering, desire, nor sense of self, and the subject is released from the effects of karma and the cycle of death and rebirth. It represents the final goal of Buddhism.

Hopefully this is now crystal clear.


> On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Would make Saint-Exup?ry proud.

/Saint-Exup?ry/ Antoine Marie Jean-Baptiste Roger, comte de Saint-Exup?ry, simply known as de Saint-Exup?ry, was a French writer, poet, aristocrat, journalist and pioneering aviator. 

This refers to Solderpunk quoting Saint-Exup?ry -without unnecessary attribution- in the context of "[Spec] Spec (un)freezes and the spec's future", circa December 20th :  ?Perfection is achieved when there is nothing left to take away.?,  (Transcriptions may vary)


> On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Your progressive grandma could whip it up in no time and run it out of her trusty gramophone to share haikus without much ado.

/your/ belonging to or associated with the person or people that the speaker is addressing 

So, not "your" as in Philip Linde own grandmother specifically, but "your" as everyone's. A generic grandmother. 

/progressive/ an advocate of social reform

In this case, synonym for ""modern", "forward looking", "hip", "edgy". Like how the Gemini crowd like to think of itself. Previous art by Little John in  the introduction to  "The Saturday Morning Gemzine": ' ... a technology cannot be said to be "for hipsters' unless someone is using it to run an e-zine"...

/grandma/ informal, one's grandmother.

This denotes  two concepts: old age (gopher), and tech savviness. Or lack therefore. This is meant to convey how easy Gemini is meant to be, as in "Even Your Grandma Can Use It". 

/gramophone/ 	old-fashioned term for record player.

/record player/ an apparatus for reproducing sound from records, comprising a turntable that spins the record at a constant speed and a stylus that slides along in the groove and picks up the sound, together with an amplifier and a loudspeaker.

old-old-fashioned like gother. Additionaly, there is quite a bit of retrotech going around in the Gemini milieu. Not judging, just saying. 

/haikus/ a Japanese poem of seventeen syllables, in three lines of five, seven, and five, traditionally evoking images of the natural world.

Synonym for poem: short artistic text of sort. The Gemini commune seem to like poetry. Not judging, just saying. 

The rest of the sentence should be clear enough to comprehend. Do tell otherwise.


> On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> And there is more to life than publishing samizdat poetry.

/samizdat/ the clandestine copying and distribution of literature banned by the state, especially formerly in the communist countries of eastern Europe.

This refers to another aspect of the Gemini commune: a bit underground, a bit anti-establishment, a bit alternative. 

In conclusion, Gemini is meant to be a retrofuturistic goldilocks to let a hip grandma enjoy some underground poetry.

All in all, my editor tells me this is a technically accurate, if obscure, description of the Gemini sphere. Your milage may vary.

HTH.



From petite.abeille at gmail.com  Mon Dec 21 20:48:49 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 21:48:49 +0100
Subject: [tech] dumb vs. dumber
In-Reply-To: <5FE102A8.4010002@marmaladefoo.com>
References: <A4BAA5F3-5524-46E1-B11D-DCD88D69958F@gmail.com>
 <CAJScK0JSG41mbVrebHSxCwLSqmX=+f92GOSc258jE9YdWcGLMw@mail.gmail.com>
 <5FE102A8.4010002@marmaladefoo.com>
Message-ID: <595FC5D5-A2E6-48F3-851D-AB4D7DD8BE30@gmail.com>



> On Dec 21, 2020, at 21:16, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> otherwise I shall feel obliged to mutter some opaque comment

In my experience, this would be frown upon. This place is all business. Official correspondence only. Also, no IRC (Internet Relay Chat) log transcripts. It's considered rude. Beyond the pale.


From gemini at g-n.site  Mon Dec 21 21:30:48 2020
From: gemini at g-n.site (Simon)
Date: Mon, 21 Dec 2020 22:30:48 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
Message-ID: <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>

As I wrote to Solderpunk before I subscribed to this mailing list, specs 
should add something about input logging :

There is not any information about input logging. I think a page asking 
for a sensitive information must not log the user input.

For instance if the page "/sensitive" returns a 11 code if there is no 
input, then it must not log inputs when there is one.

The problem is if an application needs a user password, then even if the 
password is well stored, it will remain in plain text in logs.


It would be better to have this:

```
127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 
Password: 14
127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" 30 / 6
127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
text/gemini 27
```

instead of this (this output comes from a test done with jetforce):

```
127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 
Password: 14
127.0.0.1 [30/Nov/2020:11:10:21 +0100] 
"gemini://localhost/password?secret_password" 30 / 6
127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
text/gemini 27
```

Logging normal Input and not sensitive input can be annoying. **It can 
be considered to not log any input as an easier way.** Then all input 
can be considered as sensitive + sensitive inputs needs to prevent 
shoulder surfers in addition.

Also, sensitive inputs should not remain in the client history if there 
is one.

From petite.abeille at gmail.com  Mon Dec 21 22:10:46 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 21 Dec 2020 23:10:46 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
Message-ID: <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>



> On Dec 21, 2020, at 22:30, Simon <gemini at g-n.site> wrote:
> 
> As I wrote to Solderpunk before I subscribed to this mailing list, specs should add something about input logging :

Two points:

- Usually, a spec is not meant to mandate implementation details.. i.e. do that, don't do that... as it has no mean to enforce any of it... its role is rather to describe a normative interaction (the protocol) or format (text/gemini). 

- The gemini protocol is not well tailored to handle anything sensitive. Perhaps best to avoid creating such situation in the first place. 

That said, Gemini could sport a set of recommendation and/or "best practices" in a companion document, such as "be mindful of what you log as it may contain sensitive information" and "consider using the underlying TLS mechanism for strong authentication". 

Also, it is quite common for a RFC to sport a "security consideration" section:

Guidelines for Writing RFC Text on Security Considerations
https://tools.ietf.org/html/rfc3552

Actually, it's mandatory.

Hopefully, Gemini will mature into a proper set of RFCs, with syntax grammar, security considerations, and all. Until then, the FAQ may be another place to park such consideration.

Finally, The National Institute of Standards and Technology has a rather comprehensive document on the matter:

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf

Perhaps a bit overwhelming at first sight, but then again, nothing is as trivial as it seems.



From cowan at ccil.org  Mon Dec 21 23:27:34 2020
From: cowan at ccil.org (John Cowan)
Date: Mon, 21 Dec 2020 18:27:34 -0500
Subject: [ANN] a tiny Gemini server written in Ruby
In-Reply-To: <06488db8-f4f8-ca20-ce38-eab79612f8a8@gmail.com>
References: <94b8ccbc-61a6-3784-2fc8-5b254df82142@gmail.com>
 <CAD2gp_TH1qpVE07Myq6jKyA_pp7e=2ve-nmL4gkiAYrqwQJn_w@mail.gmail.com>
 <06488db8-f4f8-ca20-ce38-eab79612f8a8@gmail.com>
Message-ID: <CAD2gp_T=jLbGSsiN7iXZA1Z4eED_aEWaDN52oew94cRaG4CRJQ@mail.gmail.com>

Thank you for relicensing!

And sorry for the confusion about which server I was talking about.
Starlit's server does not seem to have a name yet, which adds to the
ambiguity.

On Mon, Dec 21, 2020 at 6:08 AM starlit <chasmaticvoid at gmail.com> wrote:

>
> On 21/12/2020 4:28, John Cowan wrote:
> > Unless you no longer have any code left that is a direct translation
> > of Satellite, you have written a derivative work, but aren't in
> > compliance with Satellite's AGPL license, which requires derivative
> > works to be licensed under the AGPL.
>
> thank you for your concern. i have updated the license to AGPL.
>
> -starlit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201221/0a6cd516/attachment.htm>

From stephane at sources.org  Tue Dec 22 07:42:56 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 08:42:56 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
 <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
Message-ID: <20201222074256.GA20049@sources.org>

On Mon, Dec 21, 2020 at 11:10:46PM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 44 lines which said:

> - Usually, a spec is not meant to mandate implementation
> details.. i.e. do that, don't do that... as it has no mean to
> enforce any of it... its role is rather to describe a normative
> interaction (the protocol) or format (text/gemini).

In another way: the spec of a network protocol is here to allow
*interoperability*. Unilateral actions (such as logging) has no
influence on interoperability.

> - The gemini protocol is not well tailored to handle anything
> sensitive.

Why? At least for privacy, it is certainly better than HTTPS.

> That said, Gemini could sport a set of recommendation and/or "best
> practices" in a companion document, such as "be mindful of what you
> log as it may contain sensitive information" and "consider using the
> underlying TLS mechanism for strong authentication".

Good idea. A good example is RFC 8932. It is for DNS servers but its
method can be applied to Gemini servers easily. For instance, it
contains a very good and detailed discussion of IP addresses "anonymization".

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8932.txt

> Guidelines for Writing RFC Text on Security Considerations
> https://tools.ietf.org/html/rfc3552

Or on the geminispace

gemini://gemini.bortzmeyer.org/rfc-mirror/rfc3552.txt

> Finally, The National Institute of Standards and Technology has a rather comprehensive document on the matter:

Since one of the goals of Gemini is privacy, I don't think that
relying on an US official document is a good idea.


From petite.abeille at gmail.com  Tue Dec 22 08:40:42 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 09:40:42 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201222074256.GA20049@sources.org>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
 <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
 <20201222074256.GA20049@sources.org>
Message-ID: <193C60BA-A55B-4933-932E-49F7CEAC9FA5@gmail.com>



> On Dec 22, 2020, at 08:42, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> On Mon, Dec 21, 2020 at 11:10:46PM +0100,
> Petite Abeille <petite.abeille at gmail.com> wrote 
> a message of 44 lines which said:
> 
>> - Usually, a spec is not meant to mandate implementation
>> details.. i.e. do that, don't do that... as it has no mean to
>> enforce any of it... its role is rather to describe a normative
>> interaction (the protocol) or format (text/gemini).
> 
> In another way: the spec of a network protocol is here to allow
> *interoperability*. Unilateral actions (such as logging) has no
> influence on interoperability.

Right. The specification should concern itself with interoperability.

> 
>> - The gemini protocol is not well tailored to handle anything
>> sensitive.
> 
> Why? At least for privacy, it is certainly better than HTTPS.

I'm not a security expert, so I will spare myself the embarrassment of articulating a cogent answer, but by "sensitive" I understood "secure". 

There are different aspects to security: data at rest vs data in transit vs data in use, etc.

A threat model helps as well: https://blog.ivanristic.com/2009/09/ssl-threat-model.html

In any case, all above my pay grade. Perhaps someone with actual expertise in this domain could help out. 

Privacy is something else altogether.

> 
>> That said, Gemini could sport a set of recommendation and/or "best
>> practices" in a companion document, such as "be mindful of what you
>> log as it may contain sensitive information" and "consider using the
>> underlying TLS mechanism for strong authentication".
> 
> Good idea. A good example is RFC 8932. It is for DNS servers but its
> method can be applied to Gemini servers easily. For instance, it
> contains a very good and detailed discussion of IP addresses "anonymization".
> 
> gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8932.txt

Nice.

> 
>> Guidelines for Writing RFC Text on Security Considerations
>> https://tools.ietf.org/html/rfc3552
> 
> Or on the geminispace
> 
> gemini://gemini.bortzmeyer.org/rfc-mirror/rfc3552.txt

Let's split the difference:

https://portal.mozz.us/gemini/gemini.bortzmeyer.org/rfc-mirror/rfc3552.txt

In general, would people prefer gemini links? or http ones?

Accessibility is an issue. At this conjuncture, I do not have the proper tooling to systematically provide gemini links by default.  

> 
>> Finally, The National Institute of Standards and Technology has a rather comprehensive document on the matter:
> 
> Since one of the goals of Gemini is privacy, I don't think that
> relying on an US official document is a good idea.
> 

This is a technical document, not a political pamphlet. Let's keep it that way.

By the same account, avoid ARPANET and its decedents. A creation of the United States Department of Defense.

Let's not be overly childish.



From petite.abeille at gmail.com  Tue Dec 22 09:07:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 10:07:11 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201222074256.GA20049@sources.org>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
 <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
 <20201222074256.GA20049@sources.org>
Message-ID: <2210929F-882C-4C10-ACED-8CE9C3E6BB08@gmail.com>



> On Dec 22, 2020, at 08:42, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Since one of the goals of Gemini is privacy

While at it, has this assertion been validated in any ways? Is Gemini actually private in any meaningful way?

Just sticking a 'TLS'  sticker on it a calling it done seem cavalier.

Again, a bit above my pay grade, but between the small size of the user base, more or less static IP addresses, unique TLS variations, not to mention long lived TLS client side certificates, all forming a nice and easy digital fingerprint, Gemini could be a privacy minefield in practice.

Has someone the tooling and expertise to weight in one way or another?






From stephane at sources.org  Tue Dec 22 09:54:49 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 10:54:49 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <2210929F-882C-4C10-ACED-8CE9C3E6BB08@gmail.com>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
 <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
 <20201222074256.GA20049@sources.org>
 <2210929F-882C-4C10-ACED-8CE9C3E6BB08@gmail.com>
Message-ID: <20201222095449.GA24920@sources.org>

On Tue, Dec 22, 2020 at 10:07:11AM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 23 lines which said:

> > Since one of the goals of Gemini is privacy
> 
> While at it, has this assertion been validated in any ways?

It is a *goal*. It does not have to be "validated". I did not say this
goal was reached.

> Is Gemini actually private in any meaningful way?

AFAIK, there was no serious security/privacy evaluation of Gemini
yet.

From stephane at sources.org  Tue Dec 22 09:59:50 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 10:59:50 +0100
Subject: [spec] What to do of fragments when there is a redirection
Message-ID: <20201222095950.GB24920@sources.org>

Gemini specfication apparently does not mention what to do of
fragments when there is a redirection.

If original URI is <gemini://foobar.example/#baz> and there is a
redirect to <gemini://thing.example/doit>, should the Gemini client
consider is has to go to <gemini://thing.example/doit#baz> or to
<gemini://thing.example/doit>?

The spec says "The path, query and fragment components are allowed and
have no special meanings beyond those defined by the generic syntax."
But RFC 3986 just describes a *syntax*, it seems silent about
semantics.

Therefore, for HTTP, RFC 7231 has to describe in detail what the
client ("user agent", in HTTP parlance) has to do with
fragments. Should we consider that "in doubt, do as HTTP does?")


From petite.abeille at gmail.com  Tue Dec 22 11:21:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 12:21:47 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201222095449.GA24920@sources.org>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
 <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
 <20201222074256.GA20049@sources.org>
 <2210929F-882C-4C10-ACED-8CE9C3E6BB08@gmail.com>
 <20201222095449.GA24920@sources.org>
Message-ID: <E0687B79-130E-413F-AD3D-1C54D3BF9338@gmail.com>



> On Dec 22, 2020, at 10:54, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> On Tue, Dec 22, 2020 at 10:07:11AM +0100,
> Petite Abeille <petite.abeille at gmail.com> wrote 
> a message of 23 lines which said:
> 
>>> Since one of the goals of Gemini is privacy
>> 
>> While at it, has this assertion been validated in any ways?
> 
> It is a *goal*. It does not have to be "validated". I did not say this
> goal was reached.

Perhaps worthwhile validating such aspiration, practically speaking, in the field. Otherwise, it sounds like a lot of empty words.

I do not volunteer, as I don't have the skills. Anyone with such skillset?

> 
>> Is Gemini actually private in any meaningful way?
> 
> AFAIK, there was no serious security/privacy evaluation of Gemini
> yet.

That would be a valuable insight.

PSA: Anyone around the gemini space with such expertise?



From petite.abeille at gmail.com  Tue Dec 22 11:57:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 12:57:11 +0100
Subject: [tech] [psa] robustness (was Re: [ANN] A Gemini crawler, for
 statistics about the geminispace)
In-Reply-To: <20201216150549.GA19202@sources.org>
References: <20201216150549.GA19202@sources.org>
Message-ID: <B5447E8D-C5AF-4D51-AD98-C68A2AC0E303@gmail.com>



> On Dec 16, 2020, at 16:05, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> I'm running a Gemini crawler

This is a very brave endeavor. Survivability is key in an experimental, buggy, hostile, or malicious environment. 

The same rules of cautiousness applies to any user-agent, but even more so to headless, automated bots.

There are many possible traps out there. Nothing new under the sun. The interweb has been through this for the last few decades: pranksters vs bots. 

As this is a known, solved problem, I will not bore you with specific details, assuming instead everyone knows what they are doing, eyes wide open.

Just be cautious. Assume hostility, aim for survivability.






From pitr.vern at gmail.com  Tue Dec 22 12:53:41 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 22 Dec 2020 13:53:41 +0100
Subject: [tech] [psa] robustness (was Re: [ANN] A Gemini crawler, for
 statistics about the geminispace)
In-Reply-To: <B5447E8D-C5AF-4D51-AD98-C68A2AC0E303@gmail.com>
References: <20201216150549.GA19202@sources.org>
 <B5447E8D-C5AF-4D51-AD98-C68A2AC0E303@gmail.com>
Message-ID: <CAG-mZ3iBvXzX_Hg+cmDWy_enwg5zS6TFxrCRVVoyERr=NbofeA@mail.gmail.com>

I don?t think details are boring here. Would you mind listing some of the
problems and possible solutions/workarounds?

On Tue, Dec 22, 2020 at 12:57 Petite Abeille <petite.abeille at gmail.com>
wrote:

>
>
> > On Dec 16, 2020, at 16:05, Stephane Bortzmeyer <stephane at sources.org>
> wrote:
> >
> > I'm running a Gemini crawler
>
> This is a very brave endeavor. Survivability is key in an experimental,
> buggy, hostile, or malicious environment.
>
> The same rules of cautiousness applies to any user-agent, but even more so
> to headless, automated bots.
>
> There are many possible traps out there. Nothing new under the sun. The
> interweb has been through this for the last few decades: pranksters vs
> bots.
>
> As this is a known, solved problem, I will not bore you with specific
> details, assuming instead everyone knows what they are doing, eyes wide
> open.
>
> Just be cautious. Assume hostility, aim for survivability.
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201222/505b3292/attachment.htm>

From simon at g-n.site  Mon Dec 21 20:00:06 2020
From: simon at g-n.site (Simon)
Date: Mon, 21 Dec 2020 21:00:06 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
Message-ID: <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>

As I wrote to Solderpunk before I subscribed to this mailing list, specs 
should add something about input logging :

There is not any information about input logging. I think a page asking 
for a sensitive information must not log the user input.

For instance if the page "/sensitive" returns a 11 code if there is no 
input, then it must not log inputs when there is one.

The problem is if an application needs a user password, then even if the 
password is well stored, it will remain in plain text in logs.


It would be better to have this:

```
127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 
Password: 14
127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" 30 / 6
127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
text/gemini 27
```

instead of this (this output comes from a test done with jetforce):

```
127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 
Password: 14
127.0.0.1 [30/Nov/2020:11:10:21 +0100] 
"gemini://localhost/password?secret_password" 30 / 6
127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
text/gemini 27
```

Logging normal Input and not sensitive input can be annoying. **It can 
be considered to not log any input as an easier way.** Then all input 
can be considered as sensitive + sensitive inputs needs to prevent 
shoulder surfers in addition.

Also, sensitive inputs should not remain in the client history if there 
is one.

From me at adnano.co  Mon Dec 21 23:23:07 2020
From: me at adnano.co (Adnan Maolood)
Date: Mon, 21 Dec 2020 23:23:07 GMT
Subject: [users] [ANN] kiln version 0.1.0
Message-ID: <C7YUG7LYK9QI.1FRTPTQ0U2082@nitro>

kiln version 0.1.0 is released!

kiln is a simple static site generator for Gemini sites.

=> https://sr.ht/~adnano/kiln

kiln can be considered relatively stable at this point.
The current design of kiln has proven powerful enough for my needs.
Most changes from this point onward should be backwards compatible.
Some new features may be implemented in the future.

Feedback from existing kiln users would be appreciated.

From solderpunk at posteo.net  Tue Dec 22 15:13:06 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 22 Dec 2020 16:13:06 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
Message-ID: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>

Hi folks,

Okay, I'm finally getting involved in this discussion.  Sorry it took
me a while, and thanks for your patience.  Here's a characteristically
long email detailing how my thinking on this front has evolved in
just the past few days, starting a new thread with the [spec] topic tag.

My a priori thoughts when it became clear that this discussion was
turning into a major issue, but before I had delved into any details,
were something like this:

"Good support for arbitrary languages in Gemini is *important* and
worth putting up with a little bit of pain for.  This is the reason
the `lang` parameter was defined for the text/gemini media type,
because a text encoding alone is not sufficient for a client to know
to do what native speakers of some languages expect (like render
text right to left).  As weird and foreign as this stuff might seem
to a lot of people, only one (English) of the ten most widely spoken
languages in the world (and this doesn't change whether you count
only native speakers or all speakers) can be properly represented
in ASCII, so bailing on unicode support when it seems too hard is
very hard to justify and we should try hard to do the right thing.
That said, there obviously has to be an upper limit on complexity.
Hopefully we can strike a good balance..."

At this point, I'll also add that it was obviously my intention from
the very early days that internationalised URLs "just work" in Gemini.
The clue to this is that the spec defines Gemini requests in terms
of "UTF-8 encoded URLs".  Now that I'm a little wiser about these
things I realise that URIs (and hence URLs) by definition contain only
characters which are encoded identially in UTF-8 and ASCII, so that
"UTF-8 encoded URL", while not a contradiction of any sort, is not
a particularly powerful concept and does nothing to achieve i18n.
But I was certainly naively hoping that it did.  In my ideal world,
something like an IRI would absolutely work in Gemini with a minimum
of fuss.

Anyhow, the other night I read RFC 3987.  Not word for word, mind you,
but more than a casual skim.  At which point my thoughts became:

"Why on Earth is everybody on the ML banging on about punycode this
and normalisation that?  None of that would be relevant for Gemini.
That complexity is only required to transform IRIs into URIs, which
is a workaround for legacy software, document formats and protocols
which can't handle IRIs directly.  Gemini isn't legacy - if we did a
`s/URL/IRL/g` on the spec, we could just pass around UTF-8 encoded
IRLs without any of this hassle and things would just work.  The spec
already [somewhat mistakenly: see above] makes it clear that UTF-8 is
to be expected in requests.  This is a trivial change, not breaking
at all, let's just do it.

Of course, conversion of IDNs to punycode for the sake of DNS lookups
would still be required because we can't change the reality of deployed
DNS infrastructure, but it's insane to think this is the responsibility
of every individual client author, it's up to operating systems and
standard libraries to abstract this away.  Surely they already do this?
Let's check...

Python 3.7.3 (default, Apr  3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getaddrinfo("r?ksm?rg?s.josefsson.org", 1965)
[(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('2001:9b1:8633::102', 1965, 0, 0)), (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('2001:9b1:8633::102', 1965, 0, 0)), (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_RAW: 3>, 0, '', ('2001:9b1:8633::102', 1965, 0, 0)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('178.174.241.102', 1965)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('178.174.241.102', 1965)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_RAW: 3>, 0, '', ('178.174.241.102', 1965))]

Yep, great, wonderful, Python does the punycode stuff for me invisibly,
this adds no extra complexity at all!"

At this point I was, in my private thoughts, a pretty hardcore IRI
advocate, and didn't understand why anybody wouldn't be.

Then I did a little more experimenting and realised that DNS lookups
in Go don't transparently handle the punycoding like Python does, and I
was quite disappointed in Go for that.  Then I started reading through
all the mailing list posts, and realised that people weren't even upset
so much about punycoding IDNs as they were about processing IRIs to
e.g. absolutise relative IRIs or add queries.  This was considered to
require complex third party libraries in most languages.  I was kind
of baffled by this because doing this kind of operation with IRIs is
not substantially different from doing it with URIs (as Sean has shown
by actually implementing it) and I couldn't believe that something
so trivial wouldn't be well handled by standard libraries in 2020
(and, actually, based on some people's posts to the ML it seems like
it often is).  At this point my attitude became:

"Wow, the uptake of these standardised i18n tools in major programming
languages is nothing short of embarrassing.  I would be in favour
of defining Gemini as using IRLs not URLs, but when e.g. clients
written in Go fail to "just work" with these, we do not blame the
client authors and ask them to move mountains to work around the
deficiencies of their standard libraries, but blame the language
implementers.  Over time, surely, the existing DNS and URI libraries
will all be updated to follow the new standards, and those "broken"
clients will suddenly become "working" clients without their authors
even having to do anything.  It's unfortunate that there will be a
transitional period where the Gemini spec is somewhat "aspirational"
and some clients necessarily fall short due to the failings of others,
but that's better than leaving things as is and having Gemini be
forever broken with regards to internationalisation."

Then I followed the mailing list threads yet deeper, and reached
the point where Jason pointed out that RFC 3987 is only a proposed
standard, that it has effectively been abandoned by the IETF,
and that now the W3C has its own alternative standardisation of
"URL" under active development, which is "extremely WWW-centric"
(I'm taking Jason's word for this, I haven't actually looked into the
details of this yet).  This completely undermines my attitude above,
because it makes it much less likely that standard libraries will
ever be uniformly upgraded to handle IRIs correctly, and it means
we can't take the simple moral highground of saying that the Gemini
spec is based on IETF standards and it's not our fault if standard
libraries still need to lift their game to reflect those standards.

Now I honestly don't know what to think.  It has always been a core
tenet of Gemini's design that it is made by joining together mature,
widely-implemented IETF standards in simple ways, so that no heavy
lifting is required to build Gemini software in almost any language
on any almost platform because all the parts are "radically familiar".
I'm very reluctant to move away from that ideal, it's one of our core
strengths.  But I also think localisation is important and, within
reason, I buy the argument that there's a moral obligation to at least
seriously try to fix this, and the fact that other technology stacks
like the web have not is no excuse for us to do them same when we have
the opportunity to make a fresh start.  But these two principles are in
hard conflict.  There apparently *are* no mature, widely-implemented
IETF standards to handle non-ASCII URLs.  This sucks, and I really wish
it were otherwise, but I (and we, the Gemini community) are,
realistically, absolutely powerless to change this, no matter how much
we might like to.

But, *something* has to be decided.  All we can really do is be
pragmatic: consider how much pain is required to get some support
for internationalised addressing into Gemini, and consider who has
to bear that pain.  Ideally, we try to minimise the total amount
of pain, and preferentially inflict more pain on software authors
than on content authors (who are not necessarily developers or even
"power users"), and more pain on server authors than on client authors
(it's of more benefit to more people for it to be easy to roll your
own client than for it to be easy to roll your own server).

The options, then, would appear to be:

1. Nothing changes in the spec (except we remove the language
about "UTF-8 encoded URLs" because this is, frankly, a recipe for
misunderstanding).  Gemini runs entirely on URLs using only a subset
of ASCII.  Clients and servers are permitted to be highly "dumb" in
this regard, and no existing software breaks.  Ultimate responsibility
for internationalised links falls to content authors, who are obligated
to fully punycode and percent-encode all their links so they are
valid URIs, and if they do this wrong their links don't work and
it's nobody's fault but their own, and if they don't understand what
any of that even *means* they are forced to use ASCII URLs instead.
Client authors who want to be i18n friendly can visually present these
links as IRIs if they're up to it, and accept IRIs in the address
bar (or equivalent) and encode them before doing name lookups or
sending requests.  This voluntary extra complexity requires being
able to do punycoding and percent-encoding in both the forward and
backward directions.

2. We stick to ASCII-only URLs in Gemini requests, but allow IRIs in
text/gemini and require all clients to be able to suitably encode
IRIs before doing name lookups or sending requests, and to accept
IRIs in the address bar.  Content authors just write their content
in their ordinary editor in an ordinary human-readable way without
knowing what punycode or perecent enoding are.  All client authors
need to be able to do punycoding and percent-encoding in the forward
direction only.  If no standard library support for this is available,
these operations need to be done from scratch.

3. We treat RFC 3987 as a first-class entity in our world, even if
the IETF has abandoned it.  IRIs are used everywhere, in text/gemini
documents and in requests.  Nobody ever has to do percent encoding
in any direction (beyond what is already required for standard URIs).
The forward punycoding requirement remains as per 2. above.  However,
instead of having to do forward percent encoding, clients now need to
be able to do things like absolutise relative IRIs.  If no standard
library support for this is available, this needs to be done from
scratch - although, note that if standard library support for percent
encoding forward and backwards is present, then the standard library
support for relativising ASCII URLs, which we are basically already
asuming is present everywhere, is sufficient to build this up, so
this is not anywhere near as scary as it seems.  There's an addition
wrinkle here in that unicode normalisation needs to be consistent
between e.g. the client and server's idea of the domain name.
This could, I think be made entirely the server's responsibility,
by requiring servers to normalise requests in a particular way.

Obviously, option 1. is preferable from the point of view of a spec
author or a software implementer, but it has to be acknowledged
that it throws international content authors under the bus (it's
true there are such authors on the ML who are happily doing exactly
what this option requires, but we need to acknowledge that people
who can converse in technical English about protocol design on a
mailing list are not a representative sample!).  From the point of
view of international content authors, 2. and 3. are equivalent.
It's true that this problem could be minimised by the availability
of servers which transform text/gemini content on the fly, and it's
true that historically I've been happiest dumping extra complexity
on server authors, but I'm not sure this is ideal - users might move
their content between hosts and suddenly have their links break,
which will seem mysterious to them.

Regarding options 2. and 3., from a strictly conceptual/aesthetic
perspective, 3. is clearly perferable.  It's much nicer not to have to
map back and forth between a user's perspective of what addresses look
like and a machine's perspective, but to use the same representation
for both.  The less client-side munging of what's in a link line,
the better.  And following an *absolute* IRI is actually easier under
option 3. than under option 2, because it preserves the beautifully
simple idea that to follow a link, you just send the corresponding
server exactly what you find in the document, not some transformation
of it or some subpart of it.  A text/gemini link line is, in fact, a
ready-to-use request with a label on it!

But we need to consider the implementation burden.  Both 2. and
3. require exactly the same punycoding before DNS lookup (and I still
hope this will become more and more transparently handled by standard
libraries over time), so it comes down to what's more widely supported
and what's easiest to implement in the absence of support: percent
encoding an IRI to a URI so it can be parsed, possibly absolutised
and then sent over the wire as a purely ASCII request, or parsing
and possibly absolutising an IRI as-is before sending it as UTF-8?

It seems to have been a big point of concern on the ML that IRI parsing
is rarely supported in standard libraries and difficult to implement
from scratch, and that this totally sinks something like option 3.
But it seems to be the case that IRIs can in fact be processed with
standard tools in Python and Go, and sort-of-kinda in Java.  Of course,
that's not everywhere, but the capability doesn't exactly seem rare.
And in any environment where option 2. is easy, it seems to me that
3. could be achieved roughly as easily just by transforming an IRI
to a URI, parsing that and doing absolutisation with the standard URI
tools that we assume exist everywhere, and then translating back to an
absolute IRI in the end before sending the request.  The basic idea is
that transformation from IRI to URI happens as a last resort, only when
necessary, and the transformation is reversed as early as possible.
The extent and kind of transformation required is directly proportional
to how stubbornly ASCII-only the environment is.  There might be some
environments (seemingly Python could be one) where transformation
*never* needs to happen, and that seems better than an approach where
transformation *always* needs to happen.  So option 3. actually seems
within the realm of possibility to me, although I wouldn't want to
put my full weight behind it until some actual testing has taken place.

It's true that this would be a breaking change, although of a different
kind from other breaking changes I've pushed back against in the past.
It's not as if Geminispace would suddenly become impossible to access,
or would split into two totally incompatible subspaces based on the
old and new protocol versions.  Any currently extant Gemini document
which included ASCII-only links would remain perfectly accessible
by old and new clients alike.  So, it's a relatively soft break.
Given the importance of first-class internationalisation support,
it might be worthwhile.

Feedback welcome, especially if I've overlooked anything, which is
certainly possible.  What I'd be most interested in hearing, at this
point, is client authors letting me know whether the standard library
in the language their client is implemented in can straightforwardly:

1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
   technically not URLs at all, you know what I mean) in paths and/or
   domains?
2. Transform back and forth between URIs and IRIs?
3. Do DNS lookups of IDNs without them being punycoded first?  You can
   test this with r?ksm?rg?s.josefsson.org.

Getting good data on all three of these questions for a wide range
of languages is necessary to make a well-informed decision here.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Tue Dec 22 15:26:02 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 16:26:02 +0100
Subject: [tech] [psa] robustness (was Re: [ANN] A Gemini crawler, for
 statistics about the geminispace)
In-Reply-To: <CAG-mZ3iBvXzX_Hg+cmDWy_enwg5zS6TFxrCRVVoyERr=NbofeA@mail.gmail.com>
References: <20201216150549.GA19202@sources.org>
 <B5447E8D-C5AF-4D51-AD98-C68A2AC0E303@gmail.com>
 <CAG-mZ3iBvXzX_Hg+cmDWy_enwg5zS6TFxrCRVVoyERr=NbofeA@mail.gmail.com>
Message-ID: <BB8F2EE7-2508-4828-9C1F-1D794AA78210@gmail.com>



> On Dec 22, 2020, at 13:53, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
> I don?t think details are boring here.

Really? Didn't get that vibe. Anyway.

> Would you mind listing some of the problems and possible solutions/workarounds?

Two simple examples: resource exhaustion and content poisoning. 

Exhaustion is the most trivial one, The adversary (a technical term, not a value judgment) tries to slow you down or fill you up or reach various limits on your side. E.g. throttling connection, infinite output, hanged connection, any combinations of the above, etc, etc...

This is easy to deal with: always limit everything you do, be it reading, writing, waiting, computing, whatnot. Eventually something will reach these limits and let you out of the trap. You can then mark the site as hostile and/or dysfunctional. Not always clear which one is which: incompetence or malice. 

For example, assuming the network stack goes through, a client has to read at most the first 1024 + some bytes of a server response to figure out what to do. Nothing more. Don't expect a well-formed response line. Assert it. Always validate. Continuously. Drop the connection as soon as something is not right. Always remember what happened.

Of course, there are downsides  to resource exhaustion for the adversary, as it's a sort of self-inflicted denial of service. Oh well.

Content poisoning is more fun. It can be anything from feeding you continuous junk (exhaustion + poisoning), well formed, but ill-intentioned logic bombs, busy beaver, wild goose chase, the list goes on.

For example, a trivial chase is infinite redirects. Got to stop eventually. Another limit.

Another one could be well formed text/gemini, but with  junky links. Same as above.

Again this is easy to identify statistically, marking the adversary as dysfunctional. 

You can them move on, or retaliate, depending on the mood. 

User-agents could also federate such information and use them in meaningful, if ominous, ways.

This is not a one way street: user-agents, specially bots, can do a lot of damage at scale.

Always keep in mind Hanlon's razor: "never attribute to malice that which is adequately explained by stupidity".

https://en.wikipedia.org/wiki/Hanlon%27s_razor

Just my 2?. Have fun.




From ew.gemini at nassur.net  Tue Dec 22 15:43:36 2020
From: ew.gemini at nassur.net (ew.gemini)
Date: Tue, 22 Dec 2020 16:43:36 +0100
Subject: [tech] [psa] robustness (was Re: [ANN] A Gemini crawler, for
 statistics about the geminispace)
In-Reply-To: <CAG-mZ3iBvXzX_Hg+cmDWy_enwg5zS6TFxrCRVVoyERr=NbofeA@mail.gmail.com>
References: <20201216150549.GA19202@sources.org>
 <B5447E8D-C5AF-4D51-AD98-C68A2AC0E303@gmail.com>
 <CAG-mZ3iBvXzX_Hg+cmDWy_enwg5zS6TFxrCRVVoyERr=NbofeA@mail.gmail.com>
Message-ID: <82tusdzw0n.fsf@nassur.net>

Hello,

Peter Vernigorov writes:

> I don?t think details are boring here. Would you mind listing some of the
> problems and possible solutions/workarounds?

This

gemini://alexschroeder.ch/page/2020-12-22_Website_down%2C_disk_full%2C_logs_crazy
https://alexschroeder.ch/wiki/2020-12-22_Website_down%2c_disk_full%2c_logs_crazy

might have been caused by a crawler.

Cheers,
Erich


-- 
Keep it simple!

From petite.abeille at gmail.com  Tue Dec 22 15:46:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 16:46:58 +0100
Subject: [tech] [psa] robustness (was Re: [ANN] A Gemini crawler, for
 statistics about the geminispace)
In-Reply-To: <82tusdzw0n.fsf@nassur.net>
References: <20201216150549.GA19202@sources.org>
 <B5447E8D-C5AF-4D51-AD98-C68A2AC0E303@gmail.com>
 <CAG-mZ3iBvXzX_Hg+cmDWy_enwg5zS6TFxrCRVVoyERr=NbofeA@mail.gmail.com>
 <82tusdzw0n.fsf@nassur.net>
Message-ID: <0DD0B113-89E8-439A-B62B-0ED95EE6F973@gmail.com>



> On Dec 22, 2020, at 16:43, ew.gemini <ew.gemini at nassur.net> wrote:
> 
> might have been caused by a crawler.

There you go. Dysfunction cuts both way. Always be defensive. It's a hostile environment out there.


From cage-dev at twistfold.it  Tue Dec 22 16:23:19 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 22 Dec 2020 17:23:19 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <X+Idd2fuSIBPRsm/@kurosawa.casa.net>

On Tue, Dec 22, 2020 at 04:13:06PM +0100, Solderpunk wrote:
> Hi folks,

Hi!

[...]

>
> Feedback welcome, especially if I've overlooked anything, which is
> certainly possible.  What I'd be most interested in hearing, at this
> point, is client authors letting me know whether the standard library
> in the language their client is implemented in can straightforwardly:
>
> 1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
>    technically not URLs at all, you know what I mean) in paths and/or
>    domains?

Before i can answer i need help  here, i do not know what "relativise"
means, can someone explain (maybe in simple terms ;-)).

Bye!
C.

From solderpunk at posteo.net  Tue Dec 22 16:34:16 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 22 Dec 2020 17:34:16 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <X+Idd2fuSIBPRsm/@kurosawa.casa.net>
Message-ID: <C7ZGJYUS5O2O.SD45ZBQN9YK5@stilgar>

On Tue Dec 22, 2020 at 5:23 PM CET, cage wrote:

> Before i can answer i need help here, i do not know what "relativise"
> means, can someone explain (maybe in simple terms ;-)).

Whoops!  In fact, I meant "absolutise" - i.e. convert a relative URL
into an absolute URL, by using the URL where the relative URL is seen to
fill in the scheme, hostname and possibly part of the path.  Sorry for
the slip up.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Tue Dec 22 16:54:18 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 17:54:18 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>



> On Dec 22, 2020, at 16:13, Solderpunk <solderpunk at posteo.net> wrote:
> 
> Okay, I'm finally getting involved in this discussion.

Thanks for the, hmm, textwall :) Glad you are back. 

To summarize:

#1: Make ASCII Great Again. And again.
#2: Transcribe between 1 & 3
#3: Take the IRI mantel

Hopefully a fair transliteration of intent.

Clearly #3 has the most appeal.

But yes, nothing comes for free, and pragmatism may drag us back to #1.

I don't quite see what #2 is for. Midway compromise? 

Either way, let's ruminate this.








From solderpunk at posteo.net  Tue Dec 22 17:12:41 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 22 Dec 2020 18:12:41 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
Message-ID: <C7ZHDDWTNSRK.23ZFR0MYHEKZQ@stilgar>

On Tue Dec 22, 2020 at 5:54 PM CET, Petite Abeille wrote:

> To summarize:
>
> #1: Make ASCII Great Again. And again.
> #2: Transcribe between 1 & 3
> #3: Take the IRI mantel
>
> Hopefully a fair transliteration of intent.

Yep, that's about right. :)

> Clearly #3 has the most appeal.
>
> But yes, nothing comes for free, and pragmatism may drag us back to #1.

> I don't quite see what #2 is for. Midway compromise?

Option 2. doesn't appeal much to me either, but it seems, from my read
through of most of the ML posts in the three threads you helpfully
linked to, to be quite popular in the community, and it's also
apparently more or less what the web does, so it seemed worth listing.
Having it explicitly spelled out also makes it easy to compare exactly
how much extra work is involved in option 3. compared to this.

Cheers,
Solderpunk


From cage-dev at twistfold.it  Tue Dec 22 17:18:27 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 22 Dec 2020 18:18:27 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <X+IqY87CzSX5dMdv@kurosawa.casa.net>

On Tue, Dec 22, 2020 at 04:13:06PM +0100, Solderpunk wrote:
> Hi folks,

Hi!

[...]

> Feedback welcome, especially if I've overlooked anything, which is
> certainly possible.  What I'd be most interested in hearing, at this
> point, is client authors letting me know whether the standard library
> in the language their client is implemented in can straightforwardly:

The language i written my client with is Common lisp

> 1. Parse and relativise [absolutize] URLs with non-ASCII characters (so, yes, okay,
>    technically not URLs at all, you know what I mean) in paths and/or
>    domains?

The language has no concept of URI; IRI or even URL in the standard library.

I am aware of two free/libre libraries but in my experience both have problems.
I ended writing my custom parser for URI and IRI, that probably is broken as well. ;-)

> 2. Transform back and forth between URIs and IRIs?

Before making a  request I punycode the domain  and percent-encode the
query and fragment (should also percent-encode the path?).

Anyway there is a third party  free library to do percent-encoding and
decoding.

> 3. Do DNS lookups of IDNs without them being punycoded first?  You can
>    test this with r?ksm?rg?s.josefsson.org.

There  is library  in CL  that do  punycoding, i  wrapped a  C library
(libidn2) to do the same instead. I can resolve the domain above! :)

Bye!
C.

From cage-dev at twistfold.it  Tue Dec 22 16:59:54 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 22 Dec 2020 17:59:54 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZGJYUS5O2O.SD45ZBQN9YK5@stilgar>
References: <X+Idd2fuSIBPRsm/@kurosawa.casa.net>
 <C7ZGJYUS5O2O.SD45ZBQN9YK5@stilgar>
Message-ID: <X+ImCjC/0FFrp/WW@kurosawa.casa.net>

On Tue, Dec 22, 2020 at 05:34:16PM +0100, Solderpunk wrote:

Hi!

[...]

>
> Whoops!  In fact, I meant "absolutise" - i.e. convert a relative URL
> into an absolute URL, by using the URL where the relative URL is seen to
> fill in the scheme, hostname and possibly part of the path.  Sorry for
> the slip up.

No problem, i think I am able to answer now! :)

Bye!
C.

From petite.abeille at gmail.com  Tue Dec 22 17:23:51 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 18:23:51 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <X+IqY87CzSX5dMdv@kurosawa.casa.net>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
Message-ID: <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>



> On Dec 22, 2020, at 18:18, cage <cage-dev at twistfold.it> wrote:
> 
>  (should also percent-encode the path?)

Yes. 

The individual path segments actually. 

So, given /Foo/Bar/Baz, decompose the path into individual segments Foo, Bar, and Baz, encode these, and reconstruct the path. Easy-peasy.


From stephane at sources.org  Tue Dec 22 17:30:14 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 18:30:14 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <193C60BA-A55B-4933-932E-49F7CEAC9FA5@gmail.com>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
 <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
 <20201222074256.GA20049@sources.org>
 <193C60BA-A55B-4933-932E-49F7CEAC9FA5@gmail.com>
Message-ID: <20201222173014.GA4797@sources.org>

On Tue, Dec 22, 2020 at 09:40:42AM +0100,
 Petite Abeille <petite.abeille at gmail.com> wrote 
 a message of 91 lines which said:

> > Since one of the goals of Gemini is privacy, I don't think that
> > relying on an US official document is a good idea.
> 
> This is a technical document, not a political pamphlet. Let's keep
> it that way.

When, it comes to logging, there is no such thing as a purely technical
document. Since surveillance is a big issue and a big concern on the
Internet, logging is always very political.

> By the same account, avoid ARPANET and its decedents. A creation of
> the United States Department of Defense.

Completely unrelated. We do not talk about a tool (which may be used
in different ways) but about recommendations from an US agency.

> Let's not be overly childish.

Then, wise grown-up, tell me how to reconcile the US view "personal
data are free to use" with the GDPR view "personal data are like
plutonium, handle with care".



From stephane at sources.org  Tue Dec 22 17:37:01 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 18:37:01 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <20201222173701.GB4797@sources.org>

On Tue, Dec 22, 2020 at 04:13:06PM +0100,
 Solderpunk <solderpunk at posteo.net> wrote 
 a message of 278 lines which said:

> pointed out that RFC 3987 is only a proposed standard,

This specific point is probably irrelevant, since few people care
about the difference between "proposed standard" and "standard". HTTP
is "proposed standard", too.

See RFC 7127 for this classification.



From petite.abeille at gmail.com  Tue Dec 22 17:45:11 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 18:45:11 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201222173014.GA4797@sources.org>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <ebb92273-ec6a-dd74-01fb-54e596e06c77@g-n.site>
 <0E8D7813-3B4E-4286-8A0E-91B81F53B85D@gmail.com>
 <20201222074256.GA20049@sources.org>
 <193C60BA-A55B-4933-932E-49F7CEAC9FA5@gmail.com>
 <20201222173014.GA4797@sources.org>
Message-ID: <E06C2568-8BF3-4B4A-A959-B1A3BEFC0A1E@gmail.com>



> On Dec 22, 2020, at 18:30, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> Then, wise grown-up

Surely a case of mistaken identity :P

> , tell me how to reconcile the US view "personal
> data are free to use" with the GDPR view "personal data are like
> plutonium, handle with care".

International Safe Harbor Privacy Principles
https://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles

But in practice, they don't. This is why you end up with a data center in Dallas vs one in Frankfurt. There are various other complications, industry specific, such as healthcare and finance to name but two.

Not sure where this leaves California.

From jmcbray at carcosa.net  Tue Dec 22 18:14:40 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 22 Dec 2020 13:14:40 -0500
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com> (Petite
 Abeille's message of "Sun, 20 Dec 2020 02:41:02 +0100")
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
Message-ID: <8735zxiu7j.fsf@dorothy.carcosa.net>

Petite Abeille <petite.abeille at gmail.com> writes:

>> On Dec 20, 2020, at 02:26, Sean Conner <sean at conman.org> wrote:
>> 
>>> Thoughts? Opinions? Likes? Dislikes? Something?
>> 
>>  Not much.  Strong opinion.  Not at all.  Yes.  And nothing else to add.
>
> Brief, concise, and clear. Thank you.
>
> Cultural issues aside, such mechanism completely bypass the need for any
> protocol changes, while opening the door to infinite extensibility.

Lack of extensibility is an intentional feature. The only way we have to
enforce that, other than social pressure around the spec, is to make
sure that most attempts to extend the protocol will not be
backwards-compatible. 

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From come at chilliet.eu  Tue Dec 22 18:18:34 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me_Chilliet?=)
Date: Tue, 22 Dec 2020 19:18:34 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <A19A1260-05B7-4DCE-8C6C-F44D4FCB080A@chilliet.eu>

Glad to read all this, it makes a lot of sense.

I'm in full support of option 3.

In PHP from my experience parse_url can eat up any unicode I throw at it. I did not have to do any DNS lookup as I implemented a server and not a client. Percent decoding is also easy.

From jmcbray at carcosa.net  Tue Dec 22 18:28:30 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Tue, 22 Dec 2020 13:28:30 -0500
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201220065218.bmshljwb2xw3v4yc@GLaDOS> (alex@nytpu.com's
 message of "Sat, 19 Dec 2020 23:52:18 -0700")
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
Message-ID: <87y2hphf01.fsf@dorothy.carcosa.net>

Alex // nytpu <alex at nytpu.com> writes:

> Finally, I'd like to address companion specs. Especially if the spec
> is permanently finalized, there will be companion specs popping up all
> over the place.

An article I'm procrastinating on writing deals with companion specs;
maybe I'll even get it out the door one day. The tldr; is that they
shouldn't exist. The use of HTTP and its companions to implement any
arbitrary application is an aberration, and it shouldn't be looked at as
the norm for new/smol protocols. Applications should define a public
protocol that meets their needs, and people should choose applications
using those protocols. Don't build a forum on top of Gemini: spin up an
NNTP server[1].

Jason McBrayer/GCU Prosthetic Conscience

[1]: I'm actually pondering working on a successor protocol to NNTP -
     email me directly if interested.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From lambdatronic at disroot.org  Tue Dec 22 18:33:41 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Tue, 22 Dec 2020 13:33:41 -0500
Subject: [ANN] The Saturday Morning Gemzine
In-Reply-To: <20201219101746.GA28385@SDF.ORG>
References: <20201219101746.GA28385@SDF.ORG>
Message-ID: <87mty51yii.fsf@disroot.org>

Great work! I look forward to reading more issues going forward.

~Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From luke.emmet at orlando-lutes.com  Tue Dec 22 18:35:15 2020
From: luke.emmet at orlando-lutes.com (Luke Emmet)
Date: Tue, 22 Dec 2020 18:35:15 +0000
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>
Message-ID: <5FE23C63.60908@orlando-lutes.com>



On 21-Dec-2020 20:00, Simon wrote:
> As I wrote to Solderpunk before I subscribed to this mailing list, 
> specs should add something about input logging :
>
> There is not any information about input logging. I think a page 
> asking for a sensitive information must not log the user input.
>
> For instance if the page "/sensitive" returns a 11 code if there is no 
> input, then it must not log inputs when there is one.
>
> The problem is if an application needs a user password, then even if 
> the password is well stored, it will remain in plain text in logs.
>
>
> It would be better to have this:
>
> ```
> 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 
> 11 Password: 14
> 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" 
> 30 / 6
> 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
> text/gemini 27
> ```
>
> instead of this (this output comes from a test done with jetforce):
>
> ```
> 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 
> 11 Password: 14
> 127.0.0.1 [30/Nov/2020:11:10:21 +0100] 
> "gemini://localhost/password?secret_password" 30 / 6
> 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
> text/gemini 27
> ```
>
> Logging normal Input and not sensitive input can be annoying. **It can 
> be considered to not log any input as an easier way.** Then all input 
> can be considered as sensitive + sensitive inputs needs to prevent 
> shoulder surfers in addition.
>
> Also, sensitive inputs should not remain in the client history if 
> there is one.

Hello

The general problem is we cannot know which are sensitive URLs and which 
are not.

All parameterised gemini URLs are shareable and linkable - and like HTTP 
GET requests, persistable, somewhat-cacheable and promiscuous. That is 
the normal state of affairs and why the hyperlink powers the internet.

So if I have a URL gemini://host/endpoint?foo - tell me, is foo 
sensitive or not? The answer is we dont know. I can link to this from 
another website.

In my opinion it was a mistake to add the status 11 which lends a false 
sense of security. The URLs creates are in no way distinguishable from 
other URLs. Passing a password in a URL is a terrible choice.

Obviously a server might have some heuristics about what is probably 
sensitive,  some end points might be more sensitive, some not. But there 
is nothing intrinsic to any URL that will indicate this. It is in my 
opinion bad design to build your app to use a password or other 
sensitive info on the URL.

  - Luke

-- 
______________________________________

Orlando Lutes
http://www.orlando-lutes.com


From luke at marmaladefoo.com  Tue Dec 22 18:35:34 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 22 Dec 2020 18:35:34 +0000
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>
Message-ID: <5FE23C76.4050600@marmaladefoo.com>


On 21-Dec-2020 20:00, Simon wrote:
> As I wrote to Solderpunk before I subscribed to this mailing list, 
> specs should add something about input logging :
>
> There is not any information about input logging. I think a page 
> asking for a sensitive information must not log the user input.
>
> For instance if the page "/sensitive" returns a 11 code if there is no 
> input, then it must not log inputs when there is one.
>
> The problem is if an application needs a user password, then even if 
> the password is well stored, it will remain in plain text in logs.
>
>
> It would be better to have this:
>
> ```
> 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 
> 11 Password: 14
> 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" 
> 30 / 6
> 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
> text/gemini 27
> ```
>
> instead of this (this output comes from a test done with jetforce):
>
> ```
> 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 
> 11 Password: 14
> 127.0.0.1 [30/Nov/2020:11:10:21 +0100] 
> "gemini://localhost/password?secret_password" 30 / 6
> 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 
> text/gemini 27
> ```
>
> Logging normal Input and not sensitive input can be annoying. **It can 
> be considered to not log any input as an easier way.** Then all input 
> can be considered as sensitive + sensitive inputs needs to prevent 
> shoulder surfers in addition.
>
> Also, sensitive inputs should not remain in the client history if 
> there is one.

Hello

The general problem is we cannot know which are sensitive URLs and which 
are not.

All parameterised gemini URLs are shareable and linkable - and like HTTP 
GET requests, persistable, somewhat-cacheable and promiscuous. That is 
the normal state of affairs and why the hyperlink powers the internet.

So if I have a URL gemini://host/endpoint?foo - tell me, is foo 
sensitive or not? The answer is we dont know. I can link to this from 
another website.

In my opinion it was a mistake to add the status 11 which lends a false 
sense of security. The URLs creates are in no way distinguishable from 
other URLs. Passing a password in a URL is a terrible choice.

Obviously a server might have some heuristics about what is probably 
sensitive,  some end points might be more sensitive, some not. But there 
is nothing intrinsic to any URL that will indicate this. It is in my 
opinion bad design to build your app to use a password or other 
sensitive info on the URL.

  - Luke

From gemini at g-n.site  Tue Dec 22 18:56:59 2020
From: gemini at g-n.site (Simon)
Date: Tue, 22 Dec 2020 19:56:59 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <5FE23C76.4050600@marmaladefoo.com>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>
 <5FE23C76.4050600@marmaladefoo.com>
Message-ID: <7e1dd6f5-8f2f-28c9-1bd5-a0a8ef4b08e7@g-n.site>


Maybe we should move this thread if it continues, since it is not spec 
but recommendation. And actually, reading again the solderpunk answer: 
he told me that it is going on good practice and not spec. ^^'

On 12/22/20 7:35 PM, Luke Emmet wrote:
> 
> On 21-Dec-2020 20:00, Simon wrote:
>>  **It can be considered to not log any input as an easier way.** Then all input 
>> can be considered as sensitive + sensitive inputs needs to prevent 
>> shoulder surfers in addition.
>>
>> Also, sensitive inputs should not remain in the client history if 
>> there is one.
> 
> The general problem is we cannot know which are sensitive URLs and which 
> are not. 

Then we agree on that !

I just wanted to show that we are easily thinking gemini input as HTTP 
GET parameters, but they aren't, even if they are passed in the URL. The 
only way to not deal with this server side problem, would be to not log 
any input.


From khuxkm at tilde.team  Tue Dec 22 19:10:26 2020
From: khuxkm at tilde.team (Robert "khuxkm" Miles)
Date: Tue, 22 Dec 2020 19:10:26 +0000
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <7e1dd6f5-8f2f-28c9-1bd5-a0a8ef4b08e7@g-n.site>
References: <7e1dd6f5-8f2f-28c9-1bd5-a0a8ef4b08e7@g-n.site>
 <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>
 <5FE23C76.4050600@marmaladefoo.com>
Message-ID: <eddf744d8c7d197aa8af9c2e23ddc8f8@tilde.team>

December 22, 2020 1:56 PM, "Simon" <gemini at g-n.site> wrote:

> The only way to not deal with this server side problem, would be to not log any input.

Or just don't bother. If someone's building an application that takes passwords as Gemini input, that's their prerogative, especially with client certs being a first class citizen in Gemini.

Just my two cents,
Robert "khuxkm" Miles

From stephane at sources.org  Tue Dec 22 19:37:08 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 20:37:08 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <20201222193708.GA9872@sources.org>

On Tue, Dec 22, 2020 at 04:13:06PM +0100,
 Solderpunk <solderpunk at posteo.net> wrote 
 a message of 278 lines which said:

> What I'd be most interested in hearing, at this point, is client
> authors letting me know whether the standard library in the language
> their client is implemented in can straightforwardly:

Tests with Python. All of this is now implemented in the Agunua tool
<https://framagit.org/bortzmeyer/agunua>.

% agunua gemini://g?meaux.bortzmeyer.org/caf?.gmi
# Du caf?

Si vous voyez cela, c'est que votre client Gemini g?re les IRI.

> 1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
>    technically not URLs at all, you know what I mean) in paths and/or
>    domains?

No problem, standard library urllib.parse.urlparse parses IRI.

> 2. Transform back and forth between URIs and IRIs?

Not directly in the standard library, but the code is simple (attached).

> 3. Do DNS lookups of IDNs without them being punycoded first?  You can
>    test this with r?ksm?rg?s.josefsson.org.

Yes, punycoding is handled by the standard library
socket.getaddrinfo. (May be a violation of RFC 6055 but I did not
search further.)

There is also this third-party package which I did not test
<https://pypi.org/project/rfc3987/>.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: convert-iri-uri.py
Type: text/x-python
Size: 1143 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201222/77f2451d/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: convert-uri-iri.py
Type: text/x-python
Size: 659 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201222/77f2451d/attachment-0001.py>

From stephane at sources.org  Tue Dec 22 19:39:50 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 20:39:50 +0100
Subject: [tech] /.well-known/capability ehlo
In-Reply-To: <8735zxiu7j.fsf@dorothy.carcosa.net>
References: <15815838-98FE-4438-878B-6BE3EE982D0C@gmail.com>
 <20201220012623.GN9267@brevard.conman.org>
 <19B88A32-B212-4C78-B891-70C6E0933B0D@gmail.com>
 <8735zxiu7j.fsf@dorothy.carcosa.net>
Message-ID: <20201222193950.GA10053@sources.org>

On Tue, Dec 22, 2020 at 01:14:40PM -0500,
 Jason McBrayer <jmcbray at carcosa.net> wrote 
 a message of 23 lines which said:

> Lack of extensibility is an intentional feature. The only way we have to
> enforce that, other than social pressure around the spec, is to make
> sure that most attempts to extend the protocol will not be
> backwards-compatible. 

We have another tool for enforcement: simplicity of the system. That
way, there will be many clients and servers and it will be more
difficult to add a non-consensual feature. (Unlike the Web where
Google can implement anything, the few others will have to follow. The
lack of competition on the Web is one of the worst consequences of its
complexity.)


From stephane at sources.org  Tue Dec 22 19:42:25 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Tue, 22 Dec 2020 20:42:25 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <87y2hphf01.fsf@dorothy.carcosa.net>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <87y2hphf01.fsf@dorothy.carcosa.net>
Message-ID: <20201222194225.GB10053@sources.org>

On Tue, Dec 22, 2020 at 01:28:30PM -0500,
 Jason McBrayer <jmcbray at carcosa.net> wrote 
 a message of 25 lines which said:

> An article I'm procrastinating on writing deals with companion
> specs; maybe I'll even get it out the door one day. The tldr; is
> that they shouldn't exist. The use of HTTP and its companions to
> implement any arbitrary application is an aberration,

But what about "side specifications" such as robots.txt?

From petite.abeille at gmail.com  Tue Dec 22 20:01:25 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 21:01:25 +0100
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <20201222194225.GB10053@sources.org>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <87y2hphf01.fsf@dorothy.carcosa.net> <20201222194225.GB10053@sources.org>
Message-ID: <FCD3F8BC-A605-4212-8040-3D4C0906E5CF@gmail.com>



> On Dec 22, 2020, at 20:42, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> But what about "side specifications" such as robots.txt?

Or "Implementation Recommendation" (aka lesson learned, ~faq, etc )?, such as 

IMAP4 Implementation Recommendations
https://tools.ietf.org/html/rfc2683


From petite.abeille at gmail.com  Tue Dec 22 20:09:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 21:09:39 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
Message-ID: <039EB2EB-8880-4F3E-8E75-4571F863682A@gmail.com>



> On Dec 22, 2020, at 17:54, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> #3: Take the IRI mantel

If this ever goes through, we should consider increasing the maximum request size to 4,096 bytes* to keep the number of characters constant.

* the current 1,028 bytes ? 4, as UTF8  can use up to four bytes per character

From cowan at ccil.org  Tue Dec 22 20:34:03 2020
From: cowan at ccil.org (John Cowan)
Date: Tue, 22 Dec 2020 15:34:03 -0500
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <20201222095950.GB24920@sources.org>
References: <20201222095950.GB24920@sources.org>
Message-ID: <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>

>
> Therefore, for HTTP, RFC 7231 has to describe in detail what the
> client ("user agent", in HTTP parlance) has to do with
> fragments. Should we consider that "in doubt, do as HTTP does?")
>

I think we should adopt the following RFC 7231 compatible rules.

0) The semantics of a fragment are defined solely by the media type of the
resource and not by the rest of the URL.

1) Clients MUST NOT send a fragment to the server.  If the server needs to
know the content of a fragment, it should be part of the path or the query
string instead.  This was a firm HTTP rule until fragments beginning with !
were invented, and IMO should be a firm Gemini rule.

2) If the client gets a redirect containing a fragment, the client MUST
apply this fragment when the redirected resource is retrieved, ignoring any
original fragment.

3) If the original URL has a fragment and the redirect doesn't, the client
MUST apply the original fragment when the redirected resource is retrieved.

4) Content authors MUST NOT put personally identifying information into
fragments, as they can be transferred from one host to another by the
operation of rule 3.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
He who would do good to another must do it in Minute Particulars;
General Good is the plea of the scoundrel, hypocrite and flatterer:
For Art and Science cannot exist but in minutely organized Particulars.
  --William Blake, il miglior fabbro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201222/ef94f595/attachment.htm>

From lambdatronic at disroot.org  Tue Dec 22 20:51:25 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Tue, 22 Dec 2020 15:51:25 -0500
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <20201222095950.GB24920@sources.org>
References: <20201222095950.GB24920@sources.org>
Message-ID: <87h7od1s4y.fsf@disroot.org>

Stephane Bortzmeyer <stephane at sources.org> writes:

> Gemini specfication apparently does not mention what to do of
> fragments when there is a redirection.
>
> If original URI is <gemini://foobar.example/#baz> and there is a
> redirect to <gemini://thing.example/doit>, should the Gemini client
> consider is has to go to <gemini://thing.example/doit#baz> or to
> <gemini://thing.example/doit>?

This is a reasonable question. In HTTP, fragments are usually used to
denote a particular named anchor on the same page. While I support
parsing fragments from Gemini requests in my server and presenting them
to CGI-like functions, I don't include fragments in redirects to other
pages in the same way that I would leave off the query from one request
when redirecting to another page. AFAIK, both the query and fragment are
specific to a particular path on the server and don't transfer to
others.

Hopefully, Solderpunk can clarify this once and for all for us.

Best,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From sean at conman.org  Tue Dec 22 22:18:28 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 22 Dec 2020 17:18:28 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
Message-ID: <20201222221828.GX9267@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Dec 22, 2020, at 16:13, Solderpunk <solderpunk at posteo.net> wrote:
> > 
> > Okay, I'm finally getting involved in this discussion.
> 
> Thanks for the, hmm, textwall :) Glad you are back. 
> 
> To summarize:
> 
> #1: Make ASCII Great Again. And again.
> #2: Transcribe between 1 & 3
> #3: Take the IRI mantel
> 
> Hopefully a fair transliteration of intent.
> 
> Clearly #3 has the most appeal.
> 
> But yes, nothing comes for free, and pragmatism may drag us back to #1.
> 
> I don't quite see what #2 is for. Midway compromise? 

  1. Status quo
  2. Clients take the hit (have to support both URL and IRI)
  3. Clients and servers take the hit (both have to support URL and IRI)

  -spc


From petite.abeille at gmail.com  Tue Dec 22 22:21:38 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 22 Dec 2020 23:21:38 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201222221828.GX9267@brevard.conman.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
Message-ID: <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>



> On Dec 22, 2020, at 23:18, Sean Conner <sean at conman.org> wrote:
> 
>  3. Clients and servers take the hit (both have to support URL and IRI)

This being a very equalitarian commune, I say this sounds fair: everybody "take the hit" for the greater good. 


From stephen at drsudo.com  Tue Dec 22 22:40:55 2020
From: stephen at drsudo.com (Stephen)
Date: Tue, 22 Dec 2020 14:40:55 -0800
Subject: [tech] Questions about cache
Message-ID: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>

Gemini spec does not mention caching, and the FAQ says:

 > Gemini has no support for caching

So I was a bit surprised when I was putting together some dynamic 
content for my capsule and found that my client (amfora) was caching 
things. I was able to get around it by using temporary redirects to add 
cache busting query strings.

I don't have much experience with gopher, but I have seen that this has 
been a problem in the gopherspace. On the mozz.us phlog entry for his 
Rock Paper Scissors game he notes:

 > The random token at the end of the URL (e.g "/bfhqK3kH") doesn't
 > actually represent anything. I only added it for cache-busting on
 > lynx (otherwise you would always see the same result as the first
 > time you loaded the page). I really hate doing that because it screws
 > with the purity of my gopher routes. But a lot of people (including
 > myself) use lynx. It sort of reminds me of JS hacking to support old
 > Internet Explorer versions.

( gopher://mozz.us:70/1/phlog 2019-04-12 )

Is there some guarantee that a capsule writer has on what may _not_ be 
cached, or is it entirely up to the client's discretion? If the latter, 
is this something which could be clarified in the spec? My impression 
from this ML was that caching is frowned upon (except for perhaps 
navigating back and forth through your history), but this has not been 
my experience (at least with amfora).

~Stephen ( gemini://drsudo.com/ )

From luke at marmaladefoo.com  Tue Dec 22 22:46:58 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 22 Dec 2020 22:46:58 +0000
Subject: [Spec] Spec (un)freezes and the spec's future
In-Reply-To: <7e1dd6f5-8f2f-28c9-1bd5-a0a8ef4b08e7@g-n.site>
References: <20201220065218.bmshljwb2xw3v4yc@GLaDOS>
 <92832be7-d2df-6fb9-7a9b-900c268b8dbf@g-n.site>
 <5FE23C76.4050600@marmaladefoo.com>
 <7e1dd6f5-8f2f-28c9-1bd5-a0a8ef4b08e7@g-n.site>
Message-ID: <5FE27762.6040207@marmaladefoo.com>



On 22-Dec-2020 18:56, Simon wrote:
>
>> The general problem is we cannot know which are sensitive URLs and 
>> which are not. 
>
> Then we agree on that !
>
> I just wanted to show that we are easily thinking gemini input as HTTP 
> GET parameters, but they aren't, even if they are passed in the URL. 
> The only way to not deal with this server side problem, would be to 
> not log any input.

Except - au contraire - they are indeed very like HTTP GET parameters, 
ticking the same boxes just like HTTP

[x] part of the URL syntax
[x] linked to a client UI behaviour
[x] opaque, server-specific semantics
[x] replayable when the link is shared elsewhere
[x] largely indistinguishable from other elements of the URL submitted 
to the server (e.g. host/foo/bar ~ host/foo?bar)

I know the web is officially persona-non-grata round these parts, but 
URL semantics are more or less common when using them for a distributed 
hypertext system of webspace or geminispace

Regards

  - Luke

From sean at conman.org  Tue Dec 22 22:59:58 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 22 Dec 2020 17:59:58 -0500
Subject: [tech] Questions about cache
In-Reply-To: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
Message-ID: <20201222225958.GY9267@brevard.conman.org>

It was thus said that the Great Stephen once stated:
> Gemini spec does not mention caching, and the FAQ says:
> 
> > Gemini has no support for caching
> 
> So I was a bit surprised when I was putting together some dynamic 
> content for my capsule and found that my client (amfora) was caching 
> things. I was able to get around it by using temporary redirects to add 
> cache busting query strings.

  There was a thread about this in early November:

	https://lists.orbitalfox.eu/archives/gemini/2020/003077.html

  It appears that half want caching, half don't.  It's a mess.

  -spc


From luke at marmaladefoo.com  Tue Dec 22 23:08:13 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 22 Dec 2020 23:08:13 +0000
Subject: [tech] Questions about cache
In-Reply-To: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
Message-ID: <5FE27C5D.8010707@marmaladefoo.com>

On 22-Dec-2020 22:40, Stephen wrote:
>
> Is there some guarantee that a capsule writer has on what may _not_ be 
> cached, or is it entirely up to the client's discretion? If the 
> latter, is this something which could be clarified in the spec? My 
> impression from this ML was that caching is frowned upon (except for 
> perhaps navigating back and forth through your history), but this has 
> not been my experience (at least with amfora).

As a user facing client author, the semantics that makes most sense to 
me, whilst recognising the Gemini does not have any mechanism to 
indicate staleness is as follows:

1. Any overt action by the user to activate or refresh a link retrieves 
a fresh copy

2. Navigation backwards and forwards through history may use a local 
cached version

This is largely the equivalent of web pages having expires=0

Other clients (like crawlers, indexers and the like) preserve their own 
copies on the understanding that the data will be out of date - but 
still their cache may be useful for their own purposes.

I think a client caching a resource when the user has overtly requested 
it is probably overstepping its authority to provide what the user 
expected/intended.

  - Luke


From linde.philip at gmail.com  Tue Dec 22 23:09:56 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 23 Dec 2020 00:09:56 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <20201223000956.8b79ac9269a6f1bf40017537@gmail.com>

On Tue, 22 Dec 2020 16:13:06 +0100
"Solderpunk" <solderpunk at posteo.net> wrote:

> 1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
>    technically not URLs at all, you know what I mean) in paths and/or
>    domains?
> 2. Transform back and forth between URIs and IRIs?

I am using Go, which will do these things as you mentioned.

Output from net/url:

  gemini://r?ksm?rg?s.example.com:3131/?????/hej/hopp??=?#???
  Scheme: gemini
  Path: /?????/hej/hopp
  EscapedPath: /%C3%A5%C3%A4%C3%B6%C3%BC%C3%BF/hej/hopp
  RawQuery: ?=?
  Hostname: r?ksm?rg?s.example.com
  Port: 3131
  RawFragment: ???
  EscapedFragment: %C3%A7%C3%A7%C3%A7

> 3. Do DNS lookups of IDNs without them being punycoded first?  You can
>    test this with r?ksm?rg?s.josefsson.org.

Go won't do this automatically as mentioned, but there is an
experimental standard library project golang.org/x/net/idna that can
assist. I think that this is the best approach; the use of IDNA is
application dependent and IMO shouldn't be done automatically at such a
low level.

Note that for Python, Python 3.x will correctly resolve as per your
example, but Python 2.x will not. Python 3 also doesn't support
IDNA2008 (see https://bugs.python.org/issue17305), which is slightly
incompatible with IDNA2003. There is a third party library that
supports IDNA2008. As a last resort, client authors should be able to
link to e.g. Libidn2, license permitting.

In my case the problem with implementing IDNA is not in my application.
My client is a browser plugin. The browser (Dillo) doesn't support IDN
and development is pretty slow on their end. My plugin inherits this
limitation.

Even then, I am for option #1 personally. IDN/IRI are presentational
problems which I think should be left to the client. IDN/IRI in
text/gemini for authors can be solved with tooling, but I am not sure
that's desirable. I've attached the source code to a text/gemini
formatter that "un-internationalizes" IRIs in a text/gemini document
passed on stdin anyway...discovered an HTTP-ism in net/url along the
way :)

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gmifmt.go
Type: application/octet-stream
Size: 1733 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/b244c0ac/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/b244c0ac/attachment.sig>

From luke at marmaladefoo.com  Tue Dec 22 23:10:20 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 22 Dec 2020 23:10:20 +0000
Subject: [tech] Questions about cache
In-Reply-To: <5FE27C5D.8010707@marmaladefoo.com>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
 <5FE27C5D.8010707@marmaladefoo.com>
Message-ID: <5FE27CDC.2080903@marmaladefoo.com>



On 22-Dec-2020 23:08, Luke Emmet wrote:
>
> I think a client caching a resource when the user has overtly 
> requested it is probably overstepping its authority to provide what 
> the user expected/intended.
Sorry, to clarify, I meant to say that my view was that a client 
retrieving a cached version of a resource when the user has overtly 
requested it [...] has probably overstepped its authority etc

From luke at marmaladefoo.com  Tue Dec 22 23:20:19 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Tue, 22 Dec 2020 23:20:19 +0000
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
Message-ID: <5FE27F33.1070705@marmaladefoo.com>



On 22-Dec-2020 20:34, John Cowan wrote:
>
>     Therefore, for HTTP, RFC 7231 has to describe in detail what the
>     client ("user agent", in HTTP parlance) has to do with
>     fragments. Should we consider that "in doubt, do as HTTP does?")
>
>
> I think we should adopt the following RFC 7231 compatible rules.
>
> 0) The semantics of a fragment are defined solely by the media type of 
> the resource and not by the rest of the URL.
>
> 1) Clients MUST NOT send a fragment to the server.  If the server 
> needs to know the content of a fragment, it should be part of the path 
> or the query string instead.  This was a firm HTTP rule until 
> fragments beginning with ! were invented, and IMO should be a firm 
> Gemini rule.
>
> 2) If the client gets a redirect containing a fragment, the client 
> MUST apply this fragment when the redirected resource is 
> retrieved, ignoring any original fragment.
>
> 3) If the original URL has a fragment and the redirect doesn't, the 
> client MUST apply the original fragment when the redirected resource 
> is retrieved.
>
> 4) Content authors MUST NOT put personally identifying information 
> into fragments, as they can be transferred from one host to another by 
> the operation of rule 3.

I agree with this - that they should be client side only, but can be 
part of a persistent URL.

The question that remains particularly, is what should be the semantics 
of the fragment for our most prevalent media type - text/gemini?

I would propose that the fragment should indicate an offset to one of 
the headers in the page - but we'd need to agree how they should be 
formulated.

Some Markdown engines seems to have an established convention of 
creating the fragment name based on the header text, suitably 
normalised, e.g.

# Here is a heading

would have the associated offset fragment: "here-is-a-heading"

this approach is somewhat robust to page edits

Another approach could be to use the line index e.g. endpoint#12 means 
the twelfth line in that page. This is more finegrained, but is a bit 
more fragile.

Then again, do we really have much of a need to do page-specific 
indexing for URLs? Most Gemini pages are quite simple and not too 
complicated. So maybe we just get by without the fragment?

  - Luke

From linde.philip at gmail.com  Tue Dec 22 23:22:51 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 23 Dec 2020 00:22:51 +0100
Subject: [tech] Questions about cache
In-Reply-To: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
Message-ID: <20201223002251.b7c7933840e07381fef28831@gmail.com>

On Tue, 22 Dec 2020 14:40:55 -0800
Stephen <stephen at drsudo.com> wrote:

> Is there some guarantee that a capsule writer has on what may _not_ be 
> cached, or is it entirely up to the client's discretion? If the latter, 
> is this something which could be clarified in the spec? My impression 
> from this ML was that caching is frowned upon (except for perhaps 
> navigating back and forth through your history), but this has not been 
> my experience (at least with amfora).

It is at the clients discretion by my reading; it's not brought up at
all in the spec. In general it's probably best for the client to avoid
caching, at least by default. According to Stephane's statistics page?,
most documents are typically rather small anyway (but perhaps some of
the larger ones are more popular...)

The main cost is establishing a connection and the TLS handshake,
where the client and server have to do some back-and-forths and will
spend a lot of time just waiting for responses. For this reason I
personally prefer to use caching liberally, at least for the duration
of my session. There are some applications that will break as a result,
but I don't tend to use them myself.

I think that no-caching-by-default should be suggested as a best
practice in the best practices document.

1: gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/59e84aef/attachment-0001.sig>

From alex at nytpu.com  Tue Dec 22 23:29:15 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Tue, 22 Dec 2020 16:29:15 -0700
Subject: [tech] Questions about cache
In-Reply-To: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
Message-ID: <20201222232915.56pi2cy6f4heldaz@GLaDOS>

> > Gemini has no support for caching

This is referring to protocol-mandated caching, there's nothing saying a
client can't cache at its discretion. It also implies that if your
dynamic content doesn't work, then it's the client's fault, not yours
nor the protocol's.


> So I was a bit surprised when I was putting together some dynamic
> content for my capsule and found that my client (amfora) was caching
> things. I was able to get around it by using temporary redirects to
> add cache busting query strings.

Well behaved clients usually have some way to disable or get around the
cache. For instance, Lagrange only caches forwards and backwards
navigation, and any new links visited will not use the cache, even if
you've already visited that page.

Looking at the Amfora code, it seems like there's 3 limits to the
cache[1]: number of pages, size in bytes, and number of seconds. This
seems to be configurable[2],and it looks like it *should* (I may be
misreading the code) hard reload the page when you refresh a tab[3]. Not
that this is helpful for dynamic content, you can't expect your users to
do an extra refresh every time, but helpful if you're viewing a dynamic
page yourself.

[1]: https://github.com/makeworld-the-better-one/amfora/blob/master/cache/page.go#L19-L3
[2]: https://github.com/makeworld-the-better-one/amfora/blob/master/config/config.go#L199-L201
[3]: https://github.com/makeworld-the-better-one/amfora/blob/master/display/display.go#L591-L592


> > ...I only added it for cache-busting on lynx (otherwise you would
> > always see the same result as the first time you loaded the page).

This seems like lynx's fault. Caching a page permanently is not a good
idea, even in webspace.


> Is there some guarantee that a capsule writer has on what may _not_ be
> cached, or is it entirely up to the client's discretion? If the
> latter, is this something which could be clarified in the spec? My
> impression from this ML was that caching is frowned upon (except for
> perhaps navigating back and forth through your history), but this has
> not been my experience (at least with amfora).

There's no way to guarantee or request it, because pages assume they
aren't cached. The consensus on caching should be that it should be only
in special circumstances instead of the norm (for instance, caching
forward/backward navigation only). I'd look to see if there's a way to
disable caching on a per-site basis or at least temporarily disable it
globally in Amfora, because having a cache that acts like that doesn't
seem quite right. Absolute worst case, use a different client for
dynamic content than you would use for static content.


Just because I'm lazy I wouldn't go out of my way to implement cache
busting, and instead just put a warning saying some clients may cache
the page and cause it to not function properly. Especially when most
clients don't cache, and the cache-busting would clog up
forward/backward navigation on normal clients.

~nytpu

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201222/caf4c00c/attachment.sig>

From stephen at drsudo.com  Tue Dec 22 23:31:43 2020
From: stephen at drsudo.com (Stephen)
Date: Tue, 22 Dec 2020 15:31:43 -0800
Subject: [tech] Questions about cache
In-Reply-To: <20201222225958.GY9267@brevard.conman.org>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
 <20201222225958.GY9267@brevard.conman.org>
Message-ID: <0b292576-54e1-dbe1-75ab-2996a4acd20f@drsudo.com>

>    There was a thread about this in early November:
> 
> 	https://lists.orbitalfox.eu/archives/gemini/2020/003077.html
> 
>    It appears that half want caching, half don't.  It's a mess.

Well that's embarrassing. I don't know how I missed that *blush*. Thanks 
for the link and sorry for the noise.

In case anyone is curious, this is the solution I came up with to 
prevent caching. I have a cgi script like this:

if [ -z "$QUERY_STRING" ]; then
   printf '30 %s?%s\r\n' \
     "$(basename "$SCRIPT_PATH")" \
     "$(date | tr ' :' __)"
else
   printf '20 text/gemini\r\n'
   generate_content
fi

Basically, if there is no query string on the path, it redirects you to 
the same page with a cache busting query string constructed from the 
current date and time. If there is a query string, it gives you the content.

It's not perfect. A user could bookmark a page with a cache busting 
string on it and then see the same static page until it went out of 
their cache. I don't think there is a way around that though.

~Stephen

From sean at conman.org  Tue Dec 22 23:38:45 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 22 Dec 2020 18:38:45 -0500
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <5FE27F33.1070705@marmaladefoo.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
Message-ID: <20201222233845.GZ9267@brevard.conman.org>

It was thus said that the Great Luke Emmet once stated:
> 
> The question that remains particularly, is what should be the semantics 
> of the fragment for our most prevalent media type - text/gemini?

  So here's a totally off-the-cuff spec I'm pulling out of my nether regions
that seems simple and somewhat robust.

  You have the following item types in Gemini:

	text lines
	link lines
	pre toggles
	heading lines
	unordered list lines
	quote lines

  All of these can be represented by a single letter 'T', 'L', 'P', 'U'
and 'Q' with the header lines as 'H1', 'H2' and 'H3'.  So, some examples:

	foo#h1.1	- first top level header
	foo#h2.4	- fourth second level header
	foo#l.9		- ninth link line
	foo#h3.2l.2	- second link after second third level header
	foo#p.2t1	- first line past second pre-toggle

	gemini://gemini.circumlunar.space/docs/specification.gmi#h1.4h2.2h2
			- references section 3.2.2 2x (SUCCESS) section

  -spc (See?  Very simple)


From mailinglists at ngalt.com  Tue Dec 22 23:41:49 2020
From: mailinglists at ngalt.com (Nathan Galt)
Date: Tue, 22 Dec 2020 15:41:49 -0800
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <5FE27F33.1070705@marmaladefoo.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
Message-ID: <57C2DD53-0014-4BAB-97A6-4D00563B448D@ngalt.com>


> On Dec 22, 2020, at 3:20 PM, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> 
> 
> On 22-Dec-2020 20:34, John Cowan wrote:
>> 
>>    Therefore, for HTTP, RFC 7231 has to describe in detail what the
>>    client ("user agent", in HTTP parlance) has to do with
>>    fragments. Should we consider that "in doubt, do as HTTP does?")
>> 
>> 
>> I think we should adopt the following RFC 7231 compatible rules.
>> 
>> 0) The semantics of a fragment are defined solely by the media type of the resource and not by the rest of the URL.
>> 
>> 1) Clients MUST NOT send a fragment to the server.  If the server needs to know the content of a fragment, it should be part of the path or the query string instead.  This was a firm HTTP rule until fragments beginning with ! were invented, and IMO should be a firm Gemini rule.
>> 
>> 2) If the client gets a redirect containing a fragment, the client MUST apply this fragment when the redirected resource is retrieved, ignoring any original fragment.
>> 
>> 3) If the original URL has a fragment and the redirect doesn't, the client MUST apply the original fragment when the redirected resource is retrieved.
>> 
>> 4) Content authors MUST NOT put personally identifying information into fragments, as they can be transferred from one host to another by the operation of rule 3.
> 
> I agree with this - that they should be client side only, but can be part of a persistent URL.
> 
> The question that remains particularly, is what should be the semantics of the fragment for our most prevalent media type - text/gemini?
> 
> I would propose that the fragment should indicate an offset to one of the headers in the page - but we'd need to agree how they should be formulated.
> 
> Some Markdown engines seems to have an established convention of creating the fragment name based on the header text, suitably normalised, e.g.
> 
> # Here is a heading
> 
> would have the associated offset fragment: "here-is-a-heading"
> 
> this approach is somewhat robust to page edits
> 
> Another approach could be to use the line index e.g. endpoint#12 means the twelfth line in that page. This is more finegrained, but is a bit more fragile.
> 
> Then again, do we really have much of a need to do page-specific indexing for URLs? Most Gemini pages are quite simple and not too complicated. So maybe we just get by without the fragment?
> 
> - Luke

Chrome also supports text fragments like `#:~:text=an%20example%20text%20fragment` , and they?re trying to have this feature be a proper web standard. No other browser has bothered implementing it, though.

https://wicg.github.io/scroll-to-text-fragment/

PDFs also support `#page=42`.

https://helpx.adobe.com/acrobat/kb/link-html-pdf-page-acrobat.html

From petite.abeille at gmail.com  Tue Dec 22 23:46:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 00:46:09 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <20201222233845.GZ9267@brevard.conman.org>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
 <20201222233845.GZ9267@brevard.conman.org>
Message-ID: <A601DB3C-4BE0-4531-AAE1-38D9BB3D19CC@gmail.com>



> On Dec 23, 2020, at 00:38, Sean Conner <sean at conman.org> wrote:
> 
>  -spc (See?  Very simple)

Wow. Perhaps text/gemini should have no fragment whatsoever. No fragment in text/gemini, what about that? Simpler for sure.


From petite.abeille at gmail.com  Tue Dec 22 23:48:00 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 00:48:00 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <57C2DD53-0014-4BAB-97A6-4D00563B448D@ngalt.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
 <57C2DD53-0014-4BAB-97A6-4D00563B448D@ngalt.com>
Message-ID: <EE6EAC34-607E-4FAA-BDED-876969D01D18@gmail.com>



> On Dec 23, 2020, at 00:41, Nathan Galt <mailinglists at ngalt.com> wrote:
> 
> Chrome also supports text fragments like `#:~:text=an%20example%20text%20fragment` , and they?re trying to have this feature be a proper web standard. No other browser has bothered implementing it, though.

I can see why not one bothered. For sure no fragment in text/gemini :)

From petite.abeille at gmail.com  Wed Dec 23 00:04:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 01:04:43 +0100
Subject: [tech] Questions about cache
In-Reply-To: <0b292576-54e1-dbe1-75ab-2996a4acd20f@drsudo.com>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
 <20201222225958.GY9267@brevard.conman.org>
 <0b292576-54e1-dbe1-75ab-2996a4acd20f@drsudo.com>
Message-ID: <7F34B2C2-45E7-4E52-93F9-F02C0C3D0C1B@gmail.com>



> On Dec 23, 2020, at 00:31, Stephen <stephen at drsudo.com> wrote:
> 
> cache busting

Wouldn't that be a anti-pattern actually?  Perhaps gemini is not actually meant for such dynamic content at all, beside experimental purpose. Perhaps best to let it go. After all, gemini has no cache control. Why force it?

Let me present you with another anti-pattern, as far as gemini goes:

a gemini page embed a small data: link somewhere, let's call it  'meta', which includes random cache control directives, say, 'refresh=1', just because.

=> data:text;refresh%3D1 meta

When a client sees such construct, it refresh the page after one second.

Wouldn't that be cool?

Yes, I thought so too.






From petite.abeille at gmail.com  Wed Dec 23 00:09:32 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 01:09:32 +0100
Subject: [tech] Questions about cache
In-Reply-To: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
References: <a9d760b7-45b0-fb83-4ee4-72c519699b35@drsudo.com>
Message-ID: <28542890-6BB9-474D-AA37-DA686BF066D8@gmail.com>



> On Dec 22, 2020, at 23:40, Stephen <stephen at drsudo.com> wrote:
> 
> Gemini spec does not mention caching, and the FAQ says:
> 
> > Gemini has no support for caching

Perhaps this should be rewritten as "no support for cache control". This would clear up any ambiguities. The user-agent decides what to do. 




From bie at 202x.moe  Wed Dec 23 00:41:02 2020
From: bie at 202x.moe (bie)
Date: Wed, 23 Dec 2020 09:41:02 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
Message-ID: <20201223004102.GA11078@202x.moe>

On Tue, Dec 22, 2020 at 11:21:38PM +0100, Petite Abeille wrote:
> 
> 
> > On Dec 22, 2020, at 23:18, Sean Conner <sean at conman.org> wrote:
> > 
> >  3. Clients and servers take the hit (both have to support URL and IRI)
> 
> This being a very equalitarian commune, I say this sounds fair: everybody "take the hit" for the greater good. 

Everyone who stays takes the hit, that is.

My "threshold" for complexity is "can I write a conforming, relatively
strict and safe server only relying on the OpenBSD base system". It's
kind of arbitrary, sure, but what isn't.

Mandatory IRI support (and there's no real way to keep it optional,
considering queries) would push the implementation complexity a step too
far for me.

bie

From linde.philip at gmail.com  Wed Dec 23 00:51:20 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Wed, 23 Dec 2020 01:51:20 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <20201222233845.GZ9267@brevard.conman.org>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
 <20201222233845.GZ9267@brevard.conman.org>
Message-ID: <20201223015120.a525869a31818306a48f5170@gmail.com>

On Tue, 22 Dec 2020 18:38:45 -0500
Sean Conner <sean at conman.org> wrote:

>   So here's a totally off-the-cuff spec I'm pulling out of my nether regions
> that seems simple and somewhat robust.

That's only good until the author of the document you link to modifies
it at an inconvenient place. It's only one step removed from defining
the fragment to be a byte offset.

It might be more robust to define the fragment as referring to the
first heading line that has the fragment content as a prefix, but
that's still prone to break with document changes.

In the most flexible of worlds, the fragment is a regular expression
that matches the line it refers to and an index to select one of
potentially many matching lines, but I don't quite like that idea.
There are too many subtly different regex implementations for it to be
practical, and it fundamentally doesn't solve the problem that
expectations will change with the text content of the document.

For a good balance, one might have the fragment be a an exact match of
the heading line you refer to, with simple wildcards like "*" for any
(or no) string of characters and "?" for any one character.

Here it seems that the separation of presentation and rendered content
in HTML is useful. You can change a heading or edit a document and
still refer to parts of it using a set of IDs that remain consistent
through the changes. Lacking that, perhaps one of these more or
less error prone solutions are OK for Gemini, but I tend to agree with
Petite Abeille that fragments should not have a special meaning for
text/gemini.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/48473551/attachment.sig>

From petite.abeille at gmail.com  Wed Dec 23 01:02:06 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 02:02:06 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223004102.GA11078@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
Message-ID: <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>



> On Dec 23, 2020, at 01:41, bie <bie at 202x.moe> wrote:
> 
> My "threshold" for complexity is "can I write a conforming, relatively
> strict and safe server only relying on the OpenBSD base system". It's
> kind of arbitrary, sure, but what isn't.

Fair enough. But what's the showstopper really?

Not sure what the "base system" contains, nor the level at which you interact with it, but it lists Perl as one of its component. Which could handle IRIs*.

But if strict ASCII is all what "OpenBSD base system" can do, ever, then so be it. 

On the other hand, one can always, you know, write such IRI parser on their own. It has been done before. There must be a C compiler somewhere in that base system, no?

* https://metacpan.org/pod/IRI


From bie at 202x.moe  Wed Dec 23 01:37:23 2020
From: bie at 202x.moe (bie)
Date: Wed, 23 Dec 2020 10:37:23 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
Message-ID: <20201223013723.GA90439@202x.moe>

On Wed, Dec 23, 2020 at 02:02:06AM +0100, Petite Abeille wrote:
> 
> 
> > On Dec 23, 2020, at 01:41, bie <bie at 202x.moe> wrote:
> > 
> > My "threshold" for complexity is "can I write a conforming, relatively
> > strict and safe server only relying on the OpenBSD base system". It's
> > kind of arbitrary, sure, but what isn't.
> 
> Fair enough. But what's the showstopper really?
> 
> Not sure what the "base system" contains, nor the level at which you interact with it, but it lists Perl as one of its component. Which could handle IRIs*.
> 
> But if strict ASCII is all what "OpenBSD base system" can do, ever, then so be it. 
> 
> On the other hand, one can always, you know, write such IRI parser on their own. It has been done before. There must be a C compiler somewhere in that base system, no?
> 
> * https://metacpan.org/pod/IRI

Should have specified the language (C), too. I'm not going to be pulling
in perl, and writing a full-fledged IRI parser from scratch in C sounds
profoundly uncomfortable.

In any case, it's not about what's possible, just a purely personal
opinion about where gemini gets too complex to be fun. I'm not expecting
anyone to share my exact preferences, just putting it out there as a
single anecdotal data point (from someone who so far has been serving
mostly non-ascii content over gemini with no real problems or complaints)

bie

From petite.abeille at gmail.com  Wed Dec 23 01:49:34 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 02:49:34 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223013723.GA90439@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
Message-ID: <F53A7352-39A6-4C75-A118-B1DA35467588@gmail.com>


> On Dec 23, 2020, at 02:37, bie <bie at 202x.moe> wrote:
> 
> Should have specified the language (C), too. I'm not going to be pulling
> in perl, and writing a full-fledged IRI parser from scratch in C sounds
> profoundly uncomfortable.

Fair enough. And libcurl is of no help either? Or HTParse.c?

> in any case, it's not about what's possible, just a purely personal
> opinion about where gemini gets too complex to be fun.

Ok. Different pain thresholds I guess.


From petite.abeille at gmail.com  Wed Dec 23 01:53:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 02:53:43 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <F53A7352-39A6-4C75-A118-B1DA35467588@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <F53A7352-39A6-4C75-A118-B1DA35467588@gmail.com>
Message-ID: <66D331E8-ECE1-47DB-9678-F9924FDFBC74@gmail.com>



> On Dec 23, 2020, at 02:49, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> And libcurl is of no help either? Or HTParse.c?

Or https://uriparser.github.io , no use either?




From petite.abeille at gmail.com  Wed Dec 23 02:10:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 03:10:58 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223013723.GA90439@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
Message-ID: <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>



> On Dec 23, 2020, at 02:37, bie <bie at 202x.moe> wrote:
> 
>  (from someone who so far has been serving
> mostly non-ascii content over gemini with no real problems or complaints)

Got to say, I don't get it. 

You have a perfectly functional gemini server running on openbsd, handcrafted in C, serving unicode content without a fuss, handling URIs, and the whole shebang, but suddenly IRIs push you over the brink?!

This doesn't add up.

But ok. To each their own.


From bie at 202x.moe  Wed Dec 23 02:54:16 2020
From: bie at 202x.moe (bie)
Date: Wed, 23 Dec 2020 11:54:16 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
Message-ID: <20201223025416.GA25066@202x.moe>

On Wed, Dec 23, 2020 at 03:10:58AM +0100, Petite Abeille wrote:
> 
> 
> > On Dec 23, 2020, at 02:37, bie <bie at 202x.moe> wrote:
> > 
> >  (from someone who so far has been serving
> > mostly non-ascii content over gemini with no real problems or complaints)
> 
> Got to say, I don't get it. 
> 
> You have a perfectly functional gemini server running on openbsd, handcrafted in C, serving unicode content without a fuss, handling URIs, and the whole shebang, but suddenly IRIs push you over the brink?!
> 
> This doesn't add up.

Why doesn't it add up?

My server doesn't have to know anything about unicode to serve a text
file, just like it doesn't have to be able to parse JPEGs to serve
images. IRIs means it *does* have to know something about unicode, which
ucs characters are valid IRI characters, that the "private" UCS are only
valid in the query part etc etc.

bie

From me at shadowfacts.net  Wed Dec 23 02:55:34 2020
From: me at shadowfacts.net (Shadowfacts)
Date: Tue, 22 Dec 2020 21:55:34 -0500
Subject: [Users] [ANN] Rocketeer for iOS Major Update
Message-ID: <315E44BB-F5D1-439A-9DC5-296F9CAE51B6@shadowfacts.net>

Hi all,

A few months ago I released the first public build of my iOS browser for Gemini called Rocketeer. Following feedback, I?ve completely rewritten the UI layer. Rocketeer now supports edge-swipe gestures for back and forwards navigation, context menu previews, text selection, a table of contents, and displaying images! Additionally a whole bunch of bugs have been fixed, notably redirects not being followed in some circumstances.

There are still a bunch of features yet to come, including multi-window support on iPad, bookmarks, home page customization, and a Mac version!

If you?d previously installed it, you can update from the TestFlight app (and you should soon; the current build will expire in just 7 days). If you?d like to try it out, follow the instructions here: https://testflight.apple.com/join/LAs1URxM <https://testflight.apple.com/join/LAs1URxM>.

In related news, TestFlight recently gained support for automatic app updates, so you won?t have to risk the app expiring on you. As such, this should be the last time I email the list until the full-on App Store release.

As before, if you run into any issues or have other feedback, I want to hear about it! You can email me at this address or get in touch on the fediverse (I?m @shadowfacts at social.shadowfacts.net).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201222/17902463/attachment.htm>

From bjorn.warmedal at gmail.com  Wed Dec 23 07:35:38 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Wed, 23 Dec 2020 08:35:38 +0100
Subject: [tech] Questions about cache
In-Reply-To: <28542890-6BB9-474D-AA37-DA686BF066D8@gmail.com>
References: <28542890-6BB9-474D-AA37-DA686BF066D8@gmail.com>
Message-ID: <63CB6D7E-3456-4FD1-8BAF-C26F2EDCF240@gmail.com>


>> Gemini spec does not mention caching, and the FAQ says:
>> 
>>> Gemini has no support for caching
> 
> Perhaps this should be rewritten as "no support for cache control". This would clear up any ambiguities. The user-agent decides what to do. 

Very much this. How, when and for how long a browser caches is first and foremost a UI/UX question. The browser should act as the user expects, and may work to change those expectations (i.e a specialized browser that behaves in a very specific manner may describe its usage case and consequences in documentation).

Us authors have little control over how our content is fetched, displayed, or otherwise consumed.

On an Amfora-related note: makeworld talked about the caching on IRC the other day, and another user brought up that it seemed like Amfora presented cached content when a previously-visited link was clicked. Makeworld commented that this was unintended, and said they would fix it for a later release. (At least that?s how I remember it; maybe makeworld can weigh in.)

Cheers,
ew0k

Sent from my smart speaker

From petite.abeille at gmail.com  Wed Dec 23 08:45:03 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 09:45:03 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223025416.GA25066@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
Message-ID: <4F899845-78F4-4090-95B4-54B180B06D9E@gmail.com>



> On Dec 23, 2020, at 03:54, bie <bie at 202x.moe> wrote:
> 
> My server doesn't have to know anything about unicode to serve a text
> file, just like it doesn't have to be able to parse JPEGs to serve
> images. IRIs means it *does* have to know something about unicode, which
> ucs characters are valid IRI characters, that the "private" UCS are only
> valid in the query part etc etc.

Ok, so Unicode again. Fair enough. Where is Plan9 when you need it. Sigh.


From petite.abeille at gmail.com  Wed Dec 23 09:33:01 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 10:33:01 +0100
Subject: Plan9? (was Re: [spec] IRIs, IDNs, and all that international jazz)
In-Reply-To: <4F899845-78F4-4090-95B4-54B180B06D9E@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
 <4F899845-78F4-4090-95B4-54B180B06D9E@gmail.com>
Message-ID: <257BE778-64CA-45C3-A699-4E6CBD4ECAEA@gmail.com>



> On Dec 23, 2020, at 09:45, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Ok, so Unicode again. Fair enough. Where is Plan9 when you need it. Sigh.

While at it, anyone running gemini on Plan9? 

https://9p.io/plan9/

Or perhaps even using Plan 9 from User Space somehow for gemini?

https://9fans.github.io/plan9port/

From roy at royniang.com  Wed Dec 23 09:34:52 2020
From: roy at royniang.com (roy niang)
Date: Wed, 23 Dec 2020 10:34:52 +0100
Subject: =?UTF-8?Q?Re:_Plan9=3F_(was_Re:_[spec]_IRIs, _IDNs,
 _and_all_that_internat?= =?UTF-8?Q?ional_jazz)?=
In-Reply-To: <257BE778-64CA-45C3-A699-4E6CBD4ECAEA@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
 <4F899845-78F4-4090-95B4-54B180B06D9E@gmail.com>
 <257BE778-64CA-45C3-A699-4E6CBD4ECAEA@gmail.com>
Message-ID: <23432c23-efb6-4670-861b-b7d2ff9f1f24@www.fastmail.com>

I read that molly brown works on 9front.

From julien at typed-hole.org  Wed Dec 23 09:47:31 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Wed, 23 Dec 2020 10:47:31 +0100
Subject: Plan9? (was Re: [spec] IRIs, IDNs,
 and all that international jazz)
In-Reply-To: <257BE778-64CA-45C3-A699-4E6CBD4ECAEA@gmail.com>
References: <257BE778-64CA-45C3-A699-4E6CBD4ECAEA@gmail.com>
Message-ID: <664DA9E6-CBBB-4359-8BC2-08C5FDA0026A@typed-hole.org>


> Le 23 d?c. 2020 ? 10:33, Petite Abeille <petite.abeille at gmail.com> a ?crit :
> 
> While at it, anyone running gemini on Plan9?
> 
> https://9p.io/plan9/
> 
> Or perhaps even using Plan 9 from User Space somehow for gemini?
> 
> https://9fans.github.io/plan9port/

Yes! gemini://9til.de is powered by Molly Brown on 9front (a plan9 fork).

?
julienxx

From marcx2 at welz.org.za  Wed Dec 23 10:00:58 2020
From: marcx2 at welz.org.za (marc)
Date: Wed, 23 Dec 2020 11:00:58 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223004102.GA11078@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
Message-ID: <20201223100058.GA6184@localhost.localdomain>

Hi

> My "threshold" for complexity is "can I write a conforming, relatively
> strict and safe server only relying on the OpenBSD base system". It's
> kind of arbitrary, sure, but what isn't.
> 
> Mandatory IRI support (and there's no real way to keep it optional,
> considering queries) would push the implementation complexity a step too
> far for me.

TLDR:

I am with bie on the matter. Option 3 is a bridge
too far for me too.

Wall Of Text:

So I value the decency which wants to include all 
human languages in the gemini ecosystem.

But in an effort to be inclusive in one dimension
one ends up being exclusive in another dimension,
namely in the space of computer languages/host
operating systems.

It is one thing to find full I8N support in a language
such as python (slow batteries included), but what
about minorities such tcl, lua, m4 or sed ?

Protocols define the interactions between
computers. Computers don't speak any human language
all, they are programmed in computer languages. And so
it strikes me as weird to embed the (combinatorial)
complexity of human languages deep in the protocol
stack, but risk excluding niche computer languages or
operating system... which in some cases are just
one man efforts.

While the OSI 7 layer network model has its
deficiencies ("all models are wrong, some are
useful"), it does help us think about a network,
from inconvenienced electrons at the lowest layer to
high level abstractions at the top.

I think internationalisation concern belong in the
very highest level of a stack. You expect me to
say presentation or application-level, but remember
the OSI model is wrong (For instance, things like HTTP
or gemini are typically lumped into one application
layer, when there many layers to them). The actual
highest level is the naive computer uses who gets told
to "move the mouse over this and then click on this,
like so...". At that level, it might make sense for
a gemini browser to be fully localised, and render an
url in the local language (maybe even left to right,
or top to bottom).

But even the layer just below that (the competent user
level) this starts leaking. A gemini url starts with
"gemini://" - that is ascii text, and even funnier,
taken from latin. If a non-english user is confused by
english (nay, latin, with no native speakers at all)
words, then surely "gemini://" has to be rewritten as
"tweling://" or "zwilling://" or whatever farsi,
japanese or mongolian use for "twin". If not, then an
full ascii text url should be manageable too... an
url is primarily a computer address.

Long ago I came across a version of (I think it was) Pascal
had been localised into french with language keywords
like "begin" and "if" replaced. I am sure somebody can
justify this somehow, but I thought this was an impediment
to interoperability, and view the internationalising
of computer protocols (as opposed to the user interfaces) 
in a similar way.

regards

marc

From petite.abeille at gmail.com  Wed Dec 23 10:45:40 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 11:45:40 +0100
Subject: Plan9? (was Re: [spec] IRIs, IDNs, and all that international
 jazz)
In-Reply-To: <664DA9E6-CBBB-4359-8BC2-08C5FDA0026A@typed-hole.org>
References: <257BE778-64CA-45C3-A699-4E6CBD4ECAEA@gmail.com>
 <664DA9E6-CBBB-4359-8BC2-08C5FDA0026A@typed-hole.org>
Message-ID: <394261C6-707B-4292-BB08-433027DC986D@gmail.com>



> On Dec 23, 2020, at 10:47, Julien Blanchard <julien at typed-hole.org> wrote:
> 
> Yes! gemini://9til.de is powered by Molly Brown on 9front (a plan9 fork).

Wicked! In a very good way :)

Any client side niftiness?

From julien at typed-hole.org  Wed Dec 23 11:02:48 2020
From: julien at typed-hole.org (Julien Blanchard)
Date: Wed, 23 Dec 2020 12:02:48 +0100
Subject: Plan9? (was Re: [spec] IRIs, IDNs,
 and all that international jazz)
In-Reply-To: <394261C6-707B-4292-BB08-433027DC986D@gmail.com>
References: <394261C6-707B-4292-BB08-433027DC986D@gmail.com>
Message-ID: <9C5DFA9A-DE7F-4C56-8BD3-15AB1FE20B33@typed-hole.org>


> Le 23 d?c. 2020 ? 11:45, Petite Abeille <petite.abeille at gmail.com> a ?crit :
> 
> Wicked! In a very good way :)
> 
> Any client side niftiness?

Of course, there are (to my knowledge) gemnine https://git.sr.ht/~ft/gemnine and my own castor9 https://git.sr.ht/~julienxx/castor9

?
julienxx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/1b25a8ca/attachment.htm>

From petite.abeille at gmail.com  Wed Dec 23 11:18:36 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 12:18:36 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223100058.GA6184@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
Message-ID: <5463C61A-4CC9-48E5-BFCE-6021871E2A91@gmail.com>



> On Dec 23, 2020, at 11:00, marc <marcx2 at welz.org.za> wrote:
> 
> TLDR:
> 
> I am with bie on the matter. Option 3 is a bridge
> too far for me too.
> 
> Wall Of Text:

Actually, I do have sympathy for your position. And, yes, you are technically correct. The best kind of correct. No arguments here.

Unicode is a big pill to swallow. This is why we have been stuck with ASCII for so long. And yes, technically, everything can be transcoded back and forth between ASCII and The World.

Machines talking to machines. 

But, personally, I think this is missing the bigger picture about what Gemini is about.

It's not purely a technical endeavor. 

After all -as people keep pointing out ad nauseam- if you want gopher/http/whatnot, you know where to find them.

Gemini has a humanistic stride to it. Some poetry, dare I say. Esthetics matters. A human touch matters.

This is why Unicode matters. It's the human face of a technology. This counts for something.

As someone used to say: "Technology alone is not enough". This should strike a cord with a community rooted in gopher, of all things. Gopher is not a "technology", it's a community, in the best sense of the term: people talking and sharing with other people. An exchange of ideas.

This is what Gemini cares about: people. Not technology. Even if technology is necessary to achieve its humanistic goals.

It's therefore my opinion that technologists like us should make the extra effort to make our technology  as human friendly as possible. Even if this cost us something. We can do it. For the community.

?The details are not the details; they are the product?
-- Charles and Ray Eames 





From petite.abeille at gmail.com  Wed Dec 23 11:28:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 12:28:48 +0100
Subject: Plan9? (was Re: [spec] IRIs, IDNs, and all that international
 jazz)
In-Reply-To: <9C5DFA9A-DE7F-4C56-8BD3-15AB1FE20B33@typed-hole.org>
References: <394261C6-707B-4292-BB08-433027DC986D@gmail.com>
 <9C5DFA9A-DE7F-4C56-8BD3-15AB1FE20B33@typed-hole.org>
Message-ID: <2E3C1209-5BC8-41DE-9F6F-33E58E31E72C@gmail.com>



> On Dec 23, 2020, at 12:02, Julien Blanchard <julien at typed-hole.org> wrote:
> 
> 
>> Le 23 d?c. 2020 ? 11:45, Petite Abeille <petite.abeille at gmail.com> a ?crit :
>> 
>> Wicked! In a very good way :)
>> 
>> Any client side niftiness?
> 
> Of course, there are (to my knowledge) gemnine https://git.sr.ht/~ft/gemnine and my own castor9 https://git.sr.ht/~julienxx/castor9
> 

Double wicked! Always had a soft spot for plan9 :)

From gemini#lists.orbitalfox.eu#v1 at kaction.cc  Wed Dec 23 11:54:40 2020
From: gemini#lists.orbitalfox.eu#v1 at kaction.cc (Dmitry Bogatov)
Date: Wed, 23 Dec 2020 11:54:40 GMT
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223025416.GA25066@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
Message-ID: <X+MwDURqs61cZKaC@void>

On Wed, Dec 23, 2020 at 11:54:16AM +0900, bie wrote:
> My server doesn't have to know anything about unicode to serve a text
> file, just like it doesn't have to be able to parse JPEGs to serve
> images. IRIs means it *does* have to know something about unicode,
> which ucs characters are valid IRI characters, that the "private" UCS
> are only valid in the query part etc etc.

Exactly. Do not push insance complexity of Unicode on everybody,
including those who do not need it. Good thing about current state of
affairs is that server can treat unicode as opaque bytestring, and
client does not need to be aware of unicode either: to locate links
plain

	strstr(gmi, "=>")

is enough, and client can just dump response to stdout, and let terminal
driver to deal with that. Or not deal.

Anything but option #1 is too much complexity in my opinion.

By the way, I really don't understand all this fuss about Unicode links.
Seriously, why? We have

	$ rm --recursive --no-preserve-root /*

for generations, and nobody bothered to "internalized" it into something
like

	$ ?? --?????????? --??-?????????-?????? /*


From petite.abeille at gmail.com  Wed Dec 23 12:01:21 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 13:01:21 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <X+MwDURqs61cZKaC@void>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <X+MwDURqs61cZKaC@void>
Message-ID: <63D459BB-56E4-4321-BFEF-3438C933CD3A@gmail.com>



> On Dec 23, 2020, at 12:54, Dmitry Bogatov <gemini#lists.orbitalfox.eu#v1 at kaction.cc> wrote:
> 
> By the way, I really don't understand all this fuss about Unicode links.

That's perfectly fine. As adults, we should be able to hold and comprehend two divergent ideas at the same time. We can agree to disagree. 

It's not about who is "right". Both side are correct. They just have different values.

It's a choice. That's all.

From shawn at provisoire.ca  Wed Dec 23 13:38:24 2020
From: shawn at provisoire.ca (Shawn Nock)
Date: Wed, 23 Dec 2020 13:38:24 GMT
Subject: Plan9? (was Re: [spec] IRIs, IDNs,
 and all that international jazz)
In-Reply-To: <257BE778-64CA-45C3-A699-4E6CBD4ECAEA@gmail.com>
Message-ID: <F94332A16EFFC8CD70409112630913DB@provisoire.ca>

>> On Dec 23, 2020, at 09:45, Petite Abeille <petite.abeille at gmail.com> wrote:
> While at it, anyone running gemini on Plan9? 

gemini://provisoire.ca/ (quite new, little content) is hosted on Plan9
via rc-gemd and I use castor9 as my primary client.


S
-- 
Shawn Nock <shawn at provisoire.ca>


From mbays at sdf.org  Wed Dec 23 14:00:09 2020
From: mbays at sdf.org (mbays at sdf.org)
Date: Wed, 23 Dec 2020 15:00:09 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <20201223140009.qkdbaj53uibutp2e@localhost>

* Tuesday, 2020-12-22 at 16:13 +0100 - Solderpunk <solderpunk at posteo.net>:

>What I'd be most interested in hearing, at this point, is client 
>authors letting me know whether the standard library in the language 
>their client is implemented in can straightforwardly:
>
>1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
>   technically not URLs at all, you know what I mean) in paths and/or
>   domains?
>2. Transform back and forth between URIs and IRIs?
>3. Do DNS lookups of IDNs without them being punycoded first?  You can
>   test this with r?ksm?rg?s.josefsson.org.

I've looked into the situation in Haskell. It isn't nearly as good as 
I'd expected. The standard uri library 'network-uri' is strictly 3986. 
There is an 'iri' library, but it isn't widely used and doesn't seem to 
be very actively maintained: I can't even get it to install with recent 
ghc (ghc-8.8.4). It only deals with parsing and rendering, afaict 
there's no normalisation or "absolutising", nor anything on transforming 
between URIs and IRIs.

As for question 3, the answer appears to be no. In ghci:
> :set -package network
package flags have changed, resetting and loading new packages...
> import Network.Socket
> getAddrInfo (Just $ defaultHints {addrSocketType = Stream}) (Just "r?ksm?rg?s.josefsson.org") (Just "1965")
*** Exception: Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 0, addrAddress = 0.0.0.0:0, addrCanonName = Nothing}, host name: Just "r\228ksm\246rg\229s.josefsson.org", service name: Just "1965"): does not exist (Name or service not known)

So library support isn't perfect. However: converting between 
utf8-encoded IRIs and URIs seems pretty trivial to implement by hand 
(Step 2 in section 3.1 of the rfc, and its inverse), and there are 
punycode implementations in standard haskell libraries (e.g. in the 
'encoding' package), so I am not at all scared by option 3. I'd just 
convert IRIs to URIs for internal use and manipulation, then convert 
back when displaying, and punycode when making requests. I'm not sure 
I'm not being naive here -- someone please explain the subtleties (or 
tell me to read the existing threads on this more carefully) if so!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/ee90c268/attachment.sig>

From petite.abeille at gmail.com  Wed Dec 23 14:57:25 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 15:57:25 +0100
Subject: [user] macos client with a sense of aesthetics?
Message-ID: <04D8DDFD-DC82-430B-B8B0-83DFDFF62068@gmail.com>

Specifically typography. Voluptuous typography. As well as a good command of information design.

What would people recommend?

Lagrange was mentioned at time. Anything else worthwhile checking out?

Thanks.

From moody at posixcafe.org  Wed Dec 23 15:16:23 2020
From: moody at posixcafe.org (Jacob Moody)
Date: Wed, 23 Dec 2020 09:16:23 -0600
Subject: Plan9? (was Re: [spec] IRIs, IDNs, and all that international
 jazz)
In-Reply-To: <F94332A16EFFC8CD70409112630913DB@provisoire.ca>
References: <F94332A16EFFC8CD70409112630913DB@provisoire.ca>
Message-ID: <47259645-fa4e-b48d-1394-0cc57dcce514@posixcafe.org>

On Dec 23, 2020, at 09:45, Petite Abeille <petite.abeille at gmail.com> wrote:
> While at it, anyone running gemini on Plan9?

Yes my site[0] is run using my own rc-gemd[1] on 9front. For a client I
generally use gemnine. It should be possible to use rc-gemd from
plan9port but you would need some sort of UNIX tlsserver and aux/listen1.

On 12/23/20 7:38 AM, Shawn Nock wrote:
> gemini://provisoire.ca/ (quite new, little content) is hosted on Plan9
> via rc-gemd and I use castor9 as my primary client.

I am very happy you were able to make use of rc-gemd ?


Cheers,
Moody

[0] gemini://posixcafe.org
[1] http://shithub.us/git/moody/rc-gemd/HEAD/info.html

From jmcbray at carcosa.net  Wed Dec 23 16:05:18 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 23 Dec 2020 11:05:18 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar> (solderpunk@posteo.net's
 message of "Tue, 22 Dec 2020 16:13:06 +0100")
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <87o8ikh5j5.fsf@dorothy.carcosa.net>

"Solderpunk" <solderpunk at posteo.net> writes:

Answering for Common Lisp, as best I know (I'm kind of a n00b). Detailed
Common Lisp spam below, skip if you are afraid of parentheses.

> 1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
>    technically not URLs at all, you know what I mean) in paths and/or
>    domains?

No URI handling in the standard library, but quicklisp has libraries for
it. I'm using quri, which I think is the most used, and it seems to be
fine.

CL-USER> (defparameter *my-iri* (quri:uri "gemini://r?ksm?rg?s.josefsson.org/?/?.gmi"))
*MY-IRI*

CL-USER> *my-iri*
#<QURI.URI:URI gemini://r?ksm?rg?s.josefsson.org/?/?.gmi>

CL-USER> (quri:uri-domain *my-iri*)
"josefsson.org"

CL-USER> (quri:uri-authority *my-iri*)
"r?ksm?rg?s.josefsson.org"

CL-USER> (quri:uri-path *my-iri*)
"/?/?.gmi"

CL-USER> (quri:uri-query *my-iri*)
NIL

CL-USER> (setf (quri:uri-path *my-iri*) "?/?.gmi")
"?/?.gmi"

CL-USER> (quri:uri-path *my-iri*)
"?/?.gmi"

> 2. Transform back and forth between URIs and IRIs?

Using idna package in quicklisp on the hostname:

CL-USER> (idna:to-ascii (quri:uri-authority *my-iri*))
"xn--rksmrgs-5wao1o.josefsson.org"

CL-USER> (idna:to-unicode (idna:to-ascii (quri:uri-authority *my-iri*)))
"r?ksm?rg?s.josefsson.org"

And URL-encoding on the path:

CL-USER> (quri:url-encode (quri:uri-path *my-iri*))
"%F0%9F%90%87%2F%F0%9F%90%B0.gmi"

And decoding the path:

CL-USER> (quri:url-decode (quri:url-encode (quri:uri-path *my-iri*)))
"?/?.gmi"

I will note, however, that (quri:url-decode "?/?.gmi") produces
garbage, which means on the server I can't use the library to fix up the
space in "?/?%20?.gmi" when getting the filename for the IRI, and
will have to write a unicode-safe function to handle decoding just
IRI reserved characters.

Putting these together into a function and handling edge-cases is
something I'll do if it turns out I have to.

> 3. Do DNS lookups of IDNs without them being punycoded first?  You can
>    test this with r?ksm?rg?s.josefsson.org.

The CL standard library is actually so old it doesn't have
sockets/gethostbyname. But everyone uses usocket, which is in quicklisp:

CL-USER> (usocket:get-host-by-name (quri:uri-authority *my-iri*))
#(178 174 241 102)

So that works, without punycoding, at least in my environment (sbcl
2.0.1, Linux 5.8.18, Fedora 33). It might be worth someone trying sbcl
on a BSD to see if their resolver behaves differently.

> Getting good data on all three of these questions for a wide range
> of languages is necessary to make a well-informed decision here.

Personally, I would be most gratified if option 3 proved to be workable.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From petite.abeille at gmail.com  Wed Dec 23 16:26:20 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 17:26:20 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <87o8ikh5j5.fsf@dorothy.carcosa.net>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <87o8ikh5j5.fsf@dorothy.carcosa.net>
Message-ID: <16E53E60-F80F-45FE-860D-EAD9B258E05D@gmail.com>



> On Dec 23, 2020, at 17:05, Jason McBrayer <jmcbray at carcosa.net> wrote:
> 
>> Getting good data on all three of these questions for a wide range
>> of languages is necessary to make a well-informed decision here.
> 
> Personally, I would be most gratified if option 3 proved to be workable.

Adding my 2?... as a Lua aficionado -with its longstanding DIY ethos- I see no issues whatsoever.

Also, kudos to Sean Conner for being the standard-bearer for Lua in the Gemini space.

I'm personally always in awe at his mastery of Parsing Expression Grammars. A work of true beauty. 

Thanks Sean! :)

From bie at 202x.moe  Wed Dec 23 16:31:42 2020
From: bie at 202x.moe (bie)
Date: Thu, 24 Dec 2020 01:31:42 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <20201223163142.GA88927@202x.moe>

On Tue, Dec 22, 2020 at 04:13:06PM +0100, Solderpunk wrote:
> It's true that this would be a breaking change, although of a different
> kind from other breaking changes I've pushed back against in the past.
> It's not as if Geminispace would suddenly become impossible to access,
> or would split into two totally incompatible subspaces based on the
> old and new protocol versions.  Any currently extant Gemini document
> which included ASCII-only links would remain perfectly accessible
> by old and new clients alike.  So, it's a relatively soft break.
> Given the importance of first-class internationalisation support,
> it might be worthwhile.

It's only a soft break if you don't consider the query string.

Even if all the names on my server are ASCII only, a change to IRIs
means I'll be forced to update my server to remain compatible since I
have dynamic scripts that accept content through the query string.

Solution 3 is a "hard no" for me - the increased complexity is not
something I'm willing to take on, and I'll most likely just end up
shutting down my servers.

bie

From jmcbray at carcosa.net  Wed Dec 23 16:34:46 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Wed, 23 Dec 2020 11:34:46 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201222221828.GX9267@brevard.conman.org> (Sean Conner's message
 of "Tue, 22 Dec 2020 17:18:28 -0500")
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
Message-ID: <87h7och461.fsf@dorothy.carcosa.net>

Sean Conner <sean at conman.org> writes:

>   1. Status quo
>   2. Clients take the hit (have to support both URL and IRI)
>   3. Clients and servers take the hit (both have to support URL and IRI)

Looking at 2, servers still have to take a hit here.

i. They need to de-punycode the hostname to compare it to configured
   virtual host names (unless virtual host names are configured in
   punycode).

ii. They need to url-decode the path in order to find matching file
    names; they have to do this already to handle reserved characters,
    though.

So the support needed for servers is possibly similar between 2 and 3.
Clients are hit a little harder by 2.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

From petite.abeille at gmail.com  Wed Dec 23 16:43:23 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 17:43:23 +0100
Subject: Plan9? (was Re: [spec] IRIs, IDNs, and all that international
 jazz)
In-Reply-To: <F94332A16EFFC8CD70409112630913DB@provisoire.ca>
References: <F94332A16EFFC8CD70409112630913DB@provisoire.ca>
Message-ID: <D05713FC-63E6-4300-A78C-A28ABAD8B01E@gmail.com>



> On Dec 23, 2020, at 14:38, Shawn Nock <shawn at provisoire.ca> wrote:
> 
> gemini://provisoire.ca/ 

Lovely domain name.

 /provisoire/ adjectif Qui existe, se fait en attendant autre chose, ou d'?tre remplac?.


From petite.abeille at gmail.com  Wed Dec 23 16:48:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 23 Dec 2020 17:48:47 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223163142.GA88927@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <20201223163142.GA88927@202x.moe>
Message-ID: <3124B64F-56AF-4258-A1F7-7B6C5405B376@gmail.com>



> On Dec 23, 2020, at 17:31, bie <bie at 202x.moe> wrote:
> 
> Solution 3 is a "hard no" for me - the increased complexity is not
> something I'm willing to take on, and I'll most likely just end up
> shutting down my servers.

It is what it is.


From stephane at sources.org  Wed Dec 23 18:35:49 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Wed, 23 Dec 2020 19:35:49 +0100
Subject: The problem with unusual ports
Message-ID: <20201223183549.GA2041638@laperouse.bortzmeyer.org>

Currently at a very nice hotel, with a great breakfast but a WiFi
networks which allows only ports 80 and 443. As a result, I need to
tunnel all the Gemini traffic :-(

(By the way, it seems there is currently no Gemini client with SOCKS
support?)

From cowan at ccil.org  Wed Dec 23 18:39:34 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 23 Dec 2020 13:39:34 -0500
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <20201223015120.a525869a31818306a48f5170@gmail.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com> <20201222233845.GZ9267@brevard.conman.org>
 <20201223015120.a525869a31818306a48f5170@gmail.com>
Message-ID: <CAD2gp_SsKjjQpk=yUJSvaouWBNOjJU1ksX2Vzt4y=fDpNMvqFw@mail.gmail.com>

On Tue, Dec 22, 2020 at 7:51 PM Philip Linde <linde.philip at gmail.com> wrote:


> It might be more robust to define the fragment as referring to the
> first heading line that has the fragment content as a prefix, but
> that's still prone to break with document changes.
>

Even HTML fragments break if their referents are deleted.  Nothing is
completely immune.

> For a good balance, one might have the fragment be a an exact match of
> the heading line you refer to
>

That's reasonable, but I think a prefix match would suffice; that way you
aren't tempted to make headings overly short in order to keep fragments
small.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
In politics, obedience and support are the same thing.  --Hannah Arendt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/416d9569/attachment.htm>

From colecmac at protonmail.com  Wed Dec 23 18:54:15 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 23 Dec 2020 18:54:15 +0000
Subject: The problem with unusual ports
In-Reply-To: <20201223183549.GA2041638@laperouse.bortzmeyer.org>
References: <20201223183549.GA2041638@laperouse.bortzmeyer.org>
Message-ID: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>

I've experienced the same thing, very annoying. I made an issue for SOCKS
in Amfora, it should be easy to implement.

https://github.com/makeworld-the-better-one/amfora/issues/155

Another interesting way to solve this would be to have a Gemini proxy
server running on port 443. That's easier to set up (once someone writes
one, ha), and will work with Amfora today.

Cheers,
makeworld



From lambdatronic at disroot.org  Wed Dec 23 20:18:41 2020
From: lambdatronic at disroot.org (Gary Johnson)
Date: Wed, 23 Dec 2020 15:18:41 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <87o8ikh5j5.fsf@dorothy.carcosa.net>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <87o8ikh5j5.fsf@dorothy.carcosa.net>
Message-ID: <871rfgb7j2.fsf@disroot.org>

Although my server is written in Clojure, I'm leveraging the Java
standard libraries in Space Age since there is little value in
reinventing the wheel here.

In Java world, URIs can be parsed and generated with java.net.URI. This
class accepts URIs with Unicode characters in the path, query, and
fragment segments. However, it will throw an exception if Unicode
characters are included in the domain name.

Conversion between Unicode and punycode can be done with java.net.IDN.

```
Clojure 1.10.1
user=> (import 'java.net.IDN)
java.net.IDN
user=> (IDN/toUnicode "xn--9dbne9b.com")
"????.com"
user=> (IDN/toASCII "????.com")
"xn--9dbne9b.com"
```

Easy peasy.

Sadly, there is no java.net.IRI.

So if we went with options 2 or 3, I would need to manually parse the
Gemini request into segments (not particularly challenging, of course).
Then I could use java.net.IDN to perform punycode-to-Unicode or
Unicode-to-punycode encoding (depending on whether we went with option 2
or 3) to perform robust virtual hostname lookups (and presumably SNI
verification as well).

Finally, I'd need to use java.net.URI to combine the punycoded domain
name back with the path, query, and fragment segments into a valid URI
that I could then parse and percent-decode without throwing an
exception.

All of this should be doable with a bit of custom logic wrapped around
the Java standard library, so I think either option 2 or 3 should be
technically feasible from my end (or for anyone else using a language
that compiles to Java bytecode).

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From cage-dev at twistfold.it  Wed Dec 23 20:26:24 2020
From: cage-dev at twistfold.it (cage)
Date: Wed, 23 Dec 2020 21:26:24 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
Message-ID: <X+On8FFDHY1qkRBX@kurosawa.casa.net>

On Tue, Dec 22, 2020 at 06:23:51PM +0100, Petite Abeille wrote:
>
>
> > On Dec 22, 2020, at 18:18, cage <cage-dev at twistfold.it> wrote:
> >
> >  (should also percent-encode the path?)
>
> Yes.
>
> The individual path segments actually.
>
> So, given /Foo/Bar/Baz, decompose the path into individual segments Foo, Bar, and Baz, encode these, and reconstruct the path. Easy-peasy.

Seems simple, but i can make mess even with simple things. :)

Thank you! :)
Bye!

From sean at conman.org  Wed Dec 23 21:59:44 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 23 Dec 2020 16:59:44 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <20201223215944.GA9267@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> Feedback welcome, especially if I've overlooked anything, which is
> certainly possible.  What I'd be most interested in hearing, at this
> point, is client authors letting me know whether the standard library
> in the language their client is implemented in can straightforwardly:
> 
> 1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
>    technically not URLs at all, you know what I mean) in paths and/or
>    domains?
> 2. Transform back and forth between URIs and IRIs?
> 3. Do DNS lookups of IDNs without them being punycoded first?  You can
>    test this with r?ksm?rg?s.josefsson.org.

  For C, I'm sure there is code, somewhere, that can parse IRIs, but it's a
matter of finding them.  

  For Lua, the answers are:

	1. Yes.  I had to write some code [1][2], and modify some existing
	   code [3], but Lua now has modules to parse IRI and URIs.

	2. I can do IRI->URL, but not the other way---I have no need of a
	   URL->IRI as of yet.

	3. For my setups (systems I've been able to test), I cannot lookup
	   IDNs as is---I *have* to convert to punycode first.

  -spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/iri.lua

[2]	https://github.com/spc476/lua-conmanorg/blob/master/src/idn.c

[3]	https://github.com/spc476/GLV-1.12556/blob/master/Lua/GLV-1/url-util.lua

From trevor at rocketnine.space  Wed Dec 23 21:53:41 2020
From: trevor at rocketnine.space (Trevor Slocum)
Date: Wed, 23 Dec 2020 21:53:41 GMT
Subject: The problem with unusual ports
In-Reply-To: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>
References: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>
Message-ID: <023af6e4-b2d2-8427-70d2-278706922af6@rocketnine.space>

Someone has written one. :)

gmitohtml is a Gemini proxy server.

https://gitlab.com/tslocum/gmitohtml


From sean at conman.org  Wed Dec 23 22:21:58 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 23 Dec 2020 17:21:58 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223013723.GA90439@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
Message-ID: <20201223222158.GB9267@brevard.conman.org>

It was thus said that the Great bie once stated:
> 
> Should have specified the language (C), too. I'm not going to be pulling
> in perl, and writing a full-fledged IRI parser from scratch in C sounds
> profoundly uncomfortable.

  So what library or code are you using now to parse URIs?

  When I wrote my IRI parser [1] I took my existing URL parser [2], and just
  changed the unreserved rule:

	ASCII:	ALPHA / DIGIT / '-' / '.' / '_' / '~'
	UTF-8:	ALPHA / DIGIT / '-' / '.' / '_' / '~' / utf8

where 'utf8' is any character 128 or higher.  I didn't bother with
restricting the private UCS set to the query because sometimes I think RFC
authors are too concerned with theory [3] than with practice and complicate
things.

  Now the conversion of a domain name to punycode on the other hand ... I
left that to libidn.

  -spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/iri.lua

[2]	https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

[3]	A charitable way of saying "smoking crack."  I mean, RFC-822
	(written in 1982) allows:

		"Look!  I'm smoking some good stuff" (no really its good) @
		berkeley (in California) . edu

	as a valid email address!  (spaces and all) No, really, look it up!

From will at worrbase.com  Wed Dec 23 22:22:25 2020
From: will at worrbase.com (William Orr)
Date: Wed, 23 Dec 2020 22:22:25 +0000 (UTC)
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <CAD2gp_SsKjjQpk=yUJSvaouWBNOjJU1ksX2Vzt4y=fDpNMvqFw@mail.gmail.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
 <20201222233845.GZ9267@brevard.conman.org>
 <20201223015120.a525869a31818306a48f5170@gmail.com>
 <CAD2gp_SsKjjQpk=yUJSvaouWBNOjJU1ksX2Vzt4y=fDpNMvqFw@mail.gmail.com>
Message-ID: <304ec07c-60c1-40a3-a9fd-fe2b8339acf4@worrbase.com>

Wouldn't this be dependent on the other discussion of IRIs, since gemtext can have arbitrary unicode? Also would require clients to NFC normalize the prefix/heading lines before doing the matching.

23 dic. 2020 19:40:00 John Cowan <cowan at ccil.org>:

> 
> 
> On Tue, Dec 22, 2020 at 7:51 PM Philip Linde <linde.philip at gmail.com> wrote:
> ?
>> It might be more robust to define the fragment as referring to the
>> first heading line that has the fragment content as a prefix, but
>> that's still prone to break with document changes.
> 
> Even HTML fragments break if their referents are deleted.? Nothing is completely immune.
>> For a good balance, one might have the fragment be a an exact match of
>> the heading line you refer to
> 
> That's reasonable, but I think a prefix match would suffice; that way you aren't tempted to make headings overly short in order to keep fragments small.
> 
> 
> 
> John Cowan ? ? ? ? ?http://vrici.lojban.org/~cowan ? ? ? ?cowan at ccil.org
> In politics, obedience and support are the same thing. ?--Hannah Arendt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/37924367/attachment.htm>

From luke at marmaladefoo.com  Wed Dec 23 22:44:22 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Wed, 23 Dec 2020 22:44:22 +0000
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <304ec07c-60c1-40a3-a9fd-fe2b8339acf4@worrbase.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
 <20201222233845.GZ9267@brevard.conman.org>
 <20201223015120.a525869a31818306a48f5170@gmail.com>
 <CAD2gp_SsKjjQpk=yUJSvaouWBNOjJU1ksX2Vzt4y=fDpNMvqFw@mail.gmail.com>
 <304ec07c-60c1-40a3-a9fd-fe2b8339acf4@worrbase.com>
Message-ID: <5FE3C846.6070606@marmaladefoo.com>



On 23-Dec-2020 22:22, William Orr wrote:
> Wouldn't this be dependent on the other discussion of IRIs, since 
> gemtext can have arbitrary unicode? Also would require clients to NFC 
> normalize the prefix/heading lines before doing the matching.
>
> 23 dic. 2020 19:40:00 John Cowan <cowan at ccil.org>:
>
>
>
>     On Tue, Dec 22, 2020 at 7:51 PM Philip Linde
>     <linde.philip at gmail.com <mailto:linde.philip at gmail.com>> wrote:
>
>         It might be more robust to define the fragment as referring to
>         the
>         first heading line that has the fragment content as a prefix, but
>         that's still prone to break with document changes.
>
>
>     Even HTML fragments break if their referents are deleted.  Nothing
>     is completely immune.
>
>         For a good balance, one might have the fragment be a an exact
>         match of
>         the heading line you refer to
>
>
>     That's reasonable, but I think a prefix match would suffice; that
>     way you aren't tempted to make headings overly short in order to
>     keep fragments small.
>

How about this scheme:

  - use the full text of the headings only as index points, encoded in a 
simple way and truncated for simplicity

The psuedo code would be:

    marker = take-left (base64 heading) 12

Example, imagine a document having headings and we want to calculate a 
match or a lookup for some heading. Lets say heading text is:

"# This is a heading"

the marker is therefore "IyBUaGlzIGlz"

So a link to that heading would be:

gemini://server/path/to/end/point.gmi#IyBUaGlzIGlz

(or some other value, doesnt have to be 12, but feels about right)

this would have the following advantages:

1. Content-addressable, so quite robust to insertions, deletions 
elsewhere in the document, whereas the offsets/counting schemes are less 
robust. Although as others have pointed out, there is no completely 
robust mechanism that is tolerant of any change to the document.

2. Not too long, but long enough so there is a reasonable likelihood not 
to have too many false positive hits in any document, generally.

3. Easily calculated and fast

4. UI is simple - select the heading (e.g. right click or whatever the 
equivalent gesture would be in your client), and have the client tell 
you the corresponding marker

5. Works with unicode heading content

6. URL friendly

Or maybe some sort of variant on something like this.

Or maybe we just live without them - we can always return to this some 
other time if there really is a pressing user need. Is there really a 
requirement really for this yet?

  - Luke

From sean at conman.org  Wed Dec 23 23:03:19 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 23 Dec 2020 18:03:19 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223100058.GA6184@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
Message-ID: <20201223230319.GC9267@brevard.conman.org>

It was thus said that the Great marc once stated:
> 
> It is one thing to find full I8N support in a language such as python
> (slow batteries included), but what about minorities such tcl, lua, m4 or
> sed ?

  I have Lua covered.  I can't say for the others (other than, you really
use m4?  You are a better man than I am, Gunga Din).

> I think internationalisation concern belong in the very highest level of a
> stack. You expect me to say presentation or application-level, but
> remember the OSI model is wrong (For instance, things like HTTP or gemini
> are typically lumped into one application layer, when there many layers to
> them). The actual highest level is the naive computer uses who gets told
> to "move the mouse over this and then click on this, like so...". At that
> level, it might make sense for a gemini browser to be fully localised, and
> render an url in the local language (maybe even left to right, or top to
> bottom).

  I have to deal with the telephony network at work.  It *is* the OSI seven
layer burrito [1] and even *there* there are baked in assumptions relating
to i18n [2].  Text is limited to ASCII.  Yup.  7-bit US-ASCII it all its
glory.  Anything else requires some very nasty hacks.  Even better, there
does exist a way to relate a name to a phone number, but it's restricted to
just 15 bytes of US-ASCII.  So "Rafaella Gabriela Sarsaparilla" gets cut to
"Rafaella Gabrie".  Lovely, isn't it?

> But even the layer just below that (the competent user level) this starts
> leaking. A gemini url starts with "gemini://" - that is ascii text, and
> even funnier, taken from latin. If a non-english user is confused by
> english (nay, latin, with no native speakers at all) words, then surely
> "gemini://" has to be rewritten as "tweling://" or "zwilling://" or
> whatever farsi, japanese or mongolian use for "twin". If not, then an full
> ascii text url should be manageable too... an url is primarily a computer
> address.

  Sushi comes from Japanese, gesundheit from German, sauna from Finnish,
smorgasbord from Swedish, borscht from Russian and ketchup from China,
what's your point?  All those are perfectly cromulent (from Simpsons) words. 
Modern English sucks up words from all other languages.

  Also, what's the Japanese equivalent of 'https'?  I'm curious.

> Long ago I came across a version of (I think it was) Pascal
> had been localised into french with language keywords
> like "begin" and "if" replaced. 

  It wasn't H?stad [3], was it?  If it was, I made that up to make a point
about LISP.

  But yes, there have been several such localizations in the past for
various languages but they never caught on internationally for some reason. 
One language I heard about, Cornerstone, used a novel method for
identifiers---the visual representation was not part of the code but from a
map---change a variable name in one place, and every place that variable
appeared would change its name.  Pretty cool concept if you ask me.

  -spc

[1]	And a complete pain to work with.  Fortunately, it's becoming less
	and less of an issue as things are transitioning to the Internet,
	but the phone companies are fighting and screaming all the way.

[2]	??t?r??t????l?z?t???

[3]	http://boston.conman.org/2008/01/04.1

From sean at conman.org  Wed Dec 23 23:05:08 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 23 Dec 2020 18:05:08 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <16E53E60-F80F-45FE-860D-EAD9B258E05D@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <87o8ikh5j5.fsf@dorothy.carcosa.net>
 <16E53E60-F80F-45FE-860D-EAD9B258E05D@gmail.com>
Message-ID: <20201223230508.GD9267@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> Also, kudos to Sean Conner for being the standard-bearer for Lua in the
> Gemini space.
> 
> I'm personally always in awe at his mastery of Parsing Expression
> Grammars. A work of true beauty.
> 
> Thanks Sean! :)

  You're welcome.

  -spc (I still seem to be the only one to have a server in Lua)


From linde.philip at gmail.com  Thu Dec 24 01:08:57 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Thu, 24 Dec 2020 02:08:57 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201216150549.GA19202@sources.org>
References: <20201216150549.GA19202@sources.org>
Message-ID: <20201224020857.8e420526073869549e85ea52@gmail.com>

On Wed, 16 Dec 2020 16:05:50 +0100
Stephane Bortzmeyer <stephane at sources.org> wrote:

> I'm running a Gemini crawler, which gathers metadata about the
> geminispace. The goal is not to make a search engine but to survey the
> geminispace.

That's interesting, Stephane. Could you add statistics about character
encodings used for text/gemini responses specifically? I'd like to know
if there are currently text/gemini responses in any other encoding than
UTF-8 (or US ASCII). That would be an interesting topic in the IRI+IDN
discussion.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201224/1204e38c/attachment.sig>

From sean at conman.org  Thu Dec 24 02:01:13 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 23 Dec 2020 21:01:13 -0500
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201224020857.8e420526073869549e85ea52@gmail.com>
References: <20201216150549.GA19202@sources.org>
 <20201224020857.8e420526073869549e85ea52@gmail.com>
Message-ID: <20201224020112.GG9267@brevard.conman.org>

It was thus said that the Great Philip Linde once stated:
> On Wed, 16 Dec 2020 16:05:50 +0100
> Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> > I'm running a Gemini crawler, which gathers metadata about the
> > geminispace. The goal is not to make a search engine but to survey the
> > geminispace.
> 
> That's interesting, Stephane. Could you add statistics about character
> encodings used for text/gemini responses specifically? I'd like to know
> if there are currently text/gemini responses in any other encoding than
> UTF-8 (or US ASCII). That would be an interesting topic in the IRI+IDN
> discussion.

  There's a chart on the GUS stats page:

	https://portal.mozz.us/gemini/gus.guru/statistics

  It seesm it's a 54/46 split between UTF-8/US-ASCII (and 7 (seven) pages
out of 84,400 that are NOT UTF-8 nor US-ASCII).

  -spc


From stephen at drsudo.com  Thu Dec 24 03:41:56 2020
From: stephen at drsudo.com (Stephen)
Date: Thu, 24 Dec 2020 03:41:56 +0000 (UTC)
Subject: The problem with unusual ports
In-Reply-To: <023af6e4-b2d2-8427-70d2-278706922af6@rocketnine.space>
References: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>
 <023af6e4-b2d2-8427-70d2-278706922af6@rocketnine.space>
Message-ID: <e8219e39-20a5-4322-9e87-d55bd275e21b@drsudo.com>

>Someone has written one. :)
>
>gmitohtml is a Gemini proxy server.
>
>https://gitlab.com/tslocum/gmitohtml

Forgive me if I misunderstand, but I believe the idea is to run the Gemini protocol and serve gemini content, but just be able to do it on a port other than 1965 (In this case, proxying gemini over the https port).

The proxy server you suggest appears to be one for translating gmi to html and serving it over a web interface. There are several such pieces of software in common public use (such as at mozz.us) but they are different from what is being discussed here.

~Stephen

From colecmac at protonmail.com  Thu Dec 24 03:45:59 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 24 Dec 2020 03:45:59 +0000
Subject: The problem with unusual ports
In-Reply-To: <e8219e39-20a5-4322-9e87-d55bd275e21b@drsudo.com>
References: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>
 <023af6e4-b2d2-8427-70d2-278706922af6@rocketnine.space>
 <e8219e39-20a5-4322-9e87-d55bd275e21b@drsudo.com>
Message-ID: <FmrWGIqyTH8Pn7jdhDpDX72s4dJ9UPNF2M-YFS63aTnme2TlHlmSdViBxJdqYMg6MPcN8fTGaO-glRpXUgOuyrrWzihzlx2q55IwnsCPPeA=@protonmail.com>

> > Someone has written one. :)
> > gmitohtml is a Gemini proxy server.
> > https://gitlab.com/tslocum/gmitohtml
>
> Forgive me if I misunderstand, but I believe the idea is to run the Gemini
> protocol and serve gemini content, but just be able to do it on a port other
> than 1965 (In this case, proxying gemini over the https port).

To clarify, I'm talking about Gemini server that accepts request URLs with other
hosts. Like the server runs at example.com, and will accept requests for example.com,
gus.guru, makeworld.gq, etc. And it will make the request on your behalf.

And then that server could run on any port, port 443 for example. This would be a
way to get around blocking.


makeworld

From petite.abeille at gmail.com  Thu Dec 24 10:31:24 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Thu, 24 Dec 2020 11:31:24 +0100
Subject: The problem with unusual ports
In-Reply-To: <FmrWGIqyTH8Pn7jdhDpDX72s4dJ9UPNF2M-YFS63aTnme2TlHlmSdViBxJdqYMg6MPcN8fTGaO-glRpXUgOuyrrWzihzlx2q55IwnsCPPeA=@protonmail.com>
References: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>
 <023af6e4-b2d2-8427-70d2-278706922af6@rocketnine.space>
 <e8219e39-20a5-4322-9e87-d55bd275e21b@drsudo.com>
 <FmrWGIqyTH8Pn7jdhDpDX72s4dJ9UPNF2M-YFS63aTnme2TlHlmSdViBxJdqYMg6MPcN8fTGaO-glRpXUgOuyrrWzihzlx2q55IwnsCPPeA=@protonmail.com>
Message-ID: <E7E34AD8-6155-47B9-9706-820E966F5770@gmail.com>



> On Dec 24, 2020, at 04:45, colecmac at protonmail.com wrote:
> 
> And then that server could run on any port, port 443 for example. This would be a
> way to get around blocking.

In other words, assuming some hypothetical proxy service at 'tunnel.xyz' running on port 443 over TLS: 

openssl s_client -quiet -crlf -connect tunnel.xyz:443 <<< gemini://mozz.us/ 2>/dev/null

First connect to tunnel.xyz:443, then request the content at gemini://mozz.us/ .

Nice use case.

On that note, Merry Christmas and Happy Holidays.

From marcx2 at welz.org.za  Thu Dec 24 11:48:50 2020
From: marcx2 at welz.org.za (marc)
Date: Thu, 24 Dec 2020 12:48:50 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223230319.GC9267@brevard.conman.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
 <20201223230319.GC9267@brevard.conman.org>
Message-ID: <20201224114850.GA14763@localhost.localdomain>

Hello

> > It is one thing to find full internationalisation support in a language such as python
> > (slow batteries included), but what about minorities such tcl, lua, m4 or
> > sed ?
> 
>   I have Lua covered.  I can't say for the others (other than, you really
> use m4?  You are a better man than I am, Gunga Din).

So I do use m4 - it can be quite nifty to generate latex fragments, 
but that is because latex doesn't play as nicely with pipes as 
(g)roff where one can just stream things in...

m4 doesn't strike me as that special ? Prolog and postscript
felt far more exotic to me, and web servers have been written 
in the latter...

>   I have to deal with the telephony network at work.  It *is* the OSI seven
> layer burrito [1] and even *there* there are baked in assumptions relating
> to i18n [2].  Text is limited to ASCII.  Yup.  7-bit US-ASCII it all its
> glory.  Anything else requires some very nasty hacks.  

Note how the global telephone system has made it into the furthest
corners of the planet - arguably further than the internet, and did
so without worrying about internationalisation relating to their
URL equivalents (phone numbers)...

> > But even the layer just below that (the competent user level) this starts
> > leaking. A gemini url starts with "gemini://" - that is ascii text, and
> > even funnier, taken from latin. If a non-english user is confused by
> > english (nay, latin, with no native speakers at all) words, then surely
> > "gemini://" has to be rewritten as "tweling://" or "zwilling://" or
> > whatever farsi, japanese or mongolian use for "twin". If not, then an full
> > ascii text url should be manageable too... an url is primarily a computer
> > address.
> 
>   Sushi comes from Japanese, gesundheit from German, sauna from Finnish,
> smorgasbord from Swedish, borscht from Russian and ketchup from China,
> what's your point?

The insinuation was that internationalised URLs are essential
because people who don't speak english at all might not be
able to comprehend or (if their input system is sufficiently
different) generate ascii/latin text.

And my argument is that this doesn't make sense, as 
every gemini url starts with "gemini://" which is ascii text
in a language that nobody speaks anymore. And if people can manage
to type "gemini://" then a bit more ascii in the hostname or
even path should be quite manageable too even for "people who
use scripts like arabic, chinese, devanageri, etc." to quote
another list participant.

A pity that I failed to convey this point properly -
you and I (and bie, and some others) have had a very similar
conversation on the 7th and 9th of this month (under the subject
"IDN with Gemini"), where I tried to explain my position that
I view as a language as a communications protocol and not the
property of an ethnicity or nation.

The desire to be inclusive is good, but we are deferential
to pretty recent concept/meme - the monolingual nation state,
which is say 200 or 300 years old. Before that (at least
in europe, but elsewhere too) each little region had pretty strong
regional dialect or even language (limited mobility or literacy
allows for rapid linguistic drift). People who were educated spoke
a second or third language to interact with the clergy or the palaces
far away.

In this regard having people know learn a new language to interact
with the internet isn't that much of an imposition, but a return
to the way things were... just scaled up to the size of the planet. 

> All those are perfectly cromulent (from Simpsons) words. 
> Modern English sucks up words from all other languages.

Older english does too: That's why a dead cow is beef. All
languages do, absent a (religious or state-sponsored) authority
enforcing a level of purity aka stasis. Living languages evolve.

>   But yes, there have been several such localizations in the past for
> various [programming] languages but they never caught on internationally 
> for some reason. 

Isn't that yet another hint ? That the point of a language is to
communicate, not to serve as a barrier, despite the machinations
of nationalists ?

regards

marc

From stephane at sources.org  Thu Dec 24 12:34:45 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 13:34:45 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201224020857.8e420526073869549e85ea52@gmail.com>
References: <20201216150549.GA19202@sources.org>
 <20201224020857.8e420526073869549e85ea52@gmail.com>
Message-ID: <20201224123444.GA6837@sources.org>

On Thu, Dec 24, 2020 at 02:08:57AM +0100,
 Philip Linde <linde.philip at gmail.com> wrote 
 a message of 37 lines which said:

> Could you add statistics about character encodings used for
> text/gemini responses specifically?

Only for text/gemini:

* Unspecified: 5997
* utf-8: 4619
* tcvn-5712: 2
* cp437: 2
* utf-16be: 1
* utf-16: 1
* windows-1252: 1
* utf-32le: 1
* utf-32be: 1
* utf-16le: 1
* ebcdicatde: 1

But wait, all the exotic charsets are at <gemini://egsam.pitr.ca/>
which is a test site for various funny stuff. So, it is safe to say
that not one "real" gemtext resource uses something else than UTF-8.

By the way, this is the RFC 5198 recommendation
<gemini://gemini.bortzmeyer.org/rfc-mirror/rfc5198.txt>

> I'd like to know if there are currently text/gemini responses in any
> other encoding than UTF-8 (or US ASCII). That would be an
> interesting topic in the IRI+IDN discussion.

I don't see the relationship. There is clearly unanimity among
geminauts that *content* should be in UTF-8 (and I would suggest that
this SHOULD could be changed in MUST), the discussion is about
metadata, the identifier (the IRI).

From stephane at sources.org  Thu Dec 24 12:37:25 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 13:37:25 +0100
Subject: [ANN] A Gemini crawler, for statistics about the geminispace
In-Reply-To: <20201224020112.GG9267@brevard.conman.org>
References: <20201216150549.GA19202@sources.org>
 <20201224020857.8e420526073869549e85ea52@gmail.com>
 <20201224020112.GG9267@brevard.conman.org>
Message-ID: <20201224123724.GB6837@sources.org>

On Wed, Dec 23, 2020 at 09:01:13PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 22 lines which said:

>   There's a chart on the GUS stats page:
> 
> 	https://portal.mozz.us/gemini/gus.guru/statistics
> 
>   It seesm it's a 54/46 split between UTF-8/US-ASCII

It seems this percentage includes plain text (anyway, the sum of the
numbers does not match the total, not the gemtext only). I cannot find a
gemtext page tagged as US-ASCII.

From op at omarpolo.com  Thu Dec 24 12:39:16 2020
From: op at omarpolo.com (Omar Polo)
Date: Thu, 24 Dec 2020 13:39:16 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223025416.GA25066@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
Message-ID: <87lfdn74zv.fsf@omarpolo.com>


bie <bie at 202x.moe> writes:

>
> My server doesn't have to know anything about unicode to serve a text
> file, just like it doesn't have to be able to parse JPEGs to serve
> images. IRIs means it *does* have to know something about unicode, which
> ucs characters are valid IRI characters, that the "private" UCS are only
> valid in the query part etc etc.
>
> bie

I think we're in the same boat, as I have written from scratch my server
using only stuff that's in base on OpenBSD too.

Initially I was totally for option #3 (but I've that I've just finished
skimming through the RFC), but by reading your messages I was a little
scared of the consequences.

Today I did some light testing, and it seems that (IF I'm understanding
everything correctly -- please correct me otherwise) that option #3 is
actually simpler for us.

Current state of the affairs: both Lagrange (0.13.1), amfora and elpher
will encode "gemini.omarpolo.com/caf?.gmi" as
"gemini.omarpolo.com/caf%C3%A8.gmi".  Obviously open("caf%C3%A8.gmi")
fails, so my server return 51 because the actual file name is
"caf?.gmi".  I have to write code that de-encode parts of the request if
I want to serve a file named like that (spoiler: I'm not gonna write it).

With IRI: the request becomes "gemini://gemini.omarpolo.com/caf?.gmi",
so open("caf?.gmi") doesn't fail.  I think that we can continue to treat
the request as a bytestring, extract the path and try to open(2) it.

I know that what I'm proposing is a really poor-man solution, because it
doesn't matter we choose option #1, #2 or #3 as we can't really treat
the path in the URL/IRL as a bytestring and call it a day.  UNIX file
names are real bytestring with only two forbidden octet, URL/IRI
aren't.

So, if I'm not missing anything, I'm all in for option #3.

From stephane at sources.org  Thu Dec 24 13:06:25 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 14:06:25 +0100
Subject: The problem with unusual ports
In-Reply-To: <FmrWGIqyTH8Pn7jdhDpDX72s4dJ9UPNF2M-YFS63aTnme2TlHlmSdViBxJdqYMg6MPcN8fTGaO-glRpXUgOuyrrWzihzlx2q55IwnsCPPeA=@protonmail.com>
References: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>
 <023af6e4-b2d2-8427-70d2-278706922af6@rocketnine.space>
 <e8219e39-20a5-4322-9e87-d55bd275e21b@drsudo.com>
 <FmrWGIqyTH8Pn7jdhDpDX72s4dJ9UPNF2M-YFS63aTnme2TlHlmSdViBxJdqYMg6MPcN8fTGaO-glRpXUgOuyrrWzihzlx2q55IwnsCPPeA=@protonmail.com>
Message-ID: <20201224130624.GA9791@sources.org>

On Thu, Dec 24, 2020 at 03:45:59AM +0000,
 colecmac at protonmail.com <colecmac at protonmail.com> wrote 
 a message of 22 lines which said:

> To clarify, I'm talking about Gemini server that accepts request
> URLs with other hosts. Like the server runs at example.com, and will
> accept requests for example.com, gus.guru, makeworld.gq, etc. And it
> will make the request on your behalf.

A bit like "domain fronting" <https://en.wikipedia.org/wiki/Domain_fronting>.

> And then that server could run on any port, port 443 for
> example. This would be a way to get around blocking.

Indeed. I hope someone will volunteer. Do note that this requires
trust in the proxy, which will see everything in clear text.

With ALPN (RFC 7301
<gemini://gemini.bortzmeyer.org/rfc-mirror/rfc7301.txt>), the same
machine could even run HTTPS and Gemini on the same port. All it needs
is registration of ALPN for Gemini
<https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>
and its use by Gemini clients.






From bie at 202x.moe  Thu Dec 24 13:36:43 2020
From: bie at 202x.moe (bie)
Date: Thu, 24 Dec 2020 22:36:43 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <87lfdn74zv.fsf@omarpolo.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
Message-ID: <20201224133643.GA424@202x.moe>

On Thu, Dec 24, 2020 at 01:39:16PM +0100, Omar Polo wrote:
> I think we're in the same boat, as I have written from scratch my server
> using only stuff that's in base on OpenBSD too.
> 
> Initially I was totally for option #3 (but I've that I've just finished
> skimming through the RFC), but by reading your messages I was a little
> scared of the consequences.
> 
> Today I did some light testing, and it seems that (IF I'm understanding
> everything correctly -- please correct me otherwise) that option #3 is
> actually simpler for us.
> 
> Current state of the affairs: both Lagrange (0.13.1), amfora and elpher
> will encode "gemini.omarpolo.com/caf?.gmi" as
> "gemini.omarpolo.com/caf%C3%A8.gmi".  Obviously open("caf%C3%A8.gmi")
> fails, so my server return 51 because the actual file name is
> "caf?.gmi".  I have to write code that de-encode parts of the request if
> I want to serve a file named like that (spoiler: I'm not gonna write it).
> 
> With IRI: the request becomes "gemini://gemini.omarpolo.com/caf?.gmi",
> so open("caf?.gmi") doesn't fail.  I think that we can continue to treat
> the request as a bytestring, extract the path and try to open(2) it.
> 
> I know that what I'm proposing is a really poor-man solution, because it
> doesn't matter we choose option #1, #2 or #3 as we can't really treat
> the path in the URL/IRL as a bytestring and call it a day.  UNIX file
> names are real bytestring with only two forbidden octet, URL/IRI
> aren't.
> 
> So, if I'm not missing anything, I'm all in for option #3.

You're kind of correct in the sense that if we just treat the request as
arbitrary bytes and not as an IRI (no validation, no handling at all),
it's simple, but I don't think that's the right way to look at this
issue. Instead, it's about the complexity of proper URI handling vs
proper IRI handling. Not to mention that IRIs can still have
percent-encoded characters!

After thinking about this for a while, the biggest issue for me is that
this is a breaking change. Breaking in the sense that it breaks *every
single compliant server we already have*! If gemini, which has been
surprisingly good at resisting breaking spec changes, accepts this, I
don't see any reason to believe that it won't happen again and again,
for equally silly reasons.

bie

From bie at 202x.moe  Thu Dec 24 13:49:21 2020
From: bie at 202x.moe (bie)
Date: Thu, 24 Dec 2020 22:49:21 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224114850.GA14763@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
 <20201223230319.GC9267@brevard.conman.org>
 <20201224114850.GA14763@localhost.localdomain>
Message-ID: <20201224134921.GA25533@202x.moe>

On Thu, Dec 24, 2020 at 12:48:50PM +0100, marc wrote:
> The insinuation was that internationalised URLs are essential
> because people who don't speak english at all might not be
> able to comprehend or (if their input system is sufficiently
> different) generate ascii/latin text.
> 
> And my argument is that this doesn't make sense, as 
> every gemini url starts with "gemini://" which is ascii text
> in a language that nobody speaks anymore. And if people can manage
> to type "gemini://" then a bit more ascii in the hostname or
> even path should be quite manageable too even for "people who
> use scripts like arabic, chinese, devanageri, etc." to quote
> another list participant.
> 
> A pity that I failed to convey this point properly -
> you and I (and bie, and some others) have had a very similar
> conversation on the 7th and 9th of this month (under the subject
> "IDN with Gemini"), where I tried to explain my position that
> I view as a language as a communications protocol and not the
> property of an ethnicity or nation.
> 
> The desire to be inclusive is good, but we are deferential
> to pretty recent concept/meme - the monolingual nation state,
> which is say 200 or 300 years old. Before that (at least
> in europe, but elsewhere too) each little region had pretty strong
> regional dialect or even language (limited mobility or literacy
> allows for rapid linguistic drift). People who were educated spoke
> a second or third language to interact with the clergy or the palaces
> far away.
> 
> In this regard having people know learn a new language to interact
> with the internet isn't that much of an imposition, but a return
> to the way things were... just scaled up to the size of the planet. 

Just an anecdote I briefly brought up on IRC...

I briefly experimented with percent-encoded Japanese and Norwegian
addresses on some of my capsules, but quickly gave up and went back to 
pure ASCII. *Not* because typing in percent-encoded names was annoying,
but because I realized how hard it was to verbally convey my Japanese
addresses to my Norwegian friends and vice versa. The de facto
universality of ASCII might something to embrace, not something to run away
from, if we want to be serious about being inclusive.

(marc - your posts in this thread have been great.. really appreciate
them!)

bie

From stephane at sources.org  Thu Dec 24 14:07:58 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 15:07:58 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
Message-ID: <20201224140758.GA11767@sources.org>

On Tue, Dec 22, 2020 at 03:34:03PM -0500,
 John Cowan <cowan at ccil.org> wrote 
 a message of 93 lines which said:

> I think we should adopt the following RFC 7231 compatible rules.

It seems a good idea. I hope it will be included in the official
specification, or in a companion specification.

> 3) If the original URL has a fragment and the redirect doesn't, the client
> MUST apply the original fragment when the redirected resource is retrieved.

Even if it's in a different capsule?

From stephane at sources.org  Thu Dec 24 14:29:48 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 15:29:48 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224133643.GA424@202x.moe>
References: <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
 <20201224133643.GA424@202x.moe>
Message-ID: <20201224142947.GA11963@sources.org>

On Thu, Dec 24, 2020 at 10:36:43PM +0900,
 bie <bie at 202x.moe> wrote 
 a message of 46 lines which said:

> After thinking about this for a while, the biggest issue for me is
> that this is a breaking change. Breaking in the sense that it breaks
> *every single compliant server we already have*! If gemini, which
> has been surprisingly good at resisting breaking spec changes,
> accepts this, I don't see any reason to believe that it won't happen
> again and again,

As I explained in
<https://lists.orbitalfox.eu/archives/gemini/2020/004178.html>, I do
not think that backward compatibility should be a goal, since Gemini
is still experimental. Once the specification is "officially" "final",
this will be different. AFAIK, it is not the case (otherwise, what
would be the point of the [spec] topic?)

To answer your question: once the spec is "officially" adopted, it
makes sense to resist changes. We are not at this stage yet.

>  for equally silly reasons.

Internationalization is certainly not a silly reason.

From bie at 202x.moe  Thu Dec 24 14:52:53 2020
From: bie at 202x.moe (bie)
Date: Thu, 24 Dec 2020 23:52:53 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224142947.GA11963@sources.org>
References: <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
 <20201224133643.GA424@202x.moe>
 <20201224142947.GA11963@sources.org>
Message-ID: <20201224145253.GA39843@202x.moe>

On Thu, Dec 24, 2020 at 03:29:48PM +0100, Stephane Bortzmeyer wrote:
> As I explained in
> <https://lists.orbitalfox.eu/archives/gemini/2020/004178.html>, I do
> not think that backward compatibility should be a goal, since Gemini
> is still experimental. Once the specification is "officially" "final",
> this will be different. AFAIK, it is not the case (otherwise, what
> would be the point of the [spec] topic?)

In that case you should read the first part of the current
specification:

"Although not finalised yet, further changes to the specification are
likely to be relatively small. You can write code to this
pseudo-specification and be confident that it probably won't become
totally non-functional due to massive changes next week, but you are
still urged to keep an eye on ongoing development of the protocol and
make changes as required."

Now you might consider this proposed to change to be small enough or
important enough to still make sense. I do not.

> To answer your question: once the spec is "officially" adopted, it
> makes sense to resist changes. We are not at this stage yet.
> 
> >  for equally silly reasons.
> 
> Internationalization is certainly not a silly reason.

You don't need IRIs for internationalization. So yes, it is a silly
reason.

bie

From stephane at sources.org  Thu Dec 24 14:52:34 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 15:52:34 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <5FE27F33.1070705@marmaladefoo.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
Message-ID: <20201224145234.GA13257@sources.org>

On Tue, Dec 22, 2020 at 11:20:19PM +0000,
 Luke Emmet <luke at marmaladefoo.com> wrote 
 a message of 61 lines which said:

> The question that remains particularly, is what should be the
> semantics of the fragment for our most prevalent media type -
> text/gemini?

It is an interesting question but unrelated to the subject of this
thread.

> Then again, do we really have much of a need to do page-specific
> indexing for URLs? Most Gemini pages are quite simple and not too
> complicated. So maybe we just get by without the fragment?

Note there is a standard for fragments on plain text: RFC 5147
<gemini://gemini.bortzmeyer.org/rfc-mirror/rfc5147.txt>.



From stephane at sources.org  Thu Dec 24 15:01:42 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 16:01:42 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223100058.GA6184@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
Message-ID: <20201224150142.GA13573@sources.org>

On Wed, Dec 23, 2020 at 11:00:58AM +0100,
 marc <marcx2 at welz.org.za> wrote 
 a message of 79 lines which said:

> So I value the decency which wants to include all 
> human languages in the gemini ecosystem.

Actually, all human *scripts*. In any case, a Gemini client or server
won't have to understand the language. (Mandatory AI in Gemini?)

> But in an effort to be inclusive in one dimension one ends up being
> exclusive in another dimension, namely in the space of computer
> languages/host operating systems.

We already do it with the mandatory TLS: some systems cannot run
Gemini (imagine a Gemini server in assembly language). 

> It is one thing to find full I8N support in a language such as
> python (slow batteries included), but what about minorities such
> tcl, lua, m4 or sed ?

Lua is not a good example since the core language is, by design,
stricly limited. Any real Lua program uses several third-party
libraries.

> And so it strikes me as weird to embed the (combinatorial)
> complexity of human languages deep in the protocol stack,

I agree but nobody suggested to force Gemini software to understand
languages, only scripts.

> But even the layer just below that (the competent user level) this
> starts leaking. A gemini url starts with "gemini://" - that is ascii
> text, and even funnier, taken from latin. If a non-english user is
> confused by english (nay, latin, with no native speakers at all)
> words, then surely "gemini://" has to be rewritten as "tweling://"
> or "zwilling://" or whatever farsi, japanese or mongolian use for
> "twin". If not, then an full ascii text url should be manageable
> too...

The Web solved the problem by making the URI scheme optional. I don't
know Gemini clients who complete the URI with "gemini://" if it's
missing but it is a possible approach.

> an url is primarily a computer address.

This is clearly false. URI are both a technical identifier (like an IP
address or an address in memory) *and* a text seen by humans and
displayed in TV ads, business cards, spoken over the phone,
etc. Unlike addresses, they have to be internationalized. (Nobody
would use the Web if HTTP URIs were really addresses.)

> Long ago I came across a version of (I think it was) Pascal had been
> localised into french with language keywords like "begin" and "if"
> replaced. I am sure somebody can justify this somehow, but I thought
> this was an impediment to interoperability, and view the
> internationalising of computer protocols (as opposed to the user
> interfaces) in a similar way.

The idea is to have much more users than page authors and much more
page authors than programmers. Internationalizing programming
languages is a different issue, since programmers are a smaller group,
of professionals.



From luke at marmaladefoo.com  Thu Dec 24 15:13:36 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 24 Dec 2020 15:13:36 +0000
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <20201224145234.GA13257@sources.org>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com> <20201224145234.GA13257@sources.org>
Message-ID: <5FE4B020.8060005@marmaladefoo.com>


On 24-Dec-2020 14:52, Stephane Bortzmeyer wrote:
>> The question that remains particularly, is what should be the
>> semantics of the fragment for our most prevalent media type -
>> text/gemini?
> It is an interesting question but unrelated to the subject of this
> thread.
Fair point, if this thread is only about the protocol aspects, not their 
application to text/gemini.

But it is still something to be sorted out if we will use them in gemini 
content.

>> Then again, do we really have much of a need to do page-specific
>> indexing for URLs? Most Gemini pages are quite simple and not too
>> complicated. So maybe we just get by without the fragment?
> Note there is a standard for fragments on plain text: RFC 5147
> <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc5147.txt>.
>
Yes that might be useful for plain text, but gemini is not plain text, 
it is text/gemini. Similarly HTML is not plain text, rather text/html, 
and it specifies a semantics for how the fragments are identified within 
the html content via <a name, or id attributes.

We could consider using RFC5147 for any content served as text/plain.

  - Luke


From stephane at sources.org  Thu Dec 24 15:14:21 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 16:14:21 +0100
Subject: [Tech] [Spec] TOFU or not TOFU?
Message-ID: <20201224151421.GA14047@sources.org>

On 21 december, gemini://thurk.org/ had the public key
5dDrQtsEsCyzK7/ZrSFr8unk8OXfgVBhzW0kup9fTaI=. Today, it is
OqGA8UkjoW+oDCX5e3NdfH8q7wBCAlkoyBv/02BcG24=. The Lupa crawler
protested. (Same thing for gemini://mozz.us.)

What should we do when a public key changes? Reject it? Accept it if
the certificate is signed by a known CA? Ask this mailing list? The
security part of the current specification is quite vague.

It says "If the certificate is not the one previously received, but
the previous certificate's expiry date has not passed, the user is
shown a warning, analogous to the one web browser users are shown when
receiving a certificate without a signature chain leading to a trusted
CA." So, always accept, just logs a warning, thus defeating all
security? (Note that it requires to store the entire certificate, not
just the public key, which means renewals by Let's Encrypt would break
TOFU.)





From stephane at sources.org  Thu Dec 24 15:25:43 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Thu, 24 Dec 2020 16:25:43 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <5FE4B020.8060005@marmaladefoo.com>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com>
 <20201224145234.GA13257@sources.org>
 <5FE4B020.8060005@marmaladefoo.com>
Message-ID: <20201224152543.GA15407@sources.org>

On Thu, Dec 24, 2020 at 03:13:36PM +0000,
 Luke Emmet <luke at marmaladefoo.com> wrote 
 a message of 27 lines which said:

> > Note there is a standard for fragments on plain text: RFC 5147
> > <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc5147.txt>.
> > 
> Yes that might be useful for plain text, but gemini is not plain text, 

It is not but it is close to plain text. There have been several
interesting proposals on this list for fragment semantics. The good
thing about RFC 5147 is that is already exists.

From sose-iwnl at protonmail.com  Thu Dec 24 16:55:30 2020
From: sose-iwnl at protonmail.com (sose-iwnl)
Date: Thu, 24 Dec 2020 16:55:30 +0000
Subject: [ANN] motm - the messageboard on the moon
Message-ID: <dGkQlqOJuNmQ0RU2jgkHawS3SSGeW84-ksMI39h8P4NLy1Y-YgWH3qjiYd2RQcMu_R8xVZNUBaXo0BTygYxaaDOAxTKH7g0Pz6MdfnJ84mo=@protonmail.com>

Hi everyone,
I wrote a messageboard for Gemini. It uses client certs to register and authenticate users, and runs as a CGI script. Users can also append to posts they have created so post length isn't limited by the max URL length. By default it's structured like a textboard, but it can be configured pretty much any way you like.

Right now it's only been tested with Jetforce but it should work with any Gemini server that provides the same CGI variables.

There is a live version at gemini://[illegaldrugs.net/cgi-bin/motm](http://illegaldrugs.net/cgi-bin/motm/boards).
Source code and instructions can be found at https://tildegit.org/sose/motm.

Hope it proves useful for some.

- sose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201224/3e1bd6d2/attachment.htm>

From luke at marmaladefoo.com  Thu Dec 24 17:55:32 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Thu, 24 Dec 2020 17:55:32 +0000
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <20201224152543.GA15407@sources.org>
References: <20201222095950.GB24920@sources.org>
 <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <5FE27F33.1070705@marmaladefoo.com> <20201224145234.GA13257@sources.org>
 <5FE4B020.8060005@marmaladefoo.com> <20201224152543.GA15407@sources.org>
Message-ID: <5FE4D614.9030402@marmaladefoo.com>

On 24-Dec-2020 15:25, Stephane Bortzmeyer wrote:
>>> Note there is a standard for fragments on plain text: RFC 5147
>>> <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc5147.txt>.
>> Yes that might be useful for plain text, but gemini is not plain text,
> It is not but it is close to plain text. There have been several
> interesting proposals on this list for fragment semantics. The good
> thing about RFC 5147 is that is already exists.

You could say HTML is close to plain text, since it is implemented in 
text, so why not use it there?

The limitation of RFC 5147 is that it is not robust at all to any edits 
at all. And gemini resources are not the type of media that are never 
edited, so the match is not so good IMO.

A semantic based addressing scheme would be more robust, and the most 
obvious structure within a gemini document is its heading structure.

  - Luke



From colecmac at protonmail.com  Thu Dec 24 19:39:53 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 24 Dec 2020 19:39:53 +0000
Subject: [Tech] [Spec] TOFU or not TOFU?
In-Reply-To: <20201224151421.GA14047@sources.org>
References: <20201224151421.GA14047@sources.org>
Message-ID: <7V0HIMDNscDNze_dUHAfisR8HVRQPWcY_z7w_OREV07Mpq8FInCAnUfP_G46kp4N4Nddsbzg7-ZHEM2919DKceTrk53zpY7goPIdbPjnF3g=@protonmail.com>

Hello,

I have written about TOFU before, perhaps it can help?

gemini://makeworld.gq/gemlog/2020-07-03-tofu-rec.gmi

This part of TOFU is not perfect and never will be. For user-facing clients
like browsers it comes down to showing users a warning. For crawlers like
Lupa, I think that it should ignore cert changes entirely. There's no way for
a crawler to decide if it's legitimate or not, and a crawler doesn't need much
privacy as it's going to access everything anyway.


makeworld



From colecmac at protonmail.com  Thu Dec 24 20:12:23 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 24 Dec 2020 20:12:23 +0000
Subject: [tech] Questions about cache
In-Reply-To: <63CB6D7E-3456-4FD1-8BAF-C26F2EDCF240@gmail.com>
References: <28542890-6BB9-474D-AA37-DA686BF066D8@gmail.com>
 <63CB6D7E-3456-4FD1-8BAF-C26F2EDCF240@gmail.com>
Message-ID: <Ot9SinnXh1d7c_C6XmB7e8pYDrL5UQjDWUO6Haqv0e8Xp50-wdWxcTMukhH8WvYAxM15iCqWiq4uoYT-eamgNPsoJr0XJP04Heym32qoFPc=@protonmail.com>

> On an Amfora-related note: makeworld talked about the caching on
> IRC the other day, and another user brought up that it seemed like
> Amfora presented cached content when a previously-visited link was
> clicked. Makeworld commented that this was unintended, and said they
> would fix it for a later release. (At least that?s how I remember it;
> maybe makeworld can weigh in.)


Wow, a lot of talk about Amfora in this thread. I'll respond to this, and
some other things.

What I remember from that IRC conversation was that another user (probably bie)
said that Amfora was using the cache, not when a link was clicked, but when
it was typed in the bottom bar. This should not be happening in my opinion,
but it is. I've opened an issue to address this, and yes, it will be fixed
in the next release.

https://github.com/makeworld-the-better-one/amfora/issues/159


>From Stephane's original email:

> So I was a bit surprised when I was putting together some dynamic
> content for my capsule and found that my client (amfora) was caching
> things. I was able to get around it by using temporary redirects to add
> cache busting query strings.

Amfora does not use the cache for redirects. That is, if the server redirects
the client to a cached page, Amfora will not use the cache to load that page.
The code for this change can be seen here:

https://github.com/makeworld-the-better-one/amfora/commit/b05885e7100a18fb7afae5d388173b7795c274ec

So if your dynamic content was using redirects already, it should be okay.


nytpu wrote:

> Looking at the Amfora code, it seems like there's 3 limits to the
> cache[1]: number of pages, size in bytes, and number of seconds. This
> seems to be configurable[2],and it looks like it *should* (I may be
> misreading the code) hard reload the page when you refresh a tab[3].

All correct. There are some other things that disable cache as well. Redirects,
and client certs. Any page that Amfora sends a client cert to will not
be cached, and this helps with dynamic apps like Astrobotany.


It sounds like the consensus in this thread is that Amfora should not be
using the cache when the user "clicks" a link. I suppose that makes sense,
but I find that for a lot of cases using the cache improves the browsing
experience. Most content on Gemini is static, and so it's nice when the page
loads instantly, it really makes a noticeable difference, despite how fast
Gemini is.

I'm not quite sure what to do here, as I don't want to break apps, but I
want browsing static content to be nice as well. Thoughts?

Cheers,
makeworld

From linde.philip at gmail.com  Thu Dec 24 20:30:29 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Thu, 24 Dec 2020 21:30:29 +0100
Subject: Unicode vs. the World
In-Reply-To: <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
References: <BFF5254E-4C06-442B-ABB1-6A299D28F037@gmail.com>
 <CAObwWNhQFH6wFC-0GODkv3sZ_29ZD=UUZobAn32mcx-+rJRwyw@mail.gmail.com>
Message-ID: <20201224213029.b821efe8316a13ccef25943e@gmail.com>

On Fri, 18 Dec 2020 07:13:24 +0100
Katarina Eriksson <gmym at coopdot.com> wrote:

> Domain name resolution is outside of the scope of the Gemini specification,
> we don't know if it can handle UTF-8 or not. If the visitor's network
> administrator has set up name resolution to accept UTF-8, they should
> probably also accept the punycoded version for compatibility.

IDNA moves what is ideally part of DNS into the application layer,
which is what the A stands for. It was somehow decided when adopting
this standard that it was better that every application that wants to
use a hostname should implement IDNA than to fix the underlying problem
in DNS.

This probably helped adoption early on because ISPs could largely leave
the cards in their card houses as they were, but creates more of a
burden for application developers, which in the long run is more
expensive.

So no, at least IDNA has to be supported by the application.

> Why can't servers just blindly accept non-ASCII bytes as is?

A fully compliant RFC 3986 implementation can't accept non-ASCII
characters. If that's what you have, you'll have to rewrite or replace
it. RFC 3987 covers this, but it's a bit more specific than blindly
accepting non-ASCII bytes. The chapters on the comparison ladder is a
good read for an overview of what may need to be implemented to avoid
false negative matching.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201224/50370e9c/attachment.sig>

From nervuri at disroot.org  Thu Dec 24 21:01:20 2020
From: nervuri at disroot.org (nervuri at disroot.org)
Date: Thu, 24 Dec 2020 21:01:20 +0000
Subject: [tech] [spec] Decide on use of URL fragment
Message-ID: <fff3a41016125eb1482e87c12e2ed55b@disroot.org>

Hello and thank you all for Gemini! Coming to Gemini from the web feels like leaving the smog and breathing clean air again. The documentation was a delight to read through, the trade-offs Gemini makes are well thought out and argued for. I respect the effort, so I'm here to lend a hand.

One of the missing bits is the ability to link to a specific part of a Gemini page, which is quite important when dealing with large documents. At one point there was talk of a library on Gemini ( gemini://booksin.space/ ), with complete books in plain text. So, indeed, this function would be very useful.

  https://lists.orbitalfox.eu/archives/gemini/2020/003702.html

Gemini doesn't yet use the URL fragment (the part after "#"). The web does, but in a rigid way: if a web page doesn't contain elements with IDs or names, there's nothing visitors can do to link to a specific section.

Gemini browsers can do better. I'm opening this thread to gather all proposed solutions, so that a standard may be reached. In this message I'll provide an overview of the ground that has been covered so far. At the end I highlight the solutions that I think best fit the Gemini ethos.

This topic has been discussed on the mailing list, but the discussion didn't go very far:

  https://lists.orbitalfox.eu/archives/gemini/2020/001454.html
  https://lists.orbitalfox.eu/archives/gemini/2020/004291.html

Proposed solutions:

* Numbering schemes, such as #20 (line 20) or #3.2 (heading 3, subheading 2). Short and simple, but easily broken if the page is modified. RFC 5147 is another such scheme, which introduces optional integrity checks and allows highlighting passages. But even with integrity checking, the fragment becomes useless if changes are made before (or within) the specified section. The fragility of these solutions is their major downside.

* Linking to headings, either by URL-encoding them directly into the fragment (ex: #5.4%20Core%20line%20types) or converting them to kebab case (ex: #core-line-types). Such links would be more robust than using number-based fragments, but why limit them to headings?

A more flexible option for for text/gemini and text/plain is to use the fragment for in-page search. Advanced browsers are bound to develop a "find in page" function which can be reused here, taking the fragment as input. This solution allows for linking to any point in the page and can be used to highlight passages.

I made a demo which includes a "link to here" option when selecting text:

https://nervuri.net/fragment-search/

It uses the following syntax:

#<text>[:<occurrence>]

, where <text> is any URL-encoded excerpt from the page and <occurrence> is an optional integer (negative numbers can be used for backwards search). It's still partially a numeric scheme, so a link like "#a:98" (the 98th occurrence of the letter "a") is very easily broken when the document changes. But if a long enough search string is used, the link will withstand most changes.

It turns out that this idea has been around on the web for a long time:

  https://indieweb.org/fragmention

Most importantly, there is an emerging web standard which we can learn from:

  https://github.com/WICG/scroll-to-text-fragment
  https://temp.treora.com/text-fragments-ts/demo.html

The syntax is:

#:~:text=[prefix-,]textStart[,textEnd][,-suffix]

Leaving aside its complexity (which I know is a sticking point for Gemini), it is more robust and versatile than basic search, because:

* it allows specifying any fragment of text, no matter how long, using only its beginning and end
* the "prefix-" and "-suffix" are better than an integer at disambiguating a specific instance of repeating text on a dynamic page
* it allows highlighting multiple fragments of text, using the "&" separator.

The standard could be simplified for Gemini, as the security considerations don't apply and partial implementations are possible (having multiple quotes in the same URL is arguably overkill). Even so, its complexity probably rules it out for Gemini.

It's interesting to note that all of these solutions fit together like pieces of Lego. Browsers can use all or none (or partial implementations), in a way that allows for graceful degradation. Multiple standards can even be used in the same link. Examples:

#char=100       (RFC 5147)
#line=10,20     (RFC 5147)
#heading=3.1.2
#heading=core-line-types
#text=some text
#text=some text:2
#text=from here,to here
#text=pre-,from here,to here,-post
#text=first,passage&text=second,passage
#text=word:3&text=some text
#line=10&text=some text
#regex=^(.+?):(-?\d+)$      (URL-encoded)
etc.

Ok, this got out of hand. Nobody wants all of these standards floating around in Gemini space, right? So, to conclude, I think the best options for Gemini are:

* basic search (#search%20me), perhaps with occurrence number (#search%20me:3). I consider this the best fit for Gemini, as it's the lowest complexity/(robustness*flexibility) value. It's trivial to implement for browsers that already have a "find in page" function. Search engines can also use this feature to generate links that take you directly to the part of the page that matches your query. On the other hand, if avoiding long ugly links is considered important, we can go with:

* headings only, using "lowercase kebab case of the alphabetic content, with single hyphens" (ex: #core-line-types) - which is what Luke Emmet suggested back in June ( https://lists.orbitalfox.eu/archives/gemini/2020/001462.html ). This is also low-complexity, gives us shorter links and is very robust to changes. But only linking to headings is quite restrictive. Also, it wouldn't work for identical (sub)headings or headings without letters, unless an occurrence number is added.

* just yesterday Luke Emmet had another good proposal on this topic: using the first 12 chars of the base64-encoding of the heading (details here: https://lists.orbitalfox.eu/archives/gemini/2020/004341.html ). Note that it can be applied to any line in the file. Again, an occurrence number can be added if needed. Hashes can be considered as alternatives to base64. The problem with this solution is that it's the most opaque of all. There's no way to tell what the fragment points to when looking at it, and creating the link without the assistance of an advanced browser is pretty much out of the question. But it's otherwise a good compromise which takes URL length into account.

Honorable mention to just using line numbers. Fragility aside, this is the most simple, straightforward option. Maybe append a hash of the line for integrity checking, like in RFC 5147.

Fragment search can encourage use of very long links. I, for one, don't consider this to be a serious downside. Links are primarily meant for computers - that's why Gemini has the optional user-friendly link names, after all.

Whichever solution is chosen (if any), I think it should be part of the Gemini best practices document, because we want links to work the same way for everyone - at least in the more advanced browsers that will support this. I do encourage the community to choose one, as even the most rudimentary solution is better than nothing.

Finally, the fragment may also be used for other purposes. For instance, a hash could be used by the browser to check if a page has been modified, or if a file has been downloaded correctly. So it might be wise to use prefixes, like #find= and #hash:sha256=.

From bjorn.warmedal at gmail.com  Thu Dec 24 21:19:33 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Thu, 24 Dec 2020 22:19:33 +0100
Subject: [Tech] [Spec] TOFU or not TOFU?
In-Reply-To: <20201224151421.GA14047@sources.org>
References: <20201224151421.GA14047@sources.org>
Message-ID: <6BFA112E-9C99-4367-A66F-32376EB6CDED@gmail.com>

I?ve said this before, and I feel more and more confident in this position:
Expiry dates in general and CA issued certs in particular really do not mix well with TOFU. When a cert expires a window for MitMA is opened. When this happens every 30-60 days it becomes quite ridiculous. An SSH hostkey has no expiration date; neither should certificates in geminispace (or at the very least we shouldn?t care about it).

I even go further and claim that neither Common Name nor Subject Alternative Names matter either. With a self-signed certificate these are as easily forged as any other fields.

I know a lot of people disagree with me here, but I have yet to see an argument that can convince me that CN, SAN, not-valid-before or not-valid-after have any bearing on the security of the certificate or give me as a user any information that helps me make a safe decision. All of these fields are crucial in a CA validation scheme, but only add a false sense of security in TOFU.

As for the specific question: a crawler has no way to make useful decisions about the security of the certificate. It should just not try.

Cheers,
ew0k

(Also: ??? Ho ho ho! Merry Christmas, everyone!)

From stephen at drsudo.com  Thu Dec 24 22:17:21 2020
From: stephen at drsudo.com (Stephen)
Date: Thu, 24 Dec 2020 22:17:21 +0000 (UTC)
Subject: [tech] Questions about cache
In-Reply-To: <Ot9SinnXh1d7c_C6XmB7e8pYDrL5UQjDWUO6Haqv0e8Xp50-wdWxcTMukhH8WvYAxM15iCqWiq4uoYT-eamgNPsoJr0XJP04Heym32qoFPc=@protonmail.com>
References: <28542890-6BB9-474D-AA37-DA686BF066D8@gmail.com>
 <63CB6D7E-3456-4FD1-8BAF-C26F2EDCF240@gmail.com>
 <Ot9SinnXh1d7c_C6XmB7e8pYDrL5UQjDWUO6Haqv0e8Xp50-wdWxcTMukhH8WvYAxM15iCqWiq4uoYT-eamgNPsoJr0XJP04Heym32qoFPc=@protonmail.com>
Message-ID: <750c4942-fee5-4c98-8437-a9a722270633@drsudo.com>

>It sounds like the consensus in this thread is that Amfora should not be
>using the cache when the user "clicks" a link. I suppose that makes sense,
>but I find that for a lot of cases using the cache improves the browsing
>experience. Most content on Gemini is static, and so it's nice when the page
>loads instantly, it really makes a noticeable difference, despite how fast
>Gemini is.

I think calling anything on this thread a consensus is being generous ;) I say since it is your app and you are not doing anything to break the spec that you are free to implement cache however you want. I think that your reasoning and method for caching makes a lot of sense.

If I recall correctly, amfora has an option to disable caching. In my mind that's good enough. I think that in absence of any guarantees in the spec, that it is incumbent on the capsule owner to put a cache disclaimer on dynamic content (Dynamic content doesn't seem to be the focus of gemini anyway)

I love amfora btw. Hands down my favorite gemini browser. Thanks for all your work on it. I follow it on GitHub (I'm sudobash1 there btw) and wow, is it busy :)

~Stephen

From colecmac at protonmail.com  Thu Dec 24 23:28:07 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Thu, 24 Dec 2020 23:28:07 +0000
Subject: [tech] Questions about cache
In-Reply-To: <750c4942-fee5-4c98-8437-a9a722270633@drsudo.com>
References: <28542890-6BB9-474D-AA37-DA686BF066D8@gmail.com>
 <63CB6D7E-3456-4FD1-8BAF-C26F2EDCF240@gmail.com>
 <Ot9SinnXh1d7c_C6XmB7e8pYDrL5UQjDWUO6Haqv0e8Xp50-wdWxcTMukhH8WvYAxM15iCqWiq4uoYT-eamgNPsoJr0XJP04Heym32qoFPc=@protonmail.com>
 <750c4942-fee5-4c98-8437-a9a722270633@drsudo.com>
Message-ID: <OlOfcizPkevlCDNe1qK6on0Wj88GShg8slIjgx01hdD-Ma1UdRtxdwt00EMXRQSep3O6Feqgs1LpcisZU9qGE0vGNUGGIycVdGjQtA8yVGM=@protonmail.com>

> I think calling anything on this thread a consensus is being generous ;) I
> say since it is your app and you are not doing anything to break the spec
> that you are free to implement cache however you want. I think that your
> reasoning and method for caching makes a lot of sense.
>
> If I recall correctly, amfora has an option to disable caching. In my mind
> that's good enough. I think that in absence of any guarantees in the spec,
> that it is incumbent on the capsule owner to put a cache disclaimer on dynamic
> content (Dynamic content doesn't seem to be the focus of gemini anyway)

Sounds good to me! I like the solution where I'm already right :)

> I love amfora btw. Hands down my favorite gemini browser. Thanks for all your
> work on it. I follow it on GitHub (I'm sudobash1 there btw) and wow, is it busy :)

Thank you! That means a lot. And thanks for your recent PR.

Cheers,
makeworld


From cowan at ccil.org  Fri Dec 25 00:08:05 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 24 Dec 2020 19:08:05 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224114850.GA14763@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
 <20201223230319.GC9267@brevard.conman.org>
 <20201224114850.GA14763@localhost.localdomain>
Message-ID: <CAD2gp_Sf-K6stk+zmshj4dZYCOHpCSRovV+DYKRz8kZ5k1A+TA@mail.gmail.com>

On Thu, Dec 24, 2020 at 6:49 AM marc <marcx2 at welz.org.za> wrote:


> Note how the global telephone system has made it into the furthest
> corners of the planet - arguably further than the internet, and did
> so without worrying about internationalisation relating to their
> URL equivalents (phone numbers)...
>

As someone who grew up actually rotating a dial to enter 7, 10, or (for
international calls) 15 digits, and looking them up in a paper booklet when
I hadn't memorized them, the user experience *sucked*.  Rectangular dials
are quicker, but otherwise not that much easier to use.  You could get a
name-to-number mapping by voice if you had enough details (typically a
postal address), but that is increasingly useless except for reaching a
business.  So what we have now is a system where numbers are universal and
the associated names are purely local.

The insinuation was that internationalised URLs are essential
> because people who don't speak english at all might not be
> able to comprehend or (if their input system is sufficiently
> different) generate ascii/latin text.
>

I think that is not the point at all.  In general, anglophones don't want
URLs that are completely meaningless: domain names generally have meaning
and so do path names and file names (consider gemini://
gemini.circumlunar.space/docs/companion/robots.gmi, for example, which
tells you a lot about the document it identifies).  But if they are in the
wrong script, ??? ?? ??? ?? ?? ??? ?? ?????????? ?? ???? ?? ?????????.  In
addition, ?? k?nv?n??nz ?v tr?nzl?t?re???n ?r n?t n?s?s?rili k?ns?st?nt
bitwin pip?l or k?ntriz.


> The desire to be inclusive is good, but we are deferential
> to pretty recent concept/meme - the monolingual nation state,
> which is say 200 or 300 years old.


Nid yw pob gwlad yn defnyddio un iaith yn unig.  (Not all countries use
only one language).


> In this regard having people know learn a new language to interact
> with the internet isn't that much of an imposition, but a return
> to the way things were... just scaled up to the size of the planet.
>

In imperio Romanorum, facilis est negotiator Romanus quam Gallus sive
Germanus, because the Roman grew up knowing the language of trade.
Likewise the anglophone today.

Isn't that yet another hint ? That the point of a language is to
> communicate, not to serve as a barrier, despite the machinations
> of nationalists ?
>

'M?lin eru h?fu?einkenni ?j??anna' ? Languages are the chief distinguishing
> marks of peoples. No people in fact comes into being until it speaks a
> language of its own; let the languages perish and the peoples perish too,
> or become different peoples. But that never happens except as the result of
> oppression and distress.'
> These are the words of a little-known Icelander of the early nineteenth
> century, Sj?ra Tomas S?mundsson, He had, of course, primarily in mind the
> part played by the cultivated Icelandic language, in spite of poverty, lack
> of power, and insignificant numbers, in keeping the Icelanders in being in
> desperate times. But the words might as well apply to the Welsh of Wales,
> who have also loved and cultivated their language for its own sake (not as
> an aspirant for the ruinous honour of becoming the lingua franca of the
> world), and who by it and with it maintain their identity.


--J.R.R. Tolkien, who was the furthest thing possible from either a
nationalist or an imperialist.  This is less true in Wales than it was when
Tolkien wrote it, but the point is the same.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201224/44ff0be6/attachment-0001.htm>

From gemini at stillspinning.cc  Fri Dec 25 09:02:32 2020
From: gemini at stillspinning.cc (spinner)
Date: Fri, 25 Dec 2020 01:02:32 -0800
Subject: [spec] IRIs, IDNs, and all that international jazz
Message-ID: <CAFM0rObLSuwR8v2amJRf=xsLk=d_wY1n4bGMnLnq8w76S8vfuw@mail.gmail.com>

> I briefly experimented with percent-encoded Japanese and Norwegian
addresses on some of my capsules, but quickly gave up and went back to pure
ASCII.
> *Not* because typing in percent-encoded names was annoying, but because I
realized how hard it was to verbally convey my Japanese addresses to my
Norwegian friends and vice versa. The de facto universality of ASCII might
something to embrace, not something to run away from, if we want to be
serious about being inclusive.

Verbally conveying addresses doesn't seem like a situation to optimize for;
doesn't seem to happen so often, at least in my life as a Japanese-speaking
internet user. Even among such occasions among future gemininauts, I
conjecture that, most of the time, both parties will speak Japanese and the
address can be quickly spelled out in Japanese.

For end-users, reading, following and writing links probably will be the
most likely ways you interact with URLs.

1. Read/follow links with a user-friendly name/title: If the URL is
non-ascii: Encoding of the URL may not matter much, since it will be
hidden. If the client is capable of showing the URL upon focus or
something, showing it in unicode is far more accessible that
percent-encoding
2. Read/follow links with bare URL: If the URL is non-ascii: more
accessible to be able to read the URL in its non-ascii form
3. Write links to URLs that I control: More inclusive and convenient to be
able to use and write URLs using the script that I'm used to.
4. Write links to URLs that I don't control: It'll be more
accessible/convenient to be able to write the URL in non-ascii characters.
Copying a non-ascii URL off of a web browser's address bar will probably
percent-encode it (just tried it on desktop Chrome), but I shouldn't have
to rely on such tools.

While embracing ASCII may work when we have control over URLs we read and
write, it falls short in terms of accessibility when linking to, say,
Wikipedia, which uses non-ascii page names.

If the aim is to support i18n/inclusivity as a principle/ideal/a 100%
thing, adopting standards such as IRI/IDN(/ASCII) may make sense; if the
motivation is out of practical concerns (whether people will find
themselves reading and writing non-ascii URLs a lot and we want to make
their lives easier in that case), having clients percent-encode path
components before sending requests may suffice for now..?

>From my standpoint, chances/expectations of a particular component of a URL
having non-ascii characters:

- protocol: none
- domain: 2% of the time (8.3 million IDNs [1] / total domain names 370.7
million [2]) - but, for me, nearly none in practice. I suppose it depends
on the person
- path/query/fragment: fairly often, since I use (Japanese) Wikipedia a lot

[1] https://idnworldreport.eu/ (2020 Q1)
[2] https://www.verisign.com/en_US/domain-names/dnib/index.xhtml (2020 Q3)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201225/c9e4369d/attachment.htm>

From bie at 202x.moe  Fri Dec 25 12:07:09 2020
From: bie at 202x.moe (bie)
Date: Fri, 25 Dec 2020 21:07:09 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <CAFM0rObLSuwR8v2amJRf=xsLk=d_wY1n4bGMnLnq8w76S8vfuw@mail.gmail.com>
References: <CAFM0rObLSuwR8v2amJRf=xsLk=d_wY1n4bGMnLnq8w76S8vfuw@mail.gmail.com>
Message-ID: <20201225120709.GA62135@202x.moe>

On Fri, Dec 25, 2020 at 01:02:32AM -0800, spinner wrote:
> Verbally conveying addresses doesn't seem like a situation to optimize for;
> doesn't seem to happen so often, at least in my life as a Japanese-speaking
> internet user. Even among such occasions among future gemininauts, I
> conjecture that, most of the time, both parties will speak Japanese and the
> address can be quickly spelled out in Japanese.

Verbally conveying URLs and usernames is a situation I find myself in
at least monthly... even more often before COVID.
When both parties speak the same language, sure, it's more or less fine,
but trying to explain an address with a character the other party has no
idea how to input is an exercise in frustration.

> For end-users, reading, following and writing links probably will be the
> most likely ways you interact with URLs.
> 
> 1. Read/follow links with a user-friendly name/title: If the URL is
> non-ascii: Encoding of the URL may not matter much, since it will be
> hidden. If the client is capable of showing the URL upon focus or
> something, showing it in unicode is far more accessible that
> percent-encoding

Agreed. This can be handled *today* by clients with no change in the
protocol.

> 2. Read/follow links with bare URL: If the URL is non-ascii: more
> accessible to be able to read the URL in its non-ascii form

Agreed. Again, this can be handled *today* by clients with no change to
the protocol.

> 3. Write links to URLs that I control: More inclusive and convenient to be
> able to use and write URLs using the script that I'm used to.
> 4. Write links to URLs that I don't control: It'll be more
> accessible/convenient to be able to write the URL in non-ascii characters.

I'd actually say it's just *slighty* more convenient. In most cases
you'll be copying and pasting the URL. If the gemini community feels that a
breaking change that increases the complexity of implementing servers
*and* clients is worth it for this slight change in convenience... well,
like I mentioned earlier, that doesn't bode well for the future.

As for inclusivity/accessibility... I just don't buy it. Completely
non-technical people are going to be using tooling for writing gemtext
anyway - the rest are perfectly capable of percent-encoding if they
*really really* want to use non-ascii characters.

All that said, I'll make another attempt at leaving this discussion (and
the mailing list) again... hopefully a final decision will be made
soon ;)

bie

From johann at qwertqwefsday.eu  Fri Dec 25 15:06:11 2020
From: johann at qwertqwefsday.eu (Johann Galle)
Date: Fri, 25 Dec 2020 16:06:11 +0100
Subject: [TECH] proxies and TOFU (was Re: The problem with unusual ports)
In-Reply-To: <FmrWGIqyTH8Pn7jdhDpDX72s4dJ9UPNF2M-YFS63aTnme2TlHlmSdViBxJdqYMg6MPcN8fTGaO-glRpXUgOuyrrWzihzlx2q55IwnsCPPeA=@protonmail.com>
References: <G9ZWcFND0zdLixlTv8rmFipzge8LDrB1IafZmyPGz2VhCMRXUBqPYaYuBe8igZzje2g0Lhs-usbv2h9egpbnuE9DypncPthzoAv2oos_RzE=@protonmail.com>
 <023af6e4-b2d2-8427-70d2-278706922af6@rocketnine.space>
 <e8219e39-20a5-4322-9e87-d55bd275e21b@drsudo.com>
 <FmrWGIqyTH8Pn7jdhDpDX72s4dJ9UPNF2M-YFS63aTnme2TlHlmSdViBxJdqYMg6MPcN8fTGaO-glRpXUgOuyrrWzihzlx2q55IwnsCPPeA=@protonmail.com>
Message-ID: <21b0d947-4f5c-231d-1eff-ed797139bb3c@qwertqwefsday.eu>

On 2020-12-24T03:45Z, colecmac at protonmail.com wrote:
>>> Someone has written one. :)
>>> gmitohtml is a Gemini proxy server.
>>> https://gitlab.com/tslocum/gmitohtml
>>
>> Forgive me if I misunderstand, but I believe the idea is to run the Gemini
>> protocol and serve gemini content, but just be able to do it on a port other
>> than 1965 (In this case, proxying gemini over the https port).
>
> To clarify, I'm talking about Gemini server that accepts request URLs with
> other hosts. Like the server runs at example.com, and will accept requests for
> example.com, gus.guru, makeworld.gq, etc. And it will make the request on your
> behalf.
>
> And then that server could run on any port, port 443 for example. This would
> be a way to get around blocking.
>
> makeworld

This topic has now been mentioned in another thread, but TOFU makes a "nice"[1]
proxy difficult:

The TLS certificate has to be sent before any content from the client is
transmitted (* remember this). This means that the proxy sends its own
certificate. Depending on how lax the client is on checking the certificates
contents, it cannot work differently.
Only after verifying the certificate is the requested URL transmitted.

Now the problem arises: How should the proxy handle the endpoint's certificate
under TOFU?

Idealy the certificate would just be forwarded by the proxy, but this is not
possible because of (*).
The proxy could do its own TOFU and allow its users to update the cert store,
but on a public proxy this could be exploited by an attacker.
The proxy could have its own "user sessions" but at that point the
implementation of the proxy would be considerably inflated IMHO.
It would probably be much cleaner to use a VPN or an SSH tunnel at that point
(and probably a zillion other ways).

[1] Whatever would be considered nice is a different point, i.e. what
     Stephane Bortzmeyer wrote on 2020-12-24T13:06Z:
     > Do note that this requires trust in the proxy [...]

Johann
---
You can verify the digital signature on this email with the public key
available through web key discovery. Try e.g. `gpg --locate-keys`...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201225/ef270839/attachment.sig>

From stephane at sources.org  Fri Dec 25 16:50:19 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 25 Dec 2020 17:50:19 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224114850.GA14763@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
 <20201223230319.GC9267@brevard.conman.org>
 <20201224114850.GA14763@localhost.localdomain>
Message-ID: <20201225165019.GA13729@sources.org>

On Thu, Dec 24, 2020 at 12:48:50PM +0100,
 marc <marcx2 at welz.org.za> wrote 
 a message of 91 lines which said:

> In this regard having people know learn a new language to interact
> with the internet isn't that much of an imposition,

Specially if it is *my* script. Imagine a chinese person asking that
all URI be in chinese characters because people can learn a new
script, after all. I bet that many proponents of ASCII URIs would not
be so happy.





From stephane at sources.org  Fri Dec 25 16:53:40 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 25 Dec 2020 17:53:40 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224134921.GA25533@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
 <20201223230319.GC9267@brevard.conman.org>
 <20201224114850.GA14763@localhost.localdomain>
 <20201224134921.GA25533@202x.moe>
Message-ID: <20201225165339.GB13729@sources.org>

On Thu, Dec 24, 2020 at 10:49:21PM +0900,
 bie <bie at 202x.moe> wrote 
 a message of 48 lines which said:

> but because I realized how hard it was to verbally convey my
> Japanese addresses to my Norwegian friends and vice versa.

I don't see the point, anyway. If the adresse (the URI) uses the
Japanese writing, it is probably because the content is in Japanese
and/or is interesting only for people who are in Japan. Therefore
either your norwegian friend is in one of these two cases, or you
wouldn't tell him/her the adress, anyway.

> The de facto universality of ASCII

No, the latin script (and even more the ASCII character set) is not
universal (even if it would be simpler for me).


From stephane at sources.org  Fri Dec 25 16:57:56 2020
From: stephane at sources.org (Stephane Bortzmeyer)
Date: Fri, 25 Dec 2020 17:57:56 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <X+On8FFDHY1qkRBX@kurosawa.casa.net>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net>
Message-ID: <20201225165756.GC13729@sources.org>

On Wed, Dec 23, 2020 at 09:26:24PM +0100,
 cage <cage-dev at twistfold.it> wrote 
 a message of 17 lines which said:

> > The individual path segments actually.
> >
> > So, given /Foo/Bar/Baz, decompose the path into individual
> > segments Foo, Bar, and Baz, encode these, and reconstruct the
> > path. Easy-peasy.

I don't think that percent-encoding has to be done per path segment. I
don't find anything in RFC 3986 that makes your algorithm
mandatory. "/" is a safe character, anyway so it seems to me that you
can percent-encode the entire path in one operation.


From cage-dev at twistfold.it  Fri Dec 25 19:55:53 2020
From: cage-dev at twistfold.it (cage)
Date: Fri, 25 Dec 2020 20:55:53 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201225165756.GC13729@sources.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net>
 <20201225165756.GC13729@sources.org>
Message-ID: <X+ZDydWt1ySKT6bm@kurosawa.casa.net>

On Fri, Dec 25, 2020 at 05:57:56PM +0100, Stephane Bortzmeyer wrote:

Hi!

> On Wed, Dec 23, 2020 at 09:26:24PM +0100,
>  cage <cage-dev at twistfold.it> wrote
>  a message of 17 lines which said:
>
> > > The individual path segments actually.
> > >
> > > So, given /Foo/Bar/Baz, decompose the path into individual
> > > segments Foo, Bar, and Baz, encode these, and reconstruct the
> > > path. Easy-peasy.
>
> I don't think that percent-encoding has to be done per path segment. I
> don't find anything in RFC 3986 that makes your algorithm
> mandatory. "/" is a safe character, anyway so it seems to me that you
> can percent-encode the entire path in one operation.

Please correct me  if i am wrong  so this means that if given a path like:

"/?/?/c"

it is safe to send to the server

"%2F%C3%A8%2F%C3%A0%2Fc"

instead of

"/%C3%A8/%C3%A0/c"

I can see that percent-decoding both  the two string above returns the
same results:  the first  path. Could  this be  the reason  because no
splitting is needed?

Bye!
C.

From petite.abeille at gmail.com  Fri Dec 25 21:54:17 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 25 Dec 2020 22:54:17 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201225120709.GA62135@202x.moe>
References: <CAFM0rObLSuwR8v2amJRf=xsLk=d_wY1n4bGMnLnq8w76S8vfuw@mail.gmail.com>
 <20201225120709.GA62135@202x.moe>
Message-ID: <19EF535B-25B0-419E-95F9-7484822B02DA@gmail.com>



> On Dec 25, 2020, at 13:07, bie <bie at 202x.moe> wrote:
> 
> All that said, I'll make another attempt at leaving this discussion (and the mailing list) again...

Still don't get it. 

You have a perfectly functional gemini server, written in C, using but the OpenBSD base system. Fabulous.

Furthermore, you sail through your English-Japanese-Norwegian workflow by the simple expedient of transliterating  all identifiers to US-ASCII, ala Unidecode!. Terrific.

To top it all, you can dictate the resulting identifiers, in plain English, over a rotary phone line to your trilingual Japanese-Norwegian friends. Much excellent.

All in all, everything is covered. Nothing to add. Nothing to take away. All set.

If tomorrow, Gemini adopts IRIs, nothing changes for you. Your setup is fully upward compatible. You do not have to lift a finger to keep going. 

All stays exactly the same for you.

Of course, no one on your setup can use IRIs. Only URIs. But they don't want IRIs anyway. No loss.

Arguably, your setup may not be fully compliant with the letter of the spec. No big deal. 99% there. No one is going to sue you. Just a hobby. 

But it's working. Today. For your needs.

On the other hand, it doesn't work for me. 

I do not like transliteration. I want native.

I want my Kabuki file to be named ?.gmi, and not kabuki.gmi, nor xn--7q8h.gmi, nor %F0%9F%91%B9.gmi. Nor any other weird encodings. ?.gmi it is.

I do not want to type ?.gmi. I want to copy & paste. I do not type identifiers by hand, nor do I dictate them over the phone. Ever. It's error prone. And annoying.

But's that me.

I do not want to be dragged to the lowest of the lowest common denominator just because you cannot be bothered to support Unicode.

But that's just me.

What I want is Unicode. Because I like to name my file ?.gmi. It's 2020. And it's important to me.

Moving to IRIs allows me to use Unicode file names. While not breaking anything on your side.

Staying with URIs prevents me from doing what I want. While not changing anything for you.

Why do you want to prevent me from using the names I want? 

I do not tell you how to name your files.

Why do you want to tell me?

This could be construed as rude.


* Unidecode! -- plain ASCII transliterations of Unicode text, Sean M. Burke, 2001



From petite.abeille at gmail.com  Fri Dec 25 22:03:26 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 25 Dec 2020 23:03:26 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201225211045.GA19683@sources.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <B2B546AC-67FB-4226-A6BE-DA8F3AA4DC64@gmail.com>
 <20201225211045.GA19683@sources.org>
Message-ID: <921F2638-396C-46F4-B1E9-F40ACE0CCDBC@gmail.com>



> On Dec 25, 2020, at 22:10, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> On Fri, Dec 25, 2020 at 10:07:37PM +0100,
> Petite Abeille <petite.abeille at gmail.com> wrote 
> a message of 8 lines which said:
> 
>>> I don't think that percent-encoding has to be done per path segment.
>> 
>> Reserved Characters gen-delims "/"
> 
> So?

You are not meant to encode the path separator if you would like to preserve the path semantic. If you do, you turn the entire path into one segment. Which is certainly not the desired effect most of the time.


From petite.abeille at gmail.com  Fri Dec 25 22:16:08 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 25 Dec 2020 23:16:08 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <X+ZDydWt1ySKT6bm@kurosawa.casa.net>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <X+ZDydWt1ySKT6bm@kurosawa.casa.net>
Message-ID: <7AA3450D-37E6-41F0-9CEC-E44E0BE24629@gmail.com>



> On Dec 25, 2020, at 20:55, cage <cage-dev at twistfold.it> wrote:
> "/?/?/c"
> 
> it is safe to send to the server
> 
> "%2F%C3%A8%2F%C3%A0%2Fc"
> 
> instead of
> 
> "/%C3%A8/%C3%A0/c"

Those are two different paths. 

The first one has one segment, with encoded separators. The second one has 3 segments, properly encoded. Which matches the semantic of your original path, which sport 3 segments ?, ?, and c.

From petite.abeille at gmail.com  Fri Dec 25 22:30:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Fri, 25 Dec 2020 23:30:43 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224114850.GA14763@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
 <20201223230319.GC9267@brevard.conman.org>
 <20201224114850.GA14763@localhost.localdomain>
Message-ID: <385D7C10-756A-4794-8FBC-3CBDE4DA6944@gmail.com>



> On Dec 24, 2020, at 12:48, marc <marcx2 at welz.org.za> wrote:
> 
> deferential to pretty recent concept/meme - the monolingual nation state

( wat? )

If I wish, out of juvenile impertinence, to name my file ?.gmi then I should be able to do so without further ado. 

I would find it patronizing to be forced to type %F0%9F%96%95.gmi .




From gemini at stillspinning.cc  Fri Dec 25 22:49:00 2020
From: gemini at stillspinning.cc (spinner)
Date: Fri, 25 Dec 2020 14:49:00 -0800
Subject: [spec] IRIs, IDNs, and all that international jazz
Message-ID: <CAFM0rOYP00wtroHbAJQOTGvnhLf6tgig6Sfatijh_SPSqPnUqQ@mail.gmail.com>

> > 4. Write links to URLs that I don't control: It'll be more
> > accessible/convenient to be able to write the URL in non-ascii
characters.
>
> I'd actually say it's just *slighty* more convenient. In most cases
> you'll be copying and pasting the URL.

I realized the original list missed one distinction: reading links using a
client as a reader vs reading links using an editor as a content author. So
the initial authoring may be done through copy-pasting, but revisiting that
piece afterwards can leave you unsure about exactly which URL a link is
pointing to, if it's all percent-encoded.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201225/60315514/attachment.htm>

From petite.abeille at gmail.com  Fri Dec 25 23:09:23 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 00:09:23 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <EE122D3B-E3AE-4A80-82C4-A2F48E81CFAC@gmail.com>



> On Dec 22, 2020, at 16:13, Solderpunk <solderpunk at posteo.net> wrote:
> 
> Okay, I'm finally getting involved in this discussion.

Thought exercise:

Each time you see URI, replace it with MORSE CODE.
Each time you see IRI, replace it with ASCII.

Debriefing at noon.


From petite.abeille at gmail.com  Fri Dec 25 23:20:22 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 00:20:22 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201223025416.GA25066@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
Message-ID: <05083825-BAB9-4D02-A8F8-0AB554D771BA@gmail.com>



> On Dec 23, 2020, at 03:54, bie <bie at 202x.moe> wrote:
> 
> doesn't have to be able to parse JPEGs to serve images.

( wat? )

Presently text/gemini mandates 3 different encoding in a link:

=> gemini://punicode/url-encoded utf8

3 different encodings in one line.

3 in 1.

Moving to IRI clean this up to 1 encoding, utf8.

1 in 1.



From list at gkbrk.com  Fri Dec 25 23:29:39 2020
From: list at gkbrk.com (Leo)
Date: Sat, 26 Dec 2020 02:29:39 +0300
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <CAFM0rOYP00wtroHbAJQOTGvnhLf6tgig6Sfatijh_SPSqPnUqQ@mail.gmail.com>
Message-ID: <C8299NHVF4OO.3L7JQZVITKHM8@rath>

Just want to let you know that your email client does not properly send
an In-Reply-To header and breaks threading.

--
Leo

From petite.abeille at gmail.com  Fri Dec 25 23:33:53 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 00:33:53 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C8299NHVF4OO.3L7JQZVITKHM8@rath>
References: <C8299NHVF4OO.3L7JQZVITKHM8@rath>
Message-ID: <98224F67-CF18-44A4-900A-9A78D65875D4@gmail.com>



> On Dec 26, 2020, at 00:29, Leo <list at gkbrk.com> wrote:
> 
> Just want to let you know that your email client does not properly send
> an In-Reply-To header and breaks threading.

This is not my experience, but I would be happy to be proven wrong, and fix it if necessary.

Could you be more specific? What does break, exactly?

From op at omarpolo.com  Sat Dec 26 00:28:32 2020
From: op at omarpolo.com (Omar Polo)
Date: Sat, 26 Dec 2020 01:28:32 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <05083825-BAB9-4D02-A8F8-0AB554D771BA@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
 <05083825-BAB9-4D02-A8F8-0AB554D771BA@gmail.com>
Message-ID: <87im8p1kcv.fsf@omarpolo.com>


Petite Abeille <petite.abeille at gmail.com> writes:

>> On Dec 23, 2020, at 03:54, bie <bie at 202x.moe> wrote:
>> 
>> doesn't have to be able to parse JPEGs to serve images.
>
> ( wat? )
>
> Presently text/gemini mandates 3 different encoding in a link:
>
> => gemini://punicode/url-encoded utf8
>
> 3 different encodings in one line.
>
> 3 in 1.
>
> Moving to IRI clean this up to 1 encoding, utf8.
>
> 1 in 1.

Not really.  I don't know basically anything about punycode so I can't
comment on that, but IRI allows percent encoding too.

From op at omarpolo.com  Sat Dec 26 00:32:00 2020
From: op at omarpolo.com (Omar Polo)
Date: Sat, 26 Dec 2020 01:32:00 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224133643.GA424@202x.moe>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
 <20201224133643.GA424@202x.moe>
Message-ID: <87ft3t1k73.fsf@omarpolo.com>


bie <bie at 202x.moe> writes:
>
> You're kind of correct in the sense that if we just treat the request as
> arbitrary bytes and not as an IRI (no validation, no handling at all),
> it's simple, but I don't think that's the right way to look at this
> issue. Instead, it's about the complexity of proper URI handling vs
> proper IRI handling. Not to mention that IRIs can still have
> percent-encoded characters!

Sorry if it took long for the reply, but I took some time to fix up my
server and now here I am :)

Originally, when I wrote my server I did a really simple routine to
extract the path from a url and that's it.  (plus minor checking)  This
wasn't good, of course.

In the last two days I took the time to write first a proper URL
parser[0], and than extending it to support IRIs[1].  Turns out, once
you have a URL parser (not hard to do at all), you almost have a
complete IRI parser.  As Sean wrote, you basically have to replace the
unreserved rule to allow other utf8 characters and you're done.  And
even if you're uncomfortable doing this, the RFC lists the valid ranges,
so adding a couple of checks isn't the end of the world (if you want to
be 100% compliant, whatever that means).

(And all of this comes from one that has never, ever, implemented a
IRI/URI parser before, that has read for the first time the rfc3986
while writing the code and has successfully -- I believe -- implemented
a full IRI parser in less than 500 lines of C, with comments and
everything, without using anything other than the standard library.
Heck, the parser doesn't even allocates memory.)

> After thinking about this for a while, the biggest issue for me is that
> this is a breaking change. Breaking in the sense that it breaks *every
> single compliant server we already have*! If gemini, which has been
> surprisingly good at resisting breaking spec changes, accepts this, I
> don't see any reason to believe that it won't happen again and again,
> for equally silly reasons.
>
> bie

I don't buy this argument.  It's not like tomorrow we won't be able to
browse gemini unless we update clients/servers.  Valid URI are also
valid IRI, so it's not an armageddon.  The whole thing started (IIRC)
because the spec says "UTF8 URI".  Furthermore, the spec isn't finalised
yet (see for instance the change regarding full url vs relative ones in
the requests).

If you wrote your server for you, you probably won't need to change
anything: from what you wrote, I assume you're serving only files whose
names are ASCII only, so unless you want to host things with funny
names, you're probably good.

Anyway, sorry for the long reply, I didn't want to drag this discussion
too much, really.  Let's see what will be decided :)

Cheers!

[0]:
https://github.com/omar-polo/gmid/commit/33d32d1fd66a577f22f3f33f238e8dac44ec9995
[1]: https://github.com/omar-polo/gmid/commit/df6ca41da36c3f617cbbf3302ab120721ebfcfd2

From petite.abeille at gmail.com  Sat Dec 26 00:32:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 01:32:48 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <87im8p1kcv.fsf@omarpolo.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
 <05083825-BAB9-4D02-A8F8-0AB554D771BA@gmail.com>
 <87im8p1kcv.fsf@omarpolo.com>
Message-ID: <20D3D223-235B-4C4F-9271-4B8C0D479FDF@gmail.com>



> On Dec 26, 2020, at 01:28, Omar Polo <op at omarpolo.com> wrote:
> 
> Not really.  I don't know basically anything about punycode so I can't
> comment on that, but IRI allows percent encoding too.

Surprise me. Here is my IRI: 

gemini://?/?.gmi 

Show me your URI, and then, justify why it a good thing for me.




From op at omarpolo.com  Sat Dec 26 00:41:50 2020
From: op at omarpolo.com (Omar Polo)
Date: Sat, 26 Dec 2020 01:41:50 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20D3D223-235B-4C4F-9271-4B8C0D479FDF@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
 <05083825-BAB9-4D02-A8F8-0AB554D771BA@gmail.com>
 <87im8p1kcv.fsf@omarpolo.com>
 <20D3D223-235B-4C4F-9271-4B8C0D479FDF@gmail.com>
Message-ID: <87czyx1jqp.fsf@omarpolo.com>


Petite Abeille <petite.abeille at gmail.com> writes:

>> On Dec 26, 2020, at 01:28, Omar Polo <op at omarpolo.com> wrote:
>> 
>> Not really.  I don't know basically anything about punycode so I can't
>> comment on that, but IRI allows percent encoding too.
>
> Surprise me. Here is my IRI: 
>
> gemini://?/?.gmi 
>
> Show me your URI, and then, justify why it a good thing for me.

Sorry, I wasn't saying that gemini://?/%F0%9F%91%B9.gmi [0] is better
than gemini://?/?.gmi (it is not).  Rather, than even with
IRIs you don't want to delete the percent-decoding code in your parser.

[0]     idn2 refuses to punycode ? :/

From petite.abeille at gmail.com  Sat Dec 26 00:47:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 01:47:28 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <87czyx1jqp.fsf@omarpolo.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe>
 <05083825-BAB9-4D02-A8F8-0AB554D771BA@gmail.com>
 <87im8p1kcv.fsf@omarpolo.com>
 <20D3D223-235B-4C4F-9271-4B8C0D479FDF@gmail.com>
 <87czyx1jqp.fsf@omarpolo.com>
Message-ID: <1C7DAF65-844C-4124-93EE-23ECD1CC51BA@gmail.com>



> On Dec 26, 2020, at 01:41, Omar Polo <op at omarpolo.com> wrote:
> 
> Sorry

Let's recap:

IRI gemini://?/?.gmi 
URI gemini://xn--el8h/%F0%9F%91%B9.gmi

? reserved characters which always needs to be encoded, irrespectively of any other consideration. 

From petite.abeille at gmail.com  Sat Dec 26 01:34:33 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 02:34:33 +0100
Subject: [spec] <URL> is a UTF-8 erratum
Message-ID: <F0AFB303-DA11-4719-9190-84E68A853A5C@gmail.com>

The spec says, as of v0.14.3, November 29th 2020, under # 2 Gemini requests:

<URL> is a UTF-8 encoded absolute URL, including a scheme, of maximum length 1024 bytes. 

This is wrong.

What's wrong is URL. It should read IRI instead, to make it consistent with UTF-8. An URL cannot be UTF-8, while an IRI can. As UTF-8 precedes URL in the sentence, UTF-8 has to take precedence.

I suggest the following correction:

<URL> is a UTF-8 encoded absolute IRI, including a scheme, of maximum length 4,096* bytes. 

* Note the increase in size, to compensate for the consistent use of UTF-8 encoding.

To avoid confusion further down the document (inconsistent use of URL vs. URI. vs IRI), I would suggest to systematically refer to IRI for all of them.

Which gives us:

<IRI> is a UTF-8 encoded absolute IRI, including a scheme, of maximum length 4,096 bytes. 




From jmcbray at carcosa.net  Sat Dec 26 02:33:53 2020
From: jmcbray at carcosa.net (Jason McBrayer)
Date: Fri, 25 Dec 2020 21:33:53 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224133643.GA424@202x.moe> (bie@202x.moe's message of "Thu, 
 24 Dec 2020 22:36:43 +0900")
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
 <20201224133643.GA424@202x.moe>
Message-ID: <874kk947ou.fsf@cassilda.carcosa.net>

bie <bie at 202x.moe> writes:

> After thinking about this for a while, the biggest issue for me is
> that this is a breaking change. Breaking in the sense that it breaks
> *every single compliant server we already have*!

I think that's a little dramatic. Looking at my server, I need to make a
change in exactly one place: when mapping IRI paths to file paths, I
can no longer use the url decoding library I was using to decode URI
paths, because it mangles Unicode characters. But since I can now be
sure that only IRI reserved characters are encoded, I can just do a
simple substring substitution. It's also a change that is
backward-compatible with old clients.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

From steve at tryingtobeawesome.com  Sat Dec 26 02:54:15 2020
From: steve at tryingtobeawesome.com (Steve Phillips)
Date: Fri, 25 Dec 2020 18:54:15 -0800
Subject: [spec] IRIs, IDNs, and all that international jazz
Message-ID: <CANSQPTgTcSDgU=RPJQVtdMEwCZ3DNJJv-T8Uea23ANT+vZHVzQ@mail.gmail.com>

> gemini://?/?.gmi

Must we permit question marks in Gemini domains at all?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201225/34c7469a/attachment.htm>

From petite.abeille at gmail.com  Sat Dec 26 11:01:14 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 12:01:14 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <CANSQPTgTcSDgU=RPJQVtdMEwCZ3DNJJv-T8Uea23ANT+vZHVzQ@mail.gmail.com>
References: <CANSQPTgTcSDgU=RPJQVtdMEwCZ3DNJJv-T8Uea23ANT+vZHVzQ@mail.gmail.com>
Message-ID: <CB75DEAB-6E54-4F9A-9EBF-D17F15E50FC1@gmail.com>



> On Dec 26, 2020, at 03:54, Steve Phillips <steve at tryingtobeawesome.com> wrote:
> 
> Must we permit question marks in Gemini domains at all?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201226/02855a15/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nq050816.gif
Type: image/gif
Size: 29260 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201226/02855a15/attachment-0001.gif>

From cage-dev at twistfold.it  Sat Dec 26 12:10:24 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 26 Dec 2020 13:10:24 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <7AA3450D-37E6-41F0-9CEC-E44E0BE24629@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net>
 <20201225165756.GC13729@sources.org>
 <X+ZDydWt1ySKT6bm@kurosawa.casa.net>
 <7AA3450D-37E6-41F0-9CEC-E44E0BE24629@gmail.com>
Message-ID: <X+coMN+fDj8JFTsg@kurosawa.casa.net>

On Fri, Dec 25, 2020 at 11:16:08PM +0100, Petite Abeille wrote:

Hi!

>
> > On Dec 25, 2020, at 20:55, cage <cage-dev at twistfold.it> wrote:
> > "/?/?/c"
> >
> > it is safe to send to the server
> >
> > "%2F%C3%A8%2F%C3%A0%2Fc"
> >
> > instead of
> >
> > "/%C3%A8/%C3%A0/c"
>
> Those are two different paths.
>  The first one has one  segment, with encoded separators. The second
> one has 3 segments, properly  encoded. Which matches the semantic of
> your original path, which sport 3 segments ?, ?, and c.

This makes sense to me!

Thanks!
C.

From solderpunk at posteo.net  Sat Dec 26 11:08:54 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 12:08:54 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <87ft3t1k73.fsf@omarpolo.com>
Message-ID: <C82O517SM9LU.3UJUE8UO0XVA6@stilgar>

On Sat Dec 26, 2020 at 1:32 AM CET, Omar Polo wrote:

> In the last two days I took the time to write first a proper URL
> parser[0], and than extending it to support IRIs[1]. Turns out, once
> you have a URL parser (not hard to do at all), you almost have a
> complete IRI parser. As Sean wrote, you basically have to replace the
> unreserved rule to allow other utf8 characters and you're done. And
> even if you're uncomfortable doing this, the RFC lists the valid ranges,
> so adding a couple of checks isn't the end of the world (if you want to
> be 100% compliant, whatever that means).
>
> (And all of this comes from one that has never, ever, implemented a
> IRI/URI parser before, that has read for the first time the rfc3986
> while writing the code and has successfully -- I believe -- implemented
> a full IRI parser in less than 500 lines of C, with comments and
> everything, without using anything other than the standard library.
> Heck, the parser doesn't even allocates memory.)

This is, more and more, how I'm conceptualising things.
Parsing/validating IRIs is not actually remotely difficult at all.
Algorithmically it's an extremely minor change to parsing/validating
URIs.  The apparent pain exists only because the world has apparently
been very slow about packaging code up for this into major
libraries/languages, probably because HTTP's ASCII-only nature reduces
demand.  If we adopt IRIs, I would actually encourage Gemini software
authors who find their language lacking tools for this not to write
custom code for it that lives only in their software, but to actually
try to get the functionality accepted upstream into standard libraries,
or widely used third-party libraries.  This is generally useful
functionality that's in no way Gemini-specific, and having easy support
for it everywhere makes the world a better place regardless of whether
Gemini thrives or declines.

I don't really think the alleged difficulty of handling IRIs is a good
argument against accepting them.  I'm now more interested in
learning/thinking about normalisation issues, which have been relatively
under discussed so far.  It's possible this is where the real trouble
lies.  Breaking a UTF-8 IRI up into (scheme, authority, path) is not a
substantial hurdle.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sat Dec 26 11:19:18 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 12:19:18 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224114850.GA14763@localhost.localdomain>
Message-ID: <C82OD012FZJ0.3G0MZ0S83C0RO@stilgar>

On Thu Dec 24, 2020 at 12:48 PM CET, marc wrote:

> Note how the global telephone system has made it into the furthest
> corners of the planet - arguably further than the internet, and did
> so without worrying about internationalisation relating to their
> URL equivalents (phone numbers)...

This is not really a compelling comparison at all.  Even if different
languages and cultures use different words and symbols for numbers, the
overwhelming majority of them use base 10, meaning there is a
straightforward and unambiguous mapping between them all.  Almost
anybody can read/write and say/hear a phone number in their native
language, making it much easier to memorise and transmit them.  I don't
know if it was ever done (I wouldn't be at all surprised if it was), but
it would be no technical problem at all to manufacture either a DTMF or
rotary phoneset which had ?, ?, ?, etc. printed on it instead of 1,
2, 3 and have it work correctly anywhere on Earth.  Even if this couldn't
be done and people had to learn a foreign system of numeric symbols,
the fact that there's only 10 of them and that they map directly to
native equivalents makes them much easier to learn.  And, of course, the
Arabic numeral system was already widely used across many languages and
cultures before the phone system arrived, and people in all cultures
already had practice reading, writing and memorising numeric values for
many other reasons (calendars and money are ancient technology).

Cheers,
Solderpunk

From solderpunk at posteo.net  Sat Dec 26 12:12:17 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 13:12:17 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224142947.GA11963@sources.org>
Message-ID: <C82PHK0R8XZY.1SRLNILFWOVPP@stilgar>

On Thu Dec 24, 2020 at 3:29 PM CET, Stephane Bortzmeyer wrote:

> Once the specification is "officially" "final",
> this will be different. AFAIK, it is not the case (otherwise, what
> would be the point of the [spec] topic?)

Anybody could be forgiven for not inferring it from actually looking at
what gets posted to [spec], but the main reason there's a venue for
discussing spec finalisation at all is that there are still lots of
things to be done at the level of "crossing t's and dotting i's".  For
example, somebody recently reminded me off-list that the spec is still
silent on the question of whether or not servers need to use TLS's
close_notify mechanism once they're done sending a response, or whether
it's okay to simply close the TCP connection.  Or see also the fragment
related stuff that people have been posting about  Stuff like this, that
is to say small but important technical details and edge cases, is
actually what I consider the most important task of the [spec] topic.
This stuff ought to be finalised before a formal RFC-style specification
can be written up and potentially submitted to IETF.

The possible change to using IRIs is *by far* the most major change I
have considered making in probably a year.  I do not expect to ever
consider anything this large again, ever (meaning that the fear of
adopting IRIs being a slippery slope to more drastic changes in the
future is unfounded).  I'm taking my time on it because it's a major
change and because internationalisation is IMHO a very important issue,
but make no mistake -  I cannot *wait* for it to done so we can focus
on the smaller, hopefully much less contentious, details and get the
whole thing finalised.

I really consider Gemini 100% complete in terms of scope/capabilities.
People are doing wonderful things with it as is, it's basically
everything I ever dreamed of.  I am very ready to transition to spending
10 x more time and energy reading and writing Gemini content than
managing the protocol.

Cheers,
Solderpunk

From bie at 202x.moe  Sat Dec 26 15:12:01 2020
From: bie at 202x.moe (bie)
Date: Sun, 27 Dec 2020 00:12:01 +0900
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C82O517SM9LU.3UJUE8UO0XVA6@stilgar>
References: <87ft3t1k73.fsf@omarpolo.com> <C82O517SM9LU.3UJUE8UO0XVA6@stilgar>
Message-ID: <20201226151201.GA12387@202x.moe>

> This is, more and more, how I'm conceptualising things.
> Parsing/validating IRIs is not actually remotely difficult at all.
> Algorithmically it's an extremely minor change to parsing/validating
> URIs.  The apparent pain exists only because the world has apparently
> been very slow about packaging code up for this into major
> libraries/languages, probably because HTTP's ASCII-only nature reduces
> demand.  If we adopt IRIs, I would actually encourage Gemini software
> authors who find their language lacking tools for this not to write
> custom code for it that lives only in their software, but to actually
> try to get the functionality accepted upstream into standard libraries,
> or widely used third-party libraries.  This is generally useful
> functionality that's in no way Gemini-specific, and having easy support
> for it everywhere makes the world a better place regardless of whether
> Gemini thrives or declines.
> 
> I don't really think the alleged difficulty of handling IRIs is a good
> argument against accepting them.  I'm now more interested in
> learning/thinking about normalisation issues, which have been relatively
> under discussed so far.  It's possible this is where the real trouble
> lies.  Breaking a UTF-8 IRI up into (scheme, authority, path) is not a
> substantial hurdle.

This is enough of a decision for me, so I'm out. I'm not one to stand in
the way of "progress", however misguided, so I've taken down my 4 gemini
servers.

bie

From solderpunk at posteo.net  Sat Dec 26 14:12:45 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 15:12:45 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
Message-ID: <C82S1SRJ1KCC.FMHALL9DFJKL@stilgar>

On Tue Dec 22, 2020 at 9:34 PM CET, John Cowan wrote:

Given the potential for "what should fragments mean/do in Gemini?" to
turn into yet another endless discussion, and given their relatively low
importance (Gopher has survived without them for 30 years and I,
personally, don't remember ever really missing them in that context),
I'm tempted to take quite seriously Petite Abeille's suggestion to
simply remove them entirely.  However, for the sake of responding
coherently to other issues raised in this thread, let's suppose
fragments hang around:

> 1) Clients MUST NOT send a fragment to the server.

I agree with this, and would be happy to make it explicit in the spec.

> 2) If the client gets a redirect containing a fragment, the client MUST
> apply this fragment when the redirected resource is retrieved, ignoring
> any
> original fragment.
>
> 3) If the original URL has a fragment and the redirect doesn't, the
> client
> MUST apply the original fragment when the redirected resource is
> retrieved.

This I'm not so clear on.  If a server receives a request for a URL
which doesn't include a fragment (which everybody seems to agree is how
things should work), why on Earth would it want to redirect to a URL
which *does* have a fragment?  The only case I can think of where this
might be useful is if multiple separate documents were merged into a
single document, with fragments pointing to the distinct subsections
which used to stand alone.  That's neat, but is it so important that we
should support it instead of doing the brutually simple thing of just
saying that redirect URLs, like request URLs, should not include
fragments, and that following a redirect involves completely discarding
the previous URL (including fragments)?  Carrying stuff across between
distinct requests feels a bit ugly to me.

Cheers,
Solderpunk

From solderpunk at posteo.net  Sat Dec 26 15:01:39 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 16:01:39 +0100
Subject: [spec] <URL> is a UTF-8 erratum
In-Reply-To: <F0AFB303-DA11-4719-9190-84E68A853A5C@gmail.com>
Message-ID: <C82T38LZQGT2.3VAFFEB8JVNZX@stilgar>

On Sat Dec 26, 2020 at 2:34 AM CET, Petite Abeille wrote:
> The spec says, as of v0.14.3, November 29th 2020, under # 2 Gemini
> requests:
>
> <URL> is a UTF-8 encoded absolute URL, including a scheme, of maximum
> length 1024 bytes.
>
> This is wrong.
>
> What's wrong is URL. It should read IRI instead, to make it consistent
> with UTF-8. An URL cannot be UTF-8, while an IRI can. As UTF-8 precedes
> URL in the sentence, UTF-8 has to take precedence.

I've already made it very clear in the main [spec] thread for this topic
that whether we adopt IRIs or not, the use of "UTF-8 encoded URL" should
be fixed, as it is likely to cause confusion.  Rest assured, when the
decision is made, this will be fixed accordingly.  There's no need to
split the thread over this.

It's not true that URLs cannot be UTF-8.  In fact, the opposite is true.
The characters valid in a URL are a subset of those which can be
represented in ASCII, and all byte strings which are valid ASCII are also
valid UTF-8, with equivalent decodings.  Hence, *every* URL is UTF-8.
So there. :p

The idea that, as a general principle, when an existing sentence in the
spec is ambiguous or inconsistent, the problem should be resolved by
granting absolute priority to whichever term occurs first in the current
form of the sentence is, plainly, absurd.

It's probably not a hill I'll choose to die on when it comes time to
update the spec based on the IRI decision, but personally I reject the
modern notion that the URL/URN (or IRL/IRN) distinction is not important
and thus everything should be specified at maximum generality as a URI
(or IRN).  The difference matters and protocols/formats should choose
appropriately.  The practical question of how to handle a text/gemini
document becomes *considerably* murkier when link lines contain URNs (of
course, you and I know this quite well already).

Cheers,
Solderpunk

From solderpunk at posteo.net  Sat Dec 26 15:20:30 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 16:20:30 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201226151201.GA12387@202x.moe>
Message-ID: <C82THO90S5JA.2RLL7LXVUSQ4T@stilgar>

On Sat Dec 26, 2020 at 4:12 PM CET, bie wrote:

> This is enough of a decision for me, so I'm out. I'm not one to stand in
> the way of "progress", however misguided, so I've taken down my 4 gemini
> servers.

I'm, genuinely and sincerely, sorry to hear this.  Thanks for having run
them for the time you did.  The final decision is still to be made and
in the even that I end up backtracking on this, I hope you'll
reconsider.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sat Dec 26 15:25:05 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 16:25:05 +0100
Subject: [spec] <URL> is a UTF-8 erratum
In-Reply-To: <C82T38LZQGT2.3VAFFEB8JVNZX@stilgar>
References: <C82T38LZQGT2.3VAFFEB8JVNZX@stilgar>
Message-ID: <E404751B-3C24-4C1F-AB95-E604AA5E5C50@gmail.com>



> On Dec 26, 2020, at 16:01, Solderpunk <solderpunk at posteo.net> wrote:
> 
> Hence, *every* URL is UTF-8. So there. :p

A subset thereof :D

> plainly, absurd.

Yes. And yet, we need a bit of formalism in the spec. 

>  (of course, you and I know this quite well already).

Indeed. The rabbit hole is deep.

From nervuri at disroot.org  Sat Dec 26 15:27:07 2020
From: nervuri at disroot.org (nervuri)
Date: Sat, 26 Dec 2020 15:27:07 +0000
Subject: [Tech] [Spec] TOFU or not TOFU?
In-Reply-To: <6BFA112E-9C99-4367-A66F-32376EB6CDED@gmail.com>
References: <6BFA112E-9C99-4367-A66F-32376EB6CDED@gmail.com>
 <20201224151421.GA14047@sources.org>
Message-ID: <927b9d62efd327725b57324c5445cdf9@disroot.org>

> I know a lot of people disagree with me here, but I have yet to see an argument that can convince me that CN, SAN, not-valid-before or not-valid-after have any bearing on the security of the certificate or give me as a user any information that helps me make a safe decision. All of these fields are crucial in a CA validation scheme, but only add a false sense of security in TOFU.

When making self-signed certs for my domains, I make sure that all fields are correct and set the expiration date years into the future. If any of the fields don't match, I want that to be seen as indication that something isn't right. This might be good enough to prevent a sloppy attempt at interception.

Some admins are not as careful about their certs, but that's on them. As long as we're using X.509, the browser should inform the user of any discrepancies.

As for renewal of CA-signed certs: when receiving a new cert from the same CA, if the old cert is within 30 days of expiration, the browser could either silently accept it, or show the user a notice along the lines of: "The old certificate is about to expire in 20 days, renewal in this time frame is expected. Do you want to continue?".

For crawlers like Lupa, sure, there's no need for any kind of cert validation, except for generating TLS-related statistics, which would be quite interesting.

From cage-dev at twistfold.it  Sat Dec 26 15:32:10 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 26 Dec 2020 16:32:10 +0100
Subject: [spec] adding a "magic number" for gemini files
Message-ID: <X+dXetNKqh2ju2ys@kurosawa.casa.net>

Hi!

I think  a lot of  guesswork is needed  (line finding link  lines with
gemini  scheme?), for  example, to  discriminate between  markdown and
gemini file format.

I wonder if  a magic number (three, maybe four  chars?) could be added
on the first line of each file.

Bye!
C.

From petite.abeille at gmail.com  Sat Dec 26 15:35:49 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 16:35:49 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <C82S1SRJ1KCC.FMHALL9DFJKL@stilgar>
References: <C82S1SRJ1KCC.FMHALL9DFJKL@stilgar>
Message-ID: <63504ACC-EF36-4B0E-9685-AD2194D20FD0@gmail.com>



> On Dec 26, 2020, at 15:12, Solderpunk <solderpunk at posteo.net> wrote:
> 
> simply remove them entirely

Alternatively, ignore them, but explicitly. i.e. some verbiage to the effect of "while fragments are allowed in IRIs, they do not have any special meaning in gemini".

Perhaps someone will come up with an interesting use case in the future. 

In the meantime, fragment = undefined behavior for now.

My 2?.







From solderpunk at posteo.net  Sat Dec 26 15:34:25 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 16:34:25 +0100
Subject: [spec] adding a "magic number" for gemini files
In-Reply-To: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
Message-ID: <C82TSBUY1QBI.UNG3VL20MGXD@stilgar>

On Sat Dec 26, 2020 at 4:32 PM CET, cage wrote:

> I think a lot of guesswork is needed (line finding link lines with
> gemini scheme?), for example, to discriminate between markdown and
> gemini file format.

When is this really necessary?  Both Gemini and HTTP provide a means to
inform the client what's coming down the pipe.  For files distributed
otherwise, filename conventions would seem to do the trick.

> I wonder if a magic number (three, maybe four chars?) could be added
> on the first line of each file.

This feels like too much complexity for too little benefit to me.
Plenty of people write their text/gemini content by hand with a standard
text editor.  Many of them will forget to add the magic number.  What
should a client do when it receives a file which the server declares as
text/gemini but which doesn't have the magic number?  This creates more
questions/problems than it solves.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sat Dec 26 15:40:55 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 16:40:55 +0100
Subject: [spec] adding a "magic number" for gemini files
In-Reply-To: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
References: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
Message-ID: <4E201954-D64A-4B2F-9B93-E7DBF5486B9A@gmail.com>



> On Dec 26, 2020, at 16:32, cage <cage-dev at twistfold.it> wrote:
> 
> I wonder if  a magic number (three, maybe four  chars?) could be added
> on the first line of each file.

No*. 

We still pay the price for that BOM abomination. No need to double down.

That said, there are other signs, such as link sequences '=> '.

Otherwise, text/gemini is, rightly, identified as text/plain;charset=utf-8;. 

Why do you need more?

* This is my personal opinion, not an authoritative answer :D


From cage-dev at twistfold.it  Sat Dec 26 15:54:22 2020
From: cage-dev at twistfold.it (cage)
Date: Sat, 26 Dec 2020 16:54:22 +0100
Subject: [spec] adding a "magic number" for gemini files
In-Reply-To: <C82TSBUY1QBI.UNG3VL20MGXD@stilgar>
References: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
 <C82TSBUY1QBI.UNG3VL20MGXD@stilgar>
Message-ID: <X+dcrk/JFdyccE/J@kurosawa.casa.net>

On Sat, Dec 26, 2020 at 04:34:25PM +0100, Solderpunk wrote:
> On Sat Dec 26, 2020 at 4:32 PM CET, cage wrote:
>
> > I think a lot of guesswork is needed (line finding link lines with
> > gemini scheme?), for example, to discriminate between markdown and
> > gemini file format.
>
> When is this really necessary?  Both Gemini and HTTP provide a means to
> inform the client what's coming down the pipe.  For files distributed
> otherwise, filename conventions would seem to do the trick.

I was  thinking abot file(1) and  libmagic in general.

> > I wonder if a magic number (three, maybe four chars?) could be added
> > on the first line of each file.
>
> This feels like too much complexity for too little benefit to me.
> Plenty of people write their text/gemini content by hand with a standard
> text editor.  Many of them will forget to add the magic number.  What
> should a client do when it receives a file which the server declares as
> text/gemini but which doesn't have the magic number?  This creates more
> questions/problems than it solves.

Anyway  i agree this was a silly proposal, thank you for you reply! :)
Bye!
C.

From petite.abeille at gmail.com  Sat Dec 26 15:56:50 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 16:56:50 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201226151201.GA12387@202x.moe>
References: <87ft3t1k73.fsf@omarpolo.com> <C82O517SM9LU.3UJUE8UO0XVA6@stilgar>
 <20201226151201.GA12387@202x.moe>
Message-ID: <642D9779-B94B-480B-87FC-9FE3530DFF35@gmail.com>



> On Dec 26, 2020, at 16:12, bie <bie at 202x.moe> wrote:
> 
> so I've taken down my 4 gemini servers.

This is your prerogative. Sounds like a tantrum though. Disappointing both ways. C'est la vie.

From petite.abeille at gmail.com  Sat Dec 26 16:10:35 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 17:10:35 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <642D9779-B94B-480B-87FC-9FE3530DFF35@gmail.com>
References: <87ft3t1k73.fsf@omarpolo.com> <C82O517SM9LU.3UJUE8UO0XVA6@stilgar>
 <20201226151201.GA12387@202x.moe>
 <642D9779-B94B-480B-87FC-9FE3530DFF35@gmail.com>
Message-ID: <1A80A37E-4AC0-476C-BE23-5B05D668AD2E@gmail.com>



> On Dec 26, 2020, at 16:56, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> tantrum

rage-quit from 6 years old on:

rage-quit, verb, INFORMAL, US, angrily abandon an activity or pursuit that has become frustrating, especially the playing of a video game.

Now we know.

From solderpunk at posteo.net  Sat Dec 26 16:12:20 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sat, 26 Dec 2020 17:12:20 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <1A80A37E-4AC0-476C-BE23-5B05D668AD2E@gmail.com>
Message-ID: <C82ULCUUIOUM.3KNHXJRRBIKYP@stilgar>

On Sat Dec 26, 2020 at 5:10 PM CET, Petite Abeille wrote:

> > On Dec 26, 2020, at 16:56, Petite Abeille <petite.abeille at gmail.com> wrote:
> > 
> > tantrum
>
> rage-quit from 6 years old on:
>
> rage-quit, verb, INFORMAL, US, angrily abandon an activity or pursuit
> that has become frustrating, especially the playing of a video game.

People are free to shutdown their servers whenever they want, whyever
they want.  There's no need to taunt them for it.  Please just let it
go.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sat Dec 26 16:18:56 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 17:18:56 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C82ULCUUIOUM.3KNHXJRRBIKYP@stilgar>
References: <C82ULCUUIOUM.3KNHXJRRBIKYP@stilgar>
Message-ID: <8BBEF65A-E7D9-4BA7-93C7-01BEB85286C5@gmail.com>



> On Dec 26, 2020, at 17:12, Solderpunk <solderpunk at posteo.net> wrote:
> 
> People are free to shutdown their servers whenever they want, whyever
> they want.  

Agree.

> There's no need to taunt them for it.

There is a qualitative difference in publicly "threatening" to do so: one can always move on quietly.

>  Please just let it go.

Water under the bridge.


From nervuri at disroot.org  Sat Dec 26 16:28:39 2020
From: nervuri at disroot.org (nervuri)
Date: Sat, 26 Dec 2020 16:28:39 +0000
Subject: [tech] [spec] Decide on use of URL fragment
In-Reply-To: <fff3a41016125eb1482e87c12e2ed55b@disroot.org>
References: <fff3a41016125eb1482e87c12e2ed55b@disroot.org>
Message-ID: <bb9320004602c48e823be97470ccac21@disroot.org>

> Finally, the fragment may also be used for other purposes. For instance, a hash could be used by the browser to check if a page has been modified, or if a file has been downloaded correctly. So it might be wise to use prefixes, like #find= and #hash:sha256=.

Two more quirky ideas for alternate uses of fragments:

* content-length (#size=1436) - can be added automatically in a server-generated file listing. Optionally, a Gemini server could append #size= to all links pointing to domains which it hosts. And browsers could limit their use of #size to instances where the destination file is hosted on the same domain as the page that links to it.

* certificate fingerprint (#cert:sha256=EB07E03...) - embeds a server's (or a user's) perspective on the cert used by a linked-to domain. Can be periodically refreshed by the server. If it doesn't match, browser shows a warning.

From petite.abeille at gmail.com  Sat Dec 26 16:35:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 17:35:39 +0100
Subject: [tech] [spec] Decide on use of URL fragment
In-Reply-To: <bb9320004602c48e823be97470ccac21@disroot.org>
References: <fff3a41016125eb1482e87c12e2ed55b@disroot.org>
 <bb9320004602c48e823be97470ccac21@disroot.org>
Message-ID: <1B8BC1F1-B5AE-4B74-9D86-BB4D75FE3FD6@gmail.com>



> On Dec 26, 2020, at 17:28, nervuri <nervuri at disroot.org> wrote:
> 
> Two more quirky ideas for alternate uses of fragments:

Oh my... perhaps you should not have mentioned all these use cases so explicitly... another side channel to kill :D

The choices are clear:

(1) Keep fragments, and define their behavior in minute, baroque details.
(2) Keep them, but mark them as "undefined", i.e. anything goes.
(3) Kill them altogether.

I would just kill them in the context of gemini.

From come at chilliet.eu  Sat Dec 26 17:19:37 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me_Chilliet?=)
Date: Sat, 26 Dec 2020 18:19:37 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <874kk947ou.fsf@cassilda.carcosa.net>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
 <20201224133643.GA424@202x.moe> <874kk947ou.fsf@cassilda.carcosa.net>
Message-ID: <7098817A-CC31-4B6A-9EB8-7A4D82B3907E@chilliet.eu>

I'm pretty sure this is not true. In all cases (uri/iri), percent encoding is allowed for any character, so the server has to percent-decode paths segment before using them to match a file.

Unless gemini goes for a more severe specification which only allows percent-encoding for reserved characters. But this may break a lot of client code.

From petite.abeille at gmail.com  Sat Dec 26 19:06:06 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 20:06:06 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <7098817A-CC31-4B6A-9EB8-7A4D82B3907E@chilliet.eu>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
 <20201224133643.GA424@202x.moe> <874kk947ou.fsf@cassilda.carcosa.net>
 <7098817A-CC31-4B6A-9EB8-7A4D82B3907E@chilliet.eu>
Message-ID: <1854F67D-A1C4-480C-8B2A-BC25EC7BEC2D@gmail.com>



> On Dec 26, 2020, at 18:19, C?me Chilliet <come at chilliet.eu> wrote:
> 
> percent-decode paths segment

Do try it and then report back your findings.


From petite.abeille at gmail.com  Sat Dec 26 19:30:33 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 20:30:33 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <1854F67D-A1C4-480C-8B2A-BC25EC7BEC2D@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <1B2B8574-0E61-41A6-B815-5E28E35DDDF6@gmail.com>
 <20201223013723.GA90439@202x.moe>
 <DB75EC71-BE31-4677-AF6E-1873CFBEC282@gmail.com>
 <20201223025416.GA25066@202x.moe> <87lfdn74zv.fsf@omarpolo.com>
 <20201224133643.GA424@202x.moe> <874kk947ou.fsf@cassilda.carcosa.net>
 <7098817A-CC31-4B6A-9EB8-7A4D82B3907E@chilliet.eu>
 <1854F67D-A1C4-480C-8B2A-BC25EC7BEC2D@gmail.com>
Message-ID: <5523ACF3-615E-40C7-B663-79F279821C44@gmail.com>



> On Dec 26, 2020, at 20:06, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
>> On Dec 26, 2020, at 18:19, C?me Chilliet <come at chilliet.eu> wrote:
>> 
>> percent-decode paths segment
> 
> Do try it and then report back your findings.

For example, do try to roundtrip one path segment: "A/B Testing". 

Do show what happens in each case.


From petite.abeille at gmail.com  Sat Dec 26 20:28:59 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 21:28:59 +0100
Subject: [user] psa: killfile
Message-ID: <E8F6E982-59F2-46FC-9716-BF9FDE729C38@gmail.com>

"A kill file (also killfile, bozo bin or twit list) is a file used by some ... reading programs to discard articles matching some unwanted patterns of subject, author, or other header lines. Adding a person or subject to one's kill file means that person or topic will be ignored by one's ... reader in the future. By extension, the term may be used for a decision to ignore the person or subject in other media."

https://en.wikipedia.org/wiki/Kill_file
https://en.wikipedia.org/wiki/Plonk_(Usenet)

Perhaps of practical use.


From gemini#lists.orbitalfox.eu#v1 at kaction.cc  Sat Dec 26 20:38:44 2020
From: gemini#lists.orbitalfox.eu#v1 at kaction.cc (Dmitry Bogatov)
Date: Sat, 26 Dec 2020 20:38:44 GMT
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <19EF535B-25B0-419E-95F9-7484822B02DA@gmail.com>
References: <CAFM0rObLSuwR8v2amJRf=xsLk=d_wY1n4bGMnLnq8w76S8vfuw@mail.gmail.com>
 <20201225120709.GA62135@202x.moe>
 <19EF535B-25B0-419E-95F9-7484822B02DA@gmail.com>
Message-ID: <20201226203900.GA4060@void>

On Fri, Dec 25, 2020 at 10:54:17PM +0100, Petite Abeille wrote:
> If tomorrow, Gemini adopts IRIs, nothing changes for you. Your setup is fully upward compatible. You do not have to lift a finger to keep going. 
> 
> All stays exactly the same for you.
> 
> Of course, no one on your setup can use IRIs. Only URIs. But they don't want IRIs anyway. No loss.
> 
> Arguably, your setup may not be fully compliant with the letter of the spec. No big deal. 99% there. No one is going to sue you. Just a hobby. 

Been there, done that. Best viewed with browser %s.

Several such "improvements", and client that was first-class citizen
becomes something like w3m or lynx in modern web, and another dream is
ruined in pursue for aesthetics.

From colecmac at protonmail.com  Sat Dec 26 20:25:27 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sat, 26 Dec 2020 20:25:27 +0000
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
Message-ID: <CZh4g23bYSQGYlgmD1YvDSXsY2GpbQydqkxGi1Wqbu40--dlHzDP5_8xreZQoe1vNVNSTAbrG7p0WxhOMqNfnddcfMl6hi4OZ3KSBhVFHOc=@protonmail.com>

> Feedback welcome, especially if I've overlooked anything, which is
> certainly possible.  What I'd be most interested in hearing, at this
> point, is client authors letting me know whether the standard library
> in the language their client is implemented in can straightforwardly:
>
> 1. Parse and relativise URLs with non-ASCII characters (so, yes, okay,
>    technically not URLs at all, you know what I mean) in paths and/or
>    domains?
> 2. Transform back and forth between URIs and IRIs?
> 3. Do DNS lookups of IDNs without them being punycoded first?  You can
>    test this with r?ksm?rg?s.josefsson.org.

The main language I use for Gemini software is Go. My clients, Amfora and
gemget, are both programmed using Go, and they use Go's built-in URL
library, called "net/url".

This library cannot properly handle 1, 2, or 3. This likely because the Go
stdlib is high quality, and appears to be coded to follow RFCs very strictly,
and the library was only designed to support URLs, and not IRIs.

For example, it will accept invalid characters in the path when parsing the
URL, but when converting it back into a string, it will percent-encode the
invalid characters. This does not happen with the query string, though.

The fact that paths and query strings are treated differently makes converting
IRIs to URIs not straightforward. And doing the reverse would require taking
the bits of the parsed URL and then decoding them compliantly, and then
stitching them together manually.

As for #3, the Go stdlib looks up the domain in the URL as-is, and will not
punycode anything. I have had to do it myself, which was annoying but not
super difficult. Amfora and gemget both have support for IDNs.

See the link below for how IDN support was added, if it's of interest.

https://github.com/makeworld-the-better-one/go-gemini/compare/a557676343c51dabbc7d5a112d38bb8095db94d7...2f79af7688e88942d0d51d6ed65617b68a91a733


I believe these difficulties have implications on whether or not IRIs should
be added to the spec, but I'd rather let this email and the facts of the matter
stand on their own.


makeworld

From petite.abeille at gmail.com  Sat Dec 26 20:49:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 21:49:09 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201226203900.GA4060@void>
References: <CAFM0rObLSuwR8v2amJRf=xsLk=d_wY1n4bGMnLnq8w76S8vfuw@mail.gmail.com>
 <20201225120709.GA62135@202x.moe>
 <19EF535B-25B0-419E-95F9-7484822B02DA@gmail.com> <20201226203900.GA4060@void>
Message-ID: <341CC552-E67A-49DA-A745-294501D278C1@gmail.com>



> On Dec 26, 2020, at 21:38, Dmitry Bogatov <gemini#lists.orbitalfox.eu#v1 at kaction.cc> wrote:
> 
> Been there, done that. Best viewed with browser %s.

Fair point, But this concerns a server. Not a client. The server in question will never handle Unicode identifiers. Nor does it need to. Zero practical impact.

Plus, really, we are already in the "best viewed with xyz" age. Compare and contrast, say, LaGrange? and Amphora?. They are both great. In their own different ways.

Are you suggesting a normative user experience?

? https://github.com/skyjake/lagrange
? https://github.com/makeworld-the-better-one/amfora

From cowan at ccil.org  Sat Dec 26 21:10:48 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 26 Dec 2020 16:10:48 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201225165756.GC13729@sources.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net>
 <20201225165756.GC13729@sources.org>
Message-ID: <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>

On Fri, Dec 25, 2020 at 11:58 AM Stephane Bortzmeyer <stephane at sources.org>
wrote:


> I don't think that percent-encoding has to be done per path segment. I
> don't find anything in RFC 3986 that makes your algorithm
> mandatory. "/" is a safe character, anyway so it seems to me that you
> can percent-encode the entire path in one operation.
>

Once any necessary punycoding has been done (look for // on the left and
either / or end-of-string on the right), the whole URI can have its
non-ASCII characters %-encoded all at once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201226/31aff2f2/attachment.htm>

From petite.abeille at gmail.com  Sat Dec 26 21:33:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 22:33:28 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
Message-ID: <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>



> On Dec 26, 2020, at 22:10, John Cowan <cowan at ccil.org> wrote:
> 
> the whole URI can have its non-ASCII characters %-encoded all at once

Right. But that was not Stephane problematic, which was related to how to encode Reserved Characters gen-delims "/" in a path.

Consider the following 3 path segments: "Research", "A/B Testing", "Results".

Stephane asserts the following encodings are equivalent:

Research%2FA%2FB%20Testing%2FResults

vs.
Research/A%2FB%20Testing/Results

They are clearly not. The first variant will result in one path segment, with data loss. While the second one will preserve the original semantic, with 3 segments, individually encoded, and intact.

They are not equivalent path. Try it in your favorite library.








From petite.abeille at gmail.com  Sat Dec 26 22:05:26 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 23:05:26 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <CZh4g23bYSQGYlgmD1YvDSXsY2GpbQydqkxGi1Wqbu40--dlHzDP5_8xreZQoe1vNVNSTAbrG7p0WxhOMqNfnddcfMl6hi4OZ3KSBhVFHOc=@protonmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <CZh4g23bYSQGYlgmD1YvDSXsY2GpbQydqkxGi1Wqbu40--dlHzDP5_8xreZQoe1vNVNSTAbrG7p0WxhOMqNfnddcfMl6hi4OZ3KSBhVFHOc=@protonmail.com>
Message-ID: <6F901483-2736-4471-8154-449EE4F2E717@gmail.com>



> On Dec 26, 2020, at 21:25, colecmac at protonmail.com wrote:
> 
> This likely because the Go stdlib is high quality, and appears to be coded to follow RFCs very strictly, and the library was only designed to support URLs, and not IRIs.

Would a strict ANTLR grammar for IRI help?

https://pkg.go.dev/bramp.net/antlr4/iri
https://github.com/antlr/grammars-v4/blob/master/iri/IRI.g4


From petite.abeille at gmail.com  Sat Dec 26 22:26:36 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sat, 26 Dec 2020 23:26:36 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <CZh4g23bYSQGYlgmD1YvDSXsY2GpbQydqkxGi1Wqbu40--dlHzDP5_8xreZQoe1vNVNSTAbrG7p0WxhOMqNfnddcfMl6hi4OZ3KSBhVFHOc=@protonmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <CZh4g23bYSQGYlgmD1YvDSXsY2GpbQydqkxGi1Wqbu40--dlHzDP5_8xreZQoe1vNVNSTAbrG7p0WxhOMqNfnddcfMl6hi4OZ3KSBhVFHOc=@protonmail.com>
Message-ID: <795A0303-E717-43BC-89D1-A13749C5814E@gmail.com>



> On Dec 26, 2020, at 21:25, colecmac at protonmail.com wrote:
> 
> appears to be coded to follow RFCs very strictly

Looking at url/url.go, the implementation seems more pragmatic than dogmatic:

https://github.com/golang/go/blob/master/src/net/url/url.go

A fascinating read. But a strict RFC grammar it's not. 

It has gone through a long and tumultuous history:

https://github.com/golang/go/commits/49a210eb87da6b7ac960cac990337ef4dc113b0d/src/net/url/url.go

Either way, would preprocessing an IRI into an URL help? Similarly to the Java situation.






From sean at conman.org  Sat Dec 26 23:22:36 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 26 Dec 2020 18:22:36 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
Message-ID: <20201226232236.GA3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Dec 26, 2020, at 22:10, John Cowan <cowan at ccil.org> wrote:
> > 
> > the whole URI can have its non-ASCII characters %-encoded all at once
> 
> Right. But that was not Stephane problematic, which was related to how to
> encode Reserved Characters gen-delims "/" in a path.
> 
> Consider the following 3 path segments: "Research", "A/B Testing",
> "Results".
> 
> Stephane asserts the following encodings are equivalent:
> 
> Research%2FA%2FB%20Testing%2FResults
> 
> vs.
> Research/A%2FB%20Testing/Results
> 
> They are clearly not. The first variant will result in one path segment,
> with data loss. While the second one will preserve the original semantic,
> with 3 segments, individually encoded, and intact.
> 
> They are not equivalent path. Try it in your favorite library.

  It was interesting to see the Go URL library you linked to.  For your two
examles, it will return the following structures:

	{
	  Path    = "Research/A/B Testing/Results",
	  RawPath = "Research%2FA%2FB%20Testing%2FResults",
	}

	{
	  Path    = "Research/A/B Testing/Results",
	  RawPath = "Research/A%2FB%20Testing/Results",
	}

and it's up to the client to check RawPath if it's *really* necessary to
make the distinction (meaning---the client *still* has to parse the path).

  A more normal example like "Research/ABTesting/Results" will result in:

	{
	  Path    = "Research/ABTesting/Results",
	  RawPath = "",
	}

so it's not like RawPath will always have the path.

  For the record, my own URL parsing library will just return 

	Research/A/BTesting/Results

for both samples.  I found it easier to work with that than what I was doing
at the time (pedantically correct, painfully hard to use in practice). You
would be hard pressed to actually create a file named "A/B Testing" on any
file system I know of (and not have it be "B Testing" in the "A" directory). 
If there *is* a file system that allows slashes in a filename (and not just
a seperator between directories) than I might revisit my decision, but until
then ...

  -spc

From petite.abeille at gmail.com  Sat Dec 26 23:25:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 00:25:04 +0100
Subject: [tech] to postel or not to postel, that is the question
Message-ID: <1906931F-AD9A-4555-83D2-A76E4BEA0A1A@gmail.com>

Looking at the various implementations of the URL/URI/IRI stack in mainstream libraries, one has to face Jon Postel's robustness ghost ?.


Exhibit ? 1: Google's own net/url/url.go ?

// See RFC 3986. This package generally follows RFC 3986, except where
// it deviates for compatibility reasons.

Indeed. A very pragmatic approach to reality, taking the robustness principle to heart: pretty much anything goes. Such is life. 


Exhibit ? 2: Sean Conner's own Parsing Expression Grammar ? ? ?

A work of unearthly beauty which actually follows the RFC to the letter. 

The anti-thesis of Postel's law, as strict as the MUST imperative.


Both pros and cons of Postel's injunction can be argued ad nauseam.


What does Gemini want, as a protocol? Leniency as provided by Exhibit ? 1? Or strictness as demonstrated by Exhibit ? 2?


It is my personal opinion that Postel's Law is the root of all evils as we know them to this day: any old garbage can travel over the pipe, and you must do your best to handle it. Good luck to you.

This is nonsensical. We know better by now.

Protocol MUST be strict. This is why we have them in the first place. To clearly define what's legal or not, protocol wise.

What does Gemini want?
 


? https://en.wikipedia.org/wiki/Robustness_principle

? https://github.com/golang/go/blob/master/src/net/url/url.go
Even though one would have hoped Google would have learned from Sun's mistakes. Apparently not. Perhaps the same team was involve in both Java and Go implementations. Go figure.

? https://github.com/spc476/LPeg-Parsers/blob/master/iri.lua

? http://www.inf.puc-rio.br/~roberto/lpeg/

? https://bford.info/packrat/




From sean at conman.org  Sat Dec 26 23:25:43 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 26 Dec 2020 18:25:43 -0500
Subject: [spec] adding a "magic number" for gemini files
In-Reply-To: <X+dcrk/JFdyccE/J@kurosawa.casa.net>
References: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
 <C82TSBUY1QBI.UNG3VL20MGXD@stilgar> <X+dcrk/JFdyccE/J@kurosawa.casa.net>
Message-ID: <20201226232543.GB3625@brevard.conman.org>

It was thus said that the Great cage once stated:
> On Sat, Dec 26, 2020 at 04:34:25PM +0100, Solderpunk wrote:
> > On Sat Dec 26, 2020 at 4:32 PM CET, cage wrote:
> >
> > > I think a lot of guesswork is needed (line finding link lines with
> > > gemini scheme?), for example, to discriminate between markdown and
> > > gemini file format.
> >
> > When is this really necessary?  Both Gemini and HTTP provide a means to
> > inform the client what's coming down the pipe.  For files distributed
> > otherwise, filename conventions would seem to do the trick.
> 
> I was  thinking abot file(1) and  libmagic in general.

  I use libmagic for my server [1] and yet, I still use an extension to mark
a Gemini text file.

  -spc

[1]	https://github.com/spc476/GLV-1.12556

From petite.abeille at gmail.com  Sat Dec 26 23:27:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 00:27:37 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201226232236.GA3625@brevard.conman.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
Message-ID: <115B16ED-A605-4E11-98D0-B68CCF3C38B9@gmail.com>



> On Dec 27, 2020, at 00:22, Sean Conner <sean at conman.org> wrote:
> 
> You would be hard pressed to actually create a file named "A/B Testing" on any file system I know of

There is more to life than a file system, a database for example. 

Let's not conflate the limitations of the two.


From petite.abeille at gmail.com  Sat Dec 26 23:28:42 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 00:28:42 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201226232236.GA3625@brevard.conman.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
Message-ID: <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>



> On Dec 27, 2020, at 00:22, Sean Conner <sean at conman.org> wrote:
> 
>  For the record, my own URL parsing library will just return 
> 
> 	Research/A/BTesting/Results

Tragic. I take back my assessment of your LPEG grammar. It's clearly wrong. Oh well.


From sean at conman.org  Sat Dec 26 23:34:50 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 26 Dec 2020 18:34:50 -0500
Subject: [tech] to postel or not to postel, that is the question
In-Reply-To: <1906931F-AD9A-4555-83D2-A76E4BEA0A1A@gmail.com>
References: <1906931F-AD9A-4555-83D2-A76E4BEA0A1A@gmail.com>
Message-ID: <20201226233450.GC3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> Looking at the various implementations of the URL/URI/IRI stack in mainstream libraries, one has to face Jon Postel's robustness ghost ?.
> 
> Exhibit ? 1: Google's own net/url/url.go ?
> 
> // See RFC 3986. This package generally follows RFC 3986, except where
> // it deviates for compatibility reasons.
> 
> Indeed. A very pragmatic approach to reality, taking the robustness
> principle to heart: pretty much anything goes. Such is life.
> 
> 
> Exhibit ? 2: Sean Conner's own Parsing Expression Grammar ? ? ?
> 
> A work of unearthly beauty which actually follows the RFC to the letter. 

  Not quite.  I explicitly ignore this bit of RFC-3987:

	... with the restriction that private UCS characters can
	occur only in query parts.

as that was a bridge too far even for me.  I will also decode a path like
"/foo%2Fbar/" as "/foo/bar/", ignoring the sematics of the encoded slash.

> The anti-thesis of Postel's law, as strict as the MUST imperative.
> 
> Both pros and cons of Postel's injunction can be argued ad nauseam.
> 
> What does Gemini want, as a protocol? Leniency as provided by Exhibit ? 1?
> Or strictness as demonstrated by Exhibit ? 2?
> 
> It is my personal opinion that Postel's Law is the root of all evils as we
> know them to this day: any old garbage can travel over the pipe, and you
> must do your best to handle it. Good luck to you.
> 
> This is nonsensical. We know better by now.
> 
> Protocol MUST be strict. This is why we have them in the first place. To
> clearly define what's legal or not, protocol wise.
> 
> What does Gemini want?

  While I do agree with the sentiment [1], allow me to play the Devil's
Advocate here and mention one word:  XHTML---HTML but with the strict
parsing rules of XML.  To say it was unpopular is an understatment.  Not to
mention that XML itself is unpopular (but perhaps for reasons other than its
strict parsing rules).  Become too strict, and people complain.

  -spc (But become too lax, and other people complain ... )

> ? https://en.wikipedia.org/wiki/Robustness_principle
> 
> ? https://github.com/golang/go/blob/master/src/net/url/url.go
> Even though one would have hoped Google would have learned from Sun's mistakes. Apparently not. Perhaps the same team was involve in both Java and Go implementations. Go figure.
> 
> ? https://github.com/spc476/LPeg-Parsers/blob/master/iri.lua
> 
> ? http://www.inf.puc-rio.br/~roberto/lpeg/
> 
> ? https://bford.info/packrat/

From petite.abeille at gmail.com  Sat Dec 26 23:39:14 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 00:39:14 +0100
Subject: [tech] to postel or not to postel, that is the question
In-Reply-To: <20201226233450.GC3625@brevard.conman.org>
References: <1906931F-AD9A-4555-83D2-A76E4BEA0A1A@gmail.com>
 <20201226233450.GC3625@brevard.conman.org>
Message-ID: <3B70DC3D-B373-4B54-81FE-D10D555F6710@gmail.com>



> On Dec 27, 2020, at 00:34, Sean Conner <sean at conman.org> wrote:
> 
>  Not quite.  I explicitly ignore this bit of RFC-3987:
> 
> 	... with the restriction that private UCS characters can
> 	occur only in query parts.
> 
> as that was a bridge too far even for me.  I will also decode a path like
> "/foo%2Fbar/" as "/foo/bar/", ignoring the sematics of the encoded slash.

"Well, nobody's perfect."
-- Osgood Fielding III, Some Like It Hot, 1959



From sean at conman.org  Sat Dec 26 23:52:14 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 26 Dec 2020 18:52:14 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
 <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>
Message-ID: <20201226235214.GD3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Dec 27, 2020, at 00:22, Sean Conner <sean at conman.org> wrote:
> > 
> >  For the record, my own URL parsing library will just return 
> > 
> > 	Research/A/BTesting/Results
> 
> Tragic. I take back my assessment of your LPEG grammar. It's clearly
> wrong. Oh well.

  Okay, given your two examples:

	Research%2FA%2FB%20Testing%2FResults
	Research/A%2FB%20Testing/Results

what should a "proper" URL parser return?  And how should client code handle
such a construct?  Perhaps even attempt to write a URL (or IRI) parser
yourself?

  At one point, my URL parser would return the following for these:

	{
	  path =
	  {
	    "Research/A/B Testing/Results",
	  }
	}

	{
	  path = 
	  {
	    "Research",
	    "A/B Testing",
	    "Results",
	  }
	}

but I found working with such paths to be painful.  First off, how to
distinguish between

	Research/A%2FB%20Testing/Results

and

	/Research/A%2FB%20Testing/Results

  How would I specify that any URL with a path starting with "/foo" be
redirected to a path starting with "/bar"?

		/foo/this	-> /bar/this
		/foobar		-> /barbar

  And how would I deal with this in the code?

  Yes, you can say I ruined the purity of my URL parser with an ugly
pragmatic approach (keep the path a string, but decoded and ignore the
semantics of encoded delims), but there's also the saying, "Perfect is the
enemy of good."

  -spc

[1]	https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

From petite.abeille at gmail.com  Sun Dec 27 00:08:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 01:08:48 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201226235214.GD3625@brevard.conman.org>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
 <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>
 <20201226235214.GD3625@brevard.conman.org>
Message-ID: <2B11AD80-A097-49CA-97CF-48D642625AB8@gmail.com>



> On Dec 27, 2020, at 00:52, Sean Conner <sean at conman.org> wrote:
> 
> "Perfect is the enemy of good."

Agree. My own parserss are on the pragmatic side of the spectrum (even though path segments are preserved, as I tend to use databases rather than file systems). I was hoping you where a better person that I'm, to borrow your own line.

I suspect I should stop hoping for a full-fledge LPEG grammar for MIME emerging from Conman's lab :/

Oh well. We are all flawed. Skynet will just crash and segfault. 

No one cares. Even on a mailing list dedicated to designing a protocol, one ends up being "pedantic". 

I now fell the same rage-quit as bie.

On the plus side, next time someone dare to mention any RFCs, just punch them in the face. Life is too short.

Let's stop pretending.




From sean at conman.org  Sun Dec 27 00:12:09 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 26 Dec 2020 19:12:09 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201224114850.GA14763@localhost.localdomain>
References: <C7ZETTYI5ROU.27XPE787PQVJB@stilgar>
 <790E5997-43BE-4FC5-88B7-28DC1187F8D1@gmail.com>
 <20201222221828.GX9267@brevard.conman.org>
 <3C308A8F-2461-4E50-891E-3D4E2501FD35@gmail.com>
 <20201223004102.GA11078@202x.moe>
 <20201223100058.GA6184@localhost.localdomain>
 <20201223230319.GC9267@brevard.conman.org>
 <20201224114850.GA14763@localhost.localdomain>
Message-ID: <20201227001209.GE3625@brevard.conman.org>

It was thus said that the Great marc once stated:
> >   I have to deal with the telephony network at work.  It *is* the OSI seven
> > layer burrito [1] and even *there* there are baked in assumptions relating
> > to i18n [2].  Text is limited to ASCII.  Yup.  7-bit US-ASCII it all its
> > glory.  Anything else requires some very nasty hacks.  
> 
> Note how the global telephone system has made it into the furthest
> corners of the planet - arguably further than the internet, and did
> so without worrying about internationalisation relating to their
> URL equivalents (phone numbers)...

  Phone numbers are their own special Hell [1].

  The point I was making is that yes, the SS7 protocol, used by telephone
companies around the world, isn't i18n clean.  And it's not like SS7 was
developed in the 1920s ... that's all I'm saying here.  I work for a company
that translates phone numbers (like 800-555-1212) to human readable names
(like "The ACME Company") for delivery to the cell phone receiving a phone
call (so intead of getting "800-555-1212" you get "The ACME Company").  It
was a tremendous amount of engineer to work around the SS7 limitations of 15
US-ASCII characters (and it's a hack really).

  But hey, it's US-ASCII only, so it's "simple" ...

  -spc

[1]	I have to deal with phone numbers as given to us by the Oligarchic
	Cell Phone Companies.  You would think that we would be given valid
	phone numbers as defined by them, but you would be wrong.  We get
	complete trash along with good.  And then my manager's manager wants
	us to pass along all invalid NANP [2] numbers along with the valid
	NANP numbers [3], while excluding all valid international numbers
	...

[2]	North America Numbering Plan, which includes the US, Canada and the
	Carribean, but excludes Mexico and countries south of it.

[2]	Our product is only designed for the US.  This makes it interesting
	because Canada and the Carribean aren't the US, but are part of the
	NANP, which means some "area codes" are actually "country codes" in
	disguise, but I digress ...

From sean at conman.org  Sun Dec 27 00:26:26 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 26 Dec 2020 19:26:26 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <2B11AD80-A097-49CA-97CF-48D642625AB8@gmail.com>
References: <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
 <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>
 <20201226235214.GD3625@brevard.conman.org>
 <2B11AD80-A097-49CA-97CF-48D642625AB8@gmail.com>
Message-ID: <20201227002626.GF3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Dec 27, 2020, at 00:52, Sean Conner <sean at conman.org> wrote:
> > 
> > "Perfect is the enemy of good."
> 
> Agree. My own parserss are on the pragmatic side of the spectrum (even
> though path segments are preserved, as I tend to use databases rather than
> file systems). 

  How do you preseve them?  As the encoded "%2F"?  Do you convert the
encoded values to uppercase?  Lowercase?  Keep them the same?

> I was hoping you where a better person that I'm, to borrow
> your own line.

  But you said it yourself, you fall on the pragmatic side.  

> I suspect I should stop hoping for a full-fledge LPEG grammar for MIME
> emerging from Conman's lab :/

  Well, I do have one [1], although I'm not sure how "full-fledged" it is. 
I also lowercase the actual MIME type (so "TEXT/PLAIN" will become
"text/plain") to make it easier to use the results.

  I even have one for email [2], which can even parse RFC-822 style email
addresses [3], but I'm rethinking how I parse Internet messages as I'm not
entirely happy with my current approach.

> Oh well. We are all flawed. Skynet will just crash and segfault.
> 
> No one cares. Even on a mailing list dedicated to designing a protocol,
> one ends up being "pedantic".
> 
> I now fell the same rage-quit as bie.
> 
> On the plus side, next time someone dare to mention any RFCs, just punch
> them in the face. Life is too short.

  Life is too short to follow the WhatWG "standard" [4], so I guess it's a
"pick your poison" type situtation.

> Let's stop pretending.

  Yeah, let's roll our own crypto and addressing scheme!  What can possibly
go wrong?

  -spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/mimetype.lua

[2]	https://github.com/spc476/LPeg-Parsers/blob/master/email.lua

[3]	Muhammed.(I am  the greatest) Ali @(the)Vegas.WBA

[4]	https://url.spec.whatwg.org/#concept-url-parser

From petite.abeille at gmail.com  Sun Dec 27 00:46:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 01:46:43 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201227002626.GF3625@brevard.conman.org>
References: <X+IqY87CzSX5dMdv@kurosawa.casa.net>
 <E01BB714-0CB5-47AF-92FD-FCD46BD7B31C@gmail.com>
 <X+On8FFDHY1qkRBX@kurosawa.casa.net> <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
 <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>
 <20201226235214.GD3625@brevard.conman.org>
 <2B11AD80-A097-49CA-97CF-48D642625AB8@gmail.com>
 <20201227002626.GF3625@brevard.conman.org>
Message-ID: <713D83B6-ED80-43B7-8E7B-9251896CC9CD@gmail.com>



> On Dec 27, 2020, at 01:26, Sean Conner <sean at conman.org> wrote:
> 
> How do you preseve them?  As the encoded "%2F"?  Do you convert the
> encoded values to uppercase?  Lowercase?  Keep them the same?

The hex code themselves? I tend to normalize them to uppercase. Tradition or something. But perhaps we are talking about different things? Or?

>  But you said it yourself, you fall on the pragmatic side.  

Yes. Different pragmatism I guess. Strictly speaking it also depend of the context. In general, failfast systems have better survivability odds. But at time, one would rather extract as much as one can from imperfect data. It depends of the problematic at hand.

> Well, I do have one [1], although I'm not sure how "full-fledged" it is. 

Yes, but this only concerns itself with the content-type header. I mean MIME multipart constructs.

>  Life is too short to follow the WhatWG "standard" [4], so I guess it's a
> "pick your poison" type situtation.

Fair enough.

> Yeah, let's roll our own crypto and addressing scheme!  What can possibly
> go wrong?

Now, that would be crazy :)





From sean at conman.org  Sun Dec 27 01:19:45 2020
From: sean at conman.org (Sean Conner)
Date: Sat, 26 Dec 2020 20:19:45 -0500
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <713D83B6-ED80-43B7-8E7B-9251896CC9CD@gmail.com>
References: <X+On8FFDHY1qkRBX@kurosawa.casa.net>
 <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
 <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>
 <20201226235214.GD3625@brevard.conman.org>
 <2B11AD80-A097-49CA-97CF-48D642625AB8@gmail.com>
 <20201227002626.GF3625@brevard.conman.org>
 <713D83B6-ED80-43B7-8E7B-9251896CC9CD@gmail.com>
Message-ID: <20201227011945.GG3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Dec 27, 2020, at 01:26, Sean Conner <sean at conman.org> wrote:
> > 
> > How do you preseve them?  As the encoded "%2F"?  Do you convert the
> > encoded values to uppercase?  Lowercase?  Keep them the same?
> 
> The hex code themselves? I tend to normalize them to uppercase. Tradition
> or something. But perhaps we are talking about different things? Or?

  I meant:  If I gave your URL parsers the string

	Research/A%2fB%20Testing/Results

what would I, as a user, get back?  Would I get a string back?  An array of
segments?  An actual example would be be nice.

> > Well, I do have one [1], although I'm not sure how "full-fledged" it is. 
> 
> Yes, but this only concerns itself with the content-type header. I mean
> MIME multipart constructs.

  Ah.  See, I haven't needed that much functionality yet (and I suspect I
could use my email parsers for that if I really needed it).

  -spc

[1]	Missing footnote.

From petite.abeille at gmail.com  Sun Dec 27 01:40:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 02:40:37 +0100
Subject: [spec] IRIs, IDNs, and all that international jazz
In-Reply-To: <20201227011945.GG3625@brevard.conman.org>
References: <X+On8FFDHY1qkRBX@kurosawa.casa.net>
 <20201225165756.GC13729@sources.org>
 <CAD2gp_SOwrLjMqRFczDDJwGp2OZNBjEHEKKjyar4eJB8+prFqA@mail.gmail.com>
 <78508DA2-954D-45A3-B5B7-0ADD07394039@gmail.com>
 <20201226232236.GA3625@brevard.conman.org>
 <2B69B7B3-64D8-48DC-8678-0003C20AEEDA@gmail.com>
 <20201226235214.GD3625@brevard.conman.org>
 <2B11AD80-A097-49CA-97CF-48D642625AB8@gmail.com>
 <20201227002626.GF3625@brevard.conman.org>
 <713D83B6-ED80-43B7-8E7B-9251896CC9CD@gmail.com>
 <20201227011945.GG3625@brevard.conman.org>
Message-ID: <24B27595-8591-49DD-ACA1-A89859D6258E@gmail.com>



> On Dec 27, 2020, at 02:19, Sean Conner <sean at conman.org> wrote:
> 
>  I meant:  If I gave your URL parsers the string
> 
> 	Research/A%2fB%20Testing/Results
> 
> what would I, as a user, get back?  Would I get a string back?  An array of
> segments?  An actual example would be be nice.

Ultimately, a list of path segments, yes. Similar to your first (correct) example. With both an absolute and directory indicator.

In the case above, 3 segments. Not absolute, not a directory. These segments are then decoded to whatever string they represents, i.e. segment[ 2 ] would contain the string "A/B Testing". As originally provided. The URL can always round trip. If not, something is very wrong.

The same problematic applies, to, say, representing an URL in an URL.

So, given the following path segments, "cache", "gemini://host/path", and "content", the resulting path should be:

cache/gemini%3A%2F%2Fhost%2Fpath/content

And not:

cache%2Fgemini%3A%2F%2Fhost%2Fpath%2Fcontent

Which is clearly nonsensical.

> Ah.  See, I haven't needed that much functionality yet (and I suspect I
> could use my email parsers for that if I really needed it).

Yes, email.lua would handle a message/rfc822 part. It's a start :)

https://github.com/spc476/LPeg-Parsers/blob/master/email.lua



From cowan at ccil.org  Sun Dec 27 04:46:16 2020
From: cowan at ccil.org (John Cowan)
Date: Sat, 26 Dec 2020 23:46:16 -0500
Subject: [tech] to postel or not to postel, that is the question
In-Reply-To: <1906931F-AD9A-4555-83D2-A76E4BEA0A1A@gmail.com>
References: <1906931F-AD9A-4555-83D2-A76E4BEA0A1A@gmail.com>
Message-ID: <CAD2gp_R=T35C2918nEeqw8zUB+VE14xHBnP7cVeZoyvGTiw7Hg@mail.gmail.com>

On Sat, Dec 26, 2020 at 6:25 PM Petite Abeille <petite.abeille at gmail.com>
wrote:

Looking at the various implementations of the URL/URI/IRI stack in
> mainstream libraries, one has to face Jon Postel's robustness ghost ?.
>

In fairness to Jon, the context makes it clear that he did not mean what he
is commonly taken to mean.  Being liberal in what you expect does not mean
"be willing to accept anything and make sense of it".

for example: i am perfectly willing to read poetry or even prose written in
lower case only, even though it is harder for me and most people to read.
but i would never (except in this one email) write anything that was not
conventionally capitalized.  postel's law applies: i am liberal in what i
accept (conventional capitals or no capitals) but conservative in what i
send (conventional caps only).

What Postel's law does _not_ mean is that
IAMWILLINGTOACCEPTSCRIPTIOCONTINUAINENGLISH
EVENTHOUGHROMANINSCRIPTIONSWEREMOSTLY
like this.  (Imagine pages and pages of this style.  No.)  That's because
Postel's law is broken: I will not accept something well outside the
protocol of English writing, and I will not normally send something
s??? s? ??n?????p s? to read either.


>
> Exhibit ? 1: Google's own net/url/url.go ?
>
> // See RFC 3986. This package generally follows RFC 3986, except where
> // it deviates for compatibility reasons.
>
> Indeed. A very pragmatic approach to reality, taking the robustness
> principle to heart: pretty much anything goes. Such is life.
>

They have two conflicting rules to deal with: Postel's law and "Don't break
the customer's code".  There's simply no good answer to that.


> Exhibit ? 2: Sean Conner's own Parsing Expression Grammar ? ? ?
> The anti-thesis of Postel's law, as strict as the MUST imperative.


The apotheosis of Postel's law: accept everything, and only, what the
protocol says.

So here's an example closer to Gemini: should %-encoding use all lower
case?  Most code does, so it's the conservative thing to send.  But the
protocol is clear: a conformant implementation has to accept both.  But
because people often copy broken implementations from other programmers'
broken implementations, sometimes they don't even know that upper case is
acceptable.  Again, being conservative in what you send makes sure you can
interoperate with such broken implementations.

What does Gemini want, as a protocol? Leniency as provided by Exhibit ? 1?
> Or strictness as demonstrated by Exhibit ? 2?
>

Strictness, of course, give the above.


> It is my personal opinion that Postel's Law is the root of all evils as we
> know them to this day:

It isn't _money_ that's the root of all evil.  It's the greed for money.



> Protocol MUST be strict. This is why we have them in the first place. To
> clearly define what's legal or not, protocol wise.
>

Amen.  (But note that there are multiple versions of most protocols.)



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
weirdo:    When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201226/0914b422/attachment.htm>

From jclemme at uri.edu  Sun Dec 27 06:19:23 2020
From: jclemme at uri.edu (John Lemme)
Date: Sun, 27 Dec 2020 01:19:23 -0500
Subject: [ANN] announcing the outpost, a kinda sorta reddit-esque forum
Message-ID: <259A17B4-5F54-4FA7-A18C-DA38DC0D1888@getmailspring.com>

gemini is sorely lacking forums. i glommed this together over the past couple days - it's a messageboard / link aggregator with support for threaded comments. (i think sose beat me with motm, but always good to have two options y'know)

gemini://bearforceone.net/outpost (https://link.getmailspring.com/link/259A17B4-5F54-4FA7-A18C-DA38DC0D1888 at getmailspring.com/0?redirect=gemini%3A%2F%2Fbearforceone.net%2Foutpost&recipient=Z2VtaW5pQGxpc3RzLm9yYml0YWxmb3guZXU%3D)
it's a little bit simple. i'm planning on adding support for some kind of voting mechanism this week, as well as the ability to edit/append to/delete comments. it's more of a hack than a fully functional site right now but i'd love your feedback.
authentication is entirely through client certificates, where the common name of the cert is your "username". this is obviously not a good long-term solution - there's no good way to enforce username collisions, for instance - but it works in the meantime. if you're using Kristall it'll ask you for a CN when you make an identity. i might make a registration system with email verification, but i don't know if that's the best way to go about it.
anyway let me know what you think. ideally, on the site itself lol.
-john
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/faa4e15b/attachment.htm>

From solderpunk at posteo.net  Sun Dec 27 10:47:01 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 11:47:01 +0100
Subject: [spec] Oustanding issues
Message-ID: <C83IATQ52E1C.1EBSKT04414WU@stilgar>

Greetings all,

I'm trying to prepare a list of spec issues that I want to finalise as
soon as possible.  I probably should have been more disciplined about
this, but the high traffic rate of the mailing list combined with the
fact that an awful lot of the discussion is about stuff that I'm not
interested in means I've kind of lost track of the important things.
Below is everything I'm aware of which has been previously raised which
I think is worthy of some kind of consideration/response.  If you think
I've forgotten something, please let me know.

In arbitrary order:

* Obviously, the ongoing IRI vs URI issue.
* Clarification on the use of TLS close_notify has been requested.
  This is actually mandated by both TLS 1.2 and 1.3 specs so technically
  it's redundant to mention it in the Gemini spec, but given how poorly
  implemented it is, some explicit reminding could not hurt.  I think
  there's a tiny wrinkle to consider here on *when* the client should
  send this (due to a change in semantics between TLS 1.2 and 1.3).
* The question of how to handle fragments in redirects.  I suppose a
  similar question applies for queries, actually.
* The spec is a bit vague on under which circumstances the META part of
  a response header may be empty, and on exactly what that means (e.g.
  is a tab after the status code still required in any case?).  This
  needs to be tightened up, and I'm pretty sure this should be done by
  just making non-empty META a requirement.
* There's been a request for recommendations on logging of queries.  I
  think this is out of scope for the itself, but an entirely
  appropriate thing to mention in either the Best Practices document or
  a separate companion standard for standard logging format.
* Sean has asked for the spec to require a redirect follow limit in
  clients, rather than this just being a recommendation in the BP
  document.
* There was discussion of using a new 2x status code to convey
  information about cacheability of content.  I'm pretty sure I don't
  want this, but I do feel a need to actually give a justification for
  it.
* There was discussion of using a new 2x status code to convey that a
  resource is a stream.  I'm not sure I want this (though less sure than
  the cache thing), but at the very least the spec could use a bit of
  clarity about the potential for content to be streamed.  I know
  streams are not universally popular, but there is little practical
  difference between a stream and a large but finite file served over a
  "jerky" internet connection, and it's very hard to actually explicitly
  disallow streams, so I think they are here to stay.  At the absolute
  minimum, the BP document should mention that buffering responses up in
  memory until they are complete and then processing them is a fragile
  (but valid and, in practice, workable) approach.
* There's this long-standing issue of the fact that none of the
  character sequences which identify the start of a non-text line type
  were originally defined with spaces after them, but we've added that
  requirement hodge-podge as ambiguities have appeared, and now we're in
  a situation where half the line types need them and half don't.
  Consistency suggests we require spaces everywhere, but this has been
  surprisingly controversial and may break some things.  But a final
  ruling is required.

Most of these are not anywhere near as major as the IRI issue.  I hope
to get all the non-IRI things sorted out in the next week or so.  In
some cases I may start new threads here asking for feedback.  In simpler
cases I might just make decrees.

Cheers,
Solderpunk


From cage-dev at twistfold.it  Sun Dec 27 11:56:47 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 27 Dec 2020 12:56:47 +0100
Subject: [spec] adding a "magic number" for gemini files
In-Reply-To: <20201226232543.GB3625@brevard.conman.org>
References: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
 <C82TSBUY1QBI.UNG3VL20MGXD@stilgar>
 <X+dcrk/JFdyccE/J@kurosawa.casa.net>
 <20201226232543.GB3625@brevard.conman.org>
Message-ID: <X+h2f3Ymzh79fsHO@kurosawa.casa.net>

On Sat, Dec 26, 2020 at 06:25:43PM -0500, Sean Conner wrote:

[...]

> > I was  thinking abo[u]t file(1) and  libmagic in general.
>
>   I use libmagic for my server [1] and yet, I still use an extension to mark
> a Gemini text file.

Do you mean you check the file extension for recognize a gemini file?
Or  you use  same kind  of heuristic  to prevent  libmagic to  returns
gemini file as text?

Bye!
C.

From cage-dev at twistfold.it  Sun Dec 27 11:51:19 2020
From: cage-dev at twistfold.it (cage)
Date: Sun, 27 Dec 2020 12:51:19 +0100
Subject: [Users] new release of mastodon allow gemini URL
Message-ID: <X+h1N+rAtLDUCmJ0@kurosawa.casa.net>

Hi!

Here is the announce:

https://github.com/tootsuite/mastodon/releases/tag/v3.3.0

and here the patch can be found:

https://github.com/tootsuite/mastodon/pull/15013

Bye!
C.

From martin at no.ucant.org  Sun Dec 27 12:01:02 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sun, 27 Dec 2020 12:01:02 +0000 (GMT)
Subject: [spec] Oustanding issues
In-Reply-To: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
References: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
Message-ID: <alpine.DEB.2.21.2012271149020.31140@pling.qwghlm.org>

On Sun, 27 Dec 2020, Solderpunk wrote:

> I think is worthy of some kind of consideration/response.  If you think
> I've forgotten something, please let me know.

You posted on your gemlog some time ago that the experience of the use of 
TLS client certificates had raised issues that needed to be clarified in 
the spec; I don't know whether these issues were satisfactorily resolved.

=> gemini://gemini.circumlunar.space/users/solderpunk/gemlog/tls-musings.gmi


For my own part I'd like to know about timeouts. My server is coded with 
some concern about DoS attacks such as the Slow Loris attack:

=> https://en.wikipedia.org/wiki/Slowloris_(computer_security)

To mitigate this, the server shuts down any connection which hasn't 
submitted a request after ten seconds. Pragmatically, client authors do 
not need licence from the spec to implement a timeout, but it may be 
useful to constrain when and how server implementors should/must/must not 
do this.

Mk

-- 
Martin Keegan, @mk270, https://mk.ucant.org/

From solderpunk at posteo.net  Sun Dec 27 12:25:41 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 13:25:41 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <alpine.DEB.2.21.2012271149020.31140@pling.qwghlm.org>
Message-ID: <C83KED7C841J.GYQBT62DU7JM@stilgar>

On Sun Dec 27, 2020 at 1:01 PM CET, Martin Keegan wrote:

> You posted on your gemlog some time ago that the experience of the use
> of
> TLS client certificates had raised issues that needed to be clarified in
> the spec; I don't know whether these issues were satisfactorily
> resolved.
>
> =>
> gemini://gemini.circumlunar.space/users/solderpunk/gemlog/tls-musings.gmi

Thanks for the reminder!  The SNI issue was addressed and this is now
mentioned in the spec.  The status codes related to client certificates
were also simplified and "transient certificates" are no longer a
first-class concept in the spec.  I *think* those were the major issues
that a little real-world experience revealed, and that they are both now
resolved.

> For my own part I'd like to know about timeouts. My server is coded with
> some concern about DoS attacks such as the Slow Loris attack:
>
> => https://en.wikipedia.org/wiki/Slowloris_(computer_security)
>
> To mitigate this, the server shuts down any connection which hasn't
> submitted a request after ten seconds. Pragmatically, client authors do
> not need licence from the spec to implement a timeout, but it may be
> useful to constrain when and how server implementors should/must/must
> not
> do this.

Hmm.  While I agree that neither servers nor clients really need
permission to implement basic functionality like timeouts, this
particular case *does* raise some questions.  Currently it seems
implicit in the spec that servers may not say anything until the client
has finished sending a request.  In principle, there are circumstances
where a server might know what it wants to do before that point - an
invalid URL (triggering a status code 59 response) might be detected
before it is complete, and the n-th request within m seconds (triggering
a status code 44 response) can be detected before *anything* is
received.  And, as you point out, reasonable defensive timeouts can
occur before a request is complete.  Is a server obligated to wait for a
complete response before saying anything?

Thanks for bringing this up, I'll think about it.  Thoughts are welcome.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sun Dec 27 14:17:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 15:17:43 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <C83KED7C841J.GYQBT62DU7JM@stilgar>
References: <C83KED7C841J.GYQBT62DU7JM@stilgar>
Message-ID: <62ED0CE4-E88B-447B-A299-5031D30F447E@gmail.com>



> On Dec 27, 2020, at 13:25, Solderpunk <solderpunk at posteo.net> wrote:
> 
> Is a server obligated to wait for a complete response before saying anything?

No. It's unreasonable to mandate any QoS (Quality of service) anywhere. Both clients and servers are free to take any defensive measures they see fit. Or none. It's their call.


From bjorn.warmedal at gmail.com  Sun Dec 27 14:35:25 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Sun, 27 Dec 2020 15:35:25 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <62ED0CE4-E88B-447B-A299-5031D30F447E@gmail.com>
References: <62ED0CE4-E88B-447B-A299-5031D30F447E@gmail.com>
Message-ID: <7F526835-F651-4E66-9712-3A5C76EB376A@gmail.com>


> 27 dec. 2020 kl. 15:18 skrev Petite Abeille <petite.abeille at gmail.com>:
> 
> ?
> 
>> On Dec 27, 2020, at 13:25, Solderpunk <solderpunk at posteo.net> wrote:
>> 
>> Is a server obligated to wait for a complete response before saying anything?
> 
> No. It's unreasonable to mandate any QoS (Quality of service) anywhere. Both clients and servers are free to take any defensive measures they see fit. Or none. It's their call.
> 
I completely agree with this. It?s in the server?s interest to strike a balance between defensive measures and good service as best they can given their situation.

Cheers,
ew0k

From dctrud at randomroad.net  Sun Dec 27 14:51:10 2020
From: dctrud at randomroad.net (David Trudgian)
Date: Sun, 27 Dec 2020 08:51:10 -0600
Subject: [users] Manually curated directory of capsules?
Message-ID: <ce99290c-e154-4355-a775-125e268870ae@www.fastmail.com>

Hello,

I was trying to think of something useful I could contribute to the gemini space, and keep coming back to standing up a manually curated list of capsules. Listed by some broad topics, one line summary etc. A bit like 'Trunk' for Mastodon (https://communitywiki.org/trunk). It might be a nice thing to have in addition to search with GUS and the CAPCOM / Spacewalk feed pages etc.

Does anyone know of anything out there already like this? If there is an active one I'd rather contribute in some way than duplicate effort.

If there isn't one, I'm hoping to stand up something by the new year. Just static pages in a Git repo, which I can expand by reviewing GUS new hosts periodically, doing simple dead link checks, and accepting submissions by email or Git patch etc.

Cheers,

dctrud

From bjorn.warmedal at gmail.com  Sun Dec 27 14:57:39 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Sun, 27 Dec 2020 15:57:39 +0100
Subject: [users] Manually curated directory of capsules?
In-Reply-To: <ce99290c-e154-4355-a775-125e268870ae@www.fastmail.com>
References: <ce99290c-e154-4355-a775-125e268870ae@www.fastmail.com>
Message-ID: <7E3854FB-68F5-49C4-B1B4-8F5C11C2A469@gmail.com>



> Just static pages in a Git repo, which I can expand by reviewing GUS new hosts periodically, doing simple dead link checks, and accepting submissions by email or Git patch etc.

I?d be interested in hosting a mirror of this! Possibly contributing too :)

Cheers,
ew0k

From nico at itwont.work  Sun Dec 27 14:58:48 2020
From: nico at itwont.work (Nico)
Date: Sun, 27 Dec 2020 14:58:48 GMT
Subject: [users] Manually curated directory of capsules?
In-Reply-To: <ce99290c-e154-4355-a775-125e268870ae@www.fastmail.com>
References: <ce99290c-e154-4355-a775-125e268870ae@www.fastmail.com>
Message-ID: <fefadbd7-89cc-0ba4-9517-cd7cfce01091@itwont.work>

On 27/12/2020 14:51, David Trudgian wrote:
> Hello,
> 
> I was trying to think of something useful I could contribute to the gemini space, and keep coming back to standing up a manually curated list of capsules. Listed by some broad topics, one line summary etc. A bit like 'Trunk' for Mastodon (https://communitywiki.org/trunk). It might be a nice thing to have in addition to search with GUS and the CAPCOM / Spacewalk feed pages etc.
> 
> Does anyone know of anything out there already like this? If there is an active one I'd rather contribute in some way than duplicate effort.
> 
> If there isn't one, I'm hoping to stand up something by the new year. Just static pages in a Git repo, which I can expand by reviewing GUS new hosts periodically, doing simple dead link checks, and accepting submissions by email or Git patch etc.
> 
> Cheers,
> 
> dctrud
> 
I'd contribute to this when I find stuff!

From solderpunk at posteo.net  Sun Dec 27 15:03:19 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 16:03:19 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <7F526835-F651-4E66-9712-3A5C76EB376A@gmail.com>
Message-ID: <C83NR29V1662.BXEQOR2MNW2E@stilgar>

On Sun Dec 27, 2020 at 3:35 PM CET, Bj?rn W?rmedal wrote:
>
> > 27 dec. 2020 kl. 15:18 skrev Petite Abeille <petite.abeille at gmail.com>:
> > 
> > No. It's unreasonable to mandate any QoS (Quality of service) anywhere. Both clients and servers are free to take any defensive measures they see fit. Or none. It's their call.
> > 
> I completely agree with this. It?s in the server?s interest to
> strike a balance between defensive measures and good service as best
> they can given their situation.

Thanks, both of you.  This is consistent with some changes I've already
started drafting.  I'll send another email around with some proposed
changes relatively soon.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sun Dec 27 15:32:03 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 16:32:03 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
Message-ID: <DA54016B-8D69-4CB8-B395-26744A84D0FD@gmail.com>

SEDR 300 VOLUME I
PROJECT GEMINI familiarization manual
LONG RANGE  and MODIFIED CONFIGURATIONS

https://www.ibiblio.org/apollo/Documents/GeminiManualVol1.pdf

I suggest the following deliverables for 2021:

1 ? RFC x1965 The Gemini Protocol: describes the over-the-wire protocol itself
1 ? RFC x1966 The Gemini Document:. describes the text/gemini document format

The above are normative, neutral in tone, IETF RFC style documents with interaction diagrams, syntax grammar, security considerations, and all. Dry & pedantic.

1 x RFC x1967 Gemini Implementation Recommendations: opinion piece about what Gemini is meant to be, its philosophy, its origin story. Plus practical bits and pieces. Not normative.

1 x IANA Registration for URI scheme gemini://:1965
1 x IANA Registration for Media Type text/gemini

1 x cURL gemini://: implementation as per https://curl.se/dev/new-protocol.html

Miscellanies:

A version control systems to support such collaborative work process.

A more preeminent domain name, such as gemini.info, gemini.xyz or something to host all of the above. Plus matching social media presence, @gemini everywhere.

Thoughts? Opinions? Suggestions?




From martin at no.ucant.org  Sun Dec 27 16:11:00 2020
From: martin at no.ucant.org (Martin Keegan)
Date: Sun, 27 Dec 2020 16:11:00 +0000 (GMT)
Subject: [user] wikipedia coverage of Gemini
Message-ID: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>


Hello,

following a reference to the problems of finding out about Gemini on 
Wikipedia, I've overhauled the page about "Gemini space", which had 
replaced "Gemini (protocol)" and which made it difficult to find at all. 
There are now two articles, one focused solely on the protocol (and thus 
more eligible to be in included in generic lists of protocols and so-on).

Previous contributors to this mailing list highlighted the problem that 
Wikipedia's policies militate against Gemini as it isn't trivially 
discoverable via the sources that Wikipedia privileges. We'll see if this 
persists as an issue; the mitigation would be to do some marketing, but 
that's probably not something we want just yet.

Mk

-- 
Martin Keegan, @mk270, https://mk.ucant.org/

From dctrud at randomroad.net  Sun Dec 27 16:12:30 2020
From: dctrud at randomroad.net (David Trudgian)
Date: Sun, 27 Dec 2020 10:12:30 -0600
Subject: [users] Manually curated directory of capsules?
In-Reply-To: <7E3854FB-68F5-49C4-B1B4-8F5C11C2A469@gmail.com>
References: <ce99290c-e154-4355-a775-125e268870ae@www.fastmail.com>
 <7E3854FB-68F5-49C4-B1B4-8F5C11C2A469@gmail.com>
Message-ID: <31ae1eec-01cd-4675-8c12-c3f4b1781350@www.fastmail.com>

Looks like there is a bit of interest in the directory idea, so I have gone ahead and put a very quick skeleton of some initial categories that I think make sense from my time browsing around the Gemini space up at: https://git.sr.ht/~dctrud/gemini-directory . This is now hosted at gemini://directory.randomroad.net

Note the disclaimer in index.gmi - the directory is almost empty to begin with, but putting it up now in the hope that I might get a few links suggested :-)

Hoping to work through the categories and add initial links over the remaining holidays this year. I'll 'officially' announce it once it hits the arbitrary target of 100 links.

Cheers!

dctrud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/40148c24/attachment.htm>

From bjorn.warmedal at gmail.com  Sun Dec 27 16:25:53 2020
From: bjorn.warmedal at gmail.com (=?utf-8?Q?Bj=C3=B6rn_W=C3=A4rmedal?=)
Date: Sun, 27 Dec 2020 17:25:53 +0100
Subject: [users] Manually curated directory of capsules?
In-Reply-To: <31ae1eec-01cd-4675-8c12-c3f4b1781350@www.fastmail.com>
References: <31ae1eec-01cd-4675-8c12-c3f4b1781350@www.fastmail.com>
Message-ID: <FA1101E4-1ABE-4BE3-9112-64DDF7942C7B@gmail.com>


> 27 dec. 2020 kl. 17:13 skrev David Trudgian <dctrud at randomroad.net>:
> 
> ?
> Looks like there is a bit of interest in the directory idea, so I have gone ahead and put a very quick skeleton of some initial categories that I think make sense from my time browsing around the Gemini space up at: https://git.sr.ht/~dctrud/gemini-directory . This is now hosted at gemini://directory.randomroad.net

A lot of capsule content are gemlog posts of varying subjects. How would you like that to be categorized? I.e. if <author> has a gemlog and writes about movies, sports, and food, should there be just one link to the gemlog itself under ?gemlogs?, a link to it under each of those categories, or a link to it under ?gemlogs? and links to individual posts under categories they fit?

Cheers,
ew0k

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/d2d395c9/attachment.htm>

From colecmac at protonmail.com  Sun Dec 27 16:38:38 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 27 Dec 2020 16:38:38 +0000
Subject: [spec] Oustanding issues
In-Reply-To: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
References: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
Message-ID: <lNC8-cVqAx7icvuI9SU-WrfhxokA0n0rmq_WWv2B2stvNgJvn47aCmoQs1KPmdxafJiHDS7ANewmUeJnpXcZ_5bVsaJbp3lJrphX146N1Uo=@protonmail.com>

> I'm trying to prepare a list of spec issues that I want to finalise as
> soon as possible.

Thanks! This is helpful. Fingers crossed it doesn't become a monster
megathread...


Also, I believe you've missed my small spec changes I proposed a while ago,
which have to do with the lang param. See these emails.

https://lists.orbitalfox.eu/archives/gemini/2020/003827.html
https://lists.orbitalfox.eu/archives/gemini/2020/003911.html


Cheers,
makeworld

From come at chilliet.eu  Sun Dec 27 16:40:28 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Sun, 27 Dec 2020 17:40:28 +0100
Subject: [users] Manually curated directory of capsules?
In-Reply-To: <31ae1eec-01cd-4675-8c12-c3f4b1781350@www.fastmail.com>
References: <ce99290c-e154-4355-a775-125e268870ae@www.fastmail.com>
 <7E3854FB-68F5-49C4-B1B4-8F5C11C2A469@gmail.com>
 <31ae1eec-01cd-4675-8c12-c3f4b1781350@www.fastmail.com>
Message-ID: <7675631.zbtgP7iTi5@tempete>

Le dimanche 27 d?cembre 2020, 17:12:30 CET David Trudgian a ?crit :
> Looks like there is a bit of interest in the directory idea, so I have gone ahead and put a very quick skeleton of some initial categories that I think make sense from my time browsing around the Gemini space up at: https://git.sr.ht/~dctrud/gemini-directory . This is now hosted at gemini://directory.randomroad.net
> 
> Note the disclaimer in index.gmi - the directory is almost empty to begin with, but putting it up now in the hope that I might get a few links suggested :-)

I?m hosting two capsules which are kind of directories themselves, one for games:
=> gemini://games.lanterne.chilliet.eu

And for french content, which I did not announce before because I thought I would have time to fill it a bit more:
=> gemini://fran?ais.lanterne.chilliet.eu

C?me



From solderpunk at posteo.net  Sun Dec 27 16:17:52 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 17:17:52 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <DA54016B-8D69-4CB8-B395-26744A84D0FD@gmail.com>
Message-ID: <C83PC4V0CT74.3SV0066R83LZH@stilgar>

On Sun Dec 27, 2020 at 4:32 PM CET, Petite Abeille wrote:

> The above are normative, neutral in tone, IETF RFC style documents with
> interaction diagrams, syntax grammar, security considerations, and all.
> Dry & pedantic.

This is basically the plan, I just want to get the current less formally
structured specification finalised before starting.  Translating it to a
proper RFC while it's still undergoing changes does not seem like a good
use of time/energy.

> 1 x IANA Registration for URI scheme gemini://:1965
> 1 x IANA Registration for Media Type text/gemini

We are not guaranteed to be able to get port 1965, as it's already
assigned by IANA - to some apparently obsolete commercial protocol now
owned (but not, as far as I can tell, actively used or promoted) by IBM.
I have no idea what IANA's policy on re-assigning previously assigned
port numbers is.  To my mind, permanently assigning numbers to
proprietary/commercial protocols is a bad idea as they are unlikely to
have long lifespans, but this is all obviously out of our hands.  So the
final port number may end up changing.  That's a shame, but it should be
an extremely easy fix to existing software.

I also don't know how the chicken-egg problem is usually resolved
whereby when applying for a port number registration from IANA you need
to give them a reference to a stable description of the protocol, but
obviously said stable description cannot, at that point in time, contain
the as-yet unassigned port number.  But obviously there is a way to
handle this, and we'll deal with it when the time comes.

> A more preeminent domain name, such as gemini.info, gemini.xyz or
> something to host all of the above.

This is also something I'm planning.  Everything currently lives at
circumlunar.space because I already owned the domain and, in the early
days, it was not clear things would come as far as they have and that
buying a new domain was warranted.  Going forward, I would like a
clearer separation between these two projects.  Naturally, I'll maintain
permanent redirects for a substantial time after the change.

> Plus matching social media presence,
> @gemini everywhere.

I have zero interest in running that myself, and don't really see enough
value in it to delegate that task to somebody else.  The most
enthusiastic uptake of Gemini has been people who I suspect have very
similar feelings.  It seems a poor cultural match.

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Dec 27 16:33:23 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 17:33:23 +0100
Subject: [spec] Proposed changes
Message-ID: <C83PO0VCH71H.3A5PCK1T74T0N@stilgar>

Hi all,

Below are some proposed spec changes to address some (but not yet all)
of the recently enumerated outstanding issues.  Feedback is welcome.

# Section 1.1:

In the outline of a Gemini transaction, the step:

> S:   Closes connection

becomes:

> S:   Closes connection (including TLS close_notify, see 4.2)

and the entire outline is followed by the following new text:

The outline above describes typical behaviour under typical
circumstances, and should be considered illustrative rather than
normative in every detail.  Some clarifying remarks follow.

It is generally the server's responsibility to close the connection,
however the client MAY close the connection at any time, e.g.
because it has not heard anything from the server for some time, or
because the size of the received response body has already exceeded
the size it is willing/able to handle.

Under non-success conditions, the server MAY send a response header
and close the connection before a complete request has been received
from the client.

The server SHOULD NOT close the connection without sending a response
header.

The client MAY begin handling a partially-received response body prior
to the closure of the connection by the server.

# Section 3

Two sets of changes here.  First, in order to address the issue of empty
<META>s:

The line:

> <META> is a UTF-8 encoded string of maximum length 1024 bytes, whose
> meaning is <STATUS> dependent.

becomes:

> <META> is a UTF-8 encoded string with a length between 1 and 1024
> bytes (inclusive), whose meaning is <STATUS> dependent.

(i.e. META may not be empty)

All instances of

> The contents of <META> may provide additional information on the
> failure

become:

> The contents of <META> SHOULD provide additional information on the
> failure

The line:

> If <META> is an empty string, the MIME type MUST default to
> "text/gemini; charset=utf-8".  The text/gemini media type is defined
> in section 5.

is removed.

Secondly, regarding redirects, the following additional lines are added
to the explanation of status code 3x in section 3.2.3:

Clients MAY request confirmation from a user before redirecting a
request.

Clients MUST NOT automatically redirect a request more than 5 times,
to prevent incorrectly or maliciously configured servers "trapping"
clients in infinite redirect sequences, which waste resources on
both sides.

# Section 4

A new subsection is added:

## 4.2 Close notification

As per RFCs 5246 and 8446, TLS 1.2 and 1.3 clients and servers both
MUST send a "close_notify" alert before closing their write side of
the connection.

Under ordinary conditions, the server is responsible for closing the
connection.  Besides being mandated by TLS RFCs, the use of
"close_notify" by the server is important as it allows clients to
disambiguate between successfully completed transactions and those
where the complete response body was not received due to a network
fault or attack.

Client authors should note that the semantics of "close_notify"
changed between TLS 1.2 and 1.3 - only in TLS 1.3 may a client safely
send a "close_notify" after a request to convey that it will not write
anything further and then continue to receive the response.  To avoid
interoperability problems, clients SHOULD NOT send a "close_notify"
before the server does under non-error conditions.  The completion of a
request is already unambiguously indicated by the CRLF characters.

Cheers,
Solderpunk

From dctrud at randomroad.net  Sun Dec 27 16:59:44 2020
From: dctrud at randomroad.net (David Trudgian)
Date: Sun, 27 Dec 2020 10:59:44 -0600
Subject: [users] Manually curated directory of capsules?
In-Reply-To: <FA1101E4-1ABE-4BE3-9112-64DDF7942C7B@gmail.com>
References: <31ae1eec-01cd-4675-8c12-c3f4b1781350@www.fastmail.com>
 <FA1101E4-1ABE-4BE3-9112-64DDF7942C7B@gmail.com>
Message-ID: <a4434227-9c2c-4d97-8b5e-f79408d47300@www.fastmail.com>

On Sun, Dec 27, 2020, at 10:25 AM, Bj?rn W?rmedal wrote:
> A lot of capsule content are gemlog posts of varying subjects. How would you like that to be categorized? I.e. if <author> has a gemlog and writes about movies, sports, and food, should there be just one link to the gemlog itself under ?gemlogs?, a link to it under each of those categories, or a link to it under ?gemlogs? and links to individual posts under categories they fit?

I guess the answer to categorization is that it'll be 'however I see fit'. but anyone submitting a link can suggest it's put where they think is best. I want this to be low effort, zero to-and-fro for anyone suggesting a link - just throw me a link, or put it where you think it goes in a patch. I'm not particularly interested in setting out rules and things around this, and I don't think they'd work. Sometimes a single post/page might be notable. Sometimes a link to the root of a capsule would be better. I'll do whatever I feel at the time :-)

Hopefully as I add links it'll basically show what I'm thinking, and prior to there being enough links for that I'll just move any suggestions as I see fit. My overriding goal with this is to have a place that just gets a bunch of links to interesting Gemini capsules 'out there'. It's a personal project that I'd love to get suggestions for, rather than a community project with aims, rules, etc. set out.

If it is at all useful and in the end someone takes the directory and makes it more structured, and that's better / more popular - well that'd be an excellent outcome.

Cheers,

dctrud

From colecmac at protonmail.com  Sun Dec 27 17:04:49 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 27 Dec 2020 17:04:49 +0000
Subject: [spec] Proposed changes
In-Reply-To: <C83PO0VCH71H.3A5PCK1T74T0N@stilgar>
References: <C83PO0VCH71H.3A5PCK1T74T0N@stilgar>
Message-ID: <LvYMhg3BzBHA9PM9fM8nClSE1qYVzPRGG4wmJQELklaLZy2lsN5Ebdw4Hnq4Oxk-3PVreTQ7-i40cHX6EvEyD75l89ZxhpK91w7jmb2P7GY=@protonmail.com>

I don't see what's wrong with having an empty META, and I believe this is
already in use. Why not just allow it and make the spec more clear so that
client authors know they need to be able to handle it? I would keep the tab
mandatory as well.


makeworld

From solderpunk at posteo.net  Sun Dec 27 17:02:27 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 18:02:27 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <lNC8-cVqAx7icvuI9SU-WrfhxokA0n0rmq_WWv2B2stvNgJvn47aCmoQs1KPmdxafJiHDS7ANewmUeJnpXcZ_5bVsaJbp3lJrphX146N1Uo=@protonmail.com>
Message-ID: <C83QAA2NY7X8.10KGUS6SKWRUU@stilgar>

On Sun Dec 27, 2020 at 5:38 PM CET,  wrote:

> Also, I believe you've missed my small spec changes I proposed a while
> ago,
> which have to do with the lang param. See these emails.
>
> https://lists.orbitalfox.eu/archives/gemini/2020/003827.html
> https://lists.orbitalfox.eu/archives/gemini/2020/003911.html

Ah, thanks.  These should, indeed, be dealt with.  But it's thankfully
very clear what to do and there's no discussion needed.  This will get
fixed in the next update (sometime before the end of this year!).

Cheers,
Solderpunk

From solderpunk at posteo.net  Sun Dec 27 17:06:42 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 18:06:42 +0100
Subject: [spec] Proposed changes
In-Reply-To: <LvYMhg3BzBHA9PM9fM8nClSE1qYVzPRGG4wmJQELklaLZy2lsN5Ebdw4Hnq4Oxk-3PVreTQ7-i40cHX6EvEyD75l89ZxhpK91w7jmb2P7GY=@protonmail.com>
Message-ID: <C83QDJ4HMBDT.B67DERRV9EZM@stilgar>

On Sun Dec 27, 2020 at 6:04 PM CET,  wrote:
> I don't see what's wrong with having an empty META, and I believe this
> is
> already in use. Why not just allow it and make the spec more clear so
> that
> client authors know they need to be able to handle it? I would keep the
> tab
> mandatory as well.

For previous discussion see
https://lists.orbitalfox.eu/archives/gemini/2020/003009.html.

The thinking is that there are circumstances where an empty META makes
no sense.  The clearest case is in redirects, where there *must* be a
new URL to request.  An empty META with a 1x status code *could* be
handled sensibly with a default prompt, but leads to a very poor user
experience (they have no idea what they're being asked to submit).

Response handling is simplest if META is either always optional or
always required (otherwise handling needs to be conditioned on the
status code), and since always optional is not sensible (due to the
above situations), always required is the simplest course of action.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Sun Dec 27 17:34:53 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 18:34:53 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <C83PC4V0CT74.3SV0066R83LZH@stilgar>
References: <C83PC4V0CT74.3SV0066R83LZH@stilgar>
Message-ID: <3E5B1340-F1FB-41F6-BB5F-3A9DCB530DD3@gmail.com>



> On Dec 27, 2020, at 17:17, Solderpunk <solderpunk at posteo.net> wrote:
> 
> This is basically the plan, I just want to get the current less formally
> structured specification finalized before starting. 

Yes, once all the current open issues are settled. Sounds like a plan. 2021 is going to be groovy.


From johann at qwertqwefsday.eu  Sun Dec 27 17:54:38 2020
From: johann at qwertqwefsday.eu (Johann Galle)
Date: Sun, 27 Dec 2020 18:54:38 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
References: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
Message-ID: <eee2f372-5713-84e3-bb93-a94a4e1d29d3@qwertqwefsday.eu>

On 2020-12-27T10:47Z, Solderpunk wrote among other things:
 > * Clarification on the use of TLS close_notify has been requested.
 >?? This is actually mandated by both TLS 1.2 and 1.3 specs so technically
 >?? it's redundant to mention it in the Gemini spec, but given how poorly
 >?? implemented it is, some explicit reminding could not hurt.? I think
 >?? there's a tiny wrinkle to consider here on *when* the client should
 >?? send this (due to a change in semantics between TLS 1.2 and 1.3).
 > * The spec is a bit vague on under which circumstances the META part of
 >?? a response header may be empty, and on exactly what that means (e.g.
 >?? is a tab after the status code still required in any case?). This
 >?? needs to be tightened up, and I'm pretty sure this should be done by
 >?? just making non-empty META a requirement.

As you have now mentioned these two issues, there was a mail with these two and
another issue[1], namely if lone LFs (or lone CRs or other line breaking code
points for that matter) are allowed inside META.

Johann

[1] https://lists.orbitalfox.eu/archives/gemini/2020/003276.html
---
You can verify the digital signature on this email with the public key
available through web key discovery. Try e.g. `gpg --locate-keys`...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/0895ac48/attachment-0001.sig>

From cowan at ccil.org  Sun Dec 27 19:35:22 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 14:35:22 -0500
Subject: [spec] Oustanding issues
In-Reply-To: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
References: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
Message-ID: <CAD2gp_RafLcecn+mMk3Sc+HFVZ9uaTOU2b2FSfZRWgERMe0PAw@mail.gmail.com>

On Sun, Dec 27, 2020 at 6:23 AM Solderpunk <solderpunk at posteo.net> wrote:


> * The spec is a bit vague on under which circumstances the META part of
>   a response header may be empty, and on exactly what that means (e.g.
>   is a tab after the status code still required in any case?).  This
>   needs to be tightened up, and I'm pretty sure this should be done by
>   just making non-empty META a requirement.
>

If empty META strings are going to be invalid (I think they should be),
then the last graf of 3.3 should be deleted.


* There's been a request for recommendations on logging of queries.  I
>   think this is out of scope for the itself, but an entirely
>   appropriate thing to mention in either the Best Practices document or
>   a separate companion standard for standard logging format.
>

I'll address that in a separate thread.  I'm also going to talk about i18n
issues (other than IRIs) in a separate thread.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
A rose by any other name may smell as sweet, but if you called it
an onion you'd get cooks very confused.          --RMS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/f93c8296/attachment.htm>

From cowan at ccil.org  Sun Dec 27 19:40:42 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 14:40:42 -0500
Subject: IETF policy on encodings and languages
Message-ID: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>

We already have good support for multiple encodings and (in the case of
text/gemini) languages.  However, two questions arise:

a) What character encoding is used for META parts intended for human
consumption?  TL;dr answer: UTF-8.

b) What language is used for those META parts, since the server does not
know what languages are acceptable to the user?  TL;dr answer: start with
English, add other languages as necessarily or useful.

Details:

BCP 18, IETF Policy on Character Sets and Languages <
https://tools.ietf.org/html/bcp18>, says what a spec should say about
character sets and languages.  The MUSTard of this BCP is:

1) Specs MUST say which parts of the protocol are meant to be
human-readable.  The answer should be that the META of status lines 1x, 4x
(except 44), 5x, and 6x are human-readable and everything else is part of
the protocol.

2) Protocols MUST specify which character encoding is in use, and it MUST
be possible for it to be UTF-8.  Nailing that down for human-readable META
text is what needs to be done.  See (a).

3) Encodings that are used MUST be in the IANA registry.  Because we are
using media types, that happens already.  No action needed.

4) Protocols MUST have a way (which can be a default) of communicating the
encoding in use.  Fixing (2) will fix this one also.

5) Protocols in which users have text presented to them MUST have a way of
dealing with multiple languages.  We have a problem here for 1x that isn't
trivial to solve: what should a Russian search engine indexing both English
and Russian documents return as the META to a 1x response?  (6) is one
approach.

6) Where there is no ability to negotiate languages (Gemini doesn't), then
"i-default" language SHOULD be used.  "i-default" text MUST be
understandable to an English-speaking person, but MAY include text in other
languages if appropriate (e.g. the languages of the capsule or server).
See (b) and (6).

7) Protocols SHOULD use BCP 47 language tags to specify languages.  We do.

8) Material on i18n SHOULD be collected into a special section so that it
can be found by people concerned with i18n or L10n.  That one's up to
Solderpunk, though it will be necessary if the spec becomes one or more
RFCs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/d5736fe1/attachment.htm>

From pjvm742 at disroot.org  Sun Dec 27 19:56:28 2020
From: pjvm742 at disroot.org (pjvm742 at disroot.org)
Date: Sun, 27 Dec 2020 19:56:28 +0000
Subject: [user] wikipedia coverage of Gemini
In-Reply-To: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>
References: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>
Message-ID: <4fe60d0fa217585872871100c459166d@disroot.org>

> Previous contributors to this mailing list highlighted the problem
> that Wikipedia's policies militate against Gemini as it isn't
> trivially discoverable via the sources that Wikipedia privileges.

"militate" is a strong word... Wikipedia can't let everything in, so
it restricts articles to topics for which there exist sources that
cover it in relative detail, are independent and 'generally reliable'.
<1> To be honest, I'm not sure the two articles would currently
survive a deletion discussion: the sources they cite are stuff like
announcements by gemini-related projects - not independent - and blog
posts - not considered 'generally reliable'.

So really, the existence of a Gemini article is not guaranteed until
it is covered by a publication, preferably multiple publications,
that meet(s) that standard. 'General reliability' mostly has to do
with having a "reputation for fact-checking and accuracy".<2>

Obviously, we think Wikipedia should have an article on Gemini, but
equally obviously, we are biased. Unfortunately for us, the Wikipedia
bureaucracy can be quite unforgiving :).

> We'll see if this persists as an issue; the mitigation would be to
> do some marketing, but that's probably not something we want just
> yet.

My instinctive response is to end that sentence with "ever" instead. I
associate the term marketing with empty publicity for commercial
products. Gemini will naturally become gradually more relevant as
people keep putting effort into it, and consequently more well-known.

<1> https://en.wikipedia.org/wiki/Wikipedia:Notability
<2> https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources

From solderpunk at posteo.net  Sun Dec 27 19:56:53 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 20:56:53 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <CAD2gp_RafLcecn+mMk3Sc+HFVZ9uaTOU2b2FSfZRWgERMe0PAw@mail.gmail.com>
Message-ID: <C83TZTSJLTUR.SVRFRYSXVQCR@stilgar>

On Sun Dec 27, 2020 at 8:35 PM CET, John Cowan wrote:
> On Sun, Dec 27, 2020 at 6:23 AM Solderpunk <solderpunk at posteo.net>
> wrote:

> If empty META strings are going to be invalid (I think they should be),
> then the last graf of 3.3 should be deleted.

Agreed, this was one of the changes in my recent "Proposed changes"
post.

Cheers,
Solerpunk


From pjvm742 at disroot.org  Sun Dec 27 19:58:21 2020
From: pjvm742 at disroot.org (pjvm742 at disroot.org)
Date: Sun, 27 Dec 2020 19:58:21 +0000
Subject: [user] wikipedia coverage of Gemini
In-Reply-To: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>
References: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>
Message-ID: <42ab7435df672b4c949ae907a9738c3b@disroot.org>

> Previous contributors to this mailing list highlighted the problem
> that Wikipedia's policies militate against Gemini as it isn't
> trivially discoverable via the sources that Wikipedia privileges.

"militate" is a strong word... Wikipedia can't let everything in, so
it restricts articles to topics for which there exist sources that
cover it in relative detail, are independent and 'generally reliable'.
<1> To be honest, I'm not sure the two articles would currently
survive a deletion discussion: the sources they cite are stuff like
announcements by gemini-related projects - not independent - and blog
posts - not considered 'generally reliable'.

So really, the existence of a Gemini article is not guaranteed until
it is covered by a publication, preferably multiple publications,
that meet(s) that standard. 'General reliability' mostly has to do
with having a "reputation for fact-checking and accuracy".<2>

Obviously, we think Wikipedia should have an article on Gemini, but
equally obviously, we are biased. Unfortunately for us, the Wikipedia
bureaucracy can be quite unforgiving :).

> We'll see if this persists as an issue; the mitigation would be to
> do some marketing, but that's probably not something we want just
> yet.

My instinctive response is to end that sentence with "ever" instead. I
associate the term marketing with empty publicity for commercial
products. Gemini will naturally become gradually more relevant as
people keep putting effort into it, and consequently more well-known.

<1> https://en.wikipedia.org/wiki/Wikipedia:Notability
<2> https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources

From cowan at ccil.org  Sun Dec 27 19:59:02 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 14:59:02 -0500
Subject: [spec] Adapting the HTTP Common Logging Format for use by Gemini
 servers
Message-ID: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>

The Common Logging Format as defined by Apache and other HTML servers
contains one line per client request divided into seven fields separated by
a single space.  They are:

1) IP address, either IPv4 or IPv6

2) Hostname of the client, or "-" if not known.

3) Name of the user, or "-" if not known.

4) Date in square brackets, in the form [10/Oct/2000:13:55:36 -0700].

5) Request line in double quotes.

6) Status code of response.

7) Number of bytes in the response body, or 0 if none.

I think there are two reasonable approaches to adapting this format to
Gemini, the "as compatible as possible" or "ACAP" approach, and the
"literal" approach.  In either approach, fields 1 and 7 are just as in
HTTP, and fields 2 and 3 are just "-".

On the ACAP approach, field 4 uses the date format above, field 5 contains
GET followed by the path segment of the URL followed by HTTP/1.1 (all space
separated), and field 6 contains the Gemini code converted to an equivalent
HTTP code (e.g. 20 becomes 200).  I'll work out the full equivalence later
if people like this.

On the literal approach, field 4 is ISO 8601 (RFC 3336) format, field 5 is
the URL request line (no quotes needed), and field 6 is the Gemini status
code unconverted.

The advantage of the ACAP approach is that it allows existing HTTP log
analyzers to be used.  The literal approach keeps all available information
but will need its own analysis tools.  Of course, a server can support both
log formats as well as any other formats desired, so the question is which
format is Best Practice if only one is provided.  It's possible to convert
literal format to ACAP format after the fact, but not vice versa.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/bb62fb83/attachment-0001.htm>

From nothien at uber.space  Sun Dec 27 20:06:40 2020
From: nothien at uber.space (Arav K.)
Date: Sun, 27 Dec 2020 21:06:40 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
Message-ID: <20201227200640.ht4msim2hkbkauoz@gux>

On Sun, Dec 27, 2020 at 02:40:42PM -0500, John Cowan wrote:
> b) What language is used for those META parts, since the server does not
> know what languages are acceptable to the user?  TL;dr answer: start with
> English, add other languages as necessarily or useful.

The best-case scenario, of course, is that everybody sees the
human-readable META parts in their own language.  The issue with that is
either the client has to specify what language they expect it in, or the
server has to provide it in every language it supports.  Both are
obviously flawed.

One counterproposal to this best-case scenario is that the response body
being sent over (for successful requests) is also (probably) only in a
single language.  It would thus be natural to have the whole interface
in that same language.  If the server offers the same file / page in
different languages, they will have different URLs (most commonly
<lang>.example.com/... or example.com/<lang>/...).  In both of these
cases, the server can easily recognize from the URL what language is
expected and should provide an interface (including human-readable META
text) in that same language.  That would mean, for example, that the
entire ://fr.example.com site should use a French interface.  We
probably also want to disallow using example.com/...?lang=<lang> or
anything similar, even if it's just in the Best Practices document.

It's the server's responsibility, but also their prerogative, to provide
an interface in multiple languages.  If they don't, and if the users of
that server choose not to as well, then it is up to the client (and the
user controlling it) to translate stuff.  text/gemini's lang parameter
helps here.

I think that this proposal resolves the general interface language
issue.  Have I missed anything?

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/028f134d/attachment.sig>

From nothien at uber.space  Sun Dec 27 20:10:54 2020
From: nothien at uber.space (Arav K.)
Date: Sun, 27 Dec 2020 21:10:54 +0100
Subject: [spec] Adapting the HTTP Common Logging Format for use by Gemini
 servers
In-Reply-To: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
Message-ID: <20201227201054.sjtagtfif3cxrkfl@gux>

On Sun, Dec 27, 2020 at 02:59:02PM -0500, John Cowan wrote:
> On the literal approach, field 4 is ISO 8601 (RFC 3336) format, field 5 is
> the URL request line (no quotes needed), and field 6 is the Gemini status
> code unconverted.

We want to be careful about malicious clients sending a request like
'\n<garbage or fake log here>'.  Although that may fail, it would still
show up in the logs and mess them up.  Perhaps the logger should check
if the request line is a proper URL, and if it is not it would encode it
in some way (perhaps just URL-encoding it, because that function may
already be available to the code).

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/e5f1c805/attachment.sig>

From solderpunk at posteo.net  Sun Dec 27 20:04:01 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 21:04:01 +0100
Subject: [spec] Adapting the HTTP Common Logging Format for use by
 Gemini servers
In-Reply-To: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
Message-ID: <C83U5AESUL6S.15B9IC0LL5IFI@stilgar>

Historically, efforts to establish a common logging format for Gemini
have not been well received.  I think there's already too much diversity
out there and server authors are reluctant to change.  The question of
whether or not IP addresses should be routinely logged also usually
proves quite divisive.

I still think there's value in such a standard (as it allows for
reusable log processing tools), but I definitely think it's out of scope
for the protocol spec proper and belongs in a companion spec.  I think
those are better suited to [tech] than [spec]?

For the record, I don't like that the Apache format uses spaces as a
field separator when spaces also occur inside the date.  Molly Brown's
log format uses tabs as separators, so it works very nicely with the
standard `cut` utility.  I use `cut`, `grep`, `sort`, `uniq` and `wc -l`
in short pipelines to run queries on my logs, and really enjoy being
able to do so.

Cheers,
Solderpunk

From cowan at ccil.org  Sun Dec 27 20:21:15 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 15:21:15 -0500
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <DA54016B-8D69-4CB8-B395-26744A84D0FD@gmail.com>
References: <DA54016B-8D69-4CB8-B395-26744A84D0FD@gmail.com>
Message-ID: <CAD2gp_TmyxdXspF3eQQ98qp2Y=HPha5mVVsJXU7ie4dD-qGT5Q@mail.gmail.com>

On Sun, Dec 27, 2020 at 10:32 AM Petite Abeille <petite.abeille at gmail.com>
wrote:


> 1 ? RFC x1965 The Gemini Protocol: describes the over-the-wire protocol
> itself
> 1 ? RFC x1966 The Gemini Document:. describes the text/gemini document
> forma
>

+1.  Note, however, that creating standards-track RFCs (as I hope we will)
implies the possibility that the IETF WG will make changes.  If the present
Gemini community doesn't want to give up change control, we can publish an
informational RFC instead.  Anyone with an email address can join an IETF
WG, however, so we can still have influence, just not control.

> 1 x RFC x1967 Gemini Implementation Recommendations: opinion piece about
> what Gemini is meant to be, its philosophy, its origin story. Plus
> practical bits and pieces. Not normative.
>

Typically documents like this are not RFCs nowadays.

1 x IANA Registration for URI scheme gemini://:1965
> 1 x IANA Registration for Media Type text/gemini
>

There is no reason not to merge the IANA registrations into the main
documents.  Separate RFCs have been used in the past when the protocol or
media type was already in use but there was no existing URI scheme.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Heh, heh: ... or three pairs of wheels? I wonder what would have happened
if Ravna had just read a little further. In some weird way, Twirlip
knows the Secret of the Riders.   --Vernor Vinge, note 601
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/2a2a7d46/attachment.htm>

From solderpunk at posteo.net  Sun Dec 27 20:31:55 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 21:31:55 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <CAD2gp_TmyxdXspF3eQQ98qp2Y=HPha5mVVsJXU7ie4dD-qGT5Q@mail.gmail.com>
Message-ID: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>

On Sun Dec 27, 2020 at 9:21 PM CET, John Cowan wrote:

> +1. Note, however, that creating standards-track RFCs (as I hope we
> will)
> implies the possibility that the IETF WG will make changes. If the
> present
> Gemini community doesn't want to give up change control, we can publish
> an
> informational RFC instead. Anyone with an email address can join an IETF
> WG, however, so we can still have influence, just not control.

This is something I've been concerned about (slightly, distantly).  I
haven't looked much into the IETF/IANA processes yet because, as I've
said, I want to focus on first getting the final details locked down so
we can start productively working toward it.  But I have wondered
exactly what is involved and to what extent we sacrifice control.  I
have a generally positive perception of the IETF, but I am also acutely
aware that the cultural/ideological perspective of Gemini folks is rare
and unusual in the wider world, and I don't know to what extent it would
be valued and preserved by a standards body that necessarily nowadays
must have quite strong ties to the exactly the kind of big, powerful
commercial entities that Gemini is trying to provide an escape from...

Cheers,
Solderpunk


From come at chilliet.eu  Sun Dec 27 20:39:41 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Sun, 27 Dec 2020 21:39:41 +0100
Subject: [spec] Adapting the HTTP Common Logging Format for use by Gemini
 servers
In-Reply-To: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
Message-ID: <2050148.5bT7vuFU4P@tempete>

The main differences with what my server is doing are:

* I use CSV format
* I do not log the IP but its sha1 hash, because of privacy concerns
* I use ISO 8601 for date because it?s easy to output from PHP
* I do not log the body length, but I log the meta line instead, which is important (especially for errors)



From cowan at ccil.org  Sun Dec 27 20:41:14 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 15:41:14 -0500
Subject: IETF policy on encodings and languages
In-Reply-To: <20201227200640.ht4msim2hkbkauoz@gux>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
Message-ID: <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>

On Sun, Dec 27, 2020 at 3:06 PM Arav K. <nothien at uber.space> wrote:


> the server can easily recognize from the URL what language is
> expected and should provide an interface (including human-readable META
> text) in that same language.  That would mean, for example, that the
> entire ://fr.example.com site should use a French interface.


And if you request gemini://example.com/la/non-exsistens.gmi and there is
no support for Latin error messages, as there probably is not?  Then what
language should be used?  With the exception of 1x responses,
human-readable <META> reflects error situations, where by definition the
server doesn't know what the user can or cannot understand.

> We probably also want to disallow using example.com/...?lang=<lang> or
> anything similar, even if it's just in the Best Practices document.
>

I have no idea why you would want to disallow that.  Changes to the query
string *are* changes to the URL, so that a particular language could be
equally well indicated using the domain, the path, or the query, depending
on the server's conventions.

It's the server's responsibility, but also their prerogative, to provide
> an interface in multiple languages.  If they don't, and if the users of
> that server choose not to as well, then it is up to the client (and the
> user controlling it) to translate stuff.


That's ideal, but it's a big burden on the client, which has to use
something as general as Google Translate to convert the Russian error
message being returned by the server to the Welsh expected by the user.

text/gemini's lang parameter helps here.
>

Not really: again, we are talking about the language of error messages.

Another point is that people often google for the meaning of error
messages, and that's made easier if they always look the same, or at least
some part of them always looks the same.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Where the wombat has walked, it will inevitably walk again.
   (even through brick walls!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/fa656b98/attachment-0001.htm>

From petite.abeille at gmail.com  Sun Dec 27 21:43:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 22:43:31 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
Message-ID: <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>


> On Dec 27, 2020, at 21:31, Solderpunk <solderpunk at posteo.net> wrote:
> 
> the cultural/ideological perspective of Gemini folks is rare and unusual in the wider world

Yes, diversity is valuable, and an added value to Gemini as it makes it stand out from the commercial crowd; but the Internet Engineering Task Force (IETF) concerns itself with engineering issues, not cultural ones.

I don't foresee any engineering issues if we do our due diligence.

If, somehow, things get derailed, an informational RFC is as good as a standard-track for the intended purpose of formally describing the protocol.

Irrespectively,  the value added of the IETF is its process and formalism. 

It's up to us to raise to their standard. 


From petite.abeille at gmail.com  Sun Dec 27 21:45:44 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 22:45:44 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <CAD2gp_TmyxdXspF3eQQ98qp2Y=HPha5mVVsJXU7ie4dD-qGT5Q@mail.gmail.com>
References: <DA54016B-8D69-4CB8-B395-26744A84D0FD@gmail.com>
 <CAD2gp_TmyxdXspF3eQQ98qp2Y=HPha5mVVsJXU7ie4dD-qGT5Q@mail.gmail.com>
Message-ID: <58B7E395-45CE-4904-AD7E-D9D063B8D073@gmail.com>



> On Dec 27, 2020, at 21:21, John Cowan <cowan at ccil.org> wrote:
> 
> 1 x IANA Registration for URI scheme gemini://:1965
> 1 x IANA Registration for Media Type text/gemini
> 
> There is no reason not to merge the IANA registrations into the main documents.  Separate RFCs have been used in the past when the protocol or media type was already in use but there was no existing URI scheme.

Sure. Didn't mean they have to be separate documents (even though there is a bit of bureaucracy involved), but rather to list them as TODOs.


From colecmac at protonmail.com  Sun Dec 27 21:48:13 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Sun, 27 Dec 2020 21:48:13 +0000
Subject: [spec] Adapting the HTTP Common Logging Format for use by Gemini
 servers
In-Reply-To: <2050148.5bT7vuFU4P@tempete>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
 <2050148.5bT7vuFU4P@tempete>
Message-ID: <gjw6WBiEbOwHsSZQSiQNFDFP59jsJeL-2oisXsjjgVu-Jtwyx7mOmqVvznnoQJHqYL6MCX-GWeEuKjpNT3fR-kmKWgGvHruBVbGo3qXEO64=@protonmail.com>

> * I do not log the IP but its sha1 hash, because of privacy concerns

Doesn't this provide no security though? It's trivial to hash all IPv4
addresses and compare them. Additionally, this doesn't provide any
security to clients, because they can't guarantee this is in effect.

makeworld

From petite.abeille at gmail.com  Sun Dec 27 21:49:33 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 22:49:33 +0100
Subject: [tech] Re: [spec] Adapting the HTTP Common Logging Format for use by
 Gemini servers
In-Reply-To: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
Message-ID: <1B906327-CCAF-4F36-BEAD-32FF196B9CD6@gmail.com>



> On Dec 27, 2020, at 20:59, John Cowan <cowan at ccil.org> wrote:
> 
> The Common Logging Format as defined by Apache and other HTML servers contains one line per client request divided into seven fields separated by a single space.  They are:
> 

IMO, that's should be left to the implementations. Their choice. Whatever is convenient. 

Doesn't hurt to point to the Common Logging Format as a FYI. And even suggest a mapping, the same way the CGI spec has been shoehorned back into Gemini. 

But that really seem to be an implementation detail.

From petite.abeille at gmail.com  Sun Dec 27 21:53:20 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 22:53:20 +0100
Subject: [tech] Re: [spec] Adapting the HTTP Common Logging Format for use by
 Gemini servers
In-Reply-To: <gjw6WBiEbOwHsSZQSiQNFDFP59jsJeL-2oisXsjjgVu-Jtwyx7mOmqVvznnoQJHqYL6MCX-GWeEuKjpNT3fR-kmKWgGvHruBVbGo3qXEO64=@protonmail.com>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
 <2050148.5bT7vuFU4P@tempete>
 <gjw6WBiEbOwHsSZQSiQNFDFP59jsJeL-2oisXsjjgVu-Jtwyx7mOmqVvznnoQJHqYL6MCX-GWeEuKjpNT3fR-kmKWgGvHruBVbGo3qXEO64=@protonmail.com>
Message-ID: <B900C8C8-45AD-41E8-925A-B6950F2C4CAC@gmail.com>



> On Dec 27, 2020, at 22:48, colecmac at protonmail.com wrote:
> 
> Doesn't this provide no security though? It's trivial to hash all IPv4
> addresses and compare them. Additionally, this doesn't provide any
> security to clients, because they can't guarantee this is in effect.

Genau. Privacy by obscurity is no privacy at all.

Furthermore, TLS leaves a big, fat digital signature trail. 

In any case, best to leave such details to the implementations.



From gmi1 at scotdoyle.com  Sun Dec 27 22:16:24 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Sun, 27 Dec 2020 16:16:24 -0600
Subject: [spec] Proposed changes
Message-ID: <764da81d-75f1-d800-f7d7-16143c32f994@scotdoyle.com>

(I apologize for breaking the thread view by not replying directly to
the original message.)

> ...
>
> Client authors should note that the semantics of "close_notify"
> changed between TLS 1.2 and 1.3 - only in TLS 1.3 may a client safely
> send a "close_notify" after a request to convey that it will not write
> anything further and then continue to receive the response.  To avoid
> interoperability problems, clients SHOULD NOT send a "close_notify"
> before the server does under non-error conditions.  The completion of a
> request is already unambiguously indicated by the CRLF characters.

Thanks Solderpunk for proposing these updates.

Section 6.1 of RFC 8446 [1] is specified in order to avoid truncation
attacks. Since, as you noted, the server has another way to determine
that a full request has been received, I think there is no need for a
client to send a TLS close_notify.

The server is allowed to close the read side of its TCP connection at
any time:

    Both parties need not wait to receive a "close_notify" alert
    before closing their read side of the connection, though doing
    so would introduce the possibility of truncation.

Since the sender of a close_notify is allowed to fully close the TCP
connection without waiting for a response, I think the RFC is
implicitely giving permission to the receiver of the close_notify
not to respond in kind.

This is also what I recall seeing in HTTP and Gemini TLS 1.3 packet
flows. Immediately after sending a TLS close_notify the server would
send a TCP FIN (disconnect) packet. When the client received the TLS
close_notify, it would not reply with its own close_notify. Rather,
it would wait for the TCP FIN packet and then reply with its own TCP
FIN packet.



[1] RFC 8446

Section 6.1. Closure Alerts

    The client and the server must share knowledge that the connection is
    ending in order to avoid a truncation attack.

    close_notify:  This alert notifies the recipient that the sender will
       not send any more messages on this connection.  Any data received
       after a closure alert has been received MUST be ignored.

    ...

    Either party MAY initiate a close of its write side of the connection
    by sending a "close_notify" alert.  Any data received after a closure
    alert has been received MUST be ignored.  If a transport-level close
    is received prior to a "close_notify", the receiver cannot know that
    all the data that was sent has been received.

    Each party MUST send a "close_notify" alert before closing its write
    side of the connection, unless it has already sent some error alert.
    This does not have any effect on its read side of the connection.
    Note that this is a change from versions of TLS prior to TLS 1.3 in
    which implementations were required to react to a "close_notify" by
    discarding pending writes and sending an immediate "close_notify"
    alert of their own.  That previous requirement could cause truncation
    in the read side.  Both parties need not wait to receive a
    "close_notify" alert before closing their read side of the
    connection, though doing so would introduce the possibility of
    truncation.

    ...



From sean at conman.org  Sun Dec 27 22:18:08 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 27 Dec 2020 17:18:08 -0500
Subject: [spec] adding a "magic number" for gemini files
In-Reply-To: <X+h2f3Ymzh79fsHO@kurosawa.casa.net>
References: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
 <C82TSBUY1QBI.UNG3VL20MGXD@stilgar> <X+dcrk/JFdyccE/J@kurosawa.casa.net>
 <20201226232543.GB3625@brevard.conman.org>
 <X+h2f3Ymzh79fsHO@kurosawa.casa.net>
Message-ID: <20201227221808.GI3625@brevard.conman.org>

It was thus said that the Great cage once stated:
> On Sat, Dec 26, 2020 at 06:25:43PM -0500, Sean Conner wrote:
> 
> [...]
> 
> > > I was  thinking abo[u]t file(1) and  libmagic in general.
> >
> >   I use libmagic for my server [1] and yet, I still use an extension to mark
> > a Gemini text file.
> 
> Do you mean you check the file extension for recognize a gemini file?
> Or  you use  same kind  of heuristic  to prevent  libmagic to  returns
> gemini file as text?

  In the configuration file, the user can specify a mapping of extensions to
MIME type, to which the default extension type that identifies a Gemini
index file is added (which for my server is ".gemini" but that can be
changed).

  During a request, the extension is checked against this mapping.  If (for
a non-Gemini file) this doesn't exist, only then is libmagic queried.

  -spc

From karmanyaahm at gmail.com  Sun Dec 27 22:20:01 2020
From: karmanyaahm at gmail.com (Karmanyaah Malhotra)
Date: Sun, 27 Dec 2020 17:20:01 -0500
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <C83PC4V0CT74.3SV0066R83LZH@stilgar>
References: <C83PC4V0CT74.3SV0066R83LZH@stilgar>
Message-ID: <7d0815f0-4678-ebe8-0190-21ad1a797e26@gmail.com>

>> A more preeminent domain name, such as gemini.info, gemini.xyz or
>> something to host all of the above.
> 
> This is also something I'm planning.  Everything currently lives at
> circumlunar.space because I already owned the domain and, in the early


The big problem with that is that since Gemini is a relatively common
name, most domains are taken. After reading this thread, just out of
interest, I contacted the seller(/scalper/) of gemini.net; they're
quoting about $30k which is probably too much, even though that domain
is just parked.

-- 
Karmanyaah Malhotra
https://karmanyaah.malhotra.cc/contact/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/fa5561fd/attachment-0001.sig>

From cowan at ccil.org  Sun Dec 27 22:20:50 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 17:20:50 -0500
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
References: <CAD2gp_TmyxdXspF3eQQ98qp2Y=HPha5mVVsJXU7ie4dD-qGT5Q@mail.gmail.com>
 <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
Message-ID: <CAD2gp_Srftvp9Oq5YWjCTLLhUiUGZkNkV1ZxaJt6iYNm+bOXXg@mail.gmail.com>

On Sun, Dec 27, 2020 at 3:36 PM Solderpunk <solderpunk at posteo.net> wrote:

But I have wondered
> exactly what is involved and to what extent we sacrifice control.  I
> have a generally positive perception of the IETF, but I am also acutely
> aware that the cultural/ideological perspective of Gemini folks is rare
> and unusual in the wider world, and I don't know to what extent it would
> be valued and preserved by a standards body that necessarily nowadays
> must have quite strong ties to the exactly the kind of big, powerful
> commercial entities that Gemini is trying to provide an escape from...
>

I'd say it has the fewest possible such ties, less than any other standards
organization except the ISO (whose members are countries).  While it's true
that most IETF participants (= members) are there as part of their paid
employment, the IETF makes it very clear that nobody speaks for anyone or
anything except themselves.  "The Tao of IETF" spells this out in great
detail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/998d4eec/attachment.htm>

From petite.abeille at gmail.com  Sun Dec 27 22:31:09 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 23:31:09 +0100
Subject: [tech] [spec] Adapting the HTTP Common Logging Format for use by
 Gemini servers
In-Reply-To: <B900C8C8-45AD-41E8-925A-B6950F2C4CAC@gmail.com>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
 <2050148.5bT7vuFU4P@tempete>
 <gjw6WBiEbOwHsSZQSiQNFDFP59jsJeL-2oisXsjjgVu-Jtwyx7mOmqVvznnoQJHqYL6MCX-GWeEuKjpNT3fR-kmKWgGvHruBVbGo3qXEO64=@protonmail.com>
 <B900C8C8-45AD-41E8-925A-B6950F2C4CAC@gmail.com>
Message-ID: <FC1A1A69-83DA-4862-8428-784ED2FAB622@gmail.com>



> On Dec 27, 2020, at 22:53, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Furthermore, TLS leaves a big, fat digital signature trail. 

Previously on Gemini:

https://tlsfingerprint.io
https://tlsfingerprint.io/static/frolov2019.pdf

Related to:
https://ssd.eff.org/en/module/what-fingerprinting

While Gemini has far fever moving part than HTTP, it still has some.

I'm not a privacy expert though, so not sure how practical this all is. But a trail is a trail :)


From petite.abeille at gmail.com  Sun Dec 27 22:46:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Sun, 27 Dec 2020 23:46:39 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <7d0815f0-4678-ebe8-0190-21ad1a797e26@gmail.com>
References: <C83PC4V0CT74.3SV0066R83LZH@stilgar>
 <7d0815f0-4678-ebe8-0190-21ad1a797e26@gmail.com>
Message-ID: <D73195EA-A71E-4A1E-AC16-9A41FB397943@gmail.com>



> On Dec 27, 2020, at 23:20, Karmanyaah Malhotra <karmanyaahm at gmail.com> wrote:
> 
>  gemini.net

Perhaps gemi.ni if one can get the Nicaraguans to cooperate :D

Alternatively, geminiprotocol.dev goes for a low-low price of $15.99! Going fast! Get it now! While supplies last!


From sean at conman.org  Sun Dec 27 22:57:13 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 27 Dec 2020 17:57:13 -0500
Subject: IETF policy on encodings and languages
In-Reply-To: <20201227200640.ht4msim2hkbkauoz@gux>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
Message-ID: <20201227225713.GJ3625@brevard.conman.org>

It was thus said that the Great Arav K. once stated:
> On Sun, Dec 27, 2020 at 02:40:42PM -0500, John Cowan wrote:
> > b) What language is used for those META parts, since the server does not
> > know what languages are acceptable to the user?  TL;dr answer: start with
> > English, add other languages as necessarily or useful.
> 
> The best-case scenario, of course, is that everybody sees the
> human-readable META parts in their own language.  The issue with that is
> either the client has to specify what language they expect it in, or the
> server has to provide it in every language it supports.  Both are
> obviously flawed.

  Here's a list of resonse codes with the type of META information they use:

	10	prompt, human text
	11	prmopt, human text
	20	MIME type
	30	URI
	31	URI
	40	error message, human text
	41	error message, human text
	42	error message, human text
	43	error message, human text
	44	SECONDS
	50	error message, human text
	51	error message, human text
	52	error message, human text
	53	error message, human text
	59	error message, human text
	60	error message, numan text
	61	error message, human text
	62	error message, human text

  The META types for the ranges 40-62 are a formality and can be safely
ignored (I'm talking about the human text portion, not the actual status
code) except for 44 which contains machine usable data.  My own server just
spits out a generic text entry for each error code (the specific error is
logged on my end---there's no need for me to send such info to the client).

  It's really the META data for response codes 10 and 11 that need to be
displayed directly to the user.  How to deal with languages here is
difficult.

  -spc

From petite.abeille at gmail.com  Sun Dec 27 23:04:33 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 00:04:33 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <20201227225713.GJ3625@brevard.conman.org>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <20201227225713.GJ3625@brevard.conman.org>
Message-ID: <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>



> On Dec 27, 2020, at 23:57, Sean Conner <sean at conman.org> wrote:
> 
>  It's really the META data for response codes 10 and 11 that need to be
> displayed directly to the user.  How to deal with languages here is
> difficult.

Could we prefix META with a language tag and call it a day?

10 EN Indica or Sativa? ???

From sean at conman.org  Sun Dec 27 23:12:19 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 27 Dec 2020 18:12:19 -0500
Subject: [spec] Adapting the HTTP Common Logging Format for use by Gemini
 servers
In-Reply-To: <C83U5AESUL6S.15B9IC0LL5IFI@stilgar>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
 <C83U5AESUL6S.15B9IC0LL5IFI@stilgar>
Message-ID: <20201227231219.GK3625@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> 
> For the record, I don't like that the Apache format uses spaces as a
> field separator when spaces also occur inside the date.  Molly Brown's
> log format uses tabs as separators, so it works very nicely with the
> standard `cut` utility.  I use `cut`, `grep`, `sort`, `uniq` and `wc -l`
> in short pipelines to run queries on my logs, and really enjoy being
> able to do so.

  My own logging format is:

	remote=XXX.XXX.XXX.XXX status=20 request="gemini://gemini.conman.org/boston/2001/11/13.1" bytes=1540 subject="" issuer=""

(I've redacted the IP address)

  The final two fields record information about the client certificate to
help debug issues with my server.  Here's an example:

	remote=XXX.XXX.XXX.XXX status=20 request="gemini://gemini.conman.org/private/" bytes=333 subject="/CN=default" issuer="/CN=default"

  I did not change the subject or issuer.  It's been interesting to see
what's being sent in client certificates.

  -spc

From solderpunk at posteo.net  Sun Dec 27 22:56:33 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 23:56:33 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <CAD2gp_Srftvp9Oq5YWjCTLLhUiUGZkNkV1ZxaJt6iYNm+bOXXg@mail.gmail.com>
Message-ID: <C83XTECI6BVB.1KF3OQHUD5XQW@stilgar>

On Sun Dec 27, 2020 at 11:20 PM CET, John Cowan wrote:

> I'd say it has the fewest possible such ties, less than any other
> standards
> organization except the ISO (whose members are countries). While it's
> true
> that most IETF participants (= members) are there as part of their paid
> employment, the IETF makes it very clear that nobody speaks for anyone
> or
> anything except themselves.

This is very encouraging, thank you!

> "The Tao of IETF" spells this out in great
> detail.

For anybody else curious: https://www.ietf.org/about/participate/tao/

Cheers,
Solderpunk


From solderpunk at posteo.net  Sun Dec 27 22:58:24 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Sun, 27 Dec 2020 23:58:24 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <eee2f372-5713-84e3-bb93-a94a4e1d29d3@qwertqwefsday.eu>
Message-ID: <C83XUTAXCDXP.AS2H9UKMG2LG@stilgar>

On Sun Dec 27, 2020 at 6:54 PM CET, Johann Galle wrote:

> As you have now mentioned these two issues, there was a mail with these
> two and
> another issue[1], namely if lone LFs (or lone CRs or other line breaking
> code
> points for that matter) are allowed inside META.
>
> [1] https://lists.orbitalfox.eu/archives/gemini/2020/003276.html

Hmm.  Currently this is perfectly legal.  I agree that it's not unlikely
there will be hastily written clients which don't handle it correctly
(although it could easily be included in Sean's torture test suite), but
I'm not sure that's a reason in and of itself to forbid it.  Can anybody
think of any any strong arguments in either direction?

Cheers,
Solderpunk


From sean at conman.org  Sun Dec 27 23:13:55 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 27 Dec 2020 18:13:55 -0500
Subject: IETF policy on encodings and languages
In-Reply-To: <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <20201227225713.GJ3625@brevard.conman.org>
 <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
Message-ID: <20201227231354.GL3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Dec 27, 2020, at 23:57, Sean Conner <sean at conman.org> wrote:
> > 
> >  It's really the META data for response codes 10 and 11 that need to be
> > displayed directly to the user.  How to deal with languages here is
> > difficult.
> 
> Could we prefix META with a language tag and call it a day?
> 
> 10 EN Indica or Sativa? ???

  Potentially breaking change, and you see how people are reacting to the
IRI/IDN threads.

  -spc


From petite.abeille at gmail.com  Sun Dec 27 23:17:19 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 00:17:19 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <20201227231354.GL3625@brevard.conman.org>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <20201227225713.GJ3625@brevard.conman.org>
 <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
 <20201227231354.GL3625@brevard.conman.org>
Message-ID: <7132C611-59AC-4981-978F-2CC529D4CA6D@gmail.com>



> On Dec 28, 2020, at 00:13, Sean Conner <sean at conman.org> wrote:
> 
>  Potentially breaking change,

Not really. META is free form text. We could just structure it a bit by prefixing a language tag. No one gets hurt: it's just a display issue.




From sean at conman.org  Sun Dec 27 23:21:57 2020
From: sean at conman.org (Sean Conner)
Date: Sun, 27 Dec 2020 18:21:57 -0500
Subject: [spec] Oustanding issues
In-Reply-To: <C83XUTAXCDXP.AS2H9UKMG2LG@stilgar>
References: <eee2f372-5713-84e3-bb93-a94a4e1d29d3@qwertqwefsday.eu>
 <C83XUTAXCDXP.AS2H9UKMG2LG@stilgar>
Message-ID: <20201227232157.GM3625@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> On Sun Dec 27, 2020 at 6:54 PM CET, Johann Galle wrote:
> 
> > As you have now mentioned these two issues, there was a mail with these
> > two and another issue[1], namely if lone LFs (or lone CRs or other line
> > breaking code points for that matter) are allowed inside META.
> >
> > [1] https://lists.orbitalfox.eu/archives/gemini/2020/003276.html
> 
> Hmm.  Currently this is perfectly legal.  I agree that it's not unlikely
> there will be hastily written clients which don't handle it correctly
> (although it could easily be included in Sean's torture test suite), but
> I'm not sure that's a reason in and of itself to forbid it.  Can anybody
> think of any any strong arguments in either direction?

  Okay, this is about:

	10 Is\nThis\nValid?\r\n

  While this is valid per the spec, I would recommend against embedded
control codes in the META response.  Arbitrary control codes can do some
pretty nasty things [1], and this can potentially mess up a client's
display.  Clients (in my opinion) should strip out such sequences, if only
because this is trying to influence how the client display text.

  -spc

[1]	Redefine the keyboard, issue commands to the operating system,
	application or device for instance.  I don't know of any current
	terminal software that support the commands, but I do know of at
	least one operating system where you can redefined the keyboard via
	control codes, and it's a very popular operating system.  Like,
	*the* most popular operating system.

From petite.abeille at gmail.com  Sun Dec 27 23:27:15 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 00:27:15 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <20201227232157.GM3625@brevard.conman.org>
References: <eee2f372-5713-84e3-bb93-a94a4e1d29d3@qwertqwefsday.eu>
 <C83XUTAXCDXP.AS2H9UKMG2LG@stilgar>
 <20201227232157.GM3625@brevard.conman.org>
Message-ID: <7EB11770-C999-4296-9B7D-9778D3C4C848@gmail.com>



> On Dec 28, 2020, at 00:21, Sean Conner <sean at conman.org> wrote:
> 
> Clients (in my opinion) should strip out such sequences, if only
> because this is trying to influence how the client display text.

Agree. Actually, client MUST sanitize all input, irrespectively of origin. Not doing so would be highly irresponsible.

This would be easier if META would not legally contain any control characters to start with.



From petite.abeille at gmail.com  Sun Dec 27 23:52:03 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 00:52:03 +0100
Subject: [spec] [rfc] SEDR 300 VOLUME I
In-Reply-To: <CAD2gp_Srftvp9Oq5YWjCTLLhUiUGZkNkV1ZxaJt6iYNm+bOXXg@mail.gmail.com>
References: <CAD2gp_TmyxdXspF3eQQ98qp2Y=HPha5mVVsJXU7ie4dD-qGT5Q@mail.gmail.com>
 <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <CAD2gp_Srftvp9Oq5YWjCTLLhUiUGZkNkV1ZxaJt6iYNm+bOXXg@mail.gmail.com>
Message-ID: <21A0B789-BD57-44A1-BAA6-C77F17FC5122@gmail.com>



> On Dec 27, 2020, at 23:20, John Cowan <cowan at ccil.org> wrote:
> 
> "The Tao of IETF" spells this out in great detail.

# wc rfc4677.txt
    2946   18541  127593 rfc4677.txt

?I didn't have time to write a short letter, so I wrote a long one instead.?
-- Mark Twain, allegedly

https://quoteinvestigator.com/2012/04/28/shorter-letter/



From petite.abeille at gmail.com  Mon Dec 28 01:14:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 02:14:31 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <20201227225713.GJ3625@brevard.conman.org>
 <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
Message-ID: <B267A335-60D8-464C-97A9-EE19F84556C0@gmail.com>



> On Dec 28, 2020, at 00:04, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Could we prefix META with a language tag and call it a day?

Alternative/additionally could we use the X.509 certificate structure to shoehorn such information? There are a lot of free form text in there...

Both in term of language negotiation: META matches the client certificate, if any. And tagging: the server certificate advertise the META language.

A bit of a side-channel, but why not. Perhaps overdoing it though.


From cowan at ccil.org  Mon Dec 28 02:04:07 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 21:04:07 -0500
Subject: IETF policy on encodings and languages
In-Reply-To: <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <20201227225713.GJ3625@brevard.conman.org>
 <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
Message-ID: <CAD2gp_R9ELG76QVDvD25E-F+oCEHmCjPP5Nph3g6J+5b-jynew@mail.gmail.com>

On Sun, Dec 27, 2020 at 6:04 PM Petite Abeille <petite.abeille at gmail.com>
wrote:

Could we prefix META with a language tag and call it a day?
>
> 10 EN Indica or Sativa? ???


I think that's the wrong way around.  The server doesn't normally have to
tell the client what language it's using (though there are obvious bad
cases like "Chat?")  The problem is that the client can't tell the server
what language the user would like to be prompted in.

Now that I think about it, though, that *can* be encoded in the URL readily
enough, though not in a universal way If a text/gemini file is in Greek,
the textual part of a link line will also normally be Greek, in which case
the URL should have "gr" in it someplace (assuming the server can handle
it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/d9f01395/attachment.htm>

From cowan at ccil.org  Mon Dec 28 03:25:28 2020
From: cowan at ccil.org (John Cowan)
Date: Sun, 27 Dec 2020 22:25:28 -0500
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <C82S1SRJ1KCC.FMHALL9DFJKL@stilgar>
References: <CAD2gp_Sf7TiN3cP941pKybu_67hO4hNLm5mgyc-kcTEQNTUKuQ@mail.gmail.com>
 <C82S1SRJ1KCC.FMHALL9DFJKL@stilgar>
Message-ID: <CAD2gp_R5diZ793SoCxDgHUZEgSuS64ML-Y2kH1yYEFhCmuTbSQ@mail.gmail.com>

On Sat, Dec 26, 2020 at 10:18 AM Solderpunk <solderpunk at posteo.net> wrote:


> > 2) If the client gets a redirect containing a fragment, the client MUST
> > apply this fragment when the redirected resource is retrieved, ignoring
> > any
> > original fragment.
>

I haven't got any idea why HTTP/1.1 prescribes this behavior either.  Your
idea of redirecting a whole page to part of another page is probably the
best explanation, but I'll do more research on it.

> 3) If the original URL has a fragment and the redirect doesn't, the
> > client
> > MUST apply the original fragment when the redirected resource is
> > retrieved.
>

This part I do understand.  Since the meaning of a fragment depends on the
media type and not the rest of the URL, then if a server is redirecting a
request to the document's new home, the client should carry over the
fragment id from the original URL.  In this case the fragment id doesn't
participate in the protocol at all.

This rule should exist even if text/gemini doesn't have a fragment
definition, because Gemini protocol can host any media type including HTML.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Fundamental thinking is ha-ard.  Let's go ideology-shopping.
                        --Philosopher Barbie




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
LEAR: Dost thou call me fool, boy?
FOOL: All thy other titles thou hast given away:
That thou wast born with.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/807d764c/attachment-0001.htm>

From dctrud at randomroad.net  Mon Dec 28 04:29:35 2020
From: dctrud at randomroad.net (David Trudgian)
Date: Sun, 27 Dec 2020 22:29:35 -0600
Subject: [users] Manually curated directory of capsules?
In-Reply-To: <a4434227-9c2c-4d97-8b5e-f79408d47300@www.fastmail.com>
References: <31ae1eec-01cd-4675-8c12-c3f4b1781350@www.fastmail.com>
 <FA1101E4-1ABE-4BE3-9112-64DDF7942C7B@gmail.com>
 <a4434227-9c2c-4d97-8b5e-f79408d47300@www.fastmail.com>
Message-ID: <04e2d98d-eae4-469f-ae35-dedf11b62070@www.fastmail.com>

Hi all,

I unexpectedly managed to sit down this evening with some snacks, a beverage, and enough time to do an initial rough pass on my gemini directory idea, and it is now up at:

gemini://directory.randomroad.net

I think there are likely to be enough links there now that it's potentially a useful resource for people who want to start exploring the Gemini space.

This was really a mad grab of things all over the Gemini space this evening, so there's no nice ordering of links and descriptions for the links are very rough. Please excuse typos. I'll come back around to improve the pages over time. The categories aren't really filled out either, e.g. to link from topics such as 'Linux' or 'Programming' to the many appropriate gemlogs. I'll try and find time to do that too.

Source is at https://git.sr.ht/~dctrud/gemini-directory

Drop me an email if you want to suggest I link something, or patches if you are really keen to help! If you want to grab the lists and approach this all in a different way completely, then go for it!

Cheers,

dctrud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/265e0eba/attachment.htm>

From etienne at depar.is  Mon Dec 28 08:02:52 2020
From: etienne at depar.is (=?utf-8?Q?=C3=89tienne?= Deparis)
Date: Mon, 28 Dec 2020 09:02:52 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_R9ELG76QVDvD25E-F+oCEHmCjPP5Nph3g6J+5b-jynew@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <20201227225713.GJ3625@brevard.conman.org>
 <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
 <CAD2gp_R9ELG76QVDvD25E-F+oCEHmCjPP5Nph3g6J+5b-jynew@mail.gmail.com>
Message-ID: <87y2hi8ij7.fsf@depar.is>


lun. 28 d?c. 2020 ? 03:04, cowan at ccil.org a ?crit?:

> On Sun, Dec 27, 2020 at 6:04 PM Petite Abeille <petite.abeille at gmail.com>
> wrote:
>
> Now that I think about it, though, that *can* be encoded in the URL readily
> enough, though not in a universal way If a text/gemini file is in Greek,
> the textual part of a link line will also normally be Greek, in which case
> the URL should have "gr" in it someplace (assuming the server can handle
> it).

I have a similar thought: I think we should somehow avoid too generic
input. I mean, when the user is prompted by an input, it?s normally
after having click on some link. Thus maybe we should think
differently. For an internalized website, it?s easy to imagine different
section, each one for different language. And thus each of these pages
will be on a different specific language, maybe reflected in their
URL. Then, it?s up to the CGIs running the site to be able, for a
similar function, to serve an input request with the correct language,
following the page where the user was when they click (again, obviously
because of some difference in the URL).

Said otherwise, we should maybe avoid to think too much on a specific
problem, and think it again as part of a much broader situation, with
easier solutions around the corner.

--
?tienne Deparis

gemini://alltext.umaneti.net/
xmpp: etienne at depar.is

From petite.abeille at gmail.com  Mon Dec 28 08:36:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 09:36:48 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_R9ELG76QVDvD25E-F+oCEHmCjPP5Nph3g6J+5b-jynew@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <20201227225713.GJ3625@brevard.conman.org>
 <D5F235C0-C175-42CF-B0D2-D5ED7898009E@gmail.com>
 <CAD2gp_R9ELG76QVDvD25E-F+oCEHmCjPP5Nph3g6J+5b-jynew@mail.gmail.com>
Message-ID: <3DB2A7BD-56CF-4982-A678-D79790ECE9F7@gmail.com>



> On Dec 28, 2020, at 03:04, John Cowan <cowan at ccil.org> wrote:
> 
> I think that's the wrong way around. 

Oh, then I misunderstood the problematic. I thought we had to systematically tag any end-user oriented text. My bad. Apologies.

From nothien at uber.space  Mon Dec 28 09:12:30 2020
From: nothien at uber.space (Arav K.)
Date: Mon, 28 Dec 2020 10:12:30 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
Message-ID: <20201228091230.nomtkdkolsdckksi@gux>

On Sun, Dec 27, 2020 at 03:41:14PM -0500, John Cowan wrote:
> And if you request gemini://example.com/la/non-exsistens.gmi and there
> is no support for Latin error messages, as there probably is not?
> Then what language should be used?  With the exception of 1x
> responses, human-readable <META> reflects error situations, where by
> definition the server doesn't know what the user can or cannot
> understand.

If the server has a Latin section, it is expected to have a complete
Latin interface.  And the language that the user is expecting is
generally encoded into the URL itself, as others have mentioned: the
server knows that the /la/ section is requested, so it can use Latin
error messages.

> I have no idea why you would want to disallow that.  Changes to the
> query string *are* changes to the URL, so that a particular language
> could be equally well indicated using the domain, the path, or the
> query, depending on the server's conventions.

Because we don't want the query string to be used as it is in HTML, i.e.
for arbitrary parameters.  Using ?lang=<lang> is setting an arguably
dangerous precedent.
 
> That's ideal, but it's a big burden on the client, which has to use
> something as general as Google Translate to convert the Russian error
> message being returned by the server to the Welsh expected by the
> user.

You're right, clients can't do translation.  But the idea is that if you
came across a site that only had <insert language you don't understand>,
and you really wanted to see it, you would translate it manually.
Similarly, if you use the <language> interface / section of a site, it's
your responsibility (not the server's) to translate it.  If the site
offers a language interface / section that you do understand, use that.
Otherwise, you'll have to translate.

> Not really: again, we are talking about the language of error messages.

You're right, never mind.

> Another point is that people often google for the meaning of error
> messages, and that's made easier if they always look the same, or at
> least some part of them always looks the same.

That's the whole point of the status code.  The user's client can also
present a generic description of the status code (in the user's language
of choice) in addition to the error message from the META line.  The
user can reasonably expect that the error messages are in the language
of the interface / section specified in the URL, e.g. requesting
gemini://example.com/la/~foo could return 51 "non est usor".  If the
user doesn't understand Latin and has still for some reason requested
the Latin interface URL, they can still get a good idea of what's going
on thanks to the code 51, which their client can/should explain as
"Permanent Failure - Not Found".

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/53b76d84/attachment.sig>

From solderpunk at posteo.net  Mon Dec 28 09:59:33 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 28 Dec 2020 10:59:33 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <CAD2gp_R5diZ793SoCxDgHUZEgSuS64ML-Y2kH1yYEFhCmuTbSQ@mail.gmail.com>
Message-ID: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>

Thanks for weighing in on this thread.  Of all the outstanding issues,
this is actually the one where I have the least clear idea of what we
should do.

On Mon Dec 28, 2020 at 4:25 AM CET, John Cowan wrote:

> > 3) If the original URL has a fragment and the redirect doesn't, the
> > > client
> > > MUST apply the original fragment when the redirected resource is
> > > retrieved.
> >
>
> This part I do understand. Since the meaning of a fragment depends on
> the
> media type and not the rest of the URL, then if a server is redirecting
> a
> request to the document's new home, the client should carry over the
> fragment id from the original URL. In this case the fragment id doesn't
> participate in the protocol at all.
>
> This rule should exist even if text/gemini doesn't have a fragment
> definition, because Gemini protocol can host any media type including
> HTML.

Okay, so original URL fragments should be carried over to redirect URLs
if the redirect URL has no fragment (which I still suspect perhaps
should be the only valid case).

What about queries?

To some extent, the issue of a redirect URL having a query in it is
similar to a link in a text/gemini document having a query in it, which
was slightly controversial.  Not so much in the sense that people
thought it should be disallowed, but that it was widely believed clients
should handle such things very carefully and give the user a chance to
confirm or edit the query string contents.

Should redirect URLs be allowed to contain queries?

If an original URL has a query in it but the client gets back a redirect
URL without a query, should the original query be appended?

Cheers,
Solderpunk

From cage-dev at twistfold.it  Mon Dec 28 10:10:43 2020
From: cage-dev at twistfold.it (cage)
Date: Mon, 28 Dec 2020 11:10:43 +0100
Subject: [spec] adding a "magic number" for gemini files
In-Reply-To: <20201227221808.GI3625@brevard.conman.org>
References: <X+dXetNKqh2ju2ys@kurosawa.casa.net>
 <C82TSBUY1QBI.UNG3VL20MGXD@stilgar>
 <X+dcrk/JFdyccE/J@kurosawa.casa.net>
 <20201226232543.GB3625@brevard.conman.org>
 <X+h2f3Ymzh79fsHO@kurosawa.casa.net>
 <20201227221808.GI3625@brevard.conman.org>
Message-ID: <X+mvI9RIgvY30Y3C@kurosawa.casa.net>

On Sun, Dec 27, 2020 at 05:18:08PM -0500, Sean Conner wrote:

[...]

>
>   In the configuration file, the user can specify a mapping of extensions to
> MIME type, to which the default extension type that identifies a Gemini
> index file is added (which for my server is ".gemini" but that can be
> changed).
>
>   During a request, the extension is checked against this mapping.  If (for
> a non-Gemini file) this doesn't exist, only then is libmagic queried.
>
>   -spc

Crystal clear, thank you! :)
C.

From solderpunk at posteo.net  Mon Dec 28 10:10:17 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 28 Dec 2020 11:10:17 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
Message-ID: <C84C58QVWNUN.3FYTCIX9B2LUK@stilgar>

On Sun Dec 27, 2020 at 9:41 PM CET, John Cowan wrote:
> On Sun, Dec 27, 2020 at 3:06 PM Arav K. <nothien at uber.space> wrote:
>
>
> > the server can easily recognize from the URL what language is
> > expected and should provide an interface (including human-readable META
> > text) in that same language.  That would mean, for example, that the
> > entire ://fr.example.com site should use a French interface.
>
>
> And if you request gemini://example.com/la/non-exsistens.gmi and there
> is
> no support for Latin error messages, as there probably is not? Then what
> language should be used? With the exception of 1x responses,
> human-readable <META> reflects error situations, where by definition the
> server doesn't know what the user can or cannot understand.

One of the motivations for having the second digits clarifying the exact
nature of the error (besides allowing useful logging on the server side
for identifying problems, and allowing the writing of more robust bots)
was that clients could use them to provide *some* degree of localised
error message.  E.g. if a server written by an English-speaking programmer
sends back "51 Not found", a client with a Finnish language interface could
recognise the 51 status code and say to its users:

> Ei l?ytynyt!  Palvelin sanoi: "Not found"

which a non-English-reading Finn would perceive as:

> Not found!  Server said: "<mysterious foreign message>"

Which is slightly better than just:

> Server said: "<mysterious foreign message>"

And for people who read *some* English (or whatever language the server
uses for errors) but not very much, having a localised translation of the
error category first might be enough context to enable them to make
enough sense of the full error message to have some understanding of
what's going on.

Cheers,
Solderpunk

From petite.abeille at gmail.com  Mon Dec 28 10:34:08 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 11:34:08 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
References: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
Message-ID: <97F3E704-44B9-4012-9796-0CD9DC27F467@gmail.com>



> On Dec 28, 2020, at 10:59, Solderpunk <solderpunk at posteo.net> wrote:
> 
> Thanks for weighing in on this thread.  Of all the outstanding issues,
> this is actually the one where I have the least clear idea of what we
> should do.

My 2?: kill fragments altogether as they don't add much values, only headaches. Keep queries as is, including redirects. Totally legit.


From petite.abeille at gmail.com  Mon Dec 28 10:45:56 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 11:45:56 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <C84C58QVWNUN.3FYTCIX9B2LUK@stilgar>
References: <C84C58QVWNUN.3FYTCIX9B2LUK@stilgar>
Message-ID: <E820ED7A-9AEF-47FF-A0A6-0E8A589F74FD@gmail.com>



> On Dec 28, 2020, at 11:10, Solderpunk <solderpunk at posteo.net> wrote:
> 
> One of the motivations for having the second digits clarifying the exact
> nature of the error

Yes, but this doesn't help with 1x responses. They are meant to be presented to the end user, as a prompt. And they lack a language tag. This is my understanding of the crux of the issue. But perhaps I missed something.




From nothien at uber.space  Mon Dec 28 10:57:29 2020
From: nothien at uber.space (Arav K.)
Date: Mon, 28 Dec 2020 11:57:29 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <E820ED7A-9AEF-47FF-A0A6-0E8A589F74FD@gmail.com>
References: <C84C58QVWNUN.3FYTCIX9B2LUK@stilgar>
 <E820ED7A-9AEF-47FF-A0A6-0E8A589F74FD@gmail.com>
Message-ID: <20201228105729.jot6mbpxfh636cg6@gux>

On Mon, Dec 28, 2020 at 11:45:56AM +0100, Petite Abeille wrote:
> Yes, but this doesn't help with 1x responses. They are meant to be
> presented to the end user, as a prompt. And they lack a language tag.
> This is my understanding of the crux of the issue. But perhaps I
> missed something.

My point was that the client is communicating the language the server
should use in the URL itself, e.g. for gemini://fr.example.com/search
the server would send a prompt in French.  If no language is specified,
the server should assume a default language, which would often be
English.

I thought this didn't need to be mentioned, but if the server supports
the URL gemini://fr.example.com/, then it is expected to have a French
interface for it.  If it doesn't support a language, then it just
shouldn't offer it, and it then becomes the user's responsibility to
translate appropriately.

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/2d3e964f/attachment.sig>

From petite.abeille at gmail.com  Mon Dec 28 11:03:54 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 12:03:54 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <20201228105729.jot6mbpxfh636cg6@gux>
References: <C84C58QVWNUN.3FYTCIX9B2LUK@stilgar>
 <E820ED7A-9AEF-47FF-A0A6-0E8A589F74FD@gmail.com>
 <20201228105729.jot6mbpxfh636cg6@gux>
Message-ID: <69F5CC33-C238-47D9-8539-CB230EBE4986@gmail.com>



> On Dec 28, 2020, at 11:57, Arav K. <nothien at uber.space> wrote:
> 
> I thought this didn't need to be mentioned, but if the server supports
> the URL gemini://fr.example.com/, then it is expected to have a French
> interface for it.  If it doesn't support a language, then it just
> shouldn't offer it, and it then becomes the user's responsibility to
> translate appropriately.

Sounds reasonable enough to me: language tags are conveyed through the expedient of embedding them in the user generated content, i.e. the URL, by convention. And not the protocol machinery, i.e. status codes, as per the specification.

I thought that John's point of contention was the protocol machinery, as opposed to the user generated content. 


From solene at perso.pw  Mon Dec 28 11:15:52 2020
From: solene at perso.pw (Solene Rapenne)
Date: Mon, 28 Dec 2020 12:15:52 +0100
Subject: What is required to be IRI compliant?
Message-ID: <20201228121552.3c7537df@kongroo.lan>

Hello,

I am the author of a gemini daemon written in C. In
regards to the discussion about IRI, I added tests
to my project to try utf-8 or emojis queries.

Requests such as the following are working well:

- gemini://ho?t/? ?.gmi
- gemini://?//??.gmi

Honestly, I am very surprised it works, in my code
everything are simple char arrays (in C), but it does.

Are there other specifics handling required for being
IRI compliant? I'm not sure I understood exactly what
it means.

From petite.abeille at gmail.com  Mon Dec 28 11:20:55 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 12:20:55 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <20201228121552.3c7537df@kongroo.lan>
References: <20201228121552.3c7537df@kongroo.lan>
Message-ID: <9FB57996-25CE-4A3D-AB90-DEDF8D6F1478@gmail.com>



> On Dec 28, 2020, at 12:15, Solene Rapenne <solene at perso.pw> wrote:
> 
> Requests such as the following are working well:
> 
> - gemini://ho?t/? ?.gmi
> - gemini://?//??.gmi
> 
> Honestly, I am very surprised it works

Fantastic. Welcome to the future. You have done it.

And yes, the only major difference between URI and IRI is the character set allowed in the various URL parts: ASCII vs UTF8. (? resolution details, unicode normalization, and minor other annoyances).

Very well done. Full credits.

From petite.abeille at gmail.com  Mon Dec 28 11:41:24 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 12:41:24 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <9FB57996-25CE-4A3D-AB90-DEDF8D6F1478@gmail.com>
References: <20201228121552.3c7537df@kongroo.lan>
 <9FB57996-25CE-4A3D-AB90-DEDF8D6F1478@gmail.com>
Message-ID: <C588A1DF-BF92-43AF-AAA3-0DD956C0F054@gmail.com>



> On Dec 28, 2020, at 12:20, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
>> Honestly, I am very surprised it works
> 
> Fantastic. Welcome to the future. You have done it.

In case the "tone of voice" is not clear, yes, you have done it. Most earnest congratulations. 

From come at chilliet.eu  Mon Dec 28 11:45:47 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Mon, 28 Dec 2020 12:45:47 +0100
Subject: [spec] Adapting the HTTP Common Logging Format for use by Gemini
 servers
In-Reply-To: <gjw6WBiEbOwHsSZQSiQNFDFP59jsJeL-2oisXsjjgVu-Jtwyx7mOmqVvznnoQJHqYL6MCX-GWeEuKjpNT3fR-kmKWgGvHruBVbGo3qXEO64=@protonmail.com>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
 <2050148.5bT7vuFU4P@tempete>
 <gjw6WBiEbOwHsSZQSiQNFDFP59jsJeL-2oisXsjjgVu-Jtwyx7mOmqVvznnoQJHqYL6MCX-GWeEuKjpNT3fR-kmKWgGvHruBVbGo3qXEO64=@protonmail.com>
Message-ID: <6073468.yAP2ceAMqc@tempete>

Le dimanche 27 d?cembre 2020, 22:48:13 CET colecmac at protonmail.com a ?crit :
> > * I do not log the IP but its sha1 hash, because of privacy concerns
> 
> Doesn't this provide no security though? It's trivial to hash all IPv4
> addresses and compare them. Additionally, this doesn't provide any
> security to clients, because they can't guarantee this is in effect.

It?s not for clients, it?s for me. I?m not sure what I am legally allowed to do with IPs so I feel more confident not storing them.
I sha1 IPs the same whether they are v4 or v6. It may indeed be easy to do a dictonnary attack for v4 log entries, but I?m not sure what I can do about that.

C?me



From solderpunk at posteo.net  Mon Dec 28 11:41:15 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 28 Dec 2020 12:41:15 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <20201228121552.3c7537df@kongroo.lan>
Message-ID: <C84E2W2G35UN.8OTSFA5SFQT9@stilgar>

On Mon Dec 28, 2020 at 12:15 PM CET, Solene Rapenne wrote:

> Requests such as the following are working well:
>
> - gemini://ho?t/? ?.gmi
> - gemini://?//??.gmi
>
> Honestly, I am very surprised it works

Me too!  Are you using a third party library to parse URIs/IRIs, or did
you implement it yourself?  People have acted like there is no easy
availability of reliable libraries for this kind of thing in C.  If that
is false, it would be very good to know.

To be fair, for a server, in addition to being able to parse the request
IRI, there is also possibly the need to normalise it, e.g. the
server's idea of its domain name might involve two separate characters
(a basic vowel plus an accent symbol, say) while the request's version
uses a single combined character (or the other way around).  We might
spec that one form is required, but robustness would require checking.
It might be that *this* is the really hard requirement, rather than
simply parsing.

(servers seem to get off lighter than clients, as they don't e.g. need
to do DNS lookups or resolve relative URLs - which, by the way, seems to
be the correct terminology, not "absolutise" as I've confused people
with earlier)

Cheers,
Solderpunk

is something people have acteThe impression I've received from other people here is that
parsing an IRI in C is prohibitively difficult., in my code
> everything are simple char arrays (in C), but it does.
>
> Are there other specifics handling required for being
> IRI compliant? I'm not sure I understood exactly what
> it means.


From come at chilliet.eu  Mon Dec 28 11:48:28 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Mon, 28 Dec 2020 12:48:28 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
Message-ID: <6238221.SMLxVx6c14@tempete>

Le dimanche 27 d?cembre 2020, 20:40:42 CET John Cowan a ?crit :
> b) What language is used for those META parts, since the server does not
> know what languages are acceptable to the user?  TL;dr answer: start with
> English, add other languages as necessarily or useful.

I agree with what has been said by some, the text in META should be in the same language as the rest of what the server is hosting.
If it is a multi-language capsule, most likely there is an indication in the address to convey language choice. Or in the session if using client certs or whatever to keep a session open.
In all cases, the server knows in which language the pages are and should use the same one for META.



From petite.abeille at gmail.com  Mon Dec 28 11:55:06 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 12:55:06 +0100
Subject: [spec] Adapting the HTTP Common Logging Format for use by Gemini
 servers
In-Reply-To: <6073468.yAP2ceAMqc@tempete>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
 <2050148.5bT7vuFU4P@tempete>
 <gjw6WBiEbOwHsSZQSiQNFDFP59jsJeL-2oisXsjjgVu-Jtwyx7mOmqVvznnoQJHqYL6MCX-GWeEuKjpNT3fR-kmKWgGvHruBVbGo3qXEO64=@protonmail.com>
 <6073468.yAP2ceAMqc@tempete>
Message-ID: <D5A27084-E2AA-409E-B574-E27874C4B398@gmail.com>



> On Dec 28, 2020, at 12:45, C?me Chilliet <come at chilliet.eu> wrote:
> 
> I sha1 IPs the same whether they are v4 or v6. It may indeed be easy to do a dictonnary attack for v4 log entries, but I?m not sure what I can do about that.

See https://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables

From solene at perso.pw  Mon Dec 28 11:59:12 2020
From: solene at perso.pw (Solene Rapenne)
Date: Mon, 28 Dec 2020 12:59:12 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <C84E2W2G35UN.8OTSFA5SFQT9@stilgar>
References: <20201228121552.3c7537df@kongroo.lan>
 <C84E2W2G35UN.8OTSFA5SFQT9@stilgar>
Message-ID: <20201228125912.6c6fee79@kongroo.lan>

On Mon, 28 Dec 2020 12:41:15 +0100
"Solderpunk" <solderpunk at posteo.net>:

> On Mon Dec 28, 2020 at 12:15 PM CET, Solene Rapenne wrote:
> 
> > Requests such as the following are working well:
> >
> > - gemini://ho?t/? ?.gmi
> > - gemini://?//??.gmi
> >
> > Honestly, I am very surprised it works  
> 
> Me too!  Are you using a third party library to parse URIs/IRIs, or did
> you implement it yourself?  People have acted like there is no easy
> availability of reliable libraries for this kind of thing in C.  If that
> is false, it would be very good to know.
> 
> To be fair, for a server, in addition to being able to parse the request
> IRI, there is also possibly the need to normalise it, e.g. the
> server's idea of its domain name might involve two separate characters
> (a basic vowel plus an accent symbol, say) while the request's version
> uses a single combined character (or the other way around).  We might
> spec that one form is required, but robustness would require checking.
> It might be that *this* is the really hard requirement, rather than
> simply parsing.
> 
> (servers seem to get off lighter than clients, as they don't e.g. need
> to do DNS lookups or resolve relative URLs - which, by the way, seems to
> be the correct terminology, not "absolutise" as I've confused people
> with earlier)
> 
> Cheers,
> Solderpunk
> 
> is something people have acteThe impression I've received from other people here is that
> parsing an IRI in C is prohibitively difficult., in my code
> > everything are simple char arrays (in C), but it does.
> >
> > Are there other specifics handling required for being
> > IRI compliant? I'm not sure I understood exactly what
> > it means.  
> 

the code doesn't check anything, it only serves what is requested [1].

I don't understand what you mean by normalizing the request.
For the hostname, I see no reason to write "?crire.hostname" as
"e'crire.hostname" if it what you mean.

What I see as an issue would be people using puny code if we go
using IRI. That would mean the server will have to check the puny
code of the hostname to check to a request using the punycode.

A library will certainly be required for that.


[1]:
```
/*
 * look for the first / after the hostname
 * in order to split hostname and uri
 */
pos = strchr(request, '/');

if (pos != NULL) {
	/* if there is a / found */
	/* separate hostname and uri */
	estrlcpy(file, pos, strlen(pos)+1);
	/* just keep hostname in request */
	pos[0] = '\0';

	/*
	 * use a default file if no file are requested this
	 * can happen in two cases gemini://hostname/
	 * gemini://hostname/directory/
	 */
	if (strlen(file) == 0)
		estrlcpy(file, "/index.gmi", 11);
	if (file[strlen(file) - 1] == '/')
		estrlcat(file, "index.gmi", sizeof(file));
} else {
	/*
	 * there are no slash / in the request
	 */
	estrlcpy(file, "/index.gmi", 11);
}
estrlcpy(hostname, request, sizeof(hostname));
```

From petite.abeille at gmail.com  Mon Dec 28 12:04:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 13:04:31 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <20201228125912.6c6fee79@kongroo.lan>
References: <20201228121552.3c7537df@kongroo.lan>
 <C84E2W2G35UN.8OTSFA5SFQT9@stilgar> <20201228125912.6c6fee79@kongroo.lan>
Message-ID: <B84F9BEC-CCCF-434B-8D8E-9E10E109CFD8@gmail.com>



> On Dec 28, 2020, at 12:59, Solene Rapenne <solene at perso.pw> wrote:
> 
> For the hostname, I see no reason to write "?crire.hostname" as
> "e'crire.hostname" if it what you mean.

The crux of the issue, with Unicode -and UTF8 by extension- is that the same character, say, the acute accent "?",  can be represented in different ways, encoding wise, while visually identical. 

This is what people means by "normalization": everyone needs to agree how to encode "?" the same way, so everyone understand what "?" is.

This is a solved problem. But it introduces additional work.

From will at worrbase.com  Mon Dec 28 12:12:57 2020
From: will at worrbase.com (William Orr)
Date: Mon, 28 Dec 2020 12:12:57 +0000 (UTC)
Subject: What is required to be IRI compliant?
In-Reply-To: <20201228125912.6c6fee79@kongroo.lan>
References: <20201228121552.3c7537df@kongroo.lan>
 <C84E2W2G35UN.8OTSFA5SFQT9@stilgar> <20201228125912.6c6fee79@kongroo.lan>
Message-ID: <1b2750ca-7781-4c9e-9f98-12a9cf22d43c@worrbase.com>

Hey,

Normalization is not so much turning e'crire to ?crire, but handling the multiple representations of the word '?crire'.

For example, the first character can be represented by multiple sets of unicode codepoints.


? can either be U+00E9 or it can also be the sequence of U+0065 U+0301 (e plus what's called a combining character). Both should render visibly as ?, and the input method is free to produce whichever form.

Normalization is the process of looking for all of these synonyms for characters, and standardizing them to the same set of codepoints. If you don't normalize, you could have a case where one user gets the intended host for ?crire.hostname and another user gets an NXDOMAIN, all depending on the sequence of bytes their input method produced.

Server-side, you probably only need to normalize the request path after doing percent decoding, since you can't always trust that a client normalized the request path correctly.

To do normalization in C, the best lib that I know of is libicu. http://site.icu-project.org/

There are different types of normalization, but imo the only kind that server authors should care about is NFC, since it accomplishes the goal of standardizing the set of bytes you're looking up, while also keeping the characters composed in a way that makes sense to display (in like logs and stuff). Here's a technical report on all of the different normalization forms for more reading: https://www.unicode.org/reports/tr15/

Hope this helps!

28 dic. 2020 12:59:33 Solene Rapenne <solene at perso.pw>:

> On Mon, 28 Dec 2020 12:41:15 +0100
> "Solderpunk" <solderpunk at posteo.net>:
> 
>> On Mon Dec 28, 2020 at 12:15 PM CET, Solene Rapenne wrote:
>> 
>>> Requests such as the following are working well:
>>> 
>>> - gemini://ho?t/? ?.gmi
>>> - gemini://?//??.gmi
>>> 
>>> Honestly, I am very surprised it works?
>> 
>> Me too!? Are you using a third party library to parse URIs/IRIs, or did
>> you implement it yourself?? People have acted like there is no easy
>> availability of reliable libraries for this kind of thing in C.? If that
>> is false, it would be very good to know.
>> 
>> To be fair, for a server, in addition to being able to parse the request
>> IRI, there is also possibly the need to normalise it, e.g. the
>> server's idea of its domain name might involve two separate characters
>> (a basic vowel plus an accent symbol, say) while the request's version
>> uses a single combined character (or the other way around).? We might
>> spec that one form is required, but robustness would require checking.
>> It might be that *this* is the really hard requirement, rather than
>> simply parsing.
>> 
>> (servers seem to get off lighter than clients, as they don't e.g. need
>> to do DNS lookups or resolve relative URLs - which, by the way, seems to
>> be the correct terminology, not "absolutise" as I've confused people
>> with earlier)
>> 
>> Cheers,
>> Solderpunk
>> 
>> is something people have acteThe impression I've received from other people here is that
>> parsing an IRI in C is prohibitively difficult., in my code
>>> everything are simple char arrays (in C), but it does.
>>> 
>>> Are there other specifics handling required for being
>>> IRI compliant? I'm not sure I understood exactly what
>>> it means.?
>> 
> 
> the code doesn't check anything, it only serves what is requested [1].
> 
> I don't understand what you mean by normalizing the request.
> For the hostname, I see no reason to write "?crire.hostname" as
> "e'crire.hostname" if it what you mean.
> 
> What I see as an issue would be people using puny code if we go
> using IRI. That would mean the server will have to check the puny
> code of the hostname to check to a request using the punycode.
> 
> A library will certainly be required for that.
> 
> 
> [1]:
> ```
> /*
> * look for the first / after the hostname
> * in order to split hostname and uri
> */
> pos = strchr(request, '/');
> 
> if (pos != NULL) {
> ? /* if there is a / found */
> ? /* separate hostname and uri */
> ? estrlcpy(file, pos, strlen(pos)+1);
> ? /* just keep hostname in request */
> ? pos[0] = '\0';
> 
> ? /*
> ?? * use a default file if no file are requested this
> ?? * can happen in two cases gemini://hostname/
> ?? * gemini://hostname/directory/
> ?? */
> ? if (strlen(file) == 0)
> ??? estrlcpy(file, "/index.gmi", 11);
> ? if (file[strlen(file) - 1] == '/')
> ??? estrlcat(file, "index.gmi", sizeof(file));
> } else {
> ? /*
> ?? * there are no slash / in the request
> ?? */
> ? estrlcpy(file, "/index.gmi", 11);
> }
> estrlcpy(hostname, request, sizeof(hostname));
> ```

From petite.abeille at gmail.com  Mon Dec 28 12:22:27 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 13:22:27 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <B84F9BEC-CCCF-434B-8D8E-9E10E109CFD8@gmail.com>
References: <20201228121552.3c7537df@kongroo.lan>
 <C84E2W2G35UN.8OTSFA5SFQT9@stilgar> <20201228125912.6c6fee79@kongroo.lan>
 <B84F9BEC-CCCF-434B-8D8E-9E10E109CFD8@gmail.com>
Message-ID: <9F4153AD-9711-4A30-B4CE-04CC50DC51D4@gmail.com>



> On Dec 28, 2020, at 13:04, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> This is what people means by "normalization": everyone needs to agree how to encode "?" the same way, so everyone understand what "?" is.

See https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization for an introduction.

This is not an abstract problem, as it can lead to unwelcome outcomes, see #Errors_due_to_normalization_differences . Or simply misunderstands.

Furthermore, if you really want to go all the way in, you need to validate the UTF8 byte sequences as well.

In the same way as there are different ways to represent the very same character in Unicode, there are various ways to encode that character in Unicode Transformation Format (UTF). Some of them malicious.

See https://en.wikipedia.org/wiki/UTF-8#Invalid_sequences_and_error_handling for an introduction.

In your case, considering your stack, you can choose to ignore such potential issues, or delegate them to some external libraries.

Your choice, ultimately.

In any case, well done to get it going with the minimal amount of work. This is the way. ??






From linde.philip at gmail.com  Mon Dec 28 12:24:56 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 28 Dec 2020 13:24:56 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <20201228125912.6c6fee79@kongroo.lan>
References: <20201228121552.3c7537df@kongroo.lan>
 <C84E2W2G35UN.8OTSFA5SFQT9@stilgar>
 <20201228125912.6c6fee79@kongroo.lan>
Message-ID: <20201228132456.a1865160cae2dca0b0dd175b@gmail.com>

On Mon, 28 Dec 2020 12:59:12 +0100
Solene Rapenne <solene at perso.pw> wrote:

> I don't understand what you mean by normalizing the request.
> For the hostname, I see no reason to write "?crire.hostname" as
> "e'crire.hostname" if it what you mean.

There are sometimes multiple ways to represent the same characters in
Unicode. For example "?" in the composed form is just U+00E9, and in
the decomposed form it's U+0065, U+0301. These are visually
indistinguishable and take the same meaning in Unicode, but encoded as
UTF-8 or UTF-32 a byte-by-byte or even code point-by-code point
comparison will not indicate that they are.

Therefore the Unicode consortium defines a process called normalization
to either "fully compose" characters (turn sequences like U+0065,
U+0301 into their composed form, U+00E9) or "fully decompose" (which
works the other way around). To support this you'd need a database that
the Unicode consortium distributes.

If you are using GLib (or are ready to use GLib) it has functions for
this.

> What I see as an issue would be people using puny code if we go
> using IRI. That would mean the server will have to check the puny
> code of the hostname to check to a request using the punycode.
> 
> A library will certainly be required for that.

Again, if you're willing to use GLib, some functions for this exist in
glib/gi18n.h

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/43a832d2/attachment.sig>

From nothien at uber.space  Mon Dec 28 12:32:42 2020
From: nothien at uber.space (Arav K.)
Date: Mon, 28 Dec 2020 13:32:42 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
References: <CAD2gp_R5diZ793SoCxDgHUZEgSuS64ML-Y2kH1yYEFhCmuTbSQ@mail.gmail.com>
 <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
Message-ID: <20201228123242.aac45s5sawfn57sq@gux>

On Mon, Dec 28, 2020 at 10:59:33AM +0100, Solderpunk wrote:
> Should redirect URLs be allowed to contain queries?
> 
> If an original URL has a query in it but the client gets back a
> redirect URL without a query, should the original query be appended?

Only the server has the necessary information to determine whether the
redirect URL should have the query from the original URL, if any, or
not.  It could be that the query string determined the redirect, in
which case the redirect would probably not have the (same) query.  If,
however, the redirect is the same regardless of the query, then perhaps
the server needs to append the query to the redirect.  It should be up
to the server.  The client should use what the server gives it verbatim
(fragments are a separate issue which may change this).

~aravk | ~nothien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/a199cc05/attachment.sig>

From come at chilliet.eu  Mon Dec 28 12:40:30 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Mon, 28 Dec 2020 13:40:30 +0100
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
References: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
Message-ID: <2465438.YfcuP8kr0n@tempete>

Le lundi 28 d?cembre 2020, 10:59:33 CET Solderpunk a ?crit :
> Okay, so original URL fragments should be carried over to redirect URLs
> if the redirect URL has no fragment (which I still suspect perhaps
> should be the only valid case).

This is my opinion as well, the fragment should be carried over if the redirect URL has no fragment.

I also think that it should be allowed to redirect to a URL with a fragment, the obvious example is if several documents are merged, their previous URL can link to the specific part of the merged document.

Someone used HTML served over gemini as an example, I think it is a good thinking exercise to be able to analyse fragment handling in gemini protocol separately from fragment meaning in text/gemini documents.
Think about a client browsing HTML through gemini protocol, and needing to be able to link and redirect to anchors.

Fragments may be forbidden in the gemini request, since they should never be sent to the server.

> What about queries?
> 
> To some extent, the issue of a redirect URL having a query in it is
> similar to a link in a text/gemini document having a query in it, which
> was slightly controversial.  Not so much in the sense that people
> thought it should be disallowed, but that it was widely believed clients
> should handle such things very carefully and give the user a chance to
> confirm or edit the query string contents.
> 
> Should redirect URLs be allowed to contain queries?
> 
> If an original URL has a query in it but the client gets back a redirect
> URL without a query, should the original query be appended?

I think queries should be handled exactly like path segment, and not be carried over to a redirection without query, and be allowed in the redirection.

If I was redoing the tictactoe today, I would use a query string instead of a path segment to carry the game state, making it clearer to people and especially crawlers (GUS and lupa both played every possible tictactoe game while crawling) that it is the same page with a different input.

See GUS backlink pages for instance, it is useful for me to be able to link to gemini://gus.guru/backlinks?tictactoe.lanterne.chilliet.eu
And it may make sense for me to redirect there from my server if I had a local responses link, and I decided to switch to using GUS backlinks instead.

C?me



From linde.philip at gmail.com  Mon Dec 28 12:44:06 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 28 Dec 2020 13:44:06 +0100
Subject: [user] wikipedia coverage of Gemini
In-Reply-To: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>
References: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>
Message-ID: <20201228134406.c74c85a2f4be769448ff680c@gmail.com>

On Sun, 27 Dec 2020 16:11:00 +0000 (GMT)
Martin Keegan <martin at no.ucant.org> wrote:

> 
> Hello,
> 
> following a reference to the problems of finding out about Gemini on 
> Wikipedia, I've overhauled the page about "Gemini space", which had 
> replaced "Gemini (protocol)" and which made it difficult to find at all. 
> There are now two articles, one focused solely on the protocol (and thus 
> more eligible to be in included in generic lists of protocols and so-on).

This seems like a good change in principle. The articles still contain
large chunks of uncited claims, or claims that  and IME could be swept
up any minute now for that reason.

> Previous contributors to this mailing list highlighted the problem that 
> Wikipedia's policies militate against Gemini as it isn't trivially 
> discoverable via the sources that Wikipedia privileges. We'll see if this 
> persists as an issue; the mitigation would be to do some marketing, but 
> that's probably not something we want just yet.

It's not so much an issue in my opinion. Wikipedia has a bar of entry
in terms of notability for a reason, and it should function more as an
encyclopedia (where the content reflects popular opinion on facts) than
an everything-site that people can use to promote their projects.

If we can manipulate the process of creating a popular opinion on facts
in a benign way (by "marketing") then maybe we should go ahead, but I
think this also happens naturally as subjects gain notability: whatever
we do, Wikipedia notability should be a side effect, not an end.

Tangential funny Wikipedia story:
https://www.newyorker.com/tech/annals-of-technology/how-a-raccoon-became-an-aardvark

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/17578e79/attachment.sig>

From petite.abeille at gmail.com  Mon Dec 28 12:47:59 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 13:47:59 +0100
Subject: [user] wikipedia coverage of Gemini
In-Reply-To: <20201228134406.c74c85a2f4be769448ff680c@gmail.com>
References: <alpine.DEB.2.21.2012271604380.31140@pling.qwghlm.org>
 <20201228134406.c74c85a2f4be769448ff680c@gmail.com>
Message-ID: <CBBDF759-EFB6-46C7-A519-CD151A109C55@gmail.com>



> On Dec 28, 2020, at 13:44, Philip Linde <linde.philip at gmail.com> wrote:
> 
> Tangential funny Wikipedia story:
> https://www.newyorker.com/tech/annals-of-technology/how-a-raccoon-became-an-aardvark

?also known as the Brazilian aardvark? 

Thanks for the link :)


From petite.abeille at gmail.com  Mon Dec 28 12:59:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 13:59:04 +0100
Subject: [user] [ot] flame warriors: a full taxonomy
Message-ID: <145D252A-B9FC-4C0B-AE7F-7DA3A9C62464@gmail.com>

There seems to be a lot of hurt feelings around the mailing list... tantrum and all.

To lighten the mood, what flame warrior are you?

Acne
Admin
Agent
ALLCAPS
Android
Archivist
Atheist 
Artiste
Artful Dodger
Big Cat
Big Dog and Me-Too
Bliss Ninny 
Blowhard
Bong 
Captialista
Centurion 
Coffee Klatch
Compost 
Crybaby
Cyber Sisters
Deacon
Diplomat
Democrats 
Duelists
Eagle Scout 
Ego 
Ent 
Ennui 
Ethnix 
Evil Clown 
Ferrous Cranus 
Filibuster 
Fragile Femme 
Furious Typer

Garble
God
Godzilla 
Grammarian 
Grenade 
Grunter 
Howlers
Ideologue 
Imposter 
Innocence Abused 
Issues
Jekyl and Hyde 
Jerk 
Klaxon
Kung-Fu Master
Lamer
L'Enfant Provocateur 
Lonely Guy
Loopy 
Lurker
Nanny
Net Rat
Netiquette Nazi
Newbie
Nitpick 
Palooka 
Patois
Peacemaker
Perv 
Philosopher 
Picador 
Pinko
Pithy Phrase 
Profundus Maximus

Propeller Head 
Rat
Rebel Leader
Rebel Without a Clue
Republicans
Rottweiler Puppy 
Royals
Stealth
Stone Deaf
Strumpet 
The Swarm
Sycophant
Target 
Therapist 
Tiny Yapper 
Tireless Rebutter
Toxic Granny 
Troglodyte 
Troller 
Typhoid Mary
Weenie
Whisper
Xenophobe
Yuk Yuk

https://en.chessbase.com/post/flame-warriors-a-full-taxonomy
https://web.archive.org/web/20040612154117/http://www.winternet.com/~mikelr/flame1.html 
https://en.wikipedia.org/wiki/Flaming_(Internet)



From linde.philip at gmail.com  Mon Dec 28 13:16:27 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 28 Dec 2020 14:16:27 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
Message-ID: <20201228141627.7bebd030c7ffde63118338c6@gmail.com>

This is not fully expressed in the specification, but practically, "all"
text/gemini documents are either UTF-8 or US-ASCII encoded. Stephane
Bortzmeyer compiled the following list from his crawler:

> Only for text/gemini:
> 
> * Unspecified: 5997
> * utf-8: 4619
> * tcvn-5712: 2
> * cp437: 2
> * utf-16be: 1
> * utf-16: 1
> * windows-1252: 1
> * utf-32le: 1
> * utf-32be: 1
> * utf-16le: 1
> * ebcdicatde: 1
> 
> But wait, all the exotic charsets are at <gemini://egsam.pitr.ca/>
> which is a test site for various funny stuff. So, it is safe to say
> that not one "real" gemtext resource uses something else than UTF-8.

While it is the case that impact is minimal, I suggest that the
specification reflects the much simpler situation these statistics
indicate rather than keep itself open to the general problem of
representing text/gemini in encodings that might not even have the meta
information characters encoded in the same way, and?if IRIs are
introduced?creates the problem of how IRIs should be represented in
e.g. ISO-8859-1.

I understand the need for other document types to take other character
encodings. For example, I have a collection of old text files in IBM437
encoding. For text/gemini, we pretty much have a blank slate, though,
and I see no reason that it should extend to support arbitrary
encodings when limiting to UTF-8 creates a much simpler situation for
implementers and is already the unspoken standard.

There are display systems and platforms that fundamentally can't
display UTF-8 directly. For example, in the PC text modes I am limited
to IBM437. The problem of transcoding text/gemini should then lie with
the client authors for those platforms, not with every other client
author. ELinks for DOS will for example transcode UTF-8 (and various
other encodings) to IBM437 and use a placeholder character where no
equivalents exist.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/f3768982/attachment.sig>

From come at chilliet.eu  Mon Dec 28 13:25:29 2020
From: come at chilliet.eu (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Date: Mon, 28 Dec 2020 14:25:29 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <20201228141627.7bebd030c7ffde63118338c6@gmail.com>
References: <20201228141627.7bebd030c7ffde63118338c6@gmail.com>
Message-ID: <1912300.0KG8479sM4@tempete>

Le lundi 28 d?cembre 2020, 14:16:27 CET Philip Linde a ?crit :
> I understand the need for other document types to take other character
> encodings. For example, I have a collection of old text files in IBM437
> encoding. For text/gemini, we pretty much have a blank slate, though,
> and I see no reason that it should extend to support arbitrary
> encodings when limiting to UTF-8 creates a much simpler situation for
> implementers and is already the unspoken standard.

The main reason I see for authorizing other encodings is to be future proof.

When people designed old protocols they thought ASCII was here to stay.

So, I think we should learn from the past and not set in stone that all files must use utf-8, maybe something else will arise and be better for some unsuspected reason, and people will want to use that.

C?me



From solderpunk at posteo.net  Mon Dec 28 13:10:36 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 28 Dec 2020 14:10:36 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <20201228125912.6c6fee79@kongroo.lan>
Message-ID: <C84FZAXR46NW.19FYONR1ABX0S@stilgar>

On Mon Dec 28, 2020 at 12:59 PM CET, Solene Rapenne wrote:

> the code doesn't check anything, it only serves what is requested [1].

Okay, I just read the complete Vger code, and see that the URL handling
is indeed pretty minimal.  E.g. domain-based virtual hosting would break
if a request included an explicit port (which would be interpreted as
part of the hostname), and filenames with spaces in them cannot be
served (because the %20 encoding of the space character in the URL path
is not reversed by the server), and queries (which make no sense for
static content and should be ignored) are not separated from the path.

I don't mean this as criticism, obviously for hobby servers something
like this is perfectly workable.  I guess the concern is that we ideally
want even "production grade" servers to be quite easy to write.  Such a
server would need to handle all the things above and more.  Few people
want to do all that parsing by hand, so would use a library, and because
URI parsing is so widely used the theory is it's never too hard to find
a library for your favourite language with your favourite license.  This
is why there are already plenty of production grade (or close to it)
servers and clients out there.  But apparently many URI parsing
libraries have never been upgraded to also do IRIs.  I had hoped Vger's
surprising IRI compatibility meant there was easily available C code for
doing this after all, but it seems not.

So, while this is still very happy news, it's no rebuttal of the
argument that switching to IRIs would make writing a solid server in C
(or other languages without extensive and modern standard libraries, C
is not really special here) into a considerably more difficult
undertaking.

Cheers,
Solderpunk

From linde.philip at gmail.com  Mon Dec 28 13:33:03 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 28 Dec 2020 14:33:03 +0100
Subject: [spec] Adapting the HTTP Common Logging Format for use by
 Gemini servers
In-Reply-To: <2050148.5bT7vuFU4P@tempete>
References: <CAD2gp_RAoEDKmS8ixeHC3HzkYHcp7iJEpwJwT4ck_RUjmgEzUA@mail.gmail.com>
 <2050148.5bT7vuFU4P@tempete>
Message-ID: <20201228143303.96a8e76c8731a9761f148d26@gmail.com>

On Sun, 27 Dec 2020 21:39:41 +0100
C?me Chilliet <come at chilliet.eu> wrote:

> * I do not log the IP but its sha1 hash, because of privacy concerns

Please note that the table of the sha-1 of the entire IPv4 address space
is ~80 GiB and that such a measure can easily be reversed if not
individually salted before hashing (after which comparing hashes in
log entries is useless), even if I have to resort to searching the
whole IPv4 address space. You should *not* depend on this measure where
you have a real need for privacy.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/d356e3e6/attachment-0001.sig>

From luke at marmaladefoo.com  Mon Dec 28 13:36:11 2020
From: luke at marmaladefoo.com (Luke Emmet)
Date: Mon, 28 Dec 2020 13:36:11 +0000
Subject: [spec] What to do of fragments when there is a redirection
In-Reply-To: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
References: <C84BX11MHOKW.10GTTO95CQ8AD@stilgar>
Message-ID: <5FE9DF4B.90401@marmaladefoo.com>



On 28-Dec-2020 09:59, Solderpunk wrote:
> Okay, so original URL fragments should be carried over to redirect URLs
> if the redirect URL has no fragment (which I still suspect perhaps
> should be the only valid case).
Redirect URLs should not have a fragment as they specify a client side 
action. They wont be aware of the clients currently held fragment, so 
cannot act legitimately on it (for example to propose an alternative 
fragment). If they do have one, the client should strip it off, if they 
re-apply the previous fragment.

But frankly I'm skeptical it is a good semantics for a client to 
re-apply an old fragment on an out of date resource to a newly 
redirected resource. In my view they are attached only to the original 
URL and should not be replayed.

There are also some information leakage questions here of replaying 
fragments against new resources, but probably they arent too problematic 
in practice.

> What about queries?
>
> To some extent, the issue of a redirect URL having a query in it is
> similar to a link in a text/gemini document having a query in it, which
> was slightly controversial.  Not so much in the sense that people
> thought it should be disallowed, but that it was widely believed clients
> should handle such things very carefully and give the user a chance to
> confirm or edit the query string contents.
>
> Should redirect URLs be allowed to contain queries?
>
> If an original URL has a query in it but the client gets back a redirect
> URL without a query, should the original query be appended?

No, queries are very different to fragments which are client side. 
Queries are part of the server's URL space, like the path.

URLs with queries should not be adjusted by the client, unless in 
response to a user input.

A server may legitimately use these to implement various kinds of state 
- for example (in relation to another thread) the language partition of 
the application. For example I could implement a weather report in 
different languages thus:

gemini://server/weather/report?english

if the server implements a redirect to a new end point, it should do the 
work of appending any relevant parameterised query, thus:

31 gemini://server/weather/new-report?english

The client cannot know that the query would be valid against the target 
URL, and besides the target URL may already have a query on it, that the 
client should not strip off and replace with something else

  - Luke

From solderpunk at posteo.net  Mon Dec 28 13:30:38 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 28 Dec 2020 14:30:38 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <1912300.0KG8479sM4@tempete>
Message-ID: <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>

> Le lundi 28 d?cembre 2020, 14:16:27 CET Philip Linde a ?crit :

> > I understand the need for other document types to take other character
> > encodings. For example, I have a collection of old text files in IBM437
> > encoding. For text/gemini, we pretty much have a blank slate, though,
> > and I see no reason that it should extend to support arbitrary
> > encodings when limiting to UTF-8 creates a much simpler situation for
> > implementers and is already the unspoken standard.

The spec says that "Compliant clients MUST support UTF-8-encoded text/*
responses.  Clients MAY optionally support other encodings".  So, the
argument that we should make things simpler for implementers does not
really carry much weight here.  It's 100% okay to write a client which
(gracefully) refuses to handle any encoding other than UTF-8.  People
who want to serve text/gemini content with some other encoding can, but
they have no right to complain when only a subset (potentially a very
small one) of people can view said content.  This all seems fine to me.
Nobody is required or expected to support anything difficult or unusual,
but if some group of people all decide they want to do something
difficult or unusual for some strange reason, and they're willing to do
the work required, then nobody can tell them they're doing anything
wrong.

Cheers,
Solderpunk

From solene at perso.pw  Mon Dec 28 13:40:42 2020
From: solene at perso.pw (Solene Rapenne)
Date: Mon, 28 Dec 2020 14:40:42 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <C84FZAXR46NW.19FYONR1ABX0S@stilgar>
References: <20201228125912.6c6fee79@kongroo.lan>
 <C84FZAXR46NW.19FYONR1ABX0S@stilgar>
Message-ID: <20201228144042.2c7ff670@kongroo.lan>

On Mon, 28 Dec 2020 14:10:36 +0100
"Solderpunk" <solderpunk at posteo.net>:

> On Mon Dec 28, 2020 at 12:59 PM CET, Solene Rapenne wrote:
> 
> > the code doesn't check anything, it only serves what is requested [1].  
> 
> Okay, I just read the complete Vger code, and see that the URL handling
> is indeed pretty minimal.  E.g. domain-based virtual hosting would break
> if a request included an explicit port (which would be interpreted as
> part of the hostname), and filenames with spaces in them cannot be
> served (because the %20 encoding of the space character in the URL path
> is not reversed by the server), and queries (which make no sense for
> static content and should be ignored) are not separated from the path.
 
indeed, using the port in the query would currently break, a patch will
be published soon. I had very few feedback about the daemon and it seem
to work for most people so yes, issues (or lacks of special cases)
are still to be found, but I'd like vger to be production grade though.

> I don't mean this as criticism, obviously for hobby servers something
> like this is perfectly workable.  I guess the concern is that we ideally
> want even "production grade" servers to be quite easy to write.  Such a
> server would need to handle all the things above and more.  Few people
> want to do all that parsing by hand, so would use a library, and because
> URI parsing is so widely used the theory is it's never too hard to find
> a library for your favourite language with your favourite license.  This
> is why there are already plenty of production grade (or close to it)
> servers and clients out there.  But apparently many URI parsing
> libraries have never been upgraded to also do IRIs.  I had hoped Vger's
> surprising IRI compatibility meant there was easily available C code for
> doing this after all, but it seems not.
> 
> So, while this is still very happy news, it's no rebuttal of the
> argument that switching to IRIs would make writing a solid server in C
> (or other languages without extensive and modern standard libraries, C
> is not really special here) into a considerably more difficult
> undertaking.
> 
> Cheers,
> Solderpunk

I'll take a look at libcu as suggested. I think it's widely available
and certainly already there for most people because it must be a very
common dependency so I wouldn't considered it a bloat to use libcu.

If I get something done with libcu, I'll share it here if someone
is interested. For others languages, it would still be possible to
use ffi to call the C libicu into your favorite programming language.

Obviously, supporting IRI is far more complicated than answering to a
query containing special characters. That's why I asked on the mailing
list, I lack knowledge in this field and I couldn't imagine all cases.

From solderpunk at posteo.net  Mon Dec 28 13:54:14 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Mon, 28 Dec 2020 14:54:14 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <1b2750ca-7781-4c9e-9f98-12a9cf22d43c@worrbase.com>
Message-ID: <C84GWPETON92.2ENUW2WU9TVIT@stilgar>

On Mon Dec 28, 2020 at 1:12 PM CET, William Orr wrote:

> Normalization is the process of looking for all of these synonyms for
> characters, and standardizing them to the same set of codepoints. If you
> don't normalize, you could have a case where one user gets the intended
> host for ?crire.hostname and another user gets an NXDOMAIN, all
> depending on the sequence of bytes their input method produced.

...and actually, now that I think about, this issue is not specific to
IRI support, is it?  Even if we followed the web's lead and declared
that Gemini requests and text/gemini links must contain ASCII-only URLs,
and people have to do punycoding of non-ASCII hostnames and
percent-encoding of UTF-8 representations of non-ASCII paths, it's still
possible for the server and client to have different ideas about how a
hostname or path are represented, right?  With one using a composed form
and the other a decomposed form?  Whether you send a UTF-8 string as-is
or first punycode and/or percent-encode it so it's valid ASCII is
totally orthogonal to that question.  Or have I missed something
important?

Cheers,
Solderpunk

From linde.philip at gmail.com  Mon Dec 28 14:34:56 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 28 Dec 2020 15:34:56 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <1912300.0KG8479sM4@tempete>
References: <20201228141627.7bebd030c7ffde63118338c6@gmail.com>
 <1912300.0KG8479sM4@tempete>
Message-ID: <20201228153456.8a22e48bc311eebea0b576b6@gmail.com>

On Mon, 28 Dec 2020 14:25:29 +0100
C?me Chilliet <come at chilliet.eu> wrote:

> The main reason I see for authorizing other encodings is to be future proof.
> 
> When people designed old protocols they thought ASCII was here to stay.

On the other hand, when people adopted Unicode 5.0, they did so fully
aware that there would likely be a Unicode 6.0, 7.0, 8.0 etc. Unicode
is future proof in the sense that it includes a process for updating
itself. The comparison to ASCII in that sense does not consider the
entirely different approaches these standards take. Where ASCII is
fixed and limited to a relatively tiny set of characters, Unicode is
deliberately open to amendment.

> So, I think we should learn from the past and not set in stone that all files must use utf-8, maybe something else will arise and be better for some unsuspected reason, and people will want to use that.

In such an event we can under the current spec either expect an
effective split of geminispace around which clients support what
encodings, or widespread client updates. This is not a very different
situation from a change to the fixed spec.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/fbca2a56/attachment.sig>

From petite.abeille at gmail.com  Mon Dec 28 14:46:51 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Mon, 28 Dec 2020 15:46:51 +0100
Subject: What is required to be IRI compliant?
In-Reply-To: <C84GWPETON92.2ENUW2WU9TVIT@stilgar>
References: <C84GWPETON92.2ENUW2WU9TVIT@stilgar>
Message-ID: <F8947968-FD42-498D-885E-A595FC3E1770@gmail.com>



> On Dec 28, 2020, at 14:54, Solderpunk <solderpunk at posteo.net> wrote:
> 
> ...and actually, now that I think about, this issue is not specific to
> IRI support, is it?

Correct. Unicode normalization is an issue in and by itself. 

Of course, as demonstrated by Solene, there are various level of compliance: from simple, but functional, to bullet proof, industrial grade, and complex.

It's a spectrum. Like this mailing list :D



From linde.philip at gmail.com  Mon Dec 28 15:34:29 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 28 Dec 2020 16:34:29 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
Message-ID: <20201228163429.124d2cd3a1c09fab32941503@gmail.com>

On Mon, 28 Dec 2020 14:30:38 +0100
"Solderpunk" <solderpunk at posteo.net> wrote:

> The spec says that "Compliant clients MUST support UTF-8-encoded text/*
> responses.  Clients MAY optionally support other encodings".  So, the
> argument that we should make things simpler for implementers does not
> really carry much weight here.  It's 100% okay to write a client which
> (gracefully) refuses to handle any encoding other than UTF-8. 

I am not so interested in what is okay or not in the abstract. As a
client author, the ideal situation for me is that my client supports the
entire per-specification geminispace. The specification currently makes
this a much harder problem than it would be if text/gemini documents
were limited to UTF-8. In fact, it's an open-ended problem that's
subject to change (as new encodings are introduced) and interpretation
(concerning what sequence of bytes represents e.g. "=>" in a
particular encoding, or how to transliterate URI to ASCII or IRI to
UTF-8). Thankfully, geminispace seems to have settled on UTF-8, which is
why I think this is a good time to tie that end up.

> People
> who want to serve text/gemini content with some other encoding can, but
> they have no right to complain when only a subset (potentially a very
> small one) of people can view said content.  This all seems fine to me.
> Nobody is required or expected to support anything difficult or unusual,
> but if some group of people all decide they want to do something
> difficult or unusual for some strange reason, and they're willing to do
> the work required, then nobody can tell them they're doing anything
> wrong.

Perhaps there is a great argument for allowing other encodings that
makes this an acceptable outcome, but a hypothetical effective split of
geminispace around which encodings are used and which clients support
them doesn't sound desirable in itself.

We can turn the question around and instead ask what motivates the
inclusion of each supported encoding (or arbitrary encodings in
general, a simpler question).

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/12e26723/attachment-0001.sig>

From linde.philip at gmail.com  Mon Dec 28 15:35:41 2020
From: linde.philip at gmail.com (Philip Linde)
Date: Mon, 28 Dec 2020 16:35:41 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <1912300.0KG8479sM4@tempete>
References: <20201228141627.7bebd030c7ffde63118338c6@gmail.com>
 <1912300.0KG8479sM4@tempete>
Message-ID: <20201228163541.def020b3130e5d9a5d0cca8a@gmail.com>

Note also, regarding the current discussion about IRI, that if IRI is
adopted and the community later adopts a different (UTF-8
incompatible) standard encoding, the way IRI is implemented has to
change, or we lose its benefits entirely when we implement a
galaxy-grade encoding in the year 2121 and still have to deal with
UTF-8 IRI.

Even if IRI is decided against, by requiring URI at all, we're betting
that this hypothetical future encoding will be ASCII-compatible, or
we're giving client authors the additional burden of transcoding.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/c7b8a00b/attachment.sig>

From pitr.vern at gmail.com  Mon Dec 28 15:39:17 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Mon, 28 Dec 2020 16:39:17 +0100
Subject: [user] [ot] flame warriors: a full taxonomy
In-Reply-To: <145D252A-B9FC-4C0B-AE7F-7DA3A9C62464@gmail.com>
References: <145D252A-B9FC-4C0B-AE7F-7DA3A9C62464@gmail.com>
Message-ID: <CAG-mZ3hWmKmnF-AnPUOXXix3QEAuUGxijrBXjb4Fa4j579=uxA@mail.gmail.com>

Is this like those ?What kind of mermaid are you?? quizzes?

https://en.wikipedia.org/wiki/Personality_test#Criticism_and_controversy

On Mon, Dec 28, 2020 at 13:59 Petite Abeille <petite.abeille at gmail.com>
wrote:

> There seems to be a lot of hurt feelings around the mailing list...
> tantrum and all.
>
> To lighten the mood, what flame warrior are you?
>
> Acne
> Admin
> Agent
> ALLCAPS
> Android
> Archivist
> Atheist
> Artiste
> Artful Dodger
> Big Cat
> Big Dog and Me-Too
> Bliss Ninny
> Blowhard
> Bong
> Captialista
> Centurion
> Coffee Klatch
> Compost
> Crybaby
> Cyber Sisters
> Deacon
> Diplomat
> Democrats
> Duelists
> Eagle Scout
> Ego
> Ent
> Ennui
> Ethnix
> Evil Clown
> Ferrous Cranus
> Filibuster
> Fragile Femme
> Furious Typer
>
> Garble
> God
> Godzilla
> Grammarian
> Grenade
> Grunter
> Howlers
> Ideologue
> Imposter
> Innocence Abused
> Issues
> Jekyl and Hyde
> Jerk
> Klaxon
> Kung-Fu Master
> Lamer
> L'Enfant Provocateur
> Lonely Guy
> Loopy
> Lurker
> Nanny
> Net Rat
> Netiquette Nazi
> Newbie
> Nitpick
> Palooka
> Patois
> Peacemaker
> Perv
> Philosopher
> Picador
> Pinko
> Pithy Phrase
> Profundus Maximus
>
> Propeller Head
> Rat
> Rebel Leader
> Rebel Without a Clue
> Republicans
> Rottweiler Puppy
> Royals
> Stealth
> Stone Deaf
> Strumpet
> The Swarm
> Sycophant
> Target
> Therapist
> Tiny Yapper
> Tireless Rebutter
> Toxic Granny
> Troglodyte
> Troller
> Typhoid Mary
> Weenie
> Whisper
> Xenophobe
> Yuk Yuk
>
> https://en.chessbase.com/post/flame-warriors-a-full-taxonomy
>
> https://web.archive.org/web/20040612154117/http://www.winternet.com/~mikelr/flame1.html
> https://en.wikipedia.org/wiki/Flaming_(Internet)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/904228ae/attachment.htm>

From will at worrbase.com  Mon Dec 28 15:56:28 2020
From: will at worrbase.com (William Orr)
Date: Mon, 28 Dec 2020 15:56:28 +0000 (UTC)
Subject: What is required to be IRI compliant?
In-Reply-To: <C84GWPETON92.2ENUW2WU9TVIT@stilgar>
References: <C84GWPETON92.2ENUW2WU9TVIT@stilgar>
Message-ID: <2f37d069-2a61-4a9d-ae51-6b7dc7873379@worrbase.com>

Yes, that's absolutely the case even if IRIs are not used. Hopefully URI libraries and IDNA libraries handle this correctly by doing normalization before percent encoding/punycoding, but I haven't checked any implementations personally.

Normalization should come up in other contexts as well that would be common in gemini, like "find in page," search indexing, etc. Those cases may even make use of other normalization schemes like NFKC.

28 dic. 2020 15:01:41 Solderpunk <solderpunk at posteo.net>:

> On Mon Dec 28, 2020 at 1:12 PM CET, William Orr wrote:
> 
>> Normalization is the process of looking for all of these synonyms for
>> characters, and standardizing them to the same set of codepoints. If you
>> don't normalize, you could have a case where one user gets the intended
>> host for ?crire.hostname and another user gets an NXDOMAIN, all
>> depending on the sequence of bytes their input method produced.
> 
> ...and actually, now that I think about, this issue is not specific to
> IRI support, is it?? Even if we followed the web's lead and declared
> that Gemini requests and text/gemini links must contain ASCII-only URLs,
> and people have to do punycoding of non-ASCII hostnames and
> percent-encoding of UTF-8 representations of non-ASCII paths, it's still
> possible for the server and client to have different ideas about how a
> hostname or path are represented, right?? With one using a composed form
> and the other a decomposed form?? Whether you send a UTF-8 string as-is
> or first punycode and/or percent-encode it so it's valid ASCII is
> totally orthogonal to that question.? Or have I missed something
> important?
> 
> Cheers,
> Solderpunk

From kiba.fox at foxypossibilities.com  Mon Dec 28 19:31:09 2020
From: kiba.fox at foxypossibilities.com (Kiba Fox)
Date: Mon, 28 Dec 2020 14:31:09 -0500
Subject: [spec] Oustanding issues
In-Reply-To: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
References: <C83IATQ52E1C.1EBSKT04414WU@stilgar>
Message-ID: <dd2695d3-c2ef-3b5f-b2a1-c1a78d64f856@foxypossibilities.com>

Hello,

I have a suggestion to add to the list and a question on parsing quote 
lines.

> I'm trying to prepare a list of spec issues that I want to finalise as
> soon as possible.  If you think I've forgotten something, please let me know.

The current spec suggests supporting TOFU.  I think you may want to 
consider also supporting using the default/system certificate authority 
trust system as a fallback.  This allows certificates signed by Let's 
Encrypt or others to be used without the client having to store the 
known certificate. It also allows server operators to renew certificates 
without breaking clients.

This might be the behavior of clients today (trust system trusted CAs or 
use TOFU), but it's nice to have clearly defined behavior.

> * There's this long-standing issue of the fact that none of the
>    character sequences which identify the start of a non-text line type
>    were originally defined with spaces after them, but we've added that
>    requirement hodge-podge as ambiguities have appeared, and now we're in
>    a situation where half the line types need them and half don't.
>    Consistency suggests we require spaces everywhere, but this has been
>    surprisingly controversial and may break some things.  But a final
>    ruling is required.

I've been wondering about this...  Specifically, in these example scenarios:

Sans whitespace: >This is a quote
With whitespace: > This is a quote

Should these two be parsed the same or should one include leading 
whitespace?

-----

Also, are you open to suggestions/additions to the text/gemini format?

-- 
Kind regards,
Kiba

From nothien at uber.space  Mon Dec 28 21:27:27 2020
From: nothien at uber.space (Arav K.)
Date: Mon, 28 Dec 2020 22:27:27 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <7EB11770-C999-4296-9B7D-9778D3C4C848@gmail.com>
References: <eee2f372-5713-84e3-bb93-a94a4e1d29d3@qwertqwefsday.eu>
 <C83XUTAXCDXP.AS2H9UKMG2LG@stilgar>
 <20201227232157.GM3625@brevard.conman.org>
 <7EB11770-C999-4296-9B7D-9778D3C4C848@gmail.com>
Message-ID: <20201228212727.ciwsyz4ap7pfpkos@gux>

On Mon, Dec 28, 2020 at 12:27:15AM +0100, Petite Abeille wrote:
> This would be easier if META would not legally contain any control
> characters to start with.

Won't be easier - malicious servers would just do it anyways.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/40b12613/attachment.sig>

From sean at conman.org  Mon Dec 28 23:35:39 2020
From: sean at conman.org (Sean Conner)
Date: Mon, 28 Dec 2020 18:35:39 -0500
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
Message-ID: <20201228233539.GO3625@brevard.conman.org>

It was thus said that the Great Solderpunk once stated:
> > Le lundi 28 d?cembre 2020, 14:16:27 CET Philip Linde a ?crit :
> 
> > > I understand the need for other document types to take other character
> > > encodings. For example, I have a collection of old text files in IBM437
> > > encoding. For text/gemini, we pretty much have a blank slate, though,
> > > and I see no reason that it should extend to support arbitrary
> > > encodings when limiting to UTF-8 creates a much simpler situation for
> > > implementers and is already the unspoken standard.
> 
> The spec says that "Compliant clients MUST support UTF-8-encoded text/*
> responses.  Clients MAY optionally support other encodings".  

  I would ammend that to read "Compliant clients MUST support UTF-8 and
US-ASCII encoded text/* reponses." This is because US-ASCII is a proper
subset of UTF-8, and any valid ASCII file is also a valid UTF-8 file.  I'm
thinking here of automated MIME detection (ala libmagic) that might return a
MIME type of 'text/plain; charset=us-ascii' for a text file.

  -spc

From johann at qwertqwefsday.eu  Tue Dec 29 01:01:30 2020
From: johann at qwertqwefsday.eu (Johann Galle)
Date: Tue, 29 Dec 2020 02:01:30 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <20201228212727.ciwsyz4ap7pfpkos@gux>
References: <eee2f372-5713-84e3-bb93-a94a4e1d29d3@qwertqwefsday.eu>
 <C83XUTAXCDXP.AS2H9UKMG2LG@stilgar>
 <20201227232157.GM3625@brevard.conman.org>
 <7EB11770-C999-4296-9B7D-9778D3C4C848@gmail.com>
 <20201228212727.ciwsyz4ap7pfpkos@gux>
Message-ID: <921cb37f-b421-c61b-e4dc-af37183fb529@qwertqwefsday.eu>

On 2020-12-28T11:27Z, Petite Abeille wrote:
 > This would be easier if META would not legally contain any control
 > characters to start with.

On 2020-12-28T21:27Z, Arav K. replied:
 > Won't be easier - malicious servers would just do it anyways.

If it is forbidden, we could just filter out control code points without worring
about destroying valid use cases. Although I wonder what those would be.

Johann
---
You can verify the digital signature on this email with the public key
available through web key discovery. Try e.g. `gpg --locate-keys`...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201229/fcce822a/attachment-0001.sig>

From petite.abeille at gmail.com  Tue Dec 29 07:51:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 08:51:48 +0100
Subject: [spec] Oustanding issues
In-Reply-To: <921cb37f-b421-c61b-e4dc-af37183fb529@qwertqwefsday.eu>
References: <eee2f372-5713-84e3-bb93-a94a4e1d29d3@qwertqwefsday.eu>
 <C83XUTAXCDXP.AS2H9UKMG2LG@stilgar>
 <20201227232157.GM3625@brevard.conman.org>
 <7EB11770-C999-4296-9B7D-9778D3C4C848@gmail.com>
 <20201228212727.ciwsyz4ap7pfpkos@gux>
 <921cb37f-b421-c61b-e4dc-af37183fb529@qwertqwefsday.eu>
Message-ID: <795611C1-09DF-4BB7-993A-8E8C98BAFB84@gmail.com>



> On Dec 29, 2020, at 02:01, Johann Galle <johann at qwertqwefsday.eu> wrote:
> 
> If it is forbidden, we could just filter out control code points without worring
> about destroying valid use cases.

Genau.

> Although I wonder what those would be.

Smuggling ASCII art in response status? :D


From petite.abeille at gmail.com  Tue Dec 29 08:00:29 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 09:00:29 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <20201228233539.GO3625@brevard.conman.org>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
Message-ID: <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>



> On Dec 29, 2020, at 00:35, Sean Conner <sean at conman.org> wrote:
> 
>  I would ammend that to read "Compliant clients MUST support UTF-8 and
> US-ASCII encoded text/* reponses."

This is wholly redundant. UTF-8 is, by design, a /superset/ of US-ASCII. 

But the reverse is not true, obviously. Therefore the endless confusion.

Drop the US-ASCII holdovers. Embrace UTF-8. Move on.

My 2?.

From petite.abeille at gmail.com  Tue Dec 29 08:17:03 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 09:17:03 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
Message-ID: <3DA9260D-9316-4B20-BBC4-BC7780528BF0@gmail.com>



> On Dec 29, 2020, at 09:00, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Drop the US-ASCII holdovers. Embrace UTF-8. Move on.

If this is too much to swallow, then we have to phrase is the other way around:

"Clients MUST support US-ASCII, and SHOULD support UTF-8"

The same applies to the request URL, and text/gemini links.






From ew.gemini at nassur.net  Tue Dec 29 08:48:47 2020
From: ew.gemini at nassur.net (ew.gemini)
Date: Tue, 29 Dec 2020 09:48:47 +0100
Subject: [user] new capsule
Message-ID: <82mtxx80b4.fsf@nassur.net>


Hello,

thanks to solderpunk for hosting my capsule at

=> gemini://gemini.circumlunar.space/~ew/

I have never really produced a blog --- allthough I heavily rely
on what information others make avaiable. I have made one attempt
(using emacs, ox-publish) and it immediately seemed awkward. I
gave up after like half a dozen posts ... Now with the minimal
approach of gemini:// writing up something feels much simpler. I
don't even have to check the cheat sheet for .gmi text layout.
So thank you everyone involved in making this experiment a
reality.

I like to read what others write. I already found a number of
posts, which brightend my day :) Thanks!


Cheers,
~ew

-- 
Keep it simple!

From sean at conman.org  Tue Dec 29 09:03:23 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 29 Dec 2020 04:03:23 -0500
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
Message-ID: <20201229090322.GP3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Dec 29, 2020, at 00:35, Sean Conner <sean at conman.org> wrote:
> > 
> >  I would ammend that to read "Compliant clients MUST support UTF-8 and
> > US-ASCII encoded text/* reponses."
> 
> This is wholly redundant. UTF-8 is, by design, a /superset/ of US-ASCII. 

  Not it's not.  Here's the origial text:

> The spec says that "Compliant clients MUST support UTF-8-encoded text/*
> responses.  Clients MAY optionally support other encodings".

  Per this wording, any client that receives "text/plain; charset=us-ascii"
is allowed to just drop it on the floor and do absolutely nothing with it. 
Some here migh actually prefer that, but "text/plain; charset=us-ascii" is
also "text/plain; charset=utf-8", that is, a client *can* do something
meaningful with it, unlike "text/plain; charset=CSISOLATIN3".

> Drop the US-ASCII holdovers. Embrace UTF-8. Move on.

  Why do you hate textfiles.com?

> My 2?.

  -spc (my $.02)


From petite.abeille at gmail.com  Tue Dec 29 09:11:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 10:11:39 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <20201229090322.GP3625@brevard.conman.org>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
Message-ID: <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>



> On Dec 29, 2020, at 10:03, Sean Conner <sean at conman.org> wrote:
> 
>  Per this wording, any client that receives "text/plain; charset=us-ascii"
> is allowed to just drop it on the floor and do absolutely nothing with it. 

Nonsense. A compliant client MUST support UTF-8. US-ASCII is a strict subset of UTF-8. Therefore a compliant client supports US-ASCII out-of-the-box.  Nothing more, and nothing less.

>  Why do you hate textfiles.com?

Haters gonna hate :P

Isn't it, like, 3am in your timezone? Go back to bed :)

From petite.abeille at gmail.com  Tue Dec 29 10:02:39 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 11:02:39 +0100
Subject: [tech] [eli5] US-ASCII is a subset of UTF-8. UTF-8 is a superset of
 US-ASCII. 
Message-ID: <ECCFB60A-21C1-4FE6-8999-8C73C365E95F@gmail.com>

"UTF-8 was first officially presented at the USENIX conference in San Diego in 1993... "

Nearly 28 years ago. We must have a clear understanding of what it is by now.

When something can handle US-ASCII, does *not* imply it can handle UTF-8.

When something can handle UTF-8, it *does* imply it can handle US-ASCII.

US-ASCII is a subset of UTF-8. UTF-8 is a superset of US-ASCII. 

UTF stands for Unicode Transformation Format.

It carries all the complexity of Unicode, plus some, namely validation.

Including Unicode normalization.

The very same character can be be represented by various code-point sequences in Unicode. 
And therefore in UTF-8 text. 
And therefore in punycode. 
And therefore in URL encoding.
And therefore in URI encoding.
And therefore in IRI.

This is why, before any interactions can take place, both parties MUST normalize Unicode the same way. And then encode/decode it.

There is no way around this requirement if we say that we support UTF-8, and therefore Unicode.

All this applies wherever UTF-8 can appear: in a request URL, in text/gemini, in a text/gemini link url.

Making UTF-8 a MUST makes Unicode a MUST. This is the way.

If Gemini does not want to deal with the complexity of Unicode, Gemini MUST change the specification to read:

Clients MUST support US-ASCII, and SHOULD support UTF-8.

Gemini cannot have it both ways, it's either UTF-8, and therefore Unicode, or plain US-ASCII.

HTH.

 




From petite.abeille at gmail.com  Tue Dec 29 12:08:04 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 13:08:04 +0100
Subject: [tech] [eli5] URI = IRI = ASCII = UTF-8 = Unicode
Message-ID: <373F9FBF-7915-4FA3-9D1A-DAA47CA63566@gmail.com>

"Uniform Resource Locators were defined in RFC 1738 in 1994 by Tim Berners-Lee"

~26 years ago. We must have a good understanding of what they are by now.


An URI can -in plain US-ASCII- represent all UTF-8 code points. Therefore all of Unicode.
An IRI can -in plain UTF-8- represent all of Unicode. No need for US-ASCII encoding.

They are wholly equivalent in term of content, and only differs in terms of encoding. 

The only visible difference between URI and IRI is how Unicode is conveyed: ASCII encoded in URI, UTF-8 in IRI.

They are otherwise identical in all aspects.


The following Gemini response is in vanilla US-ASCII:

20 text/gemini;charset=us-ascii;
=> gemini://xn--el8h/%F0%9F%91%B9.gmi

And yet, because of the nature of URI, it contains two Unicode characters; US-ASCII transmitted; UTF-8 encoded.

Here is the exact same response, but in UTF-8, due to IRI in the link:

20 text/gemini;charset=utf-8;
=> gemini://?/?.gmi


Both responses represent exactly the same content. They are only encoded differently.

Both contain UTF-8, and therefore Unicode. Both are identical. 

HTH.





From solderpunk at posteo.net  Tue Dec 29 12:28:21 2020
From: solderpunk at posteo.net (Solderpunk)
Date: Tue, 29 Dec 2020 13:28:21 +0100
Subject: [users] new capsule
In-Reply-To: <82mtxx80b4.fsf@nassur.net>
Message-ID: <C859PI2FHN19.2K4Q76NN0DXSY@stilgar>

Hi ew,

Welcome to Geminispace!  I am glad you are enjoying a less awkward
way to publish online. :)

I've changed the Subject of this reply to have the correct form of the
[users] topic, so that more people can see it.  You're certainly not the
first person to make this mistake.  I might redefine the topic so that
both [user] and [users] work, as that might make things easier.

Cheers,
Solderpunk

PS: For the curious, the choice of [users] and [tech] is mirroring
conventions from *BSD mailing lists.

On Tue Dec 29, 2020 at 9:48 AM CET, ew.gemini wrote:
>
> Hello,
>
> thanks to solderpunk for hosting my capsule at
>
> => gemini://gemini.circumlunar.space/~ew/
>
> I have never really produced a blog --- allthough I heavily rely
> on what information others make avaiable. I have made one attempt
> (using emacs, ox-publish) and it immediately seemed awkward. I
> gave up after like half a dozen posts ... Now with the minimal
> approach of gemini:// writing up something feels much simpler. I
> don't even have to check the cheat sheet for .gmi text layout.
> So thank you everyone involved in making this experiment a
> reality.
>
> I like to read what others write. I already found a number of
> posts, which brightend my day :) Thanks!
>
>
> Cheers,
> ~ew
>
> --
> Keep it simple!


From gemini at benthor.name  Tue Dec 29 12:53:57 2020
From: gemini at benthor.name (benthor)
Date: Tue, 29 Dec 2020 13:53:57 +0100
Subject: [tech] Any chagelog or older version of the Spec?
Message-ID: <878s9gojru.fsf@benthor.name>

Hi,

is there any Changelog/Diff of the Spec[1][2] available anywhere?

[1]: gemini://gemini.circumlunar.space/docs/specification.gmi
[2]: https://gemini.circumlunar.space/docs/specification.html

Cheers
benthor

From cage-dev at twistfold.it  Tue Dec 29 13:04:04 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 29 Dec 2020 14:04:04 +0100
Subject: [tech] Any chagelog or older version of the Spec?
In-Reply-To: <878s9gojru.fsf@benthor.name>
References: <878s9gojru.fsf@benthor.name>
Message-ID: <X+spRJ0y8+/ilXZ3@kurosawa.casa.net>

On Tue, Dec 29, 2020 at 01:53:57PM +0100, benthor wrote:
> Hi,

Hi!

> is there any Changelog/Diff of the Spec[1][2] available anywhere?

Yes, you can pull a git repo here:

git://gemini.circumlunar.space/gemini-site

Bye!
C.

From petite.abeille at gmail.com  Tue Dec 29 15:10:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 16:10:47 +0100
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
Message-ID: <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>



> On Dec 27, 2020, at 22:43, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> I don't foresee any engineering issues if we do our due diligence.

Honestly, I do have doubts now. Engineering wise.

This is not meant to be insulting to anyone's ego, but let's be realistic about our technical acumen, or possible lack thereof.

We do not appear to understand the two basic building blocks around which the whole of Gemini is constructed: URL and UTF-8. ?

Not to mention how they relate to each other.


Exhibit ? 1: the path segment discussion

Neither Stephane, who has spend his entire adult life versed in RFC literature, nor Sean, a technical master if there is one, nor even Google's own Go library,  get it right. In 2020.

Path segments have been around since time immemorial. They are not optional. It's not a "nice to have". Not understanding them betray a fundamental misunderstanding of what an URL is.


Exhibit ? 2: the URI vs. IRI saga

The only difference between URI & IRI is the ASCII armor around UTF-8. They are identical otherwise. They can both represent UTF-8, and therefore Unicode. Just differently.

And yet the conversation has been everywhere but at the crux of the issue, which is Unicode. As always.

Just yesterday, Soldierpunk had his eureka moment:

"...and actually, now that I think about, this issue is not specific to IRI support, is it? "

You are not saying. Nothing to do with IRI indeed. Everything to do with Unicode, as always.


I do appreciate we all have different level of technical understandings, and it never stops. Turtles all the way down.

But still, this is meant to be about designing a formal protocol. We must understand these basic building blocks to succeed.


On the other hand, there is Solene, who single-handily, without blinking, demonstrates what the essence of an IRI is, with ? a dozen lines of old fashioned C code. ?

So perhaps not everything is lost. But what a slog.



? Ignoring TLS, no one understand it.
? Yes, ? some details. But see Exhibit ? 1 and ? 2.




From cage-dev at twistfold.it  Tue Dec 29 17:25:58 2020
From: cage-dev at twistfold.it (cage)
Date: Tue, 29 Dec 2020 18:25:58 +0100
Subject: [users] [ANN] tinmop 0.4.0
Message-ID: <X+tmpv13hBV0fQ/a@kurosawa.casa.net>

Hi everyone!

I just released  a new version (0.4.0) of Tinmop:  a client for gemini
and pleroma with a terminal (curses) interface:

Here is the most important changes:

  - New features
    - added a command to repeat the last performed search;
    - "new-line" (aka 'enter') key can be used to scroll main window;
    - [gemini] added a command to refresh a page;
  - Modules
    - added a module to share a gemini link on pleroma.
  - Scripts
    - added a simple script for a welcome bot.
  - Bugfix
    - fixed IRI parsing and encoding/normalizing;
    - fixed false positive for new message on subscribed tags;
    - [gemini] fixed bug that prevented visit the same link more than
      once;
    - fixed bugs that prevented following of users whit no messages in
      local database;
    - fixed quick_quicklisp.sh building script (thanks to Ben!).
  - Documentation
    - updated manpage.

Tinmop is free software releases under  GPLv3 or later and can be found
here:

https://www.autistici.org/interzona/tinmop.html

Bye!
C.

From kiba.fox at foxypossibilities.com  Tue Dec 29 18:12:34 2020
From: kiba.fox at foxypossibilities.com (Kiba Fox)
Date: Tue, 29 Dec 2020 13:12:34 -0500
Subject: [user] new capsule
In-Reply-To: <82mtxx80b4.fsf@nassur.net>
References: <82mtxx80b4.fsf@nassur.net>
Message-ID: <e9600b11-74da-e13a-6c15-e1cdbcdad70e@foxypossibilities.com>

On 12/29/20 3:48 AM, ew.gemini wrote:
> 
> Hello,
> 
> thanks to solderpunk for hosting my capsule at
> 
> => gemini://gemini.circumlunar.space/~ew/

Hello there!

Thank you for posting your new Gemini space.  I'm enjoying your writing.

What do you prefer for a client?  I'm having trouble with some terminal 
based clients and navigating numbered links that require two keystrokes 
(e.g. 24 would navigate to the second link then the fourth on the new 
page instead of link 24 on the original page.)

> I have never really produced a blog --- allthough I heavily rely
> on what information others make avaiable. I have made one attempt
> (using emacs, ox-publish) and it immediately seemed awkward. I
> gave up after like half a dozen posts ... Now with the minimal
> approach of gemini:// writing up something feels much simpler. I
> don't even have to check the cheat sheet for .gmi text layout.
> So thank you everyone involved in making this experiment a
> reality.
I've made several attempts to make a blog in the past, myself.  I'm 
excited about Gemini for its simplicity too.  Markdown (or org-mode) is 
nice, but with Gemini text it is much simpler, and I think having less 
options actually helps free you when writing.

It's not complete yet, but I'm slowly working on a static site generator 
that uses Gemini text as the primary text format.  It'll render it to 
HTML for multi protocol hosting without a proxy.

=> https://git.sr.ht/~kiba/gdn Gemini static site generator

> I like to read what others write. I already found a number of
> posts, which brightend my day :) Thanks!

I've been happily exploring others' writings on Gemini as well.  I don't 
know where I'll host it, but I've started the git repository for my own 
site and writings here:

=> https://git.sr.ht/~kiba/garden My digital garden


I wish you the best and I look forward to reading more of your posts.

-- 
Kind regards,
Kiba

From ew.gemini at nassur.net  Tue Dec 29 18:30:29 2020
From: ew.gemini at nassur.net (ew.gemini)
Date: Tue, 29 Dec 2020 19:30:29 +0100
Subject: [user] new capsule
In-Reply-To: <e9600b11-74da-e13a-6c15-e1cdbcdad70e@foxypossibilities.com>
References: <82mtxx80b4.fsf@nassur.net>
 <e9600b11-74da-e13a-6c15-e1cdbcdad70e@foxypossibilities.com>
Message-ID: <82k0t08ny2.fsf@nassur.net>


Hello Kiba,

Kiba Fox writes:
> On 12/29/20 3:48 AM, ew.gemini wrote:
>> Hello,
>> thanks to solderpunk for hosting my capsule at
>> => gemini://gemini.circumlunar.space/~ew/
>
> Hello there!
>
> Thank you for posting your new Gemini space.  I'm enjoying
> your writing.

Thanks!

> What do you prefer for a client?

I'm using emacs/elpher, however, emacs is running in window
mode on i3.

I'm also using kristall to experiment with gemini behind an
onion service (using torify).

Cheers,
~ew


-- 
Keep it simple!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201229/02ba3974/attachment.sig>

From prx at ybad.name  Tue Dec 29 19:32:37 2020
From: prx at ybad.name (prx)
Date: Tue, 29 Dec 2020 20:32:37 +0100
Subject: [users] Another new capsule : ArraKISS
Message-ID: <X+uEVffBDmGS1RyN@shaihulud.my.domain>

Hello everyone,

Seduced by the ideas behind gemini protocol, I also found gemtext so much relaxing in the meantime.
Thus, I decided to move my writings to a new capsule:

=> gemini://ybad.name ArraKISS

It is indeed very pleasing to write without inline links or other markup, even the simplest ones such as **bold text** one can find in markdown. I think it helps wondering how to write better (at least, it does for me).

Actually, I publish both on http and gemini, but focus on gemini using a stupid gemtext to html converter. It follows gemini specification (i.e. a line is a <p></p>). I call gemtext2html in a Makefile to convert modified gmi files to html, create an index of all pages, publish an atom feed of my gemlog...

=> https://dev.ybad.name/gemtext2html/

Mostly, I write in french, but sometimes in english.

Also, I enjoy contributing to vger, the gemini server wrote by @solene, that I also use.

=> https://tildegit.org/solene/vger

I must say I feel very happy with gemini and enjoy reading other capsule with the very well thought lagrange client.

Thank you for making this possible.
<3

prx


From pitr.vern at gmail.com  Tue Dec 29 21:24:14 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Tue, 29 Dec 2020 22:24:14 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
Message-ID: <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>

On Tue, Dec 29, 2020 at 10:11 AM Petite Abeille
<petite.abeille at gmail.com> wrote:
> > On Dec 29, 2020, at 10:03, Sean Conner <sean at conman.org> wrote:
> >
> >  Per this wording, any client that receives "text/plain; charset=us-ascii"
> > is allowed to just drop it on the floor and do absolutely nothing with it.
> Nonsense. A compliant client MUST support UTF-8. US-ASCII is a strict subset of UTF-8. Therefore a compliant client supports US-ASCII out-of-the-box.  Nothing more, and nothing less.

A car contains people. Therefore people are cars.

Petite, you are confusing Is-A and Has-A relationships [1][2]. UTF-8
is a ("separate" from US-ASCII) character encoding that contains ASCII
charset. If the spec said "clients MUST support ONLY UTF-8" then any
pages specifying "charset=us-ascii" must result in an error.

[1] https://en.wikipedia.org/wiki/Is-a
[2] https://en.wikipedia.org/wiki/Has-a

Back to a more productive topic, the wording in the spec - "clients
MUST support UTF-8 encoded responses" - is ambiguous and doesn't
actually mean that acceptable value for "charset" must include
"utf-8", and says nothing about what values of "charset" are
acceptable. It says that clients must at the very least try to decode
response using UTF-8 charset decoder. Responses encoded with US-ASCII
and UTF-8 (and UTF-PETER, which is a random subset of UTF-8) will
indeed work.

Looking at latest stats on
gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi it looks like
UTF-8 (this includes unspecified charsets which per spec default to
UTF-8) is used by 81% of pages, US-ASCII accounts for 17%.

Given this, I suggest the spec be rephrased such that it instead
specifies minimum acceptable values of "charset" (specifically
us-ascii and utf-8).

From sean at conman.org  Tue Dec 29 21:37:08 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 29 Dec 2020 16:37:08 -0500
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
Message-ID: <20201229213708.GQ3625@brevard.conman.org>

It was thus said that the Great Peter Vernigorov once stated:
> 
> Looking at latest stats on
> gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi it looks like
> UTF-8 (this includes unspecified charsets which per spec default to
> UTF-8) is used by 81% of pages, US-ASCII accounts for 17%.
> 
> Given this, I suggest the spec be rephrased such that it instead
> specifies minimum acceptable values of "charset" (specifically
> us-ascii and utf-8).

  Agreed.  And looking at the stats from GUS [1], text/plain is more popular
than text/gemini (by over 2:1) and UTF-8 to US-ASCII is 54% to 46%.

  -spc

[1]	gemini://gus.guru/statistics

From jon at shit.cx  Tue Dec 29 21:38:23 2020
From: jon at shit.cx (Jon)
Date: Wed, 30 Dec 2020 08:38:23 +1100
Subject: [users] A mirror of The Guardian
Message-ID: <20201229213823.6qbffuwswdcboxjw@devbox>

Inspired by the news mirrors at gemini://rawtext.club/sloum/gemininews/
and having a want for local news, I've created a partial mirror of The
Guardian.

I'm also happy to add other localised feeds if there is a need.

You can see it at gemini://guardian.shit.cx/

For now it will continue to accumulate articles, but I'll probably add a
retention policy to delete articles older than a month or a week.

-- 
Jon

From petite.abeille at gmail.com  Tue Dec 29 22:29:34 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 29 Dec 2020 23:29:34 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
Message-ID: <C70FF514-6A73-4BF5-B3E1-B031880D4E9E@gmail.com>



> On Dec 29, 2020, at 22:24, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
> Back to a more productive topic, the wording in the spec - "clients
> MUST support UTF-8 encoded responses" - is ambiguous and doesn't
> actually mean that acceptable value for "charset" must include
> "utf-8", and says nothing about what values of "charset" are
> acceptable.

Confused indeed.

Are you making a distinction between UTF-8 the encoding vs. utf-8 the charset? Is there such difference? What would that difference be? I feel out of depth.

But ok, if that helps in term of clarity of purpose, then more power to the spec by spelling it out.





From alex at nytpu.com  Tue Dec 29 22:44:10 2020
From: alex at nytpu.com (Alex // nytpu)
Date: Tue, 29 Dec 2020 15:44:10 -0700
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <20201229213708.GQ3625@brevard.conman.org>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
 <20201229213708.GQ3625@brevard.conman.org>
Message-ID: <20201229224410.qop25qvi4vodsqwt@GLaDOS>

> looking at the stats from GUS [1], text/plain is more popular than
> text/gemini (by over 2:1)
If I remember correctly, most of that plaintext is from an RFC mirror
somewhere, I'm sure the actual stats of stuff written and intended for
gemini, not including mirrored content, differs significantly from GUS'
report.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201229/75681097/attachment.sig>

From petite.abeille at gmail.com  Tue Dec 29 23:03:58 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 00:03:58 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
Message-ID: <48F3E961-33E3-4150-A7DA-2610ED694614@gmail.com>



> On Dec 29, 2020, at 22:24, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
> Looking at latest stats on
> gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi it looks like
> UTF-8 (this includes unspecified charsets which per spec default to
> UTF-8) is used by 81% of pages, US-ASCII accounts for 17%.

The actual numbers are as follow:

? Unspecified: 39628
? us-ascii: 9995
? utf-8: 7090
( 56,713 total)

It's not clear if this pertain to the 36,477 text/gemini documents only, or the entire dataset (57,164 url vs. 56,713 encodings. 451 MIA).

Looking at the numbers I guess it covers the entire data set as there are more 'Unspecified' than 'text/gemini' to start with.

I'm not sure what these numbers mean at all, but they are not describing text/gemini.

Not sure why we would draw any conclusion from them in regards to  text/gemini.







From luis.miguelde at gmail.com  Tue Dec 29 23:08:57 2020
From: luis.miguelde at gmail.com (Miguel de Luis)
Date: Tue, 29 Dec 2020 23:08:57 +0000
Subject: Hello all
Message-ID: <CAOouO1z72QC0TppydxEp_K583F6ADE2rTOKEMPFb4ROwq0chmQ@mail.gmail.com>

I literally read about Gemini and gopher last week and got hooked. In the
past I have struggled with all the bloated nonsense of WordPress when all
you want to do is to have your own wee place. It is so hard to have your
small site.
The whole system of complicated templates and SEO plugins made me forget
why I wanted to blog in the first place
Anyway, just set up my first liitle phlog and I am loving it. Surfing the
gropher space has replaced quite a bit of my youTube time.
I am looking towards starting something on Gemini too yet I am not too
sure  wether I should do it on my own VPN server or what. I literally set
up my first www and gopher server last weekend and Im not confident at
installing from source.

So any advice or tips would be quitr welcomed ?

This is Miguel from Canary Islands, Spain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201229/3799f403/attachment-0001.htm>

From lazar.michael22 at gmail.com  Tue Dec 29 23:13:55 2020
From: lazar.michael22 at gmail.com (Michael Lazar)
Date: Tue, 29 Dec 2020 18:13:55 -0500
Subject: [tech] [eli5] URI = IRI = ASCII = UTF-8 = Unicode
In-Reply-To: <373F9FBF-7915-4FA3-9D1A-DAA47CA63566@gmail.com>
References: <373F9FBF-7915-4FA3-9D1A-DAA47CA63566@gmail.com>
Message-ID: <CAFTy05ZH9BDhc2ipDcQmKDjmZ9veok0LGNQ3EQTG2MwTovzdVg@mail.gmail.com>

URI's use UTF-8 encoded octets only by popular convention and not by
any hard rule. You can stick any kind of binary data into a URI as
long as you percent-encode the non-ASCII bytes.

https://tools.ietf.org/html/rfc3986#section-2.5

For example, this file I just threw on my apache web server:

http://mozz.us/%80.txt

- Michael

From sean at conman.org  Tue Dec 29 23:19:14 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 29 Dec 2020 18:19:14 -0500
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
 <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
Message-ID: <20201229231913.GR3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> We do not appear to understand the two basic building blocks around which
> the whole of Gemini is constructed: URL and UTF-8. ?
> 
> Not to mention how they relate to each other.
> 
> Exhibit ? 1: the path segment discussion
> 
> Neither Stephane, who has spend his entire adult life versed in RFC
> literature, nor Sean, a technical master if there is one, nor even
> Google's own Go library, get it right. In 2020.
> 
> Path segments have been around since time immemorial. 

  Nope.  The first RFC to specify the format for URLs is RFC-1630 (June
1994), and no path segments (as currently defined).  It's not until four
years later, with RFC-2396 (August 1998) that we get the first recognizable
path segment (with path parameter).

> They are not optional. It's not a "nice to have". Not understanding them
> betray a fundamental misunderstanding of what an URL is.

  First off, SETTLE DOWN!

  Second, just because a feature exists doesn't mean it's actually used.

  Here's a task---find ONE example out on the web where %2F has semantic
meaning *other* than a path separator, *in the path segment* of a URL (other
than your own stuff).  I've been using the web since the early 90s, and I
don't think this has actually been done.  I don't think I've even seen path
paramters (using the ';' sub-delimeter) used! [1]

  I suspect no one got "it right" because it's just not a thing (either
encoded slashes, or path parameters) that have actually been needed.  Go's
take is probably the best you can find, with both decoding it and having the
raw path available.

  Even the modern concept of a URL, from the WhatWG [2], is getting away
from this.  As defined there, the "path percent-encode set" is:

	U+0000 .. U+001F
	U+007F .. U+10FFFF
	U+0020	SPACE
	U+0022	"
	U+0023	#
	U+0025	%
	U+003C	<
	U+003E	>
	U+003F	?
	U+0060	`
	U+007B	{
	U+007D	}

  Nothing about U+002F ('/').  I'm not saying we need to switch from
RFC-3986 (or RFC-3987) and use the WhatWG definition of a URL, but the
WhatWG is very pragmatic and are looking at *what is actually being used,*
not *what can be used.*

  Here's another task---create a Gemini server where %2F *is required* to
retrieve the resource.  Then see how many clients can actually query it, and
then convince all the client authors to fix their code.

  Good luck.  We're counting on you.

> Exhibit ? 2: the URI vs. IRI saga

  [ snip ]

> On the other hand, there is Solene, who single-handily, without blinking,
> demonstrates what the essence of an IRI is, with ? a dozen lines of old
> fashioned C code. ?

  Yes, I can believe it. If you aren't really doing any heavy text
processing, then even parsing "byte-by-byte" can work well with UTF-8.  I
wrote my own blogging engine [3] assuming only US-ASCII, and it works just
fine with UTF-8.  Hell, even my own very simplistic URL parser I wrote back
in the mid-90s parsed a IRI just fine, but that's down to a lax parser. 
Compare that with my own URL parser [4], based off the BNF of RFC-3986,
won't deal with an IRI, because of the stricter requirements.

  I'm not intentionally belittling Solene, I'm just pointing out that
supporting UTF-8, depending on the processing, just sometimes happens "for
free".  I also recall there being an issue with Solene's client not
supporting port numbers, so it's not always perfect engineering.

  A third task for you---try writing code to properly wrap *this* page:

	gemini://gemini.conman.org/test/torture/0049

  You can assume a monospace font and a width of 80 character cells (aka, a
typical terminal width).

  Good luck.  We're counting on you.

  -spc

[1]	There were originally defined for ftp: URLs in RFC-1630, and only
	applied after the path.

[2]	https://url.spec.whatwg.org/#percent-encoded-bytes

[3]	https://github.com/spc476/mod_blog

[4]	https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

From petite.abeille at gmail.com  Tue Dec 29 23:25:31 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 00:25:31 +0100
Subject: [tech] [eli5] URI = IRI = ASCII = UTF-8 = Unicode
In-Reply-To: <CAFTy05ZH9BDhc2ipDcQmKDjmZ9veok0LGNQ3EQTG2MwTovzdVg@mail.gmail.com>
References: <373F9FBF-7915-4FA3-9D1A-DAA47CA63566@gmail.com>
 <CAFTy05ZH9BDhc2ipDcQmKDjmZ9veok0LGNQ3EQTG2MwTovzdVg@mail.gmail.com>
Message-ID: <A3EC8E63-8AD6-48F3-9369-096BD85B318E@gmail.com>



> On Dec 30, 2020, at 00:13, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> URI's use UTF-8 encoded octets only by popular convention and not by
> any hard rule. You can stick any kind of binary data into a URI as
> long as you percent-encode the non-ASCII bytes.

Yes, indeed. Any random binary will do, e.g. the query portion could contain any weird binary data one sees fit to put there.

Not so much in other parts of the URI though, UTF-8 rules there. 



From petite.abeille at gmail.com  Tue Dec 29 23:25:44 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 00:25:44 +0100
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <20201229231913.GR3625@brevard.conman.org>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
 <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
 <20201229231913.GR3625@brevard.conman.org>
Message-ID: <B61C6C74-3331-4630-B404-3C207390668D@gmail.com>



> On Dec 30, 2020, at 00:19, Sean Conner <sean at conman.org> wrote:
> 
>  First off, SETTLE DOWN!

:)

> Second, just because a feature exists doesn't mean it's actually used.

https://en.wikipedia.org/wiki/A%2FB_testing


From sean at conman.org  Tue Dec 29 23:28:20 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 29 Dec 2020 18:28:20 -0500
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <B61C6C74-3331-4630-B404-3C207390668D@gmail.com>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
 <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
 <20201229231913.GR3625@brevard.conman.org>
 <B61C6C74-3331-4630-B404-3C207390668D@gmail.com>
Message-ID: <20201229232820.GS3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Dec 30, 2020, at 00:19, Sean Conner <sean at conman.org> wrote:
> > 
> >  First off, SETTLE DOWN!
> 
> :)
> 
> > Second, just because a feature exists doesn't mean it's actually used.
> 
> https://en.wikipedia.org/wiki/A%2FB_testing

  Touch?.

  One task down, you have two left.

  Good luck.  We're counting on you.

  -spc


From petite.abeille at gmail.com  Tue Dec 29 23:41:52 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 00:41:52 +0100
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <20201229232820.GS3625@brevard.conman.org>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
 <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
 <20201229231913.GR3625@brevard.conman.org>
 <B61C6C74-3331-4630-B404-3C207390668D@gmail.com>
 <20201229232820.GS3625@brevard.conman.org>
Message-ID: <75670BD4-BAF1-4CC5-BFDF-C06BC78D5181@gmail.com>



> On Dec 30, 2020, at 00:28, Sean Conner <sean at conman.org> wrote:
> 
>  Touch?.
> 
>  One task down, you have two left.
> 

Right.

Second task: considering we cannot even agree what an URL is, ?20 years later, it's rather pointless to try with Gemini, where the concept is truly alien, "radical familiarity" notwithstanding.
Third task: wrap *this* page. Hmmm. Why would I? What does it has to do with anything? Is that a throw back from the textflow mega thread? 

Long, uninterrupted sequences of random characters are not unique to Unicode. Or is the distinction between characters vs bytes? Then yes, it's 2020. Randomly chopping bytes is not appropriate indeed.



From petite.abeille at gmail.com  Tue Dec 29 23:47:43 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 00:47:43 +0100
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <75670BD4-BAF1-4CC5-BFDF-C06BC78D5181@gmail.com>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
 <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
 <20201229231913.GR3625@brevard.conman.org>
 <B61C6C74-3331-4630-B404-3C207390668D@gmail.com>
 <20201229232820.GS3625@brevard.conman.org>
 <75670BD4-BAF1-4CC5-BFDF-C06BC78D5181@gmail.com>
Message-ID: <72E12BB2-E429-468B-AC7F-AEA4AE57B9C7@gmail.com>



> On Dec 30, 2020, at 00:41, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> Long, uninterrupted sequences of random characters are not unique to Unicode. Or is the distinction between characters vs bytes? Then yes, it's 2020. Randomly chopping bytes is not appropriate indeed.

At a more practical level, while fmt doesn't quick handle non-ASCII, par might: http://www.nicemice.net/par/

From sean at conman.org  Tue Dec 29 23:57:48 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 29 Dec 2020 18:57:48 -0500
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <75670BD4-BAF1-4CC5-BFDF-C06BC78D5181@gmail.com>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
 <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
 <20201229231913.GR3625@brevard.conman.org>
 <B61C6C74-3331-4630-B404-3C207390668D@gmail.com>
 <20201229232820.GS3625@brevard.conman.org>
 <75670BD4-BAF1-4CC5-BFDF-C06BC78D5181@gmail.com>
Message-ID: <20201229235748.GT3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Dec 30, 2020, at 00:28, Sean Conner <sean at conman.org> wrote:
> > 
> >  Touch?.
> > 
> >  One task down, you have two left.
> 
> Right.
> 
> Second task: considering we cannot even agree what an URL is, ?20 years
> later, it's rather pointless to try with Gemini, where the concept is
> truly alien, "radical familiarity" notwithstanding. 



> Third task: wrap this* page. Hmmm. Why would I? What does it has to do
> *with anything? Is that a throw back from the textflow mega thread?

  No.  It's in reference to Solene's processing of UTF-8.  Some tasks,
processing UTF-8 is easy, others, not so much.  Since you seem to be on a
tear about UTF-8, I thought I might hand you one that isn't quite so
straightforwards.

> Long, uninterrupted sequences of random characters are not unique to
> Unicode. Or is the distinction between characters vs bytes? Then yes, it's
> 2020. Randomly chopping bytes is not appropriate indeed.

  Indeed.

  -spc

From petite.abeille at gmail.com  Wed Dec 30 00:05:33 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 01:05:33 +0100
Subject: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
In-Reply-To: <20201229235748.GT3625@brevard.conman.org>
References: <C83UQNGMB4T8.LZH4OC7KWJT3@stilgar>
 <2DF4A566-8B61-4C39-99ED-83D6E0BD4255@gmail.com>
 <18090E31-DEA1-41C6-88BC-5815FD6E4E6D@gmail.com>
 <20201229231913.GR3625@brevard.conman.org>
 <B61C6C74-3331-4630-B404-3C207390668D@gmail.com>
 <20201229232820.GS3625@brevard.conman.org>
 <75670BD4-BAF1-4CC5-BFDF-C06BC78D5181@gmail.com>
 <20201229235748.GT3625@brevard.conman.org>
Message-ID: <5D35E038-581E-453F-A9B0-81EFF90059A1@gmail.com>



> On Dec 30, 2020, at 00:57, Sean Conner <sean at conman.org> wrote:
> 
>  No.  It's in reference to Solene's processing of UTF-8.

She doesn't. No problem.

>  Some tasks,
> processing UTF-8 is easy, others, not so much.  Since you seem to be on a
> tear about UTF-8, I thought I might hand you one that isn't quite so
> straightforwards.

Meh. 

# openssl s_client -quiet -crlf -connect gemini.conman.org:1965 <<< gemini://gemini.conman.org/test/torture/0049 2>/dev/null | par

L?o?r?e?m?i?p?s?u?m?d?o?l?o?r?s?i?t?a?m?e?t?c?o?
n?s?e?c?t?e?t?u?r?a?d?i?p?i?s?c?i?n?g?e?l?i?t?I?
n?l?a?c?i?n?i?a?s?e?m?p?e?r?f?r?i?n?g?i?l?l?a?D?
o?n?e?c?v?e?h?i?c?u?l?a?f?e?r?m?e?n?t?u?m?m?a?x?
i?m?u?s?A?l?i?q?u?a?m?e?g?e?t?f?e?l?i?s?q?u?a?m?
C?r?a?s?e?g?e?t?u?l?l?a?m?c?o?r?p?e?r?n?u?n?c?S?
u?s?p?e?n?d?i?s?s?e?i?d?l?a?o?r?e?e?t?r?i?s?u?s?
U?t?a?e?r?o?s?m?i?M?a?u?r?i?s?a?l?o?r?e?m?p?o?s?
u?e?r?e?e?l?e?m?e?n?t?u?m?j?u?s?t?o?s?e?d?p?e?l?
l?e?n?t?e?s?q?u?e?q?u?a?m?A?e?n?e?a?n?s?a?g?i?t?
t?i?s?q?u?a?m?e?u?p?r?e?t?i?u?m?p?o?r?t?t?i?t?o?
r?I?n?n?e?c?s?e?m?a?e?n?i?m?v?e?h?i?c?u?l?a?f?a?
u?c?i?b?u?s?A?e?n?e?a?n?l?u?c?t?u?s?n?o?n?l?o?r?
e?m?a?c?b?l?a?n?d?i?t?I?n?t?e?g?e?r?t?i?n?c?i?d?
u?n?t?l?e?c?t?u?s?n?e?c?p?u?l?v?i?n?a?r?c?o?n?g?
u?e?e?s?t?e?n?i?m?p?h?a?r?e?t?r?a?l?i?b?e?r?o?u?
t?g?r?a?v?i?d?a?d?o?l?o?r?n?e?q?u?e?e?u?l?i?b?e?
r?o?P?r?a?e?s?e?n?t?r?i?s?u?s?e?s?t?p?o?s?u?e?r?
e?a?t?a?u?g?u?e?u?t?f?e?r?m?e?n?t?u?m?f?e?r?m?e?
n?t?u?m?t?o?r?t?o?r?D?o?n?e?c?a?t?n?u?l?l?a?v?i?
t?a?e?a?u?g?u?e?m?a?x?i?m?u?s?u?l?l?a?m?c?o?r?p?
e?r?N?u?l?l?a?m?p?r?e?t?i?u?m?a?n?t?e?e?t?n?i?s?
i?f?a?c?i?l?i?s?i?s?e?t?u?l?t?r?i?c?e?s?l?e?o?u?
l?l?a?m?c?o?r?p?e?r?M?o?r?b?i?s?i?t?a?m?e?t?l?a?
c?u?s?i?n?t?e?l?l?u?s?s?e?m?p?e?r?h?e?n?d?r?e?r?
i?t?v?e?l?v?e?n?e?n?a?t?i?s?j?u?s?t?o?N?u?l?l?a?
m?v?i?t?a?e?n?i?s?i?e?u?d?i?a?m?f?e?r?m?e?n?t?u?
m?c?o?n?v?a?l?l?i?s?N?u?n?c?o?d?i?o?r?i?s?u?s?p?
u?l?v?i?n?a?r?a?f?e?l?i?s?i?n?p?h?a?r?e?t?r?a?a?
l?i?q?u?e?t?m?a?g?n?a?F?u?s?c?e?e?g?e?t?a?l?i?q?
u?e?t?e?l?i?t?E?t?i?a?m?i?n?m?a?s?s?a?c?o?n?g?u?
e?n?e?q?u?e?o?r?n?a?r?e?p?e?l?l?e?n?t?e?s?q?u?e?
s?i?t?a?m?e?t?u?t?l?a?c?u?s?V?e?s?t?i?b?u?l?u?m?
e?u?t?i?n?c?i?d?u?n?t?n?i?s?l?n?e?c?a?l?i?q?u?a?
m?u?r?n?a?I?n?t?e?g?e?r?i?a?c?u?l?i?s?a?l?i?q?u?
a?m?l?o?r?e?m?n?o?n?f?r?i?n?g?i?l?l?a?N?u?l?l?a?
f?a?c?i?l?i?s?i?A?l?i?q?u?a?m?e?u?e?l?i?t?a?u?c?
t?o?r?v?i?v?e?r?r?a?m?a?s?s?a?e?u?f?r?i?n?g?i?l?
l?a?e?s?t?D?u?i?s?d?i?c?t?u?m?e?f?f?i?c?i?t?u?r?
t?e?m?p?u?s?V?e?s?t?i?b?u?l?u?m?n?u?l?l?a?t?o?r?
t?o?r?s?o?l?l?i?c?i?t?u?d?i?n?s?c?e?l?e?r?i?s?q?
u?e?l?i?g?u?l?a?i?d?b?l?a?n?d?i?t?e?f?f?i?c?i?t?
u?r?e?s?t?S?u?s?p?e?n?d?i?s?s?e?p?o?t?e?n?t?i?N?
u?l?l?a?m?a?x?i?m?u?s?s?o?l?l?i?c?i?t?u?d?i?n?s?
e?m?a?f?r?i?n?g?i?l?l?a?m?a?s?s?a?p?r?e?t?i?u?m?
r?h?o?n?c?u?s?N?u?l?l?a?d?i?c?t?u?m?v?e?s?t?i?b?
u?l?u?m?e?r?o?s?a?t?s?e?m?p?e?r?t?u?r?p?i?s?u?l?
t?r?i?c?i?e?s?n?o?n?I?n?d?i?a?m?q?u?a?m?e?l?e?m?
e?n?t?u?m?s?i?t?a?m?e?t?e?r?a?t?s?i?t?a?m?e?t?f?
e?r?m?e?n?t?u?m?p?u?l?v?i?n?a?r?s?a?p?i?e?n?V?i?
v?a?m?u?s?e?l?e?m?e?n?t?u?m?t?i?n?c?i?d?u?n?t?o?
r?c?i?e?l?e?m?e?n?t?u?m?l?a?o?r?e?e?t?m?a?g?n?a?
b?l?a?n?d?i?t?e?t?U?t?m?a?s?s?a?a?u?g?u?e?p?r?e?
t?i?u?m?q?u?i?s?a?u?g?u?e?s?e?d?u?l?t?r?i?c?i?e?
s?f?e?u?g?i?a?t?l?i?b?e?r?o?P?r?a?e?s?e?n?t?a?t?
f?e?u?g?i?a?t?q?u?a?m?I?n?t?e?g?e?r?p?o?s?u?e?r?
e?h?e?n?d?r?e?r?i?t?p?u?r?u?s?u?t?d?a?p?i?b?u?s?
q?u?a?m?v?a?r?i?u?s?a?c?Q?u?i?s?q?u?e?v?e?n?e?n?
a?t?i?s?d?o?l?o?r?a?t?e?l?l?u?s?r?h?o?n?c?u?s?v?
i?t?a?e?u?l?t?r?i?c?e?s?m?i?t?e?m?p?o?r?S?e?d?s?
e?d?v?i?v?e?r?r?a?i?p?s?u?m?V?i?v?a?m?u?s?e?u?n?
i?s?i?m?e?t?u?s?M?o?r?b?i?a?l?i?q?u?e?t?a?u?g?u?
e?n?o?n?m?a?u?r?i?s?t?i?n?c?i?d?u?n?t?a?u?c?t?o?
r?E?t?i?a?m?v?e?l?f?r?i?n?g?i?l?l?a?m?a?u?r?i?s?
C?u?r?a?b?i?t?u?r?e?g?e?t?d?o?l?o?r?d?o?l?o?r?N?
a?m?u?t?l?e?o?a?m?a?u?r?i?s?e?l?e?m?e?n?t?u?m?s?
a?g?i?t?t?i?s?I?n?v?e?l?p?u?r?u?s?a?q?u?a?m?i?n?
t?e?r?d?u?m?v?a?r?i?u?s?e?t?f?a?u?c?i?b?u?s?m?e?
t?u?s?S?u?s?p?e?n?d?i?s?s?e?s?i?t?a?m?e?t?a?r?c?
u?v?i?t?a?e?s?e?m?v?e?s?t?i?b?u?l?u?m?a?c?c?u?m?
s?a?n?V?i?v?a?m?u?s?e?l?i?t?v?e?l?i?t?l?u?c?t?u?
s?s?e?d?e?u?i?s?m?o?d?u?t?p?r?e?t?i?u?m?e?u?d?u?
i?D?o?n?e?c?m?o?l?e?s?t?i?e?l?e?c?t?u?s?i?d?s?o?
l?l?i?c?i?t?u?d?i?n?l?o?b?o?r?t?i?s?V?e?s?t?i?b?
u?l?u?m?g?r?a?v?i?d?a?m?a?u?r?i?s?m?a?x?i?m?u?s?
e?l?i?t?c?o?n?v?a?l?l?i?s?u?t?c?o?n?d?i?m?e?n?t?
u?m?d?i?a?m?p?o?s?u?e?r?e?S?e?d?v?e?l?e?l?e?m?e?
n?t?u?m?o?d?i?o?S?e?d?s?e?d?e?x?e?u?i?s?m?o?d?e?
l?e?i?f?e?n?d?n?u?n?c?u?l?l?a?m?c?o?r?p?e?r?f?e?
u?g?i?a?t?d?i?a?m?E?t?i?a?m?l?a?o?r?e?e?t?e?l?e?
m?e?n?t?u?m?e?r?o?s?a?c?t?i?n?c?i?d?u?n?t?S?e?d?
v?a?r?i?u?s?o?d?i?o?e?g?e?t?e?l?i?t?c?u?r?s?u?s?
i?n?s?o?l?l?i?c?i?t?u?d?i?n?a?n?t?e?v?e?h?i?c?u?
l?a?P?r?o?i?n?m?a?x?i?m?u?s?q?u?a?m?q?u?i?s?u?l?
l?a?m?c?o?r?p?e?r?m?a?t?t?i?s?V?i?v?a?m?u?s?v?a?
r?i?u?s?e?s?t?s?e?d?v?i?v?e?r?r?a?l?o?b?o?r?t?i?
s?S?e?d?f?e?u?g?i?a?t?s?c?e?l?e?r?i?s?q?u?e?u?l?
t?r?i?c?e?s?V?i?v?a?m?u?s?n?i?b?h?u?r?n?a?f?r?i?
n?g?i?l?l?a?m?a?t?t?i?s?m?i?a?m?o?l?e?s?t?i?e?p?
r?e?t?i?u?m?o?r?c?i?D?o?n?e?c?u?l?l?a?m?c?o?r?p?
e?r?e?r?a?t?e?l?i?t?s?i?t?a?m?e?t?p?e?l?l?e?n?t?
e?s?q?u?e?d?u?i?g?r?a?v?i?d?a?e?t?P?r?a?e?s?e?n?
t?h?e?n?d?r?e?r?i?t?m?o?l?e?s?t?i?e?m?a?g?n?a?e?
u?c?o?m?m?o?d?o?e?s?t?A?l?i?q?u?a?m?g?r?a?v?i?d?
a?e?r?o?s?s?c?e?l?e?r?i?s?q?u?e?a?r?c?u?f?e?u?g?
i?a?t?a?u?c?t?o?r?N?u?n?c?t?i?n?c?i?d?u?n?t?s?u?
s?c?i?p?i?t?s?c?e?l?e?r?i?s?q?u?e?M?o?r?b?i?s?e?
d?i?m?p?e?r?d?i?e?t?n?u?l?l?a?Q?u?i?s?q?u?e?e?u?
a?n?t?e?e?r?a?t?D?o?n?e?c?i?d?f?r?i?n?g?i?l?l?a?
v?e?l?i?t?s?i?t?a?m?e?t?i?a?c?u?l?i?s?m?a?u?r?i?
s?C?u?r?a?b?i?t?u?r?e?g?e?t?r?i?s?u?s?o?r?n?a?r?
e?f?i?n?i?b?u?s?d?u?i?u?t?o?r?n?a?r?e?s?e?m?I?n?
b?i?b?e?n?d?u?m?p?u?r?u?s?a?r?c?u?A?l?i?q?u?a?m?
s?o?l?l?i?c?i?t?u?d?i?n?t?u?r?p?i?s?e?g?e?t?r?i?
s?u?s?s?a?g?i?t?t?i?s?r?u?t?r?u?m?Q?u?i?s?q?u?e?
v?e?l?i?t?n?e?q?u?e?t?e?m?p?o?r?s?i?t?a?m?e?t?p?
u?l?v?i?n?a?r?s?e?d?t?i?n?c?i?d?u?n?t?n?e?c?e?l?
i?t?N?u?l?l?a?m?t?r?i?s?t?i?q?u?e?c?o?n?s?e?c?t?
e?t?u?r?a?n?t?e?e?g?e?t?v?a?r?i?u?s?a?r?c?u?c?o?
n?s?e?c?t?e?t?u?r?e?t?I?n?t?e?g?e?r?n?o?n?v?e?s?
t?i?b?u?l?u?m?l?i?g?u?l?a?v?u?l?p?u?t?a?t?e?a?l?
i?q?u?e?t?s?e?m?N?u?n?c?d?i?c?t?u?m?a?u?g?u?e?a?
d?i?a?m?d?i?c?t?u?m?a?t?p?o?r?t?a?a?n?t?e?b?i?b?
e?n?d?u?m?N?u?n?c?v?i?t?a?e?m?a?g?n?a?i?n?e?r?o?
s?s?c?e?l?e?r?i?s?q?u?e?g?r?a?v?i?d?a?a?c?a?a?u?
g?u?e?N?u?n?c?p?r?e?t?i?u?m?c?o?n?s?e?q?u?a?t?r?
i?s?u?s?V?i?v?a?m?u?s?a?o?r?c?i?l?i?g?u?l?a?M?o?
r?b?i?a?n?i?b?h?i?m?p?e?r?d?i?e?t?m?o?l?e?s?t?i?
e?e?x?e?u?c?o?m?m?o?d?o?n?i?s?l?P?h?a?s?e?l?l?u?
s?e?f?f?i?c?i?t?u?r?a?n?t?e?q?u?i?s?v?e?s?t?i?b?
u?l?u?m?l?a?o?r?e?e?t?U?t?f?r?i?n?g?i?l?l?a?n?u?
n?c?s?i?t?a?m?e?t?i?p?s?u?m?f?a?u?c?i?b?u?s?v?e?
n?e?n?a?t?i?s?F?u?s?c?e?m?a?t?t?i?s?q?u?i?s?j?u?
s?t?o?o?r?n?a?r?e?e?u?i?s?m?o?d?V?e?s?t?i?b?u?l?
u?m?e?u?s?a?p?i?e?n?v?o?l?u?t?p?a?t?c?o?m?m?o?d?



From benthor at posteo.de  Wed Dec 30 00:29:12 2020
From: benthor at posteo.de (benthor)
Date: Wed, 30 Dec 2020 01:29:12 +0100
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
Message-ID: <8735zonnl3.fsf@posteo.de>

Hi all,

I may have come up with a practical way to upload content to 
Gemini servers in-band, that is, speaking only valid Gemini 
(mostly) within the Gemini protocol specification.

The proposed mechanism allows a Gemini client to temporarily act 
as a Gemini server, with the Gemini server briefly playing the 
part of a Gemini client. Entirely within an otherwise standard 
Gemini transaction, a server and client can agree to swap roles, 
with the server then waiting for any content that the client may 
send (i.e., "upload") to the server.

Being in a sense, "reversed Gemini", I've decided to call this 
mechanism "Inimeg"[1].

Inimeg strictly follows the Gemini spec and only extends it in 
three respects:

* The "inimeg://" URL scheme, used by a Gemini client for an 
  Inimeg "upload" request
* The 7X range of status code, sent by a Gemini server in response 
  to an Inimeg request
* The Inimeg transaction, a Gemini transaction with partial role 
  reversal

I was careful not break or be in conflict with solarpunk's 
excellent Gemini spec. A heavily inspired "speculative 
specification" for Inimeg can be found at [2].

Do not hesitate to try out Inimeg in the open Playground, as 
mentioned in [1]. Much less work has gone into the crude server 
implementation[3] than the spec but it should serve to demonstrate 
the general idea. (Note that the same server process that hosts 
the spec [2] also hosts the playground, so please don't be too 
unfriendly with it. It should hold up to casual experimentation 
though.)

So. What do you think?

benthor

[1]: gemini://inimeg.space/
[2]: gemini://inimeg.space/specification.gmi
[3]: https://git.sr.ht/~benthor/lunokhod

(gemini://inimeg.space only speaks TLS 1.3 at the moment, I humbly 
apologize to the folks who are stuck with TLS 1.2)


From petite.abeille at gmail.com  Wed Dec 30 00:34:01 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 01:34:01 +0100
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <8735zonnl3.fsf@posteo.de>
References: <8735zonnl3.fsf@posteo.de>
Message-ID: <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>



> On Dec 30, 2020, at 01:29, benthor <benthor at posteo.de> wrote:
> 
> Being in a sense, "reversed Gemini", I've decided to call this mechanism "Inimeg"[1].

Fantastic idea :)

But I'm afraid Sean own that trademark already. The entire concept actually.

Search the archive, circa June 14th, something related to "Uploading Gemini content"



From sean at conman.org  Wed Dec 30 00:37:04 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 29 Dec 2020 19:37:04 -0500
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
Message-ID: <20201230003704.GU3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> > On Dec 30, 2020, at 01:29, benthor <benthor at posteo.de> wrote:
> > 
> > Being in a sense, "reversed Gemini", I've decided to call this mechanism
> > "Inimeg"[1].
> 
> Fantastic idea :)
> 
> But I'm afraid Sean own that trademark already. The entire concept
> actually.
> 
> Search the archive, circa June 14th, something related to "Uploading
> Gemini content"

  Specifically, this message:

	https://lists.orbitalfox.eu/archives/gemini/2020/001650.html

  -spc


From petite.abeille at gmail.com  Wed Dec 30 00:39:46 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 01:39:46 +0100
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <20201230003704.GU3625@brevard.conman.org>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org>
Message-ID: <1B67165E-9944-46B0-9245-1C9F2B06D925@gmail.com>



> On Dec 30, 2020, at 01:37, Sean Conner <sean at conman.org> wrote:
> 
> 	https://lists.orbitalfox.eu/archives/gemini/2020/001650.html

Still love the concept :)

Very simple, and very elegant: inverse the command flow. Pure Gemini. What is there not to like.


From stephen at drsudo.com  Wed Dec 30 00:44:15 2020
From: stephen at drsudo.com (Stephen)
Date: Tue, 29 Dec 2020 16:44:15 -0800
Subject: Hello all
In-Reply-To: <CAOouO1z72QC0TppydxEp_K583F6ADE2rTOKEMPFb4ROwq0chmQ@mail.gmail.com>
References: <CAOouO1z72QC0TppydxEp_K583F6ADE2rTOKEMPFb4ROwq0chmQ@mail.gmail.com>
Message-ID: <e4d5f126-0a0f-29ad-0532-131d2c1b62d2@drsudo.com>

Welcome Miguel,

> I am looking towards starting something on Gemini too yet I am not too 
> sure? wether I should do it on my own VPN server or what. I literally 
> set up my first www and gopher server last weekend and Im not confident 
> at installing from source.

If you already have a gopher server, then it should be easy to set up a 
gemini server on the same box. I would recommend solderpunk's Unsinkable 
Molly Brown. It is written in Go, so it is pretty easy to build. If you 
are unable to build it yourself, Go statically links its binaries, so 
you could perhaps ask someone to email you the binary.

https://tildegit.org/solderpunk/molly-brown

Feel free to email me directly if you have trouble.

~Stephen

From benthor at posteo.de  Wed Dec 30 01:28:06 2020
From: benthor at posteo.de (benthor)
Date: Wed, 30 Dec 2020 02:28:06 +0100
Subject: [tech] Proposed reversed Gemini for uploads to servers -
 Feedback wanted
In-Reply-To: <20201230003704.GU3625@brevard.conman.org>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org>
Message-ID: <87y2hgm6ah.fsf@posteo.de>


Sean Conner writes:
>   Specifically, this message:
>
> 	https://lists.orbitalfox.eu/archives/gemini/2020/001650.html
>
>   -spc

Fascinating thread! Now I'm angry with myself that I haven't gone 
far enough in time on the ML to find this. 

My consolation price is the knowledge, that all the stuff I came 
up with on my own is apparently not completely silly. I've added a 
"Credits" section to the site, mentioning your names and the 
thread.

Are you interested in fleshing this idea out a bit further with 
me? Anything you'd like to see changed in the speculative spec? I 
hope to at least contribute "inimeg.space" to the cause. (Oh how 
clever I felt when I came up with that one. Sigh.)

Cheers,
benthor

PS: Solderpunk, I apologize for calling you "solarpunk" 
earlier. *shakes head*



From pitr.vern at gmail.com  Wed Dec 30 02:31:06 2020
From: pitr.vern at gmail.com (Peter Vernigorov)
Date: Wed, 30 Dec 2020 03:31:06 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <48F3E961-33E3-4150-A7DA-2610ED694614@gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
 <48F3E961-33E3-4150-A7DA-2610ED694614@gmail.com>
Message-ID: <CAG-mZ3hT7f-NEre8be4o4MdpqyG_veZMSafg1fFH4ifos-dxag@mail.gmail.com>

On Wed, Dec 30, 2020 at 00:04 Petite Abeille <petite.abeille at gmail.com>
wrote:

>
>
> > On Dec 29, 2020, at 22:24, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> >
> > Looking at latest stats on
> > gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi it looks like
> > UTF-8 (this includes unspecified charsets which per spec default to
> > UTF-8) is used by 81% of pages, US-ASCII accounts for 17%.
>
> The actual numbers are as follow:
>
> ? Unspecified: 39628
> ? us-ascii: 9995
> ? utf-8: 7090
> ( 56,713 total)
>
> It's not clear if this pertain to the 36,477 text/gemini documents only,
> or the entire dataset (57,164 url vs. 56,713 encodings. 451 MIA).
>

Could you clarify which part is unclear to you here? 56,713 is, by design,
a strict /superset/ of 36k :)


> Looking at the numbers I guess it covers the entire data set as there are
> more 'Unspecified' than 'text/gemini' to start with.
>
> I'm not sure what these numbers mean at all, but they are not describing
> text/gemini.
>
> Not sure why we would draw any conclusion from them in regards to
> text/gemini.
>

While it?s true that the thread subject mentions text/gemini, the oft
quoted part of the spec is in section ?3.3 Response bodies? and talks about
any text/* responses. The only mention of charset in section 5 (which
describes text/gemini) is a reference to 3.3. Also, looking at stats of
either entire dataset or only text/gemini shows the same picture: utf-8 and
us-ascii account for ~99% of all charset values.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201230/ea7dac64/attachment.htm>

From sean at conman.org  Wed Dec 30 02:34:06 2020
From: sean at conman.org (Sean Conner)
Date: Tue, 29 Dec 2020 21:34:06 -0500
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <87y2hgm6ah.fsf@posteo.de>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
Message-ID: <20201230023406.GV3625@brevard.conman.org>

It was thus said that the Great benthor once stated:
> 
> Sean Conner writes:
> >  Specifically, this message:
> >
> >	https://lists.orbitalfox.eu/archives/gemini/2020/001650.html
> 
> Fascinating thread! Now I'm angry with myself that I haven't gone 
> far enough in time on the ML to find this. 

  There's also the titan: protocol:

	https://communitywiki.org/wiki/Titan

also an upload method for Gemini, and also originally an idea of mine (but
developed almost exclusively by Alex Schroeder).

There is also Dioscuri:

	gemini://rawtext.club/~sloum/geminilist/002792.gmi

  I have nothing to do with this one.  So there's quite a bit of interest
and work in this.

> Are you interested in fleshing this idea out a bit further with 
> me? Anything you'd like to see changed in the speculative spec? I 
> hope to at least contribute "inimeg.space" to the cause. (Oh how 
> clever I felt when I came up with that one. Sigh.)

  I'd like to at least read the spec, but I'm still stuck at TLS 1.2 until I
check out the newer LibreSSL library.  But at the very least, check out the
others methods as well.

  -spc

From alex at alexwennerberg.com  Wed Dec 30 05:20:30 2020
From: alex at alexwennerberg.com (alex wennerberg)
Date: Wed, 30 Dec 2020 05:20:30 GMT
Subject: [users] flounder.online updates
Message-ID: <C85USQYJ38ZG.2V9BBYFZSI1XF@localhost>

Hey all!

I posted a link to a project I was working on back in July, Flounder.

https://flounder.online/
gemini://flounder.online/

I wanted to make something that makes it easy for users who may not have
familiarity with SSH/FTP/Linux to set up a simple Gemini capsule and
log, accessible over Gemini and HTTP. I've made a lot of progress
that I wanted to update you all on if you're interested. Aside from a
rewrite from Rust to Go and some UI/UX improvements, I also added
(experimental) WebDAV support and built-in support for the newly-added
companion Gemini Feed specification, e.g.:

gemini://alex.flounder.online/gemlog
https://alex.flounder.online/gemlog

Flounder is still under active development, and there are a lot of
improvements I want to make, such as adding support for custom domains,
but it's much more usable than it was last time I updated the mailing
list about it. Feel free to make an account -- in order to cut down on
spam, I have to manually approve signups, but I usually get to that
within a few hours to a day. 

If anyone is interested in hosting Flounder, either as a single-user
instance or for others, please let me know! It shouldn't be too hard to
self-host and I can help you with any questions you may have. I'd also
gladly appreciate any patches.

https://sr.ht/~alexwennerberg/flounder/

And of course, this is 100% free, open source, etc. 

All the best,

Alex

From cowan at ccil.org  Wed Dec 30 05:48:11 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 30 Dec 2020 00:48:11 -0500
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <20201230023406.GV3625@brevard.conman.org>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
 <20201230023406.GV3625@brevard.conman.org>
Message-ID: <CAD2gp_SNkO7PwDQop6OXQwVUjdRX-qdyBq0bgqA4hhbWGLJyhA@mail.gmail.com>

On Tue, Dec 29, 2020 at 9:34 PM Sean Conner <sean at conman.org> wrote:


> There is also Dioscuri:
>
>         gemini://rawtext.club/~sloum/geminilist/002792.gmi
>

That is the original version and no longer current.  Please use
http://tinyurl.com/dioscuri-home instead; that address is permanent. Note
that Dioscuri is intended as a POST protocol rather than a PUT protocol.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
A: "Spiro conjectures Ex-Lax."
Q: "What does Pat Nixon frost her cakes with?"
  --"Jeopardy" for generative semanticists
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201230/404a9f79/attachment.htm>

From cowan at ccil.org  Wed Dec 30 06:35:42 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 30 Dec 2020 01:35:42 -0500
Subject: IETF policy on encodings and languages
In-Reply-To: <20201228091230.nomtkdkolsdckksi@gux>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
 <20201228091230.nomtkdkolsdckksi@gux>
Message-ID: <CAD2gp_TG3oaHMrOApjOnD24WFvjtCZH7CSyrMH8s+rkAovJA1Q@mail.gmail.com>

On Mon, Dec 28, 2020 at 4:12 AM Arav K. <nothien at uber.space> wrote:


> If the server has a Latin section, it is expected to have a complete
> Latin interface.


That makes very little sense to me.  It's true that www.vatican.va provides
a Latin user interface, but a site presenting English law is going to have
an English interface only, even though the older laws are in Latin or Old
Norman French.  *Nobody* needs an Old Norman French user interface.

Similarly, gutenberg.org provides only an English interface, even though it
provides e-books in 55 languages, from 37527 in English and 2356 in French
down to 21 languages with a single book each.  (There are other PG-like
sites in and for many countries; see the WP article.)

> Because we don't want the query string to be used as it is in HTML, i.e.
> for arbitrary parameters.  Using ?lang=<lang> is setting an arguably
> dangerous precedent.
>

I can't agree there either.  The only requirement in Gemini imposed on the
query string is that the URL sent after a 10 or 11 response contains
whatever the user entered as the query string.  There is nothing to prevent
link lines from containing query strings themselves.

In the Gemini PG interface I plan to write as soon as I have a chance, the
UI will be entirely in English, the only language I speak.  When you are
searching, you can include words in the query like "lang:en" or
"media:text/plain" or "author:Twain", as well as plain words in any script,
more or less like Google Search.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
All Gaul is divided into three parts: the part that cooks with lard and
goose
fat, the part that cooks with olive oil, and the part that cooks with
butter.
  --David Chessler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201230/05e5ba76/attachment-0001.htm>

From petite.abeille at gmail.com  Wed Dec 30 07:52:47 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 08:52:47 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <CAG-mZ3hT7f-NEre8be4o4MdpqyG_veZMSafg1fFH4ifos-dxag@mail.gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
 <48F3E961-33E3-4150-A7DA-2610ED694614@gmail.com>
 <CAG-mZ3hT7f-NEre8be4o4MdpqyG_veZMSafg1fFH4ifos-dxag@mail.gmail.com>
Message-ID: <2A6632CE-BFB4-4882-B246-4506966272A6@gmail.com>



> On Dec 30, 2020, at 03:31, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
> Could you clarify which part is unclear to you here? 56,713 is, by design, a strict /superset/ of 36k :)
> 

Math is hard, let's go shopping.

I'm sure it will all make sense at the very, very end.

From petite.abeille at gmail.com  Wed Dec 30 07:58:27 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 08:58:27 +0100
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <87y2hgm6ah.fsf@posteo.de>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
Message-ID: <016A26EE-1203-4D9E-8B65-D458D87D2BC7@gmail.com>



> On Dec 30, 2020, at 02:28, benthor <benthor at posteo.de> wrote:
> 
>  (Oh how clever I felt when I came up with that one. Sigh.)

My exact feeling every day: surely NO ONE must have thought of this :D

inimeg ftw!

> PS: Solderpunk, I apologize for calling you "solarpunk" earlier. *shakes head*

Haha. Good one :)


From petite.abeille at gmail.com  Wed Dec 30 08:09:37 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 09:09:37 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <CAG-mZ3hT7f-NEre8be4o4MdpqyG_veZMSafg1fFH4ifos-dxag@mail.gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
 <48F3E961-33E3-4150-A7DA-2610ED694614@gmail.com>
 <CAG-mZ3hT7f-NEre8be4o4MdpqyG_veZMSafg1fFH4ifos-dxag@mail.gmail.com>
Message-ID: <7B344C61-58A5-45E6-8F7B-8A76126BE8F7@gmail.com>



> On Dec 30, 2020, at 03:31, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
> , the oft quoted part of the spec is in section ?3.3 Response bodies? and talks about any text/* responses.

Ohhhh... right you are, I was assuming text/gemini only. My bad.

This sounds like a major overreach. Shouldn't Gemini restrict itself to just text/gemini as far as the Gemini spec goes?

On what ground would Gemini redefine what a text content type is?

A MIME content type of "text" is "text/plain; charset=us-ascii" by default. 

I don't quite see the point of redefining how a major piece of MIME is defined. Sounds counterproductive.




From petite.abeille at gmail.com  Wed Dec 30 08:24:40 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 09:24:40 +0100
Subject: [spec] Limit valid encodings of text/gemini to UTF-8
In-Reply-To: <CAG-mZ3hT7f-NEre8be4o4MdpqyG_veZMSafg1fFH4ifos-dxag@mail.gmail.com>
References: <1912300.0KG8479sM4@tempete> <C84GEN0Y07M0.18AADOVH5Y6CF@stilgar>
 <20201228233539.GO3625@brevard.conman.org>
 <021D368E-5AEC-4F76-BE10-7DDEE61430C7@gmail.com>
 <20201229090322.GP3625@brevard.conman.org>
 <788947AC-A0F2-4EBD-9B5B-96D787DF38B4@gmail.com>
 <CAG-mZ3hRYfHbiZL_jVerTdeoOujdZiWJWzbW_TRd5=o4QRZeLA@mail.gmail.com>
 <48F3E961-33E3-4150-A7DA-2610ED694614@gmail.com>
 <CAG-mZ3hT7f-NEre8be4o4MdpqyG_veZMSafg1fFH4ifos-dxag@mail.gmail.com>
Message-ID: <F591131A-6761-48EB-9364-C82786F6B930@gmail.com>



> On Dec 30, 2020, at 03:31, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> 
>  ?3.3 Response bodies? and talks about any text/* responses.

Actually, this is counterproductive, and wrong, technically speaking.

Consider the following response:

20 text/html
...

While HTML5 is UTF-8 by default, most vintage html is ISO-8859-1. And there is a lot of vintage to go around.

Defaulting to UTF-8 for all of text/* at large would break the interweb as we know it.

Why take on such burden? 

Perhaps best to narrow the spec to only speak about text/gemini. 

Other text/* media types have their own idiosyncrasies. Best to leave them alone.

?2?


From nothien at uber.space  Wed Dec 30 08:25:36 2020
From: nothien at uber.space (nothien at uber.space)
Date: Wed, 30 Dec 2020 09:25:36 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_TG3oaHMrOApjOnD24WFvjtCZH7CSyrMH8s+rkAovJA1Q@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
 <20201228091230.nomtkdkolsdckksi@gux>
 <CAD2gp_TG3oaHMrOApjOnD24WFvjtCZH7CSyrMH8s+rkAovJA1Q@mail.gmail.com>
Message-ID: <36Y8S55QM3VDK.2W6PHM76TFYIC@nothien.uber.space>

John Cowan <cowan at ccil.org> wrote:
> That makes very little sense to me.  It's true that www.vatican.va
> provides a Latin user interface, but a site presenting English law is
> going to have an English interface only, even though the older laws
> are in Latin or Old Norman French.  *Nobody* needs an Old Norman
> French user interface.

Sorry, I wasn't clear.  When I said "Latin section", I meant "section
meant for Latin users".  The site you're talking about isn't meant for
Latin-speaking users, so it doesn't have a Latin interface.  That's
perfectly fine.

> Similarly, gutenberg.org provides only an English interface, even
> though it provides e-books in 55 languages, from 37527 in English and
> 2356 in French down to 21 languages with a single book each.  (There
> are other PG-like sites in and for many countries; see the WP
> article.)

One example doesn't make the rule.  I would argue that Project Gutenberg
_should_ have interfaces in other languages, because it is offering
(some) content that is almost exclusively going to be consumed by people
speaking (possibly only) these other languages.  I'm assuming that not
that many monolingual English speakers/readers are reading those 2,356
French books - Mainly French-speaking people are reading those books,
and a French interface should be made available to them.  I can
understand, however, that PG doesn't currently have the resources to
translate its interface.  But that doesn't mean that it should not be a
goal.

> I can't agree there either.  The only requirement in Gemini imposed on
> the query string is that the URL sent after a 10 or 11 response
> contains whatever the user entered as the query string.  There is
> nothing to prevent link lines from containing query strings
> themselves.

We're talking about different things.  I'm not talking about link lines
and query strings.  My point of contention is the use of HTML-style
(<key>=<value>)* formatting for query strings.

> In the Gemini PG interface I plan to write as soon as I have a chance,
> the UI will be entirely in English, the only language I speak.  When
> you are searching, you can include words in the query like "lang:en"
> or "media:text/plain" or "author:Twain", as well as plain words in any
> script, more or less like Google Search.

That makes perfect sense: you only speak English, you only design
English interfaces.  I have absolutely no problem with that.  But you
should at least open up the possibility of having other interfaces, even
if you don't write them yourself.  Non-English-readers will thank you
for it.

~aravk | ~nothien

From petite.abeille at gmail.com  Wed Dec 30 08:59:02 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 09:59:02 +0100
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <20201230023406.GV3625@brevard.conman.org>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
 <20201230023406.GV3625@brevard.conman.org>
Message-ID: <F9A81B3B-118E-4A4B-A9AB-527764AD997E@gmail.com>



> On Dec 30, 2020, at 03:34, Sean Conner <sean at conman.org> wrote:
> 
> but I'm still stuck at TLS 1.2 until I check out the newer LibreSSL library. 

Perhaps take a look at "[gentoo-dev] [RFC] Discontinuing LibreSSL support?". Fascinating dynamic.




From petite.abeille at gmail.com  Wed Dec 30 09:30:25 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 10:30:25 +0100
Subject: [tech] default response?
Message-ID: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>

Is this a valid response? Just 2, followed by text/gemini content?

2
...
<eof>

In other words: ? 2 ? 20 ? text/gemini ? text/gemini;charset=utf-8

Kosher?




From op at omarpolo.com  Wed Dec 30 10:58:40 2020
From: op at omarpolo.com (Omar Polo)
Date: Wed, 30 Dec 2020 11:58:40 +0100
Subject: [tech] default response?
In-Reply-To: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>
References: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>
Message-ID: <87h7o3h867.fsf@omarpolo.com>


Petite Abeille <petite.abeille at gmail.com> writes:

> Is this a valid response? Just 2, followed by text/gemini content?
>
> 2
> ...
> <eof>
>
> In other words: ? 2 ? 20 ? text/gemini ? text/gemini;charset=utf-8
>
> Kosher?

gemini://gemini.circumlunar.space/docs/specification.gmi

> Gemini response headers look like this:
>
> <STATUS><SPACE><META><CR><LF>
>
> <STATUS> is a two-digit numeric status code, as described below in 3.2 and in
> Appendix 1.

So it isn't allowed by the spec and, personally, I don't see how
allowing single-digit response could be a good idea.

From petite.abeille at gmail.com  Wed Dec 30 11:48:48 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 12:48:48 +0100
Subject: [tech] default response?
In-Reply-To: <87h7o3h867.fsf@omarpolo.com>
References: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>
 <87h7o3h867.fsf@omarpolo.com>
Message-ID: <F81CC939-4B5F-4992-85B8-328682106843@gmail.com>



> On Dec 30, 2020, at 11:58, Omar Polo <op at omarpolo.com> wrote:
> 
> So it isn't allowed by the spec and, personally, I don't see how
> allowing single-digit response could be a good idea.

Right. So, no more 1 digit response code (i.e. generic success "2" use to be a thing), and no more default content-type (i.e. text/gemini).

So a minimal valid response would be:

20 text/gemini
...
<eof>

Correct?


From petite.abeille at gmail.com  Wed Dec 30 11:54:36 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 12:54:36 +0100
Subject: [tech] default response?
In-Reply-To: <F81CC939-4B5F-4992-85B8-328682106843@gmail.com>
References: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>
 <87h7o3h867.fsf@omarpolo.com>
 <F81CC939-4B5F-4992-85B8-328682106843@gmail.com>
Message-ID: <120C420A-8FAF-4F30-AF63-9914D762A8BC@gmail.com>



> On Dec 30, 2020, at 12:48, Petite Abeille <petite.abeille at gmail.com> wrote:
> 
> So a minimal valid response would be:
> 
> 20 text/gemini

Actually:

20 text
<eof>

No need for a subtype.

Would that be the minimal viable response? 

From op at omarpolo.com  Wed Dec 30 11:55:55 2020
From: op at omarpolo.com (Omar Polo)
Date: Wed, 30 Dec 2020 12:55:55 +0100
Subject: [tech] default response?
In-Reply-To: <F81CC939-4B5F-4992-85B8-328682106843@gmail.com>
References: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>
 <87h7o3h867.fsf@omarpolo.com>
 <F81CC939-4B5F-4992-85B8-328682106843@gmail.com>
Message-ID: <87blebh5is.fsf@omarpolo.com>


Petite Abeille <petite.abeille at gmail.com> writes:

>> On Dec 30, 2020, at 11:58, Omar Polo <op at omarpolo.com> wrote:
>> 
>> So it isn't allowed by the spec and, personally, I don't see how
>> allowing single-digit response could be a good idea.
>
> Right. So, no more 1 digit response code (i.e. generic success "2" use to be a thing), and no more default content-type (i.e. text/gemini).

I recall reading a mail from solderpunk (or maybe was someone else)
regarding the fact that initially the codes were one digit only.  Now
two are mandatory.

> So a minimal valid response would be:
>
> 20 text/gemini
> ...
> <eof>
>
> Correct?

Yup.  (btw, that's how my server replies to every request for gemini
files, since charset=utf-8 seems to be redundant.)

From op at omarpolo.com  Wed Dec 30 12:13:26 2020
From: op at omarpolo.com (Omar Polo)
Date: Wed, 30 Dec 2020 13:13:26 +0100
Subject: [tech] default response?
In-Reply-To: <120C420A-8FAF-4F30-AF63-9914D762A8BC@gmail.com>
References: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>
 <87h7o3h867.fsf@omarpolo.com>
 <F81CC939-4B5F-4992-85B8-328682106843@gmail.com>
 <120C420A-8FAF-4F30-AF63-9914D762A8BC@gmail.com>
Message-ID: <878s9fh4pl.fsf@omarpolo.com>


Petite Abeille <petite.abeille at gmail.com> writes:

>> On Dec 30, 2020, at 12:48, Petite Abeille <petite.abeille at gmail.com> wrote:
>> 
>> So a minimal valid response would be:
>> 
>> 20 text/gemini
>
> Actually:
>
> 20 text
> <eof>
>
> No need for a subtype.

is it still valid?  Mind you, I am pretty ignorant regarding various
standards, but a quick look at RFC2045, section 5.1 "Syntax of the
Content-Type Header Field" seems to mark the subtype as required.

Also "grammar" in the wikipedia page[0] mark the subtype as required:
>type "/" [tree "."] subtype ["+" suffix] *[";" parameter]

I'm missing something?

> Would that be the minimal viable response?

To be fair, with the *current* specification

20\r\n
<eof>

is the minimal response allowed, since the spec still has the phrase:

> If <META> is an empty string, the MIME type MUST default to
> "text/gemini; charset=utf-8".  The text/gemini media type is defined
> in section 5.

but that's gonna be removed in a while (or at least is the impression I
got from the other thread).

I'm curios though, why are you trying to define the "smallest possible
response?"

[0]: https://en.wikipedia.org/wiki/Media_type

From petite.abeille at gmail.com  Wed Dec 30 12:52:50 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 13:52:50 +0100
Subject: [tech] default response?
In-Reply-To: <878s9fh4pl.fsf@omarpolo.com>
References: <F158D517-BD6B-4CD8-99D1-BD2AF8469E49@gmail.com>
 <87h7o3h867.fsf@omarpolo.com>
 <F81CC939-4B5F-4992-85B8-328682106843@gmail.com>
 <120C420A-8FAF-4F30-AF63-9914D762A8BC@gmail.com>
 <878s9fh4pl.fsf@omarpolo.com>
Message-ID: <58B220D7-FA26-479C-8767-91CDAF4388E5@gmail.com>



> On Dec 30, 2020, at 13:13, Omar Polo <op at omarpolo.com> wrote:
> 
> is it still valid?  

Ah, actually, you are right, the subtype is required now (thought old style MIME had it optional).

So text/* as a minimum I guess.

> 
> To be fair, with the *current* specification
> 
> 20\r\n
> <eof>
> 
> is the minimal response allowed, since the spec still has the phrase:

There you go. So my first example then, plus two digits code.

> but that's gonna be removed in a while (or at least is the impression I
> got from the other thread).

Is that so? Lost track over time.

> I'm curios though, why are you trying to define the "smallest possible
> response?"

Well, to flush out all such questions, and know what to expect at a very minimum :)

Which, as of today is:

20\r\n
<eof>

I.e. an empty text/gemini;charset=utf-8 response.




From benthor at posteo.de  Wed Dec 30 16:50:39 2020
From: benthor at posteo.de (benthor)
Date: Wed, 30 Dec 2020 17:50:39 +0100
Subject: [tech] Proposed reversed Gemini for uploads to servers -
 Feedback wanted
In-Reply-To: <20201230023406.GV3625@brevard.conman.org>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
 <20201230023406.GV3625@brevard.conman.org>
Message-ID: <87v9cjme5c.fsf@posteo.de>

Sean Conner writes:
>   There's also the titan: protocol:
>
> 	https://communitywiki.org/wiki/Titan
>
> also an upload method for Gemini, and also originally an idea of 
> mine (but
> developed almost exclusively by Alex Schroeder).

Very interesting. If I understand 
gemini://communitywiki.org/page/Titan correctly, the following 
should have worked:

     echo -en 
     "titan://communitywiki.org/raw/Test;token=hello;mime=text/plain;size=12\r\nHello 
     World\n" | socat - ssl:communitywiki.org:1965,verify=0

However, gemini://communitywiki.org/page/Test remained empty. Even 
after creating the page via the http interface, I couldn't update 
it. In general, I am not sure whether the token requirement 
couldn't be dropped in favor of exclusively client 
certificate-based authentication.

> There is also Dioscuri:
>
> 	gemini://rawtext.club/~sloum/geminilist/002792.gmi
>
>   I have nothing to do with this one.  So there's quite a bit of 
>   interest
> and work in this.

Oh, I like this approach! Unfortunately the Gemini version of that 
page is a bit taxing to read due to issues with newline 
conversion. Here is the HTML version for anyone who is interested:

      https://lists.orbitalfox.eu/archives/gemini/2020/002792.html

Does anyone know whether at least a toy implementation of this 
already exists? The ML thread seems to have derailed pretty 
quickly unfortunately...


>   I'd like to at least read the spec, but I'm still stuck at TLS 
>   1.2 until I
> check out the newer LibreSSL library.  But at the very least, 
> check out the
> others methods as well.

Could you check again if you can access the site? It's now using a 
taditional ECDSA certificate instead of the previous newfangled 
ED25519 cert.

      gemini://inimeg.space

benthor


From kiba.fox at foxypossibilities.com  Wed Dec 30 17:28:59 2020
From: kiba.fox at foxypossibilities.com (Kiba Fox)
Date: Wed, 30 Dec 2020 12:28:59 -0500
Subject: [user] new capsule
In-Reply-To: <82k0t08ny2.fsf@nassur.net>
References: <82mtxx80b4.fsf@nassur.net>
 <e9600b11-74da-e13a-6c15-e1cdbcdad70e@foxypossibilities.com>
 <82k0t08ny2.fsf@nassur.net>
Message-ID: <7a544b99-f2a3-8054-24fe-5d5ff16d62b6@foxypossibilities.com>

On 12/29/20 1:30 PM, ew.gemini wrote:
> I'm using emacs/elpher, however, emacs is running in window
> mode on i3.
> 
> I'm also using kristall to experiment with gemini behind an
> onion service (using torify).

Thank you! I will have to check those out.

-- 
Kind regards,
Kiba

From nervuri at disroot.org  Wed Dec 30 18:56:32 2020
From: nervuri at disroot.org (nervuri)
Date: Wed, 30 Dec 2020 18:56:32 +0000
Subject: [tech] [spec] TLS statistics
Message-ID: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>

Hi,

I recently gathered TLS-related statistics on Gemini servers, using a few shell scripts and OpenSSL. You'll find everything here:

https://gitlab.com/nervuri/gemini-stats

Among other things, the repo contains:
* data/certs/ - all certificates for servers listed by GUS
* data/ip/ip-hosts - ip & hostname pairs compatible with the OS's hosts file
* cipher-suites.md - stats on TLSv1.2 cipher suites supported by Gemini servers

Highlights:

* 422 hosts total
* 394 hosts functional
* 258 hosts remaining after eliminating subdomains with identical TLS configs (flounder.online has 107)

* 2 IPv6-only hosts

* all hosts support TLSv1.2
* 151 (59%) support TLSv1.3
* 107 (41%) do not support TLSv1.3
* 40 support TLSv1.1
* 39 support TLSv1.0

* 66 certs are signed by Let's Encrypt
* 35 pass OpenSSL validation
* 359 fail OpenSSL validation (not signed by a trusted CA, expired, etc)

* 347 serve a single cert
*  47 also serve an intermediate cert

## Public Key Algorithm

*   1 : ED25519
* 180 : ECDSA ( including flounder.online - 107 hosts )
* 213 : RSA

## Key size

*   1 : ED25519 Public-Key: (256 bit)
* 164 : ECDSA Public-Key: (256 bit) ( including flounder.online - 107 hosts )
*  15 : ECDSA Public-Key: (384 bit)
*   1 : ECDSA Public-Key: (521 bit)
*   1 : RSA Public-Key: (1024 bit)
* 102 : RSA Public-Key: (2048 bit)
* 110 : RSA Public-Key: (4096 bit)

## Expiration

### Not Before

*   1 : Not Before 1975
*   6 : Not Before 2019
* 387 : Not Before 2020 ( including flounder.online - 107 hosts )

### Not After

*   1 : Not After 2018
*   2 : Not After 2019
*  30 : Not After 2020
* 247 : Not After 2021 ( including flounder.online - 107 hosts )
*   2 : Not After 2022
*   6 : Not After 2023
*   2 : Not After 2024
*  56 : Not After 2025
*   1 : ...
*  38 : Not After 2030
*   6 : ...
*   3 : Not After 9999

-------------

These are the stats I find most interesting, but check the repo for more details. Let me know if I messed up somewhere.

I was especially interested in TLS 1.3 support. From the spec it seems like you're looking forward to getting rid of TLS 1.2, but is there a plan for that? Currently over 100 servers do not support 1.3.

  > Hopefully TLS 1.3 or higher can be specced in the near future. Clients who wish to be "ahead of the curve MAY refuse to connect to servers using TLS version 1.2 or lower.

As far as I know, with TLSv1.2 client certs are sent in the clear, revealing login information to the ISP (and whoever else is looking). In this respect, when used with TLS 1.2, client certs are worse than cookies. Also, 1.2 isn't compatible with encrypted SNI. So I hope it will be phased out soon, if possible. Let me know your thoughts.

Cheers!

From stephen at drsudo.com  Wed Dec 30 19:19:22 2020
From: stephen at drsudo.com (Stephen)
Date: Wed, 30 Dec 2020 11:19:22 -0800
Subject: [tech] [spec] TLS statistics
In-Reply-To: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
References: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
Message-ID: <231a7b74-b230-c2d3-8884-3f8de102eb76@drsudo.com>


> * 66 certs are signed by Let's Encrypt
> * 35 pass OpenSSL validation
> * 359 fail OpenSSL validation (not signed by a trusted CA, expired, etc)

66 is more Let's Encrypt certs than I would have guessed. For better or 
worse, they seem a bit out of place in gemini. When I was setting up my 
server, I was almost going to use my Let's Encrypt cert, but I'm glad I 
didn't. The Let's Encrypt method is antithetical to the TOFU model of 
certs. Using a trusted CA is irrelevant and regularly updating your 
certs (often a month in advance of expiry) is not good with TOFU.

> *   3 : Not After 9999

I wish I had gone this way. I think with TOFU this is the only sane way 
(essentially same as ssh host keys).

~Stephen

From colecmac at protonmail.com  Wed Dec 30 19:44:09 2020
From: colecmac at protonmail.com (colecmac at protonmail.com)
Date: Wed, 30 Dec 2020 19:44:09 +0000
Subject: [tech] [spec] TLS statistics
In-Reply-To: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
References: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
Message-ID: <SWxgIpNfZOmIQCIdHnliYu_bt4mrOE7skKWaWGMEC_2I5P2WUI4LuF7r5PU099CkTkpS-Op2_HoQVbNj97tO4qiVqIJxSc4477T-HNmGlAA=@protonmail.com>

> * 40 support TLSv1.1
> * 39 support TLSv1.0

This was the most surprising/concerning part to me. These servers are
breaking the spec, and my understanding is that TLS 1.0 is considered
insecure by experts. I'm less sure about how insecure 1.1 is, but I know
that it's deprecated in all main browsers by now.

Do you have any idea what server software is allowing this? Maybe you can
look at the capsules, as some will say what software they use. That way
someone can file a bug or submit a patch/PR.


makeworld

From cowan at ccil.org  Wed Dec 30 20:26:33 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 30 Dec 2020 15:26:33 -0500
Subject: IETF policy on encodings and languages
In-Reply-To: <36Y8S55QM3VDK.2W6PHM76TFYIC@nothien.uber.space>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
 <20201228091230.nomtkdkolsdckksi@gux>
 <CAD2gp_TG3oaHMrOApjOnD24WFvjtCZH7CSyrMH8s+rkAovJA1Q@mail.gmail.com>
 <36Y8S55QM3VDK.2W6PHM76TFYIC@nothien.uber.space>
Message-ID: <CAD2gp_Sgwb3z9WhP1rHcUs_LQVXkAigLuP+nkmPeWOotrUy5fg@mail.gmail.com>

On Wed, Dec 30, 2020 at 3:25 AM <nothien at uber.space> wrote:

Sorry, I wasn't clear.  When I said "Latin section", I meant "section
> meant for Latin users".  The site you're talking about isn't meant for
> Latin-speaking users, so it doesn't have a Latin interface.  That's
> perfectly fine.
>

Ah, okay.

> One example doesn't make the rule.  I would argue that Project Gutenberg
> _should_ have interfaces in other languages, because it is offering
> (some) content that is almost exclusively going to be consumed by people
> speaking (possibly only) these other languages.


Up to a point, certainly.  The tail end of languages probably don't need
interfaces.

> We're talking about different things.  I'm not talking about link lines
> and query strings.  My point of contention is the use of HTML-style
> (<key>=<value>)* formatting for query strings.
>

Suppose you have written an essay in French on the novels of Jules Verne in
text/gemini format, and you want to link to a collection of the novels
themselves.  You can then insert this link line:

=> gemini://
gemguten.example.com/advsearch.gmi?lang=fr&author=Jules&author=Verne Les
oeuvres de Jules Verne en fran?ais

The user who selects this link will receive a text/gemini document,
something like this:

=> gemini://gemguten.example.com/etext/5082 Verne, Jules, 1828-1905. Le
chate?u des Carpathe. [fr]
=> gemini://gemguten.example.com/etext/8174 Verne, Jules, 1828-1905.
K?raban-Le-T?tu, Volume I. [fr]
=> gemini://gemguten.example.com/etext/17832 Verne, Jules, 1828-1905. Une
ville flottante. [fr]
...

Since this is not an _interactive_ search, the Gemini conventions about
status 1x and the query string don't apply.

But you
> should at least open up the possibility of having other interfaces, even
> if you don't write them yourself.  Non-English-readers will thank you
> for it.
>

Absolutely.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
If I have not seen as far as other giants, it?s because I have been
standing on my head.  --Trond Engen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201230/4c0c71fa/attachment-0001.htm>

From thededem at eulenzombie.de  Wed Dec 30 21:50:18 2020
From: thededem at eulenzombie.de (thededem)
Date: Wed, 30 Dec 2020 22:50:18 +0100
Subject: [tech][ANN] LC19 - A USCPI gemini server
Message-ID: <9ee1f60a-31f9-b2a3-7930-d82dbe908491@eulenzombie.de>

Hello Geminauts,

just wanted to announce LC19, a simple Gemini "server" in written in C
following the USCPI[1] model (LC19 itself does not deal with TCP or TLS,
but only reads on stdin and writes to stdout).

Currently it can only serve static files, but CGI support may come in
the future, when I find the time.

You can find the code here
    https://git.sr.ht/~thededem/lc19
and here
    gemini://gemini.thededem.de/lc19/

The gemini capsule is served by LC19, using the tools from
s6-networking[2] for handling TCP and TLS.

Cheers,
thededem


[1] http://cr.yp.to/proto/ucspi.txt
[2] https://skarnet.org/software/s6-networking/

From petite.abeille at gmail.com  Wed Dec 30 22:06:28 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 23:06:28 +0100
Subject: [tech][ANN] LC19 - A USCPI gemini server
In-Reply-To: <9ee1f60a-31f9-b2a3-7930-d82dbe908491@eulenzombie.de>
References: <9ee1f60a-31f9-b2a3-7930-d82dbe908491@eulenzombie.de>
Message-ID: <B84C2A17-0471-4AFA-981E-1489BA78E70B@gmail.com>



> On Dec 30, 2020, at 22:50, thededem <thededem at eulenzombie.de> wrote:
> 
> USCPI

Nice. What do you use for SSL?


From thededem at eulenzombie.de  Wed Dec 30 22:10:03 2020
From: thededem at eulenzombie.de (thededem)
Date: Wed, 30 Dec 2020 23:10:03 +0100
Subject: [tech][ANN] LC19 - A USCPI gemini server
In-Reply-To: <B84C2A17-0471-4AFA-981E-1489BA78E70B@gmail.com>
References: <9ee1f60a-31f9-b2a3-7930-d82dbe908491@eulenzombie.de>
 <B84C2A17-0471-4AFA-981E-1489BA78E70B@gmail.com>
Message-ID: <f825b0bc-278c-6728-e58e-1034f34e4614@eulenzombie.de>

On 30.12.20 23:06, Petite Abeille wrote:
>> On Dec 30, 2020, at 22:50, thededem <thededem at eulenzombie.de> wrote:
>>
>> USCPI
> 
> Nice. What do you use for SSL?
I use s6-tlsserver[1] from s6-networking, compiled with LibreSSL.

[1] https://skarnet.org/software/s6-networking/s6-tlsserver.html

From nervuri at disroot.org  Wed Dec 30 22:15:11 2020
From: nervuri at disroot.org (nervuri)
Date: Wed, 30 Dec 2020 22:15:11 +0000
Subject: [tech] [spec] TLS statistics
In-Reply-To: <SWxgIpNfZOmIQCIdHnliYu_bt4mrOE7skKWaWGMEC_2I5P2WUI4LuF7r5PU099CkTkpS-Op2_HoQVbNj97tO4qiVqIJxSc4477T-HNmGlAA=@protonmail.com>
References: <SWxgIpNfZOmIQCIdHnliYu_bt4mrOE7skKWaWGMEC_2I5P2WUI4LuF7r5PU099CkTkpS-Op2_HoQVbNj97tO4qiVqIJxSc4477T-HNmGlAA=@protonmail.com>
 <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
Message-ID: <cbd574117b113284ed8e456dd96d4bc2@disroot.org>

December 30, 2020 7:19 PM, Stephen wrote:
  > 66 is more Let's Encrypt certs than I would have guessed.

What's strange to me is that 31 of those fail validation. It might be interesting to see why.

By the way, Lupa lists 68 Let's Encrypt certs:

gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

Also, Lupa knows about 528 hosts, more than GUS's 442. I wish it listed them.

  > For better or worse, they seem a bit out of place in gemini. When I was setting up my server, I was almost going to use my Let's Encrypt cert, but I'm glad I didn't. The Let's Encrypt method is antithetical to the TOFU model of certs. Using a trusted CA is irrelevant and regularly updating your certs (often a month in advance of expiry) is not good with TOFU.

There is value in a third party attesting that a specific cert belongs to a specific domain. I would like a Gemini browser to do TOFU for self-signed certs and normal validation for CA-signed certs - and let me know when I'm dealing with the latter. There is more to say on this, I might elaborate at some point.

  December 30, 2020 7:44 PM, colecmac wrote:
  > Do you have any idea what server software is allowing this? Maybe you can
look at the capsules, as some will say what software they use. That way
someone can file a bug or submit a patch/PR.

This kind of thing will always be an issue. The barrier to entry is low, so we can expect problematic server implementations to keep popping up.

I did check out *.lanterne.chilliet.eu and it looks like it's using a self-made server written in PHP. I'll submit an issue one of these days, if someone doesn't do it before me.

gemini://gemlog.lanterne.chilliet.eu/softwares.en.gmi
https://framagit.org/MCMic/gemini-server

As for the others... here are the hosts:

```
cat data/tls/tls-versions | grep tls1_1

cadence.moe | -tls1_2 -tls1_1 -tls1
code.lanterne.chilliet.eu | -tls1_2 -tls1_1 -tls1
consensus.circumlunar.space | -tls1_2 -tls1_1 -tls1
cyberpunksin.space | -tls1_3 -tls1_2 -tls1_1 -tls1
dioskouroi.xyz | -tls1_2 -tls1_1 -tls1
ftrv.se | -tls1_3 -tls1_2 -tls1_1 -tls1
gem.johanbove.info | -tls1_3 -tls1_2 -tls1_1 -tls1
gemini-textboard.fgaz.me | -tls1_3 -tls1_2 -tls1_1 -tls1
gemini.cycrad.io | -tls1_3 -tls1_2 -tls1_1 -tls1
gemini.sirodoht.com | -tls1_3 -tls1_2 -tls1_1 -tls1
gemini.slashdev.space | -tls1_2 -tls1_1 -tls1
gemini.thebackupbox.net | -tls1_3 -tls1_2 -tls1_1 -tls1
gemini.thegonz.net | -tls1_3 -tls1_2 -tls1_1 -tls1
gemini.ucant.org | -tls1_2 -tls1_1 -tls1
gemini.uxq.ch | -tls1_3 -tls1_2 -tls1_1 -tls1
gemini.uxw.ch | -tls1_3 -tls1_2 -tls1_1 -tls1
gemlog.lanterne.chilliet.eu | -tls1_2 -tls1_1 -tls1
gsthnz.com | -tls1_3 -tls1_2 -tls1_1 -tls1
hacktivis.me | -tls1_3 -tls1_2 -tls1_1 -tls1
happycreature.org | -tls1_3 -tls1_2 -tls1_1 -tls1
heavysquare.com | -tls1_3 -tls1_2 -tls1_1 -tls1
houston.coder.town | -tls1_3 -tls1_2 -tls1_1 -tls1
iim.gay | -tls1_3 -tls1_2 -tls1_1 -tls1
jfh.me | -tls1_2 -tls1_1 -tls1
kamalatta.ddnss.de | -tls1_2 -tls1_1 -tls1
kwiecien.us | -tls1_3 -tls1_2 -tls1_1 -tls1
lord.re | -tls1_3 -tls1_2 -tls1_1 -tls1
nixo.xyz | -tls1_3 -tls1_2 -tls1_1 -tls1
ols.wtf | -tls1_3 -tls1_2 -tls1_1 -tls1
posixcafe.org | -tls1_2 -tls1_1 -tls1
rainbow-100.com | -tls1_3 -tls1_2 -tls1_1 -tls1
rocketnine.space | -tls1_3 -tls1_2 -tls1_1 -tls1
rwv.io | -tls1_3 -tls1_2 -tls1_1 -tls1
saintnet.tech | -tls1_3 -tls1_2 -tls1_1 -tls1
sanctum.geek.nz | -tls1_2 -tls1_1 -tls1
sdf.org | -tls1_3 -tls1_2 -tls1_1 -tls1
stanner.bayern | -tls1_3 -tls1_2 -tls1_1 -tls1
thebackupbox.net | -tls1_3 -tls1_2 -tls1_1 -tls1
tictactoe.lanterne.chilliet.eu | -tls1_2 -tls1_1 -tls1
trfs.me | -tls1_3 -tls1_2 -tls1_1
tweek.zyxxyz.eu | -tls1_3 -tls1_2 -tls1_1 -tls1
twins.rocketnine.space | -tls1_3 -tls1_2 -tls1_1 -tls1
typed-hole.org | -tls1_2 -tls1_1 -tls1
vignette.kalasarn.se | -tls1_3 -tls1_2 -tls1_1 -tls1
```

From nothien at uber.space  Wed Dec 30 22:16:24 2020
From: nothien at uber.space (nothien at uber.space)
Date: Wed, 30 Dec 2020 23:16:24 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_Sgwb3z9WhP1rHcUs_LQVXkAigLuP+nkmPeWOotrUy5fg@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
 <20201228091230.nomtkdkolsdckksi@gux>
 <CAD2gp_TG3oaHMrOApjOnD24WFvjtCZH7CSyrMH8s+rkAovJA1Q@mail.gmail.com>
 <36Y8S55QM3VDK.2W6PHM76TFYIC@nothien.uber.space>
 <CAD2gp_Sgwb3z9WhP1rHcUs_LQVXkAigLuP+nkmPeWOotrUy5fg@mail.gmail.com>
Message-ID: <3TQ5SKO220HGX.3T5D97BB3Q792@nothien.uber.space>

John Cowan <cowan at ccil.org> wrote:
> Up to a point, certainly.  The tail end of languages probably don't
> need interfaces.

Yep, makes sense.  Too much work (unless someone's willing to do it all
for you).

> Suppose you have written an essay in French on the novels of Jules
> Verne in text/gemini format, and you want to link to a collection of
> the novels themselves.  You can then insert this link line:
> 
> => gemini://gemguten.example.com/advsearch.gmi?lang=fr&author=Jules&author=Verne Les oeuvres de Jules Verne en fran?ais
> 
> The user who selects this link will receive a text/gemini document,
> something like this:
> 
> => gemini://gemguten.example.com/etext/5082 Verne, Jules, 1828-1905. Le chate?u des Carpathe. [fr]
> => gemini://gemguten.example.com/etext/8174 Verne, Jules, 1828-1905. K?raban-Le-T?tu, Volume I. [fr]
> => gemini://gemguten.example.com/etext/17832 Verne, Jules, 1828-1905. Une ville flottante. [fr]
> ...
> 
> Since this is not an _interactive_ search, the Gemini conventions
> about status 1x and the query string don't apply.

But it is an interactive search.  When you point to someone that they
can use the advanced search page, you're going to point them to
gemini://gemguten.example.com/advsearch.gmi.  If you fill in a query
string for them, that's fine, but you also had to write that out
manually.  There's no way in Gemini to automatically create that link
(as to do so you would have to give what you're looking for to a page to
translate it to that format for you, but if it has that translation
ability it would be supported in the advsearch.gmi page itself).  In the
end, someone had to write it out by hand, and that's not the right way
to do it.  I completely understand that such a search function is
needed, and I obviously can't stop you from using this format if you
want, but I do feel that there is a better way to pull it off.  For
example, if you're just searching for an author, you could make an
author-searching page where the query string is only the author name.
But I don't know what the better way, if there is one, is yet.

Also, under my system, the URL you've given says nothing about the
language of the interface (e.g. the "Les oeuvres de Jules Verne en
fran?ais", which would presumably be in the header of the search page).
Under my system, prepending 'fr.' to the domain would effectively
request that the server use a French interface, so that everything from
the returned text/gemini documents to error messages would be in French.
But the URL would be otherwise unaffected.

~aravk | ~nothien

From petite.abeille at gmail.com  Wed Dec 30 22:16:12 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 23:16:12 +0100
Subject: [tech][ANN] LC19 - A USCPI gemini server
In-Reply-To: <f825b0bc-278c-6728-e58e-1034f34e4614@eulenzombie.de>
References: <9ee1f60a-31f9-b2a3-7930-d82dbe908491@eulenzombie.de>
 <B84C2A17-0471-4AFA-981E-1489BA78E70B@gmail.com>
 <f825b0bc-278c-6728-e58e-1034f34e4614@eulenzombie.de>
Message-ID: <07ED817C-2D65-447F-A263-A97942377FE9@gmail.com>



> On Dec 30, 2020, at 23:10, thededem <thededem at eulenzombie.de> wrote:
> 
> I use s6-tlsserver[1] from s6-networking, compiled with LibreSSL.
> 
> [1] https://skarnet.org/software/s6-networking/s6-tlsserver.html

Very nice. Glad to see the djb way alive and kicking :)


From petite.abeille at gmail.com  Wed Dec 30 22:54:20 2020
From: petite.abeille at gmail.com (Petite Abeille)
Date: Wed, 30 Dec 2020 23:54:20 +0100
Subject: [tech] [spec] TLS statistics
In-Reply-To: <cbd574117b113284ed8e456dd96d4bc2@disroot.org>
References: <SWxgIpNfZOmIQCIdHnliYu_bt4mrOE7skKWaWGMEC_2I5P2WUI4LuF7r5PU099CkTkpS-Op2_HoQVbNj97tO4qiVqIJxSc4477T-HNmGlAA=@protonmail.com>
 <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
 <cbd574117b113284ed8e456dd96d4bc2@disroot.org>
Message-ID: <B0FD94BE-B464-41FE-B4EB-E7852CAAE569@gmail.com>



> On Dec 30, 2020, at 23:15, nervuri <nervuri at disroot.org> wrote:
> 
> This kind of thing will always be an issue. The barrier to entry is low, so we can expect problematic server implementations to keep popping up.

First off, very nicely done, thank you for sharing.

A server linter would be a great little project indeed. Something along the lines of Mark Nottingham 's REDbot*, but for Gemini.

*https://redbot.org/about/

From sean at conman.org  Wed Dec 30 23:18:31 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 30 Dec 2020 18:18:31 -0500
Subject: [tech] [spec] TLS statistics
In-Reply-To: <SWxgIpNfZOmIQCIdHnliYu_bt4mrOE7skKWaWGMEC_2I5P2WUI4LuF7r5PU099CkTkpS-Op2_HoQVbNj97tO4qiVqIJxSc4477T-HNmGlAA=@protonmail.com>
References: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
 <SWxgIpNfZOmIQCIdHnliYu_bt4mrOE7skKWaWGMEC_2I5P2WUI4LuF7r5PU099CkTkpS-Op2_HoQVbNj97tO4qiVqIJxSc4477T-HNmGlAA=@protonmail.com>
Message-ID: <20201230231830.GW3625@brevard.conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> > * 40 support TLSv1.1
> > * 39 support TLSv1.0
> 
> This was the most surprising/concerning part to me. These servers are
> breaking the spec, and my understanding is that TLS 1.0 is considered
> insecure by experts. I'm less sure about how insecure 1.1 is, but I know
> that it's deprecated in all main browsers by now.
> 
> Do you have any idea what server software is allowing this? Maybe you can
> look at the capsules, as some will say what software they use. That way
> someone can file a bug or submit a patch/PR.

  The server software and the TLS library would be nice.  My own server,
<gemini://gemini.conman.org/> is running GLV-1.12556, written in Lua, and
using LibreSSL (specifically because it comes with libtls, a sane TLS
wrapper around the rest of LibreSSL).  It could very well be a limitation of
the TLS library itself.

  -spc


From sean at conman.org  Wed Dec 30 23:27:11 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 30 Dec 2020 18:27:11 -0500
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <F9A81B3B-118E-4A4B-A9AB-527764AD997E@gmail.com>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
 <20201230023406.GV3625@brevard.conman.org>
 <F9A81B3B-118E-4A4B-A9AB-527764AD997E@gmail.com>
Message-ID: <20201230232711.GX3625@brevard.conman.org>

It was thus said that the Great Petite Abeille once stated:
> 
> 
> > On Dec 30, 2020, at 03:34, Sean Conner <sean at conman.org> wrote:
> > 
> > but I'm still stuck at TLS 1.2 until I check out the newer LibreSSL library. 
> 
> Perhaps take a look at "[gentoo-dev] [RFC] Discontinuing LibreSSL
> support?". Fascinating dynamic.

  Thanks for the pointer.  Interesting read.  I don't use Gentoo, so this
isn't affecting me, but I doubt it would anyway, as I have downloaded and
installed LibreSSL myself (on a system with an older OpenSSL---what fun!
[1]).  I was happy to find a libtls for OpenSSL:

	https://git.causal.agency/libretls/

which would simplify things for me quite a bit.  Might have to play around
with that.  Seriously, I wish libtls was more popular because it's a *very
easy* library to use.

  -spc

From sean at conman.org  Wed Dec 30 23:31:33 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 30 Dec 2020 18:31:33 -0500
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <87v9cjme5c.fsf@posteo.de>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
 <20201230023406.GV3625@brevard.conman.org> <87v9cjme5c.fsf@posteo.de>
Message-ID: <20201230233133.GY3625@brevard.conman.org>

It was thus said that the Great benthor once stated:
> Sean Conner writes:
> >  There's also the titan: protocol:
> >
> >	https://communitywiki.org/wiki/Titan
> >
> >also an upload method for Gemini, and also originally an idea of 
> >mine (but
> >developed almost exclusively by Alex Schroeder).
> 
> Very interesting. If I understand 
> gemini://communitywiki.org/page/Titan correctly, the following 
> should have worked:
> 
>     echo -en 
>     "titan://communitywiki.org/raw/Test;token=hello;mime=text/plain;size=12\r\nHello 
>     World\n" | socat - ssl:communitywiki.org:1965,verify=0

  You might want to talk about Alex about that.  I think he has the only
titan: enabled server right now.

> However, gemini://communitywiki.org/page/Test remained empty. Even 
> after creating the page via the http interface, I couldn't update 
> it. In general, I am not sure whether the token requirement 
> couldn't be dropped in favor of exclusively client 
> certificate-based authentication.

  If I were doing it, I would use a certificate, but Alex doesn't want that
complication, thus the token.

> > I'd like to at least read the spec, but I'm still stuck at TLS 1.2 until
> > I check out the newer LibreSSL library.  But at the very least, check
> > out the others methods as well.
> 
> Could you check again if you can access the site? It's now using a 
> taditional ECDSA certificate instead of the previous newfangled 
> ED25519 cert.

  That works.  Thanks.

  -spc


From gmi1 at scotdoyle.com  Wed Dec 30 23:41:40 2020
From: gmi1 at scotdoyle.com (Scot)
Date: Wed, 30 Dec 2020 17:41:40 -0600
Subject: [tech] [spec] TLS statistics
In-Reply-To: <20201230231830.GW3625@brevard.conman.org>
References: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
 <SWxgIpNfZOmIQCIdHnliYu_bt4mrOE7skKWaWGMEC_2I5P2WUI4LuF7r5PU099CkTkpS-Op2_HoQVbNj97tO4qiVqIJxSc4477T-HNmGlAA=@protonmail.com>
 <20201230231830.GW3625@brevard.conman.org>
Message-ID: <59b0daa0-b877-df6e-47f2-11add7f7b99d@scotdoyle.com>

On 12/30/20 5:18 PM, Sean Conner wrote:
> My own server,
> <gemini://gemini.conman.org/> is running GLV-1.12556, written in Lua, and
> using LibreSSL (specifically because it comes with libtls, a sane TLS
> wrapper around the rest of LibreSSL).  It could very well be a limitation of
> the TLS library itself.
Looks like LibreSSL has support as of May 2020 [1].

[1] 
https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.2.0-relnotes.txt

From sean at conman.org  Wed Dec 30 23:52:58 2020
From: sean at conman.org (Sean Conner)
Date: Wed, 30 Dec 2020 18:52:58 -0500
Subject: [tech] [spec] TLS statistics
In-Reply-To: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
References: <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
Message-ID: <20201230235258.GZ3625@brevard.conman.org>

It was thus said that the Great nervuri once stated:
> 
> As far as I know, with TLSv1.2 client certs are sent in the clear,
> revealing login information to the ISP (and whoever else is looking). In
> this respect, when used with TLS 1.2, client certs are worse than cookies.

  I currently log client certificates (gasp!).  Yes, it's true, but I added
such logging last year when the protocol was still in the intial stages of
development and I wanted a way to debug client certificate issues.  I have
an area that requires client certificates but it doesn't get a lot of
traffic.  But, just bacause I'm feeling ornery about this, here are the
details of the few client certs that have crossed my server over the past
month (the subject):

	/CN=elpherAyKLzp
	/CN=default
	/CN=My Cert
	/C=CH/ST=Some-State/O=Internet Widgits Pty Ltd
	/CN=testuser
	/C=US/ST=FL/L=Boca Raton/CN=Sean Conner/emailAddress=sean at conman.org

and except for that last one (what a stupid git, giving out his name and
email address like that!), the issuer was also the same as the subject.

  Yeah, way worse than cookies I'd say.

> Also, 1.2 isn't compatible with encrypted SNI. So I hope it will be phased
> out soon, if possible. Let me know your thoughts.

  Sigh.

  Given the current state of Gemini, *even if* the domain name were
encrypted, there's still a near 80% chance of knowing which domain is being
accessed, just because most servers only serve one domain.  And there is
*no* login information in a server certificate.

  -spc (You know, a pair of scissors to the network cable does wonders for
	security ... )

From cowan at ccil.org  Thu Dec 31 03:54:01 2020
From: cowan at ccil.org (John Cowan)
Date: Wed, 30 Dec 2020 22:54:01 -0500
Subject: IETF policy on encodings and languages
In-Reply-To: <3TQ5SKO220HGX.3T5D97BB3Q792@nothien.uber.space>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
 <20201228091230.nomtkdkolsdckksi@gux>
 <CAD2gp_TG3oaHMrOApjOnD24WFvjtCZH7CSyrMH8s+rkAovJA1Q@mail.gmail.com>
 <36Y8S55QM3VDK.2W6PHM76TFYIC@nothien.uber.space>
 <CAD2gp_Sgwb3z9WhP1rHcUs_LQVXkAigLuP+nkmPeWOotrUy5fg@mail.gmail.com>
 <3TQ5SKO220HGX.3T5D97BB3Q792@nothien.uber.space>
Message-ID: <CAD2gp_SkVxO+G0CSmTT5a9vBT4oeWOVEndu=r9T3pcHyADdT1Q@mail.gmail.com>

On Wed, Dec 30, 2020 at 5:15 PM <nothien at uber.space> wrote:


> But it is an interactive search.  When you point to someone that they
> can use the advanced search page, you're going to point them to
> gemini://gemguten.example.com/advsearch.gmi.


If you chose such a link, you'd in principle get all 40,000+ document
links, since there are no restrictions.  But in fact you'd get an error
page telling you that you asked for too many documents.  There will be a
different link altogether for interactive search, where you would be asked
using a 10 response to enter keywords from the metadata (language, author,
title, Library of Congress subject classification, etc.)  However, that's
inherently less precise: if you provided keywords "Mark Twain", you'd get
both books by him and books about him, such as _My Mark Twain_ by William
Dean Howells.


> In the end, someone had to write it out by hand,


True.  But it isn't particularly difficult, either.  I'll put some samples
on the interactive search page along with the actual interactive link.


> I completely understand that such a search function is
> needed, and I obviously can't stop you from using this format if you
> want, but I do feel that there is a better way to pull it off.  For
> example, if you're just searching for an author, you could make an
> author-searching page where the query string is only the author name.
>

With so many pages to search, all the search terms are ANDed together: the
more keywords, the less output to look through.  (I'm not sure what the
upper limit on results will be: for Google it's 1000.)  You probably don't
want all the works by one author anyhow: you want the ones you can read.

Also, under my system, the URL you've given says nothing about the
> language of the interface (e.g. the "Les oeuvres de Jules Verne en
> fran?ais", which would presumably be in the header of the search page).
>

The search engine doesn't know what the link looks like.  I suppose that
could be passed in the query too: "...
&linktext=Les%20oeuvres%20de%20Jules%20Verne%20en%20fran?ais", for example.

Under my system, prepending 'fr.' to the domain would effectively
> request that the server use a French interface, so that everything from
> the returned text/gemini documents to error messages would be in French.
> But the URL would be otherwise unaffected.
>

Fine as far as the error messages are concerned.  But just because you want
a French interface, it doesn't necessarily mean you want to reject English
or German books from the search.




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
It's the old, old story.  Droid meets droid.  Droid becomes chameleon.
Droid loses chameleon, chameleon becomes blob, droid gets blob back
again.  It's a classic tale.  --Kryten, Red Dwarf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201230/50cffefa/attachment.htm>

From chris at cbrews.xyz  Thu Dec 31 03:58:10 2020
From: chris at cbrews.xyz (Chris)
Date: Thu, 31 Dec 2020 03:58:10 +0000
Subject: [ANN] Ignition: A python protocol client for devs
Message-ID: <HpnQbjRTpZB_kNZ4IxStbrIkPHIPkXA9YvveDIgMSiyEbIKnQYI3_ivaVZ_-v_RgSfHU1gFXmbq8SH5p0BEuOqgAws1LWWRDAn_UP20TrD4=@cbrews.xyz>

Howdy!

Wanted to finally shoot a message to this list in order to say "hi!" and share some of the Gemini stuff that I've been doing. I've been quietly flirting with Gemini tools and ideas since the summer but have been shy about reaching out! It's amazing to see all of the inventive ideas going on, I've really enjoyed watching from the sidelines.

Today I wanted to share the Gemini python3 client I've been working on for folks' interest. The genesis of this was really wanting to focus on and harden a client scoped around the actual protocol mechanics (less so the text rendering). This may be a good solution for spiders, scrapers, programmatic clients, and non-gui/non-visual interfaces with the Gemini protocol.

I've named it Ignition, please take a look! Definitely open to feedback; the big challenge here has been scoping this in a way so it's good at what it does but not too much more.

It's available on Github at https://github.com/cbrews/ignition or through my capsule: gemini://cbrews.xyz (with a bunch of the gothic literature I threw up there, haha).

Anywho, thanks! Maybe this will give me the boost to chat a bit more on this list :D

- Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201231/97177b30/attachment-0001.htm>

From nothien at uber.space  Thu Dec 31 07:31:48 2020
From: nothien at uber.space (nothien at uber.space)
Date: Thu, 31 Dec 2020 08:31:48 +0100
Subject: IETF policy on encodings and languages
In-Reply-To: <CAD2gp_SkVxO+G0CSmTT5a9vBT4oeWOVEndu=r9T3pcHyADdT1Q@mail.gmail.com>
References: <CAD2gp_R2qtVBxSs6A4nFaM2sbt6ncxa=Grzi1RgqygQexdeS-w@mail.gmail.com>
 <20201227200640.ht4msim2hkbkauoz@gux>
 <CAD2gp_RaqQ78ePgOtst2N6-W9eZaryXr66a6aj6aW8RJ1iN42g@mail.gmail.com>
 <20201228091230.nomtkdkolsdckksi@gux>
 <CAD2gp_TG3oaHMrOApjOnD24WFvjtCZH7CSyrMH8s+rkAovJA1Q@mail.gmail.com>
 <36Y8S55QM3VDK.2W6PHM76TFYIC@nothien.uber.space>
 <CAD2gp_Sgwb3z9WhP1rHcUs_LQVXkAigLuP+nkmPeWOotrUy5fg@mail.gmail.com>
 <3TQ5SKO220HGX.3T5D97BB3Q792@nothien.uber.space>
 <CAD2gp_SkVxO+G0CSmTT5a9vBT4oeWOVEndu=r9T3pcHyADdT1Q@mail.gmail.com>
Message-ID: <32XPUFCAG9STF.3IIX3WWKA24HC@nothien.uber.space>

John Cowan <cowan at ccil.org> wrote:
> If you chose such a link, you'd in principle get all 40,000+ document
> links, since there are no restrictions.  But in fact you'd get an
> error page telling you that you asked for too many documents.  There
> will be a different link altogether for interactive search, where you
> would be asked using a 10 response to enter keywords from the metadata
> (language, author, title, Library of Congress subject classification,
> etc.)

You could just combine the two pages and return a 10 when no query
string is provided to advsearch.gmi.

> However, that's inherently less precise: if you provided keywords
> "Mark Twain", you'd get both books by him and books about him, such as
> _My Mark Twain_ by William Dean Howells.

So you provide no interactive way to create an advanced search filter,
and you are replacing it with an interactive way to create not an
advanced search filter.

> With so many pages to search, all the search terms are ANDed together:
> the more keywords, the less output to look through.  (I'm not sure
> what the upper limit on results will be: for Google it's 1000.)  You
> probably don't want all the works by one author anyhow: you want the
> ones you can read.

You could simply prioritize books written in the language of the
interface - so with the fr.gemguten.example.com/author/Jules%20Verne.gmi
page, French books would show up at the top.  But this solution doesn't
scale to finding books in an arbitrary language.

> The search engine doesn't know what the link looks like.  I suppose
> that could be passed in the query too: "...
> &linktext=Les%20oeuvres%20de%20Jules%20Verne%20en%20fran?ais", for
> example.

The server is smart enough to generate something along those lines on
its own.  Please don't make URLs that much longer.

> Fine as far as the error messages are concerned.  But just because you
> want a French interface, it doesn't necessarily mean you want to
> reject English or German books from the search.

Of course not.  The interface language is completely dissociated from
the actual content of the pages, it only affects the language they are
written in.

~aravk | ~nothien

From nervuri at disroot.org  Thu Dec 31 11:34:08 2020
From: nervuri at disroot.org (nervuri)
Date: Thu, 31 Dec 2020 11:34:08 +0000
Subject: [tech] [spec] TLS statistics
In-Reply-To: <20201230235258.GZ3625@brevard.conman.org>
References: <20201230235258.GZ3625@brevard.conman.org>
 <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
Message-ID: <46684aa3f60f500f8bd01dbe130edb3c@disroot.org>

December 30, 2020 11:53 PM, Sean Conner wrote:
  > I currently log client certificates (gasp!).

That's different from what I was referring to. You're not a third party, you're supposed to receive that information. The problem with client certs + TLS 1.2 is that any third party on the network route can also see that information.

When I log into a web forum over https using cookies, my ISP doesn't see what user I log in as. But when I log into a gemini forum using a client cert, my ISP does - and, as you point out, may even see the email address I used. However, that problem goes away with TLS 1.3.

  > Given the current state of Gemini, *even if* the domain name were encrypted, there's still a near 80% chance of knowing which domain is being accessed, just because most servers only serve one domain.

I went from 394 to 258 hosts after eliminating subdomains (like all those *.flounder.online vhosts). So it's about 65%, rather than 80%. A 45% improvement is nothing to scoff at.

But even if in 100% of cases there was a 1-to-1 mapping from domain to IP address, encrypted SNI still raises the bar, as the watchers on the network route need to do more work to find the domain - they don't simply get it when inspecting network traffic. Especially since, with SNI, you can't always find a domain if all you have is its IP address. For example, let's take 107.5.198.24 - tell me what Gemini domain is hosted there without looking at the data I gathered. If you find out, tell us how.

From nervuri at disroot.org  Thu Dec 31 11:39:03 2020
From: nervuri at disroot.org (nervuri)
Date: Thu, 31 Dec 2020 11:39:03 +0000
Subject: [tech] [spec] TLS statistics
In-Reply-To: <46684aa3f60f500f8bd01dbe130edb3c@disroot.org>
References: <46684aa3f60f500f8bd01dbe130edb3c@disroot.org>
 <20201230235258.GZ3625@brevard.conman.org>
 <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
Message-ID: <5d6c00f8872d5f29ac380ce6bb203b36@disroot.org>

December 31, 2020 11:34 AM, nervuri wrote:
  > 45% improvement

I meant 35%.

From cowan at ccil.org  Thu Dec 31 14:15:05 2020
From: cowan at ccil.org (John Cowan)
Date: Thu, 31 Dec 2020 09:15:05 -0500
Subject: [tech] Proposed reversed Gemini for uploads to servers - Feedback
 wanted
In-Reply-To: <87v9cjme5c.fsf@posteo.de>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
 <20201230023406.GV3625@brevard.conman.org> <87v9cjme5c.fsf@posteo.de>
Message-ID: <CAD2gp_Qm7Kb7ei9ZyrV+pGT3aPkXyyu5YG+q6Bu_sOAbR+DFYA@mail.gmail.com>

On Wed, Dec 30, 2020 at 11:50 AM benthor <benthor at posteo.de> wrote:


> > There is also Dioscuri:
>


>  Oh, I like this approach! Unfortunately the Gemini version of that

page is a bit taxing to read due to issues with newline
> conversion. Here is the HTML version for anyone who is interested:
>

Please, everyone, stop propagating the mailing-list link to Dioscuri!  The
permanent HTML link is <http://tinyurl.com/dioscuri-home>.  I'm pretty much
done changing it until I get some feedback, so I would be glad for someone
to convert it to text/gemini (it is currently Git-flavored Markdown) and
host it on Gemini, somewhere handy.

There is no implementation right now because I haven't found a toy thing to
do with it yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201231/ffecf302/attachment.htm>

From luke.emmet at gmail.com  Thu Dec 31 19:04:02 2020
From: luke.emmet at gmail.com (Luke Emmet)
Date: Thu, 31 Dec 2020 19:04:02 +0000
Subject: [tech] Proposed reversed Gemini for uploads to aservers -
 Feedback wanted
In-Reply-To: <CAD2gp_Qm7Kb7ei9ZyrV+pGT3aPkXyyu5YG+q6Bu_sOAbR+DFYA@mail.gmail.com>
References: <8735zonnl3.fsf@posteo.de>
 <2031C8AA-96DC-43B3-BCE1-DB098756F8FA@gmail.com>
 <20201230003704.GU3625@brevard.conman.org> <87y2hgm6ah.fsf@posteo.de>
 <20201230023406.GV3625@brevard.conman.org> <87v9cjme5c.fsf@posteo.de>
 <CAD2gp_Qm7Kb7ei9ZyrV+pGT3aPkXyyu5YG+q6Bu_sOAbR+DFYA@mail.gmail.com>
Message-ID: <59698B47-6322-4550-9C62-B6CA11F81E70@gmail.com>



> On 31 Dec 2020, at 14:15, John Cowan <cowan at ccil.org> wrote:
> 
> 
> 
>> On Wed, Dec 30, 2020 at 11:50 AM benthor <benthor at posteo.de> wrote:
>>  
>> > There is also Dioscuri:
>  
>>  Oh, I like this approach! Unfortunately the Gemini version of that 
>> page is a bit taxing to read due to issues with newline 
>> conversion. Here is the HTML version for anyone who is interested:
> 
> Please, everyone, stop propagating the mailing-list link to Dioscuri!  The permanent HTML link is <http://tinyurl.com/dioscuri-home>.  I'm pretty much done changing it until I get some feedback, so I would be glad for someone to convert it to text/gemini (it is currently Git-flavored Markdown) and host it on Gemini, somewhere handy.
> 
> There is no implementation right now because I haven't found a toy thing to do with it yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201231/e267582a/attachment.htm>

From sean at conman.org  Thu Dec 31 21:45:09 2020
From: sean at conman.org (Sean Conner)
Date: Thu, 31 Dec 2020 16:45:09 -0500
Subject: [tech] [spec] TLS statistics
In-Reply-To: <46684aa3f60f500f8bd01dbe130edb3c@disroot.org>
References: <20201230235258.GZ3625@brevard.conman.org>
 <c78464d729c9e7fb40c356d0d49418d8@disroot.org>
 <46684aa3f60f500f8bd01dbe130edb3c@disroot.org>
Message-ID: <20201231214509.GA3625@brevard.conman.org>

It was thus said that the Great nervuri once stated:
> December 30, 2020 11:53 PM, Sean Conner wrote:
> 
> When I log into a web forum over https using cookies, my ISP doesn't see
> what user I log in as. But when I log into a gemini forum using a client
> cert, my ISP does - and, as you point out, may even see the email address
> I used. However, that problem goes away with TLS 1.3.

  Okay, point taken.
  
>   > Given the current state of Gemini, *even if* the domain name were
>   > encrypted, there's still a near 80% chance of knowing which domain is
>   > being accessed, just because most servers only serve one domain.
> 
> I went from 394 to 258 hosts after eliminating subdomains (like all those
> *.flounder.online vhosts). So it's about 65%, rather than 80%. A 45%
> improvement is nothing to scoff at.
> 
> But even if in 100% of cases there was a 1-to-1 mapping from domain to IP
> address, encrypted SNI still raises the bar, as the watchers on the
> network route need to do more work to find the domain - they don't simply
> get it when inspecting network traffic. Especially since, with SNI, you
> can't always find a domain if all you have is its IP address. For example,
> let's take 107.5.198.24 - tell me what Gemini domain is hosted there
> without looking at the data I gathered. If you find out, tell us how.

  I threw the IP address into the almighty Google.  The third result (for
me, your results may vary as this is Google) was to this link:

	https://lists.sr.ht/~emersion/alps-dev/%3C20200625175005.52130-1-zdecook%40ccel.org%3E/raw

which showed me that Zach DeCook sent a patch to the ALPS development list
originating from said IP address.  The domain of his email address,
ccel.org, did not show anything related to Gemini, but throwing his name
into the almighty Google brought me to his homepage:

	https://zachdecook.com/

where at the bottom, you can see the link to his Gemini site, which has the
IP address 107.5.198.24.

  Yes, that's a bit of work, but it was less than 5 minutes, and I'm not
even a state actor here.  Is that enough of a bar for you?

  -spc

From gorman.paul at gmail.com  Thu Dec 31 23:24:27 2020
From: gorman.paul at gmail.com (Paul Gorman)
Date: Thu, 31 Dec 2020 18:24:27 -0500
Subject: [ANN] Gneto, a personal Gemini to HTTP proxy server
Message-ID: <CABNXC2+pV_8cRwb_cPH9+J-_HB3SDdLmuw_Gd3hgkQ_rx7Oi9g@mail.gmail.com>

Happy new year, everyone!

I've written Gneto, a proxy server to make Gemini content available in a
web browser. Gneto differs from the fine web portals available at
portal.mozz.us and proxy.vulpes.one in that it's designed to proxy for a
single user. Run it on the loopback interface of your workstation, or the
server on your home LAN. If you want to run it on your public VPS, the web
interface can be password protected. Gneto supports both persistent and
transient client certificates.

Gneto source code (with a screenshot) is available at:

https://github.com/pgorman/gneto/

It has no dependencies beyond the standard Go library, so Gneto should
build easily with a simple "go build".

Binaries for Linux, Windows, macOS, and OpenBSD are available.

Thanks, and happy 2021!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201231/ca774f74/attachment.htm>