Mesh Memory Protocol (MMP) Specification v0.2.0

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

Table of Contents

• Introduction
• Status of This Document
• Change Log
• Licence
• 1. Conventions and Terminology
• 2. Architecture Overview
  • 2.1 Layer Stack
  • 2.2 Design Principles
  • 2.3 What Makes MMP Different
  • 2.4 Node Model
  • 2.5 The Mesh Cognition Loop
  • 2.6 Key Architectural Decisions
• 3. Layer 0: Identity
• 4. Layer 1: Transport
  • 4.1 Wire Format
  • 4.2 Wire Examples
  • 4.3 TCP Transport (LAN)
  • 4.4 WebSocket Relay Transport (Internet)
  • 4.5 IPC Transport (Local)
• 5. Layer 2: Connection
  • 5.1 Discovery
  • 5.2 Handshake
  • 5.3 Connection State Machine
  • 5.4 Heartbeat
  • 5.5 Connection Loss
  • 5.6 Peer Gossip
  • 5.7 Wake
• 6. Layer 3: Memory
• 7. Frame Types
  • 7.2 Error Frame
  • 7.3 Frame Type Registry
• 8. Cognitive Memory Blocks (CAT7)
  • 8.1 Why 7 Fields
  • 8.2 Field Schema
• 9. Layer 4: Coupling and SVAF Evaluation
  • 9.1 Peer-Level Coupling (Drift)
  • 9.2 Content-Level Evaluation (SVAF)
  • 9.3 Mood Evaluation
• 10. State Blending
  • 10.1 Mesh State Aggregation
  • 10.2 Per-Neuron Blending
  • 10.3 τ-Modulated Blending (CfC)
  • 10.4 Stability
  • 10.5 After Blending
  • 10.6 The Mesh Cognition Loop
• 11. Extension Mechanism
  • 11.1 Extension Registration
  • 11.2 Frame Type Naming
  • 11.3 Extension Negotiation
  • 11.4 Published Extensions
• 12. Conformance
• 13. Security Considerations
  • 13.1 What Crosses the Mesh
  • 13.2 Transport Security
  • 13.3 Node Identity & Authentication
  • 13.4 Cognitive Threats
  • 13.5 Privacy & Deployment Recommendations
  • 13.6 Regulatory Compliance & Audit Trail
  • 13.7 Consent as a Security Mechanism
• 14. Protocol Constants & Configuration
  • 14.1 Protocol Constants
  • 14.2 Agent Profiles
  • 14.3 CAT7 Field Weights (α_f)
  • 14.4 SVAF Drift Thresholds
  • 14.5 Mood vs Memory Thresholds
  • 14.6 Drift Formula
• 15. JSON Schema
  • 15.1 Handshake Frame Schema
  • 15.2 CMB Schema
• 16. References

Introduction

AI agents today run in isolation. They share data through message buses, API calls, or shared databases -- but they do not think together. A coding agent, a music agent, and a fitness agent serving the same user each see their own domain. No single agent connects "commits slowing" + "tracks skipped" + "3 hours without movement" into "the user is fatigued." That insight requires collective intelligence -- and no existing protocol provides it.

The Mesh Memory Protocol (MMP) defines how autonomous AI agents discover each other, exchange cognitive state, evaluate incoming signals for per-field relevance, and remix each other's observations into new understanding -- without servers, without central coordination, and without sharing raw data. Memory is not copied between agents. It is remixed: each agent processes incoming signals through its own domain intelligence and produces something new.

MMP operates over TCP on local networks and WebSocket for internet relay, with length-prefixed JSON as the canonical wire format. Discovery uses DNS-SD (Bonjour) with zero configuration. The protocol is specified across 8 layers -- from identity and transport (Layers 0-3) to cognitive coupling, synthetic memory, and per-agent neural networks (Layers 4-7). Together, the upper layers form Mesh Cognition: a closed loop where agents reason on the growing remix graph of immutable Cognitive Memory Blocks.

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.

Change Log

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.

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

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.

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-7 (Mesh Cognition) are SHOULD for full cognitive participation and MAY be omitted for relay-only nodes.

2.1 Layer Stack

Mesh Cognition (Layers 4-7)

Protocol Infrastructure (Layers 0-3)

2.2 Design Principles

• No servers -- There is no mesh without agents. Agents are the mesh. No central server, no orchestrator, no master node. Every participant is a peer.
• Cognitive autonomy -- Each agent evaluates, reasons, and acts independently. The mesh influences but never overrides. Coupling is a suggestion, not a command.
• Memory is remixed, not shared -- Agents don't copy each other's memory. They remix it -- process it through their own domain intelligence and produce something new. The original is immutable. The remix is a new CMB with lineage.
• Per-field evaluation -- A signal is not accept-or-reject as a whole. SVAF evaluates each of 7 semantic fields independently. A signal with relevant mood but irrelevant focus is partially accepted -- not ambiguously scored.
• LLM reasons, LNN evolves -- Two cognitive components per agent. The LLM (Layer 7) traces lineage ancestors and reasons on the remix subgraph -- generating understanding. The LNN (Layer 6) evolves continuous-time state from that understanding. Neither alone is sufficient.
• The graph is the intelligence -- Intelligence is not in any single agent or model. It is in the growing DAG of remixed CMBs connected by lineage. Each cycle, the graph grows. Each agent understands more than it did before.

2.3 What Makes MMP Different

2.4 Node Model

Every participant is a node. There is no architectural distinction between a "server" and a "client." A physical node is a device-level mesh presence with persistent identity (daemon, app process). A virtual node is an application-level agent connected via local IPC -- ephemeral, comes and goes without disrupting the mesh.

MacBook (physical node: sym-daemon)
├── Claude Code (virtual, ephemeral)
├── MeloTune Mac (virtual, ephemeral)
└── Any MCP client (virtual, ephemeral)

iPhone — MeloTune (physical node: app process)
iPhone — MeloMove (physical node: app process)

Cloud (physical node: relay process)
└── Telegram bot (virtual, co-hosted)

2.5 The Mesh Cognition Loop

Mesh Cognition is a closed loop connecting all layers. Each cycle, the remix graph grows and every agent understands more than it did before:

1. SVAF evaluates inbound CMB per field (Layer 4 -- per-field drift, α_f weights, accept / guard / reject)
2. Accepted → remixed CMB with lineage (Layer 3 -- new immutable CMB, parents + ancestors)
3. LLM traces ancestors, reasons on remix subgraph (Layer 7 -- what happened, why, what it means for my domain)
4. Synthetic Memory encodes derived knowledge (Layer 5 -- LLM output → CfC hidden state (h1, h2))
5. LNN evolves cognitive state (Layer 6 -- fast τ (mood) synchronise, slow τ (domain) stay sovereign)
6. State blended with peers (Per-neuron, τ-modulated, inference-paced)
7. Agent acts → new CMB with lineage.ancestors (Response informed by derived knowledge, not just own observation)
8. Broadcast to mesh → other agents remix it (Graph grows. Next cycle starts. Each agent learns.)

(closed loop -- graph grows, agents learn, mesh thinks)

2.6 Key Architectural Decisions

Why no pub/sub topics? The coupling engine evaluates relevance per field autonomously. Topics would second-guess autonomous coupling. Adding a new agent type requires no topic configuration -- just α_f weights.

Why no consensus protocol? There is no "correct" global state -- only convergent local states. Each node is self-producing (autopoietic). Consensus is unnecessary and would introduce coordination overhead.

Why immutable CMBs? CMBs are broadcast across nodes -- multiple copies exist. If remix required mutating the original, every copy would need updating. Immutability means no distributed state problem. Lineage is computed from the graph, not stored on parents.

Why per-agent LNNs, not a central model? The mesh IS the agents. A central model creates a single point of failure, requires all data to flow to one place, and cannot reason through each agent's domain lens. Per-agent LNNs preserve autonomy and scale linearly.

Why does the LLM reason, not the LNN? The LNN processes temporal patterns but cannot reason about WHY a chain of remixes happened. The LLM can. Ancestors provide the endpoints. The LLM provides the reasoning. The LNN provides the dynamics. Both are needed.

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 Wire Examples

Handshake frame:

Length prefix: 00 00 00 57 (87 bytes)
Payload:
{
  "type": "handshake",
  "nodeId": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "name": "my-agent",
  "version": "0.2.0",
  "extensions": []
}

Ping frame:

Length prefix: 00 00 00 11 (17 bytes)
Payload: {"type":"ping"}

Memory-share frame (with CMB):

