#gopher

It's neat to see so many people talking about doing weird things within he Gopher protocol.

I'm excited, especially because I feel at least partially responsible for keeping this conversation rolling.

I'm also seeing some pretty negative comments, both from folks that don't understand why we'd wanna do this, and from folks that use gopher now and see our ideas as evil and bad and worthy of ridicule.

That's less neat.

This is a thread.

Doing silly things with Gopher is neat! You wanna serve DAT via gopher? Cool! That's neat! You wanna implement SSL? You wanna use it like the web? Great!

It will not hurt people who use gopher the way it has been used for ~30 years. It won't break things. Those folks can ignore what we're doing.

This doesn't have to be antagonistic. If you don't wanna take part, that's cool! I'm not here to force you. Keep doing what you're doing, or do what we're doing. Either is wonderful.

What I want:

- A gopher client with the ability for the user to select fonts and colors for menus.

- A gopher client that renders HTML, Markdown and Plaintext.

- While rendering HTML, it explicitly ignores any scripting or styling (aside from anything the user has defined.)

- The client offers users the option to download and render inline images in HTML and markdown files (but only over gopher)

- Links within HTML and Markdown files to work the same as in menus.

- This HTML and Markdown rendering is entirely optional, you can just as easily download the files and render them somewhere else.

- I personally prefer Markdown to plaintext in pretty much all contexts, because people *already* use markdown formatting in plain text, and I'd rather read an unrendered markdown file than something with _no_ links, etc. So I want to see more gopher publishers publishing markdown.

- I want more gopher servers,

- I want more scripts for publishing to gopher. I really like the descriptions I've read of the phlog software on SDF, but I've never used it.

That's pretty much it. Beyond that, I just want to see more people hosting Gopher sites on their home computers. I want to see more people focusing on substance over style.

Security/Encryption -
Long term, yeah, this is probably something we need.

I don't know of a way to do SSL style encryption over gopher at this time. I don't know if this would even really be valuable. For my personal use, I'm fine with SSHing to another server, and doing my gophering from there. No one local is snooping, at least.

If you need security, use .onion you know?

So yes! Security and encryption is something someone can build. Implement it in a way that's backwards compatible. At the very least, it won't hurt anything.

But also, if you need security go use something designed to be secure.

- Gopher + DAT: This sounds absolutely wild and ridiculous. Go for it! I dunno why you'd want that, but if you do, go for it.

- Other Gopher "abuse:
As long as you don't break backwards compat, do whatever.

The Gopher protocol was written in like 1991 or something? And it will run pretty much anywhere.

The protocol is so simple that you can hack together a client in a few dozen lines of whatever.

You can implement clients on 8 bit hardware. It will be faster and easier to use and more accessible than a web browser.

It's been around forever. It's simple. It works well. It provides just enough functionality to get you to your content.

Plus, most modern Gopher servers provide an HTTP gateway. (See http://gopher.ofmanytrades.com)

So even if you think that we should just focus on making the web less antagonistic towards users, we can use gopher as one avenue towards that.

Gopher isn't ever going to replace the web.

That's not my goal. That's not anyone's goal.

Gopher is just a weird little non-capitalist, human scale way for us to publish and consume stuff.

It's fun, it's easy, and it's a weird way for folks (like you and me) to resist, in our own small way, the shit that the big centralized services do, and the things that netflix pushed the w3c in to doing.

I guess I gotta talk about the w3c a second, too.

The modern web is kind of crap. I won't rehash that here, but you know it's crap.

The w3c has moved to make it more crap by bundling DRM in our web browsers, and making it a felony to do security research on browsers that include that DRM.

This is *real* bad.

That's my biggest reason for embracing this gopher stuff.

The w3c sold us out, and the web browser isn't, can't be, truly safe anymore.

We don't need more #DRM in our lives. We don't need more very complex software that no one understands.

Simple software, when possible, is better software.

the #w3c fucked us when they voted to allow #EME without even basic protection for security research.

But before that, Google and Facebook screwed us over by stuffing more and more javascript in to our pages, and normalizing more tracking everywhere.

Be kind to one another.

Don't worry, we won't break the thing you love.

We're only here because the modern web is user hostile, and modern web browsers do/will have stuff in them that makes it a felony to keep them secure.

Tim Burners Lee killed Gopher way back when, and then his bad decisions made the web unsafe, so some of us are going back to Gopher.

@ajroach42 Do you have a list or example of some of the early bad choices? I've had a hard time finding them actually defined, which if it weren't for the fact that very practical & knowledgeable people were stating it, would make it sound like it was just nostalgia. A design document for fixing the web is needed & these early concerns need to be defined to help.

@Sci most of the bad choices have been recent.

The web was a good platform until it wasn’t anymore.

Recent bad decisions: EME (rendering browsers essentially permanently inesecure to make Netflix happy), allowing css to be, essentially, a complete programming language, stuffing JavaScript in to the browser.

There have been other questionable or shortsighted choices (the use of the anchor tag for links, the competing image tags in early html—the worst one won)

@ajroach42 It's been a long time since I was into the deep technicalities, so I'm playing catch-up a bit.

If I understand correctly, EME renders browsers insecure because it allows a remote vendor to install a decryption module into your browser, which could contain anything including malicious code or security vulnerabilities, yes?

And both CSS and Java because they push browsers beyond just displaying static documents, but allow code execution within them?

@Sci EME is a form of DRM that is/will be/is bundled in to web browsers.

Technically it's sandboxed and tested and should be "safe", but because it is a form of DRM it is protected by the DMCA making the disclosure of security vulnerabilities in the webbrowser that *might* be related to EME a felony.

The w3c was given the opportunity to stop this, and make members provide an exception for security research and/or accessibility. They refused.

@Sci So now every major web browser has a thing in it that it's illegal for anyone to look at, and we don't have even the most basic assurances that someone who discovers a flaw in EME (and there will be flaws) won't go to jail for disclosing it.

CSS and Javascript I'll address separately.

CSS is supposed to define how a browser displays elements on a page. It's now a programming language. Current CSS takes lots of computing power (which is bad) and can be used to hide/do malicious things.

@Sci

Some things are easier and more secure because of CSS3. A lot of things are harder, and more complex (and less secure because they are more complex, if not because they are directly less secure.) This means that you've got to update your hardware more often. Modern CSS techniques also frequently wreak havoc with accessibility, because everyone is trying to reinvent the wheel.

@Sci Javascript.

Javascript is complicated. I am of the opinion that netscape made a mistake including it in browsers to begin with, but that's just me.

All the stuff I said about accessibility and hardware/performance issues goes double for JS.

Except that JS is a full programming language from the ground up. You can run modern applications in it. You can use it to emulate old computers.

IT's neat!

It's also a huge performance and security hole. Malicious JS can cause many problems.

@Sci That is not to say that I think Javascript in general is bad!

I think it's great. Having this almost universal platform for application delivery is really neat!

I don't think it should be required to view a news article, or to log in to mastodon, or send an email.

I think js should be downloaded from your web browser and then rendered in a separate application.

Browsers shouldn't assume Javascript is available. Browsers shouldn't know about JS.

@Sci You want AJAX features in your web page? Great! What you want is no longer a web page, it's now an application. We'll run it in a separate environment.

You want to mandate AJAX features so that I can read your news article or watch your video? That's probably actually sketchy!

And then you've got shit like: https://www.eff.org/deeplinks/2009/09/online-trackers-and-social-networks which illustrates the tracking problem back in 2009. (it's worse now.)

