I’m old enough to have used gopher on vt100 terminals as an undergrad in college to try and do some ‘work’. And when http/www arrived, it didn’t take long to switch to a better mousetrap. And this wasn’t just because you could now render a gif in NCSA Mosaic on indigo workstation. Everything was just better in this new http world.
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].
If the desire is to make online content more readable, it might be worth starting with the assumption that all content downloaded from the network will be read on a black-and-white ereader device with no persistent internet connection.
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.
Your idea of hypermedia with an offline browsing assumption is very good! Imagine an "offline archive" format that contains a document D + a pre-downloaded copy of all referred documents R1, R2, ..., Rn, along with necessary assets to render R1,R2..Rn in some useful manner (e.g. save html + main-narrative images from each page Ri, but skip everything else).
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.
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
> Essentially, "just pass me the bare minimum of response to make Firefox Reader View work."
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.
No, because that is not realistic for the exact reason you mention — that would break a lot of sites. Probably the vast majority even.
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 solution is to stop respecting the style tag and enforce sane defaults that the user has control over. The Web was meant to be a means of creating academic documents with fancy citations in a tree structure, not a glossy magazine delivery mechanism.
>just pass me the bare minimum of response to make Firefox Reader View work.
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.
I don't think the issue is the tools available but the motivation behind their use. Until we get rid of the ad revenue model we'll be stuck with user profiling and tracking. Micropayments or some other model will have to take it's place before we see a return to the ideals we used to aspire to.
If there's support for embedded assets (you mention videos, so I assume also images, etc), how do you prevent "tracking pixels" that can monitor what content is viewed per IP address?
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.
Content addressing can help here. If every asset is identified by a cryptographic hash, the user agent is free to fetch it from any available source. In the case of images, you can hash over the rendered pixels instead of the file encoding, so all transparent 1x1 images are concise red interchangeable.
Alternatively/in addition, the user agent can treat embedded assets like textbooks do, and present them all as numbered, boxed, and captioned figures.
>render a gif in NCSA Mosaic on indigo workstation
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...
I recall those times too, however I switched back to gopher because the web was click-click-crash if you were running windows or on the college unix workstations, it was click-click-hang.
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].
[0] https://en.m.wikipedia.org/wiki/HTTP/3