Four cooperative layers
The interface lives in an extension-owned workspace, opened from either the toolbar popup or the DBOPFS Studio DevTools launcher, but the storage authority belongs to the connected website. A dormant isolated content script receives a Studio request, lazily imports the packaged DBOPFS agent in its isolated world, performs the operation against the inspected origin's storage, and returns a serializable result through extension messaging.
1. Studio workspace
The user-facing dashboard and editor run under the extension's own origin. They do not directly call navigator.storage.getDirectory(), because that would open the extension's private OPFS—not the website's.
2. Isolated extension bridge
A Manifest V3 content script provides a dormant isolated bridge on permitted HTTP(S) pages. The workspace associates each operation with its selected tab, and requests and results travel through extension messaging rather than shared filesystem handles or DOM events.
3. Isolated-world agent
On first request, the bridge dynamically imports the declared agent module with an extension URL and calls its exported request handler directly in the isolated content-script world. Content-script web storage is still scoped to the host page's origin, so OPFS resolves against the inspected website. No DOM script element, page-main-world execution, or DOM request/response channel is involved. This design also works when the site enforces a strict Content Security Policy such as script-src 'none'.
4. Bundled DBOPFS runtime
The extension carries verified DBOPFS 1.0.0 runtime files and the runtime's bundled strong-type@1.1.0 dependency. It does not load application logic from a CDN. Provenance and upstream hashes are recorded in the repository's source provenance.
DBOPFS-first operations
In database mode, the navigation model follows DBOPFS:
OPFS root/
└── apps/
└── <application-id>/
├── <table>/
│ └── <record-key>
└── <another-table>/Application, table, and record actions use the bundled DBOPFS module so the Studio honors its naming, serialization, application scoping, and error behavior. In 0.1, the visible explorer is limited to discovered DBOPFS application namespaces. A raw OPFS explorer for data outside that model is on the roadmap and is not exposed by the current UI.
An application ID is organization, not security isolation. Code with authority on the same origin can bypass DBOPFS and call the raw OPFS APIs. Use separate origins or browser profiles for mutually untrusted applications.
The origin boundary
OPFS is browser-private storage attached to an origin. At minimum, protocol, hostname, and port must match. Browsers may add storage partitioning based on top-level site, profile, private-browsing mode, or policy.
| Context | Relationship | Expected OPFS |
|---|---|---|
https://app.example/a and /b | Same origin | Same origin root |
https://app.example and http://app.example | Different protocol | Separate |
https://app.example and https://admin.example | Different hostname | Separate |
https://app.example:443 and :8443 | Different port | Separate |
DBOPFS Studio therefore operates on one selected live active or inspected page at a time. The permitted HTTP(S) content-script bridge is not a mounted global filesystem, and it does not make closed sites available. Protected browser pages and origins without a connectable tab cannot be inspected.
Permissions, explained
The unpacked build uses only storage as an explicit API permission, plus HTTP(S) host access for the static dormant bridge. Application exports use a browser download initiated by the page rather than a dedicated extension-download permission. Check the current extension/manifest.json before release, because it is the authoritative list.
Some URLs remain off-limits regardless of how Studio is opened, including browser-internal pages, browser extension stores, and other protected surfaces. Enterprise policy can further restrict installation or scripting.
Why the worker fallback is guarded
OPFS synchronous access handles are worker-only. A worker launched from an extension URL can resolve storage under the extension origin rather than the inspected website, which would make a successful-looking operation target the wrong filesystem. DBOPFS Studio refuses that unsafe fallback instead of silently crossing origin semantics. Capabilities that cannot be performed correctly in the page's origin are reported as unavailable.
Editing and destructive actions
Supported text-based records can be decoded and edited in the Studio, then written through the connected isolated agent. JSON is validated before save. Browser-supported images, audio, and video receive previews; PDFs and other binary records can open through the browser rather than being coerced into text.
The 0.1 UI can create tables and records, import files into a selected table, export an application, save record changes, and delete a record after exact-name confirmation. A backup remains the only reliable undo after data is removed.
Roadmap boundary. Rename, move, copy, raw OPFS browsing, table deletion, restore, and origin-wide clear are not exposed by the current Studio interface.
Native PDF and print path
DBOPFS Studio does not bundle PDF.js or another PDF renderer. It reads the selected PDF from the connected origin, gives the document to a browser-owned PDF surface, and relies on that browser for rendering and print UI. The exact annotation, form, save, and editing controls vary among Chrome, Edge, Brave, Vivaldi, Opera, and their versions.
The Studio print surface renders text, JSON, Markdown, and image records before entering the browser and operating-system print path. Audio and video can be previewed, but intentionally have no printable Studio rendering. Once a user exports, downloads, or prints content, that copy is outside OPFS and outside the Studio's retention controls.
Browser support strategy
Chrome and Microsoft Edge are first-class test targets. Brave, Vivaldi, Opera, and other Chromium browsers are compatibility targets when they provide the required Manifest V3 scripting and OPFS APIs. Capability detection is preferred over user-agent assumptions.
A shared Chromium engine does not guarantee identical extension policy, storage quota, persistence, partitioning, protected pages, DevTools behavior, or PDF tools. Compatibility reports should include the browser and version, operating system, page origin shape, and the unavailable capability—without including private OPFS content.
Deliberate non-goals
- No remote database, account system, telemetry pipeline, or automatic cloud synchronization.
- No claim to bypass browser origin isolation, protected pages, enterprise policy, or user permission.
- No bundled PDF renderer or promise of identical PDF editing controls across Chromium builds.
- No claim that DBOPFS application folders isolate hostile same-origin code.
- No server-side or Node.js execution of the browser-only DBOPFS runtime.