Local-first help
Setup, status, documentation, recovery guidance, and support export should remain useful without requiring a cloud account.
Support
Support should protect the user.
RelayHub support is designed around local help, clear recovery, honest product status, hardware-aware guidance, and explicit diagnostic export — not hidden remote control or automatic cloud telemetry.
Support doctrine
Recovery comes before escalation.
A RelayHub node should help the user understand what happened, what still works, what does not work, and what safe recovery path is available before support becomes complicated.
Explicit export
Support information should be shared only when the user chooses to export it. Automatic support upload is not part of the current posture.
Redacted by default
Support exports should exclude message content, private keys, recovery secrets, and unnecessary identities by default.
Support levels
Support should be clear about what is shared.
RelayHub support levels separate ordinary help, basic status, redacted diagnostics, operator diagnostics, and recovery-sensitive material.
Local help
Offline help, setup guidance, LED or status meanings, local-only explanations, and recovery instructions. No diagnostic export required.
Basic status
Product class, hardware class, software version, current state, update state, recovery availability, and simple warnings.
Redacted diagnostics
Redacted logs, service health, update history, rollback status, hardware summary, and Reticulum service summary.
Operator diagnostics
Advanced diagnostics for infrastructure-class nodes and operators. Not expected for ordinary Home Node support by default.
Recovery-sensitive export
Recovery-related material only where explicitly designed, authorised, protected, and necessary.
Review before sharing
Users should be able to see what categories are included and excluded before sending a support bundle.
What support should explain
The user should never be left guessing.
RelayHub support should explain the node state in plain language and guide the user toward the safest next action.
Working
The node is running and the core services for its current role are available.
Still useful
Local functions may still work even when internet, peers, or wider network paths are unavailable.
Reduced capability
Something is limited, unavailable, paused, or blocked, but the node may still be useful.
Needs attention
The node should guide the user toward repair, rollback, reset, transfer, support export, or last-resort recovery.
Hardware-aware support
Support depends on the node class.
A Radio Micro Node, Home Node, Infrastructure Node, and Mini PC Node do not have the same support expectations. RelayHub support must respect hardware capability and validation status.
Home Node support
Focused on appliance operation: setup, pairing, status, local dashboard, update, rollback, recovery, support export, reset, and transfer.
Radio support
Must distinguish hardware capability, firmware status, legal region, transmit permission, antenna setup, and RF observability.
Infrastructure support
May include operator diagnostics, DTN queues, bridge/gateway roles, observability, storage, power, and federation-related issues.
Recovery paths
A recoverable node is a supportable node.
RelayHub support should preserve identity, bootability, recovery access, Reticulum core operation where possible, and safe user control before convenience features.
Restart
The safest first step for simple runtime faults, where appropriate.
Rollback
A failed update should return to the previous working version or enter guided recovery.
Repair settings
Restore safe configuration without destroying ownership or identity where possible.
Restore access
Recovery authority should help regain control without enabling unauthorised takeover.
Factory reset
Destructive reset should be deliberate, explained, and never accidental.
Reflash
Reflash or rebuild guidance should be treated as a last resort, not ordinary user support.
Privacy and security
Support must not become hidden surveillance.
RelayHub support should minimise exposure, avoid automatic cloud telemetry, and make support export explicit, reviewable, and limited.
Included by default
- Product class
- Hardware class
- Software version
- Current node state
- Update and rollback status
- Recovery availability
- Redacted service health
Excluded by default
- Message content
- Private keys
- Recovery secrets
- Authentication credentials
- Unnecessary identities
- Unredacted private logs
- Hidden remote access
Current support status
RelayHub is not yet in product-supported release.
Public support will expand as the product moves through design, development, lab validation, field testing, limited deployment, and supported release.
Design support
Website, documentation, support model, recovery language, and product boundaries are being developed.
Lab support
Internal builds and hardware profiles will need repeatable support and recovery evidence.
Field support
Early testers will need clear instructions, feedback channels, recovery guides, and support boundaries.
Product support
Supported products require validated recovery, documentation, redaction, update safety, and hardware compatibility.
Need help?
Support channels are coming as the product matures.
For now, register interest if you want updates about RelayHub products, documentation, early testing, hardware validation, or developer participation.
Contact
General enquiries can be directed to:
hello@relayhub.tech