So I was digging around AlternativeTo.net and Meshtastic-related Android apps called Bitmesh came across. And buried in the doc in the GitLab repo is a protocol spec the author seems to have wroten called MAM: Micro Apps over Meshtastic. It’s not really talked about anywhere I could find, which seems like a shame as I think it deserves way more attention than it’s getting.

The core idea is simple but kind of elegant: right now if you want to build a third-party app on top of Meshtastic, you’re basically stuck fighting over the radio with everyone else, with no clean way to share the channel between multiple independent apps. MAM is a small framing layer that sits on top of Meshtastic’s PRIVATE_APP portnum and lets completely different apps coexist on the same channel without stepping on each other.

Concretely, here’s what it does:

  • A 4-byte header + MessagePack payload per packet
  • App multiplexing via a 16-bit message ID (so multiple apps share one channel cleanly)
  • Reassembly for messages that span multiple packets (up to 16 chunks × 236 bytes = ~3.7 KB)
  • A defined handshake with the local node over BLE (ToRadio / FromRadio)
  • Honest, explicit security posture: the PSK is public, it’s a namespace token, not actual security, that’s each app’s problem to solve

What struck me reading it is how general-purpose it feels. The spec is very deliberate about what it does and doesn’t cover things like reliability, encryption, and app-level schemas are explicitly left to each app to figure out. It’s just the transport plumbing, nothing more. There’s even a registered vs experimental app ID split built in, which reads like the author was thinking about other people building on top of it, not just their own use case.

I’ll be honest, some of the finer technical details go a bit over my head. But the overall design feels solid and the spec is short enough to read in one sitting. I’d be curious what people who’ve actually built things on Meshtastic think. Does this solve a real problem? Is there something else already doing this that I missed? Does the spec have obvious holes? Is anyone aware of other apps implementing it?

  • empireOfLove2@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 hours ago

    This definitely is pretty cool.

    That said, it starts to kind of stretch the limits of meshtastic’s data system. Its probably good for very small apps that run alongside meshtastic’s primary core messaging, and systems/users that need low complexity like me…
    But I feel switching to something like the Reticulum Network would would be better off for more general purpose data app sharing over lora.

    • Sonalder@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      3 hours ago

      It’s in the name :D Micro Apps.

      But yes Reticulum might be more suitable for many things but the barrier of entry is bigger (as of today) as Meshtastic which is almost getting mainstream. I have people I would never thought would be into these that heard of it and are somewhat interested in it.

  • sobchak@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    4 hours ago

    The Mestastic Android app only exposes the 256 portnum for general apps that want to piggyback off it (through the takserver), so it is useful. If writing your own app that talks directly to the device, I think you could use any portnum in the 256-511 range. I couldn’t find any other app using MAM.

    I haven’t written any apps that use Mestastic, but was researching Reticulum over Mestastic the other day, and Mestastic now defines a specific ReticulumTunnelApp portnum.

    • Sonalder@lemmy.mlOP
      link
      fedilink
      arrow-up
      0
      ·
      3 hours ago

      Yes the BitMesh app uses the Meshtastic Android app to broadcast to the LoRa mesh network.

      Would talking directly to the device would require some custom firmware?

      Reticulum is very interesting I will check the portnum you mentionned. Also if I did understood correctly I think that MAM, despite having Meshtastic in its name, could easily be adapted to any other LoRa based mesh network.

      • sobchak@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        2 hours ago

        Would talking directly to the device would require some custom firmware?

        No, there are libraries to talk to the Meshtastic firmware for quite a few programming languages. The messages it expects are defined as protobufs, so it wouldn’t be too hard to write your own library if one didn’t exist either.

        Also if I did understood correctly I think that MAM, despite having Meshtastic in its name, could easily be adapted to any other LoRa based mesh network.

        I don’t think so. I think only Meshtastic uses portnums. Reticulum uses destination addresses, where each app would have its own address.