Digital Topology & Economic Power

In the era of personal computing — which itself broke from the terminal-and-mainframe model, where user work lived on institutional machines and was accessed through centrally administered interfaces — the file was a relatively autonomous object, existing separately from the application that produced it. The practice of format openness was always contested; opaque formats were common from the beginning. But the file as portable possession was a powerful norm, embedded in operating systems, programming languages, and user expectations alike. The Unix tradition, in particular, cultivated what McIlroy, Pinson, and Tague described as a preference for programs that handled "streams of text" as a universal interface, reinforcing the notion that data should be legible and movable independently of the tools that operated on it.¹

This arrangement — the topology of digital objects, meaning the structure of boundaries and relationships between the concrete things that computing is composed of — is where power finds grip. Ownership, copyright, and control attach to the boundaries of digital objects. For users, file-app separation was a source of agency: your work existed independently of the tools which operated on it, and switching costs stayed low. But the same boundary that lets you say "this is my document" is the one that lets Adobe say "this format is our intellectual property" — and the one that allowed competing tool-makers to build alternative applications against incumbents' wishes. The file was a site of both user agency and market contestation.

As the software industry consolidated and turned toward enclosure, the portability of the file threatened the hold of dominant incumbents over their consumer base. Firms with large installed bases stood to gain from format opacity; challengers and complementary tool-makers, by contrast, often had strong interests in openness. The pressure to enclose the economic agency of the app-file relationship took two distinct but concurrent forms. The first was the proprietary format: the .psd or .doc remained technically a file you possessed, but the intelligibility of that file was enclosed within a single vendor's control. Enclosure did not need to abolish the file. It needed only to make the boundary opaque.

The second was internalization: the application interposed itself as the manager of user data, absorbing what had been discrete files into opaque, application-governed databases and packages. Apple's iTunes moved users from MP3 files in folders — objects you could see, copy, and manipulate independently — to an opaque library database that organized music on the user's behalf. iPhoto and later Photos.app enclosed images in an opaque .photoslibrary package. Outlook consolidated individual emails into monolithic .pst files. Even browser bookmarks migrated from editable HTML files to internal databases. The topological effect was different from format opacity: where proprietary formats left the file intact but made its contents unreadable, internalization put your work wholly inside the application.

Both strategies drew support from legal regimes of intellectual property expansion. The Digital Millennium Copyright Act of 1998, among other things, criminalized the circumvention of technical protection measures — meaning that even where reverse-engineering a proprietary format or extracting data from an internalized store was technically feasible, it could now be treated as a criminal act². As Seltzer has argued, this effectively created a new property right, granting vendors legal dominion over the boundary between user and data.³

The effect was to shift agency and control toward incumbents while leaving much of the formal topology of personal computing superficially intact. This was not, however, a frictionless process. The open-source and open-format movements — from the OpenDocument Format standardization effort to the European Union's interoperability mandates — fought precisely on topological terrain, seeking to hold the boundary open by political and legal means.⁴ That these efforts partially succeeded and partially failed is itself evidence that the topology of digital objects is a genuinely contested site of political struggle, not a surface that capital reshapes at will.

Only after the practices of format opacity and data internalization were well established did cloud computing re-engineer the topology of objects to be congruent with the new topology of power. The transition was short — internalization and app-specific formats had already made the application, not the file, the locus of the user's relationship to their data, and migrating the backend to a remote server merely completed a reorientation of agency that was years in the making. Your work now exists as rows in someone else's database, accessible through their interface, on their terms.⁵

Cloud platforms solved real problems of versioning, collaboration, and cross-device access, and these genuine improvements are not incidental to enclosure — enclosure succeeds not by offering users less, but by bundling genuine capability gains with topological restructuring, so that the user cannot accept the improvement without accepting the new relationship of power.⁶ Where file export exists, it ranges from genuinely functional to essentially vestigial. But even robust export — Google Takeout, Notion's markdown output, platform APIs — rarely preserves the full relational structure of work produced within a platform: the versioning, permissions, integrations, and collaborative context that constitute the cloud object have no adequate file-shaped container to export into. The topology has changed such that the file is no longer a sufficient vessel for the work. Enclosure worked through the existing material form — first by hollowing it out (proprietary formats and internalization), then by abolishing it entirely (cloud platforms) — relocating and reshaping the data beyond the user's reach, bundling real gains with a quiet transfer of power.