Architectural Blueprint for Local-Only Workspace Portability in Al.Qaeda.net Archival Reconstruction

Full report

On this page

Executive Recommendation

To achieve a seamless, highly secure, and historically authentic local-first user experience for the Al.Qaeda.net Archival Reconstruction workstation, the architecture must completely isolate user-generated research from the immutable canonical archive. The recommended approach is to implement a unified workspace package format—an .aqw (Archive Workspace) file, utilizing a standard ZIP container envelope that encapsulates structured JSON, bibliographic schemas, and plain text representations of the user's state. All import and export operations must be explicitly user-driven, mimicking the classic Windows 95 GetOpenFileName and GetSaveFileName Common Dialog Box interfaces, but powered by the modern Web File System Access API. To ensure absolute data privacy and adherence to local-first principles, the browser environment must strictly enforce a Content Security Policy (CSP) of default-src 'self' and connect-src 'none', mathematically guaranteeing that no bytes of the selected files can traverse a network interface. Conflict resolution during import must leverage the interaction paradigm of the classic Windows Briefcase, presenting users with an explicit, item-by-item reconciliation interface (a "Merge Reconciler") when imported data collides with existing browser-local IndexedDB state. This approach ensures maximum data portability, absolute user ownership, and perfect adherence to the required early-Windows nostalgic aesthetic.

1. Comparative Analysis of Historical and Modern Paradigms

The challenge of portable, disconnected data synchronization within a browser is a modern problem that requires a synthesis of contemporary web APIs and historical desktop interaction models. Designing an intuitive user experience for the Al.Qaeda.net workstation requires analyzing systems that successfully solved offline portability, data provenance, and complex state synchronization. The architecture proposed in this document draws critical insights from five primary historical and modern paradigms.

These five paradigms inform every facet of the proposed architecture. The Ink & Switch local-first philosophy dictates the underlying technical constraints—specifically, that the browser's IndexedDB is the primary database, not a caching layer for a cloud server1. Because the application cannot rely on a cloud server to resolve state conflicts, the Windows Briefcase interaction model is resurrected to give the user manual, explicit control over how incoming data merges with existing local data7. The OAIS reference model dictates the rigid internal data boundaries protecting the 425-node Archive VFS8, while Zotero and Netscape standards govern the specific formats the system must emit when a user chooses to selectively export their work10.

2. Conceptual Model for a Portable Research-Workspace File

The workspace export must serve as a comprehensive, highly portable snapshot of the user's session and analytical labor. To minimize file management friction, this snapshot must be encapsulated within a single file payload.

The ZIP Container Strategy

The most appropriate vehicle for this data is a standard ZIP archive format acting as a container envelope, utilizing a custom .aqw (Archive Workspace) file extension. A ZIP container is natively understood by decades of desktop software, supports efficient compression of large text bodies, and allows for structured internal directories19. While SQLite databases are excellent for querying structured data locally within the browser, utilizing a raw SQLite binary as the primary interchange format sacrifices human-readability and debuggability19. Instead, the .aqw ZIP file should contain easily parseable JSON, Markdown, and CSV files, enabling researchers to inspect, parse, or extract their data using generic extraction utilities (e.g., WinZip, PKZIP, or native OS extractors) even if the original workstation software becomes unavailable.

Required Package Contents

A complete backup of the user's work must serialize specific state data from the local browser storage into the .aqw file. The internal structure of the archive must separate human-readable content from machine-restorable configuration data.

Deliberate Exclusions

To manage file size, ensure rapid export times, and preserve strict archival integrity, specific elements must be deliberately excluded from the workspace export.

1. Canonical Archive Material: The 425-node immutable Archive VFS, the book sources, and the preserved research sources must never be included in the export. The .aqw file relies strictly on uniform resource identifiers (URIs) and pointers to these immutable resources rather than duplicating their raw binaries or text strings.

