Jami Plugins Store in the Client

NOTE: This page describes how the Jami plugin store works and how to use it.

The Jami team has introduced plugins as a call/chat feature for GNU/Linux, Windows, and Android, providing users with the ability to personalize their call/chat experience. If you want to learn more about Jami plugins, please refer to the Jami Plugins Page.

To enhance the plugin ecosystem, the Jami team has decided to include a Jami plugin store where they can distribute both their own plugins and third-party plugins. However, before a third party can add a plugin to the store, they must request a certificate signed by the certificate authority. For more information about plugin store certificates, please see Jami Plugins Certification.

The Jami daemon and client are responsible for verifying, installing, and managing new plugins in the device’s environment. Both the daemon and the client fetch new plugins, display them, verify their authenticity, and install them. Jami already has the capability to display and install plugins.

Please let me know if you need any further improvements or specific spell checks.

Jami Plugin Store in the Daemon

The daemon is responsible for verifying each file of the plugins and determining whether the client can install it or not.

To verify the plugin, it must contain the plugin certificate and a file containing all the signatures of each file.

The content of the file is a representation of a map, where the path is the key and the hash of the target file is the value. The client sends the path to the plugin.

The daemon extracts the plugin, reads the certificate, verifies the certificate chain, checks if the certificate has been revoked by making a request to an OCSP server.

It then reads each file and its signature to verify the file. If the certificate is verified and all signatures are valid, the plugin can be installed.

Jami Plugin in Client

The client is responsible for downloading plugins, communicating the path of the downloaded JPL file, displaying the plugin store, and providing information about plugins.

The client sends requests to the plugin store server to update information about the plugins, download plugins, and retrieve the list of available plugins. It then displays the plugins according to the specification.

For example, a typical use case for the plugin store is when the client wants to manage their plugins. The client fetches all the information about the plugins and can request more details about a specific plugin.

If the client decides to download a plugin, it sends a request to the plugin store API to obtain the plugin resource. The client then requests the daemon to install the plugin. The daemon verifies the plugin using the certificate chain and the signatures of all files contained in the plugin.

If the certificate and file signatures are verified correctly, the daemon proceeds with the installation. If not, the plugin archive is removed, and an error message is returned to the client.

Plugin State

When a user wants to install a plugin, a visual trigger should be displayed to show the stage of the plugin installation.

The plugin can be in one of three states: installed, installing, or downloading. To handle all of these cases, a state machine is used to represent all the states of the plugin and the transitions between them. The network manager and update manager for Windows have been refactored to handle all the states of the plugin during the download process.

A routine is triggered each days to check if a plugin is not up to date. The plugin version manager allow us to check and update if necessary plugins.