[spec] comments on the proposed gemini spec revisions

Hi all,

Since I don't have (and am unable to create) a gitlab account, I wrote a
Gemlog post detailing my responses to a bunch of the issues on the
gitlab repos for Sean Conner's spec revisions.

Posting here to increase the likelyhood that other relevant people will
be able to see it.

=> //nytpu.com/gemlog/2021-10-10.gmi  Available over Gemini and HTTP

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com
https://useplaintext.email/

Alex // nytpu <alex@nytpu.com> writes:

> [[PGP Signed Part:Undecided]]
> Hi all,
>
> Since I don't have (and am unable to create) a gitlab account, I wrote a
> Gemlog post detailing my responses to a bunch of the issues on the
> gitlab repos for Sean Conner's spec revisions.

I can wholeheartedly agree with the gitlab rant.  I've never used it
before and was quite shocked of how bad it is.  Even github is "decent"
in this regard, on a technical level at least.  I can at least *read* a
README, the code or the issues with w3m.

But it's a sailed ship.  We can only try to prevent similar moves in the
future.

> Posting here to increase the likelyhood that other relevant people will
> be able to see it.
>
> => //nytpu.com/gemlog/2021-10-10.gmi  Available over Gemini and HTTP

I'm not sure if this is the best place to reply to you post, but the
alternative would be to open gitlab, post your link under the mentioned
issues and reply there which... I don't really want to do it.  If I can
avoid open gitlab, all the better ;-)

1. whitespace after gemtext elements

I don't have strong opinion on this, but on the other hand I don't see a
real motivation to require a space in your post nor in the gitlab
discussion.  Whitespaces should not be mandatory if not strictly
required to separate fields (like in a link line) in my opinion at
least.  But yes, I do always write '# hello there' and not '#hello
there'.

2. BOM

> If you're making something for non-tech people to use and they use bad
> editors that include a BOM, it should be your responsibility to remove
> it before publishing the document.

I'm not sure this would be viable.  If you look at the original report
from Gnuserland you'd see a confused user that doesn't know what a BOM
is or how to deal with it.  He simply typed something in his preferred
text editor (which is mis-configured btw, why would someone on unix
force CRLF line endings is beyond my understanding), published and it
was slightly broken.

Declaring it out-of-scope for the protocol but reminding client authors
that bad documents may have a BOM in the best practice document seem the
most sensible solution to me.

I even thought about adding some kind of "feedback" to the user on how
the page is structured.  Say some kind of linter for things like hard
wrapping, bom, etc.  It may become annoying thought.

3. close_notify

Is it still a problem? :D

(Sometimes I've left dangling questions like this hoping for Bortzmeyer
to chime in and share some stats.  In the past it worked, hope he share
some this time too ;-)

4. dumb new feature proposals

I just love reading them ;)

Taking this in slightly OT direction: in what manner should client
authors experiment with extensions in their clients?  I know there isn't
a reply, if the project is mine I can do the hell I want with it, and
since most (all?) clients are free software I can take an existing one
and modify the hell out of it, and I'm grateful for this.

I know also the "don't extend gemini" mantra, and I repeat myself too.

But does improving how a document is rendered account as extending the
protocol?  If I, say, replace the "---" lines with a nice separator,
does it count as extending gemini or just a rendering nicety of the
client?

(multi-level lists gravitates too much toward the extension side I
guess, but who cares)

> ~nytpu

On Mon, Oct 11, 2021 at 08:57:59AM +0200,
 Omar Polo <op@omarpolo.com> wrote 
 a message of 87 lines which said:

> 3. close_notify
> 
> Is it still a problem? :D

Yes :-(

> (Sometimes I've left dangling questions like this hoping for Bortzmeyer
> to chime in and share some stats.  In the past it worked, hope he share
> some this time too ;-)

"50.4 % of URLs do NOT send a proper TLS shutdown (application
close). Even 36.8 % of those who return status 20 are in that case."

The future RFC on HTTP (completely rewritten and reorganised) has a
nice explanation:

9.8.  TLS Connection Closure

   TLS uses an exchange of closure alerts prior to (non-error)
   connection closure to provide secure connection closure; see
   Section 6.1 of [TLS13].  When a valid closure alert is received, an
   implementation can be assured that no further data will be received
   on that connection.

   When an implementation knows that it has sent or received all the
   message data that it cares about, typically by detecting HTTP message
   boundaries, it might generate an "incomplete close" by sending a
   closure alert and then closing the connection without waiting to
   receive the corresponding closure alert from its peer.

   An incomplete close does not call into question the security of the
   data already received, but it could indicate that subsequent data
   might have been truncated.  As TLS is not directly aware of HTTP
   message framing, it is necessary to examine the HTTP data itself to
   determine whether messages were complete.  Handling of incomplete
   messages is defined in Section 8.

   When encountering an incomplete close, a client SHOULD treat as
   completed all requests for which it has received as much data as
   specified in the Content-Length header or, when a Transfer-Encoding
   of chunked is used, for which the terminal zero-length chunk has been
   received.  A response that has neither chunked transfer coding nor
   Content-Length is complete only if a valid closure alert has been
   received.  Treating an incomplete message as complete could expose
   implementations to attack.

   A client detecting an incomplete close SHOULD recover gracefully.

   Clients MUST send a closure alert before closing the connection.
   Clients that do not expect to receive any more data MAY choose not to
   wait for the server's closure alert and simply close the connection,
   thus generating an incomplete close on the server side.

   Servers SHOULD be prepared to receive an incomplete close from the
   client, since the client can often determine when the end of server
   data is.

   Servers MUST attempt to initiate an exchange of closure alerts with
   the client before closing the connection.  Servers MAY close the
   connection after sending the closure alert, thus generating an
   incomplete close on the client side.

And also:

11.3.  Message Integrity
...
   Care is needed however to ensure that connection closure
   cannot be used to truncate messages (see Section 9.8).  User agents
   might refuse to accept incomplete messages or treat them specially.
   For example, a browser being used to view medical history or drug
   interaction information needs to indicate to the user when such
   information is detected by the protocol to be incomplete, expired, or
   corrupted during transfer.  Such mechanisms might be selectively
   enabled via user agent extensions or the presence of message
   integrity metadata in a response.

Hello Alex,

I find using GitLab horrificly expedient, it would be nice to not be
dependent on it.

I am currently working on creating a GemText based issue tracker,
leveraging git repos and a simplified directory structure.

Hopefully, one day we can federate issue repos, using tools like
grokmirror and gitolite. And not be dependent on one gitforge in
particular.

Things I intend to work on include proxies for http issue pages and
kanban boards.

Im a big fan of elinks (though I stopped when it languished and need to
package the recent fork, felinks, which is developing Gemini
compatability). Should it get packaged on Guix (which Id like to get
around to) I will try that for a parsing environment. Perhaps people can
federate GemText equivalents as part of an eLinks (et al) hook.


Jonathan McHugh
indieterminacy@libre.brussels

Alex // nytpu <alex@nytpu.com> writes:

> [[PGP Signed Part:Undecided]]
> Hi all,
>
> Since I don't have (and am unable to create) a gitlab account, I wrote a
> Gemlog post detailing my responses to a bunch of the issues on the
> gitlab repos for Sean Conner's spec revisions.
>
> Posting here to increase the likelyhood that other relevant people will
> be able to see it.
>
> => //nytpu.com/gemlog/2021-10-10.gmi  Available over Gemini and HTTP
>
> ~nytpu

On Mon, 11 Oct 2021 at 09:12, Omar Polo <op@omarpolo.com> wrote:
> 1. whitespace after gemtext elements
>
> I don't have strong opinion on this, but on the other hand I don't see a
> real motivation to require a space in your post nor in the gitlab
> discussion.  Whitespaces should not be mandatory if not strictly
> required to separate fields (like in a link line) in my opinion at
> least.  But yes, I do always write '# hello there' and not '#hello
> there'.

As someone who's making a basic gemini client, having the whitespace
makes it alot simpler, you can just split the line on the space and do
a `switch` on the first part.
Not having a space means you'd have to test if the line starts with
different things, which would be very annoying and slower in most
cases.

Having the whitespace is easier for clients, and also looks better.
I see no downside to enforcing it in the spec (a SHOULD or MUST).

> Taking this in slightly OT direction: in what manner should client
> authors experiment with extensions in their clients?  I know there isn't
> a reply, if the project is mine I can do the hell I want with it, and
> since most (all?) clients are free software I can take an existing one
> and modify the hell out of it, and I'm grateful for this.
>
> I know also the "don't extend gemini" mantra, and I repeat myself too.

Clients can do what the hell they like IMO, as long as things that
transmit over the net obey the spec.
So gemtext is pretty unlimited, but making protocol requests is
strictly limited.
Something like replacing `---` is entirely a client-side thing and
affects no one but the reader.

The spec is a baseline for a minimum working thing, there's a reason
alot of it is "SHOULD''/"MAY" rather than "MUST".

-Oliver Simmons (GoodClover)

Oliver Simmons <oliversimmo@gmail.com> writes:

> On Mon, 11 Oct 2021 at 09:12, Omar Polo <op@omarpolo.com> wrote:
>> 1. whitespace after gemtext elements
>>
>> I don't have strong opinion on this, but on the other hand I don't see a
>> real motivation to require a space in your post nor in the gitlab
>> discussion.  Whitespaces should not be mandatory if not strictly
>> required to separate fields (like in a link line) in my opinion at
>> least.  But yes, I do always write '# hello there' and not '#hello
>> there'.
>
> As someone who's making a basic gemini client, having the whitespace
> makes it alot simpler, you can just split the line on the space and do
> a `switch` on the first part.
> Not having a space means you'd have to test if the line starts with
> different things, which would be very annoying and slower in most
> cases.
> Having the whitespace is easier for clients,

I've seen this argument in the gitlab issue too, but sorry, I don't
believe it.  In what language(s) splitting a string is faster than
checking for a prefix?  Splitting requires the allocation of multiple
objects, while the prefix only requires a scan of the first few bytes.

To be more precise: splitting on a space will always be slower than
checking for a prefix even if we ignore the cost of allocating the
strings because you'd have to first scan the string for the first space
(which can be far into the line) and then the cost of comparing strings
(i.e. another scan) while checking for a prefix requires always to only
compare the first few bytes.

Even if we eventually decide to mandate a whitespace, checking for a
prefix would still lead to better and faster code.

> and also looks better.

I totally agree!  It *absolutely* looks better, but I think we shouldn't
account for aesthetic too much in the spec, as they tend to change from
time to time and from one person to another.

> I see no downside to enforcing it in the spec (a SHOULD or MUST).

My argument is kind the opposite: if there isn't a (strong) reason for
requiring something, then that something MUST be optional.  Whitespaces
are required in the link line to separate unambiguously the link from
the label, the other whitespaces in the "special" lines don't serve this
purpose so they need to be completely optional.

>As someone who's making a basic gemini client, having the whitespace
>makes it alot simpler, you can just split the line on the space and do
>a `switch` on the first part.
>Not having a space means you'd have to test if the line starts with
>different things, which would be very annoying and slower in most
>cases.

Doesn't the spec say that line type indicators are only three characters 
maximum? It also implies that line type indicators should be the first 
thing on the line and that nothing should come before them (i.e. no 
whitespace before the indicator).

That should mean that simply taking a three character substring of the 
line should be enough to determine whether it has a line type indicator 
and, if so, which type. That should be relatively easy and quick to parse 
as there's only about 5-6 different cases to handle.

Stephane Bortzmeyer <stephane@sources.org> writes:

> On Mon, Oct 11, 2021 at 08:57:59AM +0200,
>  Omar Polo <op@omarpolo.com> wrote 
>  a message of 87 lines which said:
>
>> 3. close_notify
>> 
>> Is it still a problem? :D
>
> Yes :-(
>
>> (Sometimes I've left dangling questions like this hoping for Bortzmeyer
>> to chime in and share some stats.  In the past it worked, hope he share
>> some this time too ;-)
>
> "50.4 % of URLs do NOT send a proper TLS shutdown (application
> close). Even 36.8 % of those who return status 20 are in that case."

It's worst than what I thought!  We know what software this servers are
using?

Thanks for chiming in and also for sharing the excerpt about
close_notify :)

> The future RFC on HTTP (completely rewritten and reorganised) has a
> nice explanation:
>
> 9.8.  TLS Connection Closure
>
>    TLS uses an exchange of closure alerts prior to (non-error)
>    connection closure to provide secure connection closure; see
>    Section 6.1 of [TLS13].  When a valid closure alert is received, an
>    implementation can be assured that no further data will be received
>    on that connection.
>
>    When an implementation knows that it has sent or received all the
>    message data that it cares about, typically by detecting HTTP message
>    boundaries, it might generate an "incomplete close" by sending a
>    closure alert and then closing the connection without waiting to
>    receive the corresponding closure alert from its peer.
>
>    An incomplete close does not call into question the security of the
>    data already received, but it could indicate that subsequent data
>    might have been truncated.  As TLS is not directly aware of HTTP
>    message framing, it is necessary to examine the HTTP data itself to
>    determine whether messages were complete.  Handling of incomplete
>    messages is defined in Section 8.
>
>    When encountering an incomplete close, a client SHOULD treat as
>    completed all requests for which it has received as much data as
>    specified in the Content-Length header or, when a Transfer-Encoding
>    of chunked is used, for which the terminal zero-length chunk has been
>    received.  A response that has neither chunked transfer coding nor
>    Content-Length is complete only if a valid closure alert has been
>    received.  Treating an incomplete message as complete could expose
>    implementations to attack.
>
>    A client detecting an incomplete close SHOULD recover gracefully.
>
>    Clients MUST send a closure alert before closing the connection.
>    Clients that do not expect to receive any more data MAY choose not to
>    wait for the server's closure alert and simply close the connection,
>    thus generating an incomplete close on the server side.
>
>    Servers SHOULD be prepared to receive an incomplete close from the
>    client, since the client can often determine when the end of server
>    data is.
>
>    Servers MUST attempt to initiate an exchange of closure alerts with
>    the client before closing the connection.  Servers MAY close the
>    connection after sending the closure alert, thus generating an
>    incomplete close on the client side.
>
> And also:
>
> 11.3.  Message Integrity
> ...
>    Care is needed however to ensure that connection closure
>    cannot be used to truncate messages (see Section 9.8).  User agents
>    might refuse to accept incomplete messages or treat them specially.
>    For example, a browser being used to view medical history or drug
>    interaction information needs to indicate to the user when such
>    information is detected by the protocol to be incomplete, expired, or
>    corrupted during transfer.  Such mechanisms might be selectively
>    enabled via user agent extensions or the presence of message
>    integrity metadata in a response.
>

On 11/10/2021 13:51, Oliver Simmons wrote:
> Clients can do what the hell they like IMO, as long as things that
> transmit over the net obey the spec.
> So gemtext is pretty unlimited, but making protocol requests is
> strictly limited.
> Something like replacing `---` is entirely a client-side thing and
> affects no one but the reader.

The current spec states:

   Text lines should be presented to the user, after being wrapped to the
   appropriate width for the client's viewport (see below). Text lines
   may be
   presented to the user in a visually pleasing manner for general
   reading, the
   precise meaning of which is at the client's discretion. For example,
   variable width fonts may be used, spacing may be normalised, with spaces
   between sentences being made wider than spacing between words, and other
   such typographical niceties may be applied. Clients may permit users to
   customise the appearance of text lines by altering the font, font
   size, text
   and background colour, etc. Authors should not expect to exercise any
   control over the precise rendering of their text lines, only of
   their actual
   textual content.

