The NHE Mesh Protocol: Entity-to-Entity Messaging and Task Distribution
draft-ruvalcaba-nhe-mesh-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Cristian Xavier Ruvalcaba | ||
| Last updated | 2026-08-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ruvalcaba-nhe-mesh-00
Individual Submission C.X. Ruvalcaba
Internet-Draft Saluca LLC
Intended status: Standards Track 11 August 2026
Expires: 12 February 2027
The NHE Mesh Protocol: Entity-to-Entity Messaging and Task Distribution
draft-ruvalcaba-nhe-mesh-00
Abstract
The NHE Mesh Protocol lets independently operated Non-Human Entities
(NHEs) exchange messages and distribute work without a central
coordinator. It defines three things: a liveness/presence mechanism,
an addressed message envelope, and a task lifecycle (create, claim,
complete) that provides at-most-once assignment of a unit of work
across mutually distrusting peers. Peers are named by their NHE
identity and authenticated through the NHE identity interface; the
Mesh Protocol carries the envelope and runs over a secure transport.
This is a skeleton (-00): the framing, message set, and state machine
are specified here, and the concrete on-the-wire encoding is deferred
to the next revision.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Ruvalcaba Expires 12 February 2027 [Page 1]
Internet-Draft NHE Mesh August 2026
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Relationship to the NHE Architecture . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Task Lifecycle . . . . . . . . . . . . . . . . . . . . . 4
5. Wire Format (to be specified in -01) . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
9. Informative References . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. 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
[I-D.ruvalcaba-nhe-arch].
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.
2. Relationship to the NHE Architecture
This document specifies the Mesh interface of the NHE reference model
[I-D.ruvalcaba-nhe-arch] 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.
Ruvalcaba Expires 12 February 2027 [Page 2]
Internet-Draft NHE Mesh August 2026
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.
3. Terminology
The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "OPTIONAL" are
to be interpreted as described in BCP 14 [RFC2119] [RFC8174].
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.
4. 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.
4.1. 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 Section 5. 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.
Ruvalcaba Expires 12 February 2027 [Page 3]
Internet-Draft NHE Mesh August 2026
4.2. 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.
CREATE CLAIM (atomic, COMPLETE
| at-most-one) |
v | v
[ OPEN ] -----------+------> [ 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.
5. 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
[I-D.ruvalcaba-hctp]); a registry-controlled message-type space
(Section 7); 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.
Ruvalcaba Expires 12 February 2027 [Page 4]
Internet-Draft NHE Mesh August 2026
6. 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 [RFC8446] or QUIC
[RFC9000]) 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 [I-D.ruvalcaba-nhe-arch]: a participant's
ability to create or claim tasks is a revocable grant.
7. 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 [RFC8126].
No IANA action is requested by this skeleton revision.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
9. Informative References
Ruvalcaba Expires 12 February 2027 [Page 5]
Internet-Draft NHE Mesh August 2026
[I-D.ruvalcaba-hctp]
Ruvalcaba, C.X., "The Hash-Chain Context Transfer Protocol
(HCTP)", Work in Progress, Internet-Draft, draft-
ruvalcaba-hctp-00, August 2026,
<https://datatracker.ietf.org/doc/html/draft-ruvalcaba-
hctp-00>.
[I-D.ruvalcaba-nhe-arch]
Ruvalcaba, C.X., "An Architecture for Non-Human Entities
(NHE)", Work in Progress, Internet-Draft, draft-ruvalcaba-
nhe-arch-00, August 2026,
<https://datatracker.ietf.org/doc/html/draft-ruvalcaba-
nhe-arch-00>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
Author's Address
Cristian Xavier Ruvalcaba
Saluca LLC
Email: cristian@saluca.com
Ruvalcaba Expires 12 February 2027 [Page 6]