Many of us have been frankly sick of it for years. The problem is more political than technical. How to convince thousands and millions that unhealthy things are bad for them and they must depart from their Facebooks and Instagrams and Tumblrs.

The real problem is figuring out how to build it without any support whatsoever.

@h@enkiv2@jaycie thank you for hacking!! Indeed, the WWW has been co-opted by commercial interests because it wasn't designed to resist them. The Internet is entirely compromised by state actors, again because it wasn't designed to resist them. The only choice now is build a new system which makes the old one obsolete!

I share many of your views, and I wholeheartedly support the gopher subculture for other reasons as expressed earlier, but using gopher for security reasons is an argument that doesn't make any sense whatsoever.

It's like pouring more salt on the fries to make them more nutritive.They taste better, but the argument for nutrition is moot.

@h@ajroach42@uranther@jaycieAgreed. Gopher is not merely non-secret but also unsigned and easily forged, at the protocol level. It should not be used for anything intended to be secret, nor should content transmitted over gopher be trusted to be untampered-with, in the absence of other mechanisms.

(Though you could just encrypt text files with your private key or somebody's public key and serve them over gopher, or sign them with your private key, or whatever.)

@jaycie@uranther@ajroach42@hOn the other hand, *right now* gopher is dead enough that not even the NSA is probably paying any attention to gopher traffic, and there are no accepted mechanisms for account-oriented (i.e., user-associated) storage over gopher. This makes it a poor match for dragnet surveillance -- 5eyes is probably not looking at gopher traffic unless it's associated with one of a couple thousand specific persons of interest.

@h@ajroach42@urantherIf we're planning on using gopher seriously (rather than having it be one of twenty or thirty small-scale alternate protocols), we ought to invest in mechanisms for signing, encryption, and onion routing.

(Luckily, these are all solved problems: with the exception of onion routing, every linux distro ships with pretty solid shell tools for handling this, and onion routing is as easy as having a directory of repeaters.)

@h@enkiv2@ajroach42@uranther again, the strength of Gopher is the SHEER simplicity or just sending something to port 70 and getting it back. when you're talking about blockchains or markup parsers... why not just HTTP, and keep your content simple?

IPFS is just a DHT, and one with pretty wide support. Supporting an IPFS type is a matter of maybe three lines of code added to my client. (This would not be IPFS over gopher or gopher over IPFS but merely gopher links for IPFS hashes, the same way gopher links support HTTP URLs and telnet connection info.)

@enkiv2@h@ajroach42@uranther I thought IPFS would be more complex to support. This is good to know, though I'm not personally convinced on the utility of IPFS. (discussion for another time, I guess)

As stated upthread though, I just don't see the benefit of adding this to gopher instead of just using existing web technology minus the nasty. I like gopher because it's /dead/ simple, and from a time when that mattered.

@h@enkiv2@ajroach42@uranther so really, my question is - why add this stuff onto Gopher, which is fun because it IS a simple relic of 1990? If your problem is with the garbage of the modern web, no one said HTTP and HTML are cancerous with it - it'd be little trouble to just use all the existing work of the web, and not take the bad parts. By extending gopher in these ways, what's the benefit?

wrt blockchains, I was pointing it out as a blanket thing for onions/IPFS even if those things aren't.

1) I have expressed before that HTTP and HTML are part of the problem of centralisation. I don't remember having said they're cancerous. You are free to use HTTP and HTML, which aren't part of this discussion, and I will never attempt to force you to use anything you don't want. Be happy.

Even if you don't understand why I expressed that, you and I don't have to have the exact same motivation for promoting Gopher.

1. HTTP/HTML are no worse for centralization than gopher and type 1 menus are. I scrolled up the thread and didn't see anything of the sort. Why, and what does Gopher bring to this, without having to add most of HTTP onto it?

2. Since I lacked space, to elaborate further, a blanket term for complexity; a bit of an exaggeration. Sorry for being unclear.

@calvin@h@ajroach42@urantherEncrypted relays for gopher are conceptually simple. What I'm writing doesn't require normal gopher servers to be modified, and only requires a couple lines to be added to a client to support it, using standard tools.

Onion routing for a simple stateless protocol like gopher comes down to nesting three randomly chosen relays. Again, a couple lines of code to implement, in theory.

@uranther@ajroach42@h@calvinI'm explicitly trying to avoid nonsense like DNS cert hierarchies, of course. Which is to say, poorly-designed and horribly insecure mistakes baked into the way we do encryption for HTTPS. We have the opportunity to avoid making the same mistakes, while keeping things as simple as possible.

I'm trying to avoid anything that takes more than ~200 lines of python total end to end.

1) A security layer for Gopher has nothing to do with HTML or HTTP. Nobody discussed HTML or HTTP in this thread, that's something that you introduced. A security layer doesn't change the basic Gopher protocol. In the case of using a onion router, gopher servers and clients could run unmodified.