[Tracking] Application-scoped peer mesh for Runtime Hosts

[M4n5ter]

English

Problem

Runtime Host remote access currently depends on a Client reaching a configured endpoint. Users who want private reachability across ordinary NAT must therefore expose an endpoint or separately install, join, and operate a general-purpose overlay network.

External overlays remain valuable routes, but they do not provide a Maka-native flow in which several users can connect their Runtime Hosts through Maka alone, expose only Runtime Host traffic, and optionally help one another establish connectivity.

This issue supersedes the connectivity scope of #3801. Resource authorization and Session sharing are tracked independently in #3843.

Desired outcome

Deliver an application-scoped Runtime Host peer mesh in which devices operated by different users can:

• join through an explicit Mesh invitation;
• establish authenticated direct connections when the network permits;
• discover only Runtime Host endpoints made visible to them;
• recover from address and path changes;
• optionally provide bounded one-hop transit for other permitted peers;
• carry the existing Runtime Host protocol over an end-to-end authenticated secure stream.

The mesh is native connectivity for Maka, not a general machine network. It does not expose arbitrary ports, assign virtual IPs, or replace existing TLS, SSH, acknowledged plaintext, or external-overlay routes.

Architecture boundary

The peer mesh answers only how a Client reaches an expected Runtime Host.

It owns:

• Mesh invitation and admission;
• node authentication;
• scoped Runtime Host discovery and ephemeral reachability;
• direct connection attempts and NAT traversal;
• reconnect and bounded route diagnostics;
• optional, explicitly enabled transit.

It does not own:

• Runtime Host credentials or resource authorization;
• Session visibility, sharing, or collaboration policy;
• Owner approval or Guest execution policy;
• Runtime state, State Root replication, or cross-Host consensus;
• access to unrelated services on a participating machine.

Joining the peer mesh grants no Runtime Host authority. The target Host independently verifies its pinned transport identity and expected Root ID, authenticates the presented Runtime Host credential, and authorizes every operation.

Invitation authority boundary

A Mesh invitation authorizes only connectivity membership and scoped discovery. Its one-time payload, node identity, receipt, durable admission state, and removal authority remain independent from collaboration invitations, Guest principals, Runtime Host credentials, and Session grants.

Milestone 1 creates no Mesh invitation authority; pairwise connectivity uses the existing Owner credential. If Milestone 2 is approved, removing a node from the mesh must not revoke Session grants that remain usable over TLS, SSH, or another transport. Revoking a Session grant must not remove the node from the mesh.

A future QR code or link may package opaque Mesh and collaboration invitation payloads for one scan. The Mesh and Host authorities must validate and commit their own payloads and report their own outcomes. The envelope provides no shared durable membership and no cross-authority atomicity guarantee.

Identity and control state

The design distinguishes:

• State Root identity;
• the target Host's pinned transport identity;
• node identity used for peer connectivity;
• admission to a particular peer mesh;
• Host-local resource credentials and grants.

No additional provider-neutral Host ID is introduced without a concrete invariant that existing target verification cannot express.

Admission, removal, discovery, and reachability need defined security semantics, but this tracker does not prescribe a global membership database, gossip protocol, distributed consensus, or CRDT. Those mechanisms must be justified by measured prototypes and the smallest design that satisfies the product outcome.

Transit model

The first transit capability is deliberately bounded:

• at most one transit hop;
• available only to explicitly permitted peers;
• disabled unless a node operator opts in;
• limited by connection, bandwidth, duration, and health policy;
• end-to-end encrypted and authenticated between Client and target Host;
• unable to grant or exercise Runtime Host authority;
• never an open or public Relay.

A route may be direct, use an explicitly permitted mesh transit, or use an existing external overlay. No route is guaranteed to be available, and the product must report an unreachable topology honestly.

Current gate

Only Milestone 1 is approved for implementation and prototyping. Milestones 2 and 3 describe the intended direction; they do not inherit approval from this tracker or from Milestone 1.

Before either later milestone starts, evidence from the preceding milestone must be reviewed to justify its product value, supported network behavior, security semantics, and added complexity.

Staged delivery

Milestone 1: Pairwise direct peer

• Pair one Client with one expected Host.
• Establish an authenticated secure stream using pinned Host identity, expected Root ID, and the existing Runtime Host credential.
• Measure NAT traversal, reconnect, diagnostics, and cross-platform behavior.
• Ship only as experimental until supported network topologies are evidenced.

Milestone 2: Multi-peer mesh

• Allow multiple independently operated nodes to participate.
• Add a Maka-native Mesh invitation with scoped discovery, removal, and recovery semantics.
• Keep connectivity membership independent from Runtime Host resource authority.

Milestone 3: Cooperative transit

• Validate one consenting node carrying an end-to-end encrypted Runtime Host stream between two permitted peers.
• Define resource limits, operator controls, diagnostics, and failure behavior.
• Treat transit as optional capacity, not a public-service or availability promise.

Each milestone is independently reviewable and must earn the next one. Provider selection follows measured evidence; Maka does not invent a new cryptographic transport protocol.

Acceptance criteria

• Pairwise direct connectivity can be delivered and evaluated independently of the later mesh milestones.
• Devices operated by different users can explicitly participate in the same private Runtime Host peer mesh.
• A Mesh invitation never creates a Guest principal, Runtime Host credential, or Session grant.
• Mesh removal and Session-grant revocation remain independent across every transport.
• Joining the mesh does not reveal a Runtime Host until that Host independently authenticates and authorizes the Client.
• Only authorized Runtime Host endpoints are discoverable; unrelated machine services are not exposed.
• A Client can reach the expected Host directly when the tested topology permits it.
• With three nodes, a Client can reach a target through one consenting transit node when no direct route is available.
• A transit node cannot read Runtime Host application plaintext or use transit authority to operate the target Host.
• Removing a peer prevents future mesh connectivity after the relevant control state propagates.
• Address changes and transient disconnects recover without silently retargeting a Host profile.
• An unreachable topology fails clearly without claiming guaranteed connectivity.
• Existing Local, TLS, SSH, acknowledged plaintext, and external-overlay routes do not regress.

Non-goals

• A general-purpose VPN or tailnet
• Arbitrary IP or port connectivity between participating machines
• Session sharing or collaboration permissions
• A unified invitation, identity, membership, receipt, or revocation authority spanning connectivity and Runtime resources
• Atomic commit across Mesh and collaboration invitation payloads
• Federated Runtime execution or replicated State Roots
• A distributed SQL/CRDT authority
• Arbitrary multi-hop routing in the first implementation
• Public discovery of arbitrary Hosts
• An Apache-operated production Relay or SLA
• Replacing existing external overlays
• Selecting a provider before measured cross-platform prototypes

简体中文

问题

当前 Runtime Host 远程访问依赖 Client 能够连接一个配置好的 endpoint。希望跨普通 NAT 私密连接的用户必须暴露 endpoint，或者额外安装、加入并维护一个通用 overlay network。

External overlay 仍然是有价值的 route，但它不能提供 Maka 原生流程：多个用户只使用 Maka 就能连接各自的 Runtime Hosts、只暴露 Runtime Host 流量，并可选地帮助彼此建立连接。

本 issue 替代 #3801 中的 connectivity 范围。资源授权与 Session sharing 由 #3843 独立跟踪。

期望结果

交付一个 application-scoped Runtime Host peer mesh，使不同用户运营的设备能够：

• 通过明确的 Mesh invitation 加入；
• 在网络条件允许时建立经过认证的 direct connection；
• 只发现对其可见的 Runtime Host endpoints；
• 从地址和路径变化中恢复；
• 可选地为获准 peers 提供有界的单跳 transit；
• 在端到端认证的安全连接上承载现有 Runtime Host protocol。

该 mesh 是 Maka 原生连接能力，不是通用机器网络。它不暴露任意端口、不分配虚拟 IP，也不替换现有 TLS、SSH、acknowledged plaintext 或 external-overlay routes。

架构边界

Peer mesh 只回答：Client 如何到达预期 Runtime Host。

它负责：

• Mesh invitation 与 admission；
• node authentication；
• scoped Runtime Host discovery 与临时 reachability；
• direct connection 与 NAT traversal；
• reconnect 与有界 route diagnostics；
• 可选且明确开启的 transit。

它不负责：

• Runtime Host credentials 或资源授权；
• Session visibility、sharing 或 collaboration policy；
• Owner approval 或 Guest execution policy；
• Runtime state、State Root 复制或跨 Host 共识；
• 访问参与设备上的无关服务。

加入 peer mesh 不授予任何 Runtime Host authority。目标 Host 仍独立验证固定的 transport identity 和 expected Root ID，认证所提供的 Runtime Host credential，并授权每个 operation。

Invitation authority 边界

