Subject: Issue with Persistent Storage Plugins (data-store w/ sql.js, data-store-json) in Chrome Extension MV3 Service Worker (Veramo v6)

[montassar-isbored]

Hi Veramo Team & Community,

I'm working on building a browser wallet using Veramo (v6.x, latest stable packages) as a Chrome Extension with Manifest V3. The core agent logic runs inside the background Service Worker.

My goal is to create a basic Veramo agent instance that can manage DIDs (did:key) and keys (kms-local) with persistent storage that survives service worker restarts and browser sessions. I've encountered significant roadblocks with both primary persistent storage plugin approaches in this environment.

Environment:

Chrome Browser (Latest Stable)
Manifest V3 Extension
Background Script: Service Worker (type: "module")
Bundler: Webpack 5
Key Veramo Packages: @veramo/core, @veramo/key-manager, @veramo/kms-local, @veramo/did-manager, @veramo/did-provider-key, @veramo/data-store / @veramo/data-store-json, @veramo/core-types.

Attempt 1: Using @veramo/data-store (TypeORM + sql.js)

Setup: Configured DataSource with type: 'sqljs', passing the initialized sql.js module via driver, used Veramo Entities and migrations, set migrationsRun: true, synchronize: false. Configured KeyManager and DIDManager with KeyStore, DIDStore, PrivateKeyStore using the DataSource connection. Correct CSP (script-src 'self' 'wasm-unsafe-eval'; connect-src 'self';) was added to manifest.json.
Errors Encountered:
    If useLocalForage: true was set: Failed during dbConnection.initialize() with ReferenceError: window is not defined.
    If autoSave: false was set (required for potential manual persistence): Also failed during dbConnection.initialize() with ReferenceError: window is not defined.
    If both useLocalForage and autoSave were omitted/false: dbConnection.initialize() sometimes failed with TypeError: Cannot read properties of undefined (reading 'getItem'). When it did seem to initialize, subsequent calls (like agent.didManagerFind or agent.didManagerCreate) failed with QueryFailedError: no such table: identifier, indicating migrations ran but didn't persist correctly before reads. Attempts to manually sync using FS.syncfs were unsuccessful as the FS object wasn't accessible via the driver.

Attempt 2: Using @veramo/data-store-json (+ chrome.storage.local helper)

Setup: Created helper functions loadState/saveState using chrome.storage.local. Created a jsonStoreManager object holding the loaded state and a notifyUpdate callback calling saveState. Instantiated KeyStoreJson, DIDStoreJson, PrivateKeyStoreJson passing the jsonStoreManager. Instantiated DataStoreJson plugin passing jsonStoreManager. Passed KeyManager (with KeyStoreJson/PrivateKeyStoreJson), DIDManager (with DIDStoreJson), and DataStoreJson to createAgent. Removed TypeORM/sql.js/Wasm dependencies and configs.
Error Encountered: createAgent completes without throwing an error, BUT the returned agent object is missing methods from DIDManager. typeof agent.didManagerFind logs undefined, leading to TypeError: agent.didManagerFind is not a function when called.

Summary of Problem:

Neither of the standard persistent storage plugin approaches seems to function correctly out-of-the-box within the MV3 Service Worker environment. The TypeORM/sql.js path fails during initialization or has unreliable persistence, while the data-store-json path fails to correctly assemble the agent methods.

Question:

Is there a documented, recommended, or known working configuration for achieving persistent agent storage using official Veramo v6 plugins within a Manifest V3 Service Worker? Are these known limitations or bugs? Is there an alternative storage plugin specifically designed for this environment (e.g., directly using IndexedDB via Dexie/idb, or chrome.storage) that integrates correctly with createAgent?

Any guidance or examples would be greatly appreciated!

Thanks,
Montassar

[montassar-isbored]

The persistence proble; was solved using @veramo/data-store-json by creating a JSON file in which the state of the wallet data is regularly updated. The JSON is stored locally on the browser in Local.
The limit size is 10Mb but it can be further extended by modifying the storage limit on the browser.

[mirceanis]

Amazing!

BTW, the data-store-json plugin was created as a way to see if we can eventually move away from the typeorm-based data-store plugin.

In this initial version, it provides a 1:1 mapping of the API.
Next we were planning to transform it into a streaming-like engine, where the data is no longer pre-processed at store time, but at query time. This would allow us to reuse this plugin in a map-reduce kind of situation.

Someone with the bandwidth to do so could quite easily mimic the data-store-json plugin and build an IndexedDB variant, which would significantly improve performance as well as increase the data limits in browsers.

PRs welcome ;)