💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › 1646331056.bystand@zzo38co… captured on 2024-07-08 at 23:31:26. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-04-28)

-=-=-=-=-=-=-

Re: teletext-ish pages?

Message headers

From: news@zzo38computer.org.invalid

Subject: Re: teletext-ish pages?

Date: Thu, 03 Mar 2022 11:17:04 -0800

Message-ID: <1646331056.bystand@zzo38computer.org>

Message content

<joe@example.invalid> wrote:

Having tools that generate gemini pages, instead of HTML, from code the
way DoxyGen does seems like it would have been a major boost for gemini,
but the SSL requirement really breaks a lot of stuff.

I agree that TLS should not be mandatory; it should be optional. I had

previously proposed a "insecure-gemini" protocol. Its specification is:

"gemini" and "insecure-gemini" the same in the request text.

client certificate to be accessed, then it must issue a 3x response which

redirects to the secure version of the Gemini protocol.

stunnel does not have this capability, making this difficult to implement.

However, the protocol does not seem to be ambiguous, so it would seem to

me that it should be possible somehow.

bytes with the high bit set are treated the same as the corresponding

percent encodings by the server. If the server's domain name uses any

non-ASCII characters, then it should accept both the Punycode and UTF-8

representations of the domain name. (This retains compatibility with the

existing protocol, but allows for non-Unicode filenames too. A client

which uses Unicode text input will require that these names are percent

encoded if they are not valid UTF-8.)

MUST be represented using only ASCII characters, otherwise the result

of trying to follow that link is undefined. (Non-ASCII characters are

allowed if they are percent-encoded or if the document is UTF-8.)

SNI, it assumes whatever is appropriate, defaulting to the domain name

given in the request if that name is appropriate.

optional parameter in the <META> line to give the length of the response

in decimal (if it is known; if not, then it can be omitted). (This also

allows download progress to be displayed.) (Although, maybe this is too

difficult to fit into the existing protocol.)

I'd also like to see support for color.

I disagree. The colours should not be defined by the document. (If you

need coloured ANSI art, you could either include a telnet link or you

could serve a file of a different file format, I suppose.)

Ascii (well, unicode really) art with unicode can be very, very
impressive and quite artistic. If it were possible to add color, this
would totally rock. (it would also really suck for blind people, but you
could, and should, wrap it in ``` anyway. Blind readers could skip that)

Actually, I think that Unicode is very bad for a lot of things, and would

rather not use it. It is especially bad for "ASCII art"; some character

widths may be ambiguous, or not ambiguous but wrong for your application,

or mismatch by fonts, not lining up or other character properties wrong,

other ambiguity or non-ambiguity which does not match (e.g. in the PC

character set, one character can be either Greek or German), and then

tere is han unification, complex scripts, etc. This is a huge mess.

(However, the "lang" parameter can mitigate the problem with the han

unification, sometimes, at least. Not always.)

Adding colours can be done in a separate file, perhaps.

Petscii is still a thing in some circles. There are ascii art contests
that still take place. To be truly impressive, they need color support.

This is true, but the Commodore 64 colours are not the same as the ANSI

colours, though.

If you support unicode, (via the terminal) this shouldn't be that much
harder. The terminal does all the work. The challenge would be malware
that sends escape codes to bugger up the screen. (even then, the worst
that could happen is you need to do a screen reset. Hardly a big deal)

I am not sure what is the worse that can happen, actually. Messed up

screen is not necessarily the only possibility.

I've never used teletext, I've read about it though. There are quite a
few people who miss it. They sound a lot like gopher users who prefer
the simple interface.

Neither have I, but I read about it.

Teletext was an old protocol for television sets that allowed you to
view news pages, weather, etc.. in a semi-textual format.

There is also Viewdata, which I think is similar. There are some Viewdata

services existing that you can access over the internet, and you can use

a Viwedata client to access it. It is a interactive protocol (similar to

telnet), unlike static pages that were previously used in television.

I could easily see designing a teletext type of client for gemini but
color is important. Teletext DID have graphics, implemented via a kind
of escape code into an alternate character set of blocky characters, not
unlike commodore graphics. Unicode could probably do this too.

I argued above that Unicode shouldn't do it.

SSL is a deal breaker
---------------------
Imagine what a flop UNIX would have been if 'grep', 'awk', 'sed'
required all their input to be encrypted.
Unix was a big success in part because the commands don't actually care
where the input is coming from.

I agree; TLS should not be mandatory.

I mentioned above some ideas about "insecure-gemini" protocol.

--

Don't laugh at the moon when it is day time in France.

Related

Parent:

teletext-ish pages? (by <joe@example.invalid> on Thu, 3 Mar 2022 06:49:40 -0000 (UTC))

Children:

Re: teletext-ish pages? (by <joe@example.invalid> on Fri, 4 Mar 2022 11:48:39 -0000 (UTC))