Skip to content

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.