Skip to content

History / How MMRelay Works

Revisions

  • Updated How MMRelay Works (markdown)

    @jeremiah-k jeremiah-k committed Aug 18, 2026
  • Updated How MMRelay Works (markdown)

    @jeremiah-k jeremiah-k committed Aug 17, 2026
  • Updated How MMRelay Works (markdown)

    @jeremiah-k jeremiah-k committed Aug 17, 2026
  • docs: rewrite How-MMRelay-Works from code-verified behavior Ground every claim in the implementation and Meshtastic sources: - Custom meshtastic_* fields exist for relay-to-relay identity transfer, not room display; visible attribution comes from the message prefix - Document both default prefixes ([{long}/{mesh}]: and {display5}[M]: ) and their prefix_format knobs - Document remote-instance handling: identity read from metadata, original prefix stripped, same-meshnet events dropped (loop prevention) - Add multi-meshnet round-trip walkthrough and forged-attribution note - Channel count 0-7 verified against mtjk MAX_CHANNELS and protobufs

    @jeremiah-k jeremiah-k committed Aug 17, 2026
  • docs: correct mapping to 1:1 per instance; document multi-meshnet room sharing Remove the claim that multiple Matrix rooms may map to the same channel within one instance. Mapping is one Meshtastic channel (0-7) to one Matrix room per MMRelay instance. Bridging multiple meshnets into one room is done by running one relay per meshnet pointing at the same room, with custom fields preserving origin.

    @jeremiah-k jeremiah-k committed Aug 17, 2026
  • docs: organize MMRelay concepts and navigation

    @jeremiah-k jeremiah-k committed Aug 17, 2026