Plugins

Problem Statement

LBRY needs people to build new and exciting experiences on top of the LBRY Network and SDK. There is currently no simple way to go from idea to working solution that integrates with the daemon and with our desktop application. A plugin system in the daemon and in the desktop app would make it easier for people to build solutions and to make those solutions available to existing desktop users.

Requirements

• Low Friction: All you need is the binary builds of the LBRY desktop app / daemon and a simple text editor.

• Secure: Users are prompted when a plugin is enabled to authorize the permissions and actions available to the plugin. (eg, the way Android permissions work).

• Modular: UI parts and the daemon parts are decoupled. (eg. one developer could implement a comments UI and another developer can implement the comment storage; users can mix and match compatible UI / daemon plugins.)

Solution

Plugins are implemented in Python for the daemon and in JavaScript for the desktop application. They are published to the LBRY Network using the same claim mechanism as other media content. Daemon will provide all of the necessary APIs to discover, install and authorize plugins.

• Plugins are composed of JavaScript and/or Python files zipped and published as a claim with specific metadata to the LBRY blockchain.

• Daemon will bundle a bunch of standard plugins by default.

Discovery

A plugin is a claim on the LBRY network just like any other content. Desktop app would have a UI for searching and requesting to have plugin installed.

Installation

1. Users discovers plugin they want to install and initiates the process.
2. Desktop app calls daemon API with plugin_id (claim_id) to being installation process.
3. Daemon downloads blobs, assembles zip file, unzips the data into plugins directory.
4. Daemon starts the Python script if there is one as a separate process.
5. Daemon exposes any JavaScript / HTML / CSS via an HTTP endpoint.
6. Daemon notifies the desktop app that the plugin is installed.
7. If the plugin had a Python script and upon starting the Python script the plugin connects to daemon to register, Daemon will send notification to desktop app listing the requested permissions, endpoints and any other details and ask the user to approve.
8. Once approved the plugin will be allowed to participate in various daemon workflows and interactions.

Security

Daemon will spawn plugin as separate process and require the plugin to connect back to the daemon via JSON-RPC to negotiate an authorization token.

1. Daemon spawns plugin as separate process.
2. Upon initial startup the plugin will request an authorization token along with the permissions it seeks.
3. Daemon will notify the desktop app of the authorization request.
4. Desktop app will prompt user and then send back the approval along with itemized permissions.
5. Daemon will generate a token and record which permissions were granted for that token and then send the token to the plugin.
6. In all future communication the plugin will include this token.
7. User can view in the desktop app which plugins/tokens are enabled and can revoke a token at any point.

Desktop app will use HTTP request to load all of the plugin assets into a restricted iframe. It should not be possible for any loaded JavaScript to craft RPC calls to the daemon. All communication between the plugin and the desktop app will occur through the DOM or explicit message passing.

Use Cases

The general workflow for daemon plugins will be to register to either intercept certain API calls (get, resolve, account_send, etc) or to receive various events (new content on channel subscription, disk is full, etc) and have some pre-determined actions it can take in response, such as:

1. Augment JSON responses sent to the desktop app (eg. inject comments / ratings into claims on resolve).
2. Augment JSON-RPC request arguments provided to the daemon from desktop (eg. automatically inject some boilerplate metadata when performing publish).
3. Cancel the interaction (eg. plugin which prevents viewing objectionable content would cancel a get).
4. Simply acknowledge an event and perform some external actions (blinking an LED on incoming payment transaction.)

Desktop app will expose locations in the UI where a plugin can display itself and will notify plugins for events for which they've registered.

No files or tests are named; start by mapping the daemon and desktop application entry points, especially the daemon API and JSON-RPC communication described here. Break the proposal into separately scoped discovery, installation, authorization, daemon, and desktop work, with completion criteria defined for each part.