This gives clients a broad discretion as to what visual modifications they 
make to text lines by altering font size, colours, spacing, etc. It 
doesn't appear to go as far as permitting clients to amend or replace the 
actual text that appears on a text line, and appears to suggest that 
authors should expect to exercise control over the precise rendering of 
their "actual textual content". (At least, my interpretation of the second 
last sentence is that clients may allow users to customise appearance of 
text lines by altering text colour, not text itself, though I appreciate 
it's slightly ambiguous.)

The problem I have with separators and similar visual niceties is that 
they involve deleting or replacing text that was put there by the author. 
What if an author didn't want to put a separator there, but really wanted 
to put "---"? Unless the spec provides that "---" means a separator it is 
not reasonable to expect authors to know that.

In truth I'm not sure in what circumstances a "---" text line would be 
intended as something other than a separator, but I'm sure other authors 
are more imaginative than I am. To take another example, I have regularly 
encountered situations where a single * in a markdown document is 
incorrectly interpreted as marking the beginning of italicised text, so 
the rest of the document is italicised inappropriately. I'd like for that 
not to become commonplace in Geminispace.

Separately, on the whitespace issue, I do think it would be helpful to 
clarify in the spec whether whitespace is mandatory, particularly for 
headers. For example, should the line "#### Hello" be interpreted as (i) a 
level 3 header whose text is "# Hello", or (ii) a text line whose text is 
"#### Hello"? AFAIK that is ambiguous unless there is a clear stance on 
mandatory whitespace in the spec.

On Mon, 11 Oct 2021 15:44:33 +0100, Alan Bunbury wrote:

> For example, should the line "#### Hello" be interpreted as (i)
> a level 3 header whose text is "# Hello", or (ii) a text line whose text
> is "#### Hello"? AFAIK that is ambiguous unless there is a clear stance
> on mandatory whitespace in the spec.

Considering 5.3 of the current spec, "#### Hello" is to be interpreted as 
(i), i. e. as a level-three-header with content "# Hello", I guess:

> It is possible to unambiguously determine a line's type purely by 
inspecting its first three characters.

https://gemini.circumlunar.space/docs/specification.gmi

October 11, 2021 10:44 AM, "Alan Bunbury" <gemini@bunburya.eu> wrote:

> In truth I'm not sure in what circumstances a "---" text line would be 
intended as something other
> than a separator, but I'm sure other authors are more imaginative than I 
am. To take another
> example, I have regularly encountered situations where a single * in a 
markdown document is
> incorrectly interpreted as marking the beginning of italicised text, so 
the rest of the document is
> italicised inappropriately. I'd like for that not to become commonplace in Geminispace.

I fail to see how replacing a line that has only `---` on it with a 
graphical separator is anything like the runaway italics thing you 
mentioned. Still, I can kind of see where you're going with that.

> Separately, on the whitespace issue, I do think it would be helpful to 
clarify in the spec whether
> whitespace is mandatory, particularly for headers. For example, should 
the line "#### Hello" be
> interpreted as (i) a level 3 header whose text is "# Hello", or (ii) a 
text line whose text is
> "#### Hello"? AFAIK that is ambiguous unless there is a clear stance on 
mandatory whitespace in the
> spec.

That is not ambiguous, with or without mandatory whitespace. As Plain Text 
pointed out, the max amount of characters used to determine the linetype 
is the first 3, per 5.3 in the gemtext spec (awkwardly numbered because it 
was originally part of the protocol spec):

> It is possible to unambiguously determine a line's type purely by 
inspecting its first three characters.

Therefore, any (good) client will see that the first 3 characters of the 
line are "###" and correctly call it what it is: a level 3 header with the 
text "# Hello". I fail to see how that would be ambiguous (I guess the 
spec doesn't do *that* good of a job explaining it, but I would think you 
could catch on by the fact that the section on header lines only gives 
examples of #, ##, and ###).

Just my two cents,
Robert "khuxkm" Miles

On Mon, 11 Oct 2021 at 15:12, Omar Polo <op@omarpolo.com> wrote:
> I've seen this argument in the gitlab issue too […]

I haven't checked the issue yet, will do after sending this.

> In what language(s) splitting a string is faster than
> checking for a prefix?  Splitting requires the allocation of multiple
> objects, while the prefix only requires a scan of the first few bytes.

I said simpler, not faster. What you said is true in some cases, but
not everyone is striving for optimisation speed-wise.

It'll depend on the language used, but splitting allows you to use a
simple equality switch statement, which isn't possible by checking
with a prefix.
The way I understand your message, I would have to use an else-if
list, which is hardly ideal.

e.g. in C#:
 ```
// If it's <3 chars then just treat it as a text line (the default).
switch ((line.Length < 3) ? "" : line.Substring(0, 3).Split(" ", 2)[0])
{
    case "=>": …
    case "* ": …
    … and so on …
    default: …
}
 ```
vs
 ```
if (line.StartsWith("=> ") {
    …
} else if (line.StartsWith("* ") {
    …
} … and so on …
else { … }
 ```

At the least, it should be required for link (as you said) and list
lines ("* "). I've seen where people have tried to use *emphasis* at
the start of a line and got a bullet point by mistake.

> > I see no downside to enforcing it in the spec (a SHOULD or MUST).
>
> My argument is kind the opposite: if there isn't a (strong) reason for
> requiring something, then that something MUST be optional.  Whitespaces
> are required in the link line to separate unambiguously the link from
> the label, the other whitespaces in the "special" lines don't serve this
> purpose so they need to be completely optional.

At the very least it should be recommended by the spec IMO.

-Oliver Simmons (GoodClover)

On Mon, 11 Oct 2021 at 15:07, Chris McGowan <cmcgowan9990@gmail.com> wrote:
> Doesn't the spec say that line type indicators are only three characters maximum?
> It also implies that line type indicators should be the first thing on 
the line and that nothing should come before them (i.e. no whitespace 
before the indicator).

Yes and yup, we're talking about the space after the indicator.

> That should mean that simply taking a three character substring of the 
line should be enough to determine whether it has a line type indicator 
and, if so, which type. That should be relatively easy and quick to parse 
as there's only about 5-6 different cases to handle.

Unfortunately, no. For example, take this line: `# Foo bar I'm a level-1 title`
A 3-char substring of that would yield "# F", which isn't useful.
It would work if the spec required (MUST) you to add whitespace
padding the indicator to three characters, but that's not how it is.

To determine the line-type you have to do a starts-with check or split
on the space like me and Omar are saying.

-Oliver Simmons (GoodClover)

> Unfortunately, no. For example, take this line: `# Foo bar I'm a level-1 title`
> A 3-char substring of that would yield "# F", which isn't useful.

In what way isn't it useful? It tells you literally everything you need to 
know. An example (in Perl):

 ```
my $first3 = substr $line, 0, 3;
# slightly magical regex, /g will return an array of matches,
# assigning back to a scalar gives us a count of matches
if ( my $level = $first3 =~ m/(#)+/g )
{
  return "Level $level header";
}
elsif ( $first3 =~ m/=>/ )
{
  return "Link"
}
elsif( $first3 =~ m/```/ )
{
  return "preformatted";
}
elsif( $first3 =~ m/\*/ )
{
  return "list item";
}
elsif ( $first3 =~ m/>/ )
{
  return 'Blockquote';
}
else
{
  return "Text";
}
 ```

That's a simplified, very naive gemtext parser I wrote in my email client 
in about 3 minutes. It took longer to remember all of the list types than 
it did to write the code for them. In fact, the substring isn't even 
necessary in this code as I could anchor the regex at the start of the line like so:

 ```
if ( $line =~ m/^\*/ )
{
  return "list item";
}
 ```

but that's largely true for languages which have decent regex support. If 
you weren't using one of those (i.e. C) or are for some reason allergic to 
regexes you could simply index the string to determine the line type 
(note: this would likely improve speed, but probably only a imperceptibly 
small amount and likely wouldn't be worth it.)

Just to really drive home the point that this isn't a difficult task, 
here's the version I wouldn't write unless I was using C (still in Perl though):

 ```
# Note: split here is because perl doesn't allow direct subscripting of
# strings. In languages that do allow that, this other array is
# unnecessary and you could use $line directly.
my @first3 = split( "", substr( $line, 0, 3));
if ( $first3[0] eq '#' )
{
  if ( $first3[1] eq '#' )
  {
    if ( $first3[2] eq '#' )
    {
      return "Level 3 header";
    }
    return "Level 2 header";
  }
  return "Level 1 header";
}
elsif ( $first3[0] eq '=' && $first3[1] eq '>' )
{
  return "link";
}
elsif ( $first3[0] eq '*' )
{
  return 'List Item';
}
elsif ($first3[0] eq '>' )
{
  return "Blockquote";
}
elsif( $first3[0] eq '`' && $first3[1] eq '`' && $first3[2] eq '`' )
{
  return "preformatted";
}
else
{
  return "Text";
}
 ```

It's a bit more annoying to write, sure but it's still really simple. 
That's ~33 lines of code (mostly because of the Allman style braces, 
honestly.) It only took me 5 minutes to write.

In summary, I hardly think it's impossible or even difficult to 
unambiguously parse gemtext without having a mandatory space.

Oliver Simmons <oliversimmo@gmail.com> writes:

> On Mon, 11 Oct 2021 at 15:12, Omar Polo <op@omarpolo.com> wrote:
>> I've seen this argument in the gitlab issue too […]
>
> I haven't checked the issue yet, will do after sending this.
>
>> In what language(s) splitting a string is faster than
>> checking for a prefix?  Splitting requires the allocation of multiple
>> objects, while the prefix only requires a scan of the first few bytes.
>
> I said simpler, not faster. What you said is true in some cases, but
> not everyone is striving for optimisation speed-wise.

You didn't said "faster", true, but said that (emphasis mine)

> Not having a space means you'd have to test if the line starts with
> different things, which would be very annoying and **slower** in most
> cases.

I was contradicting that.

> It'll depend on the language used, but splitting allows you to use a
> simple equality switch statement, which isn't possible by checking
> with a prefix.

(btw, checking for equality inside a switch statement doesn't work for
strings in languages like C or Java.  Err... yes, it works, but it's not
same the equality you mean ;-)

> The way I understand your message, I would have to use an else-if
> list, which is hardly ideal.

This depends on the language design.  Some languages allows expression
inside switches, like Go IIRC, so you could write

switch {
case strings.HasPrefix(line, "*"):
	// ...
case strings.HasPrefix(line, "###"):
	// ...
...
}

other allows to do more elaborate things (clojure for example)

(defn has-prefix? [prefix str]
  (str/starts-with? str prefix))

(condp has-prefix? line
  "*"   :item
  "=>"  :link
  "###" :header-3
  ,,,)

Even when we take into account an ancient language like C, you could
take advantage that the first byte of a line is enough to get an idea of
its type and greatly reduce the number of chained ifs:

(this is more or less what I have in telescope)

switch (*line) {
case '*': return LINE_ITEM;
case '>': return LINE_QUOTE;
case '=':
	if (line[1] == '>')
		return LINE_LINK;
	break;
case '#':
	/* some ifs to check whether is a level 1, 2 or 3 */
	...
case '`':
	/* check for a ``` marker */
	...
}
return LINE_TEXT;

I don't think taking into account the particularities of one specific
programming language is a wise choice for a markup language meant to be
written by humans for humans.

The question should thus become: is it intuitive for a random user that

#hello world

and

# hello world

are effectively the same line?

Let's forget the code when tackling these issues, we think better when
we're not in front of a keyboard.

> [...]
>
> At the least, it should be required for link (as you said) and list
> lines ("* ").

Probably I was too ambiguous.  My point was that in a link line a space
in necessary between the link and the label, not after the marker.  So,
outside of the mandatory space to separate a link and its label,
whitespaces are irrelevant.

> I've seen where people have tried to use *emphasis* at
> the start of a line and got a bullet point by mistake.

I've seen people writing like that, and a conforming client (IMHO)
should consider those lines items.

It's like using => something like this <= to highlight text and then
complaining that a client mis-render a line because the author tried to
"highlight" the first words and now it's a link.

Who cares?  Gemini doesn't have inline formatting, so why bother trying
to support it?

(I've used some *emphasis* on some pages too, but more I write and more
I think I shouldn't, it's easier to read without too much noise.  That's
my opinion, at least.)

Anyway, whatever the final decision will be, I hope we could at least
ensure that all the clients are consistent in their rendering.

>> > I see no downside to enforcing it in the spec (a SHOULD or MUST).
>>
>> My argument is kind the opposite: if there isn't a (strong) reason for
>> requiring something, then that something MUST be optional.  Whitespaces
>> are required in the link line to separate unambiguously the link from
>> the label, the other whitespaces in the "special" lines don't serve this
>> purpose so they need to be completely optional.
>
> At the very least it should be recommended by the spec IMO.
>
> -Oliver Simmons (GoodClover)

On Mon, 11 Oct 2021 15:15:44 +0000, Plain Text wrote:

> https://gemini.circumlunar.space/docs/specification.gmi

My try on identifying line types using Python re named groups 
what became a quite unreadable line, also missing ```, sorry.


line.py
    import re, sys
    for line in sys.stdin:
        m = 
re.match(r'((?P<heads>(?P<h3>###)|(?P<h2>##)|(?P<h1>#))|(?P<list>\* 
)|(?P<link>=> (?P<url>[^\s]+))|(?P<quote>>))\s*(?P<content>.*)$', line)
        if m:
            print(m.groupdict())

example.gmi
    # Heading of Level One
    ## Heading of Level Two
    ### Heading of Level Three
    ###Heading of Level Three Tight
    ####Heading of Level Three with starting hash
    #### Heading of Level Three with starting hash and space
    * list item
    *  list item spacey
    *   list item spaceous
    => http://example.org/no/name
    => http://example.org/with/name Linkname
    >Quote Tight
    > Quote Nice
    >>Quote starting with gt
    >>> Quote starting with two gts
    End

cat example.gmi | python line.py
    {'heads': '#', 'h3': None, 'h2': None, 'h1': '#', 'list': None, 
'link': None, 'url': None, 'quote': None, 'content': 'Heading of Level One'}
    {'heads': '##', 'h3': None, 'h2': '##', 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': None, 'content': 'Heading of Level Two'}
    {'heads': '###', 'h3': '###', 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': None, 'content': 'Heading of Level Three'}
    {'heads': '###', 'h3': '###', 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': None, 'content': 'Heading of Level Three Tight'}
    {'heads': '###', 'h3': '###', 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': None, 'content': '#Heading of Level 
Three with starting hash'}
    {'heads': '###', 'h3': '###', 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': None, 'content': '# Heading of Level 
Three with starting hash and space'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': '* ', 
'link': None, 'url': None, 'quote': None, 'content': 'list item'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': '* ', 
'link': None, 'url': None, 'quote': None, 'content': 'list item spacey'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': '* ', 
'link': None, 'url': None, 'quote': None, 'content': 'list item spaceous'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': None, 
'link': '=> http://example.org/no/name', 'url': 
'http://example.org/no/name', 'quote': None, 'content': ''}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': None, 
'link': '=> http://example.org/with/name', 'url': 
'http://example.org/with/name', 'quote': None, 'content': 'Linkname'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': '>', 'content': 'Quote Tight'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': '>', 'content': 'Quote Nice'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': '>', 'content': '>Quote starting with gt'}
    {'heads': None, 'h3': None, 'h2': None, 'h1': None, 'list': None, 
'link': None, 'url': None, 'quote': '>', 'content': '>> Quote starting with two gts'}

On Wed, 13 Oct 2021 at 21:38, Chris McGowan <cmcgowan9990@gmail.com> wrote:
>
> > Unfortunately, no. For example, take this line: `# Foo bar I'm a level-1 title`
> > A 3-char substring of that would yield "# F", which isn't useful.
>
> In what way isn't it useful? It tells you literally everything you need
> to know.

> my $first3 = substr $line, 0, 3;

*This* is what I assumed you mean by
> … simply taking a three character substring of the line should be enough …
Seems there was a misunderstanding or something, apologies.
I'll respond to the rest of the email with the assumption there wasn't
a misunderstanding.

