Need a lightweight hackable #gopher client in python with a curses interface?
I've got you covered: https://github.com/enkiv2/misc/blob/master/ncgopher.py
(It doesn't support fetching stuff from protocols other than gopher and it assumes everything that isn't a menu is plain text, but whatever.)
The fediverse attracts technically-inclined people who are frustrated with the status quo, though -- so lots of discussion about gopher, IPFS, xanadu, and other 'alternate computer universes'.
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!
Do you have a hashtag or community name of the effort? I know #indieweb and #decentralizedwebsummit and https://github.com/redecentralize/alternative-internet
For me, it's all about taking back what little control I can in media distribution.
The modern web is insecure, and not ideologically aligned with my interests anymore.
I will embrace indie web stuff, but even the browsers (in the face of EME) are out to get us. So Gopher.
Gopher is clear text over the NSA's internet.
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.
Same as the security argument.
@h @ajroach42 @uranther @jaycie
Agreed. 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 @h
On 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 @uranther
If 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 I've been poking gopher for a while, but with a lot of the new talk about it, a lot of it is just adding extra protocols on top to increase complexity and ultimately bring it up to the point of "why not HTTP?" instead of some relic of a simpler time.
if you want to fight the modern web, putting go-faster stripes on gopher is not the way; you're better off serving better content on HTTP and rejecting the web for apps, and embrace the web for documents.
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.
Gopher is very extensible in terms of supported link types -- clients ignore unsupported link types, and if there's a type collision then a client that interprets it differently merely fails to follow the link. Back during its heyday, there were lots of non-standard links, and nobody expected their client to support all of them.
So, adding another nonstandard one is fine.
@uranther @ajroach42 @h @calvin
As for onion routing -- well, conceptually that's pretty straightforward, and doesn't really require screwing around with the protocol much (see https://niu.moe/@enkiv2/99107149067254367).
I mean, I'm having a little trouble with my implementation right now, but that's just because I'm not up to speed on how to use openssl.
We can't bring 1990 back. Sorry.
If you don't understand that security concerns are a reality of life in 2017, and not a bogus new protocol, then it's pointless to discuss anything else.
Also, nobody discussed blockchains here, you are confused or don't actually understand what we're trying to discuss here.
@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.
2) A blanket blockchain thing.... Okay 🙃
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 @uranther
Encrypted 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.
Some people want their gopher traffic encrypted. I'm obliging.
@uranther @ajroach42 @h @calvin
I'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.