Appliance experience
Users should see clear states, simple actions, QR flows, guided setup, and plain-language recovery instead of Linux internals.
RelayOS Platform
The appliance operating system for RelayHub nodes.
RelayOS is the local-first platform layer that turns NixOS, Reticulum, hardware profiles, policy governance, recovery, and local web management into a simple communications appliance for ordinary people.
Platform purpose
RelayOS hides complexity without hiding reality.
The goal is not to make users become system administrators. The goal is to give homes, groups, and communities infrastructure they can plug in, pair, understand, update, recover, and safely operate.
Local-first control
Setup, status, recovery, support export, and ordinary management should remain useful without a cloud account.
Honest capability
RelayOS should show what works, what does not, what is degraded, and what is not supported on that node.
Technology stack
NixOS is the foundation. Reticulum is the substrate. RelayOS is the product.
RelayOS does not replace NixOS or Reticulum. It packages them into a governed appliance platform with onboarding, policy, observability, recovery, and support built around real users.
NixOS foundation
Declarative configuration, reproducible builds, rollback-safe updates, hardware profiles, and predictable system behaviour.
Reticulum substrate
Local-first communication across supported transports, intermittent connectivity, store-and-forward behaviour, and heterogeneous nodes.
RelayOS appliance layer
Local dashboard, QR onboarding, pairing, trust, role management, policy gates, updates, recovery, and support export.
User flow
Designed around the first ten minutes.
A RelayHub node must be understandable from the moment it powers on. The first experience should be guided, visible, and recoverable.
1. Start
The node boots and presents a visible state: starting, setup, ready, local-only, degraded, updating, recovering, or error.
2. Claim
The owner scans a QR code, opens the local setup flow, confirms the node identity, and claims ownership.
3. Recover
Recovery is introduced during setup so the user knows how to repair, roll back, reset, or transfer the node safely.
4. Operate
The dashboard explains current state, available communication paths, paired users, updates, events, and next actions.
Core capabilities
RelayOS is more than a Reticulum install.
A technically working node is not enough. RelayOS must make the node understandable, governable, recoverable, supportable, and safe to use.
Onboarding
First boot, setup QR, local browser flow, owner claim, node naming, privacy reality screen, and recovery prompt.
Identity
Node identity, owner identity, user identity, paired device identity, peer identity, and recovery authority.
Trust
Unknown, discovered, paired, trusted, limited, quarantined, and revoked relationships.
Policy
Runtime behaviour governed by hardware limits, recovery rules, legal constraints, trust, roles, and user permission.
Observability
Plain-language state, event history, Reticulum summary, peer summary, storage pressure, update state, and recovery status.
Recovery
Rollback, guided recovery, local recovery portal, support export, reset, transfer, and last-resort reflash guidance.
Capability-aware
Every feature passes through gates before it appears.
RelayOS should never imply that a node can do something merely because hardware exists. Features become visible only when they are supported, permitted, trusted, lawful, enabled, and actually available.
Hardware
What the device can physically support: CPU, RAM, storage, power, thermal profile, network, and radio.
Software
What the installed RelayOS version, Reticulum configuration, firmware, and service graph can support.
Policy
What safety, recovery, legal, privacy, trust, role, and system rules allow.
Runtime
What is actually working right now under current network, power, storage, thermal, and peer conditions.
Operational modes
The node should explain the mode it is in.
RelayOS uses operational modes to change behaviour safely under different conditions. A home node, field node, recovery node, and infrastructure node should not expose the same controls.
Home Mode
Household operation with simple dashboard, local setup, paired users, status, update, recovery, and safe defaults.
Local-Only Mode
Internet or wider network paths are unavailable, but local functions may still work. This is not automatically an error.
Recovery Mode
Guided repair, rollback, reset, transfer, support export, or safe fallback when normal operation cannot continue.
Field Mode
Low-power and transport-conscious operation for field deployments where radio or intermittent links may matter.
Infrastructure Mode
Advanced operation for validated bridge, gateway, DTN, observability, and community infrastructure roles.
Quiet Mode
Reduced discovery visibility where privacy, safety, or community policy requires lower exposure.
Node classes
RelayOS adapts to the device class.
A Radio Micro Node, Home Node, Infrastructure Node, and Mini PC Node have different ceilings. RelayOS should reflect those limits instead of hiding them.
Radio Micro Node
Field relay and radio transport class. Not a full household appliance unless paired with a suitable companion system.
Home Node
Household appliance class focused on setup, local dashboard, pairing, recovery, updates, and ordinary use.
Infrastructure Node
Community infrastructure class for validated gateway, bridge, DTN, observability, and operator roles.
Status language
RelayOS should speak in states people understand.
Technical logs may exist behind advanced views, but the ordinary dashboard should explain the node like an appliance.
Working
The node is running and core services for its current role are available.
Still useful
Local operation works, but wider network access is unavailable.
Reduced
Some capability is reduced, paused, blocked, or waiting for recovery.
Guided repair
The node needs attention and should guide the user toward safe recovery.
Security and privacy posture
Minimum exposure. Explicit trust. Realistic privacy.
RelayOS should avoid hidden remote control, automatic cloud telemetry, internet-exposed administration, and exaggerated privacy promises.
Local API boundary
The appliance control plane should be local-only, role-aware, rate-limited, and paired-client controlled by default.
Support export
Support data should be user-controlled, redacted by default, and should not include secrets or message content unless explicitly designed.
Privacy reality
RelayOS can reduce dependence on central services, but it does not make users invisible or erase metadata risk.
Validation path
RelayOS becomes supported through evidence.
A build should not be called product-supported merely because it boots. It must prove setup, recovery, rollback, documentation, degraded operation, and user comprehension.
1. Development
Internal builds may be incomplete, manual, unstable, or terminal-based. They must be labelled as development.
2. Lab validation
Boot, setup, QR flow, owner claim, dashboard, recovery entry, and default-safe exclusions are tested.
3. Field trial
Non-technical users attempt setup, pairing, local-only interpretation, recovery, support export, and reset understanding.
4. Supported release
Only after recovery, rollback, documentation, privacy claims, support, and hardware compatibility are validated.
For developers
Build modules that strengthen the appliance model.
RelayOS development should create better defaults, clearer states, stronger recovery, safer policy enforcement, and better local-first operation.
Local services
Build setup, discovery, dashboard, event history, support, update, recovery, and capability-reporting services.
Hardware profiles
Define what each device class can safely support and prevent impossible or misleading feature activation.
Validation tools
Build repeatable tests, evidence artefacts, release gates, and field trial feedback loops.
Current status
RelayOS is a platform direction, not yet a supported release.
Public language should remain honest: RelayOS is being designed and validated. Product-supported claims should wait until builds, recovery, documentation, field testing, and release gates are complete.
Follow development
Register interest if you want updates on RelayOS design, node builds, hardware validation, developer resources, documentation, and early community testing.