Community plugins and a built-in plugin store (Vencord-style, but first-class) #66

New issue

Open

opened 2026-10-06 20:53:46 +00:00 by robocub · 0 comments

robocub commented

2026-10-06 20:53:46 +00:00

Member

Goal: people can write plugins that add features to Vommet, and users can browse, install, update and remove them from inside the app, like Vencord's plugins but built in and supported: no patching, no client-mod ToS worries, no breakage when the app updates.

Constraints that shape the design

Flutter can't load arbitrary Dart at runtime (release builds are ahead-of-time compiled). Plugins need a runtime inside the app:
- WebAssembly (e.g. wasmtime/wasmer through our Rust library rust_lib_commet): sandboxed by default, any source language, works the same on desktop and Android. Strong candidate.
- JavaScript (embedded QuickJS, or a hidden webview): the biggest plugin-author pool, and closest to Vencord authors' skills.
- Lua: tiny and simple, but a smaller ecosystem.
Security is the main risk. A plugin inside a Matrix client could otherwise read every message and use the account and its encryption keys. So the design is capability-based, with nothing allowed by default:
- Each plugin declares permissions (e.g. "read messages in rooms you open", "send messages", "add a slash command", "change how messages render", "network access to example.com"), shown before install and revocable later.
- Never expose access tokens or crypto keys. Plugins call a narrow host API; Vommet does the actual Matrix work.
- Plugins can't touch the filesystem, and network access only goes to declared hosts.
Distribution rules: sideloaded Linux/Windows builds are fine. Android outside Google Play is fine (F-Droid may flag it as an anti-feature). Apple and Google Play restrict downloading executable code, which is one more reason to prefer a sandboxed interpreter/VM. Decide this before any store listing.

Building blocks that exist

Matrix widgets already run in Vommet (upstream #830), including a privileged widget runner (client/matrix/widget/privelidged_matrix_widget_runner.dart) with a capability-request flow. Plugins with a UI could reuse that permission model, and simple UI plugins could literally be widgets.
Theme files can already be loaded (the + button in Appearance), a precedent for user-supplied content.

Plugin API (first cut)

Slash commands (/roll, /translate…).
Message transforms on render (e.g. Discord-style timestamps (upstream #921), inline translations (upstream #872)) and on send.
Context-menu actions on messages, users and rooms.
A settings page per plugin (declarative: toggles, text fields, choices).
Event hooks (message received, room opened, call joined) with the declared permissions.

Store

Index: a git repository (on nether.codes) with one manifest per plugin: name, author, version, permissions, source URL, checksum. Vommet fetches the index, and adding a plugin is a pull request, which gets review.
In-app: browse, search, install, update, disable, remove. Show permissions and source link before install. Updates that ask for new permissions need re-approval.
Trust: reviewed plugins vs "unreviewed / install from URL" with a clear warning, plus a kill switch to remotely disable a plugin found to be malicious.
Sync (later): installed-plugin list in account data so a second device can offer the same plugins.

Phases

Pick the runtime (prototype WASM through rust_lib_commet vs embedded JS), then design the host API and permission manifest.
Local plugins (load from a file) with 2-3 example plugins, e.g. timestamps, /shrug-style commands, a message-transform demo.
Store index repo + in-app browser + updates.
Review process, signing and kill switch before advertising it widely.

Upstream: no Commet issue or branch about plugins (searched 2026-10-06).

Goal: people can write plugins that add features to Vommet, and users can browse, install, update and remove them from inside the app, like Vencord's plugins but **built in and supported**: no patching, no client-mod ToS worries, no breakage when the app updates. ## Constraints that shape the design - **Flutter can't load arbitrary Dart at runtime** (release builds are ahead-of-time compiled). Plugins need a runtime inside the app: - **WebAssembly** (e.g. wasmtime/wasmer through our Rust library `rust_lib_commet`): sandboxed by default, any source language, works the same on desktop and Android. Strong candidate. - **JavaScript** (embedded QuickJS, or a hidden webview): the biggest plugin-author pool, and closest to Vencord authors' skills. - **Lua**: tiny and simple, but a smaller ecosystem. - **Security is the main risk.** A plugin inside a Matrix client could otherwise read every message and use the account and its encryption keys. So the design is capability-based, with nothing allowed by default: - Each plugin declares permissions (e.g. "read messages in rooms you open", "send messages", "add a slash command", "change how messages render", "network access to example.com"), shown before install and revocable later. - Never expose access tokens or crypto keys. Plugins call a narrow host API; Vommet does the actual Matrix work. - Plugins can't touch the filesystem, and network access only goes to declared hosts. - **Distribution rules:** sideloaded Linux/Windows builds are fine. Android outside Google Play is fine (F-Droid may flag it as an anti-feature). Apple and Google Play restrict downloading executable code, which is one more reason to prefer a sandboxed interpreter/VM. Decide this before any store listing. ## Building blocks that exist - **Matrix widgets** already run in Vommet (upstream #830), including a privileged widget runner (`client/matrix/widget/privelidged_matrix_widget_runner.dart`) with a capability-request flow. Plugins with a UI could reuse that permission model, and simple UI plugins could literally be widgets. - **Theme files** can already be loaded (the + button in Appearance), a precedent for user-supplied content. ## Plugin API (first cut) - Slash commands (`/roll`, `/translate`…). - Message transforms on render (e.g. Discord-style timestamps (upstream #921), inline translations (upstream #872)) and on send. - Context-menu actions on messages, users and rooms. - A settings page per plugin (declarative: toggles, text fields, choices). - Event hooks (message received, room opened, call joined) with the declared permissions. ## Store - **Index:** a git repository (on nether.codes) with one manifest per plugin: name, author, version, permissions, source URL, checksum. Vommet fetches the index, and adding a plugin is a pull request, which gets review. - **In-app:** browse, search, install, update, disable, remove. Show permissions and source link before install. Updates that ask for new permissions need re-approval. - **Trust:** reviewed plugins vs "unreviewed / install from URL" with a clear warning, plus a kill switch to remotely disable a plugin found to be malicious. - **Sync (later):** installed-plugin list in account data so a second device can offer the same plugins. ## Phases 1. Pick the runtime (prototype WASM through `rust_lib_commet` vs embedded JS), then design the host API and permission manifest. 2. Local plugins (load from a file) with 2-3 example plugins, e.g. timestamps, `/shrug`-style commands, a message-transform demo. 3. Store index repo + in-app browser + updates. 4. Review process, signing and kill switch before advertising it widely. Upstream: no Commet issue or branch about plugins (searched 2026-10-06).

robocub added the

feature

effort: large

labels

2026-10-06 20:53:46 +00:00