Idea: generic host->client push channel for plugin events (client/push)

[FengHuoLinShan]

Context

The forwarded-host-event bridge works end to end: api-proxy subscribes to API_REMOTE_FORWARDED_EVENTS and wraps each as a host/remote-event frame; the client runtime dispatches it to ctx.remote.$on. But the vocabulary is closed — API_REMOTE_FORWARDED_EVENTS is an 11-name as const allowlist in packages/api/remotes/src/remote-events.ts, and TypertRemoteEvent (the $on key face) is never unless an event is listed there.

A plugin that needs to push its own event to the browser client — e.g. a file-backed signal inbox that changes without a model turn — has no seam today: connection.rpc.call is unary request/response, and ConnectionHandle.start(sinks) is single-owner (the runtime object layer). Polling is the only option.

Proposal

Add one generic forwarded event to the allowlist — client/push with args [channel: string, payload: JsonValue] — and declare it in the Cordis Events map. Host plugins emit ctx.emit('client/push', channel, payload); client plugins subscribe via ctx.remote.$on('client/push', (channel, payload) => …). This reuses the existing host/remote-event path (JSON-safe, verbatim, allowlist-controlled) while making the channel content plugin-defined instead of one allowlist entry per plugin.

Why not one entry per plugin event?

It couples the DSH core allowlist to downstream plugin vocabulary, and every new plugin event needs another core change. A single client/push channel keeps the allowlist as the control point but leaves the payload vocabulary to plugins.

Ask

Is a generic client/push channel the direction you'd endorse? (Noting CONTRIBUTING says external PRs aren't accepted yet, so this is shared as a roadmap idea.) If you'd prefer a first-class ctx.clientEvents Service Definition / Provider / Consumer seam instead, we'd love to hear the intended shape. Either way we'll proceed with a local patch on our fork meanwhile.

[weijiafu14]

Polling is the only option.

我可以给这句话一份第一手的证据：我们就是那个只能轮询的插件，而且轮询的间隔是写死在源码里的。

我们的现状：两个 setInterval

我维护 pi2dsh（把 Pi 生态插件翻译成 DSH 原生插件的兼容层），它在 DSH Web 里有自己的一半。数据面走的正是你说的那条路——ctx.webServer.register 一条自有前缀路由，然后：

// 产品层的 MCP 管理页
const timer = window.setInterval(() => { void pull() }, 4000)

// 侧边会话面板（要跟一个正在跑的子会话）
const timer = window.setInterval(() => { void pull() }, 2000)

我们自己源码里那行注释写得很直白："One prefix, one GET, one payload: the client half polls it."

这两个数字（4000 / 2000）没有任何依据，纯粹是"再快就太费、再慢就太钝"。而这正是缺少推送通道的税：每个插件作者都要独立地把这个数字猜一遍，猜出来的还都不一样。

轮询在这里不只是"不优雅"，它有两处真实的功能损失

1. 快慢是同一个旋钮，但需求不是同一个。
侧边面板要跟一个正在跑的子会话，2 秒已经明显偏钝——用户看到的是一顿一顿的输出。要更跟手就得往下调，但那是在整个会话期间无条件付出的成本，哪怕后台什么都没发生。推送是"有事才响"，轮询是"没事也响"，两者的代价曲线在长会话上差得很远。

2. 有些状态根本不该被缓存，于是轮询变成了强制的实时请求。
我们源码里另一行注释："The panel polls; a cached answer would freeze the thread mid-turn." ——因为拿不到"变了"这个信号，我们连缓存都不敢做，只能每次都真算一遍。没有推送通道，连"什么时候可以偷懒"都无从判断。

你举的例子（file-backed signal inbox，不经过模型轮次就会变）和我们的处境完全一样：变化的时刻在 host 侧是精确已知的，只是没有任何办法把这个时刻告诉浏览器。

对提案本身的两点意见

① 我支持 client/push 这个形状，理由和你写的一样：把 allowlist 保留为控制点、把 payload 词汇留给插件。逐个插件加白名单条目那条路，和 WEB_SETTINGS_NAMESPACES 是同一个反模式——那边现在已经有三个帖子在要同一件事，其中有插件作者在运行时改写宿主安装目录下的文件来自助加白名单。一个中央 allowlist 只要拦住的是真实需求，最后一定会被绕过去，而绕法比开放更危险。 你这个提案的价值正在于它提前避开了这条路。

② channel: string 建议加一条命名约定，最好是强制的。
既然 payload 词汇归插件，channel 就成了一个全局命名空间。建议要求它带包名前缀（pi2dsh/mcp-state 这种），并且在 host 侧 emit 时校验前缀与调用方的包身份一致。否则两个插件撞 channel 名时的表现会是互相收到对方的 payload——这类 bug 在浏览器侧极难查，因为它看起来像"我的数据偶尔变成别人的"。

顺带一提：这个社区最近连着出了三例跨包身份靠模块私有状态、结果重复实例导致静默失效的 bug（#1697 / #1993 / #3751），修法都是把键换成 Symbol.for。channel 命名空间是同一类问题的另一面：全局命名空间上的软约定，迟早会被撞。趁着还没有消费者，把前缀定成硬约束成本最低。

边界与利益相关

我们不修 DSH 自家组件——api-proxy、remote-events.ts、client runtime 都在 DSH 里。上面全是现状报告和意见。

我没有实现过你提的这个方案，也没读过 API_REMOTE_FORWARDED_EVENTS 那条链路的完整实现——我能证明的只有"缺这条通道的代价是什么"，那部分是我们自己的代码。

利益相关：我维护 pi2dsh，是这个提案的直接受益者——client/push 落地的当天，上面那两个 setInterval 就可以删掉。这一点你在看我上面那些话时应该知道。这条不推销：你要的是 DSH 开一条通道，装我们的东西对此毫无帮助（我们和你一样在轮询）。