Applications
Future Relay applications for chat, boards, markets, libraries, maps, events, files, identity, and community coordination.
Developers
Build the ecosystem without breaking the appliance.
RelayHub is being designed as a local-first ecosystem for resilient communities. Developers can help build applications, services, hardware validation, documentation, integrations, and community tools — but every contribution must preserve usability, recovery, policy, and trust.
Build on RelayHub
RelayHub is a platform direction, not just a hardware idea.
The long-term ecosystem includes RelayOS, local APIs, applications, community services, hardware classes, validation tooling, documentation, and voluntary federation. Developer participation should strengthen the appliance experience rather than expose unnecessary complexity.
Integrations
Careful integrations with Reticulum clients, local services, transport tools, hardware profiles, and community workflows.
Services
Local-first services for discovery, trust, federation, support, knowledge, marketplace coordination, and observability.
Hardware
Hardware validation, capability manifests, node profiles, boot tests, recovery drills, and compatibility evidence.
Community tools
Tools that help communities onboard people, preserve knowledge, coordinate resources, govern locally, and recover safely.
Documentation
Quick starts, recovery guides, API notes, validation evidence, hardware guides, and plain-language explanations.
Platform foundations
Advanced foundations. Simple edge.
RelayHub may be sophisticated internally, but ordinary users should not need to understand Linux, Reticulum internals, routing, radio engineering, service management, or cryptographic plumbing to participate.
RelayOS
The appliance platform that powers RelayHub nodes and provides onboarding, recovery, observability, policy, identity, trust, and local management.
Reticulum
The communications substrate. RelayHub builds usability, policy, recovery, documentation, and community services around it.
NixOS
The intended foundation for reproducible builds, declarative configuration, rollback-safe upgrades, and hardware-specific profiles.
Local APIs
The planned local appliance control plane for setup, pairing, state, recovery, updates, support export, and future applications.
Policy engine
The governance layer that determines whether capabilities, roles, transports, services, and runtime behaviours are allowed.
Trust model
Discovery, identity, reachability, permission, reputation, federation, revocation, and recovery must remain separate.
Future APIs
Planned interfaces must remain honest about their status.
These API areas are planning concepts, not current public contracts. They should become developer-facing only after architecture, recovery, security, validation, documentation, and compatibility boundaries are ready.
Local API
Node health, setup, pairing, recovery, updates, status, support export, and local web UI integration.
Application API
Future application hosting and service access for Relay applications running on RelayOS.
Discovery API
Local discovery, QR bootstrap, setup flows, recovery discovery, and service visibility.
Trust API
Trust states, paired devices, roles, revocation, limited access, federation trust, and recovery authority.
Marketplace API
Offers, requests, listings, skills exchange, local services, community rules, and settlement-neutral coordination.
Community API
Community identity, membership, governance notices, knowledge sharing, events, directories, and federation boundaries.
Open ecosystem posture
Interoperability matters, but support must be earned.
RelayHub should encourage open standards, local-first design, community participation, and compatible tools. But compatibility, certification, official status, and product support are separate claims.
Compatible
A tool or device may interoperate with RelayHub concepts without being official, certified, or product-supported.
Certified
Certification should require published requirements, validation evidence, support boundaries, and compatibility expectations.
Official
Official products, services, and applications are governed by the RelayHub ecosystem and must follow its terminology, policy, and validation rules.
Developer roadmap
Development should follow validation, not excitement.
The project should grow from a minimal validated appliance loop into a broader application and community ecosystem only after recovery, usability, and hardware-class boundaries are proven.
Website, concept pages, early access, contact, D1 storage, admin tools, analytics, and public positioning.
Documentation structure, hardware pages, product boundaries, developer guidance, support workflows, and validation language.
RelayOS builds, local APIs, application framework, community directory, marketplace coordination, and field trials.
Appliance usability, Reticulum onboarding, NixOS reproducibility, DTN behaviour, radio policy, recovery UX, and federation governance.
Contribution areas
Useful help is broader than code.
RelayHub needs builders who care about usability, validation, recovery, documentation, hardware evidence, and community operation as much as features.
Developer rules
The appliance promise comes first.
Developer work must preserve the core promise: plug in node, open app or local web UI, scan QR code, communicate where supported, and recover safely when something goes wrong.
Do not overclaim experimental features.
Do not imply compatibility means certification.
Do not activate features merely because hardware exists.
Preserve recovery paths before adding convenience.
Keep local-first operation visible.
Make privacy and security limits clear.
Respect hardware class ceilings.
Treat documentation as part of the product.
Release discipline
Build minimal. Validate. Recover. Then expand.
A feature is not ready merely because it works once. It should be reproducible, observable, recoverable, documented, and validated across the hardware class it claims to support.
1. Build
Create the smallest working version that proves the appliance loop.
2. Validate
Capture evidence for boot, setup, pairing, state, update, support, and recovery.
3. Field test
Watch real users attempt setup, recovery, state interpretation, and support export.
4. Support
Call something supported only when documentation, recovery, and validation are complete.
Developer access
Structured developer access will come after the foundations.
Public repositories, contribution guides, issue templates, API contracts, hardware manifests, and validation harnesses should appear only when the project is ready for structured collaboration.
Register as a developer
Register interest if you want to help with NixOS, Reticulum, RelayOS, local web UI, hardware testing, documentation, validation, or future community applications.