7 ms·

Counterpoints: What makes Gopher irrelevant? 1. Only one byte to specify filetype in the protocol, with only a few filetypes being being defined in the protoco

by ghssds 2y ago

Counterpoints: What makes Gopher irrelevant? 1. Only one byte to specify filetype in the protocol, with only a few filetypes being being defined in the protocol, the remaining being unofficial and implementation-dependent. Most filetypes that are defined still are ambiguous. 2. No support for Unicode in the protocol, or even for any character set but ISO-8859-1. Non-europeans can eat shit and die. 3. No support for encryption nor compression in the protocol. 4. Any implementation supporting an above-mentioned feature is operating out of specification.

erik_seaberg 2y ago
They were talking about finally adding MIME types to Gopher+ in 2002, which I think was too late to compete with the Web. Sniffing for UCS-2 or UTF-8 or Latin-1 might have worked or might have given us more https://en.wikipedia.org/wiki/Mojibake https://en.wikipedia.org/wiki/Mojibake.
- paulddraper 2y ago
  And what happened since 2002? Irrelevance?
  - erik_seaberg 2y ago
    That's my guess.
  - ahefner 2y ago
    Gopher had been irrelevant for half a decade by 2002.
contingencies 2y ago
Counterpoints: why are these not a big deal? 1. With libmagic these days this is sort of not that useful. Type "9" means Item is a binary file. Client must decide what to do with it. Just use type 9 and then determine the filetype using the first few bytes. 2. Screams for an upgrade. Could assume if encryption is used, UTF-8 is the new default charset. 3. Most TCP services are wrappable, eg. over SSL or ssh with compression. 4. Fortunately the once-feared gopher police, famed as both jaw-droppingly vicious and most morally dubious in method, have long since retired to the Bahamas.
- spc476 2y ago
  1. I agree. 2. This would be Gemini. Most people here don't like it either. Also, most gopher sites I visit use UTF-8, and my client (which I wrote---it's not hard) hasn't had an issue with mojibake. 3. It's not as simple as wrapping TLS around the TCP connection. [1] 4. There were once gopher police? [1] I talk about it here: https://boston.conman.org/2019/03/31.1 https://boston.conman.org/2019/03/31.1
  - contingencies 2y ago
    3. Break backward compatibility. It's fine. Nobody needs to run an old client these days. I'd worry more about ensuring curl and wget have support than old gopher clients.
  - snvzz 2y ago
    Gemini is far from perfect, and yet an immutable spec. A dead end. Just some narcissists' pet project that should never been entertained.
    - throw10920 2y ago
      Gemini is, explicitly, an art project. It's not, nor is it meant to be, a serious communication technology. This both explains some of the bizarre (and anti-intellectual) design decisions, and also makes it crystal clear that it shouldn't be used for anything serious (e.g. serving the course website for a class you're teaching).
  - smaudet 2y ago
    3. Hmm. I think the biggest issue then might be the inability to extend the protocol then, not the lack if TLS. Http(s) had at least some back and forth that allowed clients/servers to do protocol negotiation, not perfect, but workable such that normally crashes do not occur... Although speaking of crashes, if your app is as poorly written to easily crash, perhaps it should be re-written - if e.g. gopher were to come back in a meaningful way, that sounds like ripe pickings for security folk.
- 2y ago
trwbb 2y ago
[flagged]
GuB-42 2y ago
> No support for encryption nor compression in the protocol. I consider it a feature. Compression adds complexity. Not only you have to implement compression itself, but also a way to communicate what type of compression you want. It also makes the protocol less readable though packet dumps and make using simple tools like netcat more complex. Simplicity is a big reason for using Gopher. Encryption adds a lot of complexity, same argument, but ten times worse. In addition to complexity, I don't really like the idea of HTTPS-style encryption for a niche like this, for the following reasons: - HTTPS gives only limited privacy protection, an eavesdropper can still see your IP address and the server you are trying to reach. It is not TOR. - The signature aspect only ensures you are connecting to the right server, not that the content has been tempered with. It is not PGP. - Encryption is useful to send secrets, like passwords or credit card numbers. Why would you want use passwords? Isn't the big idea to make information publicly available? Why hide things behind passwords? And why would you want to send a credit card number, do you want e-commerce on your platform? Not having encryption is a way to ensure all information on your small network is freely accessible and stays this way. And if you disagree with regard to encryption, maybe take a look at Gemini. 1 and 2 are good points.
- woodruffw 2y ago
  > The signature aspect only ensures you are connecting to the right server, not that the content has been tempered with. It is not PGP. The “T” in TLS stands for “transport.” It absolutely does guarantee that the content has not been tampered with, unless you don’t trust the website itself (in which case you would trust the PGP key no more or less than you would the website’s certificate). But regardless, this kind of argument against encryption is just plain bad: there are all kinds of things you might want to do on the Internet that don’t involve passwords or “secret” information that a passive adversary (like a government or ISP) shouldn’t be able to observe. The contents of the political websites you visit, for example. This is especially true on our modern Internet, where observing individual endpoint IPs doesn’t really tell the passive adversary much (thanks to CGNAT and SNI/multiple sites hosted on the same IP).
- throw10920 2y ago
  > {Compression, encryption} adds complexity. There's very little downside to making those optional, and significant upside. Communication technologies without both of those things are no more than toys.
chpatrick 2y ago
> Non-europeans can eat shit and die. And Hungarians...
- bdjsiqoocwk 2y ago
  Bulgarians, Serbians, Ukranians...
- Pannoniae 2y ago
  To be fair, you can write Hungarian without accents. It's fairly readable, it's not a huge deal. The bigger problems happen with languages written with non-Latin alphabets.
ReleaseCandidat 2y ago
> Non-europeans ISO-8859-1 only supports Italian, Spanish, Portuguese, French, German, Dutch, English, Danish, Swedish, Norwegian, and Icelandic. So, about half of Europe.
- HelloNurse 2y ago
  Lack of support for "non-Europeans" is a very generous way to describe ISO-8859-1. Apart from most European and non-European languages, it doesn't support emojis, mathematical symbols, combining marks, and many other characters that are normally taken for granted.
graemep 2y ago
The lack of encryption is a problem, and the filetypes issue seesm to be one. > Non-europeans can eat shit and die. A highly inaccurate and emotive way to put it. I appears it provides all characters used by English, Spanish and Portuguese which, while European in origin, are main languages in all the Americas, Australia and New Zealand. On top of that English is widely spoken (often as a first language) in much of Africa and Asia. It also provides full support for Bahasa Indonesia and Afrikaans. On the other hand, it does not provide any characters for Russian (the language with the most speakers in Europe) or other languages written in Cyrillic letters, or full support for French of German, the next most widely spoken languages in Europe.
- paulddraper 2y ago
  If we're counting Australians as non-Europeans, surely we must be counting Russians as Asians.
  - graemep 2y ago
    Australia is not in Europe. Most of the population of Russia lives in Europe - a minority of Russians can be counted as Asians going strictly be geography, and I think Russian would still be the most widely spoken language just counting the number of speakers in Europe.
nonrandomstring 2y ago
What makes gopher still relevant in 2024, for information centred activities (like research [0], as opposed to shopping, gossiping and showing-off) is that it's structured. What's becoming irrelevant about the Web is search. The decline of search - and the whole spider/retrieval model - is a real problem in the post AI-SEO-optimised spam epoch. The Web is really a giant heap. People stopped usefully linking over a decade ago. By contrast Gopher offers a different way of discovering content because it tends toward structure. [0] https://news.ycombinator.com/item?id=40345006 https://news.ycombinator.com/item?id=40345006
- giantrobot 2y ago
  You're pretending you can't do on the web what you can do on Gopher. This is just the most absurd argument. Anyone building a gopherhole can built the exact same structure on a website. Better is anyone can access it because most of the planet carries a web browser in their pocket. If you want to put together structured content on the web no one is stopping you. Fetishizing gopher is the weirdest thing. You're making arguments about SEO and then talking about a protocol that offers zero discovery unless someone fires up some old Veronica servers. If you're unconcerned about SEO/Google there's no reason to include anything SEO or Google related on a website. It's fine to dislike how Google has ruined the web. That doesn't make the web itself bad or useless. Today you can use the web the exact same way we did thirty years ago. It has way more capability (even ignoring JavaScript bullshit) than gopher and you can reliably send a link to content to someone that isn't obsessed with a dead protocol.
  - nonrandomstring 2y ago
    That's like saying you can do anything by writing a book that you can do with haiku. It's trivially true. But it misses the value of strongly imposed constraints. I know that goes against a prevailing (well USA) culture of "bigger and more is always better". Sometimes less is more. > It's fine to dislike how Google has ruined the web. That doesn't make the web itself bad or useless. It sort of does though. It's like saying; yeah it's bad that loads of drug dealers and thieves moved into the neighbourhood. but that doesn't make the neighbourhood itself bad. For practical purposes it totally does. It may not make the buildings and streets bad, as if a technology in isolation could be "bad", but it makes nobody want to go there.
hulitu 2y ago
> 3. No support for encryption nor compression in the protocol. This is a feature.
jandrese 2y ago
Only one byte for the filetype is comically shortsighted. Even HFS from 1985 had 4 byte codes. The lack of Unicode is understandable given the era, but the lack of support for any other encoding is another "this is a toy system" red flag. Encryption and compression are the kind of thing that get layered on later as the protocol matures, leaving them out of the first implementation is not an issue. I'm sure if Gopher had stuck around there would have been a version 2.0 of the spec that addressed these issues, although that one byte filetype would make for some fun backwards compatibility hacks. The bigger issue is "what compelling reason would you have to use Gopher instead of HTTP"? What does it do better? Small reductions in overhead aren't generally worth the tradeoff. On a side note I remember one of the earliest search engines for Gopher was named VERONICA, for Very Easy Rodent Oriented Net-wide Index to Computer Archives, a glorious backronym that came about because they wanted to riff on the FTP search engine being named ARCHIE.

by ghssds 2y ago

erik_seaberg 2y ago

They were talking about finally adding MIME types to Gopher+ in 2002, which I think was too late to compete with the Web. Sniffing for UCS-2 or UTF-8 or Latin-1 might have worked or might have given us more https://en.wikipedia.org/wiki/Mojibake https://en.wikipedia.org/wiki/Mojibake.

paulddraper 2y ago
And what happened since 2002? Irrelevance?
- erik_seaberg 2y ago
  That's my guess.
- ahefner 2y ago
  Gopher had been irrelevant for half a decade by 2002.

contingencies 2y ago

Counterpoints: why are these not a big deal? 1. With libmagic these days this is sort of not that useful. Type "9" means Item is a binary file. Client must decide what to do with it. Just use type 9 and then determine the filetype using the first few bytes. 2. Screams for an upgrade. Could assume if encryption is used, UTF-8 is the new default charset. 3. Most TCP services are wrappable, eg. over SSL or ssh with compression. 4. Fortunately the once-feared gopher police, famed as both jaw-droppingly vicious and most morally dubious in method, have long since retired to the Bahamas.

spc476 2y ago
1. I agree. 2. This would be Gemini. Most people here don't like it either. Also, most gopher sites I visit use UTF-8, and my client (which I wrote---it's not hard) hasn't had an issue with mojibake. 3. It's not as simple as wrapping TLS around the TCP connection. [1] 4. There were once gopher police? [1] I talk about it here: https://boston.conman.org/2019/03/31.1 https://boston.conman.org/2019/03/31.1
- contingencies 2y ago
  3. Break backward compatibility. It's fine. Nobody needs to run an old client these days. I'd worry more about ensuring curl and wget have support than old gopher clients.
