Centralised dependency
Many communities rely on services they do not own, cannot repair, and cannot operate locally when connectivity fails.
Local-first infrastructure for resilient communities
Build resilient communities.
RelayHub helps households, groups, and communities communicate, coordinate, preserve knowledge, trade, govern, recover, and remain connected through local-first infrastructure powered by RelayOS and Reticulum.
The problem
Communities should not depend entirely on fragile central systems.
Internet outages, platform control, weak local coordination, poor recovery paths, and centralised services can leave people disconnected exactly when local trust, knowledge, and cooperation matter most.
Technical barriers
Resilient tools often expect users to understand Linux, networking, radio, cryptography, routing, or command-line recovery.
Poor recovery
If updates fail, keys are lost, hardware breaks, or connectivity disappears, ordinary users need clear recovery paths, not panic.
The RelayHub answer
Technology is the tool. Communities are the purpose.
RelayHub is being built as a local-first ecosystem for communication, trust, knowledge, trade, coordination, governance, and cultural continuity — with appliance-level usability instead of server-room complexity.
Communicate
Local-first communication for households, groups, field teams, and communities where supported paths are validated.
Coordinate
Notices, events, rosters, alerts, working bees, local updates, and practical community action.
Preserve knowledge
Guides, maps, procedures, history, lessons learned, and local memory that remains useful during disruption.
Trade
Future settlement-neutral marketplace coordination for goods, services, requests, offers, barter, and local enterprise.
Govern
Future voluntary tools for proposals, roles, decisions, notices, working groups, and community records.
Federate
Communities can connect with other communities while keeping local autonomy, trust, policy, and identity intact.
Simple at the edge
Reticulum-level infrastructure with appliance-level usability.
The internal architecture may be sophisticated. The user experience must remain understandable: plug in the node, open the local UI, scan a QR code, pair, and communicate where supported.
01
Plug in the node
The appliance starts locally and exposes setup, status, and recovery without requiring a cloud account.
02
Open the local UI
Use a browser-first interface designed for ordinary users, not Linux administrators.
03
Scan the QR code
Pair, claim ownership, invite trusted users, and understand what this node can actually do.
04
Communicate and coordinate
Use validated communication paths today, then expand toward boards, market, library, and federation as the ecosystem matures.
Ecosystem architecture
RelayHub is more than a device.
RelayHub is the ecosystem. RelayOS is the platform. Relay products are the appliances. Relay applications are the services. Communities are the primary social units. Federations are voluntary interconnection.
RelayHub
The ecosystem: communities, products, services, applications, trust networks, knowledge systems, marketplaces, and federations.
RelayOS
The platform: appliance onboarding, local web UI, policy enforcement, recovery, updates, observability, and future local APIs.
Relay products
The appliances: Relay Home, Relay Radio, Relay Infrastructure, and future validated product families.
Relay applications
Future local-first services for chat, boards, marketplace, library, files, events, identity, and governance.
Communities
The purpose: households, groups, towns, clubs, associations, local networks, and regional communities.
Federations
Voluntary interconnection between communities without replacing local autonomy, trust, or governance.
RelayOS
The local-first appliance platform behind RelayHub nodes.
RelayOS turns NixOS, Reticulum, policy governance, hardware profiles, local APIs, observability, updates, and recovery into a simple node experience.
NixOS foundation
Reproducible builds, declarative configuration, rollback-safe updates, and hardware-specific profiles.
Reticulum substrate
Local-first communication over supported transports, intermittent connectivity, and future delay-tolerant behaviour.
Appliance layer
QR setup, pairing, trust, dashboard, policy gates, guided recovery, support export, and plain-language state.
Product family
A family of nodes, not one universal box.
RelayHub is capability-aware. A household appliance, radio relay, and infrastructure node should not pretend to do the same job. Hardware capability, software capability, policy permission, runtime state, trust, legal permission, and user enablement are separate.
Relay Home
A household appliance target for local setup, QR pairing, dashboard status, updates, support export, and guided recovery.
Relay Radio
A radio-assisted field relay class for validated transport use where lawful, supported, policy-enabled, and user-enabled.
Relay Infrastructure
A stronger node class for community infrastructure, DTN, bridge, gateway, observability, and operator-governed services.
Trust, policy, and federation
Discovery is not trust. Connectivity is not permission.
RelayHub must distinguish what is discovered, paired, trusted, limited, quarantined, revoked, policy-allowed, legally allowed, and actually available at runtime.
Explicit trust
LAN presence, Reticulum reachability, and marketplace participation must not automatically become administrative trust.
Policy-governed behaviour
Transport, gateway, bridge, discovery, radio, privacy, resource, support, update, and recovery behaviour are governed by policy.
Voluntary federation
Communities can cooperate, share, and interconnect without losing autonomy or being forced into a single central authority.
Recovery-first design
Failure is expected. Recovery must be designed in.
RelayHub should fail softly rather than catastrophically. Updates, identity, pairing, reset, transfer, power loss, storage pressure, and degraded operation all need observable and documented recovery paths.
Rollback-safe updates
Failed updates should return to a previous working state or enter guided recovery instead of silently breaking the node.
Identity preservation
Node identity, owner identity, recovery authority, trust state, and transfer state need clear lifecycle rules.
Guided recovery
Recovery should be visible, local-first, documented, role-aware, authority-checked, and usable by non-technical users.
Future applications
Communications are only the beginning.
RelayHub can grow into a local-first ecosystem of community applications once the platform, validation, policy, and usability foundations are ready.
Relay Chat
Future user-facing messaging and trusted communication tools.
Relay Boards
Community notices, requests, announcements, alerts, and local coordination.
Relay Market
Settlement-neutral coordination for goods, services, skills, offers, and requests.
Relay Library
Local knowledge, guides, maps, procedures, community memory, and cultural continuity.
Relay Events
Calendars, training, meetings, working bees, rosters, and local gatherings.
Relay Governance
Future proposals, roles, decisions, delegations, records, and transparent local processes.
Validation
Claims must be proven before they become promises.
RelayHub should not present experimental ideas as product-supported. Every major claim should be testable, observable, reproducible, recoverable, evidence-backed, and release-gated.
Build minimally
Start with the smallest working appliance loop: boot, setup, QR, owner claim, dashboard, Reticulum status, and recovery entry.
Validate honestly
Test setup, power loss, update rollback, local-only mode, no-peers, storage pressure, browser compatibility, and recovery drills.
Release carefully
Product-supported status should require documentation, support, recovery, field evidence, compatibility boundaries, and known limits.
Honest limits
Resilient does not mean invincible.
What RelayHub is designed for
Local-first operation, QR onboarding, explicit trust, graceful degradation, visible recovery, capability-aware products, and reduced dependence on centralised communication paths.
What RelayHub does not promise
Perfect anonymity, invisible metadata, guaranteed message delivery, universal emergency coverage, automatic trust, or lawful radio transmit in every region.
Documentation and support
Documentation is part of the product.
RelayHub documentation should help ordinary people set up, understand, operate, recover, and safely evaluate the limits of their node.
Beginner documentation
Quick starts, setup flow, status meanings, onboarding, local-only explanations, and household guidance.
Recovery documentation
What failed, what still works, what recovery can do, what it cannot do, and how to restore safe operation.
Support boundaries
User-controlled support export, redaction by default, no hidden remote control, and clear support levels.
Early access
Follow RelayHub as it becomes real.
Register interest for RelayOS progress, product updates, documentation releases, developer resources, hardware validation, Etsy availability, and future community pilot programs.
Current status
RelayHub is in design and validation planning. Supported product claims, final pricing, hardware support, fulfilment details, and availability will be published only when they are ready.