NS · 应用模式

状态：设计阶段，尚未实现。 应用模式是 NS 的第三个部分：文件发送以及之后的功能、第三方应用，都作为应用运行在节点之上，而不是某种连接模式的附属功能。账户模式与 Quick 模式回答”谁是对端、经哪条路径到达”；应用回答”在隧道里做什么”。

1. 一个节点，一个 nsplane

目标设计中，每个 ns 节点只有一个 nsplane 数据面引擎。账户模式、Quick 模式、ns send 与第三方应用全部基于这一个引擎：

层	组件	职责
应用	ns send / ns receive、第三方应用	应用自己的协议、界面与输出
应用会话接口	ns	应用通道（会合信箱客户端、引入、按 kind 分发）、app:<session> 对端来源的生命周期、第三方应用接入
连接方式	账户模式（NSD 投影的对端）/ Quick 模式（配对产生的对端）	决定谁是对端、用哪个 relay、走哪条路径
数据面	nsplane 引擎（每个节点一个）	WireGuard、直连与 relay 路径、报文过滤；会话对端的安装与移除、隧道内连接（netstack）、按来源命名空间的 ACL 与 pinhole
会合	relay 的 /rendezvous/v1	与应用无关的会合信箱（会合协议）

应用不自带 WireGuard 引擎、TUN 或 relay 连接；它通过应用会话接口使用节点已有的引擎。这样直连探测、relay 转发预算、入站过滤和路径切换只有一份实现。

现状：账户模式（2026-10-03）与 Quick 模式（2026-10-04）都已运行在同一个 nsplane 引擎上，并自 2026-10-12 起作为平等的 membership 同时运行（在同一模型里应用会话 app:* 是又一种 membership，尚未实现）；应用通道的 confirm 模式已用于 Quick 配对，pake / peer 模式与文件发送尚未实现。进度见迁移计划。

2. 应用由什么构成

组成	说明
kind	应用标签，例如文件发送为 transfer；relay 只用它做统计
应用通道	应用声明一份 profile（kind、鉴权方式 confirm / pake / peer、对端生命周期、隧道内端口）；会合、引入、身份交换、PSK、对端安装与隧道内入口由 ns 的应用通道统一实现，需要会合时经 relay 的 /rendezvous/v1 信箱
对端	两端已是对端时使用现有对端（peer）；否则经应用通道的 pake 建立仅限本次会话的对端：从不进入允许名单，不发布名字，只放行应用端口，会话结束即删除
数据	始终在 WireGuard 隧道内，按端口区分应用；relay 上不承载应用数据（会合协议 §10）
界面	命令行、--json 事件或嵌入方的回调

Quick 模式的配对同样是应用通道上的应用（kind = "pairing"，confirm，长期对端）；它是 Quick 模式建立对端的方式，因此不出现在下面的应用清单中。

3. 与两种连接方式的关系

应用不绑定某一种模式：节点运行在哪种模式，应用就使用那种模式已有的对端与路径；没有现成对端时，经会合信箱建立仅限本次会话的对端。

节点模式	已有对端	没有现成对端
Quick 模式	ready 的已配对对端	会合信箱 + 仅限本次会话的对端，经 Quick relay 到达
账户模式	NSD 投影的 Node，受 Node L3 ACL 约束	待设计

4. 应用清单

应用	kind	入口	状态
文件发送	transfer	ns send / ns receive <票据>	设计，未实现
第三方应用	自选	ns app ...（预留）与 ns 暴露的应用接口	规划
语音、聊天	待定	待定	规划；按应用通道 §9 添加

命令约定：内置的高频应用使用顶层短命令（ns send / ns receive），它们跟随节点当前的模式，不属于账户模式或 Quick 模式；第三方应用的列出、授权与运行统一放在预留的 ns app 命令族下。

5. 待决事项

• 第三方应用的接入形式：本地 IPC、libns，还是进程内库。
• 第三方应用的 kind 命名空间与权限：哪些应用可以安装仅限本次会话的对端、可以使用哪些端口。
• 账户模式下没有现成对端时的会合与准入。