Skip to content

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

13. Experimental Extensions

Experimental Extensions describe mechanisms that are intentionally exposed for exploration, prototyping, and architectural discovery.

Experimental features are not required for protocol compliance and MAY be ignored by implementations.

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.

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.

13.1 Key Rotation and Recovery

This section describes experimental extensions to peer_announce for key rotation and recovery.

"recovery_keys": [...],
"key_history": [...],
"key_rotation_policy": "3-of-5"

One possible key management model:

  • 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 model aims to reduce the risk of:

  • DID hijacking;
  • irreversible loss of access.

The semantics and security properties of these mechanisms remain subject to further experimentation.

Key invalidation is part of the core HMP protocol (see Section 4.1) and is defined using:

"key_is_falsified": true

This mechanism remains compatible with proposed extensions.

Исходный файл (.md)