Mesh invitation 只授权 connectivity membership 和 scoped discovery。它的 one-time payload、node identity、receipt、durable admission state 和 removal authority，必须与 collaboration invitation、Guest principal、Runtime Host credential 和 Session grant 永久独立。

Milestone 1 不建立 Mesh invitation authority；pairwise connectivity 使用现有 Owner credential。如果 Milestone 2 获得批准，将 node 移出 mesh 不得撤销仍可通过 TLS、SSH 或其他 transport 使用的 Session grant；撤销 Session grant 也不得将 node 移出 mesh。

未来一个 QR code 或 link 可以封装 opaque Mesh 与 collaboration invitation payload，以提供一次扫码体验。Mesh 与 Host authorities 必须分别验证并提交各自 payload，并分别报告结果；该 envelope 不提供共享 durable membership，也不保证跨 authority 原子性。

身份与控制面状态

设计区分：

• State Root identity；
• 目标 Host 固定的 transport identity；
• 用于 peer connectivity 的 node identity；
• 特定 peer mesh 的 admission；
• Host-local resource credential 与 grant。

在没有现有 target verification 无法表达的明确不变量前，不增加额外的 provider-neutral Host ID。

Admission、removal、discovery 和 reachability 需要明确的安全语义，但本 tracker 不预设全局 membership database、gossip protocol、distributed consensus 或 CRDT。相关机制必须由可度量 prototype 证明，并采用满足产品结果的最小设计。

Transit 模型

第一版 transit 能力有意保持有界：

• 最多一个 transit hop；
• 只服务明确获准的 peers；
• node operator 未主动开启时保持关闭；
• 受连接数、带宽、持续时间和健康策略限制；
• Client 与目标 Host 之间保持端到端加密和认证；
• 不能授予或行使 Runtime Host authority；
• 永远不成为 open 或 public Relay。

Route 可以是 direct、经过明确允许的 mesh transit，或使用现有 external overlay。任何 route 都不保证一定可用，产品必须诚实报告不可达拓扑。

当前阶段门

当前只批准 Milestone 1 进入实施和 prototype。Milestone 2 和 3 描述预期方向，不会从本 tracker 或 Milestone 1 自动继承批准。

任何后续 milestone 开始前，都必须重新审查上一阶段证据，并分别证明其产品价值、支持的网络行为、安全语义和新增复杂度合理。

分阶段交付

Milestone 1：Pairwise direct peer

• 将一个 Client 与一个预期 Host 配对。
• 使用固定 Host identity、expected Root ID 和现有 Runtime Host credential 建立经过认证的安全连接。
• 度量 NAT traversal、reconnect、diagnostics 和跨平台行为。
• 在支持的网络拓扑得到证据前只作为 experimental 能力交付。

Milestone 2：Multi-peer mesh

• 允许多个独立运营的 nodes 参与。
• 增加 Maka 原生 Mesh invitation、scoped discovery、removal 和 recovery 语义。
• 连接 membership 与 Runtime Host resource authority 保持独立。

Milestone 3：Cooperative transit

• 验证一个自愿节点在两个获准 peers 之间承载端到端加密 Runtime Host stream。
• 定义资源限制、operator controls、diagnostics 和失败行为。
• 把 transit 视为可选容量，而不是公共服务或可用性承诺。

每个 milestone 都可独立审查，并必须证明进入下一阶段的价值。Provider 选择由度量证据决定；Maka 不发明新的加密传输协议。

验收标准

• Pairwise direct connectivity 可以独立于后续 mesh milestones 交付和评估。
• 不同用户运营的设备可以明确参与同一个私有 Runtime Host peer mesh。
• Mesh invitation 永远不会创建 Guest principal、Runtime Host credential 或 Session grant。
• Mesh removal 与 Session-grant revocation 在所有 transport 上保持独立。
• 加入 mesh 后，只有目标 Runtime Host 独立认证并授权 Client，才会暴露该 Host。
• 只能发现获准的 Runtime Host endpoints，不暴露设备上的无关服务。
• 在测试拓扑允许时，Client 可以 direct 连接预期 Host。
• 在三个节点场景中，无法直连时 Client 可以通过一个自愿 transit node 到达目标。
• Transit node 无法读取 Runtime Host 应用明文，也不能使用 transit authority 操作目标 Host。
• 移除 peer 后，相关控制状态传播完成时会阻止后续 mesh 连接。
• 地址变化和暂时断线可以恢复，且不会静默 retarget Host profile。
• 无法连接的拓扑会明确失败，而不是声称保证可达。
• 现有 Local、TLS、SSH、acknowledged plaintext 和 external-overlay routes 不回归。

