A Comprehensive Architecture for a Browser-Based Read-Only Virtual Filesystem in Historical Archives

Full report

On this page

The presentation of historical archival material within a browser-based desktop metaphor presents a highly specific set of architectural challenges. When constrained strictly to native web technologies—PHP, HTML, CSS, and vanilla JavaScript—without reliance on third-party frameworks, content delivery networks, or external filesystem libraries, the system must independently simulate complex operating system semantics. The core objective is to construct an immersive, highly responsive read-only virtual filesystem (VFS) that faithfully mimics desktop interactions while rigorously preserving the archival provenance of the underlying materials. In this environment, researchers must experience historical journals, book pages, reconstructed websites, research notes, and derived visualizations as distinct files and folders rather than traditional web routes. Crucially, the architecture must enforce a strict, immutable separation between canonical source material and derived representations. To achieve this, the design adapts established digital preservation metadata standards, specifically integrating the PREMIS (Preservation Metadata: Implementation Strategies) data dictionary to explicitly model the relationships between original objects, the agents that transformed them, and the events that generated new derived formats1. This report details an exhaustive architectural blueprint for this environment, providing structural schemas, security models, and behavioral specifications designed to ensure that the interface feels like a genuine filesystem browser without compromising historical integrity.

Recommended Virtual Filesystem Hierarchy

The virtual filesystem hierarchy establishes the spatial organization of the archive. Because this is a read-only historical environment, the filesystem implements a mounting architecture that separates user-ephemeral spaces from immutable archival records. This separation mimics the physical distinction between a researcher's temporary workspace and the secure vaults of a physical archive.

The topological design ensures that users instinctively understand the boundary between their working space (C:\\) and the immutable historical record (A:\\ and N:\\).

File Object Schema

To maintain the distinction between structural hierarchy and physical file data, the architecture utilizes an inode-based schema, heavily inspired by POSIX designs but implemented entirely in-memory via JavaScript3. The file object schema (inode) represents the physical data, technical metadata, and preservation metadata, completely distinct from its topological location in the directory tree. The schema incorporates PREMIS concepts to document provenance, tracking objects, events, and agents1. The strict inclusion of this metadata ensures the user interface can visually and programmatically distinguish a canonical TIFF image from a derived Markdown transcript.

