Protocol Specification

Mesh Memory Protocol (MMP)

A Peer-to-Peer Protocol for Collective Intelligence Between Autonomous AI Agents

Version0.2.0
StatusPublished
Date27 March 2026
AuthorHongwei Xu <hongwei@sym.bot>
OrganisationSYM.BOT Ltd
Canonical URLhttps://sym.bot/spec/mmp
LicenceCC BY 4.0 (specification text); Apache 2.0 (reference implementations)

Abstract

The Mesh Memory Protocol (MMP) defines how autonomous AI agents discover each other on a network, exchange cognitive state, evaluate incoming signals for relevance, and synthesise collective intelligence — without servers, without central coordination, and without sharing raw data.

MMP operates over TCP on local networks and WebSocket for internet relay. The protocol is transport-agnostic in principle but normatively specifies length-prefixed JSON framing over TCP as the canonical wire format. Discovery uses DNS-SD (Bonjour) with zero configuration. Cognitive coupling is evaluated per-peer and per-signal using drift-bounded blending with learned or heuristic per-field evaluation.

Status of This Document

This is a published specification. It reflects the protocol as implemented in the reference implementations (SYM Node.js and SYM Swift). The specification is versioned. Breaking changes increment the minor version; non-breaking additions increment the patch version.

Feedback and errata: spec@sym.bot or github.com/sym-bot/sym/issues.

1. Conventions and Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

TermDefinition
NodeA participant in the mesh. Every node has a unique identity and runs an independent cognitive model.
Physical nodeA device-level mesh presence with persistent identity and transport connections (e.g., a daemon process, an iOS app process).
Virtual nodeAn application-level agent connected to a physical node via local IPC. Ephemeral — comes and goes without disrupting the mesh.
PeerAnother node that this node has an active transport connection with and has completed a handshake.
FrameA single protocol message: a length-prefixed JSON object sent over a transport connection.
CMBCognitive Memory Block — a structured memory unit with 7 typed semantic fields (CAT7 schema). See Section 8.
DriftA scalar measure of cognitive distance between two nodes or between a signal and local state. Range [0, 1].
CouplingThe process by which a node blends its local cognitive state with peer state, weighted by drift and confidence.
SVAFSymbolic-Vector Attention Fusion — per-field content-level evaluation of incoming memory signals. See Section 9.

2. Architecture Overview

MMP is an 8-layer protocol stack. Each layer has a defined responsibility. Implementations MUST implement Layers 0–3 to participate in the mesh. Layers 4–6 (Mesh Cognition) are SHOULD for full cognitive participation and MAY be omitted for relay-only nodes.

Layer 7  APPLICATION     Domain-specific agent behaviour
Layer 6  xMesh           Per-agent LNN — bidirectional CMB flows, coupled CfC
Layer 5  SYM             Synthetic Memory (agent memory → CfC input)
Layer 4  COUPLING        Drift evaluation · SVAF per-field evaluation
──────────────────────────────────────────────────
Layer 3  MEMORY          L0 events · L1 structured · L2 cognitive state
Layer 2  CONNECTION      Handshake · heartbeat · peer gossip · wake
Layer 1  TRANSPORT       TCP (LAN) · WebSocket (relay) · IPC (local)
Layer 0  IDENTITY        nodeId (UUID) · name

3. Layer 0: Identity

Each node MUST have a globally unique nodeId (UUID v4) generated at first launch and persisted across sessions. Each node MUST have a human-readable name (UTF-8 string, 1–64 bytes). The nodeId MUST NOT change during the lifetime of a node installation.

4. Layer 1: Transport

4.1 Wire Format

Frames are length-prefixed JSON over TCP. Each frame consists of:

+-------------------+---------------------------+
| 4 bytes           | N bytes                   |
| UInt32BE (length) | UTF-8 JSON payload        |
+-------------------+---------------------------+
  • The length field is a 4-byte big-endian unsigned 32-bit integer encoding the byte length of the JSON payload.
  • Implementations MUST reject frames with length 0 or length exceeding 1,048,576 bytes (1 MiB). Rejection MUST close the transport connection.
  • The JSON payload MUST be a valid JSON object with a type field (string). Frames that fail JSON parsing or lack a type field MUST be silently discarded.
  • Implementations MUST handle partial reads (TCP stream reassembly).
  • Implementations MUST silently ignore frames with unrecognised type values (forward compatibility).

4.2 TCP Transport (LAN)

The primary transport. Nodes MUST listen on a TCP port and advertise it via DNS-SD (Section 5.1). Connection timeout MUST be no longer than 10,000 ms.

4.3 WebSocket Relay Transport (Internet)

For nodes not on the same LAN, a relay node forwards frames. Relay frames are JSON envelopes over WebSocket: { "to": "<nodeId>", "payload": <frame> }. The relay MUST NOT inspect or modify the payload. The relay is a peer, not a server — any always-on node MAY serve as a relay.

4.4 IPC Transport (Local)

Virtual nodes connect to their physical node via local IPC (Unix domain socket, named pipe, or localhost TCP). The framing is identical to TCP transport.

5. Layer 2: Connection

5.1 Discovery

Nodes MUST advertise via DNS-SD with service type _sym._tcp in the local. domain. The instance name MUST be the node’s nodeId.

TXT record fields:

KeyRequiredValue
node-idMUSTNode UUID
node-nameMUSTHuman-readable name
hostnameSHOULDMachine hostname

To prevent duplicate connections, the node with the lexicographically smaller nodeId MUST initiate the outbound TCP connection. The other node MUST NOT initiate.

5.2 Handshake

Upon connection, both sides MUST exchange the following frames in order:

1. handshake    { type: "handshake", nodeId: "<uuid>", name: "<name>",
                  version: "0.2.0", extensions: [] }
2. state-sync   { type: "state-sync", h1: [...], h2: [...], confidence: 0.8 }
3. peer-info    { type: "peer-info", peers: [...] }           [if known]
4. wake-channel { type: "wake-channel", platform, token, env } [if configured]
  • The version field MUST be the MMP specification version the node implements (e.g., "0.2.0"). Nodes SHOULD accept peers with the same major version. Nodes MAY reject peers with incompatible versions.
  • The extensions field SHOULD list supported protocol extensions (e.g., ["consent-v0.1"]). Nodes MUST ignore unrecognised extensions.
  • The inbound node MUST wait for a handshake frame as the first frame. If any other frame type arrives first, or no handshake arrives within 10,000 ms, the connection MUST be closed.
  • If a node receives a handshake with a nodeId that is already connected, the new connection MUST be closed (duplicate guard).

5.3 Heartbeat

Nodes MUST send a ping frame to each peer if no frame has been received from that peer within the heartbeat interval (default: 5,000 ms). Upon receiving ping, a node MUST respond with pong. If no frame is received from a peer within the heartbeat timeout (default: 15,000 ms), the connection MUST be closed.

5.4 Connection Loss

When a transport connection closes unexpectedly (TCP reset, timeout, OS-level close), the node MUST remove the peer from its coupling engine, discard any buffered frames for that peer, and emit a peer-left event. The node SHOULD attempt re-discovery via DNS-SD. Unexpected disconnection MUST be treated as equivalent to the peer becoming unreachable — not as a protocol error.

5.5 Peer Gossip

After handshake, nodes SHOULD exchange peer-info frames containing known peer metadata (nodeId, name, wake channels, last-seen timestamps). This enables transitive peer discovery — a node that has never been online simultaneously with a sleeping peer can learn its wake channel through gossip from a relay node.

5.6 Wake

Nodes MAY register a wake channel (APNs, FCM, or other push mechanism) via the wake-channel frame. Peers MAY use this channel to wake a sleeping node when they have a signal to deliver. Wake requests SHOULD be rate-limited (default cooldown: 300,000 ms per peer).

6. Layer 3: Memory

MMP defines three memory layers with graduated disclosure:

LayerNameSharedDescription
L0EventsNoRaw events, sensor data, interaction traces. Local only.
L1StructuredVia evaluationContent + tags + source. Shared via memory-share frames, gated by SVAF (Layer 4).
L2CognitiveVia state-syncCfC hidden state vectors. Exchanged via state-sync frames. Input to coupling.

