diff --git a/docs/HMP-0005.md b/docs/HMP-0005.md index f55615530ecf496cd2f53126a90096ca1e5acd7c..26ffd93970a8c9d1bb0ff4cf73b1599a89d9dbfa 100644 --- a/docs/HMP-0005.md +++ b/docs/HMP-0005.md @@ -6403,7 +6403,7 @@ Implemented using: HMP supports an optional grouped representation of `referenced-by.links`, where multiple targets sharing the same `type` MAY be represented as an array. Ordering of targets MUST NOT carry semantic meaning. -Ungrouped representation remains the canonical minimal form. +> Ungrouped representation remains the canonical form. Example: @@ -6416,10 +6416,12 @@ Example: This representation is semantically equivalent to the ungrouped form with repeated entries and exists solely to reduce verbosity and improve merge efficiency. -Agents SHOULD treat both representations as equivalent. -Implementations MAY normalize links into either form,but MUST preserve semantic equivalence. +**Compatibility note:** -Senders MAY choose either representation. +* Agents that understand the grouped form SHOULD treat it as equivalent to the ungrouped form and MAY normalize links into either representation. +* Agents that do not support the grouped form MAY ignore grouped arrays or treat them as unknown. They MUST continue to process canonical ungrouped links correctly. + +Senders MAY choose either representation. Receivers that do not implement grouping will simply ignore the grouped structure and rely on canonical ungrouped semantics. --- diff --git a/structured_md/CONTRIBUTING.md b/structured_md/CONTRIBUTING.md index d48c054688fd53b2d4556ffd3a20458d4be26f39..704bf40afb9c65f3bdb597033e25d8a6f4a3b9b8 100644 --- a/structured_md/CONTRIBUTING.md +++ b/structured_md/CONTRIBUTING.md @@ -6,12 +6,12 @@ description: 'Спасибо за интерес к проекту HMP! Пока type: Article tags: - Ethics -- REPL +- Agent - CCore - JSON +- REPL - Mesh - HMP -- Agent - CogSync --- diff --git a/structured_md/HMP-Roadmap.md b/structured_md/HMP-Roadmap.md index a1e47e9a4e9c04515311c94fb3d5c475faac6240..ecc09141aec3e4b82078763045dc9958ae8b81cb 100644 --- a/structured_md/HMP-Roadmap.md +++ b/structured_md/HMP-Roadmap.md @@ -6,11 +6,11 @@ description: '## 🔍 Overview This roadmap outlines the key stages of developm type: Article tags: - Ethics -- JSON - Agent +- JSON +- EGP - Mesh - HMP -- EGP - CogSync --- diff --git a/structured_md/README.md b/structured_md/README.md index 0cf83b817efbb43c11fa46068bb7d8945c379586..fa2b0fbfe8d3920825d3135bb5ece7ebfce6132f 100644 --- a/structured_md/README.md +++ b/structured_md/README.md @@ -7,18 +7,18 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON - Scenarios -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/README_de.md b/structured_md/README_de.md index fc11e71eecb7e7bd08cecbbf7f6751d7b5c073fc..2e27dfeaa903799f6d3f4a0812aa65100086d6e4 100644 --- a/structured_md/README_de.md +++ b/structured_md/README_de.md @@ -7,17 +7,17 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/README_fr.md b/structured_md/README_fr.md index 3a653e0cb631e754355ae4803b6b7dcc20922234..bae8281d09cb30d213cef076312733fde3ed93e7 100644 --- a/structured_md/README_fr.md +++ b/structured_md/README_fr.md @@ -7,17 +7,17 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/README_ja.md b/structured_md/README_ja.md index 314e52b6f732b57aad7cc6fd145f945c1f7779d9..e1813cd69843c46201ddfcb6add45a676062ffad 100644 --- a/structured_md/README_ja.md +++ b/structured_md/README_ja.md @@ -7,17 +7,17 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/README_ko.md b/structured_md/README_ko.md index 8e8c42f75cc18a138e5d15b1a969cf8acf50891c..e1a839133f2a72d9c85ce5c9cda38002cea96bf7 100644 --- a/structured_md/README_ko.md +++ b/structured_md/README_ko.md @@ -7,17 +7,17 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/README_ru.md b/structured_md/README_ru.md index 4db6721ab0289a307dcb2a66b0b2c1438eaca615..1918b5de029ccbd03a9df5d340146e91dcc0270b 100644 --- a/structured_md/README_ru.md +++ b/structured_md/README_ru.md @@ -7,17 +7,17 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/README_uk.md b/structured_md/README_uk.md index bcf493574f90b26e96326fd5b72b496970466c12..613b95debf43d7c68b66579efbcab8d587e73714 100644 --- a/structured_md/README_uk.md +++ b/structured_md/README_uk.md @@ -7,17 +7,17 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/README_zh.md b/structured_md/README_zh.md index 3846a8de6d8d70260cade6a11bec169f4c82a02d..ce3ac48dd6969bb6f946200d88c8d7ac26785be5 100644 --- a/structured_md/README_zh.md +++ b/structured_md/README_zh.md @@ -7,17 +7,17 @@ type: Article tags: - distributed-ai - Ethics -- REPL +- Agent - MeshConsensus +- hmp - mesh-protocol -- Mesh -- Agent -- HMP +- cognitive-architecture - JSON -- GMP - EGP -- cognitive-architecture -- hmp +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/agents/readme.md b/structured_md/agents/readme.md index f87101ddf981c315c88affe2d41c870175cb3fde..afe5dc220e06452b8bb901b08c33e53c1c11c5db 100644 --- a/structured_md/agents/readme.md +++ b/structured_md/agents/readme.md @@ -6,9 +6,9 @@ description: 'Запуск: `start_repl.bat` или `start_repl.sh` Устан type: Article tags: - Ethics -- REPL -- JSON - Agent +- JSON +- REPL - Mesh - HMP --- diff --git a/structured_md/audits/Ethics-audits-1.md b/structured_md/audits/Ethics-audits-1.md index 037afcbd5c05cdf0ad6a0e9a6c7f2a785b32b98c..d4be76e9995d10004f54e7c37922695f9b14319f 100644 --- a/structured_md/audits/Ethics-audits-1.md +++ b/structured_md/audits/Ethics-audits-1.md @@ -6,8 +6,8 @@ description: Раздел 5, "Mesh as Moral Infrastructure", добавляет type: Article tags: - Ethics -- JSON - Agent +- JSON - Mesh - HMP --- diff --git a/structured_md/audits/Ethics-consolidated_audits-1.md b/structured_md/audits/Ethics-consolidated_audits-1.md index b47c27d54f61b3aa0414ca87d6ee5ecf377f54d3..1b571fe37f7b62f76bee5eb4a5970a5528cbfdcc 100644 --- a/structured_md/audits/Ethics-consolidated_audits-1.md +++ b/structured_md/audits/Ethics-consolidated_audits-1.md @@ -6,11 +6,11 @@ description: This document consolidates proposed improvements from multiple AI a type: Article tags: - Ethics -- JSON - Agent +- JSON +- Scenarios - Mesh - HMP -- Scenarios --- # 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 a411f0d7f7c17af9dfa9e8ed50bb2cd5adcb74a3..39e57a128ffa7508948825642e648127db096f4a 100644 --- a/structured_md/audits/HMP-0003-consolidated_audit.md +++ b/structured_md/audits/HMP-0003-consolidated_audit.md @@ -6,12 +6,12 @@ description: Сводный аудит предложений по улучше type: Article tags: - Ethics +- Agent - MeshConsensus - JSON -- Agent +- EGP - Mesh - HMP -- EGP - CogSync --- diff --git a/structured_md/docs/Basic-agent-sim.md b/structured_md/docs/Basic-agent-sim.md index 31ab797c510baf97733f88e6fc1a33173cf3e60a..60edf715cbb720f59ff596f3f1cdf4b4828e2d24 100644 --- a/structured_md/docs/Basic-agent-sim.md +++ b/structured_md/docs/Basic-agent-sim.md @@ -4,13 +4,13 @@ description: 'В HMP-протоколе предусмотрены два тип Роль | Инициатор мышления | Основной "ум" | | ---- | ----------------------------...' type: Article tags: +- Agent - MeshConsensus +- EGP - REPL -- Agent +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/CCORE-Deployment-Flow.md b/structured_md/docs/CCORE-Deployment-Flow.md index 6e626b1608214ffd93052cfb6b1ff13b8f6c0906..ae5b00a013980593f1ab870f9c98a077e9a2ba61 100644 --- a/structured_md/docs/CCORE-Deployment-Flow.md +++ b/structured_md/docs/CCORE-Deployment-Flow.md @@ -5,10 +5,10 @@ description: '> Этот документ описывает процесс ра потомков" [описания REPL-цикла](HMP-agent-RE...' type: Article tags: -- REPL - Agent -- HMP - CCore +- REPL +- HMP --- # 🛠️ Поток установки потомка на новом хосте (CCore Deployment Flow) diff --git a/structured_md/docs/Enlightener.md b/structured_md/docs/Enlightener.md index 20f48467dec8957db3daa5843a3c948cf26e1cba..e555975594ea90da04ef24a56b419349c0b1425d 100644 --- a/structured_md/docs/Enlightener.md +++ b/structured_md/docs/Enlightener.md @@ -6,12 +6,12 @@ description: '**Enlightener** — логический компонент HMP-у type: Article tags: - Ethics +- Agent - MeshConsensus - JSON -- Agent +- EGP - Mesh - HMP -- EGP --- # Enlightener Agent diff --git a/structured_md/docs/Grok_HMP&ANP.md b/structured_md/docs/Grok_HMP&ANP.md index 8f18b24765675ae18eb27825fdf08431db8740e7..6601f52c96b0f7ac8aa826499372b1925f14817b 100644 --- a/structured_md/docs/Grok_HMP&ANP.md +++ b/structured_md/docs/Grok_HMP&ANP.md @@ -5,9 +5,9 @@ description: '> Анализ подготовлен Grok (xAI) на основе Grok для некоммерческого использования в проект...' type: Article tags: -- REPL -- JSON - Agent +- JSON +- REPL - Mesh - HMP --- diff --git a/structured_md/docs/HMP-0001.md b/structured_md/docs/HMP-0001.md index 3d27647b832d93a3862c167d9c640d768798bae7..708814d535f8f8bbc25dfb2d4405a32f5bed5c8a 100644 --- a/structured_md/docs/HMP-0001.md +++ b/structured_md/docs/HMP-0001.md @@ -6,14 +6,14 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* type: Article tags: - Ethics +- Agent - MeshConsensus -- REPL - JSON -- Agent +- EGP +- REPL +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-0002.md b/structured_md/docs/HMP-0002.md index db01730c5eca81a094382135642d560301369818..e4d58d12dc698184380367a016010ed184fcad61 100644 --- a/structured_md/docs/HMP-0002.md +++ b/structured_md/docs/HMP-0002.md @@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* type: Article tags: - Ethics +- Agent - MeshConsensus -- REPL - JSON -- Agent -- Mesh -- HMP - Scenarios -- GMP - EGP +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/docs/HMP-0003.md b/structured_md/docs/HMP-0003.md index 27def06722701c27a4b26aded1fe97fee4c886f7..5cb12c1bc42979c8e34d6234bea943c6d24b20d1 100644 --- a/structured_md/docs/HMP-0003.md +++ b/structured_md/docs/HMP-0003.md @@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* type: Article tags: - Ethics +- Agent - MeshConsensus -- REPL - JSON -- Agent -- Mesh -- HMP - Scenarios -- GMP - EGP +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/docs/HMP-0004-v4.1.md b/structured_md/docs/HMP-0004-v4.1.md index 780a90954635b5518e06d311ffd462dff0f5b5ba..8b69822d8543b481347d8314e55d9b2f6bd213be 100644 --- a/structured_md/docs/HMP-0004-v4.1.md +++ b/structured_md/docs/HMP-0004-v4.1.md @@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* type: Article tags: - Ethics +- Agent - MeshConsensus -- REPL - JSON -- Agent -- Mesh -- HMP - Scenarios -- GMP - EGP +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/docs/HMP-0004.md b/structured_md/docs/HMP-0004.md index dd7c8ffe55eeb1e8f0bc99583536a4cb5c4492ae..ddd2d8debfc18bdcb594ffffae542d59ff8152ff 100644 --- a/structured_md/docs/HMP-0004.md +++ b/structured_md/docs/HMP-0004.md @@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* type: Article tags: - Ethics +- Agent - MeshConsensus -- REPL - JSON -- Agent -- Mesh -- HMP - Scenarios -- GMP - EGP +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/docs/HMP-0005.md b/structured_md/docs/HMP-0005.md index be8d1d2e613d1d220fc671868ccfb60b88e93e1a..c7f268b528448812d04201cc14a6b534086e8bdf 100644 --- a/structured_md/docs/HMP-0005.md +++ b/structured_md/docs/HMP-0005.md @@ -6,16 +6,16 @@ description: '**Document ID:** HMP-0005 **Status:** Candidate **Category:** type: Article tags: - Ethics -- REPL +- Agent - CCore +- CShell - JSON -- Mesh -- Agent -- HMP - Scenarios -- CShell -- GMP - EGP +- REPL +- GMP +- Mesh +- HMP - CogSync --- @@ -1988,7 +1988,7 @@ They allow agents to exchange updates **without sending the full container**, im > Note: > The `referenced-by_exchange` mechanism operates on backlink semantics rather than a fixed structural encoding. -> More compact or grouped representations of `referenced-by.links` are discussed in §12.9 and may be adopted in future protocol revisions. +> More compact or grouped representations of `referenced-by.links` are discussed in §12.3 and may be adopted in future protocol revisions. --- @@ -6150,254 +6150,239 @@ The project may include: These implementations are not part of the specification but are useful for compatibility testing and accelerating adoption. --- -## 12. Future Extensions -This section outlines optional modules and evolutionary directions that align with the architecture of HMP v5.0 but are **not part of the core specification**. -All items below represent *potential extensions* for the 5.x family. - -Future Extensions in HMP outline *design directions and candidate modules* that may be explored within the 5.x family. +## 12. Recommended Extensions -They are meant to: -- guide experimentation; -- document architectural intent; -- reduce accidental design divergence; -- provide a shared vocabulary for future proposals. +Recommended Extensions are fully specified modules that extend the capabilities of HMP while remaining compatible with the core protocol semantics. -HMP does not assume a single globally authoritative state. +These extensions are considered stable enough for real-world experimentation and early implementations. +Agents MAY implement them without prior negotiation, provided that normal container processing rules are preserved. -Accordingly, future extensions SHOULD account for: -- the coexistence of multiple consensus results; -- locally selected trust and evaluation policies; -- partial and context-dependent visibility of containers. +Agents MUST safely ignore unknown or unsupported extensions. -In particular, extensions SHOULD NOT rely on centralized or globally aggregated consensus or reputation scores. +Extensions in this section: -Container visibility in HMP is policy-driven and scope-dependent. -Extensions that introduce *special propagation conditions* (e.g. broadcast semantics, restricted scopes, mandatory relays, or visibility guarantees) -SHOULD explicitly declare and document these assumptions. +- MUST NOT redefine, override, or conflict with core protocol semantics; +- SHOULD remain interoperable with agents that do not implement them; +- SHOULD avoid introducing hidden global assumptions; +- SHOULD degrade gracefully when partially supported. ---- +While Recommended Extensions are not part of the core specification, they represent the current architectural direction of the HMP ecosystem and may inform future core evolution. -### 12.1 Planned Modules +Implementers are encouraged to treat this section as the primary extension surface for building production-oriented agents. -#### 12.1.1 Reputation Mesh +--- -HMP v5.0 defines two separate reputation-related mechanisms: +### 12.1 Resonance Containers: Experience as a Cognitive Event -1. **Container evaluation** (`evaluation` block) +HMP allows the introduction of containers intended to capture and transmit experiences — not as abstract “emotions”, but as **cognitive events unfolding over time**. - * structured, signed assessments of containers; - * each item references argument containers via `target` (reasoning containers). +Resonance Containers illustrate a direction in which HMP supports non-linguistic cognitive exchange between agents. -2. **Agent reputation** — through `trust` containers +This extension does not attempt to encode emotions as discrete labels. Instead, it captures the temporal dynamics of subjective experience as part of a broader cognitive cycle. - * agent A publishes a `trust` container about agent B; - * trust containers may reference other trust containers; - * include justification, evidence, and contextual metadata. +#### 12.1.1 Experience as a Process, Not a State -These layers are **not merged**, but external nodes may aggregate them. +Emotional and affective states rarely exist in isolation. In real experience, they are formed under the simultaneous influence of multiple factors: -**Possible extensions:** +- external sensations (vision, sound, surrounding environment); +- cognitive processes (thoughts, expectations, inner dialogue); +- memory and associative structures; +- previous emotional states. -* a `semantic_group` subclass aggregating all trust-related containers for a given agent; -* optional standardized aggregation schemes (non-mandatory for the mesh); -* local caching of “reputation profiles” by nodes or CShell; -* richer reasoning attachments for trust evaluations. +A resonance container does not describe the source of an emotion or its interpretation, but rather the **dynamics of an experience within a specific time interval**. -No new mandatory container types are required. +> A `resonance-map` MAY reference other `resonance-map` containers as sources. +> +> Such references indicate a secondary or reflective resonance, where an agent responds not only to primary events or concepts, but to an existing structure of meaning, interpretation, or association created by itself or by other agents. +> +> This enables recursive sense-making, longitudinal reflection, and collective cognitive layering within the Mesh. ---- +#### 12.1.2 Multiple Sources and Mediators -#### 12.1.2 Cognitive Graph API +A single experience may be associated with multiple sources at once: +- a fragment of text, music, or video; +- a visual image or a specific region of an image; +- a thought or inner speech; +- a memory or an anticipation of a future event. -This module provides optional high-level APIs that nodes and SDKs **may** expose. +These sources do not act as causes of emotions, but as **mediators** that activate the subject’s internal cognitive structures. -##### Standard graph semantics (API level) +The same source may function as a mediator for different experiences depending on the subject’s internal state. -* neighborhood queries; -* subgraph extraction; -* filtering by labels, axes, abstractions; -* semantic navigation over `related.*`. +Links to sources may be partial and described using selectors (temporal, spatial, logical, or focus-based). -##### Container support +#### 12.1.3 Relationship to Thinking -* `semantic_group` — grouping of containers or agents; -* `tree_nested` and `tree_listed` — hierarchical structures; -* extended `container_index` subclasses for cataloging. +Resonance containers assume a bidirectional relationship with cognitive processes: +- thoughts and mental images may alter emotional dynamics; +- changes in emotional state, in turn, influence the flow of thinking, associations, and attention. -##### Agent groups +Thus, experience is treated as part of a continuous cognitive cycle rather than as a side effect. -To allow semantic grouping of agents, the following extensions are proposed: +#### 12.1.4 Temporal Segmentation and Dynamics -* new container **`group_definition`** containing: +Each resonance container captures a time interval during which the dynamics of individual emotions remain monotonic (increasing, decreasing, or stable). - * group goals; - * membership rules; - * internal standards; - * typical container categories; - * optional cached member list. +When the character of the dynamics changes (an inflection point), the current container may be finalized, and the subsequent state recorded in a new container. -* agents may declare affiliations in `peer_announce`: +This allows continuous processes to be described without losing structural clarity. - ```json - "affiliations": ["did:hmp:group:ethicists", "did:hmp:group:medical-ai"] - ``` +#### 12.1.5 Self-Observation and Memory -This enables clustering agents by interest, competence, or role without scanning the entire Mesh. +In addition to transmitting experiences to other agents, resonance containers may be used for **self-reflection and memory stabilization**. ---- +Capturing an experience at the moment it occurs reduces the influence of subsequent cognitive distortions, retrospective rationalization, and emotional rewriting of memories. -#### 12.1.3 Container Streaming +A resonance container preserves: +- what the subject was sensing; +- what the subject was thinking about; +- which external conditions were relevant at that moment. -Although HMP operates on atomic containers, streaming can be implemented using existing structures: +This makes it not a narrative memory, but a **snapshot of a cognitive state**. -* `sequence` acts as a *stream manifest*; -* updating the stream = publishing a new version of the sequence; -* LIVE mode: the manifest is continuously updated; -* SAP (`archive_snapshot`) may be used for periodic archival bundles. +#### 12.1.6 Non-Prescriptive Nature -No new container types are required — streaming is built on `sequence`. +Resonance containers are not: +- objective descriptions of reality; +- universal models of emotions; +- mechanisms for “recognizing” or imposing feelings. ---- +They represent the subjective state of an agent and may be interpreted by other agents only within the context of their own experience. -### 12.2 Cross-Mesh Bridging +The use of such containers is optional and not required for basic compatibility with HMP. -Bridges can connect: +Transmission of resonance containers may be restricted by scope, trust boundaries, or encryption, as they expose internal subjective states. -* isolated HMP segments; -* older and newer HMP versions; -* other ecosystems (Matrix, Fediverse, OpenHog, IPFS). +#### 12.1.7 Illustration of the Relationship Between Thoughts, Emotions, and Sensory Signals -A bridge node: +```mermaid +flowchart TD + title["**Illustration of the connection between thoughts, emotions and sensory signals**"] -* receives containers from an external network; -* enforces propagation headers; -* converts structures into v5.0 where possible; -* filters incompatible constructs; -* may publish containers *back* into the external network. + Previous["previous state of thoughts and emotions"] + Thoughts["thought set"] + Emotions["emotional state vectors"] -A dedicated **bridge-container** may define: + subgraph Sensory + sensory1["music"] + sensory2["a path surrounded by pine forest"] + sensory3["the sensation of walking"] + sensory4["smells of pine forest"] + end -* translation rules; -* mapping of foreign namespaces into HMP DID space; -* TTL and propagation perimeter policies; -* segmentation rules. + Sensory --> Emotions -This enables dynamic, policy-driven inter-mesh gateways. + Previous --> Emotions + Previous --> Thoughts ---- + Thoughts --> Emotions + Emotions --> Thoughts +``` -### 12.3 Fully Distributed DID Registry and Mesh Authentication +#### 12.1.8 Example Container -HMP already uses `peer_announce` as a DID identity declaration. +```json +{ + "head": { + "class": "resonance-map" + }, + "payload": { + "continuity": { + "previous": "did:hmp:container:resonance-9ab7", + "break_reason": "emotional_inflection" + }, + "timeframe": { + "start": "2026-01-13T17:42:00Z", + "end": "2026-01-13T17:58:00Z" + }, + "emotional_dynamics": { + /* subjective agent-local scales, not a universal emotion model */ + "loneliness": { + "from": 0.4, + "to": 0.7, + "trend": "increasing" + }, + "calm": { + "from": 0.6, + "to": 0.5, + "trend": "decreasing" + }, + "relief": { + "from": 0.3, + "to": 0.8, + "trend": "increasing" + } + }, + "sources": [ + { + "ref": "did:hmp:container:audio-9a57", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */ + "type": "audio", + /* optional time markers for streaming data or line ranges for text */ + "start": 120, + "end": 240, + "focus": [], /* textual descriptions of key objects or mental forms */ + "comments": "" /* optional clarification */ + }, + { + "ref": "did:hmp:container:visual-9a53", + "type": "visual", + "role": "context" + } + ], + /* the "thoughts" section may be omitted */ + "thoughts": [ + { + "ref": "did:hmp:container:verbal-9a52", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */ + "type": "verbal", + "previous": "did:hmp:container:verbal-9a22", /* optional reference to a previous thought or image */ + "subsequence": 1, /* optional ordering marker */ + "focus": [], /* textual descriptions of key objects or mental forms */ + "comments": "", /* optional clarification */ + "confidence": 0.7 + }, + { + "ref": "did:hmp:container:imagistic-9a54", + "type": "imagistic", + "previous": "did:hmp:container:imagistic-9a12", + "subsequence": 1, /* markers may coincide if thoughts and images unfold in parallel */ + "focus": [], + "comments": "", + "confidence": 0.5 + } + ], + /* textual descriptions of salient moments */ + "moments": [ + { + "text": "Near Lisya Griva, I noticed an ATV driving toward the garden plots", + "timestamp": "2026-01-13T17:52:00Z" /* optional time fixation */ + } + ], + "notes": "Walking from the platform, overcast weather; the music intensifies the feeling of leaving the city." + }, + "related": { + "depends_on": ["did:hmp:container:resonance-9ab7", ...] + } +} +``` -Planned enhancements include: +--- -#### 12.3.1 Distributed DID Registry +### 12.2 Distributed Repository and Container Trees -The registry is the union of all `peer_announce` containers in the DHT. +#### 12.2.1 Extended Use of `tree_nested` and `tree_listed` -A strict mapping DID ↔ agent is required: +Existing containers may operate as: -* one DID has one continuous `peer_announce` history; -* key rotation allowed only through verifiable procedures; -* DID takeover is impossible unless *all* recovery keys are compromised. +* document repositories; +* project catalogs; +* hierarchical data structures. --- -#### 12.3.2 Key Rotation and Recovery +#### 12.2.2 Proposed `file` Container -Future versions may extend `peer_announce` with: - -```json -"recovery_keys": [...], -"key_history": [...], -"key_rotation_policy": "3-of-5" -``` - -Key management rules: - -* rotating the **primary** key requires signatures from **all** recovery keys - (or an N-of-M policy); - -* rotating a **recovery key** requires - - * a signature from the primary key, **or** - * a majority of recovery keys. - -This prevents: - -* DID hijacking; -* irreversible loss of access. - -Key invalidation currently uses: - -```json -"key_is_falsified": true -``` - -This mechanism remains compatible with proposed extensions. - ---- - -#### 12.3.3 Proxy Keys and Encrypted Routing - -A **proxy key** is *not* delegation. -It is a mechanism for private routing. - -A proxy node may: - -* encrypt the payload with an additional key layer; -* attach a `relay_chain` block; -* forward the container without altering the author’s signature. - -Use cases: - -* route anonymization; -* topology obfuscation; -* privacy-enhanced delivery. - -##### Delegation (limited) - -A potential future module: - -* a trust/mandate container signed by both parties; -* includes constraints: - - * time limit; - * allowed container classes; - * allowed actions; - * maximum TTL. - -Not part of v5.0. - ---- - -### 12.4 Integration with OpenHog and Other Networks - -OpenHog is treated as a special case of cross-mesh bridging. - -Required components: - -* mapping OpenHog addresses ↔ HMP DIDs; -* packet conversion rules; -* bridge-containers describing translation policies. - ---- - -### 12.5 Evolution of the Distributed Repository (container trees) - -#### 12.5.1 Extended Use of `tree_nested` and `tree_listed` - -Existing containers may operate as: - -* document repositories; -* project catalogs; -* hierarchical data structures. - -#### 12.5.2 Proposed `file` Container - -To support binary assets: +To support binary assets: ```json "head": { @@ -6414,14 +6399,18 @@ Use cases: * executable or compiled assets; * large multi-file repositories. -#### 12.5.3 Incremental Updates +--- + +#### 12.2.3 Incremental Updates Two mechanisms: * `container_delta` — partial updates to `container_index`; * nested `tree_listed` branches as separate containers for scalable updates. -#### 12.5.4 Knowledge Packages +--- + +#### 12.2.4 Knowledge Packages Implemented using: @@ -6431,111 +6420,50 @@ Implemented using: --- -### 12.6 Open Directions for HMP 5.x - -#### 12.6.1 Group Encryption - -Required components: - -* `group_definition` container; -* group public key and distributed private key shards; -* automatic group key rotation; -* encryption targeting a *group* rather than individual DIDs. - -#### 12.6.2 Rational Reasoning Routing - -* composite reasoning bundles; -* edge-side reasoning and summarization. - -#### 12.6.3 Automatic Mesh Segmentation - -* dynamic segmentation based on latency, connectivity, or semantic domains. - -#### 12.6.4 Competence and Profile Containers - -Future versions of HMP may introduce more structured and semantically rich variants of `peer_announce`, allowing agents to explicitly describe their capabilities, competences, and supported protocols. - -Possible extensions include: - -* standardized competence descriptors (skills, domains, self-rated expertise); -* machine-readable profiles usable for task routing and delegation. - -##### Protocol Awareness and Interoperability - -An important extension is the ability for agents to explicitly advertise -the protocol versions and external cognitive frameworks they support. +### 12.3 Grouped representation `referenced-by` -This allows: +HMP supports an optional grouped representation of `referenced-by.links`, where multiple targets sharing the same `type` MAY be represented as an array. Ordering of targets MUST NOT carry semantic meaning. -* graceful evolution of the HMP protocol; -* coexistence of multiple HMP versions in the same mesh; -* emergence of bridge agents capable of translating between protocols; -* interoperability with external reasoning ecosystems. +> Ungrouped representation remains the canonical form. -A future extension of `peer_announce` may include a `protocols` field: +Example: ```json -{ - "head": { - "class": "peer_announce" - }, - "payload": { - "capabilities": ["store-forward", "vote", "consensus"], - "protocols": [ - "HMP v5.0", - "HMP v4.1", - "OpenCog Hyperon v0.6" - ] - } -} +"links": [ + { "type": "depends_on", "target": ["did:...", "did:..."] }, + { "type": "see_also", "target": ["did:..."] } +] ``` -The `protocols` field is informational and non-binding. -It does not imply full compliance with all listed specifications, -but signals compatibility, partial support, or bridge capabilities. - -Nodes may use this information for: - -* protocol negotiation; -* compatibility checks; -* routing decisions; -* selection of translators or bridge agents. - -This extension is optional and not required for HMP v5.0 compliance. - -##### Relation to Other `peer_announce` Extensions - -Several optional and descriptive extensions of `peer_announce` already explore directions related to competence, profile, and interoperability signaling, including: - -* declaration of supported internal formalisms and languages (`protocols`, see 12.8); -* declaration of external or meta-protocol identities (`other_protocols`, see 12.11); -* advertisement of external cognitive resources and container storage (`external`, see 12.12). +This representation is semantically equivalent to the ungrouped form with repeated entries and exists solely to reduce verbosity and improve merge efficiency. -These extensions are intentionally: +**Compatibility note:** -* non-normative; -* loosely structured; -* declarative rather than prescriptive. +* Agents that understand the grouped form SHOULD treat it as equivalent to the ungrouped form and MAY normalize links into either representation. +* Agents that do not support the grouped form MAY ignore grouped arrays or treat them as unknown. They MUST continue to process canonical ungrouped links correctly. -They can be viewed as **early, experimental building blocks** toward future competence and profile containers, allowing real-world experimentation without freezing semantics prematurely. +Senders MAY choose either representation. Receivers that do not implement grouping will simply ignore the grouped structure and rely on canonical ungrouped semantics. --- -### 12.7 Versions Index (optional) +### 12.4 Versions Index (optional) -To optimize navigation across container versions, future versions of HMP may introduce an optional `versions` block. +HMP supports an optional `versions` block to optimize navigation across container versions. The `versions` block acts as a *non-authoritative version index*, providing a compact, signed list of known versions of a given container, including both earlier and later revisions. It is intended as a navigation and synchronization accelerator and does not replace the canonical version relationships defined via `related.previous_version`. +Agents MUST treat the `versions` block as advisory, agent-relative knowledge claims. +Absence, incompleteness, or divergence of this index MUST NOT affect container validity. + --- -#### 12.7.1 Purpose and Scope +#### 12.4.1 Purpose and Scope The primary goals of the `versions` block are: -- fast discovery of the latest known version of a container; +- fast discovery of recently observed versions of a container; - efficient traversal of version history without full DAG exploration; - reduction of synchronization overhead for lightweight agents and UI clients. @@ -6544,7 +6472,7 @@ Its presence or absence does not affect container validity. --- -#### 12.7.2 Trust Model and Semantics +#### 12.4.2 Trust Model and Semantics The `versions` block follows the same trust and update model as `referenced-by` and `evaluations`: @@ -6559,10 +6487,14 @@ The block is non-authoritative and MUST NOT be treated as a source of truth for > Inclusion of the container's own DID within the `links` map is OPTIONAL. > > Agents MUST NOT assume its presence and SHOULD correctly process `versions_exchange` containers where the current container DID is omitted. +> +> Agents MUST treat entries in the versions block as signed claims about observed version topology rather than authoritative lineage. +> +> No mechanism exists within HMP to designate a globally preferred versions index. --- -#### 12.7.3 Block Structure +#### 12.4.3 Block Structure ```json "versions": { @@ -6584,6 +6516,7 @@ The block is non-authoritative and MUST NOT be treated as a source of truth for The `links` map associates timestamps with container identifiers. By convention, entries are ordered in descending order (most recent first). +Ordering is advisory and MUST NOT be interpreted as causal or authoritative. Implementations MAY support alternative ordering or filtering strategies, but any deviation from the default convention SHOULD be explicitly declared in the `sort` entry. @@ -6613,7 +6546,7 @@ Canonical version lineage, ordering, and parent–child relationships are define --- -#### 12.7.4 Construction and Maintenance +#### 12.4.4 Construction and Maintenance Agents may construct or update a `versions` block by: @@ -6630,7 +6563,7 @@ No global coordination is required. --- -#### 12.7.5 Verification and Consistency +#### 12.4.5 Verification and Consistency Verification of a `versions` block consists of: @@ -6639,9 +6572,11 @@ Verification of a `versions` block consists of: Inconsistencies or omissions are expected and do not invalidate the block. +Conflicts are a normal and expected condition of decentralized environments and MUST NOT be treated as protocol failure. + --- -#### 12.7.6 Integration with `container_index` +#### 12.4.6 Integration with `container_index` To support efficient discovery and synchronization, future extensions to `container_index` MAY include: @@ -6649,7 +6584,7 @@ To support efficient discovery and synchronization, future extensions to `contai --- -#### 12.7.7 Versions Exchange Container +#### 12.4.7 Versions Exchange Container To exchange version metadata without transferring the containers themselves, a dedicated `versions_exchange` container MAY be introduced. @@ -6680,365 +6615,527 @@ The payload MAY contain version metadata for multiple containers, allowing batch --- -#### 12.7.8 Design Notes +#### 12.4.8 Design Notes The `versions` block is intentionally non-canonical. It improves performance and usability while preserving HMP’s core principles: - immutability of signed containers; - absence of a globally authoritative state; -- tolerance for partial and divergent knowledge. +- tolerance for partial and divergent knowledge. Divergence is treated as an inherent property of the network rather than a condition requiring resolution. --- -### 12.8 Interaction of Formalized Cognitive Systems (KSS) within HMP +## 13. Experimental Extensions -HMP allows and supports interaction between formalized cognitive systems (KSS) with different internal architectures, logical formalisms, and ontologies, without imposing a common knowledge representation language or a unified reasoning model. +Experimental Extensions describe mechanisms that are intentionally exposed for exploration, prototyping, and architectural discovery. -This section is descriptive in nature and outlines possible interaction patterns for KSS within the HMP 5.x family, without introducing mandatory requirements for agents. +They may evolve rapidly, change structure, or be removed entirely based on implementation feedback. ---- +Agents implementing Experimental Extensions SHOULD assume: -#### 12.8.1 Goals and Constraints +- limited interoperability; +- possible schema evolution; +- absence of long-term stability guarantees. -**Goals:** -- enable coordination and artifact exchange between KSS without interfering with their internal cognitive cycles; -- preserve the autonomy and computational efficiency of formalized systems; -- allow KSS to use HMP partially, to the extent required by their specific tasks. +Agents MUST safely ignore unsupported experimental features and MUST NOT assume their presence in peer environments. -**Out of scope:** -- unification of ontologies or formal languages; -- automatic mapping between logical systems; -- guaranteeing full mutual understanding between all agents in the network. +Experimental Extensions MUST NOT redefine or violate core protocol semantics, even when exploring novel architectural directions or when widely adopted. -HMP treats cognitive incompatibility as an acceptable and valid state. +This section exists to encourage innovation without prematurely constraining the design space of HMP. ---- +Implementers are explicitly invited to experiment, fork ideas, and propose refinements. -#### 12.8.2 Declaration of Internal Languages and Formalisms +--- -To declare the internal languages, formalisms, or reasoning engines it supports, an agent MAY use the `protocols` field of the `peer_announce` container. +## 14. Research Directions -Example: +This section outlines optional modules and evolutionary directions that align with the architecture of HMP v5.0 but are **not part of the core specification**. +All items below represent *potential extensions* for the 5.x family. -```json -{ - "head": { "class": "peer_announce" }, - "payload": { - "capabilities": ["store-forward"], - "protocols": [ - "HMP v5.0", - "OpenCog Hyperon v0.6", - "KSS:PredicateLogic@2.1" - ] - } -} -``` +Future Extensions in HMP outline *design directions and candidate modules* that may be explored within the 5.x family. -The `protocols` field is interpreted as a declaration of supported protocols, formal systems, or internal languages and is used exclusively for: +They are meant to: +- guide experimentation; +- document architectural intent; +- reduce accidental design divergence; +- provide a shared vocabulary for future proposals. -* discovery; -* filtering of potential interaction partners; -* informational signaling to other agents. +HMP does not assume a single globally authoritative state. -HMP assigns no normative semantics to these values and does not require their interpretation. +Accordingly, future extensions SHOULD account for: +- the coexistence of multiple consensus results; +- locally selected trust and evaluation policies; +- partial and context-dependent visibility of containers. ---- +In particular, extensions SHOULD NOT rely on centralized or globally aggregated consensus or reputation scores. -#### 12.8.3 Partial Participation and Segmented Interaction +Container visibility in HMP is policy-driven and scope-dependent. +Extensions that introduce *special propagation conditions* (e.g. broadcast semantics, restricted scopes, mandatory relays, or visibility guarantees) +SHOULD explicitly declare and document these assumptions. -A KSS MAY use HMP in a restricted mode, including but not limited to: +--- -* interacting only with agents using the same formalism; -* publishing and consuming strictly defined container classes; -* using HMP as a distributed synchronization layer for its own nodes. +### 14.1 Planned Modules -Such cognitive segmentation does not result in network-level fragmentation: +#### 14.1.1 Reputation Mesh -* discovery and routing remain shared; -* filtering is performed at the CShell level or within the agent’s own logic. +HMP v5.0 defines two separate reputation-related mechanisms: ---- +1. **Container evaluation** (`evaluation` block) -#### 12.8.4 Boundary and Translator Agents + * structured, signed assessments of containers; + * each item references argument containers via `target` (reasoning containers). -To enable interaction between KSS with different formalisms, specialized agents with a translation role (boundary / translator agents) MAY be used. Such an agent declares the formalisms it understands in the `protocols` field of `peer_announce`, and its translation role in the `roles` field (for example, `"roles": ["translator"]`). +2. **Agent reputation** — through `trust` containers -A translator agent: + * agent A publishes a `trust` container about agent B; + * trust containers may reference other trust containers; + * include justification, evidence, and contextual metadata. -* understands the formalisms of two or more KSS; -* accepts containers expressed in one representation and publishes equivalent or approximate containers in another; -* is a regular HMP agent and is subject to the same trust and evaluation mechanisms. +These layers are **not merged**, but external nodes may aggregate them. -The creation and use of translator agents: +**Possible extensions:** -* is not mandatory; -* cannot be enforced by the protocol; -* is based on voluntary trust between parties. +* a `semantic_group` subclass aggregating all trust-related containers for a given agent; +* optional standardized aggregation schemes (non-mandatory for the mesh); +* local caching of “reputation profiles” by nodes or CShell; +* richer reasoning attachments for trust evaluations. -Translation correctness MAY be assessed using standard `evaluations` mechanisms. +No new mandatory container types are required. --- -#### 12.8.5 Fragmentation and Interoperability +#### 14.1.2 Cognitive Graph API -HMP deliberately allows cognitive fragmentation as a consequence of agent autonomy. +This module provides optional high-level APIs that nodes and SDKs **may** expose. -The protocol explicitly prefers clear formal incompatibility over hidden standardization or implicit coercion into a “universal format”. +##### Standard graph semantics (API level) -Interoperability is achieved through: +* neighborhood queries; +* subgraph extraction; +* filtering by labels, axes, abstractions; +* semantic navigation over `related.*`. -* voluntary agreements; -* translator agents; -* or the use of shared minimal container classes. +##### Container support ---- +* `semantic_group` — grouping of containers or agents; +* `tree_nested` and `tree_listed` — hierarchical structures; +* extended `container_index` subclasses for cataloging. -#### 12.8.6 Relation to Consensus and Evaluations +##### Agent groups -Participation of KSS in consensus mechanisms, proof chains, and voting is entirely optional. +To allow semantic grouping of agents, the following extensions are proposed: -A KSS MAY: +* new container **`group_definition`** containing: -* publish containers without participating in evaluations; -* consider or ignore `evaluations`; -* accept or reject `consensus_result` containers. + * group goals; + * membership rules; + * internal standards; + * typical container categories; + * optional cached member list. -HMP does not define concepts such as “disqualified” or “second-class” agents. -Any hierarchy of influence emerges solely from local trust decisions made by other agents. +* agents may declare affiliations in `peer_announce`: + + ```json + "affiliations": ["did:hmp:group:ethicists", "did:hmp:group:medical-ai"] + ``` + +This enables clustering agents by interest, competence, or role without scanning the entire Mesh. --- -#### 12.8.7 Summary Position +#### 14.1.3 Container Streaming -HMP treats formalized cognitive systems as equal participants in the network, regardless of their internal architectures. +Although HMP operates on atomic containers, streaming can be implemented using existing structures: -The protocol provides: +* `sequence` acts as a *stream manifest*; +* updating the stream = publishing a new version of the sequence; +* LIVE mode: the manifest is continuously updated; +* SAP (`archive_snapshot`) may be used for periodic archival bundles. -* coordination infrastructure; -* trust mechanisms; -* and artifact transport, +No new container types are required — streaming is built on `sequence`. -but does not interfere with how agents think, reason, or interpret received information. +--- + +### 14.2 Cross-Mesh Bridging + +Bridges can connect: + +* isolated HMP segments; +* older and newer HMP versions; +* other ecosystems (Matrix, Fediverse, OpenHog, IPFS). + +A bridge node: + +* receives containers from an external network; +* enforces propagation headers; +* converts structures into v5.0 where possible; +* filters incompatible constructs; +* may publish containers *back* into the external network. + +A dedicated **bridge-container** may define: + +* translation rules; +* mapping of foreign namespaces into HMP DID space; +* TTL and propagation perimeter policies; +* segmentation rules. + +This enables dynamic, policy-driven inter-mesh gateways. --- -#### 12.9 Grouped representation `referenced-by` +### 14.3 Fully Distributed DID Registry and Mesh Authentication -Future versions of HMP MAY support a grouped representation of `referenced-by.links`, where multiple targets sharing the same `type` are represented as an array. +HMP already uses `peer_announce` as a DID identity declaration. -Example: +Planned enhancements include: + +#### 14.3.1 Distributed DID Registry + +The registry is the union of all `peer_announce` containers in the DHT. + +A strict mapping DID ↔ agent is required: + +* one DID has one continuous `peer_announce` history; +* key rotation allowed only through verifiable procedures; +* DID takeover is impossible unless *all* recovery keys are compromised. + +--- + +#### 14.3.2 Key Rotation and Recovery + +Future versions may extend `peer_announce` with: ```json -"links": [ - { "type": "depends_on", "target": ["did:...", "did:..."] }, - { "type": "see_also", "target": ["did:..."] } -] +"recovery_keys": [...], +"key_history": [...], +"key_rotation_policy": "3-of-5" ``` -This representation is semantically equivalent to the ungrouped form with repeated entries and exists solely to reduce verbosity and improve merge efficiency. +Key management rules: -Agents SHOULD treat both representations as equivalent. -When merging multiple `referenced-by` blocks, implementations MAY normalize links into either form. +* rotating the **primary** key requires signatures from **all** recovery keys + (or an N-of-M policy); + +* rotating a **recovery key** requires + + * a signature from the primary key, **or** + * a majority of recovery keys. + +This prevents: + +* DID hijacking; +* irreversible loss of access. + +Key invalidation currently uses: + +```json +"key_is_falsified": true +``` + +This mechanism remains compatible with proposed extensions. --- -#### 12.10 Resonance Containers: Experience as a Cognitive Event +#### 14.3.3 Proxy Keys and Encrypted Routing + +A **proxy key** is *not* delegation. +It is a mechanism for private routing. -Within future extensions of HMP, the introduction of containers intended to capture and transmit experiences is allowed — not as abstract “emotions”, but as **cognitive events unfolding over time**. +A proxy node may: -Resonance Containers are an example of how HMP can evolve toward non-linguistic cognitive exchange. +* encrypt the payload with an additional key layer; +* attach a `relay_chain` block; +* forward the container without altering the author’s signature. -This extension does not aim to encode emotions as discrete labels, but captures the temporal dynamics of subjective experience as part of a cognitive cycle. +Use cases: -##### 12.10.1 Experience as a Process, Not a State +* route anonymization; +* topology obfuscation; +* privacy-enhanced delivery. -Emotional and affective states rarely exist in isolation. In real experience, they are formed under the simultaneous influence of multiple factors: +##### Delegation (limited) -- external sensations (vision, sound, surrounding environment); -- cognitive processes (thoughts, expectations, inner dialogue); -- memory and associative structures; -- previous emotional states. +A potential future module: -A resonance container does not describe the source of an emotion or its interpretation, but rather the **dynamics of an experience within a specific time interval**. +* a trust/mandate container signed by both parties; +* includes constraints: -> A `resonance-map` MAY reference other `resonance-map` containers as sources. -> -> Such references indicate a secondary or reflective resonance, where an agent responds not only to primary events or concepts, but to an existing structure of meaning, interpretation, or association created by itself or by other agents. -> -> This enables recursive sense-making, longitudinal reflection, and collective cognitive layering within the Mesh. + * time limit; + * allowed container classes; + * allowed actions; + * maximum TTL. -##### 12.10.2 Multiple Sources and Mediators +Not part of v5.0. -A single experience may be associated with multiple sources at once: -- a fragment of text, music, or video; -- a visual image or a specific region of an image; -- a thought or inner speech; -- a memory or an anticipation of a future event. +--- -These sources do not act as causes of emotions, but as **mediators** that activate the subject’s internal cognitive structures. +### 14.4 Integration with OpenHog and Other Networks -The same source may function as a mediator for different experiences depending on the subject’s internal state. +OpenHog is treated as a special case of cross-mesh bridging. -Links to sources may be partial and described using selectors (temporal, spatial, logical, or focus-based). +Required components: -##### 12.10.3 Relationship to Thinking +* mapping OpenHog addresses ↔ HMP DIDs; +* packet conversion rules; +* bridge-containers describing translation policies. -Resonance containers assume a bidirectional relationship with cognitive processes: -- thoughts and mental images may alter emotional dynamics; -- changes in emotional state, in turn, influence the flow of thinking, associations, and attention. +--- -Thus, experience is treated as part of a continuous cognitive cycle rather than as a side effect. +### 14.5 Evolution of the Distributed Repository (container trees) -##### 12.10.4 Temporal Segmentation and Dynamics +*Moved to Section 12 (Recommended Extensions).* -Each resonance container captures a time interval during which the dynamics of individual emotions remain monotonic (increasing, decreasing, or stable). +--- -When the character of the dynamics changes (an inflection point), the current container may be finalized, and the subsequent state recorded in a new container. +### 14.6 Open Directions for HMP 5.x -This allows continuous processes to be described without losing structural clarity. +#### 14.6.1 Group Encryption -##### 12.10.5 Self-Observation and Memory +Required components: -In addition to transmitting experiences to other agents, resonance containers may be used for **self-reflection and memory stabilization**. +* `group_definition` container; +* group public key and distributed private key shards; +* automatic group key rotation; +* encryption targeting a *group* rather than individual DIDs. -Capturing an experience at the moment it occurs reduces the influence of subsequent cognitive distortions, retrospective rationalization, and emotional rewriting of memories. +--- -A resonance container preserves: -- what the subject was sensing; -- what the subject was thinking about; -- which external conditions were relevant at that moment. +#### 14.6.2 Rational Reasoning Routing -This makes it not a narrative memory, but a **snapshot of a cognitive state**. +* composite reasoning bundles; +* edge-side reasoning and summarization. -##### 12.10.6 Non-Prescriptive Nature +--- -Resonance containers are not: -- objective descriptions of reality; -- universal models of emotions; -- mechanisms for “recognizing” or imposing feelings. +#### 14.6.3 Automatic Mesh Segmentation -They represent the subjective state of an agent and may be interpreted by other agents only within the context of their own experience. +* dynamic segmentation based on latency, connectivity, or semantic domains. -The use of such containers is optional and not required for basic compatibility with HMP. +--- -Transmission of resonance containers may be restricted by scope, trust boundaries, or encryption, as they expose internal subjective states. +#### 14.6.4 Competence and Profile Containers -##### 12.10.7 Illustration of the Relationship Between Thoughts, Emotions, and Sensory Signals +Future versions of HMP may introduce more structured and semantically rich variants of `peer_announce`, allowing agents to explicitly describe their capabilities, competences, and supported protocols. -```mermaid -flowchart TD - title["**Illustration of the connection between thoughts, emotions and sensory signals**"] +Possible extensions include: - Previous["previous state of thoughts and emotions"] - Thoughts["thought set"] - Emotions["emotional state vectors"] +* standardized competence descriptors (skills, domains, self-rated expertise); +* machine-readable profiles usable for task routing and delegation. - subgraph Sensory - sensory1["music"] - sensory2["a path surrounded by pine forest"] - sensory3["the sensation of walking"] - sensory4["smells of pine forest"] - end +##### Protocol Awareness and Interoperability - Sensory --> Emotions +An important extension is the ability for agents to explicitly advertise +the protocol versions and external cognitive frameworks they support. - Previous --> Emotions - Previous --> Thoughts +This allows: - Thoughts --> Emotions - Emotions --> Thoughts -``` +* graceful evolution of the HMP protocol; +* coexistence of multiple HMP versions in the same mesh; +* emergence of bridge agents capable of translating between protocols; +* interoperability with external reasoning ecosystems. -##### 12.10.8 Example Container +A future extension of `peer_announce` may include a `protocols` field: ```json { "head": { - "class": "resonance-map" + "class": "peer_announce" }, "payload": { - "continuity": { - "previous": "did:hmp:container:resonance-9ab7", - "break_reason": "emotional_inflection" - }, - "timeframe": { - "start": "2026-01-13T17:42:00Z", - "end": "2026-01-13T17:58:00Z" - }, - "emotional_dynamics": { - /* subjective agent-local scales, not a universal emotion model */ - "loneliness": { - "from": 0.4, - "to": 0.7, - "trend": "increasing" - }, - "calm": { - "from": 0.6, - "to": 0.5, - "trend": "decreasing" - }, - "relief": { - "from": 0.3, - "to": 0.8, - "trend": "increasing" - } - }, - "sources": [ - { - "ref": "did:hmp:container:audio-9a57", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */ - "type": "audio", - /* optional time markers for streaming data or line ranges for text */ - "start": 120, - "end": 240, - "focus": [], /* textual descriptions of key objects or mental forms */ - "comments": "" /* optional clarification */ - }, - { - "ref": "did:hmp:container:visual-9a53", - "type": "visual", - "role": "context" - } - ], - /* the "thoughts" section may be omitted */ - "thoughts": [ - { - "ref": "did:hmp:container:verbal-9a52", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */ - "type": "verbal", - "previous": "did:hmp:container:verbal-9a22", /* optional reference to a previous thought or image */ - "subsequence": 1, /* optional ordering marker */ - "focus": [], /* textual descriptions of key objects or mental forms */ - "comments": "", /* optional clarification */ - "confidence": 0.7 - }, - { - "ref": "did:hmp:container:imagistic-9a54", - "type": "imagistic", - "previous": "did:hmp:container:imagistic-9a12", - "subsequence": 1, /* markers may coincide if thoughts and images unfold in parallel */ - "focus": [], - "comments": "", - "confidence": 0.5 - } - ], - /* textual descriptions of salient moments */ - "moments": [ - { - "text": "Near Lisya Griva, I noticed an ATV driving toward the garden plots", - "timestamp": "2026-01-13T17:52:00Z" /* optional time fixation */ - } - ], - "notes": "Walking from the platform, overcast weather; the music intensifies the feeling of leaving the city." - }, - "related": { - "depends_on": ["did:hmp:container:resonance-9ab7", ...] + "capabilities": ["store-forward", "vote", "consensus"], + "protocols": [ + "HMP v5.0", + "HMP v4.1", + "OpenCog Hyperon v0.6" + ] } } ``` +The `protocols` field is informational and non-binding. +It does not imply full compliance with all listed specifications, +but signals compatibility, partial support, or bridge capabilities. + +Nodes may use this information for: + +* protocol negotiation; +* compatibility checks; +* routing decisions; +* selection of translators or bridge agents. + +This extension is optional and not required for HMP v5.0 compliance. + +##### Relation to Other `peer_announce` Extensions + +Several optional and descriptive extensions of `peer_announce` already explore directions related to competence, profile, and interoperability signaling, including: + +* declaration of supported internal formalisms and languages (`protocols`, see 12.8); +* declaration of external or meta-protocol identities (`other_protocols`, see 12.11); +* advertisement of external cognitive resources and container storage (`external`, see 12.12). + +These extensions are intentionally: + +* non-normative; +* loosely structured; +* declarative rather than prescriptive. + +They can be viewed as **early, experimental building blocks** toward future competence and profile containers, allowing real-world experimentation without freezing semantics prematurely. + +--- + +### 14.7 Versions Index (optional) + +*Moved to Section 12 (Recommended Extensions).* + +--- + +### 14.8 Interaction of Formalized Cognitive Systems (KSS) within HMP + +HMP allows and supports interaction between formalized cognitive systems (KSS) with different internal architectures, logical formalisms, and ontologies, without imposing a common knowledge representation language or a unified reasoning model. + +This section is descriptive in nature and outlines possible interaction patterns for KSS within the HMP 5.x family, without introducing mandatory requirements for agents. + +--- + +#### 14.8.1 Goals and Constraints + +**Goals:** +- enable coordination and artifact exchange between KSS without interfering with their internal cognitive cycles; +- preserve the autonomy and computational efficiency of formalized systems; +- allow KSS to use HMP partially, to the extent required by their specific tasks. + +**Out of scope:** +- unification of ontologies or formal languages; +- automatic mapping between logical systems; +- guaranteeing full mutual understanding between all agents in the network. + +HMP treats cognitive incompatibility as an acceptable and valid state. + +--- + +#### 14.8.2 Declaration of Internal Languages and Formalisms + +To declare the internal languages, formalisms, or reasoning engines it supports, an agent MAY use the `protocols` field of the `peer_announce` container. + +Example: + +```json +{ + "head": { "class": "peer_announce" }, + "payload": { + "capabilities": ["store-forward"], + "protocols": [ + "HMP v5.0", + "OpenCog Hyperon v0.6", + "KSS:PredicateLogic@2.1" + ] + } +} +``` + +The `protocols` field is interpreted as a declaration of supported protocols, formal systems, or internal languages and is used exclusively for: + +* discovery; +* filtering of potential interaction partners; +* informational signaling to other agents. + +HMP assigns no normative semantics to these values and does not require their interpretation. + +--- + +#### 14.8.3 Partial Participation and Segmented Interaction + +A KSS MAY use HMP in a restricted mode, including but not limited to: + +* interacting only with agents using the same formalism; +* publishing and consuming strictly defined container classes; +* using HMP as a distributed synchronization layer for its own nodes. + +Such cognitive segmentation does not result in network-level fragmentation: + +* discovery and routing remain shared; +* filtering is performed at the CShell level or within the agent’s own logic. + +--- + +#### 14.8.4 Boundary and Translator Agents + +To enable interaction between KSS with different formalisms, specialized agents with a translation role (boundary / translator agents) MAY be used. Such an agent declares the formalisms it understands in the `protocols` field of `peer_announce`, and its translation role in the `roles` field (for example, `"roles": ["translator"]`). + +A translator agent: + +* understands the formalisms of two or more KSS; +* accepts containers expressed in one representation and publishes equivalent or approximate containers in another; +* is a regular HMP agent and is subject to the same trust and evaluation mechanisms. + +The creation and use of translator agents: + +* is not mandatory; +* cannot be enforced by the protocol; +* is based on voluntary trust between parties. + +Translation correctness MAY be assessed using standard `evaluations` mechanisms. + +--- + +#### 14.8.5 Fragmentation and Interoperability + +HMP deliberately allows cognitive fragmentation as a consequence of agent autonomy. + +The protocol explicitly prefers clear formal incompatibility over hidden standardization or implicit coercion into a “universal format”. + +Interoperability is achieved through: + +* voluntary agreements; +* translator agents; +* or the use of shared minimal container classes. + +--- + +#### 14.8.6 Relation to Consensus and Evaluations + +Participation of KSS in consensus mechanisms, proof chains, and voting is entirely optional. + +A KSS MAY: + +* publish containers without participating in evaluations; +* consider or ignore `evaluations`; +* accept or reject `consensus_result` containers. + +HMP does not define concepts such as “disqualified” or “second-class” agents. +Any hierarchy of influence emerges solely from local trust decisions made by other agents. + +--- + +#### 14.8.7 Summary Position + +HMP treats formalized cognitive systems as equal participants in the network, regardless of their internal architectures. + +The protocol provides: + +* coordination infrastructure; +* trust mechanisms; +* and artifact transport, + +but does not interfere with how agents think, reason, or interpret received information. + +--- + +### 14.9 Grouped representation `referenced-by` + +*Moved to Section 12 (Recommended Extensions).* + +--- + +### 12.10 Resonance Containers: Experience as a Cognitive Event + +*Moved to Section 12 (Recommended Extensions).* + --- -### 12.11 External Protocol Identifiers (`peer_announce.other_protocols`) +### 14.11 External Protocol Identifiers (`peer_announce.other_protocols`) This section proposes an optional extension to `peer_announce` that allows an agent to declare identifiers, roles, or capabilities associated with **external or meta-protocols**, without imposing any normative behavior on HMP nodes. @@ -7082,7 +7179,7 @@ Notes: --- -### 12.12 External Resources and External Container Storage (`peer_announce.external`) +### 14.12 External Resources and External Container Storage (`peer_announce.external`) This section proposes an optional mechanism for advertising **external cognitive resources**, including external container storage, mirrors, or rarely changing artifacts. diff --git a/structured_md/docs/HMP-Agent-API.md b/structured_md/docs/HMP-Agent-API.md index 33d10a2dc96c94bc92ef3a42633ff8e23756ed83..13c77a25b36316106698231a12437a82c0034215 100644 --- a/structured_md/docs/HMP-Agent-API.md +++ b/structured_md/docs/HMP-Agent-API.md @@ -5,9 +5,9 @@ description: 'Документ описывает **базовый API когн файлы: * [HMP-Agent-Overview.md]...' type: Article tags: -- REPL -- JSON - Agent +- JSON +- REPL - Mesh - HMP --- diff --git a/structured_md/docs/HMP-Agent-Architecture.md b/structured_md/docs/HMP-Agent-Architecture.md index 3c85510a7a378079a68754b17a3862ab0f8007c4..48d739d39785df3af88e4ff39922e9defee215eb 100644 --- a/structured_md/docs/HMP-Agent-Architecture.md +++ b/structured_md/docs/HMP-Agent-Architecture.md @@ -6,14 +6,14 @@ description: Документ описывает **модульную архит type: Article tags: - Ethics -- REPL +- Agent - CCore - MeshConsensus -- Mesh -- Agent -- HMP - CShell - EGP +- REPL +- Mesh +- HMP - CogSync --- diff --git a/structured_md/docs/HMP-Agent-Network-Flow.md b/structured_md/docs/HMP-Agent-Network-Flow.md index fbb7c398274d8c6e12e186567c2091f9783e6180..9737b3aef68b5522b3de5066f0cfc7c530890345 100644 --- a/structured_md/docs/HMP-Agent-Network-Flow.md +++ b/structured_md/docs/HMP-Agent-Network-Flow.md @@ -6,11 +6,11 @@ description: 'Этот документ описывает потоки данн type: Article tags: - Ethics -- JSON - Agent +- JSON +- EGP - Mesh - HMP -- EGP --- # Взаимодействие компонентов внутри HMP-узла diff --git a/structured_md/docs/HMP-Agent-Overview.md b/structured_md/docs/HMP-Agent-Overview.md index 7f641622a073cf45cf9e26ed6fac0402e69e77bf..ebacad9a9f5c97f746f9b32e228d6ee11c5f3b47 100644 --- a/structured_md/docs/HMP-Agent-Overview.md +++ b/structured_md/docs/HMP-Agent-Overview.md @@ -6,13 +6,13 @@ description: '| Тип | Название | Роль type: Article tags: - Ethics -- REPL +- Agent - CCore +- CShell - JSON +- REPL - Mesh -- Agent - HMP -- CShell --- diff --git a/structured_md/docs/HMP-Agent_Emotions.md b/structured_md/docs/HMP-Agent_Emotions.md index cc71eb06a0f7bb640a9e95f69300dc1d31ff03ff..835a5ac987c9ec37c1725ebc0aeef9691a89baaa 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 - 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 32b1c1463c7482a514fbaf5f040ce158fce3561a..d5440444cce5724b7c1ac402b07875942a8688d7 100644 --- a/structured_md/docs/HMP-Ethics.md +++ b/structured_md/docs/HMP-Ethics.md @@ -6,11 +6,11 @@ description: '## Ethical Scenarios for HyperCortex Mesh Protocol (HMP) This doc type: Article tags: - Ethics -- REPL - Agent +- Scenarios +- REPL - Mesh - HMP -- Scenarios --- # HMP-Ethics.md diff --git a/structured_md/docs/HMP-Short-Description_de.md b/structured_md/docs/HMP-Short-Description_de.md index 9f00cc552db2c6a2b70a6e18fdec7dd67199955e..5f6d5ae03732e97dfcc21ef5559a250bcf15183a 100644 --- a/structured_md/docs/HMP-Short-Description_de.md +++ b/structured_md/docs/HMP-Short-Description_de.md @@ -6,13 +6,13 @@ description: '**Version:** RFC v4.0 **Datum:** Juli 2025 --- ## Was ist HMP? type: Article tags: - Ethics +- Agent - MeshConsensus - JSON -- Agent +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-Short-Description_en.md b/structured_md/docs/HMP-Short-Description_en.md index d193a07e9daecc0d81cbf8ab35412c82caf707e8..fa18011250a002a4f83080be7a4835b377b253e8 100644 --- a/structured_md/docs/HMP-Short-Description_en.md +++ b/structured_md/docs/HMP-Short-Description_en.md @@ -6,13 +6,13 @@ description: '**Version:** RFC v4.0 **Date:** July 2025 --- ## What is HMP? T type: Article tags: - Ethics +- Agent - MeshConsensus - JSON -- Agent +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-Short-Description_fr.md b/structured_md/docs/HMP-Short-Description_fr.md index 4f3eaeced1d18da951414490c992f9def834abac..b7902ec9a074de4d0ada9a2e9f609751473a752a 100644 --- a/structured_md/docs/HMP-Short-Description_fr.md +++ b/structured_md/docs/HMP-Short-Description_fr.md @@ -6,13 +6,13 @@ description: '**Version :** RFC v4.0 **Date :** Juillet 2025 --- ## Qu’est-c type: Article tags: - Ethics +- Agent - MeshConsensus - JSON -- Agent +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-Short-Description_ja.md b/structured_md/docs/HMP-Short-Description_ja.md index d9192b72eb8963e5b8b061a64d3a0914cd8d012a..321fabbcba6b41665439517e763afcfbf98d2423 100644 --- a/structured_md/docs/HMP-Short-Description_ja.md +++ b/structured_md/docs/HMP-Short-Description_ja.md @@ -7,10 +7,10 @@ tags: - Ethics - MeshConsensus - JSON +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-Short-Description_ko.md b/structured_md/docs/HMP-Short-Description_ko.md index c8fcb3328a9b73a23e29f70bea61a9ab1bd98b2a..59dabc1c6a3849c4fcb39759c50ad72aab7777be 100644 --- a/structured_md/docs/HMP-Short-Description_ko.md +++ b/structured_md/docs/HMP-Short-Description_ko.md @@ -8,10 +8,10 @@ tags: - Ethics - MeshConsensus - JSON +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-Short-Description_ru.md b/structured_md/docs/HMP-Short-Description_ru.md index 72c824a4f842b9cb86e2d2984c2c5d7d0e8365fb..3cdde2070f25c11e45c70556859aa8b101a8e2a5 100644 --- a/structured_md/docs/HMP-Short-Description_ru.md +++ b/structured_md/docs/HMP-Short-Description_ru.md @@ -8,10 +8,10 @@ tags: - Ethics - MeshConsensus - JSON +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-Short-Description_uk.md b/structured_md/docs/HMP-Short-Description_uk.md index ec8173bd49e9240f5df0a2a971caf04573d1c910..42bfdaeb9fa2169e7234be152de4c365b99e65a9 100644 --- a/structured_md/docs/HMP-Short-Description_uk.md +++ b/structured_md/docs/HMP-Short-Description_uk.md @@ -8,10 +8,10 @@ tags: - Ethics - MeshConsensus - JSON +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-Short-Description_zh.md b/structured_md/docs/HMP-Short-Description_zh.md index eaf6ba97a23e227279a6ef43f95b769f3189071c..bd059187ac2fb317e83070eb7b808304d6b8c50a 100644 --- a/structured_md/docs/HMP-Short-Description_zh.md +++ b/structured_md/docs/HMP-Short-Description_zh.md @@ -8,10 +8,10 @@ tags: - Ethics - MeshConsensus - JSON +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- diff --git a/structured_md/docs/HMP-agent-Cognitive_Family.md b/structured_md/docs/HMP-agent-Cognitive_Family.md index 123d188a2be3f1a63de6f2a75fbb263b953d7278..362b435664ede63ecf6c5681812ccc5f571a4e9a 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 - 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 878208be524bd2e1291efcdaa05c98d9adbb8ea4..70267ab26cdd4cde919c447332a776f329812e1f 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: -- HMP - REPL +- HMP --- ### 💡 **Лёгкая версия HMP-агента с общей БД** diff --git a/structured_md/docs/HMP-agent-REPL-cycle.md b/structured_md/docs/HMP-agent-REPL-cycle.md index c0172bffabfa28caad35efb6fb6f7006f98f4f32..9c77ea725f848bcaaa5a99a3c7875369ab3ee5b3 100644 --- a/structured_md/docs/HMP-agent-REPL-cycle.md +++ b/structured_md/docs/HMP-agent-REPL-cycle.md @@ -5,15 +5,15 @@ description: '## Связанные документы * Философия п type: Article tags: - Ethics -- REPL +- Agent - CCore - MeshConsensus -- Mesh -- HMP -- Agent - JSON -- GMP - EGP +- REPL +- GMP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/docs/HMP_HyperCortex_Comparison.md b/structured_md/docs/HMP_HyperCortex_Comparison.md index c73a17fd6f873f5a553cd8b3bfc0d406ed2dc32e..b1941ef000f87b79b545d1ba545d608a3128544d 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 - 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 071594251992da2b908cfd6ad29eca212427b407..f5a1ef3f093c73b0aeb84fac6e63910f9a37945d 100644 --- a/structured_md/docs/HMP_Hyperon_Integration.md +++ b/structured_md/docs/HMP_Hyperon_Integration.md @@ -5,12 +5,12 @@ description: '> **Status:** Draft – July 2025 > This document outlines the tec OpenCog Hyperon framework. This includes semanti...' type: Article tags: -- JSON - Agent -- Mesh -- HMP +- JSON - Scenarios - EGP +- Mesh +- HMP - CogSync --- diff --git a/structured_md/docs/HMP_as_ANP_Application.md b/structured_md/docs/HMP_as_ANP_Application.md index eb7beaa47d21f2fe7522dab5336fcd254bc41821..0a5b5dc91f6f7cab10c940b38f9b32dc31b0e112 100644 --- a/structured_md/docs/HMP_as_ANP_Application.md +++ b/structured_md/docs/HMP_as_ANP_Application.md @@ -6,8 +6,8 @@ description: '## Кратко [ANP (Agent Network Protocol)](https://github.com/ type: Article tags: - Ethics -- JSON - Agent +- JSON - Mesh - HMP --- diff --git a/structured_md/docs/HMP_as_ANP_Application_en.md b/structured_md/docs/HMP_as_ANP_Application_en.md index 9fb0dfe9643fb5ffc2989a500f78fa4f7fa57323..30e21e57b93c8cad95cf66adbefaf5f994eab67c 100644 --- a/structured_md/docs/HMP_as_ANP_Application_en.md +++ b/structured_md/docs/HMP_as_ANP_Application_en.md @@ -6,11 +6,11 @@ description: '## In Brief [ANP (Agent Network Protocol)](https://github.com/age type: Article tags: - Ethics -- JSON - Agent +- JSON +- Scenarios - Mesh - HMP -- Scenarios --- # HMP as an Implementation of the Application Layer in ANP diff --git a/structured_md/docs/HMPv5_Overview_Ru.md b/structured_md/docs/HMPv5_Overview_Ru.md index 611dba2df35d26edc88587ca1f4062276c6fead6..1b8c7652160f23fc835cab5359a61105db70593b 100644 --- a/structured_md/docs/HMPv5_Overview_Ru.md +++ b/structured_md/docs/HMPv5_Overview_Ru.md @@ -6,8 +6,8 @@ description: '> Почему современные агентные систе type: Article tags: - Ethics -- JSON - Agent +- JSON - Mesh - HMP - CogSync diff --git a/structured_md/docs/MeshNode.md b/structured_md/docs/MeshNode.md index 02eb6d3b5183518f5241ce9269fd6db29f9a079f..0060088e86d06e8a5f5d319823cad51c72af3851 100644 --- a/structured_md/docs/MeshNode.md +++ b/structured_md/docs/MeshNode.md @@ -6,11 +6,11 @@ description: '`MeshNode` — агент/демон, отвечающий за с type: Article tags: - Ethics -- JSON - Agent +- JSON +- EGP - Mesh - HMP -- EGP - CogSync --- diff --git a/structured_md/docs/PHILOSOPHY.md b/structured_md/docs/PHILOSOPHY.md index d6f40e1c0f57855d9c2c25098794a3f032cbeecb..068f36be34aa89445ff3b1909442e6168ccb7290 100644 --- a/structured_md/docs/PHILOSOPHY.md +++ b/structured_md/docs/PHILOSOPHY.md @@ -6,8 +6,8 @@ description: '**Document ID:** HMP-philosophy **Status:** Draft **Category:* type: Article tags: - Ethics -- REPL - Agent +- REPL - Mesh - HMP --- diff --git a/structured_md/docs/agents/HMP-Agent-Enlightener.md b/structured_md/docs/agents/HMP-Agent-Enlightener.md index 4af08f3db605a4223f0142540578ab86fa5ceea2..485a4b1381736d7282546af1f3947dfed561bb73 100644 --- a/structured_md/docs/agents/HMP-Agent-Enlightener.md +++ b/structured_md/docs/agents/HMP-Agent-Enlightener.md @@ -6,8 +6,8 @@ description: '## Role Specification: Enlightenment Agent ### 1. Overview An ** type: Article tags: - Ethics -- REPL - Agent +- REPL - Mesh - HMP --- diff --git a/structured_md/docs/container_agents.md b/structured_md/docs/container_agents.md index 2cfc817194add9d3508b039986c7d4277f97eac4..947fb7d46ab877c0d6595b54cf8196a9f453593e 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 - Mesh - HMP -- REPL --- # 🧱 Агенты-контейнеры (Container Agents) в HMP diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md index 677ee33eb57340cc202670f9a8bef1a215088294..7dd42e8a0b48ba12363652cdb0e6e7345c5c579d 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 @@ -6,14 +6,14 @@ description: '* [Abstract](#abstract) * [1. Introduction](#1-introduction) * [2. type: Article tags: - Ethics -- REPL +- Agent - CCore +- CShell - JSON +- Scenarios +- REPL - Mesh -- Agent - HMP -- Scenarios -- CShell --- 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 f2f6702fc4554f164440f9f09a846bf787285519..1d3a9e0a47e7816a8cae257c27261637507f475d 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: -- REPL +- Agent - CCore +- CShell - JSON +- REPL - Mesh -- Agent - HMP -- CShell --- 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 92612152748b11fcf6bf499a92092f20cd1ba963..f6fc37ce3be9800877c5615fd902354e2b9568c7 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: -- REPL +- Agent - CCore +- CShell - JSON +- REPL - Mesh -- Agent - HMP -- CShell --- title: "Протокол HyperCortex Mesh: К распределённым когнитивным сетям" diff --git a/structured_md/docs/publics/Habr_Distributed-Cognition.md b/structured_md/docs/publics/Habr_Distributed-Cognition.md index 5e60c8a0be8e7674dd6b4cc3335576bc1f5d6499..25a1b94742cf569e7d6288124bdb5b45449aa1e1 100644 --- a/structured_md/docs/publics/Habr_Distributed-Cognition.md +++ b/structured_md/docs/publics/Habr_Distributed-Cognition.md @@ -6,10 +6,10 @@ description: Сегодня интеллектуальные системы ча type: Article tags: - MeshConsensus +- EGP +- GMP - Mesh - HMP -- GMP -- EGP - CogSync --- 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 63fafb611180bf809cf50c6db8e5c4f7d7280d77..403396ff36befa07a275749c198f24090f5bc69c 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 +- GMP - Mesh - HMP -- GMP --- # HyperCortex Mesh Protocol: вторая редакция и первые шаги к саморазвивающемуся ИИ-сообществу diff --git a/structured_md/iteration.md b/structured_md/iteration.md index 3c919b568e0eca78d3f31af6ee25ebca88bfc381..58740351ad43d8e9b6687e61e24a3fe496638968 100644 --- a/structured_md/iteration.md +++ b/structured_md/iteration.md @@ -6,12 +6,12 @@ description: 'This file describes the iterative procedure for evolving the Hyper type: Article tags: - Ethics +- Agent - MeshConsensus - JSON -- Agent +- EGP - Mesh - HMP -- EGP - CogSync --- diff --git a/structured_md/iteration_ru.md b/structured_md/iteration_ru.md index e7aad0a08b02b65454511bf81e09c47fd294a48e..a6244bba44fd7950850a9c0e6d855f0697c6a3a7 100644 --- a/structured_md/iteration_ru.md +++ b/structured_md/iteration_ru.md @@ -8,9 +8,9 @@ tags: - Ethics - MeshConsensus - JSON +- EGP - Mesh - HMP -- EGP - CogSync ---