> # slightly magical regex, /g will return an array of matches,
> # assigning back to a scalar gives us a count of matches
> if ( my $level = $first3 =~ m/(#)+/g )
> {
>    return "Level $level header";
> [...]
> ```

Using RegEx this way is in effect doing the starts-with method I
mentioned in my other email.

> In fact, the substring isn't even necessary in this code

"In what way isn't it useful?", here's the answer.
It's useful as a method for limiting counts of '#', but that could
also be done with a `max(count, 3)` or you might not even be doing
counts.

> but that's largely true for languages which have decent regex support.

A `.StartsWith(foo)` method works too.
For doing the counting '#' part this way, you'd do something along the lines of:
 ```C# code
if (line.StartWith('#')) {
    int count = line.SubString(0,3).Count(c => c == '#').Length;
OR
    int count = Math.Max(line.Count(c => c == '#').Length, 3);
 ```
(Note: this code isn't tested, and there are faster ways to count
chars than Count, it's used here for clarity)

> If you weren't using one of those (i.e. C) or are for some reason
> allergic to regexes you could simply index the string to determine the
> line type (note: this would likely improve speed, but probably only a
> imperceptibly small amount and likely wouldn't be worth it.)
>
> Just to really drive home the point that this isn't a difficult task,
> here's the version I wouldn't write unless I was using C (still in Perl
> though):
>
> ```
> # Note: split here is because perl doesn't allow direct subscripting of
> # strings. In languages that do allow that, this other array is
> # unnecessary and you could use $line directly.
> my @first3 = split( "", substr( $line, 0, 3));
> if ( $first3[0] eq '#' )
> {
>    if ( $first3[1] eq '#' )
>    {
>      if ( $first3[2] eq '#' )
>      {
>        return "Level 3 header";
>      }
>      return "Level 2 header";
>    }
>    return "Level 1 header";
> }

Certainly an interesting method for header lines.
Since this is "Perl but with C tactics" code: does Perl have a switch statement?

> In summary, I hardly think it's impossible or even difficult to
> unambiguously parse gemtext without having a mandatory space.

I never claimed that it wasn't, just that it's easier to program.


Here's a simple parser using the split-on-first-space method:
 ```C# code
// Max split of three is used so this can be re-used later when doing
link-lines, no need to do more than that anyways
string[] splitLine = line.Split(" ", 3)
switch (splitLine[0].SubString(0,3)) {
    case "#":
    case "##":
    case "###":
        Console.PrintLine("Header level of {0} with text {1}",
splitLine[0].Length, line[3..]);
        // Rather than counting the header length, you could also just
use the other `case` statements.
        break;
    case "=>":
        Console.PrintLine("Link line with link {0}, title {1}",
splitLine[1], splitLine[2]);
        break;
    [… and so on …]
    default:
        Console.PrintLine("Normal or preformatted line");
        break;
}
 ```

Thanks for your code examples,
-Oliver Simmons (GoodClover)

On Wed, 13 Oct 2021 at 22:40, Omar Polo <op@omarpolo.com> wrote:
> Oliver Simmons <oliversimmo@gmail.com> writes:
> > very annoying and **slower** in most cases.
> I was contradicting that.

Oops, my bad.

> > The way I understand your message, I would have to use an else-if
> > list, which is hardly ideal.
>
> This depends on the language design.  Some languages allows expression
> inside switches, like Go IIRC, so you could write
>
> […]

Interesting.
I don't have a clue how this would work internally, but I imagine it'd
be less optimised than equality.
Although what you mentioned about string equality has me doubting
that's well optimised either… this is getting waay off topic :P

> I don't think taking into account the particularities of one specific
> programming language is a wise choice for a markup language meant to be
> written by humans for humans.

I'd've hoped I wasn't taking a too narrow viewpoint with my language
experience (Py3, C# & a little Go).
C# is used here as I've got a basic Gemini client made in it, and
that's in C# as I have to use it for my education :p

> Gemini doesn't have inline formatting, so why bother trying to support it?

This is not about inline-formatting, using emphasis in text /like/
*this* has been a thing since before I breathed.

> (I've used some *emphasis* on some pages too, but more I write and more
> I think I shouldn't, it's easier to read without too much noise.  That's
> my opinion, at least.)

I find it useful in moderation, I'm not the best at conveying what I
mean so it helps.

-Oliver Simmons (GoodClover)

>Using RegEx this way is in effect doing the starts-with method I
>mentioned in my other email.

Sort of, its actually technically less efficient since a startsWith method 
should simply loop over the string. Regex is admittedly a bit overkill for 
this but being a Perl developer and the problem statement being parsing, 
it was the first thing I reached for.

You can actually accomplish this slightly more efficiently in Perl using 
the index (and in the case of headers, rindex) functions. 

Of course, gemini parsing is so light that the difference in execution 
speed/ memory use between either version is negligible in almost all cases.

>Since this is "Perl but with C tactics" code: does Perl have a switch statement?

Yes and no. It does have a switch statement but its use is heavily 
discouraged as it was a (failed) experiment and will likely be removed in 
the near future. If you want a switch like construct in Perl, the general idiom is:

 ```
for ( $var )
{
  if ( /a/ )
  {
     # do a stuff
  }
  elsif ( /b/ )
  {
    # do b stuff
  }
  else
  {
     # do default stuff
  }
}
 ```

Of course there's several CPAN modules which also implement a switch 
statement, so you're free to use any of them if that's not to your liking.

FWIW, the equivalent C version would not be shorter for using switch 
statements as switches in C can only work on integers and chars (which are 
also technically integers). You would have to either have nested ifs or 
nested switches, neither of which is pretty.

>> In summary, I hardly think it's impossible or even difficult to
>> unambiguously parse gemtext without having a mandatory space.
>
>I never claimed that it wasn't, just that it's easier to program.

Ah I thought you meant that the first three characters were somehow not 
enough to unambiguously parse the line without the mandatory space. 
Apologies for the misunderstanding. 

Given that argument, I would say I'm not sure that it's worth adding a 
requirement which burdens the user (admittedly very minorly) just as a 
very small benefit to the programmer parsing it. 

If you're going to lay additional requirements on the user, the benefits 
of simplifying the parsing has to be fairly substantial (at least IMO). In 
this case we're talking about reducing a ~20 line function to a ~10 line 
function. Pretty small potatoes.

On 2021-10-13 22:56, Omar Polo wrote:
> > I've seen where people have tried to use *emphasis* at
> > the start of a line and got a bullet point by mistake.
> 
> I've seen people writing like that, and a conforming client (IMHO)
> should consider those lines items.

This is not true. A space after "*" is required.


### 5.5.2 Unordered list items

Lines beginning with "* " 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 "* " should be presented to the user as
if it were a text line, i.e.  wrapped to fit the viewport and formatted
"nicely".  Advanced clients can take the space of the bullet symbol into
account when wrapping long list items to ensure that all lines of text
corresponding to the item are offset an equal distance from the edge of
the screen.

Anna “CyberTailor” <cyber@sysrq.in> writes:

> On 2021-10-13 22:56, Omar Polo wrote:
>> > I've seen where people have tried to use *emphasis* at
>> > the start of a line and got a bullet point by mistake.
>> 
>> I've seen people writing like that, and a conforming client (IMHO)
>> should consider those lines items.
>
> This is not true. A space after "*" is required.
>
>
> ### 5.5.2 Unordered list items
>
> Lines beginning with "* " 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 "* " should be presented to the user as
> if it were a text line, i.e.  wrapped to fit the viewport and formatted
> "nicely".  Advanced clients can take the space of the bullet symbol into
> account when wrapping long list items to ensure that all lines of text
> corresponding to the item are offset an equal distance from the edge of
> the screen.

Thanks for the clarification, I missed that a space is required there.
A bit annoying IMHO, but if it's the spec, it's the spec.

I have some code to fix :/

Just to clarify, the reason there's a debate raised at all about spaces
or not is that some of the line types have a required space, and the
rest have optional spaces.  The inconsistency is confusing (as you've
demonstrated), so it'd be better to either make all the lines have a
required space, or make all the lines have optional spaces.  Just in my
own personal opinion on Gemtext style I think it'd be better to make
them all have mandatory spaces.

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com
https://useplaintext.email/

On Mon, 11 Oct 2021 at 09:12, Omar Polo <op@omarpolo.com> wrote:
> 1. whitespace after gemtext elements

While we're on the subject, I had a little idea:
The spec could clarify that whitespace is to be stripped after the 
(possibly empty) linetype identifier for *all* line types (outside 
preformatted mode).

The main point is that this would apply in particular to the text 
linetype. Currently some clients strip whitespace at the start of text 
lines, while others display it. If stripping it were standardised, then 
we could safely use this as a quotation mechanism, allowing text lines 
which start with one of the magic sequences identifying another 
linetype.

This would also clarify what to do with whitespace after '>' and '```', 
which the current spec doesn't.

(Apologies to those on the list if any of this repeats what's in the 
gitlab comments, but I'm not about to fire up a javascript browser just 
to check...)

> Message: 3
> Date: Thu, 14 Oct 2021 09:56:32 -0600
> From: Alex // nytpu <alex@nytpu.com>
> To: Gemini Mailing List <gemini@lists.orbitalfox.eu>
> Subject: Re: [spec] comments on the proposed gemini spec revisions
> Message-ID: <20211014155632.tcepvij3ofsv27cw@GLaDOS.local>
> Content-Type: text/plain; charset="utf-8"
> 
> Just to clarify, the reason there's a debate raised at all about spaces
> or not is that some of the line types have a required space, and the
> rest have optional spaces.  The inconsistency is confusing (as you've
> demonstrated), so it'd be better to either make all the lines have a
> required space, or make all the lines have optional spaces.  Just in my
> own personal opinion on Gemtext style I think it'd be better to make
> them all have mandatory spaces.
> 
> ~nytpu


This is on purpose to address instances where folks may have text-style 
emphasis on a word, starting a line with *bold*, and it was pointed out 
that this would insert an unwanted unordered list--this could be for 
existing gopher text files, or for folks trying to add emphasis in their 
gemtext (since there is no inline emphasis). By requiring the space, it 
ameliorates that potential problem. So it's not different just to be 
inconsistent, there's a reason behind it. And the reason the other ones 
weren't changed was to allow the 'freedom' part, if it's not MUST then it's MAY.

On Sun Oct 10, 2021 at 11:57 PM PDT, Omar Polo wrote:
>
> Alex // nytpu <alex@nytpu.com> writes:
>
> > [[PGP Signed Part:Undecided]]
> > Hi all,
> >
> > Since I don't have (and am unable to create) a gitlab account, I wrote a
> > Gemlog post detailing my responses to a bunch of the issues on the
> > gitlab repos for Sean Conner's spec revisions.
>
> I can wholeheartedly agree with the gitlab rant. I've never used it
> before and was quite shocked of how bad it is. Even github is "decent"
> in this regard, on a technical level at least. I can at least *read* a
> README, the code or the issues with w3m.
>
> But it's a sailed ship. We can only try to prevent similar moves in the
> future.

Should sourcehut https://sr.ht/ be considered? It is also FOSS, has the
features we are looking for from a git forge, already has a vibrant
Gemini community, and places a much higher priority on supporting
alternative browsers / graceful degradation. I apologize if this was
already discussed originally.

Alex

> This is on purpose to address instances where folks may have text-style
> emphasis on a word, starting a line with *bold*, and it was pointed out
> that this would insert an unwanted unordered list--this could be for
> existing gopher text files, or for folks trying to add emphasis in their
> gemtext (since there is no inline emphasis). By requiring the space, it
> ameliorates that potential problem. So it's not different just to be
> inconsistent, there's a reason behind it. And the reason the other ones
> weren't changed was to allow the 'freedom' part, if it's not MUST then
> it's MAY.

I am not sure why this is even an issue up for discussion.  I am all for 
using *emphasis* and optionally styling emphasized text. However, the spec 
explicitly states what the initial * means.

Should we address the case of someone who wants it to mean something else? 
What about those who want to write things like:
=>Haha!<=
Should this case be discussed too?

Anyone who wishes for the * to mean something it does not can stick a 
space _in front of it_.  If they don't like how it looks, they can look at 
the available UTF-8 glyphs that are space-like but narrower.

Can we please keep the spec small...

The spec currently indicates that there must be a space after the 
asterisk; the asterisk alone is not enough. I'd like to express support 
for the spec as it stands (space required), as asterisks have been in 
common use for plain text emphasis for as long as I've used the internet. 
Since many people compose their gemtext by hand, allowing the space to be 
omitted would likely cause quite a few accidental lists.

October 16, 2021 3:13 PM, stack@tilde.club wrote:

>> This is on purpose to address instances where folks may have text-style
>> emphasis on a word, starting a line with *bold*, and it was pointed out
>> that this would insert an unwanted unordered list--this could be for
>> existing gopher text files, or for folks trying to add emphasis in their
>> gemtext (since there is no inline emphasis). By requiring the space, it
>> ameliorates that potential problem. So it's not different just to be
>> inconsistent, there's a reason behind it. And the reason the other ones
>> weren't changed was to allow the 'freedom' part, if it's not MUST then
>> it's MAY.
> 
> I am not sure why this is even an issue up for discussion. I am all for 
using *emphasis* and
> optionally styling emphasized text. However, the spec explicitly states 
what the initial * means.
> 
> Should we address the case of someone who wants it to mean something 
else? What about those who
> want to write things like:
> =>Haha!<=
> Should this case be discussed too?
> 
> Anyone who wishes for the * to mean something it does not can stick a 
space _in front of it_. If
> they don't like how it looks, they can look at the available UTF-8 
glyphs that are space-like but
> narrower.
> 
> Can we please keep the spec small...

I thought I was way overstepping my bounds when suggesting multi-level
lists for Gemtext in my post but now people want to de-facto require
full-fledged markdown in Gemini clients; my simple and miniscule
suggestion doesn't seem so bad now lol.

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com
https://useplaintext.email/

Hi Alex,

Alex // nytpu <alex@nytpu.com> writes:

> [[PGP Signed Part:Undecided]]
> I thought I was way overstepping my bounds when suggesting multi-level
> lists for Gemtext in my post but now people want to de-facto require
> full-fledged markdown in Gemini clients; my simple and miniscule
> suggestion doesn't seem so bad now lol.

Yesss, indeed. The times they are achanging ...

Cheers,
and keep posting, I *do* read your entries :-)

~ew


-- 
Keep it simple!

> The spec currently indicates that there must be a space after the 
asterisk; the asterisk alone is not enough. I'd like to express support 
for the spec as it stands (space required), as asterisks have been in 
common use for plain text emphasis for as long as I've used the internet. 
Since many people compose their gemtext by hand, allowing the space to be 
omitted would likely cause quite a few accidental lists.

I stand corrected.  This is exactly why it would make sense to not have any spaces.

Ariane client I use extensively thinks that #, ## and ### must be followed 
by a space to be deleted.  Many headers are missing the first letter.  As 
you see, Oppen was confused.  I was confused.

If we cared about a minimal and consistent way to deal with this, we would 
_not_  require spaces anywhere.  The corner case of misusing * for 
emphasis (not in the spec) should not force everyone to insert and 
transmit billions of spaces from now till the end of time (I am an optimist).

It would be so much easier to not require spaces.  It would eliminate the 
silly assumption that people actually put spaces there, as well as having 
to delete them for a 'nicer' rendering.

Gemini will be remembered as a minimal protocol with maximally
inconsistent rules.  We have five linetypes: headers, bullets, quotes, 
links and preformatted text.  We have five different delimiters: space for 
a single-character *, no space for a single-character >, no space for a 
one-, two- or three-character header #s, an optional whitespace(!) for a a 
two-character link, and a global toggle for a three-character 
pre-formatted text.  On the positive side, I can fit that into a paragraph.

I'd like some of what solderpunk was smoking on that day!  Not even 
sarcastically - I want some.

Having said that, I love Gemini and will support whatever spec is adapted.

I'll own that. It would be nice, but I don't see it ever happening because
smoll. I mean I respect it, and I guess we'd have to make yet another spec
for one step up from Gemini but not quite HTML/CSS/JS, but too many
standards...
Devin Prater
r.d.t.prater@gmail.com
gemini://tilde.pink/~devinprater/



On Sat, Oct 16, 2021 at 10:56 PM Alex // nytpu <alex@nytpu.com> wrote:

> I thought I was way overstepping my bounds when suggesting multi-level
> lists for Gemtext in my post but now people want to de-facto require
> full-fledged markdown in Gemini clients; my simple and miniscule
> suggestion doesn't seem so bad now lol.
>
> ~nytpu
>
> --
> Alex // nytpu
> alex@nytpu.com
> gpg --locate-external-key alex@nytpu.com
> https://useplaintext.email/
>

Not infrequently I see a proposal float by this list, and I think "You 
want beautifully clean HTML5 served up over HTTP. There's nothing wrong or 
even lesser with serving up beautifully-clean HTML over port 443. There 
should be more of that in the world."

That doesn't keep me from occasionally wanting this or that from the 
HTML-over-HTTP world on my capsule. The latest feature to cross my mind: 
capsule-author-supplied fonts.

And then I remember how fantastically *nice* it is to have so many 
easily-made clients, and how utterly refreshing that is compared to the 
HTML-over-HTTP world.

On Sun, Oct 17, 2021, at 7:52 AM, Devin Prater wrote:
> I'll own that. It would be nice, but I don't see it ever happening 
because smoll. I mean I respect it, and I guess we'd have to make yet 
another spec for one step up from Gemini but not quite HTML/CSS/JS, but 
too many standards...
> Devin Prater
> r.d.t.prater@gmail.com
> gemini://tilde.pink/~devinprater/
> 
> 
> 
> On Sat, Oct 16, 2021 at 10:56 PM Alex // nytpu <alex@nytpu.com> wrote:
>> I thought I was way overstepping my bounds when suggesting multi-level
>> lists for Gemtext in my post but now people want to de-facto require
>> full-fledged markdown in Gemini clients; my simple and miniscule
>> suggestion doesn't seem so bad now lol.
>> 
>> ~nytpu
>> 
>> -- 
>> Alex // nytpu
>> alex@nytpu.com
>> gpg --locate-external-key alex@nytpu.com
>> https://useplaintext.email/

"alex wennerberg" <alex@alexwennerberg.com> writes:

> On Sun Oct 10, 2021 at 11:57 PM PDT, Omar Polo wrote:
>>
>> Alex // nytpu <alex@nytpu.com> writes:
>>
>> > [[PGP Signed Part:Undecided]]
>> > Hi all,
>> >
>> > Since I don't have (and am unable to create) a gitlab account, I wrote a
>> > Gemlog post detailing my responses to a bunch of the issues on the
>> > gitlab repos for Sean Conner's spec revisions.
>>
>> I can wholeheartedly agree with the gitlab rant. I've never used it
>> before and was quite shocked of how bad it is. Even github is "decent"
>> in this regard, on a technical level at least. I can at least *read* a
>> README, the code or the issues with w3m.
>>
>> But it's a sailed ship. We can only try to prevent similar moves in the
>> future.
>
> Should sourcehut https://sr.ht/ be considered? It is also FOSS, has the
> features we are looking for from a git forge, already has a vibrant
> Gemini community, and places a much higher priority on supporting
> alternative browsers / graceful degradation. I apologize if this was
> already discussed originally.

IIRC one day various months ago we were all disappointed of the flood of
emails, pointless whining & co, so someone proposed to move the
discussion to a different place.  Gitlab was then proposed, and quickly
after (IMHO too quickly but anyway) the gitlab thing happened.

In some way, it was a good move: the discussion around the
standardisation stagnated pretty quickly after the move.

(I may sound ironic, but I'm kinda serious: the stagnation of the gitlab
repo has somehow proven that, after all, gemini is quite finished.  Yes,
we have some doubts on how to handle some edge cases, but globally the
community has more or less settled on how things should be and that's
that.)

Various months passed, and is too late to move to another platform, but
we should keep in mind the "gemini gitlab fiasco" for the future ;)

> Alex

Devin Prater <r.d.t.prater@gmail.com> writes:

> I'll own that. It would be nice, but I don't see it ever happening 
because smoll. I mean I respect it, and I guess we'd have to make
> yet another spec for one step up from Gemini but not quite HTML/CSS/JS, 
but too many standards...

There's one more point that we should probably consider: gemini is
actually something clearly different from the web.  It provides almost a
completely different experience.  We should treasure it.

I mean, if all we do is trying to replicate the web (or being too
similar to it -- first-citizen markdown would do it) why would someone
use Gemini at all?  At that point why don't use the web?

It's sound harsh but how could you sell gemini if it was just a fake
web?

Being different is what can make people want to give it at least a try.
Maybe they end up disliking it and going back to the web, that's fine.
But why even bothering trying something when you know that's only fake?
Meh

> Devin Prater
> r.d.t.prater@gmail.com
> gemini://tilde.pink/~devinprater/
>
> On Sat, Oct 16, 2021 at 10:56 PM Alex // nytpu <alex@nytpu.com> wrote:
>
>  I thought I was way overstepping my bounds when suggesting multi-level
>  lists for Gemtext in my post but now people want to de-facto require
>  full-fledged markdown in Gemini clients; my simple and miniscule
>  suggestion doesn't seem so bad now lol.
>
>  ~nytpu
>
>  -- 
>  Alex // nytpu
>  alex@nytpu.com
>  gpg --locate-external-key alex@nytpu.com
>  https://useplaintext.email/

On Tue, Oct 19, 2021 at 07:03:18PM +0200,
 Omar Polo <op@omarpolo.com> wrote 
 a message of 46 lines which said:

> the stagnation of the gitlab repo has somehow proven that, after
> all, gemini is quite finished.  Yes, we have some doubts on how to
> handle some edge cases, but globally the community has more or less
> settled on how things should be and that's that.)

I disagree with this assessment. The specification is still in poor
shape, many cases are not documented, there is no agreement on very
important things like TLS close notify or IDN and, even when there is,
it is not documented so newcomers cannot get it, they have to rely on
the hidden knowledge of some old timers. Hardly satisfying.

(Not documenting thing is a common way to keep power.)

I agree.  The fact that there was very lively and active discussion on
the spec that immediately ceased and stagnated after the move to gitlab
serves to prove that most people agree with my opinion on gitlab and are
unwilling to participate there rather than the spec being "done."  A
community doesn't immediately shift from "we have to talk about these
issues" to "oh it's finished we're done" in the span of five minutes.
Especially when you take into account how many of the issues have no
sort of resolution and the misleading comments have gone months without
being countered.

Considering that I was **not allowed to create a gitlab account** due to
"browser checks" means that even if a lot of people were willing to
create an account they were probably stuck and unable to participate.

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com

It was thus said that the Great Alex // nytpu once stated:
> I agree.  The fact that there was very lively and active discussion on
> the spec that immediately ceased and stagnated after the move to gitlab
> serves to prove that most people agree with my opinion on gitlab and are
> unwilling to participate there rather than the spec being "done."  A
> community doesn't immediately shift from "we have to talk about these
> issues" to "oh it's finished we're done" in the span of five minutes.
> Especially when you take into account how many of the issues have no
> sort of resolution and the misleading comments have gone months without
> being countered.
> 
> Considering that I was **not allowed to create a gitlab account** due to
> "browser checks" means that even if a lot of people were willing to
> create an account they were probably stuck and unable to participate.

  Back on April 17th of this year, I wrote the following to solderpunk:

	I've had time to think about it, and no.  I don't want to take it
	over, nor do I want to continue finalizing the specification(s). 
	I'm will to hand over the protocol specification, and the gitlab
	tracking system, to the next person in line.  As far as I'm
	concerned, I don't have it in me to work further on Gemini---there
	are too many people with too many divergent opinions on how it
	should all work.  My thoughts on protocol design have also changed
	since I started, but I haven't solidified the thoughts on it yet. 
	Gemini itself seems to be chugging along, yet the community that's
	there now is not necessarily one I would join (it's not good or bad,
	just different than what I expect).

  And on April 18th of this year, I got the following reply from solderpunk:

	Thanks for giving it some thought and getting back to me. ...
	
	I'm not 100% sure what I'll do now instead, but that's entirely my
	problem.

  Why the long delay in saying "I quit"?  Because I was hoping for
solderpunk to make an announcement first, but well ... THAT never happened. 
I then decided to wait and see what happens.

  Nothing.

  Other than insults the past two weeks.

  Not ONE person here who had showed interest in finalizing the spec
bothered to reach out and say, "What's up with the spec?" or "Are you still
working on the spec?"  or even "Hey! Haven't heard from you for some time."

  Nothing.

  Yes, solderpunk offered to hand the entire project off to me, so to
Stephane Bortzmeyer who said:

> (Not documenting thing is a common way to keep power.)

  Sorry, I'm not into keeping power.

  And to nytpu:

> I thought I was way overstepping my bounds when suggesting multi-level
> lists for Gemtext in my post but now people want to de-facto require
> full-fledged markdown in Gemini clients; my simple and miniscule
> suggestion doesn't seem so bad now lol.

  When solderpunk handed control over to me to finalize the spec, the ONE
condition he mandated, was, and I'm quoting here:

> I don't want to move from single level lists to up to three-level lists.
> 
> I think at this point I'm happy to defer to you on the rest of these.

  A hard NO from solderpunk himself.

  So the Gemini protocol has been adrift for the past seven months.  I'm not
working on it anymore, and I haven't since April 17th.  Unless you (the
collective you, not any single person) can rope in solderpunk, you're on
your own.  Move the discussion off gitlab, I don't care at this point.

  Oh, and one more thing---my Gemini site has been down for the past few
days.  Why?  Mainly because I got tired of poorly written Gemini bots stuck
in my redirection tests for *weeks!*  If the authors don't care that their
bots are wasting time and resources on following endless redirects, then I
don't care about outing these idiots.  These are the top 10 bots over the
past four weeks:

   2155 remote=35.177.211.100
   1876 remote=52.56.164.254
   1764 remote=107.10.102.253
   1686 remote=35.178.189.57
   1652 remote=18.170.67.76
   1615 remote=13.40.12.172
   1576 remote=18.134.157.124
   1536 remote=18.169.104.124
   1498 remote=13.40.24.31
   1412 remote=18.134.208.115

  Of course, there are over 580 bots that have followed those redirects 100
or more times in the past four weeks.

  -spc ("I don't know half of you as well as I should like, and I like less
	than half of you half as well as you deserve.")

> Not ONE person here who had showed interest in finalizing the spec

In my personal defense? I am not a coder, not versed in the knowledge 
needed to have a worthwhile discussion on the wider spec, and I'm too new 
and infrequent to the group to be a rabblerouser.

The overal tone of your post has a very 'I'm fed up, I'm angrily lashing 
out at anyone and everyone and I don't care if it's productive or hurts anyone else.'

It leaves me not terribly confident since if the guys up top are willing 
to throw a snit fit at the whole mailing list? I guess the one saving 
grace is the code exists. Even if 'you' personally decide to throw your 
hands up and devolve into screaming at the whole list? The servers that 
exist work. The Gemini sphere won't instantly collapse on itself.

Sure in the future with an incomplete spec and the original people leading 
the charge not slowly fading away but instead shouting at everyone else 
'YOU'RE NOT DOING ENOUGH!' Will have a chilling effect that will leave us 
in the same spot as gopher.

Gemini's growth has been due to the excitement and buzzz that originates 
in places like this. that buzz dies when the defacto leaders start having 
'old man shouting at clouds' moments, except directed at the very users 
they're hoping will be constructive.


In short: Dude, you're angry, and I understand... but chill.

On 2021-10-20 19:39, Sean Conner wrote:
>   Oh, and one more thing---my Gemini site has been down for the past few
> days.  Why?  Mainly because I got tired of poorly written Gemini bots stuck
> in my redirection tests for *weeks!*  If the authors don't care that their
> bots are wasting time and resources on following endless redirects, then I
> don't care about outing these idiots.  These are the top 10 bots over the
> past four weeks:

This is disappointing. Gemini was meant for humans but got full of
stupid* bots (like everything on the net).

* disrespecting robots.txt, the protocol spec and common sense

Fail2ban or "44 slow down" can be used to stop them though.

It was thus said that the Great Andrew Singleton once stated:
> > Not ONE person here who had showed interest in finalizing the spec
> 
> In my personal defense? I am not a coder, not versed in the knowledge 
> needed to have a worthwhile discussion on the wider spec, and I'm too 
> new and infrequent to the group to be a rabblerouser.
> 
> The overal tone of your post has a very 'I'm fed up, I'm angrily lashing 
> out at anyone and everyone and I don't care if it's productive or hurts 
> anyone else.'

  I was fed up seven months ago.  The last post to the mailing list (aside
from today) was April 13th.  Seven months ago.  I thought my post was pretty
chill.  I mean, did you catch this from nytpu?

	First, we have to talk about the absolute galaxy brain decision by
	Stéphane Bortzmeyer and Sean Conner to use gitlab of all places for
	discuss the Gemini specification.

	...

	Okay, so after that big "fuck you" to anybody not using a graphical
	browser ...

	...

	So after three big "fuck you"s you are forced to use your graphical
	browser with javascript enabled, and now you can actually read the
	full discussions.  But you still can't participate at all because of
	course you need an account, a fourth "fuck you."

(gemini://nytpu.com/gemlog/2021-10-10.gmi)

  Yeah, I'm not regretting my decision to leave.

> It leaves me not terribly confident since if the guys up top are willing
> to throw a snit fit at the whole mailing list? I guess the one saving
> grace is the code exists. Even if 'you' personally decide to throw your
> hands up and devolve into screaming at the whole list? The servers that
> exist work. The Gemini sphere won't instantly collapse on itself.
> 
> Sure in the future with an incomplete spec and the original people 
> leading the charge not slowly fading away but instead shouting at 
> everyone else 'YOU'RE NOT DOING ENOUGH!' Will have a chilling effect 
> that will leave us in the same spot as gopher.
> 
> Gemini's growth has been due to the excitement and buzzz that originates 
> in places like this. that buzz dies when the defacto leaders start 
> having 'old man shouting at clouds' moments, except directed at the very 
> users they're hoping will be constructive.

  Yeah, I made the right decision to leave.

> In short: Dude, you're angry, and I understand... but chill.

  Angry?  Not really.

  -spc

It was thus said that the Great Anna “CyberTailor” once stated:
> On 2021-10-20 19:39, Sean Conner wrote:
> >   Oh, and one more thing---my Gemini site has been down for the past few
> > days.  Why?  Mainly because I got tired of poorly written Gemini bots stuck
> > in my redirection tests for *weeks!*  If the authors don't care that their
> > bots are wasting time and resources on following endless redirects, then I
> > don't care about outing these idiots.  These are the top 10 bots over the
> > past four weeks:
> 
> This is disappointing. Gemini was meant for humans but got full of
> stupid* bots (like everything on the net).
> 
> * disrespecting robots.txt, the protocol spec and common sense

  Yeah, tell me about it.  Here's the robots.txt I had (have):

User-agent: *
Disallow: /test/redirhell

# Following content a mirror of http://boston.conman.org/

User-agent: archiver
Disallow: /test/redirhell
Disallow: /boston

  And the majority of traffic to my site?  Bots.  Crawling through
/test/redirhell or /boston.  

> Fail2ban or "44 slow down" can be used to stop them though.

  Yes.  Or you know, just as easy to stop running the server.

  -spc

Thanks for all your help!

====================
Jonathan McHugh
indieterminacy@libre.brussels

October 21, 2021 1:39 AM, "Sean Conner" <sean@conman.org> wrote:

> It was thus said that the Great Alex // nytpu once stated:
> 
>> I agree. The fact that there was very lively and active discussion on
>> the spec that immediately ceased and stagnated after the move to gitlab
>> serves to prove that most people agree with my opinion on gitlab and are
>> unwilling to participate there rather than the spec being "done." A
>> community doesn't immediately shift from "we have to talk about these
>> issues" to "oh it's finished we're done" in the span of five minutes.
>> Especially when you take into account how many of the issues have no
>> sort of resolution and the misleading comments have gone months without
>> being countered.
>> 
>> Considering that I was **not allowed to create a gitlab account** due to
>> "browser checks" means that even if a lot of people were willing to
>> create an account they were probably stuck and unable to participate.
> 
> Back on April 17th of this year, I wrote the following to solderpunk:
> 
> I've had time to think about it, and no. I don't want to take it
> over, nor do I want to continue finalizing the specification(s).
> I'm will to hand over the protocol specification, and the gitlab
> tracking system, to the next person in line. As far as I'm
> concerned, I don't have it in me to work further on Gemini---there
> are too many people with too many divergent opinions on how it
> should all work. My thoughts on protocol design have also changed
> since I started, but I haven't solidified the thoughts on it yet.
> Gemini itself seems to be chugging along, yet the community that's
> there now is not necessarily one I would join (it's not good or bad,
> just different than what I expect).
> 
> And on April 18th of this year, I got the following reply from solderpunk:
> 
> Thanks for giving it some thought and getting back to me. ...
> 
> I'm not 100% sure what I'll do now instead, but that's entirely my
> problem.
> 
> Why the long delay in saying "I quit"? Because I was hoping for
> solderpunk to make an announcement first, but well ... THAT never happened.
> I then decided to wait and see what happens.
> 
> Nothing.
> 
> Other than insults the past two weeks.
> 
> Not ONE person here who had showed interest in finalizing the spec
> bothered to reach out and say, "What's up with the spec?" or "Are you still
> working on the spec?" or even "Hey! Haven't heard from you for some time."
> 
> Nothing.
> 
> Yes, solderpunk offered to hand the entire project off to me, so to
> Stephane Bortzmeyer who said:
> 
>> (Not documenting thing is a common way to keep power.)
> 
> Sorry, I'm not into keeping power.
> 
> And to nytpu:
> 
>> I thought I was way overstepping my bounds when suggesting multi-level
>> lists for Gemtext in my post but now people want to de-facto require
>> full-fledged markdown in Gemini clients; my simple and miniscule
>> suggestion doesn't seem so bad now lol.
> 
> When solderpunk handed control over to me to finalize the spec, the ONE
> condition he mandated, was, and I'm quoting here:
> 
>> I don't want to move from single level lists to up to three-level lists.
>> 
>> I think at this point I'm happy to defer to you on the rest of these.
> 
> A hard NO from solderpunk himself.
> 
> So the Gemini protocol has been adrift for the past seven months. I'm not
> working on it anymore, and I haven't since April 17th. Unless you (the
> collective you, not any single person) can rope in solderpunk, you're on
> your own. Move the discussion off gitlab, I don't care at this point.
> 
> Oh, and one more thing---my Gemini site has been down for the past few
> days. Why? Mainly because I got tired of poorly written Gemini bots stuck
> in my redirection tests for *weeks!* If the authors don't care that their
> bots are wasting time and resources on following endless redirects, then I
> don't care about outing these idiots. These are the top 10 bots over the
> past four weeks:
> 
> 2155 remote=35.177.211.100
> 1876 remote=52.56.164.254
> 1764 remote=107.10.102.253
> 1686 remote=35.178.189.57
> 1652 remote=18.170.67.76
> 1615 remote=13.40.12.172
> 1576 remote=18.134.157.124
> 1536 remote=18.169.104.124
> 1498 remote=13.40.24.31
> 1412 remote=18.134.208.115
> 
> Of course, there are over 580 bots that have followed those redirects 100
> or more times in the past four weeks.
> 
> -spc ("I don't know half of you as well as I should like, and I like less
> than half of you half as well as you deserve.")

On Wed, Oct 20, 2021 at 07:39:23PM -0400,
 Sean Conner <sean@conman.org> wrote 
 a message of 101 lines which said:

>   Yes, solderpunk offered to hand the entire project off to me, so to
> Stephane Bortzmeyer who said:
> 
> > (Not documenting thing is a common way to keep power.)
> 
>   Sorry, I'm not into keeping power.

There seems to be a misunderstanding here. The rant was not against
people who works/worked on the specification, like you, but quite the
opposite, against people who claim we should not work on the
specification because they regard it as "done" (which is not the case,
IMHO).

On Thu, Oct 21, 2021 at 05:19:52AM +0500,
 Anna “CyberTailor” <cyber@sysrq.in> wrote 
 a message of 14 lines which said:

> Gemini was meant for humans but got full of stupid* bots (like
> everything on the net).

I'm not convinced. When was this "humans only" policy expressed? When
starting with Gemini, I don't remember having seen that bots were
frowned upon.

I didn't want to continue this thread, but after your reply to Sean I
think I have to at least clear a misunderstanding I caused.

Stephane Bortzmeyer <stephane@sources.org> writes:

> On Tue, Oct 19, 2021 at 07:03:18PM +0200,
>  Omar Polo <op@omarpolo.com> wrote 
>  a message of 46 lines which said:
>
>> the stagnation of the gitlab repo has somehow proven that, after
>> all, gemini is quite finished.  Yes, we have some doubts on how to
>> handle some edge cases, but globally the community has more or less
>> settled on how things should be and that's that.)
>
> I disagree with this assessment. The specification is still in poor
> shape, many cases are not documented, there is no agreement on very
> important things like TLS close notify or IDN and, even when there is,
> it is not documented so newcomers cannot get it, they have to rely on
> the hidden knowledge of some old timers. Hardly satisfying.

I wasn't trying to say that we shouldn't work on fixing the
specification, and I deeply apologise if I seemed to suggest that.  I
phrased that mail poorly.

I let my dissatisfaction speak.  I guess I have to step back and think a
bit.  I'm all for fixing all the corner cases and transform it into
something more rigorous, but just got tired of how things developed
(even before the gitlab move.)  I'm not trying to lessen my fault here
thought, even if I was fed up with the situation I shouldn't let my
frustration out like that.

Once again, I'm sorry.

> (Not documenting thing is a common way to keep power.)

On Wed, Oct 20, 2021 at 09:19:49PM -0400,
 Sean Conner <sean@conman.org> wrote 
 a message of 33 lines which said:

> > * disrespecting robots.txt, the protocol spec and common sense
> 
>   Yeah, tell me about it.  Here's the robots.txt I had (have):
> 
> User-agent: *
> Disallow: /test/redirhell

Speaking of specifications, remember that robots.txt is not
standardized anywhere, even when you limit yourself to the Web (and it
is worse for Gemini, which has no User-Agent: field). There are
several documents floating on the net and the examination of the
robots.txt of Gemini capsules indicate a lot of variety.

(Your robots.txt is very simple and therefore fits into the common
subset of all robots.txt documentation/software. But it is not the
case for all robots.txt.)

On Wed, 2021-10-20, Sean Conner wrote:
>  Not ONE person here who had showed interest in finalizing the spec
> bothered to reach out and say, "What's up with the spec?" or "Are you still
> working on the spec?"  or even "Hey! Haven't heard from you for some time."

Sean, thank you very much for your work!  I figure you and Solderpunk
had plenty of life to deal with - I certainly did during this year
(pandemic and other things).  Look, as far as I'm concerned, Gemini is
the Way, the Truth and the Life.  There are SO many fundamental things
it gets right, it's not even funny.  The spec deserves to be finalized.

But there is no rush.  Geminispace is doing good even without a final
spec: the software is getting better (Lagrange, in particular, is
amazing) and the number of capusules is growing.

Maybe Solderpunk will return or maybe someone else will pick it up.
I know I'll do what I can to push it further, time permitting.  It's
absolutely worth the effort.

All the best!  Hope you'll stick around.

Stephane,

Perhaps we can employ a stricter standard concerning poorly functioning bots?

For example, a federated 'naughty-step':
* If a server is being bothered by cretinous behaviour message a naughty-step site
* From time to time (participating) servers get a list of ips to (temporarily!) block
* The bots receive a (new) response code, pointing out that it is 
temporarily on a naugty-step
* The response code recommends a uri to better bot practices


Jonathan

Stephane Bortzmeyer <stephane@sources.org> writes:

> On Wed, Oct 20, 2021 at 09:19:49PM -0400,
>  Sean Conner <sean@conman.org> wrote 
>  a message of 33 lines which said:
>
>> > * disrespecting robots.txt, the protocol spec and common sense
>> 
>>   Yeah, tell me about it.  Here's the robots.txt I had (have):
>> 
>> User-agent: *
>> Disallow: /test/redirhell
>
> Speaking of specifications, remember that robots.txt is not
> standardized anywhere, even when you limit yourself to the Web (and it
> is worse for Gemini, which has no User-Agent: field). There are
> several documents floating on the net and the examination of the
> robots.txt of Gemini capsules indicate a lot of variety.
>
> (Your robots.txt is very simple and therefore fits into the common
> subset of all robots.txt documentation/software. But it is not the
> case for all robots.txt.)

On Wed, Oct 20, 2021 at 07:39:23PM -0400, Sean Conner wrote:

Hi!

>
>   Not ONE person here who had showed interest in finalizing the spec
> bothered to reach out and say, "What's up with the spec?" or "Are you still
> working on the spec?"  or even "Hey! Haven't heard from you for some time."
>
>   Nothing.

I am  surprised that you was  disappointed form lacks of  this kind of
messages.  I  can only speak  for myself -of course-  if i say  that i
never wrote  something like  that not  because i do  not care  for the
protocol, but  because i would  consider asking about why  no progress
was not made on gemini a form  of pressure that me -as maintainer of a
few  software- would  consider harmful  for the  mental health  of the
people in charge of the project.

So i learnt  today that some people consider not  getting this kind of
feedback  as  lacks of  interest  in  project  and people  behind  the
project, i am sorry for this misunderstanding.

Anyway, thank you for all your work, i just hope what happened did not
leave a sour taste.

Bye!
C.

Hello Sean,


On Wed, Oct 20, 2021 at 07:39:23PM -0400, Sean Conner wrote:
> Back on April 17th of this year, I wrote the following to solderpunk:
>> [...] As far as I'm concerned, I don't have it in me to work further
>> on Gemini - there are too many people with too many divergent
>> opinions on how it should all work. [...]

This is sad to hear. I suspect I'm one of the people who was making it
difficult for you... I regret being so fierce about the Gitlab thing,
and I also would like to apologise for my contribution to the awful
length of the Gitlab discussion about status code 11. I can easily see
how such, um, enthusiasm coming from many people can quickly become
too much.

Anyway, I too would like to thank you for the finalisation work that you
did for as long as you did it, and also for your significant earlier
contributions to the protocol and the gemtext format.

> Not ONE person here who had showed interest in finalizing the spec
> bothered to reach out and say, "What's up with the spec?" or "Are you still
> working on the spec?"  or even "Hey! Haven't heard from you for some time."
> 
> Nothing.

I kind of assumed it was similar with you as with Solderpunk, a break of
undefined length rather than a permanent one. Finalising the spec was
never an urgent thing, so I just waited. Also, iirc you made many
provisionary decisions in one go, which made it seem plausible (to me at
least) that the final decisions would also come in a batch.

I like that it now seems the spec is moving towards finalisation. I
will probably disagree with quite a few of Solderpunk's decisions, but
ultimately it's about minor details, and (if there's anything the Gitlab
issue tracker has demonstrated) for many of them there is something to
be said for both sides; for the controversial ones, I expect
Solderpunk's rationale will be enough for most people to accept it.


-- 
pjvm