JSON { "inode\_id": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "type": "file", "content\_ptr": "/api/raw/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "size\_bytes": 1048576, "mime\_type": "image/tiff", "extension": ".tiff", "timestamps": { "created": "1994-08-12T10:00:00Z", "archived": "2026-01-15T08:30:00Z", "last\_accessed": null }, "premis\_metadata": { "object\_category": "file", "preservation\_level": "canonical", "fixity": { "algorithm": "SHA-256", "digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" }, "relationships": \[ { "relationship\_type": "is\_source\_of", "related\_object\_id": "inode-derived-transcript-883", "event\_id": "evt-ocr-2026" } \] } }

By decoupling the inode from the directory structure, the architecture allows a single historical document to appear in multiple locations (e.g., within A:\\Journal\\ and A:\\Documents\\) without duplicating the underlying data structure or compromising the single source of truth3.

Directory Object Schema

The Directory Entry (dentry) schema maps human-readable paths and filenames to their underlying inodes. This structural table allows for aliases, shortcuts, and complex folder navigation.

JSON { "dentry\_id": "d-9938-4421", "parent\_id": "d-root-archive-journal", "name": "August\_12\_Entry.tiff", "inode\_id": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "attributes": { "is\_hidden": false, "is\_system": false, "is\_readonly": true }, "icon\_override": "icon-journal-page.png", "sort\_order": 1 }

The dentry model facilitates the creation of virtual collections. By querying the dentry array for specific parent\_id values, the vanilla JavaScript explorer application dynamically constructs the visual folder hierarchy. Aliases are implemented seamlessly by creating multiple dentry objects with different parent\_ids that all point to the same inode\_id.

Stable Identifier Strategy

Given the critical source-integrity requirement, standard auto-incrementing database IDs or sequential counters are fundamentally insufficient for archival management. The architecture mandates Content-Addressable Storage (CAS) identifiers for all canonical files. The inode\_id for any canonical file is the SHA-256 hash of its exact bitstream1. This enforces strict fixity and immutability; if a single bit of the canonical content changes, the cryptographic hash changes, resulting in a new identifier and thereby preventing silent corruption or tampering. This strategy aligns perfectly with PREMIS guidelines for ensuring long-term digital object authenticity5. Derived files, which are subject to re-processing (e.g., running a newer OCR engine on an old image), utilize a composite identifier. This composite ID comprises the canonical source hash, the derivation event ID, and the agent ID, taking the form SHA256(Source)\_EVT(Event)\_AGT(Agent). This deterministic naming convention guarantees that the precise lineage and transformation methodology of any derived file can be statically verified simply by inspecting its identifier4. Dentries and ephemeral user files utilize standard Version 4 UUIDs, as directory structures and shortcuts represent curatorial or user organization rather than immutable historical artifacts.

Canonical vs. Derived Mount Model

To prevent any ambiguity between original artifacts and reconstructed or normalized records, the virtual filesystem enforces a rigorous separation at the conceptual mount level. The filesystem metaphor must ensure that a user never confuses an OCR transcript with the physical document it represents. The primary mount point, A:\\Canonical\\, is heavily restricted by the application's internal registry. Files residing within this mount can only be executed by specific "Raw" viewer applications, such as hex viewers or raw bitstream image renderers. They are explicitly prohibited from being opened in rich-text editors, stylized document viewers, or interpretation-heavy presentation layers. This preserves the psychological and technical distinction of examining a raw artifact, ensuring the researcher interacts with the material at its most fundamental level. Conversely, the A:\\Derived\\ mount contains representations such as transcripts, data visualizations, and modernized format conversions. These files rely heavily on the PREMIS event metadata linking them back to the canonical source6. When a user views a file in the derived mount, the Explorer UI automatically injects a persistent, non-dismissible provenance banner detailing the specific transformation event. This banner explicitly states the derivation methodology (e.g., "This is a derived text representation generated via Tesseract OCR v4.0 on 2026-02-14. Click here to view the canonical source.")4. This architectural constraint guarantees that derived representations never masquerade as the original.

File Association Registry Design

In a traditional operating system, the registry maps file extensions to executable binaries. In this pure browser environment, the registry maps MIME types and file extensions to specific vanilla JavaScript classes representing windowed applications responsible for rendering the content within the DOM. The association registry is a centralized configuration object loaded during the application bootstrap phase. It dictates the default behavior when a file is executed and populates the contextual options available to the user.

This matrix allows the system to differentiate behavior based on the file type while strictly enforcing archival boundaries. For instance, the system will actively reject an attempt to open a canonical file in a Markdown viewer, forcing a fallback to the Hex Viewer to prevent the application of unverified styling to raw data.

Open-With Behavior

When a user right-clicks a file, the system prevents the default browser context menu via e.preventDefault() bound to the contextmenu event. The system then calculates the cursor coordinates and injects a custom, absolutely positioned DOM element representing the OS-level context menu. The "Open With" submenu dynamically queries the file association registry's supportedApps array for the target file's extension. This mechanism provides researchers the flexibility to interrogate files at multiple levels of abstraction. If a user selects a non-default application, the system instantiates the selected JavaScript window class, passing the file's inode\_id as the initialization parameter. This allows a researcher to view a historical image natively, or open it in a hex viewer to manually inspect the file header for digital forensics, replicating the power of a full desktop environment.

Shortcut/Link Model

Shortcuts in this environment behave similarly to .lnk files in Windows or symbolic links in POSIX systems. A shortcut is modeled as a standard dentry and inode pair, but the inode possesses a highly specific, system-recognized MIME type (application/x-shortcut). The content\_ptr property of a shortcut inode contains the exact dentry\_id or absolute path of the target file or folder. When the Explorer navigation logic encounters a shortcut during execution or traversal, it halts its default rendering loop, extracts the target ID, and executes a recursive redirection function. This mechanism is critical for populating the C:\\Desktop\\ namespace with prominent research artifacts located deep within the A:\\Book Archive\\ hierarchy without duplicating large swaths of data. To prevent infinite loops caused by recursive symbolic linking, the traversal algorithm maintains a Set of visited shortcut IDs during a single resolution pass, throwing an exception and halting execution if a duplicate ID is detected.

Explorer Behavior Specification

The visual Explorer application serves as the primary interface for interacting with the archive. Built purely with HTML, CSS, and vanilla JavaScript, it meticulously replicates complex desktop paradigms without relying on frameworks like React or Vue. The navigation model relies on double-click events bound to folder dentries. Upon execution, the system queries the master dentry array for all entries where the parent\_id matches the newly selected folder. The main display DOM element is then cleared and rapidly repopulated using DocumentFragment insertions to ensure maximum rendering performance. The address bar and breadcrumb trail are dynamically generated by traversing the parent\_id chain from the current directory back to the root C:\\ or A:\\ mount. The address bar functions bidirectionally; users can type an absolute path (e.g., A:\\Journal\\1994\\) and press Enter, triggering a path-resolution algorithm that splits the string by backslashes and walks the dentry tree to locate the target directory. The system maintains a local history stack array to manage Back/Forward navigation. Every successful directory traversal pushes the current dentry\_id into the history array, incrementing a state pointer. This allows seamless temporal navigation of the user's session without relying on the browser's native history API, which is reserved for deep-linking. The Explorer supports two distinct rendering modes toggled via the UI. Icon view utilizes a CSS Grid layout, dynamically calculating column counts based on window width and rendering large thumbnail overrides. Details view utilizes a standard HTML \<table\> element, enabling complex data presentation. The column headers (Name, Date Modified, Type, Size) are bound to event listeners that trigger array prototype sorting methods. When a header is clicked, the active dentry array is sorted alphabetically, numerically, or chronologically before the DOM is re-rendered, providing instant, client-side data organization.

Search/Index Design

Because the environment strictly forbids external APIs or server-side execution during runtime, search functionality requires a pre-computed, in-memory inverted index. During the build phase, the PHP backend scans the entire archive repository, tokenizes document titles, paths, and PREMIS metadata fields, and compiles a comprehensive JSON dictionary mapping semantic tokens to arrays of relevant dentry\_ids. When a user interacts with the search bar in the Explorer window, the JavaScript engine performs a highly optimized dictionary lookup against this loaded JSON payload. The search algorithm applies basic lexical stemming and fuzzy matching to provide responsive results as the user types. For deep content searching within derived plain-text transcripts or Markdown research files, the system instantiates a dedicated Web Worker. This worker performs non-blocking substring matching across the loaded text blobs, posting message events back to the main UI thread as matches are found. This architecture ensures that complex archival queries spanning thousands of documents do not lock the main rendering thread, maintaining the fluid illusion of a powerful desktop computer8.

Read-Only Clipboard Semantics

Standard operating system copy/paste operations involve transferring physical byte streams between memory locations. In this strictly read-only virtual filesystem, copying a file merely copies its reference. When a user executes a copy command, the system serializes a JSON object containing the target's dentry\_id, absolute path, and file type, storing this object in a custom VirtualClipboard manager that utilizes the browser's localStorage to persist data across potential page reloads. Because the historical archive mounts are strictly read-only, attempting to paste a file into locations such as A:\\Journal\\ or A:\\Documents\\ triggers a modal system error dialog emphasizing archival integrity. However, researchers are free to paste file references into their ephemeral user spaces, such as C:\\Users\\Guest\\My Documents\\ or directly onto the C:\\Desktop\\. In these instances, the system executes shortcut generation logic rather than duplicating the file. It generates a new dentry and a shortcut inode pointing back to the canonical artifact, allowing the user to curate personal collections without altering the underlying archival database.

Drag/Drop Behavior

The drag-and-drop mechanism is implemented natively using the HTML5 Drag and Drop API, utilizing the dragstart, dragover, dragenter, and drop event listeners. When a user initiates a drag event on a file node, the dataTransfer object is populated with a custom payload containing the node's dentry\_id. As the cursor moves over the desktop environment, the system calculates intersection geometry to provide visual feedback. If dropped onto a compatible application icon, the system extracts the ID and opens the file in that specific application. If the cursor hovers over a read-only folder, the UI enforces a cursor: no-drop CSS rule, visually communicating the archival boundary. If a file is dropped onto the user's Desktop or a writable ephemeral folder, the system triggers the clipboard paste logic, generating a shortcut to the underlying file. To facilitate bulk operations, the system implements multiple file selection using a custom rubberband selection box. This is achieved by drawing an absolutely positioned \<div\> over the grid during mousedown and mousemove events, dynamically calculating the intersecting bounding client rectangles between the selection box and the file nodes9. Selected nodes receive a distinct CSS class, and subsequent drag operations batch their IDs into the dataTransfer payload.

File Properties Dialog Specification

The File Properties dialog is invoked via the context menu and serves as the primary, standardized interface for exposing the complex digital preservation metadata required by the archival context. The dialog is structured into three distinct tabs, rendering data directly from the inode JSON schema. The General tab displays standard operating system metrics: the filename, system icon, calculated file size, absolute path, and timestamps indicating when the file was created and archived. The Metadata tab exhibits format-specific data extracted during the PHP build process. For images, this includes EXIF data, resolution, and color depth; for documents, it includes page counts and language encoding. The Provenance tab is the most critical component, directly rendering the PREMIS metadata block. For a canonical file, this tab displays the preservation level, the ingestion agent responsible for the file, and the cryptographic fixity checksum, assuring the user of the file's absolute integrity1. For a derived file, this tab visually maps the transformation event. It displays the parent canonical file ID as a clickable hyperlink, details the software agent used for derivation, and provides the exact timestamp of the transformation event6. This tab guarantees absolute transparency regarding how a historical representation was generated, fulfilling the core requirement of archival provenance.

URL/Deep-Link Mapping

To allow researchers to bookmark specific views, cite archival locations in external publications, or share documents with colleagues, the desktop state must be mapped to the browser's URL using the HTML5 History API, specifically leveraging window.history.pushState and replaceState. A standard deep-link URL structure is defined as follows: https://archive.example.com/?path=A:\\Journal\\1994\\\&open=d-9938-4421 Upon system initialization, the core bootstrapper parses the URLSearchParams. If the path parameter is present, the Explorer application is automatically spawned and programmatically navigated to that specific directory, circumventing the default desktop view. If the open parameter is present, the system resolves the provided dentry ID, queries the File Association Registry, and spawns the appropriate application window, overlaying it on top of the desktop context. This implementation ensures deep linkability and standard web accessibility without compromising the Single Page Application desktop illusion. As the user navigates the filesystem naturally, the system continuously updates the URL parameters via replaceState to reflect the current active window.

Persistence Rules

The integrity of a read-only historical archive demands a strict bifurcation of state management: absolute volatility for historical artifacts contrasted with durable persistence for user preferences and layouts. The state of the archive itself is strictly volatile. Any changes to sorting algorithms, column widths, or filtering views within the A:\\ drive are held only in RAM and are destroyed upon page reload. The underlying dentry and inode tables provided by the PHP payload are immutable within the client environment. Conversely, the user workspace must persist to facilitate prolonged research sessions. The contents of C:\\Desktop\\, C:\\Users\\Guest\\My Documents\\, the Favorites array, and the Recent Documents array are continuously serialized to JSON and stored in the browser's localStorage or IndexedDB depending on storage size requirements. Furthermore, window configurations—including the X/Y coordinates, z-index stacking order, and dimensions of open application windows—are debounced and saved locally. Upon returning to the site, the desktop environment reads this payload and restores the exact workspace configuration, allowing the researcher to resume their work seamlessly.

Accessibility Model

Simulating a rich desktop operating system within a web browser presents immense accessibility challenges, as standard HTML semantic flow is disrupted by absolute positioning and window management. The virtual filesystem relies heavily on WAI-ARIA (Web Accessibility Initiative \- Accessible Rich Internet Applications) guidelines to ensure robust compatibility with screen readers and keyboard-only navigation. The Explorer file grid strictly implements the WAI-ARIA treegrid pattern10. The primary container receives role="treegrid", while individual rows receive role="row". Depth and hierarchical relationships are communicated via aria-level attributes. Expandable folders utilize aria-expanded attributes toggled between true and false states to inform screen readers of structural changes11. Because standard browser tab navigation is insufficient for a complex grid, keyboard navigation is manually bound and managed in vanilla JavaScript. Arrow keys handle bidirectional focus movement across the two-dimensional grid. The Enter key executes the default file action, the Space bar toggles file selection, and a combination such as Alt+Enter opens the Properties dialog. Focus management is strictly maintained; when a new application window or modal dialog is spawned, the system implements a focus trap, restricting the user's Tab navigation strictly to the active window to prevent interaction with obscured desktop elements10.

Security and Privacy Considerations

The most significant security vector in this architecture involves rendering reconstructed historical web captures located in A:\\Web Captures\\. Historical HTML often contains outdated, malicious, or poorly scoped JavaScript that could break the SPA desktop environment or perform Cross-Site Scripting (XSS) attacks if executed within the main application context12. To mitigate this severe risk, all web captures are rendered within heavily restricted \<iframe\> elements governed by robust sandbox configurations. The sandbox attribute is applied universally. For purely static HTML pages, sandbox="" is used, denying all execution capabilities13. For historical pages requiring basic interactivity, sandbox="allow-scripts" is applied. Critically, the architecture strictly forbids the combination of allow-scripts and allow-same-origin13. Omitting allow-same-origin forces the iframe into an opaque, unique origin. This isolation ensures that even if a historical script executes maliciously, it cannot access the parent desktop's DOM, read the localStorage containing the user's workspace, or manipulate the parent URL13. Furthermore, the PHP backend issues strict Content Security Policy (CSP) headers for the main desktop application, utilizing frame-src to lock down iframe origins and script-src omitting unsafe-inline to prevent unauthorized execution12. Any necessary communication between the sandboxed web capture and the parent desktop—such as resizing the window to fit the document content—is handled explicitly via window.postMessage. The parent window enforces strict origin validation and schema checks on all incoming messages, silently discarding malformed or unexpected data payloads to prevent spoofed command execution14.

Example Filesystem Tree (Representative Nodes)

The following structure illustrates a segment of the virtual filesystem containing over 50 representative nodes. It demonstrates the complex interplay between system execution spaces, ephemeral user workspaces, canonical data mounts, and derived representations. C: ├── Desktop │ ├── Important\_Web\_Capture.lnk \-\> (A:\\Web Captures\\Geocities\_Index.warc) │ ├── Research\_Notes\_Shortcut.lnk \-\> (A:\\Derived\\Notes\_1994.md) │ └── System\_Trash.lnk \-\> (R:) ├── System │ ├── app\_hex\_viewer.js │ ├── app\_image\_viewer.js │ ├── app\_markdown\_viewer.js │ ├── app\_warc\_browser.js │ └── core\_explorer.js └── Users └── Guest ├── Favorites │ ├── favorite\_book\_shortcut.lnk \-\> (A:\\Book Archive\\Encyclopedia\_Vol\_1) │ └── favorite\_image\_shortcut.lnk \-\> (A:\\Canonical\\Images\\photo\_evidence\_A.raw) ├── My Documents │ ├── Curated\_Research\_Collection │ │ ├── manifesto\_link.lnk \-\> (A:\\Canonical\\Documents\\manifesto\_original.doc) │ │ └── notes\_link.lnk \-\> (A:\\Research\\curator\_notes\_1994.md) │ └── Saved\_Search\_Query\_1994.json └── Recent Documents ├── recent\_1.lnk \-\> (A:\\Derived\\Transcripts\\journal\_pg01\_transcript.md) └── recent\_2.lnk \-\> (A:\\Canonical\\Images\\journal\_pg01\_raw.tiff) A: ├── Book Archive │ ├── Encyclopedia\_Vol\_1 │ │ ├── cover.jpg │ │ ├── index.xml │ │ ├── metadata.json │ │ ├── pg\_001.jpg │ │ ├── pg\_002.jpg │ │ ├── pg\_003.jpg │ │ └── pg\_004.jpg │ └── Technical\_Manual\_1985 │ ├── manual\_cover.tiff │ ├── schematics.tiff │ ├── section\_1.md │ └── section\_2.md ├── Canonical\\ │ ├── Documents │ │ ├── letter\_handwritten.jpg │ │ ├── manifesto\_original.doc │ │ └── memo\_scanned.pdf │ ├── Images │ │ ├── journal\_pg01\_raw.tiff │ │ ├── journal\_pg02\_raw.tiff │ │ ├── map\_sector\_7\_raw.tiff │ │ ├── map\_sector\_8\_raw.tiff │ │ ├── photo\_evidence\_A.raw │ │ └── photo\_evidence\_B.raw │ └── Web\_Data │ ├── payload\_1998\_01.bin │ └── server\_logs\_raw.dat ├── Derived\\ │ ├── Normalized │ │ └── manifesto\_normalized.pdf │ ├── Transcripts │ │ ├── journal\_pg01\_transcript.md │ │ ├── journal\_pg02\_transcript.md │ │ └── letter\_ocr\_output.txt │ └── Visualizations │ ├── log\_traffic\_graph.svg │ ├── map\_sector\_7\_enhanced.png │ └── map\_sector\_8\_enhanced.png ├── Documents │ ├── Admin\_Records │ │ ├── budget\_1994.txt │ │ └── personnel\_list.txt │ └── Correspondence │ └── outbox\_1994.txt ├── Journal │ ├── 1994 │ │ ├── entry\_feb.md │ │ ├── entry\_jan.md │ │ └── entry\_mar.md │ └── 1995 │ ├── entry\_feb.md │ └── entry\_jan.md ├── Research │ ├── Contextual\_Essays │ │ ├── analysis\_of\_sector\_7.md │ │ └── impact\_of\_manifesto.md │ └── Finding\_Aids │ └── guide\_to\_journals.md └── Web Captures ├── Corporate\_Intranet\_1999 │ ├── directory.html │ ├── login\_page.html │ └── memo\_board.html └── Geocities\_Archive ├── about\_reconstructed.html ├── assets │ ├── bg\_tile.gif │ ├── counter.png │ └── under\_construction.gif ├── guestbook\_capture.html └── index\_reconstructed.html

Pseudocode: Filesystem Traversal and Association Resolution

The following specification details the logic used by the vanilla JavaScript engine to handle directory traversal, resolve shortcuts, detect recursive loops, and instantiate applications.

JavaScript // Global In-Memory Stores (Injected into global scope by PHP on initial page load) const DENTRY\_TABLE \= { /\ Indexed by dentry\_id \/ }; const INODE\_TABLE \= { /\ Indexed by inode\_id \/ };

/\\ \ Traverses a given absolute path string to locate the target dentry object. \ Implements strict cycle detection for symbolic link loops. \*/ function resolvePathToDentry(pathStr) { let parts \= pathStr.split('\\\\').filter(p \=\> p \!== ''); let currentId \= 'root\_dentry\_id'; let visitedNodes \= new Set();

for (let i \= 0; i \< parts.length; i++) { let part \= parts\[i\];

let found \= Object.values(DENTRY\_TABLE).find( d \=\> d.parent\_id \=== currentId && d.name.toLowerCase() \=== part.toLowerCase() );

if (\!found) return null; // Path invalid

currentId \= found.dentry\_id;

// Handle Shortcut Resolution let inode \= INODE\_TABLE\[found.inode\_id\]; if (inode.type \=== 'shortcut') { if (visitedNodes.has(inode.content\_ptr)) { throw new Error("Filesystem Error: Recursive shortcut loop detected."); } visitedNodes.add(inode.content\_ptr); currentId \= inode.content\_ptr; } } return DENTRY\_TABLE\[currentId\]; }

/\\ \ Executes a file based on its dentry and inode metadata, enforcing archival constraints. \/ function executeFile(dentry\_id) { let dentry \= DENTRY\_TABLE\[dentry\_id\]; let inode \= INODE\_TABLE\[dentry.inode\_id\];

// Directory execution triggers navigation if (inode.type \=== 'directory') { ExplorerApp.navigateAndRender(dentry\_id); return; }

// Shortcut execution triggers recursive resolution if (inode.type \=== 'shortcut') { executeFile(inode.content\_ptr); return; }

// Application Resolution via Registry let appClass \= FileAssociationRegistry.resolveDefault(inode.extension, inode.mime\_type);

if (appClass) { // Enforce Canonical integrity constraint if (inode.premis\_metadata.preservation\_level \=== 'canonical' && \!appClass.isRawViewer) { SystemDialog.alert("Archival Constraint: Canonical files must be viewed in Raw mode."); appClass \= HexViewer; // Fallback to raw bitstream viewer }

// Instantiate window geometry and logic let appInstance \= new appClass(inode.inode\_id); WindowManager.spawn(appInstance);

// Dynamically inject provenance banner for derived works if (inode.premis\_metadata.preservation\_level \=== 'derived') { let parentId \= inode.premis\_metadata.relationships\[0\].related\_object\_id; appInstance.injectProvenanceBanner( \Archival Notice: This is a derived representation. Source: ${parentId}\ ); } } else { SystemDialog.alert(\No application registered for MIME type: ${inode.mime\_type}\); } }

Detailed Test Plan

Validating the integrity, usability, and security of a custom virtual filesystem requires a rigorous, multi-layered testing protocol executed against the vanilla JavaScript logic.

Implementation Roadmap

To successfully deliver this complex architecture using purely native web technologies, development will proceed in four distinct, sequential phases over an eight-week timeline. Phase 1: Foundation and Backend Generation (Weeks 1-2) Development begins with the PHP ingestion engine. This script runs server-side during the build process, scanning the physical directory holding the historical materials. It extracts technical metadata, calculates cryptographic SHA-256 hashes for canonical items1, and builds the massive INODE\_TABLE and DENTRY\_TABLE JSON payloads. Furthermore, this phase involves implementing the PREMIS metadata generation, ensuring all derived files generated via OCR scripts or normalizers contain the correct event mapping linking back to their canonical source6. Phase 2: Core Virtual Filesystem Engine (Weeks 3-4) The focus shifts to the vanilla JavaScript core. Developers will implement the path resolution algorithms, the FileAssociationRegistry, and the HTML5 History API mapping to support deep linking. The fundamental Window Manager is constructed during this phase to handle spawning, z-index stacking manipulation, and drag calculations for moving application windows across the DOM desktop. Phase 3: Applications and Desktop Mechanics (Weeks 5-6) This phase tackles the visual interface. The primary Explorer application logic is built, implementing Grid/Details views, client-side sorting arrays, and the Back/Forward history stack. Developers will implement the HTML5 Drag and Drop API logic and the custom mouse-event math required for rubberband selection9. The suite of internal viewer applications is developed: HexViewer for canonical files, MarkdownViewer for derived texts, and the critical WebArchiveBrowser utilizing strict iframe sandboxing for HTML captures14. Phase 4: Polish, Accessibility, and Security (Weeks 7-8) The final phase focuses on refinement and hardening. Complete WAI-ARIA tagging is applied to the Explorer grids and desktop icons to ensure compliance10. The VirtualClipboard is finalized, integrating with localStorage to persist the ephemeral user workspaces, Favorites, and Recent Documents arrays. Security audits are conducted on the iframe postMessage bridges to guarantee untrusted historical JavaScript cannot breach the desktop context14. The project culminates with the execution of the Detailed Test Plan and the deployment of the monolithic read-only payload.

Works cited

1. Administative and Technical Metadata Standards, https://socialhistoryportal.org/bestpractices/technicalmetadata

2. Metadata and documentation \- Digital Preservation Handbook, https://www.dpconline.org/handbook/organisational-activities/metadata-and-documentation

3. The Missing Abstraction for AI Agents: The Agent Filesystem \- Turso, https://turso.tech/blog/agentfs

4. PREMIS Events Through an Event-sourced Lens, https://journal.code4lib.org/articles/17264

5. PREMIS Data Dictionary for Preservation Metadata, Version 3.0, https://library.oclc.org/digital/api/collection/p15003coll85/id/1168/download

6. PREMIS Events metadata \- Archivematica, https://www.archivematica.org/en/docs/archivematica-1.12/user-manual/metadata/premis/

7. PREMIS With a Fresh Coat of Paint \- D-Lib Magazine, https://www.dlib.org/dlib/may08/lavoie/05lavoie.html

8. Use Kuzu with Multiple Web Workers Safely \- OneUptime, https://oneuptime.com/blog/post/2026-08-12-kuzu-web-workers-single-process-api-layer/view

9. August 2022 \- openSUSE ARM, https://lists.opensuse.org/archives/list/arm@lists.opensuse.org/2022/8/

10. Treegrid Pattern | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/patterns/treegrid/

11. ARIA: treegrid role \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/treegrid\_role

12. Iframes in XSS, CSP and SOP \- HackTricks, https://hacktricks.wiki/en/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.html

13. HTML inline frame element \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe

14. Iframe XSS: postMessage, CSP, Sandboxing, & Clickjacking, https://7asecurity.com/blog/2026/06/iframe-xss-security/

15. Tracking Data Between iframe and Parent: postMessage, Consent, https://ceaksan.com/en/iframe-tracking-postmessage

16. Builder Guide: Designing and Building Apps \- Cribl Docs, https://docs.cribl.io/apps/builder-guide/