Tidenda
Start free

Plugins

What a plugin can add, how versions are published and pinned, and what a plugin is trusted with.

On this page

A plugin adds to the Tidenda application without being part of it: a view, a main-menu destination, an action on a document, a settings section. Approved publishers publish plugins, and each organisation decides which ones it runs. For reviewers, administrators and plugin developers.

What a plugin can contribute

A plugin works through the same extension points as the application's own features:

  • Views, with their own address, so a link to a plugin view opens it directly.
  • Main-menu destinations that open those views.
  • Actions on documents and elsewhere, shown in menus and in the command palette alongside the built-in ones.
  • Settings sections for its own configuration.

A plugin looks and behaves like the rest of the application: it uses the same components and the same theme, and follows the light and dark modes.

Publishers and versions

Only approved publishers can publish to the platform's plugin registry. No API accepts plugin code, and an organisation cannot upload code of its own.

Every plugin has a stable identifier in reverse-DNS form, such as com.dotvoid.hello, and a sequence of versions numbered with semantic versioning. A published version never changes. Fixing or extending a plugin means publishing a new version; the old one stays exactly as it was. There is no unpublish.

Enabling is per organisation, and pinned

Plugins are off until an administrator enables one for their organisation. Enabling picks one specific version. That version keeps running until an administrator chooses another, so a newly published version never reaches an organisation unannounced.

Enabling, updating and disabling take effect the next time each user loads the application.

Each version records the application interface version it was built for, and the application never loads a version built for an incompatible one; the rule is in the Plugin reference.

How a plugin is loaded

When a user opens the application, before anything is shown, the application:

  1. Asks which plugin versions the user's organisation has enabled.
  2. Skips any version built for an incompatible interface, without downloading its code.
  3. Downloads the plugin's code and checks it against the digest recorded when the version was published. Code that does not match is not run.
  4. Loads the plugin's stylesheets, each checked against its own recorded digest.
  5. Runs the plugin, which registers what it contributes.

What a plugin is trusted with

A plugin runs inside the application, in the user's browser, with the signed-in user's session. Within that boundary it is trusted as much as the application itself, so every layer around it is constrained:

  • The user's access, and no more. A plugin reaches documents and settings through the same interfaces as the application, under the same organisation boundary and the same role checks. It gains no permission the user does not hold, and it cannot see another organisation's data.
  • No credentials. A plugin receives the user's identity, never their access token or session.
  • Approved publishers only. Publishing is restricted to approved publishers, and runs on the platform's own server.
  • Immutable, checked code. Versions never change, and code and stylesheets that differ from what was published are not run.
  • One origin. All plugin code and styles are served from the application's own address, only to signed-in users. The application's security policy allows scripts from that address and nowhere else.
  • The organisation decides. Each organisation chooses which plugins and which versions it runs.
  • Failure stays contained. A plugin that fails any loading step is left out, and the application starts without it. Plugins that have not loaded after a few seconds are left out of that session. A plugin view that fails while in use shows an error in its place; the rest of the application keeps working.