Skip to content

RFC-64 M1 2/2: activate selected public catalogs - #2090

Open
branarakic wants to merge 6 commits into
codex/rfc64-m1-edge-selectionfrom
codex/rfc64-m1-selected-public-activation
Open

RFC-64 M1 2/2: activate selected public catalogs#2090
branarakic wants to merge 6 commits into
codex/rfc64-m1-edge-selectionfrom
codex/rfc64-m1-selected-public-activation

Conversation

@branarakic

@branarakic branarakic commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

User impact

This turns the RFC-64 public catalog data plane into an operable, deliberately
bounded feature. An operator can select specific public Context Graphs; only
those graphs become durable subscriptions, only those graphs can advance a
catalog after an ordinary confirmed KA publication, and receivers expose exact
per-author applied-head evidence through /api/status.

The default remains dormant. Omitting rfc64PublicCatalog, or setting
enabled: false, accepts no policies, starts no catalog bootstrap, and installs
no publication hook.

Stack

Before

The catalog transport existed, but normal daemon configuration did not select
policies, producers, or receiver targets. Ordinary publishing and legacy sync
continued, while the RFC-64 catalog lane remained fail-closed and invisible to
operators.

sequenceDiagram
    participant Operator
    participant Daemon
    participant Publisher
    participant Chain
    participant Receiver
    Operator->>Daemon: "Start with normal config"
    Daemon->>Daemon: "RFC-64 transport starts without accepted policy"
    Publisher->>Chain: "Publish public KA"
    Chain-->>Publisher: "Confirmed"
    Publisher->>Publisher: "No RFC-64 auto-publish configuration"
    Receiver->>Receiver: "No pinned catalog target"
    Note over Daemon,Receiver: "Catalog code is present but dormant"
Loading

After

One pinned finalized-policy manifest is the sole selection source. The daemon
uses its CG IDs for both durable subscription and the optional producer
allowlist; it rejects a second caller-supplied allowlist. A receiver retries the
explicit provider list, performs the existing policy/catalog/chain checks, and
reports the exact applied head.

sequenceDiagram
    participant Operator
    participant Daemon
    participant Publisher
    participant Chain
    participant Provider
    participant Receiver
    Operator->>Daemon: "Enable with pinned public-policy manifest"
    Daemon->>Daemon: "Validate manifest and derive exact CG allowlist"
    Daemon->>Receiver: "Durably subscribe only selected CGs"
    Publisher->>Chain: "Publish KA in selected public CG"
    Chain-->>Publisher: "Confirmed VM result"
    Publisher->>Provider: "Advance durable signed author-catalog head"
    Provider-->>Receiver: "Availability hint"
    Receiver->>Provider: "Fetch signed head, inventory, and KA bundle"
    Receiver->>Chain: "Verify finalized VM binding"
    Receiver->>Receiver: "Apply content and CAS applied-head pointer"
    Receiver-->>Operator: "Status: applied head, version, row count, provider"
Loading

What changed

  • adds explicit rfc64PublicCatalog.enabled activation to daemon config;
  • derives the exact selected-CG set from
    bootstrap.acceptedPublicPolicies[*].policyEnvelope.payload.contextGraphId;
  • unions only that selected set into durable graph synchronization;
  • makes the normal-publication catalog hook enforce the same bounded allowlist;
  • forwards the pinned policy/bootstrap and optional producer controls into the
    existing RFC-64 service;
  • exposes selected graphs, service stats, bootstrap passes, provider outcome,
    applied-head digest, catalog version, inventory row count, and bounded error
    evidence at GET /api/status;
  • documents operator configuration and the restart/failover completeness gate.

Catalog advancement happens only after chain confirmation and remains
fail-open relative to the already-confirmed KA: an RFC-64 catalog error is
logged and does not turn a successful mint into a false publication failure.

