I've never used gemini, I've never used teletext either. I have used
gopher.

As I read this group, and consider my own needs and how I'd be likely to
use it (if I ever do) a couple things come up.

Seems like it could have been a good way to view texinfo pages, manpages
and possibly even vim help files. It would be pretty neat to design a
text-only wiki. I really like that it works in a terminal.

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'd also like to see support for color.

ANSI colors, unicode artwork, Nerd artists
------------------------------------------

Color and ascii art would likely attract an audience that I think is
often overlooked: Nerd artists and people into crafts.

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)

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.

Don't get me wrong, there are times when I'd want to turn the color off.
Blue background with white text would give me a major headache, for
example. (but this could be done via the terminal emulator)

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)

Teletext
--------

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.

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

Pages were accessed by number, expensive television sets had memory that
could cache the pages while other less expensive units would have to
wait until the page number was rebroadcast. The page would load on your
television set. It's an old technology.

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.

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.

Being transport-agnostic would have allowed gemini to function from a
simple perl script server feeding gemini pages from a zip file over a
pipe. SSL breaks a whole host of neat things you could do like that.
(atom feeds that supply pages ala teletext above, even email could be
the basis of a teletext content delivery system .. if not for the SSL
stuff)

Gopher is one of those things the tor network likes because of the
privacy features and because a lot of hidden onion sites are running on
peoples home computers with limited resources. Since you'd be running
over onion anyway, encryption is redundant.

I could really see gemini taking off over tor, SSL is very unfortunate
IMO.

Overall I'd say this is a pretty nifty project, I hope the developers
will consider my input, because I think there is an audience of people
you may not have thought about who would really appreciate it:

Artists, teletext users and tor hidden services.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

<joe@example.invalid> wrote:
> [...]
> SSL is a deal breaker
> ---------------------
>
> Imagine what a flop UNIX would have been if 'grep', 'awk', 'sed'
> required all their input to be encrypted.

Good thing the "input" to a gemini client isn't encrypted then, huh?

Oh, sure the transport socket is encrypted with TLS, but that's pretty
simple to set up. I mean nearly everything has a libssl nowadays, and
we can get free certs from Let's Encrypt with no trouble at all.

If this was 15-20 years ago, I'd probably agree that TLS-by-default
would be questionable; but honestly it's become so ubiquitous in the
last 5-10 years that a "new" service not using it would be surprising.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIgn8UACgkQbWVw5Uzn
KGDIiQ//YE2C/ZxCGRuMRmmCpvSB1kd5KyovJz3clZg6kOAl5rhHCdZwO/e6erik
hKqje9bnXYfoMwUI11OXm03WfMb8ffEl6nUwLIqZsEaZLwAquXCvHePnLJV6J1e0
i6+hRHIeqWXmpEPFzKQeqBXi7Uohabwozb8S92wn8cQqVsVyvKRp+OcwnHTqT1Ws
YHDaMLvKvV/pF8VBNBcN7c6b5nwsSiRnIQy4qS+zohyma8QMHmgdQtOa7/+UdIoI
LwKuvV9JNuIoR7t1gHe+358vn2EACerqMuGPpBegN2oaRNoYCgYwU2n+nNj628EZ
IvJH5zJX6VFYt11cuK6Dx3JRQeKhjuDGwtC7bjxhsK+5npMEYIyzdCsmrbBhlZfH
Dd5ajOcmqZYFFr9l1+kFvw8zCPO5MNQt9Wnp6fHYVdNrJ0Ip7oecSGiRsPlmaL39
qt0m24awe3Xbm78wSpOLAJx5YQE5vQTLVl+HWQiZWB0/S3j6580gSBMzwxm0cgGV
vZrRNZHO6HVYLudjkn6ZhtQv0wh7RZjsVRfVq302KUkblr227TpJDR7Xh2uZV7ya
Pmy+mXL9f1I4ZSUrZV6dJrLPcHBfXdvYufOs0uy+7yblUuV5XXDf0Li+Hm5e4hmd
T11J9YUmBCOYGwPngq1avglwsE2Pp2VosT7Vf9dLsES2piW1csA=
=U2ZI
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Dan Purgert <dan@djph.net> wrote:
> If this was 15-20 years ago, I'd probably agree that TLS-by-default
> would be questionable; but honestly it's become so ubiquitous in the
> last 5-10 years that a "new" service not using it would be surprising.

