Add support for WASM plugins (with examples) #2158

dirkwa · 2025-12-05T00:00:35Z

Add AssemblyScript plugin SDK for WASM plugin development
Support WASM plugins written in Rust, Go, .NET, and AssemblyScript
Implement Component Model bindings for SignalK API
Add plugin lifecycle management (load, start, stop, unload)
Support multiple WASM formats (Component Model, standard WASM)
Add TCP socket API for network-capable WASM plugins
Implement plugin configuration storage via plugin-config-data
Support WASM plugin HTTP endpoints and webapps
Add comprehensive documentation and example plugins
Fix Asyncify race conditions for network-capable WASM plugins
Make WASM runtime toggleable via server settings

WASM Implementation

Documentation

wasm/
├── README.md                    # Quick reference, current status
├── IMPLEMENTATION_HISTORY.md    # Detailed development history
├── WASM_PLUGIN_DEV_GUIDE.md    # Developer documentation
├── CHANGELOG.md                 # Version changelog
├── ASYNCIFY_IMPLEMENTATION.md   # Technical details on Asyncify
└── JS_TS_WASM_SUPPORT.md       # JS/TS WASM support notes

Example WASM Plugins

JS/TS

hello-assemblyscript
- showcase for deltas
weather-plugin
- showcase for as-fetch
- showcase for weather ressource-provider at /signalk/v2/api/resources/weather
signalk-logviewer (WASM)
- showcase access to files outside the sandbox and webapp
- showcase hybrid (WASM + Node.js for large I/O)
weather-provider-plugin
showcase for Weather API for WASM plugins at /signalk/v2/api/weather/*
routes-waypoints-plugin
- showcase Routes & Waypoints Resource Provider Example
  -course-provider-plugin-wasm
- schowcase for Course Provider API
- showcase for converting real world app to WASM

RUST

anchor-watch-rust
- showcase for put handler, compiled on x86, runs on arm64
- showcase for registering custom http endpoints (REST)
signalk-mayara-radar - FORK REWRITE as PROOF OF CONCEPT
- fork of Marine Yacht Radar server to WASM
- showcase for detecting Furuno DRS4D-NXT
- not for use.

GO

charts-provider-go
- showchase Charts Provider, that also emits deltas
- showcase hybrid (WASM GO for filestore and webapp, Node.js for better-sqlite3)

C# .NET

FAILED
- Wait for better tooling, Issue created.
WORKAROUND here

tkurki · 2025-12-05T17:13:44Z

As I commented earlier I don't think doing away with the need for restarts is worth the trouble, but instead what you have here is really really interesting and pushing us forward. Just the ability to run a wasm radar server demonstrates the possibilities.

Since this is such an elephant I'll probably make several review passes, so don't expect the first one include everything.

tkurki

Please npm run format and npm run lint and fix lint errors.

Prefer import over require (lint will tell you that). Prefer typing things over adding ignore comments for any complaints.

I don't think we need to add the special support for wasm debugging, especially the serverroute. If this is something that you think would be useful let's think about the general case of configuring debugging for troubleshooting different kinds of problems. for the end user something being WASM should not be of special concern. Like, why should they care?

docs/configuration/enable_wasm_debug_logs.md

empty_file

package.json

src/index.ts

src/interfaces/plugins.ts

test/wasm-plugin-regression.ts

wasm/CHANGELOG.md

wasm/WASM_PLUGIN_DEV_GUIDE.md

src/index.ts

,vscode/settings.json

dirkwa · 2025-12-06T22:56:38Z

I don't think we need to add the special support for wasm debugging, especially the serverroute. If this is something that you think would be useful let's think about the general case of configuring debugging for troubleshooting different kinds of problems. for the end user something being WASM should not be of special concern. Like, why should they care?

For WASM developers it is very helpful. It is nicely integrated and can be disbled by default:

tkurki · 2025-12-08T19:27:02Z

I appreciate the comment that you'll continue the work, but no need to comment on each item until each has been addressed.

examples/wasm-plugins/hello-assemblyscript/package.json

src/interfaces/plugins.ts

tkurki · 2025-12-08T19:35:30Z

Git technique: you are merging master to this branch, which causes extra commits that are just noise. Please read up on rebasing - in general rebasing on master is a much better option: no extra merge commits and if conflicts arise you face them early and the branch will be eventually ready for merging to master.

dirkwa · 2025-12-09T05:11:35Z

Thank you very much that you take your time and push this so much.
I am very happy about this. I have addressed all the topics from above.
Meanwhile I made great progress with the MaYaRa wasm plugin using WebGPU.
Also I added hotplug - that reduches the server restarts massively.

PR: WASM Plugin Support with Hotplug

Summary

Adds WebAssembly plugin support to Signal K Server with complete hotplug lifecycle management. WASM plugins run alongside traditional Node.js plugins with the same enable/disable, install/uninstall behavior.

Changes

Core WASM Runtime

WASM runtime (src/wasm/) - Complete runtime for loading and executing AssemblyScript plugins
Server API bindings - Plugin access to Signal K delta updates, subscriptions, storage
Plugin ID derivation - Automatic ID from npm package name (e.g., @meri-imern/signalk-anchor-watch → meri-imern-signalk-anchor-watch)
Manifest handling - wasmManifest field in package.json for WASM-specific metadata

Plugin Hotplug

Unified hotplug for both Node.js and WASM plugins
Webapp filtering - 4-layer architecture ensures disabled plugin webapps never appear in Admin UI
Route blocking - Direct URL access to disabled plugin webapps returns 404
WebSocket cache - Filtered webapps list updated at startup

SDK

AssemblyScript SDK moved into monorepo (packages/signalk-plugin-sdk-wasm/)
Standard plugin interface: start(), stop(), registerWithRouter()

Documentation

WASM plugin development guide integrated into main docs
Internal maintainer documentation (docs/internal/hotplug.md)
Radar API documentation (experimental)

Tests

Plugin hotplug filtering tests (test/plugin-hotplug.ts)
Mock-based testing without external plugin dependencies
Removed obsolete skipped tests

Examples

Example plugins renamed with example- prefix to clarify non-production status
Folder names match npm package names

Files Changed

140 files changed, 25,572 insertions, 80 deletions

Key New Files

Path	Description
`src/wasm/wasm-runtime.ts`	WASM plugin loading and lifecycle
`src/wasm/wasm-serverapi.ts`	Server API bindings for WASM
`src/wasm/wasm-storage.ts`	Plugin storage implementation
`src/wasm/wasm-subscriptions.ts`	Delta subscriptions for WASM
`packages/signalk-plugin-sdk-wasm/`	AssemblyScript SDK
`test/plugin-hotplug.ts`	Hotplug filtering tests
`docs/internal/hotplug.md`	Maintainer documentation
`docs/develop/rest-api/radar_api.md`	Radar API (experimental)

Breaking Changes

None. WASM support is enabled by default.

Testing

npm test  # 124 tests passing

tkurki · 2025-12-09T08:27:17Z

See 2eda5f0 - let’s not include the radar API in this PR. I am thrilled about the possibilities there, but want to get Kees et al involved in the discussion, that is kinda orthogonal to adding wasm support. I assume the mayara plugin will also see separate development, so splitting it to another PR with the radar API would be the best way forward imho.

.prettierignore

package/package.json

packages/server-api/wit/signalk.wit

dirkwa · 2025-12-09T17:37:57Z

As I understood you don't want me to comment every point, so I just "resolved" the ones that I have adressed and fixed. And comment on the important topics.

dirkwa · 2025-12-09T17:55:56Z

See 2eda5f0 - let’s not include the radar API in this PR. I am thrilled about the possibilities there, but want to get Kees et al involved in the discussion, that is kinda orthogonal to adding wasm support. I assume the mayara plugin will also see separate development, so splitting it to another PR with the radar API would be the best way forward imho.

I also struggled with this and wondered whether I should include it or not. In principle, we were almost in agreement, but the one open issue that he didn't respond to was whether we need a control websocket because the radar models are too different. However, we won't know the answer to that for another six months or a year, once everything has been tested and we have gained more experience.

In the coming days, I will primarily work on MayaRa and focus my attention on control, not image enhancement. Then we should see whether the API has matured enough by the time of the merge or whether we should remove it before the “final merge.”

As I see we are merging to a 3.x alpha - so even remonving from the last beta before RC would be still ok imho.

I hope you agree with this approach.

dirkwa · 2025-12-12T01:45:17Z

@tkurki

I successfully tested all functions of my furuno radar with the Radar API (v5) in the last build.
Due to it's design I am very sure that on the server side we do not need to touch it anymore.

Would love to see it merge. Let me know if you want me to change any additional things within this PR.

tkurki

Need to stop this round now, continue over the weekend.

Tried to make suggestions as much as I could to make it easy to incporporate the feedback.

This is looking mighty good!

docs/develop/plugins/wasm/README.md

docs/develop/plugins/README.md

docs/develop/plugins/wasm/README.md

docs/develop/plugins/wasm/best_practices.md

docs/develop/plugins/wasm/capabilities.md

tkurki

Next pass, more comments. Still ways to go...

src/wasm/bindings/env-imports.ts

src/wasm/bindings/mbtiles-handler.ts

src/wasm/bindings/radar-provider.ts

src/wasm/bindings/resource-provider.ts

src/wasm/bindings/signalk-api.ts

src/wasm/bindings/socket-manager.ts

docs/develop/plugins/wasm/deltas.md

src/wasm/bindings/env-imports.ts

tkurki

More review comments.

packages/server-admin-ui/src/views/Configuration/Configuration.js

packages/server-api/src/index.ts

packages/server-api/src/radarapi.ts

packages/server-api/src/serverapi.ts

src/api/streams/index.ts

src/api/streams/binary-stream-manager.ts

src/api/streams/index.ts

tkurki

It is very easy to add AI generated content, but I fear nobody will keep it up to date nor remove stale content, so let's try to be a bit leaner.

examples/wasm-plugins/example-anchor-watch-dotnet/ISSUE_REPORT.md

examples/wasm-plugins/example-anchor-watch-dotnet/README.md

tkurki

Next round...

packages/assemblyscript-plugin-sdk/CHANGELOG.md

packages/assemblyscript-plugin-sdk/README.md

packages/assemblyscript-plugin-sdk/assembly/api.ts

tkurki · 2025-12-19T15:45:16Z

packages/assemblyscript-plugin-sdk/assembly/index.ts

+ */
+
+// Export all public types and functions
+export * from './plugin'


