Files, links, and the thing we stopped noticing: publishing
Take apart what "build a website" means today and you usually get a long list: pick a framework, attach a database, handle identity, set up deployment, configure a domain, add analytics, deal with caching, decide how search engines will read the content. The list is not absurd. It just makes it easy to forget that the first problem is a small one. I have a piece of content. How do other people reliably read it?
The early web's answer was close to plain. A document has an address, addresses can link to each other, a server exposes certain resources over HTTP, and a browser can read them. The 1989 proposal and the first browser/editor and server implementations in 1990 were not built to give everyone a personal home page. But the model produced a social consequence that mattered: publishing did not have to begin as an application development project.
HTML is part of that consequence. Early HTML was an application of SGML, yet it handed authors a much smaller document language for organising headings, paragraphs, links and media. The web did not spread because of HTML alone, and graphical browsers, cross-platform software and open implementations mattered just as much. What HTML gave people was an intuition they could act on: write what you want to say as readable structure, then give it an address others can reach.
Directories were never the essence of the web, but they left the right instinct
Many people first felt that directness through personal-directory publishing on Unix and Apache. Apache's UserDir can map a URL like ~alice to a directory of Alice's, conventionally public_html. macOS once had Personal Web Sharing, which let a user's Sites directory be served by the built-in web server. These are not the same technology, and neither one hands every person a public website automatically. Server configuration, network conditions and security policy were all still there.
Picture it concretely. On a shared Unix host with UserDir already configured, a student, researcher or employee has a shell account. They create public_html in their home directory, write an index.html, and drop in an image and a few links. Someone else receives an address like http://host/~alice/, and what opens in the browser is not a personal page inside some platform. It is the content Alice put in that space. It may be plain, perhaps only text, an image and a run of hyperlinks, but the relationship between author, resource and URL is visible at a glance. An administrator still has to enable the mapping, and the machine still has to be reachable from outside.
What matters about these conventions is not whether we should copy the directory names today. It is that they kept the author, the content and the publishing space close together. A user has content and a space first, then decides how to share it. In that model a site is primarily an organisation of resources, and the server just makes that organisation readable.
Today's usual mental model differs. An author often creates a platform account first, then writes inside the pages the platform allows. Or they initialise an application first, then wire the content into it. Both work, and both offer real convenience. But the first hands control of the relationship between identity and publishing space to a platform account, and the second turns publishing into a software delivery process. One changes the author's boundary of control over their space. The other loads unnecessary engineering onto something simple.
This is also why "bring the filesystem back to the web" is not an accurate description. Files by themselves do not solve search, versions, permissions, identity, structured data or interaction. A publishing system anyone can really use needs all of that. What the early directory model left behind is not an implementation. It is a better question: should those capabilities force every author to assemble them, or should they be part of a shared environment an author can call on?
From Gopher to home pages, the point is not which one was more advanced
Before the web reached a mass audience, Gopher was a significant way to navigate information on the internet. Put the two side by side and it is tempting to tell a simple story where a more advanced protocol replaced a less advanced one. The history does not support that single line. Different systems suited different situations, and the web spread through a combination of technical and social conditions.
The comparison is still worth keeping. An information network has to solve more than "where is the information." It also has to solve "who can naturally put information into it." Linked documents and browsers made presentation more intuitive, and personal home pages made publishing look like an everyday act. That instinct kept resurfacing, and the specific products and tools are covered later in this series and in the timeline reference.
When ARC talks about the Web Device, it does not need to enshrine any of those products as ancestors. Their shared meaning is a reminder that ordinary people's need for a publishing space never went away. What changed is that the surrounding capabilities required to publish something safely, reliably and professionally kept growing, and those capabilities were rarely treated as the responsibility of the computing environment itself.
What AFS keeps is the starting point of owning your resources
AFS is not a traditional folder under a new name. It is a filesystem abstraction: content, configuration, data sources and callable actions can all be discovered and organised through one set of path semantics. It can mount data, indexes, caches or other providers, so it does not require every site to push everything onto a local disk.
The abstraction suits publishing not because it denies databases or application code, but because it establishes a shared surface of what is true first. An author's content, the site declaration and the data available for presentation do not have to be copied into a completely separate CMS before they can become pages. The Web Device can assemble publishable output from those declarations and resources, instead of asking the author to hand-build a new site pipeline.
This still does not mean any directory automatically becomes a website. A publishing site needs explicit .web/ declarations, pages and content conventions, and unusual behaviour may still call for a custom component or provider. The difference is that the first layer an author faces is no longer a web application they must operate from zero. It is a set of publishing resources the system can understand.
The next part takes up why this instinct did not stay with static documents. Once a URL could invoke a program, the web gained a genuinely important new capability, and it also started putting "resource" and "application" into the same request. ARC's problem is not how to undo that step. It is how to keep publishing direct after keeping it.