The web as a system capability

Separate concerns instead of one tangled web stack.

Putting a website online is usually not the hard part. Making it a place that stays usable for years is.

An article needs a page, a domain and a deployment. Someone reads it and wants to respond, so now you need identity, moderation and notifications. The content grows, so you need search, indexing and permissions. One step further and the site has to talk to APIs, let colleagues collaborate, let an agent help maintain it. What began as "publish a page" has quietly become "operate an application." None of this is the modern web doing something wrong. Databases, application servers, frontend runtimes and hosting platforms all appeared for real reasons. The problem is that these needs now arrive bundled into a single default assumption: to publish information you own, first deploy and run an application.

I am not arguing for a return to static home pages, and not suggesting every site should drop its framework. The claim is narrower: a website can be an application, but it should not have to be one. For most pages whose job is publishing, public presentation, basic identity, permissions and response ought to be things the computing environment already provides. Live collaboration, business workflows and specialised runtimes can grow on top when they are actually needed.

That is the starting point for treating the web as a device in ARC (Agentic Realm Computer). It does not reduce the web to a folder, and it does not describe the Web Device as an identity or interaction system on its own. The shared model in ARC is AFS (Agentic File System): publishing, inspection, verified caller identity, authorization context and callable actions can all cooperate inside one set of system semantics, and the Web Device is the face of that turned toward public publishing. This piece is the overview for the whole series. First, why the web became complicated. Then, why ARC's answer is not one more site framework.

The early web made publishing direct

What drew people to the early web was not only hyperlinks or the browser. It was that a readable document could have an address other people could use. HTML was an application of SGML, but it did not require an author to become a network administrator or a computer scientist before turning text, links and images into a page someone else could open. Personal home pages, and later publishing conventions like Apache's UserDir and Personal Web Sharing on macOS, pushed that intuition further into ordinary use: put content into a space you own, and it can become a page others reach.

The feel of that same small act kept changing. An early author might edit an index.html on shared hosting and send friends the URL. A blogging-era author wrote a new entry in a web form, and readers arrived through a permalink or a reverse-chronological front page. In the application-stack era an editor writes into a CMS while a developer looks after builds, databases, deployment and permissions at the same time. Every step brought real convenience. It also tied "publish something of mine" to "run a complete system."

This was never unconditional. public_html is a web server convention, not a public home page Unix hands to everyone, and the Sites directory on a Mac still needed Web Sharing, network and security configuration. But they left behind a mental model worth keeping: publishing starts from a resource the author owns, not from an application instance a distant platform keeps on the author's behalf.

Before the web reached a general audience, Gopher was also a significant way to reach information on the internet. The web spread not because one technical feature defeated everything else, but because a linked-document model, graphical browsers, cross-platform distribution, open implementations and permissive licensing together lowered the cost of taking part. What deserves to survive from that period is not nostalgia for simpler times. It is a plainer question: to publish one piece of content, how many unrelated systems does an author have to operate?

ARC is not proposing that the world roll back into static directories. AFS is a filesystem abstraction rather than a reproduction of the traditional directory tree. Its value is that content, configuration, data and callable capabilities can enter one addressable model of what is true. The directness of a file becomes the starting point for a system boundary, not a ceiling on what the system can do.

Turning the web into an application platform was real progress

Once a URL could invoke a program, the web stopped being limited to files written in advance. CGI let a server run a program per request and generate a response. Template languages made pages and data easier to combine. Content management systems, application servers and databases made large amounts of content, users and business state manageable. Later, JavaScript in the browser grew steadily more capable, and Ajax, single-page applications and a layered frontend pushed live interaction much further. Today's server rendering, static generation and edge deployment can look like a return to earlier ideas. They are better read as a fresh trade-off between performance, indexability and developer experience.

So complexity should not be cast as the villain. A collaborative document, a live trading interface or a multi-party workflow genuinely needs durable state, event handling, isolation and finer security policy. The trouble is that current practice often starts an article, a product page and a complex application from the same deployment pipeline, and then asks each team to bolt on content management, search, login, comments, monitoring and permissions separately.

This is also why static site generators and hosting platforms, for all the friction they removed, did not end the problem. They solved the "get content onto the web" segment well. But as soon as readers want to sign in, respond, save something, collaborate or subscribe, the author is usually wiring in another identity system, another comment service, another set of data and moderation logic. Publishing got simpler. Conversation fragmented again.

ARC's position is not that these tools were wrong. It is that the parts each of them re-implements should move down a layer. The Web Device is ARC's publishing capability for public, indexable documents and content pages. It assembles HTML from declared site resources, page content and themes, and puts building, previewing, link and SEO checking, and publishing onto one path inside the system. It does not replace arbitrary applications, and it does not promise to turn every dynamic workload into a static page. It answers a narrower question: when the job is mostly publishing, must an author operate a whole application before deserving a professional site?

The cut can be read as a small contract. A publishing site declares its content, its presentation and the interaction it is willing to open. The ARC runtime supplies verified caller identity and authorization context to applications that use it, and the Web Device reuses the build and publish path. The moment the need becomes live editing, dragging or collaboration, that belongs to the UI Device. The moment it becomes specialised business logic or a dedicated data source, that belongs to a higher-level provider or application. None of this removes responsibility for operations, security or moderation, and it does not make a site trust an outside identity automatically. It avoids reinventing the same groundwork inside every small site.

