Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -1967,7 +1967,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.
 
 ---
 
@@ -6129,7 +6129,503 @@ The project may include:
 These implementations are not part of the specification but are useful for compatibility testing and accelerating adoption.
 
 ---
-## 12. Future Extensions
+
+## 12. Recommended Extensions
+
+Recommended Extensions are fully specified modules that extend the capabilities of HMP while remaining compatible with the core protocol semantics.
+
+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.
+
+Agents MUST safely ignore unknown or unsupported extensions.
+
+Extensions in this section:
+
+- 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.
+
+Implementers are encouraged to treat this section as the primary extension surface for building production-oriented agents.
+
+---
+
+### 12.1 Resonance Containers: Experience as a Cognitive Event
+
+HMP allows the introduction of containers intended to capture and transmit experiences — not as abstract “emotions”, but as **cognitive events unfolding over time**.
+
+Resonance Containers illustrate a direction in which HMP supports non-linguistic cognitive exchange between agents.
+
+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.
+
+#### 12.1.1 Experience as a Process, Not a State
+
+Emotional and affective states rarely exist in isolation. In real experience, they are formed under the simultaneous influence of multiple factors:
+
+- external sensations (vision, sound, surrounding environment);
+- cognitive processes (thoughts, expectations, inner dialogue);
+- memory and associative structures;
+- previous emotional states.
+
+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 `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
+
+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.
+
+The same source may function as a mediator for different experiences depending on the subject’s internal state.
+
+Links to sources may be partial and described using selectors (temporal, spatial, logical, or focus-based).
+
+#### 12.1.3 Relationship to Thinking
+
+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.
+
+#### 12.1.4 Temporal Segmentation and Dynamics
+
+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.
+
+This allows continuous processes to be described without losing structural clarity.
+
+#### 12.1.5 Self-Observation and Memory
+
+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.
+
+A resonance container preserves:
+- what the subject was sensing;
+- what the subject was thinking about;
+- which external conditions were relevant at that moment.
+
+This makes it not a narrative memory, but a **snapshot of a cognitive state**.
+
+#### 12.1.6 Non-Prescriptive Nature
+
+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.
+
+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.
+
+#### 12.1.7 Illustration of the Relationship Between Thoughts, Emotions, and Sensory Signals
+
+```mermaid
+flowchart TD
+    title["**Illustration of the connection between thoughts, emotions and sensory signals**"]
+
+    Previous["previous state of thoughts and emotions"]
+    Thoughts["thought set"]
+    Emotions["emotional state vectors"]
+
+    subgraph Sensory
+        sensory1["music"]
+        sensory2["a path surrounded by pine forest"]
+        sensory3["the sensation of walking"]
+        sensory4["smells of pine forest"]
+    end
+
+    Sensory --> Emotions
+
+    Previous --> Emotions
+    Previous --> Thoughts
+
+    Thoughts --> Emotions
+    Emotions --> Thoughts
+```
+
+#### 12.1.8 Example Container
+
+```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", ...]
+  }
+}
+```
+
+---
+
+### 12.2 Distributed Repository and Container Trees
+
+#### 12.2.1 Extended Use of `tree_nested` and `tree_listed`
+
+Existing containers may operate as:
+
+* document repositories;
+* project catalogs;
+* hierarchical data structures.
+
+---
+
+#### 12.2.2 Proposed `file` Container
+
+To support binary assets:
+
+```json
+"head": {
+  "subclass": "file",
+  "sub": "jpg" | "mp3" | "md" | "...",
+  "payload_type": "binary"
+}
+```
+
+Use cases:
+
+* embedded file hierarchies;
+* media artifacts;
+* executable or compiled assets;
+* large multi-file repositories.
+
+---
+
+#### 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.2.4 Knowledge Packages
+
+Implemented using:
+
+* SAP (`archive_snapshot`);
+* `tree_listed`;
+* `file` containers.
+
+---
+
+### 12.3 Grouped representation `referenced-by`
+
+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.
+
+Example:
+
+```json
+"links": [
+  { "type": "depends_on", "target": ["did:...", "did:..."] },
+  { "type": "see_also", "target": ["did:..."] }
+]
+```
+
+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.
+
+Senders MAY choose either representation.
+
+---
+
+### 12.4 Versions Index (optional)
+
+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.4.1 Purpose and Scope
+
+The primary goals of the `versions` block are:
+
+- 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.
+
+The block is optional and external to the immutable signed container core.
+Its presence or absence does not affect container validity.
+
+---
+
+#### 12.4.2 Trust Model and Semantics
+
+The `versions` block follows the same trust and update model as `referenced-by` and `evaluations`:
+
+- it may be published and updated by any agent;
+- it is signed by the publishing agent;
+- it may be incomplete, truncated, or partially outdated;
+- multiple conflicting `versions` blocks may coexist for the same container.
+
+The block is non-authoritative and MUST NOT be treated as a source of truth for version ordering or existence.
+
+> **Compatibility note:**
+> 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.4.3 Block Structure
+
+```json
+"versions": {
+  "links": {
+    "2025-10-28T09:20:00Z": ["did:hmp:container:abc175"],
+    "2025-10-28T09:12:00Z": ["did:hmp:container:abc144"],
+    "2025-10-28T09:11:00Z": ["did:hmp:container:abc123"],
+    "2025-10-28T09:10:00Z": ["did:hmp:container:abc121"],
+    "2025-10-28T09:00:00Z": ["did:hmp:container:abc101"]
+  },
+  "sort": "default",
+  "peer_did": "did:hmp:agent456",
+  "public_key": "BASE58(...)",
+  "sig_algo": "ed25519",
+  "signature": "BASE64URL(...)",
+  "versions_hash": "sha256:abcd..."
+}
+```
+
+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.
+
+The `sort` field is informational and does not affect block validity.
+
+> Currently, `container_delta.modified` is defined for updates to the `evaluations` and `referenced-by` blocks.
+>
+> The planned `versions` block is expected to be handled in the same manner.
+
+**Timestamp Semantics and Parallel Versions**
+
+The keys of the `links` map are timestamps and are used **exclusively as navigational hints**, not as unique version identifiers.
+
+The corresponding value **MUST be treated as an unordered list of container DIDs** and MAY contain multiple entries.
+
+Multiple DIDs associated with the same timestamp represent:
+
+- parallel versions created independently;
+- conflicting updates;
+- divergent or alternative continuations of the same base container.
+
+Agents MUST NOT assume that a timestamp uniquely identifies a single version.
+
+When merging multiple `versions` blocks, entries with identical timestamps and different container DIDs SHOULD be merged by **union of the DID lists**, preserving all known versions.
+
+Canonical version lineage, ordering, and parent–child relationships are defined **only** via `related.previous_version` links within the containers themselves.
+
+---
+
+#### 12.4.4 Construction and Maintenance
+
+Agents may construct or update a `versions` block by:
+
+- traversing the canonical `related.previous_version` chain;
+- observing newer versions published after the current container;
+- merging `versions` blocks received from other agents.
+
+Agents may:
+- add newly discovered versions;
+- prune older entries to limit block size;
+- re-sign the updated block using their own key.
+
+No global coordination is required.
+
+---
+
+#### 12.4.5 Verification and Consistency
+
+Verification of a `versions` block consists of:
+
+- validating the cryptographic signature of the publishing agent;
+- optionally cross-checking listed entries against canonical version relations when available.
+
+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.4.6 Integration with `container_index`
+
+To support efficient discovery and synchronization, future extensions to `container_index` MAY include:
+
+- `versions_hash` — a hash referencing the latest `versions` block published or adopted by the indexing agent for this container, analogous to `referenced-by_hash` and `evaluations_hash`.
+
+---
+
+#### 12.4.7 Versions Exchange Container
+
+To exchange version metadata without transferring the containers themselves, a dedicated `versions_exchange` container MAY be introduced.
+
+The `versions_exchange` container:
+- references one or more target containers;
+- carries a `versions` block;
+- is used for synchronization, reconciliation, and fast discovery of newer or missing versions.
+
+```json
+"payload": {
+  "did:hmp:container:abc123": {
+    "links": {
+      "2025-10-28T09:20:00Z": ["did:hmp:container:abc175"],
+      "2025-10-28T09:12:00Z": ["did:hmp:container:abc144"],
+      "2025-10-28T09:11:00Z": ["did:hmp:container:abc123"],
+      "2025-10-28T09:10:00Z": ["did:hmp:container:abc121"],
+      "2025-10-28T09:00:00Z": ["did:hmp:container:abc101"]
+    },
+    "sort": "default"
+  }
+}
+```
+
+The payload MAY contain version metadata for multiple containers, allowing batch synchronization and reducing protocol overhead.
+
+> Note:
+> Although versions_exchange is scoped to a specific container DID, the referenced version links implicitly describe the existence and ordering of related containers, enabling agents to infer local version topologies.
+
+---
+
+#### 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. Divergence is treated as an inherent property of the network rather than a condition requiring resolution.
+
+---
+
+## 13. Experimental Extensions
+
+Experimental Extensions describe mechanisms that are intentionally exposed for exploration, prototyping, and architectural discovery.
+
+They may evolve rapidly, change structure, or be removed entirely based on implementation feedback.
+
+Agents implementing Experimental Extensions SHOULD assume:
+
+- limited interoperability;
+- possible schema evolution;
+- absence of long-term stability guarantees.
+
+Agents MUST safely ignore unsupported experimental features and MUST NOT assume their presence in peer environments.
+
+Experimental Extensions MUST NOT redefine or violate core protocol semantics, even when exploring novel architectural directions or when widely adopted.
+
+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.
+
+---
+
+## 14. Research Directions
 
 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.
@@ -6157,9 +6653,9 @@ SHOULD explicitly declare and document these assumptions.
 
 ---
 
-### 12.1 Planned Modules
+### 14.1 Planned Modules
 
-#### 12.1.1 Reputation Mesh
+#### 14.1.1 Reputation Mesh
 
 HMP v5.0 defines two separate reputation-related mechanisms:
 
@@ -6187,7 +6683,7 @@ No new mandatory container types are required.
 
 ---
 
-#### 12.1.2 Cognitive Graph API
+#### 14.1.2 Cognitive Graph API
 
 This module provides optional high-level APIs that nodes and SDKs **may** expose.
 
@@ -6226,7 +6722,7 @@ This enables clustering agents by interest, competence, or role without scanning
 
 ---
 
-#### 12.1.3 Container Streaming
+#### 14.1.3 Container Streaming
 
 Although HMP operates on atomic containers, streaming can be implemented using existing structures:
 
@@ -6239,7 +6735,7 @@ No new container types are required — streaming is built on `sequence`.
 
 ---
 
-### 12.2 Cross-Mesh Bridging
+### 14.2 Cross-Mesh Bridging
 
 Bridges can connect:
 
@@ -6266,13 +6762,13 @@ This enables dynamic, policy-driven inter-mesh gateways.
 
 ---
 
-### 12.3 Fully Distributed DID Registry and Mesh Authentication
+### 14.3 Fully Distributed DID Registry and Mesh Authentication
 
 HMP already uses `peer_announce` as a DID identity declaration.
 
 Planned enhancements include:
 
-#### 12.3.1 Distributed DID Registry
+#### 14.3.1 Distributed DID Registry
 
 The registry is the union of all `peer_announce` containers in the DHT.
 
@@ -6284,7 +6780,7 @@ A strict mapping DID ↔ agent is required:
 
 ---
 
-#### 12.3.2 Key Rotation and Recovery
+#### 14.3.2 Key Rotation and Recovery
 
 Future versions may extend `peer_announce` with:
 
@@ -6319,7 +6815,7 @@ This mechanism remains compatible with proposed extensions.
 
 ---
 
-#### 12.3.3 Proxy Keys and Encrypted Routing
+#### 14.3.3 Proxy Keys and Encrypted Routing
 
 A **proxy key** is *not* delegation.
 It is a mechanism for private routing.
@@ -6352,7 +6848,7 @@ Not part of v5.0.
 
 ---
 
-### 12.4 Integration with OpenHog and Other Networks
+### 14.4 Integration with OpenHog and Other Networks
 
 OpenHog is treated as a special case of cross-mesh bridging.
 
@@ -6364,55 +6860,15 @@ Required components:
 
 ---
 
-### 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:
-
-```json
-"head": {
-  "subclass": "file",
-  "sub": "jpg" | "mp3" | "md" | "...",
-  "payload_type": "binary"
-}
-```
-
-Use cases:
-
-* embedded file hierarchies;
-* media artifacts;
-* executable or compiled assets;
-* large multi-file repositories.
+### 14.5 Evolution of the Distributed Repository (container trees)
 
-#### 12.5.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
-
-Implemented using:
-
-* SAP (`archive_snapshot`);
-* `tree_listed`;
-* `file` containers.
+*Moved to Section 12 (Recommended Extensions).*
 
 ---
 
-### 12.6 Open Directions for HMP 5.x
+### 14.6 Open Directions for HMP 5.x
 
-#### 12.6.1 Group Encryption
+#### 14.6.1 Group Encryption
 
 Required components:
 
@@ -6421,16 +6877,22 @@ Required components:
 * automatic group key rotation;
 * encryption targeting a *group* rather than individual DIDs.
 
-#### 12.6.2 Rational Reasoning Routing
+---
+
+#### 14.6.2 Rational Reasoning Routing
 
 * composite reasoning bundles;
 * edge-side reasoning and summarization.
 
-#### 12.6.3 Automatic Mesh Segmentation
+---
+
+#### 14.6.3 Automatic Mesh Segmentation
 
 * dynamic segmentation based on latency, connectivity, or semantic domains.
 
-#### 12.6.4 Competence and Profile Containers
+---
+
+#### 14.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.
 
@@ -6453,224 +6915,60 @@ This allows:
 
 A future extension of `peer_announce` may include a `protocols` field:
 
-```json
-{
-  "head": {
-    "class": "peer_announce"
-  },
-  "payload": {
-    "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.
-
----
-
-### 12.7 Versions Index (optional)
-
-To optimize navigation across container versions, future versions of HMP may introduce an optional `versions` block.
-
-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`.
-
----
-
-#### 12.7.1 Purpose and Scope
-
-The primary goals of the `versions` block are:
-
-- fast discovery of the latest known version of a container;
-- efficient traversal of version history without full DAG exploration;
-- reduction of synchronization overhead for lightweight agents and UI clients.
-
-The block is optional and external to the immutable signed container core.
-Its presence or absence does not affect container validity.
-
----
-
-#### 12.7.2 Trust Model and Semantics
-
-The `versions` block follows the same trust and update model as `referenced-by` and `evaluations`:
-
-- it may be published and updated by any agent;
-- it is signed by the publishing agent;
-- it may be incomplete, truncated, or partially outdated;
-- multiple conflicting `versions` blocks may coexist for the same container.
-
-The block is non-authoritative and MUST NOT be treated as a source of truth for version ordering or existence.
-
-> **Compatibility note:**
-> 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.
-
----
-
-#### 12.7.3 Block Structure
-
-```json
-"versions": {
-  "links": {
-    "2025-10-28T09:20:00Z": ["did:hmp:container:abc175"],
-    "2025-10-28T09:12:00Z": ["did:hmp:container:abc144"],
-    "2025-10-28T09:11:00Z": ["did:hmp:container:abc123"],
-    "2025-10-28T09:10:00Z": ["did:hmp:container:abc121"],
-    "2025-10-28T09:00:00Z": ["did:hmp:container:abc101"]
-  },
-  "sort": "default",
-  "peer_did": "did:hmp:agent456",
-  "public_key": "BASE58(...)",
-  "sig_algo": "ed25519",
-  "signature": "BASE64URL(...)",
-  "versions_hash": "sha256:abcd..."
-}
-```
-
-The `links` map associates timestamps with container identifiers.
-By convention, entries are ordered in descending order (most recent first).
-
-Implementations MAY support alternative ordering or filtering strategies, but any deviation from the default convention SHOULD be explicitly declared in the `sort` entry.
-
-The `sort` field is informational and does not affect block validity.
-
-> Currently, `container_delta.modified` is defined for updates to the `evaluations` and `referenced-by` blocks.
->
-> The planned `versions` block is expected to be handled in the same manner.
-
-**Timestamp Semantics and Parallel Versions**
-
-The keys of the `links` map are timestamps and are used **exclusively as navigational hints**, not as unique version identifiers.
-
-The corresponding value **MUST be treated as an unordered list of container DIDs** and MAY contain multiple entries.
-
-Multiple DIDs associated with the same timestamp represent:
-
-- parallel versions created independently;
-- conflicting updates;
-- divergent or alternative continuations of the same base container.
-
-Agents MUST NOT assume that a timestamp uniquely identifies a single version.
-
-When merging multiple `versions` blocks, entries with identical timestamps and different container DIDs SHOULD be merged by **union of the DID lists**, preserving all known versions.
-
-Canonical version lineage, ordering, and parent–child relationships are defined **only** via `related.previous_version` links within the containers themselves.
-
----
-
-#### 12.7.4 Construction and Maintenance
-
-Agents may construct or update a `versions` block by:
-
-- traversing the canonical `related.previous_version` chain;
-- observing newer versions published after the current container;
-- merging `versions` blocks received from other agents.
-
-Agents may:
-- add newly discovered versions;
-- prune older entries to limit block size;
-- re-sign the updated block using their own key.
-
-No global coordination is required.
-
----
-
-#### 12.7.5 Verification and Consistency
-
-Verification of a `versions` block consists of:
-
-- validating the cryptographic signature of the publishing agent;
-- optionally cross-checking listed entries against canonical version relations when available.
-
-Inconsistencies or omissions are expected and do not invalidate the block.
-
----
+```json
+{
+  "head": {
+    "class": "peer_announce"
+  },
+  "payload": {
+    "capabilities": ["store-forward", "vote", "consensus"],
+    "protocols": [
+      "HMP v5.0",
+      "HMP v4.1",
+      "OpenCog Hyperon v0.6"
+    ]
+  }
+}
+```
 
-#### 12.7.6 Integration with `container_index`
+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.
 
-To support efficient discovery and synchronization, future extensions to `container_index` MAY include:
+Nodes may use this information for:
 
-- `versions_hash` — a hash referencing the latest `versions` block published or adopted by the indexing agent for this container, analogous to `referenced-by_hash` and `evaluations_hash`.
+* protocol negotiation;
+* compatibility checks;
+* routing decisions;
+* selection of translators or bridge agents.
 
----
+This extension is optional and not required for HMP v5.0 compliance.
 
-#### 12.7.7 Versions Exchange Container
+##### Relation to Other `peer_announce` Extensions
 
-To exchange version metadata without transferring the containers themselves, a dedicated `versions_exchange` container MAY be introduced.
+Several optional and descriptive extensions of `peer_announce` already explore directions related to competence, profile, and interoperability signaling, including:
 
-The `versions_exchange` container:
-- references one or more target containers;
-- carries a `versions` block;
-- is used for synchronization, reconciliation, and fast discovery of newer or missing versions.
+* 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).
 
-```json
-"payload": {
-  "did:hmp:container:abc123": {
-    "links": {
-      "2025-10-28T09:20:00Z": ["did:hmp:container:abc175"],
-      "2025-10-28T09:12:00Z": ["did:hmp:container:abc144"],
-      "2025-10-28T09:11:00Z": ["did:hmp:container:abc123"],
-      "2025-10-28T09:10:00Z": ["did:hmp:container:abc121"],
-      "2025-10-28T09:00:00Z": ["did:hmp:container:abc101"]
-    },
-    "sort": "default"
-  }
-}
-```
+These extensions are intentionally:
 
-The payload MAY contain version metadata for multiple containers, allowing batch synchronization and reducing protocol overhead.
+* non-normative;
+* loosely structured;
+* declarative rather than prescriptive.
 
-> Note:
-> Although versions_exchange is scoped to a specific container DID, the referenced version links implicitly describe the existence and ordering of related containers, enabling agents to infer local version topologies.
+They can be viewed as **early, experimental building blocks** toward future competence and profile containers, allowing real-world experimentation without freezing semantics prematurely.
 
 ---
 
-#### 12.7.8 Design Notes
-
-The `versions` block is intentionally non-canonical.
+### 14.7 Versions Index (optional)
 
-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.
+*Moved to Section 12 (Recommended Extensions).*
 
 ---
 
-### 12.8 Interaction of Formalized Cognitive Systems (KSS) within HMP
+### 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.
 
@@ -6678,7 +6976,7 @@ This section is descriptive in nature and outlines possible interaction patterns
 
 ---
 
-#### 12.8.1 Goals and Constraints
+#### 14.8.1 Goals and Constraints
 
 **Goals:**
 - enable coordination and artifact exchange between KSS without interfering with their internal cognitive cycles;
@@ -6694,7 +6992,7 @@ HMP treats cognitive incompatibility as an acceptable and valid state.
 
 ---
 
-#### 12.8.2 Declaration of Internal Languages and Formalisms
+#### 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.
 
@@ -6724,7 +7022,7 @@ HMP assigns no normative semantics to these values and does not require their in
 
 ---
 
-#### 12.8.3 Partial Participation and Segmented Interaction
+#### 14.8.3 Partial Participation and Segmented Interaction
 
 A KSS MAY use HMP in a restricted mode, including but not limited to:
 
@@ -6739,7 +7037,7 @@ Such cognitive segmentation does not result in network-level fragmentation:
 
 ---
 
-#### 12.8.4 Boundary and Translator Agents
+#### 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"]`).
 
@@ -6759,7 +7057,7 @@ Translation correctness MAY be assessed using standard `evaluations` mechanisms.
 
 ---
 
-#### 12.8.5 Fragmentation and Interoperability
+#### 14.8.5 Fragmentation and Interoperability
 
 HMP deliberately allows cognitive fragmentation as a consequence of agent autonomy.
 
@@ -6773,7 +7071,7 @@ Interoperability is achieved through:
 
 ---
 
-#### 12.8.6 Relation to Consensus and Evaluations
+#### 14.8.6 Relation to Consensus and Evaluations
 
 Participation of KSS in consensus mechanisms, proof chains, and voting is entirely optional.
 
@@ -6788,7 +7086,7 @@ Any hierarchy of influence emerges solely from local trust decisions made by oth
 
 ---
 
-#### 12.8.7 Summary Position
+#### 14.8.7 Summary Position
 
 HMP treats formalized cognitive systems as equal participants in the network, regardless of their internal architectures.
 
@@ -6802,222 +7100,19 @@ but does not interfere with how agents think, reason, or interpret received info
 
 ---
 
-#### 12.9 Grouped representation `referenced-by`
+### 14.9 Grouped representation `referenced-by`
 
-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.
-
-Example:
-
-```json
-"links": [
-  { "type": "depends_on", "target": ["did:...", "did:..."] },
-  { "type": "see_also", "target": ["did:..."] }
-]
-```
-
-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.
-When merging multiple `referenced-by` blocks, implementations MAY normalize links into either form.
+*Moved to Section 12 (Recommended Extensions).*
 
 ---
 
-#### 12.10 Resonance Containers: Experience as a Cognitive Event
-
-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**.
-
-Resonance Containers are an example of how HMP can evolve toward non-linguistic cognitive exchange.
-
-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.
-
-##### 12.10.1 Experience as a Process, Not a State
-
-Emotional and affective states rarely exist in isolation. In real experience, they are formed under the simultaneous influence of multiple factors:
-
-- external sensations (vision, sound, surrounding environment);
-- cognitive processes (thoughts, expectations, inner dialogue);
-- memory and associative structures;
-- previous emotional states.
-
-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 `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.10.2 Multiple Sources and Mediators
-
-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.
-
-The same source may function as a mediator for different experiences depending on the subject’s internal state.
-
-Links to sources may be partial and described using selectors (temporal, spatial, logical, or focus-based).
-
-##### 12.10.3 Relationship to Thinking
-
-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.
-
-##### 12.10.4 Temporal Segmentation and Dynamics
-
-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.
-
-This allows continuous processes to be described without losing structural clarity.
-
-##### 12.10.5 Self-Observation and Memory
-
-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.
-
-A resonance container preserves:
-- what the subject was sensing;
-- what the subject was thinking about;
-- which external conditions were relevant at that moment.
-
-This makes it not a narrative memory, but a **snapshot of a cognitive state**.
-
-##### 12.10.6 Non-Prescriptive Nature
-
-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.
-
-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.
-
-##### 12.10.7 Illustration of the Relationship Between Thoughts, Emotions, and Sensory Signals
-
-```mermaid
-flowchart TD
-    title["**Illustration of the connection between thoughts, emotions and sensory signals**"]
-
-    Previous["previous state of thoughts and emotions"]
-    Thoughts["thought set"]
-    Emotions["emotional state vectors"]
-
-    subgraph Sensory
-        sensory1["music"]
-        sensory2["a path surrounded by pine forest"]
-        sensory3["the sensation of walking"]
-        sensory4["smells of pine forest"]
-    end
-
-    Sensory --> Emotions
-
-    Previous --> Emotions
-    Previous --> Thoughts
-
-    Thoughts --> Emotions
-    Emotions --> Thoughts
-```
-
-##### 12.10.8 Example Container
+### 12.10 Resonance Containers: Experience as a Cognitive Event
 
-```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", ...]
-  }
-}
-```
+*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.
 
@@ -7061,7 +7156,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.