I guess there's really no reason a gemini client couldn't just open
a file:// url, maybe it's not that big a deal.

Heck, why not just run gemini over http. :-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

<joe@raspberry.invalid> wrote:
> Dan Purgert <dan@djph.net> wrote:
>> If this was 15-20 years ago, I'd probably agree that TLS-by-default
>> would be questionable; but honestly it's become so ubiquitous in the
>> last 5-10 years that a "new" service not using it would be surprising.
>
> I guess there's really no reason a gemini client couldn't just open
> a file:// url, maybe it's not that big a deal.

Shouldn't be too difficult to write a gemini browser/client to
understand the "file://" URL prefix instead of just "gemini://".

Though I do prefer just opening files locally with an appropriate
application (vim, gv, etc).

>
> Heck, why not just run gemini over http. :-)

Install apache/nginx, host the *gmi files straight from it.

Granted, a normal web-browser will only see them as plaintext files,
and not actually be able to interact with them as a gemini client can.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIgvQcACgkQbWVw5Uzn
KGDyChAAt+nKcBUHqvU4Cz6FIh/8j0iz5TnKr5bi8VZ5vAih54QCd8hJCNiriRIt
W1IuV1GvlCVJDDRUnJT7sTMhUWJzIUQ6zOAhOyOlMBQMcbii8sYn6rNIOXpulbeH
AaudH7xu+g0DSHL+H+5KGYDMXOkn5+UImAG92HAqiGb61Rr5ksnkLs4IDdPKiT6P
XpAwAcaWcnVKUZK9tD2e3BxnwTgkWz42vpMTYvm2SLAN5pFdi2WjCEUuN6WeRmv9
cva+QFoajmCbCi2btsKBd2wkq2YH2Jvf+r/HcasY5AdOU8SN5sRntEKukuO1uOu9
3RY4gw0u5Fxp2U0bRfGxDasAgQ1vuhB68RSCGn0+0zi7STc78ZDWzQtfqAe8bvUd
NBevJmFGCuvRmInINqIaY7qK3x1RStjx4OX6bSuBhUJ1xO0W68UbyOK7bz2Pev7S
1arLLFOfOKEKwtGhU71igiquEQbc40v3z//jNBlnZ53EMczBBWxg4nu7VOk4hqDP
XIOHbt3YzMKadt17ZqToCf9duI4/gFVhzSEvI78Ofh/JbOG6NzWMCBwjE4PnluiE
C88zGeYYyEEy8RFhxDMtyihgXdnGE8sLsHaNwveoJT/eaEx1/B51ATKeC+Hzzz9x
qz9dA3mZIpW12lpJpymPmU3IP/X+u8slVxRTHi9y8DWzsEzkY6Q=
=sEzM
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

<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:

* The URI scheme is "insecure-gemini". However, the server should treat
"gemini" and "insecure-gemini" the same in the request text.

* Responses of type 6x are not allowed. If the requested document needs a
client certificate to be accessed, then it must issue a 3x response which
redirects to the secure version of the Gemini protocol.

* The port number is supposed to be the same, but as far as I can tell,
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.

* URLs are not automatically UTF-8. They are treated as ASCII, and any
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.)

* If the document is not encoded as UTF-8, then any URLs in the document
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.)

* Since there is no SNI, it is not required. If the server somehow needs
SNI, it assumes whatever is appropriate, defaulting to the domain name
given in the request if that name is appropriate.

* Since there is no TLS "close_notify", maybe there should be another
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.

