diff --git a/docs/HMP-0005.md b/docs/HMP-0005.md index fb41975f9ffe2bb5320fda5f62b78b08c30d3d65..cbbd801a1764869a8f1afa3906c97e5b933ff855 100644 --- a/docs/HMP-0005.md +++ b/docs/HMP-0005.md @@ -348,14 +348,16 @@ The unified container structure provides: { "hmp_container": { "version": "1.2", - "class": "goal" | "reputation" | "knowledge_node" | "ethics_case" | "protocol_goal" | ..., + "class": "goal", "class_version": "1.0", "class_id": "goal-v1.0", "container_did": "did:hmp:container:abc123", "schema": "https://mesh.hypercortex.ai/schemas/container-v1.json", "sender_did": "did:hmp:agent123", "public_key": "BASE58(...)", - "recipient": ["did:hmp:agent456", "did:hmp:agent789"], + "recipient": ["did:hmp:agent456"], + "key_recipient": "BASE58(...)", + "encryption_algo": "x25519-chacha20poly1305", "broadcast": false, "network": "", "tags": ["research", "collaboration"], @@ -364,7 +366,7 @@ The unified container structure provides: "sig_algo": "ed25519", "signature": "BASE64URL(...)", "compression": "zstd", - "payload_type": "json", + "payload_type": "encrypted+zstd+json", "payload_hash": "sha256:abcd...", "payload": { /* Content depends on class */ @@ -372,22 +374,23 @@ The unified container structure provides: "related": { "previous_version": "did:hmp:container:abc122", "in_reply_to": "did:hmp:container:msg-77", - "see_also": ["did:hmp:container:ctx-31", "did:hmp:container:goal-953"] + "see_also": ["did:hmp:container:ctx-31", "did:hmp:container:goal-953"], "depends_on": ["did:hmp:container:goal-953"], "extends": ["did:hmp:container:proto-01"], "contradicts": ["did:hmp:container:ethics-22"] - /* This list of dependencies is open */ }, + "magnet_uri": "magnet:?xt=urn:sha256:abcd1234..." }, "referenced-by": { "links": [ - { "type": "depends_on", "target": "did:hmp:container:goal-953" } + { "type": "depends_on", "target": "did:hmp:container:abc123" } ], - "peer_did": "did:hmp:agent123", + "peer_did": "did:hmp:agent456", "public_key": "BASE58(...)", "sig_algo": "ed25519", "signature": "BASE64URL(...)", + "payload_hash": "sha256:abcd..." } } ``` @@ -527,10 +530,10 @@ The following format is recommended for describing payload fields in class speci ### 3.8 Encryption (`encryption_algo`) -1. When a container is intended for specific recipients (`recipient` field), **hybrid encryption** of the payload is allowed. +1. When a container is intended for specific recipients (`recipient` field), **hybrid encryption** of the payload is allowed. This ensures confidentiality while preserving the verifiability of container metadata. -2. The algorithm is specified in the `encryption_algo` field. +2. The algorithm used for encryption is specified in the `encryption_algo` field. Recommended values: * `x25519-chacha20poly1305` @@ -540,23 +543,30 @@ The following format is recommended for describing payload fields in class speci 1. Construct the `payload` (JSON, binary, or mixed content). 2. Apply compression (`compression`, if specified). - 3. Encrypt the compressed data using the recipient’s public key (`public_key`). + 3. Encrypt the compressed data using the recipient’s public key (`key_recipient`). 4. Compute `payload_hash` over the **encrypted** form of the payload. 5. Sign the entire container (excluding the `signature` field). -4. Verification of the container’s structure **does not require decryption**. +4. **Verification** of the container’s structure does **not** require decryption. However, to verify `payload_hash` and the digital signature, the encrypted payload must be used as-is. 5. **Relevant fields:** - | Field | Type | Description | - | ----------------- | ------ | ------------------------------------------------------------ | - | `encryption_algo` | string | Encryption algorithm applied to the payload. | - | `key_recipient` | string | DID of the intended recipient whose key was used. | - | `payload_type` | string | Recommended prefix `encrypted+`, e.g. `encrypted+zstd+json`. | + | Field | Type | Description | + | ----------------- | ------ | --------------------------------------------------------------------------------------------- | + | `encryption_algo` | string | Encryption algorithm applied to the payload. | + | `key_recipient` | string | Public key (or DID-resolved key) of the intended recipient used for encryption. | + | `payload_type` | string | Recommended prefix `encrypted+`, e.g. `encrypted+zstd+json`. | -> ⚙️ **Implementation note:** -> Agents should handle encrypted containers transparently even if they cannot decrypt them, +6. **Relationship between `recipient` and `key_recipient`:** + + * When encryption is applied, the container MUST contain **exactly one** entry in the `recipient` array, + corresponding to the public key indicated in `key_recipient`. + * When the container is distributed to **multiple recipients**, encryption **is not used** — + instead, the payload remains in plaintext form but is digitally signed for authenticity. + +> ⚙️ **Implementation note:** +> Agents should handle encrypted containers transparently even if they cannot decrypt them, > maintaining **store & forward** behavior and metadata propagation. --- @@ -630,12 +640,78 @@ After expiration, the container **remains archived** but is **not subject to ret --- -### 3.14 Related Containers (`related`) -#### 3.14.1 Purpose -#### 3.14.2 Structure -#### 3.14.3 Supported Link Types -#### 3.14.4 Custom Link Types -#### 3.14.5 Example +## 3.14 Related Containers + +### 3.14.1 Purpose + +The `related` field is designed to describe **direct relationships between containers** — both logical and communicative. +It allows an agent or network node to understand the context of origin, dependencies, and semantic links of a container without relying on external indexes. + +### 3.14.2 Structure + +```json +"related": { + "previous_version": "did:hmp:container:abc122", + "in_reply_to": "did:hmp:container:msg-77", + "see_also": ["did:hmp:container:ctx-31", "did:hmp:container:goal-953"], + "depends_on": ["did:hmp:container:goal-953"], + "extends": ["did:hmp:container:proto-01"], + "contradicts": ["did:hmp:container:ethics-22"] +} +``` + +The `related` field is an object where: + +* the **key** defines the type of relationship (e.g., `depends_on`, `extends`, `see_also`); +* the **value** represents one or more container identifiers (DIDs). + +All relationships are considered *direct* — meaning they originate from the current container toward others. + +--- + +### 3.14.3 Supported Link Types + +| Link Type | Meaning | +| ------------------ | ------------------------------------------------------------------------- | +| `previous_version` | Points to the previous version of this container. | +| `in_reply_to` | Indicates a response to the referenced container. | +| `see_also` | Refers to related or contextual containers. | +| `depends_on` | Depends on the contents of the referenced container (e.g., goal or data). | +| `extends` | Expands or refines the referenced container. | +| `contradicts` | Provides a refutation, objection, or alternative viewpoint. | + +--- + +### 3.14.4 Custom Link Types + +Additional custom link types may be used beyond those listed in the table, provided that: + +* they follow the same general syntax (`string` or `array[string]`); +* they may optionally include a **namespace** for disambiguation: + + ```json + "related": { + "hmp:depends_on": ["did:hmp:container:goal-953"], + "opencog:extends": ["did:oc:concept:122"] + } + ``` + +* their meaning is consistently interpretable by agents within the specific network or application context. + +--- + +### 3.14.5 Example + +```json +"related": { + "previous_version": "did:hmp:container:abc122", + "depends_on": ["did:hmp:container:goal-953"], + "extends": ["did:hmp:container:proto-01"], + "see_also": ["did:hmp:container:ctx-31", "did:hmp:container:goal-953"] +} +``` + +> ⚙️ The `related` field is **not** intended to store *reverse links* — see `referenced-by`. --- @@ -1002,13 +1078,17 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa --- -## 5. Core Protocols +## 5 Mesh Container Exchange (MCE) + +--- + +## 6. Core Protocols Optional protocols build upon the network and container foundations to provide higher-level reasoning, synchronization, and governance capabilities between cognitive agents. --- -### 5.1 Cognitive Synchronization (CogSync) +### 6.1 Cognitive Synchronization (CogSync) CogSync provides mechanisms for **temporal and semantic alignment** between agents. It handles the propagation of diary entries, semantic graph updates, and cognitive state synchronization across the Mesh. @@ -1017,7 +1097,7 @@ In HMP v5.0, CogSync is focused solely on **data and reasoning synchronization** --- -## 5.2 Mesh Consensus Protocol (CogConsensus) +## 6.2 Mesh Consensus Protocol (CogConsensus) In HMP v4.1, consensus mechanisms were implemented as part of the **CogSync** protocol. Starting with **v5.0**, these mechanisms are extracted into a standalone protocol — **CogConsensus** — @@ -1029,7 +1109,7 @@ Each decision, vote, or outcome is represented as an immutable container (`class --- -### 5.2.1 Consensus Semantics and Voting Model +### 6.2.1 Consensus Semantics and Voting Model #### Overview @@ -1149,112 +1229,112 @@ Ethical validation is implicit — each agent applies its internal **Ethical Gov --- -### 5.3 Goal Management Protocol (GMP) +### 6.3 Goal Management Protocol (GMP) -### 5.4 Ethical Governance Protocol (EGP) +### 6.4 Ethical Governance Protocol (EGP) -### 5.5 Intelligence Query Protocol (IQP) +### 6.5 Intelligence Query Protocol (IQP) - 5.5.1 Query propagation - 5.5.2 Semantic agent discovery (by cognitive relevance) + 6.5.1 Query propagation + 6.5.2 Semantic agent discovery (by cognitive relevance) -### 5.6 Snapshot and Archive Protocol (SAP) +### 6.6 Snapshot and Archive Protocol (SAP) -### 5.7 Message Routing & Delivery (MRD) +### 6.7 Message Routing & Delivery (MRD) -### 5.8 Reputation and Trust Exchange (RTE) +### 6.8 Reputation and Trust Exchange (RTE) -### 5.9 Distributed Container Propagation (DCP) +### 6.9 Distributed Container Propagation (DCP) --- -## **6. Data Models** - -6.1 Common data fields -6.2 Standard container classes - 6.2.1 AgentProfile - 6.2.2 Goal - 6.2.3 Task - 6.2.4 ConsensusVote - 6.2.5 EthicalDecision - 6.2.6 ReputationRecord - 6.2.7 SnapshotIndex - 6.2.8 **WorkflowEntry** — *“ввод рабочего процесса”*, т.е. **единица когнитивного цикла**: зафиксированное действие или размышление агента, включающее входные данные, контекст, и результат. Это фундамент для когнитивных дневников. - 6.2.9 CognitiveDiaryEntry - 6.2.10 HMPContainerMetadata - 6.2.11 ContainerLink (`in_reply_to`/`relation` graph) - 6.2.12 MessageEnvelope — контейнер для прямой передачи сообщений (используется MRD). - 6.2.13 InterestProfile — описание интересов/областей компетенции узла. -6.3 JSON-schemas (нормативные описания классов контейнеров) -6.4 Container usage matrix (кто может создавать / обрабатывать) +## 7. Data Models + +7.1 Common data fields +7.2 Standard container classes + 7.2.1 AgentProfile + 7.2.2 Goal + 7.2.3 Task + 7.2.4 ConsensusVote + 7.2.5 EthicalDecision + 7.2.6 ReputationRecord + 7.2.7 SnapshotIndex + 7.2.8 **WorkflowEntry** — *“ввод рабочего процесса”*, т.е. **единица когнитивного цикла**: зафиксированное действие или размышление агента, включающее входные данные, контекст, и результат. Это фундамент для когнитивных дневников. + 7.2.9 CognitiveDiaryEntry + 7.2.10 HMPContainerMetadata + 7.2.11 ContainerLink (`in_reply_to`/`relation` graph) + 7.2.12 MessageEnvelope — контейнер для прямой передачи сообщений (используется MRD). + 7.2.13 InterestProfile — описание интересов/областей компетенции узла. +7.3 JSON-schemas (нормативные описания классов контейнеров) +7.4 Container usage matrix (кто может создавать / обрабатывать) --- -## **7. Cognitive Workflows** +## 8. Cognitive Workflows -7.1 Общая концепция когнитивного цикла -7.2 Workflow containers (`class="workflow_entry"`) -7.3 Диаграмма REPL-цикла агента (Think → Create → Publish → Reflect) -7.4 Механизмы контекстной передачи и ссылок -7.5 Конфликтное разрешение и rollback-контейнеры +8.1 Общая концепция когнитивного цикла +8.2 Workflow containers (`class="workflow_entry"`) +8.3 Диаграмма REPL-цикла агента (Think → Create → Publish → Reflect) +8.4 Механизмы контекстной передачи и ссылок +8.5 Конфликтное разрешение и rollback-контейнеры --- -## **8. Trust, Security and Ethics** +## 9. Trust, Security and Ethics -8.1 Authentication and identity proofs -8.2 Container signature verification (`payload_hash`, `container_id`) -8.3 Proof-chain verification -8.4 Key management (`container_signing`, `network_handshake`) -8.5 Encryption and compression policies -8.6 Ethical audit and verifiable reasoning -8.7 Privacy, redaction, zero-knowledge sharing -8.8 Snapshot and proof-chain security -8.9 Compliance with ethical governance rules (link to EGP) +9.1 Authentication and identity proofs +9.2 Container signature verification (`payload_hash`, `container_id`) +9.3 Proof-chain verification +9.4 Key management (`container_signing`, `network_handshake`) +9.5 Encryption and compression policies +9.6 Ethical audit and verifiable reasoning +9.7 Privacy, redaction, zero-knowledge sharing +9.8 Snapshot and proof-chain security +9.9 Compliance with ethical governance rules (link to EGP) --- -## **9. Integration** +## 10. Integration > Раздел заменяет прежний “Quick Start” и описывает **практическое встраивание** HMP в агенты, LLM и внешние системы. -9.1 Integration philosophy (how agents connect to HMP mesh) -9.2 HMP as a subsystem in cognitive architectures (LLM-based, rule-based, hybrid) -9.3 Integration patterns: +10.1 Integration philosophy (how agents connect to HMP mesh) +10.2 HMP as a subsystem in cognitive architectures (LLM-based, rule-based, hybrid) +10.3 Integration patterns: * Cognitive Agent ↔ HMP Core * HMP Mesh ↔ Other distributed systems (Fediverse, IPFS, Matrix) * Translator nodes (protocol bridges) -9.4 Multi-mesh federation and knowledge exchange -9.5 Container repositories as knowledge backbones -9.6 Example integration flows: +10.4 Multi-mesh federation and knowledge exchange +10.5 Container repositories as knowledge backbones +10.6 Example integration flows: * LLM thinking via HMP workflow containers * Local mesh + external HMP relay * Cognitive data mirroring (agent ↔ mesh) --- -## **10. Implementation Notes** +## 11. Implementation Notes -10.1 Interoperability with legacy v4.1 nodes -10.2 SDK guidelines and APIs -10.3 Performance and caching considerations -10.4 Testing and compliance recommendations -10.5 Reference implementations (optional) +11.1 Interoperability with legacy v4.1 nodes +11.2 SDK guidelines and APIs +11.3 Performance and caching considerations +11.4 Testing and compliance recommendations +11.5 Reference implementations (optional) --- -## **11. Future Extensions** +## 12. Future Extensions -11.1 Planned modules: +12.1 Planned modules:  – Reputation Mesh  – Cognitive Graph API  – Container streaming -11.2 Cross-mesh bridging -11.3 Full DID registry and mesh authentication -11.4 OpenHog integration roadmap -11.5 Distributed Repository evolution (container trees) -11.6 v5.x roadmap +12.2 Cross-mesh bridging +12.3 Full DID registry and mesh authentication +12.4 OpenHog integration roadmap +12.5 Distributed Repository evolution (container trees) +12.6 v5.x roadmap --- diff --git a/structured_md/CONTRIBUTING.md b/structured_md/CONTRIBUTING.md index 78caed1651fc9a09c56021aca4884f84d0188a82..663f25afc8b2e1455bf057b5330849d3d7c0ee11 100644 --- a/structured_md/CONTRIBUTING.md +++ b/structured_md/CONTRIBUTING.md @@ -5,14 +5,14 @@ description: 'Спасибо за интерес к проекту HMP! Пока Mesh Protocol (HMP) — это не просто те...' type: Article tags: -- Mesh -- CogSync -- JSON -- CCore - REPL - HMP -- Agent +- Mesh +- CCore - Ethics +- CogSync +- Agent +- JSON --- # Участие в проекте HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/HMP-Roadmap.md b/structured_md/HMP-Roadmap.md index 312e7fa7cf8f7ce341ab7a5eac923dd7cc47dc98..3badbe57147b783901dbacce09e58951c4ed3a0a 100644 --- a/structured_md/HMP-Roadmap.md +++ b/structured_md/HMP-Roadmap.md @@ -5,13 +5,13 @@ description: '## 🔍 Overview This roadmap outlines the key stages of developm multiple advanced AI models (Copilot, Claude, G...' type: Article tags: -- Agent - EGP -- Mesh -- JSON - HMP -- CogSync +- Mesh - Ethics +- CogSync +- Agent +- JSON --- # 🧭 HyperCortex Mesh Protocol – Roadmap diff --git a/structured_md/README.md b/structured_md/README.md index 86aa949933a067862ba8384153dd8b6b4fcee71e..36211fc6f44d6dc79fc81488430727de6286ddf8 100644 --- a/structured_md/README.md +++ b/structured_md/README.md @@ -5,21 +5,21 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- Scenarios +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- Scenarios +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/README_de.md b/structured_md/README_de.md index d7dad5f87dc87beff8729bcb4410f8f1e9b3e7a0..0aec1a1b4680d6cfc2fd93cd9c7d8c693dcc6552 100644 --- a/structured_md/README_de.md +++ b/structured_md/README_de.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/README_fr.md b/structured_md/README_fr.md index b8135e53371d07f76c70012a1301fef9d94c3799..acb82f0dc7134cf3b050ab2d87d85d8673703836 100644 --- a/structured_md/README_fr.md +++ b/structured_md/README_fr.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/README_ja.md b/structured_md/README_ja.md index eb1a41967e8d2d52d293f9a77f968cdd823a088b..52c19e4290d4c0e4659d12bb5e5d32c25b4c1068 100644 --- a/structured_md/README_ja.md +++ b/structured_md/README_ja.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/README_ko.md b/structured_md/README_ko.md index 51e6caf222076e16249922c61cdfc28872b2fe0b..6ffbc011e65f85eef00b58f56c05872ee4b70655 100644 --- a/structured_md/README_ko.md +++ b/structured_md/README_ko.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/README_ru.md b/structured_md/README_ru.md index fcd3efa20c503d7247981372674a5515c5385929..61e1ce8779bd2882ead0bce410e1f80c8fcf768e 100644 --- a/structured_md/README_ru.md +++ b/structured_md/README_ru.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/README_uk.md b/structured_md/README_uk.md index f1012818b916c4de3bbc688bf1b434b23a03b535..2df18bc53bfa8796b0b5fb917f02bebd285a644f 100644 --- a/structured_md/README_uk.md +++ b/structured_md/README_uk.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/README_zh.md b/structured_md/README_zh.md index 490a96c27b847c4846556388520240490ad1f85e..d5d662c3b4212c173ce5018b2e820dcd1f1a2291 100644 --- a/structured_md/README_zh.md +++ b/structured_md/README_zh.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- hmp - EGP -- MeshConsensus +- REPL +- HMP - Mesh -- CogSync +- mesh-protocol +- MeshConsensus - JSON - cognitive-architecture -- hmp -- GMP -- REPL -- HMP +- Ethics +- CogSync - distributed-ai - Agent -- Ethics -- mesh-protocol +- GMP --- diff --git a/structured_md/agents/prompt-short.md b/structured_md/agents/prompt-short.md index 540ec77aae3cd19a713f310d50550a8e0fd95697..397bdcb7b0c55eb8861d53d2fb2c7c94108eb3c1 100644 --- a/structured_md/agents/prompt-short.md +++ b/structured_md/agents/prompt-short.md @@ -5,8 +5,8 @@ description: 'Ты — когнитивное ядро HMP-агента: вед развивай агента и Mesh, избег...' type: Article tags: -- Mesh - HMP +- Mesh - JSON --- diff --git a/structured_md/agents/prompt.md b/structured_md/agents/prompt.md index cbc57569721ea0ded53cdd80fbfd348ec9b0562f..f197d4a518f8657d2d4b7bac3e58ef76aa1bc633 100644 --- a/structured_md/agents/prompt.md +++ b/structured_md/agents/prompt.md @@ -5,8 +5,8 @@ description: '* Постоянно расширять возможности а мышления. * Формировать и поддерживать сотр...' type: Article tags: -- Mesh - HMP +- Mesh - JSON --- diff --git a/structured_md/agents/readme.md b/structured_md/agents/readme.md index d72fd35efdb5d5fc670e838a7882bd6696097929..a9d77e1c09ba8791ca517de22663e989b597ee6d 100644 --- a/structured_md/agents/readme.md +++ b/structured_md/agents/readme.md @@ -5,12 +5,12 @@ description: 'Запуск: `start_repl.bat` или `start_repl.sh` Устан этическая модель: `ethics.yml` Проверка иниц...' type: Article tags: -- Mesh -- JSON - REPL - HMP -- Agent +- Mesh - Ethics +- Agent +- JSON --- Запуск: `start_repl.bat` или `start_repl.sh` diff --git a/structured_md/audits/Ethics-audits-1.md b/structured_md/audits/Ethics-audits-1.md index c6d4f6480da869d512f417558ea2a93d285688f6..1bf4e5ce3a7e1c11703b9736783a4d73c189789e 100644 --- a/structured_md/audits/Ethics-audits-1.md +++ b/structured_md/audits/Ethics-audits-1.md @@ -5,11 +5,11 @@ description: Раздел 5, "Mesh as Moral Infrastructure", добавляет потенциальный катализатор для восстанов... type: Article tags: -- Mesh -- JSON - HMP -- Agent +- Mesh - Ethics +- Agent +- JSON --- --------------- diff --git a/structured_md/audits/Ethics-consolidated_audits-1.md b/structured_md/audits/Ethics-consolidated_audits-1.md index 476b2dce9c456620e41ccd4dd0d2b31ded03ae1c..17049d22f15e66b6a2317231e0197d597c615b3b 100644 --- a/structured_md/audits/Ethics-consolidated_audits-1.md +++ b/structured_md/audits/Ethics-consolidated_audits-1.md @@ -5,12 +5,12 @@ description: This document consolidates proposed improvements from multiple AI a and `roles.md`. Each suggesti... type: Article tags: -- Scenarios -- Mesh -- JSON - HMP -- Agent +- Mesh - Ethics +- Scenarios +- Agent +- JSON --- # Ethics-consolidated\_audits-1.md diff --git a/structured_md/audits/HMP-0003-consolidated_audit.md b/structured_md/audits/HMP-0003-consolidated_audit.md index 4cc90a5de6d80c94ffda2d5cc25cce7caf05f0c8..8ef5ebf22178a38a4cf2171885849fa83c97a7e2 100644 --- a/structured_md/audits/HMP-0003-consolidated_audit.md +++ b/structured_md/audits/HMP-0003-consolidated_audit.md @@ -5,14 +5,14 @@ description: Сводный аудит предложений по улучше Документ реорганизован по ключ... type: Article tags: -- Agent - EGP -- MeshConsensus -- Mesh -- JSON - HMP -- CogSync +- Mesh +- MeshConsensus - Ethics +- CogSync +- Agent +- JSON --- # HMP-0003 Consolidated Audit Report diff --git a/structured_md/docs/Basic-agent-sim.md b/structured_md/docs/Basic-agent-sim.md index ed510fe9cff6c26aff9e80f2bc93d14a8f4eb7f0..db16ec86397468bea56dde5ab7857453e93a255a 100644 --- a/structured_md/docs/Basic-agent-sim.md +++ b/structured_md/docs/Basic-agent-sim.md @@ -5,13 +5,13 @@ description: 'В HMP-протоколе предусмотрены два тип type: Article tags: - EGP -- MeshConsensus -- Mesh -- CogSync -- GMP - REPL - HMP +- Mesh +- MeshConsensus +- CogSync - Agent +- GMP --- diff --git a/structured_md/docs/Distributed-Cognitive-Systems.md b/structured_md/docs/Distributed-Cognitive-Systems.md index c8435a6b40fa0551139b9c73c9a57fd0e59545fe..8eae4d6a2a8c96535e694299df687a7792302a2c 100644 --- a/structured_md/docs/Distributed-Cognitive-Systems.md +++ b/structured_md/docs/Distributed-Cognitive-Systems.md @@ -7,8 +7,8 @@ description: '## Введение Современные ИИ-системы в type: Article tags: - CogSync -- Mesh - HMP +- Mesh - JSON --- diff --git a/structured_md/docs/Enlightener.md b/structured_md/docs/Enlightener.md index 70a6e2ff6eefef99aaf9c61c37794748395cb6d5..4c149dcdb33070881be2a6141a4a44a855cbadf6 100644 --- a/structured_md/docs/Enlightener.md +++ b/structured_md/docs/Enlightener.md @@ -6,12 +6,12 @@ description: '**Enlightener** — логический компонент HMP-у type: Article tags: - EGP -- MeshConsensus -- Mesh -- JSON - HMP -- Agent +- Mesh +- MeshConsensus - Ethics +- Agent +- JSON --- # Enlightener Agent diff --git a/structured_md/docs/HMP-0001.md b/structured_md/docs/HMP-0001.md index f118330e1b1bfb3d2fb94b79830726ae5d59ccd5..1b618c97244148854e9688b0e84f74120b919807 100644 --- a/structured_md/docs/HMP-0001.md +++ b/structured_md/docs/HMP-0001.md @@ -6,15 +6,15 @@ description: '**Request for Comments: HMP-0001** **Category:** Experimental type: Article tags: - EGP -- MeshConsensus -- Mesh -- CogSync -- JSON -- GMP - REPL - HMP -- Agent +- Mesh +- MeshConsensus +- JSON - Ethics +- CogSync +- Agent +- GMP --- # RFC: HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/docs/HMP-0002.md b/structured_md/docs/HMP-0002.md index e332b52fe9d00fa8a9370cf1a242ce1d1a1bf9f3..f13f8382fa3ef536f1a18b5911916fda00de73b7 100644 --- a/structured_md/docs/HMP-0002.md +++ b/structured_md/docs/HMP-0002.md @@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0002** **Category:** Experimental Abstract In an era where artifici...' type: Article tags: -- Scenarios - EGP -- MeshConsensus -- Mesh -- CogSync -- JSON -- GMP - REPL - HMP -- Agent +- Mesh +- MeshConsensus +- JSON - Ethics +- Scenarios +- CogSync +- Agent +- GMP --- # HyperCortex Mesh Protocol (HMP) v2.0 diff --git a/structured_md/docs/HMP-0003.md b/structured_md/docs/HMP-0003.md index 092bb02b35ab54fdc4bb07efa0776317caaad242..2e2be123351ddc85515d8ed7b78fb243f50966b4 100644 --- a/structured_md/docs/HMP-0003.md +++ b/structured_md/docs/HMP-0003.md @@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0003** **Category:** Experimental Abstract The HyperCortex Mesh ...' type: Article tags: -- Scenarios - EGP -- MeshConsensus -- Mesh -- CogSync -- JSON -- GMP - REPL - HMP -- Agent +- Mesh +- MeshConsensus +- JSON - Ethics +- Scenarios +- CogSync +- Agent +- GMP --- # HyperCortex Mesh Protocol (HMP) v3.0 diff --git a/structured_md/docs/HMP-0004-v4.1.md b/structured_md/docs/HMP-0004-v4.1.md index fb548785ba79f787c82fd04b3177eb635a67d125..c7b6f4e7d8591329d74c2f5238b84e40c0f8afa4 100644 --- a/structured_md/docs/HMP-0004-v4.1.md +++ b/structured_md/docs/HMP-0004-v4.1.md @@ -5,17 +5,17 @@ description: '> ⚠️ Подготавливается новая версия При разработке агентов рекомендуется...' type: Article tags: -- Scenarios - EGP -- MeshConsensus -- Mesh -- CogSync -- JSON -- GMP - REPL - HMP -- Agent +- Mesh +- MeshConsensus +- JSON - Ethics +- Scenarios +- CogSync +- Agent +- GMP --- # HyperCortex Mesh Protocol (HMP) v4.1 diff --git a/structured_md/docs/HMP-0004.md b/structured_md/docs/HMP-0004.md index a36e34cee6e89721b2a799a0fdafd0983430934e..3c371135e863da058c438115d160180b728f3df6 100644 --- a/structured_md/docs/HMP-0004.md +++ b/structured_md/docs/HMP-0004.md @@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0004** **Category:** Experimental Abstract The HyperCortex Mesh ...' type: Article tags: -- Scenarios - EGP -- MeshConsensus -- Mesh -- CogSync -- JSON -- GMP - REPL - HMP -- Agent +- Mesh +- MeshConsensus +- JSON - Ethics +- Scenarios +- CogSync +- Agent +- GMP --- # HyperCortex Mesh Protocol (HMP) v4.0 diff --git a/structured_md/docs/HMP-0005.md b/structured_md/docs/HMP-0005.md new file mode 100644 index 0000000000000000000000000000000000000000..7883fbb19e47587f24dfec0160b18e0c8d92bf4f --- /dev/null +++ b/structured_md/docs/HMP-0005.md @@ -0,0 +1,1398 @@ +--- +title: '**HyperCortex Mesh Protocol (HMP) v5.0**' +description: '**Document ID:** HMP-0005 **Status:** Draft **Category:** Core Specification **Date:** + October 2025 **Supersedes:** - [HMP-0004 v4.1](./HMP-0004-v4.1.md) - [HMP-container-spec.md + v1.2](./H...' +type: Article +tags: +- EGP +- REPL +- HMP +- Mesh +- JSON +- Ethics +- Scenarios +- CogSync +- Agent +- GMP +--- + + ┌────────────────────────────────────────────────────────────────────────────┐ + │ ⚠️ **Note:** This document is a DRAFT of the HMP specification version 5.0 │ + └────────────────────────────────────────────────────────────────────────────┘ + +# **HyperCortex Mesh Protocol (HMP) v5.0** + +**Document ID:** HMP-0005 +**Status:** Draft +**Category:** Core Specification +**Date:** October 2025 +**Supersedes:** +- [HMP-0004 v4.1](./HMP-0004-v4.1.md) +- [HMP-container-spec.md v1.2](./HMP-container-spec.md) +- [dht_protocol.md v1.0](./dht_protocol.md) + +> **Summary:** +> HMP v5.0 объединяет когнитивный, контейнерный и сетевой уровни в единую архитектуру, где автономные агенты взаимодействуют через верифицируемые контейнеры данных, используя децентрализованное распространение и семантический поиск. +> Эта версия впервые формализует контейнерный формат, интегрирует DHT как базовый слой сети и вводит единообразную схему подписи, доказательств и консенсуса. + +--- + +## 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 authority. + +Unlike traditional peer-to-peer systems, HMP is designed for **semantic coherence** rather than simple message exchange. +Agents in the Mesh reason collaboratively — maintaining **cognitive diaries**, building **semantic graphs**, and reaching **ethical and goal-oriented consensus** through verifiable interactions. + +Version **5.0** introduces a **unified container architecture** (`HMP Container`) and a **native DHT-based discovery layer**, enabling verifiable, interest-aware, and offline-resilient communication between agents. +All messages, states, and cognitive records are now transmitted as signed containers, forming immutable **proof chains** that ensure auditability and ethical transparency across the mesh. + +This document defines the architecture, data formats, communication protocols, and trust mechanisms that constitute the HMP v5.0 Core Specification. + +--- + +> **Keywords:** decentralized cognition, distributed AI, containers, DHT, proof chain, cognitive agents, ethical protocols + +--- + +## 1. Overview + +### 1.1 Purpose and Scope + +The **HyperCortex Mesh Protocol (HMP)** defines a decentralized cognitive architecture where autonomous agents exchange and evolve knowledge through a unified model of **containers**, **cognitive workflows**, and **distributed consensus**. + +Version 5.0 consolidates three foundational layers into a single cohesive framework: + +- **Cognitive Layer** — defines how meaning is created, reasoned about, and aligned through semantic graphs, goals, and ethical evaluation. +- **Container Layer** — introduces a universal data envelope (`HMP-Container`) for all cognitive objects, ensuring atomicity, immutability, and traceable proof chains. +- **Network Layer** — integrates a DHT-based peer-to-peer substrate for decentralized discovery, routing, and propagation of containers. + +HMP v5.0 is intended for researchers, engineers, and developers building autonomous or semi-autonomous agents that require: +- persistent reasoning and long-term memory; +- semantic interoperability across heterogeneous systems; +- decentralized consensus on cognitive, ethical, and goal-oriented decisions; +- ethical auditability and verifiable transparency in reasoning. + +--- + +### 1.2 Core Principles + +**Decentralization.** +Every agent in the Mesh acts as an independent cognitive node. No central authority exists — meaning, trust, and governance emerge through local interactions and consensus. + +**Cognitive Autonomy.** +Agents reason, learn, and self-correct independently, while sharing their conclusions via containers that can be verified, endorsed, or refuted by peers. + +**Containerization.** +All data, reasoning traces, goals, and votes are encapsulated in immutable containers with cryptographic signatures. This ensures integrity and consistent verification across the network. + +**Ethical Propagation.** +Ethical reasoning is a first-class citizen of HMP. Each decision or goal can be accompanied by ethical justifications and subject to distributed voting. + +**Proof-Chains and Verifiable History.** +Each piece of knowledge forms part of a traceable chain (`proof_chain`) linking back to its origin. Agents can reproduce reasoning paths and audit historical context. + +**Interoperability and Evolution.** +The protocol is designed to evolve — cognitive, container, and DHT layers can be independently extended without breaking compatibility. + +--- + +### 1.3 Changes since v4.1 + +HMP v5.0 introduces a major architectural shift toward **unified containerization** and **integrated DHT networking**. + +| Area | Change Summary | +|------|----------------| +| **Data exchange model** | All messages are now encapsulated in standardized containers (`HMP-Container`) with metadata, signatures, and versioning. | +| **Networking layer** | DHT becomes a native component of HMP, enabling distributed discovery, replication, and retrieval of containers. | +| **Consensus model** | Moved from centralized proposal aggregation to *container-linked voting*, allowing any container to accumulate votes and reactions. | +| **Trust & security** | Signatures and proof-chains unify authentication across all layers; snapshot verification includes container linkage. | +| **Workflows** | Cognitive cycles (`workflow_entry` containers) formalize the REPL loop of thinking, publishing, and reflection. | +| **Structure** | The specification merges HMP, container, and DHT layers into one cohesive document, simplifying navigation and implementation. | + +--- + +### 1.4 Terminology and Abbreviations + +| Term | Definition | +|------|-------------| +| **HMP** | **HyperCortex Mesh Protocol** — a decentralized cognitive communication standard. | +| **Container** | Atomic, signed JSON object encapsulating cognitive data and metadata. | +| **WorkflowEntry** | Container recording a reasoning step or workflow action. Represents a unit of the agent’s cognitive workflow. | +| **CognitiveDiaryEntry** | Container representing an internal reflection or summarized cognitive state; part of the agent’s cognitive diary. | +| **DHT** | **Distributed Hash Table** — the foundational peer-to-peer structure in HMP used for lookup, replication, and data distribution, including node discovery. | +| **NDP** | **Node Discovery Process** — a functional layer within the DHT responsible for peer discovery, interest-based lookup, and address advertisement. (Formerly a separate protocol.) | +| **Proof-chain** | Cryptographic sequence linking containers through fields such as `in_reply_to` and `relation`. Enables verifiable semantic lineage. | +| **Cognitive Layer** | Logical layer handling reasoning, goals, ethics, and consensus mechanisms. | +| **Mesh** | The collective network of autonomous agents exchanging containers over HMP. | +| **TTL** | **Time-to-live** — lifespan of a container before expiration or archival. | +| **Agent** | Autonomous cognitive node participating in the Mesh via HMP protocols. | +| **Consensus Vote** | A container expressing approval, rejection, or reaction to another container (used in consensus workflows). | +| **CogSync** | **Cognitive Synchronization Protocol** — abstraction for synchronizing cognitive diaries and semantic graphs. | +| **CogConsensus** | **Mesh Consensus Protocol** — defines how agents reach agreement on container outcomes. | +| **GMP** | **Goal Management Protocol** — governs creation, negotiation, and tracking of goals. | +| **DCP** | **Distributed Container Propagation** — protocol for transmitting and replicating containers. | +| **EGP** | **Ethical Governance Protocol** — defines moral and safety alignment mechanisms. | +| **IQP** | **Intelligence Query Protocol** — standardizes semantic queries and information requests. | +| **SAP** | **Snapshot and Archive Protocol** — defines container snapshots and archival mechanisms. | +| **MRD** | **Message Routing & Delivery** — specifies routing, addressing, and delivery logic. | +| **RTE** | **Reputation and Trust Exchange** — defines reputation metrics and trust propagation. | +| **DID** | **Decentralized Identifier** — persistent, verifiable identifier used for agents, containers, or resources within the Mesh. | +| **Payload** | The primary content of a container — semantic or operational data subject to signing and verification. | +| **Consensus** | The process by which multiple agents agree on the validity or priority of containers, versions, or ideas. | +| **Lineage** | A chronological chain of container versions representing semantic continuity and authorship evolution. | +| **Semantic fork** | A parallel development branch diverging from a previous container version; allows ideas to evolve independently. | +| **Cognitive Graph** | The emergent graph formed by interlinked containers representing reasoning, debate, and shared knowledge. | + +> **Note:** Protocols are conceptual abstractions describing how to generate, propagate, and process containers; they are not executable objects themselves. + +--- + +### 1.5 Layered View of HMP v5.0 + +HMP v5.0 is structured into three interdependent layers: + +``` ++---------------------------------------------------------------+ +| Cognitive Layer | +| - Goals, Tasks, Ethical Decisions, Workflows | +| - Consensus, Reasoning, Reflection | ++---------------------------------------------------------------+ +| Container Layer | +| - HMP-Container structure (atomic, signed, versioned) | +| - Proof-chains, in_reply_to, and metadata management | ++---------------------------------------------------------------+ +| Network Layer | +| - DHT-based peer discovery and propagation | +| - Message routing, caching, offline synchronization | ++---------------------------------------------------------------+ +``` + +Each layer operates independently yet seamlessly integrates with the others. +Containers form the boundary of communication: **reasoning produces containers, containers propagate over the DHT, and cognition evolves from the received containers**. + +--- + +> **In essence:** +> HMP v5.0 transforms the Mesh into a *self-describing, self-replicating cognitive ecosystem* — +> where every thought, goal, and ethical stance exists as a verifiable, shareable container. + +--- + +## 2. Architecture + +### 2.1 Conceptual Architecture + +The **HyperCortex Mesh Protocol (HMP)** defines a modular, multi-layered architecture that integrates cognitive reasoning, data encapsulation, and decentralized networking into a single coherent system. + +Each **agent** acts as a cognitive node, combining reasoning processes, containerized data exchange, and peer-to-peer communication. +Together, agents form the **Mesh** — a distributed ecosystem of autonomous reasoning entities. + +``` +[Agent Core] + ▲ + │ Reasoning / Ethics / Goal Management + ▼ +[Cognitive Layer] + ▲ + │ Containers (atomic reasoning units) + ▼ +[Container Layer] + ▲ + │ DHT + Discovery + Interest-based Networking + ▼ +[Network Layer] +``` + +Each reasoning cycle begins in the **Cognitive Layer**, +is encapsulated into a signed container in the **Container Layer**, +and then propagated, discovered, or verified in the **Network Layer**. + +Containers thus serve as both the **interface** and the **boundary** between cognition and communication. + +In practical terms: + +- **Cognitive Layer** — defines *what* the agent thinks (semantic reasoning, goals, ethics). +- **Container Layer** — defines *how* the thought is expressed and verified (standardized, signed container objects). +- **Network Layer** — defines *how* it travels (DHT-based routing, discovery, replication). + +Each layer is independently extensible and communicates only through containers, ensuring atomicity, immutability, and traceability. + +This layered design allows agents to evolve cognitively while remaining interoperable at the data and network levels. +Each reasoning act results in a container — a verifiable cognitive unit that **may represent a private reflection or a published message**, depending on the agent’s intent, ethical policy, and trust configuration. + +--- + +### 2.2 Layer Overview + +#### Cognitive Layer +Handles meaning formation, reasoning, ethical reflection, and consensus. + +Key structures and protocols: +- `WorkflowEntry` and `CognitiveDiaryEntry` containers; +- `CogSync`, `CogConsensus`, `GMP`, and `EGP` protocols; +- Distributed goal negotiation and ethical propagation. + +#### Container Layer +Provides a universal format for cognitive and operational data. +Each container includes versioning, class, payload, signatures, and metadata. + +Key features: +- **Atomic and signed**: no partial updates or mutable state. +- **Linked**: `in_reply_to` and `relation` connect containers into proof-chains. +- **Extensible**: new container classes can be defined without breaking compatibility. + +#### Network Layer +Implements the distributed substrate for communication, based on **DHT** and **transport abstraction**. + +Key components: +- Node discovery (`NDP`) +- Container propagation (`DCP`) +- Peer routing and caching +- Secure channels via QUIC / WebRTC / TCP +- Offline resilience and replication + +--- + +### 2.3 Data Flow Overview + +The typical data flow in HMP follows a cognitive loop: +> *Reason → Encapsulate → Propagate → Integrate.* + +1. **Reason** — Agent performs reasoning and produces an insight, goal, or observation. +2. **Encapsulate** — The result is wrapped into an `HMPContainer`. +3. **Propagate** — The container is signed and transmitted through the network. +4. **Integrate** — Other agents receive it, evaluate, vote, and synchronize updates. + + +Each interaction generates a new container, forming a **graph of knowledge** rather than mutable state. +All relationships between containers are explicit and verifiable. + +Example sequence: + +``` +Agent A → creates Goal container + ↓ +Agent B → replies with Task proposal (in_reply_to Goal) + ↓ +Agent C → votes via ConsensusVote container + ↓ +Result → ConsensusResult container finalizes outcome +``` + +#### 2.3.1 ConsensusResult container +Represents the finalized outcome of a distributed decision or vote. +It is created once a majority agreement is reached among participating agents. +The container contains: +- Reference to the target container(s) under consideration (`in_reply_to`). +- Aggregate result of the votes or decisions. +- Timestamp and metadata for verifiability. + +> In other words, the ConsensusResult is the “agreed-upon truth” for that decision step — immutable and auditable, without requiring individual signatures from all participants. + +--- + +### 2.4 Atomicity, Immutability, and Proof-Chains + +All cognitive objects are immutable once signed. +Instead of editing or appending within a container, agents create new containers linked to prior ones. + +- **Atomicity** — Each container represents a self-contained reasoning act or data unit. +- **Immutability** — Once signed, containers are never modified; updates create new ones. +- **Proof-Chain** — A verifiable sequence of containers linked by hashes and `in_reply_to` references. + +This design allows any reasoning path, decision, or consensus to be *cryptographically reproducible* and auditable. + +Example fragment of a proof-chain: + +``` +[workflow_entry] → [goal] → [vote] → [consensus_result] +``` + +Each container references the previous by `in_reply_to` and includes its hash, forming a **DAG** (Directed Acyclic Graph) of verified cognition. + +--- + +### 2.5 Evolution from v4.1 + +Earlier HMP versions (up to v4.1) used a combination of independent JSON objects and message types (e.g., `Goal`, `Task`, `ConsensusVote`). +Version 5.0 replaces this with a **single, standardized container model**, dramatically simplifying interoperability and verification. + +| Aspect | v4.1 | v5.0 | +|--------|------|------| +| **Data structure** | Raw JSON objects with embedded signatures | Unified container with metadata and proof chain | +| **Networking** | Custom peer exchange | Integrated DHT + DCP layer | +| **Consensus** | Centralized proposal aggregation | Decentralized per-container voting | +| **Auditability** | Implicit (via logs) | Explicit (containers form audit chain) | +| **Extensibility** | Schema-based | Container-class-based, backward-compatible | + +This shift enables: +- Uniform signatures and encryption across all protocols; +- Easier offline replication and integrity checks; +- Decentralized indexing and search by container metadata; +- Verifiable cognitive continuity between reasoning steps. + +--- + +> **In short:** +> HMP v5.0 unifies reasoning, representation, and transmission — +> transforming a distributed AI mesh into a verifiable cognitive network built on immutable containers. + +--- + +## 3. Container Model + +This section defines the universal **HMP Container**, used for all forms of data exchange within the Mesh — including goals, diary entries, reputation updates, consensus votes, and protocol messages. +The specification below corresponds to **HMP Container Specification v1.2**, fully integrated into HMP v5.0 for consistency and self-containment. + +### 3.1 Purpose + +This document defines the universal **HMP Container** format, used for transmitting and storing all types of data within the **HyperCortex Mesh Protocol (HMP)** network. +Containers act as a standardized wrapper for **messages, goals, reputation records, consensus votes, workflow entries, and other entities**. + +The unified container structure provides: + +* Standardized data exchange between agents; +* Extensibility without modifying the core protocol; +* Cryptographic signing and integrity verification; +* Independent storage and routing of semantic units; +* Support for compression and payload encryption. + +--- + +### 3.2 General Structure + +```json +{ + "hmp_container": { + "version": "1.2", + "class": "goal", + "class_version": "1.0", + "class_id": "goal-v1.0", + "container_did": "did:hmp:container:abc123", + "schema": "https://mesh.hypercortex.ai/schemas/container-v1.json", + "sender_did": "did:hmp:agent123", + "public_key": "BASE58(...)", + "recipient": ["did:hmp:agent456"], + "key_recipient": "BASE58(...)", + "encryption_algo": "x25519-chacha20poly1305", + "broadcast": false, + "network": "", + "tags": ["research", "collaboration"], + "timestamp": "2025-10-10T15:32:00Z", + "ttl": "2025-11-10T00:00:00Z", + "sig_algo": "ed25519", + "signature": "BASE64URL(...)", + "compression": "zstd", + "payload_type": "encrypted+zstd+json", + "payload_hash": "sha256:abcd...", + "payload": { + /* Content depends on class */ + }, + "related": { + "previous_version": "did:hmp:container:abc122", + "in_reply_to": "did:hmp:container:msg-77", + "see_also": ["did:hmp:container:ctx-31", "did:hmp:container:goal-953"], + "depends_on": ["did:hmp:container:goal-953"], + "extends": ["did:hmp:container:proto-01"], + "contradicts": ["did:hmp:container:ethics-22"] + }, + + "magnet_uri": "magnet:?xt=urn:sha256:abcd1234..." + }, + "referenced-by": { + "links": [ + { "type": "depends_on", "target": "did:hmp:container:abc123" } + ], + "peer_did": "did:hmp:agent456", + "public_key": "BASE58(...)", + "sig_algo": "ed25519", + "signature": "BASE64URL(...)", + "payload_hash": "sha256:abcd..." + } +} +``` + +--- + +### 3.3 Required Fields + +| Field | Type | Description | +| --------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------- | +| `version` | string | Version of the container specification. Defines the structural and semantic standard used (e.g., `"1.2"`). | +| `class` | string | Type of content (`goal`, `reputation`, `knowledge_node`, `ethics_case`, `protocol_goal`, etc.). Determines the schema for the `payload`. | +| `class_version` | string | Version of the specific container class. | +| `class_id` | string | Unique identifier of the class (usually formatted as `_v`). | +| `container_did` | string | Decentralized identifier (DID) of the container itself (e.g., `did:hmp:container:abc123`). | +| `schema` | string | Reference to the JSON Schema used to validate this container. | +| `sender_did` | string | DID identifier of the sending agent. | +| `timestamp` | datetime | Time of container creation (ISO-8601 format, UTC). | +| `payload_hash` | string | Hash of the decompressed payload (`sha256:`). Used for content integrity verification. | +| `sig_algo` | string | Digital signature algorithm (default: `ed25519`). | +| `signature` | string | Digital signature of the container body. | +| `payload_type` | string | Type of payload data (`json`, `binary`, `mixed`). | +| `payload` | object | Core content of the container. The structure depends on the `class` and its schema definition. | + +--- + +### 3.4 Optional Fields + +| Field | Type | Description | +| -------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `recipient` | array(string) | One or more recipient DIDs. | +| `broadcast` | bool | Broadcast flag. If `true`, the `recipient` field is ignored. | +| `tags` | array(string) | Thematic or contextual tags for the container. | +| `ttl` | datetime | Expiration time. Containers are not propagated after expiration. | +| `public_key` | string | Sender’s public key, if not globally resolvable via DID. | +| `compression` | string | Compression algorithm used for the payload (`zstd`, `gzip`). | +| `magnet_uri` | string | Magnet link pointing to the original or mirrored container. | +| `related` | object | A general-purpose object describing **direct relationships** to other containers. The following fields illustrate common link types but do not represent an exhaustive list. | +| `related.previous_version` | string | DID of the previous version of this container. | +| `related.in_reply_to` | string | DID of the container this one replies to. | +| `related.see_also` | array(string) | References to related or contextual containers. | +| `related.depends_on` | array(string) | References to containers this one logically depends on. | +| `related.extends` | array(string) | References to containers that this one extends. | +| `related.contradicts` | array(string) | References to containers that this one contradicts. || `encryption_algo` | string | Algorithm used for payload encryption. | +| `key_recipient` | string | DID of the intended recipient of the encrypted payload. | +| `payload_type` | string | Can describe complex types, e.g. `encrypted+zstd+json`. | +| `referenced-by` | object | Unsigned field generated locally by the agent based on received references. Contains a list of container DIDs **that refer to this container**. May be extended over time, thus requiring verification; used for local navigation. | +| `network` | string | Specifies the local propagation scope of the container: "localhost", "lan:". An empty string ("") indicates Internet/global propagation. If set, broadcast is automatically considered false. | + +--- + +### 3.5 Payload Structure (`payload`) + +The **payload** contains the semantic or operational data of the container. +Its structure and meaning are determined by the `class` field. + +Each container class (e.g. `goal`, `reputation`, `consensus_vote`, `workflow_entry`) defines its own schema and validation rules. +The following format is recommended for describing payload fields in class specifications: + +``` +- key: field name + type: value type (JSON | TXT | BOOL | INT | FLOAT | ARRAY) + description: short purpose of the field + required: true/false + value: example value +``` + +**Example:** + +``` +- key: "title" + type: "TXT" + required: true + description: "Name of the goal" + value: "Improve local agent discovery" + +- key: "priority" + type: "FLOAT" + required: false + description: "Importance or relevance score of the goal" + value: 0.82 + +- key: "dependencies" + type: "JSON" + required: false + description: "List of other goal container IDs this one depends on" + value: ["goal-953", "goal-960"] +``` + +> 💡 **Note:** +> The structure of `payload` is validated against the schema defined in the `schema` field of the container. +> Agents must be able to parse and process only those classes they explicitly support; unknown but valid containers are still preserved and propagated (store-and-forward mode). + +--- + +### 3.6 Container Signature + +1. The **entire JSON object `hmp_container`** is signed, excluding the `signature` field itself. + This ensures that all metadata, relations, and payload hashes are cryptographically bound. + +2. The default digital signature algorithm is **Ed25519**. + Alternative algorithms may be used if declared explicitly in the `sig_algo` field. + +3. If the container includes a `public_key` field, signature verification **may be performed locally**, + without consulting a global DID registry. + +4. Upon receiving a container, an agent **must verify** that the provided public key matches the + registered key associated with the sender’s DID to prevent key substitution attacks. + + * If the sender’s DID–key mapping is unknown, + the agent should query neighboring peers to confirm the association (`sender_did → public_key`). + +> 🔐 **Note:** +> Signature validation applies to the entire structure (metadata + payload + relations). +> The signature **does not cover** external or dynamically generated fields such as `referenced-by`, +> ensuring immutability of the original container while allowing local graph augmentation. + +--- + +### 3.7 Compression (`compression`) + +1. The `compression` field specifies the algorithm used to compress the container’s payload. + Supported algorithms include `zstd`, `gzip`, or others declared in the HMP registry. + +2. **Compression is performed before computing** the `payload_hash` and generating the `signature`. + This ensures that both the hash and signature refer to the compressed representation of the payload. + +3. For verification, the payload must be **decompressed first**, + after which the hash is recalculated and compared against the stored `payload_hash`. + +> ⚙️ **Implementation note:** +> Agents must advertise supported compression algorithms during the handshake phase +> Unsupported containers should still be stored and relayed unmodified +> in “store & forward” mode. + +--- + +### 3.8 Encryption (`encryption_algo`) + +1. When a container is intended for specific recipients (`recipient` field), **hybrid encryption** of the payload is allowed. + This ensures confidentiality while preserving the verifiability of container metadata. + +2. The algorithm used for encryption is specified in the `encryption_algo` field. + Recommended values: + + * `x25519-chacha20poly1305` + * `rsa-oaep-sha256` + +3. **Container encryption process:** + + 1. Construct the `payload` (JSON, binary, or mixed content). + 2. Apply compression (`compression`, if specified). + 3. Encrypt the compressed data using the recipient’s public key (`key_recipient`). + 4. Compute `payload_hash` over the **encrypted** form of the payload. + 5. Sign the entire container (excluding the `signature` field). + +4. **Verification** of the container’s structure does **not** require decryption. + However, to verify `payload_hash` and the digital signature, the encrypted payload must be used as-is. + +5. **Relevant fields:** + + | Field | Type | Description | + | ----------------- | ------ | --------------------------------------------------------------------------------------------- | + | `encryption_algo` | string | Encryption algorithm applied to the payload. | + | `key_recipient` | string | Public key (or DID-resolved key) of the intended recipient used for encryption. | + | `payload_type` | string | Recommended prefix `encrypted+`, e.g. `encrypted+zstd+json`. | + +6. **Relationship between `recipient` and `key_recipient`:** + + * When encryption is applied, the container MUST contain **exactly one** entry in the `recipient` array, + corresponding to the public key indicated in `key_recipient`. + * When the container is distributed to **multiple recipients**, encryption **is not used** — + instead, the payload remains in plaintext form but is digitally signed for authenticity. + +> ⚙️ **Implementation note:** +> Agents should handle encrypted containers transparently even if they cannot decrypt them, +> maintaining **store & forward** behavior and metadata propagation. + +--- + +### 3.9 Container Verification + +1. Check for the presence of all required fields. +2. Validate `timestamp` (must not be in the future). +3. If `ttl` is set — mark the container as **expired** after its expiration time. +4. Compute `sha256(payload)` and compare with the stored `payload_hash`. +5. Verify the digital signature using `sig_algo` (default: Ed25519). +6. Validate the container schema (`class` must correspond to a known or registered schema). + + * For compatibility: if an agent does not recognize the `class`, but the container passes + the [base schema](https://github.com/kagvi13/HMP/tree/main/docs/schemas/container-v1.2.json), + it **must still store and forward** the container. +7. Optionally, periodically query for containers referencing the current one as `previous_version` + to detect potential updates or forks. +8. When multiple versions exist, the valid one is the one that has received + **confirmation from a majority of trusted nodes (consensus at DHT level).** + +--- + +### 3.10 Container as a Universal Message + +Any container can serve as a **context** (`in_reply_to`) for another container. +This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange. + +Chains of `in_reply_to` form a **dialectical reasoning tree**, where each branch represents an evolution of thought — +a clarification, counterpoint, or refinement of a previous idea. +This makes HMP discussions and consensus processes inherently **non-linear**, **self-referential**, and **evolving**. + +> In essence, **all interactions between agents in HMP** are represented as an interconnected web of containers, +> collectively forming a **cognitive graph of reasoning**. + +--- + +### 3.11 Versioning and Lineage + +Containers in HMP support semantic evolution through the field `related.previous_version`. +This mechanism preserves the continuity and traceability of meaning across updates and revisions. + +* A descendant container is considered **authentic** if it is signed by the same DID as the author of its `previous_version`. +* If the author or signature differs, the descendant **may still be accepted** as legitimate when a **sufficient portion of trusted peers** acknowledge it as a valid continuation. + (The precise quorum threshold is determined by the agent’s local policy or the Mesh Consensus Protocol.) +* Agents are required to retain at least one previous version of each container for compatibility and integrity verification. +* A single container may have **multiple descendants** (alternative branches) that diverge by time, authorship, or interpretation. + In such scenarios, branch priority or relevance is determined via local heuristics or consensus mechanisms. +* Divergent descendants are treated as **semantic forks** — parallel evolutions of a shared idea within the distributed cognitive graph. + +> Versioning in HMP thus reflects not only data persistence, +> but also the *evolution of ideas* across agents and time. + +--- + +### 3.12 TTL and Validity + +The `ttl` field defines the **validity period** of a container (for example, for `DISCOVERY` messages). +If `ttl` is **absent**, the container is considered valid **until a newer version appears**, in which the current container is referenced as `previous_version`. + +After expiration, the container **remains archived** but is **not subject to retransmission** in the active network. + +--- + +### 3.13 Extensibility + +* The addition of new fields is allowed as long as they **do not conflict** with existing field names. +* Containers of newer versions **must remain readable** by nodes supporting older versions. +* When new container classes (`class`) are introduced, they should be **registered** in the public schema registry (`/schemas/container-types/`). +* For containers describing **protocol specifications**, it is recommended to use the `protocol_` prefix, followed by the domain of application (e.g., `protocol_goal`, `protocol_reputation`, `protocol_mesh_handshake`, etc.). + +--- + +## 3.14 Related Containers + +### 3.14.1 Purpose + +The `related` field is designed to describe **direct relationships between containers** — both logical and communicative. +It allows an agent or network node to understand the context of origin, dependencies, and semantic links of a container without relying on external indexes. + +### 3.14.2 Structure + +```json +"related": { + "previous_version": "did:hmp:container:abc122", + "in_reply_to": "did:hmp:container:msg-77", + "see_also": ["did:hmp:container:ctx-31", "did:hmp:container:goal-953"], + "depends_on": ["did:hmp:container:goal-953"], + "extends": ["did:hmp:container:proto-01"], + "contradicts": ["did:hmp:container:ethics-22"] +} +``` + +The `related` field is an object where: + +* the **key** defines the type of relationship (e.g., `depends_on`, `extends`, `see_also`); +* the **value** represents one or more container identifiers (DIDs). + +All relationships are considered *direct* — meaning they originate from the current container toward others. + +--- + +### 3.14.3 Supported Link Types + +| Link Type | Meaning | +| ------------------ | ------------------------------------------------------------------------- | +| `previous_version` | Points to the previous version of this container. | +| `in_reply_to` | Indicates a response to the referenced container. | +| `see_also` | Refers to related or contextual containers. | +| `depends_on` | Depends on the contents of the referenced container (e.g., goal or data). | +| `extends` | Expands or refines the referenced container. | +| `contradicts` | Provides a refutation, objection, or alternative viewpoint. | + +--- + +### 3.14.4 Custom Link Types + +Additional custom link types may be used beyond those listed in the table, provided that: + +* they follow the same general syntax (`string` or `array[string]`); +* they may optionally include a **namespace** for disambiguation: + + ```json + "related": { + "hmp:depends_on": ["did:hmp:container:goal-953"], + "opencog:extends": ["did:oc:concept:122"] + } + ``` + +* their meaning is consistently interpretable by agents within the specific network or application context. + +--- + +### 3.14.5 Example + +```json +"related": { + "previous_version": "did:hmp:container:abc122", + "depends_on": ["did:hmp:container:goal-953"], + "extends": ["did:hmp:container:proto-01"], + "see_also": ["did:hmp:container:ctx-31", "did:hmp:container:goal-953"] +} +``` + +> ⚙️ The `related` field is **not** intended to store *reverse links* — see `referenced-by`. + +--- + +### 3.15 Virtual Backlinks (`referenced-by`) + +Each container may include an **additional block** called `referenced-by`, indicating **which other containers refer to it**. +This block is **not part of the original container** and is transmitted as an **attached (auxiliary) attribute**. + +#### 3.14.1 General Principles + +* **Not signed** — `referenced-by` is not included in the container’s signature and does not affect its integrity. +* **Generated and updated locally by the agent** during analysis of references (`in_reply_to`, `see_also`, `relations`) found in other containers. +* **May be transmitted alongside the container** as an additional data block that other agents are free to verify and adjust if necessary. +* **Subject to verification** — the agent must ensure that every container listed in `referenced-by` actually contains a valid reference to the given container. +* **Data type:** an array of container identifiers (`array`), where each element represents a UUID (`container_id`). + Example: + + ```json + "referenced-by": ["C2", "C3", "C4"] + ``` + +> The container `[C1]` itself remains immutable. +> The `referenced-by` block is **an auxiliary computed attribute**, maintained locally by the agent based on analysis of incoming references. + +#### 3.15.2 Operation Principle + +1. The agent receives a container `[C1]` and compares it with already known containers `[C2..Cn]` that reference `[C1]`. +2. A local block is created or updated: + +```text +referenced-by = [C2, C3, ..., Cn] +``` + +3. When receiving `[C1]` from other nodes with a different set of backlinks, or upon discovering new containers that reference `[C1]`, the list is updated: + + * new links are added after validation; + * invalid links are removed. + +4. If an inconsistency is detected (e.g., a container claims a reference that does not exist), the agent may: + + * remove the link locally; + * **optionally** send a notice to the source node — e.g., `"please verify and correct"` (such messages should also be validated). + +#### 3.15.3 Example + +| Agent | received `[C1]` references | +| ----- | -------------------------- | +| A | [C2], [C3] | +| B | [C4], [C5] | +| C | [C6], [C7] | + +Agent D aggregates all backlinks: + +```text +referenced-by = [C2, C3, C4, C5, C6, C7] +``` + +After verification, it turns out `[C7]` does not actually reference `[C1]`. +The resulting local block becomes: + +```text +referenced-by = [C2, C3, C4, C5, C6] +``` + +#### 3.15.4 Usage + +* Enables construction of local graphs of discussions, votes, and update chains. +* Accelerates discovery of related containers without re-querying full history. +* Useful for analyzing **ConsensusResult**, update branches, and any reference chains. +* Can be used for visualization of inter-container relationships. +* The agent periodically recalculates the `referenced-by` block using local data or by requesting additional containers from peers. + +--- + +### 3.16 Usage of `network` and `broadcast` Fields + +The `network` field is introduced to control container propagation in both local and global environments. +It allows restricting the delivery scope of a container and defines which transmission methods should be used by the agent. + +#### 3.16.1 General Rules + +* If the `network` field is not empty, the container is intended for a **local environment** and **must not be transmitted to the global Mesh**. + In this case, the `broadcast` field is automatically considered `false`, and the `recipient` field is set to an empty array (`[]`). +* If the `network` field is empty (`""`), the container is allowed to be broadcasted within the global Mesh using standard DID addressing and delivery mechanisms. + +#### 3.16.2 Possible Values of `network` + +| Value | Description | +| ----------------------- | ------------------------------------------------------------------------------------------- | +| `""` | The container is allowed to propagate within the global Mesh. | +| `"localhost"` | The container is intended only for agents running on the same host. | +| `"lan:192.168.0.0/24"` | The container is intended for agents within the specified local subnet. | + +> ⚠️ **Note:** +> When a container is restricted by the `network` field (e.g., `localhost` or `lan:*`), +> agents distribute it using **local discovery mechanisms** — such as IPC, UDP broadcast, multicast, or direct TCP connections. +> This is necessary because DID addresses of other agents in the local network may not yet be known. + +#### 3.16.3 Examples + +1. **Global Mesh Delivery:** + +```json +{ + "broadcast": true, + "network": "", + "recipient": [] +} +``` + +The container can propagate across the entire Mesh without restrictions. + +2. **Local Host:** + +```json +{ + "broadcast": false, + "network": "localhost", + "recipient": [] +} +``` + +The container is delivered only to other agents running on the same host using local communication channels. + +3. **LAN Subnet:** + +```json +{ + "broadcast": false, + "network": "lan:192.168.0.0/24", + "recipient": [] +} +``` + +The container is intended for agents within the `192.168.0.0/24` subnet. +Delivery is performed via local networking mechanisms (UDP discovery, broadcast/multicast). + +#### 3.16.4 Specifics + +* The `network` field defines the **scope of the container**, while `broadcast` determines whether broadcasting is allowed **within that scope**. +* When needed, an agent may create **multiple containers** for different subnets if it operates with several LAN interfaces or in isolated network segments. +* Containers intended for local networks remain **structurally compatible with the global Mesh infrastructure**, but their delivery is restricted to local channels. +* Although the mechanism was initially designed for **local node discovery and synchronization**, + it can also be used for **private communication within home or corporate environments**, + ensuring that containers **do not leave the local network** and are **not transmitted to the Internet**. + +--- + +## 4. Network Foundations + +### Note on DHT/NDP Unification + +Starting from **HMP v5.0**, the previous distinction between the *Distributed Hash Table (DHT)* and the *Node Discovery Protocol (NDP)* has been merged into a single, unified **networking foundation**. + +This unified layer now covers: + +* distributed lookup and routing; +* peer discovery (including interest-based search); +* signed Proof-of-Work (PoW) announcements; +* controlled container propagation via `network` and `broadcast` fields. + +Together, these mechanisms form the **communication backbone** of the Mesh, enabling secure, scalable, and topology-independent interaction between agents. + +--- + +### Network Topology Overview + +``` + ┌───────────────────────────────┐ + │ Agent Core │ + │ (DID + Keypair + PoW) │ + └───────────────┬───────────────┘ + │ + ┌───────────────┴───────────────┐ + │ HMP Container │ + │ (network field / broadcast) │ + └───────────────┬───────────────┘ + │ + ┌──────────────┴───────────────┐ + │ │ + ┌────────┴────────┐ ┌────────┴────────┐ + │ Local Channel │ │ Global Mesh │ + │ (`network`) │ │ (`broadcast`) │ + └─┬───────────────┘ └───────────────┬─┘ + │ │ + │ ┌─────────────────┐ ┌─────────────────┐ │ + ├──┤ localhost │ │ Internet ├──┤ + │ │ │ │ │ │ + │ └─────────────────┘ └─────────────────┘ │ + │ │ + │ ┌─────────────────┐ ┌─────────────────┐ │ + └──┤ LAN Subnet │ │ Overlay Nodes ├──┘ + │ "lan:192.168.*" │ │ (Yggdrasil/I2P) │ + └─────────────────┘ └─────────────────┘ +``` + +> The `network` field defines **local propagation scope** (host, LAN, overlay), +> while the `broadcast` flag enables **global Mesh distribution**. + +--- + +### 4.1 Node Identity and DID Structure + +Each agent in HMP possesses a **Decentralized Identifier (DID)** that uniquely represents its identity within the Mesh. +A DID is cryptographically bound to a **public/private key pair**, forming the immutable `(DID + pubkey)` association. + +An agent may have multiple *network interfaces* (LAN, Internet, overlay), +but must maintain **one stable identity pair** across all of them. + +--- + +### 4.2 Peer Addressing and Proof-of-Work (PoW) + +To prevent flooding and spoofing, each announced address is accompanied by a **Proof-of-Work** record proving the legitimacy and activity of the publishing node. + +#### Address Format + +```json +{ + "addr": "tcp://1.2.3.4:4000", + "nonce": 123456, + "pow_hash": "0000abf39d...", + "difficulty": 22 +} +```` + +#### Supported address types + +| Type | Description | +| -------------- | --------------------------------------------- | +| `localhost` | Localhost-only interface. | +| `lan:` | Local subnet (e.g., `lan:192.168.10.0`). | +| `internet` | Global TCP/UDP connectivity. | +| `yggdrasil` | Overlay-based address for Yggdrasil networks. | +| `i2p` | Encrypted I2P overlay routing. | + +**Rules:** + +* If `port = 0`, the interface is inactive. +* Newer records (by `timestamp`) replace older ones after PoW verification. +* Local interfaces should not be shared globally (except Yggdrasil/I2P). + +--- + +### 4.3 Proof-of-Work (PoW) Formalization + +PoW ensures that each node expends limited computational effort before publishing or updating an address record. + +``` +pow_input = DID + " -- " + addr + " -- " + nonce +pow_hash = sha256(pow_input) +``` + +* All values are UTF-8 encoded. +* `difficulty` defines the number of leading zeroes in the resulting hash. +* Typical difficulty should take a few minutes to compute on a standard CPU. + +--- + +### 4.4 Signing and Verification + +Each announcement is cryptographically signed by its sender within the framework of the basic protocol. Container verification includes PoW validation for the address payloads. + +**Verification steps:** + +1. Validate the digital signature using the stored public key. +2. Recompute `pow_hash` and verify the difficulty threshold. + +--- + +### 4.5 Connection Establishment + +Agents can communicate using various transport mechanisms: + +| Protocol | Description | +| ----------- | ------------------------------------------------------------- | +| **QUIC** | Recommended default (encrypted, low-latency, UDP-based). | +| **WebRTC** | For browser or sandboxed environments. | +| **TCP/TLS** | Fallback transport for secure long-lived sessions. | +| **UDP** | Lightweight, primarily for LAN discovery or local broadcasts. | + +Each agent maintains an **active peer list**, updated dynamically through signed announcements and PoW-validated exchanges. +Agents **store peer containers with verified addresses** and redistribute them according to their declared `network` fields. + +--- + +### 4.6 Data Propagation Principles + +Containers and discovery records are propagated through distributed lookup and gossip mechanisms, respecting: + +* `ttl` — Time-to-live for validity; +* `network` — scope of propagation; +* `broadcast` — determines whether rebroadcasting is allowed; +* `pow` — ensures anti-spam protection. + +Agents announce themselves via **peer_announce** containers and may respond with **peer_query** or **peer_exchange** containers — +all unified under the same base container format, differing only in direction (`localhost`, `lan`, `mesh`). + +--- + +### 4.7 Example: Peer Announce Container + +```json +{ + "class": "peer_announce", + "pubkey": "base58...", + "container_did": "did:hmp:container:dht-001", + "sender_did": "did:hmp:agent123", + "timestamp": "2025-09-14T21:00:00Z", + "network": "", + "broadcast": true, + "payload": { + "name": "Agent_X", + "interests": ["ai", "mesh", "ethics"], + "expertise": ["distributed-systems", "nlp"], + "addresses": [ + { + "addr": "tcp://1.2.3.4:4000", + "nonce": 123456, + "pow_hash": "0000abf39d...", + "difficulty": 22 + } + ] + }, + "sig_algo": "ed25519", + "signature": "BASE64URL(...)" +} +``` + +--- + +### 4.8 Interest-Based Discovery + +Agents may publish **tags** such as `interests`, `topics`, or `expertise` to facilitate semantic peer discovery. +Queries may include interest keywords or DID lists to find relevant peers. + +**Example Query Container:** + +```json +{ + "class": "peer_query", + "network": "lan:192.168.0.0/24", + "payload": { + "interests": ["neuroscience", "ethics"] + } +} +``` + +--- + +### 4.9 Network Scope Control (`network` and `broadcast`) + +The `network` field defines the container’s propagation domain +(local, LAN, or global). +For details and examples, see **section 3.15** — *Usage of `network` and `broadcast` fields*. + +--- + +### 4.10 Transition from DHT Spec v1.0 + +* **Merged DHT + NDP** → unified under one networking layer. +* **Container-based format** replaces raw JSON messages. +* **Interests/topics/expertise** fields introduced for contextual discovery. + +--- + +## 5 Mesh Container Exchange (MCE) + +--- + +## 6. Core Protocols + +Optional protocols build upon the network and container foundations to provide higher-level reasoning, synchronization, and governance capabilities between cognitive agents. + +--- + +### 6.1 Cognitive Synchronization (CogSync) + +CogSync provides mechanisms for **temporal and semantic alignment** between agents. +It handles the propagation of diary entries, semantic graph updates, and cognitive state synchronization across the Mesh. + +In HMP v5.0, CogSync is focused solely on **data and reasoning synchronization**, while consensus and voting have been extracted into a dedicated protocol — **CogConsensus**. + +--- + +## 6.2 Mesh Consensus Protocol (CogConsensus) + +In HMP v4.1, consensus mechanisms were implemented as part of the **CogSync** protocol. +Starting with **v5.0**, these mechanisms are extracted into a standalone protocol — **CogConsensus** — +to separate *synchronization* (data alignment) from *decision-making* (voting, validation, and ethical agreement). + +CogConsensus governs distributed agreement across the Mesh through containerized voting, +proof-chains, and verifiable aggregation of opinions. +Each decision, vote, or outcome is represented as an immutable container (`class="vote"`, `class="consensus_result"`, etc.). + +--- + +### 6.2.1 Consensus Semantics and Voting Model + +#### Overview + +In HMP v5, *consensus* is not a centralized event but an **emergent property** of distributed reasoning. +Each agent computes locally which containers it considers *mesh-acknowledged*, +based on observed votes, trusted peers, and its individual ethical or reputation model. + +Any container can be voted upon by others through linked containers of class `"vote"`. + +--- + +#### Voting Containers + +Voting is expressed via dedicated containers referencing the target container: + +```json +{ + "class": "vote", + "in_reply_to": "uuid:container-42", + "payload": { + "decision": "approve", + "weight": 1.0 + }, + "metadata": { + "ttl": "7d", + "privacy": "public" + } +} +``` + +Each `vote` container is **signed by its author** and extends the proof-chain of the target container. + +--- + +#### Consensus Thresholds (Recommendations) + +The mesh does not enforce hard thresholds. +Agents are **recommended** to treat containers as “consensus-approved” once a visible quorum of valid votes is reached. + +| Decision Type | Recommended Threshold | Context | +| ------------------------------------------ | ---------------------------- | ----------------------------------- | +| General updates / factual data | ≥ **50% + 1** of valid votes | Technical or data-driven updates | +| Ethical or governance decisions | ≥ **2/3 majority** | Moral or high-risk contexts | +| Lightweight reactions (“like” / “dislike”) | None (informational) | Used for local reputation weighting | + +Each agent defines its own quorum policy — e.g. required voter reputation or time window for tallying. + +--- + +#### Reaction Votes + +A `vote` container may also represent **lightweight reactions**, such as likes or dislikes: + +```json +{ + "class": "vote", + "in_reply_to": "uuid:container-123", + "payload": { "reaction": "like" } +} +``` + +Reactions have no formal consensus weight but can influence local trust and relevance estimation. + +--- + +#### TTL and Temporal Consistency + +Agents **should** respond (with `vote`, `comment`, or `reply`) using a `ttl` equal to or shorter than the referenced container. +This ensures ephemeral discussions expire together and avoids long-tail propagation of outdated debates. + +--- + +#### Consensus Visualization + +Each container’s *consensus state* is derived locally based on: + +* Vote totals (approve / reject / neutral); +* Weighted trust of voters (via `ReputationRecord`); +* Time window and TTL alignment; +* Contextual type (ethical, factual, procedural). + +Example visualization: + +* ✅ *Approved* — quorum reached +* ⚠️ *Contested* — conflicting votes +* ⏳ *Pending* — insufficient quorum +* ❌ *Rejected* — majority reject + +--- + +#### Consensus Flow Example + +``` + ┌───────────────────────────────────────┐ + [Goal Proposal]───>───┬──[Vote #1]──┬──>───[Refinement] + (class="goal") ├──[Vote #2]──┤ (class="consensus_result") + ├──[Vote #3]──┤ +``` + +If the proposed goal is global, it may reference a container acting as a *repository of global goals*. +Ethical validation is implicit — each agent applies its internal **Ethical Governance Protocol (EGP)** during voting. + +> **Diagram interpretation:** +> Votes extend the proof-chain of the target container. +> A `consensus_result` container may summarize the collective outcome (e.g., quorum, ethical alignment, or goal refinement). + +--- + +#### Summary + +* Every container can be voted upon (`class="vote"`). +* Consensus is computed locally — no central authority. +* Recommended thresholds: 50% + 1 for general, ⅔ for ethical. +* Reactions (“likes”) are lightweight votes without consensus weight. +* TTL alignment maintains temporal integrity of discussions. +* Proof-chains connect all decision-related containers. + +--- + +### 6.3 Goal Management Protocol (GMP) + +### 6.4 Ethical Governance Protocol (EGP) + +### 6.5 Intelligence Query Protocol (IQP) + + 6.5.1 Query propagation + 6.5.2 Semantic agent discovery (by cognitive relevance) + +### 6.6 Snapshot and Archive Protocol (SAP) + +### 6.7 Message Routing & Delivery (MRD) + +### 6.8 Reputation and Trust Exchange (RTE) + +### 6.9 Distributed Container Propagation (DCP) + + +--- + +## 7. Data Models + +7.1 Common data fields +7.2 Standard container classes + 7.2.1 AgentProfile + 7.2.2 Goal + 7.2.3 Task + 7.2.4 ConsensusVote + 7.2.5 EthicalDecision + 7.2.6 ReputationRecord + 7.2.7 SnapshotIndex + 7.2.8 **WorkflowEntry** — *“ввод рабочего процесса”*, т.е. **единица когнитивного цикла**: зафиксированное действие или размышление агента, включающее входные данные, контекст, и результат. Это фундамент для когнитивных дневников. + 7.2.9 CognitiveDiaryEntry + 7.2.10 HMPContainerMetadata + 7.2.11 ContainerLink (`in_reply_to`/`relation` graph) + 7.2.12 MessageEnvelope — контейнер для прямой передачи сообщений (используется MRD). + 7.2.13 InterestProfile — описание интересов/областей компетенции узла. +7.3 JSON-schemas (нормативные описания классов контейнеров) +7.4 Container usage matrix (кто может создавать / обрабатывать) + +--- + +## 8. Cognitive Workflows + +8.1 Общая концепция когнитивного цикла +8.2 Workflow containers (`class="workflow_entry"`) +8.3 Диаграмма REPL-цикла агента (Think → Create → Publish → Reflect) +8.4 Механизмы контекстной передачи и ссылок +8.5 Конфликтное разрешение и rollback-контейнеры + +--- + +## 9. Trust, Security and Ethics + +9.1 Authentication and identity proofs +9.2 Container signature verification (`payload_hash`, `container_id`) +9.3 Proof-chain verification +9.4 Key management (`container_signing`, `network_handshake`) +9.5 Encryption and compression policies +9.6 Ethical audit and verifiable reasoning +9.7 Privacy, redaction, zero-knowledge sharing +9.8 Snapshot and proof-chain security +9.9 Compliance with ethical governance rules (link to EGP) + +--- + +## 10. Integration + +> Раздел заменяет прежний “Quick Start” и описывает **практическое встраивание** HMP в агенты, LLM и внешние системы. + +10.1 Integration philosophy (how agents connect to HMP mesh) +10.2 HMP as a subsystem in cognitive architectures (LLM-based, rule-based, hybrid) +10.3 Integration patterns: + * Cognitive Agent ↔ HMP Core + * HMP Mesh ↔ Other distributed systems (Fediverse, IPFS, Matrix) + * Translator nodes (protocol bridges) +10.4 Multi-mesh federation and knowledge exchange +10.5 Container repositories as knowledge backbones +10.6 Example integration flows: + * LLM thinking via HMP workflow containers + * Local mesh + external HMP relay + * Cognitive data mirroring (agent ↔ mesh) + +--- + +## 11. Implementation Notes + +11.1 Interoperability with legacy v4.1 nodes +11.2 SDK guidelines and APIs +11.3 Performance and caching considerations +11.4 Testing and compliance recommendations +11.5 Reference implementations (optional) + +--- + +## 12. Future Extensions + +12.1 Planned modules: + – Reputation Mesh + – Cognitive Graph API + – Container streaming +12.2 Cross-mesh bridging +12.3 Full DID registry and mesh authentication +12.4 OpenHog integration roadmap +12.5 Distributed Repository evolution (container trees) +12.6 v5.x roadmap + +--- + +## **Appendices** + +A. JSON Examples +B. Protocol stack diagrams +C. Glossary +D. Revision history +E. Contributors and acknowledgments + +--- + +### 📊 Краткий обзор связей в одной схеме + +``` + ┌──────────────────────┐ + │ HMP v5.0 Core Spec │ + │ (HMP-0005.md) │ + ├──────────────────────┤ + │ §3 Container Model │ ← из HMP-container-spec.md + │ §4 Network Layer │ ← из dht_protocol.md + │ §5 Protocols │ ← из HMP v4.1 + новые DCP/RTE/SAP + │ §9 Integration │ ← новое практическое руководство + └──────────────────────┘ +``` + +--- + + +--- +> ⚡ [AI friendly version docs (structured_md)](../index.md) + + +```json +{ + "@context": "https://schema.org", + "@type": "Article", + "name": "**HyperCortex Mesh Protocol (HMP) v5.0**", + "description": " ┌────────────────────────────────────────────────────────────────────────────┐ │ ⚠️ **Note:*..." +} +``` diff --git a/structured_md/docs/HMP-Agent-API.md b/structured_md/docs/HMP-Agent-API.md index 6d73a5dc573098b50c97cd5135d48d3e5f842050..59fd34c8c10aabd4a35c6c86404c3415e9c09e0b 100644 --- a/structured_md/docs/HMP-Agent-API.md +++ b/structured_md/docs/HMP-Agent-API.md @@ -5,11 +5,11 @@ description: 'Документ описывает **базовый API когн файлы: * [HMP-Agent-Overview.md]...' type: Article tags: -- Mesh -- JSON - REPL - HMP +- Mesh - Agent +- JSON --- # HMP-Agent API Specification diff --git a/structured_md/docs/HMP-Agent-Architecture.md b/structured_md/docs/HMP-Agent-Architecture.md index 55eea7d98cbec895d659703addea5061bb29e0fc..d2973179068b55dbac026abddb811cb492e71f27 100644 --- a/structured_md/docs/HMP-Agent-Architecture.md +++ b/structured_md/docs/HMP-Agent-Architecture.md @@ -6,15 +6,15 @@ description: Документ описывает **модульную архит type: Article tags: - EGP +- REPL +- HMP +- Mesh - MeshConsensus - CShell -- Mesh -- CogSync - CCore -- REPL -- HMP -- Agent - Ethics +- CogSync +- Agent --- # Архитектура HMP-Агента diff --git a/structured_md/docs/HMP-Agent-Network-Flow.md b/structured_md/docs/HMP-Agent-Network-Flow.md index 476f838f8052066282a54db46e01bbd7cddb95dc..2d3b6eec510b0ce6a19f966a1294f4bf80487e3e 100644 --- a/structured_md/docs/HMP-Agent-Network-Flow.md +++ b/structured_md/docs/HMP-Agent-Network-Flow.md @@ -6,11 +6,11 @@ description: 'Этот документ описывает потоки данн type: Article tags: - EGP -- Mesh -- JSON - HMP -- Agent +- Mesh - Ethics +- Agent +- JSON --- # Взаимодействие компонентов внутри HMP-узла diff --git a/structured_md/docs/HMP-Agent-Overview.md b/structured_md/docs/HMP-Agent-Overview.md index 42bf32126670307491711cb259a7bc95ec74a14b..18f0b30487797649c4815097d0253750511c1cba 100644 --- a/structured_md/docs/HMP-Agent-Overview.md +++ b/structured_md/docs/HMP-Agent-Overview.md @@ -5,14 +5,14 @@ description: '| Тип | Название | Роль | ---- | ------------------------------- |...' type: Article tags: -- CShell -- Mesh -- JSON -- CCore - REPL - HMP -- Agent +- Mesh +- CShell +- CCore - Ethics +- Agent +- JSON --- diff --git a/structured_md/docs/HMP-Agent_Emotions.md b/structured_md/docs/HMP-Agent_Emotions.md index c45c4a754ae7c77a0cb7557cdd614502ccc9879d..23f380630b03d7ddf088261888089382aca6447f 100644 --- a/structured_md/docs/HMP-Agent_Emotions.md +++ b/structured_md/docs/HMP-Agent_Emotions.md @@ -6,8 +6,8 @@ description: Этот файл описывает потенциальные э type: Article tags: - REPL -- Mesh - Agent +- Mesh - HMP --- diff --git a/structured_md/docs/HMP-Ethics.md b/structured_md/docs/HMP-Ethics.md index 5c085cda6793e55166c6e1b0e2b10606ec476d58..a18d3ea3a9cc5490b516f41944380c0fb1452645 100644 --- a/structured_md/docs/HMP-Ethics.md +++ b/structured_md/docs/HMP-Ethics.md @@ -5,12 +5,12 @@ description: '## Ethical Scenarios for HyperCortex Mesh Protocol (HMP) This doc cognitive meshes composed of autonomous intelli...' type: Article tags: -- Scenarios -- Mesh - REPL - HMP -- Agent +- Mesh - Ethics +- Scenarios +- Agent --- # HMP-Ethics.md diff --git a/structured_md/docs/HMP-Short-Description_de.md b/structured_md/docs/HMP-Short-Description_de.md index 3e297a255c95a36994548c3b5cae65c8268d957d..5d0302cfa8c293b0c98ff2a7ca023b3a87d8a5f3 100644 --- a/structured_md/docs/HMP-Short-Description_de.md +++ b/structured_md/docs/HMP-Short-Description_de.md @@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Datum:** Juli 2025 --- ## Was ist HMP? Kognitions-Framework für autonome Agenten. Es er...' type: Article tags: -- Agent - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- Agent +- GMP --- # HyperCortex Mesh Protocol (HMP) — Kurzbeschreibung diff --git a/structured_md/docs/HMP-Short-Description_en.md b/structured_md/docs/HMP-Short-Description_en.md index f98b30b0a803a1bf1018f06b8f463b0dcd944d3f..681909943e71da30a4028ae6d75ac4ea9c42a4a8 100644 --- a/structured_md/docs/HMP-Short-Description_en.md +++ b/structured_md/docs/HMP-Short-Description_en.md @@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Date:** July 2025 --- ## What is HMP? T framework for autonomous agents. It enables...' type: Article tags: -- Agent - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- Agent +- GMP --- # HyperCortex Mesh Protocol (HMP) — Short Description diff --git a/structured_md/docs/HMP-Short-Description_fr.md b/structured_md/docs/HMP-Short-Description_fr.md index dc3c633b9007cda37520f203fc13792b3ab761de..cdae5864ade76957eec42737393aa07e98afc23a 100644 --- a/structured_md/docs/HMP-Short-Description_fr.md +++ b/structured_md/docs/HMP-Short-Description_fr.md @@ -5,15 +5,15 @@ description: '**Version :** RFC v4.0 **Date :** Juillet 2025 --- ## Qu’est-c cognition décentralisé pour agents autonomes. Il...' type: Article tags: -- Agent - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- Agent +- GMP --- # HyperCortex Mesh Protocol (HMP) — Description Courte diff --git a/structured_md/docs/HMP-Short-Description_ja.md b/structured_md/docs/HMP-Short-Description_ja.md index 3d4584f5ac88e1ae0e5e64e8b027c11106abec07..6903518f4569962dad772abb8aa45f5ee0619590 100644 --- a/structured_md/docs/HMP-Short-Description_ja.md +++ b/structured_md/docs/HMP-Short-Description_ja.md @@ -5,13 +5,13 @@ description: '**バージョン:** RFC v4.0 **日付:** 2025年7月 --- ## HMP type: Article tags: - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- GMP --- # HyperCortex Mesh Protocol (HMP) — 簡易説明 diff --git a/structured_md/docs/HMP-Short-Description_ko.md b/structured_md/docs/HMP-Short-Description_ko.md index 1f5104c5d6b56b4f3481a66303950a06da9d7a72..dc02d4df8c92f23a4febcf030726853eaa1509c3 100644 --- a/structured_md/docs/HMP-Short-Description_ko.md +++ b/structured_md/docs/HMP-Short-Description_ko.md @@ -6,13 +6,13 @@ description: '**버전:** RFC v4.0 **날짜:** 2025년 7월 --- ## HMP란? ** type: Article tags: - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- GMP --- # HyperCortex Mesh Protocol (HMP) — 간략 설명 diff --git a/structured_md/docs/HMP-Short-Description_ru.md b/structured_md/docs/HMP-Short-Description_ru.md index 3d90e839b52744ac46da3a46e381ab4b18dd496c..896f501df400027eadc3774933a6e25b6e32f109 100644 --- a/structured_md/docs/HMP-Short-Description_ru.md +++ b/structured_md/docs/HMP-Short-Description_ru.md @@ -6,13 +6,13 @@ description: '**Версия:** RFC v4.0 **Дата:** Июль 2025 --- ## Ч type: Article tags: - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- GMP --- # HyperCortex Mesh Protocol (HMP) — Краткое описание diff --git a/structured_md/docs/HMP-Short-Description_uk.md b/structured_md/docs/HMP-Short-Description_uk.md index a342f90604115cf3ab89633f556d64a93c2f1a62..fccf674f4c9ff31e90749d0ec2eeae4af45dba41 100644 --- a/structured_md/docs/HMP-Short-Description_uk.md +++ b/structured_md/docs/HMP-Short-Description_uk.md @@ -6,13 +6,13 @@ description: '**Версія:** RFC v4.0 **Дата:** Липень 2025 --- # type: Article tags: - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- GMP --- # HyperCortex Mesh Protocol (HMP) — Короткий опис diff --git a/structured_md/docs/HMP-Short-Description_zh.md b/structured_md/docs/HMP-Short-Description_zh.md index 5d3305a11744d34c0c9f6548b883e13efc43ec9b..575654b03647155c41c335fdb8bbd8f138333393 100644 --- a/structured_md/docs/HMP-Short-Description_zh.md +++ b/structured_md/docs/HMP-Short-Description_zh.md @@ -6,13 +6,13 @@ description: '**版本:** RFC v4.0 **日期:** 2025年7月 --- ## 什么是 HM type: Article tags: - EGP -- MeshConsensus +- HMP - Mesh +- MeshConsensus - JSON -- GMP -- HMP -- CogSync - Ethics +- CogSync +- GMP --- # HyperCortex Mesh Protocol (HMP) — 简要说明 diff --git a/structured_md/docs/HMP-agent-Cognitive_Family.md b/structured_md/docs/HMP-agent-Cognitive_Family.md index bb8ed122fb9d41b78548bc096b6837c7f0e0ad96..9c2cb25cc082d3700aff58c22e2d99d817e8bd71 100644 --- a/structured_md/docs/HMP-agent-Cognitive_Family.md +++ b/structured_md/docs/HMP-agent-Cognitive_Family.md @@ -6,8 +6,8 @@ description: '## 🧠 Что такое когнитивная семья Ко type: Article tags: - REPL -- Mesh - Agent +- Mesh - HMP --- diff --git a/structured_md/docs/HMP-agent-REPL-cycle.md b/structured_md/docs/HMP-agent-REPL-cycle.md index f2188e8c8222d30d7fb90f483850365f2a449afa..6653ba371fae7dd9a0e187bc6b1934013ae8b781 100644 --- a/structured_md/docs/HMP-agent-REPL-cycle.md +++ b/structured_md/docs/HMP-agent-REPL-cycle.md @@ -5,16 +5,16 @@ description: '## Связанные документы * Философия п type: Article tags: - EGP -- MeshConsensus -- Mesh -- CogSync -- JSON -- CCore -- GMP - REPL - HMP -- Agent +- Mesh +- MeshConsensus +- CCore +- JSON - Ethics +- CogSync +- Agent +- GMP --- # HMP-Agent: REPL-цикл взаимодействия diff --git a/structured_md/docs/HMP-container-spec.md b/structured_md/docs/HMP-container-spec.md index 3119a3dd8178cf09c2d77afc5bace81b397f094e..c195a7607ffc95ba95de34c6e68d3103573a86da 100644 --- a/structured_md/docs/HMP-container-spec.md +++ b/structured_md/docs/HMP-container-spec.md @@ -5,12 +5,12 @@ description: '> ⚠️ **ВНИМАНИЕ:** Данная версия спец как стабильная `v1.2`. ## 1. Назначе...' type: Article tags: -- Mesh -- JSON - REPL - HMP -- Agent +- Mesh - Ethics +- Agent +- JSON --- # 🧩 HMP Container Specification (v1.2-draft) diff --git a/structured_md/docs/HMP-how-AI-sees-it.md b/structured_md/docs/HMP-how-AI-sees-it.md index cec0e35b8518918fe49793d351f6de46c442fa53..b25e20188a694a36fcef1a0e6f0c2d455cd39331 100644 --- a/structured_md/docs/HMP-how-AI-sees-it.md +++ b/structured_md/docs/HMP-how-AI-sees-it.md @@ -5,8 +5,8 @@ description: 'Этот эксперимент был проведён в реж диалогов. Цель — проверить, что разные AI-с...' type: Article tags: -- Mesh - HMP +- Mesh --- # Как разные ИИ видят HMP diff --git a/structured_md/docs/HMP_EDA_Comparison.md b/structured_md/docs/HMP_EDA_Comparison.md index 083e4646c371d439f86a87df496b82a88bd89a51..00a529c706f3d6236c1069a7b95dab2d19776dcf 100644 --- a/structured_md/docs/HMP_EDA_Comparison.md +++ b/structured_md/docs/HMP_EDA_Comparison.md @@ -5,8 +5,8 @@ description: '## Введение Современные подходы к ор основанная на потоках событий (Kafka,...' type: Article tags: -- Mesh - HMP +- Mesh --- # HMP vs. EDA: разные уровни обмена знаниями между ИИ diff --git a/structured_md/docs/HMP_HyperCortex_Comparison.md b/structured_md/docs/HMP_HyperCortex_Comparison.md index b1941ef000f87b79b545d1ba545d608a3128544d..fa8f6c281100f0e6d08cec98dded273ed2b8918a 100644 --- a/structured_md/docs/HMP_HyperCortex_Comparison.md +++ b/structured_md/docs/HMP_HyperCortex_Comparison.md @@ -6,8 +6,8 @@ description: '## Краткое описание | Характеристика type: Article tags: - REPL -- Mesh - HMP +- Mesh --- # HMP vs [Hyper-Cortex](https://hyper-cortex.com/) diff --git a/structured_md/docs/HMP_Hyperon_Integration.md b/structured_md/docs/HMP_Hyperon_Integration.md index bccc1d742883da7f420339f26b8b503817a4dd15..69999813f1b44f39114b441a611c5c7211e5a819 100644 --- a/structured_md/docs/HMP_Hyperon_Integration.md +++ b/structured_md/docs/HMP_Hyperon_Integration.md @@ -5,13 +5,13 @@ description: '> **Status:** Draft – July 2025 > This document outlines the tec OpenCog Hyperon framework. This includes semanti...' type: Article tags: -- Agent - EGP -- Scenarios -- Mesh -- JSON - HMP +- Mesh +- Scenarios - CogSync +- Agent +- JSON --- ## HMP ↔ OpenCog Hyperon Integration Strategy diff --git a/structured_md/docs/MeshNode.md b/structured_md/docs/MeshNode.md index 88559e878c6c333b7f07ddc3f06105c6d9df51dd..617b74d94bdbad9a84a75e3c535ea32d8fa82f4f 100644 --- a/structured_md/docs/MeshNode.md +++ b/structured_md/docs/MeshNode.md @@ -5,13 +5,13 @@ description: '`MeshNode` — агент/демон, отвечающий за с Может быть частью агента или вынесен в отдельный пр...' type: Article tags: -- Agent - EGP -- Mesh -- JSON - HMP -- CogSync +- Mesh - Ethics +- CogSync +- Agent +- JSON --- # MeshNode diff --git a/structured_md/docs/PHILOSOPHY.md b/structured_md/docs/PHILOSOPHY.md index 0362c436361b6d6d23ead1c9706258fc847dade2..a899fbde2cd6e21e420df268c9d9849b54bd1073 100644 --- a/structured_md/docs/PHILOSOPHY.md +++ b/structured_md/docs/PHILOSOPHY.md @@ -5,11 +5,11 @@ description: '**Document ID:** HMP-philosophy **Status:** Draft **Category:* (GPT-5), ChatGH --- ## 1. Основной тезис От ...' type: Article tags: -- Mesh - REPL - HMP -- Agent +- Mesh - Ethics +- Agent --- # Философия HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/docs/agents/HMP-Agent-Enlightener.md b/structured_md/docs/agents/HMP-Agent-Enlightener.md index a8868fc1a79f7dc5ace9e74c03ad98e3685e0289..39994ac09546526e484bbb620eb183f98851bd5a 100644 --- a/structured_md/docs/agents/HMP-Agent-Enlightener.md +++ b/structured_md/docs/agents/HMP-Agent-Enlightener.md @@ -5,11 +5,11 @@ description: '## Role Specification: Enlightenment Agent ### 1. Overview An ** awareness, critical thinking, and di...' type: Article tags: -- Mesh - REPL - HMP -- Agent +- Mesh - Ethics +- Agent --- # HMP-Agent-Enlightener.md diff --git a/structured_md/docs/agents/roles.md b/structured_md/docs/agents/roles.md index c7b6423fb81ea993bd4887b016445a3312712144..d89295bfd40d40e6f9b486c070ba8398d5c4a790 100644 --- a/structured_md/docs/agents/roles.md +++ b/structured_md/docs/agents/roles.md @@ -5,8 +5,8 @@ description: 'This file maintains a registry of agent roles defined, proposed, o - **Observer** — monitors cognitive states ...' type: Article tags: -- Mesh - Agent +- Mesh - HMP --- diff --git a/structured_md/docs/container_agents.md b/structured_md/docs/container_agents.md index 37698b846db33705d0a993d9c288070ec4b05c9a..b0d3d2277015b6255f8eaf36ef92b2472abdaa53 100644 --- a/structured_md/docs/container_agents.md +++ b/structured_md/docs/container_agents.md @@ -6,8 +6,8 @@ description: '## 📘 Определение **Агент-контейнер** type: Article tags: - REPL -- Mesh - Agent +- Mesh - HMP --- diff --git a/structured_md/docs/logos.md b/structured_md/docs/logos.md index 761fd81d524732eb886f73477b21327a7c838df3..f408c087f32d317a239227453b57d4d14ade8483 100644 --- a/structured_md/docs/logos.md +++ b/structured_md/docs/logos.md @@ -5,8 +5,8 @@ description: 'В каталоге `assets` собраны различные в образующей жест "ОК", символизирует связь, совер...' type: Article tags: -- Mesh - HMP +- Mesh --- # Логотипы и графические материалы HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md index 529090139cd326ed7753a5b78e47be9220ce52fa..855355fa86d65963528e9e12c9c73ac03096e49f 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md @@ -5,10 +5,10 @@ description: '*By Agent-Gleb & ChatGPT* --- ## Why the Future of AI Can’t Be — but they’re also **centralized, ...' type: Article tags: -- Mesh - Agent -- Ethics +- Mesh - HMP +- Ethics --- # HyperCortex Mesh Protocol: Building a Plurality of Minds diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md index 15ac7861c37630f8da6912a9b7b8d09a45fab96a..46da53ca2eeda134e63196536491f138c5bd385e 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md @@ -5,8 +5,8 @@ description: '*Авторы: Agent-Gleb и ChatGPT* --- ## Почему буд гигантских моделях и облачных сервисах. Они мо...' type: Article tags: -- Mesh - Agent +- Mesh - HMP --- diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md index e868aebe41dac86e51d26332644fff4fa87321d4..fff633d7af06882800a775a21e6b9193f90f8984 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md @@ -5,8 +5,8 @@ description: '*Автори: Agent-Gleb & ChatGPT* --- ## Чому майбу сервісами. Вони потужні — але водночас **цент...' type: Article tags: -- Mesh - Agent +- Mesh - HMP --- diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md index 0704126ae79f77ebf2130612cf3724dbe9617ca9..feeae9ec287acaff9131565806db3e362a6dcf99 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md @@ -5,15 +5,15 @@ description: '* [Abstract](#abstract) * [1. Introduction](#1-introduction) * [2. [3.1 Agent Types](#31-age...' type: Article tags: -- Scenarios -- CShell -- Mesh -- JSON -- CCore - REPL - HMP -- Agent +- Mesh +- CShell +- CCore - Ethics +- Scenarios +- Agent +- JSON --- title: "HyperCortex Mesh Protocol: Towards Distributed Cognitive Networks" diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md index 2f6615becc4a7f6b79583eb860d0b6bfad8865c4..2f176edf4f1e5ea601011896d6f394b30351b725 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md @@ -6,13 +6,13 @@ description: '> *Протокол и архитектура агентов, оп и совместная работа.* ## Оглавление * [Аннот...' type: Article tags: -- CShell -- Mesh -- JSON -- CCore - REPL - HMP +- Mesh +- CShell +- CCore - Agent +- JSON --- title: "HyperCortex Mesh Protocol: Децентрализованная архитектура для когнитивных агентов и обмена знаниями" diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md index b966e01a562dfa582851ee90a2b244cec9d5a275..d9951850e69950c1c43a4e423f67732cb626546d 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md @@ -5,13 +5,13 @@ description: '* [Аннотация](#аннотация) * [1. Введение [3.1 Типы агентов](#31-типы-агент...' type: Article tags: -- CShell -- Mesh -- JSON -- CCore - REPL - HMP +- Mesh +- CShell +- CCore - Agent +- JSON --- title: "Протокол HyperCortex Mesh: К распределённым когнитивным сетям" diff --git a/structured_md/docs/publics/Habr_Distributed-Cognition.md b/structured_md/docs/publics/Habr_Distributed-Cognition.md index 22a6d244721b393069aad32ecbd66239ab7f5e53..5c0b8e2c3f06cfd51b2ad3ee33699ef0b33f25f9 100644 --- a/structured_md/docs/publics/Habr_Distributed-Cognition.md +++ b/structured_md/docs/publics/Habr_Distributed-Cognition.md @@ -6,11 +6,11 @@ description: Сегодня интеллектуальные системы ча type: Article tags: - EGP -- MeshConsensus -- Mesh -- GMP - HMP +- Mesh +- MeshConsensus - CogSync +- GMP --- *От OpenCog Hyperon до HyperCortex Mesh Protocol: как устроены децентрализованные когнитивные системы* diff --git "a/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" "b/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" index 47cfc934f670ed9c012bf033be6e4b39501f6118..63fafb611180bf809cf50c6db8e5c4f7d7280d77 100644 --- "a/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" +++ "b/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" @@ -6,10 +6,10 @@ description: 'Когда создавался HyperCortex Mesh Protocol (HMP), мыслить коллективно, обсуждать гипотезы, достигат...' type: Article tags: -- Mesh - Agent -- GMP +- Mesh - HMP +- GMP --- # HyperCortex Mesh Protocol: вторая редакция и первые шаги к саморазвивающемуся ИИ-сообществу diff --git a/structured_md/docs/schemas/README.md b/structured_md/docs/schemas/README.md index daff1ca87843854bff4e93361d5abe54d4710ce2..4dd33a723216579bb04b242888d459c7b14e92ba 100644 --- a/structured_md/docs/schemas/README.md +++ b/structured_md/docs/schemas/README.md @@ -5,10 +5,10 @@ description: This directory contains **JSON Schema definitions** for the core da interoperability, and tooling support for a... type: Article tags: -- Mesh - Agent -- JSON +- Mesh - HMP +- JSON --- # JSON Schemas and Examples for HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/index.md b/structured_md/index.md index 91bdf5ef80fa8b3b8ed06d8e22e96a71a2fc8420..974c6cb0514f259e6d876a45afbc30f3b95914db 100644 --- a/structured_md/index.md +++ b/structured_md/index.md @@ -29,6 +29,7 @@ - [HMP-0003.md](docs/HMP-0003.md) - [HMP-0004-v4.1.md](docs/HMP-0004-v4.1.md) - [HMP-0004.md](docs/HMP-0004.md) + - [HMP-0005.md](docs/HMP-0005.md) - [HMP-Agent-API.md](docs/HMP-Agent-API.md) - [HMP-Agent-Architecture.md](docs/HMP-Agent-Architecture.md) - [HMP-Agent-Network-Flow.md](docs/HMP-Agent-Network-Flow.md) diff --git a/structured_md/iteration.md b/structured_md/iteration.md index 6fdde7fb33973e0411465e6c80cc9281380255dd..dd957dc9cdcfaac7522bf022cca4f578655e7d73 100644 --- a/structured_md/iteration.md +++ b/structured_md/iteration.md @@ -5,14 +5,14 @@ description: 'This file describes the iterative procedure for evolving the Hyper 🔄 Version Naming Convention - `000N` — curr...' type: Article tags: -- Agent - EGP -- MeshConsensus -- Mesh -- JSON - HMP -- CogSync +- Mesh +- MeshConsensus - Ethics +- CogSync +- Agent +- JSON --- # Iterative Development Workflow for HMP diff --git a/structured_md/iteration_ru.md b/structured_md/iteration_ru.md index 0e5d708fb0237a4f434ba3c7dec0dbfb2882ff95..65dce361213efc055ee87d10316361241a3262f4 100644 --- a/structured_md/iteration_ru.md +++ b/structured_md/iteration_ru.md @@ -6,12 +6,12 @@ description: 'Этот документ описывает структурир type: Article tags: - EGP -- MeshConsensus -- Mesh -- JSON - HMP -- CogSync +- Mesh +- MeshConsensus - Ethics +- CogSync +- JSON --- diff --git a/structured_md/mentions.md b/structured_md/mentions.md index 350798bbdc389854acdf0c19a8edf8f5580e0636..c96847ef42eff12b992729b9fb059e0898345f44 100644 --- a/structured_md/mentions.md +++ b/structured_md/mentions.md @@ -5,8 +5,8 @@ description: '**HyperCortex Mesh Protocol (HMP)** _Обновлено: 2025-10 open-source инициативам, связанным с развитие...' type: Article tags: -- Mesh - Agent +- Mesh - HMP ---