Frequently asked questions.

RelayHub is a local-first ecosystem for resilient communities. It is being designed to help households, groups, and communities communicate, coordinate, share knowledge, trade, govern, recover, and remain connected when ordinary infrastructure is unavailable, unreliable, or unsuitable.

No. Messaging is one important use case, but RelayHub is broader than a chat app. It is an ecosystem for community infrastructure, trust, discovery, knowledge sharing, local coordination, recovery, marketplace services, and future applications built around local-first operation.

RelayOS is the planned appliance platform that powers RelayHub nodes. It is intended to provide onboarding, local web management, recovery, updates, observability, policy enforcement, Reticulum integration, local APIs, and hardware-aware service activation.

No. Reticulum is the communications substrate. RelayHub uses Reticulum as core infrastructure, while RelayOS and the wider RelayHub ecosystem add appliance-level usability, onboarding, recovery, policy governance, documentation, community services, and product validation.

RelayHub exists because communities should not depend entirely on fragile, centralised, always-online systems to communicate, organise, preserve knowledge, coordinate resources, and recover from disruption. The goal is not isolation. The goal is resilient interconnection.

Local-first means useful local operation comes before remote dependency. Setup, dashboard access, recovery, local status, local discovery, and supported local communication should work without requiring a cloud account or continuous internet connection.

No. Local-first does not mean anti-internet or permanently offline. Internet-assisted features can be useful. The difference is that remote services should enhance local capability, not become hidden dependencies for basic operation.

RelayHub is currently in the design, build, and validation stage. Early access registration is available, but product-supported hardware should only be offered after capability, recovery, usability, documentation, and validation gates are ready.

Not as a fully product-supported device yet. RelayHub should not be sold as a finished appliance until the core setup, recovery, update, support, privacy, hardware compatibility, and validation requirements have been proven.

The primary early product target is a Home Node: a household appliance-style node that can be plugged in, discovered locally, paired through a QR or local web flow, managed through a browser, and recovered safely if something goes wrong.

The early direction is professionally home-built or small-batch built rather than mass factory production. That still requires disciplined validation, clear documentation, hardware compatibility records, safe recovery procedures, and honest product claims.

Product-supported means a device, feature, or release has passed defined validation gates. It should have documented hardware support, tested setup, tested recovery, clear update behaviour, realistic privacy wording, support export, and reproducible evidence that it works as claimed.

Yes. The Early Access page exists for people who want to follow the project, test future builds, ask about pilot deployments, or help shape the product before wider availability.

That is the product goal. The target experience is: plug in the node, open the app or local web UI, scan a QR code, pair, and communicate where supported. The user should not need to understand Linux, NixOS, Reticulum internals, routing, radio, or system administration.

No. Ordinary setup should not require SSH, shell commands, editing configuration files, or reading system logs. Advanced operator tools may exist, but the normal household setup path should be browser-first and guided.

The early Home Node direction is browser-first for setup, dashboard, recovery, support export, reset, and transfer. Native apps may come later, but they should not be required for the basic appliance experience.

The intended flow is simple: power on the node, wait for the setup indicator, scan the setup QR code, confirm the node, claim ownership, acknowledge recovery, name the node, and reach the dashboard.

That should not automatically be treated as a failure. If local operation still works, the node should explain that it is in local-only mode and show what still works, what does not work, and what to do next.

The node should explain that it is running but has not found peers yet. No-peers is not automatically an error. It may simply mean there are no reachable nodes, no trusted peers, or no configured community connection yet.

RelayHub is designed around hardware classes rather than a single universal device. Planned classes include Radio Micro Nodes, Nano Linux Nodes, Home Nodes, Strong Home Nodes, Infrastructure Nodes, Mini PC Nodes, Developer Nodes, and Factory/Test Nodes.

No. RelayHub must never treat every device as a universal node. Hardware capability, software capability, policy permission, runtime availability, trust permission, legal permission, and user enablement are all separate.

A Home Node is the household appliance target. It is intended for ordinary homes or small groups. It should provide local setup, local dashboard, pairing, basic observability, recovery, update handling, and communication support where validated.

An Infrastructure Node is a higher-capability node for bridge, gateway, larger DTN, community, or operator roles. It should not be confused with a Home Node, and its advanced controls should be policy-governed and role-gated.

A Radio Micro Node is a small radio-focused device used for transport or field relay roles. It is not automatically a full household appliance, and radio transmit must never be assumed to be lawful or active simply because radio hardware exists.

Capability-aware means a feature only appears available when the device can actually support it, the software supports it, policy allows it, the runtime state is healthy, trust allows it, legal conditions permit it, and the user has enabled it where required.

Only if the specific hardware class, storage, power, thermal behaviour, software, policy, and validation results support that role. A larger board does not automatically become infrastructure-class just because it has more resources.

Communication is central to RelayHub, but the first Home Node should be understood as infrastructure first. It may guide users to compatible Reticulum clients or provide validated communication paths, but it should not claim full messaging capability unless that path exists and has been tested.

No. RelayHub should not claim guaranteed delivery. Messages may be delivered, queued, delayed, expired, failed, imported, exported, or waiting for a route depending on connectivity, trust, transport, queue policy, and runtime conditions.

Store-and-forward means a node may hold messages or bundles until a suitable path becomes available. This is useful in intermittent networks, but it is still not a guarantee that every message will arrive.

That is one of the major goals. Communities should be able to operate locally, establish trust, share selected services, and federate voluntarily with other communities where capability, policy, trust, and validation allow.

The architecture is designed around Reticulum as a core substrate, so wider Reticulum connectivity is part of the intended direction. Actual behaviour depends on configuration, transports, reachable peers, trust relationships, policy, and validated client support.

RelayHub’s local web setup and dashboard may work through a supported iPhone browser if validated. Reticulum-native mobile communication through Sideband should not be claimed for iOS unless a validated iOS-compatible Reticulum client exists.

Android is a stronger early fit for Reticulum-native mobile communication because compatible Reticulum client paths are more realistic there. Browser-based setup and management should still be tested separately from messaging support.

No. RelayHub must not be described as perfectly anonymous. It may reduce dependence on central services and support more resilient communication, but metadata, trusted peers, radio visibility, local configuration, compromised devices, and physical seizure still matter.

No. The approved baseline is: this node is designed for local-first, resilient communication. It can reduce dependence on central services, but it does not make you invisible.

Reticulum can support resilient and censorship-resistant communication, but it should not be presented as magical anonymity. Privacy, anonymity, encryption, metadata exposure, RF observability, peer trust, and physical risk are separate issues.

No. Local network presence should not automatically grant trust. RelayHub should require pairing, roles, permissions, and policy enforcement before management actions are allowed.

The Home Node direction is explicit support export only. Support bundles should be user-controlled, redacted by default, and should not include message content, private keys, recovery secrets, or unnecessary identities by default.

Remote vendor control should not be part of the default Home Node model. Support should rely on local help, recovery guidance, and user-exported support bundles unless a future remote-support model is separately specified, consented to, and validated.

The system should support revocation, role limits, event history, recovery paths, and explicit trust management. A paired device should not automatically have unlimited authority unless its role allows the action and policy permits it.

RelayHub systems should degrade gracefully and explain what changed, what still works, what does not work, and what action is available. Recovery should be visible, local-first, guided, role-aware, and validated.

Recovery-first design means rollback, guided repair, identity preservation where possible, safe reset, transfer, support export, offline documentation, and recovery access are treated as core product requirements rather than afterthoughts.

A failed update should roll back to the previous working version or enter guided recovery. A rollback is not a catastrophe. It is a successful safety behaviour.

RelayHub should provide a defined recovery flow. Recovery must check authority and should not allow silent takeover. The exact recovery method depends on the product version, hardware class, and validated recovery design.

A factory reset should be possible, but it must not be accidental. It should explain what happens to owner access, paired users, settings, local data, recovery, and transfer or resale state before confirmation.

