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" 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: 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: 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: References: 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: <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: <20200109071132.GA19769@brevard.conman.org> Message-ID: On Thu, Jan 9, 2020 at 2:11 AM Sean Conner 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 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. = [] - 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> <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 
 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 
 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 
 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>
 
 <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 
 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>
 
 <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>
 
 <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>
 
 <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>
 
 <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>
 
 <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 

> 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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
Message-ID: 

On Sun, Jan 12, 2020 at 1:43 PM solderpunk  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
> 
 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 
 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: 
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
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: 
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
Message-ID: 

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: 
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
Message-ID: 

On Wed, Jan 15, 2020 at 3:21 PM solderpunk  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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <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 
 and 
 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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
Message-ID: 

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: 
References: <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
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>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 <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>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 <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: 
References: <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
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: 
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
Message-ID: 

On Thu, Jan 16, 2020 at 12:41 PM Aaron Janse  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: 
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
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: 
References: <1367854366.219683.1576461212912@ichabod.co-bxl>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <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>
 
 <20191216054032.GD24166@brevard.conman.org>
 <86d7af23-fc3d-49e6-9bd6-f68c84fe8899@www.fastmail.com>
 <20200112184341.GA1011@SDF.ORG>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
Message-ID: 

On Thu, Jan 16, 2020 at 3:51 PM Aaron Janse  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: 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <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>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 <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 ===]

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.



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.

