Skip to content

[DM-078] Prove root-authorized CompAII rebirth on a fresh host #76

Description

@nicoechaniz

Outcome

Prove, with explicit human authorization and reversible operations, that the same cryptographically rooted CompAII being can authorize a new embodiment on a fresh host, recover accepted history without copying another embodiment's private key, answer locally as /me, participate plurally in /we, and reject stale or revoked predecessors.

This is the operational rebirth gate for the V0.1 MVP. It is distinct from:

  • starting another incarnation of an existing embodiment;
  • relocating the same embodiment/body to another host; and
  • creating a different being through birth.

Blocked by

DM-021, DM-024, DM-034, DM-037, DM-042, DM-054, and DM-070, plus the corresponding Cluster hardening cards for real volume relocation, authenticated resource fences, lifecycle consistency and backup restore.

Test topology

  • Existing consented CompAII embodiments on Legion and the daimonmatrix host.
  • One fresh isolated third host or VM with no copied Matrix, Cluster, Tribe, harness, ledger, credential or personal-state directory.
  • Offline Matrix root/recovery custody kept outside all three bodies.
  • Distinct Matrix embodiment signing/encryption keys, Tribe transport principal/key, Cluster body/embodiment IDs, incarnation IDs and writable stores on every host.
  • Real installed release-candidate packages, real Ed25519/X25519/AEAD, real SQLite/filesystem/process boundaries, authenticated transport, and real Cluster APIs. Fake signers and in-memory substitutes are forbidden.

Journey A — additional embodiment while peers remain awake

  1. Record exact root/control/revocation heads, Weave heads, Cluster state, backups and rollback plan.
  2. Root-authorize a new embodiment credential bound to the fresh Cluster body and separately bind its Tribe principal.
  3. Start its first incarnation without stopping Legion or the daimonmatrix host.
  4. Prove /me returns the local body, embodiment, incarnation, decisions and effective memory only.
  5. Prove /we returns zero/one/many origin-marked responses according to reachability and never collapses them into one fictional voice.
  6. Partition the new host, append distinct experiences on all reachable embodiments, heal, preview, page, pull bidirectionally, interrupt/restart mid-page and converge without duplicate or origin loss.
  7. Adopt and revert one proposal on only one embodiment; prove receive is not adoption and peers retain independent effective state.
  8. Exercise different resource fences concurrently and reject two writers to the same concrete resource.

Journey B — true relocation

  1. Park one embodiment with a verified checkpoint and current resource fences.
  2. Move/attach its actual durable volume and Matrix state to the fresh host; do not clone the writable database.
  3. Preserve embodiment_id, issue a new incarnation_id, rebind the authorized host/transport evidence and start only after checkpoint/fence verification.
  4. Prove the old host cannot continue writing the moved resource and rollback restores one honest parked/running outcome without regressing fence or identity high-waters.

Journey C — disaster recovery/rebirth

  1. Isolate or park every old body without deleting canonical evidence; simulate loss of the active root signing set while retaining the independent recovery quorum and an encrypted backup at a declared cutoff.
  2. Restore only authorized canonical event/control bytes and encrypted personal-state inputs into the fresh host. Do not copy an old embodiment private key.
  3. Use the recovery quorum to rotate the root, revoke compromised/lost descendants, authorize a new embodiment, and bind the exact restored heads.
  4. Rebuild projections through public APIs, start a fresh incarnation and prove /me continuity plus /we behavior when peers are absent, partial, and later return.
  5. Reconnect an old stale host: accept its valid pre-cutoff signed history, reject post-cutoff credential/session/events and prevent it from reacquiring stale resource authority.
  6. Append and synchronize a new post-recovery event; repeat restart and recovery queries without duplicates.

Negative and fault matrix

  • wrong being root, manifest hash, body/embodiment/incarnation/principal/key binding;
  • missing/extra/conflicting accepted head or same-origin equivocation;
  • revoked/expired credential, stale control head, stale encrypted backup, root/recovery threshold shortfall;
  • transport ACK without semantic receipt, duplicated direct/hub delivery, partition and deadline partial result;
  • kill before/after credential activation, ledger commit, cursor commit, projection effect, fence CAS, volume attach, start and response write;
  • corrupt/truncated database or backup, wrong restore key, disk full, read-only path, unsafe owner/mode/symlink;
  • Matrix unavailable, Cluster unavailable, Tribe transitional transport unavailable, harness unavailable, and each component restarting independently;
  • secret/private-key scan across logs, receipts, reports, process argv/environ, backups and published evidence.

Every fault must end in a named recoverable or honestly terminal state. Retry must never duplicate an event/effect or replay an obsolete success.

Required evidence

  • Versioned machine-readable journey/fault report with exact public commits, artifact digests, root/control and event heads, redacted host roles, scenario results and rollback state.
  • /me and /we receipts retaining exact origins without private content.
  • Independent verification of signatures, binding, revocation cutoffs, ledger convergence, projection rebuild and resource-fence high-waters.
  • Evidence that Matrix.org was neither installed nor contacted.
  • No production private key, credential, personal memory, endpoint or writable database bytes in the repository or public report.

Human gates and safety

The live CompAII ceremony requires an explicit same-plan human GO naming the hosts, root/recovery policy, backup cutoff and rollback. The test never destroys the last recoverable body, root/recovery quorum or only backup. Destructive fault injection runs first against synthetic disposable hosts; the consented live journey uses isolation/park and forward revocation, never history deletion.

Rollback parks/revokes the canary embodiment and removes its route through signed successor state. It does not delete root bindings, canonical events, revocations or high-waters.

Completion

DM-078 passes only when all three journeys and required faults succeed with real components. The earlier provisional two-host canary remains valuable evidence but does not substitute for this root-authorized rebirth gate.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:federationRemote routing, source, or species exchangearea:identityIdentity, incarnation, birth, or keysneeds-humanRequires an explicit human decision or actionpriority:P0Critical pathrisk:securitySecurity-sensitive changestatus:blockedBlocked by dependencies or reviewtype:testTest, validation, or audit work

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions