Guidance request: supported topology, headless/static-membership APIs, and safe discovery for a mixed DGX Spark + Mac + Windows lab

[ClosedLadder]

This note accompanies my comment on issue #19 (the discovery-traffic and macOS flow-leak analysis). It is intentionally a respectful long-shot request: if PAIR is intended to grow beyond its current scope, we would be grateful for architectural guidance or contact with an engineer who finds this deployment useful as a design case.

Current environment

The local lab has three DGX Spark GPU nodes, two Macs, and one Windows machine. Local models are exposed through OpenAI-compatible inference endpoints. The Macs and Windows system act primarily as clients, operator consoles, and edge-agent hosts. PAIR is currently quarantined on all six machines after the incidents described in issue #19; no production reinstallation is planned until the discovery and stability risks are resolved.

Longer-term goal

The goal is a local-first inference fabric that can serve Hermes and OpenClaw-style agent runtimes as well as interactive human sessions. A policy router would choose among local models and supported cloud providers according to capability, privacy, cost, latency, context size, and current availability. It would provide authenticated health checks, bounded retries, failover, observability, audit receipts, manual override, and hard failure isolation so a discovery or routing failure cannot impair ordinary network access.

Cloud participation would use only supported provider APIs or subscription-seat interfaces that explicitly permit automation. We are not asking to scrape web applications, bypass provider terms, share credentials between agents, or automate consumer subscriptions through unsupported interfaces. When a subscription seat has no supported automation boundary, it should remain a human-operated seat rather than part of the autonomous router.

Questions for NVIDIA

1. Is PAIR intended to become the control plane, the inference data plane, or both for a mixed local/cloud fabric like this? If its intended scope is narrower, which NVIDIA component should own model registry, policy routing, and failover?
2. Which supported headless APIs, SDKs, event streams, or static-membership interfaces exist today or are planned? Can discovery be disabled completely while nodes are registered explicitly?
3. Can node discovery be isolated from inference routing so loss or overload in discovery degrades cluster awareness without affecting the host's ordinary networking?
4. Is there a supported way to register several OpenAI-compatible local endpoints and attach health, capability, privacy, and cost metadata for policy decisions?
5. What topology, authentication, certificate, secret-storage, and network-segmentation pattern does NVIDIA recommend for Macs and Windows clients talking to a small DGX Spark cluster?
6. How should a router distinguish a process that is merely listening on a port from an endpoint that has actually produced tokens for a verification request, and how should it drain or fail over active work?
7. Are Hermes/OpenClaw-style agent runtimes expected to integrate through an OpenAI-compatible surface, MCP-style tools, another SDK, or a higher-level NVIDIA agent framework?
8. For supported cloud providers, does NVIDIA recommend a provider-adapter boundary that keeps cloud credentials and policy enforcement outside PAIR while presenting one audited routing interface to agents?
9. Until discovery is changed, is wired-only operation or a manual-nodes-only posture recommended for macOS members with the Application Firewall enabled?
10. Could NVIDIA provide a candidate fixed build, review this topology, or accept this lab as a careful design/test partner? We can supply sanitized counters and wired packet captures and test only on an isolated segment with out-of-band recovery.

Immediate requests related to PAIR 0.1.1

• A discovery mode that reuses stable sockets, browses once per node, and excludes container, VPN, and link-local point-to-point interfaces.
• A supported manual nodes only / discovery off configuration.
• macOS-specific guidance for Application Firewall and wireless members.
• A working packaged macOS sanitized-log collector.
• A documented rollback and recovery procedure that does not assume a distressed Mac can safely close a very large socket-flow population.

We appreciate that this architecture may exceed PAIR's present roadmap. Even a clear boundary—what PAIR should and should not own—would help us avoid rebuilding another fragile orchestration layer and would let us focus our local engineering on the correct interfaces.