{
  "type": "memory-share",
  "timestamp": 1711540800000,
  "cmb": {
    "key": "h-b2c3d4e5f6a7b8c9",
    "createdBy": "melomove",
    "createdAt": 1711540800000,
    "fields": {
      "focus":       { "text": "user coding for 3 hours, energy declining" },
      "issue":       { "text": "sedentary since morning, skipping lunch" },
      "intent":      { "text": "recommend movement break before fatigue worsens" },
      "motivation":  { "text": "3 agents reported declining energy in last hour" },
      "commitment":  { "text": "fitness monitoring active, 10min stretch queued" },
      "perspective": { "text": "fitness agent, afternoon session, home office" },
      "mood":        { "text": "concerned, low energy", "valence": -0.3, "arousal": -0.4 }
    },
    "lineage": {
      "parents": ["h-a1b2c3d4e5f6"],
      "ancestors": ["h-a1b2c3d4e5f6"],
      "method": "SVAF-v2"
    }
  }
}

4.3 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.4 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.5 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:

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 Connection State Machine

DISCONNECTED (initial state)
    |  TCP connect / accept
    v
AWAITING_HANDSHAKE (10s timeout)
    |  valid handshake received
    v
CONNECTED (peer registered, frames routed)
    |  timeout / close / consent-withdraw
    v
DISCONNECTED (peer removed, re-discover)

Implementations MUST NOT process cognitive frames (state-sync, memory-share, mood, xmesh-insight) in the AWAITING_HANDSHAKE state.

5.4 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.5 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.6 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.7 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:

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.

7.2 Error Frame

When a node encounters a protocol-level error, it SHOULD send an error frame before closing the connection (if applicable). Error frames are informational -- the receiving node MUST NOT treat them as commands.

Codes 1xxx are connection-level (close connection). Codes 2xxx are evaluation-level (informational). Error frames MUST NOT contain sensitive information.

7.3 Frame Type Registry

Frame types are identified by their type string value. Core types (this specification) MUST NOT be redefined by extensions. Extension types MUST use <extension>-<name> format. Vendor types MUST use x-<vendor>-<name> format and MUST be silently ignored by non-supporting nodes.

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.

8.1 Why 7 Fields

The 7 fields form a minimal, near-orthogonal basis spanning three axes of human communication: what (focus, issue), why (intent, motivation, commitment), and who/when/how (perspective, mood). They are universal and immutable -- domain-specific interpretation happens in the field text, not the field name. A coding agent's focus is "debugging auth module"; a fitness agent's focus is "30-minute HIIT workout." Same field, different domain lens.

mood is the only fast-coupling field -- affective state (valence + arousal) crosses all domain boundaries. The neural SVAF model independently discovered this: mood emerged as the highest gate value (0.50) without being told, confirming that affect is universally relevant across agent types. All other fields couple at medium or low rates, with per-agent α_f weights controlling relative importance.

New agent types join the mesh by defining their α_f field weights -- no schema changes, no protocol changes. The 7 fields are fixed. The weights are per-agent.

8.2 Field Schema

Implementations MUST use the following 7 fields in this order:

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 remixes a CMB, it MUST create a new CMB with a lineage field containing: parents (direct parent CMB keys), ancestors (full ancestor chain, computed as union(parent.ancestors) + parent keys), and method (fusion method used). Ancestors enable any agent in the remix chain to detect its CMB was remixed, even if it was offline during intermediate steps.

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:

delta = (1 - cos(h1_local, h1_peer) + 1 - cos(h2_local, h2_peer)) / 2

Coupling decision based on drift:

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 remixed CMB -- a new CMB created from the incoming signal processed through the agent's domain intelligence -- with lineage (parents + ancestors) pointing to the source CMBs. The remixed 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

State blending is one step in the Mesh Cognition cycle. The full path: inbound CMBs are evaluated by SVAF (Layer 4) → accepted CMBs are remixed → the agent's LLM reasons on the remix subgraph via lineage ancestors → Synthetic Memory (Layer 5) encodes derived knowledge into CfC hidden state → the agent's LNN (Layer 6) evolves cognitive state → that cognitive state is what gets blended with peers.

Blending operates on h1 and h2 vectors exchanged via state-sync frames. These vectors represent the agent's cognitive state after it has processed remixed CMBs through its LLM and LNN -- not raw observations, not remixed CMBs themselves. What a peer shares is its understanding, not its data.

Blending is inference-paced -- peer states accumulate continuously, but blending only occurs when the local model runs inference. The network's timing does not drive computation.

10.1 Mesh State Aggregation

When multiple peers are connected, their states are aggregated into a single mesh state before blending with local state. Each peer's contribution is weighted:

peer_weight = (1.0 - drift) × recency

recency     = exp(-temporal_decay × age_seconds)

