Re: State of Gopher and TLS?
EG stuffing crc in the ascii high bit (or the extra few bits in utf8) in that harnesses a dialup modem's decompression hardware to strip it into the modem/ethercards buffer with an at command to send it back to the server to crunch the crc check... utilising
the hp of the data terminal equipment and the server, but not the client system....
yeah I know unix boffins are far too lazy to do that....
there is an australian that has written a streaming video format for 1mhz apple IIe's that harnesses the copper effect of a modern compact flash based storage device to get data to the screen faster than the cpu ever could...
a derivative work on the same platform has the ethernet chip stream mp3's to the same 1mhz system. the hp is freed up and it plays back tte 22khz 7.4 iirc bit mp3's out of the bitbanged internal speaker.
Ye need to think outside the box.
From: Mateusz Viste <firstname.lastname@example.org>
Sent: Tuesday, 25 October 2022 6:55 PM
To: email@example.com <firstname.lastname@example.org>
Subject: Re: State of Gopher and TLS?
On 25/10/2022 10:36, Hiltjo Posthuma wrote:
> Here you can find some information about TLS over gopher.
> It doesn't violate the gopher specification:
RFC 1436 is clear about the fact that Gopher is a simple, text-based TCP
protocol. One extract below, but there are more:
In essence, the Gopher protocol consists of a client connecting to a
server and sending the server a selector (a line of text, which may
be empty) via a TCP connection.
Feel free to call the TLS contraption "gophers" or whatever else, but it
is not Gopher.
The document you linked to proposes a way of implementing dual protocol
support so a server can act simultaneously as a Gopher and "gophers"
server sharing the same port. It does not mean that "gophers" is
compatible with the Gopher protocol. A Gopher client is unable to access
"gophers" content, unless said content is also available via Gopher.