Would it make sense to make the API granular, in the direction we are moving in with Server API, or are we happy like this? (don't have a strong opinion on this, you have much better insight here)

packages/assemblyscript-plugin-sdk/assembly/plugin.ts

packages/assemblyscript-plugin-sdk/assembly/resources.ts

packages/assemblyscript-plugin-sdk/package.json

tkurki · 2025-12-19T16:13:24Z

There's a build failure that needs addressing: https://github.com/SignalK/signalk-server/actions/runs/20374772192

dirkwa · 2025-12-19T16:27:36Z

There's a build failure that needs addressing: https://github.com/SignalK/signalk-server/actions/runs/20374772192

It was introduced by your last commit:

7f8086f

no worries, I will look into it later, want you to finish all first. 04:27am here, so still plenty of "day" left :).

tkurki · 2026-01-02T18:36:02Z

I really, really wish you had not included the hotplug mechanism in this PR. It adds complexity that is not directly connected to what I think is the core, the wasm plugin mechanism. For example there's a nontrivial amount of code to disable webapps for webapp & plugin combinations.

But what I find really odd is that the hotplug mechanism does not hotplug plugins and webapps that are installed from the App store. I would think that the most important hotplug feature: not needing to restart the server to get access to the newly added addins. Is loading newly installed addins without restart not supported? Only developers toggle things on and off, end users rarely do that.

Would it be possible to create separate PRs for the wasm support (i'm ok with including radar api, even if i would like to have that separate also) and hotplug? I would love to move forward with wasm.

Related: many parts of hotplug.md now read like a PR description, not a long term document. I am personally not very fond of repeating the application code verbatim in documents, as code may evolve and often docs are not updated. To me permanent documents should not describe in detail the steps how something was implemented, but how it works.

dirkwa · 2026-01-02T18:59:46Z

Why Hotplug Exists in the WASM PR

The hotplug mechanism was originally added for WASM plugin lifecycle management:

Toggle the WASM runtime interface on/off in server settings
Enable/disable individual WASM plugins without restart
Handle WASM plugin crashes with automatic recovery

Your Observation is Correct - But There's an Opportunity

You're right that the current hotplug doesn't support "install and use immediately" for App Store plugins. However, here's what's interesting: WASM plugins CAN support this - the infrastructure exists:

discoverAndRegisterWasmPlugins() can re-scan node_modules/ at runtime
WASM modules are loaded dynamically (no Node.js require() cache issues)
This is currently triggered only on interface toggle, but could be triggered after App Store install

Node.js plugins cannot easily support this due to module caching and Express route registration at startup.

Proposal

Option A: Make "Install & Use Immediately" a WASM Advantage

Wire up App Store install completion to trigger WASM plugin discovery
This makes hotplug a core WASM feature, not separate complexity
End users get immediate value from WASM plugins
Justifies keeping hotplug in the WASM PR

Option B: Split the PR as You Requested

Extract hotplug into a separate PR
Keep only minimal WASM lifecycle (start/stop/toggle)
Lose the "install & use immediately" opportunity

Which direction would you prefer?

Regarding Node.js Plugin Hotplug

The Node.js hotplug (enable/disable without restart) was added for uniformity - same behavior for both plugin types. We can remove it if you prefer WASM-only scope.

Regarding Documentation

Agreed - hotplug.md reads like a PR description. We'll rewrite it as a technical reference focused on "how it works" rather than implementation steps.

tkurki

I've now tested the assemblyscript example webapps but they failed. The faults don't seem serious. I wonder if there should be a test that compiles them (at least the easy ones with npm based build), starts the server and asserts they are present?

I've also looked a bit into the hotplug infrastructure code. To be honest I think the hotplug is not keeping the core lean. It seems like Claude implemented it piecemeal and the result is not as clear as it could be. The logic seems to be spread in many spots over the codebase. I think that needs rework: after all there are just a few operations that actually change what plugins and webapps are available:

initial plugins and webapps registering & enablement
plugin enable/disable
install / uninstall of plugins and webapps

Modifying the app 'splugins and webapps properties is imho a bad idea: I think the code would be easier to understand if we either

always filter on the fly to app properties to get enabled ones
keep separate data structures for all and enabled ones

The preexisting code is a bit weird, because it started as webapps and plugins being totally separate, but now that line has blurred. I think a single data structure holding both would be better. Room for improvement.

I am not totally against hotplug, but imho it should start from the users' perspective, where the main painpoints afaik are requiring restart for

new plugin/webapp installs (solvable)
uninstalls (partly solvable)
updates (not solvable for plugin routes, webapps ok)

(At this point I read your reply to my separate comment)
I think we should split the PR, not include any hotplug features, and then armed with the knowledge gained here reimplement the parts of hotplug that are feasible, from scratch with a bit better code organisation.

src/index.ts

examples/wasm-plugins/example-hello-assemblyscript/package.json

examples/wasm-plugins/example-routes-waypoints/package.json

src/index.ts

src/interfaces/webapps.js

examples/wasm-plugins/example-hello-assemblyscript/package.json

tkurki

The new package assemblyscript-plugin-sdk needs to be included in container build from master and in release workflows.

In master container build packages are built and stored as build artifacts so that the container build step can use them, as they have not yet been published in npm.

https://github.com/SignalK/signalk-server/blob/master/.github/workflows/build-docker.yml#L23-L39

Release workflow checks the packages' versions against npm and publishes new versions as needed.

https://github.com/SignalK/signalk-server/blob/master/.github/workflows/release.yml

tkurki

Making progress, I see "Hello from AssemblyScript!" in my DataBrowser!

Some more details to tweak.

.npmignore

README.md

packages/assemblyscript-plugin-sdk/package.json

docs/develop/plugins/wasm/deltas.md

packages/assemblyscript-plugin-sdk/assembly/signalk.ts

src/api/radar/openApi.ts

- Add AssemblyScript plugin SDK for WASM plugin development - Support WASM plugins written in Rust, Go, .NET, and AssemblyScript - Implement Component Model bindings for SignalK API - Add plugin lifecycle management (load, start, stop, unload) - Support multiple WASM formats (Component Model, standard WASM) - Add TCP socket API for network-capable WASM plugins - Implement plugin configuration storage via plugin-config-data - Support WASM plugin HTTP endpoints and webapps - Add comprehensive documentation and example plugins - Fix Asyncify race conditions for network-capable WASM plugins - Make WASM runtime toggleable via server settings

tkurki · 2026-01-08T20:07:54Z

I think we are in a good enough shape with this. The commit log is not worth keeping and I don't want 100+ tweakthisandthat commits in master, so I'd like to split this to two commits. I don't really care if the split is 100% accurate or that they are 100% independent, but would be still good practise imho.

This is how Claude would split it: https://github.com/tkurki/signalk-server/pull/new/WASM_WASIX-split

How would you like to proceed? This is your work, so don't want my name on it.

dirkwa · 2026-01-09T01:24:21Z

This is how Claude would split it: https://github.com/tkurki/signalk-server/pull/new/WASM_WASIX-split

How would you like to proceed? This is your work, so don't want my name on it.

No worries @tkurki, I think in reality you spent at least as much time on it as I did.
Feel free to publish it your way. Happy to see that we are going a massive step forward here.

dirkwa · 2026-01-09T03:09:59Z

Good news!

C# for WASM might work soon.

bytecodealliance/wit-bindgen#1489 (comment)

tkurki · 2026-01-09T19:09:08Z

Docker build is failing https://github.com/SignalK/signalk-server/actions/runs/20862210828/job/59944659181.

tkurki · 2026-01-09T19:37:00Z

Fixed in fd61431

msallin · 2026-01-09T21:56:16Z

🚀 🚀 🚀

tkurki changed the title ~~new: Add WASM functionality to Signal K including examples~~ Add support for WASM plugins (with examples) Dec 5, 2025

tkurki reviewed Dec 5, 2025

View reviewed changes

tkurki added the feature label Dec 5, 2025

tkurki reviewed Dec 5, 2025

View reviewed changes

,vscode/settings.json Outdated Show resolved Hide resolved

tkurki reviewed Dec 8, 2025

View reviewed changes

examples/wasm-plugins/hello-assemblyscript/package.json Outdated Show resolved Hide resolved

tkurki reviewed Dec 8, 2025

View reviewed changes

src/interfaces/plugins.ts Show resolved Hide resolved

dirkwa force-pushed the WASM_WASIX branch from 68dbc8a to a661c5c Compare December 9, 2025 05:08

tkurki reviewed Dec 9, 2025

View reviewed changes

.prettierignore Show resolved Hide resolved

tkurki reviewed Dec 9, 2025

View reviewed changes

package/package.json Outdated Show resolved Hide resolved

tkurki reviewed Dec 9, 2025

View reviewed changes

packages/server-api/wit/signalk.wit Outdated Show resolved Hide resolved

dirkwa force-pushed the WASM_WASIX branch from d430542 to 6bff91a Compare December 11, 2025 23:13

tkurki reviewed Dec 12, 2025

View reviewed changes

dirkwa force-pushed the WASM_WASIX branch from 6bff91a to d4998c1 Compare December 13, 2025 01:37

tkurki reviewed Dec 13, 2025

View reviewed changes

tkurki reviewed Dec 14, 2025

View reviewed changes

docs/develop/plugins/wasm/deltas.md Outdated Show resolved Hide resolved

tkurki reviewed Dec 14, 2025

View reviewed changes

src/wasm/bindings/env-imports.ts Outdated Show resolved Hide resolved

tkurki reviewed Dec 17, 2025

View reviewed changes

dirkwa force-pushed the WASM_WASIX branch from d59b7b0 to 9891608 Compare December 17, 2025 20:22

tkurki reviewed Dec 19, 2025

View reviewed changes

examples/wasm-plugins/example-anchor-watch-dotnet/ISSUE_REPORT.md Outdated Show resolved Hide resolved

examples/wasm-plugins/example-anchor-watch-dotnet/README.md Show resolved Hide resolved

tkurki reviewed Dec 19, 2025

View reviewed changes

dirkwa changed the title ~~Add support for WASM plugins (with examples)~~ Add support for WASM plugins (with examples), Radar API, Plugin Lifecycle Dec 20, 2025

This was referenced Dec 22, 2025

Trusted reverse proxy mode #2180

Closed

RFC: Plugin Lifecycle, BLE Architecture, and External Runtime Strategy #2186

Closed

tkurki force-pushed the WASM_WASIX branch from 3636063 to 0af2da6 Compare January 1, 2026 18:30

dirkwa force-pushed the WASM_WASIX branch from 0af2da6 to a8a8493 Compare January 1, 2026 21:23

tkurki reviewed Jan 2, 2026

View reviewed changes

dirkwa force-pushed the WASM_WASIX branch from a8a8493 to 48c3a78 Compare January 4, 2026 17:37

tkurki reviewed Jan 4, 2026

View reviewed changes

examples/wasm-plugins/example-hello-assemblyscript/package.json Outdated Show resolved Hide resolved

tkurki requested changes Jan 4, 2026

View reviewed changes

tkurki reviewed Jan 5, 2026

View reviewed changes

.npmignore Outdated Show resolved Hide resolved

README.md Show resolved Hide resolved

packages/assemblyscript-plugin-sdk/package.json Outdated Show resolved Hide resolved

docs/develop/plugins/wasm/deltas.md Outdated Show resolved Hide resolved

dirkwa requested a review from tkurki January 6, 2026 02:14

tkurki reviewed Jan 6, 2026

View reviewed changes

docs/develop/plugins/wasm/deltas.md Outdated Show resolved Hide resolved

packages/assemblyscript-plugin-sdk/assembly/signalk.ts Outdated Show resolved Hide resolved

packages/assemblyscript-plugin-sdk/assembly/signalk.ts Show resolved Hide resolved

tkurki reviewed Jan 7, 2026

View reviewed changes

src/api/radar/openApi.ts Outdated Show resolved Hide resolved

tkurki force-pushed the WASM_WASIX branch from 3fe7391 to b5dede2 Compare January 9, 2026 18:47

tkurki changed the title ~~Add support for WASM plugins (with examples), Radar API, Plugin Lifecycle~~ Add support for WASM plugins (with examples) Jan 9, 2026

tkurki merged commit 0494486 into SignalK:master Jan 9, 2026
5 checks passed

tkurki mentioned this pull request Jan 9, 2026

feat: Add Radar API for radar device control #2242

Merged

Uh oh!

Add support for WASM plugins (with examples) #2158

Add support for WASM plugins (with examples) #2158

Uh oh!

Conversation

dirkwa commented Dec 5, 2025 • edited by tkurki Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

WASM Implementation

Documentation

Example WASM Plugins

JS/TS

RUST

GO

C# .NET

Uh oh!

tkurki commented Dec 5, 2025

Uh oh!

tkurki left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dirkwa commented Dec 6, 2025

Uh oh!

tkurki commented Dec 8, 2025

Uh oh!

Uh oh!

Uh oh!

tkurki commented Dec 8, 2025

Uh oh!

dirkwa commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR: WASM Plugin Support with Hotplug

Summary

Changes

Core WASM Runtime

Plugin Hotplug

SDK

Documentation

Tests

Examples

Files Changed

Key New Files

Breaking Changes

Testing

Uh oh!

tkurki commented Dec 9, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dirkwa commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dirkwa commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dirkwa commented Dec 12, 2025

Uh oh!

tkurki left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dirkwa commented Dec 5, 2025 •

edited by tkurki

Loading

dirkwa commented Dec 9, 2025 •

edited

Loading

dirkwa commented Dec 9, 2025 •

edited

Loading

dirkwa commented Dec 9, 2025 •

edited

Loading

dirkwa commented Dec 19, 2025 •

edited

Loading

tkurki left a comment •

edited

Loading