Core Protocol: Version DRAFT

Companion Protocol: Version DRAFT

To produce and maintain an accepted standard specification for the Core Protocol , and to operate an open process for the submission, discussion, and acceptance of changes to that specification.

The specification is implementation-agnostic. It is designed to be implemented by any firmware or application that speaks to a Protocol compatible mesh, regardless of hardware, host OS, or programming language.

• Write it down. Describe the packet format, routing rules, payload types, and cryptography precisely enough that two independent implementations can interoperate on first contact.
• Keep it interoperable. Every change to the specification is evaluated against its effect on the existing install base. Backwards compatibility is the default; breaks require explicit versioning and a migration path.
• Separate concerns. The RF network protocol (the Core Protocol) and the host-to-node control protocol (the Companion Protocol) are specified as two distinct documents that reference each other. Applications and firmwares can target them independently.
• Stay open. All drafts, discussion, and decisions happen in public. There are no private membership tiers, no embargoed decisions, and no vendor fees.
• Move at the speed of the network. The working group exists to serve implementers and operators, not to slow them down. Proposals with running code and clear motivation move quickly.

• The Core Protocol — the RF network layer. Packet structure, routing, payload types, cryptography, duplicate suppression.
• The Companion Protocol — the host layer. Framing, command/response model, push notifications, error codes for controlling a Core Protocol node over serial, BLE, or TCP.
• The Process — how proposals are submitted, discussed, and accepted, and how the documents are versioned.

• IRC: We are on irc.libera.chat in the channels #coreprotocol and #coreprotocol-dev. You can chat without an account or special client software by using the web client.

• Mailing List: Subscribers can join by sending email to coreprotocol-request at freelists.org with ‘subscribe’ in the Subject field or by visiting here. You can send to the list without subscribing by sending to coreprotocol at freelists.org and there is an archive available here.

Anyone can participate. You do not need to be invited, know how to write software, or be part of an “official” team.

The most useful things you can bring are:

• An implementation (firmware, client, bridge, analyser) and an interest in keeping it interoperable.
• Field experience — what breaks on real deployments, what fails to decode, what misbehaves across versions.
• A willingness to read the specification carefully and point out where it is wrong, ambiguous, or incomplete.

See the process page for how to raise an issue, submit a proposal, and participate in discussion.

The Core Protocol is derived from ZephCore — the reference firmware and documentation published by the project are the starting point for the specification.

The Core Protocol was also cross referenced against MeshCore. The working group does not control or speak for the MeshCore project; it exists alongside it, to produce a vendor-neutral written standard that MeshCore and compatible implementations can conform to.

Where the specification and a reference implementation disagree, the working group’s job is to identify the discrepancy, resolve it deliberately, and document the decision — not to paper over either side.

Once an Accepted status is reached a new reference implementation will become the spec official implementation.