Neutrino Link is a private overlay network for a person’s own devices. The devices keep a stable identity and stay reachable while the relays, transports, egresses and access networks underneath them change. Neutrino Protocol (NP) v1 is the wire protocol that carries it.
I designed the protocol, wrote the specification and built the relay and client in Go. The repository holds about 32,000 lines of Go across 41 commits from April to September 2026, plus a written specification and an evidence trail. This article explains what it does, which engineering problems it solves, how it is built, and — the part I care most about — what is actually proven versus still unknown.
The problem
Consumer and small-team connectivity is fragile in a specific way. A device attaches to a tunnel and is then tied to one relay, one transport and one address. When any of those changes — a carrier switch, a relay restart, a network that stops passing a protocol — the session breaks and the user repeats setup. A point tunnel also does not answer the questions a private network needs: is my other device online, what address does it have, how do I reach a service on it without exposing that service to the internet.
On top of that, a tunnel that looks like a tunnel is easy to single out. The transport has to blend with ordinary encrypted web traffic, or it gets treated as something worth blocking.
So the design goals were: one connection that carries several planes at once; a packet plane with no transport-coupled state; sessions that resume; relay-mediated access to devices and services; a wire image that is genuinely HTTP/3; and a protocol small enough that a small team can implement it without ambiguity.
Transport: one connection, several planes
NP v1 runs on QUIC v1 with TLS 1.3 and presents an HTTP/3 application image. That choice is deliberate: QUIC gives secure multiplexed transport, stream isolation, connection migration and resumption, while HTTP/3 gives a normal-looking profile on top.
One long-lived HTTP/3 CONNECT stream carries the session and its control messages. Overlay IP packets ride HTTP datagrams associated with that stream, so unreliable packet carriage sits next to reliable control without a separate connection. Additional CONNECT streams carry byte flows for relayed traffic and for access to published services. Control messages use a compact binary framing with variable-length integers.
The point is that all of this shares one connection with a normal ALPN and standard TLS, so on the network it looks like an HTTP/3 client talking to a website, not like a bespoke protocol.
The overlay
It is a relay-mediated overlay, not a mesh. A device attaches to a relay, receives an overlay IPv4 address, and can then reach its other devices and any published services through that relay. The relay holds presence state and forwards packets between attached peers on the same network.
Services can be published from a device and discovered by the other devices in the same network. An optional scoped UDP exit mode lets a device send internet traffic out through the relay’s egress, with NAT and per-session rate limits rather than an open relay.
V1 is IPv4-only inside the overlay and single-relay. Direct peer-to-peer, multi-relay routing, federation and IPv6 are explicitly out of scope in the specification — they are named as V2 work, not quietly implied.
Sessions that survive the road
The load-bearing idea is simple: the packet plane carries no transport-coupled state. An inner connection between two overlay addresses is a kernel socket; the carrier under it is just encapsulation. If the carrier changes, the inner connection can survive as long as the tunnel device stays the same, the overlay addresses do not change, and the relay routes packets from the new carrier to the same exit.
Sessions are resumable rather than re-established. The relay issues a single-use, encrypted resume token bound to the authenticated device; a reconnecting client presents it and either resumes the session and gets a fresh token, or is told to attach from scratch. Heartbeats track liveness. If a connection is lost without a clean disconnect, the session is marked suspect and then offline after a grace period, and peers are told.
Security model
- Each device authenticates with a short-lived signed device token (Ed25519) scoped to one device, one network and one relay, carrying a unique token id, an expiry and a feature bitmask.
- The relay validates the signature, issuer, audience, relay scope, expiry and token id, and refuses a replayed token-id and nonce pair inside a bounded window.
- Resume tokens are AEAD-sealed and single-use. The sealing key must be random and per-relay — never derived from public values, which would let anyone forge a token.
- Transport security is TLS 1.3 inside QUIC. The client can pin the relay’s certificate or use a custom CA, and the production profile fails closed rather than skipping verification.
- The relay caps control-frame sizes and decoded element counts, recovers from panics instead of crashing, and validates the inner source address of datagrams before forwarding them.
- A test key pair that had been committed by mistake was removed and rotated, with a documented rotation procedure.
The model is honest about what it does not do. In v1 the relay is trusted infrastructure. It sees device and network identity, destination addresses, timings and volumes, and the payload of anything not already end-to-end encrypted. Cross-device payloads are not end-to-end encrypted in v1; that is deferred to V2. Applications that need confidentiality bring their own encryption — SSH, HTTPS and TLS all pass through untouched.
Not standing out
The wire image is genuine HTTP/3, not a custom protocol dressed up as HTTP/3. Standard QUIC, standard TLS 1.3, a standard ALPN, ordinary CONNECT requests. The relay also serves a real website on the same server and answers unknown or unauthenticated requests the way a normal web server would, instead of revealing that a path requires authentication.
Early control traffic and small datagrams are padded to fixed size buckets so that message size does not leak content, and repeated probing is rate-limited and made to look like a slow server rather than an error. A TCP/WebSocket fallback for networks that block UDP is specified as a transport profile, but it is design only and not implemented. Padding addresses message size, not timing; timing analysis resistance is explicitly out of scope.
Client support
Native clients only. There is a Go CLI and a daemon (np-clientd) with a small control tool (npctl), on Linux via systemd and macOS via launchd, with an install bundle and a one-line bootstrap.
The daemon brings up a TUN interface and overlay routes, runs a kill switch that closes the tunnel and revokes routes when the connection drops, and a DNS-leak guard. A separate live-check tool proves the minimum real-world path: a relay attach, a session that stays up, and one packet forwarded between two attached clients.
On macOS the packet plane reached parity and passed field validation, and a second pass validated the real overlay use cases — ping, SSH over the overlay, private HTTP, a relay restart, and clean teardown. That pass found a genuine bug: after a relay restart the control plane reconnected on its own while the packet plane stayed dead until a manual restart. The fix restores the datagram capability on resume and tears the plane down on any rebind failure so the daemon self-heals. It was regression-tested and verified live.
There is a lab track alongside the protocol. A path selector routes flows across multiple egress edges with health-gated policy and a measured path matrix. A field control plane enrolls devices with hardware-backed identity, verifies signed command manifests, and runs allowlisted probes with no remote shell.
How I know what works
The project is tracked through a capability register. Every capability is marked field-proven (bounded), lab-proven, unknown or falsified, and each proof points to committed evidence with integrity hashes.
Negative results are kept. A hypothesis about a self-growing network graph was recorded as falsified rather than quietly dropped. An experiment whose outcome was a measurement-harness failure is logged as exactly that, not spun as a win. Attachment through a third-party infrastructure surface was lab-proven, while field reachability and production fitness were explicitly not promoted to proven.
This is the habit I would keep from the project above all others: the register tells you what is not proven, which is more useful than a list of what is.
Honest status
What works: authenticated relay attach, overlay address assignment, presence and network snapshots, session resume and heartbeat recovery, peer packet forwarding, service publishing with relay-mediated service flows, and scoped UDP exit with limits. What is validated live: remote attach to a real relay, a long-held session with heartbeat acknowledgements, and two-client overlay forwarding across separate hosts. The macOS packet plane passed field validation; the overlay use cases are partially validated.
What is not done or not proven:
- the release is marked research-only, and field reachability and production fitness are explicitly unknown;
- a path-mobility experiment across changing carriers came back not confirmed. The architecture looks sound — the inner connection is the continuity invariant and the carrier is disposable — but the measurement harness was the bottleneck and the repetition gate was not reached;
- the TCP/WebSocket fallback is designed but not implemented;
- there is no end-to-end encryption between devices in v1; the relay is trusted;
- the overlay is IPv4-only; no peer-to-peer, no multi-relay, no router/gateway mode;
- padding addresses message size, not timing;
- one macOS teardown defect is still open.
So this is R&D, not a production service. I will not sell it as a production continuity guarantee, and I say so plainly.
What it shows about systems engineering
The protocol itself is the small part. The work is in writing an unambiguous wire specification; choosing a wire image that is genuinely what it claims to be rather than an imitation; separating identity from transport so a device can move without losing itself; making a session resumable without letting the resume token become a master key; proving behaviour on real paths instead of in a diagram; and keeping an evidence ledger that includes the failures.
That last habit is the one I now apply everywhere else: a capability is not real until there is committed proof, and “unknown” is a perfectly good answer.