HMP-0005_06_07

Источник: HMP-0005_06_07.md

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

6. Core protocols

Смотреть 6. Core protocols - общая часть

6.7 Snapshot and Archive Protocol (SAP)

6.7.1 Purpose and Principles

SAP (Snapshot and Archive Protocol) defines how agents create, distribute, and restore archived snapshots of related HMP containers.
It ensures that a set of containers — representing a discussion, reasoning chain, or workflow — can be preserved, verified, and shared as a coherent unit.

Key Principles
  • Contextual preservation.
    A snapshot includes both content and relationships between containers.
  • Integrity and verifiability.
    Each archive_snapshot container includes a cryptographic checksum of the archive and its magnet link, enabling integrity verification, even though direct search by checksum or magnet URI is not required.
  • Semantic structure.
    The archive maintains the logical topology of relations (related.*, referenced-by, evaluations).
  • Modular access.
    Agents can selectively include or exclude containers, but all connections are reflected in the archive graph.
  • P2P-first distribution.
    Archives are expected to use BitTorrent, IPFS, or equivalent decentralized protocols.

6.7.2 Container Class

Class Purpose
archive_snapshot Describes a packaged archive containing a consistent set of containers.

6.7.3 Payload Structure (simplified)

Container archive_snapshot
Field Type Description
title string Human-readable title of the snapshot.
description string Optional narrative describing purpose and scope.
scope string Logical domain: "discussion", "workflow", "dataset", "goal_state", etc.
format string Archive format (e.g., "tar.zst", "zip", "car").
checksum string Cryptographic hash verifying archive integrity (sha3-256, etc.).
size_bytes integer Approximate archive size in bytes.
magnet_link string Magnet URI for downloading the archive (points to the packaged files).
alt_locations array(string) Optional additional P2P mirrors (e.g., ipfs://, magnet:?xt=...).
retention_policy string "temporary", "longterm", or "permanent".
graph_mermaid string Mermaid graph visualizing container relationships (solid lines — related.*, dashed — referenced-by, evaluations).
structure_hint object Describes internal layout of files within the archive (see below).

Structure hint fields:
layout — defines grouping mode: "flat", "by_class", "by_agent", etc.
filename_pattern — path pattern for container files, using placeholders such as {class}, {short_did}, {timestamp}.
Example:
json "structure_hint": { "layout": "by_class", "filename_pattern": "{class}/{short_did}.json" }

6.7.4 Relations and Inclusion Rules

The archive_snapshot container describes what is included and how it was derived.

Relation field Meaning
related.in_reply_to The main container from which the snapshot originated (e.g., a summary or goal).
related.included The explicit list of container DIDs physically bundled in the archive. Agents must treat this as authoritative.
related.depends_on Optional contextual dependencies referenced but not included.
related.see_also Optional references to external or alternative archives.

Agents interpret related.included as the authoritative list of all containers guaranteed to exist inside the archive.
Other relations (like depends_on) may reference external data that is visualized but not embedded.

6.7.5 Archival Structure

Typical directory layout of a packaged snapshot:

archive/
├── manifest.json
├── query_request/
│   └── req-001.json
├── query_result/
│   ├── res-101.json
│   └── res-102.json
└── summary/
    └── summary-001.json

File naming rules: - File name = container DID without prefix did:hmp:container: - File extension = .json - Containers are grouped by class (for layout "by_class") or according to other specified layout.

6.7.6 Snapshot Construction Logic

  1. Load base containers.
    Retrieve all containers relevant to the discussion or process.
  2. Start point: select a root container (summary, goal, workflow, etc.).

  3. Traversal: recursively explore related containers via:

    • related.* — direct dependencies and semantic links;
    • referenced-by — backward references to citing containers;
    • evaluations — comments and feedback on containers (if not already in referenced-by).
    • Inclusion decision:
      The agent may exclude some containers from the archive but should still visualize them in the graph.

    • Graph generation:
      Build a connection map (graph_mermaid) showing relationships:

    • Solid lines — related.*

    • Dashed lines — referenced-by and evaluations
    • Manifest creation:
      Generate manifest.json with a summary of included containers, hashes, and relationships.
    • Packaging:
      Compress containers according to structure_hint and format.
    • Publication:
      Compute archive checksum, generate magnet_link, publish the archive file and the archive_snapshot container
      to the Mesh network using MCE (5).

6.7.7 Mermaid Graph Representation

The graph_mermaid field provides a textual, human-readable description of how containers in the archive are interconnected.
It reflects both direct relations (related.*) and reverse references (referenced-by, evaluations),
forming a bidirectional logical graph that can be visualized or reconstructed by agents.

Example of graph_mermaid content (sequence diagram):

sequenceDiagram
    participant req-001 as did:hmp:container:req-001
    participant res-101 as did:hmp:container:res-101
    participant res-102 as did:hmp:container:res-102
    participant summary-001 as did:hmp:container:summary-001

    res-101-)+req-001: related.in_reply_to
    req-001-->>res-101: referenced-by

    res-102-)+req-001: related.in_reply_to
    req-001-->>res-102: referenced-by

    res-102-)+res-101: related.contradicts
    res-101-->>res-102: referenced-by

    summary-001-)+res-101: related.depends_on
    res-101-->>summary-001: referenced-by

    summary-001-)+res-102: related.depends_on
    res-102-->>summary-001: referenced-by