Safety boundaries

  • No sync all public CGs mode.
  • Legacy direct DKGAgent.create auto-publish callers remain source-compatible;
    selected daemon activation uses one new versioned agent config object.
  • Maximum 64 selected producer CGs, canonical and unique.
  • Public policies only; the agent performs full canonical manifest validation
    before transport startup.
  • CGs outside the manifest remain on the existing publication/sync path.
  • Policy and explicit deployment network identity must match the daemon effective chain before runtime starts.
  • Provider peer IDs and finalized policy envelopes remain pinned inputs.
  • Automatic provider discovery, automatic chain-to-policy generation, private
    CG catalogs, and a network-wide Core scheduling policy are not claimed here.

Validation

  • @origintrail-official/dkg-agent build, strict type/package-root checks: pass
  • @origintrail-official/dkg full dependency-chain build: pass
  • affected package tsc --noEmit: pass
  • RFC-64 production native wiring: 1 file / 30 tests passed
  • CLI config + daemon + status focused suites: 4 files / 143 tests passed
  • activation-focused CLI rerun: 5 passed, 120 unrelated skipped
  • real-daemon, real-Hardhat status suite: 1 file / 9 tests passed
  • git diff --check: pass

Canary acceptance after restack

  1. Boot exact candidate SHA with activation omitted and prove behavior remains
    dormant.
  2. Enable one selected public CG on publisher and receiver.
  3. Publish new KAs while receiver is live; require exact applied-head and VM
    content parity.
  4. Cold-start a clean receiver; require the same head and inventory count
    without manual catch-up.
  5. Restart the receiver and repeat the exact-head check.
  6. Remove the primary provider and require bootstrap failover to the pinned
    backup provider.
  7. Run the bounded testnet-canary soak only after all prior gates pass.

@branarakic

Copy link
Copy Markdown
Contributor Author

Exact-head validation update for d2eed1736b82bf53dd6c8184941a770c56c99e54:

  • Full local @origintrail-official/dkg-agent unit lane: 166 files / 2,299 passed / 5 skipped / 0 failed.
  • Manually dispatched full CI because the stacked base does not trigger the protected-base workflow: CI run 30957734958.
  • Exact-head EVM integration is complete and green: EVM run 30957734935.
  • testnet-canary remains at 84c2d1bb8e7ad812092648e36adde05ec7365e82; the reviewed stack has not drifted.

No merge or deployment has been performed.

Comment thread packages/cli/src/config.ts Outdated
Comment thread packages/cli/src/daemon/routes/status.ts Outdated
Comment thread packages/cli/src/config.ts Outdated
Comment thread packages/cli/src/daemon/lifecycle.ts Outdated
Comment thread packages/cli/src/daemon/routes/status.ts Outdated
@branarakic

Copy link
Copy Markdown
Contributor Author

Follow-up exact-head evidence for 10529ce7740f47f4b8183cce71b4795f30bcbf7a:

  • Kept canonical activation normalization shared, but moved it behind a narrow side-effect-free public agent subpath. CLI config no longer imports the full DKGAgent runtime.
  • Agent build + type contracts + package-root export classification: pass.
  • CLI tsc --noEmit: pass.
  • Activation resolver/daemon wiring: 127/127 passed.
  • Activation status projection: 3/3 passed (7 unrelated tests filtered).
  • The integration regression caught during the broad local lane now passes alone: write-preflight-resilience 34/34.
  • The broad local lane before that correction reached 1,922 passed / 48 skipped; its five other failed suites all lacked the external shared-Hardhat context file, so the fresh orchestrated GitHub CI/EVM runs are the authoritative real-chain gate.

Fresh exact-head workflows: CI 30959093666, EVM 30959095192. No merge or deployment has been performed.

Comment thread packages/agent/src/rfc64/public-catalog-activation-config-v1.ts
@branarakic

Copy link
Copy Markdown
Contributor Author

Exact-head update ebfac6898: centralized the complete selected-public activation resolver in the side-effect-free agent package surface, leaving the CLI as a thin adapter. Local evidence: agent build + type + package-root checks pass; CLI TypeScript passes; config/daemon/status focused lane passes 4 files / 142 tests. Fresh exact-head CI is running.

