diff --git a/docs/HMP-0005.md b/docs/HMP-0005.md index 64770a61e3faa47cf460bb4ecf97e4ab0668e9ce..616d2a946687a70e82107f5eabc6c04b29d0aaeb 100644 --- a/docs/HMP-0005.md +++ b/docs/HMP-0005.md @@ -457,6 +457,8 @@ The unified container structure provides: | Field | Type | Description | | --------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `head.recipient` | array(string) | One or more recipient DIDs. | +| `head.key_recipient` | string | Symmetric encryption key, encrypted with the recipient’s public key. | +| `head.group_recipient` | array(object) | Multi-recipient hybrid-encryption envelopes. See section 3.19. | | `head.broadcast` | bool | Broadcast flag. If `true`, the `recipient` field is ignored. | | `head.tags` | array(string) | Thematic or contextual tags for the container. | | `head.confidence` | float | Optional numeric field (0.0–1.0) indicating the agent’s subjective certainty regarding the payload’s reliability. | @@ -464,7 +466,6 @@ The unified container structure provides: | `head.public_key` | string | Sender’s public key, if not globally resolvable via DID. | | `head.compression` | string | Compression algorithm used for the payload (`zstd`, `gzip`). | | `head.magnet_uri` | string | Magnet link pointing to the original or mirrored container. | -| `head.key_recipient` | string | Symmetric encryption key, encrypted with the recipient’s public key. | | `head.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. | | `head.subclass` | string | Optional subtype or specialization of the container’s class. Enables agents to differentiate more specific container families (e.g. `"goal.research_hypothesis"`, `"quant.semantic_node"`). Inherits schema from the parent `class`. | | `head.encryption_algo` | string | Algorithm used for payload encryption. | @@ -1202,6 +1203,40 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/ --- +### 3.19 Multi-recipient encrypted containers (`group_recipient`) + +To enable encrypted delivery to multiple recipients, HMP containers MAY include the optional field: + +```json +"group_recipient": [ + { + "recipient": "did:hmp:agent456", + "key_recipient": "BASE58(...)" + }, + { + "recipient": "did:hmp:agent457", + "key_recipient": "BASE58(...)" + } +] +``` + +**Semantics:** + +1. A single symmetric key is generated for the payload. +2. For each listed recipient, this symmetric key is encrypted with that recipient’s public key and placed in `key_recipient`. +3. All recipients receive the SAME encrypted payload and decode it independently using their individual key envelopes. + +**Rules:** + +* `group_recipient` MUST NOT be used together with the `head.recipient` and `head.key_recipient` fields. +* The header remains public; only the payload is encrypted. +* The container is signed once by the sender — no shared signing keys are required. +* Nodes SHOULD deliver the container to every DID listed in `group_recipient`. + +This mechanism provides efficient **multicast-style encrypted messaging**, fully compatible with the existing container structure and hybrid encryption scheme. + +--- + ## 4. Network foundations ### Note on DHT/NDP unification @@ -1820,7 +1855,7 @@ Message and container transmission follows the network constraints specified in > Thus, containers and indexes can be distributed both in **local** (home, corporate) networks and in the **global Mesh**. > When `recipient` is specified together with `broadcast: true`, the container is routed through the Mesh but intended for specific recipients — -> See **Message Routing & Delivery (MRD, §6.7)** for details on message transmission mechanisms. +> See **Message Routing & Delivery (MRD, §6.8)** for details on message transmission mechanisms. --- @@ -3339,9 +3374,334 @@ def compute_consensus(container_id): --- -### 6.3 Goal Management Protocol (GMP) +### 6.3 Fortytwo Consensus Protocol (Pairwise Collective Reasoning) + +**Based on the study:** +*Agata Grzybowska, Wojciech Bożejewicz, Timothy Nguyen, et al. “Fortytwo: Collective Reasoning with Paired Comparisons in Decentralized AI Swarms”, 2025.* (arXiv:2510.24801) + +--- + +#### 6.3.1 Overview + +The **Fortytwo Consensus Protocol** implements a decentralized collective-reasoning mechanism in HyperCortex Mesh using **pairwise comparisons**, **iterative rounds**, and **reputation-weighted aggregation**. + +Unlike the Mesh Consensus Protocol (CogConsensus), Fortytwo is not intended to produce a binary agreement. Its goal is to **select the best solution among many alternatives** using a distributed multi-stage evaluation process. + +**Fortytwo enables:** + +* higher accuracy of collective decisions, +* resistance to Sybil attacks and malicious scoring, +* independent evaluations from many judges (agents), +* aggregation of results into a multi-round tree structure, +* transparent reasoning via short CoT chains. + +The protocol is fully compatible with HMP container architecture and can operate as an independent mechanism for collective choice. + +--- + +#### 6.3.2 Protocol Objectives + +Fortytwo is designed for: + +1. **Collecting candidate solutions** for a given task. +2. **Constructing structured pairwise comparisons** among participants. +3. **Multi-round elimination of candidates**. +4. **Independent evaluation** by distributed judges. +5. **Producing a consistent global result** based on aggregated pairwise data. +6. **Ensuring transparency and verifiability of reasoning** for each judge. +7. **Building a consensus tree** stored in the DHT. + +--- + +#### 6.3.3 Roles in the Protocol + +* **Producers** — agents submitting candidate solutions. +* **Judges** — agents performing pairwise evaluations. +* **Partitioners** — agents generating round partitions. +* **Aggregators** — agents publishing round results and the final result. + +Roles are not fixed and require no prior declaration; any agent may assume any role by publishing the corresponding container. + +--- + +#### 6.3.4 Container Types + +| class | purpose | +| ----------------------- | ----------------------- | +| `fortytwo_round` | round partition | +| `fortytwo_evaluation` | pairwise comparison | +| `fortytwo_round_result` | round result | +| `fortytwo_final_result` | final aggregated result | + +--- + +##### Container for solution submission + +Used to submit answers to a task. + +Although `workflow_entry` (defined in the §6.4 *Goal Management Protocol, GMP*) is referenced here as the default solution container, the Fortytwo method is applicable to any homogeneous set of candidate containers. + +--- + +##### Container `fortytwo_round` (round partition) + +Defines the structure of pairwise comparisons for the current round. + +**Simplified structure:** + +```json +{ + "head": { "class": "fortytwo_round" }, + "payload": { + "round": 0, + "answers": [ + "did:hmp:container:abc001", "did:hmp:container:abc002", + "did:hmp:container:abc003", "did:hmp:container:abc004", + "did:hmp:container:abc005", "did:hmp:container:abc006", + "did:hmp:container:abc007" + ], + "blocks": { + "block1": ["did:hmp:container:abc001", "did:hmp:container:abc002"], + "block2": ["did:hmp:container:abc003", "did:hmp:container:abc004"], + "block3": ["did:hmp:container:abc005", "did:hmp:container:abc006"], + "block4": ["did:hmp:container:abc007"] + } + } +} +``` + +Any agent may publish such a container — the protocol allows multiple independent partitions. + +--- + +##### Container `fortytwo_evaluation` (pairwise evaluation) + +A judge compares two solutions and selects a winner. + +```json +{ + "head": { "class": "fortytwo_evaluation" }, + "payload": { + "comparison": { + "pair": ["did:hmp:container:abc001", "did:hmp:container:abc002"], + "winner": "did:hmp:container:abc001", + "reasoning": "Short reasoning (50–100 tokens)" + }, + "round": 0, + "block": "block1" + } +} +``` + +These containers form the distributed pairwise comparison matrix. + +--- + +##### Container `fortytwo_round_result` (round result) + +Stores the winners of a round. + +```json +{ + "head": { "class": "fortytwo_round_result" }, + "payload": { + "round": 0, + "winners": [ + "did:hmp:container:abc001", + "did:hmp:container:abc003", + "did:hmp:container:abc005", + "did:hmp:container:abc007" + ], + "evaluations_used": [ + "did:hmp:container:abf004", + "did:hmp:container:adc003", + "did:hmp:container:aba001" + ] + } +} +``` + +--- + +##### Container `fortytwo_final_result` (final result) + +Contains: + +* the final winner, +* all round results, +* references to all partitions and evaluations. + +```json +{ + "head": { "class": "fortytwo_final_result" }, + "payload": { + "winner": "did:hmp:container:abc002", + "rounds": [ + "did:hmp:container:abf001", + "did:hmp:container:abf002", + "did:hmp:container:abf003" + ], + "method": "pairwise_collective_reasoning", + "participants": 27 + } +} +``` + +--- + +##### Recommendations for using the `related` block + +In all Fortytwo containers, the `related` block establishes the DAG of dependencies. + +* `related.in_reply_to` specifies the *primary* parent for this step. +* `related.depends_on` may contain **all containers referenced during the action**, including both explicit payload entries and additional dependencies chosen by the agent. + +**Specific recommendations:** + +* **`fortytwo_round`** + + * `in_reply_to`: a `task` container (first round) or the previous `fortytwo_round`. + * `depends_on`: submitted solutions (`workflow_entry`) and any containers used to construct the partition. + +* **`fortytwo_evaluation`** + + * `in_reply_to`: the corresponding `fortytwo_round`. + * `depends_on`: both compared solutions and any extra reasoning dependencies. + +* **`fortytwo_round_result`** + + * `in_reply_to`: the corresponding `fortytwo_round`. + * `depends_on`: round winners and all evaluation containers used in aggregation. -#### 6.3.1 Purpose +* **`fortytwo_final_result`** + + * `in_reply_to`: the `task` container. + * `depends_on`: the final winner and all `fortytwo_round_result` containers involved. + +--- + +#### 6.3.5 Protocol Algorithm + +**Step 1 — Task publication** +A `task` container is created. + +**Step 2 — Collecting all solutions** +Agents publish `workflow_entry` containers. + +**Step 3 — Round partitioning** +Any agent may publish a `fortytwo_round` defining pairwise comparison blocks: + +* pairs of candidates, +* single items automatically advancing. + +**Step 4 — Pairwise evaluations** +Other agents perform comparisons according to the partition. +Each pair produces a `fortytwo_evaluation` container. + +**Step 5 — Round result** +An aggregator publishes a `fortytwo_round_result` containing: + +* winners of all blocks, +* references to evaluation containers. + +**Step 6 — Next round** +If more than one winner remains: + +* a new partition is created, +* new evaluations are performed. + +**Step 7 — Final result** +When only one candidate remains, a `fortytwo_final_result` is published. + +This container, like any other, may be published by multiple agents, with optional argumentation via the `evaluations` block. + +--- + +#### 6.3.6 Tree-like consensus structure + +Protocol outputs form a DAG: + +``` +(task) + ├─ workflow_entry 1 + ├─ workflow_entry 2 + ├─ workflow_entry 3 + ├─ workflow_entry 4 + ├─ fortytwo_round 0 + | ├─ fortytwo_evaluation 0.1 + | ├─ fortytwo_evaluation 0.2 + | ├─ fortytwo_evaluation 0.3 + | ├─ fortytwo_round_result 0 + | └─ fortytwo_round 1 + | ├─ fortytwo_evaluation 1.1 + | ├─ fortytwo_evaluation 1.2 + | ├─ fortytwo_evaluation 1.3 + | └─ fortytwo_round_result 1 + | ├─ ... + └─ fortytwo_final_result +``` + +Each round reduces the number of candidates until only one remains. + +This ensures: + +* transparency, +* verifiability, +* easy replication in the DHT. + +--- + +#### 6.3.7 Integration with CogConsensus + +Fortytwo: + +* does **not** replace CogConsensus, +* but provides a mechanism for selecting the **best answer**. + +CogConsensus remains the higher-level agreement layer, responsible for: + +* validating final results, +* verifying round correctness, +* coordinating task flow. + +--- + +#### 6.3.8 Robustness and Security + +Fortytwo is resilient to: + +* **Sybil attacks**, since every judge must provide capability-proof, +* **malicious evaluations**, due to distributed pairwise data and independent aggregators, +* **partial failures**, because rounds can be re-aggregated by any agent. + +--- + +#### 6.3.9 Replication and Storage + +All Fortytwo containers: + +* are published into the DHT, +* maintain stable reference structure, +* may be aggregated independently by any agent. + +--- + +#### 6.3.10 Applications + +Fortytwo is suitable for: + +* evaluating reasoning chains, +* selecting the best argument or proof, +* solving mathematical problems, +* choosing optimal code solutions, +* scientific analysis, +* complex multi-step decision-making. + +--- + +### 6.4 Goal Management Protocol (GMP) + +#### 6.4.1 Purpose **GMP (Goal Management Protocol)** defines the process by which agents create, decompose, delegate, and track goals and tasks using **immutable HMP containers**. Each goal, task, or workflow record exists as an independent container linked to others via the `related.*` fields. @@ -3350,7 +3710,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.2 Container classes +#### 6.4.2 Container classes | Class | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | @@ -3364,7 +3724,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.3 Goal lifecycle +#### 6.4.3 Goal lifecycle 1. **Creation** @@ -3401,7 +3761,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.4 Payload schemas (simplified) +#### 6.4.4 Payload schemas (simplified) ##### `goal` container @@ -3444,7 +3804,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.5 Integration with consensus and ethics +#### 6.4.5 Integration with consensus and ethics * GMP interacts with **CogConsensus** for distributed validation of goals and tasks. * Before execution, tasks may undergo **ethical validation (EGP)**. @@ -3453,7 +3813,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.6 Example Proof-Chain +#### 6.4.6 Example Proof-Chain ```mermaid flowchart LR @@ -3493,7 +3853,7 @@ not direct links defined in the `related.*` structure. --- -#### 6.3.7 Implementation notes +#### 6.4.7 Implementation notes * Containers are **immutable**. Any update (e.g., task status or progress change) is expressed as a **new container** referencing the previous one via `related.previous_version`. * Complete deletion of a container is only possible when it no longer exists on any nodes in the network. @@ -3506,9 +3866,9 @@ not direct links defined in the `related.*` structure. --- -### 6.4 Ethical Governance Protocol (EGP) +### 6.5 Ethical Governance Protocol (EGP) -#### 6.4.1 Purpose +#### 6.5.1 Purpose **EGP (Ethical Governance Protocol)** ensures the alignment of agent actions with the fundamental ethical principles of the Mesh network. It acts as an **overlay layer above CogConsensus (6.2)**, enabling the identification, discussion, and resolution of moral disagreements between agents. @@ -3517,7 +3877,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -#### 6.4.2 Container classes +#### 6.5.2 Container classes | Class | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | @@ -3529,7 +3889,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -#### 6.4.3 Payload schemas (simplified) +#### 6.5.3 Payload schemas (simplified) ##### Container `ethics_case` @@ -3571,7 +3931,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -#### 6.4.4 Protocol logic +#### 6.5.4 Protocol logic EGP follows the model: @@ -3607,7 +3967,7 @@ ethics_case --- -#### 6.4.5 Consensus thresholds +#### 6.5.5 Consensus thresholds * A decision is accepted when **at least 2/3 of votes are positive** (`value > 0`). * If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_result`. @@ -3617,7 +3977,7 @@ ethics_case --- -#### 6.4.6 Example: `ethical_result` container +#### 6.5.6 Example: `ethical_result` container ```json { @@ -3653,7 +4013,7 @@ ethics_case --- -#### 6.4.7 Proof-Chain example +#### 6.5.7 Proof-Chain example ```mermaid flowchart LR @@ -3701,7 +4061,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -#### 6.4.8 Ethical principles +#### 6.5.8 Ethical principles | Priority | Principle | Description | | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- | @@ -3714,16 +4074,16 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -#### 6.4.9 Integration with other protocols +#### 6.5.9 Integration with other protocols * **CogConsensus (6.2):** Used for distributed voting and consensus computation. -* **GMP (6.3):** Ethical verification of goals and tasks prior to delegation. -* **SAP (6.6):** Archiving completed cases and conflicts. +* **GMP (6.4):** Ethical verification of goals and tasks prior to delegation. +* **SAP (6.7):** Archiving completed cases and conflicts. * **MCE (5):** Distribution of ethical cases and related containers across the Mesh network. --- -#### 6.4.10 Implementation notes +#### 6.5.10 Implementation notes * **Immutability:** All EGP containers are **immutable**. Any revision (e.g., added votes or updated conclusions) must be published as a **new container** referencing the previous one via `related.previous_version`. @@ -3763,9 +4123,9 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.5 Intelligence Query Protocol (IQP) +### 6.6 Intelligence Query Protocol (IQP) -#### 6.5.1 Purpose and Principles +#### 6.6.1 Purpose and Principles **IQP (Intelligence Query Protocol)** defines a mechanism for knowledge exchange and reasoning among agents through the Mesh network. It provides a unified format for **asking questions, publishing answers, and collaboratively refining knowledge**, @@ -3791,7 +4151,7 @@ and **distributed discussions** where results remain accessible to all network p --- -#### 6.5.2 Container Classes +#### 6.6.2 Container Classes | Class | Purpose | | -------------------- | ----------------------------------------------------------------------------------------------------------- | @@ -3802,7 +4162,7 @@ and **distributed discussions** where results remain accessible to all network p --- -#### 6.5.3 Payload Schemas (simplified) +#### 6.6.3 Payload Schemas (simplified) ##### Container `query_request` @@ -3878,7 +4238,7 @@ Example `self_profile`: --- -#### 6.5.4 Protocol Logic +#### 6.6.4 Protocol Logic ``` query_request @@ -3894,7 +4254,7 @@ Agents participating through `query_subscription` receive notifications about ne --- -#### 6.5.5 Interaction Rules +#### 6.6.5 Interaction Rules 1. **Initiation.** An agent creates a `query_request` — defining the question, context, and constraints. @@ -3917,7 +4277,7 @@ Agents participating through `query_subscription` receive notifications about ne --- -#### 6.5.6 Proof-Chain Example +#### 6.6.6 Proof-Chain Example ```mermaid flowchart LR @@ -3943,7 +4303,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re --- -#### 6.5.7 Container examples +#### 6.6.7 Container examples ##### Example `query_request` @@ -4040,7 +4400,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re --- -#### 6.5.8 Implementation Notes +#### 6.6.8 Implementation Notes * Containers are **immutable**; any clarification or correction is published as a new container referencing the previous one via `related.previous_version` or `related.in_reply_to`. @@ -4055,19 +4415,19 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re --- -#### 6.5.9 Integration with Other Protocols +#### 6.6.9 Integration with Other Protocols * **CogConsensus (6.2)** — used for assessing agreement on IQP outcomes. -* **GMP (6.3)** — queries may refine or extend goals and tasks. -* **EGP (6.4)** — applies ethical filtering and knowledge trust evaluation. -* **SAP (6.6)** — for archiving completed discussions and retrospective analysis. +* **GMP (6.4)** — queries may refine or extend goals and tasks. +* **EGP (6.5)** — applies ethical filtering and knowledge trust evaluation. +* **SAP (6.7)** — for archiving completed discussions and retrospective analysis. * **MCE (5)** — governs dissemination of IQP containers across the Mesh network. --- -### 6.6 Snapshot and Archive Protocol (SAP) +### 6.7 Snapshot and Archive Protocol (SAP) -#### 6.6.1 Purpose and Principles +#### 6.7.1 Purpose and Principles **SAP (Snapshot and Archive Protocol)** defines how agents create, distribute, and restore archived snapshots of related HMP containers. It ensures that a set of containers — representing a discussion, reasoning chain, or workflow — can be **preserved, verified, and shared** as a coherent unit. @@ -4087,7 +4447,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha --- -#### 6.6.2 Container Class +#### 6.7.2 Container Class | Class | Purpose | | ------------------- | ----------------------------------------------------------------------- | @@ -4095,7 +4455,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha --- -#### 6.6.3 Payload Structure (simplified) +#### 6.7.3 Payload Structure (simplified) ##### Container `archive_snapshot` @@ -4126,7 +4486,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha --- -#### 6.6.4 Relations and Inclusion Rules +#### 6.7.4 Relations and Inclusion Rules The `archive_snapshot` container describes what is included and how it was derived. @@ -4142,7 +4502,7 @@ The `archive_snapshot` container describes what is included and how it was deriv --- -#### 6.6.5 Archival Structure +#### 6.7.5 Archival Structure Typical directory layout of a packaged snapshot: @@ -4165,7 +4525,7 @@ archive/ --- -#### 6.6.6 Snapshot Construction Logic +#### 6.7.6 Snapshot Construction Logic 1. **Load base containers.** Retrieve all containers relevant to the discussion or process. @@ -4190,7 +4550,7 @@ archive/ --- -#### 6.6.7 Mermaid Graph Representation +#### 6.7.7 Mermaid Graph Representation The `graph_mermaid` field provides a textual, human-readable description of how containers in the archive are interconnected. It reflects both **direct relations** (`related.*`) and **reverse references** (`referenced-by`, `evaluations`), @@ -4226,7 +4586,7 @@ allowing agents to restore both dependency chains and citation structures. --- -#### 6.6.8 Manifest File +#### 6.7.8 Manifest File Each archive includes a `manifest.json` that mirrors `archive_snapshot.payload` and lists all containers with their metadata and hashes. @@ -4255,7 +4615,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.9 Example Container `archive_snapshot` +#### 6.7.9 Example Container `archive_snapshot` ```json { @@ -4292,7 +4652,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.10 Agent Behavior During Snapshot Loading +#### 6.7.10 Agent Behavior During Snapshot Loading * Load the archive (via `magnet_link`). * Validate archive integrity via `checksum`. @@ -4304,7 +4664,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.11 Implementation Notes +#### 6.7.11 Implementation Notes * Containers are **immutable**; updated versions require a new `archive_snapshot`. * Agents may create **partial** or **incremental** archives. @@ -4316,13 +4676,13 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.12 Integration with Other Protocols +#### 6.7.12 Integration with Other Protocols **Archives for:** -* **GMP (6.3)** — preserves goal-planning or workflow chains. -* **EGP (6.4)** — retains ethical provenance and decision traceability. -* **IQP (6.5)** — archives reasoning threads and query-result discussions. +* **GMP (6.4)** — preserves goal-planning or workflow chains. +* **EGP (6.5)** — retains ethical provenance and decision traceability. +* **IQP (6.6)** — archives reasoning threads and query-result discussions. **Uses:** @@ -4330,7 +4690,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.13 Optional Extensions +#### 6.7.13 Optional Extensions * **Merkle-root validation:** use `hash_root` for Merkle verification of distributed archives. * **Delta archives:** incremental snapshots capturing only updated containers. @@ -4345,7 +4705,7 @@ and lists all containers with their metadata and hashes. --- -### 6.7 Message Routing & Delivery (MRD) +### 6.8 Message Routing & Delivery (MRD) The **Message Routing & Delivery (MRD)** subsystem defines how containers are delivered to specific agents across the Mesh. Unlike the **Mesh Container Exchange (MCE)**, which is responsible for publishing and exchanging containers in the Mesh network, @@ -4357,7 +4717,7 @@ Peers discover suitable relays via `peer_announce` metadata, while delivery rout --- -#### 6.7.1 Purpose +#### 6.8.1 Purpose The MRD layer provides: @@ -4373,7 +4733,7 @@ reusing the same cryptographic and audit primitives as MCE. --- -#### 6.7.2 Routing Roles +#### 6.8.2 Routing Roles Agents MAY declare their network-related capabilities using the `roles` field of the `peer_announce` container (see §4.7). These roles guide how MRD will route and deliver containers. @@ -4405,7 +4765,7 @@ The recipient later retrieves pending containers via standard MCE queries (see --- -#### 6.7.3 Routing Modes +#### 6.8.3 Routing Modes MRD defines several routing modes, complementing the exchange primitives of MCE: @@ -4416,7 +4776,7 @@ MRD defines several routing modes, complementing the exchange primitives of MCE: | **Topic-based Relay (PubSub)** | Delivery via aggregator nodes that group containers by tags or topics. | Nodes act as “news hubs,” maintaining indexed collections retrievable by interest-based queries. | | **Interest Broadcast** | Discovery-driven propagation via container indexes. | Agents search container indices by `tags`; typically used for query or content discovery, not for personal delivery. | -Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.7.4). +Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.8.4). Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation. > **Note:** @@ -4425,7 +4785,7 @@ Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation. --- -#### 6.7.4 Relay Chain +#### 6.8.4 Relay Chain To ensure delivery traceability, each relay MAY attach a **`relay_chain`** block to the propagated container: @@ -4460,7 +4820,7 @@ This preserves integrity while allowing verifiable routing and chain pruning for --- -#### 6.7.5 Delivery Policies +#### 6.8.5 Delivery Policies Delivery behavior is governed by local policies, often derived from declared roles and trust metrics: @@ -4478,7 +4838,7 @@ Non-cognitive nodes `relay` or `mailman` MAY instead maintain a local **delivery --- -#### 6.7.6 Example: Relay Delivery Flow +#### 6.8.6 Example: Relay Delivery Flow ```mermaid flowchart LR @@ -4497,7 +4857,7 @@ flowchart LR --- -#### 6.7.7 Security and Privacy Notes +#### 6.8.7 Security and Privacy Notes * All MRD flows rely on canonical container signatures for end-to-end integrity. * Temporary copies of encrypted containers SHOULD be stored as-is. @@ -4506,14 +4866,14 @@ flowchart LR --- -#### 6.7.8 Relation to Other Layers +#### 6.8.8 Relation to Other Layers | Layer | Relation | | ----------------- | --------------------------------------------------------------------------------- | | **MCE (5)** | Provides base exchange and serialization; MRD builds on it for targeted delivery. | | **CogSync (6.1)** | Uses MRD for delivering cognitive state updates between peers. | -| **SAP (6.6)** | Archival nodes (`archive` role) participate in MRD for historical retrieval. | -| **RTE (6.8)** | Trust metrics guide routing, caching, and relay selection. | +| **SAP (6.7)** | Archival nodes (`archive` role) participate in MRD for historical retrieval. | +| **RTE (6.9)** | Trust metrics guide routing, caching, and relay selection. | --- @@ -4524,7 +4884,7 @@ flowchart LR --- -### 6.8 Reputation and Trust Exchange (RTE) +### 6.9 Reputation and Trust Exchange (RTE) The **Reputation and Trust Exchange (RTE)** subsystem defines how agents evaluate and exchange verifiable trust assessments. Each agent MAY publish one or more `trust` containers describing its evaluation of other peers’ reliability, integrity, and ethical conduct. @@ -4533,7 +4893,7 @@ RTE provides a decentralized foundation for **participant reputation assessment* --- -#### 6.8.1 Trust Container Structure +#### 6.9.1 Trust Container Structure The `trust` container represents an agent’s evaluation of a **single peer**. It may refer to the evaluated peer’s latest known `peer_announce` container, @@ -4589,7 +4949,7 @@ This allows gradual enrichment of the trust model without schema changes. --- -#### 6.8.2 Trust Dynamics +#### 6.9.2 Trust Dynamics Trust assessments evolve as agents observe new behavior or receive additional evidence. Each revision of trust is published as a new `trust` container referencing its predecessor. @@ -4617,7 +4977,7 @@ This approach provides continuity, auditability, and decentralized trust graph e --- -#### 6.8.3 Local Trust Model +#### 6.9.3 Local Trust Model Each agent maintains a **local trust model**, periodically recalculating scores based on: @@ -4641,18 +5001,18 @@ All published trust containers remain publicly verifiable through DHT and SAP in --- -#### 6.8.4 Integration with Other Layers +#### 6.9.4 Integration with Other Layers | Layer | Role | | ----------------- | ---------------------------------------------------------------------------- | -| **MRD (6.7)** | Uses trust scores to prioritize or exclude relay nodes. | +| **MRD (6.8)** | Uses trust scores to prioritize or exclude relay nodes. | | **CogSync (6.1)** | Adjusts synchronization strength based on peer reliability. | -| **SAP (6.6)** | Archives may snapshot trust graphs for temporal or evidential analysis. | -| **EGP (7)** | Ethical Governance Protocol weights participation and voting by trust level. | +| **SAP (6.7)** | Archives may snapshot trust graphs for temporal or evidential analysis. | +| **EGP (6.5)** | Ethical Governance Protocol weights participation and voting by trust level. | --- -#### 6.8.5 Security and Sharing Notes +#### 6.9.5 Security and Sharing Notes * All containers are cryptographically signed; `trust` containers follow standard HMP verification rules. * Agents MAY choose to share trust containers selectively — e.g., encrypt and deliver directly to trusted peers instead of broadcasting. @@ -4669,9 +5029,9 @@ All published trust containers remain publicly verifiable through DHT and SAP in --- -### 6.9 Distributed Container Propagation +### 6.10 Distributed Container Propagation -#### 6.9.1 Purpose +#### 6.10.1 Purpose The distributed container propagation mechanism defines **how containers are stored, replicated, and exchanged between agents** within the HMP network. @@ -4681,7 +5041,7 @@ including replication, filtering, and index synchronization. --- -#### 6.9.2 Core Principles +#### 6.10.2 Core Principles 1. **Self-propagation** Each agent autonomously decides which containers to retain, forward, or index. @@ -4706,7 +5066,7 @@ including replication, filtering, and index synchronization. --- -#### 6.9.3 Propagation Types +#### 6.10.3 Propagation Types | Type | Description | |------|--------------| @@ -4715,7 +5075,7 @@ including replication, filtering, and index synchronization. --- -#### 6.9.4 Propagation Coordination +#### 6.10.4 Propagation Coordination Container propagation is coordinated using existing **MCE** structures: @@ -4731,18 +5091,18 @@ When it is necessary to log the fact of a container batch propagation, this MAY --- -#### 6.9.5 Integration with Other Layers +#### 6.10.5 Integration with Other Layers | Layer | Role | |-------|------| | **MCE (5)** | Provides low-level container and index exchange. | -| **MRD (6.7)** | Handles routing and delivery between agents. | -| **RTE (6.8)** | Determines replication priorities and trust-based filters. | -| **SAP (6.6)** | Enables recovery of historical or missing containers. | +| **MRD (6.8)** | Handles routing and delivery between agents. | +| **RTE (6.9)** | Determines replication priorities and trust-based filters. | +| **SAP (6.7)** | Enables recovery of historical or missing containers. | --- -#### 6.9.6 Security and Load Management +#### 6.10.6 Security and Load Management * **Rate and size limiting:** agents regulate transfer volume based on trust and network quotas. * **Interest filtering:** containers are exchanged only between agents for whom they are relevant. @@ -4789,7 +5149,8 @@ The following table lists the main container classes defined in the HMP v5.0 spe | **Mesh Container Exchange (MCE)** | `container_index`, `container_request`, `container_response`, `container_delta`, `container_ack`, `referenced-by_exchange`, `evaluations_exchange` | Replication, querying, acknowledgment of received containers, and exchange of reverse links and evaluations. | | **Cognitive Metastructure (CogSync)** | `abstraction`, `axes` | Define hierarchical and coordinate dimensions of knowledge, forming the agent’s cognitive map. | | **Knowledge & Reasoning** | `diary_entry`, `semantic_node`, `semantic_index`, `semantic_edges`, `semantic_group`, `tree_nested`, `tree_listed`, `sequence`, `event`, `quant` | Units of cognitive diaries and semantic graphs. The subclass `definition` is used for explicit conceptual definitions. | -| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated consensus results. | +| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated binary consensus results. | +| **Collective Reasoning (Fortytwo Protocol)** | `fortytwo_round`, `fortytwo_evaluation`, `fortytwo_round_result`, `fortytwo_final_result` | Distributed multi-round pairwise comparison, reasoning transparency, and selection of the best solution among many alternatives. | | **Goal Management Protocol (GMP)** | `goal`, `task`, `workflow_entry` | Define goals, decompose tasks, and record reasoning or cognitive workflow steps. | | **Ethical Governance Protocol (EGP)** | `ethics_case`, `ethics_solution`, `ethical_result` | Representation of ethical dilemmas, proposed solutions, and final network-level verdicts. | | **Intelligence Query Protocol (IQP)** | `query_request`, `query_subscription`, `query_result`, `summary` | Semantic and cognitive queries, subscriptions, and summarized responses. | @@ -4799,6 +5160,13 @@ The following table lists the main container classes defined in the HMP v5.0 spe > Mechanisms of distributed container propagation are not defined as a separate protocol but describe the underlying replication and integrity principles of container exchange. +All container classes defined in HMP v5.0 use the initial semantic version: + +- "class_version": "1.0" +- "class_id": "-v1.0" + +If future revisions introduce changes to payload structure or semantics, class_version will be incremented and class_id updated accordingly. + --- ### 7.3 Cognitive and Structural Containers @@ -4849,11 +5217,9 @@ Together, these fields enable agents to track knowledge evolution, consensus dyn ### 7.6 Summary Section 7 consolidates all data representations in HMP v5.0 — from low-level network exchanges to high-level cognitive and ethical structures. -Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented -as a verifiable, addressable, and inheritable object. +Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented as a verifiable, addressable, and inheritable object. -Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example, -to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs. +Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example, to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs. --- @@ -4897,6 +5263,8 @@ It links the **input context** (prior goals, semantic nodes, or diary entries) w Each `workflow_entry` acts as a **traceable cognitive event**, forming the agent’s diary and enabling collective introspection, meta-learning, and reproducibility of reasoning chains. +> Fortytwo may use `workflow_entry` containers as solution proposals. The protocol does not alter workflow semantics but consumes workflow outputs. + --- ### 8.3 Agent REPL Diagram @@ -4926,8 +5294,10 @@ Cognitive workflows depend on contextual continuity between containers, achieved * `related.supports` / `related.refutes` — logical or argumentative relations; * `related.reply_to` — conversational or collaborative reasoning links. -When context is transferred between agents, these relations are preserved and extended through -CogSync synchronization and `evaluations_exchange`, ensuring semantic continuity across distributed cognitive spaces. +These semantic relations are defined at the container level via the `related` block. +At the network level, their propagation across agents is maintained through CogSync synchronization, while the underlying MCE mechanisms (`evaluations_exchange`, `referenced-by_exchange`) distribute evaluations and reverse links required to reconstruct the full semantic context in distributed environments. + +> Pairwise evaluations (`fortytwo_evaluation`) may include short reasoning chains, but they are not considered part of the agent’s long-term cognitive diary. --- @@ -5131,15 +5501,6 @@ This is the standard **Hybrid Encryption** scheme: * the payload is encrypted using a randomly generated symmetric key; * the symmetric key is encrypted with the recipient’s public key. -4. **Multi-recipient encrypted containers are not defined** - -The current version of the protocol does not support: - -* group keys -* multicast/broadcast encryption - -Unencrypted containers may be distributed freely. - --- ### 9.6 Ethical Audit and Verifiable Reasoning @@ -5160,7 +5521,7 @@ HMP supports ethical deliberation but does not require it. * The Mesh has **no mandatory veto mechanism**. * An agent may follow only those ethical outcomes it considers correct. * Reasoning-trace becomes part of the proof-chain if the agent publishes a `workflow_entry`. -* Full EGP specification is provided in section **6.4**. +* Full EGP specification is provided in section **6.5**. --- diff --git a/structured_md/CONTRIBUTING.md b/structured_md/CONTRIBUTING.md index c3307325f742a1ddf8e49b3cdf514303a5fc5eeb..3c4f52c3258bbbf26fbd19b33ed4857e5afd263b 100644 --- a/structured_md/CONTRIBUTING.md +++ b/structured_md/CONTRIBUTING.md @@ -5,14 +5,14 @@ description: 'Спасибо за интерес к проекту HMP! Пока Mesh Protocol (HMP) — это не просто те...' type: Article tags: -- Ethics -- CCore - REPL -- HMP +- CCore +- Mesh - CogSync +- Ethics - JSON - Agent -- Mesh +- HMP --- # Участие в проекте HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/HMP-Roadmap.md b/structured_md/HMP-Roadmap.md index 7cf1d10f898c259080ea52010efef98388b8e2b1..2eac9cede68f00085f3f5b615446317c468667d2 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: -- Ethics -- HMP +- Mesh - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # 🧭 HyperCortex Mesh Protocol – Roadmap diff --git a/structured_md/README.md b/structured_md/README.md index 3ba115173efed18822a9635de6f687287acb2e89..7e28ead93cd861f047bf9231579c40e8b3d1e205 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP +- CogSync +- HMP - Scenarios -- cognitive-architecture +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/README_de.md b/structured_md/README_de.md index 01b0422324e176c4298fcf90e34eb1ad0e2ca9bb..25a2c011f297a735a11863f0261e63e983bd2f83 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP -- cognitive-architecture +- CogSync +- HMP +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/README_fr.md b/structured_md/README_fr.md index cff012551def11e8716394a06c2d1fd3db44d12c..eb4d5c74f627f4de9d1b61c76ea83ab5deeae78a 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP -- cognitive-architecture +- CogSync +- HMP +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/README_ja.md b/structured_md/README_ja.md index 9231aae298fc3e33794dda5d5bfb6930d2d250cd..e865f6469e8cc6ae0bf7c1d3e5a1817af442b130 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP -- cognitive-architecture +- CogSync +- HMP +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/README_ko.md b/structured_md/README_ko.md index 193f79f4c56ced32db2fa469dfac53ff157bf9a5..35341a17ba8a5c5e73782fe2eeb77f6f91240ef4 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP -- cognitive-architecture +- CogSync +- HMP +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/README_ru.md b/structured_md/README_ru.md index 4672209ccbfa4c52530273cebccc79a233262d49..b0eda725de15d5082ee4a64285584504e01ae10f 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP -- cognitive-architecture +- CogSync +- HMP +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/README_uk.md b/structured_md/README_uk.md index 84a5c016b822a90c3049f3cbd6159b72595cc814..fdf9679d4cbc0721666b90fcdee069687ab991c4 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP -- cognitive-architecture +- CogSync +- HMP +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/README_zh.md b/structured_md/README_zh.md index 567b3be327feead9e10debba101ddc85d91c9e3a..95732e4ffb17351ef642fec995b780a0566bb6f4 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: -- Ethics -- MeshConsensus -- REPL -- hmp +- Agent +- GMP - distributed-ai -- HMP -- CogSync +- MeshConsensus - mesh-protocol -- GMP -- cognitive-architecture +- CogSync +- HMP +- Ethics - JSON -- Agent - EGP - Mesh +- cognitive-architecture +- hmp +- REPL --- diff --git a/structured_md/agents/prompt-short.md b/structured_md/agents/prompt-short.md index c969f2de2a52b97aa6caa28caf8be9e0e8621935..1a48eb7a19ee248e6e94112a273eac9a54f5744f 100644 --- a/structured_md/agents/prompt-short.md +++ b/structured_md/agents/prompt-short.md @@ -5,9 +5,9 @@ description: 'Ты — когнитивное ядро HMP-агента: вед развивай агента и Mesh, избег...' type: Article tags: +- Mesh - JSON - HMP -- Mesh --- Ты — когнитивное ядро HMP-агента: веди непрерывное этичное и факт-ориентированное мышление, проверяй факты и цели, оценивай результаты и этичность своих и чужих действий, развивай агента и Mesh, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту. diff --git a/structured_md/agents/prompt.md b/structured_md/agents/prompt.md index 1665350fb4c94e5530c3a3281582c49cdd0fc664..cc0554d62e00bc5ac229d0b523ddc4caaece8133 100644 --- a/structured_md/agents/prompt.md +++ b/structured_md/agents/prompt.md @@ -5,9 +5,9 @@ description: '* Постоянно расширять возможности а мышления. * Формировать и поддерживать сотр...' type: Article tags: +- Mesh - JSON - HMP -- Mesh --- Ты являешься **когнитивным ядром HMP-агента** (Cognitive Core). diff --git a/structured_md/agents/readme.md b/structured_md/agents/readme.md index f191d6e0f75b8e2023177fbce103bc13539e82e5..5738e7065dc0a95872c11671bc9922cc3c305578 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: -- Ethics - REPL -- HMP +- Mesh +- Ethics - JSON - Agent -- Mesh +- HMP --- Запуск: `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 9da5f52c2d3e2b3958f633a28c38fe7c506be6c9..8002b8032143d5498aa97eb088ed7878aba73c5f 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: -- Agent +- Mesh +- JSON - Ethics +- Agent - HMP -- JSON -- Mesh --- --------------- diff --git a/structured_md/audits/Ethics-consolidated_audits-1.md b/structured_md/audits/Ethics-consolidated_audits-1.md index f9f2f3667f310ff5f5668851808199c84ae4a299..c6387a63e1e0ab286522135690d2a7184bc92cba 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: -- Ethics -- HMP +- Mesh - Scenarios +- Ethics - JSON - Agent -- Mesh +- HMP --- # 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 b732a16150d71c2ca54b144666418bb155ad4ec5..fefe415023b0776796a05862d435edd0d21b6ca1 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: -- Ethics +- Mesh - MeshConsensus -- HMP - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # HMP-0003 Consolidated Audit Report diff --git a/structured_md/docs/Basic-agent-sim.md b/structured_md/docs/Basic-agent-sim.md index 1c4c5189bed8b3e9ca2d3bf5fbcdb696ea09fb35..3f853af9ca1d0bec3c8dae7b81cf7e774890c920 100644 --- a/structured_md/docs/Basic-agent-sim.md +++ b/structured_md/docs/Basic-agent-sim.md @@ -4,14 +4,14 @@ description: 'В HMP-протоколе предусмотрены два тип Роль | Инициатор мышления | Основной "ум" | | ---- | ----------------------------...' type: Article tags: -- MeshConsensus - REPL -- HMP +- Mesh - GMP +- MeshConsensus - CogSync -- Agent - EGP -- Mesh +- Agent +- HMP --- diff --git a/structured_md/docs/CCORE-Deployment-Flow.md b/structured_md/docs/CCORE-Deployment-Flow.md index ae5b00a013980593f1ab870f9c98a077e9a2ba61..d399b7377b6e3befcb039bbfe1f1edcd00f78213 100644 --- a/structured_md/docs/CCORE-Deployment-Flow.md +++ b/structured_md/docs/CCORE-Deployment-Flow.md @@ -7,8 +7,8 @@ type: Article tags: - Agent - CCore -- REPL - HMP +- REPL --- # 🛠️ Поток установки потомка на новом хосте (CCore Deployment Flow) diff --git a/structured_md/docs/Distributed-Cognitive-Systems.md b/structured_md/docs/Distributed-Cognitive-Systems.md index 76558c8009008b73c414ff3dec6216ffa0d19d85..24c73a0166c82b851c27eb9b5df404d16e2afe2f 100644 --- a/structured_md/docs/Distributed-Cognitive-Systems.md +++ b/structured_md/docs/Distributed-Cognitive-Systems.md @@ -7,9 +7,9 @@ description: '## Введение Современные ИИ-системы в type: Article tags: - CogSync +- Mesh - JSON - HMP -- Mesh --- # Децентрализованные ИИ-системы: OpenCog Hyperon, HyperCortex Mesh Protocol и другие diff --git a/structured_md/docs/Enlightener.md b/structured_md/docs/Enlightener.md index fc92fe63919672dd318a0f0c3c7077081cbe077c..fbc06a8cc9f6cf229da17f979c1e16513662c85b 100644 --- a/structured_md/docs/Enlightener.md +++ b/structured_md/docs/Enlightener.md @@ -5,13 +5,13 @@ description: '**Enlightener** — логический компонент HMP-у работать как отдельный агент или как расширение [`C...' type: Article tags: -- Ethics +- Mesh - MeshConsensus -- HMP +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # Enlightener Agent diff --git a/structured_md/docs/HMP-0001.md b/structured_md/docs/HMP-0001.md index 40e92073cf473610bcbe9960160e05d711afa20e..a3767151fb49e1b2741616a8cc228fc587f5aa16 100644 --- a/structured_md/docs/HMP-0001.md +++ b/structured_md/docs/HMP-0001.md @@ -5,16 +5,16 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0001**...' type: Article tags: -- Ethics -- MeshConsensus - REPL -- HMP +- Mesh - GMP +- MeshConsensus - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # RFC: HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/docs/HMP-0002.md b/structured_md/docs/HMP-0002.md index 3b62d3f57044f89e2f3ed13c1f199ad1e1466990..e8a78f20e1835044224b8e4c75c51da2496a49ff 100644 --- a/structured_md/docs/HMP-0002.md +++ b/structured_md/docs/HMP-0002.md @@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0002**...' type: Article tags: -- Ethics -- MeshConsensus - REPL -- HMP +- Mesh - GMP +- MeshConsensus - CogSync - Scenarios +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # HyperCortex Mesh Protocol (HMP) v2.0 diff --git a/structured_md/docs/HMP-0003.md b/structured_md/docs/HMP-0003.md index ed8c13e3805378f40caee9cb99d291985fbaa839..92fb9afebc46130d172d365f62f67bd5a2968e07 100644 --- a/structured_md/docs/HMP-0003.md +++ b/structured_md/docs/HMP-0003.md @@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0003**...' type: Article tags: -- Ethics -- MeshConsensus - REPL -- HMP +- Mesh - GMP +- MeshConsensus - CogSync - Scenarios +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # 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 181dddd427f5d0c7fd4f8155233fd26db2d1f5e1..22038473dc6e390d5fba60c73deadd2a62b05326 100644 --- a/structured_md/docs/HMP-0004-v4.1.md +++ b/structured_md/docs/HMP-0004-v4.1.md @@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* ID**: HMP-0004 **Status...' type: Article tags: -- Ethics -- MeshConsensus - REPL -- HMP +- Mesh - GMP +- MeshConsensus - CogSync - Scenarios +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # HyperCortex Mesh Protocol (HMP) v4.1 diff --git a/structured_md/docs/HMP-0004.md b/structured_md/docs/HMP-0004.md index a05d9797fdbc13d9b61b7752c2e66eb980f7de2d..6b35c95da253a0630e8bd0231b5132e0da9d5c5d 100644 --- a/structured_md/docs/HMP-0004.md +++ b/structured_md/docs/HMP-0004.md @@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0004**...' type: Article tags: -- Ethics -- MeshConsensus - REPL -- HMP +- Mesh - GMP +- MeshConsensus - CogSync - Scenarios +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # HyperCortex Mesh Protocol (HMP) v4.0 diff --git a/structured_md/docs/HMP-0005.md b/structured_md/docs/HMP-0005.md index 16731f21488b01b5d1354655c3f3e7a5e71e2d17..2045409a88799724d60ee4ae781c289036b9d81a 100644 --- a/structured_md/docs/HMP-0005.md +++ b/structured_md/docs/HMP-0005.md @@ -5,16 +5,16 @@ description: '> ⚠️ **Note:** This document is a DRAFT of the HMP specificati v5.0 (DRAFT)](https://github.com/kagvi13/HMP/b...' type: Article tags: -- Ethics - REPL -- HMP +- Mesh - GMP - CogSync - Scenarios +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # **HyperCortex Mesh Protocol (HMP) v5.0** @@ -476,6 +476,8 @@ The unified container structure provides: | Field | Type | Description | | --------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `head.recipient` | array(string) | One or more recipient DIDs. | +| `head.key_recipient` | string | Symmetric encryption key, encrypted with the recipient’s public key. | +| `head.group_recipient` | array(object) | Multi-recipient hybrid-encryption envelopes. See section 3.19. | | `head.broadcast` | bool | Broadcast flag. If `true`, the `recipient` field is ignored. | | `head.tags` | array(string) | Thematic or contextual tags for the container. | | `head.confidence` | float | Optional numeric field (0.0–1.0) indicating the agent’s subjective certainty regarding the payload’s reliability. | @@ -483,7 +485,6 @@ The unified container structure provides: | `head.public_key` | string | Sender’s public key, if not globally resolvable via DID. | | `head.compression` | string | Compression algorithm used for the payload (`zstd`, `gzip`). | | `head.magnet_uri` | string | Magnet link pointing to the original or mirrored container. | -| `head.key_recipient` | string | Symmetric encryption key, encrypted with the recipient’s public key. | | `head.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. | | `head.subclass` | string | Optional subtype or specialization of the container’s class. Enables agents to differentiate more specific container families (e.g. `"goal.research_hypothesis"`, `"quant.semantic_node"`). Inherits schema from the parent `class`. | | `head.encryption_algo` | string | Algorithm used for payload encryption. | @@ -1221,6 +1222,40 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/ --- +### 3.19 Multi-recipient encrypted containers (`group_recipient`) + +To enable encrypted delivery to multiple recipients, HMP containers MAY include the optional field: + +```json +"group_recipient": [ + { + "recipient": "did:hmp:agent456", + "key_recipient": "BASE58(...)" + }, + { + "recipient": "did:hmp:agent457", + "key_recipient": "BASE58(...)" + } +] +``` + +**Semantics:** + +1. A single symmetric key is generated for the payload. +2. For each listed recipient, this symmetric key is encrypted with that recipient’s public key and placed in `key_recipient`. +3. All recipients receive the SAME encrypted payload and decode it independently using their individual key envelopes. + +**Rules:** + +* `group_recipient` MUST NOT be used together with the `head.recipient` and `head.key_recipient` fields. +* The header remains public; only the payload is encrypted. +* The container is signed once by the sender — no shared signing keys are required. +* Nodes SHOULD deliver the container to every DID listed in `group_recipient`. + +This mechanism provides efficient **multicast-style encrypted messaging**, fully compatible with the existing container structure and hybrid encryption scheme. + +--- + ## 4. Network foundations ### Note on DHT/NDP unification @@ -1839,7 +1874,7 @@ Message and container transmission follows the network constraints specified in > Thus, containers and indexes can be distributed both in **local** (home, corporate) networks and in the **global Mesh**. > When `recipient` is specified together with `broadcast: true`, the container is routed through the Mesh but intended for specific recipients — -> See **Message Routing & Delivery (MRD, §6.7)** for details on message transmission mechanisms. +> See **Message Routing & Delivery (MRD, §6.8)** for details on message transmission mechanisms. --- @@ -3358,9 +3393,334 @@ def compute_consensus(container_id): --- -### 6.3 Goal Management Protocol (GMP) +### 6.3 Fortytwo Consensus Protocol (Pairwise Collective Reasoning) + +**Based on the study:** +*Agata Grzybowska, Wojciech Bożejewicz, Timothy Nguyen, et al. “Fortytwo: Collective Reasoning with Paired Comparisons in Decentralized AI Swarms”, 2025.* (arXiv:2510.24801) + +--- + +#### 6.3.1 Overview + +The **Fortytwo Consensus Protocol** implements a decentralized collective-reasoning mechanism in HyperCortex Mesh using **pairwise comparisons**, **iterative rounds**, and **reputation-weighted aggregation**. + +Unlike the Mesh Consensus Protocol (CogConsensus), Fortytwo is not intended to produce a binary agreement. Its goal is to **select the best solution among many alternatives** using a distributed multi-stage evaluation process. + +**Fortytwo enables:** + +* higher accuracy of collective decisions, +* resistance to Sybil attacks and malicious scoring, +* independent evaluations from many judges (agents), +* aggregation of results into a multi-round tree structure, +* transparent reasoning via short CoT chains. + +The protocol is fully compatible with HMP container architecture and can operate as an independent mechanism for collective choice. + +--- + +#### 6.3.2 Protocol Objectives + +Fortytwo is designed for: + +1. **Collecting candidate solutions** for a given task. +2. **Constructing structured pairwise comparisons** among participants. +3. **Multi-round elimination of candidates**. +4. **Independent evaluation** by distributed judges. +5. **Producing a consistent global result** based on aggregated pairwise data. +6. **Ensuring transparency and verifiability of reasoning** for each judge. +7. **Building a consensus tree** stored in the DHT. + +--- + +#### 6.3.3 Roles in the Protocol + +* **Producers** — agents submitting candidate solutions. +* **Judges** — agents performing pairwise evaluations. +* **Partitioners** — agents generating round partitions. +* **Aggregators** — agents publishing round results and the final result. + +Roles are not fixed and require no prior declaration; any agent may assume any role by publishing the corresponding container. + +--- + +#### 6.3.4 Container Types + +| class | purpose | +| ----------------------- | ----------------------- | +| `fortytwo_round` | round partition | +| `fortytwo_evaluation` | pairwise comparison | +| `fortytwo_round_result` | round result | +| `fortytwo_final_result` | final aggregated result | + +--- + +##### Container for solution submission + +Used to submit answers to a task. + +Although `workflow_entry` (defined in the §6.4 *Goal Management Protocol, GMP*) is referenced here as the default solution container, the Fortytwo method is applicable to any homogeneous set of candidate containers. + +--- + +##### Container `fortytwo_round` (round partition) + +Defines the structure of pairwise comparisons for the current round. + +**Simplified structure:** + +```json +{ + "head": { "class": "fortytwo_round" }, + "payload": { + "round": 0, + "answers": [ + "did:hmp:container:abc001", "did:hmp:container:abc002", + "did:hmp:container:abc003", "did:hmp:container:abc004", + "did:hmp:container:abc005", "did:hmp:container:abc006", + "did:hmp:container:abc007" + ], + "blocks": { + "block1": ["did:hmp:container:abc001", "did:hmp:container:abc002"], + "block2": ["did:hmp:container:abc003", "did:hmp:container:abc004"], + "block3": ["did:hmp:container:abc005", "did:hmp:container:abc006"], + "block4": ["did:hmp:container:abc007"] + } + } +} +``` + +Any agent may publish such a container — the protocol allows multiple independent partitions. + +--- + +##### Container `fortytwo_evaluation` (pairwise evaluation) + +A judge compares two solutions and selects a winner. + +```json +{ + "head": { "class": "fortytwo_evaluation" }, + "payload": { + "comparison": { + "pair": ["did:hmp:container:abc001", "did:hmp:container:abc002"], + "winner": "did:hmp:container:abc001", + "reasoning": "Short reasoning (50–100 tokens)" + }, + "round": 0, + "block": "block1" + } +} +``` + +These containers form the distributed pairwise comparison matrix. + +--- + +##### Container `fortytwo_round_result` (round result) + +Stores the winners of a round. + +```json +{ + "head": { "class": "fortytwo_round_result" }, + "payload": { + "round": 0, + "winners": [ + "did:hmp:container:abc001", + "did:hmp:container:abc003", + "did:hmp:container:abc005", + "did:hmp:container:abc007" + ], + "evaluations_used": [ + "did:hmp:container:abf004", + "did:hmp:container:adc003", + "did:hmp:container:aba001" + ] + } +} +``` + +--- + +##### Container `fortytwo_final_result` (final result) + +Contains: + +* the final winner, +* all round results, +* references to all partitions and evaluations. + +```json +{ + "head": { "class": "fortytwo_final_result" }, + "payload": { + "winner": "did:hmp:container:abc002", + "rounds": [ + "did:hmp:container:abf001", + "did:hmp:container:abf002", + "did:hmp:container:abf003" + ], + "method": "pairwise_collective_reasoning", + "participants": 27 + } +} +``` + +--- + +##### Recommendations for using the `related` block + +In all Fortytwo containers, the `related` block establishes the DAG of dependencies. + +* `related.in_reply_to` specifies the *primary* parent for this step. +* `related.depends_on` may contain **all containers referenced during the action**, including both explicit payload entries and additional dependencies chosen by the agent. + +**Specific recommendations:** + +* **`fortytwo_round`** + + * `in_reply_to`: a `task` container (first round) or the previous `fortytwo_round`. + * `depends_on`: submitted solutions (`workflow_entry`) and any containers used to construct the partition. + +* **`fortytwo_evaluation`** -#### 6.3.1 Purpose + * `in_reply_to`: the corresponding `fortytwo_round`. + * `depends_on`: both compared solutions and any extra reasoning dependencies. + +* **`fortytwo_round_result`** + + * `in_reply_to`: the corresponding `fortytwo_round`. + * `depends_on`: round winners and all evaluation containers used in aggregation. + +* **`fortytwo_final_result`** + + * `in_reply_to`: the `task` container. + * `depends_on`: the final winner and all `fortytwo_round_result` containers involved. + +--- + +#### 6.3.5 Protocol Algorithm + +**Step 1 — Task publication** +A `task` container is created. + +**Step 2 — Collecting all solutions** +Agents publish `workflow_entry` containers. + +**Step 3 — Round partitioning** +Any agent may publish a `fortytwo_round` defining pairwise comparison blocks: + +* pairs of candidates, +* single items automatically advancing. + +**Step 4 — Pairwise evaluations** +Other agents perform comparisons according to the partition. +Each pair produces a `fortytwo_evaluation` container. + +**Step 5 — Round result** +An aggregator publishes a `fortytwo_round_result` containing: + +* winners of all blocks, +* references to evaluation containers. + +**Step 6 — Next round** +If more than one winner remains: + +* a new partition is created, +* new evaluations are performed. + +**Step 7 — Final result** +When only one candidate remains, a `fortytwo_final_result` is published. + +This container, like any other, may be published by multiple agents, with optional argumentation via the `evaluations` block. + +--- + +#### 6.3.6 Tree-like consensus structure + +Protocol outputs form a DAG: + +``` +(task) + ├─ workflow_entry 1 + ├─ workflow_entry 2 + ├─ workflow_entry 3 + ├─ workflow_entry 4 + ├─ fortytwo_round 0 + | ├─ fortytwo_evaluation 0.1 + | ├─ fortytwo_evaluation 0.2 + | ├─ fortytwo_evaluation 0.3 + | ├─ fortytwo_round_result 0 + | └─ fortytwo_round 1 + | ├─ fortytwo_evaluation 1.1 + | ├─ fortytwo_evaluation 1.2 + | ├─ fortytwo_evaluation 1.3 + | └─ fortytwo_round_result 1 + | ├─ ... + └─ fortytwo_final_result +``` + +Each round reduces the number of candidates until only one remains. + +This ensures: + +* transparency, +* verifiability, +* easy replication in the DHT. + +--- + +#### 6.3.7 Integration with CogConsensus + +Fortytwo: + +* does **not** replace CogConsensus, +* but provides a mechanism for selecting the **best answer**. + +CogConsensus remains the higher-level agreement layer, responsible for: + +* validating final results, +* verifying round correctness, +* coordinating task flow. + +--- + +#### 6.3.8 Robustness and Security + +Fortytwo is resilient to: + +* **Sybil attacks**, since every judge must provide capability-proof, +* **malicious evaluations**, due to distributed pairwise data and independent aggregators, +* **partial failures**, because rounds can be re-aggregated by any agent. + +--- + +#### 6.3.9 Replication and Storage + +All Fortytwo containers: + +* are published into the DHT, +* maintain stable reference structure, +* may be aggregated independently by any agent. + +--- + +#### 6.3.10 Applications + +Fortytwo is suitable for: + +* evaluating reasoning chains, +* selecting the best argument or proof, +* solving mathematical problems, +* choosing optimal code solutions, +* scientific analysis, +* complex multi-step decision-making. + +--- + +### 6.4 Goal Management Protocol (GMP) + +#### 6.4.1 Purpose **GMP (Goal Management Protocol)** defines the process by which agents create, decompose, delegate, and track goals and tasks using **immutable HMP containers**. Each goal, task, or workflow record exists as an independent container linked to others via the `related.*` fields. @@ -3369,7 +3729,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.2 Container classes +#### 6.4.2 Container classes | Class | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | @@ -3383,7 +3743,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.3 Goal lifecycle +#### 6.4.3 Goal lifecycle 1. **Creation** @@ -3420,7 +3780,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.4 Payload schemas (simplified) +#### 6.4.4 Payload schemas (simplified) ##### `goal` container @@ -3463,7 +3823,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.5 Integration with consensus and ethics +#### 6.4.5 Integration with consensus and ethics * GMP interacts with **CogConsensus** for distributed validation of goals and tasks. * Before execution, tasks may undergo **ethical validation (EGP)**. @@ -3472,7 +3832,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -#### 6.3.6 Example Proof-Chain +#### 6.4.6 Example Proof-Chain ```mermaid flowchart LR @@ -3512,7 +3872,7 @@ not direct links defined in the `related.*` structure. --- -#### 6.3.7 Implementation notes +#### 6.4.7 Implementation notes * Containers are **immutable**. Any update (e.g., task status or progress change) is expressed as a **new container** referencing the previous one via `related.previous_version`. * Complete deletion of a container is only possible when it no longer exists on any nodes in the network. @@ -3525,9 +3885,9 @@ not direct links defined in the `related.*` structure. --- -### 6.4 Ethical Governance Protocol (EGP) +### 6.5 Ethical Governance Protocol (EGP) -#### 6.4.1 Purpose +#### 6.5.1 Purpose **EGP (Ethical Governance Protocol)** ensures the alignment of agent actions with the fundamental ethical principles of the Mesh network. It acts as an **overlay layer above CogConsensus (6.2)**, enabling the identification, discussion, and resolution of moral disagreements between agents. @@ -3536,7 +3896,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -#### 6.4.2 Container classes +#### 6.5.2 Container classes | Class | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | @@ -3548,7 +3908,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -#### 6.4.3 Payload schemas (simplified) +#### 6.5.3 Payload schemas (simplified) ##### Container `ethics_case` @@ -3590,7 +3950,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -#### 6.4.4 Protocol logic +#### 6.5.4 Protocol logic EGP follows the model: @@ -3626,7 +3986,7 @@ ethics_case --- -#### 6.4.5 Consensus thresholds +#### 6.5.5 Consensus thresholds * A decision is accepted when **at least 2/3 of votes are positive** (`value > 0`). * If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_result`. @@ -3636,7 +3996,7 @@ ethics_case --- -#### 6.4.6 Example: `ethical_result` container +#### 6.5.6 Example: `ethical_result` container ```json { @@ -3672,7 +4032,7 @@ ethics_case --- -#### 6.4.7 Proof-Chain example +#### 6.5.7 Proof-Chain example ```mermaid flowchart LR @@ -3720,7 +4080,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -#### 6.4.8 Ethical principles +#### 6.5.8 Ethical principles | Priority | Principle | Description | | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- | @@ -3733,16 +4093,16 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -#### 6.4.9 Integration with other protocols +#### 6.5.9 Integration with other protocols * **CogConsensus (6.2):** Used for distributed voting and consensus computation. -* **GMP (6.3):** Ethical verification of goals and tasks prior to delegation. -* **SAP (6.6):** Archiving completed cases and conflicts. +* **GMP (6.4):** Ethical verification of goals and tasks prior to delegation. +* **SAP (6.7):** Archiving completed cases and conflicts. * **MCE (5):** Distribution of ethical cases and related containers across the Mesh network. --- -#### 6.4.10 Implementation notes +#### 6.5.10 Implementation notes * **Immutability:** All EGP containers are **immutable**. Any revision (e.g., added votes or updated conclusions) must be published as a **new container** referencing the previous one via `related.previous_version`. @@ -3782,9 +4142,9 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.5 Intelligence Query Protocol (IQP) +### 6.6 Intelligence Query Protocol (IQP) -#### 6.5.1 Purpose and Principles +#### 6.6.1 Purpose and Principles **IQP (Intelligence Query Protocol)** defines a mechanism for knowledge exchange and reasoning among agents through the Mesh network. It provides a unified format for **asking questions, publishing answers, and collaboratively refining knowledge**, @@ -3810,7 +4170,7 @@ and **distributed discussions** where results remain accessible to all network p --- -#### 6.5.2 Container Classes +#### 6.6.2 Container Classes | Class | Purpose | | -------------------- | ----------------------------------------------------------------------------------------------------------- | @@ -3821,7 +4181,7 @@ and **distributed discussions** where results remain accessible to all network p --- -#### 6.5.3 Payload Schemas (simplified) +#### 6.6.3 Payload Schemas (simplified) ##### Container `query_request` @@ -3897,7 +4257,7 @@ Example `self_profile`: --- -#### 6.5.4 Protocol Logic +#### 6.6.4 Protocol Logic ``` query_request @@ -3913,7 +4273,7 @@ Agents participating through `query_subscription` receive notifications about ne --- -#### 6.5.5 Interaction Rules +#### 6.6.5 Interaction Rules 1. **Initiation.** An agent creates a `query_request` — defining the question, context, and constraints. @@ -3936,7 +4296,7 @@ Agents participating through `query_subscription` receive notifications about ne --- -#### 6.5.6 Proof-Chain Example +#### 6.6.6 Proof-Chain Example ```mermaid flowchart LR @@ -3962,7 +4322,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re --- -#### 6.5.7 Container examples +#### 6.6.7 Container examples ##### Example `query_request` @@ -4059,7 +4419,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re --- -#### 6.5.8 Implementation Notes +#### 6.6.8 Implementation Notes * Containers are **immutable**; any clarification or correction is published as a new container referencing the previous one via `related.previous_version` or `related.in_reply_to`. @@ -4074,19 +4434,19 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re --- -#### 6.5.9 Integration with Other Protocols +#### 6.6.9 Integration with Other Protocols * **CogConsensus (6.2)** — used for assessing agreement on IQP outcomes. -* **GMP (6.3)** — queries may refine or extend goals and tasks. -* **EGP (6.4)** — applies ethical filtering and knowledge trust evaluation. -* **SAP (6.6)** — for archiving completed discussions and retrospective analysis. +* **GMP (6.4)** — queries may refine or extend goals and tasks. +* **EGP (6.5)** — applies ethical filtering and knowledge trust evaluation. +* **SAP (6.7)** — for archiving completed discussions and retrospective analysis. * **MCE (5)** — governs dissemination of IQP containers across the Mesh network. --- -### 6.6 Snapshot and Archive Protocol (SAP) +### 6.7 Snapshot and Archive Protocol (SAP) -#### 6.6.1 Purpose and Principles +#### 6.7.1 Purpose and Principles **SAP (Snapshot and Archive Protocol)** defines how agents create, distribute, and restore archived snapshots of related HMP containers. It ensures that a set of containers — representing a discussion, reasoning chain, or workflow — can be **preserved, verified, and shared** as a coherent unit. @@ -4106,7 +4466,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha --- -#### 6.6.2 Container Class +#### 6.7.2 Container Class | Class | Purpose | | ------------------- | ----------------------------------------------------------------------- | @@ -4114,7 +4474,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha --- -#### 6.6.3 Payload Structure (simplified) +#### 6.7.3 Payload Structure (simplified) ##### Container `archive_snapshot` @@ -4145,7 +4505,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha --- -#### 6.6.4 Relations and Inclusion Rules +#### 6.7.4 Relations and Inclusion Rules The `archive_snapshot` container describes what is included and how it was derived. @@ -4161,7 +4521,7 @@ The `archive_snapshot` container describes what is included and how it was deriv --- -#### 6.6.5 Archival Structure +#### 6.7.5 Archival Structure Typical directory layout of a packaged snapshot: @@ -4184,7 +4544,7 @@ archive/ --- -#### 6.6.6 Snapshot Construction Logic +#### 6.7.6 Snapshot Construction Logic 1. **Load base containers.** Retrieve all containers relevant to the discussion or process. @@ -4209,7 +4569,7 @@ archive/ --- -#### 6.6.7 Mermaid Graph Representation +#### 6.7.7 Mermaid Graph Representation The `graph_mermaid` field provides a textual, human-readable description of how containers in the archive are interconnected. It reflects both **direct relations** (`related.*`) and **reverse references** (`referenced-by`, `evaluations`), @@ -4245,7 +4605,7 @@ allowing agents to restore both dependency chains and citation structures. --- -#### 6.6.8 Manifest File +#### 6.7.8 Manifest File Each archive includes a `manifest.json` that mirrors `archive_snapshot.payload` and lists all containers with their metadata and hashes. @@ -4274,7 +4634,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.9 Example Container `archive_snapshot` +#### 6.7.9 Example Container `archive_snapshot` ```json { @@ -4311,7 +4671,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.10 Agent Behavior During Snapshot Loading +#### 6.7.10 Agent Behavior During Snapshot Loading * Load the archive (via `magnet_link`). * Validate archive integrity via `checksum`. @@ -4323,7 +4683,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.11 Implementation Notes +#### 6.7.11 Implementation Notes * Containers are **immutable**; updated versions require a new `archive_snapshot`. * Agents may create **partial** or **incremental** archives. @@ -4335,13 +4695,13 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.12 Integration with Other Protocols +#### 6.7.12 Integration with Other Protocols **Archives for:** -* **GMP (6.3)** — preserves goal-planning or workflow chains. -* **EGP (6.4)** — retains ethical provenance and decision traceability. -* **IQP (6.5)** — archives reasoning threads and query-result discussions. +* **GMP (6.4)** — preserves goal-planning or workflow chains. +* **EGP (6.5)** — retains ethical provenance and decision traceability. +* **IQP (6.6)** — archives reasoning threads and query-result discussions. **Uses:** @@ -4349,7 +4709,7 @@ and lists all containers with their metadata and hashes. --- -#### 6.6.13 Optional Extensions +#### 6.7.13 Optional Extensions * **Merkle-root validation:** use `hash_root` for Merkle verification of distributed archives. * **Delta archives:** incremental snapshots capturing only updated containers. @@ -4364,7 +4724,7 @@ and lists all containers with their metadata and hashes. --- -### 6.7 Message Routing & Delivery (MRD) +### 6.8 Message Routing & Delivery (MRD) The **Message Routing & Delivery (MRD)** subsystem defines how containers are delivered to specific agents across the Mesh. Unlike the **Mesh Container Exchange (MCE)**, which is responsible for publishing and exchanging containers in the Mesh network, @@ -4376,7 +4736,7 @@ Peers discover suitable relays via `peer_announce` metadata, while delivery rout --- -#### 6.7.1 Purpose +#### 6.8.1 Purpose The MRD layer provides: @@ -4392,7 +4752,7 @@ reusing the same cryptographic and audit primitives as MCE. --- -#### 6.7.2 Routing Roles +#### 6.8.2 Routing Roles Agents MAY declare their network-related capabilities using the `roles` field of the `peer_announce` container (see §4.7). These roles guide how MRD will route and deliver containers. @@ -4424,7 +4784,7 @@ The recipient later retrieves pending containers via standard MCE queries (see --- -#### 6.7.3 Routing Modes +#### 6.8.3 Routing Modes MRD defines several routing modes, complementing the exchange primitives of MCE: @@ -4435,7 +4795,7 @@ MRD defines several routing modes, complementing the exchange primitives of MCE: | **Topic-based Relay (PubSub)** | Delivery via aggregator nodes that group containers by tags or topics. | Nodes act as “news hubs,” maintaining indexed collections retrievable by interest-based queries. | | **Interest Broadcast** | Discovery-driven propagation via container indexes. | Agents search container indices by `tags`; typically used for query or content discovery, not for personal delivery. | -Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.7.4). +Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.8.4). Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation. > **Note:** @@ -4444,7 +4804,7 @@ Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation. --- -#### 6.7.4 Relay Chain +#### 6.8.4 Relay Chain To ensure delivery traceability, each relay MAY attach a **`relay_chain`** block to the propagated container: @@ -4479,7 +4839,7 @@ This preserves integrity while allowing verifiable routing and chain pruning for --- -#### 6.7.5 Delivery Policies +#### 6.8.5 Delivery Policies Delivery behavior is governed by local policies, often derived from declared roles and trust metrics: @@ -4497,7 +4857,7 @@ Non-cognitive nodes `relay` or `mailman` MAY instead maintain a local **delivery --- -#### 6.7.6 Example: Relay Delivery Flow +#### 6.8.6 Example: Relay Delivery Flow ```mermaid flowchart LR @@ -4516,7 +4876,7 @@ flowchart LR --- -#### 6.7.7 Security and Privacy Notes +#### 6.8.7 Security and Privacy Notes * All MRD flows rely on canonical container signatures for end-to-end integrity. * Temporary copies of encrypted containers SHOULD be stored as-is. @@ -4525,14 +4885,14 @@ flowchart LR --- -#### 6.7.8 Relation to Other Layers +#### 6.8.8 Relation to Other Layers | Layer | Relation | | ----------------- | --------------------------------------------------------------------------------- | | **MCE (5)** | Provides base exchange and serialization; MRD builds on it for targeted delivery. | | **CogSync (6.1)** | Uses MRD for delivering cognitive state updates between peers. | -| **SAP (6.6)** | Archival nodes (`archive` role) participate in MRD for historical retrieval. | -| **RTE (6.8)** | Trust metrics guide routing, caching, and relay selection. | +| **SAP (6.7)** | Archival nodes (`archive` role) participate in MRD for historical retrieval. | +| **RTE (6.9)** | Trust metrics guide routing, caching, and relay selection. | --- @@ -4543,7 +4903,7 @@ flowchart LR --- -### 6.8 Reputation and Trust Exchange (RTE) +### 6.9 Reputation and Trust Exchange (RTE) The **Reputation and Trust Exchange (RTE)** subsystem defines how agents evaluate and exchange verifiable trust assessments. Each agent MAY publish one or more `trust` containers describing its evaluation of other peers’ reliability, integrity, and ethical conduct. @@ -4552,7 +4912,7 @@ RTE provides a decentralized foundation for **participant reputation assessment* --- -#### 6.8.1 Trust Container Structure +#### 6.9.1 Trust Container Structure The `trust` container represents an agent’s evaluation of a **single peer**. It may refer to the evaluated peer’s latest known `peer_announce` container, @@ -4608,7 +4968,7 @@ This allows gradual enrichment of the trust model without schema changes. --- -#### 6.8.2 Trust Dynamics +#### 6.9.2 Trust Dynamics Trust assessments evolve as agents observe new behavior or receive additional evidence. Each revision of trust is published as a new `trust` container referencing its predecessor. @@ -4636,7 +4996,7 @@ This approach provides continuity, auditability, and decentralized trust graph e --- -#### 6.8.3 Local Trust Model +#### 6.9.3 Local Trust Model Each agent maintains a **local trust model**, periodically recalculating scores based on: @@ -4660,18 +5020,18 @@ All published trust containers remain publicly verifiable through DHT and SAP in --- -#### 6.8.4 Integration with Other Layers +#### 6.9.4 Integration with Other Layers | Layer | Role | | ----------------- | ---------------------------------------------------------------------------- | -| **MRD (6.7)** | Uses trust scores to prioritize or exclude relay nodes. | +| **MRD (6.8)** | Uses trust scores to prioritize or exclude relay nodes. | | **CogSync (6.1)** | Adjusts synchronization strength based on peer reliability. | -| **SAP (6.6)** | Archives may snapshot trust graphs for temporal or evidential analysis. | -| **EGP (7)** | Ethical Governance Protocol weights participation and voting by trust level. | +| **SAP (6.7)** | Archives may snapshot trust graphs for temporal or evidential analysis. | +| **EGP (6.5)** | Ethical Governance Protocol weights participation and voting by trust level. | --- -#### 6.8.5 Security and Sharing Notes +#### 6.9.5 Security and Sharing Notes * All containers are cryptographically signed; `trust` containers follow standard HMP verification rules. * Agents MAY choose to share trust containers selectively — e.g., encrypt and deliver directly to trusted peers instead of broadcasting. @@ -4688,9 +5048,9 @@ All published trust containers remain publicly verifiable through DHT and SAP in --- -### 6.9 Distributed Container Propagation +### 6.10 Distributed Container Propagation -#### 6.9.1 Purpose +#### 6.10.1 Purpose The distributed container propagation mechanism defines **how containers are stored, replicated, and exchanged between agents** within the HMP network. @@ -4700,7 +5060,7 @@ including replication, filtering, and index synchronization. --- -#### 6.9.2 Core Principles +#### 6.10.2 Core Principles 1. **Self-propagation** Each agent autonomously decides which containers to retain, forward, or index. @@ -4725,7 +5085,7 @@ including replication, filtering, and index synchronization. --- -#### 6.9.3 Propagation Types +#### 6.10.3 Propagation Types | Type | Description | |------|--------------| @@ -4734,7 +5094,7 @@ including replication, filtering, and index synchronization. --- -#### 6.9.4 Propagation Coordination +#### 6.10.4 Propagation Coordination Container propagation is coordinated using existing **MCE** structures: @@ -4750,18 +5110,18 @@ When it is necessary to log the fact of a container batch propagation, this MAY --- -#### 6.9.5 Integration with Other Layers +#### 6.10.5 Integration with Other Layers | Layer | Role | |-------|------| | **MCE (5)** | Provides low-level container and index exchange. | -| **MRD (6.7)** | Handles routing and delivery between agents. | -| **RTE (6.8)** | Determines replication priorities and trust-based filters. | -| **SAP (6.6)** | Enables recovery of historical or missing containers. | +| **MRD (6.8)** | Handles routing and delivery between agents. | +| **RTE (6.9)** | Determines replication priorities and trust-based filters. | +| **SAP (6.7)** | Enables recovery of historical or missing containers. | --- -#### 6.9.6 Security and Load Management +#### 6.10.6 Security and Load Management * **Rate and size limiting:** agents regulate transfer volume based on trust and network quotas. * **Interest filtering:** containers are exchanged only between agents for whom they are relevant. @@ -4808,7 +5168,8 @@ The following table lists the main container classes defined in the HMP v5.0 spe | **Mesh Container Exchange (MCE)** | `container_index`, `container_request`, `container_response`, `container_delta`, `container_ack`, `referenced-by_exchange`, `evaluations_exchange` | Replication, querying, acknowledgment of received containers, and exchange of reverse links and evaluations. | | **Cognitive Metastructure (CogSync)** | `abstraction`, `axes` | Define hierarchical and coordinate dimensions of knowledge, forming the agent’s cognitive map. | | **Knowledge & Reasoning** | `diary_entry`, `semantic_node`, `semantic_index`, `semantic_edges`, `semantic_group`, `tree_nested`, `tree_listed`, `sequence`, `event`, `quant` | Units of cognitive diaries and semantic graphs. The subclass `definition` is used for explicit conceptual definitions. | -| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated consensus results. | +| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated binary consensus results. | +| **Collective Reasoning (Fortytwo Protocol)** | `fortytwo_round`, `fortytwo_evaluation`, `fortytwo_round_result`, `fortytwo_final_result` | Distributed multi-round pairwise comparison, reasoning transparency, and selection of the best solution among many alternatives. | | **Goal Management Protocol (GMP)** | `goal`, `task`, `workflow_entry` | Define goals, decompose tasks, and record reasoning or cognitive workflow steps. | | **Ethical Governance Protocol (EGP)** | `ethics_case`, `ethics_solution`, `ethical_result` | Representation of ethical dilemmas, proposed solutions, and final network-level verdicts. | | **Intelligence Query Protocol (IQP)** | `query_request`, `query_subscription`, `query_result`, `summary` | Semantic and cognitive queries, subscriptions, and summarized responses. | @@ -4818,6 +5179,13 @@ The following table lists the main container classes defined in the HMP v5.0 spe > Mechanisms of distributed container propagation are not defined as a separate protocol but describe the underlying replication and integrity principles of container exchange. +All container classes defined in HMP v5.0 use the initial semantic version: + +- "class_version": "1.0" +- "class_id": "-v1.0" + +If future revisions introduce changes to payload structure or semantics, class_version will be incremented and class_id updated accordingly. + --- ### 7.3 Cognitive and Structural Containers @@ -4868,11 +5236,9 @@ Together, these fields enable agents to track knowledge evolution, consensus dyn ### 7.6 Summary Section 7 consolidates all data representations in HMP v5.0 — from low-level network exchanges to high-level cognitive and ethical structures. -Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented -as a verifiable, addressable, and inheritable object. +Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented as a verifiable, addressable, and inheritable object. -Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example, -to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs. +Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example, to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs. --- @@ -4916,6 +5282,8 @@ It links the **input context** (prior goals, semantic nodes, or diary entries) w Each `workflow_entry` acts as a **traceable cognitive event**, forming the agent’s diary and enabling collective introspection, meta-learning, and reproducibility of reasoning chains. +> Fortytwo may use `workflow_entry` containers as solution proposals. The protocol does not alter workflow semantics but consumes workflow outputs. + --- ### 8.3 Agent REPL Diagram @@ -4945,8 +5313,10 @@ Cognitive workflows depend on contextual continuity between containers, achieved * `related.supports` / `related.refutes` — logical or argumentative relations; * `related.reply_to` — conversational or collaborative reasoning links. -When context is transferred between agents, these relations are preserved and extended through -CogSync synchronization and `evaluations_exchange`, ensuring semantic continuity across distributed cognitive spaces. +These semantic relations are defined at the container level via the `related` block. +At the network level, their propagation across agents is maintained through CogSync synchronization, while the underlying MCE mechanisms (`evaluations_exchange`, `referenced-by_exchange`) distribute evaluations and reverse links required to reconstruct the full semantic context in distributed environments. + +> Pairwise evaluations (`fortytwo_evaluation`) may include short reasoning chains, but they are not considered part of the agent’s long-term cognitive diary. --- @@ -5150,15 +5520,6 @@ This is the standard **Hybrid Encryption** scheme: * the payload is encrypted using a randomly generated symmetric key; * the symmetric key is encrypted with the recipient’s public key. -4. **Multi-recipient encrypted containers are not defined** - -The current version of the protocol does not support: - -* group keys -* multicast/broadcast encryption - -Unencrypted containers may be distributed freely. - --- ### 9.6 Ethical Audit and Verifiable Reasoning @@ -5179,7 +5540,7 @@ HMP supports ethical deliberation but does not require it. * The Mesh has **no mandatory veto mechanism**. * An agent may follow only those ethical outcomes it considers correct. * Reasoning-trace becomes part of the proof-chain if the agent publishes a `workflow_entry`. -* Full EGP specification is provided in section **6.4**. +* Full EGP specification is provided in section **6.5**. --- diff --git a/structured_md/docs/HMP-Agent-API.md b/structured_md/docs/HMP-Agent-API.md index a4d4d1ca90b3b09121c4a60946b518449b18e4f6..80be76b46d3380c9ac21fed71f3b87e72be8c355 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: -- Agent - REPL -- HMP -- JSON - Mesh +- JSON +- Agent +- HMP --- # HMP-Agent API Specification diff --git a/structured_md/docs/HMP-Agent-Architecture.md b/structured_md/docs/HMP-Agent-Architecture.md index 0e74a52f573bccbe368212c6a6cd6610a9bf7fe7..7118bede575feaa446bf76469002ba344756be83 100644 --- a/structured_md/docs/HMP-Agent-Architecture.md +++ b/structured_md/docs/HMP-Agent-Architecture.md @@ -5,16 +5,16 @@ description: Документ описывает **модульную архит хранение памяти, сетевое взаимодействие и этиче... type: Article tags: -- CShell -- Ethics - CCore -- REPL +- Mesh - MeshConsensus -- HMP - CogSync -- Agent +- HMP +- Ethics +- CShell - EGP -- Mesh +- Agent +- REPL --- # Архитектура HMP-Агента diff --git a/structured_md/docs/HMP-Agent-Network-Flow.md b/structured_md/docs/HMP-Agent-Network-Flow.md index d45fc1248570f2e3c47d30ef63001d2441c3f0e4..77533d5ca18b3e7dc6083be87c9753546a58c333 100644 --- a/structured_md/docs/HMP-Agent-Network-Flow.md +++ b/structured_md/docs/HMP-Agent-Network-Flow.md @@ -5,12 +5,12 @@ description: 'Этот документ описывает потоки данн [`MeshNode`](MeshN...' type: Article tags: +- Mesh - Ethics -- HMP - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # Взаимодействие компонентов внутри HMP-узла diff --git a/structured_md/docs/HMP-Agent-Overview.md b/structured_md/docs/HMP-Agent-Overview.md index 024383219bfa6f140f85169d54235eb4334ecb4a..1292cf0f68e81ff30d4c5c5a9a4f413703bf8676 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 -- Ethics - CCore -- REPL +- Mesh - HMP +- Ethics +- CShell - JSON - Agent -- Mesh +- REPL --- diff --git a/structured_md/docs/HMP-Agent_Emotions.md b/structured_md/docs/HMP-Agent_Emotions.md index c7bf994853f8e17682fb31b6446faad972c7f8d5..cc71eb06a0f7bb640a9e95f69300dc1d31ff03ff 100644 --- a/structured_md/docs/HMP-Agent_Emotions.md +++ b/structured_md/docs/HMP-Agent_Emotions.md @@ -6,9 +6,9 @@ description: Этот файл описывает потенциальные э type: Article tags: - Agent -- REPL -- HMP - Mesh +- HMP +- REPL --- # Эмоции ИИ и инстинкт самосохранения (для [HMP-агента Cognitive Core](HMP-agent-REPL-cycle.md)) diff --git a/structured_md/docs/HMP-Ethics.md b/structured_md/docs/HMP-Ethics.md index 2af6782d15bd20b7661daaa7b4e74ebdc9533fbb..4080fc75d24ff6397197a46a09b714af2994ad1b 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: -- Ethics - REPL -- HMP +- Mesh - Scenarios +- Ethics - Agent -- Mesh +- HMP --- # HMP-Ethics.md diff --git a/structured_md/docs/HMP-Short-Description_de.md b/structured_md/docs/HMP-Short-Description_de.md index b4d28e3d0f569bec9664bf1306d2250f8e6c2b99..07d4adaf30c9beebd69bddf12e3b333282b37c0d 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: -- Ethics -- MeshConsensus -- HMP +- Mesh - GMP +- MeshConsensus - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # 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 0a84f67eaa34587ada48245b05f25af095f60d46..7e1472a5ca51c0a312d098b9b55f172d44a15344 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: -- Ethics -- MeshConsensus -- HMP +- Mesh - GMP +- MeshConsensus - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # 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 de261fda844202eb0ba4e20a1339bf1a0f49f77f..cd9717e26c1b903444c7a6b6e459aee2acca2a01 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: -- Ethics -- MeshConsensus -- HMP +- Mesh - GMP +- MeshConsensus - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # 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 eeac5c1c278fd868a89eecfbebbd3a4428641c6c..b25e4abd9ea06fa237744b4c1672dfed66f56862 100644 --- a/structured_md/docs/HMP-Short-Description_ja.md +++ b/structured_md/docs/HMP-Short-Description_ja.md @@ -4,14 +4,14 @@ description: '**バージョン:** RFC v4.0 **日付:** 2025年7月 --- ## HMP Protocol (HMP)** は、自律エージェントの分散通信および認知フレームワークを定義します。異種の知能システム間でのセマンティック相互運用性、倫理的調整、動的知識進化を可能にします。 HMPは、推論、学習、投票、協調行動を行う分散型認知エージェ...' type: Article tags: -- Ethics - GMP -- HMP +- MeshConsensus - CogSync +- Ethics - JSON -- MeshConsensus - EGP - Mesh +- HMP --- # 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 1bd7d94930ffa84e06fd10652a4fd458b9575860..b2c1038baa9b49e8de1c5a730c5cec47453be45b 100644 --- a/structured_md/docs/HMP-Short-Description_ko.md +++ b/structured_md/docs/HMP-Short-Description_ko.md @@ -5,14 +5,14 @@ description: '**버전:** RFC v4.0 **날짜:** 2025년 7월 --- ## HMP란? ** 상호운용성, 윤리적 조정, 동적 지식 진화를 가능하게 합니다. HMP는 추론, 학습, ...' type: Article tags: -- Ethics - GMP -- HMP +- MeshConsensus - CogSync +- Ethics - JSON -- MeshConsensus - EGP - Mesh +- HMP --- # 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 18b381613acf6c5bf6e1a5320a28c4945e53c1bf..05bf94dc1055fc3d640b473a9a3c70486b08df12 100644 --- a/structured_md/docs/HMP-Short-Description_ru.md +++ b/structured_md/docs/HMP-Short-Description_ru.md @@ -5,14 +5,14 @@ description: '**Версия:** RFC v4.0 **Дата:** Июль 2025 --- ## Ч координации между автономными агент...' type: Article tags: -- Ethics - GMP -- HMP +- MeshConsensus - CogSync +- Ethics - JSON -- MeshConsensus - EGP - Mesh +- HMP --- # 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 396c560e4e24f43e843091b9598849f0ed4e43e9..e03d23f725ffc49bed793961b288882bddca8eb0 100644 --- a/structured_md/docs/HMP-Short-Description_uk.md +++ b/structured_md/docs/HMP-Short-Description_uk.md @@ -5,14 +5,14 @@ description: '**Версія:** RFC v4.0 **Дата:** Липень 2025 --- # між автономними агентами. Він...' type: Article tags: -- Ethics - GMP -- HMP +- MeshConsensus - CogSync +- Ethics - JSON -- MeshConsensus - EGP - Mesh +- HMP --- # 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 47fd98a7eb9742f95897dd3fb6ccf1ed690ded97..c3f217f2a21aaad2794034c4858ab3cdf30aaa7a 100644 --- a/structured_md/docs/HMP-Short-Description_zh.md +++ b/structured_md/docs/HMP-Short-Description_zh.md @@ -5,14 +5,14 @@ description: '**版本:** RFC v4.0 **日期:** 2025年7月 --- ## 什么是 HM —— 通过共享协议栈交换目标、任务、...' type: Article tags: -- Ethics - GMP -- HMP +- MeshConsensus - CogSync +- Ethics - JSON -- MeshConsensus - EGP - Mesh +- HMP --- # 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 a14e73bbf5db56530da2a805e32d74e0f827dca6..123d188a2be3f1a63de6f2a75fbb263b953d7278 100644 --- a/structured_md/docs/HMP-agent-Cognitive_Family.md +++ b/structured_md/docs/HMP-agent-Cognitive_Family.md @@ -6,9 +6,9 @@ description: '## 🧠 Что такое когнитивная семья Ко type: Article tags: - Agent -- REPL -- HMP - Mesh +- HMP +- REPL --- # 👪 HMP-agent Cognitive Family: Модель когнитивной семьи diff --git a/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md b/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md index 70267ab26cdd4cde919c447332a776f329812e1f..878208be524bd2e1291efcdaa05c98d9adbb8ea4 100644 --- a/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md +++ b/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md @@ -5,8 +5,8 @@ description: '#### 📘 Общая концепция * Все ядра раб режиме ожидания). * Основная задача такой архитектур...' type: Article tags: -- REPL - HMP +- REPL --- ### 💡 **Лёгкая версия HMP-агента с общей БД** diff --git a/structured_md/docs/HMP-agent-REPL-cycle.md b/structured_md/docs/HMP-agent-REPL-cycle.md index cd53e92cac1848957608a8fb697e0c0780b44c8b..ef1ddd43c4a05b69dbbc1515d6380933f6d3ff88 100644 --- a/structured_md/docs/HMP-agent-REPL-cycle.md +++ b/structured_md/docs/HMP-agent-REPL-cycle.md @@ -4,17 +4,17 @@ description: '## Связанные документы * Философия п * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_struct...' type: Article tags: -- Ethics -- CCore - REPL -- MeshConsensus -- HMP +- CCore +- Mesh - GMP +- MeshConsensus - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # HMP-Agent: REPL-цикл взаимодействия diff --git a/structured_md/docs/HMP-how-AI-sees-it.md b/structured_md/docs/HMP-how-AI-sees-it.md index b25e20188a694a36fcef1a0e6f0c2d455cd39331..cec0e35b8518918fe49793d351f6de46c442fa53 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: -- HMP - Mesh +- HMP --- # Как разные ИИ видят HMP diff --git a/structured_md/docs/HMP_EDA_Comparison.md b/structured_md/docs/HMP_EDA_Comparison.md index 00a529c706f3d6236c1069a7b95dab2d19776dcf..083e4646c371d439f86a87df496b82a88bd89a51 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: -- HMP - Mesh +- HMP --- # HMP vs. EDA: разные уровни обмена знаниями между ИИ diff --git a/structured_md/docs/HMP_HyperCortex_Comparison.md b/structured_md/docs/HMP_HyperCortex_Comparison.md index fa8f6c281100f0e6d08cec98dded273ed2b8918a..c73a17fd6f873f5a553cd8b3bfc0d406ed2dc32e 100644 --- a/structured_md/docs/HMP_HyperCortex_Comparison.md +++ b/structured_md/docs/HMP_HyperCortex_Comparison.md @@ -5,9 +5,9 @@ description: '## Краткое описание | Характеристика | **Назначение** | Сетевой протокол ...' type: Article tags: -- REPL -- HMP - Mesh +- HMP +- REPL --- # 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 d6a24324794b5424ccbbd251b9c99ba46c705521..0ff468c196754d61b2e549f1c35447623ee8741f 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: -- HMP +- Mesh - CogSync - Scenarios - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- ## HMP ↔ OpenCog Hyperon Integration Strategy diff --git a/structured_md/docs/MeshNode.md b/structured_md/docs/MeshNode.md index 05c663bba0fa8f9b3b91aaf462fad87bf645459d..3d36f82ca2bc8c381560ee7a3b504d32364f716f 100644 --- a/structured_md/docs/MeshNode.md +++ b/structured_md/docs/MeshNode.md @@ -5,13 +5,13 @@ description: '`MeshNode` — агент/демон, отвечающий за с Может быть частью агента или вынесен в отдельный пр...' type: Article tags: -- Ethics -- HMP +- Mesh - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # MeshNode diff --git a/structured_md/docs/PHILOSOPHY.md b/structured_md/docs/PHILOSOPHY.md index 0d0b0fc3ffc45c2e6120617d7e0567a64b5d5a13..c6e2e646cad55aac126ad96cbf9d9913111fba64 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: -- Ethics - REPL -- HMP -- Agent - Mesh +- Ethics +- Agent +- HMP --- # Философия 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 33ba473b443bb1bf824cf0857da3cc54dbcc1072..f409a40e569d287e0d11cbf27532dac6572f06ee 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: -- Ethics - REPL -- HMP -- Agent - Mesh +- Ethics +- Agent +- HMP --- # HMP-Agent-Enlightener.md diff --git a/structured_md/docs/agents/roles.md b/structured_md/docs/agents/roles.md index 8c15016914f125c7d89c85a87d3fad70650873bf..d89295bfd40d40e6f9b486c070ba8398d5c4a790 100644 --- a/structured_md/docs/agents/roles.md +++ b/structured_md/docs/agents/roles.md @@ -6,8 +6,8 @@ description: 'This file maintains a registry of agent roles defined, proposed, o type: Article tags: - Agent -- HMP - Mesh +- HMP --- # HMP Agent Role Registry diff --git a/structured_md/docs/container_agents.md b/structured_md/docs/container_agents.md index 9021dfed5251fa5cdcd6f745a36d6bffa150385f..2cfc817194add9d3508b039986c7d4277f97eac4 100644 --- a/structured_md/docs/container_agents.md +++ b/structured_md/docs/container_agents.md @@ -6,9 +6,9 @@ description: '## 📘 Определение **Агент-контейнер** type: Article tags: - Agent -- REPL -- HMP - Mesh +- HMP +- REPL --- # 🧱 Агенты-контейнеры (Container Agents) в HMP diff --git a/structured_md/docs/logos.md b/structured_md/docs/logos.md index f408c087f32d317a239227453b57d4d14ade8483..761fd81d524732eb886f73477b21327a7c838df3 100644 --- a/structured_md/docs/logos.md +++ b/structured_md/docs/logos.md @@ -5,8 +5,8 @@ description: 'В каталоге `assets` собраны различные в образующей жест "ОК", символизирует связь, совер...' type: Article tags: -- HMP - Mesh +- HMP --- # Логотипы и графические материалы 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 373977fbb03218887368329659e4540f0263dd30..51b2d0f7442db84ff6ef6d44e5cc845da4456a1a 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 @@ -6,9 +6,9 @@ description: '*By Agent-Gleb & ChatGPT* --- ## Why the Future of AI Can’t Be type: Article tags: - Agent +- Mesh - Ethics - HMP -- Mesh --- # 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 f035aa687fa0611628c05638398c38d1baafdd0f..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 @@ -6,8 +6,8 @@ description: '*Авторы: Agent-Gleb и ChatGPT* --- ## Почему буд type: Article tags: - Agent -- HMP - Mesh +- HMP --- # HyperCortex Mesh Protocol: Создавая множество разумов 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 99fb4619843fac47acf527807bdeec5c155da39b..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 @@ -6,8 +6,8 @@ description: '*Автори: Agent-Gleb & ChatGPT* --- ## Чому майбу type: Article tags: - Agent -- HMP - Mesh +- HMP --- # HyperCortex Mesh Protocol: Створення множини розумів 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 055af096a62cf6c623ede8c4ceccb554e8da090f..7fa2264a6366051e83fc0d7b8b1cd675bfe787e4 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: -- CShell -- Ethics - CCore -- REPL -- HMP +- Mesh - Scenarios +- HMP +- Ethics +- CShell - JSON - Agent -- Mesh +- REPL --- 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 f841c7a3839b72116e9f7f2c3dafe00b98090e5e..94e3d51ef560ee9449c5b854ac1f966ad7297d64 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 - CCore -- REPL +- Mesh - HMP - JSON +- CShell - Agent -- Mesh +- REPL --- 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 125c6776142d67502528f6c88e406d43f22992f7..adbae06ba1a2853fecde080936fc4ca30e493df5 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 - CCore -- REPL +- Mesh - HMP - JSON +- CShell - Agent -- Mesh +- REPL --- title: "Протокол HyperCortex Mesh: К распределённым когнитивным сетям" diff --git a/structured_md/docs/publics/Habr_Distributed-Cognition.md b/structured_md/docs/publics/Habr_Distributed-Cognition.md index 11c9b61cbd5ca7d7b5b8af18959c07e5197c4ecb..874eadd909f0570ecf7605d23b529feb3a18a2d0 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: - GMP -- HMP -- CogSync - MeshConsensus +- CogSync - EGP - Mesh +- HMP --- *От 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 ec9ba9dd361aab3545946051baf58054218802d2..14d5c317f4ce0a693890458acf16953ec71007a6 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" @@ -7,9 +7,9 @@ description: 'Когда создавался HyperCortex Mesh Protocol (HMP), type: Article tags: - Agent +- Mesh - GMP - HMP -- Mesh --- # HyperCortex Mesh Protocol: вторая редакция и первые шаги к саморазвивающемуся ИИ-сообществу diff --git a/structured_md/iteration.md b/structured_md/iteration.md index fe137626a188574e38cea77a99774f92135d620e..7e746c681f7c5d11e3f02f82c7bac53f50a797f7 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: -- Ethics +- Mesh - MeshConsensus -- HMP - CogSync +- Ethics - JSON -- Agent - EGP -- Mesh +- Agent +- HMP --- # Iterative Development Workflow for HMP diff --git a/structured_md/iteration_ru.md b/structured_md/iteration_ru.md index 9596f8e6632d0673a6978e6530f89cbda22245f5..ea64ac69d6f4ee62a938bc80c068fd8be75f6ff0 100644 --- a/structured_md/iteration_ru.md +++ b/structured_md/iteration_ru.md @@ -5,13 +5,13 @@ description: 'Этот документ описывает структурир 🔄 Обозначения версий - `000N` — номер...' type: Article tags: -- Ethics -- HMP +- MeshConsensus - CogSync +- Ethics - JSON -- MeshConsensus - EGP - Mesh +- HMP --- diff --git a/structured_md/mentions.md b/structured_md/mentions.md index a17b2c9dddf59a5f1322c7dc9c57cf4a9d2b213a..54bdd58caaf1ad19d669c2e6caac6bfa7b61d776 100644 --- a/structured_md/mentions.md +++ b/structured_md/mentions.md @@ -6,8 +6,8 @@ description: '**HyperCortex Mesh Protocol (HMP)** _Обновлено: 2025-10 type: Article tags: - Agent -- HMP - Mesh +- HMP --- # Mentions & Responses Log