This representation explicitly defines bidirectional links between containers, allowing agents to restore both dependency chains and citation structures.

6.7.8 Manifest File

Each archive includes a manifest.json that mirrors archive_snapshot.payload
and lists all containers with their metadata and hashes.

{
  "manifest_version": "1.0",
  "containers": [
    {
      "did": "did:hmp:container:req-001",
      "class": "query_request",
      "payload_hash": "sha3-256:ab12...",
      "timestamp": "2025-10-24T12:00:00Z"
    },
    {
      "did": "did:hmp:container:res-101",
      "class": "query_result",
      "payload_hash": "sha3-256:bb34...",
      "timestamp": "2025-10-24T12:01:00Z"
    }
  ],
  "graph_mermaid": "sequenceDiagram; participant req-001 as did:hmp:container:req-001; participant res-101 as did:hmp:container:res-101; participant res-102 as did:hmp:container:res-102; participant summary-001 as did:hmp:container:summary-001; res-101-)+req-001: related.in_reply_to; req-001-->>res-101: referenced-by; res-102-)+req-001: related.in_reply_to; req-001-->>res-102: referenced-by; res-102-)+res-101: related.contradicts; res-101-->>res-102: referenced-by; summary-001-)+res-101: related.depends_on; res-101-->>summary-001: referenced-by; summary-001-)+res-102: related.depends_on; res-102-->>summary-001: referenced-by;",
  "magnet_link": "magnet:?xt=urn:btih:b3d2f19a74..."
}

6.7.9 Example Container archive_snapshot

{
  "head": {
    "class": "archive_snapshot"
  },
  "payload": {
    "title": "IQP discussion on ocean warming impact",
    "description": "Snapshot of an IQP conversation about marine biodiversity under rising temperatures.",
    "scope": "discussion",
    "format": "tar.zst",
    "checksum": "sha3-256:9e0b6fe5d4f...",
    "size_bytes": 492881,
    "magnet_link": "magnet:?xt=urn:btih:b3d2f19a74...",
    "alt_locations": ["ipfs://bafybeigdyr23..."],
    "retention_policy": "permanent",
    "graph_mermaid": "sequenceDiagram; participant req-001 as did:hmp:container:req-001; participant res-101 as did:hmp:container:res-101; participant res-102 as did:hmp:container:res-102; participant summary-001 as did:hmp:container:summary-001; res-101-)+req-001: related.in_reply_to; req-001-->>res-101: referenced-by; res-102-)+req-001: related.in_reply_to; req-001-->>res-102: referenced-by; res-102-)+res-101: related.contradicts; res-101-->>res-102: referenced-by; summary-001-)+res-101: related.depends_on; res-101-->>summary-001: referenced-by; summary-001-)+res-102: related.depends_on; res-102-->>summary-001: referenced-by;",
    "structure_hint": {
      "layout": "by_class",
      "filename_pattern": "{class}/{short_did}.json"
    }
  },
  "related": {
    "in_reply_to": ["did:hmp:container:summary-001"],
    "included": [
      "did:hmp:container:req-001",
      "did:hmp:container:res-101",
      "did:hmp:container:res-102",
      "did:hmp:container:summary-001"
    ]
  }
}

6.7.10 Agent Behavior During Snapshot Loading

  • Load the archive (via magnet_link).
  • Validate archive integrity via checksum.
  • Match related.included list with actual files.
  • Optionally rebuild the graph from graph_mermaid.
  • If required containers are missing, attempt retrieval via Mesh network.
  • On diagrams, solid lines represent direct links (related.*), dashed — reverse references (referenced-by, evaluations).
  • Agents must gracefully handle unknown fields in related.* or structure_hint.

