File Systems: The Original Hypermedia
15 comments
·January 21, 2025groby_b
> This version of the web wouldn’t require users to learn advanced computer skills in order to participate.
The web doesn't require "advanced computer skills". (Unless you use non-flexbox CSS alignments ;) It is fairly trivial to create basic HTML files. SSG + MD have removed a lot of the remaining obstacles. Most web sites are structured files, just with a "compiler" and possibly a database to store the files.
But what they still do require is the ability to reason about structured data and its best configuration. And that is the truly hard problem, ever since Ted Nelson first talked about it.
It also requires us to reason about how to best make that data consumable for humans. It doesn't just magically "arise from the structure", as much as I wish it did. The web site is a clear example - the lack of understanding how humans consume info, and what helps/hinders, leads to odd boxes around each paragraph.
I still agree with the fundamental idea. The more structure we can encode in an easily graspable way, the easier it becomes to impose structure.
But even then, the fundamental advantage of the web over hierarchical file systems is the non-linearity. And yes, correct, hierarchies matter, but the fundamental point the article misses is that there isn't just _one_ hierarchy. Wikipedia is a great example here - it fundamentally cannot be expressed in a meaningful way as a tree, even though it has many hierarchies.
And hierarchies alone are insufficient. We've now learned, thoroughly I think, that hierarchical taxonomies always break down. If we're given to snark, Linnaeus took a good stab, he failed. In more practical terms, the emergence of "tags" has shown that we need a way to have non-hierarchical cross-cutting data.
I think for a discussion of the subject, there's value in separating a few topics:
* Presentation. The author is right, HTML made a grave mistake including that * Local representation. Again, agreement here, giving a file system structure that allows to infer meaning for later presentation is super helpful. (See point about SSG/MD) * Organization/Navigation: Any sufficiently complex set of data requires several separate overlaid structures to help humans navigate. * Human psychology: We're bad thinking about relation schemes beyond trees & grids. That means our organization schemes need to mirror them at least partially so we don't break our head. Corollary is that any sufficiently complex set of data needs searchability.
There's probably more. It's a topic that's been brewing in my head for a while, you're getting a very rough first draft, sorry :)
moritz
> You would create and manage content directly from the file explorer application, in the most natural way possible. This version of the web wouldn’t require users to learn advanced computer skills in order to participate.
My students at university (Gen Z) have no concept of the “file system”.
dialup_sounds
That's not even a generational thing. People have been (e.g.) saving everything to the desktop for as long as there have been desktops. "Managing files" has always been a subsidiary task to the things people wanted to use computers for.
pilgrim0
Inline, ordered multimedia is the backbone of all consumer information systems. So your students have internalized the the archetypal equivalent of file systems through a different vocabulary, such as tweet (for files) and threads (for directories)
xnx
A usable equivalent of the file system is sorely missing from the web. Every email address should come with a place to publically share files. It could be as easy as https://user@emaildomain.com/
Borg3
O really? It seems people forgot about userdir.path (or similar). So user can expose whatever he wants via: https://emaildomain.com/~user/
xnx
Exactly. This convention is virtually non existent on the web in 2025.
mongol
That is an http basic auth URL.
p_ing
I struggle to parse this with every paragraph surrounded by a border. It feels unnatural and extremely distracting.
To the author's take of using a file system as an interconnected 'web', we have networked file systems today, typically clustered though.
We've also had the _concept_ of a media-rich file system, like WinFS [as an overlay to NTFS], which was dead before it was alive due to the WWW.
Networking file systems is _complex_. All vendors would need to agree to a common export model on top of their preferred file systems. Or users would need a specialized partition/overlay developed just for this purpose.
FSes are great, but they're not fit for WWW. Without a control plane, they lack any tooling that makes the WWW better -- redirection, access control, programmatic execution of content (ASP.NET, PHP, CGI ...), etc.
Ultimately this would be a complex solution. Just like many don't simply "open up" their web server to any and all traffic to any and all content, a file system would need to be carefully partitioned the same.
The time for file systems as the vehicle for WWW content is long since past. We have better ways to do things, better caching mechanisms, better performance [through CDNs], better security mechanisms, and so on.
...not to mention, I certainly don't want to open my personal computer's file system up to the Internet.
There would have to be a big leap in evolution of file systems across all major operating systems for the author's dream to come true. I would certainly be excited to see it, but we're talking about allocating _talented_ developers to create a new file system and certainly an open source file system. Like many file systems, it would take years to become a trusted file system to host any content of value.
In the mean time, the author can always investigate WebDAV. Slower than dog shit, but it's available with every major web server.
mickael-kerjean
> WebDAV. Slower than dog shit, but it's available with every major web server.
You lost me there. WebDAV is nothing more than HTTP calls with some XML data with a slightly different syntax than the S3 API. There is no fundamental stuff in the spec that command the protocol to be "slower than dog shit" as a file transfer protocol. Please prove me wrong with another argument than: "the particular server implementation I tried was dog shit"
pilgrim0
Sorry for the poor experience with the current design, still experimenting.
I cannot disagree with you, you’re on point on everything when considering the file system as an OS component.
But if we entertain the thought of file system as a document model, or as a transactional data structure, it should come naturally that we can piggyback on the modern infrastructure, at the application level, to achieve the desired qualities.
This very website is an experiment on how this could be done. The main takeaway with my research is that we have much to gain if we leave presentation and layout concerns out of hypermedia documents, letting the client software decide on it, like we do with our editors and IDEs, choosing the theme and font we like, the information is the same no matter. To abandon the fetishism inherited from print media and to transact pure data is to make the web democratic. That’s precisely the recipe used by all social networks: standardized, systemic presentation of schematic payloads following a given ontological model. We need only to copy them with an open model
p_ing
> Sorry for the poor experience with the current design, still experimenting.
Never stop experimenting.
> file system as a document model, or as a transactional data structure, it should come naturally that we can piggyback on the modern infrastructure, at the application level, to achieve the desired qualities.
I'm having a little difficulty groking what you're trying to say, here. Can you explain it like I'm stupid? My mind immediately bounced to SQL storing binary data or a document DB of some sort.
> if we leave presentation and layout concerns out of hypermedia documents, letting the client software decide on it
Every browser engine does this today. Every engine developer has their own idea of how a standard should be implemented. Granted, this isn't end-user choice, which is probably what you're after. Well, sorta, you have some customization of fonts and [link] colors.
> To abandon the fetishism inherited from print media and to transact pure data is to make the web democratic.
It sounds like you would like some simple scheme that provided you the text and binary data (images) of the website which allowed you to manipulate them into the "newspaper" layout of your choice. Am I getting that correct?
pilgrim0
You cannot fully leave presentation concerns out of browsers. Layout and decoration is an integral part of authoring, it’s supported at the markup level. HTML and friends are practically rendering instructions at this point, as if a PostScript for screens. Worse, this has a double edge, for instance, not always what should be a single paragraph of text comes as a single <p> tag, because the mere availability of styling leads people to author ad-hoc structures, since they know it could always be visually reconciled.
What I’m proposing with the research is a data structure transmitted as text. This text payload is the equivalent of a file system volume or tree. Each line in this payload is the equivalent of a file. It’s only a semiotic analogy to file systems.
Given this is such a trivial structure, it’s easy to develop multiple rendering approaches that maintain an isomorphism between the text representation and graphical representation. It does not transmit layout information, the syntax itself is the higher-order layout.
You might wanna checkout the source of this article by appending index.fifo.txt to its URL.
pwg
> Sorry for the poor experience with the current design, still experimenting.
It also is simply a blank page when browsed with UBlockOrigin blocking all the java script from executing.
> if we always had hypermedia with directories and files, why hasn't the web evolved into a mesh of interconnected file systems?
It kind of has. URLs have the notion of paths, which are obviously strongly associated with the notion of file system hierarchies. People sometimes (sometimes accidentally) put their file systems directly on the web, see DirectoryIndex in apache for example.
> Why isn't a website just a remote directory on someone's computer that we can explore via a file browser?
Well now we are getting into the meat of it. To be a hypermedia requires the presence of hypermedia controls in a media. Hypermedia controls can be as simple as links, but the web introduced more sophisticated controls such as forms, and allowed HTML authors to specify more significant interactions beyond click-to-link.
IMO the uniform interface is the most interesting aspect of hypermedia, and that really emerged post Web. I like the authors concept of a file explorer enhanced with hypermedia ideas though and would be interested to see more details on it.