Re: State of Gopher and TLS?
I think that is the problem the whole net is discovering atm, retrospace(legacy),embeded space and IOT. any horsepower sparse system or element is locked out by... what do I call it...complex-added systems.
Dont get me wrong, security is good, but when it breaks the internet and causes a horsepower schism....
were even talking here about some i4049/51 4 bit systems, the last bastion of power useability for those systems is Gopher.
when you upgrade servers so that people who browse with low h.p. devices are locked out....
well that sort of thing is best done with the www. ever changing spec that is met by ever changing h.p.
gopher servers leave behind the only clients that gopher effectively serves.... kinda pointless.
Just my 2 dung pellets.
ps. Want a challenge? invent a security system that doesnt rely on updating legacy clients rom based mcp's or os'or any added hp to effectively deliver secure comms. Thants the gopher way.
From: Mateusz Viste <email@example.com>
Sent: Tuesday, 25 October 2022 6:55 PM
To: firstname.lastname@example.org <email@example.com>
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.