Comment thread packages/agent/src/rfc64/catalog-authority-config-v1.ts Outdated
Comment thread packages/cli/test/status-route-rpc.test.ts
Comment thread packages/agent/src/dkg-agent-types.ts Outdated
Comment thread packages/cli/test/daemon-storage-ack-timing-wiring.test.ts
@branarakic

Copy link
Copy Markdown
Contributor Author

Exact-head update a8e053e42: preserves the legacy direct-agent auto-publish API, moves selected-public behavior behind one unified versioned activation snapshot, validates split selection at DKGAgent.create, gates disabled status reads, and broadens the pre-side-effect startup proof. Local evidence: agent build/type/package-root pass; direct-agent RFC-64 integration 26/26; CLI config/daemon/status 142/142; git diff --check passes. Fresh exact-head CI is starting.

Comment thread packages/agent/src/rfc64/public-catalog-activation-config-v1.ts
@branarakic
branarakic force-pushed the codex/rfc64-m1-selected-public-activation branch from a8e053e to a17f092 Compare August 4, 2026 23:39
@branarakic

Copy link
Copy Markdown
Contributor Author

Exact-head update: a17f09230f558b7b2cb604cd7db0016bc1a318e3

This folds the final activation-snapshot cleanup into the unified boundary: the daemon resolves and freezes the selected-public activation object once, and DKGAgent.create now consumes those exact frozen deployment, auto-publish, and bootstrap components without re-snapshotting them.

Exact-tree local evidence:

  • agent build: pass
  • RFC-64 native DKGAgent integration: 1 file / 26 tests passed
  • git diff --check: pass

The generated localhost contract deployment artifact remains excluded from the PR. Fresh exact-head CI and EVM workflows have been dispatched, and automated review has been re-requested.

Comment thread packages/agent/src/dkg-agent.ts Outdated
Comment thread packages/agent/src/dkg-agent-rfc64-catalog-auto-publish.ts Outdated
Comment thread packages/agent/src/dkg-agent.ts Outdated
Comment thread packages/agent/src/dkg-agent.ts Outdated
@branarakic
branarakic force-pushed the codex/rfc64-m1-selected-public-activation branch from a17f092 to 76e8006 Compare August 4, 2026 23:45
@branarakic

Copy link
Copy Markdown
Contributor Author

Exact-head update: 76e8006ca7775a7423f55ba245f2561d8fa89424

The final open review item is addressed and resolved. RFC-64 activation now uses an explicit typed chain identity (networkId, evmChainId) derived by one named side-effect-free helper; policy-network and deployment-chain checks no longer share an ambiguously named raw string. Inconsistent identity pairs fail closed.

Exact-tree local evidence:

  • agent build + type contract + package subpath: pass
  • native DKGAgent RFC-64 integration: 1 file / 26 tests passed
  • CLI config/daemon/status: 4 files / 142 tests passed
  • git diff --check: pass

The shared Hardhat localhost deployment artifact remains excluded. Fresh exact-head CI and EVM runs are queued, and automated review has been re-requested.

Comment thread packages/cli/test/config.test.ts
@branarakic
branarakic force-pushed the codex/rfc64-m1-selected-public-activation branch 3 times, most recently from cedadfe to 930a3f5 Compare August 5, 2026 00:01
@branarakic

Copy link
Copy Markdown
Contributor Author

Exact-head evidence for 930a3f5:

  • agent build, strict type tests, and package-root checks: pass
  • RFC-64 native production wiring: 30/30 pass
  • CLI config, daemon, and status suites: 143/143 pass
  • diff check: pass
  • all five current review threads addressed and resolved

The generated localhost deployment artifact remains excluded from the commit.

@branarakic
branarakic force-pushed the codex/rfc64-m1-selected-public-activation branch from 930a3f5 to c0f6b9b Compare August 5, 2026 00:05
@branarakic

Copy link
Copy Markdown
Contributor Author

Updated exact-head evidence for c0f6b9b:

  • accepted-but-unselected public CG suppression is now explicit
  • publisher and receiver both retain no applied head for that scope
  • selected-CG publication and receiver apply remain green
  • RFC-64 native production wiring: 30/30 pass
  • diff check: pass

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants