In what scenarios do you need this feature?
The current client plugin mechanism in SiYuan relies on the Web/Electron client. When users open multiple browser windows or Electron instances, they face distributed system challenges. Each plugin instance is essentially a node in a distributed system, encountering data consistency and consensus issues across instances.
Case 1: Third-party Service Plugins
Plugins like Wakatime that need to access third-party services typically have a worker responsible for reporting statistics. Currently, complex logic is required to ensure only one instance of the worker runs at any given time, otherwise:
- Data may be duplicated (multiple instances running simultaneously)
- Data may be missed (no instance running)
With kernel plugins, the reporting task could be executed in the kernel plugin, avoiding these issues.
Case 2: Plugins Requiring Data Persistence
Currently, complex data synchronization schemes are needed to ensure data consistency across plugin instances on different clients, or we fall back to Case 1's approach of maintaining a single instance.
Describe the optimal solution
1. WASM Sandbox Runtime
Technology Choice:
Use fastschema/qjs to create a WASM-based JavaScript runtime sandbox to run kernel plugins in isolation.
Advantages:
- The project already uses Wazero as the WebAssembly execution engine
- Adding github.com/fastschema/qjs will have limited impact on kernel binary size
- WASM provides excellent isolation and security
2. RPC Service Exposure
Technology Choice:
Use filecoin-project/go-jsonrpc to expose services provided by the kernel plugin to external parties using the HTTP / WebSocket protocol for use by the client plugin/external users.
Describe the candidate solution
- Other WASM JavaScript engines (e.g.
waPC, goja, etc.)
- Other RPC frameworks (e.g.
gRPC, gorilla/websocket, etc.)
Other information
📊 Related Tech Stack
Additional Notes
- This feature can fundamentally solve data consistency issues across multiple client instances
- Kernel plugins serve as the single source of truth, client plugins handle UI interactions
- Helps build a more reliable plugin ecosystem
在什么场景下需要此功能？
当前思源笔记的客户端插件机制依托于 Web / Electron 客户端。当用户打开多个浏览器/Electron 窗口时会面临分布式挑战：每个插件实例实际上是分布式系统的一个节点，会遇到实例间数据一致性 & 共识挑战。
案例 1: 第三方服务插件
Wakatime 这类需要访问第三方服务的插件，通常有一个 worker 专门负责将统计信息上报给第三方服务。当前需要通过复杂的逻辑保证该 worker 长期只有一个实例，否则会出现：
- 数据重复上报（多实例同时运行）
- 漏报问题（无实例运行）
如果有了内核插件，可以在内核插件中执行数据上报任务，避免上述问题。
案例 2: 需要数据持久化的插件
当前需要复杂的数据同步方案确保各客户端的插件实例中数据的一致性，或者回退到案例 1 的方案维护一个单实例。
最优解决方案
1. WASM 沙箱执行引擎
技术选型:
使用 fastschema/qjs 创建基于 WASM 的 JavaScript 运行沙箱，隔离运行内核插件。
优势:
- 当前项目已经引入了 WebAssembly 执行引擎 Wazero
- 添加 github.com/fastschema/qjs 依赖后内核体积膨胀有限
- WASM 提供了良好的隔离性和安全性
2. RPC 服务暴露
技术选型:
使用 filecoin-project/go-jsonrpc 将内核插件提供的服务以 HTTP / WebSocket 协议暴露给外部，供客户端插件/外部用户使用。
描述候选解决方案
- 其他 WASM JavaScript 引擎（如
waPC, goja 等）
- 其他 RPC 框架（如
gRPC, gorilla/websocket 等）
其他信息
📊 相关技术栈
补充说明
- 此功能可从根本上解决多客户端实例的数据一致性问题
- 内核插件作为单一数据源，客户端插件负责 UI 交互
- 有利于构建更可靠的插件生态
In what scenarios do you need this feature?
The current client plugin mechanism in SiYuan relies on the Web/Electron client. When users open multiple browser windows or Electron instances, they face distributed system challenges. Each plugin instance is essentially a node in a distributed system, encountering data consistency and consensus issues across instances.
Case 1: Third-party Service Plugins
Plugins like Wakatime that need to access third-party services typically have a worker responsible for reporting statistics. Currently, complex logic is required to ensure only one instance of the worker runs at any given time, otherwise:
With kernel plugins, the reporting task could be executed in the kernel plugin, avoiding these issues.
Case 2: Plugins Requiring Data Persistence
Currently, complex data synchronization schemes are needed to ensure data consistency across plugin instances on different clients, or we fall back to Case 1's approach of maintaining a single instance.
Describe the optimal solution
1. WASM Sandbox Runtime
Technology Choice:
Use fastschema/qjs to create a WASM-based JavaScript runtime sandbox to run kernel plugins in isolation.
Advantages:
2. RPC Service Exposure
Technology Choice:
Use filecoin-project/go-jsonrpc to expose services provided by the kernel plugin to external parties using the HTTP / WebSocket protocol for use by the client plugin/external users.
Describe the candidate solution
waPC,goja, etc.)gRPC,gorilla/websocket, etc.)Other information
📊 Related Tech Stack
Additional Notes
在什么场景下需要此功能？
当前思源笔记的客户端插件机制依托于 Web / Electron 客户端。当用户打开多个浏览器/Electron 窗口时会面临分布式挑战：每个插件实例实际上是分布式系统的一个节点，会遇到实例间数据一致性 & 共识挑战。
案例 1: 第三方服务插件
Wakatime 这类需要访问第三方服务的插件，通常有一个 worker 专门负责将统计信息上报给第三方服务。当前需要通过复杂的逻辑保证该 worker 长期只有一个实例，否则会出现：
如果有了内核插件，可以在内核插件中执行数据上报任务，避免上述问题。
案例 2: 需要数据持久化的插件
当前需要复杂的数据同步方案确保各客户端的插件实例中数据的一致性，或者回退到案例 1 的方案维护一个单实例。
最优解决方案
1. WASM 沙箱执行引擎
技术选型:
使用 fastschema/qjs 创建基于 WASM 的 JavaScript 运行沙箱，隔离运行内核插件。
优势:
2. RPC 服务暴露
技术选型:
使用 filecoin-project/go-jsonrpc 将内核插件提供的服务以 HTTP / WebSocket 协议暴露给外部，供客户端插件/外部用户使用。
描述候选解决方案
waPC,goja等）gRPC,gorilla/websocket等）其他信息
📊 相关技术栈
补充说明