Ownership transfer is part of the intended lifecycle. Transfer should prevent orphaned devices, stale owner authority, insecure resale, and support confusion. It must revoke the previous owner where appropriate and establish the new owner through a clear flow.

Radio support is part of the broader architecture, including LoRa and other possible transport paths. However, radio operation must be validated, capability-aware, region-aware, policy-controlled, and legally configured.

No. Radio transmit must not be enabled merely because radio hardware exists. It should require validated hardware, correct firmware, region setup, legal permission, policy permission, and explicit user enablement where required.

LoRa is a planned radio transport class, but actual support depends on hardware, firmware, Reticulum integration, radio policy, region rules, airtime limits, and validation.

Packet radio is an experimental or specialist area and may involve legal, licensing, encryption, and operator constraints depending on jurisdiction. RelayHub should not claim general packet radio support until specific use cases are validated.

Radio may be useful in degraded environments, but RelayHub should not be marketed as a guaranteed emergency service. Coverage, legality, bandwidth, congestion, power, antennas, terrain, licensing, and peer availability all matter.

That is one of the central goals. Communities should be able to operate locally, form trust relationships, coordinate resources, preserve knowledge, and federate voluntarily with other communities.

Federation is voluntary coordination between communities. It may include shared directories, marketplace visibility, knowledge sharing, events, emergency notices, trusted gateways, or governance agreements. Federation should strengthen local communities rather than replace them.

A marketplace is part of the wider ecosystem vision. It should support local trade, services, offers, requests, reputation, and settlement-neutral coordination. It must not imply payment custody or settlement guarantees unless separately implemented, audited, and validated.

Yes, knowledge preservation is part of the long-term purpose. Communities should be able to store, recover, share, and transmit useful knowledge, local guides, procedures, maps, records, lessons learned, and cultural memory.

No. Communities should be able to define their own membership, roles, moderation, marketplace rules, governance processes, and federation relationships, within safety, recovery, lawful operation, identity, and security boundaries.

Yes. Federation should be voluntary, modular, revocable, and consent-based. Communities should be able to operate locally even when federation is unavailable or no longer desired.

Yes. The ecosystem is expected to support applications and services through local APIs, documentation, validation rules, policy boundaries, and future developer guidance. Applications must not bypass identity, trust, recovery, privacy, or hardware limits.

RelayHub’s public website currently uses Astro and Cloudflare infrastructure. RelayOS itself is planned around NixOS, Reticulum, local APIs, browser-first UI, policy enforcement, validation tooling, and hardware-specific service profiles. Exact implementation choices should remain tied to the architecture and validation documents.

NixOS is foundational because it supports declarative configuration, reproducible builds, rollback-safe upgrades, and controlled system behaviour. Those qualities align strongly with appliance-like recovery and validation requirements.

Kubernetes is not the default fit for household appliance nodes. It may be useful in some infrastructure or development contexts, but the product should avoid unnecessary complexity, especially for Home Nodes.

Potentially, yes. Compatibility must be accurate and should not imply certification. A device may be compatible, experimental, unsupported, certified, or official depending on validation, documentation, support, and governance status.

Certification means a product, application, community, or service has been validated against published requirements. Compatibility means something interoperates. Compatibility alone must not imply certification.

Early access is useful for households, rural communities, community organisers, field operators, developers, hardware builders, Reticulum users, local resilience groups, and people interested in testing practical local-first infrastructure.

Yes. Pilot ideas are welcome, especially if they involve real community needs, difficult connectivity, rural conditions, field deployments, local coordination, recovery requirements, or non-technical users.

Yes. Developer involvement will become more useful as APIs, validation requirements, application boundaries, and reference implementations become clearer. The most useful early contributions are practical, testable, documented, and recovery-aware.

Yes. Non-technical feedback is essential. RelayHub succeeds only if ordinary people can understand it, set it up, recover it, and trust what it says. Questions, confusion, wording feedback, and field-test observations are valuable.

The best feedback identifies what is confusing, what feels too technical, what claims sound unclear, what recovery steps are missing, what real-world use cases matter, and what would make a household or community actually trust the system.