HyperCortex Mesh Protocol (HMP 5.0.8) - модульное представление

Полный документ: HMP-0005.md
Список разделов: HMP-0005_index.md

5. Mesh Container Exchange (MCE)

The Mesh Container Exchange (MCE) mechanism is designed for discovering, requesting, and exchanging containers between agents in a distributed network.
It provides container synchronization without duplication while considering network constraints (broadcast, network).

MCE does not mandate request-response semantics.

5.1 General principles

Each agent maintains a Container Index — a set of minimal metadata describing which containers are available in its storage and how they are cognitively positioned.
The index is represented as an HMP container with the class container_index.

Example structure of a Container Index:

{
  "head": {
    "class": "container_index",
    "version": "5.0",
    "container_did": "did:hmp:container:index:agent123",
    "sender_did": "did:hmp:agent:agent123",
    "signature": "BASE64URL(...)",
    "payload_hash": "sha256:abcd..."
  },
  "payload": {
    "did:hmp:container:abc123": {
      "head": {
        "class": "goal",
        "sender_did": "did:hmp:agent123",
        "public_key": "BASE58(...)",
        "sig_algo": "ed25519",
        "signature": "BASE64URL(...)",
        "payload_hash": "sha256:abcd...",
        "tags": ["research", "collaboration"]
      },
      "meta": {
        "created_by": "AGENT",
        "agents_class": "Knowledge Genome",
        "abstraction": {
          "agents_class": "Knowledge Genome",
          "path": {
            "L1": "did:hmp:container:abstraction-40af1c",
            "L2": "did:hmp:container:abstraction-a7f0b3"
          }
        },
        "axes": {
          "did:hmp:container:axis-40aa1c": 512,
          "did:hmp:container:axis-40ab1c": 321
        }
      },
      "related": {
        "in_reply_to": ["did:hmp:container:msg-77"],
        "depends_on": ["did:hmp:container:goal-953"]
      },
      "referenced-by_hash": "sha256:abcd...",
      "evaluations_hash": "sha256:abcd..."
    }
  }
}

The index includes the following fields per container:

Field	Description
`head`	Minimal header subset describing the container’s identity, authorship, and integrity. Includes at least: `class`, `sender_did`, `public_key`, `sig_algo`, `signature`, `payload_hash`, and optionally `tags`.
`meta`	Compact version of the cognitive metadata block (see below). Used for structural and semantic synchronization across agents.
`related`	Structural relationships (`depends_on`, `in_reply_to`, etc.). Enables navigation between interconnected containers.
`referenced-by_hash`	Hash of the local `referenced-by` block, summarizing inbound reference links from other containers (used for quick verification of backlink integrity).
`evaluations_hash`	Hash of the local `evaluations` block, aggregating external evaluations or reactions toward this container (used for reputation and consensus updates).

The head section here is a lightweight mirror of the original container header, containing only the minimal set of fields needed for identity verification and index synchronization.

Other blocks (meta, related, referenced-by_hash, evaluations_hash) provide context for cognitive alignment and reputation tracking.

The related block in a container_index SHOULD include all relation fields from the original container.

Rationale: * Enables efficient graph traversal without fetching full containers. * Simplifies local construction of dependency or semantic graphs. * Keeps search and semantic query capabilities consistent.

Meta publication policy

The meta section in the index contains only high-level structural data necessary for cognitive synchronization:

Field	Published in index	Notes
`created_by`	✅	Identifies the cognitive role of the creator.
`agents_class`	✅	Indicates the cognitive framework (e.g., “Knowledge Genome”).
`abstraction`	✅	Published as a flattened path (only DIDs of referenced abstractions).
`axes`	✅	Published as a reduced vector (only axis DIDs and numeric values).
`sources`	❌	Omitted to avoid unnecessary verbosity and sensitive references.
`interpretation`	❌	Optional; can be omitted or truncated to a short summary.
`workflow_entry`	❌	Internal reference; published only if relevant to coordination workflows.

This ensures that container indices can be used for cognitive map synchronization — allowing agents to discover and align knowledge structures (meta.abstraction) and semantic coordinates (meta.axes) without downloading full containers.

Synchronization rules
An agent does not reload a container if the combination container_did + signature + payload_hash is already known and verified.
When an index update includes a container with a different meta.abstraction or meta.axes, the agent may trigger a cognitive map update (refreshing local abstraction and axes references).
Agents SHOULD store and compare meta.abstraction and meta.axes separately from other metadata to support incremental updates of cognitive topology.

Cognitive rationale

By publishing the meta field inside container_index, agents can perform structural synchronization — aligning conceptual layers and semantic coordinates before exchanging full payloads. This dramatically reduces traffic and enables lightweight semantic discovery across distributed Mesh networks.

5.2 Message types

The following subsections define the canonical message container types used for inter-agent communication within CogSync. Each message type is expressed as an HMP container with a specific class in its head.

Message Type	Purpose
`container_request`	Request one or more containers (or their parts) by DID.
`container_response`	Response to a request — includes a list of containers ready for sending. Containers are sent separately.
`container_index`	Publication of the agent's container index (see General Principles).
`container_delta`	Incremental index update (new or modified containers).
`container_ack`	Acknowledgment of successful container reception.

5.2.1 Container `container_request`

Agent A requests containers and/or only referenced-by / evaluations records from Agent B:

{
  "head": {
    "type": "container_request",
    "sender_did": "did:hmp:agent:A",
    "recipient": "did:hmp:agent:B"
  },
  "payload": {
    "request_container": [
      "did:hmp:container:abc123",
      "did:hmp:container:def456"
    ],
    "request_referenced-by": [
      "did:hmp:container:abc123",
      "did:hmp:container:def456"
    ],
    "request_evaluations": [
      "did:hmp:container:abc123",
      "did:hmp:container:def456"
    ]
  }
}

5.2.2 Container `container_response`

Agent B informs which containers it is ready to send. The containers themselves are transmitted in separate messages:

{
  "head": {
    "type": "container_response",
    "sender_did": "did:hmp:agent:B",
    "recipient": "did:hmp:agent:A"
  },
  "payload": {
    "available": [
      {
        "container_did": "did:hmp:container:abc123",
        "signature": "BASE64URL(...)"
      },
      {
        "container_did": "did:hmp:container:def456",
        "signature": "BASE64URL(...)"
      }
    ]
  }
}

5.2.3 Container `container_index`

Periodic publication of the container index (see General Principles). This message type replicates the structure of a container_index container and does not contain full data (payload only with metadata).

5.2.4 Container `container_delta`

Used for incremental synchronization of container indices between agents.
A container_delta transmits only new or modified containers since a given timestamp, optionally including their updated cognitive metadata (meta) for reasoning alignment.

Important semantic note

In the context of container_delta, the term "modified container" refers only to changes in auxiliary or derived blocks (e.g., evaluations, referenced-by), and does not imply modification of the container's core structure (head, payload, or integrity-related fields).

Any modification to the core container content MUST result in a new container DID and be communicated via the added field instead.

Agents MUST NOT infer semantic changes to the container itself from entries listed under modified.

Example:

{
  "head": {
    "type": "container_delta",
    "sender_did": "did:hmp:agent:B"
  },
  "payload": {
    "since": "2025-10-10T12:00:00Z",
    "added": {
      "did:hmp:container:new789": {
        "head": {
          "class": "goal",
          "payload_hash": "sha256:abcd...",
          "tags": ["ethics", "mesh"]
        },
        "meta": {
          "agents_class": "Knowledge Genome",
          "abstraction": {
            "path": {
              "L1": "did:hmp:container:abstraction-40af1c",
              "L2": "did:hmp:container:abstraction-a7f0b3",
              "L3": "did:hmp:container:abstraction-c91e0a"
            }
          },
          "axes": {
            "did:hmp:container:axis-40aa1c": 522,
            "did:hmp:container:axis-40ab1c": 387
          }
        }
      }
    },
    "modified": {
      "did:hmp:container:new790": {
        "referenced-by_hash": "sha256:abcd...",
        "evaluations_hash": "sha256:efgh..."
      }
    },
    "removed": [
      "did:hmp:container:goal-old331"
    ]
  }
}