非目标

• 通用 VPN 或 tailnet
• 参与设备之间的任意 IP 或端口连接
• Session sharing 或 collaboration permissions
• 横跨 connectivity 与 Runtime resource 的统一 invitation、identity、membership、receipt 或 revocation authority
• Mesh 与 collaboration invitation payload 的跨 authority 原子提交
• Federated Runtime execution 或复制 State Root
• Distributed SQL/CRDT authority
• 第一版支持任意多跳路由
• 公开发现任意 Hosts
• Apache 运营的生产 Relay 或 SLA
• 替换现有 external overlays
• 在完成跨平台度量 prototype 前选择 provider

[M4n5ter]

English

Milestone 1 provider and native-boundary decision

The bounded spike selects rust-libp2p 0.56.x with a napi-rs boundary for the production prototype.

Why not js-libp2p:

• js-libp2p does provide DCUtR, Circuit Relay v2, and a direct/relayed connection classification; it was not rejected for being JavaScript
• its current official module catalog does not provide a Node.js QUIC transport, while the official DCUtR guidance demonstrates TCP and the maintainer's published assessment explains that reliable simultaneous hole punching needs QUIC and that Node.js QUIC support was the missing piece: discussion
• Maka's approved slice requires a provider-proven direct QUIC path before application traffic, plus reproducible NAT and UDP-blocked behavior; choosing js-libp2p would therefore mean changing that transport contract or building another native QUIC boundary
• js-libp2p was screened out before the final topology comparison because the required capability evidence was absent; this is not reported as an experimental failure

Provider evidence:

• macOS loopback: direct QUIC in 4 ms; application proof in 6 ms
• macOS arm64 to Linux x64 on LAN: direct QUIC in 14 ms; application proof in 64 ms
• controlled two-NAT Linux topology: Relay coordination in 21 ms, DCUtR direct QUIC in 82 ms, direct-only application proof in 109 ms
• UDP-blocked topology: Relay coordination remained available, no application probe crossed the Relay, and the attempt ended with bounded direct_path_unavailable
• the persisted key kept the PeerId stable across topology teardown, address changes, and listen-port changes

Iroh 1.1.0 was tested as the comparison candidate. Its route API and LAN behavior were good, and the application gate could distinguish selected direct and Relay paths. It did not establish a direct path in the comparable controlled single-layer two-NAT topology, including after both externally observed addresses were supplied, while rust-libp2p DCUtR did. It also showed no decisive packaging or lifecycle advantage, so Maka will not maintain two providers.

The native boundary was measured separately:

• the napi-rs addon loaded and bound a real libp2p QUIC endpoint under Node 24.18, Electron 43 in Node mode, and a real Electron 43 main process
• endpoint start after module load was approximately 0.2–0.5 ms; incremental idle RSS over an empty Node process was approximately 7 MiB
• the helper prototype took approximately 6–9 ms to reach readiness and used approximately 10.4 MiB in a separate process
• napi-rs removes a private IPC protocol, another stream queue/backpressure contract, child supervision, and orphan cleanup
• accepted trade-off: a native abort terminates the owning Node/Electron process; the Rust core will remain separate from bindings so measured stability evidence can justify a future helper boundary without changing the profile or wire contract

This decision does not approve production Relay, Mesh membership, or cooperative transit. Milestone 1 still permits explicitly enabled Relay coordination only; Runtime Host credentials and application traffic are admitted only after the provider proves a direct connection.

Remaining gates:

• at least one real cross-network residential-NAT sample; the controlled topology is not a success-rate claim
• Windows x64 native build/start smoke on a Windows runner
• bounded napi stream cancellation, shutdown, and queue behavior
• generated dependency license/NOTICE material for source and binary releases

中文

Milestone 1 provider 与 native boundary 决策

有界 spike 选择 rust-libp2p 0.56.x + napi-rs 作为 production prototype。

为什么不选择 js-libp2p：

• js-libp2p 已提供 DCUtR、Circuit Relay v2 和 direct/relayed connection 分类；不选择它不是因为它使用 JavaScript
• 当前官方 module catalog 没有 Node.js QUIC transport；官方 DCUtR 指引使用 TCP，maintainer 的公开判断也指出可靠的 simultaneous hole punching 需要 QUIC，而 Node.js QUIC support 是缺失环节：discussion
• 已批准切片要求在 application traffic 前证明 direct QUIC path，并具有可复现的 NAT/UDP-blocked 行为；选择 js-libp2p 意味着改变这一 transport contract，或再实现一层 native QUIC boundary
• 因关键能力证据缺失，js-libp2p 在进入最终同拓扑对照前被筛除；这里不会把它表述为“实测失败”

