Evaluate HeatNet/UOR as mailbox overlay, transport, or virtual network #4634

Agent pickup triage

Category: design/research. This classifies the next task, not completion or a verified current-source pass.

Next bounded step: Pin the exact HeatNet/UOR artifact and execute the overlay-versus-byte-transport comparisons; return a decision, not a production networking implementation.

Read the linked handoff and coordinate any active owner before implementation. Preserve the original acceptance criteria below; this triage grants no spending, credentials, publication, host reconfiguration, or landing authority.

Parent: #4607

Related to #4622 and #4632. #4607 owns the virtual-NIC/L3 decision; #4622 owns mailbox semantics and remains independent of that decision.

Outcome

Determine from executable evidence whether vnet/HeatNet belongs in MVM as a logical PeerOverlay, a PeerTransport, a TUN/L3 VirtualNetwork, or no production dependency. Record separate consequences for #4607's adapter research and #4622's NIC-less mailbox program.

Required comparisons

1. Iroh supplies routing and transport.
2. HeatNet/UOR supplies logical route selection while Iroh transports bytes.
3. vnet/HeatNet supplies peer transport directly, if the evaluated implementation actually connects peers and carries bytes.

Record the exact source revision or released artifact evaluated. Distinguish symbolic context translation and route computation from packet or stream forwarding.

Evaluation criteria

• NAT traversal, relay behavior, offline and local-first operation.
• Stable identity and tenant isolation.
• Peer churn, partition recovery, convergence, and route correctness.
• Warm and cold latency, throughput, memory, CPU, and wire overhead.
• Dynamic loading and upgrade behavior.
• Security boundary, auditability, dependency closure, and failure containment.

Acceptance criteria

• Reproducible prototypes or falsifying tests cover every applicable comparison above.
• The result identifies which interface, if any, vnet/HeatNet implements and why.
• Dynamic modules are content-addressed, signed, version-pinned, sandboxed, capability-bounded, and included in attestation/key-release policy where sealed execution requires it.
• No prototype introduces a guest NIC, general IP path, or second unaudited data plane without the separate decision required by Research: evaluate per-VM vsock NIC adapters for vnet/HeatNet and SpiralCore #4607.
• A recorded decision chooses the production layering and identifies measured tradeoffs rather than relying on naming or architectural analogy.
• The result updates Research: evaluate per-VM vsock NIC adapters for vnet/HeatNet and SpiralCore #4607 with the virtual-NIC/L3 conclusion and Program: signed pass-by-value mailboxes for workload, host, and user messaging #4622 with any independently useful mailbox-overlay or byte-transport conclusion.