1. Plug in
The node starts, checks itself, and shows a simple status such as setup, ready, local-only, degraded, updating, or recovery.
How it works
Plug in. Scan. Connect.
RelayHub is designed to make advanced local-first communication infrastructure feel like an appliance: power the node, open the local setup flow, scan the QR code, pair safely, and communicate where supported.
The simple version
The user should not need to understand the infrastructure.
RelayHub hides technical complexity behind a local web interface, plain-language status, QR onboarding, role-aware pairing, and guided recovery. Internally, the system remains policy-governed, hardware-aware, and validation-gated.
2. Open setup
The user opens a local browser-based setup flow from a phone, tablet, laptop, or desktop where supported.
3. Scan QR
QR codes are used for setup, pairing, invites, recovery, transfer, and support flows where appropriate.
4. Connect
Users communicate through validated communication paths where hardware, software, trust, policy, and runtime conditions allow.
What is inside the appliance?
RelayOS brings the layers together.
RelayHub nodes are powered by RelayOS: the appliance platform that combines reproducible system configuration, Reticulum communication, local APIs, policy decisions, capability awareness, observability, updates, and recovery.
NixOS foundation
Provides declarative configuration, reproducible builds, rollback-safe upgrades, and hardware-specific system behaviour.
Reticulum substrate
Provides the local-first communication substrate for supported transports, intermittent connectivity, and store-and-forward behaviour.
RelayOS appliance layer
Provides setup, pairing, trust, roles, policy gates, dashboard, updates, recovery, support export, and user-facing state.
First boot
The first ten minutes matter.
A RelayHub node should be understandable from the first time it powers on. The first experience should establish ownership, explain privacy limits, create or acknowledge recovery, and show current status.
Setup state
An unclaimed node presents a setup-safe state. Management actions remain unavailable until ownership is established.
Owner claim
The owner confirms the physical node, claims it, names it, and becomes responsible for users, recovery, updates, reset, and transfer.
Recovery prompt
Recovery is introduced during setup because recovery should exist before something goes wrong.
QR onboarding
QR codes are product flows, not just links.
RelayHub uses QR codes to make setup and trust flows understandable. Each QR should have a purpose, scope, expiry or revocation where appropriate, and safe failure behaviour.
Setup QR
Starts first owner claim or setup flow without exposing long-term keys, recovery secrets, or unrestricted admin credentials.
Invite QR
Lets an owner or permitted admin invite a trusted user, guest, or household member with role and expiry clearly shown.
Recovery QR
Helps enter recovery or validate a recovery flow without bypassing recovery authority checks.
Transfer QR
Supports ownership transfer while ensuring the previous owner is revoked or the transfer fails safely.
Support QR
May identify a support context or help path, but should not grant node access by itself.
Safe failure
Expired, invalid, already-used, wrong-node, or incompatible QR codes should fail with a plain-language explanation.
Local-first operation
Local does not mean limited. It means less dependent.
RelayHub should remain useful when internet access, DNS, cloud services, overlays, peers, or wider routes are unavailable. Local-first operation reduces dependency without pretending every condition can be overcome.
Works locally where supported
Setup, dashboard, recovery, support export, event history, and local help should remain available from the local network wherever practical.
Explains wider failure
If wider network paths fail, the node should explain that local functions may still work instead of presenting total failure.
Status model
The node should say what is happening.
RelayHub status language should be plain enough for a stressed household user and precise enough for an operator to know what changed.
Core function available
The node is running and core services for its current role are available.
Wider paths unavailable
Local operation may still work even though wider connectivity does not.
Reduced capability
Some services are reduced, paused, blocked, unavailable, or awaiting action.
Needs attention
The node should guide the user toward recovery, rollback, reset, or support.
Capability gates
Every feature must pass the gates.
A RelayHub node should not expose impossible, unsafe, illegal, unsupported, or currently unavailable capabilities merely because a component exists.
Hardware capability
The physical limits of compute, memory, storage, radio, power, thermal profile, and network interfaces.
Software capability
What RelayOS, firmware, Reticulum configuration, and service modules actually support.
Policy permission
What safety, recovery, privacy, security, legal, trust, role, and community policies allow.
Runtime availability
What is actually available right now under current power, storage, transport, peer, and network conditions.
Products in practice
Different products serve different jobs.
RelayHub separates household appliances, radio nodes, and infrastructure nodes so users are not misled about what a device can do.
Relay Home
Household node for local dashboard, setup, pairing, status, support export, updates, rollback, and guided recovery.
Relay Radio
Field relay and radio-assisted transport where hardware, firmware, region, law, policy, and validation allow.
Relay Infrastructure
Community infrastructure node for validated DTN, bridge, gateway, observability, federation, and operator functions.
Communication paths
Communication depends on validated paths.
RelayHub should never claim communication is available unless at least one supported communication path exists for the node, user, client, and current runtime conditions.
Local path
Communication or management may work within the local network where supported, even without wider connectivity.
Reticulum path
Reticulum provides the communication substrate, but reachability, peers, queues, and routes still matter.
Client path
Messaging may require a compatible client or future RelayHub application. The node should explain the supported path clearly.
Recovery-first design
Failure should lead to guidance, not panic.
RelayHub treats recovery as a primary product behaviour. A failed update, interrupted setup, lost network path, or degraded service should produce a clear state and a safe next action.
Rollback
Failed updates should return to a previous working version or enter a guided recovery path.
Reset and transfer
Destructive actions should explain consequences and require deliberate confirmation.
Support export
Support information should be explicit, reviewable, redacted by default, and locally downloadable where practical.
Radio reality
Radio transmit is never automatic.
If a RelayHub product uses radio, radio operation must respect hardware, firmware, region, legal rules, power limits, duty cycle, policy, user enablement, and runtime state.
Legal region
Frequency, transmit power, duty cycle, encryption, and licensing rules vary by region.
RF observability
Radio signals may be observable. RelayHub should never claim radio use makes users invisible.
Receive-only fallback
Some environments may require transmit to remain disabled or receive-only until rules and policies are satisfied.
Community layer
The system exists to serve communities.
RelayHub begins with communication infrastructure, but the longer-term goal is to support resilient communities through trust, knowledge, trade, coordination, governance, and cultural continuity.
Households
Local infrastructure for families, homes, rural properties, and trusted small groups.
Communities
Local networks for communication, knowledge sharing, events, trade, directories, and practical coordination.
Federations
Voluntary cooperation between communities without requiring central control or surrendering local autonomy.
Current status
RelayHub is being built carefully.
The operating model, product family, hardware classes, documentation, recovery model, support model, and validation pathway are being designed before product-supported claims are made.
Follow the build
Register interest for updates on RelayHub nodes, RelayOS, hardware validation, documentation, support, developer resources, and community pilot programs.