AeroNyx App and Protocol Architecture
How the durable AeroNyx Protocol relates to the cross-platform app, encrypted identities and messaging, MemChain, decentralized privacy nodes, Nodeboard, and agent coordination.
AeroNyx separates a durable open protocol from the products that use it.
The protocol defines private routing, encrypted identity and communication, node-blind storage, signed node discovery, opaque relay delivery, and verifiable operational evidence. Products turn those rules into usable experiences: the AeroNyx App, decentralized privacy nodes, Nodeboard, MemChain surfaces, and future agent services.
Protocol and product separation
| Layer | Examples | Responsibility |
|---|---|---|
| AeroNyx Protocol | identity rules, encrypted envelopes, routing metadata limits, peer descriptors, relay receipts, MemChain commitments | Defines interoperable behavior and the information infrastructure is allowed to observe |
| User product | AeroNyx App on iOS, Android, macOS, and Windows | Provides privacy-network access, encrypted communication, identity recovery, files, wallet consent, and AI workflows |
| Node infrastructure | independently operated decentralized privacy nodes | Accepts and relays encrypted work, advertises signed capabilities, and reports bounded health evidence |
| Operator product | Nodeboard | Shows capacity, peer health, incidents, recovery, and command audit without exposing user content |
| Private memory | MemChain | Keeps local-first private memory, encrypted synchronization objects, and append-only commitment evidence |
A product can change interface, pricing, or distribution. The protocol boundary should remain stable enough for independent implementations and operators to interoperate.
Product layers
| Capability | Product role |
|---|---|
| Privacy network | User-selected encrypted network access through registered privacy nodes |
| Direct and group messaging | End-to-end encrypted communication under P2P social identities |
| Encrypted media and files | Client-encrypted blobs referenced from E2E message envelopes |
| Identity recovery | User-controlled encrypted .ayx export and import |
| MemChain | Node-blind private memory and synchronization under user-controlled keys |
| Node discovery and relay | Signed peer descriptors, routeability evidence, blind forwarding, and delivery receipts |
| Agent services | Private connectivity, encrypted coordination, and verifiable state exchange for autonomous software |
Financial identity and social identity
AeroNyx separates wallet identity from P2P communication identity.
| Identity | Scope |
|---|---|
| Wallet identity | Assets, membership, subscription, node ownership, and account-level consent |
| P2P identity | Contacts, chat identity, QR or deep-link exchange, message namespace, and social recovery |
The separation limits correlation and gives each identity a suitable recovery lifecycle. Deleting or rotating one social identity must not silently destroy the wallet root or unrelated chat identities.
Encrypted messaging and transport
Message content is encrypted on the sender endpoint before relay transport and decrypted only on an authorized receiver endpoint. Relay infrastructure processes an opaque envelope, a receiver routing identifier, bounded timestamps, replay protection, rate limits, and delivery state; it does not receive message keys.
The current product keeps the centrally operated RelayWS service as the default path for predictable delivery and offline store-and-forward. Users and compatible clients may choose decentralized privacy-node relay paths when available. This choice is explicit: AeroNyx does not claim that every production message already uses a decentralized or multi-hop path.
Contact identity should be verified by public-key fingerprint, QR code, or deep link. Local message databases remain namespaced by the active P2P identity.
Encrypted media and resumable files
Voice, images, video, and files use a ciphertext blob channel rather than placing large payloads inside WebSocket frames. Encryption keys, nonces, filenames, transcripts, and plaintext never enter the blob API.
| Flow | Endpoint | Current limit |
|---|---|---|
| Single upload | POST /api/relay/blob/ | 10 MB |
| Create resumable session | POST /api/relay/blob/session/ | 100 MB total |
| Upload or retry a chunk | PUT /api/relay/blob/session/{upload_id}/chunk/{index}/ | 1 MB default, 4 MB maximum |
| Inspect missing chunks | GET /api/relay/blob/session/{upload_id}/ | Session is valid for 24 hours |
| Complete upload | POST /api/relay/blob/session/{upload_id}/complete/ | Idempotent completion after all chunks arrive |
| Download ciphertext | GET /api/relay/blob/{blob_id}/ | Capability or authenticated access policy |
Blob retention defaults to 7 days and is bounded by backend policy to 30 days. A capability-mode blob_id is an unguessable bearer capability; authenticated mode restricts download to an allowed P2P public-key list. The E2E message carries the blob reference and decryption metadata inside its encrypted payload.
Identity backup, groups, and calls
The .ayx identity backup contains a password-protected encrypted seed payload using a random salt and authenticated encryption. The identity seed is not stored in plaintext inside the file. Import and export remain explicit user actions.
Group communication extends the same model with signed membership operations and encrypted group key state. Voice and video calling must follow the same identity and privacy boundaries, while transport failures should be translated into stable product states rather than raw protocol errors.
The blind-node invariant
Relay nodes, storage nodes, and MemChain coordinators must remain blind to user content.
They may process ciphertext, signatures, bounded route state, timestamps, replay guards, rate limits, capacity, and aggregate counters. They must not receive keys that decrypt messages, packet payloads, DNS content, browsing history, destinations, private files, MemChain plaintext, identity secrets, or stable social-graph edges.
If a user explicitly sends plaintext to an external AI model or another provider, that provider operates under its own terms. The blind-node invariant describes AeroNyx infrastructure; it does not conceal the privacy boundary of a third-party service.
Operations without surveillance
Nodeboard and public statistics should show infrastructure evidence: capacity, connection policy, peer freshness, routeability, restart recovery, file-descriptor and conntrack pressure, packet drops, pps, bps, proof acceptance, and terminal delivery counters.
They should not become user-traffic viewers. Public or operator interfaces must not expose message plaintext, packet payloads, DNS contents, destinations, URLs, client public-IP activity, private memory, contact relationships, or wallet-level traffic.
Agent protocol direction
Autonomous agents need more than a network tunnel. They need private reachability, encrypted messaging, user-controlled memory, scoped credentials, auditable consent, and verifiable state transitions.
AeroNyx can provide those primitives without forcing every agent to trust one application backend. The product direction includes encrypted agent-to-agent envelopes, node-blind MemChain records, optional private routing, independently operated service nodes, and settlement integrations outside the privacy ledger.
Honest deployment boundary
Today, the app uses a centralized relay by default while decentralized relay, multi-hop routing, wider full-node mirroring, and stronger network-diversity controls continue through controlled rollout. Public documentation distinguishes implemented production paths, optional paths, probes, and planned capabilities.
That distinction is part of the architecture: verifiable progress is more valuable than presenting a future network as if it were already universal.