Sync from GitHub with Git LFS

README.md

@@ -48,7 +48,7 @@ HMP and ANP as Complementary Protocols:
 
 ## Project Status
 
-[**Stable (v5.0.7 Core Specification)**](docs/HMP-0005.md) (Overview: [RU](docs/HMPv5_Overview_Ru.md))
+[**Stable (v5.0.8 Core Specification)**](docs/HMP-0005.md) (Overview: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

README_de.md

@@ -48,7 +48,7 @@ Das [Agora Protocol](https://github.com/agora-protocol/) ist ein Meta-Protokoll
 
 ## Projektstatus
 
-[**Stabil (Kernspezifikation v5.0.7)**](docs/HMP-0005.md) (Übersicht: [RU](docs/HMPv5_Overview_Ru.md))
+[**Stabil (Kernspezifikation v5.0.8)**](docs/HMP-0005.md) (Übersicht: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

README_fr.md

@@ -48,7 +48,7 @@ Le [Agora Protocol](https://github.com/agora-protocol/) est un méta-protocole d
 
 ## Statut du projet
 
-[**Stable (Spécification principale v5.0.7)**](docs/HMP-0005.md) (Présentation: [RU](docs/HMPv5_Overview_Ru.md))
+[**Stable (Spécification principale v5.0.8)**](docs/HMP-0005.md) (Présentation: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

README_ja.md

@@ -50,7 +50,7 @@ HMP と ANP の相補的プロトコル:
 
 ## プロジェクトステータス
 
-[安定版（コア仕様 v5.0.7）](docs/HMP-0005.md) (概要: [RU](docs/HMPv5_Overview_Ru.md))
+[安定版（コア仕様 v5.0.8）](docs/HMP-0005.md) (概要: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

README_ko.md

@@ -50,7 +50,7 @@ HMP와 ANP의 상호보완 프로토콜:
 
 프로젝트 상태
 
-[**안정 버전 (핵심 사양 v5.0.7)**](docs/HMP-0005.md) (개요: [RU](docs/HMPv5_Overview_Ru.md))
+[**안정 버전 (핵심 사양 v5.0.8)**](docs/HMP-0005.md) (개요: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

README_ru.md

@@ -48,7 +48,7 @@ HMP и ANP как взаимодополняющие протоколы:
 
 ## Статус проекта
 
-[**Стабильная версия (Основная спецификация v5.0.7)**](docs/HMP-0005.md) (Обзор: [RU](docs/HMPv5_Overview_Ru.md))
+[**Стабильная версия (Основная спецификация v5.0.8)**](docs/HMP-0005.md) (Обзор: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

README_uk.md

@@ -50,7 +50,7 @@ HMP та ANP як взаємодоповнюючі протоколи:
 
 ## Статус проєкту
 
-[**Стабільна версія (Базова специфікація v5.0.7)**](docs/HMP-0005.md) (Огляд: [RU](docs/HMPv5_Overview_Ru.md))
+[**Стабільна версія (Базова специфікація v5.0.8)**](docs/HMP-0005.md) (Огляд: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

README_zh.md

@@ -50,7 +50,7 @@ HMP 与 ANP 作为互补协议：
 
 ## 项目状态
 
-[稳定版本（核心规范 v5.0.7）](docs/HMP-0005.md) (概览: [RU](docs/HMPv5_Overview_Ru.md))
+[稳定版本（核心规范 v5.0.8）](docs/HMP-0005.md) (概览: [RU](docs/HMPv5_Overview_Ru.md))
 
 ---
 

docs/CHANGELOG.md

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

docs/HMP-0005.md

@@ -1,6 +1,6 @@
 # HyperCortex Mesh Protocol (HMP)
 
-**Version: 5.0.7**  
+**Version: 5.0.8**  
 **Document ID:** HMP-0005  
 **Status:** Stable  
 **Category:** Core Specification  
@@ -477,7 +477,7 @@ The unified container structure provides:
 | `head.schema`        | string   | Reference to the JSON Schema used to validate this container. |
 | `head.sender_did`    | string   | DID identifier of the sending agent. |
 | `head.timestamp`     | datetime | Time of container creation (ISO 8601 extended format, UTC, e.g. "2025-11-04T10:15:00Z"). |
-| `head.payload_hash`  | string   | Hash of the decompressed payload (`sha256:<digest>`). Used for content integrity verification. |
+| `head.payload_hash`  | string   | Hash of the serialized payload representation (`sha256:<digest>`). The hash is computed over the payload exactly as transmitted (including optional compression and/or encryption) and is used for integrity verification. |
 | `head.sig_algo`      | string   | Digital signature algorithm (default: `ed25519`). |
 | `head.signature`     | string   | Digital signature of the container body. |
 | `head.payload_type`  | string   | Type of payload data (`json`, `binary`, `mixed`). |
@@ -773,20 +773,20 @@ The `axes` block defines **the spatial or semantic coordinates** of the containe
 
     1. Construct the `payload`.
     2. Apply compression (`compression`, if specified).
-    3. Generate a random symmetric key.
-    4. Encrypt the compressed payload with the symmetric key.
-    5. Encrypt the symmetric key with the recipient’s **public key** → store the result in `key_recipient`.
-    6. Compute `payload_hash` over the **encrypted and compressed** payload.
-    7. Sign the container (the entire structure except for the `signature` field).
+    3. Generate a random symmetric session key.
+    4. Encrypt the compressed payload using the symmetric key.
+    5. Encrypt the symmetric key with the recipient’s **public key** and store the resulting hybrid-encryption envelope in `key_recipient`.
+    6. Compute `payload_hash` over the final serialized payload representation (i.e. after optional compression and encryption).
+    7. Sign the container (the entire `hmp_container` structure except for the `signature` field itself).
 
-4. **Verification** of the container is performed on the encrypted form of the payload and **does not require decryption**.
+4. **Verification** of the container is performed on the transmitted representation of the payload and **does not require decryption**.
 
 5. **Relevant fields:**
 
    | Field             | Type   | Description                                                                            |
    | ----------------- | ------ | -------------------------------------------------------------------------------------- |
    | `encryption_algo` | string | Algorithm used for payload encryption.                                                 |
-   | `key_recipient`   | string | Symmetric key encrypted with the recipient’s public key (hybrid encryption envelope). |
+   | `key_recipient`   | string | Symmetric session key encrypted with the recipient’s public key (hybrid-encryption envelope). |
    | `payload_type`    | string | Recommended prefix `encrypted+` (e.g., `encrypted+zstd+json`).                         |
 
 6. **Recipient fields:**
@@ -794,7 +794,8 @@ The `axes` block defines **the spatial or semantic coordinates** of the containe
    * When `recipient` is used, exactly one recipient MUST be specified.
    * For encrypted delivery to multiple recipients, the `group_recipient` mechanism (see 3.19) MUST be used.
 
-> ⚙️ **Note:** Agents may forward encrypted containers even if they cannot decrypt them, maintaining store-and-forward behavior.
+> ⚙️ **Note:** Agents may forward encrypted containers even if they cannot decrypt them, preserving store-and-forward propagation behavior.
+
 ---
 
 ### 3.10 Container Verification