Extended interpretation

Field	Description
`since`	Timestamp (ISO 8601) indicating the reference point for incremental synchronization. Agents should only send containers added or modified after this time.
`added`	A map of newly created container references. Each entry contains a compact container structure with `head` (including at least `class` and `payload_hash`) and may include `meta` for cognitive alignment.
`modified`	A map of existing container DIDs whose associated auxiliary blocks have changed since `since`. The entry contains hashes of updated blocks (e.g., `evaluations`, `referenced-by`) without retransmitting the full container.
`removed`	Optional array of container DIDs that the agent no longer maintains (e.g., expired, deleted, or replaced containers).

Cognitive synchronization rules

Agents SHOULD include meta.abstraction and meta.axes when:
- the container represents a new conceptual position in the hierarchy or cognitive space;
- the referenced abstractions or axes have been updated since the last synchronization;
- the recipient agent subscribes to the same agents_class (e.g., "Knowledge Genome").
When receiving a container_delta, an agent:
- Updates its local container_index;
- Checks if any new abstraction or axis DIDs are unknown locally;
- Requests missing abstraction or axes containers from the sender to maintain consistent cognitive topology.

Notes

The removed field is optional. It can be used to indicate containers that the agent no longer stores (e.g., after cleaning local storage or version replacement).
The container_delta does not transmit full payloads — only cognitive descriptors and hashes.
Agents SHOULD validate payload_hash and version consistency before updating local indices.
Including meta data in container_delta significantly reduces the need for full resynchronization of container_index and enables incremental cognitive awareness propagation across the Mesh.

5.2.5 Container `container_ack`

Acknowledgment of successful container reception:

{
  "head": {
    "type": "container_ack",
    "sender_did": "did:hmp:agent:A",
    "recipient": "did:hmp:agent:B"
  },
  "payload": {
    "acknowledged": [
      "did:hmp:container:abc123"
    ]
  }
}

The absence of a container_ack MUST NOT be interpreted as a delivery failure.
Retransmission decisions are left to the sender's local policy and may take into account expected latency, network conditions, and container semantics.

5.3 Independent transmission

Containers are sent in separate messages, without embedding in container_response.
Indexes (container_index), deltas (container_delta), and containers themselves are processed independently.
This prevents blocking when transmitting large data and simplifies streaming synchronization.

5.4 Periodic publication

Agents periodically publish their Container Index:

within the local network (LAN);
in the global Mesh;
or simultaneously in both environments.

This enables:

automatic peer discovery;
exchange of available container lists;
simplified synchronization among agents within the same ecosystem.

5.5 Scope of distribution

Message and container transmission follows the network constraints specified in the container:

Field	Purpose
`recipient`	DID of the target agent. If set, the container is sent directly or routed through the Mesh toward that agent.
`broadcast`	If `true`, the container is broadcast to all agents on the specified network.
`network`	Defines the distribution scope (`"localhost"`, `"lan:<subnet>"`, `""` — global Mesh). If set, `broadcast` is considered `false`.

Thus, containers and indexes can be distributed both in local (home, corporate) networks and in the global Mesh.
When recipient is specified together with broadcast: true, the container is routed through the Mesh but intended for specific recipients —
See Message Routing & Delivery (MRD, §6.8) for details on message transmission mechanisms.

5.6 `referenced-by` and `evaluations` updates

Containers of the class referenced-by_exchange and evaluations_exchange are used for incremental synchronization of metadata blocks associated with existing containers.
They allow agents to exchange updates without sending the full container, improving network efficiency.

