IFM — Node Responsibilities

IFM separates content production, network transport, content consumption, and system observation.

Each component has one primary responsibility. Components MUST NOT absorb responsibilities belonging to another layer.

Architecture

The mesh is the actual IFM network.

Stations, Listeners, and optional Relays are peers participating in the mesh.

The Rendezvous is outside the normal application traffic path and only provides an entry point.

---

Main Communication and Adaptive Forwarding Flow

The primary communication path in IFM is:

Direct peer-to-peer communication is always preferred when the connection provides adequate performance.

The mesh dynamically adapts when connectivity or performance degrades.

1. Direct Station → Listener

The Station produces and processes the content, then sends packets directly through the mesh toward the Listener.

This is the default path.

---

2. Listener-to-Listener Forwarding

If a Listener has a poor connection to the Station, but another peer has a better connection, the better-connected peer may forward the packets.

Listener A does not need to decode and re-encode the content for Listener B.

It forwards the original IFM packets.

A Listener may therefore act simultaneously as:

This allows ordinary peers to improve the network without requiring a dedicated Relay.

---

3. Relay-Assisted Forwarding

If the direct Station → Listener path is degraded and available peers cannot provide a sufficiently good forwarding path, the node may search for a suitable Relay.

If a Relay provides a better path, traffic may be routed through it:

The Relay remains completely payload-agnostic.

It forwards packets without decoding, processing, transcoding, or modifying the content.

---

Adaptive Path Selection

The preferred path order is:

The network should continuously evaluate path quality using available network information such as:

• latency;
• packet loss;
• connection stability;
• throughput;
• congestion;
• peer availability;
• observed degradation.

The objective is not to use Relays whenever they exist.

The objective is to select a path that provides the best practical delivery for the traffic being transported.

Important Rule

A Relay is not the first hop and is not required for normal communication.

when a healthy direct path exists.

and only when necessary:

or:

The same principle applies to communication between any peers.

IFM prefers direct peer-to-peer communication, uses other peers as forwarding paths when they provide a better route, and uses dedicated Relays when they provide a superior path.

This rule applies identically to the browser: a web Listener connects to the mesh through the same entry point, prefers the direct Station (or a closer Listener peer) first, and only calls a Relay when its direct signal is degraded — exactly like the desktop apps.

Role vs. Behavior

One subtle but important distinction: "Listener" describes what the node is doing with the content, not necessarily its entire network behavior. A Listener can consume content and forward packets at the same time. The role labels (Station / Listener / Relay) name the primary responsibility of a node in a given moment; they do not restrict what other mesh behaviors the node may also perform. This fits the P2P model — a dedicated Relay is optimized for forwarding, but ordinary peers participate in forwarding too, and a Relay is never a mandatory middle layer between them.

---

1. Station — Produce and Process

The Station is the content-processing node.

It receives source data and performs all processing required before transmission.

Heavy processing MUST remain at the Station.

The Station sends fully processed and encoded IFM packets into the mesh.

---

2. Rendezvous — Bootstrap Only

The Rendezvous is a minimal network entry service.

The Rendezvous MUST NOT:

• carry normal application traffic;
• relay packets;
• process content;
• decode or encode payloads;
• become a central message broker;
• become a permanent network dependency.

It should be extremely small, easy to deploy, and easy to replace.

Rendezvous introduces nodes to the mesh. It does not operate the mesh.

Signaling (INTRODUCE for the browser overlay)

The Rendezvous MAY host a signaling endpoint (plain WebSocket / WSS) that brokers browser↔browser WebRTC introductions. Browsers cannot accept inbound connections, so two browser nodes meet at the signaling endpoint, exchange SDP offers/answers and ICE candidates, and then connect over a direct peer-to-peer WebRTC data channel.

Signaling is NOT transport. The signaling endpoint carries ONLY connection-establishment information (SDP + ICE). It never carries IFM packets, payloads, or control frames — those flow over the data channel once it forms. This keeps the Rendezvous squarely in its INTRODUCE role: it introduces browser peers to each other; it does not operate the mesh.

This is distinct from the WebSocket entry (WSS as a transport for a browser joining the mesh): the entry accepts browser dials so a browser core can join the mesh as a normal peer, while signaling is purely introductions for the browser-to-browser overlay.

---

3. Mesh — The P2P Network

The mesh is the actual IFM network.

After discovering an entry peer, a node joins the mesh and communicates with other peers.

Direct peer-to-peer communication is preferred whenever possible.

The mesh MUST NOT depend on any particular Relay.

Independent Transport Lines (traffic lanes)

The mesh is shared, but the traffic lanes are independent. Different traffic classes MUST stay on their own logical transport lines — never coupled into one application-level stream merely for convenience — so a failure, congestion, or high-volume transfer on one line never blocks or significantly degrades unrelated real-time lines (e.g. a file transfer must not interfere with live audio).

Traffic classes (at minimum): AUDIO, VIDEO, CHAT, TELEMETRY, FILE, CONTROL. Each lane may have its own encoding, packet handling, queue, buffering, priority, reliability requirements, congestion behavior, and transport implementation.

