Node Discovery and Encrypted Multi-Hop Relay

AeroNyx nodes find each other through signed, expiring descriptors and can forward end-to-end encrypted payloads hop by hop, with each relay removing only its own layer of encryption. Today, real user chat goes through the central AeroNyx relay (RelayWS) by default. Routing chat through nodes is an opt-in setting in the app.

What runs today

All production nodes are operated by AeroNyx today. Centralized and decentralized paths run side by side.

How discovery works

Each node publishes a descriptor signed with its Ed25519 identity key. A descriptor includes the node ID, issue and expiry times, an optional public endpoint, capability flags (such as onion middle relay or chat relay), coarse capacity hints and the key used for onion encryption. Nodes reject descriptors that are expired or carry an invalid signature.

• Gossip is bounded. Peer exchange is rate-limited and policy-gated, and messages have size limits.
• Restart recovery. A node keeps a local peer cache and falls back to configured seed endpoints after a restart.
• Route selection. Only fresh descriptors with a usable endpoint and onion key are considered as relay candidates.

Which endpoints a descriptor may name

A signature proves who published a descriptor, not that its endpoint is safe to contact. A node therefore accepts only two forms of endpoint:

• a public IP address over http or https; loopback, private, link-local, CGNAT, documentation, multicast and reserved ranges are rejected;
• an https:// URL with a public DNS name. Single-label names, localhost and private suffixes such as .local, .internal and .home.arpa are rejected.

Hostnames are resolved at connect time through a resolver that drops every non-public address, so a name cannot be pointed at the node itself, a private network or a cloud metadata service. Peer clients also ignore proxy settings and never follow redirects.

The hostname form exists so that nodes without an IP address of their own, such as a TEE node behind a cloud gateway, can take part.

The Directory Chain

Each node also keeps a signed, hash-linked history of its own descriptor events, called its Directory Chain. Other nodes can mirror that history, fetch descriptor objects and request inclusion proofs for a specific descriptor. Operator-pinned peers can sign observation checkpoints over the histories they have seen.

There is no global ledger and no single coordinator: each node signs its own history, and others mirror and check it.

How multi-hop relay works

1. The sender wraps the payload in one layer of encryption per hop, using each relay's published onion key.
2. Each relay checks the previous hop's signature, timestamp and replay state, removes its own layer and forwards the remaining opaque blob. It never sees the inner layers.
3. The final (terminal) node delivers or stores the payload and returns a signed receipt. The receipt binds the route ID, a commitment to the payload, the terminal node's identity and the delivery time.

The protocol accepts at most three verified relay hops. The app's privacy route uses two. Abuse limits on relays are described in Blind Relay Abuse Guard.

Chat in the app

• Default: messages go through the central RelayWS service. Message content is end-to-end encrypted, but the service handles delivery metadata. See Chat relay client integration.
• Privacy route (opt-in, off by default): when it is on and a route is ready, the app sends one-to-one messages over the two-hop onion route first. If no onion route accepts the message, the app holds it on the device and does not use the standard relay unless you approve that for the message.
• Anonymous mailbox (beta): a separate drop that works only while connected to the privacy network. Ordinary conversations do not use it.

TEE node

One production node runs inside a Phala Cloud trusted execution environment (dstack on Intel TDX). It serves only as an anonymous mailbox and onion relay: its VPN is disabled, MemChain is off, and its identity key comes from the dstack key service. It is reachable only through a TLS hostname on the gateway, which is why hostname endpoints were added. The app does not currently verify the node's TEE attestation.

Live status

Aggregate network status is published at:

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

Relay and discovery aggregates appear under data.protocol_status, for example peer_store.blind_relay and peer_store.peer_quorum. Note two points when reading them:

• Node-level aggregates count only nodes with a heartbeat in the last 120 seconds, so an offline node drops out of counts such as protocol_status.reported_nodes. network.total_nodes and network.vpn_nodes still count registered active nodes, online or not.
• Synthetic probe counters (probe_*, two_hop_probe_*) measure path health. They are not user traffic.

The public response contains only counts, status buckets and timestamps. It never includes node IDs, endpoints, route IDs, payloads, recipients, client IP addresses, DNS data or social-graph edges. See Network stats and privacy boundary.

Frequently asked questions

Do my AeroNyx chat messages go through decentralized nodes?

Not by default. Messages go through the central RelayWS service. You can turn on the privacy route in the app, which sends one-to-one messages over a two-hop onion route through nodes when one is ready. If no route accepts a message, the app holds it until a route is available or you approve sending that message through the standard relay.

Can a relay node read the messages it forwards?

No. A relay removes only its own encryption layer and forwards an opaque blob. Message content is also end-to-end encrypted between the people in the conversation.

What is the Directory Chain?

The Directory Chain is each node's own signed, hash-linked history of its descriptors. Other nodes mirror it and can request inclusion proofs. It has no global coordinator.

How can a node behind a gateway join the network?

It can publish an https:// hostname as its endpoint. Other nodes resolve that name at connect time and use only public addresses, so the name cannot be redirected to private or internal targets.

Why does the public stats page show more registered nodes than online nodes?

network.total_nodes and network.vpn_nodes count registered active nodes whether or not they are online. Compare them with network.online_vpn_nodes. The protocol and forwarding counts only include nodes with a fresh heartbeat.