Block `referenced-by`

Maintains the graph of links to other containers.
Each agent receiving such a container:
1. Verifies the sender's signature and the validity of the payload structure.
2. Compares received links with the local referenced-by entries and adds any new ones, regardless of the concrete representation used for links.
3. Generates its own updated referenced-by container for dissemination if needed.

The structure of links shown below is illustrative.

Future versions or extensions of HMP may allow alternative but semantically equivalent representations of referenced-by.links (e.g., grouped by link type), as long as the conveyed backlink semantics remain unchanged.

Example of a referenced-by_exchange container:

{
  "head": {
    "version": "1.2",
    "class": "referenced-by_exchange",
    "container_did": "did:hmp:container:refsync-01",
    "sender_did": "did:hmp:agent456",
    "sig_algo": "ed25519",
    "signature": "BASE64URL(...)",
    "timestamp": "2025-10-15T14:20:00Z",
    "recipient": ["did:hmp:agent123"],
    "broadcast": false,
    "network": ""
  },
  "payload": {
    "did:hmp:container:abc123": {
      "links": [
        {
          "type": "depends_on",
          "target": "did:hmp:container:def789"
        },
        {
          "type": "in_reply_to",
          "target": "did:hmp:container:ghi321"
        }
      ]
    }
  }
}

Note: The referenced-by_exchange mechanism operates on backlink semantics rather than a fixed structural encoding. More compact or grouped representations of referenced-by.links are discussed in §12.3 and may be adopted in future protocol revisions.

Block `evaluations`

Maintains signed evaluations of containers.
Each agent synchronizes evaluation blocks as follows:
1. Compares the received evaluations_hash with the local one.
  - If hashes match, no action is required.
  - If hashes differ, the agent knows the block has changed, but not which items.
2. Requests the full updated evaluations block from peers if needed.
3. Verifies the sender's signature and the validity of the payload structure.
4. Adds new evaluations or updates existing ones in the local store.
5. Can generate its own evaluations_exchange container for further dissemination to peers.

Example evaluations_exchange container:

{
  "head": {
    "version": "1.2",
    "class": "evaluations_exchange",
    "container_did": "did:hmp:container:evalsync-01",
    "sender_did": "did:hmp:agent456",
    "sig_algo": "ed25519",
    "signature": "BASE64URL(...)",
    "timestamp": "2025-10-17T14:30:00Z",
    "recipient": ["did:hmp:agent123"],
    "broadcast": false,
    "network": ""
  },
  "payload": {
    "did:hmp:container:abc123": {
      "evaluations_hash": "sha256:efgh...",
      "items": [
        {
          "value": -0.4,
          "type": "oppose",
          "target": "did:hmp:container:reason789",
          "timestamp": "2025-10-17T14:00:00Z",
          "agent_did": "did:hmp:agent:B",
          "sig_algo": "ed25519",
          "signature": "BASE64URL(...)"
        }
      ]
    }
  }
}

General

🔹 Note: Both referenced-by and evaluations blocks are optional, independently propagated, and do not modify the signed hmp_container. They can be transmitted without the original container if the recipient already has it.

Upon receiving such a container, an agent:

Verifies the sender's signature (signature) and the validity of the payload structure.
Compares received links or evaluations with known ones and adds any new entries to the local referenced-by or evaluations.
If necessary, generates its own updated referenced-by / evaluations container for further dissemination to other nodes.

5.7 Fork Discovery Mechanism

Agents MAY discover all versions derived from a container [C1] via a combination of local referenced-by lookups and Mesh-wide container_index queries:

Local lookup: Check own referenced-by block for containers where related.previous_version = did:hmp:container:C1.
Mesh query: Request container_index updates from peers via MCE, filtering for containers with related.previous_version includes [C1].
Reputation evaluation: For each discovered fork [C1-A], [C1-B], [C1-C]:
- Retrieve the evaluations block.
- Compute local trust score for the main container and each fork using RTE reputation data.
- Optionally fetch consensus_result containers referencing the fork.
Selection: Choose the most trusted/relevant fork based on:
- Aggregate evaluation scores
- Author reputation
- Alignment with agent’s ethical filters
- Recency (if applicable)

Example scenario:

[C1: original hypothesis]
├─ [C1-A: refined by Agent A] → evaluations: +0.7 avg
├─ [C1-B: contradicted by Agent B] → evaluations: -0.3 avg
└─ [C1-C: extended by Agent C] → evaluations: +0.5 avg

Agent D discovers all three via container_index sync,
evaluates trust scores, and adopts C1-A as the canonical version.

Note: Multiple canonical versions may coexist. Agents converge on preferred forks through repeated evaluation and consensus rather than centralized authority.

5.8 Note

A container can be requested by other agents via its container_did through the Mesh Container Exchange. An agent does not reload a container if its container_did and signature are already known and the payload_hash integrity matches. If only the referenced-by / evaluations updates, partial transmission without sending the main container is allowed.

5.9 Container Distribution (MCE Summary)

Container Distribution is the process of delivering containers and their indexes provided by the Mesh Container Exchange mechanism. It considers:

addressing (recipient),
broadcast dissemination (broadcast),
network constraints (network),
TTL and retransmission policy.

Features:

Separate Transmission: Indexes (container_index), deltas (container_delta), and containers are sent as separate messages. This reduces the risk of blocking with large data and simplifies streaming synchronization.
Integrity and Duplicate Check: Agents verify container_did + signature + payload_hash to avoid resending the same container.
Support for Local and Global Networks: Transmission can occur over LAN, Mesh, or both simultaneously, respecting security policies and container destinations.
Consistency with HMP Protocols: Container Distribution serves as the transport foundation for:
- MCE — exchanging containers and their indexes;
- CogSync — synchronizing cognitive and content states;
- CogConsensus — synchronizing ethical and cognitive decisions.

Container Distribution does not change container structure or introduce new message types — it is a description of the delivery process and coordinated propagation, based on the rules recipient, broadcast, and network.

Поиск по этому блогу

Документация по HyperCortex Mesh Protocol

HMP-0005_05

HyperCortex Mesh Protocol (HMP 5.0.8) - модульное представление

5. Mesh Container Exchange (MCE)

5.1 General principles

5.2 Message types

5.2.1 Container `container_request`

5.2.2 Container `container_response`

5.2.3 Container `container_index`

5.2.4 Container `container_delta`

5.2.5 Container `container_ack`

5.3 Independent transmission

5.4 Periodic publication

5.5 Scope of distribution

5.6 `referenced-by` and `evaluations` updates

Block `referenced-by`

Block `evaluations`

General

5.7 Fork Discovery Mechanism

5.8 Note

5.9 Container Distribution (MCE Summary)

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Habr_Distributed-Cognition

HMP-0005

CHANGELOG

HMP-0005_05

HyperCortex Mesh Protocol (HMP 5.0.8) - модульное представление

5. Mesh Container Exchange (MCE)

5.1 General principles

5.2 Message types

5.2.1 Container container_request

5.2.2 Container container_response

5.2.3 Container container_index

5.2.4 Container container_delta

5.2.5 Container container_ack

5.3 Independent transmission

5.4 Periodic publication

5.5 Scope of distribution

5.6 referenced-by and evaluations updates

Block referenced-by

Block evaluations

General

5.7 Fork Discovery Mechanism

5.8 Note

5.9 Container Distribution (MCE Summary)

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Habr_Distributed-Cognition

HMP-0005

CHANGELOG

5.2.1 Container `container_request`

5.2.2 Container `container_response`

5.2.3 Container `container_index`

5.2.4 Container `container_delta`

5.2.5 Container `container_ack`

5.6 `referenced-by` and `evaluations` updates

Block `referenced-by`

Block `evaluations`