Skip to content

v3.0.0

Choose a tag to compare

View all tags
@yosebyte yosebyte released this 12 Oct 23:32
· 90 commits to main since this release
v3.0.0
00000b3

Nowhere 3.0.0

Secure transport. Flexible exits.

Nowhere 3 introduces NW3 and a three-role architecture: Vector connects applications, Portal routes traffic, and Egress provides a remote exit through an outbound QUIC connection.

Important

NW3 is wire-incompatible with NW2. Upgrade all peers on a traffic path together, and verify NW3 support in third-party clients before switching. There is no protocol negotiation or fallback.

Highlights

  • Remote exits with Egress. Place target access behind an outbound QUIC connection, without opening an inbound relay port on the exit host.
  • One connection model. Connection-bound authentication, explicit Flow setup and a single carrier per Vector connection replace session pairing and split transport paths.
  • Three output choices. Portal forwards directly, through a SOCKS5 upstream, or through a registered Egress.
  • Morph enabled by default. Shared-key wire masking applies below TLS and QUIC, with dedicated NW3 key derivation.
  • Focused observability. Passive local telemetry exposes logical TCP/UDP traffic and active Flow counts; service logs remain on stdout and stderr.

Transport and Authentication

Both TLS and QUIC use TLS 1.3 with the fixed nw3 ALPN. Authentication binds each connection to its TLS exporter and distinguishes Vector and Egress roles. Early data is disabled.

TLS dedicates one connection to each Flow. QUIC uses bidirectional Streams for TCP Flows and UDP control, with datagrams carrying UDP payloads.

Portal, Vector and Egress require exactly 32 lowercase hexadecimal characters for the Shared Key. Use nowhere generate-key to generate a key, and configure matching key text on all participating peers.

Remote Egress

Configure Portal with out=egress and connect an Egress using egress://. Target DNS resolution and TCP/UDP dialing take place on the Egress host.

Each Portal accepts one registered Egress connection. If that connection is lost, dependent Flows close and new requests fail immediately. Egress reconnects automatically and registers again; interrupted Flows are not resumed, and Portal does not fall back to direct access.

See the Egress guide for configuration and lifecycle details.

Configuration and Operations

  • Endpoint paths select the carrier, port and address family. Portal can expose TLS and QUIC listeners; Vector selects one carrier, and Egress uses QUIC.
  • Vector provides SOCKS5 ingress through in=.
  • Morph defaults to morph=1. Set morph=0 explicitly to disable it, and keep peers consistent.
  • nowhere status reports local instance identity and traffic statistics without requiring an interactive terminal.
  • nowhere.telemetry publishes passive snapshots over protected local IPC. Its six statistics cover TCP/UDP upload bytes, download bytes and active Flows.
  • Shutdown cancels pending handshakes and Egress registration attempts. Diagnostics preserve underlying error chains.

Upgrade Notes

  1. Update peers together. NW2 clients and servers cannot communicate with NW3. Keep separate deployments while transitioning.
  2. Rebuild service URLs from the current configuration reference. TLS Mux, split up/down routes, session pairing and native next chaining are no longer supported. Use endpoint paths for carrier selection, in= for Vector ingress and out= for Portal output.
  3. Check Shared Keys and Morph settings. Service keys must be exactly 32 lowercase hexadecimal characters; longer keys must be replaced. Morph is enabled by default.
  4. Update monitoring integrations. Telemetry contains identity and six logical statistics, without subscriptions, lifecycle events or resource samples. Use an OpenCtrl build that supports this contract.
  5. Replace interactive TUI workflows. Use nowhere status, service logs or a telemetry-based management interface.

Compatibility

  • NW3 uses new authentication, framing and Morph derivation. Matching keys alone do not make an NW2 peer compatible.
  • Certificate trust remains explicit: clients verify system CA trust and hostname, or an exact SHA-256 certificate pin. Morph does not replace certificate verification.
  • Third-party clients and controllers must implement the current wire and telemetry contracts; compatibility should not be inferred from URL schemes or contract names alone.

Documentation

Full Changelog: v2.2.1...v3.0.0

Assets 10
Loading