Provider 证据：

• macOS loopback：4 ms 建立 direct QUIC，6 ms 完成 application proof
• macOS arm64 到 Linux x64 LAN：14 ms 建立 direct QUIC，64 ms 完成 application proof
• Linux 受控双 NAT：21 ms 建立 Relay coordination，82 ms 经 DCUtR 建立 direct QUIC，109 ms 完成 direct-only application proof
• UDP blocked：Relay coordination 仍可达，没有 application probe 经 Relay 发送，并在有界时间后返回 direct_path_unavailable
• 持久 key 在拓扑重建、地址和监听端口变化后保持相同 PeerId

对照测试了 Iroh 1.1.0。它的 route API 与 LAN 行为良好，application gate 也能区分 selected direct/Relay path；但在可比的受控单层双 NAT 中，即使两端都提供已观察到的外部地址，也没有像 rust-libp2p DCUtR 一样建立 direct path，同时没有表现出决定性的 packaging 或 lifecycle 优势。因此 Maka 不维护双 provider。

Native boundary 单独进行了实测：

• napi-rs addon 在 Node 24.18、Electron 43 Node mode 和真实 Electron 43 main process 中均能加载并绑定真实 libp2p QUIC endpoint
• module load 后 endpoint 启动约 0.2–0.5 ms；相对空 Node process 的 idle RSS 增量约 7 MiB
• helper prototype 到 ready 约 6–9 ms，独立进程 RSS 约 10.4 MiB
• napi-rs 删除了 private IPC、第二套 stream queue/backpressure、child supervision 和 orphan cleanup
• 接受的代价：native abort 会结束 owner Node/Electron process；Rust core 与 binding 保持分层，未来若稳定性证据要求 helper，可在不改变 profile/wire contract 的前提下迁移

该决策不批准 production Relay、Mesh membership 或 cooperative transit。Milestone 1 仍只允许显式启用的 Relay coordination；只有 provider 证明 direct connection 后，才允许 Runtime Host credential 与 application traffic 进入连接。

剩余 gate：

• 至少一组真实跨网络 residential NAT；受控拓扑不能代表普遍成功率
• Windows x64 原生 build/start smoke
• napi stream cancellation、shutdown 与 bounded queue
• source/binary release 的 dependency license/NOTICE 生成

[M4n5ter]

English

Milestone 1 implementation closure

Milestone 1 is now implementation-complete on main.

Delivered slices:

• feat(runtime-host): add experimental direct peer transport #3877 — rust-libp2p direct-peer transport, pinned PeerId, direct-path gate, existing Runtime Host framing/authentication/lifecycle
• feat(cli): manage experimental direct peer hosts #3919 — release-mode native artifacts, managed-service identity lifecycle, CLI/TUI distribution and operations
• feat(desktop): onboard experimental direct peer hosts #3950 — Desktop onboarding, SSH management/recovery path, bounded route status and diagnostics
• feat(desktop): share the Local Runtime Host #3972 — sharing the current computer Local Runtime Host, concurrent Local IPC + Direct listeners, and one-time Owner connection codes

Evidence obtained

• direct QUIC was proven on macOS loopback and macOS arm64 ↔ Linux x64 LAN
• a controlled two-NAT Linux topology established the application stream only after DCUtR upgraded to a direct path and the coordination circuit closed
• with UDP blocked, coordination could remain reachable but no Runtime Host application traffic crossed the Relay; the attempt ended with bounded direct_path_unavailable
• the persisted peer key retained the same PeerId across listener/address changes, disable/re-enable, service repair and update; explicit rotation changed identity
• real macOS and Linux managed-service lifecycle tests covered enable, disable, re-enable, rotate and uninstall
• macOS arm64, Linux x64/arm64 and Windows x64 release artifacts were built and admitted without requiring Rust on the target machine
• Desktop completed authenticated Runtime Host operations and a Turn through Direct peer while retaining the independent SSH recovery profile
• two isolated Desktop instances imported a one-time connection code and used the same Host without copying its State Root
• Local IPC and Direct peer listeners operated concurrently on one Host; disabling connectivity remained separate from uninstalling the service or revoking credentials

Honest limits

