RelayFabric¶
RelayFabric is an open communications routing fabric for interconnecting otherwise incompatible messaging, mesh, radio, and Internet systems. It provides one common routing, policy, identity, security, and message-processing layer, and delegates every protocol-specific detail to plugins. Bridge a Meshtastic LoRa mesh to Reticulum/LXMF, relay Signal into Nostr, or federate two gateways over an untrusted link, through a single headless daemon.
Status: v0.4.2 released
v0.4 was the hardening/proving/packaging release, no new protocols (roadmap): per-plugin isolation, passkey-authenticated UI, the interop matrix, signed packaged releases, and a published SDK. The v0.4.x point releases add operator/self-hoster features (backup/restore, health probes, retention, self-alerting, DLQ management, Grafana, init) and two ingest/bridge plugins (XMPP, meshtripwire). The public federation (cycle G) follows later on the same line. The table below is the single source of truth for feature status; every other page defers to it.
Feature status¶
Per-plugin interop coverage (inbound/outbound/replies/attachments/reconnect/dedup/offline/restart/payload/failure-injection) lives in the Interoperability Matrix.
| Subsystem | Status | Since | Validation |
|---|---|---|---|
| Core fabric (routing, dedup, policy, queue, persistence, admin API) | shipped | v0.1 | unit + e2e suites |
| Plugin Protocol v1 (CBOR IPC, golden-locked wire format) | shipped | v0.1 | golden vectors, Rust + Python |
| MQTT plugin | shipped | v0.1 | e2e + livetest |
| LXMF plugin | shipped | v0.1 | field-tested against a live RNS backbone |
| Signal plugin | shipped | v0.1 | livetest against signal-cli |
| Meshtastic plugin (direct serial/TCP/BLE, GPL-3.0) | shipped | v0.4 | field-tested over BLE (connect + channel + direct messages, real node identity); GPL isolated to the plugin process |
| Meshtastic plugin (MQTT-JSON, Apache-2.0) | shipped | v0.1 | livetest via MQTT JSON gateway + real-node downlink (interop matrix C-2) |
| MeshCore plugin | shipped | v0.2 | fake-backend tests + real-hardware livetest (interop matrix C-1) |
| Nostr plugin | shipped | v0.3 | fake-relay tests; live-relay validation pending |
| XMPP plugin (slixmpp, Apache-2.0) | shipped | v0.4.2 | MUC + 1:1 DMs, text only; fake-backend tests; live-server validation pending |
| Bitchat plugin | shipped | v0.3 | fake tests; real-client interop unverified |
| PotatoMesh feeder plugin | shipped | v0.4-dev | unit tests against the published contract |
| meshtripwire alert plugin (ingest-only, Apache-2.0) | shipped | v0.4.2 | unit tests; relays meshtripwire tripwire alerts off-grid over LXMF/Meshtastic |
| Federation (Noise XX, signed envelopes, trust levels) | shipped | v0.3 | e2e |
| RFDP discovery | shipped | v0.3 | e2e |
| Sealed routing: phase 1, gateway-to-gateway (§113) | shipped | v0.3 | e2e + KAT |
| Sealed routing: user-to-user (X3DH/ratchet), MLS groups | not built | planned v0.5+ | — |
| Transport-class egress (phase 1, static classes) | shipped | v0.3 | SHA-locked regression e2e |
| Transport-class phase 2 (core extraction, Android) | not built | proposed | — |
Web admin UI (relayfabric-ui) |
shipped | v0.2 | passkey (WebAuthn) auth + scoped roles since v0.4-dev; ceremony suite in auth.rs |
Plugin privilege isolation (per-plugin sockets, SO_PEERCRED, systemd sandboxing) |
shipped | v0.4-dev | unit + e2e; hardened units in deploy/systemd/ |
| Packaged releases (tarballs, .deb, GHCR semver images, provenance attestations) | shipped | v0.4-dev | release.yml on version tags; first artifacts at the v0.4.0 tag |
| SDK as a product (crates.io/PyPI packages, echo example, conformance runner) | shipped | v0.4-dev | switchyardctl plugin test green on echo + potatomesh; relayfabric-core/-ipc 0.4.0 live on crates.io; relayfabric-sdk 0.4.0 live on PyPI |
| Federation over Tor/I2P | not built | proposed | — |
The idea¶
Every messaging network speaks its own protocol, carries its own identity model, and makes its own trust assumptions. RelayFabric refuses to reinvent any of them. Instead it routes messages, not identities, across a boundary you control:
flowchart TB
subgraph Networks
direction LR
R[Reticulum / LXMF]
S[Signal]
M[Meshtastic]
N[Nostr]
end
subgraph Plugins["Plugin processes"]
direction LR
PR[lxmf plugin]
PS[signal plugin]
PM[meshtastic plugin]
PN[nostr plugin]
end
R <--> PR
S <--> PS
M <--> PM
N <--> PN
PR & PS & PM & PN <-->|CBOR IPC| D[("switchyardd<br/>routing · policy · identity · security · queue")]
D <-->|Noise + attestation| F[peer gateway]
Plugins are separate, supervised processes that speak a small CBOR-over-Unix-socket protocol to the daemon. The daemon owns routing, deduplication, hop limits, store-and-forward queuing, identity pseudonymization, and the security envelope. A plugin crash never takes the fabric down.
Why RelayFabric exists
Networks should interoperate without demanding that users surrender privacy, autonomy, or control. Read the Manifesto.
What it does¶
| Capability | Summary |
|---|---|
| Protocol bridging | One route can span Reticulum, Signal, Meshtastic, MeshCore, Nostr, Bitchat, and MQTT. See Plugins. |
| Capability-aware transforms | Messages are adapted to each destination's real capabilities (text, attachments, media) at egress. See Architecture. |
| Transport-class routing | Egress degrades to the link's characteristics: payload capped, images demoted to a note on constrained transports. See Transport Classes. |
| Identity privacy | Anonymous, route-scoped pseudonymous, or verified-linked identities. See Identity & Privacy. |
| Sealed routing | Blind, gateway-to-gateway end-to-end encryption of the payload. See Security & Sealed Routing. |
| Federation | switchyardd ↔ switchyardd over Noise-authenticated links with signed attestation chains and RFDP discovery. See Federation & Discovery. |
| Store-and-forward | Persistent queue with retry, backoff, TTL, and a dead-letter queue. See Routing & Policy. |
| Operable | Unix-socket admin API, switchyardctl, Prometheus metrics, hot config reload, Swagger UI. See Operations. |
Components¶
switchyardd, the core daemon: routing, deduplication, policy enforcement, persistence, and an admin API, all headless.switchyardctl: a CLI client for the admin API (status, plugins, routes, queue, trace, config, events).- Plugins: one supervised process per protocol, speaking CBOR over a Unix socket.
Get started¶
cargo build -j2 --release # binaries in target/release/
switchyardd --config docs/relayfabric.example.yaml --check-config
Then follow Getting Started for a full end-to-end route, or jump to the Configuration reference.
Honest claims
RelayFabric is scrupulous about what it does not provide. Sealed routing hides payloads from intermediary gateways but not the metadata of who is talking to whom; pseudonyms provide cross-route unlinkability, not anonymity from the gateway operator. Each page states its guarantees (and their limits) plainly.