What is RelayHub?
A local-first ecosystem for communication, coordination, recovery, knowledge sharing, trade, governance, and resilient communities.
Documentation
Documentation is part of the product.
RelayHub documentation is designed to help ordinary people set up, understand, operate, recover, and safely evaluate local-first communication infrastructure without needing to become Linux, networking, or radio experts.
Start here
The first guides should answer the first questions.
RelayHub documentation should begin with clear, practical guidance: what the system is, what it is not, what the user can do now, and what to do when something changes state.
What is RelayOS?
The appliance platform that turns NixOS, Reticulum, policy, recovery, and local management into a usable node experience.
What is a node?
A device running RelayOS and participating in the RelayHub ecosystem according to its hardware class, role, policy, and validation status.
User guides
Guides for ordinary users.
These guides should avoid unnecessary jargon and focus on what the user sees, what it means, and what action is safe.
Quick start
Plug in the node, wait for setup status, scan the QR code, claim ownership, save recovery, and reach the dashboard.
First setup
Browser-first setup, owner claim, privacy reality screen, recovery prompt, node naming, readiness check, and first dashboard.
Pairing and invites
How owners, household admins, trusted users, guests, and recovery contacts pair safely using role-aware QR flows.
Status meanings
Understand Ready, Local-Only, No Peers, Degraded, Low Power, Updating, Rolled Back, Recovering, Factory Reset, and Error.
Local-only operation
Local-only does not mean broken. It means local functions may still work even when wider paths are unavailable.
Recovery guide
Restart, rollback, repair settings, restore access, support export, reset, transfer, and last-resort reflash guidance.
Core documentation areas
Documentation should follow the product architecture.
RelayHub documentation needs to explain the platform, node families, hardware classes, privacy limits, recovery model, support model, and future community applications.
RelayOS
Platform overview, local web UI, policy gates, identity, trust, recovery, updates, observability, and Reticulum integration.
Products
Relay Home, Relay Radio, Relay Infrastructure, product status, support boundaries, and future application families.
Hardware
Hardware classes, compatibility status, capability limits, recovery expectations, radio reality, and product-supported claims.
Communities
Households, groups, community operation, knowledge, trade, governance, continuity, and voluntary federation.
Developers
Development stack, contribution expectations, validation discipline, hardware profiles, local services, and future apps.
Support
Local help, support levels, redacted diagnostics, recovery paths, hardware-aware support, and explicit export.
Status and recovery
The most important documentation explains what still works.
RelayHub should not leave users guessing. Every degraded state should explain what changed, what still works, what no longer works, and what to do next.
Your node is ready.
The node is running and the core services for its current role are available.
Local communication may still work.
Wider connectivity is unavailable, but local operation is not automatically broken.
Reduced capability.
Some features are limited, paused, blocked, or waiting for recovery.
This node needs attention.
Recovery should guide the user toward safe repair, rollback, reset, transfer, or support export.
Offline documentation
Critical help should not disappear when the internet fails.
RelayHub documentation should include online pages, local node help, and printable/offline material for setup, status, recovery, privacy, and support.
Quick Start Card
The minimum steps to power on, scan setup, claim ownership, save recovery, and reach the dashboard.
Status Meaning Card
Plain-language explanation of lights, status labels, degraded states, local-only operation, recovery, and error messages.
Recovery Card
Where recovery is found, what recovery can do, what it cannot do, and when reset, transfer, or reflash may be required.
Privacy Reality Card
RelayHub can reduce dependence on central services, but it does not make users invisible or remove every metadata risk.
Support Export Guide
What support export includes, what it excludes, how redaction works, and why export should be explicit.
Radio Warning Card
Region, frequency, power, duty-cycle, encryption, receive-only, and legal responsibility guidance for radio-capable variants.
Documentation standards
Good documentation is honest documentation.
RelayHub documentation should make clear distinctions between what exists, what is planned, what is experimental, what is unsupported, and what is product-supported.
Plain language first
User-facing material should avoid unnecessary Linux, networking, Reticulum, radio, and cryptography jargon.
No exaggerated claims
Documentation must not claim perfect anonymity, guaranteed delivery, universal emergency coverage, or automatic lawful radio operation.
Recovery included
Every important product guide should explain failure modes, rollback, recovery, reset, transfer, and support boundaries where relevant.
Versioned guidance
Guides should clearly state which product, hardware class, RelayOS version, or release status they apply to.
Evidence-aware
Product-supported claims should be tied to validation, compatibility, recovery, and release gates.
Accessible by design
Documentation should be readable, mobile-friendly, searchable, printable, and useful under stress.
Developer and operator docs
Technical documentation should support validation, not bypass it.
Developer and operator documentation can go deeper, but it should still preserve the same rules: local-first, recovery-first, capability-aware, policy-governed, and validation-gated.
Architecture notes
RelayOS layers, Local API design, policy engine, Reticulum integration, observability, and service boundaries.
Hardware manifests
Capability manifests, hardware classes, supported roles, known limits, thermal/power profiles, and compatibility status.
Validation artefacts
Boot evidence, setup proof, recovery drills, rollback tests, field trial results, support export tests, and release gates.
Current docs status
Documentation will grow with validation.
RelayHub is still in design and validation planning. Documentation should clearly mark draft, planned, experimental, and product-supported material as the project matures.
Follow documentation releases
Register interest for updates about quick starts, recovery guides, hardware compatibility notes, RelayOS documentation, developer resources, and future community guides.