- snvzz 2y ago
  Gemini is far from perfect, and yet an immutable spec. A dead end. Just some narcissists' pet project that should never been entertained.
  - throw10920 2y ago
    Gemini is, explicitly, an art project. It's not, nor is it meant to be, a serious communication technology. This both explains some of the bizarre (and anti-intellectual) design decisions, and also makes it crystal clear that it shouldn't be used for anything serious (e.g. serving the course website for a class you're teaching).
- smaudet 2y ago
  3. Hmm. I think the biggest issue then might be the inability to extend the protocol then, not the lack if TLS. Http(s) had at least some back and forth that allowed clients/servers to do protocol negotiation, not perfect, but workable such that normally crashes do not occur... Although speaking of crashes, if your app is as poorly written to easily crash, perhaps it should be re-written - if e.g. gopher were to come back in a meaningful way, that sounds like ripe pickings for security folk.
2y ago

trwbb 2y ago

[flagged]

GuB-42 2y ago

> No support for encryption nor compression in the protocol. I consider it a feature. Compression adds complexity. Not only you have to implement compression itself, but also a way to communicate what type of compression you want. It also makes the protocol less readable though packet dumps and make using simple tools like netcat more complex. Simplicity is a big reason for using Gopher. Encryption adds a lot of complexity, same argument, but ten times worse. In addition to complexity, I don't really like the idea of HTTPS-style encryption for a niche like this, for the following reasons: - HTTPS gives only limited privacy protection, an eavesdropper can still see your IP address and the server you are trying to reach. It is not TOR. - The signature aspect only ensures you are connecting to the right server, not that the content has been tempered with. It is not PGP. - Encryption is useful to send secrets, like passwords or credit card numbers. Why would you want use passwords? Isn't the big idea to make information publicly available? Why hide things behind passwords? And why would you want to send a credit card number, do you want e-commerce on your platform? Not having encryption is a way to ensure all information on your small network is freely accessible and stays this way. And if you disagree with regard to encryption, maybe take a look at Gemini. 1 and 2 are good points.

woodruffw 2y ago
> The signature aspect only ensures you are connecting to the right server, not that the content has been tempered with. It is not PGP. The “T” in TLS stands for “transport.” It absolutely does guarantee that the content has not been tampered with, unless you don’t trust the website itself (in which case you would trust the PGP key no more or less than you would the website’s certificate). But regardless, this kind of argument against encryption is just plain bad: there are all kinds of things you might want to do on the Internet that don’t involve passwords or “secret” information that a passive adversary (like a government or ISP) shouldn’t be able to observe. The contents of the political websites you visit, for example. This is especially true on our modern Internet, where observing individual endpoint IPs doesn’t really tell the passive adversary much (thanks to CGNAT and SNI/multiple sites hosted on the same IP).
throw10920 2y ago
> {Compression, encryption} adds complexity. There's very little downside to making those optional, and significant upside. Communication technologies without both of those things are no more than toys.

chpatrick 2y ago

> Non-europeans can eat shit and die. And Hungarians...

bdjsiqoocwk 2y ago
Bulgarians, Serbians, Ukranians...
Pannoniae 2y ago
To be fair, you can write Hungarian without accents. It's fairly readable, it's not a huge deal. The bigger problems happen with languages written with non-Latin alphabets.

ReleaseCandidat 2y ago

> Non-europeans ISO-8859-1 only supports Italian, Spanish, Portuguese, French, German, Dutch, English, Danish, Swedish, Norwegian, and Icelandic. So, about half of Europe.

HelloNurse 2y ago
Lack of support for "non-Europeans" is a very generous way to describe ISO-8859-1. Apart from most European and non-European languages, it doesn't support emojis, mathematical symbols, combining marks, and many other characters that are normally taken for granted.

graemep 2y ago

The lack of encryption is a problem, and the filetypes issue seesm to be one. > Non-europeans can eat shit and die. A highly inaccurate and emotive way to put it. I appears it provides all characters used by English, Spanish and Portuguese which, while European in origin, are main languages in all the Americas, Australia and New Zealand. On top of that English is widely spoken (often as a first language) in much of Africa and Asia. It also provides full support for Bahasa Indonesia and Afrikaans. On the other hand, it does not provide any characters for Russian (the language with the most speakers in Europe) or other languages written in Cyrillic letters, or full support for French of German, the next most widely spoken languages in Europe.

paulddraper 2y ago
If we're counting Australians as non-Europeans, surely we must be counting Russians as Asians.
- graemep 2y ago
  Australia is not in Europe. Most of the population of Russia lives in Europe - a minority of Russians can be counted as Asians going strictly be geography, and I think Russian would still be the most widely spoken language just counting the number of speakers in Europe.

nonrandomstring 2y ago

What makes gopher still relevant in 2024, for information centred activities (like research [0], as opposed to shopping, gossiping and showing-off) is that it's structured. What's becoming irrelevant about the Web is search. The decline of search - and the whole spider/retrieval model - is a real problem in the post AI-SEO-optimised spam epoch. The Web is really a giant heap. People stopped usefully linking over a decade ago. By contrast Gopher offers a different way of discovering content because it tends toward structure. [0] https://news.ycombinator.com/item?id=40345006 https://news.ycombinator.com/item?id=40345006

giantrobot 2y ago
You're pretending you can't do on the web what you can do on Gopher. This is just the most absurd argument. Anyone building a gopherhole can built the exact same structure on a website. Better is anyone can access it because most of the planet carries a web browser in their pocket. If you want to put together structured content on the web no one is stopping you. Fetishizing gopher is the weirdest thing. You're making arguments about SEO and then talking about a protocol that offers zero discovery unless someone fires up some old Veronica servers. If you're unconcerned about SEO/Google there's no reason to include anything SEO or Google related on a website. It's fine to dislike how Google has ruined the web. That doesn't make the web itself bad or useless. Today you can use the web the exact same way we did thirty years ago. It has way more capability (even ignoring JavaScript bullshit) than gopher and you can reliably send a link to content to someone that isn't obsessed with a dead protocol.
- nonrandomstring 2y ago
  That's like saying you can do anything by writing a book that you can do with haiku. It's trivially true. But it misses the value of strongly imposed constraints. I know that goes against a prevailing (well USA) culture of "bigger and more is always better". Sometimes less is more. > It's fine to dislike how Google has ruined the web. That doesn't make the web itself bad or useless. It sort of does though. It's like saying; yeah it's bad that loads of drug dealers and thieves moved into the neighbourhood. but that doesn't make the neighbourhood itself bad. For practical purposes it totally does. It may not make the buildings and streets bad, as if a technology in isolation could be "bad", but it makes nobody want to go there.

hulitu 2y ago

> 3. No support for encryption nor compression in the protocol. This is a feature.

jandrese 2y ago

Only one byte for the filetype is comically shortsighted. Even HFS from 1985 had 4 byte codes. The lack of Unicode is understandable given the era, but the lack of support for any other encoding is another "this is a toy system" red flag. Encryption and compression are the kind of thing that get layered on later as the protocol matures, leaving them out of the first implementation is not an issue. I'm sure if Gopher had stuck around there would have been a version 2.0 of the spec that addressed these issues, although that one byte filetype would make for some fun backwards compatibility hacks. The bigger issue is "what compelling reason would you have to use Gopher instead of HTTP"? What does it do better? Small reductions in overhead aren't generally worth the tradeoff. On a side note I remember one of the earliest search engines for Gopher was named VERONICA, for Very Easy Rodent Oriented Net-wide Index to Computer Archives, a glorious backronym that came about because they wanted to riff on the FTP search engine being named ARCHIE.