Web of Documents (2019)
blog.danieljanus.pl
blog.danieljanus.pl
The main focus is the content of the document and the other content it leads to. Not the style, the features, the tech that it uses to load the content. I compare it to books. Most books are the same, predictable. They will have text and some images on pages. When turning a page it will show another page. It wont suddenly ask you to log in or go buy another book in the middle of this one. The covers of the books are slightly different but the basic function is the same. That's it.
Images that don't have width and height attributes always did that. Not adding those attributes to an img tag was considered a sign of a poorly made website in the very early 2000s. I think it might have been the origin of the term "layout thrashing".
Feels like such a step backward
Kind of like when I go for a walk in a forest that I haven't been to. A forest with many possible paths.
Whenever I hit a fork or a junction, I go to the places that seem most interesting. I say to myself: "Oooh it looks like there's a cozy lake over there", or "over there, there's a little river that I can jump over, or play with creating a temporary dam".
If I get lost I can walk back (click the back button) and change my choices, or decide to just walk the same way back/go home (stop reading).
4. Every document is version controlled
That way, as Daniel puts it, "[the document] will not magically alter its contents tomorrow". Or if it does, I can see a history of what was altered. Ideally, this would somehow be built into the protocol/browser rather than be a burden to the publisher.
Also, maybe after a certain amount of time I can no longer modify my document. If I'm the New York Times, this means when I publish a news article document, and it contains an advertisement, that same advertisement forever lives on that document - just like physical newspaper.
Articles and documentation need version control and with pull requests and issues you can rely on other people to notice when some stuff is out of date or inaccurate. The version control allows to see what has been changed over the years, it also prevents censoring.
Source Hut (https://sourcehut.org/) does it very well in my opinion
That said, I agree with the author and discussed the topic with friends for years.
On the "do you practice what you advocate?" side, my freelancer company website is, since day one 8 years ago, a totally static (no script, no cookie... except the one my hosting provider added without letting me options, I will quit them some day) collection of documents with readable stable URLs. https://fidergo.fr/ And the smaller English language https://fidergo.com/
The part detailing dozens of software projects is generated in advance from a structured data store into static pages uploaded to server. https://fidergo.fr/expertise
Version-controlled, scripted deployment.
Safe for me to serve, safe for you to browse and read.
That is the web of documents.
Author here. The article has not been edited since it was originally published. I agree that version control is an important topic, and I applaud efforts such as IPFS; it is, however, tangential to the main point of "documents vs applications" that I was trying to make.
Sure, I do that with my websites too, and I monetize none of them. (I do use cookies because some of my sites require logging in for access control.)
However, you and me can afford to do that because our livelihoods don't depend on revenue directly from page views. There is this subset of the web that is already just a web of documents, because we can afford to keep them this way.
But what about people whose livelihoods do depend on revenue from page views, and page views alone? It's very frustrating when people who can afford to not do X talk about X without even acknowledging people who can't.
I do encourage you to stay on this site longer before you start throwing straw man analogies at other users demanding that they change where and how they would like to comment.
I am curious how you consider "do realize that [...]" to be an argument, let alone a counterargument.
I think you're misreading gp, they want to add version control to the requirements, they're not discussing an earlier version of op that had it.
From the article: > A book is a document, to me
How can versioning work for the above statement? Will there be a new book or we modify the existing book?
I'm not making HTTP requests here, but, to your point, I am mutating the document at that url.
Maybe the protocol would somehow store the diff between those 2 documents somewhere. There could be an organization, similarly structured to ICANN, that stored and surfaced those diffs long term to users.
Having Javascript enables amazing things like interactive documents. For example I would consider [1] a document, despite the fact that there is Javascript running. What a wonderful way to interact with and get a better understanding of a Voronoi diagram! Or how about the wonderful interactive demonstrations of graph searches at [2]? To me, things like this are part of what makes the web platform fantastic.
Earlier in the article, the author writes:
"A document is stateless. It exists in and of itself; it is its own microcosm. It may be experienced interactively, but only insofar as it enables the experiencer to focus their attention on the part of their own choosing; the potential state of that interaction is external to the document, not part of itself."
I think that the two interactive javascript-powered articles I linked comply with this. Ruling out scripts entirely is too heavy-handed - perhaps a nice middle ground can be found somewhere.
[1]: https://strongriley.github.io/d3/ex/voronoi.html
[2]: https://www.redblobgames.com/pathfinding/a-star/introduction...
1. HTTP/1.1 is valuable. With the move to HTTP/2, we lost the principle of "simple things should be simple, complex things should be possible" (Alan Kay). All things in HTTP/2 are complex. I can make an HTTP/1.1 client on the command line with netcat.
2. Serving documents is incredibly simple[2] and safe (once you handle path vulnerabilities :D ).
3. We should extract web browsers from the behemoth JavaScript VMs we're all running now. I'm all for having portable VMs, and I like the direction WebAssembly is headed, but probably 80% of what I do on the web could be accomplished using an order of magnitude simpler software, accessing read-only documents.
4. Markdown and other human-readable formats are awesome. I used to think writing my blog in HTML had the least dependencies, but now I realize it makes you depend on a browser to render it, and that's a huge dependency. Markdown can be read as-is and therefore is almost dependency-free.
So I agree with the author here, and this is how I think we get there. Someone should make a stripped down web browser with the following attributes, or something similar:
1. Only speaks HTTPS
2. Only GET requests
3. A few choice headers, like Range for streaming video.
4. No JavaScript, or any Turing complete language at all.
5. Minimal CSS, ie colors, font sizes, flexbox. No animations (you don't have a language to trigger them with anyway).
6. Can probably throw away some HTML elements as well.
The nice thing about this approach is that sites made to work with this browser will still work in normal browsers. They'll just be super fast, low on resources, secure, and private.
[0] https://anderspitman.net/17/#curlable
Fortunately, we haven't lost anything yet on that front as HTTP 1.1 is still supported by practically all servers and clients.
https://gopher.floodgap.com/gopher/gw
And a search engine:
https://gopher.floodgap.com/gopher/gw?=gopher.floodgap.com+7...
What if we just released a new browser that flat out refused to load any resource outside this definition?
Would sort of be like the parallel worlds of gopher and the web for a while. I think it would be interesting to have a "web fork" that was just for documents not apps.
Ultimately, there's nothing that says a saner web couldn't exist side-by-side with the modern one. We don't have to fork the browser, we just need to create a subgraph in the larger link network - a connected, searchable subgraph of sites that are document-oriented, machine-readable, that don't track or abuse you. A search engine limited to a certain criteria and perhaps some amount of curation would work as a way to define this subgraph.
No, this won't solve the web problem for everyone, but I think this is too tall a goal to have. Instead of trying to fix everything for the world at large, I feel we should be creating our own better subspace, and slowly let those who care come over.
- specify a strict subset of html and css (no scripts, or maybe a set of well-known scripts for things like autocomplete etc, avoiding layouts that are known to be problematic)
- add a meta tag or something to indicate that the browser should attempt to read this page based on these rules.
- fall back if the page doesn't follow the spec exactly.
I guess this could result in lightening fast pages. Now get one or two organizations on board (Wikipedia? Other non-profits? etc.) and suddenly people will notice.
This seems kind of like XHTML. No one liked that because people preferred having a webpage fail gracefully and still display something, rather than throw an error (ironically, the "worse" solution of non-strict HTML in that case making the web act more like documents than applications, because sloppily written documents are still readable.)
Many applications are already being developed to create this new Web3.0 document-centric world (I'm creating one of them!) which will provide a "way" to have the original Tim Berners Lee web once again be possible.
...and not only that but it'll also be decentralized and 'uncensorable'!
It only appears uncensorable because it's not (yet?) popular enough for states to care about it.
And for blockchains to be uncensorable, you need the content to be on-chain, which doesn't scale. (because, if the content is off-chain, then you need an external solution to host the content, so the blockchain didn't solve the problem)
Meanwhile, if I want to make a blacklisted doc 'available again' all I'd have to do is add one bit or byte to the end of it, and the hash would change completely.
Right now one single person at one single tech company (like a Twitter employee) can literally ban someone for life, for perfectly legit political speech.
IPFS is the best-in-class effort to solve all that, and I'm actually a guy building a node that will go on the IPFS network.
No, it only has to take down servers hosting its content.
> all I'd have to do is add one bit or byte to the end of it, and the hash would change completely.
This is unrelated to my point, but a nitpick: IPFS uses a rolling/chunking hash, so one could blacklist chunks of a file; so it's not as easy as adding a byte at the end.
2) Regarding chunking in IPFS, the fact that files are chunked actually increases the burden on any authority attempting to implement a blacklist of hashes, and so that's in agreement with my points.
Also if someone truly wants to fight censorship you'd just symmetric encrypt the data using a publicly available key so that it DOES change all hashes of ALL chunks every time you encrypt with a different key.
And encrypting the same data under many different keys (creating different copies of whole file, is also my proposed solution to the problem of "Proof of Replication" in the IPFS system.)
Is it full of insane people blogs and illegal pornography like all the other technologies with these characteristics?
I can view wiki, yc, and even some news websites. I can search through google, but can't use my account. Of course FB, LinkedIn also doesn't work. And I also can't login to HN and consequently can't leave a comment here.
It rises a question: is it possible to decouple our personalization needs from Web of Application to get properly working and convenient Web of Documents? Or it will be like a huge library of everything?
For that matter, where does HN fall on the spectrum? It's not as "application'y" as some sites, but it's certainly not a static document either.
Although the definition in the article would seem to be that "documents" are static, non-interactive (excluding even forms and possibly any kind of server-side rendering), non-scriptable HTML pages which simulate paper documents as much as possible, with perhaps the sole exception of allowing hypertext, and "applications" are everything else.
If so, that seems far more restrictive than even the web in its infancy, at least at the point where most people became aware of it.
Opens Dev tools, views <head> tags, and "Source" tab looking for javascript
Nothing there. Well done, author. All too often I read articles like this on Medium and laugh at the authors perpetuating the problem they want to solve. I love clean, well styled, beautiful looking static blogs. I'll have to start one someday.
Encouraging better design and graceful decay didn't work, because it was too easy not to care.
If you want good design to be the majority, it must be the path of least resistance.
The key observation, that generalizes to a lot of societal woes: can be used doesn't mean will be used. Asking people for restraint doesn't work in general, and doubly so in a competitive environment. That's why asking for restraint generally never works, you can either take away the toys (a quick fix) or find a way to force restraint on people.
You mean like scroll-jacking? Some script that prevents me from copying and pasting? Something that loads images later for some reason and shifts everything around?
I don’t mean to be facetious, I am genuinely curious what you mean. In my experience JS has been nothing but a detriment (for reading documents, that is), and I have it disabled on all of my computers.
If the enrichment rules are known ahead of time, there is no reason you can't just "hard code" the colors or formats into the document.
The one and only place where I want dynamic syntax highlighting is on "pages" where content might change, such as in-browser code interpreters. This kind of thing can't be done with static syntax highlighting: https://play.rust-lang.org/
Sure, I get it, that's a problem, but it's not a _document_ problem. The web of applications let you _actually do stuff_. Yeah sure there's a ton of crap, but cherry picking only the news sites as a reason to remove PUT requests seems like the total wrong approach.
Us. All of us. All hail mesh networks.
> A document is safe. A book is safe: it will not explode in your hands, it will not magically alter its contents tomorrow, and if it happens to be illegal to possess, it will not call the authorities to denounce you. You can implicitly trust a document by virtue of it being one. An application, not so much...
- Sets of proposed features vary (happens to both lightweight WWW and modernized Gopher proposals). I guess a more viable approach may be a less strict one than composing such a set. For instance, a search engine for such websites was mentioned in another comment here, and I keep thinking about a web directory for that, but perhaps either of those would be more useful if it was able to detect (and filter by) features required by a website, rather than a single flag saying whether it's usable with a particular set of features.
- Occasionally it's suggested (in this case both in the article and in the comments) that browsers only supporting documents would help somehow. Yet there's a bunch of lightweight web browsers (even I wrote a couple), as well as combinations such as FF+noscript+uBO+Stylus, which may be nicer to use, but don't seem to affect the overall situation beyond "please enable JS" and "best viewed in IE6" messages.
I think the new Web3.0, and blockchains, and IPFS are going to lead to a new web that is more like it was in the old days where people were sharing actual documents.
I'm the creator of 'quantizr.com', which also fully adheres to your sentiments, but also a belief that documents themselves should be granular (i.e. quantized).
The IPFS 'interpretation' of my quantizr concept would be something like saying a 'document' can have a version stored on IPFS that is a specific immutable copy.
Yes! It's 'SaaSS' - as defined by Stallman, not 'SaaS'.
"On the Internet, proprietary software isn't the only way to lose your freedom. Service as a Software Substitute, or SaaSS, is another way to give someone else power over your computing.
The basic point is, you can have control over a program someone else wrote (if it's free), but you can never have control over a service someone else runs, so never use a service where in principle a program would do.
SaaSS means using a service implemented by someone else as a substitute for running your copy of a program. The term is ours; articles and ads won't use it, and they won't tell you whether a service is SaaSS. Instead they will probably use the vague and distracting term “cloud”, which lumps SaaSS together with various other practices, some abusive and some ok. With the explanation and examples in this page, you can tell whether a service is SaaSS."
Source: https://www.gnu.org/philosophy/who-does-that-server-really-s...
The problem the author has is not a technology problem, it is that sites restricted to just such documents are not especially popular with most users.
People who wish that interactivity etc had never been added to HTML are misguided. (I'm not sure if the author falls into that category.) HTML competed with other technologies (e.g. Flash, ActiveX, native apps); when authors felt overconstrained by HTML they used those instead. If interactive apps were all Flash and ActiveX and native today, and Web apps didn't exist, would that be a better world? Certainly the Linux desktop would be far less usable.
In this baking example, there are three pieces of the puzzle. Recipe source, configuration endpoint, and the brain in the middle that uses one to work on the other. I want that brain part to be independent - but you can easily see how the recipe site and the machine vendors would each like to own the brain part exclusively. That's why we can't have nice things on the Internet - nobody can accept their role as a service provider, everyone wants to be a platform, the landowner of their digital sharecrop.
I however want both "apps" and semantic "documents". Launching an app by typing an URL is powerful. And on Android you can now add an web app to the home screen.
We might not want the recipe to have the same capabilities as the "app". Maybe the apps should be closer to the OS, and "documents" opened in a reader app (browser).
One problem with the "semantic web" is that the added markup feel alien and too verbose. It was designed to be used with web page builder apps. But I and many others still prefer to code the HTML manually, with the help of a powerful editor (with autocomplete and macros). "Structured data" gets too hard to read by source. An idea is to replace the many span and div elements with actual semantic elements.
In another post I ranted that nothing had really changed for "documents" on the web in the last 20 years. We are practically standing still, without any innovation. Probably due to browsers being overly complex and hard to develop. I think the time is ripe for a "document only" web browser, and we can start innovating again! For example, the enterpise market is still using word documents, some use alternatives like Google docs. But web "documents" would be far more powerful. Instead of e-mailing files, you should just share a URL.
I'm currently working on an Editor for making web documents (but also for making web apps). I've put a lot of thoughts to how enterprise can use my editor to make web documents instead of word files and PDF's. Almost everyone are using the web today, but very few people actually make web "documents".
No, it doesn't. It only breaks down when people use the web as a sole and direct means of making money. I.e. baiting people to view ads.
Any normal company that does business over the Internet uses the web to present their offering and drive purchases. The web part is funded by proceeds from their actual business. This is entirely compatible with the "web of documents".
Regarding producing the documents, the author mentions Xanadu as inspiration, and in the linked wikipedia article we find rule 9: "Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies ("transclusions") of all or part of the document.". So the idea for a mechanism to allow payments was foreseen. I guess there can also be advertisements, only not personalised.
(Edited the Xanadu rule cited)
Advertisers find general magazines and TV still interesting enough, without any personalization.
The question is: How do we equitably allow everyone to pay for their OWN storage in a way that doesn't involve selling ADs or selling people's 'information', the way the current Big Tech monopolies do.
Disk space is ridiculously cheap nowadays. I can buy enough space to store everything you ever typed in your entire life for $10. So I hope IPFS+FileCoin is successful, and you should to!
People create content in order to make money, not to pay for their own storage. However cheap disk space is it's a cost, not revenue (btw, setting aside disk space, bandwidth is nothing but cheap with cloud providers, and nor is business or home bandwidth depending on the definition of cheap). You're shifting the goalpost.
I mean think of it, you've posted 10000s of things onto the web but you've sold NONE of it right?
What I'm advocating for is a way to eliminate the current situation of middle-men in the process (Big Tech firms), because they have a long and proven tack record of manipulating and censoring search results and social media feeds, etc. and banning people for life even.
Not only am I advocating for the Web3.0 (as it's called), I'm helping to build it.
I’m not much of a designer so I just reused a color scheme I liked that I found on ColourLovers.
First class support for Google Docs/Sheets/Slides style creation, with a clean default read mode would be perfect. An open web born out of Libreoffice rather than out of Blink/WebKit/Gecko. Secure, federated document access with easy long term caching/archival of static versions.
I do not see documents and applications as two separate things. I think an application is the inevitable next step towards our goal of disseminating information as efficiently as possible. That's why it's called hypertext - it's meant to be a better version of plain text documents.
The author's biggest complaint is "applications pretending to be documents," such as journalism sites that implement monthly article caps. Sure, but in the old days you had to pay for the newspaper too, didn't you? Paywalls are not a result of the "Web of Applications" as much as they are a corporate attempt to adapt to a new medium. Nobody will publish documents for free unless it is a hobby or passion; in order for there to be worthwhile documents churned out every week or so, someone has to get paid. The author seems to presume that news orgs would simply publish their documents for free if the Web only enabled GET requests. I have extreme doubts about this.
Web3.0, IPFS, blockchain, etc. are what will end the 'non-document-capable' web that we all seem to now be experiencing.
For example if you go to someone's blog, it's on some site, and if that site goes away, that document is gone forever. That's the problem. We need an internet that is more like a massive public blockchain than a small number of monopoly sites trying to feed you enough stuff to collect information to sell about you.
I think a version controlled web would be sweet, like git internet.
Publishing a page ultimately creates a commit hash. Removal of published commits is not a thing. Only forward changes. Mess something up? New commit.
When referencing a page from another, a commit hash can be specified if desired, however, linking to a page/accessing a page without a commit hash resolves the most current (think master branch) page/commit hash.
When accessing a page in browser, you should have the ability to rollback to a previous version of a page if so desired. Since all dynamic content and linked-out content is based on commits hashes (resolved at time of publish), you now have a way to receive all content you did before.
I like the idea of a static HTML/CSS only idea for pages and ditching JS mostly due to what crap the web has become filled with, like author mentions, paywalls and tracking.
At the same time, I think all can be accomplished without dynamic scripting as long as pages are hosted privately (as things like server logs can be inspected) and websites are able to set/retrieve session storage on client-side. Not sure how to solve for that.
I always land on the whole thing being decentralized and everyone participating holds many pieces like bittorrent where there is hash authenticity. The hashing to client lookup could be authority type servers (like cert authorities/trusted tor nodes) as trackers. The problem with this is nobody wants to have crap stored on their computer to use the internet.
Private, trusted nodes seem to me to be the better option, but they would need to be locked down like a root certificate authority. No logs either. Just multi-redundant, multi-region, eventually consistent, nodes adhering to some protocol used for passing around (in essence) a huge scalable, partitioned git repo.
Also this might be complete crazy talk, but that's okay. It's a much better dream than a world where the internet has become full of paywalls and tracking.