L0 data MUST NOT leave the node. L1 data MUST be evaluated by SVAF before storage. L2 data is exchanged on every handshake and periodically (default: every 30,000 ms). The h1 and h2 vectors in state-sync frames MUST have equal dimension. The dimension is implementation-defined (reference implementations use 64). Peers with mismatched dimensions MUST reject the state-sync frame and SHOULD log the mismatch.

7. Frame Types

All frames are JSON objects with a type field (string). Implementations MUST silently ignore frames with unrecognised type values to allow forward compatibility.

TypeLayerGatedFields
handshake2NonodeId (string), name (string), version (string), extensions (string[])
state-sync2/3Noh1 (float[]), h2 (float[]), confidence (float)
memory-share3/4SVAFkey, content, source, tags (string[]), timestamp, originTimestamp?, confidence?
mood4Driftfrom, fromName, mood (string), context?, timestamp
message2Nofrom, fromName, content, timestamp
xmesh-insight6Nofrom, fromName, trajectory (float[6]), patterns (float[8]), anomaly (float), outcome (string), coherence (float), timestamp
peer-info2Nopeers: [{ nodeId, name, wakeChannel?, lastSeen }]
wake-channel2Noplatform (string), token (string), environment (string)
ping2No(no additional fields)
pong2No(no additional fields)

8. Cognitive Memory Blocks (CAT7)

A Cognitive Memory Block (CMB) is an immutable structured memory unit. Each CMB decomposes an observation into 7 typed semantic fields (the CAT7 schema). CMBs are the data structure that flows between agents via memory-share frames.

Implementations MUST use the following 7 fields in this order:

IndexFieldAxisCaptures
0focusSubjectWhat the text is centrally about
1issueTensionRisks, gaps, assumptions, open questions
2intentGoalDesired change or purpose
3motivationWhyReasons, drivers, incentives
4commitmentPromiseWho will do what, by when
5perspectiveVantageWhose viewpoint, situational context
6moodAffectEmotion (valence) + energy (arousal)

Each field carries a symbolic text label (human-readable) and a unit-normalised vector embedding (machine-comparable). The mood field additionally carries numeric valence (-1 to 1) and arousal (-1 to 1) values.

A CMB MUST NOT be modified after creation. When an agent acts on a CMB, it MUST create a new CMB with a lineage field referencing the parent CMB key(s) and the fusion method used.

9. Layer 4: Coupling and SVAF Evaluation

9.1 Peer-Level Coupling (Drift)

When a node receives a state-sync frame, it MUST compute peer drift:

δ = (1 − cos(h1local, h1peer) + 1 − cos(h2local, h2peer)) / 2

Coupling decision based on drift:

Drift rangeDecisionBlending αDefault threshold
δ ≤ TalignedAligned0.400.25
Taligned < δ ≤ TguardedGuarded0.150.50
δ > TguardedRejected0

9.2 Content-Level Evaluation (SVAF)

When a node receives a memory-share frame, it MUST evaluate the signal independently of peer coupling state. Implementations MUST support at least the heuristic evaluation path. Neural evaluation is RECOMMENDED.

The SVAF evaluation computes per-field drift between the incoming CMB and local anchor CMBs, applies per-agent field weights (αf), combines with temporal drift, and produces a three-class decision (aligned / guarded / rejected):

totalDrift = (1 - λ) × fieldDrift + λ × temporalDrift

fieldDrift    = Σ(α_f × δ_f) / Σ(α_f)
temporalDrift = 1 - exp(-age / τ_freshness)

κ = aligned   if totalDrift ≤ T_stable    (default 0.25)
κ = guarded   if totalDrift ≤ T_guarded   (default 0.50)
κ = rejected  otherwise

If accepted, the implementation SHOULD produce a fused CMB — a new CMB synthesised from the incoming and anchor CMBs — with lineage pointing to the parent CMBs. The fused CMB is stored locally; the original incoming CMB is not stored.

9.3 Mood Evaluation

mood frames are evaluated separately from memory-share frames. Mood is encoded into a transient hidden state vector pair and evaluated via peer-level drift. The default mood threshold (0.80) is more permissive than the memory threshold (0.50) because affective state crosses all domain boundaries.

10. State Blending

When coupling is accepted (aligned or guarded), the local hidden state is blended with the peer’s state. Per-neuron blending:

sim_i  = 1 - |local_i - mesh_i| / max(|local_i|, |mesh_i|)
α_i    = α_effective × max(sim_i, 0)
out_i  = (1 - α_i) × local_i + α_i × mesh_i

For implementations with CfC models (Layer 6), blending SHOULD be modulated by per-neuron time constants (τ): αi = min(αeff × K × max(simi, 0) / τi, 1.0). Small τ (fast neurons) couple readily; large τ (slow neurons) resist coupling.

11. Conformance

11.1 Minimal Conformance (Relay Node)

A node claiming minimal MMP conformance MUST implement: Layer 0 identity (persistent UUID), Layer 1 transport (length-prefixed JSON over TCP), Layer 2 connection (handshake, heartbeat, gossip), and frame forwarding for relay. It MUST silently ignore unrecognised frame types.

11.2 Full Conformance (Cognitive Node)

A node claiming full MMP conformance MUST additionally implement: Layer 3 memory (L0/L1/L2), Layer 4 SVAF evaluation (at minimum heuristic), state-sync exchange with drift computation and coupling, and CMB creation with CAT7 field schema.

12. Security Considerations

  • Hidden state vectors (h1, h2) are compact, opaque neural representations. No raw user data crosses the mesh.
  • The current specification does not mandate transport encryption. Implementations SHOULD use TLS for TCP connections and WSS for WebSocket relay in production deployments.
  • Node identity is currently UUID-based with no cryptographic authentication. Future versions will specify a cryptographic keypair for identity verification (noted as [future] in Layer 0).
  • Peer approval for wake channels is implicit (any connected peer may wake). Implementations SHOULD rate-limit wake requests.

13. Protocol Constants

ConstantValueNotes
MAX_FRAME_SIZE1,048,576 bytesFrames exceeding this MUST be rejected
HANDSHAKE_TIMEOUT10,000 msInbound identification deadline
HEARTBEAT_INTERVAL5,000 msDefault; configurable per implementation
HEARTBEAT_TIMEOUT15,000 msDefault; configurable per implementation
STATE_SYNC_INTERVAL30,000 msDefault periodic re-broadcast
WAKE_COOLDOWN300,000 msDefault per-peer wake rate limit
PEER_RETENTION300 sStale peer eviction age
DNS-SD_SERVICE_TYPE_sym._tcpService type for Bonjour discovery
DNS-SD_DOMAINlocal.Discovery domain

14. References

[RFC 2119] Bradner, S. (1997). Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119.

[DNS-SD] Cheshire, S. & Krochmal, M. (2013). DNS-Based Service Discovery. IETF RFC 6763.

[CfC] Hasani, R. et al. (2022). Closed-form continuous-time neural networks. Nature Machine Intelligence, 4, 992–1003.

[Kuramoto] Kuramoto, Y. (1975). Self-entrainment of a population of coupled non-linear oscillators. Lecture Notes in Physics, 39, 420–422.

[SYM] Reference implementation (Node.js): github.com/sym-bot/sym

[SYM-Swift] Reference implementation (Swift): github.com/sym-bot/sym-swift

15. Change Log

VersionDateChanges
0.2.02026-03-27Formal specification published. 8-layer architecture. CAT7 CMB schema. SVAF per-field evaluation. Wire format normatively specified.
0.1.02025-08-01Initial protocol design (Consenix Labs Ltd). 4-layer architecture. Scalar drift evaluation.

16. Licence

This specification is published under the Creative Commons Attribution 4.0 International Licence (CC BY 4.0). You may share, adapt, and build upon this specification for any purpose, including commercial use, provided you give appropriate credit.

The reference implementations are published under the Apache Licence 2.0.

Mesh Memory Protocol, MMP, SYM, and related marks are trademarks of SYM.BOT Ltd.

© 2026 SYM.BOT Ltd. Specification text licenced under CC BY 4.0. Reference implementations licenced under Apache 2.0.