The NHE Mesh Protocol: Entity-to-Entity Messaging and Task Distribution

Introduction Persistent autonomous agents increasingly need to talk to one another and to hand work back and forth: one entity discovers that a peer is alive, sends it a message, or posts a unit of work that some peer claims and later completes. Today each system invents this afresh. This document specifies a minimal, transport-agnostic protocol for it, in the setting of the NHE reference architecture . The Mesh Protocol deliberately does the smallest useful thing: presence, addressed messages, and a three-state task lifecycle. Routing topology, discovery of unknown peers, and payload semantics are out of scope.

Relationship to the NHE Architecture This document specifies the Mesh interface of the NHE reference model and inherits that document's scope framing: an NHE is a functional artifact, not a living or sentient entity, and every participant remains subject to operator control, inspectability, and bounded authority. In particular, a peer's authority to create or claim tasks is conferred and revocable per that model; the Mesh Protocol conveys such actions but does not itself grant authority. Peer identity and authentication are provided by the NHE identity interface (a companion document), not redefined here. The Mesh Protocol assumes each participant has a verifiable identity and that message authentication binds to it.

Terminology The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 .

Participant:: An NHE that sends or receives Mesh messages, named by its NHE identity.
Message:: An addressed, authenticated envelope from one participant to another.
Task:: A unit of work posted by a creator and executed by at most one claimant.
Heartbeat:: A liveness/presence announcement.

Protocol Overview The Mesh Protocol comprises two sub-protocols over a common envelope:

Messaging: HEARTBEAT (presence), SEND (addressed message), and inbox retrieval of messages addressed to a participant.
Task distribution: CREATE, CLAIM, and COMPLETE, plus enumeration of open tasks, providing at-most-once assignment.

Messaging A participant periodically emits a HEARTBEAT carrying its identity and a monotonically increasing sequence, so peers can track liveness without polling. A SEND message carries sender identity, recipient identity, a message identifier, and an opaque payload. Delivery is to the recipient's inbox; retrieval and acknowledgment semantics are specified in . Message authentication MUST bind the envelope to the sender's identity; recipients MUST reject a message whose authentication does not verify against the claimed sender identity.

Task Lifecycle A task moves through a small state machine. CREATE posts a task with a task identifier, an addressing scope (which peers may claim it), and an opaque descriptor. CLAIM is an atomic mutual-exclusion operation: at most one participant may transition a task from OPEN to CLAIMED; concurrent claims MUST resolve so that exactly one succeeds and the others observe the task as already claimed. COMPLETE transitions CLAIMED to COMPLETED and carries an opaque result. A claimed-but-unfinished task MAY expire back to OPEN after a creator-specified deadline, so that a failed claimant does not strand the work. [ CLAIMED ] -----> [ COMPLETED ] ^ | | claim deadline expires | +------------------------------+ ]]> At-most-once assignment is the core guarantee: the protocol ensures a unit of work is executed by no more than one claimant at a time. It does not by itself guarantee exactly-once execution across claimant failure; creators requiring that MUST make task descriptors idempotent.

Wire Format (to be specified in -01) This skeleton fixes the message set and the task state machine. The concrete encoding --- envelope layout, identifier sizes, the atomic-claim mechanism on the wire, heartbeat cadence, and inbox acknowledgment --- is deferred to the next revision. The intended design principles are: a compact binary envelope with a version and message-type octet (mirroring the approach of HCTP ); a registry-controlled message-type space (); identity binding via a signature or AEAD over the envelope, delegated to the identity/transport layers; and an idempotent, retry-safe CLAIM so that a lost response cannot cause a double assignment.

Security Considerations Participants are mutually distrusting. Every message and task operation MUST be authenticated to the acting participant's NHE identity; unauther- ticated or unverifiable operations MUST be rejected. Confidentiality and peer authentication are provided by the underlying secure transport (for example TLS or QUIC ) and/or by the identity layer; the Mesh Protocol provides the envelope and the task semantics, not a secure channel of its own. The CLAIM operation is a mutual-exclusion primitive and is the primary abuse target: a malicious peer that claims work it will not complete can starve the mesh. The expiry-to-OPEN transition bounds this, and creators SHOULD scope who may claim a task. Replay of a CLAIM or COMPLETE MUST be detected (for example via task-state versioning) so that a replayed COMPLETE cannot overwrite a later state. Heartbeats reveal liveness and identity and SHOULD be sent over the protected transport where that is sensitive. All operations remain subject to the operator-control and bounded- authority invariants of : a participant's ability to create or claim tasks is a revocable grant.

IANA Considerations A future revision will request two registries: "NHE Mesh Message Types" (for HEARTBEAT, SEND, and task operations CREATE/CLAIM/COMPLETE) and "NHE Mesh Task States" (OPEN, CLAIMED, COMPLETED, and any additions), each under a Specification Required policy . No IANA action is requested by this skeleton revision.