The question
Your architecture doc is clear that the guiding rule is "OpenClaw should not own
the simplex-chat process lifecycle" — so the plugin talks to a separately-run
runtime over WebSocket instead of spawning or supervising it. That makes a lot
of sense when the runtime is a standalone simplex-chat executable: you
don't want plugin startup quietly babysitting a sidecar.
The new [simplex-chat](https://www.npmjs.com/package/simplex-chat) npm package
(the replacement for the deprecated WebRTC TS client) seems to change that
calculus: it embeds the SimpleX core in-process as a native library. There's
no separate process to own or supervise — the "runtime" becomes a function call,
not a daemon behind a socket.
So the real question for you: does the in-process model fit where you want this
plugin to go, or do you prefer to keep the explicit external-runtime boundary
regardless?
Why it looks low-risk
I tried the native package against this plugin's protocol and confirmed
ChatApi.sendChatCmd(cmd) plus its event stream speak the same string-command
/ JSON-event protocol you already send over WebSocket. So it slots in behind
the existing transport seam — everything above it (monitor, outbound, actions,
config, policy) is unchanged — and the existing connection.mode field makes a
mode: "native" option naturally additive and backward-compatible.
One thing genuinely worth your call: simplex-chat is AGPL-3.0 while this
plugin is MIT, so a native path would likely need to be gated behind an optional
dependency (loaded only when mode: "native") to keep default installs MIT and
AGPL-free. That's a licensing judgment, which is why I'm asking rather than
assuming.
Where I'm at
If in-process is a direction you'd welcome, I'm glad to put up the PR (keeping
mode: "external" unchanged). And if you'd rather keep this plugin focused on
the external-runtime model, no worries at all.
Regards,
Lundog
Co-Authored-By: Claude Opus 4.8
The question
Your architecture doc is clear that the guiding rule is "OpenClaw should not own
the
simplex-chatprocess lifecycle" — so the plugin talks to a separately-runruntime over WebSocket instead of spawning or supervising it. That makes a lot
of sense when the runtime is a standalone
simplex-chatexecutable: youdon't want plugin startup quietly babysitting a sidecar.
The new
[simplex-chat](https://www.npmjs.com/package/simplex-chat)npm package(the replacement for the deprecated WebRTC TS client) seems to change that
calculus: it embeds the SimpleX core in-process as a native library. There's
no separate process to own or supervise — the "runtime" becomes a function call,
not a daemon behind a socket.
So the real question for you: does the in-process model fit where you want this
plugin to go, or do you prefer to keep the explicit external-runtime boundary
regardless?
Why it looks low-risk
I tried the native package against this plugin's protocol and confirmed
ChatApi.sendChatCmd(cmd)plus its event stream speak the same string-command/ JSON-event protocol you already send over WebSocket. So it slots in behind
the existing transport seam — everything above it (monitor, outbound, actions,
config, policy) is unchanged — and the existing
connection.modefield makes amode: "native"option naturally additive and backward-compatible.One thing genuinely worth your call:
simplex-chatis AGPL-3.0 while thisplugin is MIT, so a native path would likely need to be gated behind an optional
dependency (loaded only when
mode: "native") to keep default installs MIT andAGPL-free. That's a licensing judgment, which is why I'm asking rather than
assuming.
Where I'm at
If in-process is a direction you'd welcome, I'm glad to put up the PR (keeping
mode: "external"unchanged). And if you'd rather keep this plugin focused onthe external-runtime model, no worries at all.
Regards,
Lundog
Co-Authored-By: Claude Opus 4.8