Skip to content

[DM-055] Cut over operational Weave to native encrypted Matrix peer transport #34

Description

@nicoechaniz

Outcome

Replace the transitional tribe-weave/v1 carrier with the native, root-bound Daimon Matrix peer transport and perform a reversible operational cutover after explicit human approval. Configured same-being embodiments must exchange encrypted typed /me scope requests/responses and /we.sync requests/deltas, while logical messages continue through the already-native DM-051/052/053 sealed-delivery route. No Tribe wire, directory, audience, key, database, history or runtime becomes Matrix authority or release dependency.

“Matrix” means daimon-matrix; Matrix.org is absent.

Ontology and roadmap correction

The previous short card said Matrix payloads would travel “through Tribe direct audiences.” That contradicted DM-050–054 and the V0 roadmap, which independently replaced Tribe identity, encryption, messages, routes, cursors and scopes and require removal of the standalone runtime dependency. DM-055 therefore activates the native successor wire dm.peer-envelope/v1; it does not wrap Matrix inside tribe-weave/v1.

Tribe Bridge may continue carrying ordinary human messages during the bounded canary. Those messages remain byte/protocol/runtime unchanged. New Matrix peer traffic no longer enters Tribe after cutover. DM-077 owns the later notice/archive action after V0.1.0 and explicit repository-owner approval.

Dependencies

  • DM-050 no-copy provenance and absorption boundary.
  • DM-051 root-bound recipient encryption.
  • DM-052 logical messages, receipts, queues and cursors.
  • DM-053 native local/direct/hub route semantics.
  • DM-054 signed scopes and per-origin sync plans.
  • Implementation PR merged and exact release evidence green.
  • Human authorizes the named hosts, endpoints, maintenance window and rollback trigger for the live canary.

The implementation may be completed and reviewed while this card remains status:blocked; live network/service mutation must not occur before the final human gate.

Native encrypted peer contract

  • dm.peer-envelope/v1 carries one canonical typed document to one exact active embodiment.
  • Closed content types are scope request, scope response, sync request and sync delta. New types require a successor schema/review.
  • Fresh CEK/nonces, ChaCha20-Poly1305 payload encryption, RFC 9180 HPKE Base X25519/HKDF-SHA256/ChaCha20-Poly1305 CEK wrapping and Ed25519 full-envelope signatures use separate domain strings.
  • Every envelope binds being, manifest hash, sender body/embodiment/incarnation/current credential/transport principal/signing key, recipient embodiment/current credential/encryption key, issue/expiry, correlation, reply parent and content type.
  • Receiver validates current root/control state, manifest, active origin, principal binding, signature, exact local recipient, canonical bytes and expiry before private-key use. Manifest mismatch, stale incarnation, wrong recipient and revoked sender/recipient fail closed.
  • The carrier sees ciphertext and bounded routing metadata only. It cannot answer /me, select /we, serve/adopt sync, append a ledger, mint a receipt, issue presence, decide a relationship or acquire a Cluster fence.

Normative contract: specs/peer-transport-v1.md and schemas/transport/v1/peer-envelope.schema.json.

Runtime and crash contract

  • Runtime bundle V3 adds an optional closed peer_transport section; V1/V2 remain loadable and peer transport is absent by default.
  • Private X25519 material stays in owner-only encrypted DM-021 custody under a purpose-specific slot. Endpoints and process configuration cannot substitute identity.
  • daimon-matrixd serves bounded POST /dm-peer/v1 concurrently with its owner-local AF_UNIX API only when V3 enables the peer endpoint.
  • Emission freezes one randomized encrypted request in an owner-only durable outbox before network I/O. Exact retry sends byte-identical ciphertext.
  • Ingress binds envelope ID to exact ciphertext hash and a bounded processing lease before handler execution. Exact replay returns the committed byte-identical response; changed bytes conflict.
  • Response loss after remote completion retries the same request. Existing DM-054 scope and DM-023 sync idempotency remain the handler effect truth; transport ACK never means semantic adoption.
  • /we.sync pull still imports events as known, preserves origin and performs no automatic adoption.

Implementation acceptance

  • Closed schema/module/runtime V3/daemon endpoint are packaged and documented.
  • Two root-bound embodiments complete encrypted scope request/response and paginated sync request/delta through the real protocol handlers.
  • Real HTTP I/O observes no typed plaintext; a hub/broker is not needed for direct peer calls.
  • Exact response-loss retry executes the remote handler once and returns byte-identical response bytes.
  • Concurrent duplicate, lease takeover, request-ID conflict, crash-before-commit, restart and corrupted durable-state cases fail/recover deterministically.
  • Tamper, noncanonical JSON, open fields, unknown content type/profile, wrong recipient/principal/key/body/incarnation/being/manifest, expiry, revocation and size-bound negatives fail closed.
  • Existing DM-021/023/051/052/053/054 tests, full source suite, installed wheel, strict lint/types, reproducible builds, conformance and secret scans remain green.
  • CI and explicit self-audit are the implementation review gate; no recursive external review request is required.

Operational canary acceptance

  • Operator records exact Matrix commit/wheel, V3 bundle hashes, root/manifest/control head, two embodiment/incarnation/credential IDs, AnyVPN endpoints and rollback configuration without publishing secrets.
  • Two installed daimon-matrixd processes on named hosts exchange /me and multi-page /we.sync; each response/event retains its actual origin and pull does not adopt.
  • Restart/resume and one deliberate response-loss drill preserve outbox/inbox replay and ledger high-waters.
  • Manifest mismatch and a bounded revocation drill produce zero accepted peer effect.
  • An ordinary Tribe v1 human message still works unchanged during coexistence; no Matrix peer envelope appears in Tribe stores.
  • Human explicitly approves cutover after reviewing receipts, then the native peer profile becomes the configured Weave path.

Rollback

Rollback disables the V3 peer profile/listener and returns to the exact prior transport configuration. Preserve peer outbox/exchange state for diagnosis. Never rewrite/delete Matrix ledgers, lower cursors/high-waters, translate envelopes, import Tribe rows, restore Tribe v0 or represent carrier ACK as semantic delivery. Ordinary Tribe messaging remains independent until DM-077.

Implementation paths

  • src/daimon_matrix/peer_transport.py
  • src/daimon_matrix/runtime.py
  • src/daimon_matrix/daemon.py
  • schemas/transport/v1/peer-envelope.schema.json
  • schemas/hosted/v3/bundle.schema.json
  • tests/test_dm055_peer_transport.py
  • specs/peer-transport-v1.md
  • docs/dm055-native-peer-cutover.md
  • conformance registry, release invariants, packaging/CI and Kanban evidence

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:tribeCommunications and Tribe migrationneeds-humanRequires an explicit human decision or actionpriority:P2Later V0 workrisk:migrationCompatibility or migration riskstatus:blockedBlocked by dependencies or reviewtype:opsDeployment, migration, or operational work

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions