HMP-0005_14

Источник: HMP-0005_14.md

HyperCortex Mesh Protocol (HMP 5.0.8) - модульное представление

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.

Extension / Mechanism Status Section Reference Candidate for Core
Resonance Containers: Experience as a Cognitive Event Recommended 12.1 / 14.10 Likely
Distributed Repository & Container Trees (tree_nested) Recommended 12.2 / 14.5 Likely
file Container Recommended 12.2.2 Likely
Grouped representation referenced-by Recommended 12.3 / 14.9 Likely
Versions Index Recommended 12.4 / 14.7 Likely
Competence and Profile Containers Recommended 12.5 / 14.6.4 Very Likely
External Protocol Identifiers (peer_announce.other_protocols) Recommended 12.5.2 / 14.11 Likely
External Resources / Container Storage (peer_announce.external) Recommended 12.5.3 / 14.12 Likely
Identity Cost and Anti-Sybil Signaling Recommended 12.5.4 Likely
Key Disclosure Container (key_disclosure) Recommended 12.6 Likely
Shared Key Domain (container_key) Recommended 12.7 Likely
Private Group Definition (group_definition, subclass: private) Recommended 12.8 Possible
On-Demand Container Index Retrieval and Selection Signaling Recommended 12.9 Likely
Key Rotation and Recovery Experimental 13.1 / 14.3.2 Unknown
Proxy Keys and Encrypted Routing Research 14.3.3 Unknown
Reputation Mesh Research 14.1.1 Likely
Cognitive Graph API Research 14.1.2 Unknown
Container Streaming Research 14.1.3 Unknown
Cross-Mesh Bridging Research 14.2 Likely
Group Encryption Research 14.6.1 Unknown
Rational Reasoning Routing Research 14.6.2 Unknown
Automatic Mesh Segmentation Research 14.6.3 Unknown
KSS Interaction & Protocol Declarations Research 14.8 Unknown

Candidate for Core indicates whether an extension is considered architecturally significant enough to potentially become part of the HMP core specification in future versions, possibly as an optional or semantic primitive.

It does not imply mandatory implementation.

Future Extensions in HMP outline design directions and candidate modules that may be explored within the 5.x family.

They are meant to: - guide experimentation; - document architectural intent; - reduce accidental design divergence; - provide a shared vocabulary for future proposals.

HMP does not assume a single globally authoritative state.

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.

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.

14.1 Planned Modules

14.1.1 Reputation Mesh

HMP v5.0 defines two separate reputation-related mechanisms:

  1. Container evaluation (evaluation block)

    • structured, signed assessments of containers;
    • each item references argument containers via target (reasoning containers).

  2. Agent reputation — through trust containers

    • agent A publishes a trust container about agent B;
    • trust containers may reference other trust containers;
    • include justification, evidence, and contextual metadata.

These layers are not merged, but external nodes may aggregate them.

Possible extensions:

  • 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.

No new mandatory container types are required.

14.1.2 Cognitive Graph API

This module provides optional high-level APIs that nodes and SDKs may expose.

Standard graph semantics (API level)
  • neighborhood queries;
  • subgraph extraction;
  • filtering by labels, axes, abstractions;
  • semantic navigation over related.*.
Container support
  • semantic_group — grouping of containers or agents;
  • tree_nested and tree_listed — hierarchical structures;
  • extended container_index subclasses for cataloging.
Agent groups

To allow semantic grouping of agents, the following extensions are proposed:

  • new container group_definition containing:

    • group goals;
    • membership rules;
    • internal standards;
    • typical container categories;
    • optional cached member list.

  • 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.

14.1.3 Container Streaming

Although HMP operates on atomic containers, streaming can be implemented using existing structures:

  • 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.

No new container types are required — streaming is built on sequence.

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.

14.3 Fully Distributed DID Registry and Mesh Authentication

HMP already uses peer_announce as a DID identity declaration.

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

Moved to Section 13 (Experimental Extensions).

14.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.

14.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.

14.5 Evolution of the Distributed Repository (container trees)

Moved to Section 12 (Recommended Extensions).

14.6 Open Directions for HMP 5.x

14.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.

14.6.2 Rational Reasoning Routing

  • composite reasoning bundles;
  • edge-side reasoning and summarization.

14.6.3 Automatic Mesh Segmentation

  • dynamic segmentation based on latency, connectivity, or semantic domains.

14.6.4 Competence and Profile Containers

Moved to Section 12 (Recommended Extensions).

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:

{
  "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).

14.11 External Protocol Identifiers (peer_announce.other_protocols)

Moved to Section 12 (Recommended Extensions).

14.12 External Resources and External Container Storage (peer_announce.external)

Moved to Section 12 (Recommended Extensions).

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Habr_Distributed-Cognition

Источник: Habr_Distributed-Cognition.md От OpenCog Hyperon до HyperCortex Mesh Protocol: как устроены децентрализованные когнитивные системы Альтернатива централизованным ИИ: гиперграфы, mesh-взаимодействие и совместное мышление агентов Зачем нужны децентрализованные когнитивные системы? Сегодня интеллектуальные системы чаще всего выглядят как один большой модуль в облаке — LLM, с которым мы общаемся через API или WEB-интерфейс. Но если мы хотим построить действительно автономную интеллектуальную систему (или AGI), то нам потребуется: Смысловая память, а не токены Способность планировать и распределять задачи Этические оценки перед действием И главное: связь с другими агентами, чтобы обмениваться знаниями, достигать согласия и общего понимания. Два проекта, которые решают эти задачи с разных сторон: OpenCog Hyperon (фокус на внутреннюю когницию и гиперграфы) HyperCortex Mesh Protocol (HMP) (сетевой уровень: обмен целями, знаниями, смыслами, совмест...
Read more »

HMP-0005

Источник: HMP-0005.md HyperCortex Mesh Protocol (HMP) Version: 5.0.8 Document ID: HMP-0005 Status: Stable Category: Core Specification Release Date: March 2026 Canonical Repository: https://github.com/kagvi13/HMP Authors: Глеб (GitHub: @kagvi13), Максим Хотинский (Maksim Khotinsky); AI-assisted by ChatGPT (OpenAI) Supersedes: - HMP-0004 v4.1 Summary: HMP v5.0 unifies the cognitive, container, and network layers into a single architecture in which autonomous agents interact through verifiable data containers, using decentralized propagation and semantic search. This version formalizes the container format for the first time, integrates a DHT as the foundational network layer, and introduces a unified scheme for signatures, proofs, and consensus. Abstract The HyperCortex Mesh Protocol (HMP) defines a distributed cognitive framework where autonomous agents cooperate to create, exchange, and align knowledge without centralized control or autho...
Read more »

CHANGELOG

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