RFC-64 M1 2/2: activate selected public catalogs - #2090
Conversation
|
Exact-head validation update for
No merge or deployment has been performed. |
|
Follow-up exact-head evidence for
Fresh exact-head workflows: CI 30959093666, EVM 30959095192. No merge or deployment has been performed. |
|
Exact-head update |
|
Exact-head update |
a8e053e to
a17f092
Compare
|
Exact-head update: This folds the final activation-snapshot cleanup into the unified boundary: the daemon resolves and freezes the selected-public activation object once, and Exact-tree local evidence:
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. |
a17f092 to
76e8006
Compare
|
Exact-head update: The final open review item is addressed and resolved. RFC-64 activation now uses an explicit typed chain identity ( Exact-tree local evidence:
The shared Hardhat localhost deployment artifact remains excluded. Fresh exact-head CI and EVM runs are queued, and automated review has been re-requested. |
cedadfe to
930a3f5
Compare
|
Exact-head evidence for 930a3f5:
The generated localhost deployment artifact remains excluded from the commit. |
930a3f5 to
c0f6b9b
Compare
|
Updated exact-head evidence for c0f6b9b:
|
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 settingenabled: false, accepts no policies, starts no catalog bootstrap, and installsno publication hook.
Stack
codex/rfc64-m1-edge-selection)restacked on its exact
testnet-canaryhead and validated as one candidate.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"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"What changed
rfc64PublicCatalog.enabledactivation to daemon config;bootstrap.acceptedPublicPolicies[*].policyEnvelope.payload.contextGraphId;existing RFC-64 service;
applied-head digest, catalog version, inventory row count, and bounded error
evidence at
GET /api/status;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
sync all public CGsmode.DKGAgent.createauto-publish callers remain source-compatible;selected daemon activation uses one new versioned agent config object.
before transport startup.
CG catalogs, and a network-wide Core scheduling policy are not claimed here.
Validation
@origintrail-official/dkg-agentbuild, strict type/package-root checks: pass@origintrail-official/dkgfull dependency-chain build: passtsc --noEmit: passgit diff --check: passCanary acceptance after restack
dormant.
content parity.
without manual catch-up.
backup provider.