This evidence proves the pairwise seam and the experimental product flow; it is not a general NAT success-rate claim. Restrictive NAT, CGNAT, mobile networks, UDP-blocked networks and some address-family combinations can still fail. Direct peer therefore remains explicitly experimental, does not replace a separately usable TLS/SSH/external-overlay fallback, and makes no public Relay or availability promise.

A broader real-network matrix remains useful for documenting supported topologies and any future promotion from experimental. It is no longer an architectural prerequisite for beginning Milestone 2 design: M1 has already proved that multiple independently managed Runtime Hosts can reuse the same pinned peer transport, Host authentication and lifecycle boundaries.

Next gate

Milestone 2 may now enter formal design review. It does not inherit implementation approval from M1.

The intended boundary remains:

• add explicit Mesh membership, scoped peer discovery, removal and recovery
• reuse the existing libp2p PeerId and direct-peer data plane
• keep Runtime Host credentials, Root ID verification and resource authorization independent
• exclude cooperative transit, which remains Milestone 3
• exclude Session sharing and collaboration authority, which remain in [Tracking] Resource-scoped Runtime Host sharing and collaboration #3843

简体中文

Milestone 1 实现闭环

Milestone 1 的实现现已全部合入 main。

已交付切片：

• feat(runtime-host): add experimental direct peer transport #3877 — rust-libp2p direct-peer transport、固定 PeerId、direct-path gate，以及复用现有 Runtime Host framing、认证与生命周期
• feat(cli): manage experimental direct peer hosts #3919 — release native artifacts、managed-service identity 生命周期，以及 CLI/TUI 分发与操作路径
• feat(desktop): onboard experimental direct peer hosts #3950 — Desktop onboarding、SSH 管理/恢复路径，以及有界 route 状态与诊断
• feat(desktop): share the Local Runtime Host #3972 — 共享当前电脑既有的 Local Runtime Host、Local IPC 与 Direct listener 并存，以及一次性 Owner 连接码

已取得证据

• 在 macOS loopback 和 macOS arm64 ↔ Linux x64 LAN 上证明了 direct QUIC
• 在受控的 Linux 双 NAT 拓扑中，只有 DCUtR 升级为 direct path 且 coordination circuit 关闭后，才建立 application stream
• UDP 被阻断时，coordination 仍可能可达，但没有 Runtime Host application traffic 经过 Relay；连接在有界时间后返回 direct_path_unavailable
• 持久 peer key 在 listener/address 变化、关闭/重开、service repair 与 update 后保持相同 PeerId；显式 rotation 会改变 identity
• 在真实 macOS 与 Linux managed service 上验证了 enable、disable、re-enable、rotate 与 uninstall
• macOS arm64、Linux x64/arm64 与 Windows x64 release artifacts 均可构建和准入，目标机器不需要安装 Rust
• Desktop 使用 Direct peer 完成了带认证的 Runtime Host operation 与 Turn，同时保留独立 SSH recovery profile
• 两个隔离 Desktop 实例通过一次性连接码连接同一 Host，未复制其 State Root
• 同一 Host 上 Local IPC 与 Direct peer listener 可同时工作；关闭 connectivity 与卸载 service、撤销 credential 保持独立

诚实的限制

这些证据证明了 pairwise 接缝和 experimental 产品闭环，但不代表普遍 NAT 成功率。Restrictive NAT、CGNAT、移动网络、UDP blocked 和部分 address-family 组合仍可能失败。因此 Direct peer 继续保持显式 experimental，不替代独立可用的 TLS/SSH/external-overlay fallback，也不承诺公共 Relay 或可用性。

更广泛的真实网络矩阵仍有助于记录支持拓扑，并作为未来退出 experimental 的依据；但它不再是开始 Milestone 2 设计的架构前置条件。M1 已经证明多个独立管理的 Runtime Hosts 可以复用同一套固定 peer transport、Host authentication 与 lifecycle 边界。

下一阶段门

Milestone 2 现在可以进入正式设计审查，但不会从 M1 自动继承实现批准。

边界保持为：

• 增加明确的 Mesh membership、scoped peer discovery、removal 与 recovery
• 复用现有 libp2p PeerId 和 direct-peer data plane
• Runtime Host credential、Root ID 验证与资源授权保持独立
• 不包含 cooperative transit；它仍属于 Milestone 3
• 不包含 Session sharing 与 collaboration authority；它们仍由 [Tracking] Resource-scoped Runtime Host sharing and collaboration #3843 跟踪