Remove legacy plugin stubs; make @extism/extism WASM system canonical by Copilot · Pull Request #34 · Psyborgs-git/vloop.app

Copilot · 2026-03-06T01:37:42Z

Original prompt

Remove all other extensions/plugin systems from our codebase, making the @extism/extism based plugin system canonical. Document plugin usage well and also provide examples of creating plugins, and with a thorough cleanup remove all stale/legacy code for plugins or extensions.

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

…e docs and examples Co-authored-by: Psyborgs-git <49641518+Psyborgs-git@users.noreply.github.com>

Copilot

Pull request overview

This PR removes legacy non-Wasm “plugin” stubs and makes the @extism/extism-based WebAssembly plugin system in @orch/plugin-manager the sole canonical extension mechanism, with updated docs and new/updated example plugins.

Changes:

Deletes unused TypeScript “plugin” stub packages (Telegram/WhatsApp) and a stale zip artifact.
Wires Events/Vault host-function plumbing into PluginSandbox/PluginManager (including event delivery via on_event).
Rewrites plugin documentation and adds a Rust example plugin (plus refreshes the AssemblyScript “hello world” example).

Reviewed changes

Copilot reviewed 17 out of 22 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
vitest.config.ts	Adds missing Vitest aliases for shared subpath imports.
packages/plugin-manager/src/sandbox.ts	Exposes `vault_` and `events_` host functions and cleans up event subscriptions on close.
packages/plugin-manager/src/manager.ts	Instantiates Vault/Events host functions and late-binds event delivery to `on_event`.
packages/plugin-manager/src/app.ts	Optionally resolves VaultStore/EventBus from DI to enable related host functions.
plugins/whatsapp/src/index.ts	Removes legacy non-Wasm stub.
plugins/whatsapp/package.json	Removes legacy non-Wasm stub package metadata.
plugins/telegram/src/index.ts	Removes legacy non-Wasm stub.
plugins/telegram/package.json	Removes legacy non-Wasm stub package metadata.
packages/daemon/tsconfig.tsbuildinfo	Updates a generated build artifact (should not be committed).
hello-world.zip	Removes stale build artifact.
extensions/rust-example-plugin/src/lib.rs	Adds a Rust example plugin demonstrating logging + events.
extensions/rust-example-plugin/plugin.json	Adds manifest/permissions for the Rust example plugin.
extensions/rust-example-plugin/README.md	Adds usage documentation for the Rust example plugin.
extensions/rust-example-plugin/Cargo.toml	Adds Rust crate config for the example plugin.
extensions/hello-world-plugin/src/index.ts	Updates AssemblyScript example and commentary.
extensions/hello-world-plugin/README.md	Rewrites AssemblyScript example docs and install flow.
docs/index.md	Updates docs homepage wording to reflect Wasm plugins.
docs/getting-started/plugin.md	Rewrites plugin getting-started guide (Rust + AssemblyScript).
docs/features/plugins.md	Rewrites plugin architecture/permissions/host function reference and security model.

Comments suppressed due to low confidence (1)

packages/plugin-manager/src/manager.ts:128

The on_start call result is being used as a truthiness check (if (await sandbox.call('on_start') ...)). PluginSandbox.call() returns a string; if the plugin returns an empty string (common for void lifecycle functions), this condition will be false even though on_start executed successfully. Call on_start for its side effects and log success based on the call completing, not based on its output; if you want “optional if exists”, detect the specific “missing export” error instead.

        // Optional: Call an 'on_start' function if it exists?
        // For now, we just load it.
        this.logger.info({ pluginId: record.id }, 'Plugin loaded');

        if (await sandbox.call('on_start').catch(() => false)) {
            this.logger.info({ pluginId: record.id }, 'Plugin on_start executed');
        }

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

Copilot · 2026-03-06T09:47:27Z

packages/plugin-manager/src/sandbox.ts

+                                } catch (err: any) {
+                                    pluginLogger.warn({ err, topic }, 'events_subscribe failed');
+                                    callContext.setError(err.message);
+                                    return callContext.store(`{"error":${JSON.stringify(err.message)}}`);
+                                }


In the events_subscribe error path, err.message can be undefined/non-string (e.g., thrown value is a string). JSON.stringify(err.message) can then evaluate to undefined, producing invalid JSON like {"error":undefined} and also passing undefined into callContext.setError(). Normalize to a string (e.g., err instanceof Error ? err.message : String(err)) before using it and always JSON-escape the resulting message.

Copilot · 2026-03-06T09:47:28Z

packages/plugin-manager/src/sandbox.ts

+                            events_publish: (callContext: CallContext, topicOffset: bigint, payloadOffset: bigint) => {
+                                if (!eventsHost) {
+                                    callContext.setError('No events host functions available');
+                                    return callContext.store('{"error":"No events host functions available"}');
+                                }
+                                const topic = callContext.read(topicOffset)?.string() ?? '';
+                                const payload = callContext.read(payloadOffset)?.string() ?? '';
+                                try {
+                                    eventsHost.publish(topic, payload);
+                                    return callContext.store('{"ok":true}');


events_publish is documented/declared as permission-gated (events:publish), but neither this wrapper nor EventsHostFunctions.publish() enforces that permission (it only enforces the plugin.<id>.* namespace). This currently allows a plugin without events:publish to publish events. Add an explicit permission check for events:publish (ideally in EventsHostFunctions.publish(), so all callers are covered).

Copilot · 2026-03-06T09:47:28Z

extensions/hello-world-plugin/README.md

+| `log_info(ptr)` | Log a UTF-16 string at `ptr` at INFO level |
+| `__newString(str)` | AssemblyScript runtime helper — allocates `str` and returns its address |


This README claims log_info(ptr) logs a UTF-16 string allocated by __newString. The current host implementation reads strings via callContext.read(offset)?.string(), which expects an Extism-formatted string buffer (generally UTF-8 bytes in an Extism memory block), not an AssemblyScript runtime string. Please update the README to match the actual ABI/encoding (or update the AssemblyScript example to use an Extism-compatible guest SDK/allocation scheme).

Suggested change

| `log_info(ptr)` | Log a UTF-16 string at `ptr` at INFO level |

| `__newString(str)` | AssemblyScript runtime helper — allocates `str` and returns its address |

| `log_info(ptr)` | Log at INFO level the UTF-8 string stored in an Extism-formatted string buffer starting at `ptr` |

| `__newString(str)` | AssemblyScript runtime helper — allocates `str` as a UTF-16 string in the AssemblyScript heap. This pointer is **not** directly compatible with `log_info`; use an Extism guest SDK helper that allocates Extism-formatted UTF-8 strings when passing data to the host. |

Copilot · 2026-03-06T09:47:31Z

docs/getting-started/plugin.md

+declare function log_info(ptr: usize): void;
+
+@external("extism:host/user", "events_subscribe")
+declare function events_subscribe(topicPtr: usize): usize;
+
+// AssemblyScript memory helper — allocates a UTF-16 string
+// and returns its linear-memory address as a u32.
+declare function __newString(str: string): usize;
+
+/** Called once when the plugin is loaded. */
+export function on_start(): void {
+  const msg = __newString("my-as-plugin started!");
+  log_info(msg);
+
+  // Subscribe to a system event
+  const topic = __newString("container.started");
+  events_subscribe(topic);
+}
+
+/** Called whenever a subscribed event fires. */
+export function on_event(payloadPtr: usize): void {
+  log_info(payloadPtr); // payload is already a string pointer


The AssemblyScript example uses __newString (AssemblyScript UTF-16 runtime strings) and passes the pointer directly to log_info / events_subscribe, and it defines on_event(payloadPtr: usize) as if the host passes a string pointer. The current host side reads arguments using callContext.read(offset)?.string() and invokes guest exports via plugin.call(funcName, inputString), which are Extism ABI conventions rather than raw AssemblyScript string pointers. Please adjust this guide to use an Extism-compatible guest SDK for AssemblyScript (or clearly document the required ABI/encoding) so the example matches the real runtime behavior.

Suggested change

declare function log_info(ptr: usize): void;

@external("extism:host/user", "events_subscribe")

declare function events_subscribe(topicPtr: usize): usize;

// AssemblyScript memory helper — allocates a UTF-16 string

// and returns its linear-memory address as a u32.

declare function __newString(str: string): usize;

/** Called once when the plugin is loaded. */

export function on_start(): void {

const msg = __newString("my-as-plugin started!");

log_info(msg);

// Subscribe to a system event

const topic = __newString("container.started");

events_subscribe(topic);

}

/** Called whenever a subscribed event fires. */

export function on_event(payloadPtr: usize): void {

log_info(payloadPtr); // payload is already a string pointer

// Example using an Extism-compatible AssemblyScript SDK.

// The SDK is responsible for encoding/decoding strings to the Extism ABI,

// so we work only with AssemblyScript `string` values here.

import { Host, inputString } from "@extism/as-sdk";

/** Called once when the plugin is loaded. */

export function on_start(): void {

Host.logInfo("my-as-plugin started!");

// Subscribe to a system event via an Extism host function.

// The SDK handles converting this AssemblyScript string into

// the UTF-8/Extism representation expected by the host.

Host.call("extism:host/user", "events_subscribe", "container.started");

}

/** Called whenever a subscribed event fires.

* The host invokes this export via `plugin.call("on_event", payload)`,

* where `payload` is provided as the Extism input buffer.

* `inputString()` reads that buffer as a UTF-8 AssemblyScript string.

*/

export function on_event(): void {

const payload = inputString();

Host.logInfo(payload);

Copilot · 2026-03-06T09:47:33Z

extensions/rust-example-plugin/src/lib.rs

+//                   events:publish
+
+use extism_pdk::*;
+use serde::{Deserialize, Serialize};


Serialize is imported but not used in this example (use serde::{Deserialize, Serialize};). This will trigger an unused-import warning (and may fail CI if warnings are denied). Remove Serialize or use it.

Suggested change

use serde::{Deserialize, Serialize};

use serde::Deserialize;

Copilot · 2026-03-06T09:47:35Z

packages/plugin-manager/src/sandbox.ts

+                                pluginLogger.warn({ key }, 'vault_read called; async host functions require runInWorker+JSPI');
+                                callContext.setError('Async vault_read requires JSPI support');
+                                return callContext.store('{"error":"Async vault_read requires JSPI support"}');
+                            },
+                            vault_write: (callContext: CallContext, keyOffset: bigint, _valueOffset: bigint) => {
+                                // _valueOffset intentionally unused: async vault writes require JSPI support.
+                                // The key is logged for diagnostics; value is not read to avoid leaking secrets.
+                                if (!vaultHost) {
+                                    callContext.setError('No vault host functions available');
+                                    return callContext.store('{"error":"No vault host functions available"}');
+                                }
+                                const key = callContext.read(keyOffset)?.string() ?? '';
+                                pluginLogger.warn({ key }, 'vault_write called; async host functions require runInWorker+JSPI');


vault_read/vault_write currently log the vault key (pluginLogger.warn({ key }, ...)). Vault key names can be sensitive metadata, and this also contradicts the documentation claim that vault keys are never logged. Consider removing the key from logs (or logging only a redacted/hash form) and rely on pluginId + permission checks for diagnostics.

Suggested change

pluginLogger.warn({ key }, 'vault_read called; async host functions require runInWorker+JSPI');

callContext.setError('Async vault_read requires JSPI support');

return callContext.store('{"error":"Async vault_read requires JSPI support"}');

},

vault_write: (callContext: CallContext, keyOffset: bigint, _valueOffset: bigint) => {

// _valueOffset intentionally unused: async vault writes require JSPI support.

// The key is logged for diagnostics; value is not read to avoid leaking secrets.

if (!vaultHost) {

callContext.setError('No vault host functions available');

return callContext.store('{"error":"No vault host functions available"}');

}

const key = callContext.read(keyOffset)?.string() ?? '';

pluginLogger.warn({ key }, 'vault_write called; async host functions require runInWorker+JSPI');

pluginLogger.warn('vault_read called; async host functions require runInWorker+JSPI');

callContext.setError('Async vault_read requires JSPI support');

return callContext.store('{"error":"Async vault_read requires JSPI support"}');

},

vault_write: (callContext: CallContext, keyOffset: bigint, _valueOffset: bigint) => {

// _valueOffset intentionally unused: async vault writes require JSPI support.

// The key and value are not logged to avoid leaking sensitive metadata or secrets.

if (!vaultHost) {

callContext.setError('No vault host functions available');

return callContext.store('{"error":"No vault host functions available"}');

}

const key = callContext.read(keyOffset)?.string() ?? '';

pluginLogger.warn('vault_write called; async host functions require runInWorker+JSPI');

Copilot · 2026-03-06T09:47:36Z

packages/daemon/tsconfig.tsbuildinfo

tsconfig.tsbuildinfo is a generated TypeScript incremental build artifact and typically should not be committed. Keeping it in the repo adds noise to PRs and can cause frequent merge conflicts. Please remove this file from version control and add it to the appropriate .gitignore (and/or ensure build steps don’t stage it).

Copilot · 2026-03-06T09:47:37Z

extensions/hello-world-plugin/src/index.ts

+/**
+ * Allocates `str` in Wasm linear memory and returns its address.
+ * Provided by the AssemblyScript runtime; declared here so the compiler
+ * knows about it. The `usize` return keeps the types consistent.
+ */
+declare function __newString(str: string): usize;

-// The runtime helper used by AssemblyScript to allocate a string in WASM memory.
-// We declare it explicitly so that the compiler knows about it. Using `number`
-// keeps TypeScript happy in the editor, asc will still treat it as a u32.
-declare function __newString(str: string): number;
+// ── Exported lifecycle functions ──────────────────────────────────────────

-// Standard entrypoint called by the plugin manager on startup.
+/**
+ * Called once by PluginManager immediately after the plugin is loaded.
+ * Use this function for one-time initialization work.
+ */
 export function on_start(): void {
-  const msg = "Hello from TypeScript plugin!";
-  const ptr = __newString(msg);
-  log_info(ptr);
+  const msg = __newString("Hello from AssemblyScript plugin!");
+  log_info(msg);
 }


The example passes an AssemblyScript string pointer from __newString() into log_info. However, the host implementation reads the argument via callContext.read(offset)?.string(), which expects an Extism-encoded string (as produced by Extism guest SDKs like extism_pdk::Memory::from_bytes), not an AssemblyScript runtime string object. As written, this example is very likely to log garbled data or fail at runtime. Use an Extism guest SDK for AssemblyScript (or a compatible allocation/encoding approach) and document the expected encoding (typically UTF-8 bytes in an Extism memory block).

Copilot · 2026-03-06T09:47:37Z

docs/features/plugins.md

+Subscribe to or publish on the system event bus (`HooksEventBus`). When a subscribed event fires, the host will call your plugin's exported `on_event(payload: i64) -> i64` function with a JSON payload `{"topic":"...","payload":...}`.
+
+- `events_subscribe` requires `events:subscribe:<topic>` or `events:subscribe:*` permission.
+- `events_publish` requires `events:publish` permission and can only publish to the `plugin.<id>.*` namespace.
+


This doc states that events_publish requires the events:publish permission, but the current implementation of EventsHostFunctions.publish() does not check for that permission (only the plugin.<id>.* namespace is enforced). Please either enforce the permission in code or update the docs to reflect the actual policy (namespace-only).

Copilot · 2026-03-06T09:47:39Z

docs/features/plugins.md

+- Host functions validate permissions on every call.
+- Plugins cannot access the host filesystem, network, or other processes unless those capabilities are explicitly provided as host functions (currently none are).
+- The `events:publish` permission is restricted to the `plugin.<id>.*` namespace so plugins cannot impersonate system events.
+- Vault keys are never logged by the host, even in debug mode.


The security model claims “Vault keys are never logged by the host”, but the current host-side implementation logs vault keys in multiple places (e.g., vault_read/vault_write warnings and VaultHostFunctions permission-denied logs). Please either remove/redact vault key logging in code to match this guarantee, or soften/qualify this documentation statement.

Suggested change

- Vault keys are never logged by the host, even in debug mode.

- Vault keys are treated as sensitive: the host avoids logging secret values, but vault key identifiers may appear in diagnostic or permission-denied logs.

Psyborgs-git · 2026-03-07T13:13:31Z

@copilot apply changes based on the comments in this thread

…rmission, vault key logging, AS ABI, unused imports, stale tsbuildinfo Co-authored-by: Psyborgs-git <49641518+Psyborgs-git@users.noreply.github.com>

Copilot · 2026-03-07T13:20:44Z

@copilot apply changes based on the comments in this thread

Applied all review comments in b6e25bc:

Error normalization (sandbox.ts): events_subscribe/events_publish error paths now use err instanceof Error ? err.message : String(err) to guarantee a string before setError() and JSON.stringify().
Vault key logging (sandbox.ts): Removed vault key names from warn logs — neither key nor value is logged. Also dropped now-unused _keyOffset reads.
events:publish permission (host/events.ts): Added explicit events:publish permission check before the namespace check.
Unused Serialize (rust-example-plugin/src/lib.rs): Removed.
Vault permission in rust example (rust-example-plugin/plugin.json, lib.rs, README.md): Removed vault:read:example-api-key — vault functions are JSPI-gated and not demonstrated.
AssemblyScript ABI (hello-world-plugin/src/index.ts, README.md, docs/getting-started/plugin.md): Replaced __newString (AS runtime heap, incompatible with Extism memory) with Memory.fromString() from @extism/as-pdk. Added @extism/as-pdk as a devDependency and updated docs to explain why the PDK allocator is required.
Docs (docs/features/plugins.md): Corrected vault logging claim ("values never logged, key identifiers may appear in permission-denied messages") and updated events_publish description to accurately reflect the enforced permission.
tsconfig.tsbuildinfo: Removed all four files from version control (git rm --cached); .gitignore already had **/tsconfig.tsbuildinfo.

Initial plan

2d81b12

Copilot AI assigned Copilot and Psyborgs-git Mar 6, 2026

Copilot started work on behalf of Psyborgs-git March 6, 2026 01:37 View session

Copilot AI and others added 2 commits March 6, 2026 02:13

Initial plan

8a82109

feat: remove legacy plugins, wire vault/events host functions, improv…

b0da3b9

…e docs and examples Co-authored-by: Psyborgs-git <49641518+Psyborgs-git@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Remove all other extensions and make @extism/extism canonical~~ Remove legacy plugin stubs; make @extism/extism WASM system canonical Mar 6, 2026

Copilot finished work on behalf of Psyborgs-git March 6, 2026 02:29

Psyborgs-git requested a review from Copilot March 6, 2026 09:32

Copilot started reviewing on behalf of Psyborgs-git March 6, 2026 09:33 View session

Copilot AI reviewed Mar 6, 2026

View reviewed changes

Copilot started work on behalf of Psyborgs-git March 7, 2026 13:13 View session

fix: address review comments - error normalization, events:publish pe…

b6e25bc

…rmission, vault key logging, AS ABI, unused imports, stale tsbuildinfo Co-authored-by: Psyborgs-git <49641518+Psyborgs-git@users.noreply.github.com>

Copilot finished work on behalf of Psyborgs-git March 7, 2026 13:21

Psyborgs-git approved these changes Mar 7, 2026

View reviewed changes

Psyborgs-git marked this pull request as ready for review March 7, 2026 13:44

Psyborgs-git merged commit 5c3b0f2 into main Mar 7, 2026

		\| `log_info(ptr)` \| Log a UTF-16 string at `ptr` at INFO level \|
		\| `__newString(str)` \| AssemblyScript runtime helper — allocates `str` and returns its address \|

	- Vault keys are never logged by the host, even in debug mode.
	- Vault keys are treated as sensitive: the host avoids logging secret values, but vault key identifiers may appear in diagnostic or permission-denied logs.

Conversation

Copilot AI commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Psyborgs-git commented Mar 7, 2026

Uh oh!

Copilot AI commented Mar 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Mar 6, 2026 •

edited

Loading