Eryon
Documentation

Independent mesh network · in development

Eryon.

Private Network

A decentralized mesh network project for protected communication between devices and services over the infrastructure you already operate.

The managed Linux dataplane, Control policy, and terminal interfaces are under active development. Multi-host connectivity and public release distribution are not yet verified.

Documentation Get startedExplore architecture
Control-managedUDP dataplaneLinux node focus
NETWORK / CONCEPTUAL VIEW LOCAL TESTS
Conceptual Eryon mesh topologyThree nodes exchange encrypted traffic over direct links. A relay can provide a separate ciphertext path. Control distributes membership and policy but does not carry overlay traffic. CONTROL PLANEmembership · topology · policy NODE ADEVICE NODE BTRANSIT CAPABLE NODE C NODE D RELAY
Conceptual architecture, not a live topology or availability view. Relay path is separate from Control.
Node Control exchange Optional relay path
CURRENT DELIVERY STATUS

Control-managed topology and ACL, MeshDaemon IPC, and the standalone installer exist in the source tree. No production release is published.

01 / Architecture

Separate coordination from traffic.

Control configures membership and authorized topology. Nodes establish encrypted data-plane sessions and forward overlay packets when a route and policy allow it.

CONTROL PLANE

Membership & policy

Enrollment, network-scoped devices, signed configuration snapshots, topology policy, ACL rules, and rendezvous coordination.

Does not route user packets
DATA PLANE

Peer sessions & packets

MeshDaemon owns UDP, TUN, peer sessions, route state, packet validation, forwarding, NAT traversal, and optional encrypted relay transport.

Node-to-node overlay traffic
01

Eryon Core

Application-facing runtime, local registry, and a read-only IPC adapter to the managed daemon.

02

DVeMesh

Control-managed Linux mesh agent and the sole owner of overlay dataplane resources.

03

DVeProto

Identity, handshake, encrypted session framing, and transport primitives used by the mesh.

The components remain separately versioned. The public compatibility and release contract is still being established.

02 / Packet path

From identity to delivery.

This is the implemented DVeMesh flow at a high level. WAN behavior remains unverified, and successful packet delivery depends on routes, ACL, UDP reachability, and a live next hop.

  1. 01

    Device identity

    A node has a persistent Ed25519 identity. Enrollment proves possession and associates the public NodeID with a Control network device.

  2. 02

    Peer discovery

    Control delivers authorized peer data and endpoints in a signed configuration snapshot.

  3. 03

    Secure session

    Nodes attempt authenticated DVeProto sessions over UDP; direct connectivity and NAT traversal are best effort.

  4. 04

    Route exchange

    Authenticated peers advertise reachable overlay addresses. Learned routes expire and reject paths that loop through the local node.

  5. 05

    Policy check

    The packet pipeline validates IPv4 packets and evaluates the network ACL. Unmatched traffic is denied.

  6. 06

    Transit forwarding

    When an authorized next hop and route exist, a node may forward an encrypted transit envelope with a bounded hop limit. Multi-host delivery is not yet verified.

03 / Security model

Use established primitives. State the limits.

DVeProto and DVeMesh implement cryptographic identity, session establishment, encrypted frames, and replay checks. These statements describe code paths, not an independent security certification.

Read the security notes
IDENTITY

Ed25519
Node identity, signatures, and signed protocol messages.

KEY EXCHANGE

X25519 + HKDF-SHA256
Ephemeral key agreement and directional session keys.

TRAFFIC

AEAD
AES-GCM or ChaCha20-Poly1305 in the DVeProto v2 session layer.

SESSION CHECKS

Signed handshake, Finished MAC, replay window
DVeMesh also validates signed peer identity and network metadata before health verification.

04 / Terminal first

Operate the managed node from the CLI.

Eryon reads MeshDaemon state over its local read-only Unix socket. It does not create a second dataplane or change Control authorization.

CLI reference
eryon · local commands
$ eryon --help
$ eryon doctor
$ sudo eryon daemon status
$ sudo eryon network status
$ sudo eryon peers
$ sudo eryon routes
$ sudo eryon sessions

05 / Get started

Read first. Enroll only into a test network.

There is no public production release yet. Start with the project guide, inspect current host requirements, then use a disposable Linux host and a test Control network for enrollment experiments.

Getting started Release status