Mobile plugins: Add APIs to allow file system access

[personalizedrefrigerator]

Operating system

Android/iOS

Joplin version

3.0

Mobile plugins: Provide file system and database access

Many of the plugins that fail to run on mobile do so because they lack file system access. Some need both access to an SQLite database (requested here) and access to the file system. To support these plugins on mobile, we should consider exposing these APIs.

Notes and considerations

• Ideally, these APIs should be consistent across desktop and mobile. This might be done, for example, by adding a new fs property on the joplin plugin object.
• Should there be a way to grant permission for a plugin to access the file system?
  • Doing so makes it safer to install untrusted plugins on mobile.
  • Alternatively (or, in addition to the above), plugin file system access could be restricted to a few plugin-specific directories.
• Does it make more sense to mock fs or to add a new Joplin API for file system access?
  • Mocking fs doesn't seem feasible, particularly with synchronous methods (all plugin IPC is async).
• Should we expose a real file system, or mock one using localStorage/indexedDB?
  • localStorage and indexedDB may be much faster than exposing the real file system (which is mostly app-private). It would also be more secure (and easier to clear all plugin-specific data).
  • indexedDB/localStorage would make it difficult to load/store a SQLite database file. If we expose our database driver, users will be writing to the filesystem directly. We could alternatively expose a web-based SQLite database to plugins.
    • SQLite WASM can use localStorage and the Origin-Private File System to store databases. This, however, would require bundling a large WASM file with the app.

[personalizedrefrigerator]

Fixing this issue should also allow creating and manipulating resources with plugins (e.g. to create a voice recorder plugin, as requested here).