Setup questions
Understanding first setup, local web UI access, QR pairing, owner claim, early access, and basic site or product questions.
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 scope
What support can help with.
RelayHub support starts with plain explanations, safe next actions, recovery paths, and honest product boundaries. It should help people understand the system without asking them to become server administrators.
Recovery questions
Understanding rollback, safe reset, degraded states, support exports, identity preservation, and what to try before destructive actions.
Hardware questions
Understanding hardware classes, capability limits, supported versus experimental language, and why not every node can do everything.
Developer questions
Discussing RelayOS concepts, Reticulum integration, validation, documentation, future local APIs, and contribution areas.
Community questions
Discussing community pilots, directory concepts, marketplace concepts, governance, trust, federation, and local-first operation.
Website issues
Reporting broken links, form problems, accessibility issues, unclear wording, security concerns, or documentation gaps.
Boundaries
What support cannot honestly promise.
Support should be useful without pretending RelayHub can guarantee every network condition, legal context, hardware state, or recovery outcome.
- RelayHub is not an emergency service.
- RelayHub cannot guarantee message delivery in all conditions.
- RelayHub cannot promise perfect anonymity.
- RelayHub cannot provide legal radio permission for every region.
- RelayHub cannot certify unvalidated hardware as product-supported.
- RelayHub cannot recover data that was never backed up or preserved.
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.
Local-first help
Setup, status, documentation, recovery guidance, and support export should remain useful without requiring a cloud account.
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.
Status help
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.
Not automatically broken
The node may be running correctly even if it has not found other reachable nodes yet.
Reduced capability
Something is limited, unavailable, paused, or blocked, but the node may still be useful.
Do not interrupt
The node may be applying, validating, or rolling back an update while preserving identity and recovery access.
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, validation status, policy limits, and product 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, airtime limits, and RF observability.
Infrastructure support
May include operator diagnostics, DTN queues, bridge/gateway roles, observability, storage, power, federation, and deployment 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.
How to contact support
Give enough context without exposing secrets.
RelayHub support should receive useful information without private keys, recovery secrets, passwords, or message contents.
- Use the contact form for ordinary enquiries.
- Include the page, product area, or hardware class involved.
- Describe what you expected and what actually happened.
- Include screenshots only if they do not expose private information.
- Do not send private keys, recovery secrets, passwords, or message contents.
- For security issues, clearly mark the report as security-related.