Dan Purgert <dan@djph.net> wrote:
> Shouldn't be too difficult to write a gemini browser/client to
> understand the "file://" URL prefix instead of just "gemini://".

Yes, I believe any Gemini client ought to be designed to support it
(although, it could be limited to only user entered URLs and links
from other local files, so that remote files cannot link to locals).

Sometimes the MIME type will not be known. Something that would help
(not only for this but also web browsers with HTTP(S), too) is a URI
scheme for overriding the MIME type of the response.

> >
> > Heck, why not just run gemini over http. :-)
>
> Install apache/nginx, host the *gmi files straight from it.

Yes, you can serve files of any type from HTTP(S), just as much as you
can also do with Gemini, etc. There is the MIME type header too, so it
can also identify the file format.

> Granted, a normal web-browser will only see them as plaintext files,
> and not actually be able to interact with them as a gemini client can.

I had proposed a way in which this would be possible, using a extra
HTTP response header (which MUST be implemented regardless of TLS or not):
You can have multiples, and specify a MIME type and target URL. If it is
a file type expected in that context (e.g. HTML for a top level document,
or PNG where a picture is expected), then it loads that one instead but
keeps the current URL (for the purpose of relative links, window.location,
etc). If it is a executable type (JavaScript or WebAssembly), then it will
be executed (if the end user has not disabled this capability) in order
to interpret the file and convert it to the expected format.

It isn't implemented, but it should be.

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

news@zzo38computer.org.invalid wrote:
> <joe@example.invalid> wrote:
> I agree that TLS should not be mandatory; it should be optional. I had
> previously proposed a "insecure-gemini" protocol. Its specification is:
>
> * The URI scheme is "insecure-gemini". However, the server should treat
> "gemini" and "insecure-gemini" the same in the request text.

I see gemini as something that has the potential to be a big hit over
Tor, where people run local services on their home machines. In this
case, SSL is redundant and it's kind of a pain to deal with.

But there's really no reason one couldn't just use file:// or even
http:// I guess.

>> 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.

You could move the cursor around, or send the persons terminal into an
alternate character set (which really makes a mess). You could send
escape codes that put the terminal into tektronix mode, annoying
blinking text, things like that.

If the person on the other end were using a genuine terminal, with a
printer attached (I've used those, believe it or not!) you could poison
someone by sending the escape code to initiate printing. I haven't seen
a terminal that "prints" that way in many, many years. You'd have better
luck sending a zmodem transfer sequence and tricking them into
downloading files. :-)

I found a capsule that uses ansi extensively, and I'm quite impressed!

Check it out:

=> gemini://ansi.hrtk.in ANSI art archive

They're using it in ways I hadn't thought of. It worked pretty good for
me, except they're trying to emulate a slow modem connection which just
makes the pages take a while to load.

I'm impressed!

>> 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.

That would be pretty cool to see :-)

I've seen quite a bit of cool terminal stuff lately. Modern unicode
terminals hold a lot of promise.

Overall, I am impressed with gemini, I really like the design goals. I'm
happy to see someone actually is using color. I'm off to see if I can
find anything about viewdata protocol next. Thanks for the tip.

On 2022-03-04, <joe@example.invalid> <joe@example.invalid> wrote:
> I see gemini as something that has the potential to be a big hit over
> Tor, where people run local services on their home machines. In this
> case, SSL is redundant and it's kind of a pain to deal with.
>
> But there's really no reason one couldn't just use file:// or even
> http:// I guess.

If you're already on Tor and using onion encryption to secure your
traffic, there's almost no need for Gemini. You can setup a simple
HTTP server and just serve files on it. Gemini's instistence on TLS +
TOFU makes it difficult to use on any overlay network that has
encryption out-of-the-box. Even Gopher works fine over Tor if you so
wish it.