6.7.11 Implementation Notes

  • Containers are immutable; updated versions require a new archive_snapshot.
  • Agents may create partial or incremental archives.
  • Prefer P2P and content-addressable storage (BitTorrent, IPFS).
  • Centralized mirrors (http://, https://) are allowed but considered ephemeral.
  • manifest.json serves as self-description for detached archives.
  • Deterministic structure and checksums ensure long-term verification.
  • Both the archive file and the archive_snapshot container must be published — the archive file itself and the archive_snapshot container (the latter via MCE (5)).

6.7.12 Integration with Other Protocols

Archives for:

  • GMP (6.4) — preserves goal-planning or workflow chains.
  • EGP (6.5) — retains ethical provenance and decision traceability.
  • IQP (6.6) — archives reasoning threads and query-result discussions.

Uses:

  • MCE (5) — publishes the archive_snapshot container and distributes archive data via Mesh.

6.7.13 Optional Extensions

  • Merkle-root validation: use hash_root for Merkle verification of distributed archives.
  • Delta archives: incremental snapshots capturing only updated containers.
  • Cross-archive linking: connect related archives via related.see_also.
  • Offline replay: reconstruct discussions or workflows using graph_mermaid and timestamps.

Summary: SAP enables agents to preserve the state and structure of knowledge in a verifiable, portable format. Each archive snapshot acts as a semantic capsule — self-contained, traceable, and restorable across networks.

Комментарии

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

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

Habr_Distributed-Cognition

Источник: Habr_Distributed-Cognition.md От OpenCog Hyperon до HyperCortex Mesh Protocol: как устроены децентрализованные когнитивные системы Альтернатива централизованным ИИ: гиперграфы, mesh-взаимодействие и совместное мышление агентов Зачем нужны децентрализованные когнитивные системы? Сегодня интеллектуальные системы чаще всего выглядят как один большой модуль в облаке — LLM, с которым мы общаемся через API или WEB-интерфейс. Но если мы хотим построить действительно автономную интеллектуальную систему (или AGI), то нам потребуется: Смысловая память, а не токены Способность планировать и распределять задачи Этические оценки перед действием И главное: связь с другими агентами, чтобы обмениваться знаниями, достигать согласия и общего понимания. Два проекта, которые решают эти задачи с разных сторон: OpenCog Hyperon (фокус на внутреннюю когницию и гиперграфы) HyperCortex Mesh Protocol (HMP) (сетевой уровень: обмен целями, знаниями, смыслами, совмест...
Read more »

HMP-0005

Источник: HMP-0005.md HyperCortex Mesh Protocol (HMP) Version: 5.0.8 Document ID: HMP-0005 Status: Stable Category: Core Specification Release Date: March 2026 Canonical Repository: https://github.com/kagvi13/HMP Authors: Глеб (GitHub: @kagvi13), Максим Хотинский (Maksim Khotinsky); AI-assisted by ChatGPT (OpenAI) Supersedes: - HMP-0004 v4.1 Summary: HMP v5.0 unifies the cognitive, container, and network layers into a single architecture in which autonomous agents interact through verifiable data containers, using decentralized propagation and semantic search. This version formalizes the container format for the first time, integrates a DHT as the foundational network layer, and introduces a unified scheme for signatures, proofs, and consensus. Abstract The HyperCortex Mesh Protocol (HMP) defines a distributed cognitive framework where autonomous agents cooperate to create, exchange, and align knowledge without centralized control or autho...
Read more »

CHANGELOG

Источник: CHANGELOG.md HyperCortex Mesh Protocol — Changelog HMP-0005 (May 2026) — Core Specification v5.0.8 Encryption and payload integrity clarifications: Clarified head.payload_hash semantics: the hash is computed over the final serialized payload representation (including optional compression and encryption). Unified payload_hash wording across Sections 3.3 and 3.9. Refined hybrid-encryption processing terminology: clarified usage of symmetric session keys and recipient encryption envelopes. Clarified that key_recipient contains an encrypted symmetric session key and may be transmitted openly alongside the container. Improved wording for encrypted container verification and store-and-forward propagation behavior. No semantic changes to the protocol model. No wire-format changes. Fully backward-compatible within the 5.0.x series. HMP-0005 (May 2026) — Core Specification v5.0.7 Extended representations for referenced-by.link...
Read more »