Let’s fast forward to today, yes, we’ve gone overboard all over, but then again, Gopher [i think] doesn’t come standard with TLS, it hasn’t gone through the evolution that http[s] has that makes it a robust and scalable backbone it is today.
What I’m trying to say is that we should not casually float around pipe dreams about switching to ancient tech that wasn’t that good to begin with. Yes, electric cars were a thing already in early 1900s, and we maybe took a wrong turn with combustion engine, but with Gopher, I think we should let the sleeping dogs lie, and focus on improving next version of QUIC, or even inventing something entirely new that would address many of the concerns in the article without sacrificing years of innovation since we abandoned Gopher. Heck, this new thing might as well run on TCP/70, never mind UDP appears to be the thing now[0].
A lightweight HTTP/TLS subset that severely limits client-side execution expectations would seem to accomplish the same goals.
While repurposing all the amazing tech we've built since the 1990s.
Essentially, "just pass me the bare minimum of response to make Firefox Reader View work."
... but then we wouldn't be able to serve high-value targeted ads, would we?
This assumption might require substantially reworking the hyperlink model of the internet, so that external references to content delivered by third-parties is sharply distinguished from internal references to other pages within the same work.
This "offline archive format" has numerous benefits: (A) Cognitive benefits of a limited/standard UI for information (e.g. "read on a black-and-white ereader device"), (B) Accessibility: standardizing on text would make life easier for people using screen readers, (C) Performance (since accessing everything on localhost), (D) async access (reaching the "edge" of the subgraph of the internet you have pre-downloaded on your localnet could be recorded and queued up for async retrieval by "opportunistic means", e.g., next time you connect to free wifi somewhere you retrieve the content and resolve those queued "HTTP promises", (E) cognitive benefits of staying on task when doing research (read the actual paper you wanted to read, instead of getting lost reading the references, and the references's references).
I'm not sure what "standard" for offline media (A) would should target... Do we allow video or not? On the one hand video has great usefulness as communication medium on the other it's very passive medium, often associated with entertainment rather than information. Hard choice if you ask me.
I'm sure such "pre-fetched HTTP" exists already of some sort, no? Or is it just not that useful if you only have "one hop" in the graph? How hard would it be to crawl/scrape 2 hops? 3 hops? I think we could have pretty good offline internet experience with a few hops. For me personally, I think async interactions with the internet limited to 3 hops would improve my focus—I'm thinking of hckrnews crawled + 3 hops of web content linked, a clone of any github repo encountered (if <10MB), and maybe doi links resolved to actual paper from sci-hub. Having access to this would be 80%+ of the daily "internet value" delivered for me, and more importantly allow me to cutoff from the useless information like news and youtube entertainment.
update: found WARC https://en.wikipedia.org/wiki/Web_ARChive http://archive-access.sourceforge.net/warc/warc_file_format-...
How many links from any given page are ever taken? And is it worth network capacity and storage to cache any given one?
https://old.reddit.com/r/dredmorbius/comments/6bgowu/what_if...
Plan 9 OS and the 9P protocol
I'm carving out a subsection for this, as the concept appears to contain a number of the elements (though not all of them) mentioned above. See Wikpedia's 9P (protocol) entry for more:
In particular, 9P supports Plan 9 applications through file servers:
acme: a text editor/development environment
rio: the Plan 9 windowing system
plumber: interprocess communication
ftpfs: an FTP client which presents the files and directories on a remote FTP server in the local namespace
wikifs: a wiki editing tool which presents a remote wiki as files in the local namespace
webfs: a file server that retrieves data from URLs and presents the contents and details of responses as files in the local namespace
https://old.reddit.com/r/dredmorbius/comments/6bgowu/what_if...
What would that constraint look like? Is animation and interaction prohibited there, for example?
The lesson from the modern web being, if you give web developers a toolbox, they'll figure out how to build a surveillance system.
And for decades we've been creating more powerful tools (Flash/ActionScript, ActiveX, JavaScript, Wasm, etc).
The answer would seem to be that we should be far more careful what tools we allow to be used.
(Note: Not saying restrict all the web this way, but if one wanted to build parent article's wikipedia-esque info web)
If we allow all those, it's just the modern web again.
I think it's generally useful to look at email here, where only a small subset of html—primarily photos + text—are reliably supported across clients.
No third party connections allowed. As for the originating server, they already know you requested the page, no?
Alternatively/in addition, the user agent can treat embedded assets like textbooks do, and present them all as numbered, boxed, and captioned figures.
I never understood why people have a problem with normal contrast. Low contrast is hard to read.
I wish it was possible to use a html meta tag to declare to the user-agent that it should show the content in reader view.
Then sites that only want to provide text and images and no ads etc could be implemented without any CSS at all and minimal amounts of markup and still be nice and readable on all devices thanks to user-agent reader view taking care of the presentation.
And I don’t see any real benefit in changing the defaults either. Most sites want to provide custom CSS. The point of reader view is to make simple articles consisting of text and images comfortable to read on your specific device. Device/resolution specific defaults would be at least as painful, and probably more painful, to override for every site that wants to use custom CSS.
Whereas an explicit meta tag telling the user-agent to use reader view is entirely feasible. Such a meta tag does not interfere with existing pages, requires nothing extra from sites that don’t want it, and would still fall back to something that works for all end-users whose user-agents don’t implement it (because browsers ignore meta tags they don’t understand so those browsers would render the page in the exact same way they would any unstyled page). And on top of that this theoretical meta tag would be really easy for browser vendors to implement — they parse the HTML, see the meta tag and trigger the reader view mode that they have already implemented.
The vast teeming hordes of Kardashian fans and youtube addicts would not. They like where we are now.
Couldn't an HTTP proxy work here? Something you run on localhost that fetches web pages, stripping them of trackers, adverts, and other undesirable stuff? Perhaps with enough development, it could even selectively strip CSS and JavaScript -- eg. it would be really nice if websites stopped shipping scrollbar hijacking / custom scrollbar code.
You know what I would love to see is a comparison chart for all Historic SGI machines, and their MSRP from their heyday to comparable compute capabilities in modern devices.
I remember when we were moving ILM/Lucas to the Presidio - and they were throwing our massive SGI machines, which were hundreds of thousands at the time - but some of them were turned into kegerators...
A parallel protocol and hypermedia format that's restricted enough to prevent tracking isn't going to attract everyone. It's going to attract the subset of users who care enough about stuff privacy to give up "rich Web" features like single page applications and animated HTML canvas elements in return.
That's not a group that's likely to start immediately demanding to to build in the features needed to create infiniscrolling Pinterest feeds. And it's also going to be a much restricted group, meaning businesses won't stand to profit much by pushing for it. So there might not be any economic incentive to do it.
At least, that's how it might be at first. If it remains a nice place to be for 5 years, I'd call it a decent run. 10, and I'd be ecstatic.
I yearn for a future where knowledge is distributed in a practical, organizied way such as via Gopher or similar, along with tapping the full potential of email as a one-to-many, many-to-many, and many-to-one communications medium where data is distributed and address ownership is maintained.
We already have that, it's called the World Wide Web.
You seem to be under the impression that the popularity of the web is due to centralization by and commercialization by corporate interests, but that isn't the case. It's still entirely feasible to distribute knowledge in a "practical, organized way" using HTML and HTTP, and people do use it for things besides the three social media sites people now mistakenly believe comprise the entire web.
I'd start nearly any session with Gopher, and it would end in either some web pages or an FTP server. Gopher was the go-to because it was organised unlike the rat's nest of links you had to deal with on the web.
This wasn't really fixed until the advent of big centralised search engines (and even then, the early ones weren't worth damn).
The modern web cannot do that.
(I’m not convinced gopher can either — I think NNTP was actually better at that — but like the thought experiment.)
It'd be nice to have a quieter place like old gopher, but yeah the real increase in privacy it would bring is somewhat illusory.
What do users get in the end ? half of the web is still tracking them. And many of the big guys still track them.
Not enough if you ask me. That's what makes it so difficult.
So let's solve that: let's build a search engine that let me filter sites according to privacy, Ah and be perceived as good as google - because in today's world, in many jobs, you cannot give up on an information advantage.
That's kind of an impossible mission.
https://duck.co/help/desktop/adding-duckduckgo-to-your-brows...
Gopher is an alternative to HTTP, not HTML. HTML can be used with gopher, and since documents served via gopher can be accessed by URLs, it's hypermedia features are usable over gopher. (But gopher is read only, unlike HTTP, so even with JS—since even though it uses URLs, HTML’s built-in form behavior presupposes HTTP and it's verbs—to do a gopher call for a form you'd only get the equivalent of GET forms.)
In principal at least; other than Lynx and an extension for Firefox, I don't think any current browser has support for Gopher, anyway.
> If you somehow managed to pull enough users to Gopher, they'd just write Gopher Chrome and start adding new features that conveniently allow tracking into it
You can do IP based tracking on any TCP/IP protocol, and if the clients have JS (or other scripting, but if you make it alternate channel for HTML, JS is the obvious choice) support and aren't a monoculture, and have differences detectable with JS, you can do client fingerprinting on top of that. Yes, even with gopher protocol alone, as long as your server can treat certain crafted requests specially.
Alright, let's talk to our representatives and ask them to consider taxing tracking and data collection.
But then again, the harm of advertising and surveillance capitalism is a thing. So is the focus on data hoarding, vendor lock-in, favoring prettiness over utility.
I really wish we could run a parallel web. One optimized for utility, where data and content is available in maximally useful form, where users are in control of their rendering, and are free to use whatever automation they want. Not a replacement web, just a for people who are willing to jump through some hoops in order to avoid the crap that's on the mainsteram one.
I don't know much about Gopher yet (I'm starting to learn now), but maybe such a parallel web could be developed there?
And nobody uses it.
Freenet is a distributed content-addressed store, much like IPFS, except that rather than you directly fetching content from other users who have specifically "pinned" that content (outing you both as interested in the material), the request hops over multiple users, leaving it cached (in an encrypted form, for plausible deniability) over their machines, so that it's very hard to tell who actually requested it.
usenet was also great until spam went nuts.
FB for example is US-based company. Last time I checked you are not forced to accept outside money, get VC rounds or go IPO.
Mark chosen to go the "American path" that is capitalism to the maximum so of course I will lose an argument over why he is trying to maximize profits. But nothing stopped him from building sponsorship agreements with i.e. fortune 500 corps, instead of building bidding platform ala Google.
I'm pretty sure if you would signup fortune 500 and have for example 500 rotating banners, it would give you enough founds to run operations and pay every employee $150,000 salary. Plus having exactly ZERO tracking cookies and ZERO malicious following you JS script. Its quite possible given FB size and reach, but again "this is America, this is business."