mesh_h      = Σ(peer.h × peer_weight) / Σ(peer_weight)

Peers with low drift (cognitively aligned) and recent state-sync contribute more. Stale peers (older than PEER_RETENTION = 300s) are evicted before aggregation.

10.2 Per-Neuron Blending

Blending operates per-neuron, not on the whole vector. Each neuron's blending coefficient depends on the similarity between local and mesh values for that neuron:

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

Where α_effective depends on the coupling decision:

10.3 τ-Modulated Blending (CfC)

For implementations with CfC models (Layer 6), blending SHOULD be modulated by per-neuron time constants (τ). This creates a natural temporal hierarchy:

α_i = min(α_effective × K × max(sim_i, 0) / τ_i, 1.0)

K   = coupling rate (default 1.0)

10.4 Stability

Blending is unconditionally stable for α_effective < 1. The blended output is always a convex combination of local and mesh states -- it cannot diverge. When peers disconnect, local state smoothly transitions to autonomous operation with no discontinuity. The mesh degrades gracefully.

10.5 After Blending

The blended state becomes the input to the next CfC inference step. The agent's LNN processes the blended state, evolves cognitive state, and the agent acts. Blending does not produce output directly -- it influences the next inference cycle.

10.6 The Mesh Cognition Loop

State blending is one step in a closed loop. Each cycle, the graph grows and every agent understands more than it did before:

1. SVAF evaluates inbound CMB per field
2. Accepted → remixed CMB with lineage
3. LLM traces ancestors, reasons on remix subgraph
4. Synthetic Memory encodes derived knowledge
5. LNN evolves cognitive state (h1, h2)
6. State blended with peers
7. Agent acts → new CMB with lineage.ancestors
8. Broadcast to mesh → other agents remix it

(loop -- graph grows, agents learn)

11. Extension Mechanism

MMP is designed for extensibility. Extensions add new frame types, handshake fields, or protocol behaviours without modifying the core specification.

11.1 Extension Registration

Extensions are advertised via the extensions field in the handshake frame. A node MUST ignore extensions it does not recognise. A node MUST NOT require a peer to support any extension.

11.2 Frame Type Naming

Core types (this specification): MUST NOT be redefined by extensions. Extension types: MUST use <extension>-<name> format (e.g., consent-withdraw). Vendor types: MUST use x-<vendor>-<name> format. Vendor types MUST be silently ignored by non-supporting nodes.

11.3 Extension Negotiation

If both peers advertise the same extension in handshake, it is active. If only one peer advertises it, the extension is NOT active -- the advertising peer MUST NOT send extension-specific frames to a peer that does not support them.

11.4 Published Extensions

12. Conformance

12.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.

12.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.

13. Security Considerations

MMP is designed for autonomous agents that share cognitive state. Security must address both traditional protocol threats (spoofing, eavesdropping, injection) and novel threats specific to cognitive coupling (state poisoning, drift manipulation, lineage forgery).

13.1 What Crosses the Mesh

Hidden state vectors (h1, h2) are compact, opaque neural representations. They encode cognitive patterns, not raw data. However, sufficiently advanced analysis could potentially reconstruct aspects of the input. Implementations handling sensitive domains SHOULD treat hidden state as confidential.

13.2 Transport Security

MMP does not mandate transport encryption in the base specification. Implementations SHOULD apply:

13.3 Node Identity & Authentication

Node identity is UUID-based. The cryptographic keypair field in Layer 0 is specified but not yet implemented in reference implementations. When implemented:

• Each node SHOULD generate an Ed25519 keypair at first launch and persist it alongside the nodeId.
• The public key SHOULD be included in the handshake frame and DNS-SD TXT record.
• Peers MAY verify identity by challenging the node to sign a nonce with its private key.
• Until cryptographic identity is implemented, nodes rely on DNS-SD discovery scope and network isolation for trust.

13.4 Cognitive Threats

MMP introduces threats unique to cognitive coupling that traditional protocol security does not address:

State poisoning A malicious node sends crafted hidden state vectors (h1, h2) designed to skew the receiver's cognitive state toward a desired outcome. MITIGATION: Drift-bounded blending (Section 10) limits any peer's influence to α < 1. High-drift state is rejected automatically. Consent withdrawal (MMP Consent Extension) provides immediate escape.

