I've been meaning to update it myself for some time but knowing how
personal projects go it probably would've been far into the future, so
this is much appreciated!  Thanks so much!

~nytpu

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

Luckily it's pretty easy to test this with openssl's s_client, it'll say
"closed" at the end if the connection was closed properly:

  printf "gemini://nytpu.com/about.gmi\r\n" |
    openssl s_client -ign_eof -connect nytpu.com:1965

outputs:

  depth=0 O = nytpu, CN = nytpu.com
  verify error:num=18:self signed certificate
  [...handshake and cert info...]
  20 text/gemini; lang=en-US
  [...the actual response body (if success response code)...]
  [...end-of-connection info...]

On 2021-11-08 08:07PM, codesoap at mailbox.org wrote:
> Hi all,
> > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]
> From this description I don't know whether <USER-FRIENDLY LINK NAME>
> MAY be empty. Which of these regular expressions would be correct to
> parse a link line?

The user friendly link name is optional, however if it is present
then the whitespace after the url is mandatory as well.  In other words,
the URL is mandatory, and you either have no link name and no space
after the URL or a link name and mandatory space(s) after the URL.

So you have the following possibilities for link lines:
=>url         <- no link name, no space between => and url

As of late 2019 client-side TLS 1.3 for LibreSSL was implemented, which
I can confirm.  Server support was completed by mid-to-late 2020 but 1.3
support for their OpenSSL API clone wasn't finished yet.

Apparently in the latest LibreSSL release (3.4.1, October 14th) they
completed their implementation of the OpenSSL TLS 1.3 API, which means
that an up-to-date LibreSSL should have full support for TLS 1.3 through
all of their various APIs as of now---although I can't confirm it since
I use LibreSSL very intermittently and usually just for testing of
cross-compilation to a BSD.

I've been using GnuTLS a little bit in Ada and it seems to support 1.3
fine although my testing was at the absolute most basic level.
According to various developer's blogs and the changelog GnuTLS got TLS

This will generate `id` attributes for all heading levels.  The labels
are generated using steps 1-4 of the gitlab flavored markdown algorithm
which seems to be pretty standard for generating anchors:
https://docs.gitlab.com/ee/user/markdown.html#header-ids-and-links

A unique ID isn't appended to avoid having to store a list of previous
headers to compare against.
---
This has been tested locally and on my capsule's public kineto proxy.

Would it be good to also add a link enclosing the header to allow for
clicking on the header to get the full url with the fragment?  Or do
something like the Sourcehut markdown converter does and add an icon
next to the headers that'll link to the header?  I could send a
[message trimmed]

Very screenreader unfriendly ahead...

---

MATHEMATICAL BOLD CAPITAL W MATHEMATICAL BOLD SMALL h MATHEMATICAL BOLD
SMALL y MATHEMATICAL BOLD SMALL d MATHEMATICAL BOLD SMALL o MATHEMATICAL
BOLD SMALL n APOSTROPHE MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD
SMALL y MATHEMATICAL BOLD SMALL o MATHEMATICAL BOLD SMALL u MATHEMATICAL
BOLD SMALL f MATHEMATICAL BOLD SMALL u MATHEMATICAL BOLD SMALL c
MATHEMATICAL BOLD SMALL k MATHEMATICAL BOLD SMALL o MATHEMATICAL
MATHEMATICAL BOLD SMALL f MATHEMATICAL BOLD SMALL f MATHEMATICAL BOLD
SMALL w MATHEMATICAL BOLD SMALL i MATHEMATICAL BOLD SMALL t MATHEMATICAL
BOLD SMALL h MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD SMALL h
MATHEMATICAL BOLD SMALL a MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD

On 2021-10-26 12:20AM, almaember wrote:
> He merely owns the website/capsule it's hosted on. Taking and hosting
> it, or even rewording it to avoid copyright issues, is a relatively
> simple task.
If I take a copy of whitehouse.gov and replace all the text with "lol
the government's dumb" does that make it the official whitehouse.gov
site?  Solderpunk hosts the canonical version (which you said yourself
is the one everyone follows) which means they're the one that "owns"
the Gemini specification.

> GitLab doesn't own the GitLab specification just because it's hosted
> there, and neither does the operator of this mailing list own this
> message.
And yet I both host and own nytpu.com.

Funny, I made my own last night:
=> https://sr.ht/~nytpu/Gemini-Specification/
I'll delete it in a bit, I don't want to fragment the spec finalization.

I didn't want to fill Solderpunk or Sean Conner's role either, I was
going to modify the specifications in accordance with the things that
Solderpunk and Sean Conner made a relatively final decision on in the
Gitlab and mailing list, and then open tickets for the rest.

~nytpu

-- 
Alex // nytpu
alex at nytpu.com

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.

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 at nytpu.com
gpg --locate-external-key alex at nytpu.com
https://useplaintext.email/