💾 Archived View for gemi.dev › gemini-mailing-list › 000248.gmi captured on 2024-05-26 at 15:34:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi all, I have very recently discovered Gemini, so I am late at the party, but very excited by the Gemini concept and philosophy. At the same time, I am a bit disappointed by the mandatory use of TLS in the protocol. It seems _so_ at odds with the overall philosophy and simplicity of Gemini... But I _do_ understand that there is momentum behind TLS usage. Looking for discussion about this TLS issue, I found in a message by Petite Abeille [1] a link to the Mercury document [2] by Solderpunk. I don't know when it was published and couldn't find a discussion about Mercury (i.e. Gemini without TLS) What I would like to know:
On Tuesday 23 June 2020 06:46, Phil Leblanc <philanc at gmail.com> wrote: > [2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/sold erpunk/cornedbeef/the-mercury-protocol.gmi Hey thanks! I totally miss this post about mercury. This is very interesting and address small network bandwidth / small computer ressources / frugal energy usage issue. Seems that the protocol specification should be separate from the text format protocol (true for gemini too). freD.
Hey! > * is the concept still "alive"? is the document still "open for comments"? I think Mercury was just a thought experiment, but it sounds like we can spec that out to be fully usable (specify port and such) > * are there Gemininauts interested in Mercury? Yeah, definitly. It sounds like the perfect match for embedded devices, as it requires no encryption and no complex state machines. > * are there clients and servers targeting both Gemini and Mercury? > (i.e. the Gemini concept with and without TLS) Probably in some hours? I'm really tempted to implement a mercury:// into Kristall and provide people a client they can use :) > * has a solution been proposed for the two protocols coexistence? > (e.g. port 1965 for Gemini and 1963 for Mercury (the year of the last > Mercury flight :-) > I am sorry if it has already been hashed and rehashed. And thanks in > advance for your answers about any of the points above To my knowledge we haven't had a discussion about Mercury yet and it's simple enough to "just be used" Regards - xq
On Tuesday 23 June 2020 10:33, defdefred <defdefred at protonmail.com> wrote: > On Tuesday 23 June 2020 06:46, Phil Leblanc philanc at gmail.com wrote: > > > [2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/cor nedbeef/the-mercury-protocol.gmi > > > > Hey thanks! > I totally miss this post about mercury. > > This is very interesting and address small network bandwidth / small computer ressources / frugal energy usage issue. > > Seems that the protocol specification should be separate from the text format protocol (true for gemini too). > > freD. It will also permit surfing at the speed of ligth with instant display of clicked link... something that is no more existing in the old-school-too-much dynamic web. freD.
> * is the concept still "alive"? is the document still "open for comments"? I have been in discussions with solderpunk about this and there has been debate whether to move forward. I have a server built and have integrated mercury support into a branch of my client. However, that support differs from the original posting of mercury as a concept (it simplifies status codes, but there have been talks about removing the status codes altogether). I was definitely using a different port than the suggested 1963 (I think I used 1961, the year of the first crewed flight). My implementation uses text/gemini but only recognizes link lines and all other lines are treated as plain text rendered literally. In any case I would consider waiting to implement until solderpunk is back on the mailing list as I know he had thoughts about this (I believe he was hoping to deliver a finished and complete spec and not really hash out the concept much beyond that). Otherwise I think we run the risk of fragmented implementation and drawn out discussions to patch up that fragmentation whenr eally this should be a simple thing that all can just build from an already established spec. --? Sent with https://mailfence.com Secure and private email
Hey Phil, Phil Leblanc <philanc at gmail.com> writes: > Hi all, > > I have very recently discovered Gemini, so I am late at the party, but > very excited by the Gemini concept and philosophy. > > At the same time, I am a bit disappointed by the mandatory use of TLS > in the protocol. It seems _so_ at odds with the overall philosophy and > simplicity of Gemini... But I _do_ understand that there is momentum > behind TLS usage. same and agreed > Looking for discussion about this TLS issue, I found in a message by > Petite Abeille [1] a link to the Mercury document [2] by Solderpunk. > > I don't know when it was published and couldn't find a discussion > about Mercury (i.e. Gemini without TLS) > > What I would like to know: > > * is the Mercury document an old document that has been already > discussed and the concept discarded? (any link to the discussion?) If you search the geminiverse for mercury you'll see a few comments. I found that there were mostly negative responses toward Mercury, but then again it's a pretty small sample size. > * is the concept still "alive"? is the document still "open for comments"? I don't see why there couldn't be another ecosystem around mercury. I picture clients eventually supporting a suite of protocols, such as gopher, mercury and gemini all at once. > * are there Gemininauts interested in Mercury? very much so, TLS is the only thing holding me back from publishing content on Gemini. Mercury is something I was hoping more people would pick up interest in. > * are there clients and servers targeting both Gemini and Mercury? > (i.e. the Gemini concept with and without TLS) I haven't seen any but would love that idea! Cheers, Will
>> * are there Gemininauts interested in Mercury? > > very much so, TLS is the only thing holding me back from publishing > content on Gemini. Mercury is something I was hoping more people would > pick up interest in. Can you elaborate that further? Setting up a (stupid) gemini server is not that much work, considering [0]. Using one of the many gemini servers available shouldn't be a hurdle either Regards - xq [0] gemini://tomasino.org
Felix Quei?ner <felix at masterq32.de> writes: >>> * are there Gemininauts interested in Mercury? >> >> very much so, TLS is the only thing holding me back from publishing >> content on Gemini. Mercury is something I was hoping more people would >> pick up interest in. > Can you elaborate that further? Setting up a (stupid) gemini server is > not that much work, considering [0]. setting it up is not the issue. I'm just not a fan of the extra complexity and latency[1]. I would prefer to use a protocol that is as snappy as gopher but with a nicer syntax that is more markdown-friendly. Mercury seems to fit that bill quite nicely. [1] https://bitcoinhackers.org/@jb55/104355504715040809
On Tue, 23 Jun 2020 at 19:17, William Casarin <jb55 at jb55.com> wrote: > setting it up is not the issue. I'm just not a fan of the extra > complexity and latency[1]. I would prefer to use a protocol that is as > snappy as gopher but with a nicer syntax that is more markdown-friendly. > Mercury seems to fit that bill quite nicely. > The Gemini spec does not *require* TCP, so similar levels of snappiness could be achieved with QUIC. It does the connection handshake simultaneously with the TLS handshake, ending up with no more handshake messages than the classical TCP SYN / SYN+ACK / ACK handshake. You could get still snappier with a connectionless protocol. I just captured a single page load of Gopherpedia using Wireshark. Guess how many Ethernet frames? 11. These text based protocols are not optimized for speed or simplicity (as in minimizing abstraction layers). We are all standing on the shoulders of giants. -Hannu -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200623/5aa9 2565/attachment.htm>
Hannu Hartikainen <hannu.hartikainen+gemini at gmail.com> writes: > On Tue, 23 Jun 2020 at 19:17, William Casarin <jb55 at jb55.com> wrote: > >> setting it up is not the issue. I'm just not a fan of the extra >> complexity and latency[1]. I would prefer to use a protocol that is as >> snappy as gopher but with a nicer syntax that is more markdown-friendly. >> Mercury seems to fit that bill quite nicely. >> > > The Gemini spec does not *require* TCP, so similar levels of snappiness > could be achieved with QUIC. It does the connection handshake > simultaneously with the TLS handshake, ending up with no more handshake > messages than the classical TCP SYN / SYN+ACK / ACK handshake. Gemini over QUIC would be really cool, as TLS latency is my main gripe right now.
First, thank you all for your answers. @Felix Quei?ner > Yeah, definitely. It sounds like the perfect match for embedded devices, as it requires no encryption and no complex state machines. I think also for hobbyists and education. As soon as "what is a socket" has been explained, Mercury can be used as one of the first examples of how it works. Add TLS in the mix and suddenly it becomes more difficult to grasp. @defdefred > Seems that the protocol specification should be separate from the text format protocol (true for gemini too). Of course the request/response protocol and the text/gemini format are distinct. But I think at the moment they are best together in the "Gemini Spec" document. It doesn't prevent anybody to serve text/gemini pages over http... :-) @William Casarin > I don't see why there couldn't be another ecosystem around mercury. I picture clients eventually supporting a suite of protocols, such as gopher, mercury and gemini all at once. In my mind, it wouldn't be a different ecosystem -- exactly like there is only one "web ecosystem", with both http and https URLs. As long as the spec specifies both the "with TLS" and "without TLS bits", and as long as most client/server authors agree to support both, there shouldn't be any ecosystem split -- again, same as what happened with http and https Phil
I think Mercury is a bad idea, at least for now, when Gemini is still very young and not established (or just established). For one thing, TLS was the main reason solderpunk even began thinking about an alternative to gopher (see gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/why-gopher-needs -crypto.txt), and it's really the most important part of the protocol. Specifically the concerns over censorship, traffic modification, PGP key transmission, etc. I think removing TLS (or some kind of crypto) is a bad idea for that reason. If you don't want to use TLS, use gopher. Gemini isn't trying to be everything for everyone -- it specifically mentions that it's *not* trying to supplant gopher or http, and it's trying to be a *new* protocol, built from the ground up with modern sensibilities. Mercury is a step backward in that regard. As far as http, https (cf. > As long as the spec specifies both the "with TLS" and "without TLS > bits", and as long as most client/server authors agree to support > both, there shouldn't be any ecosystem split -- again, same as what > happened with http and https > > Phil ) -- remember how much work was put into the public education part of looking to the little green lock at the address bar of browsers, and how long it took for most of the web (even now, not all of it's https) to switch to https? I'm not even really a developer and I remember seeing headline after headline, blogpost after blogpost, begging authors to switch to https -- and even now, it's a patchwork. I have to use an extension like HTTPS Everywhere to make sure that a web page doesn't load some assets in the clear while I'm on a secured page! While gemini doesn't have that *particular* issue, it'll still be confusing for people casually browsing to know when/if they're moving to an insecure channel from a secure one or vice-versa. Best, Case (acdw)
On Wed, 24 Jun 2020 09:26:59 -0500 "Case Duckworth" <acdw at acdw.net> wrote: > remember how much work was put into the public education part of > looking to the little green lock at the address bar of browsers, and > how long it took for most of the web (even now, not all of it's > https) to switch to https? I'm not even really a developer and I > remember seeing headline after headline, blogpost after blogpost, > begging authors to switch to https -- and even now, it's a patchwork. I remember, and I'd rather not repeat that bit of history. I don't want to say that Mercury is a bad idea because I'm not really qualified to make that judgment. However, I *will* say that I won't support protocols that don't require encrypted connections, whether over TLS, SSH, or something that replaces these 20 years from now. I don't want to serve my own stuff in the clear, and if I'm providing hosting to other people I don't want to serve their stuff in the clear either. It's just not safe. -- Matthew Graybosch gemini://starbreaker.org #include <disclaimer.h> gemini://demifiend.org https://matthewgraybosch.com gemini://tanelorn.city "Out of order?! Even in the future nothing works."
On Wednesday 24 June 2020 17:36, Matthew Graybosch <hello at matthewgraybosch.com> wrote: > On Wed, 24 Jun 2020 09:26:59 -0500 > "Case Duckworth" acdw at acdw.net wrote: > > remember how much work was put into the public education part of > > looking to the little green lock at the address bar of browsers, and > > how long it took for most of the web (even now, not all of it's > > https) to switch to https? I'm not even really a developer and I > > remember seeing headline after headline, blogpost after blogpost, > > begging authors to switch to https -- and even now, it's a patchwork. > I don't want to serve my own stuff in the clear, and if I'm > providing hosting to other people I don't want to serve their stuff > in the clear either. It's just not safe. That the point about serving public data encrypted while every body can request it? Example: - public domain book - weather (curl wttr.in/paris) - public news - governmental information - cute kitten videos - etc. Optional PGP signature is enough to provide integrity. Are you sure that TLS is safe? States are allowing communication they can't decipher? >From my point of view TLS is needed to manage personal data, but not for all the geminispace. freD.
Hey > That the point about serving public data encrypted while every body can request it? > Example: > - public domain book > - weather (curl wttr.in/paris) > - public news > - governmental information > - cute kitten videos > - etc. Yes, as you can trust that you actually receive the data the server wants you to see. If a MITM attack happens, they can serve you the wrong news for example, wrong governmental information (deluding you to do illegal acts) > Optional PGP signature is enough to provide integrity. It depends strongly on how you verify that PGP signature (same rules apply to TLS though) Regards - xq
On Wed, Jun 24, 2020, at 11:14 AM, defdefred wrote: > That the point about serving public data encrypted while every body can > request it? > Example: > - public domain book > - weather (curl wttr.in/paris) > - public news > - governmental information > - cute kitten videos > - etc. > > Optional PGP signature is enough to provide integrity. If transmissions are sent in the clear, anyone in the middle (ISP, malicious actor) can modify any data, including a PGP signature (meaning a malicious actor could change the PGP signature to their PGP signature, then impersonate the person). TLS encrypts the *transmission* between the two endpoints, which is the only way to guarantee the message hasn't been tampered with. > > Are you sure that TLS is safe? > States are allowing communication they can't decipher? I have no idea about this, but I defer to the experts who've designed and implemented the system. Besides, if a *state* wants to take you down, I'm not sure if there's anything you can meaningfully do. TLS is more like a lock on the door than a bunker. > > From my point of view TLS is needed to manage personal data, but not > for all the geminispace. Do you think the same of the web? HTTPS is nearly universal, and I'd say that's a good thing -- Wikipedia (to me, the definition of public information) redirects http requests to https automatically. - Case
On Wed, 24 Jun 2020 16:14:46 +0000 defdefred <defdefred at protonmail.com> wrote: I don't know enough to claim that TLS is perfectly safe, let alone enough. I just think it's better than nothing. -- Matthew Graybosch gemini://starbreaker.org #include <disclaimer.h> gemini://demifiend.org https://matthewgraybosch.com gemini://tanelorn.city "Out of order?! Even in the future nothing works."
On Wednesday 24 June 2020 18:30, Felix Quei?ner <felix at masterq32.de> wrote: > > Optional PGP signature is enough to provide integrity. > It depends strongly on how you verify that PGP signature (same rules > apply to TLS though) The fun fact is: - with TLS, the whole server is using only one certficat and the integrity of publication rely only on this security and you don't know if it is a compromised server. - with PGP signature, each writer using the server have his own certificat to secure his writing integrity. freD.
On Wed, Jun 24, 2020 at 2:27 PM Case Duckworth <acdw at acdw.net> wrote: > > I think Mercury is a bad idea, at least for now, when Gemini is still very young and not established (or just established). For one thing, TLS was the main reason solderpunk even began thinking about an alternative to gopher (see gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/why-gopher-needs -crypto.txt), and it's really the most important part of the protocol. Specifically the concerns over censorship, traffic modification, PGP key transmission, etc. I think removing TLS (or some kind of crypto) is a bad idea for that reason. I will check the Solderpunk's document. Thanks for the pointer. Regarding Gemini vs. Gopher, I do think that the very simple request/response protocol and the great text/gemini document format with links embedded in the text are together by far _the_ great step forward, from Gopher to Gemini. > If you don't want to use TLS, use gopher. Gemini isn't trying to be everything for everyone -- it specifically mentions that it's *not* trying to supplant gopher or http, and it's trying to be a *new* protocol, built from the ground up with modern sensibilities. Mercury is a step backward in that regard I find it hard to follow you here. Do you imply that starting with Mercury and adding TLS would be a step forward, in terms of _newness_? > remember how much work was put into the public education part of looking to the little green lock at the address bar of browsers, and how long it took for most of the web (even now, not all of it's https) to switch to https? Definitely yes. And the same could be said about HTML and HTTP: remember how much work has been put in education and development and infrastructure to put in place the web as we know it! -- Is it enough of a reason not to try another way? > Best, > Case (acdw) Thanks for your input. I want to reiterate that with respect to Gemini, my biggest gripe is _mandatory_ TLS, not TLS itself. I feel a bit like a guy discovering a group of people trying to establish an utopian community from the ground up, based on fresh and frugal principles. After digging a bit, I found that they mandate the use of Toyota SUV for transportation in all the villages (because they are available everywhere in the world and are efficient for transportation). Maybe villages without Toyota SUVs could also be part of the utopian community? :-) Cheers, Phil
On Wednesday 24 June 2020 18:42, Matthew Graybosch <hello at matthewgraybosch.com> wrote: > I don't know enough to claim that TLS is perfectly safe, let alone > enough. I just think it's better than nothing. True. Security software are using end-to-end encryption + TLS transport. Having TLS is better, but it come with a latency cost with the one connection per request behavior. Freedom is also having the choice. freD.
On Wednesday 24 June 2020 22:47, Phil Leblanc <philanc at gmail.com> wrote: > Maybe villages without Toyota SUVs could also be part of the utopian > community? :-) Exactly! freD.
On Wednesday 24 June 2020 18:32, Case Duckworth <acdw at acdw.net> wrote: > If transmissions are sent in the clear, anyone in the middle (ISP, malicious actor) can modify any data, including a PGP signature (meaning a malicious actor could change the PGP signature to their PGP signature, then impersonate the person). TLS encrypts thetransmission between the two endpoints, which is the only way to guarantee the message hasn't been tampered with. When you are reading pgp signed document from a server where you own a defined set of public pgp keys, you don't fear MITM attack (the same way TLS is secure only with a PKI). The difference is that external PGP signature are all computed only at document publication time and not on the fly for each user request. freD.
It was thus said that the Great defdefred once stated: > On Wednesday 24 June 2020 18:32, Case Duckworth <acdw at acdw.net> wrote: > > If transmissions are sent in the clear, anyone in the middle (ISP, > > malicious actor) can modify any data, including a PGP signature (meaning > > a malicious actor could change the PGP signature to their PGP signature, > > then impersonate the person). TLS encrypts thetransmission between the > > two endpoints, which is the only way to guarantee the message hasn't > > been tampered with. > > When you are reading pgp signed document from a server where you own a > defined set of public pgp keys, you don't fear MITM attack (the same way > TLS is secure only with a PKI). > > The difference is that external PGP signature are all computed only at > document publication time and not on the fly for each user request. How do you safely get my public key? -spc
> On Jun 25, 2020, at 00:03, Sean Conner <sean at conman.org> wrote: > >> The difference is that external PGP signature are all computed only at >> document publication time and not on the fly for each user request. > > How do you safely get my public key? Once that's [securely] sorted, they can also be complementary, as a text/gemini could have an existence outside of gemini itself. # saltpack --detach sign <<< text/gemini BEGIN SALTPACK DETACHED SIGNATURE. kYM5h1pg6qz9UMn j6G7KBABYjYydzb Pklk5155D39lht1 PIb7SbVzthKfu8l 4bRIlCMIYVYUD0g 5YG4eznmm7OwrqH xNzsAdLzTtW9vh6 aHO1UvNpWsRfjBW dWIg2IxMDW4MPp0 2JIVEgqGlv2EyDQ mQwd3Cyz5CEGTfI S05Wy9A56Wpi67d Y0CQ57mD2U2rcS6 qKSCZIu. END SALTPACK DETACHED SIGNATURE.
With Mercury, we surf at the speed of light! https://www.youtube.com/watch?v=NAMuiAYCRac Sorry...
On 24/06/2020 22:50, defdefred wrote > Having TLS is better, but it come with a latency cost with the one connection per request behavior. > Freedom is also having the choice. > What's wrong with gopher, http 0.9 or 1.0 if you don't want encryption?
On Thursday 25 June 2020 12:49, julienXX <julien at sideburns.eu> wrote: > What's wrong with gopher, http 0.9 or 1.0 if you don't want encryption? About Gopher: cut historical constraints to have a fresh and modern start About http: We need a protocol madness proof freD.
On Thu, Jun 25, 2020 at 10:50 AM julienXX <julien at sideburns.eu> wrote: > > What's wrong with gopher, http 0.9 or 1.0 if you don't want encryption? > I guess one could also ask "What's wrong with https if you want encryption?" -- and the answer could be the same :-) The best real answer has been provided by Solderpunk:here: gemini://gemini.circumlunar.space/~solderpunk/cornedbeef/why-not-just-use-a -subset-of-http-and-html.gmi It applies as well to Gemini with or without TLS. Phil
On Wed, Jun 24, 2020 at 08:47:44PM +0000, Phil Leblanc wrote: > I feel a bit like a guy discovering a group of people trying to > establish an utopian community from the ground up, based on fresh and > frugal principles. After digging a bit, I found that they mandate the > use of Toyota SUV for transportation in all the villages (because they > are available everywhere in the world and are efficient for > transportation). As a non-car-owner and keen cyclist, this hurts! :) I will reply to this whole Mercury thread tomorrow (probably relatively briefly), but a quick request for disambiguation, regarding the SUV analogy: is the objection here mostly on the grounds of prefering minimalism, simplicity, easier DIYability? Or is there actually an explicit environmental component here, regarding the energy overhead of encryption? Cheers, Solderpunk
On Thursday 25 June 2020 18:04, solderpunk <solderpunk at SDF.ORG> wrote: > I will reply to this whole Mercury thread tomorrow (probably relatively > briefly), but a quick request for disambiguation, regarding the SUV > analogy: is the objection here mostly on the grounds of prefering > minimalism, simplicity, easier DIYability? Or is there actually an > explicit environmental component here, regarding the energy overhead of > encryption? Limiting the environmental footprint of internet is useful. For example, this site https://solar.lowtechmagazine.com/ will run longer without encryption... Limiting the latency is useful too. So light document should display directly after request. The one request per file paradigm make latency more visible, when I click one image, it should display fast. Encryption is very important too. So Gemini for strong encryption and Mercury for public data or DIY static encryption seems perfect. Not everybody have fiber internet connection and a protocol able to serv data on limited network is valuable. http://www.rowetel.com/?p=7207 https://hackaday.com/2020/02/26/lora-mesh-network-with-off-the-shelf-hardware/ freD.
On Wed, Jun 24, 2020 at 06:30:26PM +0200, Felix Quei?ner wrote: > Hey > > > That the point about serving public data encrypted while every body can request it? > > Example: > > - public domain book > > - weather (curl wttr.in/paris) > > - public news > > - governmental information > > - cute kitten videos > > - etc. > Yes, as you can trust that you actually receive the data the server > wants you to see. If a MITM attack happens, they can serve you the wrong > news for example, wrong governmental information (deluding you to do > illegal acts) Okay, I lied, some Mercury responses today, not tomorrow. :) No MITM attack is even necessary for this n?ive "I can use plaintext to read publically available information and only turn it on when I do important secret stuff" attitude to backfire! Does this really need explanation in 2020? Here's a list of publically available, non-personal information, a lot of which you could find in a good public library, which would nevertheless be a very bad idea to be easily identified as wanting to read or having read in various times/places in recent history right up to the present, with consequences ranging from serious social stigma and ostracism to imprisonment, torture and death:
On Thu, Jun 25, 2020 at 4:04 PM solderpunk <solderpunk at sdf.org> wrote: > > a quick request for disambiguation, regarding the SUV > analogy: is the objection here mostly on the grounds of prefering > minimalism, simplicity, easier DIYability? Or is there actually an > explicit environmental component here, regarding the energy overhead of > encryption? _minimalism_: as a personal taste and aesthetic principle, Yes. Also a guiding principle, as frugality. _simplicity_: Yes, by far the most important reason -- as in "less moving parts", "no black box". Easily understanding all the core parts to the ground Grasping it all at the same time without digging deep. It relates to "_explainability_": explain sockets and basic network to a beginner and they will grasp Gemini without pain - it could even be a basic example of how to use sockets Back to the analogy: Show me a bicycle, I understand immediately how it works - except maybe the freewheel :-) Show me the modern SUV engine fuel injection system. I somehow _know_ what it does. I know it is very efficient. I know the black box contains powerful MCUs with sophisticated algorithms. I don't really feel I understand it. I remember a Python core developer coming up with a nice motto for a Python conference many years ago: "It fits my brain". Gemini, without TLS fits my brain. A bicycle, even an old car may fit my brain. A modern car does not anymore. _easier DIYability_: Yes. closely related to simplicity. A _very refreshing_ aspect of Gemini is "it is so simple you can implement it in a few hours. -- Ooops... and for TLS? -- it is very simple. Just call this [big] shared library. -- Hmm ... if I call a big TLS library where it becomes complex, I could as well _very easily_ build a HTTP/HTML client by calling libcurl, right? And arguably, I can find libcurl in as many platforms as libtls! I think it relates also to hardware hobbyists. I don't mean the Raspberry Pi sort of thing (actually more powerful than hardly old PCs). I mean rather Arduino-like boards. I could imagine some smart guys will or have already implemented a ultra minimal TCP stack, and PPP to an internet gateway and could use Gemini -- ... probably not with TLS. Phil
> No MITM attack is even necessary for this n?ive "I can use plaintext > to read publically available information and only turn it on when I do > ... Wonderfully said, i fully agree with you and will incorporate that email into my stash of arguments. Regards - xq
On Thu, Jun 25, 2020 at 6:08 PM defdefred <defdefred at protonmail.com> wrote: > > Limiting the environmental footprint of internet is useful. > For example, this site https://solar.lowtechmagazine.com/ will run longer without encryption... Right. > Limiting the latency is useful too. > So light document should display directly after request. > The one request per file paradigm makes latency more visible, when I click one image, it should display fast. Yes. But as Solderpunk just said, the whole industry is marching towards more efficient and integrated solutions to these: reducing the energy consumed and the latency -- ... at the expense of ever more complexity. Having a look at Early Data and how to safely use pre-shared keys (PSK) in the openssl documentation just made me cringe :-) > Encryption is very important too. Yes it is. And Gemini / Mercury could be a great playground to explore alternative options. > http://www.rowetel.com/?p=7207 > https://hackaday.com/2020/02/26/lora-mesh-network-with-off-the-shelf-hardware/ Cool!! thanks for the links. I am sure more and more hobbyists and hackers will develop interesting alternative network solutions. I think Gemini/Mercury could be a great fit in these new spaces. Phil
On Thu, Jun 25, 2020 at 08:59:29PM +0200, Felix Quei?ner wrote: > > > No MITM attack is even necessary for this n?ive "I can use plaintext > > to read publically available information and only turn it on when I do > > ... > > Wonderfully said, i fully agree with you and will incorporate that email > into my stash of arguments. > Thank you, but actually, I deeply regret making that email my first response to this thread. Please, nobody else reply to it. I believe in and stand by everything I said, but let's be honest, it's nothing everybody hasn't heard before. The people who are already sold on ubiquitous crypto are, well, already sold, and the people who aren't probably never will be. The last thing we need is this thread - which is already a distraction from work on Gemini proper - diverging into a long and heated argument about cryptopolitics. I regret letting myself get worked up over what is a personal hot topic for me. I'll reply again tomorrow with a more level-headed response. I do have other things to say on this - there are issues of fundamentally incompatible targets of optimisation (really low energy consumption and really low latency are at odds with one another) and about understanding what Gemini's realistic niches are (regarding really low energy consumption, I am full of enthusiasm for radical solarpunk utopia visions of an alternative internet, but I don't think Gemini fits there - it's full of "old world internet" ideas - client-server architecture, location-based addressing, etc. It has no real place in a future world of solar-powered RaspberryPis forming small local mesh networks with inter-village data transfer performed by vegans riding bikes with saddlebags full of USB sticks). And, of course, the actual role/status of the Mercury thought experiment. Cheers, Solderpunk (signing off the the night)
On Thursday 25 June 2020 20:42, solderpunk <solderpunk at SDF.ORG> wrote: > - The Bible So if you read www.the-bible.org TLS will not keep your privacy as IP:port is not encrypted... Seems that VPN is the only way to privacy... A good dictator should have a https proxy with TLS interception and force all the population to us it... freD.
On Thursday 25 June 2020 21:54, defdefred <defdefred at protonmail.com> wrote: > Seems that VPN is the only way to privacy... VPN + no log keeping gateway...
sorry list email missing in my reply... ??????? Original Message ??????? On Thursday 25 June 2020 10:23, defdefred <defdefred at protonmail.com> wrote: > On Thursday 25 June 2020 00:03, Sean Conner sean at conman.org wrote: > > > How do you safely get my public key? > > By asking to you? > By checking on https://keys.openpgp.org/? > By checking on several server on a dedicate page of known public keys? > > all of this...
sorry list email missing in my reply... ??????? Original Message ??????? On Thursday 25 June 2020 11:16, Sean Conner <sean at conman.org> wrote: > It was thus said that the Great defdefred once stated: > > > On Thursday 25 June 2020 00:03, Sean Conner sean at conman.org wrote: > > > > > How do you safely get my public key? > > > > By asking to you? > > By checking on https://keys.openpgp.org/? > > By checking on several server on a dedicate page of known public keys? > > all of this... > > Okay, I'll be replying to several of your messages here because I'm > getting mixed signals here. And then I can answer your questions. > > First: > > > It will also permit surfing at the speed of ligth with instant display of > > clicked link... something that is no more existing in the > > old-school-too-much dynamic web. > > and > > > Having TLS is better, but it come with a latency cost with the one > > connection per request behavior. Freedom is also having the choice. > > It seems a primary concern of yours is overhead of establishing a > connection. Well, TCP itself has overhead---three packets (at 40 bytes per) > before the connection is considered "up". Yes, TLS increaases that bit > more, but to say that there will be no latency without TLS is not a good > argument. UDP has no latency, but there are other issues with using it [1]. > > Continuing ... > > > Optional PGP signature is enough to provide integrity. > > Are you sure that TLS is safe? States are allowing communication they > > can't decipher? > > and > > > The fun fact is: > > > > - with TLS, the whole server is using only one certficat and the integrity > > of publication rely only on this security and you don't know if it is a > > compromised server. > > > > - with PGP signature, each writer using the server have his own certificat > > to secure his writing integrity. > > > > and > > > When you are reading pgp signed document from a server where you own a > > defined set of public pgp keys, you don't fear MITM attack (the same way > > TLS is secure only with a PKI). > > The difference is that external PGP signature are all computed only at > > document publication time and not on the fly for each user request. > > It also seems you have reservations about the PKI infrastructure, which is > fine, I do too. It seems you really distrust TLS. Okay. But PGP (for GPG > for that matter) isn't the silver bullet you think it is. So let me answer > you questions now. > > > By asking to you? > > Okay.HOW do I get you the public key and ensure you have it correctly? > Yes, it's a public key, so there's no issue with people seeing it, but how > do you know I am the one giving you the key? > > The only way I know of to be 100% certain is to exchange keys in person. > > > By checking on https://keys.openpgp.org/? > > I'll throw your own statement back at you: "you don't know if it is a > compromised server." I don't know, and I think you don't know either. > Again, your own words back at you: "Are you sure that TLS is safe? States > are allowing communication they can't decipher?" > > > By checking on several server on a dedicate page of known public keys? > > Reduces the likelyhood of MITM, but still a pain. > > The hardest part of cryptography, by far, is key management. There is > still no good way to distribute public keys that aren't subject to various > attacks. > > -spc > > [1] Namely, you open yourself up to participate in amplified denial of > service attacks. I used to run the QOTD service on UDP, until I > realized I was getting requests from forged IP addresses and sending > data to said forged IP addresses. This is why we can't have nice > things on the Internet. [2] > > [2] QUIC. Yes, I know about it. Yes, I don't like it, and it will have > similar issues to TCP. Yeah, yeah, Google says it has 0-connection > overhead, but I don't know how hard it's been attacked yet. And > guess what? That's yet another library dependency for a "simple > client" because QUIC has no support in any kernel I know of, and > probably won't for several years. I also don't trust Google, but > that's my issue.
On Thu, Jun 25, 2020 at 08:05:00PM +0000, defdefred wrote: > On Thursday 25 June 2020 21:54, defdefred <defdefred at protonmail.com> wrote: > > Seems that VPN is the only way to privacy... > > VPN + no log keeping gateway... > not really, VPN is only moving the problem to a different state/company, then the traffic would be plain text. The solution would be a VPN to the gemini server, but basicaly that's called TLS xD Paper
On Thursday 25 June 2020 23:23, <paper at tilde.institute> wrote: > not really, VPN is only moving the problem to a different state/company, > then the traffic would be plain text. The solution would be a VPN to the > gemini server, but basicaly that's called TLS xD True, but a VPN is created to serve multiple requests. May be wireguard to the gemini server is the way to go :-) freD.
> a future world of solar-powered RaspberryPis forming small local mesh networks > with inter-village data transfer performed by vegans riding bikes with > saddlebags full of USB sticks Stealing this ;) But seriously, thanks for chiming in on the Mercury discussion. I'll be happy to read your post tomorrow. makeworld
On Thu, 25 Jun 2020 at 21:48, Phil Leblanc <philanc at gmail.com> wrote: > It relates to "_explainability_": explain sockets and basic network > to a beginner and they will grasp Gemini without pain - it could even > be a basic example of how to use sockets > In my humble opinion, this extends to TLS too. Tell a beginner about asymmetric cryptography and how it can be used to negotiate a key for symmetric cryptography, and they will understand the general concept of TLS and thus "grasp Gemini without pain". I remember a Python core developer coming up with a nice motto for a > Python conference many years ago: "It fits my brain". Gemini, without > TLS fits my brain. A bicycle, even an old car may fit my brain. A > modern car does not anymore. > I have two issues with this argument. The first one is that whoever uses it, uses their brain as the golden standard. The second one is that it assumes that "basic networking" is easy to understand. I once spent weeks and weeks in low-level TCP debugging at my day job, and obviously trying to learn whatever I can to facilitate the work. After long days of reading RFCs and investigating Wireshark dumps, I still can't say I understand TCP (let alone IP or Ethernet, let alone the complete network stack). I once researched what it would take to implement an ethernet adapter on an FPGA and it's a huge amount of work. I've never taken a freewheel or a derailleur apart, yet I fully understand how they work. TCP/IP I've spent man-months on, yet I only have a surface understanding.
On Thu, Jun 25, 2020 at 06:48:04PM +0000, Phil Leblanc wrote: > _minimalism_: as a personal taste and aesthetic principle, Yes. Also > a guiding principle, as frugality. > > _simplicity_: Yes, by far the most important reason -- as in "less > moving parts", "no black box". Easily understanding all the core parts > to the ground Grasping it all at the same time without digging deep. > > It relates to "_explainability_": explain sockets and basic network > to a beginner and they will grasp Gemini without pain - it could even > be a basic example of how to use sockets > > ... > > _easier DIYability_: Yes. closely related to simplicity. A _very > refreshing_ aspect of Gemini is "it is so simple you can implement it > in a few hours. -- Ooops... and for TLS? -- it is very simple. Just > call this [big] shared library. -- Hmm ... if I call a big TLS library > where it becomes complex, I could as well _very easily_ build a > HTTP/HTML client by calling libcurl, right? And arguably, I can find > libcurl in as many platforms as libtls! > > I think it relates also to hardware hobbyists. I don't mean the > Raspberry Pi sort of thing (actually more powerful than hardly old > PCs). I mean rather Arduino-like boards. I could imagine some smart > guys will or have already implemented a ultra minimal TCP stack, and > PPP to an internet gateway and could use Gemini -- ... probably not > with TLS. Thanks for clarifying. For what it's worth, I acknowledge all these points. I appreciate beautifully minimal things like FORTH, I value ease of teaching and of learning, and I tinker with AVR micros and even more constrained platforms myself. I get it. These are important things to consider. But at the end of the day no one protocol can optimise simultaneously for all these things. Often times the different requirements fight each other. Even aesthetic minimalism and explainability can conflict, as really beautifully minimal systems with great generality/flexibility/power often require the user to first adapt to some unfamiliar, abstract mode of thinking that is not easy to grasp quickly. Ultimately, Gemini is supposed to be a practical protocol to solve a concrete, real-world problem: the web has become a disaster on many fronts simultaneously, and lots of people really want out, at least some of the time and for some things, but the only "off the shelf" thing they can flee to for roughly the same experience is Gopher, but many of them can't/won't flee to Gopher due to various shortcomings, one of which, yes, really, is the lack of encryption. I don't want Gemini to be a beautiful object of appreciation for hackers that most people have no use for (there's no shortage of these!), I want it to be a viable lifeboat for evacuees from the web. The first-class application is computer literate non-developers using "normal computers" and software other people wrote to read meaningful textual content with a reasonable expectation of privacy. I am happy to make it simpler, more beautiful, more hackable, more general purpose, friendlier to low power computers and slow networks, to whatever extent is possible without interfering with its seaworthiness as a lifeboat. I realise that it's worthwhile to do so to incentivise developers (who are inevitably the early adopters, and who will get excited by these properties) to write clients and servers and other tools which can then be used by others. And it honestly makes *me* happier to push it in those directions. But throwing out TLS so that it can be more readily implemented by somebody who just learned what a socket is yesterday is ultimately self-defeating from the lifeboat perspective. If part of the reason people want to flee from the web is because of privacy concerns, offering them a plaintext alternative makes no sense at all, and they just won't make the jump. The mandatory encryption in Gemini is an important, functional, deliberate part of the lifeboat design. It would be a bad lifeboat without out. When we *do* chase improvements in these other regards without compromising our role as a lifeboat, we also need to keep a sense of perspective, make our criteria clear, make measurements and not trust our guts, etc. I'm all for a lower power, greener internet. But if you really want to push in that direction hard, you need to make radical departures from the basic paradigms that the web and Gemini are both built around. I'm talking about systems where content is automatically and user-invisibly replicated across hosts and naturally ends up "migrating" to hosts which are closest, from a network perspective, to the places where demand for access to that content is highest. A really radical solarpunk future internet has to be built around slow, intermittent, improvised/opportunistic connections, and "offline first" thinking has to dominate. Gemini is just dead in the water in that kind of a world. It's built around old-fashioned ideas, on purpose, in order to be "radically familiar" to both users and developers from the web, because a lifeboat protocol *needs* to be radically familiar. If you throw in P2P and content-based addressing and blockchains and all the stuff you need to use to address the deep problems with the internet, a majority of both users and developers immediately have no idea what is going on and they won't get in your lifeboat because they can't. So, by virtue of its deliberate old fashionedness, Gemini is never going to be the absolute best choice for low power consumption, for low bandwidth, etc. That's not so say we shouldn't give those things any thought, but we needn't bend over backward for 1% or 2% savings because it just doesn't make sense. We should concern ourselves with the "low hanging fruit" of these problems. If people who are interested in solving problems other than the "web evacuee lifeboat" problem, or who are interested in building "jewels for hackers" want to start separate projects of their own to do so, I wish them, sincerely, all the luck in the world. I straight up do not have the time and energy spare after Gemini to have even slight active involvement in such projects, but that doesn't mean I don't wish them well. If these other projects want to make use of the text/gemini markup format, I am more than happy about that - it's a popular part of Gemini and one which is completely orthogonal to the network protocol. Please feel free to distribute it over IPFS, DAT, SSB, Gopher (maybe people can write Gopher clients which interpret item type 0 documents differently based on file extension? It forces you into ugly URLs forever, but so be it), and stuff that doesn't even exist yet. You have my blessing. Be wary, please, of spreading a small and young community (not the Gemini community, but the "neo small internet" community) too thin with multiple simultaneous projects with only minor differences between each other. Be wary of burdening client authors with an expectation that a good "small internet browser" needs to simultaneously support a large number of protocols to be useful, because that's a pain and you should be nice to client authors. Be wary that clients which speak encrypted protocols and unencrypted ones and which flip between them automatically and invisibly are fundamentally risky propositions. Be aware that "Mercury", as I sketched it, was a "conceptual navigational aid" for me to try to grapple with the question of whether or not Gemini was becoming "too complex" (and one that most people - not all, but most - had a very negative reaction to). As such it is was designed (very quickly!) from the perspective of starting with Gemini and ripping stuff out. If other projects seek to explicitly optimise some criteria which they feel Gemini is lacking in (energy consumption, network overhead or latency, fits-in-head-ability, need for external libraries), they should be aware that the Mercury sketch is not necessarily a sensible starting point, because its design took for granted certain concepts already depply established in the design of Gemini, and those concepts were not established with these other criteria in mind. You might do a lot better by starting from scratch and making all decisions with your ultimate goal firmly in mind. I think that's all I have to say on this matter. Cheers, Solderpunk
solderpunk <solderpunk at SDF.ORG> writes: > Yes, it sucks that this philosophy drags in some complexity (I chose TLS > precisely to try to minimise the *implementation* complexity, by virtue > of ubiquitious library support and documentation) and some performance > penalty (which we so far have not made much serious effort to > ameliorate) [...] One argument that I often see is that TLS makes it impossible to use Gemini with retrocomputing setups (i.e. computers older than about 2005 in this case). I've encountered this also with brutaldon, my static HTML front-end for the Fediverse; people want to connect to it from Windows 3.1 or Mac System 7, and can't use anything newer than SSLv2, which a modern server will reject. My general recommendation for this case is to run a proxy (e.g. stunnel) on your own LAN, on something like a Raspberry Pi or a cellphone, and let it handle the encryption. This would work for Gemini as well. You'd need a cleartext client, but only for retro devices. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
On Fri, Jun 26, 2020 at 07:51:05AM -0400, Jason McBrayer wrote: > One argument that I often see is that TLS makes it impossible to use > Gemini with retrocomputing setups (i.e. computers older than about > 2005 in this case). I've encountered this also with brutaldon, my static HTML > front-end for the Fediverse; people want to connect to it from Windows > 3.1 or Mac System 7, and can't use anything newer than SSLv2, which a > modern server will reject. I see it too. I love retrocomputing! Honestly. But it's insane to say that 99.9% of the world should sacrifice important privacy protections so that the geekiest 0.1% can play with very old computers. I am kind of dubious that it's impossible to compile a modern TLS library on a computer from 2005, but I'll admit I haven't tried it recently (up until approximatey 3 or 4 years ago I occasionally used a Thinkpad X60s (from 2006) and I don't remember having any TLS issues). > My general recommendation for this case is to run a proxy (e.g. stunnel) > on your own LAN, on something like a Raspberry Pi or a cellphone, and > let it handle the encryption. This would work for Gemini as well. You'd > need a cleartext client, but only for retro devices. This is a really solid suggestion and I may well add it to the FAQ in the retrocomputing sections. Cheers, Solderpunk
> On Jun 26, 2020, at 13:04, solderpunk <solderpunk at SDF.ORG> wrote: > > I want it to be a viable lifeboat for evacuees from the web This sum it up nicely. Perhaps worthwhile adding this to Gemini's FAQ or similar.
On Fri, Jun 26, 2020 at 11:04 AM solderpunk <solderpunk at sdf.org> wrote: > [...] > Ultimately, Gemini is supposed to be a practical protocol to solve a > concrete, real-world problem: [...] I don't want Gemini to be a > beautiful object of appreciation for hackers that most people have no > use for (there's no shortage of these!), I want it to be a viable > lifeboat for evacuees from the web. The first-class application is > computer literate non-developers using "normal computers" and software > other people wrote to read meaningful textual content with a reasonable > expectation of privacy. I think this is the best summary of the overall project direction. I quoted just a bit but maybe the whole paragraph could find its way in the Gemini FAQ or in a Gemini "vision" document. I _did_ read as much as I could before posting but didn't see this orientation as clearly stated.elsewhere. > I am happy to make it simpler, more beautiful, > more hackable, more general purpose, friendlier to low power computers > and slow networks, to whatever extent is possible without interfering > with its seaworthiness as a lifeboat. [...] > But throwing out TLS so that it can be more readily implemented by > somebody who just learned what a socket is yesterday is ultimately > self-defeating from the lifeboat perspective. Please note that my initial post was just a question: "Is this Mercury concept still alive and are members of the community interested in it?" I _did not_ suggest to "throw out TLS" and made it clear in the following discussion that my "gripe" (if I may say!) was not with TLS but with _mandatory_ TLS. I just happen to think that the initial http/https was not such a bad thing, contrary to the orthodox view in the HTTPS/Web world of today -- I won't explain why I think that because I don't want to pour more oil on the fire :-) > The mandatory encryption in Gemini is an > important, functional, deliberate part of the lifeboat design. It would > be a bad lifeboat without out. Good. It clarifies things. Maybe this (and other parts of your answer) could be prepended to the Mercury document as a caveat / "note to the reader" > > When we *do* chase improvements in these other regards without > compromising our role as a lifeboat, we also need to keep a sense of > perspective, make our criteria clear, make measurements and not trust > our guts, etc. I'm all for a lower power, greener internet. But if you > really want to push in that direction hard, you need to make radical > departures from the basic paradigms that the web and Gemini are both > built around. > [...]Gemini is > never going to be the absolute best choice for low power consumption, > for low bandwidth, etc. That's not so say we shouldn't give those > things any thought, but we needn't bend over backward for 1% or 2% > savings because it just doesn't make sense. We should concern ourselves > with the "low hanging fruit" of these problems. Maybe the whole discussion got side-tracked by my SUV analogy. It was mostly intended as a joke. I then made the mistake of answering too seriously to your "please disambiguate" question. I am sorry for that. BTW I loved your "vegans carrying loads of USB keys on their bikes". Good one! :-) > > Be aware that "Mercury", as I sketched it, was a "conceptual > navigational aid" for me to try to grapple with the question of whether > or not Gemini was becoming "too complex" (and one that most people - not > all, but most - had a very negative reaction to). I didn't know that. I guess this is why I asked on the mailing list. I do understand now that it is a touchy subject. I am sorry for the noise. > I think that's all I have to say on this matter. Heard you loud and clear ;-) Phil
On Fri, Jun 26, 2020 at 05:13:59PM +0000, Phil Leblanc wrote: > I think this is the best summary of the overall project direction. I > quoted just a bit but maybe the whole paragraph could find its way in > the Gemini FAQ or in a Gemini "vision" document. I _did_ read as much > as I could before posting but didn't see this orientation as clearly > stated.elsewhere. I've never stated it that way before. :) My own understanding of these things clarifies over time in response to other people's ideas about the direction things should take. For which I am grateful! > Please note that my initial post was just a question: "Is this Mercury > concept still alive and are members of the community interested in > it?" > > I _did not_ suggest to "throw out TLS" and made it clear in the > following discussion that my "gripe" (if I may say!) was not with TLS > but with _mandatory_ TLS. Duly noted! I guess my reply was, implicitly, addressed at various folks who expressed disapproval of the TLS idea at various times. > Maybe the whole discussion got side-tracked by my SUV analogy. It was > mostly intended as a joke. > I then made the mistake of answering too seriously to your "please > disambiguate" question. I am sorry for that. No need! > BTW I loved your "vegans carrying loads of USB keys on their bikes". > Good one! :-) I'm not even sure I was joking! If we genuinely want to minimise "Environmental Damage Units" per byte transferred per metre per second, where EDU is a vague all-encompassing measure which incorporates CO2 emissions, consumption of non-renewable resources, etc., I don't doubt that there are certain combinations of payload size and distance where "bikenet" is actually quite competitive, especially if you replace the USB keys with 1TB hard drives. A plant-based diet would undeniably help decrease the EDU total, but it may not even be necessary to outcompete higher tech solutions. It gets even better if you consider that the bike is a general-purpose tool which could also transport food, medicine, etc. at the same time... > I didn't know that. I guess this is why I asked on the mailing list. I > do understand now that it is a touchy subject. I am sorry for the > noise. No need to apologise, really! Cheers, Solderpunk
It was thus said that the Great defdefred once stated: > On Thursday 25 June 2020 23:23, <paper at tilde.institute> wrote: > > not really, VPN is only moving the problem to a different state/company, > > then the traffic would be plain text. The solution would be a VPN to the > > gemini server, but basicaly that's called TLS xD > > True, but a VPN is created to serve multiple requests. Yes and no. A VPN is *not* at all like HTTPS or Gemini. It is *not* used for program to program communication (the TCP layer) but computer to computer communciation (the IP layer). Technically, a VPN routes IP (the packet of which are encrypted) over IP (the packets of which are regular, unencrypted packets) and looks like a router. Normally, traffic would go: [program1 -> data -> TCP -> IP -> client] (1st computer) -> router -> router -> ... router -> [server -> IP -> TCP -> data -> program2] (2nd computer) A VPN does this: [program1 -> data -> TCP -> IP -> VPN endpoint -> client] (1st computer) -> router -> router ... -> router -> [VPN endpoint] (2nd computer) -> router -> router ... -> router -> [server -> IP -> TCP -> data -> program2] (3rd computer) I.E., a VPN is just a fancy router. The server never knows (nor cares) about the VPN. > May be wireguard to the gemini server is the way to go :-) Stop trying to sell it as a TLS alternative---it *ISN'T!* -spc
On Fri, Jun 26, 2020 at 06:32:19PM -0400, Sean Conner wrote: > It was thus said that the Great defdefred once stated: > > On Thursday 25 June 2020 23:23, <paper at tilde.institute> wrote: > > > not really, VPN is only moving the problem to a different state/company, > > > then the traffic would be plain text. The solution would be a VPN to the > > > gemini server, but basicaly that's called TLS xD > > > > True, but a VPN is created to serve multiple requests. > > Yes and no. A VPN is *not* at all like HTTPS or Gemini. It is *not* used > for program to program communication (the TCP layer) but computer to > computer communciation (the IP layer). Technically, a VPN routes IP (the > packet of which are encrypted) over IP (the packets of which are regular, > unencrypted packets) and looks like a router. Normally, traffic would go: > > [program1 -> data -> TCP -> IP -> client] (1st computer) > -> router -> router -> ... router -> > [server -> IP -> TCP -> data -> program2] (2nd computer) > > A VPN does this: > > [program1 -> data -> TCP -> IP -> VPN endpoint -> client] (1st computer) > -> router -> router ... -> router -> > [VPN endpoint] (2nd computer) > -> router -> router ... -> router -> > [server -> IP -> TCP -> data -> program2] (3rd computer) > > I.E., a VPN is just a fancy router. The server never knows (nor cares) > about the VPN. I know that, I was joking. My point was that defdefred was trying to invent something like TLS, so I pointed him in the right direction ;) Paper
---