Add in support for MeshCore

[mikecarper]

Description

Raw custom packet is 184 bytes in MeshCore. https://github.com/meshcore-dev/MeshCore/blob/main/docs/packet_format.md

Rationale

It's an alternate to Meshtastic

Alternatives Considered

No response

[ArxiaLayer1]

Thanks for opening this. MeshCore support is a great fit for what we're building because the architectural goals of MeshCore (lightweight, transport-agnostic, no internet required) align directly with Arxia's offline-first design.

A few notes on the technical landscape:
Payload sizing: Arxia's compact transaction format is 193 bytes (signed SEND block). MeshCore's max payload is 184 bytes per packet. There are two paths forward:

Multipart transmission across two MeshCore packets with reassembly at the receiver
Tightening the Arxia compact serialization to fit in 184 bytes (we have 9 bytes of headroom to find, which is feasible)

We will probably implement both. Multipart is the more general solution and lets us support arbitrary payloads (DID credentials, larger contracts) over MeshCore. Single-packet fit is the optimization for the SEND/RECEIVE hot path.
Integration approach: The right place for this is a new transport crate arxia-transport-meshcore parallel to the existing transport infrastructure. Arxia's Transport trait is already designed to be backend-agnostic (we run a SimulatedTransport for tests, a Python bridge for the current Meshtastic demo, and have native Rust LoRa transport on the roadmap). A native MeshCore transport in Rust fits the same pattern.
What would be most helpful from you:

If you have hardware running MeshCore and would be willing to test the integration once we have a draft, that'd be invaluable
If you have insight into MeshCore's PAYLOAD_TYPE_RAW_CUSTOM specifics (we'd use that for Arxia traffic) and any constraints we should know about
If you have a specific use case in mind (the kind of Arxia transactions you'd want to send over MeshCore), it helps prioritize multipart vs single-packet first

We'll mark this as accepted and add it to the transport roadmap. Native MeshCore support fits naturally between the current Meshtastic Python bridge (already working in our hardware demo) and the planned native Rust LoRa transport.
Tagging this as enhancement transport for the project board.

[mikecarper]

I have heltec v4s I can use for testing purposes; that are already running MeshCore. DMs have a 150 byte limit

And flood messages are at roughly 130 bytes

Here's a project that uses raw for images and audio https://github.com/dz0ny/meshcore-sar/blob/e1400cf1ecc882541c3cddfa1320a5efa3a5c1df/docs/image-mode-technical.md?plain=1#L274

Splitting it up is probably ideal; DMs get an ack back. Raw I think is zero hop only so it does have some useful functionality for local transactions but it'll not go far (I'm guessing here).

[ArxiaLayer1]

Solid info, thanks. The real numbers change the design.
DM at 150 bytes vs Arxia compact SEND at 193 bytes means single-packet isn't realistic, multipart is the right path. Plan: 2-chunk split for DMs (with reassembly using the ack mechanism), raw zero-hop for proximity transactions, flood reserved for short broadcast announcements like block headers.
Will study the meshcore-sar approach for chunk reassembly patterns.
Once we have a draft arxia-transport-meshcore ready for hardware testing, would you be open to flashing your Heltec v4s with the test bridge and running a real round-trip? That'd be the concrete data point we need.

[mikecarper]

Yep I can flash test firmware for you