Logical isolation, not one physical socket per payload. The lanes MAY share lower-level network infrastructure (the same QUIC connection, the same RTCPeerConnection, the same mesh) while keeping separate logical transport channels, queues, priorities, flow control, and failure domains. The architectural requirement is that the traffic classes remain independently transportable — it is not a requirement for separate physical connections.

Implementation: the frequency payload plane is split into per-lane GossipSub topics (/ifm/{topic_id}/{voice|video|chat|file|data}); the browser overlay gives each lane its own WebRTC data channel with lane-appropriate reliability (voice/video unordered + loss-tolerant, chat/file/data ordered + reliable); the control plane already uses dedicated topics (/ifm/stations/v1, /ifm/relays/v1, /ifm/telemetry/v1).

---

4. Relay — Optional Mesh Infrastructure

A Relay is a peer inside the mesh whose purpose is to improve connectivity, signal delivery, and network performance.

Relays may be used when:

• direct connectivity is unavailable;
• connectivity is degraded;
• network topology makes forwarding beneficial;
• additional paths improve reliability;
• additional capacity improves performance.

With Relay:

Station ─────► Relay ─────► Listener

For audio:

For telemetry / sensor data

For chat

For file transfer

So the complete set becomes:

Audio → Decode → Playback Telemetry → Decode → Sensor Data Chat → Decode → Message File → Reassemble → File

This reinforces an important IFM principle: the transport layer doesn't care what the payload represents. The appropriate Listener/plugin interprets it.

The Listener MUST NOT perform Station-side processing such as mixing, mastering, DSP, transcoding, or re-encoding.

Its job is to consume transmitted content and present it to the user or output device.

Listener-to-Listener Forwarding

A Listener may also participate in packet forwarding when the network topology requires it.

IFM Packet ↓ Listener ↓ forward packets ↓ Other Listeners

The Listener forwards the original packet, without decoding, modifying, transcoding, or re-encoding its payload.

Station │ ▼ Listener A │ │ forward packet ▼ Listener B │ ▼ Decode │ ▼ Present

This is still P2P behavior: any peer may forward traffic when it improves connectivity, while only the final consumer needs to decode and present the content.

The distinction is:

Listener receiving for itself: Receive → Decode → Present

Listener forwarding for others: Receive → Forward

Listener doing both: Receive → Decode → Present └→ Forward

This also means the architecture should avoid treating Relay as the only possible forwarding node. A dedicated Relay is optimized for forwarding, but ordinary peers can participate in forwarding when the protocol/network topology calls for it.

---

6. Desktop Applications

The desktop applications are concrete implementations of IFM node roles.

They share the same underlying IFM architecture and MUST NOT introduce different protocol responsibilities merely because they run on desktop operating systems.

Station Desktop

The Station Desktop is the desktop implementation of a Station.

It provides the user interface around the Station processing pipeline:

The desktop shell is responsible for presentation and configuration.

The underlying Station remains responsible for capture, processing, encoding, and transmission.

Relay Desktop

The Relay Desktop is the desktop implementation of a Relay.

The Relay Desktop MUST remain transport-oriented and payload-agnostic.

Its UI may expose:

• connected peers;
• traffic;
• bandwidth;
• packet statistics;
• connectivity;
• relay status.

The UI MUST NOT turn the Relay into a content-processing node.

Listener Desktop

The Listener Desktop is the desktop implementation of a Listener.

It may provide:

• frequency selection;
• playback;
• volume;
• decoded media;
• messages and metadata;
• listener controls.

It MUST remain a consumer of the stream.

and

A Listener may also participate in packet forwarding when the network topology requires it.

Browser↔browser connectivity (WebRTC overlay)

A browser node cannot accept inbound connections, so two browser nodes cannot dial each other like native peers can — without help, browser↔browser traffic would need a native station/relay in the middle. The WebRTC overlay removes that dependency:

Browser A (Rust core in wasm)                 Browser B (Rust core in wasm)
    │  opaque packet bytes                       ▲ opaque packet bytes
    ▼                                           │
  RTCPeerConnection ── WebRTC data channels ── RTCPeerConnection
    │          SDP/ICE via the signaling         │
    └────────── rendezvous (INTRODUCE only) ─────┘

The overlay is a transport pipe only (see the note below). It never builds, inspects, or modifies packets: outbound packets are the exact wire bytes the Rust core produced, and inbound bytes are fed back into the core, where the normal decode → verify → dedup → deliver path runs. A packet that also arrived over gossipsub dedups by packet id, so the overlay and the native mesh are seamlessly interchangeable — a browser can be on the mesh with both transport surfaces at once.

The overlay is also lane-separated (Independent Transport Lines): one WebRTC data channel per traffic lane (ifm-voice, ifm-video, ifm-chat, ifm-file, ifm-data), with real-time lanes unordered + loss-tolerant and reliable lanes ordered. The Rust core tags each frame with its lane index; the JS overlay routes frames to the matching channel and injects inbound bytes verbatim. All lanes share the single RTCPeerConnection between two browsers — logical isolation, not a socket per lane.

The overlay must NOT become a new application layer: it is a transport detail that implements the same mesh participation rules as every other peer, and the core protocol (packet format, signatures, topics, relay-assist on degraded signal) is unchanged.

The overlay connects browser peers; it does not change what a browser node is.

and

The Listener forwards the original packet, without decoding, modifying, transcoding, or re-encoding its payload.

Browser-specific transport mechanisms are implementation details and MUST NOT change the Listener responsibility model.

The PWA MUST NOT become a Station, Relay, or Rendezvous service.

See Listener-to-Listener Forwarding.

---

8. Dashboard — Observation Layer

The Dashboard is an observation layer for the entire IFM system.

It observes running nodes and the state of the mesh without becoming part of the content pipeline.

It may observe:

• nodes;
• peers;
• mesh topology;
• connectivity;
• Relay availability;
• packet flow;
• latency;
• bandwidth;
• signal degradation;
• errors;
• logs;
• events;
• performance metrics.

The Dashboard MUST NOT:

• process broadcast content;
• become a Relay;
• become a routing authority;
• become a required network dependency;
• replace the Rendezvous;
• become part of the audio pipeline.

The Dashboard observes the network; it does not operate the network.

---

9. Plugins — Extensible Capabilities

IFM uses plugins to extend the capabilities of Stations and Listeners without changing the core protocol or network architecture.

A plugin may add support for:

• new input sources;
• new processing pipelines;
• new codecs;
• new payload types;
• new transformations;
• new output devices;
• new application behaviors;
• new signal capabilities.

Plugins are local capabilities. They are not network infrastructure.

Station Plugins

A Station plugin can extend or modify the Station's content pipeline.

For example:

A plugin could provide:

• microphone processing;
• system-audio capture;
• audio mixing;
• DSP;
• effects;
• AI processing;
• speech processing;
• alternative codecs;
• telemetry generation;
• custom data generation;
• custom payload types.

Plugins MUST execute locally at the Station.

They MUST NOT move heavy processing into Relays or the Rendezvous.

Listener Plugins

A Listener plugin extends what a Listener can decode or present.

For example:

or:

A Listener plugin may provide:

• new decoders;
• new payload handlers;
• visualization;
• audio outputs;
• hardware outputs;
• custom presentation;
• application-specific behavior.

The plugin runs locally on the Listener.

---

Plugin and Frequency Capabilities

Plugins may define what a node can produce or consume on a frequency.

A frequency does not need to know the implementation details of a plugin.

The network only transports IFM packets.

For example:

Frequency:
  music.lofi

Station Plugins:
  audio-capture
  audio-mixer
  audio-opus

Listener Plugins:
  audio-opus
  audio-output

Another frequency can use completely different capabilities:

Frequency:
  sensor.temperature

Station Plugins:
  temperature-input
  telemetry-encoder

Listener Plugins:
  telemetry-decoder
  telemetry-display

The same IFM mesh transports both.

---

Capability Matching

Plugins should expose their capabilities so applications can determine whether a node can produce or consume a particular payload type.

Conceptually:

Example:

{
  "plugin": "audio-opus",
  "version": "1.0",
  "capabilities": {
    "input": ["pcm"],
    "output": ["voice"],
    "payload_types": ["VOICE"]
  }
}

A Listener that does not have a decoder for a payload type simply does not consume that payload.

The network does not need to change.

---

Plugin Boundary

Plugins extend node capabilities but MUST respect the node's architectural role.

Plugins MUST NOT be used to bypass the responsibility model.

In particular:

A plugin must not turn a Relay into a Station, a Rendezvous into a Relay, or a Listener into a processing service.

---

Plugin Architecture

The preferred dependency direction is:

Plugins depend on stable IFM interfaces rather than internal implementation details.

The core protocol MUST remain usable without optional plugins.

---

Responsibility Invariants

Component	Responsibility
Station	Produce, process, encode
Rendezvous	Bootstrap / introduce
Mesh	Peer-to-peer communication
Relay	Optional forwarding / connectivity improvement
Listener	Receive, decode, present, might forward
Station Desktop	Desktop Station
Relay Desktop	Desktop Relay
Listener Desktop	Desktop Listener
PWA/WEB	Web/mobile Listener
Dashboard	Observe / monitor
Plugin	Extend capability

The fundamental model is:

STATION    = PROCESS
RENDEZVOUS = INTRODUCE
MESH       = COMMUNICATE
RELAY      = IMPROVE TRANSPORT
LISTENER   = DECODE + PRESENT + IMPROVE TRANSPORT
PWA/WEB    = WEB LISTENER
DASHBOARD  = OBSERVE
PLUGIN     = EXTEND CAPABILITY

Architectural Invariant

Content processing happens at the Station. The mesh transports packets peer-to-peer. Relays are optional infrastructure that improve connectivity, stability, and performance. Content is decoded at the Listener. The Rendezvous only introduces nodes to the mesh. The Dashboard only observes the system. Desktop applications and the PWA/Web are implementations of these roles, not new architectural layers. Plugins extend capabilities; they do not redefine responsibilities. A plugin may change what a Station can produce or what a Listener can consume, but the fundamental IFM architecture remains unchanged. A plugin executes locally and cannot push its workload into another architectural role.