Colorado
Hi! I'm Alex (a.k.a. nytpu), and I do some programming and electronics projects. I love C, POSIX shell, and assembly (retro game consoles only); I dabble in Scheme, Ada, and whatever tickles my fancy at a given point in time.
From Alex // nytpu to ~nytpu/public-inbox
Thanks! ~nytpu -- Alex // nytpu alex@nytpu.com gpg --locate-external-key alex@nytpu.com
From Alex // nytpu to ~nytpu/public-inbox
Thanks! ~nytpu -- Alex // nytpu alex@nytpu.com gpg --locate-external-key alex@nytpu.com
From Alex // nytpu to ~nytpu/public-inbox
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
From Alex // nytpu to ~adnano/gemini
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...]
From Alex // nytpu to ~adnano/gemini
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
From Alex // nytpu to ~adnano/gemini
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
From nytpu to ~sircmpwn/gmni-devel
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]
From Alex // nytpu to ~adnano/gemini
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
From Alex // nytpu to ~adnano/gemini
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.
From Alex // nytpu to ~adnano/gemini
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