After publishing, the web should still be able to answer

Blogging tools once offered a different answer. They folded continuous posting, dated archives, templates and hosting into a workflow lighter than a traditional CMS. The weblog was not the origin of personal expression, but it did make repeated publishing something many people could actually sustain. TrackBack then proposed an idea of equal importance: a response can live on the responder's own site while still letting the original author know it exists.

Blogs were not the only such moment. Personal home pages, visual editors, Apple's HomePage and iWeb, hosted blogs, and cloud drives that could once turn a public folder into a static page all handed publishing back to ordinary people. Their product shapes differed, and together they show one thing: people have consistently wanted a space they can express and share from directly. The detailed product history belongs in this series' timeline. What matters here is why none of them made publishing, interaction and long-term control default capabilities at the same time.

Webmention today continues the linkback idea. It lets one page tell another "I linked to you," and the receiver verifies that the link is really there. The mechanism puts more weight on verifiability than early TrackBack did, but it is not a comment system you can drop in. The receiving end still has to handle discovery, verification, storage, abuse resistance, moderation and presentation. That is a large part of why many independent sites eventually turn comments off, or hand the conversation to a centralised platform instead.

The gap here is concrete. A reader leaving a comment, reacting, or subscribing to what comes next looks like a few small features. Underneath sit identity, authorship, write permission, moderation, records and display. If every publisher has to assemble that chain from nothing, independent publishing degrades easily into read-only publishing. It helps explain why so much independent publishing ends up hosting its conversation somewhere else, or closing responses altogether.

Part of this is already a shared capability in ARC's current runtime. The system can supply verified caller identity and authorization context to applications built on it, and comments and reactions can reuse one set of rules for authorship, ownership and administrative deletion. Pre-rendered Web Device pages can attach to the ARC runtime's comment surface without themselves becoming a long-lived live session. Full discussion boards, subscription notifications, complex feeds and dedicated social products remain higher-level application problems. Discuss Kit is still the reference application for a full board, while the interaction primitives that kept reappearing across projects are being moved down into shared capability. What moves down is not every community product. It is the part they each kept rewriting.

Why ARC treats the web as a device

Inside ARC, the split between the Web Device and the UI Device is deliberate. The first handles the publishing web: assembling content, AUP (Agentic UI Protocol) pages, site declarations and resources into pages meant for readers. The second handles continuous interactive surfaces: holding a session, receiving events, returning incremental updates. They share AFS path semantics and AUP's way of expressing an interface, and they do not pretend to be one runtime mode.

The point of that split is not only performance or rendering strategy. It separates "I want the world to read this" from "I want a user to keep operating this interface" into two different system responsibilities. The first can emphasise stability, indexability, previewability and publishing. The second can emphasise sessions, events, state and device capability. Verified caller identity, authorization context and actions do not need to be built twice. They belong to the layer underneath both.

So calling the web a device does not mean a website is equivalent to a keyboard, a screen or an agent. More precisely, ARC raises public web publishing into a system surface that can be discovered, invoked and inspected. Where the content suits publishing, a blocklet or an agent can reuse the Web Device's build and publish path, reading facts, producing pages, checking results and publishing along the same AFS semantics. When a case needs an unusual data source, complex business logic or specialised interaction, higher-level providers and applications still carry it.

This is also why ARC emphasises both shared semantics and openness. Sites under the same ARC semantics can reuse identity, records and interaction rules more naturally, but that does not mean they automatically share user data, trust or permissions. Those grants still have to be made explicitly by the site and the user. Facing outward, Webmention and ActivityPub are open directions worth connecting to: the first suits verifiable cross-site references, the second offers a federation model of actors, activities and inbox/outbox. Neither is a zero-configuration comment button, and neither is a compatibility layer ARC has shipped. Openness does not mean claiming compatibility with everything today. It means not designing internal convenience into an external wall.

Complexity should move, not disappear

A modern website can of course still be a complex application. There should also be another possibility. When the need is publishing an article, maintaining a product page, sharing material or organising a set of content, the author starts with a publishing space that belongs to them. When readers want to respond, identity, permission and basic interaction do not have to be assembled from nothing. When the need grows into live collaboration or specialised business logic, the application grows on a clear system boundary.

This is not turning the web back into the 1990s. The directness of the early web is worth understanding again not because it was capable enough, but because it treated "content I own can be published by me" as the natural starting point. The question worth asking now is different: once agents can help people create and maintain software, why does owning a web space you can publish from, converse in and keep evolving still feel like deploying a small infrastructure project?

ARC's answer to that is still being built. What it has going for it is not a claim to have replaced every framework. It is that the problem gets taken apart first: public publishing is not a side effect of running an application, basic interaction is not a plugin burden on every author, and open interoperability should not wait until everyone is on the same platform. Later articles in this series take up the move from directories to programs, from application stacks to browser runtimes, and from weblogs to linkbacks, and say more concretely what the Web Device, the UI Device and AFS each should carry.

Further reading and the limits of these facts

A full timeline, a glossary and per-item sources are maintained as reference pages in this series. This article uses these facts to support an argument, and does not treat them as an inevitable line of technical progress.