Rollback
Failed updates should not leave a node unusable. RelayHub should support rollback-safe upgrades wherever practical.
Recovery-first design
A system that cannot be recovered should not be called resilient.
RelayHub is intended to behave like an appliance, not a fragile server. Recovery paths should be visible, documented, tested, and safe for ordinary people under stress.
Safe reset
Factory reset must be understandable and should avoid destroying identity or recovery material unless the user clearly chooses that path.
Identity preservation
Node, owner, user, and community identities should survive recovery where possible, with clear limits and documented procedures.
Degraded boot
A damaged or partially failed node should still expose recovery access where practical instead of failing silently.
When something breaks
Users need a clear path, not a terminal panic.
The recovery experience should explain what still works, what is degraded, what changed, what can be attempted safely, and what should not be done without understanding the consequences.
- Open the local web UI.
- Check the visible system status.
- Read the degraded-state message.
- Export a support bundle if available.
- Try guided recovery before factory reset.
- Preserve identity material before replacing hardware.
- Avoid enabling new exposure during recovery.
- Ask for support with logs, status, and context.
Identity continuity
Recovery must respect identity and ownership.
Recovery is not just reinstalling software. RelayHub must distinguish node identity, owner identity, user identity, community identity, trust records, and recovery authority.
Preserve where possible
Safe recovery should preserve identities, trust records, local configuration, and important community data where technically and policy-wise possible.
Reset only with clarity
Destructive reset paths should clearly explain what will be erased, what can be exported, what cannot be recovered, and what ownership consequences follow.
Transfer is not automatic
Recovery must not silently transfer identity, administrative control, or community authority to another person or device.
Boundaries
Recovery has limits, and those limits must be visible.
Recovery cannot undo every physical device failure.
Recovery cannot guarantee restoration of data that was never backed up.
Recovery cannot bypass lawful or regional constraints.
Recovery should not silently transfer identity to a new owner.
Recovery must not expose secrets in support exports.
Recovery claims must be validated before being treated as product-supported.
Support exports
Support should help without exposing secrets.
A future RelayHub support bundle should help diagnose problems while excluding private keys, message contents, sensitive identity material, and unnecessary personal data by default.
Recovery principle
The best recovery system is not merely powerful. It is understandable, observable, reversible where possible, privacy-preserving, and safe for non-technical users.