meff <email@example.com> wrote:
> On 2022-03-04, <joe@example.invalid> <joe@example.invalid> wrote:
>> I see gemini as something that has the potential to be a big hit over
>> Tor, where people run local services on their home machines. In this
>> case, SSL is redundant and it's kind of a pain to deal with.
>>
>> But there's really no reason one couldn't just use file:// or even
>> http:// I guess.
>
> If you're already on Tor and using onion encryption to secure your
> traffic, there's almost no need for Gemini. You can setup a simple
> HTTP server and just serve files on it. Gemini's instistence on TLS +
> TOFU makes it difficult to use on any overlay network that has
> encryption out-of-the-box. Even Gopher works fine over Tor if you so
> wish it.

Thats true, unfortunately.

I do use gopher over onion, it's kind of what lead me to gemini.

You can browse capsules on a terminal, which is probably the best thing
about them in my view.

The really promising thing about Gemini vs http WAS that Tor users are
extremely privacy concious. HTML pages are often (usually) loaded with
javascript hacks designed to invade your privacy.

Legitimate Tor users *COULD* be, in my view, the exact audience of Gemini.

Someone who is genuinely concerned about privacy encroachment, say,
someone who supported the trucker convoy in Canada, has every reason not
to trust an HTML page, not even over Tor because of fingerprinting and
potential out of band leaks... problems gemini doesn't really suffer
from yet. (and won't, as long as every page is self contained)

They're just text files, they don't consume a lot of bandwidth either.
It's quite practical to put one on your home computer, over Tor in much
the same way gopher used to be done on work stations.

The requirement for SSL really shoots a lot of advantages down.

Gemini could, in my view, be a very practical and useful thing. It
doesn't have to be limited to a novelty. If it supported markdown, it
would instantly have millions of pages available to it. (but really,
there's no reason one couldn't just pipe from the mailcap file like mutt
does)

This kind of behavior is what you would want on the darkweb. Whistle
blowers, journalists would also want some way of uploading files, ftp
doesn't work over onion very well... and you'll never be able to
implement an interactive site or "pastebin" in gemini.

Maybe "apollo://" could have uploading, work without SSL, support
markdown and even have some kind of mechanism where it prompts you to
upload your PGP key and uses it to encrypt stuff. (PGP would actually be
AWESOME over networks like Tor, which doesn't have much for DNS, but it
would introduce the need for some kind of session management. The server
would need to know which key to encrypt with)

I'll get to work on apollo as soon as I'm done with all the other projects
I'm procrastinating on... :-)

Am 05.03.22 um 01:50 schrieb meff:
> Gemini's instistence on TLS +
> TOFU makes it difficult to use on any overlay network that has
> encryption out-of-the-box. Even Gopher works fine over Tor if you so
> wish it.

No, it doesn't make anything difficult. And TOFU has as one major point
re-identifying the server, after it had been used once before. This is
not only about transport encryption.

Martin

On 2022-03-05, Martin <martin@datapulp.de> wrote:
> No, it doesn't make anything difficult.

On overlay networks that don't have DNS services, minting a
certificate is a pain.

> And TOFU has as one major point
> re-identifying the server, after it had been used once before. This is
> not only about transport encryption.

There are overlay networks where peers are uniquely identified by a
private key like Yggdrassil, there are private overlay networks like
Zerotier or Tailscale; in these situations identifying the server is
generally unnecessary.

<joe@example.invalid> writes:

> I've never used gemini, I've never used teletext either. I have used
> gopher.
>

Swedish teletext in gemini form:

=> gemini://idiomdrottning.org/nyhetsgrej

(not my work)

/g.
--
Слава Україні!

On 2022-03-03, <joe@example.invalid> <joe@example.invalid> wrote:
> I've never used gemini, I've never used teletext either. I have used
> gopher.
>
> As I read this group, and consider my own needs and how I'd be likely to
> use it (if I ever do) a couple things come up.
>
> Seems like it could have been a good way to view texinfo pages, manpages
> and possibly even vim help files. It would be pretty neat to design a
> text-only wiki. I really like that it works in a terminal.
>
> 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'd also like to see support for color.
>
>
> ANSI colors, unicode artwork, Nerd artists
> ------------------------------------------
>
> Color and ascii art would likely attract an audience that I think is
> often overlooked: Nerd artists and people into crafts.
>
> 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)
>
> 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.
>
> Don't get me wrong, there are times when I'd want to turn the color off.
> Blue background with white text would give me a major headache, for
> example. (but this could be done via the terminal emulator)
>
> 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)
>
>
> Teletext
> --------
>
> 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.
>
> Teletext was an old protocol for television sets that allowed you to
> view news pages, weather, etc.. in a semi-textual format.
>
> Pages were accessed by number, expensive television sets had memory that
> could cache the pages while other less expensive units would have to
> wait until the page number was rebroadcast. The page would load on your
> television set. It's an old technology.
>
> 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.
>
>
> 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.
>
> Being transport-agnostic would have allowed gemini to function from a
> simple perl script server feeding gemini pages from a zip file over a
> pipe. SSL breaks a whole host of neat things you could do like that.
> (atom feeds that supply pages ala teletext above, even email could be
> the basis of a teletext content delivery system .. if not for the SSL
> stuff)
>
> Gopher is one of those things the tor network likes because of the
> privacy features and because a lot of hidden onion sites are running on
> peoples home computers with limited resources. Since you'd be running
> over onion anyway, encryption is redundant.
>
> I could really see gemini taking off over tor, SSL is very unfortunate
> IMO.
>
> Overall I'd say this is a pretty nifty project, I hope the developers
> will consider my input, because I think there is an audience of people
> you may not have thought about who would really appreciate it:
>
> Artists, teletext users and tor hidden services.
>