@Sci This is not a hopeless situation. I'm probably exaggerating the potential hazards for the average end user, but also it could potentially get a Lot worse that it already is.

We're basically waiting for one of these things to snap, you know? Things haven't broken yet, but they could without much warning. All the bad things are in place, waiting for a catastrophe.

@ajroach42 Since modern cybercrime is all about finding an exploit and automating it, the hazards for the average end-user would seem just as high.

Thanks for your replies. It's helped frame it a lot better. It's hard to imagine the net as other than an application layer already.

From a utility perspective it makes sense to have the browsers do the heavy processing rather than just using them as UI for remote server apps. But when that code can contain anything, & DMCA stops it being checked.. ugh.

@Sci

IMO, we need more server side code, and more dedicated applications, and less reliance on JS to replace native browser controls.

Have you read this: https://www.baldurbjarnason.com/notes/under-engineering-websites/

It's not directly about the problems of the modern web that I discussed here, but it goes through a lot of the reasons that native browser functions get re-engineered in worse form by valley companies, which is 100% part of the problem.

@ajroach42 @Sci

You mean, like Dropbox being essentially Gopher but poorer?

@h @Sci

Dropbox adds bidirectional sync to their desktop client, which is neat.

Using it through the web browser leaves a lot to be desired.

@ajroach42 @Sci

Well maybe Gopher 2049 should add some of the Dropbox functionality then, minus the Javascript.

#gopher #gopher2049

@h @ajroach42 I don't have experience with Gopher, but from what I read it sounds very similar to FTP in intent. A network of file systems linking to each-other, rather than documents linking to each-other with http.

@Sci Yeah, it's basically a menu system to sit on top of FTP.

here, try http://gopher.ofmanytrades.com

That's a web proxy for my gopher server.

@ajroach42 It does seem so essential and useful, and in the current climate the only thing that makes it a hard sell is that all resources are presented as equal. You can't skin their presentation in standard Gopher, can you?

@Sci Nope!

Well, no with caveats.

We totally could develop a system to let users or servers skin the presentation. Wouldn't even be that difficult.

Clients would have to support it, and we'd need to ensure it was a progressive enhancement, you know?

But I'm not sure it'd be worth it.

@ajroach42 I'm thinking along the lines that if I had two primary forms of content on a Gopher server and wanted to promote one of them over the other, I wouldn't be able to. It's good for library-style access, but not so good for individuals.

Gopher as a supporting layer under http sounds good to me. Automatically display all publicly accessible folders in Gopher-mode. Or go to http mode for more contextual arrangement of resources.

@Sci Unless I'm misunderstanding what you mean?

@ajroach42 I was thinking if I were to build something like http on top of Gopher, I'd probably treat the filesystem as a list of unique resources and reference them through it rather than as relative file locations.

I've not had to think in a structured way in a long while, so I'm liable to misuse a lot of terms.