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, Reticulum, or radio experts.
Start here
The first guides should answer the first questions.
RelayHub documentation begins with what the system is, what it is not, what the user can do now, what remains planned, and what to do when the node changes state.
User guides
Guides for ordinary users.
These guides should focus on what the user sees, what it means, what still works, 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.
Documentation hub
Core documentation areas.
RelayHub documentation follows the product architecture: products, hardware classes, RelayOS, trust, security, recovery, validation, governance, and support.
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.
RelayOS
Platform overview, local web UI, policy gates, identity, trust, recovery, updates, observability, and Reticulum integration.
Trust
Discovery, identity, reachability, permission, reputation, federation, revocation, and safe trust-state transitions.
Security
Responsible disclosure, realistic threat boundaries, service exposure, least privilege, support redaction, and security posture.
Recovery
Rollback, safe reset, identity preservation, degraded boot, support exports, and practical recovery boundaries.
Validation
Release gates, hardware class testing, recovery drills, degraded operation, supported status, and experimental boundaries.
Governance
Principles, policies, trust model, community autonomy, recovery expectations, validation discipline, and responsibilities.
Support
Local help, support levels, redacted diagnostics, recovery paths, hardware-aware support, and explicit export.
Community documentation
RelayHub is more than messaging.
Community documentation should explain coordination, knowledge sharing, trade, governance, culture, federation, discovery, and trust boundaries.
Communities
Households, groups, community operation, knowledge, trade, governance, cultural continuity, and voluntary federation.
Community directory
Future directory concept for discovery, visibility, community identity, trust status, and federation boundaries.
Marketplace
Local goods, services, requests, skills exchange, community noticeboards, and settlement-neutral coordination.
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.
No reachable peers found.
The node may be working correctly even if no other nodes are currently visible.
Reduced capability.
Some features are limited, paused, blocked, or waiting for recovery.
Update in progress.
The node should preserve identity and recovery access while applying or rolling back updates.
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, radio reality, transfer, reset, and support.
- Quick Start Card
- Status Meaning Card
- Recovery Card
- Privacy Reality Card
- Support Export Guide
- Factory Reset / Transfer Warning Card
- Radio Warning Card where applicable
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.
Use plain language before technical language.
Distinguish implemented, planned, experimental, unsupported, and product-supported behaviour.
Explain degraded operation as normal, not catastrophic.
Include recovery paths wherever failure is possible.
Avoid exaggerated claims about anonymity, delivery, emergency coverage, or radio legality.
Version guides against product, hardware class, RelayOS version, and release status.
Keep documentation readable, mobile-friendly, printable, and useful under stress.
Treat documentation as part of validation, not as marketing decoration.
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, service boundaries, and ADRs.
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, limited, unsupported, 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.