As a guy who actually used teletext, I almost didn't care on artwork
except for the maps on weather info. That's it.

Nowadays ANSI art it's noice, I can't stand it even on Gopher.

On 2022-03-03, <joe@example.invalid> <joe@example.invalid> wrote:
> Being transport-agnostic would have allowed gemini to function from a
> simple perl script server feeding gemini pages from a zip file over a
> pipe. SSL breaks a whole host of neat things you could do like that.
> (atom feeds that supply pages ala teletext above, even email could be
> the basis of a teletext content delivery system .. if not for the SSL
> stuff)
>
> Gopher is one of those things the tor network likes because of the
> privacy features and because a lot of hidden onion sites are running on
> peoples home computers with limited resources. Since you'd be running
> over onion anyway, encryption is redundant.
>
> I could really see gemini taking off over tor, SSL is very unfortunate
> IMO.
>
> Overall I'd say this is a pretty nifty project, I hope the developers
> will consider my input, because I think there is an audience of people
> you may not have thought about who would really appreciate it:
>
> Artists, teletext users and tor hidden services.

I don't think Gemini is meant to be a network technology in the same
way that Tor, I2P, Usenet, Gopher, or even private overlay networks
are. Gemini is an application built atop IP/TLS. It's a social network
that sits at the application layer instead of sitting atop the Web's
application layer, that's all.

You can send news or mail messages over AX.25, unencrypted links,
encrypted links, private networks, what have you. You can send
whatever you like in mail messages or news articles: binaries, text,
weird encodings, what have you. Gemini expects IP and TLS
connectivity, and most Gemini users and browsers only want to deal
with Gemtext or plain text. Gemini is an application, not a network.

On 2022-03-05, meff <email@example.com> wrote:
> On 2022-03-05, Martin <martin@datapulp.de> wrote:
>> No, it doesn't make anything difficult.
>
> On overlay networks that don't have DNS services, minting a
> certificate is a pain.

Is this still true when certificates are self-signed?

I know that this is an old conversation, but I don't understand your argument
at all, which probably reflects misunderstanding on my part.

--d

> Is this still true when certificates are self-signed?
>
> I know that this is an old conversation, but I don't understand your argument
> at all, which probably reflects misunderstanding on my part.
>
> --d

Nah you're right. A self-signed cert should be fine and it's true that
lots of Gemini servers use TOFU anyway.