Hardware Architecture: Modular IFM Nodes

This document outlines the architectural principles for developing IFM-compatible hardware. The design focuses on a modular, capability-driven platform rather than fixed-function appliances.

1. Design Philosophy: The Modular Platform

To support decentralized, privacy-first audio broadcasting, the IFM node architecture must be flexible. We avoid single-purpose "IFM boxes" in favor of a modular hardware platform where a generic core board connects to specialized input/output modules.

Core Model

ESP32 Core + Modular Interfaces + IFM Firmware + Replaceable Signal Modules.

The system enables users to build diverse nodes (e.g., Relay, Speaker, Sensor, Gateway) using a standardized IFM Baseboard and interchangeable modules.

---

2. System Architecture

The IFM node utilizes a generic baseboard for core logic (Wi-Fi, Bluetooth, Identity) with a standardized expansion bus for hardware-specific tasks.

2.1 Hardware Architecture (Bus Model)

2.2 Capability Management (Logic/Software)

{
  "device": "ifm-node",
  "capabilities": {
    "inputs": ["microphone", "temperature"],
    "outputs": ["i2s", "gpio"],
    "payloads": ["voice", "json", "telemetry"],
    "transports": ["wifi", "ble"]
  }
}

This facilitates intelligent, adaptive processing:

• Packet Match: The node checks if the payload (e.g., VOICE) matches supported capabilities.
• Adaptive Routing: If voice is supported + i2s output is available → decode → I²S.
• Graceful Exclusion: If unsupported (e.g., VIDEO), the node does not subscribe to or process the payload.

---

4. Firmware Plugins & Modularity

Hardware modularity is extended to firmware via a plugin architecture. The Capability Manager maps hardware-detected capabilities to pre-installed, authorized firmware plugins.

• Hardware Module: "I can produce temperature telemetry."
• Firmware Plugin: "I know how to encode temperature telemetry."

Capability Manager

---

5. Adaptive Signal Processing

Nodes can dynamically switch processing pipelines based on the declared payload_type of incoming packets without requiring firmware updates.

• Scenario: A listener tuned to a frequency carrying VOICE activates the Opus decoder/Jitter buffer. If the same frequency switches to TELEMETRY, the node updates the processing path to JSON decoder/Telemetry handler.

---

6. Security Considerations

To mitigate risks, dynamic execution of arbitrary code via network signals is prohibited.

• Policy: The network can request or announce behavior, but only pre-installed and authorized firmware modules may execute.

---

7. Reference Implementation Path

• Target MCU: ESP32-S3 (Reference implementation due to strong audio/USB/connectivity support).
• Platform Neutrality: While ESP32-S3 is the primary reference, the architecture remains MCU-agnostic (e.g., supporting RP2040 or Linux SBCs via standardized IFM Embedded Profiles).