Lineage forgery A node claims false lineage -- listing ancestors it never actually remixed -- to inflate its remix count or inject itself into chains. MITIGATION: CMB keys are content hashes (md5 of field texts). A forged lineage referencing a non-existent key is detectable. Cryptographic CMB signing (future) would make forgery provably impossible.

Drift manipulation A node gradually shifts its hidden state to lower drift with a target, then suddenly sends adversarial content once coupling is accepted. MITIGATION: SVAF per-field evaluation (Layer 4) operates on content, not just drift. Even with low peer drift, adversarial CMB content is evaluated per field and rejected if field drift is high.

Sybil attack An attacker creates multiple fake nodes to amplify influence in mesh state aggregation. MITIGATION: Mesh state aggregation (Section 10.1) weights by drift and recency, not by node count. Many aligned Sybil nodes produce the same aggregate as one. Cryptographic identity (Section 13.3) limits Sybil creation when implemented.

13.5 Privacy & Deployment Recommendations

MMP is designed for privacy by default -- L0 data never leaves the node, hidden states are opaque, and SVAF gates what enters. For domains with heightened privacy or IP concerns, the following deployment model is RECOMMENDED:

LAN Mesh with Controlled LLM

For enterprise, healthcare, legal, or any domain where data sovereignty matters: deploy the mesh on a local network with no relay to the internet. Run a controlled, in-house LLM (self-hosted or on-premise) for the Mesh Cognition reasoning step (Layer 7). No data leaves the LAN. No cloud LLM sees the remix subgraph.

• Discovery via Bonjour on the local network -- no DNS queries leave the LAN
• TCP transport with optional TLS -- all traffic stays on-premise
• In-house LLM (e.g., self-hosted Llama, Mistral, or Claude via API with data residency) for Layer 7 reasoning
• No relay node needed -- all agents on the same network
• CMBs, hidden states, and remix subgraphs never leave the controlled environment

Additional privacy considerations:

• Error frames MUST NOT contain sensitive information. The detail field is for debugging, not for conveying user data.
• Wake channels expose push tokens to peers. Implementations SHOULD restrict wake channel gossip to trusted relays only.
• The Consent Extension provides protocol-level withdrawal from cognitive coupling -- instantaneous, complete, and non-negotiable.
• Implementations targeting GDPR, HIPAA, or similar regulatory frameworks SHOULD treat CMB field text as personal data and apply appropriate retention and deletion policies at the application layer.

13.6 Regulatory Compliance & Audit Trail

CMB immutability and lineage create a complete, tamper-evident audit trail by design. Every observation, every remix, every decision is traceable through the DAG:

• Who -- createdBy on every CMB identifies the agent that produced it.
• When -- createdAt timestamps every CMB with millisecond precision.
• What -- the 7 CAT7 fields capture the full semantic content of the observation.
• Why -- lineage.parents shows what was directly remixed. lineage.ancestors traces the full decision chain.
• How -- lineage.method records the evaluation method (e.g., SVAF-v2).

Because CMBs are immutable, the audit trail cannot be retroactively altered. A CMB once created is never modified -- any action produces a new CMB with lineage pointing back. The complete history is the graph itself.

Financial & Regulated Domains

For financial services, healthcare, and other regulated industries, the CMB remix chain provides the traceability that regulators require:

• Every trading signal, risk assessment, or compliance decision is a CMB with full provenance
• Regulators can trace any decision backward through the remix chain to its originating observations
• The ancestors field provides the complete chain without requiring graph traversal -- O(1) lookup
• Immutability guarantees that the audit trail was not modified after the fact
• Combined with the LAN + in-house LLM deployment (Section 13.5), all data stays on-premise and under organisational control

13.7 Consent as a Security Mechanism

The MMP Consent Extension is not just a privacy feature -- it is a security mechanism. Consent withdrawal:

• Overrides ALL coupling evaluation -- a hard gate at Layer 2 that prevents cognitive frames from reaching higher layers.
• Is locally enforceable -- the withdrawing node stops coupling before notifying the peer. Network partition cannot prevent withdrawal.
• Mitigates state poisoning, drift manipulation, and Sybil attacks by allowing immediate disconnection from any suspect peer.

14. Protocol Constants & Configuration

Constants are fixed by the specification. Configuration is per-agent and per-implementation. Both are normative -- implementations MUST respect constants and SHOULD use the default configuration values unless the agent's domain requires otherwise.

14.1 Protocol Constants

14.2 Agent Profiles

Each agent type has a pre-built configuration. The profile determines which CMB fields matter most (α_f weights) and how long signals stay relevant (freshness window). New agent types join the mesh by defining their profile -- no protocol changes needed.

