Compatibility

Compatibility must be clear before people rely on it.

RelayHub is designed around interoperability, local-first operation, and open ecosystem participation. But compatibility, support, certification, and experimental status are different claims.

Hardware Validation

Current compatibility direction

Built around the Reticulum ecosystem.

RelayHub’s compatibility story begins with Reticulum and the tools, transports, and workflows that already exist around it. Compatibility must still be validated before being treated as supported behaviour.

Core foundation

Reticulum

Reticulum is the core communications substrate RelayHub is being designed around.

Expected ecosystem fit

LXMF

LXMF is part of the wider Reticulum messaging ecosystem and is relevant to future communication workflows.

Android ecosystem tool

Sideband

Sideband is relevant to Reticulum-based messaging, especially on Android. RelayHub must not claim iOS Sideband support.

Relevant ecosystem tool

NomadNet

NomadNet-style bulletin and information workflows are relevant to future RelayHub knowledge and board concepts.

Radio ecosystem fit

RNode devices

RNode-compatible devices may be relevant to radio transport, subject to validation, firmware, regional policy, and legal operation.

Baseline transport

TCP/IP transports

TCP/IP over Ethernet or Wi-Fi is expected to be a baseline transport for many RelayHub node classes.

Planned compatibility

Planned means not yet implemented.

These areas are important to the RelayHub ecosystem vision, but they should not be treated as current product-supported compatibility until implemented, validated, documented, and released.

Planned

RelayOS applications

Future applications for chat, boards, markets, libraries, maps, events, files, identity, and community coordination.

Planned

Community directory

Future directory compatibility for community discovery, visibility, trust state, federation scope, and local identity.

Planned

Marketplace

Future compatibility for local listings, offers, requests, services, skills exchange, and settlement-neutral trade coordination.

Planned

Future APIs

Planned Local API, Application API, Discovery API, Trust API, Marketplace API, and Community API concepts.

Hardware compatibility

Not every node can do everything.

RelayHub hardware compatibility must be capability-aware. Hardware class defines the ceiling. Policy, validation, trust, legal permission, runtime availability, and user enablement determine what can actually activate.

Radio Micro Node

Examples: LilyGo T-Beam Supreme, T3S3

Radio transport and field relay class. Not a full household appliance.

Nano Linux Node

Examples: Raspberry Pi Zero 2 W

Lightweight relay class with constrained compute, storage, and service capacity.

Home Node

Examples: Raspberry Pi 4 2GB

Household appliance target with simple setup, local web UI, recovery, and limited household operation.

Strong Home Node

Examples: Pi 4 4GB / Pi 5 4GB

Enhanced household node with more comfortable performance and stronger local capability where validated.

Infrastructure Node

Examples: Pi 5 8GB

Bridge, gateway, DTN, community infrastructure, and operator-oriented capability where validated.

Mini PC Node

Examples: N100 / N150-class mini PC

Full infrastructure class for advanced services, larger queues, and broader operator workflows.

View hardware page Support boundaries

Claim language

Compatible, supported, certified, and experimental are not the same.

Clear language protects users, developers, vendors, and communities from false expectations.

Compatible

A tool, device, or service may interoperate in some way. Compatibility does not automatically mean official support.

Supported

Supported means RelayHub has defined a support boundary, documentation, recovery path, and validation expectation.

Certified

Certified should mean a product, integration, or service has passed published requirements and evidence review.

Experimental

Experimental means the idea may work in limited conditions but must not be relied on as product-supported.

Browser compatibility

The public website is browser-first.

The current public website should work across modern desktop and mobile browsers. Future RelayOS local UI compatibility will need its own validation matrix.

  • Firefox
  • Firefox ESR
  • Chromium
  • Chrome
  • Brave
  • Edge
  • GrapheneOS Vanadium
  • Mobile browsers where layouts and forms are validated

Operating systems

Website, development, mobile, and future appliance support are separate.

RelayHub must distinguish website compatibility, developer workstation compatibility, mobile client compatibility, and future RelayOS appliance compatibility.

Linux

Current development and deployment work is Linux-oriented. Fedora Silverblue/toolbox is being used for the website workflow.

Android

Android is relevant through the existing Reticulum ecosystem, especially Sideband. Support must be validated before being claimed.

RelayOS

Future appliance platform direction for RelayHub nodes, based on local-first, NixOS-backed, recovery-aware operation.

iOS

RelayHub should not claim Reticulum/Sideband-native iOS support unless a validated iOS-compatible path exists.

Radio compatibility

Radio compatibility requires more than working hardware.

Radio-capable devices must be evaluated through hardware support, firmware support, regional policy, legal permission, airtime limits, power limits, antenna setup, and validation evidence.

Important boundary

A radio device being technically compatible does not mean transmit is enabled, lawful, supported, certified, or appropriate in every region.

Security posture Hardware

Compatibility philosophy

Open participation without false certainty.

RelayHub should encourage interoperability and avoid unnecessary lock-in, while still making support, certification, and validation boundaries clear.

Interoperability should reduce lock-in.

Compatibility must not imply certification.

Certification must be evidence-backed.

Support must include recovery paths.

Hardware capability does not equal feature activation.

Radio capability does not equal legal transmit permission.

Experimental integrations must be labelled honestly.

Local-first operation should remain the default expectation.

Want something checked?

Ask before assuming support.

If you are considering a device, transport, integration, browser, operating system, or community workflow, ask whether it is compatible, experimental, supported, or planned.