Detected is not supported
A radio chip, Ethernet port, Wi-Fi adapter, or storage device being detected does not mean the feature is product-supported.
Hardware
Hardware matters.
RelayHub is capability-aware. A small field relay, household node, and infrastructure node should not pretend to do the same job.
Hardware doctrine
Capability before claims.
RelayHub separates hardware capability, software capability, policy permission, runtime availability, trust permission, legal permission, and user enablement. A feature is not available merely because a device has the parts for it.
Supported is not active
A supported capability may still be disabled by policy, trust rules, legal requirements, user settings, or current runtime conditions.
Active is not guaranteed
Network paths, peers, radio conditions, power, storage, heat, and transport availability can change. RelayHub must explain current state.
Hardware classes
Different devices have different ceilings.
RelayHub hardware classes describe what a device is realistically suitable for. They prevent small nodes from being marketed as infrastructure and prevent infrastructure nodes from being treated like simple household appliances.
Radio Micro Node
Small radio transport and field relay class, such as LilyGo-style radio boards. Useful for radio movement, not a full local server.
Nano Linux Node
Lightweight Linux relay class for constrained compute and storage. Suitable for limited relay roles, not full household UX unless validated.
Home Node
Household appliance class focused on setup, pairing, local dashboard, status, updates, support export, and guided recovery.
Strong Home Node
Enhanced household class with more comfortable performance, larger queues where validated, and stronger local service capacity.
Infrastructure Node
Community infrastructure class for validated DTN, bridge, gateway, observability, operator dashboard, and larger storage roles.
Mini PC Node
Full infrastructure class for advanced community or regional deployments, larger storage, stronger compute, and operator-heavy workloads.
Product mapping
Product names and hardware classes are related, but not identical.
Relay Home, Relay Radio, and Relay Infrastructure are product families. Each may map to one or more hardware classes only after validation.
Relay Home
Expected to target Home Node and Strong Home Node classes. It should prioritise household usability over infrastructure features.
Relay Radio
Expected to target Radio Micro Node and field relay classes. It must clearly explain radio limits, legal constraints, and validation status.
Relay Infrastructure
Expected to target Infrastructure Node and Mini PC Node classes for operator-led community infrastructure where policy allows.
Compatibility status
“Works on my desk” is not product support.
Hardware must move through explicit compatibility states before it is presented as supported. This protects users from misleading expectations.
Candidate
Hardware is being considered but has not yet proven reliable operation.
Boots
The system starts, but core services, recovery, and support may not work.
Reticulum works
Reticulum can operate, but the product appliance flow may still be incomplete.
Stable
Repeated operation is promising, but product support still requires recovery, documentation, and validation gates.
Product-supported
The device has passed required validation, recovery, documentation, support, and release gates for a defined role.
Deprecated
Previously supported but no longer recommended for new deployments.
Unsupported
Not supported for RelayHub product use, even if experimental builds boot.
Unknown
Not yet tested. No capability, support, recovery, or safety claim should be made.
Radio reality
Radio transmit is never assumed.
Radio hardware does not automatically mean radio operation is enabled, lawful, private, reliable, or supported. Radio features must pass hardware, firmware, regional, legal, policy, user, and runtime gates.
Legal region
Frequency, power, duty cycle, encryption, and licensing rules vary by region. RelayHub must not assume global legality.
RF visibility
Radio use can be observed. RelayHub must not claim that radio operation is invisible or automatically anonymous.
Receive-only fallback
Some environments may require receive-only or disabled transmit modes until legal and policy requirements are satisfied.
Recovery expectations
Hardware must be recoverable to be supportable.
RelayHub hardware should not be considered product-supported unless users have a realistic way to restore safe operation when something goes wrong.
Identity preservation
Recovery should preserve node identity and owner authority where possible, and explain consequences where preservation is not possible.
Rollback safety
Updates should roll back to a previous working state or enter guided recovery rather than leaving a silent broken node.
Offline recovery
Critical recovery instructions should remain available locally or offline, not only through an internet service.
Current hardware direction
Start with the smallest supportable product.
RelayHub should begin with the smallest useful, recoverable, validated household node before expanding into radio, infrastructure, marketplace, federation, and advanced community services.
Home Node class
Focus on household usability, QR setup, local dashboard, recovery, updates, support export, and no-terminal operation.
Radio validation
Validate radio transport carefully, with lawful operation, receive-only fallback, duty-cycle awareness, and realistic RF privacy language.
Infrastructure expansion
Expand into stronger nodes only after recovery, observability, operator documentation, and support processes are ready.
Hardware interest
Help validate real-world hardware.
Register interest if you want updates about RelayHub hardware classes, home nodes, radio nodes, infrastructure nodes, field testing, or future compatibility registries.
Current status
Hardware support is in design and validation planning. Product-supported hardware claims will be published only after testing, documentation, recovery, and release gates are complete.