2. Application System Binaries: The JavaScript, CSS, HTML, and WebAssembly required to run the Al.Qaeda.net workstation itself must be excluded. The export file represents pure user state data, not a self-executing application binary.

3. Transient Cache: Temporary image renders, partial search indexes, or cached network responses used to speed up the local UI should be excluded to prevent unnecessary bloat.

Safe Filename Conventions and Metadata

When generating the .aqw file or any selective export, the system must enforce strict filename conventions. Filenames must avoid illegal filesystem characters native to DOS and Windows environments (\< \> : " / \\ | ? \*) to ensure the file can be safely saved and extracted on any host operating system. The default filename pattern for a full backup should follow Archive\_Workspace\_YYYYMMDD\_HHMM.aqw. If a user selectively exports a specific document, the title must be aggressively sanitized, replacing spaces with underscores and stripping non-alphanumeric characters, appending the correct extension (e.g., Analysis\_Of\_Source\_Material.md).

3. Internal Data Boundaries and Provenance Safeguards

A non-negotiable requirement of the historical archive is that imported user data must never masquerade as canonical archive material. If a user imports a workspace containing a fabricated note or an altered transcript, the system must possess the architectural rigor to visually and structurally segregate it from the recovered workstation's baseline historical truth.

The W3C Provenance Ontology (PROV-O)

To maintain absolute clarity regarding data origins, the internal data model must utilize concepts derived from the W3C Provenance Ontology (PROV-O)24. PROV-O provides a standardized framework for tracing the origin, attribution, and generation of digital entities, modeling the world through three primary classes: Entity, Activity, and Agent26. Within the context of the workstation:

• Entity: The specific digital object (e.g., a note, a bookmark, or a canonical document)26.
• Agent: The actor responsible for the entity. The system distinguishes between the SystemAgent (the immutable archive) and the UserAgent (the local researcher)24.
• Activity: The event that created or modified the entity (e.g., ImportWorkspace, CreateAnnotation, SystemInitialize)26.

By assigning prov:wasGeneratedBy and prov:wasAttributedTo properties to all data residing in the local IndexedDB, the workstation can programmatically filter out user modifications when rendering a "pure" view of the historical archive28. If a record lacks an cryptographic signature linking it to the SystemAgent, it is automatically treated as user-generated material.

The W3C Web Annotation Data Model

Annotations, including highlights, marginalia, and bookmarks, pose a unique risk to data integrity if not handled correctly. Annotations must never mutate the underlying DOM or text strings of the canonical archive documents. Instead, they must strictly adhere to the W3C Web Annotation Data Model22. In this model, an annotation is an independent entity consisting of two primary components: a Body (the user's comment or tag) and a Target (the specific segment of the canonical document being annotated)22. To reliably anchor a highlight to immutable text without relying on brittle DOM paths (which may break if the archive's internal HTML formatting is updated), the system must utilize the TextQuoteSelector algorithm29. The TextQuoteSelector dynamically locates the annotated text during the rendering pipeline by matching three distinct strings32:

• exact: The exact string of text the user highlighted34.
• prefix: A snippet of text immediately preceding the highlighted portion, used for disambiguation if the exact string appears multiple times in the document34.
• suffix: A snippet of text immediately following the highlighted portion34.

When a document is loaded, the workstation parses the user's TextQuoteSelector data from IndexedDB, locates the matching text range in the canonical document, and dynamically applies a non-destructive CSS highlight overlay34. Furthermore, the system must explicitly record the intent of the annotation using standardized W3C motivations such as oa:bookmarking, oa:commenting, or oa:tagging22.

Visual Segregation in the Nostalgic UI

To communicate provenance to the user without exposing metadata schemas or XML namespaces in the UI, the workstation must employ clear, period-authentic visual indicators. Canonical archive materials residing in the Archive Explorer must utilize standard, unadorned system icons (e.g., classic Windows 95 text file or folder icons). Conversely, any item residing in the Research Workspace or originating from an imported .aqw file must feature a distinct visual overlay. This should manifest as a small "Briefcase" or "Pen" badge superimposed on the bottom-left corner of the file icon, explicitly mimicking the classic Windows "Shortcut" arrow paradigm. Furthermore, rendering windows that display user-generated text should employ distinct background colors (e.g., an off-white or pale yellow hex code \#ffffe1, invoking the physical appearance of a notepad or sticky note), contrasting sharply with the stark white or gray backgrounds used for canonical archive documents.

4. Tiered Export Capabilities and Forward Compatibility

While the unified .aqw package serves as the primary mechanism for full-state backup and restore, users must not be forced into an all-or-nothing interaction model. The system must support a tiered export architecture, offering both machine-restorable full backups and highly specific, human-readable selective exports.

Full Workspace Backup (Machine-Restorable)

The primary "Backup" function produces the .aqw ZIP file. This is a non-lossy serialization of the user's entire IndexedDB state. Because the software architecture of the workstation may evolve over time, importing an older workspace package into a newer version of the workstation presents a risk of data corruption or schema mismatch. To guarantee forward-compatibility, the .aqw package relies on the manifest.json file at its root. This manifest explicitly declares the schema version used during the export. When a future version of the Al.Qaeda.net workstation imports an older .aqw file, a dedicated migration layer within the application's core logic intercepts the JSON payload. This migration layer acts as an adapter, applying necessary transformations and structural upgrades to the legacy JSON data in memory before writing it to the local IndexedDB, ensuring seamless continuity of research across software iterations.

Selective and Human-Readable Exports

Recognizing that researchers often need to extract their intellectual labor independently of the workstation interface to use in external publications or tools, the system must offer specific, localized "Export" dialogs accessible via right-click context menus on individual folders or files.

• Favorites & Links: Exported exclusively using the NETSCAPE-Bookmark-file-1 HTML specification15. This ensures that a researcher can instantly import their curated list of archive nodes directly into Chrome, Firefox, or Safari16.
• Citations, Bibliography, and Metadata: When exporting bibliographic data related to the archive's books or preserved sources, the system must emit industry-standard formats: BibTeX (.bib), RIS (.ris), and CSL-JSON (.json)10. This prevents proprietary lock-in and allows seamless integration with tools like Zotero or EndNote10.
• Research Drafts and Notes: Exported as Plain Text (.txt) or Markdown (.md). Markdown is highly preferred as it preserves semantic formatting (headers, bolding, lists) without the proprietary overhead of rich text formats36.
• Tabular Data: System history logs, explicit research trails, and saved search queries must be exportable as Comma-Separated Values (.csv), facilitating external analysis in spreadsheet software.

5. Browser Capabilities, Storage Constraints, and Strict Security

Developing a robust local-first application requires deeply understanding and navigating the complex, often undocumented limitations of modern browser storage APIs. The architecture must balance performance, persistence, and the non-negotiable requirement of absolute data privacy.

Content-Security-Policy (CSP) and Data Exfiltration Prevention

To honor the core directive that user data must never be uploaded to a web server, cloud account, or analytics system, the web server delivering the Al.Qaeda.net application must strictly enforce a rigid Content Security Policy (CSP) via HTTP headers38. The required policy is:

HTTP Content-Security-Policy: default-src 'self'; connect-src 'none'; object-src 'none'; script-src 'self' 'unsafe-inline';

Setting the connect-src directive to 'none' is the cornerstone of this security architecture38. It mathematically guarantees that the browser is cryptographically prohibited from establishing fetch(), XMLHttpRequest, or WebSocket connections to any external or internal server after the initial application bundle has loaded38. Even if malicious JavaScript were somehow introduced into the environment, it would be physically impossible for it to exfiltrate the user's workspace data over the network. All operations are strictly confined to the local browser context.

Local Storage Architectures: IndexedDB and OPFS

The system must rely on IndexedDB as the primary asynchronous, transactional database engine for storing structured workspace data (e.g., JSON records of annotations, window positions, and metadata)43. IndexedDB provides vital atomic operations; if a workspace import fails midway due to a corrupt file or browser error, the transaction can be safely aborted via the IDBTransaction.abort() method, rolling back all partial changes to prevent a corrupted, half-imported state45. For raw file handling and the persistence of large Markdown drafts or exported ZIP binaries, the system should leverage the Origin Private File System (OPFS) where supported49. OPFS provides a high-performance, byte-by-byte local file system sandboxed to the application's origin, bypassing the severe memory overhead and performance bottlenecks associated with storing large Blobs directly in IndexedDB50.

Managing Browser Storage Quotas and Eviction

Modern browsers fiercely protect user disk space and utilize opaque algorithms to silently evict local site data if the device faces storage pressure or if specific privacy settings are triggered43.

• Chrome and Edge: Generally allow an origin to consume up to 60% of total disk space43. However, in Incognito or Private Browsing modes, this quota is aggressively throttled to approximately 5% or a hard 300MB cap43.
• Firefox: Allocates up to 50% of free disk space, typically capped at 2GB for "best-effort" storage groups43.
• Safari (macOS/iOS): Highly restrictive and unpredictable. Safari limits IndexedDB to approximately 50MB to 1GB per origin51. More critically, under its Intelligent Tracking Prevention (ITP) protocols, Safari notoriously implements a 7-day eviction policy, permanently deleting all script-writable storage (including IndexedDB) if the user does not interact with the site for a week43.

Mitigation Strategy: The application cannot assume data permanence. It must utilize the navigator.storage.estimate() API (where available) to proactively check available storage quotas before initiating a large workspace import or saving a massive .aqw backup43. This data should be exposed to the user via a period-authentic "Disk Space" or "System Properties" window. Furthermore, upon initialization, the application must attempt to invoke navigator.storage.persist()43. If granted by the user, this upgrades the origin's storage status from "best-effort" to "persistent," protecting the archive from silent browser eviction43. Because Safari's eviction policies remain aggressive regardless, the UI must periodically surface a non-intrusive, period-authentic "Maintenance Wizard" prompting the user to manually export an .aqw backup to their physical hard drive.

File API and Rehydration Limitations

To trigger import and export dialogs naturally, the architecture should employ the W3C File System Access API (specifically the showOpenFilePicker() and showSaveFilePicker() methods)49. This API triggers the host operating system's native file selection dialogs, perfectly emulating the desktop software experience without requiring \<input type="file"\> DOM hacks57. However, a critical limitation exists regarding file rehydration. While file handles (FileSystemFileHandle) can technically be stored in IndexedDB, they lose their implicit read/write access permissions when the browser session ends49. If the application attempts to read a previously stored file handle upon a page reload, it must call requestPermission()62. This prompts the browser to display a modern, out-of-character security popup asking the user to re-grant access59. To maintain the strict retro visual immersion of the workstation, the application must not rely on persistent raw file handles outside of the sandboxed OPFS. Instead, it must fully ingest the contents of imported files into IndexedDB immediately upon selection, discarding the transient file handle entirely49.

Zip Bomb Protection

Because the application must parse .aqw ZIP files entirely client-side using JavaScript libraries (such as JSZip or fflate), it is highly vulnerable to decompression bombs (Zip bombs)20. A Zip bomb is a malicious archive designed to appear small but expand into petabytes of data, crashing the browser tab via Out-of-Memory (OOM) errors and potentially corrupting the IndexedDB instance67. The import routine must implement rigorous defensive decompression algorithms68. During stream extraction, the application must monitor the expanded byte count in real-time. The operation must be forcefully aborted if the uncompressed size exceeds a safe threshold (e.g., 100MB for a text-based workspace) or if the compression ratio exceeds a highly suspicious metric (e.g., \> 100:1)67.

6. Interaction Flows and Collision Resolution

The user interface executing these technical operations must strictly conform to the early-Windows/Internet Explorer era aesthetics. Implementations must entirely avoid Material Design, glassmorphism, floating action buttons, or modern "toast" notifications. The UX relies on heavy bevels, inset borders, MS Sans Serif typography, pixelated icons, and standard window chrome (title bars, menu bars, status bars).

Export / Backup Flow

1. Initiation: The user selects "Backup Workspace..." from a classic desktop Start \-\> Programs menu or a File drop-down menu in the primary application window.

2. Configuration Dialog: A modal Property Sheet appears, titled "Backup Configuration", featuring classic gray \#dfdfdf backgrounds and tabbed navigation. The user views a checklist (checked by default) of exportable components: Annotations, History, User Documents, and Interface Layout.

3. File Selection: Clicking "OK" triggers the showSaveFilePicker() API49. The default filename is populated as Archive\_Workspace\_YYYYMMDD.aqw. If the API is unsupported on the user's browser, the system falls back to synthesizing an anchor tag (\<a download="..."\>) to trigger the download.

4. Progress: A classic Win9x-style file transfer dialog appears. It features an animated icon of papers flying from a manila folder into a leather briefcase, accompanied by a deterministic, segmented progress bar (calculated by counting IndexedDB object iterations).

5. Completion: A system chime sounds, and a standard MessageBox (featuring an "OK" button and a blue 'i' information icon) informs the user: "Workspace backup completed successfully."

Import / Restore Flow

1. Initiation: The user selects "Restore Workspace...", triggering the showOpenFilePicker() configured to only accept .aqw or .zip files49.

2. Validation & Extraction: The system loads the selected file into memory, verifies the ZIP signature, and attempts to parse the internal manifest.json. If the file is corrupt or oversized, a MessageBox displaying a period-authentic error appears (e.g., featuring a red 'X' icon and the text: "The specified archive could not be opened. Ensure the file is a valid Workspace Package and is not corrupted. Error Code: 0x800C0005").

3. The Merge Reconciler (Preview Dialog): This is the most critical interaction design. Instead of silently overwriting current local data, the system presents a "Workspace Synchronization" wizard, visually modeled directly after the Windows 95 Briefcase "Update All" dialog7.

• The dialog features a deeply beveled ListView or TreeView comparing the current local browser state with the incoming .aqw package7.
• Columns include: Item Name, Local Status, Incoming Status, and Action.
• Visual indicators (e.g., a red 'X' for conflicts, a green arrow for new items, a clock for newer timestamps) denote differences at a glance7.

4. Collision Behavior Rules:

• Non-overlapping data (New items): Automatically set to "Merge" (Add).
• Overlapping data with identical hashes: Ignored (Skip).
• Overlapping data with different content (Conflicts): The system defaults to "Replace" (the incoming file overrides the local file if it possesses a newer timestamp), but the user can click the Action cell to open a context menu and explicitly choose "Skip" or "Keep Both". Selecting "Keep Both" appends a version string to the incoming file (e.g., Draft\_Document (2).txt).

5. Execution: The user clicks "Synchronize". An IndexedDB transaction opens. If extraction or writing fails at any point, the transaction automatically aborts, leaving the prior local state perfectly intact without data corruption46.

6. Refresh: The window manager gracefully re-renders the desktop icons, window layouts, and active documents to reflect the newly synchronized state.

7. Accessibility and Implementation Directives

While strictly maintaining the nostalgic, pixelated aesthetic, the implementation must adhere to modern accessibility standards beneath the surface. Furthermore, concrete acceptance criteria guide the engineering effort.

Accessibility Considerations

• Focus Trapping: All custom Win9x modal dialogs (such as the Merge Reconciler, Backup Configuration, or Error Message boxes) must implement rigorous keyboard focus traps. When a modal dialog is open, the Tab key must cycle exclusively through the actionable elements within that specific dialog, preventing the user from accidentally interacting with the background workspace. This conforms to ARIA 1.2 modal specifications70.
• Screen Reader Compatibility: The custom TreeViews and ListViews utilized in the Briefcase synchronization UI must utilize standard, semantic HTML elements under the hood (e.g., nested \<ul\> and \<li\> tags) paired with appropriate aria-expanded, aria-selected, and role="treeitem" attributes to ensure compatibility with modern screen readers.

MoSCoW Implementation Priorities

Must-Have Features:

• Complete Local Isolation: The application strictly enforces the connect-src 'none' CSP38. The Network tab in browser developer tools must show absolutely zero outbound requests when a workspace file is imported or exported.
• IndexedDB Transactional Integrity: All import routines must be wrapped in an atomic IDBTransaction. A simulated failure mid-import (e.g., throwing a deliberate error) must result in a complete rollback of the database45.
• The .aqw ZIP Container: Valid, extractable ZIP file generation using a library such as fflate or JSZip, containing the structured JSON representation of the workspace65.
• Win9x UI Parity: Import/Export dialogs, progress bars, and error message boxes must perfectly match the existing visual design language (classic fonts, \#c0c0c0 backgrounds, 3D inset borders).

Should-Have Features:

• Web Annotation Compliance: Output JSON for user highlights and marginalia must strictly conform to W3C standards, utilizing oa:Annotation, oa:TextQuoteSelector, and proper prefix/suffix anchoring to ensure stability against underlying markup changes23.
• Format-Specific Exports: The ability to right-click a Research Collection and export strictly as .bib (BibTeX) or .json (CSL-JSON) for immediate interoperability with academic tools like Zotero10.
• The Merge Reconciler UI: The Briefcase-style synchronization dialog allowing users to preview and manually select/deselect specific collections or documents prior to finalizing an import7.

Experimental Features:

• CRDT-based Silent Merging: Implementing Conflict-Free Replicated Data Types (CRDTs) on a local level to deterministically merge paragraph-level text edits across different workspace backups, minimizing the need for manual user intervention during complex synchronization conflicts1.

Acceptance Criteria

1. Given a user with existing annotations, a custom history trail, and specific window layouts active, When they execute "Backup Workspace", Then an .aqw (ZIP) file is immediately downloaded to their local OS without any network requests occurring.

2. Given a user opens a completely fresh browser session (or manually clears their local site data), When they select "Restore Workspace" and provide the previously generated .aqw file, Then all annotations, UI layouts, and research drafts are restored identically to the previous session.

3. Given a workspace containing a user-created note explicitly attached to a canonical archive text, When the note is rendered in the workstation, Then it features a distinct visual color scheme (e.g., yellow notepad background) and a badge icon, ensuring it cannot be mistaken for the original historical text.

4. Given a malicious .aqw file designed as a zip bomb, When the user attempts to import it, Then the application detects the anomalous uncompressed byte size, immediately aborts the extraction, and displays a standard retro warning dialog without crashing the browser tab.

Works cited

1. Local-first software: You own your data, in spite of the cloud, https://www.inkandswitch.com/essay/local-first/

2. Local-First Software \- PowerSync Docs, https://docs.powersync.com/resources/local-first-software

3. Local-first software \- Wikipedia, https://en.wikipedia.org/wiki/Local-first\_software

4. (PDF) Local-first software: you own your data, in spite of the cloud, https://www.researchgate.net/publication/336427093\_Local-first\_software\_you\_own\_your\_data\_in\_spite\_of\_the\_cloud

5. Local-First Software Architecture: Building Apps That Work Offline, https://pavanrangani.com/blog/local-first-software-architecture-sync-guide

6. Algebraic Replicated Data Types: Programming Secure Local-First, https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.ECOOP.2023.14

7. Briefcase (Microsoft Windows) \- Grokipedia, https://grokipedia.com/page/Briefcase\_(Microsoft\_Windows)

8. OAIS Reference Model (ISO 14721\) Explained \- CASRAI, https://casrai.org/dictionary/term/oais-reference-model-iso-14721

9. OAIS in Practice for Regulated Organisations \- Docbyte, https://www.docbyte.com/oais-regulated-organisations/

10. feat: RIS \+ CSL-JSON export in format\_bibliography (Zotero ... \- GitHub, https://github.com/zoharbabin/web-researcher-mcp/issues/163

11. CSL-JSON as an Interchange Format \- GROBID Tools, https://grobid.org/formats/csl-json

12. Citation export processors (The Org Manual), https://orgmode.org/manual/Citation-export-processors.html

13. Primer — An Introduction to CSL — Citation Style Language 1.0.1, https://docs.citationstyles.org/en/v1.0.2/primer.html

14. CSL-JSON — citeproc-js 1.1.73 documentation \- Read the Docs, https://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html

15. Documentation or reference for "NETSCAPE-Bookmark-file-1, https://stackoverflow.com/questions/72772176/documentation-or-reference-for-netscape-bookmark-file-1-doctype

16. Bookmarks.txt is a concept of keeping URLs in plain text files, https://news.ycombinator.com/item?id=45047572

17. The Netscape Bookmarks Format \- Pinefore, https://pinefore.com/docs/filetypes/netscape-html

18. Using AI to declutter and organise my bookmarks | van der Walt, https://vanderwalt.de/blog/ai-bookmark-organizer

19. SQLite database as a data interchange format?, https://softwareengineering.stackexchange.com/questions/371087/sqlite-database-as-a-data-interchange-format

20. Limitations of JSZip, https://stuk.github.io/jszip/documentation/limitations.html

21. Local-first software (2019) \- Hacker News, https://news.ycombinator.com/item?id=44473135

22. Web Annotation Data Model \- W3C, https://www.w3.org/TR/2014/WD-annotation-model-20141211/

23. Web Annotation Working Group \- Publications \- W3C, https://www.w3.org/groups/wg/annotation/publications/

24. PROV-O: The PROV Ontology \- W3C, https://www.w3.org/TR/prov-o/

25. PROV-Overview \- W3C, https://www.w3.org/TR/prov-overview/

26. 5\. Provenance information \- FAIR Cookbook, https://faircookbook.elixir-europe.org/content/recipes/reusability/provenance.html

27. PAV ontology: provenance, authoring and versioning \- PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC4177195/

28. The OPMW-PROV Ontology, https://www.opmw.org/ontology/

29. Web Annotation Data Model \- W3C, https://www.w3.org/TR/annotation-model/

30. Web Annotation Data Model \- W3C, https://www.w3.org/TR/2015/WD-annotation-model-20151015/

31. Web Annotation Vocabulary \- W3C, https://www.w3.org/TR/annotation-vocab/

32. README.md \- readium/annotations \- GitHub, https://github.com/readium/annotations/blob/main/README.md

33. Ontology in RDF/XML \- W3C, https://www.w3.org/ns/oa.rdf

34. Selectors and States \- W3C, https://www.w3.org/TR/selectors-states/

35. Zotero Web API Documentation, https://www.zotero.org/support/dev/web\_api/v3/basics

36. The Ultimate Guide to Local-First Software \- Dench, https://www.dench.com/blog/ultimate-guide-local-first-software

37. The Architecture Of Local-First Web Development, https://www.smashingmagazine.com/2026/05/architecture-local-first-web-development/

38. Content Security Policy | Mendix Documentation, https://docs.mendix.com/howto/security/csp/

39. Apply Content Security Policy \- OutSystems 11 Documentation, https://success.outsystems.com/documentation/11/security\_and\_compliance/apply\_content\_security\_policy/

40. Content Security Policy \- Tableau Help, https://help.tableau.com/current/server/en-us/security\_csp.htm

41. Manage your site's Content Security Policy | Microsoft Learn, https://learn.microsoft.com/en-us/power-pages/security/manage-content-security-policy

42. Content Security Policy: strict-dynamic \+ (cached) nonce, https://www.aem.live/docs/csp

43. IndexedDB: Browser Support, Storage Limits, Known Issues, https://www.testmuai.com/learning-hub/indexeddb-browser-support/

44. IndexedDB Tutorial \- How to Use IndexedDB, Its Limits, and RxDB, https://rxdb.info/articles/indexeddb/indexeddb-tutorial.html

45. IDBTransaction: abort() method \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/IDBTransaction/abort

46. IndexedDB Explained: Schema, Transactions, and Cursors, https://javascript.plainenglish.io/indexeddb-explained-storage-transactions-and-cursor-0da6abc8df68

47. Indexed Database API 3.0 \- W3C, https://www.w3.org/TR/IndexedDB/

48. Stop Abusing localStorage: The Complete Guide to Browser Storage, https://sadiqueali.medium.com/stop-abusing-localstorage-the-complete-guide-to-browser-storage-in-2026-97cf231a2588

49. File System Access API: Browser Support, Methods, Limits \- TestMu AI, https://www.testmuai.com/learning-hub/file-system-access-api-browser-support/

50. Origin private file system \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/File\_System\_API/Origin\_private\_file\_system

51. Storage for the web | Articles, https://web.dev/articles/storage-for-the-web

52. Storage quotas and eviction criteria \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/Storage\_API/Storage\_quotas\_and\_eviction\_criteria

53. What are IndexedDB's storage limits across different browsers, https://www.mindstick.com/interview/34337/what-are-indexeddb-s-storage-limits-across-different-browsers-platforms

54. Available storage on mobile device \- General \- SilverBullet Community, https://community.silverbullet.md/t/available-storage-on-mobile-device/2132

55. Does Edge/Safari have a limit on Indexeddb size? \- Stack Overflow, https://stackoverflow.com/questions/51405660/does-edge-safari-have-a-limit-on-indexeddb-size

56. Working with the Storage API \- Raymond Camden, https://www.raymondcamden.com/2023/08/25/working-with-the-storage-api

57. Getting Started With the File System Access API \- CSS-Tricks, https://css-tricks.com/getting-started-with-the-file-system-access-api/

58. The origin private file system | Articles \- web.dev, https://web.dev/articles/origin-private-file-system

59. Persistent permissions for the File System Access API | Blog, https://developer.chrome.com/blog/persistent-permissions-for-the-file-system-access-api

60. Chrome extention | re-use FileSystemFileHandle from indexedDB, https://github.com/WICG/file-system-access/issues/289

61. File System Access API: is it possible to store the fileHandle of a, https://stackoverflow.com/questions/65928613/file-system-access-api-is-it-possible-to-store-the-filehandle-of-a-saved-or-loa

62. FileSystemHandle: requestPermission() method \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/FileSystemHandle/requestPermission

63. FileSystemHandle: queryPermission() method \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/FileSystemHandle/queryPermission

64. File System Access, https://wicg.github.io/file-system-access/

65. zip.js/BENCHMARKS.md at master · gildas-lormeau/zip.js · GitHub, https://github.com/gildas-lormeau/zip.js/blob/master/BENCHMARKS.md

66. GitHub \- 101arrowz/fflate: High performance (de)compression in an, https://github.com/101arrowz/fflate

67. Incorrect security remedy for adm\_zip \- Sonar Community, https://community.sonarsource.com/t/incorrect-security-remedy-for-adm-zip/97929

68. How To Protect Your System Against Zip Bombs? \- SafeAeon, https://www.safeaeon.com/security-blog/zip-bomb/

69. What Is a Zip Bomb? Defending Against Decompression Attacks, https://www.huntress.com/cybersecurity-101/topic/what-is-zip-bomb

70. Accessible Modal Dialogs & Popups, ARIA | ExceedAbility, https://exceedability.com/modals-popups-and-dialog-boxs.html

71. Accessible Modal Dialogs: Focus Trapping and Screen Reader, https://testparty.ai/blog/modal-dialog-accessibility

72. Offline First | Apps \- Chrome for Developers, https://developer.chrome.com/docs/apps/offline\_apps