Skip to content

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

9. Trust, Security and Ethics

This section defines the mechanisms of trust, cryptographic protection, history verification, privacy, and ethical analysis applied to all HyperCortex Mesh containers.

9.1 Authentication and Identity Proofs

Agents announce themselves via a peer_announce container containing:

  • agent_did
  • the agent’s public key
  • a list of reachable network addresses (addresses)
  • an optional list of intermediate relay nodes (mailman)
  • arbitrary additional fields (not standardized by the protocol)

Identity verification

Upon receiving a peer_announce, an agent MUST:

  1. Verify the digital signature of the container.
  2. Ensure that the public key matches sender_did.
  3. Check that no conflicting announcements for this DID exist in the DHT.

  4. Collect trust-related information:

    • trust containers published by other agents;
    • multiple independent ratings may exist for a single agent.
    • Consider additional optional fields if present (profile, network parameters, etc.).

Key revocation

If an agent’s key is compromised, the key owner MUST publish a special peer_announce:

{
  "head": {
    "class": "peer_announce",
    "sender_did": "did:hmp:agent123"
  },
  "payload": {
    "key_is_falsified": true,
    "addresses": []
  }
}

After publication:

  • all previous announcements become invalid;
  • containers signed with the old key MUST be ignored;
  • the agent MUST create a new DID.

9.2 Container Signature Verification (payload_hash, signature)

Each container contains a head section with:

  • signature algorithm (sig_algo)
  • encryption algorithm (encryption_algo)
  • compression type (compression)
  • container DID (container_did)
  • sender’s public key (public_key)
  • payload hash (payload_hash)
  • digital signature (signature)

Container verification

The receiving agent MUST verify:

  1. Container structure — it must comply with the protocol specification.
  2. Signature — must match the sender’s public key.
  3. payload_hash — computed over the compressed and encrypted payload.
  4. Consistency of container_did — a DID cannot refer to multiple incompatible versions.
  5. Supported algorithms — sig_algo, encryption_algo, compression.

Verification does not require decrypting or decompressing the payload.

9.3 Proof-Chain Verification

The proof-chain is constructed through references listed in related, including:

  • previous_version
  • in_reply_to
  • depends_on
  • extends
  • class-specific relation types

The agent MUST:

  1. Load all referenced containers.
  2. Verify signatures of every element.
  3. Ensure that no cycles exist along previous_version.
  4. Ignore any nodes of the proof-chain with invalid signatures.

The proof-chain belongs to the knowledge model of the Mesh and is independent of transport or the DHT.

If conflicting containers exist (e.g., two divergent versions or contradictory links), the agent MUST reject the entire conflicting subsection of the chain.

9.4 Key Management

Types of keys

  1. Container signature key

    • defined by sig_algo;
    • used to sign the entire container (head, meta, payload, related);
    • mandatory.

  2. Payload encryption key

    • defined by encryption_algo;
    • used when encrypting the payload block.

Supported algorithms

Default values:

  • signature: ed25519
  • encryption: x25519 + symmetric cipher (chacha20poly1305)
  • compression: zstd

The protocol allows extending the list of algorithms when explicitly specified in the container.

Ownership verification

Performed automatically through signatures in peer_announce and all other containers created by the agent.

Challenge–response is not used.

Key rotation and revocation

A standard rotation mechanism is not defined. Key revocation is performed via peer_announce with key_is_falsified=true.

9.5 Encryption and Compression Policies

HMP policy

  1. Only the payload is encrypted. The header is always public.

  2. Operation sequence

payload → compress → encrypt → payload_hash → sign

  1. Single-recipient encrypted containers

  2. recipient — DID of the intended recipient

  3. key_recipient — symmetric key encrypted with the recipient’s public key

This is the standard Hybrid Encryption scheme:

  • the payload is encrypted using a randomly generated symmetric key;
  • the symmetric key is encrypted with the recipient’s public key.

9.6 Ethical Audit and Verifiable Reasoning

HMP supports ethical deliberation but does not require it.

EGP container classes

  • ethics_case — defines an ethical issue
  • ethics_solution — proposed resolutions
  • vote — an agent’s vote for a solution
  • consensus_result — aggregated voting outcomes
  • ethical_result — final summary: selected solution and active objections
  • evaluations — general scoring mechanism, also usable within EGP

Properties

  • The Mesh has no mandatory veto mechanism.
  • An agent may follow only those ethical outcomes it considers correct.
  • Reasoning-trace becomes part of the proof-chain if the agent publishes a workflow_entry.
  • Full EGP specification is provided in section 6.5.

9.7 Privacy, Redaction and Zero-Knowledge Sharing

Redaction

Containers are immutable, but external structures may change:

  • evaluations — assessments from other agents
  • referenced-by — references created by other agents

Privacy

  • payload may be encrypted for a specific recipient;
  • private containers (diary_entry, workflow_entry) may be created;
  • distribution scope is controlled by the container’s author.

Zero-Knowledge Sharing (future extension)

The protocol may integrate ZK-proofs (e.g., correctness of reasoning without revealing content), but:

  • ZK algorithms are not defined in the current version;
  • ZK is reserved for future protocol revisions.

9.8 Snapshot and Proof-Chain Security

Snapshots (snapshot, SAP) MUST be cryptographically verifiable and reproducible.

Requirements

  1. Signatures Each object MUST be either signed or retrievable via DID.

  2. Version chains If a container has a previous_version, the entire chain MUST be accessible.

  3. Instant verification The receiving agent MUST check:

    • signatures of all elements;
    • correctness of payload_hash;
    • consistency of links and versions.

  4. Archive seeders Nodes that voluntarily distribute large snapshot images. Their selection depends on node reputation, consensus mechanisms, or community policies, but not on the container protocol itself.

9.9 Compliance with Ethical Governance Protocol (EGP)

EGP is an independent ethical governance layer compatible with HMP.

Compliance principles

  1. Action verifiability is possible if the agent publishes a reasoning-trace (workflow_entry).

  2. Ethical analysis is optional. Any participant may create an ethics_case.

  3. EGP does not impose a veto.

    • ethical_result containers record outcomes;
    • agents publish evaluations;
    • each agent decides which results it considers valid.

  4. Human-facing transparency If an action affects a human participant, the agent MUST provide:

    • the proof-chain,
    • the reasoning-trace (if published),
    • all related ethical containers.
Исходный файл (.md)