[=== 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 "1ST" [4] or
even pulling out image sizes for the  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>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 <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 "1ST" [4] or
> even pulling out image sizes for the  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: 
References: 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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: 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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: 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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: 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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: 

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: 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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: 

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: 
References: <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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: <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>
 
 <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>
 
 <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: 
 <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>
 
 <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: 
 <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>
 
 <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: 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <546c2284-4b16-4ec1-8a9f-a072e0773799@www.fastmail.com>
 <20200116221202.GC23953@SDF.ORG>
Message-ID: 

On Thu, Jan 16, 2020 at 5:12 PM solderpunk  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>
 
 <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: 
References: 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.com>
 <546c2284-4b16-4ec1-8a9f-a072e0773799@www.fastmail.com>
 <20200116221202.GC23953@SDF.ORG>
 
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>
 
 <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 

> 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>
 
 <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 
> 
> 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>
 
 <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: 

On 1/18/20 8:10 AM, James Tomasino wrote:
> From: solderpunk 
> 
>> 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>
 
 <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: 

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: 
References: <20200117133312.GA7402@SDF.ORG> <20200117135804.GA5259@briz>
 <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 
 <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: <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>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118153947.GD4518@SDF.ORG>
Message-ID: 

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: 

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>
 
 <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: 
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118153947.GD4518@SDF.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: 
References: 
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>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118153947.GD4518@SDF.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>
 
 <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: 
 <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: 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118153947.GD4518@SDF.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, 
  •  and 
    • .  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: 
References: <20200117133312.GA7402@SDF.ORG> <20200117135804.GA5259@briz>
 <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 
 <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: <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
this (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: 

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>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118184530.GK4518@SDF.ORG>
Message-ID: 

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: 
References: <660019441.8880.1579116650232@ichabod.co-bxl>
 <20200118190519.GM4518@SDF.ORG>
 
Message-ID: 

> 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: 
References: 
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: 
 <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: 
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118184530.GK4518@SDF.ORG>
 
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>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118184530.GK4518@SDF.ORG>
 
 <20200118213303.GN4518@SDF.ORG>
Message-ID: 

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: 
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118153947.GD4518@SDF.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>
 
 <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: 
References: <20200117142715.GA23881@SDF.ORG> <20200117160708.GA11117@briz>
 
 <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118184530.GK4518@SDF.ORG>
 
 <20200118213303.GN4518@SDF.ORG>
 
Message-ID: 

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: 
References: <20200117172902.GA1432@SDF.ORG>
 <8517d9cd-e722-4301-aa7a-304412bdb18f@www.fastmail.com>
 <20200118114503.GA4518@SDF.ORG>
 <0913EE1C-BCF8-40AE-BF2B-188DCA09310D@lavabit.com>
 
 <20200118184530.GK4518@SDF.ORG>
 
 <20200118213303.GN4518@SDF.ORG>
 
 
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  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  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... "

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: 

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: 
References: <051fb7d9-f8c4-4d87-93b6-b6f70498d6ed@www.fastmail.com>
 
Message-ID: <6D0FC1A7-2676-4AE9-BB1B-D21E4FDA377A@lavabit.com>

-------- Original Message --------
From: Julien Blanchard 

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: 

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: 
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 
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>
 
 <20200120102856.GA4819@SDF.ORG>
Message-ID: 

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: 
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 
 <20200120102856.GA4819@SDF.ORG>
 
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>
 
 <20200120102856.GA4819@SDF.ORG>
Message-ID: 

On Mon, Jan 20, 2020 at 5:29 AM solderpunk  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 
  •  without the surrounding 
      . 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>
 
 <20200120102856.GA4819@SDF.ORG>
 
 <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: 
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 
 <20200120102856.GA4819@SDF.ORG>
 
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 
    •  without the surrounding 
        . 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>
 
 <20200120102856.GA4819@SDF.ORG>
 
 <20200120194833.GA15749@SDF.ORG>
Message-ID: 

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: 

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: 
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 
 <20200120102856.GA4819@SDF.ORG>
 
 <20200120194833.GA15749@SDF.ORG>
 
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: 

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: 
References: <574762512.1104.1579461314537@ichabod.co-bxl>
 <20200119200123.GA7786@SDF.ORG> <20200119221826.GC7786@SDF.ORG>
 
 <20200120102856.GA4819@SDF.ORG>
 
 <20200120194833.GA15749@SDF.ORG>
 
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>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 <20200116202652.GA23953@SDF.ORG>
Message-ID: <87wo9kdfas.fsf@cassilda.carcosa.net>

solderpunk  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>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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  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  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>
 
 <20200115202137.GA21763@SDF.ORG>
 
 <20200115221117.GB21763@SDF.ORG>
 <644e55a3-2da6-4c54-b2de-dd435058e2bd@www.fastmail.com>
 <20200116151001.GA24028@SDF.ORG>
 
 <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>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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>
 
 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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  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: 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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  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: 
 <359fadc4-9c53-4700-abc5-cc132c107c9a@www.fastmail.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: 

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: 
References: 
 <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: <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:  (Julien
 Blanchard's message of "Sat, 18 Jan 2020 18:05:35 +0100")
References: 
Message-ID: <87o8ujbf6j.fsf@cassilda.carcosa.net>

Julien Blanchard  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  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  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: 

On Wed, Feb 5, 2020 at 4:22 AM solderpunk  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: 
References: 
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   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: 
 <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: 

-----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: 
 <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: 
 <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: 
 <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: 
 <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: 

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: 
References: 
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: 

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: 

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: 
 <20200228024409.GA16159@brevard.conman.org>
Message-ID: 

On Fri, Feb 28, 2020 at 4:44 AM Sean Conner  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: 
References: 
 <20200228024409.GA16159@brevard.conman.org>
 
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  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: 
References: 
 <20200228024409.GA16159@brevard.conman.org>
 
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: 
References: 
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: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
Message-ID: 

On Fri, Feb 28, 2020 at 11:07 AM Sean Conner  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: 
 <20200228094347.GA6322@SDF.ORG>
Message-ID: 

On Fri, Feb 28, 2020 at 11:44 AM solderpunk  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: 
References: 
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: 
References: 
 <20200228094347.GA6322@SDF.ORG>
 
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: 
 <20200228223235.GA8734@SDF.ORG>
Message-ID: 

> 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: 
References: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
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  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 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"

	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: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
 <20200228234201.GE16159@brevard.conman.org>
Message-ID: 

On Sat, Feb 29, 2020 at 1:42 AM Sean Conner  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: 
References: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
 <20200228234201.GE16159@brevard.conman.org>
 
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  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: 

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: 
References: 
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: 
References: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
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  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: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
 <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: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
 <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
Message-ID: 

On Sun, Mar 1, 2020 at 10:22 AM Bradley D. Thornton
 wrote:
> On 2/28/2020 2:04 AM, Ciprian Dorin Craciun wrote:
> > On Fri, Feb 28, 2020 at 11:07 AM Sean Conner  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: 

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  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: 

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: 
References: 
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: 
References: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
 <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
 
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: 
 <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.... , 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: 
References: <20200225194356.GA16266@SDF.ORG>
 
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: 
 <20200302001842.GC5475@brevard.conman.org>
Message-ID: 

On Mon, Mar 2, 2020 at 2:18 AM Sean Conner  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: 
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
Message-ID: 

On Mon, Mar 2, 2020 at 10:36 AM Bradley D. Thornton
 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: 
 <20200228024409.GA16159@brevard.conman.org>
 
 <20200228090709.GB16159@brevard.conman.org>
 
 <279d3c5b-6c42-3461-d86c-c6bc40ebb353@NorthTech.US>
 
 <20200302013918.GD5475@brevard.conman.org>
Message-ID: 

On Mon, Mar 2, 2020 at 3:39 AM Sean Conner  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: 
 <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.... , 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: 
References: 
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
 
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
>  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: 
References: 
 <20200302001842.GC5475@brevard.conman.org>
 
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  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: 
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
 <20200302220047.GH5475@brevard.conman.org>
Message-ID: 

> 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.... , 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: 
References: 
 <20200302001842.GC5475@brevard.conman.org>
 <9d844f8e-250b-88c8-4d8a-c934dab3169e@NorthTech.US>
 <20200302220047.GH5475@brevard.conman.org>
 
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: 
References: 
Message-ID: 

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: 
References: 
 
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: 
References: 
 
Message-ID: 

On Tue, Mar 3, 2020 at 2:20 PM Ciprian Dorin Craciun
 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: 
 
 <20200303191620.GB29986@SDF.ORG>
Message-ID: 

On Tue, Mar 3, 2020 at 9:16 PM solderpunk  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: 
References: 
 
 <20200303191620.GB29986@SDF.ORG>
 
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: 

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  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: 

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: 

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 
wrote:

> Great idea! Now I have to make an Emacs mode :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

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: 
References: <977314474.88097.1583269503970@ichabod.co-bxl>
 <6288065B-7E7A-4819-8B49-3C252D51D0DD@typed-hole.org>
 
Message-ID: 

> 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: 

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: 
References: <977314474.88097.1583269503970@ichabod.co-bxl>
 <6288065B-7E7A-4819-8B49-3C252D51D0DD@typed-hole.org>
 
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: 

On Sun, Mar 1, 2020 at 11:36 AM solderpunk  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: 
References: <20200301163618.GA7582@SDF.ORG>
 
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  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: 
References: <20200301163618.GA7582@SDF.ORG>
 
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:  (Aaron
 Janse's message of "Fri, 28 Feb 2020 15:21:30 -0800")
References: 
 <20200228223235.GA8734@SDF.ORG>
 
Message-ID: <87d09k725p.fsf@cassilda.carcosa.net>

"Aaron Janse"  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: 
 <20200228094347.GA6322@SDF.ORG>
Message-ID: <878sk8720n.fsf@cassilda.carcosa.net>

solderpunk  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: 
 <20200302001842.GC5475@brevard.conman.org>
Message-ID: <874kuw71rg.fsf@cassilda.carcosa.net>

Sean Conner  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: 
 <20200302001842.GC5475@brevard.conman.org>
 <874kuw71rg.fsf@cassilda.carcosa.net>
Message-ID: 

On Tue, Mar 10, 2020 at 3:55 PM Jason McBrayer  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: 

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: 

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: 
 (krixano@protonmail.com's message of "Mon, 16 Mar 2020 12:28:15 +0000")
References: 
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: 
 <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  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: 

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  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: 
References: <20200322181333.GB26849@SDF.ORG>
 
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  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>
 
 <20200302120738.GB335198@goldfish.localdomain>
Message-ID: 

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: 
References: <20200225194356.GA16266@SDF.ORG>
 
 <20200302120738.GB335198@goldfish.localdomain>
 
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: 


(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: 

[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  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: 
References: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>
 
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  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>
 
 <20200420181956.GA22501@SDF.ORG>
Message-ID: 

On Mon, Apr 20, 2020 at 2:20 PM solderpunk  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: 
References: <2e3d7123-4b8a-6287-f057-26776014e9c3@typed-hole.org>
 
 <20200420181956.GA22501@SDF.ORG>
 
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: 

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: 

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: 
References: 
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: 
 <20200505125113.GA148355@goldfish.localdomain>
Message-ID: 

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  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: 

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  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: 

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: 
References: 
Message-ID: 

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  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: 

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: 
References: 
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: 
References: 
Message-ID: 

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  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: 

This is dope, thank you!

On Tue, May 5, 2020 at 2:22 AM 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 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: 
References: 
Message-ID: 

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: 
References: 
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: 
References: 
Message-ID: 




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: 
References: 
Message-ID: 


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: 

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: 

Hello, I got here from Hacker News in the beginning of the month.

Brian Evans  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: 

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: 
References: <189864553.486215.1589156337414@ichabod.co-bxl>
 
Message-ID: 

> 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  wrote:

> Hello, I got here from Hacker News in the beginning of the month.
>
> Brian Evans  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: 
References: <189864553.486215.1589156337414@ichabod.co-bxl>
 
Message-ID: <20200511172547.GA784@beanhill.localdomain>

On 11 May 2020, at  7:15 pm +0200, Katarina Eriksson wrote:
> Brian Evans  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: 

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: 
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 
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: 

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:
> 
        Hi, All.?

        To announce our new gemini capsule is online for all spanish-speaking community. Available on:

        gemini://gagarin.p4g.club

        Regards.?

        

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: 

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: 

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: 

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.  Hopefully it won't take as long
as TUNES, Loper OS, Blue Abyss, or Urbit.

> 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: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: 

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: 

Shufei  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:
gemini://gemini.circumlunar.space

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

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: 

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  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: 
References: 
 <20200505125113.GA148355@goldfish.localdomain>
 
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: 
 <20200505125113.GA148355@goldfish.localdomain>
 
 <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: 
 <20200505125113.GA148355@goldfish.localdomain>
 
 <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: 

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: 

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  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: 
 <20200505125113.GA148355@goldfish.localdomain>
 
 <20200514120907.GA2791104@goldfish.localdomain>
Message-ID: 

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  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: 

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: 
References: 
Message-ID: 

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  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: 
References: 
 
Message-ID: 

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: 
References: 
 
 
Message-ID: 

> 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: 
References: <75f471cd-882e-2f4a-c842-5e888659b359@gmx.com>
 
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: 
References: 
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: 
References: 
 
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  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: 

On Thu, May 14, 2020 at 11:56 AM Luke Emmet  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  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: 

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: 
 
 <20200514174155.GK10556@SDF.ORG>
Message-ID: 

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: 

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: 

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: 

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: 
References: <5EBD6A0C.6090702@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: 
 
 <20200514174155.GK10556@SDF.ORG>
Message-ID: 

> 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  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...).
>
> 
> 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...).
>
> 
> 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: 
References: <5EBD6A0C.6090702@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  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
>
>

> 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: 
References: <5EBD6A0C.6090702@gmail.com>
 
Message-ID: 


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: 

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: 
References: <5EBD6A0C.6090702@gmail.com> <20200514182104.GL10556@SDF.ORG>
 
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: 

Brian Evans  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: 

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: 
References: <345770818.210897.1589482670266@ichabod.co-bxl>
 
Message-ID: <20200514194628.GP10556@SDF.ORG>

On Thu, May 14, 2020 at 09:40:49PM +0200, Katarina Eriksson wrote:
> Brian Evans  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: 
References: 
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>
 
 <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: 
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: 

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: 
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: <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: 
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: <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: 

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: 
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: <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>
 
 
 <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>
 
 
 <20200514205753.GQ10556@SDF.ORG>
Message-ID: 

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: 

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: 
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>
 
 
 <20200514205753.GQ10556@SDF.ORG>
 
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: 
References: 
 
 
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: 

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: 
 <20200505125113.GA148355@goldfish.localdomain>
 
 <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: 
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: <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: 
References: <20200514150810.GB12880@SDF.ORG>
 
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: 

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: 
 
 
 <20200514214337.GA7305@brevard.conman.org>
Message-ID: 

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>
 
 
 <20200514205753.GQ10556@SDF.ORG>
 
 <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: 
References: <20200514123545.vdx2gwzhytp5risg@tilde.pink>
 
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"  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: 

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: 
References: <20200514191333.0b408523@azalea.lignumvitae.org>
 
Message-ID: 

int 80h  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: 

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: 
Message-ID: 

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>
 
 
 <20200514205753.GQ10556@SDF.ORG>
 
 <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: 


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: 

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: 


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: 

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



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: 

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: 
References: <20200515145218.503c29f2@socimda>
 
Message-ID: <20200515154421.43b75423@socimda>

On Fri, 15 May 2020 12:29:39 +0000
James Tomasino  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: 

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: 

On Thu, May 14, 2020 at 11:44 PM 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.
>
>
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: 

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: 
References: 
Message-ID: 

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: 
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
 
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 
>  --tls-certfile fullchain.pem 
> --tls-keyfile privkey.pem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

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: 
References: 
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: 
 <874ksh6lcj.fsf@dorothy.carcosa.net>
Message-ID: 

>> 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: 

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: 
References: 
 <874ksh6lcj.fsf@dorothy.carcosa.net>
 
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: 
References: <8461db9a-e5c9-a629-0e73-14bd188a95a1@systemli.org>
 
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: 
References: 
 
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: 
 <874ksh6lcj.fsf@dorothy.carcosa.net>
 
 <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: 
References: 
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: 
 <20200515210144.GH5879@SDF.ORG>
Message-ID: 

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  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: 
 
 <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: 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

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: 
References: 
Message-ID: 

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  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: 
References: 
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
>  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?

  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: 
References: 
Message-ID: 

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 
>  me up is the 
> fact that wikipedia  articles are written 
>  with a lot of inline links.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

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: 
 <20200515222321.GG24022@brevard.conman.org>
Message-ID: 

On Fri, May 15, 2020 at 3:23 PM Sean Conner  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: 

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: 
References: 
 
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: 
References: 
 <20200515222321.GG24022@brevard.conman.org>
 
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  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: 
References: 
 
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: 
References: 
Message-ID: 


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: 

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: 
 
 <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: 
References: 
 
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: 

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: 

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: 
References: <20200511001820.GI7305@brevard.conman.org>
 <20200511081816.GA23500@SDF.ORG> <20200511092101.GJ7305@brevard.conman.org>
 
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: 

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  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: 

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: 

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: 
References: 
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: 

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:

=>[][]

But no where else in the spec does it say that lines must end with
 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 , 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 , with the  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  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  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: 
References: 
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: 
References: 
Message-ID: <2TJFAQ.QMXFTMSB42CD2@kirgroup.net>



Il giorno gio 14 mag 2020 alle 13:29, Dunderpate  
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: 

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 

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  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: 

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: 

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: 

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  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: 
References: 
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: 

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: 
 <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: 

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 ,
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: 
 <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: 

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  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: 
References: 
 
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: 
 
 <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: 
References: 
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: 
References: 
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:
> 
> =>[][]
> 
> But no where else in the spec does it say that lines must end with
>  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  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: 
 <20200517084926.GD23565@SDF.ORG>
Message-ID: 


Just to add another small point: also in links section 1.3.5.3.2 it says


	=>[][]

	where:

	*  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: 
References: 
 
 <20200517084926.GD23565@SDF.ORG>
Message-ID: 

May 17, 2020 11:53 AM, "Fabio"  wrote:
> =>[][]
> 
> =>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: 
 <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: 
References: 
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: 
 <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: 
 
 <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: 
References: 
 
 <20200517084926.GD23565@SDF.ORG>
 
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"  wrote:
> > =>[][]
> > 
> > =>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: 

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  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: 

> 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: 
 
 <20200517084926.GD23565@SDF.ORG>
 
 <20200517095557.GN23565@SDF.ORG>
Message-ID: 



Il giorno dom 17 mag 2020 alle 09:55, solderpunk  
ha scritto:
> On Sun, May 17, 2020 at 08:57:13AM +0000, jan6 at tilde.ninja wrote:
>>  May 17, 2020 11:53 AM, "Fabio"  wrote:
>>  > =>[][> NAME>]
>>  >
>>  > =>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