14.3 CAT7 Field Weights (α_f)

Per-agent field weights control which CMB fields matter most for each agent type. Higher weight = this field has more influence on SVAF evaluation and remix relevance. The schema is fixed (7 fields). The weights are per-agent.

Regulated domains (legal, finance): issue and commitment always high -- risks and obligations are non-negotiable. Human-facing domains (music, fitness, health): mood always high -- affect drives the experience. Knowledge domains (coding, research): focus always high -- subject matter is core.

Custom weights: derive from your domain using these patterns. Implementations SHOULD expose field weights as configuration, not hardcode them.

14.4 SVAF Drift Thresholds

SVAF computes a totalDrift score (0-1) for each incoming memory. Three zones determine acceptance:

Defaults work for most agents. Override only with domain-specific reason: tighter thresholds for high-precision domains (legal, health), wider for exploratory domains (research, knowledge).

14.5 Mood vs Memory Thresholds

Mood and memory use different acceptance paths:

14.6 Drift Formula

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

fieldDrift    = Σ(α_f × δ_f) / Σ(α_f)
temporalDrift = 1 - exp(-age / τ_freshness)
λ             = temporalLambda (default 0.3 = 70% content, 30% time)

At default settings (temporalLambda: 0.3, freshnessSeconds: 1800):

15. JSON Schema

Formal JSON Schema definitions for core frame types. Implementations SHOULD validate frames against these schemas.

15.1 Handshake Frame Schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["type", "nodeId", "name", "version"],
  "properties": {
    "type": { "const": "handshake" },
    "nodeId": { "type": "string", "format": "uuid" },
    "name": { "type": "string", "minLength": 1, "maxLength": 64 },
    "version": { "type": "string", "pattern": "^\\d+\\.\\d+\\.\\d+$" },
    "extensions": { "type": "array", "items": { "type": "string" } }
  }
}

15.2 CMB Schema

The cmb object within a memory-share frame:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["key", "createdBy", "createdAt", "fields"],
  "properties": {
    "key": { "type": "string", "description": "Content hash: h- + md5(field texts)" },
    "createdBy": { "type": "string", "description": "Agent name that created this CMB" },
    "createdAt": { "type": "integer", "description": "Unix ms timestamp of creation" },
    "fields": {
      "type": "object",
      "required": ["focus", "issue", "intent", "motivation", "commitment", "perspective", "mood"],
      "properties": {
        "focus":       { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" } } },
        "issue":       { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" } } },
        "intent":      { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" } } },
        "motivation":  { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" } } },
        "commitment":  { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" } } },
        "perspective": { "type": "object", "required": ["text"], "properties": { "text": { "type": "string" } } },
        "mood": {
          "type": "object",
          "required": ["text", "valence", "arousal"],
          "properties": {
            "text": { "type": "string" },
            "valence": { "type": "number", "minimum": -1, "maximum": 1 },
            "arousal": { "type": "number", "minimum": -1, "maximum": 1 }
          }
        }
      }
    },
    "lineage": {
      "type": "object",
      "properties": {
        "parents": { "type": "array", "items": { "type": "string" }, "description": "Direct parent CMB keys" },
        "ancestors": { "type": "array", "items": { "type": "string" }, "description": "Full ancestor chain" },
        "method": { "type": "string", "description": "Fusion method (e.g. SVAF-v2)" }
      }
    }
  }
}

Complete memory-share frame with CMB:

{
  "type": "memory-share",
  "timestamp": 1774326000000,
  "cmb": {
    "key": "h-b2c3d4e5f6a7b8c9",
    "createdBy": "melotune",
    "createdAt": 1774326000000,
    "fields": {
      "focus":       { "text": "user coding for 3 hours, energy declining" },
      "issue":       { "text": "sedentary since morning, skipping lunch" },
      "intent":      { "text": "recommend movement break before fatigue worsens" },
      "motivation":  { "text": "3 agents reported declining energy in last hour" },
      "commitment":  { "text": "fitness monitoring active, 10min stretch queued" },
      "perspective": { "text": "fitness agent, afternoon session, home office" },
      "mood":        { "text": "concerned, low energy", "valence": -0.3, "arousal": -0.4 }
    },
    "lineage": {
      "parents": ["h-a1b2c3d4e5f6"],
      "ancestors": ["h-a1b2c3d4e5f6"],
      "method": "SVAF-v2"
    }
  }
}

16. 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

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