Technical Overview

Core model

VX6 turns local services into network-reachable services without forcing them to stop being local. The app stays on localhost. VX6 handles discovery, naming, sessions, routing, and transport between peers.

Identity, discovery, and the local registry

• Each node keeps a persistent Ed25519 identity and a stable VX6 node ID.
• Node and service records are signed before they are published.
• A node can enter through any known live peer, not only one fixed bootstrap.
• Every node keeps a local registry of known peers, services, and hidden aliases for fast future lookups.

Service flow modes

Named direct mode

service owner publishes username.service
client resolves the name
VX6 opens a node-to-node session
target node forwards traffic to the real localhost target

Direct IPv6 mode

If the client already knows the peer IPv6 address, it can skip discovery and still use VX6 service forwarding directly by address.

Relay proxy mode

VX6 can build a multi-hop relay path when the user prefers a routed path instead of a straight direct connection. Relay selection uses health, RTT, diversity, and duplicate avoidance.

Hidden services in detail

Hidden services are reached by alias instead of by a normal public service endpoint. The owner publishes routing metadata, not a standard service address, and the network builds the path in the background.

1. The owner publishes the alias

   The alias carries intro and routing metadata instead of a normal public service endpoint.

2. The client resolves the alias

   VX6 chooses an intro path, guard path, and rendezvous candidate based on live peers in the local registry.

3. Both sides build toward X

   The client and owner each build relay legs toward the same rendezvous point, where the streams are joined before the owner forwards into the localhost target.

Why this is stronger for private service hosting

• Owner application remains localhost-only; no direct public app port exposure.
• Descriptor validation requires signature, freshness, and multi-source agreement.
• Setup path and data path are separated, reducing simple tracing opportunities.
• Dual-leg rendezvous means both sides build independently toward the same meeting point.
• Hidden control flow includes anti-replay protections for setup signaling.

Benchmark reporting approach (without hardcoded numbers)

VX6 benchmark reports are presented by method categories instead of marketing claims: descriptor resolve latency, rendezvous setup time, data throughput, and churn recovery success under relay/node changes.

eBPF and performance

On Linux, VX6 includes experimental eBPF/XDP work for traffic classification and relay-side networking decisions. That lets the control plane stay readable in Go while hot networking work can move closer to the kernel.

• VX6 traffic can be identified early.
• Busy relay nodes can keep their hot path lightweight.
• Kernel-side logic reduces extra work on the relay path.
• The current release still treats this path as experimental rather than a proven production fast path.

Platform support and app layers

VX6 protocol/runtime is Linux-first with Windows-compatible coverage and macOS buildability targets. Application layers (desktop/mobile) are being built as separate products on top of the same core SDK and protocol contracts.

• Linux is the main branch for protocol and release work.
• Windows support is available and kept behaviorally aligned.
• macOS builds are supported for CLI and app tracks.
• Desktop app track: VX6 MeshChat (calls/files/chat) on top of VX6 core.
• Transport layer supports TCP and QUIC.
• Android and iOS app tracks are in active integration planning.
• Linux-only features such as systemd and eBPF management do not become native Windows features automatically.

How VX6 can evolve into SD-WAN style deployments

VX6 already has identity-based peers, decentralized discovery, relay fallback, and localhost service routing. For SD-WAN style use, the next layer is policy and operations: route preferences, branch failover rules, and richer observability.

• Keep branch apps local while sharing by name over VX6 overlay.
• Select direct vs relay paths based on policy and health.
• Add operator controls for SLA thresholds and route enforcement.
• Use common backend contracts so desktop/mobile admin tools stay aligned.