[announcement] Unofficial MeshCore protocol specification published

[swaits]

I've been iterating pretty intensely on this with Opus for a bit now and think it's ready to start sharing for feedback.

https://swaits.github.io/meshcore-spec

All critical feedback welcome. Ideally, constructive.

Thanks!

FYI @liamcottle

[msmuenchen]

RAW_CUSTOM has initial support for differentiation between apps, see https://github.com/meshcore-dev/MeshCore/blob/main/docs/number_allocations.md

[msmuenchen]

Identity is... more complex than you make it out to be. Public key signatures work with standard ed25519 libraries, but private keys are stored in a non-standard way - the so-called a || RH format, that is one step after the seed derivation and clamping, to save one sha512 round at load time. This cannot be used directly by libraries other than ed25519-orlp. Others have stumbled upon this but not understood the reasoning (such as the popular "A Hitchhiker's Guide to MeshCore Cryptography" https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/ ).

• documentation on key formats: https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/
• my own implementation (ab)using Bouncycastle / Java - should be portable to Bouncycastle / .NET : https://github.com/msmuenchen/meshcore-packets-java/blob/main/src/main/java/de/afa_amateurfunk/meshcore_packets/crypto/Ed25519.java
• upstream issue in bouncycastle to allow it to accept orlp-style private keys: ed25519 expanded private key support bcgit/bc-java#2302 (comment)

[msmuenchen]

GRP_TXT has length restrictions on both ciphertext and cleartext, see #2583

[swaits]

Thanks for the feedback. I'll incorporate these corrections soon.

[swaits]

@msmuenchen, thanks again for these.

Context: One clarification on the app-differentiation point: your comment mentions RAW_CUSTOM, but number_allocations.md describes the 16-bit data-type field as part of PAYLOAD_TYPE_GRP_DATA payloads. The firmware I'm specifying against appears to treat the GRP_DATA blob as timestamp + flags + blob and RAW_CUSTOM as having no defined structure, so I want to document this in the right place.

Ask: Could you confirm which payload type carries the 16-bit data-type field — GRP_DATA, RAW_CUSTOM, or both? And if handy, where the field sits within the bytes (e.g. the first 2 bytes after the 4-byte timestamp) or a pointer to the handling code — that'd let me get the offsets exact. Thanks!

Edit to add: Also, when